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. 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.
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?
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.
(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@xxxxxxxxxxxx, or hbhotz@xxxxxxx
