Re: [Standards] SASL Negotiation in XMPP Core introduces potential security concern
On 12/13/2014 07:49 AM, Dave Cridland wrote: > What do you think is not covered in the security considerations section of > RFC 4422, in particular section 6.1.2? You're exactly right of course. Thanks; that's exactly what I was looking for. Knew I must be missing something. Looks like it's covered afterall. Thanks, Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com signature.asc Description: OpenPGP digital signature
Re: [Standards] SASL Negotiation in XMPP Core introduces potential security concern
On 12 Dec 2014 19:10, "Sam Whited" wrote: > > > > On 12/08/2014 04:10 PM, Thijs Alkemade wrote: > > 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). > > Doesn't matter; let's assume they can arbitrarily modify things. If they > can, this means that they can force the user to fallback to a less > secure auth mechanism as the RFC is currently worded. However, if > fallback weren't an issue, all they could do (to a client who supports a > more secure mechanism) is cause a DoS. > I don't think that assertion is true. If a third party can arbitrarily change data on the wire, they can do pretty much anything, including session hijack. > > Pinning the mechanism used sounds like a good idea to me, though I would say > > clients should refuse to use anything weaker. > > Yah, agreed; this is what we do in Conversations (client for Android). > > > So I'm not missing something; this sounds like a potential security > concern in the RFC to me. Maybe something that should be considered for > change? Or maybe an best practices XEP that outlines when fallback > should happen and when it shouldn't to mitigate these kinds of downgrade > attacks would be more appropriate (and easier as it's not a full RFC)? > What do you think is not covered in the security considerations section of RFC 4422, in particular section 6.1.2? > Thanks, > Sam > > -- > Sam Whited > pub 4096R/54083AE104EA7AD3 > https://blog.samwhited.com >
Re: [Standards] SASL Negotiation in XMPP Core introduces potential security concern
On 12/08/2014 04:10 PM, Thijs Alkemade wrote: > 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). Doesn't matter; let's assume they can arbitrarily modify things. If they can, this means that they can force the user to fallback to a less secure auth mechanism as the RFC is currently worded. However, if fallback weren't an issue, all they could do (to a client who supports a more secure mechanism) is cause a DoS. > Pinning the mechanism used sounds like a good idea to me, though I would say > clients should refuse to use anything weaker. Yah, agreed; this is what we do in Conversations (client for Android). So I'm not missing something; this sounds like a potential security concern in the RFC to me. Maybe something that should be considered for change? Or maybe an best practices XEP that outlines when fallback should happen and when it shouldn't to mitigate these kinds of downgrade attacks would be more appropriate (and easier as it's not a full RFC)? Thanks, Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com signature.asc Description: OpenPGP digital signature
Re: [Standards] SASL Negotiation in XMPP Core introduces potential security concern
Hi Sam, > On 8 dec. 2014, at 21:45, Sam Whited 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
[Standards] SASL Negotiation in XMPP Core introduces potential security concern
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
