Subject: [Unbearable] Opaqueness of Token Binding ID

From: Dirk Balfanz <[email-masked]>
Date: Wed, 31 Aug 2016 17:54:09 +0000

Hi Andrei & the rest of the Unbearables,

in the FIDO (well, W3C webauthn) discussion the question came up whether
Token Binding IDs should be treated as opaque blobs in other protocols. In
particular, FIDO assertions are (in part) over Token Binding IDs.

I had originally spec'd this out as including a JWK representation of the
Token Binding key, as in:

// The FIDO signature is over this:
{
  "origin": "www.example.com",
  "challenge": "129843adj03948",
  "tokbind": {
    "kty":"EC",
    "crv":"P-256",
    "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8",
    "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4"
  }
}

The webauthn participants are pointing out that the latest Token Binding
spec says that other applications should use an opaque representation of
the Token Binding ID, as in:

// The FIDO signature is over this:
{
  "origin": "www.example.com",
  "challenge": "129843adj03948",
  "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..."
}

where the tokbind value would be the base64-enccoding of the
TokenBindingID, as specified in ietf-tokbind-protocol.

It seems to me that it is safer to explicitly surface the fact that the
Token Binding ID is a public key, and what kind of key it is, to other
applications, rather than asking them to string-compare two strings whose
semantics they don't understand.

I can't come up with a particular attack, since the Token Binding ID - just
like the JWK - is an unambiguous representation of they key. Furthermore,
since it is a canonical serialization, string comparison *should* be ok.

It seems strange, however, that the application (in this case webauthn)
shouldn't be aware of the precise semantics of the tokbind value in this
dictionary.

Any thoughts on this?

Dirk.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 18:00:55 +0000

TBPROTO currently says:
“Token Binding protocol implementations SHOULD make Token Binding IDs available to the application as opaque byte sequences.”

The reason is that a future TB version should be free to redefine the contents of the TB IDs, without breaking apps that rely on a certain TB ID structure.

Ø  It seems to me that it is safer to explicitly surface the fact that the Token Binding ID is a public key, and what kind of key it is, to other applications, rather than asking them to string-compare two strings whose semantics they don't understand.
Then the application would need to be aware of the TB version, and will likely need to be updated when we update the Token Binding protocol. We’ve already changed the contents/structure of TB IDs between drafts.

