Subject: [Unbearable] moving ahead

From: Stephen Farrell <[email-masked]>
Date: Sat, 24 Jan 2015 23:34:19 +0000

Hiya,

Andrei has asked me about next steps for this work, based on the
draft charter text at [1].

I think that text is pretty good, but before I start the formal
WG chartering process I wanted to check here that there aren't
major problems with it.

Two things I noted myself were that it'd be good to see some
support from server implementers who are not also browser makers.
And secondly, we probably need to talk to W3C about this too,
as [2] seems to need changes to XHR, which is their spec. [3]
Both of those could however be taken care of as we go forward.

I did see Hannes' issue about TLS endpoint location and OAuth
and those are issues that need to be addressed but that I think
should be done in a WG.

So can folks who have new argument as to why this work is wrong,
or definitely needs a BoF or with other new substantive comments
please post those in the next few days. Or if you previously
posted a substantive comment that was not addressed (noting that
addressed != accepted) please post a link to that thread.

I'll look at what comes up and if there is nothing new I'll
probably start the WG chartering process around mid-week.
(To be clear: at present I don't think this one needs a BoF
in March, but could be a chartered WG before then.)

Cheers,
S.

PS: As a process thing, if we're moving ahead here, this will
appear as a place-holder in the BoF list for March so we can
schedule a session for the WG, if that is formed, or else use
that session for a BoF if one turns out to be needed.

