Token Binding over HTTP
Extracted elements (25)
Clients use different Token Binding key pairs for different servers (rather than a single global key pair) to prevent Token Binding IDs from becoming universal cross-server tracking identifiers, preserving the user's privacy across distinct web origins.
The 'Sec-' prefix was chosen for the Sec-Token-Binding header field name specifically because the Fetch specification designates 'Sec-' prefixed names as 'forbidden header names', preventing web content (via DOM APIs or JavaScript) from reading or setting the header. This provides the integrity protection required to prevent cross-origin attacks.
Token Binding over HTTP is only defined when HTTP is layered over TLS (i.e., HTTPS per RFC 2818). TokenBindingMessages are not defined for plain HTTP. This document addresses TLS 1.2; Token Binding for TLS 1.3 is addressed in a separate draft (draft-ietf-tokbind-tls13).
If a TokenBindingMessage fails server validation and a Token Binding is rejected, any associated bound tokens MUST also be rejected. HTTP requests containing invalid tokens MUST be rejected; the server MAY return 400, use an application-specific invalid-token response, or terminate the connection.
If the Include-Referred-Token-Binding-ID header is received in response to a request that did not include the Sec-Token-Binding header, the client MUST ignore the Include-Referred-Token-Binding-ID header. For any HTTP status code other than a redirect (300–399), the client MUST also ignore this header.
If the server receives more than one Sec-Token-Binding header field in an HTTP request, it MUST reject the message with HTTP status code 400 (Bad Request).
In HTTP/2, the client SHOULD use header compression (HPACK, RFC 7541) to avoid the overhead of repeating the same Sec-Token-Binding header field in subsequent requests.
Once Token Binding is negotiated, clients MUST include a Sec-Token-Binding header field in every HTTP request and MUST include only one such header field per request. The header field MUST NOT be included in HTTP responses and MUST NOT be used in HTTP trailers.
The client MUST use the key parameters negotiated with the Token Consumer in the referred_token_binding TokenBinding, even if those parameters differ from those negotiated with the Token Provider (the server receiving the message).
The referred_token_binding TokenBinding in the redirect request to the Token Provider MUST be signed with the Token Binding private key used by the client for connections between itself and the Token Consumer (the server that issued the Include-Referred-Token-Binding-ID response). The TokenBindingMessage MUST also contain a provided_token_binding signed with the key used with the Token Provider.
The scope of Token Binding key pairs generated by web browsers for binding HTTP cookies MUST be no wider than the granularity of a registered domain (eTLD+1). User Agents SHOULD use an up-to-date public suffix list such as Mozilla's PSL.
The TokenBindingMessage MUST contain exactly one TokenBinding structure with TokenBindingType of provided_token_binding, signed with the Token Binding private key the client uses for connections to the server receiving the request.
Token Binding implementations MUST only convey Token Binding IDs to servers if signaled to do so by the application associated with the Token Binding ID. Signaling mechanisms other than Include-Referred-Token-Binding-ID are possible but outside the scope of this specification.
Token Providers SHOULD support all Token Binding key parameters specified in RFC 8471. If a Token Provider does not support the key parameters in the referred_token_binding, it MUST NOT issue a bound token.
When performing Token Binding over HTTP/1.1 with TLS renegotiation, renegotiation MUST only occur between a client HTTP request and the server response, the client MUST NOT send pipelined requests, and the client MUST NOT initiate renegotiation.
Clients use different Token Binding key pairs for different servers to prevent Token Binding from becoming a cross-site tracking tool. The scope of key pairs MUST be no wider than eTLD+1 for cookie-binding use cases, matching the cookie scoping rules in RFC 6265.
Endpoints that receive Token Binding IDs for TLS connections other than their own (e.g., a Token Provider receiving a Referred Token Binding ID) gain correlation handles for those other connections. A privacy analysis of such correlations should be performed before enabling referred Token Binding in application designs.
Token Binding key pairs have no expiration time, allowing servers to track users long-term like persistent cookies. HTTPS User Agents SHOULD provide a UI for discarding key pairs, and MUST discard Token Binding key pairs generated during a private browsing session after that session ends.
The Include-Referred-Token-Binding-ID HTTP response header field signals to a client that it should reveal, to a Token Provider, the Token Binding ID used between itself and the Token Consumer. Its only defined value is 'true' (case insensitive), and it is meaningful only when the HTTP status code is a redirect (300–399).
The Sec-Token-Binding HTTP request header field carries a base64url-encoded TokenBindingMessage. Its ABNF is: Sec-Token-Binding = EncodedTokenBindingMessage. It is defined for HTTP/1.1 and HTTP/2 and is only meaningful over HTTPS.
This document registers two permanent HTTP header field names with IANA: 'Sec-Token-Binding' (request header conveying the EncodedTokenBindingMessage) and 'Include-Referred-Token-Binding-ID' (response header signaling federation redirect behavior), both with status 'standard'.
In federated sign-on, both the proof of the provided Token Binding private key and the proof of the referred Token Binding private key are necessary. Without the provided-key proof, a man-in-the-middle between the client and the Token Provider can substitute its own Token Binding ID; without the referred-key proof, a MITM between the client and the Token Consumer can substitute its own Token Binding ID as the Referred ID.
The integrity of the Sec-Token-Binding header must be protected: one eTLD+1 must not be able to set the Sec-Token-Binding header used by a User Agent with another eTLD+1. The 'Sec-' prefix marks the header as a 'forbidden header name' per the Fetch specification, preventing DOM APIs from setting it.
Token Binding private keys are high-value assets because an attacker who obtains one can craft valid Sec-Token-Binding headers and impersonate the client even against servers that use Token Binding to protect cookies or OAuth tokens. Private keys SHOULD be strongly protected, ideally generated in a hardware security module that prevents key export.
EncodedTokenBindingMessage is a base64url encoding (URL- and filename-safe character set per RFC 4648 Section 5) of a single TokenBindingMessage, with all trailing padding characters ('=') omitted and no line breaks or whitespace.