Intent to Implement: Token Binding

[Nick Harper]

Intent to Implement: Token Binding

Contact:

nha...@chromium.org, van...@google.com

Specs:

http://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/

http://datatracker.ietf.org/doc/draft-popov-tokbind-negotiation/

http://datatracker.ietf.org/doc/draft-ietf-tokbind-https/

Motivation:

Many web services use bearer tokens (such as cookies, OAuth tokens) for authenticating clients to servers. Attackers gaining possession of a token can reuse it to impersonate the authenticated user. Token Binding attempts to solve this problem by cryptographically binding tokens to the TLS layer. Token Binding is similar to Channel ID in its goal, but has a different implementation.

Token Binding and Channel ID both work by having the client sign part of the TLS handshake with an asymmetric key generated by the client unique for that origin. Channel ID sends its message as part of the TLS handshake, while Token Binding sends it in the application layer (HTTP).

This Intent to Implement does not cover all of the Token Binding specs; it only covers a subset needed to reach feature parity with Channel ID. This includes supporting negotiating token binding with ECDSA keys and sending the Token-Binding HTTP header. This does not include anything from section 3 of “Token Binding over HTTP”. The current implementation of Channel ID is based on a draft spec that expired two years ago. Token Binding will continue to evolve as the replacement for Channel ID.

Compatibility Risk:

Low risk. Token Binding includes as part of its protocol negotiation the version of the protocol being used. The client can only negotiate a single version (while the server can support multiple versions). We will switch to supporting the latest version some amount of time after its (draft) spec is published, allowing time for servers that support token binding to update to the latest version.

Microsoft is behind token binding, but their plans for support in IE or Edge are unclear. Mozilla has also chatted about it, but their level of commitment is less clear. There are no signals from Safari or Opera.

Ongoing technical constraints:

None

Will this feature be supported on all six Blink platforms?

Yes

Tracking Bug:

crbug.com/467312

Design Doc:

https://docs.google.com/document/d/1Ta3GlT_LrqAOLV217Kutn3B2trvifStxB0CThQ_kk78/edit#

[Nick Harper]

Re-sending to chromium-dev

[Alex Russell]

Is there an API for this feature? Is it possible for an app (from JS) to understand/use the state of the bound tokens without reflection through the server?

Regards

[Ryan Sleevi]

The Token Binding drafts are exploring exposing details to fetch(), but exposing the bindings themselves via JS is an issue fraught with peril. The current implementation (via Channel ID, a deprecated/expired draft that Chrome implemented before the I2I/I2S phase) exposes this information via extensions, and draft proposals of the still-secret FIDO Alliance specs (which combines the public U2F and UAF APIs proposed as part of FIDO 1.0 into a new API) also look to expose this information in a more uniform way.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/0bdb277f-fc4d-4d9f-9ee6-7db7210c602d%40chromium.org.

[Anne van Kesteren]

On Wed, Jul 15, 2015 at 5:16 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> The Token Binding drafts are exploring exposing details to fetch(),

See https://github.com/whatwg/fetch/issues/30 for details.


--
https://annevankesteren.nl/