Subject: [Uta] Understanding Token Binding

From: Watson Ladd <[email-masked]>
Date: Wed, 5 Nov 2014 21:48:53 -0800

Dear all,

I want to make sure I understand the big picture of Token Binding and
why it works the way it does: in particular, it replaces the TLS
client authentication mechanism with a new one.

Token binding, as I understand it, involves the client generating a
separate certificate for each endpoint. But this certificate is not
used in the normal client authentication protocol. Instead it's used
to sign a tls_unique channel binding value.

This certificate isn't used for client authentication. Instead the
server filters out provided tokens using the token binding ID.

This is different from what appears on Browser-Auth.net in two ways:
the existing TLS client authentication mechanism isn't used, and the
application layer/TLS interaction is new: the TLS implementation must
fish out a signed value represented as application data, or export the
tls_unique binding to let the application verify the binding. This is
underspecified in the draft, which may be okay. (Also underspecified:
referred token bindings)

One part missing is specifying how to do RSA signatures. Is it PSS or
PKCS 1.5? I hope it's PSS.

I don't see any obvious security problems, and I can see some real
deployment advantages: certificate privacy is preserved without
renegotiation, and this works just like cookies for the web app
developer, assuming there is enough work done by the web server. The
UI advantage is not trivial.

However, what was wrong with OBC which reused existing TLS
authentication mechanisms? Is this something we can fix in TLS 1.3, or
not?

Sincerely,
Watson Ladd

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 6 Nov 2014 14:54:11 +0200

> client authentication mechanism with a new one.

It does not replace TLS client authentication.

> UI advantage is not trivial.

I do see obvious security problems, but those problems already exist
and this does not make those problems any worse.

> authentication mechanisms? Is this something we can fix in TLS 1.3, or

IIRC, wanting to leave the existing TLS auth "field" to other
purposes (I don't recall exact reasons, I think those were covered in
some IETF meeting).

Also, on use of ALPN: Stuff like this (combined with some other
proposals) is exactly what I had in mind when I said that using ALPN
for feature negotiation does not scale.

-Ilari

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 06 Nov 2014 10:14:39 -0800

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
Sent: Thursday, November 06, 2014 4:54 AM
To: Watson Ladd
Cc: [email-masked]
Subject: Re: [Uta] Understanding Token Binding

It does not replace TLS client authentication.
[TF] The answer of whether token binding replaces client authentication is
more dependent on the role of the site. One of the objectives of  token
authentication protocols such as oauth and SAML is to abstract the
authentication technology used with the identity provider from the relying
party. An identity provider can use whatever authentication technology it
chooses (including TLS client authentication) and then issues a token to the
client which is then presented to the relying party.  Hitherto, the only
forms of tokens widely used were Bearer Tokens where possession of the token
authenticates the user. Bearer tokens have no cryptographic binding between
the token and the TLS session with the relying party so there is no
cryptographic proof of the absence of a MITM. This draft allows holder of
key tokens to be use used where there is cryptographic proof of the absence
of a MITM.
TLS client authentication is typically used by relying parties today in high
assurance situations where they need strong MITM resistance became there was
no alternative. This draft will allow relying parties to use a common apache
to all authentication. Which will result in a more consistent user
experience. 

> UI advantage is not trivial.

I do see obvious security problems, but those problems already exist and
this does not make those problems any worse.

> authentication mechanisms? Is this something we can fix in TLS 1.3, or 

IIRC, wanting to leave the existing TLS auth "field" to other purposes (I
don't recall exact reasons, I think those were covered in some IETF
meeting).

Also, on use of ALPN: Stuff like this (combined with some other
proposals) is exactly what I had in mind when I said that using ALPN for
feature negotiation does not scale.

-Ilari

_______________________________________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uta

---

From: Adam Langley <[email-masked]>
Date: Thu, 6 Nov 2014 11:05:52 -0800

> underspecified in the draft, which may be okay. (Also underspecified:

(Assuming that we're talking about ChannelID and it's successors.)

It's based on tls_unique and the extended master secret fix will be required.

> PKCS 1.5? I hope it's PSS.

It's ECDSA at the moment. There's talk of supporting RSA signatures
and, if we do that, I very much hope that it'll be PSS.

> authentication mechanisms? Is this something we can fix in TLS 1.3, or

TLS client auth is in the clear and renegotiation sucks, thus OBC was born.

Around then SPDY was also happening and SPDY can merge several
eTLD+1's on the same connection, but there's only one TLS handshake
and thus one OBD.

So there was a SPDY CREDENTIAL frame added: the client manages a
conceptual array of signatures at the server. It can set elements of
the array to public keys with CREDENTIAL messages by signing
tls-unique. Each request indicates which public key in the array it's
linked with.

But there was a lull in OBC work and SPDY was growing up from being a
Google-internal experiment so CREDENTIAL was dropped.

Having both OBC and CREDENTIAL was overly complex but it was thought
that many applications wouldn't care about SPDY connection pooling and
would want token binding handled at the lower levels of the software
stack, so we simplified lots and ended up with ChannelID:
https://tools.ietf.org/html/draft-balfanz-tls-channelid-01. ChannelID
is like OBC but doesn't take the client-auth slot (which people wanted
for other things) and doesn't involve a dummy X.509 certificate.
That's live in Chrome at the moment.

Now it looking like it really is better to have it just at a higher
level and you end up with something like the current token binding
drafts.

Cheers

AGL

---

