Subject: [Unbearable] Should Token Binding support non-TLS applications?

From: Bill Cox <[email-masked]>
Date: Fri, 18 Sep 2015 09:26:12 -0700

There are often valid reasons to avoid TLS and go with something lighter
weight.  Should we make it a goal to support Token Binding in these
applications?

Token Binding uses a TLS extension to negotiate key parameters, but a
simple application could choose these as fixed parameters for both client
and server.  We sign the tls_unique_long, but the application could have
it's own connection-bound key exporter.  It's just a 256 bit opaque value
to us.  Is there any good reason not to structure the code to enable Token
Binding for non-TLS applications?

Thanks,
Bill

---

From: Pranav Kukreja <[email-masked]>
Date: Fri, 18 Sep 2015 16:45:03 +0000

Bill,

I work with Andrei at Microsoft on this feature, and having implemented the API's we have designed it such that client server applications can indeed use it the way you have described, for non tls applications. The keying material should be an any size blob parameter to the create binding routine. Same goes for the verification on the server side.

Thanks
Pranav

Sent from my ASUS

-------- Original Message --------
From:Bill Cox
Sent:Fri, 18 Sep 2015 09:26:31 -0700
To:[email-masked]
Subject:[Unbearable] Should Token Binding support non-TLS applications?

There are often valid reasons to avoid TLS and go with something lighter weight.  Should we make it a goal to support Token Binding in these applications?

Token Binding uses a TLS extension to negotiate key parameters, but a simple application could choose these as fixed parameters for both client and server.  We sign the tls_unique_long, but the application could have it's own connection-bound key exporter.  It's just a 256 bit opaque value to us.  Is there any good reason not to structure the code to enable Token Binding for non-TLS applications?

Thanks,
Bill

---

From: Bill Cox <[email-masked]>
Date: Fri, 18 Sep 2015 09:50:07 -0700

Sounds good.  While the Token Binding Protocol spec specifically describes
the use with TLS, we'll keep it generic so it can be use for non-TLS as
well.

Thanks,
Bill

On Fri, Sep 18, 2015 at 9:45 AM, Pranav Kukreja <[email-masked]>
wrote:

> Bill,
>
> I work with Andrei at Microsoft on this feature, and having implemented
> the API's we have designed it such that client server applications can
> indeed use it the way you have described, for non tls applications. The
> keying material should be an any size blob parameter to the create binding
> routine. Same goes for the verification on the server side.
>
> Thanks
> Pranav
>
> Sent from my ASUS
>
>

---

From: Watson Ladd <[email-masked]>
Date: Fri, 18 Sep 2015 13:00:36 -0400

On Sep 18, 2015 12:50 PM, "Bill Cox" <[email-masked]> wrote:
>
> Sounds good.  While the Token Binding Protocol spec specifically
describes the use with TLS, we'll keep it generic so it can be use for
non-TLS as well.

There are significant security issues involved with this idea. User
authentication keys must be used with only one lower level protocol.

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

---

From: Andrei Popov <[email-masked]>
Date: Fri, 18 Sep 2015 17:06:27 +0000

Ø  Is there any good reason not to structure the code to enable Token Binding for non-TLS applications?
As Pranav says, no good reason. E.g. our Token Binding implementation is separate from our TLS implementation and could be used with security protocols other than TLS and application protocols other than HTTP.

Ø  Should we make it a goal to support Token Binding in these applications?
I don't think it's an immediate goal of this WG to define the use of Token Binding with protocols other than TLS and HTTP, but the design should not prevent this.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Pranav Kukreja
Sent: Friday, September 18, 2015 9:45 AM
To: Bill Cox <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] Should Token Binding support non-TLS applications?

Bill,

Thanks
Pranav

Sent from my ASUS

-------- Original Message --------
From:Bill Cox

Thanks,
Bill

---

From: Nick Harper <[email-masked]>
Date: Fri, 18 Sep 2015 10:50:45 -0700

I've been working with the QUIC team at Google and AGL to define a Token
Binding negotiation protocol for QUIC, as well as a "quic-unique" (this was
before the tbproto spec was changed to use EKM).

On Fri, Sep 18, 2015 at 10:06 AM, Andrei Popov <[email-masked]>
wrote:

