From nobody Wed Feb 4 14:30:24 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355571A1AA3 for ; Wed, 4 Feb 2015 14:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1mlAkEvRdIe for ; Wed, 4 Feb 2015 14:30:11 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728A51A0397 for ; Wed, 4 Feb 2015 14:30:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5BF09BEFE; Wed, 4 Feb 2015 22:30:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx9k9_CitfBp; Wed, 4 Feb 2015 22:30:39 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.17.67]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 958E4BEE7; Wed, 4 Feb 2015 22:30:39 +0000 (GMT) Message-ID: <54D29D6F.5000308@cs.tcd.ie> Date: Wed, 04 Feb 2015 22:30:07 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andrei Popov , Bill Mills , Kathleen Moriarty References: <54C44BD9.6010507@cs.tcd.ie> <1028652913.19992.1422151670194.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: John Bradley , "unbearable@ietf.org" Subject: Re: [Unbearable] Updated Charter Proposal X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 22:30:17 -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. > > Cheers, > > Andrei > > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Andrei Popov > Sent: Monday, January 26, 2015 5:08 PM > To: Bill Mills; Stephen Farrell; Kathleen Moriarty > Cc: John Bradley; unbearable@ietf.org > 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:wmills_92105@yahoo.com] > Sent: Saturday, January 24, 2015 6:08 PM > To: Stephen Farrell; Kathleen Moriarty; Andrei Popov > Cc: John Bradley; unbearable@ietf.org > 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 > 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 >> > 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:ve7jtb@ve7jtb.com] >>> Sent: Thursday, January 15, 2015 12:16 PM >>> >>> >>> To: Andrei Popov >>> Cc: unbearable@ietf.org >>> 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 > >>> wrote: >>> >>> >>> >>> Thanks John; both suggestions make sense to me; will rephrase in the next >>> revision. >>> >>> >>> >>> Cheers, >>> >>> >>> >>> Andrei >>> >>> >>> >>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>> Sent: Thursday, January 15, 2015 9:25 AM >>> To: Andrei Popov >>> Cc: unbearable@ietf.org >>> 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 > >>> 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 >>> Unbearable@ietf.org >>> https://www.ietf.org/mailman/listinfo/unbearable >>> >>> >>> >>> >>> _______________________________________________ >>> Unbearable mailing list >>> Unbearable@ietf.org >>> https://www.ietf.org/mailman/listinfo/unbearable >>> >> >> >> > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Thu Feb 5 13:25:41 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417411A1A87 for ; Thu, 5 Feb 2015 13:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnhFiSbENaHh for ; Thu, 5 Feb 2015 13:25:31 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A231A8F39 for ; Thu, 5 Feb 2015 13:25:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7E56BBEB0; Thu, 5 Feb 2015 21:26:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mQc7FC7mjze; Thu, 5 Feb 2015 21:25:57 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.42.17.67]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C47E6BEA0; Thu, 5 Feb 2015 21:25:56 +0000 (GMT) Message-ID: <54D3DFC4.6020605@cs.tcd.ie> Date: Thu, 05 Feb 2015 21:25:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andrei Popov , Kathleen Moriarty References: <54C44BD9.6010507@cs.tcd.ie> <1028652913.19992.1422151670194.JavaMail.yahoo@mail.yahoo.com> <54D29D6F.5000308@cs.tcd.ie> In-Reply-To: <54D29D6F.5000308@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "unbearable@ietf.org" , "vanupam@google.com" Subject: Re: [Unbearable] Updated Charter Proposal X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:25:38 -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 On 04/02/15 22:30, Stephen Farrell wrote: > > 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. >> >> Cheers, >> >> Andrei >> >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Andrei Popov >> Sent: Monday, January 26, 2015 5:08 PM >> To: Bill Mills; Stephen Farrell; Kathleen Moriarty >> Cc: John Bradley; unbearable@ietf.org >> 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:wmills_92105@yahoo.com] >> Sent: Saturday, January 24, 2015 6:08 PM >> To: Stephen Farrell; Kathleen Moriarty; Andrei Popov >> Cc: John Bradley; unbearable@ietf.org >> 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 > 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 >>> > 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:ve7jtb@ve7jtb.com] >>>> Sent: Thursday, January 15, 2015 12:16 PM >>>> >>>> >>>> To: Andrei Popov >>>> Cc: unbearable@ietf.org >>>> 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 > >>>> wrote: >>>> >>>> >>>> >>>> Thanks John; both suggestions make sense to me; will rephrase in the next >>>> revision. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Andrei >>>> >>>> >>>> >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>> Sent: Thursday, January 15, 2015 9:25 AM >>>> To: Andrei Popov >>>> Cc: unbearable@ietf.org >>>> 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 > >>>> 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 >>>> Unbearable@ietf.org >>>> https://www.ietf.org/mailman/listinfo/unbearable >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Unbearable mailing list >>>> Unbearable@ietf.org >>>> https://www.ietf.org/mailman/listinfo/unbearable >>>> >>> >>> >>> >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> >> >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Wed Feb 11 09:54:54 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEFF1A8864 for ; Wed, 11 Feb 2015 04:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_grtsc2EBM7 for ; Wed, 11 Feb 2015 04:19:16 -0800 (PST) Received: from homiemail-a60.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 415D51A885E for ; Wed, 11 Feb 2015 04:19:16 -0800 (PST) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 078943BC06B for ; Wed, 11 Feb 2015 04:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; s=annevk.nl; bh=rlyCi5ShDdRiIkXngAHxpzlPi2U=; b=qb Xcd8cEAOQfqflxukdYr6hTT5+BXznTg8I4pWiGOQhVMxYieqA6so7447+T5bf/9E jBH+I1lhpeTzSwO4nji5D7gSCp785vq6Rpt0RVVD7y7kypJPlzphB0sO6qX2ATMk 65NkEZOCC77yx9GMTwIB6CWAtjiz7gsOGclk/nRFI= Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id EA8FE3BC063 for ; Wed, 11 Feb 2015 04:19:15 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id v10so2224028qac.6 for ; Wed, 11 Feb 2015 04:19:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.34.67 with SMTP id k61mr61486400qgk.95.1423657155176; Wed, 11 Feb 2015 04:19:15 -0800 (PST) Received: by 10.229.41.135 with HTTP; Wed, 11 Feb 2015 04:19:15 -0800 (PST) In-Reply-To: <54DB46AB.5030909@gmail.com> References: <54DB4463.2000509@gmail.com> <54DB46AB.5030909@gmail.com> Date: Wed, 11 Feb 2015 13:19:15 +0100 Message-ID: From: Anne van Kesteren To: Arthur Barstow Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 11 Feb 2015 09:54:53 -0800 Cc: public-webapps , unbearable@ietf.org, WebAppSec WG Subject: Re: [Unbearable] IETF seeking feedback on proposed "Token Binding" Working Group X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 12:19:17 -0000 On Wed, Feb 11, 2015 at 1:10 PM, Arthur Barstow wrote: > WebApps - please note the draft spec includes a new XHR property > "withRefererTokenBindingID" > . > > If anyone has feedback about the proposal, please send it to the > unbearable @ ietf.org list. However, comments related to the XHR aspect > should be Cc/Bcc to public-webapps. Relatively recently we decided not to extend XMLHttpRequest further and prioritize fetch(). Can we expect a more concrete proposal to revise either or is this it? One problem with this proposal is that it does not use the Sec-* convention for headers so the header can be spoofed... -- https://annevankesteren.nl/ From nobody Wed Feb 11 10:41:58 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47621A0383 for ; Wed, 11 Feb 2015 10:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaFME6cU2lS6 for ; Wed, 11 Feb 2015 10:41:55 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0110.outbound.protection.outlook.com [65.55.169.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669641A1A16 for ; Wed, 11 Feb 2015 10:41:55 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1249.namprd03.prod.outlook.com (25.161.207.25) with Microsoft SMTP Server (TLS) id 15.1.81.19; Wed, 11 Feb 2015 18:41:53 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0081.018; Wed, 11 Feb 2015 18:41:53 +0000 From: Andrei Popov To: Anne van Kesteren , Arthur Barstow Thread-Topic: [Unbearable] IETF seeking feedback on proposed "Token Binding" Working Group Thread-Index: AQHQRiPZmn629HImgE6eWoHR8jxzPJzrvL+w Date: Wed, 11 Feb 2015 18:41:53 +0000 Message-ID: References: <54DB4463.2000509@gmail.com> <54DB46AB.5030909@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: annevk.nl; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1249; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(52044002)(51704005)(377454003)(77156002)(62966003)(19580395003)(74316001)(76576001)(102836002)(2900100001)(2950100001)(15975445007)(19580405001)(99286002)(40100003)(2656002)(87936001)(106116001)(122556002)(86612001)(46102003)(86362001)(50986999)(76176999)(33656002)(54356999)(561944003)(92566002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1249; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2015 18:41:53.0938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1249 Archived-At: Cc: public-webapps , "unbearable@ietf.org" , WebAppSec WG Subject: Re: [Unbearable] IETF seeking feedback on proposed "Token Binding" Working Group X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 18:41:58 -0000 Hi Anne, This is part of a starting point proposal for the new working group; we exp= ect the documents to change. It's a great time to suggest revisions; please= feel free to suggest your text. I've put the initial I-Ds on github for ea= sier editing: https://github.com/TokenBinding/Internet-Drafts Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Anne van= Kesteren Sent: Wednesday, February 11, 2015 4:19 AM To: Arthur Barstow Cc: public-webapps; unbearable@ietf.org; WebAppSec WG Subject: Re: [Unbearable] IETF seeking feedback on proposed "Token Binding"= Working Group On Wed, Feb 11, 2015 at 1:10 PM, Arthur Barstow wro= te: > WebApps - please note the draft spec includes a new XHR property=20 > "withRefererTokenBindingID" > . > > If anyone has feedback about the proposal, please send it to the=20 > unbearable @ ietf.org list. However, comments related to the XHR=20 > aspect should be Cc/Bcc to public-webapps. Relatively recently we decided not to extend XMLHttpRequest further and pri= oritize fetch(). Can we expect a more concrete proposal to revise either or is this it? One problem with this proposal is that it does not use the Sec-* convention= for headers so the header can be spoofed... -- https://annevankesteren.nl/ _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Wed Feb 11 11:45:50 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A731A8986 for ; Wed, 11 Feb 2015 11:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO_l_vAyJond for ; Wed, 11 Feb 2015 11:03:05 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 33C6B1A8957 for ; Wed, 11 Feb 2015 11:03:05 -0800 (PST) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 07A17284078 for ; Wed, 11 Feb 2015 11:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; s=annevk.nl; bh=PhAGisg/PUrSahf9YoBashyKqoI=; b=E6 ewWSbvE4EN3GoIYo3O+cqZyUSe4kBgKaHD8ehZD3uprXDLMjUb2wEyLXvJSwXqig hUw4v8iNuThZ5CGnXL/vQ+xrzVBcRntuh5vgpJ4cf/sRMjO8IqbDjjgVurzeRDOV fdOMtEVWPBa05Nv45ATvwdj3RZ8AnAtIt1I01eiN0= Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id DFE74284071 for ; Wed, 11 Feb 2015 11:03:04 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id l6so4691528qcy.2 for ; Wed, 11 Feb 2015 11:03:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.229.190.6 with SMTP id dg6mr325074qcb.16.1423681384299; Wed, 11 Feb 2015 11:03:04 -0800 (PST) Received: by 10.229.41.135 with HTTP; Wed, 11 Feb 2015 11:03:04 -0800 (PST) In-Reply-To: References: <54DB4463.2000509@gmail.com> <54DB46AB.5030909@gmail.com> Date: Wed, 11 Feb 2015 20:03:04 +0100 Message-ID: From: Anne van Kesteren To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 11 Feb 2015 11:45:48 -0800 Cc: public-webapps , "unbearable@ietf.org" , Arthur Barstow , WebAppSec WG Subject: Re: [Unbearable] IETF seeking feedback on proposed "Token Binding" Working Group X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 19:03:06 -0000 On Wed, Feb 11, 2015 at 7:41 PM, Andrei Popov wrote: > This is part of a starting point proposal for the new working group; we expect the documents to change. I think it would be best if the document was written in such a way that any API could be plugged on top. And that it leaves changing APIs to those working on those APIs. > https://github.com/TokenBinding/Internet-Drafts I filed some issues for now. -- https://annevankesteren.nl/ From nobody Wed Feb 11 20:29:30 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA281A8AC2 for ; Wed, 11 Feb 2015 20:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLqAlX0AF_IH for ; Wed, 11 Feb 2015 20:29:24 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA281A8A6A for ; Wed, 11 Feb 2015 20:29:22 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id vb8so7689941obc.12 for ; Wed, 11 Feb 2015 20:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=S4PfmOQ4xslm6UXOwZeppCdMkR85nrzzk3mHmP2f+7A=; b=QCTkpK8zK8LmqusjPIJkYm6Ut0Aued1eUq8yVtWz6CpL1HT2DYODq42EqKvW3XE1dJ JBlKoKGl0fjfqMKQxMbjO6TKLYerO1FuHSZVOWQXfRAdXdZju0Nw+mZrm2BgsFsfQXxn kdQZOiCLgzGHmJbAnilt7ARnTZ7+/dXXz0Sb9qD8h6L/YHieHsN7QKRZX7AF6HjJ7+Zu 7g0zjPHqm48h0s3RMO0MXLguOfShbbGp1K4BZsqszLOQXfBkO4EfcF+ucD+lJycB9F05 W/Lsl4BUuKv+Qx5C74ZjGsO3OgFgtJk4O1kSyFCSmrNYpHuapC0QRxl99ipK9OanJ2G5 3gbg== X-Received: by 10.202.44.148 with SMTP id s142mr1288377ois.106.1423715362110; Wed, 11 Feb 2015 20:29:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.224.66 with HTTP; Wed, 11 Feb 2015 20:29:01 -0800 (PST) From: Tony Arcieri Date: Wed, 11 Feb 2015 20:29:01 -0800 Message-ID: To: unbearable@ietf.org Content-Type: multipart/alternative; boundary=001a1138e4e06b9ea1050edc9013 Archived-At: Subject: [Unbearable] Macaroons X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 04:29:28 -0000 --001a1138e4e06b9ea1050edc9013 Content-Type: text/plain; charset=UTF-8 Hi there. I just discovered your group today and haven't read your charter yet, but I just need to ask... have you heard of Macaroons? They're a highly flexible bearer token format providing simple implementations of a number of concepts, including "contextual caveats" as one of their principal features: https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/41892.pdf Perhaps one of the most interesting things about them is any holder of an unconfined Macaroon can "attenuate" it offline and add a contextual caveat using a chained HMAC operation. The resulting Macaroon is non-transferrable (bound to e.g. TLS channel ID) I've been considering starting an IETF working group specifically about Macaroons, but decided against it. However, I'd be happy to join forces with you! Relevant thread: https://groups.google.com/forum/#!topic/macaroons/lKaJnUXyKL0 -- Tony Arcieri --001a1138e4e06b9ea1050edc9013 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi there.

