Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding?

From: =JeffH <[email-masked]>
Date: Thu, 3 Mar 2016 19:29:34 -0800

Andrei wrote:
 >> finally, if I'm understanding the security model correctly, one always 
needs
 >> to use and sign the present-server-EKM when sending the TokenBindingMessage
 >> to the preset server, regardless of the type of contained TokenBindings
 >> (provided or referred), because otherwise the server won't have
 >> cryptographic proof-of-possession of the private keys. Thus this might as
 >> well be specified in one central place -- i.e., -tokbind-protocol.
 >
 > Yes, and I think we can make a simple clarification in TBPROTO, without
 > adding federation content to it. The I-D currently says:
 > " The Token Binding message consists of a series of TokenBinding
 >    structures containing the type of the token binding, the
 >    TokenBindingID, a signature over the exported keying material (EKM)
 >    value, optionally followed by Extension structures."
 >
 > We could add:
 > " The EKM MUST be obtained from the TLS connection that is used to send
 >  the Token Binding message."
 >
 > Adding federation-related content to TBPROTO seems undesirable, because
 > federation mechanisms are highly application protocol-specific.

hm, a couple thoughts..

* -tokbind-protocol-04 already contains this language..

    [I-D.ietf-tokbind-https] also describes Token Binding between
    multiple communicating parties: User Agent, Identity Provider and
    Relying Party.

..which is pretty clearly describing federation.

* more importantly, by virtue of defining the TokenBindingType of 
"referred_token_binding", TBPROTO is already tiptoe'g into the "multiple 
communicating parties" morass (aka "federation").

Perhaps if we think that pretty much only HTTP will make use of the 
TokenBindingType of "referred_token_binding", then maybe that TB type ought 
to be defined and IANA-regisgtered in -tokbind-https -- in that way it seems 
all mention of the "referred" TB concept can be excised from TBPROTO.  The 
latter spec would still establish the TB type registry.

Otherwise, I tend to think that 
<https://github.com/TokenBinding/Internet-Drafts/pull/16> embodies what 
needs to be done in TBPROTO to have proper processing rules for referred 
Token Bindings.

In any case, in my view, the processing rules language in TBPROTO could be 
usefully stated more clearly and my overall suggestions regarding that are 
embodied in the above-linked PR #16.

HTH,

=JeffH

---

From: Andrei Popov <[email-masked]>
Date: Fri, 4 Mar 2016 16:49:14 +0000

>... TBPROTO is already tiptoe'g into the "multiple communicating parties" morass (aka "federation").
It did, with the goal of defining all the Token Binding types we currently know of in one document.

> ... then maybe that TB type ought to be defined and IANA-regisgtered in -tokbind-https -- in that way it seems all mention of the "referred" TB concept can be excised from TBPROTO.  
My preference is to do this, if I have to, rather than bringing more federation language into TBROTO. Even better, we can just add one sentence explicitly saying that EKM comes from the same TLS connection that carries the signature over this EKM, and avoid any ambiguity.

-----Original Message-----
From: =JeffH [mailto:[email-masked]] 
Sent: Thursday, March 3, 2016 7:30 PM
To: Andrei Popov <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: RE: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding?

Andrei wrote:
 >> finally, if I'm understanding the security model correctly, one always needs  >> to use and sign the present-server-EKM when sending the TokenBindingMessage  >> to the preset server, regardless of the type of contained TokenBindings  >> (provided or referred), because otherwise the server won't have  >> cryptographic proof-of-possession of the private keys. Thus this might as  >> well be specified in one central place -- i.e., -tokbind-protocol.
 >
 > Yes, and I think we can make a simple clarification in TBPROTO, without  > adding federation content to it. The I-D currently says:
 > " The EKM MUST be obtained from the TLS connection that is used to send  >  the Token Binding message."
 >
 > Adding federation-related content to TBPROTO seems undesirable, because  > federation mechanisms are highly application protocol-specific.

hm, a couple thoughts..

* more importantly, by virtue of defining the TokenBindingType of "referred_token_binding", TBPROTO is already tiptoe'g into the "multiple communicating parties" morass (aka "federation").

Perhaps if we think that pretty much only HTTP will make use of the TokenBindingType of "referred_token_binding", then maybe that TB type ought to be defined and IANA-regisgtered in -tokbind-https -- in that way it seems all mention of the "referred" TB concept can be excised from TBPROTO.  The latter spec would still establish the TB type registry.

Otherwise, I tend to think that
<https://github.com/TokenBinding/Internet-Drafts/pull/16> embodies what needs to be done in TBPROTO to have proper processing rules for referred Token Bindings.

In any case, in my view, the processing rules language in TBPROTO could be usefully stated more clearly and my overall suggestions regarding that are embodied in the above-linked PR #16.

HTH,

=JeffH