Re: [Unbearable] Binding tokens to scope in HTTP

[Andrei Popov <[e-mail]>]

The idea of signing TB extensions has been discussed multiple times over the years.
Not signing extensions allows an extension to sign the TB message, which is what could be used for handy things like key attestation.
It is likely also possible to do key attestation without signing the entire TB message, so if the WG wants to change this prior consensus, we can do so.

The reason TB keys are scoped to eTLD+1 (in the case of HTTPS) is that the cookies these TB keys protect are scoped to eTLD+1.
Per IETF98 discussion, the next revision of the I-Ds will clarify that browsers cannot exceed the scope of eTLD+1. If cookies are scoped more narrowly, the same can be done with TB keys.

Cheers,

Andrei

From: Unbearable [mailto:[e-mail]] On Behalf Of Bill Cox
Sent: Monday, April 3, 2017 10:24 AM
To: Nick Sullivan <[e-mail]>
Cc: [e-mail]
Subject: Re: [Unbearable] Binding tokens to scope in HTTP

The extensions used to be covered in earlier drafts.  I forget why this was dropped, but IIRC, it was discussed on this list.  In any case, it sounds like there are a number of people who would prefer to change TB extension numbers and effectively be a new extension rather than use the header's extension capability.

Your example has a minor error:  eTLD+1 for example.com<http://example.com> is example.com<http://example.com>, so a.example.com<http://a.example.com> would have the same TB key as b.example.com<http://b.example.com>.  However, the idea for the attack is valid.  eTLD+1 based security seems to be a kludge.  I felt that binding to the sites covered by a certificate might make sense, but it does not work out.  For example, we have certs for gmail.com<http://gmail.com> and youtube.com<http://youtube.com>, and certificates covering both, IIRC.  We could use the same TB sig, bound to that certificate, for a lot of sites, reducing TB signature overhead.  It also makes sense to me from a security perspective: the server has proven ownership of a collection of domains, so just bind to that.  This would eliminate all the eTLD+1 security issues.  However, we can't count on seeing the same certificate all the time.  Sometimes a server will present a login.example.com<http://login.example.com> certificate on one connection, and *.example.com<http://example.com> on another.  Most likely, the cookie that is used for auth would be bound to login.example.com<http://login.example.com>, and would be rejected for all other *.example.com<http://example.com> domains.

I like the idea of signing extensions and also the host name from the host header.

Bill


On Mon, Apr 3, 2017 at 9:47 AM, Nick Sullivan <[e-mail]<mailto:[e-mail]>> wrote:
The token binding header does not have any identity bound to it. This is potentially problematic because it makes it much more likely that this protocol is vulnerable to unknown key share issues.

Unknown key share attacks happen when a public key is used without binding it to an identity by a signature. For example, Richard Barnes recently published a draft describing how DANE with raw keys was vulnerable to this style of: https://tools.ietf.org/html/draft-barnes-dane-uks-00.

In section 2.1. of draft-ietf-tokbind-https, the key pair scoping is defined to be eTLD+1. Depending on the threat model, this requirement can be subverted.

Consider an attacker who has access to read and modify headers, but not private keys. Imagine a buggy/malicious service worker or something else of this sort. Now imagine a site with a.example.com<http://a.example.com> and b.example.com<http://b.example.com> and a wildcard *.example.com<http://example.com> certificate. The attacker can take token binding headers from a.example.com<http://a.example.com> and put them on requests to b.example.com<http://b.example.com> and the cookies set on b.example.com<http://b.example.com> will be bound to a.example.com<http://a.example.com>'s key.

This doesn't sound like a large issue, but it's indicative of the type of subtle problems not binding the key to a context can cause.
If the token context was bound to the scope by including the eTLD+1 in the (or the origin if the browser intends to use stricter token scoping), *and* this scope was covered by the signature then this would not be possible. The server could check the host header against the token context and then refuse the token binding for new cookies.

A logical place to put this would be in the extensions of the token binding structure, but unfortunately the extensions is not signed and so can be modified. Is there a reason the extensions field of the TokenBinding structure is not signed by the private key?

Nick

_______________________________________________
Unbearable mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/unbearable