Subject: [Unbearable] Binding tokens to scope in HTTP

From: Nick Sullivan <[email-masked]>
Date: Mon, 03 Apr 2017 16:47:40 +0000

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 and b.example.com and a
wildcard *.example.com certificate. The attacker can take token binding
headers from a.example.com and put them on requests to b.example.com and
the cookies set on b.example.com will be bound to 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

---

From: Bill Cox <[email-masked]>
Date: Mon, 3 Apr 2017 10:24:09 -0700

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 is example.com, so
a.example.com would have the same TB key as 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 and
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 certificate on one connection, and
*.example.com on another.  Most likely, the cookie that is used for auth
would be bound to login.example.com, and would be rejected for all other *.
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 <[email-masked]>
wrote:

> 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
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 3 Apr 2017 19:48:09 +0000

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:[email-masked]] On Behalf Of Bill Cox
Sent: Monday, April 3, 2017 10:24 AM
To: Nick Sullivan <[email-masked]>
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable