Multiple-Mechanism Sample Code?

[Alexey Melnikov]

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.