I just discovered your group = today and haven't read your charter yet, but I just need to ask... have= you heard of Macaroons?

They're a highly flex= ible bearer token format providing simple implementations of a number of co= ncepts, including "contextual caveats" as one of their principal = features:


Perhaps one of the most interesting thin= gs about them is any holder of an unconfined Macaroon can "attenuate&q= uot; it offline and add a contextual caveat using a chained HMAC operation.= The resulting Macaroon is non-transferrable (bound to e.g. TLS channel ID)=

I've been considering starting an IETF workin= g group specifically about Macaroons, but decided against it. However, I= 9;d be happy to join forces with you!

Relevant thr= ead:

--001a1138e4e06b9ea1050edc9013-- From colingallagher.rpcv@gmail.com Wed Feb 11 18:42:07 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B961A1B6B for ; Wed, 11 Feb 2015 18:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lEGZ7bQChWE for ; Wed, 11 Feb 2015 18:42:03 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C611A1B3D for ; Wed, 11 Feb 2015 18:42:02 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id f51so5943102qge.12 for ; Wed, 11 Feb 2015 18:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g8T+YC0iQbZUQZydj41siUGY8/+xZTVSTeAM/tS1AP4=; b=qfoO0KtUNgD1yu1ETtV0oY0EKx62y37l8nbfHFUodRSMhkJwa6s1+iPLIY5VL9NGe3 A0C28+JUQqK61Ajz+ToylSPPSXky1RZ/RO5iojWhyxYYeVt/bkgfNYi07M/r8MoeJexX kfa/xlmxG8iW2V7P6CyUeuoAVpOIuMV7KL5s71srrsGi8uGTIew4jRgY9qw1eJztngOE rWsn69Dr9pahOm0fQFF5sKdpI83r7iT9SEDZEDf9nYxZPQCLGNpVPuhIQjWVh10rh2nt yQ8sdAQYx40JBzPBqYKmn4IqRlFJdkf6CQOYb1Qo2Ehar1fZq0qmOSV+tebUXljcUFNf 7ckQ== MIME-Version: 1.0 X-Received: by 10.229.125.133 with SMTP id y5mr4564956qcr.17.1423708921867; Wed, 11 Feb 2015 18:42:01 -0800 (PST) Received: by 10.140.104.51 with HTTP; Wed, 11 Feb 2015 18:42:01 -0800 (PST) Received: by 10.140.104.51 with HTTP; Wed, 11 Feb 2015 18:42:01 -0800 (PST) In-Reply-To: <54DB4463.2000509@gmail.com> References: <54DB4463.2000509@gmail.com> Date: Wed, 11 Feb 2015 18:42:01 -0800 Message-ID: From: Colin Gallagher To: unbearable@ietf.org Content-Type: multipart/alternative; boundary=001a1133d9968d32c0050edb1045 Archived-At: X-Mailman-Approved-At: Thu, 12 Feb 2015 10:10:46 -0800 Cc: public-web-security@w3.org, Stephen Farrell Subject: Re: [Unbearable] IETF seeking feedback on proposed "Token Binding" Working Group X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 02:43:48 -0000 --001a1133d9968d32c0050edb1045 Content-Type: text/plain; charset=UTF-8 I suggest connecting with crypostorm.is staff and soliciting their input for starters. On Feb 11, 2015 4:03 AM, "Arthur Barstow" wrote: > [ Bcc: WebApps, WebAppSec, Web Security IG; Reply-to: unbearable @ > ietf.org ] > > Hi All, > > Below is an e-mail from Stephen Farrell regarding a proposed "Token > Binding" Working Group at the IETF. Stephen is interested in feedback > regarding the proposed group: > > * Home: > * Draft spec: binding> > * List archive: current/maillist.html> > > The Draft charter includes: > > [[ > 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. Token > Binding enables defense against such attacks by cryptographically binding > security tokens to a secret held by the client. > > 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. > > ... > ]] > > WebAppSec, Web Security IG - this is mainly an FYI for you. > > WebApps - please note the draft spec includes a new XHR property > "withRefererTokenBindingID" draft-balfanz-https-token-binding-00#section-3.4>. > > If anyone has feedback about the proposal, please send it to the > unbearable @ ietf.org list. However, comments related to the XHR aspect > should be Cc/Bcc to public-webapps. > > -Thanks, AB > > On 6 Feb 2015, at 8:40 am, Stephen Farrell >> wrote: >> >> >> Hi Mark & W3C folks, >> >> (I'm cc'ing various W3C folks I know in case one of you just know >> the answer and can save us some iterations, apologies to the others >> of you:-) >> >> We're starting the chartering process for a WG aiming to do better >> than bearer tokens. [1] As of now, it looks like that has a good >> chance of getting into some or all browsers which is great. We'll >> see what else turns up during the chartering process as usual, and >> please do comment on that also as usual. >> >> One thing I noted is that the current draft [2] for part of this >> work proposes (in section 3.4 [3]) a small change to XHR, so I >> wanted to bring that up with you and see if you think that's a >> thing that'll need to be addressed during chartering or if it's >> ok to handle later (in whatever is the right manner) after we've >> chartered an IETF WG. Or maybe it's something that's already done >> or bring done in W3C. >> >> The informal IESG evaluation of this charter is set for Feb 19th, >> so if we could figure it out by then that'd be great. If not, >> we've another couple of weeks of external review when we can get >> it done, but I'd prefer be quick if we can. >> >> And in case it helps, I think the simplest way to handle this if >> the change turns out to be needed in the end, would be for the >> relevant folks to just keep chatting and ideally get that XHR >> change tee'd up in W3C. In the meantime, the IETF spec could say >> something like "if you did change XHR in such-and-such a way then..." >> just so's we don't get in one another's way. Or maybe some other >> plan is better. >> >> Anyway, please let me know who's the right W3C person to keep >> in the loop on this and hopefully let's sort it out in the next >> week or so. >> >> Cheers, >> Stephen. >> >> >> >> [1]https://datatracker.ietf.org/wg/tokbind/charter/ >> [2]https://tools.ietf.org/html/draft-balfanz-https-token-binding >> [3] >> https://tools.ietf.org/html/draft-balfanz-https-token- >> binding-00#section-3.4 >> >> > > --001a1133d9968d32c0050edb1045 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I suggest connecting with c= rypostorm.is staff and soliciting their input for starters.

On Feb 11, 2015 4:03 AM, "Arthur Barstow&qu= ot; <art.barstow@gmail.com&= gt; wrote:
[ Bcc: W= ebApps, WebAppSec, Web Security IG; Reply-to: unbearable @ ietf.org ]

Hi All,

Below is an e-mail from Stephen Farrell regarding a proposed "Token Bi= nding" Working Group at the IETF. Stephen is interested in feedback re= garding the proposed group:

* Home: <https://datatracker.ietf.org/wg/tokbind/charter/= >
* Draft spec: <https://tools.ietf.org/html/draft= -balfanz-https-token-binding>
* List archive: <http://www.ietf.org/mail-archive/web/unbearable/current/maillist.html>

The Draft charter includes:

[[
Web services generate various security tokens (e.g. HTTP cookies, OAuth tok= ens, etc.) for web applications to access protected resources. Currently th= ese are bearer tokens, i.e. any party in possession of such token gains acc= ess to the protected resource. Attackers export bearer tokens from client m= achines or from compromised network connections, present these bearer token= s to Web services, and impersonate authenticated users. Token Binding enabl= es defense against such attacks by cryptographically binding security token= s to a secret held by the client.

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.=

...
]]

WebAppSec, Web Security IG - this is mainly an FYI for you.

WebApps - please note the draft spec includes a new XHR property "with= RefererTokenBindingID" <https://too= ls.ietf.org/html/draft-balfanz-https-token-binding-00#section= -3.4>.

