[Standards] SASL Negotiation in XMPP Core introduces potential security concern

Thijs Alkemade thijs at xnyhps.nl
Mon Dec 8 21:10:05 UTC 2014

Hi Sam,

> On 8 dec. 2014, at 21:45, Sam Whited <sam at samwhited.com> wrote:
> 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.

Are you suggesting a scenario where the attacker can *insert* data that causes
DIGEST-MD5 to be used, but can not just *remove* the SCRAM-SHA-1 offer, only
leaving DIGEST-MD5? That sounds rather far-fetched to me. In practice, either
an attacker can make arbitrary modifications, or none at all (due to TLS).

> 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 point of using another mechanism is that you can't assume, in general,
that the server will only offer a mechanism when it supports it, because the
server does not yet know what user you will authenticate as. Maybe it has
SCRAM hashes for some users, but still wants to offer DIGEST-MD5 for the

Obviously a client shouldn't use a mechanism if it isn't secure, like PLAIN
without TLS, but falling back to a different mechanism doesn't change that.

> 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).

Pinning the mechanism used sounds like a good idea to me, though I would say
clients should refuse to use anything weaker.

Best regards,

More information about the Standards mailing list