>> Now, my suggestions? I think a SASL client should do the following: >> >> - Allow (and perhaps even enforce) the selection of a specific SASL >> mechanism. > >Do you disagree with Simon's recommendation that a client should try >all mutually supported mechanisms before giving up? In a perfect world ... no. In this world ... yes, I disagree. #1 - You need mechanism-specific knowledge to do this right. Otherwise you end up with things like prompting for a new password when you get a GSSAPI failure. I'll give you a related example: I had cases where the MacOS X-suppled ssh would "hang" for a long time when someone would kinit and then ssh to a system that didn't support GSSAPI. I wasn't able to debug it completely because the user ended up being a flaming asshole, but my theory was that when a credential cache appeared, the MacOS X ssh would always try GSSAPI ... and that was behaving badly in domains that didn't have Kerberos support. Now, people are going to point out that ssh doesn't use SASL, and that's certainly true ... I only bring it up to illustrate that I can easily envision cases where you shouldn't attempt to use GSSAPI, even if the server supports it. #2 - If you try all of the mechanisms and they all fail ... what kind of error message should you return to the user? >Absolutely necessary. Of course the error you want is for the >mechanism that was supposed to work, and not for the ones that were >supposed to fail. ;-) Right, and if you figure out how to determine _that_, let me know :-) >What I see in practice is that most (everything except MacOS X >ldapsearch?) applications make you select the specific, actual >mechanism on the client side. Nobody actually uses the mechanism >negotiation that the protocol provides. Actually, in the code I've written I let mechanism negotiation happen by default, but I let the user configure a specific mechanism if they want. This seems to work reasonably well. But there's only one shot at authentication. >I think we're both touching >on reasons why: the library doesn't properly support it. Maybe the >protocol is inadequate to make it work reliably, but I would think >that trying all the possibilities SHOULD make it more reliable rather >than less. The problem I see is that this would require the library to be able to say, "Okay, now restart authentication with this mechanism". Perhaps that wouldn't be hard. But ... and I hate harp on it, but it's very important to me ... error reporting would be a real bitch if you did that. --Ken
