Multiple-Mechanism Sample Code?
alexey.melnikov at isode.com
Sun Dec 31 04:18:17 EST 2006
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.
> 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.
More information about the Cyrus-sasl