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

Sam Whited sam at samwhited.com
Fri Dec 12 19:09:17 UTC 2014



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141212/fd14cdbe/attachment.sig>


More information about the Standards mailing list