[Standards] SASL Negotiation in XMPP Core introduces potential security concern
sam at samwhited.com
Mon Dec 8 20:45:52 UTC 2014
aIn XMPP CORE (RFC 6120) §6.3.3:
> the client's ordered list is "GSSAPI SCRAM-SHA-1", the client MUST
> try GSSAPI first and then SCRAM-SHA-1
Suggests that when authing with SASL we should fallback if auth fails
(eg. if both server and client support SCRAM-SHA-1 and DIGEST-MD5, and
SCRAM-SHA-1 auth fails, we should fallback and attempt auth with
DIGEST-MD5). Am I reading this correctly?
If so, is this not a potential security concern? Imagine the scenario
described above over an unencrypted (no TLS) connection. An attacker
could inject arbitrary data (shaped like an auth challenge stanza) into
the stream to force SCRAM-SHA-1 to fail, then simply record the
DIGEST-MD5 auth which is easier to break.
Am I missing something here? It seems to me that the client should pick
its prefered (presumably the most secure) auth method that is also
supported by the server and refuse to do anything else (trusting that if
the server is advertising it, it's actually supported).
The only problem I can see here is that if the SASL mechanism has
different "sub-mechanisms" (I'm unsure what to call that; eg. if we're
using SCRAM-SHA-1-PLUS and the information the server and client are
using different forms of channel binding) this could cause a failure at
the SASL level which XMPP wouldn't be aware of (and since it wouldn't
fall back we couldn't authenticate). However, this is very unlikely as
far as I can tell.
If this is the case, it seems like a SASL method pinning scheme should
be used (so after we have a successful login, then we refuse to do
anything else). This way, as long as the first connection works, we
mitigate the attack described above (just like HTTP TLS cert pinning, or
any other pinning scheme).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Standards