From: Dirk Balfanz [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 10:54 AM
To: Andrei Popov <[email-masked]>
Cc: Tokbind WG <[email-masked]>
Subject: Opaqueness of Token Binding ID

in the FIDO (well, W3C webauthn) discussion the question came up whether Token Binding IDs should be treated as opaque blobs in other protocols. In particular, FIDO assertions are (in part) over Token Binding IDs.

I had originally spec'd this out as including a JWK representation of the Token Binding key, as in:

  "origin": "www.example.com<http://www.example.com>",

The webauthn participants are pointing out that the latest Token Binding spec says that other applications should use an opaque representation of the Token Binding ID, as in:

// The FIDO signature is over this:
{
  "origin": "www.example.com<http://www.example.com>",
  "challenge": "129843adj03948",
  "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..."
}

where the tokbind value would be the base64-enccoding of the TokenBindingID, as specified in ietf-tokbind-protocol.

It seems to me that it is safer to explicitly surface the fact that the Token Binding ID is a public key, and what kind of key it is, to other applications, rather than asking them to string-compare two strings whose semantics they don't understand.

I can't come up with a particular attack, since the Token Binding ID - just like the JWK - is an unambiguous representation of they key. Furthermore, since it is a canonical serialization, string comparison *should* be ok.

It seems strange, however, that the application (in this case webauthn) shouldn't be aware of the precise semantics of the tokbind value in this dictionary.

Any thoughts on this?

Dirk.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 18:31:16 +0000

TBPROTO currently says:

From: Dirk Balfanz [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 10:54 AM
To: Andrei Popov <[email-masked]<mailto:[email-masked]>>
Cc: Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: Opaqueness of Token Binding ID

Any thoughts on this?

Dirk.

---

From: Bill Cox <[email-masked]>
Date: Wed, 31 Aug 2016 13:04:06 -0700

I prefer signing the version with the opaque TokenBindingID, though I think
the application should be able to inspect the key parameters.  This is easy
with the API I currently have.  All "encoded" key strings are actually
serialized TokenBindingIDs (not base-64 encoded), and I have an API to
extract the key type, which just returns *key.

The application should be aware of the key type, I think, in case some key
types are found to be insecure in the future.  So, it should not be
considered entirely opaque.  Maybe some applications need to do further
verification of these keys.  I provide a TokenBindingID -> EVP_PKEY API for
this.

Bill

On Wed, Aug 31, 2016 at 10:54 AM, Dirk Balfanz <[email-masked]> wrote:

> I can't come up with a particular attack, since the Token Binding ID -
> just like the JWK - is an unambiguous representation of they key.
> Furthermore, since it is a canonical serialization, string comparison
> *should* be ok.
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

---

From: John Bradley <[email-masked]>
Date: Wed, 31 Aug 2016 19:08:22 -0300

I personally think that for fido treating the token bindingID as opaque is the correct thing.  It will keep the fido clients from breaking when new token binding algs are added.

If the server wants to introspect the key for some reason it can do that, but in general they should be opaque.

John B.

> On Aug 31, 2016, at 2:54 PM, Dirk Balfanz <[email-masked]> wrote:
> 
>   "origin": "www.example.com <http://www.example.com/>",
>   "origin": "www.example.com <http://www.example.com/>",

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 31 Aug 2016 22:20:48 +0000

The Token Binding Key does not have to be the Token Binding ID

From: Unbearable [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, August 31, 2016 3:08 PM
To: Dirk Balfanz <[email-masked]>
Cc: Andrei Popov <[email-masked]>; Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Opaqueness of Token Binding ID

John B.

On Aug 31, 2016, at 2:54 PM, Dirk Balfanz <[email-masked]<mailto:[email-masked]>> wrote:

  "origin": "www.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.example.com%2f&data=01%7c01%7ctonynad%40microsoft.com%7cdcf54e9a957344c6068808d3d1eb5e71%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Mw8Qu0riBTuPXWDT3%2fYgqa9SPucijVaWGe4yPbsT28s%3d>",

// The FIDO signature is over this:
{
  "origin": "www.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.example.com%2f&data=01%7c01%7ctonynad%40microsoft.com%7cdcf54e9a957344c6068808d3d1eb5e71%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Mw8Qu0riBTuPXWDT3%2fYgqa9SPucijVaWGe4yPbsT28s%3d>",
  "challenge": "129843adj03948",
  "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..."
}

Any thoughts on this?

Dirk.

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

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 22:21:16 +0000

+1, to avoid coupling of apps to TB versions.

From: John Bradley [mailto:[email-masked]]

John B.

  "origin": "www.example.com<http://www.example.com/>",

// The FIDO signature is over this:
{
  "origin": "www.example.com<http://www.example.com/>",
  "challenge": "129843adj03948",
  "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..."
}

Any thoughts on this?

Dirk.

---

From: Dirk Balfanz <[email-masked]>
Date: Thu, 01 Sep 2016 06:25:47 +0000

On Wed, Aug 31, 2016 at 3:08 PM John Bradley <[email-masked]> wrote:

> I personally think that for fido treating the token bindingID as opaque is
> the correct thing.  It will keep the fido clients from breaking when new
> token binding algs are added.
>

But isn't the flip side of that coin "it will keep fido clients from
noticing when an attacker does a version rollback attack on them" ... or
something like that. Again, I'm not quite sure what the attack would be.

> but in general they should be opaque.

Yeah - I think I'm being overly paranoid here. The "opaque" version has
literally the same information in it as the JWK version - it's there for
clients who care.

If everybody else feels comfortable telling consumers of FIDO assertions
"just compare the strings, it'll be ok", then I'll shut up. :-)

Dirk.