Re: [Unbearable] WGLC 3 on core documents

[Nick Harper <[e-mail]>]

On Wed, Mar 1, 2017 at 4:00 PM, Martin Thomson <[e-mail]> wrote:
> On 2 March 2017 at 10:55, Nick Harper <[e-mail]> wrote:
>> I recall a previous discussion around referred token bindings and
>> whether a signature is needed. In that discussion, the approach
>> considered is that in the Token Consumer's (TC) request to the Token
>> Provider (TP), the TC asks for a token that is bound to the TBID
>> between the client and TC (call this TBID C). This had the problem
>> that if there was a MitM between the client and TC (and the MitM uses
>> TBID M for connections from the MitM (on "behalf" of the client) to
>> TC), then the MitM can change that request of TP "provide a token
>> bound to C" to "provide a token bound to M". The key takeaway from
>> this discussion was that whatever mechanism is used to refer a TBID
>> needs to show that the provided and referred TBIDs belong to the same
>> client. Having a signature from both keys is an obvious way to do
>> that.
>
>
> This is only a problem if the Token Consumer is able to tell the
> client which TBID to use.  I had assumed that the TC had no control
> over this, it's a boolean flag and there can be only one.
>
> Note sure that you motivated having a list here.  Unless you were
> intending to also do something about the redirect chain issue.

I was only including a list since the current structure of a
TokenBindingMessage allows for multiple referred TBIDs. I wasn't
trying to change how a redirect chain would work. If we change TBPROTO
to have signature-less referred token bindings, I think the
TokenBindingMessage would to change to one of the following:

struct {
    TokenBinding provided_token_binding;
    TokenBindingID referred_token_binding_id;
} TokenBindingMessage;

or

struct {
    TokenBinding provided_token_binding;
    TokenBindingID referred_token_binding_ids<0..2^16-1>;
} TokenBindingMessage;