From: Andrei Popov <[email-masked]>
Date: Thu, 6 Nov 2014 19:14:54 +0000

Hi Watson,

> I want to make sure I understand the big picture of Token Binding and why it works the way it does: in particular, it replaces the TLS client authentication mechanism with a new one.
Client authentication occurs outside the Token Binding protocol. Client authentication often results in a token being issued to the client by the server. The Token Binding protocol helps prevent the export and replay of this token.

> Token binding, as I understand it, involves the client generating a separate certificate for each endpoint. But this certificate is not used in the normal client authentication protocol. Instead it's used to sign a tls_unique channel binding value.
Token Binding uses a private/public key pair, without issuer, subject, or the numerous other attributes of a certificate.

> This certificate isn't used for client authentication. Instead the server filters out provided tokens using the token binding ID.
Correct, the Token Binding Key is not used for client authentication. The server receiving a bound token can ensure that the sender of this token is in possession of the private Token Binding key. Which means that stealing a token is not sufficient to impersonate the client; the attacker would also have to extract the Token Binding key (which is supposed to be strongly protected, e.g. HW-bound).

> ... the TLS implementation must fish out a signed value represented as application data, or export the tls_unique binding to let the application verify the binding.
In my opinion, the TLS implementation should not be parsing application data, so export of the TLS_UNIQUE would IMHO be the right approach. This is, however, an implementation choice.

> Also underspecified: referred token bindings
The Token Binding Protocol I-D references a companion HTTPS Token Binding I-D (http://tools.ietf.org/html/draft-balfanz-https-token-binding-00), which talks about Federation use cases involving referred token bindings (please see section 3).

> One part missing is specifying how to do RSA signatures. Is it PSS or PKCS 1.5? I hope it's PSS.
Yes, we'll need to address this in the next revision of the I-D.

> However, what was wrong with OBC which reused existing TLS authentication mechanisms? Is this something we can fix in TLS 1.3, or not?
The Token Binding protocol is designed to function at the application layer and does not require any TLS changes (apart from fixing the triple-handshake vulnerability). This also means that, if needed, Token Binding could be made to work with security protocols other than TLS.

Cheers,

Andrei

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Wednesday, November 5, 2014 9:49 PM
To: [email-masked]
Subject: [Uta] Understanding Token Binding

Dear all,

I want to make sure I understand the big picture of Token Binding and why it works the way it does: in particular, it replaces the TLS client authentication mechanism with a new one.

Token binding, as I understand it, involves the client generating a separate certificate for each endpoint. But this certificate is not used in the normal client authentication protocol. Instead it's used to sign a tls_unique channel binding value.

This certificate isn't used for client authentication. Instead the server filters out provided tokens using the token binding ID.

This is different from what appears on Browser-Auth.net in two ways:
the existing TLS client authentication mechanism isn't used, and the application layer/TLS interaction is new: the TLS implementation must fish out a signed value represented as application data, or export the tls_unique binding to let the application verify the binding. This is underspecified in the draft, which may be okay. (Also underspecified:
referred token bindings)

One part missing is specifying how to do RSA signatures. Is it PSS or PKCS 1.5? I hope it's PSS.

I don't see any obvious security problems, and I can see some real deployment advantages: certificate privacy is preserved without renegotiation, and this works just like cookies for the web app developer, assuming there is enough work done by the web server. The UI advantage is not trivial.

However, what was wrong with OBC which reused existing TLS authentication mechanisms? Is this something we can fix in TLS 1.3, or not?

Sincerely,
Watson Ladd

---

From: Andrei Popov <[email-masked]>
Date: Thu, 6 Nov 2014 19:28:00 +0000

> Also, on use of ALPN: Stuff like this (combined with some other proposals) is exactly what I had in mind when I said that using ALPN for feature negotiation does not scale.
True, this is less than ideal today, and will be more of an issue in the future if there is interest in supporting Token Binding with more application protocols, and/or more key types. The TLS WG could then define ALPN/2 with structured IDs, but this feels like a separate discussion. Some other application protocols, as well as Token Binding, could benefit from structured ALPN IDs, but on the other hand negotiating application parameters within the TLS handshake has its architectural drawbacks.

Cheers,

Andrei

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
Sent: Thursday, November 6, 2014 4:54 AM
To: Watson Ladd
Cc: [email-masked]
Subject: Re: [Uta] Understanding Token Binding

> UI advantage is not trivial.

I do see obvious security problems, but those problems already exist and this does not make those problems any worse.

> authentication mechanisms? Is this something we can fix in TLS 1.3, or 

IIRC, wanting to leave the existing TLS auth "field" to other purposes (I don't recall exact reasons, I think those were covered in some IETF meeting).

Also, on use of ALPN: Stuff like this (combined with some other
proposals) is exactly what I had in mind when I said that using ALPN for feature negotiation does not scale.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Thu, 6 Nov 2014 21:03:16 -0800

> True, this is less than ideal today, and will be more of an issue in the future if there is interest in supporting Token Binding with more application protocols, and/or more key types. The TLS WG c…

Thanks to AGL and Andrei for filling me in. I just realized that this
design is incompatible with 0-RTT, unless we define some sort of
unique binding that isn't that comes from the 0-RTT trip (say whatever
is used to prevent replays) But now a client needs to recompute the
Token Binding when the 0-RTT handshake fails. Or are we willing to eat
the latency here?

I'm still thinking hard about this whole subject: I can see some
potential security issues involving repeated parsing of bound tokens.

Sincerely,
Watson ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin