Subject: [Unbearable] Updated Charter Proposal

From: Andrei Popov <[email-masked]>
Date: Thu, 15 Jan 2015 00:14:54 +0000

The discussion on this mailing list has subsided over the holidays, so I looked through the messages for feedback regarding the proposed charter and incorporated a couple of changes suggested so far:

1. A new design goal: the solution must work for Web browsers. E.g. this means that security tokens must be presentable over multiple TLS sessions and connections.

2. Removed specific milestone dates.

Looking forward to more discussion of the charter,

Thanks,

Andrei

_____________________________________________________
Token Binding (TB)

Charter for Working Group

Web services generate various security tokens (e.g.  HTTP cookies, OAuth tokens, etc.) for web applications to access protected resources. Currently these are bearer tokens, i.e. any party in possession of such token gains access to the protected resource. Attackers export bearer tokens from client machines or from compromised network connections, present these bearer tokens to Web services, and impersonate authenticated users. The idea of Token Binding is to enable defense against such attacks by cryptographically binding security tokens to the TLS layer.

The tasks of this working group are as follows:
1.            Specify the Token Binding protocol v1.0.
2.            Specify the use of the Token Binding protocol in combination with HTTPS.

It is a goal of this working group to enable defense against attacks that involve unauthorized replay of security tokens, but other issues associated with the use of security tokens are out of scope. It is a goal of this working group to design the Token Binding protocol such that it would be also useable with application protocols other than HTTPS, however specifying such uses is not a primary goal.

Some of the main design goals for the Token Binding protocol, in no particular order:
1.            Prevent export and replay of security tokens.
2.            Allow strong key protection, e.g. using hardware-bound keys.
3.            Support both first-party and federation scenarios.
4.            Preserve user privacy.
5.            Make the Token Binding protocol useable in combination with a variety of application protocols.
6.            Allow the negotiation of the Token Binding protocol without additional round-trips.
7.            Allow the use of multiple cryptographic algorithms, so that a variety of secure hardware modules with different cryptographic capabilities could be used with Token Binding.
8.            Propose Token Binding spec that can be implemented in Web browsers (but is not limited to them). E.g. Web browsers require that the same bound security token must be presentable over multiple TLS sessions and connections.

The working group will use the following documents as a starting point for its work:
-             draft-popov-token-binding-00;
-             draft-balfanz-https-token-binding-00.

This WG will collaborate with other IETF WGs, in particular with the TLS, HTTPbis and Oauth WGs.

Milestones:
-            WG document for the Token Binding Protocol v1.0.
-            WG document for HTTPS Token Binding.
-            Token Binding Protocol v1.0 to IESG.
-            HTTPS Token Binding to IESG.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 15 Jan 2015 09:26:52 +0100

Andrei,

the questions regarding the charter I have are the following.

Why does the charter need to say already that your specific solution
will be the one worked on. There are other solution approaches possible.

For example, there are various ways in which the proof of possession
could be demonstrated in TLS (and proposals have been made in the past).

There also have been suggestions on alternative ways to obtain the token
as well, which are better integrated with existing protocols.

I also don't know whether you had a chance to look at
draft-ietf-oauth-pop-architecture-00 since in earlier discussions there
were concerns that the the token binding in TLS is insufficient for a
number of scenarios. For example, when you want to provide end-to-end
security where TLS is terminated at load balancers.

Ciao
Hannes

On 01/15/2015 01:14 AM, Andrei Popov wrote:
> The discussion on this mailing list has subsided over the holidays, so I
> looked through the messages for feedback regarding the proposed charter
> and incorporated a couple of changes suggested so far:
> 
> 1. A new design goal: the solution must work for Web browsers. E.g. this
> means that security tokens must be presentable over multiple TLS
> sessions and connections.
> 
> Web services generate various security tokens (e.g.  HTTP cookies, OAuth
> tokens, etc.) for web applications to access protected resources.
> Currently these are bearer tokens, i.e. any party in possession of such
> token gains access to the protected resource. Attackers export bearer
> tokens from client machines or from compromised network connections,
> present these bearer tokens to Web services, and impersonate
> authenticated users. The idea of Token Binding is to enable defense
> against such attacks by cryptographically binding security tokens to the
> TLS layer.
> 
>  
> 
> It is a goal of this working group to enable defense against attacks
> that involve unauthorized replay of security tokens, but other issues
> associated with the use of security tokens are out of scope. It is a
> goal of this working group to design the Token Binding protocol such
> that it would be also useable with application protocols other than
> HTTPS, however specifying such uses is not a primary goal.
> 
>  
> 
> 7.            Allow the use of multiple cryptographic algorithms, so
> that a variety of secure hardware modules with different cryptographic
> capabilities could be used with Token Binding.
> 
> 8.            Propose Token Binding spec that can be implemented in Web
> browsers (but is not limited to them). E.g. Web browsers require that
> the same bound security token must be presentable over multiple TLS
> sessions and connections.
> 
>  
> 
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: [email-masked]
Date: Thu, 15 Jan 2015 15:44:34 +0100

