Multiple-Mechanism Sample Code?

[Henry B. Hotz]

On Dec 31, 2006, at 9:41 PM, Ken Hornstein wrote:

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

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

Around here all users are in the central repository, but the  
administrative accounts for services are local to the service.  I was  
envisioning "GSSAPI CRAM-MD5" as a back-door way of supporting two  
different repositories.

> - If authentication fails with the chosen mechanism, error out and
>   return the error text 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.  ;-)

------

My own prejudices:

I think Cyrus SASL should take care of trying all the mutually  
supported mechanisms.  The client app programmer should never have to  
tell the server what mechanism it's trying; that ought to be in the  
"clientout" data returned by sasl_client_{start,step}().  The client  
app programmer should never have to call sasl_client_start() a second  
time to make the library try all of the mechanisms.  SASL_INTERACT  
should only be returned by sasl_client_start(), and never by  
sasl_client_step().  The client app should not require any mechanism  
selection configuration at all (except to exclude insecure mechanisms).

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.  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 opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu