From nobody Sat Dec 6 08:08:28 2014 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 C55DA1A8830; Sat, 6 Dec 2014 08:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 fLWuTas1nYn2; Sat, 6 Dec 2014 08:08:18 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755071A1BF1; Sat, 6 Dec 2014 08:08:15 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB6G87rW009841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Dec 2014 16:08:08 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sB6G85dW007201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Dec 2014 16:08:05 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB6G84X4016037; Sat, 6 Dec 2014 16:08:04 GMT Received: from [192.168.1.9] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 06 Dec 2014 08:08:04 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Phil Hunt In-Reply-To: <5481E0A7.2090604@cs.tcd.ie> Date: Sat, 6 Dec 2014 08:08:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2DF4B463-DD15-42BE-85AE-121C14E19A8F@oracle.com> References: <5481E0A7.2090604@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1993) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/jcn9Zx-2SXQ4YMxj6npIBJ6osMs Cc: unbearable@ietf.org, oauth Subject: Re: [Unbearable] [http-auth] unbearable - new mailing list to discuss better than bearer tokens... 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: Sat, 06 Dec 2014 16:08:22 -0000 On the surface (as currently presented) this work appears to duplicate = the POP work going on in OAuth. The key difference is that this work is = focused on using ALPN to bind tokens to the TLS channel. =46rom a use = case perspective it is very close to OAuth POP, and a specific use case = of the current OAuth POP (proof of possession) architecture. I note that the OAuth WG had originally dropped TLS binding in part = because TLS was not always end-to-end in cases where load-balancers = where used. The identified use-cases required end-to-end proof of = possession (e.g. to prevent token re-use and relaying). Never-the-less, events and approaches change and this is worth = discussing (again). =20 I think the architectural/protocol issues around the use of load = balancers have to be discussed as the current ALPN proposal may be = unbearable for many.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com > On Dec 5, 2014, at 8:43 AM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > Following up on the presentation at IETF-91 on this topic, [1] > we've created a new list [2] for moving that along. The list > description is: >=20 > "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." >=20 > If you're interested please join in. >=20 > Thanks to Vinod and Andrei for agreeing to admin the list. >=20 > We'll kick off discussion in a few days when folks have had > a chance to subscribe. >=20 > Cheers, > S. >=20 > PS: Please don't reply-all to this, join the new list, wait > a few days and then say what you need to say:-) >=20 > [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf > [2] https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Sat Dec 6 08:37:43 2014 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 436461A1B44; Sat, 6 Dec 2014 08:37:39 -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, 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 2z7G-g-__hDJ; Sat, 6 Dec 2014 08:37:37 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DABA91A0277; Sat, 6 Dec 2014 08:37:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A652BF14; Sat, 6 Dec 2014 16:37:36 +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 DDgfYUGTmNRA; Sat, 6 Dec 2014 16:37:33 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.46.31.148]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C193DBEFD; Sat, 6 Dec 2014 16:37:33 +0000 (GMT) Message-ID: <548330CC.20906@cs.tcd.ie> Date: Sat, 06 Dec 2014 16:37:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Phil Hunt References: <5481E0A7.2090604@cs.tcd.ie> <2DF4B463-DD15-42BE-85AE-121C14E19A8F@oracle.com> In-Reply-To: <2DF4B463-DD15-42BE-85AE-121C14E19A8F@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/Wq36bM7dgLBJ4MljWjWWdCsGPaM Cc: unbearable@ietf.org, oauth Subject: Re: [Unbearable] [http-auth] unbearable - new mailing list to discuss better than bearer tokens... 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: Sat, 06 Dec 2014 16:37:39 -0000 Hi Phil, Good points that need discussing but I'd suggest we give the new list a few days to allow folks to subscribe and then have that discussion. Thanks, S. On 06/12/14 16:08, Phil Hunt wrote: > On the surface (as currently presented) this work appears to duplicate the POP work going on in OAuth. The key difference is that this work is focused on using ALPN to bind tokens to the TLS channel. From a use case perspective it is very close to OAuth POP, and a specific use case of the current OAuth POP (proof of possession) architecture. > > I note that the OAuth WG had originally dropped TLS binding in part because TLS was not always end-to-end in cases where load-balancers where used. The identified use-cases required end-to-end proof of possession (e.g. to prevent token re-use and relaying). > > Never-the-less, events and approaches change and this is worth discussing (again). > > I think the architectural/protocol issues around the use of load balancers have to be discussed as the current ALPN proposal may be unbearable for many. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Dec 5, 2014, at 8:43 AM, Stephen Farrell wrote: >> >> >> Hiya, >> >> Following up on the presentation at IETF-91 on this topic, [1] >> we've created a new list [2] for moving that along. The list >> description is: >> >> "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." >> >> If you're interested please join in. >> >> Thanks to Vinod and Andrei for agreeing to admin the list. >> >> We'll kick off discussion in a few days when folks have had >> a chance to subscribe. >> >> Cheers, >> S. >> >> PS: Please don't reply-all to this, join the new list, wait >> a few days and then say what you need to say:-) >> >> [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf >> [2] https://www.ietf.org/mailman/listinfo/unbearable >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > From nobody Sat Dec 6 11:49:19 2014 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 369E21A1B15; Sat, 6 Dec 2014 11:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 swcoM4JQ5Uj4; Sat, 6 Dec 2014 11:49:14 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63EB1A1B06; Sat, 6 Dec 2014 11:49:14 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB6Jn8UE002342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Dec 2014 19:49:09 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB6Jn6iq006058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 6 Dec 2014 19:49:07 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB6Jn6E4028719; Sat, 6 Dec 2014 19:49:06 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 06 Dec 2014 11:49:06 -0800 References: <5481E0A7.2090604@cs.tcd.ie> <2DF4B463-DD15-42BE-85AE-121C14E19A8F@oracle.com> <548330CC.20906@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: <548330CC.20906@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B435) From: Phil Hunt Date: Sat, 6 Dec 2014 11:49:02 -0800 To: Stephen Farrell X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/37ZSbwfUgSZqio3mo-8hfxzB4js Cc: "unbearable@ietf.org" , oauth Subject: Re: [Unbearable] [http-auth] unbearable - new mailing list to discuss better than bearer tokens... 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: Sat, 06 Dec 2014 19:49:16 -0000 :-) Phil > On Dec 6, 2014, at 08:37, Stephen Farrell wrot= e: >=20 >=20 >=20 > Hi Phil, >=20 > Good points that need discussing but I'd suggest we give the new > list a few days to allow folks to subscribe and then have that > discussion. >=20 > Thanks, > S. >=20 >> On 06/12/14 16:08, Phil Hunt wrote: >> On the surface (as currently presented) this work appears to duplicate th= e POP work going on in OAuth. The key difference is that this work is focus= ed on using ALPN to bind tokens to the TLS channel. =46rom a use case perspe= ctive it is very close to OAuth POP, and a specific use case of the current O= Auth POP (proof of possession) architecture. >>=20 >> I note that the OAuth WG had originally dropped TLS binding in part becau= se TLS was not always end-to-end in cases where load-balancers where used. T= he identified use-cases required end-to-end proof of possession (e.g. to pre= vent token re-use and relaying). >>=20 >> Never-the-less, events and approaches change and this is worth discussing= (again). =20 >>=20 >> I think the architectural/protocol issues around the use of load balancer= s have to be discussed as the current ALPN proposal may be unbearable for ma= ny.=20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Dec 5, 2014, at 8:43 AM, Stephen Farrell w= rote: >>>=20 >>>=20 >>> Hiya, >>>=20 >>> Following up on the presentation at IETF-91 on this topic, [1] >>> we've created a new list [2] for moving that along. The list >>> description is: >>>=20 >>> "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." >>>=20 >>> If you're interested please join in. >>>=20 >>> Thanks to Vinod and Andrei for agreeing to admin the list. >>>=20 >>> We'll kick off discussion in a few days when folks have had >>> a chance to subscribe. >>>=20 >>> Cheers, >>> S. >>>=20 >>> PS: Please don't reply-all to this, join the new list, wait >>> a few days and then say what you need to say:-) >>>=20 >>> [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf >>> [2] https://www.ietf.org/mailman/listinfo/unbearable >>>=20 >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Mon Dec 8 07:48:39 2014 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 90EB91AD5F0; Fri, 5 Dec 2014 11:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kENfmRtF-wX7; Fri, 5 Dec 2014 11:18:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 692B01ACE9C; Fri, 5 Dec 2014 11:18:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141205191820.4189.348.idtracker@ietfa.amsl.com> Date: Fri, 05 Dec 2014 11:18:20 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/7ak91--8e_k_aqKwKdeRfixWUCE X-Mailman-Approved-At: Mon, 08 Dec 2014 07:48:37 -0800 Cc: Andrei.Popov@microsoft.com, vanupam@google.com, unbearable@ietf.org Subject: [Unbearable] New Non-WG Mailing List: unbearable X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 05 Dec 2014 19:18:21 -0000 A new IETF non-working group email list has been created. List address: unbearable@ietf.org Archive: http://www.ietf.org/mail-archive/web/unbearable/ To subscribe: https://www.ietf.org/mailman/listinfo/unbearable Purpose: This list is for discussion of proposals for doing better than bearer tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks. For additional information, please contact the list administrators. From nobody Mon Dec 8 07:50:13 2014 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 8AF901A00E2; Sat, 6 Dec 2014 11:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ismcMigpQVAO; Sat, 6 Dec 2014 11:19:49 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4AE1A03F9; Sat, 6 Dec 2014 11:19:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id C625BE2036; Sat, 6 Dec 2014 14:19:45 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 12320-01; Sat, 6 Dec 2014 14:19:36 -0500 (EST) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id D00C1E2034; Sat, 6 Dec 2014 14:19:35 -0500 (EST) Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id sB6JJYcu014824; Sat, 6 Dec 2014 14:19:34 -0500 From: Derek Atkins To: ietf@ietf.org References: <20141205191820.4189.348.idtracker@ietfa.amsl.com> Date: Sat, 06 Dec 2014 14:19:34 -0500 In-Reply-To: <20141205191820.4189.348.idtracker@ietfa.amsl.com> (IETF Secretariat's message of "Fri, 05 Dec 2014 11:18:20 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/-FetlKHGtfNbrcsopMW1tU_zX1s X-Mailman-Approved-At: Mon, 08 Dec 2014 07:50:12 -0800 Cc: Andrei.Popov@microsoft.com, unbearable@ietf.org, Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable 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: Sat, 06 Dec 2014 19:19:51 -0000 Hi, IETF Secretariat writes: > A new IETF non-working group email list has been created. > > List address: unbearable@ietf.org > Archive: http://www.ietf.org/mail-archive/web/unbearable/ > To subscribe: https://www.ietf.org/mailman/listinfo/unbearable > > Purpose: > > This list is for discussion of proposals for doing better than bearer > tokens (e.g. HTTP cookies, OAuth tokens etc.) for web > applications. The specific goal is chartering a WG focused on > preventing security token export and replay attacks. The OAUTH Working Group is already (and has been for a while!) looking into "holder of key" protocols to improve upon Bearer Tokens. I would suggest that this work happen there instead of creating a whole new group for it. -derek > For additional information, please contact the list administrators. -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Mon Dec 8 13:59:46 2014 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 703C61ACFEB; Mon, 8 Dec 2014 13:59:43 -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 BwAQUqQPV8QK; Mon, 8 Dec 2014 13:59:36 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23751A896F; Mon, 8 Dec 2014 13:59:36 -0800 (PST) Received: from DM2PR03CA0003.namprd03.prod.outlook.com (10.141.96.13) by BY1PR0301MB1208.namprd03.prod.outlook.com (25.161.203.16) with Microsoft SMTP Server (TLS) id 15.1.31.17; Mon, 8 Dec 2014 21:59:35 +0000 Received: from BN1AFFO11FD039.protection.gbl (2a01:111:f400:7c10::196) by DM2PR03CA0003.outlook.office365.com (2a01:111:e400:2428::13) with Microsoft SMTP Server (TLS) id 15.1.31.17 via Frontend Transport; Mon, 8 Dec 2014 21:59:34 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD039.mail.protection.outlook.com (10.58.52.243) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Mon, 8 Dec 2014 21:59:34 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.188]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0210.003; Mon, 8 Dec 2014 21:58:59 +0000 From: Mike Jones To: Derek Atkins , "ietf@ietf.org" Thread-Topic: [Unbearable] New Non-WG Mailing List: unbearable Thread-Index: AQHQEv5yAeyUxIlMxkakTLDZyjjio5yF11f/gABlmxA= Date: Mon, 8 Dec 2014 21:58:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BC15602@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141205191820.4189.348.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(377454003)(51704005)(13464003)(199003)(31966008)(69596002)(4396001)(104016003)(26826002)(54356999)(97736003)(23726002)(84676001)(19580405001)(15974865002)(50986999)(6806004)(19580395003)(107046002)(106116001)(81156004)(76176999)(77156002)(47776003)(64706001)(46102003)(20776003)(66066001)(46406003)(62966003)(50466002)(86612001)(2501002)(2656002)(97756001)(21056001)(106466001)(68736005)(55846006)(87936001)(85806002)(15975445007)(120916001)(86362001)(1720100001)(92566001)(33656002)(102836002)(99396003)(223123001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1208; H:mail.microsoft.com; FPR:; SPF:Pass; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1208; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(602002); SRVR:BY1PR0301MB1208; X-Forefront-PRVS: 041963B986 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB1208; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/C_aGc57k0hHYfBlW06Zqg3hzDaQ Cc: Andrei Popov , "unbearable@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable 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, 08 Dec 2014 21:59:43 -0000 It's my understanding that "Unbearable" is part of an effort to create a ne= w working group scoped to work on deliverables based upon these input docum= ents: http://tools.ietf.org/html/draft-balfanz-https-token-binding http://tools.ietf.org/html/draft-popov-token-binding I don't think that it was ever intended to cover every aspect of proof-of-p= ossession and so there's not actually any conflict with the work we're alre= ady doing in OAuth. (Nor does it seem to me to be productive to add even m= ore documents-in-flight to the OAuth working group at present.) Cheers, -- Mike -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Derek At= kins Sent: Saturday, December 06, 2014 11:20 AM To: ietf@ietf.org Cc: Andrei Popov; unbearable@ietf.org; Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable Hi, IETF Secretariat writes: > A new IETF non-working group email list has been created. > > List address: unbearable@ietf.org > Archive: http://www.ietf.org/mail-archive/web/unbearable/ > To subscribe: https://www.ietf.org/mailman/listinfo/unbearable > > Purpose: > > This list is for discussion of proposals for doing better than bearer=20 > tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications.=20 > The specific goal is chartering a WG focused on preventing security=20 > token export and replay attacks. The OAUTH Working Group is already (and has been for a while!) looking into= "holder of key" protocols to improve upon Bearer Tokens. I would suggest that this work happen there instead of creating a whole new= group for it. -derek > For additional information, please contact the list administrators. --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Mon Dec 8 14:54:28 2014 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 A652A1A00AE for ; Mon, 8 Dec 2014 14:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 qlyyjzX99V1w for ; Mon, 8 Dec 2014 14:54:25 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509041A007D for ; Mon, 8 Dec 2014 14:54:25 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so8500900wib.1 for ; Mon, 08 Dec 2014 14:54:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=fO/ulTHkFqqSJEWEl8p/3sF8VjPcwZhbB7RYsXJqyX4=; b=aGfG6gpGl1Hy2xtUMYGDelcu4EqN31IfDqcFNfGTdG+KmuCJemOGZi/dZ4hAF/ufKT pXpTXinqd1IkWISRZNiEA2dmWTCIFxj77woctRDOB/TnDGPoUMV0bBzTN1zA1AkS6hwv h29i3pJxSZGGpNn64UekB4DHoDkeUgcpGQulFMg4E83uXsN4KblbkU+OpxPVZqXVYHFN JfwBOmXGhVF0O9V8lHsm1k/HedcrAybp6CpO1q58xuTktXCQlcalpcRC31qatJn2Azyt 1lEeTnqLk/uRfwcOV0DUwVYccdt6h/rcUPzoF8Wtx/sB+6+m4isgj0KuS+YFMYVU7txn g0/g== X-Gm-Message-State: ALoCoQkZlBcCe4Gf987TMGKNgcHLEDQ07UJDJDKQYlGH3Zclf8IzR5e3nNaSBGzrWf1AcsEn516U X-Received: by 10.180.211.201 with SMTP id ne9mr26991206wic.30.1418079263951; Mon, 08 Dec 2014 14:54:23 -0800 (PST) Received: from [10.0.9.168] (b2b-92-50-69-180.unitymedia.biz. [92.50.69.180]) by mx.google.com with ESMTPSA id js5sm11478351wid.11.2014.12.08.14.54.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Dec 2014 14:54:22 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_362135CD-4383-41C1-BFD1-48FF2CA96083"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BC15602@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Mon, 8 Dec 2014 19:54:18 -0300 Message-Id: <282823ED-137E-4575-B5E8-B5FB840BCC11@ve7jtb.com> References: <20141205191820.4189.348.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BC15602@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Michael Jones X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/T7kaG_Nf3ZM8FIMMAbZ57_rv3fc Cc: "unbearable@ietf.org" , Andrei Popov , Derek Atkins , "ietf@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable 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, 08 Dec 2014 22:54:27 -0000 --Apple-Mail=_362135CD-4383-41C1-BFD1-48FF2CA96083 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We did discuss this at the last IETF meeting. While the work is closely related to the PoP work in OAuth it is not the = same. It will allow us to do PoP tokens for the implicit flow, = something that we haven't touched yet in OAuth because we don't have a = workable way to manage keys in the browser. This work should allow us = to do that. I think the slide deck examples showing JWT using different mechanisms = to express keys from the work done in the OAuth WG may be part of what = has some people concerned. I don't think these specs overlap with OAuth, but we do need to be = mindful of scope creep. As I stated at the F2F we need to have the two = groups work together, so that we can have PoP tokens via the browser. =20= John B. > On Dec 8, 2014, at 6:58 PM, Mike Jones = wrote: >=20 > It's my understanding that "Unbearable" is part of an effort to create = a new working group scoped to work on deliverables based upon these = input documents: >=20 > http://tools.ietf.org/html/draft-balfanz-https-token-binding > http://tools.ietf.org/html/draft-popov-token-binding >=20 > I don't think that it was ever intended to cover every aspect of = proof-of-possession and so there's not actually any conflict with the = work we're already doing in OAuth. (Nor does it seem to me to be = productive to add even more documents-in-flight to the OAuth working = group at present.) >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = Derek Atkins > Sent: Saturday, December 06, 2014 11:20 AM > To: ietf@ietf.org > Cc: Andrei Popov; unbearable@ietf.org; Stephen Farrell > Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable >=20 > Hi, >=20 > IETF Secretariat writes: >=20 >> A new IETF non-working group email list has been created. >>=20 >> List address: unbearable@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/unbearable/ >> To subscribe: https://www.ietf.org/mailman/listinfo/unbearable >>=20 >> Purpose: >>=20 >> This list is for discussion of proposals for doing better than bearer=20= >> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications.=20= >> The specific goal is chartering a WG focused on preventing security=20= >> token export and replay attacks. >=20 >=20 > The OAUTH Working Group is already (and has been for a while!) looking = into "holder of key" protocols to improve upon Bearer Tokens. >=20 > I would suggest that this work happen there instead of creating a = whole new group for it. >=20 > -derek >=20 >> For additional information, please contact the list administrators. >=20 > --=20 > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_362135CD-4383-41C1-BFD1-48FF2CA96083 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMDgyMjU0MThaMCMGCSqGSIb3DQEJBDEWBBTBVE2xQZOC8/VJiHqBeCJr y+1quDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBGZpDbjtxu+AHThkfy1w9wmMme5wpfmvRhbP2qHR1mM7vjqG9yC34B Ix8cjcniFNGUMLzho3Mf3zNcQgJqEtZkjTtWGM4zjUBD1cc8maB2w3LVIITvAjqaY2KIW0ZFm5Bi GQ8rNMk6qc8e1nndry+/Px6tOS7KbSgCH0QPSH0dFdXNKtbHatKnP7yjiv2LMKqhnglKQfJ9RrID A2PCLlSy8ag0p9kCdbKe3czcebt7xkwafwUQH0qO0PVwomcki2+GRfGpS3Bk5zR2CIbieKKcFAfB eYIz6lsv3nHxAaJqPBWxQMFprARxg/VjNNTbQneI/dDJXrsP7yRaMpMQULfhAAAAAAAA --Apple-Mail=_362135CD-4383-41C1-BFD1-48FF2CA96083-- From nobody Mon Dec 8 15:18:05 2014 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 B1DFA1A00A2; Mon, 8 Dec 2014 15:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 lOCbOVxXt-j3; Mon, 8 Dec 2014 15:17:47 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706241A0086; Mon, 8 Dec 2014 15:17:47 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB8NHfne012935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Dec 2014 23:17:42 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sB8NHYSY018833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Dec 2014 23:17:34 GMT Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB8NHYWA021156; Mon, 8 Dec 2014 23:17:34 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Dec 2014 15:17:33 -0800 References: <20141205191820.4189.348.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BC15602@TK5EX14MBXC286.redmond.corp.microsoft.com> <282823ED-137E-4575-B5E8-B5FB840BCC11@ve7jtb.com> Mime-Version: 1.0 (1.0) In-Reply-To: <282823ED-137E-4575-B5E8-B5FB840BCC11@ve7jtb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0FFD8ED9-3AE4-4CB7-871B-00C7881EEF54@oracle.com> X-Mailer: iPhone Mail (12B435) From: Phil Hunt Date: Mon, 8 Dec 2014 15:17:30 -0800 To: John Bradley X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/qHQg2K0N3mtZN_DsNJKrraxAhEA Cc: Andrei Popov , "ietf@ietf.org" , "unbearable@ietf.org" , Michael Jones , Derek Atkins , Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable 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, 08 Dec 2014 23:17:51 -0000 Maybe all token work should be together in its own WG? Phil > On Dec 8, 2014, at 14:54, John Bradley wrote: >=20 > We did discuss this at the last IETF meeting. >=20 > While the work is closely related to the PoP work in OAuth it is not the s= ame. It will allow us to do PoP tokens for the implicit flow, something tha= t we haven't touched yet in OAuth because we don't have a workable way to ma= nage keys in the browser. This work should allow us to do that. >=20 > I think the slide deck examples showing JWT using different mechanisms to e= xpress keys from the work done in the OAuth WG may be part of what has some p= eople concerned. >=20 > I don't think these specs overlap with OAuth, but we do need to be mindful= of scope creep. As I stated at the F2F we need to have the two groups wor= k together, so that we can have PoP tokens via the browser. =20 >=20 > John B. >=20 >=20 >> On Dec 8, 2014, at 6:58 PM, Mike Jones wrot= e: >>=20 >> It's my understanding that "Unbearable" is part of an effort to create a n= ew working group scoped to work on deliverables based upon these input docum= ents: >>=20 >> http://tools.ietf.org/html/draft-balfanz-https-token-binding >> http://tools.ietf.org/html/draft-popov-token-binding >>=20 >> I don't think that it was ever intended to cover every aspect of proof-of= -possession and so there's not actually any conflict with the work we're alr= eady doing in OAuth. (Nor does it seem to me to be productive to add even m= ore documents-in-flight to the OAuth working group at present.) >>=20 >> Cheers, >> -- Mike >>=20 >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Derek A= tkins >> Sent: Saturday, December 06, 2014 11:20 AM >> To: ietf@ietf.org >> Cc: Andrei Popov; unbearable@ietf.org; Stephen Farrell >> Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable >>=20 >> Hi, >>=20 >> IETF Secretariat writes: >>=20 >>> A new IETF non-working group email list has been created. >>>=20 >>> List address: unbearable@ietf.org >>> Archive: http://www.ietf.org/mail-archive/web/unbearable/ >>> To subscribe: https://www.ietf.org/mailman/listinfo/unbearable >>>=20 >>> Purpose: >>>=20 >>> This list is for discussion of proposals for doing better than bearer=20= >>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications.=20 >>> The specific goal is chartering a WG focused on preventing security=20 >>> token export and replay attacks. >>=20 >>=20 >> The OAUTH Working Group is already (and has been for a while!) looking in= to "holder of key" protocols to improve upon Bearer Tokens. >>=20 >> I would suggest that this work happen there instead of creating a whole n= ew group for it. >>=20 >> -derek >>=20 >>> For additional information, please contact the list administrators. >>=20 >> --=20 >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Mon Dec 8 15:19:50 2014 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 CE70C1A0073 for ; Mon, 8 Dec 2014 15:19:36 -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 E2q7G8VVzoOp for ; Mon, 8 Dec 2014 15:19:33 -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 5B7181A011F for ; Mon, 8 Dec 2014 15:19:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2D8CABEE5 for ; Mon, 8 Dec 2014 23:19:32 +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 Po0-m6dxTDcw for ; Mon, 8 Dec 2014 23:19:30 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.57.158]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D055ABED5 for ; Mon, 8 Dec 2014 23:19:30 +0000 (GMT) Message-ID: <54863200.4030600@cs.tcd.ie> Date: Mon, 08 Dec 2014 23:19:28 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: unbearable@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/hewquTFQnbni-8o-ZJ7KgKTuMk8 Subject: [Unbearable] one proposal for a charter - please dicsuss 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, 08 Dec 2014 23:19:37 -0000 Hi all, There's about 70+ people on the list now so let's kick off. Andrei sent Kathleen and I the charter proposal below a while ago. For myself I don't think its quite right yet but I'd rather hear what you all think. So please discuss... Cheers, S. 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 prevent 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 prevent security token export and replay attacks, 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. 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: March 2015: WG document for the Token Binding Protocol v1.0. March 2015: WG document for HTTPS Token Binding. November 2015: Token Binding Protocol v1.0 to IESG. November 2015: HTTPS Token Binding to IESG. From nobody Mon Dec 8 15:23:19 2014 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 DEEF51A0095; Mon, 8 Dec 2014 15:23:15 -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 P5VCQiAg2c0z; Mon, 8 Dec 2014 15:23:14 -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 7455F1A009E; Mon, 8 Dec 2014 15:23:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3956BBEE5; Mon, 8 Dec 2014 23:23:13 +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 cLdq1aoNpghF; Mon, 8 Dec 2014 23:23:11 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.57.158]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ABD37BED5; Mon, 8 Dec 2014 23:23:11 +0000 (GMT) Message-ID: <548632DD.8000504@cs.tcd.ie> Date: Mon, 08 Dec 2014 23:23:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Phil Hunt , John Bradley References: <20141205191820.4189.348.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BC15602@TK5EX14MBXC286.redmond.corp.microsoft.com> <282823ED-137E-4575-B5E8-B5FB840BCC11@ve7jtb.com> <0FFD8ED9-3AE4-4CB7-871B-00C7881EEF54@oracle.com> In-Reply-To: <0FFD8ED9-3AE4-4CB7-871B-00C7881EEF54@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/VqJ1nzw2hZVpSZpX8KFh7A4Ejgg Cc: "unbearable@ietf.org" , Andrei Popov , Derek Atkins , "ietf@ietf.org" , Michael Jones Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable 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, 08 Dec 2014 23:23:16 -0000 Hiya, As the sponsoring AD (or whatever term's correct) I've kicked off the discussion on the new list. [1] If you're interested then please subscribe there and discuss away. I really don't think we need to bother ietf@ietf.org with all the details. Thanks, Stephen. [1] https://www.ietf.org/mail-archive/web/unbearable/current/msg00008.html From nobody Mon Dec 8 15:42:05 2014 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 593EB1A0222 for ; Mon, 8 Dec 2014 15:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 qwuK2yzC7Ev1 for ; Mon, 8 Dec 2014 15:42:02 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204F11A00E1 for ; Mon, 8 Dec 2014 15:42:02 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so4789322lab.23 for ; Mon, 08 Dec 2014 15:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=abFp1KXy3BLnwWNdv9W+RQow1kKZsSSHUudnPdAWiDc=; b=DuEzFlViOR4QPkPabbh31Uwgx6OM8UClImRuNePKkfog5ly1h7cEHQP0PF4FWMl5XK c2sOES0GkGM76gtLaQ9FXD+QvSgDsyOKTSKGT52TT0hp7m9Vos9ymiIAi2tXFAH9g0eo mAjosNI6kIMGCDwkj66AITUJ+hSpwxqBt/BCc6r3hIgduVO1cAUeGHAhhgT7cfx+4xKj fxBMiRNJwdj/+Ti2fEDG4lRjPj8kylOzwFkifa9HqxZ9xI4iXJJhbL2Y7ySkOetCObdP ma6SB172GWyOkvrPBN0oTLgR3OTi2zW9J7RoE0eGOuav8Ar/DPHpyq2lSxDGwv9atOfy oXJw== MIME-Version: 1.0 X-Received: by 10.152.27.227 with SMTP id w3mr18831113lag.24.1418082120587; Mon, 08 Dec 2014 15:42:00 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Mon, 8 Dec 2014 15:42:00 -0800 (PST) In-Reply-To: <54863200.4030600@cs.tcd.ie> References: <54863200.4030600@cs.tcd.ie> Date: Mon, 8 Dec 2014 18:42:00 -0500 X-Google-Sender-Auth: axH2EJCHWgMCaf71fK0OOFzFVJg Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0158c2920f607b0509bcf932 Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/JsTXUiIMliyYQ2N5bgJqpBJrjRE Cc: unbearable@ietf.org Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 08 Dec 2014 23:42:04 -0000 --089e0158c2920f607b0509bcf932 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 8, 2014 at 6:19 PM, Stephen Farrell wrote: > > Hi all, > > There's about 70+ people on the list now so let's kick off. > > Andrei sent Kathleen and I the charter proposal below a while > ago. For myself I don't think its quite right yet but I'd > rather hear what you all think. So please discuss... > > Cheers, > S. > > > 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 prevent 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 prevent security token export and > replay attacks, 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. > Umm, I am still rather fuzzy about what is proposed here Stephen. In particular I don't think we are getting away from bearer tokens, we are just hiding them different. This is a draft I have been working on for a while. It allows a token to be bound to a HTTP/TLS channel. http://tools.ietf.org/html/draft-hallambaker-httpsession-03 It might help if we had a definition of bearer token. I don't think that formulation is helping. The problem is not that we have bearer tokens, it is that our proofs of possession force them to be disclosed in plaintext to the party checking them. Is an RSA private key a bearer token? How about a kerberos ticket? Presenting this as a problem with the token puts us off track. The problem is with the way we use them. --089e0158c2920f607b0509bcf932 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 8, 2014 at 6:19 PM, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farre= ll@cs.tcd.ie> wrote:

Hi all,

There's about 70+ people on the list now so let's kick off.

Andrei sent Kathleen and I the charter proposal below a while
ago. For myself I don't think its quite right yet but I'd
rather hear what you all think. So please discuss...

Cheers,
S.


Token Binding (TB)

Charter for Working Group

Web services generate various security tokens (e.g.=C2=A0 HTTP cookies, OAu= th
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 prevent such
attacks by cryptographically binding security tokens to the TLS layer.

The tasks of this working group are as follows:
1.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specify the Token Binding proto= col v1.0.
2.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specify the use of the Token Bi= nding protocol in
combination with HTTPS.

It is a goal of this working group to prevent security token export and
replay attacks, 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.

Umm, I am still rat= her fuzzy about what is proposed here Stephen.

In = particular I don't think we are getting away from bearer tokens, we are= just hiding them different.
=C2=A0
This is a draft I h= ave been working on for a while. It allows a token to be bound to a HTTP/TL= S channel.



It might = help if we had a definition of bearer token. I don't think that formula= tion is helping. The problem is not that we have bearer tokens, it is that = our proofs of possession force them to be disclosed in plaintext to the par= ty checking them.

Is an RSA private key a bearer t= oken?
How about a kerberos ticket?


<= /div>
Presenting this as a problem with the token puts us off track. Th= e problem is with the way we use them.

--089e0158c2920f607b0509bcf932-- From nobody Mon Dec 8 16:01:55 2014 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 520D31A03A5 for ; Mon, 8 Dec 2014 16:01:54 -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 K-1jXZ20UxJL for ; Mon, 8 Dec 2014 16:01:53 -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 147001A0370 for ; Mon, 8 Dec 2014 16:01:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DC5D7BEE5; Tue, 9 Dec 2014 00:01:51 +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 hpICRR_S7gah; Tue, 9 Dec 2014 00:01:50 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.57.158]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CB40CBE9A; Tue, 9 Dec 2014 00:01:50 +0000 (GMT) Message-ID: <54863BEC.9030505@cs.tcd.ie> Date: Tue, 09 Dec 2014 00:01:48 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <54863200.4030600@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/KMP_LsBbichpKRPx8A5QnEH9QKM Cc: unbearable@ietf.org Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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: Tue, 09 Dec 2014 00:01:54 -0000 Hi Phill, On 08/12/14 23:42, Phillip Hallam-Baker wrote: > Umm, I am still rather fuzzy about what is proposed here Stephen. 'tisn't my proposal so I'll let those who are making the proposal answer you in detail. The charter proposal came from Andrei and you can see the authors in the drafts listed there. That said, I do think the term bearer token is clear enough and private keys and kerberos tickets don't qualify as they won't be accepted if you just send them over the wire as-is. And from memory, yes, your draft was a proposal in roughly this space. (Roughly, since we're now in the process of figuring out the borders of "this space.") S. From nobody Mon Dec 8 18:23:34 2014 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 817A21A016A for ; Mon, 8 Dec 2014 18:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 7BSAFkPVzZmn for ; Mon, 8 Dec 2014 18:23:24 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A8D1A1AA2 for ; Mon, 8 Dec 2014 18:23:02 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so4937435lab.23 for ; Mon, 08 Dec 2014 18:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sBUN+INbttyGkDgvcVmlL0Vh8UWuW72lOguCJAmMU2Q=; b=P3pNvCl8/gb0lMQJAOPpYIcW9SKQ/eGBNxDicZB/xw2ctpeXqTW6Brxm8nrAnleUix BxRmiMC/+aA2dSRUpvmoNHYeSLlNN5TrL1Baq9PdFpvDQpmbo7GotR1nvGbBxxqKm6mo 5Hwv1aDyMhq34VnQQvrWjhefBOd03rPJtXgX2DBFcWtPJOw0UMB9DcZ1P7F/hvQduPc9 IgfUfAQ7GyUZr7Kcl3t8Vq160Gfj7BSF8SjZGQWw4iy1d8el10YUjHnaL2NiYaxiVEgw HDvyNPfh8+mitx4fDF7UXO7u9rNilVL+1NlOvdr5R2yy2k52VJHh1euZuZs+co99x2wh wSWg== MIME-Version: 1.0 X-Received: by 10.152.116.79 with SMTP id ju15mr19209179lab.84.1418091780940; Mon, 08 Dec 2014 18:23:00 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Mon, 8 Dec 2014 18:23:00 -0800 (PST) In-Reply-To: References: <54863200.4030600@cs.tcd.ie> Date: Mon, 8 Dec 2014 21:23:00 -0500 X-Google-Sender-Auth: TlxZyXJWWxys9RCoGKK1LQ7Sjsk Message-ID: From: Phillip Hallam-Baker To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11c34ec4dcabd40509bf38ab Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/xocqn8eRlLQPWIkUn0PEulVtMZA Cc: "unbearable@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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: Tue, 09 Dec 2014 02:23:27 -0000 --001a11c34ec4dcabd40509bf38ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 8, 2014 at 8:52 PM, Andrei Popov wrote: > Hi Phillip, > > > > =C3=98 In particular I don't think we are getting away from bearer token= s, we > are just hiding them different. > > > > The Token Binding Protocol I-D > provides a > mechanism for binding security tokens to the TLS layer. When a bound toke= n > is presented to a server, the server verifies the token binding and rejec= ts > the token if the binding verification fails. Therefore, such bound tokens > are not bearer tokens: they are resistant to export and replay attacks. > > > > =C3=98 This is a draft I have been working on for a while. It allows a t= oken > to be bound to a HTTP/TLS channel. > > > > I agree that your draft is designed to solve a similar problem, although > the approach you=E2=80=99ve taken is different in multiple ways. We can d= iscuss > these differences, but perhaps we should first focus on establishing the = WG > charter. > > > We have a lot of efforts in this space. What I think distinguishes them is the intended scope of use and which parts of the Web infrastructure it is proposed to change. One of the main constraints on the Web authentication/authorization proposals has been that they have to work with existing browsers. Accepting that constraint means a lot more corner cases that have to be considered and a weaker result. Another big difference is whether a bearer token has to be human friendly or not. If we are talking about credentials generated by machines for machines then we can go all 256 bit without penalty. If we have to deal with users then it gets a lot harder. --001a11c34ec4dcabd40509bf38ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 8, 2014 at 8:52 PM, Andrei Popov <Andrei.Popov@mi= crosoft.com> wrote:

Hi Phillip,

=C2=A0

=C3=98=C2=A0 In particular I don't think we are getting = away from bearer tokens, we are just hiding them different.

=C2=A0

The Token Binding Protocol I-D provides a mechanism for binding= security tokens to the TLS layer. When a bound token is presented to a ser= ver, the server verifies the token binding and rejects the token if the binding verification fails. Therefore, such bound tokens = are not bearer tokens: they are resistant to export and replay attacks.<= /u>

=C2=A0

=C3=98=C2=A0 This is a draft I have been working on for a wh= ile. It allows a token to be bound to a HTTP/TLS channel.

=C2=A0

I agree that your draft is designed t= o solve a similar problem, although the approach you=E2=80=99ve taken is di= fferent in multiple ways. We can discuss these differences, but perhaps we should first focus on establishing the WG charter.



We have a lot of efforts in this space. What I think distinguishes them is= the intended scope of use and which parts of the Web infrastructure it is = proposed to change.

One of the main constraints on= the Web authentication/authorization proposals has been that they have to = work with existing browsers. Accepting that constraint means a lot more cor= ner cases that have to be considered and a weaker result.=C2=A0
<= br>
Another big difference is whether a bearer token has to be hu= man friendly or not. If we are talking about credentials generated by machi= nes for machines then we can go all 256 bit without penalty. If we have to = deal with users then it gets a lot harder.



=C2=A0
--001a11c34ec4dcabd40509bf38ab-- From nobody Mon Dec 8 18:29:39 2014 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 0F5EE1A0360 for ; Mon, 8 Dec 2014 18:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 c-8pqt7oHvci for ; Mon, 8 Dec 2014 18:29:33 -0800 (PST) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5DA21A0070 for ; Mon, 8 Dec 2014 18:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1418092172; bh=nUT/2L3ZGwc0KBgqJZFqSBvrtszAqYbO1rm3vM55Pqs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=uKqS9Jyzn0omxpu79HyvVuval9aviGuwFKLJiUy1yMy15NgOOjIIuMQffTrHwmSorDyCtcAvTS2I5/4FO9tZA3R+Hi+MKVVxL99elEiLrchAqDFpUlKb+Rh4p1pX4IozOoodSx7bv/NrNDmqImMx/PAxdFjhKR/FH7igQEj84SMbJ6q0JA88GwuQbjgyk4Bexkbz2mKYU0/B59Ma4pvG+TUMUfUzv69aFnfXRvCu+cC7De00SxdKHMCa7IICiz7uWix43Y5OmVVqUkvjJrNkD0kit17Zn0aQLfyWTO2zIIAE6xuwgExdXFdI+WBeIGDOS2VCipRUSg7+VohDLnkVkg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=OmL4ER3IhnsFaa0Om/JutGezqTMYH6hDldEL64uwuyQOzDtOx0QO7nQd2SAdeL8Cg//6BhpY5dAGLnbrV10KkGXJM/51C6hi9dOq7BMQXMexx0qhz29LrDcYYzetj6bVxYIfI50jprYIPvZtSXx6lvboYwpxO7vqmdVtz3bmleaAgqwK9dpw2F0KO7fy8b1jTptRMENXrPtOGubLvvPmd7thSSjgzhKt7e2QGj3vlU/l9OuH01AxwPjU6dqiDkJUUdPS2tPdfmUzeFbOiZNr2x1FJGamnUXoakMMmC7uOz29rWVXFz73QaKkuP1Bna09FBXHtvb2hNZYuW6mLH3i3g==; Received: from [98.139.215.142] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 09 Dec 2014 02:29:32 -0000 Received: from [98.139.212.195] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 09 Dec 2014 02:29:31 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 09 Dec 2014 02:29:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 959234.80954.bm@omp1004.mail.bf1.yahoo.com X-YMail-OSG: 6kApyZwVM1lyEBJPP2sRHrR.9vdQbyBWhn_vZaOkTBLOqLRDIK26Nzr3bdCuk44 iq9RvarTnvUHNTnzdQQxEnn47QCv4O3Pf41I6od29GSTBjuOw8uIXBDixI0LtktUmMT3ppcvnQGU FLLNS8.g0zFRNeYBxyhbiraAgTsGh9Uhs6M0l__EzePFqc11D2g5J0Kf8kNJRxrO_gRDtYLMVZv3 NCHVbLZdsQwX3R4xjwSAbZmaDtBFfxJlpyUciA6jU8ycztq5gngNh5B8BWKP0VvVnPTRwPa.oRsP bzah0Sd_SpuRdtb._4mFPqHTlXKw3HoYuDo_qdrFHrIoytEElWjXX81HENsXfEJzGVIG3ubTNkG6 4YYEOYm5a1ynL5ok5hjSwH_ZMbBL6ElHy6EVJCognV_irclLB9w8Sjf6angslR59Vr68kjWoUiBJ KKHvbGTOmd5Va95aqsaBKJZ09VUSt4GSg9pO07aG23_qW4v4fRgSDf8oXwnWjxysLd3Rqoe1lJ4i rvlDFhmjHODrJHLcweGR7y7CJ5mmHPCqA4dibTck6tr4Ofs9QnqyFH_OyGyoc2DI- Received: by 66.196.81.110; Tue, 09 Dec 2014 02:29:31 +0000 Date: Tue, 9 Dec 2014 02:29:31 +0000 (UTC) From: Bill Mills To: Phil Hunt , John Bradley , "unbearable@ietf.org" Message-ID: <1104038573.7012868.1418092171193.JavaMail.yahoo@jws10607.mail.bf1.yahoo.com> In-Reply-To: <0FFD8ED9-3AE4-4CB7-871B-00C7881EEF54@oracle.com> References: <0FFD8ED9-3AE4-4CB7-871B-00C7881EEF54@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7012867_1312782753.1418092171186" Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/UCMwSIpg9KKYcbHgVa8h82fjejo Cc: Andrei Popov , Derek Atkins , Michael Jones , Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills 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: Tue, 09 Dec 2014 02:29:35 -0000 ------=_Part_7012867_1312782753.1418092171186 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Splitting work on POP tokens between N>1 WG is almost certainly wrong if t= hat's what we're doing. =C2=A0 In the 2 drafts Mike J. pasted I find the use of the term "TLS Binding" con= fusing here because it's dangerously close to "Channel Binding" which is *n= ot* what these drafts are talking about. =C2=A0If we are in fact doing chan= nel binding then that's the term we should be using. =C2=A0Are these drafts= intended to allow a trust relationship to be built on the client secret es= tablished during authentication, and that secret is then used to bring chan= nel binding down into the HTTP layer?=C2=A0 On Monday, December 8, 2014 3:18 PM, Phil Hunt = wrote: =20 Maybe all token work should be together in its own WG? Phil > On Dec 8, 2014, at 14:54, John Bradley wrote: >=20 > We did discuss this at the last IETF meeting. >=20 > While the work is closely related to the PoP work in OAuth it is not the = same.=C2=A0 It will allow us to do PoP tokens for the implicit flow, someth= ing that we haven't touched yet in OAuth because we don't have a workable w= ay to manage keys in the browser.=C2=A0 This work should allow us to do tha= t. >=20 > I think the slide deck examples showing JWT using different mechanisms to= express keys from the work done in the OAuth WG may be part of what has so= me people concerned. >=20 > I don't think these specs overlap with OAuth, but we do need to be mindfu= l of scope creep.=C2=A0 As I stated at the F2F we need to have the two grou= ps work together, so that we can have PoP tokens via the browser.=C2=A0=20 >=20 > John B. >=20 >=20 >> On Dec 8, 2014, at 6:58 PM, Mike Jones wro= te: >>=20 >> It's my understanding that "Unbearable" is part of an effort to create a= new working group scoped to work on deliverables based upon these input do= cuments: >>=20 >> http://tools.ietf.org/html/draft-balfanz-https-token-binding >> http://tools.ietf.org/html/draft-popov-token-binding >>=20 >> I don't think that it was ever intended to cover every aspect of proof-o= f-possession and so there's not actually any conflict with the work we're a= lready doing in OAuth.=C2=A0 (Nor does it seem to me to be productive to ad= d even more documents-in-flight to the OAuth working group at present.) >>=20 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers, >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike >>=20 >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Derek= Atkins >> Sent: Saturday, December 06, 2014 11:20 AM >> To: ietf@ietf.org >> Cc: Andrei Popov; unbearable@ietf.org; Stephen Farrell >> Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable >>=20 >> Hi, >>=20 >> IETF Secretariat writes: >>=20 >>> A new IETF non-working group email list has been created. >>>=20 >>> List address: unbearable@ietf.org >>> Archive: http://www.ietf.org/mail-archive/web/unbearable/ >>> To subscribe: https://www.ietf.org/mailman/listinfo/unbearable >>>=20 >>> Purpose: >>>=20 >>> This list is for discussion of proposals for doing better than bearer= =20 >>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications.=20 >>> The specific goal is chartering a WG focused on preventing security=20 >>> token export and replay attacks. >>=20 >>=20 >> The OAUTH Working Group is already (and has been for a while!) looking i= nto "holder of key" protocols to improve upon Bearer Tokens. >>=20 >> I would suggest that this work happen there instead of creating a whole = new group for it. >>=20 >> -derek >>=20 >>> For additional information, please contact the list administrators. >>=20 >> --=20 >>=C2=A0 =C2=A0 =C2=A0 Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 617-623-3745 >>=C2=A0 =C2=A0 =C2=A0 derek@ihtfp.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 www.ihtfp.com >>=C2=A0 =C2=A0 =C2=A0 Computer and Internet Security Consultant >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > 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 ------=_Part_7012867_1312782753.1418092171186 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Splitting work on POP tokens between N>1 WG is almost certainl= y wrong if that's what we're doing.  

In t= he 2 drafts Mike J. pasted I find the use of the term "TLS Binding" confusi= ng here because it's dangerously close to "Channel Binding" which is *not* = what these drafts are talking about.  If we are in fact doing channel = binding then that's the term we should be using.  Are these drafts int= ended to allow a trust relationship to be built on the client secret establ= ished during authentication, and that secret is then used to bring channel = binding down into the HTTP layer? 


On Monday, December 8, 2014 3:18 PM, Phil Hunt &= lt;phil.hunt@oracle.com> wrote:


Maybe all toke= n work should be together in its own WG?

Phil

> On Dec 8, = 2014, at 14:54, John Bradley <ve7jtb@ve7jtb.com> wrote:
> > We did discuss this at the last IETF meeting.
>
> While= the work is closely related to the PoP work in OAuth it is not the same.&n= bsp; It will allow us to do PoP tokens for the implicit flow, something tha= t we haven't touched yet in OAuth because we don't have a workable way to m= anage keys in the browser.  This work should allow us to do that.
= >
> I think the slide deck examples showing JWT using different m= echanisms to express keys from the work done in the OAuth WG may be part of= what has some people concerned.
>
> I don't think these specs= overlap with OAuth, but we do need to be mindful of scope creep.  As= I stated at the F2F we need to have the two groups work together, so that = we can have PoP tokens via the browser. 
>
> John B.
= >
>
>> On Dec 8, 2014, at 6:58 PM, Mike Jones <Michael.Jones@microso= ft.com> wrote:
>>
>> It's my understanding that "= Unbearable" is part of an effort to create a new working group scoped to wo= rk on deliverables based upon these input documents:
>>
>&g= t; http://tools.iet= f.org/html/draft-balfanz-https-token-binding
>> http://tools.ietf.org/html/draft-popov-to= ken-binding
>>
>> I don't think that it was ever int= ended to cover every aspect of proof-of-possession and so there's not actua= lly any conflict with the work we're already doing in OAuth.  (Nor doe= s it seem to me to be productive to add even more documents-in-flight to th= e OAuth working group at present.)
>>
>>    &n= bsp;           Cheers,
>>    &n= bsp;           -- Mike
>>
>> --= ---Original Message-----
>> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Derek Atkins
>>= ; Sent: Saturday, December 06, 2014 11:20 AM
>> To: ietf@ietf.org
&g= t;> Cc: Andrei Popov; unbearable@ietf.org; Stephen Farrell
>= ;> Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable
>= >
>> Hi,
>>
>> IETF Secretariat <ietf-secretariat@ietf.org> writes:
>>
>>&= gt; A new IETF non-working group email list has been created.
>>&g= t;
>>> List address: unbearable@ietf.org
>>>= ; Archive: http://www.ietf.org/mail-archive/web/unbearable/
>= >> To subscribe: https://www.ietf.org/mailman/listinfo/unbearable=
>>>
>>> Purpose:
>>>
>>= > This list is for discussion of proposals for doing better than bearer =
>>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web appl= ications.
>>> The specific goal is chartering a WG focused on = preventing security
>>> token export and replay attacks.
&g= t;>
>>
>> The OAUTH Working Group is already (and ha= s been for a while!) looking into "holder of key" protocols to improve upon= Bearer Tokens.
>>
>> I would suggest that this work hap= pen there instead of creating a whole new group for it.
>>
>= ;> -derek
>>
>>> For additional information, pleas= e contact the list administrators.
>>
>> --
>>=       Derek Atkins            =     617-623-3745
>>      derek@ihtfp.com&= nbsp;           www.ihtfp.com
>>  &= nbsp;   Computer and Internet Security Consultant
>>
>= > _______________________________________________
>> Unbearable= mailing list
>> Unbearable@ietf.org
>> https:= //www.ietf.org/mailman/listinfo/unbearable
>>
>> ___= ____________________________________________
>> Unbearable mailing= list
>> Unbearable@ietf.org
>> https://www.ie= tf.org/mailman/listinfo/unbearable
>
> ___________________= ____________________________
> Unbearable mailing list
> Unb= earable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbe= arable

_______________________________________________
Unbear= able mailing list
Unbearable@ietf.org
https://www.ietf.org= /mailman/listinfo/unbearable


<= /div> ------=_Part_7012867_1312782753.1418092171186-- From nobody Mon Dec 8 18:31:29 2014 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 19BBC1A0379 for ; Mon, 8 Dec 2014 17:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 HJvoPGoJtm9N for ; Mon, 8 Dec 2014 17:52:37 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994581A02F1 for ; Mon, 8 Dec 2014 17:52:36 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.31.17; Tue, 9 Dec 2014 01:52:34 +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.0031.000; Tue, 9 Dec 2014 01:52:34 +0000 From: Andrei Popov To: Phillip Hallam-Baker , Stephen Farrell Thread-Topic: [Unbearable] one proposal for a charter - please dicsuss Thread-Index: AQHQEz13HUkUpVDAykapHgbkfe3625yGWqQAgAAcnYA= Date: Tue, 9 Dec 2014 01:52:34 +0000 Message-ID: References: <54863200.4030600@cs.tcd.ie> 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::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1252; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; x-forefront-prvs: 0420213CCD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(199003)(377454003)(24454002)(189002)(16236675004)(86362001)(33656002)(86612001)(19300405004)(50986999)(106356001)(77156002)(62966003)(21056001)(92566001)(54206007)(107046002)(561944003)(99396003)(76176999)(40100003)(46102003)(19609705001)(120916001)(19625215002)(54606007)(122556002)(19617315012)(19580395003)(76576001)(20776003)(87936001)(2656002)(68736005)(74316001)(99286002)(64706001)(106116001)(105586002)(97736003)(4396001)(31966008)(19580405001)(54356999)(101416001)(15975445007)(102836002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1250C495221827422B8C22A88C650BN3PR0301MB1250_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/OXW59xX60biKtwVrrzdn8dzLeFA X-Mailman-Approved-At: Mon, 08 Dec 2014 18:31:27 -0800 Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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: Tue, 09 Dec 2014 01:52:40 -0000 --_000_BN3PR0301MB1250C495221827422B8C22A88C650BN3PR0301MB1250_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbGxpcCwNCg0KDQrDmCAgSW4gcGFydGljdWxhciBJIGRvbid0IHRoaW5rIHdlIGFyZSBn ZXR0aW5nIGF3YXkgZnJvbSBiZWFyZXIgdG9rZW5zLCB3ZSBhcmUganVzdCBoaWRpbmcgdGhlbSBk aWZmZXJlbnQuDQoNClRoZSBUb2tlbiBCaW5kaW5nIFByb3RvY29sIEktRDxodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1wb3Bvdi10b2tlbi1iaW5kaW5nLTAwPiBwcm92aWRlcyBhIG1l Y2hhbmlzbSBmb3IgYmluZGluZyBzZWN1cml0eSB0b2tlbnMgdG8gdGhlIFRMUyBsYXllci4gV2hl biBhIGJvdW5kIHRva2VuIGlzIHByZXNlbnRlZCB0byBhIHNlcnZlciwgdGhlIHNlcnZlciB2ZXJp ZmllcyB0aGUgdG9rZW4gYmluZGluZyBhbmQgcmVqZWN0cyB0aGUgdG9rZW4gaWYgdGhlIGJpbmRp bmcgdmVyaWZpY2F0aW9uIGZhaWxzLiBUaGVyZWZvcmUsIHN1Y2ggYm91bmQgdG9rZW5zIGFyZSBu b3QgYmVhcmVyIHRva2VuczogdGhleSBhcmUgcmVzaXN0YW50IHRvIGV4cG9ydCBhbmQgcmVwbGF5 IGF0dGFja3MuDQoNCg0Kw5ggIFRoaXMgaXMgYSBkcmFmdCBJIGhhdmUgYmVlbiB3b3JraW5nIG9u IGZvciBhIHdoaWxlLiBJdCBhbGxvd3MgYSB0b2tlbiB0byBiZSBib3VuZCB0byBhIEhUVFAvVExT IGNoYW5uZWwuDQoNCkkgYWdyZWUgdGhhdCB5b3VyIGRyYWZ0IGlzIGRlc2lnbmVkIHRvIHNvbHZl IGEgc2ltaWxhciBwcm9ibGVtLCBhbHRob3VnaCB0aGUgYXBwcm9hY2ggeW914oCZdmUgdGFrZW4g aXMgZGlmZmVyZW50IGluIG11bHRpcGxlIHdheXMuIFdlIGNhbiBkaXNjdXNzIHRoZXNlIGRpZmZl cmVuY2VzLCBidXQgcGVyaGFwcyB3ZSBzaG91bGQgZmlyc3QgZm9jdXMgb24gZXN0YWJsaXNoaW5n IHRoZSBXRyBjaGFydGVyLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBVbmJlYXJhYmxl IFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGhpbGxp cCBIYWxsYW0tQmFrZXINClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgOCwgMjAxNCAzOjQyIFBNDQpU bzogU3RlcGhlbiBGYXJyZWxsDQpDYzogdW5iZWFyYWJsZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtVbmJlYXJhYmxlXSBvbmUgcHJvcG9zYWwgZm9yIGEgY2hhcnRlciAtIHBsZWFzZSBkaWNzdXNz DQoNCg0KDQpPbiBNb24sIERlYyA4LCAyMDE0IGF0IDY6MTkgUE0sIFN0ZXBoZW4gRmFycmVsbCA8 c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTxtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5p ZT4+IHdyb3RlOg0KDQpIaSBhbGwsDQoNClRoZXJlJ3MgYWJvdXQgNzArIHBlb3BsZSBvbiB0aGUg bGlzdCBub3cgc28gbGV0J3Mga2ljayBvZmYuDQoNCkFuZHJlaSBzZW50IEthdGhsZWVuIGFuZCBJ IHRoZSBjaGFydGVyIHByb3Bvc2FsIGJlbG93IGEgd2hpbGUNCmFnby4gRm9yIG15c2VsZiBJIGRv bid0IHRoaW5rIGl0cyBxdWl0ZSByaWdodCB5ZXQgYnV0IEknZA0KcmF0aGVyIGhlYXIgd2hhdCB5 b3UgYWxsIHRoaW5rLiBTbyBwbGVhc2UgZGlzY3Vzcy4uLg0KDQpDaGVlcnMsDQpTLg0KDQoNClRv a2VuIEJpbmRpbmcgKFRCKQ0KDQpDaGFydGVyIGZvciBXb3JraW5nIEdyb3VwDQoNCldlYiBzZXJ2 aWNlcyBnZW5lcmF0ZSB2YXJpb3VzIHNlY3VyaXR5IHRva2VucyAoZS5nLiAgSFRUUCBjb29raWVz LCBPQXV0aA0KdG9rZW5zLCBldGMuKSBmb3Igd2ViIGFwcGxpY2F0aW9ucyB0byBhY2Nlc3MgcHJv dGVjdGVkIHJlc291cmNlcy4NCkN1cnJlbnRseSB0aGVzZSBhcmUgYmVhcmVyIHRva2VucywgaS5l LiBhbnkgcGFydHkgaW4gcG9zc2Vzc2lvbiBvZiBzdWNoDQp0b2tlbiBnYWlucyBhY2Nlc3MgdG8g dGhlIHByb3RlY3RlZCByZXNvdXJjZS4gQXR0YWNrZXJzIGV4cG9ydCBiZWFyZXINCnRva2VucyBm cm9tIGNsaWVudCBtYWNoaW5lcyBvciBmcm9tIGNvbXByb21pc2VkIG5ldHdvcmsgY29ubmVjdGlv bnMsDQpwcmVzZW50IHRoZXNlIGJlYXJlciB0b2tlbnMgdG8gV2ViIHNlcnZpY2VzLCBhbmQgaW1w ZXJzb25hdGUNCmF1dGhlbnRpY2F0ZWQgdXNlcnMuIFRoZSBpZGVhIG9mIFRva2VuIEJpbmRpbmcg aXMgdG8gcHJldmVudCBzdWNoDQphdHRhY2tzIGJ5IGNyeXB0b2dyYXBoaWNhbGx5IGJpbmRpbmcg c2VjdXJpdHkgdG9rZW5zIHRvIHRoZSBUTFMgbGF5ZXIuDQoNClRoZSB0YXNrcyBvZiB0aGlzIHdv cmtpbmcgZ3JvdXAgYXJlIGFzIGZvbGxvd3M6DQoxLiAgICAgICAgICAgIFNwZWNpZnkgdGhlIFRv a2VuIEJpbmRpbmcgcHJvdG9jb2wgdjEuMC4NCjIuICAgICAgICAgICAgU3BlY2lmeSB0aGUgdXNl IG9mIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sIGluDQpjb21iaW5hdGlvbiB3aXRoIEhUVFBT Lg0KDQpJdCBpcyBhIGdvYWwgb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRvIHByZXZlbnQgc2VjdXJp dHkgdG9rZW4gZXhwb3J0IGFuZA0KcmVwbGF5IGF0dGFja3MsIGJ1dCBvdGhlciBpc3N1ZXMgYXNz b2NpYXRlZCB3aXRoIHRoZSB1c2Ugb2Ygc2VjdXJpdHkNCnRva2VucyBhcmUgb3V0IG9mIHNjb3Bl LiBJdCBpcyBhIGdvYWwgb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRvIGRlc2lnbg0KdGhlIFRva2Vu IEJpbmRpbmcgcHJvdG9jb2wgc3VjaCB0aGF0IGl0IHdvdWxkIGJlIGFsc28gdXNlYWJsZSB3aXRo DQphcHBsaWNhdGlvbiBwcm90b2NvbHMgb3RoZXIgdGhhbiBIVFRQUywgaG93ZXZlciBzcGVjaWZ5 aW5nIHN1Y2ggdXNlcyBpcw0Kbm90IGEgcHJpbWFyeSBnb2FsLg0KDQpVbW0sIEkgYW0gc3RpbGwg cmF0aGVyIGZ1enp5IGFib3V0IHdoYXQgaXMgcHJvcG9zZWQgaGVyZSBTdGVwaGVuLg0KDQpJbiBw YXJ0aWN1bGFyIEkgZG9uJ3QgdGhpbmsgd2UgYXJlIGdldHRpbmcgYXdheSBmcm9tIGJlYXJlciB0 b2tlbnMsIHdlIGFyZSBqdXN0IGhpZGluZyB0aGVtIGRpZmZlcmVudC4NCg0KVGhpcyBpcyBhIGRy YWZ0IEkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gZm9yIGEgd2hpbGUuIEl0IGFsbG93cyBhIHRva2Vu IHRvIGJlIGJvdW5kIHRvIGEgSFRUUC9UTFMgY2hhbm5lbC4NCg0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaGFsbGFtYmFrZXItaHR0cHNlc3Npb24tMDMNCg0KDQpJdCBtaWdodCBo ZWxwIGlmIHdlIGhhZCBhIGRlZmluaXRpb24gb2YgYmVhcmVyIHRva2VuLiBJIGRvbid0IHRoaW5r IHRoYXQgZm9ybXVsYXRpb24gaXMgaGVscGluZy4gVGhlIHByb2JsZW0gaXMgbm90IHRoYXQgd2Ug aGF2ZSBiZWFyZXIgdG9rZW5zLCBpdCBpcyB0aGF0IG91ciBwcm9vZnMgb2YgcG9zc2Vzc2lvbiBm b3JjZSB0aGVtIHRvIGJlIGRpc2Nsb3NlZCBpbiBwbGFpbnRleHQgdG8gdGhlIHBhcnR5IGNoZWNr aW5nIHRoZW0uDQoNCklzIGFuIFJTQSBwcml2YXRlIGtleSBhIGJlYXJlciB0b2tlbj8NCkhvdyBh Ym91dCBhIGtlcmJlcm9zIHRpY2tldD8NCg0KDQpQcmVzZW50aW5nIHRoaXMgYXMgYSBwcm9ibGVt IHdpdGggdGhlIHRva2VuIHB1dHMgdXMgb2ZmIHRyYWNrLiBUaGUgcHJvYmxlbSBpcyB3aXRoIHRo ZSB3YXkgd2UgdXNlIHRoZW0uDQoNCg== --_000_BN3PR0301MB1250C495221827422B8C22A88C650BN3PR0301MB1250_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBv c2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTcwMzgyNjA3MTsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0MjE5NDIxNjQgLTIyMDY2MDcyMCA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgUGhp bGxpcCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JbiBwYXJ0aWN1bGFyIEkgZG9uJ3QgdGhpbmsg d2UgYXJlIGdldHRpbmcgYXdheSBmcm9tIGJlYXJlciB0b2tlbnMsIHdlIGFyZSBqdXN0IGhpZGlu ZyB0aGVtIGRpZmZlcmVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhl DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wb3Bvdi10b2tlbi1i aW5kaW5nLTAwIj5Ub2tlbiBCaW5kaW5nIFByb3RvY29sIEktRDwvYT4gcHJvdmlkZXMgYSBtZWNo YW5pc20gZm9yIGJpbmRpbmcgc2VjdXJpdHkgdG9rZW5zIHRvIHRoZSBUTFMgbGF5ZXIuIFdoZW4g YSBib3VuZCB0b2tlbiBpcyBwcmVzZW50ZWQgdG8gYSBzZXJ2ZXIsIHRoZSBzZXJ2ZXIgdmVyaWZp ZXMgdGhlIHRva2VuIGJpbmRpbmcgYW5kIHJlamVjdHMNCiB0aGUgdG9rZW4gaWYgdGhlIGJpbmRp bmcgdmVyaWZpY2F0aW9uIGZhaWxzLiBUaGVyZWZvcmUsIHN1Y2ggYm91bmQgdG9rZW5zIGFyZSBu b3QgYmVhcmVyIHRva2VuczogdGhleSBhcmUgcmVzaXN0YW50IHRvIGV4cG9ydCBhbmQgcmVwbGF5 IGF0dGFja3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhpcyBpcyBhIGRyYWZ0IEkgaGF2ZSBi ZWVuIHdvcmtpbmcgb24gZm9yIGEgd2hpbGUuIEl0IGFsbG93cyBhIHRva2VuIHRvIGJlIGJvdW5k IHRvIGEgSFRUUC9UTFMgY2hhbm5lbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SSBhZ3JlZSB0aGF0IHlvdXIgZHJhZnQgaXMgZGVzaWduZWQgdG8gc29sdmUgYSBzaW1pbGFy IHByb2JsZW0sIGFsdGhvdWdoIHRoZSBhcHByb2FjaCB5b3XigJl2ZSB0YWtlbiBpcyBkaWZmZXJl bnQgaW4gbXVsdGlwbGUgd2F5cy4gV2UgY2FuIGRpc2N1c3MgdGhlc2UgZGlmZmVyZW5jZXMsDQog YnV0IHBlcmhhcHMgd2Ugc2hvdWxkIGZpcnN0IGZvY3VzIG9uIGVzdGFibGlzaGluZyB0aGUgV0cg Y2hhcnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVy cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5QaGlsbGlwIEhhbGxhbS1CYWtlcjxicj4NCjxiPlNlbnQ6PC9iPiBN b25kYXksIERlY2VtYmVyIDgsIDIwMTQgMzo0MiBQTTxicj4NCjxiPlRvOjwvYj4gU3RlcGhlbiBG YXJyZWxsPGJyPg0KPGI+Q2M6PC9iPiB1bmJlYXJhYmxlQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gb25lIHByb3Bvc2FsIGZvciBhIGNoYXJ0ZXIgLSBwbGVh c2UgZGljc3VzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRGVjIDgsIDIwMTQg YXQgNjoxOSBQTSwgU3RlcGhlbiBGYXJyZWxsICZsdDs8YSBocmVmPSJtYWlsdG86c3RlcGhlbi5m YXJyZWxsQGNzLnRjZC5pZSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2Qu aWU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQpIaSBhbGwsPGJyPg0KPGJyPg0KVGhlcmUncyBhYm91dCA3MCYjNDM7 IHBlb3BsZSBvbiB0aGUgbGlzdCBub3cgc28gbGV0J3Mga2ljayBvZmYuPGJyPg0KPGJyPg0KQW5k cmVpIHNlbnQgS2F0aGxlZW4gYW5kIEkgdGhlIGNoYXJ0ZXIgcHJvcG9zYWwgYmVsb3cgYSB3aGls ZTxicj4NCmFnby4gRm9yIG15c2VsZiBJIGRvbid0IHRoaW5rIGl0cyBxdWl0ZSByaWdodCB5ZXQg YnV0IEknZDxicj4NCnJhdGhlciBoZWFyIHdoYXQgeW91IGFsbCB0aGluay4gU28gcGxlYXNlIGRp c2N1c3MuLi48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KUy48YnI+DQo8YnI+DQo8YnI+DQpUb2tl biBCaW5kaW5nIChUQik8YnI+DQo8YnI+DQpDaGFydGVyIGZvciBXb3JraW5nIEdyb3VwPGJyPg0K PGJyPg0KV2ViIHNlcnZpY2VzIGdlbmVyYXRlIHZhcmlvdXMgc2VjdXJpdHkgdG9rZW5zIChlLmcu Jm5ic3A7IEhUVFAgY29va2llcywgT0F1dGg8YnI+DQp0b2tlbnMsIGV0Yy4pIGZvciB3ZWIgYXBw bGljYXRpb25zIHRvIGFjY2VzcyBwcm90ZWN0ZWQgcmVzb3VyY2VzLjxicj4NCkN1cnJlbnRseSB0 aGVzZSBhcmUgYmVhcmVyIHRva2VucywgaS5lLiBhbnkgcGFydHkgaW4gcG9zc2Vzc2lvbiBvZiBz dWNoPGJyPg0KdG9rZW4gZ2FpbnMgYWNjZXNzIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UuIEF0 dGFja2VycyBleHBvcnQgYmVhcmVyPGJyPg0KdG9rZW5zIGZyb20gY2xpZW50IG1hY2hpbmVzIG9y IGZyb20gY29tcHJvbWlzZWQgbmV0d29yayBjb25uZWN0aW9ucyw8YnI+DQpwcmVzZW50IHRoZXNl IGJlYXJlciB0b2tlbnMgdG8gV2ViIHNlcnZpY2VzLCBhbmQgaW1wZXJzb25hdGU8YnI+DQphdXRo ZW50aWNhdGVkIHVzZXJzLiBUaGUgaWRlYSBvZiBUb2tlbiBCaW5kaW5nIGlzIHRvIHByZXZlbnQg c3VjaDxicj4NCmF0dGFja3MgYnkgY3J5cHRvZ3JhcGhpY2FsbHkgYmluZGluZyBzZWN1cml0eSB0 b2tlbnMgdG8gdGhlIFRMUyBsYXllci48YnI+DQo8YnI+DQpUaGUgdGFza3Mgb2YgdGhpcyB3b3Jr aW5nIGdyb3VwIGFyZSBhcyBmb2xsb3dzOjxicj4NCjEuJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgU3BlY2lmeSB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCB2MS4w Ljxicj4NCjIuJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU3BlY2lm eSB0aGUgdXNlIG9mIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sIGluPGJyPg0KY29tYmluYXRp b24gd2l0aCBIVFRQUy48YnI+DQo8YnI+DQpJdCBpcyBhIGdvYWwgb2YgdGhpcyB3b3JraW5nIGdy b3VwIHRvIHByZXZlbnQgc2VjdXJpdHkgdG9rZW4gZXhwb3J0IGFuZDxicj4NCnJlcGxheSBhdHRh Y2tzLCBidXQgb3RoZXIgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgdXNlIG9mIHNlY3VyaXR5 PGJyPg0KdG9rZW5zIGFyZSBvdXQgb2Ygc2NvcGUuIEl0IGlzIGEgZ29hbCBvZiB0aGlzIHdvcmtp bmcgZ3JvdXAgdG8gZGVzaWduPGJyPg0KdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgc3VjaCB0 aGF0IGl0IHdvdWxkIGJlIGFsc28gdXNlYWJsZSB3aXRoPGJyPg0KYXBwbGljYXRpb24gcHJvdG9j b2xzIG90aGVyIHRoYW4gSFRUUFMsIGhvd2V2ZXIgc3BlY2lmeWluZyBzdWNoIHVzZXMgaXM8YnI+ DQpub3QgYSBwcmltYXJ5IGdvYWwuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VbW0sIEkgYW0gc3RpbGwgcmF0aGVyIGZ1enp5IGFi b3V0IHdoYXQgaXMgcHJvcG9zZWQgaGVyZSBTdGVwaGVuLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwYXJ0aWN1bGFyIEkgZG9uJ3QgdGhp bmsgd2UgYXJlIGdldHRpbmcgYXdheSBmcm9tIGJlYXJlciB0b2tlbnMsIHdlIGFyZSBqdXN0IGhp ZGluZyB0aGVtIGRpZmZlcmVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhIGRyYWZ0IEkgaGF2ZSBiZWVuIHdvcmtpbmcgb24g Zm9yIGEgd2hpbGUuIEl0IGFsbG93cyBhIHRva2VuIHRvIGJlIGJvdW5kIHRvIGEgSFRUUC9UTFMg Y2hhbm5lbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFsbGFtYmFr ZXItaHR0cHNlc3Npb24tMDMiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhbGxh bWJha2VyLWh0dHBzZXNzaW9uLTAzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IG1pZ2h0IGhlbHAgaWYgd2UgaGFkIGEgZGVmaW5p dGlvbiBvZiBiZWFyZXIgdG9rZW4uIEkgZG9uJ3QgdGhpbmsgdGhhdCBmb3JtdWxhdGlvbiBpcyBo ZWxwaW5nLiBUaGUgcHJvYmxlbSBpcyBub3QgdGhhdCB3ZSBoYXZlIGJlYXJlciB0b2tlbnMsIGl0 IGlzIHRoYXQgb3VyIHByb29mcyBvZiBwb3NzZXNzaW9uIGZvcmNlIHRoZW0gdG8gYmUgZGlzY2xv c2VkIGluIHBsYWludGV4dCB0byB0aGUgcGFydHkgY2hlY2tpbmcNCiB0aGVtLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyBhbiBSU0EgcHJp dmF0ZSBrZXkgYSBiZWFyZXIgdG9rZW4/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgYWJvdXQgYSBrZXJiZXJvcyB0aWNrZXQ/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJlc2VudGlu ZyB0aGlzIGFzIGEgcHJvYmxlbSB3aXRoIHRoZSB0b2tlbiBwdXRzIHVzIG9mZiB0cmFjay4gVGhl IHByb2JsZW0gaXMgd2l0aCB0aGUgd2F5IHdlIHVzZSB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR0301MB1250C495221827422B8C22A88C650BN3PR0301MB1250_-- From nobody Tue Dec 9 18:45:17 2014 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 99B741A8972; Tue, 9 Dec 2014 09:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 SMEZ-wXgnCzx; Tue, 9 Dec 2014 09:29:31 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 821A91A87E9; Tue, 9 Dec 2014 09:29:26 -0800 (PST) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 5E8A327BC065; Tue, 9 Dec 2014 09:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=DOzzSorW/aMmIW WR1+qEP4eWy7g=; b=cQ3afz66CKujKuN/hgTGuZV7v9pl5P28ymO8jH5e1V98hk pNshZSlgvGwe1gIsIH9WTxVLm1laAC+VvAsYU2QUtbO3OceAKDsqKad0l7fD91bt 0Ll656bJ2e6Hq3pfmB1Czw4EV57PRmudHoxJRiwLRDvntc0eXM+kr5Xa6jenk= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id E19D027BC064; Tue, 9 Dec 2014 09:29:25 -0800 (PST) Date: Tue, 9 Dec 2014 11:29:25 -0600 From: Nico Williams To: Derek Atkins Message-ID: <20141209172920.GC12979@localhost> References: <20141205191820.4189.348.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/6lU65bAorNKIvJ02YGPC7jhPkNs X-Mailman-Approved-At: Tue, 09 Dec 2014 18:45:16 -0800 Cc: unbearable@ietf.org, Andrei.Popov@microsoft.com, ietf@ietf.org Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable 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: Tue, 09 Dec 2014 17:29:33 -0000 On Sat, Dec 06, 2014 at 02:19:34PM -0500, Derek Atkins wrote: > The OAUTH Working Group is already (and has been for a while!) looking > into "holder of key" protocols to improve upon Bearer Tokens. > > I would suggest that this work happen there instead of creating a whole > new group for it. That's very interesting. Key confirmation protocols will tend to all look... roughly similar: a synchronous exchange of "messages" (with cryptographic elements, of course) between a "client" and a "server" (with perhaps infrastructure message in the background) until one, the other, or both peers are authenticated to the other, or the authentication fails. If you can have keys at all, you can also have session keys, though for HTTP.. until we get something better than web cookies for session continuation, having session keys is hardly critical. Anyways, there's a reason I mention this: we already have several protocols that look like this, so new not-just-bearer-anymore bearer token extensions have literature to look at. A brief list of such protocols that might be useful for lessons to good, bad, and ugly: TLS, SASL (and various mechanisms), GSS-API (and various mechanisms), Kerberos V5, IKEv1 and IKEv2, ... Of those, these tend to have actual APIs in the wild that might be useful too: TLS (ad-hoc APIs), SASL (ad-hoc APIs), GSS (standard APIs), Kerberos (ad-hoc APIs), IKEv* (PF_KEY -- a standardish socket API). I'm not sure which lessons OAuth and others going down this path should take. I'll try to think of some so as to save the authors the time of having to digest all this material. I suggest others also do this. Nico -- From nobody Wed Dec 10 14:13:31 2014 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 A4EE21A90CD for ; Wed, 10 Dec 2014 14:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 a-C_WTWWOsmq for ; Wed, 10 Dec 2014 14:13:24 -0800 (PST) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5E71A899B for ; Wed, 10 Dec 2014 14:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1418249603; bh=e0TnBJq2cDBZSPyNm8YI+htTGbm4a+K2DY1h9vV94o8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=MeAcIg+xatWkDeRWv/DVZC+xd8SgyYyE+AoNIiItDzWPAUe47MToRtjszU28rLk7ZS5XFaIaWHisRbfS0qHsAq09nhZ0WU26GBSYTAI/rHkllX/ReZkobOj1GPOOI+zkhNO7tTpYZ/VOIaGZCmAKMCEmRDiBNmD6hXaqINWOkkrXGaEOx/+FEWur2wdBZg4QTSysNGG2KVGvyQV8VD/Z6gnr1zNYIxvlWhPosecW4QSJDF+r+tjJywhT0Fa1QrZXFSOSpS8G7GbWC/kFZWjRw4megx8xlgmDVSC0Sy3+4HpyUyENoPQb1h1ek+6Eh8CQYrAL0SCqEcDAVGGTLc1mog== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=cUg1xbyPO3Vxwkt63h+Us28RnyiAnGLECVJ57by4wqoD6W2TedNqRSAU8o6tl8D7ftrH/ZmWP+RPNOVyO2bFpJvbkvCzqLqWgPIkEzKpfX0wzIKk1F1/l8jSMTtgVQmu5jjNt6/NZqFZdz5cNjc7n3VnxHcKlWU5q+CihprKNqIuw6sA32tFgBJTYkTxynqln9opSvkvric5WBv1epzUSDU8GnmPz/1+g3D1v7QTNbO7A+q6LjXjNLatyPIbyjSkFEChaPd/qPUW4o/J72LS3vGYc40dlkRue7ayUm/j0UiypO0CQ/owXDauWU1aCZCbb/YiQn6jN2EJoI0M255N0Q==; Received: from [66.196.81.170] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 10 Dec 2014 22:13:23 -0000 Received: from [98.139.212.250] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 10 Dec 2014 22:13:23 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 10 Dec 2014 22:13:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 617104.1320.bm@omp1059.mail.bf1.yahoo.com Received: by 76.13.26.159; Wed, 10 Dec 2014 22:13:23 +0000 Date: Wed, 10 Dec 2014 22:13:22 +0000 (UTC) From: Bill Mills To: Andrei Popov , Phil Hunt , John Bradley , "unbearable@ietf.org" Message-ID: <1123945653.8070137.1418249602535.JavaMail.yahoo@jws10692.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8070136_1855472927.1418249602521" Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/Wl7WfvDw6Ut35eDw3FWQ1DRd_Fs Cc: Mike Jones , Derek Atkins , Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills 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, 10 Dec 2014 22:13:27 -0000 ------=_Part_8070136_1855472927.1418249602521 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rereading the two draft propose BOTH channel binding and what you are calli= ng "token binding". =C2=A0"Token binding" being another name for proof-of-p= ossession (POP) tokens, I prefer the "POP" nomenclature as much more distin= ct. My original comments in the thread stand then, we're potentially duplicatin= g some of the work happening in OAuth here. =C2=A0If we want to move token = work out of OAuth WG now that Bearer has established a workable first use c= ase for OAuth2 that's fine, but we need to make sure that's part of the dis= cussion. The second topic, channel binding in HTTP is interesting, and I think the q= uestion is whether we should define a generic HTTP channel binding hook is = worthwhile.but I think the discussion is really around whether there's valu= e in putting the channel binding info into a header which various profiles = could then sign against. =C2=A0The previous comments about the difficulties= of doing channel binding over HTTP in a world of TLS accelerators and HTTP= S edge termination make this something of a huge challenge. =C2=A0I think i= t's an interesting academic excercise, but the energy needs to be spent in = how we can deal with transitive trust in that type of multi-hop sitation be= fore we make a generic channel binding mechanism for HTTP that's not workab= le or deployable in general.=20 -bill On Wednesday, December 10, 2014 1:47 PM, Andrei Popov wrote: =20 #yiv8884657557 #yiv8884657557 -- _filtered #yiv8884657557 {font-family:Hel= vetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv8884657557 {font-famil= y:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv8884657557 {panose= -1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv8884657557 {font-family:Calibri;pano= se-1:2 15 5 2 2 2 4 3 2 4;}#yiv8884657557 #yiv8884657557 p.yiv8884657557Mso= Normal, #yiv8884657557 li.yiv8884657557MsoNormal, #yiv8884657557 div.yiv888= 4657557MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv88= 84657557 a:link, #yiv8884657557 span.yiv8884657557MsoHyperlink {color:blue;= text-decoration:underline;}#yiv8884657557 a:visited, #yiv8884657557 span.yi= v8884657557MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#y= iv8884657557 p.yiv8884657557MsoListParagraph, #yiv8884657557 li.yiv88846575= 57MsoListParagraph, #yiv8884657557 div.yiv8884657557MsoListParagraph {margi= n-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom= :.0001pt;font-size:12.0pt;}#yiv8884657557 span.yiv8884657557EmailStyle17 {c= olor:#1F497D;}#yiv8884657557 .yiv8884657557MsoChpDefault {font-size:10.0pt;= } _filtered #yiv8884657557 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv8884657557 = div.yiv8884657557WordSection1 {}#yiv8884657557 _filtered #yiv8884657557 {} = _filtered #yiv8884657557 {font-family:Wingdings;color:black;} _filtered #yi= v8884657557 {} _filtered #yiv8884657557 {font-family:Wingdings;} _filtered = #yiv8884657557 {font-family:Symbol;} _filtered #yiv8884657557 {} _filtered = #yiv8884657557 {font-family:Wingdings;} _filtered #yiv8884657557 {font-fami= ly:Symbol;} _filtered #yiv8884657557 {} _filtered #yiv8884657557 {font-fami= ly:Wingdings;}#yiv8884657557 ol {margin-bottom:0in;}#yiv8884657557 ul {marg= in-bottom:0in;}#yiv8884657557 Hi Bill, =C2=A0 =C3=98=C2=A0In the 2 drafts = Mike J. pasted I find the use of the term "TLS Binding" confusing here beca= use it's dangerously close to "Channel Binding" which is *not* what these d= rafts are talking about. The term =E2=80=9CTLS Binding=E2=80=9D is not used= in either of the Token Binding I-Ds. The term =E2=80=9CToken Binding=E2=80= =9D was chosen to avoid overloading the existing term =E2=80=9CChannel Bind= ing=E2=80=9D. =C2=A0 =C3=98=C2=A0Are these drafts intended to allow a trus= t relationship to be built on the client secret established during authenti= cation, and that secret is then used to bring channel binding down into the= HTTP layer?=C2=A0 Authentication is out of the scope of these drafts. Once= client authentication is complete, the server will often issue security to= kens for the client to present to this server (or other servers, in the fed= eration case). Today, these tokens can be intercepted or exported from the = client machine and replayed, so the attacker can impersonate a valid user. = These drafts allow the server to cryptographically bind security tokens to = a (non-exportable, e.g. HW-bound) key maintained by the client. The client = proves possession of this key on every TLS connection to the server, theref= ore once the security token is presented, the server can verify that it cam= e from the client that it was issued to. =C2=A0 Cheers, =C2=A0 Andrei = =C2=A0 From: Bill Mills [mailto:wmills_92105@yahoo.com] Sent: Monday, December 8, 2014 6:30 PM To: Phil Hunt; John Bradley; unbearable@ietf.org Cc: Andrei Popov; Mike Jones; Derek Atkins; Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable =C2=A0 Split= ting work on POP tokens between N>1 WG is almost certainly wrong if that's = what we're doing. =C2=A0 =C2=A0 In the 2 drafts Mike J. pasted I find the = use of the term "TLS Binding" confusing here because it's dangerously close= to "Channel Binding" which is *not* what these drafts are talking about. = =C2=A0If we are in fact doing channel binding then that's the term we shoul= d be using. =C2=A0Are these drafts intended to allow a trust relationship t= o be built on the client secret established during authentication, and that= secret is then used to bring channel binding down into the HTTP layer?=C2= =A0 =C2=A0 =C2=A0 On Monday, December 8, 2014 3:18 PM, Phil Hunt wrote: =C2=A0 Maybe all token work should be together in it= s own WG? Phil > On Dec 8, 2014, at 14:54, John Bradley wrote: >=20 > We did discuss this at the last IETF meeting. >=20 > While the work is closely related to the PoP work in OAuth it is not the = same.=C2=A0 It will allow us to do PoP tokens for the implicit flow, someth= ing that we haven't touched yet in OAuth because we don't have a workable w= ay to manage keys in the browser.=C2=A0 This work should allow us to do tha= t. >=20 > I think the slide deck examples showing JWT using different mechanisms to= express keys from the work done in the OAuth WG may be part of what has so= me people concerned. >=20 > I don't think these specs overlap with OAuth, but we do need to be mindfu= l of scope creep.=C2=A0 As I stated at the F2F we need to have the two grou= ps work together, so that we can have PoP tokens via the browser.=C2=A0 >=20 > John B. >=20 >=20 >> On Dec 8, 2014, at 6:58 PM, Mike Jones wro= te: >>=20 >> It's my understanding that "Unbearable" is part of an effort to create a= new working group scoped to work on deliverables based upon these input do= cuments: >>=20 >> http://tools.ietf.org/html/draft-balfanz-https-token-binding >> http://tools.ietf.org/html/draft-popov-token-binding >>=20 >> I don't think that it was ever intended to cover every aspect of proof-o= f-possession and so there's not actually any conflict with the work we're a= lready doing in OAuth.=C2=A0 (Nor does it seem to me to be productive to ad= d even more documents-in-flight to the OAuth working group at present.) >>=20 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers, >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike >>=20 >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Derek= Atkins >> Sent: Saturday, December 06, 2014 11:20 AM >> To: ietf@ietf.org >> Cc: Andrei Popov; unbearable@ietf.org; Stephen Farrell >> Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable >>=20 >> Hi, >>=20 >> IETF Secretariat writes: >>=20 >>> A new IETF non-working group email list has been created. >>>=20 >>> List address: unbearable@ietf.org >>> Archive: http://www.ietf.org/mail-archive/web/unbearable/ >>> To subscribe: https://www.ietf.org/mailman/listinfo/unbearable >>>=20 >>> Purpose: >>>=20 >>> This list is for discussion of proposals for doing better than bearer= =20 >>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications.=20 >>> The specific goal is chartering a WG focused on preventing security=20 >>> token export and replay attacks. >>=20 >>=20 >> The OAUTH Working Group is already (and has been for a while!) looking i= nto "holder of key" protocols to improve upon Bearer Tokens. >>=20 >> I would suggest that this work happen there instead of creating a whole = new group for it. >>=20 >> -derek >>=20 >>> For additional information, please contact the list administrators. >>=20 >> --=20 >>=C2=A0 =C2=A0 =C2=A0 Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 617-623-3745 >>=C2=A0 =C2=A0 =C2=A0 derek@ihtfp.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 www.ihtfp.com >>=C2=A0 =C2=A0 =C2=A0 Computer and Internet Security Consultant >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > 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 =20 ------=_Part_8070136_1855472927.1418249602521 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rer= eading the two draft propose BOTH channel binding and what you are calling = "token binding".  "Token binding" being another name for proof-of-poss= ession (POP) tokens, I prefer the "POP" nomenclature as much more distinct.=

<= div dir=3D"ltr" id=3D"yui_3_16_0_1_1418156877306_323451">My original commen= ts in the thread stand then, we're potentially duplicating some of the work= happening in OAuth here.  If we want to move token work out of OAuth = WG now that Bearer has established a workable first use case for OAuth2 tha= t's fine, but we need to make sure that's part of the discussion.

The second topic, channel bi= nding in HTTP is interesting, and I think the question is whether we should= define a generic HTTP channel binding hook is worthwhile.but I think the d= iscussion is really around whether there's value in putting the channel bin= ding info into a header which various profiles could then sign against. &nb= sp;The previous comments about the difficulties of doing channel binding ov= er HTTP in a world of TLS accelerators and HTTPS edge termination make this= something of a huge challenge.  I think it's an interesting academic = excercise, but the energy needs to be spent in how we can deal with transit= ive trust in that type of multi-hop sitation before we make a generic chann= el binding mechanism for HTTP that's not workable or deployable in general.=

-bill


= O= n Wednesday, December 10, 2014 1:47 PM, Andrei Popov <Andrei.Popov@micro= soft.com> wrote:


#yiv8884657557 #yiv8884657557 -- =20 _filtered #yiv8884657557 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 = 2 4;} _filtered #yiv8884657557 {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0= 0;} _filtered #yiv8884657557 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv8884657557 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 = 4;} #yiv8884657557 =20 #yiv8884657557 p.yiv8884657557MsoNormal, #yiv8884657557 li.yiv8884657557Mso= Normal, #yiv8884657557 div.yiv8884657557MsoNormal =09{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;} #yiv8884657557 a:link, #yiv8884657557 span.yiv8884657557MsoHyperlink =09{color:blue;text-decoration:underline;} #yiv8884657557 a:visited, #yiv8884657557 span.yiv8884657557MsoHyperlinkFoll= owed =09{color:purple;text-decoration:underline;} #yiv8884657557 p.yiv8884657557MsoListParagraph, #yiv8884657557 li.yiv888465= 7557MsoListParagraph, #yiv8884657557 div.yiv8884657557MsoListParagraph =09{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;marg= in-bottom:.0001pt;font-size:12.0pt;} #yiv8884657557 span.yiv8884657557EmailStyle17 =09{color:#1F497D;} #yiv8884657557 .yiv8884657557MsoChpDefault =09{font-size:10.0pt;} _filtered #yiv8884657557 {margin:1.0in 1.0in 1.0in 1.0in;} #yiv8884657557 div.yiv8884657557WordSection1 =09{} #yiv8884657557 =20 _filtered #yiv8884657557 {} _filtered #yiv8884657557 {font-family:Wingdings;color:black;} _filtered #yiv8884657557 {} _filtered #yiv8884657557 {font-family:Wingdings;} _filtered #yiv8884657557 {font-family:Symbol;} _filtered #yiv8884657557 {} _filtered #yiv8884657557 {font-family:Wingdings;} _filtered #yiv8884657557 {font-family:Symbol;} _filtered #yiv8884657557 {} _filtered #yiv8884657557 {font-family:Wingdings;} #yiv8884657557 ol =09{margin-bottom:0in;} #yiv8884657557 ul =09{margin-bottom:0in;} #yiv8884657557
Hi Bill,
=20
 
=20
=C3=98  In the 2 drafts Mike J. pasted I find the use of the te= rm "TLS Binding" confusing here because it's dangerously close to "Channel = Binding" which is *not* what these drafts are talking about.
=20
The term =E2=80=9CTLS Binding=E2=80=9D is not used in either of the Tok= en Binding I-Ds. The term =E2=80=9CToken Binding=E2=80=9D was chosen to avo= id overloading the existing term =E2=80=9CChannel Binding=E2=80=9D.<= /div>=20
 
=20
=C3=98  Are these drafts inte= nded to allow a trust relationship to be built on the client secret establi= shed during authentication, and that secret is then used to bring channel binding down into the HTTP layer? 
=20
Authentication is out of the scope of these drafts. Once client authent= ication is complete, the server will often issue security tokens for the cl= ient to present to this server (or other servers, in the federation case). Today, these to= kens can be intercepted or exported from the client machine and replayed, s= o the attacker can impersonate a valid user. These drafts allow the server = to cryptographically bind security tokens to a (non-exportable, e.g. HW-bound) key maintained by the client. = The client proves possession of this key on every TLS connection to the ser= ver, therefore once the security token is presented, the server can verify = that it came from the client that it was issued to.
=20
 
=20
Cheers,
=20
 
=20
Andrei
=20
 
=20
From: Bill Mills [mailt= o:wmills_92105@yahoo.com]
Sent: Monday, December 8, 2014 6:30 PM
To: Phil Hunt; John Bradley; unbearable@ietf.org
Cc: Andrei Popov; Mike Jones; Derek Atkins; Stephen Farrell
Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable=
=20
 
=20
Splitting work on POP tokens between N>1 = WG is almost certainly wrong if that's what we're doing.  =20
 
=20
In the 2 drafts Mike J. pasted I find the us= e of the term "TLS Binding" confusing here because it's dangerously close t= o "Channel Binding" which is *not* what these drafts are talking about.  If we are in fac= t doing channel binding then that's the term we should be using.  Are = these drafts intended to allow a trust relationship to be built on the clie= nt secret established during authentication, and that secret is then used to bring channel binding down into the HTTP l= ayer? 
=20
 
=20
 
=20
On Monday, December 8, 2014 3:18 PM, Phil H= unt <phil.hunt@or= acle.com> wrote:
=20
&nbs= p;
=20
Maybe all token work should be together= in its own WG?

Phil

> On Dec 8, 2014, at 14:54, John Bradley <ve7jtb@ve7= jtb.com> wrote:
>
> We did discuss this at the last IETF meeting.
>
> While the work is closely related to the PoP work in OAuth it is not t= he same.  It will allow us to do PoP tokens for the implicit flow, som= ething that we haven't touched yet in OAuth because we don't have a workabl= e way to manage keys in the browser.  This work should allow us to do that.
>
> I think the slide deck examples showing JWT using different mechanisms= to express keys from the work done in the OAuth WG may be part of what has= some people concerned.
>
> I don't think these specs overlap with OAuth, but we do need to be min= dful of scope creep.  As I stated at the F2F we need to have the two g= roups work together, so that we can have PoP tokens via the browser. 
>
> John B.
>
>
>> On Dec 8, 2014, at 6:58 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>
>> It's my understanding that "Unbearable" is part of an effort to cr= eate a new working group scoped to work on deliverables based upon these in= put documents:
>>
>> http://tools.ietf.org/html/draft-balfanz-https-token-binding
>> http://tools.ietf.org/html/draft-popov-token-binding
>>
>> I don't think that it was ever intended to cover every aspect of p= roof-of-possession and so there's not actually any conflict with the work w= e're already doing in OAuth.  (Nor does it seem to me to be productive= to add even more documents-in-flight to the OAuth working group at present.)
>>
>>                Cheers,
>>                -- Mike
>>
>> -----Original Message-----
>> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of D= erek Atkins
>> Sent: Saturday, December 06, 2014 11:20 AM
>> To: ietf@ietf.org
>> Cc: Andrei Popov; unbearable@ietf.org; Stephen Farrell
>> Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable
>>
>> Hi,
>>
>> IETF Secretariat <ietf-secretariat@ietf.org> writes:
>>
>>> A new IETF non-working group email list has been created.
>>>
>>> List address: unbearable@ietf.org
>>> Archive: http://www.ietf.org/mail-archive/web/unbearable/
>>> To subscribe: https://www.ietf.org/mailman/listinfo/unbearable
>>>
>>> Purpose:
>>>
>>> This list is for discussion of proposals for doing better than= bearer
>>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applicat= ions.
>>> The specific goal is chartering a WG focused on preventing sec= urity
>>> token export and replay attacks.
>>
>>
>> The OAUTH Working Group is already (and has been for a while!) loo= king into "holder of key" protocols to improve upon Bearer Tokens.
>>
>> I would suggest that this work happen there instead of creating a = whole new group for it.
>>
>> -derek
>>
>>> For additional information, please contact the list administra= tors.
>>
>> --
>>      Derek Atkins         =       617-623-3745
>>      d= erek@ihtfp.com            www.ihtfp.com
>>      Computer and Internet Security Consultant
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ie= tf.org
>> https://www.ietf.org/mailman/l= istinfo/unbearable
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ie= tf.org
>> https://www.ietf.org/mailman/l= istinfo/unbearable
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.o= rg
> https://www.ietf.org/mailman/listi= nfo/unbearable

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/u= nbearable

=20


------=_Part_8070136_1855472927.1418249602521-- From nobody Wed Dec 10 14:34:59 2014 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 188B81AC3D8 for ; Wed, 10 Dec 2014 14:34:55 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 ge8aBhMfAN8Q for ; Wed, 10 Dec 2014 14:34:50 -0800 (PST) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE2B1AC3D1 for ; Wed, 10 Dec 2014 14:34:48 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so4892091wgg.28 for ; Wed, 10 Dec 2014 14:34:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=grl5amL0ftoUW8Hy553T7dj/Do+gj0JAItX2Ihj3eAs=; b=YlojK5O0MQMOOH5R+aZDw8sY/lb7ngfuJEkNuiAc1JXLr+DowOo9DxBxtuTum2FmNT 7sSh5vllqZw+egHt25BUUoYPzjCvn2CbM4ZKug/JaarGaE0sCLfSKvcd9TZvkbZwQfn+ 7fw8NcPoa3AcnyLBxRDYyEQI2JTfWLXfqC/f+RAn6qRehe/+4q2BkE7TO94IG+uzB0Z7 swivPSjijI1JokSURaF+EQ1MsessJduYCVo9AcH+IFo6Jj1yl2kEbbiD1agXpjGvaoG9 hHLb7CGWgsCmExen3AI6I9meh2oUrC/0XkaI+i+LROeFBkkODgm1Q29/5qW2/QZbuKHf Jc7g== X-Gm-Message-State: ALoCoQnuJqlhEx63pCuEYeLUfKmhOzzxy1eAFzxkcAJzXUmooUrY2YUojOr7qRkKU0G0unY7+M0z X-Received: by 10.180.198.209 with SMTP id je17mr9965485wic.17.1418250887292; Wed, 10 Dec 2014 14:34:47 -0800 (PST) Received: from [172.30.17.77] ([146.255.1.43]) by mx.google.com with ESMTPSA id cs8sm333653wib.1.2014.12.10.14.34.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 14:34:44 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E1C284AF-D303-4E48-9A12-DF737DC8033B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <1123945653.8070137.1418249602535.JavaMail.yahoo@jws10692.mail.bf1.yahoo.com> Date: Wed, 10 Dec 2014 22:34:41 +0000 Message-Id: References: <1123945653.8070137.1418249602535.JavaMail.yahoo@jws10692.mail.bf1.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/nKfH6zAFjmiA3g645LSxyu4lpoA Cc: Andrei Popov , "unbearable@ietf.org" , Michael Jones , Phil Hunt , Derek Atkins , Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable 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, 10 Dec 2014 22:34:55 -0000 --Apple-Mail=_E1C284AF-D303-4E48-9A12-DF737DC8033B Content-Type: multipart/alternative; boundary="Apple-Mail=_B9C95F01-B50B-4225-A780-DC3B3A333431" --Apple-Mail=_B9C95F01-B50B-4225-A780-DC3B3A333431 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think one thing that people may be missing in the discussion, is that = this work is really about establishing and using pairwise keys in the = browser. This is not really for the OAuth clients other than perhaps implicit = ones in the browser. For servers and native apps we do have ways of managing keys in the = client. The current OAuth work is based around that. At the moment we have no practical way(I am excluding installing soft = certs in the users computer key store or using smart cards as = impractical in practice) of doing POP via the browser. I still think of this more at the TLS layer to establish keys, but it is = being described as being higher on the stack for reasons=E2=80=A6 Token binding may be a problematic name. The specs should describe the = key management parts and how to get at the keys to bind the relevant = public key portions to tokens, but probably leave the details for the = application protocols that are going to use it. OAuth should define how = it is used to bind a access token to the channel, and Connect should = worry about it=E2=80=99s id_tokens. etc. It might be appropriate to say something about cookies.=20 I think being clearer on what is and is not in scope will help. John B. > On Dec 10, 2014, at 10:13 PM, Bill Mills = wrote: >=20 > Rereading the two draft propose BOTH channel binding and what you are = calling "token binding". "Token binding" being another name for = proof-of-possession (POP) tokens, I prefer the "POP" nomenclature as = much more distinct. >=20 > My original comments in the thread stand then, we're potentially = duplicating some of the work happening in OAuth here. If we want to = move token work out of OAuth WG now that Bearer has established a = workable first use case for OAuth2 that's fine, but we need to make sure = that's part of the discussion. >=20 > The second topic, channel binding in HTTP is interesting, and I think = the question is whether we should define a generic HTTP channel binding = hook is worthwhile.but I think the discussion is really around whether = there's value in putting the channel binding info into a header which = various profiles could then sign against. The previous comments about = the difficulties of doing channel binding over HTTP in a world of TLS = accelerators and HTTPS edge termination make this something of a huge = challenge. I think it's an interesting academic excercise, but the = energy needs to be spent in how we can deal with transitive trust in = that type of multi-hop sitation before we make a generic channel binding = mechanism for HTTP that's not workable or deployable in general. >=20 > -bill >=20 >=20 > On Wednesday, December 10, 2014 1:47 PM, Andrei Popov = wrote: >=20 >=20 > Hi Bill, > =20 > =C3=98 In the 2 drafts Mike J. pasted I find the use of the term "TLS = Binding" confusing here because it's dangerously close to "Channel = Binding" which is *not* what these drafts are talking about. > The term =E2=80=9CTLS Binding=E2=80=9D is not used in either of the = Token Binding I-Ds. The term =E2=80=9CToken Binding=E2=80=9D was chosen = to avoid overloading the existing term =E2=80=9CChannel Binding=E2=80=9D. > =20 > =C3=98 Are these drafts intended to allow a trust relationship to be = built on the client secret established during authentication, and that = secret is then used to bring channel binding down into the HTTP layer?=20= > Authentication is out of the scope of these drafts. Once client = authentication is complete, the server will often issue security tokens = for the client to present to this server (or other servers, in the = federation case). Today, these tokens can be intercepted or exported = from the client machine and replayed, so the attacker can impersonate a = valid user. These drafts allow the server to cryptographically bind = security tokens to a (non-exportable, e.g. HW-bound) key maintained by = the client. The client proves possession of this key on every TLS = connection to the server, therefore once the security token is = presented, the server can verify that it came from the client that it = was issued to. > =20 > Cheers, > =20 > Andrei > =20 > From: Bill Mills [mailto:wmills_92105@yahoo.com]=20 > Sent: Monday, December 8, 2014 6:30 PM > To: Phil Hunt; John Bradley; unbearable@ietf.org > Cc: Andrei Popov; Mike Jones; Derek Atkins; Stephen Farrell > Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable > =20 > Splitting work on POP tokens between N>1 WG is almost certainly wrong = if that's what we're doing. =20 > =20 > In the 2 drafts Mike J. pasted I find the use of the term "TLS = Binding" confusing here because it's dangerously close to "Channel = Binding" which is *not* what these drafts are talking about. If we are = in fact doing channel binding then that's the term we should be using. = Are these drafts intended to allow a trust relationship to be built on = the client secret established during authentication, and that secret is = then used to bring channel binding down into the HTTP layer?=20 > =20 > =20 > On Monday, December 8, 2014 3:18 PM, Phil Hunt > wrote: > =20 > Maybe all token work should be together in its own WG? >=20 > Phil >=20 > > On Dec 8, 2014, at 14:54, John Bradley > wrote: > >=20 > > We did discuss this at the last IETF meeting. > >=20 > > While the work is closely related to the PoP work in OAuth it is not = the same. It will allow us to do PoP tokens for the implicit flow, = something that we haven't touched yet in OAuth because we don't have a = workable way to manage keys in the browser. This work should allow us = to do that. > >=20 > > I think the slide deck examples showing JWT using different = mechanisms to express keys from the work done in the OAuth WG may be = part of what has some people concerned. > >=20 > > I don't think these specs overlap with OAuth, but we do need to be = mindful of scope creep. As I stated at the F2F we need to have the two = groups work together, so that we can have PoP tokens via the browser. =20= > >=20 > > John B. > >=20 > >=20 > >> On Dec 8, 2014, at 6:58 PM, Mike Jones > wrote: > >>=20 > >> It's my understanding that "Unbearable" is part of an effort to = create a new working group scoped to work on deliverables based upon = these input documents: > >>=20 > >> http://tools.ietf.org/html/draft-balfanz-https-token-binding = > >> http://tools.ietf.org/html/draft-popov-token-binding = > >>=20 > >> I don't think that it was ever intended to cover every aspect of = proof-of-possession and so there's not actually any conflict with the = work we're already doing in OAuth. (Nor does it seem to me to be = productive to add even more documents-in-flight to the OAuth working = group at present.) > >>=20 > >> Cheers, > >> -- Mike > >>=20 > >> -----Original Message----- > >> From: Unbearable [mailto:unbearable-bounces@ietf.org = ] On Behalf Of Derek Atkins > >> Sent: Saturday, December 06, 2014 11:20 AM > >> To: ietf@ietf.org > >> Cc: Andrei Popov; unbearable@ietf.org ; = Stephen Farrell > >> Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable > >>=20 > >> Hi, > >>=20 > >> IETF Secretariat > writes: > >>=20 > >>> A new IETF non-working group email list has been created. > >>>=20 > >>> List address: unbearable@ietf.org > >>> Archive: http://www.ietf.org/mail-archive/web/unbearable/ = > >>> To subscribe: https://www.ietf.org/mailman/listinfo/unbearable = > >>>=20 > >>> Purpose: > >>>=20 > >>> This list is for discussion of proposals for doing better than = bearer=20 > >>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web = applications.=20 > >>> The specific goal is chartering a WG focused on preventing = security=20 > >>> token export and replay attacks. > >>=20 > >>=20 > >> The OAUTH Working Group is already (and has been for a while!) = looking into "holder of key" protocols to improve upon Bearer Tokens. > >>=20 > >> I would suggest that this work happen there instead of creating a = whole new group for it. > >>=20 > >> -derek > >>=20 > >>> For additional information, please contact the list = administrators. > >>=20 > >> --=20 > >> Derek Atkins 617-623-3745 > >> derek@ihtfp.com = www.ihtfp.com > >> Computer and Internet Security Consultant > >>=20 > >> _______________________________________________ > >> Unbearable mailing list > >> Unbearable@ietf.org > >> https://www.ietf.org/mailman/listinfo/unbearable = > >>=20 > >> _______________________________________________ > >> Unbearable mailing list > >> Unbearable@ietf.org > >> https://www.ietf.org/mailman/listinfo/unbearable = > >=20 > > _______________________________________________ > > Unbearable mailing list > > Unbearable@ietf.org > > https://www.ietf.org/mailman/listinfo/unbearable = >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = --Apple-Mail=_B9C95F01-B50B-4225-A780-DC3B3A333431 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I think one thing that people may be missing in the = discussion, is that this work is really about establishing and using = pairwise keys in the browser.

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

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

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

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

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

It might be appropriate to say = something about cookies. 

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

John B.


On Dec 10, 2014, at 10:13 PM, = Bill Mills <wmills_92105@yahoo.com> wrote:

Rereading the two = draft propose BOTH channel binding and what you are calling "token = binding".  "Token binding" being another name for = proof-of-possession (POP) tokens, I prefer the "POP" nomenclature as = much more distinct.

My original comments in the thread stand then, we're = potentially duplicating some of the work happening in OAuth here. =  If we want to move token work out of OAuth WG now that Bearer has = established a workable first use case for OAuth2 that's fine, but we = need to make sure that's part of the discussion.

The second topic, channel binding in HTTP is interesting, = and I think the question is whether we should define a generic HTTP = channel binding hook is worthwhile.but I think the discussion is really = around whether there's value in putting the channel binding info into a = header which various profiles could then sign against.  The = previous comments about the difficulties of doing channel binding over = HTTP in a world of TLS accelerators and HTTPS edge termination make this = something of a huge challenge.  I think it's an interesting = academic excercise, but the energy needs to be spent in how we can deal = with transitive trust in that type of multi-hop sitation before we make = a generic channel binding mechanism for HTTP that's not workable or = deployable in general.

-bill


On = Wednesday, December 10, 2014 1:47 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:


Hi Bill,
 
=C3=98  In the 2 drafts Mike J. pasted I find the use of the term = "TLS Binding" confusing here because it's dangerously close to "Channel = Binding" which is *not* what these drafts are talking about.
The term =E2=80=9CTLS Binding=E2=80=9D is not used in either = of the Token Binding I-Ds. The term =E2=80=9CToken Binding=E2=80=9D was = chosen to avoid overloading the existing term =E2=80=9CChannel = Binding=E2=80=9D.
 
=C3=98  Are these drafts intended to allow = a trust relationship to be built on the client secret established during = authentication, and that secret is then used to bring channel binding = down into the HTTP layer? 
Authentication is out of the = scope of these drafts. Once client authentication is complete, the = server will often issue security tokens for the client to present to = this server (or other servers, in the federation case). Today, these = tokens can be intercepted or exported from the client machine and = replayed, so the attacker can impersonate a valid user. These drafts = allow the server to cryptographically bind security tokens to a = (non-exportable, e.g. HW-bound) key maintained by the client. The client = proves possession of this key on every TLS connection to the server, = therefore once the security token is presented, the server can verify = that it came from the client that it was issued to.
 
Cheers,
 
Andrei
 
From: Bill Mills = [mailto:wmills_92105@yahoo.com] 
Sent: Monday, December 8, 2014 = 6:30 PM
To: Phil Hunt; John Bradley; unbearable@ietf.org
Cc: Andrei Popov; Mike Jones; = Derek Atkins; Stephen Farrell
Subject: Re: [Unbearable] New Non-WG = Mailing List: unbearable
 
Splitting work on POP tokens = between N>1 WG is almost certainly wrong if that's what we're doing. =  
 
In the 2 drafts Mike J. pasted I = find the use of the term "TLS Binding" confusing here because it's = dangerously close to "Channel Binding" which is *not* what these drafts = are talking about.  If we are in fact doing channel binding then = that's the term we should be using.  Are these drafts intended to = allow a trust relationship to be built on the client secret established = during authentication, and that secret is then used to bring channel = binding down into the HTTP layer? 
 
 
On Monday, December 8, 2014 3:18 = PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
 
Maybe = all token work should be together in its own WG?

Phil

> On Dec 8, 2014, at 14:54, = John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
> We did discuss this at the last IETF = meeting.
> 
> While the work is closely related to the PoP work in = OAuth it is not the same.  It will allow us to do PoP tokens for = the implicit flow, something that we haven't touched yet in OAuth = because we don't have a workable way to manage keys in the = browser.  This work should allow us to do that.
> 
> I think the slide deck examples showing = JWT using different mechanisms to express keys from the work done in the = OAuth WG may be part of what has some people concerned.
> 
> I don't think these specs overlap with = OAuth, but we do need to be mindful of scope creep.  As I stated at = the F2F we need to have the two groups work together, so that we can = have PoP tokens via the browser.  
> 
> John B.
> 
> 
>> On Dec 8, 2014, at 6:58 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> 
>> It's my understanding that = "Unbearable" is part of an effort to create a new working group scoped = to work on deliverables based upon these input documents:
>> 
>> http://tools.ietf.org/html/draft-balfanz-https-token-binding
>> http://tools.ietf.org/html/draft-popov-token-binding
>> 
>> I don't think that it was ever intended to cover = every aspect of proof-of-possession and so there's not actually any = conflict with the work we're already doing in OAuth.  (Nor does it = seem to me to be productive to add even more documents-in-flight to the = OAuth working group at present.)
>> 
>>          =       Cheers,
>>  =               -- Mike
>> >> -----Original Message-----
>> From: Unbearable [mailto:unbearable-bounces@ietf.org] = On Behalf Of Derek Atkins
>> Sent: = Saturday, December 06, 2014 11:20 AM
>>= To: ietf@ietf.org
>> Cc: Andrei Popov; unbearable@ietf.org; Stephen = Farrell
>> Subject: Re: [Unbearable] = New Non-WG Mailing List: unbearable
>> 
>> Hi,
>> 
>> IETF Secretariat <ietf-secretariat@ietf.org> = writes:
>> 
>>> A new IETF non-working group email list has been = created.
>>> 
>>> List address: unbearable@ietf.org
>>> Archive: http://www.ietf.org/mail-archive/web/unbearable/
>>> To subscribe: https://www.ietf.org/mailman/listinfo/unbearable
>>> 
>>> Purpose:
>>> 
>>> This list is for discussion of proposals for = doing better than bearer 
>>> tokens (e.g. HTTP cookies, OAuth tokens etc.) = for web applications. 
>>> The specific goal is chartering a WG focused on = preventing security 
>>> token export and replay = attacks.
>> 
>> 
>> The OAUTH Working Group is already = (and has been for a while!) looking into "holder of key" protocols to = improve upon Bearer Tokens.
>> 
>> I would suggest that this work happen there instead = of creating a whole new group for it.
>> 
>> -derek
>> 
>>> For additional information, = please contact the list administrators.
>> 
>> -- 
>>      Derek Atkins      =           617-623-3745
>>      derek@ihtfp.com        =     www.ihtfp.com
>>      Computer and Internet Security = Consultant
>> 
>> _______________________________________________
>> 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
=

= --Apple-Mail=_B9C95F01-B50B-4225-A780-DC3B3A333431-- --Apple-Mail=_E1C284AF-D303-4E48-9A12-DF737DC8033B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMTAyMjM0NDJaMCMGCSqGSIb3DQEJBDEWBBR7ps8POucNQnZQpKIXh3AK PRhc0TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCCgZpHs1LKOkAqLKtk4eE6Jsgh32BAxgebGBeKNW3YzJuPcVaPhYUh dgBQiykLJvxI/lDt1SeA8S8Rus8MZwE5Kt/1JXM6mD2c/T0fqj0cV7Xf7GCyyOesvN8fVBxnyuEI MDkNK1nASp4hTkUYRBLHS5llBaalcrBzwIH0Ms8+7pOMd4x3eFBXDtI9Ji8Jscwjj20QhFmbX1jb aubMAdm5Sa8+845fu1Crc+C6aAg45Dmit57yHFVAc8gQunLks+N5+MGV8BMbDnuXr5jj+CjiMcw6 Ra73NrQBDVaDWbDM8yQ6GV1jO8o8xJBhzAQ10S7nHUP7CKnfBr+R16enV+8xAAAAAAAA --Apple-Mail=_E1C284AF-D303-4E48-9A12-DF737DC8033B-- From nobody Wed Dec 10 14:59:20 2014 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 3629A1AC415 for ; Wed, 10 Dec 2014 14:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LDvf59EFvgfa for ; Wed, 10 Dec 2014 14:59:15 -0800 (PST) Received: from nm40-vm2.bullet.mail.bf1.yahoo.com (nm40-vm2.bullet.mail.bf1.yahoo.com [72.30.239.210]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D4B1AC417 for ; Wed, 10 Dec 2014 14:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1418252353; bh=FGzsgvGP7fUYX3v+Cgqyoxi5zMGFsRCruwuoGN8y87U=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=cO3eph+5c974HFTJljSLJaKgKeYsfNMrDN7a3CM5JyiMMfPQQVrk9+xH6ziE/ZA7Tre7As+YkW0P5exQa6cwbITiZGbQERPQZV2D2DSpqw1ukBIOyRs7ECZvswkoO9mq3u3g51FEAqaP0HaMvT0NmzgQCNowTEvvb9Qf4HhxMtA+E/v74lGQ43BIRY1lzvAdNS5g9n3azgWd9B7OJfLvlIJGzMGtfb6gsYjVpcHWJC8XSVaXXmrvkeaq8Rl9mJ5EgrH3ZvE4j/YvFhagS2N3BzYk0vVthjpuw7nxDppk9aWml2KkewllvuOIHrmjqsEYlYY8hekI8z9HI7haGQzcvw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=i94+BFoviYAIPvnoFlOCnzYOrrt4X+mY33EImQ6rbJpS5OrddVKcttz9o9FBQoyzWEfNgbh45E42dQegciLdv7X6eZ7f6kuzfFfNL4VA5ASTJxEv/RmtD9Uaz0ks4ynaPGACGYZHzJvbmacucqycXWEAk4EQ+oYf5v7pGomWlXljaUtI1dC/UgKZLRnRjagOLNB5N2odDiOe5rn0VY5xi6WkC+ajMkn7DZRiX9OLRhs4gfF7kaC2IAdzADstvJk2qc8YfKW3gkso83qftMTouRaDASygyXtOrk0ZoD3jFwMjUhA+3wzb6pNf2E1pseVURnDdmFiKAJdlefLfRhBp8Q==; Received: from [98.139.215.141] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 10 Dec 2014 22:59:13 -0000 Received: from [98.139.212.220] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 10 Dec 2014 22:59:13 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 10 Dec 2014 22:59:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 685476.5667.bm@omp1029.mail.bf1.yahoo.com Received: by 76.13.26.159; Wed, 10 Dec 2014 22:59:13 +0000 Date: Wed, 10 Dec 2014 22:59:12 +0000 (UTC) From: Bill Mills To: John Bradley Message-ID: <1710685819.143883.1418252352389.JavaMail.yahoo@jws10605.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_143882_1645809645.1418252352372" Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/_EsXkzlNOsgXU77Knx_Cd_OoE_8 Cc: Andrei Popov , "unbearable@ietf.org" , Michael Jones , Phil Hunt , Derek Atkins , Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills 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, 10 Dec 2014 22:59:18 -0000 ------=_Part_143882_1645809645.1418252352372 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OAuth doesn't care about channel binding, a new token profile might, but th= at's why we separated the tokens from the core OAuth stuff. =C2=A0 I think it is a (huge) mistake to try to use TLS to try to establish a trus= t relationship beyond that TLS context. =20 On Wednesday, December 10, 2014 2:34 PM, John Bradley wrote: =20 I think one thing that people may be missing in the discussion, is that th= is work is really about establishing and using pairwise keys in the browser= . This is not really for the OAuth clients other than perhaps implicit ones i= n the browser. For servers and native apps we do have ways of managing keys in the client.= =C2=A0The current OAuth work is based around that. At the moment we have no practical way(I am excluding installing soft certs= in the users computer key store or using smart cards as impractical in pra= ctice) of doing POP via the browser. I still think of this more at the TLS layer to establish keys, but it is be= ing described as being higher on the stack for reasons=E2=80=A6 Token binding may be a problematic name. =C2=A0The specs should describe th= e key management parts and how to get at the keys to bind the relevant publ= ic key portions to tokens, but probably leave =C2=A0the details for the app= lication protocols that are going to use it. =C2=A0OAuth should define how = it is used to bind a access token to the channel, and Connect should worry = about it=E2=80=99s id_tokens. etc. It might be appropriate to say something about cookies.=C2=A0 I think being clearer on what is and is not in scope will help. John B. On Dec 10, 2014, at 10:13 PM, Bill Mills wrote: Rereading the two draft propose BOTH channel binding and what you are calli= ng "token binding". =C2=A0"Token binding" being another name for proof-of-p= ossession (POP) tokens, I prefer the "POP" nomenclature as much more distin= ct. My original comments in the thread stand then, we're potentially duplicatin= g some of the work happening in OAuth here. =C2=A0If we want to move token = work out of OAuth WG now that Bearer has established a workable first use c= ase for OAuth2 that's fine, but we need to make sure that's part of the dis= cussion. The second topic, channel binding in HTTP is interesting, and I think the q= uestion is whether we should define a generic HTTP channel binding hook is = worthwhile.but I think the discussion is really around whether there's valu= e in putting the channel binding info into a header which various profiles = could then sign against. =C2=A0The previous comments about the difficulties= of doing channel binding over HTTP in a world of TLS accelerators and HTTP= S edge termination make this something of a huge challenge. =C2=A0I think i= t's an interesting academic excercise, but the energy needs to be spent in = how we can deal with transitive trust in that type of multi-hop sitation be= fore we make a generic channel binding mechanism for HTTP that's not workab= le or deployable in general. -bill On Wednesday, December 10, 2014 1:47 PM, Andrei Popov wrote: Hi Bill,=C2=A0=C3=98=C2=A0=C2=A0In the 2 drafts Mike J. pasted I find the u= se of the term "TLS Binding" confusing here because it's dangerously close = to "Channel Binding" which is *not* what these drafts are talking about.The= term =E2=80=9CTLS Binding=E2=80=9D is not used in either of the Token Bind= ing I-Ds. The term =E2=80=9CToken Binding=E2=80=9D was chosen to avoid over= loading the existing term =E2=80=9CChannel Binding=E2=80=9D.=C2=A0=C3=98=C2= =A0=C2=A0Are these drafts intended to allow a trust relationship to be buil= t on the client secret established during authentication, and that secret i= s then used to bring channel binding down into the HTTP layer?=C2=A0Authent= ication is out of the scope of these drafts. Once client authentication is = complete, the server will often issue security tokens for the client to pre= sent to this server (or other servers, in the federation case). Today, thes= e tokens can be intercepted or exported from the client machine and replaye= d, so the attacker can impersonate a valid user. These drafts allow the ser= ver to cryptographically bind security tokens to a (non-exportable, e.g. HW= -bound) key maintained by the client. The client proves possession of this = key on every TLS connection to the server, therefore once the security toke= n is presented, the server can verify that it came from the client that it = was issued to.=C2=A0Cheers,=C2=A0Andrei=C2=A0From:=C2=A0Bill Mills [mailto:= wmills_92105@yahoo.com]=C2=A0 Sent:=C2=A0Monday, December 8, 2014 6:30 PM To:=C2=A0Phil Hunt; John Bradley; unbearable@ietf.org Cc:=C2=A0Andrei Popov; Mike Jones; Derek Atkins; Stephen Farrell Subject:=C2=A0Re: [Unbearable] New Non-WG Mailing List: unbearable=C2=A0Spl= itting work on POP tokens between N>1 WG is almost certainly wrong if that'= s what we're doing. =C2=A0=C2=A0In the 2 drafts Mike J. pasted I find the u= se of the term "TLS Binding" confusing here because it's dangerously close = to "Channel Binding" which is *not* what these drafts are talking about. = =C2=A0If we are in fact doing channel binding then that's the term we shoul= d be using. =C2=A0Are these drafts intended to allow a trust relationship t= o be built on the client secret established during authentication, and that= secret is then used to bring channel binding down into the HTTP layer?=C2= =A0=C2=A0=C2=A0On Monday, December 8, 2014 3:18 PM, Phil Hunt wrote:=C2=A0Maybe all token work should be together in its own WG= ? Phil > On Dec 8, 2014, at 14:54, John Bradley wrote: >=C2=A0 > We did discuss this at the last IETF meeting. >=C2=A0 > While the work is closely related to the PoP work in OAuth it is not the = same.=C2=A0 It will allow us to do PoP tokens for the implicit flow, someth= ing that we haven't touched yet in OAuth because we don't have a workable w= ay to manage keys in the browser.=C2=A0 This work should allow us to do tha= t. >=C2=A0 > I think the slide deck examples showing JWT using different mechanisms to= express keys from the work done in the OAuth WG may be part of what has so= me people concerned. >=C2=A0 > I don't think these specs overlap with OAuth, but we do need to be mindfu= l of scope creep.=C2=A0 As I stated at the F2F we need to have the two grou= ps work together, so that we can have PoP tokens via the browser.=C2=A0=C2= =A0 >=C2=A0 > John B. >=C2=A0 >=C2=A0 >> On Dec 8, 2014, at 6:58 PM, Mike Jones wro= te: >>=C2=A0 >> It's my understanding that "Unbearable" is part of an effort to create a= new working group scoped to work on deliverables based upon these input do= cuments: >>=C2=A0 >>=C2=A0http://tools.ietf.org/html/draft-balfanz-https-token-binding >>=C2=A0http://tools.ietf.org/html/draft-popov-token-binding >>=C2=A0 >> I don't think that it was ever intended to cover every aspect of proof-o= f-possession and so there's not actually any conflict with the work we're a= lready doing in OAuth.=C2=A0 (Nor does it seem to me to be productive to ad= d even more documents-in-flight to the OAuth working group at present.) >>=C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers, >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike >>=C2=A0 >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Derek= Atkins >> Sent: Saturday, December 06, 2014 11:20 AM >> To:=C2=A0ietf@ietf.org >> Cc: Andrei Popov;=C2=A0unbearable@ietf.org; Stephen Farrell >> Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable >>=C2=A0 >> Hi, >>=C2=A0 >> IETF Secretariat writes: >>=C2=A0 >>> A new IETF non-working group email list has been created. >>>=C2=A0 >>> List address:=C2=A0unbearable@ietf.org >>> Archive:=C2=A0http://www.ietf.org/mail-archive/web/unbearable/ >>> To subscribe:=C2=A0https://www.ietf.org/mailman/listinfo/unbearable >>>=C2=A0 >>> Purpose: >>>=C2=A0 >>> This list is for discussion of proposals for doing better than bearer= =C2=A0 >>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications.=C2= =A0 >>> The specific goal is chartering a WG focused on preventing security=C2= =A0 >>> token export and replay attacks. >>=C2=A0 >>=C2=A0 >> The OAUTH Working Group is already (and has been for a while!) looking i= nto "holder of key" protocols to improve upon Bearer Tokens. >>=C2=A0 >> I would suggest that this work happen there instead of creating a whole = new group for it. >>=C2=A0 >> -derek >>=C2=A0 >>> For additional information, please contact the list administrators. >>=C2=A0 >> --=C2=A0 >>=C2=A0 =C2=A0 =C2=A0 Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 617-623-3745 >>=C2=A0 =C2=A0 =C2=A0=C2=A0derek@ihtfp.com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0www.ihtfp.com >>=C2=A0 =C2=A0 =C2=A0 Computer and Internet Security Consultant >>=C2=A0 >> _______________________________________________ >> Unbearable mailing list >>=C2=A0Unbearable@ietf.org >>=C2=A0https://www.ietf.org/mailman/listinfo/unbearable >>=C2=A0 >> _______________________________________________ >> Unbearable mailing list >>=C2=A0Unbearable@ietf.org >>=C2=A0https://www.ietf.org/mailman/listinfo/unbearable >=C2=A0 > _______________________________________________ > Unbearable mailing list >=C2=A0Unbearable@ietf.org >=C2=A0https://www.ietf.org/mailman/listinfo/unbearable _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable ------=_Part_143882_1645809645.1418252352372 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OAuth doesn't care about channe= l binding, a new token profile might, but that's why we separated the token= s from the core OAuth stuff.  

I think it is a (huge) mistake= to try to use TLS to try to establish a trust relationship beyond that TLS= context.




On Wednesday, December= 10, 2014 2:34 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:


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

This is not really for the OAuth clie= nts other than perhaps implicit ones in the browser.

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

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

<= div class=3D"yiv1155842625">I still think of this more at the TLS layer to = establish keys, but it is being described as being higher on the stack for = reasons=E2=80=A6

Token binding may be = a problematic name.  The specs should describe the key management part= s and how to get at the keys to bind the relevant public key portions to to= kens, but probably leave  the details for the application protocols th= at are going to use it.  OAuth should define how it is used to bind a = access token to the channel, and Connect should worry about it=E2=80=99s id= _tokens. etc.

It might be appropriate = to say something about cookies. 
= I think being clearer on what is and is not in scope will help.

John B.


=
On Dec 10, 2014, at 10:13 PM, Bill Mills <wmills_92105@yaho= o.com> wrote:

Rereading the two draft propos= e BOTH channel binding and what you are calling "token binding".  "Tok= en binding" being another name for proof-of-possession (POP) tokens, I pref= er the "POP" nomenclature as much more distinct.
<= br clear=3D"none" class=3D"yiv1155842625">
My orig= inal comments in the thread stand then, we're potentially duplicating some = of the work happening in OAuth here.  If we want to move token work ou= t of OAuth WG now that Bearer has established a workable first use case for= OAuth2 that's fine, but we need to make sure that's part of the discussion= .

The second topic, channel binding in HTTP is interesti= ng, and I think the question is whether we should define a generic HTTP cha= nnel binding hook is worthwhile.but I think the discussion is really around= whether there's value in putting the channel binding info into a header wh= ich various profiles could then sign against.  The previous comments a= bout the difficulties of doing channel binding over HTTP in a world of TLS = accelerators and HTTPS edge termination make this something of a huge chall= enge.  I think it's an interesting academic excercise, but the energy = needs to be spent in how we can deal with transitive trust in that type of = multi-hop sitation before we make a generic channel binding mechanism for H= TTP that's not workable or deployable in general.

-bill


On Wednesday, December 10, 2014 1:47 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:


Hi Bill,
 
=C3=98  In the 2 drafts Mike J. pasted I find the use of the te= rm "TLS Binding" confusing here because it's dangerously close to "Channel = Binding" which is *not* what these drafts are talking about.
The term =E2=80=9CTLS Binding=E2=80=9D is not used in either o= f the Token Binding I-Ds. The term =E2=80=9CToken Binding=E2=80=9D was chos= en to avoid overloading the existing term =E2=80=9CChannel Binding=E2=80=9D= .
 =
=C3=98  <= /span>= Are these drafts intended to allow a trust relationship to be built on the = client secret established during authentication, and that secret is then us= ed to bring channel binding down into the HTTP layer? 
Authentication is out of the scope of these drafts. Once client= authentication is complete, the server will often issue security tokens fo= r the client to present to this server (or other servers, in the federation= case). Today, these tokens can be intercepted or exported from the client = machine and replayed, so the attacker can impersonate a valid user. These d= rafts allow the server to cryptographically bind security tokens to a (non-= exportable, e.g. HW-bound) key maintained by the client. The client proves = possession of this key on every TLS connection to the server, therefore onc= e the security token is presented, the server can verify that it came from = the client that it was issued to.
 
Cheers,
 
= Andrei
 
From: Bill Mills [mailto:wmills_92105@yaho= o.com] <= br clear=3D"none" class=3D"yiv1155842625">Sent:<= /b> Monday, = December 8, 2014 6:30 PM
To: Phil Hunt; John Bradley; unbearable@ietf.org
Cc: Andrei Popov; Mike= Jones; Derek Atkins; Stephen Farrell
Subject: Re: [Unbearable] New Non-WG Mailing List: = unbearable
 
Splitting work on POP tokens between N>1 WG = is almost certainly wrong if that's what we're doing.  
 
In the 2 drafts Mike J. pasted I find the use of the term "TLS = Binding" confusing here because it's dangerously close to "Channel Binding"= which is *not* what these drafts are talking about.  If we are in fac= t doing channel binding then that's the term we should be using.  Are = these drafts intended to allow a trust relationship to be built on the clie= nt secret established during authentication, and that secret is then used t= o bring channel binding down into the HTTP layer? 
<= div class=3D"yiv1155842625" id=3D"yiv1155842625yui_3_16_0_1_1418086332840_2= 8855">
 
 
On Monday, Decemb= er 8, 2014 3:18 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
&nbs= p;
Maybe all token work should be to= gether in its own WG?

Phil

> On Dec 8, 2014, at 14= :54, John Bradley <ve7jtb@ve7jtb.com> = wrote:
> 
> We did discuss this at the last IETF meeting.
> 
> While = the work is closely related to the PoP work in OAuth it is not the same.&nb= sp; It will allow us to do PoP tokens for the implicit flow, something that= we haven't touched yet in OAuth because we don't have a workable way to ma= nage keys in the browser.  This work should allow us to do that.
> 
&g= t; I think the slide deck examples showing JWT using different mechanisms t= o express keys from the work done in the OAuth WG may be part of what has s= ome people concerned.
> 
> I don't think these specs overlap with OAuth,= but we do need to be mindful of scope creep.  As I stated at the F2F = we need to have the two groups work together, so that we can have PoP token= s via the browser. =  
> 
> John B.
&= gt; 
> 
>= > On Dec 8, 2014, at 6:58 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>> 
>= > It's my understanding that "Unbearable" is part of an effort to create= a new working group scoped to work on deliverables based upon these input = documents:
>> 
>> http://tools.ietf.org/html/draft-b= alfanz-https-token-binding
&g= t;> http://tools.ietf.org/html/draft-popov-token-binding
>> 
>> I don't think that it was ever intended to cover every aspect of = proof-of-possession and so there's not actually any conflict with the work = we're already doing in OAuth.  (Nor does it seem to me to be productiv= e to add even more documents-in-flight to the OAuth working group at presen= t.)
>> 
>>                = Cheers,
>>    &nb= sp;           -- Mike
>>&n= bsp;
>> -----Origina= l Message-----
>> From: Unb= earable [mailto:unbearable-bounces@ietf.org] On Behalf Of Derek Atkins
>> Sent: Saturday, December 06, 20= 14 11:20 AM
>> To: ietf@ietf.org
>> Cc: Andrei Popov; unb= earable@ietf.org; Stephen Farrell
>> Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable=
>> 
>> Hi,
>> 
>> IETF Secretariat <ietf-secretariat@ietf.org> writes:
>> 
>>> A new IETF non-working group email list h= as been created.
>>> 
>>> List address: unbearable@ietf.org
>>> Archive: http://www.ietf.org= /mail-archive/web/unbearable/
>>> To subscribe: https://www.ietf.org/mai= lman/listinfo/unbearable
>= >> >>> Purpose:
>>> 
&g= t;>> This list is for discussion of proposals for doing better than b= earer 
>>> tokens (e.g. HTTP cookies= , OAuth tokens etc.) for web applications. 
&= gt;>> The specific goal is chartering a WG focused on preventing secu= rity 
>>> token export and replay at= tacks.
>> 
>>&n= bsp;
>> The OAUTH Wo= rking Group is already (and has been for a while!) looking into "holder of = key" protocols to improve upon Bearer Tokens.
>>&nb= sp;
>> I would sugge= st that this work happen there instead of creating a whole new group for it= .
>> 
>> -derek
>>=  
>>> For additional information, = please contact the list administrators.
>> 
>> -- 
>>      Derek Atkins     = ;           617-623-3745
>>      derek@ihtfp.com            www.ihtfp.com=
>>     = Computer and Internet Security Consultant
>> =
>> ________________= _______________________________
&= gt;> Unbearable mailing list
&= gt;> Unbearable@ietf.org
>> http= s://www.ietf.org/mailman/listinfo/unbearable
>>=  
>> __________= _____________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
> 
> ____________= ___________________________________
> Unbearable mailing list
&= gt; Unbearable@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/unbearable

______________________= _________________________
Unbeara= ble mailing list
Unbearable@ietf.org
https://www.i= etf.org/mailman/listinfo/unbearable



------=_Part_143882_1645809645.1418252352372-- From nobody Wed Dec 10 15:05:21 2014 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 5AAD31A1A99 for ; Wed, 10 Dec 2014 15:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Fupqr0tOUjnY for ; Wed, 10 Dec 2014 15:05:19 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC411AC41C for ; Wed, 10 Dec 2014 15:05:17 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id z11so3193935lbi.10 for ; Wed, 10 Dec 2014 15:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=c2yAYaFB/zjDrKAj/eyOM1eOH6aTb15q5yby+Z6q/f0=; b=JWU9AnxkOYhNcodKrkwhw9wXrXvW+B4s4zQUXq+zZc6CPfmi5S6L/TRDzzqSDL2ij9 kiaOvMaNiKn27rNLE5wyca2kU+XN+cGEEAv25AgdS3NJYqRvgba6/1Wa/oRXc+w2HqQg DRzWEDyzNeRmk4NLMx4lpLQLUB3IsQAwHOTc5eG9VescUkGZG5j57ne9f6+a+bon8Kqn NMSsdgf0TeMoDgFqjevUUKp58Ej1EfK9l0LVBFF/53No7kGBv4R8nxVxyJFzFfpRioM6 aVo3FFvMS80Ijg899MVmAzjjpT/1C330UN6sZ5HulHelJXC/zKWEu5TKNfZRsTVEmlI1 qVSA== MIME-Version: 1.0 X-Received: by 10.152.219.3 with SMTP id pk3mr6541109lac.19.1418252715807; Wed, 10 Dec 2014 15:05:15 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Wed, 10 Dec 2014 15:05:15 -0800 (PST) In-Reply-To: References: <54863200.4030600@cs.tcd.ie> Date: Wed, 10 Dec 2014 18:05:15 -0500 X-Google-Sender-Auth: jiW-wr_9Zajb5-8TtwVS6PzKOM8 Message-ID: From: Phillip Hallam-Baker To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113409d453daaf0509e4b1b5 Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/d4pPouP63pDBW57GMoakRKnTpuk Cc: "unbearable@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 10 Dec 2014 23:05:20 -0000 --001a113409d453daaf0509e4b1b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2014 at 3:45 PM, Andrei Popov wrote: > =C3=98 One of the main constraints on the Web authentication/authorizat= ion > proposals has been that they have to work with existing browsers. > > Yes, this is a valid constraint, and it does affect the design choices. > Perhaps we should make this more explicit in the charter. > What is the design space here? Are we fitting into existing browsers or not? I am rather fed up of the idea that we never ever consider doing the job right. Yes it might take ten years before we reach 95% penetration but we can get to 30% in one Chrome release cycle. With Windows 10 we can expect something like 80% of the browsers to be on automatic update. And we did SAML ten years ago now. Think of where we might be now had we done a clean implementation along side the legacy preserving then. We don't need to make a leap in the dark here either. Web Services use HTTP and there are brand new ones every week. So if we design something that can be used for Web Services, we can eventually use it for other purposes. Even a 30% reduction in affiliate fraud is real money. The way I map out the space for authentication is that I see three separate processes, all of which are called 'authentication' but are different things. I was once on a panel on 'reauthentication' and the two other speakers had incompatible definitions. 1) Credential Issue This may or may not involve authentication of Alice, in the PKI world we call it validation. 2) Use of credential to initiate session Where I suspect this is to be situated, currently password oriented. 3) Session continuation Currently the weakest of the lot, the fact we use cookies as bearer tokens in HTTPS makes eavy demands on the crypto protocol. --001a113409d453daaf0509e4b1b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 10, 2014 at 3:45 PM, Andrei Popov <Andrei.Popov@microsoft= .com> wrote:

=C3=98=C2= =A0 One of the main constraints on the Web authenti= cation/authorization proposals has been that they have to work with existin= g browsers.

Yes, this is a valid constraint, and = it does affect the design choices. Perhaps we should make this more explici= t in the charter.


Wh= at is the design space here? Are we fitting into existing browsers or not?= =C2=A0

I am rather fed up of the idea that we neve= r ever consider doing the job right. Yes it might take ten years before we = reach 95% penetration but we can get to 30% in one Chrome release cycle. Wi= th Windows 10 we can expect something like 80% of the browsers to be on aut= omatic update.

And we did SAML ten years ago now. = Think of where we might be now had we done a clean implementation along sid= e the legacy preserving then.


We do= n't need to make a leap in the dark here either. Web Services use HTTP = and there are brand new ones every week. So if we design something that can= be used for Web Services, we can eventually use it for other purposes.

Even a 30% reduction in affiliate fraud is real money= .


The way I map out the space for a= uthentication is that I see three separate processes, all of which are call= ed 'authentication' but are different things. I was once on a panel= on 'reauthentication' and the two other speakers had incompatible = definitions.

1) Credential Issue
=C2=A0 = =C2=A0 =C2=A0This may or may not involve authentication of Alice, in the PK= I world we call it validation.

2) Use of credenti= al to initiate session
=C2=A0 =C2=A0 =C2=A0= Where I suspect this is to be situated, currently password oriented.
<= div class=3D"gmail_extra">
3) Session c= ontinuation
=C2=A0 =C2=A0 =C2=A0Currently t= he weakest of the lot, the fact we use cookies as bearer tokens in HTTPS ma= kes eavy demands on the crypto protocol.

--001a113409d453daaf0509e4b1b5-- From nobody Wed Dec 10 15:16:47 2014 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 BB2651A0105 for ; Wed, 10 Dec 2014 15:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3DHCbB3SVq3G for ; Wed, 10 Dec 2014 15:16:44 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A931A001B for ; Wed, 10 Dec 2014 15:16:43 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so6834631wiw.15 for ; Wed, 10 Dec 2014 15:16:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=TXtxm7IYD519r1g3oLYbJK8suCDW4INUqJlDLLa9dws=; b=HT3jfD3rMmfoULKzgVL+SaeOHrJan5//vEVPxkGUiNYr3LJWHhyvVL+cBDzDervG5S Zmf1L0r45jBPJIJ6pPUSo7DzExxPPFNx8ELBLrB3mNRwhz4NtAMplXBhgqT3zK/PwtdE i7BrCKlzpD26UWPxeAa9gOoiP8Yfd8OxT4ggzPYvvzicAMp/lFb8SFap3ZV62TF5tNzH QMIGfVtKWqinsnLH3V/7+VZ/XR6u4I9fZNgRmmPhdq2Oql2VHG3pfYZ6JDn8jtMubJsN VfS0LK9b8Zqf1Pz9vNL6fwOWYWWU9XTJ/jFLR3YIydteqIo+pXpx6AjXZWD2rxXWSSy7 HhJQ== X-Gm-Message-State: ALoCoQmNZYireirNAnoSx+MDTN4c0TItfdrMxHpwhkc3TXWv6AxOUOyIys+sd2r7hKs/rEvjlTnG X-Received: by 10.194.85.137 with SMTP id h9mr104793wjz.70.1418253402274; Wed, 10 Dec 2014 15:16:42 -0800 (PST) Received: from [172.30.17.77] ([146.255.1.43]) by mx.google.com with ESMTPSA id kn5sm7633117wjb.48.2014.12.10.15.16.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 15:16:41 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_93681BC0-5A2E-4113-AAAA-36A7F8AE6368"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: Date: Wed, 10 Dec 2014 23:16:39 +0000 Message-Id: References: <54863200.4030600@cs.tcd.ie> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/1I2g00OHN_o3Un_uBtYQbqC28-M Cc: Andrei Popov , "unbearable@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 10 Dec 2014 23:16:46 -0000 --Apple-Mail=_93681BC0-5A2E-4113-AAAA-36A7F8AE6368 Content-Type: multipart/alternative; boundary="Apple-Mail=_A3AE50AB-6B3B-48B2-806D-8737E6B29704" --Apple-Mail=_A3AE50AB-6B3B-48B2-806D-8737E6B29704 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As I understand it this is proposing a change to browsers. Browsers = will need to be updated. There is a pre standard version of this in = Chrome now but even that would need to change. I don=E2=80=99t think this WG is considering anything that would work = with a current browser. That is why I don=E2=80=99t think it overlaps with current OAuth work = using static client keys. John B. > On Dec 10, 2014, at 11:05 PM, Phillip Hallam-Baker = wrote: >=20 > On Wed, Dec 10, 2014 at 3:45 PM, Andrei Popov = > wrote: > =C3=98 One of the main constraints on the Web = authentication/authorization proposals has been that they have to work = with existing browsers. >=20 > Yes, this is a valid constraint, and it does affect the design = choices. Perhaps we should make this more explicit in the charter. >=20 >=20 > What is the design space here? Are we fitting into existing browsers = or not?=20 >=20 > I am rather fed up of the idea that we never ever consider doing the = job right. Yes it might take ten years before we reach 95% penetration = but we can get to 30% in one Chrome release cycle. With Windows 10 we = can expect something like 80% of the browsers to be on automatic update. >=20 > And we did SAML ten years ago now. Think of where we might be now had = we done a clean implementation along side the legacy preserving then. >=20 >=20 > We don't need to make a leap in the dark here either. Web Services use = HTTP and there are brand new ones every week. So if we design something = that can be used for Web Services, we can eventually use it for other = purposes. >=20 > Even a 30% reduction in affiliate fraud is real money. >=20 >=20 > The way I map out the space for authentication is that I see three = separate processes, all of which are called 'authentication' but are = different things. I was once on a panel on 'reauthentication' and the = two other speakers had incompatible definitions. >=20 > 1) Credential Issue > This may or may not involve authentication of Alice, in the PKI = world we call it validation. >=20 > 2) Use of credential to initiate session > Where I suspect this is to be situated, currently password = oriented. >=20 > 3) Session continuation > Currently the weakest of the lot, the fact we use cookies as = bearer tokens in HTTPS makes eavy demands on the crypto protocol. >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_A3AE50AB-6B3B-48B2-806D-8737E6B29704 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As I understand it this is proposing a change to browsers. =  Browsers will need to be updated.  There is a pre standard = version of this in Chrome now but even that would need to change.

I don=E2=80=99t think = this WG is considering anything that would work with a current = browser.

That = is why I don=E2=80=99t think it overlaps with current OAuth work using = static client keys.

John B.

On Dec 10, 2014, at 11:05 PM, = Phillip Hallam-Baker <phill@hallambaker.com> wrote:

On Wed, = Dec 10, 2014 at 3:45 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

=C3=98  One of the main constraints on = the Web authentication/authorization proposals has been that they have = to work with existing browsers.

Yes, this is a valid constraint, and it does affect = the design choices. Perhaps we should make this more explicit in the = charter.


What is the design space here? Are we = fitting into existing browsers or not? 

I am rather fed up of the idea that we = never ever consider doing the job right. Yes it might take ten years = before we reach 95% penetration but we can get to 30% in one Chrome = release cycle. With Windows 10 we can expect something like 80% of the = browsers to be on automatic update.

And we did SAML ten years ago now. = Think of where we might be now had we done a clean implementation along = side the legacy preserving then.


We = don't need to make a leap in the dark here either. Web Services use HTTP = and there are brand new ones every week. So if we design something that = can be used for Web Services, we can eventually use it for other = purposes.

Even = a 30% reduction in affiliate fraud is real money.

The= way I map out the space for authentication is that I see three separate = processes, all of which are called 'authentication' but are different = things. I was once on a panel on 'reauthentication' and the two other = speakers had incompatible definitions.

1) Credential Issue
     This may or may not involve = authentication of Alice, in the PKI world we call it = validation.

2) Use of = credential to initiate session
  =    Where I suspect this is to be situated, currently password = oriented.

3) Session continuation
     Currently the weakest of the = lot, the fact we use cookies as bearer tokens in HTTPS makes eavy = demands on the crypto protocol.


_______________________________________________
Unbearable = mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

= --Apple-Mail=_A3AE50AB-6B3B-48B2-806D-8737E6B29704-- --Apple-Mail=_93681BC0-5A2E-4113-AAAA-36A7F8AE6368 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMTAyMzE2NDBaMCMGCSqGSIb3DQEJBDEWBBRV2px+25oBh+S/u4Htk+8e iaHWFDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQB8ZwD7qSI1Bo0FSUAea0TQIBXmLYqna3rF6MiB6TX5kPTJ3RwBUPhF u+Ml3t335NeNhoTVBNsoqIekJMolCMTNxurMYpTMiKSBn4FD/hU79iayeKI+GynBaEEn5OvFYPtd 2DJnJJwvKDB/PamRx6cHNKbWnOHKYNtY5twAOVTkLjvQCM+tevUAHUgE1WU7pxV4Ky0na3WTmX+d +d4iNwQEnn4V9N4suW1ZmdgYDNn2gWk9hAfK04cY5Bvpcf6YWfU/NFFLM4UKJlsRvtaPkkiiNjNP DDYrlnpvDo3DjATlcZeR9dbztLrqUgaz5X9xtJFpJpFgiCUG60AI8ElGeELqAAAAAAAA --Apple-Mail=_93681BC0-5A2E-4113-AAAA-36A7F8AE6368-- From nobody Wed Dec 10 18:12:43 2014 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 5E0CB1A0162 for ; Wed, 10 Dec 2014 18:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 rOorD9_RKL6g for ; Wed, 10 Dec 2014 18:12:40 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B477D1A0047 for ; Wed, 10 Dec 2014 18:12:39 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id u10so3296325lbd.20 for ; Wed, 10 Dec 2014 18:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=I8jj2uDiR0GJwClV5SIZofpLyEkHffEg9YLjUqEW8as=; b=n+3lcUtwv1ak3gLBmOMOTEPBNLF6LaZTrWsyYcvfFshLf3HgxjtzrlGztZZH/288kT f/TvmxPrtIvzPFfhtgfi/zvOH+gWG0Rr6FpWeGWZ8cvV/gFcFBOdSzYG3m5DHgbyEOeA nwBoenxudJIBCHseln5UmCQTMzNRjmypkAlIxNYo4zB2uIvs2Z/9ZxXq8LGL+n11CEBe dPNbS8NnybJCeq6rqxK7pJ0BpH9rAQsUIq5vV1h+H++I2eJBKhUOeKYcG660UdXU0tFG jouNHwVB91s/t+aYfAwvixEvcD5YrBy2UUGgRUnReeONJx5j14bxyAWKf6Vf1Pa+jqT8 Bc7Q== MIME-Version: 1.0 X-Received: by 10.112.141.233 with SMTP id rr9mr7182297lbb.1.1418263958220; Wed, 10 Dec 2014 18:12:38 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Wed, 10 Dec 2014 18:12:38 -0800 (PST) In-Reply-To: References: <54863200.4030600@cs.tcd.ie> Date: Wed, 10 Dec 2014 21:12:38 -0500 X-Google-Sender-Auth: hyknnWi-27c1eeG9ccUcSWeSXm8 Message-ID: From: Phillip Hallam-Baker To: John Bradley Content-Type: multipart/alternative; boundary=001a11c38be86d772b0509e74f12 Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/9NlN_U3XYUtPAeQf3oO_wYWWhbo Cc: Andrei Popov , "unbearable@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 02:12:41 -0000 --001a11c38be86d772b0509e74f12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Dec 10, 2014 at 6:16 PM, John Bradley wrote: > As I understand it this is proposing a change to browsers. Browsers will > need to be updated. There is a pre standard version of this in Chrome no= w > but even that would need to change. > > I don=E2=80=99t think this WG is considering anything that would work wit= h a > current browser. > > That is why I don=E2=80=99t think it overlaps with current OAuth work usi= ng static > client keys. > OK, that does make a major difference. But where does it fit in this: > 1) Credential Issue > This may or may not involve authentication of Alice, in the PKI worl= d > we call it validation. > > 2) Use of credential to initiate session > Where I suspect this is to be situated, currently password oriented. > > 3) Session continuation > Currently the weakest of the lot, the fact we use cookies as bearer > tokens in HTTPS makes eavy demands on the crypto protocol. > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > > --001a11c38be86d772b0509e74f12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 10, 2014 at 6:16 PM, John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:
As I understand it this is proposing a change to browsers.=C2= =A0 Browsers will need to be updated.=C2=A0 There is a pre standard version= of this in Chrome now but even that would need to change.

I don=E2=80=99t think this WG is considering anything that would work wi= th a current browser.

That is why I don=E2=80=99t = think it overlaps with current OAuth work using static client keys.

OK, that does make a major difference.=

But where does it fit in this:
=C2=A0
=
1) Credent= ial Issue
=C2=A0 =C2=A0 =C2=A0This may or may not involve authent= ication of Alice, in the PKI world we call it validation.

2) Use of credential to initiate session
=C2=A0 =C2=A0 =C2=A0Where I suspect this is to be situated, currentl= y password oriented.

3) Session continuation
= =C2=A0 =C2=A0 =C2=A0Currently the weakest of the lot, the fact we use cooki= es as bearer tokens in HTTPS makes eavy demands on the crypto protocol.


_______________________________________________
Unbearable mailing list<= br>Unbearable@ietf= .org
https://www.ietf.org/mailman/listinfo/unbearable


<= /div> --001a11c38be86d772b0509e74f12-- From nobody Wed Dec 10 21:08:01 2014 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 6FF8B1A09C9 for ; Wed, 10 Dec 2014 21:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 g4lk7rVbiJ65 for ; Wed, 10 Dec 2014 21:07:38 -0800 (PST) Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8B81A020D for ; Wed, 10 Dec 2014 21:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1418274457; bh=psr8AiFwXbJoJte+wMToHzIPWO9tRNHBEiU+mfEk1as=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=uUR73T4bJXOO6snSXR1AdzEmjLxcmoaaWaoE25V74kA/KHx6N6Tqacja/Z6iJ8nZzMFGS99o03iQdtSYENTb+B2FOfmqkwALnqM0Nn/ktTQ0DEQl5/8tUoXXbmaUBVqqtgMBijK+Ta1EWfrKz285N/LG7im5VdOMXrQG6qVubWlS9k6n6en7wOH/lVqR1tGw4ch7GzzVEs8vZPPsCN2tACLc8WuB8+WnuwJQFpYu/wXfTWBGVJJDipsUFOW0WIBM8vv9tl4fTgNKZDOy/466Ud1Db6325rBXJwk/s0yGwvIwB3kfvIfMxtcgC429OG/S+ZxlmLOH2gQ96t2yIQw45A== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=IN4DgJAKKgps0bRgSRkw9/XIUBHO8tJF0IB7bRGHeMLiKUYoHUg9ld4O4kCOQ3woNMUP/BLepoYSUAzyD/iVyH8XWT7O6wtFQVcmyc4ooHGCVoCgMFSCIu4RxGaM3NL5RI+UqEZ4V2d6NIysMSXL83SryGjTB4r51fQ7Ny81N423XWN1utPQB+2n4SPX1wK6crtOnZ2G3MJ1qO9tlKDfbZzaZhCYDO1Z6OMI5w74Z8scu8CKmP4aIyc5QHFwM47sGnrT32Iap2hqSrTdZuVrf458QIsJ3BAD7Ic2oQE3sgCAJu+E+pqba7NNksP6Hydw+n0dYxEvnGwWcbo86bk7sw==; Received: from [66.196.81.170] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 11 Dec 2014 05:07:37 -0000 Received: from [98.139.212.235] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 11 Dec 2014 05:07:37 -0000 Received: from [127.0.0.1] by omp1044.mail.bf1.yahoo.com with NNFMP; 11 Dec 2014 05:07:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 601341.9193.bm@omp1044.mail.bf1.yahoo.com X-YMail-OSG: nXaZwncVM1ntkPQ9eMK7qHDhsyyo6R_Slce5EEEtuRofKkdGyRoKZSrLekFzJVc aREM62JhNjxbSQrgSvfIcKhdmGe__NBjqE.AAQmCyl2VpU3r1PyZ7wFtj_cuyYUMVwMwer_EigHH ObBpAwgFSwrxx7hM1Qy5aecbVhfRzXraxaw.Cm8lkxAexradNa2X0izIDOODjxX1N76l.g4me.QB 4GzCBKaByU3B20YnYzQJYXUegOCLqqkgXDwpzBmGECK5wDZDMDGDjWwLp0Svuwtv2fBy9u0iUipU _OdGSSyGd_WDjiBVkqb_BmGkhGX7eVm0Hrng26jzNiphnWXAAW40_kHVXP43kb2_A0aXguVvN2cd ViuMl16cCVc6gy83slVTrH5T8bODJlj2PCIbAzw3yGW.TSufF_2y3CRJYtVjVnHtL6vPwEqblQqC i2QueUkIzeRlrF0Z77kRrHDnumfMUOsEgjybOZgJiCL8EJpt6Et6HMvSO7Z45W0vwOECMrk91Wm5 ryrTVYk_g Received: by 76.13.26.138; Thu, 11 Dec 2014 05:07:37 +0000 Date: Thu, 11 Dec 2014 05:07:36 +0000 (UTC) From: Bill Mills To: Phillip Hallam-Baker , John Bradley Message-ID: <775296481.8248427.1418274456817.JavaMail.yahoo@jws10607.mail.bf1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8248426_840178551.1418274456811" Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/sRR95E8poNaUb2Ec-Zvbrb-CqWI Cc: Andrei Popov , "unbearable@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills 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, 11 Dec 2014 05:07:59 -0000 ------=_Part_8248426_840178551.1418274456811 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nothing in the current OAuth work requires a static client key as far as I = know. =C2=A0No reason a key can't be issued per credential just like in OAu= th 1.0a or bound to a cred if the client provides a public key when it auth= enticates.=20 On Wednesday, December 10, 2014 6:12 PM, Phillip Hallam-Baker wrote: =20 =20 On Wed, Dec 10, 2014 at 6:16 PM, John Bradley wrote: As I understand it this is proposing a change to browsers.=C2=A0 Browsers w= ill need to be updated.=C2=A0 There is a pre standard version of this in Ch= rome now but even that would need to change. I don=E2=80=99t think this WG is considering anything that would work with = a current browser. That is why I don=E2=80=99t think it overlaps with current OAuth work using= static client keys. OK, that does make a major difference. But where does it fit in this:=C2=A0 1) Credential Issue=C2=A0 =C2=A0 =C2=A0This may or may not involve authenti= cation of Alice, in the PKI world we call it validation. 2) Use of credential to initiate session=C2=A0 =C2=A0 =C2=A0Where I suspect= this is to be situated, currently password oriented. 3) Session continuation=C2=A0 =C2=A0 =C2=A0Currently the weakest of the lot= , the fact we use cookies as bearer tokens in HTTPS makes eavy demands on t= he crypto protocol. _______________________________________________ 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 ------=_Part_8248426_840178551.1418274456811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nothing in the current OAuth wo= rk requires a static client key as far as I know.  No reason a key can= 't be issued per credential just like in OAuth 1.0a or bound to a cred if t= he client provides a public key when it authenticates.


On Wednesday, December 10, 2014 6:12 PM, Phillip Hallam-Baker = <phill@hallambaker.com> wrote:




On Wed, Dec 10, 2014 at 6:16 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
As I understand it this is proposing a change to browsers.  Brows= ers will need to be updated.  There is a pre standard version of this = in Chrome now but even that would need to change.

I don= =E2=80=99t think this WG is considering anything that would work with a cur= rent browser.

That is why I don=E2=80=99t think it= overlaps with current OAuth work using static client keys.

OK, that does make a major difference.

But where does it fit in this:
 
=
1) Credential Issue
  &n= bsp;  This may or may not involve authentication of Alice, in the PKI = world we call it validation.

2) Use of credential= to initiate session
  &n= bsp;  Where I suspect this is to be situated, currently password orien= ted.

3) Session continuation
     Currently the weakest of the lot, th= e fact we use cookies as bearer tokens in HTTPS makes eavy demands on the c= rypto protocol.


_______________________________________________
Unbearable mailing list<= br>Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable



_______________________________________________
Unbearable= mailing list
Unbearable@ietf.org
https://www.ietf.org/mai= lman/listinfo/unbearable


------=_Part_8248426_840178551.1418274456811-- From nobody Wed Dec 10 22:33:38 2014 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 25F9C1A854A for ; Wed, 10 Dec 2014 22:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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 wBwd8WVTiw9E for ; Wed, 10 Dec 2014 22:33:34 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323E11A88BE for ; Wed, 10 Dec 2014 22:33:34 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l2so5530304wgh.41 for ; Wed, 10 Dec 2014 22:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4nm8oQqoHOVMDtV3A+xCmy/kGvQmZ26o+ar+2V9udGg=; b=nKDJTIZfOADW60NgwLj3cmqhnSMcbvSzCy6k2HJ/AO4ut/0Onso2t3EpEZHKuAgVj8 G8PJFbjbwy9hqF+UpBLSI5u2xWaIlx1D79BCFJGqSO6D1OLIjSMC4qU/aRkf8Xu686ek 4R63ZrtuhTbWLdewVzFmwwpuUWcDXCJjFe1es4ISh5/9E676Ve8POQqmBE0ZJYNt0CmT RC/bPvMjCStNfAlONwc+KV+CdnOjEan/bdGgYFbAabvJC6a7F0igbchnpgug11P5V97F FzW3LxAGRptu6Z4W8UnPYukEI4zODvfaZaqgvZK89Tjowd3jg7NU7hcphK2TTjh3vLmu 1QdA== X-Received: by 10.194.94.233 with SMTP id df9mr13085518wjb.46.1418279612954; Wed, 10 Dec 2014 22:33:32 -0800 (PST) Received: from yoavs-mbp.mshome.net ([109.253.142.216]) by mx.google.com with ESMTPSA id wx3sm377801wjc.19.2014.12.10.22.33.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 22:33:32 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1FBB908A-A9E6-4043-A2E8-D350B382C753" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Thu, 11 Dec 2014 08:33:25 +0200 Message-Id: <805D5302-B71A-4E35-86D3-337D1E948511@gmail.com> References: <54863200.4030600@cs.tcd.ie> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/b40QF9Sfhj_ADky2QJmzLTTFYTU Cc: John Bradley , Andrei Popov , "unbearable@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 06:33:37 -0000 --Apple-Mail=_1FBB908A-A9E6-4043-A2E8-D350B382C753 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 11, 2014, at 4:12 AM, Phillip Hallam-Baker = wrote: >=20 >=20 >=20 > On Wed, Dec 10, 2014 at 6:16 PM, John Bradley > wrote: > As I understand it this is proposing a change to browsers. Browsers = will need to be updated. There is a pre standard version of this in = Chrome now but even that would need to change. >=20 > I don=E2=80=99t think this WG is considering anything that would work = with a current browser. >=20 > That is why I don=E2=80=99t think it overlaps with current OAuth work = using static client keys. >=20 > OK, that does make a major difference. >=20 > But where does it fit in this: > =20 >> 1) Credential Issue >> This may or may not involve authentication of Alice, in the PKI = world we call it validation. >>=20 >> 2) Use of credential to initiate session >> Where I suspect this is to be situated, currently password = oriented. >>=20 >> 3) Session continuation >> Currently the weakest of the lot, the fact we use cookies as = bearer tokens in HTTPS makes eavy demands on the crypto protocol. Looking at the proposals, it=E2=80=99s mostly (3) with a little bit = about (2) What I am worried about is that it addresses just one of the issues in = HTTP cookies. The other (bigger, IMO) issue is with the scope of = cookies, and there are two drafts proposed in httpbis (and not getting = much discussion) that attempt to address that. A poor outcome would be two or three =E2=80=9Cnew cookie=E2=80=9D = mechanisms, each addressing just one of the shortcomings of cookies. = That would be bad for both browser implementers and application = developers. Yoav --Apple-Mail=_1FBB908A-A9E6-4043-A2E8-D350B382C753 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Dec 11, 2014, at 4:12 AM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:



On Wed, Dec 10, 2014 at 6:16 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
As I understand it this is = proposing a change to browsers.  Browsers will need to be = updated.  There is a pre standard version of this in Chrome now but = even that would need to change.

I don=E2=80=99t think this WG is considering anything that = would work with a current browser.

That is why I don=E2=80=99t think it = overlaps with current OAuth work using static client = keys.

OK, that does make a major difference.
But where does it fit in = this:
 
1) Credential Issue
     This may or may not involve = authentication of Alice, in the PKI world we call it = validation.

2) Use of = credential to initiate session
  =    Where I suspect this is to be situated, currently password = oriented.

3) Session continuation
     Currently the weakest of the = lot, the fact we use cookies as bearer tokens in HTTPS makes eavy = demands on the crypto = protocol.

Looking at the proposals, it=E2=80=99s mostly (3) = with a little bit about (2)

What I = am worried about is that it addresses just one of the issues in HTTP = cookies. The other (bigger, IMO) issue is with the scope of cookies, and = there are two drafts proposed in httpbis (and not getting much = discussion) that attempt to address that.

A poor outcome would be two or three =E2=80=9Cnew = cookie=E2=80=9D mechanisms, each addressing just one of the shortcomings = of cookies. That would be bad for both browser implementers and = application developers.

Yoav


= --Apple-Mail=_1FBB908A-A9E6-4043-A2E8-D350B382C753-- From nobody Wed Dec 10 23:48:15 2014 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 C4BCF1ACD15 for ; Wed, 10 Dec 2014 23:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 dpTchHAbqLOj for ; Wed, 10 Dec 2014 23:47:50 -0800 (PST) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459E71A1BFA for ; Wed, 10 Dec 2014 23:47:50 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so5659076wgh.34 for ; Wed, 10 Dec 2014 23:47:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=TzluZcjL1MyYmfaLoiDLKmeh4+Ob7v3734Zo6jBl6nA=; b=cG7tfXxo3ZA+Z8oCJcDBNpCtM7R3e9bpHnIFa7UhtHIHJmb6tczQeMNG1XwyeL/nrm KXHWDPM312o5yrVIQNu3/qxJC6gg86DDtNHOG6sBofotdGq4V9e66OTQS9lIKowQ28Q7 SojV/y84axYDieLoR4cTrswBzeeoHayojGogdi9ijyeYGJwobigZDYaRKbrtKF8SWdHV RmTi2wgF5HzXGs9zCoT7wnQEAen62YddnBTgWVZMIYgMGOxKAVU7kWe08LMOwQrSrIZx fZBEpLhYOgHbC1SedJGpArT3mKAyI3SlOpg9C2HgGN0cUTZA7C+09vUhRaRE1FZ2UkEi 6lRw== X-Gm-Message-State: ALoCoQlT26giyIs9UXtrw5GUyamGEYYE3gcv5b6b6denrD2pcvC9USAZ3odmxYTPklIfVk6tuYvQ X-Received: by 10.194.95.196 with SMTP id dm4mr14079905wjb.41.1418284068780; Wed, 10 Dec 2014 23:47:48 -0800 (PST) Received: from [172.30.17.77] ([146.255.1.43]) by mx.google.com with ESMTPSA id bo18sm1229055wib.11.2014.12.10.23.47.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Dec 2014 23:47:47 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_4F76E9AD-0CDE-4151-A584-61F9AA99459B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: <775296481.8248427.1418274456817.JavaMail.yahoo@jws10607.mail.bf1.yahoo.com> Date: Thu, 11 Dec 2014 07:47:45 +0000 Message-Id: References: <775296481.8248427.1418274456817.JavaMail.yahoo@jws10607.mail.bf1.yahoo.com> To: Bill Mills X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/P7QDZeo9zhSo5rfExGFhBf_zDjo Cc: Andrei Popov , Phillip Hallam-Baker , "unbearable@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 07:47:53 -0000 --Apple-Mail=_4F76E9AD-0CDE-4151-A584-61F9AA99459B Content-Type: multipart/alternative; boundary="Apple-Mail=_D9FA8FB7-24F8-476A-A631-DB35AB9C80B5" --Apple-Mail=_D9FA8FB7-24F8-476A-A631-DB35AB9C80B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Bill, Yes in OAuth we can issue keys on a per token basis to the client. = However these specs are about the browser, and we don=E2=80=99t = currently have any thing for browser clients other than being public. Currently we have no way to get a key into the browser that can be used = across connections. Even with web crypto we can only provision a key that works with a = single origin as I understand it. These specs create a way for the browser to expose the public key = material that it uses for its end of mutual TLS connections, and allow = that to be communicated across related sessions. Allowing it to be communicated between related sessions is new to this = proposal and a limitation of the original channel binding and origin = bound certificates. If we called this something like "Interface for exposing Origin bound = public keys=E2=80=9D then people might be less worked up (though some = are concerned about overlap with HTTP bis and other things that are = unrelated to tokens). It is the spec using the term token in the name = that infers a larger scope. I am not one of the proposers of this WG. But I read the proposal as = something OAuth can use to fill a gap, like we use TLS, not something = that intends to compete with OAuth. I suspect that this won=E2=80=99t impact the existing POP work for = server and native OAuth clients at all. This will allow us to do = something for implicit clients however. John B. > On Dec 11, 2014, at 5:07 AM, Bill Mills = wrote: >=20 > Nothing in the current OAuth work requires a static client key as far = as I know. No reason a key can't be issued per credential just like in = OAuth 1.0a or bound to a cred if the client provides a public key when = it authenticates. >=20 >=20 > On Wednesday, December 10, 2014 6:12 PM, Phillip Hallam-Baker = wrote: >=20 >=20 >=20 >=20 > On Wed, Dec 10, 2014 at 6:16 PM, John Bradley > wrote: > As I understand it this is proposing a change to browsers. Browsers = will need to be updated. There is a pre standard version of this in = Chrome now but even that would need to change. >=20 > I don=E2=80=99t think this WG is considering anything that would work = with a current browser. >=20 > That is why I don=E2=80=99t think it overlaps with current OAuth work = using static client keys. >=20 > OK, that does make a major difference. >=20 > But where does it fit in this: > =20 >> 1) Credential Issue >> This may or may not involve authentication of Alice, in the PKI = world we call it validation. >>=20 >> 2) Use of credential to initiate session >> Where I suspect this is to be situated, currently password = oriented. >>=20 >> 3) Session continuation >> Currently the weakest of the lot, the fact we use cookies as = bearer tokens in HTTPS makes eavy demands on the crypto protocol. >>=20 >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable = >=20 >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = >=20 >=20 --Apple-Mail=_D9FA8FB7-24F8-476A-A631-DB35AB9C80B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Bill,

Yes = in OAuth we can issue keys on a per token basis to the client.   = However these specs are about the browser, and we don=E2=80=99t = currently have any thing for browser clients other than being = public.

Currently we have no way to get a key into the browser that = can be used across connections.
Even with web = crypto we can only provision a key that works with a single origin as I = understand it.

These specs create a way for the browser to expose the public = key material that it uses for its end of mutual TLS connections, and = allow that to be communicated across related sessions.
Allowing it to be communicated between related sessions is = new to this proposal and a limitation of the original channel binding = and origin bound certificates.

If we called this something like = "Interface for exposing Origin bound public keys=E2=80=9D  then = people might be less worked up (though some are concerned about overlap = with HTTP bis and other things that are unrelated to tokens).   It = is the spec using the term token in the name that infers a larger = scope.

I am = not one of the proposers of this WG.   But I read the proposal as = something OAuth can use to fill a gap, like we use TLS, not something = that intends to compete with OAuth.

I suspect that this won=E2=80=99t = impact the existing POP work for server and native OAuth clients at all. =   This will allow us to do something for implicit clients = however.

John = B.

On = Dec 11, 2014, at 5:07 AM, Bill Mills <wmills_92105@yahoo.com> wrote:

Nothing in the = current OAuth work requires a static client key as far as I know. =  No reason a key can't be issued per credential just like in OAuth = 1.0a or bound to a cred if the client provides a public key when it = authenticates.


On Wednesday, December 10, 2014 6:12 PM, Phillip = Hallam-Baker <phill@hallambaker.com> wrote:
 =




On Wed, Dec 10, 2014 at 6:16 PM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
As I understand it this is proposing a change to = browsers.  Browsers will need to be updated.  There is a pre = standard version of this in Chrome now but even that would need to = change.

I don=E2=80=99= t think this WG is considering anything that would work with a current = browser.

That = is why I don=E2=80=99t think it overlaps with current OAuth work using = static client keys.

OK, that does make a major = difference.

But = where does it fit in this:
 
1) Credential = Issue
     This may or may not = involve authentication of Alice, in the PKI world we call it = validation.

2) Use of = credential to initiate session
     Where I suspect = this is to be situated, currently password oriented.

3) Session continuation
     Currently the = weakest of the lot, the fact we use cookies as bearer tokens in HTTPS = makes eavy demands on the crypto protocol.


_______________________________________________
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


=

= --Apple-Mail=_D9FA8FB7-24F8-476A-A631-DB35AB9C80B5-- --Apple-Mail=_4F76E9AD-0CDE-4151-A584-61F9AA99459B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEyMTEwNzQ3NDZaMCMGCSqGSIb3DQEJBDEWBBQ6kqTDC9BtDrsDGl2OX3y3 0NT2oDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBRN5mTQJDaQnTGXOZ8IqvuSQbCIBPRcLNu5YJo/0k58NLOlJrrDFbt erhOyy9FhJZADEeQQ630AX8Yfdwvf/XYzTMiUaVA5hm8ZrYeplfCMgJta/CS4UPvtLjtYv2rl0dZ qUlSgzhxEISkbb4Exa+o5RtZ9q7Sr14BXHotEqLd5G62+5kB1qO7XRjdAoMmvr4mjsgEu08AwSpd pkmrCXJaOF59JYLGljEHt17WsdPQ8kHId3wv9T+55tquRyVdCSv+r2+G78GlYf09v5yuvF4L7kKK VKiGQDgNfwboyfIzNHrO3aCDmKOIGsyKPaZAyCyOwW/QxIG41/JxJbjaGazWAAAAAAAA --Apple-Mail=_4F76E9AD-0CDE-4151-A584-61F9AA99459B-- From nobody Thu Dec 11 07:13:20 2014 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 E3F301ACEF5 for ; Thu, 11 Dec 2014 07:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.223 X-Spam-Level: *** X-Spam-Status: No, score=3.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] 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 5BTI2YTCPp_j for ; Thu, 11 Dec 2014 07:13:17 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504D61ACE97 for ; Thu, 11 Dec 2014 07:13:17 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id l4so4384401lbv.12 for ; Thu, 11 Dec 2014 07:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=dxNIJ/BqoOl1r+aDxL67BHFce7P4UR5u+ZQ6Bs16s44=; b=xCgp+fLWVlymVpoNuBAB0gWxWTHosUs2m6Cwu3fsTnE8DnWIIgJE+1d/BQaWhylwda VudP002UKu3zUULnV0IXGWHJ0x+6s5NMvfYcL7bipU5qvMp7XBrXiJCr9jZAq9yXW9Q0 XTloLb/wf4iwy9S/75uW1LS/DMdNefHvko6wdJb+DJbDEue9dBDZs8JyyN4ibPXI04Yn eWkyFX2Oe4HFhc+huS+iBqAlACCu4nXZu1sa5lS4Pu44QkyQ2NtXPGcBJ2h6RuSN0dQA 5yLzzAEi6yxUmwZh/Y7Dlef2j8EwlSyspcaF/Japxxy/qmDsxyH7KSt9hlucyXAIMXX6 8jyQ== MIME-Version: 1.0 X-Received: by 10.153.11.170 with SMTP id ej10mr10481929lad.24.1418310795600; Thu, 11 Dec 2014 07:13:15 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Thu, 11 Dec 2014 07:13:15 -0800 (PST) Date: Thu, 11 Dec 2014 10:13:15 -0500 X-Google-Sender-Auth: WBk_1EOA80-1k2eRFlaxdk0A4W0 Message-ID: From: Phillip Hallam-Baker To: unbearable Content-Type: multipart/alternative; boundary=001a11347914272b950509f23731 Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/eKAGwsUStPP3IBH_h_gZwduR_D4 Subject: [Unbearable] Proposal to reduce scope 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, 11 Dec 2014 15:13:20 -0000 --001a11347914272b950509f23731 Content-Type: text/plain; charset=UTF-8 I am usually the person who is arguing for the scope of a WG to be wider. In this case I think it would be best if we narrowed the scope of the WG so as to avoid conflict with other groups. Following Alan Kay's assertion that the Internet is the only large scale object oriented system functioning today, what I think important in a scope discussion is to try to define the interface to other parts of the system. As I see it, this problem should be scoped as being for two party interactions. That gives us a bright line between unbearable and SAML, OAUTH, etc. which are all designed to support multi party interactions. Another constraint is that we are only dealing with a single authentication factor and only for devices and we are requiring that the proof of possession presents an unfeasible work factor to an attacker looking to extract the credential. It seems to me that binding to the TLS channel should certainly be an option. But I don't think it should be a requirement because I don't think TLS should be a requirement. TLS is definitely desirable, but TLS is not necessarily end to end. There are many architectures in which TLS is deployed in a system that hide the tunnel parameters from the application. What people are proposing with TLS binding is a layer violation. It is an occasion where a layer violation is justified and useful but we are still committing a layer violation because that is an inevitable consequence of binding the application layer to the transport tunnel. That is OK, I agree that we should support that as useful. But we have to make it optional on the server side. The client side is a little different. Here architecture would demand that we make it an option too. But the point here is that the server wants to have a way to make certain of getting an end to end channel. I proposed the HTTP Session ID scheme some time ago and I find it simplifies the design of Web Services immensely. There are some important differences between my proposal and this one. I have also been thinking of the problem a little more generally since so the SessionID proposal is not necessarily the best one. One objective of Session-ID was to provide a drop in replacement for HTTP authentication cookies, 'hard cookies'. So the idea is that the client can tell the server it supports hard cookies. If the server returns a hard cookie to such a client, the client will present a proof of possession with future requests and never send a soft-cookie. So this is where I have been going since. A hard cookie consists of: * An opaque identifier * A set of algorithm parameters * A shared secret In a Web Service context it is most convenient to provide these in the discovery mechanism so I defined a JSON schema. And when the need for hard cookies was raised I translated the encoding into a HTTP header: Set-Session: Id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4 oB29dgs/ei6ieINZtmvXNCm2NUkWA== Key=7eb219188339135ba51e8715f3900bfb974995e145d6e490e4addbbdb26f4bb4 Alg=HMAC-SHA256 Start=True Request=True Time=True Now=745531 Domain=example.com Max-Age=31536000 It now occurs to me that the most convenient form for exchanging this type of credential would be as a URI: XXXSession:TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvij8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4oB29dgs_ei6ieINZtmvXNCm2NUkWA: HMAC-SHA256:7eb219188339135ba51e8715f3900bfb974995e145d6e490e4addbbdb26f4bb4 The advantage of the URI form is that it can be edited into configuration files and the like to establish the secret out of band. Now that isn't a path we should probably go down right now. But it would be a very powerful technique. And it needn't be limited to symmetric key. --001a11347914272b950509f23731 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am usually the person who is arguing for the scope of a = WG to be wider. In this case I think it would be best if we narrowed the sc= ope of the WG so as to avoid conflict with other groups.

Following Alan Kay's assertion that the Internet is the only large sca= le object oriented system functioning today, what I think important in a sc= ope discussion is to try to define the interface to other parts of the syst= em.


As I see it, this problem shoul= d be scoped as being for two party interactions. That gives us a bright lin= e between unbearable and SAML, OAUTH, etc. which are all designed to suppor= t multi party interactions.

Another constraint is = that we are only dealing with a single authentication factor and only for d= evices and we are requiring that the proof of possession presents an unfeas= ible work factor to an attacker looking to extract the credential.


It seems to me that binding to the TLS chan= nel should certainly be an option. But I don't think it should be a req= uirement because I don't think TLS should be a requirement.
<= br>
TLS is definitely desirable, but TLS is not necessarily end t= o end. There are many architectures in which TLS is deployed in a system th= at hide the tunnel parameters from the application.

What people are proposing with TLS binding is a layer violation. It is an= occasion where a layer violation is justified and useful but we are still = committing a layer violation because that is an inevitable consequence of b= inding the application layer to the transport tunnel.=C2=A0

<= /div>
That is OK, I agree that we should support that as useful. But we= have to make it optional on the server side.

The = client side is a little different. Here architecture would demand that we m= ake it an option too. But the point here is that the server wants to have a= way to make certain of getting an end to end channel.

=

I proposed the HTTP Session ID scheme some time ago and= I find it simplifies the design of Web Services immensely. There are some = important differences between my proposal and this one. I have also been th= inking of the problem a little more generally since so the SessionID propos= al is not necessarily the best one.


One objective of Session-ID was to provide a drop in replacement for HTTP = authentication cookies, 'hard cookies'. So the idea is that the cli= ent can tell the server it supports hard cookies. If the server returns a h= ard cookie to such a client, the client will present a proof of possession = with future requests and never send a soft-cookie.

So this is where I have been going since.

A hard = cookie consists of:

* An opaque identifier
* A set of algorithm parameters
* A shared secret
In a Web Service context it is most convenient to provide thes= e in the discovery mechanism so I defined a JSON schema. And when the need = for hard cookies was raised I translated the encoding into a HTTP header:

Set-Session:
    Id=3DTUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
      j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
      oB29dgs/ei6ieINZtmvXNCm2NUkWA=3D=3D
    Key=3D7eb219188339135ba51e8715f3900bfb974995e145d6e490e4addbbdb26f4bb4
    Alg=3DHMAC-SHA256 Start=3DTrue Request=3DTrue Time=3DTrue Now=3D745531
    Domain=3Dexample.com Max-Age=3D31536=
000

It now occurs to me that the most conven= ient form for exchanging this type of credential would be as a URI:

XXXSession:TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYm= CHfHAJcJlyvij8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4= oB29dgs_ei6ieINZtmvXNCm2NUkWA:HMAC-SHA256:7eb219188339135ba51e8715f3900bfb974995e145d6e490e4addbbdb26f4bb4

The advantage of the URI form is that it can = be edited into configuration files and the like to establish the secret out= of band.


Now that isn't a path= we should probably go down right now. But it would be a very powerful tech= nique. And it needn't be limited to symmetric key.

=


--001a11347914272b950509f23731-- From nobody Thu Dec 11 08:49:51 2014 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 5B4FA1A710D for ; Thu, 11 Dec 2014 08:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 OSd-E9i5XCtq for ; Thu, 11 Dec 2014 08:49:48 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8DB1A70FF for ; Thu, 11 Dec 2014 08:49:47 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBBGnc5R015972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Dec 2014 16:49:39 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBBGnYRA025647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Dec 2014 16:49:34 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBBGnY2V027092; Thu, 11 Dec 2014 16:49:34 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Dec 2014 08:49:33 -0800 References: <775296481.8248427.1418274456817.JavaMail.yahoo@jws10607.mail.bf1.yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-75D1DE5C-D2B3-42CD-8C75-E84C0B72D221 Content-Transfer-Encoding: 7bit Message-Id: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> X-Mailer: iPhone Mail (12B435) From: Phil Hunt Date: Thu, 11 Dec 2014 08:49:32 -0800 To: John Bradley X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/JIz_OLoP_2i4BlZtNO6rPGPo3TE Cc: "unbearable@ietf.org" , Andrei Popov , Phillip Hallam-Baker , Bill Mills , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 16:49:50 -0000 --Apple-Mail-75D1DE5C-D2B3-42CD-8C75-E84C0B72D221 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think my concern is that the announcement sounds too duplicative of the PO= P work.=20 The charter wording is going to be critical.=20 I am not clear yet that this work is browser only.=20 Phil > On Dec 10, 2014, at 23:47, John Bradley wrote: >=20 > Bill, >=20 > Yes in OAuth we can issue keys on a per token basis to the client. Howev= er these specs are about the browser, and we don=E2=80=99t currently have an= y thing for browser clients other than being public. >=20 > Currently we have no way to get a key into the browser that can be used ac= ross connections. > Even with web crypto we can only provision a key that works with a single o= rigin as I understand it. >=20 > These specs create a way for the browser to expose the public key material= that it uses for its end of mutual TLS connections, and allow that to be co= mmunicated across related sessions. > Allowing it to be communicated between related sessions is new to this pro= posal and a limitation of the original channel binding and origin bound cert= ificates. >=20 > If we called this something like "Interface for exposing Origin bound publ= ic keys=E2=80=9D then people might be less worked up (though some are conce= rned about overlap with HTTP bis and other things that are unrelated to toke= ns). It is the spec using the term token in the name that infers a larger s= cope. >=20 > I am not one of the proposers of this WG. But I read the proposal as som= ething OAuth can use to fill a gap, like we use TLS, not something that inte= nds to compete with OAuth. >=20 > I suspect that this won=E2=80=99t impact the existing POP work for server a= nd native OAuth clients at all. This will allow us to do something for imp= licit clients however. >=20 > John B. >=20 >> On Dec 11, 2014, at 5:07 AM, Bill Mills wrote: >>=20 >> Nothing in the current OAuth work requires a static client key as far as I= know. No reason a key can't be issued per credential just like in OAuth 1.= 0a or bound to a cred if the client provides a public key when it authentica= tes. >>=20 >>=20 >> On Wednesday, December 10, 2014 6:12 PM, Phillip Hallam-Baker wrote: >>=20 >>=20 >>=20 >>=20 >> On Wed, Dec 10, 2014 at 6:16 PM, John Bradley wrote: >> As I understand it this is proposing a change to browsers. Browsers will= need to be updated. There is a pre standard version of this in Chrome now b= ut even that would need to change. >>=20 >> I don=E2=80=99t think this WG is considering anything that would work wit= h a current browser. >>=20 >> That is why I don=E2=80=99t think it overlaps with current OAuth work usi= ng static client keys. >>=20 >> OK, that does make a major difference. >>=20 >> But where does it fit in this: >> =20 >>> 1) Credential Issue >>> This may or may not involve authentication of Alice, in the PKI wor= ld we call it validation. >>>=20 >>> 2) Use of credential to initiate session >>> Where I suspect this is to be situated, currently password oriented= . >>>=20 >>> 3) Session continuation >>> Currently the weakest of the lot, the fact we use cookies as bearer= tokens in HTTPS makes eavy demands on the crypto protocol. >>>=20 >>>=20 >>> _______________________________________________ >>> Unbearable mailing list >>> Unbearable@ietf.org >>> https://www.ietf.org/mailman/listinfo/unbearable >>=20 >>=20 >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail-75D1DE5C-D2B3-42CD-8C75-E84C0B72D221 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think my concern is that the announc= ement sounds too duplicative of the POP work. 

The charter wording is going to be critical. 

I am not clear yet that this work is browser only. 

Phil<= div>
On Dec 10, 2014, at 23:47, John Bradley <ve7jtb@ve7jtb.com> wrote:

Bill,

Yes in OAut= h we can issue keys on a per token basis to the client.   However these= specs are about the browser, and we don=E2=80=99t currently have any thing f= or browser clients other than being public.

Currently we have no way to get a key into the brow= ser that can be used across connections.
Even with web c= rypto we can only provision a key that works with a single origin as I under= stand it.

These sp= ecs create a way for the browser to expose the public key material that it u= ses for its end of mutual TLS connections, and allow that to be communicated= across related sessions.
Allowing it to be communicate= d between related sessions is new to this proposal and a limitation of the o= riginal channel binding and origin bound certificates.
=
If we called this something like "Inter= face for exposing Origin bound public keys=E2=80=9D  then people might b= e less worked up (though some are concerned about overlap with HTTP bis and o= ther things that are unrelated to tokens).   It is the spec using the t= erm token in the name that infers a larger scope.

I am not one of the proposers of this WG. &n= bsp; But I read the proposal as something OAuth can use to fill a gap, like w= e use TLS, not something that intends to compete with OAuth.

I suspect that this won=E2=80=99t= impact the existing POP work for server and native OAuth clients at all. &n= bsp; This will allow us to do something for implicit clients however.
<= div class=3D"">
John B.

On Dec 11, 2014, at 5:07 AM, Bill Mills <wmills_92105@yahoo.com> wr= ote:

Nothing in the current OAuth work requires a static client key as far as I= know.  No reason a key can't be issued per credential just like in OAu= th 1.0a or bound to a cred if the client provides a public key when it authe= nticates.


On Wednesday, December 10, 2014 6:12 PM, Phillip H= allam-Baker <phill@ha= llambaker.com> wrote:

<= br class=3D"">


On Wed,= Dec 10, 2014 at 6:16 PM, John Bradley <ve7jtb@ve7jtb.com> wrote= :
As I understand it this is proposing a chang= e to browsers.  Browsers will need to be updated.  There is a pre s= tandard version of this in Chrome now but even that would need to change.
I don=E2=80=99t think this= WG is considering anything that would work with a current browser.

That is why I don=E2=80=99= t think it overlaps with current OAuth work using static client keys.
<= /div>

OK, t= hat does make a major difference.

=
But where does it fit in this:
 
1) Credential= Issue
     This may or may not involve a= uthentication of Alice, in the PKI world we call it validation.

2) Use of credential to initiate session=
     Where I su= spect this is to be situated, currently password oriented.

3) Session continuation
     Currently the weakest of the lot, the fact we use c= ookies as bearer tokens in HTTPS makes eavy demands on the crypto protocol.<= /div>


_______________________________________________
Unbearable mai= ling list
Unbe= arable@ietf.org
https://www= .ietf.org/mailman/listinfo/unbearable



______________________________________________= _
Unbearable mailing list
Unbearabl= e@ietf.org
https://www.ietf.org/mailman/list= info/unbearable



=
____________________= ___________________________
Unbearable mailing listUnbearable@ietf.org
http= s://www.ietf.org/mailman/listinfo/unbearable
= --Apple-Mail-75D1DE5C-D2B3-42CD-8C75-E84C0B72D221-- From nobody Thu Dec 11 09:17:43 2014 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 A0ADB1A6ED8 for ; Thu, 11 Dec 2014 09:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OcASoGsbkeVX for ; Thu, 11 Dec 2014 09:17:38 -0800 (PST) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902D51A0141 for ; Thu, 11 Dec 2014 09:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1418318256; bh=EZ1YmDiP62sR0LodWZux8hKUK5BBVpNBUhne1mZ5kO4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=qrrethcPTFKkaOmmhBAMrqTxeeQCfA2iW8zMSNkgX76mE+PkPVNsOqwXWwdHpTNm2ICL3Sbre+6ddkzvN/fIQcstbxdOwPK1kjVa8CQMT5lBTt1VQxdIiypzgBAyhTzl5LDsJqFSncj8qoQHImMsU9sbOOi52YGzgNGEVapNn+mIs5BhLem3b+s+PvdlT1ASCpCEon6r6rMAHUnPfnad4gDmQy6Xa30VYeMO+aY5Lpe2TpfWZL7elvdM2i087h4Kd82xMVCmx5JDhdRmPD0VgIHdZVELMXk5oJVqomMkj46TdsoZms/jiEtZ1BZhCMJYiDBPEXML84jGWGto3TXpOw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=B0L/JPQkGOziI68jQ5JiTIBlP0oTMha5ww4U8eRUasLDWaApRXqgDIkiDeEB9RROCSWohtoA9FDzSOBxEzS4vQwZvkuZHrYrNA7AcvntnZR7ITTtT/fnbCuUKH1Q3qgJn57v75pnd4ncMQR4kuAch3tW0qdj/BCI0r4IhHGfSJCVIOyz0ZvSvpyyo3z97/95Df4pqp/GFmebohekTuLQ5+JlkAAyeIFeZHpz6UAy9tt9WRlxzp/UUNoJyrrYbdVOc6bBcnOqwWk6ioQwMQ+tBcDz9uciGeaRvUImayqCB47ZZ+g47r5xfTXe2BrEygw6NQQHXlGEfEBY15GnFOyTfQ==; Received: from [66.196.81.172] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 11 Dec 2014 17:17:36 -0000 Received: from [98.139.212.216] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 11 Dec 2014 17:17:36 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 11 Dec 2014 17:17:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 709385.42816.bm@omp1025.mail.bf1.yahoo.com X-YMail-OSG: 7N2K5FsVM1mp_3Akg6GBmJ4qIYypqzYUguYbuW4mIhFmwnULrVXsMvkas3iC0us NpmdmgPFwibYHSiUcCcBblmlqUEnazvqdV7QMxP1PO8ITBlM83V9_XCozC9yuCuvPmYywZ3eWQwO DNGbZgVigyZPPdlYzsDwXt9VBEONnrp6eUZgYtZRyhC6modpumaugzLXjdSOHMYdp4UZrJOr_MTP Mttz71BxKgZt1oyIj7LZmr5jXOL3aNx7QKdFmvUphAoGsNHZar47bbRJBnqIJWd.19madFNgk6AC iBaRGnz1.6W2aoe75yDQ4LeOn7XIhvXAViG_APBg.uGL.jBq.o6IFk_Ta6jfT1VMYbK6v7eloTmU rT9KPtFjeAjvpXAn6qMN0YUfD0ANzljc9iGlyoyKK6Q1MgumCDqoGXFYdshbztgG0X1ggSSB6.PE P8cgaQ448QfNhRhXMJZvFlh9PRP.gi1AoZofwS8KuJCCyHQ6fBeUgFdHSezhxAx.3kElnTwzASF6 YLP0VyKR_ Received: by 66.196.81.109; Thu, 11 Dec 2014 17:17:36 +0000 Date: Thu, 11 Dec 2014 17:17:35 +0000 (UTC) From: Bill Mills To: Phil Hunt , John Bradley Message-ID: <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> In-Reply-To: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8472899_647549795.1418318255557" Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/dVR8uyAe-iGUlVuMPCJJLU0pQzg Cc: "unbearable@ietf.org" , Phillip Hallam-Baker , Andrei Popov , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills 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, 11 Dec 2014 17:17:40 -0000 ------=_Part_8472899_647549795.1418318255557 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If this is about client certs stored and available to =C2=A0the browser to = use that's a different and interesting question. =C2=A0Is that really just = using the browser cert store as a key manager?=20 On Thursday, December 11, 2014 9:08 AM, Phil Hunt wrote: =20 I think my concern is that the announcement sounds too duplicative of the = POP work.=C2=A0 The charter wording is going to be critical.=C2=A0 I am not clear yet that this work is browser only.=C2=A0 Phil On Dec 10, 2014, at 23:47, John Bradley wrote: Bill, Yes in OAuth we can issue keys on a per token basis to the client. =C2=A0 H= owever these specs are about the browser, and we don=E2=80=99t currently ha= ve any thing for browser clients other than being public. Currently we have no way to get a key into the browser that can be used acr= oss connections.Even with web crypto we can only provision a key that works= with a single origin as I understand it. These specs create a way for the browser to expose the public key material = that it uses for its end of mutual TLS connections, and allow that to be co= mmunicated across related sessions.Allowing it to be communicated between r= elated sessions is new to this proposal and a limitation of the original ch= annel binding and origin bound certificates. If we called this something like "Interface for exposing Origin bound publi= c keys=E2=80=9D =C2=A0then people might be less worked up (though some are = concerned about overlap with HTTP bis and other things that are unrelated t= o tokens). =C2=A0 It is the spec using the term token in the name that infe= rs a larger scope. I am not one of the proposers of this WG. =C2=A0 But I read the proposal as= something OAuth can use to fill a gap, like we use TLS, not something that= intends to compete with OAuth. I suspect that this won=E2=80=99t impact the existing POP work for server a= nd native OAuth clients at all. =C2=A0 This will allow us to do something f= or implicit clients however. John B. On Dec 11, 2014, at 5:07 AM, Bill Mills wrote: Nothing in the current OAuth work requires a static client key as far as I = know. =C2=A0No reason a key can't be issued per credential just like in OAu= th 1.0a or bound to a cred if the client provides a public key when it auth= enticates.=20 On Wednesday, December 10, 2014 6:12 PM, Phillip Hallam-Baker wrote: =20 =20 On Wed, Dec 10, 2014 at 6:16 PM, John Bradley wrote: As I understand it this is proposing a change to browsers.=C2=A0 Browsers w= ill need to be updated.=C2=A0 There is a pre standard version of this in Ch= rome now but even that would need to change. I don=E2=80=99t think this WG is considering anything that would work with = a current browser. That is why I don=E2=80=99t think it overlaps with current OAuth work using= static client keys. OK, that does make a major difference. But where does it fit in this:=C2=A0 1) Credential Issue=C2=A0 =C2=A0 =C2=A0This may or may not involve authenti= cation of Alice, in the PKI world we call it validation. 2) Use of credential to initiate session=C2=A0 =C2=A0 =C2=A0Where I suspect= this is to be situated, currently password oriented. 3) Session continuation=C2=A0 =C2=A0 =C2=A0Currently the weakest of the lot= , the fact we use cookies as bearer tokens in HTTPS makes eavy demands on t= he crypto protocol. _______________________________________________ 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 =20 _______________________________________________ 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 ------=_Part_8472899_647549795.1418318255557 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If this is about client certs stored a= nd available to  the browser t= o use that's a different and interesting question.  Is that really jus= t using the browser cert store as a key manager?


On Thursday, December 11, 2014 9:08 AM, Phil Hunt <phil.hunt@oracle= .com> wrote:


I think my concern is that the announc= ement sounds too duplicative of the POP work. 

The charter wording is going to be critical. 

I am not clear yet that this work is brows= er only. 

Phil

On Dec 10, 2014, at 23:47, John Bradley <ve7jtb@ve7jtb.com> wrote:

Bill,

Yes in OAuth we can i= ssue keys on a per token basis to the client.   However these specs ar= e about the browser, and we don=E2=80=99t currently have any thing for brow= ser clients other than being public.

C= urrently we have no way to get a key into the browser that can be used acro= ss connections.
Even with web crypto we c= an only provision a key that works with a single origin as I understand it.=

These specs create a way for the brow= ser to expose the public key material that it uses for its end of mutual TL= S connections, and allow that to be communicated across related sessions.
Allowing it to be communicated between rel= ated sessions is new to this proposal and a limitation of the original chan= nel binding and origin bound certificates.

If we called this something like "Interface for exposing Origin bound = public keys=E2=80=9D  then people might be less worked up (though some= are concerned about overlap with HTTP bis and other things that are unrela= ted to tokens).   It is the spec using the term token in the name that= infers a larger scope.

I am not one o= f the proposers of this WG.   But I read the proposal as something OAu= th can use to fill a gap, like we use TLS, not something that intends to co= mpete with OAuth.

I suspect that this = won=E2=80=99t impact the existing POP work for server and native OAuth clie= nts at all.   This will allow us to do something for implicit clients = however.

John B.

On Dec 11, 2014, at 5:07 AM, Bill Mills <wmills_92105@yahoo.com> wrote:

Nothing in the current OAuth work requires a static client key as fa= r as I know.  No reason a key can't be issued per credential just like= in OAuth 1.0a or bound to a cred if the client provides a public key when = it authenticates.

=
On Wednesday, December 10, 2014 6:12 PM, Phillip Hallam-B= aker <phill@hallambaker.com> wrote:




On Wed, Dec 10, 2014 at 6:= 16 PM, John Bradley <ve7jtb@ve7j= tb.com> wrote:
As I understand it this is proposing a change to= browsers.  Browsers will need to be updated.  There is a pre sta= ndard version of this in Chrome now but even that would need to change.
<= div class=3D"yiv6219972997">I don=E2=80=99t think this WG is considering an= ything that would work with a current browser.

That is why I don=E2=80=99t think it overlaps with current OAuth w= ork using static client keys.

OK, that does make a major difference.

But where does it fit in this:
 
1) Credential = Issue
     This may or may= not involve authentication of Alice, in the PKI world we call it validatio= n.

2) Use of credential to initiate session
     Where I suspect this is t= o be situated, currently password oriented.

3) Session continuation
     Currently the weakest of the lo= t, the fact we use cookies as bearer tokens in HTTPS makes eavy demands on = the crypto protocol.


_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
<= a rel=3D"nofollow" shape=3D"rect" class=3D"yiv6219972997" target=3D"_blank"= href=3D"https://www.ietf.org/mailman/listinfo/unbearable">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
h= ttps://www.ietf.org/mailman/listinfo/unbearable


------=_Part_8472899_647549795.1418318255557-- From nobody Thu Dec 11 09:23:50 2014 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 6844C1A7D82 for ; Thu, 11 Dec 2014 09:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 iRs_Z1wGSKph for ; Thu, 11 Dec 2014 09:23:46 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 773421A6FCD for ; Thu, 11 Dec 2014 09:23:46 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 3751854077; Thu, 11 Dec 2014 09:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=B+vQG83jDhkHhR GZc6lIu1PsgJc=; b=AD7Wu8gATtLzFHN8iXniTyuDpc3YF2vJm5EhBcO9n/aYbG dwsu7zwwL85AN8+g+EhrOinZt4fYmgPCjUBMO3Uc7qXh0zZ2o2TlnnURD58ooz1O y+Pu1DjjVpUJmvaCowa6pFLkNjwPxsCHhnAzcrQjyDsbWwwq8yHVKgpXP7vT8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id DF08454073; Thu, 11 Dec 2014 09:23:45 -0800 (PST) Date: Thu, 11 Dec 2014 11:23:45 -0600 From: Nico Williams To: Phillip Hallam-Baker Message-ID: <20141211172340.GD3448@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/TuZDQZ3PhJIELYSzS3nvCwli8yE Cc: unbearable Subject: Re: [Unbearable] Proposal to reduce scope 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, 11 Dec 2014 17:23:47 -0000 On Thu, Dec 11, 2014 at 10:13:15AM -0500, Phillip Hallam-Baker wrote: > Another constraint is that we are only dealing with a single authentication > factor and only for devices and [...] Hmm, maybe. The one factor (the "token") might embody more than one in the protocol for obtaining it. > It seems to me that binding to the TLS channel should certainly be an > option. [...] Yes. > [...]. But I don't think it should be a requirement because I don't think > TLS should be a requirement. Maybe. The complexity of having two session crypto layers is quite painful. SASL has ended up dropping the "SL" part of SASL, leaving just "SA", precisely because of this. > TLS is definitely desirable, but TLS is not necessarily end to end. There > are many architectures in which TLS is deployed in a system that hide the > tunnel parameters from the application. But HTTP as-used is not end-to-end! This list is about HTTP/web... We could define "service" so broadly that it's effectively one end- point, even with load balancing, routing, and CDNs in the picture. Some deployments effectively do this. It's a fair question whether that's what we want to do as a *standard*. (I'm not sure. It depends on what the cost of linking related services in other ways might be.) > What people are proposing with TLS binding is a layer violation. It is an I disagree. Channel binding is all about this. Relying on an unbound channel's protection is a bigger layer violation. (In practice we do perform a binding based on the server's name, but it's weak and in some cases too asymmetrical, which is the reason for proposals like origin-bound cookies, for example.) > occasion where a layer violation is justified and useful but we are still > committing a layer violation because that is an inevitable consequence of > binding the application layer to the transport tunnel. Abstractions are leaky. Internet protocol layers are particularly leaky. I'm not justifying this. The key is that this only helps when the end-points match in some sense. See above comments about end-to-end. > That is OK, I agree that we should support that as useful. But we have to > make it optional on the server side. If the cost is HTTP-layer session crypto, then I think that is bound to fail. If the cost is application-layer session crypto, that might be more feasible (largely because JavaScript crypto is spreading, and if provided natively and if the tokens can key this... it should be tolerable, even workable), but even then you risk doing double the session crypto -- no one will want to! (I've made my peace with TLS. Can you tell?) > The client side is a little different. Here architecture would demand that > we make it an option too. But the point here is that the server wants to > have a way to make certain of getting an end to end channel. Well, no, typical website architecture doesn't have a single end-point, unless we define it broadly or otherwise link all those ends together. (Not linking them at all gets us into various web security problems.) > I proposed the HTTP Session ID scheme some time ago and I find it > [...] I did too. IIRC there were several proposals. You might recall that no one cared. Nico -- From nobody Thu Dec 11 10:54:02 2014 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 C9F041A88C3 for ; Thu, 11 Dec 2014 10:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Q7VEMUVc1Wxz for ; Thu, 11 Dec 2014 10:53:57 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFF11A8775 for ; Thu, 11 Dec 2014 10:53:57 -0800 (PST) Received: from BN3PR0301MB1249.namprd03.prod.outlook.com (25.161.207.25) by BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 18:53:34 +0000 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.31.17; Thu, 11 Dec 2014 18:53:32 +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.0031.000; Thu, 11 Dec 2014 18:53:32 +0000 From: Andrei Popov To: Bill Mills , Phil Hunt , John Bradley Thread-Topic: [Unbearable] one proposal for a charter - please dicsuss Thread-Index: AQHQEz13HUkUpVDAykapHgbkfe3625yGWqQAgAAcnYCAABBeAIACxW9ggAAn+4CAAAMvgIAAMSsAgAAw4wCAACy/gIAAl18AgAAH1oCAABfUQA== Date: Thu, 11 Dec 2014 18:53:32 +0000 Message-ID: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> In-Reply-To: <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1249;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(24454002)(377454003)(189002)(19580395003)(19580405001)(99286002)(77156002)(64706001)(2656002)(99396003)(20776003)(62966003)(4396001)(87936001)(122556002)(40100003)(107046002)(31966008)(76576001)(33656002)(106356001)(50986999)(54356999)(106116001)(105586002)(19300405004)(76176999)(15975445007)(86362001)(97736003)(21056001)(102836002)(92566001)(2521001)(16236675004)(120916001)(74316001)(46102003)(68736005)(551544002)(561944003)(101416001)(86612001)(19625215002)(19617315012)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1249; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1250E78929AAAC8D4D94F8398C630BN3PR0301MB1250_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/zqG1cqW7Uip79DLVjolRRpcM5kA Cc: "unbearable@ietf.org" , Phillip Hallam-Baker , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 18:54:01 -0000 --_000_BN3PR0301MB1250E78929AAAC8D4D94F8398C630BN3PR0301MB1250_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIElmIHRoaXMgaXMgYWJvdXQgY2xpZW50IGNlcnRzIHN0b3JlZCBhbmQgYXZhaWxhYmxlIHRv ICB0aGUgYnJvd3NlciB0byB1c2UgdGhhdCdzIGEgZGlmZmVyZW50IGFuZCBpbnRlcmVzdGluZyBx dWVzdGlvbi4NCkluIHRoZSBjdXJyZW50IHByb3Bvc2FscywgdGhlc2UgYXJlIG5vdCBmdWxsIGNs aWVudCBjZXJ0cywgYnV0IHB1YmxpYy1wcml2YXRlIGtleSBwYWlycy4NCg0KDQrDmCAgSXMgdGhh dCByZWFsbHkganVzdCB1c2luZyB0aGUgYnJvd3NlciBjZXJ0IHN0b3JlIGFzIGEga2V5IG1hbmFn ZXI/DQpUaGUgY3VycmVudCBJLURzIHByb3ZpZGUgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQg dG8gcHJvdmUgcG9zc2Vzc2lvbiBvZiBhIGNsaWVudC1nZW5lcmF0ZWQga2V5IHRoYXQgaXMgcHJv dGVjdGVkIGZyb20gZXhwb3J0LiBUaGlzIFRva2VuIEJpbmRpbmcga2V5IGNvdWxkIGJlIGhhcmR3 YXJlLWJvdW5kIG9yIHN0cm9uZ2x5IHByb3RlY3RlZCBpbiBhIGRpZmZlcmVudCBtYW5uZXIsIGRl cGVuZGluZyBvbiBzeXN0ZW0gY2FwYWJpbGl0aWVzLiBUaGUgc2VydmVyIGNhbiBiaW5kIHNlY3Vy aXR5IHRva2VucyB0byB0aGlzIGtleS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogQmls bCBNaWxscyBbbWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb21dDQpTZW50OiBUaHVyc2RheSwg RGVjZW1iZXIgMTEsIDIwMTQgOToxOCBBTQ0KVG86IFBoaWwgSHVudDsgSm9obiBCcmFkbGV5DQpD YzogdW5iZWFyYWJsZUBpZXRmLm9yZzsgQW5kcmVpIFBvcG92OyBQaGlsbGlwIEhhbGxhbS1CYWtl cjsgU3RlcGhlbiBGYXJyZWxsDQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIG9uZSBwcm9wb3Nh bCBmb3IgYSBjaGFydGVyIC0gcGxlYXNlIGRpY3N1c3MNCg0KSWYgdGhpcyBpcyBhYm91dCBjbGll bnQgY2VydHMgc3RvcmVkIGFuZCBhdmFpbGFibGUgdG8gIHRoZSBicm93c2VyIHRvIHVzZSB0aGF0 J3MgYSBkaWZmZXJlbnQgYW5kIGludGVyZXN0aW5nIHF1ZXN0aW9uLiAgSXMgdGhhdCByZWFsbHkg anVzdCB1c2luZyB0aGUgYnJvd3NlciBjZXJ0IHN0b3JlIGFzIGEga2V5IG1hbmFnZXI/DQoNCk9u IFRodXJzZGF5LCBEZWNlbWJlciAxMSwgMjAxNCA5OjA4IEFNLCBQaGlsIEh1bnQgPHBoaWwuaHVu dEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KDQpJIHRo aW5rIG15IGNvbmNlcm4gaXMgdGhhdCB0aGUgYW5ub3VuY2VtZW50IHNvdW5kcyB0b28gZHVwbGlj YXRpdmUgb2YgdGhlIFBPUCB3b3JrLg0KDQpUaGUgY2hhcnRlciB3b3JkaW5nIGlzIGdvaW5nIHRv IGJlIGNyaXRpY2FsLg0KDQpJIGFtIG5vdCBjbGVhciB5ZXQgdGhhdCB0aGlzIHdvcmsgaXMgYnJv d3NlciBvbmx5Lg0KDQpQaGlsDQoNCk9uIERlYyAxMCwgMjAxNCwgYXQgMjM6NDcsIEpvaG4gQnJh ZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6 DQpCaWxsLA0KDQpZZXMgaW4gT0F1dGggd2UgY2FuIGlzc3VlIGtleXMgb24gYSBwZXIgdG9rZW4g YmFzaXMgdG8gdGhlIGNsaWVudC4gICBIb3dldmVyIHRoZXNlIHNwZWNzIGFyZSBhYm91dCB0aGUg YnJvd3NlciwgYW5kIHdlIGRvbuKAmXQgY3VycmVudGx5IGhhdmUgYW55IHRoaW5nIGZvciBicm93 c2VyIGNsaWVudHMgb3RoZXIgdGhhbiBiZWluZyBwdWJsaWMuDQoNCkN1cnJlbnRseSB3ZSBoYXZl IG5vIHdheSB0byBnZXQgYSBrZXkgaW50byB0aGUgYnJvd3NlciB0aGF0IGNhbiBiZSB1c2VkIGFj cm9zcyBjb25uZWN0aW9ucy4NCkV2ZW4gd2l0aCB3ZWIgY3J5cHRvIHdlIGNhbiBvbmx5IHByb3Zp c2lvbiBhIGtleSB0aGF0IHdvcmtzIHdpdGggYSBzaW5nbGUgb3JpZ2luIGFzIEkgdW5kZXJzdGFu ZCBpdC4NCg0KVGhlc2Ugc3BlY3MgY3JlYXRlIGEgd2F5IGZvciB0aGUgYnJvd3NlciB0byBleHBv c2UgdGhlIHB1YmxpYyBrZXkgbWF0ZXJpYWwgdGhhdCBpdCB1c2VzIGZvciBpdHMgZW5kIG9mIG11 dHVhbCBUTFMgY29ubmVjdGlvbnMsIGFuZCBhbGxvdyB0aGF0IHRvIGJlIGNvbW11bmljYXRlZCBh Y3Jvc3MgcmVsYXRlZCBzZXNzaW9ucy4NCkFsbG93aW5nIGl0IHRvIGJlIGNvbW11bmljYXRlZCBi ZXR3ZWVuIHJlbGF0ZWQgc2Vzc2lvbnMgaXMgbmV3IHRvIHRoaXMgcHJvcG9zYWwgYW5kIGEgbGlt aXRhdGlvbiBvZiB0aGUgb3JpZ2luYWwgY2hhbm5lbCBiaW5kaW5nIGFuZCBvcmlnaW4gYm91bmQg Y2VydGlmaWNhdGVzLg0KDQpJZiB3ZSBjYWxsZWQgdGhpcyBzb21ldGhpbmcgbGlrZSAiSW50ZXJm YWNlIGZvciBleHBvc2luZyBPcmlnaW4gYm91bmQgcHVibGljIGtleXPigJ0gIHRoZW4gcGVvcGxl IG1pZ2h0IGJlIGxlc3Mgd29ya2VkIHVwICh0aG91Z2ggc29tZSBhcmUgY29uY2VybmVkIGFib3V0 IG92ZXJsYXAgd2l0aCBIVFRQIGJpcyBhbmQgb3RoZXIgdGhpbmdzIHRoYXQgYXJlIHVucmVsYXRl ZCB0byB0b2tlbnMpLiAgIEl0IGlzIHRoZSBzcGVjIHVzaW5nIHRoZSB0ZXJtIHRva2VuIGluIHRo ZSBuYW1lIHRoYXQgaW5mZXJzIGEgbGFyZ2VyIHNjb3BlLg0KDQpJIGFtIG5vdCBvbmUgb2YgdGhl IHByb3Bvc2VycyBvZiB0aGlzIFdHLiAgIEJ1dCBJIHJlYWQgdGhlIHByb3Bvc2FsIGFzIHNvbWV0 aGluZyBPQXV0aCBjYW4gdXNlIHRvIGZpbGwgYSBnYXAsIGxpa2Ugd2UgdXNlIFRMUywgbm90IHNv bWV0aGluZyB0aGF0IGludGVuZHMgdG8gY29tcGV0ZSB3aXRoIE9BdXRoLg0KDQpJIHN1c3BlY3Qg dGhhdCB0aGlzIHdvbuKAmXQgaW1wYWN0IHRoZSBleGlzdGluZyBQT1Agd29yayBmb3Igc2VydmVy IGFuZCBuYXRpdmUgT0F1dGggY2xpZW50cyBhdCBhbGwuICAgVGhpcyB3aWxsIGFsbG93IHVzIHRv IGRvIHNvbWV0aGluZyBmb3IgaW1wbGljaXQgY2xpZW50cyBob3dldmVyLg0KDQpKb2huIEIuDQoN Ck9uIERlYyAxMSwgMjAxNCwgYXQgNTowNyBBTSwgQmlsbCBNaWxscyA8d21pbGxzXzkyMTA1QHlh aG9vLmNvbTxtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4+IHdyb3RlOg0KDQpOb3RoaW5n IGluIHRoZSBjdXJyZW50IE9BdXRoIHdvcmsgcmVxdWlyZXMgYSBzdGF0aWMgY2xpZW50IGtleSBh cyBmYXIgYXMgSSBrbm93LiAgTm8gcmVhc29uIGEga2V5IGNhbid0IGJlIGlzc3VlZCBwZXIgY3Jl ZGVudGlhbCBqdXN0IGxpa2UgaW4gT0F1dGggMS4wYSBvciBib3VuZCB0byBhIGNyZWQgaWYgdGhl IGNsaWVudCBwcm92aWRlcyBhIHB1YmxpYyBrZXkgd2hlbiBpdCBhdXRoZW50aWNhdGVzLg0KDQpP biBXZWRuZXNkYXksIERlY2VtYmVyIDEwLCAyMDE0IDY6MTIgUE0sIFBoaWxsaXAgSGFsbGFtLUJh a2VyIDxwaGlsbEBoYWxsYW1iYWtlci5jb208bWFpbHRvOnBoaWxsQGhhbGxhbWJha2VyLmNvbT4+ IHdyb3RlOg0KDQoNCg0KT24gV2VkLCBEZWMgMTAsIDIwMTQgYXQgNjoxNiBQTSwgSm9obiBCcmFk bGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToN CkFzIEkgdW5kZXJzdGFuZCBpdCB0aGlzIGlzIHByb3Bvc2luZyBhIGNoYW5nZSB0byBicm93c2Vy cy4gIEJyb3dzZXJzIHdpbGwgbmVlZCB0byBiZSB1cGRhdGVkLiAgVGhlcmUgaXMgYSBwcmUgc3Rh bmRhcmQgdmVyc2lvbiBvZiB0aGlzIGluIENocm9tZSBub3cgYnV0IGV2ZW4gdGhhdCB3b3VsZCBu ZWVkIHRvIGNoYW5nZS4NCg0KSSBkb27igJl0IHRoaW5rIHRoaXMgV0cgaXMgY29uc2lkZXJpbmcg YW55dGhpbmcgdGhhdCB3b3VsZCB3b3JrIHdpdGggYSBjdXJyZW50IGJyb3dzZXIuDQoNClRoYXQg aXMgd2h5IEkgZG9u4oCZdCB0aGluayBpdCBvdmVybGFwcyB3aXRoIGN1cnJlbnQgT0F1dGggd29y ayB1c2luZyBzdGF0aWMgY2xpZW50IGtleXMuDQoNCk9LLCB0aGF0IGRvZXMgbWFrZSBhIG1ham9y IGRpZmZlcmVuY2UuDQoNCkJ1dCB3aGVyZSBkb2VzIGl0IGZpdCBpbiB0aGlzOg0KDQoxKSBDcmVk ZW50aWFsIElzc3VlDQogICAgIFRoaXMgbWF5IG9yIG1heSBub3QgaW52b2x2ZSBhdXRoZW50aWNh dGlvbiBvZiBBbGljZSwgaW4gdGhlIFBLSSB3b3JsZCB3ZSBjYWxsIGl0IHZhbGlkYXRpb24uDQoN CjIpIFVzZSBvZiBjcmVkZW50aWFsIHRvIGluaXRpYXRlIHNlc3Npb24NCiAgICAgV2hlcmUgSSBz dXNwZWN0IHRoaXMgaXMgdG8gYmUgc2l0dWF0ZWQsIGN1cnJlbnRseSBwYXNzd29yZCBvcmllbnRl ZC4NCg0KMykgU2Vzc2lvbiBjb250aW51YXRpb24NCiAgICAgQ3VycmVudGx5IHRoZSB3ZWFrZXN0 IG9mIHRoZSBsb3QsIHRoZSBmYWN0IHdlIHVzZSBjb29raWVzIGFzIGJlYXJlciB0b2tlbnMgaW4g SFRUUFMgbWFrZXMgZWF2eSBkZW1hbmRzIG9uIHRoZSBjcnlwdG8gcHJvdG9jb2wuDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUg bWFpbGluZyBsaXN0DQpVbmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQoN Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpV bmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFy YWJsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5i ZWFyYWJsZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86 VW5iZWFyYWJsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdW5iZWFyYWJsZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFp bHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3VuYmVhcmFibGUNCg0K --_000_BN3PR0301MB1250E78929AAAC8D4D94F8398C630BN3PR0301MB1250_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLnlpdjYyMTk5NzI5OTcNCgl7 bXNvLXN0eWxlLW5hbWU6eWl2NjIxOTk3Mjk5Nzt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQ4Mzc4OTM3Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTMxOTI5MjgwIDE1OTY5OTUzOTggNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SWYgdGhpcyBpcyBhYm91dCBjbGll bnQgY2VydHMgc3RvcmVkIGFuZCBhdmFpbGFibGUgdG8gJm5ic3A7dGhlIGJyb3dzZXIgdG8gdXNl IHRoYXQncyBhIGRpZmZlcmVudCBhbmQgaW50ZXJlc3RpbmcgcXVlc3Rpb24uPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4gdGhlIGN1cnJl bnQgcHJvcG9zYWxzLCB0aGVzZSBhcmUgbm90IGZ1bGwgY2xpZW50IGNlcnRzLCBidXQgcHVibGlj LXByaXZhdGUga2V5IHBhaXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JcyB0aGF0IHJl YWxseSBqdXN0IHVzaW5nIHRoZSBicm93c2VyIGNlcnQgc3RvcmUgYXMgYSBrZXkgbWFuYWdlcj88 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U aGUgY3VycmVudCBJLURzIHByb3ZpZGUgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQgdG8gcHJv dmUgcG9zc2Vzc2lvbiBvZiBhIGNsaWVudC1nZW5lcmF0ZWQga2V5IHRoYXQgaXMgcHJvdGVjdGVk IGZyb20gZXhwb3J0LiBUaGlzIFRva2VuIEJpbmRpbmcga2V5IGNvdWxkDQogYmUgaGFyZHdhcmUt Ym91bmQgb3Igc3Ryb25nbHkgcHJvdGVjdGVkIGluIGEgZGlmZmVyZW50IG1hbm5lciwgZGVwZW5k aW5nIG9uIHN5c3RlbSBjYXBhYmlsaXRpZXMuIFRoZSBzZXJ2ZXIgY2FuIGJpbmQgc2VjdXJpdHkg dG9rZW5zIHRvIHRoaXMga2V5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCaWxsIE1p bGxzIFttYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgRGVjZW1iZXIgMTEsIDIwMTQgOToxOCBBTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBI dW50OyBKb2huIEJyYWRsZXk8YnI+DQo8Yj5DYzo8L2I+IHVuYmVhcmFibGVAaWV0Zi5vcmc7IEFu ZHJlaSBQb3BvdjsgUGhpbGxpcCBIYWxsYW0tQmFrZXI7IFN0ZXBoZW4gRmFycmVsbDxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIG9uZSBwcm9wb3NhbCBmb3IgYSBjaGFydGVy IC0gcGxlYXNlIGRpY3N1c3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5JZiB0aGlzIGlzIGFib3V0IGNsaWVudCBjZXJ0cyBzdG9yZWQg YW5kIGF2YWlsYWJsZSB0byAmbmJzcDt0aGUgYnJvd3NlciB0byB1c2UgdGhhdCdzIGEgZGlmZmVy ZW50IGFuZCBpbnRlcmVzdGluZyBxdWVzdGlvbi4gJm5ic3A7SXMgdGhhdCByZWFsbHkNCiBqdXN0 IHVzaW5nIHRoZSBicm93c2VyIGNlcnQgc3RvcmUgYXMgYSBrZXkgbWFuYWdlcj88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk9uIFRodXJzZGF5LCBEZWNlbWJl ciAxMSwgMjAxNCA5OjA4IEFNLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGlk PSJ5aXY2MjE5OTcyOTk3Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSB0aGluayBteSBjb25jZXJuIGlz IHRoYXQgdGhlIGFubm91bmNlbWVudCBzb3VuZHMgdG9vIGR1cGxpY2F0aXZlIG9mIHRoZSBQT1Ag d29yay4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgY2hhcnRlciB3 b3JkaW5nIGlzIGdvaW5nIHRvIGJlIGNyaXRpY2FsLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPkkgYW0gbm90IGNsZWFyIHlldCB0aGF0IHRoaXMgd29yayBpcyBicm93c2Vy IG9ubHkuJm5ic3A7PGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxicj4NCk9uIERlYyAxMCwgMjAxNCwg YXQgMjM6NDcsIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIu Y29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkJpbGwsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPlllcyBpbiBPQXV0aCB3ZSBjYW4gaXNzdWUga2V5cyBvbiBhIHBl ciB0b2tlbiBiYXNpcyB0byB0aGUgY2xpZW50LiAmbmJzcDsgSG93ZXZlciB0aGVzZSBzcGVjcyBh cmUgYWJvdXQgdGhlIGJyb3dzZXIsIGFuZCB3ZSBkb27igJl0IGN1cnJlbnRseSBoYXZlIGFueSB0 aGluZw0KIGZvciBicm93c2VyIGNsaWVudHMgb3RoZXIgdGhhbiBiZWluZyBwdWJsaWMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q3VycmVudGx5IHdlIGhhdmUgbm8gd2F5IHRvIGdl dCBhIGtleSBpbnRvIHRoZSBicm93c2VyIHRoYXQgY2FuIGJlIHVzZWQgYWNyb3NzIGNvbm5lY3Rp b25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkV2ZW4gd2l0aCB3 ZWIgY3J5cHRvIHdlIGNhbiBvbmx5IHByb3Zpc2lvbiBhIGtleSB0aGF0IHdvcmtzIHdpdGggYSBz aW5nbGUgb3JpZ2luIGFzIEkgdW5kZXJzdGFuZCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5UaGVzZSBzcGVjcyBjcmVhdGUgYSB3YXkgZm9yIHRoZSBicm93c2VyIHRvIGV4cG9z ZSB0aGUgcHVibGljIGtleSBtYXRlcmlhbCB0aGF0IGl0IHVzZXMgZm9yIGl0cyBlbmQgb2YgbXV0 dWFsIFRMUyBjb25uZWN0aW9ucywgYW5kIGFsbG93IHRoYXQgdG8gYmUgY29tbXVuaWNhdGVkDQog YWNyb3NzIHJlbGF0ZWQgc2Vzc2lvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+QWxsb3dpbmcgaXQgdG8gYmUgY29tbXVuaWNhdGVkIGJldHdlZW4gcmVsYXRlZCBz ZXNzaW9ucyBpcyBuZXcgdG8gdGhpcyBwcm9wb3NhbCBhbmQgYSBsaW1pdGF0aW9uIG9mIHRoZSBv cmlnaW5hbCBjaGFubmVsIGJpbmRpbmcgYW5kIG9yaWdpbiBib3VuZCBjZXJ0aWZpY2F0ZXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SWYgd2UgY2FsbGVkIHRoaXMgc29tZXRoaW5n IGxpa2UgJnF1b3Q7SW50ZXJmYWNlIGZvciBleHBvc2luZyBPcmlnaW4gYm91bmQgcHVibGljIGtl eXPigJ0gJm5ic3A7dGhlbiBwZW9wbGUgbWlnaHQgYmUgbGVzcyB3b3JrZWQgdXAgKHRob3VnaCBz b21lIGFyZSBjb25jZXJuZWQgYWJvdXQNCiBvdmVybGFwIHdpdGggSFRUUCBiaXMgYW5kIG90aGVy IHRoaW5ncyB0aGF0IGFyZSB1bnJlbGF0ZWQgdG8gdG9rZW5zKS4gJm5ic3A7IEl0IGlzIHRoZSBz cGVjIHVzaW5nIHRoZSB0ZXJtIHRva2VuIGluIHRoZSBuYW1lIHRoYXQgaW5mZXJzIGEgbGFyZ2Vy IHNjb3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgYW0gbm90IG9uZSBvZiB0 aGUgcHJvcG9zZXJzIG9mIHRoaXMgV0cuICZuYnNwOyBCdXQgSSByZWFkIHRoZSBwcm9wb3NhbCBh cyBzb21ldGhpbmcgT0F1dGggY2FuIHVzZSB0byBmaWxsIGEgZ2FwLCBsaWtlIHdlIHVzZSBUTFMs IG5vdCBzb21ldGhpbmcgdGhhdCBpbnRlbmRzDQogdG8gY29tcGV0ZSB3aXRoIE9BdXRoLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgc3VzcGVjdCB0aGF0IHRoaXMgd29u4oCZdCBp bXBhY3QgdGhlIGV4aXN0aW5nIFBPUCB3b3JrIGZvciBzZXJ2ZXIgYW5kIG5hdGl2ZSBPQXV0aCBj bGllbnRzIGF0IGFsbC4gJm5ic3A7IFRoaXMgd2lsbCBhbGxvdyB1cyB0byBkbyBzb21ldGhpbmcg Zm9yIGltcGxpY2l0IGNsaWVudHMNCiBob3dldmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPkpvaG4gQi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+T24gRGVjIDExLCAyMDE0LCBhdCA1OjA3IEFNLCBCaWxsIE1pbGxzICZsdDs8YSBocmVm PSJtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndtaWxsc185 MjEwNUB5YWhvby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXYgaWQ9InlpdjYyMTk5NzI5OTd5dWlfM18xNl8wXzFfMTQxODE1Njg3NzMwNl82MDc5MDMi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNs YXNzPSJ5aXY2MjE5OTcyOTk3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Ob3RoaW5n IGluIHRoZSBjdXJyZW50IE9BdXRoIHdvcmsgcmVxdWlyZXMgYSBzdGF0aWMgY2xpZW50IGtleSBh cyBmYXIgYXMgSSBrbm93LiAmbmJzcDtObyByZWFzb24gYSBrZXkgY2FuJ3QgYmUNCiBpc3N1ZWQg cGVyIGNyZWRlbnRpYWwganVzdCBsaWtlIGluIE9BdXRoIDEuMGEgb3IgYm91bmQgdG8gYSBjcmVk IGlmIHRoZSBjbGllbnQgcHJvdmlkZXMgYSBwdWJsaWMga2V5IHdoZW4gaXQgYXV0aGVudGljYXRl cy48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+T24gV2VkbmVzZGF5LCBEZWNlbWJl ciAxMCwgMjAxNCA2OjEyIFBNLCBQaGlsbGlwIEhhbGxhbS1CYWtlciAmbHQ7PGEgaHJlZj0ibWFp bHRvOnBoaWxsQGhhbGxhbWJha2VyLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWxsQGhhbGxhbWJh a2VyLmNvbTwvYT4mZ3Q7DQogd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBpZD0ieWl2NjIxOTk3Mjk5NyI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PbiBXZWQsIERlYyAxMCwgMjAxNCBhdCA2OjE2IFBN LCBKb2huIEJyYWRsZXkNCjxzcGFuIGNsYXNzPSJ5aXY2MjE5OTcyOTk3Ij4mbHQ7PGEgaHJlZj0i bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5j b208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5BcyBJIHVuZGVyc3RhbmQgaXQgdGhpcyBpcyBwcm9wb3NpbmcgYSBjaGFu Z2UgdG8gYnJvd3NlcnMuJm5ic3A7IEJyb3dzZXJzIHdpbGwgbmVlZCB0byBiZSB1cGRhdGVkLiZu YnNwOyBUaGVyZSBpcyBhIHByZSBzdGFuZGFyZCB2ZXJzaW9uIG9mIHRoaXMgaW4gQ2hyb21lIG5v dyBidXQNCiBldmVuIHRoYXQgd291bGQgbmVlZCB0byBjaGFuZ2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPkkgZG9u4oCZdCB0aGluayB0aGlzIFdHIGlzIGNvbnNpZGVyaW5nIGFueXRoaW5nIHRo YXQgd291bGQgd29yayB3aXRoIGEgY3VycmVudCBicm93c2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPlRoYXQgaXMgd2h5IEkgZG9u4oCZdCB0aGluayBpdCBvdmVybGFwcyB3aXRo IGN1cnJlbnQgT0F1dGggd29yayB1c2luZyBzdGF0aWMgY2xpZW50IGtleXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PSywgdGhhdCBkb2Vz IG1ha2UgYSBtYWpvciBkaWZmZXJlbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkJ1dCB3aGVyZSBkb2VzIGl0IGZpdCBpbiB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjEpIENyZWRlbnRpYWwgSXNzdWU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwO1RoaXMg bWF5IG9yIG1heSBub3QgaW52b2x2ZSBhdXRoZW50aWNhdGlvbiBvZiBBbGljZSwgaW4gdGhlIFBL SSB3b3JsZCB3ZSBjYWxsIGl0IHZhbGlkYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjIpIFVzZSBvZiBjcmVkZW50aWFsIHRvIGluaXRpYXRlIHNlc3Npb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwO1doZXJl IEkgc3VzcGVjdCB0aGlzIGlzIHRvIGJlIHNpdHVhdGVkLCBjdXJyZW50bHkgcGFzc3dvcmQgb3Jp ZW50ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+MykgU2Vzc2lvbiBjb250aW51 YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5i c3A7ICZuYnNwO0N1cnJlbnRseSB0aGUgd2Vha2VzdCBvZiB0aGUgbG90LCB0aGUgZmFjdCB3ZSB1 c2UgY29va2llcyBhcyBiZWFyZXIgdG9rZW5zIGluIEhUVFBTIG1ha2VzIGVhdnkgZGVtYW5kcyBv biB0aGUgY3J5cHRvIHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNs YXNzPSJ5aXY2MjE5OTcyOTk3Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxicj4N CjxzcGFuIGNsYXNzPSJ5aXY2MjE5OTcyOTk3Ij5VbmJlYXJhYmxlIG1haWxpbmcgbGlzdDwvc3Bh bj48YnI+DQo8c3BhbiBjbGFzcz0ieWl2NjIxOTk3Mjk5NyI+PGEgaHJlZj0ibWFpbHRvOlVuYmVh cmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjwv c3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0ieWl2NjIxOTk3Mjk5NyI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjwvc3Bh bj48L3NwYW4+PHNwYW4gY2xhc3M9InlpdjYyMTk5NzI5OTciPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgaWQ9InlpdjYyMTk5NzI5OTd5cXRmZDkxNzY5Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgaWQ9InlpdjYyMTk5NzI5OTd5 cXRmZDIzMzgxIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBpZD0ieWl2NjIxOTk3Mjk5 N3lxdGZkODYxODAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGlkPSJ5aXY2MjE5OTcyOTk3eXF0ZmQwMDIxOCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5VbmJl YXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5 aXY2MjE5OTcyOTk3eXF0ZmQ1MzA2MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ieWl2NjIxOTk3Mjk5N3lxdGZkNDQ2NDIiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJh YmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFi bGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3VuYmVhcmFibGU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IGlkPSJ5cXRmZDkwNjU4Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyI+VW5iZWFyYWJsZUBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vu YmVhcmFibGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3VuYmVhcmFibGU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_BN3PR0301MB1250E78929AAAC8D4D94F8398C630BN3PR0301MB1250_-- From nobody Thu Dec 11 11:05:40 2014 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 2ABE01A87E4 for ; Thu, 11 Dec 2014 11:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 hXFA6St93yFw for ; Thu, 11 Dec 2014 11:05:37 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581371ACF7E for ; Thu, 11 Dec 2014 11:05:37 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id hs14so4904756lab.11 for ; Thu, 11 Dec 2014 11:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7Y9zz8H7Yas2m30W11xBo0EQKvGQ8WCVDFgSN/IOulo=; b=sB2kytq6/JQriTngonl5AeE8j3lPWGq8G1mgG2gHxJUUcKuCWZkdHBIrU+pQc5MchJ HPez1GwKX1vZ5gyIZA+wcIbnKNnUo6zLqg2loi9vTSSCSpbokmjovRm7myM9bGgWgjhW DgFBTvgaQbYB+DNWDTmft8YgQ9NWZFqhJJ2Rsmu4eBi6SekJxgeuz8+/XhFl8cqwfbLy Id/YRN/l6qBrYnCWa7QvEgqGsAXtbT/UpajtprjpuVnwqtgDZLIk8QRxUgKO3znDOdSX 0kWoh/t1g3YA8AJ9shsh95U55nMYwewdLjF/Vmw4GDbIGGYs7JvmZFq1j3WEUwaMgCpN 1rBg== MIME-Version: 1.0 X-Received: by 10.112.131.1 with SMTP id oi1mr4209611lbb.2.1418324735746; Thu, 11 Dec 2014 11:05:35 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Thu, 11 Dec 2014 11:05:35 -0800 (PST) In-Reply-To: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> Date: Thu, 11 Dec 2014 14:05:35 -0500 X-Google-Sender-Auth: S3ZdHtUSbCbGQ7d-uFKDiMYlxgQ Message-ID: From: Phillip Hallam-Baker To: Andrei Popov Content-Type: multipart/alternative; boundary=047d7b3431060ce82b0509f57639 Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/DImTT163q10aK7WAnE2D77wZbK8 Cc: John Bradley , "unbearable@ietf.org" , Stephen Farrell , Bill Mills , Phil Hunt Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 19:05:39 -0000 --047d7b3431060ce82b0509f57639 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 11, 2014 at 1:53 PM, Andrei Popov wrote: > =C3=98 If this is about client certs stored and available to the brows= er to > use that's a different and interesting question. > > In the current proposals, these are not full client certs, but > public-private key pairs. > > > > =C3=98 Is that really just using the browser cert store as a key manager= ? > > The current I-Ds provide a mechanism for the client to prove possession o= f > a client-generated key that is protected from export. This Token Binding > key could be hardware-bound or strongly protected in a different manner, > depending on system capabilities. The server can bind security tokens to > this key. > > > I like public key crypto. But this is a two party scheme. What benefit do we get from use of public key here? --047d7b3431060ce82b0509f57639 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 11, 2014 at 1:53 PM, Andrei Popov <Andrei.Popov@m= icrosoft.com> wrote:

=C3=98=C2= =A0 If this is about client certs sto= red and available to =C2=A0the browser to use that's a different and in= teresting question.

In the current proposals, these are n= ot full client certs, but public-private key pairs.

=C2=A0

=C3=98=C2= =A0 Is that really just using the bro= wser cert store as a key manager?

The current I-Ds provide a mechanism = for the client to prove possession of a client-generated key that is protec= ted from export. This Token Binding key could be hardware-bound or strongly protected in a different manner, depending o= n system capabilities. The server can bind security tokens to this key.<= /u>




I like public key crypto.

But this= is a two party scheme. What benefit do we get from use of public key here?= =C2=A0
--047d7b3431060ce82b0509f57639-- From nobody Thu Dec 11 11:19:49 2014 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 6F0A71A1B8B for ; Thu, 11 Dec 2014 11:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 LPJksldm-qK7 for ; Thu, 11 Dec 2014 11:19:42 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727AC1A6EFF for ; Thu, 11 Dec 2014 11:19:40 -0800 (PST) X-AuditID: 1209190c-f79e46d000000eb2-8d-5489ee4a52b0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 52.E2.03762.B4EE9845; Thu, 11 Dec 2014 14:19:39 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id sBBJJcBv022815; Thu, 11 Dec 2014 14:19:38 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBBJJaA4019183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Dec 2014 14:19:37 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBBJJZDX003680; Thu, 11 Dec 2014 14:19:35 -0500 (EST) Date: Thu, 11 Dec 2014 14:19:35 -0500 (EST) From: Benjamin Kaduk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT0fV+1xlisOo9q8WPSTOYLSZ+mM1o ce7xQiYHZo8Lq78yeSxZ8pPJo3XHX/YA5igum5TUnMyy1CJ9uwSujI67X1gL5jNVLHu9ib2B 8SVjFyMnh4SAicT0ky1MELaYxIV769lAbCGBxUwS3Q1hXYxcQPZGRonW7X9YIJxDTBKLpv1h hXAaGCVWtDcydzFycLAIaEscWGQL0s0moCIx881GsEkiAgYSDzdfAtvALJAs0TTtNSNIubCA q8TqOZwgYU6BQInu1V9YQWxeAUeJf5NvQI1fziQxff1bsISogI7E6v1TWCCKBCVOznzCAjFT S2L59G0sExgFZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyMo eDkleXYwvjmodIhRgINRiYc3I74zRIg1say4MvcQoyQHk5Ior9cVoBBfUn5KZUZicUZ8UWlO avEhRgkOZiUR3j2XgXK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8 wm+BGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGy4DU8BYXJOYWZ6ZD5E8x6nIsaN8/k0mIJS8/L1VK nPfRG6AiAZCijNI8uDmwpPOKURzoLWHeEJBRPMCEBTfpFdASJqAly7d0gCwpSURISTUwegnJ uyvZH16fZzq/L6GZf5eN+08Db7E1S7ZxtE2clxvRU9J1T7Lw/QONsqDFXr9nqO5YKR2zQdj2 F1d4tl1tip5cn5rGbN3OTYvFDBfpee1OnSTf6K0idm7V1t6Q6OxdhmLXSz3dalMKFyx6vVKQ +bxYNTvz9oLPwtwTm6snvjibpn1JvFSJpTgj0VCLuag4EQAeg6vDFQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/RUA-lhrv0m59YDmd59J8ZB5L0Cg Cc: Andrei Popov , "unbearable@ietf.org" Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 19:19:44 -0000 On Thu, 11 Dec 2014, Phillip Hallam-Baker wrote: > But this is a two party scheme. What benefit do we get from use of public > key here? If I remember correctly, http://tools.ietf.org/html/draft-balfanz-https-token-binding-00 describes a scheme which is not two-party. -Ben From nobody Thu Dec 11 11:25:19 2014 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 0CEFC1A8970 for ; Thu, 11 Dec 2014 11:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ojulu1jFwtOS for ; Thu, 11 Dec 2014 11:25:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4171A8951 for ; Thu, 11 Dec 2014 11:25:06 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 19:25:06 +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.0031.000; Thu, 11 Dec 2014 19:25:05 +0000 From: Andrei Popov To: Phillip Hallam-Baker Thread-Topic: [Unbearable] one proposal for a charter - please dicsuss Thread-Index: AQHQEz13HUkUpVDAykapHgbkfe3625yGWqQAgAAcnYCAABBeAIACxW9ggAAn+4CAAAMvgIAAMSsAgAAw4wCAACy/gIAAl18AgAAH1oCAABfUQIAABlmAgAAD6IA= Date: Thu, 11 Dec 2014 19:25:05 +0000 Message-ID: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.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::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1252; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(24454002)(377454003)(64706001)(54206007)(20776003)(101416001)(76576001)(4396001)(15975445007)(16236675004)(68736005)(102836002)(19625215002)(50986999)(54606007)(19609705001)(54356999)(76176999)(93886004)(122556002)(46102003)(19300405004)(97736003)(106116001)(561944003)(33656002)(106356001)(62966003)(77156002)(2656002)(31966008)(21056001)(86362001)(40100003)(99286002)(86612001)(110136001)(74316001)(19580405001)(107046002)(87936001)(92566001)(105586002)(120916001)(19580395003)(99396003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB125008430B22381290C231108C630BN3PR0301MB1250_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/lxjBK54sUxGwulwKnuFJBQ2KgSQ Cc: John Bradley , "unbearable@ietf.org" , Stephen Farrell , Bill Mills , Phil Hunt Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 19:25:12 -0000 --_000_BN3PR0301MB125008430B22381290C231108C630BN3PR0301MB1250_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aG91dCBiaW5kaW5nLCB0aGUgY29va2llIGlzIHJlbGF0aXZlbHkgZWFzeSB0byBleHBvcnQg dG8gYSBkaWZmZXJlbnQgbWFjaGluZSBhbmQgcmVwbGF5IHRvIHRoZSBzZXJ2ZXIsIGltcGVyc29u YXRpbmcgdGhlIHVzZXIuDQoNCkEgY29va2llIHRoYXTigJlzIGJvdW5kIHRvIGEga2V5IGlzIHVz ZWxlc3MsIHVubGVzcyB0aGUgYXR0YWNrZXIgY2FuIGFsc28gZXhwb3J0IHRoZSBrZXkgKHdoaWNo IGlzIHZlcnkgZGlmZmljdWx0IGluIHRoZSBjYXNlIG9mIGhhcmR3YXJlLWJvdW5kIGtleSkuDQoN ClRoZSB1c2Ugb2YgYXN5bW1ldHJpYyBrZXkgcGFpciBtZWFucyB0aGF0IHRoZSB0b2tlbiBiaW5k aW5nIGtleSBjYW4gYmUgZ2VuZXJhdGVkIGluIGEgaGFyZHdhcmUgbW9kdWxlLCBuZXZlciBleHBv c2VkIHRvIGxvY2FsIG1hbHdhcmUsIHBsdXMgdGhlIHByaXZhdGUga2V5IGlzIG5ldmVyIHRyYW5z bWl0dGVkIGFjcm9zcyB0aGUgbmV0d29yay4NCg0KRnJvbTogaGFsbGFtQGdtYWlsLmNvbSBbbWFp bHRvOmhhbGxhbUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBQaGlsbGlwIEhhbGxhbS1CYWtlcg0K U2VudDogVGh1cnNkYXksIERlY2VtYmVyIDExLCAyMDE0IDExOjA2IEFNDQpUbzogQW5kcmVpIFBv cG92DQpDYzogQmlsbCBNaWxsczsgUGhpbCBIdW50OyBKb2huIEJyYWRsZXk7IHVuYmVhcmFibGVA aWV0Zi5vcmc7IFN0ZXBoZW4gRmFycmVsbA0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBvbmUg cHJvcG9zYWwgZm9yIGEgY2hhcnRlciAtIHBsZWFzZSBkaWNzdXNzDQoNCg0KDQpPbiBUaHUsIERl YyAxMSwgMjAxNCBhdCAxOjUzIFBNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3Nv ZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQo+ICBJ ZiB0aGlzIGlzIGFib3V0IGNsaWVudCBjZXJ0cyBzdG9yZWQgYW5kIGF2YWlsYWJsZSB0byAgdGhl IGJyb3dzZXIgdG8gdXNlIHRoYXQncyBhIGRpZmZlcmVudCBhbmQgaW50ZXJlc3RpbmcgcXVlc3Rp b24uDQpJbiB0aGUgY3VycmVudCBwcm9wb3NhbHMsIHRoZXNlIGFyZSBub3QgZnVsbCBjbGllbnQg Y2VydHMsIGJ1dCBwdWJsaWMtcHJpdmF0ZSBrZXkgcGFpcnMuDQoNCg0KPiAgSXMgdGhhdCByZWFs bHkganVzdCB1c2luZyB0aGUgYnJvd3NlciBjZXJ0IHN0b3JlIGFzIGEga2V5IG1hbmFnZXI/DQpU aGUgY3VycmVudCBJLURzIHByb3ZpZGUgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQgdG8gcHJv dmUgcG9zc2Vzc2lvbiBvZiBhIGNsaWVudC1nZW5lcmF0ZWQga2V5IHRoYXQgaXMgcHJvdGVjdGVk IGZyb20gZXhwb3J0LiBUaGlzIFRva2VuIEJpbmRpbmcga2V5IGNvdWxkIGJlIGhhcmR3YXJlLWJv dW5kIG9yIHN0cm9uZ2x5IHByb3RlY3RlZCBpbiBhIGRpZmZlcmVudCBtYW5uZXIsIGRlcGVuZGlu ZyBvbiBzeXN0ZW0gY2FwYWJpbGl0aWVzLiBUaGUgc2VydmVyIGNhbiBiaW5kIHNlY3VyaXR5IHRv a2VucyB0byB0aGlzIGtleS4NCg0KDQoNCkkgbGlrZSBwdWJsaWMga2V5IGNyeXB0by4NCg0KQnV0 IHRoaXMgaXMgYSB0d28gcGFydHkgc2NoZW1lLiBXaGF0IGJlbmVmaXQgZG8gd2UgZ2V0IGZyb20g dXNlIG9mIHB1YmxpYyBrZXkgaGVyZT8NCg== --_000_BN3PR0301MB125008430B22381290C231108C630BN3PR0301MB1250_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5XaXRob3V0IGJpbmRpbmcsIHRoZSBjb29raWUgaXMgcmVsYXRpdmVs eSBlYXN5IHRvIGV4cG9ydCB0byBhIGRpZmZlcmVudCBtYWNoaW5lIGFuZCByZXBsYXkgdG8gdGhl IHNlcnZlciwgaW1wZXJzb25hdGluZyB0aGUgdXNlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkEgY29va2llIHRoYXTigJlzIGJvdW5kIHRvIGEga2V5IGlzIHVz ZWxlc3MsIHVubGVzcyB0aGUgYXR0YWNrZXIgY2FuIGFsc28gZXhwb3J0IHRoZSBrZXkgKHdoaWNo IGlzIHZlcnkgZGlmZmljdWx0IGluIHRoZSBjYXNlIG9mIGhhcmR3YXJlLWJvdW5kIGtleSkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgdXNlIG9mIGFzeW1t ZXRyaWMga2V5IHBhaXIgbWVhbnMgdGhhdCB0aGUgdG9rZW4gYmluZGluZyBrZXkgY2FuIGJlIGdl bmVyYXRlZCBpbiBhIGhhcmR3YXJlIG1vZHVsZSwgbmV2ZXIgZXhwb3NlZCB0byBsb2NhbCBtYWx3 YXJlLCBwbHVzIHRoZSBwcml2YXRlIGtleSBpcw0KIG5ldmVyIHRyYW5zbWl0dGVkIGFjcm9zcyB0 aGUgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gaGFsbGFtQGdtYWlsLmNvbSBbbWFpbHRvOmhhbGxhbUBnbWFp bC5jb21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWxsaXAgSGFsbGFtLUJha2VyPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBEZWNlbWJlciAxMSwgMjAxNCAxMTowNiBBTTxicj4NCjxiPlRv OjwvYj4gQW5kcmVpIFBvcG92PGJyPg0KPGI+Q2M6PC9iPiBCaWxsIE1pbGxzOyBQaGlsIEh1bnQ7 IEpvaG4gQnJhZGxleTsgdW5iZWFyYWJsZUBpZXRmLm9yZzsgU3RlcGhlbiBGYXJyZWxsPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gb25lIHByb3Bvc2FsIGZvciBhIGNoYXJ0 ZXIgLSBwbGVhc2UgZGljc3VzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgRGVj IDExLCAyMDE0IGF0IDE6NTMgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFu ZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPklmIHRoaXMgaXMgYWJvdXQgY2xpZW50IGNlcnRzIHN0b3JlZCBhbmQgYXZhaWxh YmxlIHRvICZuYnNwO3RoZSBicm93c2VyIHRvIHVzZSB0aGF0J3MgYSBkaWZmZXJlbnQgYW5kIGlu dGVyZXN0aW5nIHF1ZXN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIHRoZSBjdXJyZW50IHBy b3Bvc2FscywgdGhlc2UgYXJlIG5vdCBmdWxsIGNsaWVudCBjZXJ0cywgYnV0IHB1YmxpYy1wcml2 YXRlIGtleSBwYWlycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5n ZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5JcyB0aGF0IHJlYWxseSBqdXN0IHVzaW5nIHRoZSBicm93c2VyIGNlcnQgc3RvcmUgYXMg YSBrZXkgbWFuYWdlcj88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgY3VycmVudCBJLURzIHByb3Zp ZGUgYSBtZWNoYW5pc20gZm9yIHRoZSBjbGllbnQgdG8gcHJvdmUgcG9zc2Vzc2lvbiBvZiBhIGNs aWVudC1nZW5lcmF0ZWQga2V5IHRoYXQNCiBpcyBwcm90ZWN0ZWQgZnJvbSBleHBvcnQuIFRoaXMg VG9rZW4gQmluZGluZyBrZXkgY291bGQgYmUgaGFyZHdhcmUtYm91bmQgb3Igc3Ryb25nbHkgcHJv dGVjdGVkIGluIGEgZGlmZmVyZW50IG1hbm5lciwgZGVwZW5kaW5nIG9uIHN5c3RlbSBjYXBhYmls aXRpZXMuIFRoZSBzZXJ2ZXIgY2FuIGJpbmQgc2VjdXJpdHkgdG9rZW5zIHRvIHRoaXMga2V5Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGxpa2UgcHVibGljIGtleSBjcnlwdG8uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB0aGlzIGlzIGEgdHdv IHBhcnR5IHNjaGVtZS4gV2hhdCBiZW5lZml0IGRvIHdlIGdldCBmcm9tIHVzZSBvZiBwdWJsaWMg a2V5IGhlcmU/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR0301MB125008430B22381290C231108C630BN3PR0301MB1250_-- From nobody Thu Dec 11 11:26:49 2014 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 479661A89B3 for ; Thu, 11 Dec 2014 11:26:44 -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 MCTGetEwXCYV for ; Thu, 11 Dec 2014 11:26:42 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8506F1A1B80 for ; Thu, 11 Dec 2014 11:26:42 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 19:26:41 +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.0031.000; Thu, 11 Dec 2014 19:26:40 +0000 From: Andrei Popov To: Benjamin Kaduk , Phillip Hallam-Baker Thread-Topic: [Unbearable] one proposal for a charter - please dicsuss Thread-Index: AQHQEz13HUkUpVDAykapHgbkfe3625yGWqQAgAAcnYCAABBeAIACxW9ggAAn+4CAAAMvgIAAMSsAgAAw4wCAACy/gIAAl18AgAAH1oCAABfUQIAABlmAgAAD6oCAAAGw0A== Date: Thu, 11 Dec 2014 19:26:40 +0000 Message-ID: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.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::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1252; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(199003)(24454002)(189002)(77156002)(62966003)(21056001)(31966008)(2656002)(46102003)(122556002)(33656002)(106356001)(106116001)(561944003)(97736003)(107046002)(19580405001)(92566001)(87936001)(2171001)(19580395003)(99396003)(105586002)(120916001)(86362001)(74316001)(99286002)(40100003)(86612001)(76576001)(4396001)(102836002)(15975445007)(68736005)(1720100001)(54206007)(20776003)(64706001)(101416001)(50986999)(54606007)(93886004)(54356999)(76176999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/imLCtv4EewbdQxPchb1xYT-u0Ek Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 19:26:44 -0000 Yes, federation scenarios where the token is generated by an Identity Provi= der and presented to a Relying Party are also supported. Cheers, Andrei -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@MIT.EDU]=20 Sent: Thursday, December 11, 2014 11:20 AM To: Phillip Hallam-Baker Cc: Andrei Popov; unbearable@ietf.org Subject: Re: [Unbearable] one proposal for a charter - please dicsuss On Thu, 11 Dec 2014, Phillip Hallam-Baker wrote: > But this is a two party scheme. What benefit do we get from use of=20 > public key here? If I remember correctly, http://tools.ietf.org/html/draft-balfanz-https-token-binding-00 describes a= scheme which is not two-party. -Ben From nobody Thu Dec 11 11:33:21 2014 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 DBA9D1A1B57 for ; Thu, 11 Dec 2014 11:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Lcum5l4sRT-P for ; Thu, 11 Dec 2014 11:33:13 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2B81A1A9A for ; Thu, 11 Dec 2014 11:33:12 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so4652335lbv.21 for ; Thu, 11 Dec 2014 11:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GnNk/SsOcwJbXpp13dKaFEq9N7I1z7yNrAhY2WcuwXg=; b=BoLvQErkdZT6MQocA/Zw7z5DEWGXx2Eaus5JxWcxUtOEsnUwnc4XzUF81C8/g8hqCm QVU7w36ovNAu+4Kdp9CR9YhQa4RQkYclSzJIAbdK9J5tp/v4oJ/jEBxr4joMQm0r+q9E jt4ymW8q/2fxXLMhuWJVB9XL/k8AJQ7Gd1kQrpBqJgAgFnN/v4j8fxsjBefZ/E+M0qdC V662KvUwTxbCV/TKSc9m4QofEoK8tmKxIhN1aE8jGfvVr/d6q0KuZQvZ6DSyp0qUEHCI Rad/dA9tOx3SQZus93rhelRwKW0rJ/Yy+BSuyCYS/VtReFLjaNsf4BcNcNhThJt/Ypoz AMuA== MIME-Version: 1.0 X-Received: by 10.152.219.3 with SMTP id pk3mr11576714lac.19.1418326391024; Thu, 11 Dec 2014 11:33:11 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Thu, 11 Dec 2014 11:33:10 -0800 (PST) In-Reply-To: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> Date: Thu, 11 Dec 2014 14:33:10 -0500 X-Google-Sender-Auth: N6kLH5FSIh6vekYZG0Qh3K5eJvM Message-ID: From: Phillip Hallam-Baker To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113409d4b670d50509f5d8a5 Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/xGelSWg1fBQM68xCMWbH6icuW3I Cc: John Bradley , "unbearable@ietf.org" , Stephen Farrell , Bill Mills , Phil Hunt Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 19:33:14 -0000 --001a113409d4b670d50509f5d8a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 11, 2014 at 2:25 PM, Andrei Popov wrote: > Without binding, the cookie is relatively easy to export to a different > machine and replay to the server, impersonating the user. > > > > A cookie that=E2=80=99s bound to a key is useless, unless the attacker ca= n also > export the key (which is very difficult in the case of hardware-bound key= ). > Agreed > The use of asymmetric key pair means that the token binding key can be > generated in a hardware module, never exposed to local malware, plus the > private key is never transmitted across the network. > They are exactly the same. Or rather they should be. The Windows API are limited to asymmetric but that is due to a failure of imagination rather than need. The most appropriate way to handle keys in my view is for the TPM to store just one key that is then used to unwrap tickets to obtain a symmetric or asymmetric key as the need arises. This minimizes the amount of data that the TPM needs to store. --001a113409d4b670d50509f5d8a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 11, 2014 at 2:25 PM, Andrei Popov <Andrei.Popov@m= icrosoft.com> wrote:

Without binding, the cookie is relati= vely easy to export to a different machine and replay to the server, impers= onating the user.

=C2=A0

A cookie that=E2=80=99s bound to a ke= y is useless, unless the attacker can also export the key (which is very di= fficult in the case of hardware-bound key).


Agreed
=C2=A0

The use of asymmetric key pair means = that the token binding key can be generated in a hardware module, never exp= osed to local malware, plus the private key is never transmitted across the network.

<= div>
They are exactly the same. Or rather they should be. The= Windows API are limited to asymmetric but that is due to a failure of imag= ination rather than need.


The most = appropriate way to handle keys in my view is for the TPM to store just one = key that is then used to unwrap tickets to obtain a symmetric or asymmetric= key as the need arises. This minimizes the amount of data that the TPM nee= ds to store.


=C2=A0
--001a113409d4b670d50509f5d8a5-- From nobody Thu Dec 11 12:01:28 2014 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 26DF31A6FD2 for ; Thu, 11 Dec 2014 12:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 kEcjJ0zOxbqQ for ; Thu, 11 Dec 2014 12:01:26 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B08CB1A89AB for ; Thu, 11 Dec 2014 12:01:09 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 77A2C286059; Thu, 11 Dec 2014 12:01:09 -0800 (PST) Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPA id F1B1C286057; Thu, 11 Dec 2014 12:01:08 -0800 (PST) Date: Thu, 11 Dec 2014 14:00:53 -0600 From: Nico Williams To: Benjamin Kaduk Message-ID: <20141211200049.GF3448@localhost> References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/KsDIEjidqgNj_E5iUawrv7eVJJU Cc: Andrei Popov , Phillip Hallam-Baker , "unbearable@ietf.org" Subject: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss 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, 11 Dec 2014 20:01:27 -0000 On Thu, Dec 11, 2014 at 02:19:35PM -0500, Benjamin Kaduk wrote: > On Thu, 11 Dec 2014, Phillip Hallam-Baker wrote: > > But this is a two party scheme. What benefit do we get from use of public > > key here? > > If I remember correctly, > http://tools.ietf.org/html/draft-balfanz-https-token-binding-00 describes > a scheme which is not two-party. Is there a list of proposals to be discussed on this list? Nico -- From nobody Thu Dec 11 12:01:43 2014 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 E469B1A1BC8 for ; Thu, 11 Dec 2014 12:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 6uuG_-2I8g_k for ; Thu, 11 Dec 2014 12:01:33 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05DB1A6F6F for ; Thu, 11 Dec 2014 12:01:24 -0800 (PST) Received: from BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) by BN3PR0301MB1233.namprd03.prod.outlook.com (25.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 20:01:23 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 20:01:22 +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.0031.000; Thu, 11 Dec 2014 20:01:22 +0000 From: Andrei Popov To: Phillip Hallam-Baker Thread-Topic: [Unbearable] one proposal for a charter - please dicsuss Thread-Index: AQHQEz13HUkUpVDAykapHgbkfe3625yGWqQAgAAcnYCAABBeAIACxW9ggAAn+4CAAAMvgIAAMSsAgAAw4wCAACy/gIAAl18AgAAH1oCAABfUQIAABlmAgAAD6ICAAAPNAIAAAIGQ Date: Thu, 11 Dec 2014 20:01:22 +0000 Message-ID: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.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::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(24454002)(199003)(164054003)(77156002)(62966003)(76576001)(4396001)(19580405001)(19609705001)(54206007)(31966008)(19580395003)(46102003)(64706001)(20776003)(106356001)(99286002)(105586002)(106116001)(110136001)(86612001)(54606007)(19625215002)(50986999)(76176999)(54356999)(101416001)(33656002)(102836002)(19300405004)(120916001)(87936001)(2656002)(68736005)(40100003)(93886004)(16236675004)(21056001)(122556002)(97736003)(92566001)(86362001)(74316001)(15975445007)(561944003)(99396003)(107046002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1250232896AD55BB3C7A4F7D8C630BN3PR0301MB1250_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/At_YKJwZCdgr6FlcYbIWrCxsDL8 Cc: John Bradley , "unbearable@ietf.org" , Stephen Farrell , Bill Mills , Phil Hunt Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 20:01:38 -0000 --_000_BN3PR0301MB1250232896AD55BB3C7A4F7D8C630BN3PR0301MB1250_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJvdG9jb2wgZGV0YWlscywgZXhpc3RpbmcgQVBJcywgdGhlIHVzZSBvZiBUUE0sIGV0Yy4gYXJl IGFsbCBncmVhdCB0b3BpY3MgdG8gZGlzY3VzcyBhcyB3ZSBsb29rIGF0IHRoZSBwcm9wb3NhbHMu IEnigJlkIGJlIHZlcnkgaGFwcHkgdG8gZGVsdmUgaW50byB0aGVzZS4gQnV0IEkgdGhvdWdodCB0 aGUgZ3VpZGFuY2UgZnJvbSB0aGUgQURzIHdhcyB0byBkaXNjdXNzIHRoZSBjaGFydGVyIGFuZCBz ZXQgdXAgdGhlIFdHIGZpcnN0Pw0KDQpUaGFua3MsDQoNCkFuZHJlaQ0KDQpGcm9tOiBoYWxsYW1A Z21haWwuY29tIFttYWlsdG86aGFsbGFtQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFBoaWxsaXAg SGFsbGFtLUJha2VyDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMTEsIDIwMTQgMTE6MzMgQU0N ClRvOiBBbmRyZWkgUG9wb3YNCkNjOiBCaWxsIE1pbGxzOyBQaGlsIEh1bnQ7IEpvaG4gQnJhZGxl eTsgdW5iZWFyYWJsZUBpZXRmLm9yZzsgU3RlcGhlbiBGYXJyZWxsDQpTdWJqZWN0OiBSZTogW1Vu YmVhcmFibGVdIG9uZSBwcm9wb3NhbCBmb3IgYSBjaGFydGVyIC0gcGxlYXNlIGRpY3N1c3MNCg0K DQoNCk9uIFRodSwgRGVjIDExLCAyMDE0IGF0IDI6MjUgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQpXaXRob3V0IGJpbmRpbmcsIHRoZSBjb29raWUgaXMgcmVsYXRpdmVseSBlYXN5IHRv IGV4cG9ydCB0byBhIGRpZmZlcmVudCBtYWNoaW5lIGFuZCByZXBsYXkgdG8gdGhlIHNlcnZlciwg aW1wZXJzb25hdGluZyB0aGUgdXNlci4NCg0KQSBjb29raWUgdGhhdOKAmXMgYm91bmQgdG8gYSBr ZXkgaXMgdXNlbGVzcywgdW5sZXNzIHRoZSBhdHRhY2tlciBjYW4gYWxzbyBleHBvcnQgdGhlIGtl eSAod2hpY2ggaXMgdmVyeSBkaWZmaWN1bHQgaW4gdGhlIGNhc2Ugb2YgaGFyZHdhcmUtYm91bmQg a2V5KS4NCg0KQWdyZWVkDQoNClRoZSB1c2Ugb2YgYXN5bW1ldHJpYyBrZXkgcGFpciBtZWFucyB0 aGF0IHRoZSB0b2tlbiBiaW5kaW5nIGtleSBjYW4gYmUgZ2VuZXJhdGVkIGluIGEgaGFyZHdhcmUg bW9kdWxlLCBuZXZlciBleHBvc2VkIHRvIGxvY2FsIG1hbHdhcmUsIHBsdXMgdGhlIHByaXZhdGUg a2V5IGlzIG5ldmVyIHRyYW5zbWl0dGVkIGFjcm9zcyB0aGUgbmV0d29yay4NCg0KVGhleSBhcmUg ZXhhY3RseSB0aGUgc2FtZS4gT3IgcmF0aGVyIHRoZXkgc2hvdWxkIGJlLiBUaGUgV2luZG93cyBB UEkgYXJlIGxpbWl0ZWQgdG8gYXN5bW1ldHJpYyBidXQgdGhhdCBpcyBkdWUgdG8gYSBmYWlsdXJl IG9mIGltYWdpbmF0aW9uIHJhdGhlciB0aGFuIG5lZWQuDQoNCg0KVGhlIG1vc3QgYXBwcm9wcmlh dGUgd2F5IHRvIGhhbmRsZSBrZXlzIGluIG15IHZpZXcgaXMgZm9yIHRoZSBUUE0gdG8gc3RvcmUg anVzdCBvbmUga2V5IHRoYXQgaXMgdGhlbiB1c2VkIHRvIHVud3JhcCB0aWNrZXRzIHRvIG9idGFp biBhIHN5bW1ldHJpYyBvciBhc3ltbWV0cmljIGtleSBhcyB0aGUgbmVlZCBhcmlzZXMuIFRoaXMg bWluaW1pemVzIHRoZSBhbW91bnQgb2YgZGF0YSB0aGF0IHRoZSBUUE0gbmVlZHMgdG8gc3RvcmUu DQoNCg0KDQo= --_000_BN3PR0301MB1250232896AD55BB3C7A4F7D8C630BN3PR0301MB1250_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Qcm90b2NvbCBkZXRhaWxzLCBleGlzdGluZyBBUElzLCB0 aGUgdXNlIG9mIFRQTSwgZXRjLiBhcmUgYWxsIGdyZWF0IHRvcGljcyB0byBkaXNjdXNzIGFzIHdl IGxvb2sgYXQgdGhlIHByb3Bvc2Fscy4gSeKAmWQgYmUgdmVyeSBoYXBweSB0byBkZWx2ZSBpbnRv IHRoZXNlLiBCdXQNCiBJIHRob3VnaHQgdGhlIGd1aWRhbmNlIGZyb20gdGhlIEFEcyB3YXMgdG8g ZGlzY3VzcyB0aGUgY2hhcnRlciBhbmQgc2V0IHVwIHRoZSBXRyBmaXJzdD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBoYWxsYW1AZ21haWwuY29t IFttYWlsdG86aGFsbGFtQGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbGxpcCBI YWxsYW0tQmFrZXI8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIERlY2VtYmVyIDExLCAyMDE0 IDExOjMzIEFNPGJyPg0KPGI+VG86PC9iPiBBbmRyZWkgUG9wb3Y8YnI+DQo8Yj5DYzo8L2I+IEJp bGwgTWlsbHM7IFBoaWwgSHVudDsgSm9obiBCcmFkbGV5OyB1bmJlYXJhYmxlQGlldGYub3JnOyBT dGVwaGVuIEZhcnJlbGw8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBvbmUg cHJvcG9zYWwgZm9yIGEgY2hhcnRlciAtIHBsZWFzZSBkaWNzdXNzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBEZWMgMTEsIDIwMTQgYXQgMjoyNSBQTSwgQW5kcmVpIFBvcG92ICZs dDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2Js YW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2l0aG91dCBiaW5kaW5nLCB0aGUgY29va2ll IGlzIHJlbGF0aXZlbHkgZWFzeSB0byBleHBvcnQgdG8gYSBkaWZmZXJlbnQgbWFjaGluZSBhbmQg cmVwbGF5IHRvIHRoZSBzZXJ2ZXIsDQogaW1wZXJzb25hdGluZyB0aGUgdXNlci48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BIGNvb2tpZSB0aGF04oCZcyBi b3VuZCB0byBhIGtleSBpcyB1c2VsZXNzLCB1bmxlc3MgdGhlIGF0dGFja2VyIGNhbiBhbHNvIGV4 cG9ydCB0aGUga2V5ICh3aGljaCBpcyB2ZXJ5DQogZGlmZmljdWx0IGluIHRoZSBjYXNlIG9mIGhh cmR3YXJlLWJvdW5kIGtleSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlZDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSB1c2Ugb2Yg YXN5bW1ldHJpYyBrZXkgcGFpciBtZWFucyB0aGF0IHRoZSB0b2tlbiBiaW5kaW5nIGtleSBjYW4g YmUgZ2VuZXJhdGVkIGluIGEgaGFyZHdhcmUgbW9kdWxlLA0KIG5ldmVyIGV4cG9zZWQgdG8gbG9j YWwgbWFsd2FyZSwgcGx1cyB0aGUgcHJpdmF0ZSBrZXkgaXMgbmV2ZXIgdHJhbnNtaXR0ZWQgYWNy b3NzIHRoZSBuZXR3b3JrLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGV5IGFyZSBleGFj dGx5IHRoZSBzYW1lLiBPciByYXRoZXIgdGhleSBzaG91bGQgYmUuIFRoZSBXaW5kb3dzIEFQSSBh cmUgbGltaXRlZCB0byBhc3ltbWV0cmljIGJ1dCB0aGF0IGlzIGR1ZSB0byBhIGZhaWx1cmUgb2Yg aW1hZ2luYXRpb24gcmF0aGVyIHRoYW4gbmVlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbW9zdCBhcHByb3ByaWF0ZSB3YXkgdG8g aGFuZGxlIGtleXMgaW4gbXkgdmlldyBpcyBmb3IgdGhlIFRQTSB0byBzdG9yZSBqdXN0IG9uZSBr ZXkgdGhhdCBpcyB0aGVuIHVzZWQgdG8gdW53cmFwIHRpY2tldHMgdG8gb2J0YWluIGEgc3ltbWV0 cmljIG9yIGFzeW1tZXRyaWMga2V5IGFzIHRoZSBuZWVkIGFyaXNlcy4gVGhpcyBtaW5pbWl6ZXMg dGhlIGFtb3VudCBvZiBkYXRhIHRoYXQgdGhlIFRQTSBuZWVkcw0KIHRvIHN0b3JlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BN3PR0301MB1250232896AD55BB3C7A4F7D8C630BN3PR0301MB1250_-- From nobody Thu Dec 11 12:07:39 2014 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 7EE121A8A4F for ; Thu, 11 Dec 2014 12:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 J1yY-EDRKWzL for ; Thu, 11 Dec 2014 12:07:37 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C38851A894C for ; Thu, 11 Dec 2014 12:07:30 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 9E8682C806D; Thu, 11 Dec 2014 12:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=OmXCVViNUg1e3VOUI03xwCRrIzU=; b=s2o3fKoVCue z3l/ewG76GM9OhvA44silJfg0uCffzYHySzBuRU9tTlzjrMwYluorxzP1lcw82c4 juieo5FSvRT6iXPcJeSxvj67RkCPkJCpWJ2W15hckBJme/3bnNnK+KdqaQ0JN/sG 5qMCRL4d2giH75hwemgWMXWEhMZs9JXM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 088F82C8058; Thu, 11 Dec 2014 12:07:29 -0800 (PST) Date: Thu, 11 Dec 2014 14:07:29 -0600 From: Nico Williams To: Andrei Popov Message-ID: <20141211200725.GG3448@localhost> References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/oXJDG8Q57-MgXJRxlf00rmab5mc Cc: Phillip Hallam-Baker , "unbearable@ietf.org" , John Bradley , Stephen Farrell , Bill Mills , Phil Hunt Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 20:07:38 -0000 On Thu, Dec 11, 2014 at 08:01:22PM +0000, Andrei Popov wrote: > Protocol details, existing APIs, the use of TPM, etc. are all great > topics to discuss as we look at the proposals. I=E2=80=99d be very happ= y to > delve into these. But I thought the guidance from the ADs was to > discuss the charter and set up the WG first? Existing APIs might act as constraints on some proposals. Discovering the rough outline of the problem space and constraints on solutions, as well as properties we want solutions to have, seems like a worthwhile activity at this time. Details can be left for later. Thoug I don't think that TPM APIs should constrain us too much here. TPMs should be optional anyways. Nico --=20 From nobody Thu Dec 11 12:17:13 2014 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 28A2B1A8A73 for ; Thu, 11 Dec 2014 12:17:10 -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 2W4p0fT_9UoZ for ; Thu, 11 Dec 2014 12:17:08 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7399B1A8A50 for ; Thu, 11 Dec 2014 12:17:07 -0800 (PST) Received: from BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) by BN3PR0301MB0881.namprd03.prod.outlook.com (25.160.155.143) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 20:16:45 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 20:16:43 +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.0031.000; Thu, 11 Dec 2014 20:16:43 +0000 From: Andrei Popov To: Nico Williams Thread-Topic: [Unbearable] one proposal for a charter - please dicsuss Thread-Index: AQHQEz13HUkUpVDAykapHgbkfe3625yGWqQAgAAcnYCAABBeAIACxW9ggAAn+4CAAAMvgIAAMSsAgAAw4wCAACy/gIAAl18AgAAH1oCAABfUQIAABlmAgAAD6ICAAAPNAIAAAIGQgAAJFoCAAABicA== Date: Thu, 11 Dec 2014 20:16:43 +0000 Message-ID: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> <20141211200725.GG3448@localhost> In-Reply-To: <20141211200725.GG3448@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377454003)(199003)(24454002)(76176999)(54356999)(50986999)(54606007)(102836002)(101416001)(33656002)(106356001)(99286002)(110136001)(86612001)(106116001)(105586002)(74316001)(86362001)(92566001)(561944003)(107046002)(99396003)(2656002)(87936001)(93886004)(68736005)(40100003)(120916001)(97736003)(21056001)(122556002)(54206007)(76576001)(77156002)(62966003)(4396001)(19580405001)(64706001)(20776003)(19580395003)(46102003)(31966008)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB0881; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/B89SQF3zSCDh76zx2TxzzjL3AnA Cc: Phillip Hallam-Baker , "unbearable@ietf.org" , John Bradley , Stephen Farrell , Bill Mills , Phil Hunt Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 20:17:10 -0000 WWVzIG9uIGJvdGggcG9pbnRzLiBJZiB3ZSBjYW4gY29tZSB0byBhbiBhZ3JlZW1lbnQgb24gY29u c3RyYWludHMgYW5kIHJlcXVpcmVtZW50cywgZnVydGhlciBkaXNjdXNzaW9uIHdpbGwgYmUgbW9y ZSBwcm9kdWN0aXZlLg0KDQpUbyB0aGlzIGVuZCwgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgaGFzIHNv bWUgZGVzaWduIGdvYWxzIGxpc3RlZCAoaW4gbm8gcGFydGljdWxhciBvcmRlcik6DQoxLiAgICAg ICAgICAgIFByZXZlbnQgZXhwb3J0IGFuZCByZXBsYXkgb2Ygc2VjdXJpdHkgdG9rZW5zLg0KMi4g ICAgICAgICAgICBBbGxvdyBzdHJvbmcga2V5IHByb3RlY3Rpb24sIGUuZy4gdXNpbmcgaGFyZHdh cmUtYm91bmQga2V5cy4NCjMuICAgICAgICAgICAgU3VwcG9ydCBib3RoIGZpcnN0LXBhcnR5IGFu ZCBmZWRlcmF0aW9uIHNjZW5hcmlvcy4NCjQuICAgICAgICAgICAgUHJlc2VydmUgdXNlciBwcml2 YWN5Lg0KNS4gICAgICAgICAgICBNYWtlIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sIHVzZWFi bGUgaW4gY29tYmluYXRpb24gd2l0aCBhIHZhcmlldHkgb2YgYXBwbGljYXRpb24gcHJvdG9jb2xz Lg0KNi4gICAgICAgICAgICBBbGxvdyB0aGUgbmVnb3RpYXRpb24gb2YgdGhlIFRva2VuIEJpbmRp bmcgcHJvdG9jb2wgd2l0aG91dCBhZGRpdGlvbmFsIHJvdW5kLXRyaXBzLg0KNy4gICAgICAgICAg ICBBbGxvdyB0aGUgdXNlIG9mIG11bHRpcGxlIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcywgc28g dGhhdCBhIHZhcmlldHkgb2Ygc2VjdXJlIGhhcmR3YXJlIG1vZHVsZXMgd2l0aCBkaWZmZXJlbnQg Y3J5cHRvZ3JhcGhpYyBjYXBhYmlsaXRpZXMgY291bGQgYmUgdXNlZCB3aXRoIFRva2VuIEJpbmRp bmcuDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBOaWNvIFdpbGxpYW1zIFttYWlsdG86bmljb0BjcnlwdG9uZWN0b3IuY29tXSANClNlbnQ6 IFRodXJzZGF5LCBEZWNlbWJlciAxMSwgMjAxNCAxMjowNyBQTQ0KVG86IEFuZHJlaSBQb3Bvdg0K Q2M6IFBoaWxsaXAgSGFsbGFtLUJha2VyOyBKb2huIEJyYWRsZXk7IHVuYmVhcmFibGVAaWV0Zi5v cmc7IFN0ZXBoZW4gRmFycmVsbDsgQmlsbCBNaWxsczsgUGhpbCBIdW50DQpTdWJqZWN0OiBSZTog W1VuYmVhcmFibGVdIG9uZSBwcm9wb3NhbCBmb3IgYSBjaGFydGVyIC0gcGxlYXNlIGRpY3N1c3MN Cg0KT24gVGh1LCBEZWMgMTEsIDIwMTQgYXQgMDg6MDE6MjJQTSArMDAwMCwgQW5kcmVpIFBvcG92 IHdyb3RlOg0KPiBQcm90b2NvbCBkZXRhaWxzLCBleGlzdGluZyBBUElzLCB0aGUgdXNlIG9mIFRQ TSwgZXRjLiBhcmUgYWxsIGdyZWF0IA0KPiB0b3BpY3MgdG8gZGlzY3VzcyBhcyB3ZSBsb29rIGF0 IHRoZSBwcm9wb3NhbHMuIEnigJlkIGJlIHZlcnkgaGFwcHkgdG8gDQo+IGRlbHZlIGludG8gdGhl c2UuIEJ1dCBJIHRob3VnaHQgdGhlIGd1aWRhbmNlIGZyb20gdGhlIEFEcyB3YXMgdG8gDQo+IGRp c2N1c3MgdGhlIGNoYXJ0ZXIgYW5kIHNldCB1cCB0aGUgV0cgZmlyc3Q/DQoNCkV4aXN0aW5nIEFQ SXMgbWlnaHQgYWN0IGFzIGNvbnN0cmFpbnRzIG9uIHNvbWUgcHJvcG9zYWxzLiAgRGlzY292ZXJp bmcgdGhlIHJvdWdoIG91dGxpbmUgb2YgdGhlIHByb2JsZW0gc3BhY2UgYW5kIGNvbnN0cmFpbnRz IG9uIHNvbHV0aW9ucywgYXMgd2VsbCBhcyBwcm9wZXJ0aWVzIHdlIHdhbnQgc29sdXRpb25zIHRv IGhhdmUsIHNlZW1zIGxpa2UgYSB3b3J0aHdoaWxlIGFjdGl2aXR5IGF0IHRoaXMgdGltZS4gIERl dGFpbHMgY2FuIGJlIGxlZnQgZm9yIGxhdGVyLg0KDQpUaG91ZyBJIGRvbid0IHRoaW5rIHRoYXQg VFBNIEFQSXMgc2hvdWxkIGNvbnN0cmFpbiB1cyB0b28gbXVjaCBoZXJlLg0KVFBNcyBzaG91bGQg YmUgb3B0aW9uYWwgYW55d2F5cy4NCg0KTmljbw0KLS0gDQo= From nobody Thu Dec 11 12:25:09 2014 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 C828B1A1BE0 for ; Thu, 11 Dec 2014 12:25:05 -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 AyZEIcd4Rcyb for ; Thu, 11 Dec 2014 12:25:03 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3561A03B3 for ; Thu, 11 Dec 2014 12:25:03 -0800 (PST) Received: from BN3PR0301MB1249.namprd03.prod.outlook.com (25.161.207.25) by BN3PR0301MB0865.namprd03.prod.outlook.com (25.160.155.14) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 20:24:41 +0000 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.31.17; Thu, 11 Dec 2014 20:24:39 +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.0031.000; Thu, 11 Dec 2014 20:24:39 +0000 From: Andrei Popov To: Nico Williams , Benjamin Kaduk Thread-Topic: List of proposals? Re: one proposal for a charter - please dicsuss Thread-Index: AQHQFX02QqmMTuMzN0aHm7cnuEjJbJyK1THQ Date: Thu, 11 Dec 2014 20:24:39 +0000 Message-ID: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> <20141211200049.GF3448@localhost> In-Reply-To: <20141211200049.GF3448@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1249;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(377454003)(13464003)(51704005)(189002)(19580395003)(19580405001)(99286002)(76576001)(77156002)(54206007)(64706001)(20776003)(62966003)(4396001)(2171001)(87936001)(122556002)(40100003)(107046002)(31966008)(33656002)(99396003)(2656002)(106356001)(50986999)(54356999)(106116001)(105586002)(76176999)(54606007)(15975445007)(86362001)(97736003)(21056001)(102836002)(92566001)(74316001)(120916001)(1720100001)(110136001)(68736005)(561944003)(46102003)(101416001)(86612001)(93886004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1249; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB0865; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/QBllvFC9NTTdVCkzCV7fHwLjuDM Cc: "unbearable@ietf.org" , Phillip Hallam-Baker Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss 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, 11 Dec 2014 20:25:06 -0000 The proposed charter suggests the following list of I-Ds as a starting poin= t for the new WG: - http://tools.ietf.org/html/draft-popov-token-binding-00; - http://tools.ietf.org/html/draft-balfanz-https-token-binding-00. Andrei -----Original Message----- From: Nico Williams [mailto:nico@cryptonector.com]=20 Sent: Thursday, December 11, 2014 12:01 PM To: Benjamin Kaduk Cc: Phillip Hallam-Baker; Andrei Popov; unbearable@ietf.org Subject: List of proposals? Re: one proposal for a charter - please dicsuss On Thu, Dec 11, 2014 at 02:19:35PM -0500, Benjamin Kaduk wrote: > On Thu, 11 Dec 2014, Phillip Hallam-Baker wrote: > > But this is a two party scheme. What benefit do we get from use of=20 > > public key here? >=20 > If I remember correctly, > http://tools.ietf.org/html/draft-balfanz-https-token-binding-00=20 > describes a scheme which is not two-party. Is there a list of proposals to be discussed on this list? Nico --=20 From nobody Thu Dec 11 12:43:12 2014 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 0485D1A879A for ; Thu, 11 Dec 2014 12:43:11 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 0rrwF2jpdqtJ for ; Thu, 11 Dec 2014 12:43:09 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30C91A871B for ; Thu, 11 Dec 2014 12:43:08 -0800 (PST) Received: from [192.168.131.137] ([80.92.119.109]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0La3c1-1XY8601mGL-00lknv; Thu, 11 Dec 2014 21:43:05 +0100 Message-ID: <548A01D8.7000107@gmx.net> Date: Thu, 11 Dec 2014 21:43:04 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrei Popov , Nico Williams , Benjamin Kaduk References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> <20141211200049.GF3448@localhost> In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jLkS94Qm9kPLdD8pDcbEMLdpAQiJME2Js" X-Provags-ID: V03:K0:0gNyH55BE+Xu38TgCiBS7RW1a/WV4Y4KY1GtPuN24hndmtElWCi +kUBDIy9vvokqLf0hY/4GpOVmV653tzEliKjuprTBCjND04wJPWGrPQJBv/Zf53k4h3IpDa ++ge6ftFweaV6xsN+W4e1WV+NUI8PsUBz9oeggO18Cc68sLGii0Jkq/1UZm4w47sQIVgNQf bHwuM/+O4w0Z8TT7Qy2eQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/Uz32-kr0sxJVhGHomwnd2Wi8sF8 Cc: "unbearable@ietf.org" , Phillip Hallam-Baker Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss 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, 11 Dec 2014 20:43:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jLkS94Qm9kPLdD8pDcbEMLdpAQiJME2Js Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In OAuth we have explored more proposals. Use Cases/Requirements/Architecture Document (currently in WGLC): http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ These are the documents referenced: http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ http://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ Ciao Hannes On 12/11/2014 09:24 PM, Andrei Popov wrote: > The proposed charter suggests the following list of I-Ds as a starting = point for the new WG: > - http://tools.ietf.org/html/draft-popov-token-binding-00; > - http://tools.ietf.org/html/draft-balfanz-https-token-binding-00. >=20 > Andrei >=20 > -----Original Message----- > From: Nico Williams [mailto:nico@cryptonector.com]=20 > Sent: Thursday, December 11, 2014 12:01 PM > To: Benjamin Kaduk > Cc: Phillip Hallam-Baker; Andrei Popov; unbearable@ietf.org > Subject: List of proposals? Re: one proposal for a charter - please dic= suss >=20 > On Thu, Dec 11, 2014 at 02:19:35PM -0500, Benjamin Kaduk wrote: >> On Thu, 11 Dec 2014, Phillip Hallam-Baker wrote: >>> But this is a two party scheme. What benefit do we get from use of=20 >>> public key here? >> >> If I remember correctly, >> http://tools.ietf.org/html/draft-balfanz-https-token-binding-00=20 >> describes a scheme which is not two-party. >=20 > Is there a list of proposals to be discussed on this list? >=20 > Nico >=20 --jLkS94Qm9kPLdD8pDcbEMLdpAQiJME2Js Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUigHYAAoJEGhJURNOOiAtZFQH/RcxZdYGtRo9qdpZ7yKwoX4J cXmJ+a6iNgPn5RUJP94SY19NUZ0u7xLkLai1xAec+zFO0MMiBKbqdR8BJoBY7dq3 aUpuj7ZJFaKGyNEhe9U3IokilVMnb3lTqxaE68sCUlEO13tOfUf6WpAsMvjPA8Bz kqvzhGiX+EEQvickJL399V9uJaqZ6ykFe9tCLpwnhEbq8nHeBeQoqhghmF13n3BA cqRC3lzhwGRux48ttC6Pe6PipesLx2abMxT/r2OSnHJdwHK/glgUnvIosLemRXuG PXJW4H24Sl7NbzjiD67e0Wn32ciyrvHlnnIaS4kf7d0gqPMFmYGomd2AXDnA/C4= =pfKG -----END PGP SIGNATURE----- --jLkS94Qm9kPLdD8pDcbEMLdpAQiJME2Js-- From nobody Thu Dec 11 13:10:34 2014 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 B88A71A700F for ; Thu, 11 Dec 2014 13:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Q65YpE41nAS3 for ; Thu, 11 Dec 2014 13:10:30 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C25381A1A22 for ; Thu, 11 Dec 2014 13:10:29 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so4798224lbi.4 for ; Thu, 11 Dec 2014 13:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=be0DlKO/ujCGXbnzXMX3G7ENvekC4Kv+gwv8qCvcDso=; b=ZuEEEZ2p3G+oO+L16qF3HEpLO58M6n1akJu+o7d6Ht9ZuSrJKAwedjGFLW9d1d84wN hhHPrQ/bDovQtkpW2Qic2fR/fzcEi0QiOKJmhhj1dl6mwF8SnbOhNMYEFbq8PKw+Nkge /oEIwDRlgTLdkJxrpg1XSyiFqKjXyuYxd9C1JXhHVyW8zVLwnrT4bxdkUY2H9HqWzKAv jKDtdrOJ87dm+MtWBdMvE+9SoZMiC80Go7nfHi0XmIoOwdiXOdPb2jFUxn2MR8T+XUiZ /RylBlCweWN4pKxZGvvO7O8fMRpGxGa1eCoBBo3beFndHBWHckM8sYKjIRqB9T7IMRU7 RGXQ== MIME-Version: 1.0 X-Received: by 10.112.131.1 with SMTP id oi1mr4703616lbb.2.1418332228191; Thu, 11 Dec 2014 13:10:28 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Thu, 11 Dec 2014 13:10:28 -0800 (PST) In-Reply-To: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> Date: Thu, 11 Dec 2014 16:10:28 -0500 X-Google-Sender-Auth: Te4Xc98y5Az-f02YIYAP0mwLaRI Message-ID: From: Phillip Hallam-Baker To: Andrei Popov Content-Type: multipart/alternative; boundary=047d7b343106a28f520509f7344c Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/iMDnnDdZFrxtQDB635BOvhaQhDY Cc: John Bradley , "unbearable@ietf.org" , Stephen Farrell , Bill Mills , Phil Hunt Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 21:10:33 -0000 --047d7b343106a28f520509f7344c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Given that the principal constraint here is 'what else is going on', I think it is appropriate to look at mechanism. We are certainly looking to solve some of the problems that OAUTH does. That is OK with me provided that 1) we are addressing them in a different way and 2) the differences are more than syntax or a different selection of features. On Thu, Dec 11, 2014 at 3:01 PM, Andrei Popov wrote: > Protocol details, existing APIs, the use of TPM, etc. are all great > topics to discuss as we look at the proposals. I=E2=80=99d be very happy = to delve > into these. But I thought the guidance from the ADs was to discuss the > charter and set up the WG first? > > > > Thanks, > > > > Andrei > > > > *From:* hallam@gmail.com [mailto:hallam@gmail.com] *On Behalf Of *Phillip > Hallam-Baker > *Sent:* Thursday, December 11, 2014 11:33 AM > *To:* Andrei Popov > *Cc:* Bill Mills; Phil Hunt; John Bradley; unbearable@ietf.org; Stephen > Farrell > *Subject:* Re: [Unbearable] one proposal for a charter - please dicsuss > > > > > > > > On Thu, Dec 11, 2014 at 2:25 PM, Andrei Popov > wrote: > > Without binding, the cookie is relatively easy to export to a different > machine and replay to the server, impersonating the user. > > > > A cookie that=E2=80=99s bound to a key is useless, unless the attacker ca= n also > export the key (which is very difficult in the case of hardware-bound key= ). > > > > Agreed > > > > The use of asymmetric key pair means that the token binding key can be > generated in a hardware module, never exposed to local malware, plus the > private key is never transmitted across the network. > > > > They are exactly the same. Or rather they should be. The Windows API are > limited to asymmetric but that is due to a failure of imagination rather > than need. > > > > > > The most appropriate way to handle keys in my view is for the TPM to stor= e > just one key that is then used to unwrap tickets to obtain a symmetric or > asymmetric key as the need arises. This minimizes the amount of data that > the TPM needs to store. > > > > > > > --047d7b343106a28f520509f7344c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given that the principal constraint here is 'what else= is going on', I think it is appropriate to look at mechanism.

=
We are certainly looking to solve some of the problems that OAUT= H does. That is OK with me provided that 1) we are addressing them in a dif= ferent way and 2) the differences are more than syntax or a different selec= tion of features.

On Thu, Dec 11, 2014 at 3:01 PM, Andrei Popov <Andrei= .Popov@microsoft.com> wrote:

Protocol details, existing APIs, the = use of TPM, etc. are all great topics to discuss as we look at the proposal= s. I=E2=80=99d be very happy to delve into these. But I thought the guidance from the ADs was to discuss the charter and set up = the WG first?

=C2=A0

Thanks,

=C2=A0

Andrei

=C2=A0

From: hallam@gmail.com [mailto:hallam@gmail.com] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, December 11, 2014 11:33 AM
To: Andrei Popov
Cc: Bill Mills; Phil Hunt; John Bradley; unbearable@ietf.org; Stephen Farrell
Subject: Re: [Unbearable] one proposal for a charter - please dicsus= s

=C2=A0

=C2=A0

=C2=A0

On Thu, Dec 11, 2014 at 2:25 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

Without binding, the cookie is relati= vely easy to export to a different machine and replay to the server, impersonating the user.

=C2=A0

A cookie that=E2=80=99s bound to a ke= y is useless, unless the attacker can also export the key (which is very difficult in the case of hardware-bound key).

=C2=A0

Agreed

=C2=A0

The use of asymmetric key pair means = that the token binding key can be generated in a hardware module, never exposed to local malware, plus the private key is never transmitted = across the network.

=C2=A0

They are exactly the same. Or rather they should be.= The Windows API are limited to asymmetric but that is due to a failure of = imagination rather than need.

=C2=A0

=C2=A0

The most appropriate way to handle keys in my view i= s for the TPM to store just one key that is then used to unwrap tickets to = obtain a symmetric or asymmetric key as the need arises. This minimizes the= amount of data that the TPM needs to store.

=C2=A0

=C2=A0

=C2=A0


--047d7b343106a28f520509f7344c-- From nobody Thu Dec 11 14:01:37 2014 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 027EB1A0039 for ; Thu, 11 Dec 2014 14:01:35 -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 FrAmIuR4XYTJ for ; Thu, 11 Dec 2014 14:01: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 9F5891A000D for ; Thu, 11 Dec 2014 14:01:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 67545BEC4; Thu, 11 Dec 2014 22:01:30 +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 yPWfTotziJy7; Thu, 11 Dec 2014 22:01:29 +0000 (GMT) Received: from [192.168.2.162] (d8D873ACA.access.telenet.be [141.135.58.202]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AFAD1BDCB; Thu, 11 Dec 2014 22:01:28 +0000 (GMT) Message-ID: <548A1438.5050707@cs.tcd.ie> Date: Thu, 11 Dec 2014 22:01:28 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrei Popov , Phillip Hallam-Baker References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/5kmhEfXI_6U7li4QH08-sFTbb_Y Cc: John Bradley , "unbearable@ietf.org" , Bill Mills , Phil Hunt Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 22:01:35 -0000 On 11/12/14 20:01, Andrei Popov wrote: > Protocol details, existing APIs, the use of TPM, etc. are all great > topics to discuss as we look at the proposals. I’d be very happy to > delve into these. But I thought the guidance from the ADs was to > discuss the charter and set up the WG first? As I read it, I think people are trying to feel out the right scope and distinguish that from current work so some level of diving into detail should be expected (and hey, that's what we do and when did we ever manage to resist doing just that;-). For the particular question, I guess a symmetric solution would differ from an asymmetric one in a few ways that might impinge on scope, so highish level discussion of that should prove useful. But yes, the specific details of how one might protect a private/secret key are probably for later to the extent that they'd ever be part of the IETF work as opposed to the work for implementers. Hope that helps, S. > > Thanks, > > Andrei > > From: hallam@gmail.com [mailto:hallam@gmail.com] On Behalf Of Phillip > Hallam-Baker Sent: Thursday, December 11, 2014 11:33 AM To: Andrei > Popov Cc: Bill Mills; Phil Hunt; John Bradley; unbearable@ietf.org; > Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter > - please dicsuss > > > > On Thu, Dec 11, 2014 at 2:25 PM, Andrei Popov > > > wrote: Without binding, the cookie is relatively easy to export to a > different machine and replay to the server, impersonating the user. > > A cookie that’s bound to a key is useless, unless the attacker can > also export the key (which is very difficult in the case of > hardware-bound key). > > Agreed > > The use of asymmetric key pair means that the token binding key can > be generated in a hardware module, never exposed to local malware, > plus the private key is never transmitted across the network. > > They are exactly the same. Or rather they should be. The Windows API > are limited to asymmetric but that is due to a failure of imagination > rather than need. > > > The most appropriate way to handle keys in my view is for the TPM to > store just one key that is then used to unwrap tickets to obtain a > symmetric or asymmetric key as the need arises. This minimizes the > amount of data that the TPM needs to store. > > > > > > _______________________________________________ Unbearable mailing > list Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Thu Dec 11 14:34:56 2014 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 62CAD1A8A1B for ; Thu, 11 Dec 2014 14:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 6i8Pr2MzdkWM for ; Thu, 11 Dec 2014 14:34:52 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9114B1A87E0 for ; Thu, 11 Dec 2014 14:34:52 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBBMYjIk024676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Dec 2014 22:34:45 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sBBMYiD9009716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Dec 2014 22:34:44 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBBMYhvX023252; Thu, 11 Dec 2014 22:34:43 GMT Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Dec 2014 14:34:43 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Phil Hunt In-Reply-To: <548A01D8.7000107@gmx.net> Date: Thu, 11 Dec 2014 14:34:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <93BC7D25-7C16-4A8D-B303-4798D213D57A@oracle.com> References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> <20141211200049.GF3448@localhost> <548A01D8.7000107@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1993) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/lWN6fzqYTquHsw_MnjZN4Hz_P8c Cc: "unbearable@ietf.org" , Nico Williams , Andrei Popov , Phillip Hallam-Baker , Benjamin Kaduk Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss 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, 11 Dec 2014 22:34:54 -0000 This event in the press also heavily influenced the POP discussions on = symmetric vs. asymmetric: = http://www.programmableweb.com/news/why-attack-buffer-was-serious-wake-cal= l-web/analysis/2013/11/04 There was concern that symmetric keys could easily be stored with tokens = and likely will (as in the case of OAuth1). If the database is = compromised (as was the case in buffer.com), both the key and the tokens = are lost.=20 Asymmetric keys by their nature tend to have the private key kept = securely. Further, a client could use the same key-pair for multiple = separate access tokens issued to it by a service provider. This can = also get us away from the 1:1 key for token paradigm and leads to = something naturally more secure (meaning a developer has to work extra = hard to mess this up). Phil @independentid www.independentid.com phil.hunt@oracle.com > On Dec 11, 2014, at 12:43 PM, Hannes Tschofenig = wrote: >=20 > In OAuth we have explored more proposals. >=20 >=20 > Use Cases/Requirements/Architecture Document (currently in WGLC): > http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/ >=20 > These are the documents referenced: > http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ > http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/ > http://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/ >=20 > Ciao > Hannes >=20 >=20 > On 12/11/2014 09:24 PM, Andrei Popov wrote: >> The proposed charter suggests the following list of I-Ds as a = starting point for the new WG: >> - http://tools.ietf.org/html/draft-popov-token-binding-00; >> - http://tools.ietf.org/html/draft-balfanz-https-token-binding-00. >>=20 >> Andrei >>=20 >> -----Original Message----- >> From: Nico Williams [mailto:nico@cryptonector.com]=20 >> Sent: Thursday, December 11, 2014 12:01 PM >> To: Benjamin Kaduk >> Cc: Phillip Hallam-Baker; Andrei Popov; unbearable@ietf.org >> Subject: List of proposals? Re: one proposal for a charter - please = dicsuss >>=20 >> On Thu, Dec 11, 2014 at 02:19:35PM -0500, Benjamin Kaduk wrote: >>> On Thu, 11 Dec 2014, Phillip Hallam-Baker wrote: >>>> But this is a two party scheme. What benefit do we get from use of=20= >>>> public key here? >>>=20 >>> If I remember correctly, >>> http://tools.ietf.org/html/draft-balfanz-https-token-binding-00=20 >>> describes a scheme which is not two-party. >>=20 >> Is there a list of proposals to be discussed on this list? >>=20 >> Nico >>=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Thu Dec 11 15:20:30 2014 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 834DE1A899B for ; Thu, 11 Dec 2014 15:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 OQxj00ibqVHy for ; Thu, 11 Dec 2014 15:20:28 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10E41A017E for ; Thu, 11 Dec 2014 15:20:27 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id f15so5431363lbj.23 for ; Thu, 11 Dec 2014 15:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yJDIt/1xjJc+Y9U/WmZ7FyOES2/zQfQY5+bdu1f29po=; b=r0Dr3MVZlU/de1JSrmL3kBfm1BDf4DibWzUDDCta24msQNeYM7RPnUmVxbIHFEjsdq 7ewIsY63x9xOvQb8O/wD1TnXEc5EyABunaRAwp5YpydFz0lLHt3fgWzTZGM+j3LjOhTG Xrtm4xuLoPgtbUNcySwZkBfcxY6NaTLyWQuuJUPS8FfDH3aGCY6sdL3ZchqFPvaVSATC T5uJbTWRT4tN5x+YitMQf9bC+WI/b14b0+gzqcYc/M8ycqPnsOYr0D2SVozrzJudjL+I tbOj51agwKesWhj6bGCARX2gKVJCLSEuuk5oOPpX9H58nQjnD7ivLXQ9Zqt7JdMAZQA7 ReLQ== MIME-Version: 1.0 X-Received: by 10.153.11.170 with SMTP id ej10mr12505435lad.24.1418340026221; Thu, 11 Dec 2014 15:20:26 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.19.42 with HTTP; Thu, 11 Dec 2014 15:20:26 -0800 (PST) In-Reply-To: <93BC7D25-7C16-4A8D-B303-4798D213D57A@oracle.com> References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> <20141211200049.GF3448@localhost> <548A01D8.7000107@gmx.net> <93BC7D25-7C16-4A8D-B303-4798D213D57A@oracle.com> Date: Thu, 11 Dec 2014 18:20:26 -0500 X-Google-Sender-Auth: JH2KUlJFDa57m2jIqGeaVn8xLJA Message-ID: From: Phillip Hallam-Baker To: Phil Hunt Content-Type: multipart/alternative; boundary=001a113479146f0aea0509f905b6 Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/uh70WB1Str1SobY5JtCFF8b9PG0 Cc: "unbearable@ietf.org" , Nico Williams , Andrei Popov , Hannes Tschofenig , Benjamin Kaduk Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss 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, 11 Dec 2014 23:20:29 -0000 --001a113479146f0aea0509f905b6 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 11, 2014 at 5:34 PM, Phil Hunt wrote: > This event in the press also heavily influenced the POP discussions on > symmetric vs. asymmetric: > > > http://www.programmableweb.com/news/why-attack-buffer-was-serious-wake-call-web/analysis/2013/11/04 > > There was concern that symmetric keys could easily be stored with tokens > and likely will (as in the case of OAuth1). If the database is compromised > (as was the case in buffer.com), both the key and the tokens are lost. > > Asymmetric keys by their nature tend to have the private key kept > securely. Further, a client could use the same key-pair for multiple > separate access tokens issued to it by a service provider. This can also > get us away from the 1:1 key for token paradigm and leads to something > naturally more secure (meaning a developer has to work extra hard to mess > this up). > OK I concede the point if you don't have a TPM. If you do then you can play Kerberos ticket games which makes the two systems equivalent. These are pairwise secrets rather than a universal key so its not like when Gawker got rolled and my universal password for all the accounts I don't care about the asset being protected was disclosed. What I think it comes down to is the time between interactions. Do we want to do a public key interaction on every HTTP transaction? --001a113479146f0aea0509f905b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 11, 2014 at 5:34 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
This event in the pre= ss also heavily influenced the POP discussions on symmetric vs. asymmetric:=

http://www.programma= bleweb.com/news/why-attack-buffer-was-serious-wake-call-web/analysis/2013/1= 1/04

There was concern that symmetric keys could easily be stored with tokens an= d likely will (as in the case of OAuth1). If the database is compromised (a= s was the case in buffer.co= m), both the key and the tokens are lost.

Asymmetric keys by their nature tend to have the private key kept securely.= Further, a client could use the same key-pair for multiple separate access= tokens issued to it by a service provider.=C2=A0 This can also get us away= from the 1:1 key for token paradigm and leads to something naturally more = secure (meaning a developer has to work extra hard to mess this up).

OK I concede the point if you don't have = a TPM. If you do then you can play Kerberos ticket games which makes the tw= o systems equivalent.

These are pairwise secrets r= ather than a universal key so its not like when Gawker got rolled and my un= iversal password for all the accounts I don't care about the asset bein= g protected was disclosed.


What I t= hink it comes down to is the time between interactions. Do we want to do a = public key interaction on every HTTP transaction?=C2=A0
--001a113479146f0aea0509f905b6-- From nobody Thu Dec 11 15:36:41 2014 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 E86671A8ACC for ; Thu, 11 Dec 2014 15:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Z4pH5wNtjrt1 for ; Thu, 11 Dec 2014 15:36:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23241A8AAC for ; Thu, 11 Dec 2014 15:36:36 -0800 (PST) Received: from BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) by BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 23:36:14 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 23:36:13 +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.0031.000; Thu, 11 Dec 2014 23:36:12 +0000 From: Andrei Popov To: Phillip Hallam-Baker , Phil Hunt Thread-Topic: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss Thread-Index: AQHQFX02QqmMTuMzN0aHm7cnuEjJbJyK1THQgAAF8wCAAB8wgIAADMgAgAAAv2A= Date: Thu, 11 Dec 2014 23:36:12 +0000 Message-ID: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> <20141211200049.GF3448@localhost> <548A01D8.7000107@gmx.net> <93BC7D25-7C16-4A8D-B303-4798D213D57A@oracle.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::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(24454002)(111735001)(199003)(62966003)(77156002)(76576001)(4396001)(19609705001)(19580405001)(54206007)(31966008)(19580395003)(46102003)(64706001)(20776003)(551544002)(106356001)(99286002)(105586002)(106116001)(86612001)(54606007)(19625215002)(19617315012)(50986999)(76176999)(54356999)(101416001)(33656002)(102836002)(16236675004)(19300405004)(120916001)(68736005)(87936001)(2656002)(40100003)(93886004)(21056001)(122556002)(97736003)(92566001)(74316001)(86362001)(15975445007)(551934003)(561944003)(16601075003)(99396003)(107046002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12504F313C87C3E53A1A542A8C630BN3PR0301MB1250_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/He69gofL0AmL0md_kliaPc8F2lk Cc: Nico Williams , "unbearable@ietf.org" , Hannes Tschofenig , Benjamin Kaduk Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss 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, 11 Dec 2014 23:36:40 -0000 --_000_BN3PR0301MB12504F313C87C3E53A1A542A8C630BN3PR0301MB1250_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGN1cnJlbnQgVG9rZW4gQmluZGluZyBJLURzIGRvIG5vdCByZXF1aXJlIHB1YmxpYyBrZXkg b3BlcmF0aW9ucyBvbiBldmVyeSBIVFRQIHRyYW5zYWN0aW9uLg0KDQpJbiB0aGUg4oCcZmlzdC1w YXJ0eeKAnSBzY2VuYXJpbyAoSWRlbnRpdHkgUHJvdmlkZXIgZ2VuZXJhdGluZyBhIHNlY3VyaXR5 IHRva2VuIHRvIGJlIHByZXNlbnRlZCBiYWNrIHRvIHRoaXMgSWRlbnRpdHkgUHJvdmlkZXIpLCB0 aGUgY2xpZW50IHByb3ZlcyBwb3NzZXNzaW9uIG9mIHRoZSBwcml2YXRlIGtleSBvbmNlIHBlciBU TFMgaGFuZHNoYWtlLiBNdWx0aXBsZSByZXF1ZXN0cyB3aXRoaW4gdGhlIHNhbWUgVExTIGNvbm5l Y3Rpb24gZG8gbm90IHJlc3VsdCBpbiBtdWx0aXBsZSBwdWJsaWMga2V5IG9wZXJhdGlvbnMuDQoN CkluIHRoZSDigJxmZWRlcmF0aW9u4oCdIHNjZW5hcmlvIChJZGVudGl0eSBQcm92aWRlciBnZW5l cmF0aW5nIGEgc2VjdXJpdHkgdG9rZW4gZm9yIGEgUmVseWluZyBQYXJ0eSB0byBjb25zdW1lKSwg dGhlIGNsaWVudCBwcm92ZXMgcG9zc2Vzc2lvbiBvZiBvbmUgYWRkaXRpb25hbCBrZXkgcGVyIFJl bHlpbmcgUGFydHkuDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IGhhbGxhbUBnbWFpbC5j b20gW21haWx0bzpoYWxsYW1AZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUGhpbGxpcCBIYWxsYW0t QmFrZXINClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxMSwgMjAxNCAzOjIwIFBNDQpUbzogUGhp bCBIdW50DQpDYzogSGFubmVzIFRzY2hvZmVuaWc7IEFuZHJlaSBQb3BvdjsgTmljbyBXaWxsaWFt czsgQmVuamFtaW4gS2FkdWs7IHVuYmVhcmFibGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVW5i ZWFyYWJsZV0gTGlzdCBvZiBwcm9wb3NhbHM/IFJlOiBvbmUgcHJvcG9zYWwgZm9yIGEgY2hhcnRl ciAtIHBsZWFzZSBkaWNzdXNzDQoNCg0KDQpPbiBUaHUsIERlYyAxMSwgMjAxNCBhdCA1OjM0IFBN LCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbT4+IHdyb3RlOg0KVGhpcyBldmVudCBpbiB0aGUgcHJlc3MgYWxzbyBoZWF2aWx5IGluZmx1 ZW5jZWQgdGhlIFBPUCBkaXNjdXNzaW9ucyBvbiBzeW1tZXRyaWMgdnMuIGFzeW1tZXRyaWM6DQoN Cmh0dHA6Ly93d3cucHJvZ3JhbW1hYmxld2ViLmNvbS9uZXdzL3doeS1hdHRhY2stYnVmZmVyLXdh cy1zZXJpb3VzLXdha2UtY2FsbC13ZWIvYW5hbHlzaXMvMjAxMy8xMS8wNA0KDQpUaGVyZSB3YXMg Y29uY2VybiB0aGF0IHN5bW1ldHJpYyBrZXlzIGNvdWxkIGVhc2lseSBiZSBzdG9yZWQgd2l0aCB0 b2tlbnMgYW5kIGxpa2VseSB3aWxsIChhcyBpbiB0aGUgY2FzZSBvZiBPQXV0aDEpLiBJZiB0aGUg ZGF0YWJhc2UgaXMgY29tcHJvbWlzZWQgKGFzIHdhcyB0aGUgY2FzZSBpbiBidWZmZXIuY29tPGh0 dHA6Ly9idWZmZXIuY29tPiksIGJvdGggdGhlIGtleSBhbmQgdGhlIHRva2VucyBhcmUgbG9zdC4N Cg0KQXN5bW1ldHJpYyBrZXlzIGJ5IHRoZWlyIG5hdHVyZSB0ZW5kIHRvIGhhdmUgdGhlIHByaXZh dGUga2V5IGtlcHQgc2VjdXJlbHkuIEZ1cnRoZXIsIGEgY2xpZW50IGNvdWxkIHVzZSB0aGUgc2Ft ZSBrZXktcGFpciBmb3IgbXVsdGlwbGUgc2VwYXJhdGUgYWNjZXNzIHRva2VucyBpc3N1ZWQgdG8g aXQgYnkgYSBzZXJ2aWNlIHByb3ZpZGVyLiAgVGhpcyBjYW4gYWxzbyBnZXQgdXMgYXdheSBmcm9t IHRoZSAxOjEga2V5IGZvciB0b2tlbiBwYXJhZGlnbSBhbmQgbGVhZHMgdG8gc29tZXRoaW5nIG5h dHVyYWxseSBtb3JlIHNlY3VyZSAobWVhbmluZyBhIGRldmVsb3BlciBoYXMgdG8gd29yayBleHRy YSBoYXJkIHRvIG1lc3MgdGhpcyB1cCkuDQoNCk9LIEkgY29uY2VkZSB0aGUgcG9pbnQgaWYgeW91 IGRvbid0IGhhdmUgYSBUUE0uIElmIHlvdSBkbyB0aGVuIHlvdSBjYW4gcGxheSBLZXJiZXJvcyB0 aWNrZXQgZ2FtZXMgd2hpY2ggbWFrZXMgdGhlIHR3byBzeXN0ZW1zIGVxdWl2YWxlbnQuDQoNClRo ZXNlIGFyZSBwYWlyd2lzZSBzZWNyZXRzIHJhdGhlciB0aGFuIGEgdW5pdmVyc2FsIGtleSBzbyBp dHMgbm90IGxpa2Ugd2hlbiBHYXdrZXIgZ290IHJvbGxlZCBhbmQgbXkgdW5pdmVyc2FsIHBhc3N3 b3JkIGZvciBhbGwgdGhlIGFjY291bnRzIEkgZG9uJ3QgY2FyZSBhYm91dCB0aGUgYXNzZXQgYmVp bmcgcHJvdGVjdGVkIHdhcyBkaXNjbG9zZWQuDQoNCg0KV2hhdCBJIHRoaW5rIGl0IGNvbWVzIGRv d24gdG8gaXMgdGhlIHRpbWUgYmV0d2VlbiBpbnRlcmFjdGlvbnMuIERvIHdlIHdhbnQgdG8gZG8g YSBwdWJsaWMga2V5IGludGVyYWN0aW9uIG9uIGV2ZXJ5IEhUVFAgdHJhbnNhY3Rpb24/DQo= --_000_BN3PR0301MB12504F313C87C3E53A1A542A8C630BN3PR0301MB1250_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBjdXJyZW50IFRva2VuIEJpbmRpbmcg SS1EcyBkbyBub3QgcmVxdWlyZSBwdWJsaWMga2V5IG9wZXJhdGlvbnMgb24gZXZlcnkgSFRUUCB0 cmFuc2FjdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SW4gdGhlIOKAnGZpc3QtcGFydHnigJ0gc2NlbmFyaW8gKElkZW50aXR5IFByb3ZpZGVyIGdlbmVy YXRpbmcgYSBzZWN1cml0eSB0b2tlbiB0byBiZSBwcmVzZW50ZWQgYmFjayB0byB0aGlzIElkZW50 aXR5IFByb3ZpZGVyKSwgdGhlIGNsaWVudCBwcm92ZXMgcG9zc2Vzc2lvbiBvZiB0aGUNCiBwcml2 YXRlIGtleSBvbmNlIHBlciBUTFMgaGFuZHNoYWtlLiBNdWx0aXBsZSByZXF1ZXN0cyB3aXRoaW4g dGhlIHNhbWUgVExTIGNvbm5lY3Rpb24gZG8gbm90IHJlc3VsdCBpbiBtdWx0aXBsZSBwdWJsaWMg a2V5IG9wZXJhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JbiB0aGUg4oCcZmVkZXJhdGlvbuKAnSBzY2VuYXJpbyAoSWRlbnRpdHkgUHJvdmlkZXIgZ2Vu ZXJhdGluZyBhIHNlY3VyaXR5IHRva2VuIGZvciBhIFJlbHlpbmcgUGFydHkgdG8gY29uc3VtZSks IHRoZSBjbGllbnQgcHJvdmVzIHBvc3Nlc3Npb24gb2Ygb25lIGFkZGl0aW9uYWwga2V5DQogcGVy IFJlbHlpbmcgUGFydHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRy ZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gaGFsbGFtQGdtYWlsLmNvbSBbbWFpbHRvOmhhbGxhbUBnbWFpbC5jb21dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWxsaXAgSGFsbGFtLUJha2VyPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBEZWNlbWJlciAxMSwgMjAxNCAzOjIwIFBNPGJyPg0KPGI+VG86PC9iPiBQaGls IEh1bnQ8YnI+DQo8Yj5DYzo8L2I+IEhhbm5lcyBUc2Nob2ZlbmlnOyBBbmRyZWkgUG9wb3Y7IE5p Y28gV2lsbGlhbXM7IEJlbmphbWluIEthZHVrOyB1bmJlYXJhYmxlQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gTGlzdCBvZiBwcm9wb3NhbHM/IFJlOiBvbmUg cHJvcG9zYWwgZm9yIGEgY2hhcnRlciAtIHBsZWFzZSBkaWNzdXNzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBEZWMgMTEsIDIwMTQgYXQgNTozNCBQTSwgUGhpbCBIdW50ICZsdDs8 YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGls Lmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZXZlbnQgaW4gdGhlIHByZXNzIGFsc28gaGVh dmlseSBpbmZsdWVuY2VkIHRoZSBQT1AgZGlzY3Vzc2lvbnMgb24gc3ltbWV0cmljIHZzLiBhc3lt bWV0cmljOjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cucHJvZ3JhbW1hYmxld2ViLmNv bS9uZXdzL3doeS1hdHRhY2stYnVmZmVyLXdhcy1zZXJpb3VzLXdha2UtY2FsbC13ZWIvYW5hbHlz aXMvMjAxMy8xMS8wNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cucHJvZ3JhbW1hYmxld2Vi LmNvbS9uZXdzL3doeS1hdHRhY2stYnVmZmVyLXdhcy1zZXJpb3VzLXdha2UtY2FsbC13ZWIvYW5h bHlzaXMvMjAxMy8xMS8wNDwvYT48YnI+DQo8YnI+DQpUaGVyZSB3YXMgY29uY2VybiB0aGF0IHN5 bW1ldHJpYyBrZXlzIGNvdWxkIGVhc2lseSBiZSBzdG9yZWQgd2l0aCB0b2tlbnMgYW5kIGxpa2Vs eSB3aWxsIChhcyBpbiB0aGUgY2FzZSBvZiBPQXV0aDEpLiBJZiB0aGUgZGF0YWJhc2UgaXMgY29t cHJvbWlzZWQgKGFzIHdhcyB0aGUgY2FzZSBpbg0KPGEgaHJlZj0iaHR0cDovL2J1ZmZlci5jb20i IHRhcmdldD0iX2JsYW5rIj5idWZmZXIuY29tPC9hPiksIGJvdGggdGhlIGtleSBhbmQgdGhlIHRv a2VucyBhcmUgbG9zdC48YnI+DQo8YnI+DQpBc3ltbWV0cmljIGtleXMgYnkgdGhlaXIgbmF0dXJl IHRlbmQgdG8gaGF2ZSB0aGUgcHJpdmF0ZSBrZXkga2VwdCBzZWN1cmVseS4gRnVydGhlciwgYSBj bGllbnQgY291bGQgdXNlIHRoZSBzYW1lIGtleS1wYWlyIGZvciBtdWx0aXBsZSBzZXBhcmF0ZSBh Y2Nlc3MgdG9rZW5zIGlzc3VlZCB0byBpdCBieSBhIHNlcnZpY2UgcHJvdmlkZXIuJm5ic3A7IFRo aXMgY2FuIGFsc28gZ2V0IHVzIGF3YXkgZnJvbSB0aGUgMToxIGtleSBmb3IgdG9rZW4gcGFyYWRp Z20NCiBhbmQgbGVhZHMgdG8gc29tZXRoaW5nIG5hdHVyYWxseSBtb3JlIHNlY3VyZSAobWVhbmlu ZyBhIGRldmVsb3BlciBoYXMgdG8gd29yayBleHRyYSBoYXJkIHRvIG1lc3MgdGhpcyB1cCkuPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PSyBJIGNvbmNlZGUgdGhlIHBvaW50IGlmIHlvdSBkb24ndCBoYXZlIGEgVFBNLiBJZiB5b3Ug ZG8gdGhlbiB5b3UgY2FuIHBsYXkgS2VyYmVyb3MgdGlja2V0IGdhbWVzIHdoaWNoIG1ha2VzIHRo ZSB0d28gc3lzdGVtcyBlcXVpdmFsZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVzZSBhcmUgcGFpcndpc2Ugc2VjcmV0cyByYXRoZXIg dGhhbiBhIHVuaXZlcnNhbCBrZXkgc28gaXRzIG5vdCBsaWtlIHdoZW4gR2F3a2VyIGdvdCByb2xs ZWQgYW5kIG15IHVuaXZlcnNhbCBwYXNzd29yZCBmb3IgYWxsIHRoZSBhY2NvdW50cyBJIGRvbid0 IGNhcmUgYWJvdXQgdGhlIGFzc2V0IGJlaW5nIHByb3RlY3RlZCB3YXMgZGlzY2xvc2VkLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQg SSB0aGluayBpdCBjb21lcyBkb3duIHRvIGlzIHRoZSB0aW1lIGJldHdlZW4gaW50ZXJhY3Rpb25z LiBEbyB3ZSB3YW50IHRvIGRvIGEgcHVibGljIGtleSBpbnRlcmFjdGlvbiBvbiBldmVyeSBIVFRQ IHRyYW5zYWN0aW9uPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR0301MB12504F313C87C3E53A1A542A8C630BN3PR0301MB1250_-- From nobody Thu Dec 11 15:41:30 2014 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 56A011A1A86 for ; Thu, 11 Dec 2014 15:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 uJyzsLupL6k7 for ; Thu, 11 Dec 2014 15:41:27 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B41481A1A7F for ; Thu, 11 Dec 2014 15:41:27 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 7481F20202C; Thu, 11 Dec 2014 15:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=/VX2zS/eqjpF/g bHkSOctEUE2DE=; b=YPFNXpsrKZPHDid1/x9FpOZt6m85orZC1l/xiSCF0AcP4r tCzJeMmVax2+aQWXYC73Uuq/T3qt/TUI4+UR30TXhqzsjmlBm2G8QmS9frCmqshs BEKfPTJg113/BAlC/nBoaoMEHkKqvYgXe9IjV59dhuXuKbVvGXC2ytwwPQyEQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPA id E8D31202018; Thu, 11 Dec 2014 15:41:26 -0800 (PST) Date: Thu, 11 Dec 2014 17:41:26 -0600 From: Nico Williams To: Phillip Hallam-Baker Message-ID: <20141211234121.GL3448@localhost> References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> <20141211200049.GF3448@localhost> <548A01D8.7000107@gmx.net> <93BC7D25-7C16-4A8D-B303-4798D213D57A@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/C2bPu3jvKHbXALvHxN8eSF9GK4M Cc: Benjamin Kaduk , "unbearable@ietf.org" , Hannes Tschofenig , Andrei Popov , Phil Hunt Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss 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, 11 Dec 2014 23:41:28 -0000 On Thu, Dec 11, 2014 at 06:20:26PM -0500, Phillip Hallam-Baker wrote: > OK I concede the point if you don't have a TPM. If you do then you can play > Kerberos ticket games which makes the two systems equivalent. > > These are pairwise secrets rather than a universal key so its not like when > Gawker got rolled and my universal password for all the accounts I don't > care about the asset being protected was disclosed. > > What I think it comes down to is the time between interactions. Do we want > to do a public key interaction on every HTTP transaction? This is exactly the same sub-thread as we saw on the TLS list as to resumption and the OPTLS proposal. We'll probably reach similar conclusions. Nico -- From nobody Thu Dec 11 16:01:01 2014 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 730961A0387 for ; Wed, 10 Dec 2014 12:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 zkSLB2mHEfYN for ; Wed, 10 Dec 2014 12:45:08 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39841A0008 for ; Wed, 10 Dec 2014 12:45:07 -0800 (PST) Received: from BN3PR0301MB1249.namprd03.prod.outlook.com (25.161.207.25) by BN3PR0301MB1284.namprd03.prod.outlook.com (25.161.210.148) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 20:45:06 +0000 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.31.17; Wed, 10 Dec 2014 20:45:05 +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.0031.000; Wed, 10 Dec 2014 20:45:05 +0000 From: Andrei Popov To: Phillip Hallam-Baker Thread-Topic: [Unbearable] one proposal for a charter - please dicsuss Thread-Index: AQHQEz13HUkUpVDAykapHgbkfe3625yGWqQAgAAcnYCAABBeAIACxW9g Date: Wed, 10 Dec 2014 20:45:05 +0000 Message-ID: References: <54863200.4030600@cs.tcd.ie> 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::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1249;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249; x-forefront-prvs: 0421BF7135 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(377454003)(24454002)(54606007)(97736003)(21056001)(102836002)(92566001)(15975445007)(86362001)(106356001)(54356999)(76176999)(50986999)(31966008)(105586002)(106116001)(19300405004)(561944003)(101416001)(19625215002)(86612001)(16236675004)(110136001)(93886004)(19617315012)(120916001)(46102003)(68736005)(99396003)(64706001)(20776003)(54206007)(2656002)(62966003)(77156002)(4396001)(19580405001)(99286002)(33656002)(76576001)(122556002)(40100003)(107046002)(87936001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1249; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1250493B9AC52D6A34025B318C620BN3PR0301MB1250_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1284; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/izghrOzbd8JF4barHD5ik1MLtRQ X-Mailman-Approved-At: Thu, 11 Dec 2014 16:00:53 -0800 Cc: "unbearable@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 10 Dec 2014 20:45:10 -0000 --_000_BN3PR0301MB1250493B9AC52D6A34025B318C620BN3PR0301MB1250_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIE9uZSBvZiB0aGUgbWFpbiBjb25zdHJhaW50cyBvbiB0aGUgV2ViIGF1dGhlbnRpY2F0aW9u L2F1dGhvcml6YXRpb24gcHJvcG9zYWxzIGhhcyBiZWVuIHRoYXQgdGhleSBoYXZlIHRvIHdvcmsg d2l0aCBleGlzdGluZyBicm93c2Vycy4NClllcywgdGhpcyBpcyBhIHZhbGlkIGNvbnN0cmFpbnQs IGFuZCBpdCBkb2VzIGFmZmVjdCB0aGUgZGVzaWduIGNob2ljZXMuIFBlcmhhcHMgd2Ugc2hvdWxk IG1ha2UgdGhpcyBtb3JlIGV4cGxpY2l0IGluIHRoZSBjaGFydGVyLg0KDQpDaGVlcnMsDQoNCkFu ZHJlaQ0KDQpGcm9tOiBoYWxsYW1AZ21haWwuY29tIFttYWlsdG86aGFsbGFtQGdtYWlsLmNvbV0g T24gQmVoYWxmIE9mIFBoaWxsaXAgSGFsbGFtLUJha2VyDQpTZW50OiBNb25kYXksIERlY2VtYmVy IDgsIDIwMTQgNjoyMyBQTQ0KVG86IEFuZHJlaSBQb3Bvdg0KQ2M6IFN0ZXBoZW4gRmFycmVsbDsg dW5iZWFyYWJsZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBvbmUgcHJvcG9z YWwgZm9yIGEgY2hhcnRlciAtIHBsZWFzZSBkaWNzdXNzDQoNCg0KDQpPbiBNb24sIERlYyA4LCAy MDE0IGF0IDg6NTIgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208 bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpIaSBQaGlsbGlwLA0K DQoNCj4gIEluIHBhcnRpY3VsYXIgSSBkb24ndCB0aGluayB3ZSBhcmUgZ2V0dGluZyBhd2F5IGZy b20gYmVhcmVyIHRva2Vucywgd2UgYXJlIGp1c3QgaGlkaW5nIHRoZW0gZGlmZmVyZW50Lg0KDQpU aGUgVG9rZW4gQmluZGluZyBQcm90b2NvbCBJLUQ8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtcG9wb3YtdG9rZW4tYmluZGluZy0wMD4gcHJvdmlkZXMgYSBtZWNoYW5pc20gZm9yIGJp bmRpbmcgc2VjdXJpdHkgdG9rZW5zIHRvIHRoZSBUTFMgbGF5ZXIuIFdoZW4gYSBib3VuZCB0b2tl biBpcyBwcmVzZW50ZWQgdG8gYSBzZXJ2ZXIsIHRoZSBzZXJ2ZXIgdmVyaWZpZXMgdGhlIHRva2Vu IGJpbmRpbmcgYW5kIHJlamVjdHMgdGhlIHRva2VuIGlmIHRoZSBiaW5kaW5nIHZlcmlmaWNhdGlv biBmYWlscy4gVGhlcmVmb3JlLCBzdWNoIGJvdW5kIHRva2VucyBhcmUgbm90IGJlYXJlciB0b2tl bnM6IHRoZXkgYXJlIHJlc2lzdGFudCB0byBleHBvcnQgYW5kIHJlcGxheSBhdHRhY2tzLg0KDQoN Cj4gIFRoaXMgaXMgYSBkcmFmdCBJIGhhdmUgYmVlbiB3b3JraW5nIG9uIGZvciBhIHdoaWxlLiBJ dCBhbGxvd3MgYSB0b2tlbiB0byBiZSBib3VuZCB0byBhIEhUVFAvVExTIGNoYW5uZWwuDQoNCkkg YWdyZWUgdGhhdCB5b3VyIGRyYWZ0IGlzIGRlc2lnbmVkIHRvIHNvbHZlIGEgc2ltaWxhciBwcm9i bGVtLCBhbHRob3VnaCB0aGUgYXBwcm9hY2ggeW914oCZdmUgdGFrZW4gaXMgZGlmZmVyZW50IGlu IG11bHRpcGxlIHdheXMuIFdlIGNhbiBkaXNjdXNzIHRoZXNlIGRpZmZlcmVuY2VzLCBidXQgcGVy aGFwcyB3ZSBzaG91bGQgZmlyc3QgZm9jdXMgb24gZXN0YWJsaXNoaW5nIHRoZSBXRyBjaGFydGVy Lg0KDQoNCldlIGhhdmUgYSBsb3Qgb2YgZWZmb3J0cyBpbiB0aGlzIHNwYWNlLiBXaGF0IEkgdGhp bmsgZGlzdGluZ3Vpc2hlcyB0aGVtIGlzIHRoZSBpbnRlbmRlZCBzY29wZSBvZiB1c2UgYW5kIHdo aWNoIHBhcnRzIG9mIHRoZSBXZWIgaW5mcmFzdHJ1Y3R1cmUgaXQgaXMgcHJvcG9zZWQgdG8gY2hh bmdlLg0KDQpPbmUgb2YgdGhlIG1haW4gY29uc3RyYWludHMgb24gdGhlIFdlYiBhdXRoZW50aWNh dGlvbi9hdXRob3JpemF0aW9uIHByb3Bvc2FscyBoYXMgYmVlbiB0aGF0IHRoZXkgaGF2ZSB0byB3 b3JrIHdpdGggZXhpc3RpbmcgYnJvd3NlcnMuIEFjY2VwdGluZyB0aGF0IGNvbnN0cmFpbnQgbWVh bnMgYSBsb3QgbW9yZSBjb3JuZXIgY2FzZXMgdGhhdCBoYXZlIHRvIGJlIGNvbnNpZGVyZWQgYW5k IGEgd2Vha2VyIHJlc3VsdC4NCg0KQW5vdGhlciBiaWcgZGlmZmVyZW5jZSBpcyB3aGV0aGVyIGEg YmVhcmVyIHRva2VuIGhhcyB0byBiZSBodW1hbiBmcmllbmRseSBvciBub3QuIElmIHdlIGFyZSB0 YWxraW5nIGFib3V0IGNyZWRlbnRpYWxzIGdlbmVyYXRlZCBieSBtYWNoaW5lcyBmb3IgbWFjaGlu ZXMgdGhlbiB3ZSBjYW4gZ28gYWxsIDI1NiBiaXQgd2l0aG91dCBwZW5hbHR5LiBJZiB3ZSBoYXZl IHRvIGRlYWwgd2l0aCB1c2VycyB0aGVuIGl0IGdldHMgYSBsb3QgaGFyZGVyLg0KDQoNCg0KDQo= --_000_BN3PR0301MB1250493B9AC52D6A34025B318C620BN3PR0301MB1250_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE2MzUxNzY0 ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIwODU0 Mjg0MjQgLTM4MTU0MTM1MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5PbmUgb2YgdGhlIG1haW4gY29uc3RyYWludHMgb24g dGhlIFdlYiBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIHByb3Bvc2FscyBoYXMgYmVlbiB0 aGF0IHRoZXkgaGF2ZSB0byB3b3JrIHdpdGggZXhpc3RpbmcgYnJvd3NlcnMuPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZZXMsIHRoaXMgaXMgYSB2YWxp ZCBjb25zdHJhaW50LCBhbmQgaXQgZG9lcyBhZmZlY3QgdGhlIGRlc2lnbiBjaG9pY2VzLiBQZXJo YXBzIHdlIHNob3VsZCBtYWtlIHRoaXMgbW9yZSBleHBsaWNpdCBpbiB0aGUgY2hhcnRlci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBoYWxsYW1A Z21haWwuY29tIFttYWlsdG86aGFsbGFtQGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ UGhpbGxpcCBIYWxsYW0tQmFrZXI8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNlbWJlciA4 LCAyMDE0IDY6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlaSBQb3Bvdjxicj4NCjxiPkNjOjwv Yj4gU3RlcGhlbiBGYXJyZWxsOyB1bmJlYXJhYmxlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbVW5iZWFyYWJsZV0gb25lIHByb3Bvc2FsIGZvciBhIGNoYXJ0ZXIgLSBwbGVhc2Ug ZGljc3VzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRGVjIDgsIDIwMTQgYXQg ODo1MiBQTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkg UGhpbGxpcCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj7DmDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsgPC9zcGFuPg0KSW4gcGFydGljdWxhciBJIGRv bid0IHRoaW5rIHdlIGFyZSBnZXR0aW5nIGF3YXkgZnJvbSBiZWFyZXIgdG9rZW5zLCB3ZSBhcmUg anVzdCBoaWRpbmcgdGhlbSBkaWZmZXJlbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGUNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXBvcG92LXRva2VuLWJpbmRpbmctMDAiIHRhcmdldD0iX2JsYW5rIj4NClRva2VuIEJpbmRpbmcg UHJvdG9jb2wgSS1EPC9hPiBwcm92aWRlcyBhIG1lY2hhbmlzbSBmb3IgYmluZGluZyBzZWN1cml0 eSB0b2tlbnMgdG8gdGhlIFRMUyBsYXllci4gV2hlbiBhIGJvdW5kIHRva2VuIGlzIHByZXNlbnRl ZCB0byBhIHNlcnZlciwgdGhlIHNlcnZlciB2ZXJpZmllcyB0aGUgdG9rZW4gYmluZGluZyBhbmQg cmVqZWN0cyB0aGUgdG9rZW4gaWYgdGhlIGJpbmRpbmcgdmVyaWZpY2F0aW9uIGZhaWxzLiBUaGVy ZWZvcmUsIHN1Y2ggYm91bmQNCiB0b2tlbnMgYXJlIG5vdCBiZWFyZXIgdG9rZW5zOiB0aGV5IGFy ZSByZXNpc3RhbnQgdG8gZXhwb3J0IGFuZCByZXBsYXkgYXR0YWNrcy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6V2luZ2RpbmdzIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4m bmJzcDsgPC9zcGFuPg0KVGhpcyBpcyBhIGRyYWZ0IEkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gZm9y IGEgd2hpbGUuIEl0IGFsbG93cyBhIHRva2VuIHRvIGJlIGJvdW5kIHRvIGEgSFRUUC9UTFMgY2hh bm5lbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhh dCB5b3VyIGRyYWZ0IGlzIGRlc2lnbmVkIHRvIHNvbHZlIGEgc2ltaWxhciBwcm9ibGVtLCBhbHRo b3VnaCB0aGUgYXBwcm9hY2ggeW914oCZdmUgdGFrZW4NCiBpcyBkaWZmZXJlbnQgaW4gbXVsdGlw bGUgd2F5cy4gV2UgY2FuIGRpc2N1c3MgdGhlc2UgZGlmZmVyZW5jZXMsIGJ1dCBwZXJoYXBzIHdl IHNob3VsZCBmaXJzdCBmb2N1cyBvbiBlc3RhYmxpc2hpbmcgdGhlIFdHIGNoYXJ0ZXIuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSBoYXZlIGEgbG90IG9mIGVmZm9ydHMgaW4gdGhpcyBzcGFjZS4gV2hhdCBJ IHRoaW5rIGRpc3Rpbmd1aXNoZXMgdGhlbSBpcyB0aGUgaW50ZW5kZWQgc2NvcGUgb2YgdXNlIGFu ZCB3aGljaCBwYXJ0cyBvZiB0aGUgV2ViIGluZnJhc3RydWN0dXJlIGl0IGlzIHByb3Bvc2VkIHRv IGNoYW5nZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T25lIG9mIHRoZSBtYWluIGNvbnN0cmFpbnRzIG9uIHRoZSBXZWIgYXV0aGVudGljYXRp b24vYXV0aG9yaXphdGlvbiBwcm9wb3NhbHMgaGFzIGJlZW4gdGhhdCB0aGV5IGhhdmUgdG8gd29y ayB3aXRoIGV4aXN0aW5nIGJyb3dzZXJzLiBBY2NlcHRpbmcgdGhhdCBjb25zdHJhaW50IG1lYW5z IGEgbG90IG1vcmUgY29ybmVyIGNhc2VzIHRoYXQgaGF2ZSB0byBiZSBjb25zaWRlcmVkIGFuZCBh IHdlYWtlciByZXN1bHQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFub3RoZXIgYmlnIGRpZmZlcmVuY2UgaXMgd2hldGhlciBhIGJl YXJlciB0b2tlbiBoYXMgdG8gYmUgaHVtYW4gZnJpZW5kbHkgb3Igbm90LiBJZiB3ZSBhcmUgdGFs a2luZyBhYm91dCBjcmVkZW50aWFscyBnZW5lcmF0ZWQgYnkgbWFjaGluZXMgZm9yIG1hY2hpbmVz IHRoZW4gd2UgY2FuIGdvIGFsbCAyNTYgYml0IHdpdGhvdXQgcGVuYWx0eS4gSWYgd2UgaGF2ZSB0 byBkZWFsIHdpdGggdXNlcnMgdGhlbiBpdCBnZXRzDQogYSBsb3QgaGFyZGVyLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_BN3PR0301MB1250493B9AC52D6A34025B318C620BN3PR0301MB1250_-- From nobody Thu Dec 11 16:01:07 2014 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 9640A1A9073 for ; Wed, 10 Dec 2014 13:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ODOpJmW9qTXh for ; Wed, 10 Dec 2014 13:48:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E76A1A906E for ; Wed, 10 Dec 2014 13:47:59 -0800 (PST) Received: from BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) by BN3PR0301MB0882.namprd03.prod.outlook.com (25.160.155.144) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 21:47:37 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 10 Dec 2014 21:47:35 +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.0031.000; Wed, 10 Dec 2014 21:47:34 +0000 From: Andrei Popov To: Bill Mills , Phil Hunt , John Bradley , "unbearable@ietf.org" Thread-Topic: [Unbearable] New Non-WG Mailing List: unbearable Thread-Index: AQHQEMA9Qq53bvCSOEK2VbBv1auz8pyC8bZ/gANRHgCAAA92AIAABnwAgAA1poCAAs7jcA== Date: Wed, 10 Dec 2014 21:47:34 +0000 Message-ID: References: <0FFD8ED9-3AE4-4CB7-871B-00C7881EEF54@oracle.com> <1104038573.7012868.1418092171193.JavaMail.yahoo@jws10607.mail.bf1.yahoo.com> In-Reply-To: <1104038573.7012868.1418092171193.JavaMail.yahoo@jws10607.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 0421BF7135 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(189002)(13464003)(377454003)(199003)(24454002)(19625215002)(50986999)(76176999)(19617315012)(54606007)(33656002)(101416001)(102836002)(54356999)(86612001)(19300405004)(21056001)(105586002)(99286002)(106356001)(106116001)(92566001)(107046002)(86362001)(16601075003)(99396003)(2521001)(87936001)(15975445007)(68736005)(40100003)(120916001)(122556002)(16236675004)(2656002)(97736003)(54206007)(76576001)(2501002)(77156002)(62966003)(4396001)(31966008)(20776003)(19609705001)(19580405001)(64706001)(46102003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1250A9947D0173212E624F138C620BN3PR0301MB1250_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB0882; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/LxeXZrxTGBh39en9aPocYBiYeE8 X-Mailman-Approved-At: Thu, 11 Dec 2014 16:00:54 -0800 Cc: Mike Jones , Derek Atkins , Stephen Farrell Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable 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, 10 Dec 2014 21:48:07 -0000 --_000_BN3PR0301MB1250A9947D0173212E624F138C620BN3PR0301MB1250_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmlsbCwNCg0KDQrDmCAgSW4gdGhlIDIgZHJhZnRzIE1pa2UgSi4gcGFzdGVkIEkgZmluZCB0 aGUgdXNlIG9mIHRoZSB0ZXJtICJUTFMgQmluZGluZyIgY29uZnVzaW5nIGhlcmUgYmVjYXVzZSBp dCdzIGRhbmdlcm91c2x5IGNsb3NlIHRvICJDaGFubmVsIEJpbmRpbmciIHdoaWNoIGlzICpub3Qq IHdoYXQgdGhlc2UgZHJhZnRzIGFyZSB0YWxraW5nIGFib3V0Lg0KVGhlIHRlcm0g4oCcVExTIEJp bmRpbmfigJ0gaXMgbm90IHVzZWQgaW4gZWl0aGVyIG9mIHRoZSBUb2tlbiBCaW5kaW5nIEktRHMu IFRoZSB0ZXJtIOKAnFRva2VuIEJpbmRpbmfigJ0gd2FzIGNob3NlbiB0byBhdm9pZCBvdmVybG9h ZGluZyB0aGUgZXhpc3RpbmcgdGVybSDigJxDaGFubmVsIEJpbmRpbmfigJ0uDQoNCg0Kw5ggIEFy ZSB0aGVzZSBkcmFmdHMgaW50ZW5kZWQgdG8gYWxsb3cgYSB0cnVzdCByZWxhdGlvbnNoaXAgdG8g YmUgYnVpbHQgb24gdGhlIGNsaWVudCBzZWNyZXQgZXN0YWJsaXNoZWQgZHVyaW5nIGF1dGhlbnRp Y2F0aW9uLCBhbmQgdGhhdCBzZWNyZXQgaXMgdGhlbiB1c2VkIHRvIGJyaW5nIGNoYW5uZWwgYmlu ZGluZyBkb3duIGludG8gdGhlIEhUVFAgbGF5ZXI/DQpBdXRoZW50aWNhdGlvbiBpcyBvdXQgb2Yg dGhlIHNjb3BlIG9mIHRoZXNlIGRyYWZ0cy4gT25jZSBjbGllbnQgYXV0aGVudGljYXRpb24gaXMg Y29tcGxldGUsIHRoZSBzZXJ2ZXIgd2lsbCBvZnRlbiBpc3N1ZSBzZWN1cml0eSB0b2tlbnMgZm9y IHRoZSBjbGllbnQgdG8gcHJlc2VudCB0byB0aGlzIHNlcnZlciAob3Igb3RoZXIgc2VydmVycywg aW4gdGhlIGZlZGVyYXRpb24gY2FzZSkuIFRvZGF5LCB0aGVzZSB0b2tlbnMgY2FuIGJlIGludGVy Y2VwdGVkIG9yIGV4cG9ydGVkIGZyb20gdGhlIGNsaWVudCBtYWNoaW5lIGFuZCByZXBsYXllZCwg c28gdGhlIGF0dGFja2VyIGNhbiBpbXBlcnNvbmF0ZSBhIHZhbGlkIHVzZXIuIFRoZXNlIGRyYWZ0 cyBhbGxvdyB0aGUgc2VydmVyIHRvIGNyeXB0b2dyYXBoaWNhbGx5IGJpbmQgc2VjdXJpdHkgdG9r ZW5zIHRvIGEgKG5vbi1leHBvcnRhYmxlLCBlLmcuIEhXLWJvdW5kKSBrZXkgbWFpbnRhaW5lZCBi eSB0aGUgY2xpZW50LiBUaGUgY2xpZW50IHByb3ZlcyBwb3NzZXNzaW9uIG9mIHRoaXMga2V5IG9u IGV2ZXJ5IFRMUyBjb25uZWN0aW9uIHRvIHRoZSBzZXJ2ZXIsIHRoZXJlZm9yZSBvbmNlIHRoZSBz ZWN1cml0eSB0b2tlbiBpcyBwcmVzZW50ZWQsIHRoZSBzZXJ2ZXIgY2FuIHZlcmlmeSB0aGF0IGl0 IGNhbWUgZnJvbSB0aGUgY2xpZW50IHRoYXQgaXQgd2FzIGlzc3VlZCB0by4NCg0KQ2hlZXJzLA0K DQpBbmRyZWkNCg0KRnJvbTogQmlsbCBNaWxscyBbbWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5j b21dDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDgsIDIwMTQgNjozMCBQTQ0KVG86IFBoaWwgSHVu dDsgSm9obiBCcmFkbGV5OyB1bmJlYXJhYmxlQGlldGYub3JnDQpDYzogQW5kcmVpIFBvcG92OyBN aWtlIEpvbmVzOyBEZXJlayBBdGtpbnM7IFN0ZXBoZW4gRmFycmVsbA0KU3ViamVjdDogUmU6IFtV bmJlYXJhYmxlXSBOZXcgTm9uLVdHIE1haWxpbmcgTGlzdDogdW5iZWFyYWJsZQ0KDQpTcGxpdHRp bmcgd29yayBvbiBQT1AgdG9rZW5zIGJldHdlZW4gTj4xIFdHIGlzIGFsbW9zdCBjZXJ0YWlubHkg d3JvbmcgaWYgdGhhdCdzIHdoYXQgd2UncmUgZG9pbmcuDQoNCkluIHRoZSAyIGRyYWZ0cyBNaWtl IEouIHBhc3RlZCBJIGZpbmQgdGhlIHVzZSBvZiB0aGUgdGVybSAiVExTIEJpbmRpbmciIGNvbmZ1 c2luZyBoZXJlIGJlY2F1c2UgaXQncyBkYW5nZXJvdXNseSBjbG9zZSB0byAiQ2hhbm5lbCBCaW5k aW5nIiB3aGljaCBpcyAqbm90KiB3aGF0IHRoZXNlIGRyYWZ0cyBhcmUgdGFsa2luZyBhYm91dC4g IElmIHdlIGFyZSBpbiBmYWN0IGRvaW5nIGNoYW5uZWwgYmluZGluZyB0aGVuIHRoYXQncyB0aGUg dGVybSB3ZSBzaG91bGQgYmUgdXNpbmcuICBBcmUgdGhlc2UgZHJhZnRzIGludGVuZGVkIHRvIGFs bG93IGEgdHJ1c3QgcmVsYXRpb25zaGlwIHRvIGJlIGJ1aWx0IG9uIHRoZSBjbGllbnQgc2VjcmV0 IGVzdGFibGlzaGVkIGR1cmluZyBhdXRoZW50aWNhdGlvbiwgYW5kIHRoYXQgc2VjcmV0IGlzIHRo ZW4gdXNlZCB0byBicmluZyBjaGFubmVsIGJpbmRpbmcgZG93biBpbnRvIHRoZSBIVFRQIGxheWVy Pw0KDQoNCk9uIE1vbmRheSwgRGVjZW1iZXIgOCwgMjAxNCAzOjE4IFBNLCBQaGlsIEh1bnQgPHBo aWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0K DQpNYXliZSBhbGwgdG9rZW4gd29yayBzaG91bGQgYmUgdG9nZXRoZXIgaW4gaXRzIG93biBXRz8N Cg0KUGhpbA0KDQo+IE9uIERlYyA4LCAyMDE0LCBhdCAxNDo1NCwgSm9obiBCcmFkbGV5IDx2ZTdq dGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCj4NCj4gV2Ug ZGlkIGRpc2N1c3MgdGhpcyBhdCB0aGUgbGFzdCBJRVRGIG1lZXRpbmcuDQo+DQo+IFdoaWxlIHRo ZSB3b3JrIGlzIGNsb3NlbHkgcmVsYXRlZCB0byB0aGUgUG9QIHdvcmsgaW4gT0F1dGggaXQgaXMg bm90IHRoZSBzYW1lLiAgSXQgd2lsbCBhbGxvdyB1cyB0byBkbyBQb1AgdG9rZW5zIGZvciB0aGUg aW1wbGljaXQgZmxvdywgc29tZXRoaW5nIHRoYXQgd2UgaGF2ZW4ndCB0b3VjaGVkIHlldCBpbiBP QXV0aCBiZWNhdXNlIHdlIGRvbid0IGhhdmUgYSB3b3JrYWJsZSB3YXkgdG8gbWFuYWdlIGtleXMg aW4gdGhlIGJyb3dzZXIuICBUaGlzIHdvcmsgc2hvdWxkIGFsbG93IHVzIHRvIGRvIHRoYXQuDQo+ DQo+IEkgdGhpbmsgdGhlIHNsaWRlIGRlY2sgZXhhbXBsZXMgc2hvd2luZyBKV1QgdXNpbmcgZGlm ZmVyZW50IG1lY2hhbmlzbXMgdG8gZXhwcmVzcyBrZXlzIGZyb20gdGhlIHdvcmsgZG9uZSBpbiB0 aGUgT0F1dGggV0cgbWF5IGJlIHBhcnQgb2Ygd2hhdCBoYXMgc29tZSBwZW9wbGUgY29uY2VybmVk Lg0KPg0KPiBJIGRvbid0IHRoaW5rIHRoZXNlIHNwZWNzIG92ZXJsYXAgd2l0aCBPQXV0aCwgYnV0 IHdlIGRvIG5lZWQgdG8gYmUgbWluZGZ1bCBvZiBzY29wZSBjcmVlcC4gIEFzIEkgc3RhdGVkIGF0 IHRoZSBGMkYgd2UgbmVlZCB0byBoYXZlIHRoZSB0d28gZ3JvdXBzIHdvcmsgdG9nZXRoZXIsIHNv IHRoYXQgd2UgY2FuIGhhdmUgUG9QIHRva2VucyB2aWEgdGhlIGJyb3dzZXIuDQo+DQo+IEpvaG4g Qi4NCj4NCj4NCj4+IE9uIERlYyA4LCAyMDE0LCBhdCA2OjU4IFBNLCBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4+IHdyb3RlOg0KPj4NCj4+IEl0J3MgbXkgdW5kZXJzdGFuZGluZyB0aGF0ICJVbmJlYXJhYmxl IiBpcyBwYXJ0IG9mIGFuIGVmZm9ydCB0byBjcmVhdGUgYSBuZXcgd29ya2luZyBncm91cCBzY29w ZWQgdG8gd29yayBvbiBkZWxpdmVyYWJsZXMgYmFzZWQgdXBvbiB0aGVzZSBpbnB1dCBkb2N1bWVu dHM6DQo+Pg0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmFsZmFuei1odHRw cy10b2tlbi1iaW5kaW5nDQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wb3Bv di10b2tlbi1iaW5kaW5nDQo+Pg0KPj4gSSBkb24ndCB0aGluayB0aGF0IGl0IHdhcyBldmVyIGlu dGVuZGVkIHRvIGNvdmVyIGV2ZXJ5IGFzcGVjdCBvZiBwcm9vZi1vZi1wb3NzZXNzaW9uIGFuZCBz byB0aGVyZSdzIG5vdCBhY3R1YWxseSBhbnkgY29uZmxpY3Qgd2l0aCB0aGUgd29yayB3ZSdyZSBh bHJlYWR5IGRvaW5nIGluIE9BdXRoLiAgKE5vciBkb2VzIGl0IHNlZW0gdG8gbWUgdG8gYmUgcHJv ZHVjdGl2ZSB0byBhZGQgZXZlbiBtb3JlIGRvY3VtZW50cy1pbi1mbGlnaHQgdG8gdGhlIE9BdXRo IHdvcmtpbmcgZ3JvdXAgYXQgcHJlc2VudC4pDQo+Pg0KPj4gICAgICAgICAgICAgICAgQ2hlZXJz LA0KPj4gICAgICAgICAgICAgICAgLS0gTWlrZQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiBGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGll dGYub3JnPG1haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yg RGVyZWsgQXRraW5zDQo+PiBTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMDYsIDIwMTQgMTE6MjAg QU0NCj4+IFRvOiBpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPg0KPj4gQ2M6IEFu ZHJlaSBQb3BvdjsgdW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9y Zz47IFN0ZXBoZW4gRmFycmVsbA0KPj4gU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBOZXcgTm9u LVdHIE1haWxpbmcgTGlzdDogdW5iZWFyYWJsZQ0KPj4NCj4+IEhpLA0KPj4NCj4+IElFVEYgU2Vj cmV0YXJpYXQgPGlldGYtc2VjcmV0YXJpYXRAaWV0Zi5vcmc8bWFpbHRvOmlldGYtc2VjcmV0YXJp YXRAaWV0Zi5vcmc+PiB3cml0ZXM6DQo+Pg0KPj4+IEEgbmV3IElFVEYgbm9uLXdvcmtpbmcgZ3Jv dXAgZW1haWwgbGlzdCBoYXMgYmVlbiBjcmVhdGVkLg0KPj4+DQo+Pj4gTGlzdCBhZGRyZXNzOiB1 bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnPg0KPj4+IEFyY2hp dmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi91bmJlYXJhYmxlLw0KPj4+ IFRvIHN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJl YXJhYmxlDQo+Pj4NCj4+PiBQdXJwb3NlOg0KPj4+DQo+Pj4gVGhpcyBsaXN0IGlzIGZvciBkaXNj dXNzaW9uIG9mIHByb3Bvc2FscyBmb3IgZG9pbmcgYmV0dGVyIHRoYW4gYmVhcmVyDQo+Pj4gdG9r ZW5zIChlLmcuIEhUVFAgY29va2llcywgT0F1dGggdG9rZW5zIGV0Yy4pIGZvciB3ZWIgYXBwbGlj YXRpb25zLg0KPj4+IFRoZSBzcGVjaWZpYyBnb2FsIGlzIGNoYXJ0ZXJpbmcgYSBXRyBmb2N1c2Vk IG9uIHByZXZlbnRpbmcgc2VjdXJpdHkNCj4+PiB0b2tlbiBleHBvcnQgYW5kIHJlcGxheSBhdHRh Y2tzLg0KPj4NCj4+DQo+PiBUaGUgT0FVVEggV29ya2luZyBHcm91cCBpcyBhbHJlYWR5IChhbmQg aGFzIGJlZW4gZm9yIGEgd2hpbGUhKSBsb29raW5nIGludG8gImhvbGRlciBvZiBrZXkiIHByb3Rv Y29scyB0byBpbXByb3ZlIHVwb24gQmVhcmVyIFRva2Vucy4NCj4+DQo+PiBJIHdvdWxkIHN1Z2dl c3QgdGhhdCB0aGlzIHdvcmsgaGFwcGVuIHRoZXJlIGluc3RlYWQgb2YgY3JlYXRpbmcgYSB3aG9s ZSBuZXcgZ3JvdXAgZm9yIGl0Lg0KPj4NCj4+IC1kZXJlaw0KPj4NCj4+PiBGb3IgYWRkaXRpb25h bCBpbmZvcm1hdGlvbiwgcGxlYXNlIGNvbnRhY3QgdGhlIGxpc3QgYWRtaW5pc3RyYXRvcnMuDQo+ Pg0KPj4gLS0NCj4+ICAgICAgRGVyZWsgQXRraW5zICAgICAgICAgICAgICAgIDYxNy02MjMtMzc0 NQ0KPj4gICAgICBkZXJla0BpaHRmcC5jb208bWFpbHRvOmRlcmVrQGlodGZwLmNvbT4gICAgICAg ICAgICB3d3cuaWh0ZnAuY29tPGh0dHA6Ly93d3cuaWh0ZnAuY29tPg0KPj4gICAgICBDb21wdXRl ciBhbmQgSW50ZXJuZXQgU2VjdXJpdHkgQ29uc3VsdGFudA0KPj4NCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBVbmJlYXJhYmxlIG1haWxpbmcg bGlzdA0KPj4gVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZz4N Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZQ0KPj4N Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBV bmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KPj4gVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5i ZWFyYWJsZUBpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdW5iZWFyYWJsZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KPiBVbmJlYXJhYmxlQGlldGYu b3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJlYXJhYmxl QGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQoNCg== --_000_BN3PR0301MB1250A9947D0173212E624F138C620BN3PR0301MB1250_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjUwNzkwODk2ODsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQ3NzIwMDgxMiAtNjg2ODg2MTM4 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjpibGFjazt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEJp bGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkluIHRoZSAyIGRyYWZ0cyBNaWtlIEouIHBhc3Rl ZCBJIGZpbmQgdGhlIHVzZSBvZiB0aGUgdGVybSAmcXVvdDtUTFMgQmluZGluZyZxdW90OyBjb25m dXNpbmcgaGVyZSBiZWNhdXNlIGl0J3MgZGFuZ2Vyb3VzbHkgY2xvc2UgdG8gJnF1b3Q7Q2hhbm5l bCBCaW5kaW5nJnF1b3Q7IHdoaWNoIGlzICpub3QqDQogd2hhdCB0aGVzZSBkcmFmdHMgYXJlIHRh bGtpbmcgYWJvdXQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhlIHRlcm0g4oCcVExTIEJpbmRpbmfigJ0gaXMgbm90IHVzZWQgaW4gZWl0 aGVyIG9mIHRoZSBUb2tlbiBCaW5kaW5nIEktRHMuIFRoZSB0ZXJtIOKAnFRva2VuIEJpbmRpbmfi gJ0gd2FzIGNob3NlbiB0byBhdm9pZCBvdmVybG9hZGluZyB0aGUgZXhpc3RpbmcgdGVybSDigJxD aGFubmVsIEJpbmRpbmfigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibGFj ayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFyZSB0aGVzZSBkcmFm dHMgaW50ZW5kZWQgdG8gYWxsb3cgYSB0cnVzdCByZWxhdGlvbnNoaXAgdG8gYmUgYnVpbHQgb24g dGhlIGNsaWVudCBzZWNyZXQgZXN0YWJsaXNoZWQgZHVyaW5nIGF1dGhlbnRpY2F0aW9uLCBhbmQg dGhhdCBzZWNyZXQgaXMgdGhlbiB1c2VkDQogdG8gYnJpbmcgY2hhbm5lbCBiaW5kaW5nIGRvd24g aW50byB0aGUgSFRUUCBsYXllcj8mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BdXRoZW50aWNhdGlvbiBpcyBvdXQgb2YgdGhlIHNj b3BlIG9mIHRoZXNlIGRyYWZ0cy4gT25jZSBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgY29tcGxl dGUsIHRoZSBzZXJ2ZXIgd2lsbCBvZnRlbiBpc3N1ZSBzZWN1cml0eSB0b2tlbnMgZm9yIHRoZSBj bGllbnQgdG8gcHJlc2VudA0KIHRvIHRoaXMgc2VydmVyIChvciBvdGhlciBzZXJ2ZXJzLCBpbiB0 aGUgZmVkZXJhdGlvbiBjYXNlKS4gVG9kYXksIHRoZXNlIHRva2VucyBjYW4gYmUgaW50ZXJjZXB0 ZWQgb3IgZXhwb3J0ZWQgZnJvbSB0aGUgY2xpZW50IG1hY2hpbmUgYW5kIHJlcGxheWVkLCBzbyB0 aGUgYXR0YWNrZXIgY2FuIGltcGVyc29uYXRlIGEgdmFsaWQgdXNlci4gVGhlc2UgZHJhZnRzIGFs bG93IHRoZSBzZXJ2ZXIgdG8gY3J5cHRvZ3JhcGhpY2FsbHkgYmluZCBzZWN1cml0eQ0KIHRva2Vu cyB0byBhIChub24tZXhwb3J0YWJsZSwgZS5nLiBIVy1ib3VuZCkga2V5IG1haW50YWluZWQgYnkg dGhlIGNsaWVudC4gVGhlIGNsaWVudCBwcm92ZXMgcG9zc2Vzc2lvbiBvZiB0aGlzIGtleSBvbiBl dmVyeSBUTFMgY29ubmVjdGlvbiB0byB0aGUgc2VydmVyLCB0aGVyZWZvcmUgb25jZSB0aGUgc2Vj dXJpdHkgdG9rZW4gaXMgcHJlc2VudGVkLCB0aGUgc2VydmVyIGNhbiB2ZXJpZnkgdGhhdCBpdCBj YW1lIGZyb20gdGhlIGNsaWVudCB0aGF0DQogaXQgd2FzIGlzc3VlZCB0by48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gQmlsbCBNaWxscyBbbWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBEZWNlbWJlciA4LCAyMDE0IDY6MzAgUE08 YnI+DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudDsgSm9obiBCcmFkbGV5OyB1bmJlYXJhYmxlQGlldGYu b3JnPGJyPg0KPGI+Q2M6PC9iPiBBbmRyZWkgUG9wb3Y7IE1pa2UgSm9uZXM7IERlcmVrIEF0a2lu czsgU3RlcGhlbiBGYXJyZWxsPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0g TmV3IE5vbi1XRyBNYWlsaW5nIExpc3Q6IHVuYmVhcmFibGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MTgwODYzMzI4NDBfMjg4NTUiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPlNwbGl0dGluZyB3b3JrIG9uIFBPUCB0b2tlbnMgYmV0d2VlbiBO Jmd0OzEgV0cgaXMgYWxtb3N0IGNlcnRhaW5seSB3cm9uZyBpZiB0aGF0J3Mgd2hhdCB3ZSdyZSBk b2luZy4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlf M18xNl8wXzFfMTQxODA4NjMzMjg0MF8yODg1NSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQx ODA4NjMzMjg0MF8yODg1NSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SW4gdGhlIDIgZHJhZnRzIE1p a2UgSi4gcGFzdGVkIEkgZmluZCB0aGUgdXNlIG9mIHRoZSB0ZXJtICZxdW90O1RMUyBCaW5kaW5n JnF1b3Q7IGNvbmZ1c2luZyBoZXJlIGJlY2F1c2UgaXQncyBkYW5nZXJvdXNseSBjbG9zZSB0byAm cXVvdDtDaGFubmVsIEJpbmRpbmcmcXVvdDsNCiB3aGljaCBpcyAqbm90KiB3aGF0IHRoZXNlIGRy YWZ0cyBhcmUgdGFsa2luZyBhYm91dC4gJm5ic3A7SWYgd2UgYXJlIGluIGZhY3QgZG9pbmcgY2hh bm5lbCBiaW5kaW5nIHRoZW4gdGhhdCdzIHRoZSB0ZXJtIHdlIHNob3VsZCBiZSB1c2luZy4gJm5i c3A7QXJlIHRoZXNlIGRyYWZ0cyBpbnRlbmRlZCB0byBhbGxvdyBhIHRydXN0IHJlbGF0aW9uc2hp cCB0byBiZSBidWlsdCBvbiB0aGUgY2xpZW50IHNlY3JldCBlc3RhYmxpc2hlZCBkdXJpbmcgYXV0 aGVudGljYXRpb24sDQogYW5kIHRoYXQgc2VjcmV0IGlzIHRoZW4gdXNlZCB0byBicmluZyBjaGFu bmVsIGJpbmRpbmcgZG93biBpbnRvIHRoZSBIVFRQIGxheWVyPyZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MTgwODYzMzI4NDBfMjg4 NTUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MTgwODYzMzI4NDBfMjg4NTUiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0ieXVpXzNfMTZfMF8xXzE0MTgwODYzMzI4NDBfMjg4MzEiPg0KPGRpdiBpZD0ieXVpXzNfMTZf MF8xXzE0MTgwODYzMzI4NDBfMjg4MzAiPg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MTgwODYz MzI4NDBfMjg4MjkiPg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MTgwODYzMzI4NDBfMjg4MzMi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPk9uIE1vbmRheSwgRGVjZW1iZXIgOCwgMjAxNCAzOjE4IFBNLCBQ aGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5o dW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDE4MDg2MzMyODQw XzI4ODI4Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk1heWJlIGFsbCB0b2tlbiB3b3JrIHNo b3VsZCBiZSB0b2dldGhlciBpbiBpdHMgb3duIFdHPzxicj4NCjxicj4NClBoaWw8YnI+DQo8YnI+ DQomZ3Q7IE9uIERlYyA4LCAyMDE0LCBhdCAxNDo1NCwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVm PSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlIGRpZCBkaXNjdXNzIHRoaXMgYXQgdGhlIGxhc3Qg SUVURiBtZWV0aW5nLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGlsZSB0aGUgd29yayBpcyBjbG9z ZWx5IHJlbGF0ZWQgdG8gdGhlIFBvUCB3b3JrIGluIE9BdXRoIGl0IGlzIG5vdCB0aGUgc2FtZS4m bmJzcDsgSXQgd2lsbCBhbGxvdyB1cyB0byBkbyBQb1AgdG9rZW5zIGZvciB0aGUgaW1wbGljaXQg Zmxvdywgc29tZXRoaW5nIHRoYXQgd2UgaGF2ZW4ndCB0b3VjaGVkIHlldCBpbiBPQXV0aCBiZWNh dXNlIHdlIGRvbid0IGhhdmUgYSB3b3JrYWJsZSB3YXkgdG8gbWFuYWdlIGtleXMgaW4gdGhlIGJy b3dzZXIuJm5ic3A7IFRoaXMNCiB3b3JrIHNob3VsZCBhbGxvdyB1cyB0byBkbyB0aGF0Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBJIHRoaW5rIHRoZSBzbGlkZSBkZWNrIGV4YW1wbGVzIHNob3dpbmcg SldUIHVzaW5nIGRpZmZlcmVudCBtZWNoYW5pc21zIHRvIGV4cHJlc3Mga2V5cyBmcm9tIHRoZSB3 b3JrIGRvbmUgaW4gdGhlIE9BdXRoIFdHIG1heSBiZSBwYXJ0IG9mIHdoYXQgaGFzIHNvbWUgcGVv cGxlIGNvbmNlcm5lZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBkb24ndCB0aGluayB0aGVzZSBz cGVjcyBvdmVybGFwIHdpdGggT0F1dGgsIGJ1dCB3ZSBkbyBuZWVkIHRvIGJlIG1pbmRmdWwgb2Yg c2NvcGUgY3JlZXAuJm5ic3A7IEFzIEkgc3RhdGVkIGF0IHRoZSBGMkYgd2UgbmVlZCB0byBoYXZl IHRoZSB0d28gZ3JvdXBzIHdvcmsgdG9nZXRoZXIsIHNvIHRoYXQgd2UgY2FuIGhhdmUgUG9QIHRv a2VucyB2aWEgdGhlIGJyb3dzZXIuJm5ic3A7DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSm9obiBC Ljxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBPbiBEZWMgOCwgMjAxNCwgYXQg Njo1OCBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSIgaWQ9Inl1aV8zXzE2XzBfMV8xNDE4MDg2MzMyODQwXzQwNjUzIj5NaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyBJdCdzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCAmcXVvdDtVbmJlYXJhYmxlJnF1b3Q7 IGlzIHBhcnQgb2YgYW4gZWZmb3J0IHRvIGNyZWF0ZSBhIG5ldyB3b3JraW5nIGdyb3VwIHNjb3Bl ZCB0byB3b3JrIG9uIGRlbGl2ZXJhYmxlcyBiYXNlZCB1cG9uIHRoZXNlIGlucHV0IGRvY3VtZW50 czo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1iYWxmYW56LWh0dHBzLXRva2VuLWJpbmRpbmciIHRhcmdldD0iX2Js YW5rIiBpZD0ieXVpXzNfMTZfMF8xXzE0MTgwODYzMzI4NDBfMzQxMjkiPg0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYmFsZmFuei1odHRwcy10b2tlbi1iaW5kaW5nPC9hPjxicj4N CiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBvcG92 LXRva2VuLWJpbmRpbmciIHRhcmdldD0iX2JsYW5rIiBpZD0ieXVpXzNfMTZfMF8xXzE0MTgwODYz MzI4NDBfMzQxMjgiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcG9wb3YtdG9r ZW4tYmluZGluZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJIGRvbid0IHRoaW5r IHRoYXQgaXQgd2FzIGV2ZXIgaW50ZW5kZWQgdG8gY292ZXIgZXZlcnkgYXNwZWN0IG9mIHByb29m LW9mLXBvc3Nlc3Npb24gYW5kIHNvIHRoZXJlJ3Mgbm90IGFjdHVhbGx5IGFueSBjb25mbGljdCB3 aXRoIHRoZSB3b3JrIHdlJ3JlIGFscmVhZHkgZG9pbmcgaW4gT0F1dGguJm5ic3A7IChOb3IgZG9l cyBpdCBzZWVtIHRvIG1lIHRvIGJlIHByb2R1Y3RpdmUgdG8gYWRkIGV2ZW4gbW9yZSBkb2N1bWVu dHMtaW4tZmxpZ2h0IHRvIHRoZQ0KIE9BdXRoIHdvcmtpbmcgZ3JvdXAgYXQgcHJlc2VudC4pPGJy Pg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0gTWlrZTxicj4N CiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K Jmd0OyZndDsgRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1bmJlYXJh YmxlLWJvdW5jZXNAaWV0Zi5vcmciPnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u IEJlaGFsZiBPZiBEZXJlayBBdGtpbnM8YnI+DQomZ3Q7Jmd0OyBTZW50OiBTYXR1cmRheSwgRGVj ZW1iZXIgMDYsIDIwMTQgMTE6MjAgQU08YnI+DQomZ3Q7Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRv OmlldGZAaWV0Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgQ2M6IEFuZHJl aSBQb3BvdjsgPGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciPnVuYmVhcmFibGVA aWV0Zi5vcmc8L2E+OyBTdGVwaGVuIEZhcnJlbGw8YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTog W1VuYmVhcmFibGVdIE5ldyBOb24tV0cgTWFpbGluZyBMaXN0OiB1bmJlYXJhYmxlPGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgSGksPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSUVU RiBTZWNyZXRhcmlhdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGYtc2VjcmV0YXJpYXRAaWV0Zi5v cmciPmlldGYtc2VjcmV0YXJpYXRAaWV0Zi5vcmc8L2E+Jmd0OyB3cml0ZXM6PGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEEgbmV3IElFVEYgbm9uLXdvcmtpbmcgZ3JvdXAgZW1haWwg bGlzdCBoYXMgYmVlbiBjcmVhdGVkLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn dDsgTGlzdCBhZGRyZXNzOiA8YSBocmVmPSJtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyI+dW5i ZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgQXJjaGl2ZTogPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3VuYmVhcmFibGUvIiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdW5iZWFyYWJs ZS88L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IFRvIHN1YnNjcmliZTogPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PGJy Pg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBQdXJwb3NlOjxicj4NCiZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgVGhpcyBsaXN0IGlzIGZvciBkaXNjdXNzaW9uIG9mIHBy b3Bvc2FscyBmb3IgZG9pbmcgYmV0dGVyIHRoYW4gYmVhcmVyIDxicj4NCiZndDsmZ3Q7Jmd0OyB0 b2tlbnMgKGUuZy4gSFRUUCBjb29raWVzLCBPQXV0aCB0b2tlbnMgZXRjLikgZm9yIHdlYiBhcHBs aWNhdGlvbnMuIDxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgc3BlY2lmaWMgZ29hbCBpcyBjaGFydGVy aW5nIGEgV0cgZm9jdXNlZCBvbiBwcmV2ZW50aW5nIHNlY3VyaXR5IDxicj4NCiZndDsmZ3Q7Jmd0 OyB0b2tlbiBleHBvcnQgYW5kIHJlcGxheSBhdHRhY2tzLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoZSBPQVVUSCBXb3JraW5nIEdyb3VwIGlzIGFscmVhZHkg KGFuZCBoYXMgYmVlbiBmb3IgYSB3aGlsZSEpIGxvb2tpbmcgaW50byAmcXVvdDtob2xkZXIgb2Yg a2V5JnF1b3Q7IHByb3RvY29scyB0byBpbXByb3ZlIHVwb24gQmVhcmVyIFRva2Vucy48YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJIHdvdWxkIHN1Z2dlc3QgdGhhdCB0aGlzIHdvcmsgaGFw cGVuIHRoZXJlIGluc3RlYWQgb2YgY3JlYXRpbmcgYSB3aG9sZSBuZXcgZ3JvdXAgZm9yIGl0Ljxi cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IC1kZXJlazxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyBGb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiwgcGxlYXNlIGNvbnRhY3QgdGhl IGxpc3QgYWRtaW5pc3RyYXRvcnMuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgLS0gPGJy Pg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBEZXJlayBBdGtpbnMmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDYxNy02MjMtMzc0NTxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmRlcmVrQGlo dGZwLmNvbSI+ZGVyZWtAaWh0ZnAuY29tPC9hPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWh0ZnAuY29tIj4NCnd3dy5paHRmcC5j b208L2E+PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBDb21wdXRlciBhbmQgSW50 ZXJuZXQgU2VjdXJpdHkgQ29uc3VsdGFudDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZn dDsgVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86 VW5iZWFyYWJsZUBpZXRmLm9yZyI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFi bGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3VuYmVhcmFibGU8L2E+PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBVbmJlYXJh YmxlIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxl QGlldGYub3JnIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJs ZTwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyA8YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyI+VW5iZWFyYWJsZUBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFibGUgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciPlVuYmVhcmFi bGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR0301MB1250A9947D0173212E624F138C620BN3PR0301MB1250_-- From nobody Thu Dec 11 16:01:09 2014 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 8A6931ACD0F for ; Wed, 10 Dec 2014 16:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 RMYzgSPRfFLN for ; Wed, 10 Dec 2014 16:12:42 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF8F1ACD0C for ; Wed, 10 Dec 2014 16:12:41 -0800 (PST) Received: from BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) by BN3PR0301MB1282.namprd03.prod.outlook.com (25.161.210.146) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 00:12:40 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.31.17; Thu, 11 Dec 2014 00:12:38 +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.0031.000; Thu, 11 Dec 2014 00:12:38 +0000 From: Andrei Popov To: John Bradley , Phillip Hallam-Baker Thread-Topic: [Unbearable] one proposal for a charter - please dicsuss Thread-Index: AQHQEz13HUkUpVDAykapHgbkfe3625yGWqQAgAAcnYCAABBeAIACxW9ggAAn+4CAAAMvgIAADicA Date: Thu, 11 Dec 2014 00:12:38 +0000 Message-ID: References: <54863200.4030600@cs.tcd.ie> 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::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1251;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(24454002)(199003)(76576001)(77156002)(62966003)(54206007)(97736003)(4396001)(46102003)(19580395003)(31966008)(64706001)(19580405001)(20776003)(19609705001)(21056001)(19300405004)(551544002)(86612001)(106356001)(106116001)(99286002)(105586002)(54606007)(19625215002)(19617315012)(76176999)(50986999)(54356999)(101416001)(33656002)(102836002)(15975445007)(68736005)(40100003)(74316001)(87936001)(16236675004)(2656002)(120916001)(122556002)(93886004)(92566001)(86362001)(99396003)(561944003)(107046002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1250157478D9414F79B27D4F8C630BN3PR0301MB1250_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1282; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/CuI7Rqpk0EJlDloCAtj9N83YltU X-Mailman-Approved-At: Thu, 11 Dec 2014 16:00:55 -0800 Cc: "unbearable@ietf.org" , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 11 Dec 2014 00:12:46 -0000 --_000_BN3PR0301MB1250157478D9414F79B27D4F8C630BN3PR0301MB1250_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGN1cnJlbnQgSS1EcyBkbyBwcm9wb3NlIGEgY2hhbmdlIGluIHRoZSBIVFRQIHN0YWNrIChu ZXcgSFRUUCBoZWFkZXJzKS4gQnV0IEkgdGhpbmsgaXQgaXMgYSB2YWxpZCByZXF1aXJlbWVudCB0 aGF0IHdoYXRldmVyIHNvbHV0aW9uIHdlIGFycml2ZSBhdCBtdXN0IHdvcmsgZm9yIFdlYiBicm93 c2Vycy4gRS5nLiB0aGlzIG1lYW5zIHRoYXQgc2VjdXJpdHkgdG9rZW5zIG11c3QgYmUgcHJlc2Vu dGFibGUgb3ZlciBtdWx0aXBsZSBUTFMgc2Vzc2lvbnMgYW5kIGNvbm5lY3Rpb25zLCBldGMuDQoN CkZyb206IEpvaG4gQnJhZGxleSBbbWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tXQ0KU2VudDogV2Vk bmVzZGF5LCBEZWNlbWJlciAxMCwgMjAxNCAzOjE3IFBNDQpUbzogUGhpbGxpcCBIYWxsYW0tQmFr ZXINCkNjOiBBbmRyZWkgUG9wb3Y7IHVuYmVhcmFibGVAaWV0Zi5vcmc7IFN0ZXBoZW4gRmFycmVs bA0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBvbmUgcHJvcG9zYWwgZm9yIGEgY2hhcnRlciAt IHBsZWFzZSBkaWNzdXNzDQoNCkFzIEkgdW5kZXJzdGFuZCBpdCB0aGlzIGlzIHByb3Bvc2luZyBh IGNoYW5nZSB0byBicm93c2Vycy4gIEJyb3dzZXJzIHdpbGwgbmVlZCB0byBiZSB1cGRhdGVkLiAg VGhlcmUgaXMgYSBwcmUgc3RhbmRhcmQgdmVyc2lvbiBvZiB0aGlzIGluIENocm9tZSBub3cgYnV0 IGV2ZW4gdGhhdCB3b3VsZCBuZWVkIHRvIGNoYW5nZS4NCg0KSSBkb27igJl0IHRoaW5rIHRoaXMg V0cgaXMgY29uc2lkZXJpbmcgYW55dGhpbmcgdGhhdCB3b3VsZCB3b3JrIHdpdGggYSBjdXJyZW50 IGJyb3dzZXIuDQoNClRoYXQgaXMgd2h5IEkgZG9u4oCZdCB0aGluayBpdCBvdmVybGFwcyB3aXRo IGN1cnJlbnQgT0F1dGggd29yayB1c2luZyBzdGF0aWMgY2xpZW50IGtleXMuDQoNCkpvaG4gQi4N Cg0KT24gRGVjIDEwLCAyMDE0LCBhdCAxMTowNSBQTSwgUGhpbGxpcCBIYWxsYW0tQmFrZXIgPHBo aWxsQGhhbGxhbWJha2VyLmNvbTxtYWlsdG86cGhpbGxAaGFsbGFtYmFrZXIuY29tPj4gd3JvdGU6 DQoNCk9uIFdlZCwgRGVjIDEwLCAyMDE0IGF0IDM6NDUgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQo+ICBPbmUgb2YgdGhlIG1haW4gY29uc3RyYWludHMgb24gdGhlIFdlYiBhdXRoZW50 aWNhdGlvbi9hdXRob3JpemF0aW9uIHByb3Bvc2FscyBoYXMgYmVlbiB0aGF0IHRoZXkgaGF2ZSB0 byB3b3JrIHdpdGggZXhpc3RpbmcgYnJvd3NlcnMuDQpZZXMsIHRoaXMgaXMgYSB2YWxpZCBjb25z dHJhaW50LCBhbmQgaXQgZG9lcyBhZmZlY3QgdGhlIGRlc2lnbiBjaG9pY2VzLiBQZXJoYXBzIHdl IHNob3VsZCBtYWtlIHRoaXMgbW9yZSBleHBsaWNpdCBpbiB0aGUgY2hhcnRlci4NCg0KV2hhdCBp cyB0aGUgZGVzaWduIHNwYWNlIGhlcmU/IEFyZSB3ZSBmaXR0aW5nIGludG8gZXhpc3RpbmcgYnJv d3NlcnMgb3Igbm90Pw0KDQpJIGFtIHJhdGhlciBmZWQgdXAgb2YgdGhlIGlkZWEgdGhhdCB3ZSBu ZXZlciBldmVyIGNvbnNpZGVyIGRvaW5nIHRoZSBqb2IgcmlnaHQuIFllcyBpdCBtaWdodCB0YWtl IHRlbiB5ZWFycyBiZWZvcmUgd2UgcmVhY2ggOTUlIHBlbmV0cmF0aW9uIGJ1dCB3ZSBjYW4gZ2V0 IHRvIDMwJSBpbiBvbmUgQ2hyb21lIHJlbGVhc2UgY3ljbGUuIFdpdGggV2luZG93cyAxMCB3ZSBj YW4gZXhwZWN0IHNvbWV0aGluZyBsaWtlIDgwJSBvZiB0aGUgYnJvd3NlcnMgdG8gYmUgb24gYXV0 b21hdGljIHVwZGF0ZS4NCg0KQW5kIHdlIGRpZCBTQU1MIHRlbiB5ZWFycyBhZ28gbm93LiBUaGlu ayBvZiB3aGVyZSB3ZSBtaWdodCBiZSBub3cgaGFkIHdlIGRvbmUgYSBjbGVhbiBpbXBsZW1lbnRh dGlvbiBhbG9uZyBzaWRlIHRoZSBsZWdhY3kgcHJlc2VydmluZyB0aGVuLg0KDQoNCldlIGRvbid0 IG5lZWQgdG8gbWFrZSBhIGxlYXAgaW4gdGhlIGRhcmsgaGVyZSBlaXRoZXIuIFdlYiBTZXJ2aWNl cyB1c2UgSFRUUCBhbmQgdGhlcmUgYXJlIGJyYW5kIG5ldyBvbmVzIGV2ZXJ5IHdlZWsuIFNvIGlm IHdlIGRlc2lnbiBzb21ldGhpbmcgdGhhdCBjYW4gYmUgdXNlZCBmb3IgV2ViIFNlcnZpY2VzLCB3 ZSBjYW4gZXZlbnR1YWxseSB1c2UgaXQgZm9yIG90aGVyIHB1cnBvc2VzLg0KDQpFdmVuIGEgMzAl IHJlZHVjdGlvbiBpbiBhZmZpbGlhdGUgZnJhdWQgaXMgcmVhbCBtb25leS4NCg0KDQpUaGUgd2F5 IEkgbWFwIG91dCB0aGUgc3BhY2UgZm9yIGF1dGhlbnRpY2F0aW9uIGlzIHRoYXQgSSBzZWUgdGhy ZWUgc2VwYXJhdGUgcHJvY2Vzc2VzLCBhbGwgb2Ygd2hpY2ggYXJlIGNhbGxlZCAnYXV0aGVudGlj YXRpb24nIGJ1dCBhcmUgZGlmZmVyZW50IHRoaW5ncy4gSSB3YXMgb25jZSBvbiBhIHBhbmVsIG9u ICdyZWF1dGhlbnRpY2F0aW9uJyBhbmQgdGhlIHR3byBvdGhlciBzcGVha2VycyBoYWQgaW5jb21w YXRpYmxlIGRlZmluaXRpb25zLg0KDQoxKSBDcmVkZW50aWFsIElzc3VlDQogICAgIFRoaXMgbWF5 IG9yIG1heSBub3QgaW52b2x2ZSBhdXRoZW50aWNhdGlvbiBvZiBBbGljZSwgaW4gdGhlIFBLSSB3 b3JsZCB3ZSBjYWxsIGl0IHZhbGlkYXRpb24uDQoNCjIpIFVzZSBvZiBjcmVkZW50aWFsIHRvIGlu aXRpYXRlIHNlc3Npb24NCiAgICAgV2hlcmUgSSBzdXNwZWN0IHRoaXMgaXMgdG8gYmUgc2l0dWF0 ZWQsIGN1cnJlbnRseSBwYXNzd29yZCBvcmllbnRlZC4NCg0KMykgU2Vzc2lvbiBjb250aW51YXRp b24NCiAgICAgQ3VycmVudGx5IHRoZSB3ZWFrZXN0IG9mIHRoZSBsb3QsIHRoZSBmYWN0IHdlIHVz ZSBjb29raWVzIGFzIGJlYXJlciB0b2tlbnMgaW4gSFRUUFMgbWFrZXMgZWF2eSBkZW1hbmRzIG9u IHRoZSBjcnlwdG8gcHJvdG9jb2wuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJlYXJhYmxlQGll dGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQoNCg== --_000_BN3PR0301MB1250157478D9414F79B27D4F8C630BN3PR0301MB1250_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgY3VycmVudCBJLURzIGRvIHByb3Bvc2Ug YSBjaGFuZ2UgaW4gdGhlIEhUVFAgc3RhY2sgKG5ldyBIVFRQIGhlYWRlcnMpLiBCdXQgSSB0aGlu ayBpdCBpcyBhIHZhbGlkIHJlcXVpcmVtZW50IHRoYXQgd2hhdGV2ZXIgc29sdXRpb24gd2UgYXJy aXZlIGF0IG11c3Qgd29yaw0KIGZvciBXZWIgYnJvd3NlcnMuIEUuZy4gdGhpcyBtZWFucyB0aGF0 IHNlY3VyaXR5IHRva2VucyBtdXN0IGJlIHByZXNlbnRhYmxlIG92ZXIgbXVsdGlwbGUgVExTIHNl c3Npb25zIGFuZCBjb25uZWN0aW9ucywgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBEZWNlbWJlciAxMCwgMjAxNCAzOjE3IFBNPGJy Pg0KPGI+VG86PC9iPiBQaGlsbGlwIEhhbGxhbS1CYWtlcjxicj4NCjxiPkNjOjwvYj4gQW5kcmVp IFBvcG92OyB1bmJlYXJhYmxlQGlldGYub3JnOyBTdGVwaGVuIEZhcnJlbGw8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBvbmUgcHJvcG9zYWwgZm9yIGEgY2hhcnRlciAtIHBs ZWFzZSBkaWNzdXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXMgSSB1bmRlcnN0YW5kIGl0IHRoaXMgaXMgcHJvcG9zaW5nIGEgY2hhbmdlIHRvIGJyb3dz ZXJzLiAmbmJzcDtCcm93c2VycyB3aWxsIG5lZWQgdG8gYmUgdXBkYXRlZC4gJm5ic3A7VGhlcmUg aXMgYSBwcmUgc3RhbmRhcmQgdmVyc2lvbiBvZiB0aGlzIGluIENocm9tZSBub3cgYnV0IGV2ZW4g dGhhdCB3b3VsZCBuZWVkIHRvIGNoYW5nZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCB0aGluayB0aGlzIFdHIGlzIGNvbnNpZGVyaW5nIGFu eXRoaW5nIHRoYXQgd291bGQgd29yayB3aXRoIGEgY3VycmVudCBicm93c2VyLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzIHdoeSBJ IGRvbuKAmXQgdGhpbmsgaXQgb3ZlcmxhcHMgd2l0aCBjdXJyZW50IE9BdXRoIHdvcmsgdXNpbmcg c3RhdGljIGNsaWVudCBrZXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBEZWMgMTAsIDIwMTQsIGF0IDExOjA1IFBNLCBQaGls bGlwIEhhbGxhbS1CYWtlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWxsQGhhbGxhbWJha2VyLmNv bSI+cGhpbGxAaGFsbGFtYmFrZXIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRGVjIDEw LCAyMDE0IGF0IDM6NDUgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8L3NwYW4+T25l IG9mIHRoZSBtYWluIGNvbnN0cmFpbnRzIG9uIHRoZSBXZWIgYXV0aGVudGljYXRpb24vYXV0aG9y aXphdGlvbiBwcm9wb3NhbHMgaGFzIGJlZW4gdGhhdCB0aGV5IGhhdmUgdG8gd29yayB3aXRoIGV4 aXN0aW5nIGJyb3dzZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WWVzLCB0aGlzIGlzIGEgdmFsaWQgY29uc3Ry YWludCwgYW5kIGl0IGRvZXMgYWZmZWN0IHRoZSBkZXNpZ24gY2hvaWNlcy4gUGVyaGFwcyB3ZSBz aG91bGQgbWFrZSB0aGlzDQogbW9yZSBleHBsaWNpdCBpbiB0aGUgY2hhcnRlci48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBpcyB0aGUgZGVzaWduIHNwYWNlIGhlcmU/IEFyZSB3ZSBm aXR0aW5nIGludG8gZXhpc3RpbmcgYnJvd3NlcnMgb3Igbm90PyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHJhdGhlciBmZWQg dXAgb2YgdGhlIGlkZWEgdGhhdCB3ZSBuZXZlciBldmVyIGNvbnNpZGVyIGRvaW5nIHRoZSBqb2Ig cmlnaHQuIFllcyBpdCBtaWdodCB0YWtlIHRlbiB5ZWFycyBiZWZvcmUgd2UgcmVhY2ggOTUlIHBl bmV0cmF0aW9uIGJ1dCB3ZSBjYW4gZ2V0IHRvIDMwJSBpbiBvbmUgQ2hyb21lIHJlbGVhc2UgY3lj bGUuIFdpdGggV2luZG93cyAxMCB3ZSBjYW4gZXhwZWN0IHNvbWV0aGluZyBsaWtlDQogODAlIG9m IHRoZSBicm93c2VycyB0byBiZSBvbiBhdXRvbWF0aWMgdXBkYXRlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgd2UgZGlkIFNBTUwgdGVu IHllYXJzIGFnbyBub3cuIFRoaW5rIG9mIHdoZXJlIHdlIG1pZ2h0IGJlIG5vdyBoYWQgd2UgZG9u ZSBhIGNsZWFuIGltcGxlbWVudGF0aW9uIGFsb25nIHNpZGUgdGhlIGxlZ2FjeSBwcmVzZXJ2aW5n IHRoZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2UgZG9uJ3QgbmVlZCB0byBtYWtlIGEgbGVhcCBpbiB0aGUgZGFyayBoZXJlIGVpdGhl ci4gV2ViIFNlcnZpY2VzIHVzZSBIVFRQIGFuZCB0aGVyZSBhcmUgYnJhbmQgbmV3IG9uZXMgZXZl cnkgd2Vlay4gU28gaWYgd2UgZGVzaWduIHNvbWV0aGluZyB0aGF0IGNhbiBiZSB1c2VkIGZvciBX ZWIgU2VydmljZXMsIHdlIGNhbiBldmVudHVhbGx5IHVzZSBpdCBmb3Igb3RoZXIgcHVycG9zZXMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV2 ZW4gYSAzMCUgcmVkdWN0aW9uIGluIGFmZmlsaWF0ZSBmcmF1ZCBpcyByZWFsIG1vbmV5LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB3 YXkgSSBtYXAgb3V0IHRoZSBzcGFjZSBmb3IgYXV0aGVudGljYXRpb24gaXMgdGhhdCBJIHNlZSB0 aHJlZSBzZXBhcmF0ZSBwcm9jZXNzZXMsIGFsbCBvZiB3aGljaCBhcmUgY2FsbGVkICdhdXRoZW50 aWNhdGlvbicgYnV0IGFyZSBkaWZmZXJlbnQgdGhpbmdzLiBJIHdhcyBvbmNlIG9uIGEgcGFuZWwg b24gJ3JlYXV0aGVudGljYXRpb24nIGFuZCB0aGUgdHdvIG90aGVyIHNwZWFrZXJzIGhhZCBpbmNv bXBhdGlibGUNCiBkZWZpbml0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgQ3JlZGVudGlhbCBJc3N1ZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtU aGlzIG1heSBvciBtYXkgbm90IGludm9sdmUgYXV0aGVudGljYXRpb24gb2YgQWxpY2UsIGluIHRo ZSBQS0kgd29ybGQgd2UgY2FsbCBpdCB2YWxpZGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgVXNlIG9mIGNyZWRlbnRpYWwgdG8g aW5pdGlhdGUgc2Vzc2lvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtXaGVyZSBJIHN1c3BlY3QgdGhpcyBpcyB0 byBiZSBzaXR1YXRlZCwgY3VycmVudGx5IHBhc3N3b3JkIG9yaWVudGVkLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zKSBTZXNzaW9uIGNvbnRp bnVhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtDdXJyZW50bHkgdGhlIHdlYWtlc3Qgb2YgdGhlIGxvdCwg dGhlIGZhY3Qgd2UgdXNlIGNvb2tpZXMgYXMgYmVhcmVyIHRva2VucyBpbiBIVFRQUyBtYWtlcyBl YXZ5IGRlbWFuZHMgb24gdGhlIGNyeXB0byBwcm90b2NvbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnIj5VbmJlYXJhYmxlQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdW5iZWFyYWJsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJl YXJhYmxlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR0301MB1250157478D9414F79B27D4F8C630BN3PR0301MB1250_-- From nobody Thu Dec 11 19:00:16 2014 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 3F54F1A9162 for ; Thu, 11 Dec 2014 19:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 O0H54QL9Of6w for ; Thu, 11 Dec 2014 19:00:10 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028DF1A1B74 for ; Thu, 11 Dec 2014 19:00:09 -0800 (PST) X-AuditID: 1209190c-f79e46d000000eb2-99-548a5a38bb1c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 6A.40.03762.83A5A845; Thu, 11 Dec 2014 22:00:08 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id sBC308Sn013533; Thu, 11 Dec 2014 22:00:08 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBC306rw029148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Dec 2014 22:00:07 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBC3056d009150; Thu, 11 Dec 2014 22:00:05 -0500 (EST) Date: Thu, 11 Dec 2014 22:00:05 -0500 (EST) From: Benjamin Kaduk To: Phil Hunt In-Reply-To: <93BC7D25-7C16-4A8D-B303-4798D213D57A@oracle.com> Message-ID: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> <20141211200049.GF3448@localhost> <548A01D8.7000107@gmx.net> <93BC7D25-7C16-4A8D-B303-4798D213D57A@oracle.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrWsR1RVicGWhlcWC+Y3sFuceL2Ry YPJYsuQnk8fHp7dYApiiuGxSUnMyy1KL9O0SuDL+vf3OXLCBtWLe6j7mBsb5LF2MnBwSAiYS 5z5dg7LFJC7cW88GYgsJLGaS2DCXs4uRC8jeyCix9tJrdgjnEJPEzK5TjBBOA6PEnj0LgTIc HCwC2hIX9pSDdLMJqEjMfLMRbJIIkP3t6nVGkBJmAX2J+zeVQcLCAnES07p+MIGEOQXsJKZs SwEJ8wo4Sqy4fJsJYvpiFonO44uYQRKiAjoSq/dPYYEoEpQ4OfMJmM0soCWxfPo2lgmMgrOQ pGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6iXm1mil5pSuokRHKaSPDsY3xxUOsQo wMGoxMObEd8ZIsSaWFZcmXuIUZKDSUmUlzWiK0SILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG+3 JFCONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCtz8SqFGwKDU9tSIt M6cEIc3EwQkynAdoeDJIDW9xQWJucWY6RP4Uoy7Hgvb9M5mEWPLy81KlxHmDQIoEQIoySvPg 5sDSyytGcaC3hHn3gfzAA0xNcJNeAS1hAlqyfEsHyJKSRISUVAOjqgev9kmdMxI7OzT28f3P 7zzsKPN76UYTU0aTbUxBP1as7F/qXeBpbu9277bq/KUGjl4nHvYc4ijcJaadbBX8rHmikTLX dukjW6ZxMS2T0fHqd7RZpDepJuS9uM6DZzOWdj7ZuvgPK4/O5cs11f+yFOe9ntqd7nxL8LyQ rLuhKvPcg7q6vl1KLMUZiYZazEXFiQCQNKtHCgMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/nsHV76GsYNl0FsILXu2kqixlnm0 Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss 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, 12 Dec 2014 03:00:15 -0000 On Thu, 11 Dec 2014, Phil Hunt wrote: > Asymmetric keys by their nature tend to have the private key kept > securely. Further, a client could use the same key-pair for multiple > separate access tokens issued to it by a service provider. This can > also get us away from the 1:1 key for token paradigm and leads to > something naturally more secure (meaning a developer has to work extra > hard to mess this up). This does have the property that conspiring resource servers can track the user based on that reused public key (as is noted in many of the documents floating around). But, I guess that is a discussion to have after there is a charter (i.e., later). -Ben From nobody Thu Dec 11 19:12:27 2014 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 3CD401A9175 for ; Thu, 11 Dec 2014 19:12:25 -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 kotKzOFS5aeF for ; Thu, 11 Dec 2014 19:12:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0734.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:734]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B081A9172 for ; Thu, 11 Dec 2014 19:12:23 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) with Microsoft SMTP Server (TLS) id 15.1.31.17; Fri, 12 Dec 2014 03:12:00 +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.0031.000; Fri, 12 Dec 2014 03:12:00 +0000 From: Andrei Popov To: Benjamin Kaduk , Phil Hunt Thread-Topic: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss Thread-Index: AQHQFX02QqmMTuMzN0aHm7cnuEjJbJyK1THQgAAF8wCAAB8wgIAASieAgAAAxvA= Date: Fri, 12 Dec 2014 03:11:59 +0000 Message-ID: References: <2B2DE357-A83D-4FFA-A11D-687B12DA0471@oracle.com> <1887431950.8472900.1418318255569.JavaMail.yahoo@jws10681.mail.bf1.yahoo.com> <20141211200049.GF3448@localhost> <548A01D8.7000107@gmx.net> <93BC7D25-7C16-4A8D-B303-4798D213D57A@oracle.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::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1250; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1250; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(13464003)(377454003)(24454002)(189002)(46102003)(54206007)(561944003)(54606007)(33656002)(4396001)(105586002)(92566001)(97736003)(21056001)(31966008)(76576001)(99286002)(101416001)(74316001)(50986999)(106116001)(106356001)(2656002)(122556002)(120916001)(87936001)(102836002)(15975445007)(68736005)(19580395003)(64706001)(86612001)(76176999)(86362001)(40100003)(2171001)(107046002)(20776003)(93886004)(62966003)(19580405001)(54356999)(99396003)(77156002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1250; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/HvVy3EHBwDOAFGOYqfGua1LpfrY Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss 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, 12 Dec 2014 03:12:25 -0000 The current Token Binding IDs mitigate this by using different Token Bindin= g keys to connect to different resource servers, according to the token sco= ping rules of the application protocol (for HTTPS this means a Token Bindin= g key per eTLD). Additionally, the Token Binding keys can be deleted by the user at any time= , e.g. when clearing browser cookies. Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Benjamin= Kaduk Sent: Thursday, December 11, 2014 7:00 PM To: Phil Hunt Cc: unbearable@ietf.org Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter= - please dicsuss On Thu, 11 Dec 2014, Phil Hunt wrote: > Asymmetric keys by their nature tend to have the private key kept=20 > securely. Further, a client could use the same key-pair for multiple=20 > separate access tokens issued to it by a service provider. This can=20 > also get us away from the 1:1 key for token paradigm and leads to=20 > something naturally more secure (meaning a developer has to work extra=20 > hard to mess this up). This does have the property that conspiring resource servers can track the = user based on that reused public key (as is noted in many of the documents = floating around). But, I guess that is a discussion to have after there is= a charter (i.e., later). -Ben _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Fri Dec 12 02:12:25 2014 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 765591ACC81 for ; Fri, 12 Dec 2014 02:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gUS9IJAe5dnM for ; Fri, 12 Dec 2014 02:12:18 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673D51ACC7F for ; Fri, 12 Dec 2014 02:12:18 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so2001262wiv.0 for ; Fri, 12 Dec 2014 02:12:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:content-transfer-encoding:from :mime-version:subject:date:message-id:references:cc:in-reply-to:to; bh=ic4ORWwaQtzYb2qUgCRh7JNo4XtqtlFeLP4IL+Vw+fs=; b=iiwLJfOl8TvC534V9Q7Psaz3d9NPQS11IiCtWUs3/kmAScNfXVBxgCnBCZAJNPVo4K xHs/ASx/H51hJgG4Oe9gZUiDS28toAD4SSzCpn2iP8YPNtw8VseK458MpgrlW9pqi8KZ aUhzyxIopKBr7S4iWFDocUWvOy+KIDt+N8hygnFiTnMzp6jhJKweoey9VfcWq/s5aVmC eMAzI7GkYZi+dpN6UaudAG2G7GL1VvqRxmx7fDgVTpSkAO6fIOKIaw9RZ0bW0QUyqNMI 4PpGzJ0f+WkodPRMr9RKKovpBVo3BI8jG38E+1c9JWBK7L+M9E1SbZte1q6kUsn5E0kN 8jeQ== X-Gm-Message-State: ALoCoQnl07FPacGzbCzgizJMoOd0RTQTzaSr+HQWTLK9QGJxHDats0sg0atkH9386tvmDP2Bpn0V X-Received: by 10.180.37.142 with SMTP id y14mr6123456wij.47.1418379137029; Fri, 12 Dec 2014 02:12:17 -0800 (PST) Received: from [10.69.140.168] (94.197.120.31.threembb.co.uk. [94.197.120.31]) by mx.google.com with ESMTPSA id hn2sm1210528wjc.5.2014.12.12.02.12.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Dec 2014 02:12:15 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-DB4E6524-7B60-4DFC-B89A-006F38CCE672 Content-Transfer-Encoding: 7bit From: John Bradley Mime-Version: 1.0 (1.0) Date: Fri, 12 Dec 2014 10:11:33 +0000 Message-Id: References: <54863200.4030600@cs.tcd.ie> In-Reply-To: To: Andrei Popov X-Mailer: iPhone Mail (12B440) Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/QgxwtnHp3tgign9zoDLHzGwpitU Cc: "unbearable@ietf.org" , Phillip Hallam-Baker , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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, 12 Dec 2014 10:12:24 -0000 --Apple-Mail-DB4E6524-7B60-4DFC-B89A-006F38CCE672 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes the current OAuth work is based on what is currently available to native= applications only. Clarifying that this is new functionality for browsers= /user agents will help, I think.=20 John B.=20 Sent from my iPhone > On Dec 10, 2014, at 8:45 PM, Andrei Popov wro= te: >=20 > =C3=98 One of the main constraints on the Web authentication/authorizatio= n proposals has been that they have to work with existing browsers. > Yes, this is a valid constraint, and it does affect the design choices. Pe= rhaps we should make this more explicit in the charter. > =20 > Cheers, > =20 > Andrei > =20 > From: hallam@gmail.com [mailto:hallam@gmail.com] On Behalf Of Phillip Hall= am-Baker > Sent: Monday, December 8, 2014 6:23 PM > To: Andrei Popov > Cc: Stephen Farrell; unbearable@ietf.org > Subject: Re: [Unbearable] one proposal for a charter - please dicsuss > =20 > =20 > =20 > On Mon, Dec 8, 2014 at 8:52 PM, Andrei Popov w= rote: > Hi Phillip, > =20 > =C3=98 In particular I don't think we are getting away from bearer tokens= , we are just hiding them different. >=20 > =20 > The Token Binding Protocol I-D provides a mechanism for binding security t= okens to the TLS layer. When a bound token is presented to a server, the ser= ver verifies the token binding and rejects the token if the binding verifica= tion fails. Therefore, such bound tokens are not bearer tokens: they are res= istant to export and replay attacks. > =20 > =C3=98 This is a draft I have been working on for a while. It allows a to= ken to be bound to a HTTP/TLS channel. >=20 > =20 > I agree that your draft is designed to solve a similar problem, although t= he approach you=E2=80=99ve taken is different in multiple ways. We can discu= ss these differences, but perhaps we should first focus on establishing the W= G charter. > =20 > =20 > We have a lot of efforts in this space. What I think distinguishes them is= the intended scope of use and which parts of the Web infrastructure it is p= roposed to change. > =20 > One of the main constraints on the Web authentication/authorization propos= als has been that they have to work with existing browsers. Accepting that c= onstraint means a lot more corner cases that have to be considered and a wea= ker result.=20 > =20 > Another big difference is whether a bearer token has to be human friendly o= r not. If we are talking about credentials generated by machines for machine= s then we can go all 256 bit without penalty. If we have to deal with users t= hen it gets a lot harder. > =20 > =20 > =20 > =20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail-DB4E6524-7B60-4DFC-B89A-006F38CCE672 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yes the current OAuth work is based on= what is currently available to native applications only.   Clarifying t= hat this is new functionality for browsers/user agents will help, I think.&n= bsp;

John B. 

Sent from my iPhone
=

On Dec 10, 2014, at 8:45 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

=C3=98  One of the main constraints on the Web au= thentication/authorization proposals has been that they have to work with ex= isting browsers.

Yes, this is a valid constraint, and it= does affect the design choices. Perhaps we should make this more explicit i= n the charter.

 

Cheers,

 

Andrei

 

From: hallam@gmail.com [mailto:hallam@g= mail.com] On Behalf Of Phillip Hallam-Baker
Sent: Monday, December 8, 2014 6:23 PM
To: Andrei Popov
Cc: Stephen Farrell; unbearabl= e@ietf.org
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss=

 

 

 

On Mon, Dec 8, 2014 at 8:52 PM, Andrei Popov <Andrei.Popov@mic= rosoft.com> wrote:

Hi Phillip,

 

=C3=98  In particular I don't think we are getting away from bearer tokens, we are j= ust hiding them different.

 

The Token Binding Protocol I-D provides a mechanism for binding security tok= ens to the TLS layer. When a bound token is presented to a server, the serve= r verifies the token binding and rejects the token if the binding verificati= on fails. Therefore, such bound tokens are not bearer tokens: they are resistant to export and replay attac= ks.

 

=C3=98  This is a draft I have been working on for a while. It allows a token to be b= ound to a HTTP/TLS channel.

 

I agree that your draft is designed to solve a similar= problem, although the approach you=E2=80=99ve taken is different in multiple ways. We can discuss these differences, but perhap= s we should first focus on establishing the WG charter.

 

 

We have a lot of efforts in this space. What I think d= istinguishes them is the intended scope of use and which parts of the Web in= frastructure it is proposed to change.

 

One of the main constraints on the Web authentication= /authorization proposals has been that they have to work with existing brows= ers. Accepting that constraint means a lot more corner cases that have to be= considered and a weaker result. 

 

Another big difference is whether a bearer token has t= o be human friendly or not. If we are talking about credentials generated by= machines for machines then we can go all 256 bit without penalty. If we hav= e to deal with users then it gets a lot harder.

 

 

 

 

____________________= ___________________________
Unbearable mailing listUnbearable@ietf.org
http= s://www.ietf.org/mailman/listinfo/unbearable
= --Apple-Mail-DB4E6524-7B60-4DFC-B89A-006F38CCE672-- From nobody Sat Dec 13 16:27:41 2014 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 610781A01E1 for ; Sat, 13 Dec 2014 16:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.713 X-Spam-Level: * X-Spam-Status: No, score=1.713 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 IpIEQE3EcL-O for ; Sat, 13 Dec 2014 16:27:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6381A020B for ; Sat, 13 Dec 2014 16:27:37 -0800 (PST) Received: from [217.186.210.235] by 3capp-gmx-bs28.server.lan (via HTTP); Sun, 14 Dec 2014 01:27:32 +0100 MIME-Version: 1.0 Message-ID: From: D.Rogers@gmx.net To: "Andrei Popov" Content-Type: text/html; charset=UTF-8 Date: Sun, 14 Dec 2014 01:27:32 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: <54863200.4030600@cs.tcd.ie> , X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:vhTINUBlIsXkjPWD1egCOl88abXdn9qUT5LTCLTehev trnGzraxMHtQdEOTOSV7ElmHlCjNDIj1LHAh7l2NHLxKS1E6uS 4oF/2asnXNrnt60CTz8dypq1sY1flrCA2dW9ZQviBkXHdmwaP5 +pHQFOiEwOKaCLMylQxr/hqhmrSHo6Lm9r6ktNTbSQYevD/DOn haHLVYDcrxxciDlsN4aUUwewfeQCJ880QFaoAIbE0UpflQRTAW aJWzlrdGuLne8zOl6PK7kNShW1tqwayOmczB6WAs4iGQm7glOl mPNyKI= X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/unbearable/e6rfyTnAitrKKiCPymb6jsFFMoA Cc: "unbearable@ietf.org" , Phillip Hallam-Baker , Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter - please dicsuss 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: Sun, 14 Dec 2014 00:27:40 -0000
Hi All,
 
I'm catching up from oldest first, so apologies if someone else has already said te same, but the volume of messages generated at the moment precudes me sifting upward.
I think the point Andrei was making was that in the sense of pursuing the ideal, and not the ad-hock, perhaps it might be better to design for the thoeretical ideal, and once that is clear to make requests to browser developers as to what might be needed from thier systems.
Otherwise we fall into the never-ending-story of upon each iteration of browser geberation, the group has to start again.
I'm more of a get-it-right-first-time person. Further non-group involvement would just fine tuning etc.
 
Salutem
Dean
 
Gesendet: Mittwoch, 10. Dezember 2014 um 21:45 Uhr
Von: "Andrei Popov" <Andrei.Popov@microsoft.com>
An: "Phillip Hallam-Baker" <phill@hallambaker.com>
Cc: "unbearable@ietf.org" <unbearable@ietf.org>, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Betreff: Re: [Unbearable] one proposal for a charter - please dicsuss

Ø  One of the main constraints on the Web authentication/authorization proposals has been that they have to work with existing browsers.

Yes, this is a valid constraint, and it does affect the design choices. Perhaps we should make this more explicit in the charter.

 

Cheers,

 

Andrei

 

From: hallam@gmail.com [mailto:hallam@gmail.com] On Behalf Of Phillip Hallam-Baker
Sent: Monday, December 8, 2014 6:23 PM
To: Andrei Popov
Cc: Stephen Farrell; unbearable@ietf.org
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss

 

 

 

On Mon, Dec 8, 2014 at 8:52 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

Hi Phillip,

 

Ø  In particular I don't think we are getting away from bearer tokens, we are just hiding them different.

 

The Token Binding Protocol I-D provides a mechanism for binding security tokens to the TLS layer. When a bound token is presented to a server, the server verifies the token binding and rejects the token if the binding verification fails. Therefore, such bound tokens are not bearer tokens: they are resistant to export and replay attacks.

 

Ø  This is a draft I have been working on for a while. It allows a token to be bound to a HTTP/TLS channel.

 

I agree that your draft is designed to solve a similar problem, although the approach you’ve taken is different in multiple ways. We can discuss these differences, but perhaps we should first focus on establishing the WG charter.

 

 

We have a lot of efforts in this space. What I think distinguishes them is the intended scope of use and which parts of the Web infrastructure it is proposed to change.

 

One of the main constraints on the Web authentication/authorization proposals has been that they have to work with existing browsers. Accepting that constraint means a lot more corner cases that have to be considered and a weaker result. 

 

Another big difference is whether a bearer token has to be human friendly or not. If we are talking about credentials generated by machines for machines then we can go all 256 bit without penalty. If we have to deal with users then it gets a lot harder.

 

 

 

 

_______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable