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

From: =JeffH <[email-masked]>
Date: Tue, 1 Mar 2016 19:26:31 -0800

Nick wrote:
 > My understanding of referred token bindings is that the signature in the
 > TokenBinding struct is over the same EKM value for all TokenBinding
 > structs in the TokenBindingMessage. That is, when server A sends the
 > Include-Referer-Token-Binding-ID and redirects to server B, the
 > TokenBindingMessage sent to server B has a provided TokenBinding with
 > the client's TokenBindingID for server B and a signature of the EKM for
 > the connection to server B, and a referred TokenBinding with the
 > client's TokenBindingID for server A and a signature of the EKM for the
 > connection to server B. This way, server B can verify the signature for
 > both keys (assuming server B supports the key parameter used for the
 > referred TokenBinding).

Thanks for the detailed explanation, that makes sense.

Andrei added:
 > Correct, in order for a server to verify the binding, the signature has
 > to be over the EKM of the TLS connection with this server. Such
 > federation scenarios are described in detail in section 3.2 of HTTPSTB:
 > https://tools.ietf.org/html/draft-ietf-tokbind-https-02#section-3.2

However, it seems the details wrt which EKM is signed for 
referred_token_bindings is not explicitly stated AFAICT in either 
-tokbind-https-02 or in -tokbind-protocol-04. Although some folks have 
obviously figured it out, it may be difficult for others (I spose I'm one of 
'em).

So, I"ve crafted up some modest mods to -tokbind-protocol-04 that make this 
stuff explicit. The source can be perused here..

https://github.com/TokenBinding/Internet-Drafts/pull/16

..and a formatted diff is here..

<http://kingsmountain.com/doc/diff/Diff--draft-ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04c.txt.html>

HTH,

=JeffH

---

From: Andrei Popov <[email-masked]>
Date: Wed, 2 Mar 2016 19:54:43 +0000

Hi Jeff,

It is a good idea to clarify which EKM is signed in each leg of the federation scenario. I believe this will be a better fit in the HTTPSTB draft, which talks about all things federation.

Thanks,

Andrei

-----Original Message-----
From: =JeffH [mailto:[email-masked]] 
Sent: Tuesday, March 1, 2016 7:27 PM
To: Nick Harper <[email-masked]>; Andrei Popov <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in, TokenBindingMessage.TokenBinding?

Nick wrote:
 > My understanding of referred token bindings is that the signature in the  > TokenBinding struct is over the same EKM value for all TokenBinding  > structs in the TokenBindingMessage. That is, when server A sends the  > Include-Referer-Token-Binding-ID and redirects to server B, the  > TokenBindingMessage sent to server B has a provided TokenBinding with  > the client's TokenBindingID for server B and a signature of the EKM for  > the connection to server B, and a referred TokenBinding with the  > client's TokenBindingID for server A and a signature of the EKM for the  > connection to server B. This way, server B can verify the signature for  > both keys (assuming server B supports the key parameter used for the  > referred TokenBinding).

Andrei added:
 > Correct, in order for a server to verify the binding, the signature has  > to be over the EKM of the TLS connection with this server. Such  > federation scenarios are described in detail in section 3.2 of HTTPSTB:
 > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-tokbind-https-02%23section-3.2&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cd9470b33b761437b197808d3424a7ad4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=O9UBzgou7CnWJPtcyUCEdvCnq9V0YVMO2IIcwUcRbNc%3d

However, it seems the details wrt which EKM is signed for referred_token_bindings is not explicitly stated AFAICT in either
-tokbind-https-02 or in -tokbind-protocol-04. Although some folks have obviously figured it out, it may be difficult for others (I spose I'm one of 'em).

So, I"ve crafted up some modest mods to -tokbind-protocol-04 that make this stuff explicit. The source can be perused here..

<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fkingsmountain.com%2fdoc%2fdiff%2fDiff--draft-ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04c.txt.html&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cd9470b33b761437b197808d3424a7ad4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Tc64d3fInNkVKxQRnGiArlnXAoD9xta5bntjHVLGk9U%3d>

HTH,

=JeffH

---

From: =JeffH <[email-masked]>
Date: Wed, 2 Mar 2016 14:09:39 -0800

bottom-posted..

Andrei replied:
 > It is a good idea to clarify which EKM is signed

agreed, thx.

 > in each leg of the
 > federation scenario. I believe this will be a better fit in the HTTPSTB
 > draft, which talks about all things federation.

hm, I don't think that's the way to go for various reasons, e.g., 
-tokbind-protocol (aka TBPROTO)..

1. defines TokenBindingType (provided and referred),

2. specifies the signature-over-EKM(s) mechanism.

Plus, HTTPSTB (aka -tokbind-https) is HTTP-specific. If some other app 
protocol (eg SIP?) that layers over TLS leverages TokBind and has need for 
using referred_token_binding, then everything they need to know ought to be 
contained in TBPROTO and TBNEGO -- they aren't necessarily going to pay 
attention to -tokbind-https.

addtionally, -tokbind-https does not specifically mention the signature 
mechanism used in the TokenBindingMessage, i.e., it doesn't mention EKMs 
(other than in the Security Cons).

plus, in the -tokbind-protocol context specifically, all "referred" seems to 
mean is that "this other 3d-party server said it is ok to reveal to you (the 
1st party server) my TBID for that other server and to prove to you my 
possession of the private key associated with said TBID" -- i.e. the fact 
that -tokbind-https uses this "referred" building block to accommodate 
issuance and consumption of bound "federated" security tokens at the HTTP 
layer does not mean that it, -tokbind-https, needs to get into the business 
of specifying which EKM is signed by whom per token binding type.

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.