If anyone has feedback about the proposal, please send it to the unbearable= @ ietf.org list. However= , comments related to the XHR aspect should be Cc/Bcc to public-webapps.
-Thanks, AB

On 6 Feb 2015, at 8:40 am, Stephen Farrell<stephen.farrell@cs.tcd.ie>= =C2=A0 wrote:


Hi Mark & W3C folks,

(I'm cc'ing various W3C folks I know in case one of you just know the answer and can save us some iterations, apologies to the others
of you:-)

We're starting the chartering process for a WG aiming to do better
than bearer tokens. [1] As of now, it looks like that has a good
chance of getting into some or all browsers which is great. We'll
see what else turns up during the chartering process as usual, and
please do comment on that also as usual.

One thing I noted is that the current draft [2] for part of this
work proposes (in section 3.4 [3]) a small change to XHR, so I
wanted to bring that up with you and see if you think that's a
thing that'll need to be addressed during chartering or if it's
ok to handle later (in whatever is the right manner) after we've
chartered an IETF WG. Or maybe it's something that's already done or bring done in W3C.

The informal IESG evaluation of this charter is set for Feb 19th,
so if we could figure it out by then that'd be great. If not,
we've another couple of weeks of external review when we can get
it done, but I'd prefer be quick if we can.

And in case it helps, I think the simplest way to handle this if
the change turns out to be needed in the end, would be for the
relevant folks to just keep chatting and ideally get that XHR
change tee'd up in W3C. In the meantime, the IETF spec could say
something like "if you did change XHR in such-and-such a way then...&q= uot;
just so's we don't get in one another's way. Or maybe some othe= r
plan is better.

