Hi Sam, > On 8 dec. 2014, at 21:45, Sam Whited <[email protected]> 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 others. 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, Thijs
