Token binding gains momentum, but is everyone onboard?

Token Binding is currently an Internet-Draft but it is well on its way to be ratified by the Internet Engineering Task Force (IETF).   Like most specifications they first appear as drafts, which are then reviewed in the industry, perhaps prototypes are built and in some cases working solutions are often developed to prove or test the specification. Token Binding was no different here.  The Token Binding Protocol Version 1.0 specification goes back to 2014 as part of  draft-popov-token-binding-00 and over the past 4 years has seen numerous revisions.  Some vendors have even incorporated the “unofficial” specification in their own products: Google as part of the Chrome browser and Microsoft as part of Windows 10 1703 and the Edge browser.

But, is everyone still onbaord?

In a recent post by Google’s Chrome team they announced their Intenet to remove: Token Binding from Chrome.  This surprised many by this move – after all the specification is still in draft. But, before we dig into this let us first understand why we are even talking about Token Binding.

Why do we need Token Binding?

When we authenticate with a service we are typically issued with some form of “Bearer Token”.  It’s a security token that is issued by a service during a login attempt that can be used to access associated resources of the service.  The basic operating principle for Bearer Tokens is that any party in possession of the token can gain access to the protected resource(s).  This all seems fine but, what if a bad actor came along and exported the Bearer Token from a given application or device, and presented it to the service, impersonating the authenticated user? – well, they would have access to the service.  There is no other proof needed with Bearer Tokens other than having one.  And there lies the problem.

What is Token Binding?

The vast majority of online Bearer Tokens are OAuth but, we also have SAML and OpenID Connect too.  But, what about those things that typically are used by browsers to maintain and establish a session online?  Yes, that’s right – Cookies.  Cookies are also a type of Bearer token.  Of course, a lot has been done to increase the security and theft of Cookies but, there are still opportunities to steel them and this is where Token Binding enters. Token Binding does not prevent theft of the token but, rather if it were to be stolen, or hijacked they cannot be replayed or used as part of a lateral move.   This is achieved by adding a confirmation mechanism to the process that verifies the Token Binding ID of the security token presented at the time of use with the one that was issued at the time the Token Binding was established with the client.  This process is known as a  “proof of possession”.

How does Token binding work?

Let’s look at what the Internet-Draft has to say:

A Token Binding is established by a user agent generating a private-public key pair (possibly within a secure hardware module, such as a Trusted Platform Module) per target server, providing the public key to the server, and proving possession of the corresponding private key, on every TLS connection to the server.  The proof of possession involves signing the exported keying material (EKM) [RFC5705] from the TLS connection with the private key

Clear, right? It’s OK I had to read twice too and went on to read the entire specification before it really sunk in.  But, let’s try and unpack this a little.

It begins with a client or a browser (described as a user agent above) generating a public-private key pair for each server that it must connect.  Ideally, this would be done using a secure hardware module, an example of this is the Trusted Platform module (TPM), which many Corporate and Government agencies specify must be in place for both server and client hardware they use.  The actual use of Token Binding is negotiated during the TLS handshake with the server using the TLS extension.  At this point the client or browser will share the public key it generated with the server and prove it is in possession of the private key on every TLS connection it makes to the server.  The process or mechanism to prove itself is by signing the TLS Exported Key Material (EKM).  You can think of the EKM as a cryptographically unique reference for the given TLS session, which is signed with the private key.  This data is sent with every request to the server as a http header, which in turn is used to prove possession of the corresponding private key of the given public-private key pair. The Cookies and other tokens issued by the server can now be bound to this key and thus making it difficult for an attacker to use them.

Support for Token Binding

By this stage, if you are still reading then you must have a least a high-level appreciation of what Token Binding is all about.  But, as I said in my open remarks at least one of the vendors involved with the Token Binding specification is beginning to waiver a little with the announcement of their Intent to remove support for Token Binding in Chrome. This came as a big shock to many as the browser is one of the major user agents where the implementation of Token Binding makes so much sense.  It’s the key entry point for hundreds if not thousands of services where security tokens and Cookies are a part of transactions every hour, every minute and every second of our day.  So, why remove it?

