Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
Extracted elements (18)
The extension is scoped to TLS 1.2 and earlier because it adds Token Binding negotiation without extra round trips in those versions. Negotiation for TLS 1.3 is addressed by a separate draft (TOKENBIND-TLS13) and is explicitly out of scope here.
The two-octet TB_ProtocolVersion encoding (major + minor uint8) is explicitly for human convenience only and carries no protocol significance; implementers should not ascribe semantic weight to the major/minor split.
If the client does not support the Token Binding protocol version selected by the server, the connection proceeds without Token Binding. There is no requirement for the client to support any version other than the one it advertised.
If the client supports multiple Token Binding protocol versions, it SHOULD indicate the latest supported version (highest TB_ProtocolVersion.major and .minor) in the TokenBindingParameters.token_binding_version field of the ClientHello extension.
If the server supports none of the key parameters advertised by the client, it MUST NOT include the 'token_binding' extension in the ServerHello.
Once token_binding is included in ServerHello and the client supports the selected version, the version and key parameters SHALL be definitive for the TLS connection. The client MUST use the negotiated key parameters in the 'provided_token_binding' as described in RFC 8471.
The client receiving the 'token_binding' extension MUST terminate the handshake with a fatal 'unsupported_extension' alert if: the client did not send the extension; the returned version is higher than what the client advertised; key_parameters_list has more than one entry; it contains an unadvertised identifier; or TLS 1.2/older is used without extended master secret and renegotiation indication.
The server MUST only select a Token Binding key parameters identifier that the client offered, and SHOULD select the most highly preferred identifier it supports that was also advertised by the client.
Token Binding protocol version and key parameters MUST be negotiated for each TLS connection — in both full TLS handshakes establishing a new session and in abbreviated handshakes resuming an existing session.
The server includes the 'token_binding' extension in ServerHello only if: (1) it supports the offered version or a lower one, (2) it finds acceptable key parameters in the client's list, and (3) it is also negotiating the extended master secret (RFC 7627) and renegotiation indication (RFC 5746) extensions when TLS 1.2 or older is used.
The ServerHello token_binding_version is the lower of the version offered by the client and the highest version the server supports. The key_parameters_list in the ServerHello contains exactly one identifier selected from the client's advertised list.
The 'token_binding' TLS extension (ExtensionType value 24) is used by client and server to negotiate the Token Binding protocol version and key parameters within the TLS handshake, without introducing additional network round trips in TLS 1.2 and earlier.
TokenBindingKeyParameters is an enum with defined values: rsa2048_pkcs1.5(0), rsa2048_pss(1), ecdsap256(2). The 'Token Binding Key Parameters' IANA registry (established by RFC 8471) governs these identifiers.
This document updates the IANA 'TLS ExtensionType Values' registry, registering 'token_binding' with value 24, Recommended: Yes. It uses but does not add entries to the 'Token Binding Key Parameters' registry created by RFC 8471.
Downgrade attacks against Token Binding negotiation are mitigated by TLS itself: because TLS detects modification of handshake messages by active attackers, an attacker cannot remove or modify the 'token_binding' extension without breaking the TLS handshake. The signature algorithm and key length used in 'provided_token_binding' MUST match the negotiated parameters.
The triple handshake attack (TRIPLE-HS) affects TLS 1.2 and older by allowing an attacker to synchronize keying material between connections and replay bound tokens. Therefore, Token Binding MUST NOT be negotiated with these TLS versions unless both the extended master secret (RFC 7627) and renegotiation indication (RFC 5746) extensions are also negotiated.
TB_ProtocolVersion is encoded as two octets (uint8 major, uint8 minor). The document notes this two-octet representation is for human convenience only and carries no protocol significance.
The ClientHello 'token_binding' extension_data carries a TokenBindingParameters struct containing a TB_ProtocolVersion (two uint8 fields: major and minor) and a key_parameters_list of 1 to 255 TokenBindingKeyParameters identifiers in descending preference order.