Anyway, please let me know who's the right W3C person to keep
in the loop on this and hopefully let's sort it out in the next
week or so.

Cheers,
Stephen.



[1]https://datatracker.ietf.org/wg/tokbind/charter/
[2]https://tools.ietf.org/html/draft-balfanz-https-= token-binding
[3]
https://tools.ietf.org/html/draft-ba= lfanz-https-token-binding-00#section-3.4



--001a1133d9968d32c0050edb1045-- From nobody Thu Feb 12 10:12:27 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB391A8A8F for ; Wed, 11 Feb 2015 20:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnHZNfheu7NL for ; Wed, 11 Feb 2015 20:10:33 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10F91A8AB7 for ; Wed, 11 Feb 2015 20:10:32 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id b13so670212qcw.7 for ; Wed, 11 Feb 2015 20:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NJWo+69+ecSOkO36qLQ5HKIj/FGmA3a/AEgicXKs20Y=; b=jHeHk512IYSiiDZ5cUOT2biqwrEUCb9UX+DHBbaooShrzICi1NLOQFlFNlH4XovqJV k7eDS6PK4SbTHwKWnYLEH5v9jEi69Ki+m/yBUy5pkCtZ5vzCV6hbsFn2qNA/DrXF6sBO LCv20d2EPHGefNifVSitsVQZko7603TM0K7ZKSp6ubzlU4WrFlXHsH7173CDfWuSkKoF XunwQNdBxqTdQE3ZfAwpAgxUpV4jdh8uUytEXr9EeFB5X2qsMNrTbFgYrCkidvG9M6Fn REOWW2P8UXxXyShoikEwC2IngGQgm6U0ouacsoVi/Cru8Vu1RS5zXe8srvUeO7LI9Bfi qQJA== MIME-Version: 1.0 X-Received: by 10.140.44.134 with SMTP id g6mr4789225qga.85.1423714232147; Wed, 11 Feb 2015 20:10:32 -0800 (PST) Received: by 10.140.104.51 with HTTP; Wed, 11 Feb 2015 20:10:32 -0800 (PST) Received: by 10.140.104.51 with HTTP; Wed, 11 Feb 2015 20:10:32 -0800 (PST) In-Reply-To: References: <54DB4463.2000509@gmail.com> Date: Wed, 11 Feb 2015 20:10:32 -0800 Message-ID: From: Colin Gallagher To: unbearable@ietf.org Content-Type: multipart/alternative; boundary=001a11c162f811a4fb050edc4d39 Archived-At: X-Mailman-Approved-At: Thu, 12 Feb 2015 10:12:06 -0800 Cc: public-web-security@w3.org, Stephen Farrell Subject: Re: [Unbearable] IETF seeking feedback on proposed "Token Binding" Working Group X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 04:10:40 -0000 X-List-Received-Date: Thu, 12 Feb 2015 04:10:40 -0000 --001a11c162f811a4fb050edc4d39 Content-Type: text/plain; charset=UTF-8 Ah, oops. I meant, connect with https://cryptostorm.is staff. Solicit their input. Sorry for misspelling in prior email. On Feb 11, 2015 6:42 PM, "Colin Gallagher" wrote: > I suggest connecting with crypostorm.is staff and soliciting their input > for starters. > On Feb 11, 2015 4:03 AM, "Arthur Barstow" wrote: > >> [ Bcc: WebApps, WebAppSec, Web Security IG; Reply-to: unbearable @ >> ietf.org ] >> >> Hi All, >> >> Below is an e-mail from Stephen Farrell regarding a proposed "Token >> Binding" Working Group at the IETF. Stephen is interested in feedback >> regarding the proposed group: >> >> * Home: >> * Draft spec: > binding> >> * List archive: > current/maillist.html> >> >> The Draft charter includes: >> >> [[ >> 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. Token >> Binding enables defense against such attacks by cryptographically binding >> security tokens to a secret held by the client. >> >> 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. >> >> ... >> ]] >> >> WebAppSec, Web Security IG - this is mainly an FYI for you. >> >> WebApps - please note the draft spec includes a new XHR property >> "withRefererTokenBindingID" > draft-balfanz-https-token-binding-00#section-3.4>. >> >> If anyone has feedback about the proposal, please send it to the >> unbearable @ ietf.org list. However, comments related to the XHR aspect >> should be Cc/Bcc to public-webapps. >> >> -Thanks, AB >> >> On 6 Feb 2015, at 8:40 am, Stephen Farrell >>> wrote: >>> >>> >>> Hi Mark & W3C folks, >>> >>> (I'm cc'ing various W3C folks I know in case one of you just know >>> the answer and can save us some iterations, apologies to the others >>> of you:-) >>> >>> We're starting the chartering process for a WG aiming to do better >>> than bearer tokens. [1] As of now, it looks like that has a good >>> chance of getting into some or all browsers which is great. We'll >>> see what else turns up during the chartering process as usual, and >>> please do comment on that also as usual. >>> >>> One thing I noted is that the current draft [2] for part of this >>> work proposes (in section 3.4 [3]) a small change to XHR, so I >>> wanted to bring that up with you and see if you think that's a >>> thing that'll need to be addressed during chartering or if it's >>> ok to handle later (in whatever is the right manner) after we've >>> chartered an IETF WG. Or maybe it's something that's already done >>> or bring done in W3C. >>> >>> The informal IESG evaluation of this charter is set for Feb 19th, >>> so if we could figure it out by then that'd be great. If not, >>> we've another couple of weeks of external review when we can get >>> it done, but I'd prefer be quick if we can. >>> >>> And in case it helps, I think the simplest way to handle this if >>> the change turns out to be needed in the end, would be for the >>> relevant folks to just keep chatting and ideally get that XHR >>> change tee'd up in W3C. In the meantime, the IETF spec could say >>> something like "if you did change XHR in such-and-such a way then..." >>> just so's we don't get in one another's way. Or maybe some other >>> plan is better. >>> >>> Anyway, please let me know who's the right W3C person to keep >>> in the loop on this and hopefully let's sort it out in the next >>> week or so. >>> >>> Cheers, >>> Stephen. >>> >>> >>> >>> [1]https://datatracker.ietf.org/wg/tokbind/charter/ >>> [2]https://tools.ietf.org/html/draft-balfanz-https-token-binding >>> [3] >>> https://tools.ietf.org/html/draft-balfanz-https-token- >>> binding-00#section-3.4 >>> >>> >> >> --001a11c162f811a4fb050edc4d39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ah, oops. I meant, connect with https://cryptostorm.is staff. Solicit their input. Sorry for mis= spelling in prior email.

