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 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.
- 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 web sites (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 identifier structure (described in the "Token Binding ID Format" section of this document). 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 clear text 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, 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 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:
- Best Practices OpenID Connect
- John Bradley
- OAuth 2.0 Token Binding
- RFC 8471
- Token Binding ID
- Token Binding over HTTP
- Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
- Web Blog_blogentry_150617_1
- Web Blog_blogentry_170816_1