Multiple-Mechanism Sample Code?

[Andreas Winkelmann]

On Monday 18 December 2006 23:12, Alexey Melnikov 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.

This is ok and already implemented.

> 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.

No, I would say this is a Security Risk and of course useless.

If the Server offers DIGEST-MD5 and PLAIN. And the User/Client trys wrong 
Credentials, the Second try will pass in Cleartext the Internet. I would not 
like to see that if I just make a Typo in the Password, you?

Oh and useless, because why should there be a difference between one of the 
Offered Mechanisms? If DIGEST-MD5 with one set of Credentials fails, why 
should it succeed with PLAIN? This is only the case with misconfigured 
Servers (Offering *-MD5 Mechanisms with saslauthd for example). 

> 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.

-- 
	Andreas