The Token Binding Protocol Version 1.0
Extracted elements (28)
The Token Binding protocol intentionally does not define how security tokens are bound to the TLS layer (e.g., embedding Token Binding ID in the token vs. maintaining a mapping database), leaving this application-specific. This keeps the core protocol narrowly scoped while allowing flexibility for diverse application contexts.
Token Binding IDs are never conveyed over insecure connections to protect privacy, even though the bindings are long-lived across multiple TLS sessions. The design allows users to reset their Token Binding ID at any time (e.g., by clearing browser cookies), balancing the security benefit of persistent binding against user privacy control.
This document addresses Token Binding with TLS 1.2 (RFC 5246). Token Binding for TLS 1.3 is addressed separately in draft-ietf-tokbind-tls13. Specifications using Token Binding with application protocols such as HTTP (RFC 8473) MAY prohibit TLS renegotiation in combination with Token Binding to avoid synchronization complexity.
For provided_token_binding, the server MUST verify that the signature algorithm (including elliptic curve for ECDSA) and key length in the Token Binding message match those negotiated with the client; in case of mismatch the server MUST reject the binding.
If the Token Binding message does not contain at least one TokenBinding structure, or if any signature is invalid, the server MUST reject the binding. If a Token Binding is rejected, any associated bound tokens presented on the current TLS connection MUST also be rejected.
If the token is bound and a Token Binding has not been established for the client connection, the server MUST reject the token. If the Token Binding ID for the token does not match the Token Binding ID established for the client connection, the server MUST reject the token.
The client MUST generate and store Token Binding keys in a secure manner that prevents key export. The scope of the Token Binding keys MUST NOT be broader than the scope of the tokens, as defined by the application protocol, to prevent cooperating servers from linking user identities.
The Token Binding message MUST be sent if the client and server successfully negotiated its use, MUST NOT be sent otherwise, and MUST be sent in the client's first application protocol message.
The Token Binding protocol MUST be negotiated using a mechanism that prevents downgrade attacks. The signature algorithm and key length used in the provided_token_binding MUST match the negotiated parameters.
To mitigate the triple handshake vulnerability in TLS 1.2 and older, the server MUST NOT negotiate Token Binding with these TLS versions unless the server also negotiates the extended master secret TLS extension (RFC 7627) and the renegotiation indication TLS extension (RFC 5746).
TokenBinding.signature MUST be a signature of the EKM value derived from the TLS master secret that produced the session keys encrypting the TLS application_data record(s) containing the TokenBinding. This makes replay of bound tokens within renegotiated TLS sessions detectable.
When operating in a special privacy mode (e.g., private browsing), applications SHOULD use newly generated Token Binding keys and delete them when exiting this mode; otherwise, they SHOULD NOT negotiate Token Binding at all.
When rsa2048_pss is used, MGF1 with SHA256 MUST be used as the mask generation function, and the salt length MUST equal 32 bytes.
A server can use tokens and Token Binding IDs to track clients. Client applications that automatically limit the lifetime or scope of tokens to maintain user privacy SHOULD apply the same validity time and scope limits to Token Binding keys.
Token Binding uses persistent, long-lived Token Binding IDs that are never transmitted in clear text and can be reset by the user at any time (e.g., when clearing browser cookies). The scope of Token Binding keys MUST NOT be broader than the scope of the tokens to prevent cooperating servers from linking user identities.
The referred_token_binding is constructed by setting tokenbinding_type to referred_token_binding, tokenbindingid to the Token Binding ID used with the Relying Party, and computing the signature using the EKM of the TLS connection to the Identity Provider and the Token Binding key established with the Relying Party. This allows three-party Token Binding between User Agent, Identity Provider, and Relying Party.
The signature in TokenBinding is computed over the concatenation of TokenBindingType, TokenBindingKeyParameters, and the EKM value from the current TLS connection. The EKM is exported using RFC 5705 with label 'EXPORTER-Token-Binding' (no NUL terminator), no application context, and length 32 bytes.
The Token Binding ID is derived from the TokenBinding structure by discarding the type, signature, and extensions, leaving key_parameters, key_length, and the public key. For RSA, the modulus and exponent are big-endian with leading zeros omitted; for ecdsap256, the uncompressed X and Y coordinates are 32-byte big-endian values with leading zeros preserved.
The Token Binding protocol consists of one client-to-server message proving possession of one or more client-generated asymmetric private keys. The message is sent with application protocol data over TLS and is only sent when Token Binding negotiation has succeeded. Long-lived Token Binding IDs span multiple TLS sessions and connections.
Two Token Binding types are defined: provided_token_binding (value 0), used when connecting to a server, and referred_token_binding (value 1), used when requesting tokens intended for presentation to a different server. Implementations MUST ignore any unknown Token Binding types.
Establishes the 'Token Binding Protocol' IANA registry with three subregistries: 'Token Binding Key Parameters' (initial values: 0=rsa2048_pkcs1.5, 1=rsa2048_pss, 2=ecdsap256), 'Token Binding Types' (0=provided_token_binding, 1=referred_token_binding), and 'Token Binding Extensions' (no initial registrations). All operate under Specification Required policy.
Registers the TLS exporter label 'EXPORTER-Token-Binding' in the 'TLS Exporter Labels' registry with DTLS-OK: Y and Recommended: Y.
Bound tokens can be replayed by malware present in User Agents, which may be undetectable to a server. However, to export bound tokens to other machines, attackers must also export the corresponding Token Binding private keys. Token Binding private keys are high-value assets and SHOULD be strongly protected, ideally generated in a hardware security module that prevents key export.
For single sign-on scenarios where applications share tokens, those applications will also need to share Token Binding keys. Care must be taken to restrict Token Binding key sharing to exactly the same group of applications that shares tokens.
The bound token must be integrity-protected so that an attacker cannot remove the binding or substitute a Token Binding ID without detection. The Token Binding protocol does not prevent cooperating clients from sharing a bound token with its corresponding private key.
The triple handshake attack (TRIPLE-HS) is a known vulnerability in TLS 1.2 and older that allows an attacker to synchronize keying material between TLS connections, enabling successful replay of bound tokens. Token Binding MUST NOT be negotiated with these versions without the extended master secret and renegotiation indication extensions.
The TokenBindingID structure encodes key_parameters (TokenBindingKeyParameters enum), key_length (uint16 in bytes), and the TokenBindingPublicKey (either RSAPublicKey with modulus<1..2^16-1> and publicexponent<1..2^8-1>, or TB_ECPoint with point<1..2^8-1> for ecdsap256).
The TokenBindingMessage structure contains a series of TokenBinding structures encoded using the TLS presentation language: `TokenBinding tokenbindings<132..2^16-1>`. Each TokenBinding includes tokenbinding_type (1 byte), tokenbindingid, signature<64..2^16-1>, and extensions<0..2^16-1>.