IETF 101 London

27 Mar IETF 101 London

About IETF

The IETF is the premier internet standards body developing open standards through open processes. While most IETF work takes place online, meetings provide in-person opportunities to advance work.

My last IETF meeting was 48th in Pittsburgh in summer of 2000. So it’s been a while since that. What has changed I was asked? Nothing much, the IETF works the same way as back then, the IETF humming is there, as well as all the grand personalities and at times heated discussion – all of which makes IETF what It is.

This time I was here mainly for our involvement and interest in OAuth and Token Binding, and generally following other topics on the security track.

OAuth 2.0 and Token Binding

The core foundation of OAuth is already well specified and widely deployed but there’s still a good amount of improvements and new development going on. For me the two most interesting drafts are both related to token binding: The Mutual TLS specification defines certificate bound access tokens, using both self-signed and PKI certificates. The OAuth Token Binding specification builds upon new development in the TLS stack, the Token Binding Protocol.

What is token binding? A quite fundamental improvement in how various tokens on the web are processed. In the past most if not all tokens on the web are considered bearer tokens, meaning that anyone who simply presents such a token is allowed to use the token for authorized resource access. And because tokens are simply strings of characters it is theoretically possible (not always easy) to steal tokens and be able to impersonate a victim.

Token binding adds a mechanism for proof of token ownership. Within a token is encoded a reference to a public key. While presenting a token the user must also show evidence of being in control of the private key paired with the public key. This evidence is proven on the TLS connection level with using either Mutual TLS or the Token Binding Protocol.

Ultimately token binding is one of the crucial building blocks when building a safer phishing resistant web for all internet users.

ACE

For IoT the Authentication and Authorization for Constrained Environment group is working on specifications and profiles of TLS, JWT and OAuth where low power and limited bandwidth requirements are taken into account. In practice this means that ACE is working on and using specifications such as DTLS that defines UDP as transport for TLS, or CWT which is based on JWT but uses binary encoding instead of JSON.

TLS 1.3

One of the most heated discussions at this IETF meeting was around TLS 1.3 and the Visibility Extensionproposal. TLS 1.3 is the next version of TLS, probably the most widely used encryption technology on the internet used by all modern web browsers and on all major web sites. The new version of TLS removes many weak crypto algorithms and adds other improvements. All of this breaks most of the current interception technologies enterprises and data centers are using for deciphering TLS connections causing concern amongst enterprises. Isn’t it only a good thing that TLS encryption cannot be intercepted one may ask?