IETF approves new internet standards to secure authentication tokens

The Internet Engineering Task Force (IETF) --the organization that develops and promotes Internet standards-- has approved three new standards this week designed to improve the security of authentication tokens against "replay attacks."

Authentication tokens are used everywhere online these days. When a person logs into his Google or Facebook account, an authentication token is generated and stored in a cookie file inside the user's browser.

When the user accesses the Google or Facebook site, instead of asking the user to enter his/her credentials again, the user's browser gives the website the user's authentication token.

But authentication tokens haven't only been used with browser cookies and websites. They are also used inside the OAuth protocol, the JSON Web Token (JWT) standard, and a slew of public or private libraries implementing token-based authentication, often used with APIs and enterprise software solutions.

Hackers have figured out a long time ago that they could steal these tokens instead of users' passwords and access accounts without the need to know a password. Such attacks are known as "replay attacks."

This week, with contributions from Google, Microsoft, and Kings Mountain Systems engineers, the IETF has formally approved three new standards meant to protect token-based authentication systems:

• RFC 8471 - The Token Binding Protocol Version 1.0
• RFC 8472 - Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation
• RFC 8473 - Token Binding over HTTP

These three standards are meant to add an extra layer of security for the process of generating and negotiating a new access/authentication token.

The general idea is to create a connection between the user's device and the token, so even if an attacker manages to record a token, he won't be able to execute a replay attack unless he was using the same exact device or device configuration the token was created on.

At the technical level, according to RFC 4871, this can be done by the client's device generating a pair of a private and public key. The optimal scenario would be if both keys were generated inside a secure hardware module, such as a PC's TPM (Trusted Platform Module), intrinsically linking the private key with the hardware.

These two keys (the private key stored on the user's PC and a public key for a remote server) are then used to sign and encrypt parts of the negotiation steps executed before generating the actual authentication token, resulting in a hardware-dependent token value.

In theory, this sounds great.

Since the vast majority of web traffic today is encrypted, the new Token Binding protocol has been specifically designed around the TLS handshake process that happens before an TLS encrypted session is established.

The protocol's authors say they've designed the token binding process to avoid adding extra round trips to the TLS handshake process, meaning there won't be any unnecessary performance hit to existing servers.

Updates to browsers and servers will be needed in order to support the three RFCs, Tal Be'ery, Co-Founder and Security Research Manager at KZen Networks, told ZDNet in an interview.

The researcher also pointed out that the new Token Binding protocol is not necessarily limited to binding tokens at the hardware level alone, and can also work and securely bind tokens at the software level, meaning it can be implemented almost anywhere.

"It can be used by anything that communicates and needs to maintain a session," Be'ery said. "That includes IoT devices as well."

Currently, the Token Binding protocol has been designed around TLS 1.2, but it will also be modified to work with the newer TLS 1.3.

RELATED COVERAGE:

• It's 2018, and network middleware still can't handle TLS without breaking encryption
• OpenSSL 1.1.1 out with TLS 1.3 support and 'complete rewrite' of RNG component
• Web hosting providers take three days, on average, to respond to abuse reports
• DHS orders federal agencies to bolster cybersecurity with HTTPS, email authentication (TechRepublic)
• After Facebook's hack, there's a lot of useless post-breach advice (CNET)