> As Pranav says, no good reason. E.g. our Token Binding implementation is
> separate from our TLS implementation and could be used with security
> protocols other than TLS and application protocols other than HTTP.
>
>
>
> I don’t think it’s an immediate goal of this WG to define the use of Token
> Binding with protocols other than TLS and HTTP, but the design should not
> prevent this.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Pranav
> Kukreja
> *Sent:* Friday, September 18, 2015 9:45 AM
> *To:* Bill Cox <[email-masked]>; [email-masked]
> *Subject:* Re: [Unbearable] Should Token Binding support non-TLS
> applications?
>
>
>
> Bill,
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 18 Sep 2015 21:01:15 +0300

> authentication keys must be used with only one lower level protocol.

Putting in a signature prefix[1] and having different ones for
different lower level protocols is not enough?

[1] -01 had that, it was apparently removed in -02.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Fri, 18 Sep 2015 18:11:19 +0000

-02 still has the label; it's part of the EKM definition: 

" The EKM is obtained using the Keying Material Exporters for TLS
   defined in [RFC5705], by supplying the following input values:

   o  Label: The ASCII string "EXPORTER-Token-Binding" with no
      terminating NUL.
   o  Context value: NULL (no application context supplied).
   o  Length: 32 bytes."

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
Sent: Friday, September 18, 2015 11:01 AM
To: Watson Ladd <[email-masked]>
Cc: Pranav Kukreja <[email-masked]>; [email-masked]; Bill Cox <[email-masked]>
Subject: Re: [Unbearable] Should Token Binding support non-TLS applications?

On Fri, Sep 18, 2015 at 01:00:36PM -0400, Watson Ladd wrote:
> > describes the use with TLS, we'll keep it generic so it can be use 
> > for non-TLS as well.
> 

Putting in a signature prefix[1] and having different ones for different lower level protocols is not enough?

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Fri, 18 Sep 2015 14:13:55 -0400

>    o  Context value: NULL (no application context supplied).

Why can't some other protocol produce it's token binding in a way that
interacts badly with this one?

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 18 Sep 2015 21:21:22 +0300

>    o  Context value: NULL (no application context supplied).

The prefix would have to be prefixed to the EKM value to ensure
different protocol won't produce something that interacts badly.

AFAICT, such prefix existed in -01, but not -02.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Fri, 18 Sep 2015 18:35:27 +0000

-01 prepends the ASCII string "token binding" to the TLS_UNIQUE.
-02 mixes in ASCII string "EXPORTER-Token-Binding" as part of the EKM definition.

In both versions of the spec, the labels serve to distinguish the use of the TLS-exported material for TB purposes from any other uses of the same exported material.
Neither spec distinguishes the use of TB with HTTP from the use of TB with, say, SMTP.

Are you suggesting that we also mix in the string "HTTP" when TB is used with HTTP?

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
Sent: Friday, September 18, 2015 11:21 AM
To: Andrei Popov <[email-masked]>
Cc: Watson Ladd <[email-masked]>; [email-masked]; Bill Cox <[email-masked]>; Pranav Kukreja <[email-masked]>
Subject: Re: [Unbearable] Should Token Binding support non-TLS applications?

>    o  Context value: NULL (no application context supplied).

The prefix would have to be prefixed to the EKM value to ensure different protocol won't produce something that interacts badly.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 18 Sep 2015 21:57:36 +0300

> -02 mixes in ASCII string "EXPORTER-Token-Binding" as part of the EKM

What -02 does is not enough if non-TLS transports (e.g. QUIC?) are
allowed with the same keys as used by TLS.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Fri, 18 Sep 2015 19:05:30 +0000

QUIC's use of TB will require a separate specification with their own TB parameters negotiation mechanism, and their own binding method (analogous to EKM for TLS).

I thought that when the TB WG reviews this new specification, we would make sure that the new binding method is adequate and does not “interact badly” (e.g. the new QUIC binding is generated using a distinct label).

But if you're thinking of a better way to deal with this, please suggest.

-----Original Message-----
From: Ilari Liusvaara [mailto:[email-masked]] 
Sent: Friday, September 18, 2015 11:58 AM
To: Andrei Popov <[email-masked]>
Cc: Watson Ladd <[email-masked]>; [email-masked]; Bill Cox <[email-masked]>; Pranav Kukreja <[email-masked]>
Subject: Re: [Unbearable] Should Token Binding support non-TLS applications?

> -02 mixes in ASCII string "EXPORTER-Token-Binding" as part of the EKM 

What -02 does is not enough if non-TLS transports (e.g. QUIC?) are allowed with the same keys as used by TLS.

-Ilari