Hi Andrei,

indeed, discussion went so quite over the holiday period that I check I was still listed in the group.

regarding your proposals.

1. design goals to facilitate multiple TLS connections for browser based application.

Fully Agree. Although I am a fan of security connections at lower stack levels, ie IPSec, I realise this is not always convenient, so TLS is the way to go.

2. remove milestones.

Fully agree. Since the remit of te group is still developing, setting milestones at this stage seems premature.

best wishes

Dean

Gesendet: Donnerstag, 15. Januar 2015 um 01:14 Uhr

Von: "Andrei Popov" <[email-masked]>

An: "[email-masked]" <[email-masked]>

Betreff: [Unbearable] Updated Charter Proposal

Thanks,

Andrei

Token Binding (TB)

Milestones:

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

---

From: John Bradley <[email-masked]>
Date: Thu, 15 Jan 2015 14:24:30 -0300

I am generally in agrement.

A couple of points.

Under design goals change 1 to.

1.   Allow applications to prevent the export and replay of security tokens.

You could make that applications and protocols if you like as some people may see things like OAuth as a protocol vs an application. 
The point being that the goal is to provide the hooks for things a layer above these specifications to make security decisions, not the token binding protocol itself.

In 3 you use the term federation.  That may be larger in scope than what I think you intend from the two drafts.
Federation is a much larger topic than allowing the public key from one connection to be exposed in a connection to a second party via some sort of express consent from the first party.

Shrinking the scope to how public keys may be shared with permission to third parties may make some people more comfortable, if they are concerned that this is trying to be a new federation protocol to compete with SAML or OAuth.

Regards
John B.

> On Jan 14, 2015, at 9:14 PM, Andrei Popov <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 15 Jan 2015 18:39:24 +0100

Andrei,

> A new design goal: the solution must work for Web browsers. E.g. this

Could you explain what motivated this design goal? What would prevent
you from using tokens over more than one TLS exchange? Is there a
specific use case you have in mind?

Ciao
Hannes

---

From: Andrei Popov <[email-masked]>
Date: Thu, 15 Jan 2015 18:52:55 +0000

Thanks John; both suggestions make sense to me; will rephrase in the next revision.

Cheers,

Andrei

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 9:25 AM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal

A couple of points.

Regards
John B.

On Jan 14, 2015, at 9:14 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Andrei

Milestones:
[email-masked]<mailto:[email-masked]>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 15 Jan 2015 19:01:58 +0000

Hi Hannes,

The idea here is that Web browsers impose additional requirements. One example is that browsers tend to open multiple TLS sessions and connections to the target server, and the same security token can be transmitted over any of these sessions/connections. So the token binding solution has to accommodate such usage, i.e. the binding must be verifiable regardless of which of the TLS connections was used to transmit the token.

Cheers,

Andrei

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, January 15, 2015 9:39 AM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal

Andrei,

> sessions and connections.

Could you explain what motivated this design goal? What would prevent you from using tokens over more than one TLS exchange? Is there a specific use case you have in mind?

Ciao
Hannes

---

From: Prateek Mishra <[email-masked]>
Date: Thu, 15 Jan 2015 11:14:32 -0800

+1 on Hanne's Comments on TLS termination and 
draft-ietf-oauth-pop-architecture-00

Now, I understand that there are 3-4 ginormous website operators who 
completely control their
stacks all the way from wiring to applications. These folks can handle 
TLS termination in different
and innovative ways.

But for most of the rest of the world, we are 
(politically/administratively) dependent
on network architectures where TLS termination is a network hop away 
from applications.
We should include support or at least a framework for these 
architectures in this work.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 15 Jan 2015 19:53:32 +0000

> Why does the charter need to say already that your specific solution will be the one worked on. There are other solution approaches possible.
A lot of TLS WG charters specify some starting-point document(s); this gives a good idea of what problems are being solved by the WG. In my opinion, it does not mean that the WG is locked into a specific solution, because Internet-Drafts are expected to change as the discussion progresses.