[1]
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt
[2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
[3] http://www.w3.org/TR/XMLHttpRequest/

---

From: Bill Mills <[email-masked]>
Date: Sun, 25 Jan 2015 01:02:50 +0000 (UTC)

I think the current text of the charter is not descriptive of what this WG is really trying to solve.  It reads as though this is about TLS channel binding which is wrong.  I'd like to see that fixed in the language of the charter to be clearer.
There was a thread recently on what the elevator pitch for this is, and I think language similar to that shoudl be in the first paragraph. 

     On Saturday, January 24, 2015 3:34 PM, Stephen Farrell <[email-masked]> wrote:

Hiya,

Cheers,
S.

[1]

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 25 Jan 2015 01:48:17 +0000

Hi Bill,

If you can send proposed text that'd be great. Absent that,
to be honest, I'm not sure what change you'd like,

Cheers,
S.

On 25/01/15 01:02, Bill Mills wrote:
> I think the current text of the charter is not descriptive of what
> this WG is really trying to solve.  It reads as though this is about
> TLS channel binding which is wrong.  I'd like to see that fixed in
> the language of the charter to be clearer. There was a thread
> recently on what the elevator pitch for this is, and I think language
> similar to that shoudl be in the first paragraph.
> 
> I think that text is pretty good, but before I start the formal WG
> chartering process I wanted to check here that there aren't major
> problems with it.
> 
> Two things I noted myself were that it'd be good to see some support
> from server implementers who are not also browser makers. And
> secondly, we probably need to talk to W3C about this too, as [2]
> seems to need changes to XHR, which is their spec. [3] Both of those
> could however be taken care of as we go forward.
> 
> I did see Hannes' issue about TLS endpoint location and OAuth and
> those are issues that need to be addressed but that I think should be
> done in a WG.
> 
> So can folks who have new argument as to why this work is wrong, or
> definitely needs a BoF or with other new substantive comments please
> post those in the next few days. Or if you previously posted a
> substantive comment that was not addressed (noting that addressed !=
> accepted) please post a link to that thread.
> 
> I'll look at what comes up and if there is nothing new I'll probably
> start the WG chartering process around mid-week. (To be clear: at
> present I don't think this one needs a BoF in March, but could be a
> chartered WG before then.)
> 
> Cheers, S.
> 
> PS: As a process thing, if we're moving ahead here, this will appear
> as a place-holder in the BoF list for March so we can schedule a
> session for the WG, if that is formed, or else use that session for a
> BoF if one turns out to be needed.
> 
> 
> [1] 
> _______________________________________________ Unbearable mailing
> list [email-masked] 
> _______________________________________________ Unbearable mailing
> list [email-masked]

---

From: Bill Mills <[email-masked]>
Date: Sun, 25 Jan 2015 02:15:57 +0000 (UTC)

>From my "elevator pitch" question in the other thread, "Clients (browsers) being able to tie credentials to locally generated and managed keys and assert that key to the auth service.".  To extend that I think it should be something like:
"Clients (browsers) being able to tie credentials to locally generated and managed keys and assert that key to the auth service.  Those keys are used for signing transaction when accessing a protected resource via TLS.".  

     On Saturday, January 24, 2015 5:48 PM, Stephen Farrell <[email-masked]> wrote:

Hi Bill,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Jan 2015 16:53:35 +0000

Hi Bill,

Ok, so now I get the addition you're requesting.

On 25/01/15 02:15, Bill Mills wrote:
> From my "elevator pitch" question in the other thread, "Clients
> (browsers) being able to tie credentials to locally generated and
> managed keys and assert that key to the auth service.".  #

I note that that text does not occur in the current draft. [1]
But I also know what you mean so moving on...

> To extend that I think it should be something like:

> "Clients (browsers) being able to tie credentials to locally
> generated and managed keys and assert that key to the auth service.
> Those keys are used for signing transaction when accessing a
> protected resource via TLS.".

Are you asking that this work be extended so as to define
a general method for producing digital signatures on application
layer objects with the private key that is needed for moving
away from bearer tokens? (Assuming a digital signature based
way of doing better than bearer tokens, which is a reasonable
assumption.)

If so, that seems like a major extension of scope and I'd be
interested in whether or not folks support that idea. And I'd
be opposed myself FWIW - too many pitfalls. A general thing
like that might be a good follow on but in a separate WG I'd
argue.

If not, and you mean something less broad, then I think it'd
be better if you could try again and please provide a specific
charter language suggestion that only covers the narrower
scope of work you mean. And then we can see if folks like
the idea. In that case, please use OLD/NEW form to describe
the changes to [1] that you propose.

Thanks,
S.

[1]

Thanks,
S.

> If you can send proposed text that'd be great. Absent that, to be
> honest, I'm not sure what change you'd like,
> 
> Cheers, S.
> 
>> this WG is really trying to solve.  It reads as though this is
>> about TLS channel binding which is wrong.  I'd like to see that
>> fixed in the language of the charter to be clearer. There was a
>> thread recently on what the elevator pitch for this is, and I think
>> language similar to that shoudl be in the first paragraph.
>> 
>> And secondly, we probably need to talk to W3C about this too, as
>> [2] seems to need changes to XHR, which is their spec. [3] Both of
>> those could however be taken care of as we go forward.
>> 
>> those are issues that need to be addressed but that I think should
>> be done in a WG.
>> 
>> please post those in the next few days. Or if you previously posted
>> a substantive comment that was not addressed (noting that addressed
>> != accepted) please post a link to that thread.
>> 
>> probably start the WG chartering process around mid-week. (To be
>> clear: at present I don't think this one needs a BoF in March, but
>> could be a chartered WG before then.)
>> 
>> Cheers, S.
>> 
>> schedule a session for the WG, if that is formed, or else use that
>> session for a BoF if one turns out to be needed.
>> 
>> 
>> [1]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Jan 2015 16:54:17 +0000

Hiya,

I forwarded this to the IESG as a heads-up and got a
good question. That and my answer below just for
checking. Not sure if clarifying this in the charter
would be good or not.

The question was:
>> Is it reasonable to consider whether the token binding protocol
>> could be used with other security protocols other than TLS?

And I said:

> Good question. I'd say the answer is, yes in theory and other
> client-server protocols should be able to follow the design
> pattern, (arguably HOBA does in HTTP:-) but no in practice,
> the protocol specifics would be quite likely tied to TLS for
> security reasons (e.g. bind to a (pre-)master secret, though
> that could be generalised) but more likely simply for the
> convenience of using ALPN and TLS extensions and the TLS style
> of specifying PDUs, etc."

Cheers,
S.

---

From: John Bradley <[email-masked]>
Date: Mon, 26 Jan 2015 14:04:45 -0300

Last week I did a blog post on how token binding fits with a number of the other related specs.
http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html

Based on feedback from one of the token binding authors, I didn't butcher it too much.

I think the use of the key established by token binding is best left to the protocols that want to use it.

Trying to cover the application layer is too broad a scope for this WG.

John B.

> On Jan 26, 2015, at 1:53 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Bill,
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 26 Jan 2015 09:22:41 -0800

re your last point.  My concern is the OAuth WG proceeding with a largely duplicative solution in the app layer.

If the unbearable drafts can address the TLS not being end-to-end (e.g. ending at a load-balancer scenario), then I’m not sure the OAuth work would be needed in its current scope.

I am concerned about keeping these separate WGs coordinated to avoid overlap and/or perceived/actual complexity in any resulting solution.

Phil

@independentid
www.independentid.com
[email-masked]

> On Jan 26, 2015, at 9:04 AM, John Bradley <[email-masked]> wrote:
>

---

From: Bill Mills <[email-masked]>
Date: Mon, 26 Jan 2015 17:42:06 +0000 (UTC)

I don't think it's an extension of scope, this is talking about how to handle arbitrary security tokens like cookies and OAuth tokens which are presented differently enough that we're talking about generic HTTP signing.
As an aside this is very reminiscent of Eran's MAC cookies concept.
 
One of the foundation documents for this 
     On Monday, January 26, 2015 8:53 AM, Stephen Farrell <[email-masked]> wrote:

Hi Bill,

Thanks,
S.

[1]

Thanks,
S.

---

From: John Bradley <[email-masked]>
Date: Mon, 26 Jan 2015 14:43:41 -0300

I don't think the OAuth work is duplicative, mostly because I don't think that Token binding adds much to native/server applications that we don't already have with mutual TLS (perhaps some slightly nicer ways to do the same thing)

Token binding will be useful for OAuth clients that are in the browser and in securing the authorization request/response flow via the browser.

I don't think that Token binding doing end to end message level authentication over non TLS connections is in scope for this WG.

John B.

> On Jan 26, 2015, at 2:22 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: Bill Mills <[email-masked]>
Date: Mon, 26 Jan 2015 17:47:54 +0000 (UTC)

In some ways this fits right in to POP if I understand it right.  Some of this is a way for a key pair to be negotiated that could be used for an OAuth POP token, and that would be very useful. 

     On Monday, January 26, 2015 9:43 AM, John Bradley <[email-masked]> wrote:

John B.

---

From: John Bradley <[email-masked]>
Date: Mon, 26 Jan 2015 15:02:50 -0300

I think it will help to make OAuth browser based flows PoP enabled.

However the flows for server/native will probably benefit less.  In a native app you can now use a single client key across multiple sessions.  Using token binding likely will prevent the same key from being used both with the RS and token endpoint for privacy reasons.   By design the private key would also not be available to the application for signing messages (perhaps a web crypto API might be developed in the browser).

If you have a “smart” client that can manage keys/certs then token binding is probably not a huge advancement.   
It is huge for browsers where that ability to manage keys doesn’t currently exist.

Just my opinion.
John B.

> On Jan 26, 2015, at 2:47 PM, Bill Mills <[email-masked]> wrote:
> 
> > On Jan 26, 2015, at 2:22 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > [email-masked] <mailto:[email-masked]>
> > 
> >> On Jan 26, 2015, at 9:04 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html <http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html>
> >> 
> >>> On Jan 26, 2015, at 1:53 PM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>> 
> >>> Hi Bill,
> >>> 
> >>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt <https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt>
> >>> 
> >>> 
> >>> Thanks,
> >>> S.
> >>> 
> >>> 
> >>>> 
> >>>> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
> >>>> <[email-masked] <mailto:[email-masked]>> wrote:
> >>>> 
> >>>> 
> >>>> 
> >>>> Hi Bill,
> >>>> 
> >>>>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell 
> >>>>> <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> Hiya,
> >>>>> 
> >>>>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt <https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt>
> >>>>> 
> >>>>> 
> >>>> 
> >>>>> 
> >>> [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding <https://tools.ietf.org/html/draft-balfanz-https-token-binding>
> >>>>> [3] http://www.w3.org/TR/XMLHttpRequest/ <http://www.w3.org/TR/XMLHttpRequest/>
> >>>>> 
> >>>>> list [email-masked] <mailto:[email-masked]> 
> >>>>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> list [email-masked] <mailto:[email-masked]> 
> >>>>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> >>>>> 
> >>>> 
> >>>> list [email-masked] <mailto:[email-masked]> 
> >>>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>> 
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> >> 
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> > 
> 
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 26 Jan 2015 10:24:35 -0800

I agree with part of what you are saying.

The browser flows are new.  The rest is duplicative. It is the overlap with the rest of the POP work that is problematic.

Phil

@independentid
www.independentid.com
[email-masked]

> On Jan 26, 2015, at 10:02 AM, John Bradley <[email-masked]> wrote:
> 
>> On Jan 26, 2015, at 2:47 PM, Bill Mills <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Monday, January 26, 2015 9:43 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> > www.independentid.com <http://www.independentid.com/>

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 26 Jan 2015 18:33:57 +0000

I’m not seeing overlap here with OAUTH, JOSE and the proposed new WG, I see benefits to OAUTH to allow usage of OAUTH and JOSE defined tokens and keys, I also see some potential privacy enhancements that the new WG proposal can add along with some federation improvements that would help native/server.

From: Unbearable [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Monday, January 26, 2015 10:03 AM
To: Bill Mills
Cc: [email-masked]; Stephen Farrell; Phil Hunt
Subject: Re: [Unbearable] moving ahead

Just my opinion.
John B.

On Jan 26, 2015, at 2:47 PM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

On Monday, January 26, 2015 9:43 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

John B.

> On Jan 26, 2015, at 2:22 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
>
> www.independentid.com<http://www.independentid.com>
> [email-masked]<mailto:[email-masked]>
>
>> On Jan 26, 2015, at 9:04 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> On Jan 26, 2015, at 1:53 PM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>
>>> Hi Bill,
>>>
>>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>>
>>>>
>>>> Hi Bill,
>>>>
>>>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Hiya,
>>>>>
>>>>> list [email-masked]<mailto:[email-masked]>
>>>>> list [email-masked]<mailto:[email-masked]>
>>>> list [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

---

From: Vinod Anupam <[email-masked]>
Date: Mon, 26 Jan 2015 10:38:56 -0800

At a very high level, the current drafts propose:

(1) how a client can agree with a server about using token binding over a
(resumable) TLS connection
(1a) the recommendation that clients should use different "keys" for
different eTLD+1
(2) how a browser and server can exchange "bound" information over HTTP
(3) how, over HTTP, an RP can ask a browser to get, from an IdP,
information that is bound for use with the RP

Is the duplication that you are referring to in (1) ?

On Mon, Jan 26, 2015 at 10:24 AM, Phil Hunt <[email-masked]> wrote:

> The browser flows are new.  The rest is duplicative. It is the overlap
> with the rest of the POP work that is problematic.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
> However the flows for server/native will probably benefit less.  In a
> native app you can now use a single client key across multiple sessions.
> Using token binding likely will prevent the same key from being used both
> with the RS and token endpoint for privacy reasons.   By design the private
> key would also not be available to the application for signing messages
> (perhaps a web crypto API might be developed in the browser).
>
> In some ways this fits right in to POP if I understand it right.  Some of
> this is a way for a key pair to be negotiated that could be used for an
> OAuth POP token, and that would be very useful.
>
>
> I don't think the OAuth work is duplicative, mostly because I don't think
> that Token binding adds much to native/server applications that we don't
> already have with mutual TLS (perhaps some slightly nicer ways to do the
> same thing)
>
> Token binding will be useful for OAuth clients that are in the browser and
> in securing the authorization request/response flow via the browser.
>
> I don't think that Token binding doing end to end message level
> authentication over non TLS connections is in scope for this WG.
>
> John B.
>
> > re your last point.  My concern is the OAuth WG proceeding with a
> largely duplicative solution in the app layer.
> >
> > If the unbearable drafts can address the TLS not being end-to-end (e.g.
> ending at a load-balancer scenario), then I’m not sure the OAuth work would
> be needed in its current scope.
> >
> > I am concerned about keeping these separate WGs coordinated to avoid
> overlap and/or perceived/actual complexity in any resulting solution.
> >
> > Phil
> >
> > @independentid
> > www.independentid.com
> > [email-masked]
> >
> >>>> <[email-masked]> wrote:
> >>>>
> >>>>
> >>>>
> >>>> Hi Bill,
> >>>>
> >>>>> <[email-masked]> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hiya,
> >>>>>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 26 Jan 2015 19:00:34 +0000

Hi Stephen,

Correct: as currently described, TB uses TLS-UNIQUE and ALPN. A security protocol other than TLS may be able to provide similar facilities, in which case it will work with TB just as well as TLS.

It is true that TB can be adapted for use with security protocols other than TLS, but my preference would be to avoid expanding the scope of the charter, so that we can make progress in a reasonable amount of time.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Monday, January 26, 2015 8:54 AM
To: [email-masked]
Subject: Re: [Unbearable] moving ahead

Hiya,

I forwarded this to the IESG as a heads-up and got a good question. That and my answer below just for checking. Not sure if clarifying this in the charter would be good or not.

The question was:
>> Is it reasonable to consider whether the token binding protocol could 
>> be used with other security protocols other than TLS?

And I said:

> client-server protocols should be able to follow the design pattern, 
> (arguably HOBA does in HTTP:-) but no in practice, the protocol 
> specifics would be quite likely tied to TLS for security reasons (e.g. 
> bind to a (pre-)master secret, though that could be generalised) but 
> more likely simply for the convenience of using ALPN and TLS 
> extensions and the TLS style of specifying PDUs, etc."

Cheers,
S.

On 24/01/15 23:34, Stephen Farrell wrote:
> 
> Hiya,
> 
> Andrei has asked me about next steps for this work, based on the draft 
> charter text at [1].
> 
> from server implementers who are not also browser makers.
> And secondly, we probably need to talk to W3C about this too, as [2] 
> start the WG chartering process around mid-week.
> (To be clear: at present I don't think this one needs a BoF in March, 
> but could be a chartered WG before then.)
> 
> Cheers,
> S.
> 
> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG
> -Charter-Draft.txt [2] 
> https://tools.ietf.org/html/draft-balfanz-https-token-binding

---

From: Phil Hunt <[email-masked]>
Date: Mon, 26 Jan 2015 12:25:37 -0800

While the solutions between unbearable and OAuth POP are different (one is mixed layer, the other is pure app layer), the objectives are the same - proof of possession.  Why not fold the OAuth POP work into this WG?  

If the work needs to be separate, then should the OAuth POP scope of work be reduced to cover what the unbearable drafts do not cover?

Phil

@independentid
www.independentid.com
[email-masked]

> On Jan 26, 2015, at 10:38 AM, Vinod Anupam <[email-masked]> wrote:
> 
> (1) how a client can agree with a server about using token binding over a (resumable) TLS connection
> (1a) the recommendation that clients should use different "keys" for different eTLD+1
> (3) how, over HTTP, an RP can ask a browser to get, from an IdP, information that is bound for use with the RP
> 
> On Mon, Jan 26, 2015 at 10:24 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> 
>> On Jan 26, 2015, at 10:02 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>