On Feb 11, 2015 6:42 PM, "Colin Gallagher&q= uot; <colingallagher.rp= cv@gmail.com> wrote:

I suggest connecting with crypostorm.is staff and soliciting their input= for starters.

On Feb 11, 2015 4:03 AM, "Arthur Barstow&qu= ot; <art.bars= tow@gmail.com> wrote:
[ Bcc: WebApps, WebAppSec, Web Security IG; Reply-to: unbearable @= ietf.org ]

Hi All,

Below is an e-mail from Stephen Farrell regarding a proposed "Token Bi= nding" Working Group at the IETF. Stephen is interested in feedback re= garding the proposed group:

* Home: <https://datatracker.ietf.org/wg/tokbind/charter/= >
* Draft spec: <https://tools.ietf.org/html/draft= -balfanz-https-token-binding>
* List archive: <http://www.ietf.org/mail-archive/web/unbearable/current/maillist.html>

The Draft charter includes:

[[
Web services generate various security tokens (e.g. HTTP cookies, OAuth tok= ens, etc.) for web applications to access protected resources. Currently th= ese are bearer tokens, i.e. any party in possession of such token gains acc= ess to the protected resource. Attackers export bearer tokens from client m= achines or from compromised network connections, present these bearer token= s to Web services, and impersonate authenticated users. Token Binding enabl= es defense against such attacks by cryptographically binding security token= s to a secret held by the client.

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.=

...
]]

WebAppSec, Web Security IG - this is mainly an FYI for you.

WebApps - please note the draft spec includes a new XHR property "with= RefererTokenBindingID" <https://too= ls.ietf.org/html/draft-balfanz-https-token-binding-00#section= -3.4>.

If anyone has feedback about the proposal, please send it to the unbearable= @ ietf.org list. However= , comments related to the XHR aspect should be Cc/Bcc to public-webapps.
-Thanks, AB

On 6 Feb 2015, at 8:40 am, Stephen Farrell<stephen.farrell@cs.tcd.ie>= =C2=A0 wrote:


Hi Mark & W3C folks,

(I'm cc'ing various W3C folks I know in case one of you just know the answer and can save us some iterations, apologies to the others
of you:-)

We're starting the chartering process for a WG aiming to do better
than bearer tokens. [1] As of now, it looks like that has a good
chance of getting into some or all browsers which is great. We'll
see what else turns up during the chartering process as usual, and
please do comment on that also as usual.

One thing I noted is that the current draft [2] for part of this
work proposes (in section 3.4 [3]) a small change to XHR, so I
wanted to bring that up with you and see if you think that's a
thing that'll need to be addressed during chartering or if it's
ok to handle later (in whatever is the right manner) after we've
chartered an IETF WG. Or maybe it's something that's already done or bring done in W3C.

The informal IESG evaluation of this charter is set for Feb 19th,
so if we could figure it out by then that'd be great. If not,
we've another couple of weeks of external review when we can get
it done, but I'd prefer be quick if we can.

And in case it helps, I think the simplest way to handle this if
the change turns out to be needed in the end, would be for the
relevant folks to just keep chatting and ideally get that XHR
change tee'd up in W3C. In the meantime, the IETF spec could say
something like "if you did change XHR in such-and-such a way then...&q= uot;
just so's we don't get in one another's way. Or maybe some othe= r
plan is better.

Anyway, please let me know who's the right W3C person to keep
in the loop on this and hopefully let's sort it out in the next
week or so.

Cheers,
Stephen.



[1]https://datatracker.ietf.org/wg/tokbind/charter/
[2]https://tools.ietf.org/html/draft-balfanz-https-= token-binding
[3]
https://tools.ietf.org/html/draft-ba= lfanz-https-token-binding-00#section-3.4



