Subject: Re: [Unbearable] Re : Re : Answer to WGLC for core document set

From: =JeffH <[email-masked]>
Date: Thu, 1 Dec 2016 16:53:27 -0800

JohnB said on Thursday, December 1, 2016 at 2:45 PM:
 > This WG is only defining the method for tying tokens to the transport
 > layer.

well, actually, we are not defining _how_ security tokens (or app
protocol messages or whatever) might be bound to TLS using Token Binding
IDs. Rather, we are defining the _means_ for applications and app
protocols to define that, as appropriate for their situations.

 > It is up to other protocols like OAuth to define how to use those
 > bindings.

yes, where s/bindings/token binding IDs/

 > [Denis] should probably be looking at the Token binding drafts in the
 > the OAuth WG.

Agreed.

[email-masked] wrote on Wednesday, November 30, 2016 at 4:36 PM:
 >
 > Bob is willing to collaborateurs [collude] with Alice.
 >
 > He does not need to give away any secret but only using his secret
 > key to compute everything that Alice is needing.

Though, one can architect things at the app layer such that the Token
Binding IDs are bound into app layer artifacts, AND the app layer has
other safeguards, such that a collusion attack is infeasible.

For example, in..

[email-masked] wrote on Friday, November 18, 2016 at 10:57 PM:
 >
 > In this scenario Bob is willing to collaborate with Alice so that he
 > can export a token that can be re-used by Alice. Alice will not
 > necessarily impersonate Bob but will only be re-using a token that
 > has been legitimately originally obtained by Bob. If this token
 > contains an attribute saying "older than 18", Alice can present it
 > to a protected resource that can remember this attribute. If she is
 > older than 18 today, tomorrow she will obviously be older than 18
 > and such an attribute does not need to be renewed. So she can keep
 > advantage of it until she will really be 18.

..if the app layer and its security tokens are designed such that they
are not only bound to a given Token Binding ID (TBID), but they are also
bound to attributes of Bob's account, and integrity-protected (e.g.: the
sec tokens are HMAC'd with a per-account secret key that's known only to
the server), then Alice's replay of Bob's sec token, along with the
generated-in-collusion-with-Bob Token Binding Message (TBM), in the
context of Alice's account, will be detectable even though the TBID in 
the sec token and the TBM match.

I don't think its the job of the Token Binding specs themselves to solve
this, rather it is the job of app layer specs that are making use of 
Token Binding. Note that -tokbind-https (HTTPSTB) defines only the 
conveyance of the TBM in the context of HTTPS -- it does not define how 
one goes about embedding TBIDs in cookies, JWTs, HTTP message, or 
whatever is being schlepped around within/over HTTP. Specifying such is 
the job of the stuff built on top of HTTP, e.g...

 > The JWT PoP spec https://tools.ietf.org/html/rfc7800 lays the
 > foundation for a confirmation claim in JWT, and is not specific to
 > token binding.  That may be part of what you are looking for.

that all said, the Tokbind specs could perhaps better explain some of 
these nuances, eg in sec cons. Thanks for bringing up collusion attacks.

HTH,

=JeffH