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.
|
ml:ns
