>>> 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. I wasn't able to reply to your original note, but since it got brought up again ... I just wanted to offer my $0.02. I personally think this advice is wrong. I am speaking from the perspective of someone who uses (or at least tries to use) the SASL GSSAPI mechanism as much as possible, and I've written code that uses the Cyrus-SASL library as well as my own lightweight GSSAPI-SASL library code (I had my reasons for not using Cyrus-SASL for that one). Here are my reasons: - Doing this is complicated. As people have already noted, doing this right is a lot of work. If you try to use the Cyrus-SASL library, you have to duplicate the list parsing yourself, which just increases the complexity. Complexity means more bugs, and it also decreases the likelihood people will even bother to implement SASL in their products (other than the default CRAM-MD5 mechanism). If you want to do this _right_, it also requires mechanism-specific knowledge. Maybe redoing CRAM-MD5 attempts is correct, because the user's password could be wrong. But redoing GSSAPI is almost certainly wrong (although I guess retrying it isn't harmful). But I recall one recent app (I want to say Thunderbird, but I could be wrong) that if GSSAPI failed, it prompted you for a password ... THAT everyone would agree is wrong, and is just confusing for users. - It makes things more complicated for users. In your scenario, what kind of error message should be returned to a user? All of the errors from all of the mechanisms? Just the last one? None? I ask because getting the error message back from a failed SASL-GSSAPI authentication exchange is _crucial_ to debugging users problems. Like I said above, at least one recent SASL app just gave you a new password prompt for every error, even with GSSAPI. Debugging THAT issue was a whole lot of fun (I think I ended up using a system call tracer; I could have saved myself an hour's worth of work if the damn program just spit out a useful message). Also, it's sometimes rather difficult to determine if an application supports the mechanism I am interested in. I don't mean to bash on Simon's fine work at GSSAPI-ing the world; I've had many chats with him and I know the problems he's faced. It's just that it's not always clear to me with some of the programs I've run into how you're supposed to turn GSSAPI authentication on. I guess the idea is that it's "magically" supposed to work ... but when it doesn't, I'm sitting around scratching my head going, "Well, does this version even _support_ it? Do I need to enable some wacky registry key?" I like to consider myself pretty Kerberos savvy, but _none_ of these automagic SASL-GSSAPI programs ever work for me on the first try. I will contrast this with Apple's Mail.app. It has a very clear UI element to select between different SASL mechanisms, and one of them is "Kerberos V (GSSAPI)". I know that when I select that, it's going to use the mechanism I want, and none of the others. I will confess that I don't know if it returns useful error messages, because it's always worked on the first try for me. - Not all mechanisms are created the same. Aside from the issue of attacks, in general don't want my users to be using any random mechanism; I want them to be using GSSAPI in all but a few cases. If we get other SASL mechanisms that use some kind of infrastructure, I imagine the users of those mechanisms will feel the same way. If GSSAPI is failing, I consider that a serious problem and I want to know about it, _now_. I don't want users falling back to CRAM-MD5 (okay, I prevent that on the server, but I can't think of a situation where trying a bunch of mechanisms is preferrable to explicit mechanism selection on the client). Now, my suggestions? I think a SASL client should do the following: - Allow (and perhaps even enforce) the selection of a specific SASL mechanism. - If a mechanism is not specifically selected, pick the "best" one (I'm sure we could get into massive arguments about what the "best" mechanism is). You could use some intelligence here; if you don't have a Kerberos credential cache, for example, don't try GSSAPI. - If authentication fails with the chosen mechanism, error out and return the error text to the user. --Ken
