Multiple-Mechanism Sample Code?

[Henry B. Hotz]

Thanks!

On Dec 31, 2006, at 1:18 AM, Alexey Melnikov wrote:

> Henry B. Hotz wrote:
>> On Dec 18, 2006, at 2:12 PM, Alexey Melnikov wrote:
>>> Henry B. Hotz wrote:
>>>> The published sample code seems to only try the first mechanism  
>>>> and  then quit.  I'm told the "correct" way to do SASL is to try  
>>>> all the  mechanisms (or at least all the ones supported) and  
>>>> don't quit until  you've tried them all.  Is there any example  
>>>> code that illustrates this?
>>> (I wanted to point you to Cyrus imtest, but it doesn't do that).
>> It's worse than that.  |-(
>>
>> I kept looking after I posted that note, and I haven't even found  
>> any suggestion that it was feasible beyond Simon Wilkinson's  
>> comment at the UMich workshop.
>>
>> In a(n admitedly limited) test calling sasl_client_start multiple  
>> times with the same mechanism list always results in the same  
>> mechanism being chosen.  This seems to mean that you need to  
>> duplicate the list parsing code in your app and keep track of the  
>> untried mechanisms yourself.
> This is correct.
>> It also means I need to play games in order to avoid prompting the  
>> user for a username once for each mechanism that I try.
> I think this can be done using the interaction callback.
>> Now that I'm trying to actually use the API there are a number of  
>> other things that seem awkward as well, but that's OT.
>>> In general, I think a well written SASL client should behave as  
>>> follows:
>>>
>>> It should sort SASL mechanisms that both client and server  
>>> support by their "strength" or features recognized by the client.  
>>> For SASL mechanisms with equal strength the order used by the  
>>> server can be used.
>> How *does* the server order them?
>>
>> Putting "GSSAPI ANONYMOUS" in the config file results in the same  
>> list.  Putting "GSSAPI PLAIN" in the config file results in "PLAIN  
>> GSSAPI" from sasl_listmech().  Whyzzat?
> The server uses the order in which plugins were loaded from disk.
>> I don't think I'm supposed to care about the ordering.  The  
>> security considerations section of the SASL RFC says the mechanism  
>> is negotiated in the clear, and you should expect that a 3rd party  
>> may modify it.
> Right.
>> That means that *any* mechanism accepted by the server or client  
>> under any circumstances had better be "good enough".  That said I  
>> would much prefer GSSAPI/Krb5 to a mechanism that requires me to  
>> type in stuff.
>>> The client starts iterating through the ordered list, starting  
>>> from the strongest mechanism. It tries the mechanism. If  
>>> authentication succeeds - success. If not, the client may retry  
>>> the mechanism (e.g. if the server returned an indication that the  
>>> password is incorrect) several times, say 3 times. After that the  
>>> client should move on to the next strongest SASL mechanism and so  
>>> on.
>> Since the password prompt is very early after you start the client  
>> I don't think it's a big deal to just start the client over again.
> I would disagree if we are talking about a GUI client ;-).
> I wouldn't like to restart Thunderbird every time I mistype  
> password :-)
>> (Usually, not always!)
>>> There are of course some complications. Some SASL mechanisms that  
>>> can potentially be stronger can end up being weaker, because of  
>>> the options that the server supports.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu