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:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'>=</auth>
challenge + response etc.
S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<not-authorized/>
</failure>
C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
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