> There also have been suggestions on alternative ways to obtain the token as well, which are better integrated with existing protocols.
I would suggest that we discuss these alternatives in the new WG, and integrate them into the draft(s), if it makes sense.

> I also don't know whether you had a chance to look at draft-ietf-oauth-pop-architecture-00 since in earlier discussions there were concerns that the the token binding in TLS is insufficient for a number of scenarios. 
Yes, I read draft-ietf-oauth-pop-architecture-00; it appears to embrace both TLS (optionally) and asymmetric client-generated keys (also as an option), so I don't think there is any conflict here.

> For example, when you want to provide end-to-end security where TLS is terminated at load balancers.
I agree that it is common for TLS to be terminated at load balancers, and that this case should be discussed in the I-Ds. It's one of the gaps we'll need to close in the drafts, after all they are offered as a starting point, not finished product.

Cheers,

Andrei

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, January 15, 2015 12:27 AM
To: Andrei Popov; [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal

Andrei,

Why does the charter need to say already that your specific solution will be the one worked on. There are other solution approaches possible.

For example, there are various ways in which the proof of possession could be demonstrated in TLS (and proposals have been made in the past).

There also have been suggestions on alternative ways to obtain the token as well, which are better integrated with existing protocols.

I also don't know whether you had a chance to look at
draft-ietf-oauth-pop-architecture-00 since in earlier discussions there were concerns that the the token binding in TLS is insufficient for a number of scenarios. For example, when you want to provide end-to-end security where TLS is terminated at load balancers.

Ciao
Hannes

On 01/15/2015 01:14 AM, Andrei Popov wrote:
> The discussion on this mailing list has subsided over the holidays, so 
> I looked through the messages for feedback regarding the proposed 
> charter and incorporated a couple of changes suggested so far:
> 
> 1. A new design goal: the solution must work for Web browsers. E.g. 
> this means that security tokens must be presentable over multiple TLS 
> Web services generate various security tokens (e.g.  HTTP cookies, 
> OAuth tokens, etc.) for web applications to access protected resources.
> Currently these are bearer tokens, i.e. any party in possession of 
> such token gains access to the protected resource. Attackers export 
> bearer tokens from client machines or from compromised network 
> connections, present these bearer tokens to Web services, and 
> impersonate authenticated users. The idea of Token Binding is to 
> enable defense against such attacks by cryptographically binding 
> security tokens to the TLS layer.
> 
>  
>

---

From: Bill Mills <[email-masked]>
Date: Thu, 15 Jan 2015 19:59:18 +0000 (UTC)

I'm still trying to get my head around what the "elevator pitch" is for this, I don't think it's been adequately expressed yet.  Is it close to say this is all about "Clients (browsers) being able to tie credentials to locally generated and managed keys and assert that key to the auth service."? 

     On Thursday, January 15, 2015 11:02 AM, Andrei Popov <[email-masked]> wrote:

 Hi Hannes,

Cheers,

Andrei

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, January 15, 2015 9:39 AM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal

Andrei,

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Thu, 15 Jan 2015 17:16:00 -0300

A couple more possible clarifications.

> 2.            Specify the use of the Token Binding protocol in combination with HTTPS.

HTTPS is probably intended to be shorthand for a http binding for TLS + token Binding as is defined in "Token Binding over HTTP"  [https://tools.ietf.org/html/draft-balfanz-https-token-binding-00].

This is a binding to HTTP (via a new header) and to HTML  (via XML HTTP request).  

If we also say that possible future binding may be a SASSL/GSS-API binding for TLS + token binding   (The sassl-oauth spec https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 might use such a thing.)

One other thing I note in the drafts, is that at no point are  tokens defined or even really discussed other than as something that applications can bind to the exposed public key.
The applications will bind tokens to the keys exposed by the specs via the bindings.   The naming may slightly misdirect people, but there have already been too many names for this so I won't push the point.

I think keeping this down close to the TLS layer and defining bindings to HTTP and other protocols is in scope.
Encouraging applications that use protocols like HTTP + TLS to use the bindings to bind there security tokens/cookies is in scope.

I think defining the extensions for those applications to use the bindings is should be up to the applications themselves where there is active participation.

Trying to extend this to cover end to end message signing outside of a TLS session should be expressly out of scope.

We may however want to say something about how a TLS session terminated on a TLS device can have the Token Binding ID for the session passed in a HTTP header.
That and possibly some other TLS appliance issues are in scope for "Token Binding over HTTP"

Regards
John B.

> On Jan 15, 2015, at 3:52 PM, Andrei Popov <[email-masked]> wrote:
> 
> On Jan 14, 2015, at 9:14 PM, Andrei Popov <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 15 Jan 2015 20:43:06 +0000

This is indeed part of what the current -00 I-Ds offer.

We should not equate clients with Web browsers, but the browser use case is somewhat special and important to address, therefore I think it deserves mention among the goals.

From: Bill Mills [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 11:59 AM
To: Andrei Popov; Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal

On Thursday, January 15, 2015 11:02 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Hannes,

Cheers,

Andrei

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, January 15, 2015 9:39 AM
To: Andrei Popov
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Unbearable] Updated Charter Proposal

Andrei,

Ciao
Hannes

---

From: Bill Mills <[email-masked]>
Date: Thu, 15 Jan 2015 21:26:36 +0000 (UTC)

Agreed that browsers are a special and very popular case of clients and need specific considerations. 

     On Thursday, January 15, 2015 12:43 PM, Andrei Popov <[email-masked]> wrote:

 #yiv8300964038 #yiv8300964038 -- _filtered #yiv8300964038 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv8300964038 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv8300964038 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8300964038 #yiv8300964038 p.yiv8300964038MsoNormal, #yiv8300964038 li.yiv8300964038MsoNormal, #yiv8300964038 div.yiv8300964038MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8300964038 a:link, #yiv8300964038 span.yiv8300964038MsoHyperlink {color:blue;text-decoration:underline;}#yiv8300964038 a:visited, #yiv8300964038 span.yiv8300964038MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv8300964038 span.yiv8300964038EmailStyle17 {color:#1F497D;}#yiv8300964038 .yiv8300964038MsoChpDefault {font-size:10.0pt;} _filtered #yiv8300964038 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv8300964038 div.yiv8300964038WordSection1 {}#yiv8300964038 This is indeed part of what the current -00 I-Ds offer.    We should not equate clients with Web browsers, but the browser use case is somewhat special and important to address, therefore I think it deserves mention among the goals.    From: Bill Mills [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 11:59 AM
To: Andrei Popov; Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal    I'm still trying to get my head around what the "elevator pitch" is for this, I don't think it's been adequately expressed yet.  Is it close to say this is all about "Clients (browsers) being able to tie credentials to locally generated and managed keys and assert that key to the auth service."?    On Thursday, January 15, 2015 11:02 AM, Andrei Popov <[email-masked]> wrote:    Hi Hannes,

Cheers,

Andrei 
-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 9:39 AM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal

Andrei,

Ciao
Hannes

---

From: Andrei Popov <[email-masked]>
Date: Wed, 21 Jan 2015 00:07:09 +0000

I believe I've addressed the feedback received so far; the updated charter draft is on GitHub for easy authoring:
https://github.com/TokenBinding/WG-Charter

Pull requests are welcome,

Thanks,

Andrei

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, January 15, 2015 12:16 PM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal

Regards
John B.

On Jan 15, 2015, at 3:52 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Andrei

A couple of points.

Regards
John B.

Thanks,

Andrei

Milestones:

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 24 Jan 2015 20:30:07 -0500

Hi,

The charter looks like it is shaping up.  I just have some editorial
suggestions as the discussion continues, take them or leave them, not
a big deal.

Suggest changing from:
The idea of Token Binding is to enable defense against such attacks by
cryptographically binding
security tokens to the TLS layer.

To:
Token Binding enables defense against such attacks by cryptographically binding
security tokens to the TLS layer.

The word goal is used a bit much, but this is a personal preference -
take or leave the suggestions.  I suggest removing "Some" in the last
sentence listed as this only says the "main" goals/objectives, so
there is wiggle room still.

From:
It is a goal of this working group to enable defense against attacks
that involve unauthorized replay of
security tokens, but other issues associated with the use of security
tokens are out of scope. It is a goal
of this working group to design the Token Binding protocol such that
it would be also useable with
application protocols other than HTTPS, however specifying such uses
is not a primary goal.

Some of the main design goals for the Token Binding protocol, in no
particular order:

To:
It is a goal of this working group to enable defense against attacks
that involve unauthorized replay of
security tokens.  Other issues associated with the use of security
tokens are out of scope. Another goal
of this working group is to design the Token Binding protocol such
that it would be also useable with
application protocols other than HTTPS.  Specifying alternate
application protocols is not a primary goal.

The main design objectives for the Token Binding protocol, in no
particular order:

#8 - spec should probably be spelled out as specification.

Thanks,
Kathleen

On Tue, Jan 20, 2015 at 7:07 PM, Andrei Popov
<[email-masked]> wrote:
> I believe I’ve addressed the feedback received so far; the updated charter
> draft is on GitHub for easy authoring:
>
> HTTPS is probably intended to be shorthand for a http binding for TLS +
> token Binding as is defined in "Token Binding over HTTP"
> [https://tools.ietf.org/html/draft-balfanz-https-token-binding-00].
>
>
>
> If we also say that possible future binding may be a SASSL/GSS-API binding
> for TLS + token binding   (The sassl-oauth spec
> https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 might use such a
> thing.)
>
>
>
>
>
> One other thing I note in the drafts, is that at no point are  tokens
> defined or even really discussed other than as something that applications
> can bind to the exposed public key.
>
> The applications will bind tokens to the keys exposed by the specs via the
> bindings.   The naming may slightly misdirect people, but there have already
> been too many names for this so I won't push the point.
>
>
>
> Encouraging applications that use protocols like HTTP + TLS to use the
> bindings to bind there security tokens/cookies is in scope.
>
>
>
> I think defining the extensions for those applications to use the bindings
> is should be up to the applications themselves where there is active
> participation.
>
>
>
> Trying to extend this to cover end to end message signing outside of a TLS
> session should be expressly out of scope.
>
>
>
> We may however want to say something about how a TLS session terminated on a
> TLS device can have the Token Binding ID for the session passed in a HTTP
> header.
>
> You could make that applications and protocols if you like as some people
> may see things like OAuth as a protocol vs an application.
>
> The point being that the goal is to provide the hooks for things a layer
> above these specifications to make security decisions, not the token binding
> protocol itself.
>
>
>
>
>
> Federation is a much larger topic than allowing the public key from one
> connection to be exposed in a connection to a second party via some sort of
> express consent from the first party.
>
>
>
> Shrinking the scope to how public keys may be shared with permission to
> third parties may make some people more comfortable, if they are concerned
> that this is trying to be a new federation protocol to compete with SAML or
> OAuth.
>
>
>
> Regards
>
> John B.
>
>
>
> looked through the messages for feedback regarding the proposed charter and
> incorporated a couple of changes suggested so far:
>
> means that security tokens must be presentable over multiple TLS sessions
> and connections.
>
> tokens, etc.) for web applications to access protected resources. Currently
> these are bearer tokens, i.e. any party in possession of such token gains
> access to the protected resource. Attackers export bearer tokens from client
> machines or from compromised network connections, present these bearer
> tokens to Web services, and impersonate authenticated users. The idea of
> Token Binding is to enable defense against such attacks by cryptographically
> binding security tokens to the TLS layer.
>
>
>
> It is a goal of this working group to enable defense against attacks that
> involve unauthorized replay of security tokens, but other issues associated
> with the use of security tokens are out of scope. It is a goal of this
> working group to design the Token Binding protocol such that it would be
> also useable with application protocols other than HTTPS, however specifying
> such uses is not a primary goal.
>
>
>
> 7.            Allow the use of multiple cryptographic algorithms, so that a
> variety of secure hardware modules with different cryptographic capabilities
> could be used with Token Binding.
>
> browsers (but is not limited to them). E.g. Web browsers require that the
> same bound security token must be presentable over multiple TLS sessions and
> connections.
>
>
>

-- 

Best regards,
Kathleen

---

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

Cheers,

Editing will ensue:-)

S

---

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

My issue is again with the text "binding to the TLS layer", that's channel binding. 

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

Cheers,

Editing will ensue:-)

