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

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Mar 26 06:10:31 UTC 2008

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 

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.

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

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


More information about the Standards mailing list