LDAPWiki: Token Binding Protocol

Overview#

Token Binding Protocol (RFC 8471) is established by the user-agent generating a Private Key-Public Key pair (possibly within a Hardware Security Module (HSM), or a TPM) per target server, and proving possession of the private key on every TLS connection to the target server. Token Binding Protocol in the course of a TLS Handshake, a client and server can use the Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation (RFC 8472) to negotiate the Token Binding Protocol version and the parameters (signature algorithm, length) of the Token Binding key. This negotiation does not require additional Round-trips.Token Binding Protocol enables client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to Cryptographically bind Security Tokens to the TLS layer, preventing token export and Replay attacks. Token Binding Protocol uses Application-Layer Protocol Negotiation (ALPN) protocol IDs to negotiate the use of Token Binding Protocol, in addition to the actual application protocol.

Unlike TLS client certificates, the use of Token Binding keys does not require any interaction with the user. This is because:[1]

it is always clear which Token Binding key to use (so the user doesn't have to be consulted), and
the browser always uses a different key with different Websites (so the user doesn't need to give consent to use a Token Binding key).

The Proof-of-Possession involves signing the exported keying material RFC 5705 for the TLS connection with the Private Key. The corresponding Public Key is included in the Token Binding ID structure (described in the "Token Binding ID Format" section of this RFC 8471). Token Bindings are long-lived, i.e. they encompass multiple TLS connections and TLS sessions between a given client and server. To protect privacy, Token Binding IDs are NEVER transmitted in Cleartext and can be reset by the user at any time, e.g. when clearing browser cookies.

When issuing a Security Token to a client that supports Token Binding Protocol, a server includes the client's Token Binding ID in the token. Later on, when a client presents a security token containing a Token Binding ID, the server makes sure the ID in the token matches the ID of the Token Binding established with the client. In the case of a mismatch, the server discards the token.

Servers generate various Security Tokens (e.g. HTTP cookies, OAuth tokens) for applications to access Protected Resources. Any party in possession of such token gains access to the Protected Resources. Attackers export Bearer Tokens from the user's machine, present them to the servers, and impersonate authenticated users. The idea of Token Binding Protocol is to prevent such attacks by cryptographically binding Security Tokens to the TLS layer.

In order to successfully export and Replay attack a bound security token, the attacker needs to also be able to export the client's Private Key, which is hard to do in the case of the key generated in a secure hardware module.

More Information#

There might be more information for this subject on one of the following:

[#1] - Token Binding - based on information obtained 2017-03-15