Token Bindings to Gear Up Authentication Assurance

In last year’s “Passwords are Overloaded, Not Dead” I voiced skepticism that security’s oldest construct would be replaced anytime soon. But many in the industry continue working to replace passwords, and while their marketing slogans may sometimes be off the mark, their efforts are bearing fruit. One such fruit is the IETF’s work on token binding specifications  led by Microsoft, Google and others. These specifications may in time gear up authentication assurance by cryptographically binding tying cookies, SAML and OAuth tokens to a Transport Security Layer (TLS) pairing between individual clients and servers. 

There’s a lot more going on under the covers of password-based authentication than the string you enter at the login prompt. The “Authentication Flows” figure above illustrates a typical WebApp access enabled through Security Access Markup Language (SAML) tokens. The tokens are obtained via initial login to a Windows domain using Active Directory Services (ADS), or LDAP, and a Microsoft Security Token Services (STS) and Identity Provider (IDP) packaged with ADS.

The Knowledge Factor

Often, however, discussions of password sufficiency simply focus on the initial user credential, or password string, and the login event. As we’ve seen in a long “Successor to Passwords” discussion thread on Linked In’s Security Architecture group, passwords are the classic form of the knowledge factor, aka “something you know.” Knowledge factors can take other forms, such as pictorial pattern recognition. I’ll leave that particular debate to others.

Two Factors are Better than One

Research suggests that no one factor, by itself, will be strong enough to resist the efforts of determined or sophisticated adversaries. Something you know? They’ll learn it. Something you have (like a hardware token)? They’ll steal it. Something you are (biometrics)? They’ll clone the biodata.

But two factors – now we’ve raised the bar. Hence the popular combination of a static password that the user knows with a one time password (OTP) collected from a token such as a SMS-enabled phone or RSA SecurID. As I wrote in A Two Factor Authentication Makeover for your Protection, augmenting passwords with another factor can greatly increase the difficulty cyberattackers face in compromising your account.

Underlying Authentication Mechanisms and Tokens

Even after implementing strong authentication with two different kinds of (good) factors, our work is far from done. So far, we’ve only discussed the “user login” step. But even the strongest mechanisms for that initial login count for nought if event sequences in subsequent Authentication Flows – such as those shown in the figure above – fail. 

Convenience is important, so the user only has to login infrequently. After that, the devices, applications and services take over using cookies, OAuth tokens, SAML tokens and other constructs to represent to each other over an untrustworthy network that they’re acting on behalf of a logged in user. It’s mostly transparent to users, but can bite them just the same. For many of these tokens are weak. In the example shown, malware could steal the SAML artifacts, or the cookie, from the Browser and/or a server’s database. OAuth is even worse with respect to the risk of databases full of tokens getting breached. Once its obtained them, malware can use these tokens anywhere they are accepted to masquerade as a legitimate user, or to conduct man in the middle (MITM) attacks.

New IETF Token Binding Specifications

Fortunately, Internet-enabled operating systems and authentication protocols are gearing up their level of assurance for token utilization. Google and Microsoft have teamed up to develop new IETF specifications. I quote from the draft Token Binding over HTTP:

“We describe both first-party as well as federated scenarios. In a first-party scenario, an HTTP server issues a security token (such as a cookie) to a client, and expects the client to send the security token back to the server at a later time in order to authenticate. Binding the token to the TLS connection between client and server protects the security token from theft, and ensures that the security token can only be used by the client that it was issued to. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.”

The companion Token Binding Protocol draft specification defines “a Token Binding ID for a TLS connection between a client and a server. The Token Binding ID of a TLS connection is related to a private key that the client proves possession of to the server, and is long-lived (i.e., subsequent TLS connections between the same client and server have the same Token Binding ID). When issuing a security token (e.g. an HTTP cookie or an OAuth token) to a client, the server can include the Token Binding ID in the token, thus cryptographically binding the token to TLS connections between that particular client and server, and inoculating the token against theft by attackers.”

Implementations Hitting the Street

Google has already implemented functionality from the draft specs in Chrome, and Microsoft is working to include the functionality in Windows 10, which will include future versions of Internet Explorer. Note the strong cryptography pattern from the second italicized paragraph – the Token Binding ID is related to a private key that the client proves possession of the server. That may make those of us who can remember Public Key Infrastructure (PKI’s) long Trough of Disillusion pause…

But don’t worry. Token binding only requires public key cryptography (PKC) not the full-blown PKI. And its completely transparent to users. There are challenges with computational complexity performance for PKC in very small devices (think IoT) but new authentication standards related to token binding will deal with that. 

Bottom Line

Get these new IETF specifications on your radar screen, watch for further progress, and favor solutions that support them. I have a feeling they’ll become commonplace and make all our work on stronger authentication at the user layer much more worthwhile.