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
- Token Binding Type (
referred, more on this later)
- Token Binding ID (constructed from the negotiated key parameter and public key)
- 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
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
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.
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):
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,
HttpOnlycookies are an existing mitigation that is very effective in preventing cookies from being stolen through XSS.
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.
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.
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.