We call an HTTP connection over TLS an HTTPS channel. When such an HTTPS channel uses Token Binding, the server can bind its cookies to the HTTPS channel by associating them with the client's public Token Binding key, and ensuring that the cookies are only ever used over HTTPS channels authenticated with that public (client) key.

This means that if such a channel-bound cookie is ever stolen off a client's machine, that cookie won't be able to authenticate an HTTP session to the server from other machines. This includes man-in-the-middle attackers that inject themselves into the connection between client and server, perhaps by tricking users into clicking through certificate-mismatch warnings: such a man-in-the-middle will have to generate its own HTTPS channel with the server, which won't match the channel that the cookie is bound it.

It's up to the server to decide whether to bind cookies to HTTPS channels. If the client doesn't support Token Binding, then the server will not channel-bind the cookie. If it does decide to channel-bind the cookie, it should associate the cookie with the client's public key. This is similar to RFC 5929, but instead of the client binding data to the server's public key, in this case the server would be binding data (the cookie) to the client's public key. The server can do this either by simply storing, in a backend database, the fact that a certain HTTP session is expected to be authenticated with a certain client public key, or it can use suitable cryptography to encode in the cookie itself which TLS client public key that cookie is bound to.

In the figure above, the server includes the client's public key into a cryptographically signed datastructure that also includes the authenticated user's id. When the server receives the cookie back from the client, it can verify that it indeed issued the cookie (by checking the signature on the cookie), and verify that the cookie was sent over the correct channel (by matching the Token Binding key with the key mentioned in the cookie).

• Using cookies in this manner means that web applications don't have to change much. They already associate a variety of information with cookies (the user they authenticate, expiration times, etc.) - the client's public Token Binding key is simply one more piece of information to associate with the cookie.
• Using Token Binding and then (perhaps) setting cookies that are (perhaps) channel-bound means that we can keep the existing modes of user interaction that we have today: A user can be logged out (cookie is not set), can be logged into one account (channel-bound cookies is associated with one user id), or can be logged into multiple accounts (channel-bound cookie is associated with multiple user ids). Transitioning between these states uses the same UI it does today (i.e. application-rendered HTML, not browser chrome), and the underlying mechanisms also remain the same (setting/removing cookies).
• The idea of binding cookies to an HTTPS channel says nothing about how the user authenticates. The user might authenticate with a username and password, or through more sophisticated means. As long as a cookie is set as a result, and that cookie is channel-bound, we gain the advantages of stronger authentication.
• Unlike traditional TLS client authentication, Token Binding with channel-bound cookies keeps the TLS terminators in a datacenter out of the trusted computing base. The TLS terminator simply sends information about the client's public Token Binding key and the cookie downstream, where the application logic makes sure that those two match. Just like in traditional cookie-based systems, the TLS terminator can't mint valid cookies, and hence can't impersonate users at will.
  
  
  
  

Q&A

• Can't I still steal the private key? Together with a stolen cookie, I can then impersonate the victim.
  It depends on the capabilities of the attacker, and the way the private key is stored. If the attacker is in the network, it can't get to the private key. If the attacker has infiltrated the client machine it might be able to get to the private key. What's important to remember is that this model of authentication allows for the credentials (client private Token Binding keys) to potentially move into well-protected storage, which is simply not possible for models that rely solely on bearer-tokens.
  
  
• What about TLS session state? Together with a stolen cookie, I can then impersonate the victim.
  Even if the private key is stored securely in a hardware module, malware might be able to extract certain TLS session state (e.g., the session master secret), and then resume that TLS session from a different location. Token Bindig requires the client to re-submit proof of possession of the private key upon such resumption, so possession of the TLS session state and the cookie is not enough to impersonate a client - the attacker also needs the private Token Binding key.
  
  
• Does this protect against man-in-the-middle attacks?
  If we assume that a cookie is bound to the correct channel (i.e., the man-in-the-middle wasn't present when the cookie was set), then binding cookies to TLS sessions will indeed protect against man-in-the-middle attackers that are in the network between client and server, even those in which the man-in-the-middle has compromised a Certification Authority and can impersonate the server to the client. Since the man-in-the-middle will have to use its own private key with the server, the cookie that it intercepts and forwards will fail to validate at the server side.