On Mon Dec 18 22:12:03 2006, 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).
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.
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.
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.
There are more complications than that - some protocols give you a
fairly wide set of protocol-level data about why a SASL exchange
failed, others don't. For example, IMAP will give you a pretty simple
"NO" for any failure at all, whereas ACAP will tell you rather more,
such as AUTH-TOO-WEAK, ENCRYPT-NEEDED, TRANSITION-NEEDED, etc, which
can be used by the client to figure out what the next action should
be.
Also, you need to add TLS into the mix, too - which is in itself
negotiated, of course, and will probably change the advertised
mechanisms.
As a for-example, a ACAP client might initially try DIGEST-MD5,
cancel it partway through because no encryption was supported, use
STARTTLS, try DIGEST-MD5, fail due to a TRANSITION-NEEDED code, and
use PLAIN.
An IMAP client in more or less tha same situation has longer to go,
because it doesn't get the TRANSITION-NEEDED code, and therefore has
no idea if it should retry DIGEST-MD5 a few times, or try a different
mechanism.
As if anyone needed *more* reasons to use ACAP. :-)
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