S

---

From: Andrei Popov <[email-masked]>
Date: Mon, 26 Jan 2015 20:50:36 +0000

Thanks Kathleen for helping improve the charter draft.

Editorial changes have been incorporated: https://github.com/TokenBinding/WG-Charter

Cheers,

Andrei

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Saturday, January 24, 2015 5:30 PM
To: Andrei Popov
Cc: John Bradley; [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal

Hi,

The charter looks like it is shaping up.  I just have some editorial suggestions as the discussion continues, take them or leave them, not a big deal.

Suggest changing from:
The idea of Token Binding is to enable defense against such attacks by cryptographically binding security tokens to the TLS layer.

To:
Token Binding enables defense against such attacks by cryptographically binding security tokens to the TLS layer.

The word goal is used a bit much, but this is a personal preference - take or leave the suggestions.  I suggest removing "Some" in the last sentence listed as this only says the "main" goals/objectives, so there is wiggle room still.

From:

To:
It is a goal of this working group to enable defense against attacks that involve unauthorized replay of security tokens.  Other issues associated with the use of security tokens are out of scope. Another goal of this working group is to design the Token Binding protocol such that it would be also useable with application protocols other than HTTPS.  Specifying alternate application protocols is not a primary goal.

The main design objectives for the Token Binding protocol, in no particular order:

Thanks,
Kathleen

On Tue, Jan 20, 2015 at 7:07 PM, Andrei Popov <[email-masked]> wrote:
> I believe I’ve addressed the feedback received so far; the updated 
> charter draft is on GitHub for easy authoring:
>
> HTTPS is probably intended to be shorthand for a http binding for TLS 
> + token Binding as is defined in "Token Binding over HTTP"
> defined or even really discussed other than as something that 
> applications can bind to the exposed public key.
>
> I think defining the extensions for those applications to use the 
> bindings is should be up to the applications themselves where there is 
> active participation.
>
>
>
> Trying to extend this to cover end to end message signing outside of a 
> TLS session should be expressly out of scope.
>
>
>
> We may however want to say something about how a TLS session 
> terminated on a TLS device can have the Token Binding ID for the 
> session passed in a HTTP header.
>
> You could make that applications and protocols if you like as some 
> people may see things like OAuth as a protocol vs an application.
>
> The point being that the goal is to provide the hooks for things a 
> layer above these specifications to make security decisions, not the 
> token binding protocol itself.
>
>
>
>
>
> In 3 you use the term federation.  That may be larger in scope than 
> what I think you intend from the two drafts.
>
> Federation is a much larger topic than allowing the public key from 
> one connection to be exposed in a connection to a second party via 
> some sort of express consent from the first party.
>
>
>
> Shrinking the scope to how public keys may be shared with permission 
> to third parties may make some people more comfortable, if they are 
> concerned that this is trying to be a new federation protocol to 
> compete with SAML or OAuth.
>
>
>
> Regards
>
> John B.
>
>
>
> OAuth tokens, etc.) for web applications to access protected 
> resources. Currently these are bearer tokens, i.e. any party in 
> possession of such token gains access to the protected resource. 
> Attackers export bearer tokens from client machines or from 
> compromised network connections, present these bearer tokens to Web 
> services, and impersonate authenticated users. The idea of Token 
> Binding is to enable defense against such attacks by cryptographically binding security tokens to the TLS layer.
>
>
>
> variety of secure hardware modules with different cryptographic 