Well, the Google representative (Nick Harper) behind the announcement claims that very few people had enabled the feature.  OK but, the specification is still in draft and this is not something that an average end user would understand and nor should they in my opinion.  This is something we (the industry) should be pulling together to provide the safest, most secure and most reliable set of services that are ultimately completely transparent to an end user. In one of the comments to the original post, Nick later agrees to the point that the enabling of the feature is not a key indicator but, still believes there is little perceived security value in implementing and maintaining this feature when weighed up with the maintenance and support costs, and a claim of web compatibility risks; the later I find really amusing myself but, sometimes we break things for the greater good. In my research, I noted that Brian Campbell from Ping Identity, also weighed in here to and certainly challenged the position of the Chrome team and has even called for the entire industry to get onboard (see tweet below); Brian is also a contributor to the Token Binding specification.

Microsoft has also been busy building in support for Token Binding.  Recognising the importance of proving possession of a security token for both consumer and corporate use they introduced support in early 2017 first with Windows 10 1703 and with their Edge Browser.  This was followed by support in some of their client applications too. But, up until recently very little had been said in public to support Token Binding but, in the last week this has all changed with a blog article by Alex Simons calling It’s Time for Token Binding.  It’s a rally cry for us all to get behind Token Binding and to lobby our browser and software vendors.  The blog article also includes some interesting insights from Microsoft’s Director of Identity Standards on the AAD team – Pamela Dingle.  Worth a read.

The IETF Working Group for Token Binding has included representatives from Google, Microsoft and PayPal just to name a few.  Since its creation in 2014 it has followed a regular schedule of reviews and increased membership to ensure that the specification can properly address the problem that drove it to be created initially.   Having spent 4 years in the making the specification is now in the final stages of being fully ratified.  While in itself does not outright force vendors to comply, it does imply that it is “recommended” for the issue that it is addressing.  I suspect that once it is approved it will become easier for software vendors to begin work to support Token Binding (I hope!).

So, is Google, right? For every argument I read that challenges Token Binding I find one to support it.  While there has been a lot of work to protect Cookies from theft and exploit we can’t rule out that it may happen so, this is where Token Binding comes in to force the “proof of possession”.  If we look across the industry and specifically browser vendors – support is absent in both Safari and Firefox too.  So, there is work to be done to lobby these vendors too.

What others are saying

Alex Simons, Director of Program Management, Microsoft Identity Division

See It’s Time for Token Binding where Alex talk’s about Microsoft commitment to this forthcoming ratified specification by IETF:

At Microsoft, we believe that the Token Binding can greatly improve the security of both enterprise and consumer scenarios by making high identity and authentication assurance broadly and simply accessible to developers around the world.

Brian Campbell, Distinguished Engineer, Ping Identity

Brian is on the Token Binding working group and has contributed to the draft specifications.  In the tweet below he calls on us all to speak up and push Google to re-think their recent announcement to remove Token binding from Chrome.

Mark Russinovich, CTO Azure, Microsoft  

While brief, Mark shares his thoughts on Token Binding here:

Pamela Dingle, Director of Identity Standards on the Azure AD team, Microsoft

See It’s Time for Token Binding where Pamela expands on Alex Simon’s remarks on Token Binding and shares some of the key points surrounding the steps to achieve and the ongoing work to bring Token Binding to life.

Token Binding specification

The specification is still in draft but you can access the Token Binding family of specifications on the IETF web site.

Final remarks

In the past 3 weeks much has been written and said about Token Binding.  A lot of this as a direct result of Google’s intent to remove Token Binding from Chrome, which than drove others including Microsoft to state their position.  Up until last week, Token Binding was something I knew of but, wouldn’t have said I knew it confidently enough to make an argument for or against.  Having spent the last two days reading the specification and many industry professionals views on it, I am confident in supporting the need for Token Binding in our industry and trust that Google, and more importantly the Chrome team will come around to the same view point sooner rather then later.

Thanks for reading and please feel free to share your thoughts on the topic below.