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

Dave Cridland dave at cridland.net
Sat Dec 13 12:49:15 UTC 2014

On 12 Dec 2014 19:10, "Sam Whited" <sam at samwhited.com> wrote:
> On 12/08/2014 04:10 PM, Thijs Alkemade wrote:
> > Are you suggesting a scenario where the attacker can *insert* data that
> > DIGEST-MD5 to be used, but can not just *remove* the SCRAM-SHA-1 offer,
> > leaving DIGEST-MD5? That sounds rather far-fetched to me. In practice,
> > an attacker can make arbitrary modifications, or none at all (due to
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141213/df0247dc/attachment.html>

More information about the Standards mailing list