Google and Microsoft boffins playing nicely together to stop replay attacks in their tracks

Google and Microsoft engineers have pooled their efforts to propose a protection against what are known as “replay attacks”.

These occur when an attacker steals something like a victim’s OAuth token and uses it to impersonate them to access otherwise secured resources.

The Token Binding Protocol is the next instalment in the Internet Engineering Task Force’s (IETF’s) years-old effort to rewrite the internet around user security.

Compared to bygone days, the 2018 user has pretty good security: the websites they visit can be protected with HTTPS, their logins can be protected with OAuth, and so on.

However, according to the recently published Request for Comments (FRC) 8471, the tokens that HTTPS and OAuth (and other protocols) store on the user machine offer a replay attack vector that needs handling.

Enter Microsoft’s Andrei Popov and Magnus Nystroem, Googler Dirk Balfanz and W3C invited expert Jeff Hodges, authors of The Token Binding Protocol Version 1.0.

The RFC outlines a protocol that binds things like HTTPS security cookies and OAuth tokens to the TLS layer. The resulting encryption layer would prevent tokens from being exported by an attacker, and that would block replay attacks.

To establish token binding, the user agent would generate a private-public key pair for each “target” server – that is, the client presents its public key, and the handshake establishes a private key. This would happen for each TLS connection to that server.

As the RFC noted: “In order to successfully export and replay a bound security token, an attacker needs to also be able to use the client’s private key; this is hard to do if the key is specially protected” – for example, if the key was generated in a hardware module.

The authors have designed the protocol to avoid adding round trips to the normal TLS handshake: it consists of a single message sent by the client proving possession of the asymmetric private key. If it checks OK, the server creates the binding with the ID contained in the client’s message.

Exactly how the token is bound to the TLS layer, the RFC noted, will be specific to the application: the Token Binding ID or its cryptographic hash could be embedded in the security token, or could be maintained in a database mapping tokens to the binding IDs.

The RFC noted that there is one scenario in which a user is still vulnerable: the bound token could be accessible to malware on their machine. Their suggestion of using hardware modules (like security dongles) to generate the key was designed to guard against that.

The RFC also carried the recommendation that bound tokens need to be integrity-protected, so that attackers can’t switch out a Token Binding ID for one of their own choosing without being detected.

The protocol RFC is backed by two other RFCs.

Popov, Nystroem and Balfanz put their names to RFC 8472, which defines a TLS extension using the Token Binding Protocol; and RFC 8473 (Popov, Nystroem, Balfanz, Hodges, and Google’s Nick Harper) described how to apply the protocol to HTTP.

Token binding has only reached RFC stage for TLS 1.2, but this Internet Draft shows that TLS 1.3 isn’t being ignored. ®

Sponsored: Following Bottomline’s journey to the Hybrid Cloud

READ MORE HERE