[Standards] rfc3920bis: SASL "fallback" on auth failure
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
>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
>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
>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
More information about the Standards