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

Joe Hildebrand hildjj at gmail.com
Wed Mar 26 02:23:44 UTC 2008


Questions for the security folks:
- Does this lead to a potential downgrade attack?
- Does this require the use of a secure channel like TLS to prevent  
downgrade attacks?
- If not, and we can use a negotiated security layer, what happens  
when you try to switch to a SASL mechanism that doesn't support that  
security layer?

On Mar 25, 2008, at 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'/>
>
> 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).
>
> Peter
>
> -- 
> Peter Saint-Andre
> https://stpeter.im/
>

-- 
Joe Hildebrand




More information about the Standards mailing list