[Standards] Channel binding and token authentication

Matthew Wild mwild1 at gmail.com
Tue Sep 27 11:58:34 UTC 2022

On Tue, 27 Sept 2022 at 12:31, Dave Cridland <dave at cridland.net> wrote:
> On Tue, 27 Sept 2022 at 11:51, Matthew Wild <mwild1 at gmail.com> wrote:
>> On Tue, 27 Sept 2022 at 11:36, Dave Cridland <dave at cridland.net> wrote:
>> > - I seem to remember that HT-* derives a lot of its replay protection from the channel binding, so we may want to have *something* there.
>> What is the attack scenario here? Someone compromised TLS?
> Any case where an attacker obtains the SASL exchange itself, or can replay it by some other means (I think TLS Early Data has some weaknesses here).
I'm not convinced this is very exploitable in any useful way, but I
think it might be enough to do something in some cases.

If an attacker is able to do this, they have either compromised your
client, your server or TLS. In all three cases, I think SASL is the
least of your worries.

I understand that in some protocols it is more common to send your
credentials to multiple different third parties, and ensuring that
authentication is bound to the entity you think you are authenticating
to fixes a large security hole.

Here in XMPP this is rarely the case - users generally don't send
credentials for service A to service B. And in this particular
instance, we're talking about short-lived tokens that are already
unique to the service you are connecting and authenticating to. There
is nobody else to replay to that would accept the token.

Looking beyond our own ecosystem, verified TLS and a session cookie
are considered adequate protection for practically all online services
today, from webmail to internet banking. They are susceptible to these
same "replay attacks". Despite this reality, I've had many discussions
with multiple XMPP community members in recent weeks, practically
claiming the absolute necessity of channel binding. I just don't see
it. I get that it's cool, and if you can do it, why not? But I don't
think it is preventing any practical attacks at all.

> But note that there's at least three different problems here:
> - Do we need to specify an HT-*-NONE (or at least, something similar)? The answer to this is "probably, yes".

Agreed. Previous discussions have included talk of stuffing tokens
into PLAIN (which of course I've seen in multiple real-world
deployments over the years). I'd rather not sanction that approach in
a new spec, but it's pretty much the leading alternative.

> - Can we minimize the need to use this, and encourage developers down a better path? I think we're in agreement that there's some good advice we can usefully give in some cases, but sadly not all.

If we specify it, yes, we can provide guidance on it. As you noted,
such guidance may already be warranted for tls-server-end-point

> - Does a simplistic HT-*-NONE have some issues we'll want to address carefully - possibly to the point that we actually need something different in this case? Again, "probably, yes".

I'm open to suggestions about what might be done differently, that
still fits into a single round-trip.

> It might be that HT-* in general has much higher security than HT-*-NONE, and it might be that we just have to live with that.

(...suppressing more questions about how much value channel binding
really brings to us...)

This is why I would of course specify that channel binding must be
used if supported, and that tokens must be pinned to the mechanism
they were initially created for.


More information about the Standards mailing list