[Standards] Channel binding and token authentication
dave at cridland.net
Tue Sep 27 12:21:35 UTC 2022
On Tue, 27 Sept 2022 at 12:59, Matthew Wild <mwild1 at gmail.com> wrote:
> 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
> 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.
All of which I broadly agree with to various degrees, however that's not
the attack here - the attack is that a passive observer can replay TLS 1.3
Early Data, and if a client developer (fairly sensibly) chooses to send a
SASL exchange there, that might get to the point of an authenticated
connection. It's one the attacker cannot control, mind - confidentiality
has still been assured - but if a client developer were to use TLS Early
Data to send both the SASL exchange *and* a message or something, then that
might be a problem.
In other protocols also using SASL, though, it might be a worse problem -
in principle some uses of Submission (ie, SMTP for sending mails) might be
susceptible here, and there could be some other issues even on broadly
readonly protocols like IMAP.
In any case, given the focus for HT-* is 0-RTT startup, it makes a lot of
sense to try to ensure it has some protection for replay - saying "Well, if
you want to save on round-trips, you can use HT-*-NONE, but then you'll
need to disable TLS Early Data and spend an additional RTT there" doesn't
seem like an ideal situation.
Meanwhile in the HTTP world, verified TLS and a session cookie is *very*
susceptible to replay attacks based on TLS 1.3 Early Data, and it's often
blocked as a result (for example, Cloudflare reject it for anything except
"plain" GET requests, and Go doesn't even implement it, and ... ). Given it
weakens forward secrecy for the Early Data, too, there's not just replay
issues to consider anyway.
Anyway, something to worry over when looking at HT-*-NONE - and to be
explicit, my knowledge here is getting very sketchy, so I don't even know
if HT-* with (say) TLS Exporter channel bindings is any better.
> > 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.
Right. I'm not saying "Don't!", I'm saying it might not be as simple to do
as "Just don't do channel binding".
> > 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...)
Again, I'm not concerned here with the value that channel binding in
general brings - for all I think it's a nice to have - but for the value
that the additional data brings to replay attack mitigation.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards