Subject: [Unbearable] New Non-WG Mailing List: unbearable

From: IETF Secretariat <[email-masked]>
Date: Fri, 05 Dec 2014 11:18:20 -0800

A new IETF non-working group email list has been created.

List address: [email-masked]
Archive: http://www.ietf.org/mail-archive/web/unbearable/
To subscribe: https://www.ietf.org/mailman/listinfo/unbearable

Purpose:

This list is for discussion of proposals for doing better than bearer tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.

For additional information, please contact the list administrators.

---

From: Derek Atkins <[email-masked]>
Date: Sat, 06 Dec 2014 14:19:34 -0500

Hi,

IETF Secretariat <[email-masked]> writes:

> This list is for discussion of proposals for doing better than bearer
> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web
> applications. The specific goal is chartering a WG focused on
> preventing security token export and replay attacks.

The OAUTH Working Group is already (and has been for a while!) looking
into "holder of key" protocols to improve upon Bearer Tokens.

I would suggest that this work happen there instead of creating a whole
new group for it.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Mike Jones <[email-masked]>
Date: Mon, 8 Dec 2014 21:58:58 +0000

It's my understanding that "Unbearable" is part of an effort to create a new working group scoped to work on deliverables based upon these input documents:

http://tools.ietf.org/html/draft-balfanz-https-token-binding
http://tools.ietf.org/html/draft-popov-token-binding

I don't think that it was ever intended to cover every aspect of proof-of-possession and so there's not actually any conflict with the work we're already doing in OAuth.  (Nor does it seem to me to be productive to add even more documents-in-flight to the OAuth working group at present.)

				Cheers,
				-- Mike

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Derek Atkins
Sent: Saturday, December 06, 2014 11:20 AM
To: [email-masked]
Cc: Andrei Popov; [email-masked]; Stephen Farrell
Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable

Hi,

IETF Secretariat <[email-masked]> writes:

> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. 
> The specific goal is chartering a WG focused on preventing security 
> token export and replay attacks.

The OAUTH Working Group is already (and has been for a while!) looking into "holder of key" protocols to improve upon Bearer Tokens.

I would suggest that this work happen there instead of creating a whole new group for it.

-derek

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

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Dec 2014 19:54:18 -0300

We did discuss this at the last IETF meeting.

While the work is closely related to the PoP work in OAuth it is not the same.  It will allow us to do PoP tokens for the implicit flow, something that we haven't touched yet in OAuth because we don't have a workable way to manage keys in the browser.   This work should allow us to do that.

I think the slide deck examples showing JWT using different mechanisms to express keys from the work done in the OAuth WG may be part of what has some people concerned.

I don't think these specs overlap with OAuth, but we do need to be mindful of scope creep.   As I stated at the F2F we need to have the two groups work together, so that we can have PoP tokens via the browser.  

John B.

> On Dec 8, 2014, at 6:58 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 8 Dec 2014 15:17:30 -0800

Maybe all token work should be together in its own WG?

Phil

> On Dec 8, 2014, at 14:54, John Bradley <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 08 Dec 2014 23:23:09 +0000

Hiya,

