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

From: [email-masked]
Date: Mon, 29 Feb 2016 14:57:28 -0700

Hi,

The  last paragraph of -tokbind-protocol-04 section 4 [1] begins with..

   If the Token Binding message does not contain at least one
   TokenBinding structure, or the signature contained in a
   TokenBinding structure is invalid, the server MUST terminate
   the connection.

..however, if the Token Binding Message received from the client, over
"this" TLS session, contains TokenBinding structure(s) with..

  TokenBinding.tokenbinding_type == referred_token_binding

..(as well as provided_token_binding types), then the server will not be
able to verify the signature(s) within those "referred" TokenBinding
struct(s) because the server would obtain an Exported Keying Material
(EKM) [RFC5705] value from the TLS stack that is different from the EKM
value used when the referred_token_binding TokenBinding struct was created
by the client, but with a different server over a different TLS session 
-- yes ?   Or am I misunderstanding how [RFC5705] works?

thanks,

=JeffH

[1] <https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04#section-4>

---

From: Nick Harper <[email-masked]>
Date: Mon, 29 Feb 2016 14:27:07 -0800

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

On Mon, Feb 29, 2016 at 1:57 PM, <[email-masked]> wrote:

> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Bill Cox <[email-masked]>
Date: Mon, 29 Feb 2016 14:59:17 -0800

> (assuming server B supports the key parameter used for the referred

That's my understanding as well.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Tue, 1 Mar 2016 01:40:33 +0000

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

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Monday, February 29, 2016 2:59 PM
To: Nick Harper <[email-masked]>
Cc: Tokbind WG <[email-masked]>; Jeff Hodges <[email-masked]>
Subject: Re: [Unbearable] -tokbind-protocol-04: verifying signature(s) in TokenBindingMessage.TokenBinding?

On Mon, Feb 29, 2016 at 2:27 PM, Nick Harper <[email-masked]<mailto:[email-masked]>> 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).

Bill