Token Binding is a protocol that has been a subject of some debate recently due to Chrome's Intent to Remove message for the feature.

We shall take a look at how Token Binding works as well as the arguments for and against the protocol.

What problem does Token Binding aim to solve?

Web applications make heavy use of bearer tokens for security. Bearer tokens effectively allows the party in posession of the token access to a protected resource without any further questions. Examples of commonly used bearer tokens are session cookies and OAuth tokens.

These bearer tokens are a juicy target for an attacker as they can grant access to sensitive resources or allow impersonation of an authenticated user. For example, session cookies are a common target for XSS attacks.

Token Binding aims to mitigate the effectiveness of such attacks by binding security tokens to a cryptographic key.

A brief technical explanation of Token Binding

The first step of Token Binding is the Token Binding Negotiation that happens during the TLS handshake. The client uses the token_binding TLS extension to send the highest supported Token Binding protocol version as well as a list of supported key parameters in the ClientHello phase. In the typical TLS fashion, the client indicates what it can support but the server has the final say on which Token Binding version and key paremeter will be used. If the client does not support the Token Binding protocol version selected by the server, the TLS connection will continue without Token Binding.

What happens after the TLS connection is established is application protocol specific. In all cases, the client will send a Token Binding message that proves posession of a private key. In the case of HTTP, this Token Binding message is sent as the Sec-Token-Binding HTTP header. This header contains the:

1. Token Binding Type (provided / referred, more on this later)
2. Token Binding ID (constructed from the negotiated key parameter and public key)
3. Signature computed over the type, negotiated key material and the Exported Keying Material (EKM)

The EKM is obtained with the Keying Material Exporters feature of TLS described in [[RFC5705]]. This is essentially random data unique to each TLS session. As the signature is computed over the the EKM, the Token Binding message cannot be reused in another TLS session, preventing replay attacks.

Once the Token Binding message is sent by the client, the server can bind tokens to the Token Binding ID, usually by embedding the Token Binding ID within the token. This prevents the token from being used without proving posession of the private key with a valid Token Binding message for the TLS session.

The key pairs used for Token Binding are generated by the client. In the case of a web browser, a Token Binding key pair is scoped no wider than a registered domain. This puts the scope of a Token Binding key pair at the same level of a cookie. However, this does not work some use cases. For example, some federated web applications use an OpenID token from a third party service for authentication. This is where the Token Binding Type comes into play. The normal Token Binding flow uses the provided Token Binding Type. This is "used to establish a Token Binding when connecting to a server". The referred type is "used when requesting tokens that are intended to be presented to a different server".

In a federated protocol, a party known as the Identity Provider issues a token to the client which then uses it to authenticate itself with a server known as the Relying Party. As the issued token is consumed by the Relying Party, the Identity Provider should bind the token to the Token Binding ID of the TLS connection between the client and the Relying Party, which shall henceforth be referred to as binding A. This will mean that the Identity Provider needs to have knowledge of binding A. This is achieved by having the Relying Party set the Include-Referred-Token-Binding-ID: true header in the HTTP response to the client when redirecting to the Identity Provider. Upon seeing this header, the client will send binding A in the Sec-Token-Binding header to the Identity Provider.

This is a very brief overview of how Token Binding works. For more information, the Identiverse talk on Token Binding by Brian Campbell is a good watch.

Browser Support

When this blog post was written, browser support for Token Binding is fairly limited. The only popular browser with public support for the feature is Edge. Chrome has support hidden behind a feature flag while Firefox and Safari did not indicate any intention to implement the feature.

Against Token Binding

The main argument I have seen against Token Binding is that it is a very invasive change that does not actually solve a real problem (at least in the context of a web browser). This argument boils down to the fact that there are very few attack vectors which allow for cookie theft without also giving you access to the token binding key and that do not already have existing mitigations.

Let's take a look at a few potential attack vectors (in no particular order and definitely not comprehensive):

1. Cross Site Scripting (XSS): XSS is a potential vector for cookie theft that will not give an attacker access to the token binding key. However, HttpOnly cookies are an existing mitigation that is very effective in preventing cookies from being stolen through XSS.

2. Client-side Malware: Client-side malware will have full access to the browser's assets and can steal the generated token binding key along with the cookies.

3. Subdomain Takeover: This is a more interesting attack vector. Subdomain takeover can have large impact on domains that use widely scoped cookies such as Uber. Token Binding can mitigate this as compromising a subdomain will not result in a compromise of the Token Binding key which is stored on the client. However, there are two issues that undermine the effectiveness of Token Binding in this case. Firstly, it can be argued that a more appropriate defense would be to scope cookies more narrowly as widely scoped cookies open up a very large attack surface. Secondly, an attacker that took over a subdomain can already serve malicious JavaScript that executes the attack instead of stealing cookies. This is neatly described by Tavis Ormandy as "why not just use the vector you used to get the cookie in the first place".

4. MITM Attacks: Man-in-the-middle attacks can be used to steal cookies but will not provide access to the token binding key. However, MITM can be effectively negated by proper implementations of TLS which is already a requirement for Token Binding to work in the first place.

The items in this list are an attempt to summarize the discussion from a very informative Twitter thread so big shoutout to everyone involved.

Token Binding also presents a significant change in the debuggability of the Web. At the very least, it will break the HTTP proxies like Fiddler or Burp Suite as well as the ability to use an existing cookie with tools like curl. There are also unresolved questions about how Token Binding will interact with browser extensions. Ryan Sleevi has an excellent summary of the concerns on a blink-dev post from 2016.

For Token Binding

Most of the interest around Token Binding has come from groups working on authentication and Identity and Access Management (IAM) standards. For example, there have been draft specifications for OpenID Connect and OAuth to make use of Token Binding. Microsoft has also expressed strong interest in supporting Token Binding, especially for the Azure AD use case where AD tokens can be bound to a device using Token Binding. This is especially effective as the token binding key can be stored in an isolated VM that cannot be accessed from the host machine and has the potential to mitigate mimikatz-like attacks.

Conclusion (?)

Both sides have the debate have very valid points. It is likely that Token Binding will not provide significant advantages for the Web use case that the Chrome team is concerned with and is likely to require significant engineering and maintenance efforts on their part. However, Token Binding has a set of useful security properties that is difficult to find elsewhere. Chrome dropping support for Token Binding has a high chance of killing momentum around the protocol. Even worse, it might lead to a regression to the bad old days where certain browsers (Edge is the only one that currently supports Token Binding) are required for certain tasks. There is a not insignificant chance of this happening as the security properties provided by Token Binding are very useful for large enterprises.

I am currently unsure about which side of the debate I agree with. However, it would be interesting to see what the Chrome developers end up doing.