--001a11c162f811a4fb050edc4d39-- From nobody Mon Feb 16 04:00:57 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75D71A1ADC for ; Mon, 16 Feb 2015 04:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZQJWZwUMSFf for ; Mon, 16 Feb 2015 04:00:53 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F81E1A8861 for ; Mon, 16 Feb 2015 04:00:50 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wp4so41401265obc.10 for ; Mon, 16 Feb 2015 04:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DmlxwZms6Dm8vWoVG7S69g5w4H9KbqvvpaB1Wbm9J2E=; b=kEr9WrWiULbB18O57XFF0ahTglyOlEar05ooT3xNDORdJtnZRbpyBxvO+/sLQPsgUE mqdUituCfHYaqQHHx/EJgtQ8c+APushtjMhtbOmDZVgWmzQNUHpN/WA+Vamooreug09Z wBmbmyRUJObZIq1BdtetPzHZ+2Kqgi2oWWAqUIUpomyNAmcH6scqDWl/kfos8Pdtf7Kb lqvfO07jyGEEoKMAPxqdT19bavkS1NqXPYetFtZQdzj6olor4UE33hDIReuZt44fO+7F IVe3e30hF6YKtyxG+SXfO365Mob78wPmqHWNEcTWHkxSIR7Ph+3Y2CUi0F+JirxTYmCx vJ5Q== MIME-Version: 1.0 X-Received: by 10.182.60.197 with SMTP id j5mr14878625obr.85.1424088049648; Mon, 16 Feb 2015 04:00:49 -0800 (PST) Received: by 10.202.225.135 with HTTP; Mon, 16 Feb 2015 04:00:49 -0800 (PST) Date: Mon, 16 Feb 2015 23:00:49 +1100 Message-ID: From: Martin Thomson To: unbearable@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Unbearable] Where does the proof of possession belong? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 12:00:55 -0000 It's fairly clear that the first target of this is HTTP cookies, but the TLS extension is clearly written with higher aspirations than just one meagre protocol, as is the charter. What other protocols is this intended to address? I ask for several reasons: I don't see anything in the current charter using the TLS modifications. The HTTP usage lifts the format and hosts almost all of the binding protocol [1]. That leads me to wonder if other uses of the basic protocol can't do the same. I am also highly skeptical of frameworks. Understanding the properties of something in the abstract is very valuable, as is applying the lessons learned in one context to another. It's very different to attempt to codify that abstraction into a framework, which is an expensive process and can result in poor application where the original design didn't consider the new host. [1] Signature algorithm negotiation is problematic in the HTTP solution anyway. From nobody Mon Feb 16 15:56:59 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8831A88F5 for ; Mon, 16 Feb 2015 15:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1ih8_K3GnHR for ; Mon, 16 Feb 2015 15:56:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620F91A88EF for ; Mon, 16 Feb 2015 15:56:56 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1249.namprd03.prod.outlook.com (25.161.207.25) with Microsoft SMTP Server (TLS) id 15.1.81.19; Mon, 16 Feb 2015 23:56:36 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0081.018; Mon, 16 Feb 2015 23:56:36 +0000 From: Andrei Popov To: Martin Thomson , "unbearable@ietf.org" Thread-Topic: [Unbearable] Where does the proof of possession belong? Thread-Index: AQHQSeA83Ou8dyj26kK0ePoRB5hG55zz8Thw Date: Mon, 16 Feb 2015 23:56:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1249; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249; x-forefront-prvs: 0489CFBAC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(102836002)(54356999)(2950100001)(86362001)(2900100001)(77156002)(62966003)(76176999)(106116001)(15975445007)(122556002)(46102003)(2501002)(19580405001)(87936001)(50986999)(92566002)(2656002)(86612001)(33656002)(19580395003)(99286002)(74316001)(76576001)(40100003)(107886001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1249; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2015 23:56:36.4772 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1249 Archived-At: Subject: Re: [Unbearable] Where does the proof of possession belong? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 23:56:58 -0000 > It's fairly clear that the first target of this is HTTP cookies, but the = TLS extension is clearly written with higher aspirations than just one meag= re protocol, as is the charter.=20 Please clarify: what TLS extension are you referring to? > I am also highly skeptical of frameworks. Understanding the properties o= f something in the abstract is very valuable, as is applying the lessons le= arned in one context to another. It's very different to attempt to codify = that abstraction into a framework, which is an expensive process and can re= sult in poor application where the original design didn't consider the new = host. I would also prefer the approach of applying the lessons learned in one con= text to another, rather than codifying abstractions into frameworks:) =20 Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Martin T= homson Sent: Monday, February 16, 2015 4:01 AM To: unbearable@ietf.org Subject: [Unbearable] Where does the proof of possession belong? It's fairly clear that the first target of this is HTTP cookies, but the TL= S extension is clearly written with higher aspirations than just one meagre= protocol, as is the charter. What other protocols is this intended to addr= ess? I ask for several reasons: I don't see anything in the current charter using the TLS modifications. T= he HTTP usage lifts the format and hosts almost all of the binding protocol= [1]. That leads me to wonder if other uses of the basic protocol can't do= the same. I am also highly skeptical of frameworks. Understanding the properties of = something in the abstract is very valuable, as is applying the lessons lear= ned in one context to another. It's very different to attempt to codify th= at abstraction into a framework, which is an expensive process and can resu= lt in poor application where the original design didn't consider the new ho= st. [1] Signature algorithm negotiation is problematic in the HTTP solution any= way. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Fri Feb 20 11:02:26 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7011A6F3D; Fri, 20 Feb 2015 10:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VavW_dfdryUo; Fri, 20 Feb 2015 10:40:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDFD1A3BA9; Fri, 20 Feb 2015 10:40:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220184014.20582.91021.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 10:40:14 -0800 Archived-At: X-Mailman-Approved-At: Fri, 20 Feb 2015 11:02:25 -0800 Cc: tokbind WG Subject: [Unbearable] WG Review: Token Binding (tokbind) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 18:40:16 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2015-03-02. Token Binding (tokbind) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Stephen Farrell Mailing list Address: unbearable@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/unbearable Archive: http://www.ietf.org/mail-archive/web/unbearable/ Charter: 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. Token Binding enables defense against such attacks by cryptographically binding security tokens to a secret held by the client. 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. 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 alternative application protocols is not a primary goal. The main design objectives for the Token Binding protocol, in no particular order: 1. Allow applications and services to prevent unauthorized replay of security tokens. 2. Allow strong key protection, e.g. using hardware-bound keys. 3. Support both first-party (server generates a token for later use with this server) and federation (server generates a token for use with another server) 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 specification 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 and with the W3C webappsec WG. Milestones: Jan 2016 - HTTPS Token Binding to IESG. Jan 2016 - WG document for the Token Binding Protocol v1.0. Jan 2016 - WG document for HTTPS Token Binding. Jan 2016 - Token Binding Protocol v1.0 to IESG. From nobody Fri Feb 20 11:27:48 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADC11A1B54 for ; Fri, 20 Feb 2015 11:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE4CIX4ZUEjw for ; Fri, 20 Feb 2015 11:27:44 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94551A1AE3 for ; Fri, 20 Feb 2015 11:27:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5467DBEC0; Fri, 20 Feb 2015 19:27:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HElG7tJo0gs; Fri, 20 Feb 2015 19:27:40 +0000 (GMT) Received: from [10.10.5.195] (unknown [216.127.117.11]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07F05BEB5; Fri, 20 Feb 2015 19:27:39 +0000 (GMT) Message-ID: <54E78AAA.2050305@cs.tcd.ie> Date: Fri, 20 Feb 2015 19:27:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: tokbind WG References: <20150220184014.20582.91021.idtracker@ietfa.amsl.com> In-Reply-To: <20150220184014.20582.91021.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Kathleen Moriarty Subject: [Unbearable] chairs needed (was: Re: WG Review: Token Binding (tokbind)) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"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.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 19:27:46 -0000 Hi all, As you can see the charter has gone out for external review. The only change you didn't see was to add the good folks in W3C's webappsec WG as ones with whom this group ought co-ordinate, and that's already happening so I think we're good there. I hope that this charter will be approved as a WG at the IESG's next meeting on March 5th. At that point we will need working group chairs. The usual thing is to try have two chairs, at least one of whom is very familiar with the proposed work and at least one of whom is familiar with IETF process stuff and is interested in helping. If you fit one of those profiles and would be willing and able to be a co-chair for the tokbind WG, please send me a mail cc'ing Kathleen who is cc'd on this (cc'ing the mailing list disqualifies btw:-). If you're not sure but interested, do also get in touch and we can chat about the likely load and responsibilities. Thanks for your work so far on this and for the fun to come:-) Cheers, S. PS: The preliminary Dallas IETF meeting schedule will also shortly be published with a session for tokbind. Please be aware though that the schedule can still change. On 20/02/15 18:40, The IESG wrote: > A new IETF working group has been proposed in the Security Area. The IESG > has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg at ietf.org) by 2015-03-02. > > Token Binding (tokbind) > ------------------------------------------------ > Current Status: Proposed WG > > Assigned Area Director: > Stephen Farrell > > Mailing list > Address: unbearable@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/unbearable > Archive: http://www.ietf.org/mail-archive/web/unbearable/ > > Charter: > > > 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. Token Binding enables defense against such attacks > by cryptographically binding security tokens to a secret held by the > client. > > 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. 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 > alternative application protocols is not a primary goal. > > The main design objectives for the Token Binding protocol, in no > particular order: > > 1. Allow applications and services to prevent unauthorized replay of > security tokens. > 2. Allow strong key protection, e.g. using hardware-bound keys. > 3. Support both first-party (server generates a token for later use with > this server) and federation (server generates a token for use with > another server) 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 specification 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 and with the W3C webappsec WG. > > > Milestones: > Jan 2016 - HTTPS Token Binding to IESG. > Jan 2016 - WG document for the Token Binding Protocol v1.0. > Jan 2016 - WG document for HTTPS Token Binding. > Jan 2016 - Token Binding Protocol v1.0 to IESG. > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > >