Subject: [Unbearable] referred token binding and unknown key_parameters

From: Brian Campbell <[email-masked]>
Date: Fri, 5 Aug 2016 13:44:47 -0600

The way that TokenBindingID and TokenBindingKeyParameters are
structured in TBPROTO
§3 <https://tools.ietf.org/html/draft-ietf-tokbind-protocol-08#section-3>
would seem to mean that a system processing a TokenBindingMessage would be
unable to proceed if it encountered a key_parameters that it didn't
understand.

This should never be a problem with the provided TB because the
key_parameters are negotiated in the handshake.

However, the referred TB isn't negotiated with the token provider and so
might contain a TokenBindingID that the token provider doesn't know how to
parse. For example, say a new EdDSA TokenBindingKeyParameters is defined in
the future, which a browser and relying party / token consumer web site
support before an identity / token provider. A federated flow with the
Include-Referred-Token-Binding-ID header would result in the new new EdDSA
TokenBindingKeyParameters being sent to the identity / token provider as
the referred token binding, which would make the TokenBindingMessage
(nearly) impossible to process because it doesn't know the structure or
length of the new token binding ID.

Would it make sense to have TokenBindingID/TokenBindingKeyParameters
defined more like TLS hello extensions where the type and length are
available in the front of the structure in a consistent way? That would
allow for processors of TokenBindingMessages to skip over TokenBindingIDs
that aren't understood.
<https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-4.4>

---

From: Andrei Popov <[email-masked]>
Date: Sun, 7 Aug 2016 17:15:52 +0000

Yes, it may be a good idea to do something like this:

     struct {
         TokenBindingKeyParameters key_parameters;
         opaque TokenBindingID_data<1..2^16-1>;
         }
     } TokenBindingID;

Where TokenBindingID_data is RSAPublicKey, ECPoint or something else, depending on the key_parameters. This adds a couple of bytes, but makes the entire TokenBinding skippable.

Do you mind opening a GitHub issue, so that we don’t forget about this?

Thanks,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, August 5, 2016 12:45 PM
To: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] referred token binding and unknown key_parameters

The way that TokenBindingID and TokenBindingKeyParameters are structured in TBPROTO §3<https://tools.ietf.org/html/draft-ietf-tokbind-protocol-08#section-3> would seem to mean that a system processing a TokenBindingMessage would be unable to proceed if it encountered a key_parameters that it didn't understand.
This should never be a problem with the provided TB because the key_parameters are negotiated in the handshake.
However, the referred TB isn't negotiated with the token provider and so might contain a TokenBindingID that the token provider doesn't know how to parse. For example, say a new EdDSA TokenBindingKeyParameters is defined in the future, which a browser and relying party / token consumer web site support before an identity / token provider. A federated flow with the Include-Referred-Token-Binding-ID header would result in the new new EdDSA TokenBindingKeyParameters being sent to the identity / token provider as the referred token binding, which would make the TokenBindingMessage (nearly) impossible to process because it doesn't know the structure or length of the new token binding ID.
Would it make sense to have TokenBindingID/TokenBindingKeyParameters defined more like TLS hello extensions where the type and length are available in the front of the structure in a consistent way? That would allow for processors of TokenBindingMessages to skip over TokenBindingIDs that aren't understood.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 17:53:54 +1000

> Do you mind opening a GitHub issue, so that we don’t forget about this?

I independently opened #61.

(Apologies to Andrei and Brian, but gmail has decided that all
microsoft.com and pingidentity.com email on lists are spam.  I missed
these emails.)

---

From: Brian Campbell <[email-masked]>
Date: Mon, 8 Aug 2016 10:09:27 -0600

With #61 <https://github.com/TokenBinding/Internet-Drafts/issues/61>,
Martin beat me to opening an issue.

Adding the two extra bytes is unfortunate but will save some pain down the
road so is worth it, I think.

Given the static size nature ecdsap256, we could reclaim one of those bytes
for that ID by using fixed-length vector(s) to define what's in
TokenBindingID_data for that type. Something like:

  struct {
         opaque x [32];
         opaque y [32];
  } ECTokenBindingID_data;

or

  struct {
         opaque point [64];
  } ECTokenBindingID_data;

Just a thought anyway. Don't know if that's better or worse or worth doing
for one byte.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Aug 2016 09:10:02 +1000

> Just a thought anyway. Don't know if that's better or worse or worth doing

Note that I also opened #62, which suggests spending an extra byte.

https://github.com/TokenBinding/Internet-Drafts/issues/62

---

From: Brian Campbell <[email-masked]>
Date: Tue, 9 Aug 2016 13:03:58 -0600

With respect to #62, as mentioned in a comment, I don't think there's value
in that extra byte.