RFC 9266: Channel Bindings for TLS 1.3 support

[Neustradamus]

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:

• https://notes.valdikss.org.ru/jabber.ru-mitm/
• https://snikket.org/blog/on-the-jabber-ru-mitm/
• https://www.devever.net/~hl/xmpp-incident
• https://blog.jmp.chat/b/certwatch

Thanks in advance.

Linked to:

• Implement Channel Binding #2
• Status for channel binding implementation #8
• SCRAM-SHA-224(-PLUS) + SCRAM-SHA-384(-PLUS) + SCRAM-SHA-512(-PLUS) supports #9
• RFC 9266: Channel Bindings for TLS 1.3 support #19
• SCRAM-SHA3-512(-PLUS) supports #23
• https://gitlab.com/ongresinc/scram/-/issues/15
• https://gitlab.com/ongresinc/scram/-/issues/17
• https://gitlab.com/ongresinc/scram/-/issues/18
• https://gitlab.com/ongresinc/scram/-/issues/19
• State of Play scram-sasl/info#1

[jorsol]

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]

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

You can look here:

• https://datatracker.ietf.org/doc/html/rfc5802#section-4
• https://datatracker.ietf.org/doc/html/rfc7677#section-3

Can you reopen to support full RFCs?

[jorsol]

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]

@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:

• https://github.com/search?q=repo%3Aongres%2Fscram+server-end-point&type=code
• https://github.com/search?q=repo%3Aongres%2Fscram+unique&type=code
• https://github.com/search?q=repo%3Aongres%2Fscram+exporter&type=code

[jorsol]

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]

Important: The RFC9266 updates the RFC5802, etc.