Multiple-Mechanism Sample Code?

[Dave Cridland]

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 at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade