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

Alexey Melnikov alexey.melnikov at isode.com
Wed Mar 26 11:11:12 UTC 2008


Justin Karneges wrote:

>On Tuesday 25 March 2008 7:23 pm, Joe Hildebrand wrote:
>  
>
>>Questions for the security folks:
>>- Does this lead to a potential downgrade attack?
>>    
>>
>Yes, an attacker could spoof an error reply by the server, so the client 
>chooses a different mechanism.  For example, it could cause errors to occur 
>for all mechanisms except PLAIN.  However, even without the mechanism 
>fallback feature we are discussing, clients are still susceptible to a 
>downgrade attack since the attacker can simply change the mechanism list 
>offered by the server.  This is an even easier and more effective attack, 
>since the attacker can add the PLAIN mechanism to the list if it is not 
>present.
>  
>
Indeed.

>Clients using SASL libraries should be insulated from all downgrade attacks.  
>Cyrus SASL, for example, will only ever choose mechanisms that match the 
>selected security settings, so there's really nothing the client developer 
>can do to screw this up.
>  
>
Right.

>>- Does this require the use of a secure channel like TLS to prevent
>>downgrade attacks?
>>    
>>
>This is one way to solve it, although it does sort of pass the buck since TLS 
>itself is vulnerable to very similar downgrade attacks 
>(s/mechanisms/ciphersuites).  In the end, you need a minimum security level, 
>whether it is at the TLS or SASL layer.
>  
>
Very well said.

>>- 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?
>>    
>>
>If the client's minimum security level requires a security layer, then the 
>client should never pick a mechanism that does not have one.
>  
>
Exactly. The client should require some minimal security layer from TLS 
and/or SASL.




More information about the Standards mailing list