-- 

Best regards,
Kathleen

---

From: Andrei Popov <[email-masked]>
Date: Tue, 27 Jan 2015 01:08:26 +0000

After chatting with Bill off-list, here is the specific change proposed.

The charter draft currently says:
“Token Binding enables defense against such attacks by cryptographically binding security tokens to the TLS layer.“

The proposed text:
“Token Binding enables defense against such attacks by cryptographically binding security tokens to a secret held by the client.“

If the mailing list is OK with this change, I’ll go ahead and update the charter draft.

Thanks,

Andrei

From: Bill Mills [mailto:[email-masked]]
Sent: Saturday, January 24, 2015 6:08 PM
To: Stephen Farrell; Kathleen Moriarty; Andrei Popov
Cc: John Bradley; [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal

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

Cheers,

Editing will ensue:-)

S

On 25/01/15 01:30, Kathleen Moriarty wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
>> From: John Bradley [mailto:[email-masked]<mailto:[email-masked]>]
>> From: John Bradley [mailto:[email-masked]<mailto:[email-masked]>]

---

From: Andrei Popov <[email-masked]>
Date: Fri, 30 Jan 2015 22:58:28 +0000

Since nobody seems to object, I’ve pushed Bill’s change to GitHub<https://github.com/TokenBinding/WG-Charter>.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Andrei Popov
Sent: Monday, January 26, 2015 5:08 PM
To: Bill Mills; Stephen Farrell; Kathleen Moriarty
Cc: John Bradley; [email-masked]
Subject: Re: [Unbearable] Updated Charter Proposal

The proposed text:

Thanks,

Andrei

Cc: John Bradley; [email-masked]<mailto:[email-masked]>

Cheers,

Editing will ensue:-)

S