Subject: Re: [Unbearable] Opaqueness of Token Binding ID

From: Andrei Popov <[email-masked]>
Date: Thu, 1 Sep 2016 16:54:25 +0000

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

I think we should be preventing version downgrade attacks at the protocol level, and not rely on applications for this…

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

On Wed, Aug 31, 2016 at 3:08 PM John Bradley <[email-masked]<mailto:[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.

If the server wants to introspect the key for some reason it can do that, 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.

John B.

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

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<http://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<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.

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

---

From: John Bradley <[email-masked]>
Date: Thu, 1 Sep 2016 14:03:12 -0300

There is no TB version info in ether version.  

If Fido wants to prevent downgrade attacks on Token binding, you want the server receiving the fido attestation to get the additional information from the token binding layer directly.
There is probably a useful discussion to be had about what token binding API expose to the fido application on the server.   Should it expose version key and alg info?

I think trying to put that in the object that the Fido device is signing will make it too brittle if the Fido client needs to do anything other than sign a blob.

John B.
> On Sep 1, 2016, at 1:54 PM, Andrei Popov <[email-masked]> wrote:
> 
> On Wed, Aug 31, 2016 at 3:08 PM John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> On Aug 31, 2016, at 2:54 PM, Dirk Balfanz <[email-masked] <mailto:[email-masked]>> wrote:
>  
>   "origin": "www.example.com <http://www.example.com/>",
>   "origin": "www.example.com <http://www.example.com/>",
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 1 Sep 2016 22:09:50 -0400 (EDT)

Yes, making things as simple as possible for applications (read: hard to
screw up) seems like a good idea.

-Ben

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 02 Sep 2016 07:24:18 +0000

Ok, thanks everybody for your input. I'll recommend to the webauthn WG to
just use the opaque representation.

Dirk.

On Thu, Sep 1, 2016 at 7:10 PM Benjamin Kaduk <[email-masked]> wrote:

> > Ø  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.
> >
> > I think we should be preventing version downgrade attacks at the
> protocol level, and not rely on applications for this…
> >
> > 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.
> >
> > If the server wants to introspect the key for some reason it can do
> that, 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.
> >
> >
> >
> > John B.
> >
> > 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.
> >
> > 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:
> >
> > 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.
> >
> [email-masked]