As the sponsoring AD (or whatever term's correct) I've kicked
off the discussion on the new list. [1] If you're interested then
please subscribe there and discuss away. I really don't think
we need to bother [email-masked] with all the details.

Thanks,
Stephen.

[1] https://www.ietf.org/mail-archive/web/unbearable/current/msg00008.html

---

From: Bill Mills <[email-masked]>
Date: Tue, 9 Dec 2014 02:29:31 +0000 (UTC)

Splitting work on POP tokens between N>1 WG is almost certainly wrong if that's what we're doing.  
In the 2 drafts Mike J. pasted I find the use of the term "TLS Binding" confusing here because it's dangerously close to "Channel Binding" which is *not* what these drafts are talking about.  If we are in fact doing channel binding then that's the term we should be using.  Are these drafts intended to allow a trust relationship to be built on the client secret established during authentication, and that secret is then used to bring channel binding down into the HTTP layer? 

     On Monday, December 8, 2014 3:18 PM, Phil Hunt <[email-masked]> wrote:

Phil

---

From: Nico Williams <[email-masked]>
Date: Tue, 9 Dec 2014 11:29:25 -0600

> I would suggest that this work happen there instead of creating a whole

That's very interesting.

Key confirmation protocols will tend to all look... roughly similar: a
synchronous exchange of "messages" (with cryptographic elements, of
course) between a "client" and a "server" (with perhaps infrastructure
message in the background) until one, the other, or both peers are
authenticated to the other, or the authentication fails.

If you can have keys at all, you can also have session keys, though for
HTTP.. until we get something better than web cookies for session
continuation, having session keys is hardly critical.

Anyways, there's a reason I mention this: we already have several
protocols that look like this, so new not-just-bearer-anymore bearer
token extensions have literature to look at.

A brief list of such protocols that might be useful for lessons to
good, bad, and ugly: TLS, SASL (and various mechanisms), GSS-API (and
various mechanisms), Kerberos V5, IKEv1 and IKEv2, ...

Of those, these tend to have actual APIs in the wild that might be
useful too: TLS (ad-hoc APIs), SASL (ad-hoc APIs), GSS (standard APIs),
Kerberos (ad-hoc APIs), IKEv* (PF_KEY -- a standardish socket API).

I'm not sure which lessons OAuth and others going down this path should
take.  I'll try to think of some so as to save the authors the time of
having to digest all this material.  I suggest others also do this.

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Wed, 10 Dec 2014 22:13:22 +0000 (UTC)

Rereading the two draft propose BOTH channel binding and what you are calling "token binding".  "Token binding" being another name for proof-of-possession (POP) tokens, I prefer the "POP" nomenclature as much more distinct.
My original comments in the thread stand then, we're potentially duplicating some of the work happening in OAuth here.  If we want to move token work out of OAuth WG now that Bearer has established a workable first use case for OAuth2 that's fine, but we need to make sure that's part of the discussion.
The second topic, channel binding in HTTP is interesting, and I think the question is whether we should define a generic HTTP channel binding hook is worthwhile.but I think the discussion is really around whether there's value in putting the channel binding info into a header which various profiles could then sign against.  The previous comments about the difficulties of doing channel binding over HTTP in a world of TLS accelerators and HTTPS edge termination make this something of a huge challenge.  I think it's an interesting academic excercise, but the energy needs to be spent in how we can deal with transitive trust in that type of multi-hop sitation before we make a generic channel binding mechanism for HTTP that's not workable or deployable in general. 
-bill

     On Wednesday, December 10, 2014 1:47 PM, Andrei Popov <[email-masked]> wrote:

 #yiv8884657557 #yiv8884657557 -- _filtered #yiv8884657557 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv8884657557 {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv8884657557 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv8884657557 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8884657557 #yiv8884657557 p.yiv8884657557MsoNormal, #yiv8884657557 li.yiv8884657557MsoNormal, #yiv8884657557 div.yiv8884657557MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8884657557 a:link, #yiv8884657557 span.yiv8884657557MsoHyperlink {color:blue;text-decoration:underline;}#yiv8884657557 a:visited, #yiv8884657557 span.yiv8884657557MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv8884657557 p.yiv8884657557MsoListParagraph, #yiv8884657557 li.yiv8884657557MsoListParagraph, #yiv8884657557 div.yiv8884657557MsoListParagraph {margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8884657557 span.yiv8884657557EmailStyle17 {color:#1F497D;}#yiv8884657557 .yiv8884657557MsoChpDefault {font-size:10.0pt;} _filtered #yiv8884657557 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv8884657557 div.yiv8884657557WordSection1 {}#yiv8884657557 _filtered #yiv8884657557 {} _filtered #yiv8884657557 {font-family:Wingdings;color:black;} _filtered #yiv8884657557 {} _filtered #yiv8884657557 {font-family:Wingdings;} _filtered #yiv8884657557 {font-family:Symbol;} _filtered #yiv8884657557 {} _filtered #yiv8884657557 {font-family:Wingdings;} _filtered #yiv8884657557 {font-family:Symbol;} _filtered #yiv8884657557 {} _filtered #yiv8884657557 {font-family:Wingdings;}#yiv8884657557 ol {margin-bottom:0in;}#yiv8884657557 ul {margin-bottom:0in;}#yiv8884657557 Hi Bill,    Ø In the 2 drafts Mike J. pasted I find the use of the term "TLS Binding" confusing here because it's dangerously close to "Channel Binding" which is *not* what these drafts are talking about. The term “TLS Binding” is not used in either of the Token Binding I-Ds. The term “Token Binding” was chosen to avoid overloading the existing term “Channel Binding”.    Ø Are these drafts intended to allow a trust relationship to be built on the client secret established during authentication, and that secret is then used to bring channel binding down into the HTTP layer?  Authentication is out of the scope of these drafts. Once client authentication is complete, the server will often issue security tokens for the client to present to this server (or other servers, in the federation case). Today, these tokens can be intercepted or exported from the client machine and replayed, so the attacker can impersonate a valid user. These drafts allow the server to cryptographically bind security tokens to a (non-exportable, e.g. HW-bound) key maintained by the client. The client proves possession of this key on every TLS connection to the server, therefore once the security token is presented, the server can verify that it came from the client that it was issued to.    Cheers,    Andrei    From: Bill Mills [mailto:[email-masked]]
Sent: Monday, December 8, 2014 6:30 PM
To: Phil Hunt; John Bradley; [email-masked]
Cc: Andrei Popov; Mike Jones; Derek Atkins; Stephen Farrell
Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable    Splitting work on POP tokens between N>1 WG is almost certainly wrong if that's what we're doing.      In the 2 drafts Mike J. pasted I find the use of the term "TLS Binding" confusing here because it's dangerously close to "Channel Binding" which is *not* what these drafts are talking about.  If we are in fact doing channel binding then that's the term we should be using.  Are these drafts intended to allow a trust relationship to be built on the client secret established during authentication, and that secret is then used to bring channel binding down into the HTTP layer?        On Monday, December 8, 2014 3:18 PM, Phil Hunt <[email-masked]> wrote:    Maybe all token work should be together in its own WG?

Phil

---

From: John Bradley <[email-masked]>
Date: Wed, 10 Dec 2014 22:34:41 +0000

I think one thing that people may be missing in the discussion, is that this work is really about establishing and using pairwise keys in the browser.

This is not really for the OAuth clients other than perhaps implicit ones in the browser.

For servers and native apps we do have ways of managing keys in the client.  The current OAuth work is based around that.

At the moment we have no practical way(I am excluding installing soft certs in the users computer key store or using smart cards as impractical in practice) of doing POP via the browser.

I still think of this more at the TLS layer to establish keys, but it is being described as being higher on the stack for reasons…

Token binding may be a problematic name.  The specs should describe the key management parts and how to get at the keys to bind the relevant public key portions to tokens, but probably leave  the details for the application protocols that are going to use it.  OAuth should define how it is used to bind a access token to the channel, and Connect should worry about it’s id_tokens. etc.

It might be appropriate to say something about cookies. 

I think being clearer on what is and is not in scope will help.

John B.

> On Dec 10, 2014, at 10:13 PM, Bill Mills <[email-masked]> wrote:
> 
> Hi Bill,
> Ø  In the 2 drafts Mike J. pasted I find the use of the term "TLS Binding" confusing here because it's dangerously close to "Channel Binding" which is *not* what these drafts are talking about.
> The term “TLS Binding” is not used in either of the Token Binding I-Ds. The term “Token Binding” was chosen to avoid overloading the existing term “Channel Binding”.
>  
> Ø  Are these drafts intended to allow a trust relationship to be built on the client secret established during authentication, and that secret is then used to bring channel binding down into the HTTP layer? 
> Authentication is out of the scope of these drafts. Once client authentication is complete, the server will often issue security tokens for the client to present to this server (or other servers, in the federation case). Today, these tokens can be intercepted or exported from the client machine and replayed, so the attacker can impersonate a valid user. These drafts allow the server to cryptographically bind security tokens to a (non-exportable, e.g. HW-bound) key maintained by the client. The client proves possession of this key on every TLS connection to the server, therefore once the security token is presented, the server can verify that it came from the client that it was issued to.
>  
> Cheers,
>  
> Andrei
>  
> From: Bill Mills [mailto:[email-masked]] 
> On Monday, December 8, 2014 3:18 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>  
> > On Dec 8, 2014, at 14:54, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >> On Dec 8, 2014, at 6:58 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> http://tools.ietf.org/html/draft-balfanz-https-token-binding <http://tools.ietf.org/html/draft-balfanz-https-token-binding>
> >> http://tools.ietf.org/html/draft-popov-token-binding <http://tools.ietf.org/html/draft-popov-token-binding>
> >> 
> >> From: Unbearable [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Derek Atkins
> >> To: [email-masked] <mailto:[email-masked]>
> >> Cc: Andrei Popov; [email-masked] <mailto:[email-masked]>; Stephen Farrell
> >> IETF Secretariat <[email-masked] <mailto:[email-masked]>> writes:
> >> 
> >>> List address: [email-masked] <mailto:[email-masked]>
> >>> Archive: http://www.ietf.org/mail-archive/web/unbearable/ <http://www.ietf.org/mail-archive/web/unbearable/>
> >>> To subscribe: https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> >>> 
> >>> Purpose:
> >>> 
> >>      [email-masked] <mailto:[email-masked]>            www.ihtfp.com <http://www.ihtfp.com/>
> >> [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>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>

---

From: Bill Mills <[email-masked]>
Date: Wed, 10 Dec 2014 22:59:12 +0000 (UTC)

OAuth doesn't care about channel binding, a new token profile might, but that's why we separated the tokens from the core OAuth stuff.  
I think it is a (huge) mistake to try to use TLS to try to establish a trust relationship beyond that TLS context.

     On Wednesday, December 10, 2014 2:34 PM, John Bradley <[email-masked]> wrote:

Hi Bill, Ø  In the 2 drafts Mike J. pasted I find the use of the term "TLS Binding" confusing here because it's dangerously close to "Channel Binding" which is *not* what these drafts are talking about.The term “TLS Binding” is not used in either of the Token Binding I-Ds. The term “Token Binding” was chosen to avoid overloading the existing term “Channel Binding”. Ø  Are these drafts intended to allow a trust relationship to be built on the client secret established during authentication, and that secret is then used to bring channel binding down into the HTTP layer? Authentication is out of the scope of these drafts. Once client authentication is complete, the server will often issue security tokens for the client to present to this server (or other servers, in the federation case). Today, these tokens can be intercepted or exported from the client machine and replayed, so the attacker can impersonate a valid user. These drafts allow the server to cryptographically bind security tokens to a (non-exportable, e.g. HW-bound) key maintained by the client. The client proves possession of this key on every TLS connection to the server, therefore once the security token is presented, the server can verify that it came from the client that it was issued to. Cheers, Andrei From: Bill Mills [mailto:[email-masked]] 

Phil

---

From: Andrei Popov <[email-masked]>
Date: Wed, 10 Dec 2014 21:47:34 +0000

Hi Bill,

Cheers,

Andrei

On Monday, December 8, 2014 3:18 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

> On Dec 8, 2014, at 14:54, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On Dec 8, 2014, at 6:58 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Derek Atkins
>> To: [email-masked]<mailto:[email-masked]>
>> Cc: Andrei Popov; [email-masked]<mailto:[email-masked]>; Stephen Farrell
>> IETF Secretariat <[email-masked]<mailto:[email-masked]>> writes:
>>
>>> List address: [email-masked]<mailto:[email-masked]>
>>      [email-masked]<mailto:[email-masked]>            www.ihtfp.com<http://www.ihtfp.com>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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