HTH,

=JeffH

---

From: Andrei Popov <[email-masked]>
Date: Wed, 2 Mar 2016 23:09:29 +0000

> 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.

Cheers,

Andrei

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

bottom-posted..

On 03/01/2016 07:26 PM, =JeffH wrote:
 >
 > Nick wrote:
 >  > My understanding of referred token bindings is that the signature in the  >  > TokenBinding struct is over the same EKM value for all TokenBinding  >  > structs in the TokenBindingMessage. That is, when server A sends the  >  > Include-Referer-Token-Binding-ID and redirects to server B, the  >  > TokenBindingMessage sent to server B has a provided TokenBinding with  >  > the client's TokenBindingID for server B and a signature of the EKM for  >  > the connection to server B, and a referred TokenBinding with the  >  > client's TokenBindingID for server A and a signature of the EKM for the  >  > connection to server B. This way, server B can verify the signature for  >  > both keys (assuming server B supports the key parameter used for the  >  > referred TokenBinding).
 >
 >  > Correct, in order for a server to verify the binding, the signature has  >  > to be over the EKM of the TLS connection with this server. Such  >  > federation scenarios are described in detail in section 3.2 of HTTPSTB:
 >  > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-tokbind-https-02%23section-3.2&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cfb4447063a884020f67e08d342e7618e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=giVedbP8JSxV6Y8nqJDdzvJAL9SWZWXwix5hNKJcbBw%3d
 >
 > However, it seems the details wrt which EKM is signed for  > referred_token_bindings is not explicitly stated AFAICT in either  > -tokbind-https-02 or in -tokbind-protocol-04. Although some folks have  > obviously figured it out, it may be difficult for others (I spose I'm one of  > 'em).
 >
 > So, I"ve crafted up some modest mods to -tokbind-protocol-04 that make this  > stuff explicit. The source can be perused here..
 >
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fkingsmountain.com%2fdoc%2fdiff%2fDiff--draft-ietf-tokbind-protocol-04.txt--to--draft-ietf-tokbind-protocol-04c.txt.html&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cfb4447063a884020f67e08d342e7618e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j%2bPYmt7As39tA64CkXJ3hnLVYpi0h8rufJrNcXjF0vc%3d> 

agreed, thx.

HTH,

=JeffH