TLS Token-Binding Standard Gains a Foothold on the Web
Token Binding is an extension to TLS (the secure protocol used for https connections) to provide stronger web authentication and longer, more robust sessions. It’s one of the foundations of the FIDO2 and W3C WebAuthentication standards for identity options that move beyond passwords — and it’s being deprecated in Chrome just as it’s about to become an RFC through the Internet Engineering Task Force.
Token binding replaces the “bearer” tokens of OAuth 2.0 — which can be lost, stolen, intercepted, proxied, replayed or altered by man in the middle attacks, because whoever has the token can get the resources it unlocks — with tokens bound to cryptographic certificates in both the client and the server.
It’s like the difference between paying with cash, which anyone can spend even if they stole it or found it in the street, and a credit card that you have to prove belongs to you, using a signature or a PIN.
The idea behind token binding is “proof of possession” and making that harder to fake, so that it’s safe to keep tokens around for longer. “The challenge with tokens is that they’re only as secure as where you store them,” Okta product architect Tom Abbott explained to the New Stack. “Current web applications either use HTML5 Web Storage or cookies to store tokens. Both of these approaches have their issues, including being vulnerable to man in the middle, token exporting, and replay attacks.”
Token binding uses cryptographic key pairs and, ideally, secure storage, to fix that, Steve Syfuhs, a product manager in the Windows identity and security team, told us.
“With token binding, there’s a cryptographic key that lives on your device and only the device can see it; in some cases even the user can’t see it, so it’s protected and malware can’t get it. When your browser or http client makes a TLS connection to a service and does the TLS negotiation, the client says ‘I support token binding’ and the server says ‘OK, here’s a value I want you to sign’. The client signs it with the key and sends the signed value and the public key of the key. Then the server can see you’ve signed it. Whenever I need you to prove that you’ve signed this I can pass this value along, and put it in OAuth tokens and cookies and so on, so I can constantly validate it.”
That means whenever the server needs proof that your connection is coming from the same device, it can compare the signature value to see if it’s from the same key. That prevents lateral movement of the token. “It’s per device, per user, per app,” Syfuhs explained; “so it’s on my device, for my user, for my application — whether that’s a Windows application or my Edge browser — and for the domain I’m talking to. When I talk to Google.com it’s going to have a different key than Bing.com. Another user on that same device can’t steal it and if you’re on a different device the server’s going to negotiate a different key.
With token binding, man in the middle attacks can’t forward requests or replay credentials because they can’t prove they have the key bound to the token. “They could strip it or remove it from the header, but the server will say ‘it’s not there so I don’t trust this token’,” Syfuhs pointed out.” Token binding can protect session cookies, OAuth access and refresh tokens or OpenID Connect ID tokens, so they can’t be re-used outside the client-specific TLS context where they were issues.
That significantly reduces the impact of cookie-stealing malware on the device or vulnerabilities like open redirects and cross-site scripting; it doesn’t make attacks impossible, but it means they’re no longer cheap or easy.
Developers can choose how the server treats connections that don’t have the bound token they’re supposed to; perhaps setting a shorter session timeout or forcing a new sign-in. Microsoft uses it to extend session lifetimes without giving up security for user convenience, Syfuhs told us. “At some point we proved, back to the point of sign-in, that this is the same connection on the same device and nobody has proxied or man-in-the-middled it. If you’re signed in to Office 365, instead of the session lifetime being 15 minutes or an hour and constantly doing background polling to make sure you’re signed in, we can extend it to say eight or 12 hours to match your working day.”
That could also improve server bandwidth or device battery life, depending on how much background polling was involved. “If you want to reduce power usage or network bandwidth, using token binding is a way you can guarantee security of a session while reducing the overhead,” Syfuhs suggested.
Ready or Not
The token binding protocol has been in development for several years and the draft proposal, with contributions from Google, Microsoft and Paypal, is close to being ratified at the IETF (the final editing started in July), and the identity ecosystem is already starting to build on it.
Token binding has been in Windows 10 since 2015, in the Edge browser and in the platform (so any Windows application can take advantage of it), and it’s on by default in Windows Server 2016. Since the 1803 release of Windows 10 (which came out in April 2018), Microsoft has been using it in a feature called Cloud Credential Guard that protects Azure Active Directory credentials, including the ones for Single Sign-On to cloud services that organizations are managing through AAD (which could be anything from Twitter to Box, Salesforce or Google Apps).
Token binding is used for all authentications to Azure using the Web Authentication Manager which underpins the AAD SSO capabilities, Syfuhs told us, so that includes enterprise users signing in to their Windows account, with the keys stored in an isolated VM and the TPM by the Key Guard service. That will soon include any browser connections to Azure AD, like connecting to Office 365 or SharePoint. Token binding also allows for federated identity, and ADFS also supports it.
The developing W3C Web Authentication (WebAuthN) standard for using MFA and passwordless or biometric authentication (like Windows Hello or a Yubikey) will rely on token binding to avoid man in the middle attacks.
Yubico, Ping Identity and Microsoft are contributing to a spec adding token binding support to OpenID Connect and the latest OAuth 2 best practices document recommends using token binding. Government and financial systems that need to meet NIST-800-63C requirements for AAL3 authentication will require something like token binding for identity assurance if they want to user browser authentication rather than a smartcard. Dropbox and Oracle have been looking into using token binding and Gluu’s open source identity and access management system will have token binding support in version 4 (due out in early 2019).
Google started turning token binding on for some of its services like YouTube a couple of years ago, even though it was behind a flag in the Chrome browser (which caused some issues for Edge users when there were bugs in its token binding implementation). But then at the beginning of August, the Chrome team announced that the feature would be deprecated in the next version of the browser and gone altogether in Chrome 71.
One reason Google gave for the removal was the lack of interest and adoption. Part of the problem may be the different timescales of web and IETF development since a number of large organizations like Merck, HPE and Oath who’ve been planning to adopt token binding have been waiting for it to become an IETF RFC.
But Google also mentioned “web compatibility risks” which include extensions not working and developer tools breaking. There might be more fundamental issues too, Abbot suggested.
Obviously, adding keys and binding tokens to them is a little more work for clients and servers to perform and it means that the first TLS connection involves an extra round trip. Cookies can’t be shared (a security benefit that developers might view as an inconvenience). Proxies also become problematic; the server can see if the token binding is missing but it won’t be obvious if that’s malicious or just a proxy that’s stripped off the token binding, or the proxy might just break the connection.
“By tying token security (for example, an application or API layer) down to the network layer, any future changes to TLS will impact the application — making foundational changes across OSI layers, as a result, much more difficult in the future,” Abbott told us.
Token binding won’t go away if Chrome doesn’t support it; Microsoft and Yubico are both committed to it and there’s a real need to improve security for tokens (Google was, after all, one of the original contributors to the token binding spec). But developers who were planning to rely on token binding may find this frustrating.
While enterprise developers can specify Edge to get token binding, web developers generally can’t rely on Edge being available. Standards teams, in particular, the WebAuthn group, will have to do a lot of work to find a new solution for securing tokens if there has to be a completely new approach rather than just an update to the token binding protocol to address the compatibility issues Google raises. That means more delay, and a fragmented web platform.
Feature image via Pixabay.
