Re: [Unbearable] Binding tokens to scope in HTTP

[Bill Cox <[e-mail]>]

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