Multiple-Mechanism Sample Code?

Henry B. Hotz hotz at
Sun Dec 31 12:52:13 EST 2006


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, or hbhotz at

More information about the Cyrus-sasl mailing list