From stpeter@stpeter.im Mon Aug 1 08:03:17 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCC711E80A0 for ; Mon, 1 Aug 2011 08:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwPhlraoX+w8 for ; Mon, 1 Aug 2011 08:03:16 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 74EAA11E8070 for ; Mon, 1 Aug 2011 08:03:16 -0700 (PDT) Received: from squire.local (unknown [216.17.251.72]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B7C6C41309; Mon, 1 Aug 2011 09:04:37 -0600 (MDT) Message-ID: <4E36C038.3040208@stpeter.im> Date: Mon, 01 Aug 2011 09:03:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Barry Leiba References: <20110729184136.5836.39491.idtracker@ietfa.amsl.com> <4E3435A0.3000603@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:03:17 -0000 On 7/31/11 8:45 AM, Barry Leiba wrote: > On Sat, Jul 30, 2011 at 12:47, Peter Saint-Andre wrote: >> On 7/29/11 3:07 PM, Brian Campbell wrote: >>> Following up from >>> http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few >>> weeks ago, I've submitted a new I-D to establish an IETF URN >>> Sub-Namespace for OAuth (urn:ietf:params:oauth:*:*). Eran balked at >>> putting this in the core spec so it made sense to produce a separate >>> draft for it. I'd like to request from the group and the chairs that >>> this draft become a work item of the WG as soon as possible. The SAML >>> draft will utilize this to register a proper URN for the extension >>> grant type and presumably the JWT draft will as well. Hopefully it >>> will be useful in other contexts as well (like the oob parameter that >>> has been discussed). >>> >>> The draft is available at: >>> http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns-00 >>> >>> Because Hannes originally wrote all the content, I've listed him as an >>> author. Let me know if that's not appropriate. >> >> I'm happy to sponsor this draft if the Security ADs think it is too >> "appsy", but I think it's completely straightforward. > > Given the progress that the OAuth WG has made, the fact that we're in > WGLC on two major documents, and the fact that the SAML draft depends > upon what's in here, I have no issue with adding this as a WG item. > Stephen, do you agree with that? (I know that Stephen's away for a > bit, and won't be responding for a while. This can wait until he gets > back, and in the meantime the SAML doc can assume that this one is > going forward.) I think that's a good path forward. Peter -- Peter Saint-Andre https://stpeter.im/ From wmills@yahoo-inc.com Mon Aug 1 08:41:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C3211E8108 for ; Mon, 1 Aug 2011 08:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.926 X-Spam-Level: X-Spam-Status: No, score=-15.926 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiMEcR+1VqZg for ; Mon, 1 Aug 2011 08:41:09 -0700 (PDT) Received: from nm15-vm2.bullet.mail.ne1.yahoo.com (nm15-vm2.bullet.mail.ne1.yahoo.com [98.138.91.91]) by ietfa.amsl.com (Postfix) with SMTP id F21D911E8106 for ; Mon, 1 Aug 2011 08:41:08 -0700 (PDT) Received: from [98.138.90.49] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 01 Aug 2011 15:41:12 -0000 Received: from [98.138.89.197] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 01 Aug 2011 15:41:12 -0000 Received: from [127.0.0.1] by omp1055.mail.ne1.yahoo.com with NNFMP; 01 Aug 2011 15:41:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 363247.21943.bm@omp1055.mail.ne1.yahoo.com Received: (qmail 24843 invoked by uid 60001); 1 Aug 2011 15:41:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1312213271; bh=b6gL9uBn2kQWCr44VAGtn0Gml+h5mQ13iC/CQbXR7Rs=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Z4dxX/Ornw3BDBI+3RqUN3zi4X+pOVBVzbVCD4UEXqbCkPE9lTQZhbywI+1NAHq/tC4pMGDo1dQAjVVSsKLmkVnT5vQRZPwcQf1hPQecsWAfSzlMxKgbewCkBR5meQ3ERcP9jQ939Qn321w+CmIQBWbhzgJQMROdkbsBWheoJz0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=c0RcwzUbF+CckT/FtYVFDQcWQkqK5xTXCCK8XVYITtaco3ptjuN9bZpoThgNe1IKeJ4zyZ6ipysVoRLbYQ+woT0D7Ps5c2q7HruX8J3AclLt7h/ikzwMG/U6vIX1ZXlVwEpK4cMFSWi1RRLpSGz6RNi/7yavKYDr8rAKGTxIddI=; X-YMail-OSG: XXBz_G4VM1k_VOeQvBkfS9QA_vCclpXsVBbOJgboR2DegSQ _JZ4n_g2aDX__UGyKkAdgsDx3w4tc4Qw5M7RqEqhY59ThV1wFln363ZtW4r8 vEZC2yU7l9r2hsJRjId7oYf3W7Gqgl3grylID2nmY6P3xsesUQc_g9LrJF7g yJ7HxiXHouPQokrKALQ9DtwmckHkQ14UJahsKulaNROpd4zLvTSrK6TZsNgK dS4HOqKHkCjrPclLnAPkNicp5ZzZtoFjlrUsSOODwhqdmZtW38murefWZd7z 3qngm0iNjZ9oqZBojCEyOyp.1PC0mguaRBOrqOKsnkzCTjq1GTwe95FvwBDB y8oNpsih_oEwm Received: from [99.31.212.42] by web31813.mail.mud.yahoo.com via HTTP; Mon, 01 Aug 2011 08:41:11 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> Date: Mon, 1 Aug 2011 08:41:11 -0700 (PDT) From: "William J. Mills" To: Eran Hammer-Lahav , OAuth WG In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-170212033-1312213271=:20715" Cc: Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 15:41:10 -0000 --0-170212033-1312213271=:20715 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Instead of "body" hash why not make it a payload hash or additional hash.= =A0 The app can include a hash of data there as defined by the app, and you= 've reserved a spot for that.=0A=0A=0A=0A________________________________= =0AFrom: Eran Hammer-Lahav =0ATo: OAuth WG =0ACc: Ben Adida ; "'Adam Barth (adam@adambarth.com)'" = =0ASent: Friday, July 29, 2011 6:43 PM=0ASubject: [OAUT= H-WG] MAC Tokens body hash=0A=0A=0AI plan to drop support for the bodyhash = parameter in the next draft based on bad implementation experience. Even wi= th simple text body, UTF encoding has introduced significant issues for us.= The current draft does not work using simple JS code between a browser and= node.js even when both use the same v8 engine due to differences in the bo= dy encoding. Basically, the JS string used to send a request from the brows= er is not the actual string sent on the wire.=0A=A0=0ATo fix that, we need = to force UTF-8 encoding on both sides. However, that is very much applicati= on specific. This will not work for non-text bodies. Instead, the specifica= tion should offer a simple way to use the ext parameter for such needs, inc= luding singing headers. And by offer I mean give examples, but leave it app= lication specific for now.=0A=A0=0AI am open to suggestions but so far all = the solutions I came up with will introduce unacceptable complexity that wi= ll basically make this work useless.=0A=A0=0AEHL=0A________________________= _______________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www= .ietf.org/mailman/listinfo/oauth --0-170212033-1312213271=:20715 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Instead of "body" hash why not make it a payload hash or additional hash.=   The app can include a hash of data there as defined by the app, and = you've reserved a spot for that.

<= span style=3D"font-weight:bold;">From: Eran Hammer-Lahav <era= n@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
= Cc: Ben Adida <ben@adida.net>; "'Adam Barth (adam@adambart= h.com)'" <adam@adambarth.com>
Sent: Friday, July 29, 2011 6:43 PM
Subject: [OAUTH-WG] MAC Tokens body hash
I plan to drop support for th= e bodyhash parameter in the next draft based on bad implementation experien= ce. Even with simple text body, UTF encoding has introduced significant iss= ues for us. The current draft does not work using simple JS code between a = browser and node.js even when both use the same v8 engine due to difference= s in the body encoding. Basically, the JS string used to send a request fro= m the browser is not the actual string sent on the wire.
 
To fix that, we need to force UTF-8 encoding on both sides. However, that = is very much application specific. This will not work for non-text bodies. = Instead, the specification should offer a simple way to use the ext paramet= er for such needs, including singing headers. And by offer I mean give exam= ples, but leave it application specific for now.
 
=
I am open to suggestions but so far a= ll the solutions I came up with will introduce unacceptable complexity that= will basically make this work useless.
 
EHL
<= /div>
_______________________________________________
OAuth mailing l= ist
= OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--0-170212033-1312213271=:20715-- From eran@hueniverse.com Mon Aug 1 09:00:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5354F11E80EA for ; Mon, 1 Aug 2011 09:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtvgP1CtIPuB for ; Mon, 1 Aug 2011 09:00:53 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 9F1B211E80C4 for ; Mon, 1 Aug 2011 09:00:53 -0700 (PDT) Received: (qmail 27571 invoked from network); 1 Aug 2011 16:01:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Aug 2011 16:00:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 1 Aug 2011 09:00:47 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , OAuth WG Date: Mon, 1 Aug 2011 08:59:58 -0700 Thread-Topic: [OAUTH-WG] MAC Tokens body hash Thread-Index: AcxQYXNdxYV0yO+wRn+DWCW6hHx9SwAAnBkw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F61F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723450245F61F2P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:00:55 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723450245F61F2P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would you still like to see both such app-specific payload hash AND the ext= parameter? I'm thinking of taking your idea and dropping ext. This way, th= e application can define anything they want to put in the payload hash. EHL From: William J. Mills [mailto:wmills@yahoo-inc.com] Sent: Monday, August 01, 2011 8:41 AM To: Eran Hammer-Lahav; OAuth WG Cc: Ben Adida; 'Adam Barth (adam@adambarth.com)' Subject: Re: [OAUTH-WG] MAC Tokens body hash Instead of "body" hash why not make it a payload hash or additional hash. = The app can include a hash of data there as defined by the app, and you've = reserved a spot for that. ________________________________ From: Eran Hammer-Lahav > To: OAuth WG > Cc: Ben Adida >; "'Adam Barth (adam@ada= mbarth.com)'" > Sent: Friday, July 29, 2011 6:43 PM Subject: [OAUTH-WG] MAC Tokens body hash I plan to drop support for the bodyhash parameter in the next draft based o= n bad implementation experience. Even with simple text body, UTF encoding h= as introduced significant issues for us. The current draft does not work us= ing simple JS code between a browser and node.js even when both use the sam= e v8 engine due to differences in the body encoding. Basically, the JS stri= ng used to send a request from the browser is not the actual string sent on= the wire. To fix that, we need to force UTF-8 encoding on both sides. However, that i= s very much application specific. This will not work for non-text bodies. I= nstead, the specification should offer a simple way to use the ext paramete= r for such needs, including singing headers. And by offer I mean give examp= les, but leave it application specific for now. I am open to suggestions but so far all the solutions I came up with will i= ntroduce unacceptable complexity that will basically make this work useless= . EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723450245F61F2P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Would you= still like to see both such app-specific payload hash AND the ext paramete= r? I’m thinking of taking your idea and dropping ext. This way, the a= pplication can define anything they want to put in the payload hash.

 

EHL

 

From: William J. Mills [mailto:wmills@yahoo-inc.com]
Sent: Monday, A= ugust 01, 2011 8:41 AM
To: Eran Hammer-Lahav; OAuth WG
Cc:<= /b> Ben Adida; 'Adam Barth (adam@adambarth.com)'
Subject: Re: [OA= UTH-WG] MAC Tokens body hash

 

Instead o= f "body" hash why not make it a payload hash or additional hash.&= nbsp; The app can include a hash of data there as defined by the app, and y= ou've reserved a spot for that.

 

From: Era= n Hammer-Lahav <eran@hueniverse.c= om>
To: OAuth WG <oau= th@ietf.org>
Cc: Ben Adida <ben@adida.net>; "'Adam Barth (adam@adambarth.com)'" <adam@adambarth.com>
Sent: Friday, July 29, 2011 6= :43 PM
Subject: [OAUTH-WG] MAC Tokens body hash

I= plan to drop support for the bodyhash parameter in the next draft based on= bad implementation experience. Even with simple text body, UTF encoding ha= s introduced significant issues for us. The current draft does not work usi= ng simple JS code between a browser and node.js even when both use the same= v8 engine due to differences in the body encoding. Basically, the JS strin= g used to send a request from the browser is not the actual string sent on = the wire.

 

To fix that, we need to force UTF-8 encoding on both sides. However= , that is very much application specific. This will not work for non-text b= odies. Instead, the specification should offer a simple way to use the ext = parameter for such needs, including singing headers. And by offer I mean gi= ve examples, but leave it application specific for now.

 

I am open to suggesti= ons but so far all the solutions I came up with will introduce unacceptable= complexity that will basically make this work useless.

 

EHL=


___________________________= ____________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --_000_90C41DD21FB7C64BB94121FBBC2E723450245F61F2P3PW5EX1MB01E_-- From wmills@yahoo-inc.com Mon Aug 1 09:06:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2FB11E80E4 for ; Mon, 1 Aug 2011 09:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.04 X-Spam-Level: X-Spam-Status: No, score=-17.04 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUfzkOTlw857 for ; Mon, 1 Aug 2011 09:06:41 -0700 (PDT) Received: from nm6-vm3.bullet.mail.ne1.yahoo.com (nm6-vm3.bullet.mail.ne1.yahoo.com [98.138.91.136]) by ietfa.amsl.com (Postfix) with SMTP id 1B18611E8077 for ; Mon, 1 Aug 2011 09:06:41 -0700 (PDT) Received: from [98.138.90.56] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 01 Aug 2011 16:06:44 -0000 Received: from [98.138.89.254] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 01 Aug 2011 16:06:44 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 01 Aug 2011 16:06:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 176585.47538.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 27093 invoked by uid 60001); 1 Aug 2011 16:06:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1312214803; bh=alNCX0aB7rbtB67GpUlB5L1Ple/JpnHXzpysbkHQwIE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Zs+eA8ufyilWxh96+hXlBBFIF67/6/ckQPye0/IpsEHIRHfplyTFFzCb0uwZL0QrKTnYou0njTOk25C4Ce7VYMPyr7Hf7t0jb20hyohU61Kk+IP4iXlcz7hQ6nkfby4Cp9ewBvn+luFCfQGX98RxBtJSZe50UZZib9uRT+LyovI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qBGM+FH2QGTdAzTWVTk54ymNAgGBe4CoQ40orNQeauOICiF1H2nCf0BG+vbg0tflraHHUvVAZ0HorSbVj3yCPPZ9xlJpiNGzrxYKPKzzFKMR9uCOQ0KkDrY6diJ0+NSuqfLRlIpEIiyxZv3LC2+J8hKKT+IKvt3Mt5G6Fn45ITw=; X-YMail-OSG: LB8cbdQVM1k0kHbVMUT6oUY3PijOR7sYK5fMfmLuUNwyc5x Gdg.QxxOZYsznFAZKp4KN4efZ4p67m6iICVxfpnO83eaj5uVSSA_A.PepsQX AfA95aWsdx67s5MYQvD5X0FWWiS.Out7Hu92QOi_zjuIkZuAdbOvEvNkSSi7 Bx4iFLT99khLVMxe0Oi4Ng2.FZv_mdr83UZ7QIVFO5fjVdJFc9c6e6zlGS6. UROHS.1ZmkBl6J1wAq63A3OgFBnxmo_pHxFjsydyjp48isdD.2yLgqIwVZbx .ZzBiWe1WDBZAYGZlb5wVny_2Jt38_3JcywcuTGp4tFSH7RGqO6cDY6CqWC2 R6NnWQBDekVTX Received: from [99.31.212.42] by web31801.mail.mud.yahoo.com via HTTP; Mon, 01 Aug 2011 09:06:43 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723450245F61F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1312214803.15068.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Mon, 1 Aug 2011 09:06:43 -0700 (PDT) From: "William J. Mills" To: Eran Hammer-Lahav , OAuth WG In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F61F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1385684489-1312214803=:15068" Cc: Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:06:42 -0000 --0-1385684489-1312214803=:15068 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think the extended parameter still has use if someone extends the MAC stu= ff specifically, whcih the additional hash is useful for a data signature, = that's off the cuff though without implementing somethign to try it out.=0A= =0A=0A=0A________________________________=0AFrom: Eran Hammer-Lahav =0ATo: William J. Mills ; OAuth WG =0ACc: Ben Adida ; "'Adam Barth (adam@adambarth.= com)'" =0ASent: Monday, August 1, 2011 8:59 AM=0ASubjec= t: RE: [OAUTH-WG] MAC Tokens body hash=0A=0A=0AWould you still like to see = both such app-specific payload hash AND the ext parameter? I=E2=80=99m thin= king of taking your idea and dropping ext. This way, the application can de= fine anything they want to put in the payload hash.=0A=C2=A0=0AEHL=0A=C2=A0= =0AFrom:William J. Mills [mailto:wmills@yahoo-inc.com] =0ASent: Monday, Aug= ust 01, 2011 8:41 AM=0ATo: Eran Hammer-Lahav; OAuth WG=0ACc: Ben Adida; 'Ad= am Barth (adam@adambarth.com)'=0ASubject: Re: [OAUTH-WG] MAC Tokens body ha= sh=0A=C2=A0=0AInstead of "body" hash why not make it a payload hash or addi= tional hash.=C2=A0 The app can include a hash of data there as defined by t= he app, and you've reserved a spot for that.=0A=C2=A0=0A=0A________________= ________________=0A=0AFrom:Eran Hammer-Lahav =0ATo: OA= uth WG =0ACc: Ben Adida ; "'Adam Barth (adam= @adambarth.com)'" =0ASent: Friday, July 29, 2011 6:43 P= M=0ASubject: [OAUTH-WG] MAC Tokens body hash=0AI plan to drop support for t= he bodyhash parameter in the next draft based on bad implementation experie= nce. Even with simple text body, UTF encoding has introduced significant is= sues for us. The current draft does not work using simple JS code between a= browser and node.js even when both use the same v8 engine due to differenc= es in the body encoding. Basically, the JS string used to send a request fr= om the browser is not the actual string sent on the wire.=0A=C2=A0=0ATo fix= that, we need to force UTF-8 encoding on both sides. However, that is very= much application specific. This will not work for non-text bodies. Instead= , the specification should offer a simple way to use the ext parameter for = such needs, including singing headers. And by offer I mean give examples, b= ut leave it application specific for now.=0A=C2=A0=0AI am open to suggestio= ns but so far all the solutions I came up with will introduce unacceptable = complexity that will basically make this work useless.=0A=C2=A0=0AEHL=0A=0A= _______________________________________________=0AOAuth mailing list=0AOAut= h@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-1385684489-1312214803=:15068 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think the extended parameter still has use if someone extends the MAC s= tuff specifically, whcih the additional hash is useful for a data signature= , that's off the cuff though without implementing somethign to try it out.<= br>

F= rom: Eran Hammer-Lahav <eran@hueniverse.com>
To: William J. Mills <wmills@yaho= o-inc.com>; OAuth WG <oauth@ietf.org>
Cc: Ben Adida <ben@adida.net>; "'Adam Barth (adam@adambarth.com)'" <adam@adambarth.com>
Sent: Monday, August 1, 2011 8:59 AM
Subject: RE: [OAUTH-WG] MAC Token= s body hash

Would you still like to see both su= ch app-specific payload hash AND the ext parameter? I=E2=80=99m thinking of= taking your idea and dropping ext. This way, the application can define an= ything they want to put in the payload hash.
 
EHL
 
From: William J. Mills [mailt= o:wmills@yahoo-inc.com]
Sent: Monday, August 01, 2011 8:41 AMTo: Eran Hammer-Lahav; OAuth WG
Cc: Ben Adida; 'Adam Bart= h (adam@adambarth.com)'
Subject: Re: [OAUTH-WG] MAC Tokens body h= ash
 
Instead= of "body" hash why not make it a payload hash or additional hash.  Th= e app can include a hash of data there as defined by the app, and you've re= served a spot for that.
 
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: O= Auth WG <oauth@ietf.org>
Cc: Ben Adida <ben@adida.net>; "'Adam Barth (adam@adambarth.com)'" <adam@adambarth.com>
Sent: Friday, Ju= ly 29, 2011 6:43 PM
Subject: [OAUTH-WG] MAC Tokens body hash
<= div>
I plan to drop support for the bodyhash parameter in= the next draft based on bad implementation experience. Even with simple te= xt body, UTF encoding has introduced significant issues for us. The current= draft does not work using simple JS code between a browser and node.js eve= n when both use the same v8 engine due to differences in the body encoding.= Basically, the JS string used to send a request from the browser is not the actual string se= nt on the wire.
 
To fix that, we need to force UTF-8 encodin= g on both sides. However, that is very much application specific. This will= not work for non-text bodies. Instead, the specification should offer a si= mple way to use the ext parameter for such needs, including singing headers= . And by offer I mean give examples, but leave it application specific for = now.
 
I am open to suggestions but so far all the solutions = I came up with will introduce unacceptable complexity that will basically make this work = useless.
 
EHL

______________________________________________= _
OAuth mailing list
OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth



--0-1385684489-1312214803=:15068-- From phil.hunt@oracle.com Mon Aug 1 22:50:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E4F21F8E12 for ; Mon, 1 Aug 2011 22:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo3sA9Lb6g3Z for ; Mon, 1 Aug 2011 22:50:54 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 164C121F8E10 for ; Mon, 1 Aug 2011 22:50:54 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p725ovK8001814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 05:51:00 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p725oumo020096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 05:50:57 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p725opov019477; Tue, 2 Aug 2011 00:50:51 -0500 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Aug 2011 22:50:50 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--1050400694 From: Phil Hunt In-Reply-To: <1312214803.15068.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Mon, 1 Aug 2011 22:50:48 -0700 Message-Id: <62E9072B-6687-4906-9241-717D6EBD8167@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723450245F61F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312214803.15068.YahooMailNeo@web31801.mail.mud.yahoo.com> To: "William J. Mills" X-Mailer: Apple Mail (2.1084) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090208.4E379045.000D,ss=1,re=-2.300,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 05:50:55 -0000 --Apple-Mail-3--1050400694 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Agree. -1 on removing the ext parameter. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-01, at 9:06 AM, William J. Mills wrote: > I think the extended parameter still has use if someone extends the = MAC stuff specifically, whcih the additional hash is useful for a data = signature, that's off the cuff though without implementing somethign to = try it out. >=20 > From: Eran Hammer-Lahav > To: William J. Mills ; OAuth WG > Cc: Ben Adida ; "'Adam Barth (adam@adambarth.com)'" = > Sent: Monday, August 1, 2011 8:59 AM > Subject: RE: [OAUTH-WG] MAC Tokens body hash >=20 > Would you still like to see both such app-specific payload hash AND = the ext parameter? I=92m thinking of taking your idea and dropping ext. = This way, the application can define anything they want to put in the = payload hash. > =20 > EHL > =20 > From: William J. Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Monday, August 01, 2011 8:41 AM > To: Eran Hammer-Lahav; OAuth WG > Cc: Ben Adida; 'Adam Barth (adam@adambarth.com)' > Subject: Re: [OAUTH-WG] MAC Tokens body hash > =20 > Instead of "body" hash why not make it a payload hash or additional = hash. The app can include a hash of data there as defined by the app, = and you've reserved a spot for that. > =20 > From: Eran Hammer-Lahav > To: OAuth WG > Cc: Ben Adida ; "'Adam Barth (adam@adambarth.com)'" = > Sent: Friday, July 29, 2011 6:43 PM > Subject: [OAUTH-WG] MAC Tokens body hash > I plan to drop support for the bodyhash parameter in the next draft = based on bad implementation experience. Even with simple text body, UTF = encoding has introduced significant issues for us. The current draft = does not work using simple JS code between a browser and node.js even = when both use the same v8 engine due to differences in the body = encoding. Basically, the JS string used to send a request from the = browser is not the actual string sent on the wire. > =20 > To fix that, we need to force UTF-8 encoding on both sides. However, = that is very much application specific. This will not work for non-text = bodies. Instead, the specification should offer a simple way to use the = ext parameter for such needs, including singing headers. And by offer I = mean give examples, but leave it application specific for now. > =20 > I am open to suggestions but so far all the solutions I came up with = will introduce unacceptable complexity that will basically make this = work useless. > =20 > EHL >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3--1050400694 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-08-01, at 9:06 AM, William J. Mills = wrote:

I think the extended parameter = still has use if someone extends the MAC stuff specifically, whcih the = additional hash is useful for a data signature, that's off the cuff = though without implementing somethign to try it = out.

From: Eran Hammer-Lahav <eran@hueniverse.com>
To: William J. Mills <wmills@yahoo-inc.com>; OAuth = WG <oauth@ietf.org>
Cc: Ben Adida <ben@adida.net>; "'Adam Barth (adam@adambarth.com)'" <adam@adambarth.com>
Sent: Monday, August 1, 2011 = 8:59 AM
Subject: RE: = [OAUTH-WG] MAC Tokens body hash

Would you still like to see both such app-specific payload hash AND = the ext parameter? I=92m thinking of taking your idea and dropping ext. = This way, the application can define anything they want to put in the = payload hash.
 
EHL
 
From:= William J. Mills [mailto:wmills@yahoo-inc.com]
Sent: Monday, = August 01, 2011 8:41 AM
To: Eran Hammer-Lahav; OAuth = WG
Cc: Ben Adida; 'Adam Barth (adam@adambarth.com)'
Subject:= Re: [OAUTH-WG] MAC Tokens body hash
 
Instead of = "body" hash why not make it a payload hash or additional hash.  The = app can include a hash of data there as defined by the app, and you've = reserved a spot for that.
 
From: Eran Hammer-Lahav <eran@hueniverse.com>
To:<= /b> OAuth WG <oauth@ietf.org>
Cc: Ben = Adida <ben@adida.net>; = "'Adam Barth (adam@adambarth.com)'" <adam@adambarth.com>
Sent:<= /b> Friday, July 29, 2011 6:43 PM
Subject: [OAUTH-WG] MAC = Tokens body hash
I plan to drop = support for the bodyhash parameter in the next draft based on bad = implementation experience. Even with simple text body, UTF encoding has = introduced significant issues for us. The current draft does not work = using simple JS code between a browser and node.js even when both use = the same v8 engine due to differences in the body encoding. Basically, = the JS string used to send a request from the browser is not the actual string = sent on the wire.
 
To fix that, we need to force UTF-8 encoding on = both sides. However, that is very much application specific. This will = not work for non-text bodies. Instead, the specification should offer a = simple way to use the ext parameter for such needs, including singing = headers. And by offer I mean give examples, but leave it application = specific for now.
 
I am open to suggestions but so far all the = solutions I came up with will introduce unacceptable complexity that will basically make this = work useless.
 
EHL

_______________________________________________=
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth



_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail-3--1050400694-- From eran@hueniverse.com Mon Aug 1 23:23:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E3221F884E for ; Mon, 1 Aug 2011 23:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNUsWvgNLmPc for ; Mon, 1 Aug 2011 23:22:57 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id E285621F8844 for ; Mon, 1 Aug 2011 23:22:56 -0700 (PDT) Received: (qmail 11531 invoked from network); 2 Aug 2011 06:23:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Aug 2011 06:23:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 1 Aug 2011 23:23:01 -0700 From: Eran Hammer-Lahav To: Phil Hunt , "William J. Mills" Date: Mon, 1 Aug 2011 23:22:12 -0700 Thread-Topic: [OAUTH-WG] MAC Tokens body hash Thread-Index: AcxQ2CwH0CBtySE4QreQ7PH5Hjb8wgAA+wWg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F63D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723450245F61F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312214803.15068.YahooMailNeo@web31801.mail.mud.yahoo.com> <62E9072B-6687-4906-9241-717D6EBD8167@oracle.com> In-Reply-To: <62E9072B-6687-4906-9241-717D6EBD8167@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723450245F63D7P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 06:23:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723450245F63D7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am going to drop both 'bodyhash' and 'ext', and instead add 'app'. 'app' = allows you to include any data you want. 'ext' without an internal format a= nd register is just asking for trouble, and I have no intention of adding t= hat level of complexity. There are other proposals in the IETF for full HTT= P message signatures, and I'll leave these more complex use cases to them. If you can demonstrate actual need (with examples) of both 'app' and 'ext',= I'm willing to reconsider but you can clearly accomplish the same end resu= lt with just one, application-specific parameter. EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Monday, August 01, 2011 10:51 PM To: William J. Mills Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash Agree. -1 on removing the ext parameter. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-01, at 9:06 AM, William J. Mills wrote: I think the extended parameter still has use if someone extends the MAC stu= ff specifically, whcih the additional hash is useful for a data signature, = that's off the cuff though without implementing somethign to try it out. ________________________________ From: Eran Hammer-Lahav > To: William J. Mills >; O= Auth WG > Cc: Ben Adida >; "'Adam Barth (adam@ada= mbarth.com)'" > Sent: Monday, August 1, 2011 8:59 AM Subject: RE: [OAUTH-WG] MAC Tokens body hash Would you still like to see both such app-specific payload hash AND the ext= parameter? I'm thinking of taking your idea and dropping ext. This way, th= e application can define anything they want to put in the payload hash. EHL From: William J. Mills [mailto:wmills@yahoo-inc.com] Sent: Monday, August 01, 2011 8:41 AM To: Eran Hammer-Lahav; OAuth WG Cc: Ben Adida; 'Adam Barth (adam@adambarth.com)' Subject: Re: [OAUTH-WG] MAC Tokens body hash Instead of "body" hash why not make it a payload hash or additional hash. = The app can include a hash of data there as defined by the app, and you've = reserved a spot for that. ________________________________ From: Eran Hammer-Lahav > To: OAuth WG > Cc: Ben Adida >; "'Adam Barth (adam@ada= mbarth.com)'" > Sent: Friday, July 29, 2011 6:43 PM Subject: [OAUTH-WG] MAC Tokens body hash I plan to drop support for the bodyhash parameter in the next draft based o= n bad implementation experience. Even with simple text body, UTF encoding h= as introduced significant issues for us. The current draft does not work us= ing simple JS code between a browser and node.js even when both use the sam= e v8 engine due to differences in the body encoding. Basically, the JS stri= ng used to send a request from the browser is not the actual string sent on= the wire. To fix that, we need to force UTF-8 encoding on both sides. However, that i= s very much application specific. This will not work for non-text bodies. I= nstead, the specification should offer a simple way to use the ext paramete= r for such needs, including singing headers. And by offer I mean give examp= les, but leave it application specific for now. I am open to suggestions but so far all the solutions I came up with will i= ntroduce unacceptable complexity that will basically make this work useless= . EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723450245F63D7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am goin= g to drop both ‘bodyhash’ and ‘ext’, and instead ad= d ‘app’. ‘app’ allows you to include any data you w= ant. ‘ext’ without an internal format and register is just aski= ng for trouble, and I have no intention of adding that level of complexity.= There are other proposals in the IETF for full HTTP message signatures, an= d I’ll leave these more complex use cases to them.<= /p>

 

If you can demonstrate actual need (with examples) of both R= 16;app’ and ‘ext’, I’m willing to reconsider but yo= u can clearly accomplish the same end result with just one, application-spe= cific parameter.

&nbs= p;

EHL

 

<= p class=3DMsoNormal>From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent= : Monday, August 01, 2011 10:51 PM
To: William J. Mills
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] MAC = Tokens body hash

 

Agree.

 

-1 on removi= ng the ext parameter.

 

Phil<= o:p>

 

@independentid=

<= /div>

phil.hunt@oracle.com

 

=



 

On 2011-08-01= , at 9:06 AM, William J. Mills wrote:



I thin= k the extended parameter still has use if someone extends the MAC stuff spe= cifically, whcih the additional hash is useful for a data signature, that's= off the cuff though without implementing somethign to try it out.

 =

<= /span>

From: Eran Hammer-Lahav <eran@hueniverse.com>
To: William J. Mill= s <wmills@yahoo-inc.com>;= OAuth WG <oauth@ietf.org>
<= b>Cc: Ben Adida <ben@adida.net&= gt;; "'Adam Barth (adam@adambart= h.com)'" <adam@adambarth.= com>
Sent: Monday, August 1, 2011 8:59 AM
Subject: RE: [OAUTH-WG] MAC Tokens body hash

Would you still like to see both such app-sp= ecific payload hash AND the ext parameter? I’m thinking of taking you= r idea and dropping ext. This way, the application can define anything they= want to put in the payload hash.

<= span style=3D'font-size:11.0pt;font-family:"Arial","sans-serif";color:#1F49= 7D'> 

EHL

 

From: William J. Mills [mailto:wmills@yahoo-inc.com] Sent: Monday, August 01, 2011 8:41 AM
To: Eran Hammer-La= hav; OAuth WG
Cc: Ben Adida; 'Adam Barth (adam@adambarth.com)'
Subject: Re: [OAUTH-WG] M= AC Tokens body hash

 

<= p class=3DMsoNormal style=3D'background:white'>Instead of "body" hash why not make it = a payload hash or additional hash.  The app can include a hash of data= there as defined by the app, and you've reserved a spot for that.

 

From:= Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
C= c: Ben Adida <ben= @adida.net>; "'Adam Barth (adam@adambarth.com)'" <adam@adambarth.com>
Sent:<= /b> Friday, July 29, 2011 6:43 PM
Subject: [OAUTH-WG] MAC Tokens = body hash

I plan to drop support for the bodyhash= parameter in the next draft based on bad implementation experience. Even w= ith simple text body, UTF encoding has introduced significant issues for us= . The current draft does not work using simple JS code between a browser an= d node.js even when both use the same v8 engine due to differences in the b= ody encoding. Basically, the JS string used to send a request from the brow= ser is not the actual string sent on the wire.

<= /div>

 

To fix = that, we need to force UTF-8 encoding on both sides. However, that is very = much application specific. This will not work for non-text bodies. Instead,= the specification should offer a simple way to use the ext parameter for s= uch needs, including singing headers. And by offer I mean give examples, bu= t leave it application specific for now.

<= div>

 

I am open to s= uggestions but so far all the solutions I came up with will introduce unacc= eptable complexity that will basically make this work useless.

 

EHL


_______________________________= ________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth

 

=

_______________________________________________
OAu= th mailing list
OAuth@ietf.org
= https://www.ietf.or= g/mailman/listinfo/oauth

=  

= --_000_90C41DD21FB7C64BB94121FBBC2E723450245F63D7P3PW5EX1MB01E_-- From phil.hunt@oracle.com Tue Aug 2 08:31:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509B521F873D for ; Tue, 2 Aug 2011 08:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mci6ByIbEuv for ; Tue, 2 Aug 2011 08:31:27 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id D5FB421F873A for ; Tue, 2 Aug 2011 08:31:26 -0700 (PDT) Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p72FVWjh001198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 15:31:34 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p72FVUtC014173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Aug 2011 15:31:31 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p72FVOxE006680; Tue, 2 Aug 2011 10:31:25 -0500 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Aug 2011 08:31:23 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5--1015566488 From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F63D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 2 Aug 2011 08:31:22 -0700 Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723450245F61F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312214803.15068.YahooMailNeo@web31801.mail.mud.yahoo.com> <62E9072B-6687-4906-9241-717D6EBD8167@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723450245F63D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E381856.00C8,ss=1,re=-2.300,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:31:28 -0000 --Apple-Mail-5--1015566488 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Not sure I understand. How does 'app' change the issue about internal = format and register? Is it not for the user of the field to use and document its use as = appropriate? I think the text that you had for ext was just fine. Cutting the field out, eliminates any possibility of extensibility -- = and that would close a door that dead-ends the MAC design --> likely = causing another MAC variant IMHO. That may be what you are looking for. = Just want to make sure that's what you intend. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-01, at 11:22 PM, Eran Hammer-Lahav wrote: > I am going to drop both =91bodyhash=92 and =91ext=92, and instead add = =91app=92. =91app=92 allows you to include any data you want. =91ext=92 = without an internal format and register is just asking for trouble, and = I have no intention of adding that level of complexity. There are other = proposals in the IETF for full HTTP message signatures, and I=92ll leave = these more complex use cases to them. > =20 > If you can demonstrate actual need (with examples) of both =91app=92 = and =91ext=92, I=92m willing to reconsider but you can clearly = accomplish the same end result with just one, application-specific = parameter. > =20 > EHL > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Monday, August 01, 2011 10:51 PM > To: William J. Mills > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] MAC Tokens body hash > =20 > Agree. > =20 > -1 on removing the ext parameter. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > =20 >=20 >=20 > =20 > On 2011-08-01, at 9:06 AM, William J. Mills wrote: >=20 >=20 > I think the extended parameter still has use if someone extends the = MAC stuff specifically, whcih the additional hash is useful for a data = signature, that's off the cuff though without implementing somethign to = try it out. > =20 > From: Eran Hammer-Lahav > To: William J. Mills ; OAuth WG > Cc: Ben Adida ; "'Adam Barth (adam@adambarth.com)'" = > Sent: Monday, August 1, 2011 8:59 AM > Subject: RE: [OAUTH-WG] MAC Tokens body hash >=20 > Would you still like to see both such app-specific payload hash AND = the ext parameter? I=92m thinking of taking your idea and dropping ext. = This way, the application can define anything they want to put in the = payload hash. > =20 > EHL > =20 > From: William J. Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Monday, August 01, 2011 8:41 AM > To: Eran Hammer-Lahav; OAuth WG > Cc: Ben Adida; 'Adam Barth (adam@adambarth.com)' > Subject: Re: [OAUTH-WG] MAC Tokens body hash > =20 > Instead of "body" hash why not make it a payload hash or additional = hash. The app can include a hash of data there as defined by the app, = and you've reserved a spot for that. > =20 > From: Eran Hammer-Lahav > To: OAuth WG > Cc: Ben Adida ; "'Adam Barth (adam@adambarth.com)'" = > Sent: Friday, July 29, 2011 6:43 PM > Subject: [OAUTH-WG] MAC Tokens body hash > I plan to drop support for the bodyhash parameter in the next draft = based on bad implementation experience. Even with simple text body, UTF = encoding has introduced significant issues for us. The current draft = does not work using simple JS code between a browser and node.js even = when both use the same v8 engine due to differences in the body = encoding. Basically, the JS string used to send a request from the = browser is not the actual string sent on the wire. > =20 > To fix that, we need to force UTF-8 encoding on both sides. However, = that is very much application specific. This will not work for non-text = bodies. Instead, the specification should offer a simple way to use the = ext parameter for such needs, including singing headers. And by offer I = mean give examples, but leave it application specific for now. > =20 > I am open to suggestions but so far all the solutions I came up with = will introduce unacceptable complexity that will basically make this = work useless. > =20 > EHL >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-5--1015566488 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Not = sure I understand. How does 'app' change the issue about internal format = and register?

Is it not for the user of the field to = use and document its use as appropriate?  I think the text that you = had for ext was just fine.

Cutting the field = out, eliminates any possibility of extensibility -- and that would close = a door that dead-ends the MAC design --> likely causing another MAC = variant IMHO.  That may be what you are looking for. Just want to = make sure that's what you intend.


On 2011-08-01, at 11:22 PM, Eran Hammer-Lahav = wrote:

I am = going to drop both =91bodyhash=92 and =91ext=92, and instead add =91app=92= . =91app=92 allows you to include any data you want. =91ext=92 without = an internal format and register is just asking for trouble, and I have = no intention of adding that level of complexity. There are other = proposals in the IETF for full HTTP message signatures, and I=92ll leave = these more complex use cases to them.
If = you can demonstrate actual need (with examples) of both =91app=92 and = =91ext=92, I=92m willing to reconsider but you can clearly accomplish = the same end result with just one, application-specific = parameter.
 Phil = Hunt [mailto:phil.hunt@oracle.com] 
Sent: Monday, August 01, 2011 = 10:51 PM
To: William J. = Mills
Cc: Eran= Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] MAC Tokens = body hash
-1 on removing the ext = parameter.
Phil
@independentid


From: Eran Hammer-Lahav < William J. Mills <wmills@yahoo-inc.com>; OAuth WG = <oauth@ietf.org>
Cc: Ben Adida <ben@adida.net>; "'Adam Barth (adam@adambarth.com)'" < Monday, August 1, 2011 8:59 = AM
Subject: RE: [OAUTH-WG] MAC Tokens = body hash

 Eran Hammer-Lahav < OAuth WG <oauth@ietf.org>
Cc: Ben Adida <ben@adida.net>; "'Adam Barth (adam@adambarth.com)'" < Friday, July 29, 2011 6:43 = PM
Subject: [OAUTH-WG] MAC Tokens body = hash
I plan to drop support for the bodyhash parameter in the next = draft based on bad implementation experience. Even with simple text = body, UTF encoding has introduced significant issues for us. The current = draft does not work using simple JS code between a browser and node.js = even when both use the same v8 engine due to differences in the body = encoding. Basically, the JS string used to send a request from the = browser is not the actual string sent on the = wire.
To fix that, = we need to force UTF-8 encoding on both sides. However, that is very = much application specific. This will not work for non-text bodies. = Instead, the specification should offer a simple way to use the ext = parameter for such needs, including singing headers. And by offer I mean = give examples, but leave it application specific for = now.
I am open to = suggestions but so far all the solutions I came up with will introduce = unacceptable complexity that will basically make this work = useless.

OAuth@ietf.org
Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:44:40 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723450245F643EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yep. I would like to allow each application to extend what is being signed,= such as payload or specific headers. I don't want to open the door for add= itional specifications defining how to use the ext parameter. If there is e= nough consensus for an extended signing model, we should define a new schem= e. EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, August 02, 2011 8:31 AM To: Eran Hammer-Lahav Cc: William J. Mills; OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash Not sure I understand. How does 'app' change the issue about internal forma= t and register? Is it not for the user of the field to use and document its use as appropri= ate? I think the text that you had for ext was just fine. Cutting the field out, eliminates any possibility of extensibility -- and t= hat would close a door that dead-ends the MAC design --> likely causing ano= ther MAC variant IMHO. That may be what you are looking for. Just want to = make sure that's what you intend. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-01, at 11:22 PM, Eran Hammer-Lahav wrote: I am going to drop both 'bodyhash' and 'ext', and instead add 'app'. 'app' = allows you to include any data you want. 'ext' without an internal format a= nd register is just asking for trouble, and I have no intention of adding t= hat level of complexity. There are other proposals in the IETF for full HTT= P message signatures, and I'll leave these more complex use cases to them. If you can demonstrate actual need (with examples) of both 'app' and 'ext',= I'm willing to reconsider but you can clearly accomplish the same end resu= lt with just one, application-specific parameter. EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Monday, August 01, 2011 10:51 PM To: William J. Mills Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash Agree. -1 on removing the ext parameter. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-01, at 9:06 AM, William J. Mills wrote: I think the extended parameter still has use if someone extends the MAC stu= ff specifically, whcih the additional hash is useful for a data signature, = that's off the cuff though without implementing somethign to try it out. ________________________________ From: Eran Hammer-Lahav > To: William J. Mills >; O= Auth WG > Cc: Ben Adida >; "'Adam Barth (adam@ada= mbarth.com)'" > Sent: Monday, August 1, 2011 8:59 AM Subject: RE: [OAUTH-WG] MAC Tokens body hash Would you still like to see both such app-specific payload hash AND the ext= parameter? I'm thinking of taking your idea and dropping ext. This way, th= e application can define anything they want to put in the payload hash. EHL From: William J. Mills [mailto:wmills@yahoo-inc.com] Sent: Monday, August 01, 2011 8:41 AM To: Eran Hammer-Lahav; OAuth WG Cc: Ben Adida; 'Adam Barth (adam@adambarth.com)' Subject: Re: [OAUTH-WG] MAC Tokens body hash Instead of "body" hash why not make it a payload hash or additional hash. = The app can include a hash of data there as defined by the app, and you've = reserved a spot for that. ________________________________ From: Eran Hammer-Lahav > To: OAuth WG > Cc: Ben Adida >; "'Adam Barth (adam@ada= mbarth.com)'" > Sent: Friday, July 29, 2011 6:43 PM Subject: [OAUTH-WG] MAC Tokens body hash I plan to drop support for the bodyhash parameter in the next draft based o= n bad implementation experience. Even with simple text body, UTF encoding h= as introduced significant issues for us. The current draft does not work us= ing simple JS code between a browser and node.js even when both use the sam= e v8 engine due to differences in the body encoding. Basically, the JS stri= ng used to send a request from the browser is not the actual string sent on= the wire. To fix that, we need to force UTF-8 encoding on both sides. However, that i= s very much application specific. This will not work for non-text bodies. I= nstead, the specification should offer a simple way to use the ext paramete= r for such needs, including singing headers. And by offer I mean give examp= les, but leave it application specific for now. I am open to suggestions but so far all the solutions I came up with will i= ntroduce unacceptable complexity that will basically make this work useless= . EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723450245F643EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yep. I wo= uld like to allow each application to extend what is being signed, such as = payload or specific headers. I don’t want to open the door for additi= onal specifications defining how to use the ext parameter. If there is enou= gh consensus for an extended signing model, we should define a new scheme.<= o:p>

 

EHL

 

 

=

Not sure I understand. How does 'app' change the issue= about internal format and register?

 

Is it not for the us= er of the field to use and document its use as appropriate?  I think t= he text that you had for ext was just fine.

 

Cutting= the field out, eliminates any possibility of extensibility -- and that wou= ld close a door that dead-ends the MAC design --> likely causing another= MAC variant IMHO.  That may be what you are looking for. Just want to= make sure that's what you intend.

 

Phil

 

On 2011-08-01, at 11:22 PM, Eran Hammer-Lahav wrote:

<= /div>



I am going to drop both ‘bodyhash’ and ‘ext&#= 8217;, and instead add ‘app’. ‘app’ allows you to i= nclude any data you want. ‘ext’ without an internal format and = register is just asking for trouble, and I have no intention of adding that= level of complexity. There are other proposals in the IETF for full HTTP m= essage signatures, and I’ll leave these more complex use cases to the= m.

 

If you can demonstra= te actual need (with examples) of both ‘app’ and ‘extR= 17;, I’m willing to reconsider but you can clearly accomplish the sam= e end result with just one, application-specific parameter.

 

EHL

 

From: Phil Hunt [mailto:phil.hunt@oracle.com] = ;
Sent: Mo= nday, August 01, 2011 10:51 PM
To: William J. Mills
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] MAC Tokens body ha= sh

 <= o:p>

Agree.

 

-1 on removing the ext parameter.

 



From: Eran = Hammer-Lahav <eran@hueniverse.com= >
To: Will= iam J. Mills <wmills@yahoo-inc.c= om>; OAuth WG <oauth@ietf.org>
Cc: Ben Ad= ida <ben@adida.net>; "'Adam= Barth (adam@adambarth.com)'"= ; <adam@adambarth.com>
<= b>Sent: Monday, August = 1, 2011 8:59 AM
Subject: = ;RE: [OAUTH-WG] MAC Tokens body hash

Would you still like to see both such app-specific payload hash AND t= he ext parameter? I’m thinking of taking your idea and dropping ext. = This way, the application can define anything they want to put in the paylo= ad hash.

 

=

EHL

 

From: Willi= am J. Mills [mailto:wmills@yahoo-inc.com] 
Sent: Monday, August 01, 2011 8:41 AM
To: Eran Hammer-Lahav; OAuth = WG
Cc: Ben Adida;= 'Adam Barth (adam@adambarth.com)= '
Subject: Re: [O= AUTH-WG] MAC Tokens body hash

=

 

Instead of "body" hash why not make it a p= ayload hash or additional hash.  The app can include a hash of data th= ere as defined by the app, and you've reserved a spot for that.=

 

From: Eran Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Cc: Ben Adida <ben@adida.net>; "'Adam Barth (adam@adambarth.com)'&q= uot; <adam@adamb= arth.com>
Sent: <= /span>Friday, July 29, 2011 6:43 PM
Subject: [OAUTH-WG] MAC Tokens body hash

I plan to dro= p support for the bodyhash parameter in the next draft based on bad impleme= ntation experience. Even with simple text body, UTF encoding has introduced= significant issues for us. The current draft does not work using simple JS= code between a browser and node.js even when both use the same v8 engine d= ue to differences in the body encoding. Basically, the JS string used to se= nd a request from the browser is not the actual string sent on the wire.

 

To fix that, we need to force UTF-8= encoding on both sides. However, that is very much application specific. T= his will not work for non-text bodies. Instead, the specification should of= fer a simple way to use the ext parameter for such needs, including singing= headers. And by offer I mean give examples, but leave it application speci= fic for now.

 <= /span>

I am open to suggest= ions but so far all the solutions I came up with will introduce unacceptabl= e complexity that will basically make this work useless.<= /p>

 

EHL


_______________________________________________
OAuth = mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________<= br>OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723450245F643EP3PW5EX1MB01E_-- From bcampbell@pingidentity.com Tue Aug 2 12:26:53 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682A321F856C for ; Tue, 2 Aug 2011 12:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.959 X-Spam-Level: X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivcdTsFfIQLz for ; Tue, 2 Aug 2011 12:26:53 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id A9D2C21F8568 for ; Tue, 2 Aug 2011 12:26:52 -0700 (PDT) Received: from mail-qy0-f176.google.com ([209.85.216.176]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTjhPhUBPfAA/Uzs0BA8IkqPi3Pc/j8Ps@postini.com; Tue, 02 Aug 2011 12:27:02 PDT Received: by mail-qy0-f176.google.com with SMTP id 4so101969qyk.0 for ; Tue, 02 Aug 2011 12:27:01 -0700 (PDT) Received: by 10.224.186.10 with SMTP id cq10mr4542966qab.393.1312313219116; Tue, 02 Aug 2011 12:26:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.67.17 with HTTP; Tue, 2 Aug 2011 12:26:29 -0700 (PDT) In-Reply-To: <4E36C038.3040208@stpeter.im> References: <20110729184136.5836.39491.idtracker@ietfa.amsl.com> <4E3435A0.3000603@stpeter.im> <4E36C038.3040208@stpeter.im> From: Brian Campbell Date: Tue, 2 Aug 2011 13:26:29 -0600 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Barry Leiba , oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 19:26:53 -0000 Thanks Peter & Barry, I'll proceed under those assumptions. Also, just fyi that I just posted a new draft of this at http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns-01 that has only a couple minor editorial changes. I hope to get to the SAML draft soon. On Mon, Aug 1, 2011 at 9:03 AM, Peter Saint-Andre wrot= e: > On 7/31/11 8:45 AM, Barry Leiba wrote: >> Given the progress that the OAuth WG has made, the fact that we're in >> WGLC on two major documents, and the fact that the SAML draft depends >> upon what's in here, I have no issue with adding this as a WG item. >> Stephen, do you agree with that? =A0(I know that Stephen's away for a >> bit, and won't be responding for a while. =A0This can wait until he gets >> back, and in the meantime the SAML doc can assume that this one is >> going forward.) > > I think that's a good path forward. > > Peter > > > -- > Peter Saint-Andre > https://stpeter.im/ > > > From aiden449@gmail.com Tue Aug 2 15:19:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B18E11E80A1 for ; Tue, 2 Aug 2011 15:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZOmXg3i2PSp for ; Tue, 2 Aug 2011 15:19:06 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 08DB811E80CD for ; Tue, 2 Aug 2011 15:19:05 -0700 (PDT) Received: by qwc23 with SMTP id 23so210572qwc.31 for ; Tue, 02 Aug 2011 15:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=iQdWzcLiP+PaQSmo8i4xb2wqszIFbh463p31YUGs0Z0=; b=VhwpRCUjtXR5x2SY8kiZNAy0+j1f2J48WCK6JErNxoieSnTJlSZHBk1CqN60y5QC64 IuU2D73ji8qHFikIRqx2oCALdmzxBwBn4zC3/qhJTA1Sc0YIRrD6aPaoegGl9fIXPZWm 4i1SBO7MoeSzI5S1UTBlJ4oZ0KqT+B1oWbiss= MIME-Version: 1.0 Received: by 10.229.131.159 with SMTP id x31mr4596591qcs.193.1312323550216; Tue, 02 Aug 2011 15:19:10 -0700 (PDT) Received: by 10.229.187.66 with HTTP; Tue, 2 Aug 2011 15:19:10 -0700 (PDT) Date: Tue, 2 Aug 2011 23:19:10 +0100 Message-ID: From: Aiden Bell To: dr@fb.com, OAuth WG Content-Type: multipart/alternative; boundary=0015175741140a837b04a98d23e6 Subject: [OAUTH-WG] Device Profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:19:07 -0000 --0015175741140a837b04a98d23e6 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am currently implementing the device profile described at http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 Wanted to check this hadn't been superseded by any other document or protocol though I did notice the Google implementation is in-line with this document. Even though the summary states this is intended for limited input devices in combination with a full user agent (PC browser, smartphone browser), We are finding this extension useful for app authentication when the API serving the app is "open". This means that many developers can create mobile apps for one API, in conjunction with single users. For example, many apps may exist for the same API, and a single user may use many apps. As a result, we want to remove the requirement for ever entering use account-specific data (passwords etc) into apps, and allow a user to revoke app/device access on a per-instance basis. The end-user concerns of password security are lessened here. With OpenID or WebID in the mix, this further enhances the app/device authentication process as in an OpenID/WebID or similar setting, we can't always do resource owner password credentals (as in 1.4.3 of OAuth 2.0 http://tools.ietf.org/html/draft-ietf-oauth-v2-20 ) Unless I am missing another document or flow that provides the above better, (most likely I am) perhaps it is worth extending the scope/summary of device-00? Also, typo in the JSON HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "device_code":"74tq5miHKB", "user_code":"94248", "verification_uri":"http://www.example.com/device", "interval"=5 } I think should be: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "device_code":"74tq5miHKB", "user_code":"94248", "verification_uri":"http://www.example.com/device", "interval":5 } Thanks, Aiden -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --0015175741140a837b04a98d23e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I am currently implementing the device profile described at
= ht= tp://tools.ietf.org/html/draft-recordon-oauth-v2-device-00

Wante= d to check this hadn't been superseded by any other document or protoco= l
though I did notice the Google implementation is in-line with this document= .

Even though the summary states this is intended for limited input = devices in
combination with a full user agent (PC browser, smartphone br= owser),

We are finding this extension useful for app authentication when the AP= I
serving the app is "open". This means that many developers c= an create
mobile apps for one API, in conjunction with single users. For= example,
many apps may exist for the same API, and a single user may use many
app= s.

As a result, we want to remove the requirement for ever entering = use account-specific
data (passwords etc) into apps, and allow a user to= revoke app/device access on a per-instance
basis. The end-user concerns of password security are lessened here.
With OpenID or WebID in the mix, this further enhances the app/device auth= entication
process as in an OpenID/WebID or similar setting, we can'= t always do resource owner password
credentals (as in 1.4.3 of OAuth 2.0 http://tools.ietf.org/html/draft-ietf-oauth-v2-20 )

Unless I am missing another document or flow that provides the = above better, (most likely I am)
perhaps it is worth extending the scope/summary of device-00?

Also, = typo in the JSON

=A0 HTTP/1.1 200 OK
=A0 Content-Type: applicati= on/json
=A0 Cache-Control: no-store

=A0 {
=A0=A0=A0 "devi= ce_code":"74tq5miHKB",
=A0=A0=A0 "user_code":"94248",
=A0=A0=A0 "verif= ication_uri":"http://ww= w.example.com/device",
=A0=A0=A0=A0 "interval"=3D= 5
=A0=A0 }

I think should be:

=A0 HTTP/1.1 200 OK
=A0 Content-Type: application/json
=A0 = Cache-Control: no-store

=A0 {
=A0=A0=A0=A0 "device_cod= e":"74tq5miHKB",
=A0=A0=A0=A0 "user_code":&= quot;94248",
=A0=A0=A0=A0 "verification_uri":"http://www.example.com/device",
=A0=A0=A0=A0= "interval":5
=A0 }

Thanks,
Aiden

--
-----------------------------------------------------------= -------
Never send sensitive or private information via email unless it is encrypte= d. http://www.gnupg.org
--0015175741140a837b04a98d23e6-- From skylar@kiva.org Tue Aug 2 16:01:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCA111E80F4 for ; Tue, 2 Aug 2011 16:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVMS3b6AdBaM for ; Tue, 2 Aug 2011 16:01:58 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with SMTP id 6C85211E80F2 for ; Tue, 2 Aug 2011 16:01:58 -0700 (PDT) Received: from mail-wy0-f182.google.com ([74.125.82.182]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKTjiB6TKTKO9dSbpGl/g/k0b6tCFV3xlf@postini.com; Tue, 02 Aug 2011 16:02:09 PDT Received: by wyg24 with SMTP id 24so231627wyg.13 for ; Tue, 02 Aug 2011 16:02:00 -0700 (PDT) Received: by 10.216.173.81 with SMTP id u59mr2355944wel.4.1312326120594; Tue, 02 Aug 2011 16:02:00 -0700 (PDT) Received: from [192.168.1.102] (89-159-227-201.rev.numericable.fr [89.159.227.201]) by mx.google.com with ESMTPS id a43sm156964wed.28.2011.08.02.16.01.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 16:02:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 3 Aug 2011 01:01:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1244.3) Cc: Ben Adida , OAuth WG , "'Adam Barth \(adam@adambarth.com\)'" Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:01:59 -0000 hurrah! =20 (not necessarily for losing a way to sign the body, but for simplicity = and avoiding some of the potential inconsistencies w/ bodyhash). Is your plan to reserve an empty line 6 for the Normalized Request = String (which was used for bodyhash) or eliminate it, brining the total = to six elements? skylar On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote: > I plan to drop support for the bodyhash parameter in the next draft = based on bad implementation experience. Even with simple text body, UTF = encoding has introduced significant issues for us. The current draft = does not work using simple JS code between a browser and node.js even = when both use the same v8 engine due to differences in the body = encoding. Basically, the JS string used to send a request from the = browser is not the actual string sent on the wire. > =20 > To fix that, we need to force UTF-8 encoding on both sides. However, = that is very much application specific. This will not work for non-text = bodies. Instead, the specification should offer a simple way to use the = ext parameter for such needs, including singing headers. And by offer I = mean give examples, but leave it application specific for now. > =20 > I am open to suggestions but so far all the solutions I came up with = will introduce unacceptable complexity that will basically make this = work useless. > =20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Tue Aug 2 17:06:32 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8377811E80DD for ; Tue, 2 Aug 2011 17:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.977 X-Spam-Level: X-Spam-Status: No, score=-106.977 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzYepiyHBqZH for ; Tue, 2 Aug 2011 17:06:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 53CA411E8095 for ; Tue, 2 Aug 2011 17:06:30 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p7306Zki028781 for ; Tue, 2 Aug 2011 17:06:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312329996; bh=iL/q3F+KTGy2fjow6sDndZ+ep7Q=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=OBC1UKw8gv4+zhemda7k32ejvsMdN4KVRi6FDPkZvKKklqRdjXyj/tLK1ZPjKj8+A AKvtF5z5Y0UBcU08JOMHg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=BfIa5RV3pSlNgwCg5eP2lHpOilsECrl5jLz7pW6L9uU7tv58LkKa7K6Ug/9zz0atA LtHsoN21abX+o85k2LuBg== Received: from yxk38 (yxk38.prod.google.com [10.190.3.166]) by kpbe13.cbf.corp.google.com with ESMTP id p73057HW009567 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2011 17:06:34 -0700 Received: by yxk38 with SMTP id 38so254205yxk.2 for ; Tue, 02 Aug 2011 17:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qAREkXZ4oQAf3/kUSr5MEMAq9CKl4hzxBJh9OfYgZ5I=; b=HKZ5PzwkwRUnHq49NHv2gMJjeft4uDMpHqNqSO5jyOHAzjp9eJhVLAx26Txt6wNzPG S7SdmchrcbPevm6Kn8nQ== Received: by 10.101.87.1 with SMTP id p1mr4605064anl.35.1312329994330; Tue, 02 Aug 2011 17:06:34 -0700 (PDT) Received: by 10.101.87.1 with SMTP id p1mr4605058anl.35.1312329994108; Tue, 02 Aug 2011 17:06:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.194.13 with HTTP; Tue, 2 Aug 2011 17:06:14 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Tue, 2 Aug 2011 17:06:14 -0700 Message-ID: To: Aiden Bell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG , dr@fb.com Subject: Re: [OAUTH-WG] Device Profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:06:32 -0000 On Tue, Aug 2, 2011 at 3:19 PM, Aiden Bell wrote: > Hi, > > I am currently implementing the device profile described at > http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 > > Wanted to check this hadn't been superseded by any other document or > protocol > though I did notice the Google implementation is in-line with this docume= nt. Google's implementation is close, but it is not following the extension to the letter. Mostly because the OAuth 2 spec evolved since the extension was written. Here is the documentation: http://code.google.com/apis/accounts/docs/OAuth2ForDevices.html Marius > Even though the summary states this is intended for limited input devices= in > combination with a full user agent (PC browser, smartphone browser), > > We are finding this extension useful for app authentication when the API > serving the app is "open". This means that many developers can create > mobile apps for one API, in conjunction with single users. For example, > many apps may exist for the same API, and a single user may use many > apps. > > As a result, we want to remove the requirement for ever entering use > account-specific > data (passwords etc) into apps, and allow a user to revoke app/device acc= ess > on a per-instance > basis. The end-user concerns of password security are lessened here. > > With OpenID or WebID in the mix, this further enhances the app/device > authentication > process as in an OpenID/WebID or similar setting, we can't always do > resource owner password > credentals (as in 1.4.3 of OAuth 2.0 > http://tools.ietf.org/html/draft-ietf-oauth-v2-20 ) > > Unless I am missing another document or flow that provides the above bett= er, > (most likely I am) > perhaps it is worth extending the scope/summary of device-00? > > Also, typo in the JSON > > =A0 HTTP/1.1 200 OK > =A0 Content-Type: application/json > =A0 Cache-Control: no-store > > =A0 { > =A0=A0=A0 "device_code":"74tq5miHKB", > =A0=A0=A0 "user_code":"94248", > =A0=A0=A0 "verification_uri":"http://www.example.com/device", > =A0=A0=A0=A0 "interval"=3D5 > =A0=A0 } > > I think should be: > > =A0 HTTP/1.1 200 OK > =A0 Content-Type: application/json > =A0 Cache-Control: no-store > > =A0 { > =A0=A0=A0=A0 "device_code":"74tq5miHKB", > =A0=A0=A0=A0 "user_code":"94248", > =A0=A0=A0=A0 "verification_uri":"http://www.example.com/device", > =A0=A0=A0=A0 "interval":5 > =A0 } > > Thanks, > Aiden > > -- > ------------------------------------------------------------------ > Never send sensitive or private information via email unless it is > encrypted. http://www.gnupg.org > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From barryleiba.mailing.lists@gmail.com Tue Aug 2 17:28:16 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1169D11E810F for ; Tue, 2 Aug 2011 17:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.054 X-Spam-Level: X-Spam-Status: No, score=-103.054 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0R5J6Fx8OMh for ; Tue, 2 Aug 2011 17:28:15 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79AEC11E810E for ; Tue, 2 Aug 2011 17:28:15 -0700 (PDT) Received: by gyd5 with SMTP id 5so215943gyd.31 for ; Tue, 02 Aug 2011 17:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G9Jrmca4LifFi+xVL+Y3IuGN1M65q+vvHdeULsfVCYU=; b=M3j2y9Pu25TzW5TZan0yu6eOIU5GLrn1myCCrg3zn2ykk6YKxPbimeChePHGNSLTyG dpAOzwN90F4rlmSL3MIy/3+azl49tV/KT7b1na1XG1Ls0hOg4Iz9NNNJ/DEQ10c+tOwH a3tOc9xX2p2rbQ7V+dxjfa9fRI+QkMN8Hqj9E= MIME-Version: 1.0 Received: by 10.236.189.97 with SMTP id b61mr30671yhn.482.1312331304621; Tue, 02 Aug 2011 17:28:24 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.38.7 with HTTP; Tue, 2 Aug 2011 17:28:24 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F63D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723450245F61F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312214803.15068.YahooMailNeo@web31801.mail.mud.yahoo.com> <62E9072B-6687-4906-9241-717D6EBD8167@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723450245F63D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 2 Aug 2011 20:28:24 -0400 X-Google-Sender-Auth: L6irRFyjWuzsXtFnDWveixWuURE Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:28:16 -0000 On Tue, Aug 2, 2011 at 2:22 AM, Eran Hammer-Lahav wro= te: > I am going to drop both =91bodyhash=92 and =91ext=92, and instead add =91= app=92. =91app=92 > allows you to include any data you want. =91ext=92 without an internal fo= rmat > and register is just asking for trouble, and I have no intention of addin= g > that level of complexity. There are other proposals in the IETF for full > HTTP message signatures, and I=92ll leave these more complex use cases to > them. > > If you can demonstrate actual need (with examples) of both =91app=92 and = =91ext=92, > I=92m willing to reconsider but you can clearly accomplish the same end r= esult > with just one, application-specific parameter. Just a word of process stuff, here: draft-ietf-oauth-v2-http-mac is a working group document, not an individual submission. That means that the working group decides what gets changed, and we need to see consensus to make a change like this. "I am going to", "I have no intention of", and "I'm willing to reconsider" aren't appropriate. It might be that making this change is the right thing to do, but so far we have no one voicing support for the change (Skylar responded favourably to the initial message, but no one's supported removing "ext" in favour of "app"). Let's have more discussion before any decisions are made. And, in general, for all documents, let's please have editors making suggestions, not pronouncements. Tone is important. Barry, as chair From eran@hueniverse.com Tue Aug 2 17:55:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6089611E80F2 for ; Tue, 2 Aug 2011 17:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N1LeoCYa7G0 for ; Tue, 2 Aug 2011 17:55:19 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7807911E80D9 for ; Tue, 2 Aug 2011 17:55:19 -0700 (PDT) Received: (qmail 11415 invoked from network); 3 Aug 2011 00:55:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Aug 2011 00:55:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 2 Aug 2011 17:55:14 -0700 From: Eran Hammer-Lahav To: Barry Leiba Date: Tue, 2 Aug 2011 17:54:24 -0700 Thread-Topic: [OAUTH-WG] MAC Tokens body hash Thread-Index: AcxRdEJi7i0ybwY8QVyNE8gAE9IwpQAAOhcQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F661F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723450245F61F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312214803.15068.YahooMailNeo@web31801.mail.mud.yahoo.com> <62E9072B-6687-4906-9241-717D6EBD8167@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723450245F63D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:55:20 -0000 Yes, tone is important and I agree that this is a working group document an= d should follow process. This draft has shown practically no interest from this working group (last = count it was 3 people other than me). If there was no requirement from the = AD to include this as part of the OAuth 2.0 "package", it would have stayed= as an individual submission. Given that this is largely my work (to-date) and that the working group eng= agement is almost non-existent, moving forward is more likely going to come= from me putting forward proposals in the document with [[ Pending Consensu= s ]] labels than from trying to get engagement. Unless the chairs are going= to actively poke the group to engage (which I have seen no sign of), I'm n= ot expecting much to change. At this point we have established the practice of suggesting text within th= e document itself as long as it is clearly marked and we have an open issue= in the tracker. I'm going to follow that practice and make the proposed ch= anges in order to move things along at a practical pace. I'll also adjust m= y tone to address any concerns. EHL > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com > [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba > Sent: Tuesday, August 02, 2011 5:28 PM > To: Eran Hammer-Lahav > Cc: Phil Hunt; William J. Mills; OAuth WG > Subject: Re: [OAUTH-WG] MAC Tokens body hash >=20 > On Tue, Aug 2, 2011 at 2:22 AM, Eran Hammer-Lahav > wrote: > > I am going to drop both 'bodyhash' and 'ext', and instead add 'app'. 'a= pp' > > allows you to include any data you want. 'ext' without an internal > > format and register is just asking for trouble, and I have no > > intention of adding that level of complexity. There are other > > proposals in the IETF for full HTTP message signatures, and I'll leave > > these more complex use cases to them. > > > > If you can demonstrate actual need (with examples) of both 'app' and > > 'ext', I'm willing to reconsider but you can clearly accomplish the > > same end result with just one, application-specific parameter. >=20 > Just a word of process stuff, here: draft-ietf-oauth-v2-http-mac is a wor= king > group document, not an individual submission. That means that the workin= g > group decides what gets changed, and we need to see consensus to make a > change like this. "I am going to", "I have no intention of", and "I'm wi= lling to > reconsider" aren't appropriate. >=20 > It might be that making this change is the right thing to do, but so far = we have > no one voicing support for the change (Skylar responded favourably to the > initial message, but no one's supported removing "ext" in favour of "app"= ). > Let's have more discussion before any decisions are made. And, in genera= l, > for all documents, let's please have editors making suggestions, not > pronouncements. Tone is important. >=20 > Barry, as chair From eran@hueniverse.com Tue Aug 2 18:03:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7E111E8111 for ; Tue, 2 Aug 2011 18:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYUTRLRwjzO7 for ; Tue, 2 Aug 2011 18:03:25 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 669EA11E810E for ; Tue, 2 Aug 2011 18:03:25 -0700 (PDT) Received: (qmail 1224 invoked from network); 3 Aug 2011 01:03:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Aug 2011 01:03:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 2 Aug 2011 18:03:29 -0700 From: Eran Hammer-Lahav To: Skylar Woodward Date: Tue, 2 Aug 2011 18:02:39 -0700 Thread-Topic: [OAUTH-WG] MAC Tokens body hash Thread-Index: AcxRaDGRJCRCrcPBR6el4syfcaLtsAAD8EtA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ben Adida , OAuth WG , "'Adam Barth \(adam@adambarth.com\)'" Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 01:03:26 -0000 The idea is to drop 'ext' and 'bodyhash' due to being underspecified and th= erefore causing more harm than good. I added 'ext' to allow for application= specific data to be included in the signed content. However, the name sugg= ests this is an extension point for future specifications. I believe authen= tication schemes should not be extensible in ways that affect their securit= y or interop properties and without additional text (registry, process, etc= ) for the 'ext' parameter, it will cause more issues than help. Instead of the 'ext' parameter I am suggesting the 'app' parameter which wi= ll do the same, but will be better positioned as an application-specific da= ta. The prose will go a step further and recommend that the parameter value= include a hash of the data, not the data itself. This is to ensure the par= ameter does not become part of the payload which is inappropriate for HTTP = requests. As for the 'bodyhash' parameter, I would like to remove it because it is un= derspecified (we had an actual deployment experience showing that it doesn'= t produce interoperable implementations due to the many HTTP body transform= ation applied in most frameworks). Solving this issue is not possible due t= o the many different types of bodies and frameworks (and clearly operating = on the "raw" body doesn't work). Instead, developers can use the new 'app' = parameter to accomplish that. As for the normalized string, it will be adjusted to reflect these changes = when they are made, so no placeholders which will require code change. Cons= idering this is -00, it is clearly not a stable document. Will these changes work with your use cases? EHL > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Tuesday, August 02, 2011 4:02 PM > To: Eran Hammer-Lahav > Cc: OAuth WG; Ben Adida; 'Adam Barth (adam@adambarth.com)' > Subject: Re: [OAUTH-WG] MAC Tokens body hash >=20 > hurrah! > (not necessarily for losing a way to sign the body, but for simplicity an= d > avoiding some of the potential inconsistencies w/ bodyhash). >=20 > Is your plan to reserve an empty line 6 for the Normalized Request String > (which was used for bodyhash) or eliminate it, brining the total to six > elements? >=20 > skylar >=20 > On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote: >=20 > > I plan to drop support for the bodyhash parameter in the next draft bas= ed > on bad implementation experience. Even with simple text body, UTF > encoding has introduced significant issues for us. The current draft does= not > work using simple JS code between a browser and node.js even when both > use the same v8 engine due to differences in the body encoding. Basically= , > the JS string used to send a request from the browser is not the actual s= tring > sent on the wire. > > > > To fix that, we need to force UTF-8 encoding on both sides. However, th= at > is very much application specific. This will not work for non-text bodies= . > Instead, the specification should offer a simple way to use the ext param= eter > for such needs, including singing headers. And by offer I mean give > examples, but leave it application specific for now. > > > > I am open to suggestions but so far all the solutions I came up with wi= ll > introduce unacceptable complexity that will basically make this work usel= ess. > > > > EHL > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Tue Aug 2 19:15:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A38D11E80A7 for ; Tue, 2 Aug 2011 19:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-1.436, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn6qYtLoXMaE for ; Tue, 2 Aug 2011 19:15:18 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2F011E8073 for ; Tue, 2 Aug 2011 19:15:18 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p732F1cR021786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 3 Aug 2011 02:15:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p732F0U9009647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2011 02:15:01 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p732EtLb018700; Tue, 2 Aug 2011 21:14:55 -0500 Received: from [192.168.1.67] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Aug 2011 19:14:55 -0700 References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--976955230 Message-Id: X-Mailer: iPhone Mail (8L1) From: Phillip Hunt Date: Tue, 2 Aug 2011 19:14:51 -0700 To: Eran Hammer-Lahav X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4E38AF28.0018:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: Ben Adida , OAuth WG , "Adam Barth\(adam@adambarth.com\)" Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 02:15:19 -0000 --Apple-Mail-1--976955230 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Phil On 2011-08-02, at 18:02, Eran Hammer-Lahav wrote: > The idea is to drop 'ext' and 'bodyhash' due to being underspecified and t= herefore causing more harm than good. I added 'ext' to allow for application= specific data to be included in the signed content. However, the name sugge= sts this is an extension point for future specifications. I believe authenti= cation schemes should not be extensible in ways that affect their security o= r interop properties and without additional text (registry, process, etc) fo= r the 'ext' parameter, it will cause more issues than help. >=20 > Instead of the 'ext' parameter I am suggesting the 'app' parameter which w= ill do the same, but will be better positioned as an application-specific da= ta. The prose will go a step further and recommend that the parameter value i= nclude a hash of the data, not the data itself. This is to ensure the parame= ter does not become part of the payload which is inappropriate for HTTP requ= ests. -1 what you describe appears to be a separate feature from ext >=20 > As for the 'bodyhash' parameter, I would like to remove it because it is u= nderspecified (we had an actual deployment experience showing that it doesn'= t produce interoperable implementations due to the many HTTP body transforma= tion applied in most frameworks). Solving this issue is not possible due to t= he many different types of bodies and frameworks (and clearly operating on t= he "raw" body doesn't work). Instead, developers can use the new 'app' param= eter to accomplish that. +1 >=20 > As for the normalized string, it will be adjusted to reflect these changes= when they are made, so no placeholders which will require code change. Cons= idering this is -00, it is clearly not a stable document. >=20 > Will these changes work with your use cases? >=20 > EHL >=20 >> -----Original Message----- >> From: Skylar Woodward [mailto:skylar@kiva.org] >> Sent: Tuesday, August 02, 2011 4:02 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG; Ben Adida; 'Adam Barth (adam@adambarth.com)' >> Subject: Re: [OAUTH-WG] MAC Tokens body hash >>=20 >> hurrah! >> (not necessarily for losing a way to sign the body, but for simplicity an= d >> avoiding some of the potential inconsistencies w/ bodyhash). >>=20 >> Is your plan to reserve an empty line 6 for the Normalized Request String= >> (which was used for bodyhash) or eliminate it, brining the total to six >> elements? >>=20 >> skylar >>=20 >> On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote: >>=20 >>> I plan to drop support for the bodyhash parameter in the next draft base= d >> on bad implementation experience. Even with simple text body, UTF >> encoding has introduced significant issues for us. The current draft does= not >> work using simple JS code between a browser and node.js even when both >> use the same v8 engine due to differences in the body encoding. Basically= , >> the JS string used to send a request from the browser is not the actual s= tring >> sent on the wire. >>>=20 >>> To fix that, we need to force UTF-8 encoding on both sides. However, tha= t >> is very much application specific. This will not work for non-text bodies= . >> Instead, the specification should offer a simple way to use the ext param= eter >> for such needs, including singing headers. And by offer I mean give >> examples, but leave it application specific for now. >>>=20 >>> I am open to suggestions but so far all the solutions I came up with wil= l >> introduce unacceptable complexity that will basically make this work usel= ess. >>>=20 >>> EHL >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1--976955230 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


Phil

On 2011-08-0= 2, at 18:02, Eran Hammer-Lahav <er= an@hueniverse.com> wrote:

The idea is to drop 'ext' and 'bodyhash' due to being unde= rspecified and therefore causing more harm than good. I added 'ext' to allow= for application specific data to be included in the signed content. However= , the name suggests this is an extension point for future specifications. I b= elieve authentication schemes should not be extensible in ways that affect t= heir security or interop properties and without additional text (registry, p= rocess, etc) for the 'ext' parameter, it will cause more issues than help.

Instead of the 'ext' parameter I am suggesti= ng the 'app' parameter which will do the same, but will be better positioned= as an application-specific data. The prose will go a step further and recom= mend that the parameter value include a hash of the data, not the data itsel= f. This is to ensure the parameter does not become part of the payload which= is inappropriate for HTTP requests.
-1 what yo= u describe appears to be a separate feature from ext

As for the 'bodyhash' parameter, I would l= ike to remove it because it is underspecified (we had an actual deployment e= xperience showing that it doesn't produce interoperable implementations due t= o the many HTTP body transformation applied in most frameworks). Solving thi= s issue is not possible due to the many different types of bodies and framew= orks (and clearly operating on the "raw" body doesn't work). Instead, develo= pers can use the new 'app' parameter to accomplish that.

+1


As for the normalized string, it will be adjusted to reflect t= hese changes when they are made, so no placeholders which will require code c= hange. Considering this is -00, it is clearly not a stable document.<= br>
Will these changes work with your use cases?

EHL

-----Original Message-----
From: Skylar Woodward [mailto:skylar@kiva.org]<= br>
Sent: Tuesday, August 02, 20= 11 4:02 PM
To: Eran H= ammer-Lahav
Cc: OAuth= WG; Ben Adida; 'Adam Barth (adam@adam= barth.com)'
Subje= ct: Re: [OAUTH-WG] MAC Tokens body hash

h= urrah!
(not necessari= ly for losing a way to sign the body, but for simplicity and
avoiding some of the potential incon= sistencies w/ bodyhash).

Is your plan to r= eserve an empty line 6 for the Normalized Request String
(which was used for bodyhash) or elimina= te it, brining the total to six
elements?
=
skylar

On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote:<= /span>

I plan to drop s= upport for the bodyhash parameter in the next draft based
on bad implementation expe= rience. Even with simple text body, UTF
encoding has introduced significant issues for us. The cu= rrent draft does not
= work using simple JS code between a browser and node.js even when both
use the same v8 engine due= to differences in the body encoding. Basically,
the JS string used to send a request from the br= owser is not the actual string
sent on the wire.

To fix that, we need to f= orce UTF-8 encoding on both sides. However, that
is very much application specific. T= his will not work for non-text bodies.
Instead, the specification should offer a simple way to us= e the ext parameter
f= or such needs, including singing headers. And by offer I mean give
examples, but leave it applica= tion specific for now.

I am open to suggestions but s= o far all the solutions I came up with will
introduce unacceptable complexity that w= ill basically make this work useless.

EHL
=
_______________________________________________
OA= uth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth

___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth
= --Apple-Mail-1--976955230-- From wmills@yahoo-inc.com Wed Aug 3 10:27:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C383621F84EC for ; Wed, 3 Aug 2011 10:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.581 X-Spam-Level: X-Spam-Status: No, score=-16.581 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ARA0tJZ7T5l for ; Wed, 3 Aug 2011 10:27:46 -0700 (PDT) Received: from nm14-vm0.bullet.mail.ac4.yahoo.com (nm14-vm0.bullet.mail.ac4.yahoo.com [98.139.52.234]) by ietfa.amsl.com (Postfix) with SMTP id 33DDC21F84E9 for ; Wed, 3 Aug 2011 10:27:45 -0700 (PDT) Received: from [98.139.52.191] by nm14.bullet.mail.ac4.yahoo.com with NNFMP; 03 Aug 2011 17:27:55 -0000 Received: from [98.139.52.138] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 03 Aug 2011 17:27:55 -0000 Received: from [127.0.0.1] by omp1021.mail.ac4.yahoo.com with NNFMP; 03 Aug 2011 17:27:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 403467.27656.bm@omp1021.mail.ac4.yahoo.com Received: (qmail 31869 invoked by uid 60001); 3 Aug 2011 17:27:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1312392474; bh=MekHWMz9yy3yoS/fs7WK11LHAzPJeECIAW25mI2jnEc=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q0XHwkd7HzyS8wJyZ67xi3mdMCaGLSqGxeiyk7EK9wxnEhJBFWx925h1b6CrSp97BFL2GOqc4bTHRj3ovj/zeOCC/vfLtNueidWjiy3mFYwld5jAoHTXEIxfgaEdq+0CYzrP2gt3z0gICJQ7AF4h+s3tK+harHqWyxC45YfWroQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NlLpgi/GMjEGvA+Vc/tFak0XNMcCAfBPs4VXSzv2xqb9uX0UmLHL1m73z57GiZpNhU6PQkBd8TM5KcS/hBqC5O4V/cNiuPjuGCbAGmd6PRzeAbtanWRK4IB4YKY5emWcbtyI8Upiwo+fwzN3uS3IzCvtZa/h56md/PBJf+lTX0E=; X-YMail-OSG: JmHCWeoVM1kSn2bPtnjrc9ShOfWLtHcRWOIUqF034Gj069K WqpyAQB_FbLFMEvRSFcJ0teT2SmoKWAjj1pbTFlbcNiInnfcEs4HHkyW.ywn Axs6iVycVmmCeKOmZHs7wiQjSp7Wtf9UBFCBaMS5C0N6kK8Zo9ZipuRiU0YX mq3yDHouZexTIIU3t60HSEkbidm5QHWRXbXU4exgAab2RzDaDNijTbtRBkLA TtIE3zn5ElTzY0F5gYK0n_Qg9yMRXY8dybLTunC5NVIj_VnZvw7lXMl5ABrj 9WiVINa8FJMiCqwxIuNTJpEXVi_KZICbwZGwb777VTKT3fbkmInk07qlVKDQ KwPKzbvkrYFAcwNkLmyXo5nS7dERqrHlvV0ck4lVR_2UEoF1HNyxIonIQn68 4 Received: from [209.131.62.115] by web31801.mail.mud.yahoo.com via HTTP; Wed, 03 Aug 2011 10:27:54 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Wed, 3 Aug 2011 10:27:54 -0700 (PDT) From: "William J. Mills" To: Phillip Hunt , Eran Hammer-Lahav In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-660586481-1312392474=:29804" Cc: Ben Adida , OAuth WG , "Adam Barth\(adam@adambarth.com\)" Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:27:47 -0000 --0-660586481-1312392474=:29804 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In thinking about this I'm coming around to the viewpoint that a single add= itional predefined spot is sufficient.=A0 If the app developer wants to inc= lude addtional data there (iun the specified format) that's fine.=A0 If wha= t they want to do is include a signature of other payload that's fine too.= =0A=0AI'm not in love with the name "app" though, "ext" is better.=0A=0A=0A= =0A________________________________=0AFrom: Phillip Hunt =0ATo: Eran Hammer-Lahav =0ACc: Ben Adida ; OAuth WG ; "Adam Barth(adam@adambarth.com)" =0ASent: Tuesday, August 2, 2011 7:14 PM=0ASubject: Re: [OAUT= H-WG] MAC Tokens body hash=0A=0A=0A=0A=0APhil=0A=0AOn 2011-08-02, at 18:02,= Eran Hammer-Lahav wrote:=0A=0A=0AThe idea is to drop= 'ext' and 'bodyhash' due to being underspecified and therefore causing mor= e harm than good. I added 'ext' to allow for application specific data to b= e included in the signed content. However, the name suggests this is an ext= ension point for future specifications. I believe authentication schemes sh= ould not be extensible in ways that affect their security or interop proper= ties and without additional text (registry, process, etc) for the 'ext' par= ameter, it will cause more issues than help.=0A>=0A>Instead of the 'ext' pa= rameter I am suggesting the 'app' parameter which will do the same, but wil= l be better positioned as an application-specific data. The prose will go a= step further and recommend that the parameter value include a hash of the = data, not the data itself. This is to ensure the parameter does not become = part of the payload which is inappropriate for HTTP requests.=0A>-1 what yo= u describe appears to be a separate feature from ext=0A=0A=0A>As for the 'b= odyhash' parameter, I would like to remove it because it is underspecified = (we had an actual deployment experience showing that it doesn't produce int= eroperable implementations due to the many HTTP body transformation applied= in most frameworks). Solving this issue is not possible due to the many di= fferent types of bodies and frameworks (and clearly operating on the "raw" = body doesn't work). Instead, developers can use the new 'app' parameter to = accomplish that.=0A>=0A+1=0A=0A=0A=0A>As for the normalized string, it will= be adjusted to reflect these changes when they are made, so no placeholder= s which will require code change. Considering this is -00, it is clearly no= t a stable document.=0A>=0A>=0AWill these changes work with your use cases?= =0A>=0A>EHL=0A>=0A>=0A>-----Original Message-----=0A>>=0A>From: Skylar Wood= ward [mailto:skylar@kiva.org]=0A>>=0A>Sent: Tuesday, August 02, 2011 4:02 P= M=0A>>=0A>To: Eran Hammer-Lahav=0A>>=0A>Cc: OAuth WG; Ben Adida; 'Adam Bart= h (adam@adambarth.com)'=0A>>=0A>Subject: Re: [OAUTH-WG] MAC Tokens body has= h=0A>>=0A>=0A>>=0A>hurrah!=0A>>=0A>(not necessarily for losing a way to sig= n the body, but for simplicity and=0A>>=0A>avoiding some of the potential i= nconsistencies w/ bodyhash).=0A>>=0A>=0A>>=0A>Is your plan to reserve an em= pty line 6 for the Normalized Request String=0A>>=0A>(which was used for bo= dyhash) or eliminate it, brining the total to six=0A>>=0A>elements?=0A>>=0A= >=0A>>=0A>skylar=0A>>=0A>=0A>>=0A>On Jul 30, 2011, at 3:43 AM, Eran Hammer-= Lahav wrote:=0A>>=0A>=0A>>=0A>I plan to drop support for the bodyhash param= eter in the next draft based=0A>>>=0A>on bad implementation experience. Eve= n with simple text body, UTF=0A>>=0A>encoding has introduced significant is= sues for us. The current draft does not=0A>>=0A>work using simple JS code b= etween a browser and node.js even when both=0A>>=0A>use the same v8 engine = due to differences in the body encoding. Basically,=0A>>=0A>the JS string u= sed to send a request from the browser is not the actual string=0A>>=0A>sen= t on the wire.=0A>>=0A>=0A>>>=0A>To fix that, we need to force UTF-8 encodi= ng on both sides. However, that=0A>>>=0A>is very much application specific.= This will not work for non-text bodies.=0A>>=0A>Instead, the specification= should offer a simple way to use the ext parameter=0A>>=0A>for such needs,= including singing headers. And by offer I mean give=0A>>=0A>examples, but = leave it application specific for now.=0A>>=0A>=0A>>>=0A>I am open to sugge= stions but so far all the solutions I came up with will=0A>>>=0A>introduce = unacceptable complexity that will basically make this work useless.=0A>>=0A= >=0A>>>=0A>EHL=0A>>>=0A>_______________________________________________=0A>= >>=0A>OAuth mailing list=0A>>>=0A>OAuth@ietf.org=0A>>>=0A>https://www.ietf.= org/mailman/listinfo/oauth=0A>>>=0A>_______________________________________= ________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://www.ietf.org/ma= ilman/listinfo/oauth=0A>=0A_______________________________________________= =0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/oauth --0-660586481-1312392474=:29804 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In thinking about this I'm coming around to the viewpoint that a single a= dditional predefined spot is sufficient.  If the app developer wants t= o include addtional data there (iun the specified format) that's fine. = ; If what they want to do is include a signature of other payload that's fi= ne too.

I'm not in love = with the name "app" though, "ext" is better.

From: Phillip Hunt &= lt;phil.hunt@oracle.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: Ben Adida <ben@adida.net>; OAuth WG <o= auth@ietf.org>; "Adam Barth(adam@adambarth.com)" <adam@adambarth.com&= gt;
Sent: Tuesday, Augu= st 2, 2011 7:14 PM
Subject:= Re: [OAUTH-WG] MAC Tokens body hash



Phil

On 2011-08-02, at 18:02, Eran Hammer-= Lahav <eran@hueniverse.com>= wrote:

The id= ea is to drop 'ext' and 'bodyhash' due to being underspecified and therefor= e causing more harm than good. I added 'ext' to allow for application speci= fic data to be included in the signed content. However, the name suggests t= his is an extension point for future specifications. I believe authentication scheme= s should not be extensible in ways that affect their security or interop pr= operties and without additional text (registry, process, etc) for the 'ext'= parameter, it will cause more issues than help.
Instead of the 'ext' parameter I am suggesting the 'app' parameter w= hich will do the same, but will be better positioned as an application-spec= ific data. The prose will go a step further and recommend that the paramete= r value include a hash of the data, not the data itself. This is to ensure = the parameter does not become part of the payload which is inappropriate fo= r HTTP requests.
-1 what you describe appears = to be a separate feature from ext
<= /span>
As for the 'bodyhash' parameter, I would like to remove it = because it is underspecified (we had an actual deployment experience showing that it doesn't produce interoperable implementations due to the m= any HTTP body transformation applied in most frameworks). Solving this issu= e is not possible due to the many different types of bodies and frameworks = (and clearly operating on the "raw" body doesn't work). Instead, developers= can use the new 'app' parameter to accomplish that.

+1


As for the normalized string, it will be adjusted to reflect th= ese changes when they are made, so no placeholders which will require code = change. Considering this is -00, it is clearly not a stable document.

Will these changes= work with your use cases?

EHL

-----Original Message-----
From: Skylar Woodward [mailto:skylar@ki= va.org]
Sent: Tuesda= y, August 02, 2011 4:02 PM
To: Eran Hammer-Lahav
Cc: OAuth WG; Ben Adida; 'Adam Barth (adam@adambarth.com)'
Subject: Re: [OAUTH-WG] MAC Tokens body hash

hurrah!
(not necessarily for losing a way to sign the body, but for simpl= icity and
avoiding some o= f the potential inconsistencies w/ bodyhash).

Is your plan to reserve an empty line 6 for the Normalized Request S= tring
(which was use= d for bodyhash) or eliminate it, brining the total to six
elements?

skylar

On Jul 30, 2011, at 3:4= 3 AM, Eran Hammer-Lahav wrote:

I plan to drop support for the bodyhash parameter in the = next draft based
= on bad implementation experience. Even with simple text body, UTF
encoding has introduced signi= ficant issues for us. The current draft does not
work using simple JS code between a browser an= d node.js even when both
<= span>use the same v8 engine due to differences in the body encoding. Basica= lly,
the JS string u= sed to send a request from the browser is not the actual string
<= /blockquote>
sent on the wire.
=
To fix that, we need to force UTF-8 encoding on both sides. Ho= wever, that
i= s very much application specific. This will not work for non-text bodies.
Instead, the specific= ation should offer a simple way to use the ext parameter
for such needs, including singing head= ers. And by offer I mean give
examples, but leave it application specific for now.

I am open to suggestions but so far all the solutions I cam= e up with will
introduce unacceptable complexity that will basically make this wor= k useless.

EHL
__________= _____________________________________
<= blockquote type=3D"cite">
OAuth mailing list=
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /span>

________________= _______________________________
OAuth mailing listOAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
<= br>_______________________________________________
OAuth mailing listOAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth


<= /div>
--0-660586481-1312392474=:29804-- From eran@hueniverse.com Wed Aug 3 11:04:05 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6BF21F8557 for ; Wed, 3 Aug 2011 11:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNJqW7gKEX16 for ; Wed, 3 Aug 2011 11:04:01 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 77A6E21F881C for ; Wed, 3 Aug 2011 11:04:01 -0700 (PDT) Received: (qmail 26106 invoked from network); 3 Aug 2011 18:04:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Aug 2011 18:04:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 3 Aug 2011 11:04:04 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , Phillip Hunt Date: Wed, 3 Aug 2011 11:03:12 -0700 Thread-Topic: [OAUTH-WG] MAC Tokens body hash Thread-Index: AcxSArFyk5eSjzWDSZ+2LLCRiY70GwAAFS+g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345024864560@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345024864560P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Ben Adida , OAuth WG , "Adam Barth\(adam@adambarth.com\)" Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:04:05 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345024864560P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My proposal is to change 'ext' to 'app', keep the same prose as 'ext', and = add the use case of 'bodyhash' as an example. I'm not too stuck on the name= , but my thinking is that 'app' relays the right message that this is a pla= ce where developers can stick any application data they want included. 'ext= ' conveys the idea of extensions which I'm not so thrilled about. In other words, I'd like a developer reading this to feel comfortable using= it right away for securing addition bits such as a JSON payload, but I don= 't like the idea of someone publishing an I-D with a full syntax and canoni= calization requirements for say, singing an entire request, headers and all= . I feel that would be much better accomplished by defining a new HTTP auth= entication scheme. Philosophically, I think extensible authentication schemes are a bad idea. EHL From: William J. Mills [mailto:wmills@yahoo-inc.com] Sent: Wednesday, August 03, 2011 10:28 AM To: Phillip Hunt; Eran Hammer-Lahav Cc: Ben Adida; OAuth WG; Adam Barth(adam@adambarth.com) Subject: Re: [OAUTH-WG] MAC Tokens body hash In thinking about this I'm coming around to the viewpoint that a single add= itional predefined spot is sufficient. If the app developer wants to inclu= de addtional data there (iun the specified format) that's fine. If what th= ey want to do is include a signature of other payload that's fine too. I'm not in love with the name "app" though, "ext" is better. ________________________________ From: Phillip Hunt > To: Eran Hammer-Lahav > Cc: Ben Adida >; OAuth WG >; "Adam Barth(adam@adambarth.com)" > Sent: Tuesday, August 2, 2011 7:14 PM Subject: Re: [OAUTH-WG] MAC Tokens body hash Phil On 2011-08-02, at 18:02, Eran Hammer-Lahav > wrote: The idea is to drop 'ext' and 'bodyhash' due to being underspecified and th= erefore causing more harm than good. I added 'ext' to allow for application= specific data to be included in the signed content. However, the name sugg= ests this is an extension point for future specifications. I believe authen= tication schemes should not be extensible in ways that affect their securit= y or interop properties and without additional text (registry, process, etc= ) for the 'ext' parameter, it will cause more issues than help. Instead of the 'ext' parameter I am suggesting the 'app' parameter which wi= ll do the same, but will be better positioned as an application-specific da= ta. The prose will go a step further and recommend that the parameter value= include a hash of the data, not the data itself. This is to ensure the par= ameter does not become part of the payload which is inappropriate for HTTP = requests. -1 what you describe appears to be a separate feature from ext As for the 'bodyhash' parameter, I would like to remove it because it is un= derspecified (we had an actual deployment experience showing that it doesn'= t produce interoperable implementations due to the many HTTP body transform= ation applied in most frameworks). Solving this issue is not possible due t= o the many different types of bodies and frameworks (and clearly operating = on the "raw" body doesn't work). Instead, developers can use the new 'app' = parameter to accomplish that. +1 As for the normalized string, it will be adjusted to reflect these changes = when they are made, so no placeholders which will require code change. Cons= idering this is -00, it is clearly not a stable document. Will these changes work with your use cases? EHL -----Original Message----- From: Skylar Woodward [mailto:skylar@kiva.org] Sent: Tuesday, August 02, 2011 4:02 PM To: Eran Hammer-Lahav Cc: OAuth WG; Ben Adida; 'Adam Barth (adam@adambarth.com)' Subject: Re: [OAUTH-WG] MAC Tokens body hash hurrah! (not necessarily for losing a way to sign the body, but for simplicity and avoiding some of the potential inconsistencies w/ bodyhash). Is your plan to reserve an empty line 6 for the Normalized Request String (which was used for bodyhash) or eliminate it, brining the total to six elements? skylar On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote: I plan to drop support for the bodyhash parameter in the next draft based on bad implementation experience. Even with simple text body, UTF encoding has introduced significant issues for us. The current draft does n= ot work using simple JS code between a browser and node.js even when both use the same v8 engine due to differences in the body encoding. Basically, the JS string used to send a request from the browser is not the actual str= ing sent on the wire. To fix that, we need to force UTF-8 encoding on both sides. However, that is very much application specific. This will not work for non-text bodies. Instead, the specification should offer a simple way to use the ext paramet= er for such needs, including singing headers. And by offer I mean give examples, but leave it application specific for now. I am open to suggestions but so far all the solutions I came up with will introduce unacceptable complexity that will basically make this work useles= s. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72345024864560P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My propos= al is to change ‘ext’ to ‘app’, keep = the same prose as ‘ext’, and add the use case of ‘bodyhas= h’ as an example. I’m not too stuck on the name, but my thinkin= g is that ‘app’ relays the right message that this is a place w= here developers can stick any application data they want included. ‘e= xt’ conveys the idea of extensions which I’m not so thrilled ab= out.

 

In other words, I’d like a develop= er reading this to feel comfortable using it right away for securing additi= on bits such as a JSON payload, but I don’t like the idea of someone = publishing an I-D with a full syntax and canonicalization requirements for = say, singing an entire request, headers and all. I feel that would be much = better accomplished by defining a new HTTP authentication scheme.

 

Philosophically, I think extensible authentication sch= emes are a bad idea.

 

EHL

 

 

From: William J. Mills [mailto:wmills@yahoo-inc.com]
Sent: W= ednesday, August 03, 2011 10:28 AM
To: Phillip Hunt; Eran Hammer-= Lahav
Cc: Ben Adida; OAuth WG; Adam Barth(adam@adambarth.com)
= Subject: Re: [OAUTH-WG] MAC Tokens body hash

 

In thinking about this I'm coming around to the viewpoint tha= t a single additional predefined spot is sufficient.  If the app devel= oper wants to include addtional data there (iun the specified format) that'= s fine.  If what they want to do is include a signature of other paylo= ad that's fine too.

 

I'm n= ot in love with the name "app" though, "ext" is better.=

 

From: Phillip Hunt <phil.hunt@oracle.com>
To: Eran Ha= mmer-Lahav <eran@hueniverse.com>
Cc: Ben Adida <ben@adi= da.net>; OAuth WG <oauth@ietf.o= rg>; "Adam Barth(adam@ada= mbarth.com)" <adam@adamba= rth.com>
Sent: Tuesday, August 2, 2011 7:14 PM
Subje= ct: Re: [OAUTH-WG] MAC Tokens body hash



Phil


On 2011-08-02, at 18:02,= Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The idea is to dro= p 'ext' and 'bodyhash' due to being underspecified and therefore causing mo= re harm than good. I added 'ext' to allow for application specific data to = be included in the signed content. However, the name suggests this is an ex= tension point for future specifications. I believe authentication schemes s= hould not be extensible in ways that affect their security or interop prope= rties and without additional text (registry, process, etc) for the 'ext' pa= rameter, it will cause more issues than help.

Instead of the 'ext' p= arameter I am suggesting the 'app' parameter which will do the same, but wi= ll be better positioned as an application-specific data. The prose will go = a step further and recommend that the parameter value include a hash of the= data, not the data itself. This is to ensure the parameter does not become= part of the payload which is inappropriate for HTTP requests.

-1 what you describe appears to be a separate = feature from ext


As for the 'bodyhas= h' parameter, I would like to remove it because it is underspecified (we ha= d an actual deployment experience showing that it doesn't produce interoper= able implementations due to the many HTTP body transformation applied in mo= st frameworks). Solving this issue is not possible due to the many differen= t types of bodies and frameworks (and clearly operating on the "raw&qu= ot; body doesn't work). Instead, developers can use the new 'app' parameter= to accomplish that.

 

+1



<= div>


As for the normalized string, it will be adju= sted to reflect these changes when they are made, so no placeholders which = will require code change. Considering this is -00, it is clearly not a stab= le document.

Will these changes work with your use cases?<= br>
EHL


-----Original Message-----

From: Skylar Woodward [mailt= o:skylar@kiva.org]

Sent: Tuesday, August 02, 2011 4= :02 PM

To: Eran Hammer-Lahav

Cc: OAu= th WG; Ben Adida; 'Adam Barth (adam@adambarth.com)'

Subject: Re: [OAUTH= -WG] MAC Tokens body hash

 

hurr= ah!

(not necessarily for losing a way to sign the body, = but for simplicity and

avoiding some of the potential i= nconsistencies w/ bodyhash).

 <= /p>

=

Is your plan to reserve an empty line 6 for the Normalized Request String<= o:p>

(which was used for bodyhash) or eliminate it, brining t= he total to six

elements?

 =

skylar

 

On Jul= 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote:

&n= bsp;

I plan to drop support for the bodyhash parameter in the next draft base= d

on bad implementation experience. Even wi= th simple text body, UTF

encoding has introduced signifi= cant issues for us. The current draft does not

work us= ing simple JS code between a browser and node.js even when both<= /span>

use the same v8 engine due to differences in the body encoding. Bas= ically,

<= span style=3D'color:black'>the JS string used to send a request from the br= owser is not the actual string

sent on the wire.

 

To fix that, we need to force UTF-8 encoding on both sid= es. However, that

is very much application = specific. This will not work for non-text bodies.

Instea= d, the specification should offer a simple way to use the ext parameter

for such needs, including singing headers. And by offer I = mean give

examples, but leave it application specific fo= r now.

 

I am open to suggestions but so far all th= e solutions I came up with will

introduce u= nacceptable complexity that will basically make this work useless.

=  

EHL

_____________________________________= __________

<= span style=3D'color:black'>OAuth mailing list

OAuth@ietf.org=

<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
O= Auth mailing list
OA= uth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_____= __________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth

<= /div>= --_000_90C41DD21FB7C64BB94121FBBC2E72345024864560P3PW5EX1MB01E_-- From phil.hunt@oracle.com Wed Aug 3 12:42:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFFB11E8094 for ; Wed, 3 Aug 2011 12:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.311 X-Spam-Level: X-Spam-Status: No, score=-3.311 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy0LgxuJgGkV for ; Wed, 3 Aug 2011 12:42:20 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0E49C11E8086 for ; Wed, 3 Aug 2011 12:42:19 -0700 (PDT) Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p73JgTvU007662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Aug 2011 19:42:31 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p73JgRDL027155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Aug 2011 19:42:29 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p73JgLpL003594 for ; Wed, 3 Aug 2011 14:42:21 -0500 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Aug 2011 12:42:21 -0700 From: Phil Hunt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-17--914108325 Date: Wed, 3 Aug 2011 12:42:20 -0700 In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345024864560@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: OAuth WG References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72345024864560@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: <81B6B8AF-4EC0-4F08-B48C-D1E7B39AE506@oracle.com> X-Mailer: Apple Mail (2.1084) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E39A4A8.0079,ss=1,re=-6.500,fgs=0 Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:42:21 -0000 --Apple-Mail-17--914108325 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Only allowing (implied or not) app data is needlessly narrow in scope. Extending MAC to include claims or session information is a perfectly = valid thing to do. It improves scalability and reduces the need to look = up artifact data.=20 Note: I'd like to share more on this, but I'm prioritizing the Threat = Model document. Never-the-less, the above should be a sufficient example = about why extensibility is useful. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-03, at 11:03 AM, Eran Hammer-Lahav wrote: > My proposal is to change =91ext=92 to =91app=92, keep the same prose = as =91ext=92, and add the use case of =91bodyhash=92 as an example. I=92m = not too stuck on the name, but my thinking is that =91app=92 relays the = right message that this is a place where developers can stick any = application data they want included. =91ext=92 conveys the idea of = extensions which I=92m not so thrilled about. > =20 > In other words, I=92d like a developer reading this to feel = comfortable using it right away for securing addition bits such as a = JSON payload, but I don=92t like the idea of someone publishing an I-D = with a full syntax and canonicalization requirements for say, singing an = entire request, headers and all. I feel that would be much better = accomplished by defining a new HTTP authentication scheme. > =20 > Philosophically, I think extensible authentication schemes are a bad = idea. > =20 > EHL > =20 > =20 > From: William J. Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Wednesday, August 03, 2011 10:28 AM > To: Phillip Hunt; Eran Hammer-Lahav > Cc: Ben Adida; OAuth WG; Adam Barth(adam@adambarth.com) > Subject: Re: [OAUTH-WG] MAC Tokens body hash > =20 > In thinking about this I'm coming around to the viewpoint that a = single additional predefined spot is sufficient. If the app developer = wants to include addtional data there (iun the specified format) that's = fine. If what they want to do is include a signature of other payload = that's fine too. > =20 > I'm not in love with the name "app" though, "ext" is better. > =20 > From: Phillip Hunt > To: Eran Hammer-Lahav > Cc: Ben Adida ; OAuth WG ; "Adam = Barth(adam@adambarth.com)" > Sent: Tuesday, August 2, 2011 7:14 PM > Subject: Re: [OAUTH-WG] MAC Tokens body hash >=20 >=20 >=20 > Phil >=20 > On 2011-08-02, at 18:02, Eran Hammer-Lahav = wrote: >=20 > The idea is to drop 'ext' and 'bodyhash' due to being underspecified = and therefore causing more harm than good. I added 'ext' to allow for = application specific data to be included in the signed content. However, = the name suggests this is an extension point for future specifications. = I believe authentication schemes should not be extensible in ways that = affect their security or interop properties and without additional text = (registry, process, etc) for the 'ext' parameter, it will cause more = issues than help. >=20 > Instead of the 'ext' parameter I am suggesting the 'app' parameter = which will do the same, but will be better positioned as an = application-specific data. The prose will go a step further and = recommend that the parameter value include a hash of the data, not the = data itself. This is to ensure the parameter does not become part of the = payload which is inappropriate for HTTP requests. > -1 what you describe appears to be a separate feature from ext >=20 >=20 > As for the 'bodyhash' parameter, I would like to remove it because it = is underspecified (we had an actual deployment experience showing that = it doesn't produce interoperable implementations due to the many HTTP = body transformation applied in most frameworks). Solving this issue is = not possible due to the many different types of bodies and frameworks = (and clearly operating on the "raw" body doesn't work). Instead, = developers can use the new 'app' parameter to accomplish that. > =20 > +1 >=20 >=20 >=20 > As for the normalized string, it will be adjusted to reflect these = changes when they are made, so no placeholders which will require code = change. Considering this is -00, it is clearly not a stable document. >=20 > Will these changes work with your use cases? >=20 > EHL >=20 >=20 > -----Original Message----- > From: Skylar Woodward [mailto:skylar@kiva.org] > Sent: Tuesday, August 02, 2011 4:02 PM > To: Eran Hammer-Lahav > Cc: OAuth WG; Ben Adida; 'Adam Barth (adam@adambarth.com)' > Subject: Re: [OAUTH-WG] MAC Tokens body hash > =20 > hurrah! > (not necessarily for losing a way to sign the body, but for simplicity = and > avoiding some of the potential inconsistencies w/ bodyhash). > =20 > Is your plan to reserve an empty line 6 for the Normalized Request = String > (which was used for bodyhash) or eliminate it, brining the total to = six > elements? > =20 > skylar > =20 > On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote: > =20 > I plan to drop support for the bodyhash parameter in the next draft = based > on bad implementation experience. Even with simple text body, UTF > encoding has introduced significant issues for us. The current draft = does not > work using simple JS code between a browser and node.js even when both > use the same v8 engine due to differences in the body encoding. = Basically, > the JS string used to send a request from the browser is not the = actual string > sent on the wire. > =20 > To fix that, we need to force UTF-8 encoding on both sides. However, = that > is very much application specific. This will not work for non-text = bodies. > Instead, the specification should offer a simple way to use the ext = parameter > for such needs, including singing headers. And by offer I mean give > examples, but leave it application specific for now. > =20 > I am open to suggestions but so far all the solutions I came up with = will > introduce unacceptable complexity that will basically make this work = useless. > =20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail-17--914108325 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Phil

On 2011-08-03, at 11:03 AM, Eran Hammer-Lahav = wrote:

My = proposal is to change =91ext=92 to = =91app=92, keep the same prose as =91ext=92, and add the use case of = =91bodyhash=92 as an example. I=92m not too stuck on the name, but my = thinking is that =91app=92 relays the right message that this is a place = where developers can stick any application data they want included. = =91ext=92 conveys the idea of extensions which I=92m not so thrilled = about.
In = other words, I=92d like a developer reading this to feel comfortable = using it right away for securing addition bits such as a JSON payload, = but I don=92t like the idea of someone publishing an I-D with a full = syntax and canonicalization requirements for say, singing an entire = request, headers and all. I feel that would be much better accomplished = by defining a new HTTP authentication = scheme.

 Phillip Hunt < Eran Hammer-Lahav < Ben Adida <ben@adida.net>; OAuth WG <oauth@ietf.org>; "Adam Barth(adam@adambarth.com)" < Tuesday, August 2, 2011 = 7:14 PM
Subject: Re: [OAUTH-WG] MAC Tokens = body hash


On 2011-08-02, at 18:02, = Eran Hammer-Lahav <
The idea is to drop 'ext' and 'bodyhash' due to being = underspecified and therefore causing more harm than good. I added 'ext' = to allow for application specific data to be included in the signed = content. However, the name suggests this is an extension point for = future specifications. I believe authentication schemes should not be = extensible in ways that affect their security or interop properties and = without additional text (registry, process, etc) for the 'ext' = parameter, it will cause more issues than help.

Instead of the = 'ext' parameter I am suggesting the 'app' parameter which will do the = same, but will be better positioned as an application-specific data. The = prose will go a step further and recommend that the parameter value = include a hash of the data, not the data itself. This is to ensure the = parameter does not become part of the payload which is inappropriate for = HTTP requests.


OAuth mailing = list

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
Date: Wed, 03 Aug 2011 14:16:11 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:16:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-05.txt Pages : 15 Date : 2011-08-03 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-05.txt From bcampbell@pingidentity.com Wed Aug 3 14:30:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CA111E807C for ; Wed, 3 Aug 2011 14:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RH3Kibljlxo for ; Wed, 3 Aug 2011 14:30:38 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id CCACF11E8099 for ; Wed, 3 Aug 2011 14:30:37 -0700 (PDT) Received: from mail-qw0-f44.google.com ([209.85.216.44]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTjm+AyStgJI4u6biDc0r6h3GGLi7oHDs@postini.com; Wed, 03 Aug 2011 14:30:51 PDT Received: by mail-qw0-f44.google.com with SMTP id 23so1148003qwc.17 for ; Wed, 03 Aug 2011 14:30:43 -0700 (PDT) Received: by 10.224.186.10 with SMTP id cq10mr5706089qab.393.1312407043115; Wed, 03 Aug 2011 14:30:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.67.17 with HTTP; Wed, 3 Aug 2011 14:30:13 -0700 (PDT) In-Reply-To: <20110803211611.32450.57954.idtracker@ietfa.amsl.com> References: <20110803211611.32450.57954.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 3 Aug 2011 15:30:13 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:30:38 -0000 This 'nice' version of this is at http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-05 The draft has been reworked significantly to become a profile of http://tools.ietf.org/html/draft-ietf-oauth-assertions-00 and cover both assertions as access grants as well as assertions as client authentication. The grant_type URI value no longer uses oauth.net and is urn:ietf:params:oauth:grant-type:saml2-bearer which is registered/requested per http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns and a new URI of urn:ietf:params:oauth:client-assertion-type:saml2-bearer is introduced for client_assertion_type. Lastly the processing rules on the assertion have been relaxed somewhat to allow for element(s) to be optional when the element has a NotOnOrAfter attribute. Thanks, Brian On Wed, Aug 3, 2011 at 3:16 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SAML 2.0 Bearer Assertion Prof= iles for OAuth 2.0 > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Chuck Mortimore > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-saml2-bearer-05= .txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-08-03 > > =A0 This specification defines the use of a SAML 2.0 Bearer Assertion as > =A0 means for requesting an OAuth 2.0 access token as well as for use as > =A0 a means of client authentication. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-05.txt > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From bcampbell@pingidentity.com Wed Aug 3 14:59:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DB011E8099 for ; Wed, 3 Aug 2011 14:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLHeDKHUulBz for ; Wed, 3 Aug 2011 14:59:01 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 314DB11E8097 for ; Wed, 3 Aug 2011 14:59:01 -0700 (PDT) Received: from mail-qy0-f181.google.com ([209.85.216.181]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKTjnEseNQTwLqbLndtbN1WyEjwB3UIVcM@postini.com; Wed, 03 Aug 2011 14:59:14 PDT Received: by qyk15 with SMTP id 15so668016qyk.12 for ; Wed, 03 Aug 2011 14:59:13 -0700 (PDT) Received: by 10.224.188.139 with SMTP id da11mr2755163qab.143.1312408753043; Wed, 03 Aug 2011 14:59:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.67.17 with HTTP; Wed, 3 Aug 2011 14:58:43 -0700 (PDT) From: Brian Campbell Date: Wed, 3 Aug 2011 15:58:43 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Parameter Registration Requests in draft-ietf-oauth-assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:59:02 -0000 One of the changes I made in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-05 was to drop the parameter registration request for the assertion parameter because the parameter is now defined in http://tools.ietf.org/html/draft-ietf-oauth-assertions however that document doesn't currently have the registration request in its IANA Considerations section. It probably needs to have that as well as requests for client_assertion and client_assertion_type. To bootstrap that bit of work, I've included the XML source for the assertion parameter request from a previous version of the SAML document:
The following is the parameter registration request, as defined in The OAuth Parameters Registry of The OAuth 2.0 Authorization Protocol, for the assertion parameter: Parameter name: assertion Parameter usage location: token request Change controller: IETF Specification document(s): [[this document]]
From eran@hueniverse.com Thu Aug 4 16:44:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8C911E808D for ; Thu, 4 Aug 2011 16:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y95p56IA4SXN for ; Thu, 4 Aug 2011 16:44:41 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 6DCBE11E807C for ; Thu, 4 Aug 2011 16:44:41 -0700 (PDT) Received: (qmail 18168 invoked from network); 4 Aug 2011 23:44:43 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Aug 2011 23:44:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 4 Aug 2011 16:44:33 -0700 From: Eran Hammer-Lahav To: Phil Hunt Date: Thu, 4 Aug 2011 16:42:45 -0700 Thread-Topic: [OAUTH-WG] MAC Tokens body hash Thread-Index: AcxTAHZZEcNAR+OkRnmihYmG0cYfEw== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72345024864560@P3PW5EX1MB01.EX1.SECURESERVER.NET> <81B6B8AF-4EC0-4F08-B48C-D1E7B39AE506@oracle.com> In-Reply-To: <81B6B8AF-4EC0-4F08-B48C-D1E7B39AE506@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3E51E9C22BD48F2806A9BC4411927BBhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:44:43 -0000 --_000_A3E51E9C22BD48F2806A9BC4411927BBhueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2suIFdlIHNlZW0gdG8gYmUgdXNpbmcgZGlmZmVyZW50IGRlZmluaXRpb25zIG9mIHdoYXQgYXBw bGljYXRpb24gZGF0YSBtZWFuLCBidXQgaGF2ZSB0aGUgc2FtZSB1c2UgY2FzZXMgaW4gbWluZC4g SSdsbCBjb21lIHVwIHdpdGggYSBkaWZmZXJlbnQgbmFtZSBvciBqdXN0IGtlZXAgZXh0Lg0KDQpF SEwNCg0KT24gQXVnIDMsIDIwMTEsIGF0IDEyOjQyLCAiUGhpbCBIdW50IiA8cGhpbC5odW50QG9y YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCk9ubHkgYWxs b3dpbmcgKGltcGxpZWQgb3Igbm90KSBhcHAgZGF0YSBpcyBuZWVkbGVzc2x5IG5hcnJvdyBpbiBz Y29wZS4NCg0KRXh0ZW5kaW5nIE1BQyB0byBpbmNsdWRlIGNsYWltcyBvciBzZXNzaW9uIGluZm9y bWF0aW9uIGlzIGEgcGVyZmVjdGx5IHZhbGlkIHRoaW5nIHRvIGRvLiBJdCBpbXByb3ZlcyBzY2Fs YWJpbGl0eSBhbmQgcmVkdWNlcyB0aGUgbmVlZCB0byBsb29rIHVwIGFydGlmYWN0IGRhdGEuDQoN Ck5vdGU6ICBJJ2QgbGlrZSB0byBzaGFyZSBtb3JlIG9uIHRoaXMsIGJ1dCBJJ20gcHJpb3JpdGl6 aW5nIHRoZSBUaHJlYXQgTW9kZWwgZG9jdW1lbnQuIE5ldmVyLXRoZS1sZXNzLCB0aGUgYWJvdmUg c2hvdWxkIGJlIGEgc3VmZmljaWVudCBleGFtcGxlIGFib3V0IHdoeSBleHRlbnNpYmlsaXR5IGlz IHVzZWZ1bC4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0KPGh0dHA6Ly93d3cuaW5kZXBlbmRl bnRpZC5jb20+d3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5j b20+DQo8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPnBoaWwuaHVudEBvcmFjbGUuY29tPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCg0KDQpPbiAyMDExLTA4LTAzLCBhdCAx MTowMyBBTSwgRXJhbiBIYW1tZXItTGFoYXYgd3JvdGU6DQoNCk15IHByb3Bvc2FsIGlzIHRvIGNo YW5nZSDigJhleHTigJkgdG8g4oCYYXBw4oCZLCBrZWVwIHRoZSBzYW1lIHByb3NlIGFzIOKAmGV4 dOKAmSwgYW5kIGFkZCB0aGUgdXNlIGNhc2Ugb2Yg4oCYYm9keWhhc2jigJkgYXMgYW4gZXhhbXBs ZS4gSeKAmW0gbm90IHRvbyBzdHVjayBvbiB0aGUgbmFtZSwgYnV0IG15IHRoaW5raW5nIGlzIHRo YXQg4oCYYXBw4oCZIHJlbGF5cyB0aGUgcmlnaHQgbWVzc2FnZSB0aGF0IHRoaXMgaXMgYSBwbGFj ZSB3aGVyZSBkZXZlbG9wZXJzIGNhbiBzdGljayBhbnkgYXBwbGljYXRpb24gZGF0YSB0aGV5IHdh bnQgaW5jbHVkZWQuIOKAmGV4dOKAmSBjb252ZXlzIHRoZSBpZGVhIG9mIGV4dGVuc2lvbnMgd2hp Y2ggSeKAmW0gbm90IHNvIHRocmlsbGVkIGFib3V0Lg0KDQpJbiBvdGhlciB3b3JkcywgSeKAmWQg bGlrZSBhIGRldmVsb3BlciByZWFkaW5nIHRoaXMgdG8gZmVlbCBjb21mb3J0YWJsZSB1c2luZyBp dCByaWdodCBhd2F5IGZvciBzZWN1cmluZyBhZGRpdGlvbiBiaXRzIHN1Y2ggYXMgYSBKU09OIHBh eWxvYWQsIGJ1dCBJIGRvbuKAmXQgbGlrZSB0aGUgaWRlYSBvZiBzb21lb25lIHB1Ymxpc2hpbmcg YW4gSS1EIHdpdGggYSBmdWxsIHN5bnRheCBhbmQgY2Fub25pY2FsaXphdGlvbiByZXF1aXJlbWVu dHMgZm9yIHNheSwgc2luZ2luZyBhbiBlbnRpcmUgcmVxdWVzdCwgaGVhZGVycyBhbmQgYWxsLiBJ IGZlZWwgdGhhdCB3b3VsZCBiZSBtdWNoIGJldHRlciBhY2NvbXBsaXNoZWQgYnkgZGVmaW5pbmcg YSBuZXcgSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWUuDQoNClBoaWxvc29waGljYWxseSwgSSB0 aGluayBleHRlbnNpYmxlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgYXJlIGEgYmFkIGlkZWEuDQoN CkVITA0KDQoNCkZyb206IFdpbGxpYW0gSi4gTWlsbHMgW21haWx0bzp3bWlsbHNAeWFob28taW5j LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDAzLCAyMDExIDEwOjI4IEFNDQpUbzogUGhp bGxpcCBIdW50OyBFcmFuIEhhbW1lci1MYWhhdg0KQ2M6IEJlbiBBZGlkYTsgT0F1dGggV0c7IEFk YW0gQmFydGgoPG1haWx0bzphZGFtQGFkYW1iYXJ0aC5jb20+YWRhbUBhZGFtYmFydGguY29tPG1h aWx0bzphZGFtQGFkYW1iYXJ0aC5jb20+KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTUFDIFRv a2VucyBib2R5IGhhc2gNCg0KSW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBJJ20gY29taW5nIGFyb3Vu ZCB0byB0aGUgdmlld3BvaW50IHRoYXQgYSBzaW5nbGUgYWRkaXRpb25hbCBwcmVkZWZpbmVkIHNw b3QgaXMgc3VmZmljaWVudC4gIElmIHRoZSBhcHAgZGV2ZWxvcGVyIHdhbnRzIHRvIGluY2x1ZGUg YWRkdGlvbmFsIGRhdGEgdGhlcmUgKGl1biB0aGUgc3BlY2lmaWVkIGZvcm1hdCkgdGhhdCdzIGZp bmUuICBJZiB3aGF0IHRoZXkgd2FudCB0byBkbyBpcyBpbmNsdWRlIGEgc2lnbmF0dXJlIG9mIG90 aGVyIHBheWxvYWQgdGhhdCdzIGZpbmUgdG9vLg0KDQpJJ20gbm90IGluIGxvdmUgd2l0aCB0aGUg bmFtZSAiYXBwIiB0aG91Z2gsICJleHQiIGlzIGJldHRlci4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkZyb206IFBoaWxsaXAgSHVudCA8PG1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbT5waGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ Pg0KVG86IEVyYW4gSGFtbWVyLUxhaGF2IDw8bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+ZXJh bkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+DQpDYzogQmVuIEFk aWRhIDw8bWFpbHRvOmJlbkBhZGlkYS5uZXQ+YmVuQGFkaWRhLm5ldDxtYWlsdG86YmVuQGFkaWRh Lm5ldD4+OyBPQXV0aCBXRyA8PG1haWx0bzpvYXV0aEBpZXRmLm9yZz5vYXV0aEBpZXRmLm9yZzxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+PjsgIkFkYW0gQmFydGgoPG1haWx0bzphZGFtQGFkYW1iYXJ0 aC5jb20+YWRhbUBhZGFtYmFydGguY29tPG1haWx0bzphZGFtQGFkYW1iYXJ0aC5jb20+KSIgPDxt YWlsdG86YWRhbUBhZGFtYmFydGguY29tPmFkYW1AYWRhbWJhcnRoLmNvbTxtYWlsdG86YWRhbUBh ZGFtYmFydGguY29tPj4NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyLCAyMDExIDc6MTQgUE0NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE1BQyBUb2tlbnMgYm9keSBoYXNoDQoNCg0KUGhpbA0KDQpP biAyMDExLTA4LTAyLCBhdCAxODowMiwgRXJhbiBIYW1tZXItTGFoYXYgPDxtYWlsdG86ZXJhbkBo dWVuaXZlcnNlLmNvbT5lcmFuQGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2Uu Y29tPj4gd3JvdGU6DQpUaGUgaWRlYSBpcyB0byBkcm9wICdleHQnIGFuZCAnYm9keWhhc2gnIGR1 ZSB0byBiZWluZyB1bmRlcnNwZWNpZmllZCBhbmQgdGhlcmVmb3JlIGNhdXNpbmcgbW9yZSBoYXJt IHRoYW4gZ29vZC4gSSBhZGRlZCAnZXh0JyB0byBhbGxvdyBmb3IgYXBwbGljYXRpb24gc3BlY2lm aWMgZGF0YSB0byBiZSBpbmNsdWRlZCBpbiB0aGUgc2lnbmVkIGNvbnRlbnQuIEhvd2V2ZXIsIHRo ZSBuYW1lIHN1Z2dlc3RzIHRoaXMgaXMgYW4gZXh0ZW5zaW9uIHBvaW50IGZvciBmdXR1cmUgc3Bl Y2lmaWNhdGlvbnMuIEkgYmVsaWV2ZSBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIHNob3VsZCBub3Qg YmUgZXh0ZW5zaWJsZSBpbiB3YXlzIHRoYXQgYWZmZWN0IHRoZWlyIHNlY3VyaXR5IG9yIGludGVy b3AgcHJvcGVydGllcyBhbmQgd2l0aG91dCBhZGRpdGlvbmFsIHRleHQgKHJlZ2lzdHJ5LCBwcm9j ZXNzLCBldGMpIGZvciB0aGUgJ2V4dCcgcGFyYW1ldGVyLCBpdCB3aWxsIGNhdXNlIG1vcmUgaXNz dWVzIHRoYW4gaGVscC4NCg0KSW5zdGVhZCBvZiB0aGUgJ2V4dCcgcGFyYW1ldGVyIEkgYW0gc3Vn Z2VzdGluZyB0aGUgJ2FwcCcgcGFyYW1ldGVyIHdoaWNoIHdpbGwgZG8gdGhlIHNhbWUsIGJ1dCB3 aWxsIGJlIGJldHRlciBwb3NpdGlvbmVkIGFzIGFuIGFwcGxpY2F0aW9uLXNwZWNpZmljIGRhdGEu IFRoZSBwcm9zZSB3aWxsIGdvIGEgc3RlcCBmdXJ0aGVyIGFuZCByZWNvbW1lbmQgdGhhdCB0aGUg cGFyYW1ldGVyIHZhbHVlIGluY2x1ZGUgYSBoYXNoIG9mIHRoZSBkYXRhLCBub3QgdGhlIGRhdGEg aXRzZWxmLiBUaGlzIGlzIHRvIGVuc3VyZSB0aGUgcGFyYW1ldGVyIGRvZXMgbm90IGJlY29tZSBw YXJ0IG9mIHRoZSBwYXlsb2FkIHdoaWNoIGlzIGluYXBwcm9wcmlhdGUgZm9yIEhUVFAgcmVxdWVz dHMuDQotMSB3aGF0IHlvdSBkZXNjcmliZSBhcHBlYXJzIHRvIGJlIGEgc2VwYXJhdGUgZmVhdHVy ZSBmcm9tIGV4dA0KDQoNCkFzIGZvciB0aGUgJ2JvZHloYXNoJyBwYXJhbWV0ZXIsIEkgd291bGQg bGlrZSB0byByZW1vdmUgaXQgYmVjYXVzZSBpdCBpcyB1bmRlcnNwZWNpZmllZCAod2UgaGFkIGFu IGFjdHVhbCBkZXBsb3ltZW50IGV4cGVyaWVuY2Ugc2hvd2luZyB0aGF0IGl0IGRvZXNuJ3QgcHJv ZHVjZSBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBkdWUgdG8gdGhlIG1hbnkgSFRUUCBi b2R5IHRyYW5zZm9ybWF0aW9uIGFwcGxpZWQgaW4gbW9zdCBmcmFtZXdvcmtzKS4gU29sdmluZyB0 aGlzIGlzc3VlIGlzIG5vdCBwb3NzaWJsZSBkdWUgdG8gdGhlIG1hbnkgZGlmZmVyZW50IHR5cGVz IG9mIGJvZGllcyBhbmQgZnJhbWV3b3JrcyAoYW5kIGNsZWFybHkgb3BlcmF0aW5nIG9uIHRoZSAi cmF3IiBib2R5IGRvZXNuJ3Qgd29yaykuIEluc3RlYWQsIGRldmVsb3BlcnMgY2FuIHVzZSB0aGUg bmV3ICdhcHAnIHBhcmFtZXRlciB0byBhY2NvbXBsaXNoIHRoYXQuDQoNCisxDQoNCg0KDQpBcyBm b3IgdGhlIG5vcm1hbGl6ZWQgc3RyaW5nLCBpdCB3aWxsIGJlIGFkanVzdGVkIHRvIHJlZmxlY3Qg dGhlc2UgY2hhbmdlcyB3aGVuIHRoZXkgYXJlIG1hZGUsIHNvIG5vIHBsYWNlaG9sZGVycyB3aGlj aCB3aWxsIHJlcXVpcmUgY29kZSBjaGFuZ2UuIENvbnNpZGVyaW5nIHRoaXMgaXMgLTAwLCBpdCBp cyBjbGVhcmx5IG5vdCBhIHN0YWJsZSBkb2N1bWVudC4NCldpbGwgdGhlc2UgY2hhbmdlcyB3b3Jr IHdpdGggeW91ciB1c2UgY2FzZXM/DQoNCkVITA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBTa3lsYXIgV29vZHdhcmQgW21haWx0bzpza3lsYXJAa2l2YS5vcmddPG1haWx0 bzpbbWFpbHRvOnNreWxhckBraXZhLm9yZ10+DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDIsIDIw MTEgNDowMiBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2DQpDYzogT0F1dGggV0c7IEJlbiBBZGlk YTsgJ0FkYW0gQmFydGggKDxtYWlsdG86YWRhbUBhZGFtYmFydGguY29tPmFkYW1AYWRhbWJhcnRo LmNvbTxtYWlsdG86YWRhbUBhZGFtYmFydGguY29tPiknDQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBNQUMgVG9rZW5zIGJvZHkgaGFzaA0KDQpodXJyYWghDQoobm90IG5lY2Vzc2FyaWx5IGZvciBs b3NpbmcgYSB3YXkgdG8gc2lnbiB0aGUgYm9keSwgYnV0IGZvciBzaW1wbGljaXR5IGFuZA0KYXZv aWRpbmcgc29tZSBvZiB0aGUgcG90ZW50aWFsIGluY29uc2lzdGVuY2llcyB3LyBib2R5aGFzaCku DQoNCklzIHlvdXIgcGxhbiB0byByZXNlcnZlIGFuIGVtcHR5IGxpbmUgNiBmb3IgdGhlIE5vcm1h bGl6ZWQgUmVxdWVzdCBTdHJpbmcNCih3aGljaCB3YXMgdXNlZCBmb3IgYm9keWhhc2gpIG9yIGVs aW1pbmF0ZSBpdCwgYnJpbmluZyB0aGUgdG90YWwgdG8gc2l4DQplbGVtZW50cz8NCg0Kc2t5bGFy DQoNCk9uIEp1bCAzMCwgMjAxMSwgYXQgMzo0MyBBTSwgRXJhbiBIYW1tZXItTGFoYXYgd3JvdGU6 DQoNCkkgcGxhbiB0byBkcm9wIHN1cHBvcnQgZm9yIHRoZSBib2R5aGFzaCBwYXJhbWV0ZXIgaW4g dGhlIG5leHQgZHJhZnQgYmFzZWQNCm9uIGJhZCBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlLiBF dmVuIHdpdGggc2ltcGxlIHRleHQgYm9keSwgVVRGDQplbmNvZGluZyBoYXMgaW50cm9kdWNlZCBz aWduaWZpY2FudCBpc3N1ZXMgZm9yIHVzLiBUaGUgY3VycmVudCBkcmFmdCBkb2VzIG5vdA0Kd29y ayB1c2luZyBzaW1wbGUgSlMgY29kZSBiZXR3ZWVuIGEgYnJvd3NlciBhbmQgbm9kZS5qcyBldmVu IHdoZW4gYm90aA0KdXNlIHRoZSBzYW1lIHY4IGVuZ2luZSBkdWUgdG8gZGlmZmVyZW5jZXMgaW4g dGhlIGJvZHkgZW5jb2RpbmcuIEJhc2ljYWxseSwNCnRoZSBKUyBzdHJpbmcgdXNlZCB0byBzZW5k IGEgcmVxdWVzdCBmcm9tIHRoZSBicm93c2VyIGlzIG5vdCB0aGUgYWN0dWFsIHN0cmluZw0Kc2Vu dCBvbiB0aGUgd2lyZS4NCg0KVG8gZml4IHRoYXQsIHdlIG5lZWQgdG8gZm9yY2UgVVRGLTggZW5j b2Rpbmcgb24gYm90aCBzaWRlcy4gSG93ZXZlciwgdGhhdA0KaXMgdmVyeSBtdWNoIGFwcGxpY2F0 aW9uIHNwZWNpZmljLiBUaGlzIHdpbGwgbm90IHdvcmsgZm9yIG5vbi10ZXh0IGJvZGllcy4NCklu c3RlYWQsIHRoZSBzcGVjaWZpY2F0aW9uIHNob3VsZCBvZmZlciBhIHNpbXBsZSB3YXkgdG8gdXNl IHRoZSBleHQgcGFyYW1ldGVyDQpmb3Igc3VjaCBuZWVkcywgaW5jbHVkaW5nIHNpbmdpbmcgaGVh ZGVycy4gQW5kIGJ5IG9mZmVyIEkgbWVhbiBnaXZlDQpleGFtcGxlcywgYnV0IGxlYXZlIGl0IGFw cGxpY2F0aW9uIHNwZWNpZmljIGZvciBub3cuDQoNCkkgYW0gb3BlbiB0byBzdWdnZXN0aW9ucyBi dXQgc28gZmFyIGFsbCB0aGUgc29sdXRpb25zIEkgY2FtZSB1cCB3aXRoIHdpbGwNCmludHJvZHVj ZSB1bmFjY2VwdGFibGUgY29tcGxleGl0eSB0aGF0IHdpbGwgYmFzaWNhbGx5IG1ha2UgdGhpcyB3 b3JrIHVzZWxlc3MuDQoNCkVITA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KPG1haWx0bzpPQXV0aEBpZXRmLm9yZz5P QXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo8aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCjxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+T0F1dGhA aWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQo8bWFpbHRvOk9BdXRoQGlldGYub3JnPk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCjxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_A3E51E9C22BD48F2806A9BC4411927BBhueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5Pay4gV2Ugc2VlbSB0byBiZSB1c2lu ZyBkaWZmZXJlbnQgZGVmaW5pdGlvbnMgb2Ygd2hhdCBhcHBsaWNhdGlvbiBkYXRhIG1lYW4sIGJ1 dCBoYXZlIHRoZSBzYW1lIHVzZSBjYXNlcyBpbiBtaW5kLiBJJ2xsIGNvbWUgdXAgd2l0aCBhIGRp ZmZlcmVudCBuYW1lIG9yIGp1c3Qga2VlcCBleHQuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5FSEw8YnI+PGJyPk9uIEF1ZyAzLCAyMDExLCBhdCAxMjo0MiwgIlBoaWwgSHVudCIgJmx0 OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5j b208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGRpdj48ZGl2Pk9ubHkgYWxsb3dpbmcgKGltcGxpZWQgb3Igbm90KSBhcHAgZGF0 YSBpcyBuZWVkbGVzc2x5Jm5ic3A7bmFycm93IGluIHNjb3BlLjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+RXh0ZW5kaW5nIE1BQyB0byBpbmNsdWRlIGNsYWltcyBvciBzZXNzaW9uIGluZm9ybWF0 aW9uIGlzIGEgcGVyZmVjdGx5IHZhbGlkIHRoaW5nIHRvIGRvLiBJdCBpbXByb3ZlcyBzY2FsYWJp bGl0eSBhbmQgcmVkdWNlcyB0aGUgbmVlZCB0byBsb29rIHVwIGFydGlmYWN0IGRhdGEuJm5ic3A7 PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ob3RlOiAmbmJzcDtJJ2QgbGlrZSB0byBzaGFyZSBt b3JlIG9uIHRoaXMsIGJ1dCBJJ20gcHJpb3JpdGl6aW5nIHRoZSBUaHJlYXQgTW9kZWwgZG9jdW1l bnQuIE5ldmVyLXRoZS1sZXNzLCB0aGUgYWJvdmUgc2hvdWxkIGJlIGEgc3VmZmljaWVudCBleGFt cGxlIGFib3V0IHdoeSBleHRlbnNpYmlsaXR5IGlzIHVzZWZ1bC48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAx MnB4OyAiPlBoaWw8L3NwYW4+PC9kaXY+PGRpdj48ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS1zdHls ZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogYXV0bzsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwt c3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFk anVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmb250LXNpemU6IG1l ZGl1bTsgIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xs YXBzZTogc2VwYXJhdGU7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogbWVkaXVtOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9y ZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRpb25zLWluLWVm ZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7ICI+PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29s bGFwc2U6IHNlcGFyYXRlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IG1lZGl1bTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0LWJv cmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1l ZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyAiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNv bGxhcHNlOiBzZXBhcmF0ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9y ZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRpb25zLWluLWVm ZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7ICI+PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7ICI+PGJyPjwvZGl2PjxkaXY+QGluZGVwZW5kZW50aWQ8L2Rpdj48ZGl2PjxhIGhyZWY9 Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBl bmRlbnRpZC5jb20iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48L2E+PC9kaXY+PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+PGEgaHJlZj0ibWFpbHRvOnBoaWwu aHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48L2E+PGJyPjxicj48L2Rp dj48L3NwYW4+PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48L2Rpdj48L3Nw YW4+PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48L3NwYW4+PGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjwvZGl2Pg0KPGJyPjxkaXY+PGRpdj5PbiAy MDExLTA4LTAzLCBhdCAxMTowMyBBTSwgRXJhbiBIYW1tZXItTGFoYXYgd3JvdGU6PC9kaXY+PGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTog c2VwYXJhdGU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IC13ZWJr aXQtYXV0bzsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVy LWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRlci12ZXJ0aWNhbC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBm b250LXNpemU6IG1lZGl1bTsgIj48ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlv bjE7ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7ICI+TXkgcHJvcG9zYWwgaXMgdG8gYzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7ICI+aGFuZ2Ug4oCYZXh04oCZIHRvIOKAmGFwcOKAmSwga2VlcCB0 aGUgc2FtZSBwcm9zZSBhcyDigJhleHTigJksIGFuZCBhZGQgdGhlIHVzZSBjYXNlIG9mIOKAmGJv ZHloYXNo4oCZIGFzIGFuIGV4YW1wbGUuIEnigJltIG5vdCB0b28gc3R1Y2sgb24gdGhlIG5hbWUs IGJ1dCBteSB0aGlua2luZyBpcyB0aGF0IOKAmGFwcOKAmSByZWxheXMgdGhlIHJpZ2h0IG1lc3Nh Z2UgdGhhdCB0aGlzIGlzIGEgcGxhY2Ugd2hlcmUgZGV2ZWxvcGVycyBjYW4gc3RpY2sgYW55IGFw cGxpY2F0aW9uIGRhdGEgdGhleSB3YW50IGluY2x1ZGVkLiDigJhleHTigJkgY29udmV5cyB0aGUg aWRlYSBvZiBleHRlbnNpb25zIHdoaWNoIEnigJltIG5vdCBzbyB0aHJpbGxlZCBhYm91dC48bzpw PjwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1y aWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgIj5JbiBvdGhlciB3b3JkcywgSeKAmWQgbGlrZSBhIGRldmVsb3BlciBy ZWFkaW5nIHRoaXMgdG8gZmVlbCBjb21mb3J0YWJsZSB1c2luZyBpdCByaWdodCBhd2F5IGZvciBz ZWN1cmluZyBhZGRpdGlvbiBiaXRzIHN1Y2ggYXMgYSBKU09OIHBheWxvYWQsIGJ1dCBJIGRvbuKA mXQgbGlrZSB0aGUgaWRlYSBvZiBzb21lb25lIHB1Ymxpc2hpbmcgYW4gSS1EIHdpdGggYSBmdWxs IHN5bnRheCBhbmQgY2Fub25pY2FsaXphdGlvbiByZXF1aXJlbWVudHMgZm9yIHNheSwgc2luZ2lu ZyBhbiBlbnRpcmUgcmVxdWVzdCwgaGVhZGVycyBhbmQgYWxsLiBJIGZlZWwgdGhhdCB3b3VsZCBi ZSBtdWNoIGJldHRlciBhY2NvbXBsaXNoZWQgYnkgZGVmaW5pbmcgYSBuZXcgSFRUUCBhdXRoZW50 aWNhdGlvbiBzY2hlbWUuPG86cD48L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2lu LXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJv dHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7ICI+UGhpbG9zb3BoaWNhbGx5LCBJIHRo aW5rIGV4dGVuc2libGUgYXV0aGVudGljYXRpb24gc2NoZW1lcyBhcmUgYSBiYWQgaWRlYS48bzpw PjwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1y aWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgIj5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJib3JkZXItdG9wLXN0eWxlOiBub25lOyBib3JkZXIt cmlnaHQtc3R5bGU6IG5vbmU7IGJvcmRlci1ib3R0b20tc3R5bGU6IG5vbmU7IGJvcmRlci13aWR0 aDogaW5pdGlhbDsgYm9yZGVyLWNvbG9yOiBpbml0aWFsOyBib3JkZXItbGVmdC1zdHlsZTogc29s aWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiBibHVlOyBib3JkZXItbGVmdC13aWR0aDogMS41cHQ7IHBh ZGRpbmctdG9wOiAwaW47IHBhZGRpbmctcmlnaHQ6IDBpbjsgcGFkZGluZy1ib3R0b206IDBpbjsg cGFkZGluZy1sZWZ0OiA0cHQ7ICI+PGRpdj48ZGl2IHN0eWxlPSJib3JkZXItcmlnaHQtc3R5bGU6 IG5vbmU7IGJvcmRlci1ib3R0b20tc3R5bGU6IG5vbmU7IGJvcmRlci1sZWZ0LXN0eWxlOiBub25l OyBib3JkZXItd2lkdGg6IGluaXRpYWw7IGJvcmRlci1jb2xvcjogaW5pdGlhbDsgYm9yZGVyLXRv cC1zdHlsZTogc29saWQ7IGJvcmRlci10b3AtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9y ZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5nLXRvcDogM3B0OyBwYWRkaW5nLXJpZ2h0OiAwaW47 IHBhZGRpbmctYm90dG9tOiAwaW47IHBhZGRpbmctbGVmdDogMGluOyAiPjxkaXYgc3R5bGU9Im1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7ICI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2lsbGlhbSBK LiBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXTxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+PGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgQXVndXN0IDAz LCAyMDExIDEwOjI4IEFNPGJyPjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+UGhpbGxpcCBIdW50OyBFcmFuIEhhbW1lci1MYWhhdjxicj48 Yj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PkJlbiBBZGlkYTsgT0F1dGggV0c7IEFkYW0gQmFydGgoPGEgaHJlZj0ibWFpbHRvOmFkYW1AYWRh bWJhcnRoLmNvbSIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsgIj48YSBocmVmPSJtYWlsdG86YWRhbUBhZGFtYmFydGguY29tIj5hZGFtQGFkYW1iYXJ0aC5j b208L2E+PC9hPik8YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbT0FVVEgtV0ddIE1BQyBUb2tlbnMgYm9keSBoYXNo PG86cD48L286cD48L3NwYW4+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXRv cDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRv bTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgIj48bzpwPiZuYnNwOzwvbzpwPjwvZGl2PjxkaXY+PGRpdj48ZGl2IHN0eWxl PSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBt YXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3Jv dW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNr Z3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgY29sb3I6IGJsYWNrOyAiPkluIHRoaW5r aW5nIGFib3V0IHRoaXMgSSdtIGNvbWluZyBhcm91bmQgdG8gdGhlIHZpZXdwb2ludCB0aGF0IGEg c2luZ2xlIGFkZGl0aW9uYWwgcHJlZGVmaW5lZCBzcG90IGlzIHN1ZmZpY2llbnQuJm5ic3A7IElm IHRoZSBhcHAgZGV2ZWxvcGVyIHdhbnRzIHRvIGluY2x1ZGUgYWRkdGlvbmFsIGRhdGEgdGhlcmUg KGl1biB0aGUgc3BlY2lmaWVkIGZvcm1hdCkgdGhhdCdzIGZpbmUuJm5ic3A7IElmIHdoYXQgdGhl eSB3YW50IHRvIGRvIGlzIGluY2x1ZGUgYSBzaWduYXR1cmUgb2Ygb3RoZXIgcGF5bG9hZCB0aGF0 J3MgZmluZSB0b28uPG86cD48L286cD48L3NwYW4+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxl PSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBt YXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3Jv dW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNr Z3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgY29sb3I6IGJsYWNrOyAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgYmFja2dyb3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50 OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBp bml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6ICdDb3VyaWVyIE5ldyc7IGNvbG9yOiBibGFjazsgIj5JJ20gbm90IGluIGxvdmUgd2l0aCB0 aGUgbmFtZSAiYXBwIiB0aG91Z2gsICJleHQiIGlzIGJldHRlci48bzpwPjwvbzpwPjwvc3Bhbj48 L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91 bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dy b3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3Vu ZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcn OyBjb2xvcjogYmxhY2s7ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+PC9kaXY+PGRp dj48ZGl2PjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IHRleHQtYWxpZ246IGNlbnRlcjsgYmFja2dyb3VuZC1pbWFnZTogaW5p dGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjog aW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0 ZTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVh dDogaW5pdGlhbCBpbml0aWFsOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyAiPjxociBzaXplPSIxIiB3 aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+PC9zcGFuPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVm dDogMGluOyBtYXJnaW4tYm90dG9tOiAxMnB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJh Y2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7 IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IGJhY2tn cm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1yZXBlYXQ6IGluaXRp YWwgaW5pdGlhbDsgIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsgIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyBjb2xvcjogYmxhY2s7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPlBoaWxsaXAgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAi PjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5j b208L2E+PC9hPiZndDs8YnI+PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5FcmFuIEhhbW1lci1MYWhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb20iIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9u OiB1bmRlcmxpbmU7ICI+PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5A aHVlbml2ZXJzZS5jb208L2E+PC9hPiZndDs8YnI+PGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5CZW4gQWRpZGEgJmx0OzxhIGhyZWY9Im1h aWx0bzpiZW5AYWRpZGEubmV0IiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyAiPjxhIGhyZWY9Im1haWx0bzpiZW5AYWRpZGEubmV0Ij5iZW5AYWRpZGEubmV0 PC9hPjwvYT4mZ3Q7OyBPQXV0aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn IiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPjxhIGhy ZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPiZndDs7ICJB ZGFtIEJhcnRoKDxhIGhyZWY9Im1haWx0bzphZGFtQGFkYW1iYXJ0aC5jb20iIHN0eWxlPSJjb2xv cjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+PGEgaHJlZj0ibWFpbHRvOmFk YW1AYWRhbWJhcnRoLmNvbSI+YWRhbUBhZGFtYmFydGguY29tPC9hPjwvYT4pIiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFkYW1AYWRhbWJhcnRoLmNvbSIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsgIj48YSBocmVmPSJtYWlsdG86YWRhbUBhZGFtYmFydGguY29t Ij5hZGFtQGFkYW1iYXJ0aC5jb208L2E+PC9hPiZndDs8YnI+PGI+U2VudDo8L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEF1Z3VzdCAy LCAyMDExIDc6MTQgUE08YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbT0FVVEgtV0ddIE1BQyBUb2tlbnMgYm9keSBo YXNoPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+PG86cD48L286cD48L3NwYW4+ PC9wPjxkaXYgaWQ9InlpdjE1OTAyODAyNjUiPjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgYmFja2dyb3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50 OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBp bml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgIj48c3BhbiBzdHlsZT0iY29sb3I6IGJs YWNrOyAiPjxicj48YnI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXY+PHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAw aW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDEycHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1pbWFn ZTogaW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9y aWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9y OiB3aGl0ZTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5k LXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+ PGJyPk9uIDIwMTEtMDgtMDIsIGF0IDE4OjAyLCBFcmFuIEhhbW1lci1MYWhhdiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29s b3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPjxhIGhyZWY9Im1haWx0bzpl cmFuQGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPjwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7ICI+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1l bnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6 IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjog YmxhY2s7ICI+VGhlIGlkZWEgaXMgdG8gZHJvcCAnZXh0JyBhbmQgJ2JvZHloYXNoJyBkdWUgdG8g YmVpbmcgdW5kZXJzcGVjaWZpZWQgYW5kIHRoZXJlZm9yZSBjYXVzaW5nIG1vcmUgaGFybSB0aGFu IGdvb2QuIEkgYWRkZWQgJ2V4dCcgdG8gYWxsb3cgZm9yIGFwcGxpY2F0aW9uIHNwZWNpZmljIGRh dGEgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIHNpZ25lZCBjb250ZW50LiBIb3dldmVyLCB0aGUgbmFt ZSBzdWdnZXN0cyB0aGlzIGlzIGFuIGV4dGVuc2lvbiBwb2ludCBmb3IgZnV0dXJlIHNwZWNpZmlj YXRpb25zLiBJIGJlbGlldmUgYXV0aGVudGljYXRpb24gc2NoZW1lcyBzaG91bGQgbm90IGJlIGV4 dGVuc2libGUgaW4gd2F5cyB0aGF0IGFmZmVjdCB0aGVpciBzZWN1cml0eSBvciBpbnRlcm9wIHBy b3BlcnRpZXMgYW5kIHdpdGhvdXQgYWRkaXRpb25hbCB0ZXh0IChyZWdpc3RyeSwgcHJvY2Vzcywg ZXRjKSBmb3IgdGhlICdleHQnIHBhcmFtZXRlciwgaXQgd2lsbCBjYXVzZSBtb3JlIGlzc3VlcyB0 aGFuIGhlbHAuPGJyPjxicj5JbnN0ZWFkIG9mIHRoZSAnZXh0JyBwYXJhbWV0ZXIgSSBhbSBzdWdn ZXN0aW5nIHRoZSAnYXBwJyBwYXJhbWV0ZXIgd2hpY2ggd2lsbCBkbyB0aGUgc2FtZSwgYnV0IHdp bGwgYmUgYmV0dGVyIHBvc2l0aW9uZWQgYXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgZGF0YS4g VGhlIHByb3NlIHdpbGwgZ28gYSBzdGVwIGZ1cnRoZXIgYW5kIHJlY29tbWVuZCB0aGF0IHRoZSBw YXJhbWV0ZXIgdmFsdWUgaW5jbHVkZSBhIGhhc2ggb2YgdGhlIGRhdGEsIG5vdCB0aGUgZGF0YSBp dHNlbGYuIFRoaXMgaXMgdG8gZW5zdXJlIHRoZSBwYXJhbWV0ZXIgZG9lcyBub3QgYmVjb21lIHBh cnQgb2YgdGhlIHBheWxvYWQgd2hpY2ggaXMgaW5hcHByb3ByaWF0ZSBmb3IgSFRUUCByZXF1ZXN0 cy48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdiBzdHlsZT0i bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFy Z2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3Vu ZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dy b3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgIj48c3BhbiBzdHls ZT0iY29sb3I6IGJsYWNrOyAiPi0xIHdoYXQgeW91IGRlc2NyaWJlIGFwcGVhcnMgdG8gYmUgYSBz ZXBhcmF0ZSBmZWF0dXJlIGZyb20gZXh0PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGlu aXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46 IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hp dGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj48YnI+QXMgZm9yIHRoZSAnYm9keWhh c2gnIHBhcmFtZXRlciwgSSB3b3VsZCBsaWtlIHRvIHJlbW92ZSBpdCBiZWNhdXNlIGl0IGlzIHVu ZGVyc3BlY2lmaWVkICh3ZSBoYWQgYW4gYWN0dWFsIGRlcGxveW1lbnQgZXhwZXJpZW5jZSBzaG93 aW5nIHRoYXQgaXQgZG9lc24ndCBwcm9kdWNlIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25z IGR1ZSB0byB0aGUgbWFueSBIVFRQIGJvZHkgdHJhbnNmb3JtYXRpb24gYXBwbGllZCBpbiBtb3N0 IGZyYW1ld29ya3MpLiBTb2x2aW5nIHRoaXMgaXNzdWUgaXMgbm90IHBvc3NpYmxlIGR1ZSB0byB0 aGUgbWFueSBkaWZmZXJlbnQgdHlwZXMgb2YgYm9kaWVzIGFuZCBmcmFtZXdvcmtzIChhbmQgY2xl YXJseSBvcGVyYXRpbmcgb24gdGhlICJyYXciIGJvZHkgZG9lc24ndCB3b3JrKS4gSW5zdGVhZCwg ZGV2ZWxvcGVycyBjYW4gdXNlIHRoZSBuZXcgJ2FwcCcgcGFyYW1ldGVyIHRvIGFjY29tcGxpc2gg dGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0 YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQt Y2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNv bG9yOiBibGFjazsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IHN0 eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNr Z3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBi YWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFu IHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+KzE8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2Pjxk aXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0 OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7 IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRp YWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+ PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwv ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDEycHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFj a2dyb3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBi YWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNr Z3JvdW5kLWNvbG9yOiB3aGl0ZTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFs OyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyAiPjxzcGFuIHN0eWxlPSJjb2xv cjogYmxhY2s7ICI+PGJyPkFzIGZvciB0aGUgbm9ybWFsaXplZCBzdHJpbmcsIGl0IHdpbGwgYmUg YWRqdXN0ZWQgdG8gcmVmbGVjdCB0aGVzZSBjaGFuZ2VzIHdoZW4gdGhleSBhcmUgbWFkZSwgc28g bm8gcGxhY2Vob2xkZXJzIHdoaWNoIHdpbGwgcmVxdWlyZSBjb2RlIGNoYW5nZS4gQ29uc2lkZXJp bmcgdGhpcyBpcyAtMDAsIGl0IGlzIGNsZWFybHkgbm90IGEgc3RhYmxlIGRvY3VtZW50LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0 OyBtYXJnaW4tYm90dG9tOiA1cHQ7ICI+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGlu aXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRp YWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7 ICI+V2lsbCB0aGVzZSBjaGFuZ2VzIHdvcmsgd2l0aCB5b3VyIHVzZSBjYXNlcz88YnI+PGJyPkVI TDxicj48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0 b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNo bWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xp cDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9y OiBibGFjazsgIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwv ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVw dDsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBp bml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2lu OiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdo aXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+RnJvbTogU2t5bGFyIFdvb2R3YXJk PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpbbWFpbHRvOnNreWxhckBraXZhLm9yZ10iIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+W21haWx0bzpza3lsYXJAa2l2YS5vcmddPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRv cDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRv bTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgYmFja2dyb3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2ht ZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlw OiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgIj48c3BhbiBzdHlsZT0iY29sb3I6 IGJsYWNrOyAiPlNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwMiwgMjAxMSA0OjAyIFBNPG86cD48L286 cD48L3NwYW4+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGlu aXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRp YWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7 ICI+VG86IEVyYW4gSGFtbWVyLUxhaGF2PG86cD48L286cD48L3NwYW4+PC9kaXY+PC9ibG9ja3F1 b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVw dDsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBp bml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2lu OiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdo aXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+Q2M6IE9BdXRoIFdHOyBCZW4gQWRp ZGE7ICdBZGFtIEJhcnRoICg8YSBocmVmPSJtYWlsdG86YWRhbUBhZGFtYmFydGguY29tIiB0YXJn ZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsgIj48YSBocmVmPSJtYWlsdG86YWRhbUBhZGFtYmFydGguY29tIj5hZGFtQGFkYW1iYXJ0aC5j b208L2E+PC9hPiknPG86cD48L286cD48L3NwYW4+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj48ZGl2IHN0 eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNr Z3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBi YWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFu IHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+U3ViamVjdDogUmU6IFtPQVVUSC1XR10gTUFDIFRva2Vu cyBib2R5IGhhc2g8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5 bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tn cm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJh Y2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4g c3R5bGU9ImNvbG9yOiBibGFjazsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRv bTogNXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47 IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1h Z2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1v cmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xv cjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj5odXJyYWghPG86cD48L286 cD48L3NwYW4+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGlu aXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRp YWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7 ICI+KG5vdCBuZWNlc3NhcmlseSBmb3IgbG9zaW5nIGEgd2F5IHRvIHNpZ24gdGhlIGJvZHksIGJ1 dCBmb3Igc2ltcGxpY2l0eSBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAi PjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRp YWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGlu aXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7 ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj5hdm9pZGluZyBzb21lIG9mIHRoZSBwb3Rl bnRpYWwgaW5jb25zaXN0ZW5jaWVzIHcvIGJvZHloYXNoKS48bzpwPjwvbzpwPjwvc3Bhbj48L2Rp dj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2lu LWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91 bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dy b3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3Vu ZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6 IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206 IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVu dDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDog aW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBi bGFjazsgIj5JcyB5b3VyIHBsYW4gdG8gcmVzZXJ2ZSBhbiBlbXB0eSBsaW5lIDYgZm9yIHRoZSBO b3JtYWxpemVkIFJlcXVlc3QgU3RyaW5nPG86cD48L286cD48L3NwYW4+PC9kaXY+PC9ibG9ja3F1 b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVw dDsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBp bml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2lu OiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdo aXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+KHdoaWNoIHdhcyB1c2VkIGZvciBi b2R5aGFzaCkgb3IgZWxpbWluYXRlIGl0LCBicmluaW5nIHRoZSB0b3RhbCB0byBzaXg8bzpwPjwv bzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDog aW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5p dGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFj azsgIj5lbGVtZW50cz88bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYg c3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJh Y2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7 IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNw YW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJv dHRvbTogNXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAw aW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQt aW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3Vu ZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1j b2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj5za3lsYXI8bzpwPjwv bzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDog aW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5p dGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFj azsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5 bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tn cm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJh Y2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4g c3R5bGU9ImNvbG9yOiBibGFjazsgIj5PbiBKdWwgMzAsIDIwMTEsIGF0IDM6NDMgQU0sIEVyYW4g SGFtbWVyLUxhaGF2IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7ICI+ PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxl ZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1pbWFnZTogaW5pdGlh bDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5p dGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsg Ij48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv ZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJn aW4tYm90dG9tOiA1cHQ7ICI+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFy Z2luLWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tn cm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFj a2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dy b3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj5JIHBsYW4g dG8gZHJvcCBzdXBwb3J0IGZvciB0aGUgYm9keWhhc2ggcGFyYW1ldGVyIGluIHRoZSBuZXh0IGRy YWZ0IGJhc2VkPG86cD48L286cD48L3NwYW4+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90 ZT48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7 ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1pbWFnZTogaW5p dGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjog aW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0 ZTsgIj48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyAiPm9uIGJhZCBpbXBsZW1lbnRhdGlvbiBl eHBlcmllbmNlLiBFdmVuIHdpdGggc2ltcGxlIHRleHQgYm9keSwgVVRGPG86cD48L286cD48L3Nw YW4+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7 IG1hcmdpbi1ib3R0b206IDVwdDsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBi YWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7 IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJh Y2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+ZW5j b2RpbmcgaGFzIGludHJvZHVjZWQgc2lnbmlmaWNhbnQgaXNzdWVzIGZvciB1cy4gVGhlIGN1cnJl bnQgZHJhZnQgZG9lcyBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxk aXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0 OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7 IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRp YWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+ PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj53b3JrIHVzaW5nIHNpbXBsZSBKUyBjb2RlIGJl dHdlZW4gYSBicm93c2VyIGFuZCBub2RlLmpzIGV2ZW4gd2hlbiBib3RoPG86cD48L286cD48L3Nw YW4+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7 IG1hcmdpbi1ib3R0b206IDVwdDsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBi YWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7 IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJh Y2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+dXNl IHRoZSBzYW1lIHY4IGVuZ2luZSBkdWUgdG8gZGlmZmVyZW5jZXMgaW4gdGhlIGJvZHkgZW5jb2Rp bmcuIEJhc2ljYWxseSw8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYg c3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJh Y2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7 IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNw YW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj50aGUgSlMgc3RyaW5nIHVzZWQgdG8gc2VuZCBhIHJl cXVlc3QgZnJvbSB0aGUgYnJvd3NlciBpcyBub3QgdGhlIGFjdHVhbCBzdHJpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5p dGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlh bDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsg Ij5zZW50IG9uIHRoZSB3aXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7ICI+ PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAi PjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRp YWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGlu aXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7 ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2Rpdj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgYmFja2dyb3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50 OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBp bml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgIj48c3BhbiBzdHlsZT0iY29sb3I6IGJs YWNrOyAiPlRvIGZpeCB0aGF0LCB3ZSBuZWVkIHRvIGZvcmNlIFVURi04IGVuY29kaW5nIG9uIGJv dGggc2lkZXMuIEhvd2V2ZXIsIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdp bi1ib3R0b206IDVwdDsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdo dDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3Jv dW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tn cm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91 bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+aXMgdmVyeSBt dWNoIGFwcGxpY2F0aW9uIHNwZWNpZmljLiBUaGlzIHdpbGwgbm90IHdvcmsgZm9yIG5vbi10ZXh0 IGJvZGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5bGU9 Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1h cmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91 bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tn cm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5 bGU9ImNvbG9yOiBibGFjazsgIj5JbnN0ZWFkLCB0aGUgc3BlY2lmaWNhdGlvbiBzaG91bGQgb2Zm ZXIgYSBzaW1wbGUgd2F5IHRvIHVzZSB0aGUgZXh0IHBhcmFtZXRlcjxvOnA+PC9vOnA+PC9zcGFu PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBt YXJnaW4tYm90dG9tOiA1cHQ7ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFj a2dyb3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBi YWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNr Z3JvdW5kLWNvbG9yOiB3aGl0ZTsgIj48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyAiPmZvciBz dWNoIG5lZWRzLCBpbmNsdWRpbmcgc2luZ2luZyBoZWFkZXJzLiBBbmQgYnkgb2ZmZXIgSSBtZWFu IGdpdmU8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5bGU9Im1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQt YXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91 bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9 ImNvbG9yOiBibGFjazsgIj5leGFtcGxlcywgYnV0IGxlYXZlIGl0IGFwcGxpY2F0aW9uIHNwZWNp ZmljIGZvciBub3cuPG86cD48L286cD48L3NwYW4+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj48YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7ICI+PGRpdiBz dHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1pbWFnZTogaW5pdGlhbDsgYmFj a2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsg YmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgIj48c3Bh biBzdHlsZT0iY29sb3I6IGJsYWNrOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pjwv YmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVw dDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1 cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRp YWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7 IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+ SSBhbSBvcGVuIHRvIHN1Z2dlc3Rpb25zIGJ1dCBzbyBmYXIgYWxsIHRoZSBzb2x1dGlvbnMgSSBj YW1lIHVwIHdpdGggd2lsbDxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRv bTogNXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47 IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1h Z2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1v cmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xv cjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibGFjazsgIj5pbnRyb2R1Y2UgdW5hY2Nl cHRhYmxlIGNvbXBsZXhpdHkgdGhhdCB3aWxsIGJhc2ljYWxseSBtYWtlIHRoaXMgd29yayB1c2Vs ZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7ICI+PGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXYgc3R5bGU9Im1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQt YXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91 bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7ICI+PHNwYW4gc3R5bGU9 ImNvbG9yOiBibGFjazsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdp bi1ib3R0b206IDVwdDsgIj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJn aW4tYm90dG9tOiA1cHQ7ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dy b3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNr Z3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3Jv dW5kLWNvbG9yOiB3aGl0ZTsgIj48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyAiPkVITDxvOnA+ PC9vOnA+PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj48ZGl2IHN0eWxl PSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBt YXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3Jv dW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNr Z3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFuIHN0 eWxlPSJjb2xvcjogYmxhY2s7ICI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1 b3RlPjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVw dDsgIj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1 cHQ7ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1pbWFnZTog aW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdp bjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3 aGl0ZTsgIj48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyAiPk9BdXRoIG1haWxpbmcgbGlzdDxv OnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj48ZGl2IHN0 eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNr Z3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBi YWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyAiPjxzcGFu IHN0eWxlPSJjb2xvcjogYmxhY2s7ICI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsgIj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9h PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj48 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7ICI+ PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxl ZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1pbWFnZTogaW5pdGlh bDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5p dGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsg Ij48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyAiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6 IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvYmxv Y2txdW90ZT48L2Jsb2NrcXVvdGU+PGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFj a2dyb3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBi YWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNr Z3JvdW5kLWNvbG9yOiB3aGl0ZTsgIj48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyAiPjxicj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5PQXV0aCBt YWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj48 YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvYT48YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7ICI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L2E+PG86 cD48L286cD48L3NwYW4+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAxMnB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtaW1hZ2U6 IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVudDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmln aW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjog d2hpdGU7IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1y ZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsgIj48c3BhbiBzdHlsZT0iY29sb3I6IGJsYWNrOyAiPjxi cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5PQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBzdHlsZT0i Y29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPjxhIGhyZWY9Im1haWx0 bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PC9hPjxicj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayIg c3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvYT48YnI+PGJyPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L3NwYW4+ PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+T0F1dGggbWFpbGluZyBsaXN0PC9zcGFu Pjxicj48c3Bhbj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn PC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --_000_A3E51E9C22BD48F2806A9BC4411927BBhueniversecom_-- From wmills@yahoo-inc.com Thu Aug 4 18:06:05 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5290911E8095 for ; Thu, 4 Aug 2011 18:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.836 X-Spam-Level: X-Spam-Status: No, score=-16.836 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHH0dPVh5oLZ for ; Thu, 4 Aug 2011 18:06:03 -0700 (PDT) Received: from nm22-vm0.bullet.mail.ac4.yahoo.com (nm22-vm0.bullet.mail.ac4.yahoo.com [98.139.53.218]) by ietfa.amsl.com (Postfix) with SMTP id 224CD11E807C for ; Thu, 4 Aug 2011 18:06:02 -0700 (PDT) Received: from [98.139.52.191] by nm22.bullet.mail.ac4.yahoo.com with NNFMP; 05 Aug 2011 01:06:16 -0000 Received: from [98.139.52.154] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 05 Aug 2011 01:06:16 -0000 Received: from [127.0.0.1] by omp1037.mail.ac4.yahoo.com with NNFMP; 05 Aug 2011 01:06:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 274507.99679.bm@omp1037.mail.ac4.yahoo.com Received: (qmail 48021 invoked by uid 60001); 5 Aug 2011 01:06:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1312506375; bh=tmom72N+EME9c9N/NzfwMzlrRs/bCMWltuDImU/BuyY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=norK86CTBoiDVRVGVFBWdPimF1OznmFjIWeWkuQV9W77TRiDD+DraNdigHmzYqAwPTrvUAAx0qcIY6dScOy+MwJawmy+lX4N8OrM0PaEzslAjg2sPRT46sAlZhxg4P+v7+GVj1WyYFiiRSe00U1qCXOKtyjOt+wwu0gOvhiafnI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mtS5FRt36iy2BO+rV5siaVVOXj4F+zaW+Mm5iJMZ7ojsGaCi4sdljLyZjN2j9Q4CaMwG/LHySDwUBXPHbkm06NLaXSOXeDNgaoYWvix7QatisHjl015S8FZGiSM5PdFP8iFfMklCnM53nLDGcCzcOKMP2QvlFjK/K7HjNJQa6n4=; X-YMail-OSG: knvbMrQVM1kB_5eX3N6lKlsBx_f.PVasL43vOk8qx0vLiHS 3D0YAOpCm3HFZSojBIT6xsDdtT0Jz_HAWvp6CUhosMzgnNMS1gTKca538OUH scOshUoW3QDiMZRunFxrHk8x9gtQcz.IJTcGs06ud0SpYTVqUhltjHG6.Fuy cwCVVOiNYFhbshC1XncuFoAOYXJZgofXEWVOAzAWiRWKjb0aIiQzeFps439C eRLDSbCgxFKg6gtwkc9JK7245Zg5NSsGldlszFrUz.L63_Sc9bDmqqiT9Rui uQKgxvybOWwTXjVx4JSH01d96ABmhJF.gkWiWOOIYVQhUuyxXhz9yCRr3YR9 Y4bNFONB1Ak8bVaXF.G3JZ59Bwv.rj_bH6t9XWnZZGJ0XEASR.s1sTCP5LRz QVA_BIJqSUqMZwoJTfrvkc0RFJWKkkerbFZFhGgmqvjWeD5nxw1YNRikUC0x LCq.1XdI5Wt.16Q.YO5SxzICMP9OGliRDddKGZcho9CS6Arj8sG6hV.TVodv 6urSJAcoyT3HvXZvnCBprUkhvJ1YLVybiJ6ET Received: from [209.131.62.113] by web31802.mail.mud.yahoo.com via HTTP; Thu, 04 Aug 2011 18:06:15 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72345024864560@P3PW5EX1MB01.EX1.SECURESERVER.NET> <81B6B8AF-4EC0-4F08-B48C-D1E7B39AE506@oracle.com> Message-ID: <1312506375.29372.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 4 Aug 2011 18:06:15 -0700 (PDT) From: "William J. Mills" To: Eran Hammer-Lahav , Phil Hunt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1439757382-1312506375=:29372" Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 01:06:05 -0000 --0-1439757382-1312506375=:29372 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It's the proverbial 'void *client_data;' equivalent.=C2=A0 All names for th= at to date suck, my favorite is 'rock'.=0A=0A=0A=0A________________________= ________=0AFrom: Eran Hammer-Lahav =0ATo: Phil Hunt =0ACc: OAuth WG =0ASent: Thursday, Augu= st 4, 2011 4:42 PM=0ASubject: Re: [OAUTH-WG] MAC Tokens body hash=0A=0A=0AO= k. We seem to be using different definitions of what application data mean,= but have the same use cases in mind. I'll come up with a different name or= just keep ext.=C2=A0=0A=0AEHL=0A=0AOn Aug 3, 2011, at 12:42, "Phil Hunt" <= phil.hunt@oracle.com> wrote:=0A=0A=0AOnly allowing (implied or not) app dat= a is needlessly=C2=A0narrow in scope.=0A>=0A>=0A>Extending MAC to include c= laims or session information is a perfectly valid thing to do. It improves = scalability and reduces the need to look up artifact data.=C2=A0=0A>=0A>=0A= >Note: =C2=A0I'd like to share more on this, but I'm prioritizing the Threa= t Model document. Never-the-less, the above should be a sufficient example = about why extensibility is useful.=0A>=0A>=0A>Phil=0A>=0A>=0A>@independenti= d=0A>www.independentid.comphil.hunt@oracle.com=0A>=0A>=0A>=0A>=0A>=0A>=0A>O= n 2011-08-03, at 11:03 AM, Eran Hammer-Lahav wrote:=0A>=0A>My proposal is t= o change =E2=80=98ext=E2=80=99 to =E2=80=98app=E2=80=99, keep the same pros= e as =E2=80=98ext=E2=80=99, and add the use case of =E2=80=98bodyhash=E2=80= =99 as an example. I=E2=80=99m not too stuck on the name, but my thinking i= s that =E2=80=98app=E2=80=99 relays the right message that this is a place = where developers can stick any application data they want included. =E2=80= =98ext=E2=80=99 conveys the idea of extensions which I=E2=80=99m not so thr= illed about.=0A>>=C2=A0=0A>>In other words, I=E2=80=99d like a developer re= ading this to feel comfortable using it right away for securing addition bi= ts such as a JSON payload, but I don=E2=80=99t like the idea of someone pub= lishing an I-D with a full syntax and canonicalization requirements for say= , singing an entire request, headers and all. I feel that would be much bet= ter accomplished by defining a new HTTP authentication scheme.=0A>>=C2=A0= =0A>>Philosophically, I think extensible authentication schemes are a bad i= dea.=0A>>=C2=A0=0A>>EHL=0A>>=C2=A0=0A>>=C2=A0=0A>>From:=C2=A0William J. Mil= ls [mailto:wmills@yahoo-inc.com]=C2=A0=0A>>Sent:=C2=A0Wednesday, August 03,= 2011 10:28 AM=0A>>To:=C2=A0Phillip Hunt; Eran Hammer-Lahav=0A>>Cc:=C2=A0Be= n Adida; OAuth WG; Adam Barth(adam@adambarth.com)=0A>>Subject:=C2=A0Re: [OA= UTH-WG] MAC Tokens body hash=0A>>=C2=A0=0A>>In thinking about this I'm comi= ng around to the viewpoint that a single additional predefined spot is suff= icient.=C2=A0 If the app developer wants to include addtional data there (i= un the specified format) that's fine.=C2=A0 If what they want to do is incl= ude a signature of other payload that's fine too.=0A>>=C2=A0=0A>>I'm not in= love with the name "app" though, "ext" is better.=0A>>=C2=A0=0A>>=0A>>____= ____________________________=0A>>=0A>>From:=C2=A0Phillip Hunt =0A>>To:=C2=A0Eran Hammer-Lahav =0A>>Cc:=C2= =A0Ben Adida ; OAuth WG ; "Adam Barth(adam@a= dambarth.com)" =0A>>Sent:=C2=A0Tuesday, August 2, 2011 = 7:14 PM=0A>>Subject:=C2=A0Re: [OAUTH-WG] MAC Tokens body hash=0A>>=0A>>=0A>= >Phil=0A>>=0A>>On 2011-08-02, at 18:02, Eran Hammer-Lahav wrote:=0A>>The idea is to drop 'ext' and 'bodyhash' due to being under= specified and therefore causing more harm than good. I added 'ext' to allow= for application specific data to be included in the signed content. Howeve= r, the name suggests this is an extension point for future specifications. = I believe authentication schemes should not be extensible in ways that affe= ct their security or interop properties and without additional text (regist= ry, process, etc) for the 'ext' parameter, it will cause more issues than h= elp.=0A>>>=0A>>>Instead of the 'ext' parameter I am suggesting the 'app' pa= rameter which will do the same, but will be better positioned as an applica= tion-specific data. The prose will go a step further and recommend that the= parameter value include a hash of the data, not the data itself. This is t= o ensure the parameter does not become part of the payload which is inappro= priate for HTTP requests.=0A>>-1 what you describe appears to be a separate= feature from ext=0A>>=0A>>=0A>>=0A>>As for the 'bodyhash' parameter, I wou= ld like to remove it because it is underspecified (we had an actual deploym= ent experience showing that it doesn't produce interoperable implementation= s due to the many HTTP body transformation applied in most frameworks). Sol= ving this issue is not possible due to the many different types of bodies a= nd frameworks (and clearly operating on the "raw" body doesn't work). Inste= ad, developers can use the new 'app' parameter to accomplish that.=0A>>=C2= =A0=0A>>+1=0A>>=0A>>=0A>>=0A>>=0A>>As for the normalized string, it will be= adjusted to reflect these changes when they are made, so no placeholders w= hich will require code change. Considering this is -00, it is clearly not a= stable document.=0A>>Will these changes work with your use cases?=0A>>>=0A= >>>EHL=0A>>>=0A>>>=0A>>>=0A>>>-----Original Message-----=0A>>>From: Skylar = Woodward=C2=A0[mailto:skylar@kiva.org]=0A>>>Sent: Tuesday, August 02, 2011 = 4:02 PM=0A>>>To: Eran Hammer-Lahav=0A>>>Cc: OAuth WG; Ben Adida; 'Adam Bart= h (adam@adambarth.com)'=0A>>>Subject: Re: [OAUTH-WG] MAC Tokens body hash= =0A>>>=C2=A0=0A>>>hurrah!=0A>>>(not necessarily for losing a way to sign th= e body, but for simplicity and=0A>>>avoiding some of the potential inconsis= tencies w/ bodyhash).=0A>>>=C2=A0=0A>>>Is your plan to reserve an empty lin= e 6 for the Normalized Request String=0A>>>(which was used for bodyhash) or= eliminate it, brining the total to six=0A>>>elements?=0A>>>=C2=A0=0A>>>sky= lar=0A>>>=C2=A0=0A>>>On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote:= =0A>>>=C2=A0=0A>>>I plan to drop support for the bodyhash parameter in the = next draft based=0A>>>on bad implementation experience. Even with simple te= xt body, UTF=0A>>>encoding has introduced significant issues for us. The cu= rrent draft does not=0A>>>work using simple JS code between a browser and n= ode.js even when both=0A>>>use the same v8 engine due to differences in the= body encoding. Basically,=0A>>>the JS string used to send a request from t= he browser is not the actual string=0A>>>sent on the wire.=0A>>>=C2=A0=0A>>= >To fix that, we need to force UTF-8 encoding on both sides. However, that= =0A>>>is very much application specific. This will not work for non-text bo= dies.=0A>>>Instead, the specification should offer a simple way to use the = ext parameter=0A>>>for such needs, including singing headers. And by offer = I mean give=0A>>>examples, but leave it application specific for now.=0A>>>= =C2=A0=0A>>>I am open to suggestions but so far all the solutions I came up= with will=0A>>>introduce unacceptable complexity that will basically make = this work useless.=0A>>>=C2=A0=0A>>>EHL=0A>>>______________________________= _________________=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https://= www.ietf.org/mailman/listinfo/oauth=0A>>>=0A>>>____________________________= ___________________=0A>>>OAuth mailing list=0A>>>OAuth@ietf.org=0A>>>https:= //www.ietf.org/mailman/listinfo/oauth=0A>>=0A>>____________________________= ___________________=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://w= ww.ietf.org/mailman/listinfo/oauth=0A>>=0A>>=0A>=0A________________________= _______________________=0A>OAuth mailing list=0A>OAuth@ietf.org=0A>https://= www.ietf.org/mailman/listinfo/oauth=0A>=0A_________________________________= ______________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org= /mailman/listinfo/oauth --0-1439757382-1312506375=:29372 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It's the proverbial 'void *client_data;' equivalent.  All names for = that to date suck, my favorite is 'rock'.

From: Eran Hammer-Lahav= <eran@hueniverse.com>
To: Phil Hunt <phil.hunt@oracle.com>
Cc: OAuth WG <oauth@ietf.org>
Sent: Thursday, August 4, 2011 4:42 = PM
Subject: Re: [OAUTH-= WG] MAC Tokens body hash

Ok. We seem to be us= ing different definitions of what application data mean, but have the same = use cases in mind. I'll come up with a different name or just keep ext.&nbs= p;

Only all= owing (implied or not) app data is needlessly narrow in scope.

Extending MAC to include claims or session information is= a perfectly valid thing to do. It improves scalability and reduces the nee= d to look up artifact data. 

Note:  I'd = like to share more on this, but I'm prioritizing the Threat Model document.= Never-the-less, the above should be a sufficient example about why extensibility is useful.

Phil
<= span class=3D"yiv389668866Apple-style-span" style=3D"border-collapse:separa= te;color:rgb(0, 0, 0);font-family:Helvetica;font-style:normal;font-variant:= normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:= 2;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;wi= dows:2;word-spacing:0px;font-size:medium;">

@independentid
<= a rel=3D"nofollow" target=3D"_blank" href=3D"http://www.independentid.com">= www.independentid.com
phil.hunt@oracle.com



=0A
=0A
On 2011-08-03, = at 11:03 AM, Eran Hammer-Lahav wrote:

=
My proposal is to chang= e =E2=80=98ext=E2=80=99 to =E2=80=98app=E2=80=99, keep the same prose as = =E2=80=98ext=E2=80=99, and add the use case of =E2=80=98bodyhash=E2=80=99 a= s an example. I=E2=80=99m not too stuck on the name, but my thinking is that =E2=80=98app=E2=80=99 relays the righ= t message that this is a place where developers can stick any application d= ata they want included. =E2=80=98ext=E2=80=99 conveys the idea of extension= s which I=E2=80=99m not so thrilled about.
 
In other words, I=E2=80=99d like a d= eveloper reading this to feel comfortable using it right away for securing = addition bits such as a JSON payload, but I don=E2=80=99t like the idea of = someone publishing an I-D with a full syntax and canonicalization requireme= nts for say, singing an entire request, headers and all. I feel that would be much better accomplished by defining= a new HTTP authentication scheme.
 
Philosophically, I think extensible authenti= cation schemes are a bad idea.
 
EHL
 
 
= From: William J. Mills = [mailto:wmills@yahoo-inc.com] 
Sent: Wednesday, August 03, 2011 10:28 AM
To: Phillip Hunt; Era= n Hammer-Lahav
Cc: Ben Adida; OAuth = WG; Adam Barth(adam@adamba= rth.com)
Subject: Re: [OAUTH-WG] MAC Tokens body hash
 
In thinking about this I'm com= ing around to the viewpoint that a single additional predefined spot is suf= ficient.  If the app developer wants to include addtional data there (iun the specified for= mat) that's fine.  If what they want to do is include a signature of o= ther payload that's fine too.
 
I'm not in love with the name "app" though, "= ext" is better.
 
From:=  Phillip H= unt <phil.hunt@oracle.com>
To= : Eran Ha= mmer-Lahav <eran@hu= eniverse.com>
Cc: Ben Adida <ben@adida.= net>; OAuth WG <oauth@ietf.org>; "Adam Barth(adam@adambarth.com)" <= adam@adambarth.com>
Se= nt: Tuesd= ay, August 2, 2011 7:14 PM
Subject: Re: [OAUTH-WG] MAC Tokens body hash=


Phil

On 2011-08-02, at 18:02, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:
The idea is to drop 'ext' and 'bodyhash' due to being und= erspecified and therefore causing more harm than good. I added 'ext' to all= ow for application specific data to be included in the signed content. Howe= ver, the name suggests this is an extension point for future specifications= . I believe authentication schemes should not be extensible in ways that af= fect their security or interop properties and without additional text (regi= stry, process, etc) for the 'ext' parameter, it will cause more issues than= help.

Instead of the 'ext' parameter I am suggesting the 'app' para= meter which will do the same, but will be better positioned as an applicati= on-specific data. The prose will go a step further and recommend that the p= arameter value include a hash of the data, not the data itself. This is to ensure the parameter does not become part of the payload which is inapp= ropriate for HTTP requests.
Cc: OAuth WG; Ben Adida; 'Adam Barth (= adam@adambarth.com)'
Subject: Re: [OAUTH-WG] MAC Tokens body hash
 
hurrah!<= /span>
<= span style=3D"color:black;">(not necessarily for losing a way to sign the b= ody, but for simplicity and
avoiding some of th= e potential inconsistencies w/ bodyhash).
 
Is your plan to reser= ve an empty line 6 for the Normalized Request String
(which was used for bodyhash) or eliminate it, brining the total to s= ix
elements?
 
skylar
 
On Jul 30, 2011, at 3:43 AM, Eran Hamme= r-Lahav wrote:
 
I plan to drop= support for the bodyhash parameter in the next draft based
on bad implementation exper= ience. Even with simple text body, UTF
encoding= has introduced significant issues for us. The current draft does not
work using simple JS code between a browser and node= .js even when both
use the same v8 engine due to differ= ences in the body encoding. Basically,
the JS s= tring used to send a request from the browser is not the actual string
sent on the wire.
 
=
To fix that, we need to force UTF-8 encoding on both sides. However, tha= t
is very much application specifi= c. This will not work for non-text bodies.
Instead, the s= pecification should offer a simple way to use the ext parameter
for such needs, including singing headers. And by offer I= mean give
examples, but leave it application s= pecific for now.
 
I am open to suggestions but s= o far all the solutions I came up with will
introduce unacceptable complexity that will basical= ly make this work useless.
 
EHL
_______________________________________________
OAuth mailing list

_______________________________________________=
OAuth mailing list
OAuth@ietf.org
<= a rel=3D"nofollow" target=3D"_blank" href=3D"https://www.ietf.org/mailman/l= istinfo/oauth">https://www.ietf.org/mailman/listinfo/oauth
=

_______________________________________________
OAuth mailin= g list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth

<= /span>

_______________________________________________
<= span>OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/= mailman/listinfo/oauth

_________= ______________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


=
--0-1439757382-1312506375=:29372-- From phil.hunt@oracle.com Fri Aug 5 11:42:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F78421F8B95 for ; Fri, 5 Aug 2011 11:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyEAYdw-jyTh for ; Fri, 5 Aug 2011 11:42:34 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id B3EF521F8B7D for ; Fri, 5 Aug 2011 11:42:34 -0700 (PDT) Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p75Igag5008844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 5 Aug 2011 18:42:38 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p75IgZBs022480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Aug 2011 18:42:36 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p75IgTQE025528 for ; Fri, 5 Aug 2011 13:42:30 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Aug 2011 11:42:29 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary=Apple-Mail-41--744900609 Date: Fri, 5 Aug 2011 11:42:28 -0700 References: To: OAuth WG Message-Id: <4DE1850A-F03B-491A-A860-0051838D66B0@oracle.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E3C399E.00E1,ss=1,re=0.000,fgs=0 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 18:42:35 -0000 --Apple-Mail-41--744900609 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cross-posting feedback from Scott Cantor regarding change to subject = confirmation processing. Comments?=20 Phil @independentid www.independentid.com phil.hunt@oracle.com Begin forwarded message: > From: "Cantor, Scott E." > Date: August 4, 2011 9:45:57 AM PDT > To: Phillip Hunt , SAML = > Subject: Re: [security-services] Fwd: [OAUTH-WG] I-D Action: = draft-ietf-oauth-saml2-bearer-05.txt >=20 > On 8/4/11 11:36 AM, "Phillip Hunt" wrote: >>=20 >> Lastly the processing rules on the assertion have been relaxed >> somewhat to allow for element(s) to be >> optional when the element has a NotOnOrAfter attribute. >=20 > Omitting subject confirmation just means the assertion has no security > semantics or that it's "sender vouches". You could do bearer by > implication, but that's sloppy. Assertions should be self-defining > whenever possible, not punt their semantics to implication. >=20 > -- Scott >=20 >=20 > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >=20 --Apple-Mail-41--744900609 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





Begin forwarded message:

From: "Cantor, Scott E." = <cantor.2@osu.edu>
=
Date: August 4, 2011 = 9:45:57 AM PDT
Subject: Re: [security-services] Fwd: [OAUTH-WG] I-D = Action: = draft-ietf-oauth-saml2-bearer-05.txt

On = 8/4/11 11:36 AM, "Phillip Hunt" <phil.hunt@oracle.com> = wrote:

Lastly the processing rules on the assertion have been = relaxed
somewhat to allow for = <SubjectConfirmationData> element(s) to = be
optional when the = <Conditions> element has a NotOnOrAfter = attribute.

Omitting subject confirmation just means = the assertion has no security
semantics or that it's "sender = vouches". You could do bearer by
implication, but that's sloppy. = Assertions should be self-defining
whenever possible, not punt their = semantics to implication.

-- = Scott


---------------------------------------------------------= ------------
To unsubscribe from this mail list, you must leave the = OASIS TC that
generates this mail.  Follow this link to all your = TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p= hp


= --Apple-Mail-41--744900609-- From eran@hueniverse.com Sat Aug 6 00:29:56 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8949A21F875E for ; Sat, 6 Aug 2011 00:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OekgUYLelWq for ; Sat, 6 Aug 2011 00:29:55 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 67B8821F8764 for ; Sat, 6 Aug 2011 00:29:55 -0700 (PDT) Received: (qmail 25104 invoked from network); 6 Aug 2011 07:30:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Aug 2011 07:30:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 6 Aug 2011 00:30:14 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sat, 6 Aug 2011 00:29:14 -0700 Thread-Topic: Security area review Thread-Index: AcxUCkhjqPDQ6LCfRJq7Xce6UpkIXw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345024864A96@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345024864A96P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Security area review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 07:29:56 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345024864A96P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Did the chairs issue a last call request to anyone in the security area? I = thought the whole point of moving this working group from apps to security = was to increase the review and participation of that area. So far I have se= en absolutely nothing to indicate any such contribution. I would like to kn= ow what actual actions are being taken to turn this promise into reality. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72345024864A96P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Did the chairs i= ssue a last call request to anyone in the security area? I thought the whol= e point of moving this working group from apps to security was to increase = the review and participation of that area. So far I have seen absolutely no= thing to indicate any such contribution. I would like to know what actual a= ctions are being taken to turn this promise into reality.

 

EHL<= /p>

= --_000_90C41DD21FB7C64BB94121FBBC2E72345024864A96P3PW5EX1MB01E_-- From barryleiba.mailing.lists@gmail.com Sun Aug 7 20:28:06 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A92521F8862 for ; Sun, 7 Aug 2011 20:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.05 X-Spam-Level: X-Spam-Status: No, score=-103.05 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlOS7LvvYhi1 for ; Sun, 7 Aug 2011 20:28:05 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A6B1321F8849 for ; Sun, 7 Aug 2011 20:28:05 -0700 (PDT) Received: by yie12 with SMTP id 12so1002181yie.31 for ; Sun, 07 Aug 2011 20:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=R9jt4gj+tdTjx2cew00LexhFnn5TX2rIG3Vd0xvF1gk=; b=Nik012iUnLmzSj3JQAT+pXrjqZN7F62ClkdGtE7poBkajvVvtAekURfdY6vDT2YXdf PzGeJzosXbg5Gq74rcBeHFbAwiNDUcdJfOrd3dfp+L7dVn5xWufBBnwOffYp0vKwdZo0 IxK5lZmM70yZNAissGt3yDmtyqj1VWWOqljY8= MIME-Version: 1.0 Received: by 10.146.36.16 with SMTP id j16mr723017yaj.8.1312774110177; Sun, 07 Aug 2011 20:28:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.38.7 with HTTP; Sun, 7 Aug 2011 20:28:30 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345024864A96@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345024864A96@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 7 Aug 2011 23:28:30 -0400 X-Google-Sender-Auth: n2fz-dlBJ2KimXSThVzmH6ODLP4 Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security area review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 03:28:06 -0000 > Did the chairs issue a last call request to anyone in the security area? I > thought the whole point of moving this working group from apps to security > was to increase the review and participation of that area. So far I have > seen absolutely nothing to indicate any such contribution. I would like to > know what actual actions are being taken to turn this promise into reality. There'll be a security directorate review when we send the doc to the IESG. I can certainly ask Sam to schedule a review now, instead of waiting, and I'll do that. Barry, as chair From eran@hueniverse.com Sun Aug 7 23:00:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD78221F89A7 for ; Sun, 7 Aug 2011 23:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZBUzHvgrW5K for ; Sun, 7 Aug 2011 23:00:20 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 4AE8321F883A for ; Sun, 7 Aug 2011 23:00:20 -0700 (PDT) Received: (qmail 21867 invoked from network); 8 Aug 2011 06:00:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Aug 2011 06:00:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 7 Aug 2011 23:00:45 -0700 From: Eran Hammer-Lahav To: Barry Leiba Date: Sun, 7 Aug 2011 22:59:41 -0700 Thread-Topic: [OAUTH-WG] Security area review Thread-Index: AcxVe0Y3uRtlVaojRieexc0s+ZDEcAAFF24A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345024864B07@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345024864A96@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security area review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 06:00:20 -0000 Thanks. But this still puzzles me. After two years in the application area where IM= O this working clearly belongs, we were moved to the security area under th= e premise of increased review and engagement from the security area. EHL > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com > [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba > Sent: Sunday, August 07, 2011 8:29 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Security area review >=20 > > Did the chairs issue a last call request to anyone in the security > > area? I thought the whole point of moving this working group from apps > > to security was to increase the review and participation of that area. > > So far I have seen absolutely nothing to indicate any such > > contribution. I would like to know what actual actions are being taken = to > turn this promise into reality. >=20 > There'll be a security directorate review when we send the doc to the IES= G. I > can certainly ask Sam to schedule a review now, instead of waiting, and I= 'll do > that. >=20 > Barry, as chair From rbarnes@bbn.com Mon Aug 8 05:24:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69B421F8AD6 for ; Mon, 8 Aug 2011 05:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IRQ34fag3mp for ; Mon, 8 Aug 2011 05:24:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2E84121F8ABC for ; Mon, 8 Aug 2011 05:24:30 -0700 (PDT) Received: from [128.89.254.201] (port=49683 helo=[192.168.1.12]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QqOt4-000LxJ-Kg; Mon, 08 Aug 2011 08:24:55 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345024864B07@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 8 Aug 2011 08:24:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4E029255-2F7B-45F2-813E-66880B4B5B5A@bbn.com> References: <90C41DD21FB7C64BB94121FBBC2E72345024864A96@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345024864B07@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: Barry Leiba , OAuth WG Subject: Re: [OAUTH-WG] Security area review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 12:24:31 -0000 I've been loosely following this group, probably not as closely as I = should have. I'll put it in my queue to do a review of the current doc = as a way of getting back in the fray. --Richard On Aug 8, 2011, at 1:59 AM, Eran Hammer-Lahav wrote: > Thanks. >=20 > But this still puzzles me. After two years in the application area = where IMO this working clearly belongs, we were moved to the security = area under the premise of increased review and engagement from the = security area. >=20 > EHL >=20 >> -----Original Message----- >> From: barryleiba.mailing.lists@gmail.com >> [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba >> Sent: Sunday, August 07, 2011 8:29 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Security area review >>=20 >>> Did the chairs issue a last call request to anyone in the security >>> area? I thought the whole point of moving this working group from = apps >>> to security was to increase the review and participation of that = area. >>> So far I have seen absolutely nothing to indicate any such >>> contribution. I would like to know what actual actions are being = taken to >> turn this promise into reality. >>=20 >> There'll be a security directorate review when we send the doc to the = IESG. I >> can certainly ask Sam to schedule a review now, instead of waiting, = and I'll do >> that. >>=20 >> Barry, as chair > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From barryleiba@gmail.com Mon Aug 8 06:14:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2690121F86BE for ; Mon, 8 Aug 2011 06:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.049 X-Spam-Level: X-Spam-Status: No, score=-103.049 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpYD7oHcQPhZ for ; Mon, 8 Aug 2011 06:14:43 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5DC21F86BD for ; Mon, 8 Aug 2011 06:14:43 -0700 (PDT) Received: by gxk19 with SMTP id 19so885044gxk.31 for ; Mon, 08 Aug 2011 06:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nkThGe3qT856bg7ANUiuwSiegZ6vtEeFhCzSGu3kFSc=; b=nyKA1UzEJECV1XaEbaSxV6vlOF7GFOcSBPRNB/4N8teuMUWgR7aiJpHySM02wOnv8m 0PYCfa909unDhteAARPX4qITH8AJMw/l4f48dgpuWR2keNRItFmsgga0wsw3M5rXJ4kz LGge33an8Y5ai7/mjnD64/LhIcJ17feQ6sRMw= MIME-Version: 1.0 Received: by 10.236.76.170 with SMTP id b30mr1201962yhe.213.1312809305613; Mon, 08 Aug 2011 06:15:05 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.207.132 with HTTP; Mon, 8 Aug 2011 06:15:05 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345024864B07@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345024864A96@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345024864B07@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 8 Aug 2011 09:15:05 -0400 X-Google-Sender-Auth: 6ISUkoeaj571Jl5S5jNSOw4lTcQ Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security area review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 13:14:44 -0000 > But this still puzzles me. After two years in the application area where IMO this > working clearly belongs, we were moved to the security area under the premise > of increased review and engagement from the security area. I can't speak for the IESG, and it's they who made the decision to move the WG. But I can say that I disagree that it "clearly belongs" in the App area. From the start, I was puzzled why it wasn't chartered in the Sec area; OAuth is, to me, a security protocol that's used at the app layer (as opposed to an app protocol that happens to include security). DKIM was in a similar situation -- having bits in both areas -- and in 2006 was chartered in Sec... and that one seemed even more that it should have been in Apps. We have puzzling situations often, these days, where working groups "clearly belong" in more than one area, and the way things currently work, the IESG has to choose. ALTO might have been in RAI or App, was chartered in App, and now is in TSV. We've had a few recently chartered WGs where there was some debate about which area they belong in. I've thought for some time that we should have multi-area WGs, but that's not the case now. Don't pay too much attention to which AD manages the WG. Barry From julian.reschke@gmx.de Tue Aug 9 05:06:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E83D21F8B04 for ; Tue, 9 Aug 2011 05:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.501 X-Spam-Level: X-Spam-Status: No, score=-104.501 tagged_above=-999 required=5 tests=[AWL=-1.902, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeZrS9+Jke+P for ; Tue, 9 Aug 2011 05:06:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5B3B821F8AF9 for ; Tue, 9 Aug 2011 05:06:09 -0700 (PDT) Received: (qmail invoked by alias); 09 Aug 2011 12:06:36 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp067) with SMTP; 09 Aug 2011 14:06:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX187auIBG5I7znlZtPYCm2o8ccFIZN4PR/sp0cR/aO ngyyg+QABKEtbM Message-ID: <4E4122C9.8080602@gmx.de> Date: Tue, 09 Aug 2011 14:06:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 12:06:10 -0000 Hi there, below a few comments on dependencies to HTTPbis, and the actual header field syntax. Best regards, Julian -- snip -- 1.1. Notational Conventions ... This document uses the Augmented Backus-Naur Form (ABNF) notation of [I-D.ietf-httpbis-p1-messaging], which is based upon the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Additionally, the following rules are included from [RFC2617]: auth-param and realm; from [RFC3986]: URI-Reference; and from [I-D.ietf-httpbis-p1-messaging]: RWS and quoted-string. auth-param and realm should come from I-D.ietf-httpbis-p7-auth (optimally from a version >= 16 which we should get out before the end of the month). 2. Authenticated Requests Clients SHOULD make authenticated requests with a bearer token using the "Authorization" request header field defined by [RFC2617]. -> HTTPbis P7 2.1. The Authorization Request Header Field The "Authorization" request header field is used by clients to make authenticated requests with bearer tokens. The client uses the "Bearer" authentication scheme to transmit the access token in the request. For example: GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer vF9dft4qmT The "Authorization" header field uses the framework defined by [RFC2617] as follows: credentials = "Bearer" RWS access-token access-token = 1*( quoted-char / <"> ) quoted-char = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / ":" / "<" / "=" / ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" This is incompatible with the RFC2617 grammar which requires auth-params. HTTPbis P7 will introduce an alternative syntax ("b64token"), but that is restricted to a single instance and thus not extensible. I recommend to use auth-param syntax instead. 2.2. Form-Encoded Body Parameter ... o The entity-body follows the encoding requirements of the "application/x-www-form-urlencoded" content-type as defined by [W3C.REC-html401-19991224]. o The HTTP request entity-header includes the "Content-Type" header field set to "application/x-www-form-urlencoded". What about parameters? o The HTTP request method is one for which a body is permitted to be present in the request. In particular, this means that the "GET" method MUST NOT be used. GET permits a body; it's just not useful. 2.4. The WWW-Authenticate Response Header Field If the protected resource request does not include authentication credentials or contains an invalid access token, the resource server MUST include the HTTP "WWW-Authenticate" response header field; it MAY include it in response to other conditions as well. The "WWW-Authenticate" header field uses the framework defined by [RFC2617] as follows: -> HTTPbis P7 challenge = "Bearer" [ RWS 1#param ] -> please stick to the syntax defined in the authentication framework, so use "auth-param", and just define the allowed parameters separately. param = realm / scope / error / error-desc / error-uri / auth-param scope = "scope" "=" <"> scope-v *( SP scope-v ) <"> scope-v = 1*quoted-char -> This seems to override the quoted-string syntax. Don't. Generic parsers *will* use the quoted-string syntax. quoted-char = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / ":" / "<" / "=" / ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" error = "error" "=" quoted-string error-desc = "error_description" "=" quoted-string error-uri = "error_uri" "=" <"> URI-reference <"> -> missing I18N considerations -> weird syntax (why underscore?) -> the generic syntax allows token in addition to quoted-string; it's pointless to rule that out here 4. IANA Considerations -> If you have a dependency on HTTPbis then you should also add the registration for the authentication scheme as defined in HTTPbis P7. From stpeter@stpeter.im Tue Aug 9 11:57:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D5711E80D0 for ; Tue, 9 Aug 2011 11:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMAzEzz32T8L for ; Tue, 9 Aug 2011 11:57:58 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9590911E809E for ; Tue, 9 Aug 2011 11:57:58 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DCF7A413D9; Tue, 9 Aug 2011 13:00:04 -0600 (MDT) Message-ID: <4E418352.1030100@stpeter.im> Date: Tue, 09 Aug 2011 12:58:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Julian Reschke References: <4E4122C9.8080602@gmx.de> In-Reply-To: <4E4122C9.8080602@gmx.de> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 18:57:59 -0000 On 8/9/11 6:06 AM, Julian Reschke wrote: > 1.1. Notational Conventions > > ... > > This document uses the Augmented Backus-Naur Form (ABNF) notation of > [I-D.ietf-httpbis-p1-messaging], which is based upon the Augmented > Backus-Naur Form (ABNF) notation of [RFC5234]. Additionally, the > following rules are included from [RFC2617]: auth-param and realm; > from [RFC3986]: URI-Reference; and from > [I-D.ietf-httpbis-p1-messaging]: RWS and quoted-string. > > auth-param and realm should come from I-D.ietf-httpbis-p7-auth > (optimally from a version >= 16 which we should get out before the end > of the month). And also add I-D.ietf-httpbis-p7-auth to the normative references. It appears that the authors are OK with normative references to the httpbis document series, but just so we're all aware that might delay publication of an RFC for the bearer token format spec... Peter -- Peter Saint-Andre https://stpeter.im/ From Michael.Jones@microsoft.com Wed Aug 10 14:38:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BD55E800C for ; Wed, 10 Aug 2011 14:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.275 X-Spam-Level: X-Spam-Status: No, score=-9.275 tagged_above=-999 required=5 tests=[AWL=-1.092, BAYES_40=-0.185, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTMdHWFZOI1c for ; Wed, 10 Aug 2011 14:38:10 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 06BA221F898E for ; Wed, 10 Aug 2011 14:38:10 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 10 Aug 2011 14:38:42 -0700 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.65]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0323.007; Wed, 10 Aug 2011 14:38:42 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Partial set of last call comments on OAuth draft 20 from Yaron Goland Thread-Index: AcxXpdCrqvPON2CRS72O2K03CR90kw== Date: Wed, 10 Aug 2011 21:38:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739434A80B587TK5EX14MBXC201r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 21:38:21 -0000 --_000_4E1F6AAD24975D4BA5B16804296739434A80B587TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1.4. Authorization Grant: Change "resource owner authorization" to "resourc= e owner's authorization". 1.4.1. Authorization Code: Comment: "It seems odd that we can discuss the = authorization code without also discussing the security issues it raises (e= .g. passing secure information via a browser) and thus motivating the intro= duction of the refresh token. I would expect this to be referred to here. = Having read the security considerations section I can find no coherent disc= ussion there either of the relationship between the authorization code and = the refresh token and why one motivated the other. I think this is somethin= g important for implementers to understand." 1.4.2. Implicit: Comment: "I find this section confusing. I think an exam= ple is all but mandatory here if the reader is to understand what is intend= ed. For example, when I first read this section I thought it was some kind= of short cut used in cases where the client and authorization server had a= close relationship and could share information such as the client's identi= ty so no access code was needed. No where in here is any hint that this is= about browser based clients who don't have servers and who need a way to g= et tokens. Seriously. Try to read this section as someone who knows nothing= about OAuth and tell me that you get the right idea back from it. It needs= to be written to be both explicit as to its goals and clearer as to its me= ans." 1.4.2. Implicit: Change "authenticate the client and the" to "authenticat= e the client directly. The". 1.4.2. Implicit: Change "weighted" to "weighed". 1.4.3. Resource Owner Password Credentials: Comment on "(when combined wit= h a refresh token)": "This is the first time that refresh tokens are mentio= ned in the spec. And yet there is no explanation of what they are. I suspec= t they should anyway be introduced in section 1.4.1 (as previously noted) a= nd then their use here will make sense. If that isn't possible then it wou= ld be good to have a forward reference to section 1.5 below so the reader h= as some idea of what's going on." 1.4.4. Client Credentials: Comment on "(the client is also the resource o= wner)": "I think this is misleading. Imagine something like Office where a = client has been granted access to a particular resource by the resource own= er. The client can then ask for an access token to the resource using the c= lient credentials and no access code or refresh token. Just having the addr= ess of the intended resource (probably provided via SCOPE) along with the c= lient credentials is more than enough to decide if an access token should b= e issued. My point is that the client credentials scenario is fully applicable to cas= es where the client is not the resource owner but in which the resource URI= provides all the context needed to determine if the client should be able = to get an access token. I think the current text would imply otherwise. So I would propose changing the sentence to "Client credentials are used as= an authorization grant when the client is acting on its own behalf (the cl= ient is also the resource owner) or when the authorization server has enoug= h context to determine from the access token request if the client has auth= orization to access the requested resource."" 1.4.5. Extensions: Comment: "I would change this sentence to read "Addition= al grant types may be defined to support new approaches to authentication/a= uthorization as well as to provide a bridge between OAuth and other protoco= ls."" 1.5. Refresh Token: Comment on "Refresh tokens are credentials used to obta= in access tokens.": "This sentence presumes that refresh tokens are self-co= ntained credentials. In other words that one can get an access token just u= sing a refresh token and nothing else. This presumption is rebutted later i= n the document but I think it's confusing to imply one thing here and state= otherwise later on." 1.5. Refresh Token: Change "a protected resource requests" to "a protected = resource request". 1.5. Refresh Token: Comment on "(G) The client requests a new access token= by authenticating with the authorization server and presenting the refresh= token.": "Hum... now the text seems to contradict itself. Above it seemed = like you could use the refresh token by itself to get an access token and I= had to ask for language that made it clear that you could use a refresh to= ken with other credentials. But the text of point G now implies the exact = opposite, that refresh tokens can only be used with other credentials and n= ot by themselves. (Even though the picture in figure 2 for step G implies t= he opposite). I would edit this language to say "The client requests a new = access token. Depending on the authorization server's policies this request= might be made with the refresh token by itself or with a combination of th= e refresh token and other client credentials."" 2.1. Client Types: Comment on "user-agent-based application": "Give the poo= r reader a hint and mention 'browser' somewhere in the paragraph below. For= example "A user-agent-based application is a public client (such as a web = browser) in which the...."" 2.1. Client Types: web application: Change "access tokens or refresh tokens= , can receive an acceptable level" to "access tokens or refresh tokens, can= , in some cases, receive an acceptable level". 2.4. Client Authentication: Add a period after "etc". 2.4.1. Client Password: Comment on "charset=3DUTF-8": "The use of UTF-8 wit= h x-www-form-urlencoded is explicitly banned by HTML 4.01 section 17.13.1. = If we want to use UTF-8 then we have to use multipart/form-data, also defin= ed by HTML 4.01 (section 17.13.4). But since nobody would actually want to = do that I would suggest putting in a reference to section 4.2 of RFC 5552 w= hich actually defines how to use UTF-8 with x-www-form-urlencoded and speci= fying that the 5552 extension MUST be supported by OAuth participants." 3.1. Authorization Endpoint: Comment on first sentence: "There is a third= option - none of the above. It would be a shame if the text of this draft= explicitly prohibits that pattern." 3.1. Authorization Endpoint: Comment on "[RFC3986] section 3": "Shouldn't= we point directly to section 3.4 which exactly defines the query component= ?" 3.1. Authorization Endpoint: Comment on "MUST be retained when adding add= itional query parameters": "HIGH IMPORTANCE - This specification is incomplete. Sectio= n 3.4 of RFC 3986 simply asserts the existence of a query component. It say= s nothing about the syntax of that component. The spec assumes that the com= ponent is using x-www-form-urlencoded but that is not in any way mandated b= y RFC 3986. So there is a normative sentence missing here which states that= any query parameter on the authorization endpoint's URI MUST be defined as= specified in x-www-form-urlencoded." 3.1. Authorization Endpoint: Comment on "The authorization server SHOULD = ignore unrecognized request parameters.": "Although that is normal behavior= for application protocols it seems rather dangerous for a security protoco= l. After all what if the client put in a parameter specifying something sec= urity related about the request thinking that the authorization endpoint wo= uld honor it and then the authorization endpoint silently ignores it? Agai= n, this is a security protocol, not a generic application protocol, it seem= s to be that unrecognized parameters should cause a failure." 3.1.2. Redirection Endpoint: Comment on "when initiating the authorization= request": "I would suggest more explicit language "or as specified in the = redirection URI value in the authorization request."" 3.1.2.2. Registration Requirements: Comment on last word "path": "Huh? Sche= me, authorization and path is a complete URI minus a query component. Is t= he goal to specifically mandate that only the query component can vary and = the rest of the URI MUST be static? If so that should be stated explicitly = rather than implicitly as it is now. But I think, if that is the intent, i= t goes too far. We should also allow for additional path segments to be add= ed to the URI path beyond the registered prefix. Assuming we can address th= e security problem in the next comment." 3.1.2.3. Dynamic Configuration: Comment on "section 6": "The reference to = section 6 is incomplete. Section 6 defines no less than 6 different axis's = on which URI comparisons can vary. Furthermore as recently documented in dr= aft-thaler-iab-identifier-comparison-00.txt it is trivially easy to screw u= p URI comparisons and the security implications are pretty dire. Personally= I think that the only sane approach given the issues in the previous link = is to adopt section 6.2.1 of RFC 3986. I am a bit scared of how to handle partial matches. It's tempting to argue = that so long as the schema has an authority and at least one path segment t= hen we can just use a partial string match but boy oh boy do I see people s= crewing that one up royally. This is scary enough that I think I can be arg= ued into saying that partial pre-registered URIs MUST only differ by the qu= ery component. In any case this issues needs to be explicitly called out for all URI compa= risons required by the spec and normatively defined. Otherwise we will end = up with all the security issues in Dave's ID." 3.1.2.4. Invalid Endpoint: Comment on "open redirector": "How many people = even know what the heck an open redirector is? I think we need a section in= the security considerations section that defines what an open redirector i= s and why it's bad. Alternatively a normative reference to a complete defin= ition somewhere else is also fine." 3.2.1. Client Authentication: Change "Recovery" to "Recovering". 3.2.1. Client Authentication: Change "credentials, by preventing an attacke= r from abusing" to "credentials. This prevents an attacker from abusing" 3.2.1. Client Authentication: Change "periodic credentials rotation" to "pe= riodic credential rotation". 3.2.1. Client Authentication: Comment on "while rotation of a single set of= client credentials is significantly easier": "The spec calls out rotation = of credentials as being crucial but then doesn't define how this is to be d= one? That seems kind of odd. Shouldn't we define an endpoint where one can = submit one's old but unexpired credentials for new ones? This still leaves = the edge case of what to do if the old credentials have expired and new one= s haven't been issued but that is unavoidable and in that case we can requi= re out of scope action." 4.1. Authorization Code: Comment on first "^": "Shouldn't this be a v chara= cter and not a ^? This would make it consistent with A which also crosses t= wo boxes and points in the same direction." 4.1. Authorization Code: Change "If valid, responds back with an access tok= en" to "If the request is valid, then the authorization server will respond= s back with an access token and optionally a refresh token". 4.1.2. Authorization Response: Comment "The language around scopes in the = document is really frustrating. One only finds out much later in the docume= nt that it is perfectly allowable for an authorization server to more or le= ss ignore what scopes are submitted and instead to just return whatever the= hell they want. This is a fine design choice but it seems like the sort of= thing that should be forcefully repeated anywhere in the spec that we allo= w people to submit scopes so nobody forgets." 4.1.2. Authorization Response: Comment on "state": "Don't we have to provi= de some guidance on how large the state value can safely be? Otherwise we a= re asking clients to rewrite their state mechanisms every time they throw i= n support for a new protected resource server. We have to set expectations = across the industry if we are to hope for actual interoperability." 4.1.2.1. Error Response: Comment on "UTF-8 encoded text": "I think just say= ing UTF-8 encoded text can be misleading. It's not legal to put UTF-8 chara= cters into a x-www-form-urlencoded used in a GET (as defined by section 17.= 13.1 of HTML 4.01). So what you have to do is take the UTF-8 String and the= n URL encode it. Which is fine but we should call this out. Note that this= is a separate issue than UTF-8 support for x-www-form-urlencoded. That iss= ue only applies when the form is in the request body. In this scenario the = form is in a URL. There is no question that URLs in HTTP request lists don'= t support UTF-8." 4.1.3. Access Token Request: Change "For example, the client makes the foll= owing HTTP using" to "For example, if the client makes the following HTTP r= equest using" 4.1.3. Access Token Request: Comment on "that their values are identical": = "This verbiage isn't much use, for example, if the client can always send t= he same redirect_uri. So, just to be clear, this text here doesn't in anywa= y change my previous recommendation regarding the attack previously describ= ed." 4.1.4. Access Token Response: Comment on ""token_type":"example"": "Just to= prevent any confusion it would be good to actually define the token_type "= example" in this document (Probably in section 7.1 and later in the IANA se= ction) and specify that it is reserved for use in examples where one does n= ot wish to be more specific." 4.2. Implicit Grant: Comment "I have run into multiple people (including m= yself) who have read the OAuth spec and came away completely confused about= when the heck one is supposed to use the implicit grant flow for. It's not= immediately obvious that it's a way to support standalone browser based cl= ients. Can we put in an example or something to make it more obvious why it= 's here?" 4.2.1. Authorization Request: Comment on redirect_uri: "Given that the onl= y way to identify the client in the implicit grant flow is via the redirect= _uri, how can it be optional?" 4.3. Resource Owner Password Credentials: Change "enabling the grant type, = and only when other flows" to "enabling the grant type and only use it when= other flows". 4.3. Resource Owner Password Credentials: Change "resource owner credential= s" to "resource owner's credentials". 4.3.2. Access Token Request: Comment on "authorization server MUST protect= the endpoint against brute force attacks": "Shouldn't the requirement to p= revent against brute force attacks apply to all credentials, resource owner= or otherwise? In other words in section 2.4.1 we talk about how clients su= bmit their name/password. Shouldn't endpoints accepting client name/passwor= ds have the same protections against brute force attack?" 4.4.3. Access Token Response: Comment on "A refresh token SHOULD NOT be inc= luded": "Why isn't this a MUST NOT?" 4.5. Extensions: Comment "Isn't the text in this section and 8.3 redundant = with each other? It seems like we should take the text from here and merge = it with section 8.3 so all the extension information is recorded in one pla= ce. It's just plain that all other extension points are in section 8 but t= his one." 5.1. Successful Response: Comment on "parameter at the highest structure le= vel": "Are there any guarantees about the order of the members in the JSON = object? If not we should say so explicitly." 5.2. Error Response: Comment on "multiple client authentications included" = in invalid_client: "Shouldn't this be an invalid_request?" 5.2. Error Response: Comment on "Numerical values are included as JSON numb= ers": "Same issue as before, does ordering matter and if not we need to say= that." 8.1. Defining Access Token Types: Change "or use a unique" to "or using a u= nique". 9. Native Applications: Change "an scheme" to "a scheme" 9. Native Applications: Change "offer an improved usability" to "offer im= proved usability" 9. Native Applications: Change "inability to keep credentials confidentia= l" to "inability to keep client credentials confidential". 9. Native Applications: Change "When using the implicit grant type flow a= refresh token is not returned" to "When using the implicit grant type flow= a refresh token is not returned so once the access token expires the appli= cation will have to repeat the authorization process". 10.2. Client Impersonation: Change "keep is client" to "keep its client". 10.2. Client Impersonation: Change "due to the client nature" to "due to t= he client's nature". 10.2. Client Impersonation: Change "URI used for receiving authorization" = to "URI used for receiving authorization requests" 10.2. Client Impersonation: Change "engage the resource owner" to "engagin= g the resource owner". 10.2. Client Impersonation: Change "and authorize the request" to "and aut= horize or reject the request". 10.3. Access Tokens: Change "Access token (as well as any access token type= -specific attributes)" to "Access tokens (as well as any access token type = specific attributes)". 10.3. Access Tokens: Change "guessed to produce" to "guessed so as to preve= nt unauthorized parties from producing". 10.4. Refresh Tokens: Comment "As mentioned previously we really should exp= lain why we introduced refresh tokens. Without understanding the intent of = the mechanism it's unlikely implementers will use them appropriately." 10.4. Refresh Tokens: Change "storage, and shared only among" to "storage,= and are to be shared only among". 10.4. Refresh Tokens: Change "refresh tokens rotation" to "refresh token r= otation". 10.4. Refresh Tokens: Change "guessed to produce" to "guessed so as to pre= vent unauthorized parties from producing". 10.6. Authorization Code Leakage: Comment "I fancy myself as being reasonab= ly intelligent and I'm unclear what attack is actually being described here= ." 10.6. Authorization Code Leakage: Comment on "The authorization server SHOU= LD require the client to register their redirection URI": "Why is this a sh= ould?" 10.7. Resource Owner Password Credentials: Comment on "password anti-patter= n": "Is it fair to expect that the reader knows what the password anti-patt= ern is? Shouldn't some reference to a definition of this pattern be require= d?" 10.7. Resource Owner Password Credentials: Comment on "The authorization se= rver SHOULD restrict the scope and lifetime of access tokens issued via thi= s grant type": "Restrict in what ways? Based on what criteria? This stateme= nt is the equivalent of saying "don't do bad stuff". Perhaps true but not t= erribly useful." 10.12. Cross-Site Request Forgery: Comment on first paragraph: "I challenge= any reasonably intelligent person who does not already know what a CSRF is= to read this paragraph and come away any clearer as to what is being discu= ssed. At a minimum isn't some reference to a complete definition of CSRF ne= eded if there is to be any hope of user compliance?" 10.12. Cross-Site Request Forgery: Comment on "The "state" request paramete= r MUST contain a non-guessable value": "Actually a non-guessable value won'= t stop the attack discussed in the previous paragraph on its own. What's al= so needed is a way to uniquely (and unbreakably) associate the state with a= particular user so that if an authorization code swap occurs it can be rel= iably detected." 10.13. Clickjacking: Comment on "x-frame-options": "The recommendation seem= s confused. Is it o.k. to just rely on x-frame-options or MUST other action= s be taken?" 11.1. The OAuth Access Token Type Registry: Change "toke type" to "token t= ype". 11.1.1. Registration Template: Change "protected resources requests using = access token" to "protected resource requests using access tokens". 11.1.1. Registration Template: Change "Reference to document" to "Referen= ce to the document". ________________________________ --_000_4E1F6AAD24975D4BA5B16804296739434A80B587TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1.4. Authorization Grant: Change “resource own= er authorization” to “resource owner’s authorization̶= 1;.

 

1.4.1. Authorization Code:  Comment: “It = seems odd that we can discuss the authorization code without also discussin= g the security issues it raises (e.g. passing secure information via a brow= ser) and thus motivating the introduction of the refresh token. I would expect this to be referred to here.  Havin= g read the security considerations section I can find no coherent discussio= n there either of the relationship between the authorization code and the r= efresh token and why one motivated the other. I think this is something important for implementers to understand.= ”

 

1.4.2.  Implicit:  Comment: “I find = this section confusing. I think an example is all but mandatory here if the= reader is to understand what is intended.  For example, when I first = read this section I thought it was some kind of short cut used in cases where the client and authorization server had a close relati= onship and could share information such as the client’s identity so n= o access code was needed.  No where in here is any hint that this is a= bout browser based clients who don’t have servers and who need a way to get tokens. Seriously. Try to read this section as s= omeone who knows nothing about OAuth and tell me that you get the right ide= a back from it. It needs to be written to be both explicit as to its goals = and clearer as to its means.”

 

1.4.2.  Implicit:  Change “authenticate the client and the” to “authenticate the client directly. The”.

 

1.4.2.  Implicit:  Change “weighted&= #8221; to “weighed”.

 

1.4.3.  Resource Owner Password Credentials: Co= mment on “(when combined with a refresh token)”: “This is= the first time that refresh tokens are mentioned in the spec. And yet ther= e is no explanation of what they are. I suspect they should anyway be introduced in section 1.4.1 (as previously noted) and then their= use here will make sense.  If that isn’t possible then it would= be good to have a forward reference to section 1.5 below so the reader has= some idea of what’s going on.”

 

1.4.4.  Client Credentials:  Comment on &#= 8220;(the client is also the resource owner)”: “I think this is= misleading. Imagine something like Office where a client has been granted = access to a particular resource by the resource owner. The client can then ask for an access token to the resource using the client credenti= als and no access code or refresh token. Just having the address of the int= ended resource (probably provided via SCOPE) along with the client credenti= als is more than enough to decide if an access token should be issued.

 

My point is that the client credentials scenario is = fully applicable to cases where the client is not the resource owner but in= which the resource URI provides all the context needed to determine if the= client should be able to get an access token. I think the current text would imply otherwise.

 

So I would propose changing the sentence to “C= lient credentials are used as an authorization grant when the client is act= ing on its own behalf (the client is also the resource owner) or when the a= uthorization server has enough context to determine from the access token request if the client has authorization to= access the requested resource.””

 

1.4.5. Extensions: Comment: “I would change th= is sentence to read “Additional grant types may be defined to support= new approaches to authentication/authorization as well as to provide a bri= dge between OAuth and other protocols.””

 

1.5. Refresh Token: Comment on “Refresh tokens= are credentials used to obtain access tokens.”: “This sentence= presumes that refresh tokens are self-contained credentials. In other word= s that one can get an access token just using a refresh token and nothing else. This presumption is rebutted later in the document= but I think it’s confusing to imply one thing here and state otherwi= se later on.”

 

1.5. Refresh Token: Change “= a protected resource requests” to “a p= rotected resource request”.

 

1.5. Refresh Token: Comment on “(G)  The client requests a new access token by authenticating with= the authorization server and presenting the refresh token.”: = “Hum… now the text seems to contradict itself. Above it seemed like you could use the refresh token by itself to get an access = token and I had to ask for language that made it clear that you could use a= refresh token with other credentials.  But the text of point G now im= plies the exact opposite, that refresh tokens can only be used with other credentials and not by themselves. (Eve= n though the picture in figure 2 for step G implies the opposite). I would = edit this language to say “The client requests a new access token. De= pending on the authorization server’s policies this request might be made with the refresh token by itself or wi= th a combination of the refresh token and other client credentials.”&= #8221;

 

2.1. Client Types: Comment on “user-agent-base= d application”: “Give the poor reader a hint and mention ‘= ;browser’ somewhere in the paragraph below. For example “A user= -agent-based application is a public client (such as a web browser) in which the….””

 

2.1. Client Types: web application: Change “ac= cess tokens or refresh tokens, can receive an acceptable level” to &#= 8220;access tokens or refresh tokens, can, in some cases, receive an accept= able level”.

 

2.4. Client Authentication:  Add a period after= “etc”.

 

2.4.1. Client Password: Comment on “charset=3D= UTF-8”: “The use of UTF-8 with x-www-form-urlencoded is explici= tly banned by HTML 4.01 section 17.13.1. If we want to use UTF-8 then we ha= ve to use multipart/form-data, also defined by HTML 4.01 (section 17.13.4). But since nobody would actually want to do that I would= suggest putting in a reference to section 4.2 of RFC 5552 which actually d= efines how to use UTF-8 with x-www-form-urlencoded and specifying that the = 5552 extension MUST be supported by OAuth participants.”

 

3.1.  Authorization Endpoint: Comment on first = sentence:  “There is a third option – none of the above. &= nbsp;It would be a shame if the text of this draft explicitly prohibits tha= t pattern.”

 

3.1.  Authorization Endpoint:  Comment on = “[RFC3986] section 3”: “Shouldn’t we point directly= to section 3.4 which exactly defines the query component?”

 

3.1.  Authorization Endpoint:  Comment on = “MUST be retained when adding additional query

   parameters”: “HIGH IMPORTAN= CE – This specification is incomplete. Section 3.4 of RFC 3986 simply= asserts the existence of a query component. It says nothing about the synt= ax of that component. The spec assumes that the component is using x-www-form-urlencoded but that is not in any way mandated by RFC 3986. So = there is a normative sentence missing here which states that any query para= meter on the authorization endpoint’s URI MUST be defined as specifie= d in x-www-form-urlencoded.”

 

3.1.  Authorization Endpoint:  Comment on = “The authorization server SHOULD ignore unrecognized request paramete= rs.”: “Although that is normal behavior for application protoco= ls it seems rather dangerous for a security protocol. After all what if the client put in a parameter specifying something security relate= d about the request thinking that the authorization endpoint would honor it= and then the authorization endpoint silently ignores it?  Again, this= is a security protocol, not a generic application protocol, it seems to be that unrecognized parameters should c= ause a failure.”

 

3.1.2.  Redirection Endpoint: Comment on “= ;when initiating the authorization request”: “I would suggest m= ore explicit language “or as specified in the redirection URI value i= n the authorization request.””

 

3.1.2.2. Registration Requirements: Comment on last = word “path”: “Huh? Scheme, authorization and path is a co= mplete URI minus a query component.  Is the goal to specifically manda= te that only the query component can vary and the rest of the URI MUST be static? If so that should be stated explicitly rather than= implicitly as it is now.  But I think, if that is the intent, it goes= too far. We should also allow for additional path segments to be added to = the URI path beyond the registered prefix. Assuming we can address the security problem in the next comment.”

 

3.1.2.3. Dynamic Configuration: Comment on “se= ction 6”:  “The reference to section 6 is incomplete. Sect= ion 6 defines no less than 6 different axis’s on which URI comparison= s can vary. Furthermore as recently documented in draft-thaler-iab-identifi= er-comparison-00.txt it is trivially easy to screw up URI comparisons and the security implicat= ions are pretty dire. Personally I think that the only sane approach given = the issues in the previous link is to adopt section 6.2.1 of RFC 3986.=

 

I am a bit scared of how to handle partial matches. = It’s tempting to argue that so long as the schema has an authority an= d at least one path segment then we can just use a partial string match but= boy oh boy do I see people screwing that one up royally. This is scary enough that I think I can be argued into say= ing that partial pre-registered URIs MUST only differ by the query componen= t.

 

In any case this issues needs to be explicitly calle= d out for all URI comparisons required by the spec and normatively defined.= Otherwise we will end up with all the security issues in Dave’s ID.&= #8221;

 

3.1.2.4.  Invalid Endpoint: Comment on “o= pen redirector”: “How many people even know what the heck an op= en redirector is? I think we need a section in the security considerations = section that defines what an open redirector is and why it’s bad. Alternatively a normative reference to a complete definition somewher= e else is also fine.”

 

3.2.1. Client Authentication: Change “Recovery= ” to “Recovering”.

 

3.2.1. Client Authentication: Change “credenti= als, by preventing an attacker from abusing” to “credentials. T= his prevents an attacker from abusing”

 

3.2.1. Client Authentication: Change “periodic= credentials rotation” to “periodic credentia= l rotation”.

 

3.2.1. Client Authentication: Comment on “whil= e rotation of a single set of client credentials is significantly easier= 221;: “The spec calls out rotation of credentials as being crucial bu= t then doesn’t define how this is to be done? That seems kind of odd. Shouldn’t we define an endpoint where one can submit on= e’s old but unexpired credentials for new ones? This still leaves the= edge case of what to do if the old credentials have expired and new ones h= aven’t been issued but that is unavoidable and in that case we can require out of scope action.”

 

4.1. Authorization Code: Comment on first “^&#= 8221;: “Shouldn’t this be a v character and not a ^? This would= make it consistent with A which also crosses two boxes and points in the s= ame direction.”

 

4.1. Authorization Code: Change “If valid, res= ponds back with an access token” to “If the request is valid, t= hen the authorization server will responds back with an access token and op= tionally a refresh token”.

 

4.1.2.  Authorization Response: Comment “= The language around scopes in the document is really frustrating. One only = finds out much later in the document that it is perfectly allowable for an = authorization server to more or less ignore what scopes are submitted and instead to just return whatever the hell they wan= t. This is a fine design choice but it seems like the sort of thing that sh= ould be forcefully repeated anywhere in the spec that we allow people to su= bmit scopes so nobody forgets.”

 

4.1.2.  Authorization Response: Comment on R= 20;state”: “Don’t we have to provide some guidance on how= large the state value can safely be? Otherwise we are asking clients to re= write their state mechanisms every time they throw in support for a new protected resource server. We have to set expectations across the in= dustry if we are to hope for actual interoperability.”

 

4.1.2.1. Error Response: Comment on “UTF-8 enc= oded text”: “I think just saying UTF-8 encoded text can be misl= eading. It’s not legal to put UTF-8 characters into a x-www-form-urle= ncoded used in a GET (as defined by section 17.13.1 of HTML 4.01). So what you have to do is take the UTF-8 String and then URL encode= it. Which is fine but we should call this out.  Note that this is a s= eparate issue than UTF-8 support for x-www-form-urlencoded. That issue only= applies when the form is in the request body. In this scenario the form is in a URL. There is no question that URL= s in HTTP request lists don’t support UTF-8.”

 

4.1.3. Access Token Request: Change “For example, the client makes the following HTTP using̶= 1; to “For example, if the client makes the followi= ng HTTP request using”

 

4.1.3. Access Token Request: Comment on “that = their values are identical”: “This verbiage isn’t much us= e, for example, if the client can always send the same redirect_uri. So, ju= st to be clear, this text here doesn’t in anyway change my previous recommendation regarding the attack previously described.”<= o:p>

 

4.1.4. Access Token Response: Comment on “&quo= t;token_type":"example"”: “Just to prevent any c= onfusion it would be good to actually define the token_type “example&= #8221; in this document (Probably in section 7.1 and later in the IANA sect= ion) and specify that it is reserved for use in examples where one does not wish to= be more specific.”

 

4.2.  Implicit Grant: Comment “I have run= into multiple people (including myself) who have read the OAuth spec and c= ame away completely confused about when the heck one is supposed to use the= implicit grant flow for. It’s not immediately obvious that it’s a way to support standalone browser based clients.= Can we put in an example or something to make it more obvious why it’= ;s here?”

 

4.2.1. Authorization Request: Comment on redirect_ur= i:  “Given that the only way to identify the client in the impli= cit grant flow is via the redirect_uri, how can it be optional?”=

 

4.3. Resource Owner Password Credentials: Change = 220;enabling the grant type, and only when other flows” to “enabling the grant type and only use it when other flows”.

 

4.3. Resource Owner Password Credentials: Change = 220;resource owner credentials” to “resource owner’s credentials”.

 

4.3.2. Access Token Request:  Comment on “= ;authorization server MUST protect the endpoint against brute force attacks= ”: “Shouldn’t the requirement to prevent against brute fo= rce attacks apply to all credentials, resource owner or otherwise? In other words in section 2.4.1 we talk about how clients submit their nam= e/password. Shouldn’t endpoints accepting client name/passwords have = the same protections against brute force attack?”

 

4.4.3. Access Token Response: Comment on “A re= fresh token SHOULD NOT be included”: “Why isn’t this a MU= ST NOT?”

 

4.5. Extensions: Comment “Isn’t the text= in this section and 8.3 redundant with each other? It seems like we should= take the text from here and merge it with section 8.3 so all the extension= information is recorded in one place.  It’s just plain that all other extension points are in section 8 but this one.”= ;

 

5.1. Successful Response: Comment on “paramete= r at the highest structure level”: “Are there any guarantees ab= out the order of the members in the JSON object? If not we should say so ex= plicitly.”

 

5.2. Error Response: Comment on “multiple clie= nt authentications included” in invalid_client: “Shouldn’= t this be an invalid_request?”

 

5.2. Error Response: Comment on “Numerical val= ues are included as JSON numbers”: “Same issue as before, does = ordering matter and if not we need to say that.”

 

8.1. Defining Access Token Types: Change “or use a unique” to “or = using a unique”.

 

9.  Native Applications:  Change “an= scheme” to “a scheme”

 

9.  Native Applications:  Change “offer an improved usability” to “offer improved usability”

 

9.  Native Applications:  Change “inability to keep credentials confidential” to= “inability to keep client credentials confidential= ”.

 

9.  Native Applications:  Change “Wh= en using the implicit grant type flow a refresh token is not returned”= ; to “When using the implicit grant type flow a refresh token is not = returned so once the access token expires the application will have to repeat the authorization process”.

 

10.2. Client Impersonation:  Change “keep= is client” to “keep its client”.

 

10.2. Client Impersonation:  Change “due to the client nature” to “due to the client’s nature”.

 

10.2. Client Impersonation:  Change “URI used for receiving authorization” to “= URI used for receiving authorization requests̶= 1;

 

10.2. Client Impersonation:  Change “engage the resource owner” to “engaging the resource owner”.

 

10.2. Client Impersonation:  Change “and authorize the request” to “and authorize or reject the request”.

 

10.3. Access Tokens: Change “Access token (as = well as any access token type-specific attributes)” to “Access tokens (as well as any access token type specific attribu= tes)”.

 

10.3. Access Tokens: Change “guessed to produc= e” to “guessed so as to prevent unauthorized = parties from producing”.

 

10.4. Refresh Tokens: Comment “As mentioned pr= eviously we really should explain why we introduced refresh tokens. Without= understanding the intent of the mechanism it’s unlikely implementers= will use them appropriately.”

 

10.4. Refresh Tokens:  Change “storage, a= nd shared only among” to “storage, and are to be shared only am= ong”.

 

10.4. Refresh Tokens:  Change “refresh to= kens rotation” to “refresh token rotation”.

 

10.4. Refresh Tokens:  Change “guessed to= produce” to “guessed so as to prevent unauth= orized parties from producing”.

 

10.6. Authorization Code Leakage: Comment “I f= ancy myself as being reasonably intelligent and I’m unclear what atta= ck is actually being described here.”

 

10.6. Authorization Code Leakage: Comment on “= The authorization server SHOULD require the client to register their redire= ction URI”: “Why is this a should?”

 

10.7. Resource Owner Password Credentials: Comment o= n “password anti-pattern”: “Is it fair to expect that the= reader knows what the password anti-pattern is? Shouldn’t some refer= ence to a definition of this pattern be required?”

 

10.7. Resource Owner Password Credentials: Comment o= n “The authorization server SHOULD restrict the scope and lifetime of= access tokens issued via this grant type”: “Restrict in what w= ays? Based on what criteria? This statement is the equivalent of saying “don’t do bad stuff”. Perhaps true but not ter= ribly useful.”

 

10.12. Cross-Site Request Forgery: Comment on first = paragraph: “I challenge any reasonably intelligent person who does no= t already know what a CSRF is to read this paragraph and come away any clea= rer as to what is being discussed. At a minimum isn’t some reference to a complete definition of CSRF needed= if there is to be any hope of user compliance?”

 

10.12. Cross-Site Request Forgery: Comment on “= ;The "state" request parameter MUST contain a non-guessable value= ”: “Actually a non-guessable value won’t stop the attack = discussed in the previous paragraph on its own. What’s also needed is a way to uniquely (and unbreakably) associate the state with a particular = user so that if an authorization code swap occurs it can be reliably detect= ed.”

 

10.13. Clickjacking: Comment on “x-frame-optio= ns”: “The recommendation seems confused. Is it o.k. to just rel= y on x-frame-options or MUST other actions be taken?”

 

11.1.  The OAuth Access Token Type Registry: Ch= ange “toke type” to “token type”.

 

11.1.1.  Registration Template: Change “<= span lang=3D"EN">protected resources requests using access tokenR= 21; to “protected resource requests using access to= kens”.

 

11.1.1.  Registration Template:  Change &#= 8220;Reference to document” to “Reference to the document”= ;.

 

--_000_4E1F6AAD24975D4BA5B16804296739434A80B587TK5EX14MBXC201r_-- From Michael.Jones@microsoft.com Wed Aug 10 14:38:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CF921F8ADC for ; Wed, 10 Aug 2011 14:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.439 X-Spam-Level: X-Spam-Status: No, score=-10.439 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO5rGbaVMd1L for ; Wed, 10 Aug 2011 14:38:44 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id CD3F811E8084 for ; Wed, 10 Aug 2011 14:38:43 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 10 Aug 2011 14:39:14 -0700 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.65]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0323.007; Wed, 10 Aug 2011 14:39:14 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Last call comments on bearer draft 08 from Yaron Goland Thread-Index: AcxXpeoaKSALivqaQc+VleO40TtcZQ== Date: Wed, 10 Aug 2011 21:39:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739434A80B5A3@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739434A80B5A3TK5EX14MBXC201r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Last call comments on bearer draft 08 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 21:38:47 -0000 --_000_4E1F6AAD24975D4BA5B16804296739434A80B5A3TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. Introduction: Adding the word "directly" after "rather than using the = resource owner's credentials". 1.3. Overview: Comment on first sentence: "OAuth also supports having a c= lient directly provide its own credentials to get an access token. It would= seem useful to refer to this as well less the reader think that OAuth is o= nly for delegation. That was true with OAuth 1.0 but not 2.0." 1.3. Overview, paragraph 3: Commented on "The following steps are specifie= d within this document": "Actually you also specify the token type returned= in step D. I think this is worth explicitly calling out." 2. Authenticated Requests: Commented "It would seem appropriate to begin = with an example of step D showing that the returned access token is of type= bearer." 2.3. URI Query Parameter: Commented on second example: "Does order matter?= In this case the access_token is last. Is that because it has to be or bec= ause order is irrelevant?" 2.4. The WWW-Authenticate Response Header Field: Commented on word "invalid= ": "The term invalid is a tricky one. Invalid can mean 'not supported' or '= not recognized' but that is generally taken to be a 400 Bad Request and wou= ld not require a www-authenticate response header field. Or invalid can mea= n 'supported but not the right credentials' in which case the error is a 40= 1 Unauthorized and a www-authenticate response is required. I would urge y= ou to consider simplifying this text by just stating (without preamble) tha= t if a www-authenticate response header is returned (either from a 401 Unau= thorized or other reasons) then support for the Bearer token type is specif= ied as given below." 2.4. The WWW-Authenticate Response Header Field: Commented on "param" defi= nition: "As defined in http://tools.ietf.org/html/draft-ietf-httpbis-p7-aut= h-15#section-4.4, www-authenticate is not really an error response mechanis= m. It's an advertisement mechanism. It says "here is what I support by way = of authentication." So I really don't think it's appropriate to show horn = in here error information that has nothing to do with advertising authoriza= tion capabilities. If we need to return things like error, error-desc, etc.= that should either be stuck in the body or put in a separate header. We sh= ould leave the www-authenticate header to be as simple as possible." 3.1. Security Threats: Token redirect: Change "An attacker uses the token g= enerated for consumption by resource server to obtain access to another res= ource server" to "An attacker uses the token generated for consumption by a= particular resource server with a different resource server that mistakenl= y believes the token to be for it". 3.1 Security Threads: Token replay: Change "replay" to "capture" and chang= e "An attacker attempts to use a token that has already been used with that= resource server in the past" to "An attacker somehow obtains a token they = were not authorized to possess and uses it to access protected resources". 3.2 Threat Mitigation: Add at end of first paragraph: "The mechanics of s= uch an interaction are not defined by this specification." 3.2. Threat Mitigation: Delete "and replay" from paragraph 5. 3.2. Threat Mitigation: Change "has to be" to "MUST". 3.2. Threat Mitigation: Comment on "leaked" in paragraph 5: "Significantl= y? Really? In what way? Give me a token for a few hundred milliseconds and = I can probably do all the damage I could do if you gave it to me for a few = days. I would suggest removing the term significantly." 3.3. Summary of Recommendations: Validate SSL certificate chains: Change "m= ust" to "MUST". 3.3. Summary of Recommendations: Always use TLS (https): Add "or equivalen= t transport security" after TLS reference. 3.3. Summary of Recommendations: Don't store bearer tokens in cookies: Add= sentence at end: "Implementations that do store bearer tokens in cookies M= UST take precautions against cross site request forgery." 3.3. Summary of Recommendations: Comment on "Don't pass bearer tokens in p= age URLs": "It seems like this should also be mentioned in section 3.2." Appendix A. Acknowledgements: Change "Yaron Goland" to "Yaron Y. Goland". --_000_4E1F6AAD24975D4BA5B16804296739434A80B5A3TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1.  Introduction:  Adding the word “= directly” after “rather than using the resource owner's credent= ials”.

 

1.3. Overview:  Comment on first sentence: = ; “OAuth also supports having a client directly provide its own crede= ntials to get an access token. It would seem useful to refer to this as wel= l less the reader think that OAuth is only for delegation. That was true with OAuth 1.0 but not 2.0.”

 

1.3. Overview, paragraph 3:  Commented on ̶= 0;The following steps are specified within this document”: “Act= ually you also specify the token type returned in step D. I think this is w= orth explicitly calling out.”

 

2.  Authenticated Requests:  Commented = 220;It would seem appropriate to begin with an example of step D showing th= at the returned access token is of type bearer.”

 

2.3. URI Query Parameter:  Commented on second = example: “Does order matter? In this case the access_token is last. I= s that because it has to be or because order is irrelevant?”

 

2.4. The WWW-Authenticate Response Header Field: Com= mented on word “invalid”: “The term invalid is a tricky o= ne. Invalid can mean ‘not supported’ or ‘not recognized&#= 8217; but that is generally taken to be a 400 Bad Request and would not req= uire a www-authenticate response header field. Or invalid can mean ‘suppo= rted but not the right credentials’ in which case the error is a 401 = Unauthorized and a www-authenticate response is required.  I would urg= e you to consider simplifying this text by just stating (without preamble) that if a www-authenticate response header is returned = (either from a 401 Unauthorized or other reasons) then support for the Bear= er token type is specified as given below.”

 

2.4. The WWW-Authenticate Response Header Field:&nbs= p; Commented on “param” definition: “As defined in http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-15#section-4.4<= /a>, www-authenticate is not really an error response mechanism. It’s= an advertisement mechanism. It says “here is what I support by way of authentication.”  So I really don&#= 8217;t think it’s appropriate to show horn in here error information = that has nothing to do with advertising authorization capabilities. If we n= eed to return things like error, error-desc, etc. that should either be stuck in the body or put in a separate header. We should = leave the www-authenticate header to be as simple as possible.”<= /o:p>

 

3.1. Security Threats: Token redirect: Change “= ;An attacker uses the token generated for consumption by resource server to= obtain access to another resource server” to “An attacker uses= the token generated for consumption by a particular resource server with a different resource server that mistakenly believes = the token to be for it”.

 

3.1 Security Threads: Token replay:  Change = 220;replay” to “capture” and change “An attacker at= tempts to use a token that has already been used with that resource server = in the past” to “An attacker somehow obtains a token they were = not authorized to possess and uses it to access protected resources”.

 

3.2 Threat Mitigation:  Add at end of first par= agraph:  “The mechanics of such an interaction are not defined b= y this specification.”

 

3.2. Threat Mitigation:  Delete “and repl= ay” from paragraph 5.

 

3.2. Threat Mitigation:  Change “has to b= e” to “MUST”.

 

3.2. Threat Mitigation:  Comment on “leak= ed” in paragraph 5:  “Significantly? Really? In what way? = Give me a token for a few hundred milliseconds and I can probably do all th= e damage I could do if you gave it to me for a few days.  I would suggest removing the term significantly.”

 

3.3. Summary of Recommendations: Validate SSL certif= icate chains: Change “must” to “MUST”.

 

3.3. Summary of Recommendations: Always use TLS (htt= ps):  Add “or equivalent transport security” after TLS ref= erence.

 

3.3. Summary of Recommendations: Don't store bearer = tokens in cookies:  Add sentence at end: “Implementations that d= o store bearer tokens in cookies MUST take precautions against cross site r= equest forgery.”

 

3.3. Summary of Recommendations:  Comment on &#= 8220;Don't pass bearer tokens in page URLs”: “It seems like thi= s should also be mentioned in section 3.2.”

 

Appendix A.  Acknowledgements:  Change = 220;Yaron Goland” to “Yaron Y. Goland”.

 

--_000_4E1F6AAD24975D4BA5B16804296739434A80B5A3TK5EX14MBXC201r_-- From Michael.Jones@microsoft.com Wed Aug 10 14:39:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6778911E80AA for ; Wed, 10 Aug 2011 14:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.445 X-Spam-Level: X-Spam-Status: No, score=-10.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbHwLb+2UpG5 for ; Wed, 10 Aug 2011 14:39:27 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id E754611E8094 for ; Wed, 10 Aug 2011 14:39:26 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 10 Aug 2011 14:39:59 -0700 Received: from TK5EX14MBXC201.redmond.corp.microsoft.com ([169.254.8.65]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0323.007; Wed, 10 Aug 2011 14:39:59 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Comments on Assertions draft 00 by Yaron Goland Thread-Index: AcxXpfuhAGBqMyEFSg+Pg2ZI+qDJdg== Date: Wed, 10 Aug 2011 21:39:58 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739434A80B5D4@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739434A80B5D4TK5EX14MBXC201r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Comments on Assertions draft 00 by Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 21:39:29 -0000 --_000_4E1F6AAD24975D4BA5B16804296739434A80B5D4TK5EX14MBXC201r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Author List: Change "MSFT" to "Microsoft" (twice). Author List: Change "Yaron Goland" to "Yaron Y. Goland". 2. Overview: Change "privliged" to "privileged". 2. Overview: Change "messsage" to "message". 3. Authentication vs. Authorization: Add a period after "vs" so the title= becomes "Authentication vs. Authorization" 3. Authentication vs. Authorization: Comment on words "single assertion":= "This sentence implies that a system could issue two tokens, one for auth= entication and a separate one for authorization. While this is certainly po= ssible does anyone actually do that? If not then perhaps it's not worth cal= ling out?" 4.1. Using Assertions for Client Authentication: Comment on "client_id": = "It seems like a bad idea to have the client_id outside of the assertion. I= t's either redundant or insecure." 4.1. Using Assertions for Client Authentication: Change "a Authorization C= ode" to "an Authorization Code". 4.2. Using Assertions as Authorization Grants: Delete ", without direct us= er approval", per comment "This fragment sounds slimy and isn't all that re= levant so I would suggest omitting it." 4.2. Using Assertions as Authorization Grants: Comment on "client_id": "T= his seems like a bug. Why is there a client_id? In any scenario I can come = up with that would use an assertion all data needed to identifying the call= er is provided (securely) in the assertion itself. So at best requiring cli= ent_id is just redundant and redundancy in protocols just opens up new plac= es to have problems. So I would suggest that we require that assertions MU= ST identify the client and therefore the requests MUST NOT include client_i= d." 5. In title, change "Proccessing" to "Processing". 5.1. Assertion Metamodel: Audience: Change "the Authorization Server as t= he intended audience" to "the party intended to process the token", per the= comment "It's generally not considered good form to write a definition tha= t contains the word being defined.". 5.2. General Assertion Format and Processing Rules: Change "a Assertion ID= " to "an Assertion ID" and change "algortihm" to "algorithm" and change "ge= nerate assertion" to "generate the assertion". 6.1. Client authentication: Change "as in a format" to "in a format". 6.1. Client authentication: Comment on last 4 bullets: "This is all redun= dant with section 5.2. I think it's not a great idea to repeat normative re= quirements as it just opens the door for confusion and inconsistency. So I = would urge that we remove these lines and just point to section 5.2." 6.1. Client authentication: Change "a client authenticating" to "a client = authentication" and change "a Authorization Code" to "an Authorization Code= ". 6.2. Client acting on behalf of itself: Change "analagous" to "analogous". 6.2. Client acting on behalf of itself: Comment on last 4 bullets: "Again= , I would just point to section 5.2." 6.3. Client acting on behalf of a user: Comment on last 4 bullets: "Same = comment as before". 6.3. Client acting on behalf of a user: Change "a Authorization Code" to "= an Authorization Code". 6.4. Client acting on behalf of an anonymous user: Change "authorizaion" to= "authorization". 7. Error Responses: Comment on "Audience validation failed": "Isn't retur= ning this kind of information just helping an attacker to hone their attack= by trying various values and seeing what errors they get? I'm not sure how= serious this threat is though. But I get nervous any time we leak data abo= ut security validation failures." --_000_4E1F6AAD24975D4BA5B16804296739434A80B5D4TK5EX14MBXC201r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Author List:  Change “MSFT” to R= 20;Microsoft” (twice).

 

Author List:  Change “Yaron Goland”= to “Yaron Y. Goland”.

 

2.  Overview:  Change &#= 8220;privliged” to “privileged”.

 

2.  Overview:  Change &#= 8220;messsage” to “message”.

 

3.  Authentication vs. Author= ization:  Add a period after “vs” so the title becomes = 220;Authentication vs. Authorization”

 

3.  Authentication vs. Author= ization:  Comment on words “single assertion”:  ̶= 0;This sentence implies that a system could issue two tokens, one fo= r authentication and a separate one for authorization. While this is certainly possible does anyone actually do that? If not then perhaps it= 217;s not worth calling out?”

 

4.1. Using Assertions for Client Authentication:&nbs= p; Comment on “client_id”:  “It seems like a bad ide= a to have the client_id outside of the assertion. It’s either redunda= nt or insecure.”

 

4.1. Using Assertions for Client Authentication:&nbs= p; Change “a Authorization Code” to “an Authorization Cod= e”.

 

4.2. Using Assertions as Authorization Grants: = Delete “, without direct user approval”, per comment “Th= is fragment sounds slimy and isn’t all that relevant so I would sugge= st omitting it.”

 

4.2. Using Assertions as Authorization Grants: = Comment on “client_id”:  “This seems like a bug. Wh= y is there a client_id? In any scenario I can come up with that would use a= n assertion all data needed to identifying the caller is provided (securely) in the assertion itself. So at best requiring client_id is just= redundant and redundancy in protocols just opens up new places to have pro= blems.  So I would suggest that we require that assertions MUST identi= fy the client and therefore the requests MUST NOT include client_id.”

 

5.  In title, change “Proccessing” = to “Processing”.

 

5.1. Assertion Metamodel:  Audience:  Chan= ge “the Authorization Server as the intended audience” to ̶= 0;the party intended to process the token”, per the comment “It= ’s generally not considered good form to write a definition that cont= ains the word being defined.”.

 

5.2. General Assertion Format and Processing Rules:&= nbsp; Change “a Assertion ID” to “an Assertion ID” = and change “algortihm" to “algorithm” and change = 220;generate assertion” to “generate the assertion”.=

 

6.1. Client authentication:  Change “as i= n a format” to “in a format”.

 

6.1. Client authentication:  Comment on last 4 = bullets:  “This is all redundant with section 5.2. I think it= 217;s not a great idea to repeat normative requirements as it just opens th= e door for confusion and inconsistency. So I would urge that we remove these lines and just point to section 5.2.”

 

6.1. Client authentication:  Change “a cl= ient authenticating” to “a client authentication” and cha= nge “a Authorization Code” to “an Authorization Code̶= 1;.

 

6.2. Client acting on behalf of itself:  Change= “analagous” to “analogous”.

 

6.2. Client acting on behalf of itself:  Commen= t on last 4 bullets:  “Again, I would just point to section 5.2.= ”

 

6.3. Client acting on behalf of a user:  Commen= t on last 4 bullets:  “Same comment as before”.=

 

6.3. Client acting on behalf of a user:  Change= “a Authorization Code” to “an Authorization Code”.=

 

6.4. Client acting on behalf of an anonymous user: C= hange “authorizaion” to “authorization”.=

 

7.  Error Responses:  Comment on “Au= dience validation failed”: “Isn’t returning this kind of = information just helping an attacker to hone their attack by trying various= values and seeing what errors they get? I’m not sure how serious thi= s threat is though. But I get nervous any time we leak data about security v= alidation failures.”

 

--_000_4E1F6AAD24975D4BA5B16804296739434A80B5D4TK5EX14MBXC201r_-- From eran@hueniverse.com Wed Aug 10 17:18:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059A111E8094 for ; Wed, 10 Aug 2011 17:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1fXWfpDib3m for ; Wed, 10 Aug 2011 17:18:23 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 4EC5F21F8B0B for ; Wed, 10 Aug 2011 17:18:23 -0700 (PDT) Received: (qmail 1684 invoked from network); 11 Aug 2011 00:18:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 00:18:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 10 Aug 2011 17:18:46 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Wed, 10 Aug 2011 17:18:40 -0700 Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland Thread-Index: AcxXvDxJ2RVrp+pDQEu5SQ4PYgMmSQ== Message-ID: <356C947C-E0E9-4AC4-9D48-36370B40763B@hueniverse.com> References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_356C947CE0E94AC49D4836370B40763Bhueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 00:18:26 -0000 --_000_356C947CE0E94AC49D4836370B40763Bhueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXMgdGhlcmUgYSByZWFzb24gd2h5IE1yIEdvbGFuZCBpc250IHNlbmRpbmcgaGlzIG93biBjb21t ZW50cyBpbj8NCg0KT24gQXVnIDEwLCAyMDExLCBhdCAxNzozOSwgIk1pa2UgSm9uZXMiIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bT4+IHdyb3RlOg0KDQoxLjQuIEF1dGhvcml6YXRpb24gR3JhbnQ6IENoYW5nZSDigJxyZXNvdXJj ZSBvd25lciBhdXRob3JpemF0aW9u4oCdIHRvIOKAnHJlc291cmNlIG93bmVy4oCZcyBhdXRob3Jp emF0aW9u4oCdLg0KDQoxLjQuMS4gQXV0aG9yaXphdGlvbiBDb2RlOiAgQ29tbWVudDog4oCcSXQg c2VlbXMgb2RkIHRoYXQgd2UgY2FuIGRpc2N1c3MgdGhlIGF1dGhvcml6YXRpb24gY29kZSB3aXRo b3V0IGFsc28gZGlzY3Vzc2luZyB0aGUgc2VjdXJpdHkgaXNzdWVzIGl0IHJhaXNlcyAoZS5nLiBw YXNzaW5nIHNlY3VyZSBpbmZvcm1hdGlvbiB2aWEgYSBicm93c2VyKSBhbmQgdGh1cyBtb3RpdmF0 aW5nIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIHJlZnJlc2ggdG9rZW4uIEkgd291bGQgZXhwZWN0 IHRoaXMgdG8gYmUgcmVmZXJyZWQgdG8gaGVyZS4gIEhhdmluZyByZWFkIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBzZWN0aW9uIEkgY2FuIGZpbmQgbm8gY29oZXJlbnQgZGlzY3Vzc2lvbiB0 aGVyZSBlaXRoZXIgb2YgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBhdXRob3JpemF0aW9u IGNvZGUgYW5kIHRoZSByZWZyZXNoIHRva2VuIGFuZCB3aHkgb25lIG1vdGl2YXRlZCB0aGUgb3Ro ZXIuIEkgdGhpbmsgdGhpcyBpcyBzb21ldGhpbmcgaW1wb3J0YW50IGZvciBpbXBsZW1lbnRlcnMg dG8gdW5kZXJzdGFuZC7igJ0NCg0KMS40LjIuICBJbXBsaWNpdDogIENvbW1lbnQ6IOKAnEkgZmlu ZCB0aGlzIHNlY3Rpb24gY29uZnVzaW5nLiBJIHRoaW5rIGFuIGV4YW1wbGUgaXMgYWxsIGJ1dCBt YW5kYXRvcnkgaGVyZSBpZiB0aGUgcmVhZGVyIGlzIHRvIHVuZGVyc3RhbmQgd2hhdCBpcyBpbnRl bmRlZC4gIEZvciBleGFtcGxlLCB3aGVuIEkgZmlyc3QgcmVhZCB0aGlzIHNlY3Rpb24gSSB0aG91 Z2h0IGl0IHdhcyBzb21lIGtpbmQgb2Ygc2hvcnQgY3V0IHVzZWQgaW4gY2FzZXMgd2hlcmUgdGhl IGNsaWVudCBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaGFkIGEgY2xvc2UgcmVsYXRpb25zaGlw IGFuZCBjb3VsZCBzaGFyZSBpbmZvcm1hdGlvbiBzdWNoIGFzIHRoZSBjbGllbnTigJlzIGlkZW50 aXR5IHNvIG5vIGFjY2VzcyBjb2RlIHdhcyBuZWVkZWQuICBObyB3aGVyZSBpbiBoZXJlIGlzIGFu eSBoaW50IHRoYXQgdGhpcyBpcyBhYm91dCBicm93c2VyIGJhc2VkIGNsaWVudHMgd2hvIGRvbuKA mXQgaGF2ZSBzZXJ2ZXJzIGFuZCB3aG8gbmVlZCBhIHdheSB0byBnZXQgdG9rZW5zLiBTZXJpb3Vz bHkuIFRyeSB0byByZWFkIHRoaXMgc2VjdGlvbiBhcyBzb21lb25lIHdobyBrbm93cyBub3RoaW5n IGFib3V0IE9BdXRoIGFuZCB0ZWxsIG1lIHRoYXQgeW91IGdldCB0aGUgcmlnaHQgaWRlYSBiYWNr IGZyb20gaXQuIEl0IG5lZWRzIHRvIGJlIHdyaXR0ZW4gdG8gYmUgYm90aCBleHBsaWNpdCBhcyB0 byBpdHMgZ29hbHMgYW5kIGNsZWFyZXIgYXMgdG8gaXRzIG1lYW5zLuKAnQ0KDQoxLjQuMi4gIElt cGxpY2l0OiAgQ2hhbmdlIOKAnGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGFuZCB0aGXigJ0gdG8g 4oCcYXV0aGVudGljYXRlIHRoZSBjbGllbnQgZGlyZWN0bHkuIFRoZeKAnS4NCg0KMS40LjIuICBJ bXBsaWNpdDogIENoYW5nZSDigJx3ZWlnaHRlZOKAnSB0byDigJx3ZWlnaGVk4oCdLg0KDQoxLjQu My4gIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzOiBDb21tZW50IG9uIOKAnCh3 aGVuIGNvbWJpbmVkIHdpdGggYSByZWZyZXNoIHRva2VuKeKAnTog4oCcVGhpcyBpcyB0aGUgZmly c3QgdGltZSB0aGF0IHJlZnJlc2ggdG9rZW5zIGFyZSBtZW50aW9uZWQgaW4gdGhlIHNwZWMuIEFu ZCB5ZXQgdGhlcmUgaXMgbm8gZXhwbGFuYXRpb24gb2Ygd2hhdCB0aGV5IGFyZS4gSSBzdXNwZWN0 IHRoZXkgc2hvdWxkIGFueXdheSBiZSBpbnRyb2R1Y2VkIGluIHNlY3Rpb24gMS40LjEgKGFzIHBy ZXZpb3VzbHkgbm90ZWQpIGFuZCB0aGVuIHRoZWlyIHVzZSBoZXJlIHdpbGwgbWFrZSBzZW5zZS4g IElmIHRoYXQgaXNu4oCZdCBwb3NzaWJsZSB0aGVuIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBh IGZvcndhcmQgcmVmZXJlbmNlIHRvIHNlY3Rpb24gMS41IGJlbG93IHNvIHRoZSByZWFkZXIgaGFz IHNvbWUgaWRlYSBvZiB3aGF04oCZcyBnb2luZyBvbi7igJ0NCg0KMS40LjQuICBDbGllbnQgQ3Jl ZGVudGlhbHM6ICBDb21tZW50IG9uIOKAnCh0aGUgY2xpZW50IGlzIGFsc28gdGhlIHJlc291cmNl IG93bmVyKeKAnTog4oCcSSB0aGluayB0aGlzIGlzIG1pc2xlYWRpbmcuIEltYWdpbmUgc29tZXRo aW5nIGxpa2UgT2ZmaWNlIHdoZXJlIGEgY2xpZW50IGhhcyBiZWVuIGdyYW50ZWQgYWNjZXNzIHRv IGEgcGFydGljdWxhciByZXNvdXJjZSBieSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZSBjbGllbnQg Y2FuIHRoZW4gYXNrIGZvciBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIHJlc291cmNlIHVzaW5nIHRo ZSBjbGllbnQgY3JlZGVudGlhbHMgYW5kIG5vIGFjY2VzcyBjb2RlIG9yIHJlZnJlc2ggdG9rZW4u IEp1c3QgaGF2aW5nIHRoZSBhZGRyZXNzIG9mIHRoZSBpbnRlbmRlZCByZXNvdXJjZSAocHJvYmFi bHkgcHJvdmlkZWQgdmlhIFNDT1BFKSBhbG9uZyB3aXRoIHRoZSBjbGllbnQgY3JlZGVudGlhbHMg aXMgbW9yZSB0aGFuIGVub3VnaCB0byBkZWNpZGUgaWYgYW4gYWNjZXNzIHRva2VuIHNob3VsZCBi ZSBpc3N1ZWQuDQoNCk15IHBvaW50IGlzIHRoYXQgdGhlIGNsaWVudCBjcmVkZW50aWFscyBzY2Vu YXJpbyBpcyBmdWxseSBhcHBsaWNhYmxlIHRvIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQgaXMgbm90 IHRoZSByZXNvdXJjZSBvd25lciBidXQgaW4gd2hpY2ggdGhlIHJlc291cmNlIFVSSSBwcm92aWRl cyBhbGwgdGhlIGNvbnRleHQgbmVlZGVkIHRvIGRldGVybWluZSBpZiB0aGUgY2xpZW50IHNob3Vs ZCBiZSBhYmxlIHRvIGdldCBhbiBhY2Nlc3MgdG9rZW4uIEkgdGhpbmsgdGhlIGN1cnJlbnQgdGV4 dCB3b3VsZCBpbXBseSBvdGhlcndpc2UuDQoNClNvIEkgd291bGQgcHJvcG9zZSBjaGFuZ2luZyB0 aGUgc2VudGVuY2UgdG8g4oCcQ2xpZW50IGNyZWRlbnRpYWxzIGFyZSB1c2VkIGFzIGFuIGF1dGhv cml6YXRpb24gZ3JhbnQgd2hlbiB0aGUgY2xpZW50IGlzIGFjdGluZyBvbiBpdHMgb3duIGJlaGFs ZiAodGhlIGNsaWVudCBpcyBhbHNvIHRoZSByZXNvdXJjZSBvd25lcikgb3Igd2hlbiB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgaGFzIGVub3VnaCBjb250ZXh0IHRvIGRldGVybWluZSBmcm9tIHRo ZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpZiB0aGUgY2xpZW50IGhhcyBhdXRob3JpemF0aW9uIHRv IGFjY2VzcyB0aGUgcmVxdWVzdGVkIHJlc291cmNlLuKAneKAnQ0KDQoxLjQuNS4gRXh0ZW5zaW9u czogQ29tbWVudDog4oCcSSB3b3VsZCBjaGFuZ2UgdGhpcyBzZW50ZW5jZSB0byByZWFkIOKAnEFk ZGl0aW9uYWwgZ3JhbnQgdHlwZXMgbWF5IGJlIGRlZmluZWQgdG8gc3VwcG9ydCBuZXcgYXBwcm9h Y2hlcyB0byBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIGFzIHdlbGwgYXMgdG8gcHJvdmlk ZSBhIGJyaWRnZSBiZXR3ZWVuIE9BdXRoIGFuZCBvdGhlciBwcm90b2NvbHMu4oCd4oCdDQoNCjEu NS4gUmVmcmVzaCBUb2tlbjogQ29tbWVudCBvbiDigJxSZWZyZXNoIHRva2VucyBhcmUgY3JlZGVu dGlhbHMgdXNlZCB0byBvYnRhaW4gYWNjZXNzIHRva2Vucy7igJ06IOKAnFRoaXMgc2VudGVuY2Ug cHJlc3VtZXMgdGhhdCByZWZyZXNoIHRva2VucyBhcmUgc2VsZi1jb250YWluZWQgY3JlZGVudGlh bHMuIEluIG90aGVyIHdvcmRzIHRoYXQgb25lIGNhbiBnZXQgYW4gYWNjZXNzIHRva2VuIGp1c3Qg dXNpbmcgYSByZWZyZXNoIHRva2VuIGFuZCBub3RoaW5nIGVsc2UuIFRoaXMgcHJlc3VtcHRpb24g aXMgcmVidXR0ZWQgbGF0ZXIgaW4gdGhlIGRvY3VtZW50IGJ1dCBJIHRoaW5rIGl04oCZcyBjb25m dXNpbmcgdG8gaW1wbHkgb25lIHRoaW5nIGhlcmUgYW5kIHN0YXRlIG90aGVyd2lzZSBsYXRlciBv bi7igJ0NCg0KMS41LiBSZWZyZXNoIFRva2VuOiBDaGFuZ2Ug4oCcYSBwcm90ZWN0ZWQgcmVzb3Vy Y2UgcmVxdWVzdHPigJ0gdG8g4oCcYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdOKAnS4NCg0K MS41LiBSZWZyZXNoIFRva2VuOiBDb21tZW50IG9uIOKAnChHKSAgVGhlIGNsaWVudCByZXF1ZXN0 cyBhIG5ldyBhY2Nlc3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgYW5kIHByZXNlbnRpbmcgdGhlIHJlZnJlc2ggdG9rZW4u4oCdOiDigJxIdW3i gKYgbm93IHRoZSB0ZXh0IHNlZW1zIHRvIGNvbnRyYWRpY3QgaXRzZWxmLiBBYm92ZSBpdCBzZWVt ZWQgbGlrZSB5b3UgY291bGQgdXNlIHRoZSByZWZyZXNoIHRva2VuIGJ5IGl0c2VsZiB0byBnZXQg YW4gYWNjZXNzIHRva2VuIGFuZCBJIGhhZCB0byBhc2sgZm9yIGxhbmd1YWdlIHRoYXQgbWFkZSBp dCBjbGVhciB0aGF0IHlvdSBjb3VsZCB1c2UgYSByZWZyZXNoIHRva2VuIHdpdGggb3RoZXIgY3Jl ZGVudGlhbHMuICBCdXQgdGhlIHRleHQgb2YgcG9pbnQgRyBub3cgaW1wbGllcyB0aGUgZXhhY3Qg b3Bwb3NpdGUsIHRoYXQgcmVmcmVzaCB0b2tlbnMgY2FuIG9ubHkgYmUgdXNlZCB3aXRoIG90aGVy IGNyZWRlbnRpYWxzIGFuZCBub3QgYnkgdGhlbXNlbHZlcy4gKEV2ZW4gdGhvdWdoIHRoZSBwaWN0 dXJlIGluIGZpZ3VyZSAyIGZvciBzdGVwIEcgaW1wbGllcyB0aGUgb3Bwb3NpdGUpLiBJIHdvdWxk IGVkaXQgdGhpcyBsYW5ndWFnZSB0byBzYXkg4oCcVGhlIGNsaWVudCByZXF1ZXN0cyBhIG5ldyBh Y2Nlc3MgdG9rZW4uIERlcGVuZGluZyBvbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJlzIHBv bGljaWVzIHRoaXMgcmVxdWVzdCBtaWdodCBiZSBtYWRlIHdpdGggdGhlIHJlZnJlc2ggdG9rZW4g YnkgaXRzZWxmIG9yIHdpdGggYSBjb21iaW5hdGlvbiBvZiB0aGUgcmVmcmVzaCB0b2tlbiBhbmQg b3RoZXIgY2xpZW50IGNyZWRlbnRpYWxzLuKAneKAnQ0KDQoyLjEuIENsaWVudCBUeXBlczogQ29t bWVudCBvbiDigJx1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9u4oCdOiDigJxHaXZlIHRoZSBw b29yIHJlYWRlciBhIGhpbnQgYW5kIG1lbnRpb24g4oCYYnJvd3NlcuKAmSBzb21ld2hlcmUgaW4g dGhlIHBhcmFncmFwaCBiZWxvdy4gRm9yIGV4YW1wbGUg4oCcQSB1c2VyLWFnZW50LWJhc2VkIGFw cGxpY2F0aW9uIGlzIGEgcHVibGljIGNsaWVudCAoc3VjaCBhcyBhIHdlYiBicm93c2VyKSBpbiB3 aGljaCB0aGXigKYu4oCd4oCdDQoNCjIuMS4gQ2xpZW50IFR5cGVzOiB3ZWIgYXBwbGljYXRpb246 IENoYW5nZSDigJxhY2Nlc3MgdG9rZW5zIG9yIHJlZnJlc2ggdG9rZW5zLCBjYW4gcmVjZWl2ZSBh biBhY2NlcHRhYmxlIGxldmVs4oCdIHRvIOKAnGFjY2VzcyB0b2tlbnMgb3IgcmVmcmVzaCB0b2tl bnMsIGNhbiwgaW4gc29tZSBjYXNlcywgcmVjZWl2ZSBhbiBhY2NlcHRhYmxlIGxldmVs4oCdLg0K DQoyLjQuIENsaWVudCBBdXRoZW50aWNhdGlvbjogIEFkZCBhIHBlcmlvZCBhZnRlciDigJxldGPi gJ0uDQoNCjIuNC4xLiBDbGllbnQgUGFzc3dvcmQ6IENvbW1lbnQgb24g4oCcY2hhcnNldD1VVEYt OOKAnTog4oCcVGhlIHVzZSBvZiBVVEYtOCB3aXRoIHgtd3d3LWZvcm0tdXJsZW5jb2RlZCBpcyBl eHBsaWNpdGx5IGJhbm5lZCBieSBIVE1MIDQuMDEgc2VjdGlvbiAxNy4xMy4xLiBJZiB3ZSB3YW50 IHRvIHVzZSBVVEYtOCB0aGVuIHdlIGhhdmUgdG8gdXNlIG11bHRpcGFydC9mb3JtLWRhdGEsIGFs c28gZGVmaW5lZCBieSBIVE1MIDQuMDEgKHNlY3Rpb24gMTcuMTMuNCkuIEJ1dCBzaW5jZSBub2Jv ZHkgd291bGQgYWN0dWFsbHkgd2FudCB0byBkbyB0aGF0IEkgd291bGQgc3VnZ2VzdCBwdXR0aW5n IGluIGEgcmVmZXJlbmNlIHRvIHNlY3Rpb24gNC4yIG9mIFJGQyA1NTUyIHdoaWNoIGFjdHVhbGx5 IGRlZmluZXMgaG93IHRvIHVzZSBVVEYtOCB3aXRoIHgtd3d3LWZvcm0tdXJsZW5jb2RlZCBhbmQg c3BlY2lmeWluZyB0aGF0IHRoZSA1NTUyIGV4dGVuc2lvbiBNVVNUIGJlIHN1cHBvcnRlZCBieSBP QXV0aCBwYXJ0aWNpcGFudHMu4oCdDQoNCjMuMS4gIEF1dGhvcml6YXRpb24gRW5kcG9pbnQ6IENv bW1lbnQgb24gZmlyc3Qgc2VudGVuY2U6ICDigJxUaGVyZSBpcyBhIHRoaXJkIG9wdGlvbiDigJMg bm9uZSBvZiB0aGUgYWJvdmUuICBJdCB3b3VsZCBiZSBhIHNoYW1lIGlmIHRoZSB0ZXh0IG9mIHRo aXMgZHJhZnQgZXhwbGljaXRseSBwcm9oaWJpdHMgdGhhdCBwYXR0ZXJuLuKAnQ0KDQozLjEuICBB dXRob3JpemF0aW9uIEVuZHBvaW50OiAgQ29tbWVudCBvbiDigJxbUkZDMzk4Nl0gc2VjdGlvbiAz 4oCdOiDigJxTaG91bGRu4oCZdCB3ZSBwb2ludCBkaXJlY3RseSB0byBzZWN0aW9uIDMuNCB3aGlj aCBleGFjdGx5IGRlZmluZXMgdGhlIHF1ZXJ5IGNvbXBvbmVudD/igJ0NCg0KMy4xLiAgQXV0aG9y aXphdGlvbiBFbmRwb2ludDogIENvbW1lbnQgb24g4oCcTVVTVCBiZSByZXRhaW5lZCB3aGVuIGFk ZGluZyBhZGRpdGlvbmFsIHF1ZXJ5DQogICBwYXJhbWV0ZXJz4oCdOiDigJxISUdIIElNUE9SVEFO Q0Ug4oCTIFRoaXMgc3BlY2lmaWNhdGlvbiBpcyBpbmNvbXBsZXRlLiBTZWN0aW9uIDMuNCBvZiBS RkMgMzk4NiBzaW1wbHkgYXNzZXJ0cyB0aGUgZXhpc3RlbmNlIG9mIGEgcXVlcnkgY29tcG9uZW50 LiBJdCBzYXlzIG5vdGhpbmcgYWJvdXQgdGhlIHN5bnRheCBvZiB0aGF0IGNvbXBvbmVudC4gVGhl IHNwZWMgYXNzdW1lcyB0aGF0IHRoZSBjb21wb25lbnQgaXMgdXNpbmcgeC13d3ctZm9ybS11cmxl bmNvZGVkIGJ1dCB0aGF0IGlzIG5vdCBpbiBhbnkgd2F5IG1hbmRhdGVkIGJ5IFJGQyAzOTg2LiBT byB0aGVyZSBpcyBhIG5vcm1hdGl2ZSBzZW50ZW5jZSBtaXNzaW5nIGhlcmUgd2hpY2ggc3RhdGVz IHRoYXQgYW55IHF1ZXJ5IHBhcmFtZXRlciBvbiB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludOKA mXMgVVJJIE1VU1QgYmUgZGVmaW5lZCBhcyBzcGVjaWZpZWQgaW4geC13d3ctZm9ybS11cmxlbmNv ZGVkLuKAnQ0KDQozLjEuICBBdXRob3JpemF0aW9uIEVuZHBvaW50OiAgQ29tbWVudCBvbiDigJxU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGlnbm9yZSB1bnJlY29nbml6ZWQgcmVxdWVz dCBwYXJhbWV0ZXJzLuKAnTog4oCcQWx0aG91Z2ggdGhhdCBpcyBub3JtYWwgYmVoYXZpb3IgZm9y IGFwcGxpY2F0aW9uIHByb3RvY29scyBpdCBzZWVtcyByYXRoZXIgZGFuZ2Vyb3VzIGZvciBhIHNl Y3VyaXR5IHByb3RvY29sLiBBZnRlciBhbGwgd2hhdCBpZiB0aGUgY2xpZW50IHB1dCBpbiBhIHBh cmFtZXRlciBzcGVjaWZ5aW5nIHNvbWV0aGluZyBzZWN1cml0eSByZWxhdGVkIGFib3V0IHRoZSBy ZXF1ZXN0IHRoaW5raW5nIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgd291bGQgaG9u b3IgaXQgYW5kIHRoZW4gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgc2lsZW50bHkgaWdub3Jl cyBpdD8gIEFnYWluLCB0aGlzIGlzIGEgc2VjdXJpdHkgcHJvdG9jb2wsIG5vdCBhIGdlbmVyaWMg YXBwbGljYXRpb24gcHJvdG9jb2wsIGl0IHNlZW1zIHRvIGJlIHRoYXQgdW5yZWNvZ25pemVkIHBh cmFtZXRlcnMgc2hvdWxkIGNhdXNlIGEgZmFpbHVyZS7igJ0NCg0KMy4xLjIuICBSZWRpcmVjdGlv biBFbmRwb2ludDogQ29tbWVudCBvbiDigJx3aGVuIGluaXRpYXRpbmcgdGhlIGF1dGhvcml6YXRp b24gcmVxdWVzdOKAnTog4oCcSSB3b3VsZCBzdWdnZXN0IG1vcmUgZXhwbGljaXQgbGFuZ3VhZ2Ug 4oCcb3IgYXMgc3BlY2lmaWVkIGluIHRoZSByZWRpcmVjdGlvbiBVUkkgdmFsdWUgaW4gdGhlIGF1 dGhvcml6YXRpb24gcmVxdWVzdC7igJ3igJ0NCg0KMy4xLjIuMi4gUmVnaXN0cmF0aW9uIFJlcXVp cmVtZW50czogQ29tbWVudCBvbiBsYXN0IHdvcmQg4oCccGF0aOKAnTog4oCcSHVoPyBTY2hlbWUs IGF1dGhvcml6YXRpb24gYW5kIHBhdGggaXMgYSBjb21wbGV0ZSBVUkkgbWludXMgYSBxdWVyeSBj b21wb25lbnQuICBJcyB0aGUgZ29hbCB0byBzcGVjaWZpY2FsbHkgbWFuZGF0ZSB0aGF0IG9ubHkg dGhlIHF1ZXJ5IGNvbXBvbmVudCBjYW4gdmFyeSBhbmQgdGhlIHJlc3Qgb2YgdGhlIFVSSSBNVVNU IGJlIHN0YXRpYz8gSWYgc28gdGhhdCBzaG91bGQgYmUgc3RhdGVkIGV4cGxpY2l0bHkgcmF0aGVy IHRoYW4gaW1wbGljaXRseSBhcyBpdCBpcyBub3cuICBCdXQgSSB0aGluaywgaWYgdGhhdCBpcyB0 aGUgaW50ZW50LCBpdCBnb2VzIHRvbyBmYXIuIFdlIHNob3VsZCBhbHNvIGFsbG93IGZvciBhZGRp dGlvbmFsIHBhdGggc2VnbWVudHMgdG8gYmUgYWRkZWQgdG8gdGhlIFVSSSBwYXRoIGJleW9uZCB0 aGUgcmVnaXN0ZXJlZCBwcmVmaXguIEFzc3VtaW5nIHdlIGNhbiBhZGRyZXNzIHRoZSBzZWN1cml0 eSBwcm9ibGVtIGluIHRoZSBuZXh0IGNvbW1lbnQu4oCdDQoNCjMuMS4yLjMuIER5bmFtaWMgQ29u ZmlndXJhdGlvbjogQ29tbWVudCBvbiDigJxzZWN0aW9uIDbigJ06ICDigJxUaGUgcmVmZXJlbmNl IHRvIHNlY3Rpb24gNiBpcyBpbmNvbXBsZXRlLiBTZWN0aW9uIDYgZGVmaW5lcyBubyBsZXNzIHRo YW4gNiBkaWZmZXJlbnQgYXhpc+KAmXMgb24gd2hpY2ggVVJJIGNvbXBhcmlzb25zIGNhbiB2YXJ5 LiBGdXJ0aGVybW9yZSBhcyByZWNlbnRseSBkb2N1bWVudGVkIGluIGRyYWZ0LXRoYWxlci1pYWIt aWRlbnRpZmllci1jb21wYXJpc29uLTAwLnR4dCBpdCBpcyB0cml2aWFsbHkgZWFzeSB0byBzY3Jl dyB1cCBVUkkgY29tcGFyaXNvbnMgYW5kIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgYXJlIHBy ZXR0eSBkaXJlLiBQZXJzb25hbGx5IEkgdGhpbmsgdGhhdCB0aGUgb25seSBzYW5lIGFwcHJvYWNo IGdpdmVuIHRoZSBpc3N1ZXMgaW4gdGhlIHByZXZpb3VzIGxpbmsgaXMgdG8gYWRvcHQgc2VjdGlv biA2LjIuMSBvZiBSRkMgMzk4Ni4NCg0KSSBhbSBhIGJpdCBzY2FyZWQgb2YgaG93IHRvIGhhbmRs ZSBwYXJ0aWFsIG1hdGNoZXMuIEl04oCZcyB0ZW1wdGluZyB0byBhcmd1ZSB0aGF0IHNvIGxvbmcg YXMgdGhlIHNjaGVtYSBoYXMgYW4gYXV0aG9yaXR5IGFuZCBhdCBsZWFzdCBvbmUgcGF0aCBzZWdt ZW50IHRoZW4gd2UgY2FuIGp1c3QgdXNlIGEgcGFydGlhbCBzdHJpbmcgbWF0Y2ggYnV0IGJveSBv aCBib3kgZG8gSSBzZWUgcGVvcGxlIHNjcmV3aW5nIHRoYXQgb25lIHVwIHJveWFsbHkuIFRoaXMg aXMgc2NhcnkgZW5vdWdoIHRoYXQgSSB0aGluayBJIGNhbiBiZSBhcmd1ZWQgaW50byBzYXlpbmcg dGhhdCBwYXJ0aWFsIHByZS1yZWdpc3RlcmVkIFVSSXMgTVVTVCBvbmx5IGRpZmZlciBieSB0aGUg cXVlcnkgY29tcG9uZW50Lg0KDQpJbiBhbnkgY2FzZSB0aGlzIGlzc3VlcyBuZWVkcyB0byBiZSBl eHBsaWNpdGx5IGNhbGxlZCBvdXQgZm9yIGFsbCBVUkkgY29tcGFyaXNvbnMgcmVxdWlyZWQgYnkg dGhlIHNwZWMgYW5kIG5vcm1hdGl2ZWx5IGRlZmluZWQuIE90aGVyd2lzZSB3ZSB3aWxsIGVuZCB1 cCB3aXRoIGFsbCB0aGUgc2VjdXJpdHkgaXNzdWVzIGluIERhdmXigJlzIElELuKAnQ0KDQozLjEu Mi40LiAgSW52YWxpZCBFbmRwb2ludDogQ29tbWVudCBvbiDigJxvcGVuIHJlZGlyZWN0b3LigJ06 IOKAnEhvdyBtYW55IHBlb3BsZSBldmVuIGtub3cgd2hhdCB0aGUgaGVjayBhbiBvcGVuIHJlZGly ZWN0b3IgaXM/IEkgdGhpbmsgd2UgbmVlZCBhIHNlY3Rpb24gaW4gdGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHNlY3Rpb24gdGhhdCBkZWZpbmVzIHdoYXQgYW4gb3BlbiByZWRpcmVjdG9yIGlz IGFuZCB3aHkgaXTigJlzIGJhZC4gQWx0ZXJuYXRpdmVseSBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ug dG8gYSBjb21wbGV0ZSBkZWZpbml0aW9uIHNvbWV3aGVyZSBlbHNlIGlzIGFsc28gZmluZS7igJ0N Cg0KMy4yLjEuIENsaWVudCBBdXRoZW50aWNhdGlvbjogQ2hhbmdlIOKAnFJlY292ZXJ54oCdIHRv IOKAnFJlY292ZXJpbmfigJ0uDQoNCjMuMi4xLiBDbGllbnQgQXV0aGVudGljYXRpb246IENoYW5n ZSDigJxjcmVkZW50aWFscywgYnkgcHJldmVudGluZyBhbiBhdHRhY2tlciBmcm9tIGFidXNpbmfi gJ0gdG8g4oCcY3JlZGVudGlhbHMuIFRoaXMgcHJldmVudHMgYW4gYXR0YWNrZXIgZnJvbSBhYnVz aW5n4oCdDQoNCjMuMi4xLiBDbGllbnQgQXV0aGVudGljYXRpb246IENoYW5nZSDigJxwZXJpb2Rp YyBjcmVkZW50aWFscyByb3RhdGlvbuKAnSB0byDigJxwZXJpb2RpYyBjcmVkZW50aWFsIHJvdGF0 aW9u4oCdLg0KDQozLjIuMS4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiBDb21tZW50IG9uIOKAnHdo aWxlIHJvdGF0aW9uIG9mIGEgc2luZ2xlIHNldCBvZiBjbGllbnQgY3JlZGVudGlhbHMgaXMgc2ln bmlmaWNhbnRseSBlYXNpZXLigJ06IOKAnFRoZSBzcGVjIGNhbGxzIG91dCByb3RhdGlvbiBvZiBj cmVkZW50aWFscyBhcyBiZWluZyBjcnVjaWFsIGJ1dCB0aGVuIGRvZXNu4oCZdCBkZWZpbmUgaG93 IHRoaXMgaXMgdG8gYmUgZG9uZT8gVGhhdCBzZWVtcyBraW5kIG9mIG9kZC4gU2hvdWxkbuKAmXQg d2UgZGVmaW5lIGFuIGVuZHBvaW50IHdoZXJlIG9uZSBjYW4gc3VibWl0IG9uZeKAmXMgb2xkIGJ1 dCB1bmV4cGlyZWQgY3JlZGVudGlhbHMgZm9yIG5ldyBvbmVzPyBUaGlzIHN0aWxsIGxlYXZlcyB0 aGUgZWRnZSBjYXNlIG9mIHdoYXQgdG8gZG8gaWYgdGhlIG9sZCBjcmVkZW50aWFscyBoYXZlIGV4 cGlyZWQgYW5kIG5ldyBvbmVzIGhhdmVu4oCZdCBiZWVuIGlzc3VlZCBidXQgdGhhdCBpcyB1bmF2 b2lkYWJsZSBhbmQgaW4gdGhhdCBjYXNlIHdlIGNhbiByZXF1aXJlIG91dCBvZiBzY29wZSBhY3Rp b24u4oCdDQoNCjQuMS4gQXV0aG9yaXphdGlvbiBDb2RlOiBDb21tZW50IG9uIGZpcnN0IOKAnF7i gJ06IOKAnFNob3VsZG7igJl0IHRoaXMgYmUgYSB2IGNoYXJhY3RlciBhbmQgbm90IGEgXj8gVGhp cyB3b3VsZCBtYWtlIGl0IGNvbnNpc3RlbnQgd2l0aCBBIHdoaWNoIGFsc28gY3Jvc3NlcyB0d28g Ym94ZXMgYW5kIHBvaW50cyBpbiB0aGUgc2FtZSBkaXJlY3Rpb24u4oCdDQoNCjQuMS4gQXV0aG9y aXphdGlvbiBDb2RlOiBDaGFuZ2Ug4oCcSWYgdmFsaWQsIHJlc3BvbmRzIGJhY2sgd2l0aCBhbiBh Y2Nlc3MgdG9rZW7igJ0gdG8g4oCcSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQsIHRoZW4gdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIHdpbGwgcmVzcG9uZHMgYmFjayB3aXRoIGFuIGFjY2VzcyB0b2tl biBhbmQgb3B0aW9uYWxseSBhIHJlZnJlc2ggdG9rZW7igJ0uDQoNCjQuMS4yLiAgQXV0aG9yaXph dGlvbiBSZXNwb25zZTogQ29tbWVudCDigJxUaGUgbGFuZ3VhZ2UgYXJvdW5kIHNjb3BlcyBpbiB0 aGUgZG9jdW1lbnQgaXMgcmVhbGx5IGZydXN0cmF0aW5nLiBPbmUgb25seSBmaW5kcyBvdXQgbXVj aCBsYXRlciBpbiB0aGUgZG9jdW1lbnQgdGhhdCBpdCBpcyBwZXJmZWN0bHkgYWxsb3dhYmxlIGZv ciBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBtb3JlIG9yIGxlc3MgaWdub3JlIHdoYXQgc2Nv cGVzIGFyZSBzdWJtaXR0ZWQgYW5kIGluc3RlYWQgdG8ganVzdCByZXR1cm4gd2hhdGV2ZXIgdGhl IGhlbGwgdGhleSB3YW50LiBUaGlzIGlzIGEgZmluZSBkZXNpZ24gY2hvaWNlIGJ1dCBpdCBzZWVt cyBsaWtlIHRoZSBzb3J0IG9mIHRoaW5nIHRoYXQgc2hvdWxkIGJlIGZvcmNlZnVsbHkgcmVwZWF0 ZWQgYW55d2hlcmUgaW4gdGhlIHNwZWMgdGhhdCB3ZSBhbGxvdyBwZW9wbGUgdG8gc3VibWl0IHNj b3BlcyBzbyBub2JvZHkgZm9yZ2V0cy7igJ0NCg0KNC4xLjIuICBBdXRob3JpemF0aW9uIFJlc3Bv bnNlOiBDb21tZW50IG9uIOKAnHN0YXRl4oCdOiDigJxEb27igJl0IHdlIGhhdmUgdG8gcHJvdmlk ZSBzb21lIGd1aWRhbmNlIG9uIGhvdyBsYXJnZSB0aGUgc3RhdGUgdmFsdWUgY2FuIHNhZmVseSBi ZT8gT3RoZXJ3aXNlIHdlIGFyZSBhc2tpbmcgY2xpZW50cyB0byByZXdyaXRlIHRoZWlyIHN0YXRl IG1lY2hhbmlzbXMgZXZlcnkgdGltZSB0aGV5IHRocm93IGluIHN1cHBvcnQgZm9yIGEgbmV3IHBy b3RlY3RlZCByZXNvdXJjZSBzZXJ2ZXIuIFdlIGhhdmUgdG8gc2V0IGV4cGVjdGF0aW9ucyBhY3Jv c3MgdGhlIGluZHVzdHJ5IGlmIHdlIGFyZSB0byBob3BlIGZvciBhY3R1YWwgaW50ZXJvcGVyYWJp bGl0eS7igJ0NCg0KNC4xLjIuMS4gRXJyb3IgUmVzcG9uc2U6IENvbW1lbnQgb24g4oCcVVRGLTgg ZW5jb2RlZCB0ZXh04oCdOiDigJxJIHRoaW5rIGp1c3Qgc2F5aW5nIFVURi04IGVuY29kZWQgdGV4 dCBjYW4gYmUgbWlzbGVhZGluZy4gSXTigJlzIG5vdCBsZWdhbCB0byBwdXQgVVRGLTggY2hhcmFj dGVycyBpbnRvIGEgeC13d3ctZm9ybS11cmxlbmNvZGVkIHVzZWQgaW4gYSBHRVQgKGFzIGRlZmlu ZWQgYnkgc2VjdGlvbiAxNy4xMy4xIG9mIEhUTUwgNC4wMSkuIFNvIHdoYXQgeW91IGhhdmUgdG8g ZG8gaXMgdGFrZSB0aGUgVVRGLTggU3RyaW5nIGFuZCB0aGVuIFVSTCBlbmNvZGUgaXQuIFdoaWNo IGlzIGZpbmUgYnV0IHdlIHNob3VsZCBjYWxsIHRoaXMgb3V0LiAgTm90ZSB0aGF0IHRoaXMgaXMg YSBzZXBhcmF0ZSBpc3N1ZSB0aGFuIFVURi04IHN1cHBvcnQgZm9yIHgtd3d3LWZvcm0tdXJsZW5j b2RlZC4gVGhhdCBpc3N1ZSBvbmx5IGFwcGxpZXMgd2hlbiB0aGUgZm9ybSBpcyBpbiB0aGUgcmVx dWVzdCBib2R5LiBJbiB0aGlzIHNjZW5hcmlvIHRoZSBmb3JtIGlzIGluIGEgVVJMLiBUaGVyZSBp cyBubyBxdWVzdGlvbiB0aGF0IFVSTHMgaW4gSFRUUCByZXF1ZXN0IGxpc3RzIGRvbuKAmXQgc3Vw cG9ydCBVVEYtOC7igJ0NCg0KNC4xLjMuIEFjY2VzcyBUb2tlbiBSZXF1ZXN0OiBDaGFuZ2Ug4oCc Rm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQIHVzaW5n4oCd IHRvIOKAnEZvciBleGFtcGxlLCBpZiB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcgSFRU UCByZXF1ZXN0IHVzaW5n4oCdDQoNCjQuMS4zLiBBY2Nlc3MgVG9rZW4gUmVxdWVzdDogQ29tbWVu dCBvbiDigJx0aGF0IHRoZWlyIHZhbHVlcyBhcmUgaWRlbnRpY2Fs4oCdOiDigJxUaGlzIHZlcmJp YWdlIGlzbuKAmXQgbXVjaCB1c2UsIGZvciBleGFtcGxlLCBpZiB0aGUgY2xpZW50IGNhbiBhbHdh eXMgc2VuZCB0aGUgc2FtZSByZWRpcmVjdF91cmkuIFNvLCBqdXN0IHRvIGJlIGNsZWFyLCB0aGlz IHRleHQgaGVyZSBkb2VzbuKAmXQgaW4gYW55d2F5IGNoYW5nZSBteSBwcmV2aW91cyByZWNvbW1l bmRhdGlvbiByZWdhcmRpbmcgdGhlIGF0dGFjayBwcmV2aW91c2x5IGRlc2NyaWJlZC7igJ0NCg0K NC4xLjQuIEFjY2VzcyBUb2tlbiBSZXNwb25zZTogQ29tbWVudCBvbiDigJwidG9rZW5fdHlwZSI6 ImV4YW1wbGUi4oCdOiDigJxKdXN0IHRvIHByZXZlbnQgYW55IGNvbmZ1c2lvbiBpdCB3b3VsZCBi ZSBnb29kIHRvIGFjdHVhbGx5IGRlZmluZSB0aGUgdG9rZW5fdHlwZSDigJxleGFtcGxl4oCdIGlu IHRoaXMgZG9jdW1lbnQgKFByb2JhYmx5IGluIHNlY3Rpb24gNy4xIGFuZCBsYXRlciBpbiB0aGUg SUFOQSBzZWN0aW9uKSBhbmQgc3BlY2lmeSB0aGF0IGl0IGlzIHJlc2VydmVkIGZvciB1c2UgaW4g ZXhhbXBsZXMgd2hlcmUgb25lIGRvZXMgbm90IHdpc2ggdG8gYmUgbW9yZSBzcGVjaWZpYy7igJ0N Cg0KNC4yLiAgSW1wbGljaXQgR3JhbnQ6IENvbW1lbnQg4oCcSSBoYXZlIHJ1biBpbnRvIG11bHRp cGxlIHBlb3BsZSAoaW5jbHVkaW5nIG15c2VsZikgd2hvIGhhdmUgcmVhZCB0aGUgT0F1dGggc3Bl YyBhbmQgY2FtZSBhd2F5IGNvbXBsZXRlbHkgY29uZnVzZWQgYWJvdXQgd2hlbiB0aGUgaGVjayBv bmUgaXMgc3VwcG9zZWQgdG8gdXNlIHRoZSBpbXBsaWNpdCBncmFudCBmbG93IGZvci4gSXTigJlz IG5vdCBpbW1lZGlhdGVseSBvYnZpb3VzIHRoYXQgaXTigJlzIGEgd2F5IHRvIHN1cHBvcnQgc3Rh bmRhbG9uZSBicm93c2VyIGJhc2VkIGNsaWVudHMuIENhbiB3ZSBwdXQgaW4gYW4gZXhhbXBsZSBv ciBzb21ldGhpbmcgdG8gbWFrZSBpdCBtb3JlIG9idmlvdXMgd2h5IGl04oCZcyBoZXJlP+KAnQ0K DQo0LjIuMS4gQXV0aG9yaXphdGlvbiBSZXF1ZXN0OiBDb21tZW50IG9uIHJlZGlyZWN0X3VyaTog IOKAnEdpdmVuIHRoYXQgdGhlIG9ubHkgd2F5IHRvIGlkZW50aWZ5IHRoZSBjbGllbnQgaW4gdGhl IGltcGxpY2l0IGdyYW50IGZsb3cgaXMgdmlhIHRoZSByZWRpcmVjdF91cmksIGhvdyBjYW4gaXQg YmUgb3B0aW9uYWw/4oCdDQoNCjQuMy4gUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlh bHM6IENoYW5nZSDigJxlbmFibGluZyB0aGUgZ3JhbnQgdHlwZSwgYW5kIG9ubHkgd2hlbiBvdGhl ciBmbG93c+KAnSB0byDigJxlbmFibGluZyB0aGUgZ3JhbnQgdHlwZSBhbmQgb25seSB1c2UgaXQg d2hlbiBvdGhlciBmbG93c+KAnS4NCg0KNC4zLiBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVk ZW50aWFsczogQ2hhbmdlIOKAnHJlc291cmNlIG93bmVyIGNyZWRlbnRpYWxz4oCdIHRvIOKAnHJl c291cmNlIG93bmVy4oCZcyBjcmVkZW50aWFsc+KAnS4NCg0KNC4zLjIuIEFjY2VzcyBUb2tlbiBS ZXF1ZXN0OiAgQ29tbWVudCBvbiDigJxhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHByb3RlY3Qg dGhlIGVuZHBvaW50IGFnYWluc3QgYnJ1dGUgZm9yY2UgYXR0YWNrc+KAnTog4oCcU2hvdWxkbuKA mXQgdGhlIHJlcXVpcmVtZW50IHRvIHByZXZlbnQgYWdhaW5zdCBicnV0ZSBmb3JjZSBhdHRhY2tz IGFwcGx5IHRvIGFsbCBjcmVkZW50aWFscywgcmVzb3VyY2Ugb3duZXIgb3Igb3RoZXJ3aXNlPyBJ biBvdGhlciB3b3JkcyBpbiBzZWN0aW9uIDIuNC4xIHdlIHRhbGsgYWJvdXQgaG93IGNsaWVudHMg c3VibWl0IHRoZWlyIG5hbWUvcGFzc3dvcmQuIFNob3VsZG7igJl0IGVuZHBvaW50cyBhY2NlcHRp bmcgY2xpZW50IG5hbWUvcGFzc3dvcmRzIGhhdmUgdGhlIHNhbWUgcHJvdGVjdGlvbnMgYWdhaW5z dCBicnV0ZSBmb3JjZSBhdHRhY2s/4oCdDQoNCjQuNC4zLiBBY2Nlc3MgVG9rZW4gUmVzcG9uc2U6 IENvbW1lbnQgb24g4oCcQSByZWZyZXNoIHRva2VuIFNIT1VMRCBOT1QgYmUgaW5jbHVkZWTigJ06 IOKAnFdoeSBpc27igJl0IHRoaXMgYSBNVVNUIE5PVD/igJ0NCg0KNC41LiBFeHRlbnNpb25zOiBD b21tZW50IOKAnElzbuKAmXQgdGhlIHRleHQgaW4gdGhpcyBzZWN0aW9uIGFuZCA4LjMgcmVkdW5k YW50IHdpdGggZWFjaCBvdGhlcj8gSXQgc2VlbXMgbGlrZSB3ZSBzaG91bGQgdGFrZSB0aGUgdGV4 dCBmcm9tIGhlcmUgYW5kIG1lcmdlIGl0IHdpdGggc2VjdGlvbiA4LjMgc28gYWxsIHRoZSBleHRl bnNpb24gaW5mb3JtYXRpb24gaXMgcmVjb3JkZWQgaW4gb25lIHBsYWNlLiAgSXTigJlzIGp1c3Qg cGxhaW4gdGhhdCBhbGwgb3RoZXIgZXh0ZW5zaW9uIHBvaW50cyBhcmUgaW4gc2VjdGlvbiA4IGJ1 dCB0aGlzIG9uZS7igJ0NCg0KNS4xLiBTdWNjZXNzZnVsIFJlc3BvbnNlOiBDb21tZW50IG9uIOKA nHBhcmFtZXRlciBhdCB0aGUgaGlnaGVzdCBzdHJ1Y3R1cmUgbGV2ZWzigJ06IOKAnEFyZSB0aGVy ZSBhbnkgZ3VhcmFudGVlcyBhYm91dCB0aGUgb3JkZXIgb2YgdGhlIG1lbWJlcnMgaW4gdGhlIEpT T04gb2JqZWN0PyBJZiBub3Qgd2Ugc2hvdWxkIHNheSBzbyBleHBsaWNpdGx5LuKAnQ0KDQo1LjIu IEVycm9yIFJlc3BvbnNlOiBDb21tZW50IG9uIOKAnG11bHRpcGxlIGNsaWVudCBhdXRoZW50aWNh dGlvbnMgaW5jbHVkZWTigJ0gaW4gaW52YWxpZF9jbGllbnQ6IOKAnFNob3VsZG7igJl0IHRoaXMg YmUgYW4gaW52YWxpZF9yZXF1ZXN0P+KAnQ0KDQo1LjIuIEVycm9yIFJlc3BvbnNlOiBDb21tZW50 IG9uIOKAnE51bWVyaWNhbCB2YWx1ZXMgYXJlIGluY2x1ZGVkIGFzIEpTT04gbnVtYmVyc+KAnTog 4oCcU2FtZSBpc3N1ZSBhcyBiZWZvcmUsIGRvZXMgb3JkZXJpbmcgbWF0dGVyIGFuZCBpZiBub3Qg d2UgbmVlZCB0byBzYXkgdGhhdC7igJ0NCg0KOC4xLiBEZWZpbmluZyBBY2Nlc3MgVG9rZW4gVHlw ZXM6IENoYW5nZSDigJxvciB1c2UgYSB1bmlxdWXigJ0gdG8g4oCcb3IgdXNpbmcgYSB1bmlxdWXi gJ0uDQoNCjkuICBOYXRpdmUgQXBwbGljYXRpb25zOiAgQ2hhbmdlIOKAnGFuIHNjaGVtZeKAnSB0 byDigJxhIHNjaGVtZeKAnQ0KDQo5LiAgTmF0aXZlIEFwcGxpY2F0aW9uczogIENoYW5nZSDigJxv ZmZlciBhbiBpbXByb3ZlZCB1c2FiaWxpdHnigJ0gdG8g4oCcb2ZmZXIgaW1wcm92ZWQgdXNhYmls aXR54oCdDQoNCjkuICBOYXRpdmUgQXBwbGljYXRpb25zOiAgQ2hhbmdlIOKAnGluYWJpbGl0eSB0 byBrZWVwIGNyZWRlbnRpYWxzIGNvbmZpZGVudGlhbOKAnSB0byDigJxpbmFiaWxpdHkgdG8ga2Vl cCBjbGllbnQgY3JlZGVudGlhbHMgY29uZmlkZW50aWFs4oCdLg0KDQo5LiAgTmF0aXZlIEFwcGxp Y2F0aW9uczogIENoYW5nZSDigJxXaGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGZs b3cgYSByZWZyZXNoIHRva2VuIGlzIG5vdCByZXR1cm5lZOKAnSB0byDigJxXaGVuIHVzaW5nIHRo ZSBpbXBsaWNpdCBncmFudCB0eXBlIGZsb3cgYSByZWZyZXNoIHRva2VuIGlzIG5vdCByZXR1cm5l ZCBzbyBvbmNlIHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJlcyB0aGUgYXBwbGljYXRpb24gd2lsbCBo YXZlIHRvIHJlcGVhdCB0aGUgYXV0aG9yaXphdGlvbiBwcm9jZXNz4oCdLg0KDQoxMC4yLiBDbGll bnQgSW1wZXJzb25hdGlvbjogIENoYW5nZSDigJxrZWVwIGlzIGNsaWVudOKAnSB0byDigJxrZWVw IGl0cyBjbGllbnTigJ0uDQoNCjEwLjIuIENsaWVudCBJbXBlcnNvbmF0aW9uOiAgQ2hhbmdlIOKA nGR1ZSB0byB0aGUgY2xpZW50IG5hdHVyZeKAnSB0byDigJxkdWUgdG8gdGhlIGNsaWVudOKAmXMg bmF0dXJl4oCdLg0KDQoxMC4yLiBDbGllbnQgSW1wZXJzb25hdGlvbjogIENoYW5nZSDigJxVUkkg dXNlZCBmb3IgcmVjZWl2aW5nIGF1dGhvcml6YXRpb27igJ0gdG8g4oCcVVJJIHVzZWQgZm9yIHJl Y2VpdmluZyBhdXRob3JpemF0aW9uIHJlcXVlc3Rz4oCdDQoNCjEwLjIuIENsaWVudCBJbXBlcnNv bmF0aW9uOiAgQ2hhbmdlIOKAnGVuZ2FnZSB0aGUgcmVzb3VyY2Ugb3duZXLigJ0gdG8g4oCcZW5n YWdpbmcgdGhlIHJlc291cmNlIG93bmVy4oCdLg0KDQoxMC4yLiBDbGllbnQgSW1wZXJzb25hdGlv bjogIENoYW5nZSDigJxhbmQgYXV0aG9yaXplIHRoZSByZXF1ZXN04oCdIHRvIOKAnGFuZCBhdXRo b3JpemUgb3IgcmVqZWN0IHRoZSByZXF1ZXN04oCdLg0KDQoxMC4zLiBBY2Nlc3MgVG9rZW5zOiBD aGFuZ2Ug4oCcQWNjZXNzIHRva2VuIChhcyB3ZWxsIGFzIGFueSBhY2Nlc3MgdG9rZW4gdHlwZS1z cGVjaWZpYyBhdHRyaWJ1dGVzKeKAnSB0byDigJxBY2Nlc3MgdG9rZW5zIChhcyB3ZWxsIGFzIGFu eSBhY2Nlc3MgdG9rZW4gdHlwZSBzcGVjaWZpYyBhdHRyaWJ1dGVzKeKAnS4NCg0KMTAuMy4gQWNj ZXNzIFRva2VuczogQ2hhbmdlIOKAnGd1ZXNzZWQgdG8gcHJvZHVjZeKAnSB0byDigJxndWVzc2Vk IHNvIGFzIHRvIHByZXZlbnQgdW5hdXRob3JpemVkIHBhcnRpZXMgZnJvbSBwcm9kdWNpbmfigJ0u DQoNCjEwLjQuIFJlZnJlc2ggVG9rZW5zOiBDb21tZW50IOKAnEFzIG1lbnRpb25lZCBwcmV2aW91 c2x5IHdlIHJlYWxseSBzaG91bGQgZXhwbGFpbiB3aHkgd2UgaW50cm9kdWNlZCByZWZyZXNoIHRv a2Vucy4gV2l0aG91dCB1bmRlcnN0YW5kaW5nIHRoZSBpbnRlbnQgb2YgdGhlIG1lY2hhbmlzbSBp dOKAmXMgdW5saWtlbHkgaW1wbGVtZW50ZXJzIHdpbGwgdXNlIHRoZW0gYXBwcm9wcmlhdGVseS7i gJ0NCg0KMTAuNC4gUmVmcmVzaCBUb2tlbnM6ICBDaGFuZ2Ug4oCcc3RvcmFnZSwgYW5kIHNoYXJl ZCBvbmx5IGFtb25n4oCdIHRvIOKAnHN0b3JhZ2UsIGFuZCBhcmUgdG8gYmUgc2hhcmVkIG9ubHkg YW1vbmfigJ0uDQoNCjEwLjQuIFJlZnJlc2ggVG9rZW5zOiAgQ2hhbmdlIOKAnHJlZnJlc2ggdG9r ZW5zIHJvdGF0aW9u4oCdIHRvIOKAnHJlZnJlc2ggdG9rZW4gcm90YXRpb27igJ0uDQoNCjEwLjQu IFJlZnJlc2ggVG9rZW5zOiAgQ2hhbmdlIOKAnGd1ZXNzZWQgdG8gcHJvZHVjZeKAnSB0byDigJxn dWVzc2VkIHNvIGFzIHRvIHByZXZlbnQgdW5hdXRob3JpemVkIHBhcnRpZXMgZnJvbSBwcm9kdWNp bmfigJ0uDQoNCjEwLjYuIEF1dGhvcml6YXRpb24gQ29kZSBMZWFrYWdlOiBDb21tZW50IOKAnEkg ZmFuY3kgbXlzZWxmIGFzIGJlaW5nIHJlYXNvbmFibHkgaW50ZWxsaWdlbnQgYW5kIEnigJltIHVu Y2xlYXIgd2hhdCBhdHRhY2sgaXMgYWN0dWFsbHkgYmVpbmcgZGVzY3JpYmVkIGhlcmUu4oCdDQoN CjEwLjYuIEF1dGhvcml6YXRpb24gQ29kZSBMZWFrYWdlOiBDb21tZW50IG9uIOKAnFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVxdWlyZSB0aGUgY2xpZW50IHRvIHJlZ2lzdGVyIHRo ZWlyIHJlZGlyZWN0aW9uIFVSSeKAnTog4oCcV2h5IGlzIHRoaXMgYSBzaG91bGQ/4oCdDQoNCjEw LjcuIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzOiBDb21tZW50IG9uIOKAnHBh c3N3b3JkIGFudGktcGF0dGVybuKAnTog4oCcSXMgaXQgZmFpciB0byBleHBlY3QgdGhhdCB0aGUg cmVhZGVyIGtub3dzIHdoYXQgdGhlIHBhc3N3b3JkIGFudGktcGF0dGVybiBpcz8gU2hvdWxkbuKA mXQgc29tZSByZWZlcmVuY2UgdG8gYSBkZWZpbml0aW9uIG9mIHRoaXMgcGF0dGVybiBiZSByZXF1 aXJlZD/igJ0NCg0KMTAuNy4gUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHM6IENv bW1lbnQgb24g4oCcVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCByZXN0cmljdCB0aGUg c2NvcGUgYW5kIGxpZmV0aW1lIG9mIGFjY2VzcyB0b2tlbnMgaXNzdWVkIHZpYSB0aGlzIGdyYW50 IHR5cGXigJ06IOKAnFJlc3RyaWN0IGluIHdoYXQgd2F5cz8gQmFzZWQgb24gd2hhdCBjcml0ZXJp YT8gVGhpcyBzdGF0ZW1lbnQgaXMgdGhlIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIOKAnGRvbuKAmXQg ZG8gYmFkIHN0dWZm4oCdLiBQZXJoYXBzIHRydWUgYnV0IG5vdCB0ZXJyaWJseSB1c2VmdWwu4oCd DQoNCjEwLjEyLiBDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeTogQ29tbWVudCBvbiBmaXJzdCBw YXJhZ3JhcGg6IOKAnEkgY2hhbGxlbmdlIGFueSByZWFzb25hYmx5IGludGVsbGlnZW50IHBlcnNv biB3aG8gZG9lcyBub3QgYWxyZWFkeSBrbm93IHdoYXQgYSBDU1JGIGlzIHRvIHJlYWQgdGhpcyBw YXJhZ3JhcGggYW5kIGNvbWUgYXdheSBhbnkgY2xlYXJlciBhcyB0byB3aGF0IGlzIGJlaW5nIGRp c2N1c3NlZC4gQXQgYSBtaW5pbXVtIGlzbuKAmXQgc29tZSByZWZlcmVuY2UgdG8gYSBjb21wbGV0 ZSBkZWZpbml0aW9uIG9mIENTUkYgbmVlZGVkIGlmIHRoZXJlIGlzIHRvIGJlIGFueSBob3BlIG9m IHVzZXIgY29tcGxpYW5jZT/igJ0NCg0KMTAuMTIuIENyb3NzLVNpdGUgUmVxdWVzdCBGb3JnZXJ5 OiBDb21tZW50IG9uIOKAnFRoZSAic3RhdGUiIHJlcXVlc3QgcGFyYW1ldGVyIE1VU1QgY29udGFp biBhIG5vbi1ndWVzc2FibGUgdmFsdWXigJ06IOKAnEFjdHVhbGx5IGEgbm9uLWd1ZXNzYWJsZSB2 YWx1ZSB3b27igJl0IHN0b3AgdGhlIGF0dGFjayBkaXNjdXNzZWQgaW4gdGhlIHByZXZpb3VzIHBh cmFncmFwaCBvbiBpdHMgb3duLiBXaGF04oCZcyBhbHNvIG5lZWRlZCBpcyBhIHdheSB0byB1bmlx dWVseSAoYW5kIHVuYnJlYWthYmx5KSBhc3NvY2lhdGUgdGhlIHN0YXRlIHdpdGggYSBwYXJ0aWN1 bGFyIHVzZXIgc28gdGhhdCBpZiBhbiBhdXRob3JpemF0aW9uIGNvZGUgc3dhcCBvY2N1cnMgaXQg Y2FuIGJlIHJlbGlhYmx5IGRldGVjdGVkLuKAnQ0KDQoxMC4xMy4gQ2xpY2tqYWNraW5nOiBDb21t ZW50IG9uIOKAnHgtZnJhbWUtb3B0aW9uc+KAnTog4oCcVGhlIHJlY29tbWVuZGF0aW9uIHNlZW1z IGNvbmZ1c2VkLiBJcyBpdCBvLmsuIHRvIGp1c3QgcmVseSBvbiB4LWZyYW1lLW9wdGlvbnMgb3Ig TVVTVCBvdGhlciBhY3Rpb25zIGJlIHRha2VuP+KAnQ0KDQoxMS4xLiAgVGhlIE9BdXRoIEFjY2Vz cyBUb2tlbiBUeXBlIFJlZ2lzdHJ5OiBDaGFuZ2Ug4oCcdG9rZSB0eXBl4oCdIHRvIOKAnHRva2Vu IHR5cGXigJ0uDQoNCjExLjEuMS4gIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZTogQ2hhbmdlIOKAnHBy b3RlY3RlZCByZXNvdXJjZXMgcmVxdWVzdHMgdXNpbmcgYWNjZXNzIHRva2Vu4oCdIHRvIOKAnHBy b3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyB1c2luZyBhY2Nlc3MgdG9rZW5z4oCdLg0KDQoxMS4x LjEuICBSZWdpc3RyYXRpb24gVGVtcGxhdGU6ICBDaGFuZ2Ug4oCcUmVmZXJlbmNlIHRvIGRvY3Vt ZW504oCdIHRvIOKAnFJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnTigJ0uDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQo= --_000_356C947CE0E94AC49D4836370B40763Bhueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5JcyB0aGVyZSBhIHJlYXNvbiB3aHkg TXIgR29sYW5kIGlzbnQgc2VuZGluZyBoaXMgb3duIGNvbW1lbnRzIGluPzxicj48YnI+T24gQXVn IDEwLCAyMDExLCBhdCAxNzozOSwgIk1pa2UgSm9uZXMiICZsdDs8YSBocmVmPSJtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGRpdj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4xLjQuIEF1dGhvcml6YXRpb24gR3JhbnQ6IENoYW5nZSDigJxyZXNvdXJjZSBvd25lciBhdXRo b3JpemF0aW9u4oCdIHRvIOKAnHJlc291cmNlIG93bmVy4oCZcyBhdXRob3JpemF0aW9u4oCdLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLjQuMS4gQXV0aG9yaXphdGlvbiBDb2RlOiZuYnNwOyBD b21tZW50OiDigJxJdCBzZWVtcyBvZGQgdGhhdCB3ZSBjYW4gZGlzY3VzcyB0aGUgYXV0aG9yaXph dGlvbiBjb2RlIHdpdGhvdXQgYWxzbyBkaXNjdXNzaW5nIHRoZSBzZWN1cml0eSBpc3N1ZXMgaXQg cmFpc2VzIChlLmcuIHBhc3Npbmcgc2VjdXJlIGluZm9ybWF0aW9uIHZpYSBhIGJyb3dzZXIpIGFu ZCB0aHVzIG1vdGl2YXRpbmcgdGhlIGludHJvZHVjdGlvbiBvZg0KIHRoZSByZWZyZXNoIHRva2Vu LiBJIHdvdWxkIGV4cGVjdCB0aGlzIHRvIGJlIHJlZmVycmVkIHRvIGhlcmUuJm5ic3A7IEhhdmlu ZyByZWFkIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIEkgY2FuIGZpbmQgbm8g Y29oZXJlbnQgZGlzY3Vzc2lvbiB0aGVyZSBlaXRoZXIgb2YgdGhlIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgYW5kIHRoZSByZWZyZXNoIHRva2VuIGFuZCB3aHkg b25lIG1vdGl2YXRlZCB0aGUNCiBvdGhlci4gSSB0aGluayB0aGlzIGlzIHNvbWV0aGluZyBpbXBv cnRhbnQgZm9yIGltcGxlbWVudGVycyB0byB1bmRlcnN0YW5kLuKAnTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4xLjQuMi4mbmJzcDsgSW1wbGljaXQ6Jm5ic3A7IENvbW1lbnQ6IOKAnEkgZmluZCB0 aGlzIHNlY3Rpb24gY29uZnVzaW5nLiBJIHRoaW5rIGFuIGV4YW1wbGUgaXMgYWxsIGJ1dCBtYW5k YXRvcnkgaGVyZSBpZiB0aGUgcmVhZGVyIGlzIHRvIHVuZGVyc3RhbmQgd2hhdCBpcyBpbnRlbmRl ZC4mbmJzcDsgRm9yIGV4YW1wbGUsIHdoZW4gSSBmaXJzdCByZWFkIHRoaXMgc2VjdGlvbiBJIHRo b3VnaHQgaXQgd2FzIHNvbWUga2luZCBvZiBzaG9ydCBjdXQNCiB1c2VkIGluIGNhc2VzIHdoZXJl IHRoZSBjbGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyIGhhZCBhIGNsb3NlIHJlbGF0aW9u c2hpcCBhbmQgY291bGQgc2hhcmUgaW5mb3JtYXRpb24gc3VjaCBhcyB0aGUgY2xpZW504oCZcyBp ZGVudGl0eSBzbyBubyBhY2Nlc3MgY29kZSB3YXMgbmVlZGVkLiZuYnNwOyBObyB3aGVyZSBpbiBo ZXJlIGlzIGFueSBoaW50IHRoYXQgdGhpcyBpcyBhYm91dCBicm93c2VyIGJhc2VkIGNsaWVudHMg d2hvIGRvbuKAmXQgaGF2ZSBzZXJ2ZXJzDQogYW5kIHdobyBuZWVkIGEgd2F5IHRvIGdldCB0b2tl bnMuIFNlcmlvdXNseS4gVHJ5IHRvIHJlYWQgdGhpcyBzZWN0aW9uIGFzIHNvbWVvbmUgd2hvIGtu b3dzIG5vdGhpbmcgYWJvdXQgT0F1dGggYW5kIHRlbGwgbWUgdGhhdCB5b3UgZ2V0IHRoZSByaWdo dCBpZGVhIGJhY2sgZnJvbSBpdC4gSXQgbmVlZHMgdG8gYmUgd3JpdHRlbiB0byBiZSBib3RoIGV4 cGxpY2l0IGFzIHRvIGl0cyBnb2FscyBhbmQgY2xlYXJlciBhcyB0byBpdHMgbWVhbnMu4oCdPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuNC4yLiZuYnNwOyBJbXBsaWNpdDombmJzcDsgQ2hhbmdl IOKAnDxzcGFuIGxhbmc9IkVOIj5hdXRoZW50aWNhdGUgdGhlIGNsaWVudCBhbmQgdGhlPC9zcGFu PuKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+YXV0aGVudGljYXRlIHRoZSBjbGllbnQgZGlyZWN0 bHkuIFRoZTwvc3Bhbj7igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuNC4yLiZuYnNwOyBJ bXBsaWNpdDombmJzcDsgQ2hhbmdlIOKAnHdlaWdodGVk4oCdIHRvIOKAnHdlaWdoZWTigJ0uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuNC4zLiZuYnNwOyBSZXNvdXJjZSBPd25lciBQYXNzd29y ZCBDcmVkZW50aWFsczogQ29tbWVudCBvbiDigJwod2hlbiBjb21iaW5lZCB3aXRoIGEgcmVmcmVz aCB0b2tlbinigJ06IOKAnFRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhhdCByZWZyZXNoIHRva2Vu cyBhcmUgbWVudGlvbmVkIGluIHRoZSBzcGVjLiBBbmQgeWV0IHRoZXJlIGlzIG5vIGV4cGxhbmF0 aW9uIG9mIHdoYXQgdGhleSBhcmUuIEkgc3VzcGVjdCB0aGV5IHNob3VsZA0KIGFueXdheSBiZSBp bnRyb2R1Y2VkIGluIHNlY3Rpb24gMS40LjEgKGFzIHByZXZpb3VzbHkgbm90ZWQpIGFuZCB0aGVu IHRoZWlyIHVzZSBoZXJlIHdpbGwgbWFrZSBzZW5zZS4mbmJzcDsgSWYgdGhhdCBpc27igJl0IHBv c3NpYmxlIHRoZW4gaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGEgZm9yd2FyZCByZWZlcmVuY2Ug dG8gc2VjdGlvbiAxLjUgYmVsb3cgc28gdGhlIHJlYWRlciBoYXMgc29tZSBpZGVhIG9mIHdoYXTi gJlzIGdvaW5nIG9uLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLjQuNC4mbmJzcDsgQ2xp ZW50IENyZWRlbnRpYWxzOiZuYnNwOyBDb21tZW50IG9uIOKAnCh0aGUgY2xpZW50IGlzIGFsc28g dGhlIHJlc291cmNlIG93bmVyKeKAnTog4oCcSSB0aGluayB0aGlzIGlzIG1pc2xlYWRpbmcuIElt YWdpbmUgc29tZXRoaW5nIGxpa2UgT2ZmaWNlIHdoZXJlIGEgY2xpZW50IGhhcyBiZWVuIGdyYW50 ZWQgYWNjZXNzIHRvIGEgcGFydGljdWxhciByZXNvdXJjZSBieSB0aGUgcmVzb3VyY2Ugb3duZXIu IFRoZSBjbGllbnQNCiBjYW4gdGhlbiBhc2sgZm9yIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgcmVz b3VyY2UgdXNpbmcgdGhlIGNsaWVudCBjcmVkZW50aWFscyBhbmQgbm8gYWNjZXNzIGNvZGUgb3Ig cmVmcmVzaCB0b2tlbi4gSnVzdCBoYXZpbmcgdGhlIGFkZHJlc3Mgb2YgdGhlIGludGVuZGVkIHJl c291cmNlIChwcm9iYWJseSBwcm92aWRlZCB2aWEgU0NPUEUpIGFsb25nIHdpdGggdGhlIGNsaWVu dCBjcmVkZW50aWFscyBpcyBtb3JlIHRoYW4gZW5vdWdoIHRvIGRlY2lkZQ0KIGlmIGFuIGFjY2Vz cyB0b2tlbiBzaG91bGQgYmUgaXNzdWVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBwb2lu dCBpcyB0aGF0IHRoZSBjbGllbnQgY3JlZGVudGlhbHMgc2NlbmFyaW8gaXMgZnVsbHkgYXBwbGlj YWJsZSB0byBjYXNlcyB3aGVyZSB0aGUgY2xpZW50IGlzIG5vdCB0aGUgcmVzb3VyY2Ugb3duZXIg YnV0IGluIHdoaWNoIHRoZSByZXNvdXJjZSBVUkkgcHJvdmlkZXMgYWxsIHRoZSBjb250ZXh0IG5l ZWRlZCB0byBkZXRlcm1pbmUgaWYgdGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byBnZXQgYW4g YWNjZXNzDQogdG9rZW4uIEkgdGhpbmsgdGhlIGN1cnJlbnQgdGV4dCB3b3VsZCBpbXBseSBvdGhl cndpc2UuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBJIHdvdWxkIHByb3Bvc2UgY2hhbmdp bmcgdGhlIHNlbnRlbmNlIHRvIOKAnENsaWVudCBjcmVkZW50aWFscyBhcmUgdXNlZCBhcyBhbiBh dXRob3JpemF0aW9uIGdyYW50IHdoZW4gdGhlIGNsaWVudCBpcyBhY3Rpbmcgb24gaXRzIG93biBi ZWhhbGYgKHRoZSBjbGllbnQgaXMgYWxzbyB0aGUgcmVzb3VyY2Ugb3duZXIpIG9yIHdoZW4gdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGhhcyBlbm91Z2ggY29udGV4dCB0bw0KIGRldGVybWluZSBm cm9tIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpZiB0aGUgY2xpZW50IGhhcyBhdXRob3JpemF0 aW9uIHRvIGFjY2VzcyB0aGUgcmVxdWVzdGVkIHJlc291cmNlLuKAneKAnTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4xLjQuNS4gRXh0ZW5zaW9uczogQ29tbWVudDog4oCcSSB3b3VsZCBjaGFuZ2Ug dGhpcyBzZW50ZW5jZSB0byByZWFkIOKAnEFkZGl0aW9uYWwgZ3JhbnQgdHlwZXMgbWF5IGJlIGRl ZmluZWQgdG8gc3VwcG9ydCBuZXcgYXBwcm9hY2hlcyB0byBhdXRoZW50aWNhdGlvbi9hdXRob3Jp emF0aW9uIGFzIHdlbGwgYXMgdG8gcHJvdmlkZSBhIGJyaWRnZSBiZXR3ZWVuIE9BdXRoIGFuZCBv dGhlciBwcm90b2NvbHMu4oCd4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuNS4gUmVmcmVz aCBUb2tlbjogQ29tbWVudCBvbiDigJxSZWZyZXNoIHRva2VucyBhcmUgY3JlZGVudGlhbHMgdXNl ZCB0byBvYnRhaW4gYWNjZXNzIHRva2Vucy7igJ06IOKAnFRoaXMgc2VudGVuY2UgcHJlc3VtZXMg dGhhdCByZWZyZXNoIHRva2VucyBhcmUgc2VsZi1jb250YWluZWQgY3JlZGVudGlhbHMuIEluIG90 aGVyIHdvcmRzIHRoYXQgb25lIGNhbiBnZXQgYW4gYWNjZXNzIHRva2VuIGp1c3QgdXNpbmcgYSBy ZWZyZXNoDQogdG9rZW4gYW5kIG5vdGhpbmcgZWxzZS4gVGhpcyBwcmVzdW1wdGlvbiBpcyByZWJ1 dHRlZCBsYXRlciBpbiB0aGUgZG9jdW1lbnQgYnV0IEkgdGhpbmsgaXTigJlzIGNvbmZ1c2luZyB0 byBpbXBseSBvbmUgdGhpbmcgaGVyZSBhbmQgc3RhdGUgb3RoZXJ3aXNlIGxhdGVyIG9uLuKAnTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLjUuIFJlZnJlc2ggVG9rZW46IENoYW5nZSDigJw8c3Bh biBsYW5nPSJFTiI+YSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdHM8L3NwYW4+4oCdIHRvIOKA nDxzcGFuIGxhbmc9IkVOIj5hIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0PC9zcGFuPuKAnS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS41LiBSZWZyZXNoIFRva2VuOiBDb21tZW50IG9uIOKA nDxzcGFuIGxhbmc9IkVOIj4oRykmbmJzcDsgVGhlIGNsaWVudCByZXF1ZXN0cyBhIG5ldyBhY2Nl c3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg YW5kIHByZXNlbnRpbmcgdGhlIHJlZnJlc2ggdG9rZW4uPC9zcGFuPuKAnTog4oCcSHVt4oCmIG5v dyB0aGUgdGV4dCBzZWVtcyB0byBjb250cmFkaWN0IGl0c2VsZi4gQWJvdmUNCiBpdCBzZWVtZWQg bGlrZSB5b3UgY291bGQgdXNlIHRoZSByZWZyZXNoIHRva2VuIGJ5IGl0c2VsZiB0byBnZXQgYW4g YWNjZXNzIHRva2VuIGFuZCBJIGhhZCB0byBhc2sgZm9yIGxhbmd1YWdlIHRoYXQgbWFkZSBpdCBj bGVhciB0aGF0IHlvdSBjb3VsZCB1c2UgYSByZWZyZXNoIHRva2VuIHdpdGggb3RoZXIgY3JlZGVu dGlhbHMuJm5ic3A7IEJ1dCB0aGUgdGV4dCBvZiBwb2ludCBHIG5vdyBpbXBsaWVzIHRoZSBleGFj dCBvcHBvc2l0ZSwgdGhhdCByZWZyZXNoDQogdG9rZW5zIGNhbiBvbmx5IGJlIHVzZWQgd2l0aCBv dGhlciBjcmVkZW50aWFscyBhbmQgbm90IGJ5IHRoZW1zZWx2ZXMuIChFdmVuIHRob3VnaCB0aGUg cGljdHVyZSBpbiBmaWd1cmUgMiBmb3Igc3RlcCBHIGltcGxpZXMgdGhlIG9wcG9zaXRlKS4gSSB3 b3VsZCBlZGl0IHRoaXMgbGFuZ3VhZ2UgdG8gc2F5IOKAnFRoZSBjbGllbnQgcmVxdWVzdHMgYSBu ZXcgYWNjZXNzIHRva2VuLiBEZXBlbmRpbmcgb24gdGhlIGF1dGhvcml6YXRpb24gc2VydmVy4oCZ cw0KIHBvbGljaWVzIHRoaXMgcmVxdWVzdCBtaWdodCBiZSBtYWRlIHdpdGggdGhlIHJlZnJlc2gg dG9rZW4gYnkgaXRzZWxmIG9yIHdpdGggYSBjb21iaW5hdGlvbiBvZiB0aGUgcmVmcmVzaCB0b2tl biBhbmQgb3RoZXIgY2xpZW50IGNyZWRlbnRpYWxzLuKAneKAnTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4yLjEuIENsaWVudCBUeXBlczogQ29tbWVudCBvbiDigJx1c2VyLWFnZW50LWJhc2VkIGFw cGxpY2F0aW9u4oCdOiDigJxHaXZlIHRoZSBwb29yIHJlYWRlciBhIGhpbnQgYW5kIG1lbnRpb24g 4oCYYnJvd3NlcuKAmSBzb21ld2hlcmUgaW4gdGhlIHBhcmFncmFwaCBiZWxvdy4gRm9yIGV4YW1w bGUg4oCcQSB1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9uIGlzIGEgcHVibGljIGNsaWVudCAo c3VjaCBhcyBhIHdlYiBicm93c2VyKSBpbg0KIHdoaWNoIHRoZeKApi7igJ3igJ08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Mi4xLiBDbGllbnQgVHlwZXM6IHdlYiBhcHBsaWNhdGlvbjogQ2hhbmdl IOKAnGFjY2VzcyB0b2tlbnMgb3IgcmVmcmVzaCB0b2tlbnMsIGNhbiByZWNlaXZlIGFuIGFjY2Vw dGFibGUgbGV2ZWzigJ0gdG8g4oCcYWNjZXNzIHRva2VucyBvciByZWZyZXNoIHRva2VucywgY2Fu LCBpbiBzb21lIGNhc2VzLCByZWNlaXZlIGFuIGFjY2VwdGFibGUgbGV2ZWzigJ0uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjIuNC4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiZuYnNwOyBBZGQgYSBw ZXJpb2QgYWZ0ZXIg4oCcZXRj4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLjQuMS4gQ2xp ZW50IFBhc3N3b3JkOiBDb21tZW50IG9uIOKAnGNoYXJzZXQ9VVRGLTjigJ06IOKAnFRoZSB1c2Ug b2YgVVRGLTggd2l0aCB4LXd3dy1mb3JtLXVybGVuY29kZWQgaXMgZXhwbGljaXRseSBiYW5uZWQg YnkgSFRNTCA0LjAxIHNlY3Rpb24gMTcuMTMuMS4gSWYgd2Ugd2FudCB0byB1c2UgVVRGLTggdGhl biB3ZSBoYXZlIHRvIHVzZSBtdWx0aXBhcnQvZm9ybS1kYXRhLCBhbHNvIGRlZmluZWQgYnkgSFRN TCA0LjAxDQogKHNlY3Rpb24gMTcuMTMuNCkuIEJ1dCBzaW5jZSBub2JvZHkgd291bGQgYWN0dWFs bHkgd2FudCB0byBkbyB0aGF0IEkgd291bGQgc3VnZ2VzdCBwdXR0aW5nIGluIGEgcmVmZXJlbmNl IHRvIHNlY3Rpb24gNC4yIG9mIFJGQyA1NTUyIHdoaWNoIGFjdHVhbGx5IGRlZmluZXMgaG93IHRv IHVzZSBVVEYtOCB3aXRoIHgtd3d3LWZvcm0tdXJsZW5jb2RlZCBhbmQgc3BlY2lmeWluZyB0aGF0 IHRoZSA1NTUyIGV4dGVuc2lvbiBNVVNUIGJlIHN1cHBvcnRlZA0KIGJ5IE9BdXRoIHBhcnRpY2lw YW50cy7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4xLiZuYnNwOyBBdXRob3JpemF0aW9u IEVuZHBvaW50OiBDb21tZW50IG9uIGZpcnN0IHNlbnRlbmNlOiZuYnNwOyDigJxUaGVyZSBpcyBh IHRoaXJkIG9wdGlvbiDigJMgbm9uZSBvZiB0aGUgYWJvdmUuICZuYnNwO0l0IHdvdWxkIGJlIGEg c2hhbWUgaWYgdGhlIHRleHQgb2YgdGhpcyBkcmFmdCBleHBsaWNpdGx5IHByb2hpYml0cyB0aGF0 IHBhdHRlcm4u4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuMS4mbmJzcDsgQXV0aG9yaXph dGlvbiBFbmRwb2ludDombmJzcDsgQ29tbWVudCBvbiDigJxbUkZDMzk4Nl0gc2VjdGlvbiAz4oCd OiDigJxTaG91bGRu4oCZdCB3ZSBwb2ludCBkaXJlY3RseSB0byBzZWN0aW9uIDMuNCB3aGljaCBl eGFjdGx5IGRlZmluZXMgdGhlIHF1ZXJ5IGNvbXBvbmVudD/igJ08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+My4xLiZuYnNwOyBBdXRob3JpemF0aW9uIEVuZHBvaW50OiZuYnNwOyBDb21tZW50IG9u IOKAnE1VU1QgYmUgcmV0YWluZWQgd2hlbiBhZGRpbmcgYWRkaXRpb25hbCBxdWVyeTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IHBhcmFtZXRlcnPigJ06 IOKAnEhJR0ggSU1QT1JUQU5DRSDigJMgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIGluY29tcGxldGUu IFNlY3Rpb24gMy40IG9mIFJGQyAzOTg2IHNpbXBseSBhc3NlcnRzIHRoZSBleGlzdGVuY2Ugb2Yg YSBxdWVyeSBjb21wb25lbnQuIEl0IHNheXMgbm90aGluZyBhYm91dCB0aGUgc3ludGF4IG9mIHRo YXQgY29tcG9uZW50LiBUaGUgc3BlYyBhc3N1bWVzIHRoYXQgdGhlIGNvbXBvbmVudCBpcyB1c2lu Zw0KIHgtd3d3LWZvcm0tdXJsZW5jb2RlZCBidXQgdGhhdCBpcyBub3QgaW4gYW55IHdheSBtYW5k YXRlZCBieSBSRkMgMzk4Ni4gU28gdGhlcmUgaXMgYSBub3JtYXRpdmUgc2VudGVuY2UgbWlzc2lu ZyBoZXJlIHdoaWNoIHN0YXRlcyB0aGF0IGFueSBxdWVyeSBwYXJhbWV0ZXIgb24gdGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnTigJlzIFVSSSBNVVNUIGJlIGRlZmluZWQgYXMgc3BlY2lmaWVkIGlu IHgtd3d3LWZvcm0tdXJsZW5jb2RlZC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4xLiZu YnNwOyBBdXRob3JpemF0aW9uIEVuZHBvaW50OiZuYnNwOyBDb21tZW50IG9uIOKAnFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaWdub3JlIHVucmVjb2duaXplZCByZXF1ZXN0IHBhcmFt ZXRlcnMu4oCdOiDigJxBbHRob3VnaCB0aGF0IGlzIG5vcm1hbCBiZWhhdmlvciBmb3IgYXBwbGlj YXRpb24gcHJvdG9jb2xzIGl0IHNlZW1zIHJhdGhlciBkYW5nZXJvdXMgZm9yIGEgc2VjdXJpdHkg cHJvdG9jb2wuIEFmdGVyIGFsbA0KIHdoYXQgaWYgdGhlIGNsaWVudCBwdXQgaW4gYSBwYXJhbWV0 ZXIgc3BlY2lmeWluZyBzb21ldGhpbmcgc2VjdXJpdHkgcmVsYXRlZCBhYm91dCB0aGUgcmVxdWVz dCB0aGlua2luZyB0aGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHdvdWxkIGhvbm9yIGl0 IGFuZCB0aGVuIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHNpbGVudGx5IGlnbm9yZXMgaXQ/ Jm5ic3A7IEFnYWluLCB0aGlzIGlzIGEgc2VjdXJpdHkgcHJvdG9jb2wsIG5vdCBhIGdlbmVyaWMN CiBhcHBsaWNhdGlvbiBwcm90b2NvbCwgaXQgc2VlbXMgdG8gYmUgdGhhdCB1bnJlY29nbml6ZWQg cGFyYW1ldGVycyBzaG91bGQgY2F1c2UgYSBmYWlsdXJlLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4zLjEuMi4mbmJzcDsgUmVkaXJlY3Rpb24gRW5kcG9pbnQ6IENvbW1lbnQgb24g4oCcd2hl biBpbml0aWF0aW5nIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3TigJ06IOKAnEkgd291bGQgc3Vn Z2VzdCBtb3JlIGV4cGxpY2l0IGxhbmd1YWdlIOKAnG9yIGFzIHNwZWNpZmllZCBpbiB0aGUgcmVk aXJlY3Rpb24gVVJJIHZhbHVlIGluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3Qu4oCd4oCdPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuMS4yLjIuIFJlZ2lzdHJhdGlvbiBSZXF1aXJlbWVudHM6 IENvbW1lbnQgb24gbGFzdCB3b3JkIOKAnHBhdGjigJ06IOKAnEh1aD8gU2NoZW1lLCBhdXRob3Jp emF0aW9uIGFuZCBwYXRoIGlzIGEgY29tcGxldGUgVVJJIG1pbnVzIGEgcXVlcnkgY29tcG9uZW50 LiZuYnNwOyBJcyB0aGUgZ29hbCB0byBzcGVjaWZpY2FsbHkgbWFuZGF0ZSB0aGF0IG9ubHkgdGhl IHF1ZXJ5IGNvbXBvbmVudCBjYW4gdmFyeSBhbmQgdGhlIHJlc3Qgb2YNCiB0aGUgVVJJIE1VU1Qg YmUgc3RhdGljPyBJZiBzbyB0aGF0IHNob3VsZCBiZSBzdGF0ZWQgZXhwbGljaXRseSByYXRoZXIg dGhhbiBpbXBsaWNpdGx5IGFzIGl0IGlzIG5vdy4mbmJzcDsgQnV0IEkgdGhpbmssIGlmIHRoYXQg aXMgdGhlIGludGVudCwgaXQgZ29lcyB0b28gZmFyLiBXZSBzaG91bGQgYWxzbyBhbGxvdyBmb3Ig YWRkaXRpb25hbCBwYXRoIHNlZ21lbnRzIHRvIGJlIGFkZGVkIHRvIHRoZSBVUkkgcGF0aCBiZXlv bmQgdGhlIHJlZ2lzdGVyZWQgcHJlZml4Lg0KIEFzc3VtaW5nIHdlIGNhbiBhZGRyZXNzIHRoZSBz ZWN1cml0eSBwcm9ibGVtIGluIHRoZSBuZXh0IGNvbW1lbnQu4oCdPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjMuMS4yLjMuIER5bmFtaWMgQ29uZmlndXJhdGlvbjogQ29tbWVudCBvbiDigJxzZWN0 aW9uIDbigJ06Jm5ic3A7IOKAnFRoZSByZWZlcmVuY2UgdG8gc2VjdGlvbiA2IGlzIGluY29tcGxl dGUuIFNlY3Rpb24gNiBkZWZpbmVzIG5vIGxlc3MgdGhhbiA2IGRpZmZlcmVudCBheGlz4oCZcyBv biB3aGljaCBVUkkgY29tcGFyaXNvbnMgY2FuIHZhcnkuIEZ1cnRoZXJtb3JlIGFzIHJlY2VudGx5 IGRvY3VtZW50ZWQgaW4gZHJhZnQtdGhhbGVyLWlhYi1pZGVudGlmaWVyLWNvbXBhcmlzb24tMDAu dHh0DQogaXQgaXMgdHJpdmlhbGx5IGVhc3kgdG8gc2NyZXcgdXAgVVJJIGNvbXBhcmlzb25zIGFu ZCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIGFyZSBwcmV0dHkgZGlyZS4gUGVyc29uYWxseSBJ IHRoaW5rIHRoYXQgdGhlIG9ubHkgc2FuZSBhcHByb2FjaCBnaXZlbiB0aGUgaXNzdWVzIGluIHRo ZSBwcmV2aW91cyBsaW5rIGlzIHRvIGFkb3B0IHNlY3Rpb24gNi4yLjEgb2YgUkZDIDM5ODYuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gYSBiaXQgc2NhcmVkIG9mIGhvdyB0byBoYW5kbGUg cGFydGlhbCBtYXRjaGVzLiBJdOKAmXMgdGVtcHRpbmcgdG8gYXJndWUgdGhhdCBzbyBsb25nIGFz IHRoZSBzY2hlbWEgaGFzIGFuIGF1dGhvcml0eSBhbmQgYXQgbGVhc3Qgb25lIHBhdGggc2VnbWVu dCB0aGVuIHdlIGNhbiBqdXN0IHVzZSBhIHBhcnRpYWwgc3RyaW5nIG1hdGNoIGJ1dCBib3kgb2gg Ym95IGRvIEkgc2VlIHBlb3BsZSBzY3Jld2luZyB0aGF0DQogb25lIHVwIHJveWFsbHkuIFRoaXMg aXMgc2NhcnkgZW5vdWdoIHRoYXQgSSB0aGluayBJIGNhbiBiZSBhcmd1ZWQgaW50byBzYXlpbmcg dGhhdCBwYXJ0aWFsIHByZS1yZWdpc3RlcmVkIFVSSXMgTVVTVCBvbmx5IGRpZmZlciBieSB0aGUg cXVlcnkgY29tcG9uZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhbnkgY2FzZSB0aGlz IGlzc3VlcyBuZWVkcyB0byBiZSBleHBsaWNpdGx5IGNhbGxlZCBvdXQgZm9yIGFsbCBVUkkgY29t cGFyaXNvbnMgcmVxdWlyZWQgYnkgdGhlIHNwZWMgYW5kIG5vcm1hdGl2ZWx5IGRlZmluZWQuIE90 aGVyd2lzZSB3ZSB3aWxsIGVuZCB1cCB3aXRoIGFsbCB0aGUgc2VjdXJpdHkgaXNzdWVzIGluIERh dmXigJlzIElELuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLjEuMi40LiZuYnNwOyBJbnZh bGlkIEVuZHBvaW50OiBDb21tZW50IG9uIOKAnG9wZW4gcmVkaXJlY3RvcuKAnTog4oCcSG93IG1h bnkgcGVvcGxlIGV2ZW4ga25vdyB3aGF0IHRoZSBoZWNrIGFuIG9wZW4gcmVkaXJlY3RvciBpcz8g SSB0aGluayB3ZSBuZWVkIGEgc2VjdGlvbiBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c2VjdGlvbiB0aGF0IGRlZmluZXMgd2hhdCBhbiBvcGVuIHJlZGlyZWN0b3IgaXMgYW5kIHdoeSBp dOKAmXMNCiBiYWQuIEFsdGVybmF0aXZlbHkgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGEgY29t cGxldGUgZGVmaW5pdGlvbiBzb21ld2hlcmUgZWxzZSBpcyBhbHNvIGZpbmUu4oCdPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjMuMi4xLiBDbGllbnQgQXV0aGVudGljYXRpb246IENoYW5nZSDigJxS ZWNvdmVyeeKAnSB0byDigJxSZWNvdmVyaW5n4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4z LjIuMS4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiBDaGFuZ2Ug4oCcY3JlZGVudGlhbHMsIGJ5IHBy ZXZlbnRpbmcgYW4gYXR0YWNrZXIgZnJvbSBhYnVzaW5n4oCdIHRvIOKAnGNyZWRlbnRpYWxzLiBU aGlzIHByZXZlbnRzIGFuIGF0dGFja2VyIGZyb20gYWJ1c2luZ+KAnTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4zLjIuMS4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiBDaGFuZ2Ug4oCccGVyaW9kaWMg Y3JlZGVudGlhbHMgcm90YXRpb27igJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPnBlcmlvZGljIGNy ZWRlbnRpYWwgcm90YXRpb248L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLjIu MS4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiBDb21tZW50IG9uIOKAnHdoaWxlIHJvdGF0aW9uIG9m IGEgc2luZ2xlIHNldCBvZiBjbGllbnQgY3JlZGVudGlhbHMgaXMgc2lnbmlmaWNhbnRseSBlYXNp ZXLigJ06IOKAnFRoZSBzcGVjIGNhbGxzIG91dCByb3RhdGlvbiBvZiBjcmVkZW50aWFscyBhcyBi ZWluZyBjcnVjaWFsIGJ1dCB0aGVuIGRvZXNu4oCZdCBkZWZpbmUgaG93IHRoaXMgaXMgdG8gYmUg ZG9uZT8gVGhhdCBzZWVtcw0KIGtpbmQgb2Ygb2RkLiBTaG91bGRu4oCZdCB3ZSBkZWZpbmUgYW4g ZW5kcG9pbnQgd2hlcmUgb25lIGNhbiBzdWJtaXQgb25l4oCZcyBvbGQgYnV0IHVuZXhwaXJlZCBj cmVkZW50aWFscyBmb3IgbmV3IG9uZXM/IFRoaXMgc3RpbGwgbGVhdmVzIHRoZSBlZGdlIGNhc2Ug b2Ygd2hhdCB0byBkbyBpZiB0aGUgb2xkIGNyZWRlbnRpYWxzIGhhdmUgZXhwaXJlZCBhbmQgbmV3 IG9uZXMgaGF2ZW7igJl0IGJlZW4gaXNzdWVkIGJ1dCB0aGF0IGlzIHVuYXZvaWRhYmxlIGFuZA0K IGluIHRoYXQgY2FzZSB3ZSBjYW4gcmVxdWlyZSBvdXQgb2Ygc2NvcGUgYWN0aW9uLuKAnTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj40LjEuIEF1dGhvcml6YXRpb24gQ29kZTogQ29tbWVudCBvbiBm aXJzdCDigJxe4oCdOiDigJxTaG91bGRu4oCZdCB0aGlzIGJlIGEgdiBjaGFyYWN0ZXIgYW5kIG5v dCBhIF4/IFRoaXMgd291bGQgbWFrZSBpdCBjb25zaXN0ZW50IHdpdGggQSB3aGljaCBhbHNvIGNy b3NzZXMgdHdvIGJveGVzIGFuZCBwb2ludHMgaW4gdGhlIHNhbWUgZGlyZWN0aW9uLuKAnTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj40LjEuIEF1dGhvcml6YXRpb24gQ29kZTogQ2hhbmdlIOKAnElm IHZhbGlkLCByZXNwb25kcyBiYWNrIHdpdGggYW4gYWNjZXNzIHRva2Vu4oCdIHRvIOKAnElmIHRo ZSByZXF1ZXN0IGlzIHZhbGlkLCB0aGVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHJl c3BvbmRzIGJhY2sgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFsbHkgYSByZWZyZXNo IHRva2Vu4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LjEuMi4mbmJzcDsgQXV0aG9yaXph dGlvbiBSZXNwb25zZTogQ29tbWVudCDigJxUaGUgbGFuZ3VhZ2UgYXJvdW5kIHNjb3BlcyBpbiB0 aGUgZG9jdW1lbnQgaXMgcmVhbGx5IGZydXN0cmF0aW5nLiBPbmUgb25seSBmaW5kcyBvdXQgbXVj aCBsYXRlciBpbiB0aGUgZG9jdW1lbnQgdGhhdCBpdCBpcyBwZXJmZWN0bHkgYWxsb3dhYmxlIGZv ciBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBtb3JlIG9yIGxlc3MgaWdub3JlIHdoYXQNCiBz Y29wZXMgYXJlIHN1Ym1pdHRlZCBhbmQgaW5zdGVhZCB0byBqdXN0IHJldHVybiB3aGF0ZXZlciB0 aGUgaGVsbCB0aGV5IHdhbnQuIFRoaXMgaXMgYSBmaW5lIGRlc2lnbiBjaG9pY2UgYnV0IGl0IHNl ZW1zIGxpa2UgdGhlIHNvcnQgb2YgdGhpbmcgdGhhdCBzaG91bGQgYmUgZm9yY2VmdWxseSByZXBl YXRlZCBhbnl3aGVyZSBpbiB0aGUgc3BlYyB0aGF0IHdlIGFsbG93IHBlb3BsZSB0byBzdWJtaXQg c2NvcGVzIHNvIG5vYm9keSBmb3JnZXRzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LjEu Mi4mbmJzcDsgQXV0aG9yaXphdGlvbiBSZXNwb25zZTogQ29tbWVudCBvbiDigJxzdGF0ZeKAnTog 4oCcRG9u4oCZdCB3ZSBoYXZlIHRvIHByb3ZpZGUgc29tZSBndWlkYW5jZSBvbiBob3cgbGFyZ2Ug dGhlIHN0YXRlIHZhbHVlIGNhbiBzYWZlbHkgYmU/IE90aGVyd2lzZSB3ZSBhcmUgYXNraW5nIGNs aWVudHMgdG8gcmV3cml0ZSB0aGVpciBzdGF0ZSBtZWNoYW5pc21zIGV2ZXJ5IHRpbWUgdGhleSB0 aHJvdyBpbiBzdXBwb3J0IGZvcg0KIGEgbmV3IHByb3RlY3RlZCByZXNvdXJjZSBzZXJ2ZXIuIFdl IGhhdmUgdG8gc2V0IGV4cGVjdGF0aW9ucyBhY3Jvc3MgdGhlIGluZHVzdHJ5IGlmIHdlIGFyZSB0 byBob3BlIGZvciBhY3R1YWwgaW50ZXJvcGVyYWJpbGl0eS7igJ08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+NC4xLjIuMS4gRXJyb3IgUmVzcG9uc2U6IENvbW1lbnQgb24g4oCcVVRGLTggZW5jb2Rl ZCB0ZXh04oCdOiDigJxJIHRoaW5rIGp1c3Qgc2F5aW5nIFVURi04IGVuY29kZWQgdGV4dCBjYW4g YmUgbWlzbGVhZGluZy4gSXTigJlzIG5vdCBsZWdhbCB0byBwdXQgVVRGLTggY2hhcmFjdGVycyBp bnRvIGEgeC13d3ctZm9ybS11cmxlbmNvZGVkIHVzZWQgaW4gYSBHRVQgKGFzIGRlZmluZWQgYnkg c2VjdGlvbiAxNy4xMy4xIG9mIEhUTUwNCiA0LjAxKS4gU28gd2hhdCB5b3UgaGF2ZSB0byBkbyBp cyB0YWtlIHRoZSBVVEYtOCBTdHJpbmcgYW5kIHRoZW4gVVJMIGVuY29kZSBpdC4gV2hpY2ggaXMg ZmluZSBidXQgd2Ugc2hvdWxkIGNhbGwgdGhpcyBvdXQuJm5ic3A7IE5vdGUgdGhhdCB0aGlzIGlz IGEgc2VwYXJhdGUgaXNzdWUgdGhhbiBVVEYtOCBzdXBwb3J0IGZvciB4LXd3dy1mb3JtLXVybGVu Y29kZWQuIFRoYXQgaXNzdWUgb25seSBhcHBsaWVzIHdoZW4gdGhlIGZvcm0gaXMgaW4gdGhlIHJl cXVlc3QNCiBib2R5LiBJbiB0aGlzIHNjZW5hcmlvIHRoZSBmb3JtIGlzIGluIGEgVVJMLiBUaGVy ZSBpcyBubyBxdWVzdGlvbiB0aGF0IFVSTHMgaW4gSFRUUCByZXF1ZXN0IGxpc3RzIGRvbuKAmXQg c3VwcG9ydCBVVEYtOC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4xLjMuIEFjY2VzcyBU b2tlbiBSZXF1ZXN0OiBDaGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPkZvciBleGFtcGxlLCB0aGUg Y2xpZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcgSFRUUCB1c2luZzwvc3Bhbj7igJ0gdG8g4oCcPHNw YW4gbGFuZz0iRU4iPkZvciBleGFtcGxlLCBpZiB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dp bmcgSFRUUCByZXF1ZXN0IHVzaW5nPC9zcGFuPuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40 LjEuMy4gQWNjZXNzIFRva2VuIFJlcXVlc3Q6IENvbW1lbnQgb24g4oCcdGhhdCB0aGVpciB2YWx1 ZXMgYXJlIGlkZW50aWNhbOKAnTog4oCcVGhpcyB2ZXJiaWFnZSBpc27igJl0IG11Y2ggdXNlLCBm b3IgZXhhbXBsZSwgaWYgdGhlIGNsaWVudCBjYW4gYWx3YXlzIHNlbmQgdGhlIHNhbWUgcmVkaXJl Y3RfdXJpLiBTbywganVzdCB0byBiZSBjbGVhciwgdGhpcyB0ZXh0IGhlcmUgZG9lc27igJl0IGlu IGFueXdheSBjaGFuZ2UgbXkNCiBwcmV2aW91cyByZWNvbW1lbmRhdGlvbiByZWdhcmRpbmcgdGhl IGF0dGFjayBwcmV2aW91c2x5IGRlc2NyaWJlZC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ NC4xLjQuIEFjY2VzcyBUb2tlbiBSZXNwb25zZTogQ29tbWVudCBvbiDigJwidG9rZW5fdHlwZSI6 ImV4YW1wbGUi4oCdOiDigJxKdXN0IHRvIHByZXZlbnQgYW55IGNvbmZ1c2lvbiBpdCB3b3VsZCBi ZSBnb29kIHRvIGFjdHVhbGx5IGRlZmluZSB0aGUgdG9rZW5fdHlwZSDigJxleGFtcGxl4oCdIGlu IHRoaXMgZG9jdW1lbnQgKFByb2JhYmx5IGluIHNlY3Rpb24gNy4xIGFuZCBsYXRlciBpbiB0aGUg SUFOQSBzZWN0aW9uKSBhbmQNCiBzcGVjaWZ5IHRoYXQgaXQgaXMgcmVzZXJ2ZWQgZm9yIHVzZSBp biBleGFtcGxlcyB3aGVyZSBvbmUgZG9lcyBub3Qgd2lzaCB0byBiZSBtb3JlIHNwZWNpZmljLuKA nTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LjIuJm5ic3A7IEltcGxpY2l0IEdyYW50OiBDb21t ZW50IOKAnEkgaGF2ZSBydW4gaW50byBtdWx0aXBsZSBwZW9wbGUgKGluY2x1ZGluZyBteXNlbGYp IHdobyBoYXZlIHJlYWQgdGhlIE9BdXRoIHNwZWMgYW5kIGNhbWUgYXdheSBjb21wbGV0ZWx5IGNv bmZ1c2VkIGFib3V0IHdoZW4gdGhlIGhlY2sgb25lIGlzIHN1cHBvc2VkIHRvIHVzZSB0aGUgaW1w bGljaXQgZ3JhbnQgZmxvdyBmb3IuIEl04oCZcyBub3QgaW1tZWRpYXRlbHkNCiBvYnZpb3VzIHRo YXQgaXTigJlzIGEgd2F5IHRvIHN1cHBvcnQgc3RhbmRhbG9uZSBicm93c2VyIGJhc2VkIGNsaWVu dHMuIENhbiB3ZSBwdXQgaW4gYW4gZXhhbXBsZSBvciBzb21ldGhpbmcgdG8gbWFrZSBpdCBtb3Jl IG9idmlvdXMgd2h5IGl04oCZcyBoZXJlP+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LjIu MS4gQXV0aG9yaXphdGlvbiBSZXF1ZXN0OiBDb21tZW50IG9uIHJlZGlyZWN0X3VyaTombmJzcDsg 4oCcR2l2ZW4gdGhhdCB0aGUgb25seSB3YXkgdG8gaWRlbnRpZnkgdGhlIGNsaWVudCBpbiB0aGUg aW1wbGljaXQgZ3JhbnQgZmxvdyBpcyB2aWEgdGhlIHJlZGlyZWN0X3VyaSwgaG93IGNhbiBpdCBi ZSBvcHRpb25hbD/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4zLiBSZXNvdXJjZSBPd25l ciBQYXNzd29yZCBDcmVkZW50aWFsczogQ2hhbmdlIOKAnGVuYWJsaW5nIHRoZSBncmFudCB0eXBl LCBhbmQgb25seSB3aGVuIG90aGVyIGZsb3dz4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5lbmFi bGluZyB0aGUgZ3JhbnQgdHlwZSBhbmQgb25seSB1c2UgaXQgd2hlbiBvdGhlciBmbG93czwvc3Bh bj7igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuMy4gUmVzb3VyY2UgT3duZXIgUGFzc3dv cmQgQ3JlZGVudGlhbHM6IENoYW5nZSDigJw8c3BhbiBsYW5nPSJFTiI+cmVzb3VyY2Ugb3duZXIg Y3JlZGVudGlhbHM8L3NwYW4+4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5yZXNvdXJjZSBvd25l cuKAmXMgY3JlZGVudGlhbHM8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LjMu Mi4gQWNjZXNzIFRva2VuIFJlcXVlc3Q6Jm5ic3A7IENvbW1lbnQgb24g4oCcYXV0aG9yaXphdGlv biBzZXJ2ZXIgTVVTVCBwcm90ZWN0IHRoZSBlbmRwb2ludCBhZ2FpbnN0IGJydXRlIGZvcmNlIGF0 dGFja3PigJ06IOKAnFNob3VsZG7igJl0IHRoZSByZXF1aXJlbWVudCB0byBwcmV2ZW50IGFnYWlu c3QgYnJ1dGUgZm9yY2UgYXR0YWNrcyBhcHBseSB0byBhbGwgY3JlZGVudGlhbHMsIHJlc291cmNl IG93bmVyIG9yIG90aGVyd2lzZT8NCiBJbiBvdGhlciB3b3JkcyBpbiBzZWN0aW9uIDIuNC4xIHdl IHRhbGsgYWJvdXQgaG93IGNsaWVudHMgc3VibWl0IHRoZWlyIG5hbWUvcGFzc3dvcmQuIFNob3Vs ZG7igJl0IGVuZHBvaW50cyBhY2NlcHRpbmcgY2xpZW50IG5hbWUvcGFzc3dvcmRzIGhhdmUgdGhl IHNhbWUgcHJvdGVjdGlvbnMgYWdhaW5zdCBicnV0ZSBmb3JjZSBhdHRhY2s/4oCdPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjQuNC4zLiBBY2Nlc3MgVG9rZW4gUmVzcG9uc2U6IENvbW1lbnQgb24g 4oCcQSByZWZyZXNoIHRva2VuIFNIT1VMRCBOT1QgYmUgaW5jbHVkZWTigJ06IOKAnFdoeSBpc27i gJl0IHRoaXMgYSBNVVNUIE5PVD/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC41LiBFeHRl bnNpb25zOiBDb21tZW50IOKAnElzbuKAmXQgdGhlIHRleHQgaW4gdGhpcyBzZWN0aW9uIGFuZCA4 LjMgcmVkdW5kYW50IHdpdGggZWFjaCBvdGhlcj8gSXQgc2VlbXMgbGlrZSB3ZSBzaG91bGQgdGFr ZSB0aGUgdGV4dCBmcm9tIGhlcmUgYW5kIG1lcmdlIGl0IHdpdGggc2VjdGlvbiA4LjMgc28gYWxs IHRoZSBleHRlbnNpb24gaW5mb3JtYXRpb24gaXMgcmVjb3JkZWQgaW4gb25lIHBsYWNlLiZuYnNw OyBJdOKAmXMganVzdA0KIHBsYWluIHRoYXQgYWxsIG90aGVyIGV4dGVuc2lvbiBwb2ludHMgYXJl IGluIHNlY3Rpb24gOCBidXQgdGhpcyBvbmUu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUu MS4gU3VjY2Vzc2Z1bCBSZXNwb25zZTogQ29tbWVudCBvbiDigJxwYXJhbWV0ZXIgYXQgdGhlIGhp Z2hlc3Qgc3RydWN0dXJlIGxldmVs4oCdOiDigJxBcmUgdGhlcmUgYW55IGd1YXJhbnRlZXMgYWJv dXQgdGhlIG9yZGVyIG9mIHRoZSBtZW1iZXJzIGluIHRoZSBKU09OIG9iamVjdD8gSWYgbm90IHdl IHNob3VsZCBzYXkgc28gZXhwbGljaXRseS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NS4y LiBFcnJvciBSZXNwb25zZTogQ29tbWVudCBvbiDigJxtdWx0aXBsZSBjbGllbnQgYXV0aGVudGlj YXRpb25zIGluY2x1ZGVk4oCdIGluIGludmFsaWRfY2xpZW50OiDigJxTaG91bGRu4oCZdCB0aGlz IGJlIGFuIGludmFsaWRfcmVxdWVzdD/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NS4yLiBF cnJvciBSZXNwb25zZTogQ29tbWVudCBvbiDigJxOdW1lcmljYWwgdmFsdWVzIGFyZSBpbmNsdWRl ZCBhcyBKU09OIG51bWJlcnPigJ06IOKAnFNhbWUgaXNzdWUgYXMgYmVmb3JlLCBkb2VzIG9yZGVy aW5nIG1hdHRlciBhbmQgaWYgbm90IHdlIG5lZWQgdG8gc2F5IHRoYXQu4oCdPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjguMS4gRGVmaW5pbmcgQWNjZXNzIFRva2VuIFR5cGVzOiBDaGFuZ2Ug4oCc PHNwYW4gbGFuZz0iRU4iPm9yIHVzZSBhIHVuaXF1ZTwvc3Bhbj7igJ0gdG8g4oCcPHNwYW4gbGFu Zz0iRU4iPm9yIHVzaW5nIGEgdW5pcXVlPC9zcGFuPuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+OS4mbmJzcDsgTmF0aXZlIEFwcGxpY2F0aW9uczombmJzcDsgQ2hhbmdlIOKAnGFuIHNjaGVt ZeKAnSB0byDigJxhIHNjaGVtZeKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj45LiZuYnNwOyBO YXRpdmUgQXBwbGljYXRpb25zOiAmbmJzcDtDaGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPm9mZmVy IGFuIGltcHJvdmVkIHVzYWJpbGl0eTwvc3Bhbj7igJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPm9m ZmVyIGltcHJvdmVkIHVzYWJpbGl0eTwvc3Bhbj7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ OS4mbmJzcDsgTmF0aXZlIEFwcGxpY2F0aW9uczogJm5ic3A7Q2hhbmdlIOKAnDxzcGFuIGxhbmc9 IkVOIj5pbmFiaWxpdHkgdG8ga2VlcCBjcmVkZW50aWFscyBjb25maWRlbnRpYWw8L3NwYW4+4oCd IHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5pbmFiaWxpdHkgdG8ga2VlcCBjbGllbnQgY3JlZGVudGlh bHMgY29uZmlkZW50aWFsPC9zcGFuPuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OS4mbmJz cDsgTmF0aXZlIEFwcGxpY2F0aW9uczogJm5ic3A7Q2hhbmdlIOKAnFdoZW4gdXNpbmcgdGhlIGlt cGxpY2l0IGdyYW50IHR5cGUgZmxvdyBhIHJlZnJlc2ggdG9rZW4gaXMgbm90IHJldHVybmVk4oCd IHRvIOKAnFdoZW4gdXNpbmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgZmxvdyBhIHJlZnJlc2gg dG9rZW4gaXMgbm90IHJldHVybmVkIHNvIG9uY2UgdGhlIGFjY2VzcyB0b2tlbiBleHBpcmVzIHRo ZSBhcHBsaWNhdGlvbiB3aWxsDQogaGF2ZSB0byByZXBlYXQgdGhlIGF1dGhvcml6YXRpb24gcHJv Y2Vzc+KAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MTAuMi4gQ2xpZW50IEltcGVyc29uYXRp b246Jm5ic3A7IENoYW5nZSDigJxrZWVwIGlzIGNsaWVudOKAnSB0byDigJxrZWVwIGl0cyBjbGll bnTigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEwLjIuIENsaWVudCBJbXBlcnNvbmF0aW9u OiZuYnNwOyBDaGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPmR1ZSB0byB0aGUgY2xpZW50IG5hdHVy ZTwvc3Bhbj7igJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPmR1ZSB0byB0aGUgY2xpZW504oCZcyBu YXR1cmU8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xMC4yLiBDbGllbnQgSW1w ZXJzb25hdGlvbjombmJzcDsgQ2hhbmdlIOKAnDxzcGFuIGxhbmc9IkVOIj5VUkkgdXNlZCBmb3Ig cmVjZWl2aW5nIGF1dGhvcml6YXRpb248L3NwYW4+4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5V UkkgdXNlZCBmb3IgcmVjZWl2aW5nIGF1dGhvcml6YXRpb24gcmVxdWVzdHM8L3NwYW4+4oCdPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEwLjIuIENsaWVudCBJbXBlcnNvbmF0aW9uOiZuYnNwOyBD aGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPmVuZ2FnZSB0aGUgcmVzb3VyY2Ugb3duZXI8L3NwYW4+ 4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5lbmdhZ2luZyB0aGUgcmVzb3VyY2Ugb3duZXI8L3Nw YW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xMC4yLiBDbGllbnQgSW1wZXJzb25hdGlv bjombmJzcDsgQ2hhbmdlIOKAnDxzcGFuIGxhbmc9IkVOIj5hbmQgYXV0aG9yaXplIHRoZSByZXF1 ZXN0PC9zcGFuPuKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+YW5kIGF1dGhvcml6ZSBvciByZWpl Y3QgdGhlIHJlcXVlc3Q8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xMC4zLiBB Y2Nlc3MgVG9rZW5zOiBDaGFuZ2Ug4oCcQWNjZXNzIHRva2VuIChhcyB3ZWxsIGFzIGFueSBhY2Nl c3MgdG9rZW4gdHlwZS1zcGVjaWZpYyBhdHRyaWJ1dGVzKeKAnSB0byDigJw8c3BhbiBsYW5nPSJF TiI+QWNjZXNzIHRva2VucyAoYXMgd2VsbCBhcyBhbnkgYWNjZXNzIHRva2VuIHR5cGUgc3BlY2lm aWMgYXR0cmlidXRlcyk8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xMC4zLiBB Y2Nlc3MgVG9rZW5zOiBDaGFuZ2Ug4oCcZ3Vlc3NlZCB0byBwcm9kdWNl4oCdIHRvIOKAnDxzcGFu IGxhbmc9IkVOIj5ndWVzc2VkIHNvIGFzIHRvIHByZXZlbnQgdW5hdXRob3JpemVkIHBhcnRpZXMg ZnJvbSBwcm9kdWNpbmc8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xMC40LiBS ZWZyZXNoIFRva2VuczogQ29tbWVudCDigJxBcyBtZW50aW9uZWQgcHJldmlvdXNseSB3ZSByZWFs bHkgc2hvdWxkIGV4cGxhaW4gd2h5IHdlIGludHJvZHVjZWQgcmVmcmVzaCB0b2tlbnMuIFdpdGhv dXQgdW5kZXJzdGFuZGluZyB0aGUgaW50ZW50IG9mIHRoZSBtZWNoYW5pc20gaXTigJlzIHVubGlr ZWx5IGltcGxlbWVudGVycyB3aWxsIHVzZSB0aGVtIGFwcHJvcHJpYXRlbHku4oCdPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjEwLjQuIFJlZnJlc2ggVG9rZW5zOiZuYnNwOyBDaGFuZ2Ug4oCcc3Rv cmFnZSwgYW5kIHNoYXJlZCBvbmx5IGFtb25n4oCdIHRvIOKAnHN0b3JhZ2UsIGFuZCBhcmUgdG8g YmUgc2hhcmVkIG9ubHkgYW1vbmfigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEwLjQuIFJl ZnJlc2ggVG9rZW5zOiZuYnNwOyBDaGFuZ2Ug4oCccmVmcmVzaCB0b2tlbnMgcm90YXRpb27igJ0g dG8g4oCccmVmcmVzaCB0b2tlbiByb3RhdGlvbuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MTAuNC4gUmVmcmVzaCBUb2tlbnM6Jm5ic3A7IENoYW5nZSDigJxndWVzc2VkIHRvIHByb2R1Y2Xi gJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPmd1ZXNzZWQgc28gYXMgdG8gcHJldmVudCB1bmF1dGhv cml6ZWQgcGFydGllcyBmcm9tIHByb2R1Y2luZzwvc3Bhbj7igJ0uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjEwLjYuIEF1dGhvcml6YXRpb24gQ29kZSBMZWFrYWdlOiBDb21tZW50IOKAnEkgZmFu Y3kgbXlzZWxmIGFzIGJlaW5nIHJlYXNvbmFibHkgaW50ZWxsaWdlbnQgYW5kIEnigJltIHVuY2xl YXIgd2hhdCBhdHRhY2sgaXMgYWN0dWFsbHkgYmVpbmcgZGVzY3JpYmVkIGhlcmUu4oCdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjEwLjYuIEF1dGhvcml6YXRpb24gQ29kZSBMZWFrYWdlOiBDb21t ZW50IG9uIOKAnFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVxdWlyZSB0aGUgY2xp ZW50IHRvIHJlZ2lzdGVyIHRoZWlyIHJlZGlyZWN0aW9uIFVSSeKAnTog4oCcV2h5IGlzIHRoaXMg YSBzaG91bGQ/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEwLjcuIFJlc291cmNlIE93bmVy IFBhc3N3b3JkIENyZWRlbnRpYWxzOiBDb21tZW50IG9uIOKAnHBhc3N3b3JkIGFudGktcGF0dGVy buKAnTog4oCcSXMgaXQgZmFpciB0byBleHBlY3QgdGhhdCB0aGUgcmVhZGVyIGtub3dzIHdoYXQg dGhlIHBhc3N3b3JkIGFudGktcGF0dGVybiBpcz8gU2hvdWxkbuKAmXQgc29tZSByZWZlcmVuY2Ug dG8gYSBkZWZpbml0aW9uIG9mIHRoaXMgcGF0dGVybiBiZSByZXF1aXJlZD/igJ08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+MTAuNy4gUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHM6 IENvbW1lbnQgb24g4oCcVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCByZXN0cmljdCB0 aGUgc2NvcGUgYW5kIGxpZmV0aW1lIG9mIGFjY2VzcyB0b2tlbnMgaXNzdWVkIHZpYSB0aGlzIGdy YW50IHR5cGXigJ06IOKAnFJlc3RyaWN0IGluIHdoYXQgd2F5cz8gQmFzZWQgb24gd2hhdCBjcml0 ZXJpYT8gVGhpcyBzdGF0ZW1lbnQgaXMgdGhlIGVxdWl2YWxlbnQNCiBvZiBzYXlpbmcg4oCcZG9u 4oCZdCBkbyBiYWQgc3R1ZmbigJ0uIFBlcmhhcHMgdHJ1ZSBidXQgbm90IHRlcnJpYmx5IHVzZWZ1 bC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MTAuMTIuIENyb3NzLVNpdGUgUmVxdWVzdCBG b3JnZXJ5OiBDb21tZW50IG9uIGZpcnN0IHBhcmFncmFwaDog4oCcSSBjaGFsbGVuZ2UgYW55IHJl YXNvbmFibHkgaW50ZWxsaWdlbnQgcGVyc29uIHdobyBkb2VzIG5vdCBhbHJlYWR5IGtub3cgd2hh dCBhIENTUkYgaXMgdG8gcmVhZCB0aGlzIHBhcmFncmFwaCBhbmQgY29tZSBhd2F5IGFueSBjbGVh cmVyIGFzIHRvIHdoYXQgaXMgYmVpbmcgZGlzY3Vzc2VkLiBBdCBhDQogbWluaW11bSBpc27igJl0 IHNvbWUgcmVmZXJlbmNlIHRvIGEgY29tcGxldGUgZGVmaW5pdGlvbiBvZiBDU1JGIG5lZWRlZCBp ZiB0aGVyZSBpcyB0byBiZSBhbnkgaG9wZSBvZiB1c2VyIGNvbXBsaWFuY2U/4oCdPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjEwLjEyLiBDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeTogQ29tbWVu dCBvbiDigJxUaGUgInN0YXRlIiByZXF1ZXN0IHBhcmFtZXRlciBNVVNUIGNvbnRhaW4gYSBub24t Z3Vlc3NhYmxlIHZhbHVl4oCdOiDigJxBY3R1YWxseSBhIG5vbi1ndWVzc2FibGUgdmFsdWUgd29u 4oCZdCBzdG9wIHRoZSBhdHRhY2sgZGlzY3Vzc2VkIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGgg b24gaXRzIG93bi4gV2hhdOKAmXMgYWxzbyBuZWVkZWQgaXMNCiBhIHdheSB0byB1bmlxdWVseSAo YW5kIHVuYnJlYWthYmx5KSBhc3NvY2lhdGUgdGhlIHN0YXRlIHdpdGggYSBwYXJ0aWN1bGFyIHVz ZXIgc28gdGhhdCBpZiBhbiBhdXRob3JpemF0aW9uIGNvZGUgc3dhcCBvY2N1cnMgaXQgY2FuIGJl IHJlbGlhYmx5IGRldGVjdGVkLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xMC4xMy4gQ2xp Y2tqYWNraW5nOiBDb21tZW50IG9uIOKAnHgtZnJhbWUtb3B0aW9uc+KAnTog4oCcVGhlIHJlY29t bWVuZGF0aW9uIHNlZW1zIGNvbmZ1c2VkLiBJcyBpdCBvLmsuIHRvIGp1c3QgcmVseSBvbiB4LWZy YW1lLW9wdGlvbnMgb3IgTVVTVCBvdGhlciBhY3Rpb25zIGJlIHRha2VuP+KAnTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4xMS4xLiZuYnNwOyBUaGUgT0F1dGggQWNjZXNzIFRva2VuIFR5cGUgUmVn aXN0cnk6IENoYW5nZSDigJx0b2tlIHR5cGXigJ0gdG8g4oCcdG9rZW4gdHlwZeKAnS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+MTEuMS4xLiZuYnNwOyBSZWdpc3RyYXRpb24gVGVtcGxhdGU6IENo YW5nZSDigJw8c3BhbiBsYW5nPSJFTiI+cHJvdGVjdGVkIHJlc291cmNlcyByZXF1ZXN0cyB1c2lu ZyBhY2Nlc3MgdG9rZW48L3NwYW4+4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5wcm90ZWN0ZWQg cmVzb3VyY2UgcmVxdWVzdHMgdXNpbmcgYWNjZXNzIHRva2Vuczwvc3Bhbj7igJ0uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjExLjEuMS4mbmJzcDsgUmVnaXN0cmF0aW9uIFRlbXBsYXRlOiZuYnNw OyBDaGFuZ2Ug4oCcUmVmZXJlbmNlIHRvIGRvY3VtZW504oCdIHRvIOKAnFJlZmVyZW5jZSB0byB0 aGUgZG9jdW1lbnTigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6Y29tbWVu dC1saXN0Ij4NCjxociBjbGFzcz0ibXNvY29tb2ZmIiBhbGlnbj0ibGVmdCIgc2l6ZT0iMSIgd2lk dGg9IjMzJSI+DQo8L2Rpdj4NCg0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+T0F1dGggbWFpbGluZyBsaXN0PC9zcGFuPjxicj48 c3Bhbj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwv c3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --_000_356C947CE0E94AC49D4836370B40763Bhueniversecom_-- From tonynad@microsoft.com Thu Aug 11 07:57:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FB021F8574 for ; Thu, 11 Aug 2011 07:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.465 X-Spam-Level: X-Spam-Status: No, score=-7.465 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPvF4DX2bGyU for ; Thu, 11 Aug 2011 07:57:37 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3841821F8571 for ; Thu, 11 Aug 2011 07:57:37 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 07:58:11 -0700 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 07:58:11 -0700 Received: from mail43-ch1-R.bigfish.com (216.32.181.170) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 14:58:10 +0000 Received: from mail43-ch1 (localhost.localdomain [127.0.0.1]) by mail43-ch1-R.bigfish.com (Postfix) with ESMTP id 021F2D70496 for ; Thu, 11 Aug 2011 14:58:10 +0000 (UTC) X-SpamScore: -28 X-BigFish: PS-28(zz9371Kc89bh1418Mc857h98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h) X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT010.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail43-ch1: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT010.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail43-ch1 (localhost.localdomain [127.0.0.1]) by mail43-ch1 (MessageSwitch) id 1313074688558433_12443; Thu, 11 Aug 2011 14:58:08 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail43-ch1.bigfish.com (Postfix) with ESMTP id 78BE31780050; Thu, 11 Aug 2011 14:58:08 +0000 (UTC) Received: from SN2PRD0302HT010.namprd03.prod.outlook.com (207.46.4.139) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 14:58:03 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT010.namprd03.prod.outlook.com ([10.27.90.224]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 14:58:01 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Mike Jones Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland Thread-Index: AcxXpdCrqvPON2CRS72O2K03CR90kwAFmfQAAB6LQIA= Date: Thu, 11 Aug 2011 14:58:00 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> <356C947C-E0E9-4AC4-9D48-36370B40763B@hueniverse.com> In-Reply-To: <356C947C-E0E9-4AC4-9D48-36370B40763B@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89945SN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT010.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 14:57:40 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89945SN2PRD0302MB137_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGUgaXMgb3V0IG9uIHZhY2F0aW9uIHdpdGggbm8gYWNjZXNzIGFuZCBoZSBsZWZ0IE1pa2Ugd2l0 aCBhIGJ1bmNoIG9mIGNvbW1lbnRzIHRvIHB1bGwgdG9nZXRoZXIgdG8gc3VibWl0IGFuZCB3ZSBr bmV3IHRoYXQgeW91IHdhbnRlZCB0aGVzZSBjb21tZW50cyB0byBlbnN1cmUgdGhhdCB0aGUgc3Bl YyBpcyB0aGUgYmVzdCBpdCBjYW4gYmUuDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJhbiBIYW1tZXIt TGFoYXYNClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDEwLCAyMDExIDU6MTkgUE0NClRvOiBNaWtl IEpvbmVzDQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFBhcnRp YWwgc2V0IG9mIGxhc3QgY2FsbCBjb21tZW50cyBvbiBPQXV0aCBkcmFmdCAyMCBmcm9tIFlhcm9u IEdvbGFuZA0KDQpJcyB0aGVyZSBhIHJlYXNvbiB3aHkgTXIgR29sYW5kIGlzbnQgc2VuZGluZyBo aXMgb3duIGNvbW1lbnRzIGluPw0KDQpPbiBBdWcgMTAsIDIwMTEsIGF0IDE3OjM5LCAiTWlrZSBK b25lcyIgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPj4gd3JvdGU6DQoxLjQuIEF1dGhvcml6YXRpb24gR3JhbnQ6IENoYW5nZSDi gJxyZXNvdXJjZSBvd25lciBhdXRob3JpemF0aW9u4oCdIHRvIOKAnHJlc291cmNlIG93bmVy4oCZ cyBhdXRob3JpemF0aW9u4oCdLg0KDQoxLjQuMS4gQXV0aG9yaXphdGlvbiBDb2RlOiAgQ29tbWVu dDog4oCcSXQgc2VlbXMgb2RkIHRoYXQgd2UgY2FuIGRpc2N1c3MgdGhlIGF1dGhvcml6YXRpb24g Y29kZSB3aXRob3V0IGFsc28gZGlzY3Vzc2luZyB0aGUgc2VjdXJpdHkgaXNzdWVzIGl0IHJhaXNl cyAoZS5nLiBwYXNzaW5nIHNlY3VyZSBpbmZvcm1hdGlvbiB2aWEgYSBicm93c2VyKSBhbmQgdGh1 cyBtb3RpdmF0aW5nIHRoZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIHJlZnJlc2ggdG9rZW4uIEkgd291 bGQgZXhwZWN0IHRoaXMgdG8gYmUgcmVmZXJyZWQgdG8gaGVyZS4gIEhhdmluZyByZWFkIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIEkgY2FuIGZpbmQgbm8gY29oZXJlbnQgZGlz Y3Vzc2lvbiB0aGVyZSBlaXRoZXIgb2YgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBhdXRo b3JpemF0aW9uIGNvZGUgYW5kIHRoZSByZWZyZXNoIHRva2VuIGFuZCB3aHkgb25lIG1vdGl2YXRl ZCB0aGUgb3RoZXIuIEkgdGhpbmsgdGhpcyBpcyBzb21ldGhpbmcgaW1wb3J0YW50IGZvciBpbXBs ZW1lbnRlcnMgdG8gdW5kZXJzdGFuZC7igJ0NCg0KMS40LjIuICBJbXBsaWNpdDogIENvbW1lbnQ6 IOKAnEkgZmluZCB0aGlzIHNlY3Rpb24gY29uZnVzaW5nLiBJIHRoaW5rIGFuIGV4YW1wbGUgaXMg YWxsIGJ1dCBtYW5kYXRvcnkgaGVyZSBpZiB0aGUgcmVhZGVyIGlzIHRvIHVuZGVyc3RhbmQgd2hh dCBpcyBpbnRlbmRlZC4gIEZvciBleGFtcGxlLCB3aGVuIEkgZmlyc3QgcmVhZCB0aGlzIHNlY3Rp b24gSSB0aG91Z2h0IGl0IHdhcyBzb21lIGtpbmQgb2Ygc2hvcnQgY3V0IHVzZWQgaW4gY2FzZXMg d2hlcmUgdGhlIGNsaWVudCBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaGFkIGEgY2xvc2UgcmVs YXRpb25zaGlwIGFuZCBjb3VsZCBzaGFyZSBpbmZvcm1hdGlvbiBzdWNoIGFzIHRoZSBjbGllbnTi gJlzIGlkZW50aXR5IHNvIG5vIGFjY2VzcyBjb2RlIHdhcyBuZWVkZWQuICBObyB3aGVyZSBpbiBo ZXJlIGlzIGFueSBoaW50IHRoYXQgdGhpcyBpcyBhYm91dCBicm93c2VyIGJhc2VkIGNsaWVudHMg d2hvIGRvbuKAmXQgaGF2ZSBzZXJ2ZXJzIGFuZCB3aG8gbmVlZCBhIHdheSB0byBnZXQgdG9rZW5z LiBTZXJpb3VzbHkuIFRyeSB0byByZWFkIHRoaXMgc2VjdGlvbiBhcyBzb21lb25lIHdobyBrbm93 cyBub3RoaW5nIGFib3V0IE9BdXRoIGFuZCB0ZWxsIG1lIHRoYXQgeW91IGdldCB0aGUgcmlnaHQg aWRlYSBiYWNrIGZyb20gaXQuIEl0IG5lZWRzIHRvIGJlIHdyaXR0ZW4gdG8gYmUgYm90aCBleHBs aWNpdCBhcyB0byBpdHMgZ29hbHMgYW5kIGNsZWFyZXIgYXMgdG8gaXRzIG1lYW5zLuKAnQ0KDQox LjQuMi4gIEltcGxpY2l0OiAgQ2hhbmdlIOKAnGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGFuZCB0 aGXigJ0gdG8g4oCcYXV0aGVudGljYXRlIHRoZSBjbGllbnQgZGlyZWN0bHkuIFRoZeKAnS4NCg0K MS40LjIuICBJbXBsaWNpdDogIENoYW5nZSDigJx3ZWlnaHRlZOKAnSB0byDigJx3ZWlnaGVk4oCd Lg0KDQoxLjQuMy4gIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzOiBDb21tZW50 IG9uIOKAnCh3aGVuIGNvbWJpbmVkIHdpdGggYSByZWZyZXNoIHRva2VuKeKAnTog4oCcVGhpcyBp cyB0aGUgZmlyc3QgdGltZSB0aGF0IHJlZnJlc2ggdG9rZW5zIGFyZSBtZW50aW9uZWQgaW4gdGhl IHNwZWMuIEFuZCB5ZXQgdGhlcmUgaXMgbm8gZXhwbGFuYXRpb24gb2Ygd2hhdCB0aGV5IGFyZS4g SSBzdXNwZWN0IHRoZXkgc2hvdWxkIGFueXdheSBiZSBpbnRyb2R1Y2VkIGluIHNlY3Rpb24gMS40 LjEgKGFzIHByZXZpb3VzbHkgbm90ZWQpIGFuZCB0aGVuIHRoZWlyIHVzZSBoZXJlIHdpbGwgbWFr ZSBzZW5zZS4gIElmIHRoYXQgaXNu4oCZdCBwb3NzaWJsZSB0aGVuIGl0IHdvdWxkIGJlIGdvb2Qg dG8gaGF2ZSBhIGZvcndhcmQgcmVmZXJlbmNlIHRvIHNlY3Rpb24gMS41IGJlbG93IHNvIHRoZSBy ZWFkZXIgaGFzIHNvbWUgaWRlYSBvZiB3aGF04oCZcyBnb2luZyBvbi7igJ0NCg0KMS40LjQuICBD bGllbnQgQ3JlZGVudGlhbHM6ICBDb21tZW50IG9uIOKAnCh0aGUgY2xpZW50IGlzIGFsc28gdGhl IHJlc291cmNlIG93bmVyKeKAnTog4oCcSSB0aGluayB0aGlzIGlzIG1pc2xlYWRpbmcuIEltYWdp bmUgc29tZXRoaW5nIGxpa2UgT2ZmaWNlIHdoZXJlIGEgY2xpZW50IGhhcyBiZWVuIGdyYW50ZWQg YWNjZXNzIHRvIGEgcGFydGljdWxhciByZXNvdXJjZSBieSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRo ZSBjbGllbnQgY2FuIHRoZW4gYXNrIGZvciBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIHJlc291cmNl IHVzaW5nIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgYW5kIG5vIGFjY2VzcyBjb2RlIG9yIHJlZnJl c2ggdG9rZW4uIEp1c3QgaGF2aW5nIHRoZSBhZGRyZXNzIG9mIHRoZSBpbnRlbmRlZCByZXNvdXJj ZSAocHJvYmFibHkgcHJvdmlkZWQgdmlhIFNDT1BFKSBhbG9uZyB3aXRoIHRoZSBjbGllbnQgY3Jl ZGVudGlhbHMgaXMgbW9yZSB0aGFuIGVub3VnaCB0byBkZWNpZGUgaWYgYW4gYWNjZXNzIHRva2Vu IHNob3VsZCBiZSBpc3N1ZWQuDQoNCk15IHBvaW50IGlzIHRoYXQgdGhlIGNsaWVudCBjcmVkZW50 aWFscyBzY2VuYXJpbyBpcyBmdWxseSBhcHBsaWNhYmxlIHRvIGNhc2VzIHdoZXJlIHRoZSBjbGll bnQgaXMgbm90IHRoZSByZXNvdXJjZSBvd25lciBidXQgaW4gd2hpY2ggdGhlIHJlc291cmNlIFVS SSBwcm92aWRlcyBhbGwgdGhlIGNvbnRleHQgbmVlZGVkIHRvIGRldGVybWluZSBpZiB0aGUgY2xp ZW50IHNob3VsZCBiZSBhYmxlIHRvIGdldCBhbiBhY2Nlc3MgdG9rZW4uIEkgdGhpbmsgdGhlIGN1 cnJlbnQgdGV4dCB3b3VsZCBpbXBseSBvdGhlcndpc2UuDQoNClNvIEkgd291bGQgcHJvcG9zZSBj aGFuZ2luZyB0aGUgc2VudGVuY2UgdG8g4oCcQ2xpZW50IGNyZWRlbnRpYWxzIGFyZSB1c2VkIGFz IGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgd2hlbiB0aGUgY2xpZW50IGlzIGFjdGluZyBvbiBpdHMg b3duIGJlaGFsZiAodGhlIGNsaWVudCBpcyBhbHNvIHRoZSByZXNvdXJjZSBvd25lcikgb3Igd2hl biB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaGFzIGVub3VnaCBjb250ZXh0IHRvIGRldGVybWlu ZSBmcm9tIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpZiB0aGUgY2xpZW50IGhhcyBhdXRob3Jp emF0aW9uIHRvIGFjY2VzcyB0aGUgcmVxdWVzdGVkIHJlc291cmNlLuKAneKAnQ0KDQoxLjQuNS4g RXh0ZW5zaW9uczogQ29tbWVudDog4oCcSSB3b3VsZCBjaGFuZ2UgdGhpcyBzZW50ZW5jZSB0byBy ZWFkIOKAnEFkZGl0aW9uYWwgZ3JhbnQgdHlwZXMgbWF5IGJlIGRlZmluZWQgdG8gc3VwcG9ydCBu ZXcgYXBwcm9hY2hlcyB0byBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIGFzIHdlbGwgYXMg dG8gcHJvdmlkZSBhIGJyaWRnZSBiZXR3ZWVuIE9BdXRoIGFuZCBvdGhlciBwcm90b2NvbHMu4oCd 4oCdDQoNCjEuNS4gUmVmcmVzaCBUb2tlbjogQ29tbWVudCBvbiDigJxSZWZyZXNoIHRva2VucyBh cmUgY3JlZGVudGlhbHMgdXNlZCB0byBvYnRhaW4gYWNjZXNzIHRva2Vucy7igJ06IOKAnFRoaXMg c2VudGVuY2UgcHJlc3VtZXMgdGhhdCByZWZyZXNoIHRva2VucyBhcmUgc2VsZi1jb250YWluZWQg Y3JlZGVudGlhbHMuIEluIG90aGVyIHdvcmRzIHRoYXQgb25lIGNhbiBnZXQgYW4gYWNjZXNzIHRv a2VuIGp1c3QgdXNpbmcgYSByZWZyZXNoIHRva2VuIGFuZCBub3RoaW5nIGVsc2UuIFRoaXMgcHJl c3VtcHRpb24gaXMgcmVidXR0ZWQgbGF0ZXIgaW4gdGhlIGRvY3VtZW50IGJ1dCBJIHRoaW5rIGl0 4oCZcyBjb25mdXNpbmcgdG8gaW1wbHkgb25lIHRoaW5nIGhlcmUgYW5kIHN0YXRlIG90aGVyd2lz ZSBsYXRlciBvbi7igJ0NCg0KMS41LiBSZWZyZXNoIFRva2VuOiBDaGFuZ2Ug4oCcYSBwcm90ZWN0 ZWQgcmVzb3VyY2UgcmVxdWVzdHPigJ0gdG8g4oCcYSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVz dOKAnS4NCg0KMS41LiBSZWZyZXNoIFRva2VuOiBDb21tZW50IG9uIOKAnChHKSAgVGhlIGNsaWVu dCByZXF1ZXN0cyBhIG5ldyBhY2Nlc3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHByZXNlbnRpbmcgdGhlIHJlZnJlc2ggdG9rZW4u4oCd OiDigJxIdW3igKYgbm93IHRoZSB0ZXh0IHNlZW1zIHRvIGNvbnRyYWRpY3QgaXRzZWxmLiBBYm92 ZSBpdCBzZWVtZWQgbGlrZSB5b3UgY291bGQgdXNlIHRoZSByZWZyZXNoIHRva2VuIGJ5IGl0c2Vs ZiB0byBnZXQgYW4gYWNjZXNzIHRva2VuIGFuZCBJIGhhZCB0byBhc2sgZm9yIGxhbmd1YWdlIHRo YXQgbWFkZSBpdCBjbGVhciB0aGF0IHlvdSBjb3VsZCB1c2UgYSByZWZyZXNoIHRva2VuIHdpdGgg b3RoZXIgY3JlZGVudGlhbHMuICBCdXQgdGhlIHRleHQgb2YgcG9pbnQgRyBub3cgaW1wbGllcyB0 aGUgZXhhY3Qgb3Bwb3NpdGUsIHRoYXQgcmVmcmVzaCB0b2tlbnMgY2FuIG9ubHkgYmUgdXNlZCB3 aXRoIG90aGVyIGNyZWRlbnRpYWxzIGFuZCBub3QgYnkgdGhlbXNlbHZlcy4gKEV2ZW4gdGhvdWdo IHRoZSBwaWN0dXJlIGluIGZpZ3VyZSAyIGZvciBzdGVwIEcgaW1wbGllcyB0aGUgb3Bwb3NpdGUp LiBJIHdvdWxkIGVkaXQgdGhpcyBsYW5ndWFnZSB0byBzYXkg4oCcVGhlIGNsaWVudCByZXF1ZXN0 cyBhIG5ldyBhY2Nlc3MgdG9rZW4uIERlcGVuZGluZyBvbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXLigJlzIHBvbGljaWVzIHRoaXMgcmVxdWVzdCBtaWdodCBiZSBtYWRlIHdpdGggdGhlIHJlZnJl c2ggdG9rZW4gYnkgaXRzZWxmIG9yIHdpdGggYSBjb21iaW5hdGlvbiBvZiB0aGUgcmVmcmVzaCB0 b2tlbiBhbmQgb3RoZXIgY2xpZW50IGNyZWRlbnRpYWxzLuKAneKAnQ0KDQoyLjEuIENsaWVudCBU eXBlczogQ29tbWVudCBvbiDigJx1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9u4oCdOiDigJxH aXZlIHRoZSBwb29yIHJlYWRlciBhIGhpbnQgYW5kIG1lbnRpb24g4oCYYnJvd3NlcuKAmSBzb21l d2hlcmUgaW4gdGhlIHBhcmFncmFwaCBiZWxvdy4gRm9yIGV4YW1wbGUg4oCcQSB1c2VyLWFnZW50 LWJhc2VkIGFwcGxpY2F0aW9uIGlzIGEgcHVibGljIGNsaWVudCAoc3VjaCBhcyBhIHdlYiBicm93 c2VyKSBpbiB3aGljaCB0aGXigKYu4oCd4oCdDQoNCjIuMS4gQ2xpZW50IFR5cGVzOiB3ZWIgYXBw bGljYXRpb246IENoYW5nZSDigJxhY2Nlc3MgdG9rZW5zIG9yIHJlZnJlc2ggdG9rZW5zLCBjYW4g cmVjZWl2ZSBhbiBhY2NlcHRhYmxlIGxldmVs4oCdIHRvIOKAnGFjY2VzcyB0b2tlbnMgb3IgcmVm cmVzaCB0b2tlbnMsIGNhbiwgaW4gc29tZSBjYXNlcywgcmVjZWl2ZSBhbiBhY2NlcHRhYmxlIGxl dmVs4oCdLg0KDQoyLjQuIENsaWVudCBBdXRoZW50aWNhdGlvbjogIEFkZCBhIHBlcmlvZCBhZnRl ciDigJxldGPigJ0uDQoNCjIuNC4xLiBDbGllbnQgUGFzc3dvcmQ6IENvbW1lbnQgb24g4oCcY2hh cnNldD1VVEYtOOKAnTog4oCcVGhlIHVzZSBvZiBVVEYtOCB3aXRoIHgtd3d3LWZvcm0tdXJsZW5j b2RlZCBpcyBleHBsaWNpdGx5IGJhbm5lZCBieSBIVE1MIDQuMDEgc2VjdGlvbiAxNy4xMy4xLiBJ ZiB3ZSB3YW50IHRvIHVzZSBVVEYtOCB0aGVuIHdlIGhhdmUgdG8gdXNlIG11bHRpcGFydC9mb3Jt LWRhdGEsIGFsc28gZGVmaW5lZCBieSBIVE1MIDQuMDEgKHNlY3Rpb24gMTcuMTMuNCkuIEJ1dCBz aW5jZSBub2JvZHkgd291bGQgYWN0dWFsbHkgd2FudCB0byBkbyB0aGF0IEkgd291bGQgc3VnZ2Vz dCBwdXR0aW5nIGluIGEgcmVmZXJlbmNlIHRvIHNlY3Rpb24gNC4yIG9mIFJGQyA1NTUyIHdoaWNo IGFjdHVhbGx5IGRlZmluZXMgaG93IHRvIHVzZSBVVEYtOCB3aXRoIHgtd3d3LWZvcm0tdXJsZW5j b2RlZCBhbmQgc3BlY2lmeWluZyB0aGF0IHRoZSA1NTUyIGV4dGVuc2lvbiBNVVNUIGJlIHN1cHBv cnRlZCBieSBPQXV0aCBwYXJ0aWNpcGFudHMu4oCdDQoNCjMuMS4gIEF1dGhvcml6YXRpb24gRW5k cG9pbnQ6IENvbW1lbnQgb24gZmlyc3Qgc2VudGVuY2U6ICDigJxUaGVyZSBpcyBhIHRoaXJkIG9w dGlvbiDigJMgbm9uZSBvZiB0aGUgYWJvdmUuICBJdCB3b3VsZCBiZSBhIHNoYW1lIGlmIHRoZSB0 ZXh0IG9mIHRoaXMgZHJhZnQgZXhwbGljaXRseSBwcm9oaWJpdHMgdGhhdCBwYXR0ZXJuLuKAnQ0K DQozLjEuICBBdXRob3JpemF0aW9uIEVuZHBvaW50OiAgQ29tbWVudCBvbiDigJxbUkZDMzk4Nl0g c2VjdGlvbiAz4oCdOiDigJxTaG91bGRu4oCZdCB3ZSBwb2ludCBkaXJlY3RseSB0byBzZWN0aW9u IDMuNCB3aGljaCBleGFjdGx5IGRlZmluZXMgdGhlIHF1ZXJ5IGNvbXBvbmVudD/igJ0NCg0KMy4x LiAgQXV0aG9yaXphdGlvbiBFbmRwb2ludDogIENvbW1lbnQgb24g4oCcTVVTVCBiZSByZXRhaW5l ZCB3aGVuIGFkZGluZyBhZGRpdGlvbmFsIHF1ZXJ5DQogICBwYXJhbWV0ZXJz4oCdOiDigJxISUdI IElNUE9SVEFOQ0Ug4oCTIFRoaXMgc3BlY2lmaWNhdGlvbiBpcyBpbmNvbXBsZXRlLiBTZWN0aW9u IDMuNCBvZiBSRkMgMzk4NiBzaW1wbHkgYXNzZXJ0cyB0aGUgZXhpc3RlbmNlIG9mIGEgcXVlcnkg Y29tcG9uZW50LiBJdCBzYXlzIG5vdGhpbmcgYWJvdXQgdGhlIHN5bnRheCBvZiB0aGF0IGNvbXBv bmVudC4gVGhlIHNwZWMgYXNzdW1lcyB0aGF0IHRoZSBjb21wb25lbnQgaXMgdXNpbmcgeC13d3ct Zm9ybS11cmxlbmNvZGVkIGJ1dCB0aGF0IGlzIG5vdCBpbiBhbnkgd2F5IG1hbmRhdGVkIGJ5IFJG QyAzOTg2LiBTbyB0aGVyZSBpcyBhIG5vcm1hdGl2ZSBzZW50ZW5jZSBtaXNzaW5nIGhlcmUgd2hp Y2ggc3RhdGVzIHRoYXQgYW55IHF1ZXJ5IHBhcmFtZXRlciBvbiB0aGUgYXV0aG9yaXphdGlvbiBl bmRwb2ludOKAmXMgVVJJIE1VU1QgYmUgZGVmaW5lZCBhcyBzcGVjaWZpZWQgaW4geC13d3ctZm9y bS11cmxlbmNvZGVkLuKAnQ0KDQozLjEuICBBdXRob3JpemF0aW9uIEVuZHBvaW50OiAgQ29tbWVu dCBvbiDigJxUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGlnbm9yZSB1bnJlY29nbml6 ZWQgcmVxdWVzdCBwYXJhbWV0ZXJzLuKAnTog4oCcQWx0aG91Z2ggdGhhdCBpcyBub3JtYWwgYmVo YXZpb3IgZm9yIGFwcGxpY2F0aW9uIHByb3RvY29scyBpdCBzZWVtcyByYXRoZXIgZGFuZ2Vyb3Vz IGZvciBhIHNlY3VyaXR5IHByb3RvY29sLiBBZnRlciBhbGwgd2hhdCBpZiB0aGUgY2xpZW50IHB1 dCBpbiBhIHBhcmFtZXRlciBzcGVjaWZ5aW5nIHNvbWV0aGluZyBzZWN1cml0eSByZWxhdGVkIGFi b3V0IHRoZSByZXF1ZXN0IHRoaW5raW5nIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQg d291bGQgaG9ub3IgaXQgYW5kIHRoZW4gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgc2lsZW50 bHkgaWdub3JlcyBpdD8gIEFnYWluLCB0aGlzIGlzIGEgc2VjdXJpdHkgcHJvdG9jb2wsIG5vdCBh IGdlbmVyaWMgYXBwbGljYXRpb24gcHJvdG9jb2wsIGl0IHNlZW1zIHRvIGJlIHRoYXQgdW5yZWNv Z25pemVkIHBhcmFtZXRlcnMgc2hvdWxkIGNhdXNlIGEgZmFpbHVyZS7igJ0NCg0KMy4xLjIuICBS ZWRpcmVjdGlvbiBFbmRwb2ludDogQ29tbWVudCBvbiDigJx3aGVuIGluaXRpYXRpbmcgdGhlIGF1 dGhvcml6YXRpb24gcmVxdWVzdOKAnTog4oCcSSB3b3VsZCBzdWdnZXN0IG1vcmUgZXhwbGljaXQg bGFuZ3VhZ2Ug4oCcb3IgYXMgc3BlY2lmaWVkIGluIHRoZSByZWRpcmVjdGlvbiBVUkkgdmFsdWUg aW4gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC7igJ3igJ0NCg0KMy4xLjIuMi4gUmVnaXN0cmF0 aW9uIFJlcXVpcmVtZW50czogQ29tbWVudCBvbiBsYXN0IHdvcmQg4oCccGF0aOKAnTog4oCcSHVo PyBTY2hlbWUsIGF1dGhvcml6YXRpb24gYW5kIHBhdGggaXMgYSBjb21wbGV0ZSBVUkkgbWludXMg YSBxdWVyeSBjb21wb25lbnQuICBJcyB0aGUgZ29hbCB0byBzcGVjaWZpY2FsbHkgbWFuZGF0ZSB0 aGF0IG9ubHkgdGhlIHF1ZXJ5IGNvbXBvbmVudCBjYW4gdmFyeSBhbmQgdGhlIHJlc3Qgb2YgdGhl IFVSSSBNVVNUIGJlIHN0YXRpYz8gSWYgc28gdGhhdCBzaG91bGQgYmUgc3RhdGVkIGV4cGxpY2l0 bHkgcmF0aGVyIHRoYW4gaW1wbGljaXRseSBhcyBpdCBpcyBub3cuICBCdXQgSSB0aGluaywgaWYg dGhhdCBpcyB0aGUgaW50ZW50LCBpdCBnb2VzIHRvbyBmYXIuIFdlIHNob3VsZCBhbHNvIGFsbG93 IGZvciBhZGRpdGlvbmFsIHBhdGggc2VnbWVudHMgdG8gYmUgYWRkZWQgdG8gdGhlIFVSSSBwYXRo IGJleW9uZCB0aGUgcmVnaXN0ZXJlZCBwcmVmaXguIEFzc3VtaW5nIHdlIGNhbiBhZGRyZXNzIHRo ZSBzZWN1cml0eSBwcm9ibGVtIGluIHRoZSBuZXh0IGNvbW1lbnQu4oCdDQoNCjMuMS4yLjMuIER5 bmFtaWMgQ29uZmlndXJhdGlvbjogQ29tbWVudCBvbiDigJxzZWN0aW9uIDbigJ06ICDigJxUaGUg cmVmZXJlbmNlIHRvIHNlY3Rpb24gNiBpcyBpbmNvbXBsZXRlLiBTZWN0aW9uIDYgZGVmaW5lcyBu byBsZXNzIHRoYW4gNiBkaWZmZXJlbnQgYXhpc+KAmXMgb24gd2hpY2ggVVJJIGNvbXBhcmlzb25z IGNhbiB2YXJ5LiBGdXJ0aGVybW9yZSBhcyByZWNlbnRseSBkb2N1bWVudGVkIGluIGRyYWZ0LXRo YWxlci1pYWItaWRlbnRpZmllci1jb21wYXJpc29uLTAwLnR4dCBpdCBpcyB0cml2aWFsbHkgZWFz eSB0byBzY3JldyB1cCBVUkkgY29tcGFyaXNvbnMgYW5kIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlv bnMgYXJlIHByZXR0eSBkaXJlLiBQZXJzb25hbGx5IEkgdGhpbmsgdGhhdCB0aGUgb25seSBzYW5l IGFwcHJvYWNoIGdpdmVuIHRoZSBpc3N1ZXMgaW4gdGhlIHByZXZpb3VzIGxpbmsgaXMgdG8gYWRv cHQgc2VjdGlvbiA2LjIuMSBvZiBSRkMgMzk4Ni4NCg0KSSBhbSBhIGJpdCBzY2FyZWQgb2YgaG93 IHRvIGhhbmRsZSBwYXJ0aWFsIG1hdGNoZXMuIEl04oCZcyB0ZW1wdGluZyB0byBhcmd1ZSB0aGF0 IHNvIGxvbmcgYXMgdGhlIHNjaGVtYSBoYXMgYW4gYXV0aG9yaXR5IGFuZCBhdCBsZWFzdCBvbmUg cGF0aCBzZWdtZW50IHRoZW4gd2UgY2FuIGp1c3QgdXNlIGEgcGFydGlhbCBzdHJpbmcgbWF0Y2gg YnV0IGJveSBvaCBib3kgZG8gSSBzZWUgcGVvcGxlIHNjcmV3aW5nIHRoYXQgb25lIHVwIHJveWFs bHkuIFRoaXMgaXMgc2NhcnkgZW5vdWdoIHRoYXQgSSB0aGluayBJIGNhbiBiZSBhcmd1ZWQgaW50 byBzYXlpbmcgdGhhdCBwYXJ0aWFsIHByZS1yZWdpc3RlcmVkIFVSSXMgTVVTVCBvbmx5IGRpZmZl ciBieSB0aGUgcXVlcnkgY29tcG9uZW50Lg0KDQpJbiBhbnkgY2FzZSB0aGlzIGlzc3VlcyBuZWVk cyB0byBiZSBleHBsaWNpdGx5IGNhbGxlZCBvdXQgZm9yIGFsbCBVUkkgY29tcGFyaXNvbnMgcmVx dWlyZWQgYnkgdGhlIHNwZWMgYW5kIG5vcm1hdGl2ZWx5IGRlZmluZWQuIE90aGVyd2lzZSB3ZSB3 aWxsIGVuZCB1cCB3aXRoIGFsbCB0aGUgc2VjdXJpdHkgaXNzdWVzIGluIERhdmXigJlzIElELuKA nQ0KDQozLjEuMi40LiAgSW52YWxpZCBFbmRwb2ludDogQ29tbWVudCBvbiDigJxvcGVuIHJlZGly ZWN0b3LigJ06IOKAnEhvdyBtYW55IHBlb3BsZSBldmVuIGtub3cgd2hhdCB0aGUgaGVjayBhbiBv cGVuIHJlZGlyZWN0b3IgaXM/IEkgdGhpbmsgd2UgbmVlZCBhIHNlY3Rpb24gaW4gdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdGhhdCBkZWZpbmVzIHdoYXQgYW4gb3BlbiByZWRp cmVjdG9yIGlzIGFuZCB3aHkgaXTigJlzIGJhZC4gQWx0ZXJuYXRpdmVseSBhIG5vcm1hdGl2ZSBy ZWZlcmVuY2UgdG8gYSBjb21wbGV0ZSBkZWZpbml0aW9uIHNvbWV3aGVyZSBlbHNlIGlzIGFsc28g ZmluZS7igJ0NCg0KMy4yLjEuIENsaWVudCBBdXRoZW50aWNhdGlvbjogQ2hhbmdlIOKAnFJlY292 ZXJ54oCdIHRvIOKAnFJlY292ZXJpbmfigJ0uDQoNCjMuMi4xLiBDbGllbnQgQXV0aGVudGljYXRp b246IENoYW5nZSDigJxjcmVkZW50aWFscywgYnkgcHJldmVudGluZyBhbiBhdHRhY2tlciBmcm9t IGFidXNpbmfigJ0gdG8g4oCcY3JlZGVudGlhbHMuIFRoaXMgcHJldmVudHMgYW4gYXR0YWNrZXIg ZnJvbSBhYnVzaW5n4oCdDQoNCjMuMi4xLiBDbGllbnQgQXV0aGVudGljYXRpb246IENoYW5nZSDi gJxwZXJpb2RpYyBjcmVkZW50aWFscyByb3RhdGlvbuKAnSB0byDigJxwZXJpb2RpYyBjcmVkZW50 aWFsIHJvdGF0aW9u4oCdLg0KDQozLjIuMS4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiBDb21tZW50 IG9uIOKAnHdoaWxlIHJvdGF0aW9uIG9mIGEgc2luZ2xlIHNldCBvZiBjbGllbnQgY3JlZGVudGlh bHMgaXMgc2lnbmlmaWNhbnRseSBlYXNpZXLigJ06IOKAnFRoZSBzcGVjIGNhbGxzIG91dCByb3Rh dGlvbiBvZiBjcmVkZW50aWFscyBhcyBiZWluZyBjcnVjaWFsIGJ1dCB0aGVuIGRvZXNu4oCZdCBk ZWZpbmUgaG93IHRoaXMgaXMgdG8gYmUgZG9uZT8gVGhhdCBzZWVtcyBraW5kIG9mIG9kZC4gU2hv dWxkbuKAmXQgd2UgZGVmaW5lIGFuIGVuZHBvaW50IHdoZXJlIG9uZSBjYW4gc3VibWl0IG9uZeKA mXMgb2xkIGJ1dCB1bmV4cGlyZWQgY3JlZGVudGlhbHMgZm9yIG5ldyBvbmVzPyBUaGlzIHN0aWxs IGxlYXZlcyB0aGUgZWRnZSBjYXNlIG9mIHdoYXQgdG8gZG8gaWYgdGhlIG9sZCBjcmVkZW50aWFs cyBoYXZlIGV4cGlyZWQgYW5kIG5ldyBvbmVzIGhhdmVu4oCZdCBiZWVuIGlzc3VlZCBidXQgdGhh dCBpcyB1bmF2b2lkYWJsZSBhbmQgaW4gdGhhdCBjYXNlIHdlIGNhbiByZXF1aXJlIG91dCBvZiBz Y29wZSBhY3Rpb24u4oCdDQoNCjQuMS4gQXV0aG9yaXphdGlvbiBDb2RlOiBDb21tZW50IG9uIGZp cnN0IOKAnF7igJ06IOKAnFNob3VsZG7igJl0IHRoaXMgYmUgYSB2IGNoYXJhY3RlciBhbmQgbm90 IGEgXj8gVGhpcyB3b3VsZCBtYWtlIGl0IGNvbnNpc3RlbnQgd2l0aCBBIHdoaWNoIGFsc28gY3Jv c3NlcyB0d28gYm94ZXMgYW5kIHBvaW50cyBpbiB0aGUgc2FtZSBkaXJlY3Rpb24u4oCdDQoNCjQu MS4gQXV0aG9yaXphdGlvbiBDb2RlOiBDaGFuZ2Ug4oCcSWYgdmFsaWQsIHJlc3BvbmRzIGJhY2sg d2l0aCBhbiBhY2Nlc3MgdG9rZW7igJ0gdG8g4oCcSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQsIHRo ZW4gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHdpbGwgcmVzcG9uZHMgYmFjayB3aXRoIGFuIGFj Y2VzcyB0b2tlbiBhbmQgb3B0aW9uYWxseSBhIHJlZnJlc2ggdG9rZW7igJ0uDQoNCjQuMS4yLiAg QXV0aG9yaXphdGlvbiBSZXNwb25zZTogQ29tbWVudCDigJxUaGUgbGFuZ3VhZ2UgYXJvdW5kIHNj b3BlcyBpbiB0aGUgZG9jdW1lbnQgaXMgcmVhbGx5IGZydXN0cmF0aW5nLiBPbmUgb25seSBmaW5k cyBvdXQgbXVjaCBsYXRlciBpbiB0aGUgZG9jdW1lbnQgdGhhdCBpdCBpcyBwZXJmZWN0bHkgYWxs b3dhYmxlIGZvciBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBtb3JlIG9yIGxlc3MgaWdub3Jl IHdoYXQgc2NvcGVzIGFyZSBzdWJtaXR0ZWQgYW5kIGluc3RlYWQgdG8ganVzdCByZXR1cm4gd2hh dGV2ZXIgdGhlIGhlbGwgdGhleSB3YW50LiBUaGlzIGlzIGEgZmluZSBkZXNpZ24gY2hvaWNlIGJ1 dCBpdCBzZWVtcyBsaWtlIHRoZSBzb3J0IG9mIHRoaW5nIHRoYXQgc2hvdWxkIGJlIGZvcmNlZnVs bHkgcmVwZWF0ZWQgYW55d2hlcmUgaW4gdGhlIHNwZWMgdGhhdCB3ZSBhbGxvdyBwZW9wbGUgdG8g c3VibWl0IHNjb3BlcyBzbyBub2JvZHkgZm9yZ2V0cy7igJ0NCg0KNC4xLjIuICBBdXRob3JpemF0 aW9uIFJlc3BvbnNlOiBDb21tZW50IG9uIOKAnHN0YXRl4oCdOiDigJxEb27igJl0IHdlIGhhdmUg dG8gcHJvdmlkZSBzb21lIGd1aWRhbmNlIG9uIGhvdyBsYXJnZSB0aGUgc3RhdGUgdmFsdWUgY2Fu IHNhZmVseSBiZT8gT3RoZXJ3aXNlIHdlIGFyZSBhc2tpbmcgY2xpZW50cyB0byByZXdyaXRlIHRo ZWlyIHN0YXRlIG1lY2hhbmlzbXMgZXZlcnkgdGltZSB0aGV5IHRocm93IGluIHN1cHBvcnQgZm9y IGEgbmV3IHByb3RlY3RlZCByZXNvdXJjZSBzZXJ2ZXIuIFdlIGhhdmUgdG8gc2V0IGV4cGVjdGF0 aW9ucyBhY3Jvc3MgdGhlIGluZHVzdHJ5IGlmIHdlIGFyZSB0byBob3BlIGZvciBhY3R1YWwgaW50 ZXJvcGVyYWJpbGl0eS7igJ0NCg0KNC4xLjIuMS4gRXJyb3IgUmVzcG9uc2U6IENvbW1lbnQgb24g 4oCcVVRGLTggZW5jb2RlZCB0ZXh04oCdOiDigJxJIHRoaW5rIGp1c3Qgc2F5aW5nIFVURi04IGVu Y29kZWQgdGV4dCBjYW4gYmUgbWlzbGVhZGluZy4gSXTigJlzIG5vdCBsZWdhbCB0byBwdXQgVVRG LTggY2hhcmFjdGVycyBpbnRvIGEgeC13d3ctZm9ybS11cmxlbmNvZGVkIHVzZWQgaW4gYSBHRVQg KGFzIGRlZmluZWQgYnkgc2VjdGlvbiAxNy4xMy4xIG9mIEhUTUwgNC4wMSkuIFNvIHdoYXQgeW91 IGhhdmUgdG8gZG8gaXMgdGFrZSB0aGUgVVRGLTggU3RyaW5nIGFuZCB0aGVuIFVSTCBlbmNvZGUg aXQuIFdoaWNoIGlzIGZpbmUgYnV0IHdlIHNob3VsZCBjYWxsIHRoaXMgb3V0LiAgTm90ZSB0aGF0 IHRoaXMgaXMgYSBzZXBhcmF0ZSBpc3N1ZSB0aGFuIFVURi04IHN1cHBvcnQgZm9yIHgtd3d3LWZv cm0tdXJsZW5jb2RlZC4gVGhhdCBpc3N1ZSBvbmx5IGFwcGxpZXMgd2hlbiB0aGUgZm9ybSBpcyBp biB0aGUgcmVxdWVzdCBib2R5LiBJbiB0aGlzIHNjZW5hcmlvIHRoZSBmb3JtIGlzIGluIGEgVVJM LiBUaGVyZSBpcyBubyBxdWVzdGlvbiB0aGF0IFVSTHMgaW4gSFRUUCByZXF1ZXN0IGxpc3RzIGRv buKAmXQgc3VwcG9ydCBVVEYtOC7igJ0NCg0KNC4xLjMuIEFjY2VzcyBUb2tlbiBSZXF1ZXN0OiBD aGFuZ2Ug4oCcRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQ IHVzaW5n4oCdIHRvIOKAnEZvciBleGFtcGxlLCBpZiB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xs b3dpbmcgSFRUUCByZXF1ZXN0IHVzaW5n4oCdDQoNCjQuMS4zLiBBY2Nlc3MgVG9rZW4gUmVxdWVz dDogQ29tbWVudCBvbiDigJx0aGF0IHRoZWlyIHZhbHVlcyBhcmUgaWRlbnRpY2Fs4oCdOiDigJxU aGlzIHZlcmJpYWdlIGlzbuKAmXQgbXVjaCB1c2UsIGZvciBleGFtcGxlLCBpZiB0aGUgY2xpZW50 IGNhbiBhbHdheXMgc2VuZCB0aGUgc2FtZSByZWRpcmVjdF91cmkuIFNvLCBqdXN0IHRvIGJlIGNs ZWFyLCB0aGlzIHRleHQgaGVyZSBkb2VzbuKAmXQgaW4gYW55d2F5IGNoYW5nZSBteSBwcmV2aW91 cyByZWNvbW1lbmRhdGlvbiByZWdhcmRpbmcgdGhlIGF0dGFjayBwcmV2aW91c2x5IGRlc2NyaWJl ZC7igJ0NCg0KNC4xLjQuIEFjY2VzcyBUb2tlbiBSZXNwb25zZTogQ29tbWVudCBvbiDigJwidG9r ZW5fdHlwZSI6ImV4YW1wbGUi4oCdOiDigJxKdXN0IHRvIHByZXZlbnQgYW55IGNvbmZ1c2lvbiBp dCB3b3VsZCBiZSBnb29kIHRvIGFjdHVhbGx5IGRlZmluZSB0aGUgdG9rZW5fdHlwZSDigJxleGFt cGxl4oCdIGluIHRoaXMgZG9jdW1lbnQgKFByb2JhYmx5IGluIHNlY3Rpb24gNy4xIGFuZCBsYXRl ciBpbiB0aGUgSUFOQSBzZWN0aW9uKSBhbmQgc3BlY2lmeSB0aGF0IGl0IGlzIHJlc2VydmVkIGZv ciB1c2UgaW4gZXhhbXBsZXMgd2hlcmUgb25lIGRvZXMgbm90IHdpc2ggdG8gYmUgbW9yZSBzcGVj aWZpYy7igJ0NCg0KNC4yLiAgSW1wbGljaXQgR3JhbnQ6IENvbW1lbnQg4oCcSSBoYXZlIHJ1biBp bnRvIG11bHRpcGxlIHBlb3BsZSAoaW5jbHVkaW5nIG15c2VsZikgd2hvIGhhdmUgcmVhZCB0aGUg T0F1dGggc3BlYyBhbmQgY2FtZSBhd2F5IGNvbXBsZXRlbHkgY29uZnVzZWQgYWJvdXQgd2hlbiB0 aGUgaGVjayBvbmUgaXMgc3VwcG9zZWQgdG8gdXNlIHRoZSBpbXBsaWNpdCBncmFudCBmbG93IGZv ci4gSXTigJlzIG5vdCBpbW1lZGlhdGVseSBvYnZpb3VzIHRoYXQgaXTigJlzIGEgd2F5IHRvIHN1 cHBvcnQgc3RhbmRhbG9uZSBicm93c2VyIGJhc2VkIGNsaWVudHMuIENhbiB3ZSBwdXQgaW4gYW4g ZXhhbXBsZSBvciBzb21ldGhpbmcgdG8gbWFrZSBpdCBtb3JlIG9idmlvdXMgd2h5IGl04oCZcyBo ZXJlP+KAnQ0KDQo0LjIuMS4gQXV0aG9yaXphdGlvbiBSZXF1ZXN0OiBDb21tZW50IG9uIHJlZGly ZWN0X3VyaTogIOKAnEdpdmVuIHRoYXQgdGhlIG9ubHkgd2F5IHRvIGlkZW50aWZ5IHRoZSBjbGll bnQgaW4gdGhlIGltcGxpY2l0IGdyYW50IGZsb3cgaXMgdmlhIHRoZSByZWRpcmVjdF91cmksIGhv dyBjYW4gaXQgYmUgb3B0aW9uYWw/4oCdDQoNCjQuMy4gUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQg Q3JlZGVudGlhbHM6IENoYW5nZSDigJxlbmFibGluZyB0aGUgZ3JhbnQgdHlwZSwgYW5kIG9ubHkg d2hlbiBvdGhlciBmbG93c+KAnSB0byDigJxlbmFibGluZyB0aGUgZ3JhbnQgdHlwZSBhbmQgb25s eSB1c2UgaXQgd2hlbiBvdGhlciBmbG93c+KAnS4NCg0KNC4zLiBSZXNvdXJjZSBPd25lciBQYXNz d29yZCBDcmVkZW50aWFsczogQ2hhbmdlIOKAnHJlc291cmNlIG93bmVyIGNyZWRlbnRpYWxz4oCd IHRvIOKAnHJlc291cmNlIG93bmVy4oCZcyBjcmVkZW50aWFsc+KAnS4NCg0KNC4zLjIuIEFjY2Vz cyBUb2tlbiBSZXF1ZXN0OiAgQ29tbWVudCBvbiDigJxhdXRob3JpemF0aW9uIHNlcnZlciBNVVNU IHByb3RlY3QgdGhlIGVuZHBvaW50IGFnYWluc3QgYnJ1dGUgZm9yY2UgYXR0YWNrc+KAnTog4oCc U2hvdWxkbuKAmXQgdGhlIHJlcXVpcmVtZW50IHRvIHByZXZlbnQgYWdhaW5zdCBicnV0ZSBmb3Jj ZSBhdHRhY2tzIGFwcGx5IHRvIGFsbCBjcmVkZW50aWFscywgcmVzb3VyY2Ugb3duZXIgb3Igb3Ro ZXJ3aXNlPyBJbiBvdGhlciB3b3JkcyBpbiBzZWN0aW9uIDIuNC4xIHdlIHRhbGsgYWJvdXQgaG93 IGNsaWVudHMgc3VibWl0IHRoZWlyIG5hbWUvcGFzc3dvcmQuIFNob3VsZG7igJl0IGVuZHBvaW50 cyBhY2NlcHRpbmcgY2xpZW50IG5hbWUvcGFzc3dvcmRzIGhhdmUgdGhlIHNhbWUgcHJvdGVjdGlv bnMgYWdhaW5zdCBicnV0ZSBmb3JjZSBhdHRhY2s/4oCdDQoNCjQuNC4zLiBBY2Nlc3MgVG9rZW4g UmVzcG9uc2U6IENvbW1lbnQgb24g4oCcQSByZWZyZXNoIHRva2VuIFNIT1VMRCBOT1QgYmUgaW5j bHVkZWTigJ06IOKAnFdoeSBpc27igJl0IHRoaXMgYSBNVVNUIE5PVD/igJ0NCg0KNC41LiBFeHRl bnNpb25zOiBDb21tZW50IOKAnElzbuKAmXQgdGhlIHRleHQgaW4gdGhpcyBzZWN0aW9uIGFuZCA4 LjMgcmVkdW5kYW50IHdpdGggZWFjaCBvdGhlcj8gSXQgc2VlbXMgbGlrZSB3ZSBzaG91bGQgdGFr ZSB0aGUgdGV4dCBmcm9tIGhlcmUgYW5kIG1lcmdlIGl0IHdpdGggc2VjdGlvbiA4LjMgc28gYWxs IHRoZSBleHRlbnNpb24gaW5mb3JtYXRpb24gaXMgcmVjb3JkZWQgaW4gb25lIHBsYWNlLiAgSXTi gJlzIGp1c3QgcGxhaW4gdGhhdCBhbGwgb3RoZXIgZXh0ZW5zaW9uIHBvaW50cyBhcmUgaW4gc2Vj dGlvbiA4IGJ1dCB0aGlzIG9uZS7igJ0NCg0KNS4xLiBTdWNjZXNzZnVsIFJlc3BvbnNlOiBDb21t ZW50IG9uIOKAnHBhcmFtZXRlciBhdCB0aGUgaGlnaGVzdCBzdHJ1Y3R1cmUgbGV2ZWzigJ06IOKA nEFyZSB0aGVyZSBhbnkgZ3VhcmFudGVlcyBhYm91dCB0aGUgb3JkZXIgb2YgdGhlIG1lbWJlcnMg aW4gdGhlIEpTT04gb2JqZWN0PyBJZiBub3Qgd2Ugc2hvdWxkIHNheSBzbyBleHBsaWNpdGx5LuKA nQ0KDQo1LjIuIEVycm9yIFJlc3BvbnNlOiBDb21tZW50IG9uIOKAnG11bHRpcGxlIGNsaWVudCBh dXRoZW50aWNhdGlvbnMgaW5jbHVkZWTigJ0gaW4gaW52YWxpZF9jbGllbnQ6IOKAnFNob3VsZG7i gJl0IHRoaXMgYmUgYW4gaW52YWxpZF9yZXF1ZXN0P+KAnQ0KDQo1LjIuIEVycm9yIFJlc3BvbnNl OiBDb21tZW50IG9uIOKAnE51bWVyaWNhbCB2YWx1ZXMgYXJlIGluY2x1ZGVkIGFzIEpTT04gbnVt YmVyc+KAnTog4oCcU2FtZSBpc3N1ZSBhcyBiZWZvcmUsIGRvZXMgb3JkZXJpbmcgbWF0dGVyIGFu ZCBpZiBub3Qgd2UgbmVlZCB0byBzYXkgdGhhdC7igJ0NCg0KOC4xLiBEZWZpbmluZyBBY2Nlc3Mg VG9rZW4gVHlwZXM6IENoYW5nZSDigJxvciB1c2UgYSB1bmlxdWXigJ0gdG8g4oCcb3IgdXNpbmcg YSB1bmlxdWXigJ0uDQoNCjkuICBOYXRpdmUgQXBwbGljYXRpb25zOiAgQ2hhbmdlIOKAnGFuIHNj aGVtZeKAnSB0byDigJxhIHNjaGVtZeKAnQ0KDQo5LiAgTmF0aXZlIEFwcGxpY2F0aW9uczogIENo YW5nZSDigJxvZmZlciBhbiBpbXByb3ZlZCB1c2FiaWxpdHnigJ0gdG8g4oCcb2ZmZXIgaW1wcm92 ZWQgdXNhYmlsaXR54oCdDQoNCjkuICBOYXRpdmUgQXBwbGljYXRpb25zOiAgQ2hhbmdlIOKAnGlu YWJpbGl0eSB0byBrZWVwIGNyZWRlbnRpYWxzIGNvbmZpZGVudGlhbOKAnSB0byDigJxpbmFiaWxp dHkgdG8ga2VlcCBjbGllbnQgY3JlZGVudGlhbHMgY29uZmlkZW50aWFs4oCdLg0KDQo5LiAgTmF0 aXZlIEFwcGxpY2F0aW9uczogIENoYW5nZSDigJxXaGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBncmFu dCB0eXBlIGZsb3cgYSByZWZyZXNoIHRva2VuIGlzIG5vdCByZXR1cm5lZOKAnSB0byDigJxXaGVu IHVzaW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGZsb3cgYSByZWZyZXNoIHRva2VuIGlzIG5v dCByZXR1cm5lZCBzbyBvbmNlIHRoZSBhY2Nlc3MgdG9rZW4gZXhwaXJlcyB0aGUgYXBwbGljYXRp b24gd2lsbCBoYXZlIHRvIHJlcGVhdCB0aGUgYXV0aG9yaXphdGlvbiBwcm9jZXNz4oCdLg0KDQox MC4yLiBDbGllbnQgSW1wZXJzb25hdGlvbjogIENoYW5nZSDigJxrZWVwIGlzIGNsaWVudOKAnSB0 byDigJxrZWVwIGl0cyBjbGllbnTigJ0uDQoNCjEwLjIuIENsaWVudCBJbXBlcnNvbmF0aW9uOiAg Q2hhbmdlIOKAnGR1ZSB0byB0aGUgY2xpZW50IG5hdHVyZeKAnSB0byDigJxkdWUgdG8gdGhlIGNs aWVudOKAmXMgbmF0dXJl4oCdLg0KDQoxMC4yLiBDbGllbnQgSW1wZXJzb25hdGlvbjogIENoYW5n ZSDigJxVUkkgdXNlZCBmb3IgcmVjZWl2aW5nIGF1dGhvcml6YXRpb27igJ0gdG8g4oCcVVJJIHVz ZWQgZm9yIHJlY2VpdmluZyBhdXRob3JpemF0aW9uIHJlcXVlc3Rz4oCdDQoNCjEwLjIuIENsaWVu dCBJbXBlcnNvbmF0aW9uOiAgQ2hhbmdlIOKAnGVuZ2FnZSB0aGUgcmVzb3VyY2Ugb3duZXLigJ0g dG8g4oCcZW5nYWdpbmcgdGhlIHJlc291cmNlIG93bmVy4oCdLg0KDQoxMC4yLiBDbGllbnQgSW1w ZXJzb25hdGlvbjogIENoYW5nZSDigJxhbmQgYXV0aG9yaXplIHRoZSByZXF1ZXN04oCdIHRvIOKA nGFuZCBhdXRob3JpemUgb3IgcmVqZWN0IHRoZSByZXF1ZXN04oCdLg0KDQoxMC4zLiBBY2Nlc3Mg VG9rZW5zOiBDaGFuZ2Ug4oCcQWNjZXNzIHRva2VuIChhcyB3ZWxsIGFzIGFueSBhY2Nlc3MgdG9r ZW4gdHlwZS1zcGVjaWZpYyBhdHRyaWJ1dGVzKeKAnSB0byDigJxBY2Nlc3MgdG9rZW5zIChhcyB3 ZWxsIGFzIGFueSBhY2Nlc3MgdG9rZW4gdHlwZSBzcGVjaWZpYyBhdHRyaWJ1dGVzKeKAnS4NCg0K MTAuMy4gQWNjZXNzIFRva2VuczogQ2hhbmdlIOKAnGd1ZXNzZWQgdG8gcHJvZHVjZeKAnSB0byDi gJxndWVzc2VkIHNvIGFzIHRvIHByZXZlbnQgdW5hdXRob3JpemVkIHBhcnRpZXMgZnJvbSBwcm9k dWNpbmfigJ0uDQoNCjEwLjQuIFJlZnJlc2ggVG9rZW5zOiBDb21tZW50IOKAnEFzIG1lbnRpb25l ZCBwcmV2aW91c2x5IHdlIHJlYWxseSBzaG91bGQgZXhwbGFpbiB3aHkgd2UgaW50cm9kdWNlZCBy ZWZyZXNoIHRva2Vucy4gV2l0aG91dCB1bmRlcnN0YW5kaW5nIHRoZSBpbnRlbnQgb2YgdGhlIG1l Y2hhbmlzbSBpdOKAmXMgdW5saWtlbHkgaW1wbGVtZW50ZXJzIHdpbGwgdXNlIHRoZW0gYXBwcm9w cmlhdGVseS7igJ0NCg0KMTAuNC4gUmVmcmVzaCBUb2tlbnM6ICBDaGFuZ2Ug4oCcc3RvcmFnZSwg YW5kIHNoYXJlZCBvbmx5IGFtb25n4oCdIHRvIOKAnHN0b3JhZ2UsIGFuZCBhcmUgdG8gYmUgc2hh cmVkIG9ubHkgYW1vbmfigJ0uDQoNCjEwLjQuIFJlZnJlc2ggVG9rZW5zOiAgQ2hhbmdlIOKAnHJl ZnJlc2ggdG9rZW5zIHJvdGF0aW9u4oCdIHRvIOKAnHJlZnJlc2ggdG9rZW4gcm90YXRpb27igJ0u DQoNCjEwLjQuIFJlZnJlc2ggVG9rZW5zOiAgQ2hhbmdlIOKAnGd1ZXNzZWQgdG8gcHJvZHVjZeKA nSB0byDigJxndWVzc2VkIHNvIGFzIHRvIHByZXZlbnQgdW5hdXRob3JpemVkIHBhcnRpZXMgZnJv bSBwcm9kdWNpbmfigJ0uDQoNCjEwLjYuIEF1dGhvcml6YXRpb24gQ29kZSBMZWFrYWdlOiBDb21t ZW50IOKAnEkgZmFuY3kgbXlzZWxmIGFzIGJlaW5nIHJlYXNvbmFibHkgaW50ZWxsaWdlbnQgYW5k IEnigJltIHVuY2xlYXIgd2hhdCBhdHRhY2sgaXMgYWN0dWFsbHkgYmVpbmcgZGVzY3JpYmVkIGhl cmUu4oCdDQoNCjEwLjYuIEF1dGhvcml6YXRpb24gQ29kZSBMZWFrYWdlOiBDb21tZW50IG9uIOKA nFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVxdWlyZSB0aGUgY2xpZW50IHRvIHJl Z2lzdGVyIHRoZWlyIHJlZGlyZWN0aW9uIFVSSeKAnTog4oCcV2h5IGlzIHRoaXMgYSBzaG91bGQ/ 4oCdDQoNCjEwLjcuIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzOiBDb21tZW50 IG9uIOKAnHBhc3N3b3JkIGFudGktcGF0dGVybuKAnTog4oCcSXMgaXQgZmFpciB0byBleHBlY3Qg dGhhdCB0aGUgcmVhZGVyIGtub3dzIHdoYXQgdGhlIHBhc3N3b3JkIGFudGktcGF0dGVybiBpcz8g U2hvdWxkbuKAmXQgc29tZSByZWZlcmVuY2UgdG8gYSBkZWZpbml0aW9uIG9mIHRoaXMgcGF0dGVy biBiZSByZXF1aXJlZD/igJ0NCg0KMTAuNy4gUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVu dGlhbHM6IENvbW1lbnQgb24g4oCcVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCByZXN0 cmljdCB0aGUgc2NvcGUgYW5kIGxpZmV0aW1lIG9mIGFjY2VzcyB0b2tlbnMgaXNzdWVkIHZpYSB0 aGlzIGdyYW50IHR5cGXigJ06IOKAnFJlc3RyaWN0IGluIHdoYXQgd2F5cz8gQmFzZWQgb24gd2hh dCBjcml0ZXJpYT8gVGhpcyBzdGF0ZW1lbnQgaXMgdGhlIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIOKA nGRvbuKAmXQgZG8gYmFkIHN0dWZm4oCdLiBQZXJoYXBzIHRydWUgYnV0IG5vdCB0ZXJyaWJseSB1 c2VmdWwu4oCdDQoNCjEwLjEyLiBDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeTogQ29tbWVudCBv biBmaXJzdCBwYXJhZ3JhcGg6IOKAnEkgY2hhbGxlbmdlIGFueSByZWFzb25hYmx5IGludGVsbGln ZW50IHBlcnNvbiB3aG8gZG9lcyBub3QgYWxyZWFkeSBrbm93IHdoYXQgYSBDU1JGIGlzIHRvIHJl YWQgdGhpcyBwYXJhZ3JhcGggYW5kIGNvbWUgYXdheSBhbnkgY2xlYXJlciBhcyB0byB3aGF0IGlz IGJlaW5nIGRpc2N1c3NlZC4gQXQgYSBtaW5pbXVtIGlzbuKAmXQgc29tZSByZWZlcmVuY2UgdG8g YSBjb21wbGV0ZSBkZWZpbml0aW9uIG9mIENTUkYgbmVlZGVkIGlmIHRoZXJlIGlzIHRvIGJlIGFu eSBob3BlIG9mIHVzZXIgY29tcGxpYW5jZT/igJ0NCg0KMTAuMTIuIENyb3NzLVNpdGUgUmVxdWVz dCBGb3JnZXJ5OiBDb21tZW50IG9uIOKAnFRoZSAic3RhdGUiIHJlcXVlc3QgcGFyYW1ldGVyIE1V U1QgY29udGFpbiBhIG5vbi1ndWVzc2FibGUgdmFsdWXigJ06IOKAnEFjdHVhbGx5IGEgbm9uLWd1 ZXNzYWJsZSB2YWx1ZSB3b27igJl0IHN0b3AgdGhlIGF0dGFjayBkaXNjdXNzZWQgaW4gdGhlIHBy ZXZpb3VzIHBhcmFncmFwaCBvbiBpdHMgb3duLiBXaGF04oCZcyBhbHNvIG5lZWRlZCBpcyBhIHdh eSB0byB1bmlxdWVseSAoYW5kIHVuYnJlYWthYmx5KSBhc3NvY2lhdGUgdGhlIHN0YXRlIHdpdGgg YSBwYXJ0aWN1bGFyIHVzZXIgc28gdGhhdCBpZiBhbiBhdXRob3JpemF0aW9uIGNvZGUgc3dhcCBv Y2N1cnMgaXQgY2FuIGJlIHJlbGlhYmx5IGRldGVjdGVkLuKAnQ0KDQoxMC4xMy4gQ2xpY2tqYWNr aW5nOiBDb21tZW50IG9uIOKAnHgtZnJhbWUtb3B0aW9uc+KAnTog4oCcVGhlIHJlY29tbWVuZGF0 aW9uIHNlZW1zIGNvbmZ1c2VkLiBJcyBpdCBvLmsuIHRvIGp1c3QgcmVseSBvbiB4LWZyYW1lLW9w dGlvbnMgb3IgTVVTVCBvdGhlciBhY3Rpb25zIGJlIHRha2VuP+KAnQ0KDQoxMS4xLiAgVGhlIE9B dXRoIEFjY2VzcyBUb2tlbiBUeXBlIFJlZ2lzdHJ5OiBDaGFuZ2Ug4oCcdG9rZSB0eXBl4oCdIHRv IOKAnHRva2VuIHR5cGXigJ0uDQoNCjExLjEuMS4gIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZTogQ2hh bmdlIOKAnHByb3RlY3RlZCByZXNvdXJjZXMgcmVxdWVzdHMgdXNpbmcgYWNjZXNzIHRva2Vu4oCd IHRvIOKAnHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyB1c2luZyBhY2Nlc3MgdG9rZW5z4oCd Lg0KDQoxMS4xLjEuICBSZWdpc3RyYXRpb24gVGVtcGxhdGU6ICBDaGFuZ2Ug4oCcUmVmZXJlbmNl IHRvIGRvY3VtZW504oCdIHRvIOKAnFJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnTigJ0uDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89945SN2PRD0302MB137_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlIGlzIG91dCBvbiB2YWNh dGlvbiB3aXRoIG5vIGFjY2VzcyBhbmQgaGUgbGVmdCBNaWtlIHdpdGggYSBidW5jaCBvZiBjb21t ZW50cyB0byBwdWxsIHRvZ2V0aGVyIHRvIHN1Ym1pdCBhbmQgd2Uga25ldyB0aGF0IHlvdSB3YW50 ZWQgdGhlc2UgY29tbWVudHMgdG8gZW5zdXJlDQogdGhhdCB0aGUgc3BlYyBpcyB0aGUgYmVzdCBp dCBjYW4gYmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyYW4gSGFt bWVyLUxhaGF2PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDEwLCAyMDExIDU6 MTkgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFBhcnRpYWwgc2V0IG9m IGxhc3QgY2FsbCBjb21tZW50cyBvbiBPQXV0aCBkcmFmdCAyMCBmcm9tIFlhcm9uIEdvbGFuZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPklzIHRoZXJlIGEgcmVhc29uIHdoeSBNciBHb2xhbmQg aXNudCBzZW5kaW5nIGhpcyBvd24gY29tbWVudHMgaW4/PGJyPg0KPGJyPg0KT24gQXVnIDEwLCAy MDExLCBhdCAxNzozOSwgJnF1b3Q7TWlrZSBKb25lcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuNC4gQXV0aG9yaXphdGlvbiBHcmFudDogQ2hhbmdlIOKA nHJlc291cmNlIG93bmVyIGF1dGhvcml6YXRpb27igJ0gdG8g4oCccmVzb3VyY2Ugb3duZXLigJlz IGF1dGhvcml6YXRpb27igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLjQuMS4gQXV0 aG9yaXphdGlvbiBDb2RlOiZuYnNwOyBDb21tZW50OiDigJxJdCBzZWVtcyBvZGQgdGhhdCB3ZSBj YW4gZGlzY3VzcyB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIHdpdGhvdXQgYWxzbyBkaXNjdXNzaW5n IHRoZSBzZWN1cml0eSBpc3N1ZXMgaXQgcmFpc2VzIChlLmcuIHBhc3Npbmcgc2VjdXJlIGluZm9y bWF0aW9uDQogdmlhIGEgYnJvd3NlcikgYW5kIHRodXMgbW90aXZhdGluZyB0aGUgaW50cm9kdWN0 aW9uIG9mIHRoZSByZWZyZXNoIHRva2VuLiBJIHdvdWxkIGV4cGVjdCB0aGlzIHRvIGJlIHJlZmVy cmVkIHRvIGhlcmUuJm5ic3A7IEhhdmluZyByZWFkIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBzZWN0aW9uIEkgY2FuIGZpbmQgbm8gY29oZXJlbnQgZGlzY3Vzc2lvbiB0aGVyZSBlaXRoZXIg b2YgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBhdXRob3JpemF0aW9uDQogY29kZSBhbmQg dGhlIHJlZnJlc2ggdG9rZW4gYW5kIHdoeSBvbmUgbW90aXZhdGVkIHRoZSBvdGhlci4gSSB0aGlu ayB0aGlzIGlzIHNvbWV0aGluZyBpbXBvcnRhbnQgZm9yIGltcGxlbWVudGVycyB0byB1bmRlcnN0 YW5kLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS40LjIuJm5ic3A7IEltcGxpY2l0 OiZuYnNwOyBDb21tZW50OiDigJxJIGZpbmQgdGhpcyBzZWN0aW9uIGNvbmZ1c2luZy4gSSB0aGlu ayBhbiBleGFtcGxlIGlzIGFsbCBidXQgbWFuZGF0b3J5IGhlcmUgaWYgdGhlIHJlYWRlciBpcyB0 byB1bmRlcnN0YW5kIHdoYXQgaXMgaW50ZW5kZWQuJm5ic3A7IEZvciBleGFtcGxlLCB3aGVuIEkg Zmlyc3QNCiByZWFkIHRoaXMgc2VjdGlvbiBJIHRob3VnaHQgaXQgd2FzIHNvbWUga2luZCBvZiBz aG9ydCBjdXQgdXNlZCBpbiBjYXNlcyB3aGVyZSB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0aW9u IHNlcnZlciBoYWQgYSBjbG9zZSByZWxhdGlvbnNoaXAgYW5kIGNvdWxkIHNoYXJlIGluZm9ybWF0 aW9uIHN1Y2ggYXMgdGhlIGNsaWVudOKAmXMgaWRlbnRpdHkgc28gbm8gYWNjZXNzIGNvZGUgd2Fz IG5lZWRlZC4mbmJzcDsgTm8gd2hlcmUgaW4gaGVyZSBpcyBhbnkgaGludA0KIHRoYXQgdGhpcyBp cyBhYm91dCBicm93c2VyIGJhc2VkIGNsaWVudHMgd2hvIGRvbuKAmXQgaGF2ZSBzZXJ2ZXJzIGFu ZCB3aG8gbmVlZCBhIHdheSB0byBnZXQgdG9rZW5zLiBTZXJpb3VzbHkuIFRyeSB0byByZWFkIHRo aXMgc2VjdGlvbiBhcyBzb21lb25lIHdobyBrbm93cyBub3RoaW5nIGFib3V0IE9BdXRoIGFuZCB0 ZWxsIG1lIHRoYXQgeW91IGdldCB0aGUgcmlnaHQgaWRlYSBiYWNrIGZyb20gaXQuIEl0IG5lZWRz IHRvIGJlIHdyaXR0ZW4gdG8gYmUNCiBib3RoIGV4cGxpY2l0IGFzIHRvIGl0cyBnb2FscyBhbmQg Y2xlYXJlciBhcyB0byBpdHMgbWVhbnMu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4x LjQuMi4mbmJzcDsgSW1wbGljaXQ6Jm5ic3A7IENoYW5nZSDigJw8c3BhbiBsYW5nPSJFTiI+YXV0 aGVudGljYXRlIHRoZSBjbGllbnQgYW5kIHRoZTwvc3Bhbj7igJ0gdG8g4oCcPHNwYW4gbGFuZz0i RU4iPmF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGRpcmVjdGx5LiBUaGU8L3NwYW4+4oCdLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS40LjIuJm5ic3A7IEltcGxpY2l0OiZuYnNwOyBDaGFu Z2Ug4oCcd2VpZ2h0ZWTigJ0gdG8g4oCcd2VpZ2hlZOKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjEuNC4zLiZuYnNwOyBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFsczog Q29tbWVudCBvbiDigJwod2hlbiBjb21iaW5lZCB3aXRoIGEgcmVmcmVzaCB0b2tlbinigJ06IOKA nFRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhhdCByZWZyZXNoIHRva2VucyBhcmUgbWVudGlvbmVk IGluIHRoZSBzcGVjLiBBbmQgeWV0IHRoZXJlDQogaXMgbm8gZXhwbGFuYXRpb24gb2Ygd2hhdCB0 aGV5IGFyZS4gSSBzdXNwZWN0IHRoZXkgc2hvdWxkIGFueXdheSBiZSBpbnRyb2R1Y2VkIGluIHNl Y3Rpb24gMS40LjEgKGFzIHByZXZpb3VzbHkgbm90ZWQpIGFuZCB0aGVuIHRoZWlyIHVzZSBoZXJl IHdpbGwgbWFrZSBzZW5zZS4mbmJzcDsgSWYgdGhhdCBpc27igJl0IHBvc3NpYmxlIHRoZW4gaXQg d291bGQgYmUgZ29vZCB0byBoYXZlIGEgZm9yd2FyZCByZWZlcmVuY2UgdG8gc2VjdGlvbiAxLjUg YmVsb3cgc28NCiB0aGUgcmVhZGVyIGhhcyBzb21lIGlkZWEgb2Ygd2hhdOKAmXMgZ29pbmcgb24u 4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLjQuNC4mbmJzcDsgQ2xpZW50IENyZWRl bnRpYWxzOiZuYnNwOyBDb21tZW50IG9uIOKAnCh0aGUgY2xpZW50IGlzIGFsc28gdGhlIHJlc291 cmNlIG93bmVyKeKAnTog4oCcSSB0aGluayB0aGlzIGlzIG1pc2xlYWRpbmcuIEltYWdpbmUgc29t ZXRoaW5nIGxpa2UgT2ZmaWNlIHdoZXJlIGEgY2xpZW50IGhhcyBiZWVuIGdyYW50ZWQgYWNjZXNz DQogdG8gYSBwYXJ0aWN1bGFyIHJlc291cmNlIGJ5IHRoZSByZXNvdXJjZSBvd25lci4gVGhlIGNs aWVudCBjYW4gdGhlbiBhc2sgZm9yIGFuIGFjY2VzcyB0b2tlbiB0byB0aGUgcmVzb3VyY2UgdXNp bmcgdGhlIGNsaWVudCBjcmVkZW50aWFscyBhbmQgbm8gYWNjZXNzIGNvZGUgb3IgcmVmcmVzaCB0 b2tlbi4gSnVzdCBoYXZpbmcgdGhlIGFkZHJlc3Mgb2YgdGhlIGludGVuZGVkIHJlc291cmNlIChw cm9iYWJseSBwcm92aWRlZCB2aWEgU0NPUEUpIGFsb25nDQogd2l0aCB0aGUgY2xpZW50IGNyZWRl bnRpYWxzIGlzIG1vcmUgdGhhbiBlbm91Z2ggdG8gZGVjaWRlIGlmIGFuIGFjY2VzcyB0b2tlbiBz aG91bGQgYmUgaXNzdWVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkgcG9pbnQgaXMg dGhhdCB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIHNjZW5hcmlvIGlzIGZ1bGx5IGFwcGxpY2FibGUg dG8gY2FzZXMgd2hlcmUgdGhlIGNsaWVudCBpcyBub3QgdGhlIHJlc291cmNlIG93bmVyIGJ1dCBp biB3aGljaCB0aGUgcmVzb3VyY2UgVVJJIHByb3ZpZGVzIGFsbCB0aGUgY29udGV4dCBuZWVkZWQN CiB0byBkZXRlcm1pbmUgaWYgdGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byBnZXQgYW4gYWNj ZXNzIHRva2VuLiBJIHRoaW5rIHRoZSBjdXJyZW50IHRleHQgd291bGQgaW1wbHkgb3RoZXJ3aXNl Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TbyBJIHdvdWxkIHByb3Bvc2UgY2hhbmdp bmcgdGhlIHNlbnRlbmNlIHRvIOKAnENsaWVudCBjcmVkZW50aWFscyBhcmUgdXNlZCBhcyBhbiBh dXRob3JpemF0aW9uIGdyYW50IHdoZW4gdGhlIGNsaWVudCBpcyBhY3Rpbmcgb24gaXRzIG93biBi ZWhhbGYgKHRoZSBjbGllbnQgaXMgYWxzbyB0aGUgcmVzb3VyY2Ugb3duZXIpDQogb3Igd2hlbiB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaGFzIGVub3VnaCBjb250ZXh0IHRvIGRldGVybWluZSBm cm9tIHRoZSBhY2Nlc3MgdG9rZW4gcmVxdWVzdCBpZiB0aGUgY2xpZW50IGhhcyBhdXRob3JpemF0 aW9uIHRvIGFjY2VzcyB0aGUgcmVxdWVzdGVkIHJlc291cmNlLuKAneKAnTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+MS40LjUuIEV4dGVuc2lvbnM6IENvbW1lbnQ6IOKAnEkgd291bGQgY2hh bmdlIHRoaXMgc2VudGVuY2UgdG8gcmVhZCDigJxBZGRpdGlvbmFsIGdyYW50IHR5cGVzIG1heSBi ZSBkZWZpbmVkIHRvIHN1cHBvcnQgbmV3IGFwcHJvYWNoZXMgdG8gYXV0aGVudGljYXRpb24vYXV0 aG9yaXphdGlvbiBhcyB3ZWxsIGFzIHRvDQogcHJvdmlkZSBhIGJyaWRnZSBiZXR3ZWVuIE9BdXRo IGFuZCBvdGhlciBwcm90b2NvbHMu4oCd4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4x LjUuIFJlZnJlc2ggVG9rZW46IENvbW1lbnQgb24g4oCcUmVmcmVzaCB0b2tlbnMgYXJlIGNyZWRl bnRpYWxzIHVzZWQgdG8gb2J0YWluIGFjY2VzcyB0b2tlbnMu4oCdOiDigJxUaGlzIHNlbnRlbmNl IHByZXN1bWVzIHRoYXQgcmVmcmVzaCB0b2tlbnMgYXJlIHNlbGYtY29udGFpbmVkIGNyZWRlbnRp YWxzLiBJbiBvdGhlcg0KIHdvcmRzIHRoYXQgb25lIGNhbiBnZXQgYW4gYWNjZXNzIHRva2VuIGp1 c3QgdXNpbmcgYSByZWZyZXNoIHRva2VuIGFuZCBub3RoaW5nIGVsc2UuIFRoaXMgcHJlc3VtcHRp b24gaXMgcmVidXR0ZWQgbGF0ZXIgaW4gdGhlIGRvY3VtZW50IGJ1dCBJIHRoaW5rIGl04oCZcyBj b25mdXNpbmcgdG8gaW1wbHkgb25lIHRoaW5nIGhlcmUgYW5kIHN0YXRlIG90aGVyd2lzZSBsYXRl ciBvbi7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuNS4gUmVmcmVzaCBUb2tlbjog Q2hhbmdlIOKAnDxzcGFuIGxhbmc9IkVOIj5hIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0czwv c3Bhbj7igJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPmEgcHJvdGVjdGVkIHJlc291cmNlIHJlcXVl c3Q8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS41LiBSZWZyZXNoIFRv a2VuOiBDb21tZW50IG9uIOKAnDxzcGFuIGxhbmc9IkVOIj4oRykmbmJzcDsgVGhlIGNsaWVudCBy ZXF1ZXN0cyBhIG5ldyBhY2Nlc3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHByZXNlbnRpbmcgdGhlIHJlZnJlc2ggdG9rZW4uPC9zcGFu PuKAnToNCiDigJxIdW3igKYgbm93IHRoZSB0ZXh0IHNlZW1zIHRvIGNvbnRyYWRpY3QgaXRzZWxm LiBBYm92ZSBpdCBzZWVtZWQgbGlrZSB5b3UgY291bGQgdXNlIHRoZSByZWZyZXNoIHRva2VuIGJ5 IGl0c2VsZiB0byBnZXQgYW4gYWNjZXNzIHRva2VuIGFuZCBJIGhhZCB0byBhc2sgZm9yIGxhbmd1 YWdlIHRoYXQgbWFkZSBpdCBjbGVhciB0aGF0IHlvdSBjb3VsZCB1c2UgYSByZWZyZXNoIHRva2Vu IHdpdGggb3RoZXIgY3JlZGVudGlhbHMuJm5ic3A7IEJ1dCB0aGUgdGV4dCBvZg0KIHBvaW50IEcg bm93IGltcGxpZXMgdGhlIGV4YWN0IG9wcG9zaXRlLCB0aGF0IHJlZnJlc2ggdG9rZW5zIGNhbiBv bmx5IGJlIHVzZWQgd2l0aCBvdGhlciBjcmVkZW50aWFscyBhbmQgbm90IGJ5IHRoZW1zZWx2ZXMu IChFdmVuIHRob3VnaCB0aGUgcGljdHVyZSBpbiBmaWd1cmUgMiBmb3Igc3RlcCBHIGltcGxpZXMg dGhlIG9wcG9zaXRlKS4gSSB3b3VsZCBlZGl0IHRoaXMgbGFuZ3VhZ2UgdG8gc2F5IOKAnFRoZSBj bGllbnQgcmVxdWVzdHMgYSBuZXcgYWNjZXNzDQogdG9rZW4uIERlcGVuZGluZyBvbiB0aGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXLigJlzIHBvbGljaWVzIHRoaXMgcmVxdWVzdCBtaWdodCBiZSBtYWRl IHdpdGggdGhlIHJlZnJlc2ggdG9rZW4gYnkgaXRzZWxmIG9yIHdpdGggYSBjb21iaW5hdGlvbiBv ZiB0aGUgcmVmcmVzaCB0b2tlbiBhbmQgb3RoZXIgY2xpZW50IGNyZWRlbnRpYWxzLuKAneKAnTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Mi4xLiBDbGllbnQgVHlwZXM6IENvbW1lbnQgb24g 4oCcdXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbuKAnTog4oCcR2l2ZSB0aGUgcG9vciByZWFk ZXIgYSBoaW50IGFuZCBtZW50aW9uIOKAmGJyb3dzZXLigJkgc29tZXdoZXJlIGluIHRoZSBwYXJh Z3JhcGggYmVsb3cuIEZvciBleGFtcGxlIOKAnEEgdXNlci1hZ2VudC1iYXNlZA0KIGFwcGxpY2F0 aW9uIGlzIGEgcHVibGljIGNsaWVudCAoc3VjaCBhcyBhIHdlYiBicm93c2VyKSBpbiB3aGljaCB0 aGXigKYu4oCd4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yLjEuIENsaWVudCBUeXBl czogd2ViIGFwcGxpY2F0aW9uOiBDaGFuZ2Ug4oCcYWNjZXNzIHRva2VucyBvciByZWZyZXNoIHRv a2VucywgY2FuIHJlY2VpdmUgYW4gYWNjZXB0YWJsZSBsZXZlbOKAnSB0byDigJxhY2Nlc3MgdG9r ZW5zIG9yIHJlZnJlc2ggdG9rZW5zLCBjYW4sIGluIHNvbWUgY2FzZXMsIHJlY2VpdmUgYW4NCiBh Y2NlcHRhYmxlIGxldmVs4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Mi40LiBDbGll bnQgQXV0aGVudGljYXRpb246Jm5ic3A7IEFkZCBhIHBlcmlvZCBhZnRlciDigJxldGPigJ0uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yLjQuMS4gQ2xpZW50IFBhc3N3b3JkOiBDb21tZW50 IG9uIOKAnGNoYXJzZXQ9VVRGLTjigJ06IOKAnFRoZSB1c2Ugb2YgVVRGLTggd2l0aCB4LXd3dy1m b3JtLXVybGVuY29kZWQgaXMgZXhwbGljaXRseSBiYW5uZWQgYnkgSFRNTCA0LjAxIHNlY3Rpb24g MTcuMTMuMS4gSWYgd2Ugd2FudCB0byB1c2UgVVRGLTggdGhlbg0KIHdlIGhhdmUgdG8gdXNlIG11 bHRpcGFydC9mb3JtLWRhdGEsIGFsc28gZGVmaW5lZCBieSBIVE1MIDQuMDEgKHNlY3Rpb24gMTcu MTMuNCkuIEJ1dCBzaW5jZSBub2JvZHkgd291bGQgYWN0dWFsbHkgd2FudCB0byBkbyB0aGF0IEkg d291bGQgc3VnZ2VzdCBwdXR0aW5nIGluIGEgcmVmZXJlbmNlIHRvIHNlY3Rpb24gNC4yIG9mIFJG QyA1NTUyIHdoaWNoIGFjdHVhbGx5IGRlZmluZXMgaG93IHRvIHVzZSBVVEYtOCB3aXRoIHgtd3d3 LWZvcm0tdXJsZW5jb2RlZA0KIGFuZCBzcGVjaWZ5aW5nIHRoYXQgdGhlIDU1NTIgZXh0ZW5zaW9u IE1VU1QgYmUgc3VwcG9ydGVkIGJ5IE9BdXRoIHBhcnRpY2lwYW50cy7igJ08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjMuMS4mbmJzcDsgQXV0aG9yaXphdGlvbiBFbmRwb2ludDogQ29tbWVu dCBvbiBmaXJzdCBzZW50ZW5jZTombmJzcDsg4oCcVGhlcmUgaXMgYSB0aGlyZCBvcHRpb24g4oCT IG5vbmUgb2YgdGhlIGFib3ZlLiAmbmJzcDtJdCB3b3VsZCBiZSBhIHNoYW1lIGlmIHRoZSB0ZXh0 IG9mIHRoaXMgZHJhZnQgZXhwbGljaXRseSBwcm9oaWJpdHMgdGhhdA0KIHBhdHRlcm4u4oCdPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zLjEuJm5ic3A7IEF1dGhvcml6YXRpb24gRW5kcG9p bnQ6Jm5ic3A7IENvbW1lbnQgb24g4oCcW1JGQzM5ODZdIHNlY3Rpb24gM+KAnTog4oCcU2hvdWxk buKAmXQgd2UgcG9pbnQgZGlyZWN0bHkgdG8gc2VjdGlvbiAzLjQgd2hpY2ggZXhhY3RseSBkZWZp bmVzIHRoZSBxdWVyeSBjb21wb25lbnQ/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4z LjEuJm5ic3A7IEF1dGhvcml6YXRpb24gRW5kcG9pbnQ6Jm5ic3A7IENvbW1lbnQgb24g4oCcTVVT VCBiZSByZXRhaW5lZCB3aGVuIGFkZGluZyBhZGRpdGlvbmFsIHF1ZXJ5PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyBwYXJhbWV0ZXJz4oCdOiDigJxI SUdIIElNUE9SVEFOQ0Ug4oCTIFRoaXMgc3BlY2lmaWNhdGlvbiBpcyBpbmNvbXBsZXRlLiBTZWN0 aW9uIDMuNCBvZiBSRkMgMzk4NiBzaW1wbHkgYXNzZXJ0cyB0aGUgZXhpc3RlbmNlIG9mIGEgcXVl cnkgY29tcG9uZW50LiBJdCBzYXlzIG5vdGhpbmcgYWJvdXQgdGhlIHN5bnRheA0KIG9mIHRoYXQg Y29tcG9uZW50LiBUaGUgc3BlYyBhc3N1bWVzIHRoYXQgdGhlIGNvbXBvbmVudCBpcyB1c2luZyB4 LXd3dy1mb3JtLXVybGVuY29kZWQgYnV0IHRoYXQgaXMgbm90IGluIGFueSB3YXkgbWFuZGF0ZWQg YnkgUkZDIDM5ODYuIFNvIHRoZXJlIGlzIGEgbm9ybWF0aXZlIHNlbnRlbmNlIG1pc3NpbmcgaGVy ZSB3aGljaCBzdGF0ZXMgdGhhdCBhbnkgcXVlcnkgcGFyYW1ldGVyIG9uIHRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW504oCZcyBVUkkgTVVTVA0KIGJlIGRlZmluZWQgYXMgc3BlY2lmaWVkIGluIHgt d3d3LWZvcm0tdXJsZW5jb2RlZC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuMS4m bmJzcDsgQXV0aG9yaXphdGlvbiBFbmRwb2ludDombmJzcDsgQ29tbWVudCBvbiDigJxUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGlnbm9yZSB1bnJlY29nbml6ZWQgcmVxdWVzdCBwYXJh bWV0ZXJzLuKAnTog4oCcQWx0aG91Z2ggdGhhdCBpcyBub3JtYWwgYmVoYXZpb3IgZm9yIGFwcGxp Y2F0aW9uIHByb3RvY29scw0KIGl0IHNlZW1zIHJhdGhlciBkYW5nZXJvdXMgZm9yIGEgc2VjdXJp dHkgcHJvdG9jb2wuIEFmdGVyIGFsbCB3aGF0IGlmIHRoZSBjbGllbnQgcHV0IGluIGEgcGFyYW1l dGVyIHNwZWNpZnlpbmcgc29tZXRoaW5nIHNlY3VyaXR5IHJlbGF0ZWQgYWJvdXQgdGhlIHJlcXVl c3QgdGhpbmtpbmcgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB3b3VsZCBob25vciBp dCBhbmQgdGhlbiB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBzaWxlbnRseQ0KIGlnbm9yZXMg aXQ/Jm5ic3A7IEFnYWluLCB0aGlzIGlzIGEgc2VjdXJpdHkgcHJvdG9jb2wsIG5vdCBhIGdlbmVy aWMgYXBwbGljYXRpb24gcHJvdG9jb2wsIGl0IHNlZW1zIHRvIGJlIHRoYXQgdW5yZWNvZ25pemVk IHBhcmFtZXRlcnMgc2hvdWxkIGNhdXNlIGEgZmFpbHVyZS7igJ08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjMuMS4yLiZuYnNwOyBSZWRpcmVjdGlvbiBFbmRwb2ludDogQ29tbWVudCBvbiDi gJx3aGVuIGluaXRpYXRpbmcgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdOKAnTog4oCcSSB3b3Vs ZCBzdWdnZXN0IG1vcmUgZXhwbGljaXQgbGFuZ3VhZ2Ug4oCcb3IgYXMgc3BlY2lmaWVkIGluIHRo ZSByZWRpcmVjdGlvbiBVUkkgdmFsdWUgaW4gdGhlDQogYXV0aG9yaXphdGlvbiByZXF1ZXN0LuKA neKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+My4xLjIuMi4gUmVnaXN0cmF0aW9uIFJl cXVpcmVtZW50czogQ29tbWVudCBvbiBsYXN0IHdvcmQg4oCccGF0aOKAnTog4oCcSHVoPyBTY2hl bWUsIGF1dGhvcml6YXRpb24gYW5kIHBhdGggaXMgYSBjb21wbGV0ZSBVUkkgbWludXMgYSBxdWVy eSBjb21wb25lbnQuJm5ic3A7IElzIHRoZSBnb2FsIHRvIHNwZWNpZmljYWxseSBtYW5kYXRlDQog dGhhdCBvbmx5IHRoZSBxdWVyeSBjb21wb25lbnQgY2FuIHZhcnkgYW5kIHRoZSByZXN0IG9mIHRo ZSBVUkkgTVVTVCBiZSBzdGF0aWM/IElmIHNvIHRoYXQgc2hvdWxkIGJlIHN0YXRlZCBleHBsaWNp dGx5IHJhdGhlciB0aGFuIGltcGxpY2l0bHkgYXMgaXQgaXMgbm93LiZuYnNwOyBCdXQgSSB0aGlu aywgaWYgdGhhdCBpcyB0aGUgaW50ZW50LCBpdCBnb2VzIHRvbyBmYXIuIFdlIHNob3VsZCBhbHNv IGFsbG93IGZvciBhZGRpdGlvbmFsIHBhdGggc2VnbWVudHMNCiB0byBiZSBhZGRlZCB0byB0aGUg VVJJIHBhdGggYmV5b25kIHRoZSByZWdpc3RlcmVkIHByZWZpeC4gQXNzdW1pbmcgd2UgY2FuIGFk ZHJlc3MgdGhlIHNlY3VyaXR5IHByb2JsZW0gaW4gdGhlIG5leHQgY29tbWVudC7igJ08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuMS4yLjMuIER5bmFtaWMgQ29uZmlndXJhdGlvbjogQ29t bWVudCBvbiDigJxzZWN0aW9uIDbigJ06Jm5ic3A7IOKAnFRoZSByZWZlcmVuY2UgdG8gc2VjdGlv biA2IGlzIGluY29tcGxldGUuIFNlY3Rpb24gNiBkZWZpbmVzIG5vIGxlc3MgdGhhbiA2IGRpZmZl cmVudCBheGlz4oCZcyBvbiB3aGljaCBVUkkgY29tcGFyaXNvbnMgY2FuDQogdmFyeS4gRnVydGhl cm1vcmUgYXMgcmVjZW50bHkgZG9jdW1lbnRlZCBpbiBkcmFmdC10aGFsZXItaWFiLWlkZW50aWZp ZXItY29tcGFyaXNvbi0wMC50eHQgaXQgaXMgdHJpdmlhbGx5IGVhc3kgdG8gc2NyZXcgdXAgVVJJ IGNvbXBhcmlzb25zIGFuZCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIGFyZSBwcmV0dHkgZGly ZS4gUGVyc29uYWxseSBJIHRoaW5rIHRoYXQgdGhlIG9ubHkgc2FuZSBhcHByb2FjaCBnaXZlbiB0 aGUgaXNzdWVzIGluIHRoZQ0KIHByZXZpb3VzIGxpbmsgaXMgdG8gYWRvcHQgc2VjdGlvbiA2LjIu MSBvZiBSRkMgMzk4Ni48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYW0gYSBiaXQgc2Nh cmVkIG9mIGhvdyB0byBoYW5kbGUgcGFydGlhbCBtYXRjaGVzLiBJdOKAmXMgdGVtcHRpbmcgdG8g YXJndWUgdGhhdCBzbyBsb25nIGFzIHRoZSBzY2hlbWEgaGFzIGFuIGF1dGhvcml0eSBhbmQgYXQg bGVhc3Qgb25lIHBhdGggc2VnbWVudCB0aGVuIHdlIGNhbiBqdXN0IHVzZSBhIHBhcnRpYWwNCiBz dHJpbmcgbWF0Y2ggYnV0IGJveSBvaCBib3kgZG8gSSBzZWUgcGVvcGxlIHNjcmV3aW5nIHRoYXQg b25lIHVwIHJveWFsbHkuIFRoaXMgaXMgc2NhcnkgZW5vdWdoIHRoYXQgSSB0aGluayBJIGNhbiBi ZSBhcmd1ZWQgaW50byBzYXlpbmcgdGhhdCBwYXJ0aWFsIHByZS1yZWdpc3RlcmVkIFVSSXMgTVVT VCBvbmx5IGRpZmZlciBieSB0aGUgcXVlcnkgY29tcG9uZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SW4gYW55IGNhc2UgdGhpcyBpc3N1ZXMgbmVlZHMgdG8gYmUgZXhwbGljaXRseSBj YWxsZWQgb3V0IGZvciBhbGwgVVJJIGNvbXBhcmlzb25zIHJlcXVpcmVkIGJ5IHRoZSBzcGVjIGFu ZCBub3JtYXRpdmVseSBkZWZpbmVkLiBPdGhlcndpc2Ugd2Ugd2lsbCBlbmQgdXAgd2l0aCBhbGwg dGhlIHNlY3VyaXR5IGlzc3Vlcw0KIGluIERhdmXigJlzIElELuKAnTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+My4xLjIuNC4mbmJzcDsgSW52YWxpZCBFbmRwb2ludDogQ29tbWVudCBvbiDi gJxvcGVuIHJlZGlyZWN0b3LigJ06IOKAnEhvdyBtYW55IHBlb3BsZSBldmVuIGtub3cgd2hhdCB0 aGUgaGVjayBhbiBvcGVuIHJlZGlyZWN0b3IgaXM/IEkgdGhpbmsgd2UgbmVlZCBhIHNlY3Rpb24g aW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQogc2VjdGlvbiB0aGF0IGRlZmluZXMgd2hh dCBhbiBvcGVuIHJlZGlyZWN0b3IgaXMgYW5kIHdoeSBpdOKAmXMgYmFkLiBBbHRlcm5hdGl2ZWx5 IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhIGNvbXBsZXRlIGRlZmluaXRpb24gc29tZXdoZXJl IGVsc2UgaXMgYWxzbyBmaW5lLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+My4yLjEu IENsaWVudCBBdXRoZW50aWNhdGlvbjogQ2hhbmdlIOKAnFJlY292ZXJ54oCdIHRvIOKAnFJlY292 ZXJpbmfigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zLjIuMS4gQ2xpZW50IEF1dGhl bnRpY2F0aW9uOiBDaGFuZ2Ug4oCcY3JlZGVudGlhbHMsIGJ5IHByZXZlbnRpbmcgYW4gYXR0YWNr ZXIgZnJvbSBhYnVzaW5n4oCdIHRvIOKAnGNyZWRlbnRpYWxzLiBUaGlzIHByZXZlbnRzIGFuIGF0 dGFja2VyIGZyb20gYWJ1c2luZ+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+My4yLjEu IENsaWVudCBBdXRoZW50aWNhdGlvbjogQ2hhbmdlIOKAnHBlcmlvZGljIGNyZWRlbnRpYWxzIHJv dGF0aW9u4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5wZXJpb2RpYyBjcmVkZW50aWFsIHJvdGF0 aW9uPC9zcGFuPuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuMi4xLiBDbGllbnQg QXV0aGVudGljYXRpb246IENvbW1lbnQgb24g4oCcd2hpbGUgcm90YXRpb24gb2YgYSBzaW5nbGUg c2V0IG9mIGNsaWVudCBjcmVkZW50aWFscyBpcyBzaWduaWZpY2FudGx5IGVhc2llcuKAnTog4oCc VGhlIHNwZWMgY2FsbHMgb3V0IHJvdGF0aW9uIG9mIGNyZWRlbnRpYWxzIGFzIGJlaW5nIGNydWNp YWwNCiBidXQgdGhlbiBkb2VzbuKAmXQgZGVmaW5lIGhvdyB0aGlzIGlzIHRvIGJlIGRvbmU/IFRo YXQgc2VlbXMga2luZCBvZiBvZGQuIFNob3VsZG7igJl0IHdlIGRlZmluZSBhbiBlbmRwb2ludCB3 aGVyZSBvbmUgY2FuIHN1Ym1pdCBvbmXigJlzIG9sZCBidXQgdW5leHBpcmVkIGNyZWRlbnRpYWxz IGZvciBuZXcgb25lcz8gVGhpcyBzdGlsbCBsZWF2ZXMgdGhlIGVkZ2UgY2FzZSBvZiB3aGF0IHRv IGRvIGlmIHRoZSBvbGQgY3JlZGVudGlhbHMgaGF2ZSBleHBpcmVkDQogYW5kIG5ldyBvbmVzIGhh dmVu4oCZdCBiZWVuIGlzc3VlZCBidXQgdGhhdCBpcyB1bmF2b2lkYWJsZSBhbmQgaW4gdGhhdCBj YXNlIHdlIGNhbiByZXF1aXJlIG91dCBvZiBzY29wZSBhY3Rpb24u4oCdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj40LjEuIEF1dGhvcml6YXRpb24gQ29kZTogQ29tbWVudCBvbiBmaXJzdCDi gJxe4oCdOiDigJxTaG91bGRu4oCZdCB0aGlzIGJlIGEgdiBjaGFyYWN0ZXIgYW5kIG5vdCBhIF4/ IFRoaXMgd291bGQgbWFrZSBpdCBjb25zaXN0ZW50IHdpdGggQSB3aGljaCBhbHNvIGNyb3NzZXMg dHdvIGJveGVzIGFuZCBwb2ludHMgaW4gdGhlDQogc2FtZSBkaXJlY3Rpb24u4oCdPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj40LjEuIEF1dGhvcml6YXRpb24gQ29kZTogQ2hhbmdlIOKAnElm IHZhbGlkLCByZXNwb25kcyBiYWNrIHdpdGggYW4gYWNjZXNzIHRva2Vu4oCdIHRvIOKAnElmIHRo ZSByZXF1ZXN0IGlzIHZhbGlkLCB0aGVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHJl c3BvbmRzIGJhY2sgd2l0aCBhbiBhY2Nlc3MgdG9rZW4NCiBhbmQgb3B0aW9uYWxseSBhIHJlZnJl c2ggdG9rZW7igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40LjEuMi4mbmJzcDsgQXV0 aG9yaXphdGlvbiBSZXNwb25zZTogQ29tbWVudCDigJxUaGUgbGFuZ3VhZ2UgYXJvdW5kIHNjb3Bl cyBpbiB0aGUgZG9jdW1lbnQgaXMgcmVhbGx5IGZydXN0cmF0aW5nLiBPbmUgb25seSBmaW5kcyBv dXQgbXVjaCBsYXRlciBpbiB0aGUgZG9jdW1lbnQgdGhhdCBpdCBpcyBwZXJmZWN0bHkgYWxsb3dh YmxlDQogZm9yIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIG1vcmUgb3IgbGVzcyBpZ25vcmUg d2hhdCBzY29wZXMgYXJlIHN1Ym1pdHRlZCBhbmQgaW5zdGVhZCB0byBqdXN0IHJldHVybiB3aGF0 ZXZlciB0aGUgaGVsbCB0aGV5IHdhbnQuIFRoaXMgaXMgYSBmaW5lIGRlc2lnbiBjaG9pY2UgYnV0 IGl0IHNlZW1zIGxpa2UgdGhlIHNvcnQgb2YgdGhpbmcgdGhhdCBzaG91bGQgYmUgZm9yY2VmdWxs eSByZXBlYXRlZCBhbnl3aGVyZSBpbiB0aGUgc3BlYyB0aGF0DQogd2UgYWxsb3cgcGVvcGxlIHRv IHN1Ym1pdCBzY29wZXMgc28gbm9ib2R5IGZvcmdldHMu4oCdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj40LjEuMi4mbmJzcDsgQXV0aG9yaXphdGlvbiBSZXNwb25zZTogQ29tbWVudCBvbiDi gJxzdGF0ZeKAnTog4oCcRG9u4oCZdCB3ZSBoYXZlIHRvIHByb3ZpZGUgc29tZSBndWlkYW5jZSBv biBob3cgbGFyZ2UgdGhlIHN0YXRlIHZhbHVlIGNhbiBzYWZlbHkgYmU/IE90aGVyd2lzZSB3ZSBh cmUgYXNraW5nIGNsaWVudHMgdG8gcmV3cml0ZQ0KIHRoZWlyIHN0YXRlIG1lY2hhbmlzbXMgZXZl cnkgdGltZSB0aGV5IHRocm93IGluIHN1cHBvcnQgZm9yIGEgbmV3IHByb3RlY3RlZCByZXNvdXJj ZSBzZXJ2ZXIuIFdlIGhhdmUgdG8gc2V0IGV4cGVjdGF0aW9ucyBhY3Jvc3MgdGhlIGluZHVzdHJ5 IGlmIHdlIGFyZSB0byBob3BlIGZvciBhY3R1YWwgaW50ZXJvcGVyYWJpbGl0eS7igJ08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuMS4yLjEuIEVycm9yIFJlc3BvbnNlOiBDb21tZW50IG9u IOKAnFVURi04IGVuY29kZWQgdGV4dOKAnTog4oCcSSB0aGluayBqdXN0IHNheWluZyBVVEYtOCBl bmNvZGVkIHRleHQgY2FuIGJlIG1pc2xlYWRpbmcuIEl04oCZcyBub3QgbGVnYWwgdG8gcHV0IFVU Ri04IGNoYXJhY3RlcnMgaW50byBhIHgtd3d3LWZvcm0tdXJsZW5jb2RlZA0KIHVzZWQgaW4gYSBH RVQgKGFzIGRlZmluZWQgYnkgc2VjdGlvbiAxNy4xMy4xIG9mIEhUTUwgNC4wMSkuIFNvIHdoYXQg eW91IGhhdmUgdG8gZG8gaXMgdGFrZSB0aGUgVVRGLTggU3RyaW5nIGFuZCB0aGVuIFVSTCBlbmNv ZGUgaXQuIFdoaWNoIGlzIGZpbmUgYnV0IHdlIHNob3VsZCBjYWxsIHRoaXMgb3V0LiZuYnNwOyBO b3RlIHRoYXQgdGhpcyBpcyBhIHNlcGFyYXRlIGlzc3VlIHRoYW4gVVRGLTggc3VwcG9ydCBmb3Ig eC13d3ctZm9ybS11cmxlbmNvZGVkLg0KIFRoYXQgaXNzdWUgb25seSBhcHBsaWVzIHdoZW4gdGhl IGZvcm0gaXMgaW4gdGhlIHJlcXVlc3QgYm9keS4gSW4gdGhpcyBzY2VuYXJpbyB0aGUgZm9ybSBp cyBpbiBhIFVSTC4gVGhlcmUgaXMgbm8gcXVlc3Rpb24gdGhhdCBVUkxzIGluIEhUVFAgcmVxdWVz dCBsaXN0cyBkb27igJl0IHN1cHBvcnQgVVRGLTgu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj40LjEuMy4gQWNjZXNzIFRva2VuIFJlcXVlc3Q6IENoYW5nZSDigJw8c3BhbiBsYW5nPSJF TiI+Rm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxvd2luZyBIVFRQIHVzaW5n PC9zcGFuPuKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+Rm9yIGV4YW1wbGUsIGlmIHRoZSBjbGll bnQgbWFrZXMgdGhlIGZvbGxvd2luZw0KIEhUVFAgcmVxdWVzdCB1c2luZzwvc3Bhbj7igJ08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuMS4zLiBBY2Nlc3MgVG9rZW4gUmVxdWVzdDogQ29t bWVudCBvbiDigJx0aGF0IHRoZWlyIHZhbHVlcyBhcmUgaWRlbnRpY2Fs4oCdOiDigJxUaGlzIHZl cmJpYWdlIGlzbuKAmXQgbXVjaCB1c2UsIGZvciBleGFtcGxlLCBpZiB0aGUgY2xpZW50IGNhbiBh bHdheXMgc2VuZCB0aGUgc2FtZSByZWRpcmVjdF91cmkuIFNvLCBqdXN0DQogdG8gYmUgY2xlYXIs IHRoaXMgdGV4dCBoZXJlIGRvZXNu4oCZdCBpbiBhbnl3YXkgY2hhbmdlIG15IHByZXZpb3VzIHJl Y29tbWVuZGF0aW9uIHJlZ2FyZGluZyB0aGUgYXR0YWNrIHByZXZpb3VzbHkgZGVzY3JpYmVkLuKA nTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NC4xLjQuIEFjY2VzcyBUb2tlbiBSZXNwb25z ZTogQ29tbWVudCBvbiDigJwmcXVvdDt0b2tlbl90eXBlJnF1b3Q7OiZxdW90O2V4YW1wbGUmcXVv dDvigJ06IOKAnEp1c3QgdG8gcHJldmVudCBhbnkgY29uZnVzaW9uIGl0IHdvdWxkIGJlIGdvb2Qg dG8gYWN0dWFsbHkgZGVmaW5lIHRoZSB0b2tlbl90eXBlIOKAnGV4YW1wbGXigJ0gaW4gdGhpcyBk b2N1bWVudCAoUHJvYmFibHkNCiBpbiBzZWN0aW9uIDcuMSBhbmQgbGF0ZXIgaW4gdGhlIElBTkEg c2VjdGlvbikgYW5kIHNwZWNpZnkgdGhhdCBpdCBpcyByZXNlcnZlZCBmb3IgdXNlIGluIGV4YW1w bGVzIHdoZXJlIG9uZSBkb2VzIG5vdCB3aXNoIHRvIGJlIG1vcmUgc3BlY2lmaWMu4oCdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj40LjIuJm5ic3A7IEltcGxpY2l0IEdyYW50OiBDb21tZW50 IOKAnEkgaGF2ZSBydW4gaW50byBtdWx0aXBsZSBwZW9wbGUgKGluY2x1ZGluZyBteXNlbGYpIHdo byBoYXZlIHJlYWQgdGhlIE9BdXRoIHNwZWMgYW5kIGNhbWUgYXdheSBjb21wbGV0ZWx5IGNvbmZ1 c2VkIGFib3V0IHdoZW4gdGhlIGhlY2sgb25lIGlzIHN1cHBvc2VkDQogdG8gdXNlIHRoZSBpbXBs aWNpdCBncmFudCBmbG93IGZvci4gSXTigJlzIG5vdCBpbW1lZGlhdGVseSBvYnZpb3VzIHRoYXQg aXTigJlzIGEgd2F5IHRvIHN1cHBvcnQgc3RhbmRhbG9uZSBicm93c2VyIGJhc2VkIGNsaWVudHMu IENhbiB3ZSBwdXQgaW4gYW4gZXhhbXBsZSBvciBzb21ldGhpbmcgdG8gbWFrZSBpdCBtb3JlIG9i dmlvdXMgd2h5IGl04oCZcyBoZXJlP+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NC4y LjEuIEF1dGhvcml6YXRpb24gUmVxdWVzdDogQ29tbWVudCBvbiByZWRpcmVjdF91cmk6Jm5ic3A7 IOKAnEdpdmVuIHRoYXQgdGhlIG9ubHkgd2F5IHRvIGlkZW50aWZ5IHRoZSBjbGllbnQgaW4gdGhl IGltcGxpY2l0IGdyYW50IGZsb3cgaXMgdmlhIHRoZSByZWRpcmVjdF91cmksIGhvdyBjYW4gaXQg YmUgb3B0aW9uYWw/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40LjMuIFJlc291cmNl IE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzOiBDaGFuZ2Ug4oCcZW5hYmxpbmcgdGhlIGdyYW50 IHR5cGUsIGFuZCBvbmx5IHdoZW4gb3RoZXIgZmxvd3PigJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4i PmVuYWJsaW5nIHRoZSBncmFudCB0eXBlIGFuZCBvbmx5IHVzZSBpdCB3aGVuIG90aGVyIGZsb3dz PC9zcGFuPuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuMy4gUmVzb3VyY2UgT3du ZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHM6IENoYW5nZSDigJw8c3BhbiBsYW5nPSJFTiI+cmVzb3Vy Y2Ugb3duZXIgY3JlZGVudGlhbHM8L3NwYW4+4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5yZXNv dXJjZSBvd25lcuKAmXMgY3JlZGVudGlhbHM8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+NC4zLjIuIEFjY2VzcyBUb2tlbiBSZXF1ZXN0OiZuYnNwOyBDb21tZW50IG9uIOKA nGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcHJvdGVjdCB0aGUgZW5kcG9pbnQgYWdhaW5zdCBi cnV0ZSBmb3JjZSBhdHRhY2tz4oCdOiDigJxTaG91bGRu4oCZdCB0aGUgcmVxdWlyZW1lbnQgdG8g cHJldmVudCBhZ2FpbnN0IGJydXRlIGZvcmNlDQogYXR0YWNrcyBhcHBseSB0byBhbGwgY3JlZGVu dGlhbHMsIHJlc291cmNlIG93bmVyIG9yIG90aGVyd2lzZT8gSW4gb3RoZXIgd29yZHMgaW4gc2Vj dGlvbiAyLjQuMSB3ZSB0YWxrIGFib3V0IGhvdyBjbGllbnRzIHN1Ym1pdCB0aGVpciBuYW1lL3Bh c3N3b3JkLiBTaG91bGRu4oCZdCBlbmRwb2ludHMgYWNjZXB0aW5nIGNsaWVudCBuYW1lL3Bhc3N3 b3JkcyBoYXZlIHRoZSBzYW1lIHByb3RlY3Rpb25zIGFnYWluc3QgYnJ1dGUgZm9yY2UgYXR0YWNr P+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NC40LjMuIEFjY2VzcyBUb2tlbiBSZXNw b25zZTogQ29tbWVudCBvbiDigJxBIHJlZnJlc2ggdG9rZW4gU0hPVUxEIE5PVCBiZSBpbmNsdWRl ZOKAnTog4oCcV2h5IGlzbuKAmXQgdGhpcyBhIE1VU1QgTk9UP+KAnTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+NC41LiBFeHRlbnNpb25zOiBDb21tZW50IOKAnElzbuKAmXQgdGhlIHRleHQg aW4gdGhpcyBzZWN0aW9uIGFuZCA4LjMgcmVkdW5kYW50IHdpdGggZWFjaCBvdGhlcj8gSXQgc2Vl bXMgbGlrZSB3ZSBzaG91bGQgdGFrZSB0aGUgdGV4dCBmcm9tIGhlcmUgYW5kIG1lcmdlIGl0IHdp dGggc2VjdGlvbiA4LjMgc28gYWxsDQogdGhlIGV4dGVuc2lvbiBpbmZvcm1hdGlvbiBpcyByZWNv cmRlZCBpbiBvbmUgcGxhY2UuJm5ic3A7IEl04oCZcyBqdXN0IHBsYWluIHRoYXQgYWxsIG90aGVy IGV4dGVuc2lvbiBwb2ludHMgYXJlIGluIHNlY3Rpb24gOCBidXQgdGhpcyBvbmUu4oCdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj41LjEuIFN1Y2Nlc3NmdWwgUmVzcG9uc2U6IENvbW1lbnQg b24g4oCccGFyYW1ldGVyIGF0IHRoZSBoaWdoZXN0IHN0cnVjdHVyZSBsZXZlbOKAnTog4oCcQXJl IHRoZXJlIGFueSBndWFyYW50ZWVzIGFib3V0IHRoZSBvcmRlciBvZiB0aGUgbWVtYmVycyBpbiB0 aGUgSlNPTiBvYmplY3Q/IElmIG5vdCB3ZSBzaG91bGQgc2F5DQogc28gZXhwbGljaXRseS7igJ08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjUuMi4gRXJyb3IgUmVzcG9uc2U6IENvbW1lbnQg b24g4oCcbXVsdGlwbGUgY2xpZW50IGF1dGhlbnRpY2F0aW9ucyBpbmNsdWRlZOKAnSBpbiBpbnZh bGlkX2NsaWVudDog4oCcU2hvdWxkbuKAmXQgdGhpcyBiZSBhbiBpbnZhbGlkX3JlcXVlc3Q/4oCd PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj41LjIuIEVycm9yIFJlc3BvbnNlOiBDb21tZW50 IG9uIOKAnE51bWVyaWNhbCB2YWx1ZXMgYXJlIGluY2x1ZGVkIGFzIEpTT04gbnVtYmVyc+KAnTog 4oCcU2FtZSBpc3N1ZSBhcyBiZWZvcmUsIGRvZXMgb3JkZXJpbmcgbWF0dGVyIGFuZCBpZiBub3Qg d2UgbmVlZCB0byBzYXkgdGhhdC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjguMS4g RGVmaW5pbmcgQWNjZXNzIFRva2VuIFR5cGVzOiBDaGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPm9y IHVzZSBhIHVuaXF1ZTwvc3Bhbj7igJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPm9yIHVzaW5nIGEg dW5pcXVlPC9zcGFuPuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjkuJm5ic3A7IE5h dGl2ZSBBcHBsaWNhdGlvbnM6Jm5ic3A7IENoYW5nZSDigJxhbiBzY2hlbWXigJ0gdG8g4oCcYSBz Y2hlbWXigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjkuJm5ic3A7IE5hdGl2ZSBBcHBs aWNhdGlvbnM6ICZuYnNwO0NoYW5nZSDigJw8c3BhbiBsYW5nPSJFTiI+b2ZmZXIgYW4gaW1wcm92 ZWQgdXNhYmlsaXR5PC9zcGFuPuKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+b2ZmZXIgaW1wcm92 ZWQgdXNhYmlsaXR5PC9zcGFuPuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+OS4mbmJz cDsgTmF0aXZlIEFwcGxpY2F0aW9uczogJm5ic3A7Q2hhbmdlIOKAnDxzcGFuIGxhbmc9IkVOIj5p bmFiaWxpdHkgdG8ga2VlcCBjcmVkZW50aWFscyBjb25maWRlbnRpYWw8L3NwYW4+4oCdIHRvIOKA nDxzcGFuIGxhbmc9IkVOIj5pbmFiaWxpdHkgdG8ga2VlcCBjbGllbnQgY3JlZGVudGlhbHMgY29u ZmlkZW50aWFsPC9zcGFuPuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjkuJm5ic3A7 IE5hdGl2ZSBBcHBsaWNhdGlvbnM6ICZuYnNwO0NoYW5nZSDigJxXaGVuIHVzaW5nIHRoZSBpbXBs aWNpdCBncmFudCB0eXBlIGZsb3cgYSByZWZyZXNoIHRva2VuIGlzIG5vdCByZXR1cm5lZOKAnSB0 byDigJxXaGVuIHVzaW5nIHRoZSBpbXBsaWNpdCBncmFudCB0eXBlIGZsb3cgYSByZWZyZXNoIHRv a2VuIGlzIG5vdCByZXR1cm5lZA0KIHNvIG9uY2UgdGhlIGFjY2VzcyB0b2tlbiBleHBpcmVzIHRo ZSBhcHBsaWNhdGlvbiB3aWxsIGhhdmUgdG8gcmVwZWF0IHRoZSBhdXRob3JpemF0aW9uIHByb2Nl c3PigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC4yLiBDbGllbnQgSW1wZXJzb25h dGlvbjombmJzcDsgQ2hhbmdlIOKAnGtlZXAgaXMgY2xpZW504oCdIHRvIOKAnGtlZXAgaXRzIGNs aWVudOKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjIuIENsaWVudCBJbXBlcnNv bmF0aW9uOiZuYnNwOyBDaGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPmR1ZSB0byB0aGUgY2xpZW50 IG5hdHVyZTwvc3Bhbj7igJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPmR1ZSB0byB0aGUgY2xpZW50 4oCZcyBuYXR1cmU8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTAuMi4g Q2xpZW50IEltcGVyc29uYXRpb246Jm5ic3A7IENoYW5nZSDigJw8c3BhbiBsYW5nPSJFTiI+VVJJ IHVzZWQgZm9yIHJlY2VpdmluZyBhdXRob3JpemF0aW9uPC9zcGFuPuKAnSB0byDigJw8c3BhbiBs YW5nPSJFTiI+VVJJIHVzZWQgZm9yIHJlY2VpdmluZyBhdXRob3JpemF0aW9uIHJlcXVlc3RzPC9z cGFuPuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTAuMi4gQ2xpZW50IEltcGVyc29u YXRpb246Jm5ic3A7IENoYW5nZSDigJw8c3BhbiBsYW5nPSJFTiI+ZW5nYWdlIHRoZSByZXNvdXJj ZSBvd25lcjwvc3Bhbj7igJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPmVuZ2FnaW5nIHRoZSByZXNv dXJjZSBvd25lcjwvc3Bhbj7igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC4yLiBD bGllbnQgSW1wZXJzb25hdGlvbjombmJzcDsgQ2hhbmdlIOKAnDxzcGFuIGxhbmc9IkVOIj5hbmQg YXV0aG9yaXplIHRoZSByZXF1ZXN0PC9zcGFuPuKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+YW5k IGF1dGhvcml6ZSBvciByZWplY3QgdGhlIHJlcXVlc3Q8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+MTAuMy4gQWNjZXNzIFRva2VuczogQ2hhbmdlIOKAnEFjY2VzcyB0b2tl biAoYXMgd2VsbCBhcyBhbnkgYWNjZXNzIHRva2VuIHR5cGUtc3BlY2lmaWMgYXR0cmlidXRlcyni gJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPkFjY2VzcyB0b2tlbnMgKGFzIHdlbGwgYXMgYW55IGFj Y2VzcyB0b2tlbiB0eXBlIHNwZWNpZmljIGF0dHJpYnV0ZXMpPC9zcGFuPuKAnS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjEwLjMuIEFjY2VzcyBUb2tlbnM6IENoYW5nZSDigJxndWVzc2Vk IHRvIHByb2R1Y2XigJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPmd1ZXNzZWQgc28gYXMgdG8gcHJl dmVudCB1bmF1dGhvcml6ZWQgcGFydGllcyBmcm9tIHByb2R1Y2luZzwvc3Bhbj7igJ0uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC40LiBSZWZyZXNoIFRva2VuczogQ29tbWVudCDigJxB cyBtZW50aW9uZWQgcHJldmlvdXNseSB3ZSByZWFsbHkgc2hvdWxkIGV4cGxhaW4gd2h5IHdlIGlu dHJvZHVjZWQgcmVmcmVzaCB0b2tlbnMuIFdpdGhvdXQgdW5kZXJzdGFuZGluZyB0aGUgaW50ZW50 IG9mIHRoZSBtZWNoYW5pc20gaXTigJlzIHVubGlrZWx5DQogaW1wbGVtZW50ZXJzIHdpbGwgdXNl IHRoZW0gYXBwcm9wcmlhdGVseS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjQu IFJlZnJlc2ggVG9rZW5zOiZuYnNwOyBDaGFuZ2Ug4oCcc3RvcmFnZSwgYW5kIHNoYXJlZCBvbmx5 IGFtb25n4oCdIHRvIOKAnHN0b3JhZ2UsIGFuZCBhcmUgdG8gYmUgc2hhcmVkIG9ubHkgYW1vbmfi gJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC40LiBSZWZyZXNoIFRva2VuczombmJz cDsgQ2hhbmdlIOKAnHJlZnJlc2ggdG9rZW5zIHJvdGF0aW9u4oCdIHRvIOKAnHJlZnJlc2ggdG9r ZW4gcm90YXRpb27igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC40LiBSZWZyZXNo IFRva2VuczombmJzcDsgQ2hhbmdlIOKAnGd1ZXNzZWQgdG8gcHJvZHVjZeKAnSB0byDigJw8c3Bh biBsYW5nPSJFTiI+Z3Vlc3NlZCBzbyBhcyB0byBwcmV2ZW50IHVuYXV0aG9yaXplZCBwYXJ0aWVz IGZyb20gcHJvZHVjaW5nPC9zcGFuPuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEw LjYuIEF1dGhvcml6YXRpb24gQ29kZSBMZWFrYWdlOiBDb21tZW50IOKAnEkgZmFuY3kgbXlzZWxm IGFzIGJlaW5nIHJlYXNvbmFibHkgaW50ZWxsaWdlbnQgYW5kIEnigJltIHVuY2xlYXIgd2hhdCBh dHRhY2sgaXMgYWN0dWFsbHkgYmVpbmcgZGVzY3JpYmVkIGhlcmUu4oCdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4xMC42LiBBdXRob3JpemF0aW9uIENvZGUgTGVha2FnZTogQ29tbWVudCBv biDigJxUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgdGhlIGNsaWVudCB0 byByZWdpc3RlciB0aGVpciByZWRpcmVjdGlvbiBVUknigJ06IOKAnFdoeSBpcyB0aGlzIGEgc2hv dWxkP+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTAuNy4gUmVzb3VyY2UgT3duZXIg UGFzc3dvcmQgQ3JlZGVudGlhbHM6IENvbW1lbnQgb24g4oCccGFzc3dvcmQgYW50aS1wYXR0ZXJu 4oCdOiDigJxJcyBpdCBmYWlyIHRvIGV4cGVjdCB0aGF0IHRoZSByZWFkZXIga25vd3Mgd2hhdCB0 aGUgcGFzc3dvcmQgYW50aS1wYXR0ZXJuIGlzPyBTaG91bGRu4oCZdCBzb21lIHJlZmVyZW5jZQ0K IHRvIGEgZGVmaW5pdGlvbiBvZiB0aGlzIHBhdHRlcm4gYmUgcmVxdWlyZWQ/4oCdPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4xMC43LiBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50 aWFsczogQ29tbWVudCBvbiDigJxUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIHJlc3Ry aWN0IHRoZSBzY29wZSBhbmQgbGlmZXRpbWUgb2YgYWNjZXNzIHRva2VucyBpc3N1ZWQgdmlhIHRo aXMgZ3JhbnQgdHlwZeKAnTog4oCcUmVzdHJpY3QgaW4NCiB3aGF0IHdheXM/IEJhc2VkIG9uIHdo YXQgY3JpdGVyaWE/IFRoaXMgc3RhdGVtZW50IGlzIHRoZSBlcXVpdmFsZW50IG9mIHNheWluZyDi gJxkb27igJl0IGRvIGJhZCBzdHVmZuKAnS4gUGVyaGFwcyB0cnVlIGJ1dCBub3QgdGVycmlibHkg dXNlZnVsLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTAuMTIuIENyb3NzLVNpdGUg UmVxdWVzdCBGb3JnZXJ5OiBDb21tZW50IG9uIGZpcnN0IHBhcmFncmFwaDog4oCcSSBjaGFsbGVu Z2UgYW55IHJlYXNvbmFibHkgaW50ZWxsaWdlbnQgcGVyc29uIHdobyBkb2VzIG5vdCBhbHJlYWR5 IGtub3cgd2hhdCBhIENTUkYgaXMgdG8gcmVhZCB0aGlzIHBhcmFncmFwaCBhbmQNCiBjb21lIGF3 YXkgYW55IGNsZWFyZXIgYXMgdG8gd2hhdCBpcyBiZWluZyBkaXNjdXNzZWQuIEF0IGEgbWluaW11 bSBpc27igJl0IHNvbWUgcmVmZXJlbmNlIHRvIGEgY29tcGxldGUgZGVmaW5pdGlvbiBvZiBDU1JG IG5lZWRlZCBpZiB0aGVyZSBpcyB0byBiZSBhbnkgaG9wZSBvZiB1c2VyIGNvbXBsaWFuY2U/4oCd PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC4xMi4gQ3Jvc3MtU2l0ZSBSZXF1ZXN0IEZv cmdlcnk6IENvbW1lbnQgb24g4oCcVGhlICZxdW90O3N0YXRlJnF1b3Q7IHJlcXVlc3QgcGFyYW1l dGVyIE1VU1QgY29udGFpbiBhIG5vbi1ndWVzc2FibGUgdmFsdWXigJ06IOKAnEFjdHVhbGx5IGEg bm9uLWd1ZXNzYWJsZSB2YWx1ZSB3b27igJl0IHN0b3AgdGhlIGF0dGFjayBkaXNjdXNzZWQNCiBp biB0aGUgcHJldmlvdXMgcGFyYWdyYXBoIG9uIGl0cyBvd24uIFdoYXTigJlzIGFsc28gbmVlZGVk IGlzIGEgd2F5IHRvIHVuaXF1ZWx5IChhbmQgdW5icmVha2FibHkpIGFzc29jaWF0ZSB0aGUgc3Rh dGUgd2l0aCBhIHBhcnRpY3VsYXIgdXNlciBzbyB0aGF0IGlmIGFuIGF1dGhvcml6YXRpb24gY29k ZSBzd2FwIG9jY3VycyBpdCBjYW4gYmUgcmVsaWFibHkgZGV0ZWN0ZWQu4oCdPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4xMC4xMy4gQ2xpY2tqYWNraW5nOiBDb21tZW50IG9uIOKAnHgtZnJh bWUtb3B0aW9uc+KAnTog4oCcVGhlIHJlY29tbWVuZGF0aW9uIHNlZW1zIGNvbmZ1c2VkLiBJcyBp dCBvLmsuIHRvIGp1c3QgcmVseSBvbiB4LWZyYW1lLW9wdGlvbnMgb3IgTVVTVCBvdGhlciBhY3Rp b25zIGJlIHRha2VuP+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTEuMS4mbmJzcDsg VGhlIE9BdXRoIEFjY2VzcyBUb2tlbiBUeXBlIFJlZ2lzdHJ5OiBDaGFuZ2Ug4oCcdG9rZSB0eXBl 4oCdIHRvIOKAnHRva2VuIHR5cGXigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMS4x LjEuJm5ic3A7IFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZTogQ2hhbmdlIOKAnDxzcGFuIGxhbmc9IkVO Ij5wcm90ZWN0ZWQgcmVzb3VyY2VzIHJlcXVlc3RzIHVzaW5nIGFjY2VzcyB0b2tlbjwvc3Bhbj7i gJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPnByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0cyB1c2lu ZyBhY2Nlc3MgdG9rZW5zPC9zcGFuPuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEx LjEuMS4mbmJzcDsgUmVnaXN0cmF0aW9uIFRlbXBsYXRlOiZuYnNwOyBDaGFuZ2Ug4oCcUmVmZXJl bmNlIHRvIGRvY3VtZW504oCdIHRvIOKAnFJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnTigJ0uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89945SN2PRD0302MB137_-- From tonynad@microsoft.com Thu Aug 11 09:46:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E2921F8C83 for ; Thu, 11 Aug 2011 09:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuF2I2T8h41f for ; Thu, 11 Aug 2011 09:46:41 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 26DAB21F8C82 for ; Thu, 11 Aug 2011 09:46:41 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 09:47:16 -0700 Received: from TX2EHSOBE008.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 09:47:15 -0700 Received: from mail90-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 16:47:14 +0000 Received: from mail90-tx2 (localhost.localdomain [127.0.0.1]) by mail90-tx2-R.bigfish.com (Postfix) with ESMTP id 947E01708620 for ; Thu, 11 Aug 2011 16:47:14 +0000 (UTC) X-SpamScore: 3 X-BigFish: PS3(zzc85fhzz1202h1082kzz8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail90-tx2: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT002.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail90-tx2 (localhost.localdomain [127.0.0.1]) by mail90-tx2 (MessageSwitch) id 1313081197648535_12947; Thu, 11 Aug 2011 16:46:37 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.244]) by mail90-tx2.bigfish.com (Postfix) with ESMTP id EE251BF81A0 for ; Thu, 11 Aug 2011 16:44:58 +0000 (UTC) Received: from SN2PRD0302HT002.namprd03.prod.outlook.com (207.46.4.139) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 16:44:55 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT002.namprd03.prod.outlook.com ([10.27.50.85]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 16:44:54 +0000 From: Anthony Nadalin To: "OAuth WG (oauth@ietf.org)" Thread-Topic: Redirection URI Thread-Index: AcxYRb1XP0xSYd9DQVa6zRpFQxTVKA== Date: Thu, 11 Aug 2011 16:44:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89A96SN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com Subject: [OAUTH-WG] Redirection URI X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 16:46:42 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89A96SN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3.1.2 explicitly states that the redirection endpoint URI MUST be a= n absolute URI. But that means that the URI could be potentially of any sch= eme. This is probably intentional since there are scenarios where a native = client will want to register a custom scheme as the call back URI. But how can that ever be considered secure? Any app could p= otentially register a scheme with itself as the handler in the OS. Are we r= eally in a position to state that ALL OS environments in ALL cases will onl= y allow for the registration of new URI schemes in a completely secure way?= I can't help but wonder if that isn't going too far and endangering users?= Shouldn't we require that the redirect URI MUST always be a HTTPS URI and = that native clients will need to have access to a browser? If we don't then= how can we really be sure that a custom scheme is associated with the appl= ication we think it's associated with? If we are going to allow for custom schemes then fun issues= come up. Let's say that an authorization server receives a request from an= implicit client with a redirection URI value of foo:privatescheme:bar. Let= 's further say that the authorization server has an implicit client registe= red with it whose URI is foo:privatescheme:%62%61%72. What should the autho= rization server do? Should it: A) Reject the request because the submitted= redirection URI doesn't match exactly with the registered URI? B) Accept the request because, if one appli= es URL decoding, it is identical to the registered URI but send back the re= sponse with the registered value (e.g. with :bar at the end)? C) Same as B except send back the response = with the same value as specified in redirect uri parameter in the request? Any of the above is legal according to the new or proposed = language. But that clearly can't be right. After all, the host OS which all= owed the client to register the "foo" scheme may not see foo:privatescheme:= bar and foo:privatescheme:%62%61%72 as the same. So if a legitimate app was= using the %62%61%72 value then B would cause an error since the response w= ould be wrong and C would be right. But if the value is part of an attack t= hen B would be right and C would be wrong. Since there is no way for the au= thorization server to know ahead of time what OS might be in use and what b= ehavior it might have I think we have to define that the correct behavior = as "A". The agreement on how to compare redirection URIs is NOT a pr= ivate agreement between the client and authorization server. It's a public = agreement. The whole point of OAuth is to allow any client and any authoriz= ation server to interoperate. But as I show above if the client's assumptio= ns about how the redirect URI is processed and the server's assumptions are= n't the same then security breaks. Therefore the standard MUST define what = the expected behavior is. So we have to answer a couple of questions: Question #1 - How should the server compare= a submitted redirection URI to one it has registered if the server doesn't= recognize the URI scheme? Question #2 - OAuth in section 3.1.2 explic= itly states that the redirection URI can contain a query component. Does th= at override the registered value? In other words if the registered value wa= s foo:privatescheme:bar and the received value is foo:privatescheme:bar?foo= =3Dblah, do the two match? Question #3 - If a recognized URL scheme is= used then what rules apply? And how can we be sure that both the client an= d the authorization server are using the same rules? Because, if they aren'= t, then, well, Dave Thaler's paper nicely outlines the consequences. This i= s especially the case if the redirection URI is pointing to a multi-tenant = server where getting the URI 'wrong' means sending the response to the wron= g place. Propose that the only way to handle all of these rather nas= ty issues is by mandating that section 6.2.1 of RFC 3986 MUST be used by th= e authorization server when determining if a submitted redirection URI matc= hes a registered value. This explicitly precludes the use of 'prefix' match= ing and it explicitly precludes having extra query parameters. If the clien= t needs to encode state information than it can use the dedicated state var= iable. This is the simplest possible approach and therefore the one least l= ikely to be screwed up by authorization servers and therefore least likely = to introduce security holes. Please note that this proposal requires change= s in multiple places in the spec, including but possibly not limited to sec= tions 3.1.2, 3.1.2.2 and 3.1.2.3. --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89A96SN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3.1.2 explicit= ly states that the redirection endpoint URI MUST be an absolute URI. But th= at means that the URI could be potentially of any scheme. This is probably = intentional since there are scenarios where a native client will want to register a custom scheme as the call ba= ck URI.

 

   &nbs= p;            But ho= w can that ever be considered secure? Any app could potentially register a = scheme with itself as the handler in the OS. Are we really in a position to= state that ALL OS environments in ALL cases will only allow for the registration of new URI schemes in a complet= ely secure way? I can't help but wonder if that isn't going too far and end= angering users? Shouldn't we require that the redirect URI MUST always be a= HTTPS URI and that native clients will need to have access to a browser? If we don't then how can we really = be sure that a custom scheme is associated with the application we think it= 's associated with?

   &nbs= p;            <= /o:p>

   &nbs= p;            If we = are going to allow for custom schemes then fun issues come up. Let's say th= at an authorization server receives a request from an implicit client with = a redirection URI value of foo:privatescheme:bar. Let's further say that the authorization server has an implicit client reg= istered with it whose URI is foo:privatescheme:%62%61%72. What should the a= uthorization server do?

 

   &nbs= p;            Should= it:

   &nbs= p;            &= nbsp;           &nbs= p;   A) Reject the request because the submitted redirection URI = doesn't match exactly with the registered URI?

   &nbs= p;            &= nbsp;           &nbs= p;   B) Accept the request because, if one applies URL decoding, = it is identical to the registered URI but send back the response with the r= egistered value (e.g. with :bar at the end)?

   &nbs= p;            &= nbsp;           &nbs= p;   C) Same as B except send back the response with the same val= ue as specified in redirect uri parameter in the request?=

 

   &nbs= p;            Any of= the above is legal according to the new or proposed language. But that cle= arly can't be right. After all, the host OS which allowed the client to reg= ister the "foo" scheme may not see foo:privatescheme:bar and foo:privatescheme:%62%61%72 as the same. So if a legitimate app was us= ing the %62%61%72 value then B would cause an error since the response woul= d be wrong and C would be right. But if the value is part of an attack then= B would be right and C would be wrong. Since there is no way for the authorization server to know ahead of= time what OS might be in use and what behavior it might have  I think= we have to define that the correct behavior as "A".

 

   &nbs= p;           The agr= eement on how to compare redirection URIs is NOT a private agreement betwee= n the client and authorization server. It's a public agreement. The whole p= oint of OAuth is to allow any client and any authorization server to interoperate. But as I show above if the c= lient's assumptions about how the redirect URI is processed and the server'= s assumptions aren't the same then security breaks. Therefore the standard = MUST define what the expected behavior is.

 

   &nbs= p;            So we = have to answer a couple of questions:

 

   &nbs= p;            &= nbsp;           &nbs= p;   Question #1 - How should the server compare a submitted redi= rection URI to one it has registered if the server doesn't recognize the UR= I scheme?

   &nbs= p;            &= nbsp;           &nbs= p;   Question #2 - OAuth in section 3.1.2 explicitly states that = the redirection URI can contain a query component. Does that override the r= egistered value? In other words if the registered value was foo:privatescheme:bar and the received value is foo:privateschem= e:bar?foo=3Dblah, do the two match?

   &nbs= p;            &= nbsp;           &nbs= p;   Question #3 - If a recognized URL scheme is used then what r= ules apply? And how can we be sure that both the client and the authorizati= on server are using the same rules? Because, if they aren't, then, well, Dave Thaler's paper nicely outlines the conseq= uences. This is especially the case if the redirection URI is pointing to a= multi-tenant server where getting the URI 'wrong' means sending the respon= se to the wrong place.

 

   &nbs= p;            Propos= e that the only way to handle all of these rather nasty issues is by mandat= ing that section 6.2.1 of RFC 3986 MUST be used by the authorization server= when determining if a submitted redirection URI matches a registered value. This explicitly precludes the use of 'pref= ix' matching and it explicitly precludes having extra query parameters. If = the client needs to encode state information than it can use the dedicated = state variable. This is the simplest possible approach and therefore the one least likely to be screwed up by a= uthorization servers and therefore least likely to introduce security holes= . Please note that this proposal requires changes in multiple places in the= spec, including but possibly not limited to sections 3.1.2, 3.1.2.2 and 3.1.2.3.

 

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89A96SN2PRD0302MB137_-- From tonynad@microsoft.com Thu Aug 11 10:34:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E80721F8C4B for ; Thu, 11 Aug 2011 10:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWZFsLQzx6ho for ; Thu, 11 Aug 2011 10:34:12 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 948B221F8C3C for ; Thu, 11 Aug 2011 10:34:12 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 10:34:47 -0700 Received: from VA3EHSOBE002.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 10:34:47 -0700 Received: from mail192-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 17:34:33 +0000 Received: from mail192-va3 (localhost.localdomain [127.0.0.1]) by mail192-va3-R.bigfish.com (Postfix) with ESMTP id 55781178266 for ; Thu, 11 Aug 2011 17:34:33 +0000 (UTC) X-SpamScore: 3 X-BigFish: PS3(zzc85fhzz1202h1082kzz8275bh8275dhz31h2a8h668h839h63h) X-Spam-TCS-SCL: 2:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail192-va3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT004.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail192-va3 (localhost.localdomain [127.0.0.1]) by mail192-va3 (MessageSwitch) id 1313084072845373_15344; Thu, 11 Aug 2011 17:34:32 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.251]) by mail192-va3.bigfish.com (Postfix) with ESMTP id CA440E4804D for ; Thu, 11 Aug 2011 17:34:32 +0000 (UTC) Received: from SN2PRD0302HT004.namprd03.prod.outlook.com (207.46.4.139) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 17:34:30 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT004.namprd03.prod.outlook.com ([10.27.50.87]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 17:34:27 +0000 From: Anthony Nadalin To: "OAuth WG (oauth@ietf.org)" Thread-Topic: State Size Thread-Index: AcxYRoAT8CIA/dQcQJeRV435yyBjnQ== Date: Thu, 11 Aug 2011 17:34:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89B3CSN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com Subject: [OAUTH-WG] State Size X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 17:34:13 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89B3CSN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The spec states in multiple places that servers control how big authorizati= on and other codes are so clients can't be sure how much space they will ha= ve in URIs. How can anyone design a client that is intended to work with mu= ltiple authorization servers if they have no clue how big their state can b= e? Are they supposed to re-write their state system every time they run int= o a protected resource that wants to use a bigger auth code then the client= has expected them to? We have to give client developers some kind of guida= nce they can use to let them know what is a 'safe' size for their state so = they can successfully implement with all authorization servers. Recommendat= ion is to say something like - "we assume URIs can be at least 2Kb and tha= t the total client provided values (e.g. the base redirect URI plus the sta= te value) are no more than 1K." --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89B3CSN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The spec states in multiple places that servers cont= rol how big authorization and other codes are so clients can't be sure how = much space they will have in URIs. How can anyone design a client that is i= ntended to work with multiple authorization servers if they have no clue how big their state can be? Are they supposed= to re-write their state system every time they run into a protected resour= ce that wants to use a bigger auth code then the client has expected them t= o? We have to give client developers some kind of guidance they can use to let them know what is a 'safe' size = for their state so they can successfully implement with all authorization s= ervers. Recommendation is to  say something like – “we ass= ume URIs can be at least 2Kb and that the total client provided values (e.g. the base redirect URI plus the state value) are no m= ore than 1K.”

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89B3CSN2PRD0302MB137_-- From tonynad@microsoft.com Thu Aug 11 10:40:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9495E800A for ; Thu, 11 Aug 2011 10:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eIsvHXUr1Gp for ; Thu, 11 Aug 2011 10:40:21 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 311795E8001 for ; Thu, 11 Aug 2011 10:40:21 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 10:40:56 -0700 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 10:40:56 -0700 Received: from mail7-ch1-R.bigfish.com (216.32.181.168) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 17:40:55 +0000 Received: from mail7-ch1 (localhost.localdomain [127.0.0.1]) by mail7-ch1-R.bigfish.com (Postfix) with ESMTP id 217EE5A04B1 for ; Thu, 11 Aug 2011 17:40:55 +0000 (UTC) X-SpamScore: 3 X-BigFish: PS3(zzc85fhzz1202h1082kzz8275bh8275dhz31h2a8h668h839h65h) X-Spam-TCS-SCL: 4:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT011.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail7-ch1: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT011.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail7-ch1 (localhost.localdomain [127.0.0.1]) by mail7-ch1 (MessageSwitch) id 1313084454691186_28467; Thu, 11 Aug 2011 17:40:54 +0000 (UTC) Received: from CH1EHSMHS031.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail7-ch1.bigfish.com (Postfix) with ESMTP id A4385D4004F for ; Thu, 11 Aug 2011 17:40:54 +0000 (UTC) Received: from SN2PRD0302HT011.namprd03.prod.outlook.com (207.46.4.139) by CH1EHSMHS031.bigfish.com (10.43.70.31) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 17:40:52 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT011.namprd03.prod.outlook.com ([10.27.90.157]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 17:40:52 +0000 From: Anthony Nadalin To: "OAuth WG (oauth@ietf.org)" Thread-Topic: Refresh Tokens Thread-Index: AcxYTQ8Url5GUfgWROGRaafg4jY5WA== Date: Thu, 11 Aug 2011 17:40:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89B68SN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT011.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com Subject: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 17:40:22 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89B68SN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nowhere in the specification is there explanation for refresh tokens, The r= eason that the Refresh token was introduced was for anonymity. The scenario= is that a client asks the user for access. The user wants to grant the acc= ess but not tell the client the user's identity. By issuing the refresh tok= en as an 'identifier' for the user (as well as other context data like the = resource) it's possible now to let the client get access without revealing = anything about the user. Recommend that the above explanation be included s= o developers understand why the refresh tokens are there. --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89B68SN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nowhere in the specification is there explanation fo= r refresh tokens, The reason that the Refresh token was introduced was for = anonymity. The scenario is that a client asks the user for access. The user= wants to grant the access but not tell the client the user's identity. By issuing the refresh token as an 'i= dentifier' for the user (as well as other context data like the resource) i= t's possible now to let the client get access without revealing anything ab= out the user. Recommend that the above explanation be included so developers understand why the refresh tok= ens are there.

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89B68SN2PRD0302MB137_-- From dick.hardt@gmail.com Thu Aug 11 10:50:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBE021F8C81 for ; Thu, 11 Aug 2011 10:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZkRUFGg52hv for ; Thu, 11 Aug 2011 10:50:29 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC8B921F8C7E for ; Thu, 11 Aug 2011 10:50:28 -0700 (PDT) Received: by yie12 with SMTP id 12so1745743yie.31 for ; Thu, 11 Aug 2011 10:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=4FhX9OlgaYqpYCmO9jmca+b+abx6uoHRpK5dobrwDZA=; b=mSz+5QRF4mtXgnLGrku0/3Y5huDSFV44LfxYixE5EjGOmXe635gWY3wRC8CJ/zmXrL BiLcntH9LrgUNYpP93m3ewCynU2FO7fQkmB7K4pictIpgWI/gnC4Zd9ltsF5lvNy1crF LliD4ooOlm/5HKmnb1XJPYox+p6UlHNAxiFnI= Received: by 10.42.75.71 with SMTP id z7mr1149117icj.157.1313085063180; Thu, 11 Aug 2011 10:51:03 -0700 (PDT) Received: from [192.168.1.16] (c-24-5-69-173.hsd1.ca.comcast.net [24.5.69.173]) by mx.google.com with ESMTPS id hq1sm3424156icc.2.2011.08.11.10.51.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Aug 2011 10:51:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-25--229589295 From: Dick Hardt In-Reply-To: Date: Thu, 11 Aug 2011 10:50:59 -0700 Message-Id: References: To: Anthony Nadalin X-Mailer: Apple Mail (2.1084) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 17:50:29 -0000 --Apple-Mail-25--229589295 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access = token would limit the time an attacker would have access revocation: if the access token is self contained, authorization can be = revoked by not issuing new access tokens. A resource does not need to = query the authorization server to see if the access token is valid.This = simplifies access token validation and makes it easier to scale and = support multiple authorization servers. There is a window of time when = an access token is valid, but authorization is revoked.=20 On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: > Nowhere in the specification is there explanation for refresh tokens, = The reason that the Refresh token was introduced was for anonymity. The = scenario is that a client asks the user for access. The user wants to = grant the access but not tell the client the user's identity. By issuing = the refresh token as an 'identifier' for the user (as well as other = context data like the resource) it's possible now to let the client get = access without revealing anything about the user. Recommend that the = above explanation be included so developers understand why the refresh = tokens are there. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-25--229589295 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii My recollection of refresh tokens was for security = and revocation.

security: By having a short lived = access token, a compromised access token would limit the time an = attacker would have access

revocation: if the = access token is self contained, authorization can be revoked by not = issuing new access tokens. A resource does not need to query the = authorization server to see if the access token is valid.This simplifies = access token validation and makes it easier to scale and support = multiple authorization servers.  There is a window of time = when an access token is valid, but authorization is = revoked. 



On = 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:

Nowhere in the specification = is there explanation for refresh tokens, The reason that the Refresh = token was introduced was for anonymity. The scenario is that a client = asks the user for access. The user wants to grant the access but not = tell the client the user's identity. By issuing the refresh token as an = 'identifier' for the user (as well as other context data like the = resource) it's possible now to let the client get access without = revealing anything about the user. Recommend that the above explanation = be included so developers understand why the refresh tokens are = there.
_____________________________________________= __
OAuth mailing list
 To: Anthony Nadalin , "OAuth WG \(oauth@ietf.org\)" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1820279937-1313086432=:51763" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 18:13:19 -0000 --0-1820279937-1313086432=:51763 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Refresh tokens have a different main goal, in my opinion.=A0 They are usefu= l to allow a log lived durable replacement for username/password.=A0 This m= eans the user's primary credential is not stored in the client.=A0 Refresh = tokens can be revoked by the user without requiring password change.=A0 The= y are also always used over a secure channel, and can fetch a (sometimes mu= ch) shorter lived token used over a clear channel.=A0 Yahoo! Messenger and = others use a model like this now.=A0 Refresh tokens can also be issued to a= particular client requiring authentication, so are not useful if the clien= t authentication credential is not also compromised.=0A=0AThey do have the = property of anonymity as well, but that's true of both teh refresh token an= d access token, so it's not specific to refresh tokens.=0A=0A-bill=0A=0A=0A= =0A________________________________=0AFrom: Anthony Nadalin =0ATo: "OAuth WG (oauth@ietf.org)" =0ASent: Thursda= y, August 11, 2011 10:40 AM=0ASubject: [OAUTH-WG] Refresh Tokens=0A=0A=0A = =0ANowhere in the specification is there explanation for refresh tokens, Th= e reason that the Refresh token was introduced was for anonymity. The scena= rio is that a client asks the user for access. The user wants to grant the = access but not tell the client the user's identity. By issuing the refresh = token as an 'identifier' for the user (as well as other context data like t= he resource) it's possible now to let the client get access without reveali= ng anything about the user. Recommend that the above explanation be include= d so developers understand why the refresh tokens are there.=0A____________= ___________________________________=0AOAuth mailing list=0AOAuth@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-1820279937-1313086432=:51763 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Refresh tokens have a different main goal, in my opinion.  They are = useful to allow a log lived durable replacement for username/password. = ; This means the user's primary credential is not stored in the client.&nbs= p; Refresh tokens can be revoked by the user without requiring password cha= nge.  They are also always used over a secure channel, and can fetch a= (sometimes much) shorter lived token used over a clear channel.  Yaho= o! Messenger and others use a model like this now.  Refre= sh tokens can also be issued to a particular client requiring authenticatio= n, so are not useful if the client authentication credential is not also co= mpromised.

They do have = the property of anonymity as well, but that's true of both teh refresh token and access token, so it's not specific to refresh tokens.

-bill

From: Anthony Nada= lin <tonynad@microsoft.com>
= To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Sent: Thursday, August 11, 2011 = 10:40 AM
Subject: [OAUT= H-WG] Refresh Tokens

=0A=0A =0A =0A=0A=0A =0A
=0A<= div class=3D"yiv91714285MsoNormal">Nowhere in the specification is there ex= planation for refresh tokens, The reason that the Refresh token was introdu= ced was for anonymity. The scenario is that a client asks the user for acce= ss. The user wants to grant the access but not=0A tell the client the user'= s identity. By issuing the refresh token as an 'identifier' for the user (a= s well as other context data like the resource) it's possible now to let th= e client get access without revealing anything about the user. Recommend th= at the=0A above explanation be included so developers understand why the re= fresh tokens are there.
=0A
=0A =0A=0A

________________= _______________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth


--0-1820279937-1313086432=:51763-- From tonynad@microsoft.com Thu Aug 11 11:16:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B482921F8B29 for ; Thu, 11 Aug 2011 11:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I27l9x9xJtGy for ; Thu, 11 Aug 2011 11:16:09 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id EA56B21F8B19 for ; Thu, 11 Aug 2011 11:16:08 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 11:16:36 -0700 Received: from VA3EHSOBE008.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 11:16:35 -0700 Received: from mail130-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 18:15:42 +0000 Received: from mail130-va3 (localhost.localdomain [127.0.0.1]) by mail130-va3-R.bigfish.com (Postfix) with ESMTP id B725313D00FF for ; Thu, 11 Aug 2011 18:15:42 +0000 (UTC) X-SpamScore: -26 X-BigFish: PS-26(zz9371K936eKc85fh98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT009.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail130-va3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT009.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail130-va3 (localhost.localdomain [127.0.0.1]) by mail130-va3 (MessageSwitch) id 1313086534706771_16545; Thu, 11 Aug 2011 18:15:34 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.251]) by mail130-va3.bigfish.com (Postfix) with ESMTP id 9E30C101004B; Thu, 11 Aug 2011 18:15:34 +0000 (UTC) Received: from SN2PRD0302HT009.namprd03.prod.outlook.com (207.46.4.139) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 18:15:30 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT009.namprd03.prod.outlook.com ([10.27.90.204]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 18:15:29 +0000 From: Anthony Nadalin To: Dick Hardt Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYTQ8Url5GUfgWROGRaafg4jY5WAAAisuAAACFmiA= Date: Thu, 11 Aug 2011 18:15:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89BDESN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT009.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 18:16:09 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89BDESN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Many reasons, but none are explained in the specification From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Thursday, August 11, 2011 10:51 AM To: Anthony Nadalin Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access token = would limit the time an attacker would have access revocation: if the access token is self contained, authorization can be rev= oked by not issuing new access tokens. A resource does not need to query th= e authorization server to see if the access token is valid.This simplifies = access token validation and makes it easier to scale and support multiple a= uthorization servers. There is a window of time when an access token is va= lid, but authorization is revoked. On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: Nowhere in the specification is there explanation for refresh tokens, The r= eason that the Refresh token was introduced was for anonymity. The scenario= is that a client asks the user for access. The user wants to grant the acc= ess but not tell the client the user's identity. By issuing the refresh tok= en as an 'identifier' for the user (as well as other context data like the = resource) it's possible now to let the client get access without revealing = anything about the user. Recommend that the above explanation be included s= o developers understand why the refresh tokens are there. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89BDESN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Many reasons, but none ar= e explained in the specification

 <= /p>

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

 

My recollection of refresh tokens was for security a= nd revocation.

 

security: By having a short lived access token, a co= mpromised access token would limit the time an attacker would have access

 

revocation: if the access token is self contained, a= uthorization can be revoked by not issuing new access tokens. A resource do= es not need to query the authorization server to see if the access token is= valid.This simplifies access token validation and makes it easier to scale and support multiple authorization= servers.  There is a window of time when an access token is vali= d, but authorization is revoked. 

 

 

 

On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:



Nowhere in the specification is there e= xplanation for refresh tokens, The reason that the Refresh token was introd= uced was for anonymity. The scenario is that a client asks the user for access. The user wants to grant the access but not tell the c= lient the user's identity. By issuing the refresh token as an 'identifier' = for the user (as well as other context data like the resource) it's possibl= e now to let the client get access without revealing anything about the user. Recommend that the above explan= ation be included so developers understand why the refresh tokens are there= .

_____________________________________= __________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89BDESN2PRD0302MB137_-- From wmills@yahoo-inc.com Thu Aug 11 11:21:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FD221F8B6D for ; Thu, 11 Aug 2011 11:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.889 X-Spam-Level: X-Spam-Status: No, score=-16.889 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wgKbTK9B7E2 for ; Thu, 11 Aug 2011 11:21:14 -0700 (PDT) Received: from nm6-vm0.bullet.mail.bf1.yahoo.com (nm6-vm0.bullet.mail.bf1.yahoo.com [98.139.213.146]) by ietfa.amsl.com (Postfix) with SMTP id A1B1121F8A57 for ; Thu, 11 Aug 2011 11:21:13 -0700 (PDT) Received: from [98.139.215.140] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 11 Aug 2011 18:21:48 -0000 Received: from [98.139.212.227] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 11 Aug 2011 18:21:48 -0000 Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 11 Aug 2011 18:21:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 353600.3395.bm@omp1036.mail.bf1.yahoo.com Received: (qmail 631 invoked by uid 60001); 11 Aug 2011 18:21:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313086907; bh=6aJNn8xd+chjxKtCWhPe8oH6weS7+kuJjPSHEOqbVCU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=F5vWvrcjJR7o6j0znDQdioI5WEtXGiibxPRRmbJ/l52ZWSOFmJaj86b37OyZXlmos8Sdc5LiW9rgJRHdX02pkYn4t2sTjaCQv3l0du4zC3IZEmK7JnlBQ+l3Mu7BbuUr1tj8ScgmgSLA506FjxEIbGrHFh2/E5Nr7imtjwoLgFY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=S70FImOI+fa/giPoQ81Ucs2I8pa799w+2MPDIgjvX9opDS4CNA4KxmLHBst0JlWq9N0eQJJxVvlu8t5QBh+B7eINBQeTzyCfbgdGbNVGl1WQtfjwmSytbVgwMQLOKsSPlielv2ACA2Wx+VtPj0jDm5Ind58OTjj1vZFPCMeq9L8=; X-YMail-OSG: LW43ZzEVM1mccd68RwI5d1k.27yMBN2XAK950OtfRbK5F.e znbA.dQfo90zSJ4OpgzkarPWUr0zsndXilcL7H7osxAGbfYlNgzkdHUpjHYA h7n.sd3vJmPrk7UEYmt4GN0J7lcSesdMZTU4j0vvQk6E0Fj9QrR8i1vifsys 8V2p0spD25tywM9wOdkm9iBt8Vik1YBtVg5IgkX_tWOrN2JwW1E1YH6xbGKA 3EX.5b0vX_2hYo20BR36JCNPS8dqqqiIjEC9J0ajXC8Fi_E6DbBS41jf0NDi f5amQxeJL4Yl_X8B.N9zf3_dYwQWjPIUon4pWY.UU4lWOoMmPAiBUbycAjMY aVcHlqPQcaIsKsWxTkLduVB.zzOfuUfvawu2E1cAOOCT6Cn8Gx3UDk9jj5nB DuP9eZdzo6yKUCWfdwEU9Q_bO.UFze5verky9g3.2STc- Received: from [209.131.62.113] by web31803.mail.mud.yahoo.com via HTTP; Thu, 11 Aug 2011 11:21:47 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: Message-ID: <1313086907.91165.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Thu, 11 Aug 2011 11:21:47 -0700 (PDT) From: "William J. Mills" To: Anthony Nadalin , Dick Hardt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-133394987-1313086907=:91165" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 18:21:15 -0000 --0-133394987-1313086907=:91165 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Does it want to be in the main definition or the security considerations se= ction?=0A=0A=0A=0A________________________________=0AFrom: Anthony Nadalin = =0ATo: Dick Hardt =0ACc: "OAut= h WG (oauth@ietf.org)" =0ASent: Thursday, August 11, 2011 1= 1:15 AM=0ASubject: Re: [OAUTH-WG] Refresh Tokens=0A=0A=0A =0AMany reasons, = but none are explained in the specification=0A=A0=0AFrom:Dick Hardt [mailto= :dick.hardt@gmail.com] =0ASent: Thursday, August 11, 2011 10:51 AM=0ATo: An= thony Nadalin=0ACc: OAuth WG (oauth@ietf.org)=0ASubject: Re: [OAUTH-WG] Ref= resh Tokens=0A=A0=0AMy recollection of refresh tokens was for security and = revocation.=0A=A0=0Asecurity: By having a short lived access token, a compr= omised access token would limit the time an attacker would have access=0A= =A0=0Arevocation: if the access token is self contained, authorization can = be revoked by not issuing new access tokens. A resource does not need to qu= ery the authorization server to see if the access token is valid.This simpl= ifies access token validation and makes it easier to scale and support mult= iple authorization servers.=A0=A0There is a window of time when an access t= oken is valid, but authorization is revoked.=A0=0A=A0=0A=A0=0A=A0=0AOn 2011= -08-11, at 10:40 AM, Anthony Nadalin wrote:=0A=0A=0ANowhere in the specific= ation is there explanation for refresh tokens, The reason that the Refresh = token was introduced was for anonymity. The scenario is that a client asks = the user for access. The user wants to grant the access but not tell the cl= ient the user's identity. By issuing the refresh token as an 'identifier' f= or the user (as well as other context data like the resource) it's possible= now to let the client get access without revealing anything about the user= . Recommend that the above explanation be included so developers understand= why the refresh tokens are there.=0A______________________________________= _________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mail= man/listinfo/oauth=0A=A0=0A_______________________________________________= =0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/oauth --0-133394987-1313086907=:91165 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Does it want to be in the main definition or the security considerations = section?

From: Anthony Nadalin <tonynad@microsoft.com>To: Dick Hardt <dick.h= ardt@gmail.com>
Cc: = "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Sent: Thursday, August 11, 2011 11:15 AM
= Subject: Re: [OAUTH-WG] Refre= sh Tokens

=0A=0A =0A =0A=0A=0A =0A
= =0A
Many reasons, but none are explained in the specification
=0A
 
=0A
=0A
=0A
From: Dick Hardt [mailto:dick.hardt@gma= il.com]=0A
=0ASent: Thursday, August 11, 2011 10:51 AM
=0AT= o: Anthony Nadalin
=0ACc: OAuth WG (oauth@ietf.org)
=0A= Subject: Re: [OAUTH-WG] Refresh Tokens
=0A
=0A
= =0A
 
=0A
My recollection of refresh tokens was for security and r= evocation.
=0A
=0A
  =0A
=0A
=0A
security: By h= aving a short lived access token, a compromised access token would limit th= e time an attacker would have access
=0A
=0A
=0A
 
=0A
=0A
=0A
revocation: if the access token is self contained, a= uthorization can be revoked by not issuing new access tokens. A resource do= es not need to query the authorization server to see if the access token is= valid.This simplifies access token=0A validation and makes it easier to sc= ale and support multiple authorization servers.  There is a windo= w of time when an access token is valid, but authorization is revoked. = ;
=0A
=0A
=0A
  =0A
=0A
 
=0A
= =0A
=0A
 
=0A
=0A=0A
On 2011-08-11, at 10:40 AM, Anth= ony Nadalin wrote:
=0A
=0A
<= br>=0A
=0A
=0A
=0A
=0A
Nowhere in the specification is there ex= planation for refresh tokens, The reason that the Refresh token was introdu= ced was for anonymity. The scenario is that a client asks=0A the user for a= ccess. The user wants to grant the access but not tell the client the user'= s identity. By issuing the refresh token as an 'identifier' for the user (a= s well as other context data like the resource) it's possible now to let th= e client get access=0A without revealing anything about the user. Recommend= that the above explanation be included so developers understand why the re= fresh tokens are there.
=0A
=0A
______________________________= _________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps://www.ietf.org/mailman/lis= tinfo/oauth
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A =0A=0A

__= _____________________________________________
OAuth mailing list
OAuth@ietf.= org
https://www.ietf.org/mailman/listinfo/oauth


--0-133394987-1313086907=:91165-- From jricher@mitre.org Thu Aug 11 11:35:54 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AF021F8C43 for ; Thu, 11 Aug 2011 11:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ5Xl3AOa0NI for ; Thu, 11 Aug 2011 11:35:54 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 11E6321F8C44 for ; Thu, 11 Aug 2011 11:35:54 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A127121B16B5; Thu, 11 Aug 2011 14:36:28 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 900CF21B05D3; Thu, 11 Aug 2011 14:36:28 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.3.192.1; Thu, 11 Aug 2011 14:36:28 -0400 From: Justin Richer To: "William J. Mills" In-Reply-To: <1313086907.91165.YahooMailNeo@web31803.mail.mud.yahoo.com> References: <1313086907.91165.YahooMailNeo@web31803.mail.mud.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 11 Aug 2011 14:35:55 -0400 Message-ID: <1313087755.22073.59.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 18:35:54 -0000 Isn't this what section 1.5 is already there for? Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner). Issuing a refresh token is optional and is included when issuing an access token. A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers. What could make this text clearer? (Though while I'm here, I just noticed a nit: "Issuing a refresh token is optional and is included when issuing an access token." Could be clearer, as in something like: "Issuing a refresh token is optional, but when one is issued it is included along with an access token.") -- Justin On Thu, 2011-08-11 at 14:21 -0400, William J. Mills wrote: > Does it want to be in the main definition or the security > considerations section? > > > > > ______________________________________________________________________ > From: Anthony Nadalin > To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Sent: Thursday, August 11, 2011 11:15 AM > Subject: Re: [OAUTH-WG] Refresh Tokens > > Many reasons, but none are explained in the specification > > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Thursday, August 11, 2011 10:51 AM > To: Anthony Nadalin > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > > My recollection of refresh tokens was for security and revocation. > > security: By having a short lived access token, a compromised access > token would limit the time an attacker would have access > > revocation: if the access token is self contained, authorization can > be revoked by not issuing new access tokens. A resource does not need > to query the authorization server to see if the access token is > valid.This simplifies access token validation and makes it easier to > scale and support multiple authorization servers. There is a window > of time when an access token is valid, but authorization is revoked. > > > > On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: > > > > Nowhere in the specification is there explanation for refresh tokens, > The reason that the Refresh token was introduced was for anonymity. > The scenario is that a client asks the user for access. The user wants > to grant the access but not tell the client the user's identity. By > issuing the refresh token as an 'identifier' for the user (as well as > other context data like the resource) it's possible now to let the > client get access without revealing anything about the user. Recommend > that the above explanation be included so developers understand why > the refresh tokens are there. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > From eran@hueniverse.com Thu Aug 11 12:14:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F76921F8B67 for ; Thu, 11 Aug 2011 12:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE7XOcX2qkxB for ; Thu, 11 Aug 2011 12:14:36 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 7097221F8B45 for ; Thu, 11 Aug 2011 12:14:36 -0700 (PDT) Received: (qmail 11802 invoked from network); 11 Aug 2011 19:15:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 19:15:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 11 Aug 2011 12:14:53 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin Date: Thu, 11 Aug 2011 12:14:48 -0700 Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland Thread-Index: AcxYWvLo35E95LHBSpeD27uVAwtYWg== Message-ID: <9C1A8698-157C-4FB8-9FAA-016FD4722951@hueniverse.com> References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> <356C947C-E0E9-4AC4-9D48-36370B40763B@hueniverse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9C1A8698157C4FB89FAA016FD4722951hueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:14:39 -0000 --_000_9C1A8698157C4FB89FAA016FD4722951hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCB3YW50IHRvIG1ha2Ugc3VyZSBpdCBpcyBjb3ZlcmVkIGJ5IHRoZSBub3JtYWwgY29udHJp YnV0aW9uIHJ1bGUuDQoNCk9uIEF1ZyAxMSwgMjAxMSwgYXQgMTA6NTgsICJBbnRob255IE5hZGFs aW4iIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+ IHdyb3RlOg0KDQpIZSBpcyBvdXQgb24gdmFjYXRpb24gd2l0aCBubyBhY2Nlc3MgYW5kIGhlIGxl ZnQgTWlrZSB3aXRoIGEgYnVuY2ggb2YgY29tbWVudHMgdG8gcHVsbCB0b2dldGhlciB0byBzdWJt aXQgYW5kIHdlIGtuZXcgdGhhdCB5b3Ugd2FudGVkIHRoZXNlIGNvbW1lbnRzIHRvIGVuc3VyZSB0 aGF0IHRoZSBzcGVjIGlzIHRoZSBiZXN0IGl0IGNhbiBiZS4NCg0KRnJvbTogb2F1dGgtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJhbiBIYW1tZXItTGFoYXYNClNlbnQ6IFdl ZG5lc2RheSwgQXVndXN0IDEwLCAyMDExIDU6MTkgUE0NClRvOiBNaWtlIEpvbmVzDQpDYzogPG1h aWx0bzpvYXV0aEBpZXRmLm9yZz4gb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUGFydGlhbCBzZXQgb2YgbGFzdCBjYWxsIGNvbW1l bnRzIG9uIE9BdXRoIGRyYWZ0IDIwIGZyb20gWWFyb24gR29sYW5kDQoNCklzIHRoZXJlIGEgcmVh c29uIHdoeSBNciBHb2xhbmQgaXNudCBzZW5kaW5nIGhpcyBvd24gY29tbWVudHMgaW4/DQoNCk9u IEF1ZyAxMCwgMjAxMSwgYXQgMTc6MzksICJNaWtlIEpvbmVzIiA8PG1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCjEuNC4gQXV0aG9yaXphdGlvbiBHcmFu dDogQ2hhbmdlIOKAnHJlc291cmNlIG93bmVyIGF1dGhvcml6YXRpb27igJ0gdG8g4oCccmVzb3Vy Y2Ugb3duZXLigJlzIGF1dGhvcml6YXRpb27igJ0uDQoNCjEuNC4xLiBBdXRob3JpemF0aW9uIENv ZGU6ICBDb21tZW50OiDigJxJdCBzZWVtcyBvZGQgdGhhdCB3ZSBjYW4gZGlzY3VzcyB0aGUgYXV0 aG9yaXphdGlvbiBjb2RlIHdpdGhvdXQgYWxzbyBkaXNjdXNzaW5nIHRoZSBzZWN1cml0eSBpc3N1 ZXMgaXQgcmFpc2VzIChlLmcuIHBhc3Npbmcgc2VjdXJlIGluZm9ybWF0aW9uIHZpYSBhIGJyb3dz ZXIpIGFuZCB0aHVzIG1vdGl2YXRpbmcgdGhlIGludHJvZHVjdGlvbiBvZiB0aGUgcmVmcmVzaCB0 b2tlbi4gSSB3b3VsZCBleHBlY3QgdGhpcyB0byBiZSByZWZlcnJlZCB0byBoZXJlLiAgSGF2aW5n IHJlYWQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gSSBjYW4gZmluZCBubyBj b2hlcmVudCBkaXNjdXNzaW9uIHRoZXJlIGVpdGhlciBvZiB0aGUgcmVsYXRpb25zaGlwIGJldHdl ZW4gdGhlIGF1dGhvcml6YXRpb24gY29kZSBhbmQgdGhlIHJlZnJlc2ggdG9rZW4gYW5kIHdoeSBv bmUgbW90aXZhdGVkIHRoZSBvdGhlci4gSSB0aGluayB0aGlzIGlzIHNvbWV0aGluZyBpbXBvcnRh bnQgZm9yIGltcGxlbWVudGVycyB0byB1bmRlcnN0YW5kLuKAnQ0KDQoxLjQuMi4gIEltcGxpY2l0 OiAgQ29tbWVudDog4oCcSSBmaW5kIHRoaXMgc2VjdGlvbiBjb25mdXNpbmcuIEkgdGhpbmsgYW4g ZXhhbXBsZSBpcyBhbGwgYnV0IG1hbmRhdG9yeSBoZXJlIGlmIHRoZSByZWFkZXIgaXMgdG8gdW5k ZXJzdGFuZCB3aGF0IGlzIGludGVuZGVkLiAgRm9yIGV4YW1wbGUsIHdoZW4gSSBmaXJzdCByZWFk IHRoaXMgc2VjdGlvbiBJIHRob3VnaHQgaXQgd2FzIHNvbWUga2luZCBvZiBzaG9ydCBjdXQgdXNl ZCBpbiBjYXNlcyB3aGVyZSB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZlciBoYWQg YSBjbG9zZSByZWxhdGlvbnNoaXAgYW5kIGNvdWxkIHNoYXJlIGluZm9ybWF0aW9uIHN1Y2ggYXMg dGhlIGNsaWVudOKAmXMgaWRlbnRpdHkgc28gbm8gYWNjZXNzIGNvZGUgd2FzIG5lZWRlZC4gIE5v IHdoZXJlIGluIGhlcmUgaXMgYW55IGhpbnQgdGhhdCB0aGlzIGlzIGFib3V0IGJyb3dzZXIgYmFz ZWQgY2xpZW50cyB3aG8gZG9u4oCZdCBoYXZlIHNlcnZlcnMgYW5kIHdobyBuZWVkIGEgd2F5IHRv IGdldCB0b2tlbnMuIFNlcmlvdXNseS4gVHJ5IHRvIHJlYWQgdGhpcyBzZWN0aW9uIGFzIHNvbWVv bmUgd2hvIGtub3dzIG5vdGhpbmcgYWJvdXQgT0F1dGggYW5kIHRlbGwgbWUgdGhhdCB5b3UgZ2V0 IHRoZSByaWdodCBpZGVhIGJhY2sgZnJvbSBpdC4gSXQgbmVlZHMgdG8gYmUgd3JpdHRlbiB0byBi ZSBib3RoIGV4cGxpY2l0IGFzIHRvIGl0cyBnb2FscyBhbmQgY2xlYXJlciBhcyB0byBpdHMgbWVh bnMu4oCdDQoNCjEuNC4yLiAgSW1wbGljaXQ6ICBDaGFuZ2Ug4oCcYXV0aGVudGljYXRlIHRoZSBj bGllbnQgYW5kIHRoZeKAnSB0byDigJxhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBkaXJlY3RseS4g VGhl4oCdLg0KDQoxLjQuMi4gIEltcGxpY2l0OiAgQ2hhbmdlIOKAnHdlaWdodGVk4oCdIHRvIOKA nHdlaWdoZWTigJ0uDQoNCjEuNC4zLiAgUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlh bHM6IENvbW1lbnQgb24g4oCcKHdoZW4gY29tYmluZWQgd2l0aCBhIHJlZnJlc2ggdG9rZW4p4oCd OiDigJxUaGlzIGlzIHRoZSBmaXJzdCB0aW1lIHRoYXQgcmVmcmVzaCB0b2tlbnMgYXJlIG1lbnRp b25lZCBpbiB0aGUgc3BlYy4gQW5kIHlldCB0aGVyZSBpcyBubyBleHBsYW5hdGlvbiBvZiB3aGF0 IHRoZXkgYXJlLiBJIHN1c3BlY3QgdGhleSBzaG91bGQgYW55d2F5IGJlIGludHJvZHVjZWQgaW4g c2VjdGlvbiAxLjQuMSAoYXMgcHJldmlvdXNseSBub3RlZCkgYW5kIHRoZW4gdGhlaXIgdXNlIGhl cmUgd2lsbCBtYWtlIHNlbnNlLiAgSWYgdGhhdCBpc27igJl0IHBvc3NpYmxlIHRoZW4gaXQgd291 bGQgYmUgZ29vZCB0byBoYXZlIGEgZm9yd2FyZCByZWZlcmVuY2UgdG8gc2VjdGlvbiAxLjUgYmVs b3cgc28gdGhlIHJlYWRlciBoYXMgc29tZSBpZGVhIG9mIHdoYXTigJlzIGdvaW5nIG9uLuKAnQ0K DQoxLjQuNC4gIENsaWVudCBDcmVkZW50aWFsczogIENvbW1lbnQgb24g4oCcKHRoZSBjbGllbnQg aXMgYWxzbyB0aGUgcmVzb3VyY2Ugb3duZXIp4oCdOiDigJxJIHRoaW5rIHRoaXMgaXMgbWlzbGVh ZGluZy4gSW1hZ2luZSBzb21ldGhpbmcgbGlrZSBPZmZpY2Ugd2hlcmUgYSBjbGllbnQgaGFzIGJl ZW4gZ3JhbnRlZCBhY2Nlc3MgdG8gYSBwYXJ0aWN1bGFyIHJlc291cmNlIGJ5IHRoZSByZXNvdXJj ZSBvd25lci4gVGhlIGNsaWVudCBjYW4gdGhlbiBhc2sgZm9yIGFuIGFjY2VzcyB0b2tlbiB0byB0 aGUgcmVzb3VyY2UgdXNpbmcgdGhlIGNsaWVudCBjcmVkZW50aWFscyBhbmQgbm8gYWNjZXNzIGNv ZGUgb3IgcmVmcmVzaCB0b2tlbi4gSnVzdCBoYXZpbmcgdGhlIGFkZHJlc3Mgb2YgdGhlIGludGVu ZGVkIHJlc291cmNlIChwcm9iYWJseSBwcm92aWRlZCB2aWEgU0NPUEUpIGFsb25nIHdpdGggdGhl IGNsaWVudCBjcmVkZW50aWFscyBpcyBtb3JlIHRoYW4gZW5vdWdoIHRvIGRlY2lkZSBpZiBhbiBh Y2Nlc3MgdG9rZW4gc2hvdWxkIGJlIGlzc3VlZC4NCg0KTXkgcG9pbnQgaXMgdGhhdCB0aGUgY2xp ZW50IGNyZWRlbnRpYWxzIHNjZW5hcmlvIGlzIGZ1bGx5IGFwcGxpY2FibGUgdG8gY2FzZXMgd2hl cmUgdGhlIGNsaWVudCBpcyBub3QgdGhlIHJlc291cmNlIG93bmVyIGJ1dCBpbiB3aGljaCB0aGUg cmVzb3VyY2UgVVJJIHByb3ZpZGVzIGFsbCB0aGUgY29udGV4dCBuZWVkZWQgdG8gZGV0ZXJtaW5l IGlmIHRoZSBjbGllbnQgc2hvdWxkIGJlIGFibGUgdG8gZ2V0IGFuIGFjY2VzcyB0b2tlbi4gSSB0 aGluayB0aGUgY3VycmVudCB0ZXh0IHdvdWxkIGltcGx5IG90aGVyd2lzZS4NCg0KU28gSSB3b3Vs ZCBwcm9wb3NlIGNoYW5naW5nIHRoZSBzZW50ZW5jZSB0byDigJxDbGllbnQgY3JlZGVudGlhbHMg YXJlIHVzZWQgYXMgYW4gYXV0aG9yaXphdGlvbiBncmFudCB3aGVuIHRoZSBjbGllbnQgaXMgYWN0 aW5nIG9uIGl0cyBvd24gYmVoYWxmICh0aGUgY2xpZW50IGlzIGFsc28gdGhlIHJlc291cmNlIG93 bmVyKSBvciB3aGVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBoYXMgZW5vdWdoIGNvbnRleHQg dG8gZGV0ZXJtaW5lIGZyb20gdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0IGlmIHRoZSBjbGllbnQg aGFzIGF1dGhvcml6YXRpb24gdG8gYWNjZXNzIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2Uu4oCd4oCd DQoNCjEuNC41LiBFeHRlbnNpb25zOiBDb21tZW50OiDigJxJIHdvdWxkIGNoYW5nZSB0aGlzIHNl bnRlbmNlIHRvIHJlYWQg4oCcQWRkaXRpb25hbCBncmFudCB0eXBlcyBtYXkgYmUgZGVmaW5lZCB0 byBzdXBwb3J0IG5ldyBhcHByb2FjaGVzIHRvIGF1dGhlbnRpY2F0aW9uL2F1dGhvcml6YXRpb24g YXMgd2VsbCBhcyB0byBwcm92aWRlIGEgYnJpZGdlIGJldHdlZW4gT0F1dGggYW5kIG90aGVyIHBy b3RvY29scy7igJ3igJ0NCg0KMS41LiBSZWZyZXNoIFRva2VuOiBDb21tZW50IG9uIOKAnFJlZnJl c2ggdG9rZW5zIGFyZSBjcmVkZW50aWFscyB1c2VkIHRvIG9idGFpbiBhY2Nlc3MgdG9rZW5zLuKA nTog4oCcVGhpcyBzZW50ZW5jZSBwcmVzdW1lcyB0aGF0IHJlZnJlc2ggdG9rZW5zIGFyZSBzZWxm LWNvbnRhaW5lZCBjcmVkZW50aWFscy4gSW4gb3RoZXIgd29yZHMgdGhhdCBvbmUgY2FuIGdldCBh biBhY2Nlc3MgdG9rZW4ganVzdCB1c2luZyBhIHJlZnJlc2ggdG9rZW4gYW5kIG5vdGhpbmcgZWxz ZS4gVGhpcyBwcmVzdW1wdGlvbiBpcyByZWJ1dHRlZCBsYXRlciBpbiB0aGUgZG9jdW1lbnQgYnV0 IEkgdGhpbmsgaXTigJlzIGNvbmZ1c2luZyB0byBpbXBseSBvbmUgdGhpbmcgaGVyZSBhbmQgc3Rh dGUgb3RoZXJ3aXNlIGxhdGVyIG9uLuKAnQ0KDQoxLjUuIFJlZnJlc2ggVG9rZW46IENoYW5nZSDi gJxhIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0c+KAnSB0byDigJxhIHByb3RlY3RlZCByZXNv dXJjZSByZXF1ZXN04oCdLg0KDQoxLjUuIFJlZnJlc2ggVG9rZW46IENvbW1lbnQgb24g4oCcKEcp ICBUaGUgY2xpZW50IHJlcXVlc3RzIGEgbmV3IGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGlu ZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcHJlc2VudGluZyB0aGUgcmVmcmVz aCB0b2tlbi7igJ06IOKAnEh1beKApiBub3cgdGhlIHRleHQgc2VlbXMgdG8gY29udHJhZGljdCBp dHNlbGYuIEFib3ZlIGl0IHNlZW1lZCBsaWtlIHlvdSBjb3VsZCB1c2UgdGhlIHJlZnJlc2ggdG9r ZW4gYnkgaXRzZWxmIHRvIGdldCBhbiBhY2Nlc3MgdG9rZW4gYW5kIEkgaGFkIHRvIGFzayBmb3Ig bGFuZ3VhZ2UgdGhhdCBtYWRlIGl0IGNsZWFyIHRoYXQgeW91IGNvdWxkIHVzZSBhIHJlZnJlc2gg dG9rZW4gd2l0aCBvdGhlciBjcmVkZW50aWFscy4gIEJ1dCB0aGUgdGV4dCBvZiBwb2ludCBHIG5v dyBpbXBsaWVzIHRoZSBleGFjdCBvcHBvc2l0ZSwgdGhhdCByZWZyZXNoIHRva2VucyBjYW4gb25s eSBiZSB1c2VkIHdpdGggb3RoZXIgY3JlZGVudGlhbHMgYW5kIG5vdCBieSB0aGVtc2VsdmVzLiAo RXZlbiB0aG91Z2ggdGhlIHBpY3R1cmUgaW4gZmlndXJlIDIgZm9yIHN0ZXAgRyBpbXBsaWVzIHRo ZSBvcHBvc2l0ZSkuIEkgd291bGQgZWRpdCB0aGlzIGxhbmd1YWdlIHRvIHNheSDigJxUaGUgY2xp ZW50IHJlcXVlc3RzIGEgbmV3IGFjY2VzcyB0b2tlbi4gRGVwZW5kaW5nIG9uIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlcuKAmXMgcG9saWNpZXMgdGhpcyByZXF1ZXN0IG1pZ2h0IGJlIG1hZGUgd2l0 aCB0aGUgcmVmcmVzaCB0b2tlbiBieSBpdHNlbGYgb3Igd2l0aCBhIGNvbWJpbmF0aW9uIG9mIHRo ZSByZWZyZXNoIHRva2VuIGFuZCBvdGhlciBjbGllbnQgY3JlZGVudGlhbHMu4oCd4oCdDQoNCjIu MS4gQ2xpZW50IFR5cGVzOiBDb21tZW50IG9uIOKAnHVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRp b27igJ06IOKAnEdpdmUgdGhlIHBvb3IgcmVhZGVyIGEgaGludCBhbmQgbWVudGlvbiDigJhicm93 c2Vy4oCZIHNvbWV3aGVyZSBpbiB0aGUgcGFyYWdyYXBoIGJlbG93LiBGb3IgZXhhbXBsZSDigJxB IHVzZXItYWdlbnQtYmFzZWQgYXBwbGljYXRpb24gaXMgYSBwdWJsaWMgY2xpZW50IChzdWNoIGFz IGEgd2ViIGJyb3dzZXIpIGluIHdoaWNoIHRoZeKApi7igJ3igJ0NCg0KMi4xLiBDbGllbnQgVHlw ZXM6IHdlYiBhcHBsaWNhdGlvbjogQ2hhbmdlIOKAnGFjY2VzcyB0b2tlbnMgb3IgcmVmcmVzaCB0 b2tlbnMsIGNhbiByZWNlaXZlIGFuIGFjY2VwdGFibGUgbGV2ZWzigJ0gdG8g4oCcYWNjZXNzIHRv a2VucyBvciByZWZyZXNoIHRva2VucywgY2FuLCBpbiBzb21lIGNhc2VzLCByZWNlaXZlIGFuIGFj Y2VwdGFibGUgbGV2ZWzigJ0uDQoNCjIuNC4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiAgQWRkIGEg cGVyaW9kIGFmdGVyIOKAnGV0Y+KAnS4NCg0KMi40LjEuIENsaWVudCBQYXNzd29yZDogQ29tbWVu dCBvbiDigJxjaGFyc2V0PVVURi044oCdOiDigJxUaGUgdXNlIG9mIFVURi04IHdpdGggeC13d3ct Zm9ybS11cmxlbmNvZGVkIGlzIGV4cGxpY2l0bHkgYmFubmVkIGJ5IEhUTUwgNC4wMSBzZWN0aW9u IDE3LjEzLjEuIElmIHdlIHdhbnQgdG8gdXNlIFVURi04IHRoZW4gd2UgaGF2ZSB0byB1c2UgbXVs dGlwYXJ0L2Zvcm0tZGF0YSwgYWxzbyBkZWZpbmVkIGJ5IEhUTUwgNC4wMSAoc2VjdGlvbiAxNy4x My40KS4gQnV0IHNpbmNlIG5vYm9keSB3b3VsZCBhY3R1YWxseSB3YW50IHRvIGRvIHRoYXQgSSB3 b3VsZCBzdWdnZXN0IHB1dHRpbmcgaW4gYSByZWZlcmVuY2UgdG8gc2VjdGlvbiA0LjIgb2YgUkZD IDU1NTIgd2hpY2ggYWN0dWFsbHkgZGVmaW5lcyBob3cgdG8gdXNlIFVURi04IHdpdGggeC13d3ct Zm9ybS11cmxlbmNvZGVkIGFuZCBzcGVjaWZ5aW5nIHRoYXQgdGhlIDU1NTIgZXh0ZW5zaW9uIE1V U1QgYmUgc3VwcG9ydGVkIGJ5IE9BdXRoIHBhcnRpY2lwYW50cy7igJ0NCg0KMy4xLiAgQXV0aG9y aXphdGlvbiBFbmRwb2ludDogQ29tbWVudCBvbiBmaXJzdCBzZW50ZW5jZTogIOKAnFRoZXJlIGlz IGEgdGhpcmQgb3B0aW9uIOKAkyBub25lIG9mIHRoZSBhYm92ZS4gIEl0IHdvdWxkIGJlIGEgc2hh bWUgaWYgdGhlIHRleHQgb2YgdGhpcyBkcmFmdCBleHBsaWNpdGx5IHByb2hpYml0cyB0aGF0IHBh dHRlcm4u4oCdDQoNCjMuMS4gIEF1dGhvcml6YXRpb24gRW5kcG9pbnQ6ICBDb21tZW50IG9uIOKA nFtSRkMzOTg2XSBzZWN0aW9uIDPigJ06IOKAnFNob3VsZG7igJl0IHdlIHBvaW50IGRpcmVjdGx5 IHRvIHNlY3Rpb24gMy40IHdoaWNoIGV4YWN0bHkgZGVmaW5lcyB0aGUgcXVlcnkgY29tcG9uZW50 P+KAnQ0KDQozLjEuICBBdXRob3JpemF0aW9uIEVuZHBvaW50OiAgQ29tbWVudCBvbiDigJxNVVNU IGJlIHJldGFpbmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnkNCiAgIHBhcmFtZXRlcnPi gJ06IOKAnEhJR0ggSU1QT1JUQU5DRSDigJMgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIGluY29tcGxl dGUuIFNlY3Rpb24gMy40IG9mIFJGQyAzOTg2IHNpbXBseSBhc3NlcnRzIHRoZSBleGlzdGVuY2Ug b2YgYSBxdWVyeSBjb21wb25lbnQuIEl0IHNheXMgbm90aGluZyBhYm91dCB0aGUgc3ludGF4IG9m IHRoYXQgY29tcG9uZW50LiBUaGUgc3BlYyBhc3N1bWVzIHRoYXQgdGhlIGNvbXBvbmVudCBpcyB1 c2luZyB4LXd3dy1mb3JtLXVybGVuY29kZWQgYnV0IHRoYXQgaXMgbm90IGluIGFueSB3YXkgbWFu ZGF0ZWQgYnkgUkZDIDM5ODYuIFNvIHRoZXJlIGlzIGEgbm9ybWF0aXZlIHNlbnRlbmNlIG1pc3Np bmcgaGVyZSB3aGljaCBzdGF0ZXMgdGhhdCBhbnkgcXVlcnkgcGFyYW1ldGVyIG9uIHRoZSBhdXRo b3JpemF0aW9uIGVuZHBvaW504oCZcyBVUkkgTVVTVCBiZSBkZWZpbmVkIGFzIHNwZWNpZmllZCBp biB4LXd3dy1mb3JtLXVybGVuY29kZWQu4oCdDQoNCjMuMS4gIEF1dGhvcml6YXRpb24gRW5kcG9p bnQ6ICBDb21tZW50IG9uIOKAnFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaWdub3Jl IHVucmVjb2duaXplZCByZXF1ZXN0IHBhcmFtZXRlcnMu4oCdOiDigJxBbHRob3VnaCB0aGF0IGlz IG5vcm1hbCBiZWhhdmlvciBmb3IgYXBwbGljYXRpb24gcHJvdG9jb2xzIGl0IHNlZW1zIHJhdGhl ciBkYW5nZXJvdXMgZm9yIGEgc2VjdXJpdHkgcHJvdG9jb2wuIEFmdGVyIGFsbCB3aGF0IGlmIHRo ZSBjbGllbnQgcHV0IGluIGEgcGFyYW1ldGVyIHNwZWNpZnlpbmcgc29tZXRoaW5nIHNlY3VyaXR5 IHJlbGF0ZWQgYWJvdXQgdGhlIHJlcXVlc3QgdGhpbmtpbmcgdGhhdCB0aGUgYXV0aG9yaXphdGlv biBlbmRwb2ludCB3b3VsZCBob25vciBpdCBhbmQgdGhlbiB0aGUgYXV0aG9yaXphdGlvbiBlbmRw b2ludCBzaWxlbnRseSBpZ25vcmVzIGl0PyAgQWdhaW4sIHRoaXMgaXMgYSBzZWN1cml0eSBwcm90 b2NvbCwgbm90IGEgZ2VuZXJpYyBhcHBsaWNhdGlvbiBwcm90b2NvbCwgaXQgc2VlbXMgdG8gYmUg dGhhdCB1bnJlY29nbml6ZWQgcGFyYW1ldGVycyBzaG91bGQgY2F1c2UgYSBmYWlsdXJlLuKAnQ0K DQozLjEuMi4gIFJlZGlyZWN0aW9uIEVuZHBvaW50OiBDb21tZW50IG9uIOKAnHdoZW4gaW5pdGlh dGluZyB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN04oCdOiDigJxJIHdvdWxkIHN1Z2dlc3QgbW9y ZSBleHBsaWNpdCBsYW5ndWFnZSDigJxvciBhcyBzcGVjaWZpZWQgaW4gdGhlIHJlZGlyZWN0aW9u IFVSSSB2YWx1ZSBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LuKAneKAnQ0KDQozLjEuMi4y LiBSZWdpc3RyYXRpb24gUmVxdWlyZW1lbnRzOiBDb21tZW50IG9uIGxhc3Qgd29yZCDigJxwYXRo 4oCdOiDigJxIdWg/IFNjaGVtZSwgYXV0aG9yaXphdGlvbiBhbmQgcGF0aCBpcyBhIGNvbXBsZXRl IFVSSSBtaW51cyBhIHF1ZXJ5IGNvbXBvbmVudC4gIElzIHRoZSBnb2FsIHRvIHNwZWNpZmljYWxs eSBtYW5kYXRlIHRoYXQgb25seSB0aGUgcXVlcnkgY29tcG9uZW50IGNhbiB2YXJ5IGFuZCB0aGUg cmVzdCBvZiB0aGUgVVJJIE1VU1QgYmUgc3RhdGljPyBJZiBzbyB0aGF0IHNob3VsZCBiZSBzdGF0 ZWQgZXhwbGljaXRseSByYXRoZXIgdGhhbiBpbXBsaWNpdGx5IGFzIGl0IGlzIG5vdy4gIEJ1dCBJ IHRoaW5rLCBpZiB0aGF0IGlzIHRoZSBpbnRlbnQsIGl0IGdvZXMgdG9vIGZhci4gV2Ugc2hvdWxk IGFsc28gYWxsb3cgZm9yIGFkZGl0aW9uYWwgcGF0aCBzZWdtZW50cyB0byBiZSBhZGRlZCB0byB0 aGUgVVJJIHBhdGggYmV5b25kIHRoZSByZWdpc3RlcmVkIHByZWZpeC4gQXNzdW1pbmcgd2UgY2Fu IGFkZHJlc3MgdGhlIHNlY3VyaXR5IHByb2JsZW0gaW4gdGhlIG5leHQgY29tbWVudC7igJ0NCg0K My4xLjIuMy4gRHluYW1pYyBDb25maWd1cmF0aW9uOiBDb21tZW50IG9uIOKAnHNlY3Rpb24gNuKA nTogIOKAnFRoZSByZWZlcmVuY2UgdG8gc2VjdGlvbiA2IGlzIGluY29tcGxldGUuIFNlY3Rpb24g NiBkZWZpbmVzIG5vIGxlc3MgdGhhbiA2IGRpZmZlcmVudCBheGlz4oCZcyBvbiB3aGljaCBVUkkg Y29tcGFyaXNvbnMgY2FuIHZhcnkuIEZ1cnRoZXJtb3JlIGFzIHJlY2VudGx5IGRvY3VtZW50ZWQg aW4gZHJhZnQtdGhhbGVyLWlhYi1pZGVudGlmaWVyLWNvbXBhcmlzb24tMDAudHh0IGl0IGlzIHRy aXZpYWxseSBlYXN5IHRvIHNjcmV3IHVwIFVSSSBjb21wYXJpc29ucyBhbmQgdGhlIHNlY3VyaXR5 IGltcGxpY2F0aW9ucyBhcmUgcHJldHR5IGRpcmUuIFBlcnNvbmFsbHkgSSB0aGluayB0aGF0IHRo ZSBvbmx5IHNhbmUgYXBwcm9hY2ggZ2l2ZW4gdGhlIGlzc3VlcyBpbiB0aGUgcHJldmlvdXMgbGlu ayBpcyB0byBhZG9wdCBzZWN0aW9uIDYuMi4xIG9mIFJGQyAzOTg2Lg0KDQpJIGFtIGEgYml0IHNj YXJlZCBvZiBob3cgdG8gaGFuZGxlIHBhcnRpYWwgbWF0Y2hlcy4gSXTigJlzIHRlbXB0aW5nIHRv IGFyZ3VlIHRoYXQgc28gbG9uZyBhcyB0aGUgc2NoZW1hIGhhcyBhbiBhdXRob3JpdHkgYW5kIGF0 IGxlYXN0IG9uZSBwYXRoIHNlZ21lbnQgdGhlbiB3ZSBjYW4ganVzdCB1c2UgYSBwYXJ0aWFsIHN0 cmluZyBtYXRjaCBidXQgYm95IG9oIGJveSBkbyBJIHNlZSBwZW9wbGUgc2NyZXdpbmcgdGhhdCBv bmUgdXAgcm95YWxseS4gVGhpcyBpcyBzY2FyeSBlbm91Z2ggdGhhdCBJIHRoaW5rIEkgY2FuIGJl IGFyZ3VlZCBpbnRvIHNheWluZyB0aGF0IHBhcnRpYWwgcHJlLXJlZ2lzdGVyZWQgVVJJcyBNVVNU IG9ubHkgZGlmZmVyIGJ5IHRoZSBxdWVyeSBjb21wb25lbnQuDQoNCkluIGFueSBjYXNlIHRoaXMg aXNzdWVzIG5lZWRzIHRvIGJlIGV4cGxpY2l0bHkgY2FsbGVkIG91dCBmb3IgYWxsIFVSSSBjb21w YXJpc29ucyByZXF1aXJlZCBieSB0aGUgc3BlYyBhbmQgbm9ybWF0aXZlbHkgZGVmaW5lZC4gT3Ro ZXJ3aXNlIHdlIHdpbGwgZW5kIHVwIHdpdGggYWxsIHRoZSBzZWN1cml0eSBpc3N1ZXMgaW4gRGF2 ZeKAmXMgSUQu4oCdDQoNCjMuMS4yLjQuICBJbnZhbGlkIEVuZHBvaW50OiBDb21tZW50IG9uIOKA nG9wZW4gcmVkaXJlY3RvcuKAnTog4oCcSG93IG1hbnkgcGVvcGxlIGV2ZW4ga25vdyB3aGF0IHRo ZSBoZWNrIGFuIG9wZW4gcmVkaXJlY3RvciBpcz8gSSB0aGluayB3ZSBuZWVkIGEgc2VjdGlvbiBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0aGF0IGRlZmluZXMgd2hhdCBh biBvcGVuIHJlZGlyZWN0b3IgaXMgYW5kIHdoeSBpdOKAmXMgYmFkLiBBbHRlcm5hdGl2ZWx5IGEg bm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhIGNvbXBsZXRlIGRlZmluaXRpb24gc29tZXdoZXJlIGVs c2UgaXMgYWxzbyBmaW5lLuKAnQ0KDQozLjIuMS4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiBDaGFu Z2Ug4oCcUmVjb3ZlcnnigJ0gdG8g4oCcUmVjb3ZlcmluZ+KAnS4NCg0KMy4yLjEuIENsaWVudCBB dXRoZW50aWNhdGlvbjogQ2hhbmdlIOKAnGNyZWRlbnRpYWxzLCBieSBwcmV2ZW50aW5nIGFuIGF0 dGFja2VyIGZyb20gYWJ1c2luZ+KAnSB0byDigJxjcmVkZW50aWFscy4gVGhpcyBwcmV2ZW50cyBh biBhdHRhY2tlciBmcm9tIGFidXNpbmfigJ0NCg0KMy4yLjEuIENsaWVudCBBdXRoZW50aWNhdGlv bjogQ2hhbmdlIOKAnHBlcmlvZGljIGNyZWRlbnRpYWxzIHJvdGF0aW9u4oCdIHRvIOKAnHBlcmlv ZGljIGNyZWRlbnRpYWwgcm90YXRpb27igJ0uDQoNCjMuMi4xLiBDbGllbnQgQXV0aGVudGljYXRp b246IENvbW1lbnQgb24g4oCcd2hpbGUgcm90YXRpb24gb2YgYSBzaW5nbGUgc2V0IG9mIGNsaWVu dCBjcmVkZW50aWFscyBpcyBzaWduaWZpY2FudGx5IGVhc2llcuKAnTog4oCcVGhlIHNwZWMgY2Fs bHMgb3V0IHJvdGF0aW9uIG9mIGNyZWRlbnRpYWxzIGFzIGJlaW5nIGNydWNpYWwgYnV0IHRoZW4g ZG9lc27igJl0IGRlZmluZSBob3cgdGhpcyBpcyB0byBiZSBkb25lPyBUaGF0IHNlZW1zIGtpbmQg b2Ygb2RkLiBTaG91bGRu4oCZdCB3ZSBkZWZpbmUgYW4gZW5kcG9pbnQgd2hlcmUgb25lIGNhbiBz dWJtaXQgb25l4oCZcyBvbGQgYnV0IHVuZXhwaXJlZCBjcmVkZW50aWFscyBmb3IgbmV3IG9uZXM/ IFRoaXMgc3RpbGwgbGVhdmVzIHRoZSBlZGdlIGNhc2Ugb2Ygd2hhdCB0byBkbyBpZiB0aGUgb2xk IGNyZWRlbnRpYWxzIGhhdmUgZXhwaXJlZCBhbmQgbmV3IG9uZXMgaGF2ZW7igJl0IGJlZW4gaXNz dWVkIGJ1dCB0aGF0IGlzIHVuYXZvaWRhYmxlIGFuZCBpbiB0aGF0IGNhc2Ugd2UgY2FuIHJlcXVp cmUgb3V0IG9mIHNjb3BlIGFjdGlvbi7igJ0NCg0KNC4xLiBBdXRob3JpemF0aW9uIENvZGU6IENv bW1lbnQgb24gZmlyc3Qg4oCcXuKAnTog4oCcU2hvdWxkbuKAmXQgdGhpcyBiZSBhIHYgY2hhcmFj dGVyIGFuZCBub3QgYSBePyBUaGlzIHdvdWxkIG1ha2UgaXQgY29uc2lzdGVudCB3aXRoIEEgd2hp Y2ggYWxzbyBjcm9zc2VzIHR3byBib3hlcyBhbmQgcG9pbnRzIGluIHRoZSBzYW1lIGRpcmVjdGlv bi7igJ0NCg0KNC4xLiBBdXRob3JpemF0aW9uIENvZGU6IENoYW5nZSDigJxJZiB2YWxpZCwgcmVz cG9uZHMgYmFjayB3aXRoIGFuIGFjY2VzcyB0b2tlbuKAnSB0byDigJxJZiB0aGUgcmVxdWVzdCBp cyB2YWxpZCwgdGhlbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCByZXNwb25kcyBiYWNr IHdpdGggYW4gYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbGx5IGEgcmVmcmVzaCB0b2tlbuKAnS4N Cg0KNC4xLjIuICBBdXRob3JpemF0aW9uIFJlc3BvbnNlOiBDb21tZW50IOKAnFRoZSBsYW5ndWFn ZSBhcm91bmQgc2NvcGVzIGluIHRoZSBkb2N1bWVudCBpcyByZWFsbHkgZnJ1c3RyYXRpbmcuIE9u ZSBvbmx5IGZpbmRzIG91dCBtdWNoIGxhdGVyIGluIHRoZSBkb2N1bWVudCB0aGF0IGl0IGlzIHBl cmZlY3RseSBhbGxvd2FibGUgZm9yIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIG1vcmUgb3Ig bGVzcyBpZ25vcmUgd2hhdCBzY29wZXMgYXJlIHN1Ym1pdHRlZCBhbmQgaW5zdGVhZCB0byBqdXN0 IHJldHVybiB3aGF0ZXZlciB0aGUgaGVsbCB0aGV5IHdhbnQuIFRoaXMgaXMgYSBmaW5lIGRlc2ln biBjaG9pY2UgYnV0IGl0IHNlZW1zIGxpa2UgdGhlIHNvcnQgb2YgdGhpbmcgdGhhdCBzaG91bGQg YmUgZm9yY2VmdWxseSByZXBlYXRlZCBhbnl3aGVyZSBpbiB0aGUgc3BlYyB0aGF0IHdlIGFsbG93 IHBlb3BsZSB0byBzdWJtaXQgc2NvcGVzIHNvIG5vYm9keSBmb3JnZXRzLuKAnQ0KDQo0LjEuMi4g IEF1dGhvcml6YXRpb24gUmVzcG9uc2U6IENvbW1lbnQgb24g4oCcc3RhdGXigJ06IOKAnERvbuKA mXQgd2UgaGF2ZSB0byBwcm92aWRlIHNvbWUgZ3VpZGFuY2Ugb24gaG93IGxhcmdlIHRoZSBzdGF0 ZSB2YWx1ZSBjYW4gc2FmZWx5IGJlPyBPdGhlcndpc2Ugd2UgYXJlIGFza2luZyBjbGllbnRzIHRv IHJld3JpdGUgdGhlaXIgc3RhdGUgbWVjaGFuaXNtcyBldmVyeSB0aW1lIHRoZXkgdGhyb3cgaW4g c3VwcG9ydCBmb3IgYSBuZXcgcHJvdGVjdGVkIHJlc291cmNlIHNlcnZlci4gV2UgaGF2ZSB0byBz ZXQgZXhwZWN0YXRpb25zIGFjcm9zcyB0aGUgaW5kdXN0cnkgaWYgd2UgYXJlIHRvIGhvcGUgZm9y IGFjdHVhbCBpbnRlcm9wZXJhYmlsaXR5LuKAnQ0KDQo0LjEuMi4xLiBFcnJvciBSZXNwb25zZTog Q29tbWVudCBvbiDigJxVVEYtOCBlbmNvZGVkIHRleHTigJ06IOKAnEkgdGhpbmsganVzdCBzYXlp bmcgVVRGLTggZW5jb2RlZCB0ZXh0IGNhbiBiZSBtaXNsZWFkaW5nLiBJdOKAmXMgbm90IGxlZ2Fs IHRvIHB1dCBVVEYtOCBjaGFyYWN0ZXJzIGludG8gYSB4LXd3dy1mb3JtLXVybGVuY29kZWQgdXNl ZCBpbiBhIEdFVCAoYXMgZGVmaW5lZCBieSBzZWN0aW9uIDE3LjEzLjEgb2YgSFRNTCA0LjAxKS4g U28gd2hhdCB5b3UgaGF2ZSB0byBkbyBpcyB0YWtlIHRoZSBVVEYtOCBTdHJpbmcgYW5kIHRoZW4g VVJMIGVuY29kZSBpdC4gV2hpY2ggaXMgZmluZSBidXQgd2Ugc2hvdWxkIGNhbGwgdGhpcyBvdXQu ICBOb3RlIHRoYXQgdGhpcyBpcyBhIHNlcGFyYXRlIGlzc3VlIHRoYW4gVVRGLTggc3VwcG9ydCBm b3IgeC13d3ctZm9ybS11cmxlbmNvZGVkLiBUaGF0IGlzc3VlIG9ubHkgYXBwbGllcyB3aGVuIHRo ZSBmb3JtIGlzIGluIHRoZSByZXF1ZXN0IGJvZHkuIEluIHRoaXMgc2NlbmFyaW8gdGhlIGZvcm0g aXMgaW4gYSBVUkwuIFRoZXJlIGlzIG5vIHF1ZXN0aW9uIHRoYXQgVVJMcyBpbiBIVFRQIHJlcXVl c3QgbGlzdHMgZG9u4oCZdCBzdXBwb3J0IFVURi04LuKAnQ0KDQo0LjEuMy4gQWNjZXNzIFRva2Vu IFJlcXVlc3Q6IENoYW5nZSDigJxGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0aGUgZm9s bG93aW5nIEhUVFAgdXNpbmfigJ0gdG8g4oCcRm9yIGV4YW1wbGUsIGlmIHRoZSBjbGllbnQgbWFr ZXMgdGhlIGZvbGxvd2luZyBIVFRQIHJlcXVlc3QgdXNpbmfigJ0NCg0KNC4xLjMuIEFjY2VzcyBU b2tlbiBSZXF1ZXN0OiBDb21tZW50IG9uIOKAnHRoYXQgdGhlaXIgdmFsdWVzIGFyZSBpZGVudGlj YWzigJ06IOKAnFRoaXMgdmVyYmlhZ2UgaXNu4oCZdCBtdWNoIHVzZSwgZm9yIGV4YW1wbGUsIGlm IHRoZSBjbGllbnQgY2FuIGFsd2F5cyBzZW5kIHRoZSBzYW1lIHJlZGlyZWN0X3VyaS4gU28sIGp1 c3QgdG8gYmUgY2xlYXIsIHRoaXMgdGV4dCBoZXJlIGRvZXNu4oCZdCBpbiBhbnl3YXkgY2hhbmdl IG15IHByZXZpb3VzIHJlY29tbWVuZGF0aW9uIHJlZ2FyZGluZyB0aGUgYXR0YWNrIHByZXZpb3Vz bHkgZGVzY3JpYmVkLuKAnQ0KDQo0LjEuNC4gQWNjZXNzIFRva2VuIFJlc3BvbnNlOiBDb21tZW50 IG9uIOKAnCJ0b2tlbl90eXBlIjoiZXhhbXBsZSLigJ06IOKAnEp1c3QgdG8gcHJldmVudCBhbnkg Y29uZnVzaW9uIGl0IHdvdWxkIGJlIGdvb2QgdG8gYWN0dWFsbHkgZGVmaW5lIHRoZSB0b2tlbl90 eXBlIOKAnGV4YW1wbGXigJ0gaW4gdGhpcyBkb2N1bWVudCAoUHJvYmFibHkgaW4gc2VjdGlvbiA3 LjEgYW5kIGxhdGVyIGluIHRoZSBJQU5BIHNlY3Rpb24pIGFuZCBzcGVjaWZ5IHRoYXQgaXQgaXMg cmVzZXJ2ZWQgZm9yIHVzZSBpbiBleGFtcGxlcyB3aGVyZSBvbmUgZG9lcyBub3Qgd2lzaCB0byBi ZSBtb3JlIHNwZWNpZmljLuKAnQ0KDQo0LjIuICBJbXBsaWNpdCBHcmFudDogQ29tbWVudCDigJxJ IGhhdmUgcnVuIGludG8gbXVsdGlwbGUgcGVvcGxlIChpbmNsdWRpbmcgbXlzZWxmKSB3aG8gaGF2 ZSByZWFkIHRoZSBPQXV0aCBzcGVjIGFuZCBjYW1lIGF3YXkgY29tcGxldGVseSBjb25mdXNlZCBh Ym91dCB3aGVuIHRoZSBoZWNrIG9uZSBpcyBzdXBwb3NlZCB0byB1c2UgdGhlIGltcGxpY2l0IGdy YW50IGZsb3cgZm9yLiBJdOKAmXMgbm90IGltbWVkaWF0ZWx5IG9idmlvdXMgdGhhdCBpdOKAmXMg YSB3YXkgdG8gc3VwcG9ydCBzdGFuZGFsb25lIGJyb3dzZXIgYmFzZWQgY2xpZW50cy4gQ2FuIHdl IHB1dCBpbiBhbiBleGFtcGxlIG9yIHNvbWV0aGluZyB0byBtYWtlIGl0IG1vcmUgb2J2aW91cyB3 aHkgaXTigJlzIGhlcmU/4oCdDQoNCjQuMi4xLiBBdXRob3JpemF0aW9uIFJlcXVlc3Q6IENvbW1l bnQgb24gcmVkaXJlY3RfdXJpOiAg4oCcR2l2ZW4gdGhhdCB0aGUgb25seSB3YXkgdG8gaWRlbnRp ZnkgdGhlIGNsaWVudCBpbiB0aGUgaW1wbGljaXQgZ3JhbnQgZmxvdyBpcyB2aWEgdGhlIHJlZGly ZWN0X3VyaSwgaG93IGNhbiBpdCBiZSBvcHRpb25hbD/igJ0NCg0KNC4zLiBSZXNvdXJjZSBPd25l ciBQYXNzd29yZCBDcmVkZW50aWFsczogQ2hhbmdlIOKAnGVuYWJsaW5nIHRoZSBncmFudCB0eXBl LCBhbmQgb25seSB3aGVuIG90aGVyIGZsb3dz4oCdIHRvIOKAnGVuYWJsaW5nIHRoZSBncmFudCB0 eXBlIGFuZCBvbmx5IHVzZSBpdCB3aGVuIG90aGVyIGZsb3dz4oCdLg0KDQo0LjMuIFJlc291cmNl IE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzOiBDaGFuZ2Ug4oCccmVzb3VyY2Ugb3duZXIgY3Jl ZGVudGlhbHPigJ0gdG8g4oCccmVzb3VyY2Ugb3duZXLigJlzIGNyZWRlbnRpYWxz4oCdLg0KDQo0 LjMuMi4gQWNjZXNzIFRva2VuIFJlcXVlc3Q6ICBDb21tZW50IG9uIOKAnGF1dGhvcml6YXRpb24g c2VydmVyIE1VU1QgcHJvdGVjdCB0aGUgZW5kcG9pbnQgYWdhaW5zdCBicnV0ZSBmb3JjZSBhdHRh Y2tz4oCdOiDigJxTaG91bGRu4oCZdCB0aGUgcmVxdWlyZW1lbnQgdG8gcHJldmVudCBhZ2FpbnN0 IGJydXRlIGZvcmNlIGF0dGFja3MgYXBwbHkgdG8gYWxsIGNyZWRlbnRpYWxzLCByZXNvdXJjZSBv d25lciBvciBvdGhlcndpc2U/IEluIG90aGVyIHdvcmRzIGluIHNlY3Rpb24gMi40LjEgd2UgdGFs ayBhYm91dCBob3cgY2xpZW50cyBzdWJtaXQgdGhlaXIgbmFtZS9wYXNzd29yZC4gU2hvdWxkbuKA mXQgZW5kcG9pbnRzIGFjY2VwdGluZyBjbGllbnQgbmFtZS9wYXNzd29yZHMgaGF2ZSB0aGUgc2Ft ZSBwcm90ZWN0aW9ucyBhZ2FpbnN0IGJydXRlIGZvcmNlIGF0dGFjaz/igJ0NCg0KNC40LjMuIEFj Y2VzcyBUb2tlbiBSZXNwb25zZTogQ29tbWVudCBvbiDigJxBIHJlZnJlc2ggdG9rZW4gU0hPVUxE IE5PVCBiZSBpbmNsdWRlZOKAnTog4oCcV2h5IGlzbuKAmXQgdGhpcyBhIE1VU1QgTk9UP+KAnQ0K DQo0LjUuIEV4dGVuc2lvbnM6IENvbW1lbnQg4oCcSXNu4oCZdCB0aGUgdGV4dCBpbiB0aGlzIHNl Y3Rpb24gYW5kIDguMyByZWR1bmRhbnQgd2l0aCBlYWNoIG90aGVyPyBJdCBzZWVtcyBsaWtlIHdl IHNob3VsZCB0YWtlIHRoZSB0ZXh0IGZyb20gaGVyZSBhbmQgbWVyZ2UgaXQgd2l0aCBzZWN0aW9u IDguMyBzbyBhbGwgdGhlIGV4dGVuc2lvbiBpbmZvcm1hdGlvbiBpcyByZWNvcmRlZCBpbiBvbmUg cGxhY2UuICBJdOKAmXMganVzdCBwbGFpbiB0aGF0IGFsbCBvdGhlciBleHRlbnNpb24gcG9pbnRz IGFyZSBpbiBzZWN0aW9uIDggYnV0IHRoaXMgb25lLuKAnQ0KDQo1LjEuIFN1Y2Nlc3NmdWwgUmVz cG9uc2U6IENvbW1lbnQgb24g4oCccGFyYW1ldGVyIGF0IHRoZSBoaWdoZXN0IHN0cnVjdHVyZSBs ZXZlbOKAnTog4oCcQXJlIHRoZXJlIGFueSBndWFyYW50ZWVzIGFib3V0IHRoZSBvcmRlciBvZiB0 aGUgbWVtYmVycyBpbiB0aGUgSlNPTiBvYmplY3Q/IElmIG5vdCB3ZSBzaG91bGQgc2F5IHNvIGV4 cGxpY2l0bHku4oCdDQoNCjUuMi4gRXJyb3IgUmVzcG9uc2U6IENvbW1lbnQgb24g4oCcbXVsdGlw bGUgY2xpZW50IGF1dGhlbnRpY2F0aW9ucyBpbmNsdWRlZOKAnSBpbiBpbnZhbGlkX2NsaWVudDog 4oCcU2hvdWxkbuKAmXQgdGhpcyBiZSBhbiBpbnZhbGlkX3JlcXVlc3Q/4oCdDQoNCjUuMi4gRXJy b3IgUmVzcG9uc2U6IENvbW1lbnQgb24g4oCcTnVtZXJpY2FsIHZhbHVlcyBhcmUgaW5jbHVkZWQg YXMgSlNPTiBudW1iZXJz4oCdOiDigJxTYW1lIGlzc3VlIGFzIGJlZm9yZSwgZG9lcyBvcmRlcmlu ZyBtYXR0ZXIgYW5kIGlmIG5vdCB3ZSBuZWVkIHRvIHNheSB0aGF0LuKAnQ0KDQo4LjEuIERlZmlu aW5nIEFjY2VzcyBUb2tlbiBUeXBlczogQ2hhbmdlIOKAnG9yIHVzZSBhIHVuaXF1ZeKAnSB0byDi gJxvciB1c2luZyBhIHVuaXF1ZeKAnS4NCg0KOS4gIE5hdGl2ZSBBcHBsaWNhdGlvbnM6ICBDaGFu Z2Ug4oCcYW4gc2NoZW1l4oCdIHRvIOKAnGEgc2NoZW1l4oCdDQoNCjkuICBOYXRpdmUgQXBwbGlj YXRpb25zOiAgQ2hhbmdlIOKAnG9mZmVyIGFuIGltcHJvdmVkIHVzYWJpbGl0eeKAnSB0byDigJxv ZmZlciBpbXByb3ZlZCB1c2FiaWxpdHnigJ0NCg0KOS4gIE5hdGl2ZSBBcHBsaWNhdGlvbnM6ICBD aGFuZ2Ug4oCcaW5hYmlsaXR5IHRvIGtlZXAgY3JlZGVudGlhbHMgY29uZmlkZW50aWFs4oCdIHRv IOKAnGluYWJpbGl0eSB0byBrZWVwIGNsaWVudCBjcmVkZW50aWFscyBjb25maWRlbnRpYWzigJ0u DQoNCjkuICBOYXRpdmUgQXBwbGljYXRpb25zOiAgQ2hhbmdlIOKAnFdoZW4gdXNpbmcgdGhlIGlt cGxpY2l0IGdyYW50IHR5cGUgZmxvdyBhIHJlZnJlc2ggdG9rZW4gaXMgbm90IHJldHVybmVk4oCd IHRvIOKAnFdoZW4gdXNpbmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgZmxvdyBhIHJlZnJlc2gg dG9rZW4gaXMgbm90IHJldHVybmVkIHNvIG9uY2UgdGhlIGFjY2VzcyB0b2tlbiBleHBpcmVzIHRo ZSBhcHBsaWNhdGlvbiB3aWxsIGhhdmUgdG8gcmVwZWF0IHRoZSBhdXRob3JpemF0aW9uIHByb2Nl c3PigJ0uDQoNCjEwLjIuIENsaWVudCBJbXBlcnNvbmF0aW9uOiAgQ2hhbmdlIOKAnGtlZXAgaXMg Y2xpZW504oCdIHRvIOKAnGtlZXAgaXRzIGNsaWVudOKAnS4NCg0KMTAuMi4gQ2xpZW50IEltcGVy c29uYXRpb246ICBDaGFuZ2Ug4oCcZHVlIHRvIHRoZSBjbGllbnQgbmF0dXJl4oCdIHRvIOKAnGR1 ZSB0byB0aGUgY2xpZW504oCZcyBuYXR1cmXigJ0uDQoNCjEwLjIuIENsaWVudCBJbXBlcnNvbmF0 aW9uOiAgQ2hhbmdlIOKAnFVSSSB1c2VkIGZvciByZWNlaXZpbmcgYXV0aG9yaXphdGlvbuKAnSB0 byDigJxVUkkgdXNlZCBmb3IgcmVjZWl2aW5nIGF1dGhvcml6YXRpb24gcmVxdWVzdHPigJ0NCg0K MTAuMi4gQ2xpZW50IEltcGVyc29uYXRpb246ICBDaGFuZ2Ug4oCcZW5nYWdlIHRoZSByZXNvdXJj ZSBvd25lcuKAnSB0byDigJxlbmdhZ2luZyB0aGUgcmVzb3VyY2Ugb3duZXLigJ0uDQoNCjEwLjIu IENsaWVudCBJbXBlcnNvbmF0aW9uOiAgQ2hhbmdlIOKAnGFuZCBhdXRob3JpemUgdGhlIHJlcXVl c3TigJ0gdG8g4oCcYW5kIGF1dGhvcml6ZSBvciByZWplY3QgdGhlIHJlcXVlc3TigJ0uDQoNCjEw LjMuIEFjY2VzcyBUb2tlbnM6IENoYW5nZSDigJxBY2Nlc3MgdG9rZW4gKGFzIHdlbGwgYXMgYW55 IGFjY2VzcyB0b2tlbiB0eXBlLXNwZWNpZmljIGF0dHJpYnV0ZXMp4oCdIHRvIOKAnEFjY2VzcyB0 b2tlbnMgKGFzIHdlbGwgYXMgYW55IGFjY2VzcyB0b2tlbiB0eXBlIHNwZWNpZmljIGF0dHJpYnV0 ZXMp4oCdLg0KDQoxMC4zLiBBY2Nlc3MgVG9rZW5zOiBDaGFuZ2Ug4oCcZ3Vlc3NlZCB0byBwcm9k dWNl4oCdIHRvIOKAnGd1ZXNzZWQgc28gYXMgdG8gcHJldmVudCB1bmF1dGhvcml6ZWQgcGFydGll cyBmcm9tIHByb2R1Y2luZ+KAnS4NCg0KMTAuNC4gUmVmcmVzaCBUb2tlbnM6IENvbW1lbnQg4oCc QXMgbWVudGlvbmVkIHByZXZpb3VzbHkgd2UgcmVhbGx5IHNob3VsZCBleHBsYWluIHdoeSB3ZSBp bnRyb2R1Y2VkIHJlZnJlc2ggdG9rZW5zLiBXaXRob3V0IHVuZGVyc3RhbmRpbmcgdGhlIGludGVu dCBvZiB0aGUgbWVjaGFuaXNtIGl04oCZcyB1bmxpa2VseSBpbXBsZW1lbnRlcnMgd2lsbCB1c2Ug dGhlbSBhcHByb3ByaWF0ZWx5LuKAnQ0KDQoxMC40LiBSZWZyZXNoIFRva2VuczogIENoYW5nZSDi gJxzdG9yYWdlLCBhbmQgc2hhcmVkIG9ubHkgYW1vbmfigJ0gdG8g4oCcc3RvcmFnZSwgYW5kIGFy ZSB0byBiZSBzaGFyZWQgb25seSBhbW9uZ+KAnS4NCg0KMTAuNC4gUmVmcmVzaCBUb2tlbnM6ICBD aGFuZ2Ug4oCccmVmcmVzaCB0b2tlbnMgcm90YXRpb27igJ0gdG8g4oCccmVmcmVzaCB0b2tlbiBy b3RhdGlvbuKAnS4NCg0KMTAuNC4gUmVmcmVzaCBUb2tlbnM6ICBDaGFuZ2Ug4oCcZ3Vlc3NlZCB0 byBwcm9kdWNl4oCdIHRvIOKAnGd1ZXNzZWQgc28gYXMgdG8gcHJldmVudCB1bmF1dGhvcml6ZWQg cGFydGllcyBmcm9tIHByb2R1Y2luZ+KAnS4NCg0KMTAuNi4gQXV0aG9yaXphdGlvbiBDb2RlIExl YWthZ2U6IENvbW1lbnQg4oCcSSBmYW5jeSBteXNlbGYgYXMgYmVpbmcgcmVhc29uYWJseSBpbnRl bGxpZ2VudCBhbmQgSeKAmW0gdW5jbGVhciB3aGF0IGF0dGFjayBpcyBhY3R1YWxseSBiZWluZyBk ZXNjcmliZWQgaGVyZS7igJ0NCg0KMTAuNi4gQXV0aG9yaXphdGlvbiBDb2RlIExlYWthZ2U6IENv bW1lbnQgb24g4oCcVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCByZXF1aXJlIHRoZSBj bGllbnQgdG8gcmVnaXN0ZXIgdGhlaXIgcmVkaXJlY3Rpb24gVVJJ4oCdOiDigJxXaHkgaXMgdGhp cyBhIHNob3VsZD/igJ0NCg0KMTAuNy4gUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlh bHM6IENvbW1lbnQgb24g4oCccGFzc3dvcmQgYW50aS1wYXR0ZXJu4oCdOiDigJxJcyBpdCBmYWly IHRvIGV4cGVjdCB0aGF0IHRoZSByZWFkZXIga25vd3Mgd2hhdCB0aGUgcGFzc3dvcmQgYW50aS1w YXR0ZXJuIGlzPyBTaG91bGRu4oCZdCBzb21lIHJlZmVyZW5jZSB0byBhIGRlZmluaXRpb24gb2Yg dGhpcyBwYXR0ZXJuIGJlIHJlcXVpcmVkP+KAnQ0KDQoxMC43LiBSZXNvdXJjZSBPd25lciBQYXNz d29yZCBDcmVkZW50aWFsczogQ29tbWVudCBvbiDigJxUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg U0hPVUxEIHJlc3RyaWN0IHRoZSBzY29wZSBhbmQgbGlmZXRpbWUgb2YgYWNjZXNzIHRva2VucyBp c3N1ZWQgdmlhIHRoaXMgZ3JhbnQgdHlwZeKAnTog4oCcUmVzdHJpY3QgaW4gd2hhdCB3YXlzPyBC YXNlZCBvbiB3aGF0IGNyaXRlcmlhPyBUaGlzIHN0YXRlbWVudCBpcyB0aGUgZXF1aXZhbGVudCBv ZiBzYXlpbmcg4oCcZG9u4oCZdCBkbyBiYWQgc3R1ZmbigJ0uIFBlcmhhcHMgdHJ1ZSBidXQgbm90 IHRlcnJpYmx5IHVzZWZ1bC7igJ0NCg0KMTAuMTIuIENyb3NzLVNpdGUgUmVxdWVzdCBGb3JnZXJ5 OiBDb21tZW50IG9uIGZpcnN0IHBhcmFncmFwaDog4oCcSSBjaGFsbGVuZ2UgYW55IHJlYXNvbmFi bHkgaW50ZWxsaWdlbnQgcGVyc29uIHdobyBkb2VzIG5vdCBhbHJlYWR5IGtub3cgd2hhdCBhIENT UkYgaXMgdG8gcmVhZCB0aGlzIHBhcmFncmFwaCBhbmQgY29tZSBhd2F5IGFueSBjbGVhcmVyIGFz IHRvIHdoYXQgaXMgYmVpbmcgZGlzY3Vzc2VkLiBBdCBhIG1pbmltdW0gaXNu4oCZdCBzb21lIHJl ZmVyZW5jZSB0byBhIGNvbXBsZXRlIGRlZmluaXRpb24gb2YgQ1NSRiBuZWVkZWQgaWYgdGhlcmUg aXMgdG8gYmUgYW55IGhvcGUgb2YgdXNlciBjb21wbGlhbmNlP+KAnQ0KDQoxMC4xMi4gQ3Jvc3Mt U2l0ZSBSZXF1ZXN0IEZvcmdlcnk6IENvbW1lbnQgb24g4oCcVGhlICJzdGF0ZSIgcmVxdWVzdCBw YXJhbWV0ZXIgTVVTVCBjb250YWluIGEgbm9uLWd1ZXNzYWJsZSB2YWx1ZeKAnTog4oCcQWN0dWFs bHkgYSBub24tZ3Vlc3NhYmxlIHZhbHVlIHdvbuKAmXQgc3RvcCB0aGUgYXR0YWNrIGRpc2N1c3Nl ZCBpbiB0aGUgcHJldmlvdXMgcGFyYWdyYXBoIG9uIGl0cyBvd24uIFdoYXTigJlzIGFsc28gbmVl ZGVkIGlzIGEgd2F5IHRvIHVuaXF1ZWx5IChhbmQgdW5icmVha2FibHkpIGFzc29jaWF0ZSB0aGUg c3RhdGUgd2l0aCBhIHBhcnRpY3VsYXIgdXNlciBzbyB0aGF0IGlmIGFuIGF1dGhvcml6YXRpb24g Y29kZSBzd2FwIG9jY3VycyBpdCBjYW4gYmUgcmVsaWFibHkgZGV0ZWN0ZWQu4oCdDQoNCjEwLjEz LiBDbGlja2phY2tpbmc6IENvbW1lbnQgb24g4oCceC1mcmFtZS1vcHRpb25z4oCdOiDigJxUaGUg cmVjb21tZW5kYXRpb24gc2VlbXMgY29uZnVzZWQuIElzIGl0IG8uay4gdG8ganVzdCByZWx5IG9u IHgtZnJhbWUtb3B0aW9ucyBvciBNVVNUIG90aGVyIGFjdGlvbnMgYmUgdGFrZW4/4oCdDQoNCjEx LjEuICBUaGUgT0F1dGggQWNjZXNzIFRva2VuIFR5cGUgUmVnaXN0cnk6IENoYW5nZSDigJx0b2tl IHR5cGXigJ0gdG8g4oCcdG9rZW4gdHlwZeKAnS4NCg0KMTEuMS4xLiAgUmVnaXN0cmF0aW9uIFRl bXBsYXRlOiBDaGFuZ2Ug4oCccHJvdGVjdGVkIHJlc291cmNlcyByZXF1ZXN0cyB1c2luZyBhY2Nl c3MgdG9rZW7igJ0gdG8g4oCccHJvdGVjdGVkIHJlc291cmNlIHJlcXVlc3RzIHVzaW5nIGFjY2Vz cyB0b2tlbnPigJ0uDQoNCjExLjEuMS4gIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZTogIENoYW5nZSDi gJxSZWZlcmVuY2UgdG8gZG9jdW1lbnTigJ0gdG8g4oCcUmVmZXJlbmNlIHRvIHRoZSBkb2N1bWVu dOKAnS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ck9BdXRoIG1haWxpbmcgbGlzdA0KPG1haWx0bzpPQXV0aEBpZXRmLm9yZz5PQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo DQo= --_000_9C1A8698157C4FB89FAA016FD4722951hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5KdXN0IHdhbnQgdG8gbWFrZSBzdXJl IGl0IGlzIGNvdmVyZWQgYnkgdGhlIG5vcm1hbCBjb250cmlidXRpb24gcnVsZS4mbmJzcDs8YnI+ PGJyPk9uIEF1ZyAxMSwgMjAxMSwgYXQgMTA6NTgsICJBbnRob255IE5hZGFsaW4iICZsdDs8YSBo cmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208 L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGRpdj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGUgaXMgb3V0 IG9uIHZhY2F0aW9uIHdpdGggbm8gYWNjZXNzIGFuZCBoZSBsZWZ0IE1pa2Ugd2l0aCBhIGJ1bmNo IG9mIGNvbW1lbnRzIHRvIHB1bGwgdG9nZXRoZXIgdG8gc3VibWl0IGFuZCB3ZSBrbmV3IHRoYXQg eW91IHdhbnRlZCB0aGVzZSBjb21tZW50cyB0byBlbnN1cmUNCiB0aGF0IHRoZSBzcGVjIGlzIHRo ZSBiZXN0IGl0IGNhbiBiZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiA8YSBocmVmPSJtYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmFuIEhhbW1lci1M YWhhdjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAxMCwgMjAxMSA1OjE5IFBN PGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhA aWV0Zi5vcmc8L2E+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBQYXJ0 aWFsIHNldCBvZiBsYXN0IGNhbGwgY29tbWVudHMgb24gT0F1dGggZHJhZnQgMjAgZnJvbSBZYXJv biBHb2xhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JcyB0aGVyZSBhIHJlYXNvbiB3aHkg TXIgR29sYW5kIGlzbnQgc2VuZGluZyBoaXMgb3duIGNvbW1lbnRzIGluPzxicj4NCjxicj4NCk9u IEF1ZyAxMCwgMjAxMSwgYXQgMTc6MzksICJNaWtlIEpvbmVzIiAmbHQ7PGEgaHJlZj0ibWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPjwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4xLjQuIEF1dGhvcml6YXRpb24gR3JhbnQ6IENoYW5nZSDigJxyZXNvdXJj ZSBvd25lciBhdXRob3JpemF0aW9u4oCdIHRvIOKAnHJlc291cmNlIG93bmVy4oCZcyBhdXRob3Jp emF0aW9u4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS40LjEuIEF1dGhvcml6YXRp b24gQ29kZTombmJzcDsgQ29tbWVudDog4oCcSXQgc2VlbXMgb2RkIHRoYXQgd2UgY2FuIGRpc2N1 c3MgdGhlIGF1dGhvcml6YXRpb24gY29kZSB3aXRob3V0IGFsc28gZGlzY3Vzc2luZyB0aGUgc2Vj dXJpdHkgaXNzdWVzIGl0IHJhaXNlcyAoZS5nLiBwYXNzaW5nIHNlY3VyZSBpbmZvcm1hdGlvbg0K IHZpYSBhIGJyb3dzZXIpIGFuZCB0aHVzIG1vdGl2YXRpbmcgdGhlIGludHJvZHVjdGlvbiBvZiB0 aGUgcmVmcmVzaCB0b2tlbi4gSSB3b3VsZCBleHBlY3QgdGhpcyB0byBiZSByZWZlcnJlZCB0byBo ZXJlLiZuYnNwOyBIYXZpbmcgcmVhZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlv biBJIGNhbiBmaW5kIG5vIGNvaGVyZW50IGRpc2N1c3Npb24gdGhlcmUgZWl0aGVyIG9mIHRoZSBy ZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgYXV0aG9yaXphdGlvbg0KIGNvZGUgYW5kIHRoZSByZWZy ZXNoIHRva2VuIGFuZCB3aHkgb25lIG1vdGl2YXRlZCB0aGUgb3RoZXIuIEkgdGhpbmsgdGhpcyBp cyBzb21ldGhpbmcgaW1wb3J0YW50IGZvciBpbXBsZW1lbnRlcnMgdG8gdW5kZXJzdGFuZC7igJ08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuNC4yLiZuYnNwOyBJbXBsaWNpdDombmJzcDsg Q29tbWVudDog4oCcSSBmaW5kIHRoaXMgc2VjdGlvbiBjb25mdXNpbmcuIEkgdGhpbmsgYW4gZXhh bXBsZSBpcyBhbGwgYnV0IG1hbmRhdG9yeSBoZXJlIGlmIHRoZSByZWFkZXIgaXMgdG8gdW5kZXJz dGFuZCB3aGF0IGlzIGludGVuZGVkLiZuYnNwOyBGb3IgZXhhbXBsZSwgd2hlbiBJIGZpcnN0DQog cmVhZCB0aGlzIHNlY3Rpb24gSSB0aG91Z2h0IGl0IHdhcyBzb21lIGtpbmQgb2Ygc2hvcnQgY3V0 IHVzZWQgaW4gY2FzZXMgd2hlcmUgdGhlIGNsaWVudCBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg aGFkIGEgY2xvc2UgcmVsYXRpb25zaGlwIGFuZCBjb3VsZCBzaGFyZSBpbmZvcm1hdGlvbiBzdWNo IGFzIHRoZSBjbGllbnTigJlzIGlkZW50aXR5IHNvIG5vIGFjY2VzcyBjb2RlIHdhcyBuZWVkZWQu Jm5ic3A7IE5vIHdoZXJlIGluIGhlcmUgaXMgYW55IGhpbnQNCiB0aGF0IHRoaXMgaXMgYWJvdXQg YnJvd3NlciBiYXNlZCBjbGllbnRzIHdobyBkb27igJl0IGhhdmUgc2VydmVycyBhbmQgd2hvIG5l ZWQgYSB3YXkgdG8gZ2V0IHRva2Vucy4gU2VyaW91c2x5LiBUcnkgdG8gcmVhZCB0aGlzIHNlY3Rp b24gYXMgc29tZW9uZSB3aG8ga25vd3Mgbm90aGluZyBhYm91dCBPQXV0aCBhbmQgdGVsbCBtZSB0 aGF0IHlvdSBnZXQgdGhlIHJpZ2h0IGlkZWEgYmFjayBmcm9tIGl0LiBJdCBuZWVkcyB0byBiZSB3 cml0dGVuIHRvIGJlDQogYm90aCBleHBsaWNpdCBhcyB0byBpdHMgZ29hbHMgYW5kIGNsZWFyZXIg YXMgdG8gaXRzIG1lYW5zLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS40LjIuJm5i c3A7IEltcGxpY2l0OiZuYnNwOyBDaGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPmF1dGhlbnRpY2F0 ZSB0aGUgY2xpZW50IGFuZCB0aGU8L3NwYW4+4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5hdXRo ZW50aWNhdGUgdGhlIGNsaWVudCBkaXJlY3RseS4gVGhlPC9zcGFuPuKAnS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjEuNC4yLiZuYnNwOyBJbXBsaWNpdDombmJzcDsgQ2hhbmdlIOKAnHdl aWdodGVk4oCdIHRvIOKAnHdlaWdoZWTigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4x LjQuMy4mbmJzcDsgUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHM6IENvbW1lbnQg b24g4oCcKHdoZW4gY29tYmluZWQgd2l0aCBhIHJlZnJlc2ggdG9rZW4p4oCdOiDigJxUaGlzIGlz IHRoZSBmaXJzdCB0aW1lIHRoYXQgcmVmcmVzaCB0b2tlbnMgYXJlIG1lbnRpb25lZCBpbiB0aGUg c3BlYy4gQW5kIHlldCB0aGVyZQ0KIGlzIG5vIGV4cGxhbmF0aW9uIG9mIHdoYXQgdGhleSBhcmUu IEkgc3VzcGVjdCB0aGV5IHNob3VsZCBhbnl3YXkgYmUgaW50cm9kdWNlZCBpbiBzZWN0aW9uIDEu NC4xIChhcyBwcmV2aW91c2x5IG5vdGVkKSBhbmQgdGhlbiB0aGVpciB1c2UgaGVyZSB3aWxsIG1h a2Ugc2Vuc2UuJm5ic3A7IElmIHRoYXQgaXNu4oCZdCBwb3NzaWJsZSB0aGVuIGl0IHdvdWxkIGJl IGdvb2QgdG8gaGF2ZSBhIGZvcndhcmQgcmVmZXJlbmNlIHRvIHNlY3Rpb24gMS41IGJlbG93IHNv DQogdGhlIHJlYWRlciBoYXMgc29tZSBpZGVhIG9mIHdoYXTigJlzIGdvaW5nIG9uLuKAnTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS40LjQuJm5ic3A7IENsaWVudCBDcmVkZW50aWFsczom bmJzcDsgQ29tbWVudCBvbiDigJwodGhlIGNsaWVudCBpcyBhbHNvIHRoZSByZXNvdXJjZSBvd25l cinigJ06IOKAnEkgdGhpbmsgdGhpcyBpcyBtaXNsZWFkaW5nLiBJbWFnaW5lIHNvbWV0aGluZyBs aWtlIE9mZmljZSB3aGVyZSBhIGNsaWVudCBoYXMgYmVlbiBncmFudGVkIGFjY2Vzcw0KIHRvIGEg cGFydGljdWxhciByZXNvdXJjZSBieSB0aGUgcmVzb3VyY2Ugb3duZXIuIFRoZSBjbGllbnQgY2Fu IHRoZW4gYXNrIGZvciBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIHJlc291cmNlIHVzaW5nIHRoZSBj bGllbnQgY3JlZGVudGlhbHMgYW5kIG5vIGFjY2VzcyBjb2RlIG9yIHJlZnJlc2ggdG9rZW4uIEp1 c3QgaGF2aW5nIHRoZSBhZGRyZXNzIG9mIHRoZSBpbnRlbmRlZCByZXNvdXJjZSAocHJvYmFibHkg cHJvdmlkZWQgdmlhIFNDT1BFKSBhbG9uZw0KIHdpdGggdGhlIGNsaWVudCBjcmVkZW50aWFscyBp cyBtb3JlIHRoYW4gZW5vdWdoIHRvIGRlY2lkZSBpZiBhbiBhY2Nlc3MgdG9rZW4gc2hvdWxkIGJl IGlzc3VlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk15IHBvaW50IGlzIHRoYXQgdGhl IGNsaWVudCBjcmVkZW50aWFscyBzY2VuYXJpbyBpcyBmdWxseSBhcHBsaWNhYmxlIHRvIGNhc2Vz IHdoZXJlIHRoZSBjbGllbnQgaXMgbm90IHRoZSByZXNvdXJjZSBvd25lciBidXQgaW4gd2hpY2gg dGhlIHJlc291cmNlIFVSSSBwcm92aWRlcyBhbGwgdGhlIGNvbnRleHQgbmVlZGVkDQogdG8gZGV0 ZXJtaW5lIGlmIHRoZSBjbGllbnQgc2hvdWxkIGJlIGFibGUgdG8gZ2V0IGFuIGFjY2VzcyB0b2tl bi4gSSB0aGluayB0aGUgY3VycmVudCB0ZXh0IHdvdWxkIGltcGx5IG90aGVyd2lzZS4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U28gSSB3b3VsZCBwcm9wb3NlIGNoYW5naW5nIHRoZSBz ZW50ZW5jZSB0byDigJxDbGllbnQgY3JlZGVudGlhbHMgYXJlIHVzZWQgYXMgYW4gYXV0aG9yaXph dGlvbiBncmFudCB3aGVuIHRoZSBjbGllbnQgaXMgYWN0aW5nIG9uIGl0cyBvd24gYmVoYWxmICh0 aGUgY2xpZW50IGlzIGFsc28gdGhlIHJlc291cmNlIG93bmVyKQ0KIG9yIHdoZW4gdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGhhcyBlbm91Z2ggY29udGV4dCB0byBkZXRlcm1pbmUgZnJvbSB0aGUg YWNjZXNzIHRva2VuIHJlcXVlc3QgaWYgdGhlIGNsaWVudCBoYXMgYXV0aG9yaXphdGlvbiB0byBh Y2Nlc3MgdGhlIHJlcXVlc3RlZCByZXNvdXJjZS7igJ3igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjEuNC41LiBFeHRlbnNpb25zOiBDb21tZW50OiDigJxJIHdvdWxkIGNoYW5nZSB0aGlz IHNlbnRlbmNlIHRvIHJlYWQg4oCcQWRkaXRpb25hbCBncmFudCB0eXBlcyBtYXkgYmUgZGVmaW5l ZCB0byBzdXBwb3J0IG5ldyBhcHByb2FjaGVzIHRvIGF1dGhlbnRpY2F0aW9uL2F1dGhvcml6YXRp b24gYXMgd2VsbCBhcyB0bw0KIHByb3ZpZGUgYSBicmlkZ2UgYmV0d2VlbiBPQXV0aCBhbmQgb3Ro ZXIgcHJvdG9jb2xzLuKAneKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS41LiBSZWZy ZXNoIFRva2VuOiBDb21tZW50IG9uIOKAnFJlZnJlc2ggdG9rZW5zIGFyZSBjcmVkZW50aWFscyB1 c2VkIHRvIG9idGFpbiBhY2Nlc3MgdG9rZW5zLuKAnTog4oCcVGhpcyBzZW50ZW5jZSBwcmVzdW1l cyB0aGF0IHJlZnJlc2ggdG9rZW5zIGFyZSBzZWxmLWNvbnRhaW5lZCBjcmVkZW50aWFscy4gSW4g b3RoZXINCiB3b3JkcyB0aGF0IG9uZSBjYW4gZ2V0IGFuIGFjY2VzcyB0b2tlbiBqdXN0IHVzaW5n IGEgcmVmcmVzaCB0b2tlbiBhbmQgbm90aGluZyBlbHNlLiBUaGlzIHByZXN1bXB0aW9uIGlzIHJl YnV0dGVkIGxhdGVyIGluIHRoZSBkb2N1bWVudCBidXQgSSB0aGluayBpdOKAmXMgY29uZnVzaW5n IHRvIGltcGx5IG9uZSB0aGluZyBoZXJlIGFuZCBzdGF0ZSBvdGhlcndpc2UgbGF0ZXIgb24u4oCd PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLjUuIFJlZnJlc2ggVG9rZW46IENoYW5nZSDi gJw8c3BhbiBsYW5nPSJFTiI+YSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdHM8L3NwYW4+4oCd IHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5hIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0PC9zcGFu PuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuNS4gUmVmcmVzaCBUb2tlbjogQ29t bWVudCBvbiDigJw8c3BhbiBsYW5nPSJFTiI+KEcpJm5ic3A7IFRoZSBjbGllbnQgcmVxdWVzdHMg YSBuZXcgYWNjZXNzIHRva2VuIGJ5IGF1dGhlbnRpY2F0aW5nIHdpdGggdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGFuZCBwcmVzZW50aW5nIHRoZSByZWZyZXNoIHRva2VuLjwvc3Bhbj7igJ06DQog 4oCcSHVt4oCmIG5vdyB0aGUgdGV4dCBzZWVtcyB0byBjb250cmFkaWN0IGl0c2VsZi4gQWJvdmUg aXQgc2VlbWVkIGxpa2UgeW91IGNvdWxkIHVzZSB0aGUgcmVmcmVzaCB0b2tlbiBieSBpdHNlbGYg dG8gZ2V0IGFuIGFjY2VzcyB0b2tlbiBhbmQgSSBoYWQgdG8gYXNrIGZvciBsYW5ndWFnZSB0aGF0 IG1hZGUgaXQgY2xlYXIgdGhhdCB5b3UgY291bGQgdXNlIGEgcmVmcmVzaCB0b2tlbiB3aXRoIG90 aGVyIGNyZWRlbnRpYWxzLiZuYnNwOyBCdXQgdGhlIHRleHQgb2YNCiBwb2ludCBHIG5vdyBpbXBs aWVzIHRoZSBleGFjdCBvcHBvc2l0ZSwgdGhhdCByZWZyZXNoIHRva2VucyBjYW4gb25seSBiZSB1 c2VkIHdpdGggb3RoZXIgY3JlZGVudGlhbHMgYW5kIG5vdCBieSB0aGVtc2VsdmVzLiAoRXZlbiB0 aG91Z2ggdGhlIHBpY3R1cmUgaW4gZmlndXJlIDIgZm9yIHN0ZXAgRyBpbXBsaWVzIHRoZSBvcHBv c2l0ZSkuIEkgd291bGQgZWRpdCB0aGlzIGxhbmd1YWdlIHRvIHNheSDigJxUaGUgY2xpZW50IHJl cXVlc3RzIGEgbmV3IGFjY2Vzcw0KIHRva2VuLiBEZXBlbmRpbmcgb24gdGhlIGF1dGhvcml6YXRp b24gc2VydmVy4oCZcyBwb2xpY2llcyB0aGlzIHJlcXVlc3QgbWlnaHQgYmUgbWFkZSB3aXRoIHRo ZSByZWZyZXNoIHRva2VuIGJ5IGl0c2VsZiBvciB3aXRoIGEgY29tYmluYXRpb24gb2YgdGhlIHJl ZnJlc2ggdG9rZW4gYW5kIG90aGVyIGNsaWVudCBjcmVkZW50aWFscy7igJ3igJ08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjIuMS4gQ2xpZW50IFR5cGVzOiBDb21tZW50IG9uIOKAnHVzZXIt YWdlbnQtYmFzZWQgYXBwbGljYXRpb27igJ06IOKAnEdpdmUgdGhlIHBvb3IgcmVhZGVyIGEgaGlu dCBhbmQgbWVudGlvbiDigJhicm93c2Vy4oCZIHNvbWV3aGVyZSBpbiB0aGUgcGFyYWdyYXBoIGJl bG93LiBGb3IgZXhhbXBsZSDigJxBIHVzZXItYWdlbnQtYmFzZWQNCiBhcHBsaWNhdGlvbiBpcyBh IHB1YmxpYyBjbGllbnQgKHN1Y2ggYXMgYSB3ZWIgYnJvd3NlcikgaW4gd2hpY2ggdGhl4oCmLuKA neKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Mi4xLiBDbGllbnQgVHlwZXM6IHdlYiBh cHBsaWNhdGlvbjogQ2hhbmdlIOKAnGFjY2VzcyB0b2tlbnMgb3IgcmVmcmVzaCB0b2tlbnMsIGNh biByZWNlaXZlIGFuIGFjY2VwdGFibGUgbGV2ZWzigJ0gdG8g4oCcYWNjZXNzIHRva2VucyBvciBy ZWZyZXNoIHRva2VucywgY2FuLCBpbiBzb21lIGNhc2VzLCByZWNlaXZlIGFuDQogYWNjZXB0YWJs ZSBsZXZlbOKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuNC4gQ2xpZW50IEF1dGhl bnRpY2F0aW9uOiZuYnNwOyBBZGQgYSBwZXJpb2QgYWZ0ZXIg4oCcZXRj4oCdLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Mi40LjEuIENsaWVudCBQYXNzd29yZDogQ29tbWVudCBvbiDigJxj aGFyc2V0PVVURi044oCdOiDigJxUaGUgdXNlIG9mIFVURi04IHdpdGggeC13d3ctZm9ybS11cmxl bmNvZGVkIGlzIGV4cGxpY2l0bHkgYmFubmVkIGJ5IEhUTUwgNC4wMSBzZWN0aW9uIDE3LjEzLjEu IElmIHdlIHdhbnQgdG8gdXNlIFVURi04IHRoZW4NCiB3ZSBoYXZlIHRvIHVzZSBtdWx0aXBhcnQv Zm9ybS1kYXRhLCBhbHNvIGRlZmluZWQgYnkgSFRNTCA0LjAxIChzZWN0aW9uIDE3LjEzLjQpLiBC dXQgc2luY2Ugbm9ib2R5IHdvdWxkIGFjdHVhbGx5IHdhbnQgdG8gZG8gdGhhdCBJIHdvdWxkIHN1 Z2dlc3QgcHV0dGluZyBpbiBhIHJlZmVyZW5jZSB0byBzZWN0aW9uIDQuMiBvZiBSRkMgNTU1MiB3 aGljaCBhY3R1YWxseSBkZWZpbmVzIGhvdyB0byB1c2UgVVRGLTggd2l0aCB4LXd3dy1mb3JtLXVy bGVuY29kZWQNCiBhbmQgc3BlY2lmeWluZyB0aGF0IHRoZSA1NTUyIGV4dGVuc2lvbiBNVVNUIGJl IHN1cHBvcnRlZCBieSBPQXV0aCBwYXJ0aWNpcGFudHMu4oCdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4zLjEuJm5ic3A7IEF1dGhvcml6YXRpb24gRW5kcG9pbnQ6IENvbW1lbnQgb24gZmly c3Qgc2VudGVuY2U6Jm5ic3A7IOKAnFRoZXJlIGlzIGEgdGhpcmQgb3B0aW9uIOKAkyBub25lIG9m IHRoZSBhYm92ZS4gJm5ic3A7SXQgd291bGQgYmUgYSBzaGFtZSBpZiB0aGUgdGV4dCBvZiB0aGlz IGRyYWZ0IGV4cGxpY2l0bHkgcHJvaGliaXRzIHRoYXQNCiBwYXR0ZXJuLuKAnTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+My4xLiZuYnNwOyBBdXRob3JpemF0aW9uIEVuZHBvaW50OiZuYnNw OyBDb21tZW50IG9uIOKAnFtSRkMzOTg2XSBzZWN0aW9uIDPigJ06IOKAnFNob3VsZG7igJl0IHdl IHBvaW50IGRpcmVjdGx5IHRvIHNlY3Rpb24gMy40IHdoaWNoIGV4YWN0bHkgZGVmaW5lcyB0aGUg cXVlcnkgY29tcG9uZW50P+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+My4xLiZuYnNw OyBBdXRob3JpemF0aW9uIEVuZHBvaW50OiZuYnNwOyBDb21tZW50IG9uIOKAnE1VU1QgYmUgcmV0 YWluZWQgd2hlbiBhZGRpbmcgYWRkaXRpb25hbCBxdWVyeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsgcGFyYW1ldGVyc+KAnTog4oCcSElHSCBJTVBP UlRBTkNFIOKAkyBUaGlzIHNwZWNpZmljYXRpb24gaXMgaW5jb21wbGV0ZS4gU2VjdGlvbiAzLjQg b2YgUkZDIDM5ODYgc2ltcGx5IGFzc2VydHMgdGhlIGV4aXN0ZW5jZSBvZiBhIHF1ZXJ5IGNvbXBv bmVudC4gSXQgc2F5cyBub3RoaW5nIGFib3V0IHRoZSBzeW50YXgNCiBvZiB0aGF0IGNvbXBvbmVu dC4gVGhlIHNwZWMgYXNzdW1lcyB0aGF0IHRoZSBjb21wb25lbnQgaXMgdXNpbmcgeC13d3ctZm9y bS11cmxlbmNvZGVkIGJ1dCB0aGF0IGlzIG5vdCBpbiBhbnkgd2F5IG1hbmRhdGVkIGJ5IFJGQyAz OTg2LiBTbyB0aGVyZSBpcyBhIG5vcm1hdGl2ZSBzZW50ZW5jZSBtaXNzaW5nIGhlcmUgd2hpY2gg c3RhdGVzIHRoYXQgYW55IHF1ZXJ5IHBhcmFtZXRlciBvbiB0aGUgYXV0aG9yaXphdGlvbiBlbmRw b2ludOKAmXMgVVJJIE1VU1QNCiBiZSBkZWZpbmVkIGFzIHNwZWNpZmllZCBpbiB4LXd3dy1mb3Jt LXVybGVuY29kZWQu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zLjEuJm5ic3A7IEF1 dGhvcml6YXRpb24gRW5kcG9pbnQ6Jm5ic3A7IENvbW1lbnQgb24g4oCcVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIFNIT1VMRCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlcXVlc3QgcGFyYW1ldGVycy7i gJ06IOKAnEFsdGhvdWdoIHRoYXQgaXMgbm9ybWFsIGJlaGF2aW9yIGZvciBhcHBsaWNhdGlvbiBw cm90b2NvbHMNCiBpdCBzZWVtcyByYXRoZXIgZGFuZ2Vyb3VzIGZvciBhIHNlY3VyaXR5IHByb3Rv Y29sLiBBZnRlciBhbGwgd2hhdCBpZiB0aGUgY2xpZW50IHB1dCBpbiBhIHBhcmFtZXRlciBzcGVj aWZ5aW5nIHNvbWV0aGluZyBzZWN1cml0eSByZWxhdGVkIGFib3V0IHRoZSByZXF1ZXN0IHRoaW5r aW5nIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgd291bGQgaG9ub3IgaXQgYW5kIHRo ZW4gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgc2lsZW50bHkNCiBpZ25vcmVzIGl0PyZuYnNw OyBBZ2FpbiwgdGhpcyBpcyBhIHNlY3VyaXR5IHByb3RvY29sLCBub3QgYSBnZW5lcmljIGFwcGxp Y2F0aW9uIHByb3RvY29sLCBpdCBzZWVtcyB0byBiZSB0aGF0IHVucmVjb2duaXplZCBwYXJhbWV0 ZXJzIHNob3VsZCBjYXVzZSBhIGZhaWx1cmUu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4zLjEuMi4mbmJzcDsgUmVkaXJlY3Rpb24gRW5kcG9pbnQ6IENvbW1lbnQgb24g4oCcd2hlbiBp bml0aWF0aW5nIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3TigJ06IOKAnEkgd291bGQgc3VnZ2Vz dCBtb3JlIGV4cGxpY2l0IGxhbmd1YWdlIOKAnG9yIGFzIHNwZWNpZmllZCBpbiB0aGUgcmVkaXJl Y3Rpb24gVVJJIHZhbHVlIGluIHRoZQ0KIGF1dGhvcml6YXRpb24gcmVxdWVzdC7igJ3igJ08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuMS4yLjIuIFJlZ2lzdHJhdGlvbiBSZXF1aXJlbWVu dHM6IENvbW1lbnQgb24gbGFzdCB3b3JkIOKAnHBhdGjigJ06IOKAnEh1aD8gU2NoZW1lLCBhdXRo b3JpemF0aW9uIGFuZCBwYXRoIGlzIGEgY29tcGxldGUgVVJJIG1pbnVzIGEgcXVlcnkgY29tcG9u ZW50LiZuYnNwOyBJcyB0aGUgZ29hbCB0byBzcGVjaWZpY2FsbHkgbWFuZGF0ZQ0KIHRoYXQgb25s eSB0aGUgcXVlcnkgY29tcG9uZW50IGNhbiB2YXJ5IGFuZCB0aGUgcmVzdCBvZiB0aGUgVVJJIE1V U1QgYmUgc3RhdGljPyBJZiBzbyB0aGF0IHNob3VsZCBiZSBzdGF0ZWQgZXhwbGljaXRseSByYXRo ZXIgdGhhbiBpbXBsaWNpdGx5IGFzIGl0IGlzIG5vdy4mbmJzcDsgQnV0IEkgdGhpbmssIGlmIHRo YXQgaXMgdGhlIGludGVudCwgaXQgZ29lcyB0b28gZmFyLiBXZSBzaG91bGQgYWxzbyBhbGxvdyBm b3IgYWRkaXRpb25hbCBwYXRoIHNlZ21lbnRzDQogdG8gYmUgYWRkZWQgdG8gdGhlIFVSSSBwYXRo IGJleW9uZCB0aGUgcmVnaXN0ZXJlZCBwcmVmaXguIEFzc3VtaW5nIHdlIGNhbiBhZGRyZXNzIHRo ZSBzZWN1cml0eSBwcm9ibGVtIGluIHRoZSBuZXh0IGNvbW1lbnQu4oCdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4zLjEuMi4zLiBEeW5hbWljIENvbmZpZ3VyYXRpb246IENvbW1lbnQgb24g 4oCcc2VjdGlvbiA24oCdOiZuYnNwOyDigJxUaGUgcmVmZXJlbmNlIHRvIHNlY3Rpb24gNiBpcyBp bmNvbXBsZXRlLiBTZWN0aW9uIDYgZGVmaW5lcyBubyBsZXNzIHRoYW4gNiBkaWZmZXJlbnQgYXhp c+KAmXMgb24gd2hpY2ggVVJJIGNvbXBhcmlzb25zIGNhbg0KIHZhcnkuIEZ1cnRoZXJtb3JlIGFz IHJlY2VudGx5IGRvY3VtZW50ZWQgaW4gZHJhZnQtdGhhbGVyLWlhYi1pZGVudGlmaWVyLWNvbXBh cmlzb24tMDAudHh0IGl0IGlzIHRyaXZpYWxseSBlYXN5IHRvIHNjcmV3IHVwIFVSSSBjb21wYXJp c29ucyBhbmQgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBhcmUgcHJldHR5IGRpcmUuIFBlcnNv bmFsbHkgSSB0aGluayB0aGF0IHRoZSBvbmx5IHNhbmUgYXBwcm9hY2ggZ2l2ZW4gdGhlIGlzc3Vl cyBpbiB0aGUNCiBwcmV2aW91cyBsaW5rIGlzIHRvIGFkb3B0IHNlY3Rpb24gNi4yLjEgb2YgUkZD IDM5ODYuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFtIGEgYml0IHNjYXJlZCBvZiBo b3cgdG8gaGFuZGxlIHBhcnRpYWwgbWF0Y2hlcy4gSXTigJlzIHRlbXB0aW5nIHRvIGFyZ3VlIHRo YXQgc28gbG9uZyBhcyB0aGUgc2NoZW1hIGhhcyBhbiBhdXRob3JpdHkgYW5kIGF0IGxlYXN0IG9u ZSBwYXRoIHNlZ21lbnQgdGhlbiB3ZSBjYW4ganVzdCB1c2UgYSBwYXJ0aWFsDQogc3RyaW5nIG1h dGNoIGJ1dCBib3kgb2ggYm95IGRvIEkgc2VlIHBlb3BsZSBzY3Jld2luZyB0aGF0IG9uZSB1cCBy b3lhbGx5LiBUaGlzIGlzIHNjYXJ5IGVub3VnaCB0aGF0IEkgdGhpbmsgSSBjYW4gYmUgYXJndWVk IGludG8gc2F5aW5nIHRoYXQgcGFydGlhbCBwcmUtcmVnaXN0ZXJlZCBVUklzIE1VU1Qgb25seSBk aWZmZXIgYnkgdGhlIHF1ZXJ5IGNvbXBvbmVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkluIGFueSBjYXNlIHRoaXMgaXNzdWVzIG5lZWRzIHRvIGJlIGV4cGxpY2l0bHkgY2FsbGVkIG91 dCBmb3IgYWxsIFVSSSBjb21wYXJpc29ucyByZXF1aXJlZCBieSB0aGUgc3BlYyBhbmQgbm9ybWF0 aXZlbHkgZGVmaW5lZC4gT3RoZXJ3aXNlIHdlIHdpbGwgZW5kIHVwIHdpdGggYWxsIHRoZSBzZWN1 cml0eSBpc3N1ZXMNCiBpbiBEYXZl4oCZcyBJRC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjMuMS4yLjQuJm5ic3A7IEludmFsaWQgRW5kcG9pbnQ6IENvbW1lbnQgb24g4oCcb3BlbiBy ZWRpcmVjdG9y4oCdOiDigJxIb3cgbWFueSBwZW9wbGUgZXZlbiBrbm93IHdoYXQgdGhlIGhlY2sg YW4gb3BlbiByZWRpcmVjdG9yIGlzPyBJIHRoaW5rIHdlIG5lZWQgYSBzZWN0aW9uIGluIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KIHNlY3Rpb24gdGhhdCBkZWZpbmVzIHdoYXQgYW4gb3Bl biByZWRpcmVjdG9yIGlzIGFuZCB3aHkgaXTigJlzIGJhZC4gQWx0ZXJuYXRpdmVseSBhIG5vcm1h dGl2ZSByZWZlcmVuY2UgdG8gYSBjb21wbGV0ZSBkZWZpbml0aW9uIHNvbWV3aGVyZSBlbHNlIGlz IGFsc28gZmluZS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuMi4xLiBDbGllbnQg QXV0aGVudGljYXRpb246IENoYW5nZSDigJxSZWNvdmVyeeKAnSB0byDigJxSZWNvdmVyaW5n4oCd LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+My4yLjEuIENsaWVudCBBdXRoZW50aWNhdGlv bjogQ2hhbmdlIOKAnGNyZWRlbnRpYWxzLCBieSBwcmV2ZW50aW5nIGFuIGF0dGFja2VyIGZyb20g YWJ1c2luZ+KAnSB0byDigJxjcmVkZW50aWFscy4gVGhpcyBwcmV2ZW50cyBhbiBhdHRhY2tlciBm cm9tIGFidXNpbmfigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuMi4xLiBDbGllbnQg QXV0aGVudGljYXRpb246IENoYW5nZSDigJxwZXJpb2RpYyBjcmVkZW50aWFscyByb3RhdGlvbuKA nSB0byDigJw8c3BhbiBsYW5nPSJFTiI+cGVyaW9kaWMgY3JlZGVudGlhbCByb3RhdGlvbjwvc3Bh bj7igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zLjIuMS4gQ2xpZW50IEF1dGhlbnRp Y2F0aW9uOiBDb21tZW50IG9uIOKAnHdoaWxlIHJvdGF0aW9uIG9mIGEgc2luZ2xlIHNldCBvZiBj bGllbnQgY3JlZGVudGlhbHMgaXMgc2lnbmlmaWNhbnRseSBlYXNpZXLigJ06IOKAnFRoZSBzcGVj IGNhbGxzIG91dCByb3RhdGlvbiBvZiBjcmVkZW50aWFscyBhcyBiZWluZyBjcnVjaWFsDQogYnV0 IHRoZW4gZG9lc27igJl0IGRlZmluZSBob3cgdGhpcyBpcyB0byBiZSBkb25lPyBUaGF0IHNlZW1z IGtpbmQgb2Ygb2RkLiBTaG91bGRu4oCZdCB3ZSBkZWZpbmUgYW4gZW5kcG9pbnQgd2hlcmUgb25l IGNhbiBzdWJtaXQgb25l4oCZcyBvbGQgYnV0IHVuZXhwaXJlZCBjcmVkZW50aWFscyBmb3IgbmV3 IG9uZXM/IFRoaXMgc3RpbGwgbGVhdmVzIHRoZSBlZGdlIGNhc2Ugb2Ygd2hhdCB0byBkbyBpZiB0 aGUgb2xkIGNyZWRlbnRpYWxzIGhhdmUgZXhwaXJlZA0KIGFuZCBuZXcgb25lcyBoYXZlbuKAmXQg YmVlbiBpc3N1ZWQgYnV0IHRoYXQgaXMgdW5hdm9pZGFibGUgYW5kIGluIHRoYXQgY2FzZSB3ZSBj YW4gcmVxdWlyZSBvdXQgb2Ygc2NvcGUgYWN0aW9uLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+NC4xLiBBdXRob3JpemF0aW9uIENvZGU6IENvbW1lbnQgb24gZmlyc3Qg4oCcXuKAnTog 4oCcU2hvdWxkbuKAmXQgdGhpcyBiZSBhIHYgY2hhcmFjdGVyIGFuZCBub3QgYSBePyBUaGlzIHdv dWxkIG1ha2UgaXQgY29uc2lzdGVudCB3aXRoIEEgd2hpY2ggYWxzbyBjcm9zc2VzIHR3byBib3hl cyBhbmQgcG9pbnRzIGluIHRoZQ0KIHNhbWUgZGlyZWN0aW9uLuKAnTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+NC4xLiBBdXRob3JpemF0aW9uIENvZGU6IENoYW5nZSDigJxJZiB2YWxpZCwg cmVzcG9uZHMgYmFjayB3aXRoIGFuIGFjY2VzcyB0b2tlbuKAnSB0byDigJxJZiB0aGUgcmVxdWVz dCBpcyB2YWxpZCwgdGhlbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgd2lsbCByZXNwb25kcyBi YWNrIHdpdGggYW4gYWNjZXNzIHRva2VuDQogYW5kIG9wdGlvbmFsbHkgYSByZWZyZXNoIHRva2Vu 4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NC4xLjIuJm5ic3A7IEF1dGhvcml6YXRp b24gUmVzcG9uc2U6IENvbW1lbnQg4oCcVGhlIGxhbmd1YWdlIGFyb3VuZCBzY29wZXMgaW4gdGhl IGRvY3VtZW50IGlzIHJlYWxseSBmcnVzdHJhdGluZy4gT25lIG9ubHkgZmluZHMgb3V0IG11Y2gg bGF0ZXIgaW4gdGhlIGRvY3VtZW50IHRoYXQgaXQgaXMgcGVyZmVjdGx5IGFsbG93YWJsZQ0KIGZv ciBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBtb3JlIG9yIGxlc3MgaWdub3JlIHdoYXQgc2Nv cGVzIGFyZSBzdWJtaXR0ZWQgYW5kIGluc3RlYWQgdG8ganVzdCByZXR1cm4gd2hhdGV2ZXIgdGhl IGhlbGwgdGhleSB3YW50LiBUaGlzIGlzIGEgZmluZSBkZXNpZ24gY2hvaWNlIGJ1dCBpdCBzZWVt cyBsaWtlIHRoZSBzb3J0IG9mIHRoaW5nIHRoYXQgc2hvdWxkIGJlIGZvcmNlZnVsbHkgcmVwZWF0 ZWQgYW55d2hlcmUgaW4gdGhlIHNwZWMgdGhhdA0KIHdlIGFsbG93IHBlb3BsZSB0byBzdWJtaXQg c2NvcGVzIHNvIG5vYm9keSBmb3JnZXRzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ NC4xLjIuJm5ic3A7IEF1dGhvcml6YXRpb24gUmVzcG9uc2U6IENvbW1lbnQgb24g4oCcc3RhdGXi gJ06IOKAnERvbuKAmXQgd2UgaGF2ZSB0byBwcm92aWRlIHNvbWUgZ3VpZGFuY2Ugb24gaG93IGxh cmdlIHRoZSBzdGF0ZSB2YWx1ZSBjYW4gc2FmZWx5IGJlPyBPdGhlcndpc2Ugd2UgYXJlIGFza2lu ZyBjbGllbnRzIHRvIHJld3JpdGUNCiB0aGVpciBzdGF0ZSBtZWNoYW5pc21zIGV2ZXJ5IHRpbWUg dGhleSB0aHJvdyBpbiBzdXBwb3J0IGZvciBhIG5ldyBwcm90ZWN0ZWQgcmVzb3VyY2Ugc2VydmVy LiBXZSBoYXZlIHRvIHNldCBleHBlY3RhdGlvbnMgYWNyb3NzIHRoZSBpbmR1c3RyeSBpZiB3ZSBh cmUgdG8gaG9wZSBmb3IgYWN0dWFsIGludGVyb3BlcmFiaWxpdHku4oCdPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj40LjEuMi4xLiBFcnJvciBSZXNwb25zZTogQ29tbWVudCBvbiDigJxVVEYt OCBlbmNvZGVkIHRleHTigJ06IOKAnEkgdGhpbmsganVzdCBzYXlpbmcgVVRGLTggZW5jb2RlZCB0 ZXh0IGNhbiBiZSBtaXNsZWFkaW5nLiBJdOKAmXMgbm90IGxlZ2FsIHRvIHB1dCBVVEYtOCBjaGFy YWN0ZXJzIGludG8gYSB4LXd3dy1mb3JtLXVybGVuY29kZWQNCiB1c2VkIGluIGEgR0VUIChhcyBk ZWZpbmVkIGJ5IHNlY3Rpb24gMTcuMTMuMSBvZiBIVE1MIDQuMDEpLiBTbyB3aGF0IHlvdSBoYXZl IHRvIGRvIGlzIHRha2UgdGhlIFVURi04IFN0cmluZyBhbmQgdGhlbiBVUkwgZW5jb2RlIGl0LiBX aGljaCBpcyBmaW5lIGJ1dCB3ZSBzaG91bGQgY2FsbCB0aGlzIG91dC4mbmJzcDsgTm90ZSB0aGF0 IHRoaXMgaXMgYSBzZXBhcmF0ZSBpc3N1ZSB0aGFuIFVURi04IHN1cHBvcnQgZm9yIHgtd3d3LWZv cm0tdXJsZW5jb2RlZC4NCiBUaGF0IGlzc3VlIG9ubHkgYXBwbGllcyB3aGVuIHRoZSBmb3JtIGlz IGluIHRoZSByZXF1ZXN0IGJvZHkuIEluIHRoaXMgc2NlbmFyaW8gdGhlIGZvcm0gaXMgaW4gYSBV UkwuIFRoZXJlIGlzIG5vIHF1ZXN0aW9uIHRoYXQgVVJMcyBpbiBIVFRQIHJlcXVlc3QgbGlzdHMg ZG9u4oCZdCBzdXBwb3J0IFVURi04LuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NC4x LjMuIEFjY2VzcyBUb2tlbiBSZXF1ZXN0OiBDaGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPkZvciBl eGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcgSFRUUCB1c2luZzwvc3Bhbj7i gJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPkZvciBleGFtcGxlLCBpZiB0aGUgY2xpZW50IG1ha2Vz IHRoZSBmb2xsb3dpbmcNCiBIVFRQIHJlcXVlc3QgdXNpbmc8L3NwYW4+4oCdPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj40LjEuMy4gQWNjZXNzIFRva2VuIFJlcXVlc3Q6IENvbW1lbnQgb24g 4oCcdGhhdCB0aGVpciB2YWx1ZXMgYXJlIGlkZW50aWNhbOKAnTog4oCcVGhpcyB2ZXJiaWFnZSBp c27igJl0IG11Y2ggdXNlLCBmb3IgZXhhbXBsZSwgaWYgdGhlIGNsaWVudCBjYW4gYWx3YXlzIHNl bmQgdGhlIHNhbWUgcmVkaXJlY3RfdXJpLiBTbywganVzdA0KIHRvIGJlIGNsZWFyLCB0aGlzIHRl eHQgaGVyZSBkb2VzbuKAmXQgaW4gYW55d2F5IGNoYW5nZSBteSBwcmV2aW91cyByZWNvbW1lbmRh dGlvbiByZWdhcmRpbmcgdGhlIGF0dGFjayBwcmV2aW91c2x5IGRlc2NyaWJlZC7igJ08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuMS40LiBBY2Nlc3MgVG9rZW4gUmVzcG9uc2U6IENvbW1l bnQgb24g4oCcInRva2VuX3R5cGUiOiJleGFtcGxlIuKAnTog4oCcSnVzdCB0byBwcmV2ZW50IGFu eSBjb25mdXNpb24gaXQgd291bGQgYmUgZ29vZCB0byBhY3R1YWxseSBkZWZpbmUgdGhlIHRva2Vu X3R5cGUg4oCcZXhhbXBsZeKAnSBpbiB0aGlzIGRvY3VtZW50IChQcm9iYWJseQ0KIGluIHNlY3Rp b24gNy4xIGFuZCBsYXRlciBpbiB0aGUgSUFOQSBzZWN0aW9uKSBhbmQgc3BlY2lmeSB0aGF0IGl0 IGlzIHJlc2VydmVkIGZvciB1c2UgaW4gZXhhbXBsZXMgd2hlcmUgb25lIGRvZXMgbm90IHdpc2gg dG8gYmUgbW9yZSBzcGVjaWZpYy7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuMi4m bmJzcDsgSW1wbGljaXQgR3JhbnQ6IENvbW1lbnQg4oCcSSBoYXZlIHJ1biBpbnRvIG11bHRpcGxl IHBlb3BsZSAoaW5jbHVkaW5nIG15c2VsZikgd2hvIGhhdmUgcmVhZCB0aGUgT0F1dGggc3BlYyBh bmQgY2FtZSBhd2F5IGNvbXBsZXRlbHkgY29uZnVzZWQgYWJvdXQgd2hlbiB0aGUgaGVjayBvbmUg aXMgc3VwcG9zZWQNCiB0byB1c2UgdGhlIGltcGxpY2l0IGdyYW50IGZsb3cgZm9yLiBJdOKAmXMg bm90IGltbWVkaWF0ZWx5IG9idmlvdXMgdGhhdCBpdOKAmXMgYSB3YXkgdG8gc3VwcG9ydCBzdGFu ZGFsb25lIGJyb3dzZXIgYmFzZWQgY2xpZW50cy4gQ2FuIHdlIHB1dCBpbiBhbiBleGFtcGxlIG9y IHNvbWV0aGluZyB0byBtYWtlIGl0IG1vcmUgb2J2aW91cyB3aHkgaXTigJlzIGhlcmU/4oCdPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40LjIuMS4gQXV0aG9yaXphdGlvbiBSZXF1ZXN0OiBD b21tZW50IG9uIHJlZGlyZWN0X3VyaTombmJzcDsg4oCcR2l2ZW4gdGhhdCB0aGUgb25seSB3YXkg dG8gaWRlbnRpZnkgdGhlIGNsaWVudCBpbiB0aGUgaW1wbGljaXQgZ3JhbnQgZmxvdyBpcyB2aWEg dGhlIHJlZGlyZWN0X3VyaSwgaG93IGNhbiBpdCBiZSBvcHRpb25hbD/igJ08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjQuMy4gUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHM6 IENoYW5nZSDigJxlbmFibGluZyB0aGUgZ3JhbnQgdHlwZSwgYW5kIG9ubHkgd2hlbiBvdGhlciBm bG93c+KAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+ZW5hYmxpbmcgdGhlIGdyYW50IHR5cGUgYW5k IG9ubHkgdXNlIGl0IHdoZW4gb3RoZXIgZmxvd3M8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+NC4zLiBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFsczogQ2hh bmdlIOKAnDxzcGFuIGxhbmc9IkVOIj5yZXNvdXJjZSBvd25lciBjcmVkZW50aWFsczwvc3Bhbj7i gJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPnJlc291cmNlIG93bmVy4oCZcyBjcmVkZW50aWFsczwv c3Bhbj7igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40LjMuMi4gQWNjZXNzIFRva2Vu IFJlcXVlc3Q6Jm5ic3A7IENvbW1lbnQgb24g4oCcYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBw cm90ZWN0IHRoZSBlbmRwb2ludCBhZ2FpbnN0IGJydXRlIGZvcmNlIGF0dGFja3PigJ06IOKAnFNo b3VsZG7igJl0IHRoZSByZXF1aXJlbWVudCB0byBwcmV2ZW50IGFnYWluc3QgYnJ1dGUgZm9yY2UN CiBhdHRhY2tzIGFwcGx5IHRvIGFsbCBjcmVkZW50aWFscywgcmVzb3VyY2Ugb3duZXIgb3Igb3Ro ZXJ3aXNlPyBJbiBvdGhlciB3b3JkcyBpbiBzZWN0aW9uIDIuNC4xIHdlIHRhbGsgYWJvdXQgaG93 IGNsaWVudHMgc3VibWl0IHRoZWlyIG5hbWUvcGFzc3dvcmQuIFNob3VsZG7igJl0IGVuZHBvaW50 cyBhY2NlcHRpbmcgY2xpZW50IG5hbWUvcGFzc3dvcmRzIGhhdmUgdGhlIHNhbWUgcHJvdGVjdGlv bnMgYWdhaW5zdCBicnV0ZSBmb3JjZSBhdHRhY2s/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj40LjQuMy4gQWNjZXNzIFRva2VuIFJlc3BvbnNlOiBDb21tZW50IG9uIOKAnEEgcmVmcmVz aCB0b2tlbiBTSE9VTEQgTk9UIGJlIGluY2x1ZGVk4oCdOiDigJxXaHkgaXNu4oCZdCB0aGlzIGEg TVVTVCBOT1Q/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40LjUuIEV4dGVuc2lvbnM6 IENvbW1lbnQg4oCcSXNu4oCZdCB0aGUgdGV4dCBpbiB0aGlzIHNlY3Rpb24gYW5kIDguMyByZWR1 bmRhbnQgd2l0aCBlYWNoIG90aGVyPyBJdCBzZWVtcyBsaWtlIHdlIHNob3VsZCB0YWtlIHRoZSB0 ZXh0IGZyb20gaGVyZSBhbmQgbWVyZ2UgaXQgd2l0aCBzZWN0aW9uIDguMyBzbyBhbGwNCiB0aGUg ZXh0ZW5zaW9uIGluZm9ybWF0aW9uIGlzIHJlY29yZGVkIGluIG9uZSBwbGFjZS4mbmJzcDsgSXTi gJlzIGp1c3QgcGxhaW4gdGhhdCBhbGwgb3RoZXIgZXh0ZW5zaW9uIHBvaW50cyBhcmUgaW4gc2Vj dGlvbiA4IGJ1dCB0aGlzIG9uZS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjUuMS4g U3VjY2Vzc2Z1bCBSZXNwb25zZTogQ29tbWVudCBvbiDigJxwYXJhbWV0ZXIgYXQgdGhlIGhpZ2hl c3Qgc3RydWN0dXJlIGxldmVs4oCdOiDigJxBcmUgdGhlcmUgYW55IGd1YXJhbnRlZXMgYWJvdXQg dGhlIG9yZGVyIG9mIHRoZSBtZW1iZXJzIGluIHRoZSBKU09OIG9iamVjdD8gSWYgbm90IHdlIHNo b3VsZCBzYXkNCiBzbyBleHBsaWNpdGx5LuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ NS4yLiBFcnJvciBSZXNwb25zZTogQ29tbWVudCBvbiDigJxtdWx0aXBsZSBjbGllbnQgYXV0aGVu dGljYXRpb25zIGluY2x1ZGVk4oCdIGluIGludmFsaWRfY2xpZW50OiDigJxTaG91bGRu4oCZdCB0 aGlzIGJlIGFuIGludmFsaWRfcmVxdWVzdD/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjUuMi4gRXJyb3IgUmVzcG9uc2U6IENvbW1lbnQgb24g4oCcTnVtZXJpY2FsIHZhbHVlcyBhcmUg aW5jbHVkZWQgYXMgSlNPTiBudW1iZXJz4oCdOiDigJxTYW1lIGlzc3VlIGFzIGJlZm9yZSwgZG9l cyBvcmRlcmluZyBtYXR0ZXIgYW5kIGlmIG5vdCB3ZSBuZWVkIHRvIHNheSB0aGF0LuKAnTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+OC4xLiBEZWZpbmluZyBBY2Nlc3MgVG9rZW4gVHlwZXM6 IENoYW5nZSDigJw8c3BhbiBsYW5nPSJFTiI+b3IgdXNlIGEgdW5pcXVlPC9zcGFuPuKAnSB0byDi gJw8c3BhbiBsYW5nPSJFTiI+b3IgdXNpbmcgYSB1bmlxdWU8L3NwYW4+4oCdLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+OS4mbmJzcDsgTmF0aXZlIEFwcGxpY2F0aW9uczombmJzcDsgQ2hh bmdlIOKAnGFuIHNjaGVtZeKAnSB0byDigJxhIHNjaGVtZeKAnTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+OS4mbmJzcDsgTmF0aXZlIEFwcGxpY2F0aW9uczogJm5ic3A7Q2hhbmdlIOKAnDxz cGFuIGxhbmc9IkVOIj5vZmZlciBhbiBpbXByb3ZlZCB1c2FiaWxpdHk8L3NwYW4+4oCdIHRvIOKA nDxzcGFuIGxhbmc9IkVOIj5vZmZlciBpbXByb3ZlZCB1c2FiaWxpdHk8L3NwYW4+4oCdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj45LiZuYnNwOyBOYXRpdmUgQXBwbGljYXRpb25zOiAmbmJz cDtDaGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPmluYWJpbGl0eSB0byBrZWVwIGNyZWRlbnRpYWxz IGNvbmZpZGVudGlhbDwvc3Bhbj7igJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPmluYWJpbGl0eSB0 byBrZWVwIGNsaWVudCBjcmVkZW50aWFscyBjb25maWRlbnRpYWw8L3NwYW4+4oCdLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+OS4mbmJzcDsgTmF0aXZlIEFwcGxpY2F0aW9uczogJm5ic3A7 Q2hhbmdlIOKAnFdoZW4gdXNpbmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgZmxvdyBhIHJlZnJl c2ggdG9rZW4gaXMgbm90IHJldHVybmVk4oCdIHRvIOKAnFdoZW4gdXNpbmcgdGhlIGltcGxpY2l0 IGdyYW50IHR5cGUgZmxvdyBhIHJlZnJlc2ggdG9rZW4gaXMgbm90IHJldHVybmVkDQogc28gb25j ZSB0aGUgYWNjZXNzIHRva2VuIGV4cGlyZXMgdGhlIGFwcGxpY2F0aW9uIHdpbGwgaGF2ZSB0byBy ZXBlYXQgdGhlIGF1dGhvcml6YXRpb24gcHJvY2Vzc+KAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjEwLjIuIENsaWVudCBJbXBlcnNvbmF0aW9uOiZuYnNwOyBDaGFuZ2Ug4oCca2VlcCBp cyBjbGllbnTigJ0gdG8g4oCca2VlcCBpdHMgY2xpZW504oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+MTAuMi4gQ2xpZW50IEltcGVyc29uYXRpb246Jm5ic3A7IENoYW5nZSDigJw8c3Bh biBsYW5nPSJFTiI+ZHVlIHRvIHRoZSBjbGllbnQgbmF0dXJlPC9zcGFuPuKAnSB0byDigJw8c3Bh biBsYW5nPSJFTiI+ZHVlIHRvIHRoZSBjbGllbnTigJlzIG5hdHVyZTwvc3Bhbj7igJ0uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC4yLiBDbGllbnQgSW1wZXJzb25hdGlvbjombmJzcDsg Q2hhbmdlIOKAnDxzcGFuIGxhbmc9IkVOIj5VUkkgdXNlZCBmb3IgcmVjZWl2aW5nIGF1dGhvcml6 YXRpb248L3NwYW4+4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5VUkkgdXNlZCBmb3IgcmVjZWl2 aW5nIGF1dGhvcml6YXRpb24gcmVxdWVzdHM8L3NwYW4+4oCdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4xMC4yLiBDbGllbnQgSW1wZXJzb25hdGlvbjombmJzcDsgQ2hhbmdlIOKAnDxzcGFu IGxhbmc9IkVOIj5lbmdhZ2UgdGhlIHJlc291cmNlIG93bmVyPC9zcGFuPuKAnSB0byDigJw8c3Bh biBsYW5nPSJFTiI+ZW5nYWdpbmcgdGhlIHJlc291cmNlIG93bmVyPC9zcGFuPuKAnS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjIuIENsaWVudCBJbXBlcnNvbmF0aW9uOiZuYnNwOyBD aGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPmFuZCBhdXRob3JpemUgdGhlIHJlcXVlc3Q8L3NwYW4+ 4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5hbmQgYXV0aG9yaXplIG9yIHJlamVjdCB0aGUgcmVx dWVzdDwvc3Bhbj7igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC4zLiBBY2Nlc3Mg VG9rZW5zOiBDaGFuZ2Ug4oCcQWNjZXNzIHRva2VuIChhcyB3ZWxsIGFzIGFueSBhY2Nlc3MgdG9r ZW4gdHlwZS1zcGVjaWZpYyBhdHRyaWJ1dGVzKeKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+QWNj ZXNzIHRva2VucyAoYXMgd2VsbCBhcyBhbnkgYWNjZXNzIHRva2VuIHR5cGUgc3BlY2lmaWMgYXR0 cmlidXRlcyk8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTAuMy4gQWNj ZXNzIFRva2VuczogQ2hhbmdlIOKAnGd1ZXNzZWQgdG8gcHJvZHVjZeKAnSB0byDigJw8c3BhbiBs YW5nPSJFTiI+Z3Vlc3NlZCBzbyBhcyB0byBwcmV2ZW50IHVuYXV0aG9yaXplZCBwYXJ0aWVzIGZy b20gcHJvZHVjaW5nPC9zcGFuPuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjQu IFJlZnJlc2ggVG9rZW5zOiBDb21tZW50IOKAnEFzIG1lbnRpb25lZCBwcmV2aW91c2x5IHdlIHJl YWxseSBzaG91bGQgZXhwbGFpbiB3aHkgd2UgaW50cm9kdWNlZCByZWZyZXNoIHRva2Vucy4gV2l0 aG91dCB1bmRlcnN0YW5kaW5nIHRoZSBpbnRlbnQgb2YgdGhlIG1lY2hhbmlzbSBpdOKAmXMgdW5s aWtlbHkNCiBpbXBsZW1lbnRlcnMgd2lsbCB1c2UgdGhlbSBhcHByb3ByaWF0ZWx5LuKAnTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTAuNC4gUmVmcmVzaCBUb2tlbnM6Jm5ic3A7IENoYW5n ZSDigJxzdG9yYWdlLCBhbmQgc2hhcmVkIG9ubHkgYW1vbmfigJ0gdG8g4oCcc3RvcmFnZSwgYW5k IGFyZSB0byBiZSBzaGFyZWQgb25seSBhbW9uZ+KAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjEwLjQuIFJlZnJlc2ggVG9rZW5zOiZuYnNwOyBDaGFuZ2Ug4oCccmVmcmVzaCB0b2tlbnMg cm90YXRpb27igJ0gdG8g4oCccmVmcmVzaCB0b2tlbiByb3RhdGlvbuKAnS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjEwLjQuIFJlZnJlc2ggVG9rZW5zOiZuYnNwOyBDaGFuZ2Ug4oCcZ3Vl c3NlZCB0byBwcm9kdWNl4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5ndWVzc2VkIHNvIGFzIHRv IHByZXZlbnQgdW5hdXRob3JpemVkIHBhcnRpZXMgZnJvbSBwcm9kdWNpbmc8L3NwYW4+4oCdLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTAuNi4gQXV0aG9yaXphdGlvbiBDb2RlIExlYWth Z2U6IENvbW1lbnQg4oCcSSBmYW5jeSBteXNlbGYgYXMgYmVpbmcgcmVhc29uYWJseSBpbnRlbGxp Z2VudCBhbmQgSeKAmW0gdW5jbGVhciB3aGF0IGF0dGFjayBpcyBhY3R1YWxseSBiZWluZyBkZXNj cmliZWQgaGVyZS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjYuIEF1dGhvcml6 YXRpb24gQ29kZSBMZWFrYWdlOiBDb21tZW50IG9uIOKAnFRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBTSE9VTEQgcmVxdWlyZSB0aGUgY2xpZW50IHRvIHJlZ2lzdGVyIHRoZWlyIHJlZGlyZWN0aW9u IFVSSeKAnTog4oCcV2h5IGlzIHRoaXMgYSBzaG91bGQ/4oCdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4xMC43LiBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFsczogQ29tbWVu dCBvbiDigJxwYXNzd29yZCBhbnRpLXBhdHRlcm7igJ06IOKAnElzIGl0IGZhaXIgdG8gZXhwZWN0 IHRoYXQgdGhlIHJlYWRlciBrbm93cyB3aGF0IHRoZSBwYXNzd29yZCBhbnRpLXBhdHRlcm4gaXM/ IFNob3VsZG7igJl0IHNvbWUgcmVmZXJlbmNlDQogdG8gYSBkZWZpbml0aW9uIG9mIHRoaXMgcGF0 dGVybiBiZSByZXF1aXJlZD/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjcuIFJl c291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzOiBDb21tZW50IG9uIOKAnFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVzdHJpY3QgdGhlIHNjb3BlIGFuZCBsaWZldGltZSBv ZiBhY2Nlc3MgdG9rZW5zIGlzc3VlZCB2aWEgdGhpcyBncmFudCB0eXBl4oCdOiDigJxSZXN0cmlj dCBpbg0KIHdoYXQgd2F5cz8gQmFzZWQgb24gd2hhdCBjcml0ZXJpYT8gVGhpcyBzdGF0ZW1lbnQg aXMgdGhlIGVxdWl2YWxlbnQgb2Ygc2F5aW5nIOKAnGRvbuKAmXQgZG8gYmFkIHN0dWZm4oCdLiBQ ZXJoYXBzIHRydWUgYnV0IG5vdCB0ZXJyaWJseSB1c2VmdWwu4oCdPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4xMC4xMi4gQ3Jvc3MtU2l0ZSBSZXF1ZXN0IEZvcmdlcnk6IENvbW1lbnQgb24g Zmlyc3QgcGFyYWdyYXBoOiDigJxJIGNoYWxsZW5nZSBhbnkgcmVhc29uYWJseSBpbnRlbGxpZ2Vu dCBwZXJzb24gd2hvIGRvZXMgbm90IGFscmVhZHkga25vdyB3aGF0IGEgQ1NSRiBpcyB0byByZWFk IHRoaXMgcGFyYWdyYXBoIGFuZA0KIGNvbWUgYXdheSBhbnkgY2xlYXJlciBhcyB0byB3aGF0IGlz IGJlaW5nIGRpc2N1c3NlZC4gQXQgYSBtaW5pbXVtIGlzbuKAmXQgc29tZSByZWZlcmVuY2UgdG8g YSBjb21wbGV0ZSBkZWZpbml0aW9uIG9mIENTUkYgbmVlZGVkIGlmIHRoZXJlIGlzIHRvIGJlIGFu eSBob3BlIG9mIHVzZXIgY29tcGxpYW5jZT/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjEwLjEyLiBDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeTogQ29tbWVudCBvbiDigJxUaGUgInN0 YXRlIiByZXF1ZXN0IHBhcmFtZXRlciBNVVNUIGNvbnRhaW4gYSBub24tZ3Vlc3NhYmxlIHZhbHVl 4oCdOiDigJxBY3R1YWxseSBhIG5vbi1ndWVzc2FibGUgdmFsdWUgd29u4oCZdCBzdG9wIHRoZSBh dHRhY2sgZGlzY3Vzc2VkDQogaW4gdGhlIHByZXZpb3VzIHBhcmFncmFwaCBvbiBpdHMgb3duLiBX aGF04oCZcyBhbHNvIG5lZWRlZCBpcyBhIHdheSB0byB1bmlxdWVseSAoYW5kIHVuYnJlYWthYmx5 KSBhc3NvY2lhdGUgdGhlIHN0YXRlIHdpdGggYSBwYXJ0aWN1bGFyIHVzZXIgc28gdGhhdCBpZiBh biBhdXRob3JpemF0aW9uIGNvZGUgc3dhcCBvY2N1cnMgaXQgY2FuIGJlIHJlbGlhYmx5IGRldGVj dGVkLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTAuMTMuIENsaWNramFja2luZzog Q29tbWVudCBvbiDigJx4LWZyYW1lLW9wdGlvbnPigJ06IOKAnFRoZSByZWNvbW1lbmRhdGlvbiBz ZWVtcyBjb25mdXNlZC4gSXMgaXQgby5rLiB0byBqdXN0IHJlbHkgb24geC1mcmFtZS1vcHRpb25z IG9yIE1VU1Qgb3RoZXIgYWN0aW9ucyBiZSB0YWtlbj/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjExLjEuJm5ic3A7IFRoZSBPQXV0aCBBY2Nlc3MgVG9rZW4gVHlwZSBSZWdpc3RyeTog Q2hhbmdlIOKAnHRva2UgdHlwZeKAnSB0byDigJx0b2tlbiB0eXBl4oCdLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+MTEuMS4xLiZuYnNwOyBSZWdpc3RyYXRpb24gVGVtcGxhdGU6IENoYW5n ZSDigJw8c3BhbiBsYW5nPSJFTiI+cHJvdGVjdGVkIHJlc291cmNlcyByZXF1ZXN0cyB1c2luZyBh Y2Nlc3MgdG9rZW48L3NwYW4+4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5wcm90ZWN0ZWQgcmVz b3VyY2UgcmVxdWVzdHMgdXNpbmcgYWNjZXNzIHRva2Vuczwvc3Bhbj7igJ0uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4xMS4xLjEuJm5ic3A7IFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZTombmJz cDsgQ2hhbmdlIOKAnFJlZmVyZW5jZSB0byBkb2N1bWVudOKAnSB0byDigJxSZWZlcmVuY2UgdG8g dGhlIGRvY3VtZW504oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0 aEBpZXRmLm9yZzwvYT48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvYT48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --_000_9C1A8698157C4FB89FAA016FD4722951hueniversecom_-- From tonynad@microsoft.com Thu Aug 11 12:17:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249A821F8B77 for ; Thu, 11 Aug 2011 12:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.465 X-Spam-Level: X-Spam-Status: No, score=-7.465 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUYUQgNytGt8 for ; Thu, 11 Aug 2011 12:17:54 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 6521A21F8B55 for ; Thu, 11 Aug 2011 12:17:54 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 12:18:29 -0700 Received: from DB3EHSOBE005.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 12:18:28 -0700 Received: from mail116-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 19:18:27 +0000 Received: from mail116-db3 (localhost.localdomain [127.0.0.1]) by mail116-db3-R.bigfish.com (Postfix) with ESMTP id 7B805116844F for ; Thu, 11 Aug 2011 19:18:27 +0000 (UTC) X-SpamScore: -28 X-BigFish: PS-28(zz9371Kc89bh1418Mc857h98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h) X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT008.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail116-db3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT008.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail116-db3 (localhost.localdomain [127.0.0.1]) by mail116-db3 (MessageSwitch) id 1313090305722178_16594; Thu, 11 Aug 2011 19:18:25 +0000 (UTC) Received: from DB3EHSMHS003.bigfish.com (unknown [10.3.81.250]) by mail116-db3.bigfish.com (Postfix) with ESMTP id A4D6E69004F; Thu, 11 Aug 2011 19:18:25 +0000 (UTC) Received: from SN2PRD0302HT008.namprd03.prod.outlook.com (207.46.4.139) by DB3EHSMHS003.bigfish.com (10.3.87.103) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 19:18:24 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT008.namprd03.prod.outlook.com ([10.27.90.177]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 19:18:22 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland Thread-Index: AcxXpdCrqvPON2CRS72O2K03CR90kwAFmfQAAB6LQIAACSKTAAAAHOYA Date: Thu, 11 Aug 2011 19:18:21 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> <356C947C-E0E9-4AC4-9D48-36370B40763B@hueniverse.com> <9C1A8698-157C-4FB8-9FAA-016FD4722951@hueniverse.com> In-Reply-To: <9C1A8698-157C-4FB8-9FAA-016FD4722951@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89D74SN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT008.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:17:58 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89D74SN2PRD0302MB137_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVwLCBJIGJlbGlldmUgdGhleSBhcmUNCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYgW21haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAx MjoxNSBQTQ0KVG86IEFudGhvbnkgTmFkYWxpbg0KQ2M6IE1pa2UgSm9uZXM7IG9hdXRoQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBQYXJ0aWFsIHNldCBvZiBsYXN0IGNhbGwgY29t bWVudHMgb24gT0F1dGggZHJhZnQgMjAgZnJvbSBZYXJvbiBHb2xhbmQNCg0KSnVzdCB3YW50IHRv IG1ha2Ugc3VyZSBpdCBpcyBjb3ZlcmVkIGJ5IHRoZSBub3JtYWwgY29udHJpYnV0aW9uIHJ1bGUu DQoNCk9uIEF1ZyAxMSwgMjAxMSwgYXQgMTA6NTgsICJBbnRob255IE5hZGFsaW4iIDx0b255bmFk QG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSGUg aXMgb3V0IG9uIHZhY2F0aW9uIHdpdGggbm8gYWNjZXNzIGFuZCBoZSBsZWZ0IE1pa2Ugd2l0aCBh IGJ1bmNoIG9mIGNvbW1lbnRzIHRvIHB1bGwgdG9nZXRoZXIgdG8gc3VibWl0IGFuZCB3ZSBrbmV3 IHRoYXQgeW91IHdhbnRlZCB0aGVzZSBjb21tZW50cyB0byBlbnN1cmUgdGhhdCB0aGUgc3BlYyBp cyB0aGUgYmVzdCBpdCBjYW4gYmUuDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z108bWFpbHRvOlttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBF cmFuIEhhbW1lci1MYWhhdg0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTAsIDIwMTEgNToxOSBQ TQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBQYXJ0aWFsIHNldCBvZiBsYXN0IGNhbGwgY29t bWVudHMgb24gT0F1dGggZHJhZnQgMjAgZnJvbSBZYXJvbiBHb2xhbmQNCg0KSXMgdGhlcmUgYSBy ZWFzb24gd2h5IE1yIEdvbGFuZCBpc250IHNlbmRpbmcgaGlzIG93biBjb21tZW50cyBpbj8NCg0K T24gQXVnIDEwLCAyMDExLCBhdCAxNzozOSwgIk1pa2UgSm9uZXMiIDxNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0K MS40LiBBdXRob3JpemF0aW9uIEdyYW50OiBDaGFuZ2Ug4oCccmVzb3VyY2Ugb3duZXIgYXV0aG9y aXphdGlvbuKAnSB0byDigJxyZXNvdXJjZSBvd25lcuKAmXMgYXV0aG9yaXphdGlvbuKAnS4NCg0K MS40LjEuIEF1dGhvcml6YXRpb24gQ29kZTogIENvbW1lbnQ6IOKAnEl0IHNlZW1zIG9kZCB0aGF0 IHdlIGNhbiBkaXNjdXNzIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgd2l0aG91dCBhbHNvIGRpc2N1 c3NpbmcgdGhlIHNlY3VyaXR5IGlzc3VlcyBpdCByYWlzZXMgKGUuZy4gcGFzc2luZyBzZWN1cmUg aW5mb3JtYXRpb24gdmlhIGEgYnJvd3NlcikgYW5kIHRodXMgbW90aXZhdGluZyB0aGUgaW50cm9k dWN0aW9uIG9mIHRoZSByZWZyZXNoIHRva2VuLiBJIHdvdWxkIGV4cGVjdCB0aGlzIHRvIGJlIHJl ZmVycmVkIHRvIGhlcmUuICBIYXZpbmcgcmVhZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c2VjdGlvbiBJIGNhbiBmaW5kIG5vIGNvaGVyZW50IGRpc2N1c3Npb24gdGhlcmUgZWl0aGVyIG9m IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGFuZCB0aGUg cmVmcmVzaCB0b2tlbiBhbmQgd2h5IG9uZSBtb3RpdmF0ZWQgdGhlIG90aGVyLiBJIHRoaW5rIHRo aXMgaXMgc29tZXRoaW5nIGltcG9ydGFudCBmb3IgaW1wbGVtZW50ZXJzIHRvIHVuZGVyc3RhbmQu 4oCdDQoNCjEuNC4yLiAgSW1wbGljaXQ6ICBDb21tZW50OiDigJxJIGZpbmQgdGhpcyBzZWN0aW9u IGNvbmZ1c2luZy4gSSB0aGluayBhbiBleGFtcGxlIGlzIGFsbCBidXQgbWFuZGF0b3J5IGhlcmUg aWYgdGhlIHJlYWRlciBpcyB0byB1bmRlcnN0YW5kIHdoYXQgaXMgaW50ZW5kZWQuICBGb3IgZXhh bXBsZSwgd2hlbiBJIGZpcnN0IHJlYWQgdGhpcyBzZWN0aW9uIEkgdGhvdWdodCBpdCB3YXMgc29t ZSBraW5kIG9mIHNob3J0IGN1dCB1c2VkIGluIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQgYW5kIGF1 dGhvcml6YXRpb24gc2VydmVyIGhhZCBhIGNsb3NlIHJlbGF0aW9uc2hpcCBhbmQgY291bGQgc2hh cmUgaW5mb3JtYXRpb24gc3VjaCBhcyB0aGUgY2xpZW504oCZcyBpZGVudGl0eSBzbyBubyBhY2Nl c3MgY29kZSB3YXMgbmVlZGVkLiAgTm8gd2hlcmUgaW4gaGVyZSBpcyBhbnkgaGludCB0aGF0IHRo aXMgaXMgYWJvdXQgYnJvd3NlciBiYXNlZCBjbGllbnRzIHdobyBkb27igJl0IGhhdmUgc2VydmVy cyBhbmQgd2hvIG5lZWQgYSB3YXkgdG8gZ2V0IHRva2Vucy4gU2VyaW91c2x5LiBUcnkgdG8gcmVh ZCB0aGlzIHNlY3Rpb24gYXMgc29tZW9uZSB3aG8ga25vd3Mgbm90aGluZyBhYm91dCBPQXV0aCBh bmQgdGVsbCBtZSB0aGF0IHlvdSBnZXQgdGhlIHJpZ2h0IGlkZWEgYmFjayBmcm9tIGl0LiBJdCBu ZWVkcyB0byBiZSB3cml0dGVuIHRvIGJlIGJvdGggZXhwbGljaXQgYXMgdG8gaXRzIGdvYWxzIGFu ZCBjbGVhcmVyIGFzIHRvIGl0cyBtZWFucy7igJ0NCg0KMS40LjIuICBJbXBsaWNpdDogIENoYW5n ZSDigJxhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBhbmQgdGhl4oCdIHRvIOKAnGF1dGhlbnRpY2F0 ZSB0aGUgY2xpZW50IGRpcmVjdGx5LiBUaGXigJ0uDQoNCjEuNC4yLiAgSW1wbGljaXQ6ICBDaGFu Z2Ug4oCcd2VpZ2h0ZWTigJ0gdG8g4oCcd2VpZ2hlZOKAnS4NCg0KMS40LjMuICBSZXNvdXJjZSBP d25lciBQYXNzd29yZCBDcmVkZW50aWFsczogQ29tbWVudCBvbiDigJwod2hlbiBjb21iaW5lZCB3 aXRoIGEgcmVmcmVzaCB0b2tlbinigJ06IOKAnFRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhhdCBy ZWZyZXNoIHRva2VucyBhcmUgbWVudGlvbmVkIGluIHRoZSBzcGVjLiBBbmQgeWV0IHRoZXJlIGlz IG5vIGV4cGxhbmF0aW9uIG9mIHdoYXQgdGhleSBhcmUuIEkgc3VzcGVjdCB0aGV5IHNob3VsZCBh bnl3YXkgYmUgaW50cm9kdWNlZCBpbiBzZWN0aW9uIDEuNC4xIChhcyBwcmV2aW91c2x5IG5vdGVk KSBhbmQgdGhlbiB0aGVpciB1c2UgaGVyZSB3aWxsIG1ha2Ugc2Vuc2UuICBJZiB0aGF0IGlzbuKA mXQgcG9zc2libGUgdGhlbiBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYSBmb3J3YXJkIHJlZmVy ZW5jZSB0byBzZWN0aW9uIDEuNSBiZWxvdyBzbyB0aGUgcmVhZGVyIGhhcyBzb21lIGlkZWEgb2Yg d2hhdOKAmXMgZ29pbmcgb24u4oCdDQoNCjEuNC40LiAgQ2xpZW50IENyZWRlbnRpYWxzOiAgQ29t bWVudCBvbiDigJwodGhlIGNsaWVudCBpcyBhbHNvIHRoZSByZXNvdXJjZSBvd25lcinigJ06IOKA nEkgdGhpbmsgdGhpcyBpcyBtaXNsZWFkaW5nLiBJbWFnaW5lIHNvbWV0aGluZyBsaWtlIE9mZmlj ZSB3aGVyZSBhIGNsaWVudCBoYXMgYmVlbiBncmFudGVkIGFjY2VzcyB0byBhIHBhcnRpY3VsYXIg cmVzb3VyY2UgYnkgdGhlIHJlc291cmNlIG93bmVyLiBUaGUgY2xpZW50IGNhbiB0aGVuIGFzayBm b3IgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSByZXNvdXJjZSB1c2luZyB0aGUgY2xpZW50IGNyZWRl bnRpYWxzIGFuZCBubyBhY2Nlc3MgY29kZSBvciByZWZyZXNoIHRva2VuLiBKdXN0IGhhdmluZyB0 aGUgYWRkcmVzcyBvZiB0aGUgaW50ZW5kZWQgcmVzb3VyY2UgKHByb2JhYmx5IHByb3ZpZGVkIHZp YSBTQ09QRSkgYWxvbmcgd2l0aCB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGlzIG1vcmUgdGhhbiBl bm91Z2ggdG8gZGVjaWRlIGlmIGFuIGFjY2VzcyB0b2tlbiBzaG91bGQgYmUgaXNzdWVkLg0KDQpN eSBwb2ludCBpcyB0aGF0IHRoZSBjbGllbnQgY3JlZGVudGlhbHMgc2NlbmFyaW8gaXMgZnVsbHkg YXBwbGljYWJsZSB0byBjYXNlcyB3aGVyZSB0aGUgY2xpZW50IGlzIG5vdCB0aGUgcmVzb3VyY2Ug b3duZXIgYnV0IGluIHdoaWNoIHRoZSByZXNvdXJjZSBVUkkgcHJvdmlkZXMgYWxsIHRoZSBjb250 ZXh0IG5lZWRlZCB0byBkZXRlcm1pbmUgaWYgdGhlIGNsaWVudCBzaG91bGQgYmUgYWJsZSB0byBn ZXQgYW4gYWNjZXNzIHRva2VuLiBJIHRoaW5rIHRoZSBjdXJyZW50IHRleHQgd291bGQgaW1wbHkg b3RoZXJ3aXNlLg0KDQpTbyBJIHdvdWxkIHByb3Bvc2UgY2hhbmdpbmcgdGhlIHNlbnRlbmNlIHRv IOKAnENsaWVudCBjcmVkZW50aWFscyBhcmUgdXNlZCBhcyBhbiBhdXRob3JpemF0aW9uIGdyYW50 IHdoZW4gdGhlIGNsaWVudCBpcyBhY3Rpbmcgb24gaXRzIG93biBiZWhhbGYgKHRoZSBjbGllbnQg aXMgYWxzbyB0aGUgcmVzb3VyY2Ugb3duZXIpIG9yIHdoZW4gdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIGhhcyBlbm91Z2ggY29udGV4dCB0byBkZXRlcm1pbmUgZnJvbSB0aGUgYWNjZXNzIHRva2Vu IHJlcXVlc3QgaWYgdGhlIGNsaWVudCBoYXMgYXV0aG9yaXphdGlvbiB0byBhY2Nlc3MgdGhlIHJl cXVlc3RlZCByZXNvdXJjZS7igJ3igJ0NCg0KMS40LjUuIEV4dGVuc2lvbnM6IENvbW1lbnQ6IOKA nEkgd291bGQgY2hhbmdlIHRoaXMgc2VudGVuY2UgdG8gcmVhZCDigJxBZGRpdGlvbmFsIGdyYW50 IHR5cGVzIG1heSBiZSBkZWZpbmVkIHRvIHN1cHBvcnQgbmV3IGFwcHJvYWNoZXMgdG8gYXV0aGVu dGljYXRpb24vYXV0aG9yaXphdGlvbiBhcyB3ZWxsIGFzIHRvIHByb3ZpZGUgYSBicmlkZ2UgYmV0 d2VlbiBPQXV0aCBhbmQgb3RoZXIgcHJvdG9jb2xzLuKAneKAnQ0KDQoxLjUuIFJlZnJlc2ggVG9r ZW46IENvbW1lbnQgb24g4oCcUmVmcmVzaCB0b2tlbnMgYXJlIGNyZWRlbnRpYWxzIHVzZWQgdG8g b2J0YWluIGFjY2VzcyB0b2tlbnMu4oCdOiDigJxUaGlzIHNlbnRlbmNlIHByZXN1bWVzIHRoYXQg cmVmcmVzaCB0b2tlbnMgYXJlIHNlbGYtY29udGFpbmVkIGNyZWRlbnRpYWxzLiBJbiBvdGhlciB3 b3JkcyB0aGF0IG9uZSBjYW4gZ2V0IGFuIGFjY2VzcyB0b2tlbiBqdXN0IHVzaW5nIGEgcmVmcmVz aCB0b2tlbiBhbmQgbm90aGluZyBlbHNlLiBUaGlzIHByZXN1bXB0aW9uIGlzIHJlYnV0dGVkIGxh dGVyIGluIHRoZSBkb2N1bWVudCBidXQgSSB0aGluayBpdOKAmXMgY29uZnVzaW5nIHRvIGltcGx5 IG9uZSB0aGluZyBoZXJlIGFuZCBzdGF0ZSBvdGhlcndpc2UgbGF0ZXIgb24u4oCdDQoNCjEuNS4g UmVmcmVzaCBUb2tlbjogQ2hhbmdlIOKAnGEgcHJvdGVjdGVkIHJlc291cmNlIHJlcXVlc3Rz4oCd IHRvIOKAnGEgcHJvdGVjdGVkIHJlc291cmNlIHJlcXVlc3TigJ0uDQoNCjEuNS4gUmVmcmVzaCBU b2tlbjogQ29tbWVudCBvbiDigJwoRykgIFRoZSBjbGllbnQgcmVxdWVzdHMgYSBuZXcgYWNjZXNz IHRva2VuIGJ5IGF1dGhlbnRpY2F0aW5nIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFu ZCBwcmVzZW50aW5nIHRoZSByZWZyZXNoIHRva2VuLuKAnTog4oCcSHVt4oCmIG5vdyB0aGUgdGV4 dCBzZWVtcyB0byBjb250cmFkaWN0IGl0c2VsZi4gQWJvdmUgaXQgc2VlbWVkIGxpa2UgeW91IGNv dWxkIHVzZSB0aGUgcmVmcmVzaCB0b2tlbiBieSBpdHNlbGYgdG8gZ2V0IGFuIGFjY2VzcyB0b2tl biBhbmQgSSBoYWQgdG8gYXNrIGZvciBsYW5ndWFnZSB0aGF0IG1hZGUgaXQgY2xlYXIgdGhhdCB5 b3UgY291bGQgdXNlIGEgcmVmcmVzaCB0b2tlbiB3aXRoIG90aGVyIGNyZWRlbnRpYWxzLiAgQnV0 IHRoZSB0ZXh0IG9mIHBvaW50IEcgbm93IGltcGxpZXMgdGhlIGV4YWN0IG9wcG9zaXRlLCB0aGF0 IHJlZnJlc2ggdG9rZW5zIGNhbiBvbmx5IGJlIHVzZWQgd2l0aCBvdGhlciBjcmVkZW50aWFscyBh bmQgbm90IGJ5IHRoZW1zZWx2ZXMuIChFdmVuIHRob3VnaCB0aGUgcGljdHVyZSBpbiBmaWd1cmUg MiBmb3Igc3RlcCBHIGltcGxpZXMgdGhlIG9wcG9zaXRlKS4gSSB3b3VsZCBlZGl0IHRoaXMgbGFu Z3VhZ2UgdG8gc2F5IOKAnFRoZSBjbGllbnQgcmVxdWVzdHMgYSBuZXcgYWNjZXNzIHRva2VuLiBE ZXBlbmRpbmcgb24gdGhlIGF1dGhvcml6YXRpb24gc2VydmVy4oCZcyBwb2xpY2llcyB0aGlzIHJl cXVlc3QgbWlnaHQgYmUgbWFkZSB3aXRoIHRoZSByZWZyZXNoIHRva2VuIGJ5IGl0c2VsZiBvciB3 aXRoIGEgY29tYmluYXRpb24gb2YgdGhlIHJlZnJlc2ggdG9rZW4gYW5kIG90aGVyIGNsaWVudCBj cmVkZW50aWFscy7igJ3igJ0NCg0KMi4xLiBDbGllbnQgVHlwZXM6IENvbW1lbnQgb24g4oCcdXNl ci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbuKAnTog4oCcR2l2ZSB0aGUgcG9vciByZWFkZXIgYSBo aW50IGFuZCBtZW50aW9uIOKAmGJyb3dzZXLigJkgc29tZXdoZXJlIGluIHRoZSBwYXJhZ3JhcGgg YmVsb3cuIEZvciBleGFtcGxlIOKAnEEgdXNlci1hZ2VudC1iYXNlZCBhcHBsaWNhdGlvbiBpcyBh IHB1YmxpYyBjbGllbnQgKHN1Y2ggYXMgYSB3ZWIgYnJvd3NlcikgaW4gd2hpY2ggdGhl4oCmLuKA neKAnQ0KDQoyLjEuIENsaWVudCBUeXBlczogd2ViIGFwcGxpY2F0aW9uOiBDaGFuZ2Ug4oCcYWNj ZXNzIHRva2VucyBvciByZWZyZXNoIHRva2VucywgY2FuIHJlY2VpdmUgYW4gYWNjZXB0YWJsZSBs ZXZlbOKAnSB0byDigJxhY2Nlc3MgdG9rZW5zIG9yIHJlZnJlc2ggdG9rZW5zLCBjYW4sIGluIHNv bWUgY2FzZXMsIHJlY2VpdmUgYW4gYWNjZXB0YWJsZSBsZXZlbOKAnS4NCg0KMi40LiBDbGllbnQg QXV0aGVudGljYXRpb246ICBBZGQgYSBwZXJpb2QgYWZ0ZXIg4oCcZXRj4oCdLg0KDQoyLjQuMS4g Q2xpZW50IFBhc3N3b3JkOiBDb21tZW50IG9uIOKAnGNoYXJzZXQ9VVRGLTjigJ06IOKAnFRoZSB1 c2Ugb2YgVVRGLTggd2l0aCB4LXd3dy1mb3JtLXVybGVuY29kZWQgaXMgZXhwbGljaXRseSBiYW5u ZWQgYnkgSFRNTCA0LjAxIHNlY3Rpb24gMTcuMTMuMS4gSWYgd2Ugd2FudCB0byB1c2UgVVRGLTgg dGhlbiB3ZSBoYXZlIHRvIHVzZSBtdWx0aXBhcnQvZm9ybS1kYXRhLCBhbHNvIGRlZmluZWQgYnkg SFRNTCA0LjAxIChzZWN0aW9uIDE3LjEzLjQpLiBCdXQgc2luY2Ugbm9ib2R5IHdvdWxkIGFjdHVh bGx5IHdhbnQgdG8gZG8gdGhhdCBJIHdvdWxkIHN1Z2dlc3QgcHV0dGluZyBpbiBhIHJlZmVyZW5j ZSB0byBzZWN0aW9uIDQuMiBvZiBSRkMgNTU1MiB3aGljaCBhY3R1YWxseSBkZWZpbmVzIGhvdyB0 byB1c2UgVVRGLTggd2l0aCB4LXd3dy1mb3JtLXVybGVuY29kZWQgYW5kIHNwZWNpZnlpbmcgdGhh dCB0aGUgNTU1MiBleHRlbnNpb24gTVVTVCBiZSBzdXBwb3J0ZWQgYnkgT0F1dGggcGFydGljaXBh bnRzLuKAnQ0KDQozLjEuICBBdXRob3JpemF0aW9uIEVuZHBvaW50OiBDb21tZW50IG9uIGZpcnN0 IHNlbnRlbmNlOiAg4oCcVGhlcmUgaXMgYSB0aGlyZCBvcHRpb24g4oCTIG5vbmUgb2YgdGhlIGFi b3ZlLiAgSXQgd291bGQgYmUgYSBzaGFtZSBpZiB0aGUgdGV4dCBvZiB0aGlzIGRyYWZ0IGV4cGxp Y2l0bHkgcHJvaGliaXRzIHRoYXQgcGF0dGVybi7igJ0NCg0KMy4xLiAgQXV0aG9yaXphdGlvbiBF bmRwb2ludDogIENvbW1lbnQgb24g4oCcW1JGQzM5ODZdIHNlY3Rpb24gM+KAnTog4oCcU2hvdWxk buKAmXQgd2UgcG9pbnQgZGlyZWN0bHkgdG8gc2VjdGlvbiAzLjQgd2hpY2ggZXhhY3RseSBkZWZp bmVzIHRoZSBxdWVyeSBjb21wb25lbnQ/4oCdDQoNCjMuMS4gIEF1dGhvcml6YXRpb24gRW5kcG9p bnQ6ICBDb21tZW50IG9uIOKAnE1VU1QgYmUgcmV0YWluZWQgd2hlbiBhZGRpbmcgYWRkaXRpb25h bCBxdWVyeQ0KICAgcGFyYW1ldGVyc+KAnTog4oCcSElHSCBJTVBPUlRBTkNFIOKAkyBUaGlzIHNw ZWNpZmljYXRpb24gaXMgaW5jb21wbGV0ZS4gU2VjdGlvbiAzLjQgb2YgUkZDIDM5ODYgc2ltcGx5 IGFzc2VydHMgdGhlIGV4aXN0ZW5jZSBvZiBhIHF1ZXJ5IGNvbXBvbmVudC4gSXQgc2F5cyBub3Ro aW5nIGFib3V0IHRoZSBzeW50YXggb2YgdGhhdCBjb21wb25lbnQuIFRoZSBzcGVjIGFzc3VtZXMg dGhhdCB0aGUgY29tcG9uZW50IGlzIHVzaW5nIHgtd3d3LWZvcm0tdXJsZW5jb2RlZCBidXQgdGhh dCBpcyBub3QgaW4gYW55IHdheSBtYW5kYXRlZCBieSBSRkMgMzk4Ni4gU28gdGhlcmUgaXMgYSBu b3JtYXRpdmUgc2VudGVuY2UgbWlzc2luZyBoZXJlIHdoaWNoIHN0YXRlcyB0aGF0IGFueSBxdWVy eSBwYXJhbWV0ZXIgb24gdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnTigJlzIFVSSSBNVVNUIGJl IGRlZmluZWQgYXMgc3BlY2lmaWVkIGluIHgtd3d3LWZvcm0tdXJsZW5jb2RlZC7igJ0NCg0KMy4x LiAgQXV0aG9yaXphdGlvbiBFbmRwb2ludDogIENvbW1lbnQgb24g4oCcVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIFNIT1VMRCBpZ25vcmUgdW5yZWNvZ25pemVkIHJlcXVlc3QgcGFyYW1ldGVycy7i gJ06IOKAnEFsdGhvdWdoIHRoYXQgaXMgbm9ybWFsIGJlaGF2aW9yIGZvciBhcHBsaWNhdGlvbiBw cm90b2NvbHMgaXQgc2VlbXMgcmF0aGVyIGRhbmdlcm91cyBmb3IgYSBzZWN1cml0eSBwcm90b2Nv bC4gQWZ0ZXIgYWxsIHdoYXQgaWYgdGhlIGNsaWVudCBwdXQgaW4gYSBwYXJhbWV0ZXIgc3BlY2lm eWluZyBzb21ldGhpbmcgc2VjdXJpdHkgcmVsYXRlZCBhYm91dCB0aGUgcmVxdWVzdCB0aGlua2lu ZyB0aGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHdvdWxkIGhvbm9yIGl0IGFuZCB0aGVu IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHNpbGVudGx5IGlnbm9yZXMgaXQ/ICBBZ2Fpbiwg dGhpcyBpcyBhIHNlY3VyaXR5IHByb3RvY29sLCBub3QgYSBnZW5lcmljIGFwcGxpY2F0aW9uIHBy b3RvY29sLCBpdCBzZWVtcyB0byBiZSB0aGF0IHVucmVjb2duaXplZCBwYXJhbWV0ZXJzIHNob3Vs ZCBjYXVzZSBhIGZhaWx1cmUu4oCdDQoNCjMuMS4yLiAgUmVkaXJlY3Rpb24gRW5kcG9pbnQ6IENv bW1lbnQgb24g4oCcd2hlbiBpbml0aWF0aW5nIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3TigJ06 IOKAnEkgd291bGQgc3VnZ2VzdCBtb3JlIGV4cGxpY2l0IGxhbmd1YWdlIOKAnG9yIGFzIHNwZWNp ZmllZCBpbiB0aGUgcmVkaXJlY3Rpb24gVVJJIHZhbHVlIGluIHRoZSBhdXRob3JpemF0aW9uIHJl cXVlc3Qu4oCd4oCdDQoNCjMuMS4yLjIuIFJlZ2lzdHJhdGlvbiBSZXF1aXJlbWVudHM6IENvbW1l bnQgb24gbGFzdCB3b3JkIOKAnHBhdGjigJ06IOKAnEh1aD8gU2NoZW1lLCBhdXRob3JpemF0aW9u IGFuZCBwYXRoIGlzIGEgY29tcGxldGUgVVJJIG1pbnVzIGEgcXVlcnkgY29tcG9uZW50LiAgSXMg dGhlIGdvYWwgdG8gc3BlY2lmaWNhbGx5IG1hbmRhdGUgdGhhdCBvbmx5IHRoZSBxdWVyeSBjb21w b25lbnQgY2FuIHZhcnkgYW5kIHRoZSByZXN0IG9mIHRoZSBVUkkgTVVTVCBiZSBzdGF0aWM/IElm IHNvIHRoYXQgc2hvdWxkIGJlIHN0YXRlZCBleHBsaWNpdGx5IHJhdGhlciB0aGFuIGltcGxpY2l0 bHkgYXMgaXQgaXMgbm93LiAgQnV0IEkgdGhpbmssIGlmIHRoYXQgaXMgdGhlIGludGVudCwgaXQg Z29lcyB0b28gZmFyLiBXZSBzaG91bGQgYWxzbyBhbGxvdyBmb3IgYWRkaXRpb25hbCBwYXRoIHNl Z21lbnRzIHRvIGJlIGFkZGVkIHRvIHRoZSBVUkkgcGF0aCBiZXlvbmQgdGhlIHJlZ2lzdGVyZWQg cHJlZml4LiBBc3N1bWluZyB3ZSBjYW4gYWRkcmVzcyB0aGUgc2VjdXJpdHkgcHJvYmxlbSBpbiB0 aGUgbmV4dCBjb21tZW50LuKAnQ0KDQozLjEuMi4zLiBEeW5hbWljIENvbmZpZ3VyYXRpb246IENv bW1lbnQgb24g4oCcc2VjdGlvbiA24oCdOiAg4oCcVGhlIHJlZmVyZW5jZSB0byBzZWN0aW9uIDYg aXMgaW5jb21wbGV0ZS4gU2VjdGlvbiA2IGRlZmluZXMgbm8gbGVzcyB0aGFuIDYgZGlmZmVyZW50 IGF4aXPigJlzIG9uIHdoaWNoIFVSSSBjb21wYXJpc29ucyBjYW4gdmFyeS4gRnVydGhlcm1vcmUg YXMgcmVjZW50bHkgZG9jdW1lbnRlZCBpbiBkcmFmdC10aGFsZXItaWFiLWlkZW50aWZpZXItY29t cGFyaXNvbi0wMC50eHQgaXQgaXMgdHJpdmlhbGx5IGVhc3kgdG8gc2NyZXcgdXAgVVJJIGNvbXBh cmlzb25zIGFuZCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIGFyZSBwcmV0dHkgZGlyZS4gUGVy c29uYWxseSBJIHRoaW5rIHRoYXQgdGhlIG9ubHkgc2FuZSBhcHByb2FjaCBnaXZlbiB0aGUgaXNz dWVzIGluIHRoZSBwcmV2aW91cyBsaW5rIGlzIHRvIGFkb3B0IHNlY3Rpb24gNi4yLjEgb2YgUkZD IDM5ODYuDQoNCkkgYW0gYSBiaXQgc2NhcmVkIG9mIGhvdyB0byBoYW5kbGUgcGFydGlhbCBtYXRj aGVzLiBJdOKAmXMgdGVtcHRpbmcgdG8gYXJndWUgdGhhdCBzbyBsb25nIGFzIHRoZSBzY2hlbWEg aGFzIGFuIGF1dGhvcml0eSBhbmQgYXQgbGVhc3Qgb25lIHBhdGggc2VnbWVudCB0aGVuIHdlIGNh biBqdXN0IHVzZSBhIHBhcnRpYWwgc3RyaW5nIG1hdGNoIGJ1dCBib3kgb2ggYm95IGRvIEkgc2Vl IHBlb3BsZSBzY3Jld2luZyB0aGF0IG9uZSB1cCByb3lhbGx5LiBUaGlzIGlzIHNjYXJ5IGVub3Vn aCB0aGF0IEkgdGhpbmsgSSBjYW4gYmUgYXJndWVkIGludG8gc2F5aW5nIHRoYXQgcGFydGlhbCBw cmUtcmVnaXN0ZXJlZCBVUklzIE1VU1Qgb25seSBkaWZmZXIgYnkgdGhlIHF1ZXJ5IGNvbXBvbmVu dC4NCg0KSW4gYW55IGNhc2UgdGhpcyBpc3N1ZXMgbmVlZHMgdG8gYmUgZXhwbGljaXRseSBjYWxs ZWQgb3V0IGZvciBhbGwgVVJJIGNvbXBhcmlzb25zIHJlcXVpcmVkIGJ5IHRoZSBzcGVjIGFuZCBu b3JtYXRpdmVseSBkZWZpbmVkLiBPdGhlcndpc2Ugd2Ugd2lsbCBlbmQgdXAgd2l0aCBhbGwgdGhl IHNlY3VyaXR5IGlzc3VlcyBpbiBEYXZl4oCZcyBJRC7igJ0NCg0KMy4xLjIuNC4gIEludmFsaWQg RW5kcG9pbnQ6IENvbW1lbnQgb24g4oCcb3BlbiByZWRpcmVjdG9y4oCdOiDigJxIb3cgbWFueSBw ZW9wbGUgZXZlbiBrbm93IHdoYXQgdGhlIGhlY2sgYW4gb3BlbiByZWRpcmVjdG9yIGlzPyBJIHRo aW5rIHdlIG5lZWQgYSBzZWN0aW9uIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0 aW9uIHRoYXQgZGVmaW5lcyB3aGF0IGFuIG9wZW4gcmVkaXJlY3RvciBpcyBhbmQgd2h5IGl04oCZ cyBiYWQuIEFsdGVybmF0aXZlbHkgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGEgY29tcGxldGUg ZGVmaW5pdGlvbiBzb21ld2hlcmUgZWxzZSBpcyBhbHNvIGZpbmUu4oCdDQoNCjMuMi4xLiBDbGll bnQgQXV0aGVudGljYXRpb246IENoYW5nZSDigJxSZWNvdmVyeeKAnSB0byDigJxSZWNvdmVyaW5n 4oCdLg0KDQozLjIuMS4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiBDaGFuZ2Ug4oCcY3JlZGVudGlh bHMsIGJ5IHByZXZlbnRpbmcgYW4gYXR0YWNrZXIgZnJvbSBhYnVzaW5n4oCdIHRvIOKAnGNyZWRl bnRpYWxzLiBUaGlzIHByZXZlbnRzIGFuIGF0dGFja2VyIGZyb20gYWJ1c2luZ+KAnQ0KDQozLjIu MS4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiBDaGFuZ2Ug4oCccGVyaW9kaWMgY3JlZGVudGlhbHMg cm90YXRpb27igJ0gdG8g4oCccGVyaW9kaWMgY3JlZGVudGlhbCByb3RhdGlvbuKAnS4NCg0KMy4y LjEuIENsaWVudCBBdXRoZW50aWNhdGlvbjogQ29tbWVudCBvbiDigJx3aGlsZSByb3RhdGlvbiBv ZiBhIHNpbmdsZSBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlzIHNpZ25pZmljYW50bHkgZWFz aWVy4oCdOiDigJxUaGUgc3BlYyBjYWxscyBvdXQgcm90YXRpb24gb2YgY3JlZGVudGlhbHMgYXMg YmVpbmcgY3J1Y2lhbCBidXQgdGhlbiBkb2VzbuKAmXQgZGVmaW5lIGhvdyB0aGlzIGlzIHRvIGJl IGRvbmU/IFRoYXQgc2VlbXMga2luZCBvZiBvZGQuIFNob3VsZG7igJl0IHdlIGRlZmluZSBhbiBl bmRwb2ludCB3aGVyZSBvbmUgY2FuIHN1Ym1pdCBvbmXigJlzIG9sZCBidXQgdW5leHBpcmVkIGNy ZWRlbnRpYWxzIGZvciBuZXcgb25lcz8gVGhpcyBzdGlsbCBsZWF2ZXMgdGhlIGVkZ2UgY2FzZSBv ZiB3aGF0IHRvIGRvIGlmIHRoZSBvbGQgY3JlZGVudGlhbHMgaGF2ZSBleHBpcmVkIGFuZCBuZXcg b25lcyBoYXZlbuKAmXQgYmVlbiBpc3N1ZWQgYnV0IHRoYXQgaXMgdW5hdm9pZGFibGUgYW5kIGlu IHRoYXQgY2FzZSB3ZSBjYW4gcmVxdWlyZSBvdXQgb2Ygc2NvcGUgYWN0aW9uLuKAnQ0KDQo0LjEu IEF1dGhvcml6YXRpb24gQ29kZTogQ29tbWVudCBvbiBmaXJzdCDigJxe4oCdOiDigJxTaG91bGRu 4oCZdCB0aGlzIGJlIGEgdiBjaGFyYWN0ZXIgYW5kIG5vdCBhIF4/IFRoaXMgd291bGQgbWFrZSBp dCBjb25zaXN0ZW50IHdpdGggQSB3aGljaCBhbHNvIGNyb3NzZXMgdHdvIGJveGVzIGFuZCBwb2lu dHMgaW4gdGhlIHNhbWUgZGlyZWN0aW9uLuKAnQ0KDQo0LjEuIEF1dGhvcml6YXRpb24gQ29kZTog Q2hhbmdlIOKAnElmIHZhbGlkLCByZXNwb25kcyBiYWNrIHdpdGggYW4gYWNjZXNzIHRva2Vu4oCd IHRvIOKAnElmIHRoZSByZXF1ZXN0IGlzIHZhbGlkLCB0aGVuIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciB3aWxsIHJlc3BvbmRzIGJhY2sgd2l0aCBhbiBhY2Nlc3MgdG9rZW4gYW5kIG9wdGlvbmFs bHkgYSByZWZyZXNoIHRva2Vu4oCdLg0KDQo0LjEuMi4gIEF1dGhvcml6YXRpb24gUmVzcG9uc2U6 IENvbW1lbnQg4oCcVGhlIGxhbmd1YWdlIGFyb3VuZCBzY29wZXMgaW4gdGhlIGRvY3VtZW50IGlz IHJlYWxseSBmcnVzdHJhdGluZy4gT25lIG9ubHkgZmluZHMgb3V0IG11Y2ggbGF0ZXIgaW4gdGhl IGRvY3VtZW50IHRoYXQgaXQgaXMgcGVyZmVjdGx5IGFsbG93YWJsZSBmb3IgYW4gYXV0aG9yaXph dGlvbiBzZXJ2ZXIgdG8gbW9yZSBvciBsZXNzIGlnbm9yZSB3aGF0IHNjb3BlcyBhcmUgc3VibWl0 dGVkIGFuZCBpbnN0ZWFkIHRvIGp1c3QgcmV0dXJuIHdoYXRldmVyIHRoZSBoZWxsIHRoZXkgd2Fu dC4gVGhpcyBpcyBhIGZpbmUgZGVzaWduIGNob2ljZSBidXQgaXQgc2VlbXMgbGlrZSB0aGUgc29y dCBvZiB0aGluZyB0aGF0IHNob3VsZCBiZSBmb3JjZWZ1bGx5IHJlcGVhdGVkIGFueXdoZXJlIGlu IHRoZSBzcGVjIHRoYXQgd2UgYWxsb3cgcGVvcGxlIHRvIHN1Ym1pdCBzY29wZXMgc28gbm9ib2R5 IGZvcmdldHMu4oCdDQoNCjQuMS4yLiAgQXV0aG9yaXphdGlvbiBSZXNwb25zZTogQ29tbWVudCBv biDigJxzdGF0ZeKAnTog4oCcRG9u4oCZdCB3ZSBoYXZlIHRvIHByb3ZpZGUgc29tZSBndWlkYW5j ZSBvbiBob3cgbGFyZ2UgdGhlIHN0YXRlIHZhbHVlIGNhbiBzYWZlbHkgYmU/IE90aGVyd2lzZSB3 ZSBhcmUgYXNraW5nIGNsaWVudHMgdG8gcmV3cml0ZSB0aGVpciBzdGF0ZSBtZWNoYW5pc21zIGV2 ZXJ5IHRpbWUgdGhleSB0aHJvdyBpbiBzdXBwb3J0IGZvciBhIG5ldyBwcm90ZWN0ZWQgcmVzb3Vy Y2Ugc2VydmVyLiBXZSBoYXZlIHRvIHNldCBleHBlY3RhdGlvbnMgYWNyb3NzIHRoZSBpbmR1c3Ry eSBpZiB3ZSBhcmUgdG8gaG9wZSBmb3IgYWN0dWFsIGludGVyb3BlcmFiaWxpdHku4oCdDQoNCjQu MS4yLjEuIEVycm9yIFJlc3BvbnNlOiBDb21tZW50IG9uIOKAnFVURi04IGVuY29kZWQgdGV4dOKA nTog4oCcSSB0aGluayBqdXN0IHNheWluZyBVVEYtOCBlbmNvZGVkIHRleHQgY2FuIGJlIG1pc2xl YWRpbmcuIEl04oCZcyBub3QgbGVnYWwgdG8gcHV0IFVURi04IGNoYXJhY3RlcnMgaW50byBhIHgt d3d3LWZvcm0tdXJsZW5jb2RlZCB1c2VkIGluIGEgR0VUIChhcyBkZWZpbmVkIGJ5IHNlY3Rpb24g MTcuMTMuMSBvZiBIVE1MIDQuMDEpLiBTbyB3aGF0IHlvdSBoYXZlIHRvIGRvIGlzIHRha2UgdGhl IFVURi04IFN0cmluZyBhbmQgdGhlbiBVUkwgZW5jb2RlIGl0LiBXaGljaCBpcyBmaW5lIGJ1dCB3 ZSBzaG91bGQgY2FsbCB0aGlzIG91dC4gIE5vdGUgdGhhdCB0aGlzIGlzIGEgc2VwYXJhdGUgaXNz dWUgdGhhbiBVVEYtOCBzdXBwb3J0IGZvciB4LXd3dy1mb3JtLXVybGVuY29kZWQuIFRoYXQgaXNz dWUgb25seSBhcHBsaWVzIHdoZW4gdGhlIGZvcm0gaXMgaW4gdGhlIHJlcXVlc3QgYm9keS4gSW4g dGhpcyBzY2VuYXJpbyB0aGUgZm9ybSBpcyBpbiBhIFVSTC4gVGhlcmUgaXMgbm8gcXVlc3Rpb24g dGhhdCBVUkxzIGluIEhUVFAgcmVxdWVzdCBsaXN0cyBkb27igJl0IHN1cHBvcnQgVVRGLTgu4oCd DQoNCjQuMS4zLiBBY2Nlc3MgVG9rZW4gUmVxdWVzdDogQ2hhbmdlIOKAnEZvciBleGFtcGxlLCB0 aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dpbmcgSFRUUCB1c2luZ+KAnSB0byDigJxGb3IgZXhh bXBsZSwgaWYgdGhlIGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2lu Z+KAnQ0KDQo0LjEuMy4gQWNjZXNzIFRva2VuIFJlcXVlc3Q6IENvbW1lbnQgb24g4oCcdGhhdCB0 aGVpciB2YWx1ZXMgYXJlIGlkZW50aWNhbOKAnTog4oCcVGhpcyB2ZXJiaWFnZSBpc27igJl0IG11 Y2ggdXNlLCBmb3IgZXhhbXBsZSwgaWYgdGhlIGNsaWVudCBjYW4gYWx3YXlzIHNlbmQgdGhlIHNh bWUgcmVkaXJlY3RfdXJpLiBTbywganVzdCB0byBiZSBjbGVhciwgdGhpcyB0ZXh0IGhlcmUgZG9l c27igJl0IGluIGFueXdheSBjaGFuZ2UgbXkgcHJldmlvdXMgcmVjb21tZW5kYXRpb24gcmVnYXJk aW5nIHRoZSBhdHRhY2sgcHJldmlvdXNseSBkZXNjcmliZWQu4oCdDQoNCjQuMS40LiBBY2Nlc3Mg VG9rZW4gUmVzcG9uc2U6IENvbW1lbnQgb24g4oCcInRva2VuX3R5cGUiOiJleGFtcGxlIuKAnTog 4oCcSnVzdCB0byBwcmV2ZW50IGFueSBjb25mdXNpb24gaXQgd291bGQgYmUgZ29vZCB0byBhY3R1 YWxseSBkZWZpbmUgdGhlIHRva2VuX3R5cGUg4oCcZXhhbXBsZeKAnSBpbiB0aGlzIGRvY3VtZW50 IChQcm9iYWJseSBpbiBzZWN0aW9uIDcuMSBhbmQgbGF0ZXIgaW4gdGhlIElBTkEgc2VjdGlvbikg YW5kIHNwZWNpZnkgdGhhdCBpdCBpcyByZXNlcnZlZCBmb3IgdXNlIGluIGV4YW1wbGVzIHdoZXJl IG9uZSBkb2VzIG5vdCB3aXNoIHRvIGJlIG1vcmUgc3BlY2lmaWMu4oCdDQoNCjQuMi4gIEltcGxp Y2l0IEdyYW50OiBDb21tZW50IOKAnEkgaGF2ZSBydW4gaW50byBtdWx0aXBsZSBwZW9wbGUgKGlu Y2x1ZGluZyBteXNlbGYpIHdobyBoYXZlIHJlYWQgdGhlIE9BdXRoIHNwZWMgYW5kIGNhbWUgYXdh eSBjb21wbGV0ZWx5IGNvbmZ1c2VkIGFib3V0IHdoZW4gdGhlIGhlY2sgb25lIGlzIHN1cHBvc2Vk IHRvIHVzZSB0aGUgaW1wbGljaXQgZ3JhbnQgZmxvdyBmb3IuIEl04oCZcyBub3QgaW1tZWRpYXRl bHkgb2J2aW91cyB0aGF0IGl04oCZcyBhIHdheSB0byBzdXBwb3J0IHN0YW5kYWxvbmUgYnJvd3Nl ciBiYXNlZCBjbGllbnRzLiBDYW4gd2UgcHV0IGluIGFuIGV4YW1wbGUgb3Igc29tZXRoaW5nIHRv IG1ha2UgaXQgbW9yZSBvYnZpb3VzIHdoeSBpdOKAmXMgaGVyZT/igJ0NCg0KNC4yLjEuIEF1dGhv cml6YXRpb24gUmVxdWVzdDogQ29tbWVudCBvbiByZWRpcmVjdF91cmk6ICDigJxHaXZlbiB0aGF0 IHRoZSBvbmx5IHdheSB0byBpZGVudGlmeSB0aGUgY2xpZW50IGluIHRoZSBpbXBsaWNpdCBncmFu dCBmbG93IGlzIHZpYSB0aGUgcmVkaXJlY3RfdXJpLCBob3cgY2FuIGl0IGJlIG9wdGlvbmFsP+KA nQ0KDQo0LjMuIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzOiBDaGFuZ2Ug4oCc ZW5hYmxpbmcgdGhlIGdyYW50IHR5cGUsIGFuZCBvbmx5IHdoZW4gb3RoZXIgZmxvd3PigJ0gdG8g 4oCcZW5hYmxpbmcgdGhlIGdyYW50IHR5cGUgYW5kIG9ubHkgdXNlIGl0IHdoZW4gb3RoZXIgZmxv d3PigJ0uDQoNCjQuMy4gUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHM6IENoYW5n ZSDigJxyZXNvdXJjZSBvd25lciBjcmVkZW50aWFsc+KAnSB0byDigJxyZXNvdXJjZSBvd25lcuKA mXMgY3JlZGVudGlhbHPigJ0uDQoNCjQuMy4yLiBBY2Nlc3MgVG9rZW4gUmVxdWVzdDogIENvbW1l bnQgb24g4oCcYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBwcm90ZWN0IHRoZSBlbmRwb2ludCBh Z2FpbnN0IGJydXRlIGZvcmNlIGF0dGFja3PigJ06IOKAnFNob3VsZG7igJl0IHRoZSByZXF1aXJl bWVudCB0byBwcmV2ZW50IGFnYWluc3QgYnJ1dGUgZm9yY2UgYXR0YWNrcyBhcHBseSB0byBhbGwg Y3JlZGVudGlhbHMsIHJlc291cmNlIG93bmVyIG9yIG90aGVyd2lzZT8gSW4gb3RoZXIgd29yZHMg aW4gc2VjdGlvbiAyLjQuMSB3ZSB0YWxrIGFib3V0IGhvdyBjbGllbnRzIHN1Ym1pdCB0aGVpciBu YW1lL3Bhc3N3b3JkLiBTaG91bGRu4oCZdCBlbmRwb2ludHMgYWNjZXB0aW5nIGNsaWVudCBuYW1l L3Bhc3N3b3JkcyBoYXZlIHRoZSBzYW1lIHByb3RlY3Rpb25zIGFnYWluc3QgYnJ1dGUgZm9yY2Ug YXR0YWNrP+KAnQ0KDQo0LjQuMy4gQWNjZXNzIFRva2VuIFJlc3BvbnNlOiBDb21tZW50IG9uIOKA nEEgcmVmcmVzaCB0b2tlbiBTSE9VTEQgTk9UIGJlIGluY2x1ZGVk4oCdOiDigJxXaHkgaXNu4oCZ dCB0aGlzIGEgTVVTVCBOT1Q/4oCdDQoNCjQuNS4gRXh0ZW5zaW9uczogQ29tbWVudCDigJxJc27i gJl0IHRoZSB0ZXh0IGluIHRoaXMgc2VjdGlvbiBhbmQgOC4zIHJlZHVuZGFudCB3aXRoIGVhY2gg b3RoZXI/IEl0IHNlZW1zIGxpa2Ugd2Ugc2hvdWxkIHRha2UgdGhlIHRleHQgZnJvbSBoZXJlIGFu ZCBtZXJnZSBpdCB3aXRoIHNlY3Rpb24gOC4zIHNvIGFsbCB0aGUgZXh0ZW5zaW9uIGluZm9ybWF0 aW9uIGlzIHJlY29yZGVkIGluIG9uZSBwbGFjZS4gIEl04oCZcyBqdXN0IHBsYWluIHRoYXQgYWxs IG90aGVyIGV4dGVuc2lvbiBwb2ludHMgYXJlIGluIHNlY3Rpb24gOCBidXQgdGhpcyBvbmUu4oCd DQoNCjUuMS4gU3VjY2Vzc2Z1bCBSZXNwb25zZTogQ29tbWVudCBvbiDigJxwYXJhbWV0ZXIgYXQg dGhlIGhpZ2hlc3Qgc3RydWN0dXJlIGxldmVs4oCdOiDigJxBcmUgdGhlcmUgYW55IGd1YXJhbnRl ZXMgYWJvdXQgdGhlIG9yZGVyIG9mIHRoZSBtZW1iZXJzIGluIHRoZSBKU09OIG9iamVjdD8gSWYg bm90IHdlIHNob3VsZCBzYXkgc28gZXhwbGljaXRseS7igJ0NCg0KNS4yLiBFcnJvciBSZXNwb25z ZTogQ29tbWVudCBvbiDigJxtdWx0aXBsZSBjbGllbnQgYXV0aGVudGljYXRpb25zIGluY2x1ZGVk 4oCdIGluIGludmFsaWRfY2xpZW50OiDigJxTaG91bGRu4oCZdCB0aGlzIGJlIGFuIGludmFsaWRf cmVxdWVzdD/igJ0NCg0KNS4yLiBFcnJvciBSZXNwb25zZTogQ29tbWVudCBvbiDigJxOdW1lcmlj YWwgdmFsdWVzIGFyZSBpbmNsdWRlZCBhcyBKU09OIG51bWJlcnPigJ06IOKAnFNhbWUgaXNzdWUg YXMgYmVmb3JlLCBkb2VzIG9yZGVyaW5nIG1hdHRlciBhbmQgaWYgbm90IHdlIG5lZWQgdG8gc2F5 IHRoYXQu4oCdDQoNCjguMS4gRGVmaW5pbmcgQWNjZXNzIFRva2VuIFR5cGVzOiBDaGFuZ2Ug4oCc b3IgdXNlIGEgdW5pcXVl4oCdIHRvIOKAnG9yIHVzaW5nIGEgdW5pcXVl4oCdLg0KDQo5LiAgTmF0 aXZlIEFwcGxpY2F0aW9uczogIENoYW5nZSDigJxhbiBzY2hlbWXigJ0gdG8g4oCcYSBzY2hlbWXi gJ0NCg0KOS4gIE5hdGl2ZSBBcHBsaWNhdGlvbnM6ICBDaGFuZ2Ug4oCcb2ZmZXIgYW4gaW1wcm92 ZWQgdXNhYmlsaXR54oCdIHRvIOKAnG9mZmVyIGltcHJvdmVkIHVzYWJpbGl0eeKAnQ0KDQo5LiAg TmF0aXZlIEFwcGxpY2F0aW9uczogIENoYW5nZSDigJxpbmFiaWxpdHkgdG8ga2VlcCBjcmVkZW50 aWFscyBjb25maWRlbnRpYWzigJ0gdG8g4oCcaW5hYmlsaXR5IHRvIGtlZXAgY2xpZW50IGNyZWRl bnRpYWxzIGNvbmZpZGVudGlhbOKAnS4NCg0KOS4gIE5hdGl2ZSBBcHBsaWNhdGlvbnM6ICBDaGFu Z2Ug4oCcV2hlbiB1c2luZyB0aGUgaW1wbGljaXQgZ3JhbnQgdHlwZSBmbG93IGEgcmVmcmVzaCB0 b2tlbiBpcyBub3QgcmV0dXJuZWTigJ0gdG8g4oCcV2hlbiB1c2luZyB0aGUgaW1wbGljaXQgZ3Jh bnQgdHlwZSBmbG93IGEgcmVmcmVzaCB0b2tlbiBpcyBub3QgcmV0dXJuZWQgc28gb25jZSB0aGUg YWNjZXNzIHRva2VuIGV4cGlyZXMgdGhlIGFwcGxpY2F0aW9uIHdpbGwgaGF2ZSB0byByZXBlYXQg dGhlIGF1dGhvcml6YXRpb24gcHJvY2Vzc+KAnS4NCg0KMTAuMi4gQ2xpZW50IEltcGVyc29uYXRp b246ICBDaGFuZ2Ug4oCca2VlcCBpcyBjbGllbnTigJ0gdG8g4oCca2VlcCBpdHMgY2xpZW504oCd Lg0KDQoxMC4yLiBDbGllbnQgSW1wZXJzb25hdGlvbjogIENoYW5nZSDigJxkdWUgdG8gdGhlIGNs aWVudCBuYXR1cmXigJ0gdG8g4oCcZHVlIHRvIHRoZSBjbGllbnTigJlzIG5hdHVyZeKAnS4NCg0K MTAuMi4gQ2xpZW50IEltcGVyc29uYXRpb246ICBDaGFuZ2Ug4oCcVVJJIHVzZWQgZm9yIHJlY2Vp dmluZyBhdXRob3JpemF0aW9u4oCdIHRvIOKAnFVSSSB1c2VkIGZvciByZWNlaXZpbmcgYXV0aG9y aXphdGlvbiByZXF1ZXN0c+KAnQ0KDQoxMC4yLiBDbGllbnQgSW1wZXJzb25hdGlvbjogIENoYW5n ZSDigJxlbmdhZ2UgdGhlIHJlc291cmNlIG93bmVy4oCdIHRvIOKAnGVuZ2FnaW5nIHRoZSByZXNv dXJjZSBvd25lcuKAnS4NCg0KMTAuMi4gQ2xpZW50IEltcGVyc29uYXRpb246ICBDaGFuZ2Ug4oCc YW5kIGF1dGhvcml6ZSB0aGUgcmVxdWVzdOKAnSB0byDigJxhbmQgYXV0aG9yaXplIG9yIHJlamVj dCB0aGUgcmVxdWVzdOKAnS4NCg0KMTAuMy4gQWNjZXNzIFRva2VuczogQ2hhbmdlIOKAnEFjY2Vz cyB0b2tlbiAoYXMgd2VsbCBhcyBhbnkgYWNjZXNzIHRva2VuIHR5cGUtc3BlY2lmaWMgYXR0cmli dXRlcynigJ0gdG8g4oCcQWNjZXNzIHRva2VucyAoYXMgd2VsbCBhcyBhbnkgYWNjZXNzIHRva2Vu IHR5cGUgc3BlY2lmaWMgYXR0cmlidXRlcynigJ0uDQoNCjEwLjMuIEFjY2VzcyBUb2tlbnM6IENo YW5nZSDigJxndWVzc2VkIHRvIHByb2R1Y2XigJ0gdG8g4oCcZ3Vlc3NlZCBzbyBhcyB0byBwcmV2 ZW50IHVuYXV0aG9yaXplZCBwYXJ0aWVzIGZyb20gcHJvZHVjaW5n4oCdLg0KDQoxMC40LiBSZWZy ZXNoIFRva2VuczogQ29tbWVudCDigJxBcyBtZW50aW9uZWQgcHJldmlvdXNseSB3ZSByZWFsbHkg c2hvdWxkIGV4cGxhaW4gd2h5IHdlIGludHJvZHVjZWQgcmVmcmVzaCB0b2tlbnMuIFdpdGhvdXQg dW5kZXJzdGFuZGluZyB0aGUgaW50ZW50IG9mIHRoZSBtZWNoYW5pc20gaXTigJlzIHVubGlrZWx5 IGltcGxlbWVudGVycyB3aWxsIHVzZSB0aGVtIGFwcHJvcHJpYXRlbHku4oCdDQoNCjEwLjQuIFJl ZnJlc2ggVG9rZW5zOiAgQ2hhbmdlIOKAnHN0b3JhZ2UsIGFuZCBzaGFyZWQgb25seSBhbW9uZ+KA nSB0byDigJxzdG9yYWdlLCBhbmQgYXJlIHRvIGJlIHNoYXJlZCBvbmx5IGFtb25n4oCdLg0KDQox MC40LiBSZWZyZXNoIFRva2VuczogIENoYW5nZSDigJxyZWZyZXNoIHRva2VucyByb3RhdGlvbuKA nSB0byDigJxyZWZyZXNoIHRva2VuIHJvdGF0aW9u4oCdLg0KDQoxMC40LiBSZWZyZXNoIFRva2Vu czogIENoYW5nZSDigJxndWVzc2VkIHRvIHByb2R1Y2XigJ0gdG8g4oCcZ3Vlc3NlZCBzbyBhcyB0 byBwcmV2ZW50IHVuYXV0aG9yaXplZCBwYXJ0aWVzIGZyb20gcHJvZHVjaW5n4oCdLg0KDQoxMC42 LiBBdXRob3JpemF0aW9uIENvZGUgTGVha2FnZTogQ29tbWVudCDigJxJIGZhbmN5IG15c2VsZiBh cyBiZWluZyByZWFzb25hYmx5IGludGVsbGlnZW50IGFuZCBJ4oCZbSB1bmNsZWFyIHdoYXQgYXR0 YWNrIGlzIGFjdHVhbGx5IGJlaW5nIGRlc2NyaWJlZCBoZXJlLuKAnQ0KDQoxMC42LiBBdXRob3Jp emF0aW9uIENvZGUgTGVha2FnZTogQ29tbWVudCBvbiDigJxUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgU0hPVUxEIHJlcXVpcmUgdGhlIGNsaWVudCB0byByZWdpc3RlciB0aGVpciByZWRpcmVjdGlv biBVUknigJ06IOKAnFdoeSBpcyB0aGlzIGEgc2hvdWxkP+KAnQ0KDQoxMC43LiBSZXNvdXJjZSBP d25lciBQYXNzd29yZCBDcmVkZW50aWFsczogQ29tbWVudCBvbiDigJxwYXNzd29yZCBhbnRpLXBh dHRlcm7igJ06IOKAnElzIGl0IGZhaXIgdG8gZXhwZWN0IHRoYXQgdGhlIHJlYWRlciBrbm93cyB3 aGF0IHRoZSBwYXNzd29yZCBhbnRpLXBhdHRlcm4gaXM/IFNob3VsZG7igJl0IHNvbWUgcmVmZXJl bmNlIHRvIGEgZGVmaW5pdGlvbiBvZiB0aGlzIHBhdHRlcm4gYmUgcmVxdWlyZWQ/4oCdDQoNCjEw LjcuIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRpYWxzOiBDb21tZW50IG9uIOKAnFRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVzdHJpY3QgdGhlIHNjb3BlIGFuZCBsaWZl dGltZSBvZiBhY2Nlc3MgdG9rZW5zIGlzc3VlZCB2aWEgdGhpcyBncmFudCB0eXBl4oCdOiDigJxS ZXN0cmljdCBpbiB3aGF0IHdheXM/IEJhc2VkIG9uIHdoYXQgY3JpdGVyaWE/IFRoaXMgc3RhdGVt ZW50IGlzIHRoZSBlcXVpdmFsZW50IG9mIHNheWluZyDigJxkb27igJl0IGRvIGJhZCBzdHVmZuKA nS4gUGVyaGFwcyB0cnVlIGJ1dCBub3QgdGVycmlibHkgdXNlZnVsLuKAnQ0KDQoxMC4xMi4gQ3Jv c3MtU2l0ZSBSZXF1ZXN0IEZvcmdlcnk6IENvbW1lbnQgb24gZmlyc3QgcGFyYWdyYXBoOiDigJxJ IGNoYWxsZW5nZSBhbnkgcmVhc29uYWJseSBpbnRlbGxpZ2VudCBwZXJzb24gd2hvIGRvZXMgbm90 IGFscmVhZHkga25vdyB3aGF0IGEgQ1NSRiBpcyB0byByZWFkIHRoaXMgcGFyYWdyYXBoIGFuZCBj b21lIGF3YXkgYW55IGNsZWFyZXIgYXMgdG8gd2hhdCBpcyBiZWluZyBkaXNjdXNzZWQuIEF0IGEg bWluaW11bSBpc27igJl0IHNvbWUgcmVmZXJlbmNlIHRvIGEgY29tcGxldGUgZGVmaW5pdGlvbiBv ZiBDU1JGIG5lZWRlZCBpZiB0aGVyZSBpcyB0byBiZSBhbnkgaG9wZSBvZiB1c2VyIGNvbXBsaWFu Y2U/4oCdDQoNCjEwLjEyLiBDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeTogQ29tbWVudCBvbiDi gJxUaGUgInN0YXRlIiByZXF1ZXN0IHBhcmFtZXRlciBNVVNUIGNvbnRhaW4gYSBub24tZ3Vlc3Nh YmxlIHZhbHVl4oCdOiDigJxBY3R1YWxseSBhIG5vbi1ndWVzc2FibGUgdmFsdWUgd29u4oCZdCBz dG9wIHRoZSBhdHRhY2sgZGlzY3Vzc2VkIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGggb24gaXRz IG93bi4gV2hhdOKAmXMgYWxzbyBuZWVkZWQgaXMgYSB3YXkgdG8gdW5pcXVlbHkgKGFuZCB1bmJy ZWFrYWJseSkgYXNzb2NpYXRlIHRoZSBzdGF0ZSB3aXRoIGEgcGFydGljdWxhciB1c2VyIHNvIHRo YXQgaWYgYW4gYXV0aG9yaXphdGlvbiBjb2RlIHN3YXAgb2NjdXJzIGl0IGNhbiBiZSByZWxpYWJs eSBkZXRlY3RlZC7igJ0NCg0KMTAuMTMuIENsaWNramFja2luZzogQ29tbWVudCBvbiDigJx4LWZy YW1lLW9wdGlvbnPigJ06IOKAnFRoZSByZWNvbW1lbmRhdGlvbiBzZWVtcyBjb25mdXNlZC4gSXMg aXQgby5rLiB0byBqdXN0IHJlbHkgb24geC1mcmFtZS1vcHRpb25zIG9yIE1VU1Qgb3RoZXIgYWN0 aW9ucyBiZSB0YWtlbj/igJ0NCg0KMTEuMS4gIFRoZSBPQXV0aCBBY2Nlc3MgVG9rZW4gVHlwZSBS ZWdpc3RyeTogQ2hhbmdlIOKAnHRva2UgdHlwZeKAnSB0byDigJx0b2tlbiB0eXBl4oCdLg0KDQox MS4xLjEuICBSZWdpc3RyYXRpb24gVGVtcGxhdGU6IENoYW5nZSDigJxwcm90ZWN0ZWQgcmVzb3Vy Y2VzIHJlcXVlc3RzIHVzaW5nIGFjY2VzcyB0b2tlbuKAnSB0byDigJxwcm90ZWN0ZWQgcmVzb3Vy Y2UgcmVxdWVzdHMgdXNpbmcgYWNjZXNzIHRva2Vuc+KAnS4NCg0KMTEuMS4xLiAgUmVnaXN0cmF0 aW9uIFRlbXBsYXRlOiAgQ2hhbmdlIOKAnFJlZmVyZW5jZSB0byBkb2N1bWVudOKAnSB0byDigJxS ZWZlcmVuY2UgdG8gdGhlIGRvY3VtZW504oCdLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQo= --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89D74SN2PRD0302MB137_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+WWVwLCBJIGJlbGlldmUgdGhleSBhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBFcmFuIEhhbW1l ci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g VGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAxMjoxNSBQTTxicj4NCjxiPlRvOjwvYj4gQW50aG9u eSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzOyBvYXV0aEBpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBQYXJ0aWFsIHNldCBvZiBsYXN0IGNhbGwg Y29tbWVudHMgb24gT0F1dGggZHJhZnQgMjAgZnJvbSBZYXJvbiBHb2xhbmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5KdXN0IHdhbnQgdG8gbWFrZSBzdXJlIGl0IGlzIGNvdmVyZWQgYnkgdGhl IG5vcm1hbCBjb250cmlidXRpb24gcnVsZS4mbmJzcDs8YnI+DQo8YnI+DQpPbiBBdWcgMTEsIDIw MTEsIGF0IDEwOjU4LCAmcXVvdDtBbnRob255IE5hZGFsaW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SGUgaXMgb3V0IG9uIHZhY2F0aW9uIHdpdGggbm8gYWNjZXNzIGFuZCBoZSBsZWZ0IE1pa2Ugd2l0 aCBhIGJ1bmNoIG9mIGNvbW1lbnRzIHRvIHB1bGwgdG9nZXRoZXIgdG8NCiBzdWJtaXQgYW5kIHdl IGtuZXcgdGhhdCB5b3Ugd2FudGVkIHRoZXNlIGNvbW1lbnRzIHRvIGVuc3VyZSB0aGF0IHRoZSBz cGVjIGlzIHRoZSBiZXN0IGl0IGNhbiBiZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhy ZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3Jn PC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSI+DQpb bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddPC9hPiA8Yj5PbiBCZWhhbGYgT2YgPC9iPkVy YW4gSGFtbWVyLUxhaGF2PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDEwLCAy MDExIDU6MTkgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFBhcnRpYWwgc2V0IG9mIGxhc3QgY2FsbCBjb21t ZW50cyBvbiBPQXV0aCBkcmFmdCAyMCBmcm9tIFlhcm9uIEdvbGFuZDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+SXMgdGhlcmUgYSByZWFzb24gd2h5 IE1yIEdvbGFuZCBpc250IHNlbmRpbmcgaGlzIG93biBjb21tZW50cyBpbj88YnI+DQo8YnI+DQpP biBBdWcgMTAsIDIwMTEsIGF0IDE3OjM5LCAmcXVvdDtNaWtlIEpvbmVzJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS40LiBBdXRob3JpemF0aW9uIEdyYW50 OiBDaGFuZ2Ug4oCccmVzb3VyY2Ugb3duZXIgYXV0aG9yaXphdGlvbuKAnSB0byDigJxyZXNvdXJj ZSBvd25lcuKAmXMgYXV0aG9yaXphdGlvbuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjEuNC4xLiBBdXRob3JpemF0aW9uIENvZGU6Jm5ic3A7IENvbW1lbnQ6IOKAnEl0IHNlZW1zIG9k ZCB0aGF0IHdlIGNhbiBkaXNjdXNzIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgd2l0aG91dCBhbHNv IGRpc2N1c3NpbmcgdGhlIHNlY3VyaXR5IGlzc3VlcyBpdCByYWlzZXMgKGUuZy4gcGFzc2luZyBz ZWN1cmUgaW5mb3JtYXRpb24NCiB2aWEgYSBicm93c2VyKSBhbmQgdGh1cyBtb3RpdmF0aW5nIHRo ZSBpbnRyb2R1Y3Rpb24gb2YgdGhlIHJlZnJlc2ggdG9rZW4uIEkgd291bGQgZXhwZWN0IHRoaXMg dG8gYmUgcmVmZXJyZWQgdG8gaGVyZS4mbmJzcDsgSGF2aW5nIHJlYWQgdGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHNlY3Rpb24gSSBjYW4gZmluZCBubyBjb2hlcmVudCBkaXNjdXNzaW9uIHRo ZXJlIGVpdGhlciBvZiB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGF1dGhvcml6YXRpb24N CiBjb2RlIGFuZCB0aGUgcmVmcmVzaCB0b2tlbiBhbmQgd2h5IG9uZSBtb3RpdmF0ZWQgdGhlIG90 aGVyLiBJIHRoaW5rIHRoaXMgaXMgc29tZXRoaW5nIGltcG9ydGFudCBmb3IgaW1wbGVtZW50ZXJz IHRvIHVuZGVyc3RhbmQu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLjQuMi4mbmJz cDsgSW1wbGljaXQ6Jm5ic3A7IENvbW1lbnQ6IOKAnEkgZmluZCB0aGlzIHNlY3Rpb24gY29uZnVz aW5nLiBJIHRoaW5rIGFuIGV4YW1wbGUgaXMgYWxsIGJ1dCBtYW5kYXRvcnkgaGVyZSBpZiB0aGUg cmVhZGVyIGlzIHRvIHVuZGVyc3RhbmQgd2hhdCBpcyBpbnRlbmRlZC4mbmJzcDsgRm9yIGV4YW1w bGUsIHdoZW4gSSBmaXJzdA0KIHJlYWQgdGhpcyBzZWN0aW9uIEkgdGhvdWdodCBpdCB3YXMgc29t ZSBraW5kIG9mIHNob3J0IGN1dCB1c2VkIGluIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQgYW5kIGF1 dGhvcml6YXRpb24gc2VydmVyIGhhZCBhIGNsb3NlIHJlbGF0aW9uc2hpcCBhbmQgY291bGQgc2hh cmUgaW5mb3JtYXRpb24gc3VjaCBhcyB0aGUgY2xpZW504oCZcyBpZGVudGl0eSBzbyBubyBhY2Nl c3MgY29kZSB3YXMgbmVlZGVkLiZuYnNwOyBObyB3aGVyZSBpbiBoZXJlIGlzIGFueSBoaW50DQog dGhhdCB0aGlzIGlzIGFib3V0IGJyb3dzZXIgYmFzZWQgY2xpZW50cyB3aG8gZG9u4oCZdCBoYXZl IHNlcnZlcnMgYW5kIHdobyBuZWVkIGEgd2F5IHRvIGdldCB0b2tlbnMuIFNlcmlvdXNseS4gVHJ5 IHRvIHJlYWQgdGhpcyBzZWN0aW9uIGFzIHNvbWVvbmUgd2hvIGtub3dzIG5vdGhpbmcgYWJvdXQg T0F1dGggYW5kIHRlbGwgbWUgdGhhdCB5b3UgZ2V0IHRoZSByaWdodCBpZGVhIGJhY2sgZnJvbSBp dC4gSXQgbmVlZHMgdG8gYmUgd3JpdHRlbiB0byBiZQ0KIGJvdGggZXhwbGljaXQgYXMgdG8gaXRz IGdvYWxzIGFuZCBjbGVhcmVyIGFzIHRvIGl0cyBtZWFucy7igJ08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjEuNC4yLiZuYnNwOyBJbXBsaWNpdDombmJzcDsgQ2hhbmdlIOKAnDxzcGFuIGxh bmc9IkVOIj5hdXRoZW50aWNhdGUgdGhlIGNsaWVudCBhbmQgdGhlPC9zcGFuPuKAnSB0byDigJw8 c3BhbiBsYW5nPSJFTiI+YXV0aGVudGljYXRlIHRoZSBjbGllbnQgZGlyZWN0bHkuIFRoZTwvc3Bh bj7igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLjQuMi4mbmJzcDsgSW1wbGljaXQ6 Jm5ic3A7IENoYW5nZSDigJx3ZWlnaHRlZOKAnSB0byDigJx3ZWlnaGVk4oCdLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+MS40LjMuJm5ic3A7IFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENy ZWRlbnRpYWxzOiBDb21tZW50IG9uIOKAnCh3aGVuIGNvbWJpbmVkIHdpdGggYSByZWZyZXNoIHRv a2VuKeKAnTog4oCcVGhpcyBpcyB0aGUgZmlyc3QgdGltZSB0aGF0IHJlZnJlc2ggdG9rZW5zIGFy ZSBtZW50aW9uZWQgaW4gdGhlIHNwZWMuIEFuZCB5ZXQgdGhlcmUNCiBpcyBubyBleHBsYW5hdGlv biBvZiB3aGF0IHRoZXkgYXJlLiBJIHN1c3BlY3QgdGhleSBzaG91bGQgYW55d2F5IGJlIGludHJv ZHVjZWQgaW4gc2VjdGlvbiAxLjQuMSAoYXMgcHJldmlvdXNseSBub3RlZCkgYW5kIHRoZW4gdGhl aXIgdXNlIGhlcmUgd2lsbCBtYWtlIHNlbnNlLiZuYnNwOyBJZiB0aGF0IGlzbuKAmXQgcG9zc2li bGUgdGhlbiBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYSBmb3J3YXJkIHJlZmVyZW5jZSB0byBz ZWN0aW9uIDEuNSBiZWxvdyBzbw0KIHRoZSByZWFkZXIgaGFzIHNvbWUgaWRlYSBvZiB3aGF04oCZ cyBnb2luZyBvbi7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuNC40LiZuYnNwOyBD bGllbnQgQ3JlZGVudGlhbHM6Jm5ic3A7IENvbW1lbnQgb24g4oCcKHRoZSBjbGllbnQgaXMgYWxz byB0aGUgcmVzb3VyY2Ugb3duZXIp4oCdOiDigJxJIHRoaW5rIHRoaXMgaXMgbWlzbGVhZGluZy4g SW1hZ2luZSBzb21ldGhpbmcgbGlrZSBPZmZpY2Ugd2hlcmUgYSBjbGllbnQgaGFzIGJlZW4gZ3Jh bnRlZCBhY2Nlc3MNCiB0byBhIHBhcnRpY3VsYXIgcmVzb3VyY2UgYnkgdGhlIHJlc291cmNlIG93 bmVyLiBUaGUgY2xpZW50IGNhbiB0aGVuIGFzayBmb3IgYW4gYWNjZXNzIHRva2VuIHRvIHRoZSBy ZXNvdXJjZSB1c2luZyB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGFuZCBubyBhY2Nlc3MgY29kZSBv ciByZWZyZXNoIHRva2VuLiBKdXN0IGhhdmluZyB0aGUgYWRkcmVzcyBvZiB0aGUgaW50ZW5kZWQg cmVzb3VyY2UgKHByb2JhYmx5IHByb3ZpZGVkIHZpYSBTQ09QRSkgYWxvbmcNCiB3aXRoIHRoZSBj bGllbnQgY3JlZGVudGlhbHMgaXMgbW9yZSB0aGFuIGVub3VnaCB0byBkZWNpZGUgaWYgYW4gYWNj ZXNzIHRva2VuIHNob3VsZCBiZSBpc3N1ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5N eSBwb2ludCBpcyB0aGF0IHRoZSBjbGllbnQgY3JlZGVudGlhbHMgc2NlbmFyaW8gaXMgZnVsbHkg YXBwbGljYWJsZSB0byBjYXNlcyB3aGVyZSB0aGUgY2xpZW50IGlzIG5vdCB0aGUgcmVzb3VyY2Ug b3duZXIgYnV0IGluIHdoaWNoIHRoZSByZXNvdXJjZSBVUkkgcHJvdmlkZXMgYWxsIHRoZSBjb250 ZXh0IG5lZWRlZA0KIHRvIGRldGVybWluZSBpZiB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRv IGdldCBhbiBhY2Nlc3MgdG9rZW4uIEkgdGhpbmsgdGhlIGN1cnJlbnQgdGV4dCB3b3VsZCBpbXBs eSBvdGhlcndpc2UuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIEkgd291bGQgcHJv cG9zZSBjaGFuZ2luZyB0aGUgc2VudGVuY2UgdG8g4oCcQ2xpZW50IGNyZWRlbnRpYWxzIGFyZSB1 c2VkIGFzIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgd2hlbiB0aGUgY2xpZW50IGlzIGFjdGluZyBv biBpdHMgb3duIGJlaGFsZiAodGhlIGNsaWVudCBpcyBhbHNvIHRoZSByZXNvdXJjZSBvd25lcikN CiBvciB3aGVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBoYXMgZW5vdWdoIGNvbnRleHQgdG8g ZGV0ZXJtaW5lIGZyb20gdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0IGlmIHRoZSBjbGllbnQgaGFz IGF1dGhvcml6YXRpb24gdG8gYWNjZXNzIHRoZSByZXF1ZXN0ZWQgcmVzb3VyY2Uu4oCd4oCdPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLjQuNS4gRXh0ZW5zaW9uczogQ29tbWVudDog4oCc SSB3b3VsZCBjaGFuZ2UgdGhpcyBzZW50ZW5jZSB0byByZWFkIOKAnEFkZGl0aW9uYWwgZ3JhbnQg dHlwZXMgbWF5IGJlIGRlZmluZWQgdG8gc3VwcG9ydCBuZXcgYXBwcm9hY2hlcyB0byBhdXRoZW50 aWNhdGlvbi9hdXRob3JpemF0aW9uIGFzIHdlbGwgYXMgdG8NCiBwcm92aWRlIGEgYnJpZGdlIGJl dHdlZW4gT0F1dGggYW5kIG90aGVyIHByb3RvY29scy7igJ3igJ08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjEuNS4gUmVmcmVzaCBUb2tlbjogQ29tbWVudCBvbiDigJxSZWZyZXNoIHRva2Vu cyBhcmUgY3JlZGVudGlhbHMgdXNlZCB0byBvYnRhaW4gYWNjZXNzIHRva2Vucy7igJ06IOKAnFRo aXMgc2VudGVuY2UgcHJlc3VtZXMgdGhhdCByZWZyZXNoIHRva2VucyBhcmUgc2VsZi1jb250YWlu ZWQgY3JlZGVudGlhbHMuIEluIG90aGVyDQogd29yZHMgdGhhdCBvbmUgY2FuIGdldCBhbiBhY2Nl c3MgdG9rZW4ganVzdCB1c2luZyBhIHJlZnJlc2ggdG9rZW4gYW5kIG5vdGhpbmcgZWxzZS4gVGhp cyBwcmVzdW1wdGlvbiBpcyByZWJ1dHRlZCBsYXRlciBpbiB0aGUgZG9jdW1lbnQgYnV0IEkgdGhp bmsgaXTigJlzIGNvbmZ1c2luZyB0byBpbXBseSBvbmUgdGhpbmcgaGVyZSBhbmQgc3RhdGUgb3Ro ZXJ3aXNlIGxhdGVyIG9uLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MS41LiBSZWZy ZXNoIFRva2VuOiBDaGFuZ2Ug4oCcPHNwYW4gbGFuZz0iRU4iPmEgcHJvdGVjdGVkIHJlc291cmNl IHJlcXVlc3RzPC9zcGFuPuKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+YSBwcm90ZWN0ZWQgcmVz b3VyY2UgcmVxdWVzdDwvc3Bhbj7igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLjUu IFJlZnJlc2ggVG9rZW46IENvbW1lbnQgb24g4oCcPHNwYW4gbGFuZz0iRU4iPihHKSZuYnNwOyBU aGUgY2xpZW50IHJlcXVlc3RzIGEgbmV3IGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3 aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcHJlc2VudGluZyB0aGUgcmVmcmVzaCB0 b2tlbi48L3NwYW4+4oCdOg0KIOKAnEh1beKApiBub3cgdGhlIHRleHQgc2VlbXMgdG8gY29udHJh ZGljdCBpdHNlbGYuIEFib3ZlIGl0IHNlZW1lZCBsaWtlIHlvdSBjb3VsZCB1c2UgdGhlIHJlZnJl c2ggdG9rZW4gYnkgaXRzZWxmIHRvIGdldCBhbiBhY2Nlc3MgdG9rZW4gYW5kIEkgaGFkIHRvIGFz ayBmb3IgbGFuZ3VhZ2UgdGhhdCBtYWRlIGl0IGNsZWFyIHRoYXQgeW91IGNvdWxkIHVzZSBhIHJl ZnJlc2ggdG9rZW4gd2l0aCBvdGhlciBjcmVkZW50aWFscy4mbmJzcDsgQnV0IHRoZSB0ZXh0IG9m DQogcG9pbnQgRyBub3cgaW1wbGllcyB0aGUgZXhhY3Qgb3Bwb3NpdGUsIHRoYXQgcmVmcmVzaCB0 b2tlbnMgY2FuIG9ubHkgYmUgdXNlZCB3aXRoIG90aGVyIGNyZWRlbnRpYWxzIGFuZCBub3QgYnkg dGhlbXNlbHZlcy4gKEV2ZW4gdGhvdWdoIHRoZSBwaWN0dXJlIGluIGZpZ3VyZSAyIGZvciBzdGVw IEcgaW1wbGllcyB0aGUgb3Bwb3NpdGUpLiBJIHdvdWxkIGVkaXQgdGhpcyBsYW5ndWFnZSB0byBz YXkg4oCcVGhlIGNsaWVudCByZXF1ZXN0cyBhIG5ldyBhY2Nlc3MNCiB0b2tlbi4gRGVwZW5kaW5n IG9uIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcuKAmXMgcG9saWNpZXMgdGhpcyByZXF1ZXN0IG1p Z2h0IGJlIG1hZGUgd2l0aCB0aGUgcmVmcmVzaCB0b2tlbiBieSBpdHNlbGYgb3Igd2l0aCBhIGNv bWJpbmF0aW9uIG9mIHRoZSByZWZyZXNoIHRva2VuIGFuZCBvdGhlciBjbGllbnQgY3JlZGVudGlh bHMu4oCd4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yLjEuIENsaWVudCBUeXBlczog Q29tbWVudCBvbiDigJx1c2VyLWFnZW50LWJhc2VkIGFwcGxpY2F0aW9u4oCdOiDigJxHaXZlIHRo ZSBwb29yIHJlYWRlciBhIGhpbnQgYW5kIG1lbnRpb24g4oCYYnJvd3NlcuKAmSBzb21ld2hlcmUg aW4gdGhlIHBhcmFncmFwaCBiZWxvdy4gRm9yIGV4YW1wbGUg4oCcQSB1c2VyLWFnZW50LWJhc2Vk DQogYXBwbGljYXRpb24gaXMgYSBwdWJsaWMgY2xpZW50IChzdWNoIGFzIGEgd2ViIGJyb3dzZXIp IGluIHdoaWNoIHRoZeKApi7igJ3igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuMS4g Q2xpZW50IFR5cGVzOiB3ZWIgYXBwbGljYXRpb246IENoYW5nZSDigJxhY2Nlc3MgdG9rZW5zIG9y IHJlZnJlc2ggdG9rZW5zLCBjYW4gcmVjZWl2ZSBhbiBhY2NlcHRhYmxlIGxldmVs4oCdIHRvIOKA nGFjY2VzcyB0b2tlbnMgb3IgcmVmcmVzaCB0b2tlbnMsIGNhbiwgaW4gc29tZSBjYXNlcywgcmVj ZWl2ZSBhbg0KIGFjY2VwdGFibGUgbGV2ZWzigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4yLjQuIENsaWVudCBBdXRoZW50aWNhdGlvbjombmJzcDsgQWRkIGEgcGVyaW9kIGFmdGVyIOKA nGV0Y+KAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuNC4xLiBDbGllbnQgUGFzc3dv cmQ6IENvbW1lbnQgb24g4oCcY2hhcnNldD1VVEYtOOKAnTog4oCcVGhlIHVzZSBvZiBVVEYtOCB3 aXRoIHgtd3d3LWZvcm0tdXJsZW5jb2RlZCBpcyBleHBsaWNpdGx5IGJhbm5lZCBieSBIVE1MIDQu MDEgc2VjdGlvbiAxNy4xMy4xLiBJZiB3ZSB3YW50IHRvIHVzZSBVVEYtOCB0aGVuDQogd2UgaGF2 ZSB0byB1c2UgbXVsdGlwYXJ0L2Zvcm0tZGF0YSwgYWxzbyBkZWZpbmVkIGJ5IEhUTUwgNC4wMSAo c2VjdGlvbiAxNy4xMy40KS4gQnV0IHNpbmNlIG5vYm9keSB3b3VsZCBhY3R1YWxseSB3YW50IHRv IGRvIHRoYXQgSSB3b3VsZCBzdWdnZXN0IHB1dHRpbmcgaW4gYSByZWZlcmVuY2UgdG8gc2VjdGlv biA0LjIgb2YgUkZDIDU1NTIgd2hpY2ggYWN0dWFsbHkgZGVmaW5lcyBob3cgdG8gdXNlIFVURi04 IHdpdGggeC13d3ctZm9ybS11cmxlbmNvZGVkDQogYW5kIHNwZWNpZnlpbmcgdGhhdCB0aGUgNTU1 MiBleHRlbnNpb24gTVVTVCBiZSBzdXBwb3J0ZWQgYnkgT0F1dGggcGFydGljaXBhbnRzLuKAnTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+My4xLiZuYnNwOyBBdXRob3JpemF0aW9uIEVuZHBv aW50OiBDb21tZW50IG9uIGZpcnN0IHNlbnRlbmNlOiZuYnNwOyDigJxUaGVyZSBpcyBhIHRoaXJk IG9wdGlvbiDigJMgbm9uZSBvZiB0aGUgYWJvdmUuICZuYnNwO0l0IHdvdWxkIGJlIGEgc2hhbWUg aWYgdGhlIHRleHQgb2YgdGhpcyBkcmFmdCBleHBsaWNpdGx5IHByb2hpYml0cyB0aGF0DQogcGF0 dGVybi7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuMS4mbmJzcDsgQXV0aG9yaXph dGlvbiBFbmRwb2ludDombmJzcDsgQ29tbWVudCBvbiDigJxbUkZDMzk4Nl0gc2VjdGlvbiAz4oCd OiDigJxTaG91bGRu4oCZdCB3ZSBwb2ludCBkaXJlY3RseSB0byBzZWN0aW9uIDMuNCB3aGljaCBl eGFjdGx5IGRlZmluZXMgdGhlIHF1ZXJ5IGNvbXBvbmVudD/igJ08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjMuMS4mbmJzcDsgQXV0aG9yaXphdGlvbiBFbmRwb2ludDombmJzcDsgQ29tbWVu dCBvbiDigJxNVVNUIGJlIHJldGFpbmVkIHdoZW4gYWRkaW5nIGFkZGl0aW9uYWwgcXVlcnk8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7IHBhcmFtZXRl cnPigJ06IOKAnEhJR0ggSU1QT1JUQU5DRSDigJMgVGhpcyBzcGVjaWZpY2F0aW9uIGlzIGluY29t cGxldGUuIFNlY3Rpb24gMy40IG9mIFJGQyAzOTg2IHNpbXBseSBhc3NlcnRzIHRoZSBleGlzdGVu Y2Ugb2YgYSBxdWVyeSBjb21wb25lbnQuIEl0IHNheXMgbm90aGluZyBhYm91dCB0aGUgc3ludGF4 DQogb2YgdGhhdCBjb21wb25lbnQuIFRoZSBzcGVjIGFzc3VtZXMgdGhhdCB0aGUgY29tcG9uZW50 IGlzIHVzaW5nIHgtd3d3LWZvcm0tdXJsZW5jb2RlZCBidXQgdGhhdCBpcyBub3QgaW4gYW55IHdh eSBtYW5kYXRlZCBieSBSRkMgMzk4Ni4gU28gdGhlcmUgaXMgYSBub3JtYXRpdmUgc2VudGVuY2Ug bWlzc2luZyBoZXJlIHdoaWNoIHN0YXRlcyB0aGF0IGFueSBxdWVyeSBwYXJhbWV0ZXIgb24gdGhl IGF1dGhvcml6YXRpb24gZW5kcG9pbnTigJlzIFVSSSBNVVNUDQogYmUgZGVmaW5lZCBhcyBzcGVj aWZpZWQgaW4geC13d3ctZm9ybS11cmxlbmNvZGVkLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+My4xLiZuYnNwOyBBdXRob3JpemF0aW9uIEVuZHBvaW50OiZuYnNwOyBDb21tZW50IG9u IOKAnFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaWdub3JlIHVucmVjb2duaXplZCBy ZXF1ZXN0IHBhcmFtZXRlcnMu4oCdOiDigJxBbHRob3VnaCB0aGF0IGlzIG5vcm1hbCBiZWhhdmlv ciBmb3IgYXBwbGljYXRpb24gcHJvdG9jb2xzDQogaXQgc2VlbXMgcmF0aGVyIGRhbmdlcm91cyBm b3IgYSBzZWN1cml0eSBwcm90b2NvbC4gQWZ0ZXIgYWxsIHdoYXQgaWYgdGhlIGNsaWVudCBwdXQg aW4gYSBwYXJhbWV0ZXIgc3BlY2lmeWluZyBzb21ldGhpbmcgc2VjdXJpdHkgcmVsYXRlZCBhYm91 dCB0aGUgcmVxdWVzdCB0aGlua2luZyB0aGF0IHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHdv dWxkIGhvbm9yIGl0IGFuZCB0aGVuIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHNpbGVudGx5 DQogaWdub3JlcyBpdD8mbmJzcDsgQWdhaW4sIHRoaXMgaXMgYSBzZWN1cml0eSBwcm90b2NvbCwg bm90IGEgZ2VuZXJpYyBhcHBsaWNhdGlvbiBwcm90b2NvbCwgaXQgc2VlbXMgdG8gYmUgdGhhdCB1 bnJlY29nbml6ZWQgcGFyYW1ldGVycyBzaG91bGQgY2F1c2UgYSBmYWlsdXJlLuKAnTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+My4xLjIuJm5ic3A7IFJlZGlyZWN0aW9uIEVuZHBvaW50OiBD b21tZW50IG9uIOKAnHdoZW4gaW5pdGlhdGluZyB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN04oCd OiDigJxJIHdvdWxkIHN1Z2dlc3QgbW9yZSBleHBsaWNpdCBsYW5ndWFnZSDigJxvciBhcyBzcGVj aWZpZWQgaW4gdGhlIHJlZGlyZWN0aW9uIFVSSSB2YWx1ZSBpbiB0aGUNCiBhdXRob3JpemF0aW9u IHJlcXVlc3Qu4oCd4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zLjEuMi4yLiBSZWdp c3RyYXRpb24gUmVxdWlyZW1lbnRzOiBDb21tZW50IG9uIGxhc3Qgd29yZCDigJxwYXRo4oCdOiDi gJxIdWg/IFNjaGVtZSwgYXV0aG9yaXphdGlvbiBhbmQgcGF0aCBpcyBhIGNvbXBsZXRlIFVSSSBt aW51cyBhIHF1ZXJ5IGNvbXBvbmVudC4mbmJzcDsgSXMgdGhlIGdvYWwgdG8gc3BlY2lmaWNhbGx5 IG1hbmRhdGUNCiB0aGF0IG9ubHkgdGhlIHF1ZXJ5IGNvbXBvbmVudCBjYW4gdmFyeSBhbmQgdGhl IHJlc3Qgb2YgdGhlIFVSSSBNVVNUIGJlIHN0YXRpYz8gSWYgc28gdGhhdCBzaG91bGQgYmUgc3Rh dGVkIGV4cGxpY2l0bHkgcmF0aGVyIHRoYW4gaW1wbGljaXRseSBhcyBpdCBpcyBub3cuJm5ic3A7 IEJ1dCBJIHRoaW5rLCBpZiB0aGF0IGlzIHRoZSBpbnRlbnQsIGl0IGdvZXMgdG9vIGZhci4gV2Ug c2hvdWxkIGFsc28gYWxsb3cgZm9yIGFkZGl0aW9uYWwgcGF0aCBzZWdtZW50cw0KIHRvIGJlIGFk ZGVkIHRvIHRoZSBVUkkgcGF0aCBiZXlvbmQgdGhlIHJlZ2lzdGVyZWQgcHJlZml4LiBBc3N1bWlu ZyB3ZSBjYW4gYWRkcmVzcyB0aGUgc2VjdXJpdHkgcHJvYmxlbSBpbiB0aGUgbmV4dCBjb21tZW50 LuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+My4xLjIuMy4gRHluYW1pYyBDb25maWd1 cmF0aW9uOiBDb21tZW50IG9uIOKAnHNlY3Rpb24gNuKAnTombmJzcDsg4oCcVGhlIHJlZmVyZW5j ZSB0byBzZWN0aW9uIDYgaXMgaW5jb21wbGV0ZS4gU2VjdGlvbiA2IGRlZmluZXMgbm8gbGVzcyB0 aGFuIDYgZGlmZmVyZW50IGF4aXPigJlzIG9uIHdoaWNoIFVSSSBjb21wYXJpc29ucyBjYW4NCiB2 YXJ5LiBGdXJ0aGVybW9yZSBhcyByZWNlbnRseSBkb2N1bWVudGVkIGluIGRyYWZ0LXRoYWxlci1p YWItaWRlbnRpZmllci1jb21wYXJpc29uLTAwLnR4dCBpdCBpcyB0cml2aWFsbHkgZWFzeSB0byBz Y3JldyB1cCBVUkkgY29tcGFyaXNvbnMgYW5kIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgYXJl IHByZXR0eSBkaXJlLiBQZXJzb25hbGx5IEkgdGhpbmsgdGhhdCB0aGUgb25seSBzYW5lIGFwcHJv YWNoIGdpdmVuIHRoZSBpc3N1ZXMgaW4gdGhlDQogcHJldmlvdXMgbGluayBpcyB0byBhZG9wdCBz ZWN0aW9uIDYuMi4xIG9mIFJGQyAzOTg2LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBh bSBhIGJpdCBzY2FyZWQgb2YgaG93IHRvIGhhbmRsZSBwYXJ0aWFsIG1hdGNoZXMuIEl04oCZcyB0 ZW1wdGluZyB0byBhcmd1ZSB0aGF0IHNvIGxvbmcgYXMgdGhlIHNjaGVtYSBoYXMgYW4gYXV0aG9y aXR5IGFuZCBhdCBsZWFzdCBvbmUgcGF0aCBzZWdtZW50IHRoZW4gd2UgY2FuIGp1c3QgdXNlIGEg cGFydGlhbA0KIHN0cmluZyBtYXRjaCBidXQgYm95IG9oIGJveSBkbyBJIHNlZSBwZW9wbGUgc2Ny ZXdpbmcgdGhhdCBvbmUgdXAgcm95YWxseS4gVGhpcyBpcyBzY2FyeSBlbm91Z2ggdGhhdCBJIHRo aW5rIEkgY2FuIGJlIGFyZ3VlZCBpbnRvIHNheWluZyB0aGF0IHBhcnRpYWwgcHJlLXJlZ2lzdGVy ZWQgVVJJcyBNVVNUIG9ubHkgZGlmZmVyIGJ5IHRoZSBxdWVyeSBjb21wb25lbnQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JbiBhbnkgY2FzZSB0aGlzIGlzc3VlcyBuZWVkcyB0byBiZSBl eHBsaWNpdGx5IGNhbGxlZCBvdXQgZm9yIGFsbCBVUkkgY29tcGFyaXNvbnMgcmVxdWlyZWQgYnkg dGhlIHNwZWMgYW5kIG5vcm1hdGl2ZWx5IGRlZmluZWQuIE90aGVyd2lzZSB3ZSB3aWxsIGVuZCB1 cCB3aXRoIGFsbCB0aGUgc2VjdXJpdHkgaXNzdWVzDQogaW4gRGF2ZeKAmXMgSUQu4oCdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4zLjEuMi40LiZuYnNwOyBJbnZhbGlkIEVuZHBvaW50OiBD b21tZW50IG9uIOKAnG9wZW4gcmVkaXJlY3RvcuKAnTog4oCcSG93IG1hbnkgcGVvcGxlIGV2ZW4g a25vdyB3aGF0IHRoZSBoZWNrIGFuIG9wZW4gcmVkaXJlY3RvciBpcz8gSSB0aGluayB3ZSBuZWVk IGEgc2VjdGlvbiBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCiBzZWN0aW9uIHRoYXQg ZGVmaW5lcyB3aGF0IGFuIG9wZW4gcmVkaXJlY3RvciBpcyBhbmQgd2h5IGl04oCZcyBiYWQuIEFs dGVybmF0aXZlbHkgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGEgY29tcGxldGUgZGVmaW5pdGlv biBzb21ld2hlcmUgZWxzZSBpcyBhbHNvIGZpbmUu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4zLjIuMS4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiBDaGFuZ2Ug4oCcUmVjb3ZlcnnigJ0g dG8g4oCcUmVjb3ZlcmluZ+KAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuMi4xLiBD bGllbnQgQXV0aGVudGljYXRpb246IENoYW5nZSDigJxjcmVkZW50aWFscywgYnkgcHJldmVudGlu ZyBhbiBhdHRhY2tlciBmcm9tIGFidXNpbmfigJ0gdG8g4oCcY3JlZGVudGlhbHMuIFRoaXMgcHJl dmVudHMgYW4gYXR0YWNrZXIgZnJvbSBhYnVzaW5n4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4zLjIuMS4gQ2xpZW50IEF1dGhlbnRpY2F0aW9uOiBDaGFuZ2Ug4oCccGVyaW9kaWMgY3Jl ZGVudGlhbHMgcm90YXRpb27igJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPnBlcmlvZGljIGNyZWRl bnRpYWwgcm90YXRpb248L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+My4y LjEuIENsaWVudCBBdXRoZW50aWNhdGlvbjogQ29tbWVudCBvbiDigJx3aGlsZSByb3RhdGlvbiBv ZiBhIHNpbmdsZSBzZXQgb2YgY2xpZW50IGNyZWRlbnRpYWxzIGlzIHNpZ25pZmljYW50bHkgZWFz aWVy4oCdOiDigJxUaGUgc3BlYyBjYWxscyBvdXQgcm90YXRpb24gb2YgY3JlZGVudGlhbHMgYXMg YmVpbmcgY3J1Y2lhbA0KIGJ1dCB0aGVuIGRvZXNu4oCZdCBkZWZpbmUgaG93IHRoaXMgaXMgdG8g YmUgZG9uZT8gVGhhdCBzZWVtcyBraW5kIG9mIG9kZC4gU2hvdWxkbuKAmXQgd2UgZGVmaW5lIGFu IGVuZHBvaW50IHdoZXJlIG9uZSBjYW4gc3VibWl0IG9uZeKAmXMgb2xkIGJ1dCB1bmV4cGlyZWQg Y3JlZGVudGlhbHMgZm9yIG5ldyBvbmVzPyBUaGlzIHN0aWxsIGxlYXZlcyB0aGUgZWRnZSBjYXNl IG9mIHdoYXQgdG8gZG8gaWYgdGhlIG9sZCBjcmVkZW50aWFscyBoYXZlIGV4cGlyZWQNCiBhbmQg bmV3IG9uZXMgaGF2ZW7igJl0IGJlZW4gaXNzdWVkIGJ1dCB0aGF0IGlzIHVuYXZvaWRhYmxlIGFu ZCBpbiB0aGF0IGNhc2Ugd2UgY2FuIHJlcXVpcmUgb3V0IG9mIHNjb3BlIGFjdGlvbi7igJ08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuMS4gQXV0aG9yaXphdGlvbiBDb2RlOiBDb21tZW50 IG9uIGZpcnN0IOKAnF7igJ06IOKAnFNob3VsZG7igJl0IHRoaXMgYmUgYSB2IGNoYXJhY3RlciBh bmQgbm90IGEgXj8gVGhpcyB3b3VsZCBtYWtlIGl0IGNvbnNpc3RlbnQgd2l0aCBBIHdoaWNoIGFs c28gY3Jvc3NlcyB0d28gYm94ZXMgYW5kIHBvaW50cyBpbiB0aGUNCiBzYW1lIGRpcmVjdGlvbi7i gJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuMS4gQXV0aG9yaXphdGlvbiBDb2RlOiBD aGFuZ2Ug4oCcSWYgdmFsaWQsIHJlc3BvbmRzIGJhY2sgd2l0aCBhbiBhY2Nlc3MgdG9rZW7igJ0g dG8g4oCcSWYgdGhlIHJlcXVlc3QgaXMgdmFsaWQsIHRoZW4gdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIHdpbGwgcmVzcG9uZHMgYmFjayB3aXRoIGFuIGFjY2VzcyB0b2tlbg0KIGFuZCBvcHRpb25h bGx5IGEgcmVmcmVzaCB0b2tlbuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuMS4y LiZuYnNwOyBBdXRob3JpemF0aW9uIFJlc3BvbnNlOiBDb21tZW50IOKAnFRoZSBsYW5ndWFnZSBh cm91bmQgc2NvcGVzIGluIHRoZSBkb2N1bWVudCBpcyByZWFsbHkgZnJ1c3RyYXRpbmcuIE9uZSBv bmx5IGZpbmRzIG91dCBtdWNoIGxhdGVyIGluIHRoZSBkb2N1bWVudCB0aGF0IGl0IGlzIHBlcmZl Y3RseSBhbGxvd2FibGUNCiBmb3IgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gbW9yZSBvciBs ZXNzIGlnbm9yZSB3aGF0IHNjb3BlcyBhcmUgc3VibWl0dGVkIGFuZCBpbnN0ZWFkIHRvIGp1c3Qg cmV0dXJuIHdoYXRldmVyIHRoZSBoZWxsIHRoZXkgd2FudC4gVGhpcyBpcyBhIGZpbmUgZGVzaWdu IGNob2ljZSBidXQgaXQgc2VlbXMgbGlrZSB0aGUgc29ydCBvZiB0aGluZyB0aGF0IHNob3VsZCBi ZSBmb3JjZWZ1bGx5IHJlcGVhdGVkIGFueXdoZXJlIGluIHRoZSBzcGVjIHRoYXQNCiB3ZSBhbGxv dyBwZW9wbGUgdG8gc3VibWl0IHNjb3BlcyBzbyBub2JvZHkgZm9yZ2V0cy7igJ08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjQuMS4yLiZuYnNwOyBBdXRob3JpemF0aW9uIFJlc3BvbnNlOiBD b21tZW50IG9uIOKAnHN0YXRl4oCdOiDigJxEb27igJl0IHdlIGhhdmUgdG8gcHJvdmlkZSBzb21l IGd1aWRhbmNlIG9uIGhvdyBsYXJnZSB0aGUgc3RhdGUgdmFsdWUgY2FuIHNhZmVseSBiZT8gT3Ro ZXJ3aXNlIHdlIGFyZSBhc2tpbmcgY2xpZW50cyB0byByZXdyaXRlDQogdGhlaXIgc3RhdGUgbWVj aGFuaXNtcyBldmVyeSB0aW1lIHRoZXkgdGhyb3cgaW4gc3VwcG9ydCBmb3IgYSBuZXcgcHJvdGVj dGVkIHJlc291cmNlIHNlcnZlci4gV2UgaGF2ZSB0byBzZXQgZXhwZWN0YXRpb25zIGFjcm9zcyB0 aGUgaW5kdXN0cnkgaWYgd2UgYXJlIHRvIGhvcGUgZm9yIGFjdHVhbCBpbnRlcm9wZXJhYmlsaXR5 LuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NC4xLjIuMS4gRXJyb3IgUmVzcG9uc2U6 IENvbW1lbnQgb24g4oCcVVRGLTggZW5jb2RlZCB0ZXh04oCdOiDigJxJIHRoaW5rIGp1c3Qgc2F5 aW5nIFVURi04IGVuY29kZWQgdGV4dCBjYW4gYmUgbWlzbGVhZGluZy4gSXTigJlzIG5vdCBsZWdh bCB0byBwdXQgVVRGLTggY2hhcmFjdGVycyBpbnRvIGEgeC13d3ctZm9ybS11cmxlbmNvZGVkDQog dXNlZCBpbiBhIEdFVCAoYXMgZGVmaW5lZCBieSBzZWN0aW9uIDE3LjEzLjEgb2YgSFRNTCA0LjAx KS4gU28gd2hhdCB5b3UgaGF2ZSB0byBkbyBpcyB0YWtlIHRoZSBVVEYtOCBTdHJpbmcgYW5kIHRo ZW4gVVJMIGVuY29kZSBpdC4gV2hpY2ggaXMgZmluZSBidXQgd2Ugc2hvdWxkIGNhbGwgdGhpcyBv dXQuJm5ic3A7IE5vdGUgdGhhdCB0aGlzIGlzIGEgc2VwYXJhdGUgaXNzdWUgdGhhbiBVVEYtOCBz dXBwb3J0IGZvciB4LXd3dy1mb3JtLXVybGVuY29kZWQuDQogVGhhdCBpc3N1ZSBvbmx5IGFwcGxp ZXMgd2hlbiB0aGUgZm9ybSBpcyBpbiB0aGUgcmVxdWVzdCBib2R5LiBJbiB0aGlzIHNjZW5hcmlv IHRoZSBmb3JtIGlzIGluIGEgVVJMLiBUaGVyZSBpcyBubyBxdWVzdGlvbiB0aGF0IFVSTHMgaW4g SFRUUCByZXF1ZXN0IGxpc3RzIGRvbuKAmXQgc3VwcG9ydCBVVEYtOC7igJ08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjQuMS4zLiBBY2Nlc3MgVG9rZW4gUmVxdWVzdDogQ2hhbmdlIOKAnDxz cGFuIGxhbmc9IkVOIj5Gb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5n IEhUVFAgdXNpbmc8L3NwYW4+4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5Gb3IgZXhhbXBsZSwg aWYgdGhlIGNsaWVudCBtYWtlcyB0aGUgZm9sbG93aW5nDQogSFRUUCByZXF1ZXN0IHVzaW5nPC9z cGFuPuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NC4xLjMuIEFjY2VzcyBUb2tlbiBS ZXF1ZXN0OiBDb21tZW50IG9uIOKAnHRoYXQgdGhlaXIgdmFsdWVzIGFyZSBpZGVudGljYWzigJ06 IOKAnFRoaXMgdmVyYmlhZ2UgaXNu4oCZdCBtdWNoIHVzZSwgZm9yIGV4YW1wbGUsIGlmIHRoZSBj bGllbnQgY2FuIGFsd2F5cyBzZW5kIHRoZSBzYW1lIHJlZGlyZWN0X3VyaS4gU28sIGp1c3QNCiB0 byBiZSBjbGVhciwgdGhpcyB0ZXh0IGhlcmUgZG9lc27igJl0IGluIGFueXdheSBjaGFuZ2UgbXkg cHJldmlvdXMgcmVjb21tZW5kYXRpb24gcmVnYXJkaW5nIHRoZSBhdHRhY2sgcHJldmlvdXNseSBk ZXNjcmliZWQu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40LjEuNC4gQWNjZXNzIFRv a2VuIFJlc3BvbnNlOiBDb21tZW50IG9uIOKAnCZxdW90O3Rva2VuX3R5cGUmcXVvdDs6JnF1b3Q7 ZXhhbXBsZSZxdW90O+KAnTog4oCcSnVzdCB0byBwcmV2ZW50IGFueSBjb25mdXNpb24gaXQgd291 bGQgYmUgZ29vZCB0byBhY3R1YWxseSBkZWZpbmUgdGhlIHRva2VuX3R5cGUg4oCcZXhhbXBsZeKA nSBpbiB0aGlzIGRvY3VtZW50IChQcm9iYWJseQ0KIGluIHNlY3Rpb24gNy4xIGFuZCBsYXRlciBp biB0aGUgSUFOQSBzZWN0aW9uKSBhbmQgc3BlY2lmeSB0aGF0IGl0IGlzIHJlc2VydmVkIGZvciB1 c2UgaW4gZXhhbXBsZXMgd2hlcmUgb25lIGRvZXMgbm90IHdpc2ggdG8gYmUgbW9yZSBzcGVjaWZp Yy7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuMi4mbmJzcDsgSW1wbGljaXQgR3Jh bnQ6IENvbW1lbnQg4oCcSSBoYXZlIHJ1biBpbnRvIG11bHRpcGxlIHBlb3BsZSAoaW5jbHVkaW5n IG15c2VsZikgd2hvIGhhdmUgcmVhZCB0aGUgT0F1dGggc3BlYyBhbmQgY2FtZSBhd2F5IGNvbXBs ZXRlbHkgY29uZnVzZWQgYWJvdXQgd2hlbiB0aGUgaGVjayBvbmUgaXMgc3VwcG9zZWQNCiB0byB1 c2UgdGhlIGltcGxpY2l0IGdyYW50IGZsb3cgZm9yLiBJdOKAmXMgbm90IGltbWVkaWF0ZWx5IG9i dmlvdXMgdGhhdCBpdOKAmXMgYSB3YXkgdG8gc3VwcG9ydCBzdGFuZGFsb25lIGJyb3dzZXIgYmFz ZWQgY2xpZW50cy4gQ2FuIHdlIHB1dCBpbiBhbiBleGFtcGxlIG9yIHNvbWV0aGluZyB0byBtYWtl IGl0IG1vcmUgb2J2aW91cyB3aHkgaXTigJlzIGhlcmU/4oCdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj40LjIuMS4gQXV0aG9yaXphdGlvbiBSZXF1ZXN0OiBDb21tZW50IG9uIHJlZGlyZWN0 X3VyaTombmJzcDsg4oCcR2l2ZW4gdGhhdCB0aGUgb25seSB3YXkgdG8gaWRlbnRpZnkgdGhlIGNs aWVudCBpbiB0aGUgaW1wbGljaXQgZ3JhbnQgZmxvdyBpcyB2aWEgdGhlIHJlZGlyZWN0X3VyaSwg aG93IGNhbiBpdCBiZSBvcHRpb25hbD/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQu My4gUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHM6IENoYW5nZSDigJxlbmFibGlu ZyB0aGUgZ3JhbnQgdHlwZSwgYW5kIG9ubHkgd2hlbiBvdGhlciBmbG93c+KAnSB0byDigJw8c3Bh biBsYW5nPSJFTiI+ZW5hYmxpbmcgdGhlIGdyYW50IHR5cGUgYW5kIG9ubHkgdXNlIGl0IHdoZW4g b3RoZXIgZmxvd3M8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NC4zLiBS ZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFsczogQ2hhbmdlIOKAnDxzcGFuIGxhbmc9 IkVOIj5yZXNvdXJjZSBvd25lciBjcmVkZW50aWFsczwvc3Bhbj7igJ0gdG8g4oCcPHNwYW4gbGFu Zz0iRU4iPnJlc291cmNlIG93bmVy4oCZcyBjcmVkZW50aWFsczwvc3Bhbj7igJ0uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj40LjMuMi4gQWNjZXNzIFRva2VuIFJlcXVlc3Q6Jm5ic3A7IENv bW1lbnQgb24g4oCcYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBwcm90ZWN0IHRoZSBlbmRwb2lu dCBhZ2FpbnN0IGJydXRlIGZvcmNlIGF0dGFja3PigJ06IOKAnFNob3VsZG7igJl0IHRoZSByZXF1 aXJlbWVudCB0byBwcmV2ZW50IGFnYWluc3QgYnJ1dGUgZm9yY2UNCiBhdHRhY2tzIGFwcGx5IHRv IGFsbCBjcmVkZW50aWFscywgcmVzb3VyY2Ugb3duZXIgb3Igb3RoZXJ3aXNlPyBJbiBvdGhlciB3 b3JkcyBpbiBzZWN0aW9uIDIuNC4xIHdlIHRhbGsgYWJvdXQgaG93IGNsaWVudHMgc3VibWl0IHRo ZWlyIG5hbWUvcGFzc3dvcmQuIFNob3VsZG7igJl0IGVuZHBvaW50cyBhY2NlcHRpbmcgY2xpZW50 IG5hbWUvcGFzc3dvcmRzIGhhdmUgdGhlIHNhbWUgcHJvdGVjdGlvbnMgYWdhaW5zdCBicnV0ZSBm b3JjZSBhdHRhY2s/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40LjQuMy4gQWNjZXNz IFRva2VuIFJlc3BvbnNlOiBDb21tZW50IG9uIOKAnEEgcmVmcmVzaCB0b2tlbiBTSE9VTEQgTk9U IGJlIGluY2x1ZGVk4oCdOiDigJxXaHkgaXNu4oCZdCB0aGlzIGEgTVVTVCBOT1Q/4oCdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj40LjUuIEV4dGVuc2lvbnM6IENvbW1lbnQg4oCcSXNu4oCZ dCB0aGUgdGV4dCBpbiB0aGlzIHNlY3Rpb24gYW5kIDguMyByZWR1bmRhbnQgd2l0aCBlYWNoIG90 aGVyPyBJdCBzZWVtcyBsaWtlIHdlIHNob3VsZCB0YWtlIHRoZSB0ZXh0IGZyb20gaGVyZSBhbmQg bWVyZ2UgaXQgd2l0aCBzZWN0aW9uIDguMyBzbyBhbGwNCiB0aGUgZXh0ZW5zaW9uIGluZm9ybWF0 aW9uIGlzIHJlY29yZGVkIGluIG9uZSBwbGFjZS4mbmJzcDsgSXTigJlzIGp1c3QgcGxhaW4gdGhh dCBhbGwgb3RoZXIgZXh0ZW5zaW9uIHBvaW50cyBhcmUgaW4gc2VjdGlvbiA4IGJ1dCB0aGlzIG9u ZS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjUuMS4gU3VjY2Vzc2Z1bCBSZXNwb25z ZTogQ29tbWVudCBvbiDigJxwYXJhbWV0ZXIgYXQgdGhlIGhpZ2hlc3Qgc3RydWN0dXJlIGxldmVs 4oCdOiDigJxBcmUgdGhlcmUgYW55IGd1YXJhbnRlZXMgYWJvdXQgdGhlIG9yZGVyIG9mIHRoZSBt ZW1iZXJzIGluIHRoZSBKU09OIG9iamVjdD8gSWYgbm90IHdlIHNob3VsZCBzYXkNCiBzbyBleHBs aWNpdGx5LuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NS4yLiBFcnJvciBSZXNwb25z ZTogQ29tbWVudCBvbiDigJxtdWx0aXBsZSBjbGllbnQgYXV0aGVudGljYXRpb25zIGluY2x1ZGVk 4oCdIGluIGludmFsaWRfY2xpZW50OiDigJxTaG91bGRu4oCZdCB0aGlzIGJlIGFuIGludmFsaWRf cmVxdWVzdD/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjUuMi4gRXJyb3IgUmVzcG9u c2U6IENvbW1lbnQgb24g4oCcTnVtZXJpY2FsIHZhbHVlcyBhcmUgaW5jbHVkZWQgYXMgSlNPTiBu dW1iZXJz4oCdOiDigJxTYW1lIGlzc3VlIGFzIGJlZm9yZSwgZG9lcyBvcmRlcmluZyBtYXR0ZXIg YW5kIGlmIG5vdCB3ZSBuZWVkIHRvIHNheSB0aGF0LuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+OC4xLiBEZWZpbmluZyBBY2Nlc3MgVG9rZW4gVHlwZXM6IENoYW5nZSDigJw8c3BhbiBs YW5nPSJFTiI+b3IgdXNlIGEgdW5pcXVlPC9zcGFuPuKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+ b3IgdXNpbmcgYSB1bmlxdWU8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ OS4mbmJzcDsgTmF0aXZlIEFwcGxpY2F0aW9uczombmJzcDsgQ2hhbmdlIOKAnGFuIHNjaGVtZeKA nSB0byDigJxhIHNjaGVtZeKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+OS4mbmJzcDsg TmF0aXZlIEFwcGxpY2F0aW9uczogJm5ic3A7Q2hhbmdlIOKAnDxzcGFuIGxhbmc9IkVOIj5vZmZl ciBhbiBpbXByb3ZlZCB1c2FiaWxpdHk8L3NwYW4+4oCdIHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5v ZmZlciBpbXByb3ZlZCB1c2FiaWxpdHk8L3NwYW4+4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj45LiZuYnNwOyBOYXRpdmUgQXBwbGljYXRpb25zOiAmbmJzcDtDaGFuZ2Ug4oCcPHNwYW4g bGFuZz0iRU4iPmluYWJpbGl0eSB0byBrZWVwIGNyZWRlbnRpYWxzIGNvbmZpZGVudGlhbDwvc3Bh bj7igJ0gdG8g4oCcPHNwYW4gbGFuZz0iRU4iPmluYWJpbGl0eSB0byBrZWVwIGNsaWVudCBjcmVk ZW50aWFscyBjb25maWRlbnRpYWw8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+OS4mbmJzcDsgTmF0aXZlIEFwcGxpY2F0aW9uczogJm5ic3A7Q2hhbmdlIOKAnFdoZW4gdXNp bmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgZmxvdyBhIHJlZnJlc2ggdG9rZW4gaXMgbm90IHJl dHVybmVk4oCdIHRvIOKAnFdoZW4gdXNpbmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUgZmxvdyBh IHJlZnJlc2ggdG9rZW4gaXMgbm90IHJldHVybmVkDQogc28gb25jZSB0aGUgYWNjZXNzIHRva2Vu IGV4cGlyZXMgdGhlIGFwcGxpY2F0aW9uIHdpbGwgaGF2ZSB0byByZXBlYXQgdGhlIGF1dGhvcml6 YXRpb24gcHJvY2Vzc+KAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjIuIENsaWVu dCBJbXBlcnNvbmF0aW9uOiZuYnNwOyBDaGFuZ2Ug4oCca2VlcCBpcyBjbGllbnTigJ0gdG8g4oCc a2VlcCBpdHMgY2xpZW504oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTAuMi4gQ2xp ZW50IEltcGVyc29uYXRpb246Jm5ic3A7IENoYW5nZSDigJw8c3BhbiBsYW5nPSJFTiI+ZHVlIHRv IHRoZSBjbGllbnQgbmF0dXJlPC9zcGFuPuKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+ZHVlIHRv IHRoZSBjbGllbnTigJlzIG5hdHVyZTwvc3Bhbj7igJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4xMC4yLiBDbGllbnQgSW1wZXJzb25hdGlvbjombmJzcDsgQ2hhbmdlIOKAnDxzcGFuIGxh bmc9IkVOIj5VUkkgdXNlZCBmb3IgcmVjZWl2aW5nIGF1dGhvcml6YXRpb248L3NwYW4+4oCdIHRv IOKAnDxzcGFuIGxhbmc9IkVOIj5VUkkgdXNlZCBmb3IgcmVjZWl2aW5nIGF1dGhvcml6YXRpb24g cmVxdWVzdHM8L3NwYW4+4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC4yLiBDbGll bnQgSW1wZXJzb25hdGlvbjombmJzcDsgQ2hhbmdlIOKAnDxzcGFuIGxhbmc9IkVOIj5lbmdhZ2Ug dGhlIHJlc291cmNlIG93bmVyPC9zcGFuPuKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+ZW5nYWdp bmcgdGhlIHJlc291cmNlIG93bmVyPC9zcGFuPuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjEwLjIuIENsaWVudCBJbXBlcnNvbmF0aW9uOiZuYnNwOyBDaGFuZ2Ug4oCcPHNwYW4gbGFu Zz0iRU4iPmFuZCBhdXRob3JpemUgdGhlIHJlcXVlc3Q8L3NwYW4+4oCdIHRvIOKAnDxzcGFuIGxh bmc9IkVOIj5hbmQgYXV0aG9yaXplIG9yIHJlamVjdCB0aGUgcmVxdWVzdDwvc3Bhbj7igJ0uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC4zLiBBY2Nlc3MgVG9rZW5zOiBDaGFuZ2Ug4oCc QWNjZXNzIHRva2VuIChhcyB3ZWxsIGFzIGFueSBhY2Nlc3MgdG9rZW4gdHlwZS1zcGVjaWZpYyBh dHRyaWJ1dGVzKeKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+QWNjZXNzIHRva2VucyAoYXMgd2Vs bCBhcyBhbnkgYWNjZXNzIHRva2VuIHR5cGUgc3BlY2lmaWMgYXR0cmlidXRlcyk8L3NwYW4+4oCd LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTAuMy4gQWNjZXNzIFRva2VuczogQ2hhbmdl IOKAnGd1ZXNzZWQgdG8gcHJvZHVjZeKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+Z3Vlc3NlZCBz byBhcyB0byBwcmV2ZW50IHVuYXV0aG9yaXplZCBwYXJ0aWVzIGZyb20gcHJvZHVjaW5nPC9zcGFu PuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjQuIFJlZnJlc2ggVG9rZW5zOiBD b21tZW50IOKAnEFzIG1lbnRpb25lZCBwcmV2aW91c2x5IHdlIHJlYWxseSBzaG91bGQgZXhwbGFp biB3aHkgd2UgaW50cm9kdWNlZCByZWZyZXNoIHRva2Vucy4gV2l0aG91dCB1bmRlcnN0YW5kaW5n IHRoZSBpbnRlbnQgb2YgdGhlIG1lY2hhbmlzbSBpdOKAmXMgdW5saWtlbHkNCiBpbXBsZW1lbnRl cnMgd2lsbCB1c2UgdGhlbSBhcHByb3ByaWF0ZWx5LuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+MTAuNC4gUmVmcmVzaCBUb2tlbnM6Jm5ic3A7IENoYW5nZSDigJxzdG9yYWdlLCBhbmQg c2hhcmVkIG9ubHkgYW1vbmfigJ0gdG8g4oCcc3RvcmFnZSwgYW5kIGFyZSB0byBiZSBzaGFyZWQg b25seSBhbW9uZ+KAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjQuIFJlZnJlc2gg VG9rZW5zOiZuYnNwOyBDaGFuZ2Ug4oCccmVmcmVzaCB0b2tlbnMgcm90YXRpb27igJ0gdG8g4oCc cmVmcmVzaCB0b2tlbiByb3RhdGlvbuKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEw LjQuIFJlZnJlc2ggVG9rZW5zOiZuYnNwOyBDaGFuZ2Ug4oCcZ3Vlc3NlZCB0byBwcm9kdWNl4oCd IHRvIOKAnDxzcGFuIGxhbmc9IkVOIj5ndWVzc2VkIHNvIGFzIHRvIHByZXZlbnQgdW5hdXRob3Jp emVkIHBhcnRpZXMgZnJvbSBwcm9kdWNpbmc8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+MTAuNi4gQXV0aG9yaXphdGlvbiBDb2RlIExlYWthZ2U6IENvbW1lbnQg4oCcSSBm YW5jeSBteXNlbGYgYXMgYmVpbmcgcmVhc29uYWJseSBpbnRlbGxpZ2VudCBhbmQgSeKAmW0gdW5j bGVhciB3aGF0IGF0dGFjayBpcyBhY3R1YWxseSBiZWluZyBkZXNjcmliZWQgaGVyZS7igJ08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjYuIEF1dGhvcml6YXRpb24gQ29kZSBMZWFrYWdl OiBDb21tZW50IG9uIOKAnFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgcmVxdWlyZSB0 aGUgY2xpZW50IHRvIHJlZ2lzdGVyIHRoZWlyIHJlZGlyZWN0aW9uIFVSSeKAnTog4oCcV2h5IGlz IHRoaXMgYSBzaG91bGQ/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC43LiBSZXNv dXJjZSBPd25lciBQYXNzd29yZCBDcmVkZW50aWFsczogQ29tbWVudCBvbiDigJxwYXNzd29yZCBh bnRpLXBhdHRlcm7igJ06IOKAnElzIGl0IGZhaXIgdG8gZXhwZWN0IHRoYXQgdGhlIHJlYWRlciBr bm93cyB3aGF0IHRoZSBwYXNzd29yZCBhbnRpLXBhdHRlcm4gaXM/IFNob3VsZG7igJl0IHNvbWUg cmVmZXJlbmNlDQogdG8gYSBkZWZpbml0aW9uIG9mIHRoaXMgcGF0dGVybiBiZSByZXF1aXJlZD/i gJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjcuIFJlc291cmNlIE93bmVyIFBhc3N3 b3JkIENyZWRlbnRpYWxzOiBDb21tZW50IG9uIOKAnFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBT SE9VTEQgcmVzdHJpY3QgdGhlIHNjb3BlIGFuZCBsaWZldGltZSBvZiBhY2Nlc3MgdG9rZW5zIGlz c3VlZCB2aWEgdGhpcyBncmFudCB0eXBl4oCdOiDigJxSZXN0cmljdCBpbg0KIHdoYXQgd2F5cz8g QmFzZWQgb24gd2hhdCBjcml0ZXJpYT8gVGhpcyBzdGF0ZW1lbnQgaXMgdGhlIGVxdWl2YWxlbnQg b2Ygc2F5aW5nIOKAnGRvbuKAmXQgZG8gYmFkIHN0dWZm4oCdLiBQZXJoYXBzIHRydWUgYnV0IG5v dCB0ZXJyaWJseSB1c2VmdWwu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMC4xMi4g Q3Jvc3MtU2l0ZSBSZXF1ZXN0IEZvcmdlcnk6IENvbW1lbnQgb24gZmlyc3QgcGFyYWdyYXBoOiDi gJxJIGNoYWxsZW5nZSBhbnkgcmVhc29uYWJseSBpbnRlbGxpZ2VudCBwZXJzb24gd2hvIGRvZXMg bm90IGFscmVhZHkga25vdyB3aGF0IGEgQ1NSRiBpcyB0byByZWFkIHRoaXMgcGFyYWdyYXBoIGFu ZA0KIGNvbWUgYXdheSBhbnkgY2xlYXJlciBhcyB0byB3aGF0IGlzIGJlaW5nIGRpc2N1c3NlZC4g QXQgYSBtaW5pbXVtIGlzbuKAmXQgc29tZSByZWZlcmVuY2UgdG8gYSBjb21wbGV0ZSBkZWZpbml0 aW9uIG9mIENTUkYgbmVlZGVkIGlmIHRoZXJlIGlzIHRvIGJlIGFueSBob3BlIG9mIHVzZXIgY29t cGxpYW5jZT/igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjEyLiBDcm9zcy1TaXRl IFJlcXVlc3QgRm9yZ2VyeTogQ29tbWVudCBvbiDigJxUaGUgJnF1b3Q7c3RhdGUmcXVvdDsgcmVx dWVzdCBwYXJhbWV0ZXIgTVVTVCBjb250YWluIGEgbm9uLWd1ZXNzYWJsZSB2YWx1ZeKAnTog4oCc QWN0dWFsbHkgYSBub24tZ3Vlc3NhYmxlIHZhbHVlIHdvbuKAmXQgc3RvcCB0aGUgYXR0YWNrIGRp c2N1c3NlZA0KIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGggb24gaXRzIG93bi4gV2hhdOKAmXMg YWxzbyBuZWVkZWQgaXMgYSB3YXkgdG8gdW5pcXVlbHkgKGFuZCB1bmJyZWFrYWJseSkgYXNzb2Np YXRlIHRoZSBzdGF0ZSB3aXRoIGEgcGFydGljdWxhciB1c2VyIHNvIHRoYXQgaWYgYW4gYXV0aG9y aXphdGlvbiBjb2RlIHN3YXAgb2NjdXJzIGl0IGNhbiBiZSByZWxpYWJseSBkZXRlY3RlZC7igJ08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEwLjEzLiBDbGlja2phY2tpbmc6IENvbW1lbnQg b24g4oCceC1mcmFtZS1vcHRpb25z4oCdOiDigJxUaGUgcmVjb21tZW5kYXRpb24gc2VlbXMgY29u ZnVzZWQuIElzIGl0IG8uay4gdG8ganVzdCByZWx5IG9uIHgtZnJhbWUtb3B0aW9ucyBvciBNVVNU IG90aGVyIGFjdGlvbnMgYmUgdGFrZW4/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4x MS4xLiZuYnNwOyBUaGUgT0F1dGggQWNjZXNzIFRva2VuIFR5cGUgUmVnaXN0cnk6IENoYW5nZSDi gJx0b2tlIHR5cGXigJ0gdG8g4oCcdG9rZW4gdHlwZeKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjExLjEuMS4mbmJzcDsgUmVnaXN0cmF0aW9uIFRlbXBsYXRlOiBDaGFuZ2Ug4oCcPHNw YW4gbGFuZz0iRU4iPnByb3RlY3RlZCByZXNvdXJjZXMgcmVxdWVzdHMgdXNpbmcgYWNjZXNzIHRv a2VuPC9zcGFuPuKAnSB0byDigJw8c3BhbiBsYW5nPSJFTiI+cHJvdGVjdGVkIHJlc291cmNlIHJl cXVlc3RzIHVzaW5nIGFjY2VzcyB0b2tlbnM8L3NwYW4+4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+MTEuMS4xLiZuYnNwOyBSZWdpc3RyYXRpb24gVGVtcGxhdGU6Jm5ic3A7IENoYW5n ZSDigJxSZWZlcmVuY2UgdG8gZG9jdW1lbnTigJ0gdG8g4oCcUmVmZXJlbmNlIHRvIHRoZSBkb2N1 bWVudOKAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89D74SN2PRD0302MB137_-- From eran@hueniverse.com Thu Aug 11 12:34:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F77721F8B3D for ; Thu, 11 Aug 2011 12:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFeQFAG7ykGD for ; Thu, 11 Aug 2011 12:34:51 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id BC67121F8B10 for ; Thu, 11 Aug 2011 12:34:51 -0700 (PDT) Received: (qmail 15393 invoked from network); 11 Aug 2011 19:35:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 19:35:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 11 Aug 2011 12:35:17 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , Dick Hardt Date: Thu, 11 Aug 2011 12:35:07 -0700 Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYXcwj7K/GTea6Qoyp+x0mhHZJ4A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA697C4717C73eranhueniversecom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:34:52 -0000 --_000_CA697C4717C73eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 1.5 already covers refresh tokens. There are many use cases for ref= resh tokens. They are basically a protocol feature used to make scalability= and security more flexible. Anonymity was never part of their design, and = by the nature of this protocol, is more in the domain of the resource serve= r (based on what information it exposes via its API). In fact, your email i= f the first such suggestion of anonymity. EHL From: Anthony Nadalin > Date: Thu, 11 Aug 2011 11:15:28 -0700 To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Refresh Tokens Many reasons, but none are explained in the specification From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Thursday, August 11, 2011 10:51 AM To: Anthony Nadalin Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access token = would limit the time an attacker would have access revocation: if the access token is self contained, authorization can be rev= oked by not issuing new access tokens. A resource does not need to query th= e authorization server to see if the access token is valid.This simplifies = access token validation and makes it easier to scale and support multiple a= uthorization servers. There is a window of time when an access token is va= lid, but authorization is revoked. On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: Nowhere in the specification is there explanation for refresh tokens, The r= eason that the Refresh token was introduced was for anonymity. The scenario= is that a client asks the user for access. The user wants to grant the acc= ess but not tell the client the user's identity. By issuing the refresh tok= en as an 'identifier' for the user (as well as other context data like the = resource) it's possible now to let the client get access without revealing = anything about the user. Recommend that the above explanation be included s= o developers understand why the refresh tokens are there. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA697C4717C73eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Section 1.5 already cove= rs refresh tokens. There are many use cases for refresh tokens. They are ba= sically a protocol feature used to make scalability and security more flexi= ble. Anonymity was never part of their design, and by the nature of this pr= otocol, is more in the domain of the resource server (based on what informa= tion it exposes via its API). In fact, your email if the first such suggest= ion of anonymity.

EHL

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt <dick.hardt@gmail.com>
Cc: "OAuth WG (oauth@i= etf.org)" <oauth@ietf.org><= br>Subject: Re: [OAUTH-WG] Refresh= Tokens

Many reasons, but none are explained in the specification=

 

From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony N= adalin
Cc: OAuth WG (oauth@ietf= .org)
Subject: Re: [OAUTH-WG] Refresh Tokens

 

My recollection of refresh tokens was for security and revocation.=

 

=

security: By having a short lived access token, a co= mpromised access token would limit the time an attacker would have access

 

<= div>

revocation: if the access token is self containe= d, authorization can be revoked by not issuing new access tokens. A resourc= e does not need to query the authorization server to see if the access toke= n is valid.This simplifies access token validation and makes it easier to scale and support multiple authorization= servers.  There is a window of time when an access token is vali= d, but authorization is revoked. 

 

 

 

On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:=



Nowhere in the specification is there explanation for refresh = tokens, The reason that the Refresh token was introduced was for anonymity.= The scenario is that a client asks the user for access. The user wants to grant the access but not tell the c= lient the user's identity. By issuing the refresh token as an 'identifier' = for the user (as well as other context data like the resource) it's possibl= e now to let the client get access without revealing anything about the user. Recommend that the above explan= ation be included so developers understand why the refresh tokens are there= .

__________________________= _____________________
OAuth mailing list
OAuth@ietf.org<= br>https://www.ietf= .org/mailman/listinfo/oauth

 

--_000_CA697C4717C73eranhueniversecom_-- From tonynad@microsoft.com Thu Aug 11 12:41:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7711E8081 for ; Thu, 11 Aug 2011 12:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y0+XPb8dVOv for ; Thu, 11 Aug 2011 12:41:18 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0889B21F8B4A for ; Thu, 11 Aug 2011 12:41:18 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 12:41:53 -0700 Received: from DB3EHSOBE001.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 12:41:51 -0700 Received: from mail80-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 19:41:50 +0000 Received: from mail80-db3 (localhost.localdomain [127.0.0.1]) by mail80-db3-R.bigfish.com (Postfix) with ESMTP id E033A14D84F8 for ; Thu, 11 Aug 2011 19:41:49 +0000 (UTC) X-SpamScore: -26 X-BigFish: PS-26(zz9371K936eKc85fh98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h) X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT015.namprd03.prod.outlook.com; R:internal; EFV:INT X-FB-SS: 13, Received-SPF: softfail (mail80-db3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT015.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail80-db3 (localhost.localdomain [127.0.0.1]) by mail80-db3 (MessageSwitch) id 1313091692284578_24445; Thu, 11 Aug 2011 19:41:32 +0000 (UTC) Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.254]) by mail80-db3.bigfish.com (Postfix) with ESMTP id 3174F193804D; Thu, 11 Aug 2011 19:41:32 +0000 (UTC) Received: from SN2PRD0302HT015.namprd03.prod.outlook.com (207.46.4.139) by DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 19:41:30 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT015.namprd03.prod.outlook.com ([10.27.90.241]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 19:41:28 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Dick Hardt Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYTQ8Url5GUfgWROGRaafg4jY5WAAAisuAAACFmiAAAx1sgAAALzUg Date: Thu, 11 Aug 2011 19:41:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89DBFSN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT015.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:41:19 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89DBFSN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Anonymity was certainly part of the design for WRAP From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, August 11, 2011 12:35 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens Section 1.5 already covers refresh tokens. There are many use cases for ref= resh tokens. They are basically a protocol feature used to make scalability= and security more flexible. Anonymity was never part of their design, and = by the nature of this protocol, is more in the domain of the resource serve= r (based on what information it exposes via its API). In fact, your email i= f the first such suggestion of anonymity. EHL From: Anthony Nadalin > Date: Thu, 11 Aug 2011 11:15:28 -0700 To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Refresh Tokens Many reasons, but none are explained in the specification From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Thursday, August 11, 2011 10:51 AM To: Anthony Nadalin Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access token = would limit the time an attacker would have access revocation: if the access token is self contained, authorization can be rev= oked by not issuing new access tokens. A resource does not need to query th= e authorization server to see if the access token is valid.This simplifies = access token validation and makes it easier to scale and support multiple a= uthorization servers. There is a window of time when an access token is va= lid, but authorization is revoked. On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: Nowhere in the specification is there explanation for refresh tokens, The r= eason that the Refresh token was introduced was for anonymity. The scenario= is that a client asks the user for access. The user wants to grant the acc= ess but not tell the client the user's identity. By issuing the refresh tok= en as an 'identifier' for the user (as well as other context data like the = resource) it's possible now to let the client get access without revealing = anything about the user. Recommend that the above explanation be included s= o developers understand why the refresh tokens are there. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89DBFSN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anonymity was certainly p= art of the design for WRAP

 <= /p>

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

 

Section 1.5 already covers = refresh tokens. There are many use cases for refresh tokens. They are basic= ally a protocol feature used to make scalability and security more flexible. Anonymity was never part of their design, and by the nature= of this protocol, is more in the domain of the resource server (based on w= hat information it exposes via its API). In fact, your email if the first s= uch suggestion of anonymity.

 

EHL

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt <dick.hard= t@gmail.com>
Cc: "OAuth WG (oauth@ietf.org= )" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Refresh Tokens

 

Many reasons, but none ar= e explained in the specification

 

From: Dick Hardt [mailto:= dick.hardt@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)<= br> Subject: Re: [OAUTH-WG] Refresh Tokens

 =

My recollection of refre= sh tokens was for security and revocation.

 =

security: By having a sh= ort lived access token, a compromised access token would limit the time an = attacker would have access

 =

revocation: if the acces= s token is self contained, authorization can be revoked by not issuing new = access tokens. A resource does not need to query the authorization server t= o see if the access token is valid.This simplifies access token validation and makes it easier to scale and suppor= t multiple authorization servers.  There is a window of time when= an access token is valid, but authorization is revoked. 

 =

 =

 =

On 2011-08-11, at 10:40 = AM, Anthony Nadalin wrote:




Nowhere in the specificatio= n is there explanation for refresh tokens, The reason that the Refresh toke= n was introduced was for anonymity. The scenario is that a client asks the user for access. The user wants to grant the access but = not tell the client the user's identity. By issuing the refresh token as an= 'identifier' for the user (as well as other context data like the resource= ) it's possible now to let the client get access without revealing anything about the user. Recommend that the a= bove explanation be included so developers understand why the refresh token= s are there.

_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth<= /span>

 =

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89DBFSN2PRD0302MB137_-- From tonynad@microsoft.com Thu Aug 11 12:58:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E28711E808A for ; Thu, 11 Aug 2011 12:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScnxRFYkkB87 for ; Thu, 11 Aug 2011 12:58:46 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 7235321F8B42 for ; Thu, 11 Aug 2011 12:58:46 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 12:59:21 -0700 Received: from TX2EHSOBE003.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 12:59:21 -0700 Received: from mail3-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 19:59:20 +0000 Received: from mail3-tx2 (localhost.localdomain [127.0.0.1]) by mail3-tx2-R.bigfish.com (Postfix) with ESMTP id 71E86CC056A for ; Thu, 11 Aug 2011 19:59:20 +0000 (UTC) X-SpamScore: -26 X-BigFish: PS-26(zz9371K936eKc85fh98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT015.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail3-tx2: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT015.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail3-tx2 (localhost.localdomain [127.0.0.1]) by mail3-tx2 (MessageSwitch) id 131309272566603_28725; Thu, 11 Aug 2011 19:58:45 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.241]) by mail3-tx2.bigfish.com (Postfix) with ESMTP id D152CA00050; Thu, 11 Aug 2011 19:58:44 +0000 (UTC) Received: from SN2PRD0302HT015.namprd03.prod.outlook.com (207.46.4.139) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 19:58:41 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT015.namprd03.prod.outlook.com ([10.27.90.241]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 19:58:40 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Dick Hardt Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYTQ8Url5GUfgWROGRaafg4jY5WAAAisuAAACFmiAAAx1sgAAAwpIw Date: Thu, 11 Aug 2011 19:58:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89E02SN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT015.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 19:58:47 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89E02SN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 1.5 does not explain why refresh tokens are there. If implementers = don't understand why we did something then how are they supposed to get the= implementation right? From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, August 11, 2011 12:35 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens Section 1.5 already covers refresh tokens. There are many use cases for ref= resh tokens. They are basically a protocol feature used to make scalability= and security more flexible. Anonymity was never part of their design, and = by the nature of this protocol, is more in the domain of the resource serve= r (based on what information it exposes via its API). In fact, your email i= f the first such suggestion of anonymity. EHL From: Anthony Nadalin > Date: Thu, 11 Aug 2011 11:15:28 -0700 To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Refresh Tokens Many reasons, but none are explained in the specification From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Thursday, August 11, 2011 10:51 AM To: Anthony Nadalin Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access token = would limit the time an attacker would have access revocation: if the access token is self contained, authorization can be rev= oked by not issuing new access tokens. A resource does not need to query th= e authorization server to see if the access token is valid.This simplifies = access token validation and makes it easier to scale and support multiple a= uthorization servers. There is a window of time when an access token is va= lid, but authorization is revoked. On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: Nowhere in the specification is there explanation for refresh tokens, The r= eason that the Refresh token was introduced was for anonymity. The scenario= is that a client asks the user for access. The user wants to grant the acc= ess but not tell the client the user's identity. By issuing the refresh tok= en as an 'identifier' for the user (as well as other context data like the = resource) it's possible now to let the client get access without revealing = anything about the user. Recommend that the above explanation be included s= o developers understand why the refresh tokens are there. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89E02SN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 1.5 does not expl= ain why refresh tokens are there. If implementers don't understand why we d= id something then how are they supposed to get the implementation right?

 <= /p>

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

 

Section 1.5 already covers = refresh tokens. There are many use cases for refresh tokens. They are basic= ally a protocol feature used to make scalability and security more flexible. Anonymity was never part of their design, and by the nature= of this protocol, is more in the domain of the resource server (based on w= hat information it exposes via its API). In fact, your email if the first s= uch suggestion of anonymity.

 

EHL

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt <dick.hard= t@gmail.com>
Cc: "OAuth WG (oauth@ietf.org= )" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Refresh Tokens

 

Many reasons, but none ar= e explained in the specification

 

From: Dick Hardt [mailto:= dick.hardt@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)<= br> Subject: Re: [OAUTH-WG] Refresh Tokens

 =

My recollection of refre= sh tokens was for security and revocation.

 =

security: By having a sh= ort lived access token, a compromised access token would limit the time an = attacker would have access

 =

revocation: if the acces= s token is self contained, authorization can be revoked by not issuing new = access tokens. A resource does not need to query the authorization server t= o see if the access token is valid.This simplifies access token validation and makes it easier to scale and suppor= t multiple authorization servers.  There is a window of time when= an access token is valid, but authorization is revoked. 

 =

 =

 =

On 2011-08-11, at 10:40 = AM, Anthony Nadalin wrote:




Nowhere in the specificatio= n is there explanation for refresh tokens, The reason that the Refresh toke= n was introduced was for anonymity. The scenario is that a client asks the user for access. The user wants to grant the access but = not tell the client the user's identity. By issuing the refresh token as an= 'identifier' for the user (as well as other context data like the resource= ) it's possible now to let the client get access without revealing anything about the user. Recommend that the a= bove explanation be included so developers understand why the refresh token= s are there.

_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth<= /span>

 =

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89E02SN2PRD0302MB137_-- From eran@hueniverse.com Thu Aug 11 13:01:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68EE21F8B55 for ; Thu, 11 Aug 2011 13:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYo8htAttrQf for ; Thu, 11 Aug 2011 13:01:36 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 68B8521F8B4D for ; Thu, 11 Aug 2011 13:01:36 -0700 (PDT) Received: (qmail 31435 invoked from network); 11 Aug 2011 20:02:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 20:02:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 11 Aug 2011 13:02:03 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , "OAuth WG (oauth@ietf.org)" Date: Thu, 11 Aug 2011 13:01:56 -0700 Thread-Topic: [OAUTH-WG] Redirection URI Thread-Index: AcxYYYmf7NUAbtEJRWO+uhW1Mhs7Tw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA697D2617C7Deranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Redirection URI X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:01:38 -0000 --_000_CA697D2617C7Deranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't see any below justifying making changes. Comments inline. From: Anthony Nadalin > Date: Thu, 11 Aug 2011 09:44:54 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Redirection URI Section 3.1.2 explicitly states that the redirection endpoint URI MUST be a= n absolute URI. But that means that the URI could be potentially of any sch= eme. This is probably intentional since there are scenarios where a native = client will want to register a custom scheme as the call back URI. But how can that ever be considered secure? Any app could p= otentially register a scheme with itself as the handler in the OS. Are we r= eally in a position to state that ALL OS environments in ALL cases will onl= y allow for the registration of new URI schemes in a completely secure way?= I can't help but wonder if that isn't going too far and endangering users?= Shouldn't we require that the redirect URI MUST always be a HTTPS URI and = that native clients will need to have access to a browser? If we don't then= how can we really be sure that a custom scheme is associated with the appl= ication we think it's associated with? First, we already reached consensus not to require HTTPS for the redirectio= n URI. The language is SHOULD use TLS when the redirection URI is sent over= the network. Second, the spec doesn't offer anything in terms of validating ownership of= any redirection URI. There is nothing to prove that a client is in control= of an HTTP URI as well. I expect custom schemes to require special relatio= nship with the authorization server, and that most companies will either no= t support it, or require a human verification as a step. At the same time, = there is nothing to prevent a native application from messing with existing= scheme registrations, including HTTP. Either way, custom schemes are really outside the scope of this working gro= up because they are actually a violation of IETF protocols which require re= gistration. If we are going to allow for custom schemes then fun issues= come up. Let's say that an authorization server receives a request from an= implicit client with a redirection URI value of foo:privatescheme:bar. Let= 's further say that the authorization server has an implicit client registe= red with it whose URI is foo:privatescheme:%62%61%72. What should the autho= rization server do? Should it: A) Reject the request because the submitted= redirection URI doesn't match exactly with the registered URI? B) Accept the request because, if one appli= es URL decoding, it is identical to the registered URI but send back the re= sponse with the registered value (e.g. with :bar at the end)? C) Same as B except send back the response = with the same value as specified in redirect uri parameter in the request? Any of the above is legal according to the new or proposed = language. But that clearly can't be right. After all, the host OS which all= owed the client to register the "foo" scheme may not see foo:privatescheme:= bar and foo:privatescheme:%62%61%72 as the same. So if a legitimate app was= using the %62%61%72 value then B would cause an error since the response w= ould be wrong and C would be right. But if the value is part of an attack t= hen B would be right and C would be wrong. Since there is no way for the au= thorization server to know ahead of time what OS might be in use and what b= ehavior it might have I think we have to define that the correct behavior = as "A". The agreement on how to compare redirection URIs is NOT a pr= ivate agreement between the client and authorization server. It's a public = agreement. The whole point of OAuth is to allow any client and any authoriz= ation server to interoperate. But as I show above if the client's assumptio= ns about how the redirect URI is processed and the server's assumptions are= n't the same then security breaks. Therefore the standard MUST define what = the expected behavior is. How is this any different from two clients using the same HTTP URI? I belie= ve this is vendor specific. I can imagine use cases for allowing multiple c= lients to use the same redirection URI, especially when using localhost or = other special case destinations. Also, URI comparison is scheme-specific wh= ich makes it impossible for verification and comparison by the server for c= ustom schemes made up by the client. So we have to answer a couple of questions: Question #1 - How should the server compare= a submitted redirection URI to one it has registered if the server doesn't= recognize the URI scheme? It can't. URI comparison is scheme-specific. It should probably not allow r= egistration of custom schemes without some additional trust which is beyond= the scope. Question #2 - OAuth in section 3.1.2 explic= itly states that the redirection URI can contain a query component. Does th= at override the registered value? In other words if the registered value wa= s foo:privatescheme:bar and the received value is foo:privatescheme:bar?foo= =3Dblah, do the two match? That depends on how the server opts to perform its comparison. This is desc= ribed in 3.1.2.3. I can see a general question about conflict between a que= ry in both the registered and dynamic values not matching, but this is more= of a bad server implementation than anything. The server should force one = model (full URI registration or scheme, authority, and path components regi= stration). Question #3 - If a recognized URL scheme is= used then what rules apply? And how can we be sure that both the client an= d the authorization server are using the same rules? Because, if they aren'= t, then, well, Dave Thaler's paper nicely outlines the consequences. This i= s especially the case if the redirection URI is pointing to a multi-tenant = server where getting the URI 'wrong' means sending the response to the wron= g place. Again, this is a general issue with redirections. I believe the right way t= o address this is via future profiles of the protocol, based on actual depl= oyment experience. We have failed over two years to reach consensus on even= a basic set of required comparison rules. Too late to reopen that now, but= if you have a proposal, publishing a profile would be very helpful. Propose that the only way to handle all of these rather nas= ty issues is by mandating that section 6.2.1 of RFC 3986 MUST be used by th= e authorization server when determining if a submitted redirection URI matc= hes a registered value. This explicitly precludes the use of 'prefix' match= ing and it explicitly precludes having extra query parameters. If the clien= t needs to encode state information than it can use the dedicated state var= iable. This is the simplest possible approach and therefore the one least l= ikely to be screwed up by authorization servers and therefore least likely = to introduce security holes. Please note that this proposal requires change= s in multiple places in the spec, including but possibly not limited to sec= tions 3.1.2, 3.1.2.2 and 3.1.2.3. -1. OAuth 2.0 is an extremely extensible framework which will be profiled b= y every implementation. I'm hoping for industry best practices to emerge bu= t beyond that, we are not likely to agree on this. I find 3986 6.2.1 to be = perfectly acceptable for comparing two absolute HTTP(S) URIs, but it will f= ail when allowing partial registration or custom URI schemes. We can recommend string comparison but that's as far as we can go at this p= oint. If the WG suddenly endorses making such a dramatic change, I will not= argue against it, but it is far too late IMO. EHL --_000_CA697D2617C7Deranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I don't see any below ju= stifying making changes. Comments inline.

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thu, 11 Aug 2011 09:44:54 -0700
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.= org>
Subject: [OAUTH-WG]= Redirection URI

Section 3.1.2 explicitly states that the redirection end= point URI MUST be an absolute URI. But that means that the URI could be pot= entially of any scheme. This is probably intentional since there are scenar= ios where a native client will want to register a custom scheme as the call ba= ck URI.

 

          &n= bsp;     But how can that ever be considered secure? An= y app could potentially register a scheme with itself as the handler in the= OS. Are we really in a position to state that ALL OS environments in ALL cases will only allow for the registration of new URI schemes in a complet= ely secure way? I can't help but wonder if that isn't going too far and end= angering users? Shouldn't we require that the redirect URI MUST always be a= HTTPS URI and that native clients will need to have access to a browser? If we don't then how can we really = be sure that a custom scheme is associated with the application we think it= 's associated with?

         &n= bsp;     


First, we already reached consensus not to requ= ire HTTPS for the redirection URI. The language is SHOULD use TLS when the = redirection URI is sent over the network.

Second, = the spec doesn't offer anything in terms of validating ownership of any red= irection URI. There is nothing to prove that a client is in control of an H= TTP URI as well. I expect custom schemes to require special relationship wi= th the authorization server, and that most companies will either not suppor= t it, or require a human verification as a step. At the same time, there is= nothing to prevent a native application from messing with existing scheme = registrations, including HTTP.

Either way, custom = schemes are really outside the scope of this working group because they are= actually a violation of IETF protocols which require registration.

       = ;         If we are going to allow = for custom schemes then fun issues come up. Let's say that an authorization= server receives a request from an implicit client with a redirection URI v= alue of foo:privatescheme:bar. Let's further say that the authorization server has an implicit client reg= istered with it whose URI is foo:privatescheme:%62%61%72. What should the a= uthorization server do?

=  

           &nb= sp;    Should it:

       &= nbsp;           &nbs= p;            A) Rej= ect the request because the submitted redirection URI doesn't match exactly= with the registered URI?

=             &nb= sp;            =        B) Accept the request because, if one = applies URL decoding, it is identical to the registered URI but send back t= he response with the registered value (e.g. with :bar at the end)?

=             &nb= sp;            =        C) Same as B except send back the resp= onse with the same value as specified in redirect uri parameter in the requ= est?

 

           = ;     Any of the above is legal according to the new or= proposed language. But that clearly can't be right. After all, the host OS= which allowed the client to register the "foo" scheme may not see foo:priv= atescheme:bar and foo:privatescheme:%62%61%72 as the same. So if a legitimate app was us= ing the %62%61%72 value then B would cause an error since the response woul= d be wrong and C would be right. But if the value is part of an attack then= B would be right and C would be wrong. Since there is no way for the authorization server to know ahead of= time what OS might be in use and what behavior it might have  I think= we have to define that the correct behavior as "A".

=  

           &nb= sp;   The agreement on how to compare redirection URIs is NO= T a private agreement between the client and authorization server. It's a p= ublic agreement. The whole point of OAuth is to allow any client and any authorization server to interoperate. But as I show above if the c= lient's assumptions about how the redirect URI is processed and the server'= s assumptions aren't the same then security breaks. Therefore the standard = MUST define what the expected behavior is.

 

=
How is this any different from two clients using the same HT= TP URI? I believe this is vendor specific. I can imagine use cases for allo= wing multiple clients to use the same redirection URI, especially when usin= g localhost or other special case destinations. Also, URI comparison is sch= eme-specific which makes it impossible for verification and comparison by t= he server for custom schemes made up by the client.

         &n= bsp;      So we have to answer a couple of questio= ns:

 

           =             &nb= sp;        Question #1 - How should the = server compare a submitted redirection URI to one it has registered if the = server doesn't recognize the URI scheme?


It can't. URI comparison is scheme-specif= ic. It should probably not allow registration of custom schemes without som= e additional trust which is beyond the scope.

          &nb= sp;            =          Question #2 - OAuth in sec= tion 3.1.2 explicitly states that the redirection URI can contain a query c= omponent. Does that override the registered value? In other words if the re= gistered value was foo:privatescheme:bar and the received value is foo:privateschem= e:bar?foo=3Dblah, do the two match?


That depends on how the server opts to perform= its comparison. This is described in 3.1.2.3. I can see a general question= about conflict between a query in both the registered and dynamic values n= ot matching, but this is more of a bad server implementation than anything.= The server should force one model (full URI registration or scheme, author= ity, and path components registration).

<= div class=3D"WordSection1">

           &nbs= p;            &= nbsp;       Question #3 - If a recognized URL= scheme is used then what rules apply? And how can we be sure that both the= client and the authorization server are using the same rules? Because, if they aren't, then, well, Dave Thaler's paper nicely outlines the conseq= uences. This is especially the case if the redirection URI is pointing to a= multi-tenant server where getting the URI 'wrong' means sending the respon= se to the wrong place.

 


Again, this is a general issue with redire= ctions. I believe the right way to address this is via future profiles of t= he protocol, based on actual deployment experience. We have failed over two= years to reach consensus on even a basic set of required comparison rules.= Too late to reopen that now, but if you have a proposal, publishing a prof= ile would be very helpful.

 &n= bsp;            = ;  Propose that the only way to handle all of these rather nasty issue= s is by mandating that section 6.2.1 of RFC 3986 MUST be used by the author= ization server when determining if a submitted redirection URI matches a registered value. This explicitly precludes the use of 'pref= ix' matching and it explicitly precludes having extra query parameters. If = the client needs to encode state information than it can use the dedicated = state variable. This is the simplest possible approach and therefore the one least likely to be screwed up by a= uthorization servers and therefore least likely to introduce security holes= . Please note that this proposal requires changes in multiple places in the= spec, including but possibly not limited to sections 3.1.2, 3.1.2.2 and 3.1.2.3.

 


-1. OAuth 2.0 is= an extremely extensible framework which will be profiled by every implemen= tation. I'm hoping for industry best practices to emerge but beyond that, w= e are not likely to agree on this. I find 3986 6.2.1 to be perfectly accept= able for comparing two absolute HTTP(S) URIs, but it will fail when allowin= g partial registration or custom URI schemes.

We c= an recommend string comparison but that's as far as we can go at this point= . If the WG suddenly endorses making such a dramatic change, I will not arg= ue against it, but it is far too late IMO.

EHL


=

 

= --_000_CA697D2617C7Deranhueniversecom_-- From eran@hueniverse.com Thu Aug 11 13:06:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FED11E8092 for ; Thu, 11 Aug 2011 13:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGLQb-Bg17PA for ; Thu, 11 Aug 2011 13:06:37 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id D283F11E8091 for ; Thu, 11 Aug 2011 13:06:36 -0700 (PDT) Received: (qmail 12113 invoked from network); 11 Aug 2011 20:06:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 20:06:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 11 Aug 2011 13:06:46 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , "OAuth WG (oauth@ietf.org)" Date: Thu, 11 Aug 2011 13:06:39 -0700 Thread-Topic: [OAUTH-WG] State Size Thread-Index: AcxYYjLPGfCfQiSgRTGMNgIsAZGXow== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA69838C17CB7eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] State Size X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:06:37 -0000 --_000_CA69838C17CB7eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No objection, but in practice, this isn't very helpful. We can note the gen= eral practical boundaries which will warn the server to accept a minimum si= ze. EHL From: Anthony Nadalin > Date: Thu, 11 Aug 2011 10:34:26 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] State Size The spec states in multiple places that servers control how big authorizati= on and other codes are so clients can't be sure how much space they will ha= ve in URIs. How can anyone design a client that is intended to work with mu= ltiple authorization servers if they have no clue how big their state can b= e? Are they supposed to re-write their state system every time they run int= o a protected resource that wants to use a bigger auth code then the client= has expected them to? We have to give client developers some kind of guida= nce they can use to let them know what is a 'safe' size for their state so = they can successfully implement with all authorization servers. Recommendat= ion is to say something like =96 =93we assume URIs can be at least 2Kb and= that the total client provided values (e.g. the base redirect URI plus the= state value) are no more than 1K.=94 --_000_CA69838C17CB7eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
No objection, but in practice, = this isn't very helpful. We can note the general practical boundaries which= will warn the server to accept a minimum size.

EH= L



From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thu, 11 Aug 2011 10:34:26 -0700
To: "OAuth WG (= oauth@ietf.org)" <oauth@ietf.= org>
Subject: [OAUTH-WG]= State Size

The spec sta= tes in multiple places that servers control how big authorization and other= codes are so clients can't be sure how much space they will have in URIs. = How can anyone design a client that is intended to work with multiple autho= rization servers if they have no clue how big their state can be? Are they supposed= to re-write their state system every time they run into a protected resour= ce that wants to use a bigger auth code then the client has expected them t= o? We have to give client developers some kind of guidance they can use to let them know what is a 'safe' size = for their state so they can successfully implement with all authorization s= ervers. Recommendation is to  say something like =96 =93we assume URIs= can be at least 2Kb and that the total client provided values (e.g. the base redirect URI plus the state value) are no m= ore than 1K.=94

= --_000_CA69838C17CB7eranhueniversecom_-- From dick.hardt@gmail.com Thu Aug 11 13:24:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A43121F8B1C for ; Thu, 11 Aug 2011 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKOkVtE0QnU3 for ; Thu, 11 Aug 2011 13:24:50 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF5521F8B02 for ; Thu, 11 Aug 2011 13:24:50 -0700 (PDT) Received: by iye1 with SMTP id 1so588998iye.27 for ; Thu, 11 Aug 2011 13:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=ECCC6I5RaDL5C0hGqAwF73ZXO8acoCd+E0C6TC36Glk=; b=DC6btfGIcHEzLxMS4xBU4mHDmiNaqSInT9VOmISbhAzz9Pv7mcMjrV4AUwqLN7I1qL vXvqqdFju2BMV7Z0i/BO9Sy70d6gHpeCkvW/xVA/E5zmkzm/kzOCkr+k9ogHaKK6S69G yNtJ/qxLFNSNMFcu1oLQanTWcY8L0IvvBRdJE= Received: by 10.231.200.147 with SMTP id ew19mr114140ibb.79.1313094324508; Thu, 11 Aug 2011 13:25:24 -0700 (PDT) Received: from [192.168.1.47] (c-24-5-69-173.hsd1.ca.comcast.net [24.5.69.173]) by mx.google.com with ESMTPS id q4sm1730490ibb.49.2011.08.11.13.25.21 (version=SSLv3 cipher=OTHER); Thu, 11 Aug 2011 13:25:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10--220328272 From: Dick Hardt In-Reply-To: Date: Thu, 11 Aug 2011 13:25:20 -0700 Message-Id: <8ED87B37-CF6B-46F6-8D3F-C4FC3147AB2B@gmail.com> References: To: Anthony Nadalin X-Mailer: Apple Mail (2.1084) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:24:51 -0000 --Apple-Mail-10--220328272 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If it was, no one told me. On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote: > Anonymity was certainly part of the design for WRAP > =20 > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 > Sent: Thursday, August 11, 2011 12:35 PM > To: Anthony Nadalin; Dick Hardt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > =20 > Section 1.5 already covers refresh tokens. There are many use cases = for refresh tokens. They are basically a protocol feature used to make = scalability and security more flexible. Anonymity was never part of = their design, and by the nature of this protocol, is more in the domain = of the resource server (based on what information it exposes via its = API). In fact, your email if the first such suggestion of anonymity. > =20 > EHL > =20 > From: Anthony Nadalin > Date: Thu, 11 Aug 2011 11:15:28 -0700 > To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Refresh Tokens > =20 > Many reasons, but none are explained in the specification > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Thursday, August 11, 2011 10:51 AM > To: Anthony Nadalin > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > =20 > My recollection of refresh tokens was for security and revocation. > =20 > security: By having a short lived access token, a compromised access = token would limit the time an attacker would have access > =20 > revocation: if the access token is self contained, authorization can = be revoked by not issuing new access tokens. A resource does not need to = query the authorization server to see if the access token is valid.This = simplifies access token validation and makes it easier to scale and = support multiple authorization servers. There is a window of time when = an access token is valid, but authorization is revoked.=20 > =20 > =20 > =20 > On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: >=20 >=20 >=20 > Nowhere in the specification is there explanation for refresh tokens, = The reason that the Refresh token was introduced was for anonymity. The = scenario is that a client asks the user for access. The user wants to = grant the access but not tell the client the user's identity. By issuing = the refresh token as an 'identifier' for the user (as well as other = context data like the resource) it's possible now to let the client get = access without revealing anything about the user. Recommend that the = above explanation be included so developers understand why the refresh = tokens are there. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-10--220328272 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
If it was, no one told = me.

On 2011-08-11, at 12:41 PM, Anthony Nadalin = wrote:

From: Eran Hammer-Lahav = [mailto:eran@hueniverse.com] 
Sent: Thursday, August 11, 2011 = 12:35 PM
To: Anthony Nadalin; Dick = Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh = Tokens
Section 1.5 = already covers refresh tokens. There are many use cases for refresh = tokens. They are basically a protocol feature used to make scalability = and security more flexible. Anonymity was never part of their design, = and by the nature of this protocol, is more in the domain of the = resource server (based on what information it exposes via its API). In = fact, your email if the first such suggestion of = anonymity.
 
EHL
 
Many reasons, but none are = explained in the specification
From: Dick Hardt [mailto:dick.hardt@gmail.com] 
Sent: Thursday, August 11, 2011 = 10:51 AM
To: Anthony = Nadalin
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh = Tokens 
My recollection of refresh tokens was for security and = revocation.
 
security: By having a short = lived access token, a compromised access token would limit the time an = attacker would have access
revocation: if the access token is self = contained, authorization can be revoked by not issuing new access = tokens. A resource does not need to query the authorization server to = see if the access token is valid.This simplifies access token validation = and makes it easier to scale and support multiple authorization = servers.  There is a window of time when an access token is = valid, but authorization is = revoked. 
 
 
On 2011-08-11, at 10:40 AM, = Anthony Nadalin wrote:
Nowhere in the specification is there explanation for refresh = tokens, The reason that the Refresh token was introduced was for = anonymity. The scenario is that a client asks the user for access. The = user wants to grant the access but not tell the client the user's = identity. By issuing the refresh token as an 'identifier' for the user = (as well as other context data like the resource) it's possible now to = let the client get access without revealing anything about the user. = Recommend that the above explanation be included so developers = understand why the refresh tokens are there.
OAuth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:26:46 -0000 Maybe the feature was added anonymously. ;-) On 8/11/11 2:25 PM, Dick Hardt wrote: > If it was, no one told me. > > On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote: > >> Anonymity was certainly part of the design for WRAP From tonynad@microsoft.com Thu Aug 11 13:29:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CE821F8B4D for ; Thu, 11 Aug 2011 13:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYeGIJQU6Fue for ; Thu, 11 Aug 2011 13:29:57 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 43DED21F8B4C for ; Thu, 11 Aug 2011 13:29:57 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 13:30:32 -0700 Received: from DB3EHSOBE003.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 13:30:31 -0700 Received: from mail120-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 20:30:29 +0000 Received: from mail120-db3 (localhost.localdomain [127.0.0.1]) by mail120-db3-R.bigfish.com (Postfix) with ESMTP id C972610002FA for ; Thu, 11 Aug 2011 20:30:29 +0000 (UTC) X-SpamScore: -26 X-BigFish: PS-26(zz9371K936eKc85fh98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h) X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT009.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail120-db3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT009.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail120-db3 (localhost.localdomain [127.0.0.1]) by mail120-db3 (MessageSwitch) id 1313094629483292_27037; Thu, 11 Aug 2011 20:30:29 +0000 (UTC) Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.241]) by mail120-db3.bigfish.com (Postfix) with ESMTP id 6818742804E; Thu, 11 Aug 2011 20:30:29 +0000 (UTC) Received: from SN2PRD0302HT009.namprd03.prod.outlook.com (207.46.4.139) by DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 20:30:27 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT009.namprd03.prod.outlook.com ([10.27.90.204]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 20:30:26 +0000 From: Anthony Nadalin To: Dick Hardt Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYTQ8Url5GUfgWROGRaafg4jY5WAAAisuAAACFmiAAAx1sgAAALzUgAAGRxAAAACSvoA== Date: Thu, 11 Aug 2011 20:30:25 +0000 Message-ID: References: <8ED87B37-CF6B-46F6-8D3F-C4FC3147AB2B@gmail.com> In-Reply-To: <8ED87B37-CF6B-46F6-8D3F-C4FC3147AB2B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89EBESN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT009.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:29:58 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89EBESN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Could be! But a definite from Yaron. From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Thursday, August 11, 2011 1:25 PM To: Anthony Nadalin Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens If it was, no one told me. On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote: Anonymity was certainly part of the design for WRAP From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, August 11, 2011 12:35 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens Section 1.5 already covers refresh tokens. There are many use cases for ref= resh tokens. They are basically a protocol feature used to make scalability= and security more flexible. Anonymity was never part of their design, and = by the nature of this protocol, is more in the domain of the resource serve= r (based on what information it exposes via its API). In fact, your email i= f the first such suggestion of anonymity. EHL From: Anthony Nadalin > Date: Thu, 11 Aug 2011 11:15:28 -0700 To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Refresh Tokens Many reasons, but none are explained in the specification From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Thursday, August 11, 2011 10:51 AM To: Anthony Nadalin Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access token = would limit the time an attacker would have access revocation: if the access token is self contained, authorization can be rev= oked by not issuing new access tokens. A resource does not need to query th= e authorization server to see if the access token is valid.This simplifies = access token validation and makes it easier to scale and support multiple a= uthorization servers. There is a window of time when an access token is va= lid, but authorization is revoked. On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: Nowhere in the specification is there explanation for refresh tokens, The r= eason that the Refresh token was introduced was for anonymity. The scenario= is that a client asks the user for access. The user wants to grant the acc= ess but not tell the client the user's identity. By issuing the refresh tok= en as an 'identifier' for the user (as well as other context data like the = resource) it's possible now to let the client get access without revealing = anything about the user. Recommend that the above explanation be included s= o developers understand why the refresh tokens are there. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89EBESN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Could be! But a definite = from Yaron.

 <= /p>

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Thursday, August 11, 2011 1:25 PM
To: Anthony Nadalin
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

 

If it was, no one told me.

 

On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote:



Anonymity was certainly p= art of the design for WRAP

 <= /p>

 

Section 1.5 already covers = refresh tokens. There are many use cases for refresh tokens. They are basic= ally a protocol feature used to make scalability and security more flexible. Anonymity was never part of their design, and by the nature= of this protocol, is more in the domain of the resource server (based on w= hat information it exposes via its API). In fact, your email if the first s= uch suggestion of anonymity.

 

EHL

 

From: Anthony= Nadalin <tonynad@microsoft.com= >
Date: Thu, 11 Aug = 2011 11:15:28 -0700
To: Dick Hardt <= ;dick.hardt@gmail.com>
Cc: "OAuth WG= (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUT= H-WG] Refresh Tokens

 

Many reasons, but none ar= e explained in the specification

 <= /p>

From: Dick Hardt [mailto:dick.hardt@gmail.com= ] 
Sent: Thursday, Au= gust 11, 2011 10:51 AM
To: Anthony Nadali= n
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUT= H-WG] Refresh Tokens

 =

My recollection of refre= sh tokens was for security and revocation.

 =

security: By having a sh= ort lived access token, a compromised access token would limit the time an = attacker would have access

 =

revocation: if the acces= s token is self contained, authorization can be revoked by not issuing new = access tokens. A resource does not need to query the authorization server t= o see if the access token is valid.This simplifies access token validation and makes it easier to scale and suppor= t multiple authorization servers.  There is a window of time when= an access token is valid, but authorization is revoked. <= /o:p>

 =

 =

 =

On 2011-08-11, at 10:40 = AM, Anthony Nadalin wrote:





Nowhere in the specificatio= n is there explanation for refresh tokens, The reason that the Refresh toke= n was introduced was for anonymity. The scenario is that a client asks the user for access. The user wants to grant the access but = not tell the client the user's identity. By issuing the refresh token as an= 'identifier' for the user (as well as other context data like the resource= ) it's possible now to let the client get access without revealing anything about the user. Recommend that the a= bove explanation be included so developers understand why the refresh token= s are there.

_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

 =

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89EBESN2PRD0302MB137_-- From dick.hardt@gmail.com Thu Aug 11 13:43:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1BE21F8B7F for ; Thu, 11 Aug 2011 13:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jptK2zRLoffK for ; Thu, 11 Aug 2011 13:43:33 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id D47B521F8B7D for ; Thu, 11 Aug 2011 13:43:32 -0700 (PDT) Received: by yie12 with SMTP id 12so1869549yie.31 for ; Thu, 11 Aug 2011 13:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=rgYvhpPZiud1INN8GlJW0E6o8/P27q8ZFtPpfmvzbZU=; b=mormmLDbciOxXzY26wFoJG3dkcfxWW/b2hjiX7Hg4b3QxTIuFX5ZKT3cbSaRqdrW8M xIabpjjEhQi3AKouIuzz+7t0W5N/2FPqnZ/Hgdi6pmEQGV83Fql8JZaSuC34A/xSNF68 iMg0RnNdLTno76yRS/vSthCHrts61cWJVX7uk= Received: by 10.42.177.6 with SMTP id bg6mr44096icb.471.1313095446853; Thu, 11 Aug 2011 13:44:06 -0700 (PDT) Received: from [192.168.1.16] (c-24-5-69-173.hsd1.ca.comcast.net [24.5.69.173]) by mx.google.com with ESMTPS id q4sm1742479ibb.32.2011.08.11.13.44.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Aug 2011 13:44:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-30--219206263 From: Dick Hardt In-Reply-To: Date: Thu, 11 Aug 2011 13:44:02 -0700 Message-Id: <375D778D-E5D9-4261-9ABE-F69C66AA8D9C@gmail.com> References: <8ED87B37-CF6B-46F6-8D3F-C4FC3147AB2B@gmail.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1084) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:43:34 -0000 --Apple-Mail-30--219206263 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Reading over your anonymous story at at the bottom, I don't see what = difference a refresh token has over an access token. You could do the = same thing with just an access token. Am I missing something? On 2011-08-11, at 1:30 PM, Anthony Nadalin wrote: > Could be! But a definite from Yaron. > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Thursday, August 11, 2011 1:25 PM > To: Anthony Nadalin > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > =20 > If it was, no one told me. > =20 > On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote: >=20 >=20 > Anonymity was certainly part of the design for WRAP > =20 > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 > Sent: Thursday, August 11, 2011 12:35 PM > To: Anthony Nadalin; Dick Hardt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > =20 > Section 1.5 already covers refresh tokens. There are many use cases = for refresh tokens. They are basically a protocol feature used to make = scalability and security more flexible. Anonymity was never part of = their design, and by the nature of this protocol, is more in the domain = of the resource server (based on what information it exposes via its = API). In fact, your email if the first such suggestion of anonymity. > =20 > EHL > =20 > From: Anthony Nadalin > Date: Thu, 11 Aug 2011 11:15:28 -0700 > To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Refresh Tokens > =20 > Many reasons, but none are explained in the specification > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Thursday, August 11, 2011 10:51 AM > To: Anthony Nadalin > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > =20 > My recollection of refresh tokens was for security and revocation. > =20 > security: By having a short lived access token, a compromised access = token would limit the time an attacker would have access > =20 > revocation: if the access token is self contained, authorization can = be revoked by not issuing new access tokens. A resource does not need to = query the authorization server to see if the access token is valid.This = simplifies access token validation and makes it easier to scale and = support multiple authorization servers. There is a window of time when = an access token is valid, but authorization is revoked.=20 > =20 > =20 > =20 > On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: >=20 >=20 >=20 >=20 > Nowhere in the specification is there explanation for refresh tokens, = The reason that the Refresh token was introduced was for anonymity. The = scenario is that a client asks the user for access. The user wants to = grant the access but not tell the client the user's identity. By issuing = the refresh token as an 'identifier' for the user (as well as other = context data like the resource) it's possible now to let the client get = access without revealing anything about the user. Recommend that the = above explanation be included so developers understand why the refresh = tokens are there. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 --Apple-Mail-30--219206263 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Reading over your anonymous story at at the = bottom, I don't see what difference a refresh token has over an access = token. You could do the same thing with just an access token. Am I = missing something?

On 2011-08-11, at = 1:30 PM, Anthony Nadalin wrote:

Could = be! But a definite from Yaron.
From: Dick Hardt = [mailto:dick.hardt@gmail.com] 
Sent: Thursday, August 11, 2011 = 1:25 PM
To: Anthony = Nadalin
Cc: Eran Hammer-Lahav; OAuth WG = ( Re: [OAUTH-WG] Refresh = Tokens
Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Thursday, August 11, 2011 = 12:35 PM
To: Anthony Nadalin; Dick = Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh = Tokens
 
Section 1.5 already covers refresh tokens. = There are many use cases for refresh tokens. They are basically a = protocol feature used to make scalability and security more flexible. = Anonymity was never part of their design, and by the nature of this = protocol, is more in the domain of the resource server (based on what = information it exposes via its API). In fact, your email if the first = such suggestion of = anonymity.
Many reasons, but none are = explained in the specification
Dick Hardt [mailto:dick.hardt@gmail.com] 
Sent: Thursday, August 11, 2011 = 10:51 AM
To: Anthony = Nadalin
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh = Tokens
My recollection of refresh tokens was for = security and revocation.
security: By having a = short lived access token, a compromised access token would limit the = time an attacker would have = access
revocation: if the = access token is self contained, authorization can be revoked by not = issuing new access tokens. A resource does not need to query the = authorization server to see if the access token is valid.This simplifies = access token validation and makes it easier to scale and support = multiple authorization servers.  There is a window of time = when an access token is valid, but authorization is = revoked. 
On 2011-08-11, at 10:40 = AM, Anthony Nadalin wrote:
Nowhere in the specification is there = explanation for refresh tokens, The reason that the Refresh token was = introduced was for anonymity. The scenario is that a client asks the = user for access. The user wants to grant the access but not tell the = client the user's identity. By issuing the refresh token as an = 'identifier' for the user (as well as other context data like the = resource) it's possible now to let the client get access without = revealing anything about the user. Recommend that the above explanation = be included so developers understand why the refresh tokens are = there.
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:46:09 -0000 --_000_CA698D4517CCDeranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's irrelevant given WRAP does not mention anonymity or anything else ab= out refresh token not explicitly addressed already by v2. Your email is the= very first time this has been raised on this list. EHL From: Anthony Nadalin > Date: Thu, 11 Aug 2011 12:41:28 -0700 To: Eran Hammer-lahav >, Di= ck Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: RE: [OAUTH-WG] Refresh Tokens Anonymity was certainly part of the design for WRAP From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, August 11, 2011 12:35 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens Section 1.5 already covers refresh tokens. There are many use cases for ref= resh tokens. They are basically a protocol feature used to make scalability= and security more flexible. Anonymity was never part of their design, and = by the nature of this protocol, is more in the domain of the resource serve= r (based on what information it exposes via its API). In fact, your email i= f the first such suggestion of anonymity. EHL From: Anthony Nadalin > Date: Thu, 11 Aug 2011 11:15:28 -0700 To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Refresh Tokens Many reasons, but none are explained in the specification From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Thursday, August 11, 2011 10:51 AM To: Anthony Nadalin Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access token = would limit the time an attacker would have access revocation: if the access token is self contained, authorization can be rev= oked by not issuing new access tokens. A resource does not need to query th= e authorization server to see if the access token is valid.This simplifies = access token validation and makes it easier to scale and support multiple a= uthorization servers. There is a window of time when an access token is va= lid, but authorization is revoked. On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: Nowhere in the specification is there explanation for refresh tokens, The r= eason that the Refresh token was introduced was for anonymity. The scenario= is that a client asks the user for access. The user wants to grant the acc= ess but not tell the client the user's identity. By issuing the refresh tok= en as an 'identifier' for the user (as well as other context data like the = resource) it's possible now to let the client get access without revealing = anything about the user. Recommend that the above explanation be included s= o developers understand why the refresh tokens are there. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA698D4517CCDeranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
That's irrelevant given = WRAP does not mention anonymity or anything else about refresh token not ex= plicitly addressed already by v2. Your email is the very first time this ha= s been raised on this list.

EHL

From: Anthony Nadalin <<= a href=3D"mailto:tonynad@microsoft.com">tonynad@microsoft.com>
Date: Thu, 11 Aug 2011 12:41:28 -070= 0
To: Eran Hammer-lahav <eran@hueniverse.com>, Dick Hardt= <dick.hardt@gmail.com>Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Refresh Tokens

Anonymity was certainly part of the design for WRAP

 

<= div>

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony N= adalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens=

 

Section 1.5 already covers refresh token= s. There are many use cases for refresh tokens. They are basically a protoc= ol feature used to make scalability and security more flexible. Anonymity was never part of their design, and by the nature= of this protocol, is more in the domain of the resource server (based on w= hat information it exposes via its API). In fact, your email if the first s= uch suggestion of anonymity.

 

EHL

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thu, 11 Aug 2011 11:15:28= -0700
To: Dick Hardt <dick.hardt@gmail.com>
Cc: "OAuth WG (oauth@ietf.org)" <oa= uth@ietf.org>
Subject: Re: [OAUTH-WG] Refresh Tokens<= /o:p>

 

Many reasons, but none are explained in the specification

 

From:mailto:dick.hardt@gm= ail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony N= adalin
Cc: OAuth WG (oauth@ietf= .org)
Subject: Re: [OAUTH-WG] Refresh Tokens

=  

My recollection of refresh tokens was for s= ecurity and revocation.

 

security: By having a short live= d access token, a compromised access token would limit the time an attacker= would have access

<= span style=3D"color:black"> 

revocation: if the access token = is self contained, authorization can be revoked by not issuing new access t= okens. A resource does not need to query the authorization server to see if= the access token is valid.This simplifies access token validation and makes it easier to scale and suppor= t multiple authorization servers.  There is a window of time when= an access token is valid, but authorization is revoked. 

&nbs= p;

 

 

On 2011-08-11, at 10:40 AM, Anthony Nadal= in wrote:




Nowhere in the specification is there explanation for refresh t= okens, The reason that the Refresh token was introduced was for anonymity. = The scenario is that a client asks the user for access. The user wants to grant the access but = not tell the client the user's identity. By issuing the refresh token as an= 'identifier' for the user (as well as other context data like the resource= ) it's possible now to let the client get access without revealing anything about the user. Recommend that the a= bove explanation be included so developers understand why the refresh token= s are there.

=

_________________________________________= ______
OAuth mailing list
OAuth@iet= f.org
https:= //www.ietf.org/mailman/listinfo/oauth

 

--_000_CA698D4517CCDeranhueniversecom_-- From tonynad@microsoft.com Thu Aug 11 13:51:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96AB228011 for ; Thu, 11 Aug 2011 13:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x71KgRQAJsPY for ; Thu, 11 Aug 2011 13:51:30 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id C891921F8B71 for ; Thu, 11 Aug 2011 13:51:30 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 13:52:06 -0700 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 13:52:05 -0700 Received: from mail37-ch1-R.bigfish.com (216.32.181.169) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 20:51:37 +0000 Received: from mail37-ch1 (localhost.localdomain [127.0.0.1]) by mail37-ch1-R.bigfish.com (Postfix) with ESMTP id 6E5D71A601A3 for ; Thu, 11 Aug 2011 20:51:37 +0000 (UTC) X-SpamScore: -26 X-BigFish: PS-26(zz9371K936eKc85fh98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT008.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail37-ch1: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT008.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail37-ch1 (localhost.localdomain [127.0.0.1]) by mail37-ch1 (MessageSwitch) id 131309589753722_6489; Thu, 11 Aug 2011 20:51:37 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail37-ch1.bigfish.com (Postfix) with ESMTP id 09A10320064; Thu, 11 Aug 2011 20:51:37 +0000 (UTC) Received: from SN2PRD0302HT008.namprd03.prod.outlook.com (207.46.4.139) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 20:51:35 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT008.namprd03.prod.outlook.com ([10.27.90.177]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 20:51:34 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Dick Hardt Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYTQ8Url5GUfgWROGRaafg4jY5WAAAisuAAACFmiAAAx1sgAAALzUgAAJNOQAAAB4R0A== Date: Thu, 11 Aug 2011 20:51:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89F11SN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT008.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:51:32 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89F11SN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are no use cases at all in WRAP to help explain choices taken, it doe= s not matter if there were or were not previous issues raised, it is being = raised now. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, August 11, 2011 1:46 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens That's irrelevant given WRAP does not mention anonymity or anything else ab= out refresh token not explicitly addressed already by v2. Your email is the= very first time this has been raised on this list. EHL From: Anthony Nadalin > Date: Thu, 11 Aug 2011 12:41:28 -0700 To: Eran Hammer-lahav >, Di= ck Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: RE: [OAUTH-WG] Refresh Tokens Anonymity was certainly part of the design for WRAP From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, August 11, 2011 12:35 PM To: Anthony Nadalin; Dick Hardt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens Section 1.5 already covers refresh tokens. There are many use cases for ref= resh tokens. They are basically a protocol feature used to make scalability= and security more flexible. Anonymity was never part of their design, and = by the nature of this protocol, is more in the domain of the resource serve= r (based on what information it exposes via its API). In fact, your email i= f the first such suggestion of anonymity. EHL From: Anthony Nadalin > Date: Thu, 11 Aug 2011 11:15:28 -0700 To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Refresh Tokens Many reasons, but none are explained in the specification From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Thursday, August 11, 2011 10:51 AM To: Anthony Nadalin Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Refresh Tokens My recollection of refresh tokens was for security and revocation. security: By having a short lived access token, a compromised access token = would limit the time an attacker would have access revocation: if the access token is self contained, authorization can be rev= oked by not issuing new access tokens. A resource does not need to query th= e authorization server to see if the access token is valid.This simplifies = access token validation and makes it easier to scale and support multiple a= uthorization servers. There is a window of time when an access token is va= lid, but authorization is revoked. On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: Nowhere in the specification is there explanation for refresh tokens, The r= eason that the Refresh token was introduced was for anonymity. The scenario= is that a client asks the user for access. The user wants to grant the acc= ess but not tell the client the user's identity. By issuing the refresh tok= en as an 'identifier' for the user (as well as other context data like the = resource) it's possible now to let the client get access without revealing = anything about the user. Recommend that the above explanation be included s= o developers understand why the refresh tokens are there. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89F11SN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are no use cases at= all in WRAP to help explain choices taken, it does not matter if there wer= e or were not previous issues raised, it is being raised now.

 <= /p>

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens

 

That's irrelevant given WRA= P does not mention anonymity or anything else about refresh token not expli= citly addressed already by v2. Your email is the very first time this has been raised on this list.

 

EHL

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav <era= n@hueniverse.com>, Dick Hardt <dick.hardt@gmail.com>
Cc: "OAuth WG (oauth@ietf.org= )" <oauth@ietf.org> Subject: RE: [OAUTH-WG] Refresh Tokens

 

Anonymity was certainly p= art of the design for WRAP

 

From: Eran Hammer-Lahav [m= ailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oauth@ietf.org)<= br> Subject: Re: [OAUTH-WG] Refresh Tokens

 =

Section 1.5 already covers = refresh tokens. There are many use cases for refresh tokens. They are basic= ally a protocol feature used to make scalability and security more flexible. Anonymity was never part of their design, and by the nature= of this protocol, is more in the domain of the resource server (based on w= hat information it exposes via its API). In fact, your email if the first s= uch suggestion of anonymity.<= /span>

 

EHL

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt <dick.hard= t@gmail.com>
Cc: "OAuth WG (oauth@ietf.org= )" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Refresh Tokens

 

Many reasons, but none ar= e explained in the specification

 

From: Dick Hardt [mailto:= dick.hardt@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oauth@ietf.org)<= br> Subject: Re: [OAUTH-WG] Refresh Tokens

 =

My recollection of refre= sh tokens was for security and revocation.

 =

security: By having a sh= ort lived access token, a compromised access token would limit the time an = attacker would have access

 =

revocation: if the acces= s token is self contained, authorization can be revoked by not issuing new = access tokens. A resource does not need to query the authorization server t= o see if the access token is valid.This simplifies access token validation and makes it easier to scale and suppor= t multiple authorization servers.  There is a window of time when= an access token is valid, but authorization is revoked. 

 =

 =

 =

On 2011-08-11, at 10:40 = AM, Anthony Nadalin wrote:





Nowhere in the specificatio= n is there explanation for refresh tokens, The reason that the Refresh toke= n was introduced was for anonymity. The scenario is that a client asks the user for access. The user wants to grant the access but = not tell the client the user's identity. By issuing the refresh token as an= 'identifier' for the user (as well as other context data like the resource= ) it's possible now to let the client get access without revealing anything about the user. Recommend that the a= bove explanation be included so developers understand why the refresh token= s are there.

_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth<= /span>

 =

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723B89F11SN2PRD0302MB137_-- From wmills@yahoo-inc.com Thu Aug 11 13:58:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1BD21F8BAD for ; Thu, 11 Aug 2011 13:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.99 X-Spam-Level: X-Spam-Status: No, score=-16.99 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPKhJUza2NzN for ; Thu, 11 Aug 2011 13:58:03 -0700 (PDT) Received: from nm6-vm2.bullet.mail.ne1.yahoo.com (nm6-vm2.bullet.mail.ne1.yahoo.com [98.138.90.154]) by ietfa.amsl.com (Postfix) with SMTP id B8F9D21F8B8B for ; Thu, 11 Aug 2011 13:58:02 -0700 (PDT) Received: from [98.138.90.53] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 20:58:34 -0000 Received: from [98.138.88.239] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 20:58:34 -0000 Received: from [127.0.0.1] by omp1039.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 20:58:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 688052.7041.bm@omp1039.mail.ne1.yahoo.com Received: (qmail 36285 invoked by uid 60001); 11 Aug 2011 20:58:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313096314; bh=z34P7YUlRVvvGi7iKqkBVp7C+NDif7CcEtjH09nJiSw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OhgsFWvYCLxNwDbxxUHqN+WiXMvbSM92i7pOBkqP6Ho75t6YYNp4doFuiMmlBpPRUTqjfTn3MGX/9PIWwE88KO2PGsoblIa0HXg6JADABilEHEFbHyY9oywZfgt5j6N1dWA46I5bDCgCbquFUjOfDE0ghOKBzn1FlmYCjZU2J8E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=R4ucAiZI+N+/1dxGr5uRAMT4vVYMyjKYKwMr95giUMp5bQgLKWxY3E3Ml9i94vQk43cKNUBmK9ul4hjwtQwhvsyYYkS+ENg32OhS6HV8iwX6yqfyOIo3n4b5Z25xH1WkuXVCp8kV2sHtJsDEvvVE5NZl4iea7C3gu1aGqTRExAU=; X-YMail-OSG: 2EPvILYVM1mWYdvoicuiXwKKM5WvrfJJt_8hAJj9ALvfEST ucwU0c7lfbuEj6jv_7hoyjiiEugU.BGJ6CeeAx_SwdUbwlUXSKiegVLNouZN 6s9zAa37H_DzFSbVYKe_aO8.Gpx9q6U_JOLS2Gfp4zxiBw4g93FRT1yTPib0 ukqp_IviRhrkI3VSGq4bSHEhd7vcp8y19ktRfz7sVJUMSHSUwgav7waz_jbr vrFDTW03PlXEODSzxmbaKQaqEpdn.Q9ZPt9H2ZxTgG7.t8nDwt96zSPVndZe HdN8aA2q7j_0mF1Lcu4jeanw49ukgJh80Ocb5BTibUU.EPFId22UGgwEcZxf R7vlZl4cfVDZLk16bTZt4CdJBcT2tIeelUMgQDPjuK0BOMrOz9R1lRz7dYxO 7ClKsHqlZjvDi365Vy19U3sJBOE2EwNFBZW0nGFJ5SGAR Received: from [209.131.62.115] by web31811.mail.mud.yahoo.com via HTTP; Thu, 11 Aug 2011 13:58:34 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: Message-ID: <1313096314.33672.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Thu, 11 Aug 2011 13:58:34 -0700 (PDT) From: "William J. Mills" To: Anthony Nadalin , Eran Hammer-Lahav , Dick Hardt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1739596267-1313096314=:33672" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 20:58:04 -0000 --0-1739596267-1313096314=:33672 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All I'm saying is that anonymity is not unique to refresh tokens, it's true= for refresh and access tokens.=0A=0A=0A=0A________________________________= =0AFrom: Anthony Nadalin =0ATo: Eran Hammer-Lahav ; Dick Hardt =0ACc: "OAuth WG (oau= th@ietf.org)" =0ASent: Thursday, August 11, 2011 12:41 PM= =0ASubject: Re: [OAUTH-WG] Refresh Tokens=0A=0A=0A =0AAnonymity was certain= ly part of the design for WRAP=0A=A0=0AFrom:Eran Hammer-Lahav [mailto:eran@= hueniverse.com] =0ASent: Thursday, August 11, 2011 12:35 PM=0ATo: Anthony N= adalin; Dick Hardt=0ACc: OAuth WG (oauth@ietf.org)=0ASubject: Re: [OAUTH-WG= ] Refresh Tokens=0A=A0=0ASection 1.5 already covers refresh tokens. There a= re many use cases for refresh tokens. They are basically a protocol feature= used to make scalability and security more flexible. Anonymity was never p= art of their design, and by the nature of this protocol, is more in the dom= ain of the resource server (based on what information it exposes via its AP= I). In fact, your email if the first such suggestion of anonymity.=0A=A0=0A= EHL=0A=A0=0AFrom: Anthony Nadalin =0ADate: Thu, 11 A= ug 2011 11:15:28 -0700=0ATo: Dick Hardt =0ACc: "OAuth= WG (oauth@ietf.org)" =0ASubject: Re: [OAUTH-WG] Refresh To= kens=0A=A0=0AMany reasons, but none are explained in the specification=0A>= =A0=0A>From:Dick Hardt [mailto:dick.hardt@gmail.com] =0A>Sent: Thursday, Au= gust 11, 2011 10:51 AM=0A>To: Anthony Nadalin=0A>Cc: OAuth WG (oauth@ietf.o= rg)=0A>Subject: Re: [OAUTH-WG] Refresh Tokens=0A>=A0=0A>My recollection of = refresh tokens was for security and revocation.=0A>=A0=0A>security: By havi= ng a short lived access token, a compromised access token would limit the t= ime an attacker would have access=0A>=A0=0A>revocation: if the access token= is self contained, authorization can be revoked by not issuing new access = tokens. A resource does not need to query the authorization server to see i= f the access token is valid.This simplifies access token validation and mak= es it easier to scale and support multiple authorization servers.=A0=A0Ther= e is a window of time when an access token is valid, but authorization is r= evoked.=A0=0A>=A0=0A>=A0=0A>=A0=0A>On 2011-08-11, at 10:40 AM, Anthony Nada= lin wrote:=0A>=0A>=0A>=0A>=0A>Nowhere in the specification is there explana= tion for refresh tokens, The reason that the Refresh token was introduced w= as for anonymity. The scenario is that a client asks the user for access. T= he user wants to grant the access but not tell the client the user's identi= ty. By issuing the refresh token as an 'identifier' for the user (as well a= s other context data like the resource) it's possible now to let the client= get access without revealing anything about the user. Recommend that the a= bove explanation be included so developers understand why the refresh token= s are there.=0A>_______________________________________________=0A>OAuth ma= iling list=0A>OAuth@ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth= =0A>=A0=0A_______________________________________________=0AOAuth mailing l= ist=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-1739596267-1313096314=:33672 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All I'm saying is that anonymity is not unique to refresh tokens, it's tr= ue for refresh and access tokens.

<= span style=3D"font-weight:bold;">From: Anthony Nadalin <tonyn= ad@microsoft.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>; Dick Hardt <dick.hardt@= gmail.com>
Cc: "OAut= h WG (oauth@ietf.org)" <oauth@ietf.org>
Sent: Thursday, August 11, 2011 12:41 PM
Subject: Re: [OAUTH-WG] Refresh To= kens

=0A=0A =0A =0A=0A=0A =0A
=0AAnonymity was certainly part of the design for WRAP
=0A=
 
=0A
=0A
=0A
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com= ]=0A
=0ASent: Thursday, August 11, 2011 12:35 PM
=0ATo:= Anthony Nadalin; Dick Hardt
=0ACc: OAuth WG (oauth@ietf.org)
= =0ASubject: Re: [OAUTH-WG] Refresh Tokens
=0A
=0A<= /div>=0A
 
=0A
=0A
Section 1.5 already covers refresh tokens. There are many use cases for = refresh tokens. They are basically a protocol feature used to make scalabil= ity and security=0A more flexible. Anonymity was never part of their design= , and by the nature of this protocol, is more in the domain of the resource= server (based on what information it exposes via its API). In fact, your e= mail if the first such suggestion of anonymity.
=0A
=0A=0A
 
=0A
=0A
=0A
EHL =0A
=0A
=0A
 
=0A
=0A
=0A
From:=0AAnthony Nadalin <tonyna= d@microsoft.com>
=0ADate: Thu, 11 Aug 2011 11:15:28 -0700<= br>=0ATo: Dick Hardt <dic= k.hardt@gmail.com>
=0ACc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org<= /a>>
=0ASubject: Re: [OAUTH-WG] Refresh Tokens
= =0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
= Many reasons, but none are = explained in the specification =0A
 
= =0A
=0A
=0A
From: Dick Hardt [= mailto:dick.hardt@gmail.com]=0A
=0ASent: Thursday, August 11,= 2011 10:51 AM
=0ATo: Anthony Nadalin
=0ACc: OAuth WG (= oauth@ietf.org)
=0ASubject: Re: [= OAUTH-WG] Refresh Tokens
= =0A
=0A
=0A
 
=0A
My recollection of refresh tokens was for securit= y and revocation.
=0A
=0A
 
=0A
=0A
=0Asecurity: B= y having a short lived access token, a compromised access token would limit= the time an attacker would have access
=0A
=0A
=0A 
=0A
=0A
=0A
revocation: if the access token is self contained, auth= orization can be revoked by not issuing new access tokens. A resource does = not need to query the authorization server to see if the access token is va= lid.This=0A simplifies access token validation and makes it easier to scale= and support multiple authorization servers.  There is a window o= f time when an access token is valid, but authorization is revoked. 
=0A
=0A
=0A
 
=0A
=0A
 
=0A
= =0A
=0A
 
=0A
=0A
=0A
On 2011-08-11, at 10:40 AM, Anthony Nadalin= wrote:
=0A
=0A

=0A
=0A
=0A
=0A
=0A
= =0A
Nowhere in the specification is there explanation for refresh to= kens, The reason that the Refresh token was introduced was for anonymity. T= he scenario is that=0A a client asks the user for access. The user wants to= grant the access but not tell the client the user's identity. By issuing t= he refresh token as an 'identifier' for the user (as well as other context = data like the resource) it's possible now to let the client=0A get access w= ithout revealing anything about the user. Recommend that the above explanat= ion be included so developers understand why the refresh tokens are there.<= /span>
=0A
=0A
______= _________________________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Ahttps:/= /www.ietf.org/mailman/listinfo/oauth
=0A
=0A
=0A
 
=0A
=0A
=0A
= =0A
=0A=0A
=0A =0A=0A

_____________________= __________________________
OAuth mailing list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth


--0-1739596267-1313096314=:33672-- From wmills@yahoo-inc.com Thu Aug 11 14:00:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ED921F8BB5 for ; Thu, 11 Aug 2011 14:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.066 X-Spam-Level: X-Spam-Status: No, score=-17.066 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en9McIMOEuVh for ; Thu, 11 Aug 2011 14:00:20 -0700 (PDT) Received: from nm30-vm0.bullet.mail.sp2.yahoo.com (nm30-vm0.bullet.mail.sp2.yahoo.com [98.139.91.238]) by ietfa.amsl.com (Postfix) with SMTP id 5B61F21F8BB0 for ; Thu, 11 Aug 2011 14:00:20 -0700 (PDT) Received: from [98.139.91.66] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2011 21:00:50 -0000 Received: from [98.139.91.32] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2011 21:00:49 -0000 Received: from [127.0.0.1] by omp1032.mail.sp2.yahoo.com with NNFMP; 11 Aug 2011 21:00:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 873501.90304.bm@omp1032.mail.sp2.yahoo.com Received: (qmail 81937 invoked by uid 60001); 11 Aug 2011 21:00:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313096449; bh=I19awi7hlfpcUwWQweGnk4pOt8UHPKFaowcoqiMeINI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iHjifT9J0lgaJ3Ru2xW6X1SeA4055TqmC8T49vrVpTDub9xKQ0/mIoEOVEiAzh+Lmm0M5ucwkzFu2dCkKuO9yIK5o+eQTx7MUY+GnvRkqARhE45QXseF1ZTtb2odExX4EkrNZTFDkS/lNSya63RAjy7EDRCGY0jkfQFh8CkPTIs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=S7zrq1N498Owj2OYAmQwpSlbcAo2f1mAY/rblPedjIY8kfxyQ07KzWxmE8+sHIX2QaqMNC29VlwT3bLTSRxLjn1SMT+NO7xA7Z9nnJ7UQ23M/PhjVdZXHrfWE1uMDbGo/kBF3LcGKm0ofF3LkMIgiC0ye7B9fDgROVLk1CRTseE=; X-YMail-OSG: Zp1OYrIVM1kesGI.QVtg8rE0eA2bWwpWm3YM7n7tqptMQUg khvX1lyfapxhvEJYF6I4rQ7eoyEauMxcsMddnpHCjfQFOcuH7LP8GQ5Cb7Ta MvYyNB3wAunUccD5lJ9hJaTO1DGM6azhyWiiXdV5jqSG9EmW5muu2E_1q2z9 72wmTu004UI6f3UhyZsfykksvBr5MLWoRlDJrzZkXYU1oSxekONTvYdKP40u vU2r2F4xZH2gZhIMeCnQMRUTI6C4OOVPKkWIe2waLuX3NU3LvY2KyJdy9FsJ 4J0iqkaqTjNI6RRdOW_emZ_zXUNlU9cjzaAyr4JhewR.MBTTrViMixoPYiao sFOIEhU.VoZ8icdpEHm0X1WetIA1UpjyCFebMm2KuDfKVND09wTQyMCLDPAe W66btxCzKgJYhxc2jGc8r5Vf5pT5jYIHHu7iTNpBvbJM- Received: from [209.131.62.115] by web31804.mail.mud.yahoo.com via HTTP; Thu, 11 Aug 2011 14:00:49 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: Message-ID: <1313096449.45395.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Thu, 11 Aug 2011 14:00:49 -0700 (PDT) From: "William J. Mills" To: Anthony Nadalin , Eran Hammer-Lahav , Dick Hardt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-151922511-1313096449=:45395" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 21:00:21 -0000 --0-151922511-1313096449=:45395 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I maintain my opinion that anonymity be discussed in the security considera= tions section.=A0 For the purposes of the spec tokens are opaque strings no= t intended to be parsed by the client.=0A=0A=0A=0A_________________________= _______=0AFrom: Anthony Nadalin =0ATo: Eran Hammer-L= ahav ; Dick Hardt =0ACc: "OAuth = WG (oauth@ietf.org)" =0ASent: Thursday, August 11, 2011 1:5= 1 PM=0ASubject: Re: [OAUTH-WG] Refresh Tokens=0A=0A=0A =0AThere are no use = cases at all in WRAP to help explain choices taken, it does not matter if t= here were or were not previous issues raised, it is being raised now.=0A=A0= =0AFrom:Eran Hammer-Lahav [mailto:eran@hueniverse.com] =0ASent: Thursday, A= ugust 11, 2011 1:46 PM=0ATo: Anthony Nadalin; Dick Hardt=0ACc: OAuth WG (oa= uth@ietf.org)=0ASubject: Re: [OAUTH-WG] Refresh Tokens=0A=A0=0AThat's irrel= evant given WRAP does not mention anonymity or anything else about refresh = token not explicitly addressed already by v2. Your email is the very first = time this has been raised on this list.=0A=A0=0AEHL=0A=A0=0AFrom: Anthony N= adalin =0ADate: Thu, 11 Aug 2011 12:41:28 -0700=0ATo= : Eran Hammer-lahav , Dick Hardt =0ACc: "OAuth WG (oauth@ietf.org)" =0ASubject: RE: [OAUTH-= WG] Refresh Tokens=0A=A0=0AAnonymity was certainly part of the design for W= RAP=0A>=A0=0A>From:Eran Hammer-Lahav [mailto:eran@hueniverse.com] =0A>Sent:= Thursday, August 11, 2011 12:35 PM=0A>To: Anthony Nadalin; Dick Hardt=0A>C= c: OAuth WG (oauth@ietf.org)=0A>Subject: Re: [OAUTH-WG] Refresh Tokens=0A>= =A0=0A>Section 1.5 already covers refresh tokens. There are many use cases = for refresh tokens. They are basically a protocol feature used to make scal= ability and security more flexible. Anonymity was never part of their desig= n, and by the nature of this protocol, is more in the domain of the resourc= e server (based on what information it exposes via its API). In fact, your = email if the first such suggestion of anonymity.=0A>=A0=0A>EHL=0A>=A0=0A>Fr= om: Anthony Nadalin =0A>Date: Thu, 11 Aug 2011 11:15= :28 -0700=0A>To: Dick Hardt =0A>Cc: "OAuth WG (oauth@= ietf.org)" =0A>Subject: Re: [OAUTH-WG] Refresh Tokens=0A>= =A0=0A>Many reasons, but none are explained in the specification=0A>>=A0=0A= >>From:Dick Hardt [mailto:dick.hardt@gmail.com] =0A>>Sent: Thursday, August= 11, 2011 10:51 AM=0A>>To: Anthony Nadalin=0A>>Cc: OAuth WG (oauth@ietf.org= )=0A>>Subject: Re: [OAUTH-WG] Refresh Tokens=0A>>=A0=0A>>My recollection of= refresh tokens was for security and revocation.=0A>>=A0=0A>>security: By h= aving a short lived access token, a compromised access token would limit th= e time an attacker would have access=0A>>=A0=0A>>revocation: if the access = token is self contained, authorization can be revoked by not issuing new ac= cess tokens. A resource does not need to query the authorization server to = see if the access token is valid.This simplifies access token validation an= d makes it easier to scale and support multiple authorization servers.=A0= =A0There is a window of time when an access token is valid, but authorizati= on is revoked.=A0=0A>>=A0=0A>>=A0=0A>>=A0=0A>>On 2011-08-11, at 10:40 AM, A= nthony Nadalin wrote:=0A>>=0A>>=0A>>=0A>>=0A>>=0A>>Nowhere in the specifica= tion is there explanation for refresh tokens, The reason that the Refresh t= oken was introduced was for anonymity. The scenario is that a client asks t= he user for access. The user wants to grant the access but not tell the cli= ent the user's identity. By issuing the refresh token as an 'identifier' fo= r the user (as well as other context data like the resource) it's possible = now to let the client get access without revealing anything about the user.= Recommend that the above explanation be included so developers understand = why the refresh tokens are there.=0A>>_____________________________________= __________=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ietf.o= rg/mailman/listinfo/oauth=0A>>=A0=0A_______________________________________= ________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailm= an/listinfo/oauth --0-151922511-1313096449=:45395 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I maintain my opinion that anonymity be discussed in the security conside= rations section.  For the purposes of the spec tokens are opaque strin= gs not intended to be parsed by the client.

=
From: Anthony Nadali= n <tonynad@microsoft.com>
To= : Eran Hammer-Lahav <eran@hueniverse.com>; Dick Hardt <= dick.hardt@gmail.com>
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Sent: Thursday, August 11, 2011 1:= 51 PM
Subject: Re: [OAU= TH-WG] Refresh Tokens

=0A=0A =0A = =0A=0A=0A =0A
= =0A
There are no use cases at all in WRAP to help explain choices= taken, it does not matter if there were or were not previous issues raised= , it is being raised=0A now.
=0A
  =0A
=0A
=0A
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=0A
=0ASent: Thur= sday, August 11, 2011 1:46 PM
=0ATo: Anthony Nadalin; Dick Hardt<= br>=0ACc: OAuth WG (oauth@ietf.org)
=0ASubject: Re: [OAUTH= -WG] Refresh Tokens
=0A
=0A
=0A
 
=0A
=0A
That's irrelevant given = WRAP does not mention anonymity or anything else about refresh token not ex= plicitly addressed already by v2. Your email is the very first=0A time this= has been raised on this list.
=0A
=0A
=0A
=  
=0A
=0A
=0A
EHL
=0A
= =0A
=0A
 
=0A
=0A
=0A
From:=0AAnthony= Nadalin <tonynad@microsoft.co= m>
=0ADate: Thu, 11 Aug 2011 12:41:28 -0700
=0ATo: <= /b>Eran Hammer-lahav <eran@huenive= rse.com>, Dick Hardt <dic= k.hardt@gmail.com>
=0ACc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org<= /a>>
=0ASubject: RE: [OAUTH-WG] Refresh Tokens
= =0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
Anonymity was certainly = part of the design for WRAP =0A
 
=0A=
=0A
=0A
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=0A
=0ASent: Thursday, August= 11, 2011 12:35 PM
=0ATo: Anthony Nadalin; Dick Hardt
=0ACc= : OAuth WG (oauth@ietf.org)
=0ASu= bject: Re: [OAUTH-WG] Refresh Tokens
=0A
=0A
=0A
<= span style=3D"color:black;"> 
=0A
=0A
Section= 1.5 already covers refresh tokens. There are many use cases for refresh to= kens. They are basically a protocol feature used to make scalability and se= curity=0A more flexible. Anonymity was never part of their design, and by t= he nature of this protocol, is more in the domain of the resource server (b= ased on what information it exposes via its API). In fact, your email if th= e first such suggestion of anonymity.
=0A
=0A
=0A
 
=0A
=0A
=0A
EHL
=0A
=0A
=0A
 
=0A
=0A
=0A
From:=0AAnthony = Nadalin <tonynad@microsoft.com= >
=0ADate: Thu, 11 Aug 2011 11:15:28 -0700
=0ATo: Dick Hardt <dick.hardt@gmail.c= om>
=0ACc: "OAuth WG (oauth@ie= tf.org)" <oauth@ietf.org>
=0A<= b>Subject: Re: [OAUTH-WG] Refresh Tokens
=0A
=0A
=0A
 
=0A
=0A
=0A
=0A
=0A
Many rea= sons, but none are explained in the specification
=0A
 
=0A
=0A
=0A
From: Dick Hardt [mailto:dick.hardt@gmail.com]=0A
=0ASent: = Thursday, August 11, 2011 10:51 AM
=0ATo: Anthony Nadalin
=0A<= b>Cc: OAuth WG (oauth@ietf.org)
=0A<= b>Subject: Re: [OAUTH-WG] Refresh Tokens
=0A
=0A
=0A
 
=0A
My recollection of refresh t= okens was for security and revocation.
=0A
=0A
  =0A
=0A
=0A
security: By having a short lived access token, a compromised= access token would limit the time an attacker would have access =0A
=0A
=0A
 
=0A
=0A
=0A
revocation: if the access to= ken is self contained, authorization can be revoked by not issuing new acce= ss tokens. A resource does not need to query the authorization server to se= e if the access token is valid.This=0A simplifies access token validation a= nd makes it easier to scale and support multiple authorization servers.&nbs= p; There is a window of time when an access token is valid, but author= ization is revoked. 
=0A
=0A
=0A
 
=0A<= div>=0A
&= nbsp;
=0A
=0A
=0A
 
=0A
=0A
=0A
On 2011-08-11= , at 10:40 AM, Anthony Nadalin wrote:
=0A
=0A

=0A
=0A
= =0A
=0A
=0A
=0A
=0A
Nowhere in the specific= ation is there explanation for refresh tokens, The reason that the Refresh = token was introduced was for anonymity. The scenario is that=0A a client as= ks the user for access. The user wants to grant the access but not tell the= client the user's identity. By issuing the refresh token as an 'identifier= ' for the user (as well as other context data like the resource) it's possi= ble now to let the client=0A get access without revealing anything about th= e user. Recommend that the above explanation be included so developers unde= rstand why the refresh tokens are there.
=0A
=0A
_______________________________________= ________
=0AOAuth mailing list
=0AOAuth@i= etf.org
=0Ahttps://www.ietf.org/mailman/listinfo/oau= th
=0A
=0A
= =0A
 = ;
=0A
=0A
=0A
=0A
=0A
=0A=0A
=0A
=0A
=0A =0A=0A

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth


--0-151922511-1313096449=:45395-- From jricher@mitre.org Thu Aug 11 14:06:53 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DA621F87C3 for ; Thu, 11 Aug 2011 14:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCbgV16dSln7 for ; Thu, 11 Aug 2011 14:06:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 30ACD21F8783 for ; Thu, 11 Aug 2011 14:06:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5FE2C21B174F for ; Thu, 11 Aug 2011 17:07:24 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 57B7C21B094C for ; Thu, 11 Aug 2011 17:07:24 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.3.192.1; Thu, 11 Aug 2011 17:07:24 -0400 From: Justin Richer To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset="UTF-8" Date: Thu, 11 Aug 2011 17:06:51 -0400 Message-ID: <1313096811.22073.96.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "Anganes, Amanda L" Subject: [OAUTH-WG] Draft 20 last call comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 21:06:53 -0000 In addition to taking another read through the document myself, I asked another developer here to give it a once over. She's never implemented an OAuth client or server, but has knowledge of what it's for. Thus, an experienced developer new to building with OAuth2 -- a key target audience for these documents. As you'll see here, most of our qualms are in the front matter of the document. The actually gritty technical implementation details are pretty solid at this point. 1.2/1.4: The term "authorization grant" remains confusing and the introduction is riddled with jargon like "intermediate credential". With the diagram in 1.2, it appears to be an explicit technological underpinning of the protocol flow instead of a general conceptual construct that is used in several different ways. Basically, what "authorization grant" *means* is not obvious within this document. Section 4 makes much more sense than the introduction text does here. Perhaps we should just replace most of 1.4 with just the introductory text to 4 (perhaps slightly expanded), and then a reference to the sub-parts of section 4 for the meat of the concept (and in the process, nix the subsections of 1.4 entirely). 1.2(B): "Provided" is wrong here (it implies a direct hand-over), and the last sentence is awkward. Suggest reword to: The client receives an authorization grant which represents the authorization granted by the resource owner. The type of authorization grant is dependent on which methods are supported by both the client and authorization server. 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token, Refresh Token 1.4.1: We probably want to mention a user agent here in the exposure risk at the end. Since that's really the problem -- the browser could steal the token, not the end user. 1.4.2: Still don't like the term "implicit". It's misleading. Even "direct authorization" would be better, though still not ideal. 1.4.5: Throw a simple reference to 8.3 here? 2: Isn't "means" generally treated as singular in instances like this? Thus "means ... is" instead of "means ... are". 2.1/2.2: The requirements (2.2) should go first in section 2. The client types are part of deciding the requirements, and the concepts flow better this way. 2.1: I like the calling out of the types of clients, it helps cement things. 2.3: Suggest renaming to "Client Identification" to parallel "Client Authentication" in 2.4 2.3: Should "... cannot be used alone" be made into a normative, as "... MUST NOT be used alone"? 2.4.2: Want to mention the MAC binding as an example here? This would parallel the OAuth2 method of signing the fetch for a request token more directly. 3. Authorization endpoint's "used to obtain authorization from" should be "used to obtain an authorization grant from", to be parallel with the token endpoint description. -- Justin From eran@hueniverse.com Thu Aug 11 15:02:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE38C21F8AAA for ; Thu, 11 Aug 2011 15:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz487hVpxIiF for ; Thu, 11 Aug 2011 15:02:12 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id B46E621F8A91 for ; Thu, 11 Aug 2011 15:02:12 -0700 (PDT) Received: (qmail 28469 invoked from network); 11 Aug 2011 22:02:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 22:02:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 11 Aug 2011 15:02:40 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin Date: Thu, 11 Aug 2011 15:02:36 -0700 Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYcmOeBvpza4I+RcqbhpMdScIkmQ== Message-ID: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3CA3D010E3C144A7BC085FA3C83F305Ahueniversecom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 22:02:14 -0000 --_000_3CA3D010E3C144A7BC085FA3C83F305Ahueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MS4gUHJvY2Vzcy13aXNlIGl0IGRvZXMuIFRoaXMgaXMgYSBicmFuZCBuZXcgY29uY2VwdCAqaGVy ZSogYW5kIHdhcyBub3QgbWVudGlvbmVkIGluIHRoZSBjaGFydGVyIG9yIGFueSB1c2UgY2FzZXMu IFRoZXJlZm9yZSwgb3V0IG9mIHNjb3BlLg0KDQoyLiBUaGUgY3VycmVudCB0ZXh0IHByb3ZpZGVz IGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIGltZW1lbnQuIE5vIG9uZSByYWlzZWQgYW4g aW1wbGVtZW50YXRpb24gaXNzdWUgb24gdGhlIGN1cnJlbnQgdGV4dC4NCg0KMy4gUmVmcmVzaCB0 b2tlbiBkbyBub3QgcHJvdmlkZSBhbm9ueW1pdHkuIEFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGJ1 dCB0aGlzIHdhcyBuZXZlciBjb25zaWRlcmVkIGluIHRoZSBkZXNpZ24uDQoNCjQuIElmIHlvdSBo YXZlIHN1Z2dlc3RlZCB0ZXh0LCBwcmVzZW50IGl0IGJlZm9yZSB0aGUgV0dMQyBpcyBvdmVyLiBJ IGFtIG5vdCBhZGRpbmcgaXNzdWVzIHRvIG15IGxpc3Qgd2l0aG91dCBzdWdnZXN0ZWQgdGV4dCBh bmQgd2cgY29uc2Vuc3VzLg0KDQpFSEwNCg0KT24gQXVnIDExLCAyMDExLCBhdCAxNzo0NCwgIkFu dGhvbnkgTmFkYWxpbiIgPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNy b3NvZnQuY29tPj4gd3JvdGU6DQoNClRoZXJlIGFyZSBubyB1c2UgY2FzZXMgYXQgYWxsIGluIFdS QVAgdG8gaGVscCBleHBsYWluIGNob2ljZXMgdGFrZW4sIGl0IGRvZXMgbm90IG1hdHRlciBpZiB0 aGVyZSB3ZXJlIG9yIHdlcmUgbm90IHByZXZpb3VzIGlzc3VlcyByYWlzZWQsIGl0IGlzIGJlaW5n IHJhaXNlZCBub3cuDQoNCkZyb206IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVu aXZlcnNlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEgMTo0NiBQTQ0KVG86 IEFudGhvbnkgTmFkYWxpbjsgRGljayBIYXJkdA0KQ2M6IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9y ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVmcmVz aCBUb2tlbnMNCg0KVGhhdCdzIGlycmVsZXZhbnQgZ2l2ZW4gV1JBUCBkb2VzIG5vdCBtZW50aW9u IGFub255bWl0eSBvciBhbnl0aGluZyBlbHNlIGFib3V0IHJlZnJlc2ggdG9rZW4gbm90IGV4cGxp Y2l0bHkgYWRkcmVzc2VkIGFscmVhZHkgYnkgdjIuIFlvdXIgZW1haWwgaXMgdGhlIHZlcnkgZmly c3QgdGltZSB0aGlzIGhhcyBiZWVuIHJhaXNlZCBvbiB0aGlzIGxpc3QuDQoNCkVITA0KDQpGcm9t OiBBbnRob255IE5hZGFsaW4gPDxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPnRvbnluYWRA bWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkRhdGU6IFRodSwg MTEgQXVnIDIwMTEgMTI6NDE6MjggLTA3MDANClRvOiBFcmFuIEhhbW1lci1sYWhhdiA8PG1haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tPmVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVl bml2ZXJzZS5jb20+PiwgRGljayBIYXJkdCA8PG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT5k aWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KQ2M6ICJP QXV0aCBXRyAoPG1haWx0bzpvYXV0aEBpZXRmLm9yZz5vYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1 dGhAaWV0Zi5vcmc+KSIgPDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9r ZW5zDQoNCkFub255bWl0eSB3YXMgY2VydGFpbmx5IHBhcnQgb2YgdGhlIGRlc2lnbiBmb3IgV1JB UA0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29t Pm1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwg MjAxMSAxMjozNSBQTQ0KVG86IEFudGhvbnkgTmFkYWxpbjsgRGljayBIYXJkdA0KQ2M6IE9BdXRo IFdHICg8bWFpbHRvOm9hdXRoQGlldGYub3JnPm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBp ZXRmLm9yZz4pDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vucw0KDQpTZWN0 aW9uIDEuNSBhbHJlYWR5IGNvdmVycyByZWZyZXNoIHRva2Vucy4gVGhlcmUgYXJlIG1hbnkgdXNl IGNhc2VzIGZvciByZWZyZXNoIHRva2Vucy4gVGhleSBhcmUgYmFzaWNhbGx5IGEgcHJvdG9jb2wg ZmVhdHVyZSB1c2VkIHRvIG1ha2Ugc2NhbGFiaWxpdHkgYW5kIHNlY3VyaXR5IG1vcmUgZmxleGli bGUuIEFub255bWl0eSB3YXMgbmV2ZXIgcGFydCBvZiB0aGVpciBkZXNpZ24sIGFuZCBieSB0aGUg bmF0dXJlIG9mIHRoaXMgcHJvdG9jb2wsIGlzIG1vcmUgaW4gdGhlIGRvbWFpbiBvZiB0aGUgcmVz b3VyY2Ugc2VydmVyIChiYXNlZCBvbiB3aGF0IGluZm9ybWF0aW9uIGl0IGV4cG9zZXMgdmlhIGl0 cyBBUEkpLiBJbiBmYWN0LCB5b3VyIGVtYWlsIGlmIHRoZSBmaXJzdCBzdWNoIHN1Z2dlc3Rpb24g b2YgYW5vbnltaXR5Lg0KDQpFSEwNCg0KRnJvbTogQW50aG9ueSBOYWRhbGluIDw8bWFpbHRvOnRv bnluYWRAbWljcm9zb2Z0LmNvbT50b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRA bWljcm9zb2Z0LmNvbT4+DQpEYXRlOiBUaHUsIDExIEF1ZyAyMDExIDExOjE1OjI4IC0wNzAwDQpU bzogRGljayBIYXJkdCA8PG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT5kaWNrLmhhcmR0QGdt YWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KQ2M6ICJPQXV0aCBXRyAoPG1h aWx0bzpvYXV0aEBpZXRmLm9yZz5vYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ KSIgPDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGll dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zDQoNCk1hbnkg cmVhc29ucywgYnV0IG5vbmUgYXJlIGV4cGxhaW5lZCBpbiB0aGUgc3BlY2lmaWNhdGlvbg0KDQpG cm9tOiBEaWNrIEhhcmR0IFs8bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPm1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEgMTA6NTEg QU0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBPQXV0aCBXRyAoPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz5vYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnMNCg0KTXkgcmVjb2xsZWN0aW9uIG9mIHJlZnJlc2gg dG9rZW5zIHdhcyBmb3Igc2VjdXJpdHkgYW5kIHJldm9jYXRpb24uDQoNCnNlY3VyaXR5OiBCeSBo YXZpbmcgYSBzaG9ydCBsaXZlZCBhY2Nlc3MgdG9rZW4sIGEgY29tcHJvbWlzZWQgYWNjZXNzIHRv a2VuIHdvdWxkIGxpbWl0IHRoZSB0aW1lIGFuIGF0dGFja2VyIHdvdWxkIGhhdmUgYWNjZXNzDQoN CnJldm9jYXRpb246IGlmIHRoZSBhY2Nlc3MgdG9rZW4gaXMgc2VsZiBjb250YWluZWQsIGF1dGhv cml6YXRpb24gY2FuIGJlIHJldm9rZWQgYnkgbm90IGlzc3VpbmcgbmV3IGFjY2VzcyB0b2tlbnMu IEEgcmVzb3VyY2UgZG9lcyBub3QgbmVlZCB0byBxdWVyeSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgdG8gc2VlIGlmIHRoZSBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQuVGhpcyBzaW1wbGlmaWVzIGFj Y2VzcyB0b2tlbiB2YWxpZGF0aW9uIGFuZCBtYWtlcyBpdCBlYXNpZXIgdG8gc2NhbGUgYW5kIHN1 cHBvcnQgbXVsdGlwbGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzLiAgVGhlcmUgaXMgYSB3aW5kb3cg b2YgdGltZSB3aGVuIGFuIGFjY2VzcyB0b2tlbiBpcyB2YWxpZCwgYnV0IGF1dGhvcml6YXRpb24g aXMgcmV2b2tlZC4NCg0KDQoNCk9uIDIwMTEtMDgtMTEsIGF0IDEwOjQwIEFNLCBBbnRob255IE5h ZGFsaW4gd3JvdGU6DQoNCg0KDQoNCk5vd2hlcmUgaW4gdGhlIHNwZWNpZmljYXRpb24gaXMgdGhl cmUgZXhwbGFuYXRpb24gZm9yIHJlZnJlc2ggdG9rZW5zLCBUaGUgcmVhc29uIHRoYXQgdGhlIFJl ZnJlc2ggdG9rZW4gd2FzIGludHJvZHVjZWQgd2FzIGZvciBhbm9ueW1pdHkuIFRoZSBzY2VuYXJp byBpcyB0aGF0IGEgY2xpZW50IGFza3MgdGhlIHVzZXIgZm9yIGFjY2Vzcy4gVGhlIHVzZXIgd2Fu dHMgdG8gZ3JhbnQgdGhlIGFjY2VzcyBidXQgbm90IHRlbGwgdGhlIGNsaWVudCB0aGUgdXNlcidz IGlkZW50aXR5LiBCeSBpc3N1aW5nIHRoZSByZWZyZXNoIHRva2VuIGFzIGFuICdpZGVudGlmaWVy JyBmb3IgdGhlIHVzZXIgKGFzIHdlbGwgYXMgb3RoZXIgY29udGV4dCBkYXRhIGxpa2UgdGhlIHJl c291cmNlKSBpdCdzIHBvc3NpYmxlIG5vdyB0byBsZXQgdGhlIGNsaWVudCBnZXQgYWNjZXNzIHdp dGhvdXQgcmV2ZWFsaW5nIGFueXRoaW5nIGFib3V0IHRoZSB1c2VyLiBSZWNvbW1lbmQgdGhhdCB0 aGUgYWJvdmUgZXhwbGFuYXRpb24gYmUgaW5jbHVkZWQgc28gZGV2ZWxvcGVycyB1bmRlcnN0YW5k IHdoeSB0aGUgcmVmcmVzaCB0b2tlbnMgYXJlIHRoZXJlLg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KPG1haWx0bzpP QXV0aEBpZXRmLm9yZz5PQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo8aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_3CA3D010E3C144A7BC085FA3C83F305Ahueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj4xLiBQcm9jZXNzLXdpc2UgaXQgZG9l cy4gVGhpcyBpcyBhIGJyYW5kIG5ldyBjb25jZXB0ICpoZXJlKiBhbmQgd2FzIG5vdCBtZW50aW9u ZWQgaW4gdGhlIGNoYXJ0ZXIgb3IgYW55IHVzZSBjYXNlcy4gVGhlcmVmb3JlLCBvdXQgb2Ygc2Nv cGUuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4yLiBUaGUgY3VycmVudCB0ZXh0IHBy b3ZpZGVzIGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIGltZW1lbnQuIE5vIG9uZSByYWlz ZWQgYW4gaW1wbGVtZW50YXRpb24gaXNzdWUgb24gdGhlIGN1cnJlbnQgdGV4dC48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PjMuIFJlZnJlc2ggdG9rZW4gZG8gbm90IHByb3ZpZGUgYW5vbnltaXR5 LiBBbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBidXQgdGhpcyB3YXMgbmV2ZXIgY29uc2lkZXJlZCBp biB0aGUgZGVzaWduLiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+NC4gSWYgeW91IGhh dmUgc3VnZ2VzdGVkIHRleHQsIHByZXNlbnQgaXQgYmVmb3JlIHRoZSBXR0xDIGlzIG92ZXIuIEkg YW0gbm90IGFkZGluZyBpc3N1ZXMgdG8gbXkgbGlzdCB3aXRob3V0IHN1Z2dlc3RlZCB0ZXh0IGFu ZCB3ZyBjb25zZW5zdXMuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5FSEw8L2Rpdj48 ZGl2Pjxicj5PbiBBdWcgMTEsIDIwMTEsIGF0IDE3OjQ0LCAiQW50aG9ueSBOYWRhbGluIiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQu Y29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxkaXY+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJl IGFyZSBubyB1c2UgY2FzZXMgYXQgYWxsIGluIFdSQVAgdG8gaGVscCBleHBsYWluIGNob2ljZXMg dGFrZW4sIGl0IGRvZXMgbm90IG1hdHRlciBpZiB0aGVyZSB3ZXJlIG9yIHdlcmUgbm90IHByZXZp b3VzIGlzc3VlcyByYWlzZWQsIGl0IGlzIGJlaW5nIHJhaXNlZA0KIG5vdy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAxOjQ2IFBNPGJyPg0K PGI+VG86PC9iPiBBbnRob255IE5hZGFsaW47IERpY2sgSGFyZHQ8YnI+DQo8Yj5DYzo8L2I+IE9B dXRoIFdHICg8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9h Pik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGF0J3MgaXJyZWxldmFudCBnaXZl biBXUkFQIGRvZXMgbm90IG1lbnRpb24gYW5vbnltaXR5IG9yIGFueXRoaW5nIGVsc2UgYWJvdXQg cmVmcmVzaCB0b2tlbiBub3QgZXhwbGljaXRseSBhZGRyZXNzZWQgYWxyZWFkeSBieSB2Mi4gWW91 ciBlbWFpbCBpcyB0aGUgdmVyeSBmaXJzdA0KIHRpbWUgdGhpcyBoYXMgYmVlbiByYWlzZWQgb24g dGhpcyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FSEw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9t Og0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFu dGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+ PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQu Y29tPC9hPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodSwgMTEgQXVnIDIwMTEgMTI6NDE6 MjggLTA3MDA8YnI+DQo8Yj5UbzogPC9iPkVyYW4gSGFtbWVyLWxhaGF2ICZsdDs8YSBocmVmPSJt YWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJz ZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+PC9hPiZndDssIERpY2sgSGFyZHQgJmx0Ozxh IGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+PGEgaHJlZj0ibWFpbHRvOmRpY2su aGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT48L2E+Jmd0Ozxicj4NCjxi PkNjOiA8L2I+Ik9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxhIGhy ZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPikiICZsdDs8 YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRm Lm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6 IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0 OjBpbiIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QW5vbnltaXR5IHdhcyBjZXJ0YWlubHkgcGFydCBvZiB0aGUgZGVzaWduIGZv ciBXUkFQPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4gRXJhbiBIYW1tZXItTGFoYXYgWzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29t Ij48YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+bWFpbHRvOmVyYW5AaHVlbml2 ZXJzZS5jb208L2E+PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDEx LCAyMDExIDEyOjM1IFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW47IERpY2sgSGFy ZHQ8YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9h Pik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TZWN0aW9uIDEuNSBh bHJlYWR5IGNvdmVycyByZWZyZXNoIHRva2Vucy4gVGhlcmUgYXJlIG1hbnkgdXNlIGNhc2VzIGZv ciByZWZyZXNoIHRva2Vucy4gVGhleSBhcmUgYmFzaWNhbGx5IGEgcHJvdG9jb2wgZmVhdHVyZSB1 c2VkIHRvIG1ha2Ugc2NhbGFiaWxpdHkgYW5kIHNlY3VyaXR5DQogbW9yZSBmbGV4aWJsZS4gQW5v bnltaXR5IHdhcyBuZXZlciBwYXJ0IG9mIHRoZWlyIGRlc2lnbiwgYW5kIGJ5IHRoZSBuYXR1cmUg b2YgdGhpcyBwcm90b2NvbCwgaXMgbW9yZSBpbiB0aGUgZG9tYWluIG9mIHRoZSByZXNvdXJjZSBz ZXJ2ZXIgKGJhc2VkIG9uIHdoYXQgaW5mb3JtYXRpb24gaXQgZXhwb3NlcyB2aWEgaXRzIEFQSSku IEluIGZhY3QsIHlvdXIgZW1haWwgaWYgdGhlIGZpcnN0IHN1Y2ggc3VnZ2VzdGlvbiBvZiBhbm9u eW1pdHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkVITDwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+QW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBt aWNyb3NvZnQuY29tIj48YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255 bmFkQG1pY3Jvc29mdC5jb208L2E+PC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1LCAxMSBB dWcgMjAxMSAxMToxNToyOCAtMDcwMDxicj4NCjxiPlRvOiA8L2I+RGljayBIYXJkdCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj48YSBocmVmPSJtYWlsdG86ZGljay5o YXJkdEBnbWFpbC5jb20iPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPjwvYT4mZ3Q7PGJyPg0KPGI+ Q2M6IDwvYj4iT0F1dGggV0cgKDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PGEgaHJl Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48L2E+KSIgJmx0Ozxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W09BVVRILVdHXSBSZWZyZXNoIFRva2Vuczwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRE RiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCIgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ TWFueSByZWFzb25zLCBidXQgbm9uZSBhcmUgZXhwbGFpbmVkIGluIHRoZSBzcGVjaWZpY2F0aW9u PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gRGlj ayBIYXJkdCBbPGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj48YSBocmVmPSJt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iPm1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbTwv YT48L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEgMTA6 NTEgQU08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbjxicj4NCjxiPkNjOjwvYj4gT0F1 dGggV0cgKDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48L2E+KTxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vuczwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ TXkgcmVjb2xsZWN0aW9uIG9mIHJlZnJlc2ggdG9rZW5zIHdhcyBmb3Igc2VjdXJpdHkgYW5kIHJl dm9jYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5zZWN1cml0eTogQnkgaGF2aW5nIGEgc2hvcnQgbGl2ZWQgYWNjZXNzIHRva2VuLCBh IGNvbXByb21pc2VkIGFjY2VzcyB0b2tlbiB3b3VsZCBsaW1pdCB0aGUgdGltZSBhbiBhdHRhY2tl ciB3b3VsZCBoYXZlIGFjY2VzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5yZXZvY2F0aW9uOiBpZiB0aGUgYWNjZXNzIHRva2Vu IGlzIHNlbGYgY29udGFpbmVkLCBhdXRob3JpemF0aW9uIGNhbiBiZSByZXZva2VkIGJ5IG5vdCBp c3N1aW5nIG5ldyBhY2Nlc3MgdG9rZW5zLiBBIHJlc291cmNlIGRvZXMgbm90IG5lZWQgdG8gcXVl cnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIHNlZSBpZiB0aGUgYWNjZXNzIHRva2VuIGlz IHZhbGlkLlRoaXMNCiBzaW1wbGlmaWVzIGFjY2VzcyB0b2tlbiB2YWxpZGF0aW9uIGFuZCBtYWtl cyBpdCBlYXNpZXIgdG8gc2NhbGUgYW5kIHN1cHBvcnQgbXVsdGlwbGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXJzLiZuYnNwOyZuYnNwO1RoZXJlIGlzIGEgd2luZG93IG9mIHRpbWUgd2hlbiBhbiBhY2Nl c3MgdG9rZW4gaXMgdmFsaWQsIGJ1dCBhdXRob3JpemF0aW9uIGlzIHJldm9rZWQuJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5PbiAyMDExLTA4LTExLCBhdCAxMDo0MCBBTSwgQW50aG9ueSBOYWRhbGluIHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Tm93aGVyZSBpbiB0aGUgc3BlY2lmaWNh dGlvbiBpcyB0aGVyZSBleHBsYW5hdGlvbiBmb3IgcmVmcmVzaCB0b2tlbnMsIFRoZSByZWFzb24g dGhhdCB0aGUgUmVmcmVzaCB0b2tlbiB3YXMgaW50cm9kdWNlZCB3YXMgZm9yIGFub255bWl0eS4g VGhlIHNjZW5hcmlvIGlzIHRoYXQNCiBhIGNsaWVudCBhc2tzIHRoZSB1c2VyIGZvciBhY2Nlc3Mu IFRoZSB1c2VyIHdhbnRzIHRvIGdyYW50IHRoZSBhY2Nlc3MgYnV0IG5vdCB0ZWxsIHRoZSBjbGll bnQgdGhlIHVzZXIncyBpZGVudGl0eS4gQnkgaXNzdWluZyB0aGUgcmVmcmVzaCB0b2tlbiBhcyBh biAnaWRlbnRpZmllcicgZm9yIHRoZSB1c2VyIChhcyB3ZWxsIGFzIG90aGVyIGNvbnRleHQgZGF0 YSBsaWtlIHRoZSByZXNvdXJjZSkgaXQncyBwb3NzaWJsZSBub3cgdG8gbGV0IHRoZSBjbGllbnQN CiBnZXQgYWNjZXNzIHdpdGhvdXQgcmV2ZWFsaW5nIGFueXRoaW5nIGFib3V0IHRoZSB1c2VyLiBS ZWNvbW1lbmQgdGhhdCB0aGUgYWJvdmUgZXhwbGFuYXRpb24gYmUgaW5jbHVkZWQgc28gZGV2ZWxv cGVycyB1bmRlcnN0YW5kIHdoeSB0aGUgcmVmcmVzaCB0b2tlbnMgYXJlIHRoZXJlLjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn Ij48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvYT48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N Cg0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_3CA3D010E3C144A7BC085FA3C83F305Ahueniversecom_-- From tonynad@microsoft.com Thu Aug 11 15:06:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E0511E8095 for ; Thu, 11 Aug 2011 15:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqsmVQid5gAT for ; Thu, 11 Aug 2011 15:06:35 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3182511E8091 for ; Thu, 11 Aug 2011 15:06:35 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 15:07:10 -0700 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 15:07:09 -0700 Received: from mail107-ch1-R.bigfish.com (216.32.181.171) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 22:07:09 +0000 Received: from mail107-ch1 (localhost.localdomain [127.0.0.1]) by mail107-ch1-R.bigfish.com (Postfix) with ESMTP id ED6731A484B7 for ; Thu, 11 Aug 2011 22:07:08 +0000 (UTC) X-SpamScore: -26 X-BigFish: PS-26(zz9371Kc89bh936eKc857h98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT011.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail107-ch1: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT011.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail107-ch1 (localhost.localdomain [127.0.0.1]) by mail107-ch1 (MessageSwitch) id 1313100428447143_16039; Thu, 11 Aug 2011 22:07:08 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail107-ch1.bigfish.com (Postfix) with ESMTP id 5EAA71080051; Thu, 11 Aug 2011 22:07:08 +0000 (UTC) Received: from SN2PRD0302HT011.namprd03.prod.outlook.com (207.46.4.139) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 22:07:05 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT011.namprd03.prod.outlook.com ([10.27.90.157]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 22:07:04 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYTQ8Url5GUfgWROGRaafg4jY5WAAAisuAAACFmiAAAx1sgAAALzUgAAJNOQAAAB4R0AACjBwAAAAbQ/A= Date: Thu, 11 Aug 2011 22:07:03 +0000 Message-ID: References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> In-Reply-To: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B8A115SN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT011.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 22:06:36 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B8A115SN2PRD0302MB137_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gcmFpc2luZyB0aGUgaXNzdWUgb24gdGhlIGN1cnJlbnQgdGV4dCwgSSBhbHJlYWR5IHBy b3ZpZGVkIHRleHQgaWYgdGhlIG9yaWdpbmFsIGFwcGVuZC4NCg0KRnJvbTogRXJhbiBIYW1tZXIt TGFoYXYgW21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3Vz dCAxMSwgMjAxMSAzOjAzIFBNDQpUbzogQW50aG9ueSBOYWRhbGluDQpDYzogRGljayBIYXJkdDsg T0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVmcmVz aCBUb2tlbnMNCg0KMS4gUHJvY2Vzcy13aXNlIGl0IGRvZXMuIFRoaXMgaXMgYSBicmFuZCBuZXcg Y29uY2VwdCAqaGVyZSogYW5kIHdhcyBub3QgbWVudGlvbmVkIGluIHRoZSBjaGFydGVyIG9yIGFu eSB1c2UgY2FzZXMuIFRoZXJlZm9yZSwgb3V0IG9mIHNjb3BlLg0KDQoyLiBUaGUgY3VycmVudCB0 ZXh0IHByb3ZpZGVzIGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIGltZW1lbnQuIE5vIG9u ZSByYWlzZWQgYW4gaW1wbGVtZW50YXRpb24gaXNzdWUgb24gdGhlIGN1cnJlbnQgdGV4dC4NCg0K My4gUmVmcmVzaCB0b2tlbiBkbyBub3QgcHJvdmlkZSBhbm9ueW1pdHkuIEFuIGltcGxlbWVudGF0 aW9uIGNvdWxkIGJ1dCB0aGlzIHdhcyBuZXZlciBjb25zaWRlcmVkIGluIHRoZSBkZXNpZ24uDQoN CjQuIElmIHlvdSBoYXZlIHN1Z2dlc3RlZCB0ZXh0LCBwcmVzZW50IGl0IGJlZm9yZSB0aGUgV0dM QyBpcyBvdmVyLiBJIGFtIG5vdCBhZGRpbmcgaXNzdWVzIHRvIG15IGxpc3Qgd2l0aG91dCBzdWdn ZXN0ZWQgdGV4dCBhbmQgd2cgY29uc2Vuc3VzLg0KDQpFSEwNCg0KT24gQXVnIDExLCAyMDExLCBh dCAxNzo0NCwgIkFudGhvbnkgTmFkYWxpbiIgPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86 dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGVyZSBhcmUgbm8gdXNlIGNhc2VzIGF0 IGFsbCBpbiBXUkFQIHRvIGhlbHAgZXhwbGFpbiBjaG9pY2VzIHRha2VuLCBpdCBkb2VzIG5vdCBt YXR0ZXIgaWYgdGhlcmUgd2VyZSBvciB3ZXJlIG5vdCBwcmV2aW91cyBpc3N1ZXMgcmFpc2VkLCBp dCBpcyBiZWluZyByYWlzZWQgbm93Lg0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb21dPG1haWx0bzpbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21d Pg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAxOjQ2IFBNDQpUbzogQW50aG9ueSBO YWRhbGluOyBEaWNrIEhhcmR0DQpDYzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnPG1haWx0bzpv YXV0aEBpZXRmLm9yZz4pDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vucw0K DQpUaGF0J3MgaXJyZWxldmFudCBnaXZlbiBXUkFQIGRvZXMgbm90IG1lbnRpb24gYW5vbnltaXR5 IG9yIGFueXRoaW5nIGVsc2UgYWJvdXQgcmVmcmVzaCB0b2tlbiBub3QgZXhwbGljaXRseSBhZGRy ZXNzZWQgYWxyZWFkeSBieSB2Mi4gWW91ciBlbWFpbCBpcyB0aGUgdmVyeSBmaXJzdCB0aW1lIHRo aXMgaGFzIGJlZW4gcmFpc2VkIG9uIHRoaXMgbGlzdC4NCg0KRUhMDQoNCkZyb206IEFudGhvbnkg TmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5j b20+Pg0KRGF0ZTogVGh1LCAxMSBBdWcgMjAxMSAxMjo0MToyOCAtMDcwMA0KVG86IEVyYW4gSGFt bWVyLWxhaGF2IDxlcmFuQGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29t Pj4sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdt YWlsLmNvbT4+DQpDYzogIk9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+KSIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBSRTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vucw0KDQpBbm9ueW1pdHkgd2FzIGNlcnRhaW5s eSBwYXJ0IG9mIHRoZSBkZXNpZ24gZm9yIFdSQVANCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYg W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwg MjAxMSAxMjozNSBQTQ0KVG86IEFudGhvbnkgTmFkYWxpbjsgRGljayBIYXJkdA0KQ2M6IE9BdXRo IFdHIChvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnMNCg0KU2VjdGlvbiAxLjUgYWxyZWFkeSBjb3ZlcnMg cmVmcmVzaCB0b2tlbnMuIFRoZXJlIGFyZSBtYW55IHVzZSBjYXNlcyBmb3IgcmVmcmVzaCB0b2tl bnMuIFRoZXkgYXJlIGJhc2ljYWxseSBhIHByb3RvY29sIGZlYXR1cmUgdXNlZCB0byBtYWtlIHNj YWxhYmlsaXR5IGFuZCBzZWN1cml0eSBtb3JlIGZsZXhpYmxlLiBBbm9ueW1pdHkgd2FzIG5ldmVy IHBhcnQgb2YgdGhlaXIgZGVzaWduLCBhbmQgYnkgdGhlIG5hdHVyZSBvZiB0aGlzIHByb3RvY29s LCBpcyBtb3JlIGluIHRoZSBkb21haW4gb2YgdGhlIHJlc291cmNlIHNlcnZlciAoYmFzZWQgb24g d2hhdCBpbmZvcm1hdGlvbiBpdCBleHBvc2VzIHZpYSBpdHMgQVBJKS4gSW4gZmFjdCwgeW91ciBl bWFpbCBpZiB0aGUgZmlyc3Qgc3VjaCBzdWdnZXN0aW9uIG9mIGFub255bWl0eS4NCg0KRUhMDQoN CkZyb206IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255 bmFkQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogVGh1LCAxMSBBdWcgMjAxMSAxMToxNToyOCAtMDcw MA0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0 QGdtYWlsLmNvbT4+DQpDYzogIk9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA aWV0Zi5vcmc+KSIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vucw0KDQpNYW55IHJlYXNvbnMsIGJ1dCBu b25lIGFyZSBleHBsYWluZWQgaW4gdGhlIHNwZWNpZmljYXRpb24NCg0KRnJvbTogRGljayBIYXJk dCBbbWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAx MSwgMjAxMSAxMDo1MSBBTQ0KVG86IEFudGhvbnkgTmFkYWxpbg0KQ2M6IE9BdXRoIFdHIChvYXV0 aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1X R10gUmVmcmVzaCBUb2tlbnMNCg0KTXkgcmVjb2xsZWN0aW9uIG9mIHJlZnJlc2ggdG9rZW5zIHdh cyBmb3Igc2VjdXJpdHkgYW5kIHJldm9jYXRpb24uDQoNCnNlY3VyaXR5OiBCeSBoYXZpbmcgYSBz aG9ydCBsaXZlZCBhY2Nlc3MgdG9rZW4sIGEgY29tcHJvbWlzZWQgYWNjZXNzIHRva2VuIHdvdWxk IGxpbWl0IHRoZSB0aW1lIGFuIGF0dGFja2VyIHdvdWxkIGhhdmUgYWNjZXNzDQoNCnJldm9jYXRp b246IGlmIHRoZSBhY2Nlc3MgdG9rZW4gaXMgc2VsZiBjb250YWluZWQsIGF1dGhvcml6YXRpb24g Y2FuIGJlIHJldm9rZWQgYnkgbm90IGlzc3VpbmcgbmV3IGFjY2VzcyB0b2tlbnMuIEEgcmVzb3Vy Y2UgZG9lcyBub3QgbmVlZCB0byBxdWVyeSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gc2Vl IGlmIHRoZSBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQuVGhpcyBzaW1wbGlmaWVzIGFjY2VzcyB0b2tl biB2YWxpZGF0aW9uIGFuZCBtYWtlcyBpdCBlYXNpZXIgdG8gc2NhbGUgYW5kIHN1cHBvcnQgbXVs dGlwbGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzLiAgVGhlcmUgaXMgYSB3aW5kb3cgb2YgdGltZSB3 aGVuIGFuIGFjY2VzcyB0b2tlbiBpcyB2YWxpZCwgYnV0IGF1dGhvcml6YXRpb24gaXMgcmV2b2tl ZC4NCg0KDQoNCk9uIDIwMTEtMDgtMTEsIGF0IDEwOjQwIEFNLCBBbnRob255IE5hZGFsaW4gd3Jv dGU6DQoNCg0KDQoNCg0KTm93aGVyZSBpbiB0aGUgc3BlY2lmaWNhdGlvbiBpcyB0aGVyZSBleHBs YW5hdGlvbiBmb3IgcmVmcmVzaCB0b2tlbnMsIFRoZSByZWFzb24gdGhhdCB0aGUgUmVmcmVzaCB0 b2tlbiB3YXMgaW50cm9kdWNlZCB3YXMgZm9yIGFub255bWl0eS4gVGhlIHNjZW5hcmlvIGlzIHRo YXQgYSBjbGllbnQgYXNrcyB0aGUgdXNlciBmb3IgYWNjZXNzLiBUaGUgdXNlciB3YW50cyB0byBn cmFudCB0aGUgYWNjZXNzIGJ1dCBub3QgdGVsbCB0aGUgY2xpZW50IHRoZSB1c2VyJ3MgaWRlbnRp dHkuIEJ5IGlzc3VpbmcgdGhlIHJlZnJlc2ggdG9rZW4gYXMgYW4gJ2lkZW50aWZpZXInIGZvciB0 aGUgdXNlciAoYXMgd2VsbCBhcyBvdGhlciBjb250ZXh0IGRhdGEgbGlrZSB0aGUgcmVzb3VyY2Up IGl0J3MgcG9zc2libGUgbm93IHRvIGxldCB0aGUgY2xpZW50IGdldCBhY2Nlc3Mgd2l0aG91dCBy ZXZlYWxpbmcgYW55dGhpbmcgYWJvdXQgdGhlIHVzZXIuIFJlY29tbWVuZCB0aGF0IHRoZSBhYm92 ZSBleHBsYW5hdGlvbiBiZSBpbmNsdWRlZCBzbyBkZXZlbG9wZXJzIHVuZGVyc3RhbmQgd2h5IHRo ZSByZWZyZXNoIHRva2VucyBhcmUgdGhlcmUuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQoNCg== --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B8A115SN2PRD0302MB137_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmW0gcmFpc2luZyB0aGUgaXNzdWUg b24gdGhlIGN1cnJlbnQgdGV4dCwgSSBhbHJlYWR5IHByb3ZpZGVkIHRleHQgaWYgdGhlIG9yaWdp bmFsIGFwcGVuZC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyYW4gSGFtbWVyLUxhaGF2 IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgQXVndXN0IDExLCAyMDExIDM6MDMgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxp bjxicj4NCjxiPkNjOjwvYj4gRGljayBIYXJkdDsgT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKTxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2VuczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBQcm9jZXNz LXdpc2UgaXQgZG9lcy4gVGhpcyBpcyBhIGJyYW5kIG5ldyBjb25jZXB0ICpoZXJlKiBhbmQgd2Fz IG5vdCBtZW50aW9uZWQgaW4gdGhlIGNoYXJ0ZXIgb3IgYW55IHVzZSBjYXNlcy4gVGhlcmVmb3Jl LCBvdXQgb2Ygc2NvcGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjIuIFRoZSBjdXJyZW50IHRleHQgcHJvdmlkZXMgYWxsIHRoZSBp bmZvcm1hdGlvbiBuZWVkZWQgdG8gaW1lbWVudC4gTm8gb25lIHJhaXNlZCBhbiBpbXBsZW1lbnRh dGlvbiBpc3N1ZSBvbiB0aGUgY3VycmVudCB0ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBSZWZyZXNoIHRva2VuIGRvIG5vdCBwcm92 aWRlIGFub255bWl0eS4gQW4gaW1wbGVtZW50YXRpb24gY291bGQgYnV0IHRoaXMgd2FzIG5ldmVy IGNvbnNpZGVyZWQgaW4gdGhlIGRlc2lnbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4gSWYgeW91IGhhdmUgc3VnZ2VzdGVkIHRl eHQsIHByZXNlbnQgaXQgYmVmb3JlIHRoZSBXR0xDIGlzIG92ZXIuIEkgYW0gbm90IGFkZGluZyBp c3N1ZXMgdG8gbXkgbGlzdCB3aXRob3V0IHN1Z2dlc3RlZCB0ZXh0IGFuZCB3ZyBjb25zZW5zdXMu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkVITDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBBdWcgMTEsIDIwMTEsIGF0 IDE3OjQ0LCAmcXVvdDtBbnRob255IE5hZGFsaW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0 b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUg YXJlIG5vIHVzZSBjYXNlcyBhdCBhbGwgaW4gV1JBUCB0byBoZWxwIGV4cGxhaW4gY2hvaWNlcyB0 YWtlbiwgaXQgZG9lcyBub3QgbWF0dGVyIGlmIHRoZXJlDQogd2VyZSBvciB3ZXJlIG5vdCBwcmV2 aW91cyBpc3N1ZXMgcmFpc2VkLCBpdCBpcyBiZWluZyByYWlzZWQgbm93Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBFcmFuIEhhbW1lci1MYWhhdg0KPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86ZXJh bkBodWVuaXZlcnNlLmNvbV0iPlttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV08L2E+IDxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDExIDE6NDYgUE08YnI+DQo8Yj5U bzo8L2I+IEFudGhvbnkgTmFkYWxpbjsgRGljayBIYXJkdDxicj4NCjxiPkNjOjwvYj4gT0F1dGgg V0cgKDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+KTxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vuczwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGF0J3MgaXJyZWxldmFudCBnaXZl biBXUkFQIGRvZXMgbm90IG1lbnRpb24gYW5vbnltaXR5IG9yIGFueXRoaW5nIGVsc2UgYWJvdXQg cmVmcmVzaCB0b2tlbiBub3QgZXhwbGljaXRseQ0KIGFkZHJlc3NlZCBhbHJlYWR5IGJ5IHYyLiBZ b3VyIGVtYWlsIGlzIHRoZSB2ZXJ5IGZpcnN0IHRpbWUgdGhpcyBoYXMgYmVlbiByYWlzZWQgb24g dGhpcyBsaXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RUhMPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+QW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3Nv ZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5U aHUsIDExIEF1ZyAyMDExIDEyOjQxOjI4IC0wNzAwPGJyPg0KPGI+VG86IDwvYj5FcmFuIEhhbW1l ci1sYWhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVl bml2ZXJzZS5jb208L2E+Jmd0OywgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2su aGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj4mcXVvdDtPQXV0aCBXRyAoPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0 aEBpZXRmLm9yZzwvYT4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci Pm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFtPQVVUSC1X R10gUmVmcmVzaCBUb2tlbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Bbm9ueW1pdHkgd2Fz IGNlcnRhaW5seSBwYXJ0IG9mIHRoZSBkZXNpZ24gZm9yIFdSQVA8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gRXJhbg0KIEhhbW1lci1MYWhhdiBbPGEgaHJl Zj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPm1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDExIDEyOjM1 IFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW47IERpY2sgSGFyZHQ8YnI+DQo8Yj5D Yzo8L2I+IE9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGll dGYub3JnPC9hPik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBU b2tlbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U2VjdGlvbiAxLjUgYWxyZWFkeSBjb3ZlcnMgcmVmcmVz aCB0b2tlbnMuIFRoZXJlIGFyZSBtYW55IHVzZSBjYXNlcyBmb3IgcmVmcmVzaCB0b2tlbnMuIFRo ZXkgYXJlIGJhc2ljYWxseQ0KIGEgcHJvdG9jb2wgZmVhdHVyZSB1c2VkIHRvIG1ha2Ugc2NhbGFi aWxpdHkgYW5kIHNlY3VyaXR5IG1vcmUgZmxleGlibGUuIEFub255bWl0eSB3YXMgbmV2ZXIgcGFy dCBvZiB0aGVpciBkZXNpZ24sIGFuZCBieSB0aGUgbmF0dXJlIG9mIHRoaXMgcHJvdG9jb2wsIGlz IG1vcmUgaW4gdGhlIGRvbWFpbiBvZiB0aGUgcmVzb3VyY2Ugc2VydmVyIChiYXNlZCBvbiB3aGF0 IGluZm9ybWF0aW9uIGl0IGV4cG9zZXMgdmlhIGl0cyBBUEkpLiBJbiBmYWN0LA0KIHlvdXIgZW1h aWwgaWYgdGhlIGZpcnN0IHN1Y2ggc3VnZ2VzdGlvbiBvZiBhbm9ueW1pdHkuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FSEw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbnRob255IE5hZGFsaW4g Jmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9z b2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodSwgMTEgQXVnIDIwMTEgMTE6MTU6 MjggLTA3MDA8YnI+DQo8Yj5UbzogPC9iPkRpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxi PkNjOiA8L2I+JnF1b3Q7T0F1dGggV0cgKDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+ b2F1dGhAaWV0Zi5vcmc8L2E+KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FV VEgtV0ddIFJlZnJlc2ggVG9rZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiIGlkPSJNQUNfT1VUTE9PS19B VFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFueSByZWFz b25zLCBidXQgbm9uZSBhcmUgZXhwbGFpbmVkIGluIHRoZSBzcGVjaWZpY2F0aW9uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IERpY2sNCiBIYXJkdCBbPGEg aHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5tYWlsdG86ZGljay5oYXJkdEBnbWFp bC5jb208L2E+XSA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAx MDo1MSBBTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBP QXV0aCBXRyAoPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwv YT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TXkgcmVj b2xsZWN0aW9uIG9mIHJlZnJlc2ggdG9rZW5zIHdhcyBmb3Igc2VjdXJpdHkgYW5kIHJldm9jYXRp b24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+c2VjdXJpdHk6IEJ5IGhhdmluZyBhIHNob3J0IGxpdmVkIGFjY2VzcyB0b2tlbiwgYSBj b21wcm9taXNlZCBhY2Nlc3MgdG9rZW4gd291bGQgbGltaXQgdGhlIHRpbWUgYW4gYXR0YWNrZXIg d291bGQgaGF2ZSBhY2Nlc3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnJldm9jYXRpb246IGlmIHRoZSBhY2Nlc3MgdG9r ZW4gaXMgc2VsZiBjb250YWluZWQsIGF1dGhvcml6YXRpb24gY2FuIGJlIHJldm9rZWQgYnkgbm90 IGlzc3VpbmcgbmV3IGFjY2VzcyB0b2tlbnMuIEEgcmVzb3VyY2UgZG9lcyBub3QgbmVlZCB0byBx dWVyeSB0aGUNCiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBzZWUgaWYgdGhlIGFjY2VzcyB0b2tl biBpcyB2YWxpZC5UaGlzIHNpbXBsaWZpZXMgYWNjZXNzIHRva2VuIHZhbGlkYXRpb24gYW5kIG1h a2VzIGl0IGVhc2llciB0byBzY2FsZSBhbmQgc3VwcG9ydCBtdWx0aXBsZSBhdXRob3JpemF0aW9u IHNlcnZlcnMuJm5ic3A7Jm5ic3A7VGhlcmUgaXMgYSB3aW5kb3cgb2YgdGltZSB3aGVuIGFuIGFj Y2VzcyB0b2tlbiBpcyB2YWxpZCwgYnV0IGF1dGhvcml6YXRpb24gaXMgcmV2b2tlZC4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+T24gMjAxMS0wOC0xMSwgYXQgMTA6NDAgQU0sIEFudGhvbnkgTmFk YWxpbiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Ob3do ZXJlIGluIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHRoZXJlIGV4cGxhbmF0aW9uIGZvciByZWZyZXNo IHRva2VucywgVGhlIHJlYXNvbiB0aGF0IHRoZSBSZWZyZXNoIHRva2VuDQogd2FzIGludHJvZHVj ZWQgd2FzIGZvciBhbm9ueW1pdHkuIFRoZSBzY2VuYXJpbyBpcyB0aGF0IGEgY2xpZW50IGFza3Mg dGhlIHVzZXIgZm9yIGFjY2Vzcy4gVGhlIHVzZXIgd2FudHMgdG8gZ3JhbnQgdGhlIGFjY2VzcyBi dXQgbm90IHRlbGwgdGhlIGNsaWVudCB0aGUgdXNlcidzIGlkZW50aXR5LiBCeSBpc3N1aW5nIHRo ZSByZWZyZXNoIHRva2VuIGFzIGFuICdpZGVudGlmaWVyJyBmb3IgdGhlIHVzZXIgKGFzIHdlbGwg YXMgb3RoZXIgY29udGV4dA0KIGRhdGEgbGlrZSB0aGUgcmVzb3VyY2UpIGl0J3MgcG9zc2libGUg bm93IHRvIGxldCB0aGUgY2xpZW50IGdldCBhY2Nlc3Mgd2l0aG91dCByZXZlYWxpbmcgYW55dGhp bmcgYWJvdXQgdGhlIHVzZXIuIFJlY29tbWVuZCB0aGF0IHRoZSBhYm92ZSBleHBsYW5hdGlvbiBi ZSBpbmNsdWRlZCBzbyBkZXZlbG9wZXJzIHVuZGVyc3RhbmQgd2h5IHRoZSByZWZyZXNoIHRva2Vu cyBhcmUgdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B8A115SN2PRD0302MB137_-- From eran@hueniverse.com Thu Aug 11 15:07:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D2221F8AA8 for ; Thu, 11 Aug 2011 15:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngh-LT3tDt4a for ; Thu, 11 Aug 2011 15:07:19 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id BE90921F8A96 for ; Thu, 11 Aug 2011 15:07:19 -0700 (PDT) Received: (qmail 19672 invoked from network); 11 Aug 2011 22:07:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 22:07:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 11 Aug 2011 15:07:41 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Thu, 11 Aug 2011 15:07:37 -0700 Thread-Topic: Editor's Note Thread-Index: AcxYcxZ5+Cuwg1AZSjidWRjvqmsZqg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Editor's Note X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 22:07:20 -0000 If you are going to post LC comments, please make sure every comment includ= es suggested text. It is too late to raise open ended questions with specif= ic change proposal. Also, please don't post comments on behalf of others wi= thout proper attribution and making sure they read the note well.=20 EHL= From eran@hueniverse.com Thu Aug 11 15:38:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71C821F8B48 for ; Thu, 11 Aug 2011 15:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLEoJQuY1HFv for ; Thu, 11 Aug 2011 15:38:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 866B121F8B45 for ; Thu, 11 Aug 2011 15:38:07 -0700 (PDT) Received: (qmail 21880 invoked from network); 11 Aug 2011 22:38:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 22:38:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 11 Aug 2011 15:38:36 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin Date: Thu, 11 Aug 2011 15:38:31 -0700 Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYd2g1im5udHepRQ6hQzCyu5j/Ww== Message-ID: <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90DA4C9C83E14D78BD6E340084B4E912hueniversecom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 22:38:08 -0000 --_000_90DA4C9C83E14D78BD6E340084B4E912hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHRleHQgaXMgd3JvbmcuIFRoaXMgaXMgbm90IHdoeSByZWZyZXNoIHRva2VucyB3ZXJlIGlu dHJvZHVjZWQgKG9yaWdpbmFsbHkgYnkgWWFob28gdGhlbiBpbiBXUkFQKS4gQW5kIGlzIGFsc28g dGVjaG5pY2FsbHkgdW5mb3VuZGVkLiBSZWZyZXNoIHRva2VucyBoYXZlIG5vIHNwZWNpYWwgYW5v bnltaXR5IHByb3BlcnRpZXMuDQoNCkVITA0KDQpPbiBBdWcgMTEsIDIwMTEsIGF0IDE4OjE4LCAi QW50aG9ueSBOYWRhbGluIiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1p Y3Jvc29mdC5jb20+PiB3cm90ZToNCg0KSeKAmW0gcmFpc2luZyB0aGUgaXNzdWUgb24gdGhlIGN1 cnJlbnQgdGV4dCwgSSBhbHJlYWR5IHByb3ZpZGVkIHRleHQgaWYgdGhlIG9yaWdpbmFsIGFwcGVu ZC4NCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYgW21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29t XQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAzOjAzIFBNDQpUbzogQW50aG9ueSBO YWRhbGluDQpDYzogRGljayBIYXJkdDsgT0F1dGggV0cgKG9hdXRoQGlldGYub3JnPG1haWx0bzpv YXV0aEBpZXRmLm9yZz4pDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vucw0K DQoxLiBQcm9jZXNzLXdpc2UgaXQgZG9lcy4gVGhpcyBpcyBhIGJyYW5kIG5ldyBjb25jZXB0ICpo ZXJlKiBhbmQgd2FzIG5vdCBtZW50aW9uZWQgaW4gdGhlIGNoYXJ0ZXIgb3IgYW55IHVzZSBjYXNl cy4gVGhlcmVmb3JlLCBvdXQgb2Ygc2NvcGUuDQoNCjIuIFRoZSBjdXJyZW50IHRleHQgcHJvdmlk ZXMgYWxsIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgdG8gaW1lbWVudC4gTm8gb25lIHJhaXNlZCBh biBpbXBsZW1lbnRhdGlvbiBpc3N1ZSBvbiB0aGUgY3VycmVudCB0ZXh0Lg0KDQozLiBSZWZyZXNo IHRva2VuIGRvIG5vdCBwcm92aWRlIGFub255bWl0eS4gQW4gaW1wbGVtZW50YXRpb24gY291bGQg YnV0IHRoaXMgd2FzIG5ldmVyIGNvbnNpZGVyZWQgaW4gdGhlIGRlc2lnbi4NCg0KNC4gSWYgeW91 IGhhdmUgc3VnZ2VzdGVkIHRleHQsIHByZXNlbnQgaXQgYmVmb3JlIHRoZSBXR0xDIGlzIG92ZXIu IEkgYW0gbm90IGFkZGluZyBpc3N1ZXMgdG8gbXkgbGlzdCB3aXRob3V0IHN1Z2dlc3RlZCB0ZXh0 IGFuZCB3ZyBjb25zZW5zdXMuDQoNCkVITA0KDQpPbiBBdWcgMTEsIDIwMTEsIGF0IDE3OjQ0LCAi QW50aG9ueSBOYWRhbGluIiA8PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+dG9ueW5hZEBt aWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRoZXJl IGFyZSBubyB1c2UgY2FzZXMgYXQgYWxsIGluIFdSQVAgdG8gaGVscCBleHBsYWluIGNob2ljZXMg dGFrZW4sIGl0IGRvZXMgbm90IG1hdHRlciBpZiB0aGVyZSB3ZXJlIG9yIHdlcmUgbm90IHByZXZp b3VzIGlzc3VlcyByYWlzZWQsIGl0IGlzIGJlaW5nIHJhaXNlZCBub3cuDQoNCkZyb206IEVyYW4g SGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV08bWFpbHRvOlttYWlsdG86 ZXJhbkBodWVuaXZlcnNlLmNvbV0+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDExIDE6 NDYgUE0NClRvOiBBbnRob255IE5hZGFsaW47IERpY2sgSGFyZHQNCkNjOiBPQXV0aCBXRyAoPG1h aWx0bzpvYXV0aEBpZXRmLm9yZz5vYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnMNCg0KVGhhdCdzIGlycmVs ZXZhbnQgZ2l2ZW4gV1JBUCBkb2VzIG5vdCBtZW50aW9uIGFub255bWl0eSBvciBhbnl0aGluZyBl bHNlIGFib3V0IHJlZnJlc2ggdG9rZW4gbm90IGV4cGxpY2l0bHkgYWRkcmVzc2VkIGFscmVhZHkg YnkgdjIuIFlvdXIgZW1haWwgaXMgdGhlIHZlcnkgZmlyc3QgdGltZSB0aGlzIGhhcyBiZWVuIHJh aXNlZCBvbiB0aGlzIGxpc3QuDQoNCkVITA0KDQpGcm9tOiBBbnRob255IE5hZGFsaW4gPDxtYWls dG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPnRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9u eW5hZEBtaWNyb3NvZnQuY29tPj4NCkRhdGU6IFRodSwgMTEgQXVnIDIwMTEgMTI6NDE6MjggLTA3 MDANClRvOiBFcmFuIEhhbW1lci1sYWhhdiA8PG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPmVy YW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiwgRGljayBIYXJk dCA8PG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT5kaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWls dG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KQ2M6ICJPQXV0aCBXRyAoPG1haWx0bzpvYXV0aEBp ZXRmLm9yZz5vYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KSIgPDxtYWlsdG86 b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1 YmplY3Q6IFJFOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zDQoNCkFub255bWl0eSB3YXMgY2Vy dGFpbmx5IHBhcnQgb2YgdGhlIGRlc2lnbiBmb3IgV1JBUA0KDQpGcm9tOiBFcmFuIEhhbW1lci1M YWhhdiBbPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPm1haWx0bzplcmFuQGh1ZW5pdmVyc2Uu Y29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAxMjozNSBQTQ0KVG86IEFudGhv bnkgTmFkYWxpbjsgRGljayBIYXJkdA0KQ2M6IE9BdXRoIFdHICg8bWFpbHRvOm9hdXRoQGlldGYu b3JnPm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4pDQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBSZWZyZXNoIFRva2Vucw0KDQpTZWN0aW9uIDEuNSBhbHJlYWR5IGNvdmVycyBy ZWZyZXNoIHRva2Vucy4gVGhlcmUgYXJlIG1hbnkgdXNlIGNhc2VzIGZvciByZWZyZXNoIHRva2Vu cy4gVGhleSBhcmUgYmFzaWNhbGx5IGEgcHJvdG9jb2wgZmVhdHVyZSB1c2VkIHRvIG1ha2Ugc2Nh bGFiaWxpdHkgYW5kIHNlY3VyaXR5IG1vcmUgZmxleGlibGUuIEFub255bWl0eSB3YXMgbmV2ZXIg cGFydCBvZiB0aGVpciBkZXNpZ24sIGFuZCBieSB0aGUgbmF0dXJlIG9mIHRoaXMgcHJvdG9jb2ws IGlzIG1vcmUgaW4gdGhlIGRvbWFpbiBvZiB0aGUgcmVzb3VyY2Ugc2VydmVyIChiYXNlZCBvbiB3 aGF0IGluZm9ybWF0aW9uIGl0IGV4cG9zZXMgdmlhIGl0cyBBUEkpLiBJbiBmYWN0LCB5b3VyIGVt YWlsIGlmIHRoZSBmaXJzdCBzdWNoIHN1Z2dlc3Rpb24gb2YgYW5vbnltaXR5Lg0KDQpFSEwNCg0K RnJvbTogQW50aG9ueSBOYWRhbGluIDw8bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT50b255 bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+DQpEYXRlOiBU aHUsIDExIEF1ZyAyMDExIDExOjE1OjI4IC0wNzAwDQpUbzogRGljayBIYXJkdCA8PG1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbT5kaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20+Pg0KQ2M6ICJPQXV0aCBXRyAoPG1haWx0bzpvYXV0aEBpZXRmLm9yZz5vYXV0 aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KSIgPDxtYWlsdG86b2F1dGhAaWV0Zi5v cmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBb T0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zDQoNCk1hbnkgcmVhc29ucywgYnV0IG5vbmUgYXJlIGV4 cGxhaW5lZCBpbiB0aGUgc3BlY2lmaWNhdGlvbg0KDQpGcm9tOiBEaWNrIEhhcmR0IFs8bWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tPm1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbV0NClNlbnQ6 IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEgMTA6NTEgQU0NClRvOiBBbnRob255IE5hZGFsaW4N CkNjOiBPQXV0aCBXRyAoPG1haWx0bzpvYXV0aEBpZXRmLm9yZz5vYXV0aEBpZXRmLm9yZzxtYWls dG86b2F1dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tl bnMNCg0KTXkgcmVjb2xsZWN0aW9uIG9mIHJlZnJlc2ggdG9rZW5zIHdhcyBmb3Igc2VjdXJpdHkg YW5kIHJldm9jYXRpb24uDQoNCnNlY3VyaXR5OiBCeSBoYXZpbmcgYSBzaG9ydCBsaXZlZCBhY2Nl c3MgdG9rZW4sIGEgY29tcHJvbWlzZWQgYWNjZXNzIHRva2VuIHdvdWxkIGxpbWl0IHRoZSB0aW1l IGFuIGF0dGFja2VyIHdvdWxkIGhhdmUgYWNjZXNzDQoNCnJldm9jYXRpb246IGlmIHRoZSBhY2Nl c3MgdG9rZW4gaXMgc2VsZiBjb250YWluZWQsIGF1dGhvcml6YXRpb24gY2FuIGJlIHJldm9rZWQg Ynkgbm90IGlzc3VpbmcgbmV3IGFjY2VzcyB0b2tlbnMuIEEgcmVzb3VyY2UgZG9lcyBub3QgbmVl ZCB0byBxdWVyeSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gc2VlIGlmIHRoZSBhY2Nlc3Mg dG9rZW4gaXMgdmFsaWQuVGhpcyBzaW1wbGlmaWVzIGFjY2VzcyB0b2tlbiB2YWxpZGF0aW9uIGFu ZCBtYWtlcyBpdCBlYXNpZXIgdG8gc2NhbGUgYW5kIHN1cHBvcnQgbXVsdGlwbGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXJzLiAgVGhlcmUgaXMgYSB3aW5kb3cgb2YgdGltZSB3aGVuIGFuIGFjY2VzcyB0 b2tlbiBpcyB2YWxpZCwgYnV0IGF1dGhvcml6YXRpb24gaXMgcmV2b2tlZC4NCg0KDQoNCk9uIDIw MTEtMDgtMTEsIGF0IDEwOjQwIEFNLCBBbnRob255IE5hZGFsaW4gd3JvdGU6DQoNCg0KDQoNCg0K Tm93aGVyZSBpbiB0aGUgc3BlY2lmaWNhdGlvbiBpcyB0aGVyZSBleHBsYW5hdGlvbiBmb3IgcmVm cmVzaCB0b2tlbnMsIFRoZSByZWFzb24gdGhhdCB0aGUgUmVmcmVzaCB0b2tlbiB3YXMgaW50cm9k dWNlZCB3YXMgZm9yIGFub255bWl0eS4gVGhlIHNjZW5hcmlvIGlzIHRoYXQgYSBjbGllbnQgYXNr cyB0aGUgdXNlciBmb3IgYWNjZXNzLiBUaGUgdXNlciB3YW50cyB0byBncmFudCB0aGUgYWNjZXNz IGJ1dCBub3QgdGVsbCB0aGUgY2xpZW50IHRoZSB1c2VyJ3MgaWRlbnRpdHkuIEJ5IGlzc3Vpbmcg dGhlIHJlZnJlc2ggdG9rZW4gYXMgYW4gJ2lkZW50aWZpZXInIGZvciB0aGUgdXNlciAoYXMgd2Vs bCBhcyBvdGhlciBjb250ZXh0IGRhdGEgbGlrZSB0aGUgcmVzb3VyY2UpIGl0J3MgcG9zc2libGUg bm93IHRvIGxldCB0aGUgY2xpZW50IGdldCBhY2Nlc3Mgd2l0aG91dCByZXZlYWxpbmcgYW55dGhp bmcgYWJvdXQgdGhlIHVzZXIuIFJlY29tbWVuZCB0aGF0IHRoZSBhYm92ZSBleHBsYW5hdGlvbiBi ZSBpbmNsdWRlZCBzbyBkZXZlbG9wZXJzIHVuZGVyc3RhbmQgd2h5IHRoZSByZWZyZXNoIHRva2Vu cyBhcmUgdGhlcmUuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQo8bWFpbHRvOk9BdXRoQGlldGYub3JnPk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCjxodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0K --_000_90DA4C9C83E14D78BD6E340084B4E912hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5UaGUgdGV4dCBpcyB3cm9uZy4gVGhp cyBpcyBub3Qgd2h5IHJlZnJlc2ggdG9rZW5zIHdlcmUgaW50cm9kdWNlZCAob3JpZ2luYWxseSBi eSBZYWhvbyB0aGVuIGluIFdSQVApLiBBbmQgaXMgYWxzbyB0ZWNobmljYWxseSB1bmZvdW5kZWQu IFJlZnJlc2ggdG9rZW5zIGhhdmUgbm8gc3BlY2lhbCBhbm9ueW1pdHkgcHJvcGVydGllcy4mbmJz cDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkVITDxicj48YnI+T24gQXVnIDExLCAyMDExLCBh dCAxODoxOCwgIkFudGhvbnkgTmFkYWxpbiIgJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1p Y3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+ PC9kaXY+PGRpdj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbSByYWlzaW5nIHRoZSBpc3N1ZSBvbiB0aGUg Y3VycmVudCB0ZXh0LCBJIGFscmVhZHkgcHJvdmlkZWQgdGV4dCBpZiB0aGUgb3JpZ2luYWwgYXBw ZW5kLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRXJhbiBIYW1tZXItTGFoYXYgW21haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1 c3QgMTEsIDIwMTEgMzowMyBQTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJyPg0K PGI+Q2M6PC9iPiBEaWNrIEhhcmR0OyBPQXV0aCBXRyAoPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll dGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FV VEgtV0ddIFJlZnJlc2ggVG9rZW5zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjEuIFByb2Nlc3Mtd2lzZSBpdCBkb2VzLiBUaGlzIGlzIGEgYnJh bmQgbmV3IGNvbmNlcHQgKmhlcmUqIGFuZCB3YXMgbm90IG1lbnRpb25lZCBpbiB0aGUgY2hhcnRl ciBvciBhbnkgdXNlIGNhc2VzLiBUaGVyZWZvcmUsIG91dCBvZiBzY29wZS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gVGhlIGN1 cnJlbnQgdGV4dCBwcm92aWRlcyBhbGwgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0byBpbWVtZW50 LiBObyBvbmUgcmFpc2VkIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlIG9uIHRoZSBjdXJyZW50IHRl eHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjMuIFJlZnJlc2ggdG9rZW4gZG8gbm90IHByb3ZpZGUgYW5vbnltaXR5LiBBbiBpbXBsZW1lbnRh dGlvbiBjb3VsZCBidXQgdGhpcyB3YXMgbmV2ZXIgY29uc2lkZXJlZCBpbiB0aGUgZGVzaWduLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij40LiBJZiB5b3UgaGF2ZSBzdWdnZXN0ZWQgdGV4dCwgcHJlc2VudCBpdCBiZWZvcmUgdGhlIFdH TEMgaXMgb3Zlci4gSSBhbSBub3QgYWRkaW5nIGlzc3VlcyB0byBteSBsaXN0IHdpdGhvdXQgc3Vn Z2VzdGVkIHRleHQgYW5kIHdnIGNvbnNlbnN1cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RUhMPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCk9uIEF1ZyAxMSwgMjAxMSwgYXQgMTc6NDQsICJBbnRob255IE5hZGFsaW4iICZs dDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj48YSBocmVmPSJtYWlsdG86 dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+PC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGVyZSBhcmUgbm8gdXNlIGNhc2VzIGF0IGFsbCBpbiBXUkFQIHRvIGhlbHAgZXhwbGFpbiBjaG9p Y2VzIHRha2VuLCBpdCBkb2VzIG5vdCBtYXR0ZXIgaWYgdGhlcmUNCiB3ZXJlIG9yIHdlcmUgbm90 IHByZXZpb3VzIGlzc3VlcyByYWlzZWQsIGl0IGlzIGJlaW5nIHJhaXNlZCBub3cuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IEVyYW4gSGFtbWVyLUxhaGF2DQo8YSBocmVmPSJtYWlsdG86W21haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tXSI+W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXTwvYT4g PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEgMTo0NiBQTTxicj4N CjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluOyBEaWNrIEhhcmR0PGJyPg0KPGI+Q2M6PC9iPiBP QXV0aCBXRyAoPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86 b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjwvYT4pPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlRoYXQncyBpcnJlbGV2YW50IGdpdmVuIFdSQVAgZG9lcyBub3Qg bWVudGlvbiBhbm9ueW1pdHkgb3IgYW55dGhpbmcgZWxzZSBhYm91dCByZWZyZXNoIHRva2VuIG5v dCBleHBsaWNpdGx5DQogYWRkcmVzc2VkIGFscmVhZHkgYnkgdjIuIFlvdXIgZW1haWwgaXMgdGhl IHZlcnkgZmlyc3QgdGltZSB0aGlzIGhhcyBiZWVuIHJhaXNlZCBvbiB0aGlzIGxpc3QuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FSEw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BbnRob255IE5h ZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPjxhIGhyZWY9 Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT48 L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHUsIDExIEF1ZyAyMDExIDEyOjQxOjI4IC0wNzAw PGJyPg0KPGI+VG86IDwvYj5FcmFuIEhhbW1lci1sYWhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVy YW5AaHVlbml2ZXJzZS5jb20iPjxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5l cmFuQGh1ZW5pdmVyc2UuY29tPC9hPjwvYT4mZ3Q7LCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iPjxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdt YWlsLmNvbSI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+PC9hPiZndDs8YnI+DQo8Yj5DYzogPC9i PiJPQXV0aCBXRyAoPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjwvYT4pIiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h dXRoQGlldGYub3JnPC9hPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBbT0FVVEgt V0ddIFJlZnJlc2ggVG9rZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiIGlkPSJNQUNfT1VUTE9PS19BVFRS SUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5vbnltaXR5IHdh cyBjZXJ0YWlubHkgcGFydCBvZiB0aGUgZGVzaWduIGZvciBXUkFQPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IEVyYW4NCiBIYW1tZXItTGFoYXYgWzxhIGhy ZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj48YSBocmVmPSJtYWlsdG86ZXJhbkBodWVu aXZlcnNlLmNvbSI+bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb208L2E+PC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDExIDEyOjM1IFBNPGJyPg0KPGI+VG86 PC9iPiBBbnRob255IE5hZGFsaW47IERpY2sgSGFyZHQ8YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdH ICg8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBp ZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U2VjdGlvbiAxLjUg YWxyZWFkeSBjb3ZlcnMgcmVmcmVzaCB0b2tlbnMuIFRoZXJlIGFyZSBtYW55IHVzZSBjYXNlcyBm b3IgcmVmcmVzaCB0b2tlbnMuIFRoZXkgYXJlIGJhc2ljYWxseQ0KIGEgcHJvdG9jb2wgZmVhdHVy ZSB1c2VkIHRvIG1ha2Ugc2NhbGFiaWxpdHkgYW5kIHNlY3VyaXR5IG1vcmUgZmxleGlibGUuIEFu b255bWl0eSB3YXMgbmV2ZXIgcGFydCBvZiB0aGVpciBkZXNpZ24sIGFuZCBieSB0aGUgbmF0dXJl IG9mIHRoaXMgcHJvdG9jb2wsIGlzIG1vcmUgaW4gdGhlIGRvbWFpbiBvZiB0aGUgcmVzb3VyY2Ug c2VydmVyIChiYXNlZCBvbiB3aGF0IGluZm9ybWF0aW9uIGl0IGV4cG9zZXMgdmlhIGl0cyBBUEkp LiBJbiBmYWN0LA0KIHlvdXIgZW1haWwgaWYgdGhlIGZpcnN0IHN1Y2ggc3VnZ2VzdGlvbiBvZiBh bm9ueW1pdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FSEw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5BbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29m dC5jb20iPjxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWlj cm9zb2Z0LmNvbTwvYT48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHUsIDExIEF1ZyAyMDEx IDExOjE1OjI4IC0wNzAwPGJyPg0KPGI+VG86IDwvYj5EaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iPjxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdt YWlsLmNvbSI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+PC9hPiZndDs8YnI+DQo8Yj5DYzogPC9i PiJPQXV0aCBXRyAoPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWls dG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjwvYT4pIiAmbHQ7PGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h dXRoQGlldGYub3JnPC9hPjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgt V0ddIFJlZnJlc2ggVG9rZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiIGlkPSJNQUNfT1VUTE9PS19BVFRS SUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFueSByZWFzb25z LCBidXQgbm9uZSBhcmUgZXhwbGFpbmVkIGluIHRoZSBzcGVjaWZpY2F0aW9uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IERpY2sNCiBIYXJkdCBbPGEgaHJl Zj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj48YSBocmVmPSJtYWlsdG86ZGljay5oYXJk dEBnbWFpbC5jb20iPm1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT48L2E+XSA8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAxMDo1MSBBTTxicj4NCjxiPlRv OjwvYj4gQW50aG9ueSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBXRyAoPGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9h dXRoQGlldGYub3JnPC9hPjwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0dd IFJlZnJlc2ggVG9rZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+TXkgcmVjb2xsZWN0aW9uIG9mIHJlZnJlc2ggdG9rZW5zIHdhcyBmb3Igc2Vj dXJpdHkgYW5kIHJldm9jYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c2VjdXJpdHk6IEJ5IGhhdmluZyBhIHNob3J0IGxpdmVk IGFjY2VzcyB0b2tlbiwgYSBjb21wcm9taXNlZCBhY2Nlc3MgdG9rZW4gd291bGQgbGltaXQgdGhl IHRpbWUgYW4gYXR0YWNrZXIgd291bGQgaGF2ZSBhY2Nlc3M8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnJldm9jYXRpb246 IGlmIHRoZSBhY2Nlc3MgdG9rZW4gaXMgc2VsZiBjb250YWluZWQsIGF1dGhvcml6YXRpb24gY2Fu IGJlIHJldm9rZWQgYnkgbm90IGlzc3VpbmcgbmV3IGFjY2VzcyB0b2tlbnMuIEEgcmVzb3VyY2Ug ZG9lcyBub3QgbmVlZCB0byBxdWVyeSB0aGUNCiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBzZWUg aWYgdGhlIGFjY2VzcyB0b2tlbiBpcyB2YWxpZC5UaGlzIHNpbXBsaWZpZXMgYWNjZXNzIHRva2Vu IHZhbGlkYXRpb24gYW5kIG1ha2VzIGl0IGVhc2llciB0byBzY2FsZSBhbmQgc3VwcG9ydCBtdWx0 aXBsZSBhdXRob3JpemF0aW9uIHNlcnZlcnMuJm5ic3A7Jm5ic3A7VGhlcmUgaXMgYSB3aW5kb3cg b2YgdGltZSB3aGVuIGFuIGFjY2VzcyB0b2tlbiBpcyB2YWxpZCwgYnV0IGF1dGhvcml6YXRpb24g aXMgcmV2b2tlZC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T24gMjAxMS0wOC0xMSwgYXQgMTA6 NDAgQU0sIEFudGhvbnkgTmFkYWxpbiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5Ob3doZXJlIGluIHRoZSBzcGVjaWZpY2F0aW9uIGlzIHRoZXJlIGV4cGxh bmF0aW9uIGZvciByZWZyZXNoIHRva2VucywgVGhlIHJlYXNvbiB0aGF0IHRoZSBSZWZyZXNoIHRv a2VuDQogd2FzIGludHJvZHVjZWQgd2FzIGZvciBhbm9ueW1pdHkuIFRoZSBzY2VuYXJpbyBpcyB0 aGF0IGEgY2xpZW50IGFza3MgdGhlIHVzZXIgZm9yIGFjY2Vzcy4gVGhlIHVzZXIgd2FudHMgdG8g Z3JhbnQgdGhlIGFjY2VzcyBidXQgbm90IHRlbGwgdGhlIGNsaWVudCB0aGUgdXNlcidzIGlkZW50 aXR5LiBCeSBpc3N1aW5nIHRoZSByZWZyZXNoIHRva2VuIGFzIGFuICdpZGVudGlmaWVyJyBmb3Ig dGhlIHVzZXIgKGFzIHdlbGwgYXMgb3RoZXIgY29udGV4dA0KIGRhdGEgbGlrZSB0aGUgcmVzb3Vy Y2UpIGl0J3MgcG9zc2libGUgbm93IHRvIGxldCB0aGUgY2xpZW50IGdldCBhY2Nlc3Mgd2l0aG91 dCByZXZlYWxpbmcgYW55dGhpbmcgYWJvdXQgdGhlIHVzZXIuIFJlY29tbWVuZCB0aGF0IHRoZSBh Ym92ZSBleHBsYW5hdGlvbiBiZSBpbmNsdWRlZCBzbyBkZXZlbG9wZXJzIHVuZGVyc3RhbmQgd2h5 IHRoZSByZWZyZXNoIHRva2VucyBhcmUgdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwv YT48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L2E+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQoNCg0KPC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_90DA4C9C83E14D78BD6E340084B4E912hueniversecom_-- From tonynad@microsoft.com Thu Aug 11 15:48:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5555121F86C4 for ; Thu, 11 Aug 2011 15:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niFsKszmuITP for ; Thu, 11 Aug 2011 15:48:43 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 4A10D21F8B10 for ; Thu, 11 Aug 2011 15:48:36 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 15:49:11 -0700 Received: from VA3EHSOBE010.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 15:49:11 -0700 Received: from mail69-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Aug 2011 22:49:10 +0000 Received: from mail69-va3 (localhost.localdomain [127.0.0.1]) by mail69-va3-R.bigfish.com (Postfix) with ESMTP id 4316C117825C for ; Thu, 11 Aug 2011 22:49:09 +0000 (UTC) X-SpamScore: -26 X-BigFish: PS-26(zz9371Kc89bh936eKc857h98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail69-va3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT002.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail69-va3 (localhost.localdomain [127.0.0.1]) by mail69-va3 (MessageSwitch) id 1313102948313053_19673; Thu, 11 Aug 2011 22:49:08 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.251]) by mail69-va3.bigfish.com (Postfix) with ESMTP id E887823806D; Thu, 11 Aug 2011 22:45:47 +0000 (UTC) Received: from SN2PRD0302HT002.namprd03.prod.outlook.com (207.46.4.139) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 11 Aug 2011 22:45:43 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.250]) by SN2PRD0302HT002.namprd03.prod.outlook.com ([10.27.50.85]) with mapi id 14.01.0225.064; Thu, 11 Aug 2011 22:45:41 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYTQ8Url5GUfgWROGRaafg4jY5WAAAisuAAACFmiAAAx1sgAAALzUgAAJNOQAAAB4R0AACjBwAAAAbQ/AAASXcgAAAMjpQ Date: Thu, 11 Aug 2011 22:45:41 +0000 Message-ID: References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> In-Reply-To: <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723B8A1F6SN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 22:48:44 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B8A1F6SN2PRD0302MB137_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGlzYWdyZWUsIHRoaXMgd2FzIG91ciByYXRpb25hbCBhbmQgdGhpcyBpcyBvbmUgd2F5IGl04oCZ cyB1c2VkIHRvZGF5IHdpdGggb3VyIHNjZW5hcmlvcy4gVGhpcyBuZWVkcyB0byBiZSBhc3NpZ25l ZCBhbiBpc3N1ZS4NCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYgW21haWx0bzplcmFuQGh1ZW5p dmVyc2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAzOjM5IFBNDQpUbzog QW50aG9ueSBOYWRhbGluDQpDYzogRGljayBIYXJkdDsgT0F1dGggV0cgKG9hdXRoQGlldGYub3Jn KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnMNCg0KVGhlIHRleHQgaXMg d3JvbmcuIFRoaXMgaXMgbm90IHdoeSByZWZyZXNoIHRva2VucyB3ZXJlIGludHJvZHVjZWQgKG9y aWdpbmFsbHkgYnkgWWFob28gdGhlbiBpbiBXUkFQKS4gQW5kIGlzIGFsc28gdGVjaG5pY2FsbHkg dW5mb3VuZGVkLiBSZWZyZXNoIHRva2VucyBoYXZlIG5vIHNwZWNpYWwgYW5vbnltaXR5IHByb3Bl cnRpZXMuDQoNCkVITA0KDQpPbiBBdWcgMTEsIDIwMTEsIGF0IDE4OjE4LCAiQW50aG9ueSBOYWRh bGluIiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+ PiB3cm90ZToNCknigJltIHJhaXNpbmcgdGhlIGlzc3VlIG9uIHRoZSBjdXJyZW50IHRleHQsIEkg YWxyZWFkeSBwcm92aWRlZCB0ZXh0IGlmIHRoZSBvcmlnaW5hbCBhcHBlbmQuDQoNCkZyb206IEVy YW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV08bWFpbHRvOlttYWls dG86ZXJhbkBodWVuaXZlcnNlLmNvbV0+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDEx IDM6MDMgUE0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBEaWNrIEhhcmR0OyBPQXV0aCBXRyAo b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikNClN1YmplY3Q6IFJlOiBbT0FV VEgtV0ddIFJlZnJlc2ggVG9rZW5zDQoNCjEuIFByb2Nlc3Mtd2lzZSBpdCBkb2VzLiBUaGlzIGlz IGEgYnJhbmQgbmV3IGNvbmNlcHQgKmhlcmUqIGFuZCB3YXMgbm90IG1lbnRpb25lZCBpbiB0aGUg Y2hhcnRlciBvciBhbnkgdXNlIGNhc2VzLiBUaGVyZWZvcmUsIG91dCBvZiBzY29wZS4NCg0KMi4g VGhlIGN1cnJlbnQgdGV4dCBwcm92aWRlcyBhbGwgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0byBp bWVtZW50LiBObyBvbmUgcmFpc2VkIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlIG9uIHRoZSBjdXJy ZW50IHRleHQuDQoNCjMuIFJlZnJlc2ggdG9rZW4gZG8gbm90IHByb3ZpZGUgYW5vbnltaXR5LiBB biBpbXBsZW1lbnRhdGlvbiBjb3VsZCBidXQgdGhpcyB3YXMgbmV2ZXIgY29uc2lkZXJlZCBpbiB0 aGUgZGVzaWduLg0KDQo0LiBJZiB5b3UgaGF2ZSBzdWdnZXN0ZWQgdGV4dCwgcHJlc2VudCBpdCBi ZWZvcmUgdGhlIFdHTEMgaXMgb3Zlci4gSSBhbSBub3QgYWRkaW5nIGlzc3VlcyB0byBteSBsaXN0 IHdpdGhvdXQgc3VnZ2VzdGVkIHRleHQgYW5kIHdnIGNvbnNlbnN1cy4NCg0KRUhMDQoNCk9uIEF1 ZyAxMSwgMjAxMSwgYXQgMTc6NDQsICJBbnRob255IE5hZGFsaW4iIDx0b255bmFkQG1pY3Jvc29m dC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVGhlcmUgYXJlIG5v IHVzZSBjYXNlcyBhdCBhbGwgaW4gV1JBUCB0byBoZWxwIGV4cGxhaW4gY2hvaWNlcyB0YWtlbiwg aXQgZG9lcyBub3QgbWF0dGVyIGlmIHRoZXJlIHdlcmUgb3Igd2VyZSBub3QgcHJldmlvdXMgaXNz dWVzIHJhaXNlZCwgaXQgaXMgYmVpbmcgcmFpc2VkIG5vdy4NCg0KRnJvbTogRXJhbiBIYW1tZXIt TGFoYXYgW21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXTxtYWlsdG86W21haWx0bzplcmFuQGh1 ZW5pdmVyc2UuY29tXT4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEgMTo0NiBQTQ0K VG86IEFudGhvbnkgTmFkYWxpbjsgRGljayBIYXJkdA0KQ2M6IE9BdXRoIFdHIChvYXV0aEBpZXRm Lm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVm cmVzaCBUb2tlbnMNCg0KVGhhdCdzIGlycmVsZXZhbnQgZ2l2ZW4gV1JBUCBkb2VzIG5vdCBtZW50 aW9uIGFub255bWl0eSBvciBhbnl0aGluZyBlbHNlIGFib3V0IHJlZnJlc2ggdG9rZW4gbm90IGV4 cGxpY2l0bHkgYWRkcmVzc2VkIGFscmVhZHkgYnkgdjIuIFlvdXIgZW1haWwgaXMgdGhlIHZlcnkg Zmlyc3QgdGltZSB0aGlzIGhhcyBiZWVuIHJhaXNlZCBvbiB0aGlzIGxpc3QuDQoNCkVITA0KDQpG cm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5h ZEBtaWNyb3NvZnQuY29tPj4NCkRhdGU6IFRodSwgMTEgQXVnIDIwMTEgMTI6NDE6MjggLTA3MDAN ClRvOiBFcmFuIEhhbW1lci1sYWhhdiA8ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBo dWVuaXZlcnNlLmNvbT4+LCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KQ2M6ICJPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmc8bWFp bHRvOm9hdXRoQGlldGYub3JnPikiIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnMNCg0KQW5vbnltaXR5 IHdhcyBjZXJ0YWlubHkgcGFydCBvZiB0aGUgZGVzaWduIGZvciBXUkFQDQoNCkZyb206IEVyYW4g SGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NClNlbnQ6IFRodXJzZGF5 LCBBdWd1c3QgMTEsIDIwMTEgMTI6MzUgUE0NClRvOiBBbnRob255IE5hZGFsaW47IERpY2sgSGFy ZHQNCkNjOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikN ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zDQoNClNlY3Rpb24gMS41IGFs cmVhZHkgY292ZXJzIHJlZnJlc2ggdG9rZW5zLiBUaGVyZSBhcmUgbWFueSB1c2UgY2FzZXMgZm9y IHJlZnJlc2ggdG9rZW5zLiBUaGV5IGFyZSBiYXNpY2FsbHkgYSBwcm90b2NvbCBmZWF0dXJlIHVz ZWQgdG8gbWFrZSBzY2FsYWJpbGl0eSBhbmQgc2VjdXJpdHkgbW9yZSBmbGV4aWJsZS4gQW5vbnlt aXR5IHdhcyBuZXZlciBwYXJ0IG9mIHRoZWlyIGRlc2lnbiwgYW5kIGJ5IHRoZSBuYXR1cmUgb2Yg dGhpcyBwcm90b2NvbCwgaXMgbW9yZSBpbiB0aGUgZG9tYWluIG9mIHRoZSByZXNvdXJjZSBzZXJ2 ZXIgKGJhc2VkIG9uIHdoYXQgaW5mb3JtYXRpb24gaXQgZXhwb3NlcyB2aWEgaXRzIEFQSSkuIElu IGZhY3QsIHlvdXIgZW1haWwgaWYgdGhlIGZpcnN0IHN1Y2ggc3VnZ2VzdGlvbiBvZiBhbm9ueW1p dHkuDQoNCkVITA0KDQpGcm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNv bTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NCkRhdGU6IFRodSwgMTEgQXVnIDIwMTEg MTE6MTU6MjggLTA3MDANClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWls dG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KQ2M6ICJPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoQGlldGYub3JnPikiIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnMNCg0KTWFueSBy ZWFzb25zLCBidXQgbm9uZSBhcmUgZXhwbGFpbmVkIGluIHRoZSBzcGVjaWZpY2F0aW9uDQoNCkZy b206IERpY2sgSGFyZHQgW21haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbV0NClNlbnQ6IFRodXJz ZGF5LCBBdWd1c3QgMTEsIDIwMTEgMTA6NTEgQU0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBP QXV0aCBXRyAob2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikNClN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zDQoNCk15IHJlY29sbGVjdGlvbiBvZiByZWZy ZXNoIHRva2VucyB3YXMgZm9yIHNlY3VyaXR5IGFuZCByZXZvY2F0aW9uLg0KDQpzZWN1cml0eTog QnkgaGF2aW5nIGEgc2hvcnQgbGl2ZWQgYWNjZXNzIHRva2VuLCBhIGNvbXByb21pc2VkIGFjY2Vz cyB0b2tlbiB3b3VsZCBsaW1pdCB0aGUgdGltZSBhbiBhdHRhY2tlciB3b3VsZCBoYXZlIGFjY2Vz cw0KDQpyZXZvY2F0aW9uOiBpZiB0aGUgYWNjZXNzIHRva2VuIGlzIHNlbGYgY29udGFpbmVkLCBh dXRob3JpemF0aW9uIGNhbiBiZSByZXZva2VkIGJ5IG5vdCBpc3N1aW5nIG5ldyBhY2Nlc3MgdG9r ZW5zLiBBIHJlc291cmNlIGRvZXMgbm90IG5lZWQgdG8gcXVlcnkgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyIHRvIHNlZSBpZiB0aGUgYWNjZXNzIHRva2VuIGlzIHZhbGlkLlRoaXMgc2ltcGxpZmll cyBhY2Nlc3MgdG9rZW4gdmFsaWRhdGlvbiBhbmQgbWFrZXMgaXQgZWFzaWVyIHRvIHNjYWxlIGFu ZCBzdXBwb3J0IG11bHRpcGxlIGF1dGhvcml6YXRpb24gc2VydmVycy4gIFRoZXJlIGlzIGEgd2lu ZG93IG9mIHRpbWUgd2hlbiBhbiBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQsIGJ1dCBhdXRob3JpemF0 aW9uIGlzIHJldm9rZWQuDQoNCg0KDQpPbiAyMDExLTA4LTExLCBhdCAxMDo0MCBBTSwgQW50aG9u eSBOYWRhbGluIHdyb3RlOg0KDQoNCg0KDQoNCg0KTm93aGVyZSBpbiB0aGUgc3BlY2lmaWNhdGlv biBpcyB0aGVyZSBleHBsYW5hdGlvbiBmb3IgcmVmcmVzaCB0b2tlbnMsIFRoZSByZWFzb24gdGhh dCB0aGUgUmVmcmVzaCB0b2tlbiB3YXMgaW50cm9kdWNlZCB3YXMgZm9yIGFub255bWl0eS4gVGhl IHNjZW5hcmlvIGlzIHRoYXQgYSBjbGllbnQgYXNrcyB0aGUgdXNlciBmb3IgYWNjZXNzLiBUaGUg dXNlciB3YW50cyB0byBncmFudCB0aGUgYWNjZXNzIGJ1dCBub3QgdGVsbCB0aGUgY2xpZW50IHRo ZSB1c2VyJ3MgaWRlbnRpdHkuIEJ5IGlzc3VpbmcgdGhlIHJlZnJlc2ggdG9rZW4gYXMgYW4gJ2lk ZW50aWZpZXInIGZvciB0aGUgdXNlciAoYXMgd2VsbCBhcyBvdGhlciBjb250ZXh0IGRhdGEgbGlr ZSB0aGUgcmVzb3VyY2UpIGl0J3MgcG9zc2libGUgbm93IHRvIGxldCB0aGUgY2xpZW50IGdldCBh Y2Nlc3Mgd2l0aG91dCByZXZlYWxpbmcgYW55dGhpbmcgYWJvdXQgdGhlIHVzZXIuIFJlY29tbWVu ZCB0aGF0IHRoZSBhYm92ZSBleHBsYW5hdGlvbiBiZSBpbmNsdWRlZCBzbyBkZXZlbG9wZXJzIHVu ZGVyc3RhbmQgd2h5IHRoZSByZWZyZXNoIHRva2VucyBhcmUgdGhlcmUuDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpP QXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B8A1F6SN2PRD0302MB137_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGlzYWdyZWUsIHRoaXMgd2FzIG91ciBy YXRpb25hbCBhbmQgdGhpcyBpcyBvbmUgd2F5IGl04oCZcyB1c2VkIHRvZGF5IHdpdGggb3VyIHNj ZW5hcmlvcy4gVGhpcyBuZWVkcyB0byBiZSBhc3NpZ25lZCBhbiBpc3N1ZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAzOjM5IFBNPGJyPg0K PGI+VG86PC9iPiBBbnRob255IE5hZGFsaW48YnI+DQo8Yj5DYzo8L2I+IERpY2sgSGFyZHQ7IE9B dXRoIFdHIChvYXV0aEBpZXRmLm9yZyk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gUmVmcmVzaCBUb2tlbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIHRleHQgaXMgd3JvbmcuIFRoaXMgaXMgbm90IHdoeSByZWZyZXNo IHRva2VucyB3ZXJlIGludHJvZHVjZWQgKG9yaWdpbmFsbHkgYnkgWWFob28gdGhlbiBpbiBXUkFQ KS4gQW5kIGlzIGFsc28gdGVjaG5pY2FsbHkgdW5mb3VuZGVkLiBSZWZyZXNoIHRva2VucyBoYXZl IG5vIHNwZWNpYWwgYW5vbnltaXR5IHByb3BlcnRpZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+RUhMPGJyPg0KPGJyPg0KT24gQXVnIDExLCAyMDExLCBhdCAxODoxOCwgJnF1b3Q7 QW50aG9ueSBOYWRhbGluJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3Nv ZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIHJhaXNpbmcgdGhlIGlz c3VlIG9uIHRoZSBjdXJyZW50IHRleHQsIEkgYWxyZWFkeSBwcm92aWRlZCB0ZXh0IGlmIHRoZSBv cmlnaW5hbCBhcHBlbmQuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRXJhbiBIYW1t ZXItTGFoYXYNCjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dIj5b bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dPC9hPiA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEF1Z3VzdCAxMSwgMjAxMSAzOjAzIFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFs aW48YnI+DQo8Yj5DYzo8L2I+IERpY2sgSGFyZHQ7IE9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86 b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuIFByb2Nlc3Mtd2lzZSBpdCBkb2VzLiBU aGlzIGlzIGEgYnJhbmQgbmV3IGNvbmNlcHQgKmhlcmUqIGFuZCB3YXMgbm90IG1lbnRpb25lZCBp biB0aGUgY2hhcnRlciBvciBhbnkgdXNlIGNhc2VzLiBUaGVyZWZvcmUsIG91dCBvZiBzY29wZS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjIuIFRoZSBjdXJyZW50IHRleHQgcHJvdmlkZXMgYWxsIHRoZSBpbmZvcm1hdGlvbiBu ZWVkZWQgdG8gaW1lbWVudC4gTm8gb25lIHJhaXNlZCBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZSBv biB0aGUgY3VycmVudCB0ZXh0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+My4gUmVmcmVzaCB0b2tlbiBkbyBub3QgcHJvdmlkZSBhbm9u eW1pdHkuIEFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGJ1dCB0aGlzIHdhcyBuZXZlciBjb25zaWRl cmVkIGluIHRoZSBkZXNpZ24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj40LiBJZiB5b3UgaGF2ZSBzdWdnZXN0ZWQgdGV4dCwg cHJlc2VudCBpdCBiZWZvcmUgdGhlIFdHTEMgaXMgb3Zlci4gSSBhbSBub3QgYWRkaW5nIGlzc3Vl cyB0byBteSBsaXN0IHdpdGhvdXQgc3VnZ2VzdGVkIHRleHQgYW5kIHdnIGNvbnNlbnN1cy4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkVITDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQpPbiBBdWcgMTEsIDIwMTEsIGF0IDE3OjQ0LCAmcXVvdDtBbnRob255IE5hZGFsaW4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIG5vIHVzZSBjYXNlcyBhdCBhbGwgaW4gV1JBUCB0 byBoZWxwIGV4cGxhaW4gY2hvaWNlcyB0YWtlbiwgaXQgZG9lcyBub3QgbWF0dGVyIGlmIHRoZXJl DQogd2VyZSBvciB3ZXJlIG5vdCBwcmV2aW91cyBpc3N1ZXMgcmFpc2VkLCBpdCBpcyBiZWluZyBy YWlzZWQgbm93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBFcmFuIEhhbW1lci1MYWhhdg0KPGEg aHJlZj0ibWFpbHRvOlttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0iPlttYWlsdG86ZXJhbkBo dWVuaXZlcnNlLmNvbV08L2E+IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDEx LCAyMDExIDE6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbjsgRGljayBIYXJk dDxicj4NCjxiPkNjOjwvYj4gT0F1dGggV0cgKDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y ZyI+b2F1dGhAaWV0Zi5vcmc8L2E+KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdH XSBSZWZyZXNoIFRva2Vuczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5UaGF0J3MgaXJyZWxldmFudCBnaXZlbiBXUkFQIGRvZXMgbm90IG1lbnRpb24gYW5vbnltaXR5 IG9yIGFueXRoaW5nIGVsc2UgYWJvdXQgcmVmcmVzaCB0b2tlbiBub3QgZXhwbGljaXRseQ0KIGFk ZHJlc3NlZCBhbHJlYWR5IGJ5IHYyLiBZb3VyIGVtYWlsIGlzIHRoZSB2ZXJ5IGZpcnN0IHRpbWUg dGhpcyBoYXMgYmVlbiByYWlzZWQgb24gdGhpcyBsaXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+RUhMPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVm PSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+ Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHUsIDExIEF1ZyAyMDExIDEyOjQxOjI4IC0wNzAwPGJy Pg0KPGI+VG86IDwvYj5FcmFuIEhhbW1lci1sYWhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5A aHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+Jmd0OywgRGljayBIYXJkdCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWls LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtPQXV0aCBXRyAoPGEgaHJlZj0ibWFp bHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4pJnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UkU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMu NzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Bbm9ueW1pdHkgd2FzIGNlcnRhaW5seSBwYXJ0IG9mIHRoZSBkZXNpZ24gZm9y IFdSQVA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gRXJh bg0KIEhhbW1lci1MYWhhdiBbPGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPm1h aWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgQXVndXN0IDExLCAyMDExIDEyOjM1IFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFs aW47IERpY2sgSGFyZHQ8YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86 b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U2VjdGlvbiAx LjUgYWxyZWFkeSBjb3ZlcnMgcmVmcmVzaCB0b2tlbnMuIFRoZXJlIGFyZSBtYW55IHVzZSBjYXNl cyBmb3IgcmVmcmVzaCB0b2tlbnMuIFRoZXkgYXJlIGJhc2ljYWxseQ0KIGEgcHJvdG9jb2wgZmVh dHVyZSB1c2VkIHRvIG1ha2Ugc2NhbGFiaWxpdHkgYW5kIHNlY3VyaXR5IG1vcmUgZmxleGlibGUu IEFub255bWl0eSB3YXMgbmV2ZXIgcGFydCBvZiB0aGVpciBkZXNpZ24sIGFuZCBieSB0aGUgbmF0 dXJlIG9mIHRoaXMgcHJvdG9jb2wsIGlzIG1vcmUgaW4gdGhlIGRvbWFpbiBvZiB0aGUgcmVzb3Vy Y2Ugc2VydmVyIChiYXNlZCBvbiB3aGF0IGluZm9ybWF0aW9uIGl0IGV4cG9zZXMgdmlhIGl0cyBB UEkpLiBJbiBmYWN0LA0KIHlvdXIgZW1haWwgaWYgdGhlIGZpcnN0IHN1Y2ggc3VnZ2VzdGlvbiBv ZiBhbm9ueW1pdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FSEw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5BbnRob255IE5hZGFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jv c29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PlRodSwgMTEgQXVnIDIwMTEgMTE6MTU6MjggLTA3MDA8YnI+DQo8Yj5UbzogPC9iPkRpY2sgSGFy ZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+ZGljay5oYXJkdEBn bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7T0F1dGggV0cgKDxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+KSZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPlJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVm dDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+TWFueSByZWFzb25zLCBidXQgbm9uZSBhcmUgZXhwbGFpbmVkIGluIHRo ZSBzcGVjaWZpY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+IERpY2sNCiBIYXJkdCBbPGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29t Ij5tYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb208L2E+XSA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAxMDo1MSBBTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBO YWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBXRyAoPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll dGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FV VEgtV0ddIFJlZnJlc2ggVG9rZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+TXkgcmVjb2xsZWN0aW9uIG9mIHJlZnJlc2ggdG9rZW5zIHdhcyBm b3Igc2VjdXJpdHkgYW5kIHJldm9jYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c2VjdXJpdHk6IEJ5IGhhdmluZyBhIHNob3J0 IGxpdmVkIGFjY2VzcyB0b2tlbiwgYSBjb21wcm9taXNlZCBhY2Nlc3MgdG9rZW4gd291bGQgbGlt aXQgdGhlIHRpbWUgYW4gYXR0YWNrZXIgd291bGQgaGF2ZSBhY2Nlc3M8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnJldm9j YXRpb246IGlmIHRoZSBhY2Nlc3MgdG9rZW4gaXMgc2VsZiBjb250YWluZWQsIGF1dGhvcml6YXRp b24gY2FuIGJlIHJldm9rZWQgYnkgbm90IGlzc3VpbmcgbmV3IGFjY2VzcyB0b2tlbnMuIEEgcmVz b3VyY2UgZG9lcyBub3QgbmVlZCB0byBxdWVyeSB0aGUNCiBhdXRob3JpemF0aW9uIHNlcnZlciB0 byBzZWUgaWYgdGhlIGFjY2VzcyB0b2tlbiBpcyB2YWxpZC5UaGlzIHNpbXBsaWZpZXMgYWNjZXNz IHRva2VuIHZhbGlkYXRpb24gYW5kIG1ha2VzIGl0IGVhc2llciB0byBzY2FsZSBhbmQgc3VwcG9y dCBtdWx0aXBsZSBhdXRob3JpemF0aW9uIHNlcnZlcnMuJm5ic3A7Jm5ic3A7VGhlcmUgaXMgYSB3 aW5kb3cgb2YgdGltZSB3aGVuIGFuIGFjY2VzcyB0b2tlbiBpcyB2YWxpZCwgYnV0IGF1dGhvcml6 YXRpb24gaXMgcmV2b2tlZC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T24gMjAxMS0wOC0xMSwg YXQgMTA6NDAgQU0sIEFudGhvbnkgTmFkYWxpbiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Ob3doZXJlIGluIHRoZSBzcGVjaWZpY2F0aW9uIGlz IHRoZXJlIGV4cGxhbmF0aW9uIGZvciByZWZyZXNoIHRva2VucywgVGhlIHJlYXNvbiB0aGF0IHRo ZSBSZWZyZXNoIHRva2VuDQogd2FzIGludHJvZHVjZWQgd2FzIGZvciBhbm9ueW1pdHkuIFRoZSBz Y2VuYXJpbyBpcyB0aGF0IGEgY2xpZW50IGFza3MgdGhlIHVzZXIgZm9yIGFjY2Vzcy4gVGhlIHVz ZXIgd2FudHMgdG8gZ3JhbnQgdGhlIGFjY2VzcyBidXQgbm90IHRlbGwgdGhlIGNsaWVudCB0aGUg dXNlcidzIGlkZW50aXR5LiBCeSBpc3N1aW5nIHRoZSByZWZyZXNoIHRva2VuIGFzIGFuICdpZGVu dGlmaWVyJyBmb3IgdGhlIHVzZXIgKGFzIHdlbGwgYXMgb3RoZXIgY29udGV4dA0KIGRhdGEgbGlr ZSB0aGUgcmVzb3VyY2UpIGl0J3MgcG9zc2libGUgbm93IHRvIGxldCB0aGUgY2xpZW50IGdldCBh Y2Nlc3Mgd2l0aG91dCByZXZlYWxpbmcgYW55dGhpbmcgYWJvdXQgdGhlIHVzZXIuIFJlY29tbWVu ZCB0aGF0IHRoZSBhYm92ZSBleHBsYW5hdGlvbiBiZSBpbmNsdWRlZCBzbyBkZXZlbG9wZXJzIHVu ZGVyc3RhbmQgd2h5IHRoZSByZWZyZXNoIHRva2VucyBhcmUgdGhlcmUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B26C1EF377CB694EAB6BDDC8E624B6E723B8A1F6SN2PRD0302MB137_-- From wmills@yahoo-inc.com Thu Aug 11 16:25:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5631621F8ACE for ; Thu, 11 Aug 2011 16:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.125 X-Spam-Level: X-Spam-Status: No, score=-17.125 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZRKjXPpW-zs for ; Thu, 11 Aug 2011 16:25:46 -0700 (PDT) Received: from nm3-vm1.bullet.mail.ne1.yahoo.com (nm3-vm1.bullet.mail.ne1.yahoo.com [98.138.91.53]) by ietfa.amsl.com (Postfix) with SMTP id B632121F86D8 for ; Thu, 11 Aug 2011 16:25:45 -0700 (PDT) Received: from [98.138.90.53] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 23:26:21 -0000 Received: from [98.138.87.1] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 23:26:21 -0000 Received: from [127.0.0.1] by omp1001.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 23:26:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 154067.79985.bm@omp1001.mail.ne1.yahoo.com Received: (qmail 53132 invoked by uid 60001); 11 Aug 2011 23:26:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313105180; bh=r0qC4jlrEij1FX/IwNj4ZkiK8k/xEvugr5FvXcdwHM8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=diFuoKbyjVM1vh9nMTUah/AeEQ7UQcUBNKuGZqjAt/3wR6/bDfbD7Cnb7dBgw0N6bpu/dABpJawU83jBvOtuV2GuSnKh0OsBr2PNRa27BPypH1LfPcrNXoaqBM01VZbYDwIDDm3X+gTZlbwmZQZsdIrbucA+p4mH1Lp8c11SK6E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eSs31BtB97kkydNCkfvdGV4xQPgDmRw/No2UBD+mIofdC5iZONB9ECcWcc9482pCyjgkd1y/3U/wOPMMXOZrsOsFS6L0wqLZBSyci3ixgCx+0MAoD2S4sPwJcSYlerSFAfAE7BwSLjmTfEhbhaKP8CdXRPq/VA9KF6LtDGRe7vQ=; X-YMail-OSG: dJ1Z1n4VM1kvLcZTuZZl7zEb64dB1m0QJPIpv3AkbSv3S9t hSnZvO2ePlnayfjd.Cbg.9v4ct2UEJ_dSmOEZvw3rkqlKyjZ44pD1NLiw6U0 3k6JxKMC9oyCa3rqcaOqf.aWtzbo2rUW2DlEEnEUrAJRWGv8wt3Loa7DK0gq CPuTIsjJstIYRsotiA4RQXmkxbVsIA.7SwIFguKz3PhcHXoPeOmmfmF9Q_9v 1IujU3JXDA.cHUXXKLGGVVFtUmAhSWMDS4Pgi83WJDf..BhUspY7e_tDMyPk TfTTK1fhALaAKbrq3C5AElP.kynZL7tohAVFvscbxOfM_sYg51hkhdVxQIyo hNOA7qICciZtuCo8t2z5h.uHPnybx1DMkiaMXM7aiQbLNEtaMqmletaH_wO2 gYiqiGbSkQYnr1lIoTnGGqxeaTk1Kb8VY9oWzwGUHrV2L Received: from [209.131.62.115] by web31803.mail.mud.yahoo.com via HTTP; Thu, 11 Aug 2011 16:26:20 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> Message-ID: <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Thu, 11 Aug 2011 16:26:20 -0700 (PDT) From: "William J. Mills" To: Anthony Nadalin , Eran Hammer-Lahav In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1082365393-1313105180=:20903" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 23:25:47 -0000 --0-1082365393-1313105180=:20903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It's implementation specific.=C2=A0 You can choose to make them anonymous o= r you can issue signed plaintext tokens that conceal nothing.=C2=A0 The spe= c doesn't care.=C2=A0 It's a security consideration of the end implementati= on, just like the need for tamper protection.=C2=A0 The spec needs only to = define them as opaque blobs with a particular syntax.=C2=A0 We are not spec= ifying what encryption you have to use here, and we should not.=0A=0A=0A=0A= =0A________________________________=0AFrom: Anthony Nadalin =0ATo: Eran Hammer-Lahav =0ACc: "OAuth WG (oau= th@ietf.org)" =0ASent: Thursday, August 11, 2011 3:45 PM=0A= Subject: Re: [OAUTH-WG] Refresh Tokens=0A=0A=0A =0ADisagree, this was our r= ational and this is one way it=E2=80=99s used today with our scenarios. Thi= s needs to be assigned an issue.=0A=C2=A0=0AFrom:Eran Hammer-Lahav [mailto:= eran@hueniverse.com] =0ASent: Thursday, August 11, 2011 3:39 PM=0ATo: Antho= ny Nadalin=0ACc: Dick Hardt; OAuth WG (oauth@ietf.org)=0ASubject: Re: [OAUT= H-WG] Refresh Tokens=0A=C2=A0=0AThe text is wrong. This is not why refresh = tokens were introduced (originally by Yahoo then in WRAP). And is also tech= nically unfounded. Refresh tokens have no special anonymity properties.=C2= =A0=0A=C2=A0=0AEHL=0A=0AOn Aug 11, 2011, at 18:18, "Anthony Nadalin" wrote:=0AI=E2=80=99m raising the issue on the current tex= t, I already provided text if the original append.=C2=A0 =0A>=C2=A0=0A>From= :Eran Hammer-Lahav [mailto:eran@hueniverse.com] =0A>Sent: Thursday, August = 11, 2011 3:03 PM=0A>To: Anthony Nadalin=0A>Cc: Dick Hardt; OAuth WG (oauth@= ietf.org)=0A>Subject: Re: [OAUTH-WG] Refresh Tokens=0A>=C2=A0=0A>1. Process= -wise it does. This is a brand new concept *here* and was not mentioned in = the charter or any use cases. Therefore, out of scope.=C2=A0=0A>=C2=A0=0A>2= . The current text provides all the information needed to imement. No one r= aised an implementation issue on the current text.=0A>=C2=A0=0A>3. Refresh = token do not provide anonymity. An implementation could but this was never = considered in the design.=C2=A0=0A>=C2=A0=0A>4. If you have suggested text,= present it before the WGLC is over. I am not adding issues to my list with= out suggested text and wg consensus.=C2=A0=0A>=C2=A0=0A>EHL=0A>=0A>On Aug 1= 1, 2011, at 17:44, "Anthony Nadalin" wrote:=0A>Ther= e are no use cases at all in WRAP to help explain choices taken, it does no= t matter if there were or were not previous issues raised, it is being rais= ed now.=0A>>=C2=A0=0A>>From:Eran Hammer-Lahav [mailto:eran@hueniverse.com] = =0A>>Sent: Thursday, August 11, 2011 1:46 PM=0A>>To: Anthony Nadalin; Dick = Hardt=0A>>Cc: OAuth WG (oauth@ietf.org)=0A>>Subject: Re: [OAUTH-WG] Refresh= Tokens=0A>>=C2=A0=0A>>That's irrelevant given WRAP does not mention anonym= ity or anything else about refresh token not explicitly addressed already b= y v2. Your email is the very first time this has been raised on this list.= =0A>>=C2=A0=0A>>EHL=0A>>=C2=A0=0A>>From: Anthony Nadalin =0A>>Date: Thu, 11 Aug 2011 12:41:28 -0700=0A>>To: Eran Hammer-lahav <= eran@hueniverse.com>, Dick Hardt =0A>>Cc: "OAuth WG (= oauth@ietf.org)" =0A>>Subject: RE: [OAUTH-WG] Refresh Token= s=0A>>=C2=A0=0A>>Anonymity was certainly part of the design for WRAP=0A>>>= =C2=A0=0A>>>From:Eran Hammer-Lahav [mailto:eran@hueniverse.com] =0A>>>Sent:= Thursday, August 11, 2011 12:35 PM=0A>>>To: Anthony Nadalin; Dick Hardt=0A= >>>Cc: OAuth WG (oauth@ietf.org)=0A>>>Subject: Re: [OAUTH-WG] Refresh Token= s=0A>>>=C2=A0=0A>>>Section 1.5 already covers refresh tokens. There are man= y use cases for refresh tokens. They are basically a protocol feature used = to make scalability and security more flexible. Anonymity was never part of= their design, and by the nature of this protocol, is more in the domain of= the resource server (based on what information it exposes via its API). In= fact, your email if the first such suggestion of anonymity.=0A>>>=C2=A0=0A= >>>EHL=0A>>>=C2=A0=0A>>>From: Anthony Nadalin =0A>>>= Date: Thu, 11 Aug 2011 11:15:28 -0700=0A>>>To: Dick Hardt =0A>>>Cc: "OAuth WG (oauth@ietf.org)" =0A>>>Subject: R= e: [OAUTH-WG] Refresh Tokens=0A>>>=C2=A0=0A>>>Many reasons, but none are ex= plained in the specification=0A>>>>=C2=A0=0A>>>>From:Dick Hardt [mailto:dic= k.hardt@gmail.com] =0A>>>>Sent: Thursday, August 11, 2011 10:51 AM=0A>>>>To= : Anthony Nadalin=0A>>>>Cc: OAuth WG (oauth@ietf.org)=0A>>>>Subject: Re: [O= AUTH-WG] Refresh Tokens=0A>>>>=C2=A0=0A>>>>My recollection of refresh token= s was for security and revocation.=0A>>>>=C2=A0=0A>>>>security: By having a= short lived access token, a compromised access token would limit the time = an attacker would have access=0A>>>>=C2=A0=0A>>>>revocation: if the access = token is self contained, authorization can be revoked by not issuing new ac= cess tokens. A resource does not need to query the authorization server to = see if the access token is valid.This simplifies access token validation an= d makes it easier to scale and support multiple authorization servers.=C2= =A0=C2=A0There is a window of time when an access token is valid, but autho= rization is revoked.=C2=A0=0A>>>>=C2=A0=0A>>>>=C2=A0=0A>>>>=C2=A0=0A>>>>On = 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:=0A>>>>=0A>>>>=0A>>>>=0A>>>>= =0A>>>>=0A>>>>=0A>>>>=0A>>>>Nowhere in the specification is there explanati= on for refresh tokens, The reason that the Refresh token was introduced was= for anonymity. The scenario is that a client asks the user for access. The= user wants to grant the access but not tell the client the user's identity= . By issuing the refresh token as an 'identifier' for the user (as well as = other context data like the resource) it's possible now to let the client g= et access without revealing anything about the user. Recommend that the abo= ve explanation be included so developers understand why the refresh tokens = are there.=0A>>>>_______________________________________________=0A>>>>OAut= h mailing list=0A>>>>OAuth@ietf.org=0A>>>>https://www.ietf.org/mailman/list= info/oauth=0A>>>>=C2=A0=0A_______________________________________________= =0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listi= nfo/oauth --0-1082365393-1313105180=:20903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It's implementation specific.  You can choose to make them anonymous= or you can issue signed plaintext tokens that conceal nothing.  The s= pec doesn't care.  It's a security consideration of the end implementa= tion, just like the need for tamper protection.  The spec needs only t= o define them as opaque blobs with a particular syntax.  We are not sp= ecifying what encryption you have to use here, and we should not.



<= div style=3D"font-family: Courier New, courier, monaco, monospace, sans-ser= if; font-size: 10pt;">
From: Anthony Nadali= n <tonynad@microsoft.com>
To:= Eran Hammer-Lahav <eran@hueniverse.com>
Cc: "OAuth WG (oauth@ietf.org)" <oaut= h@ietf.org>
Sent: Th= ursday, August 11, 2011 3:45 PM
Su= bject: Re: [OAUTH-WG] Refresh Tokens

=0A=0A =0A =0A=0A=0A =0A
=0A
Disagree, this was our rational and this is one way it=E2=80=99s used t= oday with our scenarios. This needs to be assigned an issue.
= =0A
 
=0A
=0A
=0A
From:= Eran Hammer-Lahav [mailto:eran@huenivers= e.com]=0A
=0ASent: Thursday, August 11, 2011 3:39 PM
=0ATo:= Anthony Nadalin
=0ACc: Dick Hardt; OAuth WG (oauth@ietf.org)=
=0ASubject: Re: [OAUTH-WG] Refresh Tokens
=0A
= =0A
=0A
 
=0A
=0A=
The text is wrong. This is not why re= fresh tokens were introduced (originally by Yahoo then in WRAP). And is als= o technically unfounded. Refresh tokens have no special anonymity propertie= s. 
=0A
=0A
=0A
&= nbsp;
=0A
=0A
=0A
EHL
=0A
=0AOn Aug 11, 2011, at 18:18, "Ant= hony Nadalin" <tonynad@microso= ft.com> wrote:
=0A
=0A
=0A
=0A
=0A
I=E2=80= =99m raising the issue on the current text, I already provided text if the = original append. =0A
=0A
 
=0A
=0A
=0A
From: Eran Hammer-Lahav=0A[mailto:eran@hueniverse.com]
=0ASent: T= hursday, August 11, 2011 3:03 PM
=0ATo: Anthony Nadalin
=0A= Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
=0ASubject: Re: [OAUTH-WG] Refresh Tokens
=0A=0A
=0A
 
= =0A
=0A
1. Process-wis= e it does. This is a brand new concept *here* and was not mentioned in the = charter or any use cases. Therefore, out of scope. 
=0A
=0A=
=0A
 
=0A=0A
=0A
2. The curr= ent text provides all the information needed to imement. No one raised an i= mplementation issue on the current text.
=0A
=0A
=0A
 
=0A
=0A
=0A<= div class=3D"yiv1574665975MsoNormal" style=3D"">3. Refresh token do not pro= vide anonymity. An implementation could but this was never considered in th= e design. 
=0A
=0A
=0A
 
=0A
=0A
=0A
4. If you have suggested text, present it before the= WGLC is over. I am not adding issues to my list without suggested text and= wg consensus. 
=0A
=0A
=0A
 
=0A
=0A
=0A
EHL
=0A
=0A=0A
=0A
=0A
=0A
There are no use cases at all in WRAP to help explain choices take= n, it does not matter if there=0A were or were not previous issues raised, = it is being raised now.
=0A
 =
=0A
=0A
=0A
From: Eran Hammer-Lahav=0A[mailto:eran@hueniverse.com]
=0ASent: Th= ursday, August 11, 2011 1:46 PM
=0ATo: Anthony Nadalin; Dick Hard= t
=0ACc: OAuth WG (oauth@ietf.org= )
=0ASubject: Re: [OAUTH-WG] Refresh Tokens
=0A=0A
=0A
 
= =0A
=0A
That's irrelevant given WRAP does not mentio= n anonymity or anything else about refresh token not explicitly=0A addresse= d already by v2. Your email is the very first time this has been raised on = this list.
=0A
=0A
=0A
 
=0A
=0A
=0A
EHL
=0A
= =0A
=0A
 
=0A
=0A
= =0A
From:=0AAnthony Nadalin <tonynad@microsoft.com>
=0ADate: Thu, 11 Aug 2011 12:41:= 28 -0700
=0ATo: Eran Hammer-lahav <eran@hueniverse.com>, Dick Hardt <dick.hardt@gmail.com>
=0ACc: "OAuth WG= (oauth@ietf.org)" <oauth@ietf.org>
=0ASubject: RE: [OAUTH-WG] Refresh= Tokens
=0A
=0A
=0A
 <= /div> =0A
=0A
=0A
=0A
=0A
Anonymity was certai= nly part of the design for WRAP
=0A
 = ;
=0A
=0A
=0A
From:<= /b> Eran=0A Hammer-Lahav [mailto:eran@hueniverse.com]=0A
= =0ASent: Thursday, August 11, 2011 12:35 PM
=0ATo: Anthony= Nadalin; Dick Hardt
=0ACc: OAuth WG (oauth@ietf.org)
=0ASubject: Re: [OAUTH-WG] Refresh Tokens
=0A
=0A
=0A
 
=0A
=0A
Section 1.5 already covers refresh tokens. There are many use ca= ses for refresh tokens. They are basically=0A a protocol feature used to ma= ke scalability and security more flexible. Anonymity was never part of thei= r design, and by the nature of this protocol, is more in the domain of the = resource server (based on what information it exposes via its API). In fact= ,=0A your email if the first such suggestion of anonymity.
=0A=
=0A
=0A
 
=0A
=0A
= =0A
EHL
=0A
=0A
=0A
 
=0A
=0A
=0A
Fr= om:=0AAnthony Nada= lin <tonynad@microsoft.com= >
=0ADate: Thu, 11 Aug 2011 11:15:28 -0700
=0ATo: Di= ck Hardt <dick.hardt@gmail.com>
=0ACc: "OAuth WG (oauth@ietf.o= rg)" <oauth@ietf.org>
=0A= Subject: Re: [OAUTH-WG] Refresh Tokens
=0A
=0A
= =0A
 
=0A
=0A
=0A
=0A
=0AMany reasons, but none are explained in the specificatio= n
=0A
 
=0A
=0A=0A
From: Dick=0A Hardt [= mailto:dick.hardt@gmail.com]
=0ASent: Thursday, August 11, 2= 011 10:51 AM
=0ATo: Anthony Nadalin
=0ACc: OAuth WG (oauth@ietf.org)
=0ASubject: Re: [O= AUTH-WG] Refresh Tokens
=0A
=0A
=0A
 <= /div> =0A
My recollection of refresh tokens was for security and revocati= on.
=0A
=0A
 
=0A
=0A
=0As= ecurity: By having a short lived access token, a compromised access token w= ould limit the time an attacker would have access
=0A
=0A=
=0A
 
=0A
=0A
=0A
revocation: if the ac= cess token is self contained, authorization can be revoked by not issuing n= ew access tokens. A resource does not need to query the=0A authorization se= rver to see if the access token is valid.This simplifies access token valid= ation and makes it easier to scale and support multiple authorization serve= rs.  There is a window of time when an access token is valid, but= authorization is revoked. 
=0A
=0A
=0A
 =
=0A
=0A
<= span style=3D"color:black;"> 
=0A
=0A
=0A
&nbs= p;
=0A
=0A
=0A
On 2011-08-11, at 10:40 AM, Anthony N= adalin wrote:
=0A
=0A

=0A
=0A
=0A
=0A
= =0A
=0A
=0A
=0A
=0A
Nowhere in t= he specification is there explanation for refresh tokens, The reason that t= he Refresh token=0A was introduced was for anonymity. The scenario is that = a client asks the user for access. The user wants to grant the access but n= ot tell the client the user's identity. By issuing the refresh token as an = 'identifier' for the user (as well as other context=0A data like the resour= ce) it's possible now to let the client get access without revealing anythi= ng about the user. Recommend that the above explanation be included so deve= lopers understand why the refresh tokens are there.
=0A
= =0A
_______________________________________________
= =0AOAuth mailing list
=0AOAuth@ietf.org<= br>=0Ahttps://www.ietf.org/mailman/listinfo/oauth
=0A
=0A
=0A
 
=0A
=0A
=0A=0A
=0A
=0A
=0A
=0A
=0A
=0A=
=0A
=0A
=0A
=0A=0A
=0A =0A=0A=

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--0-1082365393-1313105180=:20903-- From eran@hueniverse.com Thu Aug 11 16:28:25 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5876C21F8B30 for ; Thu, 11 Aug 2011 16:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vTJTqc0AIys for ; Thu, 11 Aug 2011 16:28:24 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D8FB721F8B2E for ; Thu, 11 Aug 2011 16:28:23 -0700 (PDT) Received: (qmail 28757 invoked from network); 11 Aug 2011 23:27:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 23:27:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 11 Aug 2011 16:27:15 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin Date: Thu, 11 Aug 2011 16:27:11 -0700 Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYfjRXVQdEtWOfT7G2jhDXGrZFjg== Message-ID: <63B2BDD8-BAB8-4B8B-B7C6-72CA0C9C3913@hueniverse.com> References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_63B2BDD8BAB84B8BB7C672CA0C9C3913hueniversecom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 23:28:25 -0000 --_000_63B2BDD8BAB84B8BB7C672CA0C9C3913hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciBvcmlnaW5hbCBwb3N0IGRvZXMgbm90IGV4cGxhaW4gaG93IGFub255bWl0eSBpcyBhY2hp ZXZlZCBvciB3aGF0IGl0IGFjdHVhbGx5IG1lYW5zLg0KDQpOb3Qgd2VhcmluZyBteSBlZGl0b3Ig aGVhdCBJJ20gc3Ryb25nbHkgb3Bwb3NlZCB0byB0aGlzIGVudGlyZSBjb25jZXB0Lg0KDQpFSEwN Cg0KT24gQXVnIDExLCAyMDExLCBhdCAxODo0OSwgIkFudGhvbnkgTmFkYWxpbiIgPHRvbnluYWRA bWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoNCkRp c2FncmVlLCB0aGlzIHdhcyBvdXIgcmF0aW9uYWwgYW5kIHRoaXMgaXMgb25lIHdheSBpdOKAmXMg dXNlZCB0b2RheSB3aXRoIG91ciBzY2VuYXJpb3MuIFRoaXMgbmVlZHMgdG8gYmUgYXNzaWduZWQg YW4gaXNzdWUuDQoNCkZyb206IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZl cnNlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEgMzozOSBQTQ0KVG86IEFu dGhvbnkgTmFkYWxpbg0KQ2M6IERpY2sgSGFyZHQ7IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZzxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBU b2tlbnMNCg0KVGhlIHRleHQgaXMgd3JvbmcuIFRoaXMgaXMgbm90IHdoeSByZWZyZXNoIHRva2Vu cyB3ZXJlIGludHJvZHVjZWQgKG9yaWdpbmFsbHkgYnkgWWFob28gdGhlbiBpbiBXUkFQKS4gQW5k IGlzIGFsc28gdGVjaG5pY2FsbHkgdW5mb3VuZGVkLiBSZWZyZXNoIHRva2VucyBoYXZlIG5vIHNw ZWNpYWwgYW5vbnltaXR5IHByb3BlcnRpZXMuDQoNCkVITA0KDQpPbiBBdWcgMTEsIDIwMTEsIGF0 IDE4OjE4LCAiQW50aG9ueSBOYWRhbGluIiA8PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+ dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNCknigJltIHJhaXNpbmcgdGhlIGlzc3VlIG9uIHRoZSBjdXJyZW50IHRleHQsIEkgYWxyZWFk eSBwcm92aWRlZCB0ZXh0IGlmIHRoZSBvcmlnaW5hbCBhcHBlbmQuDQoNCkZyb206IEVyYW4gSGFt bWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV08bWFpbHRvOlttYWlsdG86ZXJh bkBodWVuaXZlcnNlLmNvbV0+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDExIDM6MDMg UE0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBEaWNrIEhhcmR0OyBPQXV0aCBXRyAoPG1haWx0 bzpvYXV0aEBpZXRmLm9yZz5vYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KQ0K U3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnMNCg0KMS4gUHJvY2Vzcy13aXNl IGl0IGRvZXMuIFRoaXMgaXMgYSBicmFuZCBuZXcgY29uY2VwdCAqaGVyZSogYW5kIHdhcyBub3Qg bWVudGlvbmVkIGluIHRoZSBjaGFydGVyIG9yIGFueSB1c2UgY2FzZXMuIFRoZXJlZm9yZSwgb3V0 IG9mIHNjb3BlLg0KDQoyLiBUaGUgY3VycmVudCB0ZXh0IHByb3ZpZGVzIGFsbCB0aGUgaW5mb3Jt YXRpb24gbmVlZGVkIHRvIGltZW1lbnQuIE5vIG9uZSByYWlzZWQgYW4gaW1wbGVtZW50YXRpb24g aXNzdWUgb24gdGhlIGN1cnJlbnQgdGV4dC4NCg0KMy4gUmVmcmVzaCB0b2tlbiBkbyBub3QgcHJv dmlkZSBhbm9ueW1pdHkuIEFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGJ1dCB0aGlzIHdhcyBuZXZl ciBjb25zaWRlcmVkIGluIHRoZSBkZXNpZ24uDQoNCjQuIElmIHlvdSBoYXZlIHN1Z2dlc3RlZCB0 ZXh0LCBwcmVzZW50IGl0IGJlZm9yZSB0aGUgV0dMQyBpcyBvdmVyLiBJIGFtIG5vdCBhZGRpbmcg aXNzdWVzIHRvIG15IGxpc3Qgd2l0aG91dCBzdWdnZXN0ZWQgdGV4dCBhbmQgd2cgY29uc2Vuc3Vz Lg0KDQpFSEwNCg0KT24gQXVnIDExLCAyMDExLCBhdCAxNzo0NCwgIkFudGhvbnkgTmFkYWxpbiIg PDxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPnRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWls dG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGVyZSBhcmUgbm8gdXNlIGNhc2Vz IGF0IGFsbCBpbiBXUkFQIHRvIGhlbHAgZXhwbGFpbiBjaG9pY2VzIHRha2VuLCBpdCBkb2VzIG5v dCBtYXR0ZXIgaWYgdGhlcmUgd2VyZSBvciB3ZXJlIG5vdCBwcmV2aW91cyBpc3N1ZXMgcmFpc2Vk LCBpdCBpcyBiZWluZyByYWlzZWQgbm93Lg0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbbWFp bHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dPG1haWx0bzpbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5j b21dPg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAxOjQ2IFBNDQpUbzogQW50aG9u eSBOYWRhbGluOyBEaWNrIEhhcmR0DQpDYzogT0F1dGggV0cgKDxtYWlsdG86b2F1dGhAaWV0Zi5v cmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikNClN1YmplY3Q6IFJlOiBb T0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zDQoNClRoYXQncyBpcnJlbGV2YW50IGdpdmVuIFdSQVAg ZG9lcyBub3QgbWVudGlvbiBhbm9ueW1pdHkgb3IgYW55dGhpbmcgZWxzZSBhYm91dCByZWZyZXNo IHRva2VuIG5vdCBleHBsaWNpdGx5IGFkZHJlc3NlZCBhbHJlYWR5IGJ5IHYyLiBZb3VyIGVtYWls IGlzIHRoZSB2ZXJ5IGZpcnN0IHRpbWUgdGhpcyBoYXMgYmVlbiByYWlzZWQgb24gdGhpcyBsaXN0 Lg0KDQpFSEwNCg0KRnJvbTogQW50aG9ueSBOYWRhbGluIDw8bWFpbHRvOnRvbnluYWRAbWljcm9z b2Z0LmNvbT50b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNv bT4+DQpEYXRlOiBUaHUsIDExIEF1ZyAyMDExIDEyOjQxOjI4IC0wNzAwDQpUbzogRXJhbiBIYW1t ZXItbGFoYXYgPDxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT5lcmFuQGh1ZW5pdmVyc2UuY29t PG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4sIERpY2sgSGFyZHQgPDxtYWlsdG86ZGljay5o YXJkdEBnbWFpbC5jb20+ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21h aWwuY29tPj4NCkNjOiAiT0F1dGggV0cgKDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikiIDw8bWFpbHRvOm9hdXRoQGlldGYub3JnPm9h dXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW09BVVRI LVdHXSBSZWZyZXNoIFRva2Vucw0KDQpBbm9ueW1pdHkgd2FzIGNlcnRhaW5seSBwYXJ0IG9mIHRo ZSBkZXNpZ24gZm9yIFdSQVANCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYgWzxtYWlsdG86ZXJh bkBodWVuaXZlcnNlLmNvbT5tYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NClNlbnQ6IFRodXJz ZGF5LCBBdWd1c3QgMTEsIDIwMTEgMTI6MzUgUE0NClRvOiBBbnRob255IE5hZGFsaW47IERpY2sg SGFyZHQNCkNjOiBPQXV0aCBXRyAoPG1haWx0bzpvYXV0aEBpZXRmLm9yZz5vYXV0aEBpZXRmLm9y ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVmcmVz aCBUb2tlbnMNCg0KU2VjdGlvbiAxLjUgYWxyZWFkeSBjb3ZlcnMgcmVmcmVzaCB0b2tlbnMuIFRo ZXJlIGFyZSBtYW55IHVzZSBjYXNlcyBmb3IgcmVmcmVzaCB0b2tlbnMuIFRoZXkgYXJlIGJhc2lj YWxseSBhIHByb3RvY29sIGZlYXR1cmUgdXNlZCB0byBtYWtlIHNjYWxhYmlsaXR5IGFuZCBzZWN1 cml0eSBtb3JlIGZsZXhpYmxlLiBBbm9ueW1pdHkgd2FzIG5ldmVyIHBhcnQgb2YgdGhlaXIgZGVz aWduLCBhbmQgYnkgdGhlIG5hdHVyZSBvZiB0aGlzIHByb3RvY29sLCBpcyBtb3JlIGluIHRoZSBk b21haW4gb2YgdGhlIHJlc291cmNlIHNlcnZlciAoYmFzZWQgb24gd2hhdCBpbmZvcm1hdGlvbiBp dCBleHBvc2VzIHZpYSBpdHMgQVBJKS4gSW4gZmFjdCwgeW91ciBlbWFpbCBpZiB0aGUgZmlyc3Qg c3VjaCBzdWdnZXN0aW9uIG9mIGFub255bWl0eS4NCg0KRUhMDQoNCkZyb206IEFudGhvbnkgTmFk YWxpbiA8PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+dG9ueW5hZEBtaWNyb3NvZnQuY29t PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogVGh1LCAxMSBBdWcgMjAxMSAx MToxNToyOCAtMDcwMA0KVG86IERpY2sgSGFyZHQgPDxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5j b20+ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkNj OiAiT0F1dGggV0cgKDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoQGlldGYub3JnPikiIDw8bWFpbHRvOm9hdXRoQGlldGYub3JnPm9hdXRoQGlldGYub3Jn PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZWZyZXNo IFRva2Vucw0KDQpNYW55IHJlYXNvbnMsIGJ1dCBub25lIGFyZSBleHBsYWluZWQgaW4gdGhlIHNw ZWNpZmljYXRpb24NCg0KRnJvbTogRGljayBIYXJkdCBbPG1haWx0bzpkaWNrLmhhcmR0QGdtYWls LmNvbT5tYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0 IDExLCAyMDExIDEwOjUxIEFNDQpUbzogQW50aG9ueSBOYWRhbGluDQpDYzogT0F1dGggV0cgKDxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3Jn PikNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zDQoNCk15IHJlY29sbGVj dGlvbiBvZiByZWZyZXNoIHRva2VucyB3YXMgZm9yIHNlY3VyaXR5IGFuZCByZXZvY2F0aW9uLg0K DQpzZWN1cml0eTogQnkgaGF2aW5nIGEgc2hvcnQgbGl2ZWQgYWNjZXNzIHRva2VuLCBhIGNvbXBy b21pc2VkIGFjY2VzcyB0b2tlbiB3b3VsZCBsaW1pdCB0aGUgdGltZSBhbiBhdHRhY2tlciB3b3Vs ZCBoYXZlIGFjY2Vzcw0KDQpyZXZvY2F0aW9uOiBpZiB0aGUgYWNjZXNzIHRva2VuIGlzIHNlbGYg Y29udGFpbmVkLCBhdXRob3JpemF0aW9uIGNhbiBiZSByZXZva2VkIGJ5IG5vdCBpc3N1aW5nIG5l dyBhY2Nlc3MgdG9rZW5zLiBBIHJlc291cmNlIGRvZXMgbm90IG5lZWQgdG8gcXVlcnkgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIHRvIHNlZSBpZiB0aGUgYWNjZXNzIHRva2VuIGlzIHZhbGlkLlRo aXMgc2ltcGxpZmllcyBhY2Nlc3MgdG9rZW4gdmFsaWRhdGlvbiBhbmQgbWFrZXMgaXQgZWFzaWVy IHRvIHNjYWxlIGFuZCBzdXBwb3J0IG11bHRpcGxlIGF1dGhvcml6YXRpb24gc2VydmVycy4gIFRo ZXJlIGlzIGEgd2luZG93IG9mIHRpbWUgd2hlbiBhbiBhY2Nlc3MgdG9rZW4gaXMgdmFsaWQsIGJ1 dCBhdXRob3JpemF0aW9uIGlzIHJldm9rZWQuDQoNCg0KDQpPbiAyMDExLTA4LTExLCBhdCAxMDo0 MCBBTSwgQW50aG9ueSBOYWRhbGluIHdyb3RlOg0KDQoNCg0KDQoNCg0KTm93aGVyZSBpbiB0aGUg c3BlY2lmaWNhdGlvbiBpcyB0aGVyZSBleHBsYW5hdGlvbiBmb3IgcmVmcmVzaCB0b2tlbnMsIFRo ZSByZWFzb24gdGhhdCB0aGUgUmVmcmVzaCB0b2tlbiB3YXMgaW50cm9kdWNlZCB3YXMgZm9yIGFu b255bWl0eS4gVGhlIHNjZW5hcmlvIGlzIHRoYXQgYSBjbGllbnQgYXNrcyB0aGUgdXNlciBmb3Ig YWNjZXNzLiBUaGUgdXNlciB3YW50cyB0byBncmFudCB0aGUgYWNjZXNzIGJ1dCBub3QgdGVsbCB0 aGUgY2xpZW50IHRoZSB1c2VyJ3MgaWRlbnRpdHkuIEJ5IGlzc3VpbmcgdGhlIHJlZnJlc2ggdG9r ZW4gYXMgYW4gJ2lkZW50aWZpZXInIGZvciB0aGUgdXNlciAoYXMgd2VsbCBhcyBvdGhlciBjb250 ZXh0IGRhdGEgbGlrZSB0aGUgcmVzb3VyY2UpIGl0J3MgcG9zc2libGUgbm93IHRvIGxldCB0aGUg Y2xpZW50IGdldCBhY2Nlc3Mgd2l0aG91dCByZXZlYWxpbmcgYW55dGhpbmcgYWJvdXQgdGhlIHVz ZXIuIFJlY29tbWVuZCB0aGF0IHRoZSBhYm92ZSBleHBsYW5hdGlvbiBiZSBpbmNsdWRlZCBzbyBk ZXZlbG9wZXJzIHVuZGVyc3RhbmQgd2h5IHRoZSByZWZyZXNoIHRva2VucyBhcmUgdGhlcmUuDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQo8bWFpbHRvOk9BdXRoQGlldGYub3JnPk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCjxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_63B2BDD8BAB84B8BB7C672CA0C9C3913hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5Zb3VyIG9yaWdpbmFsIHBvc3QgZG9l cyBub3QgZXhwbGFpbiBob3cgYW5vbnltaXR5IGlzIGFjaGlldmVkIG9yIHdoYXQgaXQgYWN0dWFs bHkgbWVhbnMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ob3Qgd2VhcmluZyBteSBlZGl0b3Ig aGVhdCBJJ20gc3Ryb25nbHkgb3Bwb3NlZCB0byB0aGlzIGVudGlyZSBjb25jZXB0LjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+RUhMPGJyPjxicj5PbiBBdWcgMTEsIDIwMTEsIGF0IDE4OjQ5LCAi QW50aG9ueSBOYWRhbGluIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNv bSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2 PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRpc2FncmVlLCB0aGlzIHdhcyBvdXIgcmF0aW9uYWwgYW5kIHRoaXMg aXMgb25lIHdheSBpdOKAmXMgdXNlZCB0b2RheSB3aXRoIG91ciBzY2VuYXJpb3MuIFRoaXMgbmVl ZHMgdG8gYmUgYXNzaWduZWQgYW4gaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRXJhbiBIYW1t ZXItTGFoYXYgW21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEgMzozOSBQTTxicj4NCjxiPlRvOjwvYj4gQW50aG9u eSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBEaWNrIEhhcmR0OyBPQXV0aCBXRyAoPGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4pPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0ZXh0IGlzIHdyb25nLiBUaGlz IGlzIG5vdCB3aHkgcmVmcmVzaCB0b2tlbnMgd2VyZSBpbnRyb2R1Y2VkIChvcmlnaW5hbGx5IGJ5 IFlhaG9vIHRoZW4gaW4gV1JBUCkuIEFuZCBpcyBhbHNvIHRlY2huaWNhbGx5IHVuZm91bmRlZC4g UmVmcmVzaCB0b2tlbnMgaGF2ZSBubyBzcGVjaWFsIGFub255bWl0eSBwcm9wZXJ0aWVzLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkVITDxicj4NCjxicj4NCk9uIEF1ZyAxMSwgMjAx MSwgYXQgMTg6MTgsICJBbnRob255IE5hZGFsaW4iICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5h ZEBtaWNyb3NvZnQuY29tIj48YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50 b255bmFkQG1pY3Jvc29mdC5jb208L2E+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbSByYWlzaW5nIHRoZSBpc3N1ZSBv biB0aGUgY3VycmVudCB0ZXh0LCBJIGFscmVhZHkgcHJvdmlkZWQgdGV4dCBpZiB0aGUgb3JpZ2lu YWwgYXBwZW5kLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyYW4gSGFtbWVyLUxh aGF2DQo8YSBocmVmPSJtYWlsdG86W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXSI+W21haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tXTwvYT4gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBB dWd1c3QgMTEsIDIwMTEgMzowMyBQTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJy Pg0KPGI+Q2M6PC9iPiBEaWNrIEhhcmR0OyBPQXV0aCBXRyAoPGEgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3Jn PC9hPjwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9r ZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4xLiBQcm9jZXNzLXdpc2UgaXQgZG9lcy4gVGhpcyBpcyBhIGJyYW5kIG5ldyBjb25jZXB0 ICpoZXJlKiBhbmQgd2FzIG5vdCBtZW50aW9uZWQgaW4gdGhlIGNoYXJ0ZXIgb3IgYW55IHVzZSBj YXNlcy4gVGhlcmVmb3JlLCBvdXQgb2Ygc2NvcGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yLiBUaGUgY3VycmVudCB0ZXh0 IHByb3ZpZGVzIGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIGltZW1lbnQuIE5vIG9uZSBy YWlzZWQgYW4gaW1wbGVtZW50YXRpb24gaXNzdWUgb24gdGhlIGN1cnJlbnQgdGV4dC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuIFJl ZnJlc2ggdG9rZW4gZG8gbm90IHByb3ZpZGUgYW5vbnltaXR5LiBBbiBpbXBsZW1lbnRhdGlvbiBj b3VsZCBidXQgdGhpcyB3YXMgbmV2ZXIgY29uc2lkZXJlZCBpbiB0aGUgZGVzaWduLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ NC4gSWYgeW91IGhhdmUgc3VnZ2VzdGVkIHRleHQsIHByZXNlbnQgaXQgYmVmb3JlIHRoZSBXR0xD IGlzIG92ZXIuIEkgYW0gbm90IGFkZGluZyBpc3N1ZXMgdG8gbXkgbGlzdCB3aXRob3V0IHN1Z2dl c3RlZCB0ZXh0IGFuZCB3ZyBjb25zZW5zdXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FSEw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gQXVnIDExLCAyMDExLCBhdCAx Nzo0NCwgIkFudGhvbnkgTmFkYWxpbiIgJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jv c29mdC5jb20iPjxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRA bWljcm9zb2Z0LmNvbTwvYT48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGFyZSBubyB1c2UgY2FzZXMgYXQgYWxsIGlu IFdSQVAgdG8gaGVscCBleHBsYWluIGNob2ljZXMgdGFrZW4sIGl0IGRvZXMgbm90IG1hdHRlciBp ZiB0aGVyZQ0KIHdlcmUgb3Igd2VyZSBub3QgcHJldmlvdXMgaXNzdWVzIHJhaXNlZCwgaXQgaXMg YmVpbmcgcmFpc2VkIG5vdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRXJhbiBIYW1tZXItTGFo YXYNCjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dIj5bbWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb21dPC9hPiA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1 Z3VzdCAxMSwgMjAxMSAxOjQ2IFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW47IERp Y2sgSGFyZHQ8YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86b2F1dGhA aWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8 L2E+PC9hPik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tl bnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhdCdzIGlycmVs ZXZhbnQgZ2l2ZW4gV1JBUCBkb2VzIG5vdCBtZW50aW9uIGFub255bWl0eSBvciBhbnl0aGluZyBl bHNlIGFib3V0IHJlZnJlc2ggdG9rZW4gbm90IGV4cGxpY2l0bHkNCiBhZGRyZXNzZWQgYWxyZWFk eSBieSB2Mi4gWW91ciBlbWFpbCBpcyB0aGUgdmVyeSBmaXJzdCB0aW1lIHRoaXMgaGFzIGJlZW4g cmFpc2VkIG9uIHRoaXMgbGlzdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPkVITDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnlu YWRAbWljcm9zb2Z0LmNvbSI+PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+ dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodSwg MTEgQXVnIDIwMTEgMTI6NDE6MjggLTA3MDA8YnI+DQo8Yj5UbzogPC9iPkVyYW4gSGFtbWVyLWxh aGF2ICZsdDs8YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+PGEgaHJlZj0ibWFp bHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+PC9hPiZndDss IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+PGEg aHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwv YT48L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+Ik9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86b2F1 dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5v cmc8L2E+PC9hPikiICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UkU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0 OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Bbm9ueW1pdHkgd2FzIGNlcnRhaW5seSBwYXJ0IG9mIHRoZSBkZXNpZ24g Zm9yIFdSQVA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4g RXJhbg0KIEhhbW1lci1MYWhhdiBbPGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20i PjxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5tYWlsdG86ZXJhbkBodWVuaXZl cnNlLmNvbTwvYT48L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMTEs IDIwMTEgMTI6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbjsgRGljayBIYXJk dDxicj4NCjxiPkNjOjwvYj4gT0F1dGggV0cgKDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y ZyI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48L2E+ KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vuczwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5TZWN0aW9uIDEuNSBhbHJlYWR5IGNvdmVycyByZWZyZXNoIHRva2Vucy4g VGhlcmUgYXJlIG1hbnkgdXNlIGNhc2VzIGZvciByZWZyZXNoIHRva2Vucy4gVGhleSBhcmUgYmFz aWNhbGx5DQogYSBwcm90b2NvbCBmZWF0dXJlIHVzZWQgdG8gbWFrZSBzY2FsYWJpbGl0eSBhbmQg c2VjdXJpdHkgbW9yZSBmbGV4aWJsZS4gQW5vbnltaXR5IHdhcyBuZXZlciBwYXJ0IG9mIHRoZWly IGRlc2lnbiwgYW5kIGJ5IHRoZSBuYXR1cmUgb2YgdGhpcyBwcm90b2NvbCwgaXMgbW9yZSBpbiB0 aGUgZG9tYWluIG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIgKGJhc2VkIG9uIHdoYXQgaW5mb3JtYXRp b24gaXQgZXhwb3NlcyB2aWEgaXRzIEFQSSkuIEluIGZhY3QsDQogeW91ciBlbWFpbCBpZiB0aGUg Zmlyc3Qgc3VjaCBzdWdnZXN0aW9uIG9mIGFub255bWl0eS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkVITDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRA bWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPjwvYT4mZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPlRodSwgMTEgQXVnIDIwMTEgMTE6MTU6MjggLTA3MDA8YnI+DQo8Yj5UbzogPC9i PkRpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+PGEg aHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwv YT48L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+Ik9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86b2F1 dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5v cmc8L2E+PC9hPikiICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0 OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5NYW55IHJlYXNvbnMsIGJ1dCBub25lIGFyZSBleHBsYWluZWQgaW4gdGhl IHNwZWNpZmljYXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4gRGljaw0KIEhhcmR0IFs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20i PjxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+bWFpbHRvOmRpY2suaGFyZHRA Z21haWwuY29tPC9hPjwvYT5dIDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDEx LCAyMDExIDEwOjUxIEFNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW48YnI+DQo8Yj5D Yzo8L2I+IE9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPik8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5NeSByZWNvbGxlY3Rpb24gb2Yg cmVmcmVzaCB0b2tlbnMgd2FzIGZvciBzZWN1cml0eSBhbmQgcmV2b2NhdGlvbi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5zZWN1cml0 eTogQnkgaGF2aW5nIGEgc2hvcnQgbGl2ZWQgYWNjZXNzIHRva2VuLCBhIGNvbXByb21pc2VkIGFj Y2VzcyB0b2tlbiB3b3VsZCBsaW1pdCB0aGUgdGltZSBhbiBhdHRhY2tlciB3b3VsZCBoYXZlIGFj Y2Vzczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+cmV2b2NhdGlvbjogaWYgdGhlIGFjY2VzcyB0b2tlbiBpcyBzZWxmIGNv bnRhaW5lZCwgYXV0aG9yaXphdGlvbiBjYW4gYmUgcmV2b2tlZCBieSBub3QgaXNzdWluZyBuZXcg YWNjZXNzIHRva2Vucy4gQSByZXNvdXJjZSBkb2VzIG5vdCBuZWVkIHRvIHF1ZXJ5IHRoZQ0KIGF1 dGhvcml6YXRpb24gc2VydmVyIHRvIHNlZSBpZiB0aGUgYWNjZXNzIHRva2VuIGlzIHZhbGlkLlRo aXMgc2ltcGxpZmllcyBhY2Nlc3MgdG9rZW4gdmFsaWRhdGlvbiBhbmQgbWFrZXMgaXQgZWFzaWVy IHRvIHNjYWxlIGFuZCBzdXBwb3J0IG11bHRpcGxlIGF1dGhvcml6YXRpb24gc2VydmVycy4mbmJz cDsmbmJzcDtUaGVyZSBpcyBhIHdpbmRvdyBvZiB0aW1lIHdoZW4gYW4gYWNjZXNzIHRva2VuIGlz IHZhbGlkLCBidXQgYXV0aG9yaXphdGlvbiBpcyByZXZva2VkLiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5PbiAyMDExLTA4LTExLCBhdCAxMDo0MCBBTSwgQW50aG9ueSBOYWRhbGluIHdyb3RlOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5vd2hlcmUgaW4g dGhlIHNwZWNpZmljYXRpb24gaXMgdGhlcmUgZXhwbGFuYXRpb24gZm9yIHJlZnJlc2ggdG9rZW5z LCBUaGUgcmVhc29uIHRoYXQgdGhlIFJlZnJlc2ggdG9rZW4NCiB3YXMgaW50cm9kdWNlZCB3YXMg Zm9yIGFub255bWl0eS4gVGhlIHNjZW5hcmlvIGlzIHRoYXQgYSBjbGllbnQgYXNrcyB0aGUgdXNl ciBmb3IgYWNjZXNzLiBUaGUgdXNlciB3YW50cyB0byBncmFudCB0aGUgYWNjZXNzIGJ1dCBub3Qg dGVsbCB0aGUgY2xpZW50IHRoZSB1c2VyJ3MgaWRlbnRpdHkuIEJ5IGlzc3VpbmcgdGhlIHJlZnJl c2ggdG9rZW4gYXMgYW4gJ2lkZW50aWZpZXInIGZvciB0aGUgdXNlciAoYXMgd2VsbCBhcyBvdGhl ciBjb250ZXh0DQogZGF0YSBsaWtlIHRoZSByZXNvdXJjZSkgaXQncyBwb3NzaWJsZSBub3cgdG8g bGV0IHRoZSBjbGllbnQgZ2V0IGFjY2VzcyB3aXRob3V0IHJldmVhbGluZyBhbnl0aGluZyBhYm91 dCB0aGUgdXNlci4gUmVjb21tZW5kIHRoYXQgdGhlIGFib3ZlIGV4cGxhbmF0aW9uIGJlIGluY2x1 ZGVkIHNvIGRldmVsb3BlcnMgdW5kZXJzdGFuZCB3aHkgdGhlIHJlZnJlc2ggdG9rZW5zIGFyZSB0 aGVyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQoNCg0KPC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_63B2BDD8BAB84B8BB7C672CA0C9C3913hueniversecom_-- From eran@hueniverse.com Thu Aug 11 16:28:57 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC5A11E809B for ; Thu, 11 Aug 2011 16:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdDiMwV6vJPh for ; Thu, 11 Aug 2011 16:28:56 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7BC3411E8099 for ; Thu, 11 Aug 2011 16:28:56 -0700 (PDT) Received: (qmail 25594 invoked from network); 11 Aug 2011 23:29:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Aug 2011 23:29:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 11 Aug 2011 16:28:58 -0700 From: Eran Hammer-Lahav To: "William J. Mills" Date: Thu, 11 Aug 2011 16:28:53 -0700 Thread-Topic: [OAUTH-WG] Refresh Tokens Thread-Index: AcxYfnGgpKpm7AifR6ieoU/L7DU5yg== Message-ID: References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com> In-Reply-To: <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D76A379AA43F47429488D64FF2A931AEhueniversecom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 23:28:57 -0000 --_000_D76A379AA43F47429488D64FF2A931AEhueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdHJvbmdseSBhZ3JlZS4gSSBkb24ndCBzZWUgd2hhdCB2YWx1ZSB0aGVyZSBpcyBpbiBkaXNj dXNzaW5nIGFub255bWl0eSB3aGljaCBicmluZ3MgaWRlbnRpdHkgaW50byB0aGUgc3BlYyB3aXRo b3V0IGFueSBqdXN0aWZpY2F0aW9uLg0KDQpFSEwNCg0KT24gQXVnIDExLCAyMDExLCBhdCAxOToy NiwgIldpbGxpYW0gSi4gTWlsbHMiIDx3bWlsbHNAeWFob28taW5jLmNvbTxtYWlsdG86d21pbGxz QHlhaG9vLWluYy5jb20+PiB3cm90ZToNCg0KSXQncyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4g IFlvdSBjYW4gY2hvb3NlIHRvIG1ha2UgdGhlbSBhbm9ueW1vdXMgb3IgeW91IGNhbiBpc3N1ZSBz aWduZWQgcGxhaW50ZXh0IHRva2VucyB0aGF0IGNvbmNlYWwgbm90aGluZy4gIFRoZSBzcGVjIGRv ZXNuJ3QgY2FyZS4gIEl0J3MgYSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIG9mIHRoZSBlbmQgaW1w bGVtZW50YXRpb24sIGp1c3QgbGlrZSB0aGUgbmVlZCBmb3IgdGFtcGVyIHByb3RlY3Rpb24uICBU aGUgc3BlYyBuZWVkcyBvbmx5IHRvIGRlZmluZSB0aGVtIGFzIG9wYXF1ZSBibG9icyB3aXRoIGEg cGFydGljdWxhciBzeW50YXguICBXZSBhcmUgbm90IHNwZWNpZnlpbmcgd2hhdCBlbmNyeXB0aW9u IHlvdSBoYXZlIHRvIHVzZSBoZXJlLCBhbmQgd2Ugc2hvdWxkIG5vdC4NCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRA bWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4NClRvOiBFcmFuIEhh bW1lci1MYWhhdiA8ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNv bT4+DQpDYzogIk9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ KSIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTZW50OiBUaHVyc2Rh eSwgQXVndXN0IDExLCAyMDExIDM6NDUgUE0NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZnJl c2ggVG9rZW5zDQoNCkRpc2FncmVlLCB0aGlzIHdhcyBvdXIgcmF0aW9uYWwgYW5kIHRoaXMgaXMg b25lIHdheSBpdOKAmXMgdXNlZCB0b2RheSB3aXRoIG91ciBzY2VuYXJpb3MuIFRoaXMgbmVlZHMg dG8gYmUgYXNzaWduZWQgYW4gaXNzdWUuDQoNCkZyb206IEVyYW4gSGFtbWVyLUxhaGF2IFttYWls dG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEg MzozOSBQTQ0KVG86IEFudGhvbnkgTmFkYWxpbg0KQ2M6IERpY2sgSGFyZHQ7IE9BdXRoIFdHIChv YXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gUmVmcmVzaCBUb2tlbnMNCg0KVGhlIHRleHQgaXMgd3JvbmcuIFRoaXMgaXMgbm90IHdo eSByZWZyZXNoIHRva2VucyB3ZXJlIGludHJvZHVjZWQgKG9yaWdpbmFsbHkgYnkgWWFob28gdGhl biBpbiBXUkFQKS4gQW5kIGlzIGFsc28gdGVjaG5pY2FsbHkgdW5mb3VuZGVkLiBSZWZyZXNoIHRv a2VucyBoYXZlIG5vIHNwZWNpYWwgYW5vbnltaXR5IHByb3BlcnRpZXMuDQoNCkVITA0KDQpPbiBB dWcgMTEsIDIwMTEsIGF0IDE4OjE4LCAiQW50aG9ueSBOYWRhbGluIiA8PG1haWx0bzp0b255bmFk QG1pY3Jvc29mdC5jb20+dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jv c29mdC5jb20+PiB3cm90ZToNCknigJltIHJhaXNpbmcgdGhlIGlzc3VlIG9uIHRoZSBjdXJyZW50 IHRleHQsIEkgYWxyZWFkeSBwcm92aWRlZCB0ZXh0IGlmIHRoZSBvcmlnaW5hbCBhcHBlbmQuDQoN CkZyb206IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV08bWFp bHRvOlttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0 IDExLCAyMDExIDM6MDMgUE0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBEaWNrIEhhcmR0OyBP QXV0aCBXRyAoPG1haWx0bzpvYXV0aEBpZXRmLm9yZz5vYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1 dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnMNCg0K MS4gUHJvY2Vzcy13aXNlIGl0IGRvZXMuIFRoaXMgaXMgYSBicmFuZCBuZXcgY29uY2VwdCAqaGVy ZSogYW5kIHdhcyBub3QgbWVudGlvbmVkIGluIHRoZSBjaGFydGVyIG9yIGFueSB1c2UgY2FzZXMu IFRoZXJlZm9yZSwgb3V0IG9mIHNjb3BlLg0KDQoyLiBUaGUgY3VycmVudCB0ZXh0IHByb3ZpZGVz IGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIGltZW1lbnQuIE5vIG9uZSByYWlzZWQgYW4g aW1wbGVtZW50YXRpb24gaXNzdWUgb24gdGhlIGN1cnJlbnQgdGV4dC4NCg0KMy4gUmVmcmVzaCB0 b2tlbiBkbyBub3QgcHJvdmlkZSBhbm9ueW1pdHkuIEFuIGltcGxlbWVudGF0aW9uIGNvdWxkIGJ1 dCB0aGlzIHdhcyBuZXZlciBjb25zaWRlcmVkIGluIHRoZSBkZXNpZ24uDQoNCjQuIElmIHlvdSBo YXZlIHN1Z2dlc3RlZCB0ZXh0LCBwcmVzZW50IGl0IGJlZm9yZSB0aGUgV0dMQyBpcyBvdmVyLiBJ IGFtIG5vdCBhZGRpbmcgaXNzdWVzIHRvIG15IGxpc3Qgd2l0aG91dCBzdWdnZXN0ZWQgdGV4dCBh bmQgd2cgY29uc2Vuc3VzLg0KDQpFSEwNCg0KT24gQXVnIDExLCAyMDExLCBhdCAxNzo0NCwgIkFu dGhvbnkgTmFkYWxpbiIgPDxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPnRvbnluYWRAbWlj cm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUaGVyZSBh cmUgbm8gdXNlIGNhc2VzIGF0IGFsbCBpbiBXUkFQIHRvIGhlbHAgZXhwbGFpbiBjaG9pY2VzIHRh a2VuLCBpdCBkb2VzIG5vdCBtYXR0ZXIgaWYgdGhlcmUgd2VyZSBvciB3ZXJlIG5vdCBwcmV2aW91 cyBpc3N1ZXMgcmFpc2VkLCBpdCBpcyBiZWluZyByYWlzZWQgbm93Lg0KDQpGcm9tOiBFcmFuIEhh bW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dPG1haWx0bzpbbWFpbHRvOmVy YW5AaHVlbml2ZXJzZS5jb21dPg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAxOjQ2 IFBNDQpUbzogQW50aG9ueSBOYWRhbGluOyBEaWNrIEhhcmR0DQpDYzogT0F1dGggV0cgKDxtYWls dG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikN ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zDQoNClRoYXQncyBpcnJlbGV2 YW50IGdpdmVuIFdSQVAgZG9lcyBub3QgbWVudGlvbiBhbm9ueW1pdHkgb3IgYW55dGhpbmcgZWxz ZSBhYm91dCByZWZyZXNoIHRva2VuIG5vdCBleHBsaWNpdGx5IGFkZHJlc3NlZCBhbHJlYWR5IGJ5 IHYyLiBZb3VyIGVtYWlsIGlzIHRoZSB2ZXJ5IGZpcnN0IHRpbWUgdGhpcyBoYXMgYmVlbiByYWlz ZWQgb24gdGhpcyBsaXN0Lg0KDQpFSEwNCg0KRnJvbTogQW50aG9ueSBOYWRhbGluIDw8bWFpbHRv OnRvbnluYWRAbWljcm9zb2Z0LmNvbT50b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnlu YWRAbWljcm9zb2Z0LmNvbT4+DQpEYXRlOiBUaHUsIDExIEF1ZyAyMDExIDEyOjQxOjI4IC0wNzAw DQpUbzogRXJhbiBIYW1tZXItbGFoYXYgPDxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT5lcmFu QGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4sIERpY2sgSGFyZHQg PDxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRv OmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkNjOiAiT0F1dGggV0cgKDxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikiIDw8bWFpbHRvOm9h dXRoQGlldGYub3JnPm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSRTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vucw0KDQpBbm9ueW1pdHkgd2FzIGNlcnRh aW5seSBwYXJ0IG9mIHRoZSBkZXNpZ24gZm9yIFdSQVANCg0KRnJvbTogRXJhbiBIYW1tZXItTGFo YXYgWzxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT5tYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNv bV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEgMTI6MzUgUE0NClRvOiBBbnRob255 IE5hZGFsaW47IERpY2sgSGFyZHQNCkNjOiBPQXV0aCBXRyAoPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz5vYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtP QVVUSC1XR10gUmVmcmVzaCBUb2tlbnMNCg0KU2VjdGlvbiAxLjUgYWxyZWFkeSBjb3ZlcnMgcmVm cmVzaCB0b2tlbnMuIFRoZXJlIGFyZSBtYW55IHVzZSBjYXNlcyBmb3IgcmVmcmVzaCB0b2tlbnMu IFRoZXkgYXJlIGJhc2ljYWxseSBhIHByb3RvY29sIGZlYXR1cmUgdXNlZCB0byBtYWtlIHNjYWxh YmlsaXR5IGFuZCBzZWN1cml0eSBtb3JlIGZsZXhpYmxlLiBBbm9ueW1pdHkgd2FzIG5ldmVyIHBh cnQgb2YgdGhlaXIgZGVzaWduLCBhbmQgYnkgdGhlIG5hdHVyZSBvZiB0aGlzIHByb3RvY29sLCBp cyBtb3JlIGluIHRoZSBkb21haW4gb2YgdGhlIHJlc291cmNlIHNlcnZlciAoYmFzZWQgb24gd2hh dCBpbmZvcm1hdGlvbiBpdCBleHBvc2VzIHZpYSBpdHMgQVBJKS4gSW4gZmFjdCwgeW91ciBlbWFp bCBpZiB0aGUgZmlyc3Qgc3VjaCBzdWdnZXN0aW9uIG9mIGFub255bWl0eS4NCg0KRUhMDQoNCkZy b206IEFudGhvbnkgTmFkYWxpbiA8PG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+dG9ueW5h ZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+Pg0KRGF0ZTogVGh1 LCAxMSBBdWcgMjAxMSAxMToxNToyOCAtMDcwMA0KVG86IERpY2sgSGFyZHQgPDxtYWlsdG86ZGlj ay5oYXJkdEBnbWFpbC5jb20+ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRA Z21haWwuY29tPj4NCkNjOiAiT0F1dGggV0cgKDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhA aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikiIDw8bWFpbHRvOm9hdXRoQGlldGYub3Jn Pm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW09B VVRILVdHXSBSZWZyZXNoIFRva2Vucw0KDQpNYW55IHJlYXNvbnMsIGJ1dCBub25lIGFyZSBleHBs YWluZWQgaW4gdGhlIHNwZWNpZmljYXRpb24NCg0KRnJvbTogRGljayBIYXJkdCBbPG1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbT5tYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb21dDQpTZW50OiBU aHVyc2RheSwgQXVndXN0IDExLCAyMDExIDEwOjUxIEFNDQpUbzogQW50aG9ueSBOYWRhbGluDQpD YzogT0F1dGggV0cgKDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRv Om9hdXRoQGlldGYub3JnPikNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5z DQoNCk15IHJlY29sbGVjdGlvbiBvZiByZWZyZXNoIHRva2VucyB3YXMgZm9yIHNlY3VyaXR5IGFu ZCByZXZvY2F0aW9uLg0KDQpzZWN1cml0eTogQnkgaGF2aW5nIGEgc2hvcnQgbGl2ZWQgYWNjZXNz IHRva2VuLCBhIGNvbXByb21pc2VkIGFjY2VzcyB0b2tlbiB3b3VsZCBsaW1pdCB0aGUgdGltZSBh biBhdHRhY2tlciB3b3VsZCBoYXZlIGFjY2Vzcw0KDQpyZXZvY2F0aW9uOiBpZiB0aGUgYWNjZXNz IHRva2VuIGlzIHNlbGYgY29udGFpbmVkLCBhdXRob3JpemF0aW9uIGNhbiBiZSByZXZva2VkIGJ5 IG5vdCBpc3N1aW5nIG5ldyBhY2Nlc3MgdG9rZW5zLiBBIHJlc291cmNlIGRvZXMgbm90IG5lZWQg dG8gcXVlcnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIHNlZSBpZiB0aGUgYWNjZXNzIHRv a2VuIGlzIHZhbGlkLlRoaXMgc2ltcGxpZmllcyBhY2Nlc3MgdG9rZW4gdmFsaWRhdGlvbiBhbmQg bWFrZXMgaXQgZWFzaWVyIHRvIHNjYWxlIGFuZCBzdXBwb3J0IG11bHRpcGxlIGF1dGhvcml6YXRp b24gc2VydmVycy4gIFRoZXJlIGlzIGEgd2luZG93IG9mIHRpbWUgd2hlbiBhbiBhY2Nlc3MgdG9r ZW4gaXMgdmFsaWQsIGJ1dCBhdXRob3JpemF0aW9uIGlzIHJldm9rZWQuDQoNCg0KDQpPbiAyMDEx LTA4LTExLCBhdCAxMDo0MCBBTSwgQW50aG9ueSBOYWRhbGluIHdyb3RlOg0KDQoNCg0KDQoNCg0K Tm93aGVyZSBpbiB0aGUgc3BlY2lmaWNhdGlvbiBpcyB0aGVyZSBleHBsYW5hdGlvbiBmb3IgcmVm cmVzaCB0b2tlbnMsIFRoZSByZWFzb24gdGhhdCB0aGUgUmVmcmVzaCB0b2tlbiB3YXMgaW50cm9k dWNlZCB3YXMgZm9yIGFub255bWl0eS4gVGhlIHNjZW5hcmlvIGlzIHRoYXQgYSBjbGllbnQgYXNr cyB0aGUgdXNlciBmb3IgYWNjZXNzLiBUaGUgdXNlciB3YW50cyB0byBncmFudCB0aGUgYWNjZXNz IGJ1dCBub3QgdGVsbCB0aGUgY2xpZW50IHRoZSB1c2VyJ3MgaWRlbnRpdHkuIEJ5IGlzc3Vpbmcg dGhlIHJlZnJlc2ggdG9rZW4gYXMgYW4gJ2lkZW50aWZpZXInIGZvciB0aGUgdXNlciAoYXMgd2Vs bCBhcyBvdGhlciBjb250ZXh0IGRhdGEgbGlrZSB0aGUgcmVzb3VyY2UpIGl0J3MgcG9zc2libGUg bm93IHRvIGxldCB0aGUgY2xpZW50IGdldCBhY2Nlc3Mgd2l0aG91dCByZXZlYWxpbmcgYW55dGhp bmcgYWJvdXQgdGhlIHVzZXIuIFJlY29tbWVuZCB0aGF0IHRoZSBhYm92ZSBleHBsYW5hdGlvbiBi ZSBpbmNsdWRlZCBzbyBkZXZlbG9wZXJzIHVuZGVyc3RhbmQgd2h5IHRoZSByZWZyZXNoIHRva2Vu cyBhcmUgdGhlcmUuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQo8bWFpbHRvOk9BdXRoQGlldGYub3JnPk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCjxodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29hdXRoPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQo8bWFpbHRvOk9BdXRoQGlldGYub3JnPk9BdXRoQGlldGYu b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCjxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0KDQo= --_000_D76A379AA43F47429488D64FF2A931AEhueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5JIHN0cm9uZ2x5IGFncmVlLiBJIGRv bid0IHNlZSB3aGF0IHZhbHVlIHRoZXJlIGlzIGluIGRpc2N1c3NpbmcgYW5vbnltaXR5IHdoaWNo IGJyaW5ncyBpZGVudGl0eSBpbnRvIHRoZSBzcGVjIHdpdGhvdXQgYW55IGp1c3RpZmljYXRpb24u ICZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RUhMPGJyPjxicj5PbiBBdWcgMTEsIDIw MTEsIGF0IDE5OjI2LCAiV2lsbGlhbSBKLiBNaWxscyIgJmx0OzxhIGhyZWY9Im1haWx0bzp3bWls bHNAeWFob28taW5jLmNvbSI+d21pbGxzQHlhaG9vLWluYy5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48ZGl2IHN0 eWxlPSJjb2xvcjojMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiNmZmY7IGZvbnQtZmFtaWx5OkNvdXJp ZXIgTmV3LCBjb3VyaWVyLCBtb25hY28sIG1vbm9zcGFjZSwgc2Fucy1zZXJpZjtmb250LXNpemU6 MTBwdCI+PGRpdj48c3Bhbj5JdCdzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLiZuYnNwOyBZb3Ug Y2FuIGNob29zZSB0byBtYWtlIHRoZW0gYW5vbnltb3VzIG9yIHlvdSBjYW4gaXNzdWUgc2lnbmVk IHBsYWludGV4dCB0b2tlbnMgdGhhdCBjb25jZWFsIG5vdGhpbmcuJm5ic3A7IFRoZSBzcGVjIGRv ZXNuJ3QgY2FyZS4mbmJzcDsgSXQncyBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gb2YgdGhlIGVu ZCBpbXBsZW1lbnRhdGlvbiwganVzdCBsaWtlIHRoZSBuZWVkIGZvciB0YW1wZXIgcHJvdGVjdGlv bi4mbmJzcDsgVGhlIHNwZWMgbmVlZHMgb25seSB0byBkZWZpbmUgdGhlbSBhcyBvcGFxdWUgYmxv YnMgd2l0aCBhIHBhcnRpY3VsYXIgc3ludGF4LiZuYnNwOyBXZSBhcmUgbm90IHNwZWNpZnlpbmcg d2hhdCBlbmNyeXB0aW9uIHlvdSBoYXZlIHRvIHVzZSBoZXJlLCBhbmQgd2Ugc2hvdWxkIG5vdC48 L3NwYW4+PC9kaXY+PGRpdj48YnI+PHNwYW4+PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+PGJyPjwv c3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ291cmll ciBOZXcsIGNvdXJpZXIsIG1vbmFjbywgbW9ub3NwYWNlLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDEwcHQ7Ij48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9y aywgdGltZXMsIHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6 ZT0iMiI+PGhyIHNpemU9IjEiPjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkOyI+RnJv bTo8L3NwYW4+PC9iPiBBbnRob255IE5hZGFsaW4NCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnlu YWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+VG86PC9zcGFuPjwvYj4gRXJhbiBIYW1tZXIt TGFoYXYgJmx0OzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5p dmVyc2UuY29tPC9hPiZndDs8YnI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+ Q2M6PC9zcGFuPjwvYj4gIk9BdXRoIFdHICg8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci Pm9hdXRoQGlldGYub3JnPC9hPikiICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci Pm9hdXRoQGlldGYub3JnPC9hPiZndDs8YnI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBi b2xkOyI+U2VudDo8L3NwYW4+PC9iPiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDExIDM6NDUgUE08 YnI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+U3ViamVjdDo8L3NwYW4+PC9i PiBSZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vuczxicj48L2ZvbnQ+PGJyPjxkaXYgaWQ9Inlp djE1NzQ2NjU5NzUiPg0KDQogDQogDQo8c3R5bGU+PCEtLQ0KI3lpdjE1NzQ2NjU5NzUgIA0KIF9m aWx0ZXJlZCAjeWl2MTU3NDY2NTk3NSB7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KcGFub3NlLTE6 MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KIF9maWx0ZXJlZCAjeWl2MTU3NDY2NTk3NSB7Zm9udC1m YW1pbHk6SGVsdmV0aWNhOw0KcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KIF9maWx0 ZXJlZCAjeWl2MTU3NDY2NTk3NSB7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCnBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCiBfZmlsdGVyZWQgI3lpdjE1NzQ2NjU5NzUge2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCnBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCiN5aXYxNTc0NjY1OTc1 ICANCiN5aXYxNTc0NjY1OTc1IHAueWl2MTU3NDY2NTk3NU1zb05vcm1hbCwgI3lpdjE1NzQ2NjU5 NzUgbGkueWl2MTU3NDY2NTk3NU1zb05vcm1hbCwgI3lpdjE1NzQ2NjU5NzUgZGl2LnlpdjE1NzQ2 NjU5NzVNc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCm1hcmdpbi1ib3R0b206LjAwMDFwdDsNCmZv bnQtc2l6ZToxMi4wcHQ7DQpmb250LWZhbWlseToic2VyaWYiO30NCiN5aXYxNTc0NjY1OTc1IGE6 bGluaywgI3lpdjE1NzQ2NjU5NzUgc3Bhbi55aXYxNTc0NjY1OTc1TXNvSHlwZXJsaW5rDQoJew0K Y29sb3I6Ymx1ZTsNCnRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KI3lpdjE1NzQ2NjU5NzUg YTp2aXNpdGVkLCAjeWl2MTU3NDY2NTk3NSBzcGFuLnlpdjE1NzQ2NjU5NzVNc29IeXBlcmxpbmtG b2xsb3dlZA0KCXsNCmNvbG9yOnB1cnBsZTsNCnRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K I3lpdjE1NzQ2NjU5NzUgcC55aXYxNTc0NjY1OTc1TXNvQWNldGF0ZSwgI3lpdjE1NzQ2NjU5NzUg bGkueWl2MTU3NDY2NTk3NU1zb0FjZXRhdGUsICN5aXYxNTc0NjY1OTc1IGRpdi55aXYxNTc0NjY1 OTc1TXNvQWNldGF0ZQ0KCXsNCg0KbWFyZ2luOjBpbjsNCm1hcmdpbi1ib3R0b206LjAwMDFwdDsN CmZvbnQtc2l6ZTo4LjBwdDsNCmZvbnQtZmFtaWx5OiJzYW5zLXNlcmlmIjt9DQojeWl2MTU3NDY2 NTk3NSBzcGFuLnlpdjE1NzQ2NjU5NzVCYWxsb29uVGV4dENoYXINCgl7DQoNCg0KZm9udC1mYW1p bHk6InNhbnMtc2VyaWYiO30NCiN5aXYxNTc0NjY1OTc1IHNwYW4ueWl2MTU3NDY2NTk3NUVtYWls U3R5bGUxOQ0KCXsNCmZvbnQtZmFtaWx5OiJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0Q7fQ0K I3lpdjE1NzQ2NjU5NzUgLnlpdjE1NzQ2NjU5NzVNc29DaHBEZWZhdWx0DQoJew0KZm9udC1zaXpl OjEwLjBwdDt9DQogX2ZpbHRlcmVkICN5aXYxNTc0NjY1OTc1IHsNCm1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQojeWl2MTU3NDY2NTk3NSBkaXYueWl2MTU3NDY2NTk3NVdvcmRTZWN0 aW9uMQ0KCXt9DQotLT48L3N0eWxlPg0KDQogDQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1V29y ZFNlY3Rpb24xIj4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7Ij5EaXNhZ3JlZSwgdGhpcyB3YXMg b3VyIHJhdGlvbmFsIGFuZCB0aGlzIGlzIG9uZSB3YXkgaXTigJlzIHVzZWQgdG9kYXkgd2l0aCBv dXIgc2NlbmFyaW9zLiBUaGlzIG5lZWRzIHRvIGJlIGFzc2lnbmVkIGFuIGlzc3VlLjwvc3Bhbj48 L2Rpdj4gDQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEOyI+ICZuYnNwOzwvc3Bhbj48L2Rpdj4gDQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ij4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5 NzVNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyI+IEVyYW4gSGFtbWVyLUxhaGF2 IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgQXVndXN0IDExLCAyMDExIDM6MzkgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxp bjxicj4NCjxiPkNjOjwvYj4gRGljayBIYXJkdDsgT0F1dGggV0cgKDxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vuczwvc3Bhbj48L2Rpdj4gDQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCI+ICZuYnNwOzwvZGl2PiANCjxk aXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFsIj5UaGUgdGV4dCBpcyB3cm9u Zy4gVGhpcyBpcyBub3Qgd2h5IHJlZnJlc2ggdG9rZW5zIHdlcmUgaW50cm9kdWNlZCAob3JpZ2lu YWxseSBieSBZYWhvbyB0aGVuIGluIFdSQVApLiBBbmQgaXMgYWxzbyB0ZWNobmljYWxseSB1bmZv dW5kZWQuIFJlZnJlc2ggdG9rZW5zIGhhdmUgbm8gc3BlY2lhbCBhbm9ueW1pdHkgcHJvcGVydGll cy4mbmJzcDs8L2Rpdj4gDQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1 TXNvTm9ybWFsIj4gJm5ic3A7PC9kaXY+IA0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ieWl2 MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0OyI+RUhMPGJy Pg0KPGJyPg0KT24gQXVnIDExLCAyMDExLCBhdCAxODoxOCwgIkFudGhvbnkgTmFkYWxpbiIgJmx0 OzxhIHJlbD0ibm9mb2xsb3ciIHltYWlsdG89Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20i IHRhcmdldD0iX2JsYW5rIiBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj48YSBo cmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208 L2E+PC9hPiZndDsgd3JvdGU6PC9kaXY+IA0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYg Y2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7Ij5J4oCZbSByYWlzaW5nIHRoZSBpc3N1ZSBvbiB0 aGUgY3VycmVudCB0ZXh0LCBJIGFscmVhZHkgcHJvdmlkZWQgdGV4dCBpZiB0aGUgb3JpZ2luYWwg YXBwZW5kLiZuYnNwOw0KPC9zcGFuPjwvZGl2PiANCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVN c29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMx RjQ5N0Q7Ij4mbmJzcDs8L3NwYW4+PC9kaXY+IA0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluOyI+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFsIiBzdHlsZT0iIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDsiPiBFcmFuIEhhbW1lci1MYWhhdg0KPGEgcmVsPSJub2ZvbGxv dyIgeW1haWx0bz0ibWFpbHRvOlttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0iIHRhcmdldD0i X2JsYW5rIiBocmVmPSJtYWlsdG86W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXSI+W21haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tXTwvYT4gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBB dWd1c3QgMTEsIDIwMTEgMzowMyBQTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJy Pg0KPGI+Q2M6PC9iPiBEaWNrIEhhcmR0OyBPQXV0aCBXRyAoPGEgcmVsPSJub2ZvbGxvdyIgeW1h aWx0bz0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRv Om9hdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGll dGYub3JnPC9hPjwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlZnJl c2ggVG9rZW5zPC9zcGFuPjwvZGl2PiANCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ5aXYx NTc0NjY1OTc1TXNvTm9ybWFsIiBzdHlsZT0iIj4mbmJzcDs8L2Rpdj4gDQo8ZGl2Pg0KPGRpdiBj bGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9IiI+MS4gUHJvY2Vzcy13aXNlIGl0 IGRvZXMuIFRoaXMgaXMgYSBicmFuZCBuZXcgY29uY2VwdCAqaGVyZSogYW5kIHdhcyBub3QgbWVu dGlvbmVkIGluIHRoZSBjaGFydGVyIG9yIGFueSB1c2UgY2FzZXMuIFRoZXJlZm9yZSwgb3V0IG9m IHNjb3BlLiZuYnNwOzwvZGl2PiANCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2 NjU5NzVNc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwvZGl2PiANCjwvZGl2Pg0KPGRpdj4NCjxk aXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwiIHN0eWxlPSIiPjIuIFRoZSBjdXJyZW50 IHRleHQgcHJvdmlkZXMgYWxsIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgdG8gaW1lbWVudC4gTm8g b25lIHJhaXNlZCBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZSBvbiB0aGUgY3VycmVudCB0ZXh0Ljwv ZGl2PiANCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwi IHN0eWxlPSIiPiZuYnNwOzwvZGl2PiANCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9InlpdjE1 NzQ2NjU5NzVNc29Ob3JtYWwiIHN0eWxlPSIiPjMuIFJlZnJlc2ggdG9rZW4gZG8gbm90IHByb3Zp ZGUgYW5vbnltaXR5LiBBbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBidXQgdGhpcyB3YXMgbmV2ZXIg Y29uc2lkZXJlZCBpbiB0aGUgZGVzaWduLiZuYnNwOzwvZGl2PiANCjwvZGl2Pg0KPGRpdj4NCjxk aXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwvZGl2PiAN CjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwiIHN0eWxl PSIiPjQuIElmIHlvdSBoYXZlIHN1Z2dlc3RlZCB0ZXh0LCBwcmVzZW50IGl0IGJlZm9yZSB0aGUg V0dMQyBpcyBvdmVyLiBJIGFtIG5vdCBhZGRpbmcgaXNzdWVzIHRvIG15IGxpc3Qgd2l0aG91dCBz dWdnZXN0ZWQgdGV4dCBhbmQgd2cgY29uc2Vuc3VzLiZuYnNwOzwvZGl2PiANCjwvZGl2Pg0KPGRp dj4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwv ZGl2PiANCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwi IHN0eWxlPSIiPkVITDwvZGl2PiANCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2 NjU5NzVNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDsiPjxicj4NCk9uIEF1 ZyAxMSwgMjAxMSwgYXQgMTc6NDQsICJBbnRob255IE5hZGFsaW4iICZsdDs8YSByZWw9Im5vZm9s bG93IiB5bWFpbHRvPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFu ayIgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+PGEgaHJlZj0ibWFpbHRvOnRv bnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPjwvYT4mZ3Q7IHdy b3RlOjwvZGl2PiANCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdDsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0 NjY1OTc1TXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMUY0OTdEOyI+VGhlcmUgYXJlIG5vIHVzZSBjYXNlcyBhdCBhbGwgaW4gV1JBUCB0byBo ZWxwIGV4cGxhaW4gY2hvaWNlcyB0YWtlbiwgaXQgZG9lcyBub3QgbWF0dGVyIGlmIHRoZXJlDQog d2VyZSBvciB3ZXJlIG5vdCBwcmV2aW91cyBpc3N1ZXMgcmFpc2VkLCBpdCBpcyBiZWluZyByYWlz ZWQgbm93Ljwvc3Bhbj48L2Rpdj4gDQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFs IiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEOyI+ Jm5ic3A7PC9zcGFuPjwvZGl2PiANCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjsiPg0K PGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9IiI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Ij4gRXJhbiBIYW1tZXItTGFoYXYNCjxhIHJlbD0ibm9mb2xsb3ciIHltYWls dG89Im1haWx0bzpbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dIiB0YXJnZXQ9Il9ibGFuayIg aHJlZj0ibWFpbHRvOlttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0iPlttYWlsdG86ZXJhbkBo dWVuaXZlcnNlLmNvbV08L2E+IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDEx LCAyMDExIDE6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbjsgRGljayBIYXJk dDxicj4NCjxiPkNjOjwvYj4gT0F1dGggV0cgKDxhIHJlbD0ibm9mb2xsb3ciIHltYWlsdG89Im1h aWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzpvYXV0aEBp ZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwv YT48L2E+KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZWZyZXNoIFRva2Vu czwvc3Bhbj48L2Rpdj4gDQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3 NU1zb05vcm1hbCIgc3R5bGU9IiI+Jm5ic3A7PC9kaXY+IA0KPGRpdj4NCjxkaXYgY2xhc3M9Inlp djE1NzQ2NjU5NzVNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrOyI+VGhhdCdzIGlycmVsZXZhbnQgZ2l2ZW4gV1JBUCBkb2VzIG5vdCBt ZW50aW9uIGFub255bWl0eSBvciBhbnl0aGluZyBlbHNlIGFib3V0IHJlZnJlc2ggdG9rZW4gbm90 IGV4cGxpY2l0bHkNCiBhZGRyZXNzZWQgYWxyZWFkeSBieSB2Mi4gWW91ciBlbWFpbCBpcyB0aGUg dmVyeSBmaXJzdCB0aW1lIHRoaXMgaGFzIGJlZW4gcmFpc2VkIG9uIHRoaXMgbGlzdC48L3NwYW4+ PC9kaXY+IA0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1h bCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2s7Ij4m bmJzcDs8L3NwYW4+PC9kaXY+IA0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2 NTk3NU1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2s7Ij5FSEw8L3NwYW4+PC9kaXY+IA0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0i eWl2MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6YmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9kaXY+IA0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbjsiPg0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCIg c3R5bGU9IiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2s7Ij5G cm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFj azsiPkFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRv OnRvbnluYWRAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzp0b255 bmFkQG1pY3Jvc29mdC5jb20iPjxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20i PnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHUs IDExIEF1ZyAyMDExIDEyOjQxOjI4IC0wNzAwPGJyPg0KPGI+VG86IDwvYj5FcmFuIEhhbW1lci1s YWhhdiAmbHQ7PGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOmVyYW5AaHVlbml2ZXJz ZS5jb20iIHRhcmdldD0iX2JsYW5rIiBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+ PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208 L2E+PC9hPiZndDssIERpY2sgSGFyZHQgJmx0OzxhIHJlbD0ibm9mb2xsb3ciIHltYWlsdG89Im1h aWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzpk aWNrLmhhcmR0QGdtYWlsLmNvbSI+PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29t Ij5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT48L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+Ik9BdXRo IFdHICg8YSByZWw9Im5vZm9sbG93IiB5bWFpbHRvPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIiBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0 bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPikiICZsdDs8YSByZWw9Im5v Zm9sbG93IiB5bWFpbHRvPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBo cmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y ZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFtP QVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8L3NwYW4+PC9kaXY+IA0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9kaXY+IA0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRE RiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDsiIGlkPSJ5 aXYxNTc0NjY1OTc1TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7Ij5Bbm9ueW1pdHkgd2FzIGNl cnRhaW5seSBwYXJ0IG9mIHRoZSBkZXNpZ24gZm9yIFdSQVA8L3NwYW4+PC9kaXY+IA0KPGRpdiBj bGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RDsiPiZuYnNwOzwvc3Bhbj48L2Rpdj4gDQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ij4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29O b3JtYWwiIHN0eWxlPSIiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJs YWNrOyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OmJsYWNrOyI+IEVyYW4NCiBIYW1tZXItTGFoYXYgWzxhIHJlbD0ibm9mb2xsb3ciIHltYWlsdG89 Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb20iPjxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29t Ij5tYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbTwvYT48L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBBdWd1c3QgMTEsIDIwMTEgMTI6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhv bnkgTmFkYWxpbjsgRGljayBIYXJkdDxicj4NCjxiPkNjOjwvYj4gT0F1dGggV0cgKDxhIHJlbD0i bm9mb2xsb3ciIHltYWlsdG89Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48L2E+KTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09B VVRILVdHXSBSZWZyZXNoIFRva2Vuczwvc3Bhbj48L2Rpdj4gDQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrOyI+Jm5ic3A7PC9zcGFuPjwvZGl2PiANCjxkaXY+DQo8ZGl2IGNsYXNzPSJ5aXYx NTc0NjY1OTc1TXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjpibGFjazsiPlNlY3Rpb24gMS41IGFscmVhZHkgY292ZXJzIHJlZnJlc2ggdG9rZW5z LiBUaGVyZSBhcmUgbWFueSB1c2UgY2FzZXMgZm9yIHJlZnJlc2ggdG9rZW5zLiBUaGV5IGFyZSBi YXNpY2FsbHkNCiBhIHByb3RvY29sIGZlYXR1cmUgdXNlZCB0byBtYWtlIHNjYWxhYmlsaXR5IGFu ZCBzZWN1cml0eSBtb3JlIGZsZXhpYmxlLiBBbm9ueW1pdHkgd2FzIG5ldmVyIHBhcnQgb2YgdGhl aXIgZGVzaWduLCBhbmQgYnkgdGhlIG5hdHVyZSBvZiB0aGlzIHByb3RvY29sLCBpcyBtb3JlIGlu IHRoZSBkb21haW4gb2YgdGhlIHJlc291cmNlIHNlcnZlciAoYmFzZWQgb24gd2hhdCBpbmZvcm1h dGlvbiBpdCBleHBvc2VzIHZpYSBpdHMgQVBJKS4gSW4gZmFjdCwNCiB5b3VyIGVtYWlsIGlmIHRo ZSBmaXJzdCBzdWNoIHN1Z2dlc3Rpb24gb2YgYW5vbnltaXR5Ljwvc3Bhbj48L2Rpdj4gDQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFsIiBzdHlsZT0iIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjazsiPiZuYnNwOzwvc3Bhbj48 L2Rpdj4gDQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFs IiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjazsiPkVI TDwvc3Bhbj48L2Rpdj4gDQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1 TXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjazsiPiZuYnNwOzwvc3Bhbj48L2Rpdj4gDQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluOyI+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFsIiBzdHlsZT0iIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjazsiPkZyb206DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrOyI+QW50aG9ueSBO YWRhbGluICZsdDs8YSByZWw9Im5vZm9sbG93IiB5bWFpbHRvPSJtYWlsdG86dG9ueW5hZEBtaWNy b3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0 LmNvbSI+PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNy b3NvZnQuY29tPC9hPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodSwgMTEgQXVnIDIwMTEg MTE6MTU6MjggLTA3MDA8YnI+DQo8Yj5UbzogPC9iPkRpY2sgSGFyZHQgJmx0OzxhIHJlbD0ibm9m b2xsb3ciIHltYWlsdG89Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSI+PGEgaHJlZj0ibWFpbHRvOmRp Y2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT48L2E+Jmd0Ozxicj4N CjxiPkNjOiA8L2I+Ik9BdXRoIFdHICg8YSByZWw9Im5vZm9sbG93IiB5bWFpbHRvPSJtYWlsdG86 b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v cmciPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9h PikiICZsdDs8YSByZWw9Im5vZm9sbG93IiB5bWFpbHRvPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIiBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1h aWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+PC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UmU6IFtPQVVUSC1XR10gUmVmcmVzaCBUb2tlbnM8L3NwYW4+PC9kaXY+IA0K PC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9 IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2s7Ij4mbmJzcDs8L3Nw YW4+PC9kaXY+IA0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdp bi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdDsiIGlkPSJ5aXYxNTc0NjY1OTc1TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxP Q0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3Jt YWwiIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0Q7 Ij5NYW55IHJlYXNvbnMsIGJ1dCBub25lIGFyZSBleHBsYWluZWQgaW4gdGhlIHNwZWNpZmljYXRp b248L3NwYW4+PC9kaXY+IA0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5 bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RDsiPiZuYnNw Ozwvc3Bhbj48L2Rpdj4gDQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ij4NCjxkaXYg Y2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwiIHN0eWxlPSIiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrOyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrOyI+IERpY2sNCiBIYXJkdCBbPGEgcmVsPSJu b2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayIgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj48YSBocmVmPSJtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20iPm1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT48L2E+ XSA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSAxMDo1MSBBTTxi cj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBXRyAo PGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayIgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86b2F1 dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjwvYT4pPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbT0FVVEgtV0ddIFJlZnJlc2ggVG9rZW5zPC9zcGFuPjwvZGl2PiANCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9kaXY+IA0KPGRpdiBjbGFzcz0ieWl2 MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrOyI+ TXkgcmVjb2xsZWN0aW9uIG9mIHJlZnJlc2ggdG9rZW5zIHdhcyBmb3Igc2VjdXJpdHkgYW5kIHJl dm9jYXRpb24uPC9zcGFuPjwvZGl2PiANCjxkaXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1 TXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7Ij4mbmJzcDs8L3Nw YW4+PC9kaXY+IA0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05v cm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrOyI+c2VjdXJpdHk6IEJ5IGhh dmluZyBhIHNob3J0IGxpdmVkIGFjY2VzcyB0b2tlbiwgYSBjb21wcm9taXNlZCBhY2Nlc3MgdG9r ZW4gd291bGQgbGltaXQgdGhlIHRpbWUgYW4gYXR0YWNrZXIgd291bGQgaGF2ZSBhY2Nlc3M8L3Nw YW4+PC9kaXY+IA0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05v cm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrOyI+Jm5ic3A7PC9zcGFuPjwv ZGl2PiANCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9InlpdjE1NzQ2NjU5NzVNc29Ob3JtYWwi IHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazsiPnJldm9jYXRpb246IGlmIHRoZSBh Y2Nlc3MgdG9rZW4gaXMgc2VsZiBjb250YWluZWQsIGF1dGhvcml6YXRpb24gY2FuIGJlIHJldm9r ZWQgYnkgbm90IGlzc3VpbmcgbmV3IGFjY2VzcyB0b2tlbnMuIEEgcmVzb3VyY2UgZG9lcyBub3Qg bmVlZCB0byBxdWVyeSB0aGUNCiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBzZWUgaWYgdGhlIGFj Y2VzcyB0b2tlbiBpcyB2YWxpZC5UaGlzIHNpbXBsaWZpZXMgYWNjZXNzIHRva2VuIHZhbGlkYXRp b24gYW5kIG1ha2VzIGl0IGVhc2llciB0byBzY2FsZSBhbmQgc3VwcG9ydCBtdWx0aXBsZSBhdXRo b3JpemF0aW9uIHNlcnZlcnMuJm5ic3A7Jm5ic3A7VGhlcmUgaXMgYSB3aW5kb3cgb2YgdGltZSB3 aGVuIGFuIGFjY2VzcyB0b2tlbiBpcyB2YWxpZCwgYnV0IGF1dGhvcml6YXRpb24gaXMgcmV2b2tl ZC4mbmJzcDs8L3NwYW4+PC9kaXY+IA0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ieWl2MTU3 NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrOyI+Jm5i c3A7PC9zcGFuPjwvZGl2PiANCjxkaXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9y bWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9k aXY+IA0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCIg c3R5bGU9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrOyI+Jm5ic3A7PC9zcGFuPjwvZGl2PiAN CjxkaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ieWl2MTU3NDY2NTk3NU1zb05vcm1hbCIgc3R5bGU9 IiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrOyI+T24gMjAxMS0wOC0xMSwgYXQgMTA6NDAgQU0s IEFudGhvbnkgTmFkYWxpbiB3cm90ZTo8L3NwYW4+PC9kaXY+IA0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2s7Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PC9kaXY+IA0K PGRpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFsIiBzdHlsZT0i Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjazsiPk5vd2hlcmUgaW4g dGhlIHNwZWNpZmljYXRpb24gaXMgdGhlcmUgZXhwbGFuYXRpb24gZm9yIHJlZnJlc2ggdG9rZW5z LCBUaGUgcmVhc29uIHRoYXQgdGhlIFJlZnJlc2ggdG9rZW4NCiB3YXMgaW50cm9kdWNlZCB3YXMg Zm9yIGFub255bWl0eS4gVGhlIHNjZW5hcmlvIGlzIHRoYXQgYSBjbGllbnQgYXNrcyB0aGUgdXNl ciBmb3IgYWNjZXNzLiBUaGUgdXNlciB3YW50cyB0byBncmFudCB0aGUgYWNjZXNzIGJ1dCBub3Qg dGVsbCB0aGUgY2xpZW50IHRoZSB1c2VyJ3MgaWRlbnRpdHkuIEJ5IGlzc3VpbmcgdGhlIHJlZnJl c2ggdG9rZW4gYXMgYW4gJ2lkZW50aWZpZXInIGZvciB0aGUgdXNlciAoYXMgd2VsbCBhcyBvdGhl ciBjb250ZXh0DQogZGF0YSBsaWtlIHRoZSByZXNvdXJjZSkgaXQncyBwb3NzaWJsZSBub3cgdG8g bGV0IHRoZSBjbGllbnQgZ2V0IGFjY2VzcyB3aXRob3V0IHJldmVhbGluZyBhbnl0aGluZyBhYm91 dCB0aGUgdXNlci4gUmVjb21tZW5kIHRoYXQgdGhlIGFib3ZlIGV4cGxhbmF0aW9uIGJlIGluY2x1 ZGVkIHNvIGRldmVsb3BlcnMgdW5kZXJzdGFuZCB3aHkgdGhlIHJlZnJlc2ggdG9rZW5zIGFyZSB0 aGVyZS48L3NwYW4+PC9kaXY+IA0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNv Tm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtjb2xvcjpibGFj azsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwv YT48YnI+DQo8YSByZWw9Im5vZm9sbG93IiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48L2E+PC9zcGFuPjwvZGl2PiANCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJ5aXYxNTc0NjY1OTc1TXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9kaXY+IA0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCiANCg0KPC9kaXY+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj48YSB5bWFpbHRv PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+PGEg aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48L2E+PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdl dD0iX2JsYW5rIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjwv YT48YnI+PGJyPjxicj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5 PjwvaHRtbD4= --_000_D76A379AA43F47429488D64FF2A931AEhueniversecom_-- From recordond@gmail.com Thu Aug 11 17:15:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29D921F884C for ; Thu, 11 Aug 2011 17:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSsOpB+MWiKB for ; Thu, 11 Aug 2011 17:15:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5E1C21F87FC for ; Thu, 11 Aug 2011 17:15:36 -0700 (PDT) Received: by vws12 with SMTP id 12so2600748vws.31 for ; Thu, 11 Aug 2011 17:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2KsdVuHQr5YzWYVXfjGA+Y1h49qAB5gLH3m5ombmuiA=; b=b1o1DFAhu+G0ztlTfLMwARnzS5hssfouBKfXK8HO3/A2RUclCHCx0vZwFIEqYJ+0VR Q65pCb4XLlvbnJRzWcZi8SPlOtHS84qVW6vgsc8L0B1k6h+VVTi5CyC6DxbL7nr4nNKZ RX4ZyYOT7XDc7FOKbRKTgD7mFv2W0bFyIfh7U= MIME-Version: 1.0 Received: by 10.52.175.234 with SMTP id cd10mr255864vdc.245.1313108154964; Thu, 11 Aug 2011 17:15:54 -0700 (PDT) Received: by 10.52.155.68 with HTTP; Thu, 11 Aug 2011 17:15:54 -0700 (PDT) In-Reply-To: References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Thu, 11 Aug 2011 17:15:54 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 00:15:37 -0000 Agreed as well on this being implementation specific. Also don't remember ever seeing anonymity mentioned as a use case. On Thu, Aug 11, 2011 at 4:28 PM, Eran Hammer-Lahav wr= ote: > I strongly agree. I don't see what value there is in discussing anonymity > which brings identity into the spec without any justification. > EHL > > On Aug 11, 2011, at 19:26, "William J. Mills" wrot= e: > > It's implementation specific.=A0 You can choose to make them anonymous or= you > can issue signed plaintext tokens that conceal nothing.=A0 The spec doesn= 't > care.=A0 It's a security consideration of the end implementation, just li= ke > the need for tamper protection.=A0 The spec needs only to define them as > opaque blobs with a particular syntax.=A0 We are not specifying what > encryption you have to use here, and we should not. > > > ________________________________ > From: Anthony Nadalin > To: Eran Hammer-Lahav > Cc: "OAuth WG (oauth@ietf.org)" > Sent: Thursday, August 11, 2011 3:45 PM > Subject: Re: [OAUTH-WG] Refresh Tokens > > Disagree, this was our rational and this is one way it=92s used today wit= h our > scenarios. This needs to be assigned an issue. > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Thursday, August 11, 2011 3:39 PM > To: Anthony Nadalin > Cc: Dick Hardt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > > The text is wrong. This is not why refresh tokens were introduced > (originally by Yahoo then in WRAP). And is also technically unfounded. > Refresh tokens have no special anonymity properties. > > EHL > > On Aug 11, 2011, at 18:18, "Anthony Nadalin" wrot= e: > > I=92m raising the issue on the current text, I already provided text if t= he > original append. > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Thursday, August 11, 2011 3:03 PM > To: Anthony Nadalin > Cc: Dick Hardt; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > > 1. Process-wise it does. This is a brand new concept *here* and was not > mentioned in the charter or any use cases. Therefore, out of scope. > > 2. The current text provides all the information needed to imement. No on= e > raised an implementation issue on the current text. > > 3. Refresh token do not provide anonymity. An implementation could but th= is > was never considered in the design. > > 4. If you have suggested text, present it before the WGLC is over. I am n= ot > adding issues to my list without suggested text and wg consensus. > > EHL > On Aug 11, 2011, at 17:44, "Anthony Nadalin" wrot= e: > > There are no use cases at all in WRAP to help explain choices taken, it d= oes > not matter if there were or were not previous issues raised, it is being > raised now. > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Thursday, August 11, 2011 1:46 PM > To: Anthony Nadalin; Dick Hardt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > > That's irrelevant given WRAP does not mention anonymity or anything else > about refresh token not explicitly addressed already by v2. Your email is > the very first time this has been raised on this list. > > EHL > > From: Anthony Nadalin > Date: Thu, 11 Aug 2011 12:41:28 -0700 > To: Eran Hammer-lahav , Dick Hardt > > Cc: "OAuth WG (oauth@ietf.org)" > Subject: RE: [OAUTH-WG] Refresh Tokens > > > Anonymity was certainly part of the design for WRAP > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Thursday, August 11, 2011 12:35 PM > To: Anthony Nadalin; Dick Hardt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > > Section 1.5 already covers refresh tokens. There are many use cases for > refresh tokens. They are basically a protocol feature used to make > scalability and security more flexible. Anonymity was never part of their > design, and by the nature of this protocol, is more in the domain of the > resource server (based on what information it exposes via its API). In fa= ct, > your email if the first such suggestion of anonymity. > > EHL > > From: Anthony Nadalin > Date: Thu, 11 Aug 2011 11:15:28 -0700 > To: Dick Hardt > Cc: "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Refresh Tokens > > > Many reasons, but none are explained in the specification > > From: Dick Hardt [mailto:dick.hardt@gmail.com] > Sent: Thursday, August 11, 2011 10:51 AM > To: Anthony Nadalin > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Refresh Tokens > > My recollection of refresh tokens was for security and revocation. > > security: By having a short lived access token, a compromised access toke= n > would limit the time an attacker would have access > > revocation: if the access token is self contained, authorization can be > revoked by not issuing new access tokens. A resource does not need to que= ry > the authorization server to see if the access token is valid.This simplif= ies > access token validation and makes it easier to scale and support multiple > authorization servers.=A0=A0There is a window of time when an access toke= n is > valid, but authorization is revoked. > > > > On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: > > > > > > Nowhere in the specification is there explanation for refresh tokens, The > reason that the Refresh token was introduced was for anonymity. The scena= rio > is that a client asks the user for access. The user wants to grant the > access but not tell the client the user's identity. By issuing the refres= h > token as an 'identifier' for the user (as well as other context data like > the resource) it's possible now to let the client get access without > revealing anything about the user. Recommend that the above explanation b= e > included so developers understand why the refresh tokens are there. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From aiden449@gmail.com Thu Aug 11 17:17:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814FA21F86C1 for ; Thu, 11 Aug 2011 17:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOJzota9isH9 for ; Thu, 11 Aug 2011 17:17:25 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id D7F6F21F859C for ; Thu, 11 Aug 2011 17:17:24 -0700 (PDT) Received: by qyk35 with SMTP id 35so1500939qyk.10 for ; Thu, 11 Aug 2011 17:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z3XXe9OSfqUJ9Bnp7ds43l5H3+GFMwPTCVHx3oyeY3Y=; b=lQBcn795dklR2Tg3G7eEoTAumb2VPDJmYbNIriyXURjuFOWlrl6D8Use4P5gatdtJJ 9MkoPo4Xp3/ZgVv97qT+Jq7T+6fJ7vmwI/6jZx8Z2C8YbkcOeRB07g7pK6utcwB9ckuu IzKAja8FGDJdpMuDaMjIeiYEtvAEJrl3dcKaM= MIME-Version: 1.0 Received: by 10.229.106.34 with SMTP id v34mr195342qco.111.1313108280203; Thu, 11 Aug 2011 17:18:00 -0700 (PDT) Received: by 10.229.132.2 with HTTP; Thu, 11 Aug 2011 17:18:00 -0700 (PDT) In-Reply-To: References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Fri, 12 Aug 2011 01:18:00 +0100 Message-ID: From: Aiden Bell To: Eran Hammer-Lahav , tonynad@microsoft.com Content-Type: multipart/alternative; boundary=00235429d1d897d89d04aa43d8dc Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 00:17:26 -0000 --00235429d1d897d89d04aa43d8dc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have been following this thread with my jaw slightly open... As an implementor, the purpose of the refresh token I felt was clear in 1.5= . I just don't see the anonymity slant here at all ... any more than any other part of the spec. It all depends on what your service/api or whatever allows for a faceless authorisation session. I'm with anyone who thinks it belongs well away from the spec. On 12 August 2011 00:28, Eran Hammer-Lahav wrote: > I strongly agree. I don't see what value there is in discussing anonymity > which brings identity into the spec without any justification. > > EHL > > > On Aug 11, 2011, at 19:26, "William J. Mills" > wrote: > > It's implementation specific. You can choose to make them anonymous or y= ou > can issue signed plaintext tokens that conceal nothing. The spec doesn't > care. It's a security consideration of the end implementation, just like > the need for tamper protection. The spec needs only to define them as > opaque blobs with a particular syntax. We are not specifying what > encryption you have to use here, and we should not. > > > > ------------------------------ > *From:* Anthony Nadalin > *To:* Eran Hammer-Lahav > *Cc:* "OAuth WG (oauth@ietf.org)" > *Sent:* Thursday, August 11, 2011 3:45 PM > *Subject:* Re: [OAUTH-WG] Refresh Tokens > > Disagree, this was our rational and this is one way it=92s used today wi= th > our scenarios. This needs to be assigned an issue. > > *From:* Eran Hammer-Lahav [mailto:eran@hueniverse.com] > *Sent:* Thursday, August 11, 2011 3:39 PM > *To:* Anthony Nadalin > *Cc:* Dick Hardt; OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Refresh Tokens > > The text is wrong. This is not why refresh tokens were introduced > (originally by Yahoo then in WRAP). And is also technically unfounded. > Refresh tokens have no special anonymity properties. > > EHL > > On Aug 11, 2011, at 18:18, "Anthony Nadalin" < > tonynad@microsoft.com> wrote: > > I=92m raising the issue on the current text, I already provided text if = the > original append. > > *From:* Eran Hammer-Lahav [mailto:eran@hueniverse.com] > *Sent:* Thursday, August 11, 2011 3:03 PM > *To:* Anthony Nadalin > *Cc:* Dick Hardt; OAuth WG ( oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Refresh Tokens > > 1. Process-wise it does. This is a brand new concept *here* and was not > mentioned in the charter or any use cases. Therefore, out of scope. > > 2. The current text provides all the information needed to imement. No > one raised an implementation issue on the current text. > > 3. Refresh token do not provide anonymity. An implementation could but > this was never considered in the design. > > 4. If you have suggested text, present it before the WGLC is over. I am > not adding issues to my list without suggested text and wg consensus. > > EHL > > On Aug 11, 2011, at 17:44, "Anthony Nadalin" < > tonynad@microsoft.com> wrote: > > There are no use cases at all in WRAP to help explain choices taken, it > does not matter if there were or were not previous issues raised, it is > being raised now. > > *From:* Eran Hammer-Lahav [mailto:eran@hueniverse.com] > *Sent:* Thursday, August 11, 2011 1:46 PM > *To:* Anthony Nadalin; Dick Hardt > *Cc:* OAuth WG ( oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Refresh Tokens > > That's irrelevant given WRAP does not mention anonymity or anything else > about refresh token not explicitly addressed already by v2. Your email is > the very first time this has been raised on this list. > > EHL > > *From: *Anthony Nadalin < tonynad@microsoft.com> > *Date: *Thu, 11 Aug 2011 12:41:28 -0700 > *To: *Eran Hammer-lahav < eran@hueniverse.com>, Dick > Hardt < dick.hardt@gmail.com> > *Cc: *"OAuth WG ( oauth@ietf.org)" < > oauth@ietf.org> > *Subject: *RE: [OAUTH-WG] Refresh Tokens > > > Anonymity was certainly part of the design for WRAP > > *From:* Eran Hammer-Lahav [ > mailto:eran@hueniverse.com ] > *Sent:* Thursday, August 11, 2011 12:35 PM > *To:* Anthony Nadalin; Dick Hardt > *Cc:* OAuth WG ( oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Refresh Tokens > > Section 1.5 already covers refresh tokens. There are many use cases for > refresh tokens. They are basically a protocol feature used to make > scalability and security more flexible. Anonymity was never part of their > design, and by the nature of this protocol, is more in the domain of the > resource server (based on what information it exposes via its API). In fa= ct, > your email if the first such suggestion of anonymity. > > EHL > > *From: *Anthony Nadalin < tonynad@microsoft.com> > *Date: *Thu, 11 Aug 2011 11:15:28 -0700 > *To: *Dick Hardt < dick.hardt@gmail.com> > *Cc: *"OAuth WG ( oauth@ietf.org)" < > oauth@ietf.org> > *Subject: *Re: [OAUTH-WG] Refresh Tokens > > > Many reasons, but none are explained in the specification > > *From:* Dick Hardt [ mailto:dick.hardt@gmail.com] > > *Sent:* Thursday, August 11, 2011 10:51 AM > *To:* Anthony Nadalin > *Cc:* OAuth WG ( oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Refresh Tokens > > My recollection of refresh tokens was for security and revocation. > > security: By having a short lived access token, a compromised access > token would limit the time an attacker would have access > > revocation: if the access token is self contained, authorization can be > revoked by not issuing new access tokens. A resource does not need to que= ry > the authorization server to see if the access token is valid.This simplif= ies > access token validation and makes it easier to scale and support multiple > authorization servers. There is a window of time when an access token is > valid, but authorization is revoked. > > > > On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote: > > > > > > > Nowhere in the specification is there explanation for refresh tokens, > The reason that the Refresh token was introduced was for anonymity. The > scenario is that a client asks the user for access. The user wants to gra= nt > the access but not tell the client the user's identity. By issuing the > refresh token as an 'identifier' for the user (as well as other context d= ata > like the resource) it's possible now to let the client get access without > revealing anything about the user. Recommend that the above explanation b= e > included so developers understand why the refresh tokens are there. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --00235429d1d897d89d04aa43d8dc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have been following this thread with my jaw slightly open...

As an= implementor, the purpose of the refresh token I felt was clear in 1.5. I j= ust don't see the anonymity
slant here at all ... any more than any = other part of the spec. It all depends on what your service/api or
whatever allows for a faceless authorisation session.

I'm with a= nyone who thinks it belongs well away from the spec.


On 12 August 2011 00:28, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
I strongly agree. I don't see what value there is in discu= ssing anonymity which brings identity into the spec without any justificati= on. =A0

EHL


On Aug 11, 2011, at 19:26, "William J. Mills"= ; <wmills@yaho= o-inc.com> wrote:

It's implementation specific.=A0 You can choose to make them= anonymous or you can issue signed plaintext tokens that conceal nothing.= =A0 The spec doesn't care.=A0 It's a security consideration of the = end implementation, just like the need for tamper protection.=A0 The spec n= eeds only to define them as opaque blobs with a particular syntax.=A0 We ar= e not specifying what encryption you have to use here, and we should not.



From: Anthony Nadalin <tonynad@mic= rosoft.com>
To: = Eran Hammer-Lahav <eran@hueniverse.com>
Cc: "OAuth WG (oauth@ietf.org)" <= ;oauth@ietf.org>=
Sent: Thursday, August= 11, 2011 3:45 PM
Subject: Re: [OAUTH-WG] Re= fresh Tokens

=20 =20 =20
Disagree, th= is was our rational and this is one way it=92s used today with our scenario= s. This needs to be assigned an issue.
=20
=A0<= /div>=20
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 3:39 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
=20
=A0
=20
The text is wrong. This is not why refresh tokens were introduced (ori= ginally by Yahoo then in WRAP). And is also technically unfounded. Refresh = tokens have no special anonymity properties.=A0
=20
=A0
=20
EHL

On Aug 11, 2011, at 18:18, "Anthony Nadalin" <tonynad@microsoft.com&g= t; wrote:
=20
I=92m raisin= g the issue on the current text, I already provided text if the original ap= pend.=A0
=20
=A0=20
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 3:03 PM
To: Anthony Nadalin
Cc: Dick Hardt; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
=20
=A0
=20
1. Process-wise it does. This is a brand new concept *here* and was no= t mentioned in the charter or any use cases. Therefore, out of scope.=A0=20
=A0
=20
2. The current text provides all the information needed to imement. No= one raised an implementation issue on the current text.
=20
=A0
=20
3. Refresh token do not provide anonymity. An implementation could but= this was never considered in the design.=A0
=20
=A0
=20
4. If you have suggested text, present it before the WGLC is over. I a= m not adding issues to my list without suggested text and wg consensus.=A0<= /div>=20
=A0
=20
EHL
=20

On Aug 11, 2011, at 17:44, "Anthony Nadalin" <tonynad@microsoft.com&g= t; wrote:
=20
There are no= use cases at all in WRAP to help explain choices taken, it does not matter= if there were or were not previous issues raised, it is being raised now.=20
=A0=20
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 1:46 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oaut= h@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
=20
=A0
=20
That's irrelevant= given WRAP does not mention anonymity or anything else about refresh token= not explicitly addressed already by v2. Your email is the very first time this has been r= aised on this list.
=20
=A0
=20
EHL
=20
=A0
=20
From: Anthony Nadalin &= lt;tonynad@= microsoft.com>
Date: Thu, 11 Aug 2011 12:41:28 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>, Dick Hardt <dick.hardt@gmail.com= >
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Refresh Tokens
=20
=A0
=20
Anonymity wa= s certainly part of the design for WRAP
=20
=A0=20
From: Eran Hammer-Lahav [= mailto:eran@hueniverse.com]
Sent: Thursday, August 11, 2011 12:35 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG (oaut= h@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
=20
=A0
=20
Section 1.5 already c= overs refresh tokens. There are many use cases for refresh tokens. They are= basically a protocol feature used to make scalability and security more flexible. An= onymity was never part of their design, and by the nature of this protocol,= is more in the domain of the resource server (based on what information it= exposes via its API). In fact, your email if the first such suggestion of anonymity.
=20
=A0
=20
EHL
=20
=A0
=20
From: Anthony Nadalin &= lt;tonynad@= microsoft.com>
Date: Thu, 11 Aug 2011 11:15:28 -0700
To: Dick Hardt <dick.hardt@gmail.com>
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Refresh Tokens
=20
=A0
=20
Many reasons= , but none are explained in the specification
=20
=A0=20
From: Dick Hardt [mailt= o:dick.hardt@gmail.com]
Sent: Thursday, August 11, 2011 10:51 AM
To: Anthony Nadalin
Cc: OAuth WG (oaut= h@ietf.org)
Subject: Re: [OAUTH-WG] Refresh Tokens
=20
=A0
=20
My recollection of refresh tokens was fo= r security and revocation.
=20
=A0
=20
security: By having a short lived access= token, a compromised access token would limit the time an attacker would h= ave access
=20
=A0
=20
revocation: if the access token is self = contained, authorization can be revoked by not issuing new access tokens. A= resource does not need to query the authorization server to see if the access token is valid.This simplifies a= ccess token validation and makes it easier to scale and support multiple au= thorization servers.=A0=A0There is a window of time when an access token is= valid, but authorization is revoked.=A0
=20
=A0
=20
=A0
=20
=A0
=20
On 2011-08-11, at 10:40 AM, Anthony Nada= lin wrote:
=20






=20
Nowhere in the specific= ation is there explanation for refresh tokens, The reason that the Refresh = token was introduced was for anonymity. The scenario is that a client asks the u= ser for access. The user wants to grant the access but not tell the client = the user's identity. By issuing the refresh token as an 'identifier= ' for the user (as well as other context data like the resource) it's possible now to let the client get access= without revealing anything about the user. Recommend that the above explan= ation be included so developers understand why the refresh tokens are there= .
=20
_____________________= __________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=20
=A0
=20
=20

_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth



________= _______________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
-------------------= -----------------------------------------------
Never send sensitive or = private information via email unless it is encrypted. http://www.gnupg.org
--00235429d1d897d89d04aa43d8dc-- From barryleiba.mailing.lists@gmail.com Thu Aug 11 18:00:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA88021F8B5C for ; Thu, 11 Aug 2011 18:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.043 X-Spam-Level: X-Spam-Status: No, score=-103.043 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5ALHPZPXvV3 for ; Thu, 11 Aug 2011 18:00:19 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48DA421F8B58 for ; Thu, 11 Aug 2011 18:00:19 -0700 (PDT) Received: by gyf3 with SMTP id 3so1989126gyf.31 for ; Thu, 11 Aug 2011 18:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=XItTh9XoS7tPXU6yX9dZP+zaa2dR+Tehjki5/eTgoCI=; b=D1FlpHLumKfe7kFkWFDNKFzSJEp5Nnvo9wxkNUBCLfJLGP90bhDsxCx9kmsjotYKh/ Ms2WpLqvNg2VKZbrRcpsYIDyqayKA+hkYnJvPXlsmr//9LW3rEnsFvSegm24lt/RqtPt EksdBOjViNTlGzO6kytYoy6bU3DNWIPTKte6E= MIME-Version: 1.0 Received: by 10.236.170.165 with SMTP id p25mr973906yhl.143.1313110854789; Thu, 11 Aug 2011 18:00:54 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Thu, 11 Aug 2011 18:00:54 -0700 (PDT) In-Reply-To: References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Thu, 11 Aug 2011 21:00:54 -0400 X-Google-Sender-Auth: WdfmuzQ3BrODNdmo62-TqrfLskk Message-ID: From: Barry Leiba To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 01:00:19 -0000 This seems to need a chair to step in. Tony is taking a strong stand and maintaining it: On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin wrote: > Nowhere in the specification is there explanation for refresh tokens, The > reason that the Refresh token was introduced was for anonymity. The scenario > is that a client asks the user for access. The user wants to grant the > access but not tell the client the user's identity. By issuing the refresh > token as an 'identifier' for the user (as well as other context data like > the resource) it's possible now to let the client get access without > revealing anything about the user. Recommend that the above explanation be > included so developers understand why the refresh tokens are there. So far, though it's been only half a day, I've seen several posts disagreeing with Tony, and none supporting any change to the text for this. We're close to ending WGLC, so please post here if you agree with Tony's suggested change. Otherwise, it looks like consensus is against. Barry, as chair From eran@hueniverse.com Thu Aug 11 23:16:32 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5668E11E807F for ; Thu, 11 Aug 2011 23:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSdK8bj006sY for ; Thu, 11 Aug 2011 23:16:31 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 4285021F8779 for ; Thu, 11 Aug 2011 23:16:31 -0700 (PDT) Received: (qmail 22815 invoked from network); 12 Aug 2011 06:17:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Aug 2011 06:17:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 11 Aug 2011 23:17:00 -0700 From: Eran Hammer-Lahav To: Mike Jones , "oauth@ietf.org" Date: Thu, 11 Aug 2011 23:16:53 -0700 Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland Thread-Index: AcxYt3HaNTRQrFu8TyOvn60KFmOGJA== Message-ID: In-Reply-To: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA6A0BC117D3Feranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 06:16:32 -0000 --_000_CA6A0BC117D3Feranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The following comments require a proposed text. Without it, they will not b= e included in my next editorial revision. I will respond or incorporate the= rest of the comments after the close of LC. Others are welcomed and encour= aged to discuss this (very useful and thorough) list before LC ends. EHL From: Mike Jones > Date: Wed, 10 Aug 2011 14:38:40 -0700 To: "oauth@ietf.org" > Subject: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 fro= m Yaron Goland 1.4.1. Authorization Code: Comment: =93It seems odd that we can discuss th= e authorization code without also discussing the security issues it raises = (e.g. passing secure information via a browser) and thus motivating the int= roduction of the refresh token. I would expect this to be referred to here.= Having read the security considerations section I can find no coherent di= scussion there either of the relationship between the authorization code an= d the refresh token and why one motivated the other. I think this is someth= ing important for implementers to understand.=94 1.4.2. Implicit: Comment: =93I find this section confusing. I think an ex= ample is all but mandatory here if the reader is to understand what is inte= nded. For example, when I first read this section I thought it was some ki= nd of short cut used in cases where the client and authorization server had= a close relationship and could share information such as the client=92s id= entity so no access code was needed. No where in here is any hint that thi= s is about browser based clients who don=92t have servers and who need a wa= y to get tokens. Seriously. Try to read this section as someone who knows n= othing about OAuth and tell me that you get the right idea back from it. It= needs to be written to be both explicit as to its goals and clearer as to = its means.=94 3.1.2.4. Invalid Endpoint: Comment on =93open redirector=94: =93How many p= eople even know what the heck an open redirector is? I think we need a sect= ion in the security considerations section that defines what an open redire= ctor is and why it=92s bad. Alternatively a normative reference to a comple= te definition somewhere else is also fine.=94 4.1.2. Authorization Response: Comment on =93state=94: =93Don=92t we have = to provide some guidance on how large the state value can safely be? Otherw= ise we are asking clients to rewrite their state mechanisms every time they= throw in support for a new protected resource server. We have to set expec= tations across the industry if we are to hope for actual interoperability.= =94 4.2. Implicit Grant: Comment =93I have run into multiple people (including= myself) who have read the OAuth spec and came away completely confused abo= ut when the heck one is supposed to use the implicit grant flow for. It=92s= not immediately obvious that it=92s a way to support standalone browser ba= sed clients. Can we put in an example or something to make it more obvious = why it=92s here?=94 10.4. Refresh Tokens: Comment =93As mentioned previously we really should e= xplain why we introduced refresh tokens. Without understanding the intent o= f the mechanism it=92s unlikely implementers will use them appropriately.= =94 10.7. Resource Owner Password Credentials: Comment on =93password anti-patt= ern=94: =93Is it fair to expect that the reader knows what the password ant= i-pattern is? Shouldn=92t some reference to a definition of this pattern be= required?=94 10.12. Cross-Site Request Forgery: Comment on first paragraph: =93I challen= ge any reasonably intelligent person who does not already know what a CSRF = is to read this paragraph and come away any clearer as to what is being dis= cussed. At a minimum isn=92t some reference to a complete definition of CSR= F needed if there is to be any hope of user compliance?=94 10.12. Cross-Site Request Forgery: Comment on =93The "state" request parame= ter MUST contain a non-guessable value=94: =93Actually a non-guessable valu= e won=92t stop the attack discussed in the previous paragraph on its own. W= hat=92s also needed is a way to uniquely (and unbreakably) associate the st= ate with a particular user so that if an authorization code swap occurs it = can be reliably detected.=94 ________________________________ --_000_CA6A0BC117D3Feranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The following comments require = a proposed text. Without it, they will not be included in my next editorial= revision. I will respond or incorporate the rest of the comments after the= close of LC. Others are welcomed and encouraged to discuss this (very usef= ul and thorough) list before LC ends.

EHL

From: Mike Jones = <Michael.Jones@microsoft.= com>
Date: Wed, 10 Aug 2= 011 14:38:40 -0700
To: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG] Partial set of last call comments on OAuth = draft 20 from Yaron Goland

 

1.4.1. Authorization Code:  Comment: =93It seems = odd that we can discuss the authorization code without also discussing the = security issues it raises (e.g. passing secure information via a browser) a= nd thus motivating the introduction of the refresh token. I would expect this to be referred to here.  Havin= g read the security considerations section I can find no coherent discussio= n there either of the relationship between the authorization code and the r= efresh token and why one motivated the other. I think this is something important for implementers to understand.= =94

 

1.4.2.  Implicit:  Comment: =93I find this section conf= using. I think an example is all but mandatory here if the reader is to und= erstand what is intended.  For example, when I first read this section= I thought it was some kind of short cut used in cases where the client and authorization server had a close relati= onship and could share information such as the client=92s identity so no ac= cess code was needed.  No where in here is any hint that this is about= browser based clients who don=92t have servers and who need a way to get tokens. Seriously. Try to read this section as s= omeone who knows nothing about OAuth and tell me that you get the right ide= a back from it. It needs to be written to be both explicit as to its goals = and clearer as to its means.=94

&= nbsp; 

3.1.2.4.  Invalid Endpoint= : Comment on =93open redirector=94: =93How many people even know what the h= eck an open redirector is? I think we need a section in the security consid= erations section that defines what an open redirector is and why it=92s bad. Alternatively a normative reference to a complete definition somewher= e else is also fine.=94

 

4.1.2.  Aut= horization Response: Comment on =93state=94: =93Don=92t we have to provide = some guidance on how large the state value can safely be? Otherwise we are = asking clients to rewrite their state mechanisms every time they throw in s= upport for a new protected resource server. We have to set expectations across the in= dustry if we are to hope for actual interoperability.=94

 

4.2.  Implicit Grant: Comment =93I have run into multip= le people (including myself) who have read the OAuth spec and came away com= pletely confused about when the heck one is supposed to use the implicit gr= ant flow for. It=92s not immediately obvious that it=92s a way to support standalone browser based clients. Can= we put in an example or something to make it more obvious why it=92s here?= =94

&n= bsp; 

10.4. Refresh Tokens: Comment = =93As mentioned previously we really should explain why we introduced refre= sh tokens. Without understanding the intent of the mechanism it=92s unlikel= y implementers will use them appropriately.=94


10.7. Re= source Owner Password Credentials: Comment on =93password anti-pattern=94: = =93Is it fair to expect that the reader knows what the password anti-patter= n is? Shouldn=92t some reference to a definition of this pattern be require= d?=94

=  

10.12. Cross-Site Request Forgery: C= omment on first paragraph: =93I challenge any reasonably intelligent person= who does not already know what a CSRF is to read this paragraph and come a= way any clearer as to what is being discussed. At a minimum isn=92t some reference to a complete definition of CSRF needed if = there is to be any hope of user compliance?=94

 

10.12. Cross-Site Request Forgery: Comment on =93The "state"= request parameter MUST contain a non-guessable value=94: =93Actually a non= -guessable value won=92t stop the attack discussed in the previous paragrap= h on its own. What=92s also needed is a way to uniquely (and unbreakably) associate the state with a particular = user so that if an authorization code swap occurs it can be reliably detect= ed.=94

 

 

 --_000_CA6A0BC117D3Feranhueniversecom_-- From torsten@lodderstedt.net Fri Aug 12 07:55:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8E821F889F for ; Fri, 12 Aug 2011 07:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqwbdBezMEAx for ; Fri, 12 Aug 2011 07:55:51 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by ietfa.amsl.com (Postfix) with ESMTP id 517A421F8745 for ; Fri, 12 Aug 2011 07:55:50 -0700 (PDT) Received: from [80.67.16.112] (helo=webmail.df.eu) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Qrt9u-0002Rn-FT; Fri, 12 Aug 2011 16:56:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 12 Aug 2011 16:56:26 +0200 From: Torsten Lodderstedt To: Message-ID: X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail/0.5.2 X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 14:55:52 -0000 Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10. Resource Owner Impersonation When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. From torsten@lodderstedt.net Fri Aug 12 08:10:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683BB21F8A55 for ; Fri, 12 Aug 2011 08:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCa0ZPtxpGhv for ; Fri, 12 Aug 2011 08:10:15 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id AA3BA21F8A4E for ; Fri, 12 Aug 2011 08:10:14 -0700 (PDT) Received: from [80.67.16.112] (helo=webmail.df.eu) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1QrtNp-00056B-I2 for oauth@ietf.org; Fri, 12 Aug 2011 17:10:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 12 Aug 2011 17:10:49 +0200 From: Torsten Lodderstedt To: In-Reply-To: References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com> Message-ID: <88f4b10fcf44ac276be338f7eebd5634@lodderstedt-online.de> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail/0.5.2 X-Df-Sender: torsten@lodderstedt-online.de Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 15:10:15 -0000 OAuth allows a client to access user resources without revealing the resource owner's identity to the client. Isn't this anonymity? I consider this an important property of the protocol. regards, Torsten. On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote: > This seems to need a chair to step in. Tony is taking a strong stand > and maintaining it: > > On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin > wrote: >> Nowhere in the specification is there explanation for refresh >> tokens, The >> reason that the Refresh token was introduced was for anonymity. The >> scenario >> is that a client asks the user for access. The user wants to grant >> the >> access but not tell the client the user's identity. By issuing the >> refresh >> token as an 'identifier' for the user (as well as other context data >> like >> the resource) it's possible now to let the client get access without >> revealing anything about the user. Recommend that the above >> explanation be >> included so developers understand why the refresh tokens are there. > > So far, though it's been only half a day, I've seen several posts > disagreeing with Tony, and none supporting any change to the text for > this. We're close to ending WGLC, so please post here if you agree > with Tony's suggested change. Otherwise, it looks like consensus is > against. > > Barry, as chair > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From aaron@parecki.com Fri Aug 12 08:59:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3F821F86E6 for ; Fri, 12 Aug 2011 08:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ckaxD5vTD0t for ; Fri, 12 Aug 2011 08:59:45 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id E877521F855A for ; Fri, 12 Aug 2011 08:59:44 -0700 (PDT) Received: by yie12 with SMTP id 12so2400034yie.31 for ; Fri, 12 Aug 2011 09:00:22 -0700 (PDT) Received: by 10.147.54.16 with SMTP id g16mr1108288yak.12.1313164822231; Fri, 12 Aug 2011 09:00:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id o2sm2351965yhl.57.2011.08.12.09.00.18 (version=SSLv3 cipher=OTHER); Fri, 12 Aug 2011 09:00:18 -0700 (PDT) Received: by gyf3 with SMTP id 3so2396363gyf.31 for ; Fri, 12 Aug 2011 09:00:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.172.71 with SMTP id m7mr1001554icz.478.1313164818092; Fri, 12 Aug 2011 09:00:18 -0700 (PDT) Received: by 10.231.32.194 with HTTP; Fri, 12 Aug 2011 09:00:17 -0700 (PDT) In-Reply-To: <88f4b10fcf44ac276be338f7eebd5634@lodderstedt-online.de> References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com> <88f4b10fcf44ac276be338f7eebd5634@lodderstedt-online.de> Date: Fri, 12 Aug 2011 09:00:17 -0700 Message-ID: From: Aaron Parecki To: oauth@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6136a283945b04aa51025f Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 15:59:45 -0000 --90e6ba6136a283945b04aa51025f Content-Type: text/plain; charset=UTF-8 Many APIs in practice have a method such as "/me" or "/profile" for applications to retrieve the profile information of the resource owner given their access token. IMO this is a completely appropriate use of OAuth, even though the resource owner is no longer anonymous in this case. I agree that it's implementation specific. My understanding was that OAuth is designed to give limited, revokable, and/or temporary access to a third party without revealing the resource owner's credentials. This has nothing to do with anonymity. Also this is not unique to refresh tokens, the same applies to access tokens. Aaron Parecki On Fri, Aug 12, 2011 at 8:10 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > OAuth allows a client to access user resources without revealing the > resource owner's identity to the client. Isn't this anonymity? I consider > this an important property of the protocol. > > regards, > Torsten. > > > > On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote: > >> This seems to need a chair to step in. Tony is taking a strong stand >> and maintaining it: >> >> On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin >> wrote: >> >>> Nowhere in the specification is there explanation for refresh tokens, The >>> reason that the Refresh token was introduced was for anonymity. The >>> scenario >>> is that a client asks the user for access. The user wants to grant the >>> access but not tell the client the user's identity. By issuing the >>> refresh >>> token as an 'identifier' for the user (as well as other context data like >>> the resource) it's possible now to let the client get access without >>> revealing anything about the user. Recommend that the above explanation >>> be >>> included so developers understand why the refresh tokens are there. >>> >> >> So far, though it's been only half a day, I've seen several posts >> disagreeing with Tony, and none supporting any change to the text for >> this. We're close to ending WGLC, so please post here if you agree >> with Tony's suggested change. Otherwise, it looks like consensus is >> against. >> >> Barry, as chair >> ______________________________**_________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/**listinfo/oauth >> > > ______________________________**_________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/**listinfo/oauth > --90e6ba6136a283945b04aa51025f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Many APIs in practice have a method such as "/me" or "/profi= le" for applications to retrieve the profile information of the resour= ce owner given their access token. IMO this is a completely appropriate use= of OAuth, even though the resource owner is no longer anonymous in this ca= se. I agree that it's implementation specific.

My understanding was that OAuth is designed to give limited, revokable,= and/or temporary access to a third party without revealing the resource ow= ner's credentials. This has nothing to do with anonymity.

Also t= his is not unique to refresh tokens, the same applies to access tokens.

Aaron Parecki


On Fri, Aug 12, 2011 at 8:10 AM, Torsten= Lodderstedt <torsten@lodderstedt.net> wrote:
OAuth allows a client to access user resources without revealing the resour= ce owner's identity to the client. Isn't this anonymity? I consider= this an important property of the protocol.

regards,
Torsten.



On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote:
This seems to need a chair to step in. =C2=A0Tony is taking a strong stand<= br> and maintaining it:

On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin
<tonynad@micr= osoft.com> wrote:
Nowhere in the specification is there explanation for refresh tokens, The reason that the Refresh token was introduced was for anonymity. The scenari= o
is that a client asks the user for access. The user wants to grant the
access but not tell the client the user's identity. By issuing the refr= esh
token as an 'identifier' for the user (as well as other context dat= a like
the resource) it's possible now to let the client get access without revealing anything about the user. Recommend that the above explanation be<= br> included so developers understand why the refresh tokens are there.

So far, though it's been only half a day, I've seen several posts disagreeing with Tony, and none supporting any change to the text for
this. =C2=A0We're close to ending WGLC, so please post here if you agre= e
with Tony's suggested change. =C2=A0Otherwise, it looks like consensus = is
against.

Barry, as chair
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--90e6ba6136a283945b04aa51025f-- From aiden449@gmail.com Fri Aug 12 09:05:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC77E21F873D for ; Fri, 12 Aug 2011 09:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6UFhzI0+3Mu for ; Fri, 12 Aug 2011 09:05:33 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBFBA21F8853 for ; Fri, 12 Aug 2011 09:05:06 -0700 (PDT) Received: by qwc23 with SMTP id 23so2137795qwc.31 for ; Fri, 12 Aug 2011 09:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hrWk9gVir8Ad5spfjPlHcizg96DN4qbPovXYz+rDDlU=; b=QNn/KrD64H3Q11fbDfRGx6t5xaV2CgtRivMZ+De31du6RQ/qYO5mQmghO8EPEBA0TX MFew6b5g4G2fRNCnkdUa2NaGj2Y7auZ+zSpZvAg35fUyaTBfeLz7GMa352e8Zcc29HLS VIDVitq9tSoX5rMGFIqFy18L5DOy/ZLTFWem8= MIME-Version: 1.0 Received: by 10.229.134.68 with SMTP id i4mr727407qct.263.1313165141545; Fri, 12 Aug 2011 09:05:41 -0700 (PDT) Received: by 10.229.132.2 with HTTP; Fri, 12 Aug 2011 09:05:41 -0700 (PDT) In-Reply-To: <88f4b10fcf44ac276be338f7eebd5634@lodderstedt-online.de> References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com> <88f4b10fcf44ac276be338f7eebd5634@lodderstedt-online.de> Date: Fri, 12 Aug 2011 17:05:41 +0100 Message-ID: From: Aiden Bell To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=e89a8f6465c5cb12d904aa5115f4 Cc: OAuth WG Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 16:05:34 -0000 --e89a8f6465c5cb12d904aa5115f4 Content-Type: text/plain; charset=ISO-8859-1 In some sense, but it is an indirect consequence of the fact the protocol is for granting access without requiring the revealing of user credentials, which in most (but not all) cases means hiding the user's identity on the system. In many cases however, their identity is simply translated/embodied by into tokens exchanged and the service using OAuth will expose identity. Therefore an implicit property is the negotiation of access to resources without revealing a user's identity ... but identity goes well beyond login credentials in most useful systems. Even then, you can use OAuth with login credentials (in native apps etc) (4.3) to authenticate. Because "identity" and "anonymity" may possibly be implemented using OAuth doesn't mean that it is an explicit design feature in OAuth itself. I think it is very dangerous to go down this route, as bringing explicit anonymity into the mix will confuse the purpose and scope of OAuth, when anonymity is a restriction on some system using OAuth. I don't see OAuth as being anymore a system with anonymity properties than say, my web browser. Depends on how you use it; entirely. Aiden Bell On 12 August 2011 16:10, Torsten Lodderstedt wrote: > OAuth allows a client to access user resources without revealing the > resource owner's identity to the client. Isn't this anonymity? I consider > this an important property of the protocol. > > regards, > Torsten. > > > > On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote: > >> This seems to need a chair to step in. Tony is taking a strong stand >> and maintaining it: >> >> On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin >> wrote: >> >>> Nowhere in the specification is there explanation for refresh tokens, The >>> reason that the Refresh token was introduced was for anonymity. The >>> scenario >>> is that a client asks the user for access. The user wants to grant the >>> access but not tell the client the user's identity. By issuing the >>> refresh >>> token as an 'identifier' for the user (as well as other context data like >>> the resource) it's possible now to let the client get access without >>> revealing anything about the user. Recommend that the above explanation >>> be >>> included so developers understand why the refresh tokens are there. >>> >> >> So far, though it's been only half a day, I've seen several posts >> disagreeing with Tony, and none supporting any change to the text for >> this. We're close to ending WGLC, so please post here if you agree >> with Tony's suggested change. Otherwise, it looks like consensus is >> against. >> >> Barry, as chair >> ______________________________**_________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/**listinfo/oauth >> > > ______________________________**_________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/**listinfo/oauth > -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --e89a8f6465c5cb12d904aa5115f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In some sense, but it is an indirect consequence of the fact the protocol i= s for granting access
without requiring the revealing of user credential= s, which in most (but not all) cases means
hiding the user's identit= y on the system.

In many cases however, their identity is simply translated/embodied by = into tokens exchanged and
the service using OAuth will expose identity.<= br>
Therefore an implicit property is the negotiation of access to resou= rces without revealing a
user's identity ... but identity goes well beyond login credentials in = most useful systems.
Even then, you can use OAuth with login credentials= (in native apps etc) (4.3) to authenticate.

Because "identity&= quot; and "anonymity" may possibly be implemented using OAuth doe= sn't mean
that it is an explicit design feature in OAuth itself.

I think it is= very dangerous to go down this route, as bringing explicit anonymity into = the mix
will confuse the purpose and scope of OAuth, when anonymity is a= restriction on some system
using OAuth.

I don't see OAuth as being anymore a system with an= onymity properties than say, my web browser.
Depends on how you use it; = entirely.

Aiden Bell


On 12 Au= gust 2011 16:10, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
OAuth allows a client to access user resour= ces without revealing the resource owner's identity to the client. Isn&= #39;t this anonymity? I consider this an important property of the protocol= .

regards,
Torsten.



On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote:
This seems to need a chair to step in. =A0Tony is taking a strong stand
and maintaining it:

On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin
<tonynad@micr= osoft.com> wrote:
Nowhere in the specification is there explanation for refresh tokens, The reason that the Refresh token was introduced was for anonymity. The scenari= o
is that a client asks the user for access. The user wants to grant the
access but not tell the client the user's identity. By issuing the refr= esh
token as an 'identifier' for the user (as well as other context dat= a like
the resource) it's possible now to let the client get access without revealing anything about the user. Recommend that the above explanation be<= br> included so developers understand why the refresh tokens are there.

So far, though it's been only half a day, I've seen several posts disagreeing with Tony, and none supporting any change to the text for
this. =A0We're close to ending WGLC, so please post here if you agree with Tony's suggested change. =A0Otherwise, it looks like consensus is<= br> against.

Barry, as chair
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
-----------= -------------------------------------------------------
Never send sensi= tive or private information via email unless it is encrypted. http://www.gnupg.org
--e89a8f6465c5cb12d904aa5115f4-- From barryleiba.mailing.lists@gmail.com Fri Aug 12 10:39:57 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F4D21F8581 for ; Fri, 12 Aug 2011 10:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.042 X-Spam-Level: X-Spam-Status: No, score=-103.042 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgQIfVIU-pi6 for ; Fri, 12 Aug 2011 10:39:57 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59F6F21F8588 for ; Fri, 12 Aug 2011 10:39:57 -0700 (PDT) Received: by gxk19 with SMTP id 19so2475977gxk.31 for ; Fri, 12 Aug 2011 10:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LnK5QVHBW1gsg8+haMDIuoAqUpcVKeBcnwEN6kYvmEM=; b=xKPC/CkiaDK6AjX4fx34FaaQuXuVF1hfWayeAUIzgh/VP5vAEkGDt5uvW92mUG2EtG qSqqbGHfiDdYfe6o9SarvacvbHdxTo19KxVikC20es0XoAurn40ofVWUEnzEG3dNAQ0b G9sR/J2yjuLVbh06qVO55e2wcuNClZgI7UTyA= MIME-Version: 1.0 Received: by 10.236.170.165 with SMTP id p25mr3855532yhl.143.1313170834849; Fri, 12 Aug 2011 10:40:34 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Fri, 12 Aug 2011 10:40:34 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Aug 2011 13:40:34 -0400 X-Google-Sender-Auth: 0YKM_s5qc8FhIcTGp0UalDCOgrc Message-ID: From: Barry Leiba To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 17:39:58 -0000 > Please find below the text Niv and I prepared. In comparison to =A0Niv's > original proposal, it covers resource owner impersonation for all client > categories. This makes sense to me, and I like the proposed text. Barry, as participant From igor.faynberg@alcatel-lucent.com Fri Aug 12 11:00:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0C321F8745 for ; Fri, 12 Aug 2011 11:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm7kAy0wGXod for ; Fri, 12 Aug 2011 11:00:14 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2656421F86EE for ; Fri, 12 Aug 2011 11:00:13 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p7CI0o1V022872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 12 Aug 2011 13:00:51 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7CI0o7K011399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 12 Aug 2011 13:00:50 -0500 Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p7CI0oeh014040; Fri, 12 Aug 2011 13:00:50 -0500 (CDT) Message-ID: <4E456A52.4090401@alcatel-lucent.com> Date: Fri, 12 Aug 2011 14:00:50 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <3CA3D010-E3C1-44A7-BC08-5FA3C83F305A@hueniverse.com> <90DA4C9C-83E1-4D78-BD6E-340084B4E912@hueniverse.com> <1313105180.20903.YahooMailNeo@web31803.mail.mud.yahoo.com> <88f4b10fcf44ac276be338f7eebd5634@lodderstedt-online.de> In-Reply-To: <88f4b10fcf44ac276be338f7eebd5634@lodderstedt-online.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] Refresh Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:00:14 -0000 Precisely! In fact the anonymity of this sort can be achieved even without a refresh token: as long as the end user is not required to authenticate to the client. But for all I remember, we have never had a SINGLE USE CASE (sorry to transition to my pet peeve) that required anonymity. The original and overarching OAuth requirement has been not to reveal user credentials; the refresh tokens were required in order to make end-user's life easier. In short, I do not recall anonimity being the end. I have no doubt that Tony has a new important use case, and I think we should document it, derive requirements from it, and pursue this in the next OAuth release. Igor On 8/12/2011 11:10 AM, Torsten Lodderstedt wrote: > OAuth allows a client to access user resources without revealing the > resource owner's identity to the client. Isn't this anonymity? I > consider this an important property of the protocol. > > regards, > Torsten. > > > On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote: >> This seems to need a chair to step in. Tony is taking a strong stand >> and maintaining it: >> >> On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin >> wrote: >>> Nowhere in the specification is there explanation for refresh >>> tokens, The >>> reason that the Refresh token was introduced was for anonymity. The >>> scenario >>> is that a client asks the user for access. The user wants to grant the >>> access but not tell the client the user's identity. By issuing the >>> refresh >>> token as an 'identifier' for the user (as well as other context data >>> like >>> the resource) it's possible now to let the client get access without >>> revealing anything about the user. Recommend that the above >>> explanation be >>> included so developers understand why the refresh tokens are there. >> >> So far, though it's been only half a day, I've seen several posts >> disagreeing with Tony, and none supporting any change to the text for >> this. We're close to ending WGLC, so please post here if you agree >> with Tony's suggested change. Otherwise, it looks like consensus is >> against. >> >> Barry, as chair >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Fri Aug 12 11:31:29 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335AF21F8686 for ; Fri, 12 Aug 2011 11:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQS3zjJoYvfr for ; Fri, 12 Aug 2011 11:31:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6A74E21F867A for ; Fri, 12 Aug 2011 11:31:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CAF6421B1D18 for ; Fri, 12 Aug 2011 14:32:05 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C709E21B1049 for ; Fri, 12 Aug 2011 14:32:05 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.3.192.1; Fri, 12 Aug 2011 14:32:05 -0400 From: Justin Richer To: "oauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Date: Fri, 12 Aug 2011 14:31:31 -0400 Message-ID: <1313173891.22073.127.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 8bit Cc: "Anganes, Amanda L" Subject: [OAUTH-WG] Bearer Token Last Call Comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:31:29 -0000 1.3: This draft still uses the term "access grant" where the core now uses "authorization grant". Change all references to "authorization grant" and reference section 1.4 in core. Also, too many parenthetical statements in opening paragraph -- suggested rewrite of this bit: Before a client can access a protected resource, it must first obtain an authorization grant [[link to core S.1.4]] from the resource owner, and then exchange the authorization grant for an access token. The access token then represents the scope, duration, and other access attributes granted by the authorization grant. 2: "...SHOULD NOT be used unless no other..." is a triple negative and while technically correct it is a bit head-spinny to read. Suggested rewrite: "Due to the Security Considerations (S.3) associated with the URI method, this method SHOULD NOT be used unless it is the only feasible method." 2.1/2.2/2.3: Introductory text is non-parallel. Suggest changing intro to 2.1 to parallel 2.2 and 2.3, with a "When including the access token in the Authorization header, the client ..." construct. 2.2: "unless the following conditions are met" is ambiguous. All conditions are met? At least one? 2.3: Are there conditions for this use as well, to match 2.2? 2.2/2.3: Add normative language to: "The entity-body MAY include other request specific parameters. In which case..." (similar in 2.3's request URI) Might be useful to have the example show an additional parameter. 2.4: Should this be a top-level section? Since it's dealing with the from-the-server bit instead of the to-the-server bit that the rest of 2. is dealing with. 3.1: Missing word: "Token redirect: An attacker uses the token generated for consumption by [one] resource server to obtain access to another resource server." 3: There's a mix of normative and non-normative language throughout this section, as well as a mix of imperative and descriptive language. We suggest making the whole section normative and imperative to be consistent. Particular instances: 3.2: "the lifetime of the token MUST be limited†3.3: validate SSL certificate chains: "The client MUST..." 3.3: issue short lived bearer tokens: Change to something like "Token servers SHOULD issue short-lived (one hour or less) bearer tokens, particularly when issuing tokens to clients that run within a web browser or other environments where information leakage may occur. Using short-lived bearer tokens can reduce the impact of one of them being leaked." 3.3: scoped bearer tokens: "Token servers SHOULD issue bearer tokens that contain an audience restriction..." 3.3: don't pass: "Bearer tokens SHOULD NOT be passed in page URLs (for example as query string parameters). Instead, bearer tokens SHOULD be passed in HTTP message headers or message bodies for which confidentiality measures are taken. Browsers, web servers, and other software may not adequately secure URLs in the browser history, web server logs, and other data structures. If bearer tokens are passed in page URLs, attackers might be able to steal them from the history data, logs, or other unsecured locations." -- Justin Richer From jricher@mitre.org Fri Aug 12 11:43:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2F221F8538 for ; Fri, 12 Aug 2011 11:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srie5dOmbqWi for ; Fri, 12 Aug 2011 11:43:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE5E21F8520 for ; Fri, 12 Aug 2011 11:43:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 68DD921B1A15 for ; Fri, 12 Aug 2011 14:44:22 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6583A21B1A12 for ; Fri, 12 Aug 2011 14:44:22 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.3.192.1; Fri, 12 Aug 2011 14:44:22 -0400 From: Justin Richer To: "oauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Date: Fri, 12 Aug 2011 14:43:48 -0400 Message-ID: <1313174628.22073.135.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "Anganes, Amanda L" Subject: [OAUTH-WG] MAC Token Comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:43:48 -0000 2: MAC Key: "The server MUST NOT reissue a previously issued MAC key and MAC key identifier combination." 3: I would still like to see a binding for post body and url parameters. This could be as simple as defining a set of parameter names for everything used in the auth header, but I'm still given the impression that this has been deemed outside the scope of the MAC token. Our use case is to pass around signed URLs between servers with all query parameters protected by the signature, which we use 2-legged OAuth 1.0 for today. We can try to get language for this together if there's enough draw for it, but I haven't been hearing that from other folks yet so we might just try to draft an extension to the extension, instead. 5: This section's wording should be brought more in line with the descriptions of the OAuth protocol in both core and bearer, which in turn should actually be a bit closer together themselves. Seems like we need a succinct elevator pitch for "what is OAuth2" to drop into all of these locations (and other extension specs) -- anybody want to take a crack at distilling one from these three sources? 7.9: Grammar tweak: "Those designing additional methods should evaluate the compatibility of the normalized request string with their own security requirements." -- Justin Richer From tonynad@microsoft.com Fri Aug 12 12:06:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7F111E809B for ; Fri, 12 Aug 2011 12:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzrrm5nvMSSY for ; Fri, 12 Aug 2011 12:06:06 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0300911E8090 for ; Fri, 12 Aug 2011 12:06:06 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 12 Aug 2011 12:06:43 -0700 Received: from DB3EHSOBE003.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Aug 2011 12:06:42 -0700 Received: from mail66-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Aug 2011 19:06:40 +0000 Received: from mail66-db3 (localhost.localdomain [127.0.0.1]) by mail66-db3-R.bigfish.com (Postfix) with ESMTP id 27FBA119009B for ; Fri, 12 Aug 2011 19:06:40 +0000 (UTC) X-SpamScore: -6 X-BigFish: PS-6(zzc85fh13e6Qzz1202h1082kzz8275bh8275dhz31h2a8h668h839h) X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT006.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail66-db3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT006.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail66-db3 (localhost.localdomain [127.0.0.1]) by mail66-db3 (MessageSwitch) id 1313175999503764_16771; Fri, 12 Aug 2011 19:06:39 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.252]) by mail66-db3.bigfish.com (Postfix) with ESMTP id 7096A1B7004F for ; Fri, 12 Aug 2011 19:06:39 +0000 (UTC) Received: from SN2PRD0302HT006.namprd03.prod.outlook.com (207.46.4.139) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 12 Aug 2011 19:06:38 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.22]) by SN2PRD0302HT006.namprd03.prod.outlook.com ([10.27.91.23]) with mapi id 14.01.0225.064; Fri, 12 Aug 2011 19:06:37 +0000 From: Anthony Nadalin To: "OAuth WG (oauth@ietf.org)" Thread-Topic: Auth Code Swap Attack Thread-Index: AcxZImYoC2iZvOhxR/+zEXUukLHDog== Date: Fri, 12 Aug 2011 19:06:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [50.46.124.183] Content-Type: multipart/related; boundary="_004_B26C1EF377CB694EAB6BDDC8E624B6E723BA5043SN2PRD0302MB137_"; type="multipart/alternative" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT006.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com Subject: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 19:06:07 -0000 --_004_B26C1EF377CB694EAB6BDDC8E624B6E723BA5043SN2PRD0302MB137_ Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723BA5043SN2PRD0302MB137_" --_000_B26C1EF377CB694EAB6BDDC8E624B6E723BA5043SN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is an attack that Yaron, Torsten, Phil and I have documented which sho= ws that there is a protocol flaw that needs to be corrected; the proposed t= ext changes are also included. Auth Code Swap Attack This attack describes a phishing attempt where an attacker "gives" away acc= ess to a resource controlled by the attacker in order to compromise a clien= t application. Dramatis personae Plaxo - An OAuth client. It asks its users to use OAuth to give Plaxo permi= ssion to access their address books in various services like Live. It uses = the permissions to synch address books in remote services like Live's with = the central address book kept in Plaxo. Live - A resource server. It accepts authorization requests from clients to= allow them access to protected resources. Those protected resources are ad= dress books owned by Live's users. Gene - Gene is a user of both Plaxo and Live. Gene wants to use Plaxo to ke= ep his address book at Live up to date. Basil - Basil is an evil doer. His desire is to steal the contents of Live = user's address books for marketing and other purposes. Attack setup Basil creates an account at Live. Basil creates a website called 'Silly Fun Times' The actual attack 1. Basil sends spam to various victims trying to get them to com= e to his 'Silly Fun Times' website. 2. Gene opens the spam mail and clicks on the link. 3. The server running Basil's website initiates an authorization= request to Live. The request uses Plaxo's redirection URI. The code runnin= g on Basil's server uses Basil's Live credentials to login to Live and to g= rant the authorization request. Live responds with a redirect containing an= authorization code. Basil's server swallows the redirect and creates a web= page containing the authorization code and sends the web page down to Gene= 's browser. [Note: Normally the actions in step 3 would be performed by a h= uman at a browser but in the attack Basil has automated the process so his = attack server can do everything automatically.] 4. The web page, from 'Silly Fun Times', running on Gene's brows= er now completes the redirect sending Gene, using the authorization code th= at Live issues in response to Basil's request, to Plaxo. 5. Gene is already logged into Plaxo so he isn't even asked anyt= hing before Plaxo accepts the redirect with the authorization code. 6. Plaxo's server then uses the authorization code to get an acc= ess token and refresh token. 7. Plaxo uses the access token to synchronize the address book o= n Basil's Live account with Gene's Plaxo server. The outcome of step 7 is two separate attacks. One attack is that Plaxo wil= l now push all of Gene's address book information into Basil's Live account= . So Basil has now successfully stolen all of Gene's address book data. The= other attack is that if Plaxo is doing bi-directional synch then Basil cou= ld put false contacts (perhaps with bad URLs to launch various types of att= acks) and related information into Gene's central address book at Plaxo. Variations: 1a. Basil could buy ads on search services like Bing and Google and use tho= se as a way to lure people to the 'Silly Fun Times' website. 5a. Gene might not be logged into Plaxo but if 'Silly Fun Times' sets thing= s up right it could fool Gene into thinking he is supposed to see Plaxo and= so will handle the login. There is an obvious variation of this attack for auth tokens rather than au= th codes. Pretty picture The numbers in the picture are keyed to the steps in the use case above. [Description: Description: Description: cid:image002.png@01CC5131.B0C50110] Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring "state" should change = from: state OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable= the client application to determine the user-context that was active at th= e time of the request (see section 10.12). The value MUST NOT be guessable= or predictable, and MUST be kept confidential. Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the resource owner resulting in a comprom= ise of either the resource server or of the client application itself. In t= he OAuth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather than th= e victim's. Depending on the nature of the client and the protected resourc= es, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "state" paramet= er to authorization and access token requests to the authorization server. = The client MUST keep the state value in a location accessible only by the c= lient or the user-agent (i.e., protected by same-origin policy), for exampl= e, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirect, th= e client application MUST confirm that returned value of "state" correspond= s to the state value of the user-agent's user session. If the end-user sess= ion represents an authenticated user-identity, the client MUST ensure that = the user-identity has NOT changed. Yaron, Torsten, Phil and Tony --_000_B26C1EF377CB694EAB6BDDC8E624B6E723BA5043SN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is an attack that Yaron, Torsten, Phil and I ha= ve documented which shows that there is a protocol flaw that needs to be co= rrected; the proposed text changes are also included.

 

Auth Code Swap Attack

This attack describes a phishing attempt where an at= tacker "gives" away access to a resource controlled by the attack= er in order to compromise a client application.

 

Dramatis personae

Plaxo - An OAuth client. It asks its users to use OA= uth to give Plaxo permission to access their address books in various servi= ces like Live. It uses the permissions to synch address books in remote ser= vices like Live's with the central address book kept in Plaxo.

 

Live - A resource server. It accepts authorization r= equests from clients to allow them access to protected resources. Those pro= tected resources are address books owned by Live's users.

 

Gene - Gene is a user of both Plaxo and Live. Gene w= ants to use Plaxo to keep his address book at Live up to date.

 

Basil - Basil is an evil doer. His desire is to stea= l the contents of Live user's address books for marketing and other purpose= s.

 

Attack setup

Basil creates an account at Live.

Basil creates a website called 'Silly Fun Times'

 

The actual attack

1.        &n= bsp;   Basil sends spam to various victims trying to get them to = come to his 'Silly Fun Times' website.

2.        &n= bsp;   Gene opens the spam mail and clicks on the link.

3.        &n= bsp;   The server running Basil's website initiates an authorizat= ion request to Live. The request uses Plaxo's redirection URI. The code run= ning on Basil's server uses Basil's Live credentials to login to Live and t= o grant the authorization request. Live responds with a redirect containing an authorization code. B= asil's server swallows the redirect and creates a web page containing the a= uthorization code and sends the web page down to Gene's browser. [Note: Nor= mally the actions in step 3 would be performed by a human at a browser but in the attack Basil has automated= the process so his attack server can do everything automatically.]

4.        &n= bsp;   The web page, from 'Silly Fun Times', running on Gene's br= owser now completes the redirect sending Gene, using the authorization code= that Live issues in response to Basil's request, to Plaxo.

5.        &n= bsp;   Gene is already logged into Plaxo so he isn't even asked a= nything before Plaxo accepts the redirect with the authorization code.=

6.        &n= bsp;   Plaxo's server then uses the authorization code to get an = access token and refresh token.

7.        &n= bsp;   Plaxo uses the access token to synchronize the address boo= k on Basil's Live account with Gene's Plaxo server.

 

The outcome of step 7 is two separate attacks. One a= ttack is that Plaxo will now push all of Gene's address book information in= to Basil's Live account. So Basil has now successfully stolen all of Gene's= address book data. The other attack is that if Plaxo is doing bi-directional synch then Basil could put false = contacts (perhaps with bad URLs to launch various types of attacks) and rel= ated information into Gene's central address book at Plaxo.

 

Variations:

1a. Basil could buy ads on search services like Bing= and Google and use those as a way to lure people to the 'Silly Fun Times' = website.

5a. Gene might not be logged into Plaxo but if 'Sill= y Fun Times' sets things up right it could fool Gene into thinking he is su= pposed to see Plaxo and so will handle the login.

 

There is an obvious variation of this attack for aut= h tokens rather than auth codes.

 

Pretty picture

The numbers in the picture are keyed to the steps in= the use case above.

 

3D"Description:

Re= commended Changes to draft-ietf-oauth-v2

=  

In se= ction 4, request options (e.g. 4.1.1) featuring "state" should ch= ange from:

=  

= state

= OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client.

=  

to:=

=  

= state

= REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable the client application to determin= e the user-context that was active at the time of the  request (see se= ction 10.12). The value MUST NOT be guessable or predictable, and MUST be k= ept confidential.

=  

Secti= on 10.12 Cross-Site Request Forgery

=  

Chang= e to:

=  

= Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trust= s or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the&= nbsp;resource owner resulting in a compromise of either the resource server= or of the client application itself. In the OAuth context, such attac= ks allow an attacker to inject their own authorization code or access token into a client, which can result in the client using a= n access token associated with the attacker's account rather than the = victim's. Depending on the nature of the client and the protected reso= urces, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "stat= e" parameter to authorization and access token requests to the authori= zation server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., = protected by same-origin policy), for example, using a DOM variable, H= TTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parame= ter when redirecting the user-agent back to the client. Upon receiving= a redirect, the client application MUST confirm that returned value of &qu= ot;state" corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-ide= ntity, the client MUST ensure that the user-identity has NOT changed.<= o:p>

 

Yaron, Torsten, Phil and Tony

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723BA5043SN2PRD0302MB137_-- --_004_B26C1EF377CB694EAB6BDDC8E624B6E723BA5043SN2PRD0302MB137_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=88439; creation-date="Fri, 12 Aug 2011 19:06:34 GMT"; modification-date="Fri, 12 Aug 2011 19:06:34 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAssAAAJQCAYAAAB4qSlbAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAP+QSURBVHhe 7J0HmBTF1oabLEFYFHPCHK9izjleI9ccr1mvGa/+5njNGXNWzBHFnFAxRxQDBkygiIoISxBJwv+9 bdXaO8ywM7vdM92zp57nTPd0V/xOd9dXp09Vtz777LMDC4aAIWAIGAKGgCFgCBgChoAhMDMCrQ0U Q8AQMAQMAUPAEDAEDAFDwBDIj4CRZbsyDAFDwBAwBAwBQ8AQMAQMgQIIGFm2S8MQMAQMAUPAEDAE DAFDwBAwsmzXgCFgCBgChoAhYAgYAoaAIVAaAmZZLg0vi20IGAKGgCFgCBgChoAh0IwQMLLcjJRt TTUEDAFDwBAwBAwBQ8AQKA0BI8ul4WWxDQFDwBAwBAwBQ8AQMASaEQJGlpuRsq2phoAhYAgYAoaA IWAIGAKlIWBkuTS8LLYhYAgYAoaAIWAIGAKGQDNCwMhyM1K2NdUQMAQMAUPAEDAEDAFDoDQEjCyX hpfFNgQMAUPAEDAEDAFDwBBoRggYWW5GyramGgKGgCFgCBgChoAhYAiUhoCR5dLwstiGgCFgCBgC hoAhYAgYAs0IASPLzUjZ1lRDwBAwBAwBQ8AQMAQMgdIQSB1ZPvPMM7dUE5YorRkWOwEEXjj77LOH FJOv6awYlMoSpxSdbaEaLVmWWlkhs0LAdJau6+NJPfeGxVUlPRvtPosLzKbl0196/bKYLExnxaBU ljhF66wctUkdWZ5rrrmOvfPOO7fs0KFDOdpvZeRB4KWXXgr0YDlOD40rtJ3REEhzzjnnsXfdddeW HTt2bCiqnU8IgVJ11q1bt2N0n21tOktIIUVkazorAqQyRnn00UeD3r17T9Rzr08xz71iqmb3WTEo JRvH3WcnSK+XFqNX01my+igm9wEDBgTSV9E6KybPpsZJHVlW5z1uq622amq7LH0TEBg7diypGa20 lUxuKCuvsxYtWjQU1c4nhECpOtNgdDz3meksIYUUka3prAiQyhjl66+/prROkjaSKXEUbfdZHCg2 LQ93n7VXLu0kkxrKzXTWEELJnx8/fjyFFK2z5GsUBKkjy9OnTw/GjRsXdO7cOZb2//jjj0HXrl0D LNWMVsh/k002aXTeM2bMCH744YdgwQUXDFq2bDlTPuT//vvvB2PGjAnPUVabNjx7sxMmTpxIZRu0 KPsWgQk669Kly0yN5NywYcOC7t27B3/88Ufw6quvBossskiwzDLLNBqQ33//PaitrQ0WWGCBvHnw cBw0aFAwadJfz8WmlDdt2rSATnTxxRcPfv7552ChhRYK8+QamHvuuYN27doFI0eODLDQItzkyPzz z1+vbr/++mvQqlWrYI455ijYbvIHr06dOgVTp06dZdzcTOLS2dChQ0NdvfPOOyHGXOfLL798wH3U tm3boHXr1mE7Jk+eHLY9333KtfDhhx+G+BNngw02yHuv5AOCcj799NPwfgV7ZIkllgjLXHjhhRt9 zUQTfv/998F8880X3pdgXlNTE8w222xhe6nzvPPOW6+cX375JWwH8QqFESNGhNgQDx3OKq7PIy6d xQJKCZl4nH766afw2idstNFGYdu517lm0FfWAs+nUp57xbRvVs/GYtKXIw7P09GjR4f3KM8tP4BG v3/++WeozyyHrN5nUcx5vsAt6Bv8s4X/9EP0b8UE+iWwgA/xfGefZ2BT+FAx5TYmTqk6a0wZpaZJ HVkutQENxb/iiiuCf//73wE3Pq9jCOzvsssuYedPp08HGSV6vpOmAyVAXFAecXj4nXjiiYFeYYdp p0yZUi8tF/Vxxx0XbL755mHazz77LDj00EPDzp+0PIhyH6D+eL62QPyoBx0RgbrxcMslphyns05b oP7nnXdecPnllwc33nhjiCN62G677YJ11103xIM46KJ9+/bhA4GH9oQJE8IHgw8QMI5zbODAgUHf vn2DK6+8MkwbxYf4vE595JFHgtVWWy1MThn5yDlpwREdEqgDIXpNoJtvvvkmfED973//C26++eYw zumnnx5ceuml4aDoqquuColzr169gtdffz147733gjPOOCOsG3rngfTAAw+EDynaHSWYxEG3tGHU qFGhfp966qlw8PHf//633rWXtG5p92WXXRZeu2+++WZY92eeeSb417/+FdYZ/aA7Bg4MIOhEd9hh h5mq9cQTTwT33ntvsOaaawazzz57sN56681Elv01zwOcOD4wqOBB/sorrwRyyQpWXHHFsFwwZKCC LqNpctN7nfr8uFfo8KOYn3baacENN9wQPgeuvfbasLM5/PDDgxdeeCFgsPB///d/oe4Y/HBP3XHH HcFSSy0Vdiq5uqNuXDeQbrYvvvhiqEvu+XzPlqR1WI78n3/++eCDDz4Ivvzyy2DllVcOixw8eHBw 8MEHh/cI9yX3KRh6fHiGeqMB+oBMcx487e1GObRWuAyMOzwzudYvuOCCOj0xEOLZ6MlytJ/Kvc8q 24LqL/2aa64J+336zF133TVsMLqRW0n4LPN9V/S5yn0V7UPfeuut0IjB810uDuEAl/6YZ9eee+5Z /SA2sYXpY1dNbFA0OZZkrI+Mmt9+++3goosuCk/zYPjkk0/CzpgLDUsJ5HnDDTcMCQqdJA/3448/ Puzkr7vuuvCC2nrrrYMtttgiWGWVVUKycOutt4akDjKx5ZbMSwzC/1zQkCUCF+Hee+8d/odw7b77 7sHTTz8dWs8gTjx0uKB79uwZErBzzjkn7HggKeuvv35IyulwjjzyyJDYXX/99cHw4cODzTbbLCQq p556aljHvfbaK7QApi3ccsst4WAForzCCisE3sXm9ttvDzta2nrbbbeFxAzseUCDK4RjueWWC9v1 1VdfhaSGh/mxxx4byKcsWGmllUJCd88999SREwgNAQvRgQcemJfIcV5+iaGllHjbbLNNSHDpvMkb ffBg4txOO+0U6uDzzz8PVl111XqED8LIqJ56Q3Ihtwy6IEu0A/1BGrnG0B2k4Lnnngt4YHENgcNr r70WknrIMnHI47vvvgsgI5BArhv0jWWTa4WHXJIDIgYCO+64Y9CvX7/gsMMOCwcYdKRcb9wPPJCp Kw9h7hFwg9wedNBBwcUXXxxsuummIU48gA844IAQPx+4ts8666xwIPHFF1+EAxn/kEeX3H9g2aNH j1AgXFwv5Pnuu++GWFM21xNbrh06D/I74YQTwvuca4E3Cv/4xz+CffbZJ7xnGcigS65BdEnAck6b SM9gh/PUGd1AlHk+QJzJ8z//+U9I5h9//PFQL9tvv31ImtEz+uXeRXc8Q7h2iUM7iMd1RP7gsPHG GxdtXU/bPRytD9c6+uDavP/+++s95+jE/dsH8Hr22WfDe5VrAaz8vcZ1xaCkf//+4TW23377lfQW Jc34ZK1uGCeefPLJcHDHvZKrawZF3Oc8G+++++66vpHBLPfZHnvsUdRblKzhkqb6PvTQQ2HfzvMK Y0o0YIA599xzw+fboosuGpJnOAfPT/q0I444Ilh22WXDJDy34Qrkw/MJ4w6BZ/eDDz5YR8LT1PY0 1aWqybK32tHRe0ssN/zHH38cdsh0iosttliw7bbbhuSADhhyQCcHQYPw0PFBViG7dJxYy+hQ6fzX WGON0Go2ZMjfi0bQsUKCsC4TGL1Bksn3wgsvDEk29brpppvCBxDE+ttvvw07E0g9WzpyOhEIJeXQ 6UPE6MyxylAXbgI6f0g/ZCWNRJn2Q/QgjL/99ltoweNmx/rECBjSw0AEEkUHDFljAIDFis72lFNO CUktRBv9QMx4MIALRHrfffcN/9OBu1eoIeYQGPLF5YOAGwB64jqgLuiWV+08WCAxXBMvv/xyqG/I Hh0A50866aSQsHn9Rt1uiMN1AtFjHysl1m70w/UCccPyzGAHSzHXHx0TRN1fR1hfaTv1xwrJWwm2 DBDIB7KB2wYdGcK1Epd7Ur6HELriHqAsb0EHZwYekHas55AhHrrokXOQRNoN/t71hHsAIsxghmuT hzWuD+icQQCkki24PvbYY+H9tPrqq4f5+UB+DDz9NUR6dMf9Q+cOWWPAgY64lyBcvHFAp1w33Jvk zQCXewmy7QPklfqhWzoZ7j/agH6xfj788MOhhZ02M+DmGcAg5eqrrw4OOeSQcLBM58IbE68z6ofe 0Z0mvIYDDgZUlI++uf7826E0dQCl1gW9oxdcYyBR/jnHfcS1io65hrkGeE6BAwMIrgEGvDwL1157 7fC+QG9YuN54441wMGihMggwoON5x/MpGuiHCBguuD+4bxlAcl+jW+6zJZdcMjTcWEgOAfrOXNcw Xxr3I4YHBu/0DbyJ4z7jucszFiJMf0ngue0Jc7S/5LlKH2Rh1ghUNVmm8+Ki4ILyDwIsVVijPvro o/DBjXWEfcgmIzHIAkQaiycdJHlgCaYzhFgzkiPwoMBSzWtpSJsPdBR0klhTCHQKkGNG4WuttVbY efhXJpA3OlFIF2SNjpoHERZGyCEdEq/F6IQgxzy0sHjx0OLVGDeH75DTeqGDIZhA/uhI+Q/ROfro o0NcGOWef/75IVHB8sQNzuDFr4YCJgwUcOPAmglh9AGrOjqAiIKXD7yeAlespATIC+QPUsSAhYcD lkzqhU544NOhE7gmILHUjcELBMfrK4qx94fGZWD//fcPXQd4XQ9J4IEEOYNMEY/OhOsJUk37vV+y v4bQI3iQzp/31x7XD6Ry6aWXrueukIS+aSdECMsrpI+2Q9jpKLEQcn9QdwIYM3BkAMc1ybWKHzAB XDkHKfV+5bQHYSCDTkmPdYP7yz/AC7WJcknD/cJbHPKBuPM2BoJPvbk2GHCBOXWkLuDLYIRBcfT6 8NcjA1juU/LFTYb7jLy5TsiHZwdvghh0cc369vMMwJodvTe5fknLdc6WOmER4rUnz5Z811ASOkw6 T+5L8OI6YfALLgSemeiR9vu3D2CIDzN6ZmACXlo1J0zrfZrRq7lhJK21wvlz3dI3ck/4waKPjV7o 89AVhgTmDPBWhWco9xji3+ZVrgXVXzL9Pv0IeEfnP6EXjvNGnL6Q+xJjAW9svCvUOuusMxNA5BOd U8D/XIt19aNaegurliz7V+JYjugE6RgROmdGaYzGsOJCmnChgKRysUGQPBngwU/njrWTeFhAeKjQ GWI9Jh15Q9iwlhC8vzMEjUB+5IMFzltTIYS8bvdWGCzEkGh8/ujY6VioCx3tySefHFpZqSsPK4gk RIa6QDiwCtD5pNFqxSs82k6nSr29pR4ywn90AamByDBAoM2QZ0bSBMgKeM8zzzyhDiAcWJoJ5Ev+ 4EO+WHLxJffp0JHXAUQKC6QP6AR9QLj8REzK4aGE1ZIBCKSXawIdUSc6FLY+4D8LyWWLzulUSI8F jQcaW8rEhcMTvUsuuSS0cqIr2oYllPpD1NE7+qVu4IClmusUwgnZ8Nee96Mv/VafdQp868GE+wIL KuSHgQR1BRvfObJP/dhCVLkHSBtdwQacIMnen5WSqTdvDHjVC3kET69nXCDQZzSAj/clpzzuZ3D2 afxEStJRHvHpyHGBYeBCx889uttuu4XpsCQjBPTLtccgiYBO0BFvCagXbUd3vLWBMJA3BIE2gQf3 GwNs4qA3BhQcp77ggosB5VO29//2JDpuvZU7P8gubkTg5N1hfB04hp64l3lbw1uxo446KjzGvUR8 3OEgWFxPPAPRXbUMJMqtizjKY0DH9Y6RgDd3vHXzA1vuS651rP68pcHQxFtOtv4+y71v46iT5fE3 AhjGeBN+zDHHhDrgXuK+Ifh+hPuHZxhvuejr6JfgPXCX6Bs1/xz1ixSQD0Yh3iBgFLAwawSqlizT bD+Tn30IGf7APNAZhUFEuKAgBlg8sA5ioeSVPYGOlAc5bhS8LiTOzjvvHHb6BF7FYu2kY2DCkA/k Sz6URcAijCUTSyedNg8aHkq8osdKRh25wLnQydPPbqXzhoBRLoSMm4UOGKLJMaxqdPgQ7TQSZdrO gxQLIw9icOUmhTBCVrCk8lDmoQsWkFNex3PjggOBUTHHedWLhZD4+JETwMJb3iEx4OMD6fF79jqA REX9Z6kTOvErNZAOAoceeG3O4IdBEK/cGYGDMRY1f20QHx1TP9pGvciPARMDHfIhrdcdk8cgoliW eUWGNZP8wYE4DBjAAQLmZztjHSAPXFCIQ9okSQW6wgWFAQYYg4G3GIMdZB1d+NnUfjDCfcI9QLt9 YKCQa6mgfVg7uJ9oN/eJJ9PcG7mrR3DOW6UZRKAr/vPAJ6ATcPZvg6gHFhawQr9Yf3klyfUGgeV1 vw+0kTcUPn/wR5c+HW+KyId6UjfeCnGv8azgOUJnxACQOGx55QkJJA448maCa5qBAXHIL4urQ9QB FtnhuYTLBc/BXKsVAwvw4i0ELma4HDHI9ROjGfAzGAUjnqVgRB5cExYqgwD3qdcngxgmxKNHrnEG yzyP6H/QE/cT+uc56O8zDBkWkkPAW+95ztBH3XfffeF9Q6Bfw1jBcwf9YGDhGc3zm7e16NG7SREf ruENOwyCyId+lLdkfpWn5FqS/ZyrlizzMMeq4QMPcDrraMi1OHIOf00CD30fovlE8+OCzA08ZPB1 zA0+X45D0pFoXpB1QnR1ATpvJBrwf4wGCFVaA36oiA+QGSQaeOWPG4oPkEgeyoSoe0vu5BMeBFhB /YoX0Tx5cOR7/eTjYJn3AaJD8BM02Y8SK/57lxof16fNXQ+ctw8+QNg96ecY5M5PMPNxIKeID3RO PkCSCdFBQD3gYv4DIUQIdJB+oOGLyV1eyOsIyyruM9GZ8nS+uQHimatDP/HEX/vRNAwGfYhaqD0p 9zohjr+XsMAjPtCR+44ltz65PrIMRqJ6iOqCAS4SDQyM/NskjkcJn7/26ISqLUSfN7n3A/ekf87R sUO8ckP0+RYdfFYbTllpT/S6z9ef+Xbw1tMHdJhvFZystDlL9eQZ5vv8fM8h35ZoX8MbUwaquSH6 jPd+zFnCotJ1rVqyXGlgrXxDoDkgwAM8yUmHzQFDa6MhYAgYAoZAuhEwspxu/VjtDIFUI2BEOdXq scoZAoaAIWAIxICAkeUYQLQsDAFDwBAwBAwBQ8AQMASqEwEjy9WpV2uVIWAIGAKGgCFgCBgChkAM CBhZjgFEy8IQMAQMAUPAEDAEDAFDoDoRMLJcnXq1VhkChoAhYAgYAoaAIWAIxICAkeUYQLQsDAFD wBAwBAwBQ8AQMASqEwEjy9WpV2uVIWAIGAKGgCFgCBgChkAMCBhZjgFEy8IQMAQMAUPAEDAEDAFD oDoRMLJcnXq1VhkChoAhYAgYAoaAIWAIxICAkeUYQLQsDAFDwBAwBAwBQ8AQMASqEwEjy9WpV2uV IWAIGAKGgCFgCBgChkAMCBhZjgFEy8IQMAQMAUPAEDAEDAFDoDoRMLJcnXq1VhkChoAhYAgYAoaA IWAIxICAkeUYQLQsDAFDwBAwBAwBQ8AQMASqEwEjy9WpV2uVIWAIGAKGgCFgCBgChkAMCBhZjgFE y8IQMAQMAUPAEDAEDAFDoDoRMLJcnXq1VhkChoAhYAgYAoaAIWAIxICAkeUYQLQsDAFDwBAwBAwB Q8AQMASqEwEjy9WpV2uVIWAIGAKGgCFgCBgChkAMCKSSLLdp0yaGplkWjUWgdevSLwvTWWPRjied 6SweHMuZi+msnGg3XFarVq0ajtSIGPZsbARoMSax+yxGMMuUVWN0lnTVSmdFCdfozz//7FhbWxto m3BJTc9+7NixJdWzffv2AZL2MGHCBKpY9Ihl2rRpoc6mT5+e9qZVbf1K1Zm/z0xnlbskTGeVwz5f yRMnTuRwrH2i3WeV17HdZ5XXQak1KFVnpebfmPixPhgaU4HcNL/88svra665ZseWLVu21bkZceSZ QB5Tpk6duvhGG220UJcuXYrOfvDgwcG33377iSwYY5WoZdEJyxxRnUYL4T9CRKqoOv7666+vr7XW WmnXWSEUp8+YMaOD9Dl/27Ztv1GkFmWGO5biStXZyJEj0dnsKb/PTGcRBLKksxYtWkydMmXKEnrW 1eoaq83CfTV+/HieeyOLfe4Vc+NmSWd52uOfjQvo2fh1FnRYYBCEXn8sVq+ms2Ku7GTjuP6saJ0l W5u/ck8dWT799NMvOPPMM29S3TqkmCyPVt3OOeOMM/679NJLF62n0047LXj11VcvUYKXXNuKIqNF FxBfRAgjpv2iBitOZzcqfsdi08RX1SbnNEU5LCU5QnK6ZFKTc6xMBqXq7CLdZzebziqjLFdqNets nNp4geQ9yQspf975iwB9TIvzGaZnY9bvsyWEx1FV8mws6tWn6ayiz8TovQgHKUpn5ahx6sgyjT77 7LN/0wZJbRDRGCfLSWPqx8P4Z7Ux/X4mJbRO7WEAgWQuSJedVWk6yjHu2stcGxpTYdNZY1CrbJos 6Uz3FQ9IpOqed6VcBVnSWW67pMNO7tlYq3aMKqXdWY5rOsuy9pKpeyrJcjJNtVwNgYIIjNCZqyVF WdINx1QgYDpLhRpmWYnbdXaqhJlzVWUcSD/0sdXwZ/dsTI2FL7aWVW9GprMEdGtkOQFQi8gyk36x RbQrk1FkRWBmzxuyohQ9qTGTDa2iSpvO0q9M6ehjaqn7KpllJtIPQeZraPdZ9lRoOktGZ0aWk8HV cs0QAo4kd9VDZmSGqt2sq2o6S7/6paNuquUE3VdZnQeQfpATrqHdZwkDnED2prMEQFWWRpaTwdVy zRYCC6u6J+ghc4Q6dnzKLaQfAdNZ+nV0vKr4suS59FfValgAgYV0/CQ9Gw+3Z2NmrhHTWQKqMrKc AKiWZSYRmE217qxOgUl+5rucDRWaztKtJ1b7qcENo9omNKcb9thrx33WRXocbc/G2LFNKkPTWczI GlmOGVDLLpMI0Km3k6R1Kb9MgppwpU1nCQMcQ/bMAaCPsTkaMYBZoSzQHd88sGdjhRTQiGJNZ40A raEkRpYbQsjONwcEflIjP2kODa2iNjIp8/Mqak81NuUrNYrlJI0sZ1e7dp9lT3emswR0ZmQ5AVCT zlKvw/hgy/6SxSR8WOLLfK/HFI84K0j66vyb+eqlOFvq+Mc6D2FMTVC9lldl/PU5u+r3uq+czvXS /jc69kRjK6w8+BDJ4RKWtPpDcqVkYkOvGZWuRvFWl3wg2VjxH25sHSxd4xEQ7j9KFxcphzYN6azx pVjKJiJwg9L7dXqbmJUlrwQC9At2n1UC+caXaTprPHazSmlkORlck84VssYns++QHCM5WVLrC9XD jddme7v/d2q7mY511E30grYL6v+GEsgza9WeKHlMAlkMg+Lsos10xe+rfb7njSwr+V7HQmueju+g TQf9v0/77bU/twTyjl/bRzq2l/Yh6eFMeP3Hh2peyQKSGZB3F+dJ7Y9153fSOT5g8CJxnKziyn/d DRKu0H9cJj7Q/yWpp2SoZHe2SssScLQRa9bakn6S+SQr6xz7PpAv1z+DDSaL9dL5U5WW/fUlA/X/ CyLr2D+1mUNyn8R/4Wsu7XPcyHIE1HLuumvLVlooJ+gllCX9cG/yJT8LGUbA7rPsKc90Fr/OjCzH j2niOepGeMUXIiKHL1muP1lXHdtA8fbTeUgjX9FaWPvdtf235BvJHpKnJL9L6tYXVhw+bUr4U/vb avulBEJ4q2RDHeOz1lh9IZXE2VfbpyVYeSHvXXTsIG2/kxyt/ctVDwgmZPkRl1crHYfMfy05Svt8 EGQ3V5fVXZ2JDwHnq1GQYwLthGzT/jUk1K8X5UgoYwWlpYOmbsdKbpNcJqnlvM4x0aivy4uPJZA3 X4rkC35z6Pz82kK6f5Tsof93abuShE++sqwcAwCIPOX2lkxwedmmzAhIN1wbW0mfDAYtpBABN+j+ 1A+wU1hFq1IDCLj77J/SIc92CxlAwHSWjJKMLCeDa1ly1U1xpAp6SzImT4GQQcKKEgjwDxIspetJ BkuwnkKWX5KwvJMPkGuIJ24ZkFKst2/rYXmVyjtb+xBHjvOhAayrm0hYGgpXjssUp5f2f9X+1dqH yHCNkR/W7iE6fr6OQ9hbav9y7UNoIcFPSrAEzy7BdYQPGtT7apTiT1B8iPn7Lu6NOjZIx47Tdh9t sUxjAQePfjp2k47dr/1zXV0P0NaTZfy6NnfHsZxTBwjx85LFXR0gZB6P8dp/1bXDvmYlICocalT+ 1tIvA7DfpWtbwaTCCslTPM8Y3sx8YfpJn3KKrBGGBO4znpt2nxUJWoWjmc4SUICR5QRALUeWenjh 8gDBeyBPR4Qf7gzFaadzuERco/87SyC4kArOPyr5XgJRjBKNe/V/XQkWXNK8LYlO0MES/S8Jrhe4 NxCox69uH1L8mdvHou3zpmwm+xDwuf7W7UPqSb+fBDK/qATLbqFJQaTt6PL9xVmhXVbhp3WxFvNq HhcTQq0rF9IPQfaBdt8ufG5RHuSJe8c/JLtKBkloG3V+VrKBhA8s7CMBHx9s4lIEjDLvcg1PlvAG gmvSQvoQ4H7jHkJs/fL06aeYGnGf8TzleW/3WTGIVT6O6SwBHRhZTgDUpLMUuVtaZdwtwSWgp/4/ qC1+yK86lwdcC/pITtc5yCPkEjIIKXxDwsiTfQTSuKPkI1dvrK345+L6gF80k99WdBZj3DWGS7pL mLiD0BFCdsmLQBwIDMG7T7i/dXG47nj4RuNAdKkXaTlPvn7pqehnqCHjnGPr8/jM1W9VHePBTl5g QyAO+fmlxnxdIFr/VjragIUcHHyHTnxIPvmsKVlGQkfhib1fZo46WKgMAl6fZlGuDP7FlMp9Yp+6 Lgap9Max+yy9uilUM9NZAjozspwAqGXIEkKIawEkEjILYWAiTUgcnKWZCXRYdiB6/XUMAv2bjuF7 zOvRZ3SMFQVu0T6+umHQMSbs4c4wTfuPaR8r82uSTyU/6Bhk+X4dZ4IfbhyUT96Xuyzu0dZbcC/Q vncHIQ6rFxD6SbwrA8ewOJMe0s6ERdJglaZM9qOkm/xxiRhCObRVdemtferzw1lnnXXyHHPMEVx9 9dXL6/gAHTtBcf7QPm4d3tpMHXA9AS/IOcdfkLDU1fUS3ECwME9W2lFKC85dtP+A9iHITIbETYUB iIXKIMDbB/RgZLky+BdTKs8aBqBmWS4GrXTG4Tln91k6dVOoVqazBPRlZDkBUJPOUqRtmMpAogE/ 3noBf14dQOoCBFl/8OMNg/7jv4xE43i/Xo5BjrFY98+Jwwoa0cBEQPIbGsnbu2NwHPIbrqThCLcv 36+Vy6ujh3LynOmvazvHvUsH+UHYIfDDV1hhhZN32mmnYO+9997gmGOOeeKuu+7iQY+rSq22iC+X /X7RAiDCiodrClIXdAxXDJ+OdkDUCWGbLZQfAemEAdlbDGTMH7b8+BdTovTCYBefZbMuFwNYCuPY fZZCpTRQJdNZMjozspwMrrPKdYJzlSh/yY0osQAxb0ROZUkyY8KEvxao6Nq1a3DDDTesvcsuu6x9 0UUXHfvGG29g5X5R7cm7goU69BpHqMtSUSukaQg4C/8c0tnPTcvJUieFgHQ0j/Ie5wazSRVj+SaI gLvP5pQOU7UOf4JNznzWprNkVGhkORlcZ5Ury7mx7JmtqBA/9qxiURc6dOgQbLfddsiad955Z78n nnjiHWHPqhu5YU4dWE/ncq3lPh4TAbHIW0gPAiwPeIJ0dniWBp/pga8sNfmvSsHdqe7NTFlKtULi RGAhZXaS7rPD7D6LE9ZE8zKdJQCvkeUEQG0gS1Z8eF2C24GFeBHI+4GKDz/8MPjkk0+++Pjjjxd/ 8MEHz1lqqaUKlbpa7onrrrsuuOmmmz5RZzHCXvfHq6wm5oavMr7snaWbMaabJqKZXPIuuGFIP/a8 Sw7jJHPGqMM8DfTIB6dsjkCSaMeTt+ksHhzr5WJkOQFQG8jyfT1wWJfYQswI6GE+dcaMv5/l7F9z zTVjjz76aFwwWD7v0B49ely25JKsIldcWGghBunh2s82Sak4yMoVixnfTM605fvKhXjp5TCYoY8x HZWOXVpS+Pss98NXaamf1WNmBExnCVwVRpYTALWBLGcTqWttr7QSAb59t27dgunTpwdyuQjkq/za W2+9da6w5kMjTDTqOHFidKnlhuswZQrz+WzFhYaRKnsMlvJjApkRsbJDX3SBTIBlFRzTUdGQpS4i D8xwoqaFzCBgOktAVUaWEwDVsqwYAu1wm3jooYfeko/ydSLJd2+11VYVq4wVnBwC0u0IDX4uVgms YGKvhpODuik536DErGNuZLkpKFYwLRP77D6roAIaUbTprBGgFZHEyHIRIFmUzCAw+plnntlLteVT 16WZkDPTRKuoR0A65sMyiIUUIuAGMayJbiHDCNh9lj3lmc7i15mR5fgxtRwrhIAeEHw8xUIzQMAt S7aNdH5bM2huJpsoHe2uin8iHdVbxz2TjWmmlbb7LHuKN50lozMjy8ngarkaAoZAsgjwefIt1DHw qfffzRUjWbAbmfs6SvendPSZ6aeRCFY+GZOb7T6rvB5KqYHprBS0ioxrZLlIoCyaIWAIpAoBliLD BYMVMZjsZyF9CPBlTVaRsZVk0qebYmvk77P2dp8VC1nF45nOElCBkeUEQLUsDQFDIHEEWB6J9V9t cl/iUDe6gDZKaUuONRq+VCRkcqbdZ6lQRdGVMJ0VDVXxEY0sF4+VxTQEDIH0IMAXFXsbWU6PQvLU 5FYdmyYxy3Kq1TTLyvGZa7vPsqU/01kC+jKynAColqUhYAgki4Bb7YTPl7cxf9hksW5s7n5in3Rk 1uXGgljhdNIhrjR2n1VYD6UUbzorBa3i4xpZLh4ri2kIGAIpQUAEjK/Dzcl6yympklUjBwHpaF4d GmfLOGb30pAOccHoZvdZdnRoOktGV0aWk8HVcjUEDIFkEeA75CeqYzhc22lmXU4W7Ebm/l+le1ny TCPTW7LKI8B9drLus8PsPqu8MoqsgemsSKBKiWZkuRS0LK4hYAikBQEm9mH1YpmkMWmplNWjHgLo qLOIVisNZpihbyF7CExXlZmo2VkyOnvVb5Y1Np0loHYjywmAalkaAoZA4gjgB8uycfYp5cShbnQB uMrQx5iOGg1hxRP6+8z8ziuuiqIrYDorGqriIxpZLh4ri2kIGALpQYC1lT82IpYeheSpyec6Nsp0 lGodNVQ5f581FM/OpwcB01kCujCynAColqUhYAgkiwATjvR6/xKV0tb8lZPFurG5Sy83Ske4yZhl ubEgVjiddPiz3WcVVkKJxZvOSgSsyOhGlosEyqIZAoZAuhBQpzBFNUIspBQB6Wh8Sqtm1SoSAbvP igQqRdFMZ/Erw8hy/JhajoaAIZAwAm5Zsm3VKdyScFGWfSMRkI72VNKPpaNPG5mFJaswAtLhPKrC 9tLhzRWuihVfJAKmsyKBKjGakeUSAbPohoAhkAoEmJ2/mTqG+7X93VwxUqGT3EqspQNTpaPBpp9U 6qeYSuFGs6m7zyaYHouBrOJxTGcJqMDIcgKgWpaGgCGQOAIsRTZZwooYTGixkD4E+Pobn7q2z12n TzfF1ih6n00oNpHFqygCprME4DeynAColmV6EZgxg6Vfiw9t2rDEaPCnLCrTik9lMcuAAJPGUE5p Ci1DxayIOgToX2zJsWxfEHafZU9/prMEdGZkOQFQk85Sr8Q6qIxVJN+JxP2YW57Oz61ji0m8ft9X vEl54pHPbDqX6cXm1d45HHFiMlE7tafgRyratm0bDB8+PJhzzjmDP/74I+jcuXMwevTooGvXroEj xnUwTZ48Ofjll19Y4H1OlbGg8h2eB0N8+kZFP7qguBCEuXTsl1ldC4q3LHm79F/ofzft86Cb6EgG +zPyTZJSXCyqy0nQIUQeHRdF6JWWMikbyx9lkNdQV9ZM19Os2hDHOXe9jlH9pxbKT3EW0bmRkvYS LFzU8zKJfewiDiUkkwf+5OjHLMvJ4FuOXH9SIVdIeA5ayAYCprME9GRkOQFQk8zSEcNDVAY+m4H+ 3ymS8UVOmSfqPwSSm4awpuLdqni12vKhAD4PTCe2mWRVsilUZ//1LW1b5yNjOh6aXqNEJ/eLXaSl w1QcXpuHAUKp/+EDmDpFz0Xr4uPlxslpx7xKA4laWLKg5OpC7WnXrl3w7bffBq1btw4uvfTS4OCD Dw5uu+224LDDDgsWWGCBeoT5iy++CK699lpwglzyCdGQLKtslivzqzD8T4dOl4yMtBvsz9f/g/Dx y9c+HVtXcXaUgEkH/X9UW9akBStIMPlDYrGc3punPRvq2AmSdyQMhFhzOC9ZRkc5RBSCv7UE3VM+ E7Cek9DWkCxH0+S0dyZ90W7qXUiHeeqem8cpinO18vkhgmtunKVcO2nzPYr3gbYDlaaD+VHmQ7jy x6QX1lkO7/XK18Zq0BgEpEMG1O+554G9xWkMiGVOYzpLBnAjy8ngmmSuEKOHdEN8owfYMdqHdOWS ZR5qJyvOz66zulPbLoo/v7a9JOO1f7G2EKYe2h+sbQvFf0D7EO3bJftKINaf6dhK2rbVFrIIOQ+X g9L/JV1+bbR/pfax6JL/NP3HqnqTZD7JseSlY721HSGBHE3W/7HafiTZXfv3aDsAAq39jtqHgELk mCD0urb7aNtP22cltHkPyVgdu1TbTpK5JJC9cE1XHYdc/Uv5XaT9A7T/tmTcSSedFOyyyy5BbW1t 8NxzzwXzzz9/0KJFi+CGG24Ixo4dG5xwwgnBoosuShaBc9mA0NdIOiqflamrhLa8qu0TrrzR+r+V q8fD2m7h6rg2RFP7e2n7rbY3qT6/hZkHwa6SB/T/TZ1bRvtMhsKiTFm+HbSfgU4nxbtJ20P1/zPt v6ZtF8m92r/V5UebT9b+tRL0vL6kv+Qwzuvcl9rcr/hMhvtM+6fo2IHa1up/X1eHlbVdQscYjLXQ PgQc0r6lu16+035PycbumuE6AfvjJXzWGBL7iiuPQQTXGIO6PXT8MqeHYfrPNbGe0+uD2ud6pcwu rhyukd0k4DdEWyyUDEDWpi4SBibjtL1K8jXXlfIHXwspQkB64TocyzWXompZVUpAQDqkD+At2Uxv 1UrIxqKWEQHTWTJgG1lOBtfEctVDC0IFUYY80BlBWHIDlhwsmxBW9t+T4GoBAT1fsqLkCMkdEkhU rWQ1lwlkCYIHeesnwep4kqSnBOK1uuQlFxey/oAEayR1gdxtIvmXZH+XB6/Mb5BAOol/mgSLNqQT 4rOfBKKENfhdCfEhvMSBHEJ6j5NAji+X0BauW6zhG0j2kWBl7C75WuKtHxBxLLYMCHiFD+nrtMEG GwQff/xxsNtuuwXbbrttsMMOOwTnnXdesNZaawXrrrtu0Lt37+DKK+H9qoRItALWWog4VmvyxhpL +yCCWHVrJftRlsQvr/S8q9v32p4lAev/SHaQ3BZmrkGHZFfVb1tth0mvfMBhL+1jTfYWZiy2kEuI +jbagvGLLj3t+4+OL64tg6cPtQUrLP3Mhqa+WNvXk2wvYRC0goQ6+8B5byHH2kx6iPQ6ku0kF0qG SsAaQtxbsrnkVAnXBFisKWEg8obkH5G8Ida0DeK/oBtMdHXnucbI02NIPSC7kGKuMQYAEGPikCeY 4HbEgIoBCitgcL3QTizyDBIOjpRtu+lAgEEyz4pn0lEdq0UjEOBNHQNrnl+8kTTrciNALHMS01kC gBtZTgDUMmWJdXWkHl65VmWKh5hifcQNA/JxHdZgPfBwJ8Cqy3kIHSG03ko8acJqzHUxVAIRhlg/ rfR8MS33S1xn6xzECYJ2kaRG8rji/uDiQvYgjHSaEBtIEXm/pDhDHAG8D8uT9qM+cZCjt3Wc1+yU /6D2J2ifBzX1/NWVi2/2m67+tKGufor/i+KP1DFIHwMFCFrLffbZJ7jmmmuCVq1ahS4XbLt16xaS 559++ilo2XKmN8bkCeEjf+pOfcGSunAMF5A1JFfoOK8sCRBs6sn56TqOFd37B7sowQ/a6cd50uv8 ntpCkiGtvh0MWrD6Q/YhvD8qLwYEBM7xmvtpjrtjvkysrugVvJ9QmlHKnyiz6uhoI+mxJPVTmjFK w7Vwn8uL81gIsa4z6MKyzZuL6yQQcUj09a4ebLBqMzBiwEYbIfsQ6JclDB6wONNOdFQrgSgzKKHO tPEpV84gbSHiXgdgStsYNELW95YMjJRru+lBAL3zxgEXLPMtT49eSqkJOuS5x/3Kc9RC+hEwnSWg IyPLCYDamCzVoUCSIBwQFayreYPiweYgThtLeLWNDiFOrNgAiSBANj/Q/4+cBXpHbTGXQm54dQ0h wdUBayivxCFdLRUH6/I/JVgUeb0OwYXQYMX2+UKAfYAk3ijBYni05DLJdsoHax/pcMs4SII1FAso xDWaH/X21kbqFCXjNa4Qbyn15UPmIFvnSc5x9QQDjhOXrQ8DtAOhgniR36UTJkwIJk2aFEyfPj0Y P358MGrUqGDixInBuHHjgmnTpoXnfPjzz7B/h2B6jNl6LKgvZUEwd5JcqHa/x6DCtQPiB8a4lUCo Pbn02WOpAXfcSvD7IN9aCZjQDnBmy3XBgACsIaA+kPf3Kg8XFR8gklifD5dA2Km7x5drIvd+p/6U R+Accbi+fBu5PugkaSPt5T9W5HMl4MoAYCXJYxIs3QzEeKNAgLAzWOMaAH/eHkCUud5ekPSWYMFG 5wwGTpBgNYaQ10ioD+VAxJeX0BYw4ZoEW0+0sUL7NrqibZMSBPw9mTvITkn1rBpFIMDzwD8Xiohu UVKAgOksASUYWU4A1FKydESqp9LwOht/17/ZWv6MeHBBzhg98voZ0rikBKvkJy4Jr+SxvBEgMrze h/xCgiE0EBL2IUKQ2N6SZSQQZdwEIFq4NkCSIDuDXF74sGIJ9AGrNi4SEBlMl90kWEJ3lgyXUJ+v JFigsTD3k0Do33cZfKmtt1bggkG5BMrlPwFrJKSRQDpI2KUSyBV1HCKh7VgjsThHrcuDhe9HIpT4 BUOwOk+ZMiVYfvnlw9UvunfvHgwYMCBYffXVgw4d4IEym66M4fSvUFNTEyyxxBKtv/76awYZwyTU 1d8z1AWMsWqC500SdMhAwVt2eR2Gawb+u7g3PFKXeRAweMG1gQESBJs29ZB4qykPPIhsC2eFhyRG LahYpj1ePlvygFyCCXjXSvw1MUj7v0XKZ5d4/joBO+pIGz918biOIMGQYvJBp1iy0Sf/B0i4XtEF 9bvA568640+Oy8cf2n9H+7hVfCSBQGHlJ49XXfmQZwYTB7rjWLS5XomDVZnrDhcSrsWhEq7TIyVg zmCMQZOF9CHAs4DnxUyva9JXVatRAQR4tg0ydDKFgOksAXUZWU4A1AayhPyEJEcEAj9MrMS/6pi3 yM0yueJBbvDTjQZITF1QHKxtYcDFQRtIBQESd2gkKh0Zr/8J0Vfo/MdiTIC4hK/+lRd+tnVB/7/R H6yYYVB7IIfDdDx85+8CxPfYaDrt8+qe/Pr549qHPIZB+9QTCzj7ECl/HD9VAiQP63I0eIJX76DP V9tfVb+rZEG+aI899gjjHHPMMfXispzcIYdgAP0rLLbYYsF+++3X7rTTTsNi7K26EHTqda2L5nHD lxrhHCbp/SKZ/52pOwiZ1C7uDNEQtRLXHVe9N9MfSGOdq4rS879e0LGhOoDbTTTgC0yd6q4Jf1LH sOSGQfsQG4QAvhyD6PsQ6kwBKzHiA9cXpH+moPR1vqra7+0iQLy5jqLXEgO03HCXDiA+9HE7ddeJ cGHQyCocXGMWUoYA1490xKDH/FxTpptiqyMd/iwdMghnxSLTY7HAVTCe6SwZ8I0sJ4PrrHIdp4cP r5+RhSXn6uKOWmvLX6OYSlQ7BqlteUlrTEU0NZtWLB1XSnCuGK1xd1H7ci25pWTVlLhYeF+0zqo+ hMKDwYMR5aZcWQmnlY4KupQlXLRlHxMC0iHuXYiFjCBgOotfUUaW48e0oRx3UwReJ2MNvlxSIyI2 CWuqtrgb4FLhXQl4hR1aBnUOX0/vS8oh/FWZaMaretL4MFHHcV0gDf6rUX/OYXReOu5fhfs0LCc2 1KXBOswrcR+G6hwT8HD/wGXDhwk6jmsC5SykDS4dWB7+1H/Wy52YJ814Hcc9IJrG58cHVkiDb+xi kXLG6TguB6RhcMHrfh++1bk/dBwfCvx+fYimwR8W6xZhcSbxzTFHFMZIqjy7LCenUNH7RG3MdZ+Y daWbwVnnvrS9sPFvTZpBq7PVROmIyZcfSUfeFShbDbDa8sxlvsUO0qF/02iopBwB01kyCqooCUim SanPFTIIyYSw8nqe/3dIBkkggvhtMpGJALGEUBPWk7AChg+3aAcrLiQVv01PsCHK/lX1BtpfK5KG Bx6TymokB0eO42Zxjfu/sbZM3vKB1++8lod0R9Pgb+xdEDbVfo9IGtwlcNHAhzmaBp9YT2620P4/ Iml6a3+oZO6cNHS03oVgK+0vF0nDhEKINA/0aDmD9L+Pi7e1tku7/ek77rhjP62AAbn2rxSnaz3l TrIgd9eHSnBDqDcZicl/WiHjV00ItElKEeBTsMt1z3rP92rLYM9eEadAKTlVYFIqK8EMdm8B0ldD q1FDCGBo8PcZBhK7zxpCrPLnTWcJ6MDIcgKgNpAlk+LCJcUkt+vhwwS4MGifyVVMmJsp6NxDOojU CzrO5LZcn2CfH+vRIrlpWM6rV4Fycn1FfV6sbFAoTZ8CeWE9L5RmJh9ahwEDiUJp8loRnfW9UJp6 vtjOcu2t4BSJLpaSsJrHKRImrEU7BEgyurJOIp+SK3cMv3BcMHjjgd+0hfQhgH86A38m+NX526ev mlajWSDAfcakY+4zc6nJxqViOktAT0aWEwC1gSxZIYBJaz0kx4u8MXHsERE+W4e0DLrAbUPFIHVB OmDAQcBNxK/OUYbaWBFNQIBBDM8vG8Q0AcSEk3qinHAxln2CCNh9liC4CWVtOksAWCPLCYDaQJa8 IpkiUsZ6tW+LqOF2ca22vXSsoWXjyl/b5lHij2omLh0WsoOA15mR5fTqjDdBfn3sSk2OTS862agZ y1rybLQ3A9nQF7U0nSWgKyPLCYBaRJZ1ryVFkG8VUX5AafwHRYpIblHiRMANUj5wEyzjzNrySggB 94Yg1Jn5USYEchOzlV7CJQilI1tnuYlYVip55NnIakA2MK2UIkoo13RWAlglRDWyXAJYSUXVxW2+ YEmBW0S+btWOuf1KHUUksSgVRsB0VmEFFFG8dMTKOrX2fCsCrJRGcSsnzWPPxpQqKE+1TGfJ6MrI cjK4Wq7ZQoBO/WQ9ZA5Vp2Cvi7OhO68zPhs+zaxeqVRaL9XqJQlffbSQTQS4z07l2Wj3WWYUaDpL QFVGlhMA1bLMHAK8XuRe6KxOYYwRr0zoz+uM5RZZt9xC+hBg0vLsuqda2QTm9CmnyBrhq8xETVYQ ssnPRYJW4WimswQUYGQ5AVAty8whgE8l613bWsrZUZ3pLP26YrkxPrRk91X6dVWohv4+M7/z7OjQ dJaArowsJwCqZZk5BPAZf9869UzpzXSWfnV9pCqyprsRrfTrqlAN/X2W3RY0v5qbzhLQuZHlBEC1 LLOFgF4R/6RXxXwpcTZzwciG7kxn6deTdHSb7quOqqmtopB+deWtoXT4iz0bs6U801ky+jKynAyu lmvGEHAT+2xVkgzpzXSWfmVJR/Z1xfSraZY1tPssewo0ncWvMyPL8WNqOWYMAVlO5lOVe+oBU+/T 2BlrRrOqruks/eqWjv6tWg7SffVx+mtrNcyHgHQ4r47/y56N2bk+TGfJ6MrIcjK4Wq7ZQoCvKm6g h8xdtiZsZhTndXa3ajzB3GdSqbdVVas/dF99Kv3YF+BSqaIGK8V9tqF0aPdZg1ClJoLpLAFVGFlO AFTLMnMI0JFPkcymTuF3I16Z0J/XWTvIciZq3PwqOUlNZtmxui+WNj8IMt9ilv/j67KsbGL3WTbU aTpLQE9GlhMA1bJsHAKsx6qUh0jmkFyZa+XVedbUZXF8HtyEEUwialxp9VLhV0nZQS5RVplr6PBQ HR/Jeffp3qO1y+j9Ax1/WsdW1/6PkgUkP0gWlXzj00RLUtyV9H9rV94vinNzsfVX2vUUdyMJH06B gEyUvMlW+XxabD5xxHM4bKFyn40jv0J5qJy1dW5FlXNjThyvs+kNDW6UB2vEYuUcKFlF8Qfklqc4 Gzidoce6oOOb6M+7hd446PwiOr+n0yfpPlbcx0vBRHmsrPi/SeaUjFP6b0pJn+K43FO2bFyKFVRE 1dBf+Gy0kBkETGcJqMrIcgKgWpaNRmBbpZwq+UxysuTUnJwW0//NJFe448u5r+7dqO1COra05B2R jfGc17GNtPlEwmz8PyRddO5n5+86VvsTHQFlxv55ksn631VbiBXk81dXh2e0vcGVeYK2EOfPJVso PoeJB3ntKXlC8k/JQJ17XWX8pi0kepT2sdBAlBkM9Jf87gYI8+vcD9qv0TEedJBhtj0kEDUsdISf JR9IjpC8JqFtWFhbOEJInJAM6j/Ea2ntQ6bBgq86LSN5T8fGumMbaTtV/99w/ylzQVcXCGY77f9K Wm2Ha7ukjkEOX5FgvdhVx77XtpPOv+uwo+4MCD6K6GFT/cdV4h1XzsLadpNACikfPUBWZ2ifdoVB x3bVZh/Jg9rvou0cOv+d9telTMk5kvYONwYov7p6bqrtiz4fVxb+s2DXSvEZbGGRXlyCXmjDLpKH JD/STh37yqUP1wnWMXTWQQIWb0fypi7geq87NkJxiUc68v9Z8TlWVyfts6Y36RiEfa1tWwnXz3YS rrtqIcv+noFs2ZcxIxdNhnZHqK6XSrjfLWQDAdNZAnoyspwAqJZloxF4WuRhqsgERKNnnlwgFJ8r znOcUzwe4OtqC1GCDEGSV9b/W7SFVPeQ8DlkiM+Dkj0kp0iOldzrCCXWWvLhXoD0HikZJ1lNgoUw JEiRulDWE6rDYKXni1YI5Bgixj6kgLVlN3bprtUW0t9bMkSCuwcE2LcBa/nZkgMkW0kgcZBxSDmf Cl5N5dyk+JBNiNXX+r+mts/q/yDt7659CDP1Okbygo5hDSVAJCHAwyX7SniNuorDZwvtLyWBCHZV Xk9qH9Lm6wLB5fxF5Ks472oLWYa4Qw6xiEMgD5agM8qBwDJ6oG3r6RgTJmkTpLGtI6m0gbcHDBw4 t6eOL6stFnx0Oqfq0o99BSyu4MHD/ynqovPUiboxAHpZwqCFcwxo2ug810hLd03cqryIh375yl+N BFL+peQBlwbXG+o5SsLAYBtt55d4soxuWYObOOgVYt8xQsbB/kOvTyqt8wzaeOPBZ55pN3WCpDOg 6ytB1xDI9XXsfm3/IeE64/rh+qiK4K5X/zamKtrU3BohHXK/85xp7e6l5gZB5tprOktGZUaWk8HV cm0EAhBll+x4bbHy5QbI3kZ6cEPUIE3Msj9Dso6ku+RWCWQPIgShwgIL+VlLApnz671CnugEdpBA Atn/l8uvRlusvpAWLHwQVv77APE9XXWA3AyW3CTBMh19VQlpfFiypuJBeiF0Q10GkMRDdRyyimX0 p0je3noDaYVQn6N4kC4IddRfkPOUT2CfdJC2t5TmQqV5VPv/del6avuCZAlX17Nc3bAQUy8IoCeG tPkZpT9RW0h/O1f/QS4vrNXkTb3vk2CtP1cCeV5fAqlk9YPzlA63CeJj2ca1YQUJbQbrSYpzruJw DJ2gB4gvzyNcGvpJCI+4tLgofKk0TygN1kp0DB4Qed5C/OTy420EeV+heExIArvoGr9cA5DvkIC7 NOiTwRDWdoj+QB2/xJXPhrjUCzw4zpsHBmbeck09dlN5y7s0WN3fcvmDA3n+pjyv0u5d2qde6IOB xs4SrmPypoyqWo9Y7eUaG622h296LGQPATfAnU86/C57tW+eNTadJaN3I8vJ4Gq5NhIBZzmEPEQJ qs8NEgoZgQhuJFlPD/Exf/GRYB7JihKsef6rYRBYXrGvImEfQkmA3LIPOYGsQOC8ZflO7UOuWTIJ C2/u18c21LFTVC4uFFiosWBjtYwSHZ8XZeA6gmuItxhCviDYD+vYdOWBu4O/D2kfxBdSBxEnMIDw 9XaH6m0oF4mmof1DJVhR8e0Fz7kl4IPVF3eOqyWQPogu56jPDNWHNtNGCC7pcJnAEgsphFSSB9ZR CBC+0riZUH/qCMY/RGpHevKCNJOOOhGPuhKoB2QfbLAuY1mFhPvAgADBbYE6+OB1Qjrq/q07QT0+ dPsQ+XwBrHhz4V0d2AdjrglwwxqPuwd1IRCf8kJ3DZ1Dn9G1gxnI3KFz3uUASyo+7FjQCbT1Qx0j D9LRHgZw1G85CdcrBLyqiLJr+9HaMtjE8m8hmwhwz5+m65c3SNPMupwJJZrOElCTkeUEQLUsG4eA Hsj4CkPisMCtqv/vacvkLiyWBK7X9pBMOmGd385ZJyGr+MNiIe0ugfh8IdlbsrlkmATyw2v6fbXF wkk5ECuIEqQOFwPSbiTBFxi3BogQBBZCTF0IvGJfWPngGgBRw8eWY5AuSF1YRwmWQ4gfVlCssT6E cVwbOEbZ+CvjTkGHBJGGQHZxCSg/l7BDuPy9C/n2BJu4BAi4t4iSD4MB/GzBh3ZRBzCAGNP+7pH6 YWnfUUJ7wfB8CQMXiDd4kQcPY0jgMqr3/7SFSBOXvHbRMQhzrQRCSHkfSRiw1Ei8HvbSPm4W1IO2 4yJDO3wbqJLHFBLu8fhU+7wF8HFpK2STMFskfTQf8OOaYAt2bKkLASzAm21vVx9cL+5x5326zmoX 8cDdW/WJAsndWOe4BgmQZHDw+RPX14W8yIOBGG4ju0m8pZu2Un/OV0vg2u4kbFrpejef12xq1T9b uM/8ADKbLWk+tTadJaBrI8sJgGpZNhoBCAMkBTIzlwRCxkPaByyIvFr34QLtLKaO+E1nXcbvFV/e 0fp/pfbxV8bveDUdG6Zjj2gfdwTI2Rgd66Nj+I/yCh1yixWaV+S4cDyk85/o/BOU4QvUsfN17CD9 n0/yHERe/yFHWElHSXCreFiCZRaSxGoN0dfQj+lYnUuFzuEDe7mr0+Ha4g7AYADiRLhOUuvLd1sG E9SVMEACYSONv59JQ52wTte6dlCXNSXPO2swWBwi+UP/L/X5a591ccmf1650jjdiRdcW9wzKACuw YTLkUdqHxDLp7XH9hwCDN4MM0uEDfKH2D5Vc5eo0VFtcJ/DfhTB2OfLII+fu2LHji1ddddXEP/74 gzcEPkCMIfRgG2KmPK9xOkOP6IyBEO43hIck6ICAr7i31v6qfa4b8qJt6OZ2Fw+fYcg9OsMvnMmi G9XVQO3QPkSYQQzkjzpFScOrrh5cDwTKYuAWzZ/6UxcwGeX0va3+Hymhvgw0wHgodYiUnfVdrmHu af8mIevtaY7151nMQDJ3wN4cschKm01nCWjKyHICoFqWjUNARALrJxINvMYNAyRPG8T/h/wgnMM3 FvHnGF1fK2KyiLahtU5xsJoidUHHblMcOvUjJEzcwqqM+Hzq5evyuSUnDyynBF7jE0LCpnw30QaS GC2vLu9IGbQJcjdTUH3eyD0YsbTTJv+6P1rG6+4PJA0hHn60SBggu9pgXc9Xprfkc66ufKXBhQPx eXyQkxjiCjmve+2ufUj7NT6eMMEqzRsEiCcDkxmbbrpp0LNnz+Dggw9u36tXr7sU53qlg9TX1V/x Qj27unudQTbxiQ1dKrQdFInjMeA4BBQCS/BtC//rnHfb8CSbYwMi+fhrym+jdSIubxgYnOSG8DrT +ShGYZ10DLIOCc8N5FVNAX2AlxGt7GqVe6feMzO7TWk2NTedJaBqI8sJgNpAllivIAoWyoCAsIbA 3TGrohQHN4XL4q6O8n0g7jzTnJ/aW0dQC9VTcYbr3P/58yLG69TW1oZ/F1988Ra33HJLz0cffbTn JZdc0vfbb7+9WIdZ6m4mf16nszqLeJpxaa51k45ul35xPalGf+xmoVbp8Bfp8Ao1Fvc302MGtG46 S0ZJRpaTwXVWue6khw+v9XmlbSEdCKALLK28brRQXgSWbdHi77f088wzT/Cf//wnOPDAA3e6+uqr d3rjjTce1f2C60qp4Sl1GnXW4lITW/x4EJAOopMh48nUcikrAtIhb+mqyT2orPhVojDTWfyoG1mO H9OGcuShgw+kTXhpCKnynZ9fRe0tqXMXKF/Rzb6kvJ3w6NGjg4kTJ46WdXmba6+99l+LLVbnNt4g YHfeeWdw3333baeITzYY2SIkhoAGOfsrc75y6d2UEivLMk4GAekQX/ydpcO8LlvJlGq5NgUB01lT 0Cuc1shyMrjOKld8MZkEZSElCOjhwmTCRaUXvwJCSmpW/dUQ9sNmzJhR55ZBi++///5psi7fMnbs 2HP1d59//vOfFyy6KItqFBc++CB0E65R3qw6Yi5PxcGWRKweynSC9PCJ9GBv0pJAOPk8caNZRzrs gy7NFSN5wGMowXQWA4i5WRhZTgDUBrLsaJ14+UFvoERW3GCJq27a8gEJ880rn4o6zTEHi1po5t37 7wcXXHDB188+++y5J554Yuhnzr0ybty4kmozaRIu6OYnWxJoyURGEfQxTPAzspwMxknnyhtQJuky CdpcMZJGO578TWfx4FgvFyPLCYBqWWYOAZxmbcZ+ZdTWum/fvsFrr7329aWXXtpHVbhUgxX8x32w ZccS0osGIizrxooiLCt4mXCfGC3KrVzCGxfWEmfgsrg2c+l/7oo1nNtK517L8VHGX7nQx2EKtkp5 sSyg13uHYt04lI4lH/kAUEFSx+BLcfjaJKu8rK+4/kuMCaFcerZuFZ033STWvBkoDiv8rCdhlRZW l/lYspbSsMJMvaC4m+nA2g7TTxXnER1bDd1on+UlGwpcF40iyipnLaVllRcMEaxcM7Shwvx5l3ao 0oQr+rh28IVQv9rQljr8smRnCdeMD0xI5BmyieI+W2x5VRTP+rMElGlkOQFQLcvMIcAKDay8YNav 8qtusnyMccO4Vx1btS2dVn40SytxB0VnXWjWmT5JckZOckz+L4ukLCPdsEQhxIMVXt52hBby/Loj yP/W/ns6zlcV59cxVqFhub8Zua4wisNa3Swh+JLOTdX/RYivbfiGR7KfBEsmn2PnQ0LUAxIcknn9 hyTxBog1zvkgDR+tYW1vXG74YBBreEPSJyvOO/rPB3Eg+Sx72ENyloQ12MM3SK5cyCSfVB+q/3xs iLxW0f/+xHHxqBP166zj3yreCtpfQNJf//90RHwj/ffLE5J/G8idzi2s/eHa56ud1B/iGH7oiPZr s4yE1WQYwKAHXJD66xw+w78r7rgITqxt7uu4sfaPllwk2VxxWAOcvFkn3QfIJGubI+sqDmu5LyWB UA6O4qN9/J2+d+1ZStshOgah3lz7de6DDjMIexcd/0b/Ie6smBGSdacz9Mxx0kN4aTu6JB3YQHoh 8t9RjksHiWcpTdaRP1lCfn4uye7a53r1E3f30T7+8DtJWD8dQo9+TnRpmIfSHMkyS1PSn9m8KC6q mIKR5ZiAtGyyi4Ae1Lwu/pjOTvvmglFGVbrOdSZrWBmr0JyL6geRdeSSNcFzAxaqgZI1HKFjMPOj 9pfUdk9JrWQF/eejMBAY7iM+QAPB2lBb0q8EgVM53jrNh3H4QiKTnJfUOdxtTpccJNlAsqyErxpC BiFCEKQBklUUlw/D7CqBaOM2BelCWEIQYgXhxcIKiYWkQeKow+aS8dqHWGPtJn+I/lo6hoM7a6xD uDfSf9a/5suKpIeMd1fdb9E+gfSszHK7jlMOlmyI52L6D1nb18WBrNEuPkbE5OHrJbTxZMXbWts5 JV1c/VmbnYmQDCwgsBBm2jSvK/NAbcGBjyOdKTlAAkEGXwb5kEcGCpDslV19OoCrJ6CuHrwNgMTz tVHKp25ggj54KzBW+8zdQC+Qbggrn37HYosPLCS7pfLs5+r1D21ZQ/4cF2cN7TNgqNGWAcZhEowP 5M39vY6ED/jsJyHuWZKeEgYg+EQzCGM1IrBHRw+6cx4HioUMR+cg0Ab0C4avqm58jIq6bu+Oc77Z BeHAIMj6s5g1b2Q5ZkAtu+whoAcsD2msYeHHLSwYAs0BAUeUIaenSfg0e27gU90QHchxDwmuCxAg SPPzEgjaCZI7JQwy+0juUb7P657i64wQRIgLpDIkywpfSrwfM2nvl3gCRN44qEPsIG74yg5Ufucp PwgrpHA9/d9f/yGzuFPghvA2gy4dw1JO/H7ax1IOafvK1ROCzBcysYCTjg/0YNXE0rmA0hyuNMdr H3JIuY/r2M2OBHuyTHux2jE4gGCT5yAJ7eTrkXwplLoxaCAumPjBN3lCyMGDDxDhnsCg4VEJhI98 +KDPR0pP3bCCExggHKFjWJ8htEdpi2WZOkCcIeUQ/09derBi4IBeQ2utKxcCz4DmW5dmP22pE/qA nFPfYyQMTnpJsAqfJcGl4UoJOj9H0s/lSZqPHda0Z5AE4r6H5B3JvDp3lOrCYAGc0DkCBn0kDADO l5wn2UuynAQSP0DyigTc+CAV/33I9X0HN95kQKgvVlm4ekCWj5RAGJulC5dwYADCNW39WeTiaequ keWmImjpqwEBLFWn6iFzsB4wdCAWDIGqR0DX++y63j/XFmswr7qfzGk0hIWBpJ9hCRHh/uguwVrL ccgm5BCr6xeSRZzFFDeISySQMyyrPqykHcgqaXhlTn4QLwJuGBAiymELsSJPAvGoj3eVggixTx/m SSHH+Aw7Ft631DYsw9tof0WXlriU5ecneDLr8/T/Ie9fYEnVNupzDaHERWGKO4eLBNZgCD/xPDmD WBIXoZ0E2kS+1AHLN9gx+BgkYRBAPvMqX6zFdfMnVNZIR34oC8sq5BMscGuIYkW7vOsF5UIifeB1 /CXKi0FIGJQn9aDO6AOrLxi0Uxw+d48P9IfaH6P9xbSPiwfXSNRNjfSejFEP3DdoPxZiznkssJij Rz9ogMQygCEOJJp24x6C1bsncVUuK6iQBsyigXYwgPOBOLQVLI6TzCOB8GMVb85vCOnPTqc/03aq 8GzOWORcQo3/a2S58dhZyupBgE6Ah/vsesCMsYdL9SjWWjJLBLbU9b6AYkDoPtU+RGR5Xf/vuVQQ MMgNlkIsuVj8IDee1EKESAPpId5ZEqyPvGbHMrqRywdS4wMWY0gPr/s9WcZdAv9TXA76Srgfsfp+ KPF9FHEhm18pLr6o3SWfSCBUWFoJkDaIKD68Nyoex7E2QjLJx/s199A+LgsQLV75T1RcrJu4ftAm yCPlEaKEjfx9WRBT/v8gwbJJ/vg7Uzfa0UcC8d1ax47VFgIKgYUgD5VgRaU9kNEeEgYFWIPBHLKD m8XDrg6k2UhytuR/kn4SCBB1JE9cKYiDRZHAlrb5ALn+p+qxrbbMDYCc+sEI+ECaya+14tD2oRL8 rBkQ8WYB1wjaheuJD7TXY4ErCwGdkg/5QXhJQ1reQlAn0nC9UG+uCdwywA+rOcfBAJcfrNqQbq6r LSRcf4SrJXvp/DLadpdwrWDNph4QffCnbdtJ+klyybbLpuo33leZ6x0fdgsxIGBkOQYQLYvMI0DH gQWtWb62y7z2rAGNQkDk4mGRi/2UuJP2L9U+JCZquYO8QIAgfZASiOQPios/JB0xxA63hokS76qA Nbm7pI8EAow1811fQVfmDvoPoTrIbXu7fHAxgLxidYXEQ5a93+l1ri64BRwiYTLeY6oHRMtbVG/Q PiSRLUSrRnFuUxxcC7D2viiBOFO3sM7OcovlGyKJD/cnzqqJHyzED4u7D1gwQyu54rGiBKQMF5X7 9R8XCdwVIIe4ZMyjY3foGKSYfCDjDEqIg5X2V53HhQQrL1ZVyPvVOvaT/lO/qBUXDJkcSBm4vGCt BydcNNAJLjSQIq8DiCYuFz5wfqWjjjrqrvnmm++Qyy67jPO3S5hYh/UYfH6SMMCBPJ+p47/rOG8A aH9PyTgdQwc+DHJpwAJ3Faz5DBpu1n+s+7iJrCshb7BEj2zxRf7ZWY/Je1cJuoTkfuauq1H6zwRK yDD4hsEdw+2E6wfXG/QJfuSDPn1dqDeDN9xDmmOw/iwBrRtZTgBUyzJzCPAgp0Myspw51VmFm4KA CEefCBmBSGI99uQEIoYQIM2EkIQpHdbCaPDWP+KFcUVirtIGol3PLQCSm5MW4hd11eA0ZK4uKA1+ vASssVgYw6DjwyL7+MESIJ/RtLhJRMPdOech29E8B0XO+3Ipi+eEbyf/n8jJh3bfoHZj6cWCTpyn c8rmb11ZLs7r2iJhUJqncvKt04PODYyc84OQXKw8Dj4/BgBzb7TRRsGOO+441+67737kcccdN++j jz4K5qxIkouPT/ea0kGAyf/GnDpBrhEfFxJbF5QnrhaIDwy2CLhI+DSQ51wsGGj487SvbqDFQeX7 fZ40dTpycV5zWdS5nUTr1gz2rT9LQMlGlhMA1bLMFgJ6AP+sTqG3as3SR1iBLGQfAb42BrGyUCEE hD9WxGYX1O46Qp2ixk+sra0Nq8PXMG+88cadt956650vueSSfkOGDLlYh1maL2rNDuPybNQmal1P UZOsKvkQkM7wc7f+LObLw8hyzIBadtlEwHUUWLgsVAcCO6vDWFxNmYkAVEfzMtEKXoXjm2r9TOXV tUyLFn+/OJtrrrmCgw46KDjggAN6Xn311T1fffXVJ3S/5Fr8fa0xIBR668aqId5qXPlWWg38IIfn nvVnMV4P9hCLEUzLKpsIqJNghvnOeujz2thCdSAwVs3gNa+f7FIdrcpWK5joxuQvfI8tVBYBVoqY Kfz888+BPif/69dff735DTfcsN1iizHfsLhwxx13BPfcc892en4+ZW/kisOsHLGkD1ZO2VU6wT/e QkwIGFmOCUjLJtMIMGt6bT1kbnd+iZlujFU+ROBF6fJRw6JyCOh+YnUHvvDHigoWKoiAdPHDjBkz TopW4a677pp6+OGHXz9hwoQLdHzfzTff/MJSyPJ774WLptRIeHtgLk8V1G9O0fRnfHAHX/PxNpCJ RzFGluPB0XLJNgK8smJ5pXZ6wODran7L2dYntecrZnyR0TrxyumS5cK6mR4qp4BIyZ3mnJOFObQA 9VtvBeeff/4X/fv3P+fkk0++l2PSUZvx4/3CI8XVd9KkcAlpe1YWB1c5Y/E2LezPIMvlLLiayzKy XM3atbYViwD+eLYSRrFoWTxDoDgE7J4qDqdyxGr94IMPBvJNHnL55ZffpgIvyxlImq7KoYXylGH9 WQI4G1lOAFTLMnMIsDA+X6myyWCZU51VOMUIsDQZHbe9pq+8kibfe++9x6ka94kk1y35VvlqWQ0S QOBH15/ZfI0YwTWyHCOYllU2EVDnwax9vmDGa3t7rZhNNVqtU4aA7qXwYyG6r+o+35yyKjab6kgX /dVYxEKVI2D9WTIKNrKcDK6Wa4YQUGfO1/sWdAvpZ6jmVlVDIL0I6L5iaYXfdF+xMokFQ8AQKAMC rj9bSPfdkDIU12yKMLLcbFRtDZ0FAgvq3Gl6yBykBwwTIywYAoZA0xE4Ulm8JHmy6VlZDoaAIVAk AnwqPuzPtJ1qb0uLRK2BaEaW48HRcsk2Avgq437RWQ+Y0fZwybYyrfapQYCBZ0dbDSM1+rCKNA8E 8FUO+zNJ3efFm0fTk2ulkeXksLWcs4MAE5BYm9KCIWAIxIcAS8e1iS87y8kQMASKQIA5Ah2KiGdR SkDAyHIJYFnUqkUAn8o3JLZ8UtWq2BpWAQTeV5kjJDbBrwLgW5HNFgHWVrb+LGb1G1mOGVDLLnsI yO3iF70q5tOgHcwFI3v6sxqnEwHdS3fpvsLCZSvMpFNFVqsqRED33Ujrz+JXrJHl+DG1HDOIgCPJ v2ew6lZlQyC1COi+mpjaylnFDIEqRcD6s/gVa2Q5fkwtx4whoFE4s4d30QOmd8aqbtU1BFKLgO6r g1W5gbqvPkhtJa1ihkCVIaD7bn41aTfdd1dUWdMq2hwjyxWF3wpPCQK8Kl5DD5nZ9YDB38uCIWAI NB2B5ZVFre6rQbqv7OuYTcfTcjAEikHA92eshjHeXAuLgazhOEaWG8bIYlQ/AnTk0yTt1LFPsIdL 9SvcWlgWBPgyJn0ME/yMLJcFcivEEAhYOo5lG9tBlg2PeBAwshwPjpZL9hGwSUjZ16G1IH0I2H2V Pp1YjaofAbvvYtaxkeWYAbXsMonAcNX6IgkjcguGgCEQDwLXOasy65jz5saCIWAIJI/Aj9afxQ+y keX4MbUcM4aA3C54XfyZ+9KYjcgzpj+rbjoR0H01jJrpvrJ1ltOpIqtVFSKg+26K9WfxK9bIcvyY Wo4ZQ8CtBbuQHjJfZqzqVl1DILUI6L5aQpUbpfuqNrWVtIoZAlWGgO679mrSIrrvvqiyplW0OUaW Kwq/FZ4SBFg67hQ9ZA7SA4aJERYMAUOg6QgcoSxekjzR9KwsB0PAECgSgbr+TPGn2oT1IlFrIJqR 5XhwtFyyjQAz9XG/6CzCPNoeLtlWptU+NQjwOriDc28yn+XUqMUqUuUIMPeGPo2l436r8raWrXlG lssGtRWUYgSYgNQxxfWzqhkCiSEgMrsMnaoGib/mFuJe6c6n423duW+dT2TB+ji3JuYBsHRVGzcQ Lar+Sst9OFllhORa/ztpM7HQOs06Txktdf4PX4COzat93D8aJOiKy70/m+L+rv0FtU95M8wlqyh1 WaR0IsAcAevPYtaNkeWYAbXsMolArWr9qqRFJmtvlTYEGoGAyOFsSravhI+H/KH/t+UhiYfr3DoS ZtgThirenYo3ahZF4n7B/fQs+SpuKavMnKA0fSUfu/zP1PYqyQ8FyttKxxdxcXyUtVzZDZJlxVtc spfaxMod90oGSVrp/5uq9z2NgNWSGAKVRmCcu/+sP4tRE0aWYwTTssomAuoUR6rmV2PVMheMbOrQ at0oBHA94nPUN+ra31X7O0ouyMmJV7kXKM77HFe8a7RZVFte857t4p6nLa97Sb+SZG4JvspYfb9R XAg51t4XJEw+2lvykaSPBMvzGZLPJS9K/iWhX/pY6VbRdjuXRz9t/yeplZwfmTRIGeQZDRw7WOnf Vrz3tP2v/kN8j5bMKblcx4e4BP6tUhf9f0fH/4/jSvMfyT76f1dO3vbXEEg1Au4NkfVnMWvJyHLM gFp22UWAV7HZrb3V3BAoDQG3ZOL7IoXbKyXW2Ify5IA7xWGKw8x6LMS4agyVnCi5W8Ir3+MlN0pW l1zvjk9w/1lhZl0JZBpr9EmSsyRYnzm+lOQtCRNrIe8QZkg1YbDkTcnLLh1roeMyAvmFYBMg7bmW 6w11bJBkddUb9xHiHCZ5W/KJBGv1/i49ZXofz+gSd5DpzVwc2xgCmUPA+rN4VWZkOV48LbcMIqAO ldnDu+nhcnkGq29VNgSaisBPyoBXt1hXcwOvcnHB+FaCS8ZRWK50z3RjXzJRAiGGaLbQOSzJD2gf i/QkSQcJRPlaCZ/eXUNyugRLM24PPSS4ajxDwUoLaa5lHzKv/5Bu6oa1GFeMOSTef5pohNy10bEW Q/xPcflD4DeVHCihLYUmPUXzYd/Wh/YI2zYzCOiemV+V3UP3z2WZqXQGKmpkOQNKsiomjgAd+mp6 yMyuBwwduoUqRcBNCNtSzXuxuVtehAXuC1sIh8e0v4L2l9U2tOpG/IyJ85L+v6RzrG6xnba4TECE b5PgwtRdApmd4Ug0Lh3kA+GskXSVMHEOCy+W3XMkK7o8wj5I6TbQBtKdO9mWiUr4VhMg4OQTDaTv 6PTKccqgLhBqysLajTWce/xOyTuS1SIZQIiJz6DA50Oeq0pwJbFgCGQNAd+fcb+MN9fCeNRnZDke HC2XbCNAB8tkoHZYsuzhkm1l5qu99IrVdHPJNpLnJbae9l/XfGthc7O2fPKdSW6QVogwrhEEvsKH KwaBSXuLSrBcXSzBFQNye7XkK8ln7tjr2mJxxh8ZsvudywM3DNZcxtf5e8lAya0SLM2U/6EEq++2 kjdcmQxe0dmlrkyszJTtA3nvKcGXmkC6QRJWx6AeNbqfh6uNlIP7BhMCIc0+UE+s5tSNN0zkA4G+ T+n6R+LZriGQFQRwK+L5xiDQjD8xac3IckxAWjaZRwDCbKF6EMAlwC8/1l3N2keCpfMYHYdwNfsg HOhQ+4pIPun8l7HwQojrgo5DpMOg/bHaXKU4YIsV+Rh33A88btOxNi5f8sIiDFm+ODIAfUTHn/Ll kV7/j/O60t/z9R8C7svsxX8s3dridzwtYvWmTu/o+A467l0zpvvydQw9s5IG8X5UPFbaaB0tW/tD fRxtt/cW6micKB62bwhkBAHrz2JWlJHlmAG17DKJAL6QF0pKWeIqkw1tRpXGr3Y5tZfJXrx2v0wE CMunhRwEcshjg/eAJ74RUlqXY84xLM4zhVwiGiHKYdwoGY7+L0RgXX289bugfl2+s2xfMybJ01u3 Lo0OtGxpLt0pfZjgl09/VszSiSltQvqqVdrdkb76W40MgSYjoA4SX8wvnAUrd7JQk/O3DCqCAJPR fpHgHnCydIxvLVZMfHCjE9l+17nwVaXOzaWNt2pyHfyqc9N1HB9A/P98wFWHiWe5abDmkAara940 WGUVh3I804imwQo7e6Qc/A35WMas0uDDG/XjHac0E/Ok+VPH8d31H/rIl4Y6UTe/Pms0DfWifj6M VX6szZybBsuvX4N5hMtvPsWjnQ2mUTxwBjsfapXfJGdtpm4+8BnfcKJenjRjIL0NpOEaiC4559PQ JzJ50Ycpymu0Kyc3DV/7nKJyZpWmRmm9zzXZ+DS4qLCMnQ98iGWMKyc3DR+MmYrVfhZp8AvntbsP Pg0WdyZF+jBJedW6cqKTJeeeOHFiMGkSHjj1Q4sWLYIZM2Z+LE6ZwmOz7n6ZKZ0dqAwC1p8lg7uR 5WRwtVwzhIAjNovqIcNSVRaqAwGWQ8OlgLcGx0nH5ziCu7L+/zvSRFZhYIIbBJHVHVgjmIAvK760 LCfIZK+9Imme1P6Tjij20r4nPRDo0yQwjjUlu0XS9NM+H+mAjB8rgdwQcBWgHCyjfPxjp0gaPs7B RDkID8uzecIOqSINlqP1JD0jaViJgqXWIE64HXhS/JvqezrkX8c2kuAX7ANrEL8mgTzih+zJ6kil OdNZbjfR8X9G0uD3y7JuEOiTJZ4QsrKGX3+Z46y7HJJABSYEviuhHadKvOsE/srnujj4FFOWD7iB 4NsMUaXNfjCDL7VfE5q24GvtA6tfsI4zGLPEnB+Y4Jvs/Z25Pli6zges4Nz/6PKsyHEGW35VgR21 j1596K0dltTjmqEcHzjGOcLOkuiEQvIiT1YDAQMfKNtb4rluuE59oM7UHZ9qlt7z4WPt4GdOwG/7 H5FzYANGC0nCtaNd+EDbm9w+613z9oXQdeedd36jbdu27USOPTOeMX369PZ//vnnvG3atBkaySPc /e2331rIujxWcezjF7ngVPC/9WfJgG9kORlcLddsIUAndKIeMge5UXm2am+1zYcApATSivmrt7cE awvBQ+oFRwijhKfuvM5BJJHcNBDPKOGJpoGwIrlpILiQyJmCyoEYI7lpINIQ33xpIOBIbhraDsHO lyYk+3nSMDBgEly+NI/pIJJbDlb5XvnS6BjEk68CPhc97yybRxco50EdR3LLwbp7RIE0LEGH5KbB ws0bhnztuUsHkdw0vI34T4E0t+s4kpsGC3qhNLfoHJKbhkFcoTSsWZ2vzkNnkYal+fKl+WYWaUJ/ bh/0/GNwUSPx/q74oi8uAXfWpuY6jJqYIcm5x/JVw46VFwEm4J4kfR6oLW9g7G1pDPgbWY4BRMsi 8wjQOSCz6wHDa1J7uGRepSFRZUUHPrZxofR6j/TKKhgWyocAZKuLc29q0Be6fNWykvIh4NxA/FuA MIp0xxsKBl64vODaYc/G9F8+3GsIb3AKrSme/lakrIZGllOmEKtORRDg1W7UH7MilbBCY0Wgq/M1 fVodPpbXo7TlU8pY+T6wTj9WrAtlhjsHrhYVeU0vfWNh4zrI616l87xRqnGV58MouDoUDM4HGlcV 3lbMofg/F4ui82uezb/h0H9wYeWQgl8Ndb7Y+MeHll79x6WGPLxP+CyLd/FZQo8601b6+5FKH/qu FxlwYeHZOMPumSIRq3w0r7PK16SKamBkuYqUaU1pNAK1SjlAUpFOvdG1toSzQmAGBEUdPBPOIBtX 6j/+mbz6Xlf7t+g4fskWkkMAdxcIZdmXTZB+V1G5+0LytP+etg9wLfim6hiT2/C7/sQda6Vj9yuO X985Hyrz6CDuI/gQk//TJUDHtYcvsnfbwT89fOsxizzw48b/21sHIf/zSV4pslzccHBpwQ9+aQkk myX4rlc7vy4yD3zqB0haKF0LI8xFolbZaF5nla1FlZVuZLnKFGrNKR0BdQCslHCtOoOO1hmUjl9W Uki3LB13tPTM5ClbhzRhxQnv+4U1E/8q8eoeiy2TE2tVh4e0/7gk+oEGJgx+rPNMtsRqi+WVNZ6Z gMikPJYchJQyybJGwsRNyCZuCbyJwr0E4nqoZIgEv+zjJPhpXy6BjG4qgSCfJWFCYU+lud0R1T30 n6+G8qaDCYprS54gH53HfYWAZT46gOf/kgz6FOd6bTfWf161Yylm0iqTGu+MWKuxKIcWbMn5XP+u zszPuED/8c+eZXBWaJ6NHezZ2BBa6ThvOktGD0aWk8HVcs0gArN6JZrB5liVCyAgPX9o4JQHAWE9 81pkZSha5X6JG4IESy6rouSuw8zKJSvqPJMtIaSQ4Psky0vWkDChjQmfn0qwzN4tYfWMRSW4JbDC xdvuHB9FOUQC0ebagliTFrcfVqVglQrINJZhVqggsArL9668RbSlnudIWCnjSxcn18+blS2WkPyk ekPmyZcBAPvUF6v3NhI/QZL0DFQYGIYrnAgX0kKi/YonrqhZb+wtTFEwpSqS6SxedRhZjhdPyy2D CKjzWFDV3lMPF7+sVAZbYVU2BNKFgO4rVqJ4V/fV+xWqGf66uFnwJiHXFYS+j9fVkGEswHwl8FnV maXusNhijcVyjBsJ1nHiXik5j7gSBgGQzn5K9y1vpbS/n2QLCRZoXD5aOivy1+5tBv7H3moMySVP Av7SoxQnTOOO+U30DQjkd6ir8z7askLIrZIjJViQWcKuX076fPlQRlEuZ87ivpc9GwugmsLDprNk lGJkORlcLddsIUCn10MPmdnVKURf1WarFVZbQyBdCCyl6kACmVBZVrcXlYlbAyT0ce3jCtFa27b6 z+Q8AgSYyW64Pjyhc7g14ELBcSzRWHn9msqQS8goLhdYgSGtWKIhnLhz+ODXnsbqHK4hrTxZTxkL MKQb1w0INFhAxkkbWrWdtZdj0cBzCes4pJ/gPzDCsnPUgTWT8b0eJMG3uYcEi7kP1JG6syWf8Dkn YV1riHYxATx4NuLuwUdyKuFSU0w9qy6OMF9BjWJCZ6mDTdNZAleDkeUEQLUsM4cAnRdWHTotrD/W IWROhVbhFCIAMcUKC2ErK1lWeXzy90jdz6wRzEdKmMy5t/7f7cgqBDS6+gVuFptL8G2GhEKW+egH SxCyHvEpEggvrhe4dLB+MX7RfqLcNdrHZ3krSR8J8yCeklwkYRIffsW8wWIA8YUEwspkUyzDy7gy cNWI1ok0kGCeTVik8aH+XvUfpnbgrsHSiPgds2Y29R0qwW/ZB+o4VoLrB0QfazRtuER5eKt2JHre 3bpno86aIaEhtOI9v9Syyy57yzPPPNPv7bffvlI6i+p2ViWZzuLVQ5ibkeUEQLUsM4mArQObSbVZ pVOMAPdUuUlyCIeIBf7AJ4hUsjxb6PqgfdbaDuujLaQRIuvjvxGx+vZxcb3LBJ8cP0ppos8ICDgh /LAH+SkOH45hBRafDqv20/rvV+HYRv9D9wcdw/2jp8vjhmg9I3Xiy5P00T6Nz5f0V0T0/qjiPRkp 17fJf92P/G/WQazadXlE0je0a8/GhhBK5vyE//3vf13XW2+9/W+66aZ9zjnnnANOP/30mT6kU6Bo 01nMOjGyHDOgll0mEeC1JhNx7AGTSfXlrfSfEZJSPa3KVksgdPQxFSHMjpRGCeYs7++oq0ge4tng s8G9kapHRnOvwUJvrQqR2GKv4YZIsCP6DbYh9/JSuu9EtP+n47i02Bu38t5/f44fPz6Yd955gzPO OKP1Ekss0eeOO+444vnnnz9NuuhfqCqms2SUZGQ5GVwt1wwhoIcLr4uHqFNgko91CBnS3Syq2k36 xL+0bm3d6mhWplrBa3tWXVhAuqgYYc4UYumrLAQb/+Y5pMOof3b6alp9NWJd77qw5557ttx9993X vO2221546qmnnhwyZMgdn332Wb61vunD+AR7W+ks36onNvBpxLViZLkRoFmS6kJADxRmsi8mouw/ UFBdDWyerempZjOxykha5fS/rIrGp7bYyWSVq6mVXAgBno2LS/CXLWoFDYMyNgRYKrBeaNmyZXDQ QQcFCy644LbXX3/9ttqO6Nq1a74CvdGnns4+/fTTYPDgwawjjr+7hRIQMLJcAlgWtWoR4IME+Dce 6KzMVdvQZtSwm6RLv95sM2p2epqq+wmf4JekByauWcggAtIhhO0s6ZBlAC2UEQFhv4mKY93sujBi xAhcMsa8+OKLZw8dOnT1r7/+eq/FF2csU1y48MILg5NPPrm78mZJx5LdcoorpTpjGVmuTr1aq0pD gIcGMrseIqPNFaM08FIau41zq7EOoXIKwrpVY3qonAJiKJnVTPgU+Jx6Lv4WQ36WRfEItGvT5u/V BB9++OHgrrvuelwBow5LMh4jn+a9is9Oi4NPCr8RVDdptJS0zT2ukeXmfgVY+0GADoHXjRaqCwF7 bVxZfeIvSW9veqisHppSOhyBZ2MLVvIwQ0JToCw57R/t2rUbIb9krMnj+/bty1chWfWEZRAJnUrO 8a8ENi+nEcAZWW4EaJak6hAYoxa9aJ161enVGlRZBF5X8fgs536VrrK1stJLQaDWPRtLSWNx40Hg tcUWW2zJY445Jujfvz+r++R+sj2eUiyXohAwslwUTBapmhHQQ4jF/1mLtINZTqpZ09a2ciKAz7ju Kb4mZpascgIfY1m87rdnY4yAlpAVPsVa9WLi+uuvHyAWKouAkeXK4m+lpwiByOutFNXKqmIIZBcB 3VOhk6SFbCNgz8Zs689q33QEjCw3HUPLIeMIyPrFZ2j3VofAZ2ktGAKGQAwI6L46Utm8o/vqvRiy sywqgIB7NvKZ7AvtrVsFFGBFpgYBI8upUYVVpIIItFfZK6pj6KzteOsUKqgJK7qaEGBNq5G6rwbq nrL1rrOp2XaqNuuVd5Yex9mzMZtKtFo3HQEjy03H0HLIPgL4VLLEWNvsN8VaYAikBgE+/cxKM0zw M7KcGrWUVBH0Zs/GkiCzyNWIgJHlatSqtalUBOgQ6NgtGAKGQHwI8KlxI8nx4VmJnDAk2LOxEshb malCwMhyqtRhlakQAj+o3POdBaVCVbBiDYGqQ+AatYg+BusyxNlC9hD40T0bTX/Z053VOEYEjCzH CKZllU0E5IeH5eRr96UxW+Yqm2q0WqcMAd1XI6gSH7NIWdWsOkUiYM/GIoGyaFWPgJHlqlexNbAh BNSZ8yWkxdUxfNRQXDtvCBgCxSGg+2p5xfzZPpNcHF5pjCUd8vW+JezZmEbtWJ3KiYCR5XKibWWl FYH5VbH/U8dwgDqFKWmtpNXLEMgYAoeovnwZ8/GM1duq+zcCPBtP4Nmo7RRbDcMujeaKgJHl5qp5 a3cUAWZ745M3uzqF0dYh2MVhCMSCwB/Kpb3uqda6p8znNRZIy54JesNNbXbJb2Uv3Qo0BFKCgJHl lCjCqlFRBJiAxOtGC4aAIRAfAh2UVZv4srOcKoCAPRsrALoVmT4EjCynTydWo/IjMEZFviCxiUjl x95KrF4EXlXTRkpYZ9lCNhGodc/GbNbeam0IxISAkeWYgLRssouAXhH/qtrfpNfFHcwFI7t6tJqn CwHdSw/rnuILcLbCTLpUU3RtpMNR9mwsGi6LWMUIGFmuYuVa00pDQB3DxNJSWGxDwBCYFQK6pyYb QtlHwJ6N2dehtaBpCBhZbhp+lroKEJD1ayE1Yx/JBWZZrgKFWhNSgYDuq6NUkXd0T72bigpZJUpG QDpcUIn2lZxvz8aS4bMEVYSAkeUqUqY1pdEIzKaUrAnLahjjrVNoNI6W0BCIIrCY/vyie+p93VP2 2etsXhu40fBs7Cw9jrNnYzaVaLVuOgJGlpuOoeWQfQTwqaQzb5v9plgLDIHUIMCSY6ymwAQ/I8up UUtJFUFvLK1pz8aSYLPI1YaAkeVq06i1pzEI0CHYx0gag5ylMQQKIwBZhmiVNbCuswrcWLKV5HXJ Y7mWbcXZWcff0PGfiq2c0nRV3LWU5plCaRTnXzq3gRscfK7t7YpfdgyKbVMR8TAk2LOxCKAsSnUj YGS5uvVrrSsOgR8U7dxKdOzFVc9iGQKZROBq1Zo+ButyOT9KMrfKWwKiKtlLMkHC0pDRAJEeIqkj y27uwkY69p4I7hdEduT3K5cHS0xOY9UcbX0ZfMTog0jGm2r/HQnHtpHsLblDaSDQi0geUfzf3Soh O+n/G6TVsWE6top2cXl4OkWfCP9R9eHZWE795ajK/hoClUfAyHLldWA1qDAC6piwgH2nzqqV+eRV WBlWfNUgoHvpZ0c4y7p+ucodoXKv1/08h7aTCgAKga6z+CouRPZQCXXeX/9vcMT1H9puLplHcrhk a8mnEj7h3Ucyl+JOV5mDXDm/a8uX7hBWAoFcr6rtWhLqdYT+36jtwRIsthD6x3TsZW23k3wjOYzy 3bJtBapfnsP2bCwPzlZK+hEwspx+HVkNE0ZAHVMnFbGkOoYPEy7KsjcEmg0Cuq8gmj9VkPT9R+V3 kWAZbihgKWad9atU7zO0P69kDcm9EojveRL6S++/O0hxL1fc43VscckgVwD+2QdIsCp/KXlQwjFc OHjObCi5RbK80kPKa7XPBGPKW1ICEYec39ZQhctx3j0bl8qxnpejaCvDEEgVAkaWU6UOq0yFEJhf 5R6njuEAdQrmn1chJZSrWOm5m8qqla7t1XKyoB+k7F+SPJZsMfVzdy4OEN/ztX+yzq4uGZqnDhBV H7gWClnAc79ASL/JlwkJTHyLPjOY/3COyv7IZ6w67KD9ZSRjJR0lEG5fVjRvP5nuTp0fXU7MZlHW fDoXPhtpp715S4lWrBplR8DIctkhtwJTiACdF50lS8fhg2hfHEuhkppaJUeiDlM+WPKukfAq3kJy CPwB1sK9dZkHJrhfHKRyx2tbIxmi/bW1Ha56MD+BMLvkGB3HNYKA7/Bv+t9LW3yS8WV+TYJrBC4Y WKh5TrCUGkSXOIQ2kmg/ynkIcTTg5sU1h1sG5BjXkHdUFm4f20uYMEh5uGB0lkDAiV/IhSQn+0T/ 8lyk/uCFhd2CIdAsETCy3CzVbo3OQYAJSLwitVBdCNQNekRMdlHT/il5VfK4SJMR5eR1DaGETJY1 sMKF9I0bw/qSZ/T/S+cSErUAX65zy0m49wm4THwn2UzylNIMdWSbiXkch3jXSpi0yKS3K106rMDR a+la/fdW5zCK8npaeeHLjDDBb7L+v6X9PSWvSCbr2Cc6BpFeVsIEP8pKQ7BnYxq0YHWoOAJGliuu AqtAChDglSfWnbJOREpBu6u5CpNEOP4UAVlKjcQdADL0fylaZaCasfdtY9Lar5JcN4bE2y49Q2jv 9wVBRqOF6v9g/UdyQ10ancBnGWswbjvXKg2WXlbQIHA9QYQh0nVB//P6R+s4pDga1tUf3DLGSUL/ ZOe6Uee+kadulTjECiAFl8qrRIWsTEOgEggYWa4E6lZmqhBwE5BuFbHCz9FcMFKlnUZXZh7p80il ZuLUK9LrU43OyRI2CgFh/mijEqYkkeoPSUyEKCpvLNCpD25wybNxNns2pk5df3TtyrzR4kPHjrke QsWnbe4xjSw39yvA2l+HgDqDiQZH1SAAGWFy2U2eKKvD31X/WcfWh1t17nsdZ4In/qM+fKnjrILA Ort7aMPkLB9u1rnhOr6QDmCx9uEzHX/ApWFtXVY28IFlwHANYHkyJkr58KmOP+TS7Kstn4f24Tqd 41PRHOOcDx/p+CMuzf7ado+cu5qBn9KwxvA+keMf6Hg4yU7nqDN1JzCh7CqdG6PjS2sftwAfWGv4 SZfmEG0XcCfw271S58YqDW4Mu0XSvO0IJuXgGz5XJA3ljHfuEDtH0vBhkOddOUdoy6oUBCy6lMOa xD20z8c+fHhVx1/Ucd4EHSWZ053AR5o0f+gcy7XhD+zDyzo+wLk6HK2DnmXgGkEaXCOwJLOKhQ/9 dfw1HaefJA1+ywRcMmjPFJ3DF5o1m314Tsff1HH8jkmDry8BKzJpWEpuPe2z4oUPuF3gw4y/8zES z2iw6pJmus6xisYmkTRP6Pj7Ot7epWFLwK+Y62CGzrHmM24kPvTT8Q91nPwph/III3U8JO86t4U2 WL19eFjnsMq31rlTtfVf8vtZx693aXBvYmk8Hx7UucGKD16U411dftTxm1yabbVl4qUP9+ncF0qD XsDNv434QcdZPYS6MVGStah9uFvnvtJxLP9cBz4M1XGW5CPNjtqsFDl3p859o+NcZ1xvPnyr43e4 NLhsrRA5x4dlcMth4M117cNXOn63S8N9wP3gwy0694PScN9w//jwhY7f59Jwv3Hf+cCz6kelyX22 DNZxVlWhPdzX3N+EDS+++OJgvvmYg1lceOmll4KWCtOn2wc1i0Ps71hGlktFzOJXHQLu4QQhOY9O puoa2DwbxOtyCAoTpuo6Ku1EVxngFTgBn1Mmc/kwKrL/mfZxJfABokQgbTRN1E+V1/vhGsOR/POl +SUSB0KC64APkDhCbU450S/OfaxzfsIacf1gD5IVrZufxEYcXvMPdXlzrftJZOASTTM8UpdB2v/W /aeXhcgSwCma5vtIGj7KcZrkbcmbEu8vDJbRNMNy0nii6CeWcRqcomnC+jtC+L52/WQ7JqL5FU7A P1/daPN7Ek8uSePXWwanaBqPLW1+V8KkOwJt8WnQWTSN1yHnSePJJTh7hgK2+fRDGj5o4v28If/+ eQS20TT+OqC9+D/7NBMjzzBwirqW+euNNqMT3//7a4224VYSZVJM0Dxdxy5xaTzx9fcBaZiYSJ4+ +PuH6+R1iSe+/n4j3teS6ARGP3mQY6Tx9eYe9gEXl2hduc4JXPdRbPxxzuEuEy3XnyOfaJroc4EP 0kTz8HXITROd8MjXGqP/fZngFC0n+izh2RJ9bhTzbPlUabzuX77uuutq9B/x1wl6YPDPYATyn8uK wZVnDXq01YAiF1dDu0aWG0LIzjcHBOgEmVjDahjjjTBXhcqPUysgNetKpxdre4H0CrmcKeg4HVv/ Aufy+pAqDR1ooTQfFsiLDrhQGshlvrrRiRdKM7BAGjrtQmkgivnKoRMvlAbSly8NHX2hNFhKweFD YfWyT6x9SGx0IFGXr85B+vKVAzmIDhKiaSB9+dJAWqODjzCOu7ffKJAGEhsdJPg0EA4IXL5yILHR QYJPA/FlMmm+NEN1EKkXVDfIS65vs88PEovkpoEcFUoDiUVy03BfDChQNwhpnd+1dMjbEJ6NbaN6 jKbVcQam3pe77pSOQ3x5uzNTwIqsg0hu3RggvFggDeQSyU0DWS50Heb1TVf5EN9CaSCTSG45kNlC aRrzbBlUoJ0lPVukIwZKnixz3WF5xjLOm6HayDmKgywzeIkObvJVw47lIGBk2S4JQ+CvBw0dorcC GSbZR6CLOsR71JG8oKbwav0o7eP2ELowWCgLAgxCuwj3ci8dV5bGNZNCsECGS+ZJjy3MkJA+rUsn 9Yiv9MRgCEL8Z+659NU+OzUyspwdXVlNk0MAopyGNU2Ta2EzzDlC0p7UPtayXZ0fJ/7Ib6kjMce9 ZK8LOu2yveqVbsMPaEgo93zpN7qkG/6ei+t4r0idsFLijzpTHRV3V+8nWipESosl9nBXDlbPi9zb i1lm5fx1V1OkQRL8hnFhWVdp++ZLqPj4S2PxzWtZjqZR3H/of0fFJc9SAhhi7Z2QjygrXyyYC+rc sw1l6vBnzWos8QsrzUxvBRQHf398q+vpLqct+AGvrTgPN1RmGs6rTfh0416D7zRzG6LuVzNVUfGJ h783b4jmUvwBPpLO4buPz/6s1rzGeowLTCsb4MR3BRhZjg9Lyym7COCbeJ7E+yFmtyVW87wIqHPB d/EcRxogIrw2jfpdGnLxI3CVsuRtTbn8IzdWWY9K8FM/xUm0VRBG+rxr3EEmjO0luUPXxYbaLiq5 R8KkqxN1DH9qvvTIOs0LujRY8ZiERrt4XV4jWTznjQWT0HiW3CDpLsHn9/+UB5M1mXD3ruKH7gQ6 xiRE8mOiGHnzlouJkRtJ8BPfUtJX8fbTlol4T7t6sIFU4a/9is6vTz2IqzhMpMQnm4mUuJxAnDx5 YmIbfuFMyGMyYp2vrtJwnDRMQKMe4AFpu0CyoRuMkP847fPWgLjoFleNZ3VsVW3BmAmLI/WfSa7U z+PDvBDinCUJraGKQz2YQMuERQggb4EY3OJagG6YSJhLxP9Pxx9weHbSPp/jflj/wW0OSXv9H6T/ 1I9VPPwkPOrJYASXp1rJ7BLSgw2uQUzsY9LeG0pLXKyz61CWBCz+gZ51jol+4EtbGKgw6P5npBzc INaT4KuMK9CJLg/8msM+RnkwUY8JpEz8ZaLlHpJf9f8pbZeSMCBggL+WzqP3z7RdWP+5DhmInUM+ BQKuRPRnZRuozqIuVXPKyHLVqNIa0lgE9CDiwc1s51b5rCeNzdfSpQ8B6TevP2L6apr9GkGYHDGI TjJLrGEq715HsiCkfkJhtDzucwgu/qpYfCFJkxzRZACFf+8REvy6GUhBFA+QsFIKq0RAdDh+huRA CYMB/IhZgYRnx0OuMMr25VDWBEfkdtI+VlXecEDgIFsLSbA0sjICvt3bSXpLIDpDJdco7kluf0nt bxUhj7wNI28szFgvGfT30n/qRZ2xzt4iwTLNhDqsuhCu0yS3SnBNusKRX8j/Ma5ciByrL5COgQW+ 5ytLQnyUhlUwDpbQNgYcj+nYitoyqQw/5EP1/0ptL5cw4Bih/wwKmBsAfpDoLjqGDiD5YHKY/l+n LeQdknqCK28ZHZ+uOj6v/5DMjbThusJfn/qRlhUkqAftZ7BDuyCfDE6mah9dPS5hVQriM6DaX7K1 ZBNJLwkW7VrJxoqPniHwYAh+V7syWbc9tLK7Yxw/VYK+RzsC/Jz2d5TQ7t0lkF+uBXTFwIe6MiBA 7/tonwEVJJ18l9V/BikMGuaUgA+knHiQY8g/cwva6v+qwgQMZgo6Hl47itPS+rN8CDXumJHlxuFm qaoIAT1UsDAsrQfL+1XULGuKIVBRBHRfYfkcofuKDr5cAQIKEbotT4GQDyzI3O8QTNxxIFyHSSAv kEFI3c0SiAivziEoBIghVlSE5ccGqn0Qv7MlENB/SzxZppxNJd0kWEg5DgmE8GG1hlhyDlLDQAKy 9aIEYuStgW0gsfr/scqBQENmIby5kwYh/FgiP1J8rK23ax9r7rL6v7/+12of0k+AiFF/rMM36hwY EZdy4ALL6Pi/3fMQKzOTW4kDKSQdlu7NJTe5/A9Q3DEuf9qD+wlkmbbfKMFa+z8JFt9dJeBAfSC1 rNiA5ZSBCWkhzaTxrlEMbMCOiYNYaH1YTjtYWlm2b5T2GbhgLYcck++zOtdf567V/kUSrr3LJAxE Znft7q59LONgzcdm+HoiZJU3Alh0uRbAlSXwWGMaksuABZJP+9EBVnnOgcWdEsjx+RKuKfSMTtaU PObiU/7iEtrHcerNNYXuIdQM8LguuTa8jtH5p5JaCW9KGDRcrjIZSDAQyEuWdR5rObq0/kxAxBWM LMeFpOWTZQTmU+WP1UPmAD1geEhaMAQMgaYjgEUPEghhSDzo/p1P9+/b2kLCIEgv5RQKGWHd4MsU B4tiD6xw2qcfhJxBciGbkEqIGkTWT/qFEPNKneDJP2QHogkZhWz5wH/W2e2jvDtr/woJr+CxNEJw eI0P+YRUYdGGLELwsYrms8LfpeOQKIgibgb8byj4fHjFHw1YbUOLvwJk0ZNT/kfTUD/ayRYLK0TW 4+MHDqSBdPq0HkPII9ZUiCD44JaAZRX8fSAPrNW4K+A2AGakp37UCVcQBlv4RNdIIKG+HPRDoG7o h//Unf8QaH+O4/5cFFevUyzIrGWOrnmD8K4EPVNv4nicGBB4PdMOrhd/jv/s40pDm+lLGBhgjYfE gzEY+Xq46oX/0Q1txuL9iSt7sLa+rmBBueDDAIQtoaE3NdThv2oX19QUsy57yJu2NbLcNPwsdXUg wEOTh1YnPWDs4VIdOrVWVB4ByBXr9JZrNQxeoUPMIE1Pax+ygoXNW+o4jsWUwES3bRTnH9piQcUa B2klEI/jWKmxIB+rLRZnXBI45wkoJIg+FFID4fIBArW30kFsIYH9JTxjIEiUzz4kag0JZBCiDVae nJNfSOh4la4NLhYQOCzPxPOBsiGgEK2dFBd/1i8lEFEGDVjMcTXAckk+xKf+nuBShidePP8+Upoz tcVC+6SLR5kfSyCE4OPb+oGiHqf/W7n8WdoPyzdxwIcyEHDxacAFVw3vIsOWuFi3IcjUzcfHmgtO lB8diAzS/01VNumoPy4lEOQ3XFziE7Dk4ioCzm9KILy4g3AMP2kGJpTldYmRBF1xzL9B8PyIdnDM t4Otx5D0vs7sU2cCbfJvDsgX1wyfN9cj1xREGDcM9AVu1N2XTVyO7+vioPc7VX/yQudY3AsFygVb 4uHSYSEGBIwsxwCiZZF5BHhA0VlaMAQMgfgQgDBESWR8OefJyfks99SpadpnkhjWvtpIVF7nf8B/ nZ+o8xdCKNxrePxQF5EwOY2vBuJeMUIyQIIbBNZCb/nkeUHgtTvHBkm+j5SDRduT2yHUhXPKE19f rMO7cF7H8XMlr87aZ4IaWPWWYMHG35d68vU+XCF6Sl7R/1ci5UCC8ZXmi5Ic7i55Uv/5giHuDViy aTNkE5cSyCVkzuvkAu1DIikH396rtUtbH3VlUAcIP5hR7pySZxSXCYTXubiQOXxjqcPD2qd9TNbj C48Xax+SB5mHgOObjYUay/8fioP/rh9s8PYBcnipq9Md2vaUvKR4tCEM2mfyHccZyEDg75fU6DgT DKlfqAf9xyUF32BWC3nU4YyLyCoSBi8MWiDMrKtP23kTgfWW9qBT9OIHEugZ3HBrII/xElx2CNSX gQJxcelgwh5txN0GPRP3FglvE0IMFGeI4kCe0SeTJcH5X5LjJRBd9EX+S5577rm7dejQYZvTTz/9 299//x23EvKdpHQM8AoF689mAU5jTxlZbixylq6aEMCfkI6noddb1dRma4shkDQCuGBg9cMSV5Yg EtHPF6R9iGBIBgn6T138a3r+42YQulRon1fwiI87IFLhujyjjVAarLiEWic+Lf9DgpwTH7KE1AXl gSuGTwdJwzpLgFBGj3t/6GhaSJqPAzlGfMBqzXMN1wA+C+0tntH0vv4+D6yrEF4f+JQ0BBSyyqfM IbPROj0SiQuGuBAgPo7PnzoghGdy0kTrzClvMQWLmdrs0l6iLe17QfK+yg0t1dpiRa2zpOo/z3Qf sNouL6GNWMr5zHqdC4r2GSxB2GcKET1Hr6daV2adnnzdFX+Y9hEfaFM9S7Di1GGnfd441MNS/xls /GPFFVcMVl555U7arvjEE088eeWVV6LzvfLVM3LM92cNRLPTpSBgZLkUtCxuVSLgOtHb9XBiySHv D1eVbW1GjWJdWKw0FiqEgPDPSz4qVJ1mVaywx4rd5OAIKJbt1ATVCYvyTIORWVXQkeHzUtOI4ioy buTIkcGCCy4YyjrrrLP2VlttFVx00UUDnNWepedw5agXdAyyfHtxRVisYhEwslwsUhav6hHQQybq G1f17a3yBrISALPOoxOYqrzJqWuen2BVNsty6hCojgpxD/HWzd68lVefi7Vs+fet0759+wCyLFnz nnvu6fvYY4/hNx61nhdbu5vV19V7w1FswuYcz8hyc9a+tT1EQA8cZkAzc/h/ZlmumoviU7UE39GZ Xj9XTQvT35D/qopvOUl/ba2G+RBgGbUDJfhw21u38l4juJqwJF698O677wYDBw785MMPP1ygb9++ py+zzDJF1+raa68Nrrvuug/V5w23vq5o2MKIRpZLw8tiVycCzGJeSjK7HiJM+LBOIft6HiQ95i4d lv1WZagFupc2U3U/lh6ik9Iy1AKrqnTIxDTWAH7d3JrKez0waXPGjL+7oj///DMQ2R17zDHHnKOa XCs5dPnll++99NLM+SsuLLDAAkRkMjuTAM1NrTjYjCyXgJNFrW4EeCLxqtGvv1ndrW0erWvHTHvr 4CuqbJbX6mJ6qKgOmlo4K5owOa6r9DjKDAlNhbOk9LPNOeecASRZLhfBxRdfPOCdd945XzpgYiNv RDv98UdpnoNTpoRzIc0YVJIa/opsluVGgGZJqg4BXtWX9tSpOgisQYZA7Aiwrq5Zr2KHtawZYkSw Z2NZIa8rrB1uEw8//PAbd999N8vS3bf11iybbaESCBhZrgTqVmbaEGCyw7nWsadNLVafjCNwlerP 2xp75ZtdRfLVOJ6NLOVmobwI/PbCCy/gs/yYTT4vL/D5SjOyXHkdWA0qjIB7Vf+9XmuxuL69oqqw Pqz46kBA91K4hrHuK1tFIaMqtWdj5RQn7PkqoYWUIGBkOSWKsGpUDgF15nwWdDk9nPjKlQVDwBCI AQHdV3wt7UfdV3y5zUIGEbBnYwaVZlVOBAEjy4nAaplmDIH5VN9j1DHsr46dLzxZMAQMgaYjsJ+y YEWSfk3PynKoEAKshtGLZ6O2k+3NW4W0YMVWHAEjyxVXgVUgBQgwwY9pwp3UKUyxDiEFGrEqVAMC E9WI2Ww1jEyrkgmaGBBYbswMCZlWpVW+KQgYWW4Kepa2WhBgAhKdgQVDwBCIDwGWHbM+Jj48K5GT PRsrgbqVmToE7EGWOpVYhSqAwG8q8wmJTUSqAPhWZNUiwHqw3Fv2uevsqni0ezZmtwVWc0MgBgSM LMcAomWRbQTkdkGHfodeF7c3F4xs69Jqnx4EdC89oXuKpeNYq9dCBhGQDiHL9mzMoO6syvEiYGQ5 XjwttwwjYGtZZlh5VvVUIqB7KvxkmIVsI2DPxmzrz2rfdASMLDcdQ8sh4wjI+rWwmnCARH2CrbOc cXVa9VOCgO6r41SVt3RPvZmSKlk1SkRAOlxISQ6SnGXPxhLBs+hVhYCR5apSpzWmkQjwqngJSWd1 DuOsU2gkipbMEKiPwAL6u6D72I+5YmTz6vDPxi7S41h7NmZTiVbrpiNgZLnpGFoO1YNAm+ppirXE EKg4AizJyGoKTPAzslxxdTSqAnzRFLFnY6Pgs0TVgoCR5WrRpLWjKQjQqf/elAwsrSFgCMyEAOss T5XYKjPZvTjs2Zhd3VnNY0TAyHKMYFpWmUXgB9X8XAkL8FswBAyBeBC4Stm0k9jScfHgWYlcfnTP RgY9FgyBZouAkeVmq3pruEdAfniQ5B+cbyWvHC0YAoZAExFwSzIGuq/MstxELCuV3J6NlULeyk0b AkaW06YRq0/ZEVBn3lmFLq+O4a2yF24FGgJVioDuq9XUtOG6r36u0iZWfbPcs3EFW9Gk6lVtDWwA ASPLdokYAkEwr0A4Sh3DB+oUJhsghoAhEAsC/1YuL+m+esxWUYgFz0pkMo9/Nmo72fRYCRVYmWlA wMhyGrRgdag0Akxi4eMJndSxT7EOodLqsPKrBAEm+M0mYUUMmw+QTaWiNwwIndw2m62wWhsCTUTA yHITAbTkVYEAnTmdgQVDwBCID4EOyqpiS45p4LucyscyOiB3AOz8qP+hc3O65k5QnPdm1XSloS1z SMZKFlD8b4qFSmmZ6FijNL+QRv/BpoP+jyqUh+LMr3O/KA6DedJQdif9/77YcmOIZ8/GGEC0LLKP gJHl7OvQWtB0BOiw+klsIlLTsbQcDAGPwHPaGS0p+2oYIpZrq9xdJH9Iltb/W0Uyoys6dNPxaySv ucq2V5xuivOMI6bto594dmQXd61eknMkS0pCsqxzrSC0jky3zkk3m/5PUrQekr0V5xj9Z83pjSXr Sk7JV56r01nuvCfUEPv5JDORZeVbr74xXoK/Ka9+MeZnWRkCmUTAyHIm1WaVjhMBdV506He7DsdW w4gTXMur2SKg++opRyArcU+x5NlJqsMU1eFB7d8jiZJl3iS9q/OnOrIKEb5IcQdou6dkNe0PdOmw Tp8oGSdhQI2FeX6d5wuFkN13tP+ytkdJ+NLdTdp+ItlWsoP+X6DtZhII8mKSrzkuWVnnrtZ2R0kP 7b+obT9HrqlW7uC9i4u3huJcqvj/1H+szSPJQ/+/0raPe56RvslBeY1RJvZsbDKSlkHWETCynHUN Wv1jQyBqEYotU8vIEGimCODqkGPNLRsSuCqofIgr66e/JMG6Gw3j9WcNnb9QW/yq8c29UbKsZBXJ WZLzJe9KdpNghV5Tsp6kvYs3QNvVJf+T/EfCajoQbNKdINlScpxkRckTEqzZ3nXjEe1/KVla0lVy uATi/JHkcwkh96uHEHryYJnL7bRdQsKg4F+SsyTHS7aS3OvSx7axZ2NsUFpGGUXAyHJGFWfVjg8B dTyLKLcDJWfa5L74cLWcmj0Cx+veelP31BuVQELljlX5fR2ZpK+LWpbb6v8IyWOSTSChiv+m4vfQ /jqS0yTEGS4hLWS6jwT3C/x4mRAMyX4WP2RnQd9X/zeVQHbDspxPMiuCQMCnRp4v5EceWN2ZVDxV cXI//MG56DF8l6kz+bPSCC4SEHys3tR3dsmnlBtXUJ0WVl4HS86wZ2NcqFo+WUTAyHIWtWZ1jhsB XqvyerSzOodx1inEDW968pN+mTTFK/FHpOcJ6alZVdYES+gCwryl89MtWyNV5oYqDFI7SIIbRUsd Y4JdrasEE+5+13+swW/p3PWSBbXPswBL9KWStdx/SC0WXdwleE5AWrEu44uNGwSBFSPukmCJhhiT D37My7s032o7n/63U5nEpe/FjQNLcgcdZ59j4WQ+F3C7WETnIMUQ546SuSRYp7E6v+nKp0ys2ZQb TR/JqtG7/tmIlX6sPRsbjaMlzDgCRpYzrkCrfqwIVGzmfqytsMxmQsCREV5X95Bgbcx9LW+oxY8A hA7CCqnMdSmIv7T6OQ7W3yMlTPK7QsIydnvpOrjXEXcGStHVL67TfyYFYmnmTdPpknckrHxxueRM CYT3SZfXB9rWSt53xfbWFgsvA7HrJax68ZCklwQ3DcoDi+4S3C8gvHtJqCfWWyzD/VwZLsvQgnyE BOywMOPT/Inq/5PaQd2RXyVcz9SX+K/7xDFtIemIPRtjAtSyySYCRpazqTerdbwIYI3Bh9FC9SCA v2y4tq+IBb6mTIYaoWMHVU8TU9+S3x3JK/sqM8794awchO72/3UeknlD5D8T8hDCw078aQZWvQrk 1Yfjyo/nB4Q3Gpj0h/jAxMEwKD6T8fZxf6lXXd0icSDZeYPS3xo50V/7SBLBno1JoGp5Zg4BI8uZ U5lVOAEEWIqJ5aDswwkJgFuhLEeJJON7yut4LIXnimDgf2qhfAhcpKJwO8j1xS1fDaykJiEg3Q3T fcSz0T7W1CQkE0k8rV07vImKD61bG+UrHq36MQ25xiJn6aoGAXUI4cQZ51tZiWWuqgbLFDXkDNXl O8nr0i9Ld2FhhjTjB+rDNzr3u47jf8rELR/wWx/q0nTXtnPk3Nc6N1Fp+KgEqxH4gD/nMJdmUW2Z bOXDVzr3h9Lgc7p45Hitjodr5uocvrDRD+MM0blJOs4xzvkwRsd/cGnIizx9+BJ/WKWhbOrgw2g/ UNA56kzdCVzrpGF5NdrYPZLmNx1npQXqBjZg5NN8AQHW8dCnNpJmlI4zAc2nYfDJ+sULaevT1Ggf twMffsWtwKVZSlsmzRFwPSDNNKVntQjy8GGkjv/s0rCahGcM3MekwVcYX2J8kH3g4x5MxMPKTRom 7xGoIxiQhnWM8R324WcdH+nSLKOD3hWBNJQzXefwZcYP3oefsFrzLNEB0vg+lgEDaWboHH7HrJfs A288GNzhpkHdfBp8pakbafC7Rnz4Ucd/c2koh7QEPkmNmwc6wGd87kiaH3RujI6TP2n8+teTdHyI S0O9qJ8P36FTpWknWSGS5g8dxzpOObQfHHwYpnNMrgQvyvFvFqJpwNl/EIZ0Q5VmnNKgFzDwaSbq OEvtUQ769D7iHKJu46mbS+PLxxc9XHXEXXtcPz58q3MTdJzrjOvNBz5Kg5sNabg+a/KkyX1OjFca njH5ni2FnhNxPluWHD58eNClS/SRFql1nt0xY1gJsO76mnVkO1sPASPLdkE0ewQcUVhRD764/f2a PbYVBAD/U8iG/6ADVWGd25UidWKpLjpIOvr9I8fxI73F/Wd1A0iCD721AymGhETTfKz/t7tIm2vL EmQ+XKYdrNqQl2iaD/X/TheJZcainffF+g+JhLxE0+Ajy5rBBFxLouSbQQFr7kJEomne1v8HXJpt tO3u9iGkTAxjAhkEIZqGFSxwRyCwTJknqxBF0tDrks9+Lg6bVyWPuv87aIuPOIMBhDT4/0L8vfsB UZlMx7JqBOKDEQHXh/Mk+PpC8OtcGLT/guRpR2J30r4nd/glk4YthGtXlxebZyV8JAUStrPEEzXy Jw1EG52Rnw9PaQf3Bogovs+edI1zabi+mMDXM5IGn+cBEvpWlpzzAy3wAgPwYym5bSNpWEbuNQnk cg+JHzShF9IwqOG6Rd8+4A/NBD+IItj4ARBE/QIIto4x4Y9r0Yf7tMNkQIgi/tJ+YMLAg7cAhNUk rA7iw+PKD6LPRET05gcZDKSYBEnAzWmDSJo7tD9IQjtYtcPzDAZ5+H8TuD/XjaS5Tfu4wTDQ20/i ifxQ7V/p4hGfSZc+sJ41ftqwxei1C1G+xkWiXrTJB1xvGEzU5KRhsICvOWEjycqRNNdqH8IOUY+W Q9nUgQBm6NUH6jxUkvts+VTHvAvNZtrn+vEB33ruldxnC9j3cZG20JYBCGHqjjvu2Ldly5bo3ht5 ps+YMaPT9OnTF2vVqhV41nOBmjJlSqD4I3Xe4xsp3nZnhYCRZbs+DIG/OujD1Sm8p06GmeoWso/A ya4DWV56xdLFByh8h1OvdTpOJ35svibrXNQ3tC6Kjg+dRRrfgeaWQydeqBzfUeemwXpXKI0nBLlp vphFGk88ctPQiRcqxxOc3DR04oXS8NGMGp1/SVhBiMOgfSbGITMFnfOELbccP5kt9zgEATKZL69w lYvcE1iDdezcAmkYLM80YFYaCG5e/2Gde0XnkNy6QaSZFJivbkzUQ3LTMEBgol6+NM/rIJKbhoHB qQXSPK3jSG4aBgjcH/nKYeDiBy9YTLvrP4Ow/dRWJjDmS8MAyQ+S6s5jxdaf/yuQJtcvPIyGtVyb 4wqkYcDnB33RchggFroOGVj6wWU0DQOEQmkYwPpBbDQNA4RCafxAORdryG+hNH5Anptm6CzS3BiN 7CzkDMg8Wea6401QLwnXBddHNECeuQfsDWq+i2wWx4wslwiYRa9KBLAq8ZDppIeP+eZVh4ohjM9I sMjtL70uqm1fR3yqo4XpbwWW0rl57W+4p19ZBWoIucKAMLs9G9OnQ91XDLDqrewjPTF5lbcBuJYw +LAQAwJGlmMA0bLIPAK8Zo36i2a+QdaA0JeXj0Dw2vlddSC8Pr1JW155v6jjfxhGoa8lr9V5VY0/ a+jrGg06j4sD7gn+9ftAZzEsCJ/zla11aehjsGQVFXxaRwK8Pyx+zXknCSo+r+Db6jwEIQw6hgsG /qwMgC00DQF7NjYNv0qk5p7DnaUFrkrOJacS9aiqMo0sV5U6rTGNRAC/1r48XBqZ3pKlE4G69X3V YdyujuNJVfNIybLav07HWNqs2QZhgK/joZIaCRPxHnaDiygmnF9OEk7mUlhX8W5RvB9del6d173q 1TEmQR0kGeDuKUhueF/pXCvFZSIdHTlWr/BVMK+SPTnWX5Zfu1/yOhZpbVmJ4RLJF/rPgHZaJC7J 8eHkrQE+3j7wGpqJhvXIsntljZUbNwQLxSGAZZJno4XsIDDadBa/sowsx4+p5ZgxBNR58nC5j47e RuEZU14J1XXWR6k59MM0q+Nfr2ofEy7fChMmvTGZEUt8NGBZvFhxBnFQ8fCTntdZpE9wx3pri28m E8AgqkwGxO+VCU/vSI5WfI5xjzF5icltlIlvN4T9FO3jz82EOiZxMYEO32HSryPZSOcpivJYyeBS 1SdcRcSFXP9LVo3opXivKt4r2uJvjN8qJJ6vdN6aZ1AQyc52PQLuLYI9GzN0SZjOklGWkeVkcLVc M4QAr6qorr2az5DSmlBV6XloE5JXTVLn2gBp3VuNgqTWmzzkGgqhPlVxWCKLlRcgtQgWXyY1QaZ7 SXpLWM2D47i6+IlGTM6DQLOaABMpsewz6et4CSsbMLMfYj1eAklm1Qo/WYzVQpgcCIlmshITpSDQ 5BESdQWIci5ZXlXHmEDXQ/Wu0ZYVT1iVAQLOpEQs1axuYaEBBOzZmL1LxHSWjM6MLCeDq+WaLQRY NutgPWRON8tythRntY0FAZZ8Y0UYSO2gnBxxZeE8FmJI7s26R2qdC8bR+j9WMlBCPPwjWV8Xdxdc JsJJsy4OqxgwEQmXDlwtOM5yXZDflkoXrlzhXC9C/2TuRf1n8i3/IcS4e+BrnkuOiRMN9GuQ7FMk LM3FSiMs4bWfZLhkUE58+1sYAd4IHOqejUX7nhugFUXAdJYA/EaWEwDVsswcAsza7y7hFS2Lxtuy OplToVW4VAR0rTMJEvcLrLkQ2TmdX/CMiD83bhIsqcgkyZu1v7u2Z2uL69LjbsvHIsJ1W3WOyYD7 SVjmjPuoRsIkQb+8FZbmCyWsY+tXWuC+Y31j1oNmIuH8kkGuPV21xXUDoryEhLKiy2HRhy2g9Ax4 CfgjYwHnnobgbyyBIGMBv1vCOtVYnptVED5rqMHo4RnpshTSC46LSNDRWHs2ZuKyMZ0loCYjywmA allmFgEeMhYMgeaCAAR5mASHYCbwsab06hKWCoNoEnCF8CtNsJ4wFmjI67kSSDMkFLcG1qDlIxl7 SiDVuFTw0QsIOXlBYn+RPCTBpYIPOgxwcc/QFlcJJpOxIsdqEr8+MNZn3DVY6xcXD9buja6tPFj/ +VjHSRICFmo+JAKhhnwzD4EPdVynfdYJ3kzCfnML86+77roPdevWrb+wuEqYsKxiMcEbDuzZWAxa 6YhjOktAD0aWEwDVsswcAnx0gM7dgiHQbBAQYcJ9YYAT325cLuqC4kBuw6B9SHT0Yw29csBi1YS6 lRNEyriv2igd5NmHl7WDREP0Axn1iKzSQpB9OCwnHXXiK2X75h53/yHod7m64xON+0dzDROPP/74 1ltuueVW991331ZnnXXWiT/88MNNuNQ0AIg9G7N3xZjOEtCZkeUEQLUsM4cAE4/olHnIWKgOBPi4 jOmzsrrE3cJ/UrmyNbHSp4wePTpo3759cMABBwQLL7zwRXfddddhGtDw3Hsg4nZTDylWHVEcBjOT zAUjMxcRb3nQa961yTPTipRV1MhyyhRi1Sk/As7C9pM6BSYamb9y+VWQRIlLOT9NI8xJoFtcnlh2 Z5MeeIVv91VxmCUVa/kWLf5eRn6zzTYLJN333nvvWx966KHD+/fv3+e1117DBz03eL11lR7z+Tr/ 5FZVSarelm+JCFh/ViJgRUY3slwkUBatehFQJ8BXwFbSQ6beK+jqbXGzaBlLoTGhqZTJTM0CmDI2 cm2VhU80HwixUFkEmKQ3U9h8882D8ePHryqXjFX32GOPy+aai1umIGGu99Gmt956K3jvvff4KAy+ 7BZSgoDrz3qoPzO9xKgTI8sxgmlZZRYBPmLAK8l39YBh0pOF7CPAEmd+vd7styaDLXCv+F+SHnJ9 lDPYmmxXWbpYTy3YMdqKzz//PDjhhBOGPP3006dOnz59k2HDhh0m94yiG3rhhRdCludX3uGXGYtO aBGTRoAJuPRnTKydbG9L44HbyHI8OFou2UaABz2TlzrqAWMPl2zr0te+A2v2mt9yRZWJ+8U8poeK 6sAX3hF/ZcLUqVODq6++Onj00Udvev311w+H6EpH3ceMGYMvc9GVnTgxXMGP1VDqWZyLzsAiJoUA rmcYffisPP2ahRgQMLIcA4iWReYR4IHPRxIsGAKGQHwIsEazLTkWH55NykmuFsH9998/XUT5tTff fJMPtrwVsTr+xaRLD+aLXjpmSafw/ZnpJkakjSzHCKZllVkEWEeWJbLMQpJZFVrFU4gAX/KrlYQf LLFQUQQ6yOUCfdwigvyYlpCraGWs8EQRGOX6s0QLaW6ZG1lubhq39s6EgDoPPnTwgF5Fzmb+XXaB GALxIKB76XlcMOLJzXJpIgJ8/vtJW7miiShmILlbO9v6s5h1ZQ+ymAG17LKHgDp0LMosG2eT+7Kn PqtxShFwE79s6b4U6EfPtrEpqIZVoQwIWH+WDMhGlpPB1XLNFgIsq3SoHjKnmGU5W4qz2qYagRN0 T72ue+q1VNfSKmcIVBcCzNJkNQz6M1s6MybdGlmOCUjLJtMIcB8sJOmsB8w4I8yZ1qVVPj0IdFNV 5rOlxdKjEKtJs0CA/mxB15+Ntf4sHp0bWY4HR8sl+wjgimEz97OvR2tBehBgNj59jE2cTY9OrCbV jwD3nfVnMevZyHLMgFp2mUQAv0om+VkwBAyB+BDAT5Z5AEaW48PUcjIEGkLA+rOGEGrEeSPLjQDN klQdAj+oRedIbDJS1anWGlRBBK5S2bMZWa6gBqzo5ojAj64/m9ocG59Um40sJ4Ws5ZsZBNynWn+R byUrYthC7pnRnFU0zQi4FRjGutn5aa6q1c0QqBoErD9LRpVGlpPB1XLNEALqzGtU3VX0kGEtUguG gCEQAwK6r9ZTNkN1Xw2PITvLwhAwBIpAQPddF0Vb1fqzIsAqIYqR5RLAsqhVi8DcatnBesi8aWst V62OrWHlR2A3Ffmy7qsf7Y1N+cG3EpstAvRnh+i+e0vbSXbvxXMdGFmOB0fLJdsI/KnqT5Z00gNm sj1csq1Mq31qEPhdNWkraSWx+QCpUYtVpMoR4F5jYm0nt63y5paneUaWy4OzlZJuBOjMebCYv3K6 9WS1yxYCHVRd62OypTOrbfYRsP4sAR3agywBUC3LzCHwq2p8f+ZqbRU2BNKNwOOqHsvHtUx3Na12 hkBVITDK+rP49WlkOX5MLceMISC3C9ZYflguGLOZC0bGlGfVTS0Cupf6656yPia1GrKKVSMCuu9q rT+LX7P2IIsfU8sxYwi4pa1a2+S+jCnOqptqBHRf8UXMaTYATbWarHJVhoD1Z8ko1MhyMrhartlC YBFV9zA9ZE5Wxz49W1W32hoCqUXg/1Sz1yWvpraGVjFDoPoQWFhNOkL92UnWn8WnXCPL8WFpOWUX Ae6D+SWd9YAZa5aw7CrSap4qBOZQbebVPdXKfSghVZWzyhgCVYoAE/zoz7ro3qu1/iweLRtZjgdH yyX7CDAJye6H7OvRWpAuBLinWqSrSlabPAjYSkDVdVlwz1l/FqNODcwYwbSsMosA61KOzmztreKG QJEIyNLEEol8LGQ1yQuSJ2V5mhJNrjin6H93CeuPD5LcJMH/eGvF7ddQUUrfTnH2lLDOMm9qUrfG surIhxt2VN1uoD36jxV8bf1/qqH2+fNKs6D2V1CaZ7UPpstq/yztr6T94yUTJKzffqGO/9xQvq4O ayjeR5JtlOaWhtI0dF55/kNxFlRezxSKqzg7c65NG1TccJgxY0bQv3//YOrUqT5y2VzXVNdVVShv Kt5tqKaK20NxmLT9dkNxIzpdW/vMX3ktXxrnD3w5+brz/bTtLzlI8qjSjSy2rATjWX+WALhGlhMA 1bLMHALfq8bnSOqe/plrgVXYECgOgXkVDRJ3quQMyY+Sd3KSLq//V0h+kvDJ6oMl90hCUiTCQB57 SYaIHDyh/8tonzWV15XcJ2G5uI0lR0m66/yJ2n4sgVRASF91JI4PAA3RPq+MyXNFySAdG+QmBx6q /zP0/1pXLiR0FQlk8mcdH6F4B2i/RnK1/tfdvy7/LXT8LR1/06X/t7ZzSSDIfCwFYnSD4tLeeai3 9rtqu5hkOcmXnpTp+OGuXL6INpD8qJtkms7hm91TQn0JK0i+k4DhkpLTJEc6Er2Z9l9XHiHmOraf NnNKrpf4QUuN9iHNtzhytrHiv6T9BXRsHu1/oH2wBod1JBDi+3X8Rx1nEDS7ZBH976MtultBx5/T Fl2uLnlc575y5UM+/yuiPHnkyJHBM888E3Tv3j3YaaedOF0XHn744aB9+/bBPPPMEyy33HJBy5Z1 qwFS57bKf03l+Yq2h+l/S68zVwa6pe7g/LnOveeOg1c7/b9K6fhE87ISrjEv62sf3bOdV/G4tgih FVxpttNmKYlvO3kcKOGLkQ+4eD7u1i7/u3XuF6UFB+IvoP93uPwYLRxNnSSvKY5Pc1eEBIMtbfmP y/8Cbb+QcF0+pTQd3blfleZO/d/E6Y55MZyDTO8r+VjHGawmEfi8PP1ZvUFwEgU1pzyNLDcnbVtb 8yKghxYP55F0TNq315F2nVQtArq+v1bjvta1DjH9Q4L1NzeM04Fhisv64w8obh9tn5DsoH2I50kS 1lBeSv97aLumZD8J5PAYyWWSiUoP+eQc5Aiiu6gE8vwZeUk+lQyRLC65UUIHv6fOs5QjZBGy3s4R VcqHoH8guZt9HYeQw9q+kWDJhbhAoiDfm0g+lGyh/5B38oPQUyaWVIjKTzrXXdttJZ+4NJTJwIC6 7KjzYEBePCMg2xA/6k6AAG0qoT2kgyAT/NfTaBfxv1M+WLKpL3XaWv/BGKILaSc9dXpZAgG8RDLR 5UX7dld8BhtrSVbVPoN76kD+9OHkyQTli1xaPnPM84w80TdlQDhpxyuufAggb9PGS36WtbjlpZde Guy7777B4MGDgz///DPYddddwyo8/vjjweeffx507NgxOOWUU4JXXnkleO6558I4ChDOJVyekGF0 N0NlH6v8uR4ITDiDkJ4r2clhCm608Tf9P0LbRyXgzqCEdlJfBhAcY2Axm+Ix+Okmaa19Bj1cw7S1 p/5zTTAoYVCwsP4zMIDUMg8FKzADIzDspf/olrq9KJmg/3uprpTDs/8XySQdo35cM4Ml/9X/8xQH rGg0woCKwAANSy5t4fguLg114O1KK20ZQHBNPibh/qAeG+s4/c3zLp/YNtafxQZlvYyMLCeDq+Wa IQT00KpRdVfTQwbLlwVDoDkgACmjc8/nfoS/Y/SdPGQAIoFLAQJZw/I6TALJ3EByle6fB3UvbaV9 LHMQDgjP5xKIcg8JrgCQSsg25ALyQCD+I1gOlQZLJ0QIMr6PBLIJ0eDe5PX7/YpD2QRv0cYavLI7 xgaXB1bggIySH8R4qGRDCeTTW8k5B4kDCyzLECqI1TOQJwiS9jtLsF5eJ+kr+V+kHPCDGDMYWFhp /MADjGgzlj3yo+58KIJX+xBBrL9gQZ0gdfTDd0mwWpJfnY+38vxT9eCDSSe7PCDtJ0jQAZbWLV39 yBedYTE+U4KlE3JO26mPdwMBO45BagPlj2X/o2nTprUaPnz4Drvsskvw1FNPBYMGDeJ0GL777rtg iSWWCPbYY4+QNE+ePDmYbbbZgokTQz4PIYS09pYcJ/lNAi4MJHwAg8ccpgxosLBifScDpLsEfT+v OM+pPtT9Wu0/qv1dtL1c2+11DNLN4AWd0B4GAbQH1xnyGeryHaEtrhe7S3iLAmnmLchD7vokPW8N 9PdMrgmIMVjwloB0kGJcbIhDGizM/n7gXoCwQ4q5J+5QHCz6XMPojWt6DwkDQwajV5O1BFLPoG4+ xT9d8blmaU/swfVnq6ucpCzXsdc5CxkaWc6ClqyOSSOA1ecgPWR4PUpnZaGKEZCescj9IF03u9eU rpNur7afp30swLgJQC5yQy0HFAfSAHkAq1YS7g+sdxA7XAogYlhuwZQAYUAgKYdIekiwFkKiIXqQ c0jOd6qDf4sDAVnIpecYJIPX4bze5rh/5+/jc4w01AfLNNbiL116Nlg6IdoQsNC6J8FCSF3x2YbU YVmslUCA95NAcigHoXwC6SB+9JNYECFA7SPl+LZyDKu1D1hbIVG8hocYXiOhjtTlScneLm8GGpRF fCzjWFJ9W+v8HHQMYst/yDj7EMRvJZBhSCcEGX2AL7hQZ9qJzigfvHG3eVpCnbF0Xsgx1Y98ad90 ZynWrjL4y2pct48/84QJE4JRo0YFrVu3DqZPnx60aNGC8ogINrSDvNAZZUVx4jzXEQEdEo96oDOs 8QNdfP/sBXevA64jAviSD2kh36R71uV3rLZYlRmU1EgYJO0kwXoPDr488iFvyiYvAvhEnwP8J10U f9L4QNnfSrcnRo6xS560DZccrMUMlrhvyIcBze0Sf836+NEycrJr0l8GmwfSn2mL25C/b5qUaXNP bGS5uV8B1n4Q8BaiTnrA4EdpD5cqvC6k2/nUrCMlEA6ISbMjy2pzjetI0TAkF5cMLGcf6Lr31kfI 2wU6TmcPCbhK4q2mWNB4ne8JIkQb6++6io/V1VvmIBhYGSFOWHC5xzo76zPuFP0ilxgkltfWp2sL UaEeEEAsjHNKIBkc+0FxeI3dXQJpgfxBRLAKQzx9IA9IeQ8JZAs9MyiAsFMWhI6+7wfJwxKstutK aCP3vrfssg/RfFBygAQSErW4++cE2+gzg/KPVl2xSIMTZVAP8IZEsaVOnMe1AOKGBT6aT11+wuxD 5fUvnf9IAgG6Qcee1jFwxUrKQKU2Um9ImE+PxfWfkpckm7ty0Yl38yDeEm3btl1k/fXXD0477bRg 0qRJ9XyWN9tss9AV46uvvgrGjh0b+iuLKEOaIbfkNVT1waUFCy+uC7SL68AH2rqgzp+hrbdyM2jg jQQDkDckEO8o7nXWdZdJFOswPwnXLdcoFlvS8yZjDkmN5E0XB/zZ31/l4wYCMY+S4dxnPfXbX4I1 eG+lwbXkXUkUL1wrWuT0E+RDHdAjbyi4T7gHqONREnCB8L/j6sF1xBuOJAL3C7phoGDGn5gQNrIc E5CWTaYR4KHGg8VIcqbVOFPl6bzCoA7qINeJQXxeaa5vENTu74QF5HdZCZOMxug/xBPS4QPk0Vt0 eRX9s+Jwj2j3bHw8b3RYYp3/Vv+30X9cArB2vqlj03Wst/ZPkuBCAPG9RYKvaXdt6cAhJT7wSvo1 CeQX4gXJ7qe4I7XF+sh9GbVgv6r/kJXXFQcLZEftcywMrr5YcyHIN0uYcDZecSE8sxPXtecS7fPq nbpCynGNIA5WZwJbSC6DLJ4PkOuhvhxtP5bQZrADUx+wcP4igahh2XuHEyqHOi0mya1Tp0idLtJ5 iD7uCtHA6/zfFQ+3DEgn7RzoBjT8ZfAHrgxYGJhQJuSaup2luIMVF5JI+e/46x/Cp+NnypJ8wqGH Hrp2bW1tMPfccwfLLsvl8VdYYIEFglatWgXt2rULNtxww5AoH3300cFVV13FdQMRfdTV50llhbsJ eHPcB/TL/yckTL7DlYJPoVOftk6PDEp8m7m+PMljAEVANxBo7uk2SjNa6bkm0A1vBMHlVu1DwJlc 95n+89aBuuAXTZ4Q7Deczs9y+XLd4UbjA28YvlKcT5UGPZEmzN9F4Ho4Hdwiadg9RzJKx+9SOlxr rpVAmHmL872OYbFGKA9SP0zHh+bkEddf68/iQjKSj5HlBEC1LDOHAJ3yvZmrtVV4VgjQqTFLv4e2 WIogMAfl6eSaHYrCgOsdCYP+Y5mrC64Tr9eRO7IQumtoH8veK5EkvHaGyEFOfJ6sOID1cIyOf+CP 6xhk7Todg1T5gIsC8bD6RetRR7iUDgsqVkOI9LuKi7UvJIzRNJHya7UfJUHE/TByHvLzk8sDQhkd LITYOJwgubh1EBeiBikNg85D1L27QJ0Fzx0P6xcNEDz9R+pCFBuHMSSb4K38viwIpt8P6+3qUId5 Tjqs5P5tgMcKso/k1gu/5a+wGEOGc8Mvv/wS+iizZNzBBx8c1NTUhFFEmrFgj1O9o3WLWpR9Vljy /4ji7+peh5G7psK2R68N7XsdQaxnqrcORK85CGzddam0vEHyOHGN113nOuevZZ4T3tWDsrkOwsGN uy9y7w2ugTr8I/lHdYL1P7euUX1E753cqHH8Rx/Wn8WBZCQPI8sxA2rZZQ8BPRRrVetH1GGwJqdZ l7Onwnw1xpdzOQkd+mVRIlcdzUtPK3JJUIRAvJiHNNQR50i877WPFAwqA7J0eSVarbKfU7lINYcW nTszHpk5sFQckhs6dMCrIHxbwLrEvPrPG3RuuE4gFsqAgPDGzcf6s5ixNrIcM6CWXfYQ0MMeQsUD 3/y7sqe+QjXGPxELDoRtD+kYwowLwZr8jyR6QcdZH5VXvKdI8EslYDE8R+cm6tw62t81kuZZHedD FFw3TCzC4knAekQaVoLgdfCOkTR8/INXzzxzSVPjzmHJIs0UnWPC1g6RNI/p+Ms6zitqXkcziYtQ KzkXgqJzm2l/20gaVpXAzYBX5KTh1S8BiyZpcJHAdxfx4UEdf1PHYT+kwX2AgIXqfAaQOoerBT6v Ptyn4/hf4p5AGl45E37R8fB1us7trA2vnP0AlOXKcB3AJxoMvP/vCB2/2KXBNzdq3uyjc6y7zKt8 0vjJVriAXObSsDIBPsc+3KJzvEbHtYI03v8VF4/eLs3u2q4VSXOjzn2uNHPrGNeBD9/oOC4QtGdv bVaLnMNCjlUWn21cTnxg5YXrXJp9tV05co71oL9RmgV0jMlgPnyh4ze4NPhHrxg511vnhirNwjr2 38jxT3Uc9xbqdrA2+Nf6wPWOjzc+wfh5+/CRjt/u0vxH22XciVWOP/74SV27dm0pi3GdwUDW5BaS VrI6z0SG33//ffyXNdevztspUoztVgoB68+SQd7IcjK4Wq7ZQoBO6HA9ZE6CTGSr6lbbAgjwKpRX zvg18tEC/6oVH1h8EX0IXyE7Qog/M8SUwGt671fLpJ1oGu/CAKnAVzeaBhcFAq4FuAz44F+vky+v SD1RhIR4IoIPbJ17hPb9q3jO3y3xz2smhHkfykHaj74W9vvU4y6JJ5f89yQI14Xo6/jwlbRr7x3R NODizuHSMDTSHiZ2ERhg9pEwcPB5+GiQXrDzr529dZFBxW2RNNFB6ls6HnUt8PVEf/ikeuLr3R8o C11/Fqmbt1IzEEFvPo2fpEVUfJw/iaTx5WCVi+rauzIQ9WVJnSuH9j0GvO4vlIbB2vuRcrx+uDai aepcAXT8BUnoCuCCvya4VqNpoq4jWL6jfsLezYXrLpom6s6AHzA+tIQ/9eERBn0MSvwzkOuMZyOD Ecg/11z0zRu4DpV43UeqbLsVRACdHaH+7ETrz+LTgpHl+LC0nLKLAPcBE0VYwH5shCBkt0VW8/ME ASQGy+b/Sa9M5vpeUqv/yExB55iIlu84+dT5P/oI7joplGYm/1TSuTS5fqZhljoHgYoSbH8c8gLJ z1c3SFHU/zeaBl/RfGkgXXV+ppH2QIYKpann5xxJA5GHEOcLEE0mdA2OntT/gml0jgFCPX9dhw3E LUqI67JUGghoPj9SBgiF0jBA8IOEaF4MkOrVN9JWyLEnyMWmyeuCoDozQChUzkx+xQ4DBgiF0uR1 Y1E5DBAKpRmWqzTdJ35wxSmuO3zMeUvCIKZWkuumBmH2A7cCl4EdLjMCDF7oz7pIn7XWn8WDvpHl eHC0XLKPQOiKkf1mWAscAt3USTyrfVwFVtH2AG0hiLw6N7/08lwmEK+OuJ44glyeUq2URiMgPdUj vtId/3kuTjcdNhrWSiRkEGP9WYzIG5gxgmlZZRYBrFYzWdoy2xqrOAjgZxuSNMkH2seKiD/wLdpn qSv8jgtOSqpmCJ1PI9ZCfLexYl4pLKKv9MPmKx5+s0dIeHWPvzMuCg0GpcMtBR9eZoU9XSmcVY+F qIPKb3BynuLOr7grKS6uCWUJTg8Hq0yWNUtrgCzz5iLf2sJprXNzr5f1ZwlcAUaWEwDVsswcAhAG JoTxkLFQhQi41/s3OqK8hZrIBLion2gVtrpgk3juM8HsRMn2EiZ6XRKNLZyYlMakvrMki0hwZcEq P0Jb4neUsDoFkw6ZJMbretwneF3PWrX4bLNO8TDFX0NbJgBi0Yd4Ex83FXyZe0luV76hK4niMrkQ ks6kOQY7fd1xJv4t4eMq3trax3qG4O7BZD2ILm3bXukou87HVvFX1/+NJC/rXOhDrGNHaoP1mwl8 DJzCNw7uTcSm2n3RDbSY1McAgHYwQa/O+qq4q+rYShL8n7+VQLrx/cVXmOuLAclHSvO84v5D+1x3 rMPLZD7yO1LH39d5/MjTGHA7sWdjGjVTuE6mswT0ZWQ5AVAty2whoI4K37xR6rRa2Cv6bOmu1NpK v/jeMlmu2QZhgC/vPbreu2vLihEz+eHqGCtsfKK4oT+w4oIbq3wcri0uS5BdVllgguM9EnzEWc0D gghpZiIcE/zI+yAJ5BpCzuRGiCxfvfi35CnJscr3fyoLf2H6JFZrYD3jGh3HhxuiChlnXd5jdIzV NiC4TGAkf1bjOENyqgTfclabYHUIJsltrH0Gw6x+8bhkHf3Hj5hVKthSX4g4vtqb6xy+4XtKmCy3 pyufvBgU4NZzvOQiCaQay/luEsj3nZKekv0kS0qOkzDYoM583ZBBAiuxsELKVe48E/l441GUxZ4y yx3s2VhuxJtenums6Rjmy8HIcjK4Wq4ZQkAdGTPAV8f6k6FqW1UNgaYigC/3UpLoKgo+z3q+q7o3 sJp6gohFGRLN0m1YSrHA9tF9xFJoLD8HQRwkYdky+hiI9ZUSSPTbinur4h6t/Ze0/4D2t9a+n1iG ZZmvrF2t4xBaLMxYj7HgYv31Vl6stVcqznY69pD2H9P+P7V/k4RJbZBaVnogDWS0VtKD8iUQfyZm YunFos3ya0tLIM4sNjxV+bFOLdboLpLQ113yjaS3xIca7fCFuAed1Zi2Q4ov0rGvdIwVTzZ35bKa CBZwrPN9dY4BwbUSvpD4dSTPVO26Z+MaqmODriypqngzrozpLBnlG1lOBlfLNVsIzKXqMgHsNXUK 0SWpstUKq60hUAQCus4hpks4QoivMq4Y0aXKyAVr7ILsKD79RC/J/RLvrgCZJh+szH6JPcghrgwQ Xkg0gYEo+1izOe7jYi32y5jVuUDoGK5Q86jMTm6fMigfogqpxxJLfL+8Ge4dfuk56sQ+hJfyqBt1 qpXgogHp3ksCKYbQkxfuKKxd/LCLTxy/FBpbhDZRL6zLUVctf06Hg+7uHHFZm7tGW9xVwAx8qRvx fV3Jh7qXZdk11Yc3CHxFL7p8HvVuKHRTBJ6Nr1J3e/PWEFypOG86S0ANRpYTANWyzBwCvpNl5r51 CJlTn1W4RAQgaJs6yy2kFcsoVuY2IkMhadb2Lh37t+RCR+qe1BaXB9wmsApDCvFNjgYILMe9cA73 C281jh4nrl//OLq2OfciFtpTJPRPrMfMFn/lzSQQXPLxaaJp2fcE1tcFUgp5xuoMycbKjWUZC/U6 rg6QcE+saePvavf5bCX8h3DnqysWYT780UtbSLcvk/YyKGDAQRkQZF/naD4MzFdU+o2E9wDtJxk2 1MdGWHv3NpWF20yxAcyoJ4MXT/SLTWvxKoOA6SwB3I0sJwCqZZk5BMIlrlyHlrnKW4UNgVIQEFma KtKET/C6kpH6z1fo5tZ+dI1dCPOdOs5kNNZq/dSV8YKOQTjb6thbztUAf2UCLhB+LWC2+CRjWcbH GHcHyOQ5Li5uCH41EnyOPRHjPsTlA9cIJviFa1IziNUGl4w38cnU/zNdPrhOQfgJ5E3dIL74RWO5 ZkLeSNdeJhbih41bxjM6Fq5prf/vah8r7+Xa/1X7+EMvLxms/2P0H7cT0kDk/+fKYkNZWGoXlrzu 6oG7xkTeULl8VtR/3C2o0wcuD9KeST0UB+uzt7BHso59d0Lv3r036d69+ybXXHNNrxdeeGEvj20D JdmzMXZVJJ6h6SwBiI0sJwCqZZk5BJi53qwnfWVOY1bhJiHgXqdD8MIAocyXoY7XxYnErVu5AeKt 42Fa7UMeCaErk4hgP23G63j04x/hlwwhoZH88GX2oVY7fEo79JGOxMGKW+fbq/NhGm1xqQhDThvC 1TUUfN34X68tkORIWizBPi51K4RNWH8XcCvBCk66d5TfoJw6Q/Drysg553H4LHo8wf0W3bp1C7bf fntktRNOOOGZCy644N5JkyZdoHrPyjWDttmzMUHFJJC16SwBUI0sJwCqZZktBJyliQlC7RyJyFYD rLb5EMCdxlsuDaEKICD8B5RaLBZZpXm51HSViO+eG6xskYXwx+TJ3l08CC6++OLF9tprr9POP//8 /WRxvnjMmDH91B7cRuoFHcPqnetuk4X2Nts6ep1ZfxbvJWBkOV48LbcMIqCHSuivqIfM371JBtth Va6HwCHSK0uZRX1aDaLyIoBrA5Zn3Be8r255a2CleQRwFakXVlpppeCBBx5Y8Iknnrjqjjvu+L+r rrrqpVat6nni+Pjh+tO5Ovz9998DCR+rSe1qHs1R/dafJaN1I8vJ4Gq5ZgsBPrrA5JcT9OA3cpUt 3RWqbX+deNoRtepoUfZagS8yy7cNyF7Vq67G+J7vkNuqvn37Bo8//vjzb7zxxsIPP/zwviussELR Db/wwguDyy677Ak9N7+xN3JFw1aOiAyMjpJe/s/6s/jgNrIcH5aWU3YRwJwyj6SzHjBj7cGfXUVG aj5MehxcFS3JaCN0Lw1V1X+SHvjgh4UKIiBdzD9jhjcQa+HoX38Nrr766h/OOeec46Sfh37++eej 55lnnivxay42dO7MIiOhzzbPT3N5Kha45OPxppQJu12kdybn/q345Muu2hKMLFetaq1hJSLg13Mt MZlFTykCbdRRsJqCdeKVUxDrK7Mco+mhcjrwJbfu2rVrMHbs2KBPnz7B5Zdfftf333/P6h+DXISa KVNYmrr4MG1aeGvZm7jiIStnTOvPYkbbyHLMgFp2mUQAv8roLPdMNsIqbQikDAG+fMdKC+avXHnF dDzvvPMm3nDDDc88//zzV4ok4x4TDWZ9rLyO4qqB9WdxIRnJx8hyAqBalplDgFngrNFa7xO/mWuF VdgQSBcCrFfM8mpGliuvl2EDBw7chhVK1l2X5bUtVDECfEjH+rOYFWxkOWZALbvsIeAmQYzW6+IW 5t+VPf1ZjdOJgO4lvoDH1/CMLFdYRdIFH0Sx0AwQsP4sGSUbWU4GV8s1QwioM59D1V1TD5lnMlRt q6ohkGoEdF9togqyUsKwVFfUKmcIVBECuu/4auZa1p/Fq1Qjy/HiabllEwGmgO+rh8wA91GEbLbC am0IpAuBf6k6A3RffW9vbNKlGKtNVSNAf7af7rtXtP3D7r14dG1kOR4cLZdsI4CvMp+mZeY+X36z yS7Z1qfVPh0I4IbRRmJLi6VDH1aL5oEAy5TwJcyObts8Wp1wK40sJwywZZ8JBOjMebAYSc6EuqyS GUGANXitj8mIsqyaVYMA6yxbfxazOu1BFjOgll0mEWDZuDszWXOrtCGQXgQeUtWwLptlOb06sppV HwIs2Wj9Wcx6NbIcM6CWXfYQkNvFWNWaz7a2MxeM7OnPapxOBFjLV/cURNmCIWAIlAkB3XfjrD+L H2wjy/FjajlmDAHXobe1yX0ZU5xVN9UI6L5ijeUpuq9s/fJUa8oqV00I6L7DDQPDD37LFmJCwMhy TEBaNplGYGHV/ig9ZI53a1RmujFWeUMgJQicoHq8Knk5JfWxahgCzQEB+rNjXH9mA9WYNG5kOSYg LZtMI8Cr4rkknfWAGWuuGJnWpVU+PQh04r7izY1Zl9OjFKtJ1SOAZZnl4+jPaq0/i0ffRpbjwdFy yT4CEGa7H7KvR2tBehCg0+aesi/4pUcnVpPmgYD1ZzHr2chBzIBadplEYIpq/VMma26VNgTSi8BI VY3VMIwsp1dHVrPqQ2Cq9WfxK9XIcvyYWo7ZQ+AHVflcyfTsVd1qbAikFoGrVTMm+RlZTq2KrGJV iMBw68/i16qR5fgxtRwzhoDz6Roj/64W5t+VMeVZdVOLgO6liarcRO6r1FbSKmYIVBkC1p8lo1Aj y8ngarlmCAF15nOouuvoIfNkhqptVTUEUo2A7qvNVcGvdF8NTXVFrXKGQBUh4PqzdXXfPVFFzap4 U4wsV1wFVoEUIMDM4b31kHnR1qZMgTasCtWCwPZqyADdV8PsjU21qNTakQEE5vT9mbZ/2L0Xj8aM LMeDo+WSbQRYi3KSpKM69kn2cMm2Mq32qUFgtGrSVmKfu06NSmKvyOTYc7QMm4rANEgy/ZnbNjU/ Sy8EjCzbZWAI/NWZ82CZYWAYAs0JAQ0Ot+Xa1wDxgdx269xsOraFpIM79yOfsJ4VPkpTo/NdJL9J 1pJ8Iinqwwju9TF1YcJtoP/zstX/nwuVqTgb6VwYT6G/4o7SseW0/632GQDHFpRvD2X2hWRByVDJ kpIvG/MhI4cTzxxWC6kp1lVF6VZQfPQwZlYNU7yldf4byYqSD5MwALRqFX7JfCmJ+aTHdpXFkhFL Nlp/FguUf2diZDlmQC27TCJAZ3x7JmtulTYEGomACNUOSgoBnKr9/4hQ3ZCTFcTseMkj7vhKije7 4j2tLZ3xnNr/3qfRMUjk4pJNJFdJ+ks+l7TWufaKO07bBfR/uvbDpRr1H8tzV/3/RdsdJcvp2P+5 j5gcqP90/OfoWGdtIZXR8qjDGZLHXR2OVrze2j+OrCXD9X8hbXkVDYnu7OoAuZsNlysd42tnv2kf 0kp9YIB8RGWKq9s0yLD22+k47lrMbzhHwuo5h0nO1znaU4/Q6xgDjG6+vi49S1RSdhvJVpKVJHzh kDbfq+1I127qAZZTwUX7bbRFR3zkZW7agx60xapL2b9G8XFE/AKdO5r4nii7to7R//G0zbVxQW1Z PaHegGb48OHBggtShb/C999/H3Tr1i3o0OGvcdOoUaOC335jPBTsJbmYnWj+dQltpxIIsGSj9Wcx I29kOWZALbvsIUAHqlpDANolYYHJHiJW42aCwNu63h9zRAeylkuWWfbtWcXp7eIwYW993Sfva3uI ZE7tD9L2Qcnakp0lpIEgw7S+ksCuHpL0Udxh2h4ggXzSmX8rOViylP6zzNxqkh6STvo/nrIkkEQI L8S0Rvt8OvtR1YlXzVi+B0fqd5v+Y9WeIIHsbq0tpHSyK29TbV/R/5Ulw7TPVzs3lkA2b1E+WLSx hm8kOU/CQOFJnRusbUi+JZBUBhGrSyC+xGmjONcr/WfahzQups3+EtrxkbZY7UkPwcYavakEv1La x/k1JPNJvlb8O7WlfvtJaDuDjpbakvYeCYSdtNQbXH7XuVO1ZWDRXvvPaQvxxbK8DnF0bIC2/3Ll jdH/a7W/gbZgwwDmUW2nt2jRIpgxY0bw4IMPBs8880yw++67BxtuuGFw7733BgMHDgzmmWee4PDD Dw/GjRsX3HzzzcG7776rZCFhb6s8yJ/yyK+PsPiOkxbKjwCDIZVq/VnM0BtZjhlQyy57COjhjjUJ S1NoXbJgCDQHBJzVElJ1iuT+PG0eq2M76f7AGgxJw6p7nWQDCSS4twTi9aJkD8l/JFh1sZxCZHGH YCAKscX6e5PkVgmE81DJNRIIK4SzuwRSzeoZlAvppE74PW8m+VTH79Wxu7T/vIQ43K8rOPJHkrcl WKgpn76N/SskkLidJAwM9pNAJiCV+yjPA5X+GFcGBB6Cv7GO7a0t9YTIQozfcHFox7MSttu4/HH3 gBz/H5VQwILMyjpYmy+SvCDBMg65xkINdrTtRwkDhtaqx/FuwDCP/lP2fyVYvf8tuVuCFf1pCaT7 Y8U/XPEP1z74UD7W/18ll0jQA1Z9BAsz1vDNleYApWFwAknHoo/FHWs8aWbgVvHnn3+GRPn2228P 3nnnneDHH38MtzfddFNw6aWXBh9++GHwySefBLvuumsw77zzcg7d1kgYKJ0ggbT3lIC7hQogYP1Z MqAbWU4GV8s1WwgsourSafyXV67ZqrrV1hBoPAK63r/UdQ+xgaB5dwafIVbidySXSrActsBiqPir aB8CiosEPsm89sXfn3vnKQkW3VoJJBiL8RPcV0oHQdtPAtHFQkz/Q56Q10+cdTLaGEgvAUupdxOA nPkA8cQaTP0IQ3kz5MgC8SCou0ognR9LsGyvKoFMYhH1ebEN81f6kUrPOSzMWKgZKGD1xdIMyaTN CAPsEYr/puIzeIj6R0OKsfx2lWBhZ7IVgTjkTVm+bbRhgDvvMeQ8WCLsE+c1lYX7BXljTYbE46Zx v/axVkPcIeEQY9IQj/S0jXyjbeU4xyDfBL74FjogE1q2bBlgZV5rrbWCIUOGBK1b/0UTINMcZ+v8 lX0S2gRGWP+pa+515OPZtjwIcL33cv1ZUfMFylOtbJdiZDnb+rPax4MAnR+dTGc9YMaaK0Y8oKYx F0f0cBm405G0NFazLHUSFlhbww+HUKAjs/M4dwQOYR2e7AgyhPoWxWEyHcQLy2xfCVZXSHWtBAKN lRbrLAGyyH3lJ6NhmX7JlYe7BPm0UJ5MMoRIYileVv9xhwpf70uYoPapZHEdh+hSV08A6L/wL859 5Y8VFjIKwb9ZgsUXf1/0jjWXemIphnySJ9ZtjvuABfp0yZUSb4XFQRf3B0gofsP4ZuNmAUbUgzJ9 gMhy7BnJdhKeL2AAAYdQjpBAWJeRQPZrXELygLRSFnXFmj9KQlvYJ0BGGQQwELlH5eMSQnuIh5sI EzIhwrhodJdQP3DGFYW2Qmo/kNAW6kWg3Mm4YBA6deoUvPTSS8GIESOCjTbaKCTPuGGMHj066Nix Y9C1a9fgiy++CIYNY+wREnTqN1CCGwxt8vm67G1TZgS4Rrnvukjn+Kj/pVgLTULAyHKT4LPEVYQA 94LdD1Wk0GhT1Gksq/+7SSAdvNY2l5u/3AMgXRDJsxzxgfxC4AhsB7DjLLa4TeBa8YRLg4WW1/9Y hrHuQkofluB+ADn8UMJEPsgZAZcE/GvpvC9WnmOkF/KH7J0vgYijl5C8SXCKxb0DSyWv95lM1lvp sPgSsNhiyc4NHKuVnCOhTpBfyDiT2vZUmZSHi8X1EtxBqF+dNVRxhigOvtpfQdx1Dos1XyLE/QO3 B6ztuK+QL0QU1sggwAd8gCG0/5CcJaEt4HOyhHMQWwYO1Ik2vOIS4t6B1R23iLMl4EobuktwdSFA wBmcUCbtYDBBGegCFw5wJE/aBKGnjpRHWw+SMPCgHVjDyZ9A3mvggoEV+bDDDgtuvPHG4Ljjjgsn +e27777BPffcE6yxxhqhtXnNNdcMrrzyyuDtt/F6CXXEm4UbXR2+1pbrykJlEWDQVfe2oLJVqY7S jRxUhx6tFU1DAB9DrD0WqggBEZxpIjhYubDurSRhCS3IgwUhICzwJz4jBwzIbxh0Hn9axP+H/Ppw j3YQHyBM3mc3PCbs8QH+Rvm86vKDnJ0ULU/ncAXw7gCUhWXal/eedhACFuJ6AQKrA0xMzD1+nzsA 8caPNvf8m5ED+AbPFJR32DZtIZe+PvhUExg0RMM3+oP4eFiNaXtuyK0LA5W6oLJ8/hw7LnKqLn/F waJPyCWk1+YUBsmOBiYfRts6IFLfx6UrSHcYll122aB37951aVdfffUAiYb//ve/waRJkyDM+Ga3 VL2+yMk/p3j7W0YErD9LAGwjywmAallmDgEsaOdKzF85c6orWGFm5W+ls7wSR69XqkMPJ45ZKBsC kErvm1u2Qq2gRiEwBReLUsL06eHjEiu3hXQhgEuR9Wcx68TIcsyAWnbZQ8D5dNUyecb8u7KnvwI1 vlzHsabxypxX1+Gre+mYCVv4efrAxytCH1udwz8VH0wCk56YVOWXLsP9wIevdfwbN9mKNJ4wYNEh DRZtJtng+uEDqzx86yzdpMGXlMAretL8qXPdtc/rfR/44MVQHed1KmlwCSDw+p40TJpbTPtM8PLh cx3/Xsd5tnt/W87xap40M3SO1/NLRNJ8puM/6DjEljSe4E7U8deIp3OUQVk+sDrFjzqOXzFpfF8y QcfxBybgH7uMi4PrBas4/ORcG0jjXxOP1/HQ2qtz+Lwy4daHj3TuZx0HLz/BjnPjdPwtlwbd4KPr A28QmKiHXkiDDyehVse5HihneW2YfOfDQJ1jLWYY43qR4/h84mpAGtwq5o+ce1/nftNx3FjWjRxn 3eb3XRreaOBe4sO7OjdGaXADwY3Ch1E6jt8v5fTQBpcKH97ROZ5P+Hnj9+wD6zKH1n6dY9Ilvtc+ vKVzDBhrdGDNyPFfdHyQS4MPs/eFXv39998Pl4UrNjifZeMQxQJWpniuD7P+LGa87UKPGVDLLnsI qENhsst6esjYK/rsqa9QjSGDvBqGwG4pGSLhtTyEIkoeOO8npEFsmBhDgJBCxiDNTOiKpuEcr8Yh YT0kNS4NbgGQPvxYIUjRNJSNmwFpVpbg00qAxEMumbQGuYymgbkMleBKAhmClBE4/rrbh7xF0+Ar jD8sRBQy5Ml/rUsDaYUkRtPg08rbFfqD1SSeyOOfG5LlPGl+0TEsWBBr3tFDmgm/SjxZ5rU/ZMy7 cuDqhA8zcUnjSTl5edcIiHK0btQLH2gGCrwl8ASbvEKyrNBdQr19GKod3EJoB3l5sjxc+yFZVoD4 owcf0Cc4+DT+OL7BIVlWYJBR566gfa4pJuNByqN1ZsJhSJYVuA4h5j5wTaIjSHk0DeWHZFlhKQmD Bh8Ga6c2TxrK964xDLKig6ZP9J/rBFIeLedz/R/kMqYM2kQYvMcee4Ap15ifEMY1ySRNBglep5Fq hbiCqU3oi6JS4X31ZzzD1rf+LF5FGFmOF0/LLZsIQJb30EPmeT1gsMBZyD4C+M9eJ31CYOuCs6oN ytc8ncv1RQ2jOYufJzLRvHgPfVWBvCBYnmRF00BAehdIA/nzBDCaBsKOpXymoLpBmj1xjqbxk8ry pWFCmZ9UFk3DtX9xgXJe1nGkXlD5DAIuzJdGx2grH6gYED2v//guX1CgHHxyvV9utG640JxXIE3U 7zmaBlKa67sbnlcdmKSI5LYH8vu/AuX003EkNw0DhEJp+uockpuGAUChNA8WKB8yWyiN99POLYfB RqE0UZ9z//VCSLwny1x3EHDupdMl6Dq6sgJkGUHPFtKDAP0ZE1nxa2ctbVsNIwbdGFmOAUTLIvMI 8LDHWthRD5hJ9nDJvD5pQLiCQVW0JLuNoJOeF5cQ6cKv85vd1lR5zaUjnoP1/DCkO/5znCUEi/fR qHKsUt487jUGvgx8zPgTk7KMLMcEpGUTLwJ6SC+rhzOvDOsFHccXlDVI/WvfNxWPV5i58Xj9vJDO fVlEzbAQ+vyKiB5fFOcHyaterAG8ou4u+b4xRE950WZey2OBWlh58Mq3weD8RPEb5bV6wYBOdBKX BdwV8FnFehl7cJgMcfn/6T+KUGJBrZRPCwY+zj/1u2IwVVxcA5ZRXF5jh0HHFtWGQRT6yRsUB9cG VgXABcLCXwjgnmB9TLavBvSHawaf3A7vp2w3p1nUHreY6BuCZtHopBtpD7KkEbb8S0ZAD+UjlGg/ Sf31iv7KaXcJE7T8klIHKz6ver/QFqKIFQvCgg/jYTp2iLZYRaZoH79HRt28OuSh31nHeVULWX5c UjcKhzTpHJO7FtE2XH2f4IjTaB0LV1bQf3xgsUozsSnsSFwcJiDxSpf/PLxY43WS9iHlM1ze+Efi X8Zr6dMkLDe1vYSPDVAGr1DrgkvLBLXhLj1kBMJKud4PdB/ts8zW9oqPiwD1CNvl8KFdw7TPxxyY VMZDFb/S1trneQA+0yGG+k/+82r/O1c2r7R5pQuxD/1AXVtp+6/EcThDHPm6Wb3VRQpgyaQrdEBe 5IsV60gJS5rhyzrnb7+FMNYLTETi+KKLwmNVYc3Mnzx5cjB27NigQ4fQTZdrAX2jm8MlNyh/ygox dW1lUthP6MUdA1twPFrCdYXeyKenBB9Y9IK+O4GJr5COMYDbVELB185U2eZ74AE1Hes+fsZmWc7m dcB1f6vESHJ29Gc6S0BXRpYTANWybDwCIh5MpmKWeKFlvnhoQ47DjwAoPj6WczliAzHGAgLpZEIU k15YPgxGRbxeEvwbITZYR/sq7g7aQsoglHNHSBBEu4eO8TGCZ7TFX3NPCdbVCToGIYUEQKwgePPo 2P7abivZUALRvl35YdmmfD4agO/fARLIPPWAIMMEmURDfZjpDqk4jDyV/m6lD31Ytc/kr/0kEFtW O+ij7TES/BshmwdLmCzGpCXi4mvYSzJWcW/QFmJIHdo6fPjwAm3oJ8Gaij8iE8IgfnPq3KHa7iaZ Q/t84AArP3kyWaiL5A0d/6e2tJeBCCRxQZcOCzUfdLhH9ferUGytYzvpGDg+LGFQAE58uhdfYYg1 WLKl/uN1fCNZldfr06dPMN988wVLLvnX/KXvvvsuuPPOO8OZ+yuvvHKw2267BUcffXTQvn37oEuX LsHgwcyHCjbjR3ncqA2+lwzAWD2CawOd/FuCXhgU3KbtPD6OtlxDkGb0SaHINTrGZC2uMazWL2rL NbizxONmE0RDDf0VpHs+Bc2Aw0+wi5y13SwgIB0ykH9WeuSrikaYM6A001kySjKynAyulmsjEHAd K0SZmeR+Fn9uTlgBT1BcSApWPsjXR5JzeahLmMF/HHEkkFDOkSeBmeGQIIjRh5LnJRBYrJi7SjaR YEUhQNp/1IPndJV1h/YhRp9KIElYb3EFYUWDVyW8soeUkf9ekhMlO0n2ljAxhpE+ltf9tIXstnP7 1AGSzESMRySQSOpOnhw7X+InfE3R/gAJE4OoL1ZQLKfcwxAS8qWeNRLyhRifJTlFwox36gOhHSq5 QnKmBHyelEAcsboer3r11D6WYUg8bWUgQT0GSMC3nwTrMm3dTWn2U5ottA/5hVRj2Scf8AAzv9IE bwSoEzPr0e22ivdvxdtD+wxe0OsgCRPPILToaSet/TpIluI1+ILYWWedpUOq1IsvBnxt7MgjjwwO P/zwYIsttgh++umn4NRTTw3mnnvuoHv37kS7TLKjJHzbIBkg4Vo5WXKdBP0xWCFTVh+AzHMcvR/k tiupjoerjvfrPxbS7SRDqILkSslAycaKc6AbePjVHcJ6NvcgTHh9j/uKWZUzejFIhxgE2vtBb0ab 0ayqbTpLRt1GlpPB1XJtHAJcj1hIIV0b66Z/TA9pCGo0QKIelWDthegOUhzWEyXtLhLIZH8JLg5+ trbvrLEwcgxrJ2SUzpwVC1gyihn9kCQfIKeQaYKf7b2Y9rFEY7UmHS4MuB6wfi6WV/KukWAZhsBC RLGwYSWljDVcWVhmWbbpJgnWTeJ60sskmgEu7+jkDDotrLrzSpaTYAkmHSSTutJG73dN21mbdbJ7 cFJ/xFuGiAvRZs1X1oklHXWENC4iwX0DS/RGkhp3jDKoA3mAI8FvsQaTP20AewLHom4YYR1U3jsq h0GGx5StT99B51m79zNX1lxyq1hk/Pjxwfbbw8X/CrhZvPXWW8G0adOC1VZbLaipqQkWWmih8Ctj n35ad7mAgdc3mKJL3EooD1x568C1xuAKQk/b0OUAlU9h/PcB0g9eYMCbCq4DiLd3gSEe+eNSY+Fv BBiwMvhhcGEhmwjwpulY3RPH6t7w92w2W9J8am06S0DXRpYTALUxWephhH8uZOgO9xqlMdlkOo3a zet83CV43Q2B+0P/sZgycQrrLAGCis+ud0XAOvkxxyQwpRESCCVEEpcJSA4uDRtoi3UT6y15QFix mkJwuA8gVzU5AJ7o6oOVFYJHHhDJdd3/Wm3nd1ZiCDRkCiszFt7ukihZxCqL2wEWVyy3uDB8I8G1 A2JG2dQXAo/VFkLLvg+4ApAOKydWUNoFJitIqA8kl/Ih4bSf/AhYcYn7qwQXDUgwxB1iD7YELKK0 H3JD/WkLD1yO4y7CAIGARR6SCemkbbh4MACAZEM6OY7fMQGMo4ST8wyAKL+vBHJOWuqNtRbiiRsH eGCpxno+cLbZZpuwyiqrrNWp099QtGnTJth8881DAj1w4MDws7tjxowJpk6dGlqcXYDUUwfqCW5Y wxlg0XaurQGSOyU9XL3BcilnWUcPDEa4HnkrcaQElxdeST8lwdq/ooTrBjcS3GeOl9zmC7dtiADX QzcGbEa0MntF8JzgDVQX6ZEPtJgrRvpVaTpLQEdGlhMAtZQs9QCC7OAbCkG6x3XSpWRRVXH1MMYS 9Ypw4StYfCVtNUdKPFl+Tf8hXgQs0BA4CBqW4VMlEMeLJFgPh0lqJVh4OY5LAmmxCuJXSxzOQYSx LmId9oFO4U0JVsYrVJdfVJertQ/hvlyC3zEuHpAoLJhfuC2v54+SQNohxmFQ+hFKT1kQetrSwlnE B2j/J8nrEggqpBpyDskLLdMuUJcaCYT7LAlkjrJwp3hPgkUXQvydBHL8hEuHBZ3j10hofw8JxBEi 7PMHD8gyVnmIJdfj2RLILm4T4IobAnXEqtpPMkZyqeS/ErDk2iUuVlzC4xKvJ/5fIsHFBBcL0lL3 QyXgTl3Bu7sEco97BLq5U5P2+o4YMSL0TfZhp512Cu69997gtttuC3bZZZcAIg1xbtmyZTDPPPME a665ZvDOO+/QHrAcSz6SGgmkFpcSrPH4Fx8geVtCu9Et5aJH/zW3e7W/pQSMGVhxbaJb0qFb9MSW a+ICCQM2C38jwPVDH2M+y9m+KtBhdOCb7dY0j9qbzmLWs5HlmAEtJjt8+JzbQE/Fx4rFp0mx4Flw CAiPfuxq+34UFP2H2IXBWTmiuJ2TAyDWPgLEFqLnA+TUh0elC6ybWGzf0z4kFuKGBZLP5kKmfHnM HMPiGQbFxe8Vn1g6kgclrHLxg7ZYaGcKOveQO0j53kUDSyXhkTxJ6o65OhHXx6+rRk46fHLrgtJh TfXh3Jy4Yf6K84Y7nvu6HCt8NNSRf3cQkhltK4OHMCjPemn1n7i4zfiAVT0XpxtyymOA0u/ggw9e l8l7PkCK995773pRd9111/D/vPPOG/Ts2ROy3FFl3u0iedeQaJ0YdCHRwCCiLig9rjZINEDyowGX kbprIudcc//LIIrBk5Hl7F4JvK3i+WkhOwiYzhLQlZHlBEBtIEteP/MaHbcLLurezdXtovzQ5y9R +LOUGlZST8DZXl9E/bDofqS4WF0tJIMA7jQlBeeKMYMBKQPTkhJb5DgR4G0GrjBGluNEtbx5MeA5 r7xFWmlNRMB01kQA8yU3spwAqA1kic8rPrZYLLF4hURLHTuvv/GD9OFrdfQs70VHw6t3Xk8TeOU/ QOdYmozX9rhx+MCHHL52aTbSQW+Og5STBot2d+0vF0nzpY7j7gApIQ2vrwn4kJIGf18moWEB9+Fz Hf8OX0Qd2FjiJ5bxeps0LNG1uPbxb/VhsCOlXHOk8SsH8LqdNJAb/HIRHz7BUqvj5E/d/PX6u47z Shzc8JddIpLmY50bruO4IpDGvz5kLeBXXRr8enEn8IHX7lgx20u20kGwwLrMhzpCi7SOg1n3SJoP sJaCmwQfW1+3sd5Sq+PoBh3lloMuqZsPrESBmwXl4MqAX68P7+kcK2ngtIvPtA+swxxavXVuJW1Y HcMHJu6N0nFce9aPHB/lrKWkwa9hvsi5t3VutI7jy43Lig+/6jiDAtLgy4w/tA+8ERmj4zU6gG+v D7/oOCtFkAY3mrkj597QOXyd8YPEMu8D6x1/6NLgy9zNnVjj3XffDX2Siw0sLadgz7ZiAUsonvTJ MwSxkFEEeC6r6kygbuH2M9qS5lNt01kyurYOJRlcZ5UrxJPeHOwhH7zahzDid8t/H/BJZeITAaLG RDQCcSFwkGYIRTQNE5C+lkCwIWoQHwKEnFfOWNnmyklTq/+8EocgQtQgWIQJEsglM6bwC46Wg68m bfA+rViPCLxyDUmsAqQqmgY/XXyIScOgwBN5yicND2XIWzQN7gq4Nfg0nsjjC+vLwQ0imga/UQR8 IZGeyOO3G5JlBYhlPazVGUD28O/t4dISDz9V777BYCaahvbjWkA7VnV1JA119m4NkN5oGnRDnhB5 yKq3uFHfkCwr4BJCHXz4UjvUnTTRvHg16l1Eumsf3fmA7zVuJNQtmuZb/fduBVyH0UHTp/rvJ+nl 1jkkywoMMBho+MCgDxaL/qNpqHNIlhUYNEUHQBBi/Igh/9E0uDOEZNmlIR3ho7322ou2Ep9rhMA1 CdlGv7muFJwHV66bkq3SLn/bxICA7ineoIWD8RiysywqgIB0SL+0oXSYz02sAjWyIhtCwHTWEEKN O29kuXG4NSUVy1WBO2TyKz2EIL+89sffs87n0xfgRonX5StQ55jghtQLOs7kMCYszRScldCTn7rz Og6RzvXHDM87C2ad726kblisryhQDoTRk8ZoOViaLiuQBjLrCW00DRiFbhJ52jpAx5BcDBhsXFwg Db65df65erhAUA+TPKO2XlggzfM6juSWA/Fjcle+uuEvHPUZDuNgjdUm76tNncOXOfRnjgYdZ4CS 63Ps83tMO0huGgYohdLQ+c3UAaocBgCF0uT6MPvyee1XKM0DBbCBzBZKc180DdZ7/Y+SZQaKvFE4 XsLkO3SdG0hTtzRGvjrYscQR+KdK4G3Nt2aVTBzrpArASLObdPicthNNj0nBHGu+prNY4fwrMyPL CYDaQJa8Pn9ED5/uineQtrgqPKZj0Uln5a9V8y6R+wAS30n64NPY3oLZvFFJSevd4I+3FnVBeuIt CmQYfbFvIX0IMIjB3Yo3Q+Y7nj79FFMj9IaxAtcxm5tRDGKVj2M6S0AHRpYTALWBLPl6GxOPhire adrfQdtztcXa+4iOYw20UF4EsELismAkuby4N6U0nl24f+Azbv6UTUEyubTcU9bHJIdvOXLm2QhR tmdjOdCOpwzTWTw41svFHmQJgFpKliLHj6mzZ53ZQyQHaP9as5SVgmAscXE9uDmWnCyTciFgOisX 0o0vh3WqsUqaZbnxGFY6JXMseDYaWa60Joov33RWPFZFxzSyXDRUyUV0r5lvcKsK2Kuu5KDOm7Mb nLwg/PncsXUKZca/McWZzhqDWnnTSEd82hwrly0dV17oYytNOmSitz0bY0M0+YxMZ8lgbGQ5GVwb lasu8tpGJbRETUIAtxhl0EH41/OLbVKmljhRBExnicIbS+Zu6cJJuq+YkGkhgwjYfZY9pZnOktGZ keVkcLVcs4UAayEfq4dML3XstoJCNnRnOku/nvhC4wBJ7pch019zq6FHgOUvj9Oz8Rh7NmbmojCd JaAqI8sJgGpZZg4BXhWzJnVndQp8IMRcMdKvQtNZ+nXEuuhz6p5qZUQr/coqUENcaDrzfJQex9iz MRN6NJ0loCYjywmAallmDgEeLn6Jq7JU3r0qYxUHe0XdOMRL0hmETcXMcPMDGldinlRJEEHlGX7d Mm3XRiPa6r+eyYoltCcVb22cHzX1YT36kgOrryhRy2Lb05h73dWR6zUNA/ein41NxbZkZcwigV8l x937sV1/jbgP4mxWsXkVrbNiMyReXG2P4xnHtdbYe7iUNvu4RpYbg5qlqTYE+Ez30DgbpRt5P+U3 TTfz3bn56hxfrjtCwmfBWTLwvlJWQHEd0ilKE37UQ//5IuE++p/3gypxtitfXiqfT2ovpfJvTbqs SP6s4csX/xq0djl8TlNcPu7zSWPrqHz2V1o+JBR+1VH/WVJrS8mjxeSp+Gsq3oJK37cAjpCwayV8 rZFrg68T8lGX/0ieVLqSvoSn9DuSj9L1K6Z+heIon1N07hrJJpJS8mJW/u6SpySbSWb6cE5T6hVN qzqihy5q64NF5MnXTf+/vfMAt6Mo3/hJQuiEoBTpkaIUkSCIYIEggoKIEREElSYgVYogCChIFaWE Ir2DSIfQO6E3A4EgEEBJQoAAgVy6oST/97fMnP/ck3Nzyzl7c/acd57ne7ZN+eb9Zmff+XZ2Fm9p /DtnOYny+Z0OhnVChEm7puLSloZI+Pvm+kpzemXZivNnnRsk+Uj7/CXzPMXjR0adBX4F/5rS8HdQ /sjJX09pew93lrCj68qLPucfku0kZ3dRj7ZQ/nszIu7K+9uKx1KB/G2Tt3TxT6E9VbdqOpXzQ12Y vaN7iESKg322kVwc9g/UPvfT35Qu/hW3R3opD+5N/kzZpXs+6AMeu6rsI3tU6Gd12l+b05QH9mgX gl3v1TX+qErgnw1ZX1HrYEt5g91fGbhrn7/7riu5pqN6KM7Wuvao4vNH1ulC6Ivph1kit4+Oz9KW v73u2wN8vqb03Ms8P/lPQq7BZDlXeJ15ERDQjfaSbjo6sj61di5JfSE9Vf9Qp/N7S3ZRWe+oXOLw 6+t7tM8cTzokzvEKm19w85ttfmSTEazwMIeEDErK4iH1RV3j195/lPAFO39W5PfhyyjtHYFMPKn9 V7V/iM7fLOHBS3mUyzJfPJT5syQP1bGKS0dGmZAuCD5//IOg0vlDKtokkCj+GMVfEIlLfkPYV7hd MlSyouQs5TdW12P+dOgsSbWMhPnH5A8hHK045L+vZJKOh+mY32zzy2w6xgd07kFt+TU3v7w+VNeP 0rn3wgP7B5Sr4xFBH9JdIoEkMCUAfUZJKONnkhGKe7vOr6V91m1eXcKfH7nGw+YCtiHwi3D+vhgD 5JaHCGulMy8XTyUPE36bDjl/U+nTP1z+RueWVfxrteWB+3XJPxQH3Al4YvlT4Q50/orHHzX5Qydz EFmfHWzBhYECf7TcUPGuC/iAK0RgTwmk6nxtsf+7ur68tr+Q/EsCxtkPQnR+bW3AkAcrBI7lK0fp evanRl3fTRvqO0iSrWqhc+g3hH3Jnegg4bfjkMAXdH1B7f9Wwh9EqdevJQymsoeZrq+kzeYSHqgs mwkpxBZrSE7RufI687pGu9lC8pjO8yMnBhsDJaQ5PbRl2gZ1w2tN2+YnT7RF4vIQTXWaoOPTdJ66 /E9xaRukX02CncECfZ+XXKvrELN/KQ2k9cdBX+pKO6D9/UoyVMLboUGKs4e2T8S2p30C9+/Boe1D PL6veNdoyx9D55ecoGuTdI77YBsJv4rnD5boiAyScK/QBsYp3hBtGXjwR737lTbzjgfcKZ++4tjQ JpbU/l3BzkSj/fHX1YUkQ3WeQfZfyCPJl7+Y3q/jdXQNW7P0H4OBn+scv6DH043dIf6UF/sJ6jNQ cqwkGwwoPsQJjLEVfSz3JnHm1zH9RjnoGriDI/fDpzomP/QDnzeCrWg3BP5mSv5bacOfPM9UnHFJ dutpn76QX3XTNrgXcYjwE7AbFPdpbRmAYpthEtr4+iH+bLqeDfoVB/vSnrK+K+RPu894U4XNLlGc 7C2hzlM2f+rlnjxRAoZf0vl47xCN/mKoJO0bB6GjZLzyOiPktaW2PAuw2cbK4xFde1bbTXV8nfa5 r7DLqBD/D9pC6Ok76BN5hnC/YC/6hf/qHH0I9zwDoFt1HPuH7D4L+eyuLW2ctt5uNRvFpx9icLRI yIMBPfVGR54dd0n20/E+2nJvH618eSYR6JPG6fi3uk5/dy5xJeBDOeDBAHuUhDb+HcW9Udfon1+U YDPuyxslPL8Y+NGvUb9cg8lyrvA686IgoBsSUtGuU+ip7qHjp9NJiVWaHR3VRorHn+cgwf8OHQvn eRDQmUEkIRx0JF/VdR4GK0h4ENFhQDBjwJsDSYbw04nwCo4HKvlDZuiYN5a8rHx44LwggSDwYN5L MkoyRPKKZE8JxPJbiruZtnSYEAQ8dnS66Hiw5HIJ5IKHDPnfLyHQUUMQIeB0aguEtLsrPzzfPLh4 GNEJQ2gg2gwOePCyzjhxIGl4VSEgPETxmJAnJOynOjdBW4gdZByS9D2dezaUB9HYQscfyqZ0puA5 VgLBZpACVv+V8KCFtGIHftc9VAKup0rwgEKeltC1ocrnGu0TeDBlRDMEPMvUETKDrdGFgQ+kHm8q A5i9lD4SZrwtkyTfCvEg1TsrzhGKwwAIIsKD9kc6F8viIcNDGIFs8Mt1MN1FEh982AH70Faul3xT 6SEJDIAggxAPBj7YnDYUPVCQAR5mPGCJA3Y/VFqIEnlyP2AfCA+BNsSDEEJEG6CNQeIom3ocrS3t 6SEJ7e4eyUgJNsC2j2sLGeDeWF/H4DZEAmn/m2RfndsvkDeIEg9CSD948LBkQIUOtBc+yKU8Hs7U +RAJONNWeUjT/nYBW20Z2HFfrKJjHsQfSHiwQ8z/FK7TtnhwM+DgoUzgwT1LaFubBP3RAxJGoH1B psaGMrkHwQ/CGjGGzNI+sS/kgHaK/Ulzn2RPXYNQoTMeNwYTlEs74j7lfodkQZ64Xygfu3Iv0o5p u4QNJKzXzz0DKf53OIe9IFYMgNCJAQzlY1vsAUa0wx9JuB821TH9AO0HfkAfhB3YQkggYddIaIvY /RuhT4FQ0y7plxhAQoogU+RNHcEZu3FfTdPxtsIIvCFZ9DNgyj0EaaKdch+Qdh8dM3ilfVK/wyQM BjbSNrb7PXR8iPLD+RCJ3CG6PlQyUecZRIEn9/4H2qc+3KvoD+7oxeCTdv05Xf++tvSh84c45K9s Mq8u/Rvt8W5taVf0F9iMQXbsA7l/wBBMuB+Ok9AXkyf73G/cH7FvJH90+G4ob43QTl/SMUSYdkC7 5vjbugbxJ+5NEvoJ5G2dh+ASJxsYSMB6EwmOEdrY1oozRFv6IHReS8ePagseF0qoF/ciA17aLfVf RhL7PLClndA3kx99+XJKs4GwQRf6Ktr3IzpH/8R9z/2EV5y4BAYOi+o6+YBH1Jd7kvwh99iFAQ+E nPZAnzVAgv2HSriXcWbQXmiP20jANNdgspwrvM68CAjoZqRTGKIbPvOo1RKUF0SJB+gjkvl0XG1e FZ0ynQmeIwgA5A8vBB0THQAEhnsTL8+VygNiSUdCHDyr9+kcJCgLOsZb9LrOjdCWh9hECZ3IdyR0 QgRIL50ehBCPBKSXBxXHvJ5ksMDDHH1Igy6QHQgBHdhPJJCcd8L5jHxL8Aby4KGjJOAFwbOLJxBC u66EhxqY4BGloyUvHlyQUsjLiYp/l+JvoX060AV0fIuOeWjy4OIhjZcQDzAPSUgqBJ19CA940qHy kOJBgceWDhds3lIayA+DDfSFPEHEsMvd4eEBtnTskJBRkq107SJd44FD2+goQG6p++mSAyQQkEMl f5dAcCAA2CIGHiToS3mvhfIhJRADAvmBH20Im16kOHjjOYdtIIUMKiB6lHWeBJLEAw9yBG7UietM 95isfR602BrMiQeWMdAmIEFgAwkDO0gFD3nywGuI53q5oBf2Q5e7df4SnWfAgX2pD3FIDwGgfeGt xLZzSdCBBzr17B90pBzaOSTiOJ3j7QfkPQbaKoSQ9kabHCHhQXu84t6puFuSF3mEtgOpn0PCQ572 PEJxfhnifD6USfnLSxi0oA8Y8mqbuJT9hgQssntDAfJ6pARdaR8Qc+p4tmQnCUQAQa/bQpuFxFDn GLAb2EBAKJ9BD/fVDpKvSrA1uGIbbEQbGS2hLRMXHfnj65vSkfODQzwIEIQsBogufQp9BLrS/8R7 H8JN24dcI22Sv0hon9tKuJ8YXNJ2GPzRdhnIQKCIy72CN5P7igHVKAnkH5JF30QfARHnvqJM7ELe /wl5gi1tZKSOTwz3MGQtBrCB1ELu6JNoN/ckaclvQLAz9xZ9I+fAaKCEwRx2IYA3cSGPxOOeIgyS 0GaoF4SX9g6Z5zx54aU/R2m4H+mvaEdDyKsif/LD3vR3/5JEmz0UymFzuwRs6JMY+JAXgXvnDpVD n16tb4Rw0i7AlPywG9PM/qn4a2if/on7H+LMs4F2EwNlZH27pE0C6UV32g79JgMTsKF90D+fq3MQ XtoX9xn1ifcZ9z62u0lxuF/Akf6IMiiT+4z2fqmuM8jk3qOvfV/Hz2uX+4u8/kE+kh//v5rZM4i2 Ee3PIAU8KYO+4G7J5hLqOFZyg+SPEuLRTj9O2in3GfcL+uYeTJZzh9gFFAABbnY8KjfqRowPmJ6q TYe0uISOknzxPLRVZPYnlYNHgwcD3rElJXQid0rw/PDQoWOlIyPQmUPKuF95PU/edPSVYaxOIHRw eD1GkK/io9OqknNCHnh+yIO4EPZpOqZzomOjw7pSAkmks6Zz5MEMadlb8mcJHSKdFGR2fwkENAZ0 Jk8CnSoPlMslkDTqSLpREkgWD1Ee4jwcz5KQFqG+MVDneJ5z5A0WbOlwz5dAVBnooP+lEkgFD/MY wJIHJPmABfmzjfmRVxQ64OhJgdzEhzBxSZMe8wCJBAh8yB/dSA+xJUQizD54RHwiRrF+UZc31DYO KWv+2Q7lUhbeGbwqPwp5kXY9CfahzIhbrCdpOf+gBP22kfDAI34sj7x5CEHiwQ6SBWHEU0ZbG6Tt wtJpovYhb5CFqDvpHgvpsC/XqS/TNSAJPCQhipQRbViJe9peIqlAN+w1MeQNkXxJgmc1lo0eaVrI D/WkvhAF2hxxM7JJhmGf8lN7x3uM/CIJi3qwnSThGvWjTmADzuRBu4r6xHzIPxI0yqS98H0Bc5a5 J5cO+mEP7jV0Jc4oyf2STSQMgLj3Yv1i3pAKiBhpIU0QHAZJhEMl3AsMYGI9uPfZ596H4GObiBvn sR94UYdol2ireC6rj/KB2PNdBOSIfgsCA9k6MKQnL0Jq56h3bOMRK3BLbU0ZtLVIetJrlWm/o7j0 k+RB38J9j23SNLGcsTpPu4DIXa38aYv07wwGGBDiuWYQH9sEUWl34Er+IyUMusmf+zoGdOJ4lCTa DCJ+YYgARgxE6Y++KwHzFFeiVfaNYAWmDAYiptSDvppBJW2P+4v7YBlJ2r/FvGM7j/0XA9cYaAO0 nfgMGax9rpOWvLj3430GxtgD0s6zKWIb+5W0P6ZNpdiDW7yXKJtrKc9k0PSQ7MEgNAsqZ2DYRZ89 JWDwbQn3BTowSKN/4t5J2yn4UNd4LmaZy9ZkORdYnWnBEKDjw9M0p25cPCzpw65bVVHaJ5SAaQAQ hSV03Kb9n2ofTwmeKwKvqSDRlEkngLeHhzueVTwI10noGHk4EtjSKV0r2T6cozOuDPFBTAdFfnj0 2OdBGjvQi7RPZ4xHDI8oneRxEh48kGA8R3T8dETnSXiwbCyhQ6JubRJIC94IOk0eVmmgvDjg4GFE XltLIMn0NxBcOn7yv0CyhOQLYdAA8cIrhlf6ZG3JCxI9UBJJKnlTl/kkdKR07OiMx4iHG2W1SVJP D2miXhCdsZLxKmOYtpAhcPqehHaA7aP+2AeSGgPkhtfWG4UT95JedsV7ndVP+5O1jwcIm5MXD9sY 0Gs7yW4SPk6hfMgpdY6BhxQ/yEkHbXH/DkXCFhB67M8+5IgH/g8k4EaetB08SQQeXmDE4Id2NCYp K7YvsMWDA3akxTM0XLKzZO1ZZpll8RNPPJH8Pidh8AQOhLskeOJIR9uhPVwjwSNL+gmSdYK0aUs9 nww6ksdoCQO72DbTOk/WeUg9eWMDCAt6oh+BffLEK3yMtgwwITm00yV17m/aYh/iXB/KxB5nSLhP yDMK+VE2eZIPhPVibKB0tCnm/eN1PFb7DFbAn7gQ2nUl3L/oSwDTWB+O0edUpaW+xOc+g/D8UhLJ D3EgBJGYMGD+QsgnbYPcixtKIHS02ZQwQYQ2DdfQAaLGPfbnUA7nILTcj+jB/UB7Z/uihCkMw7Tl PkI/zkcSBG7kzZQLMKAscCAvMAR3CDxe0VskbZK7JTspPv0E8TkX72HSpINO0tCvrSY5ScI9s6PS MiikLyQtb9OwKbigD2SXdk/7AC8wBHfsyLQ2PrhkPi5k7LSQ5lKd+5eOiffzkBaCCMax7aFb5mmW fCnE4d5OB2ncA/Rlqc1oJzHcE/InX7AkpH0Qx5V9I/fOfZKIKdiPknxLsr+EMskPrJZXPeg3Yoie WfqdvSS0T9oKbYRvQPbRdkA4R1/JPQte1AG73SRJ77OrdbyTBB3aJPF5GPvQtI/HjmkfSVzaAc8Z 8gBLyoyBNp+Sa85zTB1oR6MktDWei4uF9PRx3C93Spi/PkzbVyTYnWcm/UTuwWQ5d4hdQAEQoCNk pN9jklyljtzAccRLx84DKgvq6C7TDQ9RoFxeddMRQrjatOWX289on7SQXMKZkk91no+S8OZA8NKH TcyXD6YgwVMUlwc4DwriD5TQaUPmXgwP7hfxdukcr9rQgY6HcLmOIUusN43XlzyO14aH1DM6R8cG KeMB8oGOx4Z0cTNRO3/iQNf4kIaHHx/0RA8Y0xsgy1n+2od401nfKvmvzvEgu0HneYBn+Wsfwhcf Rnix6VgRHgbnKA4PPPRkALKUJGIadTqMvCR4MxgM4XFDLzw043TMhzAnaB9MKR8PD4GHTxoYXFwv YeBCoENHd8JVMaLyi/pTFvWIYYR2qON/QnkL6zhiCl7odYDORRIb02V1xqa6zkOCPGk7c+scDw8e nAO1PznYhQ8LsQN58vqeui4r4QO3cjvU8dES2greKzyPK0iYHkL7As9h2ry9+uqrr3PVVVdtc/jh h08dMWLE4U899RQPb/IeE/JeUIdP65j7h7ZBnWjDEEkwhzzw1obXtGAIyXkl6MtgKD5s8cBmD1Jt mRbENcg0r+ipB4OrSJYP1DlwukDnl9OWds+D+TfoIHlYMibodAU6URcdT6C9ax9dkUiCDtI1CCPp 0wDRGxFOHKIt9yrEBoLOPoMfMI33Y4ZpkgFYLSThfn5ZZbRpi5ceksKAB7vidQYX8H892JS2BS4P SiIm3AvH6XhxCR9rlUmK9rn3GQhx37Ou9Yc65t6fV8K9Tz0PlkCkIPZghy7HBqyJO4j0IS3ElHuG weznJQyAGDBBuKOOYI5ET+u+2mdAxKtyyodYMwUmu/d1zCCdAOGLfSO2ZooHfQzpqDdxScsUm5iW smk3lMdqGAxkKvuWbEqazkOqfqUt0z6Y3sOgjWX4SEucUTpHG0/zPyjodqW2TDuhrU6Xv65B6Ggr sS2XbRbSk/9IpQUH2gXxsR+DFtoLNuiob2T1Dto7evKhIXUcFrDKcFGAPDNwTAO2+ijUvU37kPxt Q7n0VQxy6SMiqeYcurCCBoPzc7Rfvs/IOJRLG436c/oNCc8k2sUhQQHSpuT3rzrG5i8qD+pPPeKz hSTY86gK/RlI/jHUl2fdstqnb8Ehwmo+TKkhD9o7W/p42jme6NUl2fMm72CynDfC0+cfO+neL9kl doQA3pTM+6Absy6EmU4oFqZ98m8XKjqQ7JrO4Q2K+3h96ESyuWDJ+YwEdxQq86WjUdxIkLKHKx1R mr5Kmkhsoy50/Kn3M+vsq+mg8+hNJxvT4v1KPWCkTfOHjDCPtVz3oGM5f10rDwy0n2GizhNMICZp PB4G7XQPeWVpFOIWHbBPOW7MN8TL9Ne5dqSVzlyn8aBOF6rEnQ4fxYHoZfXUPkQJaRd0voxdvJDq pn0GKTFk+oU2m3k2K7DN4ukcdq+GCw/CGId2X2n3cVy84447+i+00EKlk046qe/o0aP32GGHHfhw ESJ7q/LmAYqUQ9Ke8CiBOVNLIuFjMJLinurQru4hTadxE0x48OPxhHRluif1S/OpHIyAUbR5NshI 0tFOsnu5oo1EvcdWxC/XJ6TBLtHrnOabDqKiDavWtSJ/9JzOlqGstG2QZ5vOIwTwr9SFc2kfk5af 4SE8IWkQmJcq22ZiZ+55QmWdwLKMZ4JxOpjIEupaNjCPQccQXCRep33G+mVeYMWZrm8J5x+T3sRn UDNdfxfOVeY/3T1fLf9wr8W4090zib5j0/poP/Y9nfWNkVjGOkaSnGWner0gHXC+pFil9xAD8fG6 SHpIMVv6+1FK94SurRqOSf+PgAXtoOq9X1FOub3E+oQ+MdWF+kV8pntWKT73f7kfDuWDY0xDGdnz SXHL94320/sqDqAYHDPYa9f/VOBet0OT5bpB2eWMGCnFzqXLiRwxPwTCjchHQ1nn6tB7CAh7OvZu h2AzPkiyzbqNXvcSTFOIKVZaaaXSnXfeufEFF1yw0W233car8b/LFpdVy1HnmXLQq0Fl8rbBoU4I hPsM72x8m1KnnPPNRno/nm8JMyf3SqLcwX3HoJy+kTeJ56dxdMwbunTKyMypSB1KVV3aOVjqkOUM szBZzhvh6fNnLtb3dLouHszeV78pS+Q+YI4XUyHia9mmrGgTVco26yVjrrbaaoPSouacc87STjvt 1HfbbbddS97mtY4//vgdBw4cGKdHpFHjWzQGNOVBzSeffFJ64YUXIGBMZXBoYAQgXFJvntTL18Dq WjUhYJvl0wxMlvPBdUa5XqGLfLTA6wiHxkBgaamxt4S5rfb6N4ZNOtPCNusMoTpdn2222ZhXzvzA crj77rtLt9xyy9jLL7/8xvXXX3+X009nym3XwiuvvFJaeeWV++mhzs8q2r2S7VoOjtWLCDBnmbWO d/cb0V5EvbaibLPa8Kua2mQ5B1A7yZIF69vNz+p9FVxiioAeBHxAxrzed/3wLkbbsM16z0633357 +UOyd999t6TpF6VddtnlD6+99hp/LRv76quv/nLWWWcd0FWN8Ewr4Czgo1qT5a4CN/Pi8dZtXt1z nf5afuap6JIrELDN6twkTJbrDGgXssOjwlwie5a7AFYvRWE+Hk9wfinML0A9RaaXgK+hGNusBvC6 k7Rv377Zc+Lss88uXXfddXcMHz6cXxKzOkH2i9sdd9yxW/PGmYah4A+du2AE4ft1RdtAwkdddwr3 dOUB8P+xzn9Vgg34FfLNOseKCawgUo85nRiLe+2TtF9UGV/UOX58c28XqoGeayoeH8cOkoyr5aMs 5QURXFnypOQbyouPhDsNSreKIr2v+NmqGB0FxVsn4P1Nbfkte7uPNjstqIsRVA52va87Dhql+YHS sAxp9gFgByHarLziSIwX5p5TP+y2pvK5ozN1w9TE73YV5xng+jVdY9WOytU8pkuiMlmdgzpmq1Qp TbuP0nWd5/XaOh9XI+qsGjVfN1muGUJn0AQI8HV8uy+5m6BOzV4F26wXLMyDcu655+639tprj7rn nntY+usuPaDS1SQ8sMzJDsL+K8p6CwkfUEIOWcGh3YoXOt5MAllkebh1lYZVa4ZIWDGAlRHW0JY/ 2rHmMOtFZx9Axn1t19fhOzr/UFoNnR+kY5ZqI19WdllK5yA5EGfeIrA82bd0jmlr/O3tNe0vqH1I +1cgYTpm5QXyhiRznuUnWZaR5RfP1PXvkF8lYQv5QGyf1DV+Vb2Y9rMl6WEobMIAAFlbSURBVCRM ByLfXSQsmbaerrdpy3rnY6lDIObMs6bO6DuPBHLFsnn8MAeyiD7kxyAEvcD6PgkEk6XIWN4M0plN y1Oa72vDW+FHtZ8taSZhkPKUzrVb7UTX19N5CC2rs/ANDMcMXp4IeVEW981QCedYJpH88dyzxFsW knIG6/CxQKq30j5L37EcJ2vFYwuWkHylis1iVuSFDiMk1G9rCfXOPtoMxBNbYMcXdAzG1H3VQJDR V6cPfo4yQ5p5tV0t2BlcIbUsxUebYzk3lrK8NcRlcLOahDYMAX5KcajTQorDMoJkzvKE85OPzo3S 9rcSVshg2mo2WAntiXqTZjYJWLD0KWWvJWE51BkOhMinp8FkuafIOV3TIKAbjLVXj1SFWF/TD/8C WNY26zUj9Xnvvff2W3fddW+W9FqhLihDABJCYB1pSEo1IgBRu18CCWZuOSQmW8NZfdqQQCJYnx1S NU1byDOBdZDx9K0k4Y1aRqi5oH2I6s8kLM0GIWS9YYjpPpJlJRtKLpEweGLgtL7SnEBSCeXENbYh o/11jaXnIEssoUmd5tG5H2lLOazxDQG6NJTNGtK/krA05Oq6xjq+u0oYMEDc0QGCCQGGv1AH6juH 4rL85zJBP/JlfWHqhPfxVAmkDbIG2WUgAK6/kaALy1NyfI8EEgnxZw1lllsDC9b2nUv7kDSINmT6 BsnaOsfc+2z5Mu1vG9Itp33evkDoIIHUGX0p/5cSpjYx4GBtb+oLQSUOdoieckg939JQzhq6Rh3i cpMHaX9HCd7vlXXtam23kUSbgUX2llTXttM+dQObCyRtEgjm93UN0vxrCYOCNXXMco8sQAAmD+h4 YW0nSZiquJAEgg6u4Da/9iHfvMHAfsfoeEltvy1hHWriD5fsJKHuDAiO0nnelvxQMln7zK9mxY7L JQ9L0FebbHDDs5i4rC9Pu8KrzprLi2hLfUlPe99NAqEGo2tV51xWQjFZxiwOLY+AbrBcXrW1PLA5 AmCb5QhuyFoY8xC9Of+SXEIVBJjPDWG6TQIBaZM8WBEP8smHyXxzwbQEyA+kGVL3mAQPKMQS0gYp 2lcCUTpUcpLsu60IxmDt423MyLIC5A6iMkrCGtmQEjyNkETaA3lCnvA0Qn4g0hAjyPHZEryjV+ra Brq2p/YhmnANyD5eZT5wZwrCOAmDgHTtcogZ7Q2dIcl4HOObDMqFnN0Y8sR7jjf2CJVzgPYh2ozo ztc5/uJ3lvZHSPDIXyzZXsI0jLN1jekrd0sYZBAHvMAG0nZnKAMPKefXCTgx0PhuiD861P1kHUOs 41q/EE2wBA/wYqoDP0jZSPvkx7rJz0hY4xiCSf5DJX+XQAw3lkSyDGl/OJTDF7QQwzgNJ26xC7hz LbVZuj4zOmN/SGbkfOgGltgRnVmzHqLPYIj8bla5w6Q35Boyer+OH9WWgE2W1DF/aARzjmkLl+iY fBgUYZvdQ114o8EqYAOD/tSTMEoC6b9S0iY5XIL9eHOAvagjXn+IMm8+wAOhXdCOuM4xAw3eCjAA +W/Iu+4bk+W6Q+oMi4aAbmJuNuZkZd4Nh8ZHwDZrfBtZw5oRGKgc7lC/xKtmCDAevcqAB/YIxcmm VxCCtw+CCTnjFTpeOt6a8adKSDcfZrIf57RCnCL5Iou7JJBiPJ+bKB5kluM2Cd5ZphaQFmJLID2C LpAViCJTNwiQQcgXRK6/JE6HwNv8cwnE6YsSPMgEyBHEkrzxOuKJjR9gs4WzMEBAB4hSnD5H3pRD PdCFwD7nx6u+TIkgPp5JymQKwBnax7OOxxIPPaSXNOhMiG8ZIzYRJ3SIc2i5lk3VSMpENzy8lJe+ qSQux/xhkb91tmk/klb0wGFzVZIX+UxMjuMuabIpFAoMKrAJAyP2o834EyPefkLEhLwYKEV80AXd OUc6PPajJAxuIPQE8Od6Ov85rROkHBIeSSo6YzfaAm8f0riUz3XKJA1l4snmmGkqeKOpA15+trwx ID1tebCEwUpsR9gaO9BO8LivJVks03j6AWU4XdvGZLk2/Jy6ORDgtdxPdKNepxuWzsGh8RGINsPD wG+xPX2m8W1mDbuHAERgqvolXtNDEPk9PNMO+Jte9GRG4pjmDKmE3ED+8E5D/pgOsba2eH35yBxv I79lxtuKswCiFMNXtYPgCcbTCanB64xnmtfnkGcIzI+UHlIF2YHY4N2EWEFkBobM0AXCyhaiRBz0 GBTS4YWEXMUAmYYo8SodfkJ+oyXo8WUJutJH88Eg3kbyJbAlLR7NjaQX0xMiYadMAvnhBd1GApZM h4DUotfLkkiSIXJ49CGk1I3fcZMGMvZUKCfmCf4pkaRMph1ASM+VMIcX+zEFAu8nOA3Wub20ZQCE N5TzeNkHVuQFxhsq7rPaghP1Bhu8yc/pPB5s6oCHHIKb2uyrun6q2gn5Y6NdJASmPIApdSYvAlNP qD92oD5cj9c4xp7ktyIee+1D6ifreA9t0RuJePB2g31wxSboOilgjb4HhvgQfMpkAAhWeI8JYM4x ZTJtg6k3vDXBbpBoQhywkT/peEtBW0V/ngu5BJPlXGB1pgVDgA5ximRO3dQfmngVwnrRZnTsHuAU wmRWsjsIqB+CEEG41pNcrGM+7IIEps/t03QMkUoDb8j44I2/uG2j/TsleCwhJpAVCMnX8DzqOq/K x2mf195Z0D6/i4aQDJYcK/mpBC/hT7gsgcRB1jcPcS5SGsgnr+xfkTBwZdoAgVfsxEVHPItXSL6o +NcqPuSbD/yOSMpm+sRFOl5RwrSA13X9nyHueTrGY/mWBH0ZTDDVgoB+TBm5JxAzSBOeVQhV1OUa 7UdyC7EGj8skENhFJVuFfcqB4J8RyhqmLQSYqQbXKH9IGVM7COQd9zk+RvIbyRWKy3zk47W/jWSk jm8jgs5B/AhbSsASPcn/TcW5I1xj8/GAAQPmmTJlylGSzXTtTaWNOpEGfH5HPF17XtfwLg+WYLPN JPPqHBgdJ9lBwhsFdKLNtEnO0DFEljpsKuFjxTE6vkH7EFTCKSEubwKygYniTAxpNgx4UJ/zwrUL dW0L7S8pOSd4i/H8Qnx/IWEazIuKw8CEAcSFOm7TMdNQCBB/As9jyoN8M9VmXMiX9kV7BjfmivOm gLY9VMJbmBEhfd03Jst1h9QZFhABRtncmPZOFsd4tllxbGVNe4iAHv54BeMrcYjKA2lWOuajqHZB 58peYu2fV6VoPHRZPrp+UjXVIJ06D/HEm/oFyRSdgzilAdKKpzULuo7XOoZsX+fidTyNBNJkc191 7ewOykb/1NNdLS6DiHKoqDNkOwZIFR5o8sAjThhVUW4lhnHOcBqtjJPyGR8vVNSZMvCInpxch4if WKHrjVXqXc0OHx133HGrfu1rX3v/2GOPvVK22Fr5PxjSUq929qiwGR747Hmm8xDPVKcMD4UsL12H gJZ1TGzGtVheiinnx8bytf+m9pEs6JipFeWgY7zDcVAT4wyviBN1idM5uMzgK82nXb6J/tijHcZp unrtmyzXC0nnU2QE8How2nYoDgK2WXFs1ZGmHpw2vg0ht9Hr1/jaNpmG+tlPaZVVVpnroosuWm75 5Ze//owzzhg+fvz4gwPB7ai20WZTFc/3WJ3ahMlynYB0NsVFQB0Kc7Du0sidV4LuXApgStusAEaa sYrcZ3x45NDACOg+Y4rTCPWN6bzcBta4qVSbFn7gk1XqwAMPXGCrrbba/uijj97i4osvHjZmzJhL ZR/mc7cL0WZNhUQDVMZkuQGMYBVmLgJ6EDA/jUXsGZE7FAAB26wARpqBip9++ilf/7M0Fa+THRoX AfpGPqJibmtcRaFxtW0uzRavrM7iiy9eOvnkk+e69dZbD5SXeU95nB+Yffb4jWO72NHp085m+kV9 6fXXX987nWrRXJDlVxuT5fywdc7FQYAPNn6nh8Hu6kTSZYCKU4PW0zTa7LeyGV9cOxQIgX79+vH1 +pGQsAKp3YqqssrCvpJDJPSNfvPWe62AFUtY6aEcPv7449Kpp55aElk+/9577132zjvvXG/llVfu skaHHnpo6bDDDltBz7qn1W/6zU6XkWv/VW03kjmqEWg6BPj6e4A6kTZPxSiMbaPN+FraD/HCmC1T lI+OXpPdJhdL7dbSVv0hq0aw/BzLM/KxmkMvISDs273pfPbZZ0unnHLKUyeddNLOssV9N9xww26a 0/zNWWbpus8zxI3L+Jksd8OWXUe5G5k6qhEoGAKsrMBySp6XVxzDRZuxdSgeArwe9vOn8e0WfyTC L7H7eFDaqwbrO/fcc5cmTJiAN3mKVsQ4QUvInSYbvBi0GKjpTN1SaOrUjB+bJHcLtc8iu7PqAWhO 0nQIMG+y/Aespqtdc1bINmtOu7pWjYWA77OZZ4+59VHfG1pr+cqRI0eeKJJcXkIwqOS3ab1oG5Pl XgTbRTUmAuqEJshrwvxJfkPqDqgxzdROK9usAEayioVHgCXK3DfONDM++/zzz68nGzyx8cb8wNBh ZiJgsjwz0XfZDYNAWG6nYfSxIp0jYJt1jpFjGIFaEfB9ViuCPUsv3OPvunuWgVPVFQGT5brC6cyK iIA8J/ztiBF8+ZevRaxHK+lsm7WStV3XmYWA77OZhbzLbTQETJYbzSLWZ2YgMJ8K3VgPhuEizO/P DAVcZrcRKNtMKflS39Nnug2hExiBThEYqBg/pm/0fdYpVo7QxAiYLDexcV21LiPAJ8UsZTWHHgom Xl2GbaZGLNuMh/hM1cSFG4HmRYA1zP8nYQk532fNa2fXrBMETJbdRIxAqcTyY6w9ae9kcVqDbVYc W1nT4iLg+6y4trPmdUTAZLmOYDqrwiLwijQ/pbDat6bitllr2t217l0EJoa+0Y6E3sXdpTUYAibL DWYQq9P7CIR5yndrCsasnvva+/j3pETbrCeoOY0R6B4Cvs+6h5djNy8CJsvNa1vXrIsIiCTzl6p5 9WCY1MUkjjaTEbDNZrIBXHxLIOD7rCXM7Ep2AQGT5S6A5ChNj8ASquE+ejDsJsLcvf+HNj00DVvB aLPdZTM+QnIwAkag/ggsrix/H/pG32f1x9c5FgQBk+WCGMpq5o4AX3sP0EOhzVMxcse6XgVEm022 zeoFqfMxAtMh4PvMjaLlETBZbvkmYACEAF98zybpZzQKg0C0GVsHI2AE8kGgj7Kd1X1jPuA61+Ig YLJcHFtZ0/wQYP3QMfll75xzQMA2ywFUZ2kEKhD40H2j24QRKJVMlt0KWh4BvcJ/WdMv/iIgZvHr /GI0B9usGHaylsVGQPfZK+4bi21Da18fBEyW64Ojcyk4Anoo4EFxKBACtlmBjGVVC4uA77PCms6K 1xEBk+U6gumsiomAPCcLSvP19VC4qJg1aD2tbbPWs7lr3PsI6D5bQKX+QH3jhb1fuks0Ao2DgMly 49jCmsw8BAaq6I30YLg6LMI/8zRxyV1FoGwzJfjA02e6CpvjGYFuITBv7Bu1fd/3Wbewc+QmQsBk uYmM6ar0GAHWVp4imUOE2cSrxzD2asKyzSDLvVqyCzMCrYPAVFX1f/SNkOXWqbZragTaI2Cy7BZh BP5/6bhpBqMwCMSl42yzwpjMivYUAQ3iv6q0a0vukXf3icp8dH1NnXtC17KBo44X1WZBHT/elTIV f7DijZPws59vSVhG83nJSAlLx3UalMfXFOk5lflep5HrFEFlfllZvSFZSMIa+a+mWev67Dr+is7/ qwpm1Pm1yjR1Uq2cjXSgr1pD5TzQlbwVH2/+FpILoj07SPfxrLN+ZpqxY8eW3n///dKKK644XdRH HnmktOqqq5b69etX6t+fn9WW+LnMNJUzSNs5VcbTXdGr1eOYLLd6C3D9QeAVyUmGolAI2GaFMpeV 7SkCIjUrK+2vJHdJvqvjd0Vw/luR3y46/oMkvmWBRc2juAMVt01bfizC25iPJatIXtL515M8fqH9 yySbSPAmQ6Ag6AMkx0myv/eFfFiTHi8z2y9J/h3SHKztKYrzkLYQZkgi5fLxNPvzSHiDhw5fVvmj Qp4wOMqq1InyyH9uxX0skE7q85b25wrl76Xtg5IvSJ7S+ZdjvuStsLpkf53fVNuPJGA5VnHe1BZM b5W8quuLhJU/voKu2n9S56gfg3H+YviOzkHKy0HXV9DBrJSn/TigWEznmK7yWqjb8tpS319LMrIc 4oLHvMTT8ZLan1/7I7VPWX+UvEDe1JNytV1Yx4tIHtcx9iEsMW7cuNIKK6xQuu+++0oTJ04sTZs2 rbT00kuX5piDFwGl0qRJk0oHHXRQ6cQTTywtt9xypZdeeonTCyiPT5Xnd0Ldntb+QkEX9GefQRK6 khFtYIDOMXhq2WCy3LKmd8UjAuoE6PjvV8fQX/v2VBagadhmBTCSVawXAnxkx1QIyNsjEjzAlYE+ LJIorkF61pVsKNlf8gPJ0pLxEkjeVPV3l+g+iuvLQ7Ih02yv0fnRZKI4p2pzryT7s6mOz9I+JPvc kD9e0DUkIyQQ1qUka0lOkPDhNOSbD6fPlgyT4H1Gj9cDMSTd9pKBkr46d7HKeSaUDZn7keRjyKy2 1P0gyW8lP5fQV+NBx52KTltLxisuRPxS8lCgrugB6f6mBP0+CPWarH3IKudX0PbZUB71Rh8GJOhN udT9bOWbYa/99bRBOP85bdH5PMmj4Ry44e3eSgLPmjvowwZ78sHkFUrLwOInEuwBUYZY49k/X3KG BAJ9i7Y/lkCwV9HxP7X9vrzEK19yySWlxRZbLJMLLrigNHny5NLnP//50nbbbVcaOHBg6fnnny+9 9tprpTFjxpTGjx9fevzxxxn08H3Obdq+I5mofd4mbKntzUEX6gemFwc9qXMfnbuIQUtSj5baNVlu KXO7stUQgCTr/HwVnhaD1cAI2GYNbByrVm8E3laGkF4I7EYSSF5nr87xCOLFhWztpi2e2Lslv5P8 WbKr5NuSaj9jwgMcAwRtafWNcXoDnuLTJZDkwZK/So6WQOhulFwj2U/Cn/8I9K14XdH5ulDmCOV3 lvQ6R8d4MCGyf5eQ96SkbIg9pJf0u4e40YNL/fC+cv05CQTzYeV7rPKFiEayfK32IYOUz3SMXXT9 gFAm3uWdJZRzpIR6ER9CCYHHU88A4hDJ7yWDJXGgApGGtH5esqXkTxIGK4dKwJvpIZBwdGEgQ/4x gAle7gskO0kgrTdJ8ODjAYe0MtUGjCHr2JyBEuT1eAk6rjh16tTn1ltvvW8vuOCCmcd4kUUWKR1x xBGlXXbZJfMyQ5bXXHPN0pAhQ0prrbVW6cgjjyz98Ic//EjTMl5WegY0vBEYKsH7fYhkOwl1vzro cn0oF72WC3qYLEcremsEWhABOtPfqxPdVZ1p9rrRoeERsM0a3kQ9V1D3Yj9eFfc8h6ZKyWvwu/CW Chc8s3gmKwNe1nSuMP0YXmJILl7ltyRPSfDQ4q3FE3t/ByjFqRxcXkZymGSdEPdVPL/SgznSXwx5 QXiZFgXZJeCEgyDi0UUvCO4opg8oHXo9rC1EkH30wwuLTpBIpoLE6Q7c43jHmXcMaU/bA8cIpBli zrVHlC/n0jXz43X0iOkhtexDQON1BhOcw1sMNhBSvMFPhCkLkeDqVBaoOwR9Pgn5UecnFfcj6UC+ kGHyY5oGU0jSQQB4/Fvn39N5dF81pIeckhf1ZcAyRnEmhThMDwGj2yXgc3rfvn0vGjFiRGnllVfO pl+sttpqmWLMTUZi+OSTzx5ps8wySxYvBHSjLGxEfeeXYLMhEhJA3nmbMV468NMuprO09L8I7Fku NynvtDgCdFAD1ClM9lSMwrQE26wwpuqaorr/IGd40iB2EAOHzzyPvO7/vraQtsnax9PH/Nx3A0AQ 6I11HiIFCYL84PXEAw0hGyHhfoEggyuez88mtn4WIIswLLbrKx+mEEBW75QsDblVWXi459U+6SBU 5ElevLInHWm+LnlRAkFnekFbyJ+pCrEciCA6kc9ACR5u8hkqWVbCdAjCNyR4jyF0DBIgoBBM8sbz u4+EOjENJJtXG9KlnnFIIXO0IecfBgwhuAws0OkoCV7W70rwtEL6wRuc4UdgSEDX6NXmmMECbfSr EgYgkPQ0LgOHCZLBQd/0yzviRjyY23yf5GEJdafMiE+MA+7EYc46XmCuD9HHfRPmmmuu0jPPPFOa e+65S2+9xXhIFXvvvdKnn/7/uIKP/4iz0EILlR588EFsTFuZKMFeDE7wzOPRZk7yPRLmVtM+sjeu Waaf1T0OhsKp1tqYLLeWvV3b6gjQeeENYOtQDARss2LYqctailTwgRgPZ8gSxMBBCIikPipoICt4 WZlnzMdnEGemFkSyzLQDiNRSEpgS+P2Huf2Ke7n2RwcvJXOOme/LlI4nE4CHa58pBng38SJDVCFR eFh59d8/eDiZOhB1gkBuILlDgueUaRbzhKkQTGFgmgXEE+8xr/YJV0nGSvBSMq2gTQKBZ07u/UrL VI4saP8YlbmHdpkq8piO+VAR/RlMMS2DfPCKMt2B+o6X4DrNdAyBsiGAkOMzJVtIblNefJQHucab ytxg8GQqCNNUwPpYCZ7lOJ0DXOJUFHQ7TOkh6xBLpqBgi0tCmXhl31Cc2xTnt9rH8z4i0QmCTN3J 5wLF2Uq74HhuqOM/tA9BZgoHca5SnJ+GOOiDze/R6he/YQrGZpttls1JZq4yYYsttihxPoahQ4dm BHrHHXcsDR8+nOfcOOV5QxhwYS/aF1igI3ZAlwsZHOl8poPC45KxSR1abtdkueVM7gpXQYDXjs8Y mUIhYJsVylzTKQupmcJZPZC/pw3eQeaBXq+HNMTDIUFAmEAoy9MmdAxBKwcdQ4irBl3DO5wF7UOA D62MqPP3hnOQT7yYWZBtFtYGsprNQVY85tPGvCChSAxXJtfw2KaB+dKkH5GchFQSmJ+LTBcU/4T0 pI4ZSEXPM5cg+KMqEsZ8KY82ls4XLtdd11LdY72OSfIiLQMB8pluygpkvqLc7E2Izj8Yz2v/xMpK hfbNB3ZZgDBX1DHatmxjxQHbMr7a58O86zfffHM84qUvfxlH8Gdh/fXXb1fkDjvsUD7eYIMNSpq6 cZfSzhKwjDrEsvA0l4PiZFiGdlNZlZY6NlluKXO7stUQUEfAnKyjdc2rYRSkidhmBTFUx2oyVWAJ 3Xd4OXlLcGsFkSp8BZuhArIJy6rRNzKHvDzhtRnq1gR16KN5y92qhj4KJH46/aZb6Vs5sslyK1vf dU9H0HzMgDgUBAE9vG2zgtiqUk19dMSHVMzjPFR2PJ/rImUba8PcUgJLaLGE2f90fmnt86o9BqYU jApphmob56gyp5U0U5SG+Z94q2N4QueZvoCHlDS8YifgPeQ39yxPhnuOD5liYE1b1u5lnidp4pxN phBQzie6xtSHz76s+iyM1HnWreXZSppITHgTQhrWt+VjLebRxvAoXj6dZ44o83x5VU5g6gBppuka c2NXTtKw8sNzOk9cyonzaVmD+Rri6dpgbVZK0jyga//Reeb5kobyCG/rPNMtSMPc4HR+LT9BGafz /N2UKQyRM/BtB1MTSMM8ZeZQxxDTMI+ZciKje1NpsmkWSsM0jy8laVgh4yWdxy6kyTzZCkxnyLy+ uramNsxpj+HOMGhmCgHTB2J4XeczT6nS8BEeU1NiuD0MAAbqBB/MxTBR5zNvr9J8R5tByTUGciwx xxziHybnX9H5zPOsa2trwxzvGG7WNdZHZm4EK5nEMEHnsylGusZ0l8WSazfq2ps6z5xi5mXHwEd2 mWde15iKwxxpwndvvPHG0lJLpdVLUlXZHT2a2TdlG844sq+2Q8Bk2Q2i5RFQB8QErx+oQ2r3Oqzl gWlgAGyzBjZO11SDqEFymTMaA8fxgyKIbyRMEMF4nripZwyiNDBkwOCpszRcJ00k5RDfmAbimZYD qYyBNJGUo09MQ5w0TSS6XKcMCCMhfdZWllOZJtYPkkk+eHQry4nkOJYTdY16RZw60g3MYh6px5iy 0zR4/4fo3BUB50iw01WDKtPEfNGfcuLSDNg0hso0MV/ikiYS7NSBwWAl1S1Nk55nYBID+FdLQ/7p eQYmnaVBtzQN87E7ShPtzTZNk04xYmCQXusozZtJOWmam3fffXemfNA2ow2xy/wSBiPtpuokeTDd ibqkNkwue7caAibLbhdG4LPOeUM9FK4UYU4f3samcRGINuODIf6Y5VfEjWur6TTTMlY8yJk/uqnu OzyMt8iGfNg0XdB5vieo+k1BRwNcnWdlA6Rd0HneQ2ee7CrX+OAt/egti4I3WJtzO0jDh09IZTl4 xs/uIA0ffCGVaSCTfIRWTbdHdBKpTAOZ5AO1amkgUuX5szGC6sMA4bQO0rSbGy3b4C3dTXK50p3a QZrKuctZNMXnQzQ+mqum2widRCrr87ZOnNxBGry4mSc3DSoHAjrd3OCgw63aIpVpWDqiozR4sstz s2NCPMUzSFP+MLFCNz7m66gcPoishg0fEnaUZnhlAtmIQURKlvG+7y/hw0xskPaNDKYYKJgoVwN/ BudMlrsJmKM3JQI8DHkdy6vGD0y8CmHjaDM8ah7gFMJk7ZSEtD6te21f3XMsWzVUW14v85ocMufQ GAhAqugb8WimHtvG0M5aMChpZxfdR5+tIaepTJXXDFfPETBZ7jl2Ttk8CDDS5lWovZPFsaltVhxb VdMU+zHQYY4tv/1lziyrFqytfeb9/rOr1VN8VgRgTi+e2efj3NOYXtcHap/5ttzjDLLwkPIaelXF ZemvXgvS5QsqbHGV+2ivFRoKCvOBmY+Mx52/2T00Ix0UfztdZwoAA5vJOiYtc82ZYz3d6hBdrY/y +aLismTZdF78zvJQ2mwt4vC2IYse5hgzhzud5tFZVh1eD/OcWaquy4M2pWE6Bb/ZniGmXVFKebEC ycC0jh2lU9yFdG3+8CYFLJjfj50Y5GRf88Wga2vMSD9dX0FxpyjOfwKu3CPf1nE2X7rVg8lyq7cA 1x8EXpacIDFZLk57sM2KY6tONQ1EZx89sFdR5I20XVfnpnvl3kFGzB0dJ1lVMlhSXpYrxOccH3Mx /YJ5x3tLLpL8RvKAymL+LB/CQRLaJPOpbP6cxtxPXvEPlEBC+ENbeQ6trjMfFsK/sM7zISDHrKjD esB8DMZAgA8H+Wjuk0AOIST89IM5snyIls1H1THl87e3bHpGotOLOsfr/ywEUoYnkWkeEDTqDqlZ VPI/xeW+KAfF5wPEuQM5pz4QYFa32F5SJnZhQMF0mKdC3n/SlrmwTAthiTQ+4uPjMn5csTZ6KM/4 gR8fRVKXsToPvniiIWxPUf+gN3HadMzSdUMkgyR8cMl5PpSbUKE3pJgysqknigdXYUAElni5+Ysg 0w0gtKxTzEeV7GMDPKsDJe1sput8iAlG1JE8iUOdn9W5dP4x+bE+NV7bUSEuWPARI3/VY6pIpc0W 16kMU6VjrnpfxcvmJwdCC/llCT6OeYPCh30MCvngk/rQjhbSMQOZLSV8BLqtrvE9zSAJH5vSlojL oC9rc9r+TLK6zu8Y2ib5sOY104Z4U8qvyvnlOYO0w7XdTsfjA+6ZzdApBD5epD1mZFmBKRuzKy4f HFJnbPl5peHe4D6dqv0nkvRNvWuy3NTmdeW6goBueB4+D6oD8NJxXQGsAeLYZg1ghBxUkF2zOcCB LHapBKX5l+JDEgdJGPRWBsgkK0Hwu2iIcZyvy08XIDYsRMu8TzyTzG+FzOJxZgUO5lZDtCEp39H5 cyIJ0jFEEnIBiblYW4giH1b9RXKg5BSdZ4UNVlfoE8jZK9qHeFIWq2ng5SZOtspCICaQWIg8pKiv zv1DZUJSCftKrpTwkdZBkiMklP2wpJ/i8mOLLK72h2jDqgroh7cSbzZTlvA4lqcu6RrEDRKd1VFy k4Qff5yVEMuzdHyYjlkZA734WyAf8kHsmNc8G3pqC/ncUYId19Q5BijUDdIO8bpGWwYErHwB7ug1 q/YvU96Zp1n74A7mrISylLbM7f1VKAeSdl7AFXJKXcgDgs4PNJ6VsFbwBuQrWUNxz9MWog8xxw7M L4a0gzEOku8RR+VjGwLtZVfJu6F9QEp3lkCYOYfNIM4QVfJjYPSi5PXQvvbR/iWSyTrGiw6282of DJlDTLm8Wfm6ztGGEAZE2AkMId6LhjoyRQl9iMsceOaAM9ACG8ogLmVgOwZykGxsyzMNwsyvttGV urEyx3I6XkNbBg6xbcU596QHxxiyciW0oQskfDfwR6XnLdD3iKT9BYVb5eA0yaJ5dk2Wm8eWrkkP EQid/ud000/sYRZO1ssI2Ga9DHgvF6d7scuvwINqPNDxBJa9sInKeA03UZtZEoIgGSZhOgb7EIQ7 JZAuSAzkGfLAtA2IMt7YD5XvoUp/uvbx0MUVDfDi8TEa5PEnEoh2fKbGFSAgaPdJXpfQv+ClY9m1 Pym/w7SPR5i0kF3yhQA+LYEEQa4gfHgKYyB/9Ibksd9fgsePvNCf8iKxhlBDrBkgQGDx0lZ7ewaZ mkM6/V46HRfyZ/WLW3VM/pAsyoAosg9Bh4zdIEH3gyU/lawteUnygvI6MJBDyofwMcWG6TI/17W9 dA3iuZnkFAl15KO2GHhLcHU4YHCAfVZXuu2U7tigC4SaqSD3Ss6RgAVCfnigB0kYFP1Vco0EjzTT CRjcUBYEH1tDAkmXepapM9i/IIH4tkkGBHwYCJH2x5JhIS+24A9p5aO6Y5PBzco6htxyHS/x+pL/ 6voZqgt6gw/lnSSB8G4YdIL0DpIwzYJ4ePdj3Pih5eY6xwCB5fViG6Et0i4ZZPAm5IAwWOBtyl0S 2tlJOr+Vzm+ife6bSJa12y7gWaZ9gsX3JUMkDETwvF8joV0xEDBZrkTOx0agSRGg8+NBsYs6EX8l XAwj22bFsFPuWuq+xaOLd/H2DgqDhEBkD5fw6vgDpaH9QBwhFpAASAZTByDpyGDF2zkQikgwIdgp 2ZykOGMUBy8d/QYEOfYfkcgy5WE3CeQOHSBOvGonEB8SClFfSzJBgtcOwglBgqCgFyQ6EnSIVfQK Q2Y45rfWHwVii44xMA2BfPGaExeCS1mVgXMxHfoTl3KpA+T+gJBgNpXDT0p+r+MzQtlMe4Bw4Sln UADJw4NNoG7kl3miQ9nUj4CHFeI7VIJ+V0niQAfSiScYfCDS5BH15rU/5zlGH9Ylhvxix5d0zA+m BmufuoPfPRJWpIDkYgdI+gjJHRLIHnGoL3lgGwLb0RLIdCw7ls824sWgJdqcuuKhpyy2ccBCXOZY g88E6Ub8tD1xzBrPz+vaOtqn7YEpeePlxVOPjuj7lgSyz2CK9oQ9Y9ygemYH6r6XZKdwkgEhOMYB XPqMS9sLOKSDVMonDdMyfimhrUGW0R/7oAsEviWCPcstYWZXshMEuPnp0Aeow8LrU837YhAbCwHb rLHsMTO1Ye7uyrpv8V7yahjyzEd0kAoC9zZ/oItkiHOQAMgSRBriDAnAW4jneCXJXcoHrxmv1+fT Ph4/yAMEJQZelR+qA15xj5cwr3MencMrDcGBoDGdYJQE0rmqZISE1/YESCICsYI8QhY5xnsLGcIT iucW/SL5grhwjWkNnIdEMz2EaQoDQ1kh++xV+38l1HMbCVNDwACSw7kY2jgOdYQTQMYhipHYgd8/ JcyhHaUtnmjIPFhAjEdIBkkgU5BWMCVgB/IbKcE7DLYQMgKkdT0JdQQrSGGc/zpY+5BXCCMEEgL4 lspmOsceEkg2XvrBOre7tmtKIITYiTTohceZvMEJTLHfvySLSLDvMxIGR8TBXtjnZQkBXPGe44nH yw0e/QM+YAGGYyVMRWCfNjJQ8pCEAdmxistKLxBnsJ5Tx3j2GSRhx3VDXnizaVPoDXZghV3o274j wXYjJOiYef8l2IUtcakXZPwbSj+XykPP6FkmPwaQBOwBKV5WAs6QdvBYQUJ7ioE8h+gaWBLAI9aX KTJ4q/Fgoxf1IF7LcMiWqWjSILxrBCoRoIOlk2frUAwEos3iw7cYWlvLPBDA48ar4hi4l3l9HMky W8hoGiAxlwZPJMRviAQiBhFhzedHRBrwno2SQF6+LTlD5yHFMUAmIHiL6DyvwyHqlMur819LIFJ4 UvHyMZXjOF2HwFweMsAr97LOP6rzlI1H9aSQ7kFtNwi6QDSzoLgnK+6enJcwVYJX+8RFR1apSOP+ TXF/q/MQnXO23nrr/RdffPFnjjzyyDn12+OoA3kyrxVSRH0v1vF/dXyN9iGsEC2ILeQTDCG2jygO XnLqe4I220sglaMkENvYjzLFAdswNQE9GAzE6RUQRV7f/4x0ym84+RFCHfGK4mk/kEGOyvl7iAtO fCjIB5XgDMZ4jCn3PEkfXWOgA7eBzF5PfMl1Eoj1O8EO9Bu0C+JcqHOjYvnaMsihHTCF4jicJ8rv Uu0zhYL1ppme8UKwGQMf3h5AYm/SNebB43Xn+DUd369jMMS2D+p4qo7Bk2khTIfgYzlwgsw+K2Hw M5b8iS/BLugIbmB2kYS6QlbxArNlwEKbhywzzYK2PUbCh33U83xJm+SaEO9v2oIjbyQYBMVAm+IN ALoRKId568yth7Dz50z+jnmc9mnTtLmTk/RNvWuy3NTmdeW6iACdzFNdjOtojYFAtJnJcmPYY6Zp ETzG5XmTOoaUpccQ3JTkQsgiWWMfMom0CzrPq2/CiCCVUZ7TieGQiXhB+zdXAeKo5DoEFKFcCGgW tA/pTAPeWGS6oLjD4kkRF175s5oDJKpa3BM5qXifDB06dH/J8ptsssny++2337w6B3GEXFE+xAyJ +twV0vH6nr5xPsWBlMUpFjEeHl68qTGU+1HFzwi1AlMU8NSWAwRUBxC6NG16nfnG6TFk/JiKc5DM NKQ2Z798rH3sXdYhlD9C55B2AYIbTpSn9egcXmYk1Sm1GSQ3G6iEuGk8SGh6zAAKyYLix+sv6RAh xDZTWY+IKQO16AmH3Me8+G06Hm0GYpktlH/EARIfw3S4Kx6e7zhFKFWZPPAmI+zT3iHcLRVMllvK 3K5sNQR087+iDuavusbSTZ6CUYBmYpsVwEgzVhEC1VbkWqgNtiNvM6Mu0gHva0aIOwnT3noLJ2+p tMoqq5TOOOOM31x66aU7HHPMMWdPmjRpmPKJXvhKkgSxP6yzzH29cRCQLSfreTbMz7P62sRkub54 OreCIqAOhrljiENBELDNCmKoKmpqGgCvpXfSQ71yekSRKsXAuhHebHRFj6/06fP/qg4aNKgk73Lf HRROO+20XzzyyCOXDR8+PE6R6I4N7tF92NadBI6bPwLuG+uPscly/TF1jgVDIMx9+6E6GOYuOhQA AdusAEaasYpxznn6ZX7hK9XAFWDu63RhjjnmKM0666yzvPLKK9scddRR2yy55JJdrsLll19euvrq q/lQ7KYuJ3LE3BFw35gPxCbL+eDqXIuFAB9j8CMCPviJyzIVqwatp220GasYvO/pM8VqAH379uUr /OPD/MdiKV9AbdW3fXPatGl8CFcO8iSX9thjj3+OGzfuEJ3c/LLLLjsUj3NXw9ixYyHLn+NjOtux q6j1SjxWIeF55r6xjnCbLNcRTGdVWAT4EpkpGCyf9IGJVyHsGG0WvwIvhNJWsowAS1vNJ+FjPIf8 EZhnvvmAW1/VjRlTkhf5tVtvvfXwnXbaKVvNQP3ep2+//Xa3tPjww3RJ3m4ldeR8ESg/z1SMnT91 wtpkuU5AOptCI8ArYb769sd9xTGjbVYcW1nTmY9AP5Hj0ujRo1/VR30Xv/vuu0fwIViiVvxhxczX 1BrUigCT0/08qxXFivQmy3UG1NkVEgGW4Blmslwo29lmhTKXlZ3JCEzVh3wsnXaBSDJL3jk0LwKs YOLnWZ3ta7JcZ0CdXfEQ0MODPz49rFeR/T0Foxj2s82KYSdr2TAI3Kp7ptoa0A2joBWpDwKyM/Nj /DyrD5zlXEyW6wyosyseAiLJfCn+edbuLZ72ramxbdaadnete4aA+jZ+i+zQAgiob2QKxvx+ntXX 2CbL9cXTuRUTgcWl9n7qZHb2V92FMWC02S7S+BO/ESiM3ayoETAC+SJA3/gHnmfuG+sHtMly/bB0 TsVFgA/7GI0PUAcz2cSrEIaMNmOZpPRDpUIobyWNgBEwAjkhwFsEVpsZIPnst40ONSNgslwzhM6g CRCIP0hohL9xNQGcvVIF26xXYHYhRsAIFAyB2DeydagTAibLdQLS2RQaAdaifFJislwcM9pmxbGV NTUCRqD3EIh9Y++V2AIlmSy3gJFdxRkjwIcQmn7xN8Wa1VMwitFabLNi2MlaGgEj0LsIqG+c6OdZ /TE3Wa4/ps6xgAiog/lIaiMOBUHANiuIoaymETACvYqA+8b6w22yXH9MnWPBENAo/AtSeSN1MGcV TPWWVdc2a1nTu+JGwAjMAAH1jQvp8sZ6np1poOqHgMly/bB0TsVFgK+Gv6dO5hJ1MO8VtxotpXnZ Zqr1+54+01K2d2WNgBHoGAFWCFqX55m277lvrE9TMVmuD47OpdgIfCr1p0hmVwdj4lUMW5ZtBlku hsrW0ggYASOQOwJp32jnT53gNlmuE5DOptAIsAoG61Kydq9DMRCwzYphJ2tpBIxA7yLgvjEHvE2W cwDVWRYOgZel8fEmy4Wym21WKHNZWSNgBHoJgVfD88y/OK8j4CbLdQTTWRUTAc3p+lCaP6opGP09 v6sYNrTNimEna2kEjEDvIuC+MR+8TZbzwdW5FggBkeTZpO4C6mQmFEjtllbVNmtp87vyRsAIdICA +8Z8mobJcj64OtdiIbC41N1fncxOIsyfFEv1ltU22mxnIfCJ3wi0bDtwxY2AEWiPwGI6PIDnmfvG +jUNk+X6YemciosAH/bxgd8AdTCTTbwKYchoM5ZJmlwIja2kETACRiB/BJirDLdjec238i+uNUow WW4NO7uWM0agry7PLuErYodiIGCbFcNOvaalBrq0iQXCfcxSkG0dDXzDT23e0fUPuqOg0pE/5bye 56Ba5fRDL5XBMmDtgq7N4jdg3bFay8WNfSNbhzohYLJcJyCdTaERYC3Kx02WC2VD26xQ5uoVZRnw /l7CW6LlJMdJbq5CNn+lc9+SvCfieaKI5/iuaKe4Kyser7bfhMdKPu5Kuh7G+aXStUmGp+mlw5w6 PkByUA/zdbLmR4B153meOdQRAZPlOoLprIqJgB6Wr+ohdKy0ny1Pb1Ex0WlMrW2zxrTLzNQqeIl/ p3uZOZvbSV6o1EfXtta5foq7k/a/pP1fh3sfov1HCa+tj5QsIYFQD5KMkIyTXCoZJnlFMofSbUpe krclc0mWlTwqmSShnMNVzmvooLhLarOmji/R/sbaf0qytGQRCST8GMnEUOYPtEWfBxSXaUZ7SPBo o9c3JT/T+au0ZRUfyPuTkguUd57knWo4FAABtYOJfp7V31Amy/XH1DkWEIHwoPHDpkC2s80KZKze VfUPKu4ktY/pyLLOryY5C3V0/TmRir9q93+SwyTnS74YCOjd2v5OspVkS8m5knslD0t+I3lI8mvJ NRLKgcgSF5LO1ImLJPtJ9g5VX1DbIRJ+Qbym5A3JdyUQe9Z43ytsN9P29CA3abuS5AEJZB2v+ZmS RyTvSnaV4D1Hv59JLg5ledPiCLhvrH8DMFmuP6bOsWAIhPmLG6uDOaNgqresurZZy5p+hhVXu5hD EZir2dUPm4jLtwpzS56Q8HEUUziYynGx+oTHlSckmIE0BBdPMR5dnp1P6/rJuv5t7V8R4jIH+kLJ i5LtE2VZZSfOj8bzTGiTnBPi7qAtXmrmIz+lPOmL5pfgQf6t5PuSZSR4tZkGghf6GxK8zoMkjyVl ebeFEQh944/Vjhh0OdQJAZPlOgHpbAqNAF8Nr6NOhocjc2EdGh+Bss2k6vuePtP4BuuqhroPmc4w N+Szq2mSeEx/IB3EtlrAK4t3+QmVs7y2m0vw7MZfBEOSIdAI84MJkFiuMzWC60h2rDxYo53rkHQC 14iHpB9YZR/sKT7nmWZxh4S0lI93uBw3fNzHFA/0wnv9kuS/Esgx+ZAO3SDkTN+gHtl0DwcjIAQY +GXPM23fc99YnzZhslwfHJ1LsRHgtelHEh5+Jl7FsGXZZlKXD1ocCo6A7j2mHPxIMiiQwJ7UCO9t mSAozw11PEGEgXm9TL24UOe2lOB1e0cyTOfe1vHZ2j9JgteY7xeYNhEJN0SU/oEtHma2eIr5rTBL GFLm60FZrjGtg/bJ9RjGaOd5yeESSC5piMe8ZcgyU0AojykXEGDSUsaNEjzLtPGRIR3zn1eQMNWD j/3woqO/gxEAAdoeq8EwMLPzp05twmS5TkA6m0IjgJeIe4EHn0MxELDNimGnGWnJlIcsiKwO0YZV Kq6VnCAC29MBEAQyDSN00O5HQ8r7YpV3K0RC+xBWSPT9Ogeh/Uj772ifOcJ8rEc4SkLf8Dddm6pr R4StNtnxv3QNIkv4G3Hx5un8wVERHb+rw9N0PK/227SPJ3k+CVM2ntE5plYQIPPX63gyHmZtP9WW lTc+DPNQwQqvMz/i+Uj7eMpZAg8y72AEQMB9Yw7twGQ5B1CdZeEQeFka400yWS6O6Wyz4thqOk37 9OmDB3eKyN5a2vJRG3NwfyPSV9MfNCGvaWE6rrqOss7HecPl6Om5NJ9kP+sf4nGy5Xy7ayFeuzWS w+vwtpiH6n6y9vkJUjsdIcppesh7R3WqVo8eNotpfft2b1le2bCHRTlZzggwr53nWbt7Iecymz57 k+WmN7Er2BkCeuDw4H5MDy8+rjFh7gywBrhumzWAEWpQ4dNPP2WeLZ5XGNqZsicf1+E1Zc5v+lzC 04t3Nc4ZjqXivc28wro2qzbZnOAQOkozVWl4PV2vNFOCZ5k6MI84hhmVk6ZhqsUs0p/5zl1N01E5 nE/Zbke6fRq90Co3TTN3d8lviJ/iXkOLcNJ6IRDuCz/P6gVoyMdkuc6AOrviIaCHBnO7FlQn06Wf ExSvhs2nsW1WbJtOnTqVObcIy7yxhFpGlhV+Klk3qR1zi5nmwJSFIyCX4drYcMwhy6YNSdLgsSU/ VpNgjnAkkf/R/l9CvC20ZRWLGE7QDmsfLyRhGbkYntMOUysITBNZI7nGXONnJF+QMFUiBs5xjbCN 5OvJNfIiz0Ulf0rOUzY6EPio72vJNXRGd9Z+PjA5Tx2pK2FHyVeTa2A1VsJSePsn55kuwnQQws6S FcP+wltuueXTc845JwOP6DCYpjDrJ598Ml///v2Zi93OlTxhwoSSvNHvy5Z2MScAz+zdMAhayM+z +lrCZLm+eDq3YiLAWqd/UCdT82vgYla/kFpHm/FTBuZv+o1AgcwoksUHd9dJ+JDuIt17c4bpCJfr +MqkKnEqA1MT+NAthtTerF18WZU0TLXYrYM0zG1O1yWO0z8ghbt0kOY8nb8guRbT4CHuKA0f3rFG cwwxzYQZpGHZuNRLHNMwj7qjck7VtZS0xjSsopGmSV/NQ7Rjmj6jR49mcDFQErFlHvRSEog4g47K edGk9QdkiXEbZJe+8UCeZ9q6b6yTUUyW6wSksyk0AjwcuBcGqINhDqGJV+ObM9qMP5xlczwdioNA v379+JEHH859RbKN5G7JlUy50LbdXF9qFe7Jqj8NcpoMn6pzvTvBrTINc12RclB/CLnmY0u+EXgz 7RvD1Jhom+I0vubXFJsxPYblNbu63njzo1JjDU2WawTQyZsCAbw4zBus++tEPVDosCB0PFR44MT5 kh/3NimXLniOmKc4MRCMhjCe9JqXB3JHD/yKh3cWN9gqF5tVgsJcdp1jjux0JK4rADKnNs4T7Ur8 zuKEObo9bj+hTTKnNZu/21EI84chVGD+dj3bq17vM/VpDuXJH/EQh8ZEgD6R+yxb4SNVsZ7toTGr Xlit4vOse19sFra6vaO4yXLv4OxSGhsBXiUyL7KuZFlkA5LMK2Jen0KS79fmCgnzG5mH2GseUZXN X8l4HYt3jg+rGun1KSsi8Pvgjn4kkbYe5plCroiLN/KDXnho8wc3Xpuz3FhPwuHC/6A6EuZDpQRz UvnlcU8CP7dgzd+xnSQ+JLTTIdpeL6nmvXx/lll6/Bip6/3WEyCcplME4vrOffEk98K91qlCjtAp AvF51mlER+g6Aj3u5bpehGMagcZGQA+AV/Ug4IOc2ev8MBioPF9UnruCgMpgTdUREs5/rOOVtd1e AhFjzuGPJczX5COiNgkrA/BREWupXpJ8xc7fuyBMrAPL73Ah5XwshOfzj5LPSfgZA/NB+XAIIkq+ zLd8WsLPV7iO15slu/h4anEJHxHxcRJz3Vh6aKxktaADcx/Plg7ZMlZKz1/ImBvHa/RTJLxWpz7b SfiAiQ+zqMfgcIx38vMSdDpTsqfkXskNEvSfpjy5DpHH4/lXCWvPDpWsI7lPcrWEv1PRbzF/chnJ 0UrHB0yk3UDCB1qUzyv9jNzpOngcJKFu5Em5P5dQdwg39iEOZULCwRyd0IP5pvyKeJzyuY32EfT8 XYjDVIK3Jb9I0lB3vDroxYAIj34WlJbzEVP0gYCvqXxZXxdM0R878rOK0ZLhIV8GWMS9WTJQsr3i E/cQyZKS9SW0o9sktAHaCG2C17GbSKgfP86gDXBueaXfW1s8vGAJPltyXsIHYKTfVEJ7AQdWpMDW zBGnLTDfdVXJKvfcc8+UkSNHzrPKKqvwwZdOOTQLAmqXr+XUNzYLRA1XD9ssH5OYLOeDq3MtGAKB WNXb28r6qUvrYRM/sIFkUAZkiOkQeHuPlkAGWWsWYrVfuHaetqQbJtlaAhnCu0fYRwLhgzgOlOwl gTTzJTsEiA+X9pRA+n4iYZUPiBbEkHIgYRChf0sgoRDpbSUbh3IgyntI8H7zxTzkiy/t0RfiTvim BHL8ewkfUR0ugfhDHiljI0kkXAwCILroBXFnS/7oBxlbU/KgZE8JAwrwWUXSJllbAkbfkkDq8Sw/ LgGb8yUQUeqPB5/05EndII548glgCj4/CunxTKMz8agT2ECSwQ5SSn4I1ygf3fnxQ3wNDdnl47Q2 CaQZLy/xd5cMluApZyDB4IM0EN84hYPBArpDTiGmYLis2gjEE4xpM9iCQccvJQx2IPYMKr4ggdyS x7MS2gD2uUvCAIf6oQd2Zq7ivpKTJOhIfqwyQTnoTxvAzj8N+S6i7VjJtRLwOkECTiMl2Jg80ZtB JaR+qIQlF7cfPHjwrFdccUVpiSWWKC2wwAI65dBMCOTUNzYTRA1XF9us/iYxWa4/ps6xYAiIqCzM w18dDN7degdIUvzpwAkqg793cd/9TwLxhMhQPmQRosIyWJAY0vRV/BcUH29uur4qXs9XdS0jrsFz ijeVOOtJIFRX6fpIXYMs88HHpCAQHNx/TA0ZJmEJq+vIK3g2z9f+09qfS+fxwuLZhJxDam+nvBDI 50jFHaO4lEd9VgpxyROSxVzHkxRnsuI8q+0Z2g7ROTy0o7QPscXLGf/Wdpb2IX8MGiDdkH+8r5R/ iwRCixeUsr4sgdzjKY11xpsc60zaGBhUUF8IPd5ePOpXK+7ooDskGc80emObO3TtFl0bFHRgtYN0 IAVxRCe8tdiONLcqze1KA8HGDgwUXtK563UODztvCWgLkNiI6b91/czgIWagwWDqTsl8Ov+EzuOt Jm9sMU7nIPXYmxUbIMGDJQwqqOtFuv5i8HpD0omzhQQbXKtr/KEOEo8e4IdtwZP8eTPAh10MSIZI sCPX0JUttsZO/UN7JG90ApOLF1100V01B3mAlhBDPYcmQkBthgHaT3LqG5sIqcapim2Wjy1MlvPB tUe5qpF/TwkfUMcUyVWP8nGibiMAmVpL+F8o7OvpXYaoTFCe51VoFAnQATrPdApe/xN4nc6rbsgW 5CTen5Ch9P02+/xmF+8uZBKWQpwYr4/2IWsE8iA+hBaihHCdMiA8lMOWwLU5lC/xY/lMMcCzy7xd BEJLII8tFJepIDF/vLnE/ZIEQgWhjaSVqR/oQhnoEssjH+JETP6mfQgnnlfyon6QS44hvBBOvLVM 64Ak3xjKJ79Y51jHUExWF8rZXIJ3mjxinSHPeKo5hiRWyydOVYj5oQuDG9yo1LFaGjD5RHVmjV08 xnG+L7q0SajbNrqOTgx68DI/JqFelfUgrz6B7KIrWBEntXesD3GxbdpmUvuCA/hAgBmo3av2OVZ5 483mPrhewlsM8qH9Ula0YdoeyYe6zKl1eEvd/aEFgDkUAgHaxNpqHxdpy+/B49uVQijfokraZjkY 3mQ5B1C7k6U6IR5I35Hw0LxPEl/Xdicbx60NAcgmHksIHasy1OuBQJ7ME60MePHelVwq4VU5JPNj CWRtQwkkkHaAp/IMbfEUjkgywRPIq/ExkiclHDNVgnpAvCE3E0N8SCvEiO2UcB690IEy8TKyTyAO ehHQifyYTrCphHrcFK6xIQ883H+X/FPSJmEqBEQSgs15PMSUEfMDVwYjlEOgXHTCc8sAEe/uHyTo dLKE+KtLNpM8JWE6Cd5OiNwhkn9ImPrA1AkIbawz23TQAzFlmgKYIrH+6MC0D6ZkUO9/Sajzy1xQ wPuKVx9S+FPZ4rLQNs4L5XIN8lqZhmOmbmBb6kWcGKjT4hIwBYf7lecE5U09mE6xWjhPfHAhr9Mk B0og1QxOwI3z5I1don1JA+57SmgDx0sg6dG+xCUNOC4lod9h7jK6MEhhus93JfRD2IW+Ce/9CxJw vzy0R3BhmsbXOC+Pcj95l0s1fOiH3g6NiQD3C22B+6uejoTGrG1zaGWb5WBHk+UcQO0kyz56OMYP j+ZX3B0lkA6+lufh6ND7CEQvWb1IclYD2fN1kYs/VanOHwPpggyPDNMUIID8bhsidzZeWO0/qC2v 5d/WfnkQpf3/6Py+2kLWCE/peB9tWd7pHe1TH+a0EoZRls4xDYLt8WF7dNDhDZ37S4gL0crWTdW5 g7WFkPHhGfNl8SqhWwx4L6+QPIT+4eS1igvRyuJq/0p0CteyOuvcQ6QJ5zIddO6YoMvL6Klr/JI3 I+1c02Y+HUPWOGYwQJ6QcMgteuIZpc54oQnDEj3ZXUYCeUR/CCke6qzOAUtsxCAJbz35HBzSQ/5j uCXoSBqmxjAoyDxtIQ2EnQD57hPyIs7/KmzHQOACpcGD+66u8aHnN7TPgAhCAhlGCBDYaI+9FJdB CBhoN7MNUzWeDDowB5m4TIthINVP+0z5oT7MqSacHuIwVQXvMnblGUDcyTrHoII8IEeU82ttmHoR 33TdGOzHCiT/0/7Nur7A+++/f+Tee+9t73IAuck2sW9ssmo1dXVssxzMa7KcA6idZPmmHjJ4dZg/ uI4EMpN6nnpfI5cIeYKUTbeWaK3QRIKV5pOei0QzkJ8yGdVxNqCKJLFSD52PRDm7FIlU2C+T/oTg Zecqj2dwrjwBtQMdzlTaD3UteqKjHhmpDfmmebQrfwbltlXBaro8dQ8xB/swyVsQwgpMKwc9DEJv kUBcIfPtQlqHGeTTzqvWSZpY1zgXe7pmVIEp+jFgiKQ04pfaMSPKXcS1bJOO6qPzDDai1z/mm5Hk pJxqcdrZQth/zBSM7kzD0A9JpsPDJxoWAd5K0Df6jWfDmmg6xWyzHGxlspwDqDPIkocf0y14iPIq FG8grzSzoAdPnCMYT0VvVzY3MMmXHxLgoSIN59OnT0yDbckvhkZIEz1xlbp9lHizmF8Z5+eCVzYt InjC4lxX6lTPNPwSlA/OZqlSDj9vyEisrnWkG15LPK0xpGmYP8ZIn5DWp2qa4AmknJhmqsrPSJeu VaaB/OGZJG4908Q5r7E+1copk7egW2UaiDRzdtENDGLAa5yRQl3rKA32j/NsiZqmiXOveXg/LeGH H7SPDtPoOlM48L4z7xddqA+6daWcqDfeVJZPq0xD22EaRLX7N6apvH8r0zAdA914w9TVNGnf3ZM0 9epb5vv444/Ru8shfAiY3i9dTuuIvYtAeM5kfWM68OpdLVxadxCwzbqDVtfjmix3HauaY8qjgqeG L+P5wpz5g7zu5fVp9npUgXmVKyYF8fHXSxJeI0OsY2DuIp49ws4SPoiKgVfKeKr48GjP5PwD2j83 HDNHc9mwD4HjdTH6rCBh7mQM92iH18qEPSR4xAkQFdLg3ePjJXSIgdfcF4eDvbVdMuzjKWXeJZ6p VSRMP4nhNu1cFg6oJ/NkCXi6SAMxW1XCa+EYeAXMa34CH2nx1TYB4nKABE8gr7eZhxkDr76HBwJH nAXDBUgQqzb8W9shOveLJA0fl7GiAYSHecHMqyXg2UU3Bi3M/fx5kga9bg7EG3vwURmhLaSBfPNW gbmiMVB/cIAQ80p/QLiA5/RAyJ2Omcs8NEkDzuANgcTLGkkpUyuY1oNn9weSHyVpLtD+vRLI6JGS OKBini/1IzBvGomBdkP7gRTxSj8OWvBgxCkLzG1dP0nDXGumE8wbyuG1P4H2TLsmbCJhjmwMp2qH j9zAi3LiIHBsOCYemK0ddFhY2z0lkGGmNB0uiYMMpjVkUy2ExTbafCspZ5j2/y3B/uAWA3PA8aIR fimh/cTAea5T5iHJeQg7c4MJW0mYcxwD0xqY77uoJGLLNe75E0MkPqzjfogBm7woWUJCG42Bt0+n hIMdtF0puUYdGHx/UbJfcp5pKrFv2Un73N8xHKId5mZX9i0P69xZIdIu2tKPxEAdaCdp39Lv2muv fXTVVVedS95lBhKZN1z7n06ZMmVhzWN+X2svcy9Gu5Q++uijPpq6QR3L55IyvNtACOje4V5fWH0J 9nIoAAK2WT5GMlnOB9equX766acQoRESPIWQLPVBf4Y4xxAfoNlxIDvsPieBSMeQvmaOD+rKNDzE O0oTCUFlGh7iHaXJ5jPGkOjGQ7yjNDz4q6XhIT6yg/qk5CXFgIc4g4RqGETCVlmf+3UCktcuTfBE puSFgcP+6mQg8HdLGCRUpoFQp+Ql1Y15xZDWyjR4fSHy1TC4VSchx5VppigNH4ZVS3OjTt5UJc2H SvO7DtJcp/MMEirLeU9p9kzTJPvXaJ9BQmUa5kMzaKoWmL8cBy9cj1MRmDfL4KxaYE7wpVXKYaoS RK1a4KM+BgnYDHs8x+BHNmV+OISwWjhfJxkkVNZnotKkbTdNe7YOzqmShnnVHaVhgBAHseX2Id3G zyANA4QyaYz3FeSkIk16z5+cKpqkYS51R/fiCdXSgJ+kozTHdZAm7VumTZo0aU4JgwieJ1FPBrgM irjX470R3xhRXwZ/6Rz4Dkzn0zMZARwXB6ldMUDjjUjaDmeyai6+AwRssxyahslyDqB2kuW1uv6k BE/XceqETlcHlM2jTAhouyxCB1W1k3Ka2nGTDfD48wCfR3ji+TbWDY5BsBmec7zpk1vs/inPBa/s a2bQH1RNU6e+hcE/HvR2QTbiXoI08xfLbA5+GsIbnt7vgV1idxDgLSJ9I2+6yvPVu5OB4/Y6ArZZ DpCbLOcAaidZfk4PDl5fswwTX6Pvqi2vlv+u88/3vjouUQjEOaXMG8VLae9J4zcLbJbO0258jVtP Q17hp97mdgj4PitEg+BtAFO14luBQijd4kraZjk0AJPlHEDtJMtpImR8LMErrQ+0zzQK5jn+Tvuj tD1f57MPhhx6DQFWD2CKh+dQ9hrkNRdkm9UMYe4ZPKES+HiRgY1XU8gd7lwKYL55Ov0tl0KcaV0R sM3qCudnmZks5wBqd7IMryeztWdFltOPkLqTjePWgIBswNxVBi1z2NtVA5C9mNQ260Wwe1iUbHSu 7iu8/35T00MMZ3Yy2fA1940z2wrdK9826x5eXY1tstxVpHohnho5H6Q5zAQEhD2eL0bkDgVBwDZr fEPJRh2uNd342ltDEPB9Vrx2YJvV32Ymy/XH1DkWDAF5ThaRypuog2m3ykDBqtFS6tpmjW9u2Yhl 8R7TfcV0DIcCIiAbssrJprLhSQVUvyVVts3yMbvJcj64OtdiIcCr4m+pkzlPDwV7l4thu2gzloXL fnZTDLVbSsvB2Eb31eiOVuloKTSKWdly3+j7rDAGtM1yMJXJcg6gOsvCIcCyWiwfN7se7NkfAwtX g9ZTONqMP8F5gNOY9mcteZ4xfJ3f4XJ3jam6tQoIMD2N9bBZ2cT3WTGahW2Wg51MlnMA1VkWDgFW wfDSSMUym23W+PbyPdX4NupMQ99nnSHUeNdtsxxsYrKcA6jOsnAITJDGf7X3q1B2s80a31ynBRVZ Om66n5I0vvrWUAjwS3T6Ri/9V5zmYJvlYCuT5RxAdZbFQkDTLnhd/GRY/9pTMApgPtus8Y0kG/0H LXVf2cPc+OaqqqFsOMV9Y7GMZ5vlYy+T5Xxwda4FQkAPc/5QtUh8uBdI9ZZV1TZrfNPLRoOk5Vu6 r95pfG2tYTUEZEPmKi/qvrE47cM2y8dWJsv54Opci4XAYlL3QHUyO+ihwId+Do2PQLTZjlL1Y3+U 2ZAG+620ukNyQ0NqZ6W6ggD32R/pG32fdQWuhohjm+VgBpPlHEB1loVDgC/1+ShiHj0UJpt4FcJ+ ZZtJ27cKoXHrKcnAc+4wvclzlotp/zhXeR7fZ4UxoG2Wg6lMlnMA1VkWDgHmVDIVA8LsUAwEos2K oW1raskr/P6tWfWmqbX7xuKZ0jbLwWYmyzmA6iwLh8C70vghk+VC2c02a3xzPSYVX5X4A7/Gt1VH Gvo+K57tbLMcbGaynAOozrJYCGjaxUS9Kh6Gd9lTMIphO9us8e0kG52v+2pOaeoVZhrfXFU1lA1f d99YLOPZZvnYy2Q5H1yda8EQCL/jfb9gare0urZZ45tfNvqg8bW0hjNCwPdZ8dqHbVZ/m5ks1x9T 51gwBOQ5WUQqb6oO5sSCqd6y6tpmjW962ejX0vIx3VePN7621rAaArLhwjq/mWx4ghEqBgK2WT52 MlnOB1fnWiwE5pK6a6qTOVcPBeZ7OTQ+AmWbSdX3PH2mIQ32VWn1ju6rJ4KnqyGVtFIzRID7bA36 Rm3f9X1WiNZim+VgJpPlHEB1loVDgGXIWOZqNj0UTLyKYb6yzSDLxVC55bTkz5g8Y/jAD3s5FA8B liHL+kbIcvHUb0mNbbMczG6ynAOozrJwCLBknJeNK5bZbLPGt5fvqca3UWca+j7rDKHGu26b5WAT k+UcQHWWhUPgJWl8tL1fhbKbbdb45jo1DEL7aeufkjS+vapp+HLoG+OPLopZi9bS2jbLwd4myzmA 6iyLhYDm4U2Rxk+FP415masCmM82a3wjyUYvoqXuK6+z3Pjmqqqh77PiGc42y8dmJsv54OpcC4SA Hub8vW8xdTLPF0jtllbVNmt888tGS0nLN3Vfvd342lrDagiE+2xx2fA5I1QMBGyzfOxkspwPrs61 WAgsJnUPUiezvR4KfMzi0PgIRJvtIFU/9lf6DWmw3aTVnZLrG1I7K9UVBBaNfaPvs67A1RBxbLMc zGCynAOozrJwCPClPtMvBogwv2XiVQj7RZvNI23fKoTGrackA8+5wvQmz1kupv2Zq5z1jZI3i1mF ltPaNsvB5CbLOYDqLAuHAB8gsTalQ3EQsM0a31azS8X+ja+mNZwBAsw355flDsVBwDbLwVYmyzmA 6iwLhwBzKu+TeKmr4pjONmt8Wz0qFV+R+AO/xrdVRxqytrL7xmLZzzbLwV4myzmA6iyLhYCmXbym V8X86npOT8Eohu1ss8a3k2x0ke4rvJJeYabxzVVVQ9nwdfeNxTKebZaPvUyW88HVuRYMgUCS3y+Y 2i2trm3W+OaXjT5ofC2t4YwQ8H1WvPZhm9XfZibL9cfUORYMAXlO+Hr4Z+pghhVM9ZZV1zZrfNPL RqxUMlL31WONr601rIaAbLiIzm8uGx5vhIqBgG2Wj51MlvPB1bkWCwFeFa+uTmYePRSY7+XQ+AiU bSZV3/P0mYY02IrSqk331SjZh9VLHIqHQLzPWA3jXd9nhTCgbZaDmUyWcwDVWRYOAR7kLG01mx7s Jl7FMF/ZZpDlYqjcclryZ0yeMXzgZ7JcTPOzDBlLAM4GWS5mFVpOa9ssB5ObLOcAqrMsJAL+CKl4 ZrPNGt9mtlHj26gzDW3DzhBqvOu2WZ1tYrJcZ0CdXSERmCCtj5YwIncoBgK2WePb6ZTgVWZNbP+U pPHtVU3Dl903Fs5wtlkOJjNZzgFUZ1ksBDQPj9fFT4c/jXlEXgDz2WaNbyTZaBxa6r7yOsuNb66q GsqGH7lvLJbxbLN87GWynA+uzrVACIS1YBdXJzOmQGq3tKq2WeObXzZaRlpO0n3V1vjaWsNqCMiG c+j8krLhs0aoGAjYZvnYyWQ5H1yda7EQYOm4A9TJbK+HAh+zODQ+AtFmLE/2sb/Sb0iD7Sqt7pRc 15DaWamuIFDuG32fdQWuhohjm+VgBpPlHEB1loVDgC/1mX4xQIT5LROvQtgv2mweaftWITRuPSWZ 3jRnmN7kOcvFtD/fcXCvsXTcm8WsQstpbZvlYHKT5RxAdZaFQ4APkOYqnNatrbBt1vj2Z73X/o2v pjWcAQLMN3ffWKwmYpvlYC+T5RxAdZaFQ6BNGt8j6VM4zVtXYdus8W3/kFR8VeIP/BrfVh1p+I77 xsIZzzbLwWQmyzWA2qdP97hVd+PXoJqTdgMBTbt4Xa+KT1aSOT0FoxvAzcSottlMBL+LRctGF4eP jbzCTBcxa7RosuEb7hsbzSoz1sc2y8deJss9x7X/7LPP3q3Us8ySwW0vS7dQ653IgSS/3zuluZR6 IGCb1QPFfPOQjT7MtwTnnjcCvs/yRrj++dtm9cfUZLnnmL629dZbj59rrrm6jOELL7xQ6tu375Sp U6d2zyXdcx2d0ggYASNgBIyAETACRqAGBLpM9Gooo1mTnvHAAw/cqMoNlHT1NSMk2V/uN2uLcL2M gBEwAkbACBiBpkPAZLmHJg1/EPuP5nN110vcR2lZisfBCBgBI2AEjIARMAJGoMERMFmu0UA9+CCs q17oGjVzciNgBIyAETACRsAIGIFaETBZrhVBpzcCRsAIGAEjYASMgBFoWgRMlpvWtK6YETACRsAI GAEjYASMQK0ImCzXiqDTGwEjYASMgBEwAkbACDQtAibLTWtaV8wIGAEjYASMgBEwAkagVgRMlmtF 0OmNgBEwAkbACBgBI2AEmhYBk+WmNa0rZgSMgBEwAkbACBgBI1ArAibLtSLo9EbACBgBI2AEjIAR MAJNi4DJctOa1hUzAkbACBgBI2AEjIARqBUBk+VaEXR6I2AEjIARMAJGwAgYgaZFwGS5aU3rihkB I2AEjIARMAJGwAjUioDJcq0IOr0RMAJGwAgYASNgBIxA0yJgsty0pnXFjIARMAJGwAgYASNgBGpF wGS5VgSd3ggYASNgBIyAETACRqBpETBZblrTumJGwAgYASNgBIyAETACtSJgslwrgk5vBIyAETAC RsAIGAEj0LQImCw3rWldMSNgBIyAETACRsAIGIFaETBZrhVBpzcCRsAIGAEjYASMgBFoWgRMlpvW tK6YETACRsAIGAEjYASMQK0ImCzXiqDTGwEjYASMgBEwAkbACDQtAibLTWtaV8wIGAEjYASMgBEw AkagVgRMlmtF0OmNgBEwAkbACBgBI2AEmhYBk+WmNa0rZgSMgBEwAkbACBgBI1ArAibLtSLo9EbA CBgBI2AEjIARMAJNi4DJctOa1hUzAkbACBgBI2AEjIARqBUBk+VaEXR6I2AEjIARMAJGwAgYgaZF wGS5aU3rihkBI2AEjIARMAJGwAjUioDJcq0IOr0RMAJGwAgYASNgBIxA0yJgsty0pnXFjIARMAJG wAgYASNgBGpFwGS5VgSd3ggYASNgBIyAETACRqBpETBZblrTumJGwAgYASNgBIyAETACtSJgslwr gk5vBIyAETACRsAIGAEj0LQImCw3rWldMSNgBIyAETACRsAIGIFaETBZrhVBpzcCRsAIGAEjYASM gBFoWgRMlpvWtK6YETACRsAIGAEjYASMQK0ImCzXiqDTGwEjYASMgBEwAkbACDQtAibLTWtaV8wI GAEjYASMgBEwAkagVgRMlmtF0OmNgBEwAkbACBgBI2AEmhYBk+WmNa0rZgSMgBEwAkbACBgBI1Ar AibLtSLo9EbACBgBI2AEjIARMAJNi4DJctOa1hUzAkbACBgBI2AEjIARqBUBk+VaEXR6I2AEjIAR MAJGwAgYgaZFwGS5aU3rihkBI2AEjIARMAJGwAjUioDJcq0IOr0RMAJGwAgYASNgBIxA0yJgsty0 pnXFjIARMAJGwAgYASNgBGpFwGS5VgSd3ggYASNgBIyAETACRqBpETBZblrTumJGwAgYASNgBIyA ETACtSJgslwrgk5vBIyAETACRsAIGAEj0LQImCw3rWldMSNgBIyAETACRsAIGIFaETBZrhVBpzcC RsAIGAEjYASMgBFoWgRMlpvWtK6YETACRsAIGAEjYASMQK0ImCzXiqDTGwEjYASMgBEwAkbACDQt AibLTWtaV8wIGAEjYASMgBEwAkagVgRMlmtF0OmNgBEwAkbACBgBI2AEmhYBk+WmNa0rZgSMgBEw AkbACBgBI1ArAv8HMH4iHWFGkb0AAAAASUVORK5CYII= --_004_B26C1EF377CB694EAB6BDDC8E624B6E723BA5043SN2PRD0302MB137_-- From rrichards@cdatazone.org Fri Aug 12 12:55:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC36B21F8AD1 for ; Fri, 12 Aug 2011 12:55:58 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEe97rNfNJtS for ; Fri, 12 Aug 2011 12:55:58 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by ietfa.amsl.com (Postfix) with ESMTP id 745CA21F8ACE for ; Fri, 12 Aug 2011 12:55:58 -0700 (PDT) Received: from dsl-67-158-171-203.fairpoint.net ([67.158.171.203] helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1QrxqL-00023N-Mm for oauth@ietf.org; Fri, 12 Aug 2011 19:56:33 +0000 Message-ID: <4E458571.1070500@cdatazone.org> Date: Fri, 12 Aug 2011 15:56:33 -0400 From: Rob Richards User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] TLS 1.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 19:55:59 -0000 The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). Based on a thread about this from last year I was under the impression that it was going to be relaxed to a SHOULD with most likely TLS 1.0 (or posssibly SSLv3) as a MUST. I think it's a bit unrealistic to require 1.2 when many systems out there can't support it. IMO this is going to be a big stumbling block for people to implement a compliant OAuth system. Even PCI doesn't require 1.2. Rob From wmills@yahoo-inc.com Fri Aug 12 13:58:25 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350D811E8087 for ; Fri, 12 Aug 2011 13:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.172 X-Spam-Level: X-Spam-Status: No, score=-17.172 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLgGLZbpPKj5 for ; Fri, 12 Aug 2011 13:58:24 -0700 (PDT) Received: from nm24-vm0.bullet.mail.sp2.yahoo.com (nm24-vm0.bullet.mail.sp2.yahoo.com [98.139.91.226]) by ietfa.amsl.com (Postfix) with SMTP id 506C411E8070 for ; Fri, 12 Aug 2011 13:58:24 -0700 (PDT) Received: from [98.139.91.64] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 20:58:59 -0000 Received: from [98.139.91.42] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 20:58:59 -0000 Received: from [127.0.0.1] by omp1042.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 20:58:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 863410.42668.bm@omp1042.mail.sp2.yahoo.com Received: (qmail 32577 invoked by uid 60001); 12 Aug 2011 20:58:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313182739; bh=tIijU85iU+mrVn5UKankbrvNSMombiSdbVt2Gvq+7Ec=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Y7TrmYCvsM7QcQSXHjd2ZqQkwBCqR2lRaEY+PJwKiWu6cYvbT2U4dAGYNi27lFF3JOU0b2hne5PMeipg4l9K0gAAetOtMWmhxqfmdfzhlOKcmNBrL8gn+n2djGrZJPmZv20BDx8tQkfo7xqXac7JzcY0fQrNWo8muEmuu3a/9iM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lsCEHD91SOsF0Jy5LzAiaK1y6a7s4L0YLhQimcsu1COn9FfCHyBkJlNtSdkE7dH25e1n36lLFq8c6sMxc3MEoAiKgfoaIg6VCHUbICyuN36jvJoeE7u8mLidBwZV0Vb7+hiD2OeaanZK0gc6b1R05jc/iXQI14OoCImfApin8hM=; X-YMail-OSG: qFlOL.oVM1kOvmlioSwgDVeiV.z12HUdiUxj6BlTRLgEJVS 0ru3tqKiuAoK4aljVI9DUf0oxxzEEMSCwdda9KShk4p_27SRXkwyldI5GNir Ehl_JSEV51051wR.yJuP7S3wp2w8yxbXHM_WujBCn9Lio5sfvSpJqFr2pm_0 8opotVfXjS2iJaGpx3tayR2OpkB_LscyZGlwrlSeZdFEBkq9SScW5PBf52uj Hfoacb_Y2wRIpMesg.MdP9xmx4ZcjRGuRUqqJCGoodssHr_riLw.3U34BP6g _.Kk5fdk6eafSAf1JK.z.wfX25vhz4krleJSu9D.MqWmqAerOl1v6Aw7gVla hclsva035hScXARPdjQSM9B3pczj5rZ79_9MSnPsDCH0pEKW0HJMsTU7rmk4 HGdjhBmly2UCz.eTOuJqEEnPX.o_sWQYKsV6uLjMVTRA- Received: from [209.131.62.115] by web31810.mail.mud.yahoo.com via HTTP; Fri, 12 Aug 2011 13:58:59 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <1313174628.22073.135.camel@ground> <1313176250.95956.YahooMailNeo@web31808.mail.mud.yahoo.com> Message-ID: <1313182739.32560.YahooMailNeo@web31810.mail.mud.yahoo.com> Date: Fri, 12 Aug 2011 13:58:59 -0700 (PDT) From: "William J. Mills" To: Justin Richer , "oauth@ietf.org" In-Reply-To: <1313176250.95956.YahooMailNeo@web31808.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1022750261-1313182739=:32560" Cc: "Anganes, Amanda L" Subject: Re: [OAUTH-WG] MAC Token Comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 20:58:25 -0000 --0-1022750261-1313182739=:32560 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'll take a swag and your comment on #5.=A0 Based on the current abstract o= f the OAuth 2.0 spec=0AThe OAuth 2.0 authorization protocol enables a third= -party application to obtain limited access to an HTTP service, either on b= ehalf of a resource owner by orchestrating an approval interaction between = the resource owner and the HTTP service, or by allowing the third-party app= lication to obtain access on its own behalf.=0A=0AWhich I find somewhat obt= use, how about:=0A=0AThe OAuth 2.0 authorization protocol provides an authe= ntication framework =0Asupporting multiple HTTP authorization schemes. Thi= s allows a user to=0Agrant (limited) HTTP service access to an application = on behalf of =0Athe user or to a third party application to use on it's own= behalf.=0A=0AThe Bearer token spec, for example, could include that text a= nd state it is an authorization scheme usable within the OAuth 2 framework.= =0A=0A=0A-bill=0A=0A=0A=0A________________________________=0AFrom: Justin R= icher =0ATo: "oauth@ietf.org" =0ACc: "An= ganes, Amanda L" =0ASent: Friday, August 12, 2011 11:43= AM=0ASubject: [OAUTH-WG] MAC Token Comments=0A=0A2: MAC Key: "The server M= UST NOT reissue a previously issued MAC key and=0AMAC key identifier combin= ation." =0A=0A3: I would still like to see a binding for post body and url = parameters.=0AThis could be as simple as defining a set of parameter names = for=0Aeverything used in the auth header, but I'm still given the impressio= n=0Athat this has been deemed outside the scope of the MAC token. Our use= =0Acase is to pass around signed URLs between servers with all query=0Apara= meters protected by the signature, which we use 2-legged OAuth 1.0=0Afor to= day. We can try to get language for this together if there's=0Aenough draw= =0A for it, but I haven't been hearing that from other folks yet=0Aso we mi= ght just try to draft an extension to the extension, instead.=0A=0A5: This = section's wording should be brought more in line with the=0Adescriptions of= the OAuth protocol in both core and bearer, which in=0Aturn should actuall= y be a bit closer together themselves. Seems like we=0Aneed a succinct elev= ator pitch for "what is OAuth2" to drop into all of=0Athese locations (and = other extension specs) -- anybody want to take a=0Acrack at distilling one = from these three sources?=0A=0A7.9: Grammar tweak: "Those designing additio= nal methods should evaluate =0A=A0=A0=A0 the compatibility of the normalize= d request string with their =0A=A0=A0=A0 own security requirements."=0A=0A= =0A-- Justin Richer=0A=0A_______________________________________________=0A= OAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo= /oauth --0-1022750261-1313182739=:32560 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'l= l take a swag and your comment on #5.  Based on the current abstract o= f the OAuth 2.0 spec
   Th=
e OAuth 2.0 authorization protocol enables a third-party=0A   application t=
o obtain limited access to an HTTP service, either on=0A   behalf of a reso=
urce owner by orchestrating an approval interaction=0A   between the resour=
ce owner and the HTTP service, or by allowing the=0A   third-party applicat=
ion to obtain access on its own behalf.

Which I find somewhat obtuse=
, how about:

   The OAuth 2.0 authorization protocol provides an aut=
hentication framework 
   supporting multiple HTTP authorization schemes=
.  This allows a user to
   grant (limited) HTTP service access to an ap=
plication on behalf of 
   the user or to a third party application to u=
se on it's own behalf.

The Bearer token spec, for example, could inc=
lude that text and state it is an authorization scheme usable within the OA=
uth 2 framework.


-bill

=
From: Justin Richer <jricher@mitre.org>
To:=0A "oauth@ietf.org" <oauth= @ietf.org>
Cc: "Angan= es, Amanda L" <aanganes@mitre.org>
Sent: Friday, August 12, 2011 11:43 AM
Subject: [OAUTH-WG] MAC Token Comments
2: MAC Key: "The server MUST NOT reissue a previously issued MA= C key and
MAC key identifier combination."

3: I would still like= to see a binding for post body and url parameters.
This could be as sim= ple as defining a set of parameter names for
everything used in the auth= header, but I'm still given the impression
that this has been deemed ou= tside the scope of the MAC token. Our use
case is to pass around signed = URLs between servers with all query
parameters protected by the signatur= e, which we use 2-legged OAuth 1.0
for today. We can try to get language= for this together if there's
enough draw=0A for it, but I haven't been = hearing that from other folks yet
so we might just try to draft an exten= sion to the extension, instead.

5: This section's wording should be = brought more in line with the
descriptions of the OAuth protocol in both= core and bearer, which in
turn should actually be a bit closer together= themselves. Seems like we
need a succinct elevator pitch for "what is O= Auth2" to drop into all of
these locations (and other extension specs) -= - anybody want to take a
crack at distilling one from these three source= s?

7.9: Grammar tweak: "Those designing additional methods should ev= aluate
    the compatibility of the normalized request s= tring with their
    own security requirements."

=
-- Justin Richer

______________________________________________= _
OAuth mailing list
OAuth@ietf.org
https= ://www.ietf.org/mailman/listinfo/oauth




--0-1022750261-1313182739=:32560-- From william_john_mills@yahoo.com Fri Aug 12 12:10:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C5A21F85BB for ; Fri, 12 Aug 2011 12:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0x28hDVcPt0j for ; Fri, 12 Aug 2011 12:10:45 -0700 (PDT) Received: from nm9-vm0.bullet.mail.ne1.yahoo.com (nm9-vm0.bullet.mail.ne1.yahoo.com [98.138.91.67]) by ietfa.amsl.com (Postfix) with SMTP id E301121F851F for ; Fri, 12 Aug 2011 12:10:18 -0700 (PDT) Received: from [98.138.90.54] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 12 Aug 2011 19:10:51 -0000 Received: from [98.138.89.199] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 12 Aug 2011 19:10:51 -0000 Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 12 Aug 2011 19:10:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 199186.8129.bm@omp1057.mail.ne1.yahoo.com Received: (qmail 35058 invoked by uid 60001); 12 Aug 2011 19:10:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313176250; bh=BjxSi/S0SVYlTMs4D1xfZYfn4tGwW8e3/wspnRm2rTM=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0HnplJPVXRkvxbUIM9kqjizYeg1GKWeqwvK/tgCJpn7WndAIQW13LdzPODoRYKFGJq0O0GwG8OL7/GRCaW47mcA6pmNZw1BuKtvLJYZn+nnjKYd2aFtAiO+fSRegnyv7SFVuw8bbHqboTWdDhe1Sqm1GuwHf2o9EH3jqBBlPTBk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qXhb/0Yhn2rXhNuOdVAVX/eCDnngZ0dmEt7EyZ/+/44hePEWjvm8XknNg8hl13nSypZXrfryNlggW87lwI1+Ev3f0IRl1pnpJ7YgW4WKL+2jzU/bc12i7a0/rNzt3KPtssS353KHxBY67VM+ieanPRz2inlsVFuQPQLjT5fyOiM=; X-YMail-OSG: XW1ADzsVM1m8liA0Dc9LKHsJgkKo8CYCH8MSa6WnAgwFXc6 U9oXewEF7LxALnXQytu12b9Q3orQLt3UQvrSMYZJ2Hm97BneXo1PUbH.D9AK xczyO4LFrGVf_OFDV86Vmlc1O0usAn7XTDrtNEjOEvePe9xEtbQy3jaHarZS wuTRgMnQi.fRg4qdKqmJeC6hDxT.a_DFtqVJWh2T.PVxJI548tDWphqtcmqK zYUfKQz9XiV4q98BlOY3sayk0W5xHhdTgl34SoxtmRhKRDwwUT2z8TSI0M6g 22jdp3IFYwAT6FLIHb__G2atULYVWZAL_0BkjQKnQt0opRNq7i09RwxI_EFS ekeSQ.uVM_ZwTsItjsxUmuXKonwOKdDqCgOUzV55dcXoDAOQdJYoINgUmZuo A39P5Tnv5Qroco2gm Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Fri, 12 Aug 2011 12:10:50 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <1313174628.22073.135.camel@ground> Message-ID: <1313176250.95956.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Fri, 12 Aug 2011 12:10:50 -0700 (PDT) From: William Mills To: Justin Richer , "oauth@ietf.org" In-Reply-To: <1313174628.22073.135.camel@ground> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-605985948-1313176250=:95956" X-Mailman-Approved-At: Fri, 12 Aug 2011 14:01:40 -0700 Cc: "Anganes, Amanda L" Subject: Re: [OAUTH-WG] MAC Token Comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 20:53:24 -0000 --0-605985948-1313176250=:95956 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'll take a swag and your comment on #5.=A0 Based on the current abstract o= f the OAuth 2.0 spec=0AThe OAuth 2.0 authorization protocol enables a third= -party application to obtain limited access to an HTTP service, either on b= ehalf of a resource owner by orchestrating an approval interaction between = the resource owner and the HTTP service, or by allowing the third-party app= lication to obtain access on its own behalf.=0A=0AWhich I find somewhat obt= use, how about:=0A=0AThe OAuth 2.0 authorization protocol provides an authe= ntication framework =0Asupporting multiple HTTP authorization schemes. Thi= s allows a user to=0Agrant (limited) HTTP service access to an application = on behalf of =0Athe user or to a third party application to use on it's own= behalf.=0A=0AThe Bearer token spec, for example, could include that text a= nd state it is an authorization scheme usable within the OAuth 2 framework.= =0A=0A=0A-bill=0A=0A=0A=0A________________________________=0AFrom: Justin R= icher =0ATo: "oauth@ietf.org" =0ACc: "An= ganes, Amanda L" =0ASent: Friday, August 12, 2011 11:43= AM=0ASubject: [OAUTH-WG] MAC Token Comments=0A=0A2: MAC Key: "The server M= UST NOT reissue a previously issued MAC key and=0AMAC key identifier combin= ation." =0A=0A3: I would still like to see a binding for post body and url = parameters.=0AThis could be as simple as defining a set of parameter names = for=0Aeverything used in the auth header, but I'm still given the impressio= n=0Athat this has been deemed outside the scope of the MAC token. Our use= =0Acase is to pass around signed URLs between servers with all query=0Apara= meters protected by the signature, which we use 2-legged OAuth 1.0=0Afor to= day. We can try to get language for this together if there's=0Aenough draw = for it, but I haven't been hearing that from other folks yet=0Aso we might = just try to draft an extension to the extension, instead.=0A=0A5: This sect= ion's wording should be brought more in line with the=0Adescriptions of the= OAuth protocol in both core and bearer, which in=0Aturn should actually be= a bit closer together themselves. Seems like we=0Aneed a succinct elevator= pitch for "what is OAuth2" to drop into all of=0Athese locations (and othe= r extension specs) -- anybody want to take a=0Acrack at distilling one from= these three sources?=0A=0A7.9: Grammar tweak: "Those designing additional = methods should evaluate =0A=A0=A0=A0 the compatibility of the normalized re= quest string with their =0A=A0=A0=A0 own security requirements."=0A=0A=0A--= Justin Richer=0A=0A_______________________________________________=0AOAuth= mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oaut= h --0-605985948-1313176250=:95956 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'll take a swag and your comment on #5.  Based on the current abstr= act of the OAuth 2.0 spec
   The OAuth 2.0 authorization p=
rotocol enables a third-party=0A   application to obtain limited access to =
an HTTP service, either on=0A   behalf of a resource owner by orchestrating=
 an approval interaction=0A   between the resource owner and the HTTP servi=
ce, or by allowing the=0A   third-party application to obtain access on its=
 own behalf.

Which I find somewhat obtuse, how about:

   The =
OAuth 2.0 authorization protocol provides an authentication framework 
 =
  supporting multiple HTTP authorization schemes.  This allows a user to   grant (limited) HTTP service access to an application on behalf of 
=
   the user or to a third party application to use on it's own behalf.
<=
br>The Bearer token spec, for example, could include that text and state it=
 is an authorization scheme usable within the OAuth 2 framework.

-bill

From:= Justin Richer <jricher@mitre.org>
To: "oauth@ietf.org" <oauth@ietf.org>
Cc: "Anganes, Amanda L" <aanganes@mitre.org>
= Sent: Friday, August 12, 2011= 11:43 AM
Subject: [OAU= TH-WG] MAC Token Comments

2: MAC Key: "The server MUST NOT re= issue a previously issued MAC key and
MAC key identifier combination." <= br>
3: I would still like to see a binding for post body and url paramet= ers.
This could be as simple as defining a set of parameter names foreverything used in the auth header, but I'm still given the impression
= that this has been deemed outside the scope of the MAC token. Our use
ca= se is to pass around signed URLs between servers with all query
paramete= rs protected by the signature, which we use 2-legged OAuth 1.0
for today= . We can try to get language for this together if there's
enough draw for it, but I haven't been hearing that from other folks yet
so we migh= t just try to draft an extension to the extension, instead.

5: This = section's wording should be brought more in line with the
descriptions o= f the OAuth protocol in both core and bearer, which in
turn should actua= lly be a bit closer together themselves. Seems like we
need a succinct e= levator pitch for "what is OAuth2" to drop into all of
these locations (= and other extension specs) -- anybody want to take a
crack at distilling= one from these three sources?

7.9: Grammar tweak: "Those designing = additional methods should evaluate
    the compatibility= of the normalized request string with their
    own sec= urity requirements."


-- Justin Richer

__________________= _____________________________
OAuth mailing list
OAuth@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/oauth


<= /body> --0-605985948-1313176250=:95956-- From eran@hueniverse.com Fri Aug 12 14:52:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ED821F873D for ; Fri, 12 Aug 2011 14:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIV0b1tVgNft for ; Fri, 12 Aug 2011 14:52:29 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 91B4821F873A for ; Fri, 12 Aug 2011 14:52:29 -0700 (PDT) Received: (qmail 4914 invoked from network); 12 Aug 2011 21:53:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Aug 2011 21:53:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 12 Aug 2011 14:52:51 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , "OAuth WG (oauth@ietf.org)" Date: Fri, 12 Aug 2011 14:52:45 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZOi5rSXfDpMMhRI+ym0EhCpcebA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA6AE9D917DE9eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 21:52:30 -0000 --_000_CA6AE9D917DE9eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is really just a flavor of CSRF attacks. I have no objections to bette= r documenting it (though I feel the current text is already sufficient), bu= t we can't realistically expect to identify and close every possible browse= r-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF att= acks are not likely to implement it correctly with this information. Those = who understand it do not need the extra verbiage which is more confusing th= an helpful. As for the new requirements, they are insufficient to actually accomplish w= hat the authors propose without additional requirements on state local stor= age and verification to complete the flow. Also, the proposed text needs cl= arifications as noted below. From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring "state" should change = from: state OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable= the client application to determine the user-context that was active at th= e time of the request (see section 10.12). The value MUST NOT be guessable= or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. "valu= e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi= dential" mean? Confidential from what? Why specify an "encoded value"? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the resource owner resulting in a comprom= ise of either the resource server or of the client application itself. In t= he OAuth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather than th= e victim's. Depending on the nature of the client and the protected resourc= es, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "state" paramet= er to authorization and access token requests to the authorization server. = The client MUST keep the state value in a location accessible only by the c= lient or the user-agent (i.e., protected by same-origin policy), for exampl= e, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirect, th= e client application MUST confirm that returned value of "state" correspond= s to the state value of the user-agent's user session. If the end-user sess= ion represents an authenticated user-identity, the client MUST ensure that = the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term i= s defined. EHL --_000_CA6AE9D917DE9eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This is really just a fl= avor of CSRF attacks. I have no objections to better documenting it (though= I feel the current text is already sufficient), but we can't realistically= expect to identify and close every possible browser-based attack. A new on= e is invented every other week.

The problem with t= his text is that developers who do no understand CSRF attacks are not likel= y to implement it correctly with this information. Those who understand it = do not need the extra verbiage which is more confusing than helpful.
<= div>
As for the new requirements, they are insufficient to ac= tually accomplish what the authors propose without additional requirements = on state local storage and verification to complete the flow. Also, the pro= posed text needs clarifications as noted below.

From: Anthony Nadalin= <tonynad@microsoft.com>=
Date: Fri, 12 Aug 2011 12:06:3= 6 -0700
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subje= ct: [OAUTH-WG] Auth Code Swap Attack


=

 

In section 4,= request options (e.g. 4.1.1) featuring "state" should change from:<= /span>

 

state

OPTIONAL. An op= aque value used by the client to maintain state between the request and cal= lback. The authorization server includes this value when redirecting the us= er-agent back to the client.

 

to:

 

state

REQUIRED. An opaque value used by the client t= o maintain state between the request and callback. The authorization server= includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determin= e the user-context that was active at the time of the  request (see se= ction 10.12). The value MUST NOT be guessable or predictable, and MUST be k= ept confidential.

 

=

Making the parameter re= quired without making its usage required (I.e. "value SHOULD enable") accom= plishes nothing. Also, what does "MUST be kept confidential" mean? Confiden= tial from what? Why specify an "encoded value"?

= Section 10.12 Cross-Site Request Forgery<= /span>

 

Change to:

 

Cross-site reque= st forgery (CSRF) is a web-based attack whereby HTTP requests are transmitt= ed from the user-agent of an end-user the server trusts or has authent= icated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the&= nbsp;resource owner resulting in a compromise of either the resource server= or of the client application itself. In the OAuth context, such attac= ks allow an attacker to inject their own authorization code or access token into a client, which can result in the client using a= n access token associated with the attacker's account rather than the = victim's. Depending on the nature of the client and the protected reso= urces, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "state" pa= rameter to authorization and access token requests to the authorization ser= ver. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., = protected by same-origin policy), for example, using a DOM variable, H= TTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirec= t, the client application MUST confirm that returned value of "state" corre= sponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-ide= ntity, the client MUST ensure that the user-identity has NOT changed.<= o:p>

 


The above text uses 'user-c= ontext' and this 'user-identity'. Neither term is defined.

EHL
--_000_CA6AE9D917DE9eranhueniversecom_-- From eran@hueniverse.com Fri Aug 12 20:25:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B75A11E8090 for ; Fri, 12 Aug 2011 20:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAfcuuLSQb6B for ; Fri, 12 Aug 2011 20:25:58 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id B1C1511E8086 for ; Fri, 12 Aug 2011 20:25:58 -0700 (PDT) Received: (qmail 12280 invoked from network); 13 Aug 2011 03:26:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Aug 2011 03:26:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 12 Aug 2011 20:26:30 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Fri, 12 Aug 2011 20:26:24 -0700 Thread-Topic: Plans for draft -21 (last working group draft) Thread-Index: AcxZaMp4+sc9sx73Swi/42I1cS1I4Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA6B3CF017E42eranhueniversecom_" MIME-Version: 1.0 Subject: [OAUTH-WG] Plans for draft -21 (last working group draft) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 03:25:59 -0000 --_000_CA6B3CF017E42eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks to everyone who submitted WGLC comments on draft =9620. The majority of comments look good and will be applied to the specification= as they are purely editorial. A few are normative but some with significan= t changes - I will open issues for those. I plan to publish =9621 next week. EHL --_000_CA6B3CF017E42eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks to everyone who submitte= d WGLC comments on draft =9620.

The majority of co= mments look good and will be applied to the specification as they are purel= y editorial. A few are normative but some with significant changes -  = I will open issues for those.

I plan to publish = =9621 next week.

EHL
--_000_CA6B3CF017E42eranhueniversecom_-- From tonynad@microsoft.com Fri Aug 12 20:28:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9AE21F856A for ; Fri, 12 Aug 2011 20:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCdx5KFc-zw1 for ; Fri, 12 Aug 2011 20:28:46 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7E921F84F9 for ; Fri, 12 Aug 2011 20:28:46 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 12 Aug 2011 20:29:25 -0700 Received: from DB3EHSOBE001.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Aug 2011 20:29:24 -0700 Received: from mail16-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.22; Sat, 13 Aug 2011 03:29:23 +0000 Received: from mail16-db3 (localhost.localdomain [127.0.0.1]) by mail16-db3-R.bigfish.com (Postfix) with ESMTP id 0B9C8ED8138 for ; Sat, 13 Aug 2011 03:29:23 +0000 (UTC) X-SpamScore: 3 X-BigFish: PS3(zzc85fhzz1202h1082kzz8275bh8275dhz31h2a8h668h839h) X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT011.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail16-db3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT011.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail16-db3 (localhost.localdomain [127.0.0.1]) by mail16-db3 (MessageSwitch) id 1313206162823919_24767; Sat, 13 Aug 2011 03:29:22 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.254]) by mail16-db3.bigfish.com (Postfix) with ESMTP id C3A6EC88050 for ; Sat, 13 Aug 2011 03:29:22 +0000 (UTC) Received: from SN2PRD0302HT011.namprd03.prod.outlook.com (207.46.4.139) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.22; Sat, 13 Aug 2011 03:29:17 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.222]) by SN2PRD0302HT011.namprd03.prod.outlook.com ([10.27.90.157]) with mapi id 14.01.0225.064; Sat, 13 Aug 2011 03:29:16 +0000 From: Anthony Nadalin To: "OAuth WG (oauth@ietf.org)" Thread-Topic: x-www-form-urlencoded Thread-Index: AcxYUPGtIbsp9lRrSSie2MIJkueB6Q== Date: Sat, 13 Aug 2011 03:29:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.11.83.174] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E723BABC82SN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT011.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com Subject: [OAUTH-WG] x-www-form-urlencoded X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 03:28:47 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E723BABC82SN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the text on the authorization and token endpoints an assumption is made = that the query component of the URLs will be specified based on x-www-form-= urlencoded. But in fact that is never explicitly stated. What is explicitly= stated is that RFC 3986 section 3 has to be used (and then only for the au= thorization endpoint, not the token endpoint). But section 3 just defines w= hat characters can be used in a query component, it says nothing about x-ww= w-form-urlencoded. Suggest that the specification needs to normatively sta= te that we are requiring all authorization endpoints that use the query com= ponent to do so using x-www-form-urlencoded. Where RFC 5552 comes into the= picture is in cases where the request body is an html form. In that case i= t makes sense to natively encode the form content using UTF-8. So this only= applies to OAuth requests that use the request body. So this would apply t= o sections 2.4.1, 3.1, 3.2, 4.1.3, 4.3.2 & 4.4.2. Really, anywhere that a r= equest can be made in the request body --_000_B26C1EF377CB694EAB6BDDC8E624B6E723BABC82SN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the text on the authorization and token endpoints= an assumption is made that the query component of the URLs will be specifi= ed based on x-www-form-urlencoded. But in fact that is never explicitly sta= ted. What is explicitly stated is that RFC 3986 section 3 has to be used (and then only for the authorizatio= n endpoint, not the token endpoint). But section 3 just defines what charac= ters can be used in a query component, it says nothing about x-www-form-url= encoded. Suggest that the specification needs  to normatively state that we are requiring all authorization e= ndpoints that use the query component to do so using x-www-form-urlencoded.=   Where RFC 5552 comes into the picture is in cases where the request = body is an html form. In that case it makes sense to natively encode the form content using UTF-8. So this only applie= s to OAuth requests that use the request body. So this would apply to secti= ons 2.4.1, 3.1, 3.2, 4.1.3, 4.3.2 & 4.4.2. Really, anywhere that a requ= est can be made in the request body

--_000_B26C1EF377CB694EAB6BDDC8E624B6E723BABC82SN2PRD0302MB137_-- From torsten@lodderstedt.net Fri Aug 12 23:57:25 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C5121F86EE for ; Fri, 12 Aug 2011 23:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxYcfgB44X61 for ; Fri, 12 Aug 2011 23:57:24 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by ietfa.amsl.com (Postfix) with ESMTP id 04A8721F86D6 for ; Fri, 12 Aug 2011 23:57:23 -0700 (PDT) Received: from [79.253.44.36] (helo=[192.168.71.35]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qs8AQ-0005VY-PR; Sat, 13 Aug 2011 08:57:58 +0200 Message-ID: <4E46207A.6080404@lodderstedt.net> Date: Sat, 13 Aug 2011 08:58:02 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000602000308000001090308" X-Df-Sender: torsten@lodderstedt-online.de Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 06:57:25 -0000 This is a multi-part message in MIME format. --------------000602000308000001090308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: > This is really just a flavor of CSRF attacks. I have no objections to > better documenting it (though I feel the current text is already > sufficient), but we can't realistically expect to identify and close > every possible browser-based attack. A new one is invented every other > week. > > The problem with this text is that developers who do no understand > CSRF attacks are not likely to implement it correctly with this > information. Those who understand it do not need the extra verbiage > which is more confusing than helpful. We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well. regards, Torsten. > > As for the new requirements, they are insufficient to actually > accomplish what the authors propose without additional requirements on > state local storage and verification to complete the flow. Also, the > proposed text needs clarifications as noted below. > > > From: Anthony Nadalin > > Date: Fri, 12 Aug 2011 12:06:36 -0700 > To: "OAuth WG (oauth@ietf.org )" > > > Subject: [OAUTH-WG] Auth Code Swap Attack > > > > *Recommended Changes to draft-ietf-oauth-v2* > > In section 4, request options (e.g. 4.1.1) featuring "state" > should change from: > > state > > OPTIONAL. An opaque value used by the client to maintain state > between the request and callback. The authorization server > includes this value when redirecting the user-agent back to the > client. > > to: > > state > > REQUIRED. An opaque value used by the client to maintain state > between the request and callback. The authorization server > includes this value when redirecting the user-agent back to the > client. The encoded value SHOULD enable the client application to > determine the user-context that was active at the time of the > request (see section 10.12). The value MUST NOT be guessable or > predictable, and MUST be kept confidential. > > > Making the parameter required without making its usage required (I.e. > "value SHOULD enable") accomplishes nothing. Also, what does "MUST be > kept confidential" mean? Confidential from what? Why specify an > "encoded value"? > > > Section 10.12 Cross-Site Request Forgery > > Change to: > > Cross-site request forgery (CSRF) is a web-based attack whereby > HTTP requests are transmitted from the user-agent of an > end-user the server trusts or has authenticated. CSRF attacks > enable the attacker to intermix the attacker's security context > with that of the resource owner resulting in a compromise of > either the resource server or of the client application itself. In > the OAuth context, such attacks allow an attacker to inject their > own authorization code or access token into a client, which can > result in the client using an access token associated with the > attacker's account rather than the victim's. Depending on the > nature of the client and the protected resources, this can have > undesirable and damaging effects. > > In order to prevent such attacks, the client application MUST > encode a non-guessable, confidential end-user artifact and submit > as the "state" parameter to authorization and access token > requests to the authorization server. The client MUST keep the > state value in a location accessible only by the client or the > user-agent (i.e., protected by same-origin policy), for example, > using a DOM variable, HTTP cookie, or HTML5 client-side storage. > > The authorization server includes the value of the "state" > parameter when redirecting the user-agent back to the client. > Upon receiving a redirect, the client application MUST confirm > that returned value of "state" corresponds to the state value of > the user-agent's user session. If the end-user session represents > an authenticated user-identity, the client MUST ensure that the > user-identity has NOT changed. > > > The above text uses 'user-context' and this 'user-identity'. Neither > term is defined. > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000602000308000001090308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav:
This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week.

The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful.

We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well.

regards,
Torsten.


As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below.


From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack


Recommended Changes to draft-ietf-oauth-v2

 

In section 4, request options (e.g. 4.1.1) featuring "state" should change from:

 

state

OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.

 

to:

 

state

REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the  request (see section 10.12). The value MUST NOT be guessable or predictable, and MUST be kept confidential.

 

Making the parameter required without making its usage required (I.e. "value SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confidential" mean? Confidential from what? Why specify an "encoded value"?


Section 10.12 Cross-Site Request Forgery

 

Change to:

 

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to inject their own authorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the "state" parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parameter when redirecting the user-agent back to the client. Upon receiving a redirect, the client application MUST confirm that returned value of "state" corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has NOT changed.

 

The above text uses 'user-context' and this 'user-identity'. Neither term is defined.

EHL


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------000602000308000001090308-- From phil.hunt@oracle.com Sat Aug 13 00:21:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E278011E807E for ; Sat, 13 Aug 2011 00:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.275 X-Spam-Level: X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7Evciqs9wKs for ; Sat, 13 Aug 2011 00:21:23 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE5A11E807C for ; Sat, 13 Aug 2011 00:21:23 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7D7LxNF005654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Aug 2011 07:22:00 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7D7LwU9010128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2011 07:21:58 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7D7LrEr002419; Sat, 13 Aug 2011 02:21:53 -0500 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 13 Aug 2011 00:21:52 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-77--94538152 From: Phil Hunt In-Reply-To: <4E46207A.6080404@lodderstedt.net> Date: Sat, 13 Aug 2011 00:21:50 -0700 Message-Id: <6192E34E-57B1-4A84-B157-228258C4207B@oracle.com> References: <4E46207A.6080404@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1084) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E462619.0034:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 07:21:25 -0000 --Apple-Mail-77--94538152 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 (to putting more detail in the Threat Model document) Yes, this is another CSRF attack (hence the change to 10.2).=20 What is *new* is this is an attack on the client application rather than = the resource server. As such, I agree this new attack vector is well = deserving of wider review and discussion before finalizing the draft. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: >=20 >=20 > Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: >>=20 >> This is really just a flavor of CSRF attacks. I have no objections to = better documenting it (though I feel the current text is already = sufficient), but we can't realistically expect to identify and close = every possible browser-based attack. A new one is invented every other = week. >>=20 >> The problem with this text is that developers who do no understand = CSRF attacks are not likely to implement it correctly with this = information. Those who understand it do not need the extra verbiage = which is more confusing than helpful. >=20 > We are constantly facing the fact that a comprehensive description of = security threats needs more space than we have in the core draft. That's = the reason why the security document has 63 pages and that's also the = reason why we decided to let the core spec refer to this document for = in-depth explanations. This holds true for this threat as well. >=20 > regards, > Torsten.=20 >=20 >>=20 >> As for the new requirements, they are insufficient to actually = accomplish what the authors propose without additional requirements on = state local storage and verification to complete the flow. Also, the = proposed text needs clarifications as noted below. >>=20 >>=20 >> From: Anthony Nadalin >> Date: Fri, 12 Aug 2011 12:06:36 -0700 >> To: "OAuth WG (oauth@ietf.org)" >> Subject: [OAUTH-WG] Auth Code Swap Attack >>=20 >>=20 >>=20 >> Recommended Changes to draft-ietf-oauth-v2 >> =20 >> In section 4, request options (e.g. 4.1.1) featuring "state" should = change from: >> =20 >> state >> OPTIONAL. An opaque value used by the client to maintain state = between the request and callback. The authorization server includes this = value when redirecting the user-agent back to the client. >> =20 >> to: >> =20 >> state >> REQUIRED. An opaque value used by the client to maintain state = between the request and callback. The authorization server includes this = value when redirecting the user-agent back to the client. The encoded = value SHOULD enable the client application to determine the user-context = that was active at the time of the request (see section 10.12). The = value MUST NOT be guessable or predictable, and MUST be kept = confidential. >> =20 >>=20 >> Making the parameter required without making its usage required (I.e. = "value SHOULD enable") accomplishes nothing. Also, what does "MUST be = kept confidential" mean? Confidential from what? Why specify an "encoded = value"? >>=20 >>=20 >> Section 10.12 Cross-Site Request Forgery >> =20 >> Change to: >> =20 >> Cross-site request forgery (CSRF) is a web-based attack whereby HTTP = requests are transmitted from the user-agent of an end-user the server = trusts or has authenticated. CSRF attacks enable the attacker to = intermix the attacker's security context with that of the resource owner = resulting in a compromise of either the resource server or of the client = application itself. In the OAuth context, such attacks allow an attacker = to inject their own authorization code or access token into a client, = which can result in the client using an access token associated with the = attacker's account rather than the victim's. Depending on the nature of = the client and the protected resources, this can have undesirable and = damaging effects. >>=20 >> In order to prevent such attacks, the client application MUST encode = a non-guessable, confidential end-user artifact and submit as the = "state" parameter to authorization and access token requests to the = authorization server. The client MUST keep the state value in a location = accessible only by the client or the user-agent (i.e., protected by = same-origin policy), for example, using a DOM variable, HTTP cookie, or = HTML5 client-side storage. >>=20 >> The authorization server includes the value of the "state" parameter = when redirecting the user-agent back to the client. Upon receiving a = redirect, the client application MUST confirm that returned value of = "state" corresponds to the state value of the user-agent's user session. = If the end-user session represents an authenticated user-identity, the = client MUST ensure that the user-identity has NOT changed. >> =20 >>=20 >> The above text uses 'user-context' and this 'user-identity'. Neither = term is defined. >>=20 >> EHL >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-77--94538152 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 = (to putting more detail in the Threat Model = document)

Yes, this is another CSRF attack (hence the = change to 10.2). 

What is *new* is this is = an attack on the client application rather than the resource = server. As such, I agree this new attack vector is well deserving of = wider review and discussion before finalizing the = draft.

Phil

On 2011-08-12, at 11:58 PM, Torsten Lodderstedt = wrote:

=20 =20


Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav:
This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week.

The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful.

We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well.

regards,
Torsten.


As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below.


From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 Aug = 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack


Recommended Changes to draft-ietf-oauth-v2

 

=

In section 4, request options (e.g. 4.1.1) featuring "state" should change = from:

 

=

state

<= p class=3D"MsoNormal">OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the = client.

 

=

to:

 

=

state

<= p class=3D"MsoNormal">REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the  request (see section 10.12). The value MUST = NOT be guessable or predictable, and MUST be kept confidential.

 

=

Making the parameter required without making its usage required (I.e. "value SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confidential" mean? Confidential from what? Why specify an "encoded value"?


Section 10.12 Cross-Site Request Forgery

 

=

Change to:

 

=

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has = authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to inject their = own authorization code or access token into a client, which can result in the client using an access = token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit = as the "state" parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location = accessible only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 = client-side storage.

The authorization server includes the value of the "state" parameter when redirecting the user-agent back to the client. Upon receiving a redirect, = the client application MUST confirm that returned value of "state" corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has = NOT changed.

 

The above text uses 'user-context' and this 'user-identity'. Neither term is defined.

EHL


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail-77--94538152-- From eran@hueniverse.com Sat Aug 13 07:29:49 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0640F21F85CE for ; Sat, 13 Aug 2011 07:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb+NuJUpRTIa for ; Sat, 13 Aug 2011 07:29:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 767A721F85B1 for ; Sat, 13 Aug 2011 07:29:47 -0700 (PDT) Received: (qmail 25756 invoked from network); 13 Aug 2011 14:30:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Aug 2011 14:30:26 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 13 Aug 2011 07:30:26 -0700 From: Eran Hammer-Lahav To: Phil Hunt , Torsten Lodderstedt Date: Sat, 13 Aug 2011 07:30:19 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZxYsXZRWMgotBSSWz96dgvcxCkg== Message-ID: In-Reply-To: <6192E34E-57B1-4A84-B157-228258C4207B@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA6BD81817E81eranhueniversecom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 14:29:49 -0000 --_000_CA6BD81817E81eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All OAuth CSRF attacks are on the client. EHL From: Phil Hunt > Date: Sat, 13 Aug 2011 00:21:50 -0700 To: Torsten Lodderstedt > Cc: Eran Hammer-lahav >, "O= Auth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Auth Code Swap Attack +1 (to putting more detail in the Threat Model document) Yes, this is another CSRF attack (hence the change to 10.2). What is *new* is this is an attack on the client application rather than th= e resource server. As such, I agree this new attack vector is well deservin= g of wider review and discussion before finalizing the draft. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: This is really just a flavor of CSRF attacks. I have no objections to bette= r documenting it (though I feel the current text is already sufficient), bu= t we can't realistically expect to identify and close every possible browse= r-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF att= acks are not likely to implement it correctly with this information. Those = who understand it do not need the extra verbiage which is more confusing th= an helpful. We are constantly facing the fact that a comprehensive description of secur= ity threats needs more space than we have in the core draft. That's the rea= son why the security document has 63 pages and that's also the reason why w= e decided to let the core spec refer to this document for in-depth explanat= ions. This holds true for this threat as well. regards, Torsten. As for the new requirements, they are insufficient to actually accomplish w= hat the authors propose without additional requirements on state local stor= age and verification to complete the flow. Also, the proposed text needs cl= arifications as noted below. From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring "state" should change = from: state OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable= the client application to determine the user-context that was active at th= e time of the request (see section 10.12). The value MUST NOT be guessable= or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. "valu= e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi= dential" mean? Confidential from what? Why specify an "encoded value"? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the resource owner resulting in a comprom= ise of either the resource server or of the client application itself. In t= he OAuth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather than th= e victim's. Depending on the nature of the client and the protected resourc= es, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "state" paramet= er to authorization and access token requests to the authorization server. = The client MUST keep the state value in a location accessible only by the c= lient or the user-agent (i.e., protected by same-origin policy), for exampl= e, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirect, th= e client application MUST confirm that returned value of "state" correspond= s to the state value of the user-agent's user session. If the end-user sess= ion represents an authenticated user-identity, the client MUST ensure that = the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term i= s defined. EHL _______________________________________________ OAuth mailing list OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/= oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA6BD81817E81eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All OAuth CSRF attacks a= re on the client.

EHL

From: Phil Hunt <phil.hunt@oracle.com>
Date: Sat, 13 Aug 2011 00:21:50 -0700
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Eran Hammer-lahav <eran@hueniverse.com>, "OAuth WG (oauth@ietf.org)" <= oauth@ietf.org>
Subject: = Re: [OAUTH-WG] Auth Code Swap Attack

+1= (to putting more detail in the Threat Model document)

Y= es, this is another CSRF attack (hence the change to 10.2). 

What is *new* is this is an attack on the client app= lication rather than the resource server. As such, I agree this new attack = vector is well deserving of wider review and discussion before finalizing t= he draft.

Phil



On 2011-08-12, at 11:58 PM, To= rsten Lodderstedt wrote:

=20 =20 =20


Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav:
This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week.

The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful.

We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well.

regards,
Torsten.


As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below.


From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" <oa= uth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack


Recommended Changes to draft-ietf-oauth-v2

&nb= sp;

In se= ction 4, request options (e.g. 4.1.1) featuring "state" should change from:=

 

state

OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.

 

= to:<= /o:p>

 

state

REQU= IRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the  request (see section 10.12). The value MUST NOT b= e guessable or predictable, and MUST be kept confidential.

 

Making the parameter required without making its usage required (I.e. "value SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confidential" mean? Confidential from what? Why specify an "encoded value"?


Section 10.12 Cross-Site Request Forgery

 

Change to:

&n= bsp;

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated= . CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to inject their own= authorization code or access token into a client, which can result in the client using an access tok= en associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the "state" parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible= only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parameter when redirecting the user-agent back to the client. Upon receiving a redirect, the= client application MUST confirm that returned value of "state" corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has NOT changed.

 

The above text uses 'user-context' and this 'user-identity'. Neither term is defined.

EHL


_______________________________________________
OAuth mailing list
OAuth@=
ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oa= uth

--_000_CA6BD81817E81eranhueniversecom_-- From eran@hueniverse.com Sat Aug 13 08:14:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEC421F86AE for ; Sat, 13 Aug 2011 08:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZSU4u41o8Hn for ; Sat, 13 Aug 2011 08:14:14 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id EE9F821F8563 for ; Sat, 13 Aug 2011 08:14:13 -0700 (PDT) Received: (qmail 5715 invoked from network); 13 Aug 2011 15:14:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Aug 2011 15:14:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 13 Aug 2011 08:14:26 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Sat, 13 Aug 2011 08:14:22 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZy7BgMPPKPL7KSQOAnbJwNCUASQ== Message-ID: In-Reply-To: <4E46207A.6080404@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 15:14:15 -0000 Again, the idea that you can produce a comprehensive description of security threat is impractical if you are going to include every browser-based attack and its remedies. OAuth use of browser redirection imports almost every possible attack vector on the web. That's my point. People constantly bring up these attack vectors, and in multiple flavors and variations, as if *anyone* can produce a complete list of these issues. Now, this doesn't mean we should not try to be comprehensive but this can go on forever. The changes to 10.12 seem reasonable with the exception of the new MUSTs. I disagree that we should mandate clients to use the state parameter as the only CSRF protection vector, especially in an evolving web environment. We can still include a MUST for verifying that the user redirected to the authorization server is the same user coming back, and highlight the state parameter as one way to accomplish that. How about: state: OPTIONAL. An opaque value used by the client to maintain state between the request and redirection. The authorization server includes this value when redirecting the user-agent back to the client. Use of the "state" parameter is RECOMMENDED for preventing cross-site request forgery as described in Section 10.12. =20 Section 10.12 Cross-Site Request Forgery =20 Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to inject their own authorization code or access token into the client, which can result in the client associating the attacker's protected resources to the victim's account on the client. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. In order to prevent such attacks, the client MUST employ CSRF protection. It is strongly RECOMMENDED for the client to utilize the "state" request parameter with authorization requests to the authorization server. When used for CSRF prevention, the "state" request parameter MUST contain a non-guessable value, which the client MUST also store with the resource owner's user-agent in a location accessible only to the client or the resource owner's user-agent (i.e., protected by same-origin policy). For example, the client can using a DOM variable, HTTP cookie, or HTML5 client-side storage. When redirecting the resource owner's user-agent back to the client, the authorization server includes the value of the "state" parameter. Upon receiving the redirection request, the client MUST confirm that returned value of the "state" parameter matches the value stored with the resource owner's user-agent. EHL From: Torsten Lodderstedt Date: Fri, 12 Aug 2011 23:58:02 -0700 To: Eran Hammer-lahav Cc: Anthony Nadalin , "OAuth WG (oauth@ietf.org)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > =20 > =20 > =20 > =20 > =20 > =20 > Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: > =20 > This is really just a flavor of CSRF attacks. I have no > objections to better documenting it (though I feel the current > text is already sufficient), but we can't realistically expect > to identify and close every possible browser-based attack. A new > one is invented every other week. > =20 > =20 > The problem with this text is that developers who do no > understand CSRF attacks are not likely to implement it correctly > with this information. Those who understand it do not need the > extra verbiage which is more confusing than helpful. > =20 > > =20 > We are constantly facing the fact that a comprehensive description > of security threats needs more space than we have in the core draft. > That's the reason why the security document has 63 pages and that's > also the reason why we decided to let the core spec refer to this > document for in-depth explanations. This holds true for this threat > as well. > =20 > regards, > Torsten.=20 > =20 > =20 > =20 > =20 > As for the new requirements, they are insufficient to > actually accomplish what the authors propose without additional > requirements on state local storage and verification to complete > the flow. Also, the proposed text needs clarifications as noted > below. > =20 > =20 > =20 > =20 > =20 > From: Anthony Nadalin > Date: Fri, 12 Aug 2011 > 12:06:36 -0700 > To: "OAuth WG (oauth@ietf.org)" > > Subject: [OAUTH-WG] > Auth Code Swap Attack > =20 > =20 > =20 > > >> =20 >> =20 >> =20 > =20 > =20 > =20 > =20 > =20 > =20 > > >> =20 >> =20 >> =20 >> Recommended >> Changes to draft-ietf-oauth-v2 >> =20 >> In section 4, request options (e.g. >> 4.1.1) featuring "state" should change from: >> =20 >> state >> OPTIONAL. >> An opaque value used by the client to maintain state >> between the request and callback. The authorization >> server includes this value when redirecting the >> user-agent back to the client. >> =20 >> to: >> =20 >> state >> REQUIRED. >> An opaque value used by the client to maintain state >> between the request and callback. The authorization >> server includes this value when redirecting the >> user-agent back to the client. The encoded value >> SHOULD enable the client application to determine >> the user-context that was active at the time of the >> request (see section 10.12). The value MUST NOT be >> guessable or predictable, and MUST be kept >> confidential. >> =20 >> =20 >> =20 >> =20 >> =20 > =20 > =20 > =20 > Making the parameter required without making its usage > required (I.e. "value SHOULD enable") accomplishes nothing. > Also, what does "MUST be kept confidential" mean? Confidential > from what? Why specify an "encoded value"? > =20 > =20 > =20 > =20 > =20 > > >> =20 >> =20 >> =20 >> Section 10.12 Cross-Site Request >> Forgery >> =20 >> Change to: >> =20 >> Cross-site >> request forgery (CSRF) is a web-based attack whereby >> HTTP requests are transmitted from the user-agent of >> an end-user the server trusts or has authenticated. >> CSRF attacks enable the attacker to intermix the >> attacker's security context with that of >> the resource owner resulting in a compromise of >> either the resource server or of the client >> application itself. In the OAuth context, >> such attacks allow an attacker to inject their own >> authorization code or access token into a client, >> which can result in the client using an access token >> associated with the attacker's account rather than >> the victim's. Depending on the nature of the client >> and the protected resources, this can have >> undesirable and damaging effects. >> =20 >> In order to prevent such attacks, the client >> application MUST encode a non-guessable, >> confidential end-user artifact and submit as the >> "state" parameter to authorization and access token >> requests to the authorization server. The client >> MUST keep the state value in a location accessible >> only by the client or the user-agent (i.e., >> protected by same-origin policy), for example, using >> a DOM variable, HTTP cookie, or HTML5 client-side >> storage. >> =20 >> The authorization server includes the value of the >> "state" parameter when redirecting the user-agent >> back to the client. Upon receiving a redirect, the >> client application MUST confirm that returned value >> of "state" corresponds to the state value of the >> user-agent's user session. If the end-user session >> represents an authenticated user-identity, the >> client MUST ensure that the user-identity has NOT >> changed. >> =20 >> =20 >> =20 >> =20 >> =20 > =20 > =20 > =20 > The above text uses 'user-context' and this 'user-identity'. > Neither term is defined. > =20 > =20 > EHL > =20 > =20 > =20 > _______________________________________________ >OAuth mailing list >OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > =20 > > =20 From wmills@yahoo-inc.com Sat Aug 13 09:21:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700F621F876A for ; Sat, 13 Aug 2011 09:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.211 X-Spam-Level: X-Spam-Status: No, score=-17.211 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9chVngnDRfU5 for ; Sat, 13 Aug 2011 09:21:32 -0700 (PDT) Received: from nm33-vm6.bullet.mail.bf1.yahoo.com (nm33-vm6.bullet.mail.bf1.yahoo.com [72.30.239.206]) by ietfa.amsl.com (Postfix) with SMTP id D4E1B21F8752 for ; Sat, 13 Aug 2011 09:21:31 -0700 (PDT) Received: from [98.139.212.147] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2011 16:22:08 -0000 Received: from [98.139.212.219] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2011 16:22:08 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 13 Aug 2011 16:22:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 333905.87237.bm@omp1028.mail.bf1.yahoo.com Received: (qmail 5492 invoked by uid 60001); 13 Aug 2011 16:22:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313252527; bh=wDOBwYYXcfQC9gRr4XiGR9p621SJv8gH3+AsLHSJZAk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=i0jJgFKEgDl8j3tF0/Y9APal8uTcmGQvZC4O9tdQ4H2ZCR3qEbB16SipsTGImSNmkTPlA6QbxeS181sF5xC3Psw3spZnADs9b6b6MiMKa9uOky/+hKpsNJnkQoHBttZiWNBdYIZ5fqVKlp1N+rymUqU+At5FaUfBJyROt8QpeRQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UKJaQkDHtqzKDNxIn2aJOX1hSl0ZdfyHDqV6hdDYYsX3ToK+fIlQQvf5QQtajtbhpmv9nf6dxOOav5LxEgT8UHs/XB1aVZWi0cSEz4pXfX5T1Hl+UMR0S/a6CxQwxJZFsByCoBXD4nCyF4ONYFW/SEZn6dHYgyhmLKDUTKpvbqg=; X-YMail-OSG: PGHF4PIVM1nhF8uwlE4_oGpIifoYlCasHv51KAOqKvxqlqu xQlWnHehE0anbOHrVW6ZOmXkE4jVImI1Aa3Pe9T_woaI.3vUkfierq8f7yUt k5g5Q6BBqUcaShxDhPlnsk25fmkNB08dYtcIfGA7lLOTU.wdZdCMY59VMlFm UdHGI_57Jkrsm4USnmSvfPtMyldtIiGvdBfbjTrgtKyv25w0POGgLhiAqj9. fJ7y17m9tuowF.xMgs_L7ET0WLEljD0x4wTGq3V6x4i9Q0Mi7R36HZJfPlIq ajkuiokaXZmyczS6l7K2vwi3lak0BA1POohnr1yJ9Grvg6TiXhN8gqh6dupb uzuF8KsaA52tUlx6dBMLmEQ8tnfuuX0tU4NWHL6Ki4.N6PyT5YY6a2EpUEa2 0s4lb6fg975NBCgl71IYC3K7JMneHDLY_91To5BdsEYlWnjyNJ1wAPuNl4SE JWJ0pUyPUaeVGNkYxu194_Z7GOp0wOSxffxUAoQJNI4bUC1kHHD92ixbnl1s 95fWEs1PBM9WIe57YwBz5miZOMMEaSq.gPumVmtuNT7cRcxXBMi1.aB4y_TC VKI61SuCDLHZQtP70CvO_AUgpJIPfjglVMrXPQsz9wIGQmFPQ0yZe Received: from [209.131.62.115] by web31807.mail.mud.yahoo.com via HTTP; Sat, 13 Aug 2011 09:22:07 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <6192E34E-57B1-4A84-B157-228258C4207B@oracle.com> Message-ID: <1313252527.98143.YahooMailNeo@web31807.mail.mud.yahoo.com> Date: Sat, 13 Aug 2011 09:22:07 -0700 (PDT) From: "William J. Mills" To: Eran Hammer-Lahav , Phil Hunt , Torsten Lodderstedt In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1541028779-1313252527=:98143" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 16:21:33 -0000 --0-1541028779-1313252527=:98143 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All CSRF attacks are a against the client (confused deputy) yes.=A0 The def= ense is always in the server side.=A0 I agree that it's really worth coveri= ng.=A0 There are already good discussions of CSRF out there which I think w= e shoudl lean on rather than re-writing our own, i.e. http://www.rfc-editor= .org/rfc/rfc6265.txt=0A=0A-bill=0A=0A=0A=0A________________________________= =0AFrom: Eran Hammer-Lahav =0ATo: Phil Hunt ; Torsten Lodderstedt =0ACc: "OAuth WG= (oauth@ietf.org)" =0ASent: Saturday, August 13, 2011 7:30 = AM=0ASubject: Re: [OAUTH-WG] Auth Code Swap Attack=0A=0A=0AAll OAuth CSRF a= ttacks are on the client.=0A=0AEHL=0AFrom: Phil Hunt =0ADate: Sat, 13 Aug 2011 00:21:50 -0700=0ATo: Torsten Lodderstedt =0ACc: Eran Hammer-lahav , "OAuth= WG (oauth@ietf.org)" =0ASubject: Re: [OAUTH-WG] Auth Code= Swap Attack=0A=0A=0A+1 (to putting more detail in the Threat Model documen= t)=0A>=0A>=0A>Yes, this is another CSRF attack (hence the change to 10.2).= =A0=0A>=0A>=0A>What is *new* is this is an attack on the client application= rather than the resource server. As such, I agree this new attack vector i= s well deserving of wider review and discussion before finalizing the draft= .=0A>=0A>=0A>Phil=0A>=0A>=0A>@independentid=0A>www.independentid.comphil.hu= nt@oracle.com=0A>=0A>=0A>=0A>=0A>=0A>=0A>On 2011-08-12, at 11:58 PM, Torste= n Lodderstedt wrote:=0A>=0A>=0A>>=0A>>Am 12.08.2011 23:52, schrieb Eran Ham= mer-Lahav: =0A>>This is really just a flavor of CSRF attacks. I have no obj= ections to better documenting it (though I feel the current text is already= sufficient), but we can't realistically expect to identify and close every= possible browser-based attack. A new one is invented every other week.=0A>= >>=0A>>>=0A>>>The problem with this text is that developers who do no under= stand CSRF attacks are not likely to implement it correctly with this infor= mation. Those who understand it do not need the extra verbiage which is mor= e confusing than helpful.=0A>>We are constantly facing the fact that a comp= rehensive description=0A of security threats needs more space than we ha= ve in the core draft.=0A That's the reason why the security document has= 63 pages and that's=0A also the reason why we decided to let the core s= pec refer to this=0A document for in-depth explanations. This holds true= for this threat=0A as well.=0A>>=0A>>regards,=0A>>Torsten. =0A>>=0A>>= =0A>>=0A>>>=0A>>>As for the new requirements, they are insufficient to actu= ally accomplish what the authors propose without additional requirements on= state local storage and verification to complete the flow. Also, the propo= sed text needs clarifications as noted below.=0A>>>=0A>>>=0A>>>=0A>>>From: = Anthony Nadalin =0A>>>Date: Fri, 12 Aug 2011 12:06= :36 -0700=0A>>>To: "OAuth WG (oauth@ietf.org)" =0A>>>Subje= ct: [OAUTH-WG] Auth Code Swap Attack=0A>>>=0A>>>=0A>>> =0A>>>=0A>>>=0A>>>= =0A>>>Recommended Changes to draft-ietf-oauth-v2=0A>>>>=A0=0A>>>>In section= 4, request options (e.g. 4.1.1) featuring "state" should change from:=0A>>= >>=A0=0A>>>>state=0A>>>>OPTIONAL. An opaque value used by the client to mai= ntain state between the request and callback. The authorization server incl= udes this value when redirecting the user-agent back to the client.=0A>>>>= =A0=0A>>>>to:=0A>>>>=A0=0A>>>>state=0A>>>>REQUIRED. An opaque value used by= the client to maintain state between the request and callback. The authori= zation server includes this value when redirecting the user-agent back to t= he client. The encoded value SHOULD enable the client application to determ= ine the user-context that was active at the time of the =A0request (see sec= tion 10.12). The value MUST NOT be guessable or predictable, and MUST be ke= pt confidential.=0A>>>>=A0 =0A>>>=0A>>>=0A>>>Making the parameter required = without making its usage required (I.e. "value SHOULD enable") accomplishes= nothing. Also, what does "MUST be kept confidential" mean? Confidential fr= om what? Why specify an "encoded value"?=0A>>>=0A>>>=0A>>>=0A>>>Section 10.= 12 Cross-Site Request Forgery=0A>>>>=A0=0A>>>>Change to:=0A>>>>=A0=0A>>>>Cr= oss-site request forgery (CSRF) is a web-based attack whereby HTTP requests= are transmitted from the user-agent of an end-user=A0the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the=A0resource owner resulting in a compr= omise of either the resource server or of the client application itself. In= the OAuth context, such=A0attacks allow an attacker to inject their own = authorization code or access token into a client, which ca= n result in the client using an=A0access token associated with the attacker= 's account rather than the victim's. Depending on the nature of the client = and the protected=A0resources, this can have undesirable and damaging effec= ts.=0A>>>>=0A>>>>In order to prevent such attacks, the client=0A = application MUST encode a non-guessable,=0A con= fidential end-user artifact and submit as=A0the=0A "stat= e" parameter to authorization and access token=0A reques= ts to the authorization server. The client=0A MUST keep = the state value in=A0a location accessible only by the c= lient or the user-agent (i.e.,=0A protected by same-orig= in policy), for example, using=0A a DOM variable,=A0HTTP= cookie, or HTML5 client-side=0A storage.=0A>>>>=0A>>>>T= he authorization server includes the value of the=0A "st= ate" parameter when redirecting the user-agent=0A back t= o the client. Upon=A0receiving a redirect, the client ap= plication MUST confirm that returned value=0A of "state"= corresponds to the state value of the=0A user-agent's u= ser session. If the end-user session=0A represents an au= thenticated user-identity, the=0A client MUST ensure tha= t the user-identity=A0has NOT=0A changed.=0A>>>>=A0 =0A>= >>=0A>>>=0A>>>The above text uses 'user-context' and this 'user-identity'. = Neither term is defined.=0A>>>=0A>>>=0A>>>EHL=0A>>>=0A>>>=0A>>>____________= ___________________________________=0AOAuth mailing list OAuth@ietf.orghttp= s://www.ietf.org/mailman/listinfo/oauth=0A_________________________________= ______________=0A>>OAuth mailing list=0A>>OAuth@ietf.org=0A>>https://www.ie= tf.org/mailman/listinfo/oauth=0A>>=0A> =0A_________________________________= ______________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org= /mailman/listinfo/oauth --0-1541028779-1313252527=:98143 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All CSRF attacks are a against the client (confused deputy) yes.  Th= e defense is always in the server side.  I agree that it's really wort= h covering.  There are already good discussions of CSRF o= ut there which I think we shoudl lean on rather than re-writing our own, i.= e. http://www.rfc-editor.org/rfc/rfc6265.txt

-bill

From: Eran Hammer-Lahav <eran@hueni= verse.com>
To: Phil = Hunt <phil.hunt@oracle.com>; Torsten Lodderstedt <torsten@lodderstedt.= net>
Cc: "OAuth WG (= oauth@ietf.org)" <oauth@ietf.org>
Sent: Saturday, August 13, 2011 7:30 AM
Subject: Re: [OAUTH-WG] Auth Code Swap A= ttack

All OAuth CSRF attacks ar= e on the client.

EHL

From: Phil Hunt <phil.hunt@oracle.com>
Date: Sat, 13 Aug 2011 00:21:50 -0700<= br>To: Torsten Lodderstedt <torsten@lodderstedt.net>=
Cc: Eran Hammer-lahav <eran@hueniverse.com>, "OAuth WG (= oauth@ietf.org)" <oauth@ietf.org>
Subject: = Re: [OAUTH-WG] Auth Code Swap Attack

+1 (to putting more detail in the Threat Model document)
Yes, this is another CSRF attack (hence the change to 10.= 2). 

What is *new* is this is an attack on th= e client application rather than the resource server. As such, I agr= ee this new attack vector is well deserving of wider review and discussion = before finalizing the draft.

Phil



On 2011-08-12, at 11:58 PM, Torsten = Lodderstedt wrote:

=0A =0A =0A =0A
=0A
=0A
=0A Am = 12.08.2011 23:52, schrieb Eran Hammer-Lahav:=0A
=0A
This is really just a flavor of CSRF attacks. I have no=0A = objections to better documenting it (though I feel the current=0A = text is already sufficient), but we can't realistically expect=0A = to identify and close every possible browser-based attack. A new=0A = one is invented every other week.
=0A

=0A
= =0A
The problem with this text is that developers who do no=0A = understand CSRF attacks are not likely to implement it correctly=0A = with this information. Those who understand it do not need the=0A = extra verbiage which is more confusing than helpful.
=0A =0A
=0A We are constantly facing the fact that a comprehens= ive description=0A of security threats needs more space than we have in = the core draft.=0A That's the reason why the security document has 63 pa= ges and that's=0A also the reason why we decided to let the core spec re= fer to this=0A document for in-depth explanations. This holds true for t= his threat=0A as well.
=0A
=0A regards,
=0A Torsten. =
=0A
=0A
=0A

=0A =
=0A
As for the new requirements, they are insufficient to= =0A actually accomplish what the authors propose without additional= =0A requirements on state local storage and verification to complete= =0A the flow. Also, the proposed text needs clarifications as noted= =0A below.
=0A

=0A
=0A

= =0A
=0A =0A =
From= : Anthony Nadalin <ton= ynad@microsoft.com>
=0A Date: Fri, 12 Aug 2011=0A 12:06:36 -0700
=0A = To: "OAuth WG (oauth@ietf.org)"=0A <oauth@ietf.org>
=0A S= ubject: [OAUTH-WG]=0A Auth Code Swap Attack
=0A =
=0A

=0A
=0A
=0A
=0A
=0A
=0A =0A

=0A
=0A

=0A
=0A = =0A
=0A
=0A =
=0A
Recommended=0A Ch= anges to draft-ietf-oauth-v2
 <= /div>
 
state
OPTIONAL.=0A = An opaque value used by the client to maintain state=0A = between the request and callback. The authorization=0A = server includes this value when redirecting the=0A user-= agent back to the client.
=  
to:
 
= state
REQUIRED.=0A An opaque value used by the clie= nt to maintain state=0A between the request and callback= . The authorization=0A server includes this value when r= edirecting the=0A user-agent back to the client. The enc= oded value=0A SHOULD enable the client application to de= termine=0A the user-context that was active at the time = of the=0A  request (see section 10.12). The value M= UST NOT be=0A guessable or predictable, and MUST be kept= =0A confidential.
 
=0A
=0A
=0A
= =0A =0A =0A

=0A
= =0A
Making the parameter required without making its usage=0A = required (I.e. "value SHOULD enable") accomplishes nothing.=0A A= lso, what does "MUST be kept confidential" mean? Confidential=0A fro= m what? Why specify an "encoded value"?
=0A

=0A =0A

=0A
=0A =0A
=0A
=0A
=0A =
Section 10.12 Cross-Site Reque= st=0A Forgery
 
<= div class=3D"yiv207853719MsoNormal">Chan= ge to:
 
Cross-site=0A = request forgery (CSRF) is a web-based attack whereby=0A = HTTP requests are transmitted from the user-agent of=0A = an end-user the server trusts or has authenticated.= =0A CSRF attacks enable the attacker to intermix the=0A = attacker's security context with that of=0A = the resource owner resulting in a compromise of=0A = either the resource server or of the client=0A ap= plication itself. In the OAuth context,=0A such att= acks allow an attacker to inject their own authorization= code or access token into a client,=0A which can result= in the client using an access token=0A associated = with the attacker's account rather than=0A the victim's.= Depending on the nature of the client=0A and the protec= ted resources, this can have=0A undesirable and dam= aging effects.
=0A
=0A In orde= r to prevent such attacks, the client=0A application MUS= T encode a non-guessable,=0A confidential end-user artif= act and submit as the=0A "state" parameter to autho= rization and access token=0A requests to the authorizati= on server. The client=0A MUST keep the state value in&nb= sp;a location accessible only by the client or the user-= agent (i.e.,=0A protected by same-origin policy), for ex= ample, using=0A a DOM variable, HTTP cookie, or HTM= L5 client-side=0A storage.
=0A =0A The authorization server includes the value of the= =0A "state" parameter when redirecting the user-agent=0A= back to the client. Upon receiving a redirect, the= client application MUST confirm that returned value=0A = of "state" corresponds to the state value of the=0A = user-agent's user session. If the end-user session=0A = represents an authenticated user-identity, the=0A = client MUST ensure that the user-identity has NOT=0A = changed.
 <= /div> =0A
=0A
=0A
=0A =
=0A =0A

=0A
=0A =
The above text uses 'user-context' and this 'user-identity'.=0A = Neither term is defined.
=0A

=0A
=0A <= div>EHL
=0A
=0A
=0A
=0A 
________________________=
_______________________=0AOAuth mailing list=0AOAuth@ietf.orghttps://www.ietf.org/mail=
man/listinfo/oauth
=0A =0A
=0A=0A__________= _____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

=0A
_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list= info/oauth


--0-1541028779-1313252527=:98143-- From phil.hunt@oracle.com Sat Aug 13 16:40:43 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326AE21F8A55 for ; Sat, 13 Aug 2011 16:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCnXkNXsRSXS for ; Sat, 13 Aug 2011 16:40:41 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9FC21F8A36 for ; Sat, 13 Aug 2011 16:40:41 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7DNfH6J028270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Aug 2011 23:41:19 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7DNfF3I013613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2011 23:41:16 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7DNf9Jt028245; Sat, 13 Aug 2011 18:41:09 -0500 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 13 Aug 2011 16:41:09 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-82--35781592 From: Phil Hunt In-Reply-To: Date: Sat, 13 Aug 2011 16:41:07 -0700 Message-Id: References: To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090202.4E470BA0.002F,ss=1,re=-2.300,fgs=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 23:40:43 -0000 --Apple-Mail-82--35781592 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There are two CSRF variations scenarios that I see. I can attack you and give my client access to your resources (original = attack on the "resource"). I can attack you and give your client access to my resource (new attack = on the "client"). Attack on the client vs. attack on the resource may be misleading here. = Draft 20 only referred to attacks on the "resource" in its original CSRF = description. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-13, at 7:30 AM, Eran Hammer-Lahav wrote: > All OAuth CSRF attacks are on the client. >=20 > EHL >=20 > From: Phil Hunt > Date: Sat, 13 Aug 2011 00:21:50 -0700 > To: Torsten Lodderstedt > Cc: Eran Hammer-lahav , "OAuth WG = (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Auth Code Swap Attack >=20 >> +1 (to putting more detail in the Threat Model document) >>=20 >> Yes, this is another CSRF attack (hence the change to 10.2).=20 >>=20 >> What is *new* is this is an attack on the client application rather = than the resource server. As such, I agree this new attack vector is = well deserving of wider review and discussion before finalizing the = draft. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: >>=20 >>>=20 >>>=20 >>> Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: >>>>=20 >>>> This is really just a flavor of CSRF attacks. I have no objections = to better documenting it (though I feel the current text is already = sufficient), but we can't realistically expect to identify and close = every possible browser-based attack. A new one is invented every other = week. >>>>=20 >>>> The problem with this text is that developers who do no understand = CSRF attacks are not likely to implement it correctly with this = information. Those who understand it do not need the extra verbiage = which is more confusing than helpful. >>>=20 >>> We are constantly facing the fact that a comprehensive description = of security threats needs more space than we have in the core draft. = That's the reason why the security document has 63 pages and that's also = the reason why we decided to let the core spec refer to this document = for in-depth explanations. This holds true for this threat as well. >>>=20 >>> regards, >>> Torsten.=20 >>>=20 >>>>=20 >>>> As for the new requirements, they are insufficient to actually = accomplish what the authors propose without additional requirements on = state local storage and verification to complete the flow. Also, the = proposed text needs clarifications as noted below. >>>>=20 >>>>=20 >>>> From: Anthony Nadalin >>>> Date: Fri, 12 Aug 2011 12:06:36 -0700 >>>> To: "OAuth WG (oauth@ietf.org)" >>>> Subject: [OAUTH-WG] Auth Code Swap Attack >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Recommended Changes to draft-ietf-oauth-v2 >>>>> =20 >>>>> In section 4, request options (e.g. 4.1.1) featuring "state" = should change from: >>>>> =20 >>>>> state >>>>> OPTIONAL. An opaque value used by the client to maintain state = between the request and callback. The authorization server includes this = value when redirecting the user-agent back to the client. >>>>> =20 >>>>> to: >>>>> =20 >>>>> state >>>>> REQUIRED. An opaque value used by the client to maintain state = between the request and callback. The authorization server includes this = value when redirecting the user-agent back to the client. The encoded = value SHOULD enable the client application to determine the user-context = that was active at the time of the request (see section 10.12). The = value MUST NOT be guessable or predictable, and MUST be kept = confidential. >>>>> =20 >>>>=20 >>>>=20 >>>> Making the parameter required without making its usage required = (I.e. "value SHOULD enable") accomplishes nothing. Also, what = does "MUST be kept confidential" mean? Confidential from what? Why = specify an "encoded value"? >>>>=20 >>>>=20 >>>>> Section 10.12 Cross-Site Request Forgery >>>>> =20 >>>>> Change to: >>>>> =20 >>>>> Cross-site request forgery (CSRF) is a web-based attack whereby = HTTP requests are transmitted from the user-agent of an end-user the = server trusts or has authenticated. CSRF attacks enable the attacker to = intermix the attacker's security context with that of the resource owner = resulting in a compromise of either the resource server or of the client = application itself. In the OAuth context, such attacks allow an attacker = to inject their own authorization code or access token into a client, = which can result in the client using an access token associated with the = attacker's account rather than the victim's. Depending on the nature of = the client and the protected resources, this can have undesirable and = damaging effects. >>>>>=20 >>>>> In order to prevent such attacks, the client application MUST = encode a non-guessable, confidential end-user artifact and submit as the = "state" parameter to authorization and access token requests to the = authorization server. The client MUST keep the state value in a location = accessible only by the client or the user-agent (i.e., protected by = same-origin policy), for example, using a DOM variable, HTTP cookie, or = HTML5 client-side storage. >>>>>=20 >>>>> The authorization server includes the value of the "state" = parameter when redirecting the user-agent back to the client. Upon = receiving a redirect, the client application MUST confirm that returned = value of "state" corresponds to the state value of the user-agent's user = session. If the end-user session represents an authenticated = user-identity, the client MUST ensure that the user-identity has NOT = changed. >>>>> =20 >>>>=20 >>>>=20 >>>> The above text uses 'user-context' and this 'user-identity'. = Neither term is defined. >>>>=20 >>>> EHL >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 --Apple-Mail-82--35781592 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii There = are two CSRF variations scenarios that I see.

I can = attack you and give my client access to your resources (original attack = on the "resource").

I can attack you and give = your client access to my resource (new attack on the = "client").

Attack on the client vs. attack on = the resource may be misleading here.  Draft 20 only referred to = attacks on the "resource" in its original CSRF = description.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-08-13, at 7:30 AM, Eran Hammer-Lahav = wrote:

All OAuth CSRF = attacks are on the = client.

EHL

From: = Phil Hunt <phil.hunt@oracle.com>
Date: Sat, 13 Aug 2011 00:21:50 = -0700
To: Torsten = Lodderstedt <torsten@lodderstedt.net>Cc: Eran Hammer-lahav <eran@hueniverse.com>, "OAuth = WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Auth Code = Swap Attack

+1 (to putting more detail in = the Threat Model document)

Yes, this is another CSRF = attack (hence the change to 10.2). 

What = is *new* is this is an attack on the client application rather = than the resource server. As such, I agree this new attack vector is = well deserving of wider review and discussion before finalizing the = draft.

Phil

On 2011-08-12, = at 11:58 PM, Torsten Lodderstedt wrote:

=20 =20 =20


Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav:
This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week.

The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful.

We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well.

regards,
Torsten.


As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below.


From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 Aug = 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack


Recommended Changes to = draft-ietf-oauth-v2
 
In = section 4, request options (e.g. 4.1.1) featuring "state" should change = from:
 
state
OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the = client.
 
 
state
REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the  request (see section 10.12). The value MUST = NOT be guessable or predictable, and MUST be kept confidential.
 

Making the parameter required without making its usage required (I.e. "value SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confidential" mean? Confidential from what? Why specify an "encoded value"?


Section 10.12 Cross-Site Request Forgery
 
Change = to:
 
Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has = authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to inject their = own authorization code or access token into a client, which can result in the client using an access = token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit = as the "state" parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location = accessible only by the client or the user-agent = (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 = client-side storage.

The authorization server includes the value of the "state" parameter when redirecting the user-agent back to the client. Upon receiving a redirect, = the client application MUST confirm that returned = value of "state" corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has = NOT changed.
 

The above text uses 'user-context' and this 'user-identity'. Neither term is defined.

EHL


_______________________________________________
OAuth mailing list
OAuth@ietf.orghttps://www.ietf.org/=
mailman/listinfo/oauth
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


= --Apple-Mail-82--35781592-- From wmills@yahoo-inc.com Sat Aug 13 21:15:49 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2B921F8715 for ; Sat, 13 Aug 2011 21:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.243 X-Spam-Level: X-Spam-Status: No, score=-17.243 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUv7NF5a0M8Q for ; Sat, 13 Aug 2011 21:15:47 -0700 (PDT) Received: from nm34-vm5.bullet.mail.bf1.yahoo.com (nm34-vm5.bullet.mail.bf1.yahoo.com [72.30.239.77]) by ietfa.amsl.com (Postfix) with SMTP id 60EBC21F86BD for ; Sat, 13 Aug 2011 21:15:47 -0700 (PDT) Received: from [98.139.212.153] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 14 Aug 2011 04:16:24 -0000 Received: from [98.139.212.248] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 14 Aug 2011 04:16:24 -0000 Received: from [127.0.0.1] by omp1057.mail.bf1.yahoo.com with NNFMP; 14 Aug 2011 04:16:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 743607.35354.bm@omp1057.mail.bf1.yahoo.com Received: (qmail 77367 invoked by uid 60001); 14 Aug 2011 04:16:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313295383; bh=x4WSDRi6sUawrDfcJCcMK1+BTtPrSLBDSyhHpNCKa+0=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q6oYmHmu6hvFBMIbJtGsPdCUhRXDbIir+pR2S1tRnQaxfNEdtdd4yztzZ9xO/Vo7bVNfEHJk5Gv+QpkoSaaxFweegBzpQy4fiuoQztxGprdCX+RCwWSI4PRv96VwBrRNWUIjOw1F8aIqa5QelXzpA7QKp7Tgo6WAVCTfJRx+XHo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=opUfFfcYKAE+caUySpYx+ZM+5s6pgZE19L1nsEsMmuQdPLsVdG4x73bR2Hp3YZigwjRpAsuXUWLeHxr8+ZnqNPvxNmyOJNiL3eZxY2/us7l37RAAymwslnsEfqTDljOg/MHOL4AzREOLXeEZd8VZLEuuW1UMw3HV0VxNvSpeB+k=; X-YMail-OSG: MA6IhAUVM1lC7noGX.rC8R2gA.UGl_Iq0rijdEGO_98Zayr uV7spuGZi.jQV19XIj5WKqSoGgE2wWCw.ClzSWB11ls50zaTKbkIMwHl64Tc lkSPBCtKU8x32rb7kwdQdtYz_oR04FqfZwzzLVKMso5Ryx9zAfbWkdqA_H.z DNTsAKZaurN41Rjp61bpIa1ZD0B_Bxz5eh9jHuoPMt2u_Nd12BRJtJuYK.68 3F8G0yli4hZMOIrlArTiANMz6TAFyGLyWOqBljJXRpTtY4gNe0ZtxoGOmB7P rbAKp9r8OIUbgbznDrTUbpC6x50dYFqRnbtwR2I5.VPS_VOFdYPwjZ1qACMf pT8cp6LBWUZf8iju0Y8b5oymslJxose32FO90Er_Sm.oxV7B0yHsEAUYSmbk pfq7lUfmHIPGt8YAwQcrMWgXyTGXgyTSDOhVZ1kWVDNoRCflya.CVSIfdfPE .d__ciCgmZMeOXHjum2o_2GhgKhU5AtWWA5tq0uxrT8SL7kB6up.mu5TgtW9 0P1P5iCeNnocZK87HnqnhMCKSCgkcx2hscy.p Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Sat, 13 Aug 2011 21:16:23 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: Message-ID: <1313295383.69882.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Sat, 13 Aug 2011 21:16:23 -0700 (PDT) From: "William J. Mills" To: Phil Hunt , Eran Hammer-Lahav In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1951798441-1313295383=:69882" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 04:15:49 -0000 --0-1951798441-1313295383=:69882 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The defense is the same though, correct?=0A=0A=0A=0A_______________________= _________=0AFrom: Phil Hunt =0ATo: Eran Hammer-Lahav = =0ACc: "OAuth WG (oauth@ietf.org)" =0A= Sent: Saturday, August 13, 2011 4:41 PM=0ASubject: Re: [OAUTH-WG] Auth Code= Swap Attack=0A=0A=0AThere are two CSRF variations scenarios that I see.=0A= =0AI can attack you and give my client access to your resources (original a= ttack on the "resource").=0A=0AI can attack you and give your client access= to my resource (new attack on the "client").=0A=0AAttack on the client vs.= attack on the resource may be misleading here. =A0Draft 20 only referred t= o attacks on the "resource" in its original CSRF description.=0A=0APhil=0A= =0A@independentid=0Awww.independentid.comphil.hunt@oracle.com=0A=0A=0A=0A= =0A=0A=0AOn 2011-08-13, at 7:30 AM, Eran Hammer-Lahav wrote:=0A=0AAll OAuth= CSRF attacks are on the client.=0A>=0A>=0A>EHL=0A>=0A>From: Phil Hunt =0A>Date: Sat, 13 Aug 2011 00:21:50 -0700=0A>To: Torst= en Lodderstedt =0A>Cc: Eran Hammer-lahav , "OAuth WG (oauth@ietf.org)" =0A>Subject: Re= : [OAUTH-WG] Auth Code Swap Attack=0A>=0A>=0A>=0A>+1 (to putting more detai= l in the Threat Model document)=0A>>=0A>>=0A>>Yes, this is another CSRF att= ack (hence the change to 10.2).=A0=0A>>=0A>>=0A>>What is *new* is this is a= n attack on the client application rather than the resource server. As such= , I agree this new attack vector is well deserving of wider review and disc= ussion before finalizing the draft.=0A>>=0A>>=0A>>Phil=0A>>=0A>>=0A>>@indep= endentid=0A>>www.independentid.comphil.hunt@oracle.com=0A>>=0A>>=0A>>=0A>>= =0A>>=0A>>=0A>>On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote:=0A>>= =0A>>=0A>>>=0A>>>Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: =0A>>>This= is really just a flavor of CSRF attacks. I have no objections to better do= cumenting it (though I feel the current text is already sufficient), but we= can't realistically expect to identify and close every possible browser-ba= sed attack. A new one is invented every other week.=0A>>>>=0A>>>>=0A>>>>The= problem with this text is that developers who do no understand CSRF attack= s are not likely to implement it correctly with this information. Those who= understand it do not need the extra verbiage which is more confusing than = helpful.=0A>>>We are constantly facing the fact that a comprehensive descri= ption=0A of security threats needs more space than we have in the core d= raft.=0A That's the reason why the security document has 63 pages and th= at's=0A also the reason why we decided to let the core spec refer to thi= s=0A document for in-depth explanations. This holds true for this threat= =0A as well.=0A>>>=0A>>>regards,=0A>>>Torsten. =0A>>>=0A>>>=0A>>>=0A>>>>= =0A>>>>As for the new requirements, they are insufficient to actually accom= plish what the authors propose without additional requirements on state loc= al storage and verification to complete the flow. Also, the proposed text n= eeds clarifications as noted below.=0A>>>>=0A>>>>=0A>>>>=0A>>>>From: Antho= ny Nadalin =0A>>>>Date: Fri, 12 Aug 2011 12:06:36 -= 0700=0A>>>>To: "OAuth WG (oauth@ietf.org)" =0A>>>>Subject:= [OAUTH-WG] Auth Code Swap Attack=0A>>>>=0A>>>>=0A>>>> =0A>>>>=0A>>>>=0A>>= >>=0A>>>>Recommended Changes to draft-ietf-oauth-v2=0A>>>>>=A0=0A>>>>>In se= ction 4, request options (e.g. 4.1.1) featuring "state" should change from:= =0A>>>>>=A0=0A>>>>>state=0A>>>>>OPTIONAL. An opaque value used by the clien= t to maintain state between the request and callback. The authorization ser= ver includes this value when redirecting the user-agent back to the client.= =0A>>>>>=A0=0A>>>>>to:=0A>>>>>=A0=0A>>>>>state=0A>>>>>REQUIRED. An opaque v= alue used by the client to maintain state between the request and callback.= The authorization server includes this value when redirecting the user-age= nt back to the client. The encoded value SHOULD enable the client applicati= on to determine the user-context that was active at the time of the =A0requ= est (see section 10.12). The value MUST NOT be guessable or predictable, an= d MUST be kept confidential.=0A>>>>>=A0 =0A>>>>=0A>>>>=0A>>>>Making the par= ameter required without making its usage required (I.e. "value SHOULD enabl= e") accomplishes nothing. Also, what does "MUST be kept confidential" mean?= Confidential from what? Why specify an "encoded value"?=0A>>>>=0A>>>>=0A>>= >>=0A>>>>Section 10.12 Cross-Site Request Forgery=0A>>>>>=A0=0A>>>>>Change = to:=0A>>>>>=A0=0A>>>>>Cross-site request forgery (CSRF) is a web-based atta= ck whereby HTTP requests are transmitted from the user-agent of an end-user= =A0the server trusts or has authenticated. CSRF attacks enable the attacker= to intermix the attacker's security context with that of the=A0resource ow= ner resulting in a compromise of either the resource server or of the clien= t application itself. In the OAuth context, such=A0attacks allow an attacke= r to inject their own authorization code or access token= into a client, which can result in the client using an=A0access token asso= ciated with the attacker's account rather than the victim's. Depending on t= he nature of the client and the protected=A0resources, this can have undesi= rable and damaging effects.=0A>>>>>=0A>>>>>In order to prevent such attacks= , the client=0A application MUST encode a non-guessable,= =0A confidential end-user artifact and submit as=A0the= =0A "state" parameter to authorization and access token= =0A requests to the authorization server. The client=0A = MUST keep the state value in=A0a location accessible = only by the client or the user-agent (i.e.,=0A = protected by same-origin policy), for example, using=0A = a DOM variable,=A0HTTP cookie, or HTML5 client-side=0A = storage.=0A>>>>>=0A>>>>>The authorization server includes the value o= f the=0A "state" parameter when redirecting the user-age= nt=0A back to the client. Upon=A0receiving a redirect, t= he client application MUST confirm that returned value= =0A of "state" corresponds to the state value of the=0A = user-agent's user session. If the end-user session=0A = represents an authenticated user-identity, the=0A = client MUST ensure that the user-identity=A0has NOT=0A = changed.=0A>>>>>=A0 =0A>>>>=0A>>>>=0A>>>>The above text uses 'use= r-context' and this 'user-identity'. Neither term is defined.=0A>>>>=0A>>>>= =0A>>>>EHL=0A>>>>=0A>>>>=0A>>>>____________________________________________= ___=0AOAuth mailing list OAuth@ietf.orghttps://www.ietf.org/mailman/listinf= o/oauth=0A_______________________________________________=0A>>>OAuth mailin= g list=0A>>>OAuth@ietf.org=0A>>>https://www.ietf.org/mailman/listinfo/oauth= =0A>>>=0A>>=0A=0A_______________________________________________=0AOAuth ma= iling list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-1951798441-1313295383=:69882 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The defense is the same though, correct?

<= div style=3D"font-family: Courier New, courier, monaco, monospace, sans-ser= if; font-size: 10pt;">
From: Phil Hunt <= phil.hunt@oracle.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf= .org>
Sent: Saturday= , August 13, 2011 4:41 PM
Subject:= Re: [OAUTH-WG] Auth Code Swap Attack

There are two CSRF variations scenarios that I see.

I can att= ack you and give my client access to your resources (original attack on the= "resource").

I can attack you and give your clien= t access to my resource (new attack on the "client").

<= div>Attack on the client vs. attack on the resource may be misleading here.=  Draft 20 only referred to attacks on the "resource" in its original = CSRF description.

=0A
Phil

=
@independentid
<= /div>phil.hunt@oracle.com


<= br class=3D"yiv1101594262Apple-interchange-newline">
=0A
=0A
On 2011-08-1= 3, at 7:30 AM, Eran Hammer-Lahav wrote:

From: Phil= Hunt <phil.hunt@oracle.com&= gt;
Date: Sat, 13 Aug 2011 00:= 21:50 -0700
To: Torsten Lodderstedt <tors= ten@lodderstedt.net>
Cc: Eran Hammer-lahav <eran@hueniver= se.com>, "OAuth WG (oauth@ietf.org)"= <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
=

+1 (to putt= ing more detail in the Threat Model document)

Yes, this is another CSRF attack (hence the c= hange to 10.2). 

What is *new* is this is an = attack on the client application rather than the resource server. As= such, I agree this new attack vector is well deserving of wider review and= discussion before finalizing the draft.

Phil<= /div>

On 2011-08-12, at 11= :58 PM, Torsten Lodderstedt wrote:

=0A =0A =0A =0A
=0A =
=0A
=0A Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav:=0A=
=0A
This is really just a flavor of= CSRF attacks. I have no=0A objections to better documenting it (tho= ugh I feel the current=0A text is already sufficient), but we can't = realistically expect=0A to identify and close every possible browser= -based attack. A new=0A one is invented every other week.
=0A =

=0A
=0A
The problem with this text is tha= t developers who do no=0A understand CSRF attacks are not likely to = implement it correctly=0A with this information. Those who understan= d it do not need the=0A extra verbiage which is more confusing than = helpful.
=0A
=0A
=0A We are constantly facin= g the fact that a comprehensive description=0A of security threats needs= more space than we have in the core draft.=0A That's the reason why the= security document has 63 pages and that's=0A also the reason why we dec= ided to let the core spec refer to this=0A document for in-depth explana= tions. This holds true for this threat=0A as well.
=0A
=0A = regards,
=0A Torsten.
=0A
=0A
=0A

=0A
=0A
As for the new requirements= , they are insufficient to=0A actually accomplish what the authors p= ropose without additional=0A requirements on state local storage and= verification to complete=0A the flow. Also, the proposed text needs= clarifications as noted=0A below.
=0A

=0A <= /div>=0A

=0A
=0A =0A
From: Anthony Nadalin <tonynad@microsoft.com>
=0A Date: Fri, 12 Aug 2011=0A 12:06:= 36 -0700
=0A To: "OAu= th WG (oauth@ietf.org)"=0A <oauth@ietf.org>
=0A Subject: [OAUTH-WG]=0A Auth Code = Swap Attack
=0A
=0A

=0A
=0A =
=0A
=0A
=0A
=0A <= /span>=0A

=0A
=0A

=0A
=0A= =0A =0A =
=0A
=0A
Recommended=0A = Changes to draft-ietf-oauth-v2
 
In section 4, request options (e.g.=0A = 4.1.1) featuring "state" should change from:
=  
state
OPTIO= NAL.=0A An opaque value used by the client to maintain s= tate=0A between the request and callback. The authorizat= ion=0A server includes this value when redirecting the= =0A user-agent back to the client.
 
to:
 
state
REQUIRED.=0A = An opaque value used by the client to maintain state=0A = between the request and callback. The authorization=0A = server includes this value when redirecting the=0A user= -agent back to the client. The encoded value=0A SHOULD e= nable the client application to determine=0A the user-co= ntext that was active at the time of the=0A  reques= t (see section 10.12). The value MUST NOT be=0A guessabl= e or predictable, and MUST be kept=0A confidential.
 
=0A
=0A =
=0A
=0A
=0A = =0A

=0A
=0A
Making the parameter require= d without making its usage=0A required (I.e. "value SHOULD enable") = accomplishes nothing.=0A Also, what does "MUST be kept confidential"= mean? Confidential=0A from what? Why specify an "encoded value"?=0A

=0A
=0A

=0A
=0A = =0A
=0A =
=0A
=0A
Section 10.12 Cross-Site Request=0A = Forgery
 
Change to:=
 
Cross-site=0A = request forgery (CSRF) is a web-based attack whereby=0A = HTTP requests are transmitted from the user-agent of=0A = an end-user the server trusts or has authenticated.=0A = CSRF attacks enable the attacker to intermix the=0A = attacker's security context with that of=0A the re= source owner resulting in a compromise of=0A either the = resource server or of the client=0A application itself. = In the OAuth context,=0A such attacks allow an atta= cker to inject their own authorization code or access to= ken into a client,=0A which can result in the client usi= ng an access token=0A associated with the attacker'= s account rather than=0A the victim's. Depending on the = nature of the client=0A and the protected resources= , this can have=0A undesirable and damaging effects.
= =0A
=0A In order to prevent such = attacks, the client=0A application MUST encode a non-gue= ssable,=0A confidential end-user artifact and submit as&= nbsp;the=0A "state" parameter to authorization and acces= s token=0A requests to the authorization server. The cli= ent=0A MUST keep the state value in a location acce= ssible only by the client or the user-agent (i.e.,=0A = protected by same-origin policy), for example, using=0A = a DOM variable, HTTP cookie, or HTML5 client-side=0A = storage.
=0A
=0A = The authorization server includes the value of the=0A = "state" parameter when redirecting the user-agent=0A = back to the client. Upon receiving a redirect, the = client application MUST confirm that returned value=0A = of "state" corresponds to the state value of the=0A user= -agent's user session. If the end-user session=0A repres= ents an authenticated user-identity, the=0A client MUST = ensure that the user-identity has NOT=0A changed.
 
=0A =
=0A
=0A
=0A
= =0A =0A

=0A
=0A
The above te= xt uses 'user-context' and this 'user-identity'.=0A Neither term is = defined.
=0A

=0A
=0A
EHL
=0A =
=0A
=0A
=0A 
_________________________________________=
______=0AOAuth mailing list=0AOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o=
auth
=0A
=0A
=0A=0A________________________= _______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth

=0A


_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth


--0-1951798441-1313295383=:69882-- From phil.hunt@oracle.com Sat Aug 13 22:54:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152D621F8841 for ; Sat, 13 Aug 2011 22:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=-1.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pAtjaea5mL5 for ; Sat, 13 Aug 2011 22:54:49 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id E934A21F8742 for ; Sat, 13 Aug 2011 22:54:48 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7E5tRqH028341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 14 Aug 2011 05:55:29 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7E5tOlM020075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Aug 2011 05:55:25 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7E5tJ4K012527; Sun, 14 Aug 2011 00:55:19 -0500 Received: from [192.168.1.67] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 13 Aug 2011 22:55:19 -0700 References: <1313295383.69882.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: <1313295383.69882.YahooMailNeo@web31808.mail.mud.yahoo.com> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-16--13328470 Message-Id: <4DE6F907-E45B-4F70-9CE7-FF58ABE13BF6@oracle.com> X-Mailer: iPhone Mail (8L1) From: Phillip Hunt Date: Sat, 13 Aug 2011 22:55:18 -0700 To: "William J. Mills" X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090206.4E476351.002E,ss=1,re=-2.300,fgs=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 05:54:50 -0000 --Apple-Mail-16--13328470 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii No. I don't think so. In the new variant the client has to check the returne= d state to confirm it has not changed or associated with a different user. =20= Previously the authz server had to do the checks.=20 Phil On 2011-08-13, at 21:16, "William J. Mills" wrote: > The defense is the same though, correct? >=20 > From: Phil Hunt > To: Eran Hammer-Lahav > Cc: "OAuth WG (oauth@ietf.org)" > Sent: Saturday, August 13, 2011 4:41 PM > Subject: Re: [OAUTH-WG] Auth Code Swap Attack >=20 > There are two CSRF variations scenarios that I see. >=20 > I can attack you and give my client access to your resources (original att= ack on the "resource"). >=20 > I can attack you and give your client access to my resource (new attack on= the "client"). >=20 > Attack on the client vs. attack on the resource may be misleading here. D= raft 20 only referred to attacks on the "resource" in its original CSRF desc= ription. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2011-08-13, at 7:30 AM, Eran Hammer-Lahav wrote: >=20 >> All OAuth CSRF attacks are on the client. >>=20 >> EHL >>=20 >> From: Phil Hunt >> Date: Sat, 13 Aug 2011 00:21:50 -0700 >> To: Torsten Lodderstedt >> Cc: Eran Hammer-lahav , "OAuth WG (oauth@ietf.org)" <= oauth@ietf.org> >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>=20 >>> +1 (to putting more detail in the Threat Model document) >>>=20 >>> Yes, this is another CSRF attack (hence the change to 10.2).=20 >>>=20 >>> What is *new* is this is an attack on the client application rather than= the resource server. As such, I agree this new attack vector is well deserv= ing of wider review and discussion before finalizing the draft. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: >>>=20 >>>>=20 >>>>=20 >>>> Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: >>>>>=20 >>>>> This is really just a flavor of CSRF attacks. I have no objections to b= etter documenting it (though I feel the current text is already sufficient),= but we can't realistically expect to identify and close every possible brow= ser-based attack. A new one is invented every other week. >>>>>=20 >>>>> The problem with this text is that developers who do no understand CSR= F attacks are not likely to implement it correctly with this information. Th= ose who understand it do not need the extra verbiage which is more confusing= than helpful. >>>>=20 >>>> We are constantly facing the fact that a comprehensive description of s= ecurity threats needs more space than we have in the core draft. That's the r= eason why the security document has 63 pages and that's also the reason why w= e decided to let the core spec refer to this document for in-depth explanati= ons. This holds true for this threat as well. >>>>=20 >>>> regards, >>>> Torsten.=20 >>>>=20 >>>>>=20 >>>>> As for the new requirements, they are insufficient to actually accompl= ish what the authors propose without additional requirements on state local s= torage and verification to complete the flow. Also, the proposed text needs c= larifications as noted below. >>>>>=20 >>>>>=20 >>>>> From: Anthony Nadalin >>>>> Date: Fri, 12 Aug 2011 12:06:36 -0700 >>>>> To: "OAuth WG (oauth@ietf.org)" >>>>> Subject: [OAUTH-WG] Auth Code Swap Attack >>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Recommended Changes to draft-ietf-oauth-v2 >>>>>> =20 >>>>>> In section 4, request options (e.g. 4.1.1) featuring "state" should c= hange from: >>>>>> =20 >>>>>> state >>>>>> OPTIONAL. An opaque value used by the client to maintain state betwee= n the request and callback. The authorization server includes this value whe= n redirecting the user-agent back to the client. >>>>>> =20 >>>>>> to: >>>>>> =20 >>>>>> state >>>>>> REQUIRED. An opaque value used by the client to maintain state betwee= n the request and callback. The authorization server includes this value whe= n redirecting the user-agent back to the client. The encoded value SHOULD en= able the client application to determine the user-context that was active at= the time of the request (see section 10.12). The value= MUST NOT be guessable or predictable, and MUST be kept confidential. >>>>>> =20 --Apple-Mail-16--13328470 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
No. I don't think so. In the new varian= t the client has to check the returned state to confirm it has not changed o= r associated with a different user.  

Previous= ly the authz server had to do the checks. 

Phil

On= 2011-08-13, at 21:16, "William J. Mills" <wmills@yahoo-inc.com> wrote:

From: Phil Hunt &= lt;phil.hunt@oracle.com>
<= b>To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: "OAuth WG (oauth@ietf.org)" <oau= th@ietf.org>
Sent: Saturday, August 13, 2011 4:41 PM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

There are two CSRF variations scenarios that I see.

I can atta= ck you and give my client access to your resources (original attack on the "= resource").

I can attack you and give your client a= ccess to my resource (new attack on the "client").

= Attack on the client vs. attack on the resource may be misleading here. &nbs= p;Draft 20 only referred to attacks on the "resource" in its original CSRF d= escription.


<= /div>


On 2011-08-13, at 7:30 AM, Eran Hammer-Lahav wrote:

All OAuth CSRF attacks are on the client.

EHL

From:= Phil Hunt <phil.hunt@oracle.com>
Date: Sat, 13 Aug 2011 00:21:50 -0700
To: Torsten Lodderstedt <torsten@lodderstedt.net>
= Cc: Eran Hammer-lahav <eran@huen= iverse.com>, "OAuth WG (oauth@ietf.org)" <= oauth@ietf.org>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

+1 (to puttin= g more detail in the Threat Model document)

Yes, this is another CSRF attack (hence the ch= ange to 10.2). 

What is *new* is this is an at= tack on the client application rather than the resource server. As su= ch, I agree this new attack vector is well deserving of wider review and dis= cussion before finalizing the draft.

Phil
<= div>

=
On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote:
=20 =20 =20


Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav:
This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week.

The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful.

We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well.

regards,
Torsten.


As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below.


From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)"= <oa= uth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack


Recommended Changes to draft-ietf-oauth-v2
 
In section 4, request options (e.g. 4.1.1) featuring "state" should change from:
 
state
OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.
 
to:
 
st= ate
REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the  request (see section 10.12). The value MUST NOT be= guessable or predictable, and MUST be kept confidential.
 <= /div>=20
=
<= /div>= --Apple-Mail-16--13328470-- From john@jkemp.net Sun Aug 14 06:05:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FB221F8922 for ; Sun, 14 Aug 2011 06:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VjphMogZAf7 for ; Sun, 14 Aug 2011 06:05:39 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id B49B421F8593 for ; Sun, 14 Aug 2011 06:05:39 -0700 (PDT) Received: (qmail 22215 invoked by uid 0); 14 Aug 2011 13:06:21 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy2.bluehost.com with SMTP; 14 Aug 2011 13:06:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jkemp.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=V5tp7cDasN8W5wDHt0s4APp0nHtstmX4DdVctdqmuAo=; b=CfnUH6dWxAwtLPOMVkb5KOmH16ey+gANGT0U4rfvEtqub9Oj4EGLku1dO6L6LVOprr6C9MVHW1HuG+EkKxXF8m1A0NsJ1aELGu/WIaEo2nVO2ldhP7yXhe2M718zKKsE; Received: from cpe-74-67-30-101.nycap.res.rr.com ([74.67.30.101] helo=[192.168.1.108]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1QsaOS-0002Wc-Md; Sun, 14 Aug 2011 07:06:21 -0600 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: John Kemp In-Reply-To: Date: Sun, 14 Aug 2011 09:06:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9475CD54-9D1F-484D-9809-11241B5B7529@jkemp.net> References: To: Anthony Nadalin X-Mailer: Apple Mail (2.1244.3) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 74.67.30.101 authed with john+jkemp.net} Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 13:05:40 -0000 Hi Tony (et al), On Aug 12, 2011, at 3:06 PM, Anthony Nadalin wrote: [=85] > 2. Gene opens the spam mail and clicks on the link. > 3. The server running Basil's website initiates an = authorization request to Live. The request uses Plaxo's redirection URI. And why does Live believe that this is a valid authorization request? = Has Basil forged a request to Live as if it came from Plaxo (Basil has = at least the client_id for Plaxo's client)? Shouldn't Live protect its = authorization endpoint by requiring some authentication of the = requester? > The code running on Basil's server uses Basil's Live credentials to = login to Live and to grant the authorization request. Live responds with = a redirect containing an authorization code. Basil's server swallows the = redirect and creates a web page containing the authorization code and = sends the web page down to Gene's browser. [Note: Normally the actions = in step 3 would be performed by a human at a browser but in the attack = Basil has automated the process so his attack server can do everything = automatically.] > 4. The web page, from 'Silly Fun Times', running on Gene's = browser now completes the redirect sending Gene, using the authorization = code that Live issues in response to Basil's request, to Plaxo. > 5. Gene is already logged into Plaxo so he isn't even asked = anything before Plaxo accepts the redirect with the authorization code. > 6. Plaxo's server then uses the authorization code to get = an access token and refresh token. > 7. Plaxo uses the access token to synchronize the address = book on Basil's Live account with Gene's Plaxo server. Although Plaxo never had a request initiated from anyone (Gene, or = Basil) to sync Gene's contacts with Live? And shouldn't Plaxo ask Gene = for explicit authorization before syncing his contacts to Live, = regardless of whether he is already authenticated?=20 Regards, - John > =20 > The outcome of step 7 is two separate attacks. One attack is that = Plaxo will now push all of Gene's address book information into Basil's = Live account. So Basil has now successfully stolen all of Gene's address = book data. The other attack is that if Plaxo is doing bi-directional = synch then Basil could put false contacts (perhaps with bad URLs to = launch various types of attacks) and related information into Gene's = central address book at Plaxo. > =20 > Variations: > 1a. Basil could buy ads on search services like Bing and Google and = use those as a way to lure people to the 'Silly Fun Times' website. > 5a. Gene might not be logged into Plaxo but if 'Silly Fun Times' sets = things up right it could fool Gene into thinking he is supposed to see = Plaxo and so will handle the login. > =20 > There is an obvious variation of this attack for auth tokens rather = than auth codes. > =20 > Pretty picture > The numbers in the picture are keyed to the steps in the use case = above. > =20 > > Recommended Changes to draft-ietf-oauth-v2 > =20 > In section 4, request options (e.g. 4.1.1) featuring "state" should = change from: > =20 > state > OPTIONAL. An opaque value used by the client to maintain state between = the request and callback. The authorization server includes this value = when redirecting the user-agent back to the client. > =20 > to: > =20 > state > REQUIRED. An opaque value used by the client to maintain state between = the request and callback. The authorization server includes this value = when redirecting the user-agent back to the client. The encoded value = SHOULD enable the client application to determine the user-context that = was active at the time of the request (see section 10.12). The value = MUST NOT be guessable or predictable, and MUST be kept confidential. > =20 > Section 10.12 Cross-Site Request Forgery > =20 > Change to: > =20 > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP = requests are transmitted from the user-agent of an end-user the server = trusts or has authenticated. CSRF attacks enable the attacker to = intermix the attacker's security context with that of the resource owner = resulting in a compromise of either the resource server or of the client = application itself. In the OAuth context, such attacks allow an attacker = to inject their own authorization code or access token into a client, = which can result in the client using an access token associated with the = attacker's account rather than the victim's. Depending on the nature of = the client and the protected resources, this can have undesirable and = damaging effects. >=20 > In order to prevent such attacks, the client application MUST encode a = non-guessable, confidential end-user artifact and submit as the "state" = parameter to authorization and access token requests to the = authorization server. The client MUST keep the state value in a location = accessible only by the client or the user-agent (i.e., protected by = same-origin policy), for example, using a DOM variable, HTTP cookie, or = HTML5 client-side storage. >=20 > The authorization server includes the value of the "state" parameter = when redirecting the user-agent back to the client. Upon receiving a = redirect, the client application MUST confirm that returned value of = "state" corresponds to the state value of the user-agent's user session. = If the end-user session represents an authenticated user-identity, the = client MUST ensure that the user-identity has NOT changed. > =20 > Yaron, Torsten, Phil and Tony > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From john@jkemp.net Sun Aug 14 06:19:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E0A21F876F for ; Sun, 14 Aug 2011 06:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 857H4Y-sTJCK for ; Sun, 14 Aug 2011 06:19:00 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id F33B621F8760 for ; Sun, 14 Aug 2011 06:18:59 -0700 (PDT) Received: (qmail 5557 invoked by uid 0); 14 Aug 2011 13:19:41 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by oproxy1.bluehost.com with SMTP; 14 Aug 2011 13:19:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jkemp.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=Rriojx68VCH0YNHCOpl/wgCsYwr7hyucxHbOqJ8IzVE=; b=HKqfKa2f9jPLyALk7Lq7i7ujVdpMiZg7OcD+AkmyhZGf8clez6ClZ+j+VXbBJTrKdXAbVtbhK9WRq/b8E1HkwKM+0nlt3xqe+JuAQ4lC8dfMMW+cAPo1Qinr9BtADraI; Received: from cpe-74-67-30-101.nycap.res.rr.com ([74.67.30.101] helo=[192.168.1.108]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1QsabN-0006l2-6S; Sun, 14 Aug 2011 07:19:41 -0600 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <4DE6F907-E45B-4F70-9CE7-FF58ABE13BF6@oracle.com> Date: Sun, 14 Aug 2011 09:19:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1313295383.69882.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DE6F907-E45B-4F70-9CE7-FF58ABE13BF6@oracle.com> To: Phillip Hunt X-Mailer: Apple Mail (2.1244.3) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 74.67.30.101 authed with john+jkemp.net} Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 13:19:01 -0000 On Aug 14, 2011, at 1:55 AM, Phillip Hunt wrote: > No. I don't think so. In the new variant the client has to check the = returned state to confirm it has not changed or associated with a = different user. =20 >=20 > Previously the authz server had to do the checks.=20 In a CSRF attack, either of the two web servers (one is the OAuth = "client" in this case) may be attacked with a CSRF. The defense against = a CSRF is always for the recipient of the request to authenticate the = requester in one way or another. One way to do that is with a CSRF token = (see = https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Preventi= on_Cheat_Sheet).=20 In OAuth, I think it's fair to say that an "OAuth CSRF attack" might be = a special-case of a CSRF attack, but the typical defenses apply to both = the OAuth "client" and the OAuth "resource server". - John >=20 > Phil >=20 > On 2011-08-13, at 21:16, "William J. Mills" = wrote: >=20 >> The defense is the same though, correct? >>=20 >> From: Phil Hunt >> To: Eran Hammer-Lahav >> Cc: "OAuth WG (oauth@ietf.org)" >> Sent: Saturday, August 13, 2011 4:41 PM >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>=20 >> There are two CSRF variations scenarios that I see. >>=20 >> I can attack you and give my client access to your resources = (original attack on the "resource"). >>=20 >> I can attack you and give your client access to my resource (new = attack on the "client"). >>=20 >> Attack on the client vs. attack on the resource may be misleading = here. Draft 20 only referred to attacks on the "resource" in its = original CSRF description. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2011-08-13, at 7:30 AM, Eran Hammer-Lahav wrote: >>=20 >>> All OAuth CSRF attacks are on the client. >>>=20 >>> EHL >>>=20 >>> From: Phil Hunt >>> Date: Sat, 13 Aug 2011 00:21:50 -0700 >>> To: Torsten Lodderstedt >>> Cc: Eran Hammer-lahav , "OAuth WG = (oauth@ietf.org)" >>> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>>=20 >>>> +1 (to putting more detail in the Threat Model document) >>>>=20 >>>> Yes, this is another CSRF attack (hence the change to 10.2).=20 >>>>=20 >>>> What is *new* is this is an attack on the client application rather = than the resource server. As such, I agree this new attack vector is = well deserving of wider review and discussion before finalizing the = draft. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2011-08-12, at 11:58 PM, Torsten Lodderstedt wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: >>>>>> This is really just a flavor of CSRF attacks. I have no = objections to better documenting it (though I feel the current text is = already sufficient), but we can't realistically expect to identify and = close every possible browser-based attack. A new one is invented every = other week. >>>>>>=20 >>>>>> The problem with this text is that developers who do no = understand CSRF attacks are not likely to implement it correctly with = this information. Those who understand it do not need the extra verbiage = which is more confusing than helpful. >>>>>=20 >>>>> We are constantly facing the fact that a comprehensive description = of security threats needs more space than we have in the core draft. = That's the reason why the security document has 63 pages and that's also = the reason why we decided to let the core spec refer to this document = for in-depth explanations. This holds true for this threat as well. >>>>>=20 >>>>> regards, >>>>> Torsten.=20 >>>>>=20 >>>>>>=20 >>>>>> As for the new requirements, they are insufficient to actually = accomplish what the authors propose without additional requirements on = state local storage and verification to complete the flow. Also, the = proposed text needs clarifications as noted below. >>>>>>=20 >>>>>>=20 >>>>>> From: Anthony Nadalin >>>>>> Date: Fri, 12 Aug 2011 12:06:36 -0700 >>>>>> To: "OAuth WG (oauth@ietf.org)" >>>>>> Subject: [OAUTH-WG] Auth Code Swap Attack >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> Recommended Changes to draft-ietf-oauth-v2 >>>>>>> =20 >>>>>>> In section 4, request options (e.g. 4.1.1) featuring "state" = should change from: >>>>>>> =20 >>>>>>> state >>>>>>> OPTIONAL. An opaque value used by the client to maintain state = between the request and callback. The authorization server includes this = value when redirecting the user-agent back to the client. >>>>>>> =20 >>>>>>> to: >>>>>>> =20 >>>>>>> state >>>>>>> REQUIRED. An opaque value used by the client to maintain state = between the request and callback. The authorization server includes this = value when redirecting the user-agent back to the client. The encoded = value SHOULD enable the client application to determine the user-context = that was active at the time of the request (see section 10.12). The = value MUST NOT be guessable or predictable, and MUST be kept = confidential. >>>>>>> =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Aug 14 06:30:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4390F21F87D3 for ; Sun, 14 Aug 2011 06:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdCxM6NDXY3u for ; Sun, 14 Aug 2011 06:30:19 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id F0A5821F87C2 for ; Sun, 14 Aug 2011 06:30:18 -0700 (PDT) Received: (qmail 5875 invoked from network); 14 Aug 2011 13:31:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Aug 2011 13:31:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 14 Aug 2011 06:31:00 -0700 From: Eran Hammer-Lahav To: Phillip Hunt Date: Sun, 14 Aug 2011 06:30:40 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxahmgKd0Cu2rpDQea13tQwoVJjrQ== Message-ID: <0DB326FF-DBE4-46B3-B593-09FAF49E2DC6@hueniverse.com> References: <1313295383.69882.YahooMailNeo@web31808.mail.mud.yahoo.com> <4DE6F907-E45B-4F70-9CE7-FF58ABE13BF6@oracle.com> In-Reply-To: <4DE6F907-E45B-4F70-9CE7-FF58ABE13BF6@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0DB326FFDBE446B3B59309FAF49E2DC6hueniversecom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 13:30:20 -0000 --_000_0DB326FFDBE446B3B59309FAF49E2DC6hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHRydWUuIEl0IGlzIHRoZSBzYW1lLg0KDQpFSEwNCg0KT24gQXVnIDE0LCAyMDExLCBhdCAx OjU1LCAiUGhpbGxpcCBIdW50IiA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCk5vLiBJIGRvbid0IHRoaW5rIHNvLiBJbiB0aGUgbmV3 IHZhcmlhbnQgdGhlIGNsaWVudCBoYXMgdG8gY2hlY2sgdGhlIHJldHVybmVkIHN0YXRlIHRvIGNv bmZpcm0gaXQgaGFzIG5vdCBjaGFuZ2VkIG9yIGFzc29jaWF0ZWQgd2l0aCBhIGRpZmZlcmVudCB1 c2VyLg0KDQpQcmV2aW91c2x5IHRoZSBhdXRoeiBzZXJ2ZXIgaGFkIHRvIGRvIHRoZSBjaGVja3Mu DQoNClBoaWwNCg0KT24gMjAxMS0wOC0xMywgYXQgMjE6MTYsICJXaWxsaWFtIEouIE1pbGxzIiA8 PG1haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbT53bWlsbHNAeWFob28taW5jLmNvbTxtYWlsdG86 d21pbGxzQHlhaG9vLWluYy5jb20+PiB3cm90ZToNCg0KVGhlIGRlZmVuc2UgaXMgdGhlIHNhbWUg dGhvdWdoLCBjb3JyZWN0Pw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv bTogUGhpbCBIdW50IDw8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPnBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpUbzogRXJhbiBIYW1tZXItTGFo YXYgPDxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT5lcmFuQGh1ZW5pdmVyc2UuY29tPG1haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4NCkNjOiAiT0F1dGggV0cgKDxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikiIDw8bWFpbHRvOm9h dXRoQGlldGYub3JnPm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpTZW50 OiBTYXR1cmRheSwgQXVndXN0IDEzLCAyMDExIDQ6NDEgUE0NClN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIEF1dGggQ29kZSBTd2FwIEF0dGFjaw0KDQpUaGVyZSBhcmUgdHdvIENTUkYgdmFyaWF0aW9u cyBzY2VuYXJpb3MgdGhhdCBJIHNlZS4NCg0KSSBjYW4gYXR0YWNrIHlvdSBhbmQgZ2l2ZSBteSBj bGllbnQgYWNjZXNzIHRvIHlvdXIgcmVzb3VyY2VzIChvcmlnaW5hbCBhdHRhY2sgb24gdGhlICJy ZXNvdXJjZSIpLg0KDQpJIGNhbiBhdHRhY2sgeW91IGFuZCBnaXZlIHlvdXIgY2xpZW50IGFjY2Vz cyB0byBteSByZXNvdXJjZSAobmV3IGF0dGFjayBvbiB0aGUgImNsaWVudCIpLg0KDQpBdHRhY2sg b24gdGhlIGNsaWVudCB2cy4gYXR0YWNrIG9uIHRoZSByZXNvdXJjZSBtYXkgYmUgbWlzbGVhZGlu ZyBoZXJlLiAgRHJhZnQgMjAgb25seSByZWZlcnJlZCB0byBhdHRhY2tzIG9uIHRoZSAicmVzb3Vy Y2UiIGluIGl0cyBvcmlnaW5hbCBDU1JGIGRlc2NyaXB0aW9uLg0KDQpQaGlsDQoNCkBpbmRlcGVu ZGVudGlkDQo8aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT48aHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbT53d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlk LmNvbT4NCjxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PG1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbT5waGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+ DQoNCg0KDQoNCg0KT24gMjAxMS0wOC0xMywgYXQgNzozMCBBTSwgRXJhbiBIYW1tZXItTGFoYXYg d3JvdGU6DQoNCkFsbCBPQXV0aCBDU1JGIGF0dGFja3MgYXJlIG9uIHRoZSBjbGllbnQuDQoNCkVI TA0KDQpGcm9tOiBQaGlsIEh1bnQgPDxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PG1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT5waGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20+Pg0KRGF0ZTogU2F0LCAxMyBBdWcgMjAxMSAwMDoyMTo1MCAtMDcwMA0K VG86IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+ PG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxt YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+Pg0KQ2M6IEVyYW4gSGFtbWVyLWxhaGF2IDw8 bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPmVy YW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiwgIk9BdXRoIFdH ICg8bWFpbHRvOm9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikiIDw8bWFpbHRvOm9hdXRoQGlldGYub3JnPjxt YWlsdG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3Jn Pj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEF1dGggQ29kZSBTd2FwIEF0dGFjaw0KDQorMSAo dG8gcHV0dGluZyBtb3JlIGRldGFpbCBpbiB0aGUgVGhyZWF0IE1vZGVsIGRvY3VtZW50KQ0KDQpZ ZXMsIHRoaXMgaXMgYW5vdGhlciBDU1JGIGF0dGFjayAoaGVuY2UgdGhlIGNoYW5nZSB0byAxMC4y KS4NCg0KV2hhdCBpcyAqbmV3KiBpcyB0aGlzIGlzIGFuIGF0dGFjayBvbiB0aGUgY2xpZW50IGFw cGxpY2F0aW9uIHJhdGhlciB0aGFuIHRoZSByZXNvdXJjZSBzZXJ2ZXIuIEFzIHN1Y2gsIEkgYWdy ZWUgdGhpcyBuZXcgYXR0YWNrIHZlY3RvciBpcyB3ZWxsIGRlc2VydmluZyBvZiB3aWRlciByZXZp ZXcgYW5kIGRpc2N1c3Npb24gYmVmb3JlIGZpbmFsaXppbmcgdGhlIGRyYWZ0Lg0KDQpQaGlsDQoN CkBpbmRlcGVuZGVudGlkDQo8aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8+PGh0dHA6Ly93 d3cuaW5kZXBlbmRlbnRpZC5jb20+d3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5k ZXBlbmRlbnRpZC5jb20+DQo8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPjxtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20+cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tPg0KDQoNCg0KDQoNCk9uIDIwMTEtMDgtMTIsIGF0IDExOjU4IFBNLCBUb3JzdGVu IExvZGRlcnN0ZWR0IHdyb3RlOg0KDQoNCg0KQW0gMTIuMDguMjAxMSAyMzo1Miwgc2NocmllYiBF cmFuIEhhbW1lci1MYWhhdjoNClRoaXMgaXMgcmVhbGx5IGp1c3QgYSBmbGF2b3Igb2YgQ1NSRiBh dHRhY2tzLiBJIGhhdmUgbm8gb2JqZWN0aW9ucyB0byBiZXR0ZXIgZG9jdW1lbnRpbmcgaXQgKHRo b3VnaCBJIGZlZWwgdGhlIGN1cnJlbnQgdGV4dCBpcyBhbHJlYWR5IHN1ZmZpY2llbnQpLCBidXQg d2UgY2FuJ3QgcmVhbGlzdGljYWxseSBleHBlY3QgdG8gaWRlbnRpZnkgYW5kIGNsb3NlIGV2ZXJ5 IHBvc3NpYmxlIGJyb3dzZXItYmFzZWQgYXR0YWNrLiBBIG5ldyBvbmUgaXMgaW52ZW50ZWQgZXZl cnkgb3RoZXIgd2Vlay4NCg0KVGhlIHByb2JsZW0gd2l0aCB0aGlzIHRleHQgaXMgdGhhdCBkZXZl bG9wZXJzIHdobyBkbyBubyB1bmRlcnN0YW5kIENTUkYgYXR0YWNrcyBhcmUgbm90IGxpa2VseSB0 byBpbXBsZW1lbnQgaXQgY29ycmVjdGx5IHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gVGhvc2Ugd2hv IHVuZGVyc3RhbmQgaXQgZG8gbm90IG5lZWQgdGhlIGV4dHJhIHZlcmJpYWdlIHdoaWNoIGlzIG1v cmUgY29uZnVzaW5nIHRoYW4gaGVscGZ1bC4NCg0KV2UgYXJlIGNvbnN0YW50bHkgZmFjaW5nIHRo ZSBmYWN0IHRoYXQgYSBjb21wcmVoZW5zaXZlIGRlc2NyaXB0aW9uIG9mIHNlY3VyaXR5IHRocmVh dHMgbmVlZHMgbW9yZSBzcGFjZSB0aGFuIHdlIGhhdmUgaW4gdGhlIGNvcmUgZHJhZnQuIFRoYXQn cyB0aGUgcmVhc29uIHdoeSB0aGUgc2VjdXJpdHkgZG9jdW1lbnQgaGFzIDYzIHBhZ2VzIGFuZCB0 aGF0J3MgYWxzbyB0aGUgcmVhc29uIHdoeSB3ZSBkZWNpZGVkIHRvIGxldCB0aGUgY29yZSBzcGVj IHJlZmVyIHRvIHRoaXMgZG9jdW1lbnQgZm9yIGluLWRlcHRoIGV4cGxhbmF0aW9ucy4gVGhpcyBo b2xkcyB0cnVlIGZvciB0aGlzIHRocmVhdCBhcyB3ZWxsLg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4N Cg0KDQpBcyBmb3IgdGhlIG5ldyByZXF1aXJlbWVudHMsIHRoZXkgYXJlIGluc3VmZmljaWVudCB0 byBhY3R1YWxseSBhY2NvbXBsaXNoIHdoYXQgdGhlIGF1dGhvcnMgcHJvcG9zZSB3aXRob3V0IGFk ZGl0aW9uYWwgcmVxdWlyZW1lbnRzIG9uIHN0YXRlIGxvY2FsIHN0b3JhZ2UgYW5kIHZlcmlmaWNh dGlvbiB0byBjb21wbGV0ZSB0aGUgZmxvdy4gQWxzbywgdGhlIHByb3Bvc2VkIHRleHQgbmVlZHMg Y2xhcmlmaWNhdGlvbnMgYXMgbm90ZWQgYmVsb3cuDQoNCg0KRnJvbTogQW50aG9ueSBOYWRhbGlu IDw8bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT48bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0 LmNvbT50b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+ DQpEYXRlOiBGcmksIDEyIEF1ZyAyMDExIDEyOjA2OjM2IC0wNzAwDQpUbzogIk9BdXRoIFdHICg8 bWFpbHRvOm9hdXRoQGlldGYub3JnPjxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0Zi5v cmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPikiIDw8bWFpbHRvOm9hdXRoQGlldGYub3JnPjxtYWls dG86b2F1dGhAaWV0Zi5vcmc+b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4N ClN1YmplY3Q6IFtPQVVUSC1XR10gQXV0aCBDb2RlIFN3YXAgQXR0YWNrDQoNCg0KDQpSZWNvbW1l bmRlZCBDaGFuZ2VzIHRvIGRyYWZ0LWlldGYtb2F1dGgtdjINCg0KSW4gc2VjdGlvbiA0LCByZXF1 ZXN0IG9wdGlvbnMgKGUuZy4gNC4xLjEpIGZlYXR1cmluZyAic3RhdGUiIHNob3VsZCBjaGFuZ2Ug ZnJvbToNCg0Kc3RhdGUNCk9QVElPTkFMLiBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xp ZW50IHRvIG1haW50YWluIHN0YXRlIGJldHdlZW4gdGhlIHJlcXVlc3QgYW5kIGNhbGxiYWNrLiBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0 aW5nIHRoZSB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudC4NCg0KdG86DQoNCnN0YXRlDQpS RVFVSVJFRC4gQW4gb3BhcXVlIHZhbHVlIHVzZWQgYnkgdGhlIGNsaWVudCB0byBtYWludGFpbiBz dGF0ZSBiZXR3ZWVuIHRoZSByZXF1ZXN0IGFuZCBjYWxsYmFjay4gVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGluY2x1ZGVzIHRoaXMgdmFsdWUgd2hlbiByZWRpcmVjdGluZyB0aGUgdXNlci1hZ2Vu dCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBlbmNvZGVkIHZhbHVlIFNIT1VMRCBlbmFibGUgdGhl IGNsaWVudCBhcHBsaWNhdGlvbiB0byBkZXRlcm1pbmUgdGhlIHVzZXItY29udGV4dCB0aGF0IHdh cyBhY3RpdmUgYXQgdGhlIHRpbWUgb2YgdGhlICByZXF1ZXN0IChzZWUgc2VjdGlvbiAxMC4xMiku IFRoZSB2YWx1ZSBNVVNUIE5PVCBiZSBndWVzc2FibGUgb3IgcHJlZGljdGFibGUsIGFuZCBNVVNU IGJlIGtlcHQgY29uZmlkZW50aWFsLg0KDQo= --_000_0DB326FFDBE446B3B59309FAF49E2DC6hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5Ob3QgdHJ1ZS4gSXQgaXMgdGhlIHNh bWUuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5FSEw8YnI+PGJyPk9uIEF1ZyAxNCwg MjAxMSwgYXQgMTo1NSwgIlBoaWxsaXAgSHVudCIgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1 bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJy PjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48ZGl2Pk5vLiBJ IGRvbid0IHRoaW5rIHNvLiBJbiB0aGUgbmV3IHZhcmlhbnQgdGhlIGNsaWVudCBoYXMgdG8gY2hl Y2sgdGhlIHJldHVybmVkIHN0YXRlIHRvIGNvbmZpcm0gaXQgaGFzIG5vdCBjaGFuZ2VkIG9yIGFz c29jaWF0ZWQgd2l0aCBhIGRpZmZlcmVudCB1c2VyLiAmbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2PlByZXZpb3VzbHkgdGhlIGF1dGh6IHNlcnZlciBoYWQgdG8gZG8gdGhlIGNoZWNrcy4m bmJzcDs8YnI+PGJyPlBoaWw8L2Rpdj48ZGl2Pjxicj5PbiAyMDExLTA4LTEzLCBhdCAyMToxNiwg IldpbGxpYW0gSi4gTWlsbHMiICZsdDs8YSBocmVmPSJtYWlsdG86d21pbGxzQHlhaG9vLWluYy5j b20iPjxhIGhyZWY9Im1haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbSI+d21pbGxzQHlhaG9vLWlu Yy5jb208L2E+PC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2PjwvZGl2PjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGRpdiBzdHlsZT0iY29sb3I6IzAwMDsgYmFja2dyb3VuZC1j b2xvcjojZmZmOyBmb250LWZhbWlseTpDb3VyaWVyIE5ldywgY291cmllciwgbW9uYWNvLCBtb25v c3BhY2UsIHNhbnMtc2VyaWY7Zm9udC1zaXplOjEwcHQiPjxkaXY+PHNwYW4+VGhlIGRlZmVuc2Ug aXMgdGhlIHNhbWUgdGhvdWdoLCBjb3JyZWN0Pzxicj48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJpZXIgTmV3LCBjb3VyaWVyLCBtb25hY28s IG1vbm9zcGFjZSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMHB0OyI+PGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZjsgZm9udC1z aXplOiAxMnB0OyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiPjxociBzaXplPSIxIj48Yj48 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZDsiPkZyb206PC9zcGFuPjwvYj4gUGhpbCBIdW50 ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9hPiZndDs8 YnI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+VG86PC9zcGFuPjwvYj4gRXJh biBIYW1tZXItTGFoYXYgJmx0OzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj48 YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+ZXJhbkBodWVuaXZlcnNlLmNvbTwv YT48L2E+Jmd0Ozxicj48Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5DYzo8L3Nw YW4+PC9iPiAiT0F1dGggV0cgKDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PGEgaHJl Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48L2E+KSIgJmx0Ozxh IGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYu b3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48L2E+Jmd0Ozxicj48Yj48c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6IGJvbGQ7Ij5TZW50Ojwvc3Bhbj48L2I+IFNhdHVyZGF5LCBBdWd1c3QgMTMsIDIwMTEg NDo0MSBQTTxicj48Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7Ij5TdWJqZWN0Ojwv c3Bhbj48L2I+IFJlOiBbT0FVVEgtV0ddIEF1dGggQ29kZSBTd2FwIEF0dGFjazxicj48L2ZvbnQ+ PGJyPjxkaXYgaWQ9InlpdjExMDE1OTQyNjIiPlRoZXJlDQogYXJlIHR3byBDU1JGIHZhcmlhdGlv bnMgc2NlbmFyaW9zIHRoYXQgSSBzZWUuPGRpdj48YnI+PC9kaXY+PGRpdj5JIGNhbiBhdHRhY2sg eW91IGFuZCBnaXZlIG15IGNsaWVudCBhY2Nlc3MgdG8geW91ciByZXNvdXJjZXMgKG9yaWdpbmFs IGF0dGFjayBvbiB0aGUgInJlc291cmNlIikuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGNh biBhdHRhY2sgeW91IGFuZCBnaXZlIHlvdXIgY2xpZW50IGFjY2VzcyB0byBteSByZXNvdXJjZSAo bmV3IGF0dGFjayBvbiB0aGUgImNsaWVudCIpLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QXR0 YWNrIG9uIHRoZSBjbGllbnQgdnMuIGF0dGFjayBvbiB0aGUgcmVzb3VyY2UgbWF5IGJlIG1pc2xl YWRpbmcgaGVyZS4gJm5ic3A7RHJhZnQgMjAgb25seSByZWZlcnJlZCB0byBhdHRhY2tzIG9uIHRo ZSAicmVzb3VyY2UiIGluIGl0cyBvcmlnaW5hbCBDU1JGIGRlc2NyaXB0aW9uLjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+PGRpdj4NCjxzcGFuIGNsYXNzPSJ5aXYxMTAxNTk0MjYyQXBwbGUtc3R5 bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTpzZXBhcmF0ZTtjb2xvcjpyZ2IoMCwgMCwg MCk7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpu b3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5lLWhlaWdo dDpub3JtYWw7b3JwaGFuczoyO3RleHQtYWxpZ246YXV0bzt0ZXh0LWluZGVudDowcHg7dGV4dC10 cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d2lkb3dzOjI7d29yZC1zcGFjaW5nOjBw eDtmb250LXNpemU6bWVkaXVtOyI+PHNwYW4gY2xhc3M9InlpdjExMDE1OTQyNjJBcHBsZS1zdHls ZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOnNlcGFyYXRlO2NvbG9yOnJnYigwLCAwLCAw KTtmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOm1lZGl1bTtmb250LXN0eWxlOm5vcm1h bDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpu b3JtYWw7bGluZS1oZWlnaHQ6bm9ybWFsO29ycGhhbnM6Mjt0ZXh0LWluZGVudDowcHg7dGV4dC10 cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d2lkb3dzOjI7d29yZC1zcGFjaW5nOjBw eDsiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkOyI+PHNwYW4gY2xhc3M9InlpdjEx MDE1OTQyNjJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOnNlcGFyYXRl O2NvbG9yOnJnYigwLCAwLA0KIDApO2ZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6bWVk aXVtO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6bm9y bWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5lLWhlaWdodDpub3JtYWw7b3JwaGFuczoyO3Rl eHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3aWRv d3M6Mjt3b3JkLXNwYWNpbmc6MHB4OyI+PGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7 Ij48c3BhbiBjbGFzcz0ieWl2MTEwMTU5NDI2MkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3Jk ZXItY29sbGFwc2U6c2VwYXJhdGU7Y29sb3I6cmdiKDAsIDAsIDApO2ZvbnQtZmFtaWx5OkhlbHZl dGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFs O2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6bm9y bWFsO29ycGhhbnM6Mjt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1z cGFjZTpub3JtYWw7d2lkb3dzOjI7d29yZC1zcGFjaW5nOjBweDsiPjxkaXYgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkOyI+PGRpdj48ZGl2PjxkaXY+UGhpbDwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+QGluZGVwZW5kZW50aWQ8L2Rpdj48ZGl2PjxhIHJlbD0ibm9mb2xsb3ciIHRhcmdldD0i X2JsYW5rIiBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIj48L2E+PGEgaHJlZj0i aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjwvYT48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L3NwYW4+PGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0ibWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tIj48L2E+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj48YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwv YT48YnI+PGJyPjwvZGl2Pjwvc3Bhbj48YnIgY2xhc3M9InlpdjExMDE1OTQyNjJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj48L2Rpdj48L3NwYW4+PGJyIGNsYXNzPSJ5aXYxMTAxNTk0MjYyQXBw bGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PC9zcGFuPjxiciBjbGFzcz0ieWl2MTEwMTU5NDI2MkFw cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPC9kaXY+DQo8YnI+PGRpdj48ZGl2Pk9uIDIwMTEt MDgtMTMsIGF0IDc6MzAgQU0sIEVyYW4gSGFtbWVyLUxhaGF2IHdyb3RlOjwvZGl2PjxiciBjbGFz cz0ieWl2MTEwMTU5NDI2MkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2NvbG9yOnJnYigwLCAw LCAwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PGRp dj5BbGwgT0F1dGggQ1NSRiBhdHRhY2tzIGFyZSBvbiB0aGUgY2xpZW50LjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+RUhMPC9kaXY+PGRpdj48YnI+PC9kaXY+PHNwYW4gaWQ9InlpdjExMDE1OTQy NjJPTEtfU1JDX0JPRFlfU0VDVElPTiI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtm b250LXNpemU6MTFwdDt0ZXh0LWFsaWduOmxlZnQ7Y29sb3I6YmxhY2s7Qk9SREVSLUJPVFRPTTpt ZWRpdW0gbm9uZTtCT1JERVItTEVGVDptZWRpdW0gbm9uZTtQQURESU5HLUJPVFRPTTowaW47UEFE RElORy1MRUZUOjBpbjtQQURESU5HLVJJR0hUOjBpbjtCT1JERVItVE9QOiNiNWM0ZGYgMXB0IHNv bGlkO0JPUkRFUi1SSUdIVDptZWRpdW0gbm9uZTtQQURESU5HLVRPUDozcHQ7Ij48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZDsiPkZyb206IDwvc3Bhbj4gUGhpbCBIdW50ICZsdDs8YSByZWw9 Im5vZm9sbG93IiB5bWFpbHRvPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0i X2JsYW5rIiBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjwvYT48YSBocmVmPSJt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9hPiZndDs8YnI+PHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQ7Ij5EYXRlOiA8L3NwYW4+IFNhdCwgMTMgQXVnIDIwMTEgMDA6MjE6 NTAgLTA3MDA8YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQ7Ij5UbzogPC9zcGFuPg0K IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIHJlbD0ibm9mb2xsb3ciIHltYWlsdG89Im1haWx0 bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzp0 b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+PC9hPjxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldCI+PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij50b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT48L2E+Jmd0Ozxicj48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZDsiPkNjOiA8L3NwYW4+IEVyYW4gSGFtbWVyLWxhaGF2ICZsdDs8YSByZWw9Im5vZm9s bG93IiB5bWFpbHRvPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj48L2E+PGEgaHJlZj0ibWFpbHRvOmVy YW5AaHVlbml2ZXJzZS5jb20iPjxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5l cmFuQGh1ZW5pdmVyc2UuY29tPC9hPjwvYT4mZ3Q7LCAiT0F1dGggV0cgKDxhIHJlbD0ibm9mb2xs b3ciIHltYWlsdG89Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PC9hPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9y ZyI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48L2E+ KSIgJmx0OzxhIHJlbD0ibm9mb2xsb3ciIHltYWlsdG89Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PC9hPjxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5v YXV0aEBpZXRmLm9yZzwvYT48L2E+Jmd0Ozxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZDsiPlN1YmplY3Q6IDwvc3Bhbj4gUmU6IFtPQVVUSC1XR10gQXV0aCBDb2RlIFN3YXAgQXR0YWNr PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIGlkPSJ5aXYxMTAxNTk0MjYyTUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiNiNWM0 ZGYgNSBzb2xpZDtQQURESU5HOjAgMCAwIDU7TUFSR0lOOjAgMCAwIDU7IiB0eXBlPSJjaXRlIj48 ZGl2PjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkOyI+KzEgKHRvIHB1dHRpbmcgbW9y ZSBkZXRhaWwgaW4gdGhlIFRocmVhdCBNb2RlbA0KIGRvY3VtZW50KTxkaXY+PGJyPjwvZGl2Pjxk aXY+WWVzLCB0aGlzIGlzIGFub3RoZXIgQ1NSRiBhdHRhY2sgKGhlbmNlIHRoZSBjaGFuZ2UgdG8g MTAuMikuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5XaGF0IGlzICpuZXcqIGlzIHRo aXMgaXMgYW4gYXR0YWNrIG9uIHRoZSA8Yj5jbGllbnQ8L2I+IGFwcGxpY2F0aW9uIHJhdGhlciB0 aGFuIHRoZSByZXNvdXJjZSBzZXJ2ZXIuIEFzIHN1Y2gsIEkgYWdyZWUgdGhpcyBuZXcgYXR0YWNr IHZlY3RvciBpcyB3ZWxsIGRlc2VydmluZyBvZiB3aWRlciByZXZpZXcgYW5kIGRpc2N1c3Npb24g YmVmb3JlIGZpbmFsaXppbmcgdGhlIGRyYWZ0LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PHNw YW4gY2xhc3M9InlpdjExMDE1OTQyNjJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXpl OjEycHg7Ij5QaGlsPC9zcGFuPjwvZGl2PjxkaXY+PGRpdj48c3BhbiBjbGFzcz0ieWl2MTEwMTU5 NDI2MkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6c2VwYXJhdGU7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudDpub3JtYWw7 Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5lLWhlaWdodDpub3Jt YWw7b3JwaGFuczoyO3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNw YWNlOm5vcm1hbDt3aWRvd3M6Mjt3b3JkLXNwYWNpbmc6MHB4O2ZvbnQtc2l6ZTptZWRpdW07Ij48 c3BhbiBjbGFzcz0ieWl2MTEwMTU5NDI2MkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXIt Y29sbGFwc2U6c2VwYXJhdGU7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZTptZWRpdW07 Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7 bGV0dGVyLXNwYWNpbmc6bm9ybWFsO2xpbmUtaGVpZ2h0Om5vcm1hbDtvcnBoYW5zOjI7dGV4dC1p bmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dpZG93czoy O3dvcmQtc3BhY2luZzowcHg7Ij48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDsiPjxz cGFuIGNsYXNzPSJ5aXYxMTAxNTk0MjYyQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImJvcmRlci1j b2xsYXBzZTpzZXBhcmF0ZTtmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOm1lZGl1bTtm b250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDts ZXR0ZXItc3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6bm9ybWFsO29ycGhhbnM6Mjt0ZXh0LWlu ZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d2lkb3dzOjI7 d29yZC1zcGFjaW5nOjBweDsiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkOyI+PHNw YW4gY2xhc3M9InlpdjExMDE1OTQyNjJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNv bGxhcHNlOnNlcGFyYXRlO2ZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250 LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0 ZXItc3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6bm9ybWFsO29ycGhhbnM6Mjt0ZXh0LWluZGVu dDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d2lkb3dzOjI7d29y ZC1zcGFjaW5nOjBweDsiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkOyI+PGRpdj48 ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QGluZGVwZW5kZW50aWQ8L2Rpdj48ZGl2PjxhIHJlbD0i bm9mb2xsb3ciIHRhcmdldD0iX2JsYW5rIiBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQu Y29tLyI+PC9hPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPjxhIGhyZWY9 Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48 L2E+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFuPjxhIHJlbD0ibm9mb2xsb3ciIHltYWls dG89Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+PC9hPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvYT48L2E+PGJyPjxicj48L2Rpdj48L3NwYW4+PGJyIGNsYXNzPSJ5aXYx MTAxNTk0MjYyQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PC9kaXY+PC9zcGFuPjxiciBjbGFz cz0ieWl2MTEwMTU5NDI2MkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjwvc3Bhbj48YnIgY2xh c3M9InlpdjExMDE1OTQyNjJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48L2Rpdj48YnI+PGRp dj48ZGl2Pk9uIDIwMTEtMDgtMTIsIGF0IDExOjU4IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0IHdy b3RlOjwvZGl2PjxiciBjbGFzcz0ieWl2MTEwMTU5NDI2MkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICANCiAgICANCiAgDQogIDxkaXY+DQogICAg PGJyPg0KICAgIDxicj4NCiAgICBBbSAxMi4wOC4yMDExIDIzOjUyLCBzY2hyaWViIEVyYW4gSGFt bWVyLUxhaGF2Og0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgPGRpdj5UaGlz IGlzIHJlYWxseSBqdXN0IGEgZmxhdm9yIG9mIENTUkYgYXR0YWNrcy4gSSBoYXZlIG5vDQogICAg ICAgIG9iamVjdGlvbnMgdG8gYmV0dGVyIGRvY3VtZW50aW5nIGl0ICh0aG91Z2ggSSBmZWVsIHRo ZSBjdXJyZW50DQogICAgICAgIHRleHQgaXMgYWxyZWFkeSBzdWZmaWNpZW50KSwgYnV0IHdlIGNh bid0IHJlYWxpc3RpY2FsbHkgZXhwZWN0DQogICAgICAgIHRvIGlkZW50aWZ5IGFuZCBjbG9zZSBl dmVyeSBwb3NzaWJsZSBicm93c2VyLWJhc2VkIGF0dGFjay4gQSBuZXcNCiAgICAgICAgb25lIGlz IGludmVudGVkIGV2ZXJ5IG90aGVyIHdlZWsuPC9kaXY+DQogICAgICA8ZGl2Pjxicj4NCiAgICAg IDwvZGl2Pg0KICAgICAgPGRpdj5UaGUgcHJvYmxlbSB3aXRoIHRoaXMgdGV4dCBpcyB0aGF0IGRl dmVsb3BlcnMgd2hvIGRvIG5vDQogICAgICAgIHVuZGVyc3RhbmQgQ1NSRiBhdHRhY2tzIGFyZSBu b3QgbGlrZWx5IHRvIGltcGxlbWVudCBpdCBjb3JyZWN0bHkNCiAgICAgICAgd2l0aCB0aGlzIGlu Zm9ybWF0aW9uLiBUaG9zZSB3aG8gdW5kZXJzdGFuZCBpdCBkbyBub3QgbmVlZCB0aGUNCiAgICAg ICAgZXh0cmEgdmVyYmlhZ2Ugd2hpY2ggaXMgbW9yZSBjb25mdXNpbmcgdGhhbiBoZWxwZnVsLjwv ZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQogICAgV2UgYXJlIGNvbnN0YW50bHkg ZmFjaW5nIHRoZSBmYWN0IHRoYXQgYSBjb21wcmVoZW5zaXZlIGRlc2NyaXB0aW9uDQogICAgb2Yg c2VjdXJpdHkgdGhyZWF0cyBuZWVkcyBtb3JlIHNwYWNlIHRoYW4gd2UgaGF2ZSBpbiB0aGUgY29y ZSBkcmFmdC4NCiAgICBUaGF0J3MgdGhlIHJlYXNvbiB3aHkgdGhlIHNlY3VyaXR5IGRvY3VtZW50 IGhhcyA2MyBwYWdlcyBhbmQgdGhhdCdzDQogICAgYWxzbyB0aGUgcmVhc29uIHdoeSB3ZSBkZWNp ZGVkIHRvIGxldCB0aGUgY29yZSBzcGVjIHJlZmVyIHRvIHRoaXMNCiAgICBkb2N1bWVudCBmb3Ig aW4tZGVwdGggZXhwbGFuYXRpb25zLiBUaGlzIGhvbGRzIHRydWUgZm9yIHRoaXMgdGhyZWF0DQog ICAgYXMgd2VsbC48YnI+DQogICAgPGJyPg0KICAgIHJlZ2FyZHMsPGJyPg0KICAgIFRvcnN0ZW4u IDxicj4NCiAgICA8YnI+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICA8ZGl2 Pjxicj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj5BcyBmb3IgdGhlIG5ldyByZXF1aXJlbWVu dHMsIHRoZXkgYXJlIGluc3VmZmljaWVudCB0bw0KICAgICAgICBhY3R1YWxseSBhY2NvbXBsaXNo IHdoYXQgdGhlIGF1dGhvcnMgcHJvcG9zZSB3aXRob3V0IGFkZGl0aW9uYWwNCiAgICAgICAgcmVx dWlyZW1lbnRzIG9uIHN0YXRlIGxvY2FsIHN0b3JhZ2UgYW5kIHZlcmlmaWNhdGlvbiB0byBjb21w bGV0ZQ0KICAgICAgICB0aGUgZmxvdy4gQWxzbywgdGhlIHByb3Bvc2VkIHRleHQgbmVlZHMgY2xh cmlmaWNhdGlvbnMgYXMgbm90ZWQNCiAgICAgICAgYmVsb3cuPC9kaXY+DQogICAgICA8ZGl2Pjxi cj4NCiAgICAgIDwvZGl2Pg0KICAgICAgPGRpdj48YnI+DQogICAgICA8L2Rpdj4NCiAgICAgIDxz cGFuIGlkPSJ5aXYxMTAxNTk0MjYyT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KICAgICAgICA8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxMXB0O3RleHQtYWxpZ246bGVm dDtjb2xvcjpibGFjaztCT1JERVItQk9UVE9NOm1lZGl1bSBub25lO0JPUkRFUi1MRUZUOm1lZGl1 bSBub25lO1BBRERJTkctQk9UVE9NOjBpbjsNClBBRERJTkctTEVGVDowaW47UEFERElORy1SSUdI VDowaW47Qk9SREVSLVRPUDojYjVjNGRmIDFwdCBzb2xpZDtCT1JERVItUklHSFQ6bWVkaXVtIG5v bmU7UEFERElORy1UT1A6M3B0OyI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQ7Ij5Gcm9t OiA8L3NwYW4+IEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0i bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Im1haWx0 bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPjwvYT48YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNy b3NvZnQuY29tIj48YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFk QG1pY3Jvc29mdC5jb208L2E+PC9hPiZndDs8YnI+DQogICAgICAgICAgPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQ7Ij5EYXRlOiA8L3NwYW4+IEZyaSwgMTIgQXVnIDIwMTENCiAgICAgICAg ICAxMjowNjozNiAtMDcwMDxicj4NCiAgICAgICAgICA8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZDsiPlRvOiA8L3NwYW4+ICJPQXV0aCBXRyAoPGEgcmVsPSJub2ZvbGxvdyIgeW1haWx0bz0i bWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOm9hdXRo QGlldGYub3JnIj48L2E+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj48YSBocmVmPSJt YWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjwvYT4pIg0KICAgICAgICAg ICZsdDs8YSByZWw9Im5vZm9sbG93IiB5bWFpbHRvPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIiBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjwvYT48YSBocmVmPSJt YWlsdG86b2F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1 dGhAaWV0Zi5vcmc8L2E+PC9hPiZndDs8YnI+DQogICAgICAgICAgPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQ7Ij5TdWJqZWN0OiA8L3NwYW4+IFtPQVVUSC1XR10NCiAgICAgICAgICBBdXRo IENvZGUgU3dhcCBBdHRhY2s8YnI+DQogICAgICAgIDwvZGl2Pg0KICAgICAgICA8ZGl2Pjxicj4N CiAgICAgICAgPC9kaXY+DQogICAgICAgIDxibG9ja3F1b3RlIGlkPSJ5aXYxMTAxNTk0MjYyTUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiNiNWM0 ZGYgNSBzb2xpZDtQQURESU5HOjAgMCAwIDU7TUFSR0lOOjAgMCAwIDU7IiB0eXBlPSJjaXRlIj4N CiAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgPHN0eWxlPjwhLS0NCiN5aXYxMTAxNTk0MjYy ICANCiBfZmlsdGVyZWQgI3lpdjExMDE1OTQyNjIge2ZvbnQtZmFtaWx5OkhlbHZldGljYTtwYW5v c2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQogX2ZpbHRlcmVkICN5aXYxMTAxNTk0MjYyIHtm b250LWZhbWlseTpDb3VyaWVyO3Bhbm9zZS0xOjIgNyA0IDkgMiAyIDUgMiA0IDQ7fQ0KIF9maWx0 ZXJlZCAjeWl2MTEwMTU5NDI2MiB7Zm9udC1mYW1pbHk6Q291cmllcjtwYW5vc2UtMToyIDcgNCA5 IDIgMiA1IDIgNCA0O30NCiBfZmlsdGVyZWQgI3lpdjExMDE1OTQyNjIge2ZvbnQtZmFtaWx5OkNh bGlicmk7cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KIF9maWx0ZXJlZCAjeWl2MTEw MTU5NDI2MiB7Zm9udC1mYW1pbHk6VGFob21hO3Bhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCiN5aXYxMTAxNTk0MjYyICANCiN5aXYxMTAxNTk0MjYyIHAueWl2MTEwMTU5NDI2Mk1zb05v cm1hbCwgI3lpdjExMDE1OTQyNjIgbGkueWl2MTEwMTU5NDI2Mk1zb05vcm1hbCwgI3lpdjExMDE1 OTQyNjIgZGl2LnlpdjExMDE1OTQyNjJNc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQ7Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToic2Fucy1zZXJpZiI7fQ0K I3lpdjExMDE1OTQyNjIgYTpsaW5rLCAjeWl2MTEwMTU5NDI2MiBzcGFuLnlpdjExMDE1OTQyNjJN c29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTt0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCiN5 aXYxMTAxNTk0MjYyIGE6dmlzaXRlZCwgI3lpdjExMDE1OTQyNjIgc3Bhbi55aXYxMTAxNTk0MjYy TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlO3RleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KI3lpdjExMDE1OTQyNjIgcC55aXYxMTAxNTk0MjYyTXNvQWNldGF0ZSwgI3lpdjEx MDE1OTQyNjIgbGkueWl2MTEwMTU5NDI2Mk1zb0FjZXRhdGUsICN5aXYxMTAxNTk0MjYyIGRpdi55 aXYxMTAxNTk0MjYyTXNvQWNldGF0ZQ0KCXttYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dDtmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6InNhbnMtc2VyaWYiO30NCiN5aXYxMTAxNTk0 MjYyIHNwYW4ueWl2MTEwMTU5NDI2MkVtYWlsU3R5bGUxNw0KCXtmb250LWZhbWlseToic2Fucy1z ZXJpZiI7Y29sb3I6d2luZG93dGV4dDt9DQojeWl2MTEwMTU5NDI2MiBzcGFuLnlpdjExMDE1OTQy NjJhcHBsZS1zdHlsZS1zcGFuDQoJe30NCiN5aXYxMTAxNTk0MjYyIHNwYW4ueWl2MTEwMTU5NDI2 MkJhbGxvb25UZXh0Q2hhcg0KCXtmb250LWZhbWlseToic2Fucy1zZXJpZiI7fQ0KI3lpdjExMDE1 OTQyNjIgLnlpdjExMDE1OTQyNjJNc29DaHBEZWZhdWx0DQoJe2ZvbnQtZmFtaWx5OiJzYW5zLXNl cmlmIjt9DQogX2ZpbHRlcmVkICN5aXYxMTAxNTk0MjYyIHttYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KI3lpdjExMDE1OTQyNjIgZGl2LnlpdjExMDE1OTQyNjJXb3JkU2VjdGlvbjEN Cgl7fQ0KLS0+PC9zdHlsZT48L2Rpdj4NCiAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgPC9z cGFuPg0KICAgICAgPGRpdj48YnI+DQogICAgICA8L2Rpdj4NCiAgICAgIDxkaXY+PGJyPg0KICAg ICAgPC9kaXY+DQogICAgICA8c3BhbiBpZD0ieWl2MTEwMTU5NDI2Mk9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCiAgICAgICAgPGJsb2NrcXVvdGUgaWQ9InlpdjExMDE1OTQyNjJNQUNfT1VUTE9PS19B VFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6I2I1YzRkZiA1IHNvbGlk O1BBRERJTkc6MCAwIDAgNTtNQVJHSU46MCAwIDAgNTsiIHR5cGU9ImNpdGUiPg0KICAgICAgICAg IDxkaXY+DQogICAgICAgICAgICA8ZGl2IGxhbmc9IkVOLVVTIj4NCiAgICAgICAgICAgICAgPGRp diBjbGFzcz0ieWl2MTEwMTU5NDI2MldvcmRTZWN0aW9uMSI+PGRpdiBjbGFzcz0ieWl2MTEwMTU5 NDI2Mk1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5cHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyI+UmVjb21tZW5kZWQNCiAgICAgICAgICAgICAgICAgICAg ICBDaGFuZ2VzIHRvIGRyYWZ0LWlldGYtb2F1dGgtdjI8L3NwYW4+PC9iPjwvZGl2PjxkaXYgY2xh c3M9InlpdjExMDE1OTQyNjJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6Q291cmllcjsiPiAmbmJzcDs8L3NwYW4+PC9kaXY+PGRpdiBjbGFzcz0ieWl2 MTEwMTU5NDI2Mk1zb05vcm1hbCI+PHNwYW4gY2xhc3M9InlpdjExMDE1OTQyNjJhcHBsZS1zdHls ZS1zcGFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDtmb250LWZhbWlseTpIZWx2ZXRpY2Es IHNhbnMtc2VyaWY7Ij5JbiBzZWN0aW9uIDQsIHJlcXVlc3Qgb3B0aW9ucyAoZS5nLg0KICAgICAg ICAgICAgICAgICAgICAgIDQuMS4xKSBmZWF0dXJpbmcgInN0YXRlIiBzaG91bGQgY2hhbmdlIGZy b206PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OkNvdXJpZXI7Ij48L3NwYW4+PC9kaXY+PGRpdiBjbGFzcz0ieWl2MTEwMTU5NDI2Mk1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb3VyaWVyOyI+ICZu YnNwOzwvc3Bhbj48L2Rpdj48ZGl2IGNsYXNzPSJ5aXYxMTAxNTk0MjYyTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Ij5zdGF0ZTwvc3Bh bj48L2Rpdj48ZGl2IGNsYXNzPSJ5aXYxMTAxNTk0MjYyTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Ij5PUFRJT05BTC4NCiAgICAgICAg ICAgICAgICAgICAgQW4gb3BhcXVlIHZhbHVlIHVzZWQgYnkgdGhlIGNsaWVudCB0byBtYWludGFp biBzdGF0ZQ0KICAgICAgICAgICAgICAgICAgICBiZXR3ZWVuIHRoZSByZXF1ZXN0IGFuZCBjYWxs YmFjay4gVGhlIGF1dGhvcml6YXRpb24NCiAgICAgICAgICAgICAgICAgICAgc2VydmVyIGluY2x1 ZGVzIHRoaXMgdmFsdWUgd2hlbiByZWRpcmVjdGluZyB0aGUNCiAgICAgICAgICAgICAgICAgICAg dXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuPC9zcGFuPjwvZGl2PjxkaXYgY2xhc3M9Inlp djExMDE1OTQyNjJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6Q291cmllcjsiPiAmbmJzcDs8L3NwYW4+PC9kaXY+PGRpdiBjbGFzcz0ieWl2MTEwMTU5 NDI2Mk1zb05vcm1hbCI+PHNwYW4gY2xhc3M9InlpdjExMDE1OTQyNjJhcHBsZS1zdHlsZS1zcGFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjlwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EsIHNhbnMt c2VyaWY7Ij50bzo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6Q291cmllcjsiPjwvc3Bhbj48L2Rpdj48ZGl2IGNsYXNzPSJ5aXYxMTAxNTk0MjYy TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvdXJp ZXI7Ij4gJm5ic3A7PC9zcGFuPjwvZGl2PjxkaXYgY2xhc3M9InlpdjExMDE1OTQyNjJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjsiPnN0 YXRlPC9zcGFuPjwvZGl2PjxkaXYgY2xhc3M9InlpdjExMDE1OTQyNjJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q291cmllcjsiPlJFUVVJUkVELg0K ICAgICAgICAgICAgICAgICAgICBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xpZW50IHRv IG1haW50YWluIHN0YXRlDQogICAgICAgICAgICAgICAgICAgIGJldHdlZW4gdGhlIHJlcXVlc3Qg YW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlvbg0KICAgICAgICAgICAgICAgICAgICBzZXJ2 ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZQ0KICAgICAgICAgICAg ICAgICAgICB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudC4gVGhlIGVuY29kZWQgdmFsdWUN CiAgICAgICAgICAgICAgICAgICAgU0hPVUxEIGVuYWJsZSB0aGUgY2xpZW50IGFwcGxpY2F0aW9u IHRvIGRldGVybWluZQ0KICAgICAgICAgICAgICAgICAgICB0aGUgdXNlci1jb250ZXh0IHRoYXQg d2FzIGFjdGl2ZSBhdCB0aGUgdGltZSBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgJm5ic3A7 cmVxdWVzdCAoc2VlIHNlY3Rpb24gMTAuMTIpLiBUaGUgdmFsdWUgTVVTVCBOT1QgYmUNCiAgICAg ICAgICAgICAgICAgICAgZ3Vlc3NhYmxlIG9yIHByZWRpY3RhYmxlLCBhbmQgTVVTVCBiZSBrZXB0 DQogICAgICAgICAgICAgICAgICAgIGNvbmZpZGVudGlhbC48L3NwYW4+PC9kaXY+PGRpdiBjbGFz cz0ieWl2MTEwMTU5NDI2Mk1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpDb3VyaWVyOyI+ICZuYnNwOzwvc3Bhbj48L2Rpdj4gDQogICAgICAgICAgICAg IDwvZGl2Pg0KICAgICAgICAgICAgPC9kaXY+DQo8L2Rpdj48L2Jsb2NrcXVvdGU+PC9zcGFuPjwv YmxvY2txdW90ZT48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9i bG9ja3F1b3RlPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYmxvY2txdW90ZT48L2Jv ZHk+PC9odG1sPg== --_000_0DB326FFDBE446B3B59309FAF49E2DC6hueniversecom_-- From eran@hueniverse.com Sun Aug 14 23:10:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EDC21F8B1D for ; Sun, 14 Aug 2011 23:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfo0DAEvvJzH for ; Sun, 14 Aug 2011 23:09:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 0A56521F8B1E for ; Sun, 14 Aug 2011 23:09:25 -0700 (PDT) Received: (qmail 15279 invoked from network); 15 Aug 2011 06:10:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:10:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 14 Aug 2011 23:10:09 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Sun, 14 Aug 2011 23:08:57 -0700 Thread-Topic: [OAUTH-WG] redirect uri validation Thread-Index: AcxK8ixmC0aAySH5S26xwHZeEopeLwQH5tlw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345021F37877@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DAAEA.7090304@lodderstedt.net> In-Reply-To: <4E2DAAEA.7090304@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "torsten@lodderstedt-online.de" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] redirect uri validation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 06:10:07 -0000 V2hlcmUgd291bGQgeW91IHN1Z2dlc3QgSSBhZGQgdGhpcz8NCg0KRUhMDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVG9yc3RlbiBMb2RkZXJzdGVkdCBbbWFpbHRvOnRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0XQ0KPiBTZW50OiBNb25kYXksIEp1bHkgMjUsIDIwMTEgMTA6 NDIgQU0NCj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2DQo+IENjOiB0b3JzdGVuQGxvZGRlcnN0ZWR0 LW9ubGluZS5kZTsgb2F1dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gcmVk aXJlY3QgdXJpIHZhbGlkYXRpb24NCj4gDQo+IEhpIEVyYW4sDQo+IA0KPiA+Pj4gT0F1dGggMS4w IHdhcyBoaWdobHkgY3JpdGljaXplZCBmb3IgZmFpbGluZyB0byBhZGRyZXNzIGNsaWVudA0KPiA+ Pj4gaWRlbnRpdHkgaW4gcHVibGljIGNsaWVudHMuIEkgYmVsaWV2ZSBPQXV0aCAyLjAgb2ZmZXJz IGEgbXVjaCBiZXR0ZXINCj4gPj4+IHN0b3J5LCB3aXRoaW4gdGhlIGJvdW5kYXJpZXM+b2Ygd2hh dOKAmXMgcG9zc2libGUgdG9kYXkuDQo+ID4+IEFncmVlZC4gSSB0aGluayB3ZSBtdXN0IGhvbmVz dGx5IGRpc2N1c3MgdGhlIHZhbHVlIG9mIGNsaWVudA0KPiA+PiBhdXRoZW50aWNhdGlvbi9pZGVu dGlmaWNhdGlvbiBpdHNlbGYuIEkgcGVyc29uYWxseSB0aGluayBpdCBpcw0KPiA+PiBvdmVyLWVt cGhhemlzZWQgcmlnaHQgbm93LiBUaGUgc3RyZW5ndGggb2YgT0F1dGggMi4wIGlzIHRoYXQgaXQN Cj4gPj4gYWxsb3dzIHNvbHV0aW9ucyB3aGVyZSBuZWl0aGVyIGNsaWVudCBub3IgcmVzb3VyY2Ug c2VydmVyIGhhdmUgYWNjZXNzIG9yDQo+IGRvIHN0b3JlIGVuZC11c2VyIGNyZWRlbnRpYWxzLg0K PiA+PiBDbGllbnQgYXV0aGVudGljYXRpb24gaXMgbmljZSBidXQgbm90IHRoZSBtYWluIGZlYXR1 cmUuDQo+ID4gRG8geW91IGhhdmUgYW55IHNwZWNpZmljIHN1Z2dlc3Rpb25zIG5vdCBhbHJlYWR5 IG1lbnRpb25lZCBvbiB0aGUgbGlzdD8NCj4gDQo+IEkgd291bGQgc3VnZ2VzdCB0byBtZW50aW9u IHRoYXQgd2hpbGUgYW4gaW52YWxpZCByZWRpcmVjdF91cmkgaW5kaWNhdGVzIGENCj4gY291bnRl cmZlaXQgY2xpZW50cyBhIHZhbGlkIHJlZGlyZWN0IGRvZXMgbm90IHByb3ZlIHRoZSBjYWxsaW5n IGNsaWVudCdzIGlkZW50aXR5Lg0KPiANCj4gcmVnYXJkcywNCj4gVG9yc3Rlbi4NCj4gDQo+IA0K PiA+IEVITA0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== From eran@hueniverse.com Sun Aug 14 23:18:56 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DD011E80AE for ; Sun, 14 Aug 2011 23:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuSb95m8K6Fj for ; Sun, 14 Aug 2011 23:18:55 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id B211C11E80AD for ; Sun, 14 Aug 2011 23:18:55 -0700 (PDT) Received: (qmail 27697 invoked from network); 15 Aug 2011 06:19:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:19:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 14 Aug 2011 23:19:38 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sun, 14 Aug 2011 23:18:27 -0700 Thread-Topic: couple minor spec issues Thread-Index: AQHMS6QtMsuj60qNLUK/U1Pu7gq3j5UAReQAgB1IzxA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDD8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] FW: couple minor spec issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 06:18:56 -0000 Sending to the list for proper archiving. EHL -----Original Message----- From: Casey Lucas [mailto:CLucas@e-miles.com]=20 Sent: Wednesday, July 27, 2011 8:05 AM To: Eran Hammer-Lahav Subject: FW: couple minor spec issues Eran, I tried to send this to the oauth list yesterday but it didn't get through.= I'm not sure what the problem was but wanted to relay the information in c= ase you found it helpful. Thanks, -casey On 7/26/11 9:56 AM, "Casey Lucas" wrote: Thank you all for the oauth2 related work. While evaluating the applicability of oauth for some of my company's proble= ms I noticed what appear to be a couple of minor issues with the spec (vers= ion 20): 1. Section 4.1.3 Access Token Request is missing the word "request": "For example, the client makes the following HTTP using transport-layer sec= urity (extra line breaks are for display purposes only)" Likely it should be: For example, the client makes the following HTTP _request_ using transport-= layer security (extra line breaks are for display purposes only) 2. Section 6 Refreshing an Access Token seems to conflict with itself conce= rning token scope: "The requested scope MUST be equal or lesser than the scope originally gran= ted by the resource owner, and if omitted is treated as equal to the scope = originally granted by the resource owner." Yet the last sentence in that section states: "If a new refresh token is issued, its scope MUST be identical to that of t= he refresh token included in the request." Should't it be the lesser of the original refresh_token's scope and the new= ly requested scope? Since the scope parameter is either passed or implied, = should that last sentence be something like: If a new refresh token is issued, its scope MUST be identical to the passed= or implied scope parameter. For reference, the scope parameter description is currently: OPTIONAL. The scope of the access request expressed as a list of space-delimited, case sensitive strings. The value is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. The requested scope MUST be equal or lesser than the scope originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner. -casey From eran@hueniverse.com Sun Aug 14 23:27:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F417F21F8785 for ; Sun, 14 Aug 2011 23:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P54MLOz8qCqS for ; Sun, 14 Aug 2011 23:27:49 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7162A21F85EE for ; Sun, 14 Aug 2011 23:27:49 -0700 (PDT) Received: (qmail 3875 invoked from network); 15 Aug 2011 06:28:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:28:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 14 Aug 2011 23:28:34 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Sun, 14 Aug 2011 23:27:22 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxNWiAmwaoXWhpRRLSIm3Z69CEQXANudKkQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E317125.7080006@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 06:27:50 -0000 Added to 2.4.1: client_secret REQUIRED. The client secret. The client MAY omit the parame= ter if the client secret is an empty string. Added to 3.2.1: A public client that was not issued a client password MAY use t= he 'client_id' request parameter to identify itself when sending requests to the token endpoint. EHL > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Thursday, July 28, 2011 12:11 PM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and > identification >=20 > I would be very much in favor of that addition/clarification. >=20 > On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav > wrote: > > > > [...] and I can also add a short note that public clients may use the > > client_id for the purpose of identification with the token endpoint. > > EHL > > From eran@hueniverse.com Sun Aug 14 23:29:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BDD21F85EE for ; Sun, 14 Aug 2011 23:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MWzq7gXs-5x for ; Sun, 14 Aug 2011 23:29:26 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 35FAF21F84FD for ; Sun, 14 Aug 2011 23:29:25 -0700 (PDT) Received: (qmail 28953 invoked from network); 15 Aug 2011 06:30:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:30:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 14 Aug 2011 23:30:10 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , Phil Hunt Date: Sun, 14 Aug 2011 23:28:58 -0700 Thread-Topic: [OAUTH-WG] MAC Tokens body hash Thread-Index: AcxTC+JLg9ScljKwReyLI5rd9WccugICKLJw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDDA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72345024864560@P3PW5EX1MB01.EX1.SECURESERVER.NET> <81B6B8AF-4EC0-4F08-B48C-D1E7B39AE506@oracle.com> <1312506375.29372.YahooMailNeo@web31802.mail.mud.yahoo.com> In-Reply-To: <1312506375.29372.YahooMailNeo@web31802.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234502498CDDAP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 06:29:28 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234502498CDDAP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IGFib3V0IOKAmGFkZOKAmT8gYXMgaW4g4oCcVXNlZCB0byBpbmNsdWRlIGFkZGl0aW9uYWwg ZGF0YSBpbiB0aGUgTUFDIG5vcm1hbGl6ZWQgc3RyaW5n4oCdLg0KDQpFSEwNCg0KRnJvbTogV2ls bGlhbSBKLiBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXQ0KU2VudDogVGh1cnNk YXksIEF1Z3VzdCAwNCwgMjAxMSA2OjA2IFBNDQpUbzogRXJhbiBIYW1tZXItTGFoYXY7IFBoaWwg SHVudA0KQ2M6IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBNQUMgVG9rZW5zIGJv ZHkgaGFzaA0KDQpJdCdzIHRoZSBwcm92ZXJiaWFsICd2b2lkICpjbGllbnRfZGF0YTsnIGVxdWl2 YWxlbnQuICBBbGwgbmFtZXMgZm9yIHRoYXQgdG8gZGF0ZSBzdWNrLCBteSBmYXZvcml0ZSBpcyAn cm9jaycuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBFcmFuIEhh bW1lci1MYWhhdiA8ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNv bT4+DQpUbzogUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50 QG9yYWNsZS5jb20+Pg0KQ2M6IE9BdXRoIFdHIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA aWV0Zi5vcmc+Pg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCA0LCAyMDExIDQ6NDIgUE0NClN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIE1BQyBUb2tlbnMgYm9keSBoYXNoDQpPay4gV2Ugc2VlbSB0byBi ZSB1c2luZyBkaWZmZXJlbnQgZGVmaW5pdGlvbnMgb2Ygd2hhdCBhcHBsaWNhdGlvbiBkYXRhIG1l YW4sIGJ1dCBoYXZlIHRoZSBzYW1lIHVzZSBjYXNlcyBpbiBtaW5kLiBJJ2xsIGNvbWUgdXAgd2l0 aCBhIGRpZmZlcmVudCBuYW1lIG9yIGp1c3Qga2VlcCBleHQuDQoNCkVITA0KDQpPbiBBdWcgMywg MjAxMSwgYXQgMTI6NDIsICJQaGlsIEh1bnQiIDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCk9ubHkgYWxsb3dpbmcgKGltcGxpZWQgb3Ig bm90KSBhcHAgZGF0YSBpcyBuZWVkbGVzc2x5IG5hcnJvdyBpbiBzY29wZS4NCg0KRXh0ZW5kaW5n IE1BQyB0byBpbmNsdWRlIGNsYWltcyBvciBzZXNzaW9uIGluZm9ybWF0aW9uIGlzIGEgcGVyZmVj dGx5IHZhbGlkIHRoaW5nIHRvIGRvLiBJdCBpbXByb3ZlcyBzY2FsYWJpbGl0eSBhbmQgcmVkdWNl cyB0aGUgbmVlZCB0byBsb29rIHVwIGFydGlmYWN0IGRhdGEuDQoNCk5vdGU6ICBJJ2QgbGlrZSB0 byBzaGFyZSBtb3JlIG9uIHRoaXMsIGJ1dCBJJ20gcHJpb3JpdGl6aW5nIHRoZSBUaHJlYXQgTW9k ZWwgZG9jdW1lbnQuIE5ldmVyLXRoZS1sZXNzLCB0aGUgYWJvdmUgc2hvdWxkIGJlIGEgc3VmZmlj aWVudCBleGFtcGxlIGFib3V0IHdoeSBleHRlbnNpYmlsaXR5IGlzIHVzZWZ1bC4NCg0KUGhpbA0K DQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBl bmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20+DQoNCg0KDQoNCk9uIDIwMTEtMDgtMDMsIGF0IDExOjAzIEFNLCBFcmFuIEhhbW1lci1M YWhhdiB3cm90ZToNCg0KDQpNeSBwcm9wb3NhbCBpcyB0byBjaGFuZ2Ug4oCYZXh04oCZIHRvIOKA mGFwcOKAmSwga2VlcCB0aGUgc2FtZSBwcm9zZSBhcyDigJhleHTigJksIGFuZCBhZGQgdGhlIHVz ZSBjYXNlIG9mIOKAmGJvZHloYXNo4oCZIGFzIGFuIGV4YW1wbGUuIEnigJltIG5vdCB0b28gc3R1 Y2sgb24gdGhlIG5hbWUsIGJ1dCBteSB0aGlua2luZyBpcyB0aGF0IOKAmGFwcOKAmSByZWxheXMg dGhlIHJpZ2h0IG1lc3NhZ2UgdGhhdCB0aGlzIGlzIGEgcGxhY2Ugd2hlcmUgZGV2ZWxvcGVycyBj YW4gc3RpY2sgYW55IGFwcGxpY2F0aW9uIGRhdGEgdGhleSB3YW50IGluY2x1ZGVkLiDigJhleHTi gJkgY29udmV5cyB0aGUgaWRlYSBvZiBleHRlbnNpb25zIHdoaWNoIEnigJltIG5vdCBzbyB0aHJp bGxlZCBhYm91dC4NCg0KSW4gb3RoZXIgd29yZHMsIEnigJlkIGxpa2UgYSBkZXZlbG9wZXIgcmVh ZGluZyB0aGlzIHRvIGZlZWwgY29tZm9ydGFibGUgdXNpbmcgaXQgcmlnaHQgYXdheSBmb3Igc2Vj dXJpbmcgYWRkaXRpb24gYml0cyBzdWNoIGFzIGEgSlNPTiBwYXlsb2FkLCBidXQgSSBkb27igJl0 IGxpa2UgdGhlIGlkZWEgb2Ygc29tZW9uZSBwdWJsaXNoaW5nIGFuIEktRCB3aXRoIGEgZnVsbCBz eW50YXggYW5kIGNhbm9uaWNhbGl6YXRpb24gcmVxdWlyZW1lbnRzIGZvciBzYXksIHNpbmdpbmcg YW4gZW50aXJlIHJlcXVlc3QsIGhlYWRlcnMgYW5kIGFsbC4gSSBmZWVsIHRoYXQgd291bGQgYmUg bXVjaCBiZXR0ZXIgYWNjb21wbGlzaGVkIGJ5IGRlZmluaW5nIGEgbmV3IEhUVFAgYXV0aGVudGlj YXRpb24gc2NoZW1lLg0KDQpQaGlsb3NvcGhpY2FsbHksIEkgdGhpbmsgZXh0ZW5zaWJsZSBhdXRo ZW50aWNhdGlvbiBzY2hlbWVzIGFyZSBhIGJhZCBpZGVhLg0KDQpFSEwNCg0KDQpGcm9tOiBXaWxs aWFtIEouIE1pbGxzIFttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21dPG1haWx0bzpbbWFpbHRv OndtaWxsc0B5YWhvby1pbmMuY29tXT4NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDAzLCAyMDEx IDEwOjI4IEFNDQpUbzogUGhpbGxpcCBIdW50OyBFcmFuIEhhbW1lci1MYWhhdg0KQ2M6IEJlbiBB ZGlkYTsgT0F1dGggV0c7IEFkYW0gQmFydGgoYWRhbUBhZGFtYmFydGguY29tPG1haWx0bzphZGFt QGFkYW1iYXJ0aC5jb20+KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTUFDIFRva2VucyBib2R5 IGhhc2gNCg0KSW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBJJ20gY29taW5nIGFyb3VuZCB0byB0aGUg dmlld3BvaW50IHRoYXQgYSBzaW5nbGUgYWRkaXRpb25hbCBwcmVkZWZpbmVkIHNwb3QgaXMgc3Vm ZmljaWVudC4gIElmIHRoZSBhcHAgZGV2ZWxvcGVyIHdhbnRzIHRvIGluY2x1ZGUgYWRkdGlvbmFs IGRhdGEgdGhlcmUgKGl1biB0aGUgc3BlY2lmaWVkIGZvcm1hdCkgdGhhdCdzIGZpbmUuICBJZiB3 aGF0IHRoZXkgd2FudCB0byBkbyBpcyBpbmNsdWRlIGEgc2lnbmF0dXJlIG9mIG90aGVyIHBheWxv YWQgdGhhdCdzIGZpbmUgdG9vLg0KDQpJJ20gbm90IGluIGxvdmUgd2l0aCB0aGUgbmFtZSAiYXBw IiB0aG91Z2gsICJleHQiIGlzIGJldHRlci4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkZyb206IFBoaWxsaXAgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tPj4NClRvOiBFcmFuIEhhbW1lci1MYWhhdiA8ZXJhbkBodWVuaXZl cnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+DQpDYzogQmVuIEFkaWRhIDxiZW5A YWRpZGEubmV0PG1haWx0bzpiZW5AYWRpZGEubmV0Pj47IE9BdXRoIFdHIDxvYXV0aEBpZXRmLm9y ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PjsgIkFkYW0gQmFydGgoYWRhbUBhZGFtYmFydGguY29t PG1haWx0bzphZGFtQGFkYW1iYXJ0aC5jb20+KSIgPGFkYW1AYWRhbWJhcnRoLmNvbTxtYWlsdG86 YWRhbUBhZGFtYmFydGguY29tPj4NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyLCAyMDExIDc6MTQg UE0NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE1BQyBUb2tlbnMgYm9keSBoYXNoDQoNCg0KUGhp bA0KDQpPbiAyMDExLTA4LTAyLCBhdCAxODowMiwgRXJhbiBIYW1tZXItTGFoYXYgPGVyYW5AaHVl bml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiB3cm90ZToNClRoZSBpZGVh IGlzIHRvIGRyb3AgJ2V4dCcgYW5kICdib2R5aGFzaCcgZHVlIHRvIGJlaW5nIHVuZGVyc3BlY2lm aWVkIGFuZCB0aGVyZWZvcmUgY2F1c2luZyBtb3JlIGhhcm0gdGhhbiBnb29kLiBJIGFkZGVkICdl eHQnIHRvIGFsbG93IGZvciBhcHBsaWNhdGlvbiBzcGVjaWZpYyBkYXRhIHRvIGJlIGluY2x1ZGVk IGluIHRoZSBzaWduZWQgY29udGVudC4gSG93ZXZlciwgdGhlIG5hbWUgc3VnZ2VzdHMgdGhpcyBp cyBhbiBleHRlbnNpb24gcG9pbnQgZm9yIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucy4gSSBiZWxpZXZl IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgc2hvdWxkIG5vdCBiZSBleHRlbnNpYmxlIGluIHdheXMg dGhhdCBhZmZlY3QgdGhlaXIgc2VjdXJpdHkgb3IgaW50ZXJvcCBwcm9wZXJ0aWVzIGFuZCB3aXRo b3V0IGFkZGl0aW9uYWwgdGV4dCAocmVnaXN0cnksIHByb2Nlc3MsIGV0YykgZm9yIHRoZSAnZXh0 JyBwYXJhbWV0ZXIsIGl0IHdpbGwgY2F1c2UgbW9yZSBpc3N1ZXMgdGhhbiBoZWxwLg0KDQpJbnN0 ZWFkIG9mIHRoZSAnZXh0JyBwYXJhbWV0ZXIgSSBhbSBzdWdnZXN0aW5nIHRoZSAnYXBwJyBwYXJh bWV0ZXIgd2hpY2ggd2lsbCBkbyB0aGUgc2FtZSwgYnV0IHdpbGwgYmUgYmV0dGVyIHBvc2l0aW9u ZWQgYXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgZGF0YS4gVGhlIHByb3NlIHdpbGwgZ28gYSBz dGVwIGZ1cnRoZXIgYW5kIHJlY29tbWVuZCB0aGF0IHRoZSBwYXJhbWV0ZXIgdmFsdWUgaW5jbHVk ZSBhIGhhc2ggb2YgdGhlIGRhdGEsIG5vdCB0aGUgZGF0YSBpdHNlbGYuIFRoaXMgaXMgdG8gZW5z dXJlIHRoZSBwYXJhbWV0ZXIgZG9lcyBub3QgYmVjb21lIHBhcnQgb2YgdGhlIHBheWxvYWQgd2hp Y2ggaXMgaW5hcHByb3ByaWF0ZSBmb3IgSFRUUCByZXF1ZXN0cy4NCi0xIHdoYXQgeW91IGRlc2Ny aWJlIGFwcGVhcnMgdG8gYmUgYSBzZXBhcmF0ZSBmZWF0dXJlIGZyb20gZXh0DQoNCkFzIGZvciB0 aGUgJ2JvZHloYXNoJyBwYXJhbWV0ZXIsIEkgd291bGQgbGlrZSB0byByZW1vdmUgaXQgYmVjYXVz ZSBpdCBpcyB1bmRlcnNwZWNpZmllZCAod2UgaGFkIGFuIGFjdHVhbCBkZXBsb3ltZW50IGV4cGVy aWVuY2Ugc2hvd2luZyB0aGF0IGl0IGRvZXNuJ3QgcHJvZHVjZSBpbnRlcm9wZXJhYmxlIGltcGxl bWVudGF0aW9ucyBkdWUgdG8gdGhlIG1hbnkgSFRUUCBib2R5IHRyYW5zZm9ybWF0aW9uIGFwcGxp ZWQgaW4gbW9zdCBmcmFtZXdvcmtzKS4gU29sdmluZyB0aGlzIGlzc3VlIGlzIG5vdCBwb3NzaWJs ZSBkdWUgdG8gdGhlIG1hbnkgZGlmZmVyZW50IHR5cGVzIG9mIGJvZGllcyBhbmQgZnJhbWV3b3Jr cyAoYW5kIGNsZWFybHkgb3BlcmF0aW5nIG9uIHRoZSAicmF3IiBib2R5IGRvZXNuJ3Qgd29yayku IEluc3RlYWQsIGRldmVsb3BlcnMgY2FuIHVzZSB0aGUgbmV3ICdhcHAnIHBhcmFtZXRlciB0byBh Y2NvbXBsaXNoIHRoYXQuDQoNCisxDQoNCg0KQXMgZm9yIHRoZSBub3JtYWxpemVkIHN0cmluZywg aXQgd2lsbCBiZSBhZGp1c3RlZCB0byByZWZsZWN0IHRoZXNlIGNoYW5nZXMgd2hlbiB0aGV5IGFy ZSBtYWRlLCBzbyBubyBwbGFjZWhvbGRlcnMgd2hpY2ggd2lsbCByZXF1aXJlIGNvZGUgY2hhbmdl LiBDb25zaWRlcmluZyB0aGlzIGlzIC0wMCwgaXQgaXMgY2xlYXJseSBub3QgYSBzdGFibGUgZG9j dW1lbnQuDQpXaWxsIHRoZXNlIGNoYW5nZXMgd29yayB3aXRoIHlvdXIgdXNlIGNhc2VzPw0KDQpF SEwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNreWxhciBXb29kd2FyZCBb bWFpbHRvOnNreWxhckBraXZhLm9yZ108bWFpbHRvOlttYWlsdG86c2t5bGFyQGtpdmEub3JnXT4N ClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwMiwgMjAxMSA0OjAyIFBNDQpUbzogRXJhbiBIYW1tZXIt TGFoYXYNCkNjOiBPQXV0aCBXRzsgQmVuIEFkaWRhOyAnQWRhbSBCYXJ0aCAoYWRhbUBhZGFtYmFy dGguY29tPG1haWx0bzphZGFtQGFkYW1iYXJ0aC5jb20+KScNClN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIE1BQyBUb2tlbnMgYm9keSBoYXNoDQoNCmh1cnJhaCENCihub3QgbmVjZXNzYXJpbHkgZm9y IGxvc2luZyBhIHdheSB0byBzaWduIHRoZSBib2R5LCBidXQgZm9yIHNpbXBsaWNpdHkgYW5kDQph dm9pZGluZyBzb21lIG9mIHRoZSBwb3RlbnRpYWwgaW5jb25zaXN0ZW5jaWVzIHcvIGJvZHloYXNo KS4NCg0KSXMgeW91ciBwbGFuIHRvIHJlc2VydmUgYW4gZW1wdHkgbGluZSA2IGZvciB0aGUgTm9y bWFsaXplZCBSZXF1ZXN0IFN0cmluZw0KKHdoaWNoIHdhcyB1c2VkIGZvciBib2R5aGFzaCkgb3Ig ZWxpbWluYXRlIGl0LCBicmluaW5nIHRoZSB0b3RhbCB0byBzaXgNCmVsZW1lbnRzPw0KDQpza3ls YXINCg0KT24gSnVsIDMwLCAyMDExLCBhdCAzOjQzIEFNLCBFcmFuIEhhbW1lci1MYWhhdiB3cm90 ZToNCg0KSSBwbGFuIHRvIGRyb3Agc3VwcG9ydCBmb3IgdGhlIGJvZHloYXNoIHBhcmFtZXRlciBp biB0aGUgbmV4dCBkcmFmdCBiYXNlZA0Kb24gYmFkIGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2Uu IEV2ZW4gd2l0aCBzaW1wbGUgdGV4dCBib2R5LCBVVEYNCmVuY29kaW5nIGhhcyBpbnRyb2R1Y2Vk IHNpZ25pZmljYW50IGlzc3VlcyBmb3IgdXMuIFRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgbm90DQp3 b3JrIHVzaW5nIHNpbXBsZSBKUyBjb2RlIGJldHdlZW4gYSBicm93c2VyIGFuZCBub2RlLmpzIGV2 ZW4gd2hlbiBib3RoDQp1c2UgdGhlIHNhbWUgdjggZW5naW5lIGR1ZSB0byBkaWZmZXJlbmNlcyBp biB0aGUgYm9keSBlbmNvZGluZy4gQmFzaWNhbGx5LA0KdGhlIEpTIHN0cmluZyB1c2VkIHRvIHNl bmQgYSByZXF1ZXN0IGZyb20gdGhlIGJyb3dzZXIgaXMgbm90IHRoZSBhY3R1YWwgc3RyaW5nDQpz ZW50IG9uIHRoZSB3aXJlLg0KDQpUbyBmaXggdGhhdCwgd2UgbmVlZCB0byBmb3JjZSBVVEYtOCBl bmNvZGluZyBvbiBib3RoIHNpZGVzLiBIb3dldmVyLCB0aGF0DQppcyB2ZXJ5IG11Y2ggYXBwbGlj YXRpb24gc3BlY2lmaWMuIFRoaXMgd2lsbCBub3Qgd29yayBmb3Igbm9uLXRleHQgYm9kaWVzLg0K SW5zdGVhZCwgdGhlIHNwZWNpZmljYXRpb24gc2hvdWxkIG9mZmVyIGEgc2ltcGxlIHdheSB0byB1 c2UgdGhlIGV4dCBwYXJhbWV0ZXINCmZvciBzdWNoIG5lZWRzLCBpbmNsdWRpbmcgc2luZ2luZyBo ZWFkZXJzLiBBbmQgYnkgb2ZmZXIgSSBtZWFuIGdpdmUNCmV4YW1wbGVzLCBidXQgbGVhdmUgaXQg YXBwbGljYXRpb24gc3BlY2lmaWMgZm9yIG5vdy4NCg0KSSBhbSBvcGVuIHRvIHN1Z2dlc3Rpb25z IGJ1dCBzbyBmYXIgYWxsIHRoZSBzb2x1dGlvbnMgSSBjYW1lIHVwIHdpdGggd2lsbA0KaW50cm9k dWNlIHVuYWNjZXB0YWJsZSBjb21wbGV4aXR5IHRoYXQgd2lsbCBiYXNpY2FsbHkgbWFrZSB0aGlz IHdvcmsgdXNlbGVzcy4NCg0KRUhMDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86 T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_90C41DD21FB7C64BB94121FBBC2E7234502498CDDAP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi55aXYz ODk2Njg4NjZhcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOnlpdjM4OTY2ODg2NmFw cGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi55aXYzODk2Njg4NjZhcHBsZS1jb252ZXJ0ZWQtc3BhY2UN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2Mzg5NjY4ODY2YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVh ZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3Jk U2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SG93IGFi b3V0IOKAmGFkZOKAmT8gYXMgaW4g4oCcVXNlZCB0byBpbmNsdWRlIGFkZGl0aW9uYWwgZGF0YSBp biB0aGUgTUFDIG5vcm1hbGl6ZWQgc3RyaW5n4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RUhMPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiBXaWxsaWFtIEouIE1pbGxzIFttYWlsdG86d21pbGxz QHlhaG9vLWluYy5jb21dIDxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAwNCwgMjAx MSA2OjA2IFBNPGJyPjxiPlRvOjwvYj4gRXJhbiBIYW1tZXItTGFoYXY7IFBoaWwgSHVudDxicj48 Yj5DYzo8L2I+IE9BdXRoIFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBNQUMg VG9rZW5zIGJvZHkgaGFzaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPkl0J3MgdGhlIHByb3ZlcmJpYWwgJ3ZvaWQgKmNsaWVu dF9kYXRhOycgZXF1aXZhbGVudC4mbmJzcDsgQWxsIG5hbWVzIGZvciB0aGF0IHRvIGRhdGUgc3Vj aywgbXkgZmF2b3JpdGUgaXMgJ3JvY2snLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2Vu dGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpibGFjayc+PGhyIHNpemU9MSB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyPjwvc3Bhbj48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91 bmQ6d2hpdGUnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPiBFcmFuIEhhbW1lci1MYWhhdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVl bml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+Jmd0Ozxicj48Yj5Ubzo8L2I+IFBo aWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPjxiPkNjOjwvYj4gT0F1dGggV0cgJmx0OzxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj48Yj5TZW50 OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCA0LCAyMDExIDQ6NDIgUE08YnI+PGI+U3ViamVjdDo8L2I+ IFJlOiBbT0FVVEgtV0ddIE1BQyBUb2tlbnMgYm9keSBoYXNoPC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXYgaWQ9eWl2Mzg5NjY4ODY2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPk9rLiBXZSBzZWVtIHRvIGJlIHVzaW5nIGRpZmZlcmVudCBkZWZpbml0 aW9ucyBvZiB3aGF0IGFwcGxpY2F0aW9uIGRhdGEgbWVhbiwgYnV0IGhhdmUgdGhlIHNhbWUgdXNl IGNhc2VzIGluIG1pbmQuIEknbGwgY29tZSB1cCB3aXRoIGEgZGlmZmVyZW50IG5hbWUgb3IganVz dCBrZWVwIGV4dC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPkVITDxicj48YnI+T24gQXVnIDMsIDIwMTEsIGF0IDEyOjQy LCAmcXVvdDtQaGlsIEh1bnQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+T25s eSBhbGxvd2luZyAoaW1wbGllZCBvciBub3QpIGFwcCBkYXRhIGlzIG5lZWRsZXNzbHkmbmJzcDtu YXJyb3cgaW4gc2NvcGUuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5F eHRlbmRpbmcgTUFDIHRvIGluY2x1ZGUgY2xhaW1zIG9yIHNlc3Npb24gaW5mb3JtYXRpb24gaXMg YSBwZXJmZWN0bHkgdmFsaWQgdGhpbmcgdG8gZG8uIEl0IGltcHJvdmVzIHNjYWxhYmlsaXR5IGFu ZCByZWR1Y2VzIHRoZSBuZWVkIHRvIGxvb2sgdXAgYXJ0aWZhY3QgZGF0YS4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk5vdGU6ICZuYnNwO0knZCBsaWtlIHRv IHNoYXJlIG1vcmUgb24gdGhpcywgYnV0IEknbSBwcmlvcml0aXppbmcgdGhlIFRocmVhdCBNb2Rl bCBkb2N1bWVudC4gTmV2ZXItdGhlLWxlc3MsIHRoZSBhYm92ZSBzaG91bGQgYmUgYSBzdWZmaWNp ZW50IGV4YW1wbGUgYWJvdXQgd2h5IGV4dGVuc2liaWxpdHkgaXMgdXNlZnVsLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIGNsYXNzPXlpdjM4OTY2ODg2NmFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayc+UGhpbDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2Pjxk aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIjtj b2xvcjpibGFjayc+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEzLjVwdDtiYWNr Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToi SGVsdmV0aWNhIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxhIGhyZWY9Im1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0 ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48YnI+PGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+T24gMjAxMS0wOC0w MywgYXQgMTE6MDMgQU0sIEVyYW4gSGFtbWVyLUxhaGF2IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk15IHByb3Bvc2FsIGlzIHRvIGNoYW5nZSDigJhleHTigJkg dG8g4oCYYXBw4oCZLCBrZWVwIHRoZSBzYW1lIHByb3NlIGFzIOKAmGV4dOKAmSwgYW5kIGFkZCB0 aGUgdXNlIGNhc2Ugb2Yg4oCYYm9keWhhc2jigJkgYXMgYW4gZXhhbXBsZS4gSeKAmW0gbm90IHRv byBzdHVjayBvbiB0aGUgbmFtZSwgYnV0IG15IHRoaW5raW5nIGlzIHRoYXQg4oCYYXBw4oCZIHJl bGF5cyB0aGUgcmlnaHQgbWVzc2FnZSB0aGF0IHRoaXMgaXMgYSBwbGFjZSB3aGVyZSBkZXZlbG9w ZXJzIGNhbiBzdGljayBhbnkgYXBwbGljYXRpb24gZGF0YSB0aGV5IHdhbnQgaW5jbHVkZWQuIOKA mGV4dOKAmSBjb252ZXlzIHRoZSBpZGVhIG9mIGV4dGVuc2lvbnMgd2hpY2ggSeKAmW0gbm90IHNv IHRocmlsbGVkIGFib3V0Ljwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dy b3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+SW4gb3RoZXIgd29yZHMsIEnigJlkIGxpa2UgYSBkZXZlbG9wZXIgcmVhZGluZyB0aGlzIHRv IGZlZWwgY29tZm9ydGFibGUgdXNpbmcgaXQgcmlnaHQgYXdheSBmb3Igc2VjdXJpbmcgYWRkaXRp b24gYml0cyBzdWNoIGFzIGEgSlNPTiBwYXlsb2FkLCBidXQgSSBkb27igJl0IGxpa2UgdGhlIGlk ZWEgb2Ygc29tZW9uZSBwdWJsaXNoaW5nIGFuIEktRCB3aXRoIGEgZnVsbCBzeW50YXggYW5kIGNh bm9uaWNhbGl6YXRpb24gcmVxdWlyZW1lbnRzIGZvciBzYXksIHNpbmdpbmcgYW4gZW50aXJlIHJl cXVlc3QsIGhlYWRlcnMgYW5kIGFsbC4gSSBmZWVsIHRoYXQgd291bGQgYmUgbXVjaCBiZXR0ZXIg YWNjb21wbGlzaGVkIGJ5IGRlZmluaW5nIGEgbmV3IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1l Ljwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGhpbG9zb3BoaWNh bGx5LCBJIHRoaW5rIGV4dGVuc2libGUgYXV0aGVudGljYXRpb24gc2NoZW1lcyBhcmUgYSBiYWQg aWRlYS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVITDwvc3Bh bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6aW5pdGlhbCc+PGRpdj48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbjtib3JkZXItY29sb3I6aW5pdGlhbCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGNsYXNzPXlpdjM4OTY2ODg2NmFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5XaWxs aWFtIEouIE1pbGxzIDxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29t XSI+W21haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbV08L2E+PHNwYW4gY2xhc3M9eWl2Mzg5NjY4 ODY2YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+PGI+U2VudDo8L2I+PHNw YW4gY2xhc3M9eWl2Mzg5NjY4ODY2YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5X ZWRuZXNkYXksIEF1Z3VzdCAwMywgMjAxMSAxMDoyOCBBTTxicj48Yj5Ubzo8L2I+PHNwYW4gY2xh c3M9eWl2Mzg5NjY4ODY2YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5QaGlsbGlw IEh1bnQ7IEVyYW4gSGFtbWVyLUxhaGF2PGJyPjxiPkNjOjwvYj48c3BhbiBjbGFzcz15aXYzODk2 Njg4NjZhcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPkJlbiBBZGlkYTsgT0F1dGgg V0c7IEFkYW0gQmFydGgoPGEgaHJlZj0ibWFpbHRvOmFkYW1AYWRhbWJhcnRoLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmFkYW1AYWRhbWJhcnRoLmNvbTwvYT4pPGJyPjxiPlN1YmplY3Q6PC9iPjxzcGFu IGNsYXNzPXlpdjM4OTY2ODg2NmFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+UmU6 IFtPQVVUSC1XR10gTUFDIFRva2VucyBib2R5IGhhc2g8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPkluIHRoaW5raW5nIGFib3V0 IHRoaXMgSSdtIGNvbWluZyBhcm91bmQgdG8gdGhlIHZpZXdwb2ludCB0aGF0IGEgc2luZ2xlIGFk ZGl0aW9uYWwgcHJlZGVmaW5lZCBzcG90IGlzIHN1ZmZpY2llbnQuJm5ic3A7IElmIHRoZSBhcHAg ZGV2ZWxvcGVyIHdhbnRzIHRvIGluY2x1ZGUgYWRkdGlvbmFsIGRhdGEgdGhlcmUgKGl1biB0aGUg c3BlY2lmaWVkIGZvcm1hdCkgdGhhdCdzIGZpbmUuJm5ic3A7IElmIHdoYXQgdGhleSB3YW50IHRv IGRvIGlzIGluY2x1ZGUgYSBzaWduYXR1cmUgb2Ygb3RoZXIgcGF5bG9hZCB0aGF0J3MgZmluZSB0 b28uPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJs YWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPkknbSBub3QgaW4gbG92ZSB3aXRoIHRoZSBuYW1lICZxdW90O2FwcCZxdW90 OyB0aG91Z2gsICZxdW90O2V4dCZxdW90OyBpcyBiZXR0ZXIuPC9zcGFuPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRp dj48ZGl2PjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGln bjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxociBzaXplPTEg d2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2lu LWJvdHRvbToxMi4wcHQnPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0 ZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz15aXYz ODk2Njg4NjZhcHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPlBoaWxsaXAgSHVudCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9y YWNsZS5jb208L2E+Jmd0Ozxicj48Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9eWl2Mzg5NjY4ODY2YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5FcmFuIEhhbW1lci1MYWhhdiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iIHRhcmdldD0iX2JsYW5rIj5lcmFuQGh1 ZW5pdmVyc2UuY29tPC9hPiZndDs8YnI+PGI+Q2M6PC9iPjxzcGFuIGNsYXNzPXlpdjM4OTY2ODg2 NmFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+QmVuIEFkaWRhICZsdDs8YSBocmVm PSJtYWlsdG86YmVuQGFkaWRhLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmJlbkBhZGlkYS5uZXQ8L2E+ Jmd0OzsgT0F1dGggV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs7ICZxdW90O0FkYW0gQmFydGgoPGEgaHJl Zj0ibWFpbHRvOmFkYW1AYWRhbWJhcnRoLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYW1AYWRhbWJh cnRoLmNvbTwvYT4pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWRhbUBhZGFtYmFydGguY29t IiB0YXJnZXQ9Il9ibGFuayI+YWRhbUBhZGFtYmFydGguY29tPC9hPiZndDs8YnI+PGI+U2VudDo8 L2I+PHNwYW4gY2xhc3M9eWl2Mzg5NjY4ODY2YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj5UdWVzZGF5LCBBdWd1c3QgMiwgMjAxMSA3OjE0IFBNPGJyPjxiPlN1YmplY3Q6PC9iPjxz cGFuIGNsYXNzPXlpdjM4OTY2ODg2NmFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+ UmU6IFtPQVVUSC1XR10gTUFDIFRva2VucyBib2R5IGhhc2g8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBpZD15aXYzODk2Njg4 NjY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YnI+PGJyPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxicj5PbiAyMDExLTA4LTAyLCBhdCAxODowMiwgRXJhbiBIYW1tZXItTGFoYXYg Jmx0OzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZXJhbkBodWVuaXZlcnNlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRoZSBpZGVhIGlzIHRvIGRyb3AgJ2V4 dCcgYW5kICdib2R5aGFzaCcgZHVlIHRvIGJlaW5nIHVuZGVyc3BlY2lmaWVkIGFuZCB0aGVyZWZv cmUgY2F1c2luZyBtb3JlIGhhcm0gdGhhbiBnb29kLiBJIGFkZGVkICdleHQnIHRvIGFsbG93IGZv ciBhcHBsaWNhdGlvbiBzcGVjaWZpYyBkYXRhIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBzaWduZWQg Y29udGVudC4gSG93ZXZlciwgdGhlIG5hbWUgc3VnZ2VzdHMgdGhpcyBpcyBhbiBleHRlbnNpb24g cG9pbnQgZm9yIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucy4gSSBiZWxpZXZlIGF1dGhlbnRpY2F0aW9u IHNjaGVtZXMgc2hvdWxkIG5vdCBiZSBleHRlbnNpYmxlIGluIHdheXMgdGhhdCBhZmZlY3QgdGhl aXIgc2VjdXJpdHkgb3IgaW50ZXJvcCBwcm9wZXJ0aWVzIGFuZCB3aXRob3V0IGFkZGl0aW9uYWwg dGV4dCAocmVnaXN0cnksIHByb2Nlc3MsIGV0YykgZm9yIHRoZSAnZXh0JyBwYXJhbWV0ZXIsIGl0 IHdpbGwgY2F1c2UgbW9yZSBpc3N1ZXMgdGhhbiBoZWxwLjxicj48YnI+SW5zdGVhZCBvZiB0aGUg J2V4dCcgcGFyYW1ldGVyIEkgYW0gc3VnZ2VzdGluZyB0aGUgJ2FwcCcgcGFyYW1ldGVyIHdoaWNo IHdpbGwgZG8gdGhlIHNhbWUsIGJ1dCB3aWxsIGJlIGJldHRlciBwb3NpdGlvbmVkIGFzIGFuIGFw cGxpY2F0aW9uLXNwZWNpZmljIGRhdGEuIFRoZSBwcm9zZSB3aWxsIGdvIGEgc3RlcCBmdXJ0aGVy IGFuZCByZWNvbW1lbmQgdGhhdCB0aGUgcGFyYW1ldGVyIHZhbHVlIGluY2x1ZGUgYSBoYXNoIG9m IHRoZSBkYXRhLCBub3QgdGhlIGRhdGEgaXRzZWxmLiBUaGlzIGlzIHRvIGVuc3VyZSB0aGUgcGFy YW1ldGVyIGRvZXMgbm90IGJlY29tZSBwYXJ0IG9mIHRoZSBwYXlsb2FkIHdoaWNoIGlzIGluYXBw cm9wcmlhdGUgZm9yIEhUVFAgcmVxdWVzdHMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4t MSB3aGF0IHlvdSBkZXNjcmliZSBhcHBlYXJzIHRvIGJlIGEgc2VwYXJhdGUgZmVhdHVyZSBmcm9t IGV4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxi cj5BcyBmb3IgdGhlICdib2R5aGFzaCcgcGFyYW1ldGVyLCBJIHdvdWxkIGxpa2UgdG8gcmVtb3Zl IGl0IGJlY2F1c2UgaXQgaXMgdW5kZXJzcGVjaWZpZWQgKHdlIGhhZCBhbiBhY3R1YWwgZGVwbG95 bWVudCBleHBlcmllbmNlIHNob3dpbmcgdGhhdCBpdCBkb2Vzbid0IHByb2R1Y2UgaW50ZXJvcGVy YWJsZSBpbXBsZW1lbnRhdGlvbnMgZHVlIHRvIHRoZSBtYW55IEhUVFAgYm9keSB0cmFuc2Zvcm1h dGlvbiBhcHBsaWVkIGluIG1vc3QgZnJhbWV3b3JrcykuIFNvbHZpbmcgdGhpcyBpc3N1ZSBpcyBu b3QgcG9zc2libGUgZHVlIHRvIHRoZSBtYW55IGRpZmZlcmVudCB0eXBlcyBvZiBib2RpZXMgYW5k IGZyYW1ld29ya3MgKGFuZCBjbGVhcmx5IG9wZXJhdGluZyBvbiB0aGUgJnF1b3Q7cmF3JnF1b3Q7 IGJvZHkgZG9lc24ndCB3b3JrKS4gSW5zdGVhZCwgZGV2ZWxvcGVycyBjYW4gdXNlIHRoZSBuZXcg J2FwcCcgcGFyYW1ldGVyIHRvIGFjY29tcGxpc2ggdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+KzE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRv bToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSdtYXJnaW4tYm90 dG9tOjEyLjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxicj5BcyBmb3IgdGhlIG5vcm1hbGl6ZWQgc3RyaW5n LCBpdCB3aWxsIGJlIGFkanVzdGVkIHRvIHJlZmxlY3QgdGhlc2UgY2hhbmdlcyB3aGVuIHRoZXkg YXJlIG1hZGUsIHNvIG5vIHBsYWNlaG9sZGVycyB3aGljaCB3aWxsIHJlcXVpcmUgY29kZSBjaGFu Z2UuIENvbnNpZGVyaW5nIHRoaXMgaXMgLTAwLCBpdCBpcyBjbGVhcmx5IG5vdCBhIHN0YWJsZSBk b2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGJsb2NrcXVvdGUgc3R5 bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0 ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5XaWxsIHRoZXNlIGNoYW5nZXMgd29yayB3aXRo IHlvdXIgdXNlIGNhc2VzPzxicj48YnI+RUhMPGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+RnJvbTogU2t5bGFyIFdvb2R3 YXJkPHNwYW4gY2xhc3M9eWl2Mzg5NjY4ODY2YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86W21haWx0bzpza3lsYXJAa2l2YS5vcmddIiB0YXJnZXQ9Il9i bGFuayI+W21haWx0bzpza3lsYXJAa2l2YS5vcmddPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+U2VudDogVHVlc2RheSwgQXVndXN0 IDAyLCAyMDExIDQ6MDIgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3Rl PjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQn PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPlRvOiBFcmFuIEhhbW1lci1MYWhhdjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Q2M6IE9BdXRoIFdHOyBC ZW4gQWRpZGE7ICdBZGFtIEJhcnRoICg8YSBocmVmPSJtYWlsdG86YWRhbUBhZGFtYmFydGguY29t IiB0YXJnZXQ9Il9ibGFuayI+YWRhbUBhZGFtYmFydGguY29tPC9hPiknPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5TdWJqZWN0OiBSZTog W09BVVRILVdHXSBNQUMgVG9rZW5zIGJvZHkgaGFzaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5odXJyYWghPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4obm90IG5l Y2Vzc2FyaWx5IGZvciBsb3NpbmcgYSB3YXkgdG8gc2lnbiB0aGUgYm9keSwgYnV0IGZvciBzaW1w bGljaXR5IGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+YXZvaWRpbmcgc29tZSBvZiB0aGUgcG90ZW50aWFsIGluY29uc2lzdGVuY2ll cyB3LyBib2R5aGFzaCkuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPklzIHlvdXIgcGxhbiB0byByZXNlcnZlIGFuIGVtcHR5 IGxpbmUgNiBmb3IgdGhlIE5vcm1hbGl6ZWQgUmVxdWVzdCBTdHJpbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPih3aGljaCB3YXMgdXNl ZCBmb3IgYm9keWhhc2gpIG9yIGVsaW1pbmF0ZSBpdCwgYnJpbmluZyB0aGUgdG90YWwgdG8gc2l4 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHls ZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz5lbGVtZW50cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Jsb2NrcXVv dGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+c2t5bGFyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0 ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk9uIEp1bCAzMCwgMjAxMSwgYXQg Mzo0MyBBTSwgRXJhbiBIYW1tZXItTGFoYXYgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkkgcGxhbiB0byBkcm9w IHN1cHBvcnQgZm9yIHRoZSBib2R5aGFzaCBwYXJhbWV0ZXIgaW4gdGhlIG5leHQgZHJhZnQgYmFz ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz5vbiBiYWQgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZS4gRXZlbiB3 aXRoIHNpbXBsZSB0ZXh0IGJvZHksIFVURjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ZW5jb2RpbmcgaGFzIGludHJvZHVjZWQgc2lnbmlm aWNhbnQgaXNzdWVzIGZvciB1cy4gVGhlIGN1cnJlbnQgZHJhZnQgZG9lcyBub3Q8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPndvcmsgdXNp bmcgc2ltcGxlIEpTIGNvZGUgYmV0d2VlbiBhIGJyb3dzZXIgYW5kIG5vZGUuanMgZXZlbiB3aGVu IGJvdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl IHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPnVzZSB0aGUgc2FtZSB2OCBlbmdpbmUgZHVlIHRvIGRpZmZlcmVuY2VzIGluIHRoZSBi b2R5IGVuY29kaW5nLiBCYXNpY2FsbHksPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxv Y2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz50aGUgSlMgc3RyaW5nIHVzZWQgdG8gc2VuZCBhIHJl cXVlc3QgZnJvbSB0aGUgYnJvd3NlciBpcyBub3QgdGhlIGFjdHVhbCBzdHJpbmc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPnNlbnQgb24g dGhlIHdpcmUuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2tx dW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48YmxvY2tx dW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Jz48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UbyBmaXggdGhhdCwgd2UgbmVlZCB0byBm b3JjZSBVVEYtOCBlbmNvZGluZyBvbiBib3RoIHNpZGVzLiBIb3dldmVyLCB0aGF0PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg c3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+aXMgdmVyeSBtdWNoIGFwcGxpY2F0aW9uIHNwZWNpZmljLiBUaGlzIHdpbGwgbm90IHdv cmsgZm9yIG5vbi10ZXh0IGJvZGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkluc3RlYWQsIHRoZSBzcGVjaWZpY2F0aW9uIHNob3Vs ZCBvZmZlciBhIHNpbXBsZSB3YXkgdG8gdXNlIHRoZSBleHQgcGFyYW1ldGVyPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5mb3Igc3VjaCBu ZWVkcywgaW5jbHVkaW5nIHNpbmdpbmcgaGVhZGVycy4gQW5kIGJ5IG9mZmVyIEkgbWVhbiBnaXZl PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHls ZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz5leGFtcGxlcywgYnV0IGxlYXZlIGl0IGFwcGxpY2F0aW9uIHNwZWNpZmljIGZvciBub3cuPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0n bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48YmxvY2txdW90ZSBzdHlsZT0n bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90 ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Jz48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5JIGFtIG9wZW4gdG8gc3VnZ2VzdGlvbnMgYnV0IHNvIGZhciBh bGwgdGhlIHNvbHV0aW9ucyBJIGNhbWUgdXAgd2l0aCB3aWxsPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+aW50cm9k dWNlIHVuYWNjZXB0YWJsZSBjb21wbGV4aXR5IHRoYXQgd2lsbCBiYXNpY2FsbHkgbWFrZSB0aGlz IHdvcmsgdXNlbGVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxi bG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Jsb2Nr cXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQnPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkVITDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxibG9ja3F1b3RlIHN0eWxlPSdt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5 bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGJsb2NrcXVvdGUgc3R5 bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2tx dW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCc+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGEgaHJlZj0ibWFpbHRvOk9BdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5 bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGJsb2NrcXVvdGUgc3R5 bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVv dGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rp dj48ZGl2IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0i bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+ PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndo aXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxicj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJl Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPjxi cj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9i b2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E7234502498CDDAP3PW5EX1MB01E_-- From eran@hueniverse.com Sun Aug 14 23:32:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC3D11E8083 for ; Sun, 14 Aug 2011 23:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkA86fqCnLWv for ; Sun, 14 Aug 2011 23:32:20 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id BC3FB21F8541 for ; Sun, 14 Aug 2011 23:32:20 -0700 (PDT) Received: (qmail 30951 invoked from network); 15 Aug 2011 06:33:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:33:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 14 Aug 2011 23:33:05 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , Torsten Lodderstedt Date: Sun, 14 Aug 2011 23:31:53 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZy7BgMPPKPL7KSQOAnbJwNCUASQBSUo4A Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E46207A.6080404@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 06:32:21 -0000 I'm using my proposed text in -21. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Saturday, August 13, 2011 8:14 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack >=20 > Again, the idea that you can produce a comprehensive description of secur= ity > threat is impractical if you are going to include every browser-based att= ack > and its remedies. OAuth use of browser redirection imports almost every > possible attack vector on the web. That's my point. > People constantly bring up these attack vectors, and in multiple flavors = and > variations, as if *anyone* can produce a complete list of these issues. >=20 > Now, this doesn't mean we should not try to be comprehensive but this can > go on forever. >=20 > The changes to 10.12 seem reasonable with the exception of the new > MUSTs. > I disagree that we should mandate clients to use the state parameter as t= he > only CSRF protection vector, especially in an evolving web environment. W= e > can still include a MUST for verifying that the user redirected to the > authorization server is the same user coming back, and highlight the stat= e > parameter as one way to accomplish that. >=20 > How about: >=20 >=20 > state: OPTIONAL. An opaque value used by the client to maintain state > between the request and redirection. The authorization server includes th= is > value when redirecting the user-agent back to the client. Use of the "sta= te" > parameter is RECOMMENDED for preventing cross-site request forgery as > described in Section 10.12. >=20 >=20 >=20 >=20 > Section 10.12 Cross-Site Request Forgery >=20 >=20 > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP > requests are transmitted from the user-agent of an end-user the server > trusts or has authenticated. CSRF attacks enable the attacker to intermix= the > attacker's security context with that of the resource owner resulting in = a > compromise of either the resource server or of the client application its= elf. >=20 > In the OAuth context, such attacks allow an attacker to inject their own > authorization code or access token into the client, which can result in t= he > client associating the attacker's protected resources to the victim's acc= ount > on the client. Depending on the nature of the client and the protected > resources, this can have undesirable and damaging effects. In order to > prevent such attacks, the client MUST employ CSRF protection. >=20 > It is strongly RECOMMENDED for the client to utilize the "state" request > parameter with authorization requests to the authorization server. When > used for CSRF prevention, the "state" request parameter MUST contain a > non-guessable value, which the client MUST also store with the resource > owner's user-agent in a location accessible only to the client or the res= ource > owner's user-agent (i.e., protected by same-origin policy). For example, = the > client can using a DOM variable, HTTP cookie, or HTML5 client-side storag= e. >=20 >=20 > When redirecting the resource owner's user-agent back to the client, the > authorization server includes the value of the "state" parameter. Upon > receiving the redirection request, the client MUST confirm that returned > value of the "state" parameter matches the value stored with the resource > owner's user-agent. >=20 >=20 > EHL >=20 >=20 >=20 >=20 > From: Torsten Lodderstedt > Date: Fri, 12 Aug 2011 23:58:02 -0700 > To: Eran Hammer-lahav > Cc: Anthony Nadalin , "OAuth WG > (oauth@ietf.org)" > > Subject: Re: [OAUTH-WG] Auth Code Swap Attack >=20 >=20 > > > > > > > > > > > > > > > > Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: > > > > This is really just a flavor of CSRF attacks. I have no > > objections to better documenting it (though I feel the current > > text is already sufficient), but we can't realistically expect > > to identify and close every possible browser-based attack. A new > > one is invented every other week. > > > > > > The problem with this text is that developers who do no > > understand CSRF attacks are not likely to implement it correctly > > with this information. Those who understand it do not need the > > extra verbiage which is more confusing than helpful. > > > > > > > > We are constantly facing the fact that a comprehensive description > > of security threats needs more space than we have in the core draft. > > That's the reason why the security document has 63 pages and that's > > also the reason why we decided to let the core spec refer to this > > document for in-depth explanations. This holds true for this threat > > as well. > > > > regards, > > Torsten. > > > > > > > > > > As for the new requirements, they are insufficient to > > actually accomplish what the authors propose without additional > > requirements on state local storage and verification to complete > > the flow. Also, the proposed text needs clarifications as noted > > below. > > > > > > > > > > > > From: Anthony Nadalin > > Date: Fri, 12 Aug 2011 > > 12:06:36 -0700 > > To: "OAuth WG (oauth@ietf.org)" > > > > Subject: [OAUTH-WG] > > Auth Code Swap Attack > > > > > > > > > > >> > >> > >> > > > > > > > > > > > > > > > > >> > >> > >> > >> Recommended > >> Changes to draft-ietf-oauth-v2 > >> > >> In section 4, request options (e.g. > >> 4.1.1) featuring "state" should change from: > >> > >> state > >> OPTIONAL. > >> An opaque value used by the client to maintain stat= e > >> between the request and callback. The authorization > >> server includes this value when redirecting the > >> user-agent back to the client. > >> > >> to: > >> > >> state > >> REQUIRED. > >> An opaque value used by the client to maintain stat= e > >> between the request and callback. The authorization > >> server includes this value when redirecting the > >> user-agent back to the client. The encoded value > >> SHOULD enable the client application to determine > >> the user-context that was active at the time of the > >> request (see section 10.12). The value MUST NOT be > >> guessable or predictable, and MUST be kept > >> confidential. > >> > >> > >> > >> > >> > > > > > > > > Making the parameter required without making its usage > > required (I.e. "value SHOULD enable") accomplishes nothing. > > Also, what does "MUST be kept confidential" mean? Confidential > > from what? Why specify an "encoded value"? > > > > > > > > > > > > > > >> > >> > >> > >> Section 10.12 Cross-Site Request > >> Forgery > >> > >> Change to: > >> > >> Cross-site > >> request forgery (CSRF) is a web-based attack whereb= y > >> HTTP requests are transmitted from the user-agent o= f > >> an end-user the server trusts or has authenticated. > >> CSRF attacks enable the attacker to intermix the > >> attacker's security context with that of > >> the resource owner resulting in a compromise of > >> either the resource server or of the client > >> application itself. In the OAuth context, > >> such attacks allow an attacker to inject their own > >> authorization code or access token into a client, > >> which can result in the client using an access toke= n > >> associated with the attacker's account rather than > >> the victim's. Depending on the nature of the client > >> and the protected resources, this can have > >> undesirable and damaging effects. > >> > >> In order to prevent such attacks, the client > >> application MUST encode a non-guessable, > >> confidential end-user artifact and submit as the > >> "state" parameter to authorization and access token > >> requests to the authorization server. The client > >> MUST keep the state value in a location accessible > >> only by the client or the user-agent (i.e., > >> protected by same-origin policy), for example, usin= g > >> a DOM variable, HTTP cookie, or HTML5 client-side > >> storage. > >> > >> The authorization server includes the value of the > >> "state" parameter when redirecting the user-agent > >> back to the client. Upon receiving a redirect, the > >> client application MUST confirm that returned value > >> of "state" corresponds to the state value of the > >> user-agent's user session. If the end-user session > >> represents an authenticated user-identity, the > >> client MUST ensure that the user-identity has NOT > >> changed. > >> > >> > >> > >> > >> > > > > > > > > The above text uses 'user-context' and this 'user-identity'. > > Neither term is defined. > > > > > > EHL > > > > > > > > _______________________________________________ > >OAuth mailing list > >OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Aug 14 23:40:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C345C21F857D for ; Sun, 14 Aug 2011 23:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSoKjP8BixyZ for ; Sun, 14 Aug 2011 23:40:27 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id D2C7521F8574 for ; Sun, 14 Aug 2011 23:40:27 -0700 (PDT) Received: (qmail 3894 invoked from network); 15 Aug 2011 06:41:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:41:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 14 Aug 2011 23:41:11 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sun, 14 Aug 2011 23:40:00 -0700 Thread-Topic: couple minor spec issues Thread-Index: AQHMS6QtMsuj60qNLUK/U1Pu7gq3j5UAReQAgB1IzxCAAAXHYA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDDC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CDD8@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CDD8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] couple minor spec issues X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 06:40:28 -0000 > On 7/26/11 9:56 AM, "Casey Lucas" wrote: > 2. Section 6 Refreshing an Access Token seems to conflict with itself > concerning token scope: >=20 > "The requested scope MUST be equal or lesser than the scope originally > granted by the resource owner, and if omitted is treated as equal to the > scope originally granted by the resource owner." >=20 >=20 > Yet the last sentence in that section states: >=20 > "If a new refresh token is issued, its scope MUST be identical to that of= the > refresh token included in the request." The identical scope is only for the refresh token, not the access token bei= ng refreshed. Clarified: If a new refresh token is issued, the refresh token scope MUST be i= dentical to that of the refresh token included by the client in the request. EHL From eran@hueniverse.com Sun Aug 14 23:49:48 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A7421F8834 for ; Sun, 14 Aug 2011 23:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpCrWGVqfq1l for ; Sun, 14 Aug 2011 23:49:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 8698321F87FA for ; Sun, 14 Aug 2011 23:49:47 -0700 (PDT) Received: (qmail 9952 invoked from network); 15 Aug 2011 06:50:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:50:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 14 Aug 2011 23:50:32 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sun, 14 Aug 2011 23:49:20 -0700 Thread-Topic: [draft-ietf-oauth] Removed a repeated sentence in 3.1.2.2 (#1) Thread-Index: Acxafv+73OTdUKHPTvCfaV3kPllGAAAmFCag Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDDD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: alexbilbie Subject: Re: [OAUTH-WG] [draft-ietf-oauth] Removed a repeated sentence in 3.1.2.2 (#1) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 06:49:48 -0000 UmVjZWl2ZWQgdmlhIGdpdGh1YjoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBhbGV4YmlsYmllIFttYWlsdG86cmVwbHkraS0xNDAyOTc5LQ0KPiBlNjRlZWQxNTVkZGRj MzE5MjJmZDJhMmFmY2Y1MTU0MGE2MTE5NTZhQHJlcGx5LmdpdGh1Yi5jb21dDQo+IFNlbnQ6IFN1 bmRheSwgQXVndXN0IDE0LCAyMDExIDU6MzggQU0NCj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2DQo+ IFN1YmplY3Q6IFtkcmFmdC1pZXRmLW9hdXRoXSBSZW1vdmVkIGEgcmVwZWF0ZWQgc2VudGVuY2Ug aW4gMy4xLjIuMiAoIzEpDQo+IA0KPiBIZWxsbywNCj4gDQo+IEkgY2hhbmdlZCB0aGUgZmlyc3Qg cGFyYWdyYXBoIG9mIHNlY3Rpb24gMy4xLjIuMiBmcm9tOg0KPiANCj4gICAgIFRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgcHVibGljIGNsaWVudHMgdG8gcmVnaXN0ZXINCj4g ICAgIHRoZWlyIHJlZGlyZWN0aW9uIFVSSSwgTVVTVCByZXF1aXJlIGFsbCBjbGllbnRzIHRvIHJl Z2lzdGVyIHRoZWlyDQo+ICAgICByZWRpcmVjdGlvbiBVUkkgcHJpb3IgdG8gdXRpbGl6aW5nIHRo ZSBpbXBsaWNpdCBncmFudCB0eXBlLCBhbmQNCj4gICAgIFNIT1VMRCByZXF1aXJlIGFsbCBjbGll bnRzIHRvIHJlZ2lzdGVyIHRoZWlyIHJlZGlyZWN0aW9uIFVSSSBwcmlvciB0bw0KPiAgICAgdXRp bGl6aW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQgdHlwZS4NCj4gDQo+IHRvOg0KPiAN Cj4gICAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVpcmUgYWxsIGNsaWVudHMg dG8gcmVnaXN0ZXIgdGhlaXINCj4gICAgIHJlZGlyZWN0aW9uIFVSSSBwcmlvciB0byB1dGlsaXpp bmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUsIGFuZA0KPiAgICAgU0hPVUxEIHJlcXVpcmUgYWxs IGNsaWVudHMgdG8gcmVnaXN0ZXIgdGhlaXIgcmVkaXJlY3Rpb24gVVJJIHByaW9yIHRvDQo+ICAg ICB1dGlsaXppbmcgdGhlIGF1dGhvcml6YXRpb24gY29kZSBncmFudCB0eXBlLg0KPiANCj4gSSB0 aGluayB0aGUgcGhyYXNlICJNVVNUIHJlcXVpcmUgcHVibGljIGNsaWVudHMgdG8gcmVnaXN0ZXIg dGhlaXIgcmVkaXJlY3Rpb24NCj4gVVJJIiB3YXMgdW5uZWNlc3Nhcnkgd2hlbiBmb2xsb3dlZCBi eSAiTVVTVCByZXF1aXJlIGFsbCBjbGllbnRzIHRvIHJlZ2lzdGVyDQo+IHRoZWlyIHJlZGlyZWN0 aW9uIFVSSSINCg0KQ2hhbmdlZCB0bzoNCg0KICAgICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgU0hPVUxEIHJlcXVpcmUgYWxsIGNsaWVudHMgdG8gcmVnaXN0ZXIgdGhlaXIgcmVk aXJlY3Rpb24gVVJJDQogICAgICAgICAgICAgIHByaW9yIHRvIHVzaW5nIHRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50LCBhbmQgTVVTVCByZXF1aXJlIHRoZSBmb2xsb3dpbmcgY2xpZW50cyB0bw0K ICAgICAgICAgICAgICByZWdpc3RlciB0aGVpciByZWRpcmVjdGlvbiBVUkk6DQoNCiAgICAgICAg ICAgICAgbyAgICBQdWJsaWMgY2xpZW50cy4NCiAgICAgICAgICAgICAgbyAgICBDb25maWRlbnRp YWwgY2xpZW50cyB1dGlsaXppbmcgdGhlIGltcGxpY2l0IGdyYW50IHR5cGUuDQoNCkVITA0K From eran@hueniverse.com Sun Aug 14 23:57:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2707611E8081 for ; Sun, 14 Aug 2011 23:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72vx8IaCUeYy for ; Sun, 14 Aug 2011 23:57:36 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id AB14F11E8082 for ; Sun, 14 Aug 2011 23:57:36 -0700 (PDT) Received: (qmail 15140 invoked from network); 15 Aug 2011 06:58:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:58:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 14 Aug 2011 23:58:21 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , Torsten Lodderstedt Date: Sun, 14 Aug 2011 23:57:10 -0700 Thread-Topic: [OAUTH-WG] redirect uri validation Thread-Index: AcxK8ixmC0aAySH5S26xwHZeEopeLwQH5tlwAAGqMzA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDDE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345021F37877@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DAAEA.7090304@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CDD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "torsten@lodderstedt-online.de" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] redirect uri validation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 06:57:37 -0000 QWRkZWQgdG8gMS40LjI6DQoNCiAgICAgICAgICAgIFdoZW4gaXNzdWluZyBhbiBpbXBsaWNpdCBn cmFudCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRvZXMgbm90IGF1dGhlbnRpY2F0ZSB0aGUN CiAgICAgICAgICAgIGNsaWVudCBhbmQgW1tpbiBzb21lIGNhc2VzXV0sIHRoZSBjbGllbnQgaWRl bnRpdHkgW1tjYW5dXSBiZSB2ZXJpZmllZCB2aWEgdGhlIHJlZGlyZWN0aW9uIFVSSQ0KICAgICAg ICAgICAgdXNlZCB0byBkZWxpdmVyIHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4gVGhl IGFjY2VzcyB0b2tlbiBtYXkgYmUgZXhwb3NlZCB0byB0aGUNCiAgICAgICAgICAgIHJlc291cmNl IG93bmVyIG9yIG90aGVyIGFwcGxpY2F0aW9ucyB3aXRoIGFjY2VzcyB0byB0aGUgcmVzb3VyY2Ug b3duZXIncyB1c2VyLWFnZW50Lg0KDQpIb3BlIHRoaXMgaXMgc3VmZmljaWVudC4NCg0KRUhMDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBFcmFu IEhhbW1lci1MYWhhdg0KPiBTZW50OiBTdW5kYXksIEF1Z3VzdCAxNCwgMjAxMSAxMTowOSBQTQ0K PiBUbzogVG9yc3RlbiBMb2RkZXJzdGVkdA0KPiBDYzogdG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxp bmUuZGU7IG9hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHJlZGlyZWN0 IHVyaSB2YWxpZGF0aW9uDQo+IA0KPiBXaGVyZSB3b3VsZCB5b3Ugc3VnZ2VzdCBJIGFkZCB0aGlz Pw0KPiANCj4gRUhMDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJv bTogVG9yc3RlbiBMb2RkZXJzdGVkdCBbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0XQ0K PiA+IFNlbnQ6IE1vbmRheSwgSnVseSAyNSwgMjAxMSAxMDo0MiBBTQ0KPiA+IFRvOiBFcmFuIEhh bW1lci1MYWhhdg0KPiA+IENjOiB0b3JzdGVuQGxvZGRlcnN0ZWR0LW9ubGluZS5kZTsgb2F1dGhA aWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSByZWRpcmVjdCB1cmkgdmFsaWRh dGlvbg0KPiA+DQo+ID4gSGkgRXJhbiwNCj4gPg0KPiA+ID4+PiBPQXV0aCAxLjAgd2FzIGhpZ2hs eSBjcml0aWNpemVkIGZvciBmYWlsaW5nIHRvIGFkZHJlc3MgY2xpZW50DQo+ID4gPj4+IGlkZW50 aXR5IGluIHB1YmxpYyBjbGllbnRzLiBJIGJlbGlldmUgT0F1dGggMi4wIG9mZmVycyBhIG11Y2gN Cj4gPiA+Pj4gYmV0dGVyIHN0b3J5LCB3aXRoaW4gdGhlIGJvdW5kYXJpZXM+b2Ygd2hhdOKAmXMg cG9zc2libGUgdG9kYXkuDQo+ID4gPj4gQWdyZWVkLiBJIHRoaW5rIHdlIG11c3QgaG9uZXN0bHkg ZGlzY3VzcyB0aGUgdmFsdWUgb2YgY2xpZW50DQo+ID4gPj4gYXV0aGVudGljYXRpb24vaWRlbnRp ZmljYXRpb24gaXRzZWxmLiBJIHBlcnNvbmFsbHkgdGhpbmsgaXQgaXMNCj4gPiA+PiBvdmVyLWVt cGhhemlzZWQgcmlnaHQgbm93LiBUaGUgc3RyZW5ndGggb2YgT0F1dGggMi4wIGlzIHRoYXQgaXQN Cj4gPiA+PiBhbGxvd3Mgc29sdXRpb25zIHdoZXJlIG5laXRoZXIgY2xpZW50IG5vciByZXNvdXJj ZSBzZXJ2ZXIgaGF2ZQ0KPiA+ID4+IGFjY2VzcyBvcg0KPiA+IGRvIHN0b3JlIGVuZC11c2VyIGNy ZWRlbnRpYWxzLg0KPiA+ID4+IENsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBuaWNlIGJ1dCBub3Qg dGhlIG1haW4gZmVhdHVyZS4NCj4gPiA+IERvIHlvdSBoYXZlIGFueSBzcGVjaWZpYyBzdWdnZXN0 aW9ucyBub3QgYWxyZWFkeSBtZW50aW9uZWQgb24gdGhlIGxpc3Q/DQo+ID4NCj4gPiBJIHdvdWxk IHN1Z2dlc3QgdG8gbWVudGlvbiB0aGF0IHdoaWxlIGFuIGludmFsaWQgcmVkaXJlY3RfdXJpDQo+ ID4gaW5kaWNhdGVzIGEgY291bnRlcmZlaXQgY2xpZW50cyBhIHZhbGlkIHJlZGlyZWN0IGRvZXMg bm90IHByb3ZlIHRoZSBjYWxsaW5nDQo+IGNsaWVudCdzIGlkZW50aXR5Lg0KPiA+DQo+ID4gcmVn YXJkcywNCj4gPiBUb3JzdGVuLg0KPiA+DQo+ID4NCj4gPiA+IEVITA0KPiA+ID4NCj4gPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBPQXV0 aCBtYWlsaW5nIGxpc3QNCj4gPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= From tonynad@microsoft.com Mon Aug 15 07:50:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C106F21F8BFE for ; Mon, 15 Aug 2011 07:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4q89-7aRKUp for ; Mon, 15 Aug 2011 07:50:41 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id A534B21F8BF3 for ; Mon, 15 Aug 2011 07:50:41 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 15 Aug 2011 07:51:27 -0700 Received: from VA3EHSOBE008.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Aug 2011 07:51:26 -0700 Received: from mail143-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 15 Aug 2011 14:51:25 +0000 Received: from mail143-va3 (localhost.localdomain [127.0.0.1]) by mail143-va3-R.bigfish.com (Postfix) with ESMTP id 8C83C18900FB for ; Mon, 15 Aug 2011 14:51:25 +0000 (UTC) X-SpamScore: -31 X-BigFish: PS-31(zz9371K542M1432Nzz1202h1082kzz8275ch1033IL8275bh8275dhz31h2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT013.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail143-va3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT013.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail143-va3 (localhost.localdomain [127.0.0.1]) by mail143-va3 (MessageSwitch) id 131341988579117_19317; Mon, 15 Aug 2011 14:51:25 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.238]) by mail143-va3.bigfish.com (Postfix) with ESMTP id F3F79F68055; Mon, 15 Aug 2011 14:51:24 +0000 (UTC) Received: from SN2PRD0302HT013.namprd03.prod.outlook.com (207.46.4.139) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 15 Aug 2011 14:51:23 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.5.112]) by SN2PRD0302HT013.namprd03.prod.outlook.com ([10.27.90.203]) with mapi id 14.01.0225.064; Mon, 15 Aug 2011 14:51:22 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , "eran@sled.com" , Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZImYoC2iZvOhxR/+zEXUukLHDogAF8TGAABMLNgAAEVWRAABSVdeAABFT4dA= Date: Mon, 15 Aug 2011 14:51:21 +0000 Message-ID: References: <4E46207A.6080404@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.0.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT013.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%SLED.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LODDERSTEDT.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 14:50:42 -0000 That's nice, four people come up with text and you decide to use your text.= Making state optional does nothing to fix the protocol issue, people will = get this wrong and have. Our developers have been through this and agreed u= pon the text that was generated. They find the text in the current draft un= acceptable and confusing and think that new text is acceptable.=20 So -1 on your text -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Sunday, August 14, 2011 11:32 PM To: eran@sled.com; Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I'm using my proposed text in -21. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Eran Hammer-Lahav > Sent: Saturday, August 13, 2011 8:14 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack >=20 > Again, the idea that you can produce a comprehensive description of=20 > security threat is impractical if you are going to include every=20 > browser-based attack and its remedies. OAuth use of browser=20 > redirection imports almost every possible attack vector on the web. That'= s my point. > People constantly bring up these attack vectors, and in multiple=20 > flavors and variations, as if *anyone* can produce a complete list of the= se issues. >=20 > Now, this doesn't mean we should not try to be comprehensive but this=20 > can go on forever. >=20 > The changes to 10.12 seem reasonable with the exception of the new=20 > MUSTs. > I disagree that we should mandate clients to use the state parameter=20 > as the only CSRF protection vector, especially in an evolving web=20 > environment. We can still include a MUST for verifying that the user=20 > redirected to the authorization server is the same user coming back,=20 > and highlight the state parameter as one way to accomplish that. >=20 > How about: >=20 >=20 > state: OPTIONAL. An opaque value used by the client to maintain state=20 > between the request and redirection. The authorization server includes=20 > this value when redirecting the user-agent back to the client. Use of the= "state" > parameter is RECOMMENDED for preventing cross-site request forgery as=20 > described in Section 10.12. >=20 >=20 >=20 >=20 > Section 10.12 Cross-Site Request Forgery >=20 >=20 > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP=20 > requests are transmitted from the user-agent of an end-user the server=20 > trusts or has authenticated. CSRF attacks enable the attacker to=20 > intermix the attacker's security context with that of the resource=20 > owner resulting in a compromise of either the resource server or of the c= lient application itself. >=20 > In the OAuth context, such attacks allow an attacker to inject their=20 > own authorization code or access token into the client, which can=20 > result in the client associating the attacker's protected resources to=20 > the victim's account on the client. Depending on the nature of the=20 > client and the protected resources, this can have undesirable and=20 > damaging effects. In order to prevent such attacks, the client MUST emplo= y CSRF protection. >=20 > It is strongly RECOMMENDED for the client to utilize the "state"=20 > request parameter with authorization requests to the authorization=20 > server. When used for CSRF prevention, the "state" request parameter=20 > MUST contain a non-guessable value, which the client MUST also store=20 > with the resource owner's user-agent in a location accessible only to=20 > the client or the resource owner's user-agent (i.e., protected by=20 > same-origin policy). For example, the client can using a DOM variable, HT= TP cookie, or HTML5 client-side storage. >=20 >=20 > When redirecting the resource owner's user-agent back to the client,=20 > the authorization server includes the value of the "state" parameter.=20 > Upon receiving the redirection request, the client MUST confirm that=20 > returned value of the "state" parameter matches the value stored with=20 > the resource owner's user-agent. >=20 >=20 > EHL >=20 >=20 >=20 >=20 > From: Torsten Lodderstedt > Date: Fri, 12 Aug 2011 23:58:02 -0700 > To: Eran Hammer-lahav > Cc: Anthony Nadalin , "OAuth WG=20 > (oauth@ietf.org)" > > Subject: Re: [OAUTH-WG] Auth Code Swap Attack >=20 >=20 > > > > > > > > > > > > > > > > Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: > > > > This is really just a flavor of CSRF attacks. I have no > > objections to better documenting it (though I feel the current > > text is already sufficient), but we can't realistically expect > > to identify and close every possible browser-based attack. A new > > one is invented every other week. > > > > > > The problem with this text is that developers who do no > > understand CSRF attacks are not likely to implement it correctly > > with this information. Those who understand it do not need the > > extra verbiage which is more confusing than helpful. > > > > > > > > We are constantly facing the fact that a comprehensive description > > of security threats needs more space than we have in the core draft. > > That's the reason why the security document has 63 pages and that's > > also the reason why we decided to let the core spec refer to this > > document for in-depth explanations. This holds true for this threat > > as well. > > > > regards, > > Torsten. > > > > > > > > > > As for the new requirements, they are insufficient to > > actually accomplish what the authors propose without additional > > requirements on state local storage and verification to complete > > the flow. Also, the proposed text needs clarifications as noted > > below. > > > > > > > > > > > > From: Anthony Nadalin > > Date: Fri, 12 Aug 2011 > > 12:06:36 -0700 > > To: "OAuth WG (oauth@ietf.org)" > > > > Subject: [OAUTH-WG] > > Auth Code Swap Attack > > > > > > > > > > >> > >> > >> > > > > > > > > > > > > > > > > >> > >> > >> > >> Recommended > >> Changes to draft-ietf-oauth-v2 > >> > >> In section 4, request options (e.g. > >> 4.1.1) featuring "state" should change from: > >> > >> state > >> OPTIONAL. > >> An opaque value used by the client to maintain stat= e > >> between the request and callback. The authorization > >> server includes this value when redirecting the > >> user-agent back to the client. > >> > >> to: > >> > >> state > >> REQUIRED. > >> An opaque value used by the client to maintain stat= e > >> between the request and callback. The authorization > >> server includes this value when redirecting the > >> user-agent back to the client. The encoded value > >> SHOULD enable the client application to determine > >> the user-context that was active at the time of the > >> request (see section 10.12). The value MUST NOT be > >> guessable or predictable, and MUST be kept > >> confidential. > >> > >> > >> > >> > >> > > > > > > > > Making the parameter required without making its usage > > required (I.e. "value SHOULD enable") accomplishes nothing. > > Also, what does "MUST be kept confidential" mean? Confidential > > from what? Why specify an "encoded value"? > > > > > > > > > > > > > > >> > >> > >> > >> Section 10.12 Cross-Site Request > >> Forgery > >> > >> Change to: > >> > >> Cross-site > >> request forgery (CSRF) is a web-based attack whereb= y > >> HTTP requests are transmitted from the user-agent o= f > >> an end-user the server trusts or has authenticated. > >> CSRF attacks enable the attacker to intermix the > >> attacker's security context with that of > >> the resource owner resulting in a compromise of > >> either the resource server or of the client > >> application itself. In the OAuth context, > >> such attacks allow an attacker to inject their own > >> authorization code or access token into a client, > >> which can result in the client using an access toke= n > >> associated with the attacker's account rather than > >> the victim's. Depending on the nature of the client > >> and the protected resources, this can have > >> undesirable and damaging effects. > >> > >> In order to prevent such attacks, the client > >> application MUST encode a non-guessable, > >> confidential end-user artifact and submit as the > >> "state" parameter to authorization and access token > >> requests to the authorization server. The client > >> MUST keep the state value in a location accessible > >> only by the client or the user-agent (i.e., > >> protected by same-origin policy), for example, usin= g > >> a DOM variable, HTTP cookie, or HTML5 client-side > >> storage. > >> > >> The authorization server includes the value of the > >> "state" parameter when redirecting the user-agent > >> back to the client. Upon receiving a redirect, the > >> client application MUST confirm that returned value > >> of "state" corresponds to the state value of the > >> user-agent's user session. If the end-user session > >> represents an authenticated user-identity, the > >> client MUST ensure that the user-identity has NOT > >> changed. > >> > >> > >> > >> > >> > > > > > > > > The above text uses 'user-context' and this 'user-identity'. > > Neither term is defined. > > > > > > EHL > > > > > > > > _______________________________________________ > >OAuth mailing list > >OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From barryleiba.mailing.lists@gmail.com Mon Aug 15 08:05:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ABD21F8C35 for ; Mon, 15 Aug 2011 08:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.041 X-Spam-Level: X-Spam-Status: No, score=-103.041 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA-8RRp7gBv8 for ; Mon, 15 Aug 2011 08:05:59 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0657521F8C31 for ; Mon, 15 Aug 2011 08:05:58 -0700 (PDT) Received: by yie12 with SMTP id 12so3667969yie.31 for ; Mon, 15 Aug 2011 08:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GIH438fvFR7k970bHg5nz8i01f+u9K9dg9wh6MxF1PQ=; b=i0+TjRzVBQWiaHKznPanWeMlQy3dIGRJrfps3OjRdl/79QqzU1EcQVx/RmAJ+erToj 3AEwKFX++Y2NhzreAreKgt+LA+kdCku8kkWR/PL6JRJNL1q46nHzpVfe5PJZWMjyk3y1 ZGnTLjVMMO7q0DIowXhNsSUlq3naodnW/t5ho= MIME-Version: 1.0 Received: by 10.236.115.73 with SMTP id d49mr12429228yhh.245.1313420804553; Mon, 15 Aug 2011 08:06:44 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Mon, 15 Aug 2011 08:06:44 -0700 (PDT) In-Reply-To: References: <4E46207A.6080404@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 15 Aug 2011 11:06:44 -0400 X-Google-Sender-Auth: fTuIEZV67rrAO55rkhZXjX8Owqo Message-ID: From: Barry Leiba To: Anthony Nadalin Content-Type: text/plain; charset=ISO-8859-1 Cc: "eran@sled.com" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:05:59 -0000 On Mon, Aug 15, 2011 at 10:51 AM, Anthony Nadalin wrote: > That's nice, four people come up with text and you decide to use your text. > Making state optional does nothing to fix the protocol issue, people will get > this wrong and have. Our developers have been through this and agreed > upon the text that was generated. They find the text in the current draft > unacceptable and confusing and think that new text is acceptable. I have to agree with what Tony says above. The text proposed in his message was agreed upon by several WG participants, and unless there's some significant objection to it I think we should use it in the -21 version, subject to final WG review. Barry, as chair From eran@hueniverse.com Mon Aug 15 08:07:49 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E33421F8B70 for ; Mon, 15 Aug 2011 08:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC-hFpx6ciAF for ; Mon, 15 Aug 2011 08:07:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id BB04D21F8B32 for ; Mon, 15 Aug 2011 08:07:47 -0700 (PDT) Received: (qmail 14157 invoked from network); 15 Aug 2011 15:08:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 15:08:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 15 Aug 2011 08:08:20 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , Torsten Lodderstedt Date: Mon, 15 Aug 2011 08:07:08 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZImYoC2iZvOhxR/+zEXUukLHDogAF8TGAABMLNgAAEVWRAABSVdeAABFT4dAAADzeYA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CE49@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E46207A.6080404@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:07:49 -0000 (please don't use my sled.com work email address) I'll ask the chairs to open an issue for this. My proposed requires CSRF protected without adding additional requirements,= and therefore, is within the scope of my editorial discretion. IOW, my tex= t is already well-within working group consensus. Your text has not establi= shed consensus, and I have listed actual issues with the proposed text whic= h none of the authors have addressed so far. I'm opposed to making the state parameter required because it is meaningles= s without addition specification of exactly how to use it (i.e. achieve int= eroperable implementation), which is clearly outside the scope of this docu= ment. The "new" attack described is in no way more severe than the existing CSRF = attack described in -20. You have provided no justification for making this= significant normative change other than this "new" CSRF attack, and the cu= rrent text is based on actual working group consensus. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Monday, August 15, 2011 7:51 AM > To: Eran Hammer-Lahav; eran@sled.com; Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Auth Code Swap Attack >=20 > That's nice, four people come up with text and you decide to use your tex= t. > Making state optional does nothing to fix the protocol issue, people will= get > this wrong and have. Our developers have been through this and agreed > upon the text that was generated. They find the text in the current draft > unacceptable and confusing and think that new text is acceptable. >=20 > So -1 on your text >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Sunday, August 14, 2011 11:32 PM > To: eran@sled.com; Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack >=20 > I'm using my proposed text in -21. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Saturday, August 13, 2011 8:14 AM > > To: Torsten Lodderstedt > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > Again, the idea that you can produce a comprehensive description of > > security threat is impractical if you are going to include every > > browser-based attack and its remedies. OAuth use of browser > > redirection imports almost every possible attack vector on the web. Tha= t's > my point. > > People constantly bring up these attack vectors, and in multiple > > flavors and variations, as if *anyone* can produce a complete list of t= hese > issues. > > > > Now, this doesn't mean we should not try to be comprehensive but this > > can go on forever. > > > > The changes to 10.12 seem reasonable with the exception of the new > > MUSTs. > > I disagree that we should mandate clients to use the state parameter > > as the only CSRF protection vector, especially in an evolving web > > environment. We can still include a MUST for verifying that the user > > redirected to the authorization server is the same user coming back, > > and highlight the state parameter as one way to accomplish that. > > > > How about: > > > > > > state: OPTIONAL. An opaque value used by the client to maintain state > > between the request and redirection. The authorization server includes > > this value when redirecting the user-agent back to the client. Use of t= he > "state" > > parameter is RECOMMENDED for preventing cross-site request forgery as > > described in Section 10.12. > > > > > > > > > > Section 10.12 Cross-Site Request Forgery > > > > > > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP > > requests are transmitted from the user-agent of an end-user the server > > trusts or has authenticated. CSRF attacks enable the attacker to > > intermix the attacker's security context with that of the resource > > owner resulting in a compromise of either the resource server or of the > client application itself. > > > > In the OAuth context, such attacks allow an attacker to inject their > > own authorization code or access token into the client, which can > > result in the client associating the attacker's protected resources to > > the victim's account on the client. Depending on the nature of the > > client and the protected resources, this can have undesirable and > > damaging effects. In order to prevent such attacks, the client MUST emp= loy > CSRF protection. > > > > It is strongly RECOMMENDED for the client to utilize the "state" > > request parameter with authorization requests to the authorization > > server. When used for CSRF prevention, the "state" request parameter > > MUST contain a non-guessable value, which the client MUST also store > > with the resource owner's user-agent in a location accessible only to > > the client or the resource owner's user-agent (i.e., protected by > > same-origin policy). For example, the client can using a DOM variable, = HTTP > cookie, or HTML5 client-side storage. > > > > > > When redirecting the resource owner's user-agent back to the client, > > the authorization server includes the value of the "state" parameter. > > Upon receiving the redirection request, the client MUST confirm that > > returned value of the "state" parameter matches the value stored with > > the resource owner's user-agent. > > > > > > EHL > > > > > > > > > > From: Torsten Lodderstedt > > Date: Fri, 12 Aug 2011 23:58:02 -0700 > > To: Eran Hammer-lahav > > Cc: Anthony Nadalin , "OAuth WG > > (oauth@ietf.org)" > > > > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > > > > > > > > > > > > > > > > > > > > > > > > > Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: > > > > > > This is really just a flavor of CSRF attacks. I have no > > > objections to better documenting it (though I feel the current > > > text is already sufficient), but we can't realistically expect > > > to identify and close every possible browser-based attack. A n= ew > > > one is invented every other week. > > > > > > > > > The problem with this text is that developers who do no > > > understand CSRF attacks are not likely to implement it correct= ly > > > with this information. Those who understand it do not need the > > > extra verbiage which is more confusing than helpful. > > > > > > > > > > > > We are constantly facing the fact that a comprehensive description > > > of security threats needs more space than we have in the core draf= t. > > > That's the reason why the security document has 63 pages and that'= s > > > also the reason why we decided to let the core spec refer to this > > > document for in-depth explanations. This holds true for this threa= t > > > as well. > > > > > > regards, > > > Torsten. > > > > > > > > > > > > > > > As for the new requirements, they are insufficient to > > > actually accomplish what the authors propose without additiona= l > > > requirements on state local storage and verification to comple= te > > > the flow. Also, the proposed text needs clarifications as note= d > > > below. > > > > > > > > > > > > > > > > > > From: Anthony Nadalin > > > Date: Fri, 12 Aug 2011 > > > 12:06:36 -0700 > > > To: "OAuth WG (oauth@ietf.org)" > > > > > > Subject: [OAUTH-WG] > > > Auth Code Swap Attack > > > > > > > > > > > > > > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > >> > > >> > > >> > > >> Recommended > > >> Changes to draft-ietf-oauth-v2 > > >> > > >> In section 4, request options (e.g. > > >> 4.1.1) featuring "state" should change from: > > >> > > >> state > > >> OPTIONAL. > > >> An opaque value used by the client to maintain st= ate > > >> between the request and callback. The authorizati= on > > >> server includes this value when redirecting the > > >> user-agent back to the client. > > >> > > >> to: > > >> > > >> state > > >> REQUIRED. > > >> An opaque value used by the client to maintain st= ate > > >> between the request and callback. The authorizati= on > > >> server includes this value when redirecting the > > >> user-agent back to the client. The encoded value > > >> SHOULD enable the client application to determine > > >> the user-context that was active at the time of t= he > > >> request (see section 10.12). The value MUST NOT = be > > >> guessable or predictable, and MUST be kept > > >> confidential. > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > Making the parameter required without making its usage > > > required (I.e. "value SHOULD enable") accomplishes nothing. > > > Also, what does "MUST be kept confidential" mean? Confidential > > > from what? Why specify an "encoded value"? > > > > > > > > > > > > > > > > > > > > > >> > > >> > > >> > > >> Section 10.12 Cross-Site Request > > >> Forgery > > >> > > >> Change to: > > >> > > >> Cross-site > > >> request forgery (CSRF) is a web-based attack wher= eby > > >> HTTP requests are transmitted from the user-agent= of > > >> an end-user the server trusts or has authenticate= d. > > >> CSRF attacks enable the attacker to intermix the > > >> attacker's security context with that of > > >> the resource owner resulting in a compromise of > > >> either the resource server or of the client > > >> application itself. In the OAuth context, > > >> such attacks allow an attacker to inject their ow= n > > >> authorization code or access token into a client, > > >> which can result in the client using an access to= ken > > >> associated with the attacker's account rather tha= n > > >> the victim's. Depending on the nature of the clie= nt > > >> and the protected resources, this can have > > >> undesirable and damaging effects. > > >> > > >> In order to prevent such attacks, the client > > >> application MUST encode a non-guessable, > > >> confidential end-user artifact and submit as the > > >> "state" parameter to authorization and access tok= en > > >> requests to the authorization server. The client > > >> MUST keep the state value in a location accessibl= e > > >> only by the client or the user-agent (i.e., > > >> protected by same-origin policy), for example, us= ing > > >> a DOM variable, HTTP cookie, or HTML5 client-side > > >> storage. > > >> > > >> The authorization server includes the value of th= e > > >> "state" parameter when redirecting the user-agent > > >> back to the client. Upon receiving a redirect, th= e > > >> client application MUST confirm that returned val= ue > > >> of "state" corresponds to the state value of the > > >> user-agent's user session. If the end-user sessio= n > > >> represents an authenticated user-identity, the > > >> client MUST ensure that the user-identity has NOT > > >> changed. > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > The above text uses 'user-context' and this 'user-identity'. > > > Neither term is defined. > > > > > > > > > EHL > > > > > > > > > > > > _______________________________________________ > > >OAuth mailing list > > >OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 From eran@hueniverse.com Mon Aug 15 08:10:53 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F7021F8C52 for ; Mon, 15 Aug 2011 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5BRGnqQCQqO for ; Mon, 15 Aug 2011 08:10:52 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A944921F8C50 for ; Mon, 15 Aug 2011 08:10:52 -0700 (PDT) Received: (qmail 20997 invoked from network); 15 Aug 2011 15:11:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 15:11:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 15 Aug 2011 08:11:23 -0700 From: Eran Hammer-Lahav To: Barry Leiba , Anthony Nadalin Date: Mon, 15 Aug 2011 08:10:11 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxbXPSiDHdMCdNtRUqP4pa88ufKlAAABdXQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CE4A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E46207A.6080404@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:10:53 -0000 Please go back to the beginning of the thread where I expressed (not as edi= tor) my "significant objection" and listed actual problems with the propose= d text, as well as the entire justification for making it. In addition, my text is well within my discretion for making non-normative = editorial changes. EHL > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com > [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba > Sent: Monday, August 15, 2011 8:07 AM > To: Anthony Nadalin > Cc: Eran Hammer-Lahav; eran@sled.com; Torsten Lodderstedt; OAuth WG > (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack >=20 > On Mon, Aug 15, 2011 at 10:51 AM, Anthony Nadalin > wrote: > > That's nice, four people come up with text and you decide to use your t= ext. > > Making state optional does nothing to fix the protocol issue, people > > will get this wrong and have. Our developers have been through this > > and agreed upon the text that was generated. They find the text in the > > current draft unacceptable and confusing and think that new text is > acceptable. >=20 > I have to agree with what Tony says above. The text proposed in his > message was agreed upon by several WG participants, and unless there's > some significant objection to it I think we should use it in the -21 vers= ion, > subject to final WG review. >=20 > Barry, as chair From trac+oauth@trac.tools.ietf.org Mon Aug 15 08:17:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E1B21F8B50 for ; Mon, 15 Aug 2011 08:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NzjYKTNiH3h for ; Mon, 15 Aug 2011 08:17:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A3A8121F8B49 for ; Mon, 15 Aug 2011 08:17:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QsyvT-0004D8-7t; Mon, 15 Aug 2011 08:18:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Mon, 15 Aug 2011 15:18:03 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/23 Message-ID: <063.7f8c809279a65936aee8fa160f5f16a8@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #23: Auth Code Swap Attack (CSRF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:17:19 -0000 #23: Auth Code Swap Attack (CSRF) See discussion thread beginning here: http://www.ietf.org/mail-archive/web/oauth/current/msg07233.html Text proposed by Tony, Yaron, Thorsten, and Phil; proposed text makes "state" option required. Eran objects and proposes alternative text that does not make "state" required. -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: In WG Last Call | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From barryleiba.mailing.lists@gmail.com Mon Aug 15 08:24:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2031B21F8C1E for ; Mon, 15 Aug 2011 08:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.04 X-Spam-Level: X-Spam-Status: No, score=-103.04 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSK8WrL6SdlZ for ; Mon, 15 Aug 2011 08:24:44 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 70E7421F8BEF for ; Mon, 15 Aug 2011 08:24:44 -0700 (PDT) Received: by yie12 with SMTP id 12so3680580yie.31 for ; Mon, 15 Aug 2011 08:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7wZCBr/X6/MQa6wzr9AwTXRkerUdTriCKEjavtbvbUE=; b=SrvhWQkjaoayTKuu02ite42Xr3Xbbxg1WtGWUHh0AmnDPs1t9VZEzQOQY5l4OP8tjP CsAYntAB3r65jmVKYlHFSKhzxkPr9x0BKKQWCFEoCLjJtYRq0XtQh6GiZdieaw6MPgHz d2MX9DlptLGEiE5eqnCQdD57Bpvrm9kJ2nl00= MIME-Version: 1.0 Received: by 10.236.145.102 with SMTP id o66mr12065775yhj.211.1313421923852; Mon, 15 Aug 2011 08:25:23 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Mon, 15 Aug 2011 08:25:22 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CE4A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E46207A.6080404@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234502498CE4A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 15 Aug 2011 11:25:22 -0400 X-Google-Sender-Auth: 3dcHAvFoqx8B9tyNZrg2PWrJ_7o Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:24:45 -0000 > I'll ask the chairs to open an issue for this. The chairs consider themselves asked, and have opened a ticket: http://trac.tools.ietf.org/wg/oauth/trac/ticket/23 > My proposed requires CSRF protected without adding additional requirements, > and therefore, is within the scope of my editorial discretion. IOW, my text is > already well-within working group consensus. Your text has not established > consensus, and I have listed actual issues with the proposed text which none > of the authors have addressed so far. This chair disagrees with the editorial prerogative at this point. I have not discussed this with my co-chairs, and perhaps they don't agree with me. I agree with Eran that the issue isn't settled -- that the Tony/Yaron/Torsten/Phil text, and the normative change it proposes, does not yet have WG consensus. And I note Eran's objection and the reasons for it, and I agree that it needs more discussion. But I believe the T/Y/T/P proposal has enough backing that it's the one that should be floated in the next version of the document right now. That by no means makes it final, and the chairs will track the discussion and make a proper consensus judgment at the appropriate time. I also think it's perfectly acceptable for the editor to put both versions of the text in, with a note that the WG must choose which way to go. Eran, is that a path you can tolerate? Barry, as chair From john@jkemp.net Mon Aug 15 08:25:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DB821F8BE5 for ; Mon, 15 Aug 2011 08:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLpUmkKxQb7a for ; Mon, 15 Aug 2011 08:25:19 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 46DF921F8C4C for ; Mon, 15 Aug 2011 08:25:14 -0700 (PDT) Received: (qmail 11090 invoked by uid 0); 15 Aug 2011 15:25:59 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy1.bluehost.com with SMTP; 15 Aug 2011 15:25:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jkemp.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=/vbxZxuKL6c5cjzODXVtoiw3CrCtaumJKdhqY8ZPMOY=; b=c3V8iLxYc9HTkoQ4epkrrK3rl2P4mLQNwLj1QLZ3HEJ72mEySy3eiAww2+QbH//cEPgVIQx5sZ7fXzBquS6TWaAjq2iqiWBsnKczOF2zre+obxRj3BK+w5qvZnEmatoJ; Received: from cpe-74-67-30-101.nycap.res.rr.com ([74.67.30.101] helo=[192.168.1.108]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Qsz38-0004Gk-Pq; Mon, 15 Aug 2011 09:25:59 -0600 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CE49@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 15 Aug 2011 11:25:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3E0A84DB-B239-4643-803B-334B64BC2F6E@jkemp.net> References: <4E46207A.6080404@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234502498CE49@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1244.3) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 74.67.30.101 authed with john+jkemp.net} Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:25:20 -0000 On Aug 15, 2011, at 11:07 AM, Eran Hammer-Lahav wrote: > (please don't use my sled.com work email address) >=20 > I'll ask the chairs to open an issue for this. >=20 > My proposed requires CSRF protected without adding additional = requirements, and therefore, is within the scope of my editorial = discretion. IOW, my text is already well-within working group consensus. = Your text has not established consensus, and I have listed actual issues = with the proposed text which none of the authors have addressed so far. >=20 > I'm opposed to making the state parameter required because it is = meaningless without addition specification of exactly how to use it = (i.e. achieve interoperable implementation), which is clearly outside = the scope of this document. I agree - I am also opposed to making 'state' required. >=20 > The "new" attack described is in no way more severe than the existing = CSRF attack described in -20. I, too, do not see how this attack is different than other CSRF attacks, = or why existing security measures (including but not limited to 'state') = as described in the specification are not sufficient to prevent this = attack. =20 - John > You have provided no justification for making this significant = normative change other than this "new" CSRF attack, and the current text = is based on actual working group consensus. >=20 > EHL >=20 >=20 >> -----Original Message----- >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >> Sent: Monday, August 15, 2011 7:51 AM >> To: Eran Hammer-Lahav; eran@sled.com; Torsten Lodderstedt >> Cc: OAuth WG (oauth@ietf.org) >> Subject: RE: [OAUTH-WG] Auth Code Swap Attack >>=20 >> That's nice, four people come up with text and you decide to use your = text. >> Making state optional does nothing to fix the protocol issue, people = will get >> this wrong and have. Our developers have been through this and agreed >> upon the text that was generated. They find the text in the current = draft >> unacceptable and confusing and think that new text is acceptable. >>=20 >> So -1 on your text >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Eran Hammer-Lahav >> Sent: Sunday, August 14, 2011 11:32 PM >> To: eran@sled.com; Torsten Lodderstedt >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>=20 >> I'm using my proposed text in -21. >>=20 >> EHL >>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>> Of Eran Hammer-Lahav >>> Sent: Saturday, August 13, 2011 8:14 AM >>> To: Torsten Lodderstedt >>> Cc: OAuth WG (oauth@ietf.org) >>> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>>=20 >>> Again, the idea that you can produce a comprehensive description of >>> security threat is impractical if you are going to include every >>> browser-based attack and its remedies. OAuth use of browser >>> redirection imports almost every possible attack vector on the web. = That's >> my point. >>> People constantly bring up these attack vectors, and in multiple >>> flavors and variations, as if *anyone* can produce a complete list = of these >> issues. >>>=20 >>> Now, this doesn't mean we should not try to be comprehensive but = this >>> can go on forever. >>>=20 >>> The changes to 10.12 seem reasonable with the exception of the new >>> MUSTs. >>> I disagree that we should mandate clients to use the state parameter >>> as the only CSRF protection vector, especially in an evolving web >>> environment. We can still include a MUST for verifying that the user >>> redirected to the authorization server is the same user coming back, >>> and highlight the state parameter as one way to accomplish that. >>>=20 >>> How about: >>>=20 >>>=20 >>> state: OPTIONAL. An opaque value used by the client to maintain = state >>> between the request and redirection. The authorization server = includes >>> this value when redirecting the user-agent back to the client. Use = of the >> "state" >>> parameter is RECOMMENDED for preventing cross-site request forgery = as >>> described in Section 10.12. >>>=20 >>>=20 >>>=20 >>>=20 >>> Section 10.12 Cross-Site Request Forgery >>>=20 >>>=20 >>> Cross-site request forgery (CSRF) is a web-based attack whereby HTTP >>> requests are transmitted from the user-agent of an end-user the = server >>> trusts or has authenticated. CSRF attacks enable the attacker to >>> intermix the attacker's security context with that of the resource >>> owner resulting in a compromise of either the resource server or of = the >> client application itself. >>>=20 >>> In the OAuth context, such attacks allow an attacker to inject their >>> own authorization code or access token into the client, which can >>> result in the client associating the attacker's protected resources = to >>> the victim's account on the client. Depending on the nature of the >>> client and the protected resources, this can have undesirable and >>> damaging effects. In order to prevent such attacks, the client MUST = employ >> CSRF protection. >>>=20 >>> It is strongly RECOMMENDED for the client to utilize the "state" >>> request parameter with authorization requests to the authorization >>> server. When used for CSRF prevention, the "state" request parameter >>> MUST contain a non-guessable value, which the client MUST also store >>> with the resource owner's user-agent in a location accessible only = to >>> the client or the resource owner's user-agent (i.e., protected by >>> same-origin policy). For example, the client can using a DOM = variable, HTTP >> cookie, or HTML5 client-side storage. >>>=20 >>>=20 >>> When redirecting the resource owner's user-agent back to the client, >>> the authorization server includes the value of the "state" = parameter. >>> Upon receiving the redirection request, the client MUST confirm that >>> returned value of the "state" parameter matches the value stored = with >>> the resource owner's user-agent. >>>=20 >>>=20 >>> EHL >>>=20 >>>=20 >>>=20 >>>=20 >>> From: Torsten Lodderstedt >>> Date: Fri, 12 Aug 2011 23:58:02 -0700 >>> To: Eran Hammer-lahav >>> Cc: Anthony Nadalin , "OAuth WG >>> (oauth@ietf.org)" >>> >>> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: >>>>=20 >>>> This is really just a flavor of CSRF attacks. I have no >>>> objections to better documenting it (though I feel the = current >>>> text is already sufficient), but we can't realistically = expect >>>> to identify and close every possible browser-based attack. A = new >>>> one is invented every other week. >>>>=20 >>>>=20 >>>> The problem with this text is that developers who do no >>>> understand CSRF attacks are not likely to implement it = correctly >>>> with this information. Those who understand it do not need = the >>>> extra verbiage which is more confusing than helpful. >>>>=20 >>>>=20 >>>>=20 >>>> We are constantly facing the fact that a comprehensive = description >>>> of security threats needs more space than we have in the core = draft. >>>> That's the reason why the security document has 63 pages and = that's >>>> also the reason why we decided to let the core spec refer to this >>>> document for in-depth explanations. This holds true for this = threat >>>> as well. >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> As for the new requirements, they are insufficient to >>>> actually accomplish what the authors propose without = additional >>>> requirements on state local storage and verification to = complete >>>> the flow. Also, the proposed text needs clarifications as = noted >>>> below. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> From: Anthony Nadalin >>>> Date: Fri, 12 Aug 2011 >>>> 12:06:36 -0700 >>>> To: "OAuth WG (oauth@ietf.org)" >>>> >>>> Subject: [OAUTH-WG] >>>> Auth Code Swap Attack >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Recommended >>>>> Changes to draft-ietf-oauth-v2 >>>>>=20 >>>>> In section 4, request options (e.g. >>>>> 4.1.1) featuring "state" should change from: >>>>>=20 >>>>> state >>>>> OPTIONAL. >>>>> An opaque value used by the client to maintain = state >>>>> between the request and callback. The = authorization >>>>> server includes this value when redirecting the >>>>> user-agent back to the client. >>>>>=20 >>>>> to: >>>>>=20 >>>>> state >>>>> REQUIRED. >>>>> An opaque value used by the client to maintain = state >>>>> between the request and callback. The = authorization >>>>> server includes this value when redirecting the >>>>> user-agent back to the client. The encoded value >>>>> SHOULD enable the client application to = determine >>>>> the user-context that was active at the time of = the >>>>> request (see section 10.12). The value MUST NOT = be >>>>> guessable or predictable, and MUST be kept >>>>> confidential. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Making the parameter required without making its usage >>>> required (I.e. "value SHOULD enable") accomplishes nothing. >>>> Also, what does "MUST be kept confidential" mean? = Confidential >>>> from what? Why specify an "encoded value"? >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Section 10.12 Cross-Site Request >>>>> Forgery >>>>>=20 >>>>> Change to: >>>>>=20 >>>>> Cross-site >>>>> request forgery (CSRF) is a web-based attack = whereby >>>>> HTTP requests are transmitted from the = user-agent of >>>>> an end-user the server trusts or has = authenticated. >>>>> CSRF attacks enable the attacker to intermix the >>>>> attacker's security context with that of >>>>> the resource owner resulting in a compromise of >>>>> either the resource server or of the client >>>>> application itself. In the OAuth context, >>>>> such attacks allow an attacker to inject their = own >>>>> authorization code or access token into a = client, >>>>> which can result in the client using an access = token >>>>> associated with the attacker's account rather = than >>>>> the victim's. Depending on the nature of the = client >>>>> and the protected resources, this can have >>>>> undesirable and damaging effects. >>>>>=20 >>>>> In order to prevent such attacks, the client >>>>> application MUST encode a non-guessable, >>>>> confidential end-user artifact and submit as the >>>>> "state" parameter to authorization and access = token >>>>> requests to the authorization server. The client >>>>> MUST keep the state value in a location = accessible >>>>> only by the client or the user-agent (i.e., >>>>> protected by same-origin policy), for example, = using >>>>> a DOM variable, HTTP cookie, or HTML5 = client-side >>>>> storage. >>>>>=20 >>>>> The authorization server includes the value of = the >>>>> "state" parameter when redirecting the = user-agent >>>>> back to the client. Upon receiving a redirect, = the >>>>> client application MUST confirm that returned = value >>>>> of "state" corresponds to the state value of the >>>>> user-agent's user session. If the end-user = session >>>>> represents an authenticated user-identity, the >>>>> client MUST ensure that the user-identity has = NOT >>>>> changed. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The above text uses 'user-context' and this 'user-identity'. >>>> Neither term is defined. >>>>=20 >>>>=20 >>>> EHL >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Aug 15 08:53:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C35B21F8BBA for ; Mon, 15 Aug 2011 08:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IBkcdphdVW3 for ; Mon, 15 Aug 2011 08:53:18 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 799A121F8BA0 for ; Mon, 15 Aug 2011 08:53:18 -0700 (PDT) Received: (qmail 20734 invoked from network); 15 Aug 2011 15:54:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 15:54:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 15 Aug 2011 08:53:52 -0700 From: Eran Hammer-Lahav To: Barry Leiba Date: Mon, 15 Aug 2011 08:52:33 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxbX5tsYmpwsjEkSd+c07Pecx0gMQAACskA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CE6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E46207A.6080404@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234502498CE4A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:53:19 -0000 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com > [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba > Sent: Monday, August 15, 2011 8:25 AM > To: Eran Hammer-Lahav > Cc: Anthony Nadalin; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack >=20 > > I'll ask the chairs to open an issue for this. >=20 > The chairs consider themselves asked, and have opened a ticket: > http://trac.tools.ietf.org/wg/oauth/trac/ticket/23 >=20 > > My proposed requires CSRF protected without adding additional > > requirements, and therefore, is within the scope of my editorial > > discretion. IOW, my text is already well-within working group > > consensus. Your text has not established consensus, and I have listed > > actual issues with the proposed text which none of the authors have > addressed so far. >=20 > This chair disagrees with the editorial prerogative at this point. I hav= e not > discussed this with my co-chairs, and perhaps they don't agree with me. What does "at this point" mean? This is how this working group has operated for 20 revisions. Does "at this= point" references the late stage of the specification and closing of WGLC?= If so, then your support for making such a significant normative change is= puzzling. Seems like *not* making this change first and discussing later i= s the appropriate action "at this point". I would suggest you compare the two texts side by side to see that the only= real difference is the use of MUST vs. RECOMMENDED. I didn't just make stu= ff up. "My" text is just an editorial cleanup with exclusion of the new MUS= T. And this new MUST is clearly against past established consensus since ve= rsion -00 (!) of this document and even earlier in its wrap_client_state fo= rm in WRAP. It is even a noticeable departure from the authors' own origina= l security consideration text submitted before. > I agree with Eran that the issue isn't settled -- that the > Tony/Yaron/Torsten/Phil text, and the normative change it proposes, does > not yet have WG consensus. And I note Eran's objection and the reasons f= or > it, and I agree that it needs more discussion. >=20 > But I believe the T/Y/T/P proposal has enough backing that it's the one t= hat > should be floated in the next version of the document right now. That by= no > means makes it final, and the chairs will track the discussion and make a > proper consensus judgment at the appropriate time. >=20 > I also think it's perfectly acceptable for the editor to put both version= s of the > text in, with a note that the WG must choose which way to go. Eran, is t= hat a > path you can tolerate? I do not plan to publish another draft until this issue is closed and resol= ved. I plan to seek WG consensus to every change made to -21 prior to publi= cation to reduce the need for another WG draft. This is why I am informing = the list with every change I make on my local copy so that people can raise= their concerns or objections. Of course, like any WG document, -21 will be subject to review, but there i= s a difference between publishing a document known to include issues to one= that can be safely considered stable. Ignoring Mr. Nadalin unproductive tone, this is exactly what has happened h= ere. Text was proposed, issues raised, an alternative was proposed, and I i= nformed the list of my intention of using the edited text. Mr. Nadalin then= raised his disagreement with the proposed edit. Fine. Now we wait for more= participants to express their views. EHL =20 From barryleiba.mailing.lists@gmail.com Mon Aug 15 09:26:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5033421F8C5C for ; Mon, 15 Aug 2011 09:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.04 X-Spam-Level: X-Spam-Status: No, score=-103.04 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaSC1pumLGBu for ; Mon, 15 Aug 2011 09:26:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1ECF21F8C52 for ; Mon, 15 Aug 2011 09:26:12 -0700 (PDT) Received: by yxp4 with SMTP id 4so3691493yxp.31 for ; Mon, 15 Aug 2011 09:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SjreA2fOOt5IWiwp5QNWHgL8h3z+UGPn2dkrj9dm0lg=; b=TgGPUW+55DuRlLkmYAyPN+Wx4sPmuHvTkLyszfoYLrT1mJstq7Kh/Q42su5p6cEKVZ EOtfWRlyyCeS0Q4BmxuKoMxsRr18FOIjRUmnrI6Xx9l1ardzzicX/KicngI/umq746ON DvsHSAIr7bVm6ykr0p9vGaGd2O96ghVBBptCI= MIME-Version: 1.0 Received: by 10.236.144.232 with SMTP id n68mr12778510yhj.177.1313425617632; Mon, 15 Aug 2011 09:26:57 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Mon, 15 Aug 2011 09:26:57 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CE6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E46207A.6080404@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234502498CE4A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234502498CE6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 15 Aug 2011 12:26:57 -0400 X-Google-Sender-Auth: sJqNyBovTLf4OAQxqiG9XAZ_v94 Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 16:26:13 -0000 > I do not plan to publish another draft until this issue is closed and resolved. > I plan to seek WG consensus to every change made to -21 prior to publication > to reduce the need for another WG draft. ... > and I informed the list of my intention of using the edited text. Mr. Nadalin then > raised his disagreement with the proposed edit. Fine. Now we wait for more > participants to express their views. OK, this is where the disconnect came from, and why I had a problem with what I heard. My guess is that that's the same problem Tony had: My interpretation of your one-line message that said, "I'm using my proposed text in -21," was that you were deciding the issue, and were about to publish a new draft now-ish that reflects your decision. What you say here makes it clear that that's not the case, and that what you meant was, "I believe my proposed text addresses this issue while maintaining established consensus about the protocol details, and when I post -21 (soon, but not now), which I hope will be the final version, I intend to use that version of the text, unless further discussion shows that WG consensus on the 'state' option has now changed." That's rather more long-winded, of course, but I have, as chair, no problem at all with that plan. I also suspect that Tony will consider the longer-winded explanation to be less dismissive of the T/Y/T/P proposal than the one-sentence version may have come across. And, so, carry on. Barry, still chair-like From eran@hueniverse.com Mon Aug 15 09:35:59 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1807621F8C08 for ; Mon, 15 Aug 2011 09:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgmWxjw92Y7Z for ; Mon, 15 Aug 2011 09:35:55 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 8862121F8BF9 for ; Mon, 15 Aug 2011 09:35:55 -0700 (PDT) Received: (qmail 21041 invoked from network); 15 Aug 2011 16:36:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 16:36:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 15 Aug 2011 09:36:25 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 15 Aug 2011 09:35:13 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZOi5rSXfDpMMhRI+ym0EhCpcebACK0AbQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234502498CE8DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 16:35:59 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234502498CE8DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To demonstrate why making state required as proposed isn't very helpful, he= re is an incomplete list of other requirements needed to make an effective = CSRF: * State value must not be empty (a common bug in many implementations using= simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a has= h of the session cookie, with or without salt which isn't sufficient. We us= e "cannot be generated, modified, or guessed to produce valid values" elsew= here in the document, but this is much easier to get right for access token= s and refresh tokens than CSRF tokens which are often just some algorithm o= n top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session = cookie to prevent the use of a leaked state value in multiple attacks on th= e same user session once the leak is no longer viable. In addition, this is not what "state" was originally intended for. If the w= orking group decides to mandate a CSRF parameter, it should probably be a n= ew parameter with a more appropriate name (e.g. 'csrf'). By forcing clients= to use "state" for this purpose, developers will need to use dynamic queri= es for other state information which further reduces the security of the pr= otocol (as the draft recommends not using dynamic callback query components= ). Encoding both CSRF tokens and other state information can be non-intuiti= ve or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to bette= r documenting it (though I feel the current text is already sufficient), bu= t we can't realistically expect to identify and close every possible browse= r-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF att= acks are not likely to implement it correctly with this information. Those = who understand it do not need the extra verbiage which is more confusing th= an helpful. As for the new requirements, they are insufficient to actually accomplish w= hat the authors propose without additional requirements on state local stor= age and verification to complete the flow. Also, the proposed text needs cl= arifications as noted below. From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring "state" should change = from: state OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable= the client application to determine the user-context that was active at th= e time of the request (see section 10.12). The value MUST NOT be guessable= or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. "valu= e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi= dential" mean? Confidential from what? Why specify an "encoded value"? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the resource owner resulting in a comprom= ise of either the resource server or of the client application itself. In t= he OAuth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather than th= e victim's. Depending on the nature of the client and the protected resourc= es, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "state" paramet= er to authorization and access token requests to the authorization server. = The client MUST keep the state value in a location accessible only by the c= lient or the user-agent (i.e., protected by same-origin policy), for exampl= e, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirect, th= e client application MUST confirm that returned value of "state" correspond= s to the state value of the user-agent's user session. If the end-user sess= ion represents an authenticated user-identity, the client MUST ensure that = the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term i= s defined. EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234502498CE8DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To demonstrate why making state required as proposed isn̵= 7;t very helpful, here is an incomplete list of other requirements needed t= o make an effective CSRF:

 

* State value must not be empty (a common bug in= many implementations using simple value comparison).

=

 =

* ‘Non-guessab= le’ isn’t sufficient as most developers will simply use a hash = of the session cookie, with or without salt which isn’t sufficient. W= e use “cannot be generated, modified, or guessed to produce valid val= ues” elsewhere in the document, but this is much easier to get right = for access tokens and refresh tokens than CSRF tokens which are often just = some algorithm on top of the session cookie.

 

* State CSRF value should be= short-lived or based on a short-lived session cookie to prevent the use of= a leaked state value in multiple attacks on the same user session once the= leak is no longer viable.

 

In addition, this is not what “state̶= 1; was originally intended for. If the working group decides to mandate a C= SRF parameter, it should probably be a new parameter with a more appropriat= e name (e.g. ‘csrf’). By forcing clients to use “state= 221; for this purpose, developers will need to use dynamic queries for othe= r state information which further reduces the security of the protocol (as = the draft recommends not using dynamic callback query components). Encoding= both CSRF tokens and other state information can be non-intuitive or compl= icated for some developers/platforms.

 

EHL

 

 

 

 

From: Eran Hammer-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; O= Auth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap A= ttack

 

This is really just a flavor of CSRF attacks. I have no objections to bet= ter documenting it (though I feel the current text is already sufficient), = but we can't realistically expect to identify and close every possible brow= ser-based attack. A new one is invented every other week.=

 

The problem with this text is that deve= lopers who do no understand CSRF attacks are not likely to implement it cor= rectly with this information. Those who understand it do not need the extra= verbiage which is more confusing than helpful.

=

 

As for the new requirements, they are insufficien= t to actually accomplish what the authors propose without additional requir= ements on state local storage and verification to complete the flow. Also, = the proposed text needs clarifications as noted below.

 

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 Aug 2011 12= :06:36 -0700
To: "OAuth WG (oauth@ietf.org)" <oauth@iet= f.org>
Subject: [OAUTH-WG] Auth Code Swap Attack

 

<= span style=3D'font-size:10.5pt;color:black'> 

<= o:p> 

Recommended Changes to draft-ietf-oauth-v2

 

In section 4, request options (e.g. 4.1.1) featu= ring "state" should change from:

 

state

OPTIONAL. An opaque value used by the c= lient to maintain state between the request and callback. The authorization= server includes this value when redirecting the user-agent back to the cli= ent.

&nbs= p;

to:

 

state

REQUIRED. An opaque value used by th= e client to maintain state between the request and callback. The authorizat= ion server includes this value when redirecting the user-agent back to the = client. The encoded value SHOULD enable the client application to determine= the user-context that was active at the time of the  request (see sec= tion 10.12). The value MUST NOT be guessable or predictable, and MUST be ke= pt confidential.

 

 

Making the parameter require= d without making its usage required (I.e. "value SHOULD enable") = accomplishes nothing. Also, what does "MUST be kept confidential"= mean? Confidential from what? Why specify an "encoded value"?

 

 =

Section 10.12 Cross-Site Request Forgery

 =

Change to:

 

Cross-site request forgery (CSRF) i= s a web-based attack whereby HTTP requests are transmitted from the user-ag= ent of an end-user the server trusts or has authenticated. CSRF attack= s enable the attacker to intermix the attacker's security context with that= of the resource owner resulting in a compromise of either the resourc= e server or of the client application itself. In the OAuth context, such&nb= sp;attacks allow an attacker to inject their own authorization code or acce= ss token into a client, which can result in the client using an access= token associated with the attacker's account rather than the victim's. Dep= ending on the nature of the client and the protected resources, this c= an have undesirable and damaging effects.

In order to prevent such a= ttacks, the client application MUST encode a non-guessable, confidential en= d-user artifact and submit as the "state" parameter to autho= rization and access token requests to the authorization server. The client = MUST keep the state value in a location accessible only by the client = or the user-agent (i.e., protected by same-origin policy), for example, usi= ng a DOM variable, HTTP cookie, or HTML5 client-side storage.

T= he authorization server includes the value of the "state" paramet= er when redirecting the user-agent back to the client. Upon receiving = a redirect, the client application MUST confirm that returned value of &quo= t;state" corresponds to the state value of the user-agent's user sessi= on. If the end-user session represents an authenticated user-identity, the = client MUST ensure that the user-identity has NOT changed.

 

&n= bsp;

The above text uses 'user-context' and this 'user-id= entity'. Neither term is defined.

 =

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E7234502498CE8DP3PW5EX1MB01E_-- From romeda@gmail.com Mon Aug 15 09:44:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F25921F8C14 for ; Mon, 15 Aug 2011 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tr7q47X1CfLD for ; Mon, 15 Aug 2011 09:44:23 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 980E821F8C0C for ; Mon, 15 Aug 2011 09:44:23 -0700 (PDT) Received: by qyk34 with SMTP id 34so907231qyk.10 for ; Mon, 15 Aug 2011 09:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=PtGtkRtlSwnj+rQ0SETrVJs/GG5cu+KImjsEnY40T5E=; b=AIus4edbRXfrrnOHtfASzqAsBSv5cs15OVq3zkvAJ9cVZwa5gY26z3MTUB6DsBbLTj HuiJZ9eLAyYNwdUY0Mhjt9Og0piUm26yvdd+MOI9Z7Jn3w/upeD4YcLdynNbUb6o5r13 jOhW0vO/pC2ZW9uFu8BDfwHosQL9Hyt56Zl0k= Received: by 10.229.65.7 with SMTP id g7mr2598616qci.264.1313426709091; Mon, 15 Aug 2011 09:45:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.85 with HTTP; Mon, 15 Aug 2011 09:44:49 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Mon, 15 Aug 2011 17:44:49 +0100 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 16:44:24 -0000 >From my chair-seat, Barry's interpretation matches mine. Having carefully reviewed Eran's revised text vis-a-vis the proposal from Anthony et al., it seems like the concerns are addressed without forcing the use of any specific mechanism to maintain state, which is commensurate with the approach to the problem in the HTTP world. Reviewing the history of the state parameter, and thinking about how it will be used within a functioning system, I'm inclined to agree with Eran's most recent comments. Thus, the challenge for me is whether or not there is a way to introduce a required CSRF parameter that meets the security requirements, can be implemented seamlessly in libraries, and is reasonably scalable in its default (library-driven) form (my intuition says there isn't). b. On 15 August 2011 17:35, Eran Hammer-Lahav wrote: > To demonstrate why making state required as proposed isn=E2=80=99t very h= elpful, > here is an incomplete list of other requirements needed to make an effect= ive > CSRF: > > > > * State value must not be empty (a common bug in many implementations usi= ng > simple value comparison). > > > > * =E2=80=98Non-guessable=E2=80=99 isn=E2=80=99t sufficient as most develo= pers will simply use a hash > of the session cookie, with or without salt which isn=E2=80=99t sufficien= t. We use > =E2=80=9Ccannot be generated, modified, or guessed to produce valid value= s=E2=80=9D > elsewhere in the document, but this is much easier to get right for acces= s > tokens and refresh tokens than CSRF tokens which are often just some > algorithm on top of the session cookie. > > > > * State CSRF value should be short-lived or based on a short-lived sessio= n > cookie to prevent the use of a leaked state value in multiple attacks on = the > same user session once the leak is no longer viable. > > > > In addition, this is not what =E2=80=9Cstate=E2=80=9D was originally inte= nded for. If the > working group decides to mandate a CSRF parameter, it should probably be = a > new parameter with a more appropriate name (e.g. =E2=80=98csrf=E2=80=99).= By forcing clients > to use =E2=80=9Cstate=E2=80=9D for this purpose, developers will need to = use dynamic queries > for other state information which further reduces the security of the > protocol (as the draft recommends not using dynamic callback query > components). Encoding both CSRF tokens and other state information can be > non-intuitive or complicated for some developers/platforms. > > > > EHL > > > > > > > > > > From: Eran Hammer-Lahav > Sent: Friday, August 12, 2011 2:53 PM > To: Anthony Nadalin; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > This is really just a flavor of CSRF attacks. I have no objections to bet= ter > documenting it (though I feel the current text is already sufficient), bu= t > we can't realistically expect to identify and close every possible > browser-based attack. A new one is invented every other week. > > > > The problem with this text is that developers who do no understand CSRF > attacks are not likely to implement it correctly with this information. > Those who understand it do not need the extra verbiage which is more > confusing than helpful. > > > > As for the new requirements, they are insufficient to actually accomplish > what the authors propose without additional requirements on state local > storage and verification to complete the flow. Also, the proposed text ne= eds > clarifications as noted below. > > > > > > From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 > To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack > > > > > > > > Recommended Changes to draft-ietf-oauth-v2 > > > > In section 4, request options (e.g. 4.1.1) featuring "state" should chang= e > from: > > > > state > > OPTIONAL. An opaque value used by the client to maintain state between th= e > request and callback. The authorization server includes this value when > redirecting the user-agent back to the client. > > > > to: > > > > state > > REQUIRED. An opaque value used by the client to maintain state between th= e > request and callback. The authorization server includes this value when > redirecting the user-agent back to the client. The encoded value SHOULD > enable the client application to determine the user-context that was acti= ve > at the time of the =C2=A0request (see section 10.12). The value MUST NOT = be > guessable or predictable, and MUST be kept confidential. > > > > > > Making the parameter required without making its usage required (I.e. "va= lue > SHOULD enable") accomplishes nothing. Also, what does "MUST be kept > confidential" mean? Confidential from what? Why specify an "encoded value= "? > > > > > > Section 10.12 Cross-Site Request Forgery > > > > Change to: > > > > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP > requests are transmitted from the user-agent of an end-user=C2=A0the serv= er > trusts or has authenticated. CSRF attacks enable the attacker to intermix > the attacker's security context with that of the=C2=A0resource owner resu= lting in > a compromise of either the resource server or of the client application > itself. In the OAuth context, such=C2=A0attacks allow an attacker to inje= ct their > own authorization code or access token into a client, which can result in > the client using an=C2=A0access token associated with the attacker's acco= unt > rather than the victim's. Depending on the nature of the client and the > protected=C2=A0resources, this can have undesirable and damaging effects. > > In order to prevent such attacks, the client application MUST encode a > non-guessable, confidential end-user artifact and submit as=C2=A0the "sta= te" > parameter to authorization and access token requests to the authorization > server. The client MUST keep the state value in=C2=A0a location accessibl= e only > by the client or the user-agent (i.e., protected by same-origin policy), = for > example, using a DOM variable,=C2=A0HTTP cookie, or HTML5 client-side sto= rage. > > The authorization server includes the value of the "state" parameter when > redirecting the user-agent back to the client. Upon=C2=A0receiving a redi= rect, > the client application MUST confirm that returned value of "state" > corresponds to the state value of the user-agent's user session. If the > end-user session represents an authenticated user-identity, the client MU= ST > ensure that the user-identity=C2=A0has NOT changed. > > > > > > The above text uses 'user-context' and this 'user-identity'. Neither term= is > defined. > > > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From wmills@yahoo-inc.com Mon Aug 15 09:45:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004F721F8C12 for ; Mon, 15 Aug 2011 09:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.133 X-Spam-Level: X-Spam-Status: No, score=-17.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgL0eN4aua1p for ; Mon, 15 Aug 2011 09:45:22 -0700 (PDT) Received: from nm40-vm4.bullet.mail.bf1.yahoo.com (nm40-vm4.bullet.mail.bf1.yahoo.com [72.30.239.212]) by ietfa.amsl.com (Postfix) with SMTP id D7E7C21F8C0C for ; Mon, 15 Aug 2011 09:45:21 -0700 (PDT) Received: from [98.139.212.149] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 15 Aug 2011 16:46:05 -0000 Received: from [98.139.212.218] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 15 Aug 2011 16:46:05 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 15 Aug 2011 16:46:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 21109.10537.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 58165 invoked by uid 60001); 15 Aug 2011 16:46:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313426764; bh=IImQqS/9J6JiNlfFUJFA+ETfaYw7PIjWC3U6rFMF3Xg=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Q0WWfDoA82MHHNVb/9lVRAuzDzzMNtT/QhQxnz5d+uweXPpr3HezubLZPmUxLQN0taPm60UPem6wcYBAu5ovJTiEBoF0Kzwyr8KsqUbqKLz6T16l9WFawoqiLswr2JaUBx+tA3StQP2PKFvO2qYSt2JpyWvRdveL201UFdomgaI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KtdNdLd3KfzPXQRMKiGh+FZNFhpokuEYlWCBcO8hBgSR47hhGM2SPcUqbKDceq7KFSxjuIc2aCWqfnS83OKGcK3N75E3AvjkrLWH4SUlz7wHef0SPV5NZfC7Qz9BQ/bJQK+/x3fH91owhh+jfX7ujXQyz1iG+kAP0nK6WAZmsQk=; X-YMail-OSG: c00AMy4VM1khApBUu3j.GKtLfoPkqMluqFEWazbo4NSJfhZ JioKLXOm5PM66oQlZ_bAFl3WTTq.UvvNlpewEKSHic6x9KRETQily72RlL1i rUMVaN6UW2VYvjMisGAP7f.QLdQEQZBW0.p41i85h_At_5Hv0l0XFmjRlUUf XieBLJ88HIj8ZDCv..jbNZF1uvpNzE2vf6SOsVK_V77_I0hEf9dSmHIpjjoK 764HHWF9.0nNa4np.Klo3CwBIPTz.aOD58IUIT4j_mjnXAH39wlyuivG27.J O3Ukr_J1ndCeULbTEmFjuf5mGyM6qAOcOrThiEWU8GY0W1j3BWJ1BlWIUlv1 fO3CKL_pFZZqcbakHVeAggX1K.p.WZ3luC33sXLkcjjB3ZXJi8i1zHZYhGGj dW.ZJfPxAwdXENZb62oapbBa1eyXFmUOjldtfmHmjY_G5f6QEvwzYz8lyOjT XrMC_ap5CAdtQ0xsaeBY3N2IyJVT95MVLuc4- Received: from [99.31.212.42] by web31806.mail.mud.yahoo.com via HTTP; Mon, 15 Aug 2011 09:46:03 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72345024864560@P3PW5EX1MB01.EX1.SECURESERVER.NET> <81B6B8AF-4EC0-4F08-B48C-D1E7B39AE506@oracle.com> <1312506375.29372.YahooMailNeo@web31802.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1313426763.9579.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Mon, 15 Aug 2011 09:46:03 -0700 (PDT) From: "William J. Mills" To: Eran Hammer-Lahav , Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CDDA@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1833318785-1313426763=:9579" Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 16:45:24 -0000 --0-1833318785-1313426763=:9579 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "add" doesn't really say it to me either.=C2=A0 "ah", short for "additional= hash" is somewhat more mnemonic for me, but then I think "ext" isn't horri= ble because it's a frequent abbreviation for extension.=0A=0A-bill=0A=0A=0A= =0A________________________________=0AFrom: Eran Hammer-Lahav =0ATo: William J. Mills ; Phil Hunt =0ACc: OAuth WG =0ASent: Sunday, August 14, 20= 11 11:28 PM=0ASubject: RE: [OAUTH-WG] MAC Tokens body hash=0A=0A=0AHow abou= t =E2=80=98add=E2=80=99? as in =E2=80=9CUsed to include additional data in = the MAC normalized string=E2=80=9D.=0A=C2=A0=0AEHL=0A=C2=A0=0AFrom:William = J. Mills [mailto:wmills@yahoo-inc.com] =0ASent: Thursday, August 04, 2011 6= :06 PM=0ATo: Eran Hammer-Lahav; Phil Hunt=0ACc: OAuth WG=0ASubject: Re: [OA= UTH-WG] MAC Tokens body hash=0A=C2=A0=0AIt's the proverbial 'void *client_d= ata;' equivalent.=C2=A0 All names for that to date suck, my favorite is 'ro= ck'.=0A=C2=A0=0A=0A________________________________=0A=0AFrom:Eran Hammer-L= ahav =0ATo: Phil Hunt =0ACc: OAu= th WG =0ASent: Thursday, August 4, 2011 4:42 PM=0ASubject: = Re: [OAUTH-WG] MAC Tokens body hash=0AOk. We seem to be using different def= initions of what application data mean, but have the same use cases in mind= . I'll come up with a different name or just keep ext.=C2=A0=0A=C2=A0=0AEHL= =0A=0AOn Aug 3, 2011, at 12:42, "Phil Hunt" wrote:= =0AOnly allowing (implied or not) app data is needlessly=C2=A0narrow in sco= pe.=0A>=C2=A0=0A>Extending MAC to include claims or session information is = a perfectly valid thing to do. It improves scalability and reduces the need= to look up artifact data.=C2=A0=0A>=C2=A0=0A>Note: =C2=A0I'd like to share= more on this, but I'm prioritizing the Threat Model document. Never-the-le= ss, the above should be a sufficient example about why extensibility is use= ful.=0A>=C2=A0=0A>Phil=0A>=C2=A0=0A>@independentid=0A>www.independentid.com= =0A>phil.hunt@oracle.com=0A>=C2=A0=0A>=0A>=0A>=0A>=C2=A0=0A>On 2011-08-03, = at 11:03 AM, Eran Hammer-Lahav wrote:=0A>=0A>=0A>=0A>My proposal is to chan= ge =E2=80=98ext=E2=80=99 to =E2=80=98app=E2=80=99, keep the same prose as = =E2=80=98ext=E2=80=99, and add the use case of =E2=80=98bodyhash=E2=80=99 a= s an example. I=E2=80=99m not too stuck on the name, but my thinking is tha= t =E2=80=98app=E2=80=99 relays the right message that this is a place where= developers can stick any application data they want included. =E2=80=98ext= =E2=80=99 conveys the idea of extensions which I=E2=80=99m not so thrilled = about.=0A>=C2=A0=0A>In other words, I=E2=80=99d like a developer reading th= is to feel comfortable using it right away for securing addition bits such = as a JSON payload, but I don=E2=80=99t like the idea of someone publishing = an I-D with a full syntax and canonicalization requirements for say, singin= g an entire request, headers and all. I feel that would be much better acco= mplished by defining a new HTTP authentication scheme.=0A>=C2=A0=0A>Philoso= phically, I think extensible authentication schemes are a bad idea.=0A>=C2= =A0=0A>EHL=0A>=C2=A0=0A>=C2=A0=0A>From:=C2=A0William J. Mills [mailto:wmill= s@yahoo-inc.com]=C2=A0=0A>Sent:=C2=A0Wednesday, August 03, 2011 10:28 AM=0A= >To:=C2=A0Phillip Hunt; Eran Hammer-Lahav=0A>Cc:=C2=A0Ben Adida; OAuth WG; = Adam Barth(adam@adambarth.com)=0A>Subject:=C2=A0Re: [OAUTH-WG] MAC Tokens b= ody hash=0A>=C2=A0=0A>In thinking about this I'm coming around to the viewp= oint that a single additional predefined spot is sufficient.=C2=A0 If the a= pp developer wants to include addtional data there (iun the specified forma= t) that's fine.=C2=A0 If what they want to do is include a signature of oth= er payload that's fine too.=0A>=C2=A0=0A>I'm not in love with the name "app= " though, "ext" is better.=0A>=C2=A0=0A>=0A>_______________________________= _=0A>=0A>From:=C2=A0Phillip Hunt =0A>To:=C2=A0Eran Ha= mmer-Lahav =0A>Cc:=C2=A0Ben Adida ; OAu= th WG ; "Adam Barth(adam@adambarth.com)" =0A>Sent:=C2=A0Tuesday, August 2, 2011 7:14 PM=0A>Subject:=C2=A0Re: [OAUT= H-WG] MAC Tokens body hash=0A>=0A>=0A>Phil=0A>=0A>On 2011-08-02, at 18:02, = Eran Hammer-Lahav wrote:=0A>The idea is to drop 'ext'= and 'bodyhash' due to being underspecified and therefore causing more harm= than good. I added 'ext' to allow for application specific data to be incl= uded in the signed content. However, the name suggests this is an extension= point for future specifications. I believe authentication schemes should n= ot be extensible in ways that affect their security or interop properties a= nd without additional text (registry, process, etc) for the 'ext' parameter= , it will cause more issues than help.=0A>>=0A>>Instead of the 'ext' parame= ter I am suggesting the 'app' parameter which will do the same, but will be= better positioned as an application-specific data. The prose will go a ste= p further and recommend that the parameter value include a hash of the data= , not the data itself. This is to ensure the parameter does not become part= of the payload which is inappropriate for HTTP requests.=0A>-1 what you de= scribe appears to be a separate feature from ext=0A>=0A>As for the 'bodyhas= h' parameter, I would like to remove it because it is underspecified (we ha= d an actual deployment experience showing that it doesn't produce interoper= able implementations due to the many HTTP body transformation applied in mo= st frameworks). Solving this issue is not possible due to the many differen= t types of bodies and frameworks (and clearly operating on the "raw" body d= oesn't work). Instead, developers can use the new 'app' parameter to accomp= lish that.=0A>=C2=A0=0A>+1=0A>=C2=A0=0A>=0A>As for the normalized string, i= t will be adjusted to reflect these changes when they are made, so no place= holders which will require code change. Considering this is -00, it is clea= rly not a stable document.=0A>Will these changes work with your use cases?= =0A>>=0A>>EHL=0A>>=0A>>=0A>>-----Original Message-----=0A>>From: Skylar Woo= dward=C2=A0[mailto:skylar@kiva.org]=0A>>Sent: Tuesday, August 02, 2011 4:02= PM=0A>>To: Eran Hammer-Lahav=0A>>Cc: OAuth WG; Ben Adida; 'Adam Barth (ada= m@adambarth.com)'=0A>>Subject: Re: [OAUTH-WG] MAC Tokens body hash=0A>>=C2= =A0=0A>>hurrah!=0A>>(not necessarily for losing a way to sign the body, but= for simplicity and=0A>>avoiding some of the potential inconsistencies w/ b= odyhash).=0A>>=C2=A0=0A>>Is your plan to reserve an empty line 6 for the No= rmalized Request String=0A>>(which was used for bodyhash) or eliminate it, = brining the total to six=0A>>elements?=0A>>=C2=A0=0A>>skylar=0A>>=C2=A0=0A>= >On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote:=0A>>=C2=A0=0A>>I pla= n to drop support for the bodyhash parameter in the next draft based=0A>>on= bad implementation experience. Even with simple text body, UTF=0A>>encodin= g has introduced significant issues for us. The current draft does not=0A>>= work using simple JS code between a browser and node.js even when both=0A>>= use the same v8 engine due to differences in the body encoding. Basically,= =0A>>the JS string used to send a request from the browser is not the actua= l string=0A>>sent on the wire.=0A>>=C2=A0=0A>>To fix that, we need to force= UTF-8 encoding on both sides. However, that=0A>>is very much application s= pecific. This will not work for non-text bodies.=0A>>Instead, the specifica= tion should offer a simple way to use the ext parameter=0A>>for such needs,= including singing headers. And by offer I mean give=0A>>examples, but leav= e it application specific for now.=0A>>=C2=A0=0A>>I am open to suggestions = but so far all the solutions I came up with will=0A>>introduce unacceptable= complexity that will basically make this work useless.=0A>>=C2=A0=0A>>EHL= =0A>>_______________________________________________=0A>>OAuth mailing list= =0A>>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/oauth=0A>>=0A= >>_______________________________________________=0A>>OAuth mailing list=0A= >>OAuth@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/oauth=0A>=0A>___= ____________________________________________=0A>OAuth mailing list=0A>OAuth= @ietf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A>=C2=A0=0A______= _________________________________________=0A>OAuth mailing list=0A>OAuth@ie= tf.org=0A>https://www.ietf.org/mailman/listinfo/oauth=0A=0A________________= _______________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/oauth --0-1833318785-1313426763=:9579 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
"add" doesn't really say it to me either.  "ah", short for "addition= al hash" is somewhat more mnemonic for me, but then I think "ext" isn't hor= rible because it's a frequent abbreviation for extension.
=
-bill

From: Eran Hammer-Lahav &= lt;eran@hueniverse.com>
To: William J. Mills <wmills@yahoo-inc.com>; Phil Hunt <phil.h= unt@oracle.com>
Cc: = OAuth WG <oauth@ietf.org>
Sent: Sunday, August 14, 2011 11:28 PM
Subject: RE: [OAUTH-WG] MAC Tokens body hash
How about =E2=80=98add=E2=80=99? as in =E2=80=9CUsed to include addit= ional data in the MAC normalized string=E2=80=9D.
 
EHL
 
From: = William J. Mills [mailto:wmills@yahoo-inc.com]
Sent: Thursday, A= ugust 04, 2011 6:06 PM
To: Eran Hammer-Lahav; Phil Hunt
Cc:= OAuth WG
Subject: Re: [OAUTH-WG] MAC Tokens body hash=
 
<= div>
It's the prover= bial 'void *client_data;' equivalent.  All names for that to date suck= , my favorite is 'rock'.
 
From: Eran Hammer-Lahav <= eran@hueniverse.com>
To:= Phil Hunt <phil.hunt@oracle= .com>
Cc: OAuth WG <oauth@i= etf.org>
Sent: Thursday, August 4, 2011 4:42 PM
Subj= ect: Re: [OAUTH-WG] MAC Tokens body hash
Ok. We seem to be using diff= erent definitions of what application data mean, but have the same use case= s in mind. I'll come up with a different name or just keep ext. 
 
EHL

On Aug 3, 2011, at 12:42, "Ph= il Hunt" <phil.hunt@oracle.com> wrote:
Extending MAC to include claims= or session information is a perfectly valid thing to do. It improves scala= bility and reduces the need to look up artifact data. 
 
On 2011-08-03, at 11:03 AM, Eran Hammer-Lahav wrote= :


= My proposal is to change =E2=80=98ext=E2=80=99 to =E2=80=98app=E2=80=99, ke= ep the same prose as =E2=80=98ext=E2=80=99, and add the use case of =E2=80= =98bodyhash=E2=80=99 as an example. I=E2=80=99m not too stuck on the name, = but my thinking is that =E2=80=98app=E2=80=99 relays the right message that= this is a place where developers can stick any application data they want = included. =E2=80=98ext=E2=80=99 conveys the idea of extensions which I=E2= =80=99m not so thrilled about.
 
In othe= r words, I=E2=80=99d like a developer reading this to feel comfortable usin= g it right away for securing addition bits such as a JSON payload, but I do= n=E2=80=99t like the idea of someone publishing an I-D with a full syntax a= nd canonicalization requirements for say, singing an entire request, header= s and all. I feel that would be much better accomplished by defining a new = HTTP authentication scheme.
 
Phi= losophically, I think extensible authentication schemes are a bad idea.
 
EHL
 <= /span>
 
From: = ;William J. Mills [mailto:wmills@yahoo-inc.com] 
= Sent:=  Wednesday, August 03, 2011 10:28 AM
To: Phillip Hu= nt; Eran Hammer-Lahav
Cc: Ben Adida; OAuth WG; Adam Barth(adam@adambarth.com)
Subject: R= e: [OAUTH-WG] MAC Tokens body hash
 
In thinking abo= ut this I'm coming around to the viewpoint that a single additional predefi= ned spot is sufficient.  If the app developer wants to include addtion= al data there (iun the specified format) that's fine.  If what they wa= nt to do is include a signature of other payload that's fine too.
 
I'm not in love with the name "app" though, "ext" = is better.
 
From: Phillip Hunt <phil.hunt@oracle= .com>
To: Eran= Hammer-Lahav <eran@hueniverse.com= >
Cc: Ben Adida <ben@adida.ne= t>; OAuth WG <oauth@ietf.org>;= "Adam Barth(adam@adambarth.com)" &= lt;adam@adambarth.com>
Sen= t: = Tuesday, August 2, 2011 7:14 PM
Subject: Re: [OAUTH-WG] MAC Tokens body hash


Phil

On 2011-08-02, a= t 18:02, Eran Hammer-Lahav <eran@h= ueniverse.com> wrote:
The ide= a is to drop 'ext' and 'bodyhash' due to being underspecified and therefore= causing more harm than good. I added 'ext' to allow for application specific data to be included in the= signed content. However, the name suggests this is an extension point for = future specifications. I believe authentication schemes should not be exten= sible in ways that affect their security or interop properties and without = additional text (registry, process, etc) for the 'ext' parameter, it will c= ause more issues than help.

Instead of the 'ext' parameter I am sugg= esting the 'app' parameter which will do the same, but will be better posit= ioned as an application-specific data. The prose will go a step further and= recommend that the parameter value include a hash of the data, not the dat= a itself. This is to ensure the parameter does not become part of the paylo= ad which is inappropriate for HTTP requests.
-1 what you describe appears to be a separate feature from ext

As for the 'bodyhash' parameter, I would like to remo= ve it because it is underspecified (we had an actual deployment experience = showing that it doesn't produce interoperable implementations due to the ma= ny HTTP body transformation applied in most frameworks). Solving this issue= is not possible due to the many different types of bodies and frameworks (= and clearly operating on the "raw" body doesn't work). Instead, developers = can use the new 'app' parameter to accomplish that.
 
+1
 

As for the normalized string, it will be adjusted to = reflect these changes when they are made, so no placeholders which will req= uire code change. Considering this is -00, it is clearly not a stable docum= ent.
Will these= changes work with your use cases?

EHL

-----Original Message-----
From: Skylar Wood= ward [mailto:skylar@kiva.or= g]
Sent: Tuesday, August 02, 2= 011 4:02 PM
To: Eran Hammer-Lahav<= /span>
Cc: OAuth WG; Ben Adida; 'Adam Bar= th (adam@adambarth.com)'
Subject: Re: [OAUTH-WG] MAC Tokens body hash
 
hurrah= !
(not necessarily for losing a wa= y to sign the body, but for simplicity and
avoiding some of t= he potential inconsistencies w/ bodyhash).
<= blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt;">
 
Is your plan to r= eserve an empty line 6 for the Normalized Request String
=
(which was used for bodyhash) or eliminate it, brini= ng the total to six
elements?
<= /blockquote>
 
skyla= r
 
On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote:
 
I plan to drop support for the bodyhas= h parameter in the next draft based
on bad implementation experience. Even with simple text body= , UTF
encoding has introduced significant issues for us. = The current draft does not
work us= ing simple JS code between a browser and node.js even when both
use the same v8 engine due to differences in = the body encoding. Basically,
the = JS string used to send a request from the browser is not the actual string<= /span>
s= ent on the wire.
 
To fix that, we need to force UTF-8 encoding on both sides. H= owever, that
is very= much application specific. This will not work for non-text bodies.
Instead, the specification should offer a simple way to use the ext = parameter
for such needs, includi= ng singing headers. And by offer I mean give
examples, but leave it application specific for now.
 
I am open t= o suggestions but so far all the solutions I came up with will
=
introduce unacceptable complexity= that will basically make this work useless.
 
=
EHL
_____________________________________= __________
OAuth mailing list
=

__________________= _____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_________________________________= ______________
OAuth mailing list
OAuth@i= etf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>
 
=

______________________________= _________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth



--0-1833318785-1313426763=:9579-- From development@christoph-gerstner.de Mon Aug 15 09:46:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0CE21F8C36 for ; Mon, 15 Aug 2011 09:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.811 X-Spam-Level: * X-Spam-Status: No, score=1.811 tagged_above=-999 required=5 tests=[BAD_ENC_HEADER=1.81, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9O+plmIzOU6 for ; Mon, 15 Aug 2011 09:46:13 -0700 (PDT) Received: from server48.mivitec.net (server48.mivitec.net [91.90.146.82]) by ietfa.amsl.com (Postfix) with ESMTP id 008D221F8C0D for ; Mon, 15 Aug 2011 09:46:12 -0700 (PDT) Received: by server48.mivitec.net (Postfix, from userid 782) id 4E14C51001D; Mon, 15 Aug 2011 18:46:40 +0200 (CEST) To: oauth@ietf.org From: development@christoph-gerstner.de X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced by Parallels Confixx WebMail X-Mailer: Parallels Confixx WebMail (like SquirrelMail) Cc: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20110815164640.4E14C51001D@server48.mivitec.net> Date: Mon, 15 Aug 2011 18:46:40 +0200 (CEST) Subject: [OAUTH-WG] =?iso-8859-1?q?OAuth_2=2E0_Android_Library?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 16:46:13 -0000 Hey everyone! I just wanted to inform you that I uploaded an OAuth 2.0 library for Android to github. You can get it here: https://github.com/Xotan/OAuth2Android git@github.com:Xotan/OAuth2Android.git Even if a library isn't really necessary for OAuth 2.0 and Bearer-Tokens, API developers might want some easier solution to use MAC-Tokens (which was the major goal for me) Of course it is still under development. The minimum system requirements are: Android Platform Version 2.3.3; API Level 10. Currently it supports Bearer-Tokens and MAC-Tokens based on the specifications: draft-ietf-oauth-v2-16 draft-ietf-oauth-v2-bearer-06 draft-ietf-oauth-v2-http-mac-00 Other extensions are also possible. I hope this project is interesting for some of you and maybe helpful. Please don't hesitate to contact me if you have questions, advice or criticism. regards Christoph From eran@hueniverse.com Mon Aug 15 09:47:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0AD21F8C37 for ; Mon, 15 Aug 2011 09:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OXF1J9LKW9h for ; Mon, 15 Aug 2011 09:47:44 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id E51C721F8BF8 for ; Mon, 15 Aug 2011 09:47:43 -0700 (PDT) Received: (qmail 26913 invoked from network); 15 Aug 2011 16:48:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 16:48:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 15 Aug 2011 09:48:08 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , Phil Hunt Date: Mon, 15 Aug 2011 09:46:56 -0700 Thread-Topic: [OAUTH-WG] MAC Tokens body hash Thread-Index: AcxbatlV4pJDeWUeSfKT9bWlPtPqVQAAASHA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CE9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72345024864560@P3PW5EX1MB01.EX1.SECURESERVER.NET> <81B6B8AF-4EC0-4F08-B48C-D1E7B39AE506@oracle.com> <1312506375.29372.YahooMailNeo@web31802.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1313426763.9579.YahooMailNeo@web31806.mail.mud.yahoo.com> In-Reply-To: <1313426763.9579.YahooMailNeo@web31806.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234502498CE9AP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 16:47:46 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234502498CE9AP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV04oCZcyBqdXN0IGtlZXAg4oCYZXh04oCZIGFuZCBkcm9wIOKAmGJvZHloYXNo4oCZLiBTZWVt cyBsaWtlIHRoaXMgc2hvdWxkIHJlc29sdmUgdGhlIGlzc3VlLg0KDQpFSEwNCg0KRnJvbTogV2ls bGlhbSBKLiBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXQ0KU2VudDogTW9uZGF5 LCBBdWd1c3QgMTUsIDIwMTEgOTo0NiBBTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBQaGlsIEh1 bnQNCkNjOiBPQXV0aCBXRw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTUFDIFRva2VucyBib2R5 IGhhc2gNCg0KImFkZCIgZG9lc24ndCByZWFsbHkgc2F5IGl0IHRvIG1lIGVpdGhlci4gICJhaCIs IHNob3J0IGZvciAiYWRkaXRpb25hbCBoYXNoIiBpcyBzb21ld2hhdCBtb3JlIG1uZW1vbmljIGZv ciBtZSwgYnV0IHRoZW4gSSB0aGluayAiZXh0IiBpc24ndCBob3JyaWJsZSBiZWNhdXNlIGl0J3Mg YSBmcmVxdWVudCBhYmJyZXZpYXRpb24gZm9yIGV4dGVuc2lvbi4NCg0KLWJpbGwNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEVyYW4gSGFtbWVyLUxhaGF2IDxlcmFu QGh1ZW5pdmVyc2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4NClRvOiBXaWxsaWFt IEouIE1pbGxzIDx3bWlsbHNAeWFob28taW5jLmNvbTxtYWlsdG86d21pbGxzQHlhaG9vLWluYy5j b20+PjsgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20+Pg0KQ2M6IE9BdXRoIFdHIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+Pg0KU2VudDogU3VuZGF5LCBBdWd1c3QgMTQsIDIwMTEgMTE6MjggUE0NClN1YmplY3Q6 IFJFOiBbT0FVVEgtV0ddIE1BQyBUb2tlbnMgYm9keSBoYXNoDQpIb3cgYWJvdXQg4oCYYWRk4oCZ PyBhcyBpbiDigJxVc2VkIHRvIGluY2x1ZGUgYWRkaXRpb25hbCBkYXRhIGluIHRoZSBNQUMgbm9y bWFsaXplZCBzdHJpbmfigJ0uDQoNCkVITA0KDQpGcm9tOiBXaWxsaWFtIEouIE1pbGxzIFttYWls dG86d21pbGxzQHlhaG9vLWluYy5jb21dPG1haWx0bzpbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMu Y29tXT4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDQsIDIwMTEgNjowNiBQTQ0KVG86IEVyYW4g SGFtbWVyLUxhaGF2OyBQaGlsIEh1bnQNCkNjOiBPQXV0aCBXRw0KU3ViamVjdDogUmU6IFtPQVVU SC1XR10gTUFDIFRva2VucyBib2R5IGhhc2gNCg0KSXQncyB0aGUgcHJvdmVyYmlhbCAndm9pZCAq Y2xpZW50X2RhdGE7JyBlcXVpdmFsZW50LiAgQWxsIG5hbWVzIGZvciB0aGF0IHRvIGRhdGUgc3Vj aywgbXkgZmF2b3JpdGUgaXMgJ3JvY2snLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb20+Pg0KVG86IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCkNjOiBPQXV0aCBXRyA8b2F1dGhAaWV0 Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgNCwg MjAxMSA0OjQyIFBNDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBNQUMgVG9rZW5zIGJvZHkgaGFz aA0KT2suIFdlIHNlZW0gdG8gYmUgdXNpbmcgZGlmZmVyZW50IGRlZmluaXRpb25zIG9mIHdoYXQg YXBwbGljYXRpb24gZGF0YSBtZWFuLCBidXQgaGF2ZSB0aGUgc2FtZSB1c2UgY2FzZXMgaW4gbWlu ZC4gSSdsbCBjb21lIHVwIHdpdGggYSBkaWZmZXJlbnQgbmFtZSBvciBqdXN0IGtlZXAgZXh0Lg0K DQpFSEwNCg0KT24gQXVnIDMsIDIwMTEsIGF0IDEyOjQyLCAiUGhpbCBIdW50IiA8cGhpbC5odW50 QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQpPbmx5IGFs bG93aW5nIChpbXBsaWVkIG9yIG5vdCkgYXBwIGRhdGEgaXMgbmVlZGxlc3NseSBuYXJyb3cgaW4g c2NvcGUuDQoNCkV4dGVuZGluZyBNQUMgdG8gaW5jbHVkZSBjbGFpbXMgb3Igc2Vzc2lvbiBpbmZv cm1hdGlvbiBpcyBhIHBlcmZlY3RseSB2YWxpZCB0aGluZyB0byBkby4gSXQgaW1wcm92ZXMgc2Nh bGFiaWxpdHkgYW5kIHJlZHVjZXMgdGhlIG5lZWQgdG8gbG9vayB1cCBhcnRpZmFjdCBkYXRhLg0K DQpOb3RlOiAgSSdkIGxpa2UgdG8gc2hhcmUgbW9yZSBvbiB0aGlzLCBidXQgSSdtIHByaW9yaXRp emluZyB0aGUgVGhyZWF0IE1vZGVsIGRvY3VtZW50LiBOZXZlci10aGUtbGVzcywgdGhlIGFib3Zl IHNob3VsZCBiZSBhIHN1ZmZpY2llbnQgZXhhbXBsZSBhYm91dCB3aHkgZXh0ZW5zaWJpbGl0eSBp cyB1c2VmdWwuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNv bTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KT24gMjAxMS0wOC0wMywgYXQgMTE6MDMg QU0sIEVyYW4gSGFtbWVyLUxhaGF2IHdyb3RlOg0KDQpNeSBwcm9wb3NhbCBpcyB0byBjaGFuZ2Ug 4oCYZXh04oCZIHRvIOKAmGFwcOKAmSwga2VlcCB0aGUgc2FtZSBwcm9zZSBhcyDigJhleHTigJks IGFuZCBhZGQgdGhlIHVzZSBjYXNlIG9mIOKAmGJvZHloYXNo4oCZIGFzIGFuIGV4YW1wbGUuIEni gJltIG5vdCB0b28gc3R1Y2sgb24gdGhlIG5hbWUsIGJ1dCBteSB0aGlua2luZyBpcyB0aGF0IOKA mGFwcOKAmSByZWxheXMgdGhlIHJpZ2h0IG1lc3NhZ2UgdGhhdCB0aGlzIGlzIGEgcGxhY2Ugd2hl cmUgZGV2ZWxvcGVycyBjYW4gc3RpY2sgYW55IGFwcGxpY2F0aW9uIGRhdGEgdGhleSB3YW50IGlu Y2x1ZGVkLiDigJhleHTigJkgY29udmV5cyB0aGUgaWRlYSBvZiBleHRlbnNpb25zIHdoaWNoIEni gJltIG5vdCBzbyB0aHJpbGxlZCBhYm91dC4NCg0KSW4gb3RoZXIgd29yZHMsIEnigJlkIGxpa2Ug YSBkZXZlbG9wZXIgcmVhZGluZyB0aGlzIHRvIGZlZWwgY29tZm9ydGFibGUgdXNpbmcgaXQgcmln aHQgYXdheSBmb3Igc2VjdXJpbmcgYWRkaXRpb24gYml0cyBzdWNoIGFzIGEgSlNPTiBwYXlsb2Fk LCBidXQgSSBkb27igJl0IGxpa2UgdGhlIGlkZWEgb2Ygc29tZW9uZSBwdWJsaXNoaW5nIGFuIEkt RCB3aXRoIGEgZnVsbCBzeW50YXggYW5kIGNhbm9uaWNhbGl6YXRpb24gcmVxdWlyZW1lbnRzIGZv ciBzYXksIHNpbmdpbmcgYW4gZW50aXJlIHJlcXVlc3QsIGhlYWRlcnMgYW5kIGFsbC4gSSBmZWVs IHRoYXQgd291bGQgYmUgbXVjaCBiZXR0ZXIgYWNjb21wbGlzaGVkIGJ5IGRlZmluaW5nIGEgbmV3 IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lLg0KDQpQaGlsb3NvcGhpY2FsbHksIEkgdGhpbmsg ZXh0ZW5zaWJsZSBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIGFyZSBhIGJhZCBpZGVhLg0KDQpFSEwN Cg0KDQpGcm9tOiBXaWxsaWFtIEouIE1pbGxzIFttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21d PG1haWx0bzpbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXT4NClNlbnQ6IFdlZG5lc2RheSwg QXVndXN0IDAzLCAyMDExIDEwOjI4IEFNDQpUbzogUGhpbGxpcCBIdW50OyBFcmFuIEhhbW1lci1M YWhhdg0KQ2M6IEJlbiBBZGlkYTsgT0F1dGggV0c7IEFkYW0gQmFydGgoYWRhbUBhZGFtYmFydGgu Y29tPG1haWx0bzphZGFtQGFkYW1iYXJ0aC5jb20+KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g TUFDIFRva2VucyBib2R5IGhhc2gNCg0KSW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBJJ20gY29taW5n IGFyb3VuZCB0byB0aGUgdmlld3BvaW50IHRoYXQgYSBzaW5nbGUgYWRkaXRpb25hbCBwcmVkZWZp bmVkIHNwb3QgaXMgc3VmZmljaWVudC4gIElmIHRoZSBhcHAgZGV2ZWxvcGVyIHdhbnRzIHRvIGlu Y2x1ZGUgYWRkdGlvbmFsIGRhdGEgdGhlcmUgKGl1biB0aGUgc3BlY2lmaWVkIGZvcm1hdCkgdGhh dCdzIGZpbmUuICBJZiB3aGF0IHRoZXkgd2FudCB0byBkbyBpcyBpbmNsdWRlIGEgc2lnbmF0dXJl IG9mIG90aGVyIHBheWxvYWQgdGhhdCdzIGZpbmUgdG9vLg0KDQpJJ20gbm90IGluIGxvdmUgd2l0 aCB0aGUgbmFtZSAiYXBwIiB0aG91Z2gsICJleHQiIGlzIGJldHRlci4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IFBoaWxsaXAgSHVudCA8cGhpbC5odW50QG9yYWNs ZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NClRvOiBFcmFuIEhhbW1lci1MYWhh diA8ZXJhbkBodWVuaXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+DQpDYzog QmVuIEFkaWRhIDxiZW5AYWRpZGEubmV0PG1haWx0bzpiZW5AYWRpZGEubmV0Pj47IE9BdXRoIFdH IDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+PjsgIkFkYW0gQmFydGgoYWRh bUBhZGFtYmFydGguY29tPG1haWx0bzphZGFtQGFkYW1iYXJ0aC5jb20+KSIgPGFkYW1AYWRhbWJh cnRoLmNvbTxtYWlsdG86YWRhbUBhZGFtYmFydGguY29tPj4NClNlbnQ6IFR1ZXNkYXksIEF1Z3Vz dCAyLCAyMDExIDc6MTQgUE0NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE1BQyBUb2tlbnMgYm9k eSBoYXNoDQoNCg0KUGhpbA0KDQpPbiAyMDExLTA4LTAyLCBhdCAxODowMiwgRXJhbiBIYW1tZXIt TGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+PiB3 cm90ZToNClRoZSBpZGVhIGlzIHRvIGRyb3AgJ2V4dCcgYW5kICdib2R5aGFzaCcgZHVlIHRvIGJl aW5nIHVuZGVyc3BlY2lmaWVkIGFuZCB0aGVyZWZvcmUgY2F1c2luZyBtb3JlIGhhcm0gdGhhbiBn b29kLiBJIGFkZGVkICdleHQnIHRvIGFsbG93IGZvciBhcHBsaWNhdGlvbiBzcGVjaWZpYyBkYXRh IHRvIGJlIGluY2x1ZGVkIGluIHRoZSBzaWduZWQgY29udGVudC4gSG93ZXZlciwgdGhlIG5hbWUg c3VnZ2VzdHMgdGhpcyBpcyBhbiBleHRlbnNpb24gcG9pbnQgZm9yIGZ1dHVyZSBzcGVjaWZpY2F0 aW9ucy4gSSBiZWxpZXZlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgc2hvdWxkIG5vdCBiZSBleHRl bnNpYmxlIGluIHdheXMgdGhhdCBhZmZlY3QgdGhlaXIgc2VjdXJpdHkgb3IgaW50ZXJvcCBwcm9w ZXJ0aWVzIGFuZCB3aXRob3V0IGFkZGl0aW9uYWwgdGV4dCAocmVnaXN0cnksIHByb2Nlc3MsIGV0 YykgZm9yIHRoZSAnZXh0JyBwYXJhbWV0ZXIsIGl0IHdpbGwgY2F1c2UgbW9yZSBpc3N1ZXMgdGhh biBoZWxwLg0KDQpJbnN0ZWFkIG9mIHRoZSAnZXh0JyBwYXJhbWV0ZXIgSSBhbSBzdWdnZXN0aW5n IHRoZSAnYXBwJyBwYXJhbWV0ZXIgd2hpY2ggd2lsbCBkbyB0aGUgc2FtZSwgYnV0IHdpbGwgYmUg YmV0dGVyIHBvc2l0aW9uZWQgYXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgZGF0YS4gVGhlIHBy b3NlIHdpbGwgZ28gYSBzdGVwIGZ1cnRoZXIgYW5kIHJlY29tbWVuZCB0aGF0IHRoZSBwYXJhbWV0 ZXIgdmFsdWUgaW5jbHVkZSBhIGhhc2ggb2YgdGhlIGRhdGEsIG5vdCB0aGUgZGF0YSBpdHNlbGYu IFRoaXMgaXMgdG8gZW5zdXJlIHRoZSBwYXJhbWV0ZXIgZG9lcyBub3QgYmVjb21lIHBhcnQgb2Yg dGhlIHBheWxvYWQgd2hpY2ggaXMgaW5hcHByb3ByaWF0ZSBmb3IgSFRUUCByZXF1ZXN0cy4NCi0x IHdoYXQgeW91IGRlc2NyaWJlIGFwcGVhcnMgdG8gYmUgYSBzZXBhcmF0ZSBmZWF0dXJlIGZyb20g ZXh0DQoNCkFzIGZvciB0aGUgJ2JvZHloYXNoJyBwYXJhbWV0ZXIsIEkgd291bGQgbGlrZSB0byBy ZW1vdmUgaXQgYmVjYXVzZSBpdCBpcyB1bmRlcnNwZWNpZmllZCAod2UgaGFkIGFuIGFjdHVhbCBk ZXBsb3ltZW50IGV4cGVyaWVuY2Ugc2hvd2luZyB0aGF0IGl0IGRvZXNuJ3QgcHJvZHVjZSBpbnRl cm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBkdWUgdG8gdGhlIG1hbnkgSFRUUCBib2R5IHRyYW5z Zm9ybWF0aW9uIGFwcGxpZWQgaW4gbW9zdCBmcmFtZXdvcmtzKS4gU29sdmluZyB0aGlzIGlzc3Vl IGlzIG5vdCBwb3NzaWJsZSBkdWUgdG8gdGhlIG1hbnkgZGlmZmVyZW50IHR5cGVzIG9mIGJvZGll cyBhbmQgZnJhbWV3b3JrcyAoYW5kIGNsZWFybHkgb3BlcmF0aW5nIG9uIHRoZSAicmF3IiBib2R5 IGRvZXNuJ3Qgd29yaykuIEluc3RlYWQsIGRldmVsb3BlcnMgY2FuIHVzZSB0aGUgbmV3ICdhcHAn IHBhcmFtZXRlciB0byBhY2NvbXBsaXNoIHRoYXQuDQoNCisxDQoNCg0KQXMgZm9yIHRoZSBub3Jt YWxpemVkIHN0cmluZywgaXQgd2lsbCBiZSBhZGp1c3RlZCB0byByZWZsZWN0IHRoZXNlIGNoYW5n ZXMgd2hlbiB0aGV5IGFyZSBtYWRlLCBzbyBubyBwbGFjZWhvbGRlcnMgd2hpY2ggd2lsbCByZXF1 aXJlIGNvZGUgY2hhbmdlLiBDb25zaWRlcmluZyB0aGlzIGlzIC0wMCwgaXQgaXMgY2xlYXJseSBu b3QgYSBzdGFibGUgZG9jdW1lbnQuDQpXaWxsIHRoZXNlIGNoYW5nZXMgd29yayB3aXRoIHlvdXIg dXNlIGNhc2VzPw0KDQpFSEwNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTa3ls YXIgV29vZHdhcmQgW21haWx0bzpza3lsYXJAa2l2YS5vcmddPG1haWx0bzpbbWFpbHRvOnNreWxh ckBraXZhLm9yZ10+DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMDIsIDIwMTEgNDowMiBQTQ0KVG86 IEVyYW4gSGFtbWVyLUxhaGF2DQpDYzogT0F1dGggV0c7IEJlbiBBZGlkYTsgJ0FkYW0gQmFydGgg KGFkYW1AYWRhbWJhcnRoLmNvbTxtYWlsdG86YWRhbUBhZGFtYmFydGguY29tPiknDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBNQUMgVG9rZW5zIGJvZHkgaGFzaA0KDQpodXJyYWghDQoobm90IG5l Y2Vzc2FyaWx5IGZvciBsb3NpbmcgYSB3YXkgdG8gc2lnbiB0aGUgYm9keSwgYnV0IGZvciBzaW1w bGljaXR5IGFuZA0KYXZvaWRpbmcgc29tZSBvZiB0aGUgcG90ZW50aWFsIGluY29uc2lzdGVuY2ll cyB3LyBib2R5aGFzaCkuDQoNCklzIHlvdXIgcGxhbiB0byByZXNlcnZlIGFuIGVtcHR5IGxpbmUg NiBmb3IgdGhlIE5vcm1hbGl6ZWQgUmVxdWVzdCBTdHJpbmcNCih3aGljaCB3YXMgdXNlZCBmb3Ig Ym9keWhhc2gpIG9yIGVsaW1pbmF0ZSBpdCwgYnJpbmluZyB0aGUgdG90YWwgdG8gc2l4DQplbGVt ZW50cz8NCg0Kc2t5bGFyDQoNCk9uIEp1bCAzMCwgMjAxMSwgYXQgMzo0MyBBTSwgRXJhbiBIYW1t ZXItTGFoYXYgd3JvdGU6DQoNCkkgcGxhbiB0byBkcm9wIHN1cHBvcnQgZm9yIHRoZSBib2R5aGFz aCBwYXJhbWV0ZXIgaW4gdGhlIG5leHQgZHJhZnQgYmFzZWQNCm9uIGJhZCBpbXBsZW1lbnRhdGlv biBleHBlcmllbmNlLiBFdmVuIHdpdGggc2ltcGxlIHRleHQgYm9keSwgVVRGDQplbmNvZGluZyBo YXMgaW50cm9kdWNlZCBzaWduaWZpY2FudCBpc3N1ZXMgZm9yIHVzLiBUaGUgY3VycmVudCBkcmFm dCBkb2VzIG5vdA0Kd29yayB1c2luZyBzaW1wbGUgSlMgY29kZSBiZXR3ZWVuIGEgYnJvd3NlciBh bmQgbm9kZS5qcyBldmVuIHdoZW4gYm90aA0KdXNlIHRoZSBzYW1lIHY4IGVuZ2luZSBkdWUgdG8g ZGlmZmVyZW5jZXMgaW4gdGhlIGJvZHkgZW5jb2RpbmcuIEJhc2ljYWxseSwNCnRoZSBKUyBzdHJp bmcgdXNlZCB0byBzZW5kIGEgcmVxdWVzdCBmcm9tIHRoZSBicm93c2VyIGlzIG5vdCB0aGUgYWN0 dWFsIHN0cmluZw0Kc2VudCBvbiB0aGUgd2lyZS4NCg0KVG8gZml4IHRoYXQsIHdlIG5lZWQgdG8g Zm9yY2UgVVRGLTggZW5jb2Rpbmcgb24gYm90aCBzaWRlcy4gSG93ZXZlciwgdGhhdA0KaXMgdmVy eSBtdWNoIGFwcGxpY2F0aW9uIHNwZWNpZmljLiBUaGlzIHdpbGwgbm90IHdvcmsgZm9yIG5vbi10 ZXh0IGJvZGllcy4NCkluc3RlYWQsIHRoZSBzcGVjaWZpY2F0aW9uIHNob3VsZCBvZmZlciBhIHNp bXBsZSB3YXkgdG8gdXNlIHRoZSBleHQgcGFyYW1ldGVyDQpmb3Igc3VjaCBuZWVkcywgaW5jbHVk aW5nIHNpbmdpbmcgaGVhZGVycy4gQW5kIGJ5IG9mZmVyIEkgbWVhbiBnaXZlDQpleGFtcGxlcywg YnV0IGxlYXZlIGl0IGFwcGxpY2F0aW9uIHNwZWNpZmljIGZvciBub3cuDQoNCkkgYW0gb3BlbiB0 byBzdWdnZXN0aW9ucyBidXQgc28gZmFyIGFsbCB0aGUgc29sdXRpb25zIEkgY2FtZSB1cCB3aXRo IHdpbGwNCmludHJvZHVjZSB1bmFjY2VwdGFibGUgY29tcGxleGl0eSB0aGF0IHdpbGwgYmFzaWNh bGx5IG1ha2UgdGhpcyB3b3JrIHVzZWxlc3MuDQoNCkVITA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0 Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1 dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQoNCg== --_000_90C41DD21FB7C64BB94121FBBC2E7234502498CE9AP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC55aXYxMjYyMzQyMTgwbXNvYWNldGF0 ZSwgbGkueWl2MTI2MjM0MjE4MG1zb2FjZXRhdGUsIGRpdi55aXYxMjYyMzQyMTgwbXNvYWNldGF0 ZQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjYyMzQyMTgwbXNvYWNldGF0ZTsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC55aXYxMjYyMzQyMTgwbXNvbm9ybWFs LCBsaS55aXYxMjYyMzQyMTgwbXNvbm9ybWFsLCBkaXYueWl2MTI2MjM0MjE4MG1zb25vcm1hbA0K CXttc28tc3R5bGUtbmFtZTp5aXYxMjYyMzQyMTgwbXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLnlpdjEyNjIzNDIxODBtc29jaHBkZWZhdWx0 LCBsaS55aXYxMjYyMzQyMTgwbXNvY2hwZGVmYXVsdCwgZGl2LnlpdjEyNjIzNDIxODBtc29jaHBk ZWZhdWx0DQoJe21zby1zdHlsZS1uYW1lOnlpdjEyNjIzNDIxODBtc29jaHBkZWZhdWx0Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjEyNjIzNDIx ODBtc29oeXBlcmxpbmsNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTI2MjM0MjE4MG1zb2h5cGVybGlu azt9DQpzcGFuLnlpdjEyNjIzNDIxODBtc29oeXBlcmxpbmtmb2xsb3dlZA0KCXttc28tc3R5bGUt bmFtZTp5aXYxMjYyMzQyMTgwbXNvaHlwZXJsaW5rZm9sbG93ZWQ7fQ0Kc3Bhbi55aXYxMjYyMzQy MTgwZW1haWxzdHlsZTE5DQoJe21zby1zdHlsZS1uYW1lOnlpdjEyNjIzNDIxODBlbWFpbHN0eWxl MTk7fQ0Kc3Bhbi55aXYxMjYyMzQyMTgwYmFsbG9vbnRleHRjaGFyDQoJe21zby1zdHlsZS1uYW1l OnlpdjEyNjIzNDIxODBiYWxsb29udGV4dGNoYXI7fQ0KcC55aXYxMjYyMzQyMTgwbXNvbm9ybWFs MSwgbGkueWl2MTI2MjM0MjE4MG1zb25vcm1hbDEsIGRpdi55aXYxMjYyMzQyMTgwbXNvbm9ybWFs MQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjYyMzQyMTgwbXNvbm9ybWFsMTsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi55aXYxMjYyMzQyMTgwbXNvaHlw ZXJsaW5rMQ0KCXttc28tc3R5bGUtbmFtZTp5aXYxMjYyMzQyMTgwbXNvaHlwZXJsaW5rMTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXYxMjYyMzQy MTgwbXNvaHlwZXJsaW5rZm9sbG93ZWQxDQoJe21zby1zdHlsZS1uYW1lOnlpdjEyNjIzNDIxODBt c29oeXBlcmxpbmtmb2xsb3dlZDE7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC55aXYxMjYyMzQyMTgwbXNvYWNldGF0ZTEsIGxpLnlpdjEyNjIzNDIxODBt c29hY2V0YXRlMSwgZGl2LnlpdjEyNjIzNDIxODBtc29hY2V0YXRlMQ0KCXttc28tc3R5bGUtbmFt ZTp5aXYxMjYyMzQyMTgwbXNvYWNldGF0ZTE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO30NCnNwYW4ueWl2MTI2MjM0MjE4MGVtYWlsc3R5bGUxOTENCgl7bXNvLXN0eWxlLW5h bWU6eWl2MTI2MjM0MjE4MGVtYWlsc3R5bGUxOTE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLnlpdjEyNjIzNDIxODBiYWxsb29udGV4 dGNoYXIxDQoJe21zby1zdHlsZS1uYW1lOnlpdjEyNjIzNDIxODBiYWxsb29udGV4dGNoYXIxOw0K CWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCnAueWl2MTI2MjM0MjE4MG1zb2No cGRlZmF1bHQxLCBsaS55aXYxMjYyMzQyMTgwbXNvY2hwZGVmYXVsdDEsIGRpdi55aXYxMjYyMzQy MTgwbXNvY2hwZGVmYXVsdDENCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTI2MjM0MjE4MG1zb2NocGRl ZmF1bHQxOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu LnlpdjEyNjIzNDIxODB5aXYzODk2Njg4NjZhcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1u YW1lOnlpdjEyNjIzNDIxODB5aXYzODk2Njg4NjZhcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4ueWl2 MTI2MjM0MjE4MHlpdjM4OTY2ODg2NmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUt bmFtZTp5aXYxMjYyMzQyMTgweWl2Mzg5NjY4ODY2YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNw YW4uRW1haWxTdHlsZTMzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVh ZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3Jk U2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TGV04oCZ cyBqdXN0IGtlZXAg4oCYZXh04oCZIGFuZCBkcm9wIOKAmGJvZHloYXNo4oCZLiBTZWVtcyBsaWtl IHRoaXMgc2hvdWxkIHJlc29sdmUgdGhlIGlzc3VlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RUhMPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiBXaWxsaWFtIEouIE1pbGxzIFttYWlsdG86d21pbGxz QHlhaG9vLWluYy5jb21dIDxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMTUsIDIwMTEg OTo0NiBBTTxicj48Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyLUxhaGF2OyBQaGlsIEh1bnQ8YnI+PGI+ Q2M6PC9iPiBPQXV0aCBXRzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTUFDIFRv a2VucyBib2R5IGhhc2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPiZxdW90O2FkZCZxdW90OyBk b2Vzbid0IHJlYWxseSBzYXkgaXQgdG8gbWUgZWl0aGVyLiZuYnNwOyAmcXVvdDthaCZxdW90Oywg c2hvcnQgZm9yICZxdW90O2FkZGl0aW9uYWwgaGFzaCZxdW90OyBpcyBzb21ld2hhdCBtb3JlIG1u ZW1vbmljIGZvciBtZSwgYnV0IHRoZW4gSSB0aGluayAmcXVvdDtleHQmcXVvdDsgaXNuJ3QgaG9y cmlibGUgYmVjYXVzZSBpdCdzIGEgZnJlcXVlbnQgYWJicmV2aWF0aW9uIGZvciBleHRlbnNpb24u PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPi1iaWxsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXYgY2xhc3M9TXNvTm9ybWFs IGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPjxociBzaXplPTEgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj48 L3NwYW4+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBw dDtiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOmJsYWNrJz4gRXJhbiBIYW1tZXItTGFoYXYgJmx0OzxhIGhyZWY9Im1haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDs8YnI+PGI+ VG86PC9iPiBXaWxsaWFtIEouIE1pbGxzICZsdDs8YSBocmVmPSJtYWlsdG86d21pbGxzQHlhaG9v LWluYy5jb20iPndtaWxsc0B5YWhvby1pbmMuY29tPC9hPiZndDs7IFBoaWwgSHVudCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwv YT4mZ3Q7PGJyPjxiPkNjOjwvYj4gT0F1dGggV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBp ZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj48Yj5TZW50OjwvYj4gU3VuZGF5LCBB dWd1c3QgMTQsIDIwMTEgMTE6MjggUE08YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbT0FVVEgtV0dd IE1BQyBUb2tlbnMgYm9keSBoYXNoPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhvdyBhYm91dCDigJhhZGTigJk/ IGFzIGluIOKAnFVzZWQgdG8gaW5jbHVkZSBhZGRpdGlvbmFsIGRhdGEgaW4gdGhlIE1BQyBub3Jt YWxpemVkIHN0cmluZ+KAnS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ RUhMPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2 PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+IFdpbGxpYW0gSi4gTWlsbHMgPGEgaHJlZj0ibWFpbHRvOlttYWls dG86d21pbGxzQHlhaG9vLWluYy5jb21dIj5bbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXTwv YT4gPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDA0LCAyMDExIDY6MDYgUE08YnI+ PGI+VG86PC9iPiBFcmFuIEhhbW1lci1MYWhhdjsgUGhpbCBIdW50PGJyPjxiPkNjOjwvYj4gT0F1 dGggV0c8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE1BQyBUb2tlbnMgYm9keSBo YXNoPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciO2Nv bG9yOmJsYWNrJz5JdCdzIHRoZSBwcm92ZXJiaWFsICd2b2lkICpjbGllbnRfZGF0YTsnIGVxdWl2 YWxlbnQuJm5ic3A7IEFsbCBuYW1lcyBmb3IgdGhhdCB0byBkYXRlIHN1Y2ssIG15IGZhdm9yaXRl IGlzICdyb2NrJy48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 Y29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PGRpdiBjbGFzcz1Nc29Ob3Jt YWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRl Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjpibGFjayc+PGhyIHNpemU9MSB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVy Pjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gRXJhbiBIYW1tZXItTGFoYXYgJmx0 OzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXJh bkBodWVuaXZlcnNlLmNvbTwvYT4mZ3Q7PGJyPjxiPlRvOjwvYj4gUGhpbCBIdW50ICZsdDs8YSBo cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPjxiPkNjOjwvYj4gT0F1dGggV0cgJmx0OzxhIGhyZWY9 Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9h PiZndDs8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgNCwgMjAxMSA0OjQyIFBNPGJy PjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBNQUMgVG9rZW5zIGJvZHkgaGFzaDwvc3Bh bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2IGlkPXlpdjEyNjIzNDIxODB5aXYzODk2Njg4NjY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5P ay4gV2Ugc2VlbSB0byBiZSB1c2luZyBkaWZmZXJlbnQgZGVmaW5pdGlvbnMgb2Ygd2hhdCBhcHBs aWNhdGlvbiBkYXRhIG1lYW4sIGJ1dCBoYXZlIHRoZSBzYW1lIHVzZSBjYXNlcyBpbiBtaW5kLiBJ J2xsIGNvbWUgdXAgd2l0aCBhIGRpZmZlcmVudCBuYW1lIG9yIGp1c3Qga2VlcCBleHQuJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5FSEw8YnI+PGJyPk9uIEF1ZyAzLCAy MDExLCBhdCAxMjo0MiwgJnF1b3Q7UGhpbCBIdW50JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48YmxvY2tx dW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+T25seSBhbGxvd2luZyAoaW1wbGllZCBvciBub3QpIGFwcCBk YXRhIGlzIG5lZWRsZXNzbHkmbmJzcDtuYXJyb3cgaW4gc2NvcGUuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+RXh0ZW5kaW5nIE1B QyB0byBpbmNsdWRlIGNsYWltcyBvciBzZXNzaW9uIGluZm9ybWF0aW9uIGlzIGEgcGVyZmVjdGx5 IHZhbGlkIHRoaW5nIHRvIGRvLiBJdCBpbXByb3ZlcyBzY2FsYWJpbGl0eSBhbmQgcmVkdWNlcyB0 aGUgbmVlZCB0byBsb29rIHVwIGFydGlmYWN0IGRhdGEuJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Tm90ZTogJm5ic3A7 SSdkIGxpa2UgdG8gc2hhcmUgbW9yZSBvbiB0aGlzLCBidXQgSSdtIHByaW9yaXRpemluZyB0aGUg VGhyZWF0IE1vZGVsIGRvY3VtZW50LiBOZXZlci10aGUtbGVzcywgdGhlIGFib3ZlIHNob3VsZCBi ZSBhIHN1ZmZpY2llbnQgZXhhbXBsZSBhYm91dCB3aHkgZXh0ZW5zaWJpbGl0eSBpcyB1c2VmdWwu PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIGNsYXNzPXlpdjEyNjIz NDIxODB5aXYzODk2Njg4NjZhcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 OS4wcHQ7Y29sb3I6YmxhY2snPlBoaWw8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48ZGl2Pjxk aXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkBpbmRlcGVu ZGVudGlkPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBl bmRlbnRpZC5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1ib3R0b206MTMuNXB0Jz48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48YSBocmVmPSJt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3Jh Y2xlLmNvbTwvYT48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndo aXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+T24gMjAxMS0wOC0wMywgYXQgMTE6 MDMgQU0sIEVyYW4gSGFtbWVyLUxhaGF2IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQ7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk15IHBy b3Bvc2FsIGlzIHRvIGNoYW5nZSDigJhleHTigJkgdG8g4oCYYXBw4oCZLCBrZWVwIHRoZSBzYW1l IHByb3NlIGFzIOKAmGV4dOKAmSwgYW5kIGFkZCB0aGUgdXNlIGNhc2Ugb2Yg4oCYYm9keWhhc2ji gJkgYXMgYW4gZXhhbXBsZS4gSeKAmW0gbm90IHRvbyBzdHVjayBvbiB0aGUgbmFtZSwgYnV0IG15 IHRoaW5raW5nIGlzIHRoYXQg4oCYYXBw4oCZIHJlbGF5cyB0aGUgcmlnaHQgbWVzc2FnZSB0aGF0 IHRoaXMgaXMgYSBwbGFjZSB3aGVyZSBkZXZlbG9wZXJzIGNhbiBzdGljayBhbnkgYXBwbGljYXRp b24gZGF0YSB0aGV5IHdhbnQgaW5jbHVkZWQuIOKAmGV4dOKAmSBjb252ZXlzIHRoZSBpZGVhIG9m IGV4dGVuc2lvbnMgd2hpY2ggSeKAmW0gbm90IHNvIHRocmlsbGVkIGFib3V0Ljwvc3Bhbj48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SW4gb3Ro ZXIgd29yZHMsIEnigJlkIGxpa2UgYSBkZXZlbG9wZXIgcmVhZGluZyB0aGlzIHRvIGZlZWwgY29t Zm9ydGFibGUgdXNpbmcgaXQgcmlnaHQgYXdheSBmb3Igc2VjdXJpbmcgYWRkaXRpb24gYml0cyBz dWNoIGFzIGEgSlNPTiBwYXlsb2FkLCBidXQgSSBkb27igJl0IGxpa2UgdGhlIGlkZWEgb2Ygc29t ZW9uZSBwdWJsaXNoaW5nIGFuIEktRCB3aXRoIGEgZnVsbCBzeW50YXggYW5kIGNhbm9uaWNhbGl6 YXRpb24gcmVxdWlyZW1lbnRzIGZvciBzYXksIHNpbmdpbmcgYW4gZW50aXJlIHJlcXVlc3QsIGhl YWRlcnMgYW5kIGFsbC4gSSBmZWVsIHRoYXQgd291bGQgYmUgbXVjaCBiZXR0ZXIgYWNjb21wbGlz aGVkIGJ5IGRlZmluaW5nIGEgbmV3IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lLjwvc3Bhbj48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGhp bG9zb3BoaWNhbGx5LCBJIHRoaW5rIGV4dGVuc2libGUgYXV0aGVudGljYXRpb24gc2NoZW1lcyBh cmUgYSBiYWQgaWRlYS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkVITDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdDtib3JkZXItY29sb3I6aW5pdGlhbCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp bjtib3JkZXItY29sb3I6aW5pdGlhbCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nYmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwv Yj48c3BhbiBjbGFzcz15aXYxMjYyMzQyMTgweWl2Mzg5NjY4ODY2YXBwbGUtY29udmVydGVkLXNw YWNlPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJs YWNrJz5XaWxsaWFtIEouIE1pbGxzIDxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOndtaWxsc0B5YWhv by1pbmMuY29tXSIgdGFyZ2V0PSJfYmxhbmsiPlttYWlsdG86d21pbGxzQHlhaG9vLWluYy5jb21d PC9hPjxzcGFuIGNsYXNzPXlpdjEyNjIzNDIxODB5aXYzODk2Njg4NjZhcHBsZS1jb252ZXJ0ZWQt c3BhY2U+Jm5ic3A7PC9zcGFuPjxicj48Yj5TZW50OjwvYj48c3BhbiBjbGFzcz15aXYxMjYyMzQy MTgweWl2Mzg5NjY4ODY2YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5XZWRuZXNk YXksIEF1Z3VzdCAwMywgMjAxMSAxMDoyOCBBTTxicj48Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9eWl2 MTI2MjM0MjE4MHlpdjM4OTY2ODg2NmFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+ UGhpbGxpcCBIdW50OyBFcmFuIEhhbW1lci1MYWhhdjxicj48Yj5DYzo8L2I+PHNwYW4gY2xhc3M9 eWl2MTI2MjM0MjE4MHlpdjM4OTY2ODg2NmFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3Nw YW4+QmVuIEFkaWRhOyBPQXV0aCBXRzsgQWRhbSBCYXJ0aCg8YSBocmVmPSJtYWlsdG86YWRhbUBh ZGFtYmFydGguY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhbUBhZGFtYmFydGguY29tPC9hPik8YnI+ PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9eWl2MTI2MjM0MjE4MHlpdjM4OTY2ODg2NmFwcGxl LWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+UmU6IFtPQVVUSC1XR10gTUFDIFRva2VucyBi b2R5IGhhc2g8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5JbiB0aGlua2luZyBhYm91dCB0 aGlzIEknbSBjb21pbmcgYXJvdW5kIHRvIHRoZSB2aWV3cG9pbnQgdGhhdCBhIHNpbmdsZSBhZGRp dGlvbmFsIHByZWRlZmluZWQgc3BvdCBpcyBzdWZmaWNpZW50LiZuYnNwOyBJZiB0aGUgYXBwIGRl dmVsb3BlciB3YW50cyB0byBpbmNsdWRlIGFkZHRpb25hbCBkYXRhIHRoZXJlIChpdW4gdGhlIHNw ZWNpZmllZCBmb3JtYXQpIHRoYXQncyBmaW5lLiZuYnNwOyBJZiB3aGF0IHRoZXkgd2FudCB0byBk byBpcyBpbmNsdWRlIGEgc2lnbmF0dXJlIG9mIG90aGVyIHBheWxvYWQgdGhhdCdzIGZpbmUgdG9v Ljwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXci O2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+SSdtIG5vdCBpbiBsb3ZlIHdpdGggdGhl IG5hbWUgJnF1b3Q7YXBwJnF1b3Q7IHRob3VnaCwgJnF1b3Q7ZXh0JnF1b3Q7IGlzIGJldHRlci48 L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48ZGl2IGNsYXNzPU1z b05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48aHIgc2l6ZT0xIHdpZHRoPSIxMDAlIiBhbGlnbj1j ZW50ZXI+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz15aXYxMjYyMzQyMTgweWl2Mzg5 NjY4ODY2YXBwbGUtY29udmVydGVkLXNwYWNlPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5QaGlsbGlwIEh1bnQgJmx0OzxhIGhyZWY9Im1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFj bGUuY29tPC9hPiZndDs8YnI+PGI+VG86PC9iPjxzcGFuIGNsYXNzPXlpdjEyNjIzNDIxODB5aXYz ODk2Njg4NjZhcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPkVyYW4gSGFtbWVyLUxh aGF2ICZsdDs8YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+Jmd0Ozxicj48Yj5DYzo8L2I+PHNwYW4gY2xhc3M9 eWl2MTI2MjM0MjE4MHlpdjM4OTY2ODg2NmFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3Nw YW4+QmVuIEFkaWRhICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQGFkaWRhLm5ldCIgdGFyZ2V0PSJf YmxhbmsiPmJlbkBhZGlkYS5uZXQ8L2E+Jmd0OzsgT0F1dGggV0cgJmx0OzxhIGhyZWY9Im1haWx0 bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPiZndDs7 ICZxdW90O0FkYW0gQmFydGgoPGEgaHJlZj0ibWFpbHRvOmFkYW1AYWRhbWJhcnRoLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmFkYW1AYWRhbWJhcnRoLmNvbTwvYT4pJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86YWRhbUBhZGFtYmFydGguY29tIiB0YXJnZXQ9Il9ibGFuayI+YWRhbUBhZGFtYmFydGgu Y29tPC9hPiZndDs8YnI+PGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9eWl2MTI2MjM0MjE4MHlpdjM4 OTY2ODg2NmFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+VHVlc2RheSwgQXVndXN0 IDIsIDIwMTEgNzoxNCBQTTxicj48Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz15aXYxMjYyMzQy MTgweWl2Mzg5NjY4ODY2YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5SZTogW09B VVRILVdHXSBNQUMgVG9rZW5zIGJvZHkgaGFzaDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2IGlkPXlpdjEyNjIzNDIx ODB5aXYzODk2Njg4NjY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxicj48YnI+UGhpbDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9J21h cmdpbi1ib3R0b206MTIuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dy b3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YnI+T24gMjAxMS0wOC0wMiwg YXQgMTg6MDIsIEVyYW4gSGFtbWVyLUxhaGF2ICZsdDs8YSBocmVmPSJtYWlsdG86ZXJhbkBodWVu aXZlcnNlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGJsb2NrcXVvdGUg c3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPlRoZSBpZGVhIGlzIHRvIGRyb3AgJ2V4dCcgYW5kICdib2R5aGFzaCcg ZHVlIHRvIGJlaW5nIHVuZGVyc3BlY2lmaWVkIGFuZCB0aGVyZWZvcmUgY2F1c2luZyBtb3JlIGhh cm0gdGhhbiBnb29kLiBJIGFkZGVkICdleHQnIHRvIGFsbG93IGZvciBhcHBsaWNhdGlvbiBzcGVj aWZpYyBkYXRhIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBzaWduZWQgY29udGVudC4gSG93ZXZlciwg dGhlIG5hbWUgc3VnZ2VzdHMgdGhpcyBpcyBhbiBleHRlbnNpb24gcG9pbnQgZm9yIGZ1dHVyZSBz cGVjaWZpY2F0aW9ucy4gSSBiZWxpZXZlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgc2hvdWxkIG5v dCBiZSBleHRlbnNpYmxlIGluIHdheXMgdGhhdCBhZmZlY3QgdGhlaXIgc2VjdXJpdHkgb3IgaW50 ZXJvcCBwcm9wZXJ0aWVzIGFuZCB3aXRob3V0IGFkZGl0aW9uYWwgdGV4dCAocmVnaXN0cnksIHBy b2Nlc3MsIGV0YykgZm9yIHRoZSAnZXh0JyBwYXJhbWV0ZXIsIGl0IHdpbGwgY2F1c2UgbW9yZSBp c3N1ZXMgdGhhbiBoZWxwLjxicj48YnI+SW5zdGVhZCBvZiB0aGUgJ2V4dCcgcGFyYW1ldGVyIEkg YW0gc3VnZ2VzdGluZyB0aGUgJ2FwcCcgcGFyYW1ldGVyIHdoaWNoIHdpbGwgZG8gdGhlIHNhbWUs IGJ1dCB3aWxsIGJlIGJldHRlciBwb3NpdGlvbmVkIGFzIGFuIGFwcGxpY2F0aW9uLXNwZWNpZmlj IGRhdGEuIFRoZSBwcm9zZSB3aWxsIGdvIGEgc3RlcCBmdXJ0aGVyIGFuZCByZWNvbW1lbmQgdGhh dCB0aGUgcGFyYW1ldGVyIHZhbHVlIGluY2x1ZGUgYSBoYXNoIG9mIHRoZSBkYXRhLCBub3QgdGhl IGRhdGEgaXRzZWxmLiBUaGlzIGlzIHRvIGVuc3VyZSB0aGUgcGFyYW1ldGVyIGRvZXMgbm90IGJl Y29tZSBwYXJ0IG9mIHRoZSBwYXlsb2FkIHdoaWNoIGlzIGluYXBwcm9wcmlhdGUgZm9yIEhUVFAg cmVxdWVzdHMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2tx dW90ZT48ZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ LTEgd2hhdCB5b3UgZGVzY3JpYmUgYXBwZWFycyB0byBiZSBhIHNlcGFyYXRlIGZlYXR1cmUgZnJv bSBleHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxicj5BcyBmb3IgdGhlICdib2R5aGFzaCcgcGFyYW1ldGVyLCBJIHdvdWxkIGxp a2UgdG8gcmVtb3ZlIGl0IGJlY2F1c2UgaXQgaXMgdW5kZXJzcGVjaWZpZWQgKHdlIGhhZCBhbiBh Y3R1YWwgZGVwbG95bWVudCBleHBlcmllbmNlIHNob3dpbmcgdGhhdCBpdCBkb2Vzbid0IHByb2R1 Y2UgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgZHVlIHRvIHRoZSBtYW55IEhUVFAgYm9k eSB0cmFuc2Zvcm1hdGlvbiBhcHBsaWVkIGluIG1vc3QgZnJhbWV3b3JrcykuIFNvbHZpbmcgdGhp cyBpc3N1ZSBpcyBub3QgcG9zc2libGUgZHVlIHRvIHRoZSBtYW55IGRpZmZlcmVudCB0eXBlcyBv ZiBib2RpZXMgYW5kIGZyYW1ld29ya3MgKGFuZCBjbGVhcmx5IG9wZXJhdGluZyBvbiB0aGUgJnF1 b3Q7cmF3JnF1b3Q7IGJvZHkgZG9lc24ndCB3b3JrKS4gSW5zdGVhZCwgZGV2ZWxvcGVycyBjYW4g dXNlIHRoZSBuZXcgJ2FwcCcgcGFyYW1ldGVyIHRvIGFjY29tcGxpc2ggdGhhdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPisxPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRp dj48ZGl2IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YnI+QXMgZm9yIHRoZSBub3JtYWxpemVk IHN0cmluZywgaXQgd2lsbCBiZSBhZGp1c3RlZCB0byByZWZsZWN0IHRoZXNlIGNoYW5nZXMgd2hl biB0aGV5IGFyZSBtYWRlLCBzbyBubyBwbGFjZWhvbGRlcnMgd2hpY2ggd2lsbCByZXF1aXJlIGNv ZGUgY2hhbmdlLiBDb25zaWRlcmluZyB0aGlzIGlzIC0wMCwgaXQgaXMgY2xlYXJseSBub3QgYSBz dGFibGUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2Pjxi bG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxk aXY+PGRpdj48ZGl2IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPldpbGwgdGhlc2UgY2hhbmdlcyB3b3JrIHdpdGggeW91ciB1c2Ug Y2FzZXM/PGJyPjxicj5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkZyb206IFNreWxhciBX b29kd2FyZDxzcGFuIGNsYXNzPXlpdjEyNjIzNDIxODB5aXYzODk2Njg4NjZhcHBsZS1jb252ZXJ0 ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnNreWxhckBraXZh Lm9yZ10iIHRhcmdldD0iX2JsYW5rIj5bbWFpbHRvOnNreWxhckBraXZhLm9yZ108L2E+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHls ZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPlNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwMiwgMjAxMSA0OjAyIFBNPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PlRvOiBFcmFuIEhhbW1lci1MYWhhdjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5DYzogT0F1dGggV0c7IEJlbiBBZGlk YTsgJ0FkYW0gQmFydGggKDxhIGhyZWY9Im1haWx0bzphZGFtQGFkYW1iYXJ0aC5jb20iIHRhcmdl dD0iX2JsYW5rIj5hZGFtQGFkYW1iYXJ0aC5jb208L2E+KSc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+U3ViamVjdDog UmU6IFtPQVVUSC1XR10gTUFDIFRva2VucyBib2R5IGhhc2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBz dHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPmh1cnJhaCE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+KG5vdCBuZWNlc3NhcmlseSBmb3IgbG9zaW5n IGEgd2F5IHRvIHNpZ24gdGhlIGJvZHksIGJ1dCBmb3Igc2ltcGxpY2l0eSBhbmQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+YXZvaWRpbmcgc29tZSBvZiB0aGUgcG90ZW50aWFsIGluY29uc2lzdGVuY2llcyB3LyBib2R5 aGFzaCkuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48Ymxv Y2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dy b3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JcyB5b3VyIHBsYW4gdG8gcmVz ZXJ2ZSBhbiBlbXB0eSBsaW5lIDYgZm9yIHRoZSBOb3JtYWxpemVkIFJlcXVlc3QgU3RyaW5nPG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBz dHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPih3aGljaCB3YXMgdXNlZCBmb3IgYm9keWhhc2gpIG9yIGVsaW1pbmF0ZSBpdCwg YnJpbmluZyB0aGUgdG90YWwgdG8gc2l4PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPmVsZW1lbnRzPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxi bG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+c2t5bGFyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNr Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz5PbiBKdWwgMzAsIDIwMTEsIGF0IDM6NDMgQU0sIEVyYW4gSGFtbWVyLUxhaGF2IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg c3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQnPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+SSBwbGFuIHRvIGRyb3Agc3VwcG9ydCBmb3Ig dGhlIGJvZHloYXNoIHBhcmFtZXRlciBpbiB0aGUgbmV4dCBkcmFmdCBiYXNlZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+b24gYmFkIGltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2UuIEV2ZW4gd2l0 aCBzaW1wbGUgdGV4dCBib2R5LCBVVEY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ZW5jb2RpbmcgaGFzIGludHJvZHVj ZWQgc2lnbmlmaWNhbnQgaXNzdWVzIGZvciB1cy4gVGhlIGN1cnJlbnQgZHJhZnQgZG9lcyBub3Q8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl IHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+d29yayB1c2luZyBzaW1wbGUgSlMgY29kZSBiZXR3ZWVuIGEgYnJvd3NlciBh bmQgbm9kZS5qcyBldmVuIHdoZW4gYm90aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dy b3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz51c2UgdGhlIHNhbWUgdjggZW5n aW5lIGR1ZSB0byBkaWZmZXJlbmNlcyBpbiB0aGUgYm9keSBlbmNvZGluZy4gQmFzaWNhbGx5LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg c3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz50aGUgSlMgc3RyaW5nIHVzZWQgdG8gc2VuZCBhIHJlcXVlc3QgZnJvbSB0aGUg YnJvd3NlciBpcyBub3QgdGhlIGFjdHVhbCBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+c2VudCBvbiB0aGUg d2lyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxibG9j a3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5UbyBmaXgg dGhhdCwgd2UgbmVlZCB0byBmb3JjZSBVVEYtOCBlbmNvZGluZyBvbiBib3RoIHNpZGVzLiBIb3dl dmVyLCB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5pcyB2ZXJ5IG11Y2ggYXBwbGljYXRp b24gc3BlY2lmaWMuIFRoaXMgd2lsbCBub3Qgd29yayBmb3Igbm9uLXRleHQgYm9kaWVzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5 bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz5JbnN0ZWFkLCB0aGUgc3BlY2lmaWNhdGlvbiBzaG91bGQgb2ZmZXIgYSBzaW1wbGUg d2F5IHRvIHVzZSB0aGUgZXh0IHBhcmFtZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5mb3Igc3VjaCBuZWVkcywg aW5jbHVkaW5nIHNpbmdpbmcgaGVhZGVycy4gQW5kIGJ5IG9mZmVyIEkgbWVhbiBnaXZlPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHls ZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPmV4YW1wbGVzLCBidXQgbGVhdmUgaXQgYXBwbGljYXRpb24gc3BlY2lmaWMgZm9yIG5v dy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxibG9ja3F1 b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2Pjwv YmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5JIGFtIG9wZW4g dG8gc3VnZ2VzdGlvbnMgYnV0IHNvIGZhciBhbGwgdGhlIHNvbHV0aW9ucyBJIGNhbWUgdXAgd2l0 aCB3aWxsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Js b2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5pbnRyb2R1Y2UgdW5hY2NlcHRhYmxlIGNv bXBsZXhpdHkgdGhhdCB3aWxsIGJhc2ljYWxseSBtYWtlIHRoaXMgd29yayB1c2VsZXNzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5 bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGJsb2NrcXVvdGUgc3R5 bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1 b3RlPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Jz48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNr Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkVITDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl IHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxibG9ja3F1b3Rl IHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdj b2xvcjpibGFjayc+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYmxvY2tx dW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Jz48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRl Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxibG9ja3F1 b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9k aXY+PC9kaXY+PGRpdiBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxkaXYgc3R5bGU9J21h cmdpbi1ib3R0b206MTIuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PGJyPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj48YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9y ZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2 PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGRpdiBzdHlsZT0n bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJv dHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1 dGggbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_90C41DD21FB7C64BB94121FBBC2E7234502498CE9AP3PW5EX1MB01E_-- From wmills@yahoo-inc.com Mon Aug 15 10:06:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC2221F8C96 for ; Mon, 15 Aug 2011 10:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.2 X-Spam-Level: X-Spam-Status: No, score=-17.2 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIkH9U6PZRqx for ; Mon, 15 Aug 2011 10:06:51 -0700 (PDT) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) by ietfa.amsl.com (Postfix) with SMTP id 50DA521F8C90 for ; Mon, 15 Aug 2011 10:06:51 -0700 (PDT) Received: from [98.139.212.145] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 15 Aug 2011 17:07:30 -0000 Received: from [98.139.212.244] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 15 Aug 2011 17:07:30 -0000 Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 15 Aug 2011 17:07:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 550475.55893.bm@omp1053.mail.bf1.yahoo.com Received: (qmail 87098 invoked by uid 60001); 15 Aug 2011 17:07:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313428050; bh=Qb2saCMiziqseBmmMydXSq5+mz3W4+t0SfZ8DA6fuBs=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WW/9rqTmtZG895htcMWFp1+CJ26YdnFwhkkYbdpdx20VrVAuCBOaUcc8L9dyQ1gc6LSKsAcklp2jocCNIERhbRh60BJZ9t2dx3Li2b0YqWLS0L63atVA7FN+JuadYjkiLsi1a/r2pc9X1onzrtSafpYEH0uXX/XNgGKjlaq9GIo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QDbNq+X+qIedQUZIzAafEHC24i0hURVxufFRuqDSoj1QimzYQIw0RNEwJJJ5+SIFZSA3bCAO5nbUTxOhXN9EIdWj2YLU+XVVqC4VjbyWOT67w5hHa+p6p5SWyhkxDe7BZTJl3x8LqNbC+CCcYJPporw40VMw1qRYLJv/X3cHjUs=; X-YMail-OSG: g7vZnygVM1mxbTdDOejOXWqRS6AtOQ2z7m4X9farIX.O6XT uAa5lom7K8VLPe596qxSrgXStcwSKjfSgP_mVrMvswyYh4e_Dtjfq8uRIQiP T47TVzIg9bBTnGnp64ORgGNmnY8AqfjWtReA6tpI5eaiW2YW5BA0tM1KV5no TROJ45Hdj04RTnZs33t2pi3vYkA6LEcJHBjHhNIKyvlEVhzE5TX1Jr2UEMjs .a3FkKSk2z28lift_84X5j3we44nrjHpyNqfOAYgLblQYohXhEwjHRNzbt5J BpTqwfnfqp1dE7m9JkvvqAb.c7dXjOa25NOC0Tre8lQCkPCBFW7Tfs45amvB 8n2Jq8cjloFT9V.zrWbg1OWyntKIWIQsUv9lpX2O.7w12sS5F1lnwtFxexCC .z9Ah_uZUlj3ehC4FU18- Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Mon, 15 Aug 2011 10:07:29 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <4E46207A.6080404@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1313428049.81355.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Mon, 15 Aug 2011 10:07:29 -0700 (PDT) From: "William J. Mills" To: Barry Leiba , Anthony Nadalin In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-995464739-1313428049=:81355" Cc: "OAuth WG \(oauth@ietf.org\)" , "eran@sled.com" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 17:06:52 -0000 --0-995464739-1313428049=:81355 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'm a -1 on both of these until I re-read the attack description and really= parse this again.=A0 Perhaps I'm being confused by the usage of "client" h= ere.=A0 My initial reaction is that any time we are relying on the client t= o protect itself from CSRF it is a mistake.=0A=0AI do think that CSRF prote= ction is REQUIRED, the remaining question is whether it's reasonable to for= ce folks to use the state parameter.=A0 My gut says it's not unreasonable t= o force this simple model.=0A=0A=0AI also don't particularly like either CS= RF description used.=A0 As I've said before I think there are better discus= sions of it out there.=0A=0AMore later when I have more time to think on th= is.=0A=0A-bill=0A=0A=0A=0A________________________________=0AFrom: Barry Le= iba =0ATo: Anthony Nadalin = =0ACc: "eran@sled.com" ; "OAuth WG (oauth@ietf.org)" =0ASent: Monday, August 15, 2011 8:06 AM=0ASubject: Re: [OAUTH-WG]= Auth Code Swap Attack=0A=0AOn Mon, Aug 15, 2011 at 10:51 AM, Anthony Nadal= in wrote:=0A> That's nice, four people come up with= text and you decide to use your text.=0A> Making state optional does nothi= ng to fix the protocol issue, people will get=0A> this wrong and have. Our = developers have been through this and agreed=0A> upon the text that was gen= erated. They find the text in the current draft=0A> unacceptable and confus= ing and think that new text is acceptable.=0A=0AI have to agree with what T= ony says above.=A0 The text proposed in his=0Amessage was agreed upon by se= veral WG participants, and unless there's=0Asome significant objection to i= t I think we should use it in the -21=0Aversion, subject to final WG review= .=0A=0ABarry, as chair=0A_______________________________________________=0A= OAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo= /oauth --0-995464739-1313428049=:81355 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'm a -1 on both of these until I re-read the attack description and real= ly parse this again.  Perhaps I'm being confused by the usage of "clie= nt" here.  My initial reaction is that any time we are relying on the = client to protect itself from CSRF it is a mistake.

I do think that CSRF protection is REQUIRED, the remaining questio= n is whether it's reasonable to force folks to use the state parameter.&nbs= p; My gut says it's not unreasonable to force this simple model.
<= div>
I also don't particularly like either= CSRF description used.  As I've said before I think there are better = discussions of it out there.

<= span>More later when I have more time to think on this.

-bill
<= /div>

From:= Barry Leiba <barryleiba@computer.org>
To: Anthony Nadalin <tonynad@microsoft.com>=
Cc: "eran@sled.com" &l= t;eran@sled.com>; "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
= Sent: Monday, August 15, 2= 011 8:06 AM
Subject: Re= : [OAUTH-WG] Auth Code Swap Attack

On Mon, Aug 15, 2011 at 10= :51 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:=
> That's nice, four people come up with text and you decide to use y= our text.
> Making state optional does nothing to fix the protocol is= sue, people will get
> this wrong and have. Our developers have been = through this and agreed
> upon the text that was generated. They find= the text in the current draft
> unacceptable and confusing and think= that new text is acceptable.

I have to agree with what Tony says ab= ove.  The text proposed in his
message was agreed upon by several W= G participants, and unless there's
some significant objection to it I th= ink we should use it in the -21
version, subject to final WG review.
=
Barry, as chair
_______________________________________________
O= Auth mailing list
OAuth@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/oauth


<= /body> --0-995464739-1313428049=:81355-- From torsten@lodderstedt.net Mon Aug 15 13:34:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EB311E8100 for ; Mon, 15 Aug 2011 13:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWWkAGXhq0zO for ; Mon, 15 Aug 2011 13:34:43 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id 361E311E80E5 for ; Mon, 15 Aug 2011 13:34:43 -0700 (PDT) Received: from [87.142.249.124] (helo=[192.168.71.35]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qt3se-0007LJ-0i; Mon, 15 Aug 2011 22:35:28 +0200 Message-ID: <4E498313.3080009@lodderstedt.net> Date: Mon, 15 Aug 2011 22:35:31 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72345021F37877@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DAAEA.7090304@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CDDE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" , "eran@sled.com" Subject: Re: [OAUTH-WG] redirect uri validation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 20:34:44 -0000 Hi Eran, Am 15.08.2011 08:57, schrieb Eran Hammer-Lahav: > Added to 1.4.2: > > When issuing an implicit grant, the authorization server does not authenticate the > client and [[in some cases]], the client identity [[can]] be verified via the redirection URI > used to deliver the access token to the client. The access token may be exposed to the > resource owner or other applications with access to the resource owner's user-agent. > > Hope this is sufficient. What do you want to express? Clients can sometimes be verified via redirection URI? My intention was to point out that an invalid redirect URI is a counter-evidence for a client's identity but a valid redirect URI is _not_ an evidence for its identity. I would suggest to add the text below to section 10.1., last paragraph after the sentence "For example, by requiring the registration of the client redirection URI or enlisting the resource owner to confirm identity." proposed text: Please note: while an invalid redirection URI indicates a counterfeit client, a valid redirection URI is not sufficient to confirm a client's identity. regards, Torsten. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Eran Hammer-Lahav >> Sent: Sunday, August 14, 2011 11:09 PM >> To: Torsten Lodderstedt >> Cc: torsten@lodderstedt-online.de; oauth@ietf.org >> Subject: Re: [OAUTH-WG] redirect uri validation >> >> Where would you suggest I add this? >> >> EHL >> >>> -----Original Message----- >>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>> Sent: Monday, July 25, 2011 10:42 AM >>> To: Eran Hammer-Lahav >>> Cc: torsten@lodderstedt-online.de; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] redirect uri validation >>> >>> Hi Eran, >>> >>>>>> OAuth 1.0 was highly criticized for failing to address client >>>>>> identity in public clients. I believe OAuth 2.0 offers a much >>>>>> better story, within the boundaries>of what’s possible today. >>>>> Agreed. I think we must honestly discuss the value of client >>>>> authentication/identification itself. I personally think it is >>>>> over-emphazised right now. The strength of OAuth 2.0 is that it >>>>> allows solutions where neither client nor resource server have >>>>> access or >>> do store end-user credentials. >>>>> Client authentication is nice but not the main feature. >>>> Do you have any specific suggestions not already mentioned on the list? >>> I would suggest to mention that while an invalid redirect_uri >>> indicates a counterfeit clients a valid redirect does not prove the calling >> client's identity. >>> regards, >>> Torsten. >>> >>> >>>> EHL >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Mon Aug 15 18:45:27 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD0E21F8C64 for ; Mon, 15 Aug 2011 18:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.271 X-Spam-Level: X-Spam-Status: No, score=-17.271 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3erlEGUNiKZ for ; Mon, 15 Aug 2011 18:45:26 -0700 (PDT) Received: from nm10.bullet.mail.bf1.yahoo.com (nm10.bullet.mail.bf1.yahoo.com [98.139.212.169]) by ietfa.amsl.com (Postfix) with SMTP id 2C06321F8C63 for ; Mon, 15 Aug 2011 18:45:26 -0700 (PDT) Received: from [98.139.212.146] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 16 Aug 2011 01:41:08 -0000 Received: from [98.139.212.217] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 16 Aug 2011 01:41:08 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 16 Aug 2011 01:41:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 110577.91703.bm@omp1026.mail.bf1.yahoo.com Received: (qmail 96604 invoked by uid 60001); 16 Aug 2011 01:41:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313458867; bh=QXmK04Lf8DPksbGxtWEByFFOjW92zZEupoBYSG/VvzU=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gEqLDrX9NCXraDvyxH8p6MAjkPbUj365jG2sAGMGyzdDYa4ZLLoE/ly/8XVVMWkpU+6kFn4P6aTQzx+Sns1eNgsDs3heaogkjVgU49GtsbILNI/IkhBMjmgsL7WtlPHS1pG4I+DImnv2S5fNoNfBf40EyfcvISYt5nRYlhWN2cU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TLHP6X4Dm0ZxRmla1kIWwk4Du3IQ3PhiuOfYOcC57vevKXrk/NX407VQVlgYA8jNBJrQu63pHVH6KnRNzqpakspt6/eZFHo5ssbbvr2Ly4vNKDJweMvFWpF2E2evYRm4ojn/g2p8OYMBnmdwNNg2JpsEk1snwFe3nC56eusri+k=; X-YMail-OSG: AnPCbnIVM1npc38pmczyWDrek6jNLgfDaMI3oR8Lbt0xrg. d.2y0d1Z5FM7MRPbeTumngZo.S5tkXkUUR_H0z443BISeVCzoiuGJEcXdCbg Eoo8HIFJBK8KvV_ExTT6DIn.Fs3zwMWlEIkJYPX_IfpkpCG8.MhYnANAaZoJ m_1EfXx27tEGqOHVqFp3Pkb6742obUPpWewmtCvByGgHMu6fN747d.aNB2.q S0VWQ9ZWhIhATyEMYo8MjBPFtWl9cDAX1QNJ79XCP8tO3WqOg7BrvoDtc0pa hHieJRlhiLXDUnyyAJSMVe0mOt7M9L4bsHzX1xKgV5EMHnpSHZcMbZqzR16h Zi7F89AuM4Pv6156DETGaw71XGb9m69sW1zMg4OX_SBqO3i_4hSZhZ4JJuaK Gttg1JXJFsmoJ7w32sBWll12R4FhSBMbRPfdqLZOCjw-- Received: from [209.131.62.113] by web31804.mail.mud.yahoo.com via HTTP; Mon, 15 Aug 2011 18:41:07 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <4E46207A.6080404@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1313428049.81355.YahooMailNeo@web31811.mail.mud.yahoo.com> Message-ID: <1313458867.58222.YahooMailNeo@web31804.mail.mud.yahoo.com> Date: Mon, 15 Aug 2011 18:41:07 -0700 (PDT) From: "William J. Mills" To: "William J. Mills" , Barry Leiba , Anthony Nadalin In-Reply-To: <1313428049.81355.YahooMailNeo@web31811.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-981699020-1313458867=:58222" Cc: "OAuth WG \(oauth@ietf.org\)" , "eran@sled.com" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 01:45:27 -0000 --0-981699020-1313458867=:58222 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable After thinking about this and getting on the phone with Eran, I think makin= g "state" required isn't right (because we're dictating one solution/format= to no real point), but CSRF protection *is* REQUIRED.=A0 I also think that= we're probably not sufficiently clear about which state parameter we're ta= lking about, since we have 2, but that's a different question). The core of= the problem described =0Ain the first message of this topic is a plain CSR= F vulnerability of the =0Aredirect URI.=A0 Alice's (our victim) browser vis= its the malicious =0Aredirect URI, presents her credential, and the bad thi= ng happens.=0A=0AI'm proposing a 3rd variant.=A0 The original -20 text is i= ncluded below, it's closer to where I think we should be.=A0 This leans on = a rather fuzzy-term "non-guessable" but I'm OK with it if no on else object= s.=0A=0A=0A=0A10.12.=A0=A0Cross-Site Request Forgery=0A=0ACross-site reques= t forgery (CSRF) =0Ais an attack whereby malicious URLs are sent to the use= r-agent of an end user (generally as hidden links or images) and transmitte= d from the =0Auser-agent the server trusts or has authenticated. The most c= ommonly exploited mechanism for this is credentials held in cookies automat= ically presented by a web browser.=A0 CSRF attacks against the client's red= irection URI allow =0Aan attacker to inject their own authorization code or= access token, =0Awhich can result in the client using an access token asso= ciated with the attacker's account rather than the victim's.=A0 CSRF =0Aatt= acks are also possible against an authorization endpoint. =A0=0A=0AClient a= pplications MUST implement CSRF protection for the redirection URI.=A0 CSRF= protection for a request is data included in the request that ties that re= quest to the user's authenticated state, i.e. a cryptographic signature of = the user credential and the redirection URI path.=A0 Upon receipt of a requ= est the client application computes the CSRF data based on the presented cr= edential and compares that to the CSRF protection data presented in the req= uest.=A0 CSRF protection data MUST contain a non-guessable value, and the c= lient MUST keep it in a =0Alocation accessible only by the client or the us= er-agent (i.e., =0Aprotected by same-origin policy). The "state" redirectio= n URI parameter is provided as one method of carrying CSRF protection data,= and is RECOMMENDEDto provide the greatest compatibility with systems imple= menting strong redirection URI validation.=A0 =0A=0A=0AIt is strongly RECOM= MENDED that =0Athe client includes the "state" request parameter with autho= rization =0Arequests to the authorization server.=A0=A0The "state" request = parameter =0AMUST contain a non-guessable value, and the client MUST keep i= t in a =0Alocation accessible only by the client or the user-agent (i.e., = =0Aprotected by same-origin policy). =0A=0A=0AFor example, using a DOM vari= able, HTTP cookie, or HTML5 client-side =0Astorage.=A0=A0The authorization = server includes the value of the "state" =0Aparameter when redirecting the = user-agent back to the client which MUST =0Athen ensure the received value = matches the stored value. =0A=0A=0A=0A=0AOriginal -20 text:=0A=0A=0A10.12.= =A0=A0Cross-Site Request Forgery=0A=0ACross-site request forgery (CSRF) is = a web-based attack whereby HTTP requests are transmitted from the user-agen= t of an end-user the server trusts or has authenticated.=A0=A0CSRF attacks = on the authorization endpoint can allow an attacker to obtain authorization= without the consent of the resource owner. =0A=0A=0AThe "state" request pa= rameter SHOULD be used to mitigate against CSRF attacks, particularly for l= ogin CSRF attacks.=A0 CSRF attacks against the client's redirection URI all= ow an attacker to inject their own authorization code or access token, whic= h can result in the client using an access token associated with the attack= er's account rather than the victim's.=A0=A0Depending on the nature of the = client and the protected resources, this can have undesirable and damaging = effects. =0A=0A=0AIt is strongly RECOMMENDED that the client includes the "= state" request parameter with authorization requests to the authorization s= erver.=A0=A0The "state" request parameter MUST contain a non-guessable valu= e, and the client MUST keep it in a location accessible only by the client = or the user-agent (i.e., protected by same-origin policy). =0A=0A=0AFor exa= mple, using a DOM variable, HTTP cookie, or HTML5 client-side storage.=A0= =A0The authorization server includes the value of the "state" parameter whe= n redirecting the user-agent back to the client which MUST then ensure the = received value matches the stored value. =0A=0A=0A=0A______________________= __________=0AFrom: William J. Mills =0ATo: Barry Leib= a ; Anthony Nadalin =0ACc: = "OAuth WG (oauth@ietf.org)" ; "eran@sled.com" =0ASent: Monday, August 15, 2011 10:07 AM=0ASubject: Re: [OAUTH-WG] Auth = Code Swap Attack=0A=0A=0AI'm a -1 on both of these until I re-read the atta= ck description and really parse this again.=A0 Perhaps I'm being confused b= y the usage of "client" here.=A0 My initial reaction is that any time we ar= e relying on the client to protect itself from CSRF it is a mistake.=0A=0AI= do think that CSRF protection is REQUIRED, the remaining question is wheth= er it's reasonable to force folks to use the state parameter.=A0 My gut say= s it's not unreasonable to force this simple model.=0A=0A=0AI also don't pa= rticularly like either CSRF description used.=A0 As I've said before I thin= k there are better discussions of it out there.=0A=0AMore later when I have= more time to think on this.=0A=0A-bill=0A=0A=0A=0A________________________= ________=0AFrom: Barry Leiba =0ATo: Anthony Nadali= n =0ACc: "eran@sled.com" ; "OAuth WG = (oauth@ietf.org)" =0ASent: Monday, August 15, 2011 8:06 AM= =0ASubject: Re: [OAUTH-WG] Auth Code Swap Attack=0A=0AOn Mon, Aug 15, 2011 = at 10:51 AM, Anthony Nadalin wrote:=0A> That's nice= , four people come up with text and you decide to use your text.=0A> Making= state optional does nothing to fix the protocol issue, people will get=0A>= this wrong and have. Our developers have been through this and agreed=0A> = upon the text that was generated. They find the text in the current draft= =0A> unacceptable and confusing and think that new text is acceptable.=0A= =0AI have to agree with what Tony says above.=A0 The text proposed in his= =0Amessage was agreed upon by several WG participants, and unless there's= =0Asome significant objection to it I think we should use it in the -21=0Av= ersion, subject to final WG review.=0A=0ABarry, as chair=0A________________= _______________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/oauth=0A=0A=0A=0A_______________________= ________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://ww= w.ietf.org/mailman/listinfo/oauth --0-981699020-1313458867=:58222 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Afte= r thinking about this and getting on the phone with Eran, I think making "s= tate" required isn't right (because we're dictating one solution/format to = no real point), but CSRF protection *is* REQUIRED.  I also think that = we're probably not sufficiently clear about which state parameter we're tal= king about, since we have 2, but that's a different question). The core of = the problem described =0Ain the first message of this topic is a plain CSRF= vulnerability of the =0Aredirect URI.  Alice's (our victim) browser v= isits the malicious =0Aredirect URI, presents her credential, and the bad t= hing happens.

I'm proposing a 3rd variant.  T= he original -20 text is included below, it's closer to where I think we sho= uld be.  This leans on a rather fuzzy-term "non-guessable" but I'm OK = with it if no on else objects.


10.12.  Cross-Site Request Forgery=0A

=0A
Cross-site request forgery (CS= RF) =0Ais an attack whereby malicious URLs are sent to the user-agent of an= end user (generally as hidden links or images) and transmitted from the = =0Auser-agent the server trusts or has authenticated. The most commonly exp= loited mechanism for this is credentials held in cookies automatically pres= ented by a web browser.  CSRF attacks against the client's redirection= URI allow =0Aan attacker to inject their own authorization code or access = token, =0Awhich can result in the client using an access token associated w= ith the=0A attacker's account rather than the victim's.  CSRF =0Aattac= ks are also possible against an authorization endpoint.  =0A
=0A
=0A
=0A
Client applications MUST implement CSRF protection for the red= irection URI.  CSRF protection for a request is data included in the r= equest that ties that request to the user's authenticated state, i.e. a cry= ptographic signature of the user credential and the redirection URI path.&n= bsp; Upon receipt of a request the client application computes the CSRF dat= a based on the presented credential and compares that to the CSRF protectio= n data presented in the request.  CSRF protection data MUST contain a = non-guessable value, and the client MUST keep it in a =0Alocation accessibl= e only by the client or the user-agent (i.e., =0Aprotected by same-origin p= olicy). The "state" redirection URI parameter is provided as one method of = carrying CSRF protection data, and is RECOMMENDED to provide the greatest c= ompatibility with systems implementing strong redirection URI validation.&n= bsp;
=0A

=0A
=0A
It is strongly RECOMMENDED that =0Athe clie= nt includes the "state" request parameter with authorization =0Arequests to= the authorization server.  The "state" request parameter =0AMUST= contain a non-guessable value, and the client MUST keep it in a =0Alocatio= n accessible only by the client or the user-agent (i.e., =0Aprotected by sa= me-origin policy).
=0A
=0A
=

=0A
=0AFor example, using a DOM variable, HTTP cookie, or HTML5 client-si= de =0Astorage.  The authorization server includes the value of th= e "state" =0Aparameter when redirecting the user-agent back to the client w= hich MUST =0Athen ensure the received value matches the stored value.
<= /div>



Original -20 text:
10.12.  Cross-Site = Request Forgery

Cross-site request forgery (CSRF) is a web-based at= tack whereby HTTP requests are transmitted from the user-agent of an end-us= er the server trusts or has authenticated.  CSRF attacks on the a= uthorization endpoint can allow an attacker to obtain authorization without= the consent of the resource owner.

The "state" request parame= ter SHOULD be used to mitigate against CSRF attacks, particularly for login= CSRF attacks.  CSRF attacks against the client's redirection URI allo= w an attacker to inject their own authorization code or access token, which= can result in the client using an access token associated with the attacker's account ra= ther than the victim's.  Depending on the nature of the client an= d the protected resources, this can have undesirable and damaging effects. =

It is strongly RECOMMENDED that the client includes the "state= " request parameter with authorization requests to the authorization server= .  The "state" request parameter MUST contain a non-guessable val= ue, and the client MUST keep it in a location accessible only by the client= or the user-agent (i.e., protected by same-origin policy).

Fo= r example, using a DOM variable, HTTP cookie, or HTML5 client-side storage.=   The authorization server includes the value of the "state" para= meter when redirecting the user-agent back to the client which MUST then ensure the received value matches the stored value.

________________________________
From: William J. Mills <wmills@yaho= o-inc.com>
To: Barry Leiba <barryleiba@computer.org>; Anthony N= adalin <tonynad@microsoft.com>
Cc: "OAuth WG (oauth@ietf.org)" <= ;oauth@ietf.org>; "eran@sled.com" <eran@sled.com>
Sent: Monday,= August 15, 2011 10:07 AM
Subject: Re: [OAUTH-WG] Auth Code Swap Attack<= br>

I'm a -1 on both of these until I re-read the attack description= and really parse this again.  Perhaps I'm being confused by the usage= of "client" here.  My initial reaction is that any time we are relyin= g on the client to protect itself from CSRF it is a mistake.

I do th= ink that CSRF protection is REQUIRED, the remaining question is whether it'= s reasonable to force folks to use the state parameter.  My gut says i= t's not unreasonable to force this simple model.


I also don't particularly like either CSRF description used.  As I've said b= efore I think there are better discussions of it out there.

More lat= er when I have more time to think on this.

-bill



____= ____________________________
From: Barry Leiba <barryleiba@computer.o= rg>
To: Anthony Nadalin <tonynad@microsoft.com>
Cc: "eran@sl= ed.com" <eran@sled.com>; "OAuth WG (oauth@ietf.org)" <oauth@ietf.o= rg>
Sent: Monday, August 15, 2011 8:06 AM
Subject: Re: [OAUTH-WG] = Auth Code Swap Attack

On Mon, Aug 15, 2011 at 10:51 AM, Anthony Nada= lin <tonynad@microsoft.com> wrote:
> That's nice, four people c= ome up with text and you decide to use your text.
> Making state opti= onal does nothing to fix the protocol issue, people will get
> this w= rong and have. Our developers have been through this and agreed
> upo= n the text that was generated. They find the text in the current draft
> unacceptable and confusing and think that new text is accept= able.

I have to agree with what Tony says above.  The text prop= osed in his
message was agreed upon by several WG participants, and unle= ss there's
some significant objection to it I think we should use it in = the -21
version, subject to final WG review.

Barry, as chair
_= ______________________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
= OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0-981699020-1313458867=:58222-- From phil.hunt@oracle.com Mon Aug 15 22:15:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7518D11E80A6 for ; Mon, 15 Aug 2011 22:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-1.332, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-Cs+4BsZI5P for ; Mon, 15 Aug 2011 22:15:36 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 57DCC11E8085 for ; Mon, 15 Aug 2011 22:15:36 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7G5GJSC023505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Aug 2011 05:16:21 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7G5GHCA008651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2011 05:16:18 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7G5GBWW006191; Tue, 16 Aug 2011 00:16:12 -0500 Received: from [192.168.1.67] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 15 Aug 2011 22:16:11 -0700 References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723450245F6626@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312392474.29804.YahooMailNeo@web31801.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72345024864560@P3PW5EX1MB01.EX1.SECURESERVER.NET> <81B6B8AF-4EC0-4F08-B48C-D1E7B39AE506@oracle.com> <1312506375.29372.YahooMailNeo@web31802.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1313426763.9579.YahooMailNeo@web31806.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234502498CE9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CE9A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1-157121246 Message-Id: <942049EE-A2D4-427A-8A6F-8EA6F85CAA13@oracle.com> X-Mailer: iPhone Mail (8L1) From: Phillip Hunt Date: Mon, 15 Aug 2011 22:16:04 -0700 To: Eran Hammer-Lahav X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090204.4E49FD26.0066,ss=1,re=-6.500,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 05:15:38 -0000 --Apple-Mail-1-157121246 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 Phil On 2011-08-15, at 9:46, Eran Hammer-Lahav wrote: > Let=E2=80=99s just keep =E2=80=98ext=E2=80=99 and drop =E2=80=98bodyhash=E2= =80=99. Seems like this should resolve the issue. >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: William J. Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Monday, August 15, 2011 9:46 AM > To: Eran Hammer-Lahav; Phil Hunt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] MAC Tokens body hash >=20 > =20 >=20 > "add" doesn't really say it to me either. "ah", short for "additional has= h" is somewhat more mnemonic for me, but then I think "ext" isn't horrible b= ecause it's a frequent abbreviation for extension. >=20 > =20 >=20 > -bill >=20 > =20 >=20 > From: Eran Hammer-Lahav > To: William J. Mills ; Phil Hunt > Cc: OAuth WG > Sent: Sunday, August 14, 2011 11:28 PM > Subject: RE: [OAUTH-WG] MAC Tokens body hash >=20 > How about =E2=80=98add=E2=80=99? as in =E2=80=9CUsed to include additional= data in the MAC normalized string=E2=80=9D. >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: William J. Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Thursday, August 04, 2011 6:06 PM > To: Eran Hammer-Lahav; Phil Hunt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] MAC Tokens body hash >=20 > =20 >=20 > It's the proverbial 'void *client_data;' equivalent. All names for that t= o date suck, my favorite is 'rock'. >=20 > =20 >=20 > From: Eran Hammer-Lahav > To: Phil Hunt > Cc: OAuth WG > Sent: Thursday, August 4, 2011 4:42 PM > Subject: Re: [OAUTH-WG] MAC Tokens body hash >=20 > Ok. We seem to be using different definitions of what application data mea= n, but have the same use cases in mind. I'll come up with a different name o= r just keep ext.=20 >=20 > =20 >=20 > EHL >=20 > On Aug 3, 2011, at 12:42, "Phil Hunt" wrote: >=20 > Only allowing (implied or not) app data is needlessly narrow in scope. >=20 > =20 >=20 > Extending MAC to include claims or session information is a perfectly vali= d thing to do. It improves scalability and reduces the need to look up artif= act data.=20 >=20 > =20 >=20 > Note: I'd like to share more on this, but I'm prioritizing the Threat Mod= el document. Never-the-less, the above should be a sufficient example about w= hy extensibility is useful. >=20 > =20 >=20 > Phil >=20 > =20 >=20 > @independentid >=20 > www.independentid.com >=20 > phil.hunt@oracle.com >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On 2011-08-03, at 11:03 AM, Eran Hammer-Lahav wrote: >=20 > =20 >=20 > My proposal is to change =E2=80=98ext=E2=80=99 to =E2=80=98app=E2=80=99, k= eep the same prose as =E2=80=98ext=E2=80=99, and add the use case of =E2=80=98= bodyhash=E2=80=99 as an example. I=E2=80=99m not too stuck on the name, but m= y thinking is that =E2=80=98app=E2=80=99 relays the right message that this i= s a place where developers can stick any application data they want included= . =E2=80=98ext=E2=80=99 conveys the idea of extensions which I=E2=80=99m not= so thrilled about. >=20 > =20 >=20 > In other words, I=E2=80=99d like a developer reading this to feel comforta= ble using it right away for securing addition bits such as a JSON payload, b= ut I don=E2=80=99t like the idea of someone publishing an I-D with a full sy= ntax and canonicalization requirements for say, singing an entire request, h= eaders and all. I feel that would be much better accomplished by defining a n= ew HTTP authentication scheme. >=20 > =20 >=20 > Philosophically, I think extensible authentication schemes are a bad idea.= >=20 > =20 >=20 > EHL >=20 > =20 >=20 > =20 >=20 > From: William J. Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Wednesday, August 03, 2011 10:28 AM > To: Phillip Hunt; Eran Hammer-Lahav > Cc: Ben Adida; OAuth WG; Adam Barth(adam@adambarth.com) > Subject: Re: [OAUTH-WG] MAC Tokens body hash >=20 > =20 >=20 > In thinking about this I'm coming around to the viewpoint that a single ad= ditional predefined spot is sufficient. If the app developer wants to inclu= de addtional data there (iun the specified format) that's fine. If what the= y want to do is include a signature of other payload that's fine too. >=20 > =20 >=20 > I'm not in love with the name "app" though, "ext" is better. >=20 > =20 >=20 > From: Phillip Hunt > To: Eran Hammer-Lahav > Cc: Ben Adida ; OAuth WG ; "Adam Barth(adam= @adambarth.com)" > Sent: Tuesday, August 2, 2011 7:14 PM > Subject: Re: [OAUTH-WG] MAC Tokens body hash >=20 >=20 >=20 > Phil >=20 >=20 > On 2011-08-02, at 18:02, Eran Hammer-Lahav wrote: >=20 > The idea is to drop 'ext' and 'bodyhash' due to being underspecified and t= herefore causing more harm than good. I added 'ext' to allow for application= specific data to be included in the signed content. However, the name sugge= sts this is an extension point for future specifications. I believe authenti= cation schemes should not be extensible in ways that affect their security o= r interop properties and without additional text (registry, process, etc) fo= r the 'ext' parameter, it will cause more issues than help. >=20 > Instead of the 'ext' parameter I am suggesting the 'app' parameter which w= ill do the same, but will be better positioned as an application-specific da= ta. The prose will go a step further and recommend that the parameter value i= nclude a hash of the data, not the data itself. This is to ensure the parame= ter does not become part of the payload which is inappropriate for HTTP requ= ests. >=20 > -1 what you describe appears to be a separate feature from ext >=20 >=20 > As for the 'bodyhash' parameter, I would like to remove it because it is u= nderspecified (we had an actual deployment experience showing that it doesn'= t produce interoperable implementations due to the many HTTP body transforma= tion applied in most frameworks). Solving this issue is not possible due to t= he many different types of bodies and frameworks (and clearly operating on t= he "raw" body doesn't work). Instead, developers can use the new 'app' param= eter to accomplish that. >=20 > =20 >=20 > +1 >=20 > =20 >=20 >=20 > As for the normalized string, it will be adjusted to reflect these changes= when they are made, so no placeholders which will require code change. Cons= idering this is -00, it is clearly not a stable document. >=20 > Will these changes work with your use cases? >=20 > EHL >=20 > -----Original Message----- >=20 > From: Skylar Woodward [mailto:skylar@kiva.org] >=20 > Sent: Tuesday, August 02, 2011 4:02 PM >=20 > To: Eran Hammer-Lahav >=20 > Cc: OAuth WG; Ben Adida; 'Adam Barth (adam@adambarth.com)' >=20 > Subject: Re: [OAUTH-WG] MAC Tokens body hash >=20 > =20 >=20 > hurrah! >=20 > (not necessarily for losing a way to sign the body, but for simplicity and= >=20 > avoiding some of the potential inconsistencies w/ bodyhash). >=20 > =20 >=20 > Is your plan to reserve an empty line 6 for the Normalized Request String >=20 > (which was used for bodyhash) or eliminate it, brining the total to six >=20 > elements? >=20 > =20 >=20 > skylar >=20 > =20 >=20 > On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote: >=20 > =20 >=20 > I plan to drop support for the bodyhash parameter in the next draft based >=20 > on bad implementation experience. Even with simple text body, UTF >=20 > encoding has introduced significant issues for us. The current draft does n= ot >=20 > work using simple JS code between a browser and node.js even when both >=20 > use the same v8 engine due to differences in the body encoding. Basically,= >=20 > the JS string used to send a request from the browser is not the actual st= ring >=20 > sent on the wire. >=20 > =20 >=20 > To fix that, we need to force UTF-8 encoding on both sides. However, that >=20 > is very much application specific. This will not work for non-text bodies.= >=20 > Instead, the specification should offer a simple way to use the ext parame= ter >=20 > for such needs, including singing headers. And by offer I mean give >=20 > examples, but leave it application specific for now. >=20 > =20 >=20 > I am open to suggestions but so far all the solutions I came up with will >=20 > introduce unacceptable complexity that will basically make this work usele= ss. >=20 > =20 >=20 > EHL >=20 > _______________________________________________ >=20 > OAuth mailing list >=20 > OAuth@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 --Apple-Mail-1-157121246 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
+1

Phil

On 2011-08= -15, at 9:46, Eran Hammer-Lahav <e= ran@hueniverse.com> wrote:

Let=E2=80=99s just keep =E2=80=98ext=E2=80=99 and drop =E2=80=98= bodyhash=E2=80=99. Seems like this should resolve the issue.

 

EHL

 

From: William J. Mills [mailto:wmills@yahoo-inc.com]
Sent: Monday, August 15, 2011 9:46 AM
To: Eran Hammer-Lahav; Phil Hunt=
Cc: OAuth WG
Subject: Re: [OAUTH-WG] MAC Tokens body ha= sh

 =

"add" doe= sn't really say it to me either.  "ah", short for "additional hash" is s= omewhat more mnemonic for me, but then I think "ext" isn't horrible because i= t's a frequent abbreviation for extension.

<= p class=3D"MsoNormal" style=3D"background:white"> 

-bil= l

 

From: Eran Hammer-Lahav &= lt;eran@hueniverse.com>
To: William J. Mills <= wmills@yahoo-inc.com>; Phil Hunt <phil.hunt@oracle.com= >
Cc: OAuth WG <oauth@ietf.org>
Sent: Sunda= y, August 14, 2011 11:28 PM
Subject: RE: [OAUTH-WG] MAC Tokens bod= y hash

How ab= out =E2=80=98add=E2=80=99? as in =E2=80=9CUsed to include additional data in= the MAC normalized string=E2=80=9D.=

 

EHL

 

From: Willia= m J. Mills [mailto:wmills@y= ahoo-inc.com]
Sent: Thursday, August 04, 2011 6:06 PM
T= o: Eran Hammer-Lahav; Phil Hunt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] MAC Tokens body hash

 

It's the proverbial 'v= oid *client_data;' equivalent.  All names for that to date suck, my fav= orite is 'rock'.

 

From: Eran Hammer-Lahav <eran@hueniverse.com><= br>To: Phil Hunt <phil.hunt@oracle.com>
Cc: OAuth WG <oauth@ietf.org>
= Sent: Thursday, August 4, 2011 4:42 PM
Subject: Re: [OAUTH-WG]= MAC Tokens body hash

Ok. We seem to be u= sing different definitions of what application data mean, but have the same u= se cases in mind. I'll come up with a different name or just keep ext. =

 

EHL

On Aug 3, 20= 11, at 12:42, "Phil Hunt" <phil.hunt@oracle.com= > wrote:

Only allowing (implied or not= ) app data is needlessly narrow in scope.

 

Extending M= AC to include claims or session information is a perfectly valid thing to do= . It improves scalability and reduces the need to look up artifact data.&nbs= p;

 

<= /div>

Note:  I'd like to share more on this, but I'm p= rioritizing the Threat Model document. Never-the-less, the above should be a= sufficient example about why extensibility is useful.

=

 

Ph= il

 

 

On 2011-08-03,= at 11:03 AM, Eran Hammer-Lahav wrote:

 

= My proposal is to change =E2=80=98ext=E2=80=99 to =E2=80=98app=E2=80=99, kee= p the same prose as =E2=80=98ext=E2=80=99, and add the use case of =E2=80=98= bodyhash=E2=80=99 as an example. I=E2=80=99m not too stuck on the name, but m= y thinking is that =E2=80=98app=E2=80=99 relays the right message that this i= s a place where developers can stick any application data they want included= . =E2=80=98ext=E2=80=99 conveys the idea of extensions which I=E2=80=99m not= so thrilled about.

=

 

In other words, I=E2=80=99d like a developer read= ing this to feel comfortable using it right away for securing addition bits s= uch as a JSON payload, but I don=E2=80=99t like the idea of someone publishi= ng an I-D with a full syntax and canonicalization requirements for say, sing= ing an entire request, headers and all. I feel that would be much better acc= omplished by defining a new HTTP authentication scheme.

 

Philosophical= ly, I think extensible authentication schemes are a bad idea.

 <= span style=3D"color:black">

EHL

<= p class=3D"MsoNormal" style=3D"background:white">&nb= sp;

 

From:=  William J. Mil= ls [mailt= o:wmills@yahoo-inc.com] 
Sent: Wednesday, August 03, 2011 10:28 A= M
To: Phillip Hunt; Eran Hammer-Lahav
Cc: Ben Adida; OAuth= WG; Adam Barth(adam@adambarth.com)
Subject:=  Re: [OAUTH-WG] MAC Tokens body hash

 

 

I'm not in love with the name "app" thou= gh, "ext" is better.

&nbs= p;

From: Phillip Hunt <= phil.hunt@oracle.com>
To: Eran Ham= mer-Lahav <eran@hueniverse.com>
Cc:<= /b> Ben Adida <ben@adida.net>; OAuth WG <oau= th@ietf.org>; "Adam Barth(adam@adambarth.com)" <adam@adambarth.com>
Sent: Tu= esday, August 2, 2011 7:14 PM
Subject: Re: [OAUTH-WG] MAC Tokens bo= dy hash

=



Phil

=


On 2011-08-02, at 18:02, Eran Hammer-Lahav <era= n@hueniverse.com> wrote:

<= blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">

Th= e idea is to drop 'ext' and 'bodyhash' due to being underspecified and there= fore causing more harm than good. I added 'ext' to allow for application spe= cific data to be included in the signed content. However, the name suggests t= his is an extension point for future specifications. I believe authenticatio= n schemes should not be extensible in ways that affect their security or int= erop properties and without additional text (registry, process, etc) for the= 'ext' parameter, it will cause more issues than help.

Instead of the= 'ext' parameter I am suggesting the 'app' parameter which will do the same,= but will be better positioned as an application-specific data. The prose wi= ll go a step further and recommend that the parameter value include a hash o= f the data, not the data itself. This is to ensure the parameter does not be= come part of the payload which is inappropriate for HTTP requests.

-1 what you describe appears to be a separate feature from ext


As for the 'bodyhash' par= ameter, I would like to remove it because it is underspecified (we had an ac= tual deployment experience showing that it doesn't produce interoperable imp= lementations due to the many HTTP body transformation applied in most framew= orks). Solving this issue is not possible due to the many different types of= bodies and frameworks (and clearly operating on the "raw" body doesn't work= ). Instead, developers can use the new 'app' parameter to accomplish that.

 

+1

 


As for the norma= lized string, it will be adjusted to reflect these changes when they are mad= e, so no placeholders which will require code change. Considering this is -0= 0, it is clearly not a stable document.

Will these changes wo= rk with your use cases?

EHL

-----Original Message-----

From: Skylar Woodw= ard [mailto:sky= lar@kiva.org]

Sent: Tuesday, Aug= ust 02, 2011 4:02 PM

To: Eran Hamme= r-Lahav

Cc: OAuth WG; Ben Adida; 'Ada= m Barth (adam@adambarth.com)'

Subject: Re: [OAUTH-WG] MAC Tokens body hash=

 

hurrah!

(not necessarily for losi= ng a way to sign the body, but for simplicity and

avoiding some of the potential inconsistencies w/ bodyhash).

 

=

Is your plan to reserve an empty line 6 for the Normalized Reque= st String

(which was used for bodyh= ash) or eliminate it, brining the total to six

=

elements?

 

skylar

<= /blockquote>
=

 

On Jul 30, 2011, at 3:= 43 AM, Eran Hammer-Lahav wrote:

&nb= sp;

= I plan to drop support for the bodyhash paramete= r in the next draft based

on bad implementation experience. Even with simple text body, UTF

encoding has introduced significant issue= s for us. The current draft does not

=

work using simple JS code between a browser and node.js even when both

use the same v8 engine due to differen= ces in the body encoding. Basically,

=

the JS string used to send a request from the browser is not the actual st= ring

sent on the wire.

=

 

To fix that, we need= to force UTF-8 encoding on both sides. However, that

<= /div>

is very much application specific. This will= not work for non-text bodies.

Inst= ead, the specification should offer a simple way to use the ext parameter

for such needs, including singing hea= ders. And by offer I mean give

exam= ples, but leave it application specific for now.

=

&nb= sp;

I am open to suggestions but so far= all the solutions I came up with will

introduce unacceptable complexity that will basically make t= his work useless.

 

<= /div>

EHL

__________________________= _____________________

OAuth mailing list=


_______________= ________________________________
OAuth mailing list
OAuth@ie= tf.org
http= s://www.ietf.org/mailman/listinfo/oauth

<= /div>


______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/l= istinfo/oauth

=  

<= div>

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

=
____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/list= info/oauth

=

 

<= /div>
= --Apple-Mail-1-157121246-- From rrichards@cdatazone.org Tue Aug 16 12:35:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B7811E80A9 for ; Tue, 16 Aug 2011 12:35:45 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO3hJVKRkYWN for ; Tue, 16 Aug 2011 12:35:45 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by ietfa.amsl.com (Postfix) with ESMTP id F29F211E809E for ; Tue, 16 Aug 2011 12:35:44 -0700 (PDT) Received: from dsl-67-158-171-203.fairpoint.net ([67.158.171.203] helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1QtPR5-0003xY-Aw for oauth@ietf.org; Tue, 16 Aug 2011 19:36:27 +0000 Message-ID: <4E4AC6BA.2090007@cdatazone.org> Date: Tue, 16 Aug 2011 15:36:26 -0400 From: Rob Richards User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: oauth@ietf.org References: <4E458571.1070500@cdatazone.org> In-Reply-To: <4E458571.1070500@cdatazone.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] TLS 1.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 19:35:45 -0000 I wanted to follow up on this and see if there was any consideration to relaxing this requirement. Can someone actually point me to a compliant implementation using TLS 1.2 because after looking at a number of them, I have yet to find one that does. Rob On 8/12/11 3:56 PM, Rob Richards wrote: > The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). Based > on a thread about this from last year I was under the impression that > it was going to be relaxed to a SHOULD with most likely TLS 1.0 (or > posssibly SSLv3) as a MUST. I think it's a bit unrealistic to require > 1.2 when many systems out there can't support it. IMO this is going to > be a big stumbling block for people to implement a compliant OAuth > system. Even PCI doesn't require 1.2. > > Rob > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Tue Aug 16 12:48:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74ECD11E80D6 for ; Tue, 16 Aug 2011 12:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me5Sg7JvX606 for ; Tue, 16 Aug 2011 12:48:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69E228309 for ; Tue, 16 Aug 2011 12:48:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0D1A321B16FE; Tue, 16 Aug 2011 15:49:15 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 077A421B16FB; Tue, 16 Aug 2011 15:49:15 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.3.192.1; Tue, 16 Aug 2011 15:49:14 -0400 From: Justin Richer To: Rob Richards In-Reply-To: <4E4AC6BA.2090007@cdatazone.org> References: <4E458571.1070500@cdatazone.org> <4E4AC6BA.2090007@cdatazone.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 16 Aug 2011 15:48:36 -0400 Message-ID: <1313524116.13419.81.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] TLS 1.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 19:48:31 -0000 As I recall, the logic of the group here was something like: "We want transport-layer encryption, so let's grab the latest version of that around, which looks to be TLS 1.2" With that logic in mind, this relaxation makes sense to me. Does anyone remember this requirement differently? -- Justin (who admittedly couldn't tell the difference between SSL and TLS) On Tue, 2011-08-16 at 15:36 -0400, Rob Richards wrote: > I wanted to follow up on this and see if there was any consideration to > relaxing this requirement. Can someone actually point me to a compliant > implementation using TLS 1.2 because after looking at a number of them, > I have yet to find one that does. > > Rob > > On 8/12/11 3:56 PM, Rob Richards wrote: > > The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). Based > > on a thread about this from last year I was under the impression that > > it was going to be relaxed to a SHOULD with most likely TLS 1.0 (or > > posssibly SSLv3) as a MUST. I think it's a bit unrealistic to require > > 1.2 when many systems out there can't support it. IMO this is going to > > be a big stumbling block for people to implement a compliant OAuth > > system. Even PCI doesn't require 1.2. > > > > Rob > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Aug 16 12:55:56 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2705B22830B for ; Tue, 16 Aug 2011 12:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QILbCm4ubmth for ; Tue, 16 Aug 2011 12:55:55 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id A85A622830A for ; Tue, 16 Aug 2011 12:55:55 -0700 (PDT) Received: (qmail 27142 invoked from network); 16 Aug 2011 19:56:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Aug 2011 19:56:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 16 Aug 2011 12:56:31 -0700 From: Eran Hammer-Lahav To: Justin Richer , Rob Richards Date: Tue, 16 Aug 2011 12:55:16 -0700 Thread-Topic: [OAUTH-WG] TLS 1.2 Thread-Index: AcxcTdVcH0c7rW0kQMaAT3XKQ9uqQwAAIzbg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498D1B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E458571.1070500@cdatazone.org> <4E4AC6BA.2090007@cdatazone.org> <1313524116.13419.81.camel@ground> In-Reply-To: <1313524116.13419.81.camel@ground> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] TLS 1.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 19:55:56 -0000 We should relax it. Just need someone to propose new language. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Justin Richer > Sent: Tuesday, August 16, 2011 12:49 PM > To: Rob Richards > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] TLS 1.2 >=20 > As I recall, the logic of the group here was something like: >=20 > "We want transport-layer encryption, so let's grab the latest version of = that > around, which looks to be TLS 1.2" >=20 > With that logic in mind, this relaxation makes sense to me. Does anyone > remember this requirement differently? >=20 > -- Justin > (who admittedly couldn't tell the difference between SSL and TLS) >=20 > On Tue, 2011-08-16 at 15:36 -0400, Rob Richards wrote: > > I wanted to follow up on this and see if there was any consideration > > to relaxing this requirement. Can someone actually point me to a > > compliant implementation using TLS 1.2 because after looking at a > > number of them, I have yet to find one that does. > > > > Rob > > > > On 8/12/11 3:56 PM, Rob Richards wrote: > > > The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). > > > Based on a thread about this from last year I was under the > > > impression that it was going to be relaxed to a SHOULD with most > > > likely TLS 1.0 (or posssibly SSLv3) as a MUST. I think it's a bit > > > unrealistic to require > > > 1.2 when many systems out there can't support it. IMO this is going > > > to be a big stumbling block for people to implement a compliant > > > OAuth system. Even PCI doesn't require 1.2. > > > > > > Rob > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Tue Aug 16 13:03:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E94E21F8A69 for ; Tue, 16 Aug 2011 13:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIy4qsTBaL37 for ; Tue, 16 Aug 2011 13:03:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7484321F8A66 for ; Tue, 16 Aug 2011 13:03:49 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 934494150D; Tue, 16 Aug 2011 14:06:34 -0600 (MDT) Message-ID: <4E4ACD53.2010404@stpeter.im> Date: Tue, 16 Aug 2011 14:04:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E458571.1070500@cdatazone.org> <4E4AC6BA.2090007@cdatazone.org> <1313524116.13419.81.camel@ground> <90C41DD21FB7C64BB94121FBBC2E7234502498D1B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498D1B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] TLS 1.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 20:03:50 -0000 How's this? The authorization server MUST support Transport Layer Security (at the time of this writing, the latest version is specified in [RFC5246]). It MAY support additional transport-layer mechanisms meeting its security requirements. On 8/16/11 1:55 PM, Eran Hammer-Lahav wrote: > We should relax it. Just need someone to propose new language. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Justin Richer >> Sent: Tuesday, August 16, 2011 12:49 PM >> To: Rob Richards >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] TLS 1.2 >> >> As I recall, the logic of the group here was something like: >> >> "We want transport-layer encryption, so let's grab the latest version of that >> around, which looks to be TLS 1.2" >> >> With that logic in mind, this relaxation makes sense to me. Does anyone >> remember this requirement differently? >> >> -- Justin >> (who admittedly couldn't tell the difference between SSL and TLS) >> >> On Tue, 2011-08-16 at 15:36 -0400, Rob Richards wrote: >>> I wanted to follow up on this and see if there was any consideration >>> to relaxing this requirement. Can someone actually point me to a >>> compliant implementation using TLS 1.2 because after looking at a >>> number of them, I have yet to find one that does. >>> >>> Rob >>> >>> On 8/12/11 3:56 PM, Rob Richards wrote: >>>> The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). >>>> Based on a thread about this from last year I was under the >>>> impression that it was going to be relaxed to a SHOULD with most >>>> likely TLS 1.0 (or posssibly SSLv3) as a MUST. I think it's a bit >>>> unrealistic to require >>>> 1.2 when many systems out there can't support it. IMO this is going >>>> to be a big stumbling block for people to implement a compliant >>>> OAuth system. Even PCI doesn't require 1.2. >>>> >>>> Rob >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Peter Saint-Andre https://stpeter.im/ From phil.hunt@oracle.com Tue Aug 16 13:29:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BBB21F85B8 for ; Tue, 16 Aug 2011 13:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K82tI1OGSoV for ; Tue, 16 Aug 2011 13:29:50 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8EB21F85B1 for ; Tue, 16 Aug 2011 13:29:50 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7GKUXGH003007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 16 Aug 2011 20:30:35 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7GKUXlX015603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2011 20:30:33 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7GKUREi009953; Tue, 16 Aug 2011 15:30:27 -0500 Received: from [192.168.1.67] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Aug 2011 13:30:27 -0700 References: <4E458571.1070500@cdatazone.org> <4E4AC6BA.2090007@cdatazone.org> <1313524116.13419.81.camel@ground> <90C41DD21FB7C64BB94121FBBC2E7234502498D1B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E4ACD53.2010404@stpeter.im> In-Reply-To: <4E4ACD53.2010404@stpeter.im> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8L1) From: Phillip Hunt Date: Tue, 16 Aug 2011 13:30:24 -0700 To: Peter Saint-Andre X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4E4AD36B.00D3:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] TLS 1.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 20:29:51 -0000 +1 Phil On 2011-08-16, at 13:04, Peter Saint-Andre wrote: > How's this? >=20 > The authorization server MUST support Transport Layer Security > (at the time of this writing, the latest version is specified in > [RFC5246]). It MAY support additional transport-layer mechanisms > meeting its security requirements. >=20 > On 8/16/11 1:55 PM, Eran Hammer-Lahav wrote: >> We should relax it. Just need someone to propose new language. >>=20 >> EHL >>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Justin Richer >>> Sent: Tuesday, August 16, 2011 12:49 PM >>> To: Rob Richards >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] TLS 1.2 >>>=20 >>> As I recall, the logic of the group here was something like: >>>=20 >>> "We want transport-layer encryption, so let's grab the latest version of= that >>> around, which looks to be TLS 1.2" >>>=20 >>> With that logic in mind, this relaxation makes sense to me. Does anyone >>> remember this requirement differently? >>>=20 >>> -- Justin >>> (who admittedly couldn't tell the difference between SSL and TLS) >>>=20 >>> On Tue, 2011-08-16 at 15:36 -0400, Rob Richards wrote: >>>> I wanted to follow up on this and see if there was any consideration >>>> to relaxing this requirement. Can someone actually point me to a >>>> compliant implementation using TLS 1.2 because after looking at a >>>> number of them, I have yet to find one that does. >>>>=20 >>>> Rob >>>>=20 >>>> On 8/12/11 3:56 PM, Rob Richards wrote: >>>>> The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). >>>>> Based on a thread about this from last year I was under the >>>>> impression that it was going to be relaxed to a SHOULD with most >>>>> likely TLS 1.0 (or posssibly SSLv3) as a MUST. I think it's a bit >>>>> unrealistic to require >>>>> 1.2 when many systems out there can't support it. IMO this is going >>>>> to be a big stumbling block for people to implement a compliant >>>>> OAuth system. Even PCI doesn't require 1.2. >>>>>=20 >>>>> Rob >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From rrichards@cdatazone.org Tue Aug 16 13:33:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2470B21F8B34 for ; Tue, 16 Aug 2011 13:33:47 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR+QXKAp57uk for ; Tue, 16 Aug 2011 13:33:46 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by ietfa.amsl.com (Postfix) with ESMTP id 8430821F8B28 for ; Tue, 16 Aug 2011 13:33:46 -0700 (PDT) Received: from dsl-67-158-171-203.fairpoint.net ([67.158.171.203] helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1QtQLF-00031d-Cf; Tue, 16 Aug 2011 20:34:29 +0000 Message-ID: <4E4AD454.9040302@cdatazone.org> Date: Tue, 16 Aug 2011 16:34:28 -0400 From: Rob Richards User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E458571.1070500@cdatazone.org> <4E4AC6BA.2090007@cdatazone.org> <1313524116.13419.81.camel@ground> <90C41DD21FB7C64BB94121FBBC2E7234502498D1B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E4ACD53.2010404@stpeter.im> In-Reply-To: <4E4ACD53.2010404@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] TLS 1.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 20:33:47 -0000 After dealing with a few companies' security teams over the spec, I don't think it should be allowed too much room for interpretation and needs to be spelled out clearly. They would most likely interpret that as requiring the latest version of TLS at the time of implementation. Maybe something more along the lines of: The authorization server SHOULD support TLS 1.2 as defined in [RFC5246] but at a minimum MUST support TLS 1.0 as defined in [RFC2246], and MAY support additional transport-layer mechanisms meeting its security requirements. On 8/16/11 4:04 PM, Peter Saint-Andre wrote: > How's this? > > The authorization server MUST support Transport Layer Security > (at the time of this writing, the latest version is specified in > [RFC5246]). It MAY support additional transport-layer mechanisms > meeting its security requirements. > > On 8/16/11 1:55 PM, Eran Hammer-Lahav wrote: >> We should relax it. Just need someone to propose new language. >> >> EHL >> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Justin Richer >>> Sent: Tuesday, August 16, 2011 12:49 PM >>> To: Rob Richards >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] TLS 1.2 >>> >>> As I recall, the logic of the group here was something like: >>> >>> "We want transport-layer encryption, so let's grab the latest version of that >>> around, which looks to be TLS 1.2" >>> >>> With that logic in mind, this relaxation makes sense to me. Does anyone >>> remember this requirement differently? >>> >>> -- Justin >>> (who admittedly couldn't tell the difference between SSL and TLS) >>> >>> On Tue, 2011-08-16 at 15:36 -0400, Rob Richards wrote: >>>> I wanted to follow up on this and see if there was any consideration >>>> to relaxing this requirement. Can someone actually point me to a >>>> compliant implementation using TLS 1.2 because after looking at a >>>> number of them, I have yet to find one that does. >>>> >>>> Rob >>>> >>>> On 8/12/11 3:56 PM, Rob Richards wrote: >>>>> The latest draft shows TLS 1.2 as a MUST (sections 3.1 and 3.2). >>>>> Based on a thread about this from last year I was under the >>>>> impression that it was going to be relaxed to a SHOULD with most >>>>> likely TLS 1.0 (or posssibly SSLv3) as a MUST. I think it's a bit >>>>> unrealistic to require >>>>> 1.2 when many systems out there can't support it. IMO this is going >>>>> to be a big stumbling block for people to implement a compliant >>>>> OAuth system. Even PCI doesn't require 1.2. >>>>> >>>>> Rob >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Tue Aug 16 14:25:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B630C11E80CA for ; Tue, 16 Aug 2011 14:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMQ83vl6Q-Xj for ; Tue, 16 Aug 2011 14:25:08 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 82D1911E80AA for ; Tue, 16 Aug 2011 14:25:08 -0700 (PDT) Received: (qmail 8668 invoked from network); 16 Aug 2011 21:25:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Aug 2011 21:25:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 16 Aug 2011 14:25:48 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 16 Aug 2011 14:24:34 -0700 Thread-Topic: Redirection URI registration feedback (Yaron Goland) Thread-Index: AcxcWeH24dAQPEiRRnqiHahTQZ/41A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498D1F3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234502498D1F3P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Redirection URI registration feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:25:10 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D1F3P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Working group feedback requested at the end) Moved here to solicit additional feedback from the group. > 3.1.2.2. Registration Requirements: Comment on last word "path": "Huh? > Scheme, authorization and path is a complete URI minus a query > component. Is the goal to specifically mandate that only the query > component can vary and the rest of the URI MUST be static? If so that sho= uld > be stated explicitly rather than implicitly as it is now. But I think, i= f that is the > intent, it goes too far. We should also allow for additional path segment= s to > be added to the URI path beyond the registered prefix. Assuming we can > address the security problem in the next comment." Added after 'path': "(allowing the client to dynamically change only the qu= ery component of the redirection URI when requesting authorization)". As for allowing dynamic changes to the path, that's still allowed but not t= he recommended way. Basically, full registration is best, then dynamic quer= y second best, but anything else is still permitted. > 3.1.2.3. Dynamic Configuration: Comment on "section 6": "The reference t= o > section 6 is incomplete. Section 6 defines no less than 6 different axis'= s on > which URI comparisons can vary. Furthermore as recently documented in > draft-thaler-iab-identifier-comparison-00.txt it is trivially easy to scr= ew up URI > comparisons and the security implications are pretty dire. Personally I t= hink > that the only sane approach given the issues in the previous link is to a= dopt > section 6.2.1 of RFC 3986. > > I am a bit scared of how to handle partial matches. It's tempting to argu= e that > so long as the schema has an authority and at least one path segment then > we can just use a partial string match but boy oh boy do I see people > screwing that one up royally. This is scary enough that I think I can be = argued > into saying that partial pre-registered URIs MUST only differ by the quer= y > component. > > In any case this issues needs to be explicitly called out for all URI com= parisons > required by the spec and normatively defined. Otherwise we will end up > with all the security issues in Dave's ID." Looks like you are contradicting yourself. First you say that limiting to q= uery only is to limited and now you recommend it. It is well established that URI comparison is hard because normalization is= hard. That was the main issue in OAuth 1.0. It is also the motivation behi= nd recommending registration of the complete URI. I'm open to requiring str= ing comparison for fully registered URIs but not for dynamic URIs because o= f the difficulty in applying such a rule to partial registration. Existing text in 3.1.2.3: When a redirection URI is included in an authorization request, the authorization server MUST compare and match the value received against at least one of the registered redirection URIs (or URI components) as defined in [RFC3986] section 6, if any redirection URIs were registered. Suggested addition: If the client registration included the full redirection URI, the author= ization server MUST compare the two URIs using simple string comparison as defin= ed in [RFC3986] section 6.2.1. I'm looking for feedback on this proposed addition. EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D1F3P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Working grou= p feedback requested at the end)

 

Moved here to solicit additional f= eedback from the group.

 

> 3.1.2.2. Registration Requirements: Co= mment on last word “path”: “Huh?

> Scheme, authorization and path is a complete URI minus= a query

> component.  Is the= goal to specifically mandate that only the query

> component can vary and the rest of the URI MUST be static= ? If so that should

> be stated ex= plicitly rather than implicitly as it is now.  But I think, if that is= the

> intent, it goes too far. We= should also allow for additional path segments to

> be added to the URI path beyond the registered prefix.= Assuming we can

> address the sec= urity problem in the next comment.”

 

Added after 'path': "(allowing the client to dynamically change onl= y the query component of the redirection URI when requesting authorization)= ".

 

As for allowing dynamic changes to the path, that's still allowe= d but not the recommended way. Basically, full registration is best, then d= ynamic query second best, but anything else is still permitted.<= /span>

 

> 3.1.2.3. Dynamic Configuration:= Comment on “section 6”:  “The reference to

> section 6 is incomplete. Section 6 defin= es no less than 6 different axis’s on

> which URI comparisons can vary. Furthermore as recently documen= ted in

> draft-thaler-iab-identifi= er-comparison-00.txt it is trivially easy to screw up URI

> comparisons and the security implications are pre= tty dire. Personally I think

> tha= t the only sane approach given the issues in the previous link is to adopt<= o:p>

> section 6.2.1 of RFC 3986.<= /o:p>

> 

> I am a bit scared of how to handle partial matches. It’s = tempting to argue that

> so long a= s the schema has an authority and at least one path segment then=

> we can just use a partial string match but= boy oh boy do I see people

> scre= wing that one up royally. This is scary enough that I think I can be argued=

> into saying that partial pre-re= gistered URIs MUST only differ by the query

> component.

>

> In any case this issues needs to be expl= icitly called out for all URI comparisons

> required by the spec and normatively defined. Otherwise we will e= nd up

> with all the security issu= es in Dave’s ID.”

&n= bsp;

Looks lik= e you are contradicting yourself. First you say that limiting to query only= is to limited and now you recommend it.

 

It is well established that URI= comparison is hard because normalization is hard. That was the main issue = in OAuth 1.0. It is also the motivation behind recommending registration of= the complete URI. I'm open to requiring string comparison for fully regist= ered URIs but not for dynamic URIs because of the difficulty in applying su= ch a rule to partial registration.

 

Existing text in 3.1.2.3:<= /o:p>

 

&nb= sp;  When a redirection URI is included in an authorization request, t= he

   authorization server MUS= T compare and match the value received

&= nbsp;  against at least one of the registered redirection URIs (or URI=

   components) as defined in = [RFC3986] section 6, if any redirection

=    URIs were registered.

=  

Suggested addition:

 

   If = the client registration included the full redirection URI, the authorizatio= n

   server MUST compare the t= wo URIs using simple string comparison as defined

   in [RFC3986] section 6.2.1.

 

I’m looking fo= r feedback on this proposed addition.

 

EHL

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D1F3P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Aug 16 14:45:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CDE11E8103 for ; Tue, 16 Aug 2011 14:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq3L9oVjPi7y for ; Tue, 16 Aug 2011 14:45:30 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id BFE4311E8101 for ; Tue, 16 Aug 2011 14:45:27 -0700 (PDT) Received: (qmail 16469 invoked from network); 16 Aug 2011 21:46:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Aug 2011 21:46:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 16 Aug 2011 14:46:02 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 16 Aug 2011 14:44:47 -0700 Thread-Topic: Open redirector feedback (Yaron Goland) Thread-Index: AcxcXZWPNliGpm+dSi2eHbYp4Bn6aA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498D202@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234502498D202P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Open redirector feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:45:31 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D202P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Moved here to help discuss. > 3.1.2.4. Invalid Endpoint: Comment on "open redirector": "How many peopl= e > even know what the heck an open redirector is? I think we need a section = in > the security considerations section that defines what an open redirector = is > and why it's bad. Alternatively a normative reference to a complete > definition somewhere else is also fine." Added new section and reference to it: 10.15. Open Redirectors The authorization server authorization endpoint and the client redirection endpoint can be improperly configured and operate as open redirectors. An open redirector is an endpoint using a parameter to automatically redirect a user-agent to the location specified by the parameter value without any validation. Open redirectors can be used in phishing attacks to get end-users to visit malicious sites by making the URI's authority look like a familiar and trusted destination. In addition, if the authorization server allows the client to register only part of the redirection URI, an attacker can use an open redirector operated by the client to construct a redirection URI that will pass the authorization server validation but will send the authorization code or access token to an endpoint under the control of the attacker. --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D202P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Moved here to he= lp discuss.

 

> 3.1.2.4.  Invalid Endpoint: Comment on “op= en redirector”: “How many people

> even know what the heck an open redirector is? I think we need= a section in

> the security consi= derations section that defines what an open redirector is

> and why it’s bad. Alternatively a normative= reference to a complete

> definit= ion somewhere else is also fine.”

=  

Added new section and reference t= o it:

 

10.15.  Open Redirectors

 

   The authorization serv= er authorization endpoint and the client

   redirection endpoint can be improperly configured and operate= as open

   redirectors. = An open redirector is an endpoint using a parameter to

   automatically redirect a user-agent to the loc= ation specified by the

   para= meter value without any validation.

 

   Open redirectors can be = used in phishing attacks to get end-users to

   visit malicious sites by making the URI's authority look = like a

  familiar and trusted= destination.  In addition, if the authorization

   server allows the client to register only part o= f the redirection

   URI, an a= ttacker can use an open redirector operated by the client to

=

   construct a redirection URI that will pas= s the authorization server

   = validation but will send the authorization code or access token to an<= /o:p>

   endpoint under the control of th= e attacker.

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D202P3PW5EX1MB01E_-- From wmills@yahoo-inc.com Tue Aug 16 15:35:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523DA21F8BB0 for ; Tue, 16 Aug 2011 15:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.294 X-Spam-Level: X-Spam-Status: No, score=-17.294 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ1C0o+u4yIm for ; Tue, 16 Aug 2011 15:35:45 -0700 (PDT) Received: from nm29-vm0.bullet.mail.sp2.yahoo.com (nm29-vm0.bullet.mail.sp2.yahoo.com [98.139.91.236]) by ietfa.amsl.com (Postfix) with SMTP id 4CCB521F8BAD for ; Tue, 16 Aug 2011 15:35:45 -0700 (PDT) Received: from [98.139.91.64] by nm29.bullet.mail.sp2.yahoo.com with NNFMP; 16 Aug 2011 22:36:34 -0000 Received: from [98.139.91.51] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 16 Aug 2011 22:36:34 -0000 Received: from [127.0.0.1] by omp1051.mail.sp2.yahoo.com with NNFMP; 16 Aug 2011 22:36:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 829104.73270.bm@omp1051.mail.sp2.yahoo.com Received: (qmail 61863 invoked by uid 60001); 16 Aug 2011 22:36:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313534194; bh=0eE5g8XpgND4o64Rzm0pfnGl9Nf/YAFwHAWuj0+m2N8=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ITvQggX5UCvfuBYOoV6jZIWvncOPiSjEHrKmffH7Yy0LeXtPy/ulFflZeWPwl/QAugjrVcavd0hvaqO8qI3MCgpDJfvJVAgVg3wzZiNX2stBgKyH2/iNpLn8N6fmabDqpQNmDbpRDwBATQvbPrR7gAVzZrEzjMeWGHsJ7NCioHE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=SwxHSg8I2tWbYTGsye9Vq1G0ttVfIzo4KEQKDQn0ItFdef10kGEIbNH8s5Vf7Y8GJWwoBqD0+Fv4tZ0/DQHYkVkl0PrA2QrH5ewvIePX+JDJByBv32oJwK7J17dnWnyM+yIjDvwVrUF+RnVyUSk47Nlyiy9N2XzDYnPRfe8JvS0=; X-YMail-OSG: FjYCsSYVM1k97iuVF7rX4KvrnO0JeuunZgmqqddjrNkvHMg oFINLgz1Uoi6wrjz54HiXF1bKhNoN8suPsTCdpAOvPfiu1dqbQqmPDh3te63 veEUI9R9zLRwZKRkLi4i.XUnVxVmpjUDUfB3gkPT6ROiopj0zx0ovmF0G.FY 89h29kfEan7z2IKultNhE6bpl0cXLh.hEEW.6h0jBY_S2vKtIMh0Rf8CWDtJ Bf6.i7jX9K7I1NAZ2u52r.5bdsJ.ZGKNRM9h4TJDiFvtQNB5.esGoClV3VU9 IFpApSK8gUKpoP_P0vsFQ6WBR3mNF68FnGbmjUHsDZV6ET4yul2Bc25DMHrj sPLFwqowwz6a3z65zFxu4Q_NkDC2nyDbOxhqjgnhY6L84X8WodwMFcCsR1Kf KYzGOUNesIuG6.CFO9aZLFy7NDAlbtumi19evcJCTyA-- Received: from [209.131.62.113] by web31801.mail.mud.yahoo.com via HTTP; Tue, 16 Aug 2011 15:36:34 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <90C41DD21FB7C64BB94121FBBC2E7234502498D202@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1313534194.51222.YahooMailNeo@web31801.mail.mud.yahoo.com> Date: Tue, 16 Aug 2011 15:36:34 -0700 (PDT) From: "William J. Mills" To: Eran Hammer-Lahav , OAuth WG In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498D202@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1538599910-1313534194=:51222" Subject: Re: [OAUTH-WG] Open redirector feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:35:46 -0000 --0-1538599910-1313534194=:51222 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I like it, but I think using "phishing attacks" is too limited.=C2=A0 I sug= gest changing "phishing attacks" to "by an attacker"=0A=0A=0A=0A___________= _____________________=0AFrom: Eran Hammer-Lahav =0ATo:= OAuth WG =0ASent: Tuesday, August 16, 2011 2:44 PM=0ASubje= ct: [OAUTH-WG] Open redirector feedback (Yaron Goland)=0A=0A=0AMoved here t= o help discuss.=0A=C2=A0=0A> 3.1.2.4.=C2=A0 Invalid Endpoint: Comment on = =E2=80=9Copen redirector=E2=80=9D: =E2=80=9CHow many people=0A> even know w= hat the heck an open redirector is? I think we need a section in=0A> the se= curity considerations section that defines what an open redirector is=0A> a= nd why it=E2=80=99s bad. Alternatively a normative reference to a complete= =0A> definition somewhere else is also fine.=E2=80=9D=0A=C2=A0=0AAdded new = section and reference to it:=0A=C2=A0=0A10.15.=C2=A0 Open Redirectors=0A=C2= =A0=0A=C2=A0=C2=A0 The authorization server authorization endpoint and the = client=0A=C2=A0=C2=A0 redirection endpoint can be improperly configured and= operate as open=0A=C2=A0=C2=A0 redirectors.=C2=A0 An open redirector is an= endpoint using a parameter to=0A=C2=A0=C2=A0 automatically redirect a user= -agent to the location specified by the=0A=C2=A0=C2=A0 parameter value with= out any validation.=0A=C2=A0=0A=C2=A0=C2=A0 Open redirectors can be used in= phishing attacks to get end-users to=0A=C2=A0=C2=A0 visit malicious sites = by making the URI's authority look like a=0A=C2=A0=C2=A0familiar and truste= d destination.=C2=A0 In addition, if the authorization=0A=C2=A0=C2=A0 serve= r allows the client to register only part of the redirection=0A=C2=A0=C2=A0= URI, an attacker can use an open redirector operated by the client to=0A= =C2=A0=C2=A0 construct a redirection URI that will pass the authorization s= erver=0A=C2=A0=C2=A0 validation but will send the authorization code or acc= ess token to an=0A=C2=A0=C2=A0 endpoint under the control of the attacker.= =0A=C2=A0=0A=C2=A0=0A_______________________________________________=0AOAut= h mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oau= th --0-1538599910-1313534194=:51222 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I like it, but I think using "phishing attacks" is too limited.&nb= sp; I suggest changing "phishing attacks" to "by an attacker"

From: Eran= Hammer-Lahav <eran@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Sent: Tuesday, August 16, 2011 2:44 PM
<= b>Subject: [OAUTH-WG] Open re= director feedback (Yaron Goland)

Moved here to help discuss.
 
>= ; 3.1.2.4.  Invalid Endpoint: Comment on =E2=80=9Copen redirector=E2= =80=9D: =E2=80=9CHow many people
> even know what the heck an open redirector is? I think we need a se= ction in
> the security con= siderations section that defines what an open redirector is
> and why it=E2=80=99s bad. Alternatively = a normative reference to a complete
> definition somewhere else is also fine.=E2=80=9D
 
Added new section and reference to it:
 
10.15.  Open Redirectors
 
   The authorization server authorization endpoint and the c= lient
   redirection en= dpoint can be improperly configured and operate as open
   redirectors.  An open redirector i= s an endpoint using a parameter to
   automatically redirect a user-agent to the location specifie= d by the
   parameter v= alue without any validation.
&nb= sp;
   Open redirectors= can be used in phishing attacks to get end-users to
   visit malicious sites by making the URI's = authority look like a
  familia= r and trusted destination.  In addition, if the authorization
   server allows the client to = register only part of the redirection
   URI, an attacker can use an open redirector operated by t= he client to
   constru= ct a redirection URI that will pass the authorization server
   validation but will send the autho= rization code or access token to an
   endpoint under the control of the attacker.
 
 

____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m= ailman/listinfo/oauth


--0-1538599910-1313534194=:51222-- From eran@hueniverse.com Tue Aug 16 15:38:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E0811E80BB for ; Tue, 16 Aug 2011 15:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPfmst7ufqki for ; Tue, 16 Aug 2011 15:38:21 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 5DA6711E80B8 for ; Tue, 16 Aug 2011 15:38:21 -0700 (PDT) Received: (qmail 12789 invoked from network); 16 Aug 2011 22:39:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Aug 2011 22:39:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 16 Aug 2011 15:38:57 -0700 From: Eran Hammer-Lahav To: "William J. Mills" Date: Tue, 16 Aug 2011 15:37:41 -0700 Thread-Topic: [OAUTH-WG] Open redirector feedback (Yaron Goland) Thread-Index: AcxcZPVlLb9amO8eSFeHN7gZX3p+cQAACECQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498D235@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498D202@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1313534194.51222.YahooMailNeo@web31801.mail.mud.yahoo.com> In-Reply-To: <1313534194.51222.YahooMailNeo@web31801.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234502498D235P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Open redirector feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:38:22 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D235P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2suDQoNCkZyb206IFdpbGxpYW0gSi4gTWlsbHMgW21haWx0bzp3bWlsbHNAeWFob28taW5jLmNv bV0NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAxNiwgMjAxMSAzOjM3IFBNDQpUbzogRXJhbiBIYW1t ZXItTGFoYXY7IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPcGVuIHJlZGlyZWN0 b3IgZmVlZGJhY2sgKFlhcm9uIEdvbGFuZCkNCg0KSSBsaWtlIGl0LCBidXQgSSB0aGluayB1c2lu ZyAicGhpc2hpbmcgYXR0YWNrcyIgaXMgdG9vIGxpbWl0ZWQuICBJIHN1Z2dlc3QgY2hhbmdpbmcg InBoaXNoaW5nIGF0dGFja3MiIHRvICJieSBhbiBhdHRhY2tlciINCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IEVyYW4gSGFtbWVyLUxhaGF2IDxlcmFuQGh1ZW5pdmVy c2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4NClRvOiBPQXV0aCBXRyA8b2F1dGhA aWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAx NiwgMjAxMSAyOjQ0IFBNDQpTdWJqZWN0OiBbT0FVVEgtV0ddIE9wZW4gcmVkaXJlY3RvciBmZWVk YmFjayAoWWFyb24gR29sYW5kKQ0KTW92ZWQgaGVyZSB0byBoZWxwIGRpc2N1c3MuDQoNCj4gMy4x LjIuNC4gIEludmFsaWQgRW5kcG9pbnQ6IENvbW1lbnQgb24g4oCcb3BlbiByZWRpcmVjdG9y4oCd OiDigJxIb3cgbWFueSBwZW9wbGUNCj4gZXZlbiBrbm93IHdoYXQgdGhlIGhlY2sgYW4gb3BlbiBy ZWRpcmVjdG9yIGlzPyBJIHRoaW5rIHdlIG5lZWQgYSBzZWN0aW9uIGluDQo+IHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRoYXQgZGVmaW5lcyB3aGF0IGFuIG9wZW4gcmVkaXJl Y3RvciBpcw0KPiBhbmQgd2h5IGl04oCZcyBiYWQuIEFsdGVybmF0aXZlbHkgYSBub3JtYXRpdmUg cmVmZXJlbmNlIHRvIGEgY29tcGxldGUNCj4gZGVmaW5pdGlvbiBzb21ld2hlcmUgZWxzZSBpcyBh bHNvIGZpbmUu4oCdDQoNCkFkZGVkIG5ldyBzZWN0aW9uIGFuZCByZWZlcmVuY2UgdG8gaXQ6DQoN CjEwLjE1LiAgT3BlbiBSZWRpcmVjdG9ycw0KDQogICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg YXV0aG9yaXphdGlvbiBlbmRwb2ludCBhbmQgdGhlIGNsaWVudA0KICAgcmVkaXJlY3Rpb24gZW5k cG9pbnQgY2FuIGJlIGltcHJvcGVybHkgY29uZmlndXJlZCBhbmQgb3BlcmF0ZSBhcyBvcGVuDQog ICByZWRpcmVjdG9ycy4gIEFuIG9wZW4gcmVkaXJlY3RvciBpcyBhbiBlbmRwb2ludCB1c2luZyBh IHBhcmFtZXRlciB0bw0KICAgYXV0b21hdGljYWxseSByZWRpcmVjdCBhIHVzZXItYWdlbnQgdG8g dGhlIGxvY2F0aW9uIHNwZWNpZmllZCBieSB0aGUNCiAgIHBhcmFtZXRlciB2YWx1ZSB3aXRob3V0 IGFueSB2YWxpZGF0aW9uLg0KDQogICBPcGVuIHJlZGlyZWN0b3JzIGNhbiBiZSB1c2VkIGluIHBo aXNoaW5nIGF0dGFja3MgdG8gZ2V0IGVuZC11c2VycyB0bw0KICAgdmlzaXQgbWFsaWNpb3VzIHNp dGVzIGJ5IG1ha2luZyB0aGUgVVJJJ3MgYXV0aG9yaXR5IGxvb2sgbGlrZSBhDQogIGZhbWlsaWFy IGFuZCB0cnVzdGVkIGRlc3RpbmF0aW9uLiAgSW4gYWRkaXRpb24sIGlmIHRoZSBhdXRob3JpemF0 aW9uDQogICBzZXJ2ZXIgYWxsb3dzIHRoZSBjbGllbnQgdG8gcmVnaXN0ZXIgb25seSBwYXJ0IG9m IHRoZSByZWRpcmVjdGlvbg0KICAgVVJJLCBhbiBhdHRhY2tlciBjYW4gdXNlIGFuIG9wZW4gcmVk aXJlY3RvciBvcGVyYXRlZCBieSB0aGUgY2xpZW50IHRvDQogICBjb25zdHJ1Y3QgYSByZWRpcmVj dGlvbiBVUkkgdGhhdCB3aWxsIHBhc3MgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQogICB2YWxp ZGF0aW9uIGJ1dCB3aWxsIHNlbmQgdGhlIGF1dGhvcml6YXRpb24gY29kZSBvciBhY2Nlc3MgdG9r ZW4gdG8gYW4NCiAgIGVuZHBvaW50IHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBhdHRhY2tlci4N Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D235P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC55aXY5NzgzOTExODJtc29wbGFpbnRl eHQsIGxpLnlpdjk3ODM5MTE4Mm1zb3BsYWludGV4dCwgZGl2Lnlpdjk3ODM5MTE4Mm1zb3BsYWlu dGV4dA0KCXttc28tc3R5bGUtbmFtZTp5aXY5NzgzOTExODJtc29wbGFpbnRleHQ7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2OTc4MzkxMTgybXNvbm9y bWFsLCBsaS55aXY5NzgzOTExODJtc29ub3JtYWwsIGRpdi55aXY5NzgzOTExODJtc29ub3JtYWwN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2OTc4MzkxMTgybXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjk3ODM5MTE4Mm1zb2h5cGVybGlu aw0KCXttc28tc3R5bGUtbmFtZTp5aXY5NzgzOTExODJtc29oeXBlcmxpbms7fQ0Kc3Bhbi55aXY5 NzgzOTExODJtc29oeXBlcmxpbmtmb2xsb3dlZA0KCXttc28tc3R5bGUtbmFtZTp5aXY5NzgzOTEx ODJtc29oeXBlcmxpbmtmb2xsb3dlZDt9DQpzcGFuLnlpdjk3ODM5MTE4MmVtYWlsc3R5bGUxNw0K CXttc28tc3R5bGUtbmFtZTp5aXY5NzgzOTExODJlbWFpbHN0eWxlMTc7fQ0Kc3Bhbi55aXY5Nzgz OTExODJwbGFpbnRleHRjaGFyDQoJe21zby1zdHlsZS1uYW1lOnlpdjk3ODM5MTE4MnBsYWludGV4 dGNoYXI7fQ0KcC55aXY5NzgzOTExODJtc29ub3JtYWwxLCBsaS55aXY5NzgzOTExODJtc29ub3Jt YWwxLCBkaXYueWl2OTc4MzkxMTgybXNvbm9ybWFsMQ0KCXttc28tc3R5bGUtbmFtZTp5aXY5Nzgz OTExODJtc29ub3JtYWwxOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi55aXY5NzgzOTExODJtc29oeXBlcmxpbmsxDQoJe21zby1zdHlsZS1uYW1lOnlpdjk3ODM5 MTE4Mm1zb2h5cGVybGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4ueWl2OTc4MzkxMTgybXNvaHlwZXJsaW5rZm9sbG93ZWQxDQoJe21zby1zdHls ZS1uYW1lOnlpdjk3ODM5MTE4Mm1zb2h5cGVybGlua2ZvbGxvd2VkMTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLnlpdjk3ODM5MTE4Mm1zb3BsYWludGV4 dDEsIGxpLnlpdjk3ODM5MTE4Mm1zb3BsYWludGV4dDEsIGRpdi55aXY5NzgzOTExODJtc29wbGFp bnRleHQxDQoJe21zby1zdHlsZS1uYW1lOnlpdjk3ODM5MTE4Mm1zb3BsYWludGV4dDE7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLnlpdjk3ODM5MTE4MmVtYWls c3R5bGUxNzENCgl7bXNvLXN0eWxlLW5hbWU6eWl2OTc4MzkxMTgyZW1haWxzdHlsZTE3MTsNCglm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ueWl2OTc4MzkxMTgycGxhaW50ZXh0Y2hhcjENCgl7bXNvLXN0eWxlLW5hbWU6eWl2OTc4Mzkx MTgycGxhaW50ZXh0Y2hhcjE7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o ZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Pay48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+ PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Iic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFdpbGxpYW0gSi4gTWlsbHMgW21haWx0bzp3bWls bHNAeWFob28taW5jLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMTYsIDIw MTEgMzozNyBQTTxicj48Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRzxicj48 Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT3BlbiByZWRpcmVjdG9yIGZlZWRiYWNrIChZ YXJvbiBHb2xhbmQpPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5JIGxpa2UgaXQsIGJ1dCBJIHRo aW5rIHVzaW5nICZxdW90O3BoaXNoaW5nIGF0dGFja3MmcXVvdDsgaXMgdG9vIGxpbWl0ZWQuJm5i c3A7IEkgc3VnZ2VzdCBjaGFuZ2luZyAmcXVvdDtwaGlzaGluZyBhdHRhY2tzJnF1b3Q7IHRvICZx dW90O2J5IGFuIGF0dGFja2VyJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXYgY2xhc3M9TXNv Tm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3 aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxociBzaXplPTEgd2lkdGg9IjEwMCUiIGFsaWduPWNl bnRlcj48L3NwYW4+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gRXJhbiBIYW1tZXItTGFoYXYgJmx0OzxhIGhyZWY9 Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDs8 YnI+PGI+VG86PC9iPiBPQXV0aCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn Ij5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3Qg MTYsIDIwMTEgMjo0NCBQTTxicj48Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBPcGVuIHJlZGly ZWN0b3IgZmVlZGJhY2sgKFlhcm9uIEdvbGFuZCk8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdiBpZD15aXY5NzgzOTExODI+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz5Nb3ZlZCBoZXJlIHRvIGhlbHAgZGlzY3Vzcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZndDsgMy4xLjIuNC4mbmJzcDsgSW52YWxpZCBFbmRw b2ludDogQ29tbWVudCBvbiDigJxvcGVuIHJlZGlyZWN0b3LigJ06IOKAnEhvdyBtYW55IHBlb3Bs ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IGV2ZW4g a25vdyB3aGF0IHRoZSBoZWNrIGFuIG9wZW4gcmVkaXJlY3RvciBpcz8gSSB0aGluayB3ZSBuZWVk IGEgc2VjdGlvbiBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz4mZ3Q7IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRoYXQgZGVmaW5lcyB3 aGF0IGFuIG9wZW4gcmVkaXJlY3RvciBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9 J2NvbG9yOmJsYWNrJz4mZ3Q7IGFuZCB3aHkgaXTigJlzIGJhZC4gQWx0ZXJuYXRpdmVseSBhIG5v cm1hdGl2ZSByZWZlcmVuY2UgdG8gYSBjb21wbGV0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mZ3Q7IGRlZmluaXRpb24gc29tZXdoZXJlIGVsc2UgaXMgYWxz byBmaW5lLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+QWRkZWQg bmV3IHNlY3Rpb24gYW5kIHJlZmVyZW5jZSB0byBpdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPjEwLjE1LiZuYnNwOyBPcGVuIFJlZGlyZWN0b3JzPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0 ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYW5kIHRoZSBjbGllbnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7IHJlZGlyZWN0 aW9uIGVuZHBvaW50IGNhbiBiZSBpbXByb3Blcmx5IGNvbmZpZ3VyZWQgYW5kIG9wZXJhdGUgYXMg b3BlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsm bmJzcDsgcmVkaXJlY3RvcnMuJm5ic3A7IEFuIG9wZW4gcmVkaXJlY3RvciBpcyBhbiBlbmRwb2lu dCB1c2luZyBhIHBhcmFtZXRlciB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgYXV0b21hdGljYWxseSByZWRpcmVjdCBhIHVzZXItYWdl bnQgdG8gdGhlIGxvY2F0aW9uIHNwZWNpZmllZCBieSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7IHBhcmFtZXRlciB2YWx1ZSB3aXRo b3V0IGFueSB2YWxpZGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj ayc+Jm5ic3A7Jm5ic3A7IE9wZW4gcmVkaXJlY3RvcnMgY2FuIGJlIHVzZWQgaW4gcGhpc2hpbmcg YXR0YWNrcyB0byBnZXQgZW5kLXVzZXJzIHRvPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyB2aXNpdCBtYWxpY2lvdXMgc2l0ZXMgYnkgbWFr aW5nIHRoZSBVUkkncyBhdXRob3JpdHkgbG9vayBsaWtlIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7Jm5ic3A7ZmFtaWxpYXIgYW5kIHRydXN0ZWQg ZGVzdGluYXRpb24uJm5ic3A7IEluIGFkZGl0aW9uLCBpZiB0aGUgYXV0aG9yaXphdGlvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgc2Vy dmVyIGFsbG93cyB0aGUgY2xpZW50IHRvIHJlZ2lzdGVyIG9ubHkgcGFydCBvZiB0aGUgcmVkaXJl Y3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 Jm5ic3A7IFVSSSwgYW4gYXR0YWNrZXIgY2FuIHVzZSBhbiBvcGVuIHJlZGlyZWN0b3Igb3BlcmF0 ZWQgYnkgdGhlIGNsaWVudCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9y OmJsYWNrJz4mbmJzcDsmbmJzcDsgY29uc3RydWN0IGEgcmVkaXJlY3Rpb24gVVJJIHRoYXQgd2ls bCBwYXNzIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDsmbmJzcDsgdmFsaWRhdGlvbiBidXQgd2lsbCBzZW5k IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgb3IgYWNjZXNzIHRva2VuIHRvIGFuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOyZuYnNwOyBlbmRwb2ludCB1 bmRlciB0aGUgY29udHJvbCBvZiB0aGUgYXR0YWNrZXIuPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNr Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxicj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D235P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Aug 16 15:58:30 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D202921F8B63 for ; Tue, 16 Aug 2011 15:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+-3SDix+xZ1 for ; Tue, 16 Aug 2011 15:58:29 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 8E4FE21F8B56 for ; Tue, 16 Aug 2011 15:58:29 -0700 (PDT) Received: (qmail 15763 invoked from network); 16 Aug 2011 22:59:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Aug 2011 22:59:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 16 Aug 2011 15:59:13 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 16 Aug 2011 15:57:59 -0700 Thread-Topic: Scope definition feedback (Yaron Goland) Thread-Index: AcxcZ7wlGdX3t4yBRYyXt5ZPA1iJfw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498D246@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234502498D246P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Scope definition feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:58:30 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D246P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > 4.1.2. Authorization Response: Comment "The language around scopes in > the document is really frustrating. One only finds out much later in the > document that it is perfectly allowable for an authorization server to mo= re or > less ignore what scopes are submitted and instead to just return whatever > the hell they want. This is a fine design choice but it seems like the so= rt of > thing that should be forcefully repeated anywhere in the spec that we all= ow > people to submit scopes so nobody forgets." Added new section and changed all duplicate definitions of 'scope' to refer= ence it: 3.3. Access Token Scope The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. The value of the scope parameter is expressed as a list of space- delimited, case sensitive strings. The strings are defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. The authorization server MAY fully or partially ignore the scope requested by the client based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the "scope" response parameter to inform the client of the actual scope granted. EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D246P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> 4.1.2.&n= bsp; Authorization Response: Comment “The language around scopes in

> the document is really frustratin= g. One only finds out much later in the

> document that it is perfectly allowable for an authorization server= to more or

> less ignore what sco= pes are submitted and instead to just return whatever

> the hell they want. This is a fine design choice but = it seems like the sort of

> thing = that should be forcefully repeated anywhere in the spec that we allow<= /o:p>

> people to submit scopes so nobody for= gets.”

 

Added new section and changed all duplicate definitions of &= #8216;scope’ to reference it:

 

3.3.  Access Token Scope

 

 = ;  The authorization and token endpoints allow the client to specify t= he

   scope of the access requ= est using the "scope" request parameter.  In

<= p class=3DMsoNormal>   turn, the authorization server uses the &q= uot;scope" response parameter to

&n= bsp;  inform the client of the scope of the access token issued.<= /o:p>

 

&nb= sp;  The value of the scope parameter is expressed as a list of space-=

   delimited, case sensitive = strings.  The strings are defined by the

   authorization server.  If the value contains multip= le space-delimited

   strings,= their order does not matter, and each string adds an

   additional access range to the requested scope.<= o:p>

 

   The authorization server MAY fully or partially ignore the s= cope

   requested by the clien= t based on the authorization server policy or

   the resource owner's instructions.  If the issued a= ccess token scope

   is differ= ent from the one requested by the client, the authorization

<= p class=3DMsoNormal>   server SHOULD include the "scope"= ; response parameter to inform the

 = ;  client of the actual scope granted.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E7234502498D246P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Aug 16 23:41:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719BB11E8084 for ; Tue, 16 Aug 2011 23:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P6XJYbN6DH1 for ; Tue, 16 Aug 2011 23:41:50 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id E913C21F85C6 for ; Tue, 16 Aug 2011 23:41:49 -0700 (PDT) Received: (qmail 11148 invoked from network); 17 Aug 2011 06:42:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Aug 2011 06:42:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 16 Aug 2011 23:42:35 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 16 Aug 2011 23:38:38 -0700 Thread-Topic: Authorization Code Leakage feedback (Yaron Goland) Thread-Index: AcxcoxKThYc7pGPAToaDsdhSj5islA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345028F2D75CP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 06:41:51 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345028F2D75CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > 10.6. Authorization Code Leakage: Comment "I fancy myself as being > reasonably intelligent and I'm unclear what attack is actually being desc= ribed > here." Yeah... I had to go back to -16 to be reminded of the section original titl= e 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the "redirect_uri" parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72345028F2D75CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> 10.6. Au= thorization Code Leakage: Comment “I fancy myself as being=

> reasonably intelligent and I’m uncle= ar what attack is actually being described

> here.”

 

Yeah... I had t= o go back to -16 to be reminded of the section original title 'session fixa= tion attack' to figure out what this was about.

 

<= p class=3DMsoPlainText>How about this:

 = ;

10.6.=   Authorization Code Redirection URI Manipulation

 

   When= requesting authorization using the authorization code grant

   typ= e, the client can specify a redirection URI via the "redirect_uri"= ;

=    parameter.  If an attacker can manipulate the value of th= e

=    redirection URI, it can cause the authorization server to redi= rect

   the resource owner user-agent to a URI under the control of= the

   attacker with the authorization code.

=

 

   An at= tacker can create an account at a legitimate client and initiate=

  = the authorization flow.  When the attacker is sent to the<= /span>

   = authorization server to grant access, the attacker grabs the

   aut= horization URI provided by the legitimate client, and replaces the

 &nbs= p; client's redirection URI with a URI under the control of the<= /span>

   = attacker.  The attacker then tricks the victim into following the=

 =   manipulated link to authorize access to the legitimate client.<= /o:p>

&n= bsp;

&n= bsp;  Once at the authorization server, the victim is prompted with a<= o:p>

&n= bsp;  normal, valid request on behalf of a legitimate and familiar cli= ent,

   and authorizes the request.  The victim is then redire= cted to an

   endpoint under the control of the attacker with the a= uthorization

   code.  The attacker completes the authorizatio= n flow by sending

   the authorization code to the client using th= e original redirection

   URI provided by the client.  The cli= ent exchanges the authorization

   code with an access token and li= nks it to the attacker's client

  account which can now gain acces= s to the protected resources

<= span style=3D'color:black'>   authorized by the victim (via the c= lient).

 

   In order to prevent such an attack, the authorizati= on server MUST

   ensure that the redirection URI used to obtain th= e authorization

   code, is the same as the redirection URI provide= d when exchanging the

   authorization code for an access token.&nb= sp; The authorization server

<= span style=3D'color:black'>   SHOULD require the client to regist= er their redirection URI and if

   provided, MUST validate the redi= rection URI received in the

   authorization request against the re= gistered value.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E72345028F2D75CP3PW5EX1MB01E_-- From eran@hueniverse.com Tue Aug 16 23:51:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C6411E80A7 for ; Tue, 16 Aug 2011 23:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbr4d4cTqkZ7 for ; Tue, 16 Aug 2011 23:51:13 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 904A611E80A6 for ; Tue, 16 Aug 2011 23:51:13 -0700 (PDT) Received: (qmail 26608 invoked from network); 17 Aug 2011 06:52:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Aug 2011 06:52:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 16 Aug 2011 23:52:02 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , OAuth WG Date: Tue, 16 Aug 2011 23:50:48 -0700 Thread-Topic: Authorization Code Leakage feedback (Yaron Goland) Thread-Index: AcxcoxKThYc7pGPAToaDsdhSj5islAABbMpA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 06:51:14 -0000 Noticed this follow up question after I sent this: > 10.6. Authorization Code Leakage: Comment on "The authorization server > SHOULD require the client to register their redirection URI": "Why is thi= s a > should?" Because comparing the redirect_uri value used between the two calls (author= ization and token) along with client authentication is sufficient to avoid = the attack described for confidential clients. For public clients it is a M= UST. How about this: 10.6.=A0 Authorization Code Redirection URI Manipulation =A0=A0 When requesting authorization using the authorization code grant =A0=A0 type, the client can specify a redirection URI via the "redirect_uri= " =A0=A0 parameter.=A0 If an attacker can manipulate the value of the =A0=A0 redirection URI, it can cause the authorization server to redirect =A0=A0 the resource owner user-agent to a URI under the control of the =A0=A0 attacker with the authorization code. =A0=A0 An attacker can create an account at a legitimate client and initiat= e =A0=A0 the authorization flow.=A0 When the attacker is sent to the =A0=A0 authorization server to grant access, the attacker grabs the =A0=A0 authorization URI provided by the legitimate client, and replaces th= e =A0=A0 client's redirection URI with a URI under the control of the =A0=A0 attacker.=A0 The attacker then tricks the victim into following the =A0=A0 manipulated link to authorize access to the legitimate client. =A0=A0 Once at the authorization server, the victim is prompted with a =A0=A0 normal, valid request on behalf of a legitimate and familiar client, =A0=A0 and authorizes the request.=A0 The victim is then redirected to an =A0=A0 endpoint under the control of the attacker with the authorization =A0=A0 code.=A0 The attacker completes the authorization flow by sending =A0=A0 the authorization code to the client using the original redirection =A0=A0 URI provided by the client.=A0 The client exchanges the authorizatio= n =A0=A0 code with an access token and links it to the attacker's client =A0=A0account which can now gain access to the protected resources =A0=A0 authorized by the victim (via the client). =A0=A0 In order to prevent such an attack, the authorization server MUST =A0=A0 ensure that the redirection URI used to obtain the authorization =A0=A0 code, is the same as the redirection URI provided when exchanging th= e =A0=A0 authorization code for an access token.=A0 The authorization server =A0=A0 MUST require public clients and SHOULD require confidential clients = to register their redirection URI and if provided in the request, MUST validate the redirection URI received in the authorization request against the registered value. EHL From eran@hueniverse.com Wed Aug 17 00:06:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FE111E80A7 for ; Wed, 17 Aug 2011 00:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzlYzkFrE41s for ; Wed, 17 Aug 2011 00:06:33 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 3B8E711E809C for ; Wed, 17 Aug 2011 00:06:33 -0700 (PDT) Received: (qmail 9786 invoked from network); 17 Aug 2011 07:07:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Aug 2011 07:07:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 17 Aug 2011 00:07:23 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Wed, 17 Aug 2011 00:06:06 -0700 Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland Thread-Index: AcxXpdCrqvPON2CRS72O2K03CR90kwDcgn2Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 07:06:35 -0000 This is fantastic feedback. Some parts moved to new threads. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Wednesday, August 10, 2011 2:39 PM > 1.4. Authorization Grant: Change "resource owner authorization" to > "resource owner's authorization". Ok. > 1.4.1. Authorization Code: Comment: "It seems odd that we can discuss th= e > authorization code without also discussing the security issues it raises = (e.g. > passing secure information via a browser) and thus motivating the > introduction of the refresh token. I would expect this to be referred to > here. Having read the security considerations section I can find no cohe= rent > discussion there either of the relationship between the authorization cod= e > and the refresh token and why one motivated the other. I think this is > something important for implementers to understand." This particular relationship has not been discussed on the list before. The primary justifications of refresh tokens were the need to allow access = token rotations because of the weaker nature of bearer tokens, and to suppo= rt large scale deployments in which access tokens are self-contained and do= not require a DB lookup (which implies short-lived, similar to self-contai= ned session cookies). If we are going to add a discussion, it should cover these as well, however= , such a discussion really belongs in the threat model document. We have no= t included any other motivations in the document and I don't feel this just= ifies an exception. Either way, please provide text and we can decide where it belongs. > 1.4.2. Implicit: Comment: "I find this section confusing. I think an ex= ample is > all but mandatory here if the reader is to understand what is intended. = For > example, when I first read this section I thought it was some kind of sho= rt cut > used in cases where the client and authorization server had a close > relationship and could share information such as the client's identity so= no > access code was needed. No where in here is any hint that this is about > browser based clients who don't have servers and who need a way to get > tokens. Seriously. Try to read this section as someone who knows nothing > about OAuth and tell me that you get the right idea back from it. It need= s to > be written to be both explicit as to its goals and clearer as to its mean= s." Changed first paragraph to: The implicit grant is a simplified authorization code flow opti= mized for clients implemented in a browser using a scripting language such as Jav= aScript. In the implicit flow, instead of issuing the client an authorization code, the = client is issued an access token directly (as the result of the resource owner auth= orization). The grant type is implicit as no intermediate credentials (such as an aut= horization code) are issued (and later used to obtain an access token). > 1.4.2. Implicit: Change "authenticate the client and the" to "authentic= ate the > client directly. The". Text already changed. > 1.4.2. Implicit: Change "weighted" to "weighed". Ok. > 1.4.3. Resource Owner Password Credentials: Comment on "(when > combined with a refresh token)": "This is the first time that refresh tok= ens > are mentioned in the spec. And yet there is no explanation of what they a= re. > I suspect they should anyway be introduced in section 1.4.1 (as previousl= y > noted) and then their use here will make sense. If that isn't possible t= hen it > would be good to have a forward reference to section 1.5 below so the > reader has some idea of what's going on." I removed '(when combined with a refresh token)'. This is actually not true= as there is no assumption that access tokens are always short-lived or tha= t refresh tokens will always be issued to native applications using this gr= ant type. > 1.4.4. Client Credentials: Comment on "(the client is also the resource > owner)": "I think this is misleading. Imagine something like Office where= a > client has been granted access to a particular resource by the resource > owner. The client can then ask for an access token to the resource using = the > client credentials and no access code or refresh token. Just having the > address of the intended resource (probably provided via SCOPE) along with > the client credentials is more than enough to decide if an access token s= hould > be issued. > > My point is that the client credentials scenario is fully applicable to c= ases > where the client is not the resource owner but in which the resource URI > provides all the context needed to determine if the client should be able= to > get an access token. I think the current text would imply otherwise. > > So I would propose changing the sentence to "Client credentials are used = as > an authorization grant when the client is acting on its own behalf (the c= lient is > also the resource owner) or when the authorization server has enough > context to determine from the access token request if the client has > authorization to access the requested resource."" Added: "or is requesting access to protected resources based on an authorization p= reviously arranged with the authorization server." To make is more in line with the existing language of 4.4. > 1.4.5. Extensions: Comment: "I would change this sentence to read > "Additional grant types may be defined to support new approaches to > authentication/authorization as well as to provide a bridge between OAuth > and other protocols."" Took out the entire section. The introduction to 1.4 already contained all = the relevant information. > 1.5. Refresh Token: Change "a protected resource requests" to "a protecte= d > resource request". Ok. > 1.5. Refresh Token: Comment on "Refresh tokens are credentials used to > obtain access tokens.": "This sentence presumes that refresh tokens are > self-contained credentials. In other words that one can get an access tok= en > just using a refresh token and nothing else. This presumption is rebutted > later in the document but I think it's confusing to imply one thing here = and > state otherwise later on." > 1.5. Refresh Token: Comment on "(G) The client requests a new access > token by authenticating with the authorization server and presenting the > refresh token.": "Hum... now the text seems to contradict itself. Above i= t > seemed like you could use the refresh token by itself to get an access to= ken > and I had to ask for language that made it clear that you could use a ref= resh > token with other credentials. But the text of point G now implies the ex= act > opposite, that refresh tokens can only be used with other credentials and > not by themselves. (Even though the picture in figure 2 for step G implie= s the > opposite). I would edit this language to say "The client requests a new a= ccess > token. Depending on the authorization server's policies this request migh= t be > made with the refresh token by itself or with a combination of the refres= h > token and other client credentials."" Added to (G): "The client authentication requirements are based on the clie= nt type and on the authorization server policies." > 2.1. Client Types: Comment on "user-agent-based application": "Give the > poor reader a hint and mention 'browser' somewhere in the paragraph > below. For example "A user-agent-based application is a public client (su= ch as > a web browser) in which the...."" Ok. > 2.1. Client Types: web application: Change "access tokens or refresh toke= ns, > can receive an acceptable level" to "access tokens or refresh tokens, can= , in > some cases, receive an acceptable level". This doesn't really add anything. > 2.4. Client Authentication: Add a period after "etc". Huh? > 2.4.1. Client Password: Comment on "charset=3DUTF-8": "The use of UTF-8 w= ith > x-www-form-urlencoded is explicitly banned by HTML 4.01 section 17.13.1. = If > we want to use UTF-8 then we have to use multipart/form-data, also define= d > by HTML 4.01 (section 17.13.4). But since nobody would actually want to d= o > that I would suggest putting in a reference to section 4.2 of RFC 5552 wh= ich > actually defines how to use UTF-8 with x-www-form-urlencoded and > specifying that the 5552 extension MUST be supported by OAuth > participants." http://www.w3.org/TR/html401/interact/forms.html#h-17.13.1 Where? > 3.1. Authorization Endpoint: Comment on first sentence: "There is a thi= rd > option - none of the above. It would be a shame if the text of this draf= t > explicitly prohibits that pattern." Dropped "which is expressed explicitly as an authorization code (later exch= anged for an access token), or implicitly by direct issuance of an access t= oken" as it is no longer accurate given the new response type extensibility= . Either way, section 3.1.1 covers this. > 3.1. Authorization Endpoint: Comment on "[RFC3986] section 3": "Shouldn= 't > we point directly to section 3.4 which exactly defines the query componen= t?" Ok. > 3.1. Authorization Endpoint: Comment on "MUST be retained when adding > additional query > parameters": "HIGH IMPORTANCE - This specification is incomplete. > Section 3.4 of RFC 3986 simply asserts the existence of a query component= . It > says nothing about the syntax of that component. The spec assumes that th= e > component is using x-www-form-urlencoded but that is not in any way > mandated by RFC 3986. So there is a normative sentence missing here which > states that any query parameter on the authorization endpoint's URI MUST > be defined as specified in x-www-form-urlencoded." Changed to: The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted ([W3C.REC-html401-19991224]) query component ([RFC3986] section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component. > 3.1. Authorization Endpoint: Comment on "The authorization server > SHOULD ignore unrecognized request parameters.": "Although that is normal > behavior for application protocols it seems rather dangerous for a securi= ty > protocol. After all what if the client put in a parameter specifying some= thing > security related about the request thinking that the authorization endpoi= nt > would honor it and then the authorization endpoint silently ignores it? = Again, > this is a security protocol, not a generic application protocol, it seems= to be > that unrecognized parameters should cause a failure." This is an issue for those defining additional parameters. Basically, you s= hould not define new parameters that when not-understood cause degradation = of the base protocol security. > 3.1.2. Redirection Endpoint: Comment on "when initiating the authorizati= on > request": "I would suggest more explicit language "or as specified in the > redirection URI value in the authorization request."" Changed to "during the client registration process or when making the autho= rization request". > 3.2.1. Client Authentication: Change "Recovery" to "Recovering". Ok. > 3.2.1. Client Authentication: Change "credentials, by preventing an attac= ker > from abusing" to "credentials. This prevents an attacker from abusing" Changed 'by' to 'thus'. > 3.2.1. Client Authentication: Change "periodic credentials rotation" to > "periodic credential rotation". Ok. > 3.2.1. Client Authentication: Comment on "while rotation of a single set = of > client credentials is significantly easier": "The spec calls out rotation= of > credentials as being crucial but then doesn't define how this is to be do= ne? > That seems kind of odd. Shouldn't we define an endpoint where one can > submit one's old but unexpired credentials for new ones? This still leave= s the > edge case of what to do if the old credentials have expired and new ones > haven't been issued but that is unavoidable and in that case we can requi= re > out of scope action." The spec leaves much out of scope. You are welcome to submit a proposal for= such a new endpoint. > 4.1. Authorization Code: Comment on first "^": "Shouldn't this be a v > character and not a ^? This would make it consistent with A which also > crosses two boxes and points in the same direction." (B) is bi-directional (server serves a login page, user enter password, fet= ches another page...). > 4.1. Authorization Code: Change "If valid, responds back with an access > token" to "If the request is valid, then the authorization server will re= sponds > back with an access token and optionally a refresh token". Ok. > 4.1.2. Authorization Response: Comment on "state": "Don't we have to > provide some guidance on how large the state value can safely be? > Otherwise we are asking clients to rewrite their state mechanisms every t= ime > they throw in support for a new protected resource server. We have to set > expectations across the industry if we are to hope for actual > interoperability." Need proposed text. > 4.1.2.1. Error Response: Comment on "UTF-8 encoded text": "I think just > saying UTF-8 encoded text can be misleading. It's not legal to put UTF-8 > characters into a x-www-form-urlencoded used in a GET (as defined by > section 17.13.1 of HTML 4.01). So what you have to do is take the UTF-8 S= tring > and then URL encode it. Which is fine but we should call this out. Note = that > this is a separate issue than UTF-8 support for x-www-form-urlencoded. Th= at > issue only applies when the form is in the request body. In this scenario= the > form is in a URL. There is no question that URLs in HTTP request lists do= n't > support UTF-8." Whatever value goes into the parameter has to be form-encoded. I think that= 's pretty clear throughout the specification. We don't put any restrictions= on most values we expect to be delivered using form-encoded strings. The e= xpectation is that implementers will use a library that takes some structur= e with parameter names and values and turn it into a valid URI or body. > 4.1.3. Access Token Request: Change "For example, the client makes the > following HTTP using" to "For example, if the client makes the following = HTTP > request using" Already fixed. > 4.1.3. Access Token Request: Comment on "that their values are identical"= : > "This verbiage isn't much use, for example, if the client can always send= the > same redirect_uri. So, just to be clear, this text here doesn't in anyway > change my previous recommendation regarding the attack previously > described." Huh? > 4.1.4. Access Token Response: Comment on ""token_type":"example"": > "Just to prevent any confusion it would be good to actually define the > token_type "example" in this document (Probably in section 7.1 and later = in > the IANA section) and specify that it is reserved for use in examples whe= re > one does not wish to be more specific." Added to 8.1: "The token type 'example' is reserved for use in examples." > 4.2. Implicit Grant: Comment "I have run into multiple people (including > myself) who have read the OAuth spec and came away completely confused > about when the heck one is supposed to use the implicit grant flow for. I= t's > not immediately obvious that it's a way to support standalone browser bas= ed > clients. Can we put in an example or something to make it more obvious wh= y > it's here?" I think the text is pretty clear: These clients are typically implemented in a browser using a scripting l= anguage such as JavaScript. But I'm open to suggestions. Please propose text. > 4.2.1. Authorization Request: Comment on redirect_uri: "Given that the o= nly > way to identify the client in the implicit grant flow is via the redirect= _uri, how > can it be optional?" client_id is required. > 4.3. Resource Owner Password Credentials: Change "enabling the grant type= , > and only when other flows" to "enabling the grant type and only use it wh= en > other flows". Ok. > 4.3. Resource Owner Password Credentials: Change "resource owner > credentials" to "resource owner's credentials". Ok. > 4.3.2. Access Token Request: Comment on "authorization server MUST > protect the endpoint against brute force attacks": "Shouldn't the > requirement to prevent against brute force attacks apply to all credentia= ls, > resource owner or otherwise? In other words in section 2.4.1 we talk abou= t > how clients submit their name/password. Shouldn't endpoints accepting > client name/passwords have the same protections against brute force > attack?" Yes, but in general brute force attacks are more likely on human-friendly p= asswords than machine-issued client credentials. I'll add it to 2.4.1: Since this client authentication method involves a password, th= e authorization server MUST protect any endpoint utilizing it against brute force atta= cks. > 4.4.3. Access Token Response: Comment on "A refresh token SHOULD NOT > be included": "Why isn't this a MUST NOT?" Working group consensus. It was discussed and some people expressed use cas= es for allowing it. > 4.5. Extensions: Comment "Isn't the text in this section and 8.3 redundan= t > with each other? It seems like we should take the text from here and merg= e > it with section 8.3 so all the extension information is recorded in one > place. It's just plain that all other extension points are in section 8 = but this > one." This one is about usage white the others are about registration. This is th= e right place to inform developers of the need to handle URI values. > 5.1. Successful Response: Comment on "parameter at the highest structure > level": "Are there any guarantees about the order of the members in the > JSON object? If not we should say so explicitly." Added: "The order of parameters does not matter and can vary." > 5.2. Error Response: Comment on "multiple client authentications included= " > in invalid_client: "Shouldn't this be an invalid_request?" Yep. > 5.2. Error Response: Comment on "Numerical values are included as JSON > numbers": "Same issue as before, does ordering matter and if not we need > to say that." Same text added. > 8.1. Defining Access Token Types: Change "or use a unique" to "or using a > unique". Ok. > 9. Native Applications: Change "an scheme" to "a scheme" Ok. > 9. Native Applications: Change "offer an improved usability" to "offer > improved usability" Ok. > 9. Native Applications: Change "inability to keep credentials confident= ial" to > "inability to keep client credentials confidential". Ok. > 9. Native Applications: Change "When using the implicit grant type flow= a > refresh token is not returned" to "When using the implicit grant type flo= w a > refresh token is not returned so once the access token expires the > application will have to repeat the authorization process". Ok. > 10.2. Client Impersonation: Change "keep is client" to "keep its client"= . Already fixed. > 10.2. Client Impersonation: Change "due to the client nature" to "due to= the > client's nature". Ok. > 10.2. Client Impersonation: Change "URI used for receiving authorization= " to > "URI used for receiving authorization requests" Actually, responses. > 10.2. Client Impersonation: Change "engage the resource owner" to > "engaging the resource owner". Ok. > 10.2. Client Impersonation: Change "and authorize the request" to "and > authorize or reject the request". Ok. > 10.3. Access Tokens: Change "Access token (as well as any access token ty= pe- > specific attributes)" to "Access tokens (as well as any access token type > specific attributes)". Nah. I like the -. > 10.3. Access Tokens: Change "guessed to produce" to "guessed so as to > prevent unauthorized parties from producing". Ok. > 10.4. Refresh Tokens: Comment "As mentioned previously we really should > explain why we introduced refresh tokens. Without understanding the > intent of the mechanism it's unlikely implementers will use them > appropriately." Disagree. Feel free to propose text. > 10.4. Refresh Tokens: Change "storage, and shared only among" to "storag= e, > and are to be shared only among". Nah. > 10.4. Refresh Tokens: Change "refresh tokens rotation" to "refresh token > rotation". Ok. > 10.4. Refresh Tokens: Change "guessed to produce" to "guessed so as to > prevent unauthorized parties from producing". Ok. > 10.7. Resource Owner Password Credentials: Comment on "password anti- > pattern": "Is it fair to expect that the reader knows what the password a= nti- > pattern is? Shouldn't some reference to a definition of this pattern be > required?" In this case, lack of understanding does not take away from the rest of the= prose and a reader can look it up. It is a well-established term and the r= eason for OAuth in the first place. But feel free to propose text. > 10.7. Resource Owner Password Credentials: Comment on "The > authorization server SHOULD restrict the scope and lifetime of access tok= ens > issued via this grant type": "Restrict in what ways? Based on what criter= ia? > This statement is the equivalent of saying "don't do bad stuff". Perhaps = true > but not terribly useful." Yeah... especially with a normative SHOULD. Changed 'restrict' to 'consider= ' and lowercased the should (I know it doesn't really matter but it reads b= etter now): The authorization server should consider the scope and lifetime of access tokens issued via this grant type. > 10.12. Cross-Site Request Forgery: Comment on first paragraph: "I challen= ge > any reasonably intelligent person who does not already know what a CSRF i= s > to read this paragraph and come away any clearer as to what is being > discussed. At a minimum isn't some reference to a complete definition of > CSRF needed if there is to be any hope of user compliance?" It seems we are still discussing this section on another thread. But genera= lly, we cannot be expected to provide a comprehensive web security guide wi= thin this protocol. The attack is presented in very general terms and the r= eader should go and study it if they are not familiar with it. I think the = extra prose in the beginning doesn't hurt but I don't mind dropping it and = just starting with "A cross-site request forgery (CSRF) allow an attacker t= o inject..." and drop the entire first paragraph. No change for now. > 10.12. Cross-Site Request Forgery: Comment on "The "state" request > parameter MUST contain a non-guessable value": "Actually a non-guessable > value won't stop the attack discussed in the previous paragraph on its ow= n. > What's also needed is a way to uniquely (and unbreakably) associate the > state with a particular user so that if an authorization code swap occurs= it can > be reliably detected." Discussed on another thread. > 10.13. Clickjacking: Comment on "x-frame-options": "The recommendation > seems confused. Is it o.k. to just rely on x-frame-options or MUST other > actions be taken?" Seems pretty clear to me. There is no full solution, but using the header i= s one way to prevent newer browsers from allowing such an attack. Can't put= a MUST here because there is no way to completely close this attack vector= . > 11.1. The OAuth Access Token Type Registry: Change "toke type" to "token > type". Ok. > 11.1.1. Registration Template: Change "protected resources requests usin= g > access token" to "protected resource requests using access tokens". Ok. > 11.1.1. Registration Template: Change "Reference to document" to > "Reference to the document". Ok. Thanks! EHL From eran@hueniverse.com Wed Aug 17 00:13:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C668021F861A for ; Wed, 17 Aug 2011 00:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atwrzvd5csTP for ; Wed, 17 Aug 2011 00:13:37 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 6E76021F85EE for ; Wed, 17 Aug 2011 00:13:35 -0700 (PDT) Received: (qmail 17056 invoked from network); 17 Aug 2011 07:14:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Aug 2011 07:14:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 17 Aug 2011 00:14:26 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , "OAuth WG (oauth@ietf.org)" Date: Wed, 17 Aug 2011 00:13:10 -0700 Thread-Topic: x-www-form-urlencoded Thread-Index: AcxYUPGtIbsp9lRrSSie2MIJkueB6QEW5ZYg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] x-www-form-urlencoded X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 07:13:38 -0000 This seems to include two separate items. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Anthony Nadalin > Sent: Friday, August 12, 2011 8:29 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] x-www-form-urlencoded >=20 > In the text on the authorization and token endpoints an assumption is mad= e > that the query component of the URLs will be specified based on x-www- > form-urlencoded. But in fact that is never explicitly stated. What is exp= licitly > stated is that RFC 3986 section 3 has to be used (and then only for the > authorization endpoint, not the token endpoint). But section 3 just defin= es > what characters can be used in a query component, it says nothing about x= - > www-form-urlencoded. Suggest that the specification needs =A0to normative= ly > state that we are requiring all authorization endpoints that use the quer= y > component to do so using x-www-form-urlencoded.=A0 This issue was raised by Yaron and corrected for both endpoints as indicate= d on the other thread. The new text is: The endpoint URI MAY include an "application/x-www-form-urlencode= d" formatted ([W3C.REC-html401-19991224]) query component ([RFC3986] section 3= .4), which MUST be retained when adding additional query parameters. The endpoint= URI MUST NOT include a fragment component. > Where RFC 5552 comes > into the picture is in cases where the request body is an html form. In t= hat > case it makes sense to natively encode the form content using UTF-8. So t= his > only applies to OAuth requests that use the request body. So this would > apply to sections 2.4.1, 3.1, 3.2, 4.1.3, 4.3.2 & 4.4.2. Really, anywhere= that a > request can be made in the request body I have no idea what this is about. EHL From t.lodderstedt@telekom.de Wed Aug 17 03:21:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A43F21F8AD3 for ; Wed, 17 Aug 2011 03:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uOJtweatPam for ; Wed, 17 Aug 2011 03:21:37 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 6657A21F8A4D for ; Wed, 17 Aug 2011 03:21:36 -0700 (PDT) Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail51.telekom.de with ESMTP; 17 Aug 2011 12:22:16 +0200 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by g8pxd.blf01.telekom.de with ESMTP; Wed, 17 Aug 2011 12:22:16 +0200 Received: from QEO40072.de.t-online.corp ([169.254.1.145]) by QEO40065.de.t-online.corp ([10.224.209.65]) with mapi; Wed, 17 Aug 2011 12:22:15 +0200 From: "Lodderstedt, Torsten" To: Eran Hammer-Lahav , OAuth WG Date: Wed, 17 Aug 2011 12:22:14 +0200 Thread-Topic: Authorization Code Leakage feedback (Yaron Goland) Thread-Index: AcxcoxKThYc7pGPAToaDsdhSj5islAAI/wTA Message-Id: <63366D5A116E514AA4A9872D3C53353956FE1275A3@QEO40072.de.t-online.corp> References: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_63366D5A116E514AA4A9872D3C53353956FE1275A3QEO40072deton_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 10:21:39 -0000 --_000_63366D5A116E514AA4A9872D3C53353956FE1275A3QEO40072deton_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Text sounds very good. wrt title: this threat is about phishing another user's authorization code.= Because of the design of the protocol this requires the attacker to use an= other redirect URI than used by the legitimate client. To make this the tit= le sound bit weird to me. Why not "authorization code phishing"? regards, Torsten. Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) > 10.6. Authorization Code Leakage: Comment "I fancy myself as being > reasonably intelligent and I'm unclear what attack is actually being desc= ribed > here." Yeah... I had to go back to -16 to be reminded of the section original titl= e 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the "redirect_uri" parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL --_000_63366D5A116E514AA4A9872D3C53353956FE1275A3QEO40072deton_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Text sounds very good.

 

wrt title: this threat is = about phishing another user’s authorization code. Because of the desi= gn of the protocol this requires the attacker to use another redirect URI t= han used by the legitimate client. To make this the title sound bit weird t= o me. Why not “authorization code phishing”?<= /p>

&nb= sp;

regards,

Torsten.

 

=

Von:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Mittwoch, 17. A= ugust 2011 08:39
An: OAuth WG
Betreff: [OAUTH-WG] Autho= rization Code Leakage feedback (Yaron Goland)

 

=

>= ; 10.6. Authorization Code Leakage: Comment “I fancy myself as being<= o:p>

<= span lang=3DEN-US>> reasonably intelligent and I’m unclear what at= tack is actually being described

> here.”

 

Yeah... I had to= go back to -16 to be reminded of the section original title 'session fixat= ion attack' to figure out what this was about.

 

How about this:<= o:p>

<= span lang=3DEN-US style=3D'color:black'> 

10.6.  Authorization Code Redirection URI Manipulation

 

   When requesting authorization using the authorizati= on code grant

   type, th= e client can specify a redirection URI via the "redirect_uri"

   parameter.  If an at= tacker can manipulate the value of the

   redirection URI, it can cause the authorization server to = redirect

   the resource = owner user-agent to a URI under the control of the

   attacker with the authorization code.

 

   An attacker can create an account at a legitimate client = and initiate

   the autho= rization flow.  When the attacker is sent to the

=

   authorization server to grant access, the a= ttacker grabs the

   auth= orization URI provided by the legitimate client, and replaces the

   client's redirection URI with a= URI under the control of the

 = ;  attacker.  The attacker then tricks the victim into following = the

   manipulated link t= o authorize access to the legitimate client.

 

   Once= at the authorization server, the victim is prompted with a

   normal, valid request on behalf of a = legitimate and familiar client,

&nb= sp;  and authorizes the request.  The victim is then redirected t= o an

   endpoint under th= e control of the attacker with the authorization

   code.  The attacker completes the authoriza= tion flow by sending

   t= he authorization code to the client using the original redirection

   URI provided by the client.&nb= sp; The client exchanges the authorization

   code with an access token and links it to the attacker= 's client

  account which= can now gain access to the protected resources

   authorized by the victim (via the client).

 

   In order to prevent such an attack, the authorization se= rver MUST

   ensure that = the redirection URI used to obtain the authorization

<= p class=3DMsoPlainText style=3D'margin-left:35.4pt'>   code, is the same as the redirection URI pro= vided when exchanging the

 &nb= sp; authorization code for an access token.  The authorization server<= o:p>

<= span lang=3DEN-US style=3D'color:black'>   SHOULD require the cli= ent to register their redirection URI and if

   provided, MUST validate the redirection URI receive= d in the

   authorization= request against the registered value.

 

EHL

= --_000_63366D5A116E514AA4A9872D3C53353956FE1275A3QEO40072deton_-- From eran@hueniverse.com Wed Aug 17 11:15:51 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1CE21F8BF9 for ; Wed, 17 Aug 2011 11:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn1L4lHarcst for ; Wed, 17 Aug 2011 11:15:50 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id AFD7E21F8BE8 for ; Wed, 17 Aug 2011 11:15:50 -0700 (PDT) Received: (qmail 30564 invoked from network); 17 Aug 2011 18:16:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Aug 2011 18:16:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 17 Aug 2011 11:16:31 -0700 From: Eran Hammer-Lahav To: Justin Richer , "OAuth WG (oauth@ietf.org)" Date: Wed, 17 Aug 2011 11:15:15 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comments Thread-Index: AcxYcNP9BMbO/ni8T3yA7gll5itVuwEgmb+A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFA82D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1313096811.22073.96.camel@ground> In-Reply-To: <1313096811.22073.96.camel@ground> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Anganes, Amanda L" Subject: Re: [OAUTH-WG] Draft 20 last call comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 18:15:51 -0000 Thanks for the feedback. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Justin Richer > Sent: Thursday, August 11, 2011 2:07 PM > 1.2/1.4: The term "authorization grant" remains confusing and the > introduction is riddled with jargon like "intermediate credential". With = the > diagram in 1.2, it appears to be an explicit technological underpinning o= f the > protocol flow instead of a general conceptual construct that is used in s= everal > different ways. Basically, what "authorization grant" *means* is not obvi= ous > within this document. > > Section 4 makes much more sense than the introduction text does here. > Perhaps we should just replace most of 1.4 with just the introductory tex= t to > 4 (perhaps slightly expanded), and then a reference to the sub-parts of > section 4 for the meat of the concept (and in the process, nix the subsec= tions > of 1.4 entirely). >=20 > 1.2(B): "Provided" is wrong here (it implies a direct hand-over), and the= last > sentence is awkward. Suggest reword to: > The client receives an authorization grant which represents the > authorization granted by the resource owner. The type of > authorization grant is dependent on which methods are supported > by both the client and authorization server. Change (B) in 1.2 to: The client receives an authorization grant which is a credent= ial representing the resource owner's authorization, expressed using one of fo= ur grant types defined in this specification or using an extension grant type. The a= uthorization grant type depends on the method used by the client to request authoriza= tion and the types supported by the authorization server. And changed 1.4 to: An authorization grant is a credential representing the resource = owner's authorization (to access its protected resources) used by the client to obtain = an access token. This specification defines four grant types: authorization code, impli= cit, resource owner password credentials, and client credentials, as well as an exten= sibility mechanism for defining additional types. > 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Toke= n, > Refresh Token Not sure. What do others think? I put access token first because it is a mo= re important term to get out of the way. > 1.4.1: We probably want to mention a user agent here in the exposure risk= at > the end. Since that's really the problem -- the browser could steal the t= oken, > not the end user. Proposed text? > 1.4.2: Still don't like the term "implicit". It's misleading. Even "direc= t > authorization" would be better, though still not ideal. It's the best we've got. "Direct authorization" is not a grant type, but a = flow description. > 1.4.5: Throw a simple reference to 8.3 here? No forward references whenever possible. > 2: Isn't "means" generally treated as singular in instances like this? > Thus "means ... is" instead of "means ... are". Don't know. > 2.1/2.2: The requirements (2.2) should go first in section 2. The client = types > are part of deciding the requirements, and the concepts flow better this = way. You need to first define client types before you can require it. > 2.1: I like the calling out of the types of clients, it helps cement thin= gs. >=20 > 2.3: Suggest renaming to "Client Identification" to parallel "Client > Authentication" in 2.4 It's not about identification. =20 > 2.3: Should "... cannot be used alone" be made into a normative, as "... > MUST NOT be used alone"? I'm ok with that. Anyone else? > 2.4.2: Want to mention the MAC binding as an example here? This would > parallel the OAuth2 method of signing the fetch for a request token more > directly. Nah. > 3. Authorization endpoint's "used to obtain authorization from" should be > "used to obtain an authorization grant from", to be parallel with the tok= en > endpoint description. Ok. EHL From jricher@mitre.org Wed Aug 17 13:12:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F087B21F8A66 for ; Wed, 17 Aug 2011 13:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evxSihWaIHML for ; Wed, 17 Aug 2011 13:12:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 003E421F8829 for ; Wed, 17 Aug 2011 13:12:34 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 234CA21B12EA; Wed, 17 Aug 2011 16:13:25 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1CC3C21B12E0; Wed, 17 Aug 2011 16:13:25 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.3.192.1; Wed, 17 Aug 2011 16:13:24 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFA82D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1313096811.22073.96.camel@ground> <90C41DD21FB7C64BB94121FBBC2E72345029DFA82D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Wed, 17 Aug 2011 16:12:45 -0400 Message-ID: <1313611965.13419.112.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "Anganes, Amanda L" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft 20 last call comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 20:12:36 -0000 Comments inline. On Wed, 2011-08-17 at 14:15 -0400, Eran Hammer-Lahav wrote: > Thanks for the feedback. > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Justin Richer > > Sent: Thursday, August 11, 2011 2:07 PM > > > 1.2/1.4: The term "authorization grant" remains confusing and the > > introduction is riddled with jargon like "intermediate credential". With the > > diagram in 1.2, it appears to be an explicit technological underpinning of the > > protocol flow instead of a general conceptual construct that is used in several > > different ways. Basically, what "authorization grant" *means* is not obvious > > within this document. > > > > Section 4 makes much more sense than the introduction text does here. > > Perhaps we should just replace most of 1.4 with just the introductory text to > > 4 (perhaps slightly expanded), and then a reference to the sub-parts of > > section 4 for the meat of the concept (and in the process, nix the subsections > > of 1.4 entirely). > > > > 1.2(B): "Provided" is wrong here (it implies a direct hand-over), and the last > > sentence is awkward. Suggest reword to: > > The client receives an authorization grant which represents the > > authorization granted by the resource owner. The type of > > authorization grant is dependent on which methods are supported > > by both the client and authorization server. > > Change (B) in 1.2 to: > > The client receives an authorization grant which is a credential representing > the resource owner's authorization, expressed using one of four grant types defined > in this specification or using an extension grant type. The authorization grant type > depends on the method used by the client to request authorization and the types > supported by the authorization server. > > And changed 1.4 to: > > An authorization grant is a credential representing the resource owner's authorization > (to access its protected resources) used by the client to obtain an access token. This > specification defines four grant types: authorization code, implicit, resource owner > password credentials, and client credentials, as well as an extensibility mechanism for > defining additional types. Much better for both overall though. > > 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token, > > Refresh Token > > Not sure. What do others think? I put access token first because it is a more important term to get out of the way. I agree that access tokens are a more important topic to OAuth overall, but the rest of the document presents things in protocol flow order: you get the auth grant, then you get the tokens. > > 1.4.1: We probably want to mention a user agent here in the exposure risk at > > the end. Since that's really the problem -- the browser could steal the token, > > not the end user. > > Proposed text? The authorization code provides a few important security benefits such as the ability to authenticate the client and issuing the access token directly to the client without potentially exposing it to others, including the resource owner or other applications in the resource owner's user agent. (Still not good wording... but the idea is to point out that you the leak possibility here stems from using the front channel.) > > 1.4.2: Still don't like the term "implicit". It's misleading. Even "direct > > authorization" would be better, though still not ideal. > > It's the best we've got. "Direct authorization" is not a grant type, but a flow description. Fair enough. I shall remain a conscientious objector. :) > > 1.4.5: Throw a simple reference to 8.3 here? > > No forward references whenever possible. Fair style point, but I think this one is worth it. This is why our documents have hyperlinks. For each of 1.4.x, I'd still rather see the 1.4.x sections just go away. > > 2: Isn't "means" generally treated as singular in instances like this? > > Thus "means ... is" instead of "means ... are". > > Don't know. I think it is, unless someone can put a stake in to say that's wrong. > > 2.1/2.2: The requirements (2.2) should go first in section 2. The client types > > are part of deciding the requirements, and the concepts flow better this way. > > You need to first define client types before you can require it. No you don't, you just need to reference them. You already don't define the other requirements until after (such as the redirection urls). I think it reads better to have the requirements up front, when the full matter of what they're all about in the following sections. The client As it is now, there are both forward and backward references in the requirements paragraph and it's confusing to read like that. > > 2.1: I like the calling out of the types of clients, it helps cement things. > > > > 2.3: Suggest renaming to "Client Identification" to parallel "Client > > Authentication" in 2.4 > > It's not about identification. Then why is it called "Client Identifier"? Usually, one uses an identifier for identification. :) Really, this comment was about parallelizing the language in the two subsequent headers: Identification and Authentication. > > 2.4.2: Want to mention the MAC binding as an example here? This would > > parallel the OAuth2 method of signing the fetch for a request token more > > directly. > > Nah. Let me put it stronger: I would like to see an explicit reference to the MAC binding here as an example of a stronger auth binding, along with an example. OAuth1 allowed for binding against the token endpoint using a client secret that was not passed across the wire, and the MAC spec gives that capability to OAuth2. I would really like to see that. I see no problem in the core document pointing out the MAC and Bearer documents as prime examples where appropriate. -- Justin From barryleiba.mailing.lists@gmail.com Wed Aug 17 13:33:48 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1DC1F0C58 for ; Wed, 17 Aug 2011 13:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.038 X-Spam-Level: X-Spam-Status: No, score=-103.038 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wj3ZstP0kGG3 for ; Wed, 17 Aug 2011 13:33:47 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE89F1F0C51 for ; Wed, 17 Aug 2011 13:33:47 -0700 (PDT) Received: by yie12 with SMTP id 12so1146927yie.31 for ; Wed, 17 Aug 2011 13:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=wbGqwxoVqq8hvy7FQ28LtKNpYm7buBbbpE/DRrH0b04=; b=Y9FSGlhBxbXb4G8+59aBiH7lJl6BXr7tFNN8nU+IPWKBMyyEpOoo2Kfxyd8lOgMznl hIHFwdOo61DoJexf/rvMwnpl4cDjUfzHzN20QG3P8nTBwYTdasAn2yFT29bZONv6pbM0 SpaoxsYjxEKhVH6AY/q6pWgrE0dzAF13LlZFA= MIME-Version: 1.0 Received: by 10.147.87.18 with SMTP id p18mr1556344yal.24.1313613279558; Wed, 17 Aug 2011 13:34:39 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Wed, 17 Aug 2011 13:34:39 -0700 (PDT) Date: Wed, 17 Aug 2011 16:34:39 -0400 X-Google-Sender-Auth: jjpNWb8bjg4STn0hWSvQ2ee3rTM Message-ID: From: Barry Leiba To: oauth@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 20:33:48 -0000 I'm sorry for the delay in getting this written. Because of the delay, the working group has just a short time to review my proposed response, below. Everyone, please have a look at the answers I propose to send, and post any objections to this thread by the end of the day on Monday, 22 August. Hannes, please also check with the IAB in parallel, and make sure we can send this via Murray as soon as we've resolved any WG objections. Barry, as chair ----------------------------------------------------------------- The IETF OAuth working group thanks OMA ARC SEC for the liaison statement titled "OAuth discovery and specification availability", dated 18 July 2011. The OMA liaison statement asks the OAuth working group to address five issues, and our answers are as follows: =95 Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. Answer: The IETF cannot guarantee publication dates, but we can give some best-guess timeframes. As this writing, draft-ietf-oauth-v2 and draft-ietf-oauth-v2-bearer have completed Working Group last call and are undergoing their final revisions before being sent to the IESG. We expect the final versions of those documents to be in the RFC Editor queue around the end of September, though it could be later if issues come up in IETF-wide last call or during IESG evaluation. The draft-hammer-oauth-v2-mac-token document has been replaced by draft-ietf-oauth-v2-http-mac, which is a working group document. It is likely to be in the RFC Editor queue by the end of the year. The remaining two documents are not working group documents, and the working group can say nothing about their status. The OAuth working group intends to revise its charter in the November timeframe, and it's possible that one or both of those documents could be adopted by the working group at that time, and we could have further information about target publication dates then. =95 Availability of the OAuth Parameters Registry Answer: The draft-ietf-oauth-v2 document establishes the OAuth Parameters Registry (in section 11.2, as of draft version 20). The registry will be available when the RFC is published, which will be some time after the document goes into the RFC Editor queue, depending upon the RFC Editor's load at the time. =95 IETF intent to specify an OAuth Discovery mechanism Answer: There is interest among OAuth working group participants for specifying such a mechanism, but the work is not in the current charter. It will likely be considered during the aforementioned charter update in (approximately) November. =95 Considerations that can help implementors decide about the type of OAuth access token to deploy. Answer: There is no current work planned, but documents with such implementation advice might also be considered during the rechartering discussion. =95 For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. Answer: In the bearer token document (Section 2.4 of draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header Field"), the "scope-v" element is unambiguously defined to allow a specific set of characters. That set of characters does permit, but does not mandate, support for percent-encoding of characters. ----------------------------------------------------------------- From igor.faynberg@alcatel-lucent.com Wed Aug 17 13:55:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BAE11E80C5 for ; Wed, 17 Aug 2011 13:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOQ8l6JKiFMN for ; Wed, 17 Aug 2011 13:55:47 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id CA3DE11E80C3 for ; Wed, 17 Aug 2011 13:55:47 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p7HKuda4019507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Aug 2011 15:56:39 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7HKucED031160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 17 Aug 2011 15:56:39 -0500 Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p7HKucfr002612; Wed, 17 Aug 2011 15:56:38 -0500 (CDT) Message-ID: <4E4C2B05.508@alcatel-lucent.com> Date: Wed, 17 Aug 2011 16:56:37 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 20:55:51 -0000 Barry, I personally think that this is both a very thorough and very timely follow-up. (You may consider a minor editorial: "As this writing" in the first answer, should be "As of this writing." Could not catch anything else. The only other suggestion is that maybe the response could omit RFC Queue and other details of the IETF process as those are unfamiliar to OMA. They asked for dates, and the dates are there.) Igor On 8/17/2011 4:34 PM, Barry Leiba wrote: > I'm sorry for the delay in getting this written. Because of the > delay, the working group has just a short time to review my proposed > response, below. Everyone, please have a look at the answers I > propose to send, and post any objections to this thread by the end of > the day on Monday, 22 August. Hannes, please also check with the IAB > in parallel, and make sure we can send this via Murray as soon as > we've resolved any WG objections. > > Barry, as chair > > ----------------------------------------------------------------- > > The IETF OAuth working group thanks OMA ARC SEC for the liaison > statement titled "OAuth discovery and specification availability", > dated 18 July 2011. > > The OMA liaison statement asks the OAuth working group to address five > issues, and our answers are as follows: > > • Availability of the IETF OAuth specifications: especially > [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also > [draft-hammer-oauth-v2-mac-token], > [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. > > Answer: > The IETF cannot guarantee publication dates, but we can give some > best-guess timeframes. As this writing, draft-ietf-oauth-v2 and > draft-ietf-oauth-v2-bearer have completed Working Group last call and > are undergoing their final revisions before being sent to the IESG. > We expect the final versions of those documents to be in the RFC > Editor queue around the end of September, though it could be later if > issues come up in IETF-wide last call or during IESG evaluation. The > draft-hammer-oauth-v2-mac-token document has been replaced by > draft-ietf-oauth-v2-http-mac, which is a working group document. It > is likely to be in the RFC Editor queue by the end of the year. > > The remaining two documents are not working group documents, and the > working group can say nothing about their status. The OAuth working > group intends to revise its charter in the November timeframe, and > it's possible that one or both of those documents could be adopted by > the working group at that time, and we could have further information > about target publication dates then. > > • Availability of the OAuth Parameters Registry > > Answer: > The draft-ietf-oauth-v2 document establishes the OAuth Parameters > Registry (in section 11.2, as of draft version 20). The registry will > be available when the RFC is published, which will be some time after > the document goes into the RFC Editor queue, depending upon the RFC > Editor's load at the time. > > • IETF intent to specify an OAuth Discovery mechanism > > Answer: > There is interest among OAuth working group participants for > specifying such a mechanism, but the work is not in the current > charter. It will likely be considered during the aforementioned > charter update in (approximately) November. > > • Considerations that can help implementors decide about the type of > OAuth access token to deploy. > > Answer: > There is no current work planned, but documents with such > implementation advice might also be considered during the rechartering > discussion. > > • For bearer tokens: clarification whether the non-support of percent > encoding for scope-v element of WWW-Authenticate Response Header Field > grammar is intentional. > > Answer: > In the bearer token document (Section 2.4 of > draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header > Field"), the "scope-v" element is unambiguously defined to allow a > specific set of characters. That set of characters does permit, but > does not mandate, support for percent-encoding of characters. > > ----------------------------------------------------------------- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Aug 17 14:59:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FAA21F8A4E for ; Wed, 17 Aug 2011 14:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScsK77OtkRDe for ; Wed, 17 Aug 2011 14:59:36 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id F2D1A21F8A36 for ; Wed, 17 Aug 2011 14:59:35 -0700 (PDT) Received: (qmail 26170 invoked from network); 17 Aug 2011 22:00:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Aug 2011 22:00:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 17 Aug 2011 15:00:17 -0700 From: Eran Hammer-Lahav To: Justin Richer Date: Wed, 17 Aug 2011 14:59:01 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comments Thread-Index: AcxdJiAZTGGxs0AXRUexHIvvNipYFwAAI02g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFA8EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1313096811.22073.96.camel@ground> <90C41DD21FB7C64BB94121FBBC2E72345029DFA82D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1313611965.13419.112.camel@ground> In-Reply-To: <1313611965.13419.112.camel@ground> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Anganes, Amanda L" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft 20 last call comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 21:59:36 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSnVzdGluIFJpY2hlciBb bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnXQ0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxNywg MjAxMSAxOjEzIFBNDQoNCj4gPiA+IDEuMy8xLjQvMS41OiBDb25zaWRlciBzd2l0Y2hpbmcgb3Jk ZXIgdG8gQXV0aG9yaXphdGlvbiBHcmFudCwgQWNjZXNzDQo+ID4gPiBUb2tlbiwgUmVmcmVzaCBU b2tlbg0KPiA+DQo+ID4gTm90IHN1cmUuIFdoYXQgZG8gb3RoZXJzIHRoaW5rPyBJIHB1dCBhY2Nl c3MgdG9rZW4gZmlyc3QgYmVjYXVzZSBpdCBpcyBhIG1vcmUNCj4gaW1wb3J0YW50IHRlcm0gdG8g Z2V0IG91dCBvZiB0aGUgd2F5Lg0KPiANCj4gSSBhZ3JlZSB0aGF0IGFjY2VzcyB0b2tlbnMgYXJl IGEgbW9yZSBpbXBvcnRhbnQgdG9waWMgdG8gT0F1dGggb3ZlcmFsbCwgYnV0DQo+IHRoZSByZXN0 IG9mIHRoZSBkb2N1bWVudCBwcmVzZW50cyB0aGluZ3MgaW4gcHJvdG9jb2wgZmxvdyBvcmRlcjog eW91IGdldCB0aGUNCj4gYXV0aCBncmFudCwgdGhlbiB5b3UgZ2V0IHRoZSB0b2tlbnMuDQoNCk9r LiBJJ2xsIGdpdmUgaXQgYSB0cnkuDQoNCj4gPiA+IDEuNC4xOiBXZSBwcm9iYWJseSB3YW50IHRv IG1lbnRpb24gYSB1c2VyIGFnZW50IGhlcmUgaW4gdGhlIGV4cG9zdXJlDQo+ID4gPiByaXNrIGF0 IHRoZSBlbmQuIFNpbmNlIHRoYXQncyByZWFsbHkgdGhlIHByb2JsZW0gLS0gdGhlIGJyb3dzZXIN Cj4gPiA+IGNvdWxkIHN0ZWFsIHRoZSB0b2tlbiwgbm90IHRoZSBlbmQgdXNlci4NCj4gPg0KPiA+ IFByb3Bvc2VkIHRleHQ/DQo+IA0KPiAgICBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIHByb3ZpZGVz IGEgZmV3IGltcG9ydGFudCBzZWN1cml0eSBiZW5lZml0cw0KPiAgICBzdWNoIGFzIHRoZSBhYmls aXR5IHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50IGFuZCBpc3N1aW5nIHRoZSBhY2Nlc3MNCj4g ICAgdG9rZW4gZGlyZWN0bHkgdG8gdGhlIGNsaWVudCB3aXRob3V0IHBvdGVudGlhbGx5IGV4cG9z aW5nIGl0IHRvDQo+ICAgIG90aGVycywgaW5jbHVkaW5nIHRoZSByZXNvdXJjZSBvd25lciBvciBv dGhlciBhcHBsaWNhdGlvbnMgaW4gdGhlIHJlc291cmNlDQo+ICAgIG93bmVyJ3MgdXNlciBhZ2Vu dC4NCg0KSG93IGFib3V0Og0KDQogICAgICAgICAgICBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIHBy b3ZpZGVzIGEgZmV3IGltcG9ydGFudCBzZWN1cml0eSBiZW5lZml0cyBzdWNoIGFzIHRoZSBhYmls aXR5DQogICAgICAgICAgICB0byBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCwgYW5kIHRoZSB0cmFu c21pc3Npb24gb2YgdGhlIHRoZSBhY2Nlc3MgdG9rZW4gZGlyZWN0bHkgdG8NCiAgICAgICAgICAg IHRoZSBjbGllbnQgd2l0aG91dCBwYXNzaW5nIGl0IHRocm91Z2ggdGhlIHJlc291cmNlIG93bmVy J3MgdXNlci1hZ25ldCwgcG90ZW50aWFsbHkNCiAgICAgICAgICAgIGV4cG9zaW5nIGl0IHRvIG90 aGVycywgaW5jbHVkaW5nIHRoZSByZXNvdXJjZSBvd25lci4NCg0KPiA+ID4gMjogSXNuJ3QgIm1l YW5zIiBnZW5lcmFsbHkgdHJlYXRlZCBhcyBzaW5ndWxhciBpbiBpbnN0YW5jZXMgbGlrZSB0aGlz Pw0KPiA+ID4gVGh1cyAibWVhbnMgLi4uIGlzIiBpbnN0ZWFkIG9mICJtZWFucyAuLi4gYXJlIi4N Cj4gPg0KPiA+IERvbid0IGtub3cuDQo+IA0KPiBJIHRoaW5rIGl0IGlzLCB1bmxlc3Mgc29tZW9u ZSBjYW4gcHV0IGEgc3Rha2UgaW4gdG8gc2F5IHRoYXQncyB3cm9uZy4NCg0KIkl0IGlzIHBsdXJh bCB3aGVuIGl0IHJlZmVycyB0byBhIGdyb3VwIG9mIHN0cmF0ZWdpZXMgb3IgbWV0aG9kcyINCiAN Cj4gPiA+IDIuMS8yLjI6IFRoZSByZXF1aXJlbWVudHMgKDIuMikgc2hvdWxkIGdvIGZpcnN0IGlu IHNlY3Rpb24gMi4gVGhlDQo+ID4gPiBjbGllbnQgdHlwZXMgYXJlIHBhcnQgb2YgZGVjaWRpbmcg dGhlIHJlcXVpcmVtZW50cywgYW5kIHRoZSBjb25jZXB0cyBmbG93DQo+IGJldHRlciB0aGlzIHdh eS4NCj4gPg0KPiA+IFlvdSBuZWVkIHRvIGZpcnN0IGRlZmluZSBjbGllbnQgdHlwZXMgYmVmb3Jl IHlvdSBjYW4gcmVxdWlyZSBpdC4NCj4gDQo+IE5vIHlvdSBkb24ndCwgeW91IGp1c3QgbmVlZCB0 byByZWZlcmVuY2UgdGhlbS4gWW91IGFscmVhZHkgZG9uJ3QgZGVmaW5lIHRoZQ0KPiBvdGhlciBy ZXF1aXJlbWVudHMgdW50aWwgYWZ0ZXIgKHN1Y2ggYXMgdGhlIHJlZGlyZWN0aW9uIHVybHMpLiBJ IHRoaW5rIGl0IHJlYWRzDQo+IGJldHRlciB0byBoYXZlIHRoZSByZXF1aXJlbWVudHMgdXAgZnJv bnQsIHdoZW4gdGhlIGZ1bGwgbWF0dGVyIG9mIHdoYXQNCj4gdGhleSdyZSBhbGwgYWJvdXQgaW4g dGhlIGZvbGxvd2luZyBzZWN0aW9ucy4gVGhlIGNsaWVudCBBcyBpdCBpcyBub3csIHRoZXJlIGFy ZQ0KPiBib3RoIGZvcndhcmQgYW5kIGJhY2t3YXJkIHJlZmVyZW5jZXMgaW4gdGhlIHJlcXVpcmVt ZW50cyBwYXJhZ3JhcGggYW5kDQo+IGl0J3MgY29uZnVzaW5nIHRvIHJlYWQgbGlrZSB0aGF0Lg0K DQpPay4NCg0KPiA+ID4gMi40LjI6IFdhbnQgdG8gbWVudGlvbiB0aGUgTUFDIGJpbmRpbmcgYXMg YW4gZXhhbXBsZSBoZXJlPyBUaGlzDQo+ID4gPiB3b3VsZCBwYXJhbGxlbCB0aGUgT0F1dGgyIG1l dGhvZCBvZiBzaWduaW5nIHRoZSBmZXRjaCBmb3IgYSByZXF1ZXN0DQo+ID4gPiB0b2tlbiBtb3Jl IGRpcmVjdGx5Lg0KPiA+DQo+ID4gTmFoLg0KPiANCj4gTGV0IG1lIHB1dCBpdCBzdHJvbmdlcjog SSB3b3VsZCBsaWtlIHRvIHNlZSBhbiBleHBsaWNpdCByZWZlcmVuY2UgdG8gdGhlIE1BQw0KPiBi aW5kaW5nIGhlcmUgYXMgYW4gZXhhbXBsZSBvZiBhIHN0cm9uZ2VyIGF1dGggYmluZGluZywgYWxv bmcgd2l0aCBhbg0KPiBleGFtcGxlLiBPQXV0aDEgYWxsb3dlZCBmb3IgYmluZGluZyBhZ2FpbnN0 IHRoZSB0b2tlbiBlbmRwb2ludCB1c2luZyBhDQo+IGNsaWVudCBzZWNyZXQgdGhhdCB3YXMgbm90 IHBhc3NlZCBhY3Jvc3MgdGhlIHdpcmUsIGFuZCB0aGUgTUFDIHNwZWMgZ2l2ZXMNCj4gdGhhdCBj YXBhYmlsaXR5IHRvIE9BdXRoMi4gSSB3b3VsZCByZWFsbHkgbGlrZSB0byBzZWUgdGhhdC4NCj4g DQo+IEkgc2VlIG5vIHByb2JsZW0gaW4gdGhlIGNvcmUgZG9jdW1lbnQgcG9pbnRpbmcgb3V0IHRo ZSBNQUMgYW5kIEJlYXJlcg0KPiBkb2N1bWVudHMgYXMgcHJpbWUgZXhhbXBsZXMgd2hlcmUgYXBw cm9wcmlhdGUuDQoNClBvaW50aW5nIHRvIHRoZSBNQUMgc3BlY2lmaWNhdGlvbiBpbiB0aGlzIGNv bnRleHQgd2lsbCBiZSBib3RoIGNvbmZ1c2luZyBhbmQgYWdhaW5zdCB0aGUgYmFsYW5jZSB3ZSBo YXZlIHJlYWNoZWQgKHdpdGggZ3JlYXQgZWZmb3J0KSBpbiBob3cgd2UgZGlzY3VzcyBhdXRoZW50 aWNhdGlvbi4gTm8gb25lIGlzIGEgYmlnZ2VyIHN1cHBvcnRlciBvZiB0aGUgTUFDIHByb3Bvc2Fs IHRoYW4gbWUuLi4gYW5kIEkgcmF0aGVyIGF2b2lkIHRoaXMgcmVmZXJlbmNlLCBoZXJlLg0KDQpF SEwNCg0K From eran@hueniverse.com Wed Aug 17 22:58:47 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AD121F85EC for ; Wed, 17 Aug 2011 22:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YCFCB9y8lK4 for ; Wed, 17 Aug 2011 22:58:46 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id C513121F85E3 for ; Wed, 17 Aug 2011 22:58:46 -0700 (PDT) Received: (qmail 4268 invoked from network); 18 Aug 2011 05:59:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 05:59:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 17 Aug 2011 22:59:39 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , "oauth@ietf.org" Date: Wed, 17 Aug 2011 22:58:23 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: AcxZAD9oCYx+xdzVQuy705Z1zNxKpgEaydKw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 05:58:47 -0000 I've read the thread leading to this, and the proposed text and I do not un= derstand the attack. Can you provide a step-by-step scenario of how an atta= cker gains access? Also, it is unlikely that any major provider is going to require CAPCHA as = part of the authorization flow. This is especially true in the case of usin= g OAuth for login which has to be practically transparent (one click). I wo= uld hate to recommend a solution that no one is going to take seriously. I'm keeping this proposed text out until we resolve this questions. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Friday, August 12, 2011 7:56 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner > Impersonation) >=20 > Hi all, >=20 > I think the impersonation issue as raised by Niv on the list should be co= vered > by the core spec. It directly aims at the trustworthiness of the user con= sent, > which in my opinion is one of the core principles of OAuth. I therefore > suggest to add a description to section 10. >=20 > Please find below the text Niv and I prepared. In comparison to Niv's or= iginal > proposal, it covers resource owner impersonation for all client categorie= s. >=20 > regards, > Torsten. >=20 > proposed text: >=20 > 10. Resource Owner Impersonation >=20 > When a client requests access to protected resources, the authorization f= low > normally involves the resource owner's explicit response to the access > request, either granting or denying access to the protected resources. >=20 > A malicious client can exploit knowledge of the structure of this flow in= order > to gain authorization without the resource owner's consent, by transmitti= ng > the necessary requests programmatically, and simulating the flow against = the > authorization server. An suthorization server will be vulnerable to this = threat, > if it uses non-interactive authentication mechanisms or split the authori= zation > flow across multiple pages. >=20 > It is RECOMMENDED that the authorization server takes measures to ensure > that the authorization flow cannot be simulated. > Attacks performed by scripts running within a trusted user-agent can be > detected by verifying the source of the request using HTTP referrer heade= rs. > In order to prevent such an attack, the authorization server may force a = user > interaction based on non-predictable input values as part of the user con= sent > approval. >=20 > The authorization server could combine password authentication and user > consent in a single form, make use of CAPTCHAs or one-time secrets. >=20 > Alternatively, the authorization server could notify the resource owner o= f > any approval by appropriate means, e.g. text message or e-Mail. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Aug 17 23:05:24 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7731A21F8678 for ; Wed, 17 Aug 2011 23:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4uiA-5HhUyp for ; Wed, 17 Aug 2011 23:05:20 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 806B321F863E for ; Wed, 17 Aug 2011 23:05:20 -0700 (PDT) Received: (qmail 10982 invoked from network); 18 Aug 2011 06:06:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 06:06:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 17 Aug 2011 23:06:12 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , "OAuth WG (oauth@ietf.org)" Date: Wed, 17 Aug 2011 23:04:56 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZOi5rSXfDpMMhRI+ym0EhCpcebACK0AbQAIGmj2A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA961P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 06:05:24 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA961P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to hear from the other 3 authors of the proposed change about = their reasons for changing the use of 'state' from recommended to required = for CSRF prevention. It would also help moving this issue forward if the 4 = authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I be= lieve we have a tie (4:4) and therefore no consensus for making it (as of t= his point). However, we did identify issues with the section's language and= clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, he= re is an incomplete list of other requirements needed to make an effective = CSRF: * State value must not be empty (a common bug in many implementations using= simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a has= h of the session cookie, with or without salt which isn't sufficient. We us= e "cannot be generated, modified, or guessed to produce valid values" elsew= here in the document, but this is much easier to get right for access token= s and refresh tokens than CSRF tokens which are often just some algorithm o= n top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session = cookie to prevent the use of a leaked state value in multiple attacks on th= e same user session once the leak is no longer viable. In addition, this is not what "state" was originally intended for. If the w= orking group decides to mandate a CSRF parameter, it should probably be a n= ew parameter with a more appropriate name (e.g. 'csrf'). By forcing clients= to use "state" for this purpose, developers will need to use dynamic queri= es for other state information which further reduces the security of the pr= otocol (as the draft recommends not using dynamic callback query components= ). Encoding both CSRF tokens and other state information can be non-intuiti= ve or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to bette= r documenting it (though I feel the current text is already sufficient), bu= t we can't realistically expect to identify and close every possible browse= r-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF att= acks are not likely to implement it correctly with this information. Those = who understand it do not need the extra verbiage which is more confusing th= an helpful. As for the new requirements, they are insufficient to actually accomplish w= hat the authors propose without additional requirements on state local stor= age and verification to complete the flow. Also, the proposed text needs cl= arifications as noted below. From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring "state" should change = from: state OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable= the client application to determine the user-context that was active at th= e time of the request (see section 10.12). The value MUST NOT be guessable= or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. "valu= e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi= dential" mean? Confidential from what? Why specify an "encoded value"? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the resource owner resulting in a comprom= ise of either the resource server or of the client application itself. In t= he OAuth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather than th= e victim's. Depending on the nature of the client and the protected resourc= es, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "state" paramet= er to authorization and access token requests to the authorization server. = The client MUST keep the state value in a location accessible only by the c= lient or the user-agent (i.e., protected by same-origin policy), for exampl= e, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirect, th= e client application MUST confirm that returned value of "state" correspond= s to the state value of the user-agent's user session. If the end-user sess= ion represents an authenticated user-identity, the client MUST ensure that = the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term i= s defined. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA961P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to hear from the other 3 authors of the proposed= change about their reasons for changing the use of ‘state’ fro= m recommended to required for CSRF prevention. It would also help moving th= is issue forward if the 4 authors can provide answers or clarifications on = the issues raised below.

 

Assuming we can count all 4 authors are in favor = of making the change, I believe we have a tie (4:4) and therefore no consen= sus for making it (as of this point). However, we did identify issues with = the section’s language and clarity which we should address either way= .

<= o:p> 

To clarify – I am not proposing we close this issue just yet.=

&n= bsp;

EHL=

 

From:= oau= th-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Era= n Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swa= p Attack

 <= /o:p>

To demonstrate = why making state required as proposed isn’t very helpful, here is an = incomplete list of other requirements needed to make an effective CSRF:

&= nbsp;

* = State value must not be empty (a common bug in many implementations using s= imple value comparison).

 

* ‘Non-guessable’ isn’t suffici= ent as most developers will simply use a hash of the session cookie, with o= r without salt which isn’t sufficient. We use “cannot be genera= ted, modified, or guessed to produce valid values” elsewhere in the d= ocument, but this is much easier to get right for access tokens and refresh= tokens than CSRF tokens which are often just some algorithm on top of the = session cookie.

 

* State CSRF value should be short-lived or based on a s= hort-lived session cookie to prevent the use of a leaked state value in mul= tiple attacks on the same user session once the leak is no longer viable.

 

= In addition, this is not what “state” was originally intended f= or. If the working group decides to mandate a CSRF parameter, it should pro= bably be a new parameter with a more appropriate name (e.g. ‘csrfR= 17;). By forcing clients to use “state” for this purpose, devel= opers will need to use dynamic queries for other state information which fu= rther reduces the security of the protocol (as the draft recommends not usi= ng dynamic callback query components). Encoding both CSRF tokens and other = state information can be non-intuitive or complicated for some developers/p= latforms.

 

EHL

 

 

 

 

<= p class=3DMsoNormal>From: Eran Hammer-Lahav
Sent: Friday, August 1= 2, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth = Code Swap Attack

 

This is really just a flavor of CSRF attacks. I have no object= ions to better documenting it (though I feel the current text is already su= fficient), but we can't realistically expect to identify and close every po= ssible browser-based attack. A new one is invented every other week.

 

The problem with this text i= s that developers who do no understand CSRF attacks are not likely to imple= ment it correctly with this information. Those who understand it do not nee= d the extra verbiage which is more confusing than helpful.

 

As for the new requirements, they are = insufficient to actually accomplish what the authors propose without additi= onal requirements on state local storage and verification to complete the f= low. Also, the proposed text needs clarifications as noted below.

 

<= span style=3D'font-size:10.5pt;color:black'> 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 A= ug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack=

 

 

 

Recommende= d Changes to draft-ietf-oauth-v2

 <= /o:p>

I= n section 4, request options (e.g. 4.1.1) featuring "state" shoul= d change from:<= /p>

 

state

OPTIONAL. An opaque value used by the client to maintain state betw= een the request and callback. The authorization server includes this value = when redirecting the user-agent back to the client.

 

to:

 =

state

REQUIRED. An opaque value used by the client to maintain state b= etween the request and callback. The authorization server includes this val= ue when redirecting the user-agent back to the client. The encoded value SH= OULD enable the client application to determine the user-context that was a= ctive at the time of the  request (see section 10.12). The value MUST = NOT be guessable or predictable, and MUST be kept confidential.

 

 =

Making the parameter required without making its usage r= equired (I.e. "value SHOULD enable") accomplishes nothing. Also, = what does "MUST be kept confidential" mean? Confidential from wha= t? Why specify an "encoded value"?

&n= bsp;

 

Section 10.12 Cross-Site Request Forgery

&nb= sp;

Change to:

 

Cross-site request for= gery (CSRF) is a web-based attack whereby HTTP requests are transmitted fro= m the user-agent of an end-user the server trusts or has authenticated= . CSRF attacks enable the attacker to intermix the attacker's security cont= ext with that of the resource owner resulting in a compromise of eithe= r the resource server or of the client application itself. In the OAuth con= text, such attacks allow an attacker to inject their own authorization= code or access token into a client, which can result in the client using a= n access token associated with the attacker's account rather than the = victim's. Depending on the nature of the client and the protected reso= urces, this can have undesirable and damaging effects.

In order to p= revent such attacks, the client application MUST encode a non-guessable, co= nfidential end-user artifact and submit as the "state" param= eter to authorization and access token requests to the authorization server= . The client MUST keep the state value in a location accessible only b= y the client or the user-agent (i.e., protected by same-origin policy), for= example, using a DOM variable, HTTP cookie, or HTML5 client-side stor= age.

The authorization server includes the value of the "state&= quot; parameter when redirecting the user-agent back to the client. Upon&nb= sp;receiving a redirect, the client application MUST confirm that returned = value of "state" corresponds to the state value of the user-agent= 's user session. If the end-user session represents an authenticated user-i= dentity, the client MUST ensure that the user-identity has NOT changed= .

 

 

The above text uses 'user-context' and = this 'user-identity'. Neither term is defined.

<= div>

=  

EHL

<= /body>= --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA961P3PW5EX1MB01E_-- From eran@hueniverse.com Wed Aug 17 23:06:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5327221F8686 for ; Wed, 17 Aug 2011 23:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJvKt7xrIROQ for ; Wed, 17 Aug 2011 23:06:37 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id AF38C21F863E for ; Wed, 17 Aug 2011 23:06:36 -0700 (PDT) Received: (qmail 14860 invoked from network); 18 Aug 2011 06:07:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 06:07:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 17 Aug 2011 23:07:27 -0700 From: Eran Hammer-Lahav To: "Lodderstedt, Torsten" , OAuth WG Date: Wed, 17 Aug 2011 23:06:11 -0700 Thread-Topic: Authorization Code Leakage feedback (Yaron Goland) Thread-Index: AcxcoxKThYc7pGPAToaDsdhSj5islAAI/wTAAClx6dA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFA962@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956FE1275A3@QEO40072.de.t-online.corp> In-Reply-To: <63366D5A116E514AA4A9872D3C53353956FE1275A3@QEO40072.de.t-online.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA962P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 06:06:39 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA962P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think using phishing here is misleading. This is not a classic phishing a= ttack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code.= Because of the design of the protocol this requires the attacker to use an= other redirect URI than used by the legitimate client. To make this the tit= le sound bit weird to me. Why not "authorization code phishing"? regards, Torsten. Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) > 10.6. Authorization Code Leakage: Comment "I fancy myself as being > reasonably intelligent and I'm unclear what attack is actually being desc= ribed > here." Yeah... I had to go back to -16 to be reminded of the section original titl= e 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the "redirect_uri" parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA962P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think using phishing here is misleading. This is not a clas= sic phishing attack. I’m open to other suggestions.=

 

EHL

 

From: Lodderstedt, Tor= sten [mailto:t.lodderstedt@telekom.de]
Sent: Wednesday, August 1= 7, 2011 3:22 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Authorization Code Leakage feedback (Yaron Goland)<= /p>

 

Text sounds very good.

 

wrt title: this threat is about phishing another user’s authorizati= on code. Because of the design of the protocol this requires the attacker t= o use another redirect URI than used by the legitimate client. To make this= the title sound bit weird to me. Why not “authorization code phishin= g”?

 

regards,

Torsten.

 

Von: Eran Hamme= r-Lahav [mailto:eran@hueniv= erse.com]
Gesendet: Mittwoch, 17. August 2011 08:39
An= : OAuth WG
Betreff: [OAUTH-WG] Authorization Code Leakage fee= dback (Yaron Goland)

 

> 10.6. Authorization= Code Leakage: Comment “I fancy myself as being

> reasonably intelligent a= nd I’m unclear what attack is actually being described

=

> here.”=

 <= /o:p>

Yeah... I had to go back to -16 to be reminded of the sect= ion original title 'session fixation attack' to figure out what this was ab= out.

 

How about= this:

 

10.6.&n= bsp; Authorization Code Redirection URI Manipulation

<= p class=3DMsoPlainText style=3D'margin-left:35.4pt'> 

   When requesting authori= zation using the authorization code grant

 =   type, the client can specify a redirection URI via the "redirec= t_uri"

   parameter.  If an = attacker can manipulate the value of the

 &= nbsp; redirection URI, it can cause the authorization server to redirect

   the resource owner user-agent to a UR= I under the control of the

   attacker= with the authorization code.

 <= /span>

   An attacker can create an account at a legiti= mate client and initiate

   the author= ization flow.  When the attacker is sent to the

<= p class=3DMsoPlainText style=3D'margin-left:35.4pt'>   authorization server to grant access, the attacker grabs = the

   authorization URI provided by t= he legitimate client, and replaces the

 &nb= sp; client's redirection URI with a URI under the control of the=

   attacker.  The attacker then tricks the = victim into following the

   manipulat= ed link to authorize access to the legitimate client.

=

 

   Once at the authorizat= ion server, the victim is prompted with a

 =   normal, valid request on behalf of a legitimate and familiar client,=

=    and authorizes the request.  = The victim is then redirected to an

  = endpoint under the control of the attacker with the authorization

   code.  The attacker completes the auth= orization flow by sending

   the autho= rization code to the client using the original redirection

   URI provided by the client.  The client exchan= ges the authorization

   code with an = access token and links it to the attacker's client

  account which can now gain access to the protected resources=

=    authorized by the victim (via the = client).

 

 = ;  In order to prevent such an attack, the authorization server MUST

   ensure that the redirection URI used= to obtain the authorization

   code, = is the same as the redirection URI provided when exchanging the<= /span>

   authorization code for an access token. = The authorization server

   SHOULD re= quire the client to register their redirection URI and if=

   provided, MUST validate the redirection URI received= in the

   authorization request again= st the registered value.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA962P3PW5EX1MB01E_-- From phil.hunt@oracle.com Wed Aug 17 23:40:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D91021F8531 for ; Wed, 17 Aug 2011 23:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4kBXQjSjowq for ; Wed, 17 Aug 2011 23:40:26 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8940821F8515 for ; Wed, 17 Aug 2011 23:40:26 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7I6fFws028676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 06:41:17 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7I6fEdn013870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Aug 2011 06:41:14 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7I6f8YM009600; Thu, 18 Aug 2011 01:41:08 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Aug 2011 23:41:07 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9-335017320 From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 17 Aug 2011 23:41:06 -0700 Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4E4CB40E.0013:SCFMA922111,ss=1,re=-10.500,fgs=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 06:40:28 -0000 --Apple-Mail-9-335017320 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I felt the argument provided was persuasive and that the current spec = leaves implementers open to attack. I get concerned when the core spec = says "OPTIONAL" for state and then Security Considerations says = REQUIRED. The inconsistency seemed to be a flaw in draft 20. As to your comment about a tie vote, all that shows is a lack of = consensus. Clearly we need to keep working on some more proposals. I think it is reasonable to determine whether MUST is appropriate in all = cases. I agree with what you said earlier, we should have more specific = language other then "of sufficient complexity" to describe the value of = the state parameter.=20 I saw a proposal by William Mills that I would like to see more = discussion on. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-17, at 11:04 PM, Eran Hammer-Lahav wrote: > I would like to hear from the other 3 authors of the proposed change = about their reasons for changing the use of =91state=92 from recommended = to required for CSRF prevention. It would also help moving this issue = forward if the 4 authors can provide answers or clarifications on the = issues raised below. > =20 > Assuming we can count all 4 authors are in favor of making the change, = I believe we have a tie (4:4) and therefore no consensus for making it = (as of this point). However, we did identify issues with the section=92s = language and clarity which we should address either way. > =20 > To clarify =96 I am not proposing we close this issue just yet. > =20 > EHL > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer-Lahav > Sent: Monday, August 15, 2011 9:35 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > =20 > To demonstrate why making state required as proposed isn=92t very = helpful, here is an incomplete list of other requirements needed to make = an effective CSRF: > =20 > * State value must not be empty (a common bug in many implementations = using simple value comparison). > =20 > * =91Non-guessable=92 isn=92t sufficient as most developers will = simply use a hash of the session cookie, with or without salt which = isn=92t sufficient. We use =93cannot be generated, modified, or guessed = to produce valid values=94 elsewhere in the document, but this is much = easier to get right for access tokens and refresh tokens than CSRF = tokens which are often just some algorithm on top of the session cookie. > =20 > * State CSRF value should be short-lived or based on a short-lived = session cookie to prevent the use of a leaked state value in multiple = attacks on the same user session once the leak is no longer viable. > =20 > In addition, this is not what =93state=94 was originally intended for. = If the working group decides to mandate a CSRF parameter, it should = probably be a new parameter with a more appropriate name (e.g. =91csrf=92)= . By forcing clients to use =93state=94 for this purpose, developers = will need to use dynamic queries for other state information which = further reduces the security of the protocol (as the draft recommends = not using dynamic callback query components). Encoding both CSRF tokens = and other state information can be non-intuitive or complicated for some = developers/platforms. > =20 > EHL > =20 > =20 > =20 > =20 > From: Eran Hammer-Lahav=20 > Sent: Friday, August 12, 2011 2:53 PM > To: Anthony Nadalin; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > =20 > This is really just a flavor of CSRF attacks. I have no objections to = better documenting it (though I feel the current text is already = sufficient), but we can't realistically expect to identify and close = every possible browser-based attack. A new one is invented every other = week. > =20 > The problem with this text is that developers who do no understand = CSRF attacks are not likely to implement it correctly with this = information. Those who understand it do not need the extra verbiage = which is more confusing than helpful. > =20 > As for the new requirements, they are insufficient to actually = accomplish what the authors propose without additional requirements on = state local storage and verification to complete the flow. Also, the = proposed text needs clarifications as noted below. > =20 > =20 > From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 > To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack > =20 > =20 > =20 > Recommended Changes to draft-ietf-oauth-v2 > =20 > In section 4, request options (e.g. 4.1.1) featuring "state" should = change from: > =20 > state > OPTIONAL. An opaque value used by the client to maintain state between = the request and callback. The authorization server includes this value = when redirecting the user-agent back to the client. > =20 > to: > =20 > state > REQUIRED. An opaque value used by the client to maintain state between = the request and callback. The authorization server includes this value = when redirecting the user-agent back to the client. The encoded value = SHOULD enable the client application to determine the user-context that = was active at the time of the request (see section 10.12). The value = MUST NOT be guessable or predictable, and MUST be kept confidential. > =20 > =20 > Making the parameter required without making its usage required (I.e. = "value SHOULD enable") accomplishes nothing. Also, what does "MUST be = kept confidential" mean? Confidential from what? Why specify an "encoded = value"? > =20 > =20 > Section 10.12 Cross-Site Request Forgery > =20 > Change to: > =20 > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP = requests are transmitted from the user-agent of an end-user the server = trusts or has authenticated. CSRF attacks enable the attacker to = intermix the attacker's security context with that of the resource owner = resulting in a compromise of either the resource server or of the client = application itself. In the OAuth context, such attacks allow an attacker = to inject their own authorization code or access token into a client, = which can result in the client using an access token associated with the = attacker's account rather than the victim's. Depending on the nature of = the client and the protected resources, this can have undesirable and = damaging effects. >=20 > In order to prevent such attacks, the client application MUST encode a = non-guessable, confidential end-user artifact and submit as the "state" = parameter to authorization and access token requests to the = authorization server. The client MUST keep the state value in a location = accessible only by the client or the user-agent (i.e., protected by = same-origin policy), for example, using a DOM variable, HTTP cookie, or = HTML5 client-side storage. >=20 > The authorization server includes the value of the "state" parameter = when redirecting the user-agent back to the client. Upon receiving a = redirect, the client application MUST confirm that returned value of = "state" corresponds to the state value of the user-agent's user session. = If the end-user session represents an authenticated user-identity, the = client MUST ensure that the user-identity has NOT changed. > =20 > =20 > The above text uses 'user-context' and this 'user-identity'. Neither = term is defined. > =20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-9-335017320 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = felt the argument provided was persuasive and that the current spec = leaves implementers open to attack. I get concerned when the core spec = says "OPTIONAL" for state and then Security Considerations says = REQUIRED. The inconsistency seemed to be a flaw in draft = 20.

As to your comment about a tie vote, all that = shows is a lack of consensus. Clearly we need to keep working on some = more proposals.

I think it is reasonable to = determine whether MUST is appropriate in all cases. I agree with what = you said earlier, we should have more specific language other then "of = sufficient complexity" to describe the value of the state = parameter. 

I saw a proposal by William = Mills that I would like to see more discussion on.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-08-17, at 11:04 PM, Eran Hammer-Lahav = wrote:

I would like to hear from the other 3 authors of the = proposed change about their reasons for changing the use of =91state=92 = from recommended to required for CSRF prevention. It would also help = moving this issue forward if the 4 authors can provide answers or = clarifications on the issues raised below.
Assuming we can count all 4 authors are in favor of making = the change, I believe we have a tie (4:4) and therefore no consensus for = making it (as of this point). However, we did identify issues with the = section=92s language and clarity which we should address either = way.
 
To clarify =96 I am not proposing we close this issue just = yet.
 
EHL
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] On Behalf = Of Eran = Hammer-Lahav
Sent: Monday, August 15, 2011 = 9:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code = Swap Attack
To demonstrate why making state required as proposed isn=92t = very helpful, here is an incomplete list of other requirements needed to = make an effective CSRF:
 
* State value = must not be empty (a common bug in many implementations using simple = value comparison).
 
* =91Non-guessable=92 isn=92t sufficient as most developers = will simply use a hash of the session cookie, with or without salt which = isn=92t sufficient. We use =93cannot be generated, modified, or guessed = to produce valid values=94 elsewhere in the document, but this is much = easier to get right for access tokens and refresh tokens than CSRF = tokens which are often just some algorithm on top of the session = cookie.
 
* State CSRF value should be short-lived or based on a = short-lived session cookie to prevent the use of a leaked state value in = multiple attacks on the same user session once the leak is no longer = viable.
 
In addition, this is not what =93state=94 was originally = intended for. If the working group decides to mandate a CSRF parameter, = it should probably be a new parameter with a more appropriate name (e.g. = =91csrf=92). By forcing clients to use =93state=94 for this purpose, = developers will need to use dynamic queries for other state information = which further reduces the security of the protocol (as the draft = recommends not using dynamic callback query components). Encoding both = CSRF tokens and other state information can be non-intuitive or = complicated for some developers/platforms.
EHL
 
 
 
 
Section 10.12 Cross-Site Request = Forgery 
Change to:
Cross-site request forgery (CSRF) = is a web-based attack whereby HTTP requests are transmitted from the = user-agent of an end-user the server trusts or has authenticated. = CSRF attacks enable the attacker to intermix the attacker's security = context with that of the resource owner resulting in a compromise = of either the resource server or of the client application itself. In = the OAuth context, such attacks allow an attacker to inject their = own authorization code or access token into a client, which can result = in the client using an access token associated with the attacker's = account rather than the victim's. Depending on the nature of the client = and the protected resources, this can have undesirable and damaging = effects.

In order to prevent such attacks, the client application = MUST encode a non-guessable, confidential end-user artifact and submit = as the "state" parameter to authorization and access token requests = to the authorization server. The client MUST keep the state value = in a location accessible only by the client or the user-agent = (i.e., protected by same-origin policy), for example, using a DOM = variable, HTTP cookie, or HTML5 client-side storage.

The = authorization server includes the value of the "state" parameter when = redirecting the user-agent back to the client. Upon receiving a = redirect, the client application MUST confirm that returned value of = "state" corresponds to the state value of the user-agent's user session. = If the end-user session represents an authenticated user-identity, the = client MUST ensure that the user-identity has NOT = changed.The above text uses = 'user-context' and this 'user-identity'. Neither term is = defined.
OAuth@ietf.org
To: Eran Hammer-Lahav , OAuth WG Date: Thu, 18 Aug 2011 09:11:35 +0200 Thread-Topic: Authorization Code Leakage feedback (Yaron Goland) Thread-Index: AcxcoxKThYc7pGPAToaDsdhSj5islAAI/wTAAClx6dAAAkWyAA== Message-Id: <63366D5A116E514AA4A9872D3C533539570852FD8B@QEO40072.de.t-online.corp> References: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956FE1275A3@QEO40072.de.t-online.corp> <90C41DD21FB7C64BB94121FBBC2E72345029DFA962@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFA962@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_63366D5A116E514AA4A9872D3C533539570852FD8BQEO40072deton_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 07:10:55 -0000 --_000_63366D5A116E514AA4A9872D3C533539570852FD8BQEO40072deton_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The security document designates it as "Authorization code leakage through = counterfeit client" http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1= .7 Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 08:06 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) I think using phishing here is misleading. This is not a classic phishing a= ttack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code.= Because of the design of the protocol this requires the attacker to use an= other redirect URI than used by the legitimate client. To make this the tit= le sound bit weird to me. Why not "authorization code phishing"? regards, Torsten. Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) > 10.6. Authorization Code Leakage: Comment "I fancy myself as being > reasonably intelligent and I'm unclear what attack is actually being desc= ribed > here." Yeah... I had to go back to -16 to be reminded of the section original titl= e 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the "redirect_uri" parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL --_000_63366D5A116E514AA4A9872D3C533539570852FD8BQEO40072deton_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The security document designates it as “Auth= orization code leakage through counterfeit client”<= /p>

&nb= sp;

http://tools.ietf.org/html/draft-ietf-oauth-v2-thre= atmodel-00#section-4.4.1.7

 

 =

= Von:<= /span> Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Donn= erstag, 18. August 2011 08:06
An: Lodderstedt, Torsten; OAuth WG<= br>Betreff: RE: Authorization Code Leakage feedback (Yaron Goland)

 

I think using phishing here i= s misleading. This is not a classic phishing attack. I’m open to othe= r suggestions.

 

EHL

&n= bsp;

From: Lodderstedt, Torsten [mailto= :t.lodderstedt@telekom.de]
Sent: Wednesday, August 17, 2011 3:22= AM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Author= ization Code Leakage feedback (Yaron Goland)

 

= Text sounds very good.

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'> 

wrt title: this threat is= about phishing another user’s authorization code. Because of the des= ign of the protocol this requires the attacker to use another redirect URI = than used by the legitimate client. To make this the title sound bit weird = to me. Why not “authorization code phishing”?=

 

regards= ,

Torsten.

 

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet:<= /b> Mittwoch, 17. August 2011 08:39
An: OAuth WG
Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland)=

 

> 10.6. Authorization Code Leakage: Comment “I fan= cy myself as being

> reasonably intelligent and I̵= 7;m unclear what attack is actually being described

> = here.”

 

Yeah... I had to go back to -16 to be reminded of the section original t= itle 'session fixation attack' to figure out what this was about.

 

How about this:

 

10.6.  Authorization Code Redirection U= RI Manipulation

 

   When requesting authorization usin= g the authorization code grant

&nbs= p;  type, the client can specify a redirection URI via the "redir= ect_uri"

   paramete= r.  If an attacker can manipulate the value of the

   redirection URI, it can cause the authori= zation server to redirect

 &nb= sp; the resource owner user-agent to a URI under the control of the

   attacker with the authorizati= on code.

 

   An attacker can create an account at a le= gitimate client and initiate

 =   the authorization flow.  When the attacker is sent to the<= /o:p>

   authorization server to gra= nt access, the attacker grabs the

&= nbsp;  authorization URI provided by the legitimate client, and replac= es the

   client's redire= ction URI with a URI under the control of the

   attacker.  The attacker then tricks the victim= into following the

   ma= nipulated link to authorize access to the legitimate client.

 

&n= bsp;  Once at the authorization server, the victim is prompted with a<= o:p>

<= span lang=3DEN-US style=3D'color:black'>   normal, valid request = on behalf of a legitimate and familiar client,

   and authorizes the request.  The victim is th= en redirected to an

   en= dpoint under the control of the attacker with the authorization<= /span>

   code.  The attacker comple= tes the authorization flow by sending

   the authorization code to the client using the original red= irection

   URI provided = by the client.  The client exchanges the authorization

   code with an access token and links i= t to the attacker's client

 &n= bsp;account which can now gain access to the protected resources=

   authorized by the victim (via t= he client).

 

   In order to prevent such an attack, th= e authorization server MUST

 &= nbsp; ensure that the redirection URI used to obtain the authorization=

   code, is the same as the r= edirection URI provided when exchanging the

   authorization code for an access token.  The a= uthorization server

   SH= OULD require the client to register their redirection URI and if=

   provided, MUST validate the red= irection URI received in the

 =   authorization request against the registered value.

 

EHL<= o:p>

= --_000_63366D5A116E514AA4A9872D3C533539570852FD8BQEO40072deton_-- From eran@hueniverse.com Thu Aug 18 00:16:02 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B5311E8084 for ; Thu, 18 Aug 2011 00:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1I4-Fhb35T3 for ; Thu, 18 Aug 2011 00:15:43 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7937721F84CE for ; Thu, 18 Aug 2011 00:15:40 -0700 (PDT) Received: (qmail 19279 invoked from network); 18 Aug 2011 07:16:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 07:16:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 18 Aug 2011 00:16:31 -0700 From: Eran Hammer-Lahav To: Phil Hunt Date: Thu, 18 Aug 2011 00:15:15 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxdcdaZvjxF67yXSiK2lQA5SNJGTwAAuDng Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFA964@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA964P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 07:16:02 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA964P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was no argument made. You described a CSRF attack scenario which carr= ies the exact same risk and uses the exact same solution as the CSRF attack= already present in the specification. Then jumped from there to a new norm= ative requirement. I have not seen any argument to justify the new MUST req= uirement - if I have missed it, please point me in the right direction. Also, -20 has no such inconsistencies. It is OPTIONAL in one place and RECO= MMENDED in the other. However, -20 does not *require* CSRF protection which put it at odds with h= ow we address every other attack vector, so we are in full agreement that C= SRF prevention is a MUST. My text fixes that in a manner consistent with ho= w you and the other security consideration section drafters approached many= of the other sections (by requiring a solution but not limiting developers= to a particular one). There are two open issues: - the quality of the prose (I agree that Bill's text is a good new starting= point), and - whether we should dictate to developers the parameter name (and location)= of the CSRF artifact. If we decide that we should mandate such a parameter, we then need to decid= e if 'state' is the right place and if it is, find a new way to describe it= because using it for CSRF is a relative new use case for the parameter (wh= ich still have all the previous use cases). EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Wednesday, August 17, 2011 11:41 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I felt the argument provided was persuasive and that the current spec leave= s implementers open to attack. I get concerned when the core spec says "OPT= IONAL" for state and then Security Considerations says REQUIRED. The incons= istency seemed to be a flaw in draft 20. As to your comment about a tie vote, all that shows is a lack of consensus.= Clearly we need to keep working on some more proposals. I think it is reasonable to determine whether MUST is appropriate in all ca= ses. I agree with what you said earlier, we should have more specific langu= age other then "of sufficient complexity" to describe the value of the stat= e parameter. I saw a proposal by William Mills that I would like to see more discussion = on. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-17, at 11:04 PM, Eran Hammer-Lahav wrote: I would like to hear from the other 3 authors of the proposed change about = their reasons for changing the use of 'state' from recommended to required = for CSRF prevention. It would also help moving this issue forward if the 4 = authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I be= lieve we have a tie (4:4) and therefore no consensus for making it (as of t= his point). However, we did identify issues with the section's language and= clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Eran = Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, he= re is an incomplete list of other requirements needed to make an effective = CSRF: * State value must not be empty (a common bug in many implementations using= simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a has= h of the session cookie, with or without salt which isn't sufficient. We us= e "cannot be generated, modified, or guessed to produce valid values" elsew= here in the document, but this is much easier to get right for access token= s and refresh tokens than CSRF tokens which are often just some algorithm o= n top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session = cookie to prevent the use of a leaked state value in multiple attacks on th= e same user session once the leak is no longer viable. In addition, this is not what "state" was originally intended for. If the w= orking group decides to mandate a CSRF parameter, it should probably be a n= ew parameter with a more appropriate name (e.g. 'csrf'). By forcing clients= to use "state" for this purpose, developers will need to use dynamic queri= es for other state information which further reduces the security of the pr= otocol (as the draft recommends not using dynamic callback query components= ). Encoding both CSRF tokens and other state information can be non-intuiti= ve or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to bette= r documenting it (though I feel the current text is already sufficient), bu= t we can't realistically expect to identify and close every possible browse= r-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF att= acks are not likely to implement it correctly with this information. Those = who understand it do not need the extra verbiage which is more confusing th= an helpful. As for the new requirements, they are insufficient to actually accomplish w= hat the authors propose without additional requirements on state local stor= age and verification to complete the flow. Also, the proposed text needs cl= arifications as noted below. From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring "state" should change = from: state OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable= the client application to determine the user-context that was active at th= e time of the request (see section 10.12). The value MUST NOT be guessable= or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. "valu= e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi= dential" mean? Confidential from what? Why specify an "encoded value"? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the resource owner resulting in a comprom= ise of either the resource server or of the client application itself. In t= he OAuth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather than th= e victim's. Depending on the nature of the client and the protected resourc= es, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "state" paramet= er to authorization and access token requests to the authorization server. = The client MUST keep the state value in a location accessible only by the c= lient or the user-agent (i.e., protected by same-origin policy), for exampl= e, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirect, th= e client application MUST confirm that returned value of "state" correspond= s to the state value of the user-agent's user session. If the end-user sess= ion represents an authenticated user-identity, the client MUST ensure that = the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term i= s defined. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA964P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There was= no argument made. You described a CSRF attack scenario which carries the e= xact same risk and uses the exact same solution as the CSRF attack already = present in the specification. Then jumped from there to a new normative req= uirement. I have not seen any argument to justify the new MUST requirement = – if I have missed it, please point me in the right direction.

 

Also, -20 has no such inconsistencies. It is OPTION= AL in one place and RECOMMENDED in the other.

 

However, -20 does not *require* CSRF protection which put it at odd= s with how we address every other attack vector, so we are in full agreemen= t that CSRF prevention is a MUST. My text fixes that in a manner consistent= with how you and the other security consideration section drafters approac= hed many of the other sections (by requiring a solution but not limiting de= velopers to a particular one).

 

There are two = open issues:

 

- the quality of the prose (I ag= ree that Bill’s text is a good new starting point), and

 

- whether we should dictate to developers the parameter na= me (and location) of the CSRF artifact.

 

If w= e decide that we should mandate such a parameter, we then need to decide if= ‘state’ is the right place and if it is, find a new way to des= cribe it because using it for CSRF is a relative new use case for the param= eter (which still have all the previous use cases).

 

= EHL

 

 

From: Phil Hunt [mailto:phil.hunt@oracle.= com]
Sent: Wednesday, August 17, 2011 11:41 PM
To: Era= n Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: R= e: [OAUTH-WG] Auth Code Swap Attack

 

I felt the argumen= t provided was persuasive and that the current spec leaves implementers ope= n to attack. I get concerned when the core spec says "OPTIONAL" f= or state and then Security Considerations says REQUIRED. The inconsistency = seemed to be a flaw in draft 20.

 

As to your comment about= a tie vote, all that shows is a lack of consensus. Clearly we need to keep= working on some more proposals.

 

I think it is reas= onable to determine whether MUST is appropriate in all cases. I agree with = what you said earlier, we should have more specific language other then &qu= ot;of sufficient complexity" to describe the value of the state parame= ter. 

 <= /p>

I saw a proposal by William Mills that I= would like to see more discussion on.

 

Phil

 

@= independentid

www.independentid.com=

phil.hunt@oracle= .com

 =



 

On 2011-08-17, at 11:04 PM, Eran Hammer-Lahav wrote:



I would like to hear from the other 3 authors of the propose= d change about their reasons for changing the use of ‘state’ fr= om recommended to required for CSRF prevention. It would also help moving t= his issue forward if the 4 authors can provide answers or clarifications on= the issues raised below.

 

Assuming we can count all 4 authors are in favor of making the change, I= believe we have a tie (4:4) and therefore no consensus for making it (as o= f this point). However, we did identify issues with the section’s lan= guage and clarity which we should address either way.

=

 

To clarify – I am not proposing we clo= se this issue just yet.

 

EHL

 

= From: oauth-bounces@ietf.org [= mailto:oauth-bounces@ietf.org] = ;On Behalf Of Eran Hammer-Lahav
Sent: = ;Monday, August 15, 2011 9:35 AM
To: OAuth WG (oaut= h@ietf.org)
Subject: = ;Re: [OAUTH-WG] Auth Code Swap Attack

 

To demonstrate why making state required as proposed is= n’t very helpful, here is an incomplete list of other requirements ne= eded to make an effective CSRF:

 

* State value must not be empty (a common bug in many implementati= ons using simple value comparison).

 

* ‘Non-guessable’ isn’t sufficient as most d= evelopers will simply use a hash of the session cookie, with or without sal= t which isn’t sufficient. We use “cannot be generated, modified= , or guessed to produce valid values” elsewhere in the document, but = this is much easier to get right for access tokens and refresh tokens than = CSRF tokens which are often just some algorithm on top of the session cooki= e.

 <= /o:p>

* State CSRF value s= hould be short-lived or based on a short-lived session cookie to prevent th= e use of a leaked state value in multiple attacks on the same user session = once the leak is no longer viable.

 

In addition, this is not what “state” was originall= y intended for. If the working group decides to mandate a CSRF parameter, i= t should probably be a new parameter with a more appropriate name (e.g. = 216;csrf’). By forcing clients to use “state” for this pu= rpose, developers will need to use dynamic queries for other state informat= ion which further reduces the security of the protocol (as the draft recomm= ends not using dynamic callback query components). Encoding both CSRF token= s and other state information can be non-intuitive or complicated for some = developers/platforms.

=  

E= HL

 <= /o:p>

 

 

=

 

From: Eran Hammer-Lahav 
Sent:&n= bsp;Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack=

 

This is really just a flavor of = CSRF attacks. I have no objections to better documenting it (though I feel = the current text is already sufficient), but we can't realistically expect = to identify and close every possible browser-based attack. A new one is inv= ented every other week.

 

The problem with this text is that developers who do no = understand CSRF attacks are not likely to implement it correctly with this = information. Those who understand it do not need the extra verbiage which i= s more confusing than helpful.

<= p class=3DMsoNormal> 

=

As for the new requirements, they are insufficien= t to actually accomplish what the authors propose without additional requir= ements on state local storage and verification to complete the flow. Also, = the proposed text needs clarifications as noted below.

 =

 

From: <= /span>Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack=

 

 

 

Recommended Changes to draft-ietf-oauth-v2

 

In section 4, request opt= ions (e.g. 4.1.1) featuring "state" should change from:

 

<= div>

state

OPTIONAL. An = opaque value used by the client to maintain state between the request and c= allback. The authorization server includes this value when redirecting the = user-agent back to the client.

&n= bsp;

to:

&n= bsp;

state

<= /div>

REQUIRED. An opaque value used by the client to maintai= n state between the request and callback. The authorization server includes= this value when redirecting the user-agent back to the client. The encoded= value SHOULD enable the client application to determine the user-context t= hat was active at the time of the  request (see section 10.12). The va= lue MUST NOT be guessable or predictable, and MUST be kept confidential.

 

<= /div>

 

Making the par= ameter required without making its usage required (I.e. "value SHOULD = enable") accomplishes nothing. Also, what does "MUST be kept conf= idential" mean? Confidential from what? Why specify an "encoded v= alue"?

 

 

Secti= on 10.12 Cross-Site Request Forgery

=

 

Change to:

 

Cross-sit= e request forgery (CSRF) is a web-based attack whereby HTTP requests are tr= ansmitted from the user-agent of an end-user the server trusts or has = authenticated. CSRF attacks enable the attacker to intermix the attacker's = security context with that of the resource owner resulting in a compro= mise of either the resource server or of the client application itself. In = the OAuth context, such attacks allow an attacker to inject their own = authorization code or access token into a client, which can result in the c= lient using an access token associated with the attacker's account rat= her than the victim's. Depending on the nature of the client and the protec= ted resources, this can have undesirable and damaging effects.

= In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "stat= e" parameter to authorization and access token requests to the authori= zation server. The client MUST keep the state value in a location acce= ssible only by the client or the user-agent (i.e., protected by same-origin= policy), for example, using a DOM variable, HTTP cookie, or HTML5 cli= ent-side storage.

The authorization server includes the value of the= "state" parameter when redirecting the user-agent back to the cl= ient. Upon receiving a redirect, the client application MUST confirm t= hat returned value of "state" corresponds to the state value of t= he user-agent's user session. If the end-user session represents an authent= icated user-identity, the client MUST ensure that the user-identity ha= s NOT changed.

&n= bsp;

 

The above text uses 'user-context' and this 'user-identi= ty'. Neither term is defined.

 

<= p class=3DMsoNormal>EHL

<= p class=3DMsoNormal>_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA964P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Aug 18 00:17:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0F021F84E6 for ; Thu, 18 Aug 2011 00:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YViB4Mb4JAAa for ; Thu, 18 Aug 2011 00:17:05 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7457121F8561 for ; Thu, 18 Aug 2011 00:17:04 -0700 (PDT) Received: (qmail 20763 invoked from network); 18 Aug 2011 07:17:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 07:17:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 18 Aug 2011 00:17:55 -0700 From: Eran Hammer-Lahav To: "Lodderstedt, Torsten" , OAuth WG Date: Thu, 18 Aug 2011 00:16:39 -0700 Thread-Topic: Authorization Code Leakage feedback (Yaron Goland) Thread-Index: AcxcoxKThYc7pGPAToaDsdhSj5islAAI/wTAAClx6dAAAkWyAAAALYyA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFA965@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956FE1275A3@QEO40072.de.t-online.corp> <90C41DD21FB7C64BB94121FBBC2E72345029DFA962@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FD8B@QEO40072.de.t-online.corp> In-Reply-To: <63366D5A116E514AA4A9872D3C533539570852FD8B@QEO40072.de.t-online.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA965P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 07:17:09 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA965P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But it's not really a counterfeit client but a real client with modified re= direction uri. It is a counterfeit redirection endpoint. *I* understand exa= ctly what you mean, but I fear new readers will get completely confused by = the title. EHL From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] Sent: Thursday, August 18, 2011 12:12 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) The security document designates it as "Authorization code leakage through = counterfeit client" http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1= .7 Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 08:06 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) I think using phishing here is misleading. This is not a classic phishing a= ttack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code.= Because of the design of the protocol this requires the attacker to use an= other redirect URI than used by the legitimate client. To make this the tit= le sound bit weird to me. Why not "authorization code phishing"? regards, Torsten. Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) > 10.6. Authorization Code Leakage: Comment "I fancy myself as being > reasonably intelligent and I'm unclear what attack is actually being desc= ribed > here." Yeah... I had to go back to -16 to be reminded of the section original titl= e 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the "redirect_uri" parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA965P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But it’s not really a counterfeit client but a real cli= ent with modified redirection uri. It is a counterfeit redirection endpoint= . *I* understand exactly what you mean, but I fear new readers will = get completely confused by the title.

 

EHL

 

=

From: Lodderstedt, Torsten [mailto:t.lodde= rstedt@telekom.de]
Sent: Thursday, August 18, 2011 12:12 AM
<= b>To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Authorization = Code Leakage feedback (Yaron Goland)

 

The security document designates it as “Authorization co= de leakage through counterfeit client”

 

http://tools.= ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7

&nbs= p;

=  

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet:= Donnerstag, 18. August 2011 08:06
An: Lodderstedt, Torsten; = OAuth WG
Betreff: RE: Authorization Code Leakage feedback (Yaron = Goland)

 

I think us= ing phishing here is misleading. This is not a classic phishing attack. I&#= 8217;m open to other suggestions.

 

EHL

 

From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de]
Sent: Wednesday, August 1= 7, 2011 3:22 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Authorization Code Leakage feedback (Yaron Goland)<= /p>

 = ;

Text sounds very good.

 

wrt title: this threat is about = phishing another user’s authorization code. Because of the design of = the protocol this requires the attacker to use another redirect URI than us= ed by the legitimate client. To make this the title sound bit weird to me. = Why not “authorization code phishing”?

 

regards,

Tor= sten.

 

<= p class=3DMsoNormal style=3D'margin-left:70.8pt'>Von: E= ran Hammer-Lahav [mailto:er= an@hueniverse.com]
Gesendet: Mittwoch, 17. August 2011 08:39=
An: OAuth WG
Betreff: [OAUTH-WG] Authorization Code Le= akage feedback (Yaron Goland)

 

> 10.6. Auth= orization Code Leakage: Comment “I fancy myself as being

> reasonably inte= lligent and I’m unclear what attack is actually being described<= /o:p>

> here.= 221;

 

Yeah... I had to go back to -16 to be reminded of t= he section original title 'session fixation attack' to figure out what this= was about.

 

Ho= w about this:

 

= 10.6.  Authorization Code Redirection URI Manipulation

 

   When requesting = authorization using the authorization code grant

   type, the client can specify a redirection URI via the "= redirect_uri"

   parameter. = If an attacker can manipulate the value of the

=    redirection URI, it can cause the authorization server to redi= rect

   the resource owner user-agent = to a URI under the control of the

   a= ttacker with the authorization code.

 =

   An attacker can create an account at a = legitimate client and initiate

   the = authorization flow.  When the attacker is sent to the

   authorization server to grant access, the attacker = grabs the

   authorization URI provide= d by the legitimate client, and replaces the

&n= bsp;  client's redirection URI with a URI under the control of the

   attacker.  The attacker then tric= ks the victim into following the

   ma= nipulated link to authorize access to the legitimate client.

 

   Once at the aut= horization server, the victim is prompted with a

   normal, valid request on behalf of a legitimate and familiar = client,

   and authorizes the request.=   The victim is then redirected to an

 = ;  endpoint under the control of the attacker with the authorization

   code.  The attacker completes t= he authorization flow by sending

   th= e authorization code to the client using the original redirection

   URI provided by the client.  The client= exchanges the authorization

   code w= ith an access token and links it to the attacker's client=

  account which can now gain access to the protected re= sources

   authorized by the victim (v= ia the client).

 

   In order to prevent such an attack, the authorization server= MUST

   ensure that the redirection U= RI used to obtain the authorization

  = code, is the same as the redirection URI provided when exchanging the=

   authorization code for an access token.=   The authorization server

   SHO= ULD require the client to register their redirection URI and if<= /span>

   provided, MUST validate the redirection URI r= eceived in the

   authorization reques= t against the registered value.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFA965P3PW5EX1MB01E_-- From t.lodderstedt@telekom.de Thu Aug 18 00:21:55 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF455E8002 for ; Thu, 18 Aug 2011 00:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.768 X-Spam-Level: X-Spam-Status: No, score=-2.768 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fkDlin69Fxt for ; Thu, 18 Aug 2011 00:21:52 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 88CCD5E8007 for ; Thu, 18 Aug 2011 00:21:48 -0700 (PDT) Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail31.telekom.de with ESMTP; 18 Aug 2011 09:22:37 +0200 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by g8pxd.blf01.telekom.de with ESMTP; Thu, 18 Aug 2011 09:22:37 +0200 Received: from QEO40072.de.t-online.corp ([169.254.1.155]) by QEO40065.de.t-online.corp ([10.224.209.65]) with mapi; Thu, 18 Aug 2011 09:22:37 +0200 From: "Lodderstedt, Torsten" To: Eran Hammer-Lahav , OAuth WG Date: Thu, 18 Aug 2011 09:22:36 +0200 Thread-Topic: Authorization Code Leakage feedback (Yaron Goland) Thread-Index: AcxcoxKThYc7pGPAToaDsdhSj5islAAI/wTAAClx6dAAAkWyAAAALYyAAAAgG0A= Message-Id: <63366D5A116E514AA4A9872D3C533539570852FDA3@QEO40072.de.t-online.corp> References: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C53353956FE1275A3@QEO40072.de.t-online.corp> <90C41DD21FB7C64BB94121FBBC2E72345029DFA962@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FD8B@QEO40072.de.t-online.corp> <90C41DD21FB7C64BB94121FBBC2E72345029DFA965@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFA965@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_63366D5A116E514AA4A9872D3C533539570852FDA3QEO40072deton_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 07:21:55 -0000 --_000_63366D5A116E514AA4A9872D3C533539570852FDA3QEO40072deton_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In my opinion, the counterfeit redirection endpoint is another client - the= counterfeit client. The attacker must trick the victim into accessing this= client and approving the authorization request. So I would assume the atta= cker would try to let his endpoint look like the real client. Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 09:17 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) But it's not really a counterfeit client but a real client with modified re= direction uri. It is a counterfeit redirection endpoint. *I* understand exa= ctly what you mean, but I fear new readers will get completely confused by = the title. EHL From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] Sent: Thursday, August 18, 2011 12:12 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) The security document designates it as "Authorization code leakage through = counterfeit client" http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1= .7 Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Gesendet: Donnerstag, 18. August 2011 08:06 An: Lodderstedt, Torsten; OAuth WG Betreff: RE: Authorization Code Leakage feedback (Yaron Goland) I think using phishing here is misleading. This is not a classic phishing a= ttack. I'm open to other suggestions. EHL From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM To: Eran Hammer-Lahav; OAuth WG Subject: AW: Authorization Code Leakage feedback (Yaron Goland) Text sounds very good. wrt title: this threat is about phishing another user's authorization code.= Because of the design of the protocol this requires the attacker to use an= other redirect URI than used by the legitimate client. To make this the tit= le sound bit weird to me. Why not "authorization code phishing"? regards, Torsten. Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Gesendet: Mittwoch, 17. August 2011 08:39 An: OAuth WG Betreff: [OAUTH-WG] Authorization Code Leakage feedback (Yaron Goland) > 10.6. Authorization Code Leakage: Comment "I fancy myself as being > reasonably intelligent and I'm unclear what attack is actually being desc= ribed > here." Yeah... I had to go back to -16 to be reminded of the section original titl= e 'session fixation attack' to figure out what this was about. How about this: 10.6. Authorization Code Redirection URI Manipulation When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the "redirect_uri" parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code. An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client, and replaces the client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client. Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and familiar client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account which can now gain access to the protected resources authorized by the victim (via the client). In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code, is the same as the redirection URI provided when exchanging the authorization code for an access token. The authorization server SHOULD require the client to register their redirection URI and if provided, MUST validate the redirection URI received in the authorization request against the registered value. EHL --_000_63366D5A116E514AA4A9872D3C533539570852FDA3QEO40072deton_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In my opinion, the counterfeit redirection endpoin= t is another client – the counterfeit client. The attacker must trick= the victim into accessing this client and approving the authorization requ= est. So I would assume the attacker would try to let his endpoint look like= the real client.

 

Von: Eran Hammer-Lahav [mailto:e= ran@hueniverse.com]
Gesendet: Donnerstag, 18. August 2011 09:17<= br>An: Lodderstedt, Torsten; OAuth WG
Betreff: RE: Authori= zation Code Leakage feedback (Yaron Goland)

 

But it’s not really a counterfeit client but a real c= lient with modified redirection uri. It is a counterfeit redirection endpoi= nt. *I* understand exactly what you mean, but I fear new readers wil= l get completely confused by the title.

 

EHL

=

 

From: Lo= dderstedt, Torsten [mailto:t.lodderstedt@telekom.de]
Sent: Thurs= day, August 18, 2011 12:12 AM
To: Eran Hammer-Lahav; OAuth WG
= Subject: AW: Authorization Code Leakage feedback (Yaron Goland)=

 

The se= curity document designates it as “Authorization code leakage through = counterfeit client”

&nb= sp;

http://tools.ietf.org/= html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7

 

=  

Von: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Gesendet: Donnerstag, 18.= August 2011 08:06
An: Lodderstedt, Torsten; OAuth WG
Betre= ff: RE: Authorization Code Leakage feedback (Yaron Goland)

 

I think using phishing here is misleadin= g. This is not a classic phishing attack. I’m open to other suggestio= ns.

=  

EHL

 <= /span>

From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] Sent: Wednesday, August 17, 2011 3:22 AM
To: Eran Hammer= -Lahav; OAuth WG
Subject: AW: Authorization Code Leakage feedback= (Yaron Goland)

 

Text sounds very good.

 <= /p>

wrt title: this threat is about phishing another user&= #8217;s authorization code. Because of the design of the protocol this requ= ires the attacker to use another redirect URI than used by the legitimate c= lient. To make this the title sound bit weird to me. Why not “authori= zation code phishing”?

&n= bsp;

regards,

Torsten.

 

Vo= n: Eran Hammer-Lahav [ma= ilto:eran@hueniverse.com]
Gesendet: Mittwoch, 17. August 201= 1 08:39
An: OAuth WG
Betreff: [OAUTH-WG] Authorization = Code Leakage feedback (Yaron Goland)

 

> 10.6.= Authorization Code Leakage: Comment “I fancy myself as being

> reasonably intelligent and I’m unclear what attack i= s actually being described

> here.”<= /span>

 

Yeah... I had to g= o back to -16 to be reminded of the section original title 'session fixatio= n attack' to figure out what this was about.

 

How about this:=

 

10.6.  Authorization Code Redirection URI Manipulatio= n

 

   When requesting authorization using the autho= rization code grant

   t= ype, the client can specify a redirection URI via the "redirect_uri&qu= ot;

   parameter.  = If an attacker can manipulate the value of the

   redirection URI, it can cause the authorization s= erver to redirect

   the= resource owner user-agent to a URI under the control of the

   attacker with the authorization cod= e.

 

   An attacker can create an account at a legiti= mate client and initiate

 &nb= sp; the authorization flow.  When the attacker is sent to the

   authorization server to grant= access, the attacker grabs the

&n= bsp;  authorization URI provided by the legitimate client, and replace= s the

   client's redire= ction URI with a URI under the control of the

   attacker.  The attacker then tricks the victi= m into following the

   = manipulated link to authorize access to the legitimate client.

 

   Once at the authorization server, the victim is prompted w= ith a

   normal, valid r= equest on behalf of a legitimate and familiar client,

=

   and authorizes the request.  The vict= im is then redirected to an

 =   endpoint under the control of the attacker with the authorization

   code.  The attacke= r completes the authorization flow by sending

   the authorization code to the client using the ori= ginal redirection

   URI= provided by the client.  The client exchanges the authorization<= /o:p>

   code with an access token = and links it to the attacker's client

  account which can now gain access to the protected resource= s

   authorized by the v= ictim (via the client).

&nbs= p;

   In order to prevent suc= h an attack, the authorization server MUST

   ensure that the redirection URI used to obtain the au= thorization

   code, is = the same as the redirection URI provided when exchanging the

   authorization code for an access to= ken.  The authorization server

   SHOULD require the client to register their redirection URI = and if

   provided, MUST= validate the redirection URI received in the

   authorization request against the registered value= .

 

EHL

= --_000_63366D5A116E514AA4A9872D3C533539570852FDA3QEO40072deton_-- From t.lodderstedt@telekom.de Thu Aug 18 00:23:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618EC5E800C for ; Thu, 18 Aug 2011 00:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XpQngyGP+ob for ; Thu, 18 Aug 2011 00:23:37 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2E35E8002 for ; Thu, 18 Aug 2011 00:23:37 -0700 (PDT) Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail31.telekom.de with ESMTP; 18 Aug 2011 09:24:26 +0200 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by g8pxd.blf01.telekom.de with ESMTP; Thu, 18 Aug 2011 09:24:26 +0200 Received: from QEO40072.de.t-online.corp ([169.254.1.155]) by QEO40065.de.t-online.corp ([10.224.209.65]) with mapi; Thu, 18 Aug 2011 09:24:25 +0200 From: "Lodderstedt, Torsten" To: Eran Hammer-Lahav , Justin Richer , "OAuth WG (oauth@ietf.org)" Date: Thu, 18 Aug 2011 09:24:25 +0200 Thread-Topic: [OAUTH-WG] Draft 20 last call comments Thread-Index: AcxYcNP9BMbO/ni8T3yA7gll5itVuwEgmb+AACDH8JA= Message-Id: <63366D5A116E514AA4A9872D3C533539570852FDA5@QEO40072.de.t-online.corp> References: <1313096811.22073.96.camel@ground> <90C41DD21FB7C64BB94121FBBC2E72345029DFA82D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFA82D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Anganes, Amanda L" Subject: Re: [OAUTH-WG] Draft 20 last call comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 07:23:39 -0000 >> 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Tok= en, >> Refresh Token >Not sure. What do others think? I put access token first because it is a m= ore important term to get out of the >way. I would rather consider to change order to Access Token, Refresh Token, Aut= horization Grant since the first two are the core OAuth concepts developers= must become familiar with. Authorization grants are "just" an mean to an e= nd to get the token for certain client types. Moreover, I expect the number= of authorization grants to increase over time. >> 2.3: Should "... cannot be used alone" be made into a normative, as "... >> MUST NOT be used alone"? >I'm ok with that. Anyone else? +1 regards, Torsten. From t.lodderstedt@telekom.de Thu Aug 18 00:25:57 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD85F21F8570 for ; Thu, 18 Aug 2011 00:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC6nONVNh9IQ for ; Thu, 18 Aug 2011 00:25:57 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 72FAD21F856D for ; Thu, 18 Aug 2011 00:25:56 -0700 (PDT) Received: from g8pxb.blf01.telekom.de ([164.25.63.141]) by tcmail81.telekom.de with ESMTP; 18 Aug 2011 09:26:49 +0200 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by g8pxd.blf01.telekom.de with ESMTP; Thu, 18 Aug 2011 09:26:47 +0200 Received: from QEO40072.de.t-online.corp ([169.254.1.155]) by QEO40065.de.t-online.corp ([10.224.209.65]) with mapi; Thu, 18 Aug 2011 09:26:45 +0200 From: "Lodderstedt, Torsten" To: Barry Leiba , "oauth@ietf.org" Date: Thu, 18 Aug 2011 09:26:45 +0200 Thread-Topic: [OAUTH-WG] OMA Liaison Has Arrived! Thread-Index: AcxdHSdP3Zz0R2gwRUmmMa3trNVKMwAWwXAg Message-Id: <63366D5A116E514AA4A9872D3C533539570852FDA8@QEO40072.de.t-online.corp> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 07:25:57 -0000 +1 -----Urspr=FCngliche Nachricht----- Von: Barry Leiba [mailto:barryleiba@computer.org]=20 Gesendet: Mittwoch, 17. August 2011 22:35 An: oauth@ietf.org Betreff: Re: [OAUTH-WG] OMA Liaison Has Arrived! I'm sorry for the delay in getting this written. Because of the delay, the working group has just a short time to review my proposed response, below. Everyone, please have a look at the answers I propose to send, and post any objections to this thread by the end of the day on Monday, 22 August. Hannes, please also check with the IAB in parallel, and make sure we can send this via Murray as soon as we've resolved any WG objections. Barry, as chair ----------------------------------------------------------------- The IETF OAuth working group thanks OMA ARC SEC for the liaison statement titled "OAuth discovery and specification availability", dated 18 July 2011. The OMA liaison statement asks the OAuth working group to address five issues, and our answers are as follows: . Availability of the IETF OAuth specifications: especially [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also [draft-hammer-oauth-v2-mac-token], [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. Answer: The IETF cannot guarantee publication dates, but we can give some best-guess timeframes. As this writing, draft-ietf-oauth-v2 and draft-ietf-oauth-v2-bearer have completed Working Group last call and are undergoing their final revisions before being sent to the IESG. We expect the final versions of those documents to be in the RFC Editor queue around the end of September, though it could be later if issues come up in IETF-wide last call or during IESG evaluation. The draft-hammer-oauth-v2-mac-token document has been replaced by draft-ietf-oauth-v2-http-mac, which is a working group document. It is likely to be in the RFC Editor queue by the end of the year. The remaining two documents are not working group documents, and the working group can say nothing about their status. The OAuth working group intends to revise its charter in the November timeframe, and it's possible that one or both of those documents could be adopted by the working group at that time, and we could have further information about target publication dates then. . Availability of the OAuth Parameters Registry Answer: The draft-ietf-oauth-v2 document establishes the OAuth Parameters Registry (in section 11.2, as of draft version 20). The registry will be available when the RFC is published, which will be some time after the document goes into the RFC Editor queue, depending upon the RFC Editor's load at the time. . IETF intent to specify an OAuth Discovery mechanism Answer: There is interest among OAuth working group participants for specifying such a mechanism, but the work is not in the current charter. It will likely be considered during the aforementioned charter update in (approximately) November. . Considerations that can help implementors decide about the type of OAuth access token to deploy. Answer: There is no current work planned, but documents with such implementation advice might also be considered during the rechartering discussion. . For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. Answer: In the bearer token document (Section 2.4 of draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header Field"), the "scope-v" element is unambiguously defined to allow a specific set of characters. That set of characters does permit, but does not mandate, support for percent-encoding of characters. ----------------------------------------------------------------- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From t.lodderstedt@telekom.de Thu Aug 18 00:51:02 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5827C21F8A57 for ; Thu, 18 Aug 2011 00:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OhrT-A0QQ2C for ; Thu, 18 Aug 2011 00:51:01 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 32EEF21F874F for ; Thu, 18 Aug 2011 00:51:01 -0700 (PDT) Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail71.telekom.de with ESMTP; 18 Aug 2011 09:51:48 +0200 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by G8DBSE01.krf01.telekom.de with ESMTP; Thu, 18 Aug 2011 09:51:48 +0200 Received: from QEO40072.de.t-online.corp ([169.254.1.155]) by QEO40065.de.t-online.corp ([10.224.209.65]) with mapi; Thu, 18 Aug 2011 09:51:48 +0200 From: "Lodderstedt, Torsten" To: Eran Hammer-Lahav , Torsten Lodderstedt , "oauth@ietf.org" Date: Thu, 18 Aug 2011 09:51:45 +0200 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: AcxZAD9oCYx+xdzVQuy705Z1zNxKpgEaydKwAANDmfA= Message-Id: <63366D5A116E514AA4A9872D3C533539570852FDC0@QEO40072.de.t-online.corp> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 07:51:02 -0000 >I've read the thread leading to this, and the proposed text and I do not u= nderstand the attack. Can you >provide a step-by-step scenario of how an at= tacker gains access? I'm honestly surprised you do not understand the attack. The client simply = uses screen scraping on the authorization flow and programmatically "presse= s" the right buttons. This obviously only works if the client can predict t= he form structure and expected input values. >Also, it is unlikely that any major provider is going to require CAPCHA as= part of the authorization flow. >This is especially true in the case of us= ing OAuth for login which has to be practically transparent (one >click). I= would hate to recommend a solution that no one is going to take seriously. This text has been proposed by 2 WG members (Niv and me), and reviewed by 3= others (Phil, Tony, Barry) and all agree with it. What is the foundation o= f your strong assessment? The text proposes three classes of countermeasures (detect source, prevent = using unpredictable input, inform resource owner and give her a chance to r= evoke). CAPTCHAs are one out of three examples given for unpredictable inpu= t. So I don't understand why your objection focuses on it. The selection of= the appropriate countermeasure is the task of the service provider and it = will most likely depend this on its capabilities, cost, user experience, an= d risk/impact associated with abuse. CAPTCHAs (and even one time passwords)= might not be the choice for the average internet service. This will be com= pletely different if OAuth is used to process payment transactions. >I'm keeping this proposed text out until we resolve this questions. See above - I probably misunderstand the IETF process, but several people a= greed with it and no one (except you) objected. Why do you hold it back?=20 regards, Torsten. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Friday, August 12, 2011 7:56 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner > Impersonation) >=20 > Hi all, >=20 > I think the impersonation issue as raised by Niv on the list should be co= vered > by the core spec. It directly aims at the trustworthiness of the user con= sent, > which in my opinion is one of the core principles of OAuth. I therefore > suggest to add a description to section 10. >=20 > Please find below the text Niv and I prepared. In comparison to Niv's or= iginal > proposal, it covers resource owner impersonation for all client categorie= s. >=20 > regards, > Torsten. >=20 > proposed text: >=20 > 10. Resource Owner Impersonation >=20 > When a client requests access to protected resources, the authorization f= low > normally involves the resource owner's explicit response to the access > request, either granting or denying access to the protected resources. >=20 > A malicious client can exploit knowledge of the structure of this flow in= order > to gain authorization without the resource owner's consent, by transmitti= ng > the necessary requests programmatically, and simulating the flow against = the > authorization server. An suthorization server will be vulnerable to this = threat, > if it uses non-interactive authentication mechanisms or split the authori= zation > flow across multiple pages. >=20 > It is RECOMMENDED that the authorization server takes measures to ensure > that the authorization flow cannot be simulated. > Attacks performed by scripts running within a trusted user-agent can be > detected by verifying the source of the request using HTTP referrer heade= rs. > In order to prevent such an attack, the authorization server may force a = user > interaction based on non-predictable input values as part of the user con= sent > approval. >=20 > The authorization server could combine password authentication and user > consent in a single form, make use of CAPTCHAs or one-time secrets. >=20 > Alternatively, the authorization server could notify the resource owner o= f > any approval by appropriate means, e.g. text message or e-Mail. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From t.lodderstedt@telekom.de Thu Aug 18 01:00:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD9721F8A51 for ; Thu, 18 Aug 2011 01:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wychtYevjm52 for ; Thu, 18 Aug 2011 01:00:20 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2003C21F8A4F for ; Thu, 18 Aug 2011 01:00:19 -0700 (PDT) Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail31.telekom.de with ESMTP; 18 Aug 2011 10:01:06 +0200 Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by G8DBSE01.krf01.telekom.de with ESMTP; Thu, 18 Aug 2011 10:01:06 +0200 Received: from QEO40072.de.t-online.corp ([169.254.1.155]) by QEO40064.de.t-online.corp ([10.224.209.64]) with mapi; Thu, 18 Aug 2011 10:01:05 +0200 From: "Lodderstedt, Torsten" To: Eran Hammer-Lahav , "oauth@ietf.org" Date: Thu, 18 Aug 2011 10:01:04 +0200 Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland Thread-Index: AcxXpdCrqvPON2CRS72O2K03CR90kwDcgn2QAJkH2nA= Message-Id: <63366D5A116E514AA4A9872D3C533539570852FDCA@QEO40072.de.t-online.corp> References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 08:00:21 -0000 >> 1.4.3. Resource Owner Password Credentials: Comment on "(when >> combined with a refresh token)": "This is the first time that refresh to= kens >> are mentioned in the spec. And yet there is no explanation of what they = are. >> I suspect they should anyway be introduced in section 1.4.1 (as previous= ly >> noted) and then their use here will make sense. If that isn't possible = then it >> would be good to have a forward reference to section 1.5 below so the >> reader has some idea of what's going on." >I removed '(when combined with a refresh token)'. This is actually not tru= e as there is no assumption that >access tokens are always short-lived or t= hat refresh tokens will always be issued to native applications using >this= grant type. -1 against removing this text (w/o an suitable replacement) and w/o group c= onsent.=20 The -20 text clearly points out that this combination "... eliminates the n= eed for the client to store the resource owner credentials for future use".= The resource owner grant type alone does not justify this statement. It's true that the spec does not explicitly defines the lifetime assumption= for access and refresh tokens (which is pity in my opinion). So at least a= dd something like "if the token lifetime is reasonable long enough". regards, Torsten. From James.H.Manger@team.telstra.com Thu Aug 18 04:14:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC5321F8AD2 for ; Thu, 18 Aug 2011 04:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.134 X-Spam-Level: X-Spam-Status: No, score=-4.134 tagged_above=-999 required=5 tests=[AWL=-3.233, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhNmwW+uKB9S for ; Thu, 18 Aug 2011 04:14:30 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7355B21F8ADE for ; Thu, 18 Aug 2011 04:14:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,244,1312120800"; d="scan'208";a="42850022" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 18 Aug 2011 21:15:21 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6441"; a="34563783" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 18 Aug 2011 21:15:21 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Thu, 18 Aug 2011 21:15:20 +1000 From: "Manger, James H" To: Barry Leiba , "oauth@ietf.org" Date: Thu, 18 Aug 2011 21:15:18 +1000 Thread-Topic: [OAUTH-WG] OMA Liaison Has Arrived! scope-v Thread-Index: AcxdHRt2KDLjqfJoQaO9VydhcegKRwAVKytw Message-ID: <255B9BB34FB7D647A506DC292726F6E1128B5BB96C@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 11:14:31 -0000 >> * For bearer tokens: clarification whether the non-support of percent encoding for scope-v element of WWW-Authenticate Response Header Field grammar is intentional. > Answer: > In the bearer token document (Section 2.4 of > draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header > Field"), the "scope-v" element is unambiguously defined to allow a > specific set of characters. That set of characters does permit, but > does not mandate, support for percent-encoding of characters. This is a poor answer. A client app receiving a scope value in an "WWW-Authenticate: Bearer scope= =3D..." response will either compare it with strings from a OAuth2 JSON-enc= oded token response, or copy it into a request to an authorization server. = It needs to know if it needs to %-decode the value or not before doing thes= e things. Clients cannot be expected to behave differently for different se= rvers in this respect. OAuth2 core (implicitly) allows a scope to use any Unicode char except spac= e (as space is used as a delimiter). Bearer restricts scopes to 93 ASCII chars. OMA are asking if this is intentional. If we really want to restrict scope values it would be better done in OAuth= 2 core. If we don't want to restrict values then the bearer spec needs to be able t= o handle any possible scope value by defining an escaping mechanism for sco= pe-v (or by not having a scope parameter). -- James Manger From nivstein@gmail.com Thu Aug 18 05:48:05 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA321F8AB0 for ; Thu, 18 Aug 2011 05:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+LrFYZj7jb3 for ; Thu, 18 Aug 2011 05:48:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79F4921F8A62 for ; Thu, 18 Aug 2011 05:48:04 -0700 (PDT) Received: by vxi29 with SMTP id 29so2075768vxi.31 for ; Thu, 18 Aug 2011 05:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=EEpGRDQBn3eqzhq8A8kRsKJAoDlV/e9UfvufZQ1mW7o=; b=OCNSD22ImtGNQekQNuVLfFiXxemczU3dzFgID3jlFRXUXyZnL1GxYggJmsx+iJpYJk fJ7PAesS1kScDlPJHRXT8bwtWp9m61mD1dcyj+Id/jGIbRj21J3TtuPUiMlqDshkLQlK j+FpSrenHDWLmGeQuyfjLX3lhJkEZrcLWdG1g= Received: by 10.52.21.194 with SMTP id x2mr686722vde.389.1313671737153; Thu, 18 Aug 2011 05:48:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.170 with HTTP; Thu, 18 Aug 2011 05:48:37 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Niv Steingarten Date: Thu, 18 Aug 2011 15:48:37 +0300 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 12:48:05 -0000 Here are two very simple examples. They are very naive ones, but get the point across and I would not be suprised if they could be found in the wild: Say a client has its authorization endpoint at (1) http://www.domain.com/auth.php =09 A client requests access to protected resources by redirecting the user-agent to: (2) http://www.domain.com/auth.php?response_type=3Dcode&client_id=3D1234& redirect_uri=3DSOMEURI&scope=3DSOMESCOPE One possible design choice for the developer, if a bad one, is to have the 'Allow' button point to: (3) http://www.domain.com/auth.php?[..previous query params..]&allow=3D1 In this case, a malicious client who knows the structure of this auth flow, can simply skip (2) and redirect the user-agent to (3) in order to gain access to the protected resources. Another possible design choice for the developer (again, a very bad one) would be to issue some kind of session cookie after (2) in order to keep a state. Then, the 'Allow' button could possibly point to: (4) http://www.domain.com/allow.php without any parameters (since the state is maintained by a cookie). Here, an attacker could launch a request to (2) just to issue the state cookie, and immediately redirect the user-agent to (4) in order to gain access to the protected resources. These are two very naive scenarios which can be averted using a nonce for example (+ better design choices, for that matter). In non-user-agent based clients, a client might also be able to actually scrape the contents of the authorization HTML page, and simulate the click programmatically. In this case a nonce would be useless, but a CAPTCHA or a PIN code/password would solve the problem. -- Niv On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav wrot= e: > I've read the thread leading to this, and the proposed text and I do not = understand the attack. Can you provide a step-by-step scenario of how an at= tacker gains access? > > Also, it is unlikely that any major provider is going to require CAPCHA a= s part of the authorization flow. This is especially true in the case of us= ing OAuth for login which has to be practically transparent (one click). I = would hate to recommend a solution that no one is going to take seriously. > > I'm keeping this proposed text out until we resolve this questions. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Friday, August 12, 2011 7:56 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> >> Hi all, >> >> I think the impersonation issue as raised by Niv on the list should be c= overed >> by the core spec. It directly aims at the trustworthiness of the user co= nsent, >> which in my opinion is one of the core principles of OAuth. I therefore >> suggest to add a description to section 10. >> >> Please find below the text Niv and I prepared. In comparison to =C2=A0Ni= v's original >> proposal, it covers resource owner impersonation for all client categori= es. >> >> regards, >> Torsten. >> >> proposed text: >> >> 10. Resource Owner Impersonation >> >> When a client requests access to protected resources, the authorization = flow >> normally involves the resource owner's explicit response to the access >> request, either granting or denying access to the protected resources. >> >> A malicious client can exploit knowledge of the structure of this flow i= n order >> to gain authorization without the resource owner's consent, by transmitt= ing >> the necessary requests programmatically, and simulating the flow against= the >> authorization server. An suthorization server will be vulnerable to this= threat, >> if it uses non-interactive authentication mechanisms or split the author= ization >> flow across multiple pages. >> >> It is RECOMMENDED that the authorization server takes measures to ensure >> that the authorization flow cannot be simulated. >> Attacks performed by scripts running within a trusted user-agent can be >> detected by verifying the source of the request using HTTP referrer head= ers. >> In order to prevent such an attack, the authorization server may force a= user >> interaction based on non-predictable input values as part of the user co= nsent >> approval. >> >> The authorization server could combine password authentication and user >> consent in a single form, make use of CAPTCHAs or one-time secrets. >> >> Alternatively, the authorization server could notify the resource owner = of >> any approval by appropriate means, e.g. text message or e-Mail. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Thu Aug 18 07:28:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6904A21F8B5D for ; Thu, 18 Aug 2011 07:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm0XofSOhJFn for ; Thu, 18 Aug 2011 07:28:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CD2C421F8B5A for ; Thu, 18 Aug 2011 07:28:51 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 59B8721B0B71; Thu, 18 Aug 2011 10:29:45 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 53B0521B0AC5; Thu, 18 Aug 2011 10:29:45 -0400 (EDT) Received: from [129.83.50.1] (129.83.50.1) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.3.192.1; Thu, 18 Aug 2011 10:29:45 -0400 From: Justin Richer To: "Lodderstedt, Torsten" In-Reply-To: <63366D5A116E514AA4A9872D3C533539570852FDA5@QEO40072.de.t-online.corp> References: <1313096811.22073.96.camel@ground> <90C41DD21FB7C64BB94121FBBC2E72345029DFA82D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDA5@QEO40072.de.t-online.corp> Content-Type: text/plain; charset="UTF-8" Date: Thu, 18 Aug 2011 10:29:04 -0400 Message-ID: <1313677744.13419.119.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "Anganes, Amanda L" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft 20 last call comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:28:52 -0000 > >> 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token, > >> Refresh Token > > >Not sure. What do others think? I put access token first because it is a more important term to get out of the >way. > > I would rather consider to change order to Access Token, Refresh Token, Authorization Grant since the first two are the core OAuth concepts developers must become familiar with. Authorization grants are "just" an mean to an end to get the token for certain client types. Moreover, I expect the number of authorization grants to increase over time. You have to use *some* kind of authorization grant to get any kind of token, and this part of the OAuth spec is all about "how to get a token in a programmatic way". I agree that there will be many more types of auth grants in the future, and that's why I think it should be the first concept in the list. I can see the logic of putting both token types first (though I still prefer the auth grant first), but having the auth grant in between the two token types is definitely a bad idea. -- Justin From torsten@lodderstedt.net Thu Aug 18 07:48:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A276F21F8BB0 for ; Thu, 18 Aug 2011 07:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH-tJIHNT8Pv for ; Thu, 18 Aug 2011 07:48:39 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4921F8BAE for ; Thu, 18 Aug 2011 07:48:38 -0700 (PDT) Received: from [87.142.251.101] (helo=[192.168.71.35]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qu3uU-0005LD-Jl; Thu, 18 Aug 2011 16:49:30 +0200 Message-ID: <4E4D267F.2020507@lodderstedt.net> Date: Thu, 18 Aug 2011 16:49:35 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Justin Richer References: <1313096811.22073.96.camel@ground> <90C41DD21FB7C64BB94121FBBC2E72345029DFA82D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDA5@QEO40072.de.t-online.corp> <1313677744.13419.119.camel@ground> In-Reply-To: <1313677744.13419.119.camel@ground> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "Anganes, Amanda L" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Draft 20 last call comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:48:39 -0000 > I can see the logic of putting both token types first (though I still > prefer the auth grant first), but having the auth grant in between the > two token types is definitely a bad idea. +1 > > -- Justin > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Thu Aug 18 08:48:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CF221F8B5F for ; Thu, 18 Aug 2011 08:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slHP0EG9Lk6D for ; Thu, 18 Aug 2011 08:48:39 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EEA3721F8B53 for ; Thu, 18 Aug 2011 08:48:37 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p7IFnV3l015023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Aug 2011 10:49:31 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7IFnVre010230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 18 Aug 2011 10:49:31 -0500 Received: from [135.244.34.67] (faynberg.lra.lucent.com [135.244.34.67]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p7IFnTqs021791; Thu, 18 Aug 2011 10:49:30 -0500 (CDT) Message-ID: <4E4D3488.6090903@alcatel-lucent.com> Date: Thu, 18 Aug 2011 11:49:28 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDC0@QEO40072.de.t-online.corp> In-Reply-To: <63366D5A116E514AA4A9872D3C533539570852FDC0@QEO40072.de.t-online.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 15:48:39 -0000 >This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony,>Barry) and all agree with it. Maybe my e-mail was lost, but I was and still am among those who have agreed with the text, as I am sure many others have What is also important is that no one has objected. I see neither the reason nor the right of an editor to remove the text. Igor On 8/18/2011 3:51 AM, Lodderstedt, Torsten wrote: >> I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you>provide a step-by-step scenario of how an attacker gains access? > I'm honestly surprised you do not understand the attack. The client simply uses screen scraping on the authorization flow and programmatically "presses" the right buttons. This obviously only works if the client can predict the form structure and expected input values. > >> Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow.>This is especially true in the case of using OAuth for login which has to be practically transparent (one>click). I would hate to recommend a solution that no one is going to take seriously. > This text has been proposed by 2 WG members (Niv and me), and reviewed by 3 others (Phil, Tony, Barry) and all agree with it. What is the foundation of your strong assessment? > > The text proposes three classes of countermeasures (detect source, prevent using unpredictable input, inform resource owner and give her a chance to revoke). CAPTCHAs are one out of three examples given for unpredictable input. So I don't understand why your objection focuses on it. The selection of the appropriate countermeasure is the task of the service provider and it will most likely depend this on its capabilities, cost, user experience, and risk/impact associated with abuse. CAPTCHAs (and even one time passwords) might not be the choice for the average internet service. This will be completely different if OAuth is used to process payment transactions. > >> I'm keeping this proposed text out until we resolve this questions. > See above - I probably misunderstand the IETF process, but several people agreed with it and no one (except you) objected. Why do you hold it back? > > regards, > Torsten. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Friday, August 12, 2011 7:56 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> >> Hi all, >> >> I think the impersonation issue as raised by Niv on the list should be covered >> by the core spec. It directly aims at the trustworthiness of the user consent, >> which in my opinion is one of the core principles of OAuth. I therefore >> suggest to add a description to section 10. >> >> Please find below the text Niv and I prepared. In comparison to Niv's original >> proposal, it covers resource owner impersonation for all client categories. >> >> regards, >> Torsten. >> >> proposed text: >> >> 10. Resource Owner Impersonation >> >> When a client requests access to protected resources, the authorization flow >> normally involves the resource owner's explicit response to the access >> request, either granting or denying access to the protected resources. >> >> A malicious client can exploit knowledge of the structure of this flow in order >> to gain authorization without the resource owner's consent, by transmitting >> the necessary requests programmatically, and simulating the flow against the >> authorization server. An suthorization server will be vulnerable to this threat, >> if it uses non-interactive authentication mechanisms or split the authorization >> flow across multiple pages. >> >> It is RECOMMENDED that the authorization server takes measures to ensure >> that the authorization flow cannot be simulated. >> Attacks performed by scripts running within a trusted user-agent can be >> detected by verifying the source of the request using HTTP referrer headers. >> In order to prevent such an attack, the authorization server may force a user >> interaction based on non-predictable input values as part of the user consent >> approval. >> >> The authorization server could combine password authentication and user >> consent in a single form, make use of CAPTCHAs or one-time secrets. >> >> Alternatively, the authorization server could notify the resource owner of >> any approval by appropriate means, e.g. text message or e-Mail. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Aug 18 09:24:21 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847E221F8B4D for ; Thu, 18 Aug 2011 09:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA2h3vjT3lt4 for ; Thu, 18 Aug 2011 09:24:20 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A5DE021F8B53 for ; Thu, 18 Aug 2011 09:24:20 -0700 (PDT) Received: (qmail 20151 invoked from network); 18 Aug 2011 16:25:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 16:25:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 18 Aug 2011 09:25:08 -0700 From: Eran Hammer-Lahav To: Niv Steingarten Date: Thu, 18 Aug 2011 09:23:52 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: AcxdpT72MI94CMGvRJO664vqQ1yDOgAHOlgw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 16:24:21 -0000 VGhhbmtzLiBZb3UgaGF2ZSBhIHR5cG8gaW4gIzEgKHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50 IGJlbG9uZ3MgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBub3QgY2xpZW50KS4NCg0KVGhp cyBpcyBhIHRleHRib29rIENTUkYgYXR0YWNrIG9uIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50 Lg0KDQpUaGUgcmlnaHQgc29sdXRpb24gaXMgZm9yIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0 byBzZXQgb3IgbWFpbnRhaW4gYSBzZXNzaW9uIGNvb2tpZSAob3Igb3RoZXIgc2FtZS1vcmlnaW4t cHJvdGVjdGVkIHN0YXRlIGluIHRoZSBicm93c2VyKSBpbiAjMSBhcyB3ZWxsIGFzIHNvbWUgaGlk ZGVuIENTUkYgdG9rZW4gaW4gdGhlIEFjY2VwdCBmb3JtIGFuZCBub3QgYWxsb3cgQ09SUyBjYWxs cyB0byB0aGF0IGVuZHBvaW50LiBJIGRvbid0IHNlZSBob3cgdGhlIG1lYXN1cmVzIHByb3Bvc2Vk IGluIHRoZSBuZXcgc2VjdGlvbiBhcmUgcmVsZXZhbnQgaGVyZS4NCg0KRUhMDQoNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOaXYgU3RlaW5nYXJ0ZW4gW21haWx0bzpu aXZzdGVpbkBnbWFpbC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTgsIDIwMTEgNTo0 OSBBTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXYNCj4gQ2M6IFRvcnN0ZW4gTG9kZGVyc3RlZHQ7 IG9hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIERyYWZ0IDIwIGxhc3Qg Y2FsbCBjb21tZW50IChSZXNvdXJjZSBPd25lcg0KPiBJbXBlcnNvbmF0aW9uKQ0KPiANCj4gSGVy ZSBhcmUgdHdvIHZlcnkgc2ltcGxlIGV4YW1wbGVzLiBUaGV5IGFyZSB2ZXJ5IG5haXZlIG9uZXMs IGJ1dCBnZXQgdGhlDQo+IHBvaW50IGFjcm9zcyBhbmQgSSB3b3VsZCBub3QgYmUgc3VwcmlzZWQg aWYgdGhleSBjb3VsZCBiZSBmb3VuZCBpbiB0aGUNCj4gd2lsZDoNCj4gDQo+IFNheSBhIGNsaWVu dCBoYXMgaXRzIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXQNCj4gDQo+ICAgKDEpIGh0dHA6Ly93 d3cuZG9tYWluLmNvbS9hdXRoLnBocA0KPiANCj4gQSBjbGllbnQgcmVxdWVzdHMgYWNjZXNzIHRv IHByb3RlY3RlZCByZXNvdXJjZXMgYnkgcmVkaXJlY3RpbmcgdGhlIHVzZXItYWdlbnQNCj4gdG86 DQo+IA0KPiAgICgyKQ0KPiBodHRwOi8vd3d3LmRvbWFpbi5jb20vYXV0aC5waHA/cmVzcG9uc2Vf dHlwZT1jb2RlJmNsaWVudF9pZD0xMjM0Jg0KPiAgICAgICByZWRpcmVjdF91cmk9U09NRVVSSSZz Y29wZT1TT01FU0NPUEUNCj4gDQo+IE9uZSBwb3NzaWJsZSBkZXNpZ24gY2hvaWNlIGZvciB0aGUg ZGV2ZWxvcGVyLCBpZiBhIGJhZCBvbmUsIGlzIHRvIGhhdmUgdGhlDQo+ICdBbGxvdycgYnV0dG9u IHBvaW50IHRvOg0KPiANCj4gICAoMykgaHR0cDovL3d3dy5kb21haW4uY29tL2F1dGgucGhwP1su LnByZXZpb3VzIHF1ZXJ5DQo+IHBhcmFtcy4uXSZhbGxvdz0xDQo+IA0KPiBJbiB0aGlzIGNhc2Us IGEgbWFsaWNpb3VzIGNsaWVudCB3aG8ga25vd3MgdGhlIHN0cnVjdHVyZSBvZiB0aGlzIGF1dGgg ZmxvdywgY2FuDQo+IHNpbXBseSBza2lwICgyKSBhbmQgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQg dG8gKDMpIGluIG9yZGVyIHRvIGdhaW4gYWNjZXNzIHRvIHRoZQ0KPiBwcm90ZWN0ZWQgcmVzb3Vy Y2VzLg0KPiANCj4gQW5vdGhlciBwb3NzaWJsZSBkZXNpZ24gY2hvaWNlIGZvciB0aGUgZGV2ZWxv cGVyIChhZ2FpbiwgYSB2ZXJ5IGJhZA0KPiBvbmUpIHdvdWxkIGJlIHRvIGlzc3VlIHNvbWUga2lu ZCBvZiBzZXNzaW9uIGNvb2tpZSBhZnRlciAoMikgaW4gb3JkZXIgdG8ga2VlcA0KPiBhIHN0YXRl LiBUaGVuLCB0aGUgJ0FsbG93JyBidXR0b24gY291bGQgcG9zc2libHkgcG9pbnQgdG86DQo+IA0K PiAgICg0KSBodHRwOi8vd3d3LmRvbWFpbi5jb20vYWxsb3cucGhwDQo+IA0KPiB3aXRob3V0IGFu eSBwYXJhbWV0ZXJzIChzaW5jZSB0aGUgc3RhdGUgaXMgbWFpbnRhaW5lZCBieSBhIGNvb2tpZSku DQo+IA0KPiBIZXJlLCBhbiBhdHRhY2tlciBjb3VsZCBsYXVuY2ggYSByZXF1ZXN0IHRvICgyKSBq dXN0IHRvIGlzc3VlIHRoZSBzdGF0ZSBjb29raWUsDQo+IGFuZCBpbW1lZGlhdGVseSByZWRpcmVj dCB0aGUgdXNlci1hZ2VudCB0byAoNCkgaW4gb3JkZXIgdG8gZ2FpbiBhY2Nlc3MgdG8gdGhlDQo+ IHByb3RlY3RlZCByZXNvdXJjZXMuDQo+IA0KPiBUaGVzZSBhcmUgdHdvIHZlcnkgbmFpdmUgc2Nl bmFyaW9zIHdoaWNoIGNhbiBiZSBhdmVydGVkIHVzaW5nIGEgbm9uY2UgZm9yDQo+IGV4YW1wbGUg KCsgYmV0dGVyIGRlc2lnbiBjaG9pY2VzLCBmb3IgdGhhdCBtYXR0ZXIpLg0KPiANCj4gSW4gbm9u LXVzZXItYWdlbnQgYmFzZWQgY2xpZW50cywgYSBjbGllbnQgbWlnaHQgYWxzbyBiZSBhYmxlIHRv IGFjdHVhbGx5IHNjcmFwZQ0KPiB0aGUgY29udGVudHMgb2YgdGhlIGF1dGhvcml6YXRpb24gSFRN TCBwYWdlLCBhbmQgc2ltdWxhdGUgdGhlIGNsaWNrDQo+IHByb2dyYW1tYXRpY2FsbHkuIEluIHRo aXMgY2FzZSBhIG5vbmNlIHdvdWxkIGJlIHVzZWxlc3MsIGJ1dCBhIENBUFRDSEEgb3IgYQ0KPiBQ SU4gY29kZS9wYXNzd29yZCB3b3VsZCBzb2x2ZSB0aGUgcHJvYmxlbS4NCj4gDQo+IC0tIE5pdg0K PiANCj4gDQo+IA0KPiBPbiBUaHUsIEF1ZyAxOCwgMjAxMSBhdCAwODo1OCwgRXJhbiBIYW1tZXIt TGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb20+DQo+IHdyb3RlOg0KPiA+IEkndmUgcmVhZCB0aGUg dGhyZWFkIGxlYWRpbmcgdG8gdGhpcywgYW5kIHRoZSBwcm9wb3NlZCB0ZXh0IGFuZCBJIGRvIG5v dA0KPiB1bmRlcnN0YW5kIHRoZSBhdHRhY2suIENhbiB5b3UgcHJvdmlkZSBhIHN0ZXAtYnktc3Rl cCBzY2VuYXJpbyBvZiBob3cgYW4NCj4gYXR0YWNrZXIgZ2FpbnMgYWNjZXNzPw0KPiA+DQo+ID4g QWxzbywgaXQgaXMgdW5saWtlbHkgdGhhdCBhbnkgbWFqb3IgcHJvdmlkZXIgaXMgZ29pbmcgdG8g cmVxdWlyZSBDQVBDSEEgYXMNCj4gcGFydCBvZiB0aGUgYXV0aG9yaXphdGlvbiBmbG93LiBUaGlz IGlzIGVzcGVjaWFsbHkgdHJ1ZSBpbiB0aGUgY2FzZSBvZiB1c2luZw0KPiBPQXV0aCBmb3IgbG9n aW4gd2hpY2ggaGFzIHRvIGJlIHByYWN0aWNhbGx5IHRyYW5zcGFyZW50IChvbmUgY2xpY2spLiBJ IHdvdWxkDQo+IGhhdGUgdG8gcmVjb21tZW5kIGEgc29sdXRpb24gdGhhdCBubyBvbmUgaXMgZ29p bmcgdG8gdGFrZSBzZXJpb3VzbHkuDQo+ID4NCj4gPiBJJ20ga2VlcGluZyB0aGlzIHByb3Bvc2Vk IHRleHQgb3V0IHVudGlsIHdlIHJlc29sdmUgdGhpcyBxdWVzdGlvbnMuDQo+ID4NCj4gPiBFSEwN Cj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IG9h dXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbg0K PiA+PiBCZWhhbGYgT2YgVG9yc3RlbiBMb2RkZXJzdGVkdA0KPiA+PiBTZW50OiBGcmlkYXksIEF1 Z3VzdCAxMiwgMjAxMSA3OjU2IEFNDQo+ID4+IFRvOiBvYXV0aEBpZXRmLm9yZw0KPiA+PiBTdWJq ZWN0OiBbT0FVVEgtV0ddIERyYWZ0IDIwIGxhc3QgY2FsbCBjb21tZW50IChSZXNvdXJjZSBPd25l cg0KPiA+PiBJbXBlcnNvbmF0aW9uKQ0KPiA+Pg0KPiA+PiBIaSBhbGwsDQo+ID4+DQo+ID4+IEkg dGhpbmsgdGhlIGltcGVyc29uYXRpb24gaXNzdWUgYXMgcmFpc2VkIGJ5IE5pdiBvbiB0aGUgbGlz dCBzaG91bGQNCj4gPj4gYmUgY292ZXJlZCBieSB0aGUgY29yZSBzcGVjLiBJdCBkaXJlY3RseSBh aW1zIGF0IHRoZSB0cnVzdHdvcnRoaW5lc3MNCj4gPj4gb2YgdGhlIHVzZXIgY29uc2VudCwgd2hp Y2ggaW4gbXkgb3BpbmlvbiBpcyBvbmUgb2YgdGhlIGNvcmUNCj4gPj4gcHJpbmNpcGxlcyBvZiBP QXV0aC4gSSB0aGVyZWZvcmUgc3VnZ2VzdCB0byBhZGQgYSBkZXNjcmlwdGlvbiB0byBzZWN0aW9u IDEwLg0KPiA+Pg0KPiA+PiBQbGVhc2UgZmluZCBiZWxvdyB0aGUgdGV4dCBOaXYgYW5kIEkgcHJl cGFyZWQuIEluIGNvbXBhcmlzb24gdG8NCj4gPj4gTml2J3Mgb3JpZ2luYWwgcHJvcG9zYWwsIGl0 IGNvdmVycyByZXNvdXJjZSBvd25lciBpbXBlcnNvbmF0aW9uIGZvciBhbGwNCj4gY2xpZW50IGNh dGVnb3JpZXMuDQo+ID4+DQo+ID4+IHJlZ2FyZHMsDQo+ID4+IFRvcnN0ZW4uDQo+ID4+DQo+ID4+ IHByb3Bvc2VkIHRleHQ6DQo+ID4+DQo+ID4+IDEwLjx0byBiZSBkZXRlcm1pbmVkPiBSZXNvdXJj ZSBPd25lciBJbXBlcnNvbmF0aW9uDQo+ID4+DQo+ID4+IFdoZW4gYSBjbGllbnQgcmVxdWVzdHMg YWNjZXNzIHRvIHByb3RlY3RlZCByZXNvdXJjZXMsIHRoZQ0KPiA+PiBhdXRob3JpemF0aW9uIGZs b3cgbm9ybWFsbHkgaW52b2x2ZXMgdGhlIHJlc291cmNlIG93bmVyJ3MgZXhwbGljaXQNCj4gPj4g cmVzcG9uc2UgdG8gdGhlIGFjY2VzcyByZXF1ZXN0LCBlaXRoZXIgZ3JhbnRpbmcgb3IgZGVueWlu ZyBhY2Nlc3MgdG8gdGhlDQo+IHByb3RlY3RlZCByZXNvdXJjZXMuDQo+ID4+DQo+ID4+IEEgbWFs aWNpb3VzIGNsaWVudCBjYW4gZXhwbG9pdCBrbm93bGVkZ2Ugb2YgdGhlIHN0cnVjdHVyZSBvZiB0 aGlzDQo+ID4+IGZsb3cgaW4gb3JkZXIgdG8gZ2FpbiBhdXRob3JpemF0aW9uIHdpdGhvdXQgdGhl IHJlc291cmNlIG93bmVyJ3MNCj4gPj4gY29uc2VudCwgYnkgdHJhbnNtaXR0aW5nIHRoZSBuZWNl c3NhcnkgcmVxdWVzdHMgcHJvZ3JhbW1hdGljYWxseSwgYW5kDQo+ID4+IHNpbXVsYXRpbmcgdGhl IGZsb3cgYWdhaW5zdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIEFuDQo+ID4+IHN1dGhvcml6 YXRpb24gc2VydmVyIHdpbGwgYmUgdnVsbmVyYWJsZSB0byB0aGlzIHRocmVhdCwgaWYgaXQgdXNl cw0KPiA+PiBub24taW50ZXJhY3RpdmUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBvciBzcGxp dCB0aGUgYXV0aG9yaXphdGlvbiBmbG93DQo+IGFjcm9zcyBtdWx0aXBsZSBwYWdlcy4NCj4gPj4N Cj4gPj4gSXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdGFr ZXMgbWVhc3VyZXMgdG8NCj4gPj4gZW5zdXJlIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gZmxvdyBj YW5ub3QgYmUgc2ltdWxhdGVkLg0KPiA+PiBBdHRhY2tzIHBlcmZvcm1lZCBieSBzY3JpcHRzIHJ1 bm5pbmcgd2l0aGluIGEgdHJ1c3RlZCB1c2VyLWFnZW50IGNhbg0KPiA+PiBiZSBkZXRlY3RlZCBi eSB2ZXJpZnlpbmcgdGhlIHNvdXJjZSBvZiB0aGUgcmVxdWVzdCB1c2luZyBIVFRQIHJlZmVycmVy DQo+IGhlYWRlcnMuDQo+ID4+IEluIG9yZGVyIHRvIHByZXZlbnQgc3VjaCBhbiBhdHRhY2ssIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBtYXkNCj4gPj4gZm9yY2UgYSB1c2VyIGludGVyYWN0aW9u IGJhc2VkIG9uIG5vbi1wcmVkaWN0YWJsZSBpbnB1dCB2YWx1ZXMgYXMNCj4gPj4gcGFydCBvZiB0 aGUgdXNlciBjb25zZW50IGFwcHJvdmFsLg0KPiA+Pg0KPiA+PiBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgY291bGQgY29tYmluZSBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiBhbmQNCj4gPj4gdXNl ciBjb25zZW50IGluIGEgc2luZ2xlIGZvcm0sIG1ha2UgdXNlIG9mIENBUFRDSEFzIG9yIG9uZS10 aW1lIHNlY3JldHMuDQo+ID4+DQo+ID4+IEFsdGVybmF0aXZlbHksIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBjb3VsZCBub3RpZnkgdGhlIHJlc291cmNlDQo+ID4+IG93bmVyIG9mIGFueSBhcHBy b3ZhbCBieSBhcHByb3ByaWF0ZSBtZWFucywgZS5nLiB0ZXh0IG1lc3NhZ2Ugb3IgZS1NYWlsLg0K PiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPj4gT0F1dGhAaWV0Zi5vcmcNCj4gPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBs aXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQo+ID4NCg== From eran@hueniverse.com Thu Aug 18 09:55:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F72621F8B02 for ; Thu, 18 Aug 2011 09:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-MYK0UapJYK for ; Thu, 18 Aug 2011 09:54:59 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 83F7421F874E for ; Thu, 18 Aug 2011 09:54:59 -0700 (PDT) Received: (qmail 19017 invoked from network); 18 Aug 2011 16:55:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 16:55:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 18 Aug 2011 09:55:48 -0700 From: Eran Hammer-Lahav To: "Lodderstedt, Torsten" , Torsten Lodderstedt , "oauth@ietf.org" Date: Thu, 18 Aug 2011 09:54:31 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: AcxZAD9oCYx+xdzVQuy705Z1zNxKpgEaydKwAANDmfAAErXkwA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA3B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDC0@QEO40072.de.t-online.corp> In-Reply-To: <63366D5A116E514AA4A9872D3C533539570852FDC0@QEO40072.de.t-online.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 16:55:00 -0000 Hey Torsten, > -----Original Message----- > From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] > Sent: Thursday, August 18, 2011 12:52 AM > To: Eran Hammer-Lahav; Torsten Lodderstedt; oauth@ietf.org > Subject: AW: [OAUTH-WG] Draft 20 last call comment (Resource Owner > Impersonation) >=20 > >I've read the thread leading to this, and the proposed text and I do not > understand the attack. Can you >provide a step-by-step scenario of how an > attacker gains access? >=20 > I'm honestly surprised you do not understand the attack. The client simpl= y > uses screen scraping on the authorization flow and programmatically > "presses" the right buttons. This obviously only works if the client can = predict > the form structure and expected input values. That's not an attack but a description of capabilities. The attack example = provided by Niv is a *classic* CSRF attack on the authorization endpoint. > >Also, it is unlikely that any major provider is going to require CAPCHA = as part > of the authorization flow. >This is especially true in the case of using = OAuth > for login which has to be practically transparent (one >click). I would h= ate to > recommend a solution that no one is going to take seriously. >=20 > This text has been proposed by 2 WG members (Niv and me), and reviewed > by 3 others (Phil, Tony, Barry) and all agree with it. What is the founda= tion of > your strong assessment? I don't understand the attack and how the proposed solution address it. I'm= really happy for everyone else who got it, but I need more information to = process it. > The text proposes three classes of countermeasures (detect source, preven= t > using unpredictable input, inform resource owner and give her a chance to > revoke). CAPTCHAs are one out of three examples given for unpredictable > input. So I don't understand why your objection focuses on it. True. But it was central in the list discussion and was promoted as strong = defense to whatever this attack is. I think that CAPCHA is an impractical r= ecommendation in general for the authorization endpoint. Can you point to a= ny real world example of a large provider forcing CAPCHA on every login? Th= at's what this amounts to. > The selection > of the appropriate countermeasure is the task of the service provider and= it > will most likely depend this on its capabilities, cost, user experience, = and > risk/impact associated with abuse. CAPTCHAs (and even one time > passwords) might not be the choice for the average internet service. This= will > be completely different if OAuth is used to process payment transactions. The text hints at a very dangerous attack vector of scripts doing 'really b= ad things'. But it doesn't show why this attack requires any kind of automa= tion at all. If I am targeting just a small number of people, I can "automa= te" this by sending a message to a human who will break the CAPCHA and quic= kly return the link to approve access. The other measures either have the s= ame properties, are just there to annoy the attacker, or provide some kind = of after the fact notice (when it is clearly too late to prevent damage). > >I'm keeping this proposed text out until we resolve this questions. >=20 > See above - I probably misunderstand the IETF process, but several people > agreed with it and no one (except you) objected. Why do you hold it back? "no one (except you)" is an interesting statement... :-) This is not a process issue. New text has been proposed with the support of= a few working group members. The working group has been largely silent abo= ut it (and the review you referenced above was done off list). I have read = the new text and did not understand it, therefore, could not edit the text = as I have done with every other proposed language. No new draft will be published until we resolve all open issues, which is e= xactly what I have stated above. To make it clearer: I am keeping this proposed text out of *my* working draft for -21 until the= working group discusses the text further and addresses the issues I have r= aised about the text as a working group member (technical issues) and as an= editor (clarity issues). As for IETF process, all it takes is one objection to block text from being= *automatically* added to the specification. I have not implied anywhere th= at I have made any decision (or have the authority to) with regard to this = text, only that I'm holding it back until the issues are resolved. And IETF= process does not require full agreement to solve issues which is the role = of the chairs to resolve. In this case, we're nowhere near needing help fro= m the chairs - just the assistance of the text authors to do their job and = explain it. EHL From tonynad@microsoft.com Thu Aug 18 09:58:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B57421F8B3B for ; Thu, 18 Aug 2011 09:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.467 X-Spam-Level: X-Spam-Status: No, score=-7.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BimrLYnpdwWH for ; Thu, 18 Aug 2011 09:58:21 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 9605621F8B34 for ; Thu, 18 Aug 2011 09:58:21 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 18 Aug 2011 09:59:16 -0700 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Aug 2011 09:59:15 -0700 Received: from mail137-ch1-R.bigfish.com (216.32.181.172) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Thu, 18 Aug 2011 16:59:14 +0000 Received: from mail137-ch1 (localhost.localdomain [127.0.0.1]) by mail137-ch1-R.bigfish.com (Postfix) with ESMTP id CCB23430429 for ; Thu, 18 Aug 2011 16:59:14 +0000 (UTC) X-SpamScore: -25 X-BigFish: PS-25(zz9371K542Mzz1202h1082kzz1033IL8275dhz31h2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT011.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail137-ch1: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT011.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail137-ch1 (localhost.localdomain [127.0.0.1]) by mail137-ch1 (MessageSwitch) id 1313686727419252_27615; Thu, 18 Aug 2011 16:58:47 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail137-ch1.bigfish.com (Postfix) with ESMTP id 080B3AC81FC; Thu, 18 Aug 2011 16:58:13 +0000 (UTC) Received: from SN2PRD0302HT011.namprd03.prod.outlook.com (207.46.4.139) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 18 Aug 2011 16:58:12 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.2.234]) by SN2PRD0302HT011.namprd03.prod.outlook.com ([10.27.90.157]) with mapi id 14.01.0225.064; Thu, 18 Aug 2011 16:58:11 +0000 From: Anthony Nadalin To: "Lodderstedt, Torsten" , Eran Hammer-Lahav , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland Thread-Index: AcxXpdCrqvPON2CRS72O2K03CR90kwDcgn2QAJkH2nAAEvp9YA== Date: Thu, 18 Aug 2011 16:58:10 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDCA@QEO40072.de.t-online.corp> In-Reply-To: <63366D5A116E514AA4A9872D3C533539570852FDCA@QEO40072.de.t-online.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.42.119.173] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT011.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TELEKOM.DE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 16:58:22 -0000 Agree, against the removal of text -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of L= odderstedt, Torsten Sent: Thursday, August 18, 2011 1:01 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20= from Yaron Goland >> 1.4.3. Resource Owner Password Credentials: Comment on "(when=20 >> combined with a refresh token)": "This is the first time that refresh=20 >> tokens are mentioned in the spec. And yet there is no explanation of wha= t they are. >> I suspect they should anyway be introduced in section 1.4.1 (as=20 >> previously >> noted) and then their use here will make sense. If that isn't=20 >> possible then it would be good to have a forward reference to section=20 >> 1.5 below so the reader has some idea of what's going on." >I removed '(when combined with a refresh token)'. This is actually not tru= e as there is no assumption that >access tokens are always short-lived or t= hat refresh tokens will always be issued to native applications using >this= grant type. -1 against removing this text (w/o an suitable replacement) and w/o group c= onsent.=20 The -20 text clearly points out that this combination "... eliminates the n= eed for the client to store the resource owner credentials for future use".= The resource owner grant type alone does not justify this statement. It's true that the spec does not explicitly defines the lifetime assumption= for access and refresh tokens (which is pity in my opinion). So at least a= dd something like "if the token lifetime is reasonable long enough". regards, Torsten. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Aug 18 09:58:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F418D21F8B48 for ; Thu, 18 Aug 2011 09:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc7trtxtwU3h for ; Thu, 18 Aug 2011 09:58:37 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 7F94D21F8B34 for ; Thu, 18 Aug 2011 09:58:37 -0700 (PDT) Received: (qmail 27079 invoked from network); 18 Aug 2011 16:59:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 16:59:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 18 Aug 2011 09:59:28 -0700 From: Eran Hammer-Lahav To: "igor.faynberg@alcatel-lucent.com" , "oauth@ietf.org" Date: Thu, 18 Aug 2011 09:58:11 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: AcxdvnqUBHFtJju5TJmvCzWaBRU/wQACRMQw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA3E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDC0@QEO40072.de.t-online.corp> <4E4D3488.6090903@alcatel-lucent.com> In-Reply-To: <4E4D3488.6090903@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 16:58:38 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Igor Faynberg > Sent: Thursday, August 18, 2011 8:49 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner > Impersonation) >=20 > >This text has been proposed by 2 WG members (Niv and me), and reviewed > by 3 others (Phil, Tony,>Barry) and all agree with it. >=20 > Maybe my e-mail was lost, but I was and still am among those who have > agreed with the text, as I am sure many others have Fantastic! Now explain it to me. > What is also important is that no one has objected. >=20 > I see neither the reason nor the right of an editor to remove the text. Nothing was *removed* - it wasn't even rejected. It is simply held back to = allow additional discussion and it is clearly within the role of editor. EHL From eran@hueniverse.com Thu Aug 18 10:01:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1140721F8B46 for ; Thu, 18 Aug 2011 10:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBwULQPGEZWS for ; Thu, 18 Aug 2011 10:01:31 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 9F4F421F8B62 for ; Thu, 18 Aug 2011 10:01:31 -0700 (PDT) Received: (qmail 7042 invoked from network); 18 Aug 2011 17:02:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 17:02:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 18 Aug 2011 10:02:21 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 18 Aug 2011 10:01:04 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: AcxZAD9oCYx+xdzVQuy705Z1zNxKpgEaydKwABcr5dA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA42@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth-chairs@tools.ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:01:33 -0000 I'd like to ask the chairs to open an issue for this. I didn't realize how hyper sensitive this working group has become that eve= ry proposal being questioned needs a ticket to prove to people that they ar= e not being dismissed. But since this is clearly the case, let's be pedanti= c and open an issue. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Wednesday, August 17, 2011 10:58 PM > To: Torsten Lodderstedt; oauth@ietf.org > Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner > Impersonation) >=20 > I've read the thread leading to this, and the proposed text and I do not > understand the attack. Can you provide a step-by-step scenario of how an > attacker gains access? >=20 > Also, it is unlikely that any major provider is going to require CAPCHA a= s part > of the authorization flow. This is especially true in the case of using O= Auth for > login which has to be practically transparent (one click). I would hate t= o > recommend a solution that no one is going to take seriously. >=20 > I'm keeping this proposed text out until we resolve this questions. >=20 > EHL >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Torsten Lodderstedt > > Sent: Friday, August 12, 2011 7:56 AM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner > > Impersonation) > > > > Hi all, > > > > I think the impersonation issue as raised by Niv on the list should be > > covered by the core spec. It directly aims at the trustworthiness of > > the user consent, which in my opinion is one of the core principles of > > OAuth. I therefore suggest to add a description to section 10. > > > > Please find below the text Niv and I prepared. In comparison to Niv's > > original proposal, it covers resource owner impersonation for all clien= t > categories. > > > > regards, > > Torsten. > > > > proposed text: > > > > 10. Resource Owner Impersonation > > > > When a client requests access to protected resources, the > > authorization flow normally involves the resource owner's explicit > > response to the access request, either granting or denying access to th= e > protected resources. > > > > A malicious client can exploit knowledge of the structure of this flow > > in order to gain authorization without the resource owner's consent, > > by transmitting the necessary requests programmatically, and > > simulating the flow against the authorization server. An suthorization > > server will be vulnerable to this threat, if it uses non-interactive > > authentication mechanisms or split the authorization flow across multip= le > pages. > > > > It is RECOMMENDED that the authorization server takes measures to > > ensure that the authorization flow cannot be simulated. > > Attacks performed by scripts running within a trusted user-agent can > > be detected by verifying the source of the request using HTTP referrer > headers. > > In order to prevent such an attack, the authorization server may force > > a user interaction based on non-predictable input values as part of > > the user consent approval. > > > > The authorization server could combine password authentication and > > user consent in a single form, make use of CAPTCHAs or one-time secrets= . > > > > Alternatively, the authorization server could notify the resource > > owner of any approval by appropriate means, e.g. text message or e-Mail= . > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nivstein@gmail.com Thu Aug 18 10:14:58 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B54A21F8B13 for ; Thu, 18 Aug 2011 10:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZDL7S7p1w7m for ; Thu, 18 Aug 2011 10:14:57 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9A821F8A97 for ; Thu, 18 Aug 2011 10:14:57 -0700 (PDT) Received: by vxi29 with SMTP id 29so2340921vxi.31 for ; Thu, 18 Aug 2011 10:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=HHAYlXUFET5BPH7szuhEAq3/J8W6vBX1x04mbBxbS/0=; b=MEOowO8Zkao/2HsWIbmYTVzYXCsTi2wj6DLVdmHLX6GaYFS3EGD9lylAoCcKWFcblB Ld1Es8GsRTA4DB+nOiZatMCpEu1/9HWf5svstBAcoH2rwtCNsHI7a8tWMSRGIzS4gJrM z5ejQEMh+QgO+zNhP56kDZg10iL8OGu8pITNA= Received: by 10.52.19.204 with SMTP id h12mr1118883vde.54.1313687750070; Thu, 18 Aug 2011 10:15:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.170 with HTTP; Thu, 18 Aug 2011 10:15:30 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Niv Steingarten Date: Thu, 18 Aug 2011 20:15:30 +0300 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:14:58 -0000 (thanks for the typo correction) Yes, the example I provided is a very lightweight one which does take the form of CSRF, but it is only the simplest example of a family of automated authorization flow attacks. Indeed, a nonce (or hidden token, both serve the same purpose in this case) would be enough here. If the client is not user-agent based, a full-fledged forgery of the whole process is possible, one in which CORS and sandboxes have no meaning. In a native client, unless some kind of human test is performed, the whole flow could be spoofed. A CAPTCHA and/or password entry are not bullet-proof, but they provide a steep obstacle for the attacker. Another option would be, for example, to email the resource owner an OTP, with the following message "The application [...] requests access to [...]. Please use the number XXXX to allow it access etc..." (similar to Google's and Facebook's two-step sign-in). The first attack described in my previous message takes the form of CSRF, while the above one may be bypassed by an attacker with the help of some sort of clickjacking or similar. Eventually this threat description is for a family of attacks which mimic the behavior of the resource owner in order to gain access to protected resources, and some possible countermeasures. -- Niv On Thu, Aug 18, 2011 at 19:23, Eran Hammer-Lahav wrot= e: > Thanks. You have a typo in #1 (the authorization endpoint belongs to the = authorization server, not client). > > This is a textbook CSRF attack on the authorization endpoint. > > The right solution is for the authorization server to set or maintain a s= ession cookie (or other same-origin-protected state in the browser) in #1 a= s well as some hidden CSRF token in the Accept form and not allow CORS call= s to that endpoint. I don't see how the measures proposed in the new sectio= n are relevant here. > > EHL > > >> -----Original Message----- >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> Sent: Thursday, August 18, 2011 5:49 AM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> >> Here are two very simple examples. They are very naive ones, but get the >> point across and I would not be suprised if they could be found in the >> wild: >> >> Say a client has its authorization endpoint at >> >> =C2=A0 (1) http://www.domain.com/auth.php >> >> A client requests access to protected resources by redirecting the user-= agent >> to: >> >> =C2=A0 (2) >> http://www.domain.com/auth.php?response_type=3Dcode&client_id=3D1234& >> =C2=A0 =C2=A0 =C2=A0 redirect_uri=3DSOMEURI&scope=3DSOMESCOPE >> >> One possible design choice for the developer, if a bad one, is to have t= he >> 'Allow' button point to: >> >> =C2=A0 (3) http://www.domain.com/auth.php?[..previous query >> params..]&allow=3D1 >> >> In this case, a malicious client who knows the structure of this auth fl= ow, can >> simply skip (2) and redirect the user-agent to (3) in order to gain acce= ss to the >> protected resources. >> >> Another possible design choice for the developer (again, a very bad >> one) would be to issue some kind of session cookie after (2) in order to= keep >> a state. Then, the 'Allow' button could possibly point to: >> >> =C2=A0 (4) http://www.domain.com/allow.php >> >> without any parameters (since the state is maintained by a cookie). >> >> Here, an attacker could launch a request to (2) just to issue the state = cookie, >> and immediately redirect the user-agent to (4) in order to gain access t= o the >> protected resources. >> >> These are two very naive scenarios which can be averted using a nonce fo= r >> example (+ better design choices, for that matter). >> >> In non-user-agent based clients, a client might also be able to actually= scrape >> the contents of the authorization HTML page, and simulate the click >> programmatically. In this case a nonce would be useless, but a CAPTCHA o= r a >> PIN code/password would solve the problem. >> >> -- Niv >> >> >> >> On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav >> wrote: >> > I've read the thread leading to this, and the proposed text and I do n= ot >> understand the attack. Can you provide a step-by-step scenario of how an >> attacker gains access? >> > >> > Also, it is unlikely that any major provider is going to require CAPCH= A as >> part of the authorization flow. This is especially true in the case of u= sing >> OAuth for login which has to be practically transparent (one click). I w= ould >> hate to recommend a solution that no one is going to take seriously. >> > >> > I'm keeping this proposed text out until we resolve this questions. >> > >> > EHL >> > >> > >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >> Behalf Of Torsten Lodderstedt >> >> Sent: Friday, August 12, 2011 7:56 AM >> >> To: oauth@ietf.org >> >> Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> >> Impersonation) >> >> >> >> Hi all, >> >> >> >> I think the impersonation issue as raised by Niv on the list should >> >> be covered by the core spec. It directly aims at the trustworthiness >> >> of the user consent, which in my opinion is one of the core >> >> principles of OAuth. I therefore suggest to add a description to sect= ion 10. >> >> >> >> Please find below the text Niv and I prepared. In comparison to >> >> Niv's original proposal, it covers resource owner impersonation for a= ll >> client categories. >> >> >> >> regards, >> >> Torsten. >> >> >> >> proposed text: >> >> >> >> 10. Resource Owner Impersonation >> >> >> >> When a client requests access to protected resources, the >> >> authorization flow normally involves the resource owner's explicit >> >> response to the access request, either granting or denying access to = the >> protected resources. >> >> >> >> A malicious client can exploit knowledge of the structure of this >> >> flow in order to gain authorization without the resource owner's >> >> consent, by transmitting the necessary requests programmatically, and >> >> simulating the flow against the authorization server. An >> >> suthorization server will be vulnerable to this threat, if it uses >> >> non-interactive authentication mechanisms or split the authorization = flow >> across multiple pages. >> >> >> >> It is RECOMMENDED that the authorization server takes measures to >> >> ensure that the authorization flow cannot be simulated. >> >> Attacks performed by scripts running within a trusted user-agent can >> >> be detected by verifying the source of the request using HTTP referre= r >> headers. >> >> In order to prevent such an attack, the authorization server may >> >> force a user interaction based on non-predictable input values as >> >> part of the user consent approval. >> >> >> >> The authorization server could combine password authentication and >> >> user consent in a single form, make use of CAPTCHAs or one-time secre= ts. >> >> >> >> Alternatively, the authorization server could notify the resource >> >> owner of any approval by appropriate means, e.g. text message or e-Ma= il. >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > > From igor.faynberg@alcatel-lucent.com Thu Aug 18 10:15:54 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA4C21F8BBA for ; Thu, 18 Aug 2011 10:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Q2WZZVXq74w for ; Thu, 18 Aug 2011 10:15:54 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id BE5F821F8BB3 for ; Thu, 18 Aug 2011 10:15:47 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p7IHGfA3018939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Aug 2011 12:16:41 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7IHGf1p031577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 18 Aug 2011 12:16:41 -0500 Received: from [135.244.34.67] (faynberg.lra.lucent.com [135.244.34.67]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p7IHGe3W008715; Thu, 18 Aug 2011 12:16:41 -0500 (CDT) Message-ID: <4E4D48F8.8050803@alcatel-lucent.com> Date: Thu, 18 Aug 2011 13:16:40 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDCA@QEO40072.de.t-online.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:15:54 -0000 +1 (against the removal) On 8/18/2011 12:58 PM, Anthony Nadalin wrote: > Agree, against the removal of text > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Lodderstedt, Torsten > Sent: Thursday, August 18, 2011 1:01 AM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland > >>> 1.4.3. Resource Owner Password Credentials: Comment on "(when >>> combined with a refresh token)": "This is the first time that refresh >>> tokens are mentioned in the spec. And yet there is no explanation of what they are. >>> I suspect they should anyway be introduced in section 1.4.1 (as >>> previously >>> noted) and then their use here will make sense. If that isn't >>> possible then it would be good to have a forward reference to section >>> 1.5 below so the reader has some idea of what's going on." >> I removed '(when combined with a refresh token)'. This is actually not true as there is no assumption that>access tokens are always short-lived or that refresh tokens will always be issued to native applications using>this grant type. > -1 against removing this text (w/o an suitable replacement) and w/o group consent. > > The -20 text clearly points out that this combination "... eliminates the need for the client to store the resource owner credentials for future use". The resource owner grant type alone does not justify this statement. > It's true that the spec does not explicitly defines the lifetime assumption for access and refresh tokens (which is pity in my opinion). So at least add something like "if the token lifetime is reasonable long enough". > > regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Aug 18 10:20:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B363821F8B3C for ; Thu, 18 Aug 2011 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX4GeKuLlNHA for ; Thu, 18 Aug 2011 10:20:45 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 59D7A21F856C for ; Thu, 18 Aug 2011 10:20:43 -0700 (PDT) Received: (qmail 14958 invoked from network); 18 Aug 2011 17:21:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 17:21:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 18 Aug 2011 10:21:28 -0700 From: Eran Hammer-Lahav To: "Lodderstedt, Torsten" , "oauth@ietf.org" Date: Thu, 18 Aug 2011 10:20:11 -0700 Thread-Topic: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland Thread-Index: AcxXpdCrqvPON2CRS72O2K03CR90kwDcgn2QAJkH2nAAEz+pwA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA51@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDCA@QEO40072.de.t-online.corp> In-Reply-To: <63366D5A116E514AA4A9872D3C533539570852FDCA@QEO40072.de.t-online.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:20:45 -0000 Chairs - please open an issue for this: "Clarifying reference to refresh to= kens in section 1.4.3 of -20". > -----Original Message----- > From: Lodderstedt, Torsten [mailto:t.lodderstedt@telekom.de] > Sent: Thursday, August 18, 2011 1:01 AM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: AW: [OAUTH-WG] Partial set of last call comments on OAuth draft = 20 > from Yaron Goland >=20 > >> 1.4.3. Resource Owner Password Credentials: Comment on "(when > >> combined with a refresh token)": "This is the first time that refresh > >> tokens are mentioned in the spec. And yet there is no explanation of > what they are. > >> I suspect they should anyway be introduced in section 1.4.1 (as > >> previously > >> noted) and then their use here will make sense. If that isn't > >> possible then it would be good to have a forward reference to section > >> 1.5 below so the reader has some idea of what's going on." >=20 > >I removed '(when combined with a refresh token)'. This is actually not t= rue > as there is no assumption that >access tokens are always short-lived or t= hat > refresh tokens will always be issued to native applications using >this g= rant > type. >=20 > -1 against removing this text (w/o an suitable replacement) and w/o group > consent. Since you felt it necessary to make this a process issue, I've asked the ch= airs to open a ticket. > The -20 text clearly points out that this combination "... eliminates the= need > for the client to store the resource owner credentials for future use". T= he > resource owner grant type alone does not justify this statement. > It's true that the spec does not explicitly defines the lifetime assumpti= on for > access and refresh tokens (which is pity in my opinion). So at least add > something like "if the token lifetime is reasonable long enough". How about: This grant type can eliminates the need for the client to store the reso= urce owner credentials for future use, by exchanging the credentials with a long-li= ved access token or refresh token. As for Yaron's original comment, I think this text is sufficient and no for= ward reference is needed to 1.5 (which is a few lines lower in the same pag= e). Also, with the new organization proposed by Justin, the access token te= rm isn't full defined yet either and it reads just fine. EHL From eran@hueniverse.com Thu Aug 18 10:32:16 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BB521F8B04 for ; Thu, 18 Aug 2011 10:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhNab7YfDHpA for ; Thu, 18 Aug 2011 10:32:15 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 6C09F21F8AFE for ; Thu, 18 Aug 2011 10:32:15 -0700 (PDT) Received: (qmail 10102 invoked from network); 18 Aug 2011 17:33:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 17:33:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 18 Aug 2011 10:32:56 -0700 From: Eran Hammer-Lahav To: Niv Steingarten Date: Thu, 18 Aug 2011 10:31:39 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: AcxdyoCcbQN55M78QPCioZff6BEUegAAMTew Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:32:16 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTml2IFN0ZWluZ2FydGVu IFttYWlsdG86bml2c3RlaW5AZ21haWwuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE4 LCAyMDExIDEwOjE2IEFNDQo+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiBDYzogVG9yc3RlbiBM b2RkZXJzdGVkdDsgb2F1dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRHJh ZnQgMjAgbGFzdCBjYWxsIGNvbW1lbnQgKFJlc291cmNlIE93bmVyDQo+IEltcGVyc29uYXRpb24p DQo+IA0KPiAodGhhbmtzIGZvciB0aGUgdHlwbyBjb3JyZWN0aW9uKQ0KPiANCj4gWWVzLCB0aGUg ZXhhbXBsZSBJIHByb3ZpZGVkIGlzIGEgdmVyeSBsaWdodHdlaWdodCBvbmUgd2hpY2ggZG9lcyB0 YWtlIHRoZQ0KPiBmb3JtIG9mIENTUkYsIGJ1dCBpdCBpcyBvbmx5IHRoZSBzaW1wbGVzdCBleGFt cGxlIG9mIGEgZmFtaWx5IG9mIGF1dG9tYXRlZA0KPiBhdXRob3JpemF0aW9uIGZsb3cgYXR0YWNr cy4gSW5kZWVkLCBhIG5vbmNlIChvciBoaWRkZW4gdG9rZW4sIGJvdGggc2VydmUgdGhlDQo+IHNh bWUgcHVycG9zZSBpbiB0aGlzIGNhc2UpIHdvdWxkIGJlIGVub3VnaCBoZXJlLg0KDQpHcmVhdC4g U28gd2UgbmVlZCB0byBhZGQgZXhwbGljaXQgdGV4dCBhYm91dCBwcmV2ZW50aW5nIENTUkYgYXR0 YWNrcyBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4NCg0KPiBJZiB0aGUgY2xpZW50IGlz IG5vdCB1c2VyLWFnZW50IGJhc2VkLCBhIGZ1bGwtZmxlZGdlZCBmb3JnZXJ5IG9mIHRoZSB3aG9s ZQ0KPiBwcm9jZXNzIGlzIHBvc3NpYmxlLCBvbmUgaW4gd2hpY2ggQ09SUyBhbmQgc2FuZGJveGVz IGhhdmUgbm8gbWVhbmluZy4gSW4gYQ0KPiBuYXRpdmUgY2xpZW50LCB1bmxlc3Mgc29tZSBraW5k IG9mIGh1bWFuIHRlc3QgaXMgcGVyZm9ybWVkLCB0aGUgd2hvbGUgZmxvdw0KPiBjb3VsZCBiZSBz cG9vZmVkLg0KDQpDYW4geW91IHByb3ZpZGUgYW5vdGhlciBleGFtcGxlIHdpdGggdGhlIHNhbWUg bGV2ZWwgb2YgZGV0YWlsIGFzIHlvdSBwcm92aWRlZCBiZWxvdz8NCg0KPiBBIENBUFRDSEEgYW5k L29yIHBhc3N3b3JkIGVudHJ5IGFyZSBub3QgYnVsbGV0LXByb29mLA0KPiBidXQgdGhleSBwcm92 aWRlIGEgc3RlZXAgb2JzdGFjbGUgZm9yIHRoZSBhdHRhY2tlci4NCg0KQ0FQVENIQSBhbmQgcGFz c3dvcmQgZW50cnkgYXJlIHR3byBjb21wbGV0ZWx5IGRpZmZlcmVuY2UgbWVhc3VyZXMgYW5kIGFy ZSByYXJlbHkgaW50ZXJjaGFuZ2VhYmxlLiBDQVBUQ0hBIGRvZXMgbm90aGluZyBtb3JlIHRoYW4g aW5jcmVhc2UgdGhlIGxpa2VsaWhvb2QgdGhhdCB0aGUgZW50aXR5IG9uIHRoZSBvdGhlciBzaWRl IGlzIGEgaHVtYW4uIEFueSBhdHRhY2sgcHJldmVudGVkIGJ5IENBUFRDSEEgbXVzdCBiZSBvbmUg aW4gd2hpY2ggYXV0b21hdGlvbiBhbmQgc3BlZWQgYXJlIGNydWNpYWwuIEkgc3RpbGwgZG9uJ3Qg dW5kZXJzdGFuZCB3aGF0IGl0ICpzb2x2ZXMqLg0KDQo+IEFub3RoZXIgb3B0aW9uIHdvdWxkIGJl LA0KPiBmb3IgZXhhbXBsZSwgdG8gZW1haWwgdGhlIHJlc291cmNlIG93bmVyIGFuIE9UUCwgd2l0 aCB0aGUgZm9sbG93aW5nDQo+IG1lc3NhZ2UgIlRoZSBhcHBsaWNhdGlvbiBbLi4uXSByZXF1ZXN0 cyBhY2Nlc3MgdG8gWy4uLl0uIFBsZWFzZSB1c2UgdGhlIG51bWJlcg0KPiBYWFhYIHRvIGFsbG93 IGl0IGFjY2VzcyBldGMuLi4iIChzaW1pbGFyIHRvIEdvb2dsZSdzIGFuZCBGYWNlYm9vaydzIHR3 by1zdGVwDQo+IHNpZ24taW4pLg0KDQpUd28tZmFjdG9yIGF1dGhlbnRpY2F0aW9uIGlzIGdvb2Qs IGJ1dCBjb21wbGV0ZWx5IGltcHJhY3RpY2FsIGZvciBtb3N0IHdlYiBhdXRob3JpemF0aW9uIHNj ZW5hcmlvLiBZb3UgbmVlZCB0byByZW1lbWJlciB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHBhZ2Ug aXMgdXNlZCBmb3IgYm90aCB0aGUgaW5pdGlhbCBncmFudCwgYnV0IGFsc28gZm9yIGRlbGVnYXRl ZCBsb2dpbiAoYnkgZmFyIGEgbW9yZSBmcmVxdWVudCB1c2UpLiBBbiBhY2Nlc3MgdG9rZW4gY2Fu IGJlIGlzc3VlZCBhbG1vc3QgYXV0b21hdGljYWxseSBpZiB0aGUgY2xpZW50IGhhcyBiZWVuIHBy ZXZpb3VzbHkgYXV0aG9yaXplZC4NCg0KPiBUaGUgZmlyc3QgYXR0YWNrIGRlc2NyaWJlZCBpbiBt eSBwcmV2aW91cyBtZXNzYWdlIHRha2VzIHRoZSBmb3JtIG9mIENTUkYsDQo+IHdoaWxlIHRoZSBh Ym92ZSBvbmUgbWF5IGJlIGJ5cGFzc2VkIGJ5IGFuIGF0dGFja2VyIHdpdGggdGhlIGhlbHAgb2Yg c29tZQ0KPiBzb3J0IG9mIGNsaWNramFja2luZyBvciBzaW1pbGFyLiBFdmVudHVhbGx5IHRoaXMg dGhyZWF0IGRlc2NyaXB0aW9uIGlzIGZvciBhIGZhbWlseQ0KPiBvZiBhdHRhY2tzIHdoaWNoIG1p bWljIHRoZSBiZWhhdmlvciBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgaW4gb3JkZXIgdG8gZ2Fpbg0K PiBhY2Nlc3MgdG8gcHJvdGVjdGVkIHJlc291cmNlcywgYW5kIHNvbWUgcG9zc2libGUgY291bnRl cm1lYXN1cmVzLg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyAiZmFtaWx5IG9mIGF0dGFja3Mi Lg0KDQpFSEwNCg0K From barryleiba.mailing.lists@gmail.com Thu Aug 18 10:33:00 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E10821F8BBD for ; Thu, 18 Aug 2011 10:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.895 X-Spam-Level: X-Spam-Status: No, score=-102.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gl98UMpfKcBv for ; Thu, 18 Aug 2011 10:32:59 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E235121F8B8A for ; Thu, 18 Aug 2011 10:32:52 -0700 (PDT) Received: by gwb20 with SMTP id 20so1198087gwb.31 for ; Thu, 18 Aug 2011 10:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mtA45hPw5TV7cDx8V1UmbVDNqijqyleI4zcLPxGdt64=; b=Thp3ip1fLymkCcGf+Sf59iwoUi5zAAy1TSNf6Sp9WQeojaeBke5p0HTPoRYzXTFWI+ V7PjiB3mukd4g+VmanIOp0nYAtGuqgaHRxsb+7zP3NiJebPGB4x0BTwdZtHOS+qD4UeD 89WazfGzhwkeIHuN3RaxFMawKYjRWmP5pV+FU= MIME-Version: 1.0 Received: by 10.146.58.22 with SMTP id g22mr1049861yaa.34.1313688825964; Thu, 18 Aug 2011 10:33:45 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Thu, 18 Aug 2011 10:33:45 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA42@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA42@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 18 Aug 2011 13:33:45 -0400 X-Google-Sender-Auth: 6w-vPJsUnxX6hlevlOUEn3rCrYw Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:33:00 -0000 > I'd like to ask the chairs to open an issue for this. http://trac.tools.ietf.org/wg/oauth/trac/ticket/24 > I didn't realize how hyper sensitive this working group has become that every > proposal being questioned needs a ticket to prove to people that they are not > being dismissed. It's OK: tickets are cheap, and I don't mind... and if it helps people to know that discussions that aren't quickly resolved are being tracked, then that's what the issue tracker is there for. It makes sure things don't get forgotten, and reminds people what to look more closely at in the next doc rev. Barry, as chair From barryleiba.mailing.lists@gmail.com Thu Aug 18 10:47:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A5911E80B3 for ; Thu, 18 Aug 2011 10:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.037 X-Spam-Level: X-Spam-Status: No, score=-103.037 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NItetA338OB for ; Thu, 18 Aug 2011 10:47:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA4711E80C0 for ; Thu, 18 Aug 2011 10:47:20 -0700 (PDT) Received: by ywm21 with SMTP id 21so1759171ywm.31 for ; Thu, 18 Aug 2011 10:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Ce+qKmVjGRRIZTVrOUjfb3mdOnC1U7wUdwg+052lQqc=; b=UVj9TUOLUh2niTZQq3vuVJ3aBW385PgdcSdIIC7xe9JOLEp5Vy1jIsobC2Vty90wFM WeYJI0oetImIDV9DELZhPg6bK83UPFodU69fj0VlnGTZe0N8R7DuI6OBBccmlSUbhNBW ek/Wg/u5dmnPES+f88aOA9eCNxJnKNNwKul5g= MIME-Version: 1.0 Received: by 10.146.58.22 with SMTP id g22mr1067537yaa.34.1313689693536; Thu, 18 Aug 2011 10:48:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Thu, 18 Aug 2011 10:48:13 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 18 Aug 2011 13:48:13 -0400 X-Google-Sender-Auth: 2fo8N5_6x9xN-Lx_xXcIrMnkAP4 Message-ID: From: Barry Leiba To: "oauth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:47:22 -0000 >> Yes, the example I provided is a very lightweight one which does take the >> form of CSRF, but it is only the simplest example of a family of automated >> authorization flow attacks. Indeed, a nonce (or hidden token, both serve the >> same purpose in this case) would be enough here. > > Great. So we need to add explicit text about preventing CSRF attacks at the > authorization endpoint. General comment, not for this issue alone (and not specifically to the folks conversing here): There are a great many things we can say about threats and attacks, which is why we have the threats document by Torsten, et al. I'm generally in favour of putting more security considerations into the base document to describe threats that implementors need to be concerned about, and well-crafted text that the editors can drop in is a good thing. That said, the reason we decided to put "highlights" into the base doc's Security Considerations section, and then refer to the larger document for more details and a more complete threat analysis is that we wanted to strike a balance, keep the base doc for protocol details, and leave the threat descriptions in the base doc as general threat *classes*. As we debate the various attack descriptions and mitigations that we might like to add, please keep that balance in mind, and think carefully about whether the details of *this specific* attack should go into this document, or whether we just need to cover the general class of threats here and put the details of this attack into draft-ietf-oauth-v2-threatmodel. Otherwise, we might eventually merge the entire threat analysis document into the base, one paragraph at a time. Barry, as chair From barryleiba.mailing.lists@gmail.com Thu Aug 18 10:51:45 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA2121F893C for ; Thu, 18 Aug 2011 10:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.036 X-Spam-Level: X-Spam-Status: No, score=-103.036 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9b-CMut8DTG for ; Thu, 18 Aug 2011 10:51:43 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD43921F89A1 for ; Thu, 18 Aug 2011 10:51:38 -0700 (PDT) Received: by yxj17 with SMTP id 17so327266yxj.31 for ; Thu, 18 Aug 2011 10:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zPge0ZJMUbNMX8NV3Z2wMQL85w5QCZX8I3SQkoeUaDw=; b=fwjZZeGJZn9hrBt+rtIKMDuJz66I/mzZSdMoNqH2zDwhMXD0XHcLduLO+Ba5ZTeUIx gEBXj9YG+9hzU8NNen/rHflCY2weuvBj+H5ga4OIAOrJqIv7VgSuFturV+E69rbev3b7 Gb24nqF1GA98qT9dkxKvtRF553TGKRKQojsSI= MIME-Version: 1.0 Received: by 10.236.200.195 with SMTP id z43mr5989845yhn.127.1313689953223; Thu, 18 Aug 2011 10:52:33 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Thu, 18 Aug 2011 10:52:33 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128B5BB96C@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1128B5BB96C@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 18 Aug 2011 13:52:33 -0400 X-Google-Sender-Auth: uV0JNZbBEmTtjglS0bIrO1oKS9c Message-ID: From: Barry Leiba To: "Manger, James H" , Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:51:45 -0000 The text for the answer below came from Mike, as the chairs asked for at the IETF 81 meeting. Mike, do you have a response to James's issue? Can we give a better response here? Should the bearer doc specify %-encoding explicitly? Barry On Thu, Aug 18, 2011 at 7:15 AM, Manger, James H wrote: >>> * =A0 =A0For bearer tokens: clarification whether the non-support of pe= rcent > encoding for scope-v element of WWW-Authenticate Response Header Field > grammar is intentional. > >> Answer: >> In the bearer token document (Section 2.4 of >> draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header >> Field"), the "scope-v" element is unambiguously defined to allow a >> specific set of characters. =A0That set of characters does permit, but >> does not mandate, support for percent-encoding of characters. > > > This is a poor answer. > A client app receiving a scope value in an "WWW-Authenticate: Bearer scop= e=3D..." response will either compare it with strings from a OAuth2 JSON-en= coded token response, or copy it into a request to an authorization server.= It needs to know if it needs to %-decode the value or not before doing the= se things. Clients cannot be expected to behave differently for different s= ervers in this respect. > > OAuth2 core (implicitly) allows a scope to use any Unicode char except sp= ace (as space is used as a delimiter). > Bearer restricts scopes to 93 ASCII chars. > OMA are asking if this is intentional. > > If we really want to restrict scope values it would be better done in OAu= th2 core. > If we don't want to restrict values then the bearer spec needs to be able= to handle any possible scope value by defining an escaping mechanism for s= cope-v (or by not having a scope parameter). > > -- > James Manger From nivstein@gmail.com Thu Aug 18 11:07:35 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8061421F8AF9 for ; Thu, 18 Aug 2011 11:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3etkKktJzzi for ; Thu, 18 Aug 2011 11:07:35 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2E5A21F8AFE for ; Thu, 18 Aug 2011 11:07:34 -0700 (PDT) Received: by vxi29 with SMTP id 29so2391141vxi.31 for ; Thu, 18 Aug 2011 11:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=95U14fOADHISdPd0I0zCB9DpCkCyAcbu9XCg/u3Aa6o=; b=v9yysKxT/KgrIG623dXSH40L3vDUxPd9re2mZhtrjPcVZ7dyu4l4wARYmNA/d2vI5L ZGrpfIGdaAHPciiOlVAvnXqOzG2N/6t4ZRJXUDTKrYRI9yBYCJv+UjGMB+9ycEU4farX 5lJEoDzE0+ZGyE9w2TsLczkI3RRnUL2UF7aDo= Received: by 10.52.72.116 with SMTP id c20mr1075674vdv.188.1313690909124; Thu, 18 Aug 2011 11:08:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.170 with HTTP; Thu, 18 Aug 2011 11:08:09 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Niv Steingarten Date: Thu, 18 Aug 2011 21:08:09 +0300 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:07:35 -0000 On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav wrot= e: > > >> -----Original Message----- >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> Sent: Thursday, August 18, 2011 10:16 AM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> > Can you provide another example with the same level of detail as you prov= ided below? The malicious client sends a request to the authorization endpoint with the appropriate parameters, and in return receives the markup of the web-page which should be displayed to the user in order to get consent. In addition, since the request is launched not via a sandboxed user-agent, the client also has access to any 'Set-Cookie' HTTP headers. Instead of displaying the page to the user, the client extracts the web-form data (including the hidden nonce/token) which would be submitted when 'Allow' is clicked. It then forges the appropriate POST request with the cookies, form data and referrer, and dispatches it, to finally receive an access token/authorization code in the redirection. > CAPTCHA and password entry are two completely difference measures and are= rarely interchangeable. CAPTCHA does nothing more than increase the likeli= hood that the entity on the other side is a human. Any attack prevented by = CAPTCHA must be one in which automation and speed are crucial. I still don'= t understand what it *solves*. CAPTCHAs are used for human testing and passwords for identity testing, but in this case they both serve the same purpose of decreasing the likelihood that the flow is automated. > Two-factor authentication is good, but completely impractical for most we= b authorization scenario. You need to remember that the authorization page = is used for both the initial grant, but also for delegated login (by far a = more frequent use). An access token can be issued almost automatically if t= he client has been previously authorized. You're right, sometimes there's a trade-off between better security and user experience. I think it should eventually be up to the implementer to choose what is right for their applications' security requirements. I think it is in the scope of the specification to bring this issue up for developers to consider. > I don't understand this "family of attacks". I don't know how to put it any differently than I already have; simply a class of attacks (the three scenarios described in this thread are examples thereof) in which a malicious client takes the role of both the client and the resource owner. -- Niv From wmills@yahoo-inc.com Thu Aug 18 11:08:48 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6148521F8B01 for ; Thu, 18 Aug 2011 11:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.314 X-Spam-Level: X-Spam-Status: No, score=-17.314 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDD9qL2+F8DS for ; Thu, 18 Aug 2011 11:08:47 -0700 (PDT) Received: from nm14-vm0.bullet.mail.sp2.yahoo.com (nm14-vm0.bullet.mail.sp2.yahoo.com [98.139.91.246]) by ietfa.amsl.com (Postfix) with SMTP id 1FA5121F8AF9 for ; Thu, 18 Aug 2011 11:08:47 -0700 (PDT) Received: from [98.139.91.68] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 18 Aug 2011 18:09:41 -0000 Received: from [98.139.91.24] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 18 Aug 2011 18:09:41 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 18 Aug 2011 18:09:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 761637.10751.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 10083 invoked by uid 60001); 18 Aug 2011 18:09:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313690981; bh=/PMNUPMberi487p0L/vHgMzjK0WZhFEoaVTN/j6bE24=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=XmtrsiWaf9n+cg0vsLVh4sb7BJG7cRAwg0Bk/gOrOgiVJXvkwh4PkkhCChFg/k6SNVab1R+onlKVB1O3nR1HNs3ciDMad1IEs6LfH7mjJU6da8u/rBa2rb+dS6b2TzwxisGI9UCGkNrc66ih9YAGK35/J0HVJnY28sMwukmrcBc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=iBc4WivFqxQOjrRzOapFM4ck6xM+ejsjjJXTe4bP58VsiE+WVpmqCb6jRXZaGra3ZHoxe/COvskIPU6dKF561zf3/gUC8/jtoOHMZicTNBozcWJvZFkuIYF3qHtAO/s6fOb9zu5BJgJCDAfg+8+pW3W/XuZEIKIKCanmhKXkiUY=; X-YMail-OSG: WH0wWT8VM1khud8doPRXFc8n5kkyUkYk1kL0MVrBa9PfdEq WBKL5KkWxivu9Xlhox4z0jHXJCIEBIiLCYT5YTnVAIsZFhQr1EVi._EIOKvX T410vpeMDqCjIgg4K0veOzhtOQvAfbY5o6uViXYOEEAEpRCbXx5kbUA0zdHI HsojKjiueVcOZ0XMWHEuFBoHEAaaXX0FR_xW6cQtGNFVySnIgDN3OllFsPge lf1HdywIp1g.YrHlAOwB7ROqSsrbhSAMz9FHN5Nc2n59F341J5QyFMmiFKvd 0vHGkeNASEORUEcGBhFooLsh9kkHf8SufHlKWovnarO7mtH0g2dlZshrt96z a565dXohGbUK4iSBJjv1ejXXzprNNSHhDT36X6wyvOcdC4ZL_5CFYZvVlyRv ZcqInyiJ19ZyaU5KUkzeF2sX6GkakKU.KTvQ07OdQ79Jpa7w- Received: from [209.131.62.113] by web31805.mail.mud.yahoo.com via HTTP; Thu, 18 Aug 2011 11:09:41 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <255B9BB34FB7D647A506DC292726F6E1128B5BB96C@WSMSG3153V.srv.dir.telstra.com> Message-ID: <1313690981.82232.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Thu, 18 Aug 2011 11:09:41 -0700 (PDT) From: "William J. Mills" To: "Manger, James H" , Barry Leiba , "oauth@ietf.org" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128B5BB96C@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-707943344-1313690981=:82232" Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:08:48 -0000 --0-707943344-1313690981=:82232 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable +1 for Jame's feedback here.=A0 We need to solve this.=0A=0A=0A=0A_________= _______________________=0AFrom: "Manger, James H" =0ATo: Barry Leiba ; "oauth@ietf.org" =0ASent: Thursday, August 18, 2011 4:15 AM=0ASubject: Re: [OAUT= H-WG] OMA Liaison Has Arrived! scope-v=0A=0A>> *=A0=A0=A0 For bearer tokens= : clarification whether the non-support of percent=0Aencoding for scope-v e= lement of WWW-Authenticate Response Header Field=0Agrammar is intentional.= =0A=0A> Answer:=0A> In the bearer token document (Section 2.4 of=0A> draft-= ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header=0A> Field"),= the "scope-v" element is unambiguously defined to allow a=0A> specific set= of characters.=A0 That set of characters does permit, but=0A> does not man= date, support for percent-encoding of characters.=0A=0A=0AThis is a poor an= swer.=0AA client app receiving a scope value in an "WWW-Authenticate: Beare= r scope=3D..." response will either compare it with strings from a OAuth2 J= SON-encoded token response, or copy it into a request to an authorization s= erver. It needs to know if it needs to %-decode the value or not before doi= ng these things. Clients cannot be expected to behave differently for diffe= rent servers in this respect.=0A=0AOAuth2 core (implicitly) allows a scope = to use any Unicode char except space (as space is used as a delimiter).=0AB= earer restricts scopes to 93 ASCII chars.=0AOMA are asking if this is inten= tional.=0A=0AIf we really want to restrict scope values it would be better = done in OAuth2 core.=0AIf we don't want to restrict values then the bearer = spec needs to be able to handle any possible scope value by defining an esc= aping mechanism for scope-v (or by not having a scope parameter).=0A=0A--= =0AJames Manger=0A=0A_______________________________________________=0AOAut= h mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oau= th --0-707943344-1313690981=:82232 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
+1 for Jame's feedback here.  We need to solve this.

From: "Ma= nger, James H" <James.H.Manger@team.telstra.com>
To: Barry Leiba <barryleiba@computer.org= >; "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, August 18, 2011 4:15 AM
Subject: Re: [OAUTH-WG] OMA Liaison= Has Arrived! scope-v

>> *    For bearer= tokens: clarification whether the non-support of percent
encoding for scope-v e= lement of WWW-Authenticate Response Header Field
grammar is intentional.=

> Answer:
> In the bearer token document (Section 2.4 of> draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header=
> Field"), the "scope-v" element is unambiguously defined to allow a=
> specific set of characters.  That set of characters does perm= it, but
> does not mandate, support for percent-encoding of character= s.


This is a poor answer.
A client app receiving a scope valu= e in an "WWW-Authenticate: Bearer scope=3D..." response will either compare= it with strings from a OAuth2 JSON-encoded token response, or copy it into= a request to an authorization server. It needs to know if it needs to %-de= code the value or not before doing these things. Clients cannot be expected= to behave differently for different servers in this respect.

OAuth2 core (implicitly) allows a scope to use any Unicode= char except space (as space is used as a delimiter).
Bearer restricts s= copes to 93 ASCII chars.
OMA are asking if this is intentional.

I= f we really want to restrict scope values it would be better done in OAuth2= core.
If we don't want to restrict values then the bearer spec needs to= be able to handle any possible scope value by defining an escaping mechani= sm for scope-v (or by not having a scope parameter).

--
James Man= ger

_______________________________________________
OAuth mailing= list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
<= br>
--0-707943344-1313690981=:82232-- From eran@hueniverse.com Thu Aug 18 11:18:13 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D347921F8B92 for ; Thu, 18 Aug 2011 11:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzUPI6Of6jk7 for ; Thu, 18 Aug 2011 11:18:12 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A987321F8B95 for ; Thu, 18 Aug 2011 11:18:12 -0700 (PDT) Received: (qmail 13195 invoked from network); 18 Aug 2011 18:19:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 18:19:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 18 Aug 2011 11:19:02 -0700 From: Eran Hammer-Lahav To: Niv Steingarten Date: Thu, 18 Aug 2011 11:17:46 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: Acxd0diNWtmi1qd8T7mjWfCMXAsiEwAAALcg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:18:13 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTml2IFN0ZWluZ2FydGVu IFttYWlsdG86bml2c3RlaW5AZ21haWwuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE4 LCAyMDExIDExOjA4IEFNDQo+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiBDYzogVG9yc3RlbiBM b2RkZXJzdGVkdDsgb2F1dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRHJh ZnQgMjAgbGFzdCBjYWxsIGNvbW1lbnQgKFJlc291cmNlIE93bmVyDQo+IEltcGVyc29uYXRpb24p DQo+IA0KPiBPbiBUaHUsIEF1ZyAxOCwgMjAxMSBhdCAyMDozMSwgRXJhbiBIYW1tZXItTGFoYXYg PGVyYW5AaHVlbml2ZXJzZS5jb20+DQo+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogTml2IFN0ZWluZ2FydGVuIFttYWlsdG86bml2 c3RlaW5AZ21haWwuY29tXQ0KPiA+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE4LCAyMDExIDEw OjE2IEFNDQo+ID4+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiA+PiBDYzogVG9yc3RlbiBMb2Rk ZXJzdGVkdDsgb2F1dGhAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRHJh ZnQgMjAgbGFzdCBjYWxsIGNvbW1lbnQgKFJlc291cmNlIE93bmVyDQo+ID4+IEltcGVyc29uYXRp b24pDQo+ID4+DQo+ID4gQ2FuIHlvdSBwcm92aWRlIGFub3RoZXIgZXhhbXBsZSB3aXRoIHRoZSBz YW1lIGxldmVsIG9mIGRldGFpbCBhcyB5b3UNCj4gcHJvdmlkZWQgYmVsb3c/DQo+IA0KPiBUaGUg bWFsaWNpb3VzIGNsaWVudCBzZW5kcyBhIHJlcXVlc3QgdG8gdGhlIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgd2l0aCB0aGUNCj4gYXBwcm9wcmlhdGUgcGFyYW1ldGVycywgYW5kIGluIHJldHVybiBy ZWNlaXZlcyB0aGUgbWFya3VwIG9mIHRoZSB3ZWItcGFnZQ0KPiB3aGljaCBzaG91bGQgYmUgZGlz cGxheWVkIHRvIHRoZSB1c2VyIGluIG9yZGVyIHRvIGdldCBjb25zZW50LiBJbiBhZGRpdGlvbiwN Cj4gc2luY2UgdGhlIHJlcXVlc3QgaXMgbGF1bmNoZWQgbm90IHZpYSBhIHNhbmRib3hlZCB1c2Vy LWFnZW50LCB0aGUgY2xpZW50IGFsc28NCj4gaGFzIGFjY2VzcyB0byBhbnkgJ1NldC1Db29raWUn DQo+IEhUVFAgaGVhZGVycy4NCj4gDQo+IEluc3RlYWQgb2YgZGlzcGxheWluZyB0aGUgcGFnZSB0 byB0aGUgdXNlciwgdGhlIGNsaWVudCBleHRyYWN0cyB0aGUgd2ViLWZvcm0NCj4gZGF0YSAoaW5j bHVkaW5nIHRoZSBoaWRkZW4gbm9uY2UvdG9rZW4pIHdoaWNoIHdvdWxkIGJlIHN1Ym1pdHRlZCB3 aGVuDQo+ICdBbGxvdycgaXMgY2xpY2tlZC4gSXQgdGhlbiBmb3JnZXMgdGhlIGFwcHJvcHJpYXRl IFBPU1QgcmVxdWVzdCB3aXRoIHRoZQ0KPiBjb29raWVzLCBmb3JtIGRhdGEgYW5kIHJlZmVycmVy LCBhbmQgZGlzcGF0Y2hlcyBpdCwNCg0KU0NFTkUgTUlTU0lORyBbMV0NCg0KPiB0byBmaW5hbGx5 IHJlY2VpdmUgYW4gYWNjZXNzIHRva2VuL2F1dGhvcml6YXRpb24gY29kZSBpbiB0aGUgcmVkaXJl Y3Rpb24uDQoNCllvdSBza2lwcGVkIHRoZSBiZXN0IHBhcnQhDQoNCldoYXQgZG8geW91IG1lYW4g YnkgImRpc3BhdGNoZXMgaXQiPyBIb3cgaXMgdGhlIHJlc291cmNlIG93bmVyIHRyaWNrZWQgb3Ig YWJ1c2VkIHRvIGdyYW50IGF1dGhvcml6YXRpb24gdW5rbm93aW5nbHk/IEkgdW5kZXJzdGFuZCBo b3cgeW91ciBwcm9wb3NhbCAiZml4ZXMiIHRoZSBmaXJzdCBoYWxmLCBidXQgbm90IHdoYXQga2lu ZCBvZiBhdHRhY2sgaXMgaGFwcGVuaW5nIGluIHRoZSBzZWNvbmQgaGFsZi4NCg0KRUhMDQoNClsx XSBodHRwOi8vd3d3LmlicmFzLmRrL21vbnR5cHl0aG9uL2VwaXNvZGUzNC5odG0NCg0K From barryleiba.mailing.lists@gmail.com Thu Aug 18 11:26:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72C511E8094 for ; Thu, 18 Aug 2011 11:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.036 X-Spam-Level: X-Spam-Status: No, score=-103.036 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp3daTrP2Jm3 for ; Thu, 18 Aug 2011 11:26:07 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1D8F11E8087 for ; Thu, 18 Aug 2011 11:26:06 -0700 (PDT) Received: by yxj17 with SMTP id 17so354835yxj.31 for ; Thu, 18 Aug 2011 11:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=b+vrwEFFL1FbwBbtMx+TDSm1XuJ4WbDPiDNXaa4rcAc=; b=C3tt7F8+FkOzzLbBCfN0RzR8z+QwLXfNSuP8+98Gn7GiHZW191YwnZYDNIhL/meiTr N7CHnH2xgK1ZoHzAMq/pr9Qjwi7Inw1g17EzxNdCKMemRoMoCmqv/VGCJi9pBLjvUBmU vQPoa8JglT8az9fr6bl60IHeE66eAYBs6CZ9s= MIME-Version: 1.0 Received: by 10.147.87.18 with SMTP id p18mr1118611yal.24.1313692019707; Thu, 18 Aug 2011 11:26:59 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Thu, 18 Aug 2011 11:26:59 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA51@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739434A80B587@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72345028F2D75E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <63366D5A116E514AA4A9872D3C533539570852FDCA@QEO40072.de.t-online.corp> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA51@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 18 Aug 2011 14:26:59 -0400 X-Google-Sender-Auth: 5pjTdEvK_Pwx1L20-rtF1m6Z-G4 Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:26:07 -0000 > Chairs - please open an issue for this: "Clarifying reference to refresh tokens > in section 1.4.3 of -20". http://trac.tools.ietf.org/wg/oauth/trac/ticket/25 b From eran@hueniverse.com Thu Aug 18 11:32:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5E321F86AC for ; Thu, 18 Aug 2011 11:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBP5LRHCXbS4 for ; Thu, 18 Aug 2011 11:32:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 5BAE621F86AA for ; Thu, 18 Aug 2011 11:32:07 -0700 (PDT) Received: (qmail 15037 invoked from network); 18 Aug 2011 18:33:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 18:33:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 18 Aug 2011 11:33:01 -0700 From: Eran Hammer-Lahav To: Rob Richards , Peter Saint-Andre Date: Thu, 18 Aug 2011 11:31:44 -0700 Thread-Topic: [OAUTH-WG] TLS 1.2 Thread-Index: AcxcU+p2zNZTfLk8R/uNcaumqDWtvgBgJs0A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E458571.1070500@cdatazone.org> <4E4AC6BA.2090007@cdatazone.org> <1313524116.13419.81.camel@ground> <90C41DD21FB7C64BB94121FBBC2E7234502498D1B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E4ACD53.2010404@stpeter.im> <4E4AD454.9040302@cdatazone.org> In-Reply-To: <4E4AD454.9040302@cdatazone.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] TLS 1.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:32:08 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvYiBSaWNoYXJkcyBbbWFp bHRvOnJyaWNoYXJkc0BjZGF0YXpvbmUub3JnXQ0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTYs IDIwMTEgMTozNCBQTQ0KDQo+IFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgc3VwcG9y dCBUTFMgMS4yIGFzIGRlZmluZWQgaW4gW1JGQzUyNDZdIGJ1dA0KPiBhdCBhIG1pbmltdW0gTVVT VCBzdXBwb3J0IFRMUyAxLjAgYXMgZGVmaW5lZCBpbiBbUkZDMjI0Nl0sIGFuZCBNQVkNCj4gc3Vw cG9ydCBhZGRpdGlvbmFsIHRyYW5zcG9ydC1sYXllciBtZWNoYW5pc21zIG1lZXRpbmcgaXRzIHNl Y3VyaXR5DQo+IHJlcXVpcmVtZW50cy4NCg0KSG93IGFib3V0Og0KDQpUaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgTVVTVCBzdXBwb3J0IFRMUyAxLjAgKFtSRkMyMjQ2XSksIFNIT1VMRCBzdXBwb3J0 IFRMUyAxLjIgKFtSRkM1MjQ2XSkgYW5kIGl0cyBmdXR1cmUgcmVwbGFjZW1lbnRzLCBhbmQgTUFZ IHN1cHBvcnQgYWRkaXRpb25hbCB0cmFuc3BvcnQtbGF5ZXIgbWVjaGFuaXNtcyBtZWV0aW5nIGl0 cyBzZWN1cml0eSByZXF1aXJlbWVudHMuDQoNCkVITA0KDQo= From nivstein@gmail.com Thu Aug 18 12:11:26 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E1721F8B8E for ; Thu, 18 Aug 2011 12:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fph0tdMq6AB8 for ; Thu, 18 Aug 2011 12:11:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 723BD21F8B8C for ; Thu, 18 Aug 2011 12:11:25 -0700 (PDT) Received: by vxi29 with SMTP id 29so2452023vxi.31 for ; Thu, 18 Aug 2011 12:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=31PU5G65o5rAX955ICIEO2q6sn8ydNGQz8YQWyZhvZ8=; b=WNH/gApZmAZ6W0xyIpBgOShtBk2wY9HY7ORhXPh1lHeHZT6hYWLJ6nw/k3+oXqUKOp s8cTMGvFZP70me+ZbkyhgNVLbRtfv9VK0t1VZpa4aR+FnUcP+bCR+vqvr8P65+kGPSH8 K76OKeyx06TkZS81ccROZEscwwuwbAa89dep0= Received: by 10.52.72.116 with SMTP id c20mr1159423vdv.188.1313694739106; Thu, 18 Aug 2011 12:12:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.170 with HTTP; Thu, 18 Aug 2011 12:11:59 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Niv Steingarten Date: Thu, 18 Aug 2011 22:11:59 +0300 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 19:11:26 -0000 On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> Sent: Thursday, August 18, 2011 11:08 AM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav >> wrote: >> > >> > >> >> -----Original Message----- >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> >> Sent: Thursday, August 18, 2011 10:16 AM >> >> To: Eran Hammer-Lahav >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> >> Impersonation) >> >> >> > Can you provide another example with the same level of detail as you >> provided below? >> >> The malicious client sends a request to the authorization endpoint with the >> appropriate parameters, and in return receives the markup of the web-page >> which should be displayed to the user in order to get consent. In addition, >> since the request is launched not via a sandboxed user-agent, the client also >> has access to any 'Set-Cookie' >> HTTP headers. >> >> Instead of displaying the page to the user, the client extracts the web-form >> data (including the hidden nonce/token) which would be submitted when >> 'Allow' is clicked. It then forges the appropriate POST request with the >> cookies, form data and referrer, and dispatches it, > > SCENE MISSING [1] > >> to finally receive an access token/authorization code in the redirection. > > You skipped the best part! > > What do you mean by "dispatches it"? How is the resource owner tricked or abused to grant authorization unknowingly? I understand how your proposal "fixes" the first half, but not what kind of attack is happening in the second half. > I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request and launch it using the same HTTP framework/WebKit, simulating the "Allow" button. > > [1] http://www.ibras.dk/montypython/episode34.htm > +1 for more Monty Python references. -- Niv From eran@hueniverse.com Thu Aug 18 12:21:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEF111E80A7 for ; Thu, 18 Aug 2011 12:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxfFxv7cK4IG for ; Thu, 18 Aug 2011 12:21:20 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7618A11E808C for ; Thu, 18 Aug 2011 12:21:16 -0700 (PDT) Received: (qmail 31065 invoked from network); 18 Aug 2011 19:21:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 19:21:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 18 Aug 2011 12:21:08 -0700 From: Eran Hammer-Lahav To: Niv Steingarten Date: Thu, 18 Aug 2011 12:19:48 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: Acxd2sFY18VWejdmTQevMrVmAe/ghAAAEwug Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 19:21:22 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTml2IFN0ZWluZ2FydGVu IFttYWlsdG86bml2c3RlaW5AZ21haWwuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE4 LCAyMDExIDEyOjEyIFBNDQo+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiBDYzogVG9yc3RlbiBM b2RkZXJzdGVkdDsgb2F1dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRHJh ZnQgMjAgbGFzdCBjYWxsIGNvbW1lbnQgKFJlc291cmNlIE93bmVyDQo+IEltcGVyc29uYXRpb24p DQo+IA0KPiBPbiBUaHUsIEF1ZyAxOCwgMjAxMSBhdCAyMToxNywgRXJhbiBIYW1tZXItTGFoYXYg PGVyYW5AaHVlbml2ZXJzZS5jb20+DQo+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogTml2IFN0ZWluZ2FydGVuIFttYWlsdG86bml2 c3RlaW5AZ21haWwuY29tXQ0KPiA+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE4LCAyMDExIDEx OjA4IEFNDQo+ID4+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiA+PiBDYzogVG9yc3RlbiBMb2Rk ZXJzdGVkdDsgb2F1dGhAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRHJh ZnQgMjAgbGFzdCBjYWxsIGNvbW1lbnQgKFJlc291cmNlIE93bmVyDQo+ID4+IEltcGVyc29uYXRp b24pDQo+ID4+DQo+ID4+IE9uIFRodSwgQXVnIDE4LCAyMDExIGF0IDIwOjMxLCBFcmFuIEhhbW1l ci1MYWhhdg0KPiA+PiA8ZXJhbkBodWVuaXZlcnNlLmNvbT4NCj4gPj4gd3JvdGU6DQo+ID4+ID4N Cj4gPj4gPg0KPiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+PiBGcm9t OiBOaXYgU3RlaW5nYXJ0ZW4gW21haWx0bzpuaXZzdGVpbkBnbWFpbC5jb21dDQo+ID4+ID4+IFNl bnQ6IFRodXJzZGF5LCBBdWd1c3QgMTgsIDIwMTEgMTA6MTYgQU0NCj4gPj4gPj4gVG86IEVyYW4g SGFtbWVyLUxhaGF2DQo+ID4+ID4+IENjOiBUb3JzdGVuIExvZGRlcnN0ZWR0OyBvYXV0aEBpZXRm Lm9yZw0KPiA+PiA+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBEcmFmdCAyMCBsYXN0IGNhbGwg Y29tbWVudCAoUmVzb3VyY2UgT3duZXINCj4gPj4gPj4gSW1wZXJzb25hdGlvbikNCj4gPj4gPj4N Cj4gPj4gPiBDYW4geW91IHByb3ZpZGUgYW5vdGhlciBleGFtcGxlIHdpdGggdGhlIHNhbWUgbGV2 ZWwgb2YgZGV0YWlsIGFzDQo+ID4+ID4geW91DQo+ID4+IHByb3ZpZGVkIGJlbG93Pw0KPiA+Pg0K PiA+PiBUaGUgbWFsaWNpb3VzIGNsaWVudCBzZW5kcyBhIHJlcXVlc3QgdG8gdGhlIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQNCj4gPj4gd2l0aCB0aGUgYXBwcm9wcmlhdGUgcGFyYW1ldGVycywgYW5k IGluIHJldHVybiByZWNlaXZlcyB0aGUgbWFya3VwIG9mDQo+ID4+IHRoZSB3ZWItcGFnZSB3aGlj aCBzaG91bGQgYmUgZGlzcGxheWVkIHRvIHRoZSB1c2VyIGluIG9yZGVyIHRvIGdldA0KPiA+PiBj b25zZW50LiBJbiBhZGRpdGlvbiwgc2luY2UgdGhlIHJlcXVlc3QgaXMgbGF1bmNoZWQgbm90IHZp YSBhDQo+ID4+IHNhbmRib3hlZCB1c2VyLWFnZW50LCB0aGUgY2xpZW50IGFsc28gaGFzIGFjY2Vz cyB0byBhbnkgJ1NldC1Db29raWUnDQo+ID4+IEhUVFAgaGVhZGVycy4NCj4gPj4NCj4gPj4gSW5z dGVhZCBvZiBkaXNwbGF5aW5nIHRoZSBwYWdlIHRvIHRoZSB1c2VyLCB0aGUgY2xpZW50IGV4dHJh Y3RzIHRoZQ0KPiA+PiB3ZWItZm9ybSBkYXRhIChpbmNsdWRpbmcgdGhlIGhpZGRlbiBub25jZS90 b2tlbikgd2hpY2ggd291bGQgYmUNCj4gPj4gc3VibWl0dGVkIHdoZW4gJ0FsbG93JyBpcyBjbGlj a2VkLiBJdCB0aGVuIGZvcmdlcyB0aGUgYXBwcm9wcmlhdGUNCj4gPj4gUE9TVCByZXF1ZXN0IHdp dGggdGhlIGNvb2tpZXMsIGZvcm0gZGF0YSBhbmQgcmVmZXJyZXIsIGFuZCBkaXNwYXRjaGVzDQo+ ID4+IGl0LA0KPiA+DQo+ID4gU0NFTkUgTUlTU0lORyBbMV0NCj4gPg0KPiA+PiB0byBmaW5hbGx5 IHJlY2VpdmUgYW4gYWNjZXNzIHRva2VuL2F1dGhvcml6YXRpb24gY29kZSBpbiB0aGUgcmVkaXJl Y3Rpb24uDQo+ID4NCj4gPiBZb3Ugc2tpcHBlZCB0aGUgYmVzdCBwYXJ0IQ0KPiA+DQo+ID4gV2hh dCBkbyB5b3UgbWVhbiBieSAiZGlzcGF0Y2hlcyBpdCI/IEhvdyBpcyB0aGUgcmVzb3VyY2Ugb3du ZXIgdHJpY2tlZA0KPiBvciBhYnVzZWQgdG8gZ3JhbnQgYXV0aG9yaXphdGlvbiB1bmtub3dpbmds eT8gSSB1bmRlcnN0YW5kIGhvdyB5b3VyDQo+IHByb3Bvc2FsICJmaXhlcyIgdGhlIGZpcnN0IGhh bGYsIGJ1dCBub3Qgd2hhdCBraW5kIG9mIGF0dGFjayBpcyBoYXBwZW5pbmcgaW4gdGhlDQo+IHNl Y29uZCBoYWxmLg0KPiA+DQo+IA0KPiBJIG1pZ2h0IGhhdmUgYWNjaWRlbnRhbGx5IHNraXBwZWQg dGhlIHBhcnQgd2hlcmUgdGhlIHVzZXIgaXMgYWxyZWFkeSBsb2dnZWQgaW4NCj4gYXQgdGhlIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQsIHNvIG5vIGxvZy1pbiBpcyByZXF1aXJlZCBidXQgcmF0aGVy IGp1c3QNCj4gYWxsb3dpbmcvZGVueWluZyBhY2Nlc3MgKGNvcnJlY3Rpb246IHRoZSBmaXJzdCBy ZXF1ZXN0IGlzIHNlbnQgdXNpbmcgYW4gSFRUUA0KPiBmcmFtZXdvcmsvV2ViS2l0LCBzbyBubyBh Y2Nlc3MgdG8gY29va2llcykuIE9uY2UgaXQgZXh0cmFjdHMgdGhlIGRhdGEgZnJvbQ0KPiB0aGUg d2ViLWZvcm0sIHRoZSBjbGllbnQgaGFzIGFsbCB0aGUgaW5mb3JtYXRpb24gaXQgbmVlZHMgaW4g b3JkZXIgdG8gY3JlYXRlIGFuDQo+IEhUVFAgcmVxdWVzdCANCg0KTm8gLSB0aGUgYXR0YWNrZXIg ZG9lcyBub3QgaGF2ZSBhY2Nlc3MgdG8gdGhlIHNlc3Npb24gY29va2llLiBJdCBzdGlsbCBuZWVk cyB0byBmaW5kIGEgd2F5IHRvIG1ha2UgYSBDU1MgY2FsbC4NCg0KPiBhbmQgbGF1bmNoIGl0IHVz aW5nIHRoZSBzYW1lIEhUVFAgZnJhbWV3b3JrL1dlYktpdCwNCj4gc2ltdWxhdGluZyB0aGUgIkFs bG93IiBidXR0b24uDQoNClRoaXMgaXMgc3RpbGwganVzdCBhIENTUkYgYXR0YWNrLg0KDQpJbiBv cmRlciB0byBhdXRvbWF0ZSB0aGUgYXBwcm92YWwgYWN0aW9uLCB0aGV5IGF0dGFja2VyIGhhcyB0 byBnZXQgdGhlIHVzZXItYWdlbnQgKGVtYmVkZGVkIG9yIG5vdCkgdG8gbWFrZSBhIGNyb3NzIHNp dGUgcmVxdWVzdCB3aGljaCB3aWxsIGluY2x1ZGUgc29tZSBzZXNzaW9uIHN0YXRlIChjb29raWVz IG9yIG90aGVyd2lzZSkuIElmIHRoZSBhdXRob3JpemF0aW9uIHBhZ2UgaXMgQ1NSRiBwcm90ZWN0 ZWQsIHRoZXkgYXR0YWNrZXIgd2lsbCBub3QgYmUgYWJsZSB0byBjb25zdHJ1Y3Qgc3VjaCBhIGxp bmsuDQoNClRoZSBuYXR1cmUgb2YgdGhlIGNsaWVudCBkb2VzIG5vdCBtYXR0ZXIuIEluIGVpdGhl ciBjYXNlLCB0aGUgY2xpZW50IGhhcyB0byBnYWluIGFjY2VzcyBzb21laG93IHRvIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBzdGF0ZSBzdG9yZWQgaW4gdGhlIGJyb3dzZXIuDQoNCkVITA0KDQo= From wmills@yahoo-inc.com Thu Aug 18 12:25:54 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F29111E808C for ; Thu, 18 Aug 2011 12:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.332 X-Spam-Level: X-Spam-Status: No, score=-17.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJa2J1XGwDBP for ; Thu, 18 Aug 2011 12:25:52 -0700 (PDT) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by ietfa.amsl.com (Postfix) with SMTP id D784921F8BA7 for ; Thu, 18 Aug 2011 12:25:52 -0700 (PDT) Received: from [98.139.91.62] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 18 Aug 2011 19:26:47 -0000 Received: from [98.139.91.56] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 18 Aug 2011 19:26:47 -0000 Received: from [127.0.0.1] by omp1056.mail.sp2.yahoo.com with NNFMP; 18 Aug 2011 19:26:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 585784.73664.bm@omp1056.mail.sp2.yahoo.com Received: (qmail 30461 invoked by uid 60001); 18 Aug 2011 19:26:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313695606; bh=CmdEieAdjNV/Na55VBUsOowBACC7+gNpjxsRPl2HtaE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DZwKg7r6XuAy34VvFBY8u5+Uta0C2UHP2cweRsoalTd9asZif3x9J2/dpltgqRNrqPnvOdBqcqIdxvMmO0QNO7ZTLFxbhZbh6U2aw3Wif59bquiuIHxrvLXTm+FuUENRSgEkZhTeNIZP5uRpkS8YTQ+l1DAli3H7JF0T42wf0cE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tOwqs095C2CCTQg5jPXdz9XK94P2lYzGRil3WueF2OC2AZXPo42D6Rt51wZ3ZfXYq9IqUQ+lV7wyLecdIJtwVfsZiyAqbXzhNuuDbd+fDCkJgc0dJQtZzl5BxFF8/JWpOXHJPmJrQ0yy/2dnPCyCLZFsmIgal5YjSqxVP0gvReY=; X-YMail-OSG: YSkv9xUVM1mm_rMkWLn1K52qiCqLocYTD2lzxdRTCXpEte6 1o2WvfFAkfKBJQtLOuUskrZIFZMJ59FLMOnibZIpCL3eTv51SZ02UJfUiyLB bKa6OeDFnoiNIJsPnIf6ti3yo2U._E7CHWNmYOshDItJXHZGwxoGc8XaWCzO vlvCSWnHCugOS1Kn7_JUp5vtdxzqO9ezlDyGey05ic7sOr_DQVfShUQjwrJL 9QGFTYGWgVF4pqN77jVycUHRV8pbIWuOr_s98cpb.kFwNQkgOuKhNvyZzy6_ DxiLhsTPPDMTc2mHPscMwWixcJKqHfz5evLp3qg23jIIdiu5yWOjaKoaL2ui sHdU2tTuwi.cIS57fvegMfSvS6pB8YbVri56OTIVUEjgUZuhu7IHPeopqRvQ 13YrvtD42jFy1ZUKOmMCji8GyjcJ42.TVmGhuCEAg2x1h_VRP5Hja0AvmUfx 3DwJ50X5bCfwCO36GJYa4TBdJnsKUT4RJ1dJHWdbxix3m6qXNnp2LW8sKktJ 8pHVoFzoThQ-- Received: from [209.131.62.113] by web31806.mail.mud.yahoo.com via HTTP; Thu, 18 Aug 2011 12:26:46 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.315625 References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1313695606.21151.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Thu, 18 Aug 2011 12:26:46 -0700 (PDT) From: "William J. Mills" To: Niv Steingarten , Eran Hammer-Lahav In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-260224373-1313695606=:21151" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 19:25:54 -0000 --0-260224373-1313695606=:21151 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This is, in my opinion, another style of CSRF.=A0 I the attacker present yo= ur browser (user agent) with a link, and your browser presents a credential= automatically to the token endpoint, which automatically issues a token to= be given back to me?=A0 That's a classic CSRF, how to fix it is interestin= g.=A0 I'm of the opinion that the user *should* be pesented with some UI at= that point so they can make an informed choice about issuing a credential.= =A0 Not everyone agrees with me though (mostly business folks that want to = avoid user interaction because it's too scary .... and somehow informing th= e user what they are doign is a bad thing).=0A=0A-bill=0A=0A=0A=0A_________= _______________________=0AFrom: Niv Steingarten =0ATo: = Eran Hammer-Lahav =0ACc: "oauth@ietf.org" =0ASent: Thursday, August 18, 2011 12:11 PM=0ASubject: Re: [OAUTH-WG] D= raft 20 last call comment (Resource Owner Impersonation)=0A=0AOn Thu, Aug 1= 8, 2011 at 21:17, Eran Hammer-Lahav wrote:=0A>=0A>=0A= >> -----Original Message-----=0A>> From: Niv Steingarten [mailto:nivstein@g= mail.com]=0A>> Sent: Thursday, August 18, 2011 11:08 AM=0A>> To: Eran Hamme= r-Lahav=0A>> Cc: Torsten Lodderstedt; oauth@ietf.org=0A>> Subject: Re: [OAU= TH-WG] Draft 20 last call comment (Resource Owner=0A>> Impersonation)=0A>>= =0A>> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav =0A>> wrote:=0A>> >=0A>> >=0A>> >> -----Original Message-----=0A>> >> From= : Niv Steingarten [mailto:nivstein@gmail.com]=0A>> >> Sent: Thursday, Augus= t 18, 2011 10:16 AM=0A>> >> To: Eran Hammer-Lahav=0A>> >> Cc: Torsten Lodde= rstedt; oauth@ietf.org=0A>> >> Subject: Re: [OAUTH-WG] Draft 20 last call c= omment (Resource Owner=0A>> >> Impersonation)=0A>> >>=0A>> > Can you provid= e another example with the same level of detail as you=0A>> provided below?= =0A>>=0A>> The malicious client sends a request to the authorization endpoi= nt with the=0A>> appropriate parameters, and in return receives the markup = of the web-page=0A>> which should be displayed to the user in order to get = consent. In addition,=0A>> since the request is launched not via a sandboxe= d user-agent, the client also=0A>> has access to any 'Set-Cookie'=0A>> HTTP= headers.=0A>>=0A>> Instead of displaying the page to the user, the client = extracts the web-form=0A>> data (including the hidden nonce/token) which wo= uld be submitted when=0A>> 'Allow' is clicked. It then forges the appropria= te POST request with the=0A>> cookies, form data and referrer, and dispatch= es it,=0A>=0A> SCENE MISSING [1]=0A>=0A>> to finally receive an access toke= n/authorization code in the redirection.=0A>=0A> You skipped the best part!= =0A>=0A> What do you mean by "dispatches it"? How is the resource owner tri= cked or abused to grant authorization unknowingly? I understand how your pr= oposal "fixes" the first half, but not what kind of attack is happening in = the second half.=0A>=0A=0AI might have accidentally skipped the part where = the user is already=0Alogged in at the authorization endpoint, so no log-in= is required but=0Arather just allowing/denying access (correction: the fir= st request is=0Asent using an HTTP framework/WebKit, so no access to cookie= s). Once it=0Aextracts the data from the web-form, the client has all the= =0Ainformation it needs in order to create an HTTP request and launch it=0A= using the same HTTP framework/WebKit, simulating the "Allow" button.=0A=0A>= =0A> [1] http://www.ibras.dk/montypython/episode34.htm=0A>=0A=0A+1 for more= Monty Python references.=0A=0A-- Niv=0A___________________________________= ____________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/m= ailman/listinfo/oauth --0-260224373-1313695606=:21151 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
This is, in my opinion, another style of CSRF.  I the attacker prese= nt your browser (user agent) with a link, and your browser presents a crede= ntial automatically to the token endpoint, which automatically issues a tok= en to be given back to me?  That's a classic CSRF, how to fix it is in= teresting.  I'm of the opinion that the user *should* be pesented with= some UI at that point so they can make an informed choice about issuing a = credential.  Not everyone agrees with me though (mostly business folks= that want to avoid user interaction because it's too scary .... and someho= w informing the user what they are doign is a bad thing).
=
-bill

<= hr size=3D"1">From: Niv Ste= ingarten <nivstein@gmail.com>
Cc: "oauth@ietf.org" <oauth@ietf= .org>
Sent: Thursday= , August 18, 2011 12:11 PM
Subject= : Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impe= rsonation)

On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav &= lt;eran@hueniverse.com> wrote:
>
>
>> -----O= riginal Message-----
>> From: Niv Steingarten [mailto:n= ivstein@gmail.com]
>> Sent: Thursday, August 18, 2011 11:08 AM=
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf= .org
>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Re= source Owner
>> Impersonation)
>>
>> On Thu, Aug= 18, 2011 at 20:31, Eran Hammer-Lahav <eran@hueniverse.com>>> wrote:
>> >
>> >
>> >> ---= --Original Message-----
>> >> From: Niv Steingarten [mailto:= nivstein@gmail.com]
>> >> Sent: Thursday, August 18, 20= 11 10:16 AM
>> >> To: Eran Hammer-Lahav
>> >>= Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> Subject: Re: [OAUTH-= WG] Draft 20 last call comment (Resource Owner
>> >> Imperso= nation)
>> >>
>> > Can you provide another examp= le with the same level of detail as you
>> provided below?
>= >
>> The malicious client sends a request to the authorization = endpoint with the
>> appropriate parameters, and in return receive= s the markup of the web-page
>> which should be displayed to the u= ser in order to get consent. In addition,
>> since the request is = launched not via a sandboxed user-agent, the client also
>> has ac= cess to any 'Set-Cookie'
>> HTTP headers.
>>
>> = Instead of displaying the page to the user, the client extracts the web-for= m
>> data (including the hidden nonce/token) which would be submitted when
>> 'Allow' is clicked. It then forges the appropri= ate POST request with the
>> cookies, form data and referrer, and = dispatches it,
>
> SCENE MISSING [1]
>
>> to fin= ally receive an access token/authorization code in the redirection.
>=
> You skipped the best part!
>
> What do you mean by "di= spatches it"? How is the resource owner tricked or abused to grant authoriz= ation unknowingly? I understand how your proposal "fixes" the first half, b= ut not what kind of attack is happening in the second half.
>

= I might have accidentally skipped the part where the user is already
log= ged in at the authorization endpoint, so no log-in is required but
rathe= r just allowing/denying access (correction: the first request is
sent us= ing an HTTP framework/WebKit, so no access to cookies). Once it
extracts= the data from the web-form, the client has all the
information it needs in order to create an HTTP request and launch it
using the sam= e HTTP framework/WebKit, simulating the "Allow" button.

>
>= [1] http://www.ibras.dk/montypython/episode34.htm
>

+1 f= or more Monty Python references.

-- Niv
_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth


--0-260224373-1313695606=:21151-- From eran@hueniverse.com Thu Aug 18 12:30:54 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511C721F8BEC for ; Thu, 18 Aug 2011 12:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAetee6hXS-z for ; Thu, 18 Aug 2011 12:30:53 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 3510A21F8BDC for ; Thu, 18 Aug 2011 12:30:53 -0700 (PDT) Received: (qmail 19187 invoked from network); 18 Aug 2011 19:31:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 19:31:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 18 Aug 2011 12:31:47 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , Niv Steingarten Date: Thu, 18 Aug 2011 12:30:28 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: Acxd3McRT9VQRo0/RYSG0yMGV+ThuAAAF5jA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAAE5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1313695606.21151.YahooMailNeo@web31806.mail.mud.yahoo.com> In-Reply-To: <1313695606.21151.YahooMailNeo@web31806.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345029DFAAE5P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 19:30:54 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFAAE5P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We know how to fix CSRF attacks on form submission which this is. The UI qu= estions about more about legitimate client interaction and how informed a u= ser should be. EHL From: William J. Mills [mailto:wmills@yahoo-inc.com] Sent: Thursday, August 18, 2011 12:27 PM To: Niv Steingarten; Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Imperson= ation) This is, in my opinion, another style of CSRF. I the attacker present your= browser (user agent) with a link, and your browser presents a credential a= utomatically to the token endpoint, which automatically issues a token to b= e given back to me? That's a classic CSRF, how to fix it is interesting. = I'm of the opinion that the user *should* be pesented with some UI at that = point so they can make an informed choice about issuing a credential. Not = everyone agrees with me though (mostly business folks that want to avoid us= er interaction because it's too scary .... and somehow informing the user w= hat they are doign is a bad thing). -bill ________________________________ From: Niv Steingarten > To: Eran Hammer-Lahav > Cc: "oauth@ietf.org" > Sent: Thursday, August 18, 2011 12:11 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Imperson= ation) On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav > wrote: > > >> -----Original Message----- >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> Sent: Thursday, August 18, 2011 11:08 AM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav > >> wrote: >> > >> > >> >> -----Original Message----- >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> >> Sent: Thursday, August 18, 2011 10:16 AM >> >> To: Eran Hammer-Lahav >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> >> Impersonation) >> >> >> > Can you provide another example with the same level of detail as you >> provided below? >> >> The malicious client sends a request to the authorization endpoint with = the >> appropriate parameters, and in return receives the markup of the web-pag= e >> which should be displayed to the user in order to get consent. In additi= on, >> since the request is launched not via a sandboxed user-agent, the client= also >> has access to any 'Set-Cookie' >> HTTP headers. >> >> Instead of displaying the page to the user, the client extracts the web-= form >> data (including the hidden nonce/token) which would be submitted when >> 'Allow' is clicked. It then forges the appropriate POST request with the >> cookies, form data and referrer, and dispatches it, > > SCENE MISSING [1] > >> to finally receive an access token/authorization code in the redirection= . > > You skipped the best part! > > What do you mean by "dispatches it"? How is the resource owner tricked or= abused to grant authorization unknowingly? I understand how your proposal = "fixes" the first half, but not what kind of attack is happening in the sec= ond half. > I might have accidentally skipped the part where the user is already logged in at the authorization endpoint, so no log-in is required but rather just allowing/denying access (correction: the first request is sent using an HTTP framework/WebKit, so no access to cookies). Once it extracts the data from the web-form, the client has all the information it needs in order to create an HTTP request and launch it using the same HTTP framework/WebKit, simulating the "Allow" button. > > [1] http://www.ibras.dk/montypython/episode34.htm > +1 for more Monty Python references. -- Niv _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFAAE5P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We know h= ow to fix CSRF attacks on form submission which this is. The UI questions a= bout more about legitimate client interaction and how informed a user shoul= d be.

 

EHL

 

From: William J. Mills [mailto:wmills@yahoo-inc.com]
Sent: Thursday, August 18, 2011 12:27 PM
To: Niv Steingarten; Eran Ha= mmer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] D= raft 20 last call comment (Resource Owner Impersonation)<= /p>

 

This is, in my opinion, another style o= f CSRF.  I the attacker present your browser (user agent) with a link,= and your browser presents a credential automatically to the token endpoint= , which automatically issues a token to be given back to me?  That's a= classic CSRF, how to fix it is interesting.  I'm of the opinion that = the user *should* be pesented with some UI at that point so they can make a= n informed choice about issuing a credential.  Not everyone agrees wit= h me though (mostly business folks that want to avoid user interaction beca= use it's too scary .... and somehow informing the user what they are doign = is a bad thing).

 

-bill

 

From:<= /span> Niv Steingarten <niv= stein@gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, August = 18, 2011 12:11 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comm= ent (Resource Owner Impersonation)
On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>
>
&g= t;> -----Original Message-----
>> From: Niv Steingarten [mailto= :nivstein@gmail.com]
>> = Sent: Thursday, August 18, 2011 11:08 AM
>> To: Eran Hammer-Lahav<= br>>> Cc: Torsten Lodderstedt; oaut= h@ietf.org
>> Subject: Re: [OAUTH-WG] Draft 20 last call comme= nt (Resource Owner
>> Impersonation)
>>
>> On Th= u, Aug 18, 2011 at 20:31, Eran Hammer-Lahav <eran@hueniverse.com>
>> wrote:
>> >=
>> >
>> >> -----Original Message-----
>&g= t; >> From: Niv Steingarten [mailto:nivstein@gmail.com]
>> >> Sent: Thursday, August 18= , 2011 10:16 AM
>> >> To: Eran Hammer-Lahav
>> >= > Cc: Torsten Lodderstedt; oauth@ietf.= org
>> >> Subject: Re: [OAUTH-WG] Draft 20 last call com= ment (Resource Owner
>> >> Impersonation)
>> >&g= t;
>> > Can you provide another example with the same level of = detail as you
>> provided below?
>>
>> The malic= ious client sends a request to the authorization endpoint with the
>&= gt; appropriate parameters, and in return receives the markup of the web-pa= ge
>> which should be displayed to the user in order to get consen= t. In addition,
>> since the request is launched not via a sandbox= ed user-agent, the client also
>> has access to any 'Set-Cookie'>> HTTP headers.
>>
>> Instead of displaying the = page to the user, the client extracts the web-form
>> data (includ= ing the hidden nonce/token) which would be submitted when
>> 'Allo= w' is clicked. It then forges the appropriate POST request with the
>= > cookies, form data and referrer, and dispatches it,
>
> SC= ENE MISSING [1]
>
>> to finally receive an access token/auth= orization code in the redirection.
>
> You skipped the best par= t!
>
> What do you mean by "dispatches it"? How is th= e resource owner tricked or abused to grant authorization unknowingly? I un= derstand how your proposal "fixes" the first half, but not what k= ind of attack is happening in the second half.
>

I might have = accidentally skipped the part where the user is already
logged in at the= authorization endpoint, so no log-in is required but
rather just allowi= ng/denying access (correction: the first request is
sent using an HTTP f= ramework/WebKit, so no access to cookies). Once it
extracts the data fro= m the web-form, the client has all the
information it needs in order to = create an HTTP request and launch it
using the same HTTP framework/WebKi= t, simulating the "Allow" button.

>
> [1] http:/= /www.ibras.dk/montypython/episode34.htm
>

+1 for more Mont= y Python references.

-- Niv
_____________________________________= __________
OAuth mailing list
OAuth= @ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFAAE5P3PW5EX1MB01E_-- From rrichards@cdatazone.org Thu Aug 18 12:45:20 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC22921F8C2A for ; Thu, 18 Aug 2011 12:45:20 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5cVT8c0cZMn for ; Thu, 18 Aug 2011 12:45:20 -0700 (PDT) Received: from smtp2go.com (smtp2go.com [207.58.142.213]) by ietfa.amsl.com (Postfix) with ESMTP id 3F65D21F8C29 for ; Thu, 18 Aug 2011 12:45:20 -0700 (PDT) Received: from dsl-67-158-171-203.fairpoint.net ([67.158.171.203] helo=Rob-Richardss-MacBook-Pro.local) by smtp2go.com with esmtp (Exim 4.69) (envelope-from ) id 1Qu8XY-0006Sc-It; Thu, 18 Aug 2011 19:46:08 +0000 Message-ID: <4E4D6BFF.8080102@cdatazone.org> Date: Thu, 18 Aug 2011 15:46:07 -0400 From: Rob Richards User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E458571.1070500@cdatazone.org> <4E4AC6BA.2090007@cdatazone.org> <1313524116.13419.81.camel@ground> <90C41DD21FB7C64BB94121FBBC2E7234502498D1B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E4ACD53.2010404@stpeter.im> <4E4AD454.9040302@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAA9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] TLS 1.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 19:45:20 -0000 On 8/18/11 2:31 PM, Eran Hammer-Lahav wrote: >> -----Original Message----- >> From: Rob Richards [mailto:rrichards@cdatazone.org] >> Sent: Tuesday, August 16, 2011 1:34 PM >> The authorization server SHOULD support TLS 1.2 as defined in [RFC5246] but >> at a minimum MUST support TLS 1.0 as defined in [RFC2246], and MAY >> support additional transport-layer mechanisms meeting its security >> requirements. > How about: > > The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD support TLS 1.2 ([RFC5246]) and its future replacements, and MAY support additional transport-layer mechanisms meeting its security requirements. > > EHL > > That works Rob From nivstein@gmail.com Thu Aug 18 13:03:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D9021F8B66 for ; Thu, 18 Aug 2011 13:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lRDeMF-k5oM for ; Thu, 18 Aug 2011 13:03:32 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 80D4A21F8B65 for ; Thu, 18 Aug 2011 13:03:32 -0700 (PDT) Received: by vws12 with SMTP id 12so2257678vws.31 for ; Thu, 18 Aug 2011 13:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4fsYnvTw5OFTeyUYxE9lJcLNDDgP0deKgYQL3Avpvdc=; b=TkOX8VhKE8Rso0LH8vEMGczRaUdgeB/6OMEkeMhgvGgpfuN1fJIiz522W7fvTGhI1q ptkFmo2aFEpu9YAVHCiRQBeDkptXUG+SQxknGTDvBysgEmBJ0p78lpVHeVaxJnJaudPx K3v07rFMxPjNQRqoCSlhlllA0VTh9Sc+Dc3ZQ= Received: by 10.52.72.116 with SMTP id c20mr1218770vdv.188.1313697867032; Thu, 18 Aug 2011 13:04:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.170 with HTTP; Thu, 18 Aug 2011 13:04:07 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Niv Steingarten Date: Thu, 18 Aug 2011 23:04:07 +0300 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:03:33 -0000 On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> Sent: Thursday, August 18, 2011 12:12 PM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav >> wrote: >> > >> > >> >> -----Original Message----- >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> >> Sent: Thursday, August 18, 2011 11:08 AM >> >> To: Eran Hammer-Lahav >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> >> Impersonation) >> >> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav >> >> >> >> wrote: >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> >> >> Sent: Thursday, August 18, 2011 10:16 AM >> >> >> To: Eran Hammer-Lahav >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> >> >> Impersonation) >> >> >> >> >> > Can you provide another example with the same level of detail as >> >> > you >> >> provided below? >> >> >> >> The malicious client sends a request to the authorization endpoint >> >> with the appropriate parameters, and in return receives the markup of >> >> the web-page which should be displayed to the user in order to get >> >> consent. In addition, since the request is launched not via a >> >> sandboxed user-agent, the client also has access to any 'Set-Cookie' >> >> HTTP headers. >> >> >> >> Instead of displaying the page to the user, the client extracts the >> >> web-form data (including the hidden nonce/token) which would be >> >> submitted when 'Allow' is clicked. It then forges the appropriate >> >> POST request with the cookies, form data and referrer, and dispatches >> >> it, >> > >> > SCENE MISSING [1] >> > >> >> to finally receive an access token/authorization code in the redirection. >> > >> > You skipped the best part! >> > >> > What do you mean by "dispatches it"? How is the resource owner tricked >> or abused to grant authorization unknowingly? I understand how your >> proposal "fixes" the first half, but not what kind of attack is happening in the >> second half. >> > >> >> I might have accidentally skipped the part where the user is already logged in >> at the authorization endpoint, so no log-in is required but rather just >> allowing/denying access (correction: the first request is sent using an HTTP >> framework/WebKit, so no access to cookies). Once it extracts the data from >> the web-form, the client has all the information it needs in order to create an >> HTTP request > > No - the attacker does not have access to the session cookie. It still needs to find a way to make a CSS call. > That's what I said -- "no access to cookies". But since both requests (the one requesting the auth endpoint and the one simulating the "allow") are sent from the same user-agent, the cookies are handled by the user-agent itself. The client just POSTs the request with the appropriate parameters to the action endpoint of the form. >> and launch it using the same HTTP framework/WebKit, >> simulating the "Allow" button. > > This is still just a CSRF attack. > I think you may be right. I still believe this particular style of attack on the authorization server is worth mentioning, be it in its own separate section or under the existing CSRF section (as you suggested). -- Niv From huilan.lu@alcatel-lucent.com Thu Aug 18 13:44:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE40B11E8095 for ; Thu, 18 Aug 2011 13:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrestpWul9RY for ; Thu, 18 Aug 2011 13:44:22 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0A76E11E8091 for ; Thu, 18 Aug 2011 13:44:21 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p7IKj8Gj022493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 15:45:09 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7IKj8VU020321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Aug 2011 15:45:08 -0500 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.135]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 18 Aug 2011 15:45:08 -0500 From: "Lu, Hui-Lan (Huilan)" To: "'Eran Hammer-Lahav'" , Brian Campbell Date: Thu, 18 Aug 2011 15:45:08 -0500 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxNWiAmwaoXWhpRRLSIm3Z69CEQXANudKkQALSSvmA= Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244272@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <4E317125.7080006@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:44:22 -0000 Eran Hammer-Lahav wrote: > Added to 2.4.1: >=20 > client_secret > REQUIRED. The client secret. The client MAY omit the para= meter if the > client secret > is an empty string. I would suggest rewording the above as follows: client_secret=20 REQUIRED unless it is an empty string. The client secret. > Added to 3.2.1: >=20 > A public client that was not issued a client password MAY use= the > 'client_id' request parameter to identify itself when sending > requests to the token endpoint. It is difficult to parse the last sentence of 3.2.1: "The security ramifica= tions of allowing unauthenticated access by public clients to the token end= point MUST be considered, as well as the issuance of refresh tokens to publ= ic clients, their scope, and lifetime." I think it should be rewritten and reference relevant parts of security con= siderations. Huilan From huilan.lu@alcatel-lucent.com Thu Aug 18 13:48:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E06921F8B5B for ; Thu, 18 Aug 2011 13:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3crtTde235J for ; Thu, 18 Aug 2011 13:48:32 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8551B21F8B53 for ; Thu, 18 Aug 2011 13:48:32 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p7IKnMl8001918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 15:49:22 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7IKnMJX032090 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Aug 2011 15:49:22 -0500 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.135]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 18 Aug 2011 15:49:22 -0500 From: "Lu, Hui-Lan (Huilan)" To: "'Rob Richards'" , Eran Hammer-Lahav Date: Thu, 18 Aug 2011 15:49:22 -0500 Thread-Topic: [OAUTH-WG] TLS 1.2 Thread-Index: Acxd34CB0oEnV9g8ToOcDofXxwJRzgACMq2w Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244273@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <4E458571.1070500@cdatazone.org> <4E4AC6BA.2090007@cdatazone.org> <1313524116.13419.81.camel@ground> <90C41DD21FB7C64BB94121FBBC2E7234502498D1B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E4ACD53.2010404@stpeter.im> <4E4AD454.9040302@cdatazone.org> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E4D6BFF.8080102@cdatazone.org> In-Reply-To: <4E4D6BFF.8080102@cdatazone.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] TLS 1.2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:48:33 -0000 +1 Huilan > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Rob > Richards > Sent: Thursday, August 18, 2011 3:46 PM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] TLS 1.2 >=20 > On 8/18/11 2:31 PM, Eran Hammer-Lahav wrote: > >> -----Original Message----- > >> From: Rob Richards [mailto:rrichards@cdatazone.org] > >> Sent: Tuesday, August 16, 2011 1:34 PM > >> The authorization server SHOULD support TLS 1.2 as defined in [RFC5246= ] but > >> at a minimum MUST support TLS 1.0 as defined in [RFC2246], and MAY > >> support additional transport-layer mechanisms meeting its security > >> requirements. > > How about: > > > > The authorization server MUST support TLS 1.0 ([RFC2246]), SHOULD suppo= rt TLS > 1.2 ([RFC5246]) and its future replacements, and MAY support additional t= ransport- > layer mechanisms meeting its security requirements. > > > > EHL > > > > >=20 > That works >=20 > Rob > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Aug 18 14:14:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC6821F8B14 for ; Thu, 18 Aug 2011 14:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfFLNISOpjin for ; Thu, 18 Aug 2011 14:14:01 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id A8F9021F8B0F for ; Thu, 18 Aug 2011 14:14:01 -0700 (PDT) Received: (qmail 32040 invoked from network); 18 Aug 2011 21:14:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 21:14:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 18 Aug 2011 14:14:54 -0700 From: Eran Hammer-Lahav To: Niv Steingarten Date: Thu, 18 Aug 2011 14:13:35 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: Acxd4gnvUJ33Wx1JQ+qlXH+iWp3MTQAB/qNQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 21:14:09 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTml2IFN0ZWluZ2FydGVu IFttYWlsdG86bml2c3RlaW5AZ21haWwuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE4 LCAyMDExIDE6MDQgUE0NCj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2DQo+IENjOiBUb3JzdGVuIExv ZGRlcnN0ZWR0OyBvYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBEcmFm dCAyMCBsYXN0IGNhbGwgY29tbWVudCAoUmVzb3VyY2UgT3duZXINCj4gSW1wZXJzb25hdGlvbikN Cj4gDQo+IE9uIFRodSwgQXVnIDE4LCAyMDExIGF0IDIyOjE5LCBFcmFuIEhhbW1lci1MYWhhdiA8 ZXJhbkBodWVuaXZlcnNlLmNvbT4NCj4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBOaXYgU3RlaW5nYXJ0ZW4gW21haWx0bzpuaXZz dGVpbkBnbWFpbC5jb21dDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTgsIDIwMTEgMTI6 MTIgUE0NCj4gPj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2DQo+ID4+IENjOiBUb3JzdGVuIExvZGRl cnN0ZWR0OyBvYXV0aEBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBEcmFm dCAyMCBsYXN0IGNhbGwgY29tbWVudCAoUmVzb3VyY2UgT3duZXINCj4gPj4gSW1wZXJzb25hdGlv bikNCj4gPj4NCj4gPj4gT24gVGh1LCBBdWcgMTgsIDIwMTEgYXQgMjE6MTcsIEVyYW4gSGFtbWVy LUxhaGF2DQo+ID4+IDxlcmFuQGh1ZW5pdmVyc2UuY29tPg0KPiA+PiB3cm90ZToNCj4gPj4gPg0K PiA+PiA+DQo+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+IEZyb206 IE5pdiBTdGVpbmdhcnRlbiBbbWFpbHRvOm5pdnN0ZWluQGdtYWlsLmNvbV0NCj4gPj4gPj4gU2Vu dDogVGh1cnNkYXksIEF1Z3VzdCAxOCwgMjAxMSAxMTowOCBBTQ0KPiA+PiA+PiBUbzogRXJhbiBI YW1tZXItTGFoYXYNCj4gPj4gPj4gQ2M6IFRvcnN0ZW4gTG9kZGVyc3RlZHQ7IG9hdXRoQGlldGYu b3JnDQo+ID4+ID4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIERyYWZ0IDIwIGxhc3QgY2FsbCBj b21tZW50IChSZXNvdXJjZSBPd25lcg0KPiA+PiA+PiBJbXBlcnNvbmF0aW9uKQ0KPiA+PiA+Pg0K PiA+PiA+PiBPbiBUaHUsIEF1ZyAxOCwgMjAxMSBhdCAyMDozMSwgRXJhbiBIYW1tZXItTGFoYXYN Cj4gPj4gPj4gPGVyYW5AaHVlbml2ZXJzZS5jb20+DQo+ID4+ID4+IHdyb3RlOg0KPiA+PiA+PiA+ DQo+ID4+ID4+ID4NCj4gPj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g Pj4gPj4gRnJvbTogTml2IFN0ZWluZ2FydGVuIFttYWlsdG86bml2c3RlaW5AZ21haWwuY29tXQ0K PiA+PiA+PiA+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDE4LCAyMDExIDEwOjE2IEFNDQo+ID4+ ID4+ID4+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiA+PiA+PiA+PiBDYzogVG9yc3RlbiBMb2Rk ZXJzdGVkdDsgb2F1dGhAaWV0Zi5vcmcNCj4gPj4gPj4gPj4gU3ViamVjdDogUmU6IFtPQVVUSC1X R10gRHJhZnQgMjAgbGFzdCBjYWxsIGNvbW1lbnQgKFJlc291cmNlDQo+ID4+ID4+ID4+IE93bmVy DQo+ID4+ID4+ID4+IEltcGVyc29uYXRpb24pDQo+ID4+ID4+ID4+DQo+ID4+ID4+ID4gQ2FuIHlv dSBwcm92aWRlIGFub3RoZXIgZXhhbXBsZSB3aXRoIHRoZSBzYW1lIGxldmVsIG9mIGRldGFpbCBh cw0KPiA+PiA+PiA+IHlvdQ0KPiA+PiA+PiBwcm92aWRlZCBiZWxvdz8NCj4gPj4gPj4NCj4gPj4g Pj4gVGhlIG1hbGljaW91cyBjbGllbnQgc2VuZHMgYSByZXF1ZXN0IHRvIHRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50DQo+ID4+ID4+IHdpdGggdGhlIGFwcHJvcHJpYXRlIHBhcmFtZXRlcnMsIGFu ZCBpbiByZXR1cm4gcmVjZWl2ZXMgdGhlIG1hcmt1cA0KPiA+PiA+PiBvZiB0aGUgd2ViLXBhZ2Ug d2hpY2ggc2hvdWxkIGJlIGRpc3BsYXllZCB0byB0aGUgdXNlciBpbiBvcmRlciB0bw0KPiA+PiA+ PiBnZXQgY29uc2VudC4gSW4gYWRkaXRpb24sIHNpbmNlIHRoZSByZXF1ZXN0IGlzIGxhdW5jaGVk IG5vdCB2aWEgYQ0KPiA+PiA+PiBzYW5kYm94ZWQgdXNlci1hZ2VudCwgdGhlIGNsaWVudCBhbHNv IGhhcyBhY2Nlc3MgdG8gYW55ICdTZXQtQ29va2llJw0KPiA+PiA+PiBIVFRQIGhlYWRlcnMuDQo+ ID4+ID4+DQo+ID4+ID4+IEluc3RlYWQgb2YgZGlzcGxheWluZyB0aGUgcGFnZSB0byB0aGUgdXNl ciwgdGhlIGNsaWVudCBleHRyYWN0cw0KPiA+PiA+PiB0aGUgd2ViLWZvcm0gZGF0YSAoaW5jbHVk aW5nIHRoZSBoaWRkZW4gbm9uY2UvdG9rZW4pIHdoaWNoIHdvdWxkDQo+ID4+ID4+IGJlIHN1Ym1p dHRlZCB3aGVuICdBbGxvdycgaXMgY2xpY2tlZC4gSXQgdGhlbiBmb3JnZXMgdGhlDQo+ID4+ID4+ IGFwcHJvcHJpYXRlIFBPU1QgcmVxdWVzdCB3aXRoIHRoZSBjb29raWVzLCBmb3JtIGRhdGEgYW5k IHJlZmVycmVyLA0KPiA+PiA+PiBhbmQgZGlzcGF0Y2hlcyBpdCwNCj4gPj4gPg0KPiA+PiA+IFND RU5FIE1JU1NJTkcgWzFdDQo+ID4+ID4NCj4gPj4gPj4gdG8gZmluYWxseSByZWNlaXZlIGFuIGFj Y2VzcyB0b2tlbi9hdXRob3JpemF0aW9uIGNvZGUgaW4gdGhlIHJlZGlyZWN0aW9uLg0KPiA+PiA+ DQo+ID4+ID4gWW91IHNraXBwZWQgdGhlIGJlc3QgcGFydCENCj4gPj4gPg0KPiA+PiA+IFdoYXQg ZG8geW91IG1lYW4gYnkgImRpc3BhdGNoZXMgaXQiPyBIb3cgaXMgdGhlIHJlc291cmNlIG93bmVy DQo+ID4+ID4gdHJpY2tlZA0KPiA+PiBvciBhYnVzZWQgdG8gZ3JhbnQgYXV0aG9yaXphdGlvbiB1 bmtub3dpbmdseT8gSSB1bmRlcnN0YW5kIGhvdyB5b3VyDQo+ID4+IHByb3Bvc2FsICJmaXhlcyIg dGhlIGZpcnN0IGhhbGYsIGJ1dCBub3Qgd2hhdCBraW5kIG9mIGF0dGFjayBpcw0KPiA+PiBoYXBw ZW5pbmcgaW4gdGhlIHNlY29uZCBoYWxmLg0KPiA+PiA+DQo+ID4+DQo+ID4+IEkgbWlnaHQgaGF2 ZSBhY2NpZGVudGFsbHkgc2tpcHBlZCB0aGUgcGFydCB3aGVyZSB0aGUgdXNlciBpcyBhbHJlYWR5 DQo+ID4+IGxvZ2dlZCBpbiBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgc28gbm8gbG9n LWluIGlzIHJlcXVpcmVkIGJ1dA0KPiA+PiByYXRoZXIganVzdCBhbGxvd2luZy9kZW55aW5nIGFj Y2VzcyAoY29ycmVjdGlvbjogdGhlIGZpcnN0IHJlcXVlc3QgaXMNCj4gPj4gc2VudCB1c2luZyBh biBIVFRQIGZyYW1ld29yay9XZWJLaXQsIHNvIG5vIGFjY2VzcyB0byBjb29raWVzKS4gT25jZQ0K PiA+PiBpdCBleHRyYWN0cyB0aGUgZGF0YSBmcm9tIHRoZSB3ZWItZm9ybSwgdGhlIGNsaWVudCBo YXMgYWxsIHRoZQ0KPiA+PiBpbmZvcm1hdGlvbiBpdCBuZWVkcyBpbiBvcmRlciB0byBjcmVhdGUg YW4gSFRUUCByZXF1ZXN0DQo+ID4NCj4gPiBObyAtIHRoZSBhdHRhY2tlciBkb2VzIG5vdCBoYXZl IGFjY2VzcyB0byB0aGUgc2Vzc2lvbiBjb29raWUuIEl0IHN0aWxsIG5lZWRzDQo+IHRvIGZpbmQg YSB3YXkgdG8gbWFrZSBhIENTUyBjYWxsLg0KPiA+DQo+IA0KPiBUaGF0J3Mgd2hhdCBJIHNhaWQg LS0gIm5vIGFjY2VzcyB0byBjb29raWVzIi4NCg0KWW91IG9ubHkgc2FpZCB0aGF0IGFib3V0IHRo ZSBmaXJzdCByZXF1ZXN0Lg0KDQo+IEJ1dCBzaW5jZSBib3RoIHJlcXVlc3RzICh0aGUgb25lDQo+ IHJlcXVlc3RpbmcgdGhlIGF1dGggZW5kcG9pbnQgYW5kIHRoZSBvbmUgc2ltdWxhdGluZyB0aGUN Cj4gImFsbG93IikgYXJlIHNlbnQgZnJvbSB0aGUgc2FtZSB1c2VyLWFnZW50LCB0aGUgY29va2ll cyBhcmUgaGFuZGxlZCBieSB0aGUNCj4gdXNlci1hZ2VudCBpdHNlbGYuIFRoZSBjbGllbnQganVz dCBQT1NUcyB0aGUgcmVxdWVzdCB3aXRoIHRoZSBhcHByb3ByaWF0ZQ0KPiBwYXJhbWV0ZXJzIHRv IHRoZSBhY3Rpb24gZW5kcG9pbnQgb2YgdGhlIGZvcm0uDQoNClRoYXQncyBub3QgZXhhY3RseSBy aWdodC4NCg0KVGhpcyBlbnRpcmUgYXR0YWNrIGlzIGJhc2VkIG9uOg0KDQoxLiBUaGUgcHJlc2Vu Y2Ugb2Ygc29tZSBzZXNzaW9uIGNvb2tpZSBvciBvdGhlciB1c2VyLWFnZW50IHN0YXRlIHRvIGJ5 cGFzcyBhY3RpdmUgYXV0aGVudGljYXRpb24sIGFuZA0KMi4gVGhlIGFiaWxpdHkgb2YgdGhlIG1h bGljaW91cyBjbGllbnQgdG8gbWFrZSBDU1MgY2FsbHMgdXNpbmcgIzEuDQoNCkV2ZXJ5dGhpbmcg ZWxzZSBpcyBhIHJlZCBoZXJyaW5nIGJlY2F1c2UgdGhlIGFiaWxpdHkgdG8gYXV0b21hdGUgdGhp cyBhdHRhY2sgYW5kIG1ha2UgaXQgbW9yZSBwb3dlcmZ1bCBpcyBjb21wbGV0ZWx5IGJlc2lkZSB0 aGUgcG9pbnQuIElmIHlvdSBkZXBsb3kgYW4gZWZmZWN0aXZlIENTUkYgcHJvdGVjdGlvbiwgZXZl cnl0aGluZyBlbHNlIGlzIGEgbm9uLWlzc3VlLg0KDQpUaGlzIGlzIHdoeSB0aGUgY2xpZW50IHR5 cGUgZG9lcyBub3QgbWF0dGVyIHdoZW4gaXQgY29tZXMgdG8gbm90IHVzaW5nIENPUlMuIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBNVVNUIE5PVCBhbGxvdyBDU1MgY2FsbHMgb24gdGhlIGF1dGhv cml6YXRpb24gZW5kcG9pbnQgYmVjYXVzZSB0aGF0J3MgdGhlIGFjdHVhbCBhdHRhY2sgeW91IGRl c2NyaWJlZCAtIHVzaW5nIGxvY2FsIHN0YXRlIChzZXNzaW9uIGNvb2tpZSkgdG8gbWFrZSBhIENT UyBjYWxsLiBJZiB0aGUgY2xpZW50IG1ha2VzIGRpcmVjdCBjYWxscyB0byB0aGUgYXV0aG9yaXph dGlvbiBlbmRwb2ludCwgaXQgY2Fubm90IGltcGVyc29uYXRlIHRoZSByZXNvdXJjZSBvd25lci4N Cg0KPiA+PiBhbmQgbGF1bmNoIGl0IHVzaW5nIHRoZSBzYW1lIEhUVFAgZnJhbWV3b3JrL1dlYktp dCwgc2ltdWxhdGluZyB0aGUNCj4gPj4gIkFsbG93IiBidXR0b24uDQo+ID4NCj4gPiBUaGlzIGlz IHN0aWxsIGp1c3QgYSBDU1JGIGF0dGFjay4NCj4gPg0KPiANCj4gSSB0aGluayB5b3UgbWF5IGJl IHJpZ2h0LiBJIHN0aWxsIGJlbGlldmUgdGhpcyBwYXJ0aWN1bGFyIHN0eWxlIG9mIGF0dGFjayBv biB0aGUNCj4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgd29ydGggbWVudGlvbmluZywgYmUgaXQg aW4gaXRzIG93biBzZXBhcmF0ZSBzZWN0aW9uIG9yDQo+IHVuZGVyIHRoZSBleGlzdGluZyBDU1JG IHNlY3Rpb24gKGFzIHlvdSBzdWdnZXN0ZWQpLg0KDQpUaGlzIGlzIG5vdCBhIHN0eWxlIG9mIGF0 dGFjayBidXQgdGVjaG5pcXVlcyB0byBlbmhhbmNlIG90aGVyIGV4cGxvaXRzLCBpbiB0aGlzIGNh c2UsIENTUkYuIElmIHlvdSBsYWNrIENTUkYgcHJvdGVjdGlvbiwgdGhlbiB5ZXMsIGxhY2sgb2Yg cmVzb3VyY2Ugb3duZXIgZm9yY2VkIGludGVyYWN0aW9uIHdpbGwgbWFrZSBpdCBlYXNpZXIgdG8g ZXhlY3V0ZS4gQnV0IHRoYXQncyBqdXN0IGEgdGlueSBzcGVlZCBidW1wIGNvbnNpZGVyaW5nIHRo ZSBhY3R1YWwgZXhwbG9pdC4NCg0KSSBkb24ndCBzZWUgYW55IHJlYXNvbiB0byBpbmNsdWRlIHRo aXMgbmV3IHRleHQgYmFzZWQgb24gdGhpcyB0aHJlYXQgYW5hbHlzaXMuDQoNCkhvd2V2ZXIsIHRo aXMgZG9lc24ndCBtZWFuIHRoaXMgZGlzY3Vzc2lvbiB3YXNuJ3QgdXNlZnVsLiBXZSBkaWQgaWRl bnRpZnkgdGhlIG5lZWQgdG8gZXhwbGljaXRseSBkaXNjdXNzIENTUkYgYXR0YWNrcyBvbiB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludC4gV2UgbmVlZCB0byBleHBsaWNpdGx5IHNlcGFyYXRlIHRo ZSB0d28gdGFyZ2V0IG9mIENTUkYgYXR0YWNrcyAoY2xpZW50LCBzZXJ2ZXIpIGJlY2F1c2Ugd2hp bGUgdGhlIHNvbHV0aW9uIGlzIHRoZSBzYW1lLCB0aGUgaW1wbGVtZW50YXRpb24gaXMgdmVyeSBk aWZmZXJlbnQgKGR1ZSB0byB0aGUgdXNlIG9mIHJlZGlyZWN0aW9ucyBpbiBvbmUpLg0KDQpFSEwN Cg0KDQoNCg0KDQo= From eran@hueniverse.com Thu Aug 18 14:17:50 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EE621F85B1 for ; Thu, 18 Aug 2011 14:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx9xP1li7xUk for ; Thu, 18 Aug 2011 14:17:50 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 5873D21F85AE for ; Thu, 18 Aug 2011 14:17:50 -0700 (PDT) Received: (qmail 4636 invoked from network); 18 Aug 2011 21:17:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2011 21:17:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 18 Aug 2011 14:17:48 -0700 From: Eran Hammer-Lahav To: "Lu, Hui-Lan (Huilan)" , Brian Campbell Date: Thu, 18 Aug 2011 14:16:29 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxNWiAmwaoXWhpRRLSIm3Z69CEQXANudKkQALSSvmAAAWgcIA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E317125.7080006@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244272@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> In-Reply-To: <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244272@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 21:17:50 -0000 > -----Original Message----- > From: Lu, Hui-Lan (Huilan) [mailto:huilan.lu@alcatel-lucent.com] > Sent: Thursday, August 18, 2011 1:45 PM > To: Eran Hammer-Lahav; Brian Campbell > Cc: oauth > Subject: RE: [OAUTH-WG] treatment of client_id for authentication and > identification >=20 > Eran Hammer-Lahav wrote: > > Added to 2.4.1: > > > > client_secret > > REQUIRED. The client secret. The client MAY omit the > > parameter if the client secret > > is an empty string. >=20 > I would suggest rewording the above as follows: > client_secret > REQUIRED unless it is an empty string. The client secret. "unless its value is an empty string". Do people read this new text to mean= OPTIONAL if not empty? > > Added to 3.2.1: > > > > A public client that was not issued a client password MAY u= se the > > 'client_id' request parameter to identify itself when sendi= ng > > requests to the token endpoint. >=20 > It is difficult to parse the last sentence of 3.2.1: "The security ramifi= cations of > allowing unauthenticated access by public clients to the token endpoint > MUST be considered, as well as the issuance of refresh tokens to public > clients, their scope, and lifetime." >=20 > I think it should be rewritten and reference relevant parts of security > considerations. Text? EHL From trac+oauth@trac.tools.ietf.org Thu Aug 18 14:19:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC0021F85EC for ; Thu, 18 Aug 2011 14:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK23rftrhjlT for ; Thu, 18 Aug 2011 14:19:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [12.22.58.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9662921F85C4 for ; Thu, 18 Aug 2011 14:19:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qu6R6-00046S-B5; Thu, 18 Aug 2011 10:31:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Thu, 18 Aug 2011 17:31:20 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/24 Message-ID: <063.ec10a0cb7f5a7aa6d2a4806ad1847869@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #24: Resource Owner Impersonation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 21:19:15 -0000 #24: Resource Owner Impersonation See discussion thread beginning here: http://www.ietf.org/mail-archive/web/oauth/current/msg07225.html Torsten proposes text that describes the attack and suggests defenses. -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Thu Aug 18 14:19:14 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE8E21F85B5 for ; Thu, 18 Aug 2011 14:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgAwmRtbUJDr for ; Thu, 18 Aug 2011 14:19:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [12.22.58.42]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5F21F8574 for ; Thu, 18 Aug 2011 14:19:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qu6vn-0005wv-50; Thu, 18 Aug 2011 11:03:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Thu, 18 Aug 2011 18:03:03 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/22#comment:3 Message-ID: <072.b902c0f393f3d2beeb1ae66a93075770@trac.tools.ietf.org> References: <063.707240208e9ab0af6aaf9ec7f599e841@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <063.707240208e9ab0af6aaf9ec7f599e841@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #22: WG last call complete; waiting for new revision (was: In final review before WG last call) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 21:19:15 -0000 #22: WG last call complete; waiting for new revision Changes (by barryleiba@…): * severity: Active WG Document => In WG Last Call -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: barryleiba@… Type: state | Status: assigned Priority: information | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: In WG Last Call | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Thu Aug 18 14:19:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E4821F8574 for ; Thu, 18 Aug 2011 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvmeRN4yxFUP for ; Thu, 18 Aug 2011 14:19:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [12.22.58.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8F20F21F85B1 for ; Thu, 18 Aug 2011 14:19:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1Qu7IQ-0005kV-SK; Thu, 18 Aug 2011 11:26:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Thu, 18 Aug 2011 18:26:26 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/25 Message-ID: <063.c133e18b72fd00182857db8e365e916c@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #25: Clarifying reference to refresh tokens in section 1.4.3 of -20 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 21:19:15 -0000 #25: Clarifying reference to refresh tokens in section 1.4.3 of -20 See discussion thread beginning here: http://www.ietf.org/mail-archive/web/oauth/current/msg07309.html Yaron brings up a point in his review, to which Eran responds with a suggestion of removing "(when combined with a refresh token)". Several objections are raised to the removal. Eran proposes an alternative here: http://www.ietf.org/mail-archive/web/oauth/current/msg07322.html -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: new Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From bcampbell@pingidentity.com Thu Aug 18 14:24:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64CB21F8880 for ; Thu, 18 Aug 2011 14:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.961 X-Spam-Level: X-Spam-Status: No, score=-5.961 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23NGS4Bwqpd4 for ; Thu, 18 Aug 2011 14:24:19 -0700 (PDT) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id E112021F87C9 for ; Thu, 18 Aug 2011 14:24:18 -0700 (PDT) Received: from mail-qw0-f49.google.com ([209.85.216.49]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKTk2DMKRRx15EfrARKNFV2i/f2MUAJH/R@postini.com; Thu, 18 Aug 2011 14:25:14 PDT Received: by mail-qw0-f49.google.com with SMTP id 2so2075057qwi.36 for ; Thu, 18 Aug 2011 14:25:04 -0700 (PDT) Received: by 10.224.198.135 with SMTP id eo7mr1147990qab.33.1313702704130; Thu, 18 Aug 2011 14:25:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.28.202 with HTTP; Thu, 18 Aug 2011 14:24:34 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E317125.7080006@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244272@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Thu, 18 Aug 2011 15:24:34 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 21:24:19 -0000 FWIW, I was okay with the text EHL had originally proposed for 21. >> > client_secret >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 REQUIRED. The client secret. The clien= t MAY omit the >> > parameter if the client secret >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is an empty string. >> >> I would suggest rewording the above as follows: >> client_secret >> =A0 =A0 =A0 REQUIRED unless it is an empty string. The client secret. > > "unless its value is an empty string". Do people read this new text to me= an OPTIONAL if not empty? From huilan.lu@alcatel-lucent.com Thu Aug 18 14:46:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F91D21F8876 for ; Thu, 18 Aug 2011 14:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89HwuzsalYSB for ; Thu, 18 Aug 2011 14:46:18 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id CE5E021F884C for ; Thu, 18 Aug 2011 14:46:18 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p7ILlBKk015829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 16:47:12 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7ILlBwW028893 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Aug 2011 16:47:11 -0500 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.135]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 18 Aug 2011 16:47:11 -0500 From: "Lu, Hui-Lan (Huilan)" To: "'Eran Hammer-Lahav'" , Brian Campbell Date: Thu, 18 Aug 2011 16:47:10 -0500 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxNWiAmwaoXWhpRRLSIm3Z69CEQXANudKkQALSSvmAAAWgcIAABDUFQ Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244274@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <4E317125.7080006@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244272@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 21:46:19 -0000 > > It is difficult to parse the last sentence of 3.2.1: "The security rami= fications of > > allowing unauthenticated access by public clients to the token endpoint > > MUST be considered, as well as the issuance of refresh tokens to public > > clients, their scope, and lifetime." > > > > I think it should be rewritten and reference relevant parts of security > > considerations. >=20 > Text? >=20 > EHL Here is my stab: Allowing unauthenticated access by public clients has security ramification= s. So does the issuance of refresh tokens to public clients. Such security = ramifications MUST be considered. See section 10 for further details. Huilan From huilan.lu@alcatel-lucent.com Thu Aug 18 15:13:19 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340F321F8876 for ; Thu, 18 Aug 2011 15:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XeeDnG6cfUs for ; Thu, 18 Aug 2011 15:13:18 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 918C821F8713 for ; Thu, 18 Aug 2011 15:13:18 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p7IMDfdt006380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 17:13:59 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7IMDeh5028342 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Aug 2011 17:13:40 -0500 Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.135]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 18 Aug 2011 17:13:40 -0500 From: "Lu, Hui-Lan (Huilan)" To: "Lu, Hui-Lan (Huilan)" , "'Eran Hammer-Lahav'" , Brian Campbell Date: Thu, 18 Aug 2011 17:13:40 -0500 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxNWiAmwaoXWhpRRLSIm3Z69CEQXANudKkQALSSvmAAAWgcIAABDUFQAADlC2A= Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244275@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <4E317125.7080006@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244272@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244274@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> In-Reply-To: <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244274@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 22:13:19 -0000 I just noticed that some words were missing in my previous post. Here is th= e full text that Eran requested: Allowing unauthenticated access to the token endpoint by public clients has= security ramifications. So does issuing refresh tokens to public clients. Such security ramifications MUST = be considered. See section 10 for further details. Huilan > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Lu, > Hui-Lan (Huilan) > Sent: Thursday, August 18, 2011 5:47 PM > To: 'Eran Hammer-Lahav'; Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ide= ntification >=20 > > > It is difficult to parse the last sentence of 3.2.1: "The security ra= mifications of > > > allowing unauthenticated access by public clients to the token endpoi= nt > > > MUST be considered, as well as the issuance of refresh tokens to publ= ic > > > clients, their scope, and lifetime." > > > > > > I think it should be rewritten and reference relevant parts of securi= ty > > > considerations. > > > > Text? > > > > EHL >=20 > Here is my stab: > Allowing unauthenticated access by public clients has security ramificati= ons. So does > the issuance of refresh tokens to public clients. Such security ramificat= ions MUST be > considered. See section 10 for further details. >=20 > Huilan > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nivstein@gmail.com Thu Aug 18 16:32:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8259721F874B for ; Thu, 18 Aug 2011 16:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74VxtoBz0yT5 for ; Thu, 18 Aug 2011 16:32:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 30C6021F873A for ; Thu, 18 Aug 2011 16:32:37 -0700 (PDT) Received: by vws12 with SMTP id 12so2418018vws.31 for ; Thu, 18 Aug 2011 16:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=QACKlSDfcZ3VYg/Z5fTrz+ZvUO9yZFXW5JAgNdXYap8=; b=r2lJEdp6gSOehZQD8BBH81IgtH/mNolOWDMRoEnkqvUIU+VCrtVPxMeSGXY2vblNQR uAo8l2oGvByR3qbrt/rD/pIbAL0FQ8mcqQ7CrXbZ7uevc2u3rKTJL3swKUi4D6CW4yjq mDFGDfBRu4V7Kv60wjbakLOnD48VEsUqc/KJM= Received: by 10.52.24.9 with SMTP id q9mr187986vdf.54.1313710412124; Thu, 18 Aug 2011 16:33:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.170 with HTTP; Thu, 18 Aug 2011 16:33:12 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Niv Steingarten Date: Fri, 19 Aug 2011 02:33:12 +0300 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 23:32:38 -0000 How about add something like this as the second paragraph in 10.12: The authorization server SHOULD employ measures to prevent CSRF attacks on the authorization endpoint. A non-guessable token SHOULD be included in requests and form submissions within the authorization server's internal authorization flow. This token MUST NOT be accessible by the client. In addition, the authorization server may make use of HTTP referrer headers in order to verify the origin of requests made during the authorization flow. In addition, I think that: The "state" request parameter SHOULD be used to mitigate against CSRF attacks, ... should be changed to: The "state" request parameter SHOULD be used to mitigate against CSRF attacks against the client's redirection URI, ... so that the fact that the 'state' parameter protects against CSRF attacks on the *client*, as opposed to CSRF on the *authorization server*, is made explicit. -- Niv On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav wrot= e: > > >> -----Original Message----- >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> Sent: Thursday, August 18, 2011 1:04 PM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> >> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav >> wrote: >> > >> > >> >> -----Original Message----- >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> >> Sent: Thursday, August 18, 2011 12:12 PM >> >> To: Eran Hammer-Lahav >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> >> Impersonation) >> >> >> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav >> >> >> >> wrote: >> >> > >> >> > >> >> >> -----Original Message----- >> >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> >> >> Sent: Thursday, August 18, 2011 11:08 AM >> >> >> To: Eran Hammer-Lahav >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> >> >> Impersonation) >> >> >> >> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav >> >> >> >> >> >> wrote: >> >> >> > >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM >> >> >> >> To: Eran Hammer-Lahav >> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource >> >> >> >> Owner >> >> >> >> Impersonation) >> >> >> >> >> >> >> > Can you provide another example with the same level of detail as >> >> >> > you >> >> >> provided below? >> >> >> >> >> >> The malicious client sends a request to the authorization endpoint >> >> >> with the appropriate parameters, and in return receives the markup >> >> >> of the web-page which should be displayed to the user in order to >> >> >> get consent. In addition, since the request is launched not via a >> >> >> sandboxed user-agent, the client also has access to any 'Set-Cooki= e' >> >> >> HTTP headers. >> >> >> >> >> >> Instead of displaying the page to the user, the client extracts >> >> >> the web-form data (including the hidden nonce/token) which would >> >> >> be submitted when 'Allow' is clicked. It then forges the >> >> >> appropriate POST request with the cookies, form data and referrer, >> >> >> and dispatches it, >> >> > >> >> > SCENE MISSING [1] >> >> > >> >> >> to finally receive an access token/authorization code in the redir= ection. >> >> > >> >> > You skipped the best part! >> >> > >> >> > What do you mean by "dispatches it"? How is the resource owner >> >> > tricked >> >> or abused to grant authorization unknowingly? I understand how your >> >> proposal "fixes" the first half, but not what kind of attack is >> >> happening in the second half. >> >> > >> >> >> >> I might have accidentally skipped the part where the user is already >> >> logged in at the authorization endpoint, so no log-in is required but >> >> rather just allowing/denying access (correction: the first request is >> >> sent using an HTTP framework/WebKit, so no access to cookies). Once >> >> it extracts the data from the web-form, the client has all the >> >> information it needs in order to create an HTTP request >> > >> > No - the attacker does not have access to the session cookie. It still= needs >> to find a way to make a CSS call. >> > >> >> That's what I said -- "no access to cookies". > > You only said that about the first request. > >> But since both requests (the one >> requesting the auth endpoint and the one simulating the >> "allow") are sent from the same user-agent, the cookies are handled by t= he >> user-agent itself. The client just POSTs the request with the appropriat= e >> parameters to the action endpoint of the form. > > That's not exactly right. > > This entire attack is based on: > > 1. The presence of some session cookie or other user-agent state to bypas= s active authentication, and > 2. The ability of the malicious client to make CSS calls using #1. > > Everything else is a red herring because the ability to automate this att= ack and make it more powerful is completely beside the point. If you deploy= an effective CSRF protection, everything else is a non-issue. > > This is why the client type does not matter when it comes to not using CO= RS. The authorization server MUST NOT allow CSS calls on the authorization = endpoint because that's the actual attack you described - using local state= (session cookie) to make a CSS call. If the client makes direct calls to t= he authorization endpoint, it cannot impersonate the resource owner. > >> >> and launch it using the same HTTP framework/WebKit, simulating the >> >> "Allow" button. >> > >> > This is still just a CSRF attack. >> > >> >> I think you may be right. I still believe this particular style of attac= k on the >> authorization server is worth mentioning, be it in its own separate sect= ion or >> under the existing CSRF section (as you suggested). > > This is not a style of attack but techniques to enhance other exploits, i= n this case, CSRF. If you lack CSRF protection, then yes, lack of resource = owner forced interaction will make it easier to execute. But that's just a = tiny speed bump considering the actual exploit. > > I don't see any reason to include this new text based on this threat anal= ysis. > > However, this doesn't mean this discussion wasn't useful. We did identify= the need to explicitly discuss CSRF attacks on the authorization endpoint.= We need to explicitly separate the two target of CSRF attacks (client, ser= ver) because while the solution is the same, the implementation is very dif= ferent (due to the use of redirections in one). > > EHL > > > > > > From wmills@yahoo-inc.com Thu Aug 18 16:46:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1851411E809F for ; Thu, 18 Aug 2011 16:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.348 X-Spam-Level: X-Spam-Status: No, score=-17.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL6A1JhpdCQU for ; Thu, 18 Aug 2011 16:46:05 -0700 (PDT) Received: from nm38-vm4.bullet.mail.bf1.yahoo.com (nm38-vm4.bullet.mail.bf1.yahoo.com [72.30.239.20]) by ietfa.amsl.com (Postfix) with SMTP id 6EF5211E8073 for ; Thu, 18 Aug 2011 16:46:05 -0700 (PDT) Received: from [98.139.215.141] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 18 Aug 2011 23:46:57 -0000 Received: from [98.139.212.239] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 18 Aug 2011 23:46:57 -0000 Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 18 Aug 2011 23:46:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 689997.60461.bm@omp1048.mail.bf1.yahoo.com Received: (qmail 75213 invoked by uid 60001); 18 Aug 2011 23:46:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313711216; bh=adlk9o70H1lYxIF+U5nE7QhyWW+0Qh11XjYQywQdBRo=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nNfSY8nqr0LTruw3D10x4ErlUSEA1rkv2Kj3sJWtDe1AF2eOnVRbRQpCVBhEtvolCUhB7tWReUogGhELG53lMEwpWRzkaWVlb3C/epQbVLY8p497pVAFvQUi1Mj10mUQfRe2u6/K5gkjov3F4ZVYDoGVd9ZuiG8iB2hb+Ka9HyM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gH6U7ygJkCpjdsfVhATNrHmP1qFkPe1iPYPycYlvIme12t7LDg+4iI8k94tL94j6gKFAZEYJTFRSeKiLSd4hW5ywLRb9TYvg8omXIZ7Gne4eKj3Ktu4y2807qep8aOroCLwiS9fYZUtLSuGwnLQT+yZiucPWSb4nkj8x8FUw6TY=; X-YMail-OSG: NxX88NIVM1l4uSUjJGVU7Udp08.GrGdUoD6QLgCuGJoXJON piiPAh.zW2N3sWYDMb4bC8OM2bnbjZOThgasZxFRTXzizglNRQwRdjR9Qv.q koMMCT3h8lUtOpoxhegCax1EBCXtbfR5TYUne5EEu4tHdzrS0iuCGU8a0wTJ pH3qMLC_wtqlY2cX8DAmexwINfXwjPLn36.E8IXz16WpsNcqbGR3skmJFhgF xi__fTAGXjTxOuZRKl3ZFIM9LWzz78fwVpD8MXVldd3r46WP84_oz.WzS0bD hJ4HmI9jRoj5QcyjDa4uQRzYgXvtv_DrwlE8e1qCPexJAhfUteR7D.ncZ_LZ 22pdpc_fnDahvH5IsopM0Fv.zZ1XSkEE412frzrf1TRRiaNLzmaMOspa4yHT H_4DHd1gZNu_OgjiQkNGs360aOIQ8ssQIRoWJA50_gB4- Received: from [209.131.62.115] by web31808.mail.mud.yahoo.com via HTTP; Thu, 18 Aug 2011 16:46:55 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.114.317681 References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <1313711215.67102.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Thu, 18 Aug 2011 16:46:55 -0700 (PDT) From: "William J. Mills" To: Niv Steingarten , Eran Hammer-Lahav In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-58944271-1313711215=:67102" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 23:46:07 -0000 --0-58944271-1313711215=:67102 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I proposed text that I think is more complete in a previous message...=0A= =0A=0A=0A________________________________=0AFrom: Niv Steingarten =0ATo: Eran Hammer-Lahav =0ACc: "oauth@ietf= .org" =0ASent: Thursday, August 18, 2011 4:33 PM=0ASubject:= Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)= =0A=0AHow about add something like this as the second paragraph in 10.12:= =0A=0A=A0 The authorization server SHOULD employ measures to prevent CSRF= =0A=A0 attacks on the authorization endpoint. A non-guessable token SHOULD= =0A=A0 be included in requests and form submissions within the authorizati= on=0A=A0 server's internal authorization flow. This token MUST NOT be=0A= =A0 accessible by the client. In addition, the authorization server may=0A= =A0 make use of HTTP referrer headers in order to verify the origin of=0A= =A0 requests made during the authorization flow.=0A=0AIn addition, I think= that:=0A=0A=A0 The "state" request parameter SHOULD be used to mitigate a= gainst CSRF=0A=A0 attacks, ...=0A=0Ashould be changed to:=0A=0A=A0 The "s= tate" request parameter SHOULD be used to mitigate against CSRF=0A=A0 atta= cks against the client's redirection URI, ...=0A=0Aso that the fact that th= e 'state' parameter protects against CSRF=0Aattacks on the *client*, as opp= osed to CSRF on the *authorization=0Aserver*, is made explicit.=0A=0A-- Niv= =0A=0A=0AOn Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav wrote:=0A>=0A>=0A>> -----Original Message-----=0A>> From: Niv Steingar= ten [mailto:nivstein@gmail.com]=0A>> Sent: Thursday, August 18, 2011 1:04 P= M=0A>> To: Eran Hammer-Lahav=0A>> Cc: Torsten Lodderstedt; oauth@ietf.org= =0A>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner=0A= >> Impersonation)=0A>>=0A>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Laha= v =0A>> wrote:=0A>> >=0A>> >=0A>> >> -----Original Mes= sage-----=0A>> >> From: Niv Steingarten [mailto:nivstein@gmail.com]=0A>> >>= Sent: Thursday, August 18, 2011 12:12 PM=0A>> >> To: Eran Hammer-Lahav=0A>= > >> Cc: Torsten Lodderstedt; oauth@ietf.org=0A>> >> Subject: Re: [OAUTH-WG= ] Draft 20 last call comment (Resource Owner=0A>> >> Impersonation)=0A>> >>= =0A>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav=0A>> >> =0A>> >> wrote:=0A>> >> >=0A>> >> >=0A>> >> >> -----Original Me= ssage-----=0A>> >> >> From: Niv Steingarten [mailto:nivstein@gmail.com]=0A>= > >> >> Sent: Thursday, August 18, 2011 11:08 AM=0A>> >> >> To: Eran Hammer= -Lahav=0A>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org=0A>> >> >> Subjec= t: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner=0A>> >> >> Imp= ersonation)=0A>> >> >>=0A>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hamme= r-Lahav=0A>> >> >> =0A>> >> >> wrote:=0A>> >> >> >=0A>= > >> >> >=0A>> >> >> >> -----Original Message-----=0A>> >> >> >> From: Niv = Steingarten [mailto:nivstein@gmail.com]=0A>> >> >> >> Sent: Thursday, Augus= t 18, 2011 10:16 AM=0A>> >> >> >> To: Eran Hammer-Lahav=0A>> >> >> >> Cc: T= orsten Lodderstedt; oauth@ietf.org=0A>> >> >> >> Subject: Re: [OAUTH-WG] Dr= aft 20 last call comment (Resource=0A>> >> >> >> Owner=0A>> >> >> >> Impers= onation)=0A>> >> >> >>=0A>> >> >> > Can you provide another example with th= e same level of detail as=0A>> >> >> > you=0A>> >> >> provided below?=0A>> = >> >>=0A>> >> >> The malicious client sends a request to the authorization = endpoint=0A>> >> >> with the appropriate parameters, and in return receives= the markup=0A>> >> >> of the web-page which should be displayed to the use= r in order to=0A>> >> >> get consent. In addition, since the request is lau= nched not via a=0A>> >> >> sandboxed user-agent, the client also has access= to any 'Set-Cookie'=0A>> >> >> HTTP headers.=0A>> >> >>=0A>> >> >> Instead= of displaying the page to the user, the client extracts=0A>> >> >> the web= -form data (including the hidden nonce/token) which would=0A>> >> >> be sub= mitted when 'Allow' is clicked. It then forges the=0A>> >> >> appropriate P= OST request with the cookies, form data and referrer,=0A>> >> >> and dispat= ches it,=0A>> >> >=0A>> >> > SCENE MISSING [1]=0A>> >> >=0A>> >> >> to fina= lly receive an access token/authorization code in the redirection.=0A>> >> = >=0A>> >> > You skipped the best part!=0A>> >> >=0A>> >> > What do you mean= by "dispatches it"? How is the resource owner=0A>> >> > tricked=0A>> >> or= abused to grant authorization unknowingly? I understand how your=0A>> >> p= roposal "fixes" the first half, but not what kind of attack is=0A>> >> happ= ening in the second half.=0A>> >> >=0A>> >>=0A>> >> I might have accidental= ly skipped the part where the user is already=0A>> >> logged in at the auth= orization endpoint, so no log-in is required but=0A>> >> rather just allowi= ng/denying access (correction: the first request is=0A>> >> sent using an H= TTP framework/WebKit, so no access to cookies). Once=0A>> >> it extracts th= e data from the web-form, the client has all the=0A>> >> information it nee= ds in order to create an HTTP request=0A>> >=0A>> > No - the attacker does = not have access to the session cookie. It still needs=0A>> to find a way to= make a CSS call.=0A>> >=0A>>=0A>> That's what I said -- "no access to cook= ies".=0A>=0A> You only said that about the first request.=0A>=0A>> But sinc= e both requests (the one=0A>> requesting the auth endpoint and the one simu= lating the=0A>> "allow") are sent from the same user-agent, the cookies are= handled by the=0A>> user-agent itself. The client just POSTs the request w= ith the appropriate=0A>> parameters to the action endpoint of the form.=0A>= =0A> That's not exactly right.=0A>=0A> This entire attack is based on:=0A>= =0A> 1. The presence of some session cookie or other user-agent state to by= pass active authentication, and=0A> 2. The ability of the malicious client = to make CSS calls using #1.=0A>=0A> Everything else is a red herring becaus= e the ability to automate this attack and make it more powerful is complete= ly beside the point. If you deploy an effective CSRF protection, everything= else is a non-issue.=0A>=0A> This is why the client type does not matter w= hen it comes to not using CORS. The authorization server MUST NOT allow CSS= calls on the authorization endpoint because that's the actual attack you d= escribed - using local state (session cookie) to make a CSS call. If the cl= ient makes direct calls to the authorization endpoint, it cannot impersonat= e the resource owner.=0A>=0A>> >> and launch it using the same HTTP framewo= rk/WebKit, simulating the=0A>> >> "Allow" button.=0A>> >=0A>> > This is sti= ll just a CSRF attack.=0A>> >=0A>>=0A>> I think you may be right. I still b= elieve this particular style of attack on the=0A>> authorization server is = worth mentioning, be it in its own separate section or=0A>> under the exist= ing CSRF section (as you suggested).=0A>=0A> This is not a style of attack = but techniques to enhance other exploits, in this case, CSRF. If you lack C= SRF protection, then yes, lack of resource owner forced interaction will ma= ke it easier to execute. But that's just a tiny speed bump considering the = actual exploit.=0A>=0A> I don't see any reason to include this new text bas= ed on this threat analysis.=0A>=0A> However, this doesn't mean this discuss= ion wasn't useful. We did identify the need to explicitly discuss CSRF atta= cks on the authorization endpoint. We need to explicitly separate the two t= arget of CSRF attacks (client, server) because while the solution is the sa= me, the implementation is very different (due to the use of redirections in= one).=0A>=0A> EHL=0A>=0A>=0A>=0A>=0A>=0A>=0A______________________________= _________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.= org/mailman/listinfo/oauth --0-58944271-1313711215=:67102 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I proposed text that I think is more complete in a previous message...

From: Niv Steingarten <nivstein@gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com= >
Cc: "oauth@ietf.or= g" <oauth@ietf.org>
Sent: Thursday, August 18, 2011 4:33 PM
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Res= ource Owner Impersonation)

How about add something like this as the seco= nd paragraph in 10.12:

  The authorization server SHOULD emplo= y measures to prevent CSRF
  attacks on the authorization endpoint= . A non-guessable token SHOULD
  be included in requests and form = submissions within the authorization
  server's internal authoriza= tion flow. This token MUST NOT be
  accessible by the client. In a= ddition, the authorization server may
  make use of HTTP referrer = headers in order to verify the origin of
  requests made during th= e authorization flow.

In addition, I think that:

  The = "state" request parameter SHOULD be used to mitigate against CSRF
 = attacks, ...

should be changed to:

  The "state" requ= est parameter SHOULD be used to mitigate against CSRF
  attacks ag= ainst the client's redirection URI, ...

so that the fact that the 'state' parameter protects against CSRF
attacks on the *client*, as= opposed to CSRF on the *authorization
server*, is made explicit.
-- Niv


On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav <= eran@hueniverse.com> wrote:
>
>
>> -----Origina= l Message-----
>> From: Niv Steingarten [mailto:nivstein@gmail.co= m]
>> Sent: Thursday, August 18, 2011 1:04 PM
>> To: = Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>&= gt; Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
&= gt;> Impersonation)
>>
>> On Thu, Aug 18, 2011 at 22:1= 9, Eran Hammer-Lahav <eran@hueniverse.com>
>>= ; wrote:
>> >
>> >
>> >> -----Origin= al Message-----
>> >> From: Niv Steingarten [mailto:nivstei= n@gmail.com]
>> >> Sent: Thursday, August 18, 2011 12:12= PM
>> >> To: Eran Hammer-Lahav
>> >> Cc: Tor= sten Lodderstedt; oauth@ietf.org
>> >> Subject: Re: [OAUTH-WG] = Draft 20 last call comment (Resource Owner
>> >> Impersonati= on)
>> >>
>> >> On Thu, Aug 18, 2011 at 21:17= , Eran Hammer-Lahav
>> >> <eran@hueniverse.com>=
>> >> wrote:
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> = >> >> From: Niv Steingarten [mailto:nivstein@gmail.com]>> >> >> Sent: Thursday, August 18, 2011 11:08 AM
>= ;> >> >> To: Eran Hammer-Lahav
>> >> >>= Cc: Torsten Lodderstedt; oauth@ietf.org
>> >> >> Subject= : Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> >= ;> >> Impersonation)
>> >> >>
>> >= ;> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
>>= >> >> <eran@hueniverse.com>
>> >> = >> wrote:
>> >> >> >
>> >> >= ;> >
>> >> >> >> -----Original Message-----
= >> >> >> >> From: Niv Steingarten [mailto:nivstein= @gmail.com]
>> >> >> >> Sent: Thursday, Augu= st 18, 2011 10:16 AM
>> >> >> >> To: Eran Hammer= -Lahav
>> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.= org
>> >> >> >> Subject: Re: [OAUTH-WG] Draf= t 20 last call comment (Resource
>> >> >> >> Own= er
>> >> >> >> Impersonation)
>> >&g= t; >> >>
>> >> >> > Can you provide ano= ther example with the same level of detail as
>> >> >>= > you
>> >> >> provided below?
>> >>= ; >>
>> >> >> The malicious client sends a reques= t to the authorization endpoint
>> >> >> with the appr= opriate parameters, and in return receives the markup
>> >> = >> of the web-page which should be displayed to the user in order to<= br>>> >> >> get consent. In addition, since the request i= s launched not via a
>> >> >> sandboxed user-agent, th= e client also has access to any 'Set-Cookie'
>> >> >> = HTTP headers.
>> >> >>
>> >> >> I= nstead of displaying the page to the user, the client extracts
>> = >> >> the web-form data (including the hidden nonce/token) whic= h would
>> >> >> be submitted when 'Allow' is clicked.= It then forges the
>> >> >> appropriate POST request = with the cookies, form data and referrer,
>> >> >> and dispatches it,
>> >> >
>> >>= > SCENE MISSING [1]
>> >> >
>> >> >= > to finally receive an access token/authorization code in the redirecti= on.
>> >> >
>> >> > You skipped the bes= t part!
>> >> >
>> >> > What do you mea= n by "dispatches it"? How is the resource owner
>> >> > t= ricked
>> >> or abused to grant authorization unknowingly? I= understand how your
>> >> proposal "fixes" the first half, = but not what kind of attack is
>> >> happening in the second= half.
>> >> >
>> >>
>> >> = I might have accidentally skipped the part where the user is already
>= ;> >> logged in at the authorization endpoint, so no log-in is req= uired but
>> >> rather just allowing/denying access (correction: the first request is
>> >> sent using an HTTP = framework/WebKit, so no access to cookies). Once
>> >> it ex= tracts the data from the web-form, the client has all the
>> >&= gt; information it needs in order to create an HTTP request
>> >= ;
>> > No - the attacker does not have access to the session co= okie. It still needs
>> to find a way to make a CSS call.
>&= gt; >
>>
>> That's what I said -- "no access to cookie= s".
>
> You only said that about the first request.
>
= >> But since both requests (the one
>> requesting the auth e= ndpoint and the one simulating the
>> "allow") are sent from the s= ame user-agent, the cookies are handled by the
>> user-agent itsel= f. The client just POSTs the request with the appropriate
>> param= eters to the action endpoint of the form.
>
> That's not exactly right.
>
> This entire attack is based on:
>
= > 1. The presence of some session cookie or other user-agent state to by= pass active authentication, and
> 2. The ability of the malicious cli= ent to make CSS calls using #1.
>
> Everything else is a red he= rring because the ability to automate this attack and make it more powerful= is completely beside the point. If you deploy an effective CSRF protection= , everything else is a non-issue.
>
> This is why the client ty= pe does not matter when it comes to not using CORS. The authorization serve= r MUST NOT allow CSS calls on the authorization endpoint because that's the= actual attack you described - using local state (session cookie) to make a= CSS call. If the client makes direct calls to the authorization endpoint, = it cannot impersonate the resource owner.
>
>> >> and = launch it using the same HTTP framework/WebKit, simulating the
>> >> "Allow" button.
>> >
>> >= This is still just a CSRF attack.
>> >
>>
>>= I think you may be right. I still believe this particular style of attack = on the
>> authorization server is worth mentioning, be it in its o= wn separate section or
>> under the existing CSRF section (as you = suggested).
>
> This is not a style of attack but techniques to= enhance other exploits, in this case, CSRF. If you lack CSRF protection, t= hen yes, lack of resource owner forced interaction will make it easier to e= xecute. But that's just a tiny speed bump considering the actual exploit.>
> I don't see any reason to include this new text based on thi= s threat analysis.
>
> However, this doesn't mean this discussi= on wasn't useful. We did identify the need to explicitly discuss CSRF attac= ks on the authorization endpoint. We need to explicitly separate the two target of CSRF attacks (client, server) because while the solution is = the same, the implementation is very different (due to the use of redirecti= ons in one).
>
> EHL
>
>
>
>
>>
_______________________________________________
OAuth mailing l= ist
= OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--0-58944271-1313711215=:67102-- From nivstein@gmail.com Thu Aug 18 18:06:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F0B21F84F2 for ; Thu, 18 Aug 2011 18:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT5-gINl6CJp for ; Thu, 18 Aug 2011 18:06:03 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01B3921F8586 for ; Thu, 18 Aug 2011 18:06:02 -0700 (PDT) Received: by vxi29 with SMTP id 29so2710425vxi.31 for ; Thu, 18 Aug 2011 18:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=XtL5CTra7fsQpQnJu2B0Y7buEHnqaoSqapqk3l/UTJA=; b=jrv1vWlD+7rGObYfNx/BlIQdcuOBYgUluxt1VFd5JUGHBnscUtO8XuSxrU+TdySbqG sHv+N1Q/YJpQz2Xo3u3jGJGFAfXyRTILb+lRwOml5mF42psg5KYArejgGzxxU5w5bWAM 6eF1z19c0LP3yHYZkxrE/BncrGcAFw4wdIoCM= Received: by 10.52.26.97 with SMTP id k1mr1569327vdg.523.1313716018074; Thu, 18 Aug 2011 18:06:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.170 with HTTP; Thu, 18 Aug 2011 18:06:38 -0700 (PDT) In-Reply-To: <1313711215.67102.YahooMailNeo@web31808.mail.mud.yahoo.com> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1313711215.67102.YahooMailNeo@web31808.mail.mud.yahoo.com> From: Niv Steingarten Date: Fri, 19 Aug 2011 04:06:38 +0300 Message-ID: To: "William J. Mills" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 01:06:04 -0000 I suppose you're talking about this: http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html It is indeed more complete w.r.t. CSRF attacks on the client's redirection URI, but it does not address CSRF attacks on the authorization server. I believe something along the lines of the text I proposed could be combined in whichever text is eventually decided upon. -- Niv On Fri, Aug 19, 2011 at 02:46, William J. Mills wrot= e: > I proposed text that I think is more complete in a previous message... > ________________________________ > From: Niv Steingarten > To: Eran Hammer-Lahav > Cc: "oauth@ietf.org" > Sent: Thursday, August 18, 2011 4:33 PM > Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner > Impersonation) > > How about add something like this as the second paragraph in 10.12: > > =C2=A0 The authorization server SHOULD employ measures to prevent CSRF > =C2=A0 attacks on the authorization endpoint. A non-guessable token SHOUL= D > =C2=A0 be included in requests and form submissions within the authorizat= ion > =C2=A0 server's internal authorization flow. This token MUST NOT be > =C2=A0 accessible by the client. In addition, the authorization server ma= y > =C2=A0 make use of HTTP referrer headers in order to verify the origin of > =C2=A0 requests made during the authorization flow. > > In addition, I think that: > > =C2=A0 The "state" request parameter SHOULD be used to mitigate against C= SRF > =C2=A0 attacks, ... > > should be changed to: > > =C2=A0 The "state" request parameter SHOULD be used to mitigate against C= SRF > =C2=A0 attacks against the client's redirection URI, ... > > so that the fact that the 'state' parameter protects against CSRF > attacks on the *client*, as opposed to CSRF on the *authorization > server*, is made explicit. > > -- Niv > > > On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav > wrote: >> >> >>> -----Original Message----- >>> From: Niv Steingarten [mailto:nivstein@gmail.com] >>> Sent: Thursday, August 18, 2011 1:04 PM >>> To: Eran Hammer-Lahav >>> Cc: Torsten Lodderstedt; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >>> Impersonation) >>> >>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav >>> wrote: >>> > >>> > >>> >> -----Original Message----- >>> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >>> >> Sent: Thursday, August 18, 2011 12:12 PM >>> >> To: Eran Hammer-Lahav >>> >> Cc: Torsten Lodderstedt; oauth@ietf.org >>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >>> >> Impersonation) >>> >> >>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav >>> >> >>> >> wrote: >>> >> > >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >>> >> >> Sent: Thursday, August 18, 2011 11:08 AM >>> >> >> To: Eran Hammer-Lahav >>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owne= r >>> >> >> Impersonation) >>> >> >> >>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav >>> >> >> >>> >> >> wrote: >>> >> >> > >>> >> >> > >>> >> >> >> -----Original Message----- >>> >> >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM >>> >> >> >> To: Eran Hammer-Lahav >>> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >>> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource >>> >> >> >> Owner >>> >> >> >> Impersonation) >>> >> >> >> >>> >> >> > Can you provide another example with the same level of detail a= s >>> >> >> > you >>> >> >> provided below? >>> >> >> >>> >> >> The malicious client sends a request to the authorization endpoin= t >>> >> >> with the appropriate parameters, and in return receives the marku= p >>> >> >> of the web-page which should be displayed to the user in order to >>> >> >> get consent. In addition, since the request is launched not via a >>> >> >> sandboxed user-agent, the client also has access to any >>> >> >> 'Set-Cookie' >>> >> >> HTTP headers. >>> >> >> >>> >> >> Instead of displaying the page to the user, the client extracts >>> >> >> the web-form data (including the hidden nonce/token) which would >>> >> >> be submitted when 'Allow' is clicked. It then forges the >>> >> >> appropriate POST request with the cookies, form data and referrer= , >>> >> >> and dispatches it, >>> >> > >>> >> > SCENE MISSING [1] >>> >> > >>> >> >> to finally receive an access token/authorization code in the >>> >> >> redirection. >>> >> > >>> >> > You skipped the best part! >>> >> > >>> >> > What do you mean by "dispatches it"? How is the resource owner >>> >> > tricked >>> >> or abused to grant authorization unknowingly? I understand how your >>> >> proposal "fixes" the first half, but not what kind of attack is >>> >> happening in the second half. >>> >> > >>> >> >>> >> I might have accidentally skipped the part where the user is already >>> >> logged in at the authorization endpoint, so no log-in is required bu= t >>> >> rather just allowing/denying access (correction: the first request i= s >>> >> sent using an HTTP framework/WebKit, so no access to cookies). Once >>> >> it extracts the data from the web-form, the client has all the >>> >> information it needs in order to create an HTTP request >>> > >>> > No - the attacker does not have access to the session cookie. It stil= l >>> > needs >>> to find a way to make a CSS call. >>> > >>> >>> That's what I said -- "no access to cookies". >> >> You only said that about the first request. >> >>> But since both requests (the one >>> requesting the auth endpoint and the one simulating the >>> "allow") are sent from the same user-agent, the cookies are handled by >>> the >>> user-agent itself. The client just POSTs the request with the appropria= te >>> parameters to the action endpoint of the form. >> >> That's not exactly right. >> >> This entire attack is based on: >> >> 1. The presence of some session cookie or other user-agent state to bypa= ss >> active authentication, and >> 2. The ability of the malicious client to make CSS calls using #1. >> >> Everything else is a red herring because the ability to automate this >> attack and make it more powerful is completely beside the point. If you >> deploy an effective CSRF protection, everything else is a non-issue. >> >> This is why the client type does not matter when it comes to not using >> CORS. The authorization server MUST NOT allow CSS calls on the authoriza= tion >> endpoint because that's the actual attack you described - using local st= ate >> (session cookie) to make a CSS call. If the client makes direct calls to= the >> authorization endpoint, it cannot impersonate the resource owner. >> >>> >> and launch it using the same HTTP framework/WebKit, simulating the >>> >> "Allow" button. >>> > >>> > This is still just a CSRF attack. >>> > >>> >>> I think you may be right. I still believe this particular style of atta= ck >>> on the >>> authorization server is worth mentioning, be it in its own separate >>> section or >>> under the existing CSRF section (as you suggested). >> >> This is not a style of attack but techniques to enhance other exploits, = in >> this case, CSRF. If you lack CSRF protection, then yes, lack of resource >> owner forced interaction will make it easier to execute. But that's just= a >> tiny speed bump considering the actual exploit. >> >> I don't see any reason to include this new text based on this threat >> analysis. >> >> However, this doesn't mean this discussion wasn't useful. We did identif= y >> the need to explicitly discuss CSRF attacks on the authorization endpoin= t. >> We need to explicitly separate the two target of CSRF attacks (client, >> server) because while the solution is the same, the implementation is ve= ry >> different (due to the use of redirections in one). >> >> EHL >> >> >> >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > From wmills@yahoo-inc.com Thu Aug 18 21:20:32 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A70221F86EC for ; Thu, 18 Aug 2011 21:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.249 X-Spam-Level: X-Spam-Status: No, score=-17.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q0iG7kC+cFw for ; Thu, 18 Aug 2011 21:20:30 -0700 (PDT) Received: from nm12.bullet.mail.ac4.yahoo.com (nm12.bullet.mail.ac4.yahoo.com [98.139.52.209]) by ietfa.amsl.com (Postfix) with SMTP id B292521F86DD for ; Thu, 18 Aug 2011 21:20:28 -0700 (PDT) Received: from [98.139.52.195] by nm12.bullet.mail.ac4.yahoo.com with NNFMP; 19 Aug 2011 04:21:20 -0000 Received: from [98.139.52.167] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 19 Aug 2011 04:21:20 -0000 Received: from [127.0.0.1] by omp1050.mail.ac4.yahoo.com with NNFMP; 19 Aug 2011 04:21:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 563529.83434.bm@omp1050.mail.ac4.yahoo.com Received: (qmail 4699 invoked by uid 60001); 19 Aug 2011 04:21:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1313727679; bh=/ZmwV6ywDK0mM+sCn76UijHcRWHoDUJLAwx5kULrznM=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=U5aUiorHz9pA+visS7OnamHS5tay3hGZvB0bv34pWiljVdpJgBe4jjtGnJBVQNPU5V9oGLmaosdTsc1jbn1gLkFCxwWez2dKhaHsQfspGlxU7HJB0j7Zg4ZqhqAnCyDjvk/RU+7ZsM9vwbO+ENG2Y4A/9WJWPGp3lY35npKNl94= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XFa/Ljjf1Guz8Gb6GWNvQbXju2i9Mwqp/DKU0AvrF9hSW2s+KeeteSQ+yEpYiXVCw07Ta4rSoBF74YbmKx083M8lNCIziVXylUrlbWIkRk+BbLunyAQf8Ua2ulSdF+t4k0XZwD46RJTkZ7lnkAOq6XdVJ9wJ06LnNCE/SoJOFMg=; X-YMail-OSG: rheT.jMVM1mEpbs1GUGAHRkkQFeo6NZyrnldYQfcqm42.Xr CwztZU6FAvkcwlATtWjjJi3yrLjptrR.6ST63Axab9VwH8mDOx7GG8c107MH RjUh_2r3Uq1S0qitb4uTPPu.0BVkZ3Ok5odqfZa5pUYqWcsy1_3VuNGQneNN ccLFIKDsjbSeQztQ84v0W_U4OEwFhcL_d68Qf5TO1ctQToRNHpJd_687XB7v S.xsJV8E7F5HCkUupt8SlPT7xoX1zrrFi2NXCG.rizpVSMU6npP4QmsEMmXs z9K9rPwfPCda2cBhmMsJDmV0zwFZaey8Mjyij7cCem6iaqKlt1aEQLT3eVZp w7DF71W_ku6yYTQIbSvZqDd_v67upnw.AmvheNzHeOBCvBKXtwtOTeZhVu.y fKsl0xmIN77LOVdi.9erK Received: from [99.31.212.42] by web31802.mail.mud.yahoo.com via HTTP; Thu, 18 Aug 2011 21:21:19 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.114.317681 References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1313711215.67102.YahooMailNeo@we b31808.mail.mud.yahoo.com> Message-ID: <1313727679.93999.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 18 Aug 2011 21:21:19 -0700 (PDT) From: "William J. Mills" To: Niv Steingarten In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-415210984-1313727679=:93999" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 04:20:32 -0000 --0-415210984-1313727679=:93999 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable While I agree in principal, I think there are real world use cases that mak= e this more complicated.=A0 If, for example, a user has previously approved= access to a particular endpoint then we might be willing to re-issue crede= ntials without user interaction.=A0 I don't know how we capture this in the= right way in the spec.=0A=0A=0A=0A________________________________=0AFrom:= Niv Steingarten =0ATo: William J. Mills =0ACc: Eran Hammer-Lahav ; "oauth@ietf.org" =0ASent: Thursday, August 18, 2011 6:06 PM=0ASubject: Re: [OA= UTH-WG] Draft 20 last call comment (Resource Owner Impersonation)=0A=0AI su= ppose you're talking about this:=0Ahttp://www.ietf.org/mail-archive/web/oau= th/current/msg07275.html=0A=0AIt is indeed more complete w.r.t. CSRF attack= s on the client's=0Aredirection URI, but it does not address CSRF attacks o= n the=0Aauthorization server.=0A=0AI believe something along the lines of t= he text I proposed could be=0Acombined in whichever text is eventually deci= ded upon.=0A=0A-- Niv=0A=0A=0AOn Fri, Aug 19, 2011 at 02:46, William J. Mil= ls wrote:=0A> I proposed text that I think is more c= omplete in a previous message...=0A> ________________________________=0A> F= rom: Niv Steingarten =0A> To: Eran Hammer-Lahav =0A> Cc: "oauth@ietf.org" =0A> Sent: Thursday= , August 18, 2011 4:33 PM=0A> Subject: Re: [OAUTH-WG] Draft 20 last call co= mment (Resource Owner=0A> Impersonation)=0A>=0A> How about add something li= ke this as the second paragraph in 10.12:=0A>=0A> =A0 The authorization ser= ver SHOULD employ measures to prevent CSRF=0A> =A0 attacks on the authoriza= tion endpoint. A non-guessable token SHOULD=0A> =A0 be included in requests= and form submissions within the authorization=0A> =A0 server's internal au= thorization flow. This token MUST NOT be=0A> =A0 accessible by the client. = In addition, the authorization server may=0A> =A0 make use of HTTP referrer= headers in order to verify the origin of=0A> =A0 requests made during the = authorization flow.=0A>=0A> In addition, I think that:=0A>=0A> =A0 The "sta= te" request parameter SHOULD be used to mitigate against CSRF=0A> =A0 attac= ks, ...=0A>=0A> should be changed to:=0A>=0A> =A0 The "state" request param= eter SHOULD be used to mitigate against CSRF=0A> =A0 attacks against the cl= ient's redirection URI, ...=0A>=0A> so that the fact that the 'state' param= eter protects against CSRF=0A> attacks on the *client*, as opposed to CSRF = on the *authorization=0A> server*, is made explicit.=0A>=0A> -- Niv=0A>=0A>= =0A> On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav = =0A> wrote:=0A>>=0A>>=0A>>> -----Original Message-----=0A>>> From: Niv Stei= ngarten [mailto:nivstein@gmail.com]=0A>>> Sent: Thursday, August 18, 2011 1= :04 PM=0A>>> To: Eran Hammer-Lahav=0A>>> Cc: Torsten Lodderstedt; oauth@iet= f.org=0A>>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Ow= ner=0A>>> Impersonation)=0A>>>=0A>>> On Thu, Aug 18, 2011 at 22:19, Eran Ha= mmer-Lahav =0A>>> wrote:=0A>>> >=0A>>> >=0A>>> >> ----= -Original Message-----=0A>>> >> From: Niv Steingarten [mailto:nivstein@gmai= l.com]=0A>>> >> Sent: Thursday, August 18, 2011 12:12 PM=0A>>> >> To: Eran = Hammer-Lahav=0A>>> >> Cc: Torsten Lodderstedt; oauth@ietf.org=0A>>> >> Subj= ect: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner=0A>>> >> Imp= ersonation)=0A>>> >>=0A>>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-La= hav=0A>>> >> =0A>>> >> wrote:=0A>>> >> >=0A>>> >> >=0A= >>> >> >> -----Original Message-----=0A>>> >> >> From: Niv Steingarten [mai= lto:nivstein@gmail.com]=0A>>> >> >> Sent: Thursday, August 18, 2011 11:08 A= M=0A>>> >> >> To: Eran Hammer-Lahav=0A>>> >> >> Cc: Torsten Lodderstedt; oa= uth@ietf.org=0A>>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment= (Resource Owner=0A>>> >> >> Impersonation)=0A>>> >> >>=0A>>> >> >> On Thu,= Aug 18, 2011 at 20:31, Eran Hammer-Lahav=0A>>> >> >> = =0A>>> >> >> wrote:=0A>>> >> >> >=0A>>> >> >> >=0A>>> >> >> >> -----Origina= l Message-----=0A>>> >> >> >> From: Niv Steingarten [mailto:nivstein@gmail.= com]=0A>>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM=0A>>> >> >> >>= To: Eran Hammer-Lahav=0A>>> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.o= rg=0A>>> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resou= rce=0A>>> >> >> >> Owner=0A>>> >> >> >> Impersonation)=0A>>> >> >> >>=0A>>>= >> >> > Can you provide another example with the same level of detail as= =0A>>> >> >> > you=0A>>> >> >> provided below?=0A>>> >> >>=0A>>> >> >> The = malicious client sends a request to the authorization endpoint=0A>>> >> >> = with the appropriate parameters, and in return receives the markup=0A>>> >>= >> of the web-page which should be displayed to the user in order to=0A>>>= >> >> get consent. In addition, since the request is launched not via a=0A= >>> >> >> sandboxed user-agent, the client also has access to any=0A>>> >> = >> 'Set-Cookie'=0A>>> >> >> HTTP headers.=0A>>> >> >>=0A>>> >> >> Instead o= f displaying the page to the user, the client extracts=0A>>> >> >> the web-= form data (including the hidden nonce/token) which would=0A>>> >> >> be sub= mitted when 'Allow' is clicked. It then forges the=0A>>> >> >> appropriate = POST request with the cookies, form data and referrer,=0A>>> >> >> and disp= atches it,=0A>>> >> >=0A>>> >> > SCENE MISSING [1]=0A>>> >> >=0A>>> >> >> t= o finally receive an access token/authorization code in the=0A>>> >> >> red= irection.=0A>>> >> >=0A>>> >> > You skipped the best part!=0A>>> >> >=0A>>>= >> > What do you mean by "dispatches it"? How is the resource owner=0A>>> = >> > tricked=0A>>> >> or abused to grant authorization unknowingly? I under= stand how your=0A>>> >> proposal "fixes" the first half, but not what kind = of attack is=0A>>> >> happening in the second half.=0A>>> >> >=0A>>> >>=0A>= >> >> I might have accidentally skipped the part where the user is already= =0A>>> >> logged in at the authorization endpoint, so no log-in is required= but=0A>>> >> rather just allowing/denying access (correction: the first re= quest is=0A>>> >> sent using an HTTP framework/WebKit, so no access to cook= ies). Once=0A>>> >> it extracts the data from the web-form, the client has = all the=0A>>> >> information it needs in order to create an HTTP request=0A= >>> >=0A>>> > No - the attacker does not have access to the session cookie.= It still=0A>>> > needs=0A>>> to find a way to make a CSS call.=0A>>> >=0A>= >>=0A>>> That's what I said -- "no access to cookies".=0A>>=0A>> You only s= aid that about the first request.=0A>>=0A>>> But since both requests (the o= ne=0A>>> requesting the auth endpoint and the one simulating the=0A>>> "all= ow") are sent from the same user-agent, the cookies are handled by=0A>>> th= e=0A>>> user-agent itself. The client just POSTs the request with the appro= priate=0A>>> parameters to the action endpoint of the form.=0A>>=0A>> That'= s not exactly right.=0A>>=0A>> This entire attack is based on:=0A>>=0A>> 1.= The presence of some session cookie or other user-agent state to bypass=0A= >> active authentication, and=0A>> 2. The ability of the malicious client t= o make CSS calls using #1.=0A>>=0A>> Everything else is a red herring becau= se the ability to automate this=0A>> attack and make it more powerful is co= mpletely beside the point. If you=0A>> deploy an effective CSRF protection,= everything else is a non-issue.=0A>>=0A>> This is why the client type does= not matter when it comes to not using=0A>> CORS. The authorization server = MUST NOT allow CSS calls on the authorization=0A>> endpoint because that's = the actual attack you described - using local state=0A>> (session cookie) t= o make a CSS call. If the client makes direct calls to the=0A>> authorizati= on endpoint, it cannot impersonate the resource owner.=0A>>=0A>>> >> and la= unch it using the same HTTP framework/WebKit, simulating the=0A>>> >> "Allo= w" button.=0A>>> >=0A>>> > This is still just a CSRF attack.=0A>>> >=0A>>>= =0A>>> I think you may be right. I still believe this particular style of a= ttack=0A>>> on the=0A>>> authorization server is worth mentioning, be it in= its own separate=0A>>> section or=0A>>> under the existing CSRF section (a= s you suggested).=0A>>=0A>> This is not a style of attack but techniques to= enhance other exploits, in=0A>> this case, CSRF. If you lack CSRF protecti= on, then yes, lack of resource=0A>> owner forced interaction will make it e= asier to execute. But that's just a=0A>> tiny speed bump considering the ac= tual exploit.=0A>>=0A>> I don't see any reason to include this new text bas= ed on this threat=0A>> analysis.=0A>>=0A>> However, this doesn't mean this = discussion wasn't useful. We did identify=0A>> the need to explicitly discu= ss CSRF attacks on the authorization endpoint.=0A>> We need to explicitly s= eparate the two target of CSRF attacks (client,=0A>> server) because while = the solution is the same, the implementation is very=0A>> different (due to= the use of redirections in one).=0A>>=0A>> EHL=0A>>=0A>>=0A>>=0A>>=0A>>=0A= >>=0A> _______________________________________________=0A> OAuth mailing li= st=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A>= =0A>=0A> --0-415210984-1313727679=:93999 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
While I agree in principal, I think there are real world use cases that m= ake this more complicated.  If, for example, a user has previously app= roved access to a particular endpoint then we might be willing to re-issue = credentials without user interaction.  I don't know how we capture thi= s in the right way in the spec.

From: Niv Steingarten <nivstein@gm= ail.com>
To: William= J. Mills <wmills@yahoo-inc.com>
Cc: Eran Hammer-Lahav <eran@hueniverse.com>; "oaut= h@ietf.org" <oauth@ietf.org>
Sent: Thursday, August 18, 2011 6:06 PM
Subject: Re: [OAUTH-WG] Draft 20 last call com= ment (Resource Owner Impersonation)

I suppose you're talking = about this:
http://www.ietf.org/mail-archive/web/oau= th/current/msg07275.html

It is indeed more complete w.r.t. CSRF = attacks on the client's
redirection URI, but it does not address CSRF at= tacks on the
authorization server.

I believe something along the = lines of the text I proposed could be
combined in whichever text is even= tually decided upon.

-- Niv


On Fri, Aug 19, 2011 at 02:46= , William J. Mills <wmills@yahoo-inc.com> wrote:> I proposed text that I think is more complete in a previous message.= ..
> ________________________________
> From: Niv Steingarten &= lt;nivstein@gmail.com>
> To: Eran Hammer-Lahav <eran@hu= eniverse.com>
> Cc: "oauth@ietf.org" <oauth@ietf.org>
> = Sent: Thursday, August 18, 2011 4:33 PM
> Subject: Re: [OAUTH-WG] Dra= ft 20 last call comment (Resource Owner
> Impersonation)
>
&= gt; How about add something like this as the second paragraph in 10.12:
= >
>   The authorization server SHOULD employ measures to prev= ent CSRF
>   attacks on the authorization endpoint. A non-guessable= token SHOULD
>   be included in requests and form submissions w= ithin the authorization
>   server's internal authorization flow= . This token MUST NOT be
>   accessible by the client. In additi= on, the authorization server may
>   make use of HTTP referrer h= eaders in order to verify the origin of
>   requests made during= the authorization flow.
>
> In addition, I think that:
>=
>   The "state" request parameter SHOULD be used to mitigate ag= ainst CSRF
>   attacks, ...
>
> should be changed to= :
>
>   The "state" request parameter SHOULD be used to mi= tigate against CSRF
>   attacks against the client's redirection= URI, ...
>
> so that the fact that the 'state' parameter prote= cts against CSRF
> attacks on the *client*, as opposed to CSRF on the *authorization
> server*, is made explicit.
>
> -= - Niv
>
>
> On Fri, Aug 19, 2011 at 00:13, Eran Hammer-La= hav <eran@hueniverse.com>
> wrote:
>>
>&g= t;
>>> -----Original Message-----
>>> From: Niv Ste= ingarten [mailto:nivstein@gmail.com]
>>> Sent: Thursday, A= ugust 18, 2011 1:04 PM
>>> To: Eran Hammer-Lahav
>>>= ; Cc: Torsten Lodderstedt; oauth@ietf.org
>>> Subject: Re: [OAUTH-= WG] Draft 20 last call comment (Resource Owner
>>> Impersonatio= n)
>>>
>>> On Thu, Aug 18, 2011 at 22:19, Eran Hamm= er-Lahav <eran@hueniverse.com>
>>= ;> wrote:
>>> >
>>> >
>>> >= > -----Original Message-----
>>> >> From: Niv Steingar= ten [mailto:nivstein@gmail.com]
>>> >> Sent: Thursda= y, August 18, 2011 12:12 PM
>>> >> To: Eran Hammer-Lahav<= br>>>> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>>&g= t; >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Ow= ner
>>> >> Impersonation)
>>> >>
>= ;>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav
>= >> >> <eran@hueniverse.com>
>>> >&g= t; wrote:
>>> >> >
>>> >> >
>= >> >> >> -----Original Message-----
>>> >&= gt; >> From: Niv Steingarten [mailto:nivstein@gmail.com]
>= >> >> >> Sent: Thursday, August 18, 2011 11:08 AM
>= >> >> >> To: Eran Hammer-Lahav
>>> >> &= gt;> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> >> >= > Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner
= >>> >> >> Impersonation)
>>> >> >= >
>>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran = Hammer-Lahav
>>> >> >> <eran@hueniverse.com>
>>= ;> >> >> wrote:
>>> >> >> >
&g= t;>> >> >> >
>>> >> >> >>= ; -----Original Message-----
>>> >> >> >> Fro= m: Niv Steingarten [mailto:nivstein@gmail.com]
>>> >>= ; >> >> Sent: Thursday, August 18, 2011 10:16 AM
>>>= ; >> >> >> To: Eran Hammer-Lahav
>>> >>= >> >> Cc: Torsten Lodderstedt; oauth@ietf.org
>>> >= ;> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment = (Resource
>>> >> >> >> Owner
>>> = >> >> >> Impersonation)
>>> >> >> >>
>>> >> >> > Can you provide another ex= ample with the same level of detail as
>>> >> >> &g= t; you
>>> >> >> provided below?
>>> &g= t;> >>
>>> >> >> The malicious client send= s a request to the authorization endpoint
>>> >> >>= with the appropriate parameters, and in return receives the markup
>= >> >> >> of the web-page which should be displayed to the= user in order to
>>> >> >> get consent. In additio= n, since the request is launched not via a
>>> >> >>= ; sandboxed user-agent, the client also has access to any
>>> &= gt;> >> 'Set-Cookie'
>>> >> >> HTTP header= s.
>>> >> >>
>>> >> >> Inst= ead of displaying the page to the user, the client extracts
>>> >> >> the web-form data (including th= e hidden nonce/token) which would
>>> >> >> be subm= itted when 'Allow' is clicked. It then forges the
>>> >> = >> appropriate POST request with the cookies, form data and referrer,=
>>> >> >> and dispatches it,
>>> >&= gt; >
>>> >> > SCENE MISSING [1]
>>> &g= t;> >
>>> >> >> to finally receive an access = token/authorization code in the
>>> >> >> redirecti= on.
>>> >> >
>>> >> > You skipped= the best part!
>>> >> >
>>> >> >= What do you mean by "dispatches it"? How is the resource owner
>>= > >> > tricked
>>> >> or abused to grant auth= orization unknowingly? I understand how your
>>> >> proposal "fixes" the first half, but not what kind of attack is>>> >> happening in the second half.
>>> >&= gt; >
>>> >>
>>> >> I might have acc= identally skipped the part where the user is already
>>> >&g= t; logged in at the authorization endpoint, so no log-in is required but>>> >> rather just allowing/denying access (correction: the= first request is
>>> >> sent using an HTTP framework/Web= Kit, so no access to cookies). Once
>>> >> it extracts th= e data from the web-form, the client has all the
>>> >> i= nformation it needs in order to create an HTTP request
>>> >=
>>> > No - the attacker does not have access to the session= cookie. It still
>>> > needs
>>> to find a way = to make a CSS call.
>>> >
>>>
>>> That's what I said -- "no access to c= ookies".
>>
>> You only said that about the first request= .
>>
>>> But since both requests (the one
>>&= gt; requesting the auth endpoint and the one simulating the
>>>= "allow") are sent from the same user-agent, the cookies are handled by
= >>> the
>>> user-agent itself. The client just POSTs t= he request with the appropriate
>>> parameters to the action en= dpoint of the form.
>>
>> That's not exactly right.
&g= t;>
>> This entire attack is based on:
>>
>> = 1. The presence of some session cookie or other user-agent state to bypass<= br>>> active authentication, and
>> 2. The ability of the ma= licious client to make CSS calls using #1.
>>
>> Everythi= ng else is a red herring because the ability to automate this
>> attack and make it more powerful is completely beside the= point. If you
>> deploy an effective CSRF protection, everything = else is a non-issue.
>>
>> This is why the client type do= es not matter when it comes to not using
>> CORS. The authorizatio= n server MUST NOT allow CSS calls on the authorization
>> endpoint= because that's the actual attack you described - using local state
>= > (session cookie) to make a CSS call. If the client makes direct calls = to the
>> authorization endpoint, it cannot impersonate the resour= ce owner.
>>
>>> >> and launch it using the same= HTTP framework/WebKit, simulating the
>>> >> "Allow" but= ton.
>>> >
>>> > This is still just a CSRF at= tack.
>>> >
>>>
>>> I think you may = be right. I still believe this particular style of attack
>>> on the
>>> authorization server is wort= h mentioning, be it in its own separate
>>> section or
>&= gt;> under the existing CSRF section (as you suggested).
>>
= >> This is not a style of attack but techniques to enhance other expl= oits, in
>> this case, CSRF. If you lack CSRF protection, then yes= , lack of resource
>> owner forced interaction will make it easier= to execute. But that's just a
>> tiny speed bump considering the = actual exploit.
>>
>> I don't see any reason to include t= his new text based on this threat
>> analysis.
>>
>= > However, this doesn't mean this discussion wasn't useful. We did ident= ify
>> the need to explicitly discuss CSRF attacks on the authoriz= ation endpoint.
>> We need to explicitly separate the two target o= f CSRF attacks (client,
>> server) because while the solution is the same, the implementation is very
>> different (du= e to the use of redirections in one).
>>
>> EHL
>&g= t;
>>
>>
>>
>>
>>
> ____= ___________________________________________
> OAuth mailing list
&= gt; OAu= th@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
&= gt;
>
>


--0-415210984-1313727679=:93999-- From eran@hueniverse.com Thu Aug 18 22:05:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDBB21F86A9 for ; Thu, 18 Aug 2011 22:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YXhWHJEBnAJ for ; Thu, 18 Aug 2011 22:05:43 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 8E9FB21F8686 for ; Thu, 18 Aug 2011 22:05:43 -0700 (PDT) Received: (qmail 20570 invoked from network); 19 Aug 2011 05:06:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Aug 2011 05:06:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 18 Aug 2011 22:06:37 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , Niv Steingarten Date: Thu, 18 Aug 2011 22:05:16 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: AcxeJ3OsrSR8GgyMQrOI5G5SpDLwyQABeJ/w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345029DFABD6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1313711215.67102.YahooMailNeo@web31808.mail.mud.yahoo.com> <1313727679.93999.YahooMailNeo@web31802.mail.mud.yahoo.com> In-Reply-To: <1313727679.93999.YahooMailNeo@web31802.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72345029DFABD6P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 05:05:47 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFABD6P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To reiterate Berry's earlier point, we are not going to cover everything in= the v2 spec. We need to agree on new language for the CSRF section, and ad= d the potential attacks on both endpoints. But beyond that, it will probabl= y be best to add it to the threat model document - but I will leave that up= to the editors of that document. EHL From: William J. Mills [mailto:wmills@yahoo-inc.com] Sent: Thursday, August 18, 2011 9:21 PM To: Niv Steingarten Cc: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Imperson= ation) While I agree in principal, I think there are real world use cases that mak= e this more complicated. If, for example, a user has previously approved a= ccess to a particular endpoint then we might be willing to re-issue credent= ials without user interaction. I don't know how we capture this in the rig= ht way in the spec. ________________________________ From: Niv Steingarten > To: William J. Mills > Cc: Eran Hammer-Lahav >; "o= auth@ietf.org" > Sent: Thursday, August 18, 2011 6:06 PM Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Imperson= ation) I suppose you're talking about this: http://www.ietf.org/mail-archive/web/oauth/current/msg07275.html It is indeed more complete w.r.t. CSRF attacks on the client's redirection URI, but it does not address CSRF attacks on the authorization server. I believe something along the lines of the text I proposed could be combined in whichever text is eventually decided upon. -- Niv On Fri, Aug 19, 2011 at 02:46, William J. Mills > wrote: > I proposed text that I think is more complete in a previous message... > ________________________________ > From: Niv Steingarten > > To: Eran Hammer-Lahav > > Cc: "oauth@ietf.org" > > Sent: Thursday, August 18, 2011 4:33 PM > Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner > Impersonation) > > How about add something like this as the second paragraph in 10.12: > > The authorization server SHOULD employ measures to prevent CSRF > attacks on the authorization endpoint. A non-guessable token SHOULD > be included in requests and form submissions within the authorization > server's internal authorization flow. This token MUST NOT be > accessible by the client. In addition, the authorization server may > make use of HTTP referrer headers in order to verify the origin of > requests made during the authorization flow. > > In addition, I think that: > > The "state" request parameter SHOULD be used to mitigate against CSRF > attacks, ... > > should be changed to: > > The "state" request parameter SHOULD be used to mitigate against CSRF > attacks against the client's redirection URI, ... > > so that the fact that the 'state' parameter protects against CSRF > attacks on the *client*, as opposed to CSRF on the *authorization > server*, is made explicit. > > -- Niv > > > On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav > > wrote: >> >> >>> -----Original Message----- >>> From: Niv Steingarten [mailto:nivstein@gmail.com] >>> Sent: Thursday, August 18, 2011 1:04 PM >>> To: Eran Hammer-Lahav >>> Cc: Torsten Lodderstedt; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >>> Impersonation) >>> >>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav > >>> wrote: >>> > >>> > >>> >> -----Original Message----- >>> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >>> >> Sent: Thursday, August 18, 2011 12:12 PM >>> >> To: Eran Hammer-Lahav >>> >> Cc: Torsten Lodderstedt; oauth@ietf.org >>> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner >>> >> Impersonation) >>> >> >>> >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav >>> >> > >>> >> wrote: >>> >> > >>> >> > >>> >> >> -----Original Message----- >>> >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >>> >> >> Sent: Thursday, August 18, 2011 11:08 AM >>> >> >> To: Eran Hammer-Lahav >>> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >>> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owne= r >>> >> >> Impersonation) >>> >> >> >>> >> >> On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav >>> >> >> > >>> >> >> wrote: >>> >> >> > >>> >> >> > >>> >> >> >> -----Original Message----- >>> >> >> >> From: Niv Steingarten [mailto:nivstein@gmail.com] >>> >> >> >> Sent: Thursday, August 18, 2011 10:16 AM >>> >> >> >> To: Eran Hammer-Lahav >>> >> >> >> Cc: Torsten Lodderstedt; oauth@ietf.org >>> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource >>> >> >> >> Owner >>> >> >> >> Impersonation) >>> >> >> >> >>> >> >> > Can you provide another example with the same level of detail a= s >>> >> >> > you >>> >> >> provided below? >>> >> >> >>> >> >> The malicious client sends a request to the authorization endpoin= t >>> >> >> with the appropriate parameters, and in return receives the marku= p >>> >> >> of the web-page which should be displayed to the user in order to >>> >> >> get consent. In addition, since the request is launched not via a >>> >> >> sandboxed user-agent, the client also has access to any >>> >> >> 'Set-Cookie' >>> >> >> HTTP headers. >>> >> >> >>> >> >> Instead of displaying the page to the user, the client extracts >>> >> >> the web-form data (including the hidden nonce/token) which would >>> >> >> be submitted when 'Allow' is clicked. It then forges the >>> >> >> appropriate POST request with the cookies, form data and referrer= , >>> >> >> and dispatches it, >>> >> > >>> >> > SCENE MISSING [1] >>> >> > >>> >> >> to finally receive an access token/authorization code in the >>> >> >> redirection. >>> >> > >>> >> > You skipped the best part! >>> >> > >>> >> > What do you mean by "dispatches it"? How is the resource owner >>> >> > tricked >>> >> or abused to grant authorization unknowingly? I understand how your >>> >> proposal "fixes" the first half, but not what kind of attack is >>> >> happening in the second half. >>> >> > >>> >> >>> >> I might have accidentally skipped the part where the user is already >>> >> logged in at the authorization endpoint, so no log-in is required bu= t >>> >> rather just allowing/denying access (correction: the first request i= s >>> >> sent using an HTTP framework/WebKit, so no access to cookies). Once >>> >> it extracts the data from the web-form, the client has all the >>> >> information it needs in order to create an HTTP request >>> > >>> > No - the attacker does not have access to the session cookie. It stil= l >>> > needs >>> to find a way to make a CSS call. >>> > >>> >>> That's what I said -- "no access to cookies". >> >> You only said that about the first request. >> >>> But since both requests (the one >>> requesting the auth endpoint and the one simulating the >>> "allow") are sent from the same user-agent, the cookies are handled by >>> the >>> user-agent itself. The client just POSTs the request with the appropria= te >>> parameters to the action endpoint of the form. >> >> That's not exactly right. >> >> This entire attack is based on: >> >> 1. The presence of some session cookie or other user-agent state to bypa= ss >> active authentication, and >> 2. The ability of the malicious client to make CSS calls using #1. >> >> Everything else is a red herring because the ability to automate this >> attack and make it more powerful is completely beside the point. If you >> deploy an effective CSRF protection, everything else is a non-issue. >> >> This is why the client type does not matter when it comes to not using >> CORS. The authorization server MUST NOT allow CSS calls on the authoriza= tion >> endpoint because that's the actual attack you described - using local st= ate >> (session cookie) to make a CSS call. If the client makes direct calls to= the >> authorization endpoint, it cannot impersonate the resource owner. >> >>> >> and launch it using the same HTTP framework/WebKit, simulating the >>> >> "Allow" button. >>> > >>> > This is still just a CSRF attack. >>> > >>> >>> I think you may be right. I still believe this particular style of atta= ck >>> on the >>> authorization server is worth mentioning, be it in its own separate >>> section or >>> under the existing CSRF section (as you suggested). >> >> This is not a style of attack but techniques to enhance other exploits, = in >> this case, CSRF. If you lack CSRF protection, then yes, lack of resource >> owner forced interaction will make it easier to execute. But that's just= a >> tiny speed bump considering the actual exploit. >> >> I don't see any reason to include this new text based on this threat >> analysis. >> >> However, this doesn't mean this discussion wasn't useful. We did identif= y >> the need to explicitly discuss CSRF attacks on the authorization endpoin= t. >> We need to explicitly separate the two target of CSRF attacks (client, >> server) because while the solution is the same, the implementation is ve= ry >> different (due to the use of redirections in one). >> >> EHL >> >> >> >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFABD6P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To reiter= ate Berry’s earlier point, we are not going to cover everything in th= e v2 spec. We need to agree on new language for the CSRF section, and add t= he potential attacks on both endpoints. But beyond that, it will probably b= e best to add it to the threat model document – but I will leave that= up to the editors of that document.

 

EHL=

 

From: William J. Mills [mailto:wmills= @yahoo-inc.com]
Sent: Thursday, August 18, 2011 9:21 PM
To= : Niv Steingarten
Cc: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Imp= ersonation)

&nbs= p;

While I a= gree in principal, I think there are real world use cases that make this mo= re complicated.  If, for example, a user has previously approved acces= s to a particular endpoint then we might be willing to re-issue credentials= without user interaction.  I don't know how we capture this in the ri= ght way in the spec.

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black= '>

From:<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:black= '> Niv Steingarten <nivstein@gmail= .com>
To: William J. Mills <wmills@yahoo-inc.com>
Cc: Eran Hammer-Lahav &= lt;eran@hueniverse.com>; &quo= t;oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, Au= gust 18, 2011 6:06 PM
Subject: Re: [OAUTH-WG] Draft 20 last call = comment (Resource Owner Impersonation)

I suppose you're talking about this:
http://ww= w.ietf.org/mail-archive/web/oauth/current/msg07275.html

It is in= deed more complete w.r.t. CSRF attacks on the client's
redirection URI, = but it does not address CSRF attacks on the
authorization server.
I believe something along the lines of the text I proposed could be
com= bined in whichever text is eventually decided upon.

-- Niv

On Fri, Aug 19, 2011 at 02:46, William J. Mills <wmills@yahoo-inc.com> wrote:
> I proposed t= ext that I think is more complete in a previous message...
> ________= ________________________
> From: Niv Steingarten <nivstein@gmail.com>
> To: Eran Hammer-La= hav <eran@hueniverse.com><= br>> Cc: "oauth@ietf.org"= ; <oauth@ietf.org>
> Sent= : Thursday, August 18, 2011 4:33 PM
> Subject: Re: [OAUTH-WG] Draft 2= 0 last call comment (Resource Owner
> Impersonation)
>
> = How about add something like this as the second paragraph in 10.12:
>=
>   The authorization server SHOULD employ measures to prevent = CSRF
>   attacks on the authorization endpoint. A non-guessable = token SHOULD
>   be included in requests and form submissions wi= thin the authorization
>   server's internal authorization flow.= This token MUST NOT be
>   accessible by the client. In additio= n, the authorization server may
>   make use of HTTP referrer he= aders in order to verify the origin of
>   requests made during = the authorization flow.
>
> In addition, I think that:
><= br>>   The "state" request parameter SHOULD be used to mi= tigate against CSRF
>   attacks, ...
>
> should be c= hanged to:
>
>   The "state" request parameter S= HOULD be used to mitigate against CSRF
>   attacks against the c= lient's redirection URI, ...
>
> so that the fact that the 'sta= te' parameter protects against CSRF
> attacks on the *client*, as opp= osed to CSRF on the *authorization
> server*, is made explicit.
&g= t;
> -- Niv
>
>
> On Fri, Aug 19, 2011 at 00:13, Er= an Hammer-Lahav <eran@hueniverse.= com>
> wrote:
>>
>>
>>> -----Ori= ginal Message-----
>>> From: Niv Steingarten [mailto:nivstein@gmail.com]
>>> Sent: T= hursday, August 18, 2011 1:04 PM
>>> To: Eran Hammer-Lahav
&= gt;>> Cc: Torsten Lodderstedt; oaut= h@ietf.org
>>> Subject: Re: [OAUTH-WG] Draft 20 last call c= omment (Resource Owner
>>> Impersonation)
>>>
&g= t;>> On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav <eran@hueniverse.com>
>>> wro= te:
>>> >
>>> >
>>> >> ----= -Original Message-----
>>> >> From: Niv Steingarten [mail= to:nivstein@gmail.com]
>>= ;> >> Sent: Thursday, August 18, 2011 12:12 PM
>>> >= ;> To: Eran Hammer-Lahav
>>> >> Cc: Torsten Loddersted= t; oauth@ietf.org
>>> >= ;> Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner>>> >> Impersonation)
>>> >>
>>&= gt; >> On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav
>>&g= t; >> <eran@hueniverse.com<= /a>>
>>> >> wrote:
>>> >> >
&g= t;>> >> >
>>> >> >> -----Original Me= ssage-----
>>> >> >> From: Niv Steingarten [mailto:= nivstein@gmail.com]
>>&g= t; >> >> Sent: Thursday, August 18, 2011 11:08 AM
>>&g= t; >> >> To: Eran Hammer-Lahav
>>> >> >>= ; Cc: Torsten Lodderstedt; oauth@ietf.org=
>>> >> >> Subject: Re: [OAUTH-WG] Draft 20 las= t call comment (Resource Owner
>>> >> >> Impersonat= ion)
>>> >> >>
>>> >> >> On= Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav
>>> >> >= ;> <eran@hueniverse.com>= ;
>>> >> >> wrote:
>>> >> >>= ; >
>>> >> >> >
>>> >> >= > >> -----Original Message-----
>>> >> >> = >> From: Niv Steingarten [mailto:nivstein@gmail.com]
>>> >> >> >> Sent: = Thursday, August 18, 2011 10:16 AM
>>> >> >> >&g= t; To: Eran Hammer-Lahav
>>> >> >> >> Cc: Tor= sten Lodderstedt; oauth@ietf.org
&= gt;>> >> >> >> Subject: Re: [OAUTH-WG] Draft 20 las= t call comment (Resource
>>> >> >> >> Owner>>> >> >> >> Impersonation)
>>> &g= t;> >> >>
>>> >> >> > Can you pro= vide another example with the same level of detail as
>>> >&= gt; >> > you
>>> >> >> provided below?
= >>> >> >>
>>> >> >> The malici= ous client sends a request to the authorization endpoint
>>> &g= t;> >> with the appropriate parameters, and in return receives the= markup
>>> >> >> of the web-page which should be d= isplayed to the user in order to
>>> >> >> get cons= ent. In addition, since the request is launched not via a
>>> &= gt;> >> sandboxed user-agent, the client also has access to any>>> >> >> 'Set-Cookie'
>>> >> >&= gt; HTTP headers.
>>> >> >>
>>> >>= ; >> Instead of displaying the page to the user, the client extracts<= br>>>> >> >> the web-form data (including the hidden n= once/token) which would
>>> >> >> be submitted when= 'Allow' is clicked. It then forges the
>>> >> >> a= ppropriate POST request with the cookies, form data and referrer,
>&g= t;> >> >> and dispatches it,
>>> >> >>>> >> > SCENE MISSING [1]
>>> >> >= ;
>>> >> >> to finally receive an access token/auth= orization code in the
>>> >> >> redirection.
>= ;>> >> >
>>> >> > You skipped the best = part!
>>> >> >
>>> >> > What do y= ou mean by "dispatches it"? How is the resource owner
>>= > >> > tricked
>>> >> or abused to grant auth= orization unknowingly? I understand how your
>>> >> propo= sal "fixes" the first half, but not what kind of attack is
>= ;>> >> happening in the second half.
>>> >> &= gt;
>>> >>
>>> >> I might have accident= ally skipped the part where the user is already
>>> >> lo= gged in at the authorization endpoint, so no log-in is required but
>= >> >> rather just allowing/denying access (correction: the firs= t request is
>>> >> sent using an HTTP framework/WebKit, = so no access to cookies). Once
>>> >> it extracts the dat= a from the web-form, the client has all the
>>> >> inform= ation it needs in order to create an HTTP request
>>> >
&= gt;>> > No - the attacker does not have access to the session cook= ie. It still
>>> > needs
>>> to find a way to ma= ke a CSS call.
>>> >
>>>
>>> That's = what I said -- "no access to cookies".
>>
>> Yo= u only said that about the first request.
>>
>>> But s= ince both requests (the one
>>> requesting the auth endpoint an= d the one simulating the
>>> "allow") are sent from t= he same user-agent, the cookies are handled by
>>> the
>&= gt;> user-agent itself. The client just POSTs the request with the appro= priate
>>> parameters to the action endpoint of the form.
&g= t;>
>> That's not exactly right.
>>
>> This e= ntire attack is based on:
>>
>> 1. The presence of some s= ession cookie or other user-agent state to bypass
>> active authen= tication, and
>> 2. The ability of the malicious client to make CS= S calls using #1.
>>
>> Everything else is a red herring = because the ability to automate this
>> attack and make it more po= werful is completely beside the point. If you
>> deploy an effecti= ve CSRF protection, everything else is a non-issue.
>>
>>= This is why the client type does not matter when it comes to not using
= >> CORS. The authorization server MUST NOT allow CSS calls on the aut= horization
>> endpoint because that's the actual attack you descri= bed - using local state
>> (session cookie) to make a CSS call. If= the client makes direct calls to the
>> authorization endpoint, i= t cannot impersonate the resource owner.
>>
>>> >&g= t; and launch it using the same HTTP framework/WebKit, simulating the
&g= t;>> >> "Allow" button.
>>> >
>&= gt;> > This is still just a CSRF attack.
>>> >
>= >>
>>> I think you may be right. I still believe this par= ticular style of attack
>>> on the
>>> authorizatio= n server is worth mentioning, be it in its own separate
>>> sec= tion or
>>> under the existing CSRF section (as you suggested).=
>>
>> This is not a style of attack but techniques to en= hance other exploits, in
>> this case, CSRF. If you lack CSRF prot= ection, then yes, lack of resource
>> owner forced interaction wil= l make it easier to execute. But that's just a
>> tiny speed bump = considering the actual exploit.
>>
>> I don't see any rea= son to include this new text based on this threat
>> analysis.
= >>
>> However, this doesn't mean this discussion wasn't usef= ul. We did identify
>> the need to explicitly discuss CSRF attacks= on the authorization endpoint.
>> We need to explicitly separate = the two target of CSRF attacks (client,
>> server) because while t= he solution is the same, the implementation is very
>> different (= due to the use of redirections in one).
>>
>> EHL
>= >
>>
>>
>>
>>
>>
> __= _____________________________________________
> OAuth mailing list> OAuth@ietf.org
> https://= www.ietf.org/mailman/listinfo/oauth
>
>
>

= --_000_90C41DD21FB7C64BB94121FBBC2E72345029DFABD6P3PW5EX1MB01E_-- From jricher@mitre.org Fri Aug 19 04:55:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBB421F8AEC for ; Fri, 19 Aug 2011 04:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZj+EtG7Hc83 for ; Fri, 19 Aug 2011 04:55:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7A22F21F8AEA for ; Fri, 19 Aug 2011 04:55:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 813A221B11D3; Fri, 19 Aug 2011 07:56:15 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 551A821B11B0; Fri, 19 Aug 2011 07:56:15 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 19 Aug 2011 07:56:15 -0400 From: "Richer, Justin P." To: Eran Hammer-Lahav , "Lu, Hui-Lan (Huilan)" , Brian Campbell Date: Fri, 19 Aug 2011 07:55:56 -0400 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxNWiAmwaoXWhpRRLSIm3Z69CEQXANudKkQALSSvmAAAWgcIAAexYj7 Message-ID: References: <4E317125.7080006@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244272@USNAVSXCHMBSB3.ndc.alcatel-lucent.com>, <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 11:55:22 -0000 I find the original text clearer, myself. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Thursday, August 18, 2011 5:16 PM To: Lu, Hui-Lan (Huilan); Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification > -----Original Message----- > From: Lu, Hui-Lan (Huilan) [mailto:huilan.lu@alcatel-lucent.com] > Sent: Thursday, August 18, 2011 1:45 PM > To: Eran Hammer-Lahav; Brian Campbell > Cc: oauth > Subject: RE: [OAUTH-WG] treatment of client_id for authentication and > identification > > Eran Hammer-Lahav wrote: > > Added to 2.4.1: > > > > client_secret > > REQUIRED. The client secret. The client MAY omit the > > parameter if the client secret > > is an empty string. > > I would suggest rewording the above as follows: > client_secret > REQUIRED unless it is an empty string. The client secret. "unless its value is an empty string". Do people read this new text to mean= OPTIONAL if not empty? > > Added to 3.2.1: > > > > A public client that was not issued a client password MAY u= se the > > 'client_id' request parameter to identify itself when sendi= ng > > requests to the token endpoint. > > It is difficult to parse the last sentence of 3.2.1: "The security ramifi= cations of > allowing unauthenticated access by public clients to the token endpoint > MUST be considered, as well as the issuance of refresh tokens to public > clients, their scope, and lifetime." > > I think it should be rewritten and reference relevant parts of security > considerations. Text? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From internet-drafts@ietf.org Fri Aug 19 06:56:18 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A7821F8834; Fri, 19 Aug 2011 06:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9976Re4AAjE; Fri, 19 Aug 2011 06:56:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146DD21F87C5; Fri, 19 Aug 2011 06:56:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110819135618.4006.79378.idtracker@ietfa.amsl.com> Date: Fri, 19 Aug 2011 06:56:18 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 13:56:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-06.txt Pages : 15 Date : 2011-08-19 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-06.txt From bcampbell@pingidentity.com Fri Aug 19 07:05:52 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EB121F8A91 for ; Fri, 19 Aug 2011 07:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.962 X-Spam-Level: X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqzFBtR-4k0X for ; Fri, 19 Aug 2011 07:05:51 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF8E21F8ACA for ; Fri, 19 Aug 2011 07:05:51 -0700 (PDT) Received: from mail-qw0-f48.google.com ([209.85.216.48]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTk5t7/RNK72AXpuLPf1JLbUYwW4qtiX3@postini.com; Fri, 19 Aug 2011 07:06:48 PDT Received: by qwj9 with SMTP id 9so2987973qwj.35 for ; Fri, 19 Aug 2011 07:06:39 -0700 (PDT) Received: by 10.224.194.198 with SMTP id dz6mr2122088qab.183.1313762799100; Fri, 19 Aug 2011 07:06:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.67.129 with HTTP; Fri, 19 Aug 2011 07:06:09 -0700 (PDT) In-Reply-To: <20110819135618.4006.79378.idtracker@ietfa.amsl.com> References: <20110819135618.4006.79378.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 19 Aug 2011 08:06:09 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-saml2-bearer-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 14:05:52 -0000 This -06 draft at http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-06 contains only a few fixes to typos identified by my colleague Peter Motykowski. ---------- Forwarded message ---------- From: Date: Fri, Aug 19, 2011 at 7:56 AM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-06.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SAML 2.0 Bearer Assertion Profil= es for OAuth 2.0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Chuck Mortimore =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-saml2-bearer-06.t= xt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-08-19 =A0 This specification defines the use of a SAML 2.0 Bearer Assertion as =A0 means for requesting an OAuth 2.0 access token as well as for use as =A0 a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-06.txt _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Sun Aug 21 10:58:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71D821F886A for ; Sun, 21 Aug 2011 10:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1VzPw59pKaI for ; Sun, 21 Aug 2011 10:58:09 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0244021F8781 for ; Sun, 21 Aug 2011 10:58:08 -0700 (PDT) Received: from [79.253.32.3] (helo=[192.168.71.26]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QvCIe-0003up-3d; Sun, 21 Aug 2011 19:59:08 +0200 Message-ID: <4E514770.7040405@lodderstedt.net> Date: Sun, 21 Aug 2011 19:59:12 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 17:58:09 -0000 Hi Eran, >>> This is still just a CSRF attack. >>> >> I think you may be right. I still believe this particular style of attack on the >> authorization server is worth mentioning, be it in its own separate section or >> under the existing CSRF section (as you suggested). > This is not a style of attack but techniques to enhance other exploits, in this case, CSRF. If you lack CSRF protection, then yes, lack of resource owner forced interaction will make it easier to execute. But that's just a tiny speed bump considering the actual exploit. > > I don't see any reason to include this new text based on this threat analysis. > > However, this doesn't mean this discussion wasn't useful. We did identify the need to explicitly discuss CSRF attacks on the authorization endpoint. We need to explicitly separate the two target of CSRF attacks (client, server) because while the solution is the same, the implementation is very different (due to the use of redirections in one). I agree, we should explicitely document these two variants of CSRF (client, authz server). But I suspect it's not only CSRF we are talking about in this thread - at least not textbook CSRF. Let me explain my thoughts: As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a "I agree" button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages ("send mouse click") or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal browser and perform an authorization flow with the resource owner for one particular scope. Using the same browser instance and based on the cookies obtained in the first run, it could silently perform additional authorization flows for other scopes. 4) internal browser (non-interactive authentication methods) - There are authentication methods available w/o the need for user-interaction, for examples SIM card authentication or certificate-based authentication. The attacker could utilize an internal, invisible browser instance in combination with such an authentication method in order to perform the authorization process. I'm not sure whether the scenarios described above can be classified as CSRF. regards, Torsten. From torsten@lodderstedt.net Sun Aug 21 11:03:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42CD21F8781 for ; Sun, 21 Aug 2011 11:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gixPDS1bZqdS for ; Sun, 21 Aug 2011 11:03:21 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id 5D32C21F8511 for ; Sun, 21 Aug 2011 11:03:20 -0700 (PDT) Received: from [79.253.32.3] (helo=[192.168.71.26]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QvCNh-0000Fd-QI; Sun, 21 Aug 2011 20:04:22 +0200 Message-ID: <4E5148A8.8070903@lodderstedt.net> Date: Sun, 21 Aug 2011 20:04:24 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------060901090002080403050006" X-Df-Sender: torsten@lodderstedt-online.de Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 18:03:23 -0000 This is a multi-part message in MIME format. --------------060901090002080403050006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My intention is to require clients to implement CSRF prevention. I thought making the state parameter mandatory would be the straightforward way. regards, Torsten. Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: > > I would like to hear from the other 3 authors of the proposed change > about their reasons for changing the use of 'state' from recommended > to required for CSRF prevention. It would also help moving this issue > forward if the 4 authors can provide answers or clarifications on the > issues raised below. > > Assuming we can count all 4 authors are in favor of making the change, > I believe we have a tie (4:4) and therefore no consensus for making it > (as of this point). However, we did identify issues with the section's > language and clarity which we should address either way. > > To clarify -- I am not proposing we close this issue just yet. > > EHL > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Eran Hammer-Lahav > *Sent:* Monday, August 15, 2011 9:35 AM > *To:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Auth Code Swap Attack > > To demonstrate why making state required as proposed isn't very > helpful, here is an incomplete list of other requirements needed to > make an effective CSRF: > > * State value must not be empty (a common bug in many implementations > using simple value comparison). > > * 'Non-guessable' isn't sufficient as most developers will simply use > a hash of the session cookie, with or without salt which isn't > sufficient. We use "cannot be generated, modified, or guessed to > produce valid values" elsewhere in the document, but this is much > easier to get right for access tokens and refresh tokens than CSRF > tokens which are often just some algorithm on top of the session cookie. > > * State CSRF value should be short-lived or based on a short-lived > session cookie to prevent the use of a leaked state value in multiple > attacks on the same user session once the leak is no longer viable. > > In addition, this is not what "state" was originally intended for. If > the working group decides to mandate a CSRF parameter, it should > probably be a new parameter with a more appropriate name (e.g. > 'csrf'). By forcing clients to use "state" for this purpose, > developers will need to use dynamic queries for other state > information which further reduces the security of the protocol (as the > draft recommends not using dynamic callback query components). > Encoding both CSRF tokens and other state information can be > non-intuitive or complicated for some developers/platforms. > > EHL > > *From:*Eran Hammer-Lahav > *Sent:* Friday, August 12, 2011 2:53 PM > *To:* Anthony Nadalin; OAuth WG (oauth@ietf.org ) > *Subject:* Re: [OAUTH-WG] Auth Code Swap Attack > > This is really just a flavor of CSRF attacks. I have no objections to > better documenting it (though I feel the current text is already > sufficient), but we can't realistically expect to identify and close > every possible browser-based attack. A new one is invented every other > week. > > The problem with this text is that developers who do no understand > CSRF attacks are not likely to implement it correctly with this > information. Those who understand it do not need the extra verbiage > which is more confusing than helpful. > > As for the new requirements, they are insufficient to actually > accomplish what the authors propose without additional requirements on > state local storage and verification to complete the flow. Also, the > proposed text needs clarifications as noted below. > > *From: *Anthony Nadalin > > *Date: *Fri, 12 Aug 2011 12:06:36 -0700 > *To: *"OAuth WG (oauth@ietf.org )" > > > *Subject: *[OAUTH-WG] Auth Code Swap Attack > > *Recommended Changes to draft-ietf-oauth-v2* > > In section 4, request options (e.g. 4.1.1) featuring "state" > should change from: > > state > > OPTIONAL. An opaque value used by the client to maintain state > between the request and callback. The authorization server > includes this value when redirecting the user-agent back to the > client. > > to: > > state > > REQUIRED. An opaque value used by the client to maintain state > between the request and callback. The authorization server > includes this value when redirecting the user-agent back to the > client. The encoded value SHOULD enable the client application to > determine the user-context that was active at the time of the > request (see section 10.12). The value MUST NOT be guessable or > predictable, and MUST be kept confidential. > > Making the parameter required without making its usage required (I.e. > "value SHOULD enable") accomplishes nothing. Also, what does "MUST be > kept confidential" mean? Confidential from what? Why specify an > "encoded value"? > > Section 10.12 Cross-Site Request Forgery > > Change to: > > Cross-site request forgery (CSRF) is a web-based attack whereby > HTTP requests are transmitted from the user-agent of an > end-user the server trusts or has authenticated. CSRF attacks > enable the attacker to intermix the attacker's security context > with that of the resource owner resulting in a compromise of > either the resource server or of the client application itself. In > the OAuth context, such attacks allow an attacker to inject their > own authorization code or access token into a client, which can > result in the client using an access token associated with the > attacker's account rather than the victim's. Depending on the > nature of the client and the protected resources, this can have > undesirable and damaging effects. > > In order to prevent such attacks, the client application MUST > encode a non-guessable, confidential end-user artifact and submit > as the "state" parameter to authorization and access token > requests to the authorization server. The client MUST keep the > state value in a location accessible only by the client or the > user-agent (i.e., protected by same-origin policy), for example, > using a DOM variable, HTTP cookie, or HTML5 client-side storage. > > The authorization server includes the value of the "state" > parameter when redirecting the user-agent back to the client. > Upon receiving a redirect, the client application MUST confirm > that returned value of "state" corresponds to the state value of > the user-agent's user session. If the end-user session represents > an authenticated user-identity, the client MUST ensure that the > user-identity has NOT changed. > > The above text uses 'user-context' and this 'user-identity'. Neither > term is defined. > > EHL > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------060901090002080403050006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit My intention is to require clients to implement CSRF prevention. I thought making the state parameter mandatory would be the straightforward way.

regards,
Torsten.

Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav:

I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of ‘state’ from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below.

 

Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section’s language and clarity which we should address either way.

 

To clarify – I am not proposing we close this issue just yet.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

To demonstrate why making state required as proposed isn’t very helpful, here is an incomplete list of other requirements needed to make an effective CSRF:

 

* State value must not be empty (a common bug in many implementations using simple value comparison).

 

* ‘Non-guessable’ isn’t sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn’t sufficient. We use “cannot be generated, modified, or guessed to produce valid values” elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie.

 

* State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable.

 

In addition, this is not what “state” was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. ‘csrf’). By forcing clients to use “state” for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms.

 

EHL

 

 

 

 

From: Eran Hammer-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week.

 

The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful.

 

As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below.

 

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack

 

 

 

Recommended Changes to draft-ietf-oauth-v2

 

In section 4, request options (e.g. 4.1.1) featuring "state" should change from:

 

state

OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.

 

to:

 

state

REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the  request (see section 10.12). The value MUST NOT be guessable or predictable, and MUST be kept confidential.

 

 

Making the parameter required without making its usage required (I.e. "value SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confidential" mean? Confidential from what? Why specify an "encoded value"?

 

 

Section 10.12 Cross-Site Request Forgery

 

Change to:

 

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to inject their own authorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the "state" parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parameter when redirecting the user-agent back to the client. Upon receiving a redirect, the client application MUST confirm that returned value of "state" corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has NOT changed.

 

 

The above text uses 'user-context' and this 'user-identity'. Neither term is defined.

 

EHL



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------060901090002080403050006-- From eran@hueniverse.com Sun Aug 21 12:04:39 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8906E21F8B19 for ; Sun, 21 Aug 2011 12:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxg3LW3MIl9U for ; Sun, 21 Aug 2011 12:04:35 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 3180221F8B18 for ; Sun, 21 Aug 2011 12:04:34 -0700 (PDT) Received: (qmail 30245 invoked from network); 21 Aug 2011 19:05:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Aug 2011 19:05:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 21 Aug 2011 12:04:04 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Sun, 21 Aug 2011 12:02:41 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxgLMN0Y2Y+vxPHR3aUSIUK/Z5JuAACAwIQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> In-Reply-To: <4E5148A8.8070903@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234518A292F49P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 19:04:39 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234518A292F49P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I light to the recent discussion, do you still feel that changing 'state' f= rom optional to required is the best approach? EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, August 21, 2011 11:04 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack My intention is to require clients to implement CSRF prevention. I thought = making the state parameter mandatory would be the straightforward way. regards, Torsten. Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: I would like to hear from the other 3 authors of the proposed change about = their reasons for changing the use of 'state' from recommended to required = for CSRF prevention. It would also help moving this issue forward if the 4 = authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I be= lieve we have a tie (4:4) and therefore no consensus for making it (as of t= his point). However, we did identify issues with the section's language and= clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, he= re is an incomplete list of other requirements needed to make an effective = CSRF: * State value must not be empty (a common bug in many implementations using= simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a has= h of the session cookie, with or without salt which isn't sufficient. We us= e "cannot be generated, modified, or guessed to produce valid values" elsew= here in the document, but this is much easier to get right for access token= s and refresh tokens than CSRF tokens which are often just some algorithm o= n top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session = cookie to prevent the use of a leaked state value in multiple attacks on th= e same user session once the leak is no longer viable. In addition, this is not what "state" was originally intended for. If the w= orking group decides to mandate a CSRF parameter, it should probably be a n= ew parameter with a more appropriate name (e.g. 'csrf'). By forcing clients= to use "state" for this purpose, developers will need to use dynamic queri= es for other state information which further reduces the security of the pr= otocol (as the draft recommends not using dynamic callback query components= ). Encoding both CSRF tokens and other state information can be non-intuiti= ve or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to bette= r documenting it (though I feel the current text is already sufficient), bu= t we can't realistically expect to identify and close every possible browse= r-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF att= acks are not likely to implement it correctly with this information. Those = who understand it do not need the extra verbiage which is more confusing th= an helpful. As for the new requirements, they are insufficient to actually accomplish w= hat the authors propose without additional requirements on state local stor= age and verification to complete the flow. Also, the proposed text needs cl= arifications as noted below. From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring "state" should change = from: state OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable= the client application to determine the user-context that was active at th= e time of the request (see section 10.12). The value MUST NOT be guessable= or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. "valu= e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi= dential" mean? Confidential from what? Why specify an "encoded value"? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the resource owner resulting in a comprom= ise of either the resource server or of the client application itself. In t= he OAuth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather than th= e victim's. Depending on the nature of the client and the protected resourc= es, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "state" paramet= er to authorization and access token requests to the authorization server. = The client MUST keep the state value in a location accessible only by the c= lient or the user-agent (i.e., protected by same-origin policy), for exampl= e, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirect, th= e client application MUST confirm that returned value of "state" correspond= s to the state value of the user-agent's user session. If the end-user sess= ion represents an authenticated user-identity, the client MUST ensure that = the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term i= s defined. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E7234518A292F49P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I light to the recent discussion, do you stil= l feel that changing ‘state’ from optional to required is the b= est approach?

 

EHL

 

From: Torsten Lodderstedt [mai= lto:torsten@lodderstedt.net]
Sent: Sunday, August 21, 2011 11:04= AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)=
Subject: Re: [OAUTH-WG] Auth Code Swap Attack<= /p>

 

My intention is to require clients to implement CSRF prevention. I thoug= ht making the state parameter mandatory would be the straightforward way.
regards,
Torsten.

Am 18.08.2011 08:04, schrieb Eran Hammer-= Lahav:

I = would like to hear from the other 3 authors of the proposed change about th= eir reasons for changing the use of ‘state’ from recommended to= required for CSRF prevention. It would also help moving this issue forward= if the 4 authors can provide answers or clarifications on the issues raise= d below.

 

Assuming we can count all 4 authors are in favor of making the ch= ange, I believe we have a tie (4:4) and therefore no consensus for making i= t (as of this point). However, we did identify issues with the section̵= 7;s language and clarity which we should address either way.

 

To clarify &#= 8211; I am not proposing we close this issue just yet.

 

EHL

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To:<= /b> OAuth WG (oauth@ietf.org)
S= ubject: Re: [OAUTH-WG] Auth Code Swap Attack

 

To demonstrate why making state required as propos= ed isn’t very helpful, here is an incomplete list of other requiremen= ts needed to make an effective CSRF:

 

* State value must not be empty (a co= mmon bug in many implementations using simple value comparison).

 =

* ‘= Non-guessable’ isn’t sufficient as most developers will simply = use a hash of the session cookie, with or without salt which isn’t su= fficient. We use “cannot be generated, modified, or guessed to produc= e valid values” elsewhere in the document, but this is much easier to= get right for access tokens and refresh tokens than CSRF tokens which are = often just some algorithm on top of the session cookie.

 

* State CSRF value= should be short-lived or based on a short-lived session cookie to prevent = the use of a leaked state value in multiple attacks on the same user sessio= n once the leak is no longer viable.

 

In addition, this is not what “= state” was originally intended for. If the working group decides to m= andate a CSRF parameter, it should probably be a new parameter with a more = appropriate name (e.g. ‘csrf’). By forcing clients to use ̶= 0;state” for this purpose, developers will need to use dynamic querie= s for other state information which further reduces the security of the pro= tocol (as the draft recommends not using dynamic callback query components)= . Encoding both CSRF tokens and other state information can be non-intuitiv= e or complicated for some developers/platforms.

 

EHL

<= p class=3DMsoNormal> <= /p>

 

 

 =

From: Eran Hammer-La= hav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony = Nadalin; OAuth WG (oauth@ietf.org)Subject: Re: [OAUTH-WG] Auth Code Swap Attack

=

 

This is really just a flavor of CSRF = attacks. I have no objections to better documenting it (though I feel the c= urrent text is already sufficient), but we can't realistically expect to id= entify and close every possible browser-based attack. A new one is invented= every other week.

 

The problem with this text = is that developers who do no understand CSRF attacks are not likely to impl= ement it correctly with this information. Those who understand it do not ne= ed the extra verbiage which is more confusing than helpful.

&nbs= p;

As for the new requirements, they are insufficient to actuall= y accomplish what the authors propose without additional requirements on st= ate local storage and verification to complete the flow. Also, the proposed= text needs clarifications as noted below.

=

 

&nb= sp;

From: A= nthony Nadalin <tonynad@microso= ft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)&quo= t; <oauth@ietf.org>
Subje= ct: [OAUTH-WG] Auth Code Swap Attack

 

<= /div>

 

 

Recommended Changes to d= raft-ietf-oauth-v2

 

In section 4, request options (e.g= . 4.1.1) featuring "state" should change from:=

 

state

OPTIONAL. An opa= que value used by the client to maintain state between the request and call= back. The authorization server includes this value when redirecting the use= r-agent back to the client.

 

=

to:<= /p>

 

state

= REQUIRED. An opaque val= ue used by the client to maintain state between the request and callback. T= he authorization server includes this value when redirecting the user-agent= back to the client. The encoded value SHOULD enable the client application= to determine the user-context that was active at the time of the  req= uest (see section 10.12). The value MUST NOT be guessable or predictable, a= nd MUST be kept confidential.

 

 

Making the parameter required without making i= ts usage required (I.e. "value SHOULD enable") accomplishes nothi= ng. Also, what does "MUST be kept confidential" mean? Confidentia= l from what? Why specify an "encoded value"?

 

 

Section 10.12 Cross-Site Request Forgery

=

&n= bsp;

Cha= nge to:

 

Cross-site requ= est forgery (CSRF) is a web-based attack whereby HTTP requests are transmit= ted from the user-agent of an end-user the server trusts or has authen= ticated. CSRF attacks enable the attacker to intermix the attacker's securi= ty context with that of the resource owner resulting in a compromise o= f either the resource server or of the client application itself. In the OA= uth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather th= an the victim's. Depending on the nature of the client and the protected&nb= sp;resources, this can have undesirable and damaging effects.

In ord= er to prevent such attacks, the client application MUST encode a non-guessa= ble, confidential end-user artifact and submit as the "state"= ; parameter to authorization and access token requests to the authorization= server. The client MUST keep the state value in a location accessible= only by the client or the user-agent (i.e., protected by same-origin polic= y), for example, using a DOM variable, HTTP cookie, or HTML5 client-si= de storage.

The authorization server includes the value of the "= ;state" parameter when redirecting the user-agent back to the client. = Upon receiving a redirect, the client application MUST confirm that re= turned value of "state" corresponds to the state value of the use= r-agent's user session. If the end-user session represents an authenticated= user-identity, the client MUST ensure that the user-identity has NOT = changed.

 

 

The above text uses 'user-context' and this 'user-i= dentity'. Neither term is defined.

 

<= /div>

EHL<= o:p>




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
o:p>
= --_000_90C41DD21FB7C64BB94121FBBC2E7234518A292F49P3PW5EX1MB01E_-- From recordond@gmail.com Sun Aug 21 18:09:49 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27FD21F86B1 for ; Sun, 21 Aug 2011 18:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-6LWDt5NfAu for ; Sun, 21 Aug 2011 18:09:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 845C521F86AC for ; Sun, 21 Aug 2011 18:09:33 -0700 (PDT) Received: by vws12 with SMTP id 12so4624401vws.31 for ; Sun, 21 Aug 2011 18:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5d7au0f0M0xN1yDqsN4jl/J0EN1dWp6eDDZt40MijNs=; b=mavV7sJcj61wIufzvoKPhiUBuTB+L5U3Ess9ysNAXiNKD4dJY3zORRs0M9G6C8RHr+ vvMrYiTZTUI0GK7Rt/D6h8Z+j+v27FNYjqoUFbUc3lIqRaaNxefQj8MnaqeRuqUftzFm HYBYF3LpOpsdgDYAbM0DEib993GtP3IjbstP0= MIME-Version: 1.0 Received: by 10.52.65.168 with SMTP id y8mr1553583vds.16.1313975435235; Sun, 21 Aug 2011 18:10:35 -0700 (PDT) Received: by 10.52.164.170 with HTTP; Sun, 21 Aug 2011 18:10:35 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 21 Aug 2011 18:10:35 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 01:09:49 -0000 So far Facebook has used `state` in examples within our documentation and strongly recommend it but have not gone so far as to mandate it. Quoting https://developers.facebook.com/docs/authentication/: > Cross site request forgery is an attack in which an trusted (authenticate= d > and authorized) user unknowingly performs an action on website. To preven= t > this attack, you should pass an identifier in the state parameter, and th= en > validate the state parameter matches on the response. We strongly recomme= nd > that any app implementing Facebook user login implement CSRF protection u= sing > this mechanism. I'd rather clearly document this in the spec, strongly recommend a solution but not mandate this specific parameter. --David On Sun, Aug 21, 2011 at 12:02 PM, Eran Hammer-Lahav w= rote: > I light to the recent discussion, do you still feel that changing =91stat= e=92 > from optional to required is the best approach? > > > > EHL > > > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Sunday, August 21, 2011 11:04 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > My intention is to require clients to implement CSRF prevention. I though= t > making the state parameter mandatory would be the straightforward way. > > regards, > Torsten. > > Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: > > I would like to hear from the other 3 authors of the proposed change abou= t > their reasons for changing the use of =91state=92 from recommended to req= uired > for CSRF prevention. It would also help moving this issue forward if the = 4 > authors can provide answers or clarifications on the issues raised below. > > > > Assuming we can count all 4 authors are in favor of making the change, I > believe we have a tie (4:4) and therefore no consensus for making it (as = of > this point). However, we did identify issues with the section=92s languag= e and > clarity which we should address either way. > > > > To clarify =96 I am not proposing we close this issue just yet. > > > > EHL > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Eran Hammer-Lahav > Sent: Monday, August 15, 2011 9:35 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > To demonstrate why making state required as proposed isn=92t very helpful= , > here is an incomplete list of other requirements needed to make an effect= ive > CSRF: > > > > * State value must not be empty (a common bug in many implementations usi= ng > simple value comparison). > > > > * =91Non-guessable=92 isn=92t sufficient as most developers will simply u= se a hash > of the session cookie, with or without salt which isn=92t sufficient. We = use > =93cannot be generated, modified, or guessed to produce valid values=94 > elsewhere in the document, but this is much easier to get right for acces= s > tokens and refresh tokens than CSRF tokens which are often just some > algorithm on top of the session cookie. > > > > * State CSRF value should be short-lived or based on a short-lived sessio= n > cookie to prevent the use of a leaked state value in multiple attacks on = the > same user session once the leak is no longer viable. > > > > In addition, this is not what =93state=94 was originally intended for. If= the > working group decides to mandate a CSRF parameter, it should probably be = a > new parameter with a more appropriate name (e.g. =91csrf=92). By forcing = clients > to use =93state=94 for this purpose, developers will need to use dynamic = queries > for other state information which further reduces the security of the > protocol (as the draft recommends not using dynamic callback query > components). Encoding both CSRF tokens and other state information can be > non-intuitive or complicated for some developers/platforms. > > > > EHL > > > > > > > > > > From: Eran Hammer-Lahav > Sent: Friday, August 12, 2011 2:53 PM > To: Anthony Nadalin; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > This is really just a flavor of CSRF attacks. I have no objections to bet= ter > documenting it (though I feel the current text is already sufficient), bu= t > we can't realistically expect to identify and close every possible > browser-based attack. A new one is invented every other week. > > > > The problem with this text is that developers who do no understand CSRF > attacks are not likely to implement it correctly with this information. > Those who understand it do not need the extra verbiage which is more > confusing than helpful. > > > > As for the new requirements, they are insufficient to actually accomplish > what the authors propose without additional requirements on state local > storage and verification to complete the flow. Also, the proposed text ne= eds > clarifications as noted below. > > > > > > From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 > To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack > > > > > > > > Recommended Changes to draft-ietf-oauth-v2 > > > > In section 4, request options (e.g. 4.1.1) featuring "state" should chang= e > from: > > > > state > > OPTIONAL. An opaque value used by the client to maintain state between th= e > request and callback. The authorization server includes this value when > redirecting the user-agent back to the client. > > > > to: > > > > state > > REQUIRED. An opaque value used by the client to maintain state between th= e > request and callback. The authorization server includes this value when > redirecting the user-agent back to the client. The encoded value SHOULD > enable the client application to determine the user-context that was acti= ve > at the time of the =A0request (see section 10.12). The value MUST NOT be > guessable or predictable, and MUST be kept confidential. > > > > > > Making the parameter required without making its usage required (I.e. "va= lue > SHOULD enable") accomplishes nothing. Also, what does "MUST be kept > confidential" mean? Confidential from what? Why specify an "encoded value= "? > > > > > > Section 10.12 Cross-Site Request Forgery > > > > Change to: > > > > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP > requests are transmitted from the user-agent of an end-user=A0the server > trusts or has authenticated. CSRF attacks enable the attacker to intermix > the attacker's security context with that of the=A0resource owner resulti= ng in > a compromise of either the resource server or of the client application > itself. In the OAuth context, such=A0attacks allow an attacker to inject = their > own authorization code or access token into a client, which can result in > the client using an=A0access token associated with the attacker's account > rather than the victim's. Depending on the nature of the client and the > protected=A0resources, this can have undesirable and damaging effects. > > In order to prevent such attacks, the client application MUST encode a > non-guessable, confidential end-user artifact and submit as=A0the "state" > parameter to authorization and access token requests to the authorization > server. The client MUST keep the state value in=A0a location accessible o= nly > by the client or the user-agent (i.e., protected by same-origin policy), = for > example, using a DOM variable,=A0HTTP cookie, or HTML5 client-side storag= e. > > The authorization server includes the value of the "state" parameter when > redirecting the user-agent back to the client. Upon=A0receiving a redirec= t, > the client application MUST confirm that returned value of "state" > corresponds to the state value of the user-agent's user session. If the > end-user session represents an authenticated user-identity, the client MU= ST > ensure that the user-identity=A0has NOT changed. > > > > > > The above text uses 'user-context' and this 'user-identity'. Neither term= is > defined. > > > > EHL > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From phil.hunt@oracle.com Sun Aug 21 22:37:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51BE21F859E for ; Sun, 21 Aug 2011 22:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKsVcNZ+Hxvs for ; Sun, 21 Aug 2011 22:37:40 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 99D5D21F8559 for ; Sun, 21 Aug 2011 22:37:40 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7M5cfQS017238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2011 05:38:43 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7M5cepF000015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2011 05:38:40 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7M5cYWU023887; Mon, 22 Aug 2011 00:38:35 -0500 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Aug 2011 22:38:34 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Phil Hunt In-Reply-To: Date: Sun, 21 Aug 2011 22:38:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <27FB3C06-942B-487C-B780-7733BF50D6E4@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: David Recordon X-Mailer: Apple Mail (2.1084) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4E51EB63.004C:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 05:37:41 -0000 I think the complication here is that CSRF issues are multi-site issues = where the attacker cross connecting his client with a victims resource, = or a victims client with the attackers resource. So while an individual site (e.g. Facebook) may presume little or no = risk - there is a network effect here. A CSRF attacker could be using = facebook to attack another site. See Yaron's original text about = Plaxo/Live at the start of this thread. Would it be reasonable to assess whether a resource site could make it = mandatory based on a pre-registered client? IOW, would Facebook want to = make state mandatory for Confidential clients, but not public clients? Would it be acceptable to change status from OPTIONAL to RECOMMENDED? Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-21, at 6:10 PM, David Recordon wrote: > So far Facebook has used `state` in examples within our documentation > and strongly recommend it but have not gone so far as to mandate it. >=20 > Quoting https://developers.facebook.com/docs/authentication/: >> Cross site request forgery is an attack in which an trusted = (authenticated >> and authorized) user unknowingly performs an action on website. To = prevent >> this attack, you should pass an identifier in the state parameter, = and then >> validate the state parameter matches on the response. We strongly = recommend >> that any app implementing Facebook user login implement CSRF = protection using >> this mechanism. >=20 > I'd rather clearly document this in the spec, strongly recommend a > solution but not mandate this specific parameter. >=20 > --David >=20 >=20 > On Sun, Aug 21, 2011 at 12:02 PM, Eran Hammer-Lahav = wrote: >> I light to the recent discussion, do you still feel that changing = =91state=92 >> from optional to required is the best approach? >>=20 >>=20 >>=20 >> EHL >>=20 >>=20 >>=20 >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Sunday, August 21, 2011 11:04 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >>=20 >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>=20 >>=20 >>=20 >> My intention is to require clients to implement CSRF prevention. I = thought >> making the state parameter mandatory would be the straightforward = way. >>=20 >> regards, >> Torsten. >>=20 >> Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: >>=20 >> I would like to hear from the other 3 authors of the proposed change = about >> their reasons for changing the use of =91state=92 from recommended to = required >> for CSRF prevention. It would also help moving this issue forward if = the 4 >> authors can provide answers or clarifications on the issues raised = below. >>=20 >>=20 >>=20 >> Assuming we can count all 4 authors are in favor of making the = change, I >> believe we have a tie (4:4) and therefore no consensus for making it = (as of >> this point). However, we did identify issues with the section=92s = language and >> clarity which we should address either way. >>=20 >>=20 >>=20 >> To clarify =96 I am not proposing we close this issue just yet. >>=20 >>=20 >>=20 >> EHL >>=20 >>=20 >>=20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of >> Eran Hammer-Lahav >> Sent: Monday, August 15, 2011 9:35 AM >> To: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>=20 >>=20 >>=20 >> To demonstrate why making state required as proposed isn=92t very = helpful, >> here is an incomplete list of other requirements needed to make an = effective >> CSRF: >>=20 >>=20 >>=20 >> * State value must not be empty (a common bug in many implementations = using >> simple value comparison). >>=20 >>=20 >>=20 >> * =91Non-guessable=92 isn=92t sufficient as most developers will = simply use a hash >> of the session cookie, with or without salt which isn=92t sufficient. = We use >> =93cannot be generated, modified, or guessed to produce valid values=94= >> elsewhere in the document, but this is much easier to get right for = access >> tokens and refresh tokens than CSRF tokens which are often just some >> algorithm on top of the session cookie. >>=20 >>=20 >>=20 >> * State CSRF value should be short-lived or based on a short-lived = session >> cookie to prevent the use of a leaked state value in multiple attacks = on the >> same user session once the leak is no longer viable. >>=20 >>=20 >>=20 >> In addition, this is not what =93state=94 was originally intended = for. If the >> working group decides to mandate a CSRF parameter, it should probably = be a >> new parameter with a more appropriate name (e.g. =91csrf=92). By = forcing clients >> to use =93state=94 for this purpose, developers will need to use = dynamic queries >> for other state information which further reduces the security of the >> protocol (as the draft recommends not using dynamic callback query >> components). Encoding both CSRF tokens and other state information = can be >> non-intuitive or complicated for some developers/platforms. >>=20 >>=20 >>=20 >> EHL >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> From: Eran Hammer-Lahav >> Sent: Friday, August 12, 2011 2:53 PM >> To: Anthony Nadalin; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>=20 >>=20 >>=20 >> This is really just a flavor of CSRF attacks. I have no objections to = better >> documenting it (though I feel the current text is already = sufficient), but >> we can't realistically expect to identify and close every possible >> browser-based attack. A new one is invented every other week. >>=20 >>=20 >>=20 >> The problem with this text is that developers who do no understand = CSRF >> attacks are not likely to implement it correctly with this = information. >> Those who understand it do not need the extra verbiage which is more >> confusing than helpful. >>=20 >>=20 >>=20 >> As for the new requirements, they are insufficient to actually = accomplish >> what the authors propose without additional requirements on state = local >> storage and verification to complete the flow. Also, the proposed = text needs >> clarifications as noted below. >>=20 >>=20 >>=20 >>=20 >>=20 >> From: Anthony Nadalin >> Date: Fri, 12 Aug 2011 12:06:36 -0700 >> To: "OAuth WG (oauth@ietf.org)" >> Subject: [OAUTH-WG] Auth Code Swap Attack >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Recommended Changes to draft-ietf-oauth-v2 >>=20 >>=20 >>=20 >> In section 4, request options (e.g. 4.1.1) featuring "state" should = change >> from: >>=20 >>=20 >>=20 >> state >>=20 >> OPTIONAL. An opaque value used by the client to maintain state = between the >> request and callback. The authorization server includes this value = when >> redirecting the user-agent back to the client. >>=20 >>=20 >>=20 >> to: >>=20 >>=20 >>=20 >> state >>=20 >> REQUIRED. An opaque value used by the client to maintain state = between the >> request and callback. The authorization server includes this value = when >> redirecting the user-agent back to the client. The encoded value = SHOULD >> enable the client application to determine the user-context that was = active >> at the time of the request (see section 10.12). The value MUST NOT = be >> guessable or predictable, and MUST be kept confidential. >>=20 >>=20 >>=20 >>=20 >>=20 >> Making the parameter required without making its usage required (I.e. = "value >> SHOULD enable") accomplishes nothing. Also, what does "MUST be kept >> confidential" mean? Confidential from what? Why specify an "encoded = value"? >>=20 >>=20 >>=20 >>=20 >>=20 >> Section 10.12 Cross-Site Request Forgery >>=20 >>=20 >>=20 >> Change to: >>=20 >>=20 >>=20 >> Cross-site request forgery (CSRF) is a web-based attack whereby HTTP >> requests are transmitted from the user-agent of an end-user the = server >> trusts or has authenticated. CSRF attacks enable the attacker to = intermix >> the attacker's security context with that of the resource owner = resulting in >> a compromise of either the resource server or of the client = application >> itself. In the OAuth context, such attacks allow an attacker to = inject their >> own authorization code or access token into a client, which can = result in >> the client using an access token associated with the attacker's = account >> rather than the victim's. Depending on the nature of the client and = the >> protected resources, this can have undesirable and damaging effects. >>=20 >> In order to prevent such attacks, the client application MUST encode = a >> non-guessable, confidential end-user artifact and submit as the = "state" >> parameter to authorization and access token requests to the = authorization >> server. The client MUST keep the state value in a location accessible = only >> by the client or the user-agent (i.e., protected by same-origin = policy), for >> example, using a DOM variable, HTTP cookie, or HTML5 client-side = storage. >>=20 >> The authorization server includes the value of the "state" parameter = when >> redirecting the user-agent back to the client. Upon receiving a = redirect, >> the client application MUST confirm that returned value of "state" >> corresponds to the state value of the user-agent's user session. If = the >> end-user session represents an authenticated user-identity, the = client MUST >> ensure that the user-identity has NOT changed. >>=20 >>=20 >>=20 >>=20 >>=20 >> The above text uses 'user-context' and this 'user-identity'. Neither = term is >> defined. >>=20 >>=20 >>=20 >> EHL >>=20 >>=20 >> _______________________________________________ >>=20 >> OAuth mailing list >>=20 >> OAuth@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Aug 21 22:54:15 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E50C21F86B1 for ; Sun, 21 Aug 2011 22:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D53VW8Qh+k6 for ; Sun, 21 Aug 2011 22:54:14 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id AB76E21F85A3 for ; Sun, 21 Aug 2011 22:54:14 -0700 (PDT) Received: (qmail 18371 invoked from network); 22 Aug 2011 05:55:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Aug 2011 05:55:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Sun, 21 Aug 2011 22:55:18 -0700 From: Eran Hammer-Lahav To: Phil Hunt , David Recordon Date: Sun, 21 Aug 2011 22:53:54 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxgjcIRXJJUdfv9R2iqyTyOj7ZYeQAAHTDQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A292F66@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <27FB3C06-942B-487C-B780-7733BF50D6E4@oracle.com> In-Reply-To: <27FB3C06-942B-487C-B780-7733BF50D6E4@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 05:54:15 -0000 > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Sunday, August 21, 2011 10:39 PM > To: David Recordon > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack >=20 > I think the complication here is that CSRF issues are multi-site issues w= here > the attacker cross connecting his client with a victims resource, or a vi= ctims > client with the attackers resource. >=20 > So while an individual site (e.g. Facebook) may presume little or no risk= - > there is a network effect here. A CSRF attacker could be using facebook t= o > attack another site. See Yaron's original text about Plaxo/Live at the st= art of > this thread. It's still just a CSRF attack. =20 > Would it be reasonable to assess whether a resource site could make it > mandatory based on a pre-registered client? IOW, would Facebook want to > make state mandatory for Confidential clients, but not public clients? That's irrelevant. The authorization server has absolutely no way of verify= ing if the client is implementing a CSRF protection properly. Making 'state= ' required does not accomplish such an enforcement. A client can pass the p= roposed text requirement with "state=3Dni". > Would it be acceptable to change status from OPTIONAL to RECOMMENDED? Parameters are either required or optional. We can makes it optional and re= commended for a particular purpose which is consistent with the existing te= xt. It should be mandatory to implement CSRF protection. We agree on that and s= hould add it to the text. We also agree that 'state' is a great way of impl= ementing it and should recommend it. We already do that in the security con= sideration section and can enhance that when defining the 'state' parameter= . EHL From phil.hunt@oracle.com Mon Aug 22 08:57:01 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C500321F85EC for ; Mon, 22 Aug 2011 08:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohHM2xLOFTIp for ; Mon, 22 Aug 2011 08:57:00 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id CC08021F85C4 for ; Mon, 22 Aug 2011 08:57:00 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7MFw2IP014990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2011 15:58:04 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7MFw0Yv000455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2011 15:58:01 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7MFvtmA008478; Mon, 22 Aug 2011 10:57:55 -0500 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Aug 2011 08:57:55 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A292F66@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 22 Aug 2011 08:57:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9031AB22-68C0-4A3D-9587-944287CFD5FD@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <27FB3C06-942B-487C-B780-7733BF50D6E4@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234518A292F66@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090202.4E527C8C.00CF,ss=1,re=0.000,fgs=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 15:57:01 -0000 Eran, to summarize, 1. The server cannot tell if the client did its job - so the server = can't "require" the client to implement state 2. There are many ways to enforce CSRF There is an important "network" effect here (and in general with OAuth) = - that client decisions affect the security of the resource server and = vice-versa. One could argue, that many implementers will want a solution = for #1 above -- some form of mutual state validation. This may not be = of interest to today's implementers, but I know this is critical for = government and financial services where fraud (and phishing) become a = much larger issue. I am beginning to believe we can't fix this now. This will likely have = to be an optional RFC for higher strength anti-CSRF which specifies a = standard methodology that can be verified by the server (so it can = enforce that it was done). My belief is that a standard methodology = would make things easier for developers since they would have clear = instructions on how to do it. Hopefully this would address folks like = Facebook who are concerned developers have a hard time getting this = right. Because of this, I re-checked RFC2119 regarding making state = "RECOMMENDED". Whereas "REQUIRED" is equivalent to "MUST", = "RECOMMENDED" is equivalent to SHOULD and could be used as a parameter = qualifier. Though I agree, traditionally this isn't done. However, my = feeling is that the developer needs to be alerted to the importance of = "state". Deciding not to use it means they should have some other = technique to counter CSRF. This is what SHOULD is meant for. Changing = to RECOMMENDED makes the calls consistent with the security = consideration requirement that anti-CSRF is a MUST. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-21, at 10:53 PM, Eran Hammer-Lahav wrote: >=20 >=20 >> -----Original Message----- >> From: Phil Hunt [mailto:phil.hunt@oracle.com] >> Sent: Sunday, August 21, 2011 10:39 PM >> To: David Recordon >> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>=20 >> I think the complication here is that CSRF issues are multi-site = issues where >> the attacker cross connecting his client with a victims resource, or = a victims >> client with the attackers resource. >>=20 >> So while an individual site (e.g. Facebook) may presume little or no = risk - >> there is a network effect here. A CSRF attacker could be using = facebook to >> attack another site. See Yaron's original text about Plaxo/Live at = the start of >> this thread. >=20 > It's still just a CSRF attack. >=20 >> Would it be reasonable to assess whether a resource site could make = it >> mandatory based on a pre-registered client? IOW, would Facebook want = to >> make state mandatory for Confidential clients, but not public = clients? >=20 > That's irrelevant. The authorization server has absolutely no way of = verifying if the client is implementing a CSRF protection properly. = Making 'state' required does not accomplish such an enforcement. A = client can pass the proposed text requirement with "state=3Dni". >=20 >> Would it be acceptable to change status from OPTIONAL to RECOMMENDED? >=20 > Parameters are either required or optional. We can makes it optional = and recommended for a particular purpose which is consistent with the = existing text. >=20 > It should be mandatory to implement CSRF protection. We agree on that = and should add it to the text. We also agree that 'state' is a great way = of implementing it and should recommend it. We already do that in the = security consideration section and can enhance that when defining the = 'state' parameter. >=20 > EHL From trac+oauth@trac.tools.ietf.org Mon Aug 22 10:50:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA60121F8C07 for ; Mon, 22 Aug 2011 10:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWdxRtBYdwTd for ; Mon, 22 Aug 2011 10:50:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:123a::1:2a]) by ietfa.amsl.com (Postfix) with ESMTP id 293AA21F8C00 for ; Mon, 22 Aug 2011 10:50:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QvYeN-0007Df-Fm; Mon, 22 Aug 2011 10:51:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: draft-ietf-oauth-v2-bearer@tools.ietf.org, barryleiba@computer.org X-Trac-Project: oauth Date: Mon, 22 Aug 2011 17:51:03 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 Message-ID: <063.05a6468910b9273126be082130670b4e@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-oauth-v2-bearer@tools.ietf.org, barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20110822175007.293AA21F8C00@ietfa.amsl.com> Resent-Date: Mon, 22 Aug 2011 10:50:07 -0700 (PDT) Resent-From: trac+oauth@trac.tools.ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] [oauth] #26: scope-v percent-encoding X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 17:50:07 -0000 #26: scope-v percent-encoding See discussion thread beginning here: http://www.ietf.org/mail-archive/web/oauth/current/msg07310.html This was triggered by the OMA liaison statement, and the WG response to it. << A client app receiving a scope value in an "WWW-Authenticate: Bearer scope=..." response will either compare it with strings from a OAuth2 JSON-encoded token response, or copy it into a request to an authorization server. It needs to know if it needs to %-decode the value or not before doing these things. Clients cannot be expected to behave differently for different servers in this respect. >> -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: draft-ietf-oauth-v2-bearer@… Type: defect | Status: new Priority: major | Milestone: Deliver bearer token spec Component: v2-bearer | Version: Severity: Active WG Document | Keywords: -------------------------------------+-------------------------------------- Ticket URL: oauth From barryleiba.mailing.lists@gmail.com Mon Aug 22 10:52:23 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A6221F8C12 for ; Mon, 22 Aug 2011 10:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.034 X-Spam-Level: X-Spam-Status: No, score=-103.034 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22RCHKZhtE0k for ; Mon, 22 Aug 2011 10:52:23 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1756021F8C10 for ; Mon, 22 Aug 2011 10:52:23 -0700 (PDT) Received: by ywe9 with SMTP id 9so636837ywe.31 for ; Mon, 22 Aug 2011 10:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aDI5lx97GlbKn9Ou+hE1bsWINfcJcsUodXOXvczBkVY=; b=hjlYUGBbq+rDgh6KGtYtccPgjFuN/Yp5kzKTOKX+ojVX3gd2FTXcNAeLf4Pm4DhUXL ql3YxMvCQLII7wuFr1+rreCPrG7WDWnl2D14tpdPKnWR4ENq1aCOZ1FmBWFdnXvgCFzt 3IhUlEvIZ0O2dDztETbo7qRF1GjfKHRyWaP/Y= MIME-Version: 1.0 Received: by 10.236.191.103 with SMTP id f67mr16408097yhn.93.1314035608484; Mon, 22 Aug 2011 10:53:28 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Mon, 22 Aug 2011 10:53:28 -0700 (PDT) In-Reply-To: <1313690981.82232.YahooMailNeo@web31805.mail.mud.yahoo.com> References: <255B9BB34FB7D647A506DC292726F6E1128B5BB96C@WSMSG3153V.srv.dir.telstra.com> <1313690981.82232.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Mon, 22 Aug 2011 13:53:28 -0400 X-Google-Sender-Auth: 3eaBLgNNfO5fBtybUgXGhsZD6lk Message-ID: From: Barry Leiba To: "William J. Mills" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 17:52:23 -0000 > +1 for Jame's feedback here.=A0 We need to solve this. I have opened an issue in the tracker on this: http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 I intend to add the following to the response to this item: "The working group understands that client code needs to know whether to use and decode percent-encoding. The issue is being discussed and tracked, and will be resolved before the final version of the bearer document is produced." Barry, as chair From eran@hueniverse.com Mon Aug 22 12:15:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B6B21F8BF9 for ; Mon, 22 Aug 2011 12:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V17f-fBeJ2aG for ; Mon, 22 Aug 2011 12:15:06 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 8E5BD21F8BDC for ; Mon, 22 Aug 2011 12:15:06 -0700 (PDT) Received: (qmail 21003 invoked from network); 22 Aug 2011 19:16:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Aug 2011 19:16:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 22 Aug 2011 12:16:02 -0700 From: Eran Hammer-Lahav To: Phil Hunt Date: Mon, 22 Aug 2011 12:16:03 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: Acxg/+66EPLGS3lgS/yy3IQwVtvKYQ== Message-ID: In-Reply-To: <9031AB22-68C0-4A3D-9587-944287CFD5FD@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA77F8E918801eranhueniversecom_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:15:07 -0000 --_000_CA77F8E918801eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sounds like a good compromise. I will play with the text Bill proposed and = follow up with new text on the list. EHL From: Phil Hunt > Date: Mon, 22 Aug 2011 08:57:54 -0700 To: Eran Hammer-lahav > Cc: "recordond@gmail.com" >, "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Auth Code Swap Attack Eran, to summarize, 1. The server cannot tell if the client did its job - so the server can't "= require" the client to implement state 2. There are many ways to enforce CSRF There is an important "network" effect here (and in general with OAuth) - = that client decisions affect the security of the resource server and vice-v= ersa. One could argue, that many implementers will want a solution for #1 a= bove -- some form of mutual state validation. This may not be of interest = to today's implementers, but I know this is critical for government and fin= ancial services where fraud (and phishing) become a much larger issue. I am beginning to believe we can't fix this now. This will likely have to b= e an optional RFC for higher strength anti-CSRF which specifies a standard = methodology that can be verified by the server (so it can enforce that it w= as done). My belief is that a standard methodology would make things easie= r for developers since they would have clear instructions on how to do it. = Hopefully this would address folks like Facebook who are concerned develope= rs have a hard time getting this right. Because of this, I re-checked RFC2119 regarding making state "RECOMMENDED".= Whereas "REQUIRED" is equivalent to "MUST", "RECOMMENDED" is equivalent t= o SHOULD and could be used as a parameter qualifier. Though I agree, tradit= ionally this isn't done. However, my feeling is that the developer needs t= o be alerted to the importance of "state". Deciding not to use it means the= y should have some other technique to counter CSRF. This is what SHOULD is= meant for. Changing to RECOMMENDED makes the calls consistent with the se= curity consideration requirement that anti-CSRF is a MUST. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-21, at 10:53 PM, Eran Hammer-Lahav wrote: -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Sunday, August 21, 2011 10:39 PM To: David Recordon Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I think the complication here is that CSRF issues are multi-site issues whe= re the attacker cross connecting his client with a victims resource, or a vict= ims client with the attackers resource. So while an individual site (e.g. Facebook) may presume little or no risk - there is a network effect here. A CSRF attacker could be using facebook to attack another site. See Yaron's original text about Plaxo/Live at the star= t of this thread. It's still just a CSRF attack. Would it be reasonable to assess whether a resource site could make it mandatory based on a pre-registered client? IOW, would Facebook want to make state mandatory for Confidential clients, but not public clients? That's irrelevant. The authorization server has absolutely no way of verify= ing if the client is implementing a CSRF protection properly. Making 'state= ' required does not accomplish such an enforcement. A client can pass the p= roposed text requirement with "state=3Dni". Would it be acceptable to change status from OPTIONAL to RECOMMENDED? Parameters are either required or optional. We can makes it optional and re= commended for a particular purpose which is consistent with the existing te= xt. It should be mandatory to implement CSRF protection. We agree on that and s= hould add it to the text. We also agree that 'state' is a great way of impl= ementing it and should recommend it. We already do that in the security con= sideration section and can enhance that when defining the 'state' parameter= . EHL --_000_CA77F8E918801eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sounds like a good compr= omise. I will play with the text Bill proposed and follow up with new text = on the list.

EHL

From: Phil Hunt <phil.hunt@oracle.com>
Date: Mon, 22 Aug 2011 08:57:54 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: "recordond@gmail.com" <recordond@gmail.com>,= "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

<= div>
Eran, to summarize,

1. The server cannot = tell if the client did its job - so the server can't "require" the client t= o implement state
2. There are many ways to enforce CSRF

There is an important "network" effect  here (an= d in general with OAuth) - that client decisions affect the security of the= resource server and vice-versa. One could argue, that many implementers wi= ll want a solution for #1 above -- some form of mutual state validation.&nb= sp; This may not be of interest to today's implementers, but I know th= is is critical for government and financial services where fraud (and phish= ing) become a much larger issue.

I am beginning to= believe we can't fix this now. This will likely have to be an optional RFC= for higher strength anti-CSRF which specifies a standard methodology that = can be verified by the server (so it can enforce that it was done). &n= bsp;My belief is that a standard methodology would make things easier for d= evelopers since they would have clear instructions on how to do it. Hopeful= ly this would address folks like Facebook who are concerned developers have= a hard time getting this right.

Because of this, = I re-checked RFC2119 regarding making state "RECOMMENDED".  Where= as "REQUIRED" is equivalent to "MUST", "RECOMMENDED" is equivalent to SHOUL= D and could be used as a parameter qualifier. Though I agree, traditionally= this isn't done.  However, my feeling is that the developer need= s to be alerted to the importance of "state". Deciding not to use it means = they should have some other technique to counter CSRF.  This is w= hat SHOULD is meant for.  Changing to RECOMMENDED makes the calls= consistent with the security consideration requirement that anti-CSRF is a= MUST.

Phil

@independenti= d
www.independentid.com


<= br>


On 2011-08-21, at 10:53 PM, Era= n Hammer-Lahav wrote:

-----Original Message-----
From: Phil = Hunt [mailto:phil.hunt@oracle.com]
Subject: Re: [OAUTH-WG] Auth Cod= e Swap Attack
I think the complication here is that = CSRF issues are multi-site issues where
the attacker cross conne= cting his client with a victims resource, or a victims
client wi= th the attackers resource.
So while an individual si= te (e.g. Facebook) may presume little or no risk -
there is a ne= twork effect here. A CSRF attacker could be using facebook to
at= tack another site. See Yaron's original text about Plaxo/Live at the start = of
this thread.
It's still j= ust a CSRF attack.
Would it be reasonable to assess whether a resource site= could make it
mandatory based on a pre-registered client? =  IOW, would Facebook want to
make state mandatory for Confi= dential clients, but not public clients?
That's irrelevant. The authorization server has absolutely no way of veri= fying if the client is implementing a CSRF protection properly. Making 'sta= te' required does not accomplish such an enforcement. A client can pass the= proposed text requirement with "state=3Dni".
Would it be acceptable to cha= nge status from OPTIONAL to RECOMMENDED?
Parameters are either required or optional. We can makes it optional and = recommended for a particular purpose which is consistent with the existing = text.
It should be mandatory to implement CSRF prote= ction. We agree on that and should add it to the text. We also agree that '= state' is a great way of implementing it and should recommend it. We alread= y do that in the security consideration section and can enhance that when d= efining the 'state' parameter.
EHL


--_000_CA77F8E918801eranhueniversecom_-- From tonynad@microsoft.com Mon Aug 22 14:58:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244FC21F8CA6 for ; Mon, 22 Aug 2011 14:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyUNu-1tKLF7 for ; Mon, 22 Aug 2011 14:58:40 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id AC68021F8CA3 for ; Mon, 22 Aug 2011 14:58:40 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 22 Aug 2011 14:59:46 -0700 Received: from DB3EHSOBE003.bigfish.com (157.54.51.112) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Aug 2011 14:59:46 -0700 Received: from mail118-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.22; Mon, 22 Aug 2011 21:59:44 +0000 Received: from mail118-db3 (localhost.localdomain [127.0.0.1]) by mail118-db3-R.bigfish.com (Postfix) with ESMTP id 6828E1B380CC for ; Mon, 22 Aug 2011 21:59:44 +0000 (UTC) X-SpamScore: -31 X-BigFish: PS-31(zz9371K936eKc85fh542M98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT013.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail118-db3: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT013.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail118-db3 (localhost.localdomain [127.0.0.1]) by mail118-db3 (MessageSwitch) id 1314050383938519_11560; Mon, 22 Aug 2011 21:59:43 +0000 (UTC) Received: from DB3EHSMHS014.bigfish.com (unknown [10.3.81.251]) by mail118-db3.bigfish.com (Postfix) with ESMTP id DEECD16B804B; Mon, 22 Aug 2011 21:59:43 +0000 (UTC) Received: from SN2PRD0302HT013.namprd03.prod.outlook.com (207.46.4.139) by DB3EHSMHS014.bigfish.com (10.3.87.114) with Microsoft SMTP Server (TLS) id 14.1.225.22; Mon, 22 Aug 2011 21:59:42 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.2.234]) by SN2PRD0302HT013.namprd03.prod.outlook.com ([10.27.90.203]) with mapi id 14.01.0225.064; Mon, 22 Aug 2011 21:58:54 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Phil Hunt Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZImYoC2iZvOhxR/+zEXUukLHDogAF8TGAAIvI14AAgNyjAACwAFgAAAIJGIAADNlIgAAJW6kAAACJYwAAFRgvAAAG65mAAAWRMJA= Date: Mon, 22 Aug 2011 21:58:53 +0000 Message-ID: References: <9031AB22-68C0-4A3D-9587-944287CFD5FD@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.69] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E35D5SN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT013.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 21:58:42 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E35D5SN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Concern here is we have a protocol that is open to attacks, we need to docu= ment a way that developers can safely implement, leaving it up to the devel= oper may not be the best way unless they know what they are doing, so more = in favor of recommending the use of state and if the developer can do some= thing better the so be it From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, August 22, 2011 12:16 PM To: Phil Hunt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack Sounds like a good compromise. I will play with the text Bill proposed and = follow up with new text on the list. EHL From: Phil Hunt > Date: Mon, 22 Aug 2011 08:57:54 -0700 To: Eran Hammer-lahav > Cc: "recordond@gmail.com" >, "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Auth Code Swap Attack Eran, to summarize, 1. The server cannot tell if the client did its job - so the server can't "= require" the client to implement state 2. There are many ways to enforce CSRF There is an important "network" effect here (and in general with OAuth) - = that client decisions affect the security of the resource server and vice-v= ersa. One could argue, that many implementers will want a solution for #1 a= bove -- some form of mutual state validation. This may not be of interest = to today's implementers, but I know this is critical for government and fin= ancial services where fraud (and phishing) become a much larger issue. I am beginning to believe we can't fix this now. This will likely have to b= e an optional RFC for higher strength anti-CSRF which specifies a standard = methodology that can be verified by the server (so it can enforce that it w= as done). My belief is that a standard methodology would make things easie= r for developers since they would have clear instructions on how to do it. = Hopefully this would address folks like Facebook who are concerned develope= rs have a hard time getting this right. Because of this, I re-checked RFC2119 regarding making state "RECOMMENDED".= Whereas "REQUIRED" is equivalent to "MUST", "RECOMMENDED" is equivalent t= o SHOULD and could be used as a parameter qualifier. Though I agree, tradit= ionally this isn't done. However, my feeling is that the developer needs t= o be alerted to the importance of "state". Deciding not to use it means the= y should have some other technique to counter CSRF. This is what SHOULD is= meant for. Changing to RECOMMENDED makes the calls consistent with the se= curity consideration requirement that anti-CSRF is a MUST. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-21, at 10:53 PM, Eran Hammer-Lahav wrote: -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Sunday, August 21, 2011 10:39 PM To: David Recordon Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I think the complication here is that CSRF issues are multi-site issues whe= re the attacker cross connecting his client with a victims resource, or a vict= ims client with the attackers resource. So while an individual site (e.g. Facebook) may presume little or no risk - there is a network effect here. A CSRF attacker could be using facebook to attack another site. See Yaron's original text about Plaxo/Live at the star= t of this thread. It's still just a CSRF attack. Would it be reasonable to assess whether a resource site could make it mandatory based on a pre-registered client? IOW, would Facebook want to make state mandatory for Confidential clients, but not public clients? That's irrelevant. The authorization server has absolutely no way of verify= ing if the client is implementing a CSRF protection properly. Making 'state= ' required does not accomplish such an enforcement. A client can pass the p= roposed text requirement with "state=3Dni". Would it be acceptable to change status from OPTIONAL to RECOMMENDED? Parameters are either required or optional. We can makes it optional and re= commended for a particular purpose which is consistent with the existing te= xt. It should be mandatory to implement CSRF protection. We agree on that and s= hould add it to the text. We also agree that 'state' is a great way of impl= ementing it and should recommend it. We already do that in the security con= sideration section and can enhance that when defining the 'state' parameter= . EHL --_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E35D5SN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Concern here is we have a= protocol that is open to attacks, we need to document a way that developer= s can safely implement, leaving it up to the developer may not be the best way unless they know what they are doing, so more in favor= of recommending the use of  state and if the developer can do somethi= ng better the so be it

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 22, 2011 12:16 PM
To: Phil Hunt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

Sounds like a good compromi= se. I will play with the text Bill proposed and follow up with new text on = the list.

 

EHL

 

From: Phil Hunt <phil.hunt@oracle.com>
Date: Mon, 22 Aug 2011 08:57:54 -0700
To: Eran Hammer-lahav <era= n@hueniverse.com>
Cc: "recordond@gmail.com= " <recordond@gmail.com>, "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

Eran, to summarize,

 

1. The server cannot tell i= f the client did its job - so the server can't "require" the clie= nt to implement state

2. There are many ways to e= nforce CSRF

 

There is an important "= ;network" effect  here (and in general with OAuth) - that cl= ient decisions affect the security of the resource server and vice-versa. O= ne could argue, that many implementers will want a solution for #1 above -- s= ome form of mutual state validation.  This may not be of interest= to today's implementers, but I know this is critical for government and fi= nancial services where fraud (and phishing) become a much larger issue.

 

I am beginning to believe w= e can't fix this now. This will likely have to be an optional RFC for highe= r strength anti-CSRF which specifies a standard methodology that can be verified by the server (so it can enforce that it was done).&n= bsp; My belief is that a standard methodology would make things easier= for developers since they would have clear instructions on how to do it. H= opefully this would address folks like Facebook who are concerned developers have a hard time getting this right.

 

Because of this, I re-check= ed RFC2119 regarding making state "RECOMMENDED".  Where= as "REQUIRED" is equivalent to "MUST", "RECOMMENDE= D" is equivalent to SHOULD and could be used as a parameter qualifier. Though I agree, traditionally = this isn't done.  However, my feeling is that the developer needs= to be alerted to the importance of "state". Deciding not to use = it means they should have some other technique to counter CSRF.  This is what SHOULD is meant for.  Changing to = RECOMMENDED makes the calls consistent with the security consideration requ= irement that anti-CSRF is a MUST.

 

Phil

 

@independentid

 

 

 

 

 

On 2011-08-21, at 10:53 PM,= Eran Hammer-Lahav wrote:

 

-----Original Message-----<= o:p>

From: Phil Hunt [mailto:phil.hunt@oracle.com]

Sent: Sunday, August 21, 20= 11 10:39 PM

To: David Recordon

Cc: Eran Hammer-Lahav; OAut= h WG (oauth@ietf.org)

Subject: Re: [OAUTH-WG] Aut= h Code Swap Attack

I think the complication he= re is that CSRF issues are multi-site issues where

the attacker cross connecti= ng his client with a victims resource, or a victims

client with the attackers r= esource.

So while an individual site= (e.g. Facebook) may presume little or no risk -

there is a network effect h= ere. A CSRF attacker could be using facebook to

attack another site. See Ya= ron's original text about Plaxo/Live at the start of

this thread.

It's still just a CSRF atta= ck.

Would it be reasonable to a= ssess whether a resource site could make it

mandatory based on a pre-re= gistered client?  IOW, would Facebook want to

make state mandatory for Co= nfidential clients, but not public clients?

That's irrelevant. The auth= orization server has absolutely no way of verifying if the client is implem= enting a CSRF protection properly. Making 'state' required does not accomplish such an enforcement. A client can pass the proposed te= xt requirement with "state=3Dni".

Would it be acceptable to c= hange status from OPTIONAL to RECOMMENDED?

Parameters are either requi= red or optional. We can makes it optional and recommended for a particular = purpose which is consistent with the existing text.

It should be mandatory to i= mplement CSRF protection. We agree on that and should add it to the text. W= e also agree that 'state' is a great way of implementing it and should recommend it. We already do that in the security considerati= on section and can enhance that when defining the 'state' parameter.

EHL

 

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E35D5SN2PRD0302MB137_-- From eran@hueniverse.com Mon Aug 22 15:16:04 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3406121F8783 for ; Mon, 22 Aug 2011 15:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+VZnJ+0wUhI for ; Mon, 22 Aug 2011 15:16:00 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id BCEFF21F8742 for ; Mon, 22 Aug 2011 15:16:00 -0700 (PDT) Received: (qmail 25242 invoked from network); 22 Aug 2011 22:17:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Aug 2011 22:17:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Mon, 22 Aug 2011 15:17:04 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , Phil Hunt Date: Mon, 22 Aug 2011 15:15:37 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZImYoC2iZvOhxR/+zEXUukLHDogAF8TGAAIvI14AAgNyjAACwAFgAAAIJGIAADNlIgAAJW6kAAACJYwAAFRgvAAAG65mAAAWRMJAAALCfMA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A29316D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <9031AB22-68C0-4A3D-9587-944287CFD5FD@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234518A29316DP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 22:16:04 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234518A29316DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's what we are saying. Not sure what exactly are you arguing against no= w. EHL From: Anthony Nadalin [mailto:tonynad@microsoft.com] Sent: Monday, August 22, 2011 2:59 PM To: Eran Hammer-Lahav; Phil Hunt Cc: OAuth WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Auth Code Swap Attack Concern here is we have a protocol that is open to attacks, we need to docu= ment a way that developers can safely implement, leaving it up to the devel= oper may not be the best way unless they know what they are doing, so more = in favor of recommending the use of state and if the developer can do some= thing better the so be it From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Eran = Hammer-Lahav Sent: Monday, August 22, 2011 12:16 PM To: Phil Hunt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack Sounds like a good compromise. I will play with the text Bill proposed and = follow up with new text on the list. EHL From: Phil Hunt > Date: Mon, 22 Aug 2011 08:57:54 -0700 To: Eran Hammer-lahav > Cc: "recordond@gmail.com" >, "OAuth WG (oauth@ietf.org)" > Subject: Re: [OAUTH-WG] Auth Code Swap Attack Eran, to summarize, 1. The server cannot tell if the client did its job - so the server can't "= require" the client to implement state 2. There are many ways to enforce CSRF There is an important "network" effect here (and in general with OAuth) - = that client decisions affect the security of the resource server and vice-v= ersa. One could argue, that many implementers will want a solution for #1 a= bove -- some form of mutual state validation. This may not be of interest = to today's implementers, but I know this is critical for government and fin= ancial services where fraud (and phishing) become a much larger issue. I am beginning to believe we can't fix this now. This will likely have to b= e an optional RFC for higher strength anti-CSRF which specifies a standard = methodology that can be verified by the server (so it can enforce that it w= as done). My belief is that a standard methodology would make things easie= r for developers since they would have clear instructions on how to do it. = Hopefully this would address folks like Facebook who are concerned develope= rs have a hard time getting this right. Because of this, I re-checked RFC2119 regarding making state "RECOMMENDED".= Whereas "REQUIRED" is equivalent to "MUST", "RECOMMENDED" is equivalent t= o SHOULD and could be used as a parameter qualifier. Though I agree, tradit= ionally this isn't done. However, my feeling is that the developer needs t= o be alerted to the importance of "state". Deciding not to use it means the= y should have some other technique to counter CSRF. This is what SHOULD is= meant for. Changing to RECOMMENDED makes the calls consistent with the se= curity consideration requirement that anti-CSRF is a MUST. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-21, at 10:53 PM, Eran Hammer-Lahav wrote: -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Sunday, August 21, 2011 10:39 PM To: David Recordon Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I think the complication here is that CSRF issues are multi-site issues whe= re the attacker cross connecting his client with a victims resource, or a vict= ims client with the attackers resource. So while an individual site (e.g. Facebook) may presume little or no risk - there is a network effect here. A CSRF attacker could be using facebook to attack another site. See Yaron's original text about Plaxo/Live at the star= t of this thread. It's still just a CSRF attack. Would it be reasonable to assess whether a resource site could make it mandatory based on a pre-registered client? IOW, would Facebook want to make state mandatory for Confidential clients, but not public clients? That's irrelevant. The authorization server has absolutely no way of verify= ing if the client is implementing a CSRF protection properly. Making 'state= ' required does not accomplish such an enforcement. A client can pass the p= roposed text requirement with "state=3Dni". Would it be acceptable to change status from OPTIONAL to RECOMMENDED? Parameters are either required or optional. We can makes it optional and re= commended for a particular purpose which is consistent with the existing te= xt. It should be mandatory to implement CSRF protection. We agree on that and s= hould add it to the text. We also agree that 'state' is a great way of impl= ementing it and should recommend it. We already do that in the security con= sideration section and can enhance that when defining the 'state' parameter= . EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234518A29316DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That̵= 7;s what we are saying. Not sure what exactly are you arguing against now.<= o:p>

 

EHL

 

Fr= om: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Mond= ay, August 22, 2011 2:59 PM
To: Eran Hammer-Lahav; Phil Hunt
<= b>Cc: OAuth WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Auth = Code Swap Attack

 

Concern here is we have a prot= ocol that is open to attacks, we need to document a way that developers can= safely implement, leaving it up to the developer may not be the best way u= nless they know what they are doing, so more in favor of recommending the u= se of  state and if the developer can do something better the so be it=

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran H= ammer-Lahav
Sent: Monday, August 22, 2011 12:16 PM
To: = Phil Hunt
Cc: OAuth WG (oauth@i= etf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

<= p class=3DMsoNormal>Sounds like a good compromise. I will play with th= e text Bill proposed and follow up with new text on the list.

 

EHL

 

From: Phil Hunt <phil.hunt@oracle.com>
Date: Mon, 22 = Aug 2011 08:57:54 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: "recordond@gmail.com" <recordond@gmail.com>, "OAuth = WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [O= AUTH-WG] Auth Code Swap Attack

 

Eran= , to summarize,

<= o:p> 

1. The serv= er cannot tell if the client did its job - so the server can't "requir= e" the client to implement state

2. There are many ways to enforce CSRF

 

There is an important "network" = effect  here (and in general with OAuth) - that client decisions = affect the security of the resource server and vice-versa. One could argue,= that many implementers will want a solution for #1 above -- some form of m= utual state validation.  This may not be of interest to today's i= mplementers, but I know this is critical for government and financial servi= ces where fraud (and phishing) become a much larger issue.

 

I am beginning to believe we can't fix this= now. This will likely have to be an optional RFC for higher strength anti-= CSRF which specifies a standard methodology that can be verified by the ser= ver (so it can enforce that it was done).  My belief is that a st= andard methodology would make things easier for developers since they would= have clear instructions on how to do it. Hopefully this would address folk= s like Facebook who are concerned developers have a hard time getting this = right.

 = ;

Because of this, I r= e-checked RFC2119 regarding making state "RECOMMENDED". &nbs= p;Whereas "REQUIRED" is equivalent to "MUST", "REC= OMMENDED" is equivalent to SHOULD and could be used as a parameter qua= lifier. Though I agree, traditionally this isn't done.  However, = my feeling is that the developer needs to be alerted to the importance of &= quot;state". Deciding not to use it means they should have some other = technique to counter CSRF.  This is what SHOULD is meant for.&nbs= p; Changing to RECOMMENDED makes the calls consistent with the securit= y consideration requirement that anti-CSRF is a MUST.

=

 

Phil

 

= @independentid

=

 

 

 

 

 <= /o:p>

On 2011-08-21, at 10:5= 3 PM, Eran Hammer-Lahav wrote:

 

-----Original Message-----<= /o:p>

From: Phil Hunt [mailto:phil.hunt@oracle.com]

Sent: Sunday, August 21,= 2011 10:39 PM

To= : David Recordon

= Cc: Eran Hammer-Lahav; OAuth WG (oauth@ie= tf.org)

Subje= ct: Re: [OAUTH-WG] Auth Code Swap Attack

I think the complication here is that CSRF issues a= re multi-site issues where

the attacker cross connecting his client with a victims resource,= or a victims

cli= ent with the attackers resource.

So while an individual site (e.g. Facebook) may presume l= ittle or no risk -

there is a network effect here. A CSRF attacker could be using facebook t= o

attack another = site. See Yaron's original text about Plaxo/Live at the start of=

this thread.

It's still just a = CSRF attack.

Would it be reasonable= to assess whether a resource site could make it

mandatory based on a pre-registered client?=   IOW, would Facebook want to

make state mandatory for Confidential clients, but n= ot public clients?

That's irrelevant. The authorization server has absolutely n= o way of verifying if the client is implementing a CSRF protection properly= . Making 'state' required does not accomplish such an enforcement. A client= can pass the proposed text requirement with "state=3Dni".

Would it be acceptable to change status f= rom OPTIONAL to RECOMMENDED?

<= p class=3DMsoNormal>Parameters are either required or optional. We can= makes it optional and recommended for a particular purpose which is consis= tent with the existing text.

It should be mandatory to implement CSRF protection. We agree o= n that and should add it to the text. We also agree that 'state' is a great= way of implementing it and should recommend it. We already do that in the = security consideration section and can enhance that when defining the 'stat= e' parameter.

EHL=

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234518A29316DP3PW5EX1MB01E_-- From torsten@lodderstedt.net Tue Aug 23 23:05:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5B21F8B57 for ; Tue, 23 Aug 2011 23:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mrjd+p072Qbl for ; Tue, 23 Aug 2011 23:05:09 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A25B21F8B3F for ; Tue, 23 Aug 2011 23:05:07 -0700 (PDT) Received: from [79.253.47.190] (helo=[192.168.71.38]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Qw6bO-0004oR-7C; Wed, 24 Aug 2011 08:06:14 +0200 Message-ID: <4E5494D4.4060109@lodderstedt.net> Date: Wed, 24 Aug 2011 08:06:12 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------020902040208010509000109" X-Df-Sender: torsten@lodderstedt-online.de Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 06:05:12 -0000 This is a multi-part message in MIME format. --------------020902040208010509000109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit making CSRF prevention a MUST and recommending the state parameter as implementation pattern is ok with me. regards, Torsten. Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav: > > I light to the recent discussion, do you still feel that changing > 'state' from optional to required is the best approach? > > EHL > > *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Sunday, August 21, 2011 11:04 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Auth Code Swap Attack > > My intention is to require clients to implement CSRF prevention. I > thought making the state parameter mandatory would be the > straightforward way. > > regards, > Torsten. > > Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: > > I would like to hear from the other 3 authors of the proposed change > about their reasons for changing the use of 'state' from recommended > to required for CSRF prevention. It would also help moving this issue > forward if the 4 authors can provide answers or clarifications on the > issues raised below. > > Assuming we can count all 4 authors are in favor of making the change, > I believe we have a tie (4:4) and therefore no consensus for making it > (as of this point). However, we did identify issues with the section's > language and clarity which we should address either way. > > To clarify -- I am not proposing we close this issue just yet. > > EHL > > *From:*oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org] *On Behalf Of *Eran Hammer-Lahav > *Sent:* Monday, August 15, 2011 9:35 AM > *To:* OAuth WG (oauth@ietf.org ) > *Subject:* Re: [OAUTH-WG] Auth Code Swap Attack > > To demonstrate why making state required as proposed isn't very > helpful, here is an incomplete list of other requirements needed to > make an effective CSRF: > > * State value must not be empty (a common bug in many implementations > using simple value comparison). > > * 'Non-guessable' isn't sufficient as most developers will simply use > a hash of the session cookie, with or without salt which isn't > sufficient. We use "cannot be generated, modified, or guessed to > produce valid values" elsewhere in the document, but this is much > easier to get right for access tokens and refresh tokens than CSRF > tokens which are often just some algorithm on top of the session cookie. > > * State CSRF value should be short-lived or based on a short-lived > session cookie to prevent the use of a leaked state value in multiple > attacks on the same user session once the leak is no longer viable. > > In addition, this is not what "state" was originally intended for. If > the working group decides to mandate a CSRF parameter, it should > probably be a new parameter with a more appropriate name (e.g. > 'csrf'). By forcing clients to use "state" for this purpose, > developers will need to use dynamic queries for other state > information which further reduces the security of the protocol (as the > draft recommends not using dynamic callback query components). > Encoding both CSRF tokens and other state information can be > non-intuitive or complicated for some developers/platforms. > > EHL > > *From:*Eran Hammer-Lahav > *Sent:* Friday, August 12, 2011 2:53 PM > *To:* Anthony Nadalin; OAuth WG (oauth@ietf.org ) > *Subject:* Re: [OAUTH-WG] Auth Code Swap Attack > > This is really just a flavor of CSRF attacks. I have no objections to > better documenting it (though I feel the current text is already > sufficient), but we can't realistically expect to identify and close > every possible browser-based attack. A new one is invented every other > week. > > The problem with this text is that developers who do no understand > CSRF attacks are not likely to implement it correctly with this > information. Those who understand it do not need the extra verbiage > which is more confusing than helpful. > > As for the new requirements, they are insufficient to actually > accomplish what the authors propose without additional requirements on > state local storage and verification to complete the flow. Also, the > proposed text needs clarifications as noted below. > > *From: *Anthony Nadalin > > *Date: *Fri, 12 Aug 2011 12:06:36 -0700 > *To: *"OAuth WG (oauth@ietf.org )" > > > *Subject: *[OAUTH-WG] Auth Code Swap Attack > > *Recommended Changes to draft-ietf-oauth-v2* > > In section 4, request options (e.g. 4.1.1) featuring "state" > should change from: > > state > > OPTIONAL. An opaque value used by the client to maintain state > between the request and callback. The authorization server > includes this value when redirecting the user-agent back to the > client. > > to: > > state > > REQUIRED. An opaque value used by the client to maintain state > between the request and callback. The authorization server > includes this value when redirecting the user-agent back to the > client. The encoded value SHOULD enable the client application to > determine the user-context that was active at the time of the > request (see section 10.12). The value MUST NOT be guessable or > predictable, and MUST be kept confidential. > > Making the parameter required without making its usage required (I.e. > "value SHOULD enable") accomplishes nothing. Also, what does "MUST be > kept confidential" mean? Confidential from what? Why specify an > "encoded value"? > > Section 10.12 Cross-Site Request Forgery > > Change to: > > Cross-site request forgery (CSRF) is a web-based attack whereby > HTTP requests are transmitted from the user-agent of an > end-user the server trusts or has authenticated. CSRF attacks > enable the attacker to intermix the attacker's security context > with that of the resource owner resulting in a compromise of > either the resource server or of the client application itself. In > the OAuth context, such attacks allow an attacker to inject their > own authorization code or access token into a client, which can > result in the client using an access token associated with the > attacker's account rather than the victim's. Depending on the > nature of the client and the protected resources, this can have > undesirable and damaging effects. > > In order to prevent such attacks, the client application MUST > encode a non-guessable, confidential end-user artifact and submit > as the "state" parameter to authorization and access token > requests to the authorization server. The client MUST keep the > state value in a location accessible only by the client or the > user-agent (i.e., protected by same-origin policy), for example, > using a DOM variable, HTTP cookie, or HTML5 client-side storage. > > The authorization server includes the value of the "state" > parameter when redirecting the user-agent back to the client. > Upon receiving a redirect, the client application MUST confirm > that returned value of "state" corresponds to the state value of > the user-agent's user session. If the end-user session represents > an authenticated user-identity, the client MUST ensure that the > user-identity has NOT changed. > > The above text uses 'user-context' and this 'user-identity'. Neither > term is defined. > > EHL > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020902040208010509000109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit making CSRF prevention a MUST and recommending the state parameter as implementation pattern is ok with me.

regards,
Torsten.

Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav:

I light to the recent discussion, do you still feel that changing ‘state’ from optional to required is the best approach?

 

EHL

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, August 21, 2011 11:04 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

My intention is to require clients to implement CSRF prevention. I thought making the state parameter mandatory would be the straightforward way.

regards,
Torsten.

Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav:

I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of ‘state’ from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below.

 

Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section’s language and clarity which we should address either way.

 

To clarify – I am not proposing we close this issue just yet.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

To demonstrate why making state required as proposed isn’t very helpful, here is an incomplete list of other requirements needed to make an effective CSRF:

 

* State value must not be empty (a common bug in many implementations using simple value comparison).

 

* ‘Non-guessable’ isn’t sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn’t sufficient. We use “cannot be generated, modified, or guessed to produce valid values” elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie.

 

* State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable.

 

In addition, this is not what “state” was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. ‘csrf’). By forcing clients to use “state” for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms.

 

EHL

 

 

 

 

From: Eran Hammer-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week.

 

The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful.

 

As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below.

 

 

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack

 

 

 

Recommended Changes to draft-ietf-oauth-v2

 

In section 4, request options (e.g. 4.1.1) featuring "state" should change from:

 

state

OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.

 

to:

 

state

REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the  request (see section 10.12). The value MUST NOT be guessable or predictable, and MUST be kept confidential.

 

 

Making the parameter required without making its usage required (I.e. "value SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confidential" mean? Confidential from what? Why specify an "encoded value"?

 

 

Section 10.12 Cross-Site Request Forgery

 

Change to:

 

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to inject their own authorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the "state" parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parameter when redirecting the user-agent back to the client. Upon receiving a redirect, the client application MUST confirm that returned value of "state" corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has NOT changed.

 

 

The above text uses 'user-context' and this 'user-identity'. Neither term is defined.

 

EHL




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------020902040208010509000109-- From barryleiba.mailing.lists@gmail.com Wed Aug 24 05:31:16 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7324121F8785 for ; Wed, 24 Aug 2011 05:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.031 X-Spam-Level: X-Spam-Status: No, score=-103.031 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OvQdqTV7YAD for ; Wed, 24 Aug 2011 05:31:15 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id C382121F8569 for ; Wed, 24 Aug 2011 05:31:15 -0700 (PDT) Received: by yie12 with SMTP id 12so983394yie.31 for ; Wed, 24 Aug 2011 05:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Q+t/T/fuIogkZj/x2ZsJ5QolA3TYHKsx4WY+WAcJ1UU=; b=egGbchYtz/3HamxmhMHURs4CRxiyHL2QdalEdx1et1Q/2hgBLZE/ZCXewyjIiP6J6+ 6e+BeKkl8P7b10du2CEMoJqx2+fjd8OJAndWk5900scHQH54qRSZ7S04YamEggKCVcXu F0Ur0vyO6uK2qoS2xGmSvXvHBgMnyyFhB1Zq8= MIME-Version: 1.0 Received: by 10.146.50.16 with SMTP id x16mr5126645yax.29.1314189145985; Wed, 24 Aug 2011 05:32:25 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Wed, 24 Aug 2011 05:32:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 08:32:25 -0400 X-Google-Sender-Auth: CNSJVwZkhETU4eNBSrWpAnS1gV0 Message-ID: From: Barry Leiba To: oauth@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:31:16 -0000 On Mon, Aug 22, 2011 at 1:53 PM, Barry Leiba wrot= e: > I intend to add the following to the response to this item: > "The working group understands that client code needs to know whether > to use and decode percent-encoding. =A0The issue is being discussed and > tracked, and will be resolved before the final version of the bearer > document is produced." For confirmation: Murray Kucherawy, our liaison to OMA, delivered our response yesterday (Tuesday, 23 August), and OMA has acknowledged it. They thank us for our prompt response. Barry, as chair > ----------------------------------------------------------------- > > The IETF OAuth working group thanks OMA ARC SEC for the liaison > statement titled "OAuth discovery and specification availability", > dated 18 July 2011. > > The OMA liaison statement asks the OAuth working group to address five > issues, and our answers are as follows: > > =95 =A0 =A0 =A0 Availability of the IETF OAuth specifications: especially > [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also > [draft-hammer-oauth-v2-mac-token], > [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. > > Answer: > The IETF cannot guarantee publication dates, but we can give some > best-guess timeframes. =A0At this writing, draft-ietf-oauth-v2 and > draft-ietf-oauth-v2-bearer have completed Working Group last call and > are undergoing their final revisions before being sent to the IESG. > We expect the final versions of those documents to be in the RFC > Editor queue around the end of September, though it could be later if > issues come up in IETF-wide last call or during IESG evaluation. =A0The > draft-hammer-oauth-v2-mac-token document has been replaced by > draft-ietf-oauth-v2-http-mac, which is a working group document. =A0It > is likely to be in the RFC Editor queue by the end of the year. > > The remaining two documents are not working group documents, and the > working group can say nothing about their status. =A0The OAuth working > group intends to revise its charter in the November timeframe, and > it's possible that one or both of those documents could be adopted by > the working group at that time, and we could have further information > about target publication dates then. > > =95 =A0 =A0 =A0 Availability of the OAuth Parameters Registry > > Answer: > The draft-ietf-oauth-v2 document establishes the OAuth Parameters > Registry (in section 11.2, as of draft version 20). =A0The registry will > be available when the RFC is published, which will be some time after > the document goes into the RFC Editor queue, depending upon the RFC > Editor's load at the time. > > =95 =A0 =A0 =A0 IETF intent to specify an OAuth Discovery mechanism > > Answer: > There is interest among OAuth working group participants for > specifying such a mechanism, but the work is not in the current > charter. =A0It will likely be considered during the aforementioned > charter update in (approximately) November. > > =95 =A0 =A0 =A0 Considerations that can help implementors decide about th= e type of > OAuth access token to deploy. > > Answer: > There is no current work planned, but documents with such > implementation advice might also be considered during the rechartering > discussion. > > =95 =A0 =A0 =A0 For bearer tokens: clarification whether the non-support = of percent > encoding for scope-v element of WWW-Authenticate Response Header Field > grammar is intentional. > > Answer: > In the bearer token document (Section 2.4 of > draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header > Field"), the "scope-v" element is unambiguously defined to allow a > specific set of characters. =A0That set of characters does permit, but > does not mandate, support for percent-encoding of characters. > > ----------------------------------------------------------------- From eran@hueniverse.com Wed Aug 24 07:54:44 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F2C21F8BB3 for ; Wed, 24 Aug 2011 07:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSywqOnl7bUP for ; Wed, 24 Aug 2011 07:54:40 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 57CB521F8BCB for ; Wed, 24 Aug 2011 07:54:38 -0700 (PDT) Received: (qmail 22932 invoked from network); 24 Aug 2011 14:55:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 Aug 2011 14:55:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 24 Aug 2011 07:55:40 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Wed, 24 Aug 2011 07:54:10 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxiI/aYTOXd2IOsQs29XYLRykfLVwASahbQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A293491@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5494D4.4060109@lodderstedt.net> In-Reply-To: <4E5494D4.4060109@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234518A293491P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 14:54:44 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234518A293491P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe we have full consensus on this approach. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Tuesday, August 23, 2011 11:06 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack making CSRF prevention a MUST and recommending the state parameter as imple= mentation pattern is ok with me. regards, Torsten. Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav: I light to the recent discussion, do you still feel that changing 'state' f= rom optional to required is the best approach? EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, August 21, 2011 11:04 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack My intention is to require clients to implement CSRF prevention. I thought = making the state parameter mandatory would be the straightforward way. regards, Torsten. Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: I would like to hear from the other 3 authors of the proposed change about = their reasons for changing the use of 'state' from recommended to required = for CSRF prevention. It would also help moving this issue forward if the 4 = authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I be= lieve we have a tie (4:4) and therefore no consensus for making it (as of t= his point). However, we did identify issues with the section's language and= clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, he= re is an incomplete list of other requirements needed to make an effective = CSRF: * State value must not be empty (a common bug in many implementations using= simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a has= h of the session cookie, with or without salt which isn't sufficient. We us= e "cannot be generated, modified, or guessed to produce valid values" elsew= here in the document, but this is much easier to get right for access token= s and refresh tokens than CSRF tokens which are often just some algorithm o= n top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session = cookie to prevent the use of a leaked state value in multiple attacks on th= e same user session once the leak is no longer viable. In addition, this is not what "state" was originally intended for. If the w= orking group decides to mandate a CSRF parameter, it should probably be a n= ew parameter with a more appropriate name (e.g. 'csrf'). By forcing clients= to use "state" for this purpose, developers will need to use dynamic queri= es for other state information which further reduces the security of the pr= otocol (as the draft recommends not using dynamic callback query components= ). Encoding both CSRF tokens and other state information can be non-intuiti= ve or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to bette= r documenting it (though I feel the current text is already sufficient), bu= t we can't realistically expect to identify and close every possible browse= r-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF att= acks are not likely to implement it correctly with this information. Those = who understand it do not need the extra verbiage which is more confusing th= an helpful. As for the new requirements, they are insufficient to actually accomplish w= hat the authors propose without additional requirements on state local stor= age and verification to complete the flow. Also, the proposed text needs cl= arifications as noted below. From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring "state" should change = from: state OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable= the client application to determine the user-context that was active at th= e time of the request (see section 10.12). The value MUST NOT be guessable= or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. "valu= e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi= dential" mean? Confidential from what? Why specify an "encoded value"? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the resource owner resulting in a comprom= ise of either the resource server or of the client application itself. In t= he OAuth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather than th= e victim's. Depending on the nature of the client and the protected resourc= es, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "state" paramet= er to authorization and access token requests to the authorization server. = The client MUST keep the state value in a location accessible only by the c= lient or the user-agent (i.e., protected by same-origin policy), for exampl= e, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirect, th= e client application MUST confirm that returned value of "state" correspond= s to the state value of the user-agent's user session. If the end-user sess= ion represents an authenticated user-identity, the client MUST ensure that = the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term i= s defined. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E7234518A293491P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I believe we have full consensus on this appr= oach.

 

EHL

 

From: Torsten Lodderstedt [mailto:torste= n@lodderstedt.net]
Sent: Tuesday, August 23, 2011 11:06 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Su= bject: Re: [OAUTH-WG] Auth Code Swap Attack

=

 

making= CSRF prevention a MUST and recommending the state parameter as implementat= ion pattern is ok with me.

regards,
Torsten.

Am 21.08.2011= 21:02, schrieb Eran Hammer-Lahav:

I light to the recent discussion, do you still fe= el that changing ‘state’ from optional to required is the best = approach?

 

EHL

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, August 21, 2011 11:04 AM
To: Eran Hammer-La= hav
Cc: OAuth WG (oauth@ietf.or= g)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack<= /o:p>

 

My intention is to require clients to implement CSRF prevention. I= thought making the state parameter mandatory would be the straightforward = way.

regards,
Torsten.

Am 18.08.2011 08:04, schrieb Eran H= ammer-Lahav:

I would like to hear from the other 3 authors of the proposed change ab= out their reasons for changing the use of ‘state’ from recommen= ded to required for CSRF prevention. It would also help moving this issue f= orward if the 4 authors can provide answers or clarifications on the issues= raised below.

 

Assuming we can count all 4 authors are in favor of making = the change, I believe we have a tie (4:4) and therefore no consensus for ma= king it (as of this point). However, we did identify issues with the sectio= n’s language and clarity which we should address either way.

 

To clar= ify – I am not proposing we close this issue just yet.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.org)Subject: Re: [OAUTH-WG] Auth Code Swap Attack

=

 

= To demonstrate why making state required as p= roposed isn’t very helpful, here is an incomplete list of other requi= rements needed to make an effective CSRF:

 

* State value must not be empty = (a common bug in many implementations using simple value comparison).

 

* &#= 8216;Non-guessable’ isn’t sufficient as most developers will si= mply use a hash of the session cookie, with or without salt which isn’= ;t sufficient. We use “cannot be generated, modified, or guessed to p= roduce valid values” elsewhere in the document, but this is much easi= er to get right for access tokens and refresh tokens than CSRF tokens which= are often just some algorithm on top of the session cookie.

 

* State CSRF = value should be short-lived or based on a short-lived session cookie to pre= vent the use of a leaked state value in multiple attacks on the same user s= ession once the leak is no longer viable.

 

In addition, this is not what &#= 8220;state” was originally intended for. If the working group decides= to mandate a CSRF parameter, it should probably be a new parameter with a = more appropriate name (e.g. ‘csrf’). By forcing clients to use = “state” for this purpose, developers will need to use dynamic q= ueries for other state information which further reduces the security of th= e protocol (as the draft recommends not using dynamic callback query compon= ents). Encoding both CSRF tokens and other state information can be non-int= uitive or complicated for some developers/platforms.

<= p class=3DMsoNormal> <= /p>

EHL=

 

 

 

 

From: Eran Hamm= er-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Ant= hony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

=

 

 

From: = Anthony Nadalin <tonynad@mi= crosoft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
T= o: "OAuth WG (oauth@ietf.org= )" <oauth@ietf.org>
= Subject: [OAUTH-WG] Auth Code Swap Attack

 <= /p>

 <= /span>

 

Recommended Changes = to draft-ietf-oauth-v2

 

<= p class=3DMsoNormal>In section 4, request options = (e.g. 4.1.1) featuring "state" should change from:<= o:p>

 

state

OPTIONAL. = An opaque value used by the client to maintain state between the request an= d callback. The authorization server includes this value when redirecting t= he user-agent back to the client.

 

to:<= /o:p>

 

state

REQUIRED. An opaq= ue value used by the client to maintain state between the request and callb= ack. The authorization server includes this value when redirecting the user= -agent back to the client. The encoded value SHOULD enable the client appli= cation to determine the user-context that was active at the time of the &nb= sp;request (see section 10.12). The value MUST NOT be guessable or predicta= ble, and MUST be kept confidential.

 

 

Making the parameter required without ma= king its usage required (I.e. "value SHOULD enable") accomplishes= nothing. Also, what does "MUST be kept confidential" mean? Confi= dential from what? Why specify an "encoded value"?

&nb= sp;

 

Section 10.12 Cross-Site Request Forgery

 

Change to:

 

Cross-s= ite request forgery (CSRF) is a web-based attack whereby HTTP requests are = transmitted from the user-agent of an end-user the server trusts or ha= s authenticated. CSRF attacks enable the attacker to intermix the attacker'= s security context with that of the resource owner resulting in a comp= romise of either the resource server or of the client application itself. I= n the OAuth context, such attacks allow an attacker to inject their ow= n authorization code or access token into a client, which can result in the= client using an access token associated with the attacker's account r= ather than the victim's. Depending on the nature of the client and the prot= ected resources, this can have undesirable and damaging effects.
In order to prevent such attacks, the client application MUST encode a no= n-guessable, confidential end-user artifact and submit as the "st= ate" parameter to authorization and access token requests to the autho= rization server. The client MUST keep the state value in a location ac= cessible only by the client or the user-agent (i.e., protected by same-orig= in policy), for example, using a DOM variable, HTTP cookie, or HTML5 c= lient-side storage.

The authorization server includes the value of t= he "state" parameter when redirecting the user-agent back to the = client. Upon receiving a redirect, the client application MUST confirm= that returned value of "state" corresponds to the state value of= the user-agent's user session. If the end-user session represents an authe= nticated user-identity, the client MUST ensure that the user-identity = has NOT changed.

 

 

<= span style=3D'font-size:10.5pt'>The above text uses 'user-context' and this= 'user-identity'. Neither term is defined.

=

 

EHL= 




__________________________________________=
_____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailm=
an/listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234518A293491P3PW5EX1MB01E_-- From barryleiba.mailing.lists@gmail.com Wed Aug 24 08:35:22 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF8121F8B74 for ; Wed, 24 Aug 2011 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.03 X-Spam-Level: X-Spam-Status: No, score=-103.03 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ-WF4uMbt-b for ; Wed, 24 Aug 2011 08:35:21 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAEF21F8B30 for ; Wed, 24 Aug 2011 08:35:21 -0700 (PDT) Received: by ywe9 with SMTP id 9so1136494ywe.31 for ; Wed, 24 Aug 2011 08:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=v/S701rgVMDOo3cqMbyeyPlYpb8InCX9dPWncqXeVf4=; b=QUWGT0KyXV6swfFs6LBazjgu5wm/6GfpMtpP6YJNTaNdQFLLZMWSpBrZ+fB2fQU6S4 Khg+O+q09xIdx3qkrsfgzXew6UTRHGKyqHNWbKh+iHIH+pTUWNRwlBKmOn871YHkCw/W y/uJ/C6+5OlpgKMSb07Xyu4XRH7w1xqlV0duk= MIME-Version: 1.0 Received: by 10.236.187.74 with SMTP id x50mr31143878yhm.76.1314200173484; Wed, 24 Aug 2011 08:36:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Wed, 24 Aug 2011 08:36:13 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A293491@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5494D4.4060109@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A293491@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 24 Aug 2011 11:36:13 -0400 X-Google-Sender-Auth: mp__S-fA6FCOZvQjMF5VgrJEjOE Message-ID: From: Barry Leiba To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 15:35:22 -0000 > I believe we have full consensus on this approach. I agree, and I will close the issue. Barry, happy chair From trac+oauth@trac.tools.ietf.org Wed Aug 24 08:36:46 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EFB21F8B91 for ; Wed, 24 Aug 2011 08:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8uv-Vs6fTVh for ; Wed, 24 Aug 2011 08:36:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:123a::1:2a]) by ietfa.amsl.com (Postfix) with ESMTP id 2E31721F8B85 for ; Wed, 24 Aug 2011 08:36:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QwFWd-00076q-Qq; Wed, 24 Aug 2011 08:37:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "oauth issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: barryleiba@computer.org X-Trac-Project: oauth Date: Wed, 24 Aug 2011 15:37:55 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/23#comment:1 Message-ID: <072.4a441e5c1fff65845e98e929d32066cc@trac.tools.ietf.org> References: <063.7f8c809279a65936aee8fa160f5f16a8@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <063.7f8c809279a65936aee8fa160f5f16a8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: barryleiba@computer.org, oauth@ietf.org X-SA-Exim-Mail-From: trac+oauth@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #23: Auth Code Swap Attack (CSRF) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 15:36:46 -0000 #23: Auth Code Swap Attack (CSRF) Changes (by barryleiba@…): * status: new => closed * resolution: => fixed Comment: Consensus is to make CSRF prevention a MUST and to recommend the state parameter as an implementation mechanism. Text will go into version -21. -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From igor.faynberg@alcatel-lucent.com Wed Aug 24 09:44:12 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7498D21F8C80 for ; Wed, 24 Aug 2011 09:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XynUIc9Eyc4I for ; Wed, 24 Aug 2011 09:44:11 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id B9A1021F8C3E for ; Wed, 24 Aug 2011 09:44:11 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p7OGjK2S026402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 24 Aug 2011 11:45:20 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7OGjJOn017108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Aug 2011 11:45:20 -0500 Received: from [135.244.35.237] (faynberg.lra.lucent.com [135.244.35.237]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p7OGjIGg009761; Wed, 24 Aug 2011 11:45:19 -0500 (CDT) Message-ID: <4E552A9E.6040201@alcatel-lucent.com> Date: Wed, 24 Aug 2011 12:45:18 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 16:44:12 -0000 Bravo! This has been project-managed masterly. Igor On 8/24/2011 8:32 AM, Barry Leiba wrote: > On Mon, Aug 22, 2011 at 1:53 PM, Barry Leiba wrote: >> I intend to add the following to the response to this item: >> "The working group understands that client code needs to know whether >> to use and decode percent-encoding. The issue is being discussed and >> tracked, and will be resolved before the final version of the bearer >> document is produced." > > For confirmation: Murray Kucherawy, our liaison to OMA, delivered our > response yesterday (Tuesday, 23 August), and OMA has acknowledged it. > They thank us for our prompt response. > > Barry, as chair > >> ----------------------------------------------------------------- >> >> The IETF OAuth working group thanks OMA ARC SEC for the liaison >> statement titled "OAuth discovery and specification availability", >> dated 18 July 2011. >> >> The OMA liaison statement asks the OAuth working group to address five >> issues, and our answers are as follows: >> >> • Availability of the IETF OAuth specifications: especially >> [draft-ietf-oauth-v2] and [draft-ietf-oauth-v2-bearer], and also >> [draft-hammer-oauth-v2-mac-token], >> [draft-lodderstedt-oauth-revocation] and [draft-recordon-oauth-v2-ux]. >> >> Answer: >> The IETF cannot guarantee publication dates, but we can give some >> best-guess timeframes. At this writing, draft-ietf-oauth-v2 and >> draft-ietf-oauth-v2-bearer have completed Working Group last call and >> are undergoing their final revisions before being sent to the IESG. >> We expect the final versions of those documents to be in the RFC >> Editor queue around the end of September, though it could be later if >> issues come up in IETF-wide last call or during IESG evaluation. The >> draft-hammer-oauth-v2-mac-token document has been replaced by >> draft-ietf-oauth-v2-http-mac, which is a working group document. It >> is likely to be in the RFC Editor queue by the end of the year. >> >> The remaining two documents are not working group documents, and the >> working group can say nothing about their status. The OAuth working >> group intends to revise its charter in the November timeframe, and >> it's possible that one or both of those documents could be adopted by >> the working group at that time, and we could have further information >> about target publication dates then. >> >> • Availability of the OAuth Parameters Registry >> >> Answer: >> The draft-ietf-oauth-v2 document establishes the OAuth Parameters >> Registry (in section 11.2, as of draft version 20). The registry will >> be available when the RFC is published, which will be some time after >> the document goes into the RFC Editor queue, depending upon the RFC >> Editor's load at the time. >> >> • IETF intent to specify an OAuth Discovery mechanism >> >> Answer: >> There is interest among OAuth working group participants for >> specifying such a mechanism, but the work is not in the current >> charter. It will likely be considered during the aforementioned >> charter update in (approximately) November. >> >> • Considerations that can help implementors decide about the type of >> OAuth access token to deploy. >> >> Answer: >> There is no current work planned, but documents with such >> implementation advice might also be considered during the rechartering >> discussion. >> >> • For bearer tokens: clarification whether the non-support of percent >> encoding for scope-v element of WWW-Authenticate Response Header Field >> grammar is intentional. >> >> Answer: >> In the bearer token document (Section 2.4 of >> draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header >> Field"), the "scope-v" element is unambiguously defined to allow a >> specific set of characters. That set of characters does permit, but >> does not mandate, support for percent-encoding of characters. >> >> ----------------------------------------------------------------- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From tonynad@microsoft.com Thu Aug 25 08:34:07 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E964B21F861A for ; Thu, 25 Aug 2011 08:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.466 X-Spam-Level: X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6WgY2hewMhJ for ; Thu, 25 Aug 2011 08:34:03 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id CEE9521F85B1 for ; Thu, 25 Aug 2011 08:33:55 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 25 Aug 2011 08:35:09 -0700 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Aug 2011 08:34:50 -0700 Received: from mail215-ch1-R.bigfish.com (216.32.181.174) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Thu, 25 Aug 2011 15:11:13 +0000 Received: from mail215-ch1 (localhost.localdomain [127.0.0.1]) by mail215-ch1-R.bigfish.com (Postfix) with ESMTP id 67CA012803C2 for ; Thu, 25 Aug 2011 15:11:13 +0000 (UTC) X-SpamScore: -20 X-BigFish: PS-20(zz9371Kc85fhzz1202h1082kzz8275ch1033IL8275bh8275dhz31h2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT005.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail215-ch1: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT005.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail215-ch1 (localhost.localdomain [127.0.0.1]) by mail215-ch1 (MessageSwitch) id 1314285071539842_16934; Thu, 25 Aug 2011 15:11:11 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail215-ch1.bigfish.com (Postfix) with ESMTP id 7E8BFA6004B; Thu, 25 Aug 2011 15:11:11 +0000 (UTC) Received: from SN2PRD0302HT005.namprd03.prod.outlook.com (207.46.4.139) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 25 Aug 2011 15:11:06 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.2.234]) by SN2PRD0302HT005.namprd03.prod.outlook.com ([10.27.50.88]) with mapi id 14.01.0225.064; Thu, 25 Aug 2011 15:11:01 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZImYoC2iZvOhxR/+zEXUukLHDogAF8TGAAIvI14AAgNyjAACwAFgAAAIJGIAAe8GCAAAScGQAADLTUAA= Date: Thu, 25 Aug 2011 15:11:01 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5494D4.4060109@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A293491@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A293491@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.28.29.112] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E772FSN2PRD0302MB137_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0302HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LODDERSTEDT.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:34:08 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E772FSN2PRD0302MB137_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have not seen any updated text, so I don't believe we have consensus. Als= o we have a flawed protocol and we are not providing a fix, suggest that MU= ST be on the state also unless someone has a better fix From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Wednesday, August 24, 2011 7:54 AM To: Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack I believe we have full consensus on this approach. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Tuesday, August 23, 2011 11:06 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack making CSRF prevention a MUST and recommending the state parameter as imple= mentation pattern is ok with me. regards, Torsten. Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav: I light to the recent discussion, do you still feel that changing 'state' f= rom optional to required is the best approach? EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, August 21, 2011 11:04 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack My intention is to require clients to implement CSRF prevention. I thought = making the state parameter mandatory would be the straightforward way. regards, Torsten. Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: I would like to hear from the other 3 authors of the proposed change about = their reasons for changing the use of 'state' from recommended to required = for CSRF prevention. It would also help moving this issue forward if the 4 = authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I be= lieve we have a tie (4:4) and therefore no consensus for making it (as of t= his point). However, we did identify issues with the section's language and= clarity which we should address either way. To clarify - I am not proposing we close this issue just yet. EHL From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Monday, August 15, 2011 9:35 AM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, he= re is an incomplete list of other requirements needed to make an effective = CSRF: * State value must not be empty (a common bug in many implementations using= simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a has= h of the session cookie, with or without salt which isn't sufficient. We us= e "cannot be generated, modified, or guessed to produce valid values" elsew= here in the document, but this is much easier to get right for access token= s and refresh tokens than CSRF tokens which are often just some algorithm o= n top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session = cookie to prevent the use of a leaked state value in multiple attacks on th= e same user session once the leak is no longer viable. In addition, this is not what "state" was originally intended for. If the w= orking group decides to mandate a CSRF parameter, it should probably be a n= ew parameter with a more appropriate name (e.g. 'csrf'). By forcing clients= to use "state" for this purpose, developers will need to use dynamic queri= es for other state information which further reduces the security of the pr= otocol (as the draft recommends not using dynamic callback query components= ). Encoding both CSRF tokens and other state information can be non-intuiti= ve or complicated for some developers/platforms. EHL From: Eran Hammer-Lahav Sent: Friday, August 12, 2011 2:53 PM To: Anthony Nadalin; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to bette= r documenting it (though I feel the current text is already sufficient), bu= t we can't realistically expect to identify and close every possible browse= r-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF att= acks are not likely to implement it correctly with this information. Those = who understand it do not need the extra verbiage which is more confusing th= an helpful. As for the new requirements, they are insufficient to actually accomplish w= hat the authors propose without additional requirements on state local stor= age and verification to complete the flow. Also, the proposed text needs cl= arifications as noted below. From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack Recommended Changes to draft-ietf-oauth-v2 In section 4, request options (e.g. 4.1.1) featuring "state" should change = from: state OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable= the client application to determine the user-context that was active at th= e time of the request (see section 10.12). The value MUST NOT be guessable= or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. "valu= e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi= dential" mean? Confidential from what? Why specify an "encoded value"? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the attacke= r's security context with that of the resource owner resulting in a comprom= ise of either the resource server or of the client application itself. In t= he OAuth context, such attacks allow an attacker to inject their own author= ization code or access token into a client, which can result in the client = using an access token associated with the attacker's account rather than th= e victim's. Depending on the nature of the client and the protected resourc= es, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "state" paramet= er to authorization and access token requests to the authorization server. = The client MUST keep the state value in a location accessible only by the c= lient or the user-agent (i.e., protected by same-origin policy), for exampl= e, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the "state" parameter when r= edirecting the user-agent back to the client. Upon receiving a redirect, th= e client application MUST confirm that returned value of "state" correspond= s to the state value of the user-agent's user session. If the end-user sess= ion represents an authenticated user-identity, the client MUST ensure that = the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term i= s defined. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E772FSN2PRD0302MB137_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have not seen any up= dated text, so I don’t believe we have consensus. Also we have a flaw= ed protocol and we are not providing a fix, suggest that MUST be on the sta= te also unless someone has a better fix

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf= .org] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, August 24, 2011 7:54 AM
To: Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

I believe we have full= consensus on this approach.

 

EHL<= /p>

 

From: Torsten Lodderstedt [mailto:torsten@lodders= tedt.net]
Sent: Tuesday, August 23, 2011 11:06 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)<= br> Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

making CSRF prevention a MUST and recommending the s= tate parameter as implementation pattern is ok with me.

regards,
Torsten.

Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav:

I light to the recent = discussion, do you still feel that changing ‘state’ from option= al to required is the best approach?

 

EHL<= /p>

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, August 21, 2011 11:04 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)<= br> Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

My intention is to require clients to implement CSRF= prevention. I thought making the state parameter mandatory would be the st= raightforward way.

regards,
Torsten.

Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav:

I would like to hear f= rom the other 3 authors of the proposed change about their reasons for chan= ging the use of ‘state’ from recommended to required for CSRF p= revention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issu= es raised below.

 

Assuming we can count = all 4 authors are in favor of making the change, I believe we have a tie (4= :4) and therefore no consensus for making it (as of this point). However, w= e did identify issues with the section’s language and clarity which we should address either way.=

 

To clarify – I a= m not proposing we close this issue just yet.

 

EHL<= /p>

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.org)<= br> Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

To demonstrate why mak= ing state required as proposed isn’t very helpful, here is an incompl= ete list of other requirements needed to make an effective CSRF:

 

* State value must not= be empty (a common bug in many implementations using simple value comparis= on).

 

* ‘Non-guessable= ’ isn’t sufficient as most developers will simply use a hash of= the session cookie, with or without salt which isn’t sufficient. We = use “cannot be generated, modified, or guessed to produce valid values” elsewhere in the document, but this is much easier to get ri= ght for access tokens and refresh tokens than CSRF tokens which are often j= ust some algorithm on top of the session cookie.

 

* State CSRF value sho= uld be short-lived or based on a short-lived session cookie to prevent the = use of a leaked state value in multiple attacks on the same user session on= ce the leak is no longer viable.

 

In addition, this is n= ot what “state” was originally intended for. If the working gro= up decides to mandate a CSRF parameter, it should probably be a new paramet= er with a more appropriate name (e.g. ‘csrf’). By forcing clients to use “state” for this purpose, developers wi= ll need to use dynamic queries for other state information which further re= duces the security of the protocol (as the draft recommends not using dynam= ic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicate= d for some developers/platforms.

 

EHL<= /p>

 

 

 

 

From: Eran Ham= mer-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG (oau= th@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

 

This is really just= a flavor of CSRF attacks. I have no objections to better documenting it (t= hough I feel the current text is already sufficient), but we can't realisti= cally expect to identify and close every possible browser-based attack. A new one is invented every other week.

 <= /o:p>

The problem with th= is text is that developers who do no understand CSRF attacks are not likely= to implement it correctly with this information. Those who understand it d= o not need the extra verbiage which is more confusing than helpful.

 <= /o:p>

As for the new requ= irements, they are insufficient to actually accomplish what the authors pro= pose without additional requirements on state local storage and verificatio= n to complete the flow. Also, the proposed text needs clarifications as noted below.

 <= /o:p>

 <= /o:p>

From: Anthony Nadalin <tonynad@microsoft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org= )" <oauth@ietf.org> Subject: [OAUTH-WG] Auth Code Swap Attack

 <= /o:p>

 <= /o:p>

 <= /o:p>

Recommended Changes to draft-ietf-o= auth-v2

=  

In se= ction 4, request options (e.g. 4.1.1) featuring "state" should ch= ange from:

=  

= state

= OPTIONAL. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client.

=  

to:

=  

= state

= REQUIRED. An opaque value used by the client to maintain state between the = request and callback. The authorization server includes this value when red= irecting the user-agent back to the client. The encoded value SHOULD enable the client application to determin= e the user-context that was active at the time of the  request (see se= ction 10.12). The value MUST NOT be guessable or predictable, and MUST be k= ept confidential.

=  

 <= /o:p>

Making the paramete= r required without making its usage required (I.e. "value SHOULD enabl= e") accomplishes nothing. Also, what does "MUST be kept confident= ial" mean? Confidential from what? Why specify an "encoded value"?

 <= /o:p>

 <= /o:p>

Secti= on 10.12 Cross-Site Request Forgery

=  

Chang= e to:

=  

= Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques= ts are transmitted from the user-agent of an end-user the server trust= s or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the&= nbsp;resource owner resulting in a compromise of either the resource server= or of the client application itself. In the OAuth context, such attac= ks allow an attacker to inject their own authorization code or access token into a client, which can result in the client using a= n access token associated with the attacker's account rather than the = victim's. Depending on the nature of the client and the protected reso= urces, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-= guessable, confidential end-user artifact and submit as the "stat= e" parameter to authorization and access token requests to the authori= zation server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., = protected by same-origin policy), for example, using a DOM variable, H= TTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parame= ter when redirecting the user-agent back to the client. Upon receiving= a redirect, the client application MUST confirm that returned value of &qu= ot;state" corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-ide= ntity, the client MUST ensure that the user-identity has NOT changed.<= /span>

 

 <= /o:p>

The above text uses= 'user-context' and this 'user-identity'. Neither term is defined.

 <= /o:p>

EHL




_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ie=
tf.org/mailman/listinfo/oauth

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E772FSN2PRD0302MB137_-- From phil.hunt@oracle.com Thu Aug 25 09:24:32 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570AF21F86AF for ; Thu, 25 Aug 2011 09:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tlcktyzkWan for ; Thu, 25 Aug 2011 09:24:30 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 60D7221F86B6 for ; Thu, 25 Aug 2011 09:24:30 -0700 (PDT) Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7PGPe6L013173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Aug 2011 16:25:42 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7PGPcW7010110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2011 16:25:39 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7PGPXvq032146; Thu, 25 Aug 2011 11:25:33 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Aug 2011 09:25:32 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-76-974881539 From: Phil Hunt In-Reply-To: Date: Thu, 25 Aug 2011 09:25:30 -0700 Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5494D4.4060109@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A293491@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Anthony Nadalin X-Mailer: Apple Mail (2.1084) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090208.4E567787.0022,ss=1,re=-6.500,fgs=0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Auth Code Swap Attack X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:24:32 -0000 --Apple-Mail-76-974881539 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree. I think at least one implementation must be included in the = spec. However, I'd like to see it left that more methods could be = implemented in the future. =20 I can live with "SHOULD" given the definition in 2119. Or phrased "MUST = implement at least the following method..." for stronger language. Tony is correct, I think it is a serious issue given the dependence on = grants being passed by URLs through redirects. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-08-25, at 8:11 AM, Anthony Nadalin wrote: > I have not seen any updated text, so I don=92t believe we have = consensus. Also we have a flawed protocol and we are not providing a = fix, suggest that MUST be on the state also unless someone has a better = fix > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer-Lahav > Sent: Wednesday, August 24, 2011 7:54 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > =20 > I believe we have full consensus on this approach. > =20 > EHL > =20 > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 > Sent: Tuesday, August 23, 2011 11:06 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > =20 > making CSRF prevention a MUST and recommending the state parameter as = implementation pattern is ok with me. >=20 > regards, > Torsten. >=20 > Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav: > I light to the recent discussion, do you still feel that changing = =91state=92 from optional to required is the best approach? > =20 > EHL > =20 > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 > Sent: Sunday, August 21, 2011 11:04 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > =20 > My intention is to require clients to implement CSRF prevention. I = thought making the state parameter mandatory would be the = straightforward way. >=20 > regards, > Torsten. >=20 > Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: > I would like to hear from the other 3 authors of the proposed change = about their reasons for changing the use of =91state=92 from recommended = to required for CSRF prevention. It would also help moving this issue = forward if the 4 authors can provide answers or clarifications on the = issues raised below. > =20 > Assuming we can count all 4 authors are in favor of making the change, = I believe we have a tie (4:4) and therefore no consensus for making it = (as of this point). However, we did identify issues with the section=92s = language and clarity which we should address either way. > =20 > To clarify =96 I am not proposing we close this issue just yet. > =20 > EHL > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer-Lahav > Sent: Monday, August 15, 2011 9:35 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > =20 > To demonstrate why making state required as proposed isn=92t very = helpful, here is an incomplete list of other requirements needed to make = an effective CSRF: > =20 > * State value must not be empty (a common bug in many implementations = using simple value comparison). > =20 > * =91Non-guessable=92 isn=92t sufficient as most developers will = simply use a hash of the session cookie, with or without salt which = isn=92t sufficient. We use =93cannot be generated, modified, or guessed = to produce valid values=94 elsewhere in the document, but this is much = easier to get right for access tokens and refresh tokens than CSRF = tokens which are often just some algorithm on top of the session cookie. > =20 > * State CSRF value should be short-lived or based on a short-lived = session cookie to prevent the use of a leaked state value in multiple = attacks on the same user session once the leak is no longer viable. > =20 > In addition, this is not what =93state=94 was originally intended for. = If the working group decides to mandate a CSRF parameter, it should = probably be a new parameter with a more appropriate name (e.g. =91csrf=92)= . By forcing clients to use =93state=94 for this purpose, developers = will need to use dynamic queries for other state information which = further reduces the security of the protocol (as the draft recommends = not using dynamic callback query components). Encoding both CSRF tokens = and other state information can be non-intuitive or complicated for some = developers/platforms. > =20 > EHL > =20 > =20 > =20 > =20 > From: Eran Hammer-Lahav=20 > Sent: Friday, August 12, 2011 2:53 PM > To: Anthony Nadalin; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > =20 > This is really just a flavor of CSRF attacks. I have no objections to = better documenting it (though I feel the current text is already = sufficient), but we can't realistically expect to identify and close = every possible browser-based attack. A new one is invented every other = week. > =20 > The problem with this text is that developers who do no understand = CSRF attacks are not likely to implement it correctly with this = information. Those who understand it do not need the extra verbiage = which is more confusing than helpful. > =20 > As for the new requirements, they are insufficient to actually = accomplish what the authors propose without additional requirements on = state local storage and verification to complete the flow. Also, the = proposed text needs clarifications as noted below. > =20 > =20 > From: Anthony Nadalin > Date: Fri, 12 Aug 2011 12:06:36 -0700 > To: "OAuth WG (oauth@ietf.org)" > Subject: [OAUTH-WG] Auth Code Swap Attack > =20 > =20 > =20 > Recommended Changes to draft-ietf-oauth-v2 > =20 > In section 4, request options (e.g. 4.1.1) featuring "state" should = change from: > =20 > state > OPTIONAL. An opaque value used by the client to maintain state between = the request and callback. The authorization server includes this value = when redirecting the user-agent back to the client. > =20 > to: > =20 > state > REQUIRED. An opaque value used by the client to maintain state between = the request and callback. The authorization server includes this value = when redirecting the user-agent back to the client. The encoded value = SHOULD enable the client application to determine the user-context that = was active at the time of the request (see section 10.12). The value = MUST NOT be guessable or predictable, and MUST be kept confidential. > =20 > =20 > Making the parameter required without making its usage required (I.e. = "value SHOULD enable") accomplishes nothing. Also, what does "MUST be = kept confidential" mean? Confidential from what? Why specify an "encoded = value"? > =20 > =20 > Section 10.12 Cross-Site Request Forgery > =20 > Change to: > =20 > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP = requests are transmitted from the user-agent of an end-user the server = trusts or has authenticated. CSRF attacks enable the attacker to = intermix the attacker's security context with that of the resource owner = resulting in a compromise of either the resource server or of the client = application itself. In the OAuth context, such attacks allow an attacker = to inject their own authorization code or access token into a client, = which can result in the client using an access token associated with the = attacker's account rather than the victim's. Depending on the nature of = the client and the protected resources, this can have undesirable and = damaging effects. >=20 > In order to prevent such attacks, the client application MUST encode a = non-guessable, confidential end-user artifact and submit as the "state" = parameter to authorization and access token requests to the = authorization server. The client MUST keep the state value in a location = accessible only by the client or the user-agent (i.e., protected by = same-origin policy), for example, using a DOM variable, HTTP cookie, or = HTML5 client-side storage. >=20 > The authorization server includes the value of the "state" parameter = when redirecting the user-agent back to the client. Upon receiving a = redirect, the client application MUST confirm that returned value of = "state" corresponds to the state value of the user-agent's user session. = If the end-user session represents an authenticated user-identity, the = client MUST ensure that the user-identity has NOT changed. > =20 > =20 > The above text uses 'user-context' and this 'user-identity'. Neither = term is defined. > =20 > EHL >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-76-974881539 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = agree. I think at least one implementation must be included in the spec. =  However, I'd like to see it left that more methods could be = implemented in the future.  

I can live with = "SHOULD" given the definition in 2119.  Or phrased "MUST implement = at least the following method..." for stronger = language.

Tony is correct, I think it is a = serious issue given the dependence on grants being passed by URLs = through redirects.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-08-25, at 8:11 AM, Anthony Nadalin wrote:

I = have not seen any updated text, so I don=92t believe we have consensus. = Also we have a flawed protocol and we are not providing a fix, suggest = that MUST be on the state also unless someone has a better = fix
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.or= g] On Behalf = Of Eran = Hammer-Lahav
Sent: Wednesday, August 24, 2011 = 7:54 AM
To: Torsten = Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code = Swap Attack
I believe we have full consensus on this = approach.
 
 
 Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 
Sent: Tuesday, August 23, 2011 = 11:06 PM
To: Eran = Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code = Swap Attack
making CSRF prevention = a MUST and recommending the state parameter as implementation pattern is = ok with me.

regards,
Torsten.

Am 21.08.2011 21:02, = schrieb Eran Hammer-Lahav:
I light to the recent discussion, do = you still feel that changing =91state=92 from optional to required is = the best approach?
 
 
 Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 
Sent: Sunday, August 21, 2011 = 11:04 AM
To: Eran = Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code = Swap Attack
My intention is to = require clients to implement CSRF prevention. I thought making the state = parameter mandatory would be the straightforward = way.

regards,
Torsten.

Am 18.08.2011 08:04, schrieb = Eran Hammer-Lahav:
I would like to hear from the other = 3 authors of the proposed change about their reasons for changing the = use of =91state=92 from recommended to required for CSRF prevention. It = would also help moving this issue forward if the 4 authors can provide = answers or clarifications on the issues raised = below.
 
 
To = clarify =96 I am not proposing we close this issue just = yet.
 
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran = Hammer-Lahav
Sent: Monday, August 15, 2011 = 9:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code = Swap Attack
To demonstrate why making state required as proposed = isn=92t very helpful, here is an incomplete list of other requirements = needed to make an effective CSRF:
* State value must not be empty (a = common bug in many implementations using simple value = comparison).
 
* = =91Non-guessable=92 isn=92t sufficient as most developers will simply = use a hash of the session cookie, with or without salt which isn=92t = sufficient. We use =93cannot be generated, modified, or guessed to = produce valid values=94 elsewhere in the document, but this is much = easier to get right for access tokens and refresh tokens than CSRF = tokens which are often just some algorithm on top of the session = cookie.
 
* = State CSRF value should be short-lived or based on a short-lived session = cookie to prevent the use of a leaked state value in multiple attacks on = the same user session once the leak is no longer = viable.
 
In = addition, this is not what =93state=94 was originally intended for. If = the working group decides to mandate a CSRF parameter, it should = probably be a new parameter with a more appropriate name (e.g. =91csrf=92)= . By forcing clients to use =93state=94 for this purpose, developers = will need to use dynamic queries for other state information which = further reduces the security of the protocol (as the draft recommends = not using dynamic callback query components). Encoding both CSRF tokens = and other state information can be non-intuitive or complicated for some = developers/platforms.
 
 
 
In section 4, request options (e.g. 4.1.1) = featuring "state" should change from:
 
OPTIONAL. An opaque = value used by the client to maintain state between the request and = callback. The authorization server includes this value when redirecting = the user-agent back to the client.
 
to:
 
REQUIRED. An opaque = value used by the client to maintain state between the request and = callback. The authorization server includes this value when redirecting = the user-agent back to the client. The encoded value SHOULD enable the = client application to determine the user-context that was active at the = time of the  request (see section 10.12). The value MUST NOT be = guessable or predictable, and MUST be kept = confidential.
Making the parameter required without = making its usage required (I.e. "value SHOULD enable") accomplishes = nothing. Also, what does "MUST be kept confidential" mean? Confidential = from what? Why specify an "encoded = value"?
Section 10.12 Cross-Site Request = Forgery
Change to:
 
Cross-site request = forgery (CSRF) is a web-based attack whereby HTTP requests are = transmitted from the user-agent of an end-user the server trusts or = has authenticated. CSRF attacks enable the attacker to intermix the = attacker's security context with that of the resource owner = resulting in a compromise of either the resource server or of the client = application itself. In the OAuth context, such attacks allow an = attacker to inject their own authorization code or access token into a = client, which can result in the client using an access token = associated with the attacker's account rather than the victim's. = Depending on the nature of the client and the protected resources, = this can have undesirable and damaging effects.

In order to = prevent such attacks, the client application MUST encode a = non-guessable, confidential end-user artifact and submit as the = "state" parameter to authorization and access token requests to the = authorization server. The client MUST keep the state value in a = location accessible only by the client or the user-agent (i.e., = protected by same-origin policy), for example, using a DOM = variable, HTTP cookie, or HTML5 client-side storage.

The = authorization server includes the value of the "state" parameter when = redirecting the user-agent back to the client. Upon receiving a = redirect, the client application MUST confirm that returned value of = "state" corresponds to the state value of the user-agent's user session. = If the end-user session represents an authenticated user-identity, the = client MUST ensure that the user-identity has NOT = changed.
The above text uses 'user-context' and = this 'user-identity'. Neither term is = defined.



OAuth mailing list
OAuth@ietf.org
OAuth@ietf.org

Subject: Re: [OAUTH-WG] Auth Code Swap Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 16:52:46 -0000

--_000_CA7BCB9118B65eranhueniversecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Everyone yourself included indicated that the combination of MUST prevent C=
SRF and SHOULD use 'state' is the way to go. Yes, we still need to agree on=
 text but the normative language part is settled.

If you still insist on making 'state' required, I will defer to the chairs =
to decide how to move forward.

EHL

From: Anthony Nadalin >
Date: Thu, 25 Aug 2011 08:11:01 -0700
To: Eran Hammer-lahav >, To=
rsten Lodderstedt >
Cc: "OAuth WG (oauth@ietf.org)" >
Subject: RE: [OAUTH-WG] Auth Code Swap Attack

I have not seen any updated text, so I don=92t believe we have consensus. A=
lso we have a flawed protocol and we are not providing a fix, suggest that =
MUST be on the state also unless someone has a better fix

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, August 24, 2011 7:54 AM
To: Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

I believe we have full consensus on this approach.

EHL

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Tuesday, August 23, 2011 11:06 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

making CSRF prevention a MUST and recommending the state parameter as imple=
mentation pattern is ok with me.

regards,
Torsten.

Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav:
I light to the recent discussion, do you still feel that changing =91state=
=92 from optional to required is the best approach?

EHL

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, August 21, 2011 11:04 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

My intention is to require clients to implement CSRF prevention. I thought =
making the state parameter mandatory would be the straightforward way.

regards,
Torsten.

Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav:
I would like to hear from the other 3 authors of the proposed change about =
their reasons for changing the use of =91state=92 from recommended to requi=
red for CSRF prevention. It would also help moving this issue forward if th=
e 4 authors can provide answers or clarifications on the issues raised belo=
w.

Assuming we can count all 4 authors are in favor of making the change, I be=
lieve we have a tie (4:4) and therefore no consensus for making it (as of t=
his point). However, we did identify issues with the section=92s language a=
nd clarity which we should address either way.

To clarify =96 I am not proposing we close this issue just yet.

EHL

From:oauth-bounces@ietf.org [mailto:oauth-bo=
unces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

To demonstrate why making state required as proposed isn=92t very helpful, =
here is an incomplete list of other requirements needed to make an effectiv=
e CSRF:

* State value must not be empty (a common bug in many implementations using=
 simple value comparison).

* =91Non-guessable=92 isn=92t sufficient as most developers will simply use=
 a hash of the session cookie, with or without salt which isn=92t sufficien=
t. We use =93cannot be generated, modified, or guessed to produce valid val=
ues=94 elsewhere in the document, but this is much easier to get right for =
access tokens and refresh tokens than CSRF tokens which are often just some=
 algorithm on top of the session cookie.

* State CSRF value should be short-lived or based on a short-lived session =
cookie to prevent the use of a leaked state value in multiple attacks on th=
e same user session once the leak is no longer viable.

In addition, this is not what =93state=94 was originally intended for. If t=
he working group decides to mandate a CSRF parameter, it should probably be=
 a new parameter with a more appropriate name (e.g. =91csrf=92). By forcing=
 clients to use =93state=94 for this purpose, developers will need to use d=
ynamic queries for other state information which further reduces the securi=
ty of the protocol (as the draft recommends not using dynamic callback quer=
y components). Encoding both CSRF tokens and other state information can be=
 non-intuitive or complicated for some developers/platforms.

EHL




From: Eran Hammer-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

This is really just a flavor of CSRF attacks. I have no objections to bette=
r documenting it (though I feel the current text is already sufficient), bu=
t we can't realistically expect to identify and close every possible browse=
r-based attack. A new one is invented every other week.

The problem with this text is that developers who do no understand CSRF att=
acks are not likely to implement it correctly with this information. Those =
who understand it do not need the extra verbiage which is more confusing th=
an helpful.

As for the new requirements, they are insufficient to actually accomplish w=
hat the authors propose without additional requirements on state local stor=
age and verification to complete the flow. Also, the proposed text needs cl=
arifications as noted below.


From: Anthony Nadalin >
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" >
Subject: [OAUTH-WG] Auth Code Swap Attack



Recommended Changes to draft-ietf-oauth-v2

In section 4, request options (e.g. 4.1.1) featuring "state" should change =
from:

state
OPTIONAL. An opaque value used by the client to maintain state between the =
request and callback. The authorization server includes this value when red=
irecting the user-agent back to the client.

to:

state
REQUIRED. An opaque value used by the client to maintain state between the =
request and callback. The authorization server includes this value when red=
irecting the user-agent back to the client. The encoded value SHOULD enable=
 the client application to determine the user-context that was active at th=
e time of the  request (see section 10.12). The value MUST NOT be guessable=
 or predictable, and MUST be kept confidential.


Making the parameter required without making its usage required (I.e. "valu=
e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi=
dential" mean? Confidential from what? Why specify an "encoded value"?


Section 10.12 Cross-Site Request Forgery

Change to:

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques=
ts are transmitted from the user-agent of an end-user the server trusts or =
has authenticated. CSRF attacks enable the attacker to intermix the attacke=
r's security context with that of the resource owner resulting in a comprom=
ise of either the resource server or of the client application itself. In t=
he OAuth context, such attacks allow an attacker to inject their own author=
ization code or access token into a client, which can result in the client =
using an access token associated with the attacker's account rather than th=
e victim's. Depending on the nature of the client and the protected resourc=
es, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-=
guessable, confidential end-user artifact and submit as the "state" paramet=
er to authorization and access token requests to the authorization server. =
The client MUST keep the state value in a location accessible only by the c=
lient or the user-agent (i.e., protected by same-origin policy), for exampl=
e, using a DOM variable, HTTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parameter when r=
edirecting the user-agent back to the client. Upon receiving a redirect, th=
e client application MUST confirm that returned value of "state" correspond=
s to the state value of the user-agent's user session. If the end-user sess=
ion represents an authenticated user-identity, the client MUST ensure that =
the user-identity has NOT changed.


The above text uses 'user-context' and this 'user-identity'. Neither term i=
s defined.

EHL




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


--_000_CA7BCB9118B65eranhueniversecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



Everyone yourself included indi=
cated that the combination of MUST prevent CSRF and SHOULD use 'state' is t=
he way to go. Yes, we still need to agree on text but the normative languag=
e part is settled.

If you still insist on making '=
state' required, I will defer to the chairs to decide how to move forward.<=
/div>

EHL

From:  Anthony Nadalin <tonynad@microsoft.com>
Date:  Thu, 25 Aug 2011 08:11:01 -0700
To:  Eran Hammer-lahav <eran@hueniverse.com>, Torsten Lodderstedt <torsten@lodderstedt.net>
Cc:  "OAuth WG (oauth@ietf.org)" <oa=
uth@ietf.org>
Subject:  R=
E: [OAUTH-WG] Auth Code Swap Attack

I have not seen any updated text, so I do=
n=92t believe we have consensus. Also we have a flawed protocol and we are =
not providing a fix, suggest that MUST be on the state also unless someone =
has a better fix
 
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, August 24,=
 2011 7:54 AM
To: Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [=
OAUTH-WG] Auth Code Swap Attack
 
I believe we have full consensus on this approach.=

 =

EHL
 
From: Torsten Lodderstedt
[mailto:torsten@lodders=
tedt.net]
Sent: Tuesday, August 23, 2011 11:06 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap At=
tack
 
making CSRF prevention a MUST and recommendin=
g the state parameter as implementation pattern is ok with me.


regards,

Torsten.


Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav: 
I light to the recent discussion, =
do you still feel that changing =91state=92 from optional to required is th=
e best approach?
 
EHL
 
<=
p class=3D"MsoNormal">From: Torsten Lod=
derstedt [mailto:torsten@lodders=
tedt.net]

Sent: Sunday, August 21, 2011 11:04 AM
To: Eran Hammer=
-Lahav
Cc: OAuth WG (oauth@ietf=
.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
 
My intention is to require clients to implement CSRF preven=
tion. I thought making the state parameter mandatory would be the straightf=
orward way.


regards,

Torsten.


Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: 
I would like to hear from the othe=
r 3 authors of the proposed change about their reasons for changing the use=
 of =91state=92 from recommended to required for CSRF prevention. It would =
also help moving this issue
 forward if the 4 authors can provide answers or clarifications on the issu=
es raised below.
 
Assuming we can count all 4 authors are in favor of m=
aking the change, I believe we have a tie (4:4) and therefore no consensus =
for making it (as of this point). However, we did identify issues with the =
section=92s
 language and clarity which we should address either way.=

 =

To clarify =
=96 I am not proposing we close this issue just yet.
<=
p class=3D"MsoNormal"> 
EHL
 <=
o:p>
From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 20=
11 9:35 AM
To: OAuth WG (oauth@=
ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
 
To demonstrate why making=
 state required as proposed isn=92t very helpful, here is an incomplete lis=
t of other requirements needed to make an effective CSRF:=

 =

* State valu=
e must not be empty (a common bug in many implementations using simple valu=
e comparison).
 
* =91Non-guessable=92 isn=92t sufficient as most develo=
pers will simply use a hash of the session cookie, with or without salt whi=
ch isn=92t sufficient. We use =93cannot be generated, modified, or guessed =
to produce valid
 values=94 elsewhere in the document, but this is much easier to get right =
for access tokens and refresh tokens than CSRF tokens which are often just =
some algorithm on top of the session cookie.
 
* State CSRF value shoul=
d be short-lived or based on a short-lived session cookie to prevent the us=
e of a leaked state value in multiple attacks on the same user session once=
 the leak is no longer viable.
=
 
In addition, this is not what =93state=
=94 was originally intended for. If the working group decides to mandate a =
CSRF parameter, it should probably be a new parameter with a more appropria=
te name (e.g. =91csrf=92). By
 forcing clients to use =93state=94 for this purpose, developers will need =
to use dynamic queries for other state information which further reduces th=
e security of the protocol (as the draft recommends not using dynamic callb=
ack query components). Encoding both
 CSRF tokens and other state information can be non-intuitive or complicate=
d for some developers/platforms.
 
EHL
 
 
=

 
 
From: Eran Hammer-Lah=
av

Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nada=
lin; OAuth WG (oauth@ietf.org)
=
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
 
This is really just a flavor of CSRF =
attacks. I have no objections to better documenting it (though I feel the c=
urrent text is already sufficient), but we can't realistically expect to id=
entify and close every
 possible browser-based attack. A new one is invented every other week.
 
The problem with this text is that developers=
 who do no understand CSRF attacks are not likely to implement it correctly=
 with this information. Those who understand it do not need the extra verbi=
age which
 is more confusing than helpful.
 
As for =
the new requirements, they are insufficient to actually accomplish what the=
 authors propose without additional requirements on state local storage and=
 verification to complete the flow. Also, the proposed
 text needs clarifications as noted below.
=

 <=
/o:p>
 
From:=
 Anthony Nadalin <tonynad@m=
icrosoft.com>
Date: Fri, 12 Aug 2011 12:06:36 -0700
=
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack
 
&n=
bsp;
 
Recommended=
 Changes to draft-ietf-oauth-v2
 =

In section 4, r=
equest options (e.g. 4.1.1) featuring "state" should change from:=

 
state<=
/o:p>
OPTIONAL. An opaque value used by the client to maintain state bet=
ween the request and callback. The authorization server includes this value=
 when redirecting the user-agent back to the
 client.
 
to:
 
state
REQUIRED. An opaque value us=
ed by the client to maintain state between the request and callback. The au=
thorization server includes this value when redirecting the user-agent back=
 to the
 client. The encoded value SHOULD enable the client application to determin=
e the user-context that was active at the time of the  request (see se=
ction 10.12). The value MUST NOT be guessable or predictable, and MUST be k=
ept confidential.
 
=

 
Making the parameter required without making its u=
sage required (I.e. "value SHOULD enable") accomplishes nothing. =
Also, what does "MUST be kept confidential" mean? Confidential fr=
om what? Why specify an "encoded
 value"?
 
 
<=
p class=3D"MsoNormal">Section 10.12 Cross-Site R=
equest Forgery
 
Change to:=

 
Cross-site request forgery (CSRF) is =
a web-based attack whereby HTTP requests are transmitted from the user-agen=
t of an end-user the server trusts or has authenticated. CSRF attacks =
enable
 the attacker to intermix the attacker's security context with that of the&=
nbsp;resource owner resulting in a compromise of either the resource server=
 or of the client application itself. In the OAuth context, such attac=
ks allow an attacker to inject their own authorization
 code or access token into a client, which can result in the client using a=
n access token associated with the attacker's account rather than the =
victim's. Depending on the nature of the client and the protected reso=
urces, this can have undesirable and damaging
 effects.


In order to prevent such attacks, the client application MUST encode a non-=
guessable, confidential end-user artifact and submit as the "stat=
e" parameter to authorization and access token requests to the authori=
zation server. The client MUST keep the state value
 in a location accessible only by the client or the user-agent (i.e., =
protected by same-origin policy), for example, using a DOM variable, H=
TTP cookie, or HTML5 client-side storage.


The authorization server includes the value of the "state" parame=
ter when redirecting the user-agent back to the client. Upon receiving=
 a redirect, the client application MUST confirm that returned value of &qu=
ot;state" corresponds to the state value of the user-agent's
 user session. If the end-user session represents an authenticated user-ide=
ntity, the client MUST ensure that the user-identity has NOT changed.<=
/span>
 
 
The above text uses 'user-context' and this 'user-ide=
ntity'. Neither term is defined.
 
EHL



________________=
_______________________________
OAuth mailing list
OAuth@ietf.org=

ht=
tps://www.ietf.org/mailman/listinfo/oauth
 


--_000_CA7BCB9118B65eranhueniversecom_--

From tonynad@microsoft.com  Thu Aug 25 09:59:20 2011
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE8321F8B02 for ; Thu, 25 Aug 2011 09:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.466
X-Spam-Level: 
X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7unH7EURpNR9 for ; Thu, 25 Aug 2011 09:59:15 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 43B4521F8AFA for ; Thu, 25 Aug 2011 09:59:15 -0700 (PDT)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 25 Aug 2011 10:00:29 -0700
Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Aug 2011 10:00:28 -0700
Received: from mail80-ch1-R.bigfish.com (216.32.181.170) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Thu, 25 Aug 2011 17:00:18 +0000
Received: from mail80-ch1 (localhost.localdomain [127.0.0.1])	by mail80-ch1-R.bigfish.com (Postfix) with ESMTP id 477B51A01B0	for ; Thu, 25 Aug 2011 17:00:18 +0000 (UTC)
X-SpamScore: -20
X-BigFish: PS-20(zz9371Kc85fhzz1202h1082kzz8275ch1033IL8275bh8275dhz31h2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:207.46.4.139; KIP:(null); UIP:(null); IPV:SKI; H:SN2PRD0302HT001.namprd03.prod.outlook.com; R:internal; EFV:INT
Received-SPF: softfail (mail80-ch1: transitioning domain of microsoft.com does not designate 207.46.4.139 as permitted sender) client-ip=207.46.4.139; envelope-from=tonynad@microsoft.com; helo=SN2PRD0302HT001.namprd03.prod.outlook.com ; .outlook.com ; 
Received: from mail80-ch1 (localhost.localdomain [127.0.0.1]) by mail80-ch1 (MessageSwitch) id 1314291617406200_20773; Thu, 25 Aug 2011 17:00:17 +0000 (UTC)
Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244])	by mail80-ch1.bigfish.com (Postfix) with ESMTP id 5FEA01498050;	Thu, 25 Aug 2011 17:00:17 +0000 (UTC)
Received: from SN2PRD0302HT001.namprd03.prod.outlook.com (207.46.4.139) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 25 Aug 2011 17:00:15 +0000
Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.2.234]) by SN2PRD0302HT001.namprd03.prod.outlook.com ([10.27.50.84]) with mapi id 14.01.0225.064; Thu, 25 Aug 2011 17:00:15 +0000
From: Anthony Nadalin 
To: Eran Hammer-Lahav , Torsten Lodderstedt 
Thread-Topic: [OAUTH-WG] Auth Code Swap Attack
Thread-Index: AcxZImYoC2iZvOhxR/+zEXUukLHDogAF8TGAAIvI14AAgNyjAACwAFgAAAIJGIAAe8GCAAAScGQAADLTUAAAA6PagAAAL7bw
Date: Thu, 25 Aug 2011 17:00:13 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.28.29.69]
Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E7820SN2PRD0302MB137_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: SN2PRD0302HT001.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%HUENIVERSE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%LODDERSTEDT.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-OriginatorOrg: microsoft.com
X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com
Cc: "OAuth WG \(oauth@ietf.org\)" 
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 16:59:20 -0000

--_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E7820SN2PRD0302MB137_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

No that is not what I said; you seemed to have interpreted it that way,

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, August 25, 2011 9:54 AM
To: Anthony Nadalin; Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Everyone yourself included indicated that the combination of MUST prevent C=
SRF and SHOULD use 'state' is the way to go. Yes, we still need to agree on=
 text but the normative language part is settled.

If you still insist on making 'state' required, I will defer to the chairs =
to decide how to move forward.

EHL

From: Anthony Nadalin >
Date: Thu, 25 Aug 2011 08:11:01 -0700
To: Eran Hammer-lahav >, To=
rsten Lodderstedt >
Cc: "OAuth WG (oauth@ietf.org)" >
Subject: RE: [OAUTH-WG] Auth Code Swap Attack

I have not seen any updated text, so I don't believe we have consensus. Als=
o we have a flawed protocol and we are not providing a fix, suggest that MU=
ST be on the state also unless someone has a better fix

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, August 24, 2011 7:54 AM
To: Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

I believe we have full consensus on this approach.

EHL

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Tuesday, August 23, 2011 11:06 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

making CSRF prevention a MUST and recommending the state parameter as imple=
mentation pattern is ok with me.

regards,
Torsten.

Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav:
I light to the recent discussion, do you still feel that changing 'state' f=
rom optional to required is the best approach?

EHL

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, August 21, 2011 11:04 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

My intention is to require clients to implement CSRF prevention. I thought =
making the state parameter mandatory would be the straightforward way.

regards,
Torsten.

Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav:
I would like to hear from the other 3 authors of the proposed change about =
their reasons for changing the use of 'state' from recommended to required =
for CSRF prevention. It would also help moving this issue forward if the 4 =
authors can provide answers or clarifications on the issues raised below.

Assuming we can count all 4 authors are in favor of making the change, I be=
lieve we have a tie (4:4) and therefore no consensus for making it (as of t=
his point). However, we did identify issues with the section's language and=
 clarity which we should address either way.

To clarify - I am not proposing we close this issue just yet.

EHL

From:oauth-bounces@ietf.org [mailto:oauth-bo=
unces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

To demonstrate why making state required as proposed isn't very helpful, he=
re is an incomplete list of other requirements needed to make an effective =
CSRF:

* State value must not be empty (a common bug in many implementations using=
 simple value comparison).

* 'Non-guessable' isn't sufficient as most developers will simply use a has=
h of the session cookie, with or without salt which isn't sufficient. We us=
e "cannot be generated, modified, or guessed to produce valid values" elsew=
here in the document, but this is much easier to get right for access token=
s and refresh tokens than CSRF tokens which are often just some algorithm o=
n top of the session cookie.

* State CSRF value should be short-lived or based on a short-lived session =
cookie to prevent the use of a leaked state value in multiple attacks on th=
e same user session once the leak is no longer viable.

In addition, this is not what "state" was originally intended for. If the w=
orking group decides to mandate a CSRF parameter, it should probably be a n=
ew parameter with a more appropriate name (e.g. 'csrf'). By forcing clients=
 to use "state" for this purpose, developers will need to use dynamic queri=
es for other state information which further reduces the security of the pr=
otocol (as the draft recommends not using dynamic callback query components=
). Encoding both CSRF tokens and other state information can be non-intuiti=
ve or complicated for some developers/platforms.

EHL




From: Eran Hammer-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

This is really just a flavor of CSRF attacks. I have no objections to bette=
r documenting it (though I feel the current text is already sufficient), bu=
t we can't realistically expect to identify and close every possible browse=
r-based attack. A new one is invented every other week.

The problem with this text is that developers who do no understand CSRF att=
acks are not likely to implement it correctly with this information. Those =
who understand it do not need the extra verbiage which is more confusing th=
an helpful.

As for the new requirements, they are insufficient to actually accomplish w=
hat the authors propose without additional requirements on state local stor=
age and verification to complete the flow. Also, the proposed text needs cl=
arifications as noted below.


From: Anthony Nadalin >
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" >
Subject: [OAUTH-WG] Auth Code Swap Attack



Recommended Changes to draft-ietf-oauth-v2

In section 4, request options (e.g. 4.1.1) featuring "state" should change =
from:

state
OPTIONAL. An opaque value used by the client to maintain state between the =
request and callback. The authorization server includes this value when red=
irecting the user-agent back to the client.

to:

state
REQUIRED. An opaque value used by the client to maintain state between the =
request and callback. The authorization server includes this value when red=
irecting the user-agent back to the client. The encoded value SHOULD enable=
 the client application to determine the user-context that was active at th=
e time of the  request (see section 10.12). The value MUST NOT be guessable=
 or predictable, and MUST be kept confidential.


Making the parameter required without making its usage required (I.e. "valu=
e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi=
dential" mean? Confidential from what? Why specify an "encoded value"?


Section 10.12 Cross-Site Request Forgery

Change to:

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques=
ts are transmitted from the user-agent of an end-user the server trusts or =
has authenticated. CSRF attacks enable the attacker to intermix the attacke=
r's security context with that of the resource owner resulting in a comprom=
ise of either the resource server or of the client application itself. In t=
he OAuth context, such attacks allow an attacker to inject their own author=
ization code or access token into a client, which can result in the client =
using an access token associated with the attacker's account rather than th=
e victim's. Depending on the nature of the client and the protected resourc=
es, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-=
guessable, confidential end-user artifact and submit as the "state" paramet=
er to authorization and access token requests to the authorization server. =
The client MUST keep the state value in a location accessible only by the c=
lient or the user-agent (i.e., protected by same-origin policy), for exampl=
e, using a DOM variable, HTTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parameter when r=
edirecting the user-agent back to the client. Upon receiving a redirect, th=
e client application MUST confirm that returned value of "state" correspond=
s to the state value of the user-agent's user session. If the end-user sess=
ion represents an authenticated user-identity, the client MUST ensure that =
the user-identity has NOT changed.


The above text uses 'user-context' and this 'user-identity'. Neither term i=
s defined.

EHL





_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


--_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E7820SN2PRD0302MB137_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











No that is not what I =
said; you seemed to have interpreted it that way,



 






From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]


Sent: Thursday, August 25, 2011 9:54 AM

To: Anthony Nadalin; Torsten Lodderstedt

Cc: OAuth WG (oauth@ietf.org)

Subject: Re: [OAUTH-WG] Auth Code Swap Attack






 




Everyone yourself i=
ncluded indicated that the combination of MUST prevent CSRF and SHOULD use =
'state' is the way to go. Yes, we still need to agree on text but the norma=
tive language part is settled.






 






If you still insist=
 on making 'state' required, I will defer to the chairs to decide how to mo=
ve forward.






 






EHL






 






From: Anthony Nadalin <tonynad@microsoft.com>

Date: Thu, 25 Aug 2011 08:11:01 -0700

To: Eran Hammer-lahav <era=
n@hueniverse.com>, Torsten Lodderstedt <torsten@lodderstedt.net>

Cc: "OAuth WG (oauth@ietf.org=
)" <oauth@ietf.org>
Subject: RE: [OAUTH-WG] Auth Code Swap Attack






 










I have not seen any up=
dated text, so I don’t believe we have consensus. Also we have a flaw=
ed protocol and we are not providing a fix, suggest that MUST be on the sta=
te also unless someone has a better fix


 






From:
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Eran Hammer-Lahav

Sent: Wednesday, August 24, 2011 7:54 AM

To: Torsten Lodderstedt

Cc: OAuth WG (oauth@ietf.org)<=
br>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack






 


I believe we have full=
 consensus on this approach.


 


EHL<=
/p>

 








From: Torsten Lodderstedt
[mailto:torsten@lodders=
tedt.net]

Sent: Tuesday, August 23, 2011 11:06 PM

To: Eran Hammer-Lahav

Cc: OAuth WG (oauth@ietf.org)<=
br>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack






 


making CSRF prevention a MUST and recommending the s=
tate parameter as implementation pattern is ok with me.



regards,

Torsten.



Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav: 


I light to the recent =
discussion, do you still feel that changing ‘state’ from option=
al to required is the best approach?


 


EHL<=
/p>

 








From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]


Sent: Sunday, August 21, 2011 11:04 AM

To: Eran Hammer-Lahav

Cc: OAuth WG (oauth@ietf.org)<=
br>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack






 


My intention is to require clients to implement CSRF=
 prevention. I thought making the state parameter mandatory would be the st=
raightforward way.



regards,

Torsten.



Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: 


I would like to hear f=
rom the other 3 authors of the proposed change about their reasons for chan=
ging the use of ‘state’ from recommended to required for CSRF p=
revention. It would also help moving this issue
 forward if the 4 authors can provide answers or clarifications on the issu=
es raised below.


 


Assuming we can count =
all 4 authors are in favor of making the change, I believe we have a tie (4=
:4) and therefore no consensus for making it (as of this point). However, w=
e did identify issues with the section’s
 language and clarity which we should address either way.=



 


To clarify – I a=
m not proposing we close this issue just yet.


 


EHL<=
/p>

 








From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Eran Hammer-Lahav

Sent: Monday, August 15, 2011 9:35 AM

To: OAuth WG (oauth@ietf.org)<=
br>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack






 


To demonstrate why mak=
ing state required as proposed isn’t very helpful, here is an incompl=
ete list of other requirements needed to make an effective CSRF:


 


* State value must not=
 be empty (a common bug in many implementations using simple value comparis=
on).


 


* ‘Non-guessable=
’ isn’t sufficient as most developers will simply use a hash of=
 the session cookie, with or without salt which isn’t sufficient. We =
use “cannot be generated, modified, or guessed to produce valid
 values” elsewhere in the document, but this is much easier to get ri=
ght for access tokens and refresh tokens than CSRF tokens which are often j=
ust some algorithm on top of the session cookie.


 


* State CSRF value sho=
uld be short-lived or based on a short-lived session cookie to prevent the =
use of a leaked state value in multiple attacks on the same user session on=
ce the leak is no longer viable.


 


In addition, this is n=
ot what “state” was originally intended for. If the working gro=
up decides to mandate a CSRF parameter, it should probably be a new paramet=
er with a more appropriate name (e.g. ‘csrf’). By
 forcing clients to use “state” for this purpose, developers wi=
ll need to use dynamic queries for other state information which further re=
duces the security of the protocol (as the draft recommends not using dynam=
ic callback query components). Encoding both
 CSRF tokens and other state information can be non-intuitive or complicate=
d for some developers/platforms.


 


EHL<=
/p>

 


 


 


 








From: Eran Ham=
mer-Lahav


Sent: Friday, August 12, 2011 2:53 PM

To: Anthony Nadalin; OAuth WG (oau=
th@ietf.org)

Subject: Re: [OAUTH-WG] Auth Code Swap Attack






 




This is really just=
 a flavor of CSRF attacks. I have no objections to better documenting it (t=
hough I feel the current text is already sufficient), but we can't realisti=
cally expect to identify and close every
 possible browser-based attack. A new one is invented every other week.






 <=
/o:p>






The problem with th=
is text is that developers who do no understand CSRF attacks are not likely=
 to implement it correctly with this information. Those who understand it d=
o not need the extra verbiage which
 is more confusing than helpful.






 <=
/o:p>






As for the new requ=
irements, they are insufficient to actually accomplish what the authors pro=
pose without additional requirements on state local storage and verificatio=
n to complete the flow. Also, the proposed
 text needs clarifications as noted below.






 <=
/o:p>






 <=
/o:p>






From: Anthony Nadalin <tonynad@microsoft.com>

Date: Fri, 12 Aug 2011 12:06:36 -0700

To: "OAuth WG (oauth@ietf.org=
)" <oauth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack






 <=
/o:p>






 <=
/o:p>






 <=
/o:p>










Recommended Changes to draft-ietf-o=
auth-v2


=
 


In se=
ction 4, request options (e.g. 4.1.1) featuring "state" should ch=
ange from:


=
 


=
state


=
OPTIONAL. An opaque value used by the client to maintain state between the =
request and callback. The authorization server includes this value when red=
irecting the user-agent back to the
 client.


=
 


to:


=
 


=
state


=
REQUIRED. An opaque value used by the client to maintain state between the =
request and callback. The authorization server includes this value when red=
irecting the user-agent back to the
 client. The encoded value SHOULD enable the client application to determin=
e the user-context that was active at the time of the  request (see se=
ction 10.12). The value MUST NOT be guessable or predictable, and MUST be k=
ept confidential.


=
 










 <=
/o:p>






Making the paramete=
r required without making its usage required (I.e. "value SHOULD enabl=
e") accomplishes nothing. Also, what does "MUST be kept confident=
ial" mean? Confidential from what? Why specify an "encoded
 value"?






 <=
/o:p>






 <=
/o:p>










Secti=
on 10.12 Cross-Site Request Forgery


=
 


Chang=
e to:


=
 


=
Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques=
ts are transmitted from the user-agent of an end-user the server trust=
s or has authenticated. CSRF attacks enable
 the attacker to intermix the attacker's security context with that of the&=
nbsp;resource owner resulting in a compromise of either the resource server=
 or of the client application itself. In the OAuth context, such attac=
ks allow an attacker to inject their own authorization
 code or access token into a client, which can result in the client using a=
n access token associated with the attacker's account rather than the =
victim's. Depending on the nature of the client and the protected reso=
urces, this can have undesirable and damaging
 effects.



In order to prevent such attacks, the client application MUST encode a non-=
guessable, confidential end-user artifact and submit as the "stat=
e" parameter to authorization and access token requests to the authori=
zation server. The client MUST keep the state value
 in a location accessible only by the client or the user-agent (i.e., =
protected by same-origin policy), for example, using a DOM variable, H=
TTP cookie, or HTML5 client-side storage.



The authorization server includes the value of the "state" parame=
ter when redirecting the user-agent back to the client. Upon receiving=
 a redirect, the client application MUST confirm that returned value of &qu=
ot;state" corresponds to the state value of the user-agent's
 user session. If the end-user session represents an authenticated user-ide=
ntity, the client MUST ensure that the user-identity has NOT changed.<=
/span>


 










 <=
/o:p>






The above text uses=
 'user-context' and this 'user-identity'. Neither term is defined.






 <=
/o:p>






EHL



















_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth




 














--_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E7820SN2PRD0302MB137_--

From eran@hueniverse.com  Thu Aug 25 10:01:23 2011
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEA521F8AD9 for ; Thu, 25 Aug 2011 10:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level: 
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3jwN-VSc6CK for ; Thu, 25 Aug 2011 10:01:21 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 9305921F8ACE for ; Thu, 25 Aug 2011 10:01:21 -0700 (PDT)
Received: (qmail 14297 invoked from network); 25 Aug 2011 17:02:35 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Aug 2011 17:02:34 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 25 Aug 2011 10:02:18 -0700
From: Eran Hammer-Lahav 
To: Phil Hunt , Anthony Nadalin 
Date: Thu, 25 Aug 2011 10:02:15 -0700
Thread-Topic: [OAUTH-WG] Auth Code Swap Attack
Thread-Index: AcxjSL7idmsuB5kSSLOdueEHmqCwDw==
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CA7BCC2918B6Aeranhueniversecom_"
MIME-Version: 1.0
Cc: "OAuth WG \(oauth@ietf.org\)" 
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Aug 2011 17:01:23 -0000

--_000_CA7BCC2918B6Aeranhueniversecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

We already have one recommended implementation with 'state'. It is clearly =
described in the security section which is the right place to define it. I =
will further emphasize it in the 'state' parameter definition as previously=
 proposed.

BTW, as stated repeatedly before, making the parameter required does not pr=
ovide *ANY* CSRF protection. It just forces it to be included. To guarantee=
 CSRF protection, you need a LOT more normative language in how to bind the=
 state value with some form of session information on the user-agent =96 wh=
ich is clearly outside the scope of this working group. Requiring CSRF prot=
ection accomplishes that, and if a developer doesn't know how to do that, u=
nfortunately, we will not be able to help within the scope of this document=
 =96 which doesn't exclude it from being discussed in details in the thread=
 model document as advised by the chairs.

CSRF is a serious attack vector, but our correct course is to highlight it,=
 suggest a path, and leave it to developers to implement proper security li=
ke the other handful of possible attacks listed.

EHL

From: Phil Hunt >
Date: Thu, 25 Aug 2011 09:25:30 -0700
To: Anthony Nadalin >
Cc: Eran Hammer-lahav >, To=
rsten Lodderstedt >=
, "OAuth WG (oauth@ietf.org)" >
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

I agree. I think at least one implementation must be included in the spec. =
 However, I'd like to see it left that more methods could be implemented in=
 the future.

I can live with "SHOULD" given the definition in 2119.  Or phrased "MUST im=
plement at least the following method..." for stronger language.

Tony is correct, I think it is a serious issue given the dependence on gran=
ts being passed by URLs through redirects.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2011-08-25, at 8:11 AM, Anthony Nadalin wrote:

I have not seen any updated text, so I don=92t believe we have consensus. A=
lso we have a flawed protocol and we are not providing a fix, suggest that =
MUST be on the state also unless someone has a better fix

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, August 24, 2011 7:54 AM
To: Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

I believe we have full consensus on this approach.

EHL

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Tuesday, August 23, 2011 11:06 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

making CSRF prevention a MUST and recommending the state parameter as imple=
mentation pattern is ok with me.

regards,
Torsten.

Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav:
I light to the recent discussion, do you still feel that changing =91state=
=92 from optional to required is the best approach?

EHL

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, August 21, 2011 11:04 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

My intention is to require clients to implement CSRF prevention. I thought =
making the state parameter mandatory would be the straightforward way.

regards,
Torsten.

Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav:
I would like to hear from the other 3 authors of the proposed change about =
their reasons for changing the use of =91state=92 from recommended to requi=
red for CSRF prevention. It would also help moving this issue forward if th=
e 4 authors can provide answers or clarifications on the issues raised belo=
w.

Assuming we can count all 4 authors are in favor of making the change, I be=
lieve we have a tie (4:4) and therefore no consensus for making it (as of t=
his point). However, we did identify issues with the section=92s language a=
nd clarity which we should address either way.

To clarify =96 I am not proposing we close this issue just yet.

EHL

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

To demonstrate why making state required as proposed isn=92t very helpful, =
here is an incomplete list of other requirements needed to make an effectiv=
e CSRF:

* State value must not be empty (a common bug in many implementations using=
 simple value comparison).

* =91Non-guessable=92 isn=92t sufficient as most developers will simply use=
 a hash of the session cookie, with or without salt which isn=92t sufficien=
t. We use =93cannot be generated, modified, or guessed to produce valid val=
ues=94 elsewhere in the document, but this is much easier to get right for =
access tokens and refresh tokens than CSRF tokens which are often just some=
 algorithm on top of the session cookie.

* State CSRF value should be short-lived or based on a short-lived session =
cookie to prevent the use of a leaked state value in multiple attacks on th=
e same user session once the leak is no longer viable.

In addition, this is not what =93state=94 was originally intended for. If t=
he working group decides to mandate a CSRF parameter, it should probably be=
 a new parameter with a more appropriate name (e.g. =91csrf=92). By forcing=
 clients to use =93state=94 for this purpose, developers will need to use d=
ynamic queries for other state information which further reduces the securi=
ty of the protocol (as the draft recommends not using dynamic callback quer=
y components). Encoding both CSRF tokens and other state information can be=
 non-intuitive or complicated for some developers/platforms.

EHL




From: Eran Hammer-Lahav
Sent: Friday, August 12, 2011 2:53 PM
To: Anthony Nadalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

This is really just a flavor of CSRF attacks. I have no objections to bette=
r documenting it (though I feel the current text is already sufficient), bu=
t we can't realistically expect to identify and close every possible browse=
r-based attack. A new one is invented every other week.

The problem with this text is that developers who do no understand CSRF att=
acks are not likely to implement it correctly with this information. Those =
who understand it do not need the extra verbiage which is more confusing th=
an helpful.

As for the new requirements, they are insufficient to actually accomplish w=
hat the authors propose without additional requirements on state local stor=
age and verification to complete the flow. Also, the proposed text needs cl=
arifications as noted below.


From: Anthony Nadalin >
Date: Fri, 12 Aug 2011 12:06:36 -0700
To: "OAuth WG (oauth@ietf.org)" >
Subject: [OAUTH-WG] Auth Code Swap Attack



Recommended Changes to draft-ietf-oauth-v2

In section 4, request options (e.g. 4.1.1) featuring "state" should change =
from:

state
OPTIONAL. An opaque value used by the client to maintain state between the =
request and callback. The authorization server includes this value when red=
irecting the user-agent back to the client.

to:

state
REQUIRED. An opaque value used by the client to maintain state between the =
request and callback. The authorization server includes this value when red=
irecting the user-agent back to the client. The encoded value SHOULD enable=
 the client application to determine the user-context that was active at th=
e time of the  request (see section 10.12). The value MUST NOT be guessable=
 or predictable, and MUST be kept confidential.


Making the parameter required without making its usage required (I.e. "valu=
e SHOULD enable") accomplishes nothing. Also, what does "MUST be kept confi=
dential" mean? Confidential from what? Why specify an "encoded value"?


Section 10.12 Cross-Site Request Forgery

Change to:

Cross-site request forgery (CSRF) is a web-based attack whereby HTTP reques=
ts are transmitted from the user-agent of an end-user the server trusts or =
has authenticated. CSRF attacks enable the attacker to intermix the attacke=
r's security context with that of the resource owner resulting in a comprom=
ise of either the resource server or of the client application itself. In t=
he OAuth context, such attacks allow an attacker to inject their own author=
ization code or access token into a client, which can result in the client =
using an access token associated with the attacker's account rather than th=
e victim's. Depending on the nature of the client and the protected resourc=
es, this can have undesirable and damaging effects.

In order to prevent such attacks, the client application MUST encode a non-=
guessable, confidential end-user artifact and submit as the "state" paramet=
er to authorization and access token requests to the authorization server. =
The client MUST keep the state value in a location accessible only by the c=
lient or the user-agent (i.e., protected by same-origin policy), for exampl=
e, using a DOM variable, HTTP cookie, or HTML5 client-side storage.

The authorization server includes the value of the "state" parameter when r=
edirecting the user-agent back to the client. Upon receiving a redirect, th=
e client application MUST confirm that returned value of "state" correspond=
s to the state value of the user-agent's user session. If the end-user sess=
ion represents an authenticated user-identity, the client MUST ensure that =
the user-identity has NOT changed.


The above text uses 'user-context' and this 'user-identity'. Neither term i=
s defined.

EHL




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--_000_CA7BCC2918B6Aeranhueniversecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



We already have one recommended=
 implementation with 'state'. It is clearly described in the security secti=
on which is the right place to define it. I will further emphasize it in th=
e 'state' parameter definition as previously proposed.

=

BTW, as stated repeatedly before, making the parameter required does n=
ot provide *ANY* CSRF protection. It just forces it to be included. To guar=
antee CSRF protection, you need a LOT more normative language in how to bin=
d the state value with some form of session information on the user-agent =
=96 which is clearly outside the scope of this working group. Requiring CSR=
F protection accomplishes that, and if a developer doesn't know how to do t=
hat, unfortunately, we will not be able to help within the scope of this do=
cument =96 which doesn't exclude it from being discussed in details in the =
thread model document as advised by the chairs.

CS=
RF is a serious attack vector, but our correct course is to highlight it, s=
uggest a path, and leave it to developers to implement proper security like=
 the other handful of possible attacks listed.

EHL=


From:  Ph=
il Hunt <phil.hunt@oracle.com>
Date:  Thu, 25 Aug 2011 09=
:25:30 -0700
To:  Anthony Nadali=
n <tonynad@microsoft.com>=
;
Cc:  Eran Hammer-lahav <eran@hueniverse.com>, Torsten Lo=
dderstedt <torsten@loddersted=
t.net>, "OAuth WG (oauth@ietf=
.org)" <oauth@ietf.org>=
;
Subject:  Re: [OAUTH-WG] Auth =
Code Swap Attack

I agree. I think at lea=
st one implementation must be included in the spec.  However, I'd like=
 to see it left that more methods could be implemented in the future.  =
;

I can live with "SHOULD" given the definitio=
n in 2119.  Or phrased "MUST implement at least the following met=
hod..." for stronger language.

Tony is correc=
t, I think it is a serious issue given the dependence on grants being passe=
d by URLs through redirects.


On 2011-08-25, at 8:11 AM, Anthony Nadalin wrote:

I have not seen any updated text, so I don=92t believe we have =
consensus. Also we have a flawed protocol and we are not providing a fix, s=
uggest that MUST be on the state also unless someone has a better fix<=
/o:p>
=
 
From:<=
span style=3D"font-size: 10pt; color: windowtext; font-family: Tahoma, sans=
-serif; "> oauth-bounces@ietf.org =
[mailto:oauth-bounces@ietf=
.org] On Behalf Of=
 Eran Hammer-LahavSent: Wednesday, =
August 24, 2011 7:54 AM
To:=
 Torsten Lodderstedt
Cc: OAuth WG (oauth@ietf.org)
Subjec=
t: Re: [OAUTH-WG] Aut=
h Code Swap Attack
 =

I believe w=
e have full consensus on this approach.
=
 
EHL
 
From: Torsten Lodderstedt [mailto:tor=
sten@lodderstedt.net] 
Sent: Tuesday=
, August 23, 2011 11:06 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subje=
ct: Re: [OAUTH-WG] Au=
th Code Swap Attack
 =
;
making CSRF prevention a MUST and recommending the s=
tate parameter as implementation pattern is ok with me.

regards,
=
Torsten.

Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav:<=
/div>
I light to the rec=
ent discussion, do you still feel that changing =91state=92 from optional t=
o required is the best approach?
 
=
EHL
 
=

From: Torsten Lodderstedt [mai=
lto:torsten@lodderstedt.net] =
;
Sent: =
Sunday, August 21, 2011 11:04 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-=
WG] Auth Code Swap Attack
&nbs=
p;
My intention is to require clients to implemen=
t CSRF prevention. I thought making the state parameter mandatory would be =
the straightforward way.

regards,
Torsten.

Am 18.08.2011 0=
8:04, schrieb Eran Hammer-Lahav:
I would like to hear from the other 3 authors of =
the proposed change about their reasons for changing the use of =91state=92=
 from recommended to required for CSRF prevention. It would also help movin=
g this issue forward if the 4 authors can provide answers or clarifications=
 on the issues raised below.
 
Assuming we can count all 4 authors a=
re in favor of making the change, I believe we have a tie (4:4) and therefo=
re no consensus for making it (as of this point). However, we did identify =
issues with the section=92s language and clarity which we should address ei=
ther way.
 
To clarify =96 I am not proposing we close this issue just=
 yet.
 
EHL
 
From: oauth-bounces@ie=
tf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =
Eran Hammer-Lahav
Sent: Monday, August 15, 2011 9:35 AM
To: OAuth WG (oauth@ietf.or=
g)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
 
To demonstrate why making state required as proposed isn=92t very h=
elpful, here is an incomplete list of other requirements needed to make an =
effective CSRF:
 
* State value must not be empty (a common bug in man=
y implementations using simple value comparison).
 <=
/div>
* =91Non-guessable=
=92 isn=92t sufficient as most developers will simply use a hash of the ses=
sion cookie, with or without salt which isn=92t sufficient. We use =93canno=
t be generated, modified, or guessed to produce valid values=94 elsewhere i=
n the document, but this is much easier to get right for access tokens and =
refresh tokens than CSRF tokens which are often just some algorithm on top =
of the session cookie.
 
* State CSRF value should be short-lived or =
based on a short-lived session cookie to prevent the use of a leaked state =
value in multiple attacks on the same user session once the leak is no long=
er viable.
 
In addition, this is not what =93state=94 was originally =
intended for. If the working group decides to mandate a CSRF parameter, it =
should probably be a new parameter with a more appropriate name (e.g. =91cs=
rf=92). By forcing clients to use =93state=94 for this purpose, developers =
will need to use dynamic queries for other state information which further =
reduces the security of the protocol (as the draft recommends not using dyn=
amic callback query components). Encoding both CSRF tokens and other state =
information can be non-intuitive or complicated for some developers/platfor=
ms.
 
EHL
 
 
 
 
From: Eran Hammer-Lah=
av 
Sent: Friday, August 12, 2011 2:53 P=
M
To: Anthony N=
adalin; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Auth Code Swap At=
tack
 
This is really just a flav=
or of CSRF attacks. I have no objections to better documenting it (though I=
 feel the current text is already sufficient), but we can't realistically e=
xpect to identify and close every possible browser-based attack. A new one =
is invented every other week.
=
 
The problem with this text =
is that developers who do no understand CSRF attacks are not likely to impl=
ement it correctly with this information. Those who understand it do not ne=
ed the extra verbiage which is more confusing than helpful.
 
=
 
 
From: =
Anthony Nadalin <tonynad@microsoft.com&=
gt;
Date: Fri, =
12 Aug 2011 12:06:36 -0700
To:&=
nbsp;"OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: [OAUTH-WG] Auth Code Swap Attack
=

 =

 =

 
Recommended Changes to draft-iet=
f-oauth-v2
 
In section 4, request options (e.g. 4.1.1) featuring &q=
uot;state" should change from:
 <=
/o:p>
state
OPTIONAL. An opaque value used by the client to maintai=
n state between the request and callback. The authorization server includes=
 this value when redirecting the user-agent back to the client.=

=
to:
 
state
REQUIRED. An opaqu=
e value used by the client to maintain state between the request and callba=
ck. The authorization server includes this value when redirecting the user-=
agent back to the client. The encoded value SHOULD enable the client applic=
ation to determine the user-context that was active at the time of the &nbs=
p;request (see section 10.12). The value MUST NOT be guessable or predictab=
le, and MUST be kept confidential.
 
 
Making the parameter required without making its usage requ=
ired (I.e. "value SHOULD enable") accomplishes nothing. Also, wha=
t does "MUST be kept confidential" mean? Confidential from what? =
Why specify an "encoded value"?
 
 
Section 10.12 Cross-Site=
 Request Forgery
 
Change to:
 
Cross-site request forgery (CSRF) is a web-based attack whereby HTTP r=
equests are transmitted from the user-agent of an end-user the server =
trusts or has authenticated. CSRF attacks enable the attacker to intermix t=
he attacker's security context with that of the resource owner resulti=
ng in a compromise of either the resource server or of the client applicati=
on itself. In the OAuth context, such attacks allow an attacker to inj=
ect their own authorization code or access token into a client, which can r=
esult in the client using an access token associated with the attacker=
's account rather than the victim's. Depending on the nature of the client =
and the protected resources, this can have undesirable and damaging ef=
fects.

In order to prevent such attacks, the client application MUST=
 encode a non-guessable, confidential end-user artifact and submit as =
the "state" parameter to authorization and access token requests =
to the authorization server. The client MUST keep the state value in a=
 location accessible only by the client or the user-agent (i.e., protected =
by same-origin policy), for example, using a DOM variable, HTTP cookie=
, or HTML5 client-side storage.

The authorization server includes th=
e value of the "state" parameter when redirecting the user-agent =
back to the client. Upon receiving a redirect, the client application =
MUST confirm that returned value of "state" corresponds to the st=
ate value of the user-agent's user session. If the end-user session represe=
nts an authenticated user-identity, the client MUST ensure that the user-id=
entity has NOT changed.
 
 
The above text uses 'user-context' and this 'user-=
identity'. Neither term is defined.
 
EHL<=
/div>



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org=
/mailman/listinfo/oauth
 =

_______________________________________________OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--_000_CA7BCC2918B6Aeranhueniversecom_-- From bcampbell@pingidentity.com Fri Aug 26 09:08:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7384E21F8C62 for ; Fri, 26 Aug 2011 09:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.362 X-Spam-Level: X-Spam-Status: No, score=-4.362 tagged_above=-999 required=5 tests=[AWL=-1.585, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rQQ6F3lVkQH for ; Fri, 26 Aug 2011 09:08:32 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4137721F8C15 for ; Fri, 26 Aug 2011 09:08:31 -0700 (PDT) Received: from mail-qy0-f174.google.com ([209.85.216.174]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTlfFRQSIuSpnUIX3GCoAQCpCjPplGR2a@postini.com; Fri, 26 Aug 2011 09:09:49 PDT Received: by mail-qy0-f174.google.com with SMTP id 38so547996qyk.5 for ; Fri, 26 Aug 2011 09:09:41 -0700 (PDT) Received: by 10.229.34.77 with SMTP id k13mr1709738qcd.214.1314374980200; Fri, 26 Aug 2011 09:09:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.53.207 with HTTP; Fri, 26 Aug 2011 09:09:10 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 26 Aug 2011 10:09:10 -0600 Message-ID: To: "Engler, Michael" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Doersam, Joachim" , oauth Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-saml2-bearer X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 16:08:33 -0000 Hi Michael, I apologize for being so slow in responding to this.=A0 I did not receive the first message and haven't had a chance to respond to this direct email as I've been very busy trying to get a product release out the door. I attempt to answer the questions inline below. I'm also cc'ing the OAUTH WG mailing list as these are questions that others might have too. Note there are also questions about draft-ietf-oauth-assertions-00 too. Thanks for the review and feedback. Hopefully I can address your questions= . Brian On Mon, Aug 15, 2011 at 5:50 AM, Engler, Michael w= rote: > > Hi Brian, > > possibly the previous mail was lost somewhere in the IETF mailinglists = =85 thus I send here again directly. I apologize if you now received it twi= ce =85 J > > Greetings, > Michael > > > _____________________________________________ > From: Engler, Michael > Sent: Mittwoch, 10. August 2011 18:11 > To: 'draft-ietf-oauth-saml2-bearer@tools.ietf.org' > Cc: Doersam, Joachim > Subject: Mail regarding draft-ietf-oauth-saml2-bearer > > > Hi Brian, > > I are currently reading your latest draft on SAML bearer assertion usage = in OAuth 2. Some parts are currently unclear, and it would be great if you = could bring light into the dark J =85 > > In the document I read the following: =93If the Assertion was issued with= the intention that the presenter act autonomously on behalf of the subject= , an SHOULD NOT be included.=A0 The presenter SHOULD be id= entified in the or similar element, the ele= ment, or by other available means like [OASIS.saml-deleg-cs].=94 > > > What does it actually mean if the presenter (=3D OAuth client) acts auton= omously but still on behalf of the subject? Isn=92t this a contradiction? Perhaps 'autonomously' isn't the best word there and I'm open to suggestions on an alternative. What I'm trying to do is differentiate between two general cases: 1) the case where the user/resource owner is present to the client in some way and the client has authenticated the resource owner or is sufficiently confident in the authentication event and 2) the case where the client is doing something on behalf of a resource owner but the resource owner isn't present to the client and hasn't directly authenticated with the client. An example of the former case might be where the client is some web application that the resource owner has logged onto and is using at the time of this transaction. The later case might be where the client is some cron job or something that runs nightly and does something on the user or users behalf but without them being around for the transaction. > Can you elaborate more on this point why the authentication statement sho= uld be left out here? Related to what I said above, there are cases where the resource owner hasn't authenticated with the client (or some STS) and so it seems like it makes sense to say that no claim should be made in the assertion about any type of authentication. In that case, it's really just a claim about some identity about whom this access token is being requested. > Should the SAML subject reference the resource owner, or the OAuth client= in that case? My intent is that the subject (or the subject and some of the attributes) should reference the resource owner while the delegation to the client (though it's kind of implied) can be expressed through other semantics in the assertion (that's what the second sentence from the piece of the spec you quoted is intended to cover). > > In section 3.1 you write that =93If present, the authorization server MUS= T also validate the client credentials.=93 =85 > > > What is the syntax for adding the client credentials to the assertion req= uest in case of the SAML bearer token? Do you refer to the separate asserti= on covering the client as SAML subject =85 or are there yet another type of= client credentials to take into account? > The means of client authentication is totally independent from the grant type being presented (true for SAML grant type but also in general). That statement is just intended to ensure that client credentials aren't ignored, if they are there. > > I would assume that the client id needs to be transferred as part of the = access token request. In draft-ietf-oauth-assertions-00 you write the follo= wing: > The following non-normative example demonstrates an assertion being > used as an authorization grant. (line breaks are for display purposes > only): > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > client_id=3Ds6BhdRkqt3& > grant_type=3Durn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion& > assertion=3DPHNhbWxwOl...[omitted for brevity]...ZT4 > > Why do you assume it is sufficient that the client_id is not contained wi= thin the assertion but is =93solely=94 added to the request? In our discuss= ions so far, we assumed that the client id could be transferred as an attri= bute statement within the SAML assertion. This would prevent tampering with= the client id subsequently. What are your thoughts on this? I don't necessarily assume that in all cases. In some the client_id is little more than an identifier (not authentication) of the client - a hint really. Other cases might require that the client authenticate and that can be done any number of ways. I also think that client_id should be made optional in the next rev of draft-ietf-oauth-assertion (it is currently required but that, I think, is an artifact of trying to stay consistent with a draft of the core spec that is now obsolete). > Greetings, > Michael > > Dr. Michael Engler > Security & Identity Management > TIP Core Security, Connectivity, Integration > SAP AG > > Dietmar-Hopp-Allee 16 > 69190 Walldorf > T=A0=A0 +49/6227/7-47599 > F=A0=A0 +49/6227/78-46187 > E=A0=A0 michael.engler@sap.com > > Sitz der Gesellschaft/Registered Office: Walldorf, Germany > Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO), L=E9o Apo= theker (stellvertretender Sprecher/Deputy CEO), Werner Brandt, Claus Heinri= ch, Gerhard Oswald, Peter Zencke > Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board: = Hasso Plattner > Registergericht/Commercial Register Mannheim No HRB 350269 > > Diese E-Mail kann Betriebs- oder Gesch=E4ftsgeheimnisse oder sonstige ver= trauliche Informationen enthalten. Sollten Sie diese E-Mail irrt=FCmlich er= halten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf=E4lti= gung oder Weitergabe der E-Mail ausdr=FCcklich untersagt. > Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. V= ielen Dank. > > This e-mail may contain trade secrets or privileged, undisclosed, or othe= rwise confidential information. If you have received this e-mail in error, = you are hereby notified that any review, copying, or distribution of it is = strictly prohibited. Please inform us immediately and destroy the original = transmittal. Thank you for your cooperation. > > > > > > > > From bcampbell@pingidentity.com Fri Aug 26 11:24:09 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8DA21F8C39 for ; Fri, 26 Aug 2011 11:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTTR0gMgXEDY for ; Fri, 26 Aug 2011 11:24:08 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F121F8B5E for ; Fri, 26 Aug 2011 11:24:06 -0700 (PDT) Received: from mail-qw0-f46.google.com ([209.85.216.46]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKTlflEnU9uyCmhG5dShSavKqiIU4+GtKT@postini.com; Fri, 26 Aug 2011 11:25:24 PDT Received: by mail-qw0-f46.google.com with SMTP id 3so3042537qwk.33 for ; Fri, 26 Aug 2011 11:25:22 -0700 (PDT) Received: by 10.229.26.3 with SMTP id b3mr1869808qcc.290.1314383122071; Fri, 26 Aug 2011 11:25:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.53.207 with HTTP; Fri, 26 Aug 2011 11:24:52 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739434A80B5D4@TK5EX14MBXC201.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739434A80B5D4@TK5EX14MBXC201.redmond.corp.microsoft.com> From: Brian Campbell Date: Fri, 26 Aug 2011 12:24:52 -0600 Message-ID: To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Comments on Assertions draft 00 by Yaron Goland X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 18:24:09 -0000 Couple comments on the comments inline: On Wed, Aug 10, 2011 at 3:39 PM, Mike Jones w= rote: > > 4.1. Using Assertions for Client Authentication:=A0 Comment on =93client_= id=94: > =93It seems like a bad idea to have the client_id outside of the assertio= n. > It=92s either redundant or insecure.=94 > I tend to agree with this. Now that treatment of client_id seems to have stabilized in the core spec, this draft is probable due for some reconciliatory changes around the parameter. > > 7.=A0 Error Responses:=A0 Comment on =93Audience validation failed=94: = =93Isn=92t > returning this kind of information just helping an attacker to hone their > attack by trying various values and seeing what errors they get? I=92m no= t > sure how serious this threat is though. But I get nervous any time we lea= k > data about security validation failures.=94 Trying to walk the line between security and having useful feedback available for troubleshooting during the early stages of deployments. Given that there's a signature over the assertion, providing details about other semantic validation issues doesn't seem like an issue to me. But I know that such information disclosure is usually considered a no no in security related contexts. Anyway, the error_description parameter is optional so individual implementation/deployments can make their own decisions about what, if anything, to put there and/or when to put info there. From justin@affinix.com Fri Aug 26 16:03:41 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F280A21F8B7D for ; Fri, 26 Aug 2011 16:03:41 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+p+9bU675xD for ; Fri, 26 Aug 2011 16:03:41 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 438FE21F8B0B for ; Fri, 26 Aug 2011 16:03:41 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 90F5110AFB1 for ; Fri, 26 Aug 2011 16:04:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=affinix.com; h=from:to:subject :date:mime-version:content-type:content-transfer-encoding: message-id; q=dns; s=affinix.com; b=rTHrX/y6ijzllZ+Vi/j8YpkNdR9k DwaPbDR3CVOxs/SxsfhThKM57wcnaj8nE+qOBBufsjHAwcJhhNjK4uI7jYRQV2t9 Rywts5nY0PSTBEIbTNFG3Sk6gfpArUUaLCvQoPZtD5cZ5xjzCK+kP/tYs1WnUMLJ Oiu+MEe4PiW+FF8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=affinix.com; h=from:to :subject:date:mime-version:content-type :content-transfer-encoding:message-id; s=affinix.com; bh=gVchGwH mjQMczHNb4nUKupfajV4=; b=g+Qcm1cOThMFBrmcmw8l7bpXfnfbJ8MyFT4SvwW k8NPqsZlEZLTHbuWjt3ot3ypDZx4ZSbg3D3nmamVTkS76DPxYDDhNI9UNDTHRKAL +Q1Bk//GUigeUb8u5tTw4HBSM0blMoxNuZ6Q2PPuk/iFxbsL6VkNRemu3WqtCJRN p+1E= Received: from purelace.localnet (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: justin@affinix.com) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 742AD10AFAD for ; Fri, 26 Aug 2011 16:04:58 -0700 (PDT) From: Justin Karneges To: oauth@ietf.org Date: Fri, 26 Aug 2011 16:04:57 -0700 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.6.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201108261604.57643.justin@affinix.com> Subject: [OAUTH-WG] SSO scenario X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 23:03:42 -0000 Hi folks, I currently use a proprietary token approach to provide authentication to a browser widget, and I wonder if OAuth could be used to replace it. Here's how the system currently works: - website supports authenticated users (happens via username/password form) - website and widget provider have a shared secret - the website serves a page to the browser, containing an embed of a remote widget as well as a token that asserts the currently logged in user. the widget takes this token and performs an ajax call to the widget provider server. behold, the user is now logged in to the widget. In trying to organize this into OAuth terms and roles, here is what I come up with: - resource owner: the user - resource server: widget provider (where the resource is generically "the ability to utilize the widget") - client: the webpage running in the browser - authorization server: the website The website essentially serves up the client application and token in one shot, so the client never has to explicitly ask for a token. However, the client would then take that token and use it to access a service. The website and widget provider would share key material such that token validation is possible, but it's important to note that the two services are not owned and operated by the same people. Does this seem right? Normally when I think of OAuth, I think of a user giving a third-party service access to his personal stuff, but in the above flow I'm proposing that OAuth be used so that the user gains access to his own stuff. In fact, there would be no way to access his stuff other than this approach, so it's not just about optional third-party access. It's the direct and only access. Would love confirmation that OAuth is appropriate for my needs, and if I have the roles right in that case. Thanks, Justin From torsten@lodderstedt.net Sun Aug 28 10:14:10 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCEB21F85BB for ; Sun, 28 Aug 2011 10:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nzJ84uC3S7k for ; Sun, 28 Aug 2011 10:14:10 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by ietfa.amsl.com (Postfix) with ESMTP id CE7A921F861A for ; Sun, 28 Aug 2011 10:14:09 -0700 (PDT) Received: from [79.253.27.149] (helo=[192.168.71.26]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1QxixD-0002bp-TN; Sun, 28 Aug 2011 19:15:27 +0200 Message-ID: <4E5A77B6.1030205@lodderstedt.net> Date: Sun, 28 Aug 2011 19:15:34 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA22@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAA81@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAAD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E514770.7040405@lodderstedt.net> In-Reply-To: <4E514770.7040405@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 17:14:10 -0000 no comments? Am 21.08.2011 19:59, schrieb Torsten Lodderstedt: > Hi Eran, >>>> This is still just a CSRF attack. >>>> >>> I think you may be right. I still believe this particular style of >>> attack on the >>> authorization server is worth mentioning, be it in its own separate >>> section or >>> under the existing CSRF section (as you suggested). >> This is not a style of attack but techniques to enhance other >> exploits, in this case, CSRF. If you lack CSRF protection, then yes, >> lack of resource owner forced interaction will make it easier to >> execute. But that's just a tiny speed bump considering the actual >> exploit. >> >> I don't see any reason to include this new text based on this threat >> analysis. >> >> However, this doesn't mean this discussion wasn't useful. We did >> identify the need to explicitly discuss CSRF attacks on the >> authorization endpoint. We need to explicitly separate the two target >> of CSRF attacks (client, server) because while the solution is the >> same, the implementation is very different (due to the use of >> redirections in one). > > I agree, we should explicitely document these two variants of CSRF > (client, authz server). But I suspect it's not only CSRF we are > talking about in this thread - at least not textbook CSRF. Let me > explain my thoughts: > > As far as I understood, in a textbook CSRF attack the attacker would > create his own requests in order to abuse a user's session. This can > be prevented by utilizing standard CSRF coutermeasures (page token, > nounce, signature as parameter on every request URL), which bind URLs > to a certain session. > > But why should the attacker create requests et all? All he needs is > already provided by the authorization server themselves. The malicious > client can download the HTML pages comprising the authorization flow > from the authz server and use the embedded URLs to issue the requests > which normaly would have been issued by the resource owner herself > (using the use agent indeed). It's more or less the push on a "I > agree" button we are talking about. The authorization server may add a > page token to the respective form URL. But it does not matter since > the client just uses the authz server manufactured URL to post the form. > > So let's assume the attacker has to programmatically handle HTML forms > the authorization server delivers to the user agent. As you correctly > pointed out, the pre-requisite for such an attack to succeed is that > the resource owner must be authenticated somehow, e.g. based on a > session cookie. Which also means, we are talking about clients running > on the victim's device, within the user agent or as native app. > > I see the following possible scenarios: > > 1) external system browser - The app could utilize an existing session > within the system browser on the victim's device. It could then remote > control a browser window, e.g. using low-level operating system > messages ("send mouse click") or component techniques such as ActiveX. > There are tools available to create macros which automatically control > and obtain data from such applications. So this should be feasible. > > 2) internal browser (cross-browser cookies) - If the authorization > server uses cross-browser cookie techniques, such as flash cookies, > the attacker could instantiate an internal (invisible) browser and try > to utilize a session associated with such a cookie. I assume > controlling such a browser instance will be even simpler then in (1). > > 3) internal browser (silent authz flow) - This is a scenario where the > attacker is unable to abuse an existing session on the device. It > could instead create an internal browser and perform an authorization > flow with the resource owner for one particular scope. Using the same > browser instance and based on the cookies obtained in the first run, > it could silently perform additional authorization flows for other > scopes. > > 4) internal browser (non-interactive authentication methods) - There > are authentication methods available w/o the need for > user-interaction, for examples SIM card authentication or > certificate-based authentication. The attacker could utilize an > internal, invisible browser instance in combination with such an > authentication method in order to perform the authorization process. > > I'm not sure whether the scenarios described above can be classified > as CSRF. > > regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Mon Aug 29 01:14:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB91321F874B for ; Mon, 29 Aug 2011 01:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0xblE4kPdPr for ; Mon, 29 Aug 2011 01:14:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8451B21F8584 for ; Mon, 29 Aug 2011 01:14:36 -0700 (PDT) Received: (qmail invoked by alias); 29 Aug 2011 08:15:52 -0000 Received: from a88-115-210-23.elisa-laajakaista.fi (EHLO [10.0.0.8]) [88.115.210.23] by mail.gmx.net (mp064) with SMTP; 29 Aug 2011 10:15:52 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19HwDp/9xtHlIGZIE355v/VZ9OSD5sCV1Evmd1TBz fdkPwlW9S73yZD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345024864A96@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 29 Aug 2011 11:15:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1765F65A-9FFF-47AC-89D0-EC29E2918EE9@gmx.net> References: <90C41DD21FB7C64BB94121FBBC2E72345024864A96@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Security area review X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 08:14:37 -0000 Hi Eran,=20 I gave presentations to the security area directorate, and have asked = for review comments. Some of the folks (such as Tom Yu, and Shawn Emery) = showed up in the meetings and the side meetings and provided comments.=20= As Barry said, there will be more review comments flying in after the = document left the working group.=20 Ciao Hannes PS: I had also given presentations at the SAAG meeting to solicit more = feedback.=20 On Aug 6, 2011, at 10:29 AM, Eran Hammer-Lahav wrote: > Did the chairs issue a last call request to anyone in the security = area? I thought the whole point of moving this working group from apps = to security was to increase the review and participation of that area. = So far I have seen absolutely nothing to indicate any such contribution. = I would like to know what actual actions are being taken to turn this = promise into reality. > =20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From barryleiba@gmail.com Tue Aug 30 12:21:40 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC3021F8D22 for ; Tue, 30 Aug 2011 12:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.831 X-Spam-Level: X-Spam-Status: No, score=-102.831 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMx490oCzjDu for ; Tue, 30 Aug 2011 12:21:39 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3248921F8E1A for ; Tue, 30 Aug 2011 12:21:38 -0700 (PDT) Received: by gwb20 with SMTP id 20so6884405gwb.31 for ; Tue, 30 Aug 2011 12:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=mGTmYjMCwJU0/hKYnw5P2s1kS4uZYHyFnzCg70WeIUo=; b=GEY74njtKWwjJILghhZPR8IGRtOFb8SOyB4GRxX0mTvbJqaB/mKCOcNbCcr6s5vn02 cXJXYlHekMioBEpsRFIDZC52rPXQ34GrEwxaOF8QJt8PsOUHJ/EHrgeddkLjnbVvZO67 XAM4tA4xRbaap0Y/6iewkPOt390Vn6Gs8hd8E= MIME-Version: 1.0 Received: by 10.236.72.233 with SMTP id t69mr35771726yhd.55.1314732186168; Tue, 30 Aug 2011 12:23:06 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.208.35 with HTTP; Tue, 30 Aug 2011 12:23:06 -0700 (PDT) In-Reply-To: References: <20110729184136.5836.39491.idtracker@ietfa.amsl.com> <4E3435A0.3000603@stpeter.im> Date: Tue, 30 Aug 2011 15:23:06 -0400 X-Google-Sender-Auth: 9YdGKWoZC31JpT5C7o1WoylU0II Message-ID: From: Barry Leiba To: Brian Campbell , oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 19:21:40 -0000 Following up on this: On Sun, Jul 31, 2011 at 10:45, Barry Leiba wrote: > On 7/29/11 3:07 PM, Brian Campbell wrote: >> Following up from >> http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few >> weeks ago, I've submitted a new I-D to establish an IETF URN >> Sub-Namespace for OAuth (urn:ietf:params:oauth:*:*). =A0Eran balked at >> putting this in the core spec so it made sense to produce a separate >> draft for it. =A0I'd like to request from the group and the chairs that >> this draft become a work item of the WG as soon as possible. The SAML >> draft will utilize this to register a proper URN for the extension >> grant type and presumably the JWT draft will as well. =A0 Hopefully it >> will be useful in other contexts as well (like the oob parameter that >> has been discussed). >> >> The draft is available at: >> http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns-00 > > Given the progress that the OAuth WG has made, the fact that we're in > WGLC on two major documents, and the fact that the SAML draft depends > upon what's in here, I have no issue with adding this as a WG item. > Stephen, do you agree with that? =A0(I know that Stephen's away for a > bit, and won't be responding for a while. =A0This can wait until he gets > back, and in the meantime the SAML doc can assume that this one is > going forward.) Having seen support from Stephen for this direction, gotten agreement from my co-chairs, and seen no objection from the working group, I have pre-approved "draft-ietf-oauth-urn-sub-ns" as a working group item. Brian, please submit a new version under that name, and send a note to iesg-secretary asking them to mark the new document as replacing the old one. Everyone, please give this document some review, and make comments. Barry, as chair From internet-drafts@ietf.org Tue Aug 30 12:55:16 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE0221F8EFF; Tue, 30 Aug 2011 12:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISCrHusLkyQa; Tue, 30 Aug 2011 12:55:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1464E21F8EEB; Tue, 30 Aug 2011 12:55:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110830195516.9445.90096.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 12:55:16 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 19:55:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : An IETF URN Sub-Namespace for OAuth Author(s) : Hannes Tschofenig Filename : draft-ietf-oauth-urn-sub-ns-00.txt Pages : 5 Date : 2011-08-30 This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-urn-sub-ns-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-urn-sub-ns-00.txt From bcampbell@pingidentity.com Tue Aug 30 13:00:03 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5458121F8F3C for ; Tue, 30 Aug 2011 13:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewC5nfM7EGoF for ; Tue, 30 Aug 2011 13:00:02 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id 871A421F8F3D for ; Tue, 30 Aug 2011 13:00:02 -0700 (PDT) Received: from mail-qw0-f45.google.com ([209.85.216.45]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKTl1BmoYHdxtXuCCq0CM9vBskeR4RdIKm@postini.com; Tue, 30 Aug 2011 13:01:31 PDT Received: by mail-qw0-f45.google.com with SMTP id 8so6625qwj.4 for ; Tue, 30 Aug 2011 13:01:30 -0700 (PDT) Received: by 10.224.27.80 with SMTP id h16mr3019634qac.89.1314734490089; Tue, 30 Aug 2011 13:01:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.67.20 with HTTP; Tue, 30 Aug 2011 13:01:00 -0700 (PDT) In-Reply-To: References: <20110729184136.5836.39491.idtracker@ietfa.amsl.com> <4E3435A0.3000603@stpeter.im> From: Brian Campbell Date: Tue, 30 Aug 2011 14:01:00 -0600 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:00:03 -0000 Thanks Barry, The new draft has been submitted and is up at http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-00 (no changes other than the document name/identifier). I'll send a note to iesg-secretary shortly. -Brian On Tue, Aug 30, 2011 at 1:23 PM, Barry Leiba wrot= e: > Following up on this: > > On Sun, Jul 31, 2011 at 10:45, Barry Leiba wrot= e: >> On 7/29/11 3:07 PM, Brian Campbell wrote: >>> Following up from >>> http://www.ietf.org/mail-archive/web/oauth/current/msg06949.html a few >>> weeks ago, I've submitted a new I-D to establish an IETF URN >>> Sub-Namespace for OAuth (urn:ietf:params:oauth:*:*). =A0Eran balked at >>> putting this in the core spec so it made sense to produce a separate >>> draft for it. =A0I'd like to request from the group and the chairs that >>> this draft become a work item of the WG as soon as possible. The SAML >>> draft will utilize this to register a proper URN for the extension >>> grant type and presumably the JWT draft will as well. =A0 Hopefully it >>> will be useful in other contexts as well (like the oob parameter that >>> has been discussed). >>> >>> The draft is available at: >>> http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns-00 >> >> Given the progress that the OAuth WG has made, the fact that we're in >> WGLC on two major documents, and the fact that the SAML draft depends >> upon what's in here, I have no issue with adding this as a WG item. >> Stephen, do you agree with that? =A0(I know that Stephen's away for a >> bit, and won't be responding for a while. =A0This can wait until he gets >> back, and in the meantime the SAML doc can assume that this one is >> going forward.) > > Having seen support from Stephen for this direction, gotten agreement > from my co-chairs, and seen no objection from the working group, I > have pre-approved "draft-ietf-oauth-urn-sub-ns" as a working group > item. =A0Brian, please submit a new version under that name, and send a > note to iesg-secretary asking them to mark the new document as > replacing the old one. > > Everyone, please give this document some review, and make comments. > > Barry, as chair > From internet-drafts@ietf.org Tue Aug 30 13:13:53 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD1B21F8EDD; Tue, 30 Aug 2011 13:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIqY345GCmem; Tue, 30 Aug 2011 13:13:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196F021F8EAC; Tue, 30 Aug 2011 13:13:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110830201351.17809.4004.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 13:13:51 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:13:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-07.txt Pages : 16 Date : 2011-08-30 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-07.txt From internet-drafts@ietf.org Tue Aug 30 15:26:48 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C778121F8EEF; Tue, 30 Aug 2011 15:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0+XQcgBbsNa; Tue, 30 Aug 2011 15:26:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C89C21F8EC9; Tue, 30 Aug 2011 15:26:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110830222648.21755.8463.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 15:26:48 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 22:26:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Gr= oup of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-08.txt Pages : 16 Date : 2011-08-30 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-08.txt From wmills@yahoo-inc.com Tue Aug 30 22:13:37 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187D221F8C4E for ; Tue, 30 Aug 2011 22:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.288 X-Spam-Level: X-Spam-Status: No, score=-17.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh2bbb8MMPYP for ; Tue, 30 Aug 2011 22:13:36 -0700 (PDT) Received: from nm24.bullet.mail.sp2.yahoo.com (nm24.bullet.mail.sp2.yahoo.com [98.139.91.94]) by ietfa.amsl.com (Postfix) with SMTP id 158FE21F8C4C for ; Tue, 30 Aug 2011 22:13:36 -0700 (PDT) Received: from [98.139.91.68] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 31 Aug 2011 05:14:59 -0000 Received: from [98.139.91.37] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 31 Aug 2011 05:14:59 -0000 Received: from [127.0.0.1] by omp1037.mail.sp2.yahoo.com with NNFMP; 31 Aug 2011 05:14:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 286639.56246.bm@omp1037.mail.sp2.yahoo.com Received: (qmail 47070 invoked by uid 60001); 31 Aug 2011 05:14:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1314767698; bh=JCSF1qHyr7+XV6OndNsXaisNZjuB3SHYr+dEqm2TU0E=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=h8WzN5HKrUhZXKAJosH8fzLgi/TPZYAZm/5tftkDW9JNzkJQiOcTpo+ODObBiWcmmjC8kp55Shx3Ir7KEYX2i9PpOUMZFx73qQdAROnJ8sDY2osJR8fPTawzNsVGSCcjpf8buGoll/WagEiqLTkdi5/G6qXuTO/EDC12F+kZVxs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=mg/c5FDnK11lFakq9uJ13rMY7hfZq0R/XLUfIxYzrLpV2/IsO4jNT2Nom3Jlvo2XdGN1xEWHB5qhxplSYnmYTwbXifscDvcXWTwk5svFXqZgcfD8xxWD91VGSBJLh8sg2mUUXmoF6j73xBTBqX6O2UArTztU1stV4Hkfny8eh+k=; X-YMail-OSG: 0bRtgKsVM1kpG2_1JwOXqBZtoAnUGWqDajKHhhK8JLm4XYC KaIXYPuhzRN970xQz5kPJBdpzL0XE.pJsRELxTEmfCGNPZaNzObG2UZGUMLx MIk8DXocmBgOyAhqN7rkRh4qw7xj79gY.IaYxLiFI_48BvImGRxNa28TBF30 R31yIUaF9cjs8HU0PJnvfOuLF4fUeSRRCazRV9N7V5aOH2lueA3JK6ih4xjO _E9hhoH9GMEk1qTIgb4QNSsn3LtLrJK6r_wEEEGorfk4eN2blnOm07Bs24rU UEGztgsxeoGdJUzcXkOGPpVRO6DaYnPPc_hsTOuM94allA4LhCtJNIIH2d2o R1tMqpYCjgXBTXRiFo464U8WJSs2m.EJo2KU8o9vkPCjiW9ZuX6Jh.Nr9tKv 6wIzWhhTQa7G9JtF5tpGK Received: from [99.31.212.42] by web31808.mail.mud.yahoo.com via HTTP; Tue, 30 Aug 2011 22:14:58 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.114.317681 References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> Message-ID: <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> Date: Tue, 30 Aug 2011 22:14:58 -0700 (PDT) From: "William J. Mills" To: "Manger, James H" , "oauth@ietf.org" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1856681075-1314767698=:36186" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 05:13:37 -0000 --0-1856681075-1314767698=:36186 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Did item #2 below get resolved?=A0 I haven't seen any more traffic about it= and it seems pretty significant.=0A=0AThanks,=0A=0A-bill=0A=0A=0A=0A______= __________________________=0AFrom: "Manger, James H" =0ATo: "oauth@ietf.org" =0ASent: Thursday, July = 28, 2011 8:51 PM=0ASubject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WG= LC comments=0A=0AMy working group last call comments on draft-ietf-oauth-v2= -bearer-08.txt:=0A=0A=0A1. Mentioning that this is an HTTP authentication m= echanism in the title and/or abstract would be useful to the wider IETF (& = beyond) audience.=0ATitle:=0A=A0 "The BEARER HTTP authentication mechanism = for use with OAuth 2"=0AAbstract:=0A=A0 "This specification describes how t= o use bearer tokens in=0A=A0 HTTP requests to access OAuth 2 protected res= ources."=0A=0A[Personally, I wouldn't bother mentioning OAuth at all here, = but others seem to want this context restriction.]=0A=0A=0A2. The ABNF for = does not comply with RFC 2617 "HTTP Authentication". And even= though RFC 2617 is broken is this aspect, the BEARER spec doesn't comply w= ith the errata (still broken) or the more likely fixes proposed for HTTPbis= [draft-ietf-httpbis-p7-auth].=0AI expect HTTPbis to allow a base64-like-bl= ob consistently in Authorization and WWW-Authenticate headers (to accommoda= te BASIC and NTLM). Multiple WWW-Authenticate headers can have their values= combined, separated by commas. They can also have quoted-string parameters= . To be able to parse this, requires disallowing commas and double-quotes f= rom the base64-like-blob (and hence from ) at a minimum; only= allowing equals at the end also helps.=0AThe current approach in the beare= r spec disallows all but 94 chars/bytes. I suggest reducing this to 69. Som= ething in between (eg 91 chars, dropping comma, quote, and slash) might wor= k. None of these options are materially easier than the others for a token = issuer; and less symbols just means less risk of escaping problems elsewher= e (eg allowing "<" in an access token will wreck someone's XML somewhere, f= or no benefit).=0A=0ASuggestion: =0A=A0 access-token =3D 1*( ALPHA / DIGIT = / "-" / "." / "_" / "~" / "+" / "/" ) *"=3D"=0A=0A=A0 includ= es the 66 unreserved URI characters plus a few others.=0A=A0 It can hold a = base64, base64url (URL and filename safe alphabet),=0A=A0 base32, or base16= (hex) encoding, with or without padding, but=0A=A0 excluding whitespace [R= FC4648].=0A=0A2b. If 2 is not accepted (and assuming HTTPbis will allow any= content after the scheme name in a Authorization header) can we please not= misuse the label when no quoting is going on. The following = is a better equivalent:=0A=0A=A0 access-token =3D 1*(%x21-7E) ; ASCII, exce= pt controls, space, or delete=0A=0A=0A3. Drop '\' from the allowed chars in= a scope value, to avoid clashing with the HTTP quoted-string escaping mech= anism (and don't use the label when no quoting is going on).= =0A=A0 scope-v =3D 1*(%x21 / %x23-5B / %x5D-7E); excludes space and " and \= =0A=0A=0A4. Section 3.3 "Summary of Recommendations" sensibly says clients = "MUST ensure that bearer tokens are not leaked to *unintended parties*" and= correctly notes that this is "the primary security consideration" that und= erlies all the others. So it is a glaring hole that OAuth2 fails to tell th= e client who the intended parties are when issuing a bearer token.=0A=0A=0A= --=0AJames Manger=0A_______________________________________________=0AOAuth= mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oaut= h --0-1856681075-1314767698=:36186 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Did item #2 below get resolved?  I haven't seen any more traffic abo= ut it and it seems pretty significant.

Thanks,

-= bill

From: "Manger, James H" <James.H.Manger@team.telstra.com&= gt;
To: "oauth@ietf.org= " <oauth@ietf.org>
Sent: Thursday, July 28, 2011 8:51 PM
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WG= LC comments

My working group last call comments on draft-ietf= -oauth-v2-bearer-08.txt:


1. Mentioning that this is an HTTP auth= entication mechanism in the title and/or abstract would be useful to the wi= der IETF (& beyond) audience.
Title:
  "The BEARER HTTP auth= entication mechanism for use with OAuth 2"
Abstract:
  "This spe= cification describes how to use bearer tokens in
  HTTP requests t= o access OAuth 2 protected resources."

[Personally, I wouldn't bothe= r mentioning OAuth at all here, but others seem to want this context restri= ction.]


2. The ABNF for <credentials> does not comply with= RFC 2617 "HTTP Authentication". And even though RFC 2617 is broken is this= aspect, the BEARER spec doesn't comply with the errata (still broken) or t= he more likely fixes proposed for HTTPbis [draft-ietf-httpbis-p7-auth].
I expect HTTPbis to allow a base64-like-b= lob consistently in Authorization and WWW-Authenticate headers (to accommod= ate BASIC and NTLM). Multiple WWW-Authenticate headers can have their value= s combined, separated by commas. They can also have quoted-string parameter= s. To be able to parse this, requires disallowing commas and double-quotes = from the base64-like-blob (and hence from <access-token>) at a minimu= m; only allowing equals at the end also helps.
The current approach in t= he bearer spec disallows all but 94 chars/bytes. I suggest reducing this to= 69. Something in between (eg 91 chars, dropping comma, quote, and slash) m= ight work. None of these options are materially easier than the others for = a token issuer; and less symbols just means less risk of escaping problems = elsewhere (eg allowing "<" in an access token will wreck someone's XML s= omewhere, for no benefit).

Suggestion:
  access-token =3D 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *= "=3D"

  <access-token> includes the 66 unreserved URI cha= racters plus a few others.
  It can hold a base64, base64url (URL a= nd filename safe alphabet),
  base32, or base16 (hex) encoding, wit= h or without padding, but
  excluding whitespace [RFC4648].

= 2b. If 2 is not accepted (and assuming HTTPbis will allow any content after= the scheme name in a Authorization header) can we please not misuse the &l= t;quoted-char> label when no quoting is going on. The following is a bet= ter equivalent:

  access-token =3D 1*(%x21-7E) ; ASCII, except = controls, space, or delete


3. Drop '\' from the allowed chars in= a scope value, to avoid clashing with the HTTP quoted-string escaping mech= anism (and don't use the <quoted-char> label when no quoting is going= on).
  scope-v =3D 1*(%x21 / %x23-5B / %x5D-7E); excludes space an= d " and \


4. Section 3.3 "Summary of Recommendations" sensibly sa= ys clients "MUST ensure that bearer tokens are not leaked to *unintended pa= rties*" and correctly notes that this is "the primary security consideratio= n" that underlies all the others. So it is a glaring hole that OAuth2 fails= to tell the client who the intended parties are when issuing a bearer toke= n.


--
James Manger
_______________________________________= ________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailma= n/listinfo/oauth


--0-1856681075-1314767698=:36186-- From James.H.Manger@team.telstra.com Tue Aug 30 23:38:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD40221F8BFB for ; Tue, 30 Aug 2011 23:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[AWL=-2.910, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+MbHXvg+JTW for ; Tue, 30 Aug 2011 23:38:34 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 34B2C21F8B1E for ; Tue, 30 Aug 2011 23:38:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,306,1312120800"; d="scan'208,217";a="44531884" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 31 Aug 2011 16:39:58 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6454"; a="35561170" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdvi.tcif.telstra.com.au with ESMTP; 31 Aug 2011 16:39:55 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 31 Aug 2011 16:39:57 +1000 From: "Manger, James H" To: "William J. Mills" , "oauth@ietf.org" Date: Wed, 31 Aug 2011 16:39:56 +1000 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: AcxnnPDAE16t+EqSQQ6EDNNdp+Iq0QACeYMg Message-ID: <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> In-Reply-To: <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1128DB1DE6EWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 06:38:36 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1128DB1DE6EWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable William J. Mills said: >Did item #2 below get resolved? I haven't seen any more traffic about it = and it seems pretty significant. No, I haven't seen any resolution for #2 (or any of these comments). The latest HTTPbis draft (http://tools.ietf.org/html/draft-ietf-httpbis-p7-= auth-16) has updated ABNF for and that supports t= he base64-blobs used by BASIC and NTLM. It does not allow what BEARER tries= to do. -- James Manger ________________________________ From: "Manger, James H" To: "oauth@ietf.org" Sent: Thursday, July 28, 2011 8:51 PM Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt: 1. Mentioning that this is an HTTP authentication mechanism in the title an= d/or abstract would be useful to the wider IETF (& beyond) audience. Title: "The BEARER HTTP authentication mechanism for use with OAuth 2" Abstract: "This specification describes how to use bearer tokens in HTTP requests to access OAuth 2 protected resources." [Personally, I wouldn't bother mentioning OAuth at all here, but others see= m to want this context restriction.] 2. The ABNF for does not comply with RFC 2617 "HTTP Authentic= ation". And even though RFC 2617 is broken is this aspect, the BEARER spec = doesn't comply with the errata (still broken) or the more likely fixes prop= osed for HTTPbis [draft-ietf-httpbis-p7-auth]. I expect HTTPbis to allow a base64-like-blob consistently in Authorization = and WWW-Authenticate headers (to accommodate BASIC and NTLM). Multiple WWW-= Authenticate headers can have their values combined, separated by commas. T= hey can also have quoted-string parameters. To be able to parse this, requi= res disallowing commas and double-quotes from the base64-like-blob (and hen= ce from ) at a minimum; only allowing equals at the end also = helps. The current approach in the bearer spec disallows all but 94 chars/bytes. I= suggest reducing this to 69. Something in between (eg 91 chars, dropping c= omma, quote, and slash) might work. None of these options are materially ea= sier than the others for a token issuer; and less symbols just means less r= isk of escaping problems elsewhere (eg allowing "<" in an access token will= wreck someone's XML somewhere, for no benefit). Suggestion: access-token =3D 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) = *"=3D" includes the 66 unreserved URI characters plus a few other= s. It can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace [RFC4648]. 2b. If 2 is not accepted (and assuming HTTPbis will allow any content after= the scheme name in a Authorization header) can we please not misuse the label when no quoting is going on. The following is a better eq= uivalent: access-token =3D 1*(%x21-7E) ; ASCII, except controls, space, or delete 3. Drop '\' from the allowed chars in a scope value, to avoid clashing with= the HTTP quoted-string escaping mechanism (and don't use the = label when no quoting is going on). scope-v =3D 1*(%x21 / %x23-5B / %x5D-7E); excludes space and " and \ 4. Section 3.3 "Summary of Recommendations" sensibly says clients "MUST ens= ure that bearer tokens are not leaked to *unintended parties*" and correctl= y notes that this is "the primary security consideration" that underlies al= l the others. So it is a glaring hole that OAuth2 fails to tell the client = who the intended parties are when issuing a bearer token. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_255B9BB34FB7D647A506DC292726F6E1128DB1DE6EWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

William J. = Mills said:

>Did item #2 below get resolved?  I haven't seen any more traffic abou= t it and it seems pretty significant.

 

<= /span>

From: "Manger, James H" <James.H.Man= ger@team.telstra.com>
To: "oauth@ietf.org" <oauth= @ietf.org>
Sent: Thursday, July 28, 2011 8:51 PM
Subject= : [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments
=
My working group last call comments on draf= t-ietf-oauth-v2-bearer-08.txt:


1. Mentioning that this is an HTT= P authentication mechanism in the title and/or abstract would be useful to = the wider IETF (& beyond) audience.
Title:
  "The BEARE= R HTTP authentication mechanism for use with OAuth 2"
Abstract:
=   "This specification describes how to use bearer tokens in
&n= bsp; HTTP requests to access OAuth 2 protected resources."

[Per= sonally, I wouldn't bother mentioning OAuth at all here, but others seem to= want this context restriction.]


2. The ABNF for <credentials= > does not comply with RFC 2617 "HTTP Authentication". And eve= n though RFC 2617 is broken is this aspect, the BEARER spec doesn't comply = with the errata (still broken) or the more likely fixes proposed for HTTPbi= s [draft-ietf-httpbis-p7-auth].
I expect HTTPbis to allow a base64-like-= blob consistently in Authorization and WWW-Authenticate headers (to accommo= date BASIC and NTLM). Multiple WWW-Authenticate headers can have their valu= es combined, separated by commas. They can also have quoted-string paramete= rs. To be able to parse this, requires disallowing commas and double-quotes= from the base64-like-blob (and hence from <access-token>) at a minim= um; only allowing equals at the end also helps.
The current approach in = the bearer spec disallows all but 94 chars/bytes. I suggest reducing this t= o 69. Something in between (eg 91 chars, dropping comma, quote, and slash) = might work. None of these options are materially easier than the others for= a token issuer; and less symbols just means less risk of escaping problems= elsewhere (eg allowing "<" in an access token will wreck some= one's XML somewhere, for no benefit).

Suggestion:
  access-= token =3D 1*( ALPHA / DIGIT / "-" / "." / "_"= / "~" / "+" / "/" ) *"=3D"

=   <access-token> includes the 66 unreserved URI characters plus = a few others.
  It can hold a base64, base64url (URL and filename s= afe alphabet),
  base32, or base16 (hex) encoding, with or without = padding, but
  excluding whitespace [RFC4648].

2b. If 2 is n= ot accepted (and assuming HTTPbis will allow any content after the scheme n= ame in a Authorization header) can we please not misuse the <quoted-char= > label when no quoting is going on. The following is a better equivalen= t:

  access-token =3D 1*(%x21-7E) ; ASCII, except controls, spa= ce, or delete


3. Drop '\' from the allowed chars in a scope valu= e, to avoid clashing with the HTTP quoted-string escaping mechanism (and do= n't use the <quoted-char> label when no quoting is going on).
&nbs= p; scope-v =3D 1*(%x21 / %x23-5B / %x5D-7E); excludes space and " and = \


4. Section 3.3 "Summary of Recommendations" sensibly= says clients "MUST ensure that bearer tokens are not leaked to *unint= ended parties*" and correctly notes that this is "the primary sec= urity consideration" that underlies all the others. So it is a glaring= hole that OAuth2 fails to tell the client who the intended parties are whe= n issuing a bearer token.


--
James Manger
________________= _______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/= oauth

= --_000_255B9BB34FB7D647A506DC292726F6E1128DB1DE6EWSMSG3153Vsrv_-- From julian.reschke@gmx.de Tue Aug 30 23:51:36 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D26521F8BA7 for ; Tue, 30 Aug 2011 23:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.136 X-Spam-Level: X-Spam-Status: No, score=-104.136 tagged_above=-999 required=5 tests=[AWL=-1.537, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV8RVUomyUYT for ; Tue, 30 Aug 2011 23:51:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1EDF621F8B8B for ; Tue, 30 Aug 2011 23:51:34 -0700 (PDT) Received: (qmail invoked by alias); 31 Aug 2011 06:53:03 -0000 Received: from p508FA8FA.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.168.250] by mail.gmx.net (mp036) with SMTP; 31 Aug 2011 08:53:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19EsEZpuoVEFH6lZt02hqlKaSOO4XLx09Ls5qOqCw ZSx2W5Y1nEUjtG Message-ID: <4E5DDA4C.7070607@gmx.de> Date: Wed, 31 Aug 2011 08:53:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "Manger, James H" References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 06:51:36 -0000 On 2011-08-31 08:39, Manger, James H wrote: > William J. Mills said: > >>Did item #2 below get resolved? I haven't seen any more traffic about it > and it seems pretty significant. > > No, I haven’t seen any resolution for #2 (or any of these comments). > > The latest HTTPbis draft > (http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16) has updated > ABNF for and that supports the base64-blobs > used by BASIC and NTLM. It does not allow what BEARER tries to do. > ... Also note...: Best regards, Julian From stpeter@stpeter.im Wed Aug 31 12:13:11 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA9621F8F1C for ; Wed, 31 Aug 2011 12:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0hNKuucQaSn for ; Wed, 31 Aug 2011 12:13:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 93ED421F8F1A for ; Wed, 31 Aug 2011 12:13:10 -0700 (PDT) Received: from leavealone.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CB0784174A; Wed, 31 Aug 2011 13:17:18 -0600 (MDT) Message-ID: <4E5E881F.70901@stpeter.im> Date: Wed, 31 Aug 2011 13:14:39 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Justin Karneges References: <201108261604.57643.justin@affinix.com> In-Reply-To: <201108261604.57643.justin@affinix.com> X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] SSO scenario X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:13:11 -0000 I tried to help Justin off-list, but it would be nice to have a FAQ somewhere that shows developers how to translate from OAuth 1.1 to OAuth 2.0, even just conceptually (as in, "they got rid of the legs, how do I do two-legged auth in OAuth 2.0?!?"). On 8/26/11 5:04 PM, Justin Karneges wrote: > Hi folks, > > I currently use a proprietary token approach to provide authentication to a > browser widget, and I wonder if OAuth could be used to replace it. > > Here's how the system currently works: > - website supports authenticated users (happens via username/password form) > - website and widget provider have a shared secret > - the website serves a page to the browser, containing an embed of a remote > widget as well as a token that asserts the currently logged in user. the > widget takes this token and performs an ajax call to the widget provider > server. behold, the user is now logged in to the widget. > > In trying to organize this into OAuth terms and roles, here is what I come up > with: > - resource owner: the user > - resource server: widget provider (where the resource is generically "the > ability to utilize the widget") > - client: the webpage running in the browser > - authorization server: the website > > The website essentially serves up the client application and token in one > shot, so the client never has to explicitly ask for a token. However, the > client would then take that token and use it to access a service. The website > and widget provider would share key material such that token validation is > possible, but it's important to note that the two services are not owned and > operated by the same people. > > Does this seem right? Normally when I think of OAuth, I think of a user > giving a third-party service access to his personal stuff, but in the above flow > I'm proposing that OAuth be used so that the user gains access to his own > stuff. In fact, there would be no way to access his stuff other than this > approach, so it's not just about optional third-party access. It's the direct > and only access. > > Would love confirmation that OAuth is appropriate for my needs, and if I have > the roles right in that case. > > Thanks, > Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Wed Aug 31 12:41:31 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4850F21F8CAB for ; Wed, 31 Aug 2011 12:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUSj+GMAJF4h for ; Wed, 31 Aug 2011 12:41:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2A721F8C7B for ; Wed, 31 Aug 2011 12:41:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 17CBF21B129A; Wed, 31 Aug 2011 15:43:01 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B361421B153A; Wed, 31 Aug 2011 15:43:00 -0400 (EDT) Received: from [129.83.50.1] (129.83.31.55) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server id 14.1.270.1; Wed, 31 Aug 2011 15:43:00 -0400 From: Justin Richer To: Peter Saint-Andre In-Reply-To: <4E5E881F.70901@stpeter.im> References: <201108261604.57643.justin@affinix.com> <4E5E881F.70901@stpeter.im> Content-Type: text/plain; charset="UTF-8" Date: Wed, 31 Aug 2011 15:42:05 -0400 Message-ID: <1314819725.9663.322.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SSO scenario X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:41:31 -0000 This description actually sounds a lot like the user-agent flow (aka, "implicit authorization grant") in OAuth2 more than it does a true two-legged system. The user is still there, and there's still a client and protected resource, it's just that they're fairly tightly tied. When using the implicit flow, one of the things you rely on for verification of the client is the callback url. In this case, it can be completely pre-registered back to something that the AS/PR has direct control over. If you wanted to do a more traditional two-legged approach, you can use the client-credentials flow between the two servers and have the user's identity just be asserted as part of an explicit API call. But since you have a user in the loop, you might as well use them and do a real three-legged kind of thing. Additionally, the "user is logged in" bits could be handled by using OpenID Connect if he wants to go in that direction. At a very high level, the user ID basically becomes an OAuth2 protected resource, thus allowing you to log in from any where you can get an access token. (Connect folks, please feel free to chime in and tell Justin how wrong I am.) -- Justin On Wed, 2011-08-31 at 15:14 -0400, Peter Saint-Andre wrote: > I tried to help Justin off-list, but it would be nice to have a FAQ > somewhere that shows developers how to translate from OAuth 1.1 to OAuth > 2.0, even just conceptually (as in, "they got rid of the legs, how do I > do two-legged auth in OAuth 2.0?!?"). > > On 8/26/11 5:04 PM, Justin Karneges wrote: > > Hi folks, > > > > I currently use a proprietary token approach to provide authentication to a > > browser widget, and I wonder if OAuth could be used to replace it. > > > > Here's how the system currently works: > > - website supports authenticated users (happens via username/password form) > > - website and widget provider have a shared secret > > - the website serves a page to the browser, containing an embed of a remote > > widget as well as a token that asserts the currently logged in user. the > > widget takes this token and performs an ajax call to the widget provider > > server. behold, the user is now logged in to the widget. > > > > In trying to organize this into OAuth terms and roles, here is what I come up > > with: > > - resource owner: the user > > - resource server: widget provider (where the resource is generically "the > > ability to utilize the widget") > > - client: the webpage running in the browser > > - authorization server: the website > > > > The website essentially serves up the client application and token in one > > shot, so the client never has to explicitly ask for a token. However, the > > client would then take that token and use it to access a service. The website > > and widget provider would share key material such that token validation is > > possible, but it's important to note that the two services are not owned and > > operated by the same people. > > > > Does this seem right? Normally when I think of OAuth, I think of a user > > giving a third-party service access to his personal stuff, but in the above flow > > I'm proposing that OAuth be used so that the user gains access to his own > > stuff. In fact, there would be no way to access his stuff other than this > > approach, so it's not just about optional third-party access. It's the direct > > and only access. > > > > Would love confirmation that OAuth is appropriate for my needs, and if I have > > the roles right in that case. > > > > Thanks, > > Justin > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Wed Aug 31 13:45:33 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32BA21F8E84 for ; Wed, 31 Aug 2011 13:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.451 X-Spam-Level: X-Spam-Status: No, score=-10.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NgL6zVin0Ab for ; Wed, 31 Aug 2011 13:45:31 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 1561F21F8F24 for ; Wed, 31 Aug 2011 13:45:31 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 31 Aug 2011 13:47:02 -0700 Received: from TK5EX14MBXC203.redmond.corp.microsoft.com ([169.254.3.132]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0323.007; Wed, 31 Aug 2011 13:47:01 -0700 From: Mike Jones To: "Manger, James H" , "William J. Mills" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: AQHMTaLJnWCrafb4ZE+NLLSMK5FwXJU3E+0AgAAXvQCAAHcLQA== Date: Wed, 31 Aug 2011 20:47:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435B777471@TK5EX14MBXC203.redmond.corp.microsoft.com> References: <20110727131700.23436.11568.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739434986822D@TK5EX14MBXC202.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E11289635128@WSMSG3153V.srv.dir.telstra.com> <1314767698.36186.YahooMailNeo@web31808.mail.mud.yahoo.com> <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128DB1DE6E@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435B777471TK5EX14MBXC203r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 20:45:34 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435B777471TK5EX14MBXC203r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm back from several weeks away from the office and presently reviewing th= e WGLC comments on the bearer token specification, so as to propose resolut= ions to the issues raised. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Tuesday, August 30, 2011 11:40 PM To: William J. Mills; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments William J. Mills said: >Did item #2 below get resolved? I haven't seen any more traffic about it = and it seems pretty significant. No, I haven't seen any resolution for #2 (or any of these comments). The latest HTTPbis draft (http://tools.ietf.org/html/draft-ietf-httpbis-p7-= auth-16) has updated ABNF for and that supports t= he base64-blobs used by BASIC and NTLM. It does not allow what BEARER tries= to do. -- James Manger ________________________________ From: "Manger, James H" To: "oauth@ietf.org" Sent: Thursday, July 28, 2011 8:51 PM Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt: 1. Mentioning that this is an HTTP authentication mechanism in the title an= d/or abstract would be useful to the wider IETF (& beyond) audience. Title: "The BEARER HTTP authentication mechanism for use with OAuth 2" Abstract: "This specification describes how to use bearer tokens in HTTP requests to access OAuth 2 protected resources." [Personally, I wouldn't bother mentioning OAuth at all here, but others see= m to want this context restriction.] 2. The ABNF for does not comply with RFC 2617 "HTTP Authentic= ation". And even though RFC 2617 is broken is this aspect, the BEARER spec = doesn't comply with the errata (still broken) or the more likely fixes prop= osed for HTTPbis [draft-ietf-httpbis-p7-auth]. I expect HTTPbis to allow a base64-like-blob consistently in Authorization = and WWW-Authenticate headers (to accommodate BASIC and NTLM). Multiple WWW-= Authenticate headers can have their values combined, separated by commas. T= hey can also have quoted-string parameters. To be able to parse this, requi= res disallowing commas and double-quotes from the base64-like-blob (and hen= ce from ) at a minimum; only allowing equals at the end also = helps. The current approach in the bearer spec disallows all but 94 chars/bytes. I= suggest reducing this to 69. Something in between (eg 91 chars, dropping c= omma, quote, and slash) might work. None of these options are materially ea= sier than the others for a token issuer; and less symbols just means less r= isk of escaping problems elsewhere (eg allowing "<" in an access token will= wreck someone's XML somewhere, for no benefit). Suggestion: access-token =3D 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) = *"=3D" includes the 66 unreserved URI characters plus a few other= s. It can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace [RFC4648]. 2b. If 2 is not accepted (and assuming HTTPbis will allow any content after= the scheme name in a Authorization header) can we please not misuse the label when no quoting is going on. The following is a better eq= uivalent: access-token =3D 1*(%x21-7E) ; ASCII, except controls, space, or delete 3. Drop '\' from the allowed chars in a scope value, to avoid clashing with= the HTTP quoted-string escaping mechanism (and don't use the = label when no quoting is going on). scope-v =3D 1*(%x21 / %x23-5B / %x5D-7E); excludes space and " and \ 4. Section 3.3 "Summary of Recommendations" sensibly says clients "MUST ens= ure that bearer tokens are not leaked to *unintended parties*" and correctl= y notes that this is "the primary security consideration" that underlies al= l the others. So it is a glaring hole that OAuth2 fails to tell the client = who the intended parties are when issuing a bearer token. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739435B777471TK5EX14MBXC203r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m back from sever= al weeks away from the office and presently reviewing the WGLC comments on = the bearer token specification, so as to propose resolutions to the issues raised.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, James H
Sent: Tuesday, August 30, 2011 11:40 PM
To: William J. Mills; oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comme= nts

 

William J. Mills said:

>Did = item #2 below get resolved?  I haven't seen any more traffic about it and it seems pretty significant.

 

 

No, I have= n’t seen any resolution for #2 (or any of these comments).=

The latest HTTPbis draft (http://tools.ietf.org/html/draft-ietf-= httpbis-p7-auth-16) has updated ABNF for <challenge> and <credentials> that suppor= ts the base64-blobs used by BASIC and NTLM. It does not allow what BEARER t= ries to do.

 

--

James Manger

 

 

<= span lang=3D"EN-AU" style=3D"font-size:10.0pt;font-family:"Arial"= ,"sans-serif";color:black">From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Sent: Thursday, July 28, 2011 8:51 PM
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08.txt WGLC comments<= br>
My working group last call comments on draft-ietf-oauth-v2-bearer-08.txt:

1. Mentioning that this is an HTTP authentication mechanism in the title an= d/or abstract would be useful to the wider IETF (& beyond) audience. Title:
  "The BEARER HTTP authentication mechanism for use with OAuth 2&= quot;
Abstract:
  "This specification describes how to use bearer tokens in
  HTTP requests to access OAuth 2 protected resources."

[Personally, I wouldn't bother mentioning OAuth at all here, but others see= m to want this context restriction.]


2. The ABNF for <credentials> does not comply with RFC 2617 "HTT= P Authentication". And even though RFC 2617 is broken is this aspect, = the BEARER spec doesn't comply with the errata (still broken) or the more l= ikely fixes proposed for HTTPbis [draft-ietf-httpbis-p7-auth].
I expect HTTPbis to allow a base64-like-blob consistently in Authorization = and WWW-Authenticate headers (to accommodate BASIC and NTLM). Multiple WWW-= Authenticate headers can have their values combined, separated by commas. T= hey can also have quoted-string parameters. To be able to parse this, requires disallowing commas and doub= le-quotes from the base64-like-blob (and hence from <access-token>) a= t a minimum; only allowing equals at the end also helps.
The current approach in the bearer spec disallows all but 94 chars/bytes. I= suggest reducing this to 69. Something in between (eg 91 chars, dropping c= omma, quote, and slash) might work. None of these options are materially ea= sier than the others for a token issuer; and less symbols just means less risk of escaping problems elsewhe= re (eg allowing "<" in an access token will wreck someone's XM= L somewhere, for no benefit).

Suggestion:
  access-token =3D 1*( ALPHA / DIGIT / "-" / "." /= "_" / "~" / "+" / "/" ) *"= ;=3D"

  <access-token> includes the 66 unreserved URI characters plus = a few others.
  It can hold a base64, base64url (URL and filename safe alphabet),   base32, or base16 (hex) encoding, with or without padding, but
  excluding whitespace [RFC4648].

2b. If 2 is not accepted (and assuming HTTPbis will allow any content after= the scheme name in a Authorization header) can we please not misuse the &l= t;quoted-char> label when no quoting is going on. The following is a bet= ter equivalent:

  access-token =3D 1*(%x21-7E) ; ASCII, except controls, space, or del= ete


3. Drop '\' from the allowed chars in a scope value, to avoid clashing with= the HTTP quoted-string escaping mechanism (and don't use the <quoted-ch= ar> label when no quoting is going on).
  scope-v =3D 1*(%x21 / %x23-5B / %x5D-7E); excludes space and " = and \


4. Section 3.3 "Summary of Recommendations" sensibly says clients= "MUST ensure that bearer tokens are not leaked to *unintended parties= *" and correctly notes that this is "the primary security conside= ration" that underlies all the others. So it is a glaring hole that OAuth2 fails to tell the client who the intended parties are whe= n issuing a bearer token.


--
James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--_000_4E1F6AAD24975D4BA5B16804296739435B777471TK5EX14MBXC203r_-- From justin@affinix.com Wed Aug 31 13:56:38 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DC621F8DBF for ; Wed, 31 Aug 2011 13:56:38 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yfYSAFogNDo for ; Wed, 31 Aug 2011 13:56:37 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0FE21F8DBD for ; Wed, 31 Aug 2011 13:56:37 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 38769284091; Wed, 31 Aug 2011 13:58:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=affinix.com; h=from:to:subject :date:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=affinix.com; b=b dVxO/hi+Udf8OBDefeI3AwPDgpuGnLXKW5tW7AtMiaNXkmViKWNPaW9GsOhNV88y XHFqxiIO1gj5KJYkH7g88bTBEHxycxDpwV+kg8tV/U1LhQ6paPmjJ7yakRl8NdJW kov2VSwl4WDH1e0/LsI7sagiNkg7Y3MPLBh8yuHDJs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=affinix.com; h=from:to :subject:date:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; s= affinix.com; bh=zeCDuPxlZbDS8b0kuSWI58ol1E0=; b=SEpyTuAw677VVOaV p40W9+uD7q1IOa0QM4lr+81O9olZW5Mh4KJ9Q2IF47WIibseb20lKABJDqmQrl0y a60PuWjX+FZxdwyajPM4/4SWKCki6oEiLRuGT20m7SeMZOjjaenXZHzuh+qXfX77 FHF/0vK25AETMwi5AaWmnSF+qc0= Received: from purelace.localnet (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: justin@affinix.com) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 22BED28408B; Wed, 31 Aug 2011 13:58:08 -0700 (PDT) From: Justin Karneges To: Justin Richer Date: Wed, 31 Aug 2011 13:58:07 -0700 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.6.2; x86_64; ; ) References: <201108261604.57643.justin@affinix.com> <4E5E881F.70901@stpeter.im> <1314819725.9663.322.camel@ground> In-Reply-To: <1314819725.9663.322.camel@ground> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201108311358.07248.justin@affinix.com> Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SSO scenario X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 20:56:38 -0000 Thanks Justin. I tend to agree that this is probably not a 2-legged issue, and that there is likely a better fitting arrangement in the OAuth 2.0 system. I've thought about this some more, and, especially given that the website and widget provider are separately-owned entities, maybe the roles ought to be: - resource owner: the website (not the user) - resource server: widget provider (where the resource is generically "the ability to utilize the widget") - client: the webpage running in the browser - authorization server: widget provider (not the website) This way, we are sharing an auth grant between two separately-owned entities rather than an access token. As I understand it, an access token is really meant for exchange between two tightly related entities since as far as I can tell access token formats are proprietary. Auth grants, on the other hand, are being standardized (SAML?), and so they seem more appropriate for exchange between organizations. So, by the fact that the website trusts the client (the user has signed into the website using a traditional web form, and the client possesses a cookie), the website gives an authorization grant to the client in order to access widget services. The grant would indicate rights scoped appropriately based on the particular user. How's that? :) On Wednesday, August 31, 2011 12:42:05 PM Justin Richer wrote: > This description actually sounds a lot like the user-agent flow (aka, > "implicit authorization grant") in OAuth2 more than it does a true > two-legged system. The user is still there, and there's still a client > and protected resource, it's just that they're fairly tightly tied. > > When using the implicit flow, one of the things you rely on for > verification of the client is the callback url. In this case, it can be > completely pre-registered back to something that the AS/PR has direct > control over. > > If you wanted to do a more traditional two-legged approach, you can use > the client-credentials flow between the two servers and have the user's > identity just be asserted as part of an explicit API call. But since you > have a user in the loop, you might as well use them and do a real > three-legged kind of thing. > > Additionally, the "user is logged in" bits could be handled by using > OpenID Connect if he wants to go in that direction. At a very high > level, the user ID basically becomes an OAuth2 protected resource, thus > allowing you to log in from any where you can get an access token. > (Connect folks, please feel free to chime in and tell Justin how wrong I > am.) > > -- Justin > > On Wed, 2011-08-31 at 15:14 -0400, Peter Saint-Andre wrote: > > I tried to help Justin off-list, but it would be nice to have a FAQ > > somewhere that shows developers how to translate from OAuth 1.1 to OAuth > > 2.0, even just conceptually (as in, "they got rid of the legs, how do I > > do two-legged auth in OAuth 2.0?!?"). > > > > On 8/26/11 5:04 PM, Justin Karneges wrote: > > > Hi folks, > > > > > > I currently use a proprietary token approach to provide authentication > > > to a browser widget, and I wonder if OAuth could be used to replace > > > it. > > > > > > Here's how the system currently works: > > > - website supports authenticated users (happens via username/password > > > form) - website and widget provider have a shared secret > > > - the website serves a page to the browser, containing an embed of a > > > remote > > > > > > widget as well as a token that asserts the currently logged in user. > > > the widget takes this token and performs an ajax call to the widget > > > provider server. behold, the user is now logged in to the widget. > > > > > > In trying to organize this into OAuth terms and roles, here is what I > > > come up > > > > > > with: > > > - resource owner: the user > > > - resource server: widget provider (where the resource is generically > > > "the > > > > > > ability to utilize the widget") > > > > > > - client: the webpage running in the browser > > > - authorization server: the website > > > > > > The website essentially serves up the client application and token in > > > one shot, so the client never has to explicitly ask for a token. > > > However, the client would then take that token and use it to access a > > > service. The website and widget provider would share key material > > > such that token validation is possible, but it's important to note > > > that the two services are not owned and operated by the same people. > > > > > > Does this seem right? Normally when I think of OAuth, I think of a > > > user giving a third-party service access to his personal stuff, but in > > > the above flow I'm proposing that OAuth be used so that the user gains > > > access to his own stuff. In fact, there would be no way to access his > > > stuff other than this approach, so it's not just about optional > > > third-party access. It's the direct and only access. > > > > > > Would love confirmation that OAuth is appropriate for my needs, and if > > > I have the roles right in that case. > > > > > > Thanks, > > > Justin > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From gffletch@aol.com Wed Aug 31 14:04:42 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B94A21F8F85 for ; Wed, 31 Aug 2011 14:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PHbAQUjf8fk for ; Wed, 31 Aug 2011 14:04:41 -0700 (PDT) Received: from imr-da05.mx.aol.com (imr-da05.mx.aol.com [205.188.105.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5340521F8F82 for ; Wed, 31 Aug 2011 14:04:41 -0700 (PDT) Received: from mtaout-db04.r1000.mx.aol.com (mtaout-db04.r1000.mx.aol.com [172.29.51.196]) by imr-da05.mx.aol.com (8.14.1/8.14.1) with ESMTP id p7VL5xbX027212; Wed, 31 Aug 2011 17:05:59 -0400 Received: from palantir.local (unknown [10.172.0.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-db04.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2838EE000085; Wed, 31 Aug 2011 17:05:59 -0400 (EDT) Message-ID: <4E5EA236.9080904@aol.com> Date: Wed, 31 Aug 2011 17:05:58 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Justin Karneges References: <201108261604.57643.justin@affinix.com> <4E5E881F.70901@stpeter.im> <1314819725.9663.322.camel@ground> <201108311358.07248.justin@affinix.com> In-Reply-To: <201108311358.07248.justin@affinix.com> Content-Type: multipart/alternative; boundary="------------040709080102020706030101" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:456362176:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d33c44e5ea2370872 X-AOL-IP: 10.172.0.93 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SSO scenario X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 21:04:42 -0000 This is a multi-part message in MIME format. --------------040709080102020706030101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit You could also use a signed JWT returned by the resource owner (web site) to be presented to the resource server (widget provider) that the resource server can validate (e.g. verify the signature). The JWT can contain scopes, expiry time, etc as needed. If the widget provider needs to access services at the resource owner, the JWT can contain an appropriate access_token for the user. Thanks, George On 8/31/11 4:58 PM, Justin Karneges wrote: > Thanks Justin. I tend to agree that this is probably not a 2-legged issue, > and that there is likely a better fitting arrangement in the OAuth 2.0 system. > > I've thought about this some more, and, especially given that the website and > widget provider are separately-owned entities, maybe the roles ought to be: > > - resource owner: the website (not the user) > - resource server: widget provider (where the resource is generically "the > ability to utilize the widget") > - client: the webpage running in the browser > - authorization server: widget provider (not the website) > > This way, we are sharing an auth grant between two separately-owned entities > rather than an access token. As I understand it, an access token is really > meant for exchange between two tightly related entities since as far as I can > tell access token formats are proprietary. Auth grants, on the other hand, > are being standardized (SAML?), and so they seem more appropriate for exchange > between organizations. > > So, by the fact that the website trusts the client (the user has signed into > the website using a traditional web form, and the client possesses a cookie), > the website gives an authorization grant to the client in order to access > widget services. The grant would indicate rights scoped appropriately based > on the particular user. > > How's that? :) > > On Wednesday, August 31, 2011 12:42:05 PM Justin Richer wrote: >> This description actually sounds a lot like the user-agent flow (aka, >> "implicit authorization grant") in OAuth2 more than it does a true >> two-legged system. The user is still there, and there's still a client >> and protected resource, it's just that they're fairly tightly tied. >> >> When using the implicit flow, one of the things you rely on for >> verification of the client is the callback url. In this case, it can be >> completely pre-registered back to something that the AS/PR has direct >> control over. >> >> If you wanted to do a more traditional two-legged approach, you can use >> the client-credentials flow between the two servers and have the user's >> identity just be asserted as part of an explicit API call. But since you >> have a user in the loop, you might as well use them and do a real >> three-legged kind of thing. >> >> Additionally, the "user is logged in" bits could be handled by using >> OpenID Connect if he wants to go in that direction. At a very high >> level, the user ID basically becomes an OAuth2 protected resource, thus >> allowing you to log in from any where you can get an access token. >> (Connect folks, please feel free to chime in and tell Justin how wrong I >> am.) >> >> -- Justin >> >> On Wed, 2011-08-31 at 15:14 -0400, Peter Saint-Andre wrote: >>> I tried to help Justin off-list, but it would be nice to have a FAQ >>> somewhere that shows developers how to translate from OAuth 1.1 to OAuth >>> 2.0, even just conceptually (as in, "they got rid of the legs, how do I >>> do two-legged auth in OAuth 2.0?!?"). >>> >>> On 8/26/11 5:04 PM, Justin Karneges wrote: >>>> Hi folks, >>>> >>>> I currently use a proprietary token approach to provide authentication >>>> to a browser widget, and I wonder if OAuth could be used to replace >>>> it. >>>> >>>> Here's how the system currently works: >>>> - website supports authenticated users (happens via username/password >>>> form) - website and widget provider have a shared secret >>>> - the website serves a page to the browser, containing an embed of a >>>> remote >>>> >>>> widget as well as a token that asserts the currently logged in user. >>>> the widget takes this token and performs an ajax call to the widget >>>> provider server. behold, the user is now logged in to the widget. >>>> >>>> In trying to organize this into OAuth terms and roles, here is what I >>>> come up >>>> >>>> with: >>>> - resource owner: the user >>>> - resource server: widget provider (where the resource is generically >>>> "the >>>> >>>> ability to utilize the widget") >>>> >>>> - client: the webpage running in the browser >>>> - authorization server: the website >>>> >>>> The website essentially serves up the client application and token in >>>> one shot, so the client never has to explicitly ask for a token. >>>> However, the client would then take that token and use it to access a >>>> service. The website and widget provider would share key material >>>> such that token validation is possible, but it's important to note >>>> that the two services are not owned and operated by the same people. >>>> >>>> Does this seem right? Normally when I think of OAuth, I think of a >>>> user giving a third-party service access to his personal stuff, but in >>>> the above flow I'm proposing that OAuth be used so that the user gains >>>> access to his own stuff. In fact, there would be no way to access his >>>> stuff other than this approach, so it's not just about optional >>>> third-party access. It's the direct and only access. >>>> >>>> Would love confirmation that OAuth is appropriate for my needs, and if >>>> I have the roles right in that case. >>>> >>>> Thanks, >>>> Justin >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------040709080102020706030101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You could also use a signed JWT returned by the resource owner (web site) to be presented to the resource server (widget provider) that the resource server can validate (e.g. verify the signature). The JWT can contain scopes, expiry time, etc as needed. If the widget provider needs to access services at the resource owner, the JWT can contain an appropriate access_token for the user.

Thanks,
George

On 8/31/11 4:58 PM, Justin Karneges wrote: 
Thanks Justin.  I tend to agree that this is probably not a 2-legged issue, 
and that there is likely a better fitting arrangement in the OAuth 2.0 system.

I've thought about this some more, and, especially given that the website and 
widget provider are separately-owned entities, maybe the roles ought to be:

 - resource owner: the website (not the user)
 - resource server: widget provider (where the resource is generically "the 
ability to utilize the widget")
 - client: the webpage running in the browser
 - authorization server: widget provider (not the website)

This way, we are sharing an auth grant between two separately-owned entities 
rather than an access token.  As I understand it, an access token is really 
meant for exchange between two tightly related entities since as far as I can 
tell access token formats are proprietary.  Auth grants, on the other hand, 
are being standardized (SAML?), and so they seem more appropriate for exchange 
between organizations.

So, by the fact that the website trusts the client (the user has signed into 
the website using a traditional web form, and the client possesses a cookie), 
the website gives an authorization grant to the client in order to access 
widget services.  The grant would indicate rights scoped appropriately based 
on the particular user.

How's that? :)

On Wednesday, August 31, 2011 12:42:05 PM Justin Richer wrote:

This description actually sounds a lot like the user-agent flow (aka,
"implicit authorization grant") in OAuth2 more than it does a true
two-legged system. The user is still there, and there's still a client
and protected resource, it's just that they're fairly tightly tied.

When using the implicit flow, one of the things you rely on for
verification of the client is the callback url. In this case, it can be
completely pre-registered back to something that the AS/PR has direct
control over.

If you wanted to do a more traditional two-legged approach, you can use
the client-credentials flow between the two servers and have the user's
identity just be asserted as part of an explicit API call. But since you
have a user in the loop, you might as well use them and do a real
three-legged kind of thing.

Additionally, the "user is logged in" bits could be handled by using
OpenID Connect if he wants to go in that direction. At a very high
level, the user ID basically becomes an OAuth2 protected resource, thus
allowing you to log in from any where you can get an access token.
(Connect folks, please feel free to chime in and tell Justin how wrong I
am.)

 -- Justin

On Wed, 2011-08-31 at 15:14 -0400, Peter Saint-Andre wrote:

I tried to help Justin off-list, but it would be nice to have a FAQ
somewhere that shows developers how to translate from OAuth 1.1 to OAuth
2.0, even just conceptually (as in, "they got rid of the legs, how do I
do two-legged auth in OAuth 2.0?!?").

On 8/26/11 5:04 PM, Justin Karneges wrote:

Hi folks,

I currently use a proprietary token approach to provide authentication
to a browser widget, and I wonder if OAuth could be used to replace
it.

Here's how the system currently works:
  - website supports authenticated users (happens via username/password
  form) - website and widget provider have a shared secret
  - the website serves a page to the browser, containing an embed of a
  remote

widget as well as a token that asserts the currently logged in user. 
the widget takes this token and performs an ajax call to the widget
provider server.  behold, the user is now logged in to the widget.

In trying to organize this into OAuth terms and roles, here is what I
come up

with:
  - resource owner: the user
  - resource server: widget provider (where the resource is generically
  "the

ability to utilize the widget")

  - client: the webpage running in the browser
  - authorization server: the website

The website essentially serves up the client application and token in
one shot, so the client never has to explicitly ask for a token. 
However, the client would then take that token and use it to access a
service.  The website and widget provider would share key material
such that token validation is possible, but it's important to note
that the two services are not owned and operated by the same people.

Does this seem right?  Normally when I think of OAuth, I think of a
user giving a third-party service access to his personal stuff, but in
the above flow I'm proposing that OAuth be used so that the user gains
access to his own stuff.  In fact, there would be no way to access his
stuff other than this approach, so it's not just about optional
third-party access.  It's the direct and only access.

Would love confirmation that OAuth is appropriate for my needs, and if
I have the roles right in that case.

Thanks,
Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------040709080102020706030101-- From justin@affinix.com Wed Aug 31 14:13:34 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F5821F8EF5 for ; Wed, 31 Aug 2011 14:13:34 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEdIhFNUkZs9 for ; Wed, 31 Aug 2011 14:13:33 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id A276921F8EF3 for ; Wed, 31 Aug 2011 14:13:33 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 81EE510AFAD; Wed, 31 Aug 2011 14:15:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=affinix.com; h=from:to:subject :date:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=affinix.com; b=K ihGpN255cq2qFxSF73RlC//1SqmaE4d9eIfqi73QPFhjbTSMMUCleBJ5yX2w7shg MA8OMCHxvQwdt5cq4IfwjZ9gvYqYkxfyCWjHL17oQ2bRQUoN4nel7t52N25cHTc2 az2es1dfwEP+LC5hkWVpwB4R2pLuzHnjZp34YoOkYk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=affinix.com; h=from:to :subject:date:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; s= affinix.com; bh=Fj5O07JWt0lwd3Yd1md2qSiH0Go=; b=ghOxIXbsEdWWejj3 j7Y+k4/qv1jqMSXi2TFszTGnwuJmfcbx1fW8zaZ2MGDeDKl+gfMGfd/iOXeULVYv g+f10q+LkcryCPjTQIF3FWpuqYa9vKjmwhrL9xoMYhyKfJxlEnvpTMVFiMWE7kPC f+gy3vxVlfVYZfu+MpzBewf74fw= Received: from purelace.localnet (andross.dreamhost.com [75.119.221.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: justin@affinix.com) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 694D110AFA1; Wed, 31 Aug 2011 14:15:02 -0700 (PDT) From: Justin Karneges To: George Fletcher Date: Wed, 31 Aug 2011 14:15:01 -0700 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.6.2; x86_64; ; ) References: <201108261604.57643.justin@affinix.com> <201108311358.07248.justin@affinix.com> <4E5EA236.9080904@aol.com> In-Reply-To: <4E5EA236.9080904@aol.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201108311415.01737.justin@affinix.com> Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SSO scenario X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 21:13:34 -0000 On Wednesday, August 31, 2011 02:05:58 PM George Fletcher wrote: > You could also use a signed JWT returned by the resource owner (web > site) to be presented to the resource server (widget provider) that the > resource server can validate (e.g. verify the signature). The JWT can > contain scopes, expiry time, etc as needed. If the widget provider needs > to access services at the resource owner, the JWT can contain an > appropriate access_token for the user. Interesting, I was not aware of JSON Web Tokens until now. Is there a relationship to OAuth? Are they at odds or serve different purposes? Justin From bcampbell@pingidentity.com Wed Aug 31 15:47:28 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C43721F8D97 for ; Wed, 31 Aug 2011 15:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTagwim1+njD for ; Wed, 31 Aug 2011 15:47:27 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6B82C21F8D94 for ; Wed, 31 Aug 2011 15:47:26 -0700 (PDT) Received: from mail-qw0-f54.google.com ([209.85.216.54]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKTl66U2Nz8RGiAZA32XFXrBAfPwOeZOaO@postini.com; Wed, 31 Aug 2011 15:48:59 PDT Received: by mail-qw0-f54.google.com with SMTP id 9so911694qwc.41 for ; Wed, 31 Aug 2011 15:48:51 -0700 (PDT) Received: by 10.224.27.80 with SMTP id h16mr786463qac.89.1314830930065; Wed, 31 Aug 2011 15:48:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.67.20 with HTTP; Wed, 31 Aug 2011 15:48:20 -0700 (PDT) In-Reply-To: <201108311415.01737.justin@affinix.com> References: <201108261604.57643.justin@affinix.com> <201108311358.07248.justin@affinix.com> <4E5EA236.9080904@aol.com> <201108311415.01737.justin@affinix.com> From: Brian Campbell Date: Wed, 31 Aug 2011 16:48:20 -0600 Message-ID: To: Justin Karneges Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SSO scenario X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 22:47:28 -0000 JWT is definitely not at odds with OAuth. I guess you could say JWT is potentially complementary in a number of ways (they can be used together but don't need to be). Though I'm not aware of any spec work around it, I suspect many will chose to use JWT as a bearer access token format. JWTs can also be used as an OAuth grant type [1] which is based on similar functionality for SAML tokens [2]. [1] http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer On Wed, Aug 31, 2011 at 3:15 PM, Justin Karneges wrote= : > On Wednesday, August 31, 2011 02:05:58 PM George Fletcher wrote: >> You could also use a signed JWT returned by the resource owner (web >> site) to be presented to the resource server (widget provider) that the >> resource server can validate (e.g. verify the signature). The JWT can >> contain scopes, expiry time, etc as needed. If the widget provider needs >> to access services at the resource owner, the JWT can contain an >> appropriate access_token for the user. > > Interesting, I was not aware of JSON Web Tokens until now. =A0Is there a > relationship to OAuth? =A0Are they at odds or serve different purposes? > > Justin > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From ve7jtb@ve7jtb.com Wed Aug 31 17:35:08 2011 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277DF21F8CDF for ; Wed, 31 Aug 2011 17:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvlIsHWyme1o for ; Wed, 31 Aug 2011 17:35:07 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37C6121F8CDE for ; Wed, 31 Aug 2011 17:35:07 -0700 (PDT) Received: by gyf3 with SMTP id 3so1276201gyf.31 for ; Wed, 31 Aug 2011 17:36:38 -0700 (PDT) Received: by 10.147.16.28 with SMTP id t28mr873831yai.37.1314837396939; Wed, 31 Aug 2011 17:36:36 -0700 (PDT) Received: from [192.168.1.213] ([190.22.119.247]) by mx.google.com with ESMTPS id b4sm129554yhe.57.2011.08.31.17.36.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Aug 2011 17:36:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_B96F68D1-363C-4DAD-8772-A66C9E9444FA"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: Date: Wed, 31 Aug 2011 21:36:30 -0300 Message-Id: <2D968B37-03C7-4EE9-8D65-0F8A0ACBE4EE@ve7jtb.com> References: <201108261604.57643.justin@affinix.com> <201108311358.07248.justin@affinix.com> <4E5EA236.9080904@aol.com> <201108311415.01737.justin@affinix.com> To: Brian Campbell X-Mailer: Apple Mail (2.1244.3) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] SSO scenario X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 00:35:08 -0000 --Apple-Mail=_B96F68D1-363C-4DAD-8772-A66C9E9444FA Content-Type: multipart/alternative; boundary="Apple-Mail=_320F0731-BEE7-4495-8683-89A781874158" --Apple-Mail=_320F0731-BEE7-4495-8683-89A781874158 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 JWT is designed to be used with OAuth and openID Connect. There is a IETF WG being created to standardize the signing and = encryption for JWT and other JSON tokens. John B. > A new IETF working group has been proposed in the Security Area. The=20= > IESG has not made any determination as yet. The following draft = charter=20 > was submitted, and is provided for informational purposes only. Please=20= > send your comments to the IESG mailing list (iesg@ietf.org) by = Tuesday,=20 > September 6, 2011 =20 >=20 > Javascript Object Signing and Encryption (jose) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > Status: Proposed Working Group > Last updated: 2011-08-18 >=20 > Chairs > TBD >=20 > Security Area Directors: > Stephen Farrell > Sean Turner >=20 > Security Area Advisor: > Sean Turner >=20 > Mailing Lists: > General Discussion: jose@ietf.org > To Subscribe: > Archive: On 2011-08-31, at 7:48 PM, Brian Campbell wrote: > JWT is definitely not at odds with OAuth. I guess you could say JWT > is potentially complementary in a number of ways (they can be used > together but don't need to be). Though I'm not aware > of any spec work around it, I suspect many will chose to use JWT as a > bearer access token format. JWTs can also be used as an OAuth grant > type [1] which is based on similar functionality for SAML tokens [2]. >=20 > [1] http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer > [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer >=20 >=20 > On Wed, Aug 31, 2011 at 3:15 PM, Justin Karneges = wrote: >> On Wednesday, August 31, 2011 02:05:58 PM George Fletcher wrote: >>> You could also use a signed JWT returned by the resource owner (web >>> site) to be presented to the resource server (widget provider) that = the >>> resource server can validate (e.g. verify the signature). The JWT = can >>> contain scopes, expiry time, etc as needed. If the widget provider = needs >>> to access services at the resource owner, the JWT can contain an >>> appropriate access_token for the user. >>=20 >> Interesting, I was not aware of JSON Web Tokens until now. Is there = a >> relationship to OAuth? Are they at odds or serve different purposes? >>=20 >> Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_320F0731-BEE7-4495-8683-89A781874158 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 JWT = is designed to be used with OAuth and openID = Connect.

There is a IETF WG being created to = standardize the signing and encryption for JWT and other JSON = tokens.

John = B.

A new IETF working = group has been proposed in the Security Area. =  The 
IESG has not = made any determination as yet. The following draft = charter 
was submitted, = and is provided for informational purposes only. = Please 
send your = comments to the IESG mailing list (iesg@ietf.org) by = Tuesday, 
September 6, = 2011 =             &n= bsp;           &nbs= p;  

Javascript = Object Signing and Encryption (jose)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
Status: Proposed = Working Group
Last updated: = 2011-08-18

Chairs
  TBD

Security Area = Directors:
  Stephen = Farrell <stephen.farrell@cs.tcd.ie>= ;
  Sean Turner = <turners@ieca.com>
=

Security Area Advisor:
  Sean Turner <turners@ieca.com>
=

Mailing Lists:
 General Discussion: jose@ietf.org
 To Subscribe: <https://www.ietf.org/m= ailman/listinfo/jose>
 Archive: <http://www.ietf.org/ma= il-archive/web/jose/>

On = 2011-08-31, at 7:48 PM, Brian Campbell wrote:

JWT = is definitely not at odds with OAuth.  I guess you could say = JWT
is potentially complementary in a number of ways (they can be = used
together but don't need to be).  Though I'm not aware
of = any spec work around it, I suspect many will chose to use JWT as = a
bearer access token format.  JWTs can also be used as an OAuth = grant
type [1] which is based on similar functionality for SAML = tokens [2].

[1] http://to= ols.ietf.org/html/draft-jones-oauth-jwt-bearer
[2] http://t= ools.ietf.org/html/draft-ietf-oauth-saml2-bearer


On Wed, = Aug 31, 2011 at 3:15 PM, Justin Karneges <justin@affinix.com> = wrote:
On Wednesday, August 31, 2011 = 02:05:58 PM George Fletcher wrote:
You could also use a signed JWT = returned by the resource owner = (web
site) to be presented to the resource server (widget = provider) that the
resource server can validate = (e.g. verify the signature). The JWT = can
contain scopes, expiry time, etc as needed. If the widget = provider needs
to access services at the = resource owner, the JWT can contain = an
appropriate access_token for the = user.

Interesting, I = was not aware of JSON Web Tokens until now.  Is there = a
relationship to OAuth? =  Are they at odds or serve different = purposes?

Justin
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

___________________________________________= ____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_320F0731-BEE7-4495-8683-89A781874158-- --Apple-Mail=_B96F68D1-363C-4DAD-8772-A66C9E9444FA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA5 MDEwMDM2MzBaMCMGCSqGSIb3DQEJBDEWBBQ56k1tvOjPQn14PJNr2EeYQMNxpzCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQC9VbpUuW93OS7Q3moEsNewDSG61vzv1euLThWNJyAyHj3T4lsRpZ/IFZZQ9Gdh3dla38VGFw7W 8m/Xv7La2fgU8gZ9062qZ+fkLDkf5QUKoCa6tK6O3bKpZFU6EAV77rjzMmmQYAPgR/vttYP/ZI4w wGIjcEyXsCtpjpRjMsGBUsA6dhhNbaCzhczlO2Q3fGHontZI3D2G2fGboG8rASKSJvPB9Xhekuzv IZfrMnx/MOHQDy0iHH/aAYC7JgtdhMEcs3nbhiDHvtRN48xxpHUpDsHfcfwH6ZTiZ3IrtDEiKLWo V4+9IOLAdk7Fx+gskQChH0iNcI+cf1s+oUODi+x8AAAAAAAA --Apple-Mail=_B96F68D1-363C-4DAD-8772-A66C9E9444FA--