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
