Re: rfc3920bis: SASL "fallback" on auth failure

On Tuesday 25 March 2008 2:16 pm, Peter Saint-Andre wrote:
> Evan Schoenberg of the Adium project pinged offlist
regarding the proper
> behavior for a client to follow if SASL authentication
fails using one
> mechanism but other mechanisms are available. I think a
flow like the
> following makes sense (I ran this by Alexey Melnikov
and he concurred).
>
> C: <auth xmlns='urn:ietf:paramsml:ns
mpp-s
asl'
>          mechanism='DIGEST-MD5'>=</auth>
>
> challenge + response etc.
>
> S: <failure xmlns='urn:ietf:paramsml:ns
mpp-s
asl'>
>      <not-authorized/>
>    </failure>
>
> C: <auth xmlns='urn:ietf:paramsml:ns
mpp-s
asl'
>          mechanism='PLAIN'/>

The one trouble with this approach that I've discovered is
that you can't 
easily reprompt for a password.  Suppose you have a client
that doesn't save 
a password, and prompts on demand.  What should it do if
DIGEST-MD5 returns 
not-authorized?  The user could have just made a typo, but
instead we'll try 
some other mechanism?  Weird.  And we probably shouldn't
prompt for the 
fallback mechanisms.

I guess the unfortunate solution is something like this:
  1) Try SASL mechs in some order.
  2) If one asks for a password, prompt, cache, and use a
password.
  3) If another mech asks for a password, use the cached
password.
  4) If all mechs fail, only then clear the password cache
and start over.

> Alexey pointed out that we probably need to specify
some text like this:
>
>    SASL mechanisms MUST be tried in the order of their
strength as
>    perceived by the client (assuming the client has
this information).
>    For example, if the server advertises "PLAIN
DIGEST-MD5 GSSAPI" or
>    "DIGEST-MD5 GSSAPI PLAIN", the client
should try GSSAPI first, then
>    DIGEST-MD5, then PLAIN. The client should also be
able to disallow
>    some mechanisms (e.g. PLAIN).

Also, if using a SASL library, probably the best approach to
ensuring the 
proper selection order is to remove the offending mechanism
from the list and 
retry again using the reduced list.  Repeat until out of
mechanisms.

-Justin

Justin Karneges wrote:

>On Tuesday 25 March 2008 2:16 pm, Peter Saint-Andre
wrote:
>  
>
>>Evan Schoenberg of the Adium project pinged offlist
regarding the proper
>>behavior for a client to follow if SASL
authentication fails using one
>>mechanism but other mechanisms are available. I
think a flow like the
>>following makes sense (I ran this by Alexey Melnikov
and he concurred).
>>
>>C: <auth xmlns='urn:ietf:paramsml:ns
mpp-s
asl'
>>         mechanism='DIGEST-MD5'>=</auth>
>>
>>challenge + response etc.
>>
>>S: <failure xmlns='urn:ietf:paramsml:ns
mpp-s
asl'>
>>     <not-authorized/>
>>   </failure>
>>
>>C: <auth xmlns='urn:ietf:paramsml:ns
mpp-s
asl'
>>         mechanism='PLAIN'/>
>>    
>>
>The one trouble with this approach that I've discovered
is that you can't 
>easily reprompt for a password.  Suppose you have a
client that doesn't save 
>a password, and prompts on demand.  What should it do if
DIGEST-MD5 returns 
>not-authorized?
>
The client should try a reasonable number of retries with
the same SASL 
mechanism.

>The user could have just made a typo,
>
Indeed.

>but instead we'll try 
>some other mechanism?
>
The client needs to retry the same mechanism several times,
then 
fallback to the next one, etc.

But this is a bit of oversimplification. There is one
complication: some 
mechanisms require password to be asked directly from the
user (e.g. 
DIGEST-MD5, CRAM-MD5, PLAIN), but others typically require
the user to 
specify the password before launching the application (e.g.
to obtain 
Kerberos ticket for GSSAPI). In the latter case there is no
need to 
retry: either the client has a valid Kerberos ticket or it
doesn't. 
However SASL APIs don't necessarily have a way of telling
applications 
about differences between the two types of mechanisms
described above.

>Weird.  And we probably shouldn't prompt for the 
>fallback mechanisms.
>
>I guess the unfortunate solution is something like
this:
>  1) Try SASL mechs in some order.
>  2) If one asks for a password, prompt, cache, and use
a password.
>  3) If another mech asks for a password, use the cached
password.
>  
>
If another mechanism asks for a password, it means that
authentication 
using the previous mechanism failed.
So the client might as well ask for the password again.

>  4) If all mechs fail, only then clear the password
cache and start over.
>  
>
>>Alexey pointed out that we probably need to specify
some text like this:
>>
>>   SASL mechanisms MUST be tried in the order of
their strength as
>>   perceived by the client (assuming the client has
this information).
>>   For example, if the server advertises "PLAIN
DIGEST-MD5 GSSAPI" or
>>   "DIGEST-MD5 GSSAPI PLAIN", the client
should try GSSAPI first, then
>>   DIGEST-MD5, then PLAIN. The client should also be
able to disallow
>>   some mechanisms (e.g. PLAIN).
>>    
>>
>Also, if using a SASL library, probably the best
approach to ensuring the 
>proper selection order is to remove the offending
mechanism from the list and 
>retry again using the reduced list.  Repeat until out of
mechanisms.
>  
>
Yes.