RFC 9266: Channel Bindings for TLS 1.3 support

Neustradamus commented 10 months ago

Dear @ongres team,

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?

https://datatracker.ietf.org/doc/html/rfc9266

Little details, to know easily:

tls-unique for TLS =< 1.2
tls-server-end-point
tls-exporter for TLS = 1.3

I think that you have seen the jabber.ru MITM and Channel Binding is the solution:

Thanks in advance.

Linked to:

jorsol commented 7 months ago

This library implements RFC 5802 and RFC 7677, this library doesn't implement external security layers such as that provided by TLS as can be read on the RFC for SCRAM:

For simplicity, this family of mechanisms does not presently include
negotiation of a security layer [RFC4422].  It is intended to be used
with an external security layer such as that provided by TLS or SSH,
with optional channel binding [RFC5056] to the external security
layer.

This library provides the building blocks to provide the SCRAM negotiation with servers, the RFC 5929 and RFC 9266 are out of the scope for this library.

Anyone who needs to extract channel-binding data that can later be used with SCRAM should check for the Bouncy Castle Crypto APIs.

Neustradamus commented 7 months ago

@jorsol: -PLUS variants are in RFC 5802 and RFC 7677 and more.

You can look here:

Can you reopen to support full RFCs?

jorsol commented 6 months ago

Hi @Neustradamus, I'm quoting the RFC 5802 section 4 linked:

The "-PLUS" suffix is used only when the server supports channel binding to the external channel. If the server supports channel binding, it will advertise both the "bare" and "plus" versions of whatever mechanisms it supports (e.g., if the server supports only SCRAM with SHA-1, then it will advertise support for both SCRAM-SHA-1 and SCRAM-SHA-1-PLUS). If the server does not support channel binding, then it will advertise only the "bare" version of the mechanism (e.g., only SCRAM-SHA-1). The "-PLUS" exists to allow negotiation of the use of channel binding.

The "-PLUS" exists to allow negotiation of the use of channel binding.

What this means is that the "-PLUS" suffix only signals that the mechanism requires channel binding during negotiation, it doesn't mention that all SCRAM libraries MUST implement channel binding, nor it is its job.

You can look at the RFC 5802 section 1:

For simplicity, this family of mechanisms does not presently include negotiation of a security layer [RFC4422]. It is intended to be used with an external security layer such as that provided by TLS or SSH, with optional channel binding [RFC5056] to the external security layer.

In other words, the family of SCRAM mechanisms DOES NOT include a security layer, that it is meant to be provided by an external security layer during negotiation, and an external library that can provide channel-binding data is the Bouncy Castle Crypto APIs, so this library MAY be used in conjunction with a library that implements channel-binding data to provide support for negotiation of the "-PLUS" mechanisms. The point here is that, this library is not a TLS library, it provides the building blocks to support SCRAM in a client/server, and an external helper that implements channel binding data extraction must be used.

I hope it is clear now.

Neustradamus commented 3 months ago

@jorsol: Good news in 3.0 (2024-04-03), a little part of Channel Binding has been added!

tls-server-end-point

Can you add now the tls-exporter support?

Thanks in advance.

Links:

jorsol commented 3 months ago

Hi @Neustradamus, sorry but no, there is no plan to support tls-exporter, this just implements RFC-5802, and is out of the scope to implement the security layer in this library.

If an external library implements tls-exporter and pass the channel binding data to this library, it should work.

Neustradamus commented 3 months ago

Important: The RFC9266 updates the RFC5802, etc.

ongres / scram

RFC 9266: Channel Bindings for TLS 1.3 support #19