Channel Bindings for TLS 1.3
updates
- rfc-5801 — Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family
- rfc-5802 — Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
- rfc-5929 — Channel Bindings for TLS
- rfc-7677 — SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
Extracted elements (14)
The 'tls-unique' binding defined in RFC 5929 is susceptible to the triple handshake vulnerability without the extended master secret extension (RFC 7627). TLS 1.3 was not analyzed for channel binding safety during its core protocol work, so channel bindings for TLS 1.3 were deferred and are now defined here via 'tls-exporter'.
'tls-exporter' uses Exported Keying Material (EKM) rather than handshake messages because EKM is already widely exposed by TLS implementations, making the channel binding mechanism practical without requiring new implementation surface.
The 'tls-unique' channel binding type from RFC 5929 is not defined for TLS 1.3 and greater; 'tls-exporter' is its replacement for these versions. RFC 5929 is updated by this document to add 'tls-exporter' as an additional unique channel binding type.
This document updates RFCs 5801, 5802, and 7677 to use 'tls-exporter' as the default channel binding over TLS 1.3 and greater, replacing 'tls-unique'. The default channel binding for TLS 1.2 remains 'tls-unique'.
Implementations that support channel binding over TLS 1.3 MUST implement 'tls-exporter' as the mandatory-to-implement channel binding.
The derived EKM data MUST NOT be used for any purpose other than channel bindings as described in RFC 5056. Implementations MUST NOT use channel binding as a secret key to protect privileged information.
The 'tls-exporter' channel binding mechanism is defined only when the TLS handshake results in unique master secrets: for TLS prior to 1.3 this requires the extended master secret extension (RFC 7627), while TLS 1.3 always produces unique master secrets.
The 'tls-exporter' channel binding type uses Exported Keying Material (EKM) obtained via the TLS keying material exporter with label 'EXPORTER-Channel-Binding' (no terminating NUL), zero-length context, and a 32-byte output length.
IANA has registered the TLS exporter label 'EXPORTER-Channel-Binding' in the 'TLS Exporter Labels' registry. DTLS-OK is Y and Recommended is Y.
IANA has registered 'tls-exporter' in the 'Channel-Binding Types' registry as a unique channel binding type for TLS, with the EKM value from the current TLS connection as the binding data. Channel-binding is not secret; intended usage is COMMON.
Disclosure of the 'tls-exporter' channel binding data does not leak secret information about the TLS channel and does not affect the security of the TLS channel, because the EKM is derived specifically for this purpose.
The 'tls-exporter' binding provides only the weaker form of channel binding uniqueness (unique per TLS connection), not the stronger form (unique per upper-layer authentication protocol instance). Applications MUST NOT use the channel binding for more than one authentication mechanism instance on a given TLS connection, and MUST immediately close the TLS connection after the upper-layer protocol concludes.
When TLS renegotiation is enabled on a connection, the 'tls-exporter' channel binding type is not defined for that connection, and implementations MUST NOT support it. Users should upgrade to TLS 1.3 or later to take advantage of channel binding.
When using 'tls-exporter' with TLS versions below 1.3, extra precaution must be taken to ensure that the chosen cipher suites always result in unique master secrets, requiring the extended master secret extension (RFC 7627).