Subject: Re: [Unbearable] Updated Charter Proposal

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Feb 2015 22:30:07 +0000

Thanks all. I had hoped to get this into the chartering process
earlier this week but didn't get to it. I'll get it started in
the next couple of days.

Cheers,
S.

On 30/01/15 22:58, Andrei Popov wrote:
> 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
> 
> 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]<mailto:[email-masked]>
> Subject: Re: [Unbearable] Updated Charter Proposal
> 
> 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]<mailto:[email-masked]>> wrote:
> 
> 
> Cheers,
> 
> Editing will ensue:-)
> 
> S
> 
> On 25/01/15 01:30, Kathleen Moriarty wrote:
>> 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]<mailto:[email-masked]>> wrote:
>>> 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]<mailto:[email-masked]>]
>>> Sent: Thursday, January 15, 2015 12:16 PM
>>>
>>>
>>> To: Andrei Popov
>>> Cc: [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [Unbearable] Updated Charter Proposal
>>>
>>>
>>>
>>> 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]<mailto:[email-masked]>>
>>> wrote:
>>>
>>>
>>>
>>> Thanks John; both suggestions make sense to me; will rephrase in the next
>>> revision.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Andrei
>>>
>>>
>>>
>>> From: John Bradley [mailto:[email-masked]<mailto:[email-masked]>]
>>> Sent: Thursday, January 15, 2015 9:25 AM
>>> To: Andrei Popov
>>> Cc: [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [Unbearable] Updated Charter Proposal
>>>
>>>
>>>
>>> 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]<mailto:[email-masked]>>
>>> 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.
>>>
>>> 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.
>>>
>>> _______________________________________________
>>> Unbearable mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Unbearable mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>
>>
>>
>>
> 
> _______________________________________________
> Unbearable mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable
> 
> 
> 
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Feb 2015 21:25:24 +0000

Hi again,

I've started the chartering process. [1] That means that
the IESG will ponder this in a couple of weeks after which
(all going well) we'll send the resulting charter out for
review to the main IETF list and to other organisations
(there's a mega list for announcing new work with IEEE,
W3C etc on it). As comments arrive, we'll edit the charter
text to match whatever rough consensus emerges. But do
feel free to continue working on the charter and the
drafts in the meantime on this list.

After the external review is done,  the IESG again review
the resulting charter to check if that does represent IETF
consensus and then decide to form the WG or do something
else. The earliest that'd happen would be March 5th.

Since all of that is quite close to the Dallas meeting,
I've requested a session for about 75 people. The way
we do that is to add this to the list of BoF requests [2]
even it'll hopefully be a WG before Dallas. If we hit
any kind of delay, we can proceed with the session as a
BoF as well. (The meeting schedule will be announced as
per [3], as usual.)

And in case you're wondering about chairs, those will be
appointed at the end of all this process just as the WG
is officially formed. In the meantime I'm sure Andrei and
Vinod will continue to help manage this list as before.

Thanks,
Stephen.

[1] https://datatracker.ietf.org/doc/charter-ietf-tokbind/
[2] https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Security
[3] https://www.ietf.org/meeting/important-dates-2015.html#ietf92