Multiple-Mechanism Sample Code?

[Ken Hornstein]

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