Re: rfc3920bis: SASL "fallback" on auth failure

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:paramsml:ns
mpp-s
asl'
>         mechanism='DIGEST-MD5'>=</auth>
>
> challenge + response etc.
>
> S: <failure xmlns='urn:ietf:paramsml:ns
mpp-s
asl'>
>     <not-authorized/>
>   </failure>
>
> C: <auth xmlns='urn:ietf:paramsml:ns
mpp-s
asl'
>         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

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.

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.

-Justin