[Standards] rfc3920bis: SASL "fallback" on auth failure

Alexey Melnikov alexey.melnikov at isode.com
Wed Mar 26 10:49:54 UTC 2008


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:params:xml:ns:xmpp-sasl'
>>         mechanism='DIGEST-MD5'>=</auth>
>>
>>challenge + response etc.
>>
>>S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>     <not-authorized/>
>>   </failure>
>>
>>C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
>>         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.




More information about the Standards mailing list