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). Thoughts? Best, Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com
signature.asc
Description: OpenPGP digital signature
