[Standards] Channel binding and token authentication

Dave Cridland dave at cridland.net
Tue Sep 27 10:35:01 UTC 2022

On Tue, 27 Sept 2022 at 09:59, Matthew Wild <mwild1 at gmail.com> wrote:

> On Tue, 27 Sep 2022, 09:46 Dave Cridland, <dave at cridland.net> wrote:
>>  Before committing to this, some observations:
>> - HT-*-NONE is needed for cases where there's no TLS at all. These are
>> rare, but there's legitimate cases where this is a sensible choice.
>> - Channel bindings can be used in cases where TLS is terminated in
>> advance by either:
>>   - Using TLS Endpoint channel bindings, which merely mean the XMPP
>> server needs to know the certificate which is to be used, or
>>   - Just going through the motions and blindly accepting the client's
>> channel binding choice, perhaps most sensibly by again using
>> tls-server-end-point
>> So I'm not *against* a HT-*-NONE, but I wonder if we should promote the
>> second bullet-point above the first?
> What would you propose exactly? That web clients just send some junk data
> and servers just accept it?
I'd not considered web clients - can they not obtain the server certificate
at all, even these days?

> I think any mode that blindly accepts in this way is worse than explicitly
> not using channel binding. With the planned token authentication protocols,
> a token is bound to a specific mechanism. That means if it is obtained with
> support for channel binding, it can only be used for authentication with
> that channel binding. If the server isn't always verifying the channel
> binding data, this undermines the security of this mechanism.
Yes, but:

- I'd assumed that all clients could use tls-server-end-point fairly
easily. If that's not the case for web clients, that's clearly a problem.
- As a client, it's impossible to tell whether a server is validating the
channel binding data or simply blindly accepting it anyway.
- Ideally, even with TLS termination before the XMPP server, the XMPP
server can discover or be configured with its TLS certificate so it can
verify that.
- 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.

> Unless I'm misunderstanding your proposal.

Well, my proposal is to think about it a bit before we commit, so maybe
you're unwittingly accepting it anyway?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20220927/e67771e1/attachment-0001.html>

More information about the Standards mailing list