From justin@affinix.com Fri Sep 2 15:49: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 90C0F21F8E04 for ; Fri, 2 Sep 2011 15:49:15 -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 Wttsn4LELP+t for ; Fri, 2 Sep 2011 15:49:15 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 121BB21F8E02 for ; Fri, 2 Sep 2011 15:49:15 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by hapkido.dreamhost.com (Postfix) with ESMTP id EA5DA17A5F0; Fri, 2 Sep 2011 15:50:50 -0700 (PDT) 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-a2.g.dreamhost.com (Postfix) with ESMTPSA id 25B6B28007B; Fri, 2 Sep 2011 15:50:42 -0700 (PDT) From: Justin Karneges To: Brian Campbell Date: Fri, 2 Sep 2011 15:50:41 -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> <201108311415.01737.justin@affinix.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109021550.41410.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: Fri, 02 Sep 2011 22:49:15 -0000 Very nice. The token format is straightforward, and not terribly unlike our current "proprietary" approach (we use CSV instead of JSON, but at the end of the day it's a bunch of fields and HMAC). Even if all we did was swap out our current format for JWT, I think that would be a big win. So, in the context of OAuth, the website could provide a JWT-formatted Authorization Grant with the page, and then the client could pass that grant to the widget provider to obtain an access token. The token could then be used to access resources at the widget provider. JWT grant fields: iss = website prn = the user logged into the website? aud = widget provider Does this seem right? One other question: can the access token step be bypassed, such that a resource can be accessed directly with the grant? Thanks Justin On Wednesday, August 31, 2011 03:48:20 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://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. 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 From jricher@mitre.org Fri Sep 2 18:13: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 3750821F8C69 for ; Fri, 2 Sep 2011 18:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 ntIFXF3Eq7bv for ; Fri, 2 Sep 2011 18:13:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5886021F8C5B for ; Fri, 2 Sep 2011 18:13:03 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B051821B0EA0; Fri, 2 Sep 2011 21:14:39 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A99F121B0153; Fri, 2 Sep 2011 21:14:39 -0400 (EDT) Received: from [172.31.16.187] (172.31.16.187) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 2 Sep 2011 21:14:39 -0400 Message-ID: <4E617F7C.3010101@mitre.org> Date: Fri, 2 Sep 2011 21:14:36 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Justin Karneges References: <201108261604.57643.justin@affinix.com> <201108311415.01737.justin@affinix.com> <201109021550.41410.justin@affinix.com> In-Reply-To: <201109021550.41410.justin@affinix.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed 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: Sat, 03 Sep 2011 01:13:04 -0000 You can actually issue a JWT as an access token (since OAuth doesn't care about the token format), so in this case the JWT would be used to get access to the widget provider. The JWT would be a pre-signed bearer token that the provider would know how to check. -- Justin On 9/2/2011 6:50 PM, Justin Karneges wrote: > Very nice. The token format is straightforward, and not terribly unlike our > current "proprietary" approach (we use CSV instead of JSON, but at the end of > the day it's a bunch of fields and HMAC). Even if all we did was swap out our > current format for JWT, I think that would be a big win. > > So, in the context of OAuth, the website could provide a JWT-formatted > Authorization Grant with the page, and then the client could pass that grant > to the widget provider to obtain an access token. The token could then be > used to access resources at the widget provider. > > JWT grant fields: > iss = website > prn = the user logged into the website? > aud = widget provider > > Does this seem right? > > One other question: can the access token step be bypassed, such that a > resource can be accessed directly with the grant? > > Thanks > Justin > > On Wednesday, August 31, 2011 03:48:20 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://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. 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 From eran@hueniverse.com Sun Sep 4 15:04: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 97E4721F8AB8 for ; Sun, 4 Sep 2011 15:04:28 -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 BLfkDWp4k1oh for ; Sun, 4 Sep 2011 15:04:27 -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 BEE1F21F8A64 for ; Sun, 4 Sep 2011 15:04:27 -0700 (PDT) Received: (qmail 31950 invoked from network); 4 Sep 2011 22:06:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Sep 2011 22:06:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 4 Sep 2011 15:06:05 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Sun, 4 Sep 2011 15:04:14 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: AcxgLAkyOqIvrAxORb6Q5RFUEAz6FALH/PHQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D0@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> <4E514770.7040405@lodderstedt.net> In-Reply-To: <4E514770.7040405@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: "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, 04 Sep 2011 22:04:28 -0000 U29ycnkgZm9yIHRoZSBsYXRlIHJlc3BvbnNlLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldF0NCj4gU2VudDogU3VuZGF5LCBBdWd1c3QgMjEsIDIwMTEgMTA6NTkgQU0NCj4gVG86 IEVyYW4gSGFtbWVyLUxhaGF2DQo+IENjOiBOaXYgU3RlaW5nYXJ0ZW47IG9hdXRoQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIERyYWZ0IDIwIGxhc3QgY2FsbCBjb21tZW50IChS ZXNvdXJjZSBPd25lcg0KPiBJbXBlcnNvbmF0aW9uKQ0KPiANCj4gSGkgRXJhbiwNCj4gPj4+IFRo aXMgaXMgc3RpbGwganVzdCBhIENTUkYgYXR0YWNrLg0KPiA+Pj4NCj4gPj4gSSB0aGluayB5b3Ug bWF5IGJlIHJpZ2h0LiBJIHN0aWxsIGJlbGlldmUgdGhpcyBwYXJ0aWN1bGFyIHN0eWxlIG9mDQo+ ID4+IGF0dGFjayBvbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXMgd29ydGggbWVudGlvbmlu ZywgYmUgaXQgaW4gaXRzDQo+ID4+IG93biBzZXBhcmF0ZSBzZWN0aW9uIG9yIHVuZGVyIHRoZSBl eGlzdGluZyBDU1JGIHNlY3Rpb24gKGFzIHlvdQ0KPiBzdWdnZXN0ZWQpLg0KPiA+IFRoaXMgaXMg bm90IGEgc3R5bGUgb2YgYXR0YWNrIGJ1dCB0ZWNobmlxdWVzIHRvIGVuaGFuY2Ugb3RoZXIgZXhw bG9pdHMsIGluIHRoaXMNCj4gY2FzZSwgQ1NSRi4gSWYgeW91IGxhY2sgQ1NSRiBwcm90ZWN0aW9u LCB0aGVuIHllcywgbGFjayBvZiByZXNvdXJjZSBvd25lcg0KPiBmb3JjZWQgaW50ZXJhY3Rpb24g d2lsbCBtYWtlIGl0IGVhc2llciB0byBleGVjdXRlLiBCdXQgdGhhdCdzIGp1c3QgYSB0aW55IHNw ZWVkDQo+IGJ1bXAgY29uc2lkZXJpbmcgdGhlIGFjdHVhbCBleHBsb2l0Lg0KPiA+DQo+ID4gSSBk b24ndCBzZWUgYW55IHJlYXNvbiB0byBpbmNsdWRlIHRoaXMgbmV3IHRleHQgYmFzZWQgb24gdGhp cyB0aHJlYXQgYW5hbHlzaXMuDQo+ID4NCj4gPiBIb3dldmVyLCB0aGlzIGRvZXNuJ3QgbWVhbiB0 aGlzIGRpc2N1c3Npb24gd2Fzbid0IHVzZWZ1bC4gV2UgZGlkIGlkZW50aWZ5DQo+IHRoZSBuZWVk IHRvIGV4cGxpY2l0bHkgZGlzY3VzcyBDU1JGIGF0dGFja3Mgb24gdGhlIGF1dGhvcml6YXRpb24g ZW5kcG9pbnQuIFdlDQo+IG5lZWQgdG8gZXhwbGljaXRseSBzZXBhcmF0ZSB0aGUgdHdvIHRhcmdl dCBvZiBDU1JGIGF0dGFja3MgKGNsaWVudCwgc2VydmVyKQ0KPiBiZWNhdXNlIHdoaWxlIHRoZSBz b2x1dGlvbiBpcyB0aGUgc2FtZSwgdGhlIGltcGxlbWVudGF0aW9uIGlzIHZlcnkgZGlmZmVyZW50 DQo+IChkdWUgdG8gdGhlIHVzZSBvZiByZWRpcmVjdGlvbnMgaW4gb25lKS4NCj4gDQo+IEkgYWdy ZWUsIHdlIHNob3VsZCBleHBsaWNpdGVseSBkb2N1bWVudCB0aGVzZSB0d28gdmFyaWFudHMgb2Yg Q1NSRiAoY2xpZW50LA0KPiBhdXRoeiBzZXJ2ZXIpLiBCdXQgSSBzdXNwZWN0IGl0J3Mgbm90IG9u bHkgQ1NSRiB3ZSBhcmUgdGFsa2luZyBhYm91dCBpbiB0aGlzDQo+IHRocmVhZCAtIGF0IGxlYXN0 IG5vdCB0ZXh0Ym9vayBDU1JGLiBMZXQgbWUgZXhwbGFpbiBteQ0KPiB0aG91Z2h0czoNCj4gDQo+ IEFzIGZhciBhcyBJIHVuZGVyc3Rvb2QsIGluIGEgdGV4dGJvb2sgQ1NSRiBhdHRhY2sgdGhlIGF0 dGFja2VyIHdvdWxkIGNyZWF0ZQ0KPiBoaXMgb3duIHJlcXVlc3RzIGluIG9yZGVyIHRvIGFidXNl IGEgdXNlcidzIHNlc3Npb24uIFRoaXMgY2FuIGJlIHByZXZlbnRlZCBieQ0KPiB1dGlsaXppbmcg c3RhbmRhcmQgQ1NSRiBjb3V0ZXJtZWFzdXJlcyAocGFnZSB0b2tlbiwgbm91bmNlLCBzaWduYXR1 cmUgYXMNCj4gcGFyYW1ldGVyIG9uIGV2ZXJ5IHJlcXVlc3QgVVJMKSwgd2hpY2ggYmluZCBVUkxz IHRvIGEgY2VydGFpbiBzZXNzaW9uLg0KDQpBIHRleHRib29rIENTUkYgYXR0YWNrIGlzIHdoZW4g YW4gYXR0YWNrZXIgY29uc3RydWN0cyBhIFVSSSBhbmQgdGhlbiBtYW5pcHVsYXRlIGEgdXNlci1h Z2VudCB3aXRoIGFuIGFjdGl2ZSBzZXNzaW9uIHRvIGNhbGwgdGhhdC4gSW4gdGhlIHNpbXBsZXN0 IGV4YW1wbGUsIGFuIGF0dGFja2VyIGNvbnN0cnVjdHMgYSBVUkkgdGhhdCB0cmFuc2ZlcnMgYSBt aWxsaW9uIGRvbGxhcnMgZnJvbSB0aGUgY3VycmVudCBhY2NvdW50IHRvIGl0cywgdGhlbiB0cmlj a3MgdGhlIHVzZXIgdG8gY2xpY2sgb24gdGhhdCBsaW5rIG9yIGF1dG9tYXRpY2FsbHkgcmVkaXJl Y3RzIHRoZSB1c2VyIHRvIHRoYXQgVVJJLiBCZWNhdXNlIHRoZSB1c2VyIGlzIGFscmVhZHkgc2ln bmVkIGluIGFuZCBoYXMgYW4gYWN0aXZlIHNlc3Npb24gdG9rZW4sIHRoZSByZXF1ZXN0IGdvZXMg dGhyb3VnaC4NCg0KVG8gcHJldmVudCBpdCwgdGhlIHJlcXVlc3QgVVJJIG11c3QgaW5jbHVkZSBh biBhcnRpZmFjdCB0aGF0IGJpbmRzIHRoZSByZXF1ZXN0IHRvIHRoZSBhY3RpdmUgc2Vzc2lvbi4g U2luY2UgdGhlIGF0dGFja2VyIGhhcyBubyB3YXkgb2YgYWNjZXNzaW5nIHRoZSBzZXNzaW9uIGlu Zm9ybWF0aW9uLCBpdCBjYW5ub3QgY29uc3RydWN0IGFzIGEgVVJJLiBJbiBwcmFjdGljZSwgdGhp cyBtZWFucyBhZGRpbmcgYSBoaWRkZW4gZm9ybSBwYXJhbWV0ZXIgdG8gdGhlIGJ1dHRvbiB3aXRo IHNvbWUgaGFzaCBvZiB0aGUgc2Vzc2lvbiBpbmZvcm1hdGlvbiB0aGF0IHRoZSBzZXJ2ZXIgY2Fu IHZlcmlmeS4NCg0KPiBCdXQgd2h5IHNob3VsZCB0aGUgYXR0YWNrZXIgY3JlYXRlIHJlcXVlc3Rz IGV0IGFsbD8gQWxsIGhlIG5lZWRzIGlzIGFscmVhZHkNCj4gcHJvdmlkZWQgYnkgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIHRoZW1zZWx2ZXMuIFRoZSBtYWxpY2lvdXMgY2xpZW50IGNhbg0KPiBk b3dubG9hZCB0aGUgSFRNTCBwYWdlcyBjb21wcmlzaW5nIHRoZSBhdXRob3JpemF0aW9uIGZsb3cg ZnJvbSB0aGUgYXV0aHoNCj4gc2VydmVyIGFuZCB1c2UgdGhlIGVtYmVkZGVkIFVSTHMgdG8gaXNz dWUgdGhlIHJlcXVlc3RzIHdoaWNoIG5vcm1hbHkNCj4gd291bGQgaGF2ZSBiZWVuIGlzc3VlZCBi eSB0aGUgcmVzb3VyY2Ugb3duZXIgaGVyc2VsZiAodXNpbmcgdGhlIHVzZSBhZ2VudA0KPiBpbmRl ZWQpLiBJdCdzIG1vcmUgb3IgbGVzcyB0aGUgcHVzaCBvbiBhICJJIGFncmVlIg0KPiBidXR0b24g d2UgYXJlIHRhbGtpbmcgYWJvdXQuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBtYXkgYWRkIGEg cGFnZSB0b2tlbg0KPiB0byB0aGUgcmVzcGVjdGl2ZSBmb3JtIFVSTC4gQnV0IGl0IGRvZXMgbm90 IG1hdHRlciBzaW5jZSB0aGUgY2xpZW50IGp1c3QgdXNlcw0KPiB0aGUgYXV0aHogc2VydmVyIG1h bnVmYWN0dXJlZCBVUkwgdG8gcG9zdCB0aGUgZm9ybS4NCg0KT2YgY291cnNlIGl0IG1hdHRlcnMu DQoNClRoZSBvbmx5IHdheSB0aGUgYXR0YWNrZXIgY2FuIGdldCBhY2Nlc3MgaXMgYnkgY2FsbGlu ZyB0aGUgJ0kgYWdyZWUnIGJ1dHRvbiBhY3Rpb24gdmlhIGFuIGFjdGl2ZSB1c2VyIHNlc3Npb24u IFRoZSBhdHRhY2tlciBjYW5ub3QgYWNjZXNzIHRoZSBoaWRkZW4gZm9ybSB2YWx1ZSB3aXRoIHRo ZSBzZXNzaW9uIGhhc2ggKG9yIHdoYXRldmVyIHRoZSBzZXJ2ZXIgaXMgdXNpbmcgZm9yIENTUkYg cHJvdGVjdGlvbikuIFNvIHdoYXRldmVyIFVSSSBpdCBjb25zdHJ1Y3RzIHdpbGwgbm90IHdvcmsg d2hlbiBjYWxsZWQgd2l0aCB0aGUgYWN0aXZlIHVzZXIgc2Vzc2lvbi4NCg0KPiBTbyBsZXQncyBh c3N1bWUgdGhlIGF0dGFja2VyIGhhcyB0byBwcm9ncmFtbWF0aWNhbGx5IGhhbmRsZSBIVE1MIGZv cm1zIHRoZQ0KPiBhdXRob3JpemF0aW9uIHNlcnZlciBkZWxpdmVycyB0byB0aGUgdXNlciBhZ2Vu dC4gQXMgeW91IGNvcnJlY3RseSBwb2ludGVkIG91dCwNCj4gdGhlIHByZS1yZXF1aXNpdGUgZm9y IHN1Y2ggYW4gYXR0YWNrIHRvIHN1Y2NlZWQgaXMgdGhhdCB0aGUgcmVzb3VyY2Ugb3duZXINCj4g bXVzdCBiZSBhdXRoZW50aWNhdGVkIHNvbWVob3csIGUuZy4gYmFzZWQgb24gYSBzZXNzaW9uIGNv b2tpZS4gV2hpY2ggYWxzbw0KPiBtZWFucywgd2UgYXJlIHRhbGtpbmcgYWJvdXQgY2xpZW50cyBy dW5uaW5nIG9uIHRoZSB2aWN0aW0ncyBkZXZpY2UsIHdpdGhpbiB0aGUNCj4gdXNlciBhZ2VudCBv ciBhcyBuYXRpdmUgYXBwLg0KPiANCj4gSSBzZWUgdGhlIGZvbGxvd2luZyBwb3NzaWJsZSBzY2Vu YXJpb3M6DQo+IA0KPiAxKSBleHRlcm5hbCBzeXN0ZW0gYnJvd3NlciAtIFRoZSBhcHAgY291bGQg dXRpbGl6ZSBhbiBleGlzdGluZyBzZXNzaW9uIHdpdGhpbg0KPiB0aGUgc3lzdGVtIGJyb3dzZXIg b24gdGhlIHZpY3RpbSdzIGRldmljZS4gSXQgY291bGQgdGhlbiByZW1vdGUgY29udHJvbCBhDQo+ IGJyb3dzZXIgd2luZG93LCBlLmcuIHVzaW5nIGxvdy1sZXZlbCBvcGVyYXRpbmcgc3lzdGVtIG1l c3NhZ2VzICgic2VuZA0KPiBtb3VzZSBjbGljayIpIG9yIGNvbXBvbmVudCB0ZWNobmlxdWVzIHN1 Y2ggYXMgQWN0aXZlWC4gVGhlcmUgYXJlIHRvb2xzDQo+IGF2YWlsYWJsZSB0byBjcmVhdGUgbWFj cm9zIHdoaWNoIGF1dG9tYXRpY2FsbHkgY29udHJvbCBhbmQgb2J0YWluIGRhdGEgZnJvbQ0KPiBz dWNoIGFwcGxpY2F0aW9ucy4gU28gdGhpcyBzaG91bGQgYmUgZmVhc2libGUuDQo+IA0KPiAyKSBp bnRlcm5hbCBicm93c2VyIChjcm9zcy1icm93c2VyIGNvb2tpZXMpIC0gSWYgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIHVzZXMNCj4gY3Jvc3MtYnJvd3NlciBjb29raWUgdGVjaG5pcXVlcywgc3Vj aCBhcyBmbGFzaCBjb29raWVzLCB0aGUgYXR0YWNrZXIgY291bGQNCj4gaW5zdGFudGlhdGUgYW4g aW50ZXJuYWwgKGludmlzaWJsZSkgYnJvd3NlciBhbmQgdHJ5IHRvIHV0aWxpemUgYSBzZXNzaW9u DQo+IGFzc29jaWF0ZWQgd2l0aCBzdWNoIGEgY29va2llLiBJIGFzc3VtZSBjb250cm9sbGluZyBz dWNoIGEgYnJvd3NlciBpbnN0YW5jZQ0KPiB3aWxsIGJlIGV2ZW4gc2ltcGxlciB0aGVuIGluICgx KS4NCj4gDQo+IDMpIGludGVybmFsIGJyb3dzZXIgKHNpbGVudCBhdXRoeiBmbG93KSAtIFRoaXMg aXMgYSBzY2VuYXJpbyB3aGVyZSB0aGUgYXR0YWNrZXINCj4gaXMgdW5hYmxlIHRvIGFidXNlIGFu IGV4aXN0aW5nIHNlc3Npb24gb24gdGhlIGRldmljZS4gSXQgY291bGQgaW5zdGVhZCBjcmVhdGUN Cj4gYW4gaW50ZXJuYWwgYnJvd3NlciBhbmQgcGVyZm9ybSBhbiBhdXRob3JpemF0aW9uIGZsb3cg d2l0aCB0aGUgcmVzb3VyY2UNCj4gb3duZXIgZm9yIG9uZSBwYXJ0aWN1bGFyIHNjb3BlLiBVc2lu ZyB0aGUgc2FtZSBicm93c2VyIGluc3RhbmNlIGFuZCBiYXNlZA0KPiBvbiB0aGUgY29va2llcyBv YnRhaW5lZCBpbiB0aGUgZmlyc3QgcnVuLCBpdCBjb3VsZCBzaWxlbnRseSBwZXJmb3JtIGFkZGl0 aW9uYWwNCj4gYXV0aG9yaXphdGlvbiBmbG93cyBmb3Igb3RoZXIgc2NvcGVzLg0KPiANCj4gNCkg aW50ZXJuYWwgYnJvd3NlciAobm9uLWludGVyYWN0aXZlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMp IC0gVGhlcmUgYXJlDQo+IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgYXZhaWxhYmxlIHcvbyB0aGUg bmVlZCBmb3IgdXNlci1pbnRlcmFjdGlvbiwgZm9yDQo+IGV4YW1wbGVzIFNJTSBjYXJkIGF1dGhl bnRpY2F0aW9uIG9yIGNlcnRpZmljYXRlLWJhc2VkIGF1dGhlbnRpY2F0aW9uLg0KPiBUaGUgYXR0 YWNrZXIgY291bGQgdXRpbGl6ZSBhbiBpbnRlcm5hbCwgaW52aXNpYmxlIGJyb3dzZXIgaW5zdGFu Y2UgaW4NCj4gY29tYmluYXRpb24gd2l0aCBzdWNoIGFuIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBp biBvcmRlciB0byBwZXJmb3JtIHRoZQ0KPiBhdXRob3JpemF0aW9uIHByb2Nlc3MuDQo+IA0KPiBJ J20gbm90IHN1cmUgd2hldGhlciB0aGUgc2NlbmFyaW9zIGRlc2NyaWJlZCBhYm92ZSBjYW4gYmUg Y2xhc3NpZmllZCBhcw0KPiBDU1JGLg0KDQpJJ20gaGF2aW5nIGEgaGFyZCB0aW1lIGZvbGxvd2lu ZyBhbGwgdGhlc2Ugc2NlbmFyaW9zLiBCdXQgdGhlIGltcG9ydGFudCBwYXJ0IGlzIHRoYXQgT0F1 dGggYXNzdW1lcyB0aGUgJ3VzZXItYWdlbnQnIGlzIGEgY29tcGxpYW50IGFuZCBzZWN1cmUgd2Vi IGJyb3dzZXIuIElmIHRoZSB1c2VyLWFnZW50IGRvZXMgbm90IGVuZm9yY2UgY29va2llIGJvdW5k YXJpZXMsIFhTUywgQ09SUyBwb2xpY3ksIGV0Yy4gdGhlcmUgaXNuJ3QgbXVjaCB3ZSBjYW4gZG8u IEluIG90aGVyIHdvcmRzLCBpZiB0aGUgdXNlciBpbnN0YWxscyBhIHBvb3JseSBkZXNpZ24gbmF0 aXZlIGFwcGxpY2F0aW9uIHdoaWNoIGhhcyBpdHMgb3duIHVzZXItYWdlbnQgaW1wbGVtZW50YXRp b24gb3BlbmVkIHRvIGtub3duIHdlYiBhdHRhY2tzLCBhbGwgYmV0cyBhcmUgb2ZmLg0KDQpUaGUg c2VjdXJpdHkgbW9kZWwgYmVoaW5kIGFsbCB0aGVzZSBpcyBwcmV0dHkgc2ltcGxlLiBUaGUgYWN0 aXZlIHVzZXIgc2Vzc2lvbiBoYXMgdG8gYmUgcHJvdGVjdGVkIGZyb20gYW55IGV4dGVybmFsIGFj Y2VzcyBieSBhdHRhY2tlcnMgYW5kIGVuZm9yY2Ugc2FtZS1vcmlnaW4gcG9saWN5Lg0KDQpJIHN0 aWxsIGRvbid0IHNlZSB0aGUgbmVlZCB0byBhZGQgdGhlIHByb3Bvc2VkIHNlY3Rpb24uDQoNCkVI TA0KDQoNCg0K From eran@hueniverse.com Sun Sep 4 15:13: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 05E0B21F8AB9 for ; Sun, 4 Sep 2011 15:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=-0.258, 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 1cXqctHDOQzQ for ; Sun, 4 Sep 2011 15:13:11 -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 5CFED21F8ACA for ; Sun, 4 Sep 2011 15:13:11 -0700 (PDT) Received: (qmail 13903 invoked from network); 4 Sep 2011 22:14:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Sep 2011 22:14:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 4 Sep 2011 15:14:52 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Sun, 4 Sep 2011 15:13:01 -0700 Thread-Topic: [OAUTH-WG] redirect uri validation Thread-Index: AcxbjCpSWRw59kJJSwGr4PITrEZuDgPwu/VA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345021F37877@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DAAEA.7090304@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E498313.3080009@lodderstedt.net> In-Reply-To: <4E498313.3080009@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: "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: Sun, 04 Sep 2011 22:13:12 -0000 VGhhdCdzIG5vdCBjb21wbGV0ZS4gQSB2YWxpZCByZWRpcmVjdGlvbiBVUkkgaXMgbm90IGVub3Vn aCB0byB2ZXJpZnkgY2xpZW50IGlkZW50aXR5IGF0IHRoZSB0aW1lIGl0IGlzIHByZXNlbnRlZCwg YnV0IGl0IGlzIGVub3VnaCBpbiBtYW55IGNhc2VzIHRvIHByZXZlbnQgbGVha2luZyBjcmVkZW50 aWFscyBsYXRlciBvbi4NCg0KSG93IGFib3V0IGEgc2xpZ2h0IGNoYW5nZToNCg0KICAgICAgICAg IEEgdmFsaWQgcmVkaXJlY3Rpb24gVVJJIGlzIG5vdCBzdWZmaWNpZW50IHRvIHZlcmlmeSB0aGUg Y2xpZW50J3MgaWRlbnRpdHkgd2hlbiBhc2tpbmcgZm9yDQogICAgICAgICAgZW5kLXVzZXIgYXV0 aG9yaXphdGlvbiwgYnV0IGNhbiBiZSB1c2VkIHRvIHByZXZlbnQgZGVsaXZlcmluZyBjcmVkZW50 aWFscyB0byBhDQogICAgICAgICAgY291bnRlcmZlaXQgY2xpZW50IGFmdGVyIG9idGFpbmluZyBl bmQtdXNlciBhdXRob3JpemF0aW9uLg0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXRdDQo+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDE1LCAyMDExIDE6MzYgUE0NCj4gVG86 IEVyYW4gSGFtbWVyLUxhaGF2DQo+IENjOiBlcmFuQHNsZWQuY29tOyBvYXV0aEBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSByZWRpcmVjdCB1cmkgdmFsaWRhdGlvbg0KPiANCj4g SGkgRXJhbiwNCj4gDQo+IEFtIDE1LjA4LjIwMTEgMDg6NTcsIHNjaHJpZWIgRXJhbiBIYW1tZXIt TGFoYXY6DQo+ID4gQWRkZWQgdG8gMS40LjI6DQo+ID4NCj4gPiAgICAgICAgICAgICAgV2hlbiBp c3N1aW5nIGFuIGltcGxpY2l0IGdyYW50LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZG9lcyBu b3QNCj4gYXV0aGVudGljYXRlIHRoZQ0KPiA+ICAgICAgICAgICAgICBjbGllbnQgYW5kIFtbaW4g c29tZSBjYXNlc11dLCB0aGUgY2xpZW50IGlkZW50aXR5IFtbY2FuXV0gYmUgdmVyaWZpZWQgdmlh DQo+IHRoZSByZWRpcmVjdGlvbiBVUkkNCj4gPiAgICAgICAgICAgICAgdXNlZCB0byBkZWxpdmVy IHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhlIGNsaWVudC4gVGhlIGFjY2VzcyB0b2tlbiBtYXkNCj4g YmUgZXhwb3NlZCB0byB0aGUNCj4gPiAgICAgICAgICAgICAgcmVzb3VyY2Ugb3duZXIgb3Igb3Ro ZXIgYXBwbGljYXRpb25zIHdpdGggYWNjZXNzIHRvIHRoZSByZXNvdXJjZQ0KPiBvd25lcidzIHVz ZXItYWdlbnQuDQo+ID4NCj4gPiBIb3BlIHRoaXMgaXMgc3VmZmljaWVudC4NCj4gDQo+IFdoYXQg ZG8geW91IHdhbnQgdG8gZXhwcmVzcz8gQ2xpZW50cyBjYW4gc29tZXRpbWVzIGJlIHZlcmlmaWVk IHZpYQ0KPiByZWRpcmVjdGlvbiBVUkk/DQo+IA0KPiBNeSBpbnRlbnRpb24gd2FzIHRvIHBvaW50 IG91dCB0aGF0IGFuIGludmFsaWQgcmVkaXJlY3QgVVJJIGlzIGEgY291bnRlci0NCj4gZXZpZGVu Y2UgZm9yIGEgY2xpZW50J3MgaWRlbnRpdHkgYnV0IGEgdmFsaWQgcmVkaXJlY3QgVVJJIGlzIF9u b3RfIGFuIGV2aWRlbmNlDQo+IGZvciBpdHMgaWRlbnRpdHkuDQo+IA0KPiBJIHdvdWxkIHN1Z2dl c3QgdG8gYWRkIHRoZSB0ZXh0IGJlbG93IHRvIHNlY3Rpb24gMTAuMS4sIGxhc3QgcGFyYWdyYXBo IGFmdGVyDQo+IHRoZSBzZW50ZW5jZQ0KPiANCj4gIkZvcg0KPiAgICAgZXhhbXBsZSwgYnkgcmVx dWlyaW5nIHRoZSByZWdpc3RyYXRpb24gb2YgdGhlIGNsaWVudCByZWRpcmVjdGlvbiBVUkkNCj4g ICAgIG9yIGVubGlzdGluZyB0aGUgcmVzb3VyY2Ugb3duZXIgdG8gY29uZmlybSBpZGVudGl0eS4i DQo+IA0KPiBwcm9wb3NlZCB0ZXh0Og0KPiANCj4gUGxlYXNlIG5vdGU6IHdoaWxlIGFuIGludmFs aWQgcmVkaXJlY3Rpb24gVVJJIGluZGljYXRlcyBhIGNvdW50ZXJmZWl0IGNsaWVudCwgYQ0KPiB2 YWxpZCByZWRpcmVjdGlvbiBVUkkgaXMgbm90IHN1ZmZpY2llbnQgdG8gY29uZmlybSBhIGNsaWVu dCdzIGlkZW50aXR5Lg0KPiANCj4gcmVnYXJkcywNCj4gVG9yc3Rlbi4NCj4gDQo+IA0KPiA+DQo+ ID4gRUhMDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTog b2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u DQo+ID4+IEJlaGFsZiBPZiBFcmFuIEhhbW1lci1MYWhhdg0KPiA+PiBTZW50OiBTdW5kYXksIEF1 Z3VzdCAxNCwgMjAxMSAxMTowOSBQTQ0KPiA+PiBUbzogVG9yc3RlbiBMb2RkZXJzdGVkdA0KPiA+ PiBDYzogdG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU7IG9hdXRoQGlldGYub3JnDQo+ID4+ IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHJlZGlyZWN0IHVyaSB2YWxpZGF0aW9uDQo+ID4+DQo+ ID4+IFdoZXJlIHdvdWxkIHlvdSBzdWdnZXN0IEkgYWRkIHRoaXM/DQo+ID4+DQo+ID4+IEVITA0K PiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+IEZyb206IFRvcnN0 ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0NCj4gPj4+IFNl bnQ6IE1vbmRheSwgSnVseSAyNSwgMjAxMSAxMDo0MiBBTQ0KPiA+Pj4gVG86IEVyYW4gSGFtbWVy LUxhaGF2DQo+ID4+PiBDYzogdG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU7IG9hdXRoQGll dGYub3JnDQo+ID4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSByZWRpcmVjdCB1cmkgdmFsaWRh dGlvbg0KPiA+Pj4NCj4gPj4+IEhpIEVyYW4sDQo+ID4+Pg0KPiA+Pj4+Pj4gT0F1dGggMS4wIHdh cyBoaWdobHkgY3JpdGljaXplZCBmb3IgZmFpbGluZyB0byBhZGRyZXNzIGNsaWVudA0KPiA+Pj4+ Pj4gaWRlbnRpdHkgaW4gcHVibGljIGNsaWVudHMuIEkgYmVsaWV2ZSBPQXV0aCAyLjAgb2ZmZXJz IGEgbXVjaA0KPiA+Pj4+Pj4gYmV0dGVyIHN0b3J5LCB3aXRoaW4gdGhlIGJvdW5kYXJpZXM+b2Yg d2hhdOKAmXMgcG9zc2libGUgdG9kYXkuDQo+ID4+Pj4+IEFncmVlZC4gSSB0aGluayB3ZSBtdXN0 IGhvbmVzdGx5IGRpc2N1c3MgdGhlIHZhbHVlIG9mIGNsaWVudA0KPiA+Pj4+PiBhdXRoZW50aWNh dGlvbi9pZGVudGlmaWNhdGlvbiBpdHNlbGYuIEkgcGVyc29uYWxseSB0aGluayBpdCBpcw0KPiA+ Pj4+PiBvdmVyLWVtcGhhemlzZWQgcmlnaHQgbm93LiBUaGUgc3RyZW5ndGggb2YgT0F1dGggMi4w IGlzIHRoYXQgaXQNCj4gPj4+Pj4gYWxsb3dzIHNvbHV0aW9ucyB3aGVyZSBuZWl0aGVyIGNsaWVu dCBub3IgcmVzb3VyY2Ugc2VydmVyIGhhdmUNCj4gPj4+Pj4gYWNjZXNzIG9yDQo+ID4+PiBkbyBz dG9yZSBlbmQtdXNlciBjcmVkZW50aWFscy4NCj4gPj4+Pj4gQ2xpZW50IGF1dGhlbnRpY2F0aW9u IGlzIG5pY2UgYnV0IG5vdCB0aGUgbWFpbiBmZWF0dXJlLg0KPiA+Pj4+IERvIHlvdSBoYXZlIGFu eSBzcGVjaWZpYyBzdWdnZXN0aW9ucyBub3QgYWxyZWFkeSBtZW50aW9uZWQgb24gdGhlDQo+IGxp c3Q/DQo+ID4+PiBJIHdvdWxkIHN1Z2dlc3QgdG8gbWVudGlvbiB0aGF0IHdoaWxlIGFuIGludmFs aWQgcmVkaXJlY3RfdXJpDQo+ID4+PiBpbmRpY2F0ZXMgYSBjb3VudGVyZmVpdCBjbGllbnRzIGEg dmFsaWQgcmVkaXJlY3QgZG9lcyBub3QgcHJvdmUgdGhlDQo+ID4+PiBjYWxsaW5nDQo+ID4+IGNs aWVudCdzIGlkZW50aXR5Lg0KPiA+Pj4gcmVnYXJkcywNCj4gPj4+IFRvcnN0ZW4uDQo+ID4+Pg0K PiA+Pj4NCj4gPj4+PiBFSEwNCj4gPj4+Pg0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4+ Pj4gT0F1dGhAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+PiBPQXV0aEBpZXRmLm9yZw0K PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= From eran@hueniverse.com Sun Sep 4 15:28: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 2644021F8A64 for ; Sun, 4 Sep 2011 15:28:38 -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 fMGXKKNNpJLC for ; Sun, 4 Sep 2011 15:28: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 904C021F8512 for ; Sun, 4 Sep 2011 15:28:37 -0700 (PDT) Received: (qmail 26013 invoked from network); 4 Sep 2011 22:30:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Sep 2011 22:30:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 4 Sep 2011 15:30:20 -0700 From: Eran Hammer-Lahav To: "Richer, Justin P." , "Lu, Hui-Lan (Huilan)" , Brian Campbell Date: Sun, 4 Sep 2011 15:28:29 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxNWiAmwaoXWhpRRLSIm3Z69CEQXANudKkQALSSvmAAAWgcIAAexYj7Azq/y7A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D3@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> 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: Sun, 04 Sep 2011 22:28:38 -0000 New tweak: The security ramifications of allowing unauthenticated access b= y public clients to the token endpoint, as well as the issuance of refresh tokens to pu= blic clients MUST be taken into consideration. EHL > -----Original Message----- > From: Richer, Justin P. [mailto:jricher@mitre.org] > Sent: Friday, August 19, 2011 4:56 AM > To: Eran Hammer-Lahav; Lu, Hui-Lan (Huilan); Brian Campbell > Cc: oauth > Subject: RE: [OAUTH-WG] treatment of client_id for authentication and > identification >=20 > I find the original text clearer, myself. >=20 > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran > Hammer-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 > identification >=20 > > -----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. >=20 > "unless its value is an empty string". Do people read this new text to me= an > OPTIONAL if not empty? >=20 > > > Added to 3.2.1: > > > > > > A public client that was not issued a client password MAY= use the > > > 'client_id' request parameter to identify itself when sen= ding > > > requests to the token endpoint. > > > > It is difficult to parse the last sentence of 3.2.1: "The security > > ramifications 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Sep 4 16:19: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 4BC9921F8ABC for ; Sun, 4 Sep 2011 16:19:44 -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 BQOXWvSUBRuD for ; Sun, 4 Sep 2011 16:19: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 F3B3821F8AC9 for ; Sun, 4 Sep 2011 16:19:41 -0700 (PDT) Received: (qmail 12046 invoked from network); 4 Sep 2011 23:21:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Sep 2011 23:21:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 4 Sep 2011 16:21:23 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , Anthony Nadalin , Torsten Lodderstedt Date: Sun, 4 Sep 2011 16:19:32 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxjWshx+81E1zxCT4uviHHsUmJj0wH/K/3g Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D6@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> <1314299478.57208.YahooMailNeo@web31812.mail.mud.yahoo.com> In-Reply-To: <1314299478.57208.YahooMailNeo@web31812.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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, 04 Sep 2011 23:19:44 -0000 VGhpcyBpcyBteSBwcm9wb3NlZCB0ZXh0IGZvciAtMjEgKGJhc2VkIG9uIEJpbGwncyB0ZXh0IGFz IGEgc3RhcnRpbmcgcG9pbnQpOg0KDQoxMC4xMi4gIENyb3NzLVNpdGUgUmVxdWVzdCBGb3JnZXJ5 DQoNCiAgIENyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IChDU1JGKSBpcyBhbiBleHBsb2l0IGlu IHdoaWNoIGFuIGF0dGFja2VyDQogICBjYXVzZXMgdGhlIHVzZXItYWdlbnQgb2YgYSB2aWN0aW0g ZW5kLXVzZXIgdG8gZm9sbG93IGEgbWFsaWNpb3VzIFVSSQ0KICAgKGUuZy4gcHJvdmlkZWQgdG8g dGhlIHVzZXItYWdlbnQgYXMgYSBtaXNsZWFkaW5nIGxpbmssIGltYWdlLCBvcg0KICAgcmVkaXJl Y3Rpb24pIHRvIGEgdHJ1c3Rpbmcgc2VydmVyICh1c3VhbGx5IGVzdGFibGlzaGVkIHZpYSB0aGUN CiAgIHByZXNlbmNlIG9mIGEgdmFsaWQgc2Vzc2lvbiBjb29raWUpLg0KDQogICBBIENTUkYgYXR0 YWNrIGFnYWluc3QgdGhlIGNsaWVudCdzIHJlZGlyZWN0aW9uIFVSSSBhbGxvd3MgYW4gYXR0YWNr ZXINCiAgIHRvIGluamVjdCB0aGVpciBvd24gYXV0aG9yaXphdGlvbiBjb2RlIG9yIGFjY2VzcyB0 b2tlbiwgd2hpY2ggY2FuDQogICByZXN1bHQgaW4gdGhlIGNsaWVudCB1c2luZyBhbiBhY2Nlc3Mg dG9rZW4gYXNzb2NpYXRlZCB3aXRoIHRoZQ0KICAgYXR0YWNrZXIncyBwcm90ZWN0ZWQgcmVzb3Vy Y2VzIHJhdGhlciB0aGFuIHRoZSB2aWN0aW0ncyAoZS5nLiBzYXZlDQogICB0aGUgdmljdGltJ3Mg YmFuayBhY2NvdW50IGluZm9ybWF0aW9uIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlDQogICBjb250 cm9sbGVkIGJ5IHRoZSBhdHRhY2tlcikuDQoNCiAgIFRoZSBjbGllbnQgTVVTVCBpbXBsZW1lbnQg Q1NSRiBwcm90ZWN0aW9uIGZvciBpdHMgcmVkaXJlY3Rpb24gVVJJLg0KICAgVGhpcyBpcyB0eXBp Y2FsbHkgYWNjb21wbGlzaGVkIGJ5IHJlcXVpcmluZyBhbnkgcmVxdWVzdCBzZW50IHRvIHRoZQ0K ICAgcmVkaXJlY3Rpb24gVVJJIGVuZHBvaW50IHRvIGluY2x1ZGUgYSB2YWx1ZSB0aGF0IGJpbmRz IHRoZSByZXF1ZXN0IHRvDQogICB0aGUgdXNlci1hZ2VudCdzIGF1dGhlbnRpY2F0ZWQgc3RhdGUg KGUuZy4gYSBoYXNoIG9mIHRoZSBzZXNzaW9uDQogICBjb29raWUgdXNlZCB0byBhdXRoZW50aWNh dGlvbiB0aGUgdXNlci1hZ2VudCkuICBUaGUgY2xpZW50IFNIT1VMRA0KICAgdXRpbGl6ZSB0aGUg InN0YXRlIiByZXF1ZXN0IHBhcmFtZXRlciB0byBkZWxpdmVyIHRoaXMgdmFsdWUgdG8gdGhlDQog ICBhdXRob3JpemF0aW9uIHNlcnZlciB3aGVuIG1ha2luZyBhbiBhdXRob3JpemF0aW9uIHJlcXVl c3QuDQoNCiAgIE9uY2UgYXV0aG9yaXphdGlvbiBoYXMgYmVlbiBvYnRhaW5lZCBmcm9tIHRoZSBl bmQtdXNlciwgdGhlDQogICBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIGVuZC11 c2VyJ3MgdXNlci1hZ2VudCBiYWNrIHRvIHRoZQ0KICAgY2xpZW50IHdpdGggdGhlIHJlcXVpcmVk IGJpbmRpbmcgdmFsdWUgY29udGFpbmVkIGluIHRoZSAic3RhdGUiDQogICBwYXJhbWV0ZXIuICBU aGUgYmluZGluZyB2YWx1ZSBlbmFibGVzIHRoZSBjbGllbnQgdG8gdmFsaWRhdGUgdGhlDQogICB2 YWxpZGl0eSBvZiB0aGUgcmVxdWVzdCBieSBtYXRjaGluZyB0aGUgYmluZGluZyB2YWx1ZSB0byB0 aGUgdXNlci0NCiAgIGFnZW50J3MgYXV0aGVudGljYXRlZCBzdGF0ZS4gIFRoZSBiaW5kaW5nIHZh bHVlIHVzZWQgZm9yIENTUkYNCiAgIHByb3RlY3Rpb24gTVVTVCBjb250YWluIGEgbm9uLWd1ZXNz YWJsZSB2YWx1ZSwgYW5kIHRoZSB1c2VyLWFnZW50J3MNCiAgIGF1dGhlbnRpY2F0ZWQgc3RhdGUg KGUuZy4gc2Vzc2lvbiBjb29raWUsIEhUTUw1IGxvY2FsIHN0b3JhZ2UpIE1VU1QNCiAgIGJlIGtl cHQgaW4gYSBsb2NhdGlvbiBhY2Nlc3NpYmxlIG9ubHkgdG8gdGhlIGNsaWVudCBhbmQgdGhlIHVz ZXItDQogICBhZ2VudCAoaS5lLiwgcHJvdGVjdGVkIGJ5IHNhbWUtb3JpZ2luIHBvbGljeSkuDQoN CiAgIEEgQ1NSRiBhdHRhY2sgYWdhaW5zdCB0aGUgYWdhaW5zdCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIncw0KICAgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBjYW4gcmVzdWx0IGluIGFuIGF0dGFj a2VyIG9idGFpbmluZyBlbmQtdXNlcg0KICAgYXV0aG9yaXphdGlvbiBmb3IgYSBtYWxpY2lvdXMg Y2xpZW50IHdpdGhvdXQgaW52b2x2aW5nIG9yIGFsZXJ0aW5nDQogICB0aGUgZW5kLXVzZXIuDQoN CiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGltcGxlbWVudCBDU1JGIHByb3RlY3Rp b24gZm9yIGl0cw0KICAgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgYW5kIGVuc3VyZSB0aGF0IGEg bWFsaWNpb3VzIGNsaWVudCBjYW5ub3QNCiAgIG9idGFpbiBhdXRob3JpemF0aW9uIHdpdGhvdXQg dGhlIGF3YXJlbmVzcyBhbmQgZXhwbGljaXQgY29uc2VudCBvZg0KICAgdGhlIHJlc291cmNlIG93 bmVyLg0KDQpFSEwNCg0KDQpGcm9tOiBXaWxsaWFtIEouIE1pbGxzIFttYWlsdG86d21pbGxzQHlh aG9vLWluYy5jb21dIA0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyNSwgMjAxMSAxMjoxMSBQTQ0K VG86IEFudGhvbnkgTmFkYWxpbjsgRXJhbiBIYW1tZXItTGFoYXY7IFRvcnN0ZW4gTG9kZGVyc3Rl ZHQNCkNjOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBBdXRoIENvZGUgU3dhcCBBdHRhY2sNCg0KSSBoYWQgcHJvcG9zZWQgdGV4dCwgYW5kIEknbGwg cmVwcmlzZSBpdCBoZXJlIHdpdGggYSBtb2RpZmljYXRpb24gdG8gbWFrZSB0aGUgYXV0aG9yaXph dG9uIHNlcnZlciByZWxhdGVkIGV4cGxpY2l0Lg0KDQoxMC4xMi7CoMKgQ3Jvc3MtU2l0ZSBSZXF1 ZXN0IEZvcmdlcnkgDQoNCkNyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IChDU1JGKSBpcyBhbiBh dHRhY2sgd2hlcmVieSBtYWxpY2lvdXMgVVJMcyBhcmUgc2VudCB0byB0aGUgdXNlci1hZ2VudCBv ZiBhbiBlbmQgdXNlciAoZ2VuZXJhbGx5IGFzIGhpZGRlbiBsaW5rcyBvciBpbWFnZXMpIGFuZCB0 cmFuc21pdHRlZCBmcm9tIHRoZSB1c2VyLWFnZW50IHRoZSBzZXJ2ZXIgdHJ1c3RzIG9yIGhhcyBh dXRoZW50aWNhdGVkLiBUaGUgbW9zdCBjb21tb25seSBleHBsb2l0ZWQgbWVjaGFuaXNtIGZvciB0 aGlzIGlzIGNyZWRlbnRpYWxzIGhlbGQgaW4gY29va2llcyBhdXRvbWF0aWNhbGx5IHByZXNlbnRl ZCBieSBhIHdlYiBicm93c2VyLsKgIENTUkYgYXR0YWNrcyBhZ2FpbnN0IHRoZSBjbGllbnQncyBy ZWRpcmVjdGlvbiBVUkkgYWxsb3cgYW4gYXR0YWNrZXIgdG8gaW5qZWN0IHRoZWlyIG93biBhdXRo b3JpemF0aW9uIGNvZGUgb3IgYWNjZXNzIHRva2VuLCB3aGljaCBjYW4gcmVzdWx0IGluIHRoZSBj bGllbnQgdXNpbmcgYW4gYWNjZXNzIHRva2VuIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXR0YWNrZXIn cyBhY2NvdW50IHJhdGhlciB0aGFuIHRoZSB2aWN0aW0ncy7CoCBDU1JGIGF0dGFja3MgYXJlIGFs c28gcG9zc2libGUgYWdhaW5zdCBhbiBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJlc3VsdGluZyBp biBkZWxpdmVyaW5nIGEgdXNlciBjcmVkZW50aWFsIHRvIGFuIGF0dGFja2VyLiDCoCANCg0KQ2xp ZW50IGFwcGxpY2F0aW9ucyBNVVNUIGltcGxlbWVudCBDU1JGIHByb3RlY3Rpb24gZm9yIHRoZSBy ZWRpcmVjdGlvbiBVUkkuwqAgQ1NSRiBwcm90ZWN0aW9uIGZvciBhIHJlcXVlc3QgaXMgZGF0YSBp bmNsdWRlZCBpbiB0aGUgcmVxdWVzdCB0aGF0IHRpZXMgdGhhdCByZXF1ZXN0IHRvIHRoZSB1c2Vy J3MgYXV0aGVudGljYXRlZCBzdGF0ZSwgaS5lLiBhIGNyeXB0b2dyYXBoaWMgc2lnbmF0dXJlIG9m IHRoZSB1c2VyIGNyZWRlbnRpYWwgYW5kIHRoZSByZWRpcmVjdGlvbiBVUkkgcGF0aC7CoCBVcG9u IHJlY2VpcHQgb2YgYSByZXF1ZXN0IHRoZSBjbGllbnQgYXBwbGljYXRpb24gY29tcHV0ZXMgdGhl IENTUkYgZGF0YSBiYXNlZCBvbiB0aGUgcHJlc2VudGVkIGNyZWRlbnRpYWwgYW5kIGNvbXBhcmVz IHRoYXQgdG8gdGhlIENTUkYgcHJvdGVjdGlvbiBkYXRhIHByZXNlbnRlZCBpbiB0aGUgcmVxdWVz dC7CoCBDU1JGIHByb3RlY3Rpb24gZGF0YSBNVVNUIGNvbnRhaW4gYSBub24tZ3Vlc3NhYmxlIHZh bHVlLCBhbmQgdGhlIGNsaWVudCBNVVNUIGtlZXAgaXQgaW4gYSBsb2NhdGlvbiBhY2Nlc3NpYmxl IG9ubHkgYnkgdGhlIGNsaWVudCBvciB0aGUgdXNlci1hZ2VudCAoaS5lLiwgcHJvdGVjdGVkIGJ5 IHNhbWUtb3JpZ2luIHBvbGljeSkuIFRoZSAic3RhdGUiIHJlZGlyZWN0aW9uIFVSSSBwYXJhbWV0 ZXIgaXMgcHJvdmlkZWQgYXMgb25lIG1ldGhvZCBvZiBjYXJyeWluZyBDU1JGIHByb3RlY3Rpb24g ZGF0YSwgYW5kIGlzIFJFQ09NTUVOREVEIHRvIHByb3ZpZGUgdGhlIGdyZWF0ZXN0IGNvbXBhdGli aWxpdHkgd2l0aCBzeXN0ZW1zIGltcGxlbWVudGluZyBzdHJvbmcgcmVkaXJlY3Rpb24gVVJJIHZh bGlkYXRpb24uwqAgDQoNCkF1dGhvcml6YXRpb24gc2VydmVycyBNVVNUIGltcGxlbWVudCBDU1JG IHByb3RlY3Rpb24gZm9yIGF1dGhvcml6YXRpb24gcmVxdWVzdHMsIHVzZSBvZiB0aGUgInN0YXRl IiBwYXJhbWV0ZXIgaXMgUkVDT01NRU5ERUQgYXMgdGhlIHdheSB0byB0cmFuc21pdCB0aGUgQ1NS RiBwcm90ZWN0aW9uIGRhdGEuwqDCoFRoZSBDU1JGIHByb3RlY3Rpb24gZGF0YSBNVVNUIGNvbnRh aW4gYSBub24tZ3Vlc3NhYmxlIHZhbHVlLCBhbmQgTVVTVCBiZSBwcmVzZW50ZWQgYXMgcGFydCBv ZiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGRhdGEgKGUuZy4gbm90IGFzIGEgY29va2llKS7C oCBBdXRob3JpemF0aW9uIHNlcnZlcnMgTUFZIHVzZSBwcm9vZiBvZiBwcmV2aW91c8KgIGF1dGhv cml6YXRpb24gYnkgYSB1c2VyIGZvciBhIGNsaWVudCBpbiBsaWV1IG9mIGV4cGxpY2l0IENTUkYg cHJvdGVjdGlvbi4NCg0KRm9yIGV4YW1wbGUsIHVzaW5nIGEgRE9NIHZhcmlhYmxlLCBIVFRQIGNv b2tpZSwgb3IgSFRNTDUgY2xpZW50LXNpZGUgc3RvcmFnZS7CoMKgVGhlIGF1dGhvcml6YXRpb24g c2VydmVyIGluY2x1ZGVzIHRoZSB2YWx1ZSBvZiB0aGUgInN0YXRlIiBwYXJhbWV0ZXIgd2hlbiBy ZWRpcmVjdGluZyB0aGUgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQgd2hpY2ggTVVTVCB0 aGVuIHZhbGlkYXRlIHRoZSByZWNlaXZlZCB2YWx1ZSBhZ2FpbnN0IHRoZSBzdG9yZWQgdmFsdWUs IG9yIGJ5IHJlY29tcHV0aW5nIHRoZSBleHBlY3RlZCB2YWx1ZSBvZiB0aGUgQ1NSRiBwcm90ZWN0 aW9uIGRhdGEgYW5kIGNvbXBhcmluZyB0aGF0IHRvIHRoZSB2YWx1ZSBwcmVzZW50ZWQuIA0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogQW50aG9u eSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb20+DQpUbzogRXJhbiBIYW1tZXItTGFoYXYg PGVyYW5AaHVlbml2ZXJzZS5jb20+OyBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldD4NCkNjOiAiT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKSIgPG9hdXRoQGlldGYu b3JnPg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyNSwgMjAxMSA4OjExIEFNDQpTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBBdXRoIENvZGUgU3dhcCBBdHRhY2sNCkkgaGF2ZSBub3Qgc2VlbiBhbnkg dXBkYXRlZCB0ZXh0LCBzbyBJIGRvbuKAmXQgYmVsaWV2ZSB3ZSBoYXZlIGNvbnNlbnN1cy4gQWxz byB3ZSBoYXZlIGEgZmxhd2VkIHByb3RvY29sIGFuZCB3ZSBhcmUgbm90IHByb3ZpZGluZyBhIGZp eCwgc3VnZ2VzdCB0aGF0IE1VU1QgYmUgb24gdGhlIHN0YXRlIGFsc28gdW5sZXNzIHNvbWVvbmUg aGFzIGEgYmV0dGVyIGZpeA0KwqANCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJhbiBIYW1tZXItTGFoYXYN ClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI0LCAyMDExIDc6NTQgQU0NClRvOiBUb3JzdGVuIExv ZGRlcnN0ZWR0DQpDYzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KU3ViamVjdDogUmU6IFtP QVVUSC1XR10gQXV0aCBDb2RlIFN3YXAgQXR0YWNrDQrCoA0KSSBiZWxpZXZlIHdlIGhhdmUgZnVs bCBjb25zZW5zdXMgb24gdGhpcyBhcHByb2FjaC4NCsKgDQpFSEwNCsKgDQpGcm9tOiBUb3JzdGVu IExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdIA0KU2VudDogVHVl c2RheSwgQXVndXN0IDIzLCAyMDExIDExOjA2IFBNDQpUbzogRXJhbiBIYW1tZXItTGFoYXYNCkNj OiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBdXRo IENvZGUgU3dhcCBBdHRhY2sNCsKgDQptYWtpbmcgQ1NSRiBwcmV2ZW50aW9uIGEgTVVTVCBhbmQg cmVjb21tZW5kaW5nIHRoZSBzdGF0ZSBwYXJhbWV0ZXIgYXMgaW1wbGVtZW50YXRpb24gcGF0dGVy biBpcyBvayB3aXRoIG1lLg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQW0gMjEuMDguMjAxMSAy MTowMiwgc2NocmllYiBFcmFuIEhhbW1lci1MYWhhdjogDQpJIGxpZ2h0IHRvIHRoZSByZWNlbnQg ZGlzY3Vzc2lvbiwgZG8geW91IHN0aWxsIGZlZWwgdGhhdCBjaGFuZ2luZyDigJhzdGF0ZeKAmSBm cm9tIG9wdGlvbmFsIHRvIHJlcXVpcmVkIGlzIHRoZSBiZXN0IGFwcHJvYWNoPw0KwqANCkVITA0K wqANCkZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldF0gDQpTZW50OiBTdW5kYXksIEF1Z3VzdCAyMSwgMjAxMSAxMTowNCBBTQ0KVG86IEVyYW4g SGFtbWVyLUxhaGF2DQpDYzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gQXV0aCBDb2RlIFN3YXAgQXR0YWNrDQrCoA0KTXkgaW50ZW50aW9uIGlzIHRv IHJlcXVpcmUgY2xpZW50cyB0byBpbXBsZW1lbnQgQ1NSRiBwcmV2ZW50aW9uLiBJIHRob3VnaHQg bWFraW5nIHRoZSBzdGF0ZSBwYXJhbWV0ZXIgbWFuZGF0b3J5IHdvdWxkIGJlIHRoZSBzdHJhaWdo dGZvcndhcmQgd2F5Lg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQW0gMTguMDguMjAxMSAwODow NCwgc2NocmllYiBFcmFuIEhhbW1lci1MYWhhdjogDQpJIHdvdWxkIGxpa2UgdG8gaGVhciBmcm9t IHRoZSBvdGhlciAzIGF1dGhvcnMgb2YgdGhlIHByb3Bvc2VkIGNoYW5nZSBhYm91dCB0aGVpciBy ZWFzb25zIGZvciBjaGFuZ2luZyB0aGUgdXNlIG9mIOKAmHN0YXRl4oCZIGZyb20gcmVjb21tZW5k ZWQgdG8gcmVxdWlyZWQgZm9yIENTUkYgcHJldmVudGlvbi4gSXQgd291bGQgYWxzbyBoZWxwIG1v dmluZyB0aGlzIGlzc3VlIGZvcndhcmQgaWYgdGhlIDQgYXV0aG9ycyBjYW4gcHJvdmlkZSBhbnN3 ZXJzIG9yIGNsYXJpZmljYXRpb25zIG9uIHRoZSBpc3N1ZXMgcmFpc2VkIGJlbG93Lg0KwqANCkFz c3VtaW5nIHdlIGNhbiBjb3VudCBhbGwgNCBhdXRob3JzIGFyZSBpbiBmYXZvciBvZiBtYWtpbmcg dGhlIGNoYW5nZSwgSSBiZWxpZXZlIHdlIGhhdmUgYSB0aWUgKDQ6NCkgYW5kIHRoZXJlZm9yZSBu byBjb25zZW5zdXMgZm9yIG1ha2luZyBpdCAoYXMgb2YgdGhpcyBwb2ludCkuIEhvd2V2ZXIsIHdl IGRpZCBpZGVudGlmeSBpc3N1ZXMgd2l0aCB0aGUgc2VjdGlvbuKAmXMgbGFuZ3VhZ2UgYW5kIGNs YXJpdHkgd2hpY2ggd2Ugc2hvdWxkIGFkZHJlc3MgZWl0aGVyIHdheS4NCsKgDQpUbyBjbGFyaWZ5 IOKAkyBJIGFtIG5vdCBwcm9wb3Npbmcgd2UgY2xvc2UgdGhpcyBpc3N1ZSBqdXN0IHlldC4NCsKg DQpFSEwNCsKgDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyYW4gSGFtbWVyLUxhaGF2DQpTZW50OiBNb25k YXksIEF1Z3VzdCAxNSwgMjAxMSA5OjM1IEFNDQpUbzogT0F1dGggV0cgKG9hdXRoQGlldGYub3Jn KQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQXV0aCBDb2RlIFN3YXAgQXR0YWNrDQrCoA0KVG8g ZGVtb25zdHJhdGUgd2h5IG1ha2luZyBzdGF0ZSByZXF1aXJlZCBhcyBwcm9wb3NlZCBpc27igJl0 IHZlcnkgaGVscGZ1bCwgaGVyZSBpcyBhbiBpbmNvbXBsZXRlIGxpc3Qgb2Ygb3RoZXIgcmVxdWly ZW1lbnRzIG5lZWRlZCB0byBtYWtlIGFuIGVmZmVjdGl2ZSBDU1JGOg0KwqANCiogU3RhdGUgdmFs dWUgbXVzdCBub3QgYmUgZW1wdHkgKGEgY29tbW9uIGJ1ZyBpbiBtYW55IGltcGxlbWVudGF0aW9u cyB1c2luZyBzaW1wbGUgdmFsdWUgY29tcGFyaXNvbikuDQrCoA0KKiDigJhOb24tZ3Vlc3NhYmxl 4oCZIGlzbuKAmXQgc3VmZmljaWVudCBhcyBtb3N0IGRldmVsb3BlcnMgd2lsbCBzaW1wbHkgdXNl IGEgaGFzaCBvZiB0aGUgc2Vzc2lvbiBjb29raWUsIHdpdGggb3Igd2l0aG91dCBzYWx0IHdoaWNo IGlzbuKAmXQgc3VmZmljaWVudC4gV2UgdXNlIOKAnGNhbm5vdCBiZSBnZW5lcmF0ZWQsIG1vZGlm aWVkLCBvciBndWVzc2VkIHRvIHByb2R1Y2UgdmFsaWQgdmFsdWVz4oCdIGVsc2V3aGVyZSBpbiB0 aGUgZG9jdW1lbnQsIGJ1dCB0aGlzIGlzIG11Y2ggZWFzaWVyIHRvIGdldCByaWdodCBmb3IgYWNj ZXNzIHRva2VucyBhbmQgcmVmcmVzaCB0b2tlbnMgdGhhbiBDU1JGIHRva2VucyB3aGljaCBhcmUg b2Z0ZW4ganVzdCBzb21lIGFsZ29yaXRobSBvbiB0b3Agb2YgdGhlIHNlc3Npb24gY29va2llLg0K wqANCiogU3RhdGUgQ1NSRiB2YWx1ZSBzaG91bGQgYmUgc2hvcnQtbGl2ZWQgb3IgYmFzZWQgb24g YSBzaG9ydC1saXZlZCBzZXNzaW9uIGNvb2tpZSB0byBwcmV2ZW50IHRoZSB1c2Ugb2YgYSBsZWFr ZWQgc3RhdGUgdmFsdWUgaW4gbXVsdGlwbGUgYXR0YWNrcyBvbiB0aGUgc2FtZSB1c2VyIHNlc3Np b24gb25jZSB0aGUgbGVhayBpcyBubyBsb25nZXIgdmlhYmxlLg0KwqANCkluIGFkZGl0aW9uLCB0 aGlzIGlzIG5vdCB3aGF0IOKAnHN0YXRl4oCdIHdhcyBvcmlnaW5hbGx5IGludGVuZGVkIGZvci4g SWYgdGhlIHdvcmtpbmcgZ3JvdXAgZGVjaWRlcyB0byBtYW5kYXRlIGEgQ1NSRiBwYXJhbWV0ZXIs IGl0IHNob3VsZCBwcm9iYWJseSBiZSBhIG5ldyBwYXJhbWV0ZXIgd2l0aCBhIG1vcmUgYXBwcm9w cmlhdGUgbmFtZSAoZS5nLiDigJhjc3Jm4oCZKS4gQnkgZm9yY2luZyBjbGllbnRzIHRvIHVzZSDi gJxzdGF0ZeKAnSBmb3IgdGhpcyBwdXJwb3NlLCBkZXZlbG9wZXJzIHdpbGwgbmVlZCB0byB1c2Ug ZHluYW1pYyBxdWVyaWVzIGZvciBvdGhlciBzdGF0ZSBpbmZvcm1hdGlvbiB3aGljaCBmdXJ0aGVy IHJlZHVjZXMgdGhlIHNlY3VyaXR5IG9mIHRoZSBwcm90b2NvbCAoYXMgdGhlIGRyYWZ0IHJlY29t bWVuZHMgbm90IHVzaW5nIGR5bmFtaWMgY2FsbGJhY2sgcXVlcnkgY29tcG9uZW50cykuIEVuY29k aW5nIGJvdGggQ1NSRiB0b2tlbnMgYW5kIG90aGVyIHN0YXRlIGluZm9ybWF0aW9uIGNhbiBiZSBu b24taW50dWl0aXZlIG9yIGNvbXBsaWNhdGVkIGZvciBzb21lIGRldmVsb3BlcnMvcGxhdGZvcm1z Lg0KwqANCkVITA0KwqANCsKgDQrCoA0KwqANCkZyb206IEVyYW4gSGFtbWVyLUxhaGF2IA0KU2Vu dDogRnJpZGF5LCBBdWd1c3QgMTIsIDIwMTEgMjo1MyBQTQ0KVG86IEFudGhvbnkgTmFkYWxpbjsg T0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQXV0aCBD b2RlIFN3YXAgQXR0YWNrDQrCoA0KVGhpcyBpcyByZWFsbHkganVzdCBhIGZsYXZvciBvZiBDU1JG IGF0dGFja3MuIEkgaGF2ZSBubyBvYmplY3Rpb25zIHRvIGJldHRlciBkb2N1bWVudGluZyBpdCAo dGhvdWdoIEkgZmVlbCB0aGUgY3VycmVudCB0ZXh0IGlzIGFscmVhZHkgc3VmZmljaWVudCksIGJ1 dCB3ZSBjYW4ndCByZWFsaXN0aWNhbGx5IGV4cGVjdCB0byBpZGVudGlmeSBhbmQgY2xvc2UgZXZl cnkgcG9zc2libGUgYnJvd3Nlci1iYXNlZCBhdHRhY2suIEEgbmV3IG9uZSBpcyBpbnZlbnRlZCBl dmVyeSBvdGhlciB3ZWVrLg0KwqANClRoZSBwcm9ibGVtIHdpdGggdGhpcyB0ZXh0IGlzIHRoYXQg ZGV2ZWxvcGVycyB3aG8gZG8gbm8gdW5kZXJzdGFuZCBDU1JGIGF0dGFja3MgYXJlIG5vdCBsaWtl bHkgdG8gaW1wbGVtZW50IGl0IGNvcnJlY3RseSB3aXRoIHRoaXMgaW5mb3JtYXRpb24uIFRob3Nl IHdobyB1bmRlcnN0YW5kIGl0IGRvIG5vdCBuZWVkIHRoZSBleHRyYSB2ZXJiaWFnZSB3aGljaCBp cyBtb3JlIGNvbmZ1c2luZyB0aGFuIGhlbHBmdWwuDQrCoA0KQXMgZm9yIHRoZSBuZXcgcmVxdWly ZW1lbnRzLCB0aGV5IGFyZSBpbnN1ZmZpY2llbnQgdG8gYWN0dWFsbHkgYWNjb21wbGlzaCB3aGF0 IHRoZSBhdXRob3JzIHByb3Bvc2Ugd2l0aG91dCBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBvbiBz dGF0ZSBsb2NhbCBzdG9yYWdlIGFuZCB2ZXJpZmljYXRpb24gdG8gY29tcGxldGUgdGhlIGZsb3cu IEFsc28sIHRoZSBwcm9wb3NlZCB0ZXh0IG5lZWRzIGNsYXJpZmljYXRpb25zIGFzIG5vdGVkIGJl bG93Lg0KwqANCsKgDQpGcm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNv bT4NCkRhdGU6IEZyaSwgMTIgQXVnIDIwMTEgMTI6MDY6MzYgLTA3MDANClRvOiAiT0F1dGggV0cg KG9hdXRoQGlldGYub3JnKSIgPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogW09BVVRILVdHXSBB dXRoIENvZGUgU3dhcCBBdHRhY2sNCsKgDQrCoA0KwqANClJlY29tbWVuZGVkIENoYW5nZXMgdG8g ZHJhZnQtaWV0Zi1vYXV0aC12Mg0KwqANCkluIHNlY3Rpb24gNCwgcmVxdWVzdCBvcHRpb25zIChl LmcuIDQuMS4xKSBmZWF0dXJpbmcgInN0YXRlIiBzaG91bGQgY2hhbmdlIGZyb206DQrCoA0Kc3Rh dGUNCk9QVElPTkFMLiBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xpZW50IHRvIG1haW50 YWluIHN0YXRlIGJldHdlZW4gdGhlIHJlcXVlc3QgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZSB1c2Vy LWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudC4NCsKgDQp0bzoNCsKgDQpzdGF0ZQ0KUkVRVUlSRUQu IEFuIG9wYXF1ZSB2YWx1ZSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gbWFpbnRhaW4gc3RhdGUgYmV0 d2VlbiB0aGUgcmVxdWVzdCBhbmQgY2FsbGJhY2suIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBp bmNsdWRlcyB0aGlzIHZhbHVlIHdoZW4gcmVkaXJlY3RpbmcgdGhlIHVzZXItYWdlbnQgYmFjayB0 byB0aGUgY2xpZW50LiBUaGUgZW5jb2RlZCB2YWx1ZSBTSE9VTEQgZW5hYmxlIHRoZSBjbGllbnQg YXBwbGljYXRpb24gdG8gZGV0ZXJtaW5lIHRoZSB1c2VyLWNvbnRleHQgdGhhdCB3YXMgYWN0aXZl IGF0IHRoZSB0aW1lIG9mIHRoZSDCoHJlcXVlc3QgKHNlZSBzZWN0aW9uIDEwLjEyKS4gVGhlIHZh bHVlIE1VU1QgTk9UIGJlIGd1ZXNzYWJsZSBvciBwcmVkaWN0YWJsZSwgYW5kIE1VU1QgYmUga2Vw dCBjb25maWRlbnRpYWwuDQrCoA0KwqANCk1ha2luZyB0aGUgcGFyYW1ldGVyIHJlcXVpcmVkIHdp dGhvdXQgbWFraW5nIGl0cyB1c2FnZSByZXF1aXJlZCAoSS5lLiAidmFsdWUgU0hPVUxEIGVuYWJs ZSIpIGFjY29tcGxpc2hlcyBub3RoaW5nLiBBbHNvLCB3aGF0IGRvZXMgIk1VU1QgYmUga2VwdCBj b25maWRlbnRpYWwiIG1lYW4/IENvbmZpZGVudGlhbCBmcm9tIHdoYXQ/IFdoeSBzcGVjaWZ5IGFu ICJlbmNvZGVkIHZhbHVlIj8NCsKgDQrCoA0KU2VjdGlvbiAxMC4xMiBDcm9zcy1TaXRlIFJlcXVl c3QgRm9yZ2VyeQ0KwqANCkNoYW5nZSB0bzoNCsKgDQpDcm9zcy1zaXRlIHJlcXVlc3QgZm9yZ2Vy eSAoQ1NSRikgaXMgYSB3ZWItYmFzZWQgYXR0YWNrIHdoZXJlYnkgSFRUUCByZXF1ZXN0cyBhcmUg dHJhbnNtaXR0ZWQgZnJvbSB0aGUgdXNlci1hZ2VudCBvZiBhbiBlbmQtdXNlcsKgdGhlIHNlcnZl ciB0cnVzdHMgb3IgaGFzIGF1dGhlbnRpY2F0ZWQuIENTUkYgYXR0YWNrcyBlbmFibGUgdGhlIGF0 dGFja2VyIHRvIGludGVybWl4IHRoZSBhdHRhY2tlcidzIHNlY3VyaXR5IGNvbnRleHQgd2l0aCB0 aGF0IG9mIHRoZcKgcmVzb3VyY2Ugb3duZXIgcmVzdWx0aW5nIGluIGEgY29tcHJvbWlzZSBvZiBl aXRoZXIgdGhlIHJlc291cmNlIHNlcnZlciBvciBvZiB0aGUgY2xpZW50IGFwcGxpY2F0aW9uIGl0 c2VsZi4gSW4gdGhlIE9BdXRoIGNvbnRleHQsIHN1Y2jCoGF0dGFja3MgYWxsb3cgYW4gYXR0YWNr ZXIgdG8gaW5qZWN0IHRoZWlyIG93biBhdXRob3JpemF0aW9uIGNvZGUgb3IgYWNjZXNzIHRva2Vu IGludG8gYSBjbGllbnQsIHdoaWNoIGNhbiByZXN1bHQgaW4gdGhlIGNsaWVudCB1c2luZyBhbsKg YWNjZXNzIHRva2VuIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXR0YWNrZXIncyBhY2NvdW50IHJhdGhl ciB0aGFuIHRoZSB2aWN0aW0ncy4gRGVwZW5kaW5nIG9uIHRoZSBuYXR1cmUgb2YgdGhlIGNsaWVu dCBhbmQgdGhlIHByb3RlY3RlZMKgcmVzb3VyY2VzLCB0aGlzIGNhbiBoYXZlIHVuZGVzaXJhYmxl IGFuZCBkYW1hZ2luZyBlZmZlY3RzLg0KDQpJbiBvcmRlciB0byBwcmV2ZW50IHN1Y2ggYXR0YWNr cywgdGhlIGNsaWVudCBhcHBsaWNhdGlvbiBNVVNUIGVuY29kZSBhIG5vbi1ndWVzc2FibGUsIGNv bmZpZGVudGlhbCBlbmQtdXNlciBhcnRpZmFjdCBhbmQgc3VibWl0IGFzwqB0aGUgInN0YXRlIiBw YXJhbWV0ZXIgdG8gYXV0aG9yaXphdGlvbiBhbmQgYWNjZXNzIHRva2VuIHJlcXVlc3RzIHRvIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlIGNsaWVudCBNVVNUIGtlZXAgdGhlIHN0YXRlIHZh bHVlIGluwqBhIGxvY2F0aW9uIGFjY2Vzc2libGUgb25seSBieSB0aGUgY2xpZW50IG9yIHRoZSB1 c2VyLWFnZW50IChpLmUuLCBwcm90ZWN0ZWQgYnkgc2FtZS1vcmlnaW4gcG9saWN5KSwgZm9yIGV4 YW1wbGUsIHVzaW5nIGEgRE9NIHZhcmlhYmxlLMKgSFRUUCBjb29raWUsIG9yIEhUTUw1IGNsaWVu dC1zaWRlIHN0b3JhZ2UuDQoNClRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbmNsdWRlcyB0aGUg dmFsdWUgb2YgdGhlICJzdGF0ZSIgcGFyYW1ldGVyIHdoZW4gcmVkaXJlY3RpbmcgdGhlIHVzZXIt YWdlbnQgYmFjayB0byB0aGUgY2xpZW50LiBVcG9uwqByZWNlaXZpbmcgYSByZWRpcmVjdCwgdGhl IGNsaWVudCBhcHBsaWNhdGlvbiBNVVNUIGNvbmZpcm0gdGhhdCByZXR1cm5lZCB2YWx1ZSBvZiAi c3RhdGUiIGNvcnJlc3BvbmRzIHRvIHRoZSBzdGF0ZSB2YWx1ZSBvZiB0aGUgdXNlci1hZ2VudCdz IHVzZXIgc2Vzc2lvbi4gSWYgdGhlIGVuZC11c2VyIHNlc3Npb24gcmVwcmVzZW50cyBhbiBhdXRo ZW50aWNhdGVkIHVzZXItaWRlbnRpdHksIHRoZSBjbGllbnQgTVVTVCBlbnN1cmUgdGhhdCB0aGUg dXNlci1pZGVudGl0ecKgaGFzIE5PVCBjaGFuZ2VkLg0KwqANCsKgDQpUaGUgYWJvdmUgdGV4dCB1 c2VzICd1c2VyLWNvbnRleHQnIGFuZCB0aGlzICd1c2VyLWlkZW50aXR5Jy4gTmVpdGhlciB0ZXJt IGlzIGRlZmluZWQuDQrCoA0KRUhMDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCsKgDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxp c3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCg== From eran@hueniverse.com Sun Sep 4 16:20: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 E1FA221F8AC9 for ; Sun, 4 Sep 2011 16:20:49 -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 mUld6xEmRG-1 for ; Sun, 4 Sep 2011 16:20: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 7004021F8ABC for ; Sun, 4 Sep 2011 16:20:49 -0700 (PDT) Received: (qmail 13321 invoked from network); 4 Sep 2011 23:22:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Sep 2011 23:22:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Sun, 4 Sep 2011 16:22:32 -0700 From: Eran Hammer-Lahav To: Hannes Tschofenig Date: Sun, 4 Sep 2011 16:20:41 -0700 Thread-Topic: [OAUTH-WG] Security area review Thread-Index: AcxmI+ANYBPleroZQyGfb2fKoQ9XYAFNV9Jg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345024864A96@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1765F65A-9FFF-47AC-89D0-EC29E2918EE9@gmx.net> In-Reply-To: <1765F65A-9FFF-47AC-89D0-EC29E2918EE9@gmx.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 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: Sun, 04 Sep 2011 23:20:50 -0000 Where is this feedback? > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] > Sent: Monday, August 29, 2011 1:16 AM > To: Eran Hammer-Lahav > Cc: Hannes Tschofenig; OAuth WG > Subject: Re: [OAUTH-WG] Security area review >=20 > 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. > As Barry said, there will be more review comments flying in after the > document left the working group. >=20 > Ciao > Hannes >=20 > 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: >=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 securit= y > 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 kno= w > what actual actions are being taken to turn this promise into reality. > > > > EHL > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Sep 4 16:25: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 418D021F8AD2 for ; Sun, 4 Sep 2011 16:25:11 -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 sPkvrB9Qo9-1 for ; Sun, 4 Sep 2011 16:25:10 -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 CD1E821F8ADC for ; Sun, 4 Sep 2011 16:25:09 -0700 (PDT) Received: (qmail 17756 invoked from network); 4 Sep 2011 23:26:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Sep 2011 23:26:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Sun, 4 Sep 2011 16:26:52 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , "William J. Mills" , Anthony Nadalin , Torsten Lodderstedt Date: Sun, 4 Sep 2011 16:25:01 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxjWshx+81E1zxCT4uviHHsUmJj0wH/K/3gAACTyvA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D8@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> <1314299478.57208.YahooMailNeo@web31812.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D6@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: "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, 04 Sep 2011 23:25:11 -0000 VGhlIGNvcnJlc3BvbmRpbmcgJ3N0YXRlJyBwYXJhbWV0ZXIgZGVmaW5pdGlvbjoNCg0KICAgICAg ICAgICAgICAgIFJFQ09NTUVOREVELiBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xpZW50 IHRvIG1haW50YWluIHN0YXRlIGJldHdlZW4gdGhlIHJlcXVlc3QNCiAgICAgICAgICAgICAgICBh bmQgY2FsbGJhY2suIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbmNsdWRlcyB0aGlzIHZhbHVl IHdoZW4gcmVkaXJlY3RpbmcgdGhlDQogICAgICAgICAgICAgICAgdXNlci1hZ2VudCBiYWNrIHRv IHRoZSBjbGllbnQuIFRoZSBwYXJhbWV0ZXIgU0hPVUxEIGJlIHVzZWQgZm9yIHByZXZlbnRpbmcN CiAgICAgICAgICAgICAgICBjcm9zcy1zaXRlIHJlcXVlc3QgZm9yZ2VyeSBhcyBkZXNjcmliZWQg aW4gc2VjdGlvbiAxMC4xMi4NCg0KRUhMDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBFcmFuIEhhbW1lci1MYWhhdg0KPiBTZW50OiBTdW5kYXks IFNlcHRlbWJlciAwNCwgMjAxMSA0OjIwIFBNDQo+IFRvOiBXaWxsaWFtIEouIE1pbGxzOyBBbnRo b255IE5hZGFsaW47IFRvcnN0ZW4gTG9kZGVyc3RlZHQNCj4gQ2M6IE9BdXRoIFdHIChvYXV0aEBp ZXRmLm9yZykNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQXV0aCBDb2RlIFN3YXAgQXR0YWNr DQo+DQo+IFRoaXMgaXMgbXkgcHJvcG9zZWQgdGV4dCBmb3IgLTIxIChiYXNlZCBvbiBCaWxsJ3Mg dGV4dCBhcyBhIHN0YXJ0aW5nIHBvaW50KToNCj4NCj4gMTAuMTIuICBDcm9zcy1TaXRlIFJlcXVl c3QgRm9yZ2VyeQ0KPg0KPiAgICBDcm9zcy1zaXRlIHJlcXVlc3QgZm9yZ2VyeSAoQ1NSRikgaXMg YW4gZXhwbG9pdCBpbiB3aGljaCBhbiBhdHRhY2tlcg0KPiAgICBjYXVzZXMgdGhlIHVzZXItYWdl bnQgb2YgYSB2aWN0aW0gZW5kLXVzZXIgdG8gZm9sbG93IGEgbWFsaWNpb3VzIFVSSQ0KPiAgICAo ZS5nLiBwcm92aWRlZCB0byB0aGUgdXNlci1hZ2VudCBhcyBhIG1pc2xlYWRpbmcgbGluaywgaW1h Z2UsIG9yDQo+ICAgIHJlZGlyZWN0aW9uKSB0byBhIHRydXN0aW5nIHNlcnZlciAodXN1YWxseSBl c3RhYmxpc2hlZCB2aWEgdGhlDQo+ICAgIHByZXNlbmNlIG9mIGEgdmFsaWQgc2Vzc2lvbiBjb29r aWUpLg0KPg0KPiAgICBBIENTUkYgYXR0YWNrIGFnYWluc3QgdGhlIGNsaWVudCdzIHJlZGlyZWN0 aW9uIFVSSSBhbGxvd3MgYW4gYXR0YWNrZXINCj4gICAgdG8gaW5qZWN0IHRoZWlyIG93biBhdXRo b3JpemF0aW9uIGNvZGUgb3IgYWNjZXNzIHRva2VuLCB3aGljaCBjYW4NCj4gICAgcmVzdWx0IGlu IHRoZSBjbGllbnQgdXNpbmcgYW4gYWNjZXNzIHRva2VuIGFzc29jaWF0ZWQgd2l0aCB0aGUNCj4g ICAgYXR0YWNrZXIncyBwcm90ZWN0ZWQgcmVzb3VyY2VzIHJhdGhlciB0aGFuIHRoZSB2aWN0aW0n cyAoZS5nLiBzYXZlDQo+ICAgIHRoZSB2aWN0aW0ncyBiYW5rIGFjY291bnQgaW5mb3JtYXRpb24g dG8gYSBwcm90ZWN0ZWQgcmVzb3VyY2UNCj4gICAgY29udHJvbGxlZCBieSB0aGUgYXR0YWNrZXIp Lg0KPg0KPiAgICBUaGUgY2xpZW50IE1VU1QgaW1wbGVtZW50IENTUkYgcHJvdGVjdGlvbiBmb3Ig aXRzIHJlZGlyZWN0aW9uIFVSSS4NCj4gICAgVGhpcyBpcyB0eXBpY2FsbHkgYWNjb21wbGlzaGVk IGJ5IHJlcXVpcmluZyBhbnkgcmVxdWVzdCBzZW50IHRvIHRoZQ0KPiAgICByZWRpcmVjdGlvbiBV UkkgZW5kcG9pbnQgdG8gaW5jbHVkZSBhIHZhbHVlIHRoYXQgYmluZHMgdGhlIHJlcXVlc3QgdG8N Cj4gICAgdGhlIHVzZXItYWdlbnQncyBhdXRoZW50aWNhdGVkIHN0YXRlIChlLmcuIGEgaGFzaCBv ZiB0aGUgc2Vzc2lvbg0KPiAgICBjb29raWUgdXNlZCB0byBhdXRoZW50aWNhdGlvbiB0aGUgdXNl ci1hZ2VudCkuICBUaGUgY2xpZW50IFNIT1VMRA0KPiAgICB1dGlsaXplIHRoZSAic3RhdGUiIHJl cXVlc3QgcGFyYW1ldGVyIHRvIGRlbGl2ZXIgdGhpcyB2YWx1ZSB0byB0aGUNCj4gICAgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgd2hlbiBtYWtpbmcgYW4gYXV0aG9yaXphdGlvbiByZXF1ZXN0Lg0KPg0K PiAgICBPbmNlIGF1dGhvcml6YXRpb24gaGFzIGJlZW4gb2J0YWluZWQgZnJvbSB0aGUgZW5kLXVz ZXIsIHRoZQ0KPiAgICBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIGVuZC11c2Vy J3MgdXNlci1hZ2VudCBiYWNrIHRvIHRoZQ0KPiAgICBjbGllbnQgd2l0aCB0aGUgcmVxdWlyZWQg YmluZGluZyB2YWx1ZSBjb250YWluZWQgaW4gdGhlICJzdGF0ZSINCj4gICAgcGFyYW1ldGVyLiAg VGhlIGJpbmRpbmcgdmFsdWUgZW5hYmxlcyB0aGUgY2xpZW50IHRvIHZhbGlkYXRlIHRoZQ0KPiAg ICB2YWxpZGl0eSBvZiB0aGUgcmVxdWVzdCBieSBtYXRjaGluZyB0aGUgYmluZGluZyB2YWx1ZSB0 byB0aGUgdXNlci0NCj4gICAgYWdlbnQncyBhdXRoZW50aWNhdGVkIHN0YXRlLiAgVGhlIGJpbmRp bmcgdmFsdWUgdXNlZCBmb3IgQ1NSRg0KPiAgICBwcm90ZWN0aW9uIE1VU1QgY29udGFpbiBhIG5v bi1ndWVzc2FibGUgdmFsdWUsIGFuZCB0aGUgdXNlci1hZ2VudCdzDQo+ICAgIGF1dGhlbnRpY2F0 ZWQgc3RhdGUgKGUuZy4gc2Vzc2lvbiBjb29raWUsIEhUTUw1IGxvY2FsIHN0b3JhZ2UpIE1VU1QN Cj4gICAgYmUga2VwdCBpbiBhIGxvY2F0aW9uIGFjY2Vzc2libGUgb25seSB0byB0aGUgY2xpZW50 IGFuZCB0aGUgdXNlci0NCj4gICAgYWdlbnQgKGkuZS4sIHByb3RlY3RlZCBieSBzYW1lLW9yaWdp biBwb2xpY3kpLg0KPg0KPiAgICBBIENTUkYgYXR0YWNrIGFnYWluc3QgdGhlIGFnYWluc3QgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyJ3MNCj4gICAgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBjYW4g cmVzdWx0IGluIGFuIGF0dGFja2VyIG9idGFpbmluZyBlbmQtdXNlcg0KPiAgICBhdXRob3JpemF0 aW9uIGZvciBhIG1hbGljaW91cyBjbGllbnQgd2l0aG91dCBpbnZvbHZpbmcgb3IgYWxlcnRpbmcN Cj4gICAgdGhlIGVuZC11c2VyLg0KPg0KPiAgICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCBpbXBsZW1lbnQgQ1NSRiBwcm90ZWN0aW9uIGZvciBpdHMNCj4gICAgYXV0aG9yaXphdGlvbiBl bmRwb2ludCwgYW5kIGVuc3VyZSB0aGF0IGEgbWFsaWNpb3VzIGNsaWVudCBjYW5ub3QNCj4gICAg b2J0YWluIGF1dGhvcml6YXRpb24gd2l0aG91dCB0aGUgYXdhcmVuZXNzIGFuZCBleHBsaWNpdCBj b25zZW50IG9mDQo+ICAgIHRoZSByZXNvdXJjZSBvd25lci4NCj4NCj4gRUhMDQo+DQo+DQo+IEZy b206IFdpbGxpYW0gSi4gTWlsbHMgW21haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbV0NCj4gU2Vu dDogVGh1cnNkYXksIEF1Z3VzdCAyNSwgMjAxMSAxMjoxMSBQTQ0KPiBUbzogQW50aG9ueSBOYWRh bGluOyBFcmFuIEhhbW1lci1MYWhhdjsgVG9yc3RlbiBMb2RkZXJzdGVkdA0KPiBDYzogT0F1dGgg V0cgKG9hdXRoQGlldGYub3JnKQ0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBdXRoIENvZGUg U3dhcCBBdHRhY2sNCj4NCj4gSSBoYWQgcHJvcG9zZWQgdGV4dCwgYW5kIEknbGwgcmVwcmlzZSBp dCBoZXJlIHdpdGggYSBtb2RpZmljYXRpb24gdG8gbWFrZSB0aGUNCj4gYXV0aG9yaXphdG9uIHNl cnZlciByZWxhdGVkIGV4cGxpY2l0Lg0KPg0KPiAxMC4xMi4gIENyb3NzLVNpdGUgUmVxdWVzdCBG b3JnZXJ5DQo+DQo+IENyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IChDU1JGKSBpcyBhbiBhdHRh Y2sgd2hlcmVieSBtYWxpY2lvdXMgVVJMcyBhcmUNCj4gc2VudCB0byB0aGUgdXNlci1hZ2VudCBv ZiBhbiBlbmQgdXNlciAoZ2VuZXJhbGx5IGFzIGhpZGRlbiBsaW5rcyBvciBpbWFnZXMpDQo+IGFu ZCB0cmFuc21pdHRlZCBmcm9tIHRoZSB1c2VyLWFnZW50IHRoZSBzZXJ2ZXIgdHJ1c3RzIG9yIGhh cyBhdXRoZW50aWNhdGVkLg0KPiBUaGUgbW9zdCBjb21tb25seSBleHBsb2l0ZWQgbWVjaGFuaXNt IGZvciB0aGlzIGlzIGNyZWRlbnRpYWxzIGhlbGQgaW4NCj4gY29va2llcyBhdXRvbWF0aWNhbGx5 IHByZXNlbnRlZCBieSBhIHdlYiBicm93c2VyLiAgQ1NSRiBhdHRhY2tzIGFnYWluc3QgdGhlDQo+ IGNsaWVudCdzIHJlZGlyZWN0aW9uIFVSSSBhbGxvdyBhbiBhdHRhY2tlciB0byBpbmplY3QgdGhl aXIgb3duIGF1dGhvcml6YXRpb24NCj4gY29kZSBvciBhY2Nlc3MgdG9rZW4sIHdoaWNoIGNhbiBy ZXN1bHQgaW4gdGhlIGNsaWVudCB1c2luZyBhbiBhY2Nlc3MgdG9rZW4NCj4gYXNzb2NpYXRlZCB3 aXRoIHRoZSBhdHRhY2tlcidzIGFjY291bnQgcmF0aGVyIHRoYW4gdGhlIHZpY3RpbSdzLiAgQ1NS RiBhdHRhY2tzDQo+IGFyZSBhbHNvIHBvc3NpYmxlIGFnYWluc3QgYW4gYXV0aG9yaXphdGlvbiBl bmRwb2ludCByZXN1bHRpbmcgaW4gZGVsaXZlcmluZyBhDQo+IHVzZXIgY3JlZGVudGlhbCB0byBh biBhdHRhY2tlci4NCj4NCj4gQ2xpZW50IGFwcGxpY2F0aW9ucyBNVVNUIGltcGxlbWVudCBDU1JG IHByb3RlY3Rpb24gZm9yIHRoZSByZWRpcmVjdGlvbg0KPiBVUkkuICBDU1JGIHByb3RlY3Rpb24g Zm9yIGEgcmVxdWVzdCBpcyBkYXRhIGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0IHRoYXQgdGllcw0K PiB0aGF0IHJlcXVlc3QgdG8gdGhlIHVzZXIncyBhdXRoZW50aWNhdGVkIHN0YXRlLCBpLmUuIGEg Y3J5cHRvZ3JhcGhpYyBzaWduYXR1cmUNCj4gb2YgdGhlIHVzZXIgY3JlZGVudGlhbCBhbmQgdGhl IHJlZGlyZWN0aW9uIFVSSSBwYXRoLiAgVXBvbiByZWNlaXB0IG9mIGENCj4gcmVxdWVzdCB0aGUg Y2xpZW50IGFwcGxpY2F0aW9uIGNvbXB1dGVzIHRoZSBDU1JGIGRhdGEgYmFzZWQgb24gdGhlDQo+ IHByZXNlbnRlZCBjcmVkZW50aWFsIGFuZCBjb21wYXJlcyB0aGF0IHRvIHRoZSBDU1JGIHByb3Rl Y3Rpb24gZGF0YQ0KPiBwcmVzZW50ZWQgaW4gdGhlIHJlcXVlc3QuICBDU1JGIHByb3RlY3Rpb24g ZGF0YSBNVVNUIGNvbnRhaW4gYSBub24tDQo+IGd1ZXNzYWJsZSB2YWx1ZSwgYW5kIHRoZSBjbGll bnQgTVVTVCBrZWVwIGl0IGluIGEgbG9jYXRpb24gYWNjZXNzaWJsZSBvbmx5IGJ5DQo+IHRoZSBj bGllbnQgb3IgdGhlIHVzZXItYWdlbnQgKGkuZS4sIHByb3RlY3RlZCBieSBzYW1lLW9yaWdpbiBw b2xpY3kpLiBUaGUNCj4gInN0YXRlIiByZWRpcmVjdGlvbiBVUkkgcGFyYW1ldGVyIGlzIHByb3Zp ZGVkIGFzIG9uZSBtZXRob2Qgb2YgY2FycnlpbmcNCj4gQ1NSRiBwcm90ZWN0aW9uIGRhdGEsIGFu ZCBpcyBSRUNPTU1FTkRFRCB0byBwcm92aWRlIHRoZSBncmVhdGVzdA0KPiBjb21wYXRpYmlsaXR5 IHdpdGggc3lzdGVtcyBpbXBsZW1lbnRpbmcgc3Ryb25nIHJlZGlyZWN0aW9uIFVSSSB2YWxpZGF0 aW9uLg0KPg0KPiBBdXRob3JpemF0aW9uIHNlcnZlcnMgTVVTVCBpbXBsZW1lbnQgQ1NSRiBwcm90 ZWN0aW9uIGZvciBhdXRob3JpemF0aW9uDQo+IHJlcXVlc3RzLCB1c2Ugb2YgdGhlICJzdGF0ZSIg cGFyYW1ldGVyIGlzIFJFQ09NTUVOREVEIGFzIHRoZSB3YXkgdG8NCj4gdHJhbnNtaXQgdGhlIENT UkYgcHJvdGVjdGlvbiBkYXRhLiAgVGhlIENTUkYgcHJvdGVjdGlvbiBkYXRhIE1VU1QgY29udGFp biBhDQo+IG5vbi1ndWVzc2FibGUgdmFsdWUsIGFuZCBNVVNUIGJlIHByZXNlbnRlZCBhcyBwYXJ0 IG9mIHRoZSBhdXRob3JpemF0aW9uDQo+IHJlcXVlc3QgZGF0YSAoZS5nLiBub3QgYXMgYSBjb29r aWUpLiAgQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIE1BWSB1c2UgcHJvb2Ygb2YNCj4gcHJldmlvdXMg IGF1dGhvcml6YXRpb24gYnkgYSB1c2VyIGZvciBhIGNsaWVudCBpbiBsaWV1IG9mIGV4cGxpY2l0 IENTUkYgcHJvdGVjdGlvbi4NCj4NCj4gRm9yIGV4YW1wbGUsIHVzaW5nIGEgRE9NIHZhcmlhYmxl LCBIVFRQIGNvb2tpZSwgb3IgSFRNTDUgY2xpZW50LXNpZGUNCj4gc3RvcmFnZS4gIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBpbmNsdWRlcyB0aGUgdmFsdWUgb2YgdGhlICJzdGF0ZSINCj4gcGFy YW1ldGVyIHdoZW4gcmVkaXJlY3RpbmcgdGhlIHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50 IHdoaWNoIE1VU1QNCj4gdGhlbiB2YWxpZGF0ZSB0aGUgcmVjZWl2ZWQgdmFsdWUgYWdhaW5zdCB0 aGUgc3RvcmVkIHZhbHVlLCBvciBieSByZWNvbXB1dGluZw0KPiB0aGUgZXhwZWN0ZWQgdmFsdWUg b2YgdGhlIENTUkYgcHJvdGVjdGlvbiBkYXRhIGFuZCBjb21wYXJpbmcgdGhhdCB0byB0aGUNCj4g dmFsdWUgcHJlc2VudGVkLg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEZyb206IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQu Y29tPg0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb20+OyBUb3Jz dGVuIExvZGRlcnN0ZWR0DQo+IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4NCj4gQ2M6ICJPQXV0 aCBXRyAob2F1dGhAaWV0Zi5vcmcpIiA8b2F1dGhAaWV0Zi5vcmc+DQo+IFNlbnQ6IFRodXJzZGF5 LCBBdWd1c3QgMjUsIDIwMTEgODoxMSBBTQ0KPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBdXRo IENvZGUgU3dhcCBBdHRhY2sgSSBoYXZlIG5vdCBzZWVuIGFueQ0KPiB1cGRhdGVkIHRleHQsIHNv IEkgZG9u4oCZdCBiZWxpZXZlIHdlIGhhdmUgY29uc2Vuc3VzLiBBbHNvIHdlIGhhdmUgYSBmbGF3 ZWQNCj4gcHJvdG9jb2wgYW5kIHdlIGFyZSBub3QgcHJvdmlkaW5nIGEgZml4LCBzdWdnZXN0IHRo YXQgTVVTVCBiZSBvbiB0aGUgc3RhdGUNCj4gYWxzbyB1bmxlc3Mgc29tZW9uZSBoYXMgYSBiZXR0 ZXIgZml4DQo+DQo+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgRXJhbiBIYW1tZXItTGFoYXYNCj4gU2Vu dDogV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTEgNzo1NCBBTQ0KPiBUbzogVG9yc3RlbiBMb2Rk ZXJzdGVkdA0KPiBDYzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiBTdWJqZWN0OiBSZTog W09BVVRILVdHXSBBdXRoIENvZGUgU3dhcCBBdHRhY2sNCj4NCj4gSSBiZWxpZXZlIHdlIGhhdmUg ZnVsbCBjb25zZW5zdXMgb24gdGhpcyBhcHByb2FjaC4NCj4NCj4gRUhMDQo+DQo+IEZyb206IFRv cnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0NCj4gU2Vu dDogVHVlc2RheSwgQXVndXN0IDIzLCAyMDExIDExOjA2IFBNDQo+IFRvOiBFcmFuIEhhbW1lci1M YWhhdg0KPiBDYzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiBTdWJqZWN0OiBSZTogW09B VVRILVdHXSBBdXRoIENvZGUgU3dhcCBBdHRhY2sNCj4NCj4gbWFraW5nIENTUkYgcHJldmVudGlv biBhIE1VU1QgYW5kIHJlY29tbWVuZGluZyB0aGUgc3RhdGUgcGFyYW1ldGVyIGFzDQo+IGltcGxl bWVudGF0aW9uIHBhdHRlcm4gaXMgb2sgd2l0aCBtZS4NCj4NCj4gcmVnYXJkcywNCj4gVG9yc3Rl bi4NCj4NCj4gQW0gMjEuMDguMjAxMSAyMTowMiwgc2NocmllYiBFcmFuIEhhbW1lci1MYWhhdjoN Cj4gSSBsaWdodCB0byB0aGUgcmVjZW50IGRpc2N1c3Npb24sIGRvIHlvdSBzdGlsbCBmZWVsIHRo YXQgY2hhbmdpbmcg4oCYc3RhdGXigJkgZnJvbQ0KPiBvcHRpb25hbCB0byByZXF1aXJlZCBpcyB0 aGUgYmVzdCBhcHByb2FjaD8NCj4NCj4gRUhMDQo+DQo+IEZyb206IFRvcnN0ZW4gTG9kZGVyc3Rl ZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0NCj4gU2VudDogU3VuZGF5LCBBdWd1 c3QgMjEsIDIwMTEgMTE6MDQgQU0NCj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2DQo+IENjOiBPQXV0 aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEF1dGggQ29k ZSBTd2FwIEF0dGFjaw0KPg0KPiBNeSBpbnRlbnRpb24gaXMgdG8gcmVxdWlyZSBjbGllbnRzIHRv IGltcGxlbWVudCBDU1JGIHByZXZlbnRpb24uIEkgdGhvdWdodA0KPiBtYWtpbmcgdGhlIHN0YXRl IHBhcmFtZXRlciBtYW5kYXRvcnkgd291bGQgYmUgdGhlIHN0cmFpZ2h0Zm9yd2FyZCB3YXkuDQo+ DQo+IHJlZ2FyZHMsDQo+IFRvcnN0ZW4uDQo+DQo+IEFtIDE4LjA4LjIwMTEgMDg6MDQsIHNjaHJp ZWIgRXJhbiBIYW1tZXItTGFoYXY6DQo+IEkgd291bGQgbGlrZSB0byBoZWFyIGZyb20gdGhlIG90 aGVyIDMgYXV0aG9ycyBvZiB0aGUgcHJvcG9zZWQgY2hhbmdlIGFib3V0DQo+IHRoZWlyIHJlYXNv bnMgZm9yIGNoYW5naW5nIHRoZSB1c2Ugb2Yg4oCYc3RhdGXigJkgZnJvbSByZWNvbW1lbmRlZCB0 byByZXF1aXJlZA0KPiBmb3IgQ1NSRiBwcmV2ZW50aW9uLiBJdCB3b3VsZCBhbHNvIGhlbHAgbW92 aW5nIHRoaXMgaXNzdWUgZm9yd2FyZCBpZiB0aGUgNA0KPiBhdXRob3JzIGNhbiBwcm92aWRlIGFu c3dlcnMgb3IgY2xhcmlmaWNhdGlvbnMgb24gdGhlIGlzc3VlcyByYWlzZWQgYmVsb3cuDQo+DQo+ IEFzc3VtaW5nIHdlIGNhbiBjb3VudCBhbGwgNCBhdXRob3JzIGFyZSBpbiBmYXZvciBvZiBtYWtp bmcgdGhlIGNoYW5nZSwgSQ0KPiBiZWxpZXZlIHdlIGhhdmUgYSB0aWUgKDQ6NCkgYW5kIHRoZXJl Zm9yZSBubyBjb25zZW5zdXMgZm9yIG1ha2luZyBpdCAoYXMgb2YNCj4gdGhpcyBwb2ludCkuIEhv d2V2ZXIsIHdlIGRpZCBpZGVudGlmeSBpc3N1ZXMgd2l0aCB0aGUgc2VjdGlvbuKAmXMgbGFuZ3Vh Z2UgYW5kDQo+IGNsYXJpdHkgd2hpY2ggd2Ugc2hvdWxkIGFkZHJlc3MgZWl0aGVyIHdheS4NCj4N Cj4gVG8gY2xhcmlmeSDigJMgSSBhbSBub3QgcHJvcG9zaW5nIHdlIGNsb3NlIHRoaXMgaXNzdWUg anVzdCB5ZXQuDQo+DQo+IEVITA0KPg0KPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIEVyYW4gSGFtbWVy LUxhaGF2DQo+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDE1LCAyMDExIDk6MzUgQU0NCj4gVG86IE9B dXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQXV0aCBD b2RlIFN3YXAgQXR0YWNrDQo+DQo+IFRvIGRlbW9uc3RyYXRlIHdoeSBtYWtpbmcgc3RhdGUgcmVx dWlyZWQgYXMgcHJvcG9zZWQgaXNu4oCZdCB2ZXJ5IGhlbHBmdWwsDQo+IGhlcmUgaXMgYW4gaW5j b21wbGV0ZSBsaXN0IG9mIG90aGVyIHJlcXVpcmVtZW50cyBuZWVkZWQgdG8gbWFrZSBhbg0KPiBl ZmZlY3RpdmUgQ1NSRjoNCj4NCj4gKiBTdGF0ZSB2YWx1ZSBtdXN0IG5vdCBiZSBlbXB0eSAoYSBj b21tb24gYnVnIGluIG1hbnkgaW1wbGVtZW50YXRpb25zDQo+IHVzaW5nIHNpbXBsZSB2YWx1ZSBj b21wYXJpc29uKS4NCj4NCj4gKiDigJhOb24tZ3Vlc3NhYmxl4oCZIGlzbuKAmXQgc3VmZmljaWVu dCBhcyBtb3N0IGRldmVsb3BlcnMgd2lsbCBzaW1wbHkgdXNlIGEgaGFzaCBvZg0KPiB0aGUgc2Vz c2lvbiBjb29raWUsIHdpdGggb3Igd2l0aG91dCBzYWx0IHdoaWNoIGlzbuKAmXQgc3VmZmljaWVu dC4gV2UgdXNlIOKAnGNhbm5vdA0KPiBiZSBnZW5lcmF0ZWQsIG1vZGlmaWVkLCBvciBndWVzc2Vk IHRvIHByb2R1Y2UgdmFsaWQgdmFsdWVz4oCdIGVsc2V3aGVyZSBpbg0KPiB0aGUgZG9jdW1lbnQs IGJ1dCB0aGlzIGlzIG11Y2ggZWFzaWVyIHRvIGdldCByaWdodCBmb3IgYWNjZXNzIHRva2VucyBh bmQNCj4gcmVmcmVzaCB0b2tlbnMgdGhhbiBDU1JGIHRva2VucyB3aGljaCBhcmUgb2Z0ZW4ganVz dCBzb21lIGFsZ29yaXRobSBvbiB0b3ANCj4gb2YgdGhlIHNlc3Npb24gY29va2llLg0KPg0KPiAq IFN0YXRlIENTUkYgdmFsdWUgc2hvdWxkIGJlIHNob3J0LWxpdmVkIG9yIGJhc2VkIG9uIGEgc2hv cnQtbGl2ZWQgc2Vzc2lvbg0KPiBjb29raWUgdG8gcHJldmVudCB0aGUgdXNlIG9mIGEgbGVha2Vk IHN0YXRlIHZhbHVlIGluIG11bHRpcGxlIGF0dGFja3Mgb24gdGhlDQo+IHNhbWUgdXNlciBzZXNz aW9uIG9uY2UgdGhlIGxlYWsgaXMgbm8gbG9uZ2VyIHZpYWJsZS4NCj4NCj4gSW4gYWRkaXRpb24s IHRoaXMgaXMgbm90IHdoYXQg4oCcc3RhdGXigJ0gd2FzIG9yaWdpbmFsbHkgaW50ZW5kZWQgZm9y LiBJZiB0aGUgd29ya2luZw0KPiBncm91cCBkZWNpZGVzIHRvIG1hbmRhdGUgYSBDU1JGIHBhcmFt ZXRlciwgaXQgc2hvdWxkIHByb2JhYmx5IGJlIGEgbmV3DQo+IHBhcmFtZXRlciB3aXRoIGEgbW9y ZSBhcHByb3ByaWF0ZSBuYW1lIChlLmcuIOKAmGNzcmbigJkpLiBCeSBmb3JjaW5nIGNsaWVudHMg dG8NCj4gdXNlIOKAnHN0YXRl4oCdIGZvciB0aGlzIHB1cnBvc2UsIGRldmVsb3BlcnMgd2lsbCBu ZWVkIHRvIHVzZSBkeW5hbWljIHF1ZXJpZXMgZm9yDQo+IG90aGVyIHN0YXRlIGluZm9ybWF0aW9u IHdoaWNoIGZ1cnRoZXIgcmVkdWNlcyB0aGUgc2VjdXJpdHkgb2YgdGhlIHByb3RvY29sDQo+IChh cyB0aGUgZHJhZnQgcmVjb21tZW5kcyBub3QgdXNpbmcgZHluYW1pYyBjYWxsYmFjayBxdWVyeSBj b21wb25lbnRzKS4NCj4gRW5jb2RpbmcgYm90aCBDU1JGIHRva2VucyBhbmQgb3RoZXIgc3RhdGUg aW5mb3JtYXRpb24gY2FuIGJlIG5vbi1pbnR1aXRpdmUNCj4gb3IgY29tcGxpY2F0ZWQgZm9yIHNv bWUgZGV2ZWxvcGVycy9wbGF0Zm9ybXMuDQo+DQo+IEVITA0KPg0KPg0KPg0KPg0KPiBGcm9tOiBF cmFuIEhhbW1lci1MYWhhdg0KPiBTZW50OiBGcmlkYXksIEF1Z3VzdCAxMiwgMjAxMSAyOjUzIFBN DQo+IFRvOiBBbnRob255IE5hZGFsaW47IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4gU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gQXV0aCBDb2RlIFN3YXAgQXR0YWNrDQo+DQo+IFRoaXMgaXMg cmVhbGx5IGp1c3QgYSBmbGF2b3Igb2YgQ1NSRiBhdHRhY2tzLiBJIGhhdmUgbm8gb2JqZWN0aW9u cyB0byBiZXR0ZXINCj4gZG9jdW1lbnRpbmcgaXQgKHRob3VnaCBJIGZlZWwgdGhlIGN1cnJlbnQg dGV4dCBpcyBhbHJlYWR5IHN1ZmZpY2llbnQpLCBidXQgd2UNCj4gY2FuJ3QgcmVhbGlzdGljYWxs eSBleHBlY3QgdG8gaWRlbnRpZnkgYW5kIGNsb3NlIGV2ZXJ5IHBvc3NpYmxlIGJyb3dzZXItYmFz ZWQNCj4gYXR0YWNrLiBBIG5ldyBvbmUgaXMgaW52ZW50ZWQgZXZlcnkgb3RoZXIgd2Vlay4NCj4N Cj4gVGhlIHByb2JsZW0gd2l0aCB0aGlzIHRleHQgaXMgdGhhdCBkZXZlbG9wZXJzIHdobyBkbyBu byB1bmRlcnN0YW5kIENTUkYNCj4gYXR0YWNrcyBhcmUgbm90IGxpa2VseSB0byBpbXBsZW1lbnQg aXQgY29ycmVjdGx5IHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gVGhvc2UNCj4gd2hvIHVuZGVyc3Rh bmQgaXQgZG8gbm90IG5lZWQgdGhlIGV4dHJhIHZlcmJpYWdlIHdoaWNoIGlzIG1vcmUgY29uZnVz aW5nDQo+IHRoYW4gaGVscGZ1bC4NCj4NCj4gQXMgZm9yIHRoZSBuZXcgcmVxdWlyZW1lbnRzLCB0 aGV5IGFyZSBpbnN1ZmZpY2llbnQgdG8gYWN0dWFsbHkgYWNjb21wbGlzaA0KPiB3aGF0IHRoZSBh dXRob3JzIHByb3Bvc2Ugd2l0aG91dCBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBvbiBzdGF0ZSBs b2NhbA0KPiBzdG9yYWdlIGFuZCB2ZXJpZmljYXRpb24gdG8gY29tcGxldGUgdGhlIGZsb3cuIEFs c28sIHRoZSBwcm9wb3NlZCB0ZXh0IG5lZWRzDQo+IGNsYXJpZmljYXRpb25zIGFzIG5vdGVkIGJl bG93Lg0KPg0KPg0KPiBGcm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNv bT4NCj4gRGF0ZTogRnJpLCAxMiBBdWcgMjAxMSAxMjowNjozNiAtMDcwMA0KPiBUbzogIk9BdXRo IFdHIChvYXV0aEBpZXRmLm9yZykiIDxvYXV0aEBpZXRmLm9yZz4NCj4gU3ViamVjdDogW09BVVRI LVdHXSBBdXRoIENvZGUgU3dhcCBBdHRhY2sNCj4NCj4NCj4NCj4gUmVjb21tZW5kZWQgQ2hhbmdl cyB0byBkcmFmdC1pZXRmLW9hdXRoLXYyDQo+DQo+IEluIHNlY3Rpb24gNCwgcmVxdWVzdCBvcHRp b25zIChlLmcuIDQuMS4xKSBmZWF0dXJpbmcgInN0YXRlIiBzaG91bGQgY2hhbmdlDQo+IGZyb206 DQo+DQo+IHN0YXRlDQo+IE9QVElPTkFMLiBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xp ZW50IHRvIG1haW50YWluIHN0YXRlIGJldHdlZW4NCj4gdGhlIHJlcXVlc3QgYW5kIGNhbGxiYWNr LiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuDQo+IHJl ZGlyZWN0aW5nIHRoZSB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudC4NCj4NCj4gdG86DQo+ DQo+IHN0YXRlDQo+IFJFUVVJUkVELiBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xpZW50 IHRvIG1haW50YWluIHN0YXRlIGJldHdlZW4NCj4gdGhlIHJlcXVlc3QgYW5kIGNhbGxiYWNrLiBU aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuDQo+IHJlZGly ZWN0aW5nIHRoZSB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudC4gVGhlIGVuY29kZWQgdmFs dWUgU0hPVUxEDQo+IGVuYWJsZSB0aGUgY2xpZW50IGFwcGxpY2F0aW9uIHRvIGRldGVybWluZSB0 aGUgdXNlci1jb250ZXh0IHRoYXQgd2FzIGFjdGl2ZSBhdA0KPiB0aGUgdGltZSBvZiB0aGUgIHJl cXVlc3QgKHNlZSBzZWN0aW9uIDEwLjEyKS4gVGhlIHZhbHVlIE1VU1QgTk9UIGJlDQo+IGd1ZXNz YWJsZSBvciBwcmVkaWN0YWJsZSwgYW5kIE1VU1QgYmUga2VwdCBjb25maWRlbnRpYWwuDQo+DQo+ DQo+IE1ha2luZyB0aGUgcGFyYW1ldGVyIHJlcXVpcmVkIHdpdGhvdXQgbWFraW5nIGl0cyB1c2Fn ZSByZXF1aXJlZCAoSS5lLg0KPiAidmFsdWUgU0hPVUxEIGVuYWJsZSIpIGFjY29tcGxpc2hlcyBu b3RoaW5nLiBBbHNvLCB3aGF0IGRvZXMgIk1VU1QgYmUNCj4ga2VwdCBjb25maWRlbnRpYWwiIG1l YW4/IENvbmZpZGVudGlhbCBmcm9tIHdoYXQ/IFdoeSBzcGVjaWZ5IGFuICJlbmNvZGVkDQo+IHZh bHVlIj8NCj4NCj4NCj4gU2VjdGlvbiAxMC4xMiBDcm9zcy1TaXRlIFJlcXVlc3QgRm9yZ2VyeQ0K Pg0KPiBDaGFuZ2UgdG86DQo+DQo+IENyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IChDU1JGKSBp cyBhIHdlYi1iYXNlZCBhdHRhY2sgd2hlcmVieSBIVFRQDQo+IHJlcXVlc3RzIGFyZSB0cmFuc21p dHRlZCBmcm9tIHRoZSB1c2VyLWFnZW50IG9mIGFuIGVuZC11c2VyIHRoZSBzZXJ2ZXINCj4gdHJ1 c3RzIG9yIGhhcyBhdXRoZW50aWNhdGVkLiBDU1JGIGF0dGFja3MgZW5hYmxlIHRoZSBhdHRhY2tl ciB0byBpbnRlcm1peCB0aGUNCj4gYXR0YWNrZXIncyBzZWN1cml0eSBjb250ZXh0IHdpdGggdGhh dCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgcmVzdWx0aW5nIGluIGENCj4gY29tcHJvbWlzZSBvZiBl aXRoZXIgdGhlIHJlc291cmNlIHNlcnZlciBvciBvZiB0aGUgY2xpZW50IGFwcGxpY2F0aW9uIGl0 c2VsZi4gSW4NCj4gdGhlIE9BdXRoIGNvbnRleHQsIHN1Y2ggYXR0YWNrcyBhbGxvdyBhbiBhdHRh Y2tlciB0byBpbmplY3QgdGhlaXIgb3duDQo+IGF1dGhvcml6YXRpb24gY29kZSBvciBhY2Nlc3Mg dG9rZW4gaW50byBhIGNsaWVudCwgd2hpY2ggY2FuIHJlc3VsdCBpbiB0aGUgY2xpZW50DQo+IHVz aW5nIGFuIGFjY2VzcyB0b2tlbiBhc3NvY2lhdGVkIHdpdGggdGhlIGF0dGFja2VyJ3MgYWNjb3Vu dCByYXRoZXIgdGhhbiB0aGUNCj4gdmljdGltJ3MuIERlcGVuZGluZyBvbiB0aGUgbmF0dXJlIG9m IHRoZSBjbGllbnQgYW5kIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2VzLA0KPiB0aGlzIGNhbiBoYXZl IHVuZGVzaXJhYmxlIGFuZCBkYW1hZ2luZyBlZmZlY3RzLg0KPg0KPiBJbiBvcmRlciB0byBwcmV2 ZW50IHN1Y2ggYXR0YWNrcywgdGhlIGNsaWVudCBhcHBsaWNhdGlvbiBNVVNUIGVuY29kZSBhIG5v bi0NCj4gZ3Vlc3NhYmxlLCBjb25maWRlbnRpYWwgZW5kLXVzZXIgYXJ0aWZhY3QgYW5kIHN1Ym1p dCBhcyB0aGUgInN0YXRlIiBwYXJhbWV0ZXINCj4gdG8gYXV0aG9yaXphdGlvbiBhbmQgYWNjZXNz IHRva2VuIHJlcXVlc3RzIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlDQo+IGNsaWVu dCBNVVNUIGtlZXAgdGhlIHN0YXRlIHZhbHVlIGluIGEgbG9jYXRpb24gYWNjZXNzaWJsZSBvbmx5 IGJ5IHRoZSBjbGllbnQgb3INCj4gdGhlIHVzZXItYWdlbnQgKGkuZS4sIHByb3RlY3RlZCBieSBz YW1lLW9yaWdpbiBwb2xpY3kpLCBmb3IgZXhhbXBsZSwgdXNpbmcgYQ0KPiBET00gdmFyaWFibGUs IEhUVFAgY29va2llLCBvciBIVE1MNSBjbGllbnQtc2lkZSBzdG9yYWdlLg0KPg0KPiBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgaW5jbHVkZXMgdGhlIHZhbHVlIG9mIHRoZSAic3RhdGUiIHBhcmFt ZXRlciB3aGVuDQo+IHJlZGlyZWN0aW5nIHRoZSB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVu dC4gVXBvbiByZWNlaXZpbmcgYSByZWRpcmVjdCwgdGhlDQo+IGNsaWVudCBhcHBsaWNhdGlvbiBN VVNUIGNvbmZpcm0gdGhhdCByZXR1cm5lZCB2YWx1ZSBvZiAic3RhdGUiIGNvcnJlc3BvbmRzDQo+ IHRvIHRoZSBzdGF0ZSB2YWx1ZSBvZiB0aGUgdXNlci1hZ2VudCdzIHVzZXIgc2Vzc2lvbi4gSWYg dGhlIGVuZC11c2VyIHNlc3Npb24NCj4gcmVwcmVzZW50cyBhbiBhdXRoZW50aWNhdGVkIHVzZXIt aWRlbnRpdHksIHRoZSBjbGllbnQgTVVTVCBlbnN1cmUgdGhhdCB0aGUNCj4gdXNlci1pZGVudGl0 eSBoYXMgTk9UIGNoYW5nZWQuDQo+DQo+DQo+IFRoZSBhYm92ZSB0ZXh0IHVzZXMgJ3VzZXItY29u dGV4dCcgYW5kIHRoaXMgJ3VzZXItaWRlbnRpdHknLiBOZWl0aGVyIHRlcm0gaXMNCj4gZGVmaW5l ZC4NCj4NCj4gRUhMDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxp bmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= From eran@hueniverse.com Sun Sep 4 16: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 54C9B21F8A4D for ; Sun, 4 Sep 2011 16:35:22 -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 yZn6SyUyYmGc for ; Sun, 4 Sep 2011 16:35: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 A0D3B21F86C2 for ; Sun, 4 Sep 2011 16:35:21 -0700 (PDT) Received: (qmail 9665 invoked from network); 4 Sep 2011 23:37:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Sep 2011 23:37:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Sun, 4 Sep 2011 16:37:04 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sun, 4 Sep 2011 16:35:13 -0700 Thread-Topic: Request for open issues resolution Thread-Index: AcxrWkKEXZILxjG9SX+C2LSEcJb56g== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D9@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_90C41DD21FB7C64BB94121FBBC2E7234518A4F23D9P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Request for open issues resolution 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, 04 Sep 2011 23:35:22 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234518A4F23D9P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable #19 - no text proposed, consider current text sufficient. Close. #20 - reference to DOM variable removed. Close. #21 - resolved by new text, no comments received. Close. #24 - pending comments. Close if agreed to by Torsten. #25 - no comments received to proposed text which has been applied. Close. I will post -21 shortly and will follow with -22 if needed later this week.= I am only posting -21 to help facilitate the discussion moving forward, no= t to imply consensus on items still open (issue #24 and new CSRF text). EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234518A4F23D9P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

#19 – no t= ext proposed, consider current text sufficient. Close.

#20 – reference to DOM variable removed. Close.

#21 – resolved by new text, no comments = received. Close.

#24 – pending com= ments. Close if agreed to by Torsten.

#2= 5 – no comments received to proposed text which has been applied. Clo= se.

 

I will post -21 shortly and will follow with -22 if needed later this= week. I am only posting -21 to help facilitate the discussion moving forwa= rd, not to imply consensus on items still open (issue #24 and new CSRF text= ).

 

EHL

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234518A4F23D9P3PW5EX1MB01E_-- From internet-drafts@ietf.org Sun Sep 4 16:42: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 F35C621F8A4B; Sun, 4 Sep 2011 16:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 WGDP548dFLa0; Sun, 4 Sep 2011 16:42:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9879B21F86FF; Sun, 4 Sep 2011 16:42:31 -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: <20110904234231.31813.59424.idtracker@ietfa.amsl.com> Date: Sun, 04 Sep 2011 16:42:31 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-21.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: Sun, 04 Sep 2011 23:42:32 -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 : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer-Lahav David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-21.txt Pages : 64 Date : 2011-09-04 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-21.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-v2-21.txt From eran@hueniverse.com Sun Sep 4 16:50: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 3C95821F8A7E for ; Sun, 4 Sep 2011 16:50:03 -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 9sS+xl-NYsor for ; Sun, 4 Sep 2011 16:50:02 -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 8B1B321F87FC for ; Sun, 4 Sep 2011 16:50:02 -0700 (PDT) Received: (qmail 10089 invoked from network); 4 Sep 2011 23:51:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Sep 2011 23:51:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 4 Sep 2011 16:51:45 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sun, 4 Sep 2011 16:49:54 -0700 Thread-Topic: Draft -21 next steps Thread-Index: AcxrXQ02+nNo11WXRHue7QJ+toz+wQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23DB@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_90C41DD21FB7C64BB94121FBBC2E7234518A4F23DBP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Draft -21 next steps 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, 04 Sep 2011 23:50:03 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234518A4F23DBP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to ask the chairs to declare a 2 weeks review period limited to ch= anges made since -20 after which we will either declare -21 as the final WG= draft or publish a quick -22 with all changes agreed prior on the list and= no additional WG review period. Of course, the chairs can change all these= rules as they see fit. EHL --_000_90C41DD21FB7C64BB94121FBBC2E7234518A4F23DBP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like t= o ask the chairs to declare a 2 weeks review period limited to changes made= since -20 after which we will either declare -21 as the final WG draft or = publish a quick -22 with all changes agreed prior on the list and no additi= onal WG review period. Of course, the chairs can change all these rules as = they see fit.

 

EHL

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234518A4F23DBP3PW5EX1MB01E_-- From mike@mtcc.com Tue Sep 6 10:39: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 1202C21F8C8C for ; Tue, 6 Sep 2011 10:39:14 -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 LFSzEVVmGkpO for ; Tue, 6 Sep 2011 10:39:13 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 65EAA21F8C8A for ; Tue, 6 Sep 2011 10:39:13 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86HewrU018485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Sep 2011 10:41:00 -0700 Message-ID: <4E665B25.6090709@mtcc.com> Date: Tue, 06 Sep 2011 10:40:53 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1572; t=1315330860; x=1316194860; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20problem=20statement |Sender:=20 |To:=20oauth@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=R9UKsxxnHquOWxWMhwk9FMusDHQYHq4imcDmirzMH30=; b=Y4FJOGzRZbO6bWLdI3/59tSyvaJ7zCOsGC9Q6UAm651cX3Vqz2r4Ca/1N9 Nl6UP/P4K3ZNA53sOBH1RkyF0lFTkRANoYOIRIRFJz4LSv+UzT7iaiK09S/L KEiKGQlq36ndwtNAfNqr2DbT11UAvfjiCw38bJ5cqWfB9q5AnDDn8=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: [OAUTH-WG] problem statement 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, 06 Sep 2011 17:39:14 -0000 Hi all, Barry suggested that I might subscribe and explain what I sent him. My basic problem is that in neither the protocol nor the threats drafts, I can't seem to find what problem is actually trying to be solved with oauth, and what assumptions you're making about various elements. Here's what I did. I've written an app, and I wanted re-integrate the ability to send tweets after they deprecated Basic. So the app has a webView (android, iphone...) which it obviously completely controls. With oauth, the webview UA will ultimately redirect off to Twitter's site to collect the user's credentials and grant my app's backend an access token (sorry if I get terminology screwed up, i'm just coming up to speed). What occurs to me is that webview affords exactly zero protection from my client (ie, the app) from getting the user's twitter credentials. All I have to do is set up a keypress handler on that webview and in a few minutes of hacking I have a key logger. etc. So what I can't tell is whether this is a "problem" or not, because I don't know what problem you're trying to solve. If the object of oauth isn't to keep user/server credentials out of the hands of a third party, then what is it trying to solve? Is there an expectation that the UA is trusted by the user/server? What happens when that's not the case? Regardless of whether I'm misunderstanding, it would sure be nice to have both the problem and your assumptions laid out, hopefully with some prominence so you don't get these sort of dumb questions. Mike From igor.faynberg@alcatel-lucent.com Tue Sep 6 11:08: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 8819B21F8C06 for ; Tue, 6 Sep 2011 11:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 mxUc4l1W5e9E for ; Tue, 6 Sep 2011 11:08:20 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D926021F8BCB for ; Tue, 6 Sep 2011 11:08:19 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p86IA5kG003453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Sep 2011 13:10:05 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p86IA4sm010187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Sep 2011 13:10:05 -0500 Received: from [135.244.40.187] (faynberg.lra.lucent.com [135.244.40.187]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p86IA3CV010681; Tue, 6 Sep 2011 13:10:04 -0500 (CDT) Message-ID: <4E6661FA.7050804@alcatel-lucent.com> Date: Tue, 06 Sep 2011 14:10:02 -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: <4E665B25.6090709@mtcc.com> In-Reply-To: <4E665B25.6090709@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [OAUTH-WG] problem statement 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: Tue, 06 Sep 2011 18:08:20 -0000 Mike, You've got the problem statement right: allowing the user to authorize resource access to another party without divulging user's credentials is the objective of OAuth. You are also right in that the attack you have described defies the whole purpose of OAuth. I do not think though that it is related to OAuth per se. To this end, the security work led by Torsten has thoroughly analyzed the protocol and specified protection against multiple protocol attacks. From what you described, it appears to me that the attack you mention is not related to the protocol but rather to the user's environment. There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like the problem rests with the implementation of WebView. If I am wrong, I would appreciate a detailed description of what happened. Igor On 9/6/2011 1:40 PM, Michael Thomas wrote: > Hi all, > > Barry suggested that I might subscribe and explain what I sent him. > > My basic problem is that in neither the protocol nor the threats drafts, > I can't seem to find what problem is actually trying to be solved with > oauth, and what assumptions you're making about various elements. > > Here's what I did. I've written an app, and I wanted re-integrate the > ability to send tweets after they deprecated Basic. So the app has a > webView (android, iphone...) which it obviously completely controls. > With oauth, the webview UA will ultimately redirect off to Twitter's > site to collect the user's credentials and grant my app's backend an > access token (sorry if I get terminology screwed up, i'm just coming > up to speed). > > What occurs to me is that webview affords exactly zero protection from > my client (ie, the app) from getting the user's twitter credentials. All > I have to do is set up a keypress handler on that webview and in a few > minutes of hacking I have a key logger. etc. > > So what I can't tell is whether this is a "problem" or not, because I > don't know what problem you're trying to solve. If the object of oauth > isn't to keep user/server credentials out of the hands of a third party, > then what is it trying to solve? Is there an expectation that the > UA is trusted by the user/server? What happens when that's not the case? > > Regardless of whether I'm misunderstanding, it would sure be nice to have > both the problem and your assumptions laid out, hopefully with some > prominence > so you don't get these sort of dumb questions. > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From paul.madsen@gmail.com Tue Sep 6 11:10: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 5CF8021F8C49 for ; Tue, 6 Sep 2011 11:10:09 -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 2fx4V74hqzRo for ; Tue, 6 Sep 2011 11:10:08 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA3F121F8C3C for ; Tue, 6 Sep 2011 11:10:07 -0700 (PDT) Received: by bkar4 with SMTP id r4so6661783bka.31 for ; Tue, 06 Sep 2011 11:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=sKnYTP/KJu9sU1MZ6FzHGLe7ki6znMisBiytab1mcUU=; b=c9N4c1IXK2B1Fb59dPNpbqlhzWId0Js+0dtI+SJC6kvgWRZEmYrIeFE0z4iWzwU19t MEZnM96U/W/JXoF82VPgfRPDMQrQuDEh0jEuPRgARZRJ05EjA4NNOZVvlOsBXqS/BAf8 hD0tv+8VFBSMeIavr/Dybn974k5gY9N6Zr6A4= Received: by 10.204.142.18 with SMTP id o18mr2906181bku.30.1315332707769; Tue, 06 Sep 2011 11:11:47 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id y3sm1256254bkw.4.2011.09.06.11.11.46 (version=SSLv3 cipher=OTHER); Tue, 06 Sep 2011 11:11:47 -0700 (PDT) Message-ID: <4E66629B.5000100@gmail.com> Date: Tue, 06 Sep 2011 14:12:43 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> In-Reply-To: <4E6661FA.7050804@alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------000108080600010407040803" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:10:09 -0000 This is a multi-part message in MIME format. --------------000108080600010407040803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit that is the original problem statement, but surely no longer the only one On 9/6/11 2:10 PM, Igor Faynberg wrote: > Mike, > > You've got the problem statement right: allowing the user to > authorize resource access to another party without divulging user's > credentials is the objective of OAuth. You are also right in that the > attack you have described defies the whole purpose of OAuth. I do not > think though that it is related to OAuth per se. > > To this end, the security work led by Torsten has thoroughly analyzed > the protocol and specified protection against multiple protocol > attacks. From what you described, it appears to me that the attack > you mention is not related to the protocol but rather to the user's > environment. There is no possible protection from key loggers that a > protocol can implement. I could be mistaken; in any case, it looks > like the problem rests with the implementation of WebView. > > If I am wrong, I would appreciate a detailed description of what > happened. > > Igor > > On 9/6/2011 1:40 PM, Michael Thomas wrote: >> Hi all, >> >> Barry suggested that I might subscribe and explain what I sent him. >> >> My basic problem is that in neither the protocol nor the threats drafts, >> I can't seem to find what problem is actually trying to be solved with >> oauth, and what assumptions you're making about various elements. >> >> Here's what I did. I've written an app, and I wanted re-integrate the >> ability to send tweets after they deprecated Basic. So the app has a >> webView (android, iphone...) which it obviously completely controls. >> With oauth, the webview UA will ultimately redirect off to Twitter's >> site to collect the user's credentials and grant my app's backend an >> access token (sorry if I get terminology screwed up, i'm just coming >> up to speed). >> >> What occurs to me is that webview affords exactly zero protection from >> my client (ie, the app) from getting the user's twitter credentials. All >> I have to do is set up a keypress handler on that webview and in a few >> minutes of hacking I have a key logger. etc. >> >> So what I can't tell is whether this is a "problem" or not, because I >> don't know what problem you're trying to solve. If the object of oauth >> isn't to keep user/server credentials out of the hands of a third party, >> then what is it trying to solve? Is there an expectation that the >> UA is trusted by the user/server? What happens when that's not the case? >> >> Regardless of whether I'm misunderstanding, it would sure be nice to >> have >> both the problem and your assumptions laid out, hopefully with some >> prominence >> so you don't get these sort of dumb questions. >> >> Mike >> _______________________________________________ >> 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 --------------000108080600010407040803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit that is the original problem statement, but surely no longer the only one

On 9/6/11 2:10 PM, Igor Faynberg wrote:
Mike,

You've got the problem statement right: allowing the user to authorize  resource access to another party without divulging user's credentials is the objective of OAuth. You are also right in that the attack you have described defies the whole purpose of OAuth.  I do not think though that it is related to OAuth per se.

To this end, the security work led by Torsten has thoroughly analyzed the protocol and specified protection against multiple protocol attacks.  From what you described, it appears to me that the attack you mention is not related to the protocol but rather to the user's environment.  There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like the problem rests with the implementation of WebView.

If I am wrong, I would appreciate a detailed description of what happened.

Igor

On 9/6/2011 1:40 PM, Michael Thomas wrote:
Hi all,

Barry suggested that I might subscribe and explain what I sent him.

My basic problem is that in neither the protocol nor the threats drafts,
I can't seem to find what problem is actually trying to be solved with
oauth, and what assumptions you're making about various elements.

Here's what I did. I've written an app, and I wanted re-integrate the
ability to send tweets after they deprecated Basic. So the app has a
webView (android, iphone...) which it obviously completely controls.
With oauth, the webview UA will ultimately redirect off to Twitter's
site to collect the user's credentials and grant my app's backend an
access token (sorry if I get terminology screwed up, i'm just coming
up to speed).

What occurs to me is that webview affords exactly zero protection from
my client (ie, the app) from getting the user's twitter credentials. All
I have to do is set up a keypress handler on that webview and in a few
minutes of hacking I have a key logger. etc.

So what I can't tell is whether this is a "problem" or not, because I
don't know what problem you're trying to solve. If the object of oauth
isn't to keep user/server credentials out of the hands of a third party,
then what is it trying to solve? Is there an expectation that the
UA is trusted by the user/server? What happens when that's not the case?

Regardless of whether I'm misunderstanding, it would sure be nice to have
both the problem and your assumptions laid out, hopefully with some prominence
so you don't get these sort of dumb questions.

Mike
_______________________________________________
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
--------------000108080600010407040803-- From eran@hueniverse.com Tue Sep 6 11:12: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 8D44921F8CB3 for ; Tue, 6 Sep 2011 11:12:51 -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 DN+YSvkRHPAG for ; Tue, 6 Sep 2011 11:12: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 B5B8C21F8B58 for ; Tue, 6 Sep 2011 11:12:50 -0700 (PDT) Received: (qmail 22905 invoked from network); 6 Sep 2011 18:14:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Sep 2011 18:14:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 6 Sep 2011 11:14:32 -0700 From: Eran Hammer-Lahav To: "igor.faynberg@alcatel-lucent.com" Date: Tue, 6 Sep 2011 11:14:25 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: AcxswNLvFuAFja1QTXyASEJbYfEyoA== Message-ID: References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> In-Reply-To: <4E6661FA.7050804@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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:12:51 -0000 I agree. If you are going to install a native app, you better trust it not = to do bad things. Grabbing your password is the least interesting thing suc= h an app can abuse. I don't see any need to change the v2 draft.=20 EHL On Sep 6, 2011, at 11:10, "Igor Faynberg" wrote: > Mike, >=20 > You've got the problem statement right: allowing the user to authorize =20 > resource access to another party without divulging user's credentials is= =20 > the objective of OAuth. You are also right in that the attack you have=20 > described defies the whole purpose of OAuth. I do not think though that= =20 > it is related to OAuth per se. >=20 > To this end, the security work led by Torsten has thoroughly analyzed=20 > the protocol and specified protection against multiple protocol=20 > attacks. From what you described, it appears to me that the attack you=20 > mention is not related to the protocol but rather to the user's=20 > environment. There is no possible protection from key loggers that a=20 > protocol can implement. I could be mistaken; in any case, it looks like=20 > the problem rests with the implementation of WebView. >=20 > If I am wrong, I would appreciate a detailed description of what happened= . >=20 > Igor >=20 > On 9/6/2011 1:40 PM, Michael Thomas wrote: >> Hi all, >>=20 >> Barry suggested that I might subscribe and explain what I sent him. >>=20 >> My basic problem is that in neither the protocol nor the threats drafts, >> I can't seem to find what problem is actually trying to be solved with >> oauth, and what assumptions you're making about various elements. >>=20 >> Here's what I did. I've written an app, and I wanted re-integrate the >> ability to send tweets after they deprecated Basic. So the app has a >> webView (android, iphone...) which it obviously completely controls. >> With oauth, the webview UA will ultimately redirect off to Twitter's >> site to collect the user's credentials and grant my app's backend an >> access token (sorry if I get terminology screwed up, i'm just coming >> up to speed). >>=20 >> What occurs to me is that webview affords exactly zero protection from >> my client (ie, the app) from getting the user's twitter credentials. All >> I have to do is set up a keypress handler on that webview and in a few >> minutes of hacking I have a key logger. etc. >>=20 >> So what I can't tell is whether this is a "problem" or not, because I >> don't know what problem you're trying to solve. If the object of oauth >> isn't to keep user/server credentials out of the hands of a third party, >> then what is it trying to solve? Is there an expectation that the >> UA is trusted by the user/server? What happens when that's not the case? >>=20 >> Regardless of whether I'm misunderstanding, it would sure be nice to hav= e >> both the problem and your assumptions laid out, hopefully with some=20 >> prominence >> so you don't get these sort of dumb questions. >>=20 >> Mike >> _______________________________________________ >> 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 john@jkemp.net Tue Sep 6 11:13: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 B0F6921F8CA7 for ; Tue, 6 Sep 2011 11:13:44 -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 93DkSCHnmbeT for ; Tue, 6 Sep 2011 11:13:44 -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 BB0BF21F8B58 for ; Tue, 6 Sep 2011 11:13:39 -0700 (PDT) Received: (qmail 14497 invoked by uid 0); 6 Sep 2011 18:15:26 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by oproxy1.bluehost.com with SMTP; 6 Sep 2011 18:15:26 -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=ZRQO71qM5uZU20d8J8xoMuBC/A2lefSfEI4szQkM4Z4=; b=RLMBZDRx4eTgqwz66Nc/RxX8ezGmHmuXQbjqT6Xy62Wbou6WUDh52dwghqDqcwkYXUW8mWZtBwDcOjzowa4UraHnP0vc+pJmxJf6QDO5Jfg7fCAvVe/0saKHoBtQRvHZ; Received: from cpe-74-67-30-101.nycap.res.rr.com ([74.67.30.101] helo=[192.168.1.110]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1R10BC-0000ib-Ic; Tue, 06 Sep 2011 12:15:26 -0600 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <4E665B25.6090709@mtcc.com> Date: Tue, 6 Sep 2011 14:15:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E665B25.6090709@mtcc.com> To: Michael Thomas 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@ietf.org Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:13:44 -0000 Michael, On Sep 6, 2011, at 1:40 PM, Michael Thomas wrote: > Hi all, >=20 > Barry suggested that I might subscribe and explain what I sent him. >=20 > My basic problem is that in neither the protocol nor the threats = drafts, > I can't seem to find what problem is actually trying to be solved with > oauth, and what assumptions you're making about various elements. >=20 > Here's what I did. I've written an app, and I wanted re-integrate the > ability to send tweets after they deprecated Basic. So the app has a > webView (android, iphone...) which it obviously completely controls. > With oauth, the webview UA will ultimately redirect off to Twitter's > site to collect the user's credentials and grant my app's backend an > access token (sorry if I get terminology screwed up, i'm just coming > up to speed). >=20 > What occurs to me is that webview affords exactly zero protection from > my client (ie, the app) from getting the user's twitter credentials. = All > I have to do is set up a keypress handler on that webview and in a few > minutes of hacking I have a key logger. etc. If an attacker is able to log key presses from a "webview" created by = your app with their own app/library, then this is a threat to the user's = credentials, yes. >=20 > So what I can't tell is whether this is a "problem" or not, because I > don't know what problem you're trying to solve. Broadly-speaking, the "problem" to be solved is to avoid the requirement = for a user to share her username/password at one web application with = another. OAuth is similar in that regard to Kerberos or SAML - a = "ticket" system.=20 =20 > If the object of oauth > isn't to keep user/server credentials out of the hands of a third = party, > then what is it trying to solve? Is there an expectation that the > UA is trusted by the user/server? Not in all cases, no. It depends on which OAuth "flow" you use for your = application. In general, I would say that the UA is NOT to be trusted by = the user/server. > What happens when that's not the case? >=20 > Regardless of whether I'm misunderstanding, it would sure be nice to = have > both the problem and your assumptions laid out, hopefully with some = prominence > so you don't get these sort of dumb questions. One point I would mention first is that your question isn't dumb ;)=20 But, as I noted, OAuth seeks to avoid the requirement for a user to = share her username/password at one web application with another. That = being said, there are lots of ways to get that wrong, and the way of = resolving those is to implement OAuth-based applications using the = security features available in their specific environments, as these = vary quite a lot. OAuth provides a number of different protocol flows to = help with that, and "security considerations" that discuss known = security threats within various environments. By careful reading, you = can determine which flow is appropriate for your application, and which = security features should be used to avoid the threats to your = application. Regards, - John >=20 > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mike@mtcc.com Tue Sep 6 11: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 CB04221F8CCB for ; Tue, 6 Sep 2011 11:16:02 -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 c8wRlMRKL167 for ; Tue, 6 Sep 2011 11:16:02 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 02ADE21F8CC6 for ; Tue, 6 Sep 2011 11:16:01 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86IHhmi031358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 11:17:44 -0700 Message-ID: <4E6663C3.2030506@mtcc.com> Date: Tue, 06 Sep 2011 11:17:39 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> In-Reply-To: <4E6661FA.7050804@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3533; t=1315333065; x=1316197065; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20igor.faynberg@alcatel-lucent.com |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Yo3p50TcL9TYmqCxsvsn4x1s1Z29BtQrIuKTVRukjIE=; b=AppE3s03Li+ICihkc61D7kvg/6KrHCdgjm4jPUK8dh5bB9tRpHu5lHgT9l LB6bjA8HaEMptdK4RgOIE+9gPAr4lv9bHu2iXYOy9htonJEKNpzt1UqTyfCr LBt5td3ed52BfO8pRBuHh24QJ+TY8ty6kfBodeTBDNpYAALLoHEwI=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:16:02 -0000 Igor Faynberg wrote: > Mike, > > You've got the problem statement right: allowing the user to authorize > resource access to another party without divulging user's credentials is > the objective of OAuth. You are also right in that the attack you have > described defies the whole purpose of OAuth. I do not think though that > it is related to OAuth per se. > > To this end, the security work led by Torsten has thoroughly analyzed > the protocol and specified protection against multiple protocol > attacks. From what you described, it appears to me that the attack you > mention is not related to the protocol but rather to the user's > environment. There is no possible protection from key loggers that a > protocol can implement. I could be mistaken; in any case, it looks like > the problem rests with the implementation of WebView. There is no problem with the webview; it's working completely as intended. An embedded webview is not a fortress for the sake of the user/server, it's a UI element that can be manipulated by an app. And even if Android, say, did try to make keyboard logging impossible, I could always create my own webview UA that allowed me to log keystrokes after it rendered the server's login page. So it appears that there is an implicit expectation that the UA is "trusted". Well, here's a case where that's not the case. Can the server tell the difference? Mike > > If I am wrong, I would appreciate a detailed description of what happened. > > Igor > > On 9/6/2011 1:40 PM, Michael Thomas wrote: >> Hi all, >> >> Barry suggested that I might subscribe and explain what I sent him. >> >> My basic problem is that in neither the protocol nor the threats drafts, >> I can't seem to find what problem is actually trying to be solved with >> oauth, and what assumptions you're making about various elements. >> >> Here's what I did. I've written an app, and I wanted re-integrate the >> ability to send tweets after they deprecated Basic. So the app has a >> webView (android, iphone...) which it obviously completely controls. >> With oauth, the webview UA will ultimately redirect off to Twitter's >> site to collect the user's credentials and grant my app's backend an >> access token (sorry if I get terminology screwed up, i'm just coming >> up to speed). >> >> What occurs to me is that webview affords exactly zero protection from >> my client (ie, the app) from getting the user's twitter credentials. All >> I have to do is set up a keypress handler on that webview and in a few >> minutes of hacking I have a key logger. etc. >> >> So what I can't tell is whether this is a "problem" or not, because I >> don't know what problem you're trying to solve. If the object of oauth >> isn't to keep user/server credentials out of the hands of a third party, >> then what is it trying to solve? Is there an expectation that the >> UA is trusted by the user/server? What happens when that's not the case? >> >> Regardless of whether I'm misunderstanding, it would sure be nice to have >> both the problem and your assumptions laid out, hopefully with some >> prominence >> so you don't get these sort of dumb questions. >> >> Mike >> _______________________________________________ >> 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 mike@mtcc.com Tue Sep 6 11:21: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 23B9721F8C5E for ; Tue, 6 Sep 2011 11:21:37 -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 KfW8QhqOjpVe for ; Tue, 6 Sep 2011 11:21:36 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id BFC4421F8C51 for ; Tue, 6 Sep 2011 11:21:35 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86INIRn000698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 11:23:19 -0700 Message-ID: <4E666512.7010701@mtcc.com> Date: Tue, 06 Sep 2011 11:23:14 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3770; t=1315333400; x=1316197400; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Yow9gAg4HG2IHTpmjrq8oP95hDibG26V6CPGPgjpV48=; b=OX+JalMa2t8A8FdZSihypUW1C53b+jv0mOhUUG3AvAUeSpVXlB05yVrAQz sJZx6WGHChFRZwSN1pZg6rn+AWeGGpcaTzCddUkjzRyOTABnDNcrfasDqagM vuBQRi038biYKkCQOYGIrWA3+WURH3pRtXG6Ju0P7ypF2+uiuQgo4=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:21:37 -0000 Eran Hammer-Lahav wrote: > I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. How, exactly, is the user supposed to protect themselves against rogue apps? It sounds like the solution is to tell them to never use oauth in an app at all. Is oauth only intended to be used on standalone trustable web browsers? I don't recall seeing that anywhere. Mike > > EHL > > On Sep 6, 2011, at 11:10, "Igor Faynberg" wrote: > >> Mike, >> >> You've got the problem statement right: allowing the user to authorize >> resource access to another party without divulging user's credentials is >> the objective of OAuth. You are also right in that the attack you have >> described defies the whole purpose of OAuth. I do not think though that >> it is related to OAuth per se. >> >> To this end, the security work led by Torsten has thoroughly analyzed >> the protocol and specified protection against multiple protocol >> attacks. From what you described, it appears to me that the attack you >> mention is not related to the protocol but rather to the user's >> environment. There is no possible protection from key loggers that a >> protocol can implement. I could be mistaken; in any case, it looks like >> the problem rests with the implementation of WebView. >> >> If I am wrong, I would appreciate a detailed description of what happened. >> >> Igor >> >> On 9/6/2011 1:40 PM, Michael Thomas wrote: >>> Hi all, >>> >>> Barry suggested that I might subscribe and explain what I sent him. >>> >>> My basic problem is that in neither the protocol nor the threats drafts, >>> I can't seem to find what problem is actually trying to be solved with >>> oauth, and what assumptions you're making about various elements. >>> >>> Here's what I did. I've written an app, and I wanted re-integrate the >>> ability to send tweets after they deprecated Basic. So the app has a >>> webView (android, iphone...) which it obviously completely controls. >>> With oauth, the webview UA will ultimately redirect off to Twitter's >>> site to collect the user's credentials and grant my app's backend an >>> access token (sorry if I get terminology screwed up, i'm just coming >>> up to speed). >>> >>> What occurs to me is that webview affords exactly zero protection from >>> my client (ie, the app) from getting the user's twitter credentials. All >>> I have to do is set up a keypress handler on that webview and in a few >>> minutes of hacking I have a key logger. etc. >>> >>> So what I can't tell is whether this is a "problem" or not, because I >>> don't know what problem you're trying to solve. If the object of oauth >>> isn't to keep user/server credentials out of the hands of a third party, >>> then what is it trying to solve? Is there an expectation that the >>> UA is trusted by the user/server? What happens when that's not the case? >>> >>> Regardless of whether I'm misunderstanding, it would sure be nice to have >>> both the problem and your assumptions laid out, hopefully with some >>> prominence >>> so you don't get these sort of dumb questions. >>> >>> Mike >>> _______________________________________________ >>> 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 wmills@yahoo-inc.com Tue Sep 6 11:25: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 1607421F8CF5 for ; Tue, 6 Sep 2011 11:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.319 X-Spam-Level: X-Spam-Status: No, score=-17.319 tagged_above=-999 required=5 tests=[AWL=0.279, 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 r1L5mx3bjXa6 for ; Tue, 6 Sep 2011 11:25:14 -0700 (PDT) Received: from nm10-vm0.bullet.mail.ne1.yahoo.com (nm10-vm0.bullet.mail.ne1.yahoo.com [98.138.91.72]) by ietfa.amsl.com (Postfix) with SMTP id 8928321F8CF4 for ; Tue, 6 Sep 2011 11:25:07 -0700 (PDT) Received: from [98.138.90.57] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 06 Sep 2011 18:26:52 -0000 Received: from [98.138.89.165] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 06 Sep 2011 18:26:52 -0000 Received: from [127.0.0.1] by omp1021.mail.ne1.yahoo.com with NNFMP; 06 Sep 2011 18:26:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 373659.48286.bm@omp1021.mail.ne1.yahoo.com Received: (qmail 6304 invoked by uid 60001); 6 Sep 2011 18:26:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1315333611; bh=8NzuoXhwDU0U5f7i50AVM3Sy+5mV0QeFiU4B1jndTCs=; 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=T49/tfYDoJNT98BRV/dsF5jma8bevDohM0WR5PdEfYUsTBIe9lW7sm4ki00aOrtY4KxFZlWRwOx8n8O2nGZ1S/uh071Pa437nNasxfNRl/JdZlBoOdWrOsVsqchslG5CwFTZ5LYAErL3ois/VKqGCNu2CREnnXH2Pomk3ww1ims= 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=DqJjfDy8/DK9gaDQmSmedpvqUDkG9mFzPzgra+PV4MqS+YIwORTXuTv+O/hFhvIbfQRSPSxZ2Pn2m2HP6Bv+wCL2QygMYhyU0OlmpWTf1P4oe+SwKURgQSfHSSrapExwbXMwPu1u3CqcOPNLAWyy+RU5oOzEjAQz7wfwNnjCvaA=; X-YMail-OSG: 58mEJt8VM1mlKR5IMCFspl1bg.SIPoZStaRfDSyx9Tc1AMW NMxfM0hue9AKoOHQ48V9MWcXrY2lC6wIL1Z2TDMf9KKA_O..snzWarPqgyYt uO5F4Uwby_woydxHrkGtw.2ZClLy0lAbFeDyCT6ZTex17rr5b3gzuw8JJcvk m98rPkmpNs64t8KuvtHUNmu525B5Fe2m9MDfrVpsfpwV4YNaR4QMlJFQBpDu EJAGDXkQHk62qSHJLqLKvk3g17EFRaSpZ_78w_EltbJi0Clptnjs.ZxCTp3n I_VHm_kSGUnKXszEM4HZHEQcM5yErNI4U3e3ZP8D2RY9EUrsAguAXkuyaa1o o6VFctonpJX4rpvh8_Dnsg.rCVP.vB0Et6dAzmVN4WBkgfQXBBwBFxR_fCLm 1vQ4m7AmVyDEWgq36_jYgsfmfOWvt_4Hp Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Tue, 06 Sep 2011 11:26:51 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.114.317681 References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> Message-ID: <1315333611.41270.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Tue, 6 Sep 2011 11:26:51 -0700 (PDT) From: William Mills To: Michael Thomas , Eran Hammer-Lahav In-Reply-To: <4E666512.7010701@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-474192642-1315333611=:41270" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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: Tue, 06 Sep 2011 18:25:15 -0000 --0-474192642-1315333611=:41270 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > How, exactly, is the user supposed to protect themselves against rogue ap= ps?=0A=0A=0ADon't install them.=0A=0A=0A________________________________=0A= From: Michael Thomas =0ATo: Eran Hammer-Lahav =0ACc: "oauth@ietf.org" =0ASent: Tuesday, September = 6, 2011 11:23 AM=0ASubject: Re: [OAUTH-WG] problem statement=0A=0AEran Hamm= er-Lahav wrote:=0A> I agree. If you are going to install a native app, you = better trust it not to do bad things. Grabbing your password is the least i= nteresting thing such an app can abuse. I don't see any need to change the = v2 draft. =0A=0AHow, exactly, is the user supposed to protect themselves ag= ainst rogue apps?=0AIt sounds like the solution is to tell them to never us= e oauth in an app at all.=0A=0AIs oauth only intended to be used on standal= one trustable web browsers? I don't recall=0Aseeing that anywhere.=0A=0AMik= e=0A=0A> =0A> EHL=0A> =0A> On Sep 6, 2011, at 11:10, "Igor Faynberg" wrote:=0A> =0A>> Mike,=0A>> =0A>> You've got t= he problem statement right: allowing the user to authorize=A0 resource acce= ss to another party without divulging user's credentials is the objective o= f OAuth. You are also right in that the attack you have described defies th= e whole purpose of OAuth.=A0 I do not think though that it is related to OA= uth per se.=0A>> =0A>> To this end, the security work led by Torsten has th= oroughly analyzed the protocol and specified protection against multiple pr= otocol attacks.=A0 From what you described, it appears to me that the attac= k you mention is not related to the protocol but rather to the user's envir= onment.=A0 There is no possible protection from key loggers that a protocol= can implement. I could be mistaken; in any case, it looks like the problem= rests with the implementation of WebView.=0A>> =0A>> If I am wrong, I woul= d appreciate a detailed description of what happened.=0A>> =0A>> Igor=0A>> = =0A>> On 9/6/2011 1:40 PM, Michael Thomas wrote:=0A>>> Hi all,=0A>>> =0A>>>= Barry suggested that I might subscribe and explain what I sent him.=0A>>> = =0A>>> My basic problem is that in neither the protocol nor the threats dra= fts,=0A>>> I can't seem to find what problem is actually trying to be solve= d with=0A>>> oauth, and what assumptions you're making about various elemen= ts.=0A>>> =0A>>> Here's what I did. I've written an app, and I wanted re-in= tegrate the=0A>>> ability to send tweets after they deprecated Basic. So th= e app has a=0A>>> webView (android, iphone...) which it obviously completel= y controls.=0A>>> With oauth, the webview UA will ultimately redirect off t= o Twitter's=0A>>> site to collect the user's credentials and grant my app's= backend an=0A>>> access token (sorry if I get terminology screwed up, i'm = just coming=0A>>> up to speed).=0A>>> =0A>>> What occurs to me is that webv= iew affords exactly zero protection from=0A>>> my client (ie, the app) from= getting the user's twitter credentials. All=0A>>> I have to do is set up a= keypress handler on that webview and in a few=0A>>> minutes of hacking I h= ave a key logger. etc.=0A>>> =0A>>> So what I can't tell is whether this is= a "problem" or not, because I=0A>>> don't know what problem you're trying = to solve. If the object of oauth=0A>>> isn't to keep user/server credential= s out of the hands of a third party,=0A>>> then what is it trying to solve?= Is there an expectation that the=0A>>> UA is trusted by the user/server? W= hat happens when that's not the case?=0A>>> =0A>>> Regardless of whether I'= m misunderstanding, it would sure be nice to have=0A>>> both the problem an= d your assumptions laid out, hopefully with some prominence=0A>>> so you do= n't get these sort of dumb questions.=0A>>> =0A>>> Mike=0A>>> _____________= __________________________________=0A>>> OAuth mailing list=0A>>> OAuth@iet= f.org=0A>>> https://www.ietf.org/mailman/listinfo/oauth=0A>> ______________= _________________________________=0A>> OAuth mailing list=0A>> OAuth@ietf.o= rg=0A>> https://www.ietf.org/mailman/listinfo/oauth=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.i= etf.org/mailman/listinfo/oauth --0-474192642-1315333611=:41270 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>= How, exactly, is the user supposed to protect themselves against rogue app= s?

Don't install them.

From: Michael Thomas <= ;mike@mtcc.com>
To: = Eran Hammer-Lahav <eran@hueniverse.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, September 6, 201= 1 11:23 AM
Subject: Re:= [OAUTH-WG] problem statement

Eran Hammer-Lahav wrote:
> I agree. = If you are going to install a native app, you better trust it not to do bad= things. Grabbing your password is the least interesting thing such an app = can abuse. I don't see any need to change the v2 draft.

How, exactl= y, is the user supposed to protect themselves against rogue apps?
It sou= nds like the solution is to tell them to never use oauth in an app at all.<= br>
Is oauth only intended to be used on standalone trustable web browse= rs? I don't recall
seeing that anywhere.

Mike

>
>= ; EHL
>
> On Sep 6, 2011, at 11:10, "Igor Faynberg" <igor.faynberg@alcatel-lucent.com> wrote:
&= gt;
>> Mike,
>>
>> You've got the problem stat= ement right: allowing the user to authorize  resource access to another party without divulging user's credentials is the objective of OAu= th. You are also right in that the attack you have described defies the who= le purpose of OAuth.  I do not think though that it is related to OAut= h per se.
>>
>> To this end, the security work led by To= rsten has thoroughly analyzed the protocol and specified protection against= multiple protocol attacks.  From what you described, it appears to me= that the attack you mention is not related to the protocol but rather to t= he user's environment.  There is no possible protection from key logge= rs that a protocol can implement. I could be mistaken; in any case, it look= s like the problem rests with the implementation of WebView.
>> >> If I am wrong, I would appreciate a detailed description of what= happened.
>>
>> Igor
>>
>> On 9/6/20= 11 1:40 PM, Michael Thomas wrote:
>>> Hi all,
>>>
>>> Barry suggested that I might subscri= be and explain what I sent him.
>>>
>>> My basic p= roblem is that in neither the protocol nor the threats drafts,
>>&= gt; I can't seem to find what problem is actually trying to be solved with<= br>>>> oauth, and what assumptions you're making about various ele= ments.
>>>
>>> Here's what I did. I've written an = app, and I wanted re-integrate the
>>> ability to send tweets a= fter they deprecated Basic. So the app has a
>>> webView (andro= id, iphone...) which it obviously completely controls.
>>> With= oauth, the webview UA will ultimately redirect off to Twitter's
>>= ;> site to collect the user's credentials and grant my app's backend an<= br>>>> access token (sorry if I get terminology screwed up, i'm ju= st coming
>>> up to speed).
>>>
>>> What occurs to me is that webview affords exactly zero pr= otection from
>>> my client (ie, the app) from getting the user= 's twitter credentials. All
>>> I have to do is set up a keypre= ss handler on that webview and in a few
>>> minutes of hacking = I have a key logger. etc.
>>>
>>> So what I can't = tell is whether this is a "problem" or not, because I
>>> don't= know what problem you're trying to solve. If the object of oauth
>&g= t;> isn't to keep user/server credentials out of the hands of a third pa= rty,
>>> then what is it trying to solve? Is there an expectati= on that the
>>> UA is trusted by the user/server? What happens = when that's not the case?
>>>
>>> Regardless of wh= ether I'm misunderstanding, it would sure be nice to have
>>> b= oth the problem and your assumptions laid out, hopefully with some prominence
>>> so you don't get these sort of dumb questions.<= br>>>>
>>> Mike
>>> _____________________= __________________________
>>> OAuth mailing list
>>&g= t; OAut= h@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
> htt= ps://www.ietf.org/mailman/listinfo/oauth

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


--0-474192642-1315333611=:41270-- From mike@mtcc.com Tue Sep 6 11:26: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 E755E21F8D01 for ; Tue, 6 Sep 2011 11:26:55 -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 U5fRzdtXxYao for ; Tue, 6 Sep 2011 11:26:55 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id AC77821F8CF5 for ; Tue, 6 Sep 2011 11:26:50 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86ISaKP002619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 11:28:37 -0700 Message-ID: <4E66664F.3010900@mtcc.com> Date: Tue, 06 Sep 2011 11:28:31 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: John Kemp References: <4E665B25.6090709@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1331; t=1315333718; x=1316197718; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20John=20Kemp=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=xVAhCVacTgfy2vdCjYgy/KBVZWzoXarlBrjay4gkdx0=; b=ghWkLh0y4sD8gMKCuEjIKDTPpz3SRnOkLYNz2T6cFkp3wmMnIN58vy/pio 6FN1n7eGpGM0Mbfl0mm4qEIRRXltUEbSPVp5JwUAOaY0jkPpwQ541OKLbieY Ehzm/3eadjbkJQEnI7P5I4C/LMbXBA3QA7dXDZQ+hQteMgaKQA9lA=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:26:56 -0000 John Kemp wrote: >> Regardless of whether I'm misunderstanding, it would sure be nice to have >> both the problem and your assumptions laid out, hopefully with some prominence >> so you don't get these sort of dumb questions. > > One point I would mention first is that your question isn't dumb ;) > > But, as I noted, OAuth seeks to avoid the requirement for a user to share her username/password at one web application with another. That being said, there are lots of ways to get that wrong, and the way of resolving those is to implement OAuth-based applications using the security features available in their specific environments, as these vary quite a lot. OAuth provides a number of different protocol flows to help with that, and "security considerations" that discuss known security threats within various environments. By careful reading, you can determine which flow is appropriate for your application, and which security features should be used to avoid the threats to your application. So to take this back to the concrete (I'm new here, so abstractions are hard): are you saying that Twitter got it wrong? My app can't be the one that's wrong because my app is the potential attacker. If it was Twitter, what did they do wrong? If not, who got what wrong that allows this situation to occur? Mike From mike@mtcc.com Tue Sep 6 11:28: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 DD77E21F8D0F for ; Tue, 6 Sep 2011 11:28:23 -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 goR75wJS6Am2 for ; Tue, 6 Sep 2011 11:28:23 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE2821F8CFF for ; Tue, 6 Sep 2011 11:28:23 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86IU7Ej003184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 11:30:08 -0700 Message-ID: <4E6666A9.5000102@mtcc.com> Date: Tue, 06 Sep 2011 11:30:01 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: William Mills References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <1315333611.41270.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: <1315333611.41270.YahooMailNeo@web31811.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4713; t=1315333809; x=1316197809; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20William=20Mills=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=a2D5xdODsNs6BOMbTxJScnMa9rVfePBA6DAWZ4oRND0=; b=YmYne7L1GYFrXzcYc05Mw4a4+JM3612sdnyTwqNWE0fiOnaiRgHczXwMvV au7+UoMIAvG8Jm7WIJIm0quNqtSg/Vq201Bi5N6TUfXRpsiHNtpFVESy44bu 8jivPLz4ooTdPvCGjl10KUFHPnnIKKTkoRQITUd4ttxjyjXYwf0XU=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:28:24 -0000 William Mills wrote: > > How, exactly, is the user supposed to protect themselves against > rogue apps? > > Don't install them. Will they be marked with rfc 3514? Mike > > *From:* Michael Thomas > *To:* Eran Hammer-Lahav > *Cc:* "oauth@ietf.org" > *Sent:* Tuesday, September 6, 2011 11:23 AM > *Subject:* Re: [OAUTH-WG] problem statement > > Eran Hammer-Lahav wrote: > > I agree. If you are going to install a native app, you better trust > it not to do bad things. Grabbing your password is the least interesting > thing such an app can abuse. I don't see any need to change the v2 draft. > > How, exactly, is the user supposed to protect themselves against rogue apps? > It sounds like the solution is to tell them to never use oauth in an app > at all. > > Is oauth only intended to be used on standalone trustable web browsers? > I don't recall > seeing that anywhere. > > Mike > > > > > EHL > > > > On Sep 6, 2011, at 11:10, "Igor Faynberg" > > wrote: > > > >> Mike, > >> > >> You've got the problem statement right: allowing the user to > authorize resource access to another party without divulging user's > credentials is the objective of OAuth. You are also right in that the > attack you have described defies the whole purpose of OAuth. I do not > think though that it is related to OAuth per se. > >> > >> To this end, the security work led by Torsten has thoroughly > analyzed the protocol and specified protection against multiple protocol > attacks. From what you described, it appears to me that the attack you > mention is not related to the protocol but rather to the user's > environment. There is no possible protection from key loggers that a > protocol can implement. I could be mistaken; in any case, it looks like > the problem rests with the implementation of WebView. > >> > >> If I am wrong, I would appreciate a detailed description of what > happened. > >> > >> Igor > >> > >> On 9/6/2011 1:40 PM, Michael Thomas wrote: > >>> Hi all, > >>> > >>> Barry suggested that I might subscribe and explain what I sent him. > >>> > >>> My basic problem is that in neither the protocol nor the threats > drafts, > >>> I can't seem to find what problem is actually trying to be solved with > >>> oauth, and what assumptions you're making about various elements. > >>> > >>> Here's what I did. I've written an app, and I wanted re-integrate the > >>> ability to send tweets after they deprecated Basic. So the app has a > >>> webView (android, iphone...) which it obviously completely controls. > >>> With oauth, the webview UA will ultimately redirect off to Twitter's > >>> site to collect the user's credentials and grant my app's backend an > >>> access token (sorry if I get terminology screwed up, i'm just coming > >>> up to speed). > >>> > >>> What occurs to me is that webview affords exactly zero protection from > >>> my client (ie, the app) from getting the user's twitter > credentials. All > >>> I have to do is set up a keypress handler on that webview and in a few > >>> minutes of hacking I have a key logger. etc. > >>> > >>> So what I can't tell is whether this is a "problem" or not, because I > >>> don't know what problem you're trying to solve. If the object of oauth > >>> isn't to keep user/server credentials out of the hands of a third > party, > >>> then what is it trying to solve? Is there an expectation that the > >>> UA is trusted by the user/server? What happens when that's not the > case? > >>> > >>> Regardless of whether I'm misunderstanding, it would sure be nice > to have > >>> both the problem and your assumptions laid out, hopefully with some > prominence > >>> so you don't get these sort of dumb questions. > >>> > >>> Mike > >>> _______________________________________________ > >>> 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 Sep 6 11:28: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 1954F21F8CFF for ; Tue, 6 Sep 2011 11:28:24 -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 FTFdJ-imtw6W for ; Tue, 6 Sep 2011 11:28:23 -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 68A7321F8D0B for ; Tue, 6 Sep 2011 11:28:23 -0700 (PDT) Received: (qmail 26240 invoked from network); 6 Sep 2011 18:30:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Sep 2011 18:30:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Sep 2011 11:29:54 -0700 From: Eran Hammer-Lahav To: Michael Thomas Date: Tue, 6 Sep 2011 11:29:47 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: AcxswviiVY6hyHnjSs+Ushp75IeLNw== Message-ID: References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> In-Reply-To: <4E666512.7010701@mtcc.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:28:24 -0000 Don't install crap on you device or computer. OAuth is the least of your co= ncern if you install bad software.=20 If there was a solution to this we would not need an antivirus.=20 EHL=20 On Sep 6, 2011, at 11:23, "Michael Thomas" wrote: > Eran Hammer-Lahav wrote: >> I agree. If you are going to install a native app, you better trust it n= ot to do bad things. Grabbing your password is the least interesting thing = such an app can abuse. I don't see any need to change the v2 draft.=20 >=20 > How, exactly, is the user supposed to protect themselves against rogue ap= ps? > It sounds like the solution is to tell them to never use oauth in an app = at all. >=20 > Is oauth only intended to be used on standalone trustable web browsers? I= don't recall > seeing that anywhere. >=20 > Mike >=20 >>=20 >> EHL >>=20 >> On Sep 6, 2011, at 11:10, "Igor Faynberg" wrote: >>=20 >>> Mike, >>>=20 >>> You've got the problem statement right: allowing the user to authorize = =20 >>> resource access to another party without divulging user's credentials i= s=20 >>> the objective of OAuth. You are also right in that the attack you have= =20 >>> described defies the whole purpose of OAuth. I do not think though tha= t=20 >>> it is related to OAuth per se. >>>=20 >>> To this end, the security work led by Torsten has thoroughly analyzed=20 >>> the protocol and specified protection against multiple protocol=20 >>> attacks. From what you described, it appears to me that the attack you= =20 >>> mention is not related to the protocol but rather to the user's=20 >>> environment. There is no possible protection from key loggers that a=20 >>> protocol can implement. I could be mistaken; in any case, it looks like= =20 >>> the problem rests with the implementation of WebView. >>>=20 >>> If I am wrong, I would appreciate a detailed description of what happen= ed. >>>=20 >>> Igor >>>=20 >>> On 9/6/2011 1:40 PM, Michael Thomas wrote: >>>> Hi all, >>>>=20 >>>> Barry suggested that I might subscribe and explain what I sent him. >>>>=20 >>>> My basic problem is that in neither the protocol nor the threats draft= s, >>>> I can't seem to find what problem is actually trying to be solved with >>>> oauth, and what assumptions you're making about various elements. >>>>=20 >>>> Here's what I did. I've written an app, and I wanted re-integrate the >>>> ability to send tweets after they deprecated Basic. So the app has a >>>> webView (android, iphone...) which it obviously completely controls. >>>> With oauth, the webview UA will ultimately redirect off to Twitter's >>>> site to collect the user's credentials and grant my app's backend an >>>> access token (sorry if I get terminology screwed up, i'm just coming >>>> up to speed). >>>>=20 >>>> What occurs to me is that webview affords exactly zero protection from >>>> my client (ie, the app) from getting the user's twitter credentials. A= ll >>>> I have to do is set up a keypress handler on that webview and in a few >>>> minutes of hacking I have a key logger. etc. >>>>=20 >>>> So what I can't tell is whether this is a "problem" or not, because I >>>> don't know what problem you're trying to solve. If the object of oauth >>>> isn't to keep user/server credentials out of the hands of a third part= y, >>>> then what is it trying to solve? Is there an expectation that the >>>> UA is trusted by the user/server? What happens when that's not the cas= e? >>>>=20 >>>> Regardless of whether I'm misunderstanding, it would sure be nice to h= ave >>>> both the problem and your assumptions laid out, hopefully with some=20 >>>> prominence >>>> so you don't get these sort of dumb questions. >>>>=20 >>>> Mike >>>> _______________________________________________ >>>> 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 From mike@mtcc.com Tue Sep 6 11:33: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 B2A5121F8D1F for ; Tue, 6 Sep 2011 11:33:24 -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 sryTmWQvKQoX for ; Tue, 6 Sep 2011 11:33:23 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id D20B621F8D1B for ; Tue, 6 Sep 2011 11:33:23 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86IZ1W4005020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 11:35:02 -0700 Message-ID: <4E6667D1.3080404@mtcc.com> Date: Tue, 06 Sep 2011 11:34:57 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4450; t=1315334103; x=1316198103; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=R0Piq2E5UX+zXvIqaJRm9k3Hh3F/bYlkmB7MV8FtwL4=; b=EzWZVHQUNJYIgCS6ilBbJsRFggiLtMO+TVOIE03g8/NTgsxifW8Hblb9hz qkDPv7WjAOJfQ3zQ4Lz4nYvuNGpDGls57jalSrRfisq0AWWVRsINn15MGwdo mwpOPX/GM2WVdwsx8xmNb+USWhH2q3irl544ial8NdNuZ9/EssmTs=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:33:24 -0000 Eran Hammer-Lahav wrote: > Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software. > > If there was a solution to this we would not need an antivirus. How exactly does an end user know what is "crap" or not? Or are you just dismissive of apps in general? I don't think that apple and google are going to close up shop because it breaks oauth's trust model. Mike > > EHL > > On Sep 6, 2011, at 11:23, "Michael Thomas" wrote: > >> Eran Hammer-Lahav wrote: >>> I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. >> How, exactly, is the user supposed to protect themselves against rogue apps? >> It sounds like the solution is to tell them to never use oauth in an app at all. >> >> Is oauth only intended to be used on standalone trustable web browsers? I don't recall >> seeing that anywhere. >> >> Mike >> >>> EHL >>> >>> On Sep 6, 2011, at 11:10, "Igor Faynberg" wrote: >>> >>>> Mike, >>>> >>>> You've got the problem statement right: allowing the user to authorize >>>> resource access to another party without divulging user's credentials is >>>> the objective of OAuth. You are also right in that the attack you have >>>> described defies the whole purpose of OAuth. I do not think though that >>>> it is related to OAuth per se. >>>> >>>> To this end, the security work led by Torsten has thoroughly analyzed >>>> the protocol and specified protection against multiple protocol >>>> attacks. From what you described, it appears to me that the attack you >>>> mention is not related to the protocol but rather to the user's >>>> environment. There is no possible protection from key loggers that a >>>> protocol can implement. I could be mistaken; in any case, it looks like >>>> the problem rests with the implementation of WebView. >>>> >>>> If I am wrong, I would appreciate a detailed description of what happened. >>>> >>>> Igor >>>> >>>> On 9/6/2011 1:40 PM, Michael Thomas wrote: >>>>> Hi all, >>>>> >>>>> Barry suggested that I might subscribe and explain what I sent him. >>>>> >>>>> My basic problem is that in neither the protocol nor the threats drafts, >>>>> I can't seem to find what problem is actually trying to be solved with >>>>> oauth, and what assumptions you're making about various elements. >>>>> >>>>> Here's what I did. I've written an app, and I wanted re-integrate the >>>>> ability to send tweets after they deprecated Basic. So the app has a >>>>> webView (android, iphone...) which it obviously completely controls. >>>>> With oauth, the webview UA will ultimately redirect off to Twitter's >>>>> site to collect the user's credentials and grant my app's backend an >>>>> access token (sorry if I get terminology screwed up, i'm just coming >>>>> up to speed). >>>>> >>>>> What occurs to me is that webview affords exactly zero protection from >>>>> my client (ie, the app) from getting the user's twitter credentials. All >>>>> I have to do is set up a keypress handler on that webview and in a few >>>>> minutes of hacking I have a key logger. etc. >>>>> >>>>> So what I can't tell is whether this is a "problem" or not, because I >>>>> don't know what problem you're trying to solve. If the object of oauth >>>>> isn't to keep user/server credentials out of the hands of a third party, >>>>> then what is it trying to solve? Is there an expectation that the >>>>> UA is trusted by the user/server? What happens when that's not the case? >>>>> >>>>> Regardless of whether I'm misunderstanding, it would sure be nice to have >>>>> both the problem and your assumptions laid out, hopefully with some >>>>> prominence >>>>> so you don't get these sort of dumb questions. >>>>> >>>>> Mike >>>>> _______________________________________________ >>>>> 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 wmills@yahoo-inc.com Tue Sep 6 11:42: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 9F60A21F8D3C for ; Tue, 6 Sep 2011 11:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.344 X-Spam-Level: X-Spam-Status: No, score=-17.344 tagged_above=-999 required=5 tests=[AWL=0.254, 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 FVNJURZudmsw for ; Tue, 6 Sep 2011 11:42:52 -0700 (PDT) Received: from nm5.bullet.mail.ne1.yahoo.com (nm5.bullet.mail.ne1.yahoo.com [98.138.90.68]) by ietfa.amsl.com (Postfix) with SMTP id 4DF8621F8D3D for ; Tue, 6 Sep 2011 11:42:52 -0700 (PDT) Received: from [98.138.90.53] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 06 Sep 2011 18:44:38 -0000 Received: from [98.138.89.249] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 06 Sep 2011 18:44:37 -0000 Received: from [127.0.0.1] by omp1041.mail.ne1.yahoo.com with NNFMP; 06 Sep 2011 18:44:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 897883.89427.bm@omp1041.mail.ne1.yahoo.com Received: (qmail 31557 invoked by uid 60001); 6 Sep 2011 18:44:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1315334677; bh=uK5i+EvMexRMn+q1mGp6PvgxH0lGZEXf0xYubE5RZ0k=; 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=lq3P0UrLDE8394xHXDEbXD+Jil9GJC4I+R5/ZWtkAPVYQy68D4z+hu5/lYs9UF1XbAhbbypzilM+Z86GZWEUQRmIq29NquE2hT38HtN2ZZ0FgULY/oUlr0ehZ9zNzR8tAcLhxqvikI2qVz2zHcb8d14WjS4vVjw+KGNyPSQpxRk= 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=flnDkfsOPDOJkxMNUCkDNDK1kRHaGruOBtac8rg7HxmpjJ1mPeBl3ZxTh2Icnn7Eu2c/VD2RXXNLynGycV1FKLxVR/8tvs7XFGLLNaNmrlStAQAn0w0JpjIsdXXN8jPzJIJ9oQ3G4J/c6i/fUsUW+bDcHdP5vVVMiqplfsygxsM=; X-YMail-OSG: ytcJP7sVM1leFsmG1UkyDkl46yfx6PhOnichZk.ad_lGcUA Ne2Tr.w6PCpZAy79Dza37jVfQjFxLtHVEavu4FIiMfG0B7k8WXK20qQMBJZr 2a4YesE3XDB1rCkvEqX6wYs8TKjYKYCMr3wuadU9rH56qnFontKHd_JLLHg7 2OD24HLip.BVRB3XMdxlwZW98yrrQlrqmz2xFS1eQ8XIxt5G9a0t5IX9x0PH RXW.hZsszWmWayJrw3c_jaTJm_FkGQKhdkiBG0.m2vt6hC3OoK5Cd1JILEne iXXDSBsmhsZx3ahbOBVKxqlhX0ExkDwMR1v.ZJPN3yoNhqQZbD2dPHGjHbCL BItAbRLwRDOfqZyV81EmRpLK2hwcUgT2pS0fDHDgxyu2QNzy7MxUmHU8kDTi 7nu0yc3k4A9ByNhgppsjOwTLs8Jp2Qeo- Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Tue, 06 Sep 2011 11:44:37 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.114.317681 References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> Message-ID: <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 6 Sep 2011 11:44:37 -0700 (PDT) From: William Mills To: Michael Thomas , Eran Hammer-Lahav In-Reply-To: <4E6667D1.3080404@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1542732601-1315334677=:26387" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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: Tue, 06 Sep 2011 18:42:53 -0000 --0-1542732601-1315334677=:26387 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OAuth doesn't solve this problem, and can't.=A0 Generally the question is w= hether the app appears to come from a reputable source, and nowadays whethe= r it's signed (in windows land) or otherwize certified by the provider.=0A= =0AIf you manage to solve this problem in a real way I'd be interested in i= nvesting in your company.=0A=0A=0A=0A________________________________=0AFro= m: Michael Thomas =0ATo: Eran Hammer-Lahav =0ACc: "oauth@ietf.org" =0ASent: Tuesday, September 6, = 2011 11:34 AM=0ASubject: Re: [OAUTH-WG] problem statement=0A=0AEran Hammer-= Lahav wrote:=0A> Don't install crap on you device or computer. OAuth is the= least of your concern if you install bad software. =0A> If there was a sol= ution to this we would not need an antivirus. =0A=0AHow exactly does an end= user know what is "crap" or not? Or are you just dismissive of apps in=0Ag= eneral? I don't think that apple and google are going to close up shop beca= use it breaks oauth's=0Atrust model.=0A=0AMike=0A=0A> =0A> EHL =0A> On Sep = 6, 2011, at 11:23, "Michael Thomas" wrote:=0A> =0A>> Eran H= ammer-Lahav wrote:=0A>>> I agree. If you are going to install a native app,= you better trust it not to do bad things. Grabbing your password is the le= ast interesting thing such an app can abuse. I don't see any need to change= the v2 draft. =0A>> How, exactly, is the user supposed to protect themselv= es against rogue apps?=0A>> It sounds like the solution is to tell them to = never use oauth in an app at all.=0A>> =0A>> Is oauth only intended to be u= sed on standalone trustable web browsers? I don't recall=0A>> seeing that a= nywhere.=0A>> =0A>> Mike=0A>> =0A>>> EHL=0A>>> =0A>>> On Sep 6, 2011, at 11= :10, "Igor Faynberg" wrote:=0A>>> =0A>>>= > Mike,=0A>>>> =0A>>>> You've got the problem statement right: allowing the= user to authorize=A0 resource access to another party without divulging us= er's credentials is the objective of OAuth. You are also right in that the = attack you have described defies the whole purpose of OAuth.=A0 I do not th= ink though that it is related to OAuth per se.=0A>>>> =0A>>>> To this end, = the security work led by Torsten has thoroughly analyzed the protocol and s= pecified protection against multiple protocol attacks.=A0 From what you des= cribed, it appears to me that the attack you mention is not related to the = protocol but rather to the user's environment.=A0 There is no possible prot= ection from key loggers that a protocol can implement. I could be mistaken;= in any case, it looks like the problem rests with the implementation of We= bView.=0A>>>> =0A>>>> If I am wrong, I would appreciate a detailed descript= ion of what happened.=0A>>>> =0A>>>> Igor=0A>>>> =0A>>>> On 9/6/2011 1:40 P= M, Michael Thomas wrote:=0A>>>>> Hi all,=0A>>>>> =0A>>>>> Barry suggested t= hat I might subscribe and explain what I sent him.=0A>>>>> =0A>>>>> My basi= c problem is that in neither the protocol nor the threats drafts,=0A>>>>> I= can't seem to find what problem is actually trying to be solved with=0A>>>= >> oauth, and what assumptions you're making about various elements.=0A>>>>= > =0A>>>>> Here's what I did. I've written an app, and I wanted re-integrat= e the=0A>>>>> ability to send tweets after they deprecated Basic. So the ap= p has a=0A>>>>> webView (android, iphone...) which it obviously completely = controls.=0A>>>>> With oauth, the webview UA will ultimately redirect off t= o Twitter's=0A>>>>> site to collect the user's credentials and grant my app= 's backend an=0A>>>>> access token (sorry if I get terminology screwed up, = i'm just coming=0A>>>>> up to speed).=0A>>>>> =0A>>>>> What occurs to me is= that webview affords exactly zero protection from=0A>>>>> my client (ie, t= he app) from getting the user's twitter credentials. All=0A>>>>> I have to = do is set up a keypress handler on that webview and in a few=0A>>>>> minute= s of hacking I have a key logger. etc.=0A>>>>> =0A>>>>> So what I can't tel= l is whether this is a "problem" or not, because I=0A>>>>> don't know what = problem you're trying to solve. If the object of oauth=0A>>>>> isn't to kee= p user/server credentials out of the hands of a third party,=0A>>>>> then w= hat is it trying to solve? Is there an expectation that the=0A>>>>> UA is t= rusted by the user/server? What happens when that's not the case?=0A>>>>> = =0A>>>>> Regardless of whether I'm misunderstanding, it would sure be nice = to have=0A>>>>> both the problem and your assumptions laid out, hopefully w= ith some prominence=0A>>>>> so you don't get these sort of dumb questions.= =0A>>>>> =0A>>>>> Mike=0A>>>>> ____________________________________________= ___=0A>>>>> OAuth mailing list=0A>>>>> OAuth@ietf.org=0A>>>>> https://www.i= etf.org/mailman/listinfo/oauth=0A>>>> _____________________________________= __________=0A>>>> OAuth mailing list=0A>>>> OAuth@ietf.org=0A>>>> https://w= ww.ietf.org/mailman/listinfo/oauth=0A>>> __________________________________= _____________=0A>>> OAuth mailing list=0A>>> OAuth@ietf.org=0A>>> https://w= ww.ietf.org/mailman/listinfo/oauth=0A=0A___________________________________= ____________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/m= ailman/listinfo/oauth --0-1542732601-1315334677=:26387 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OAuth doesn't solve this problem, and can't.  Generally the question= is whether the app appears to come from a reputable source, and nowadays w= hether it's signed (in windows land) or otherwize certified by the provider= .

If you manage to solve= this problem in a real way I'd be interested in investing in your company.=

= From: Michael Thomas <mike@mtcc.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, September 6, 2011 11:34 AM
= Subject: Re: [OAUTH-WG] probl= em statement

Eran Hammer-Lahav wrote:
> Don't install c= rap on you device or computer. OAuth is the least of your concern if you in= stall bad software.
> If there was a solution to this we would not n= eed an antivirus.

How exactly does an end user know what is "crap" = or not? Or are you just dismissive of apps in
general? I don't think tha= t apple and google are going to close up shop because it breaks oauth's
= trust model.

Mike

>
> EHL
> On Sep 6, 2011, = at 11:23, "Michael Thomas" <mike@mtcc.com> wrote:
>
>> Era= n Hammer-Lahav wrote:
>>> I agree. If you are going to install a= native app, you better trust it not to do bad things. Grabbing your passwo= rd is the least interesting thing such an app can abuse. I don't see any ne= ed to change the v2 draft.
>> How, exactly, is the user supposed = to protect themselves against rogue apps?
>> It sounds like the so= lution is to tell them to never use oauth in an app at all.
>> >> Is oauth only intended to be used on standalone trustable web bro= wsers? I don't recall
>> seeing that anywhere.
>>
>= ;> Mike
>>
>>> EHL
>>>
>>>= ; On Sep 6, 2011, at 11:10, "Igor Faynberg" <igor.faynberg@alcatel-lucent.com> wrote:
>>>
>&= gt;>> Mike,
>>>>
>>>> You've got the problem statement right: allowing the user to authorize  resource= access to another party without divulging user's credentials is the object= ive of OAuth. You are also right in that the attack you have described defi= es the whole purpose of OAuth.  I do not think though that it is relat= ed to OAuth per se.
>>>>
>>>> To this end, t= he security work led by Torsten has thoroughly analyzed the protocol and sp= ecified protection against multiple protocol attacks.  From what you d= escribed, it appears to me that the attack you mention is not related to th= e protocol but rather to the user's environment.  There is no possible= protection from key loggers that a protocol can implement. I could be mist= aken; in any case, it looks like the problem rests with the implementation = of WebView.
>>>>
>>>> If I am wrong, I would= appreciate a detailed description of what happened.
>>>>
>>>> Igor
>>>>= ;
>>>> On 9/6/2011 1:40 PM, Michael Thomas wrote:
>&g= t;>>> Hi all,
>>>>>
>>>>> Bar= ry suggested that I might subscribe and explain what I sent him.
>>= ;>>>
>>>>> My basic problem is that in neither = the protocol nor the threats drafts,
>>>>> I can't seem t= o find what problem is actually trying to be solved with
>>>>= ;> oauth, and what assumptions you're making about various elements.
= >>>>>
>>>>> Here's what I did. I've writt= en an app, and I wanted re-integrate the
>>>>> ability to= send tweets after they deprecated Basic. So the app has a
>>>&= gt;> webView (android, iphone...) which it obviously completely controls= .
>>>>> With oauth, the webview UA will ultimately redirect off to Twitter's
>>>>> site to collect the user= 's credentials and grant my app's backend an
>>>>> access= token (sorry if I get terminology screwed up, i'm just coming
>>&= gt;>> up to speed).
>>>>>
>>>>> = What occurs to me is that webview affords exactly zero protection from
&= gt;>>>> my client (ie, the app) from getting the user's twitter= credentials. All
>>>>> I have to do is set up a keypress= handler on that webview and in a few
>>>>> minutes of ha= cking I have a key logger. etc.
>>>>>
>>>>= ;> So what I can't tell is whether this is a "problem" or not, because I=
>>>>> don't know what problem you're trying to solve. If= the object of oauth
>>>>> isn't to keep user/server cred= entials out of the hands of a third party,
>>>>> then what is it trying to solve? Is there an expectation that the
>&= gt;>>> UA is trusted by the user/server? What happens when that's = not the case?
>>>>>
>>>>> Regardless o= f whether I'm misunderstanding, it would sure be nice to have
>>&g= t;>> both the problem and your assumptions laid out, hopefully with s= ome prominence
>>>>> so you don't get these sort of dumb = questions.
>>>>>
>>>>> Mike
>>= ;>>> _______________________________________________
>>&g= t;>> OAuth mailing list
>>>>> OAuth@ietf.org
>&g= t;>>> https://www.ietf.org/mailman/listinfo/oauth
>>&g= t;> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> http= s://www.ietf.org/mailman/listinfo/oauth
>>> _______________= ________________________________
>>> OAuth mailing list
>= >> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/o= auth

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


--0-1542732601-1315334677=:26387-- From eran@hueniverse.com Tue Sep 6 11:45: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 21DFD21F8D4C for ; Tue, 6 Sep 2011 11:45:34 -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 jkkwEFCuEWZJ for ; Tue, 6 Sep 2011 11:45:33 -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 714B621F8D42 for ; Tue, 6 Sep 2011 11:45:33 -0700 (PDT) Received: (qmail 24751 invoked from network); 6 Sep 2011 18:47:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Sep 2011 18:47:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 6 Sep 2011 11:47:00 -0700 From: Eran Hammer-Lahav To: Michael Thomas Date: Tue, 6 Sep 2011 11:46:53 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: AcxsxVxArH92hTxyQ3KP/MQgBoWLOQ== Message-ID: <35A51DCF-DC1D-46B5-9FE7-23D832C17BDE@hueniverse.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> In-Reply-To: <4E6667D1.3080404@mtcc.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:45:34 -0000 I'm dismissive of this being an OAuth problem.=20 EHL On Sep 6, 2011, at 11:35, "Michael Thomas" wrote: > Eran Hammer-Lahav wrote: >> Don't install crap on you device or computer. OAuth is the least of your= concern if you install bad software.=20 >>=20 >> If there was a solution to this we would not need an antivirus.=20 >=20 > How exactly does an end user know what is "crap" or not? Or are you just = dismissive of apps in > general? I don't think that apple and google are going to close up shop b= ecause it breaks oauth's > trust model. >=20 > Mike >=20 >>=20 >> EHL=20 >>=20 >> On Sep 6, 2011, at 11:23, "Michael Thomas" wrote: >>=20 >>> Eran Hammer-Lahav wrote: >>>> I agree. If you are going to install a native app, you better trust it= not to do bad things. Grabbing your password is the least interesting thin= g such an app can abuse. I don't see any need to change the v2 draft.=20 >>> How, exactly, is the user supposed to protect themselves against rogue = apps? >>> It sounds like the solution is to tell them to never use oauth in an ap= p at all. >>>=20 >>> Is oauth only intended to be used on standalone trustable web browsers?= I don't recall >>> seeing that anywhere. >>>=20 >>> Mike >>>=20 >>>> EHL >>>>=20 >>>> On Sep 6, 2011, at 11:10, "Igor Faynberg" wrote: >>>>=20 >>>>> Mike, >>>>>=20 >>>>> You've got the problem statement right: allowing the user to authoriz= e =20 >>>>> resource access to another party without divulging user's credentials= is=20 >>>>> the objective of OAuth. You are also right in that the attack you hav= e=20 >>>>> described defies the whole purpose of OAuth. I do not think though t= hat=20 >>>>> it is related to OAuth per se. >>>>>=20 >>>>> To this end, the security work led by Torsten has thoroughly analyzed= =20 >>>>> the protocol and specified protection against multiple protocol=20 >>>>> attacks. From what you described, it appears to me that the attack y= ou=20 >>>>> mention is not related to the protocol but rather to the user's=20 >>>>> environment. There is no possible protection from key loggers that a= =20 >>>>> protocol can implement. I could be mistaken; in any case, it looks li= ke=20 >>>>> the problem rests with the implementation of WebView. >>>>>=20 >>>>> If I am wrong, I would appreciate a detailed description of what happ= ened. >>>>>=20 >>>>> Igor >>>>>=20 >>>>> On 9/6/2011 1:40 PM, Michael Thomas wrote: >>>>>> Hi all, >>>>>>=20 >>>>>> Barry suggested that I might subscribe and explain what I sent him. >>>>>>=20 >>>>>> My basic problem is that in neither the protocol nor the threats dra= fts, >>>>>> I can't seem to find what problem is actually trying to be solved wi= th >>>>>> oauth, and what assumptions you're making about various elements. >>>>>>=20 >>>>>> Here's what I did. I've written an app, and I wanted re-integrate th= e >>>>>> ability to send tweets after they deprecated Basic. So the app has a >>>>>> webView (android, iphone...) which it obviously completely controls. >>>>>> With oauth, the webview UA will ultimately redirect off to Twitter's >>>>>> site to collect the user's credentials and grant my app's backend an >>>>>> access token (sorry if I get terminology screwed up, i'm just coming >>>>>> up to speed). >>>>>>=20 >>>>>> What occurs to me is that webview affords exactly zero protection fr= om >>>>>> my client (ie, the app) from getting the user's twitter credentials.= All >>>>>> I have to do is set up a keypress handler on that webview and in a f= ew >>>>>> minutes of hacking I have a key logger. etc. >>>>>>=20 >>>>>> So what I can't tell is whether this is a "problem" or not, because = I >>>>>> don't know what problem you're trying to solve. If the object of oau= th >>>>>> isn't to keep user/server credentials out of the hands of a third pa= rty, >>>>>> then what is it trying to solve? Is there an expectation that the >>>>>> UA is trusted by the user/server? What happens when that's not the c= ase? >>>>>>=20 >>>>>> Regardless of whether I'm misunderstanding, it would sure be nice to= have >>>>>> both the problem and your assumptions laid out, hopefully with some= =20 >>>>>> prominence >>>>>> so you don't get these sort of dumb questions. >>>>>>=20 >>>>>> Mike >>>>>> _______________________________________________ >>>>>> 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 From jricher@mitre.org Tue Sep 6 11:48: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 25CA721F8D59 for ; Tue, 6 Sep 2011 11:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 HsxWoa01BiZG for ; Tue, 6 Sep 2011 11:48:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EC27C21F8D29 for ; Tue, 6 Sep 2011 11:48:10 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D2F1C21B16B0; Tue, 6 Sep 2011 14:49:57 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CC30821B16A4; Tue, 6 Sep 2011 14:49:57 -0400 (EDT) Received: from [129.83.50.1] (129.83.31.55) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server id 14.1.270.1; Tue, 6 Sep 2011 14:49:57 -0400 From: Justin Richer To: Michael Thomas In-Reply-To: <4E6667D1.3080404@mtcc.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 6 Sep 2011 14:48:55 -0400 Message-ID: <1315334935.3136.29.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:48:12 -0000 Mike, The basic argument here is that if the app wants to do bad things, and you go through the process of authorizing it, it's going to be able to do bad things. Not just to your stolen credentials, either, since it's now got an access token too. OAuth's trust model does work with installed applications -- however, there are several caveats. This is one of them, as is the fact that they can't be shipped with secured secrets (ie, client secrets). And it's exactly this acquiescence to their limitations that opens the way for things like the username/password flow in OAuth2. In this flow, the app just asks for the user's username and password directly and exchanges them for an access token. There is still a distinction from logging in directly with the user's credentials to the API endpoint though. First, the user's credentials don't get tossed out onto the wire with every request. This lessens the susceptibility to theft in transmission. Second, the app doesn't *have* to store the credentials. After the first step goes through and the app gets a token, it can toss them. That way nobody can steal the credentials out of an on-disk store after the fact. If it wants to hang on to them, then yeah, you're absolutely right -- it has your credentials and you're hosed. But nothing in the OAuth protocol is going to force a misbehaving application to not do that. Just like nothing in the OAuth protocol is going to stop phishing attempts to look like the Twitter login screen. A solution to not letting an app steal your credentials is to not use credentials in the first place and to use things like a rotating token or a client-side certificate instead of a username/password to authenticate the user during the authoirzation flow. Since OAuth doesn't care how the user authenticates in the verification code flow, you don't even have to change your client code. We actually had this happen locally when developers moved from one environment that used username/password and into another that used OpenID. The OAuth code didn't change at all between them. But ultimately, a bad app is going to be a bad app, and you need to be careful what software you run and where you type your password. I think it's a mistake of this group to flippantly ignore the threat, but at the same token this reality does not make the OAuth protocol or its underlying model useless. -- Justin On Tue, 2011-09-06 at 14:34 -0400, Michael Thomas wrote: > Eran Hammer-Lahav wrote: > > Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software. > > > > If there was a solution to this we would not need an antivirus. > > How exactly does an end user know what is "crap" or not? Or are you just dismissive of apps in > general? I don't think that apple and google are going to close up shop because it breaks oauth's > trust model. > > Mike > > > > > EHL > > > > On Sep 6, 2011, at 11:23, "Michael Thomas" wrote: > > > >> Eran Hammer-Lahav wrote: > >>> I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. > >> How, exactly, is the user supposed to protect themselves against rogue apps? > >> It sounds like the solution is to tell them to never use oauth in an app at all. > >> > >> Is oauth only intended to be used on standalone trustable web browsers? I don't recall > >> seeing that anywhere. > >> > >> Mike > >> > >>> EHL > >>> > >>> On Sep 6, 2011, at 11:10, "Igor Faynberg" wrote: > >>> > >>>> Mike, > >>>> > >>>> You've got the problem statement right: allowing the user to authorize > >>>> resource access to another party without divulging user's credentials is > >>>> the objective of OAuth. You are also right in that the attack you have > >>>> described defies the whole purpose of OAuth. I do not think though that > >>>> it is related to OAuth per se. > >>>> > >>>> To this end, the security work led by Torsten has thoroughly analyzed > >>>> the protocol and specified protection against multiple protocol > >>>> attacks. From what you described, it appears to me that the attack you > >>>> mention is not related to the protocol but rather to the user's > >>>> environment. There is no possible protection from key loggers that a > >>>> protocol can implement. I could be mistaken; in any case, it looks like > >>>> the problem rests with the implementation of WebView. > >>>> > >>>> If I am wrong, I would appreciate a detailed description of what happened. > >>>> > >>>> Igor > >>>> > >>>> On 9/6/2011 1:40 PM, Michael Thomas wrote: > >>>>> Hi all, > >>>>> > >>>>> Barry suggested that I might subscribe and explain what I sent him. > >>>>> > >>>>> My basic problem is that in neither the protocol nor the threats drafts, > >>>>> I can't seem to find what problem is actually trying to be solved with > >>>>> oauth, and what assumptions you're making about various elements. > >>>>> > >>>>> Here's what I did. I've written an app, and I wanted re-integrate the > >>>>> ability to send tweets after they deprecated Basic. So the app has a > >>>>> webView (android, iphone...) which it obviously completely controls. > >>>>> With oauth, the webview UA will ultimately redirect off to Twitter's > >>>>> site to collect the user's credentials and grant my app's backend an > >>>>> access token (sorry if I get terminology screwed up, i'm just coming > >>>>> up to speed). > >>>>> > >>>>> What occurs to me is that webview affords exactly zero protection from > >>>>> my client (ie, the app) from getting the user's twitter credentials. All > >>>>> I have to do is set up a keypress handler on that webview and in a few > >>>>> minutes of hacking I have a key logger. etc. > >>>>> > >>>>> So what I can't tell is whether this is a "problem" or not, because I > >>>>> don't know what problem you're trying to solve. If the object of oauth > >>>>> isn't to keep user/server credentials out of the hands of a third party, > >>>>> then what is it trying to solve? Is there an expectation that the > >>>>> UA is trusted by the user/server? What happens when that's not the case? > >>>>> > >>>>> Regardless of whether I'm misunderstanding, it would sure be nice to have > >>>>> both the problem and your assumptions laid out, hopefully with some > >>>>> prominence > >>>>> so you don't get these sort of dumb questions. > >>>>> > >>>>> Mike > >>>>> _______________________________________________ > >>>>> 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 mike@mtcc.com Tue Sep 6 11: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 9CC4421F8D63 for ; Tue, 6 Sep 2011 11:48:39 -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 cH86RNSnnWOe for ; Tue, 6 Sep 2011 11:48:38 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE1321F8D61 for ; Tue, 6 Sep 2011 11:48:32 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86IoHxw010316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 11:50:17 -0700 Message-ID: <4E666B65.30701@mtcc.com> Date: Tue, 06 Sep 2011 11:50:13 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: William Mills References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> In-Reply-To: <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6089; t=1315335018; x=1316199018; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20William=20Mills=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ompy3kK0Rcf9niKDKMF1r4/xRItuD0P2sH++eZeIy08=; b=B+X23XwbVxAUYR46G1ZbIz3PF+RVhwiNoQI3xapF/ZcuG5eya6oZ8QyewR UWYK8hNz/+X49sjNDb9vFw7td9pAvWkhph/hDtJ/4Y91yv6iQnkdcgjai8iF Q4P9+aJCVvnmlCyvC8u4IXPgmUNNQmcLkBC8vZ5XBEwpfoxn0/VmY=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:48:39 -0000 William Mills wrote: > OAuth doesn't solve this problem, and can't. Generally the question is > whether the app appears to come from a reputable source, and nowadays > whether it's signed (in windows land) or otherwize certified by the > provider. > > If you manage to solve this problem in a real way I'd be interested in > investing in your company. Then what I don't see anywhere is that oauth is not applicable to embedded web objects, and that end users should *never* trust oauth in a, say, phone app. As far as I can tell, the server deploying oauth can't tell that it's being misused, so this is all on the shoulders of the end user. It sure looks like oauth is easily subverted in the real world. Mike > > ------------------------------------------------------------------------ > *From:* Michael Thomas > *To:* Eran Hammer-Lahav > *Cc:* "oauth@ietf.org" > *Sent:* Tuesday, September 6, 2011 11:34 AM > *Subject:* Re: [OAUTH-WG] problem statement > > Eran Hammer-Lahav wrote: > > Don't install crap on you device or computer. OAuth is the least of > your concern if you install bad software. > > If there was a solution to this we would not need an antivirus. > > How exactly does an end user know what is "crap" or not? Or are you just > dismissive of apps in > general? I don't think that apple and google are going to close up shop > because it breaks oauth's > trust model. > > Mike > > > > > EHL > > On Sep 6, 2011, at 11:23, "Michael Thomas" > wrote: > > > >> Eran Hammer-Lahav wrote: > >>> I agree. If you are going to install a native app, you better trust > it not to do bad things. Grabbing your password is the least interesting > thing such an app can abuse. I don't see any need to change the v2 draft. > >> How, exactly, is the user supposed to protect themselves against > rogue apps? > >> It sounds like the solution is to tell them to never use oauth in an > app at all. > >> > >> Is oauth only intended to be used on standalone trustable web > browsers? I don't recall > >> seeing that anywhere. > >> > >> Mike > >> > >>> EHL > >>> > >>> On Sep 6, 2011, at 11:10, "Igor Faynberg" > > wrote: > >>> > >>>> Mike, > >>>> > >>>> You've got the problem statement right: allowing the user to > authorize resource access to another party without divulging user's > credentials is the objective of OAuth. You are also right in that the > attack you have described defies the whole purpose of OAuth. I do not > think though that it is related to OAuth per se. > >>>> > >>>> To this end, the security work led by Torsten has thoroughly > analyzed the protocol and specified protection against multiple protocol > attacks. From what you described, it appears to me that the attack you > mention is not related to the protocol but rather to the user's > environment. There is no possible protection from key loggers that a > protocol can implement. I could be mistaken; in any case, it looks like > the problem rests with the implementation of WebView. > >>>> > >>>> If I am wrong, I would appreciate a detailed description of what > happened. > >>>> > >>>> Igor > >>>> > >>>> On 9/6/2011 1:40 PM, Michael Thomas wrote: > >>>>> Hi all, > >>>>> > >>>>> Barry suggested that I might subscribe and explain what I sent him. > >>>>> > >>>>> My basic problem is that in neither the protocol nor the threats > drafts, > >>>>> I can't seem to find what problem is actually trying to be solved > with > >>>>> oauth, and what assumptions you're making about various elements. > >>>>> > >>>>> Here's what I did. I've written an app, and I wanted re-integrate the > >>>>> ability to send tweets after they deprecated Basic. So the app has a > >>>>> webView (android, iphone...) which it obviously completely controls. > >>>>> With oauth, the webview UA will ultimately redirect off to Twitter's > >>>>> site to collect the user's credentials and grant my app's backend an > >>>>> access token (sorry if I get terminology screwed up, i'm just coming > >>>>> up to speed). > >>>>> > >>>>> What occurs to me is that webview affords exactly zero protection > from > >>>>> my client (ie, the app) from getting the user's twitter > credentials. All > >>>>> I have to do is set up a keypress handler on that webview and in > a few > >>>>> minutes of hacking I have a key logger. etc. > >>>>> > >>>>> So what I can't tell is whether this is a "problem" or not, because I > >>>>> don't know what problem you're trying to solve. If the object of > oauth > >>>>> isn't to keep user/server credentials out of the hands of a third > party, > >>>>> then what is it trying to solve? Is there an expectation that the > >>>>> UA is trusted by the user/server? What happens when that's not > the case? > >>>>> > >>>>> Regardless of whether I'm misunderstanding, it would sure be nice > to have > >>>>> both the problem and your assumptions laid out, hopefully with > some prominence > >>>>> so you don't get these sort of dumb questions. > >>>>> > >>>>> Mike > >>>>> _______________________________________________ > >>>>> 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 mike@mtcc.com Tue Sep 6 11:56: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 1A36621F8C09 for ; Tue, 6 Sep 2011 11:56: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=[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 SfrJLsbwyIBS for ; Tue, 6 Sep 2011 11:56:33 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2970121F8BE4 for ; Tue, 6 Sep 2011 11:56:33 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86IwGpU012943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 11:58:17 -0700 Message-ID: <4E666D43.5030407@mtcc.com> Date: Tue, 06 Sep 2011 11:58:11 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <35A51DCF-DC1D-46B5-9FE7-23D832C17BDE@hueniverse.com> In-Reply-To: <35A51DCF-DC1D-46B5-9FE7-23D832C17BDE@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5672; t=1315335498; x=1316199498; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=q8i4H1fiZ474fgpumYSk9aQxso5OXqsAU/RgCidDxlo=; b=o1eVOfrH2KENTkpBDEmYjB5HpgoXtN0NiAJY3XdqQse+uEWf9wKP45gLOU DtEzX59TeLMB/pKrfhENWgXJds8UvWDw0gy0PxsB2kmSR88L0/GrNYivNlf3 /Nr48D7dy2mC5LKiPpz6IaTDy2xpmClBeXO201SweKieMzgH/dnxU=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:56:34 -0000 Eran Hammer-Lahav wrote: > I'm dismissive of this being an OAuth problem. Which brings us back to my original problem: what is the problem it's trying to solve? What are the assumptions it makes? What is its applicability? None of those are addressed very well if at all in the drafts. I'm sure that I'm not the only one who would be very surprised to hear that using oauth on a phone app is a bad idea. Put it this way: your favorite example of a photo printing service needing access to flickr. It's ok if you do that from a browser, but not if the photo printer makes an app. How many users, exactly, are going to know that they shouldn't do the second one? I think that's an oauth problem because oauth makes it *seem* like you're protected from the third party, whereas if the app itself asked for your login credentials there would be far less confusion. So in that sense, oauth is making things worse, not better. Mike > > EHL > > On Sep 6, 2011, at 11:35, "Michael Thomas" wrote: > >> Eran Hammer-Lahav wrote: >>> Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software. >>> >>> If there was a solution to this we would not need an antivirus. >> How exactly does an end user know what is "crap" or not? Or are you just dismissive of apps in >> general? I don't think that apple and google are going to close up shop because it breaks oauth's >> trust model. >> >> Mike >> >>> EHL >>> >>> On Sep 6, 2011, at 11:23, "Michael Thomas" wrote: >>> >>>> Eran Hammer-Lahav wrote: >>>>> I agree. If you are going to install a native app, you better trust it not to do bad things. Grabbing your password is the least interesting thing such an app can abuse. I don't see any need to change the v2 draft. >>>> How, exactly, is the user supposed to protect themselves against rogue apps? >>>> It sounds like the solution is to tell them to never use oauth in an app at all. >>>> >>>> Is oauth only intended to be used on standalone trustable web browsers? I don't recall >>>> seeing that anywhere. >>>> >>>> Mike >>>> >>>>> EHL >>>>> >>>>> On Sep 6, 2011, at 11:10, "Igor Faynberg" wrote: >>>>> >>>>>> Mike, >>>>>> >>>>>> You've got the problem statement right: allowing the user to authorize >>>>>> resource access to another party without divulging user's credentials is >>>>>> the objective of OAuth. You are also right in that the attack you have >>>>>> described defies the whole purpose of OAuth. I do not think though that >>>>>> it is related to OAuth per se. >>>>>> >>>>>> To this end, the security work led by Torsten has thoroughly analyzed >>>>>> the protocol and specified protection against multiple protocol >>>>>> attacks. From what you described, it appears to me that the attack you >>>>>> mention is not related to the protocol but rather to the user's >>>>>> environment. There is no possible protection from key loggers that a >>>>>> protocol can implement. I could be mistaken; in any case, it looks like >>>>>> the problem rests with the implementation of WebView. >>>>>> >>>>>> If I am wrong, I would appreciate a detailed description of what happened. >>>>>> >>>>>> Igor >>>>>> >>>>>> On 9/6/2011 1:40 PM, Michael Thomas wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Barry suggested that I might subscribe and explain what I sent him. >>>>>>> >>>>>>> My basic problem is that in neither the protocol nor the threats drafts, >>>>>>> I can't seem to find what problem is actually trying to be solved with >>>>>>> oauth, and what assumptions you're making about various elements. >>>>>>> >>>>>>> Here's what I did. I've written an app, and I wanted re-integrate the >>>>>>> ability to send tweets after they deprecated Basic. So the app has a >>>>>>> webView (android, iphone...) which it obviously completely controls. >>>>>>> With oauth, the webview UA will ultimately redirect off to Twitter's >>>>>>> site to collect the user's credentials and grant my app's backend an >>>>>>> access token (sorry if I get terminology screwed up, i'm just coming >>>>>>> up to speed). >>>>>>> >>>>>>> What occurs to me is that webview affords exactly zero protection from >>>>>>> my client (ie, the app) from getting the user's twitter credentials. All >>>>>>> I have to do is set up a keypress handler on that webview and in a few >>>>>>> minutes of hacking I have a key logger. etc. >>>>>>> >>>>>>> So what I can't tell is whether this is a "problem" or not, because I >>>>>>> don't know what problem you're trying to solve. If the object of oauth >>>>>>> isn't to keep user/server credentials out of the hands of a third party, >>>>>>> then what is it trying to solve? Is there an expectation that the >>>>>>> UA is trusted by the user/server? What happens when that's not the case? >>>>>>> >>>>>>> Regardless of whether I'm misunderstanding, it would sure be nice to have >>>>>>> both the problem and your assumptions laid out, hopefully with some >>>>>>> prominence >>>>>>> so you don't get these sort of dumb questions. >>>>>>> >>>>>>> Mike >>>>>>> _______________________________________________ >>>>>>> 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 Sep 6 11:56: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 C728321F8C59 for ; Tue, 6 Sep 2011 11:56:42 -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 g2SSmPQCTj5d for ; Tue, 6 Sep 2011 11:56:42 -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 E03FE21F8C1D for ; Tue, 6 Sep 2011 11:56:41 -0700 (PDT) Received: (qmail 29525 invoked from network); 6 Sep 2011 18:57:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Sep 2011 18:57:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 6 Sep 2011 11:57:29 -0700 From: Eran Hammer-Lahav To: Michael Thomas Date: Tue, 6 Sep 2011 11:57:22 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: AcxsxtNsyztBHXtjR266ssIH1m+R9A== Message-ID: <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> In-Reply-To: <4E666B65.30701@mtcc.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 18:56:42 -0000 Framing this as an OAuth issue is wrong. In your scenario: 1. Install bad app 2. Do protocol X 3. Bad things happen X can be anything. For example, the app can add a root cert to your os and = break TLS protection.=20 EHL On Sep 6, 2011, at 11:50, "Michael Thomas" wrote: > William Mills wrote: >> OAuth doesn't solve this problem, and can't. Generally the question is= =20 >> whether the app appears to come from a reputable source, and nowadays=20 >> whether it's signed (in windows land) or otherwize certified by the=20 >> provider. >>=20 >> If you manage to solve this problem in a real way I'd be interested in=20 >> investing in your company. >=20 > Then what I don't see anywhere is that oauth is not applicable to embedde= d > web objects, and that end users should *never* trust oauth in a, say, pho= ne > app. As far as I can tell, the server deploying oauth can't tell that it'= s > being misused, so this is all on the shoulders of the end user. >=20 > It sure looks like oauth is easily subverted in the real world. >=20 > Mike >=20 >>=20 >> ------------------------------------------------------------------------ >> *From:* Michael Thomas >> *To:* Eran Hammer-Lahav >> *Cc:* "oauth@ietf.org" >> *Sent:* Tuesday, September 6, 2011 11:34 AM >> *Subject:* Re: [OAUTH-WG] problem statement >>=20 >> Eran Hammer-Lahav wrote: >>> Don't install crap on you device or computer. OAuth is the least of=20 >> your concern if you install bad software. >>> If there was a solution to this we would not need an antivirus. >>=20 >> How exactly does an end user know what is "crap" or not? Or are you just= =20 >> dismissive of apps in >> general? I don't think that apple and google are going to close up shop= =20 >> because it breaks oauth's >> trust model. >>=20 >> Mike >>=20 >>>=20 >>> EHL >>> On Sep 6, 2011, at 11:23, "Michael Thomas" > > wrote: >>>=20 >>>> Eran Hammer-Lahav wrote: >>>>> I agree. If you are going to install a native app, you better trust=20 >> it not to do bad things. Grabbing your password is the least interesting= =20 >> thing such an app can abuse. I don't see any need to change the v2 draft= . >>>> How, exactly, is the user supposed to protect themselves against=20 >> rogue apps? >>>> It sounds like the solution is to tell them to never use oauth in an=20 >> app at all. >>>>=20 >>>> Is oauth only intended to be used on standalone trustable web=20 >> browsers? I don't recall >>>> seeing that anywhere. >>>>=20 >>>> Mike >>>>=20 >>>>> EHL >>>>>=20 >>>>> On Sep 6, 2011, at 11:10, "Igor Faynberg"=20 >> > > wrote: >>>>>=20 >>>>>> Mike, >>>>>>=20 >>>>>> You've got the problem statement right: allowing the user to=20 >> authorize resource access to another party without divulging user's=20 >> credentials is the objective of OAuth. You are also right in that the=20 >> attack you have described defies the whole purpose of OAuth. I do not=20 >> think though that it is related to OAuth per se. >>>>>>=20 >>>>>> To this end, the security work led by Torsten has thoroughly=20 >> analyzed the protocol and specified protection against multiple protocol= =20 >> attacks. From what you described, it appears to me that the attack you= =20 >> mention is not related to the protocol but rather to the user's=20 >> environment. There is no possible protection from key loggers that a=20 >> protocol can implement. I could be mistaken; in any case, it looks like= =20 >> the problem rests with the implementation of WebView. >>>>>>=20 >>>>>> If I am wrong, I would appreciate a detailed description of what=20 >> happened. >>>>>>=20 >>>>>> Igor >>>>>>=20 >>>>>> On 9/6/2011 1:40 PM, Michael Thomas wrote: >>>>>>> Hi all, >>>>>>>=20 >>>>>>> Barry suggested that I might subscribe and explain what I sent him. >>>>>>>=20 >>>>>>> My basic problem is that in neither the protocol nor the threats=20 >> drafts, >>>>>>> I can't seem to find what problem is actually trying to be solved=20 >> with >>>>>>> oauth, and what assumptions you're making about various elements. >>>>>>>=20 >>>>>>> Here's what I did. I've written an app, and I wanted re-integrate t= he >>>>>>> ability to send tweets after they deprecated Basic. So the app has = a >>>>>>> webView (android, iphone...) which it obviously completely controls= . >>>>>>> With oauth, the webview UA will ultimately redirect off to Twitter'= s >>>>>>> site to collect the user's credentials and grant my app's backend a= n >>>>>>> access token (sorry if I get terminology screwed up, i'm just comin= g >>>>>>> up to speed). >>>>>>>=20 >>>>>>> What occurs to me is that webview affords exactly zero protection=20 >> from >>>>>>> my client (ie, the app) from getting the user's twitter=20 >> credentials. All >>>>>>> I have to do is set up a keypress handler on that webview and in=20 >> a few >>>>>>> minutes of hacking I have a key logger. etc. >>>>>>>=20 >>>>>>> So what I can't tell is whether this is a "problem" or not, because= I >>>>>>> don't know what problem you're trying to solve. If the object of=20 >> oauth >>>>>>> isn't to keep user/server credentials out of the hands of a third=20 >> party, >>>>>>> then what is it trying to solve? Is there an expectation that the >>>>>>> UA is trusted by the user/server? What happens when that's not=20 >> the case? >>>>>>>=20 >>>>>>> Regardless of whether I'm misunderstanding, it would sure be nice=20 >> to have >>>>>>> both the problem and your assumptions laid out, hopefully with=20 >> some prominence >>>>>>> so you don't get these sort of dumb questions. >>>>>>>=20 >>>>>>> Mike >>>>>>> _______________________________________________ >>>>>>> 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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >=20 From mike@mtcc.com Tue Sep 6 12:01: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 5C54D21F8B46 for ; Tue, 6 Sep 2011 12:01:35 -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 jocRgzoOizl8 for ; Tue, 6 Sep 2011 12:01:34 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 43B7C21F8661 for ; Tue, 6 Sep 2011 12:01:34 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86J3JvB014835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 12:03:20 -0700 Message-ID: <4E666E73.3050502@mtcc.com> Date: Tue, 06 Sep 2011 12:03:15 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> In-Reply-To: <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6738; t=1315335801; x=1316199801; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=LnHJUeQEAMRvMe7Lu26fGHt492iQy7tdg67EHEFgLMc=; b=MKtBoWuMxnP6zj/17slnS0q1o5DzMVQoVbt9zCYtJbNwS5MzWJoqlgv3m7 cnXSnILbCpFQNgAh+I6mYVYobXMz6ncr1z3kxoaMN8PZOmTLJskp+VJ1DFe3 i8jLyvnFfEyY/WJA3VSkAc7N6h3MhhMhEzCEP9doxS8U6071zvZAs=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:01:35 -0000 Eran Hammer-Lahav wrote: > Framing this as an OAuth issue is wrong. In your scenario: > > 1. Install bad app > 2. Do protocol X > 3. Bad things happen No. It's 1. Install app. Users don't know which are which. Have you ever used oauth through a phone app? How did you determine it wasn't evil? The yahoo guy here apparently has lots of money if you can tell him too. Mike > > X can be anything. For example, the app can add a root cert to your os and break TLS protection. > > EHL > > On Sep 6, 2011, at 11:50, "Michael Thomas" wrote: > >> William Mills wrote: >>> OAuth doesn't solve this problem, and can't. Generally the question is >>> whether the app appears to come from a reputable source, and nowadays >>> whether it's signed (in windows land) or otherwize certified by the >>> provider. >>> >>> If you manage to solve this problem in a real way I'd be interested in >>> investing in your company. >> Then what I don't see anywhere is that oauth is not applicable to embedded >> web objects, and that end users should *never* trust oauth in a, say, phone >> app. As far as I can tell, the server deploying oauth can't tell that it's >> being misused, so this is all on the shoulders of the end user. >> >> It sure looks like oauth is easily subverted in the real world. >> >> Mike >> >>> ------------------------------------------------------------------------ >>> *From:* Michael Thomas >>> *To:* Eran Hammer-Lahav >>> *Cc:* "oauth@ietf.org" >>> *Sent:* Tuesday, September 6, 2011 11:34 AM >>> *Subject:* Re: [OAUTH-WG] problem statement >>> >>> Eran Hammer-Lahav wrote: >>>> Don't install crap on you device or computer. OAuth is the least of >>> your concern if you install bad software. >>>> If there was a solution to this we would not need an antivirus. >>> How exactly does an end user know what is "crap" or not? Or are you just >>> dismissive of apps in >>> general? I don't think that apple and google are going to close up shop >>> because it breaks oauth's >>> trust model. >>> >>> Mike >>> >>>> EHL >>>> On Sep 6, 2011, at 11:23, "Michael Thomas" >> > wrote: >>>>> Eran Hammer-Lahav wrote: >>>>>> I agree. If you are going to install a native app, you better trust >>> it not to do bad things. Grabbing your password is the least interesting >>> thing such an app can abuse. I don't see any need to change the v2 draft. >>>>> How, exactly, is the user supposed to protect themselves against >>> rogue apps? >>>>> It sounds like the solution is to tell them to never use oauth in an >>> app at all. >>>>> Is oauth only intended to be used on standalone trustable web >>> browsers? I don't recall >>>>> seeing that anywhere. >>>>> >>>>> Mike >>>>> >>>>>> EHL >>>>>> >>>>>> On Sep 6, 2011, at 11:10, "Igor Faynberg" >>> >> > wrote: >>>>>>> Mike, >>>>>>> >>>>>>> You've got the problem statement right: allowing the user to >>> authorize resource access to another party without divulging user's >>> credentials is the objective of OAuth. You are also right in that the >>> attack you have described defies the whole purpose of OAuth. I do not >>> think though that it is related to OAuth per se. >>>>>>> To this end, the security work led by Torsten has thoroughly >>> analyzed the protocol and specified protection against multiple protocol >>> attacks. From what you described, it appears to me that the attack you >>> mention is not related to the protocol but rather to the user's >>> environment. There is no possible protection from key loggers that a >>> protocol can implement. I could be mistaken; in any case, it looks like >>> the problem rests with the implementation of WebView. >>>>>>> If I am wrong, I would appreciate a detailed description of what >>> happened. >>>>>>> Igor >>>>>>> >>>>>>> On 9/6/2011 1:40 PM, Michael Thomas wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Barry suggested that I might subscribe and explain what I sent him. >>>>>>>> >>>>>>>> My basic problem is that in neither the protocol nor the threats >>> drafts, >>>>>>>> I can't seem to find what problem is actually trying to be solved >>> with >>>>>>>> oauth, and what assumptions you're making about various elements. >>>>>>>> >>>>>>>> Here's what I did. I've written an app, and I wanted re-integrate the >>>>>>>> ability to send tweets after they deprecated Basic. So the app has a >>>>>>>> webView (android, iphone...) which it obviously completely controls. >>>>>>>> With oauth, the webview UA will ultimately redirect off to Twitter's >>>>>>>> site to collect the user's credentials and grant my app's backend an >>>>>>>> access token (sorry if I get terminology screwed up, i'm just coming >>>>>>>> up to speed). >>>>>>>> >>>>>>>> What occurs to me is that webview affords exactly zero protection >>> from >>>>>>>> my client (ie, the app) from getting the user's twitter >>> credentials. All >>>>>>>> I have to do is set up a keypress handler on that webview and in >>> a few >>>>>>>> minutes of hacking I have a key logger. etc. >>>>>>>> >>>>>>>> So what I can't tell is whether this is a "problem" or not, because I >>>>>>>> don't know what problem you're trying to solve. If the object of >>> oauth >>>>>>>> isn't to keep user/server credentials out of the hands of a third >>> party, >>>>>>>> then what is it trying to solve? Is there an expectation that the >>>>>>>> UA is trusted by the user/server? What happens when that's not >>> the case? >>>>>>>> Regardless of whether I'm misunderstanding, it would sure be nice >>> to have >>>>>>>> both the problem and your assumptions laid out, hopefully with >>> some prominence >>>>>>>> so you don't get these sort of dumb questions. >>>>>>>> >>>>>>>> Mike >>>>>>>> _______________________________________________ >>>>>>>> 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 jill@adaburrows.com Tue Sep 6 12:10: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 204C621F8D5B for ; Tue, 6 Sep 2011 12:10:32 -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 4zWRKq40s731 for ; Tue, 6 Sep 2011 12:10:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5ED21F8D64 for ; Tue, 6 Sep 2011 12:10:15 -0700 (PDT) Received: by iakc1 with SMTP id c1so100089iak.31 for ; Tue, 06 Sep 2011 12:12:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.146.7 with SMTP id h7mr1574584icv.197.1315336319752; Tue, 06 Sep 2011 12:11:59 -0700 (PDT) Received: by 10.231.53.196 with HTTP; Tue, 6 Sep 2011 12:11:59 -0700 (PDT) X-Originating-IP: [209.63.10.109] In-Reply-To: <4E666E73.3050502@mtcc.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> Date: Tue, 6 Sep 2011 12:11:59 -0700 Message-ID: From: Jill Burrows To: Michael Thomas Content-Type: multipart/alternative; boundary=90e6ba6135b4195a8004ac4a9a1a Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:10:32 -0000 --90e6ba6135b4195a8004ac4a9a1a Content-Type: text/plain; charset=UTF-8 Mike, Let me say this: If I hired a developer to write an app for me for, I would expect that developer to not implement a key logger or anything that could damage my company's reputation down the line. If I reviewed the code and found something suspicious, I would terminate their contract. Generally, companies who care about their brand and reputation implement trusted applications. There are times when they may contract with people who are shady, but they will find out later once the damage is done that they needed to do more research and hire someone who could be trusted to not injure their brand. If that company's brand suffered, I would hope they sued the developer for damages to teach that shady developer a lesson. It is definitely up to people to choose what they install on their devices. If they randomly install malicious software, I'm sure that getting credentials to an OAuth enabled site is the least of what they could do. Someone could write an app for anything, like a bank and steal the users credentials for that. It doesn't matter the protocol involved if the application or website, is made to do something malicious. People who are susceptible to installing non-trusted applications might also suffer from a rootkit infestation -- in which case, their social media credentials might be the least of their worries, since all of the information on their device would be available to the writer of the rootkit. I repeat, it is not an OAuth problem. Perhaps, companies that implement OAuth servers for their service should remind developers and users what to expect with OAuth on their service. As for as I know, it is not in the scope of the OAuth specification to clearly state things which are entirely dependent on a certain services implementation of OAuth. -Jill On Tue, Sep 6, 2011 at 12:03 PM, Michael Thomas wrote: > Eran Hammer-Lahav wrote: > >> Framing this as an OAuth issue is wrong. In your scenario: >> >> 1. Install bad app >> 2. Do protocol X >> 3. Bad things happen >> > > No. It's > > 1. Install app. > > Users don't know which are which. Have you ever used oauth through a phone > app? How > did you determine it wasn't evil? The yahoo guy here apparently has lots of > money > if you can tell him too. > > Mike > > > >> X can be anything. For example, the app can add a root cert to your os and >> break TLS protection. >> EHL >> >> On Sep 6, 2011, at 11:50, "Michael Thomas" wrote: >> >> William Mills wrote: >>> >>>> OAuth doesn't solve this problem, and can't. Generally the question is >>>> whether the app appears to come from a reputable source, and nowadays >>>> whether it's signed (in windows land) or otherwize certified by the >>>> provider. >>>> >>>> If you manage to solve this problem in a real way I'd be interested in >>>> investing in your company. >>>> >>> Then what I don't see anywhere is that oauth is not applicable to >>> embedded >>> web objects, and that end users should *never* trust oauth in a, say, >>> phone >>> app. As far as I can tell, the server deploying oauth can't tell that >>> it's >>> being misused, so this is all on the shoulders of the end user. >>> >>> It sure looks like oauth is easily subverted in the real world. >>> >>> Mike >>> >>> ------------------------------**------------------------------** >>>> ------------ >>>> *From:* Michael Thomas >>>> *To:* Eran Hammer-Lahav >>>> *Cc:* "oauth@ietf.org" >>>> *Sent:* Tuesday, September 6, 2011 11:34 AM >>>> *Subject:* Re: [OAUTH-WG] problem statement >>>> >>>> Eran Hammer-Lahav wrote: >>>> >>>>> Don't install crap on you device or computer. OAuth is the least of >>>>> >>>> your concern if you install bad software. >>>> >>>>> If there was a solution to this we would not need an antivirus. >>>>> >>>> How exactly does an end user know what is "crap" or not? Or are you just >>>> dismissive of apps in >>>> general? I don't think that apple and google are going to close up shop >>>> because it breaks oauth's >>>> trust model. >>>> >>>> Mike >>>> >>>> EHL >>>>> On Sep 6, 2011, at 11:23, "Michael Thomas" >>>> >>>> > wrote: >>>> >>>>> Eran Hammer-Lahav wrote: >>>>>> >>>>>>> I agree. If you are going to install a native app, you better trust >>>>>>> >>>>>> it not to do bad things. Grabbing your password is the least >>>> interesting thing such an app can abuse. I don't see any need to change the >>>> v2 draft. >>>> >>>>> How, exactly, is the user supposed to protect themselves against >>>>>> >>>>> rogue apps? >>>> >>>>> It sounds like the solution is to tell them to never use oauth in an >>>>>> >>>>> app at all. >>>> >>>>> Is oauth only intended to be used on standalone trustable web >>>>>> >>>>> browsers? I don't recall >>>> >>>>> seeing that anywhere. >>>>>> >>>>>> Mike >>>>>> >>>>>> EHL >>>>>>> >>>>>>> On Sep 6, 2011, at 11:10, "Igor Faynberg" >>>>>>> >>>>>> >>> igor.faynberg@alcatel-**lucent.com >> >>>> wrote: >>>> >>>>> Mike, >>>>>>>> >>>>>>>> You've got the problem statement right: allowing the user to >>>>>>>> >>>>>>> authorize resource access to another party without divulging user's >>>> credentials is the objective of OAuth. You are also right in that the attack >>>> you have described defies the whole purpose of OAuth. I do not think though >>>> that it is related to OAuth per se. >>>> >>>>> To this end, the security work led by Torsten has thoroughly >>>>>>>> >>>>>>> analyzed the protocol and specified protection against multiple >>>> protocol attacks. From what you described, it appears to me that the attack >>>> you mention is not related to the protocol but rather to the user's >>>> environment. There is no possible protection from key loggers that a >>>> protocol can implement. I could be mistaken; in any case, it looks like the >>>> problem rests with the implementation of WebView. >>>> >>>>> If I am wrong, I would appreciate a detailed description of what >>>>>>>> >>>>>>> happened. >>>> >>>>> Igor >>>>>>>> >>>>>>>> On 9/6/2011 1:40 PM, Michael Thomas wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Barry suggested that I might subscribe and explain what I sent him. >>>>>>>>> >>>>>>>>> My basic problem is that in neither the protocol nor the threats >>>>>>>>> >>>>>>>> drafts, >>>> >>>>> I can't seem to find what problem is actually trying to be solved >>>>>>>>> >>>>>>>> with >>>> >>>>> oauth, and what assumptions you're making about various elements. >>>>>>>>> >>>>>>>>> Here's what I did. I've written an app, and I wanted re-integrate >>>>>>>>> the >>>>>>>>> ability to send tweets after they deprecated Basic. So the app has >>>>>>>>> a >>>>>>>>> webView (android, iphone...) which it obviously completely >>>>>>>>> controls. >>>>>>>>> With oauth, the webview UA will ultimately redirect off to >>>>>>>>> Twitter's >>>>>>>>> site to collect the user's credentials and grant my app's backend >>>>>>>>> an >>>>>>>>> access token (sorry if I get terminology screwed up, i'm just >>>>>>>>> coming >>>>>>>>> up to speed). >>>>>>>>> >>>>>>>>> What occurs to me is that webview affords exactly zero protection >>>>>>>>> >>>>>>>> from >>>> >>>>> my client (ie, the app) from getting the user's twitter >>>>>>>>> >>>>>>>> credentials. All >>>> >>>>> I have to do is set up a keypress handler on that webview and in >>>>>>>>> >>>>>>>> a few >>>> >>>>> minutes of hacking I have a key logger. etc. >>>>>>>>> >>>>>>>>> So what I can't tell is whether this is a "problem" or not, because >>>>>>>>> I >>>>>>>>> don't know what problem you're trying to solve. If the object of >>>>>>>>> >>>>>>>> oauth >>>> >>>>> isn't to keep user/server credentials out of the hands of a third >>>>>>>>> >>>>>>>> party, >>>> >>>>> then what is it trying to solve? Is there an expectation that the >>>>>>>>> UA is trusted by the user/server? What happens when that's not >>>>>>>>> >>>>>>>> the case? >>>> >>>>> Regardless of whether I'm misunderstanding, it would sure be nice >>>>>>>>> >>>>>>>> to have >>>> >>>>> both the problem and your assumptions laid out, hopefully with >>>>>>>>> >>>>>>>> some prominence >>>> >>>>> so you don't get these sort of dumb questions. >>>>>>>>> >>>>>>>>> Mike >>>>>>>>> ______________________________**_________________ >>>>>>>>> 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 >>>> >>>> >>>> > ______________________________**_________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/**listinfo/oauth > -- Thanks, Jill Burrows CTO / Lead Technologist - uLynk Consultant / Technologist - Creative Sagacity +1 503 208 5455 jill@adaburrows.com http://adaburrows.com @jburrows (http://twitter.com/jburrows) --90e6ba6135b4195a8004ac4a9a1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike,

Let me say this:

If I hir= ed a developer to write an app for me for, I would expect that developer to= not implement a key logger or anything that could damage my company's = reputation down the line. If I reviewed the code and found something suspic= ious, I would terminate their contract.

Generally, companies who care about their brand and rep= utation implement trusted applications. There are times when they may contr= act with people who are shady, but they will find out later once the damage= is done that they needed to do more research and hire someone who could be= trusted to not injure their brand. If that company's brand suffered, I= would hope they sued the developer for damages to teach that shady develop= er a lesson.

It is definitely up to people to choose what they insta= ll on their devices. If they randomly install malicious software, I'm s= ure that getting credentials to an OAuth enabled site is the least of what = they could do. Someone could write an app for anything, like a bank and ste= al the users credentials for that. It doesn't matter the protocol invol= ved if the application or website, is made to do something malicious.

People who are susceptible to installing non-trusted ap= plications might also suffer from a rootkit infestation -- in which case, t= heir social media credentials might be the least of their worries, since al= l of the information on their device would be available to the writer of th= e rootkit.

I repeat, it is not an OAuth problem.

Perhaps, companies that implement OAuth servers for their service s= hould remind developers and users what to expect with OAuth on their servic= e. As for as I know, it is not in the scope of the OAuth specification to c= learly state things which are entirely dependent on a certain services impl= ementation of OAuth.

-Jill


On Tue, Sep 6, 2011 at 12:03 PM, Michael Thomas <mike@mtcc.com> wrote:
Eran Hammer-Lahav wrote:
Framing this as an OAuth issue is wrong. In your scenario:

1. Install bad app
2. Do protocol X
3. Bad things happen

No. It's

1. Install app.

Users don't know which are which. Have you ever used oauth through a ph= one app? How
did you determine it wasn't evil? The yahoo guy here apparently has lot= s of money
if you can tell him too.

Mike



X can be anything. For example, the app can add a root cert to your os and = break TLS protection.
EHL

On Sep 6, 2011, at 11:50, "Michael Thomas" <mike@mtcc.com> wrote:

William Mills wrote:
OAuth doesn't solve this problem, and can't. =C2=A0Generally the qu= estion is whether the app appears to come from a reputable source, and nowa= days whether it's signed (in windows land) or otherwize certified by th= e provider.

If you manage to solve this problem in a real way I'd be interested in = investing in your company.
Then what I don't see anywhere is that oauth is not applicable to embed= ded
web objects, and that end users should *never* trust oauth in a, say, phone=
app. As far as I can tell, the server deploying oauth can't tell that i= t's
being misused, so this is all on the shoulders of the end user.

It sure looks like oauth is easily subverted in the real world.

Mike

-------------------------------------------------------------= -----------
*From:* Michael Thomas <mike@mtcc.com>
*To:* Eran Hammer-Lahav <eran@hueniverse.com>
*Cc:* "oauth@ietf.= org" <oauth= @ietf.org>
*Sent:* Tuesday, September 6, 2011 11:34 AM
*Subject:* Re: [OAUTH-WG] problem statement

Eran Hammer-Lahav wrote:
Don't install crap on you device or computer. OAuth is the least of
your concern if you install bad software.
If there was a solution to this we would not need an antivirus.
How exactly does an end user know what is "crap" or not? Or are y= ou just dismissive of apps in
general? I don't think that apple and google are going to close up shop= because it breaks oauth's
trust model.

Mike

EHL
On Sep 6, 2011, at 11:23, "Michael Thomas" <mike@mtcc.com
<mailto:mike@mtcc.com= >> wrote:
Eran Hammer-Lahav wrote:
I agree. If you are going to install a native app, you better trust
it not to do bad things. Grabbing your password is the least interesting th= ing such an app can abuse. I don't see any need to change the v2 draft.=
How, exactly, is the user supposed to protect themselves against
rogue apps?
It sounds like the solution is to tell them to never use oauth in an
app at all.
Is oauth only intended to be used on standalone trustable web
browsers? I don't recall
seeing that anywhere.

Mike

EHL

On Sep 6, 2011, at 11:10, "Igor Faynberg"
<i= gor.faynberg@alcatel-lucent.com <mailto:igor.faynberg@alcatel-<= /u>lucent.com>> wrote:
Mike,

You've got the problem statement right: allowing the user to
authorize =C2=A0resource access to another party without divulging user'= ;s credentials is the objective of OAuth. You are also right in that the at= tack you have described defies the whole purpose of OAuth. =C2=A0I do not t= hink though that it is related to OAuth per se.
To this end, the security work led by Torsten has thoroughly
analyzed the protocol and specified protection against multiple protocol at= tacks. =C2=A0From what you described, it appears to me that the attack you = mention is not related to the protocol but rather to the user's environ= ment. =C2=A0There is no possible protection from key loggers that a protoco= l can implement. I could be mistaken; in any case, it looks like the proble= m rests with the implementation of WebView.
If I am wrong, I would appreciate a detailed description of what
happened.
Igor

On 9/6/2011 1:40 PM, Michael Thomas wrote:
Hi all,

Barry suggested that I might subscribe and explain what I sent him.

My basic problem is that in neither the protocol nor the threats
drafts,
I can't seem to find what problem is actually trying to be solved
with
oauth, and what assumptions you're making about various elements.

Here's what I did. I've written an app, and I wanted re-integrate t= he
ability to send tweets after they deprecated Basic. So the app has a
webView (android, iphone...) which it obviously completely controls.
With oauth, the webview UA will ultimately redirect off to Twitter's site to collect the user's credentials and grant my app's backend a= n
access token (sorry if I get terminology screwed up, i'm just coming up to speed).

What occurs to me is that webview affords exactly zero protection
from
my client (ie, the app) from getting the user's twitter
credentials. All
I have to do is set up a keypress handler on that webview and in
a few
minutes of hacking I have a key logger. etc.

So what I can't tell is whether this is a "problem" or not, b= ecause I
don't know what problem you're trying to solve. If the object of
oauth
isn't to keep user/server credentials out of the hands of a third
party,
then what is it trying to solve? Is there an expectation that the
UA is trusted by the user/server? What happens when that's not
the case?
Regardless of whether I'm misunderstanding, it would sure be nice
to have
both the problem and your assumptions laid out, hopefully with
some prominence
so you don't get these sort of dumb questions.

Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org <= mailto:OAuth@ietf.org>
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <= mailto:OAuth@ietf.org>
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <= mailto:OAuth@ietf.org>
h= ttps://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <= mailto: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



--
= Thanks,

Jill Burrows
CTO / Lead Techno= logist - uLynk
Consultant / Technologist - Creative Sagacity
+1 503 208 5455
jill@adaburrows.com
http://adaburrows.com
@jburrows (http://twitter.com/jburrows)

--90e6ba6135b4195a8004ac4a9a1a-- From eran@hueniverse.com Tue Sep 6 12:12: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 A600D21F8D97 for ; Tue, 6 Sep 2011 12:12:59 -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 AMoKGPiqXS0O for ; Tue, 6 Sep 2011 12:12:58 -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 455F321F8D3A for ; Tue, 6 Sep 2011 12:12:58 -0700 (PDT) Received: (qmail 13925 invoked from network); 6 Sep 2011 19:14:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Sep 2011 19:14:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 6 Sep 2011 12:14:29 -0700 From: Eran Hammer-Lahav To: Michael Thomas Date: Tue, 6 Sep 2011 12:14:23 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: AcxsyTL1IaHryGjUSwGYUcvs3qDjtQ== Message-ID: In-Reply-To: <4E666D43.5030407@mtcc.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_CA8BBD69193BEeranhueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:13:00 -0000 --_000_CA8BBD69193BEeranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You are one making the argument that no one should be installing apps. There is no known way to stop users from installing malware and viruses oth= er than not letting them install anything off a whitelist. The problem you = are describing has nothing to do with OAuth, its a fundamental problem with= running untrusted code on your devices. Once you do that, yes, OAuth can b= e exploited but that's true for every authentication scheme when one side i= s compromised. My point, which you seems to miss, is that the same argument can be made ag= ainst any other protocol. TLS offers your certain protections but they are = all gone if you install a bad native app =96 following your logic people sh= ould not use TLS in apps either. I do not consider this an issue. EHL From: Michael Thomas > Date: Tue, 6 Sep 2011 11:58:11 -0700 To: Eran Hammer-lahav > Cc: "igor.faynberg@alcatel-lucent.com" >, "oauth@ietf.org" > Subject: Re: [OAUTH-WG] problem statement Eran Hammer-Lahav wrote: I'm dismissive of this being an OAuth problem. Which brings us back to my original problem: what is the problem it's tryin= g to solve? What are the assumptions it makes? What is its applicability? None of those= are addressed very well if at all in the drafts. I'm sure that I'm not the only one who w= ould be very surprised to hear that using oauth on a phone app is a bad idea. Put it this way: your favorite example of a photo printing service needing = access to flickr. It's ok if you do that from a browser, but not if the photo printer makes a= n app. How many users, exactly, are going to know that they shouldn't do the second one? I think that's an oauth problem because oauth makes it *seem* like you're p= rotected from the third party, whereas if the app itself asked for your login credentials= there would be far less confusion. So in that sense, oauth is making things worse, not = better. Mike EHL On Sep 6, 2011, at 11:35, "Michael Thomas" > wrote: Eran Hammer-Lahav wrote: Don't install crap on you device or computer. OAuth is the least of your co= ncern if you install bad software. If there was a solution to this we would not need an antivirus. How exactly does an end user know what is "crap" or not? Or are you just di= smissive of apps in general? I don't think that apple and google are going to close up shop bec= ause it breaks oauth's trust model. Mike EHL On Sep 6, 2011, at 11:23, "Michael Thomas" > wrote: Eran Hammer-Lahav wrote: I agree. If you are going to install a native app, you better trust it not = to do bad things. Grabbing your password is the least interesting thing suc= h an app can abuse. I don't see any need to change the v2 draft. How, exactly, is the user supposed to protect themselves against rogue apps= ? It sounds like the solution is to tell them to never use oauth in an app at= all. Is oauth only intended to be used on standalone trustable web browsers? I d= on't recall seeing that anywhere. Mike EHL On Sep 6, 2011, at 11:10, "Igor Faynberg" > wrote: Mike, You've got the problem statement right: allowing the user to authorize resource access to another party without divulging user's credentials is the objective of OAuth. You are also right in that the attack you have described defies the whole purpose of OAuth. I do not think though that it is related to OAuth per se. To this end, the security work led by Torsten has thoroughly analyzed the protocol and specified protection against multiple protocol attacks. From what you described, it appears to me that the attack you mention is not related to the protocol but rather to the user's environment. There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like the problem rests with the implementation of WebView. If I am wrong, I would appreciate a detailed description of what happened. Igor On 9/6/2011 1:40 PM, Michael Thomas wrote: Hi all, Barry suggested that I might subscribe and explain what I sent him. My basic problem is that in neither the protocol nor the threats drafts, I can't seem to find what problem is actually trying to be solved with oauth, and what assumptions you're making about various elements. Here's what I did. I've written an app, and I wanted re-integrate the ability to send tweets after they deprecated Basic. So the app has a webView (android, iphone...) which it obviously completely controls. With oauth, the webview UA will ultimately redirect off to Twitter's site to collect the user's credentials and grant my app's backend an access token (sorry if I get terminology screwed up, i'm just coming up to speed). What occurs to me is that webview affords exactly zero protection from my client (ie, the app) from getting the user's twitter credentials. All I have to do is set up a keypress handler on that webview and in a few minutes of hacking I have a key logger. etc. So what I can't tell is whether this is a "problem" or not, because I don't know what problem you're trying to solve. If the object of oauth isn't to keep user/server credentials out of the hands of a third party, then what is it trying to solve? Is there an expectation that the UA is trusted by the user/server? What happens when that's not the case? Regardless of whether I'm misunderstanding, it would sure be nice to have both the problem and your assumptions laid out, hopefully with some prominence so you don't get these sort of dumb questions. Mike _______________________________________________ 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_CA8BBD69193BEeranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
You are one making the argument= that no one should be installing apps.

There is n= o known way to stop users from installing malware and viruses other than no= t letting them install anything off a whitelist. The problem you are descri= bing has nothing to do with OAuth, its a fundamental problem with running u= ntrusted code on your devices. Once you do that, yes, OAuth can be exploite= d but that's true for every authentication scheme when one side is compromi= sed.

My point, which you seems to miss, is that th= e same argument can be made against any other protocol. TLS offers your cer= tain protections but they are all gone if you install a bad native app =96 = following your logic people should not use TLS in apps either.
I do not consider this an issue.

EHL<= /div>

From: Mic= hael Thomas <mike@mtcc.com>
<= span style=3D"font-weight:bold">Date: Tue, 6 Sep 2011 11:58:11 -070= 0
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: "igor.faynberg@alcatel-lucent.com" <igor.faynberg@alcatel-lucent.c= om>, "oauth@ietf.org"= ; <oauth@ietf.org>
Subject: Re: [OAUTH-WG] problem statement

=
Eran Hammer-Lahav wrote:
I'm dismissive of this being an OAuth problem. =

Which brings us back to my original = problem: what is the problem it's trying to solve?
What are the a= ssumptions it makes? What is its applicability? None of those are addressed=
very well if at all in the drafts. I'm sure that I'm not the onl= y one who would be very
surprised to hear that using oauth on a p= hone app is a bad idea.

Put it this way: your favo= rite example of a photo printing service needing access to flickr.
It's ok if you do that from a browser, but not if the photo printer makes= an app. How many users,
exactly, are going to know that they sho= uldn't do the second one?

I think that's an oauth = problem because oauth makes it *seem* like you're protected from
= the third party, whereas if the app itself asked for your login credentials= there would
be far less confusion. So in that sense, oauth is ma= king things worse, not better.

Mike

=
= EHL
On Sep 6, 2011, at 11:35, "Michael Thomas&= quot; <mike@mtcc.com> wrote:
E= ran Hammer-Lahav wrote:
Don't install crap on you device or computer. OAuth is the leas= t of your concern if you install bad software.

I= f there was a solution to this we would not need an antivirus.
How exactly does an end user know what is "crap" or = not? Or are you just dismissive of apps in
general? I don't thin= k that apple and google are going to close up shop because it breaks oauth'= s
trust model.

Mike

EHL
=
On Sep 6, 2011, at 11:23, "Michael Thomas" <mike@mtcc.com> wrote:

<= /div>
Eran Hammer-= Lahav wrote:
= I agree. If you are going to install a native app, you better trust it not= to do bad things. Grabbing your password is the least interesting thing su= ch an app can abuse. I don't see any need to change the v2 draft.
How, exactly, is the user supposed to protect themselves ag= ainst rogue apps?
It sounds like the solution is to tell them to= never use oauth in an app at all.

Is oauth only = intended to be used on standalone trustable web browsers? I don't recall
seeing that anywhere.

Mike
EHL
<= div>
On Sep 6, 2011, at 11:10, "Igor Faynberg" <= ;igor.faynberg@alcatel-= lucent.com> wrote:

Mike,

You've got the= problem statement right: allowing the user to authorize  
<= div> resource access to another party without divulging user's credentials = is
the objective of OAuth. You are also right in that the attac= k you have
described defies the whole purpose of OAuth. &n= bsp;I do not think though that
it is related to OAuth per se.

To this end, the security work led by Torsten has = thoroughly analyzed
the protocol and specified protection again= st multiple protocol
attacks.  From what you describe= d, it appears to me that the attack you
mention is not related = to the protocol but rather to the user's
environment. &nbs= p;There is no possible protection from key loggers that a
proto= col can implement. I could be mistaken; in any case, it looks like
the problem rests with the implementation of WebView.

If I am wrong, I would appreciate a detailed description of what h= appened.

Igor

On 9/6/20= 11 1:40 PM, Michael Thomas wrote:
Hi all,

Barry suggested tha= t I might subscribe and explain what I sent him.

= My basic problem is that in neither the protocol nor the threats drafts,
I can't seem to find what problem is actually trying to be solved = with
oauth, and what assumptions you're making about various ele= ments.

Here's what I did. I've written an app, an= d I wanted re-integrate the
ability to send tweets after they de= precated Basic. So the app has a
webView (android, iphone...) wh= ich it obviously completely controls.
With oauth, the webview UA= will ultimately redirect off to Twitter's
site to collect the u= ser's credentials and grant my app's backend an
access token (so= rry if I get terminology screwed up, i'm just coming
up to speed= ).

What occurs to me is that webview affords exac= tly zero protection from
my client (ie, the app) from getting th= e user's twitter credentials. All
I have to do is set up a keypr= ess handler on that webview and in a few
minutes of hacking I ha= ve a key logger. etc.

So what I can't tell is whe= ther this is a "problem" or not, because I
don't know = what problem you're trying to solve. If the object of oauth
isn'= t to keep user/server credentials out of the hands of a third party,
<= div> then what is it trying to solve? Is there an expectation that the
UA is trusted by the user/server? What happens when that's not the c= ase?

Regardless of whether I'm misunderstanding, = it would sure be nice to have
both the problem and your assumpti= ons laid out, hopefully with some
prominence
so you = don't get these sort of dumb questions.

Mike
_______________________________________________
OAuth mai= ling list
____________= ___________________________________
OAuth mailing list
OAuth@ietf.org
_____________________________= __________________
OAuth mailing list


--_000_CA8BBD69193BEeranhueniversecom_-- From aiden449@gmail.com Tue Sep 6 12:15: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 AC0A221F8DA4 for ; Tue, 6 Sep 2011 12:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.387, 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 buSq9zzA9bL7 for ; Tue, 6 Sep 2011 12:15:34 -0700 (PDT) Received: from mail-qw0-f52.google.com (mail-qw0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 269DF21F8D3A for ; Tue, 6 Sep 2011 12:15:33 -0700 (PDT) Received: by qwb8 with SMTP id 8so5742987qwb.25 for ; Tue, 06 Sep 2011 12:17: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:date:message-id:subject:from:to :content-type; bh=t72Ba9u0k+WHfjP3QcVDMmhCWBLF7FBaVyFgIxwgdRM=; b=vW0/zwjq9rmyGxu2vFRlhXRx43/hjudA5shdvax1S0+qSR+htx02fjWyf6Fy/uzJGk zd4FYjKbnN2VM0yM7T7H47nZXUBQlHYa3IbgXLB7zloE25Xlm3SxS49tBUBwD0F9MeMU tUXdnS8GFMwb0doCJS3h3WpgmOgM10F6HeowY= MIME-Version: 1.0 Received: by 10.229.71.161 with SMTP id h33mr4078545qcj.276.1315336640031; Tue, 06 Sep 2011 12:17:20 -0700 (PDT) Received: by 10.229.249.71 with HTTP; Tue, 6 Sep 2011 12:17:19 -0700 (PDT) Received: by 10.229.249.71 with HTTP; Tue, 6 Sep 2011 12:17:19 -0700 (PDT) In-Reply-To: References: <4E666D43.5030407@mtcc.com> Date: Tue, 6 Sep 2011 20:17:19 +0100 Message-ID: From: Aiden Bell To: Eran Hammer-Lahav , OAuth WG Content-Type: multipart/alternative; boundary=0016e6505810306ac204ac4aadb7 Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:15:35 -0000 --0016e6505810306ac204ac4aadb7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree. This is like saying SSL has an issue because it doesn't stop keyloggers. Not an oauth issue. sent from my android phone On Sep 6, 2011 8:14 PM, "Eran Hammer-Lahav" wrote: > You are one making the argument that no one should be installing apps. > > There is no known way to stop users from installing malware and viruses other than not letting them install anything off a whitelist. The problem you are describing has nothing to do with OAuth, its a fundamental problem with running untrusted code on your devices. Once you do that, yes, OAuth can be exploited but that's true for every authentication scheme when one side is compromised. > > My point, which you seems to miss, is that the same argument can be made against any other protocol. TLS offers your certain protections but they ar= e all gone if you install a bad native app =96 following your logic people should not use TLS in apps either. > > I do not consider this an issue. > > EHL > > From: Michael Thomas > > Date: Tue, 6 Sep 2011 11:58:11 -0700 > To: Eran Hammer-lahav > > Cc: "igor.faynberg@alcatel-lucent.com" >, "oauth@ietf.org" > > Subject: Re: [OAUTH-WG] problem statement > > Eran Hammer-Lahav wrote: > I'm dismissive of this being an OAuth problem. > > Which brings us back to my original problem: what is the problem it's trying to solve? > What are the assumptions it makes? What is its applicability? None of those are addressed > very well if at all in the drafts. I'm sure that I'm not the only one who would be very > surprised to hear that using oauth on a phone app is a bad idea. > > Put it this way: your favorite example of a photo printing service needin= g access to flickr. > It's ok if you do that from a browser, but not if the photo printer makes an app. How many users, > exactly, are going to know that they shouldn't do the second one? > > I think that's an oauth problem because oauth makes it *seem* like you're protected from > the third party, whereas if the app itself asked for your login credentials there would > be far less confusion. So in that sense, oauth is making things worse, no= t better. > > Mike > > EHL > On Sep 6, 2011, at 11:35, "Michael Thomas" > wrote: > Eran Hammer-Lahav wrote: > Don't install crap on you device or computer. OAuth is the least of your concern if you install bad software. > > If there was a solution to this we would not need an antivirus. > How exactly does an end user know what is "crap" or not? Or are you just dismissive of apps in > general? I don't think that apple and google are going to close up shop because it breaks oauth's > trust model. > > Mike > > EHL > > On Sep 6, 2011, at 11:23, "Michael Thomas" > wrote: > > Eran Hammer-Lahav wrote: > I agree. If you are going to install a native app, you better trust it no= t to do bad things. Grabbing your password is the least interesting thing suc= h an app can abuse. I don't see any need to change the v2 draft. > How, exactly, is the user supposed to protect themselves against rogue apps? > It sounds like the solution is to tell them to never use oauth in an app at all. > > Is oauth only intended to be used on standalone trustable web browsers? I don't recall > seeing that anywhere. > > Mike > > EHL > > On Sep 6, 2011, at 11:10, "Igor Faynberg" < igor.faynberg@alcatel-lucent.com> wrote: > > Mike, > > You've got the problem statement right: allowing the user to authorize > resource access to another party without divulging user's credentials is > the objective of OAuth. You are also right in that the attack you have > described defies the whole purpose of OAuth. I do not think though that > it is related to OAuth per se. > > To this end, the security work led by Torsten has thoroughly analyzed > the protocol and specified protection against multiple protocol > attacks. From what you described, it appears to me that the attack you > mention is not related to the protocol but rather to the user's > environment. There is no possible protection from key loggers that a > protocol can implement. I could be mistaken; in any case, it looks like > the problem rests with the implementation of WebView. > > If I am wrong, I would appreciate a detailed description of what happened= . > > Igor > > On 9/6/2011 1:40 PM, Michael Thomas wrote: > Hi all, > > Barry suggested that I might subscribe and explain what I sent him. > > My basic problem is that in neither the protocol nor the threats drafts, > I can't seem to find what problem is actually trying to be solved with > oauth, and what assumptions you're making about various elements. > > Here's what I did. I've written an app, and I wanted re-integrate the > ability to send tweets after they deprecated Basic. So the app has a > webView (android, iphone...) which it obviously completely controls. > With oauth, the webview UA will ultimately redirect off to Twitter's > site to collect the user's credentials and grant my app's backend an > access token (sorry if I get terminology screwed up, i'm just coming > up to speed). > > What occurs to me is that webview affords exactly zero protection from > my client (ie, the app) from getting the user's twitter credentials. All > I have to do is set up a keypress handler on that webview and in a few > minutes of hacking I have a key logger. etc. > > So what I can't tell is whether this is a "problem" or not, because I > don't know what problem you're trying to solve. If the object of oauth > isn't to keep user/server credentials out of the hands of a third party, > then what is it trying to solve? Is there an expectation that the > UA is trusted by the user/server? What happens when that's not the case? > > Regardless of whether I'm misunderstanding, it would sure be nice to have > both the problem and your assumptions laid out, hopefully with some > prominence > so you don't get these sort of dumb questions. > > Mike > _______________________________________________ > 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 > > --0016e6505810306ac204ac4aadb7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


I agree. This is like saying SSL has an issue because it doesn't stop k= eyloggers.

Not an oauth issue.

sent from my android phone

On Sep 6, 2011 8:14 PM, "Eran Hammer-Lahav&= quot; <eran@hueniverse.com>= ; wrote:
> You are one making the argument that = no one should be installing apps.
>
> There is no known way to stop users from installing malware a= nd viruses other than not letting them install anything off a whitelist. Th= e problem you are describing has nothing to do with OAuth, its a fundamenta= l problem with running untrusted code on your devices. Once you do that, ye= s, OAuth can be exploited but that's true for every authentication sche= me when one side is compromised.
>
> My point, which you seems to miss, is that the same argument = can be made against any other protocol. TLS offers your certain protections= but they are all gone if you install a bad native app =96 following your l= ogic people should not use TLS in apps either.
>
> I do not consider this an issue.
>
> EHL
>=
> From: Michael Thomas <mike@mt= cc.com<mailto:mike@mtcc.com>= >
> Date: Tue, 6 Sep 2011 11:58:11 -0700
> To: Eran Hammer-lahav <= ;eran@hueniverse.com<mailto:<= a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com>>
&g= t; Cc: "igor.faynb= erg@alcatel-lucent.com<mailto:igor.faynberg@alcatel-lucent.com>" <igor.faynberg@alcatel-lucent.com<= /a><mailto:igor.fayn= berg@alcatel-lucent.com>>, "oauth@ietf.org<mailto:oauth@ietf= .org>" <oauth@ietf.org= <mailto:oauth@ietf.org>>
> Subject: Re: [OAUTH-WG] problem statement
>
> Eran Hammer= -Lahav wrote:
> I'm dismissive of this being an OAuth problem.>
> Which brings us back to my original problem: what is the pro= blem it's trying to solve?
> What are the assumptions it makes? What is its applicability? None of = those are addressed
> very well if at all in the drafts. I'm sure= that I'm not the only one who would be very
> surprised to hear = that using oauth on a phone app is a bad idea.
>
> Put it this way: your favorite example of a photo printing se= rvice needing access to flickr.
> It's ok if you do that from a b= rowser, but not if the photo printer makes an app. How many users,
> = exactly, are going to know that they shouldn't do the second one?
>
> I think that's an oauth problem because oauth makes it *s= eem* like you're protected from
> the third party, whereas if the= app itself asked for your login credentials there would
> be far les= s confusion. So in that sense, oauth is making things worse, not better. >
> Mike
>
> EHL
> On Sep 6, 2011, at 11:35, &= quot;Michael Thomas" <mike@mtcc.co= m<mailto:mike@mtcc.com>> = wrote:
> Eran Hammer-Lahav wrote:
> Don't install crap on you device = or computer. OAuth is the least of your concern if you install bad software= .
>
> If there was a solution to this we would not need an ant= ivirus.
> How exactly does an end user know what is "crap" or not? Or = are you just dismissive of apps in
> general? I don't think that = apple and google are going to close up shop because it breaks oauth's > trust model.
>
> Mike
>
> EHL
>
&g= t; On Sep 6, 2011, at 11:23, "Michael Thomas" <mike@mtcc.com<mailto:mike@mtcc.com>> wrote:
>
> Eran Hammer-Lahav wrote:
> I agree. If you are going to= install a native app, you better trust it not to do bad things. Grabbing y= our password is the least interesting thing such an app can abuse. I don= 9;t see any need to change the v2 draft.
> How, exactly, is the user supposed to protect themselves against rogue= apps?
> It sounds like the solution is to tell them to never use oau= th in an app at all.
>
> Is oauth only intended to be used on = standalone trustable web browsers? I don't recall
> seeing that anywhere.
>
> Mike
>
> EHL
&g= t;
> On Sep 6, 2011, at 11:10, "Igor Faynberg" <igor.faynberg@alcatel-lucent.c= om<mailto:igor.f= aynberg@alcatel-lucent.com>> wrote:
>
> Mike,
>
> You've got the problem statement r= ight: allowing the user to authorize
> resource access to another par= ty without divulging user's credentials is
> the objective of OAu= th. You are also right in that the attack you have
> described defies the whole purpose of OAuth. I do not think though th= at
> it is related to OAuth per se.
>
> To this end, the= security work led by Torsten has thoroughly analyzed
> the protocol = and specified protection against multiple protocol
> attacks. From what you described, it appears to me that the attack yo= u
> mention is not related to the protocol but rather to the user'= ;s
> environment. There is no possible protection from key loggers t= hat a
> protocol can implement. I could be mistaken; in any case, it looks lik= e
> the problem rests with the implementation of WebView.
> > If I am wrong, I would appreciate a detailed description of what happ= ened.
>
> Igor
>
> On 9/6/2011 1:40 PM, Michael Thomas wro= te:
> Hi all,
>
> Barry suggested that I might subscribe= and explain what I sent him.
>
> My basic problem is that in = neither the protocol nor the threats drafts,
> I can't seem to find what problem is actually trying to be solved = with
> oauth, and what assumptions you're making about various el= ements.
>
> Here's what I did. I've written an app, an= d I wanted re-integrate the
> ability to send tweets after they deprecated Basic. So the app has a> webView (android, iphone...) which it obviously completely controls.=
> With oauth, the webview UA will ultimately redirect off to Twitter= 's
> site to collect the user's credentials and grant my app's back= end an
> access token (sorry if I get terminology screwed up, i'm= just coming
> up to speed).
>
> What occurs to me is th= at webview affords exactly zero protection from
> my client (ie, the app) from getting the user's twitter credential= s. All
> I have to do is set up a keypress handler on that webview an= d in a few
> minutes of hacking I have a key logger. etc.
> > So what I can't tell is whether this is a "problem" or n= ot, because I
> don't know what problem you're trying to solv= e. If the object of oauth
> isn't to keep user/server credentials= out of the hands of a third party,
> then what is it trying to solve? Is there an expectation that the
&= gt; UA is trusted by the user/server? What happens when that's not the = case?
>
> Regardless of whether I'm misunderstanding, it w= ould sure be nice to have
> both the problem and your assumptions laid out, hopefully with some> prominence
> so you don't get these sort of dumb questions.=
>
> Mike
> ____________________________________________= ___
> OAuth mailing list
> OAuth@iet= f.org<mailto:OAuth@ietf.org>= ;
> https://w= ww.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing = list
> OAuth@ietf.org<mailto= :OAuth@ietf.org>
> https://www.ietf.org/mailm= an/listinfo/oauth
> _______________________________________________
> OAuth mailing = list
> OAuth@ietf.org<mailto= :OAuth@ietf.org>
> https://www.ietf.org/mailm= an/listinfo/oauth
>
>
--0016e6505810306ac204ac4aadb7-- From melinda.shore@gmail.com Tue Sep 6 12:16: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 785FF21F8D0A for ; Tue, 6 Sep 2011 12:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 GSY1RPurQP8A for ; Tue, 6 Sep 2011 12:16:26 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id ABD4E21F8DC9 for ; Tue, 6 Sep 2011 12:16:24 -0700 (PDT) Received: by pzk33 with SMTP id 33so16936472pzk.18 for ; Tue, 06 Sep 2011 12:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+qrFwMuzwnSPJ96MIzfUlppwgIK+VnLmdG7bbVFxIHU=; b=fAyi32jBRB+GcSCZzho0rUKdbk6OWu9pPiPMyErZW5zcPvE6fxOFw6xyzsvV6zqId+ iCvkoeCqXav7bkJFA0ZIfhmzb+lHWQ1iBobj36BJvcl9i4h+spo4K9G0qQghjtHUxjGx KsjM3tqaB3uP8LILJGMfq3AaR80gGEVR3wAPY= Received: by 10.68.56.5 with SMTP id w5mr4224784pbp.388.1315336691956; Tue, 06 Sep 2011 12:18:11 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu. [137.229.12.236]) by mx.google.com with ESMTPS id m1sm2100218pbf.3.2011.09.06.12.18.09 (version=SSLv3 cipher=OTHER); Tue, 06 Sep 2011 12:18:10 -0700 (PDT) Message-ID: <4E6671FA.3090503@gmail.com> Date: Tue, 06 Sep 2011 11:18:18 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: oauth@ietf.org References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:16:26 -0000 On 09/06/2011 11:11 AM, Jill Burrows wrote: > I repeat, it is not an OAuth problem. If I'm reading Mike correctly (and if I'm not it won't be the first time I've misunderstood him), he's not really asking for OAUTH to solve this particular problem but to clarify the documents and beef up discussions of what is and is not in scope. He read the document and couldn't figure out whether or not this particular problem is the business of the working group. Melinda From mike@mtcc.com Tue Sep 6 12:20: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 7559F21F8DDE for ; Tue, 6 Sep 2011 12:20:36 -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 sd7Bl3lS+QbW for ; Tue, 6 Sep 2011 12:20:35 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1586821F8D57 for ; Tue, 6 Sep 2011 12:20:35 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86JMJCr021176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 12:22:20 -0700 Message-ID: <4E6672E7.6040305@mtcc.com> Date: Tue, 06 Sep 2011 12:22:15 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10702; t=1315336941; x=1316200941; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3Dwindows-1252=3B= 20format=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=ud+uVIf3ScgIHebyQ/e2vlwkuAkwKihdU0Yx6IcmEm0=; b=XAIdd+RABt2Lv2//jeZk3Ox1zpnegYa+7i7PI2PwhGZv6qhBIc8z5QupLz jLQc2MyAlvl0V+91tmlZxRmer5bxu9oeStSJMxwF1CBT30Vpsxpgse6e6HBe bsdJfFC2J5LWb+YpsCFVzhHfmSv2QGWWTX9hyh26vXyBLOwgFO0/Q=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:20:36 -0000 Eran Hammer-Lahav wrote: > You are one making the argument that no one should be installing apps. > > There is no known way to stop users from installing malware and viruses > other than not letting them install anything off a whitelist. The > problem you are describing has nothing to do with OAuth, its a > fundamental problem with running untrusted code on your devices. Once > you do that, yes, OAuth can be exploited but that's true for every > authentication scheme when one side is compromised. > > My point, which you seems to miss, is that the same argument can be made > against any other protocol. TLS offers your certain protections but they > are all gone if you install a bad native app – following your logic > people should not use TLS in apps either. I haven't missed the issue. OAuth is fundamentally trying to make an assertion that it protects you from third party snooping. Except that it doesn't in some large use cases. As far as I can tell that's not documented anywhere. How many oauth server-owners know that their users have this vulnerability? > I do not consider this an issue. That's the real problem here. Mike > > EHL > > From: Michael Thomas > > Date: Tue, 6 Sep 2011 11:58:11 -0700 > To: Eran Hammer-lahav > > Cc: "igor.faynberg@alcatel-lucent.com > " > >, "oauth@ietf.org > " > > Subject: Re: [OAUTH-WG] problem statement > > Eran Hammer-Lahav wrote: > > I'm dismissive of this being an OAuth problem. > > > Which brings us back to my original problem: what is the problem > it's trying to solve? > What are the assumptions it makes? What is its applicability? None > of those are addressed > very well if at all in the drafts. I'm sure that I'm not the only > one who would be very > surprised to hear that using oauth on a phone app is a bad idea. > > Put it this way: your favorite example of a photo printing service > needing access to flickr. > It's ok if you do that from a browser, but not if the photo printer > makes an app. How many users, > exactly, are going to know that they shouldn't do the second one? > > I think that's an oauth problem because oauth makes it *seem* like > you're protected from > the third party, whereas if the app itself asked for your login > credentials there would > be far less confusion. So in that sense, oauth is making things > worse, not better. > > Mike > > EHL > On Sep 6, 2011, at 11:35, "Michael Thomas" > wrote: > > Eran Hammer-Lahav wrote: > > Don't install crap on you device or computer. OAuth is > the least of your concern if you install bad software. > > If there was a solution to this we would not need an > antivirus. > > How exactly does an end user know what is "crap" or not? Or > are you just dismissive of apps in > general? I don't think that apple and google are going to > close up shop because it breaks oauth's > trust model. > > Mike > > EHL > > On Sep 6, 2011, at 11:23, "Michael Thomas" > > wrote: > > Eran Hammer-Lahav wrote: > > I agree. If you are going to install a native > app, you better trust it not to do bad things. > Grabbing your password is the least interesting > thing such an app can abuse. I don't see any > need to change the v2 draft. > > How, exactly, is the user supposed to protect > themselves against rogue apps? > It sounds like the solution is to tell them to never > use oauth in an app at all. > > Is oauth only intended to be used on standalone > trustable web browsers? I don't recall > seeing that anywhere. > > Mike > > EHL > > On Sep 6, 2011, at 11:10, "Igor Faynberg" > > wrote: > > Mike, > > You've got the problem statement right: > allowing the user to authorize > resource access to another party without > divulging user's credentials is > the objective of OAuth. You are also right > in that the attack you have > described defies the whole purpose of > OAuth. I do not think though that > it is related to OAuth per se. > > To this end, the security work led by > Torsten has thoroughly analyzed > the protocol and specified protection > against multiple protocol > attacks. From what you described, it > appears to me that the attack you > mention is not related to the protocol but > rather to the user's > environment. There is no possible > protection from key loggers that a > protocol can implement. I could be mistaken; > in any case, it looks like > the problem rests with the implementation of > WebView. > > If I am wrong, I would appreciate a detailed > description of what happened. > > Igor > > On 9/6/2011 1:40 PM, Michael Thomas wrote: > > Hi all, > > Barry suggested that I might subscribe > and explain what I sent him. > > My basic problem is that in neither the > protocol nor the threats drafts, > I can't seem to find what problem is > actually trying to be solved with > oauth, and what assumptions you're > making about various elements. > > Here's what I did. I've written an app, > and I wanted re-integrate the > ability to send tweets after they > deprecated Basic. So the app has a > webView (android, iphone...) which it > obviously completely controls. > With oauth, the webview UA will > ultimately redirect off to Twitter's > site to collect the user's credentials > and grant my app's backend an > access token (sorry if I get terminology > screwed up, i'm just coming > up to speed). > > What occurs to me is that webview > affords exactly zero protection from > my client (ie, the app) from getting the > user's twitter credentials. All > I have to do is set up a keypress > handler on that webview and in a few > minutes of hacking I have a key logger. etc. > > So what I can't tell is whether this is > a "problem" or not, because I > don't know what problem you're trying to > solve. If the object of oauth > isn't to keep user/server credentials > out of the hands of a third party, > then what is it trying to solve? Is > there an expectation that the > UA is trusted by the user/server? What > happens when that's not the case? > > Regardless of whether I'm > misunderstanding, it would sure be nice > to have > both the problem and your assumptions > laid out, hopefully with some > prominence > so you don't get these sort of dumb > questions. > > Mike > _______________________________________________ > 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 Sep 6 12:21: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 8F77421F8D56 for ; Tue, 6 Sep 2011 12:21:11 -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 8QlfwIPK1o7O for ; Tue, 6 Sep 2011 12:21:11 -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 0E38921F8CB2 for ; Tue, 6 Sep 2011 12:21:11 -0700 (PDT) Received: (qmail 11316 invoked from network); 6 Sep 2011 19:22:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Sep 2011 19:22:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Sep 2011 12:22:26 -0700 From: Eran Hammer-Lahav To: Melinda Shore , "oauth@ietf.org" Date: Tue, 6 Sep 2011 12:22:17 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: Acxsyk7/FEL+4oukQhq3IUfgvJyIkQ== Message-ID: In-Reply-To: <4E6671FA.3090503@gmail.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_CA8BC07419447eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:21:11 -0000 --_000_CA8BC07419447eranhueniversecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understood his request and disagree that any action needs to be taken. It= is unreasonable to expect every protocol to discuss the security considera= tions of a user installing malware. EHL From: Melinda Shore > Date: Tue, 6 Sep 2011 12:18:18 -0700 To: "oauth@ietf.org" > Subject: Re: [OAUTH-WG] problem statement On 09/06/2011 11:11 AM, Jill Burrows wrote: I repeat, it is not an OAuth problem. If I'm reading Mike correctly (and if I'm not it won't be the first time I've misunderstood him), he's not really asking for OAUTH to solve this particular problem but to clarify the documents and beef up discussions of what is and is not in scope. He read the document and couldn't figure out whether or not this particular problem is the business of the working group. Melinda _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_CA8BC07419447eranhueniversecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I understood his request= and disagree that any action needs to be taken. It is unreasonable to expe= ct every protocol to discuss the security considerations of a user installi= ng malware.

EHL

From: Melinda Shore <melinda.shore@gmail.com>
Date: Tue, 6 Sep 2011 12:18:18 -0700
To: "oauth= @ietf.org" <oauth@ietf.org>=
Subject: Re: [OAUTH-WG] proble= m statement

On 09/06/2011 11:11 AM, Jill Burrows wrote:
I repeat, it is= not an OAuth problem.

If I'm reading= Mike correctly (and if I'm not it won't be the
first time I've m= isunderstood him), he's not really asking for
OAUTH to solve this= particular problem but to clarify the
documents and beef up disc= ussions of what is and is not in
scope.  He read the do= cument and couldn't figure out whether
or not this particular pro= blem is the business of the working
group.

Melinda
_______________________________________________
<= div>OAuth mailing list

 --_000_CA8BC07419447eranhueniversecom_-- From mike@mtcc.com Tue Sep 6 12:27: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 0550421F8D8C for ; Tue, 6 Sep 2011 12:27:02 -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 YixSX0DQOoe8 for ; Tue, 6 Sep 2011 12:27:01 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 62A1F21F8D41 for ; Tue, 6 Sep 2011 12:27:01 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86JSkIj023395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 12:28:47 -0700 Message-ID: <4E667469.2040007@mtcc.com> Date: Tue, 06 Sep 2011 12:28:41 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Melinda Shore References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> In-Reply-To: <4E6671FA.3090503@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1043; t=1315337327; x=1316201327; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Melinda=20Shore=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=0xgMmTAHfxpn6OPKpvgX8hCfb9JkC9Q0RryiIGyrMug=; b=eoe8wr56l+gELMwytiB+Ee3JEjVtrIfnSbN40cgiTQHRjlFOJpO/vLdNAe qqEzHeXdrqra1ZzmNcJ8V0KfEQrji3dMfSVYhrUkhqyEjS6OuE0G6MJSM2Fs ZTGCYdhJreEgViyEUXoKkz/14B/WM/wUWJJQhBf412n36OZDgOkis=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:27:02 -0000 Melinda Shore wrote: > On 09/06/2011 11:11 AM, Jill Burrows wrote: >> I repeat, it is not an OAuth problem. > > If I'm reading Mike correctly (and if I'm not it won't be the > first time I've misunderstood him), he's not really asking for > OAUTH to solve this particular problem but to clarify the > documents and beef up discussions of what is and is not in > scope. He read the document and couldn't figure out whether > or not this particular problem is the business of the working > group. I'm fairly certain that if somebody were deploying oauth for their servers that unless the document told me that oauth doesn't provide protection against third party snooping if it's embedded in any app, most people wouldn't have a clue that that was a dangerous assumption. What this says is that oauth only works in one use case, and that only the user can tell the difference. Given the proliferation of phone apps and embedded webviews, it seems that the original assumptions of oauth are no longer up to date. Mike From aiden449@gmail.com Tue Sep 6 12:34: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 8267A21F8E21 for ; Tue, 6 Sep 2011 12:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.246 X-Spam-Level: X-Spam-Status: No, score=-3.246 tagged_above=-999 required=5 tests=[AWL=0.352, 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 LVox2cMeDROt for ; Tue, 6 Sep 2011 12:34:39 -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 B013C21F8E17 for ; Tue, 6 Sep 2011 12:34:39 -0700 (PDT) Received: by qyk35 with SMTP id 35so4088151qyk.10 for ; Tue, 06 Sep 2011 12:36:26 -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 :content-type; bh=MtaqTzgu+aL/6K5HtULKWUpEtzPGcbtsm2lIDucayYw=; b=akHcnQx/MH0lUnxdR7emaEhuRAj/FMRzIxOsQA/mQccGMp/wkoKJzbc0wdVSnfM7uT ImqjlrJE2+lIHrwqOuEHdmQybXjTJIBFCYUmgJt80GYW9+JZ1xCvC2E+ZcBM1unwErx1 zFvWD+aHOH78MpApZucE5bNUU0cXMmD0byKsI= MIME-Version: 1.0 Received: by 10.229.71.161 with SMTP id h33mr4091706qcj.276.1315337786722; Tue, 06 Sep 2011 12:36:26 -0700 (PDT) Received: by 10.229.249.71 with HTTP; Tue, 6 Sep 2011 12:36:26 -0700 (PDT) Received: by 10.229.249.71 with HTTP; Tue, 6 Sep 2011 12:36:26 -0700 (PDT) In-Reply-To: <4E667469.2040007@mtcc.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> Date: Tue, 6 Sep 2011 20:36:26 +0100 Message-ID: From: Aiden Bell To: Michael Thomas , OAuth WG Content-Type: multipart/alternative; boundary=0016e6505810898b5104ac4af1ba Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:34:40 -0000 --0016e6505810898b5104ac4af1ba Content-Type: text/plain; charset=ISO-8859-1 I'm pretty sure anyone charged with implementing the oauth protocol should be able to make a fairly informed judgement about what oauth does and doesn't do and the implications of that scope. Like all security, it is about layers ... And oauth isn't all layers. That's obvious. I don't think writing about that helps the spec too much, past saying "oauth isn't a one stop shop for end to end security" sent from my android phone On Sep 6, 2011 8:28 PM, "Michael Thomas" wrote: > Melinda Shore wrote: >> On 09/06/2011 11:11 AM, Jill Burrows wrote: >>> I repeat, it is not an OAuth problem. >> >> If I'm reading Mike correctly (and if I'm not it won't be the >> first time I've misunderstood him), he's not really asking for >> OAUTH to solve this particular problem but to clarify the >> documents and beef up discussions of what is and is not in >> scope. He read the document and couldn't figure out whether >> or not this particular problem is the business of the working >> group. > > I'm fairly certain that if somebody were deploying oauth for their servers > that unless the document told me that oauth doesn't provide protection > against third party snooping if it's embedded in any app, most people wouldn't > have a clue that that was a dangerous assumption. > > What this says is that oauth only works in one use case, and that only the > user can tell the difference. Given the proliferation of phone apps and > embedded webviews, it seems that the original assumptions of oauth are > no longer up to date. > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --0016e6505810898b5104ac4af1ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


I'm pretty sure anyone charged with implementing the oauth protocol sho= uld be able to make a fairly informed judgement about what oauth does and d= oesn't do and the implications of that scope. Like all security, it is = about layers ... And oauth isn't all layers. That's obvious.

I don't think writing about that helps the spec too much, past sayin= g "oauth isn't a one stop shop for end to end security"

sent from my android phone

On Sep 6, 2011 8:28 PM, "Michael Thomas&quo= t; <mike@mtcc.com> wrote:
> Melinda Shore wrote:
>> On 09/06/2011 11:11= AM, Jill Burrows wrote:
>>> I repeat, it is not an OAuth problem.
>>
>>= If I'm reading Mike correctly (and if I'm not it won't be the<= br>>> first time I've misunderstood him), he's not really ask= ing for
>> OAUTH to solve this particular problem but to clarify the
>&= gt; documents and beef up discussions of what is and is not in
>> = scope. He read the document and couldn't figure out whether
>>= ; or not this particular problem is the business of the working
>> group.
>
> I'm fairly certain that if somebody we= re deploying oauth for their servers
> that unless the document told = me that oauth doesn't provide protection
> against third party sn= ooping if it's embedded in any app, most people wouldn't
> have a clue that that was a dangerous assumption.
>
> Wha= t this says is that oauth only works in one use case, and that only the
= > user can tell the difference. Given the proliferation of phone apps an= d
> embedded webviews, it seems that the original assumptions of oauth are=
> no longer up to date.
>
> Mike
> ______________= _________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth
--0016e6505810898b5104ac4af1ba-- From mike@mtcc.com Tue Sep 6 12:34: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 4293F21F8E29 for ; Tue, 6 Sep 2011 12:34: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=[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 Hv2KvkS-4VT8 for ; Tue, 6 Sep 2011 12:34:40 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 8B72E21F8E17 for ; Tue, 6 Sep 2011 12:34:40 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86JaOSQ026011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 12:36:25 -0700 Message-ID: <4E667635.8090806@mtcc.com> Date: Tue, 06 Sep 2011 12:36:21 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1796; t=1315337786; x=1316201786; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=cVVh+91HC8pdPVJQP3Ui4ufHOuQ95jsF0ERb322p16w=; b=GCiRyj2j5BQrTS4eiPk0hJNciTCM5iRaK2JBq7J0YULO4mOCBtLyIitHfv 51dDoT3QF6svNstAwFZsvuAEq+ajxIYX1Nu8gGm3EsjUC/oPdjyuZZkZ5Ye2 xhQT+gyZAfa4XLGxU4kTvscGWtSYBVoTla8SWbgLeDM6OOkZ9+r7w=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:34:41 -0000 Eran Hammer-Lahav wrote: > I understood his request and disagree that any action needs to be taken. > It is unreasonable to expect every protocol to discuss the security > considerations of a user installing malware. If you could find an equivalent attack on, oh say, DKIM, I'd say yes you should discuss it. OAuth is a user-facing protocol. That means that users will be using it. It absolutely guarantees you that hackers will hack it. In the case of embedded webviews, oauth makes the malware situation worse from what I can tell. Mike > > EHL > > From: Melinda Shore > > Date: Tue, 6 Sep 2011 12:18:18 -0700 > To: "oauth@ietf.org " > > Subject: Re: [OAUTH-WG] problem statement > > On 09/06/2011 11:11 AM, Jill Burrows wrote: > > I repeat, it is not an OAuth problem. > > > If I'm reading Mike correctly (and if I'm not it won't be the > first time I've misunderstood him), he's not really asking for > OAUTH to solve this particular problem but to clarify the > documents and beef up discussions of what is and is not in > scope. He read the document and couldn't figure out whether > or not this particular problem is the business of the working > group. > > Melinda > _______________________________________________ > 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 Tue Sep 6 12:36: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 9B64E21F8C98 for ; Tue, 6 Sep 2011 12:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 bpZqQs+GzuYv for ; Tue, 6 Sep 2011 12:36:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D3FA121F84DB for ; Tue, 6 Sep 2011 12:36:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7814721B16B1; Tue, 6 Sep 2011 15:37:52 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7168F21B1565; Tue, 6 Sep 2011 15:37:52 -0400 (EDT) Received: from [129.83.50.1] (129.83.31.55) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.270.1; Tue, 6 Sep 2011 15:37:51 -0400 From: Justin Richer To: Michael Thomas In-Reply-To: <4E667469.2040007@mtcc.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 6 Sep 2011 15:36:49 -0400 Message-ID: <1315337809.3136.38.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:36:12 -0000 Mike, I think this is a red herring. as this vector has nothing to do with mobile apps. The attack that you've suggested is also possible with a compromised browser on a desktop using the web flow. In this case, the browser (UA) can steal the user's credentials and hand them to whoever they want to when the user gets redirected. It doesn't have to be the OAuth client that's phishing the credentials, after all. OAuth *does* work with phone apps, and it's a misnomer to say that it's not a good idea in such environments. In all cases, you have to trust the user agent and all of the mechanisms that let the user log into the host site. But you have to do that in order to let the user log into the host site at all. Fixing that is a larger problem for the web as a whole and ultimately outside of OAuth. -- Justin On Tue, 2011-09-06 at 15:28 -0400, Michael Thomas wrote: > Melinda Shore wrote: > > On 09/06/2011 11:11 AM, Jill Burrows wrote: > >> I repeat, it is not an OAuth problem. > > > > If I'm reading Mike correctly (and if I'm not it won't be the > > first time I've misunderstood him), he's not really asking for > > OAUTH to solve this particular problem but to clarify the > > documents and beef up discussions of what is and is not in > > scope. He read the document and couldn't figure out whether > > or not this particular problem is the business of the working > > group. > > I'm fairly certain that if somebody were deploying oauth for their servers > that unless the document told me that oauth doesn't provide protection > against third party snooping if it's embedded in any app, most people wouldn't > have a clue that that was a dangerous assumption. > > What this says is that oauth only works in one use case, and that only the > user can tell the difference. Given the proliferation of phone apps and > embedded webviews, it seems that the original assumptions of oauth are > no longer up to date. > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Tue Sep 6 12:38: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 3B01F21F8E32 for ; Tue, 6 Sep 2011 12:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 kA2hJbnnQcnn for ; Tue, 6 Sep 2011 12:38:36 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7B50121F8E22 for ; Tue, 6 Sep 2011 12:38:36 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p86JeMLn027915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 14:40:22 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p86JeMSM031007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Sep 2011 14:40:22 -0500 Received: from [135.244.40.187] (faynberg.lra.lucent.com [135.244.40.187]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p86JeLFV003400; Tue, 6 Sep 2011 14:40:21 -0500 (CDT) Message-ID: <4E667725.20205@alcatel-lucent.com> Date: Tue, 06 Sep 2011 15:40:21 -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: Michael Thomas References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> In-Reply-To: <4E666512.7010701@mtcc.com> 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.10 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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: Tue, 06 Sep 2011 19:38:37 -0000 On 9/6/2011 2:23 PM, Michael Thomas wrote: > ... > How, exactly, is the user supposed to protect themselves against rogue > apps? > ... There are a number of ways: 1) Buy shrink-wrapped software only, 2) Inspect the source code of every application, etc... The mobile network providers solve this problem by allowing ONLY applications signed with a special key to run. > > Is oauth only intended to be used on standalone trustable web > browsers? I don't recall > seeing that anywhere. When it comes to browsers, yes the user is supposed to trust them. But OAuth is expected to work with the native applications, too (you may find several interesting threads in the archive on that). In both cases, ensuring that the application is not evil is a basic administrative problem. It is not an OAuth problem for two reasons: 1) Whatever would make OAuth fail here will make any other protocol fail; 2) Neither OAuth nor any other protocol can deal with key logging. Igor From igor.faynberg@alcatel-lucent.com Tue Sep 6 12:45: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 6A15521F8E3D for ; Tue, 6 Sep 2011 12:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.604 X-Spam-Level: X-Spam-Status: No, score=-6.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 wNRQA-EGx8Xk for ; Tue, 6 Sep 2011 12:45:28 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8B90E21F8E22 for ; Tue, 6 Sep 2011 12:45:28 -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 p86JlE0r008841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Sep 2011 14:47:15 -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 p86JlEA3020780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Sep 2011 14:47:14 -0500 Received: from [135.244.40.187] (faynberg.lra.lucent.com [135.244.40.187]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p86JlEPY009625; Tue, 6 Sep 2011 14:47:14 -0500 (CDT) Message-ID: <4E6678C1.4070702@alcatel-lucent.com> Date: Tue, 06 Sep 2011 15:47:13 -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: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> In-Reply-To: <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] problem statement 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: Tue, 06 Sep 2011 19:45:29 -0000 Q.E.D. Igor On 9/6/2011 2:57 PM, Eran Hammer-Lahav wrote: > Framing this as an OAuth issue is wrong. In your scenario: > > 1. Install bad app > 2. Do protocol X > 3. Bad things happen > > X can be anything. For example, the app can add a root cert to your os and break TLS protection. > > EHL > > On Sep 6, 2011, at 11:50, "Michael Thomas" wrote: > >> William Mills wrote: >>> OAuth doesn't solve this problem, and can't. Generally the question is >>> whether the app appears to come from a reputable source, and nowadays >>> whether it's signed (in windows land) or otherwize certified by the >>> provider. >>> >>> If you manage to solve this problem in a real way I'd be interested in >>> investing in your company. >> Then what I don't see anywhere is that oauth is not applicable to embedded >> web objects, and that end users should *never* trust oauth in a, say, phone >> app. As far as I can tell, the server deploying oauth can't tell that it's >> being misused, so this is all on the shoulders of the end user. >> >> It sure looks like oauth is easily subverted in the real world. >> >> Mike >> >>> ------------------------------------------------------------------------ >>> *From:* Michael Thomas >>> *To:* Eran Hammer-Lahav >>> *Cc:* "oauth@ietf.org" >>> *Sent:* Tuesday, September 6, 2011 11:34 AM >>> *Subject:* Re: [OAUTH-WG] problem statement >>> >>> Eran Hammer-Lahav wrote: >>>> Don't install crap on you device or computer. OAuth is the least of >>> your concern if you install bad software. >>>> If there was a solution to this we would not need an antivirus. >>> How exactly does an end user know what is "crap" or not? Or are you just >>> dismissive of apps in >>> general? I don't think that apple and google are going to close up shop >>> because it breaks oauth's >>> trust model. >>> >>> Mike >>> >>>> EHL >>>> On Sep 6, 2011, at 11:23, "Michael Thomas">> > wrote: >>>>> Eran Hammer-Lahav wrote: >>>>>> I agree. If you are going to install a native app, you better trust >>> it not to do bad things. Grabbing your password is the least interesting >>> thing such an app can abuse. I don't see any need to change the v2 draft. >>>>> How, exactly, is the user supposed to protect themselves against >>> rogue apps? >>>>> It sounds like the solution is to tell them to never use oauth in an >>> app at all. >>>>> Is oauth only intended to be used on standalone trustable web >>> browsers? I don't recall >>>>> seeing that anywhere. >>>>> >>>>> Mike >>>>> >>>>>> EHL >>>>>> >>>>>> On Sep 6, 2011, at 11:10, "Igor Faynberg" >>> >> > wrote: >>>>>>> Mike, >>>>>>> >>>>>>> You've got the problem statement right: allowing the user to >>> authorize resource access to another party without divulging user's >>> credentials is the objective of OAuth. You are also right in that the >>> attack you have described defies the whole purpose of OAuth. I do not >>> think though that it is related to OAuth per se. >>>>>>> To this end, the security work led by Torsten has thoroughly >>> analyzed the protocol and specified protection against multiple protocol >>> attacks. From what you described, it appears to me that the attack you >>> mention is not related to the protocol but rather to the user's >>> environment. There is no possible protection from key loggers that a >>> protocol can implement. I could be mistaken; in any case, it looks like >>> the problem rests with the implementation of WebView. >>>>>>> If I am wrong, I would appreciate a detailed description of what >>> happened. >>>>>>> Igor >>>>>>> >>>>>>> On 9/6/2011 1:40 PM, Michael Thomas wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Barry suggested that I might subscribe and explain what I sent him. >>>>>>>> >>>>>>>> My basic problem is that in neither the protocol nor the threats >>> drafts, >>>>>>>> I can't seem to find what problem is actually trying to be solved >>> with >>>>>>>> oauth, and what assumptions you're making about various elements. >>>>>>>> >>>>>>>> Here's what I did. I've written an app, and I wanted re-integrate the >>>>>>>> ability to send tweets after they deprecated Basic. So the app has a >>>>>>>> webView (android, iphone...) which it obviously completely controls. >>>>>>>> With oauth, the webview UA will ultimately redirect off to Twitter's >>>>>>>> site to collect the user's credentials and grant my app's backend an >>>>>>>> access token (sorry if I get terminology screwed up, i'm just coming >>>>>>>> up to speed). >>>>>>>> >>>>>>>> What occurs to me is that webview affords exactly zero protection >>> from >>>>>>>> my client (ie, the app) from getting the user's twitter >>> credentials. All >>>>>>>> I have to do is set up a keypress handler on that webview and in >>> a few >>>>>>>> minutes of hacking I have a key logger. etc. >>>>>>>> >>>>>>>> So what I can't tell is whether this is a "problem" or not, because I >>>>>>>> don't know what problem you're trying to solve. If the object of >>> oauth >>>>>>>> isn't to keep user/server credentials out of the hands of a third >>> party, >>>>>>>> then what is it trying to solve? Is there an expectation that the >>>>>>>> UA is trusted by the user/server? What happens when that's not >>> the case? >>>>>>>> Regardless of whether I'm misunderstanding, it would sure be nice >>> to have >>>>>>>> both the problem and your assumptions laid out, hopefully with >>> some prominence >>>>>>>> so you don't get these sort of dumb questions. >>>>>>>> >>>>>>>> Mike >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> >>> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mike@mtcc.com Tue Sep 6 12:48: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 9BD6D21F8E14 for ; Tue, 6 Sep 2011 12:48:00 -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 XTIvS+-GqpMM for ; Tue, 6 Sep 2011 12:47:59 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id D183A21F8E07 for ; Tue, 6 Sep 2011 12:47:59 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86JnhM4030560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 12:49:44 -0700 Message-ID: <4E667953.9020906@mtcc.com> Date: Tue, 06 Sep 2011 12:49:39 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Justin Richer References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> In-Reply-To: <1315337809.3136.38.camel@ground> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3295; t=1315338585; x=1316202585; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Justin=20Richer=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ms9WbjGyWGpKDZza/gAM0W1kVIC3HWS5kQmoWhGbr2Y=; b=QLlvOW/J/+TY0NkVKc1iOilhnxcErkS8JeF5E4KiwE5X7Vg2LVd2QJ2S1P Kz+lm2FxtKVtEh2MQReBT7mNzyg2v7LyDuQQ4z8VG1VJKXxwVV3poO/JDBzr XJ4Kiem0/wSi7j7iuBCfEOQpM56ug0njhDhfiRLPDa3xA9jojY/OI=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:48:00 -0000 Justin Richer wrote: > Mike, > > I think this is a red herring. as this vector has nothing to do with > mobile apps. The attack that you've suggested is also possible with a > compromised browser on a desktop using the web flow. In this case, the > browser (UA) can steal the user's credentials and hand them to whoever > they want to when the user gets redirected. It doesn't have to be the > OAuth client that's phishing the credentials, after all. Absolutely. I only brought it up because that is what I was working on. > OAuth *does* work with phone apps, and it's a misnomer to say that it's > not a good idea in such environments. In all cases, you have to trust > the user agent and all of the mechanisms that let the user log into the > host site. But you have to do that in order to let the user log into the > host site at all. Fixing that is a larger problem for the web as a whole > and ultimately outside of OAuth. Except in the desktop web world, I choose from a *tiny* set of browsers: chrome, firefox, opera, and, uh, ie. To a lesser or greater extent, I don't expect that the browsers themselves are malicious. Which is a pretty ok assumption. With embedded web views, that assumption goes out the window. There are 100's of thousands of apps, all of which can use webviews. I have no way to know if a given app is evil or not, and *lots* of apps provide facebook and twitter integration. Not because they're evil, but because that's what's expected by users. So the use model of oauth in this case is *very* different than the desktop use case. But I'm being told that use cases aren't the problem of oauth. I'd say that there has all along been a hidden assumption that the browser was a trusted entity. Since it isn't always, it should be very explicit in the protocol, threats, and security considerations of what could happen if it's not. Mike, frankly this is why apps do suck but i'm not king of the world > > -- Justin > > On Tue, 2011-09-06 at 15:28 -0400, Michael Thomas wrote: >> Melinda Shore wrote: >>> On 09/06/2011 11:11 AM, Jill Burrows wrote: >>>> I repeat, it is not an OAuth problem. >>> If I'm reading Mike correctly (and if I'm not it won't be the >>> first time I've misunderstood him), he's not really asking for >>> OAUTH to solve this particular problem but to clarify the >>> documents and beef up discussions of what is and is not in >>> scope. He read the document and couldn't figure out whether >>> or not this particular problem is the business of the working >>> group. >> I'm fairly certain that if somebody were deploying oauth for their servers >> that unless the document told me that oauth doesn't provide protection >> against third party snooping if it's embedded in any app, most people wouldn't >> have a clue that that was a dangerous assumption. >> >> What this says is that oauth only works in one use case, and that only the >> user can tell the difference. Given the proliferation of phone apps and >> embedded webviews, it seems that the original assumptions of oauth are >> no longer up to date. >> >> Mike >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From igor.faynberg@alcatel-lucent.com Tue Sep 6 12:52: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 4D5B521F8E4B for ; Tue, 6 Sep 2011 12:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.604 X-Spam-Level: X-Spam-Status: No, score=-6.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 ZWWaH33WCSal for ; Tue, 6 Sep 2011 12:52:31 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BC6A421F8E3B for ; Tue, 6 Sep 2011 12:52:31 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p86JsGb0011478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Sep 2011 14:54:16 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p86JsGsJ002202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Sep 2011 14:54:16 -0500 Received: from [135.244.40.187] (faynberg.lra.lucent.com [135.244.40.187]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p86JsF1Z015333; Tue, 6 Sep 2011 14:54:15 -0500 (CDT) Message-ID: <4E667A67.5050305@alcatel-lucent.com> Date: Tue, 06 Sep 2011 15:54:15 -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: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> In-Reply-To: <1315337809.3136.38.camel@ground> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [OAUTH-WG] problem statement 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: Tue, 06 Sep 2011 19:52:32 -0000 On 9/6/2011 3:36 PM, Justin Richer wrote: > ... > > OAuth *does* work with phone apps, and it's a misnomer to say that it's > not a good idea in such environments. > To support and amplify Justin's point, OAuth has been adopted by OMA and WAC, and ITU-T is developing an OAuth profile. Mobile providers reported OAuth implementation on this list. Igor From john@jkemp.net Tue Sep 6 12:56: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 928A921F8D73 for ; Tue, 6 Sep 2011 12:56:21 -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 ANAuqVBnAEgz for ; Tue, 6 Sep 2011 12:56:20 -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 D2B8221F8D67 for ; Tue, 6 Sep 2011 12:56:20 -0700 (PDT) Received: (qmail 8800 invoked by uid 0); 6 Sep 2011 19:58:08 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by oproxy1.bluehost.com with SMTP; 6 Sep 2011 19:58:08 -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=PZRTcimX7B/SsJFepP3alXFHK1W4jNpVLO5W5t3IAsE=; b=DnFm5pV3NE8d+puMlgSkWM8RDwPY82IyxRaD3s01J+Al6ZJ9O/6UDcRM+wtKxoLJdPY1QtFAjlFNmkXUGvfvJrjhSEfSi2iXCD4PITmy6f4ki5FiNf1uPZn6ifgMwZzA; Received: from cpe-74-67-30-101.nycap.res.rr.com ([74.67.30.101] helo=[192.168.1.110]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1R11mZ-0000yQ-T0; Tue, 06 Sep 2011 13:58:08 -0600 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <4E667953.9020906@mtcc.com> Date: Tue, 6 Sep 2011 15:58:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> To: Michael Thomas 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 Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 19:56:21 -0000 On Sep 6, 2011, at 3:49 PM, Michael Thomas wrote: >=20 > Except in the desktop web world, I choose from a *tiny* set of = browsers: > chrome, firefox, opera, and, uh, ie. To a lesser or greater extent, I = don't > expect that the browsers themselves are malicious. Which is a pretty = ok > assumption. It is? I would certainly question it. The WebKit WebView is embeddable = in the C/C++ programming languages and APIs are available for that on = most platforms - all are open to the same attacks you mention. How about = the plugins you get for your browser from various places - they could = have key loggers too. It's also possible for an app delivered from a = server to present a login form that looks like it is from Twitter, but = is actually from an attacker site. Such attacks are very common indeed, = and don't require a key logger. They do require the user to "trust" the = app though, just as the user would need to trust the key logger he = installed. >=20 > With embedded web views, that assumption goes out the window. There = are > 100's of thousands of apps, all of which can use webviews. I have no = way > to know if a given app is evil or not, and *lots* of apps provide = facebook > and twitter integration. Not because they're evil, but because that's = what's > expected by users. So the use model of oauth in this case is *very* = different > than the desktop use case. I disagree. If anything, because desktop machines tend to be less = 'locked-down' than mobile platforms (app stores for desktops followed = app stores for mobile platforms), they are more widely open to abuse. >=20 > But I'm being told that use cases aren't the problem of oauth. I'd say = that > there has all along been a hidden assumption that the browser was > a trusted entity. The point is simply that if you can subvert the actual platform, then = OAuth problems are the least of your worries (as a user). - John > Since it isn't always, it should be very explicit in the > protocol, threats, and security considerations of what could happen if = it's > not. >=20 > Mike, frankly this is why apps do suck but i'm not king of the world >=20 >> -- Justin >> On Tue, 2011-09-06 at 15:28 -0400, Michael Thomas wrote: >>> Melinda Shore wrote: >>>> On 09/06/2011 11:11 AM, Jill Burrows wrote: >>>>> I repeat, it is not an OAuth problem. >>>> If I'm reading Mike correctly (and if I'm not it won't be the >>>> first time I've misunderstood him), he's not really asking for >>>> OAUTH to solve this particular problem but to clarify the >>>> documents and beef up discussions of what is and is not in >>>> scope. He read the document and couldn't figure out whether >>>> or not this particular problem is the business of the working >>>> group. >>> I'm fairly certain that if somebody were deploying oauth for their = servers >>> that unless the document told me that oauth doesn't provide = protection >>> against third party snooping if it's embedded in any app, most = people wouldn't >>> have a clue that that was a dangerous assumption. >>>=20 >>> What this says is that oauth only works in one use case, and that = only the >>> user can tell the difference. Given the proliferation of phone apps = and >>> embedded webviews, it seems that the original assumptions of oauth = are >>> no longer up to date. >>>=20 >>> Mike >>> _______________________________________________ >>> 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 From mike@mtcc.com Tue Sep 6 13:08: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 5022721F8E1A for ; Tue, 6 Sep 2011 13:08: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 mOVAtGgYauWd for ; Tue, 6 Sep 2011 13:08:40 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5A21F8E17 for ; Tue, 6 Sep 2011 13:08:40 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86KAQcp005614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 13:10:27 -0700 Message-ID: <4E667E2E.7090304@mtcc.com> Date: Tue, 06 Sep 2011 13:10:22 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: John Kemp References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> In-Reply-To: <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4448; t=1315339827; x=1316203827; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20John=20Kemp=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=JfDSc5amkTXXNWwHWoTeHhJXXWN1ApfKErpUhFPpgbQ=; b=iTk8RLgd60KJP0HtZNsoOCltoZcUCuSA3/2ntIi4R41yRIdIo17MDKcf8n wjcUtSiMy/k4zorI3+hAlckmYmms5f2A7/eTl2yli+u5At9k0aWoPYVgcpPt 8Df5E/ecciQIxJV8yxKNjgZgCxAIVQH6vdEWai7m78amHNdTSuqg4=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: OAuth WG Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 20:08:41 -0000 John Kemp wrote: > On Sep 6, 2011, at 3:49 PM, Michael Thomas wrote: >> Except in the desktop web world, I choose from a *tiny* set of browsers: >> chrome, firefox, opera, and, uh, ie. To a lesser or greater extent, I don't >> expect that the browsers themselves are malicious. Which is a pretty ok >> assumption. > > It is? I would certainly question it. The WebKit WebView is embeddable in the C/C++ programming languages and APIs are available for that on most platforms - all are open to the same attacks you mention. How about the plugins you get for your browser from various places - they could have key loggers too. It's also possible for an app delivered from a server to present a login form that looks like it is from Twitter, but is actually from an attacker site. Such attacks are very common indeed, and don't require a key logger. They do require the user to "trust" the app though, just as the user would need to trust the key logger he installed. I didn't say they weren't embeddable elsewhere. I just gave my example. And if I don't use plugins, the browser is relatively trustable, especially in comparison to standalone apps -- on desktop *or* phone, etc. >> With embedded web views, that assumption goes out the window. There are >> 100's of thousands of apps, all of which can use webviews. I have no way >> to know if a given app is evil or not, and *lots* of apps provide facebook >> and twitter integration. Not because they're evil, but because that's what's >> expected by users. So the use model of oauth in this case is *very* different >> than the desktop use case. > > I disagree. If anything, because desktop machines tend to be less 'locked-down' than mobile platforms (app stores for desktops followed app stores for mobile platforms), they are more widely open to abuse. I can tell you from experience that Android absolutely doesn't check anything of this sort, and it would take extremely deep voodoo for Apple to do the same: they never see source. So the reality is that neither are trustable. > >> But I'm being told that use cases aren't the problem of oauth. I'd say that >> there has all along been a hidden assumption that the browser was >> a trusted entity. > > The point is simply that if you can subvert the actual platform, then OAuth problems are the least of your worries (as a user). People keep saying that to deflect criticism, but I don't buy it. Other protocols aren't availing an attacker to user credentials to third party servers by simply snooping on the webview key traffic in an otherwise completely normal use pattern. Have you ever signed on to facebook in an app before? Mike > > - John > >> Since it isn't always, it should be very explicit in the >> protocol, threats, and security considerations of what could happen if it's >> not. >> >> Mike, frankly this is why apps do suck but i'm not king of the world >> >>> -- Justin >>> On Tue, 2011-09-06 at 15:28 -0400, Michael Thomas wrote: >>>> Melinda Shore wrote: >>>>> On 09/06/2011 11:11 AM, Jill Burrows wrote: >>>>>> I repeat, it is not an OAuth problem. >>>>> If I'm reading Mike correctly (and if I'm not it won't be the >>>>> first time I've misunderstood him), he's not really asking for >>>>> OAUTH to solve this particular problem but to clarify the >>>>> documents and beef up discussions of what is and is not in >>>>> scope. He read the document and couldn't figure out whether >>>>> or not this particular problem is the business of the working >>>>> group. >>>> I'm fairly certain that if somebody were deploying oauth for their servers >>>> that unless the document told me that oauth doesn't provide protection >>>> against third party snooping if it's embedded in any app, most people wouldn't >>>> have a clue that that was a dangerous assumption. >>>> >>>> What this says is that oauth only works in one use case, and that only the >>>> user can tell the difference. Given the proliferation of phone apps and >>>> embedded webviews, it seems that the original assumptions of oauth are >>>> no longer up to date. >>>> >>>> Mike >>>> _______________________________________________ >>>> 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 john@jkemp.net Tue Sep 6 13:14: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 8C18521F8E7A for ; Tue, 6 Sep 2011 13:14:19 -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 7AJpEgo0PlaE for ; Tue, 6 Sep 2011 13:14:18 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id AFE0821F8E4C for ; Tue, 6 Sep 2011 13:14:18 -0700 (PDT) Received: (qmail 562 invoked by uid 0); 6 Sep 2011 20:16:05 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by oproxy8.bluehost.com with SMTP; 6 Sep 2011 20:16:05 -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=S/KBAchkNf1NyLZEouD2upig7GQBqd206GjxgHtE5+E=; b=kDFYqEKDYc/EPw9XKyLQWYLlusebjtGMwx9WiFhqTIobLrjRiElTM+ZQJyEw4sI5KY8yl5d/8v37mTmzbdcll36PMduK0U2AKOZ6mNmxW1ax8Eg+6Y/hrIS5f9MOdSa2; Received: from cpe-74-67-30-101.nycap.res.rr.com ([74.67.30.101] helo=[192.168.1.110]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1R123x-0001gr-Dn; Tue, 06 Sep 2011 14:16:05 -0600 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: John Kemp In-Reply-To: <4E667E2E.7090304@mtcc.com> Date: Tue, 6 Sep 2011 16:16:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> To: Michael Thomas 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 Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 20:14:19 -0000 On Sep 6, 2011, at 4:10 PM, Michael Thomas wrote: > John Kemp wrote: >> On Sep 6, 2011, at 3:49 PM, Michael Thomas wrote: >>> Except in the desktop web world, I choose from a *tiny* set of = browsers: >>> chrome, firefox, opera, and, uh, ie. To a lesser or greater extent, = I don't >>> expect that the browsers themselves are malicious. Which is a pretty = ok >>> assumption. >> It is? I would certainly question it. The WebKit WebView is = embeddable in the C/C++ programming languages and APIs are available for = that on most platforms - all are open to the same attacks you mention. = How about the plugins you get for your browser from various places - = they could have key loggers too. It's also possible for an app delivered = from a server to present a login form that looks like it is from = Twitter, but is actually from an attacker site. Such attacks are very = common indeed, and don't require a key logger. They do require the user = to "trust" the app though, just as the user would need to trust the key = logger he installed. >=20 > I didn't say they weren't embeddable elsewhere. I just gave my = example. And if I don't > use plugins, the browser is relatively trustable, especially in = comparison to standalone > apps -- on desktop *or* phone, etc. Again, I disagree. As a user, I should pay attention to the sites I = visit - as much as I should pay attention to the apps I download. >=20 >=20 >>> With embedded web views, that assumption goes out the window. There = are >>> 100's of thousands of apps, all of which can use webviews. I have no = way >>> to know if a given app is evil or not, and *lots* of apps provide = facebook >>> and twitter integration. Not because they're evil, but because = that's what's >>> expected by users. So the use model of oauth in this case is *very* = different >>> than the desktop use case. >> I disagree. If anything, because desktop machines tend to be less = 'locked-down' than mobile platforms (app stores for desktops followed = app stores for mobile platforms), they are more widely open to abuse. >=20 > I can tell you from experience that Android absolutely doesn't check = anything of this > sort, and it would take extremely deep voodoo for Apple to do the = same: they never see > source. I believe that both Apple and Google *do attempt* to prevent malware = from getting into their stores.=20 =20 >=20 > So the reality is that neither are trustable. This I agree with ;) >=20 >>> But I'm being told that use cases aren't the problem of oauth. I'd = say that >>> there has all along been a hidden assumption that the browser was >>> a trusted entity. >> The point is simply that if you can subvert the actual platform, then = OAuth problems are the least of your worries (as a user). >=20 > People keep saying that to deflect criticism, but I don't buy it. = Other protocols aren't > availing an attacker to user credentials to third party servers by = simply snooping on the > webview key traffic in an otherwise completely normal use pattern. HTTP Auth? Web form login?=20 >=20 > Have you ever signed on to facebook in an app before? Frankly, not too often, no, since these apps usually ask for far more = authority than I believe is necessary for the purpose of using the app. - John >=20 > Mike >=20 >> - John >>> Since it isn't always, it should be very explicit in the >>> protocol, threats, and security considerations of what could happen = if it's >>> not. >>>=20 >>> Mike, frankly this is why apps do suck but i'm not king of the world >>>=20 >>>> -- Justin >>>> On Tue, 2011-09-06 at 15:28 -0400, Michael Thomas wrote: >>>>> Melinda Shore wrote: >>>>>> On 09/06/2011 11:11 AM, Jill Burrows wrote: >>>>>>> I repeat, it is not an OAuth problem. >>>>>> If I'm reading Mike correctly (and if I'm not it won't be the >>>>>> first time I've misunderstood him), he's not really asking for >>>>>> OAUTH to solve this particular problem but to clarify the >>>>>> documents and beef up discussions of what is and is not in >>>>>> scope. He read the document and couldn't figure out whether >>>>>> or not this particular problem is the business of the working >>>>>> group. >>>>> I'm fairly certain that if somebody were deploying oauth for their = servers >>>>> that unless the document told me that oauth doesn't provide = protection >>>>> against third party snooping if it's embedded in any app, most = people wouldn't >>>>> have a clue that that was a dangerous assumption. >>>>>=20 >>>>> What this says is that oauth only works in one use case, and that = only the >>>>> user can tell the difference. Given the proliferation of phone = apps and >>>>> embedded webviews, it seems that the original assumptions of oauth = are >>>>> no longer up to date. >>>>>=20 >>>>> Mike >>>>> _______________________________________________ >>>>> 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 From wmills@yahoo-inc.com Tue Sep 6 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 E4D4E21F8E97 for ; Tue, 6 Sep 2011 13:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.362 X-Spam-Level: X-Spam-Status: No, score=-17.362 tagged_above=-999 required=5 tests=[AWL=0.236, 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 SMA16MKqPEcz for ; Tue, 6 Sep 2011 13:34:43 -0700 (PDT) Received: from nm12-vm0.bullet.mail.ac4.yahoo.com (nm12-vm0.bullet.mail.ac4.yahoo.com [98.139.53.198]) by ietfa.amsl.com (Postfix) with SMTP id 5154E21F8E96 for ; Tue, 6 Sep 2011 13:34:42 -0700 (PDT) Received: from [98.139.52.189] by nm12.bullet.mail.ac4.yahoo.com with NNFMP; 06 Sep 2011 20:36:27 -0000 Received: from [98.139.52.129] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 06 Sep 2011 20:36:27 -0000 Received: from [127.0.0.1] by omp1012.mail.ac4.yahoo.com with NNFMP; 06 Sep 2011 20:36:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 584333.69513.bm@omp1012.mail.ac4.yahoo.com Received: (qmail 69096 invoked by uid 60001); 6 Sep 2011 20:36:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1315341386; bh=yKGJNZ5tqEpeSS43/qJYJaJhoZReVb5WeCPevZH6JLA=; 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=ZPYL7qHreZZVQ02RvUpK1FXJtG1Sr2l9sxYnRDKkpisfseKvs1sAfgAiMcfUiq9O7NZPztMrSXZfJhqbF7IScLNOFrkYIooLDPmKhEIr1/yIhXI4KI5dW99MuEU4rergS51UuTMrjJ/MZv5B0KavQRbQFBLXKK1mwJfo4LDCF34= 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=oj0/cUhIt73dg+IZjAB8m1UqdXbtmNaZhSq+lxBfwZ5+BotDRVG83Bhe3MwVm6VgCxiHsRA0hPGuTP+AidwPMctXTZ+9AM2LN4TrPa+edIcbZCcPWPFValomevNoi0SUPmoL1WObKn/u/P7hIiZdaHgyTKITp5450gu2EX/0whE=; X-YMail-OSG: ejvaypAVM1msWOPVyRWn_9vI534tw8MFRaadnetb.xRdvnM mwI5wL_5s_kQL2sfzw8nmJeXvCpx3_J1cULzbw5Ob0ZX32u9d81ChD_Hp4Tg 08wQxQHwmbb6OWVaxMPh0ESiiiSRGpQqQXV.felSWKb_Mp7EP_GjjioVvWnT DyOccPWmDcBO0.Cv.PUcz06ZgkZU50QhQhb6sjXpPZvnV9GYh4GKahYyfUDK 5xpwGH51LSCwjs_8h2xn4XOmQhTterGgL_8_FBRSinq9QkkBnlrB8aa756M6 YpMTPnIzgqiAS5KMUVzDF_YgQ8EcXw8y4UUbWMqbYJ3gB391H8Rh5ErGOJwF ff5ya36aF0vSBmPHh1ifkIT5roFbmPRA3rXyy09zKvOqTXcjvF.8sz2NICoS S_Lg7u5ufXlzzBxHiJdWgmWQn35dUJE9m2k92vISv8bf9azQVYWJa2A-- Received: from [209.131.62.113] by web31806.mail.mud.yahoo.com via HTTP; Tue, 06 Sep 2011 13:36:26 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.114.317681 References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> Message-ID: <1315341386.69038.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Tue, 6 Sep 2011 13:36:26 -0700 (PDT) From: William Mills To: Michael Thomas In-Reply-To: <4E666B65.30701@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-208145903-1315341386=:69038" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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: Tue, 06 Sep 2011 20:34:45 -0000 --0-208145903-1315341386=:69038 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes, unfortunately a lot *is* on the shoulders of the users.=A0 It's a very= difficult problem.=A0 What OAuth *does* do is hopefully make the situation= incrementally better because there's an infrastructure for having the user= only enter their username/password pair at the site they actually have tha= t relationship with, and in installed apps that previously demanded caching= the user password we can have a credential there instead.=0A=0ANone of it = addresses the "is this thing safe to use?" question though.=0A=0A=0A=0A____= ____________________________=0AFrom: Michael Thomas =0ATo: W= illiam Mills =0ACc: Eran Hammer-Lahav ; "oauth@ietf.org" =0ASent: Tuesday, September 6, 201= 1 11:50 AM=0ASubject: Re: [OAUTH-WG] problem statement=0A=0AWilliam Mills w= rote:=0A> OAuth doesn't solve this problem, and can't.=A0 Generally the que= stion is whether the app appears to come from a reputable source, and nowad= ays whether it's signed (in windows land) or otherwize certified by the pro= vider.=0A> =0A> If you manage to solve this problem in a real way I'd be in= terested in investing in your company.=0A=0AThen what I don't see anywhere = is that oauth is not applicable to embedded=0Aweb objects, and that end use= rs should *never* trust oauth in a, say, phone=0Aapp. As far as I can tell,= the server deploying oauth can't tell that it's=0Abeing misused, so this i= s all on the shoulders of the end user.=0A=0AIt sure looks like oauth is ea= sily subverted in the real world.=0A=0AMike=0A=0A> =0A> -------------------= -----------------------------------------------------=0A> *From:* Michael T= homas =0A> *To:* Eran Hammer-Lahav =0A>= *Cc:* "oauth@ietf.org" =0A> *Sent:* Tuesday, September 6, = 2011 11:34 AM=0A> *Subject:* Re: [OAUTH-WG] problem statement=0A> =0A> Eran= Hammer-Lahav wrote:=0A>=A0 > Don't install crap on you device or computer.= OAuth is the least of your concern if you install bad software.=0A>=A0 > I= f there was a solution to this we would not need an antivirus.=0A> =0A> How= exactly does an end user know what is "crap" or not? Or are you just dismi= ssive of apps in=0A> general? I don't think that apple and google are going= to close up shop because it breaks oauth's=0A> trust model.=0A> =0A> Mike= =0A> =0A>=A0 >=0A>=A0 > EHL=0A>=A0 > On Sep 6, 2011, at 11:23, "Michael Tho= mas" > wrote:=0A>=A0 >=0A>=A0 >> Eran = Hammer-Lahav wrote:=0A>=A0 >>> I agree. If you are going to install a nativ= e app, you better trust it not to do bad things. Grabbing your password is = the least interesting thing such an app can abuse. I don't see any need to = change the v2 draft.=0A>=A0 >> How, exactly, is the user supposed to protec= t themselves against rogue apps?=0A>=A0 >> It sounds like the solution is t= o tell them to never use oauth in an app at all.=0A>=A0 >>=0A>=A0 >> Is oau= th only intended to be used on standalone trustable web browsers? I don't r= ecall=0A>=A0 >> seeing that anywhere.=0A>=A0 >>=0A>=A0 >> Mike=0A>=A0 >>=0A= >=A0 >>> EHL=0A>=A0 >>>=0A>=A0 >>> On Sep 6, 2011, at 11:10, "Igor Faynberg= " > wrote:=0A>=A0 >>>=0A>=A0 >>>> Mike,=0A>=A0 >>>>=0A>=A0 >>>> You've got = the problem statement right: allowing the user to authorize=A0 resource acc= ess to another party without divulging user's credentials is the objective = of OAuth. You are also right in that the attack you have described defies t= he whole purpose of OAuth.=A0 I do not think though that it is related to O= Auth per se.=0A>=A0 >>>>=0A>=A0 >>>> To this end, the security work led by = Torsten has thoroughly analyzed the protocol and specified protection again= st multiple protocol attacks.=A0 From what you described, it appears to me = that the attack you mention is not related to the protocol but rather to th= e user's environment.=A0 There is no possible protection from key loggers t= hat a protocol can implement. I could be mistaken; in any case, it looks li= ke the problem rests with the implementation of WebView.=0A>=A0 >>>>=0A>=A0= >>>> If I am wrong, I would appreciate a detailed description of what happ= ened.=0A>=A0 >>>>=0A>=A0 >>>> Igor=0A>=A0 >>>>=0A>=A0 >>>> On 9/6/2011 1:40= PM, Michael Thomas wrote:=0A>=A0 >>>>> Hi all,=0A>=A0 >>>>>=0A>=A0 >>>>> B= arry suggested that I might subscribe and explain what I sent him.=0A>=A0 >= >>>>=0A>=A0 >>>>> My basic problem is that in neither the protocol nor the = threats drafts,=0A>=A0 >>>>> I can't seem to find what problem is actually = trying to be solved with=0A>=A0 >>>>> oauth, and what assumptions you're ma= king about various elements.=0A>=A0 >>>>>=0A>=A0 >>>>> Here's what I did. I= 've written an app, and I wanted re-integrate the=0A>=A0 >>>>> ability to s= end tweets after they deprecated Basic. So the app has a=0A>=A0 >>>>> webVi= ew (android, iphone...) which it obviously completely controls.=0A>=A0 >>>>= > With oauth, the webview UA will ultimately redirect off to Twitter's=0A>= =A0 >>>>> site to collect the user's credentials and grant my app's backend= an=0A>=A0 >>>>> access token (sorry if I get terminology screwed up, i'm j= ust coming=0A>=A0 >>>>> up to speed).=0A>=A0 >>>>>=0A>=A0 >>>>> What occurs= to me is that webview affords exactly zero protection from=0A>=A0 >>>>> my= client (ie, the app) from getting the user's twitter credentials. All=0A>= =A0 >>>>> I have to do is set up a keypress handler on that webview and in = a few=0A>=A0 >>>>> minutes of hacking I have a key logger. etc.=0A>=A0 >>>>= >=0A>=A0 >>>>> So what I can't tell is whether this is a "problem" or not, = because I=0A>=A0 >>>>> don't know what problem you're trying to solve. If t= he object of oauth=0A>=A0 >>>>> isn't to keep user/server credentials out o= f the hands of a third party,=0A>=A0 >>>>> then what is it trying to solve?= Is there an expectation that the=0A>=A0 >>>>> UA is trusted by the user/se= rver? What happens when that's not the case?=0A>=A0 >>>>>=0A>=A0 >>>>> Rega= rdless of whether I'm misunderstanding, it would sure be nice to have=0A>= =A0 >>>>> both the problem and your assumptions laid out, hopefully with so= me prominence=0A>=A0 >>>>> so you don't get these sort of dumb questions.= =0A>=A0 >>>>>=0A>=A0 >>>>> Mike=0A>=A0 >>>>> ______________________________= _________________=0A>=A0 >>>>> OAuth mailing list=0A>=A0 >>>>> OAuth@ietf.o= rg =0A>=A0 >>>>> https://www.ietf.org/mailman/listin= fo/oauth=0A>=A0 >>>> _______________________________________________=0A>=A0= >>>> OAuth mailing list=0A>=A0 >>>> OAuth@ietf.org = =0A>=A0 >>>> https://www.ietf.org/mailman/listinfo/oauth=0A>=A0 >>> _______= ________________________________________=0A>=A0 >>> OAuth mailing list=0A>= =A0 >>> OAuth@ietf.org =0A>=A0 >>> 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> --0-208145903-1315341386=:69038 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, unfortunately a lot *is* on the shoulders of the users.  It's a= very difficult problem.  What OAuth *does* do is hopefully make the s= ituation incrementally better because there's an infrastructure for having = the user only enter their username/password pair at the site they actually = have that relationship with, and in installed apps that previously demanded= caching the user password we can have a credential there instead.

None of it addresses the "is thi= s thing safe to use?" question though.

From: Michael T= homas <mike@mtcc.com>
To: William Mills <wmills@yahoo-inc.com>
Cc: Eran Hammer-Lahav <eran@hueniverse.com&= gt;; "oauth@ietf.org" <oauth@ietf.org>
Sent: Tuesday, September 6, 2011 11:50 AM
Subject: Re: [OAUTH-WG] problem st= atement

William Mills wrote:
> OAuth doesn't solve this= problem, and can't.  Generally the question is whether the app appear= s to come from a reputable source, and nowadays whether it's signed (in win= dows land) or otherwize certified by the provider.
>
> If you = manage to solve this problem in a real way I'd be interested in investing i= n your company.

Then what I don't see anywhere is that oauth is not applicable to embedded
web objects, and that end users should *never* t= rust oauth in a, say, phone
app. As far as I can tell, the server deploy= ing oauth can't tell that it's
being misused, so this is all on the shou= lders of the end user.

It sure looks like oauth is easily subverted = in the real world.

Mike

>
> -----------------------= -------------------------------------------------
> *From:* Michael T= homas <mike@mtcc.com>
> *To:* Eran Hammer-Lahav <eran@hueniver= se.com>
> *Cc:* "oauth@ietf.org" <oauth@ietf.org>
> *Sen= t:* Tuesday, September 6, 2011 11:34 AM
> *Subject:* Re: [OAUTH-WG] p= roblem statement
>
> Eran Hammer-Lahav wrote:
>  > Don= 't install crap on you device or computer. OAuth is the least of your conce= rn if you install bad software.
>  > If there was a solution = to this we would not need an antivirus.
>
> How exactly does a= n end user know what is "crap" or not? Or are you just dismissive of apps i= n
> general? I don't think that apple and google are going to close u= p shop because it breaks oauth's
> trust model.
>
> Mike=
>
>  >
>  > EHL
>  > On S= ep 6, 2011, at 11:23, "Michael Thomas" <mike@mtcc.com <mailto:mike@mtcc.com&g= t;> wrote:
>  >
>  >> Eran Hammer-Lahav w= rote:
>  >>> I agree. If you are going to install a nat= ive app, you better trust it not to do bad things. Grabbing your password is t= he least interesting thing such an app can abuse. I don't see any need to c= hange the v2 draft.
>  >> How, exactly, is the user suppos= ed to protect themselves against rogue apps?
>  >> It soun= ds like the solution is to tell them to never use oauth in an app at all.>  >>
>  >> Is oauth only intended to be u= sed on standalone trustable web browsers? I don't recall
>  >= > seeing that anywhere.
>  >>
>  >> Mi= ke
>  >>
>  >>> EHL
>  >= >>
>  >>> On Sep 6, 2011, at 11:10, "Igor Faynber= g" <igor.faynberg@alcatel-lucent.com &l= t;mailto:igor.faynberg@alcatel-luc= ent.com>> wrote:
>  >>>
>  >>= ;>> Mike,
>  >>>>
>  >>>&g= t; You've got the problem statement right: allowing the user to authorize&n= bsp; resource access to another party without divulging user's credentials = is the objective of OAuth. You are also right in that the attack you have d= escribed defies the whole purpose of OAuth.  I do not think though tha= t it is related to OAuth per se.
>  >>>>
>&nbs= p; >>>> To this end, the security work led by Torsten has thoro= ughly analyzed the protocol and specified protection against multiple proto= col attacks.  From what you described, it appears to me that the attac= k you mention is not related to the protocol but rather to the user's envir= onment.  There is no possible protection from key loggers that a protocol can implement. I could be mistaken; in any case, it looks like th= e problem rests with the implementation of WebView.
>  >>&= gt;>
>  >>>> If I am wrong, I would appreciate a = detailed description of what happened.
>  >>>>
&g= t;  >>>> Igor
>  >>>>
> = >>>> On 9/6/2011 1:40 PM, Michael Thomas wrote:
>  = >>>>> Hi all,
>  >>>>>
>&nbs= p; >>>>> Barry suggested that I might subscribe and explain = what I sent him.
>  >>>>>
>  >>&= gt;>> My basic problem is that in neither the protocol nor the threat= s drafts,
>  >>>>> I can't seem to find what prob= lem is actually trying to be solved with
>  >>>>>= oauth, and what assumptions you're making about various elements.
>  >>>>>
>  >>>>= ;> Here's what I did. I've written an app, and I wanted re-integrate the=
>  >>>>> ability to send tweets after they depre= cated Basic. So the app has a
>  >>>>> webView (a= ndroid, iphone...) which it obviously completely controls.
>  &g= t;>>>> With oauth, the webview UA will ultimately redirect off = to Twitter's
>  >>>>> site to collect the user's = credentials and grant my app's backend an
>  >>>>>= ; access token (sorry if I get terminology screwed up, i'm just coming
&= gt;  >>>>> up to speed).
>  >>>>= >
>  >>>>> What occurs to me is that webview a= ffords exactly zero protection from
>  >>>>> my c= lient (ie, the app) from getting the user's twitter credentials. All
>  >>>>> I have to do is set up a keypress h= andler on that webview and in a few
>  >>>>> minu= tes of hacking I have a key logger. etc.
>  >>>>>=
>  >>>>> So what I can't tell is whether this is= a "problem" or not, because I
>  >>>>> don't kno= w what problem you're trying to solve. If the object of oauth
> = >>>>> isn't to keep user/server credentials out of the hand= s of a third party,
>  >>>>> then what is it tryi= ng to solve? Is there an expectation that the
>  >>>>= ;> UA is trusted by the user/server? What happens when that's not the ca= se?
>  >>>>>
>  >>>>> R= egardless of whether I'm misunderstanding, it would sure be nice to have>  >>>>> both the problem and your assumptions laid out, hopefully with some prominence
>  >>= ;>>> so you don't get these sort of dumb questions.
>  = >>>>>
>  >>>>> Mike
>  = >>>>> _______________________________________________
>= ;  >>>>> OAuth mailing list
>  >>>&= gt;> OAuth@ietf.org <mailto:OAuth@ietf.org>
>  >>>&g= t;> https://www.ietf.org/mailman/listinfo/oauth
>  >>= ;>> _______________________________________________
>  >= ;>>> OAuth mailing list
>  >>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>  >>>> https://www.ietf.= org/mailman/listinfo/oauth
>  >>> _________________= ______________________________
>  >>> OAuth mailing lis= t
>  >>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>=   >>> https://www.ietf.org/mailman/listinfo/oauth
> =
> _______________________________________________
> OAuth mail= ing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.i= etf.org/mailman/listinfo/oauth
>
>



<= /div>
--0-208145903-1315341386=:69038-- From mike@mtcc.com Tue Sep 6 13:35: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 8FF3F21F8EA3 for ; Tue, 6 Sep 2011 13:35:04 -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 RaCpR+Wj6Gxb for ; Tue, 6 Sep 2011 13:35:03 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id D5B6421F8E96 for ; Tue, 6 Sep 2011 13:35:03 -0700 (PDT) Received: from piolinux.mtcc.com (65-165-164-246.volcano.net [65.165.164.246]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p86KanjA014592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 13:36:50 -0700 Message-ID: <4E66845E.7090906@mtcc.com> Date: Tue, 06 Sep 2011 13:36:46 -0700 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: John Kemp References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> In-Reply-To: <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2223; t=1315341411; x=1316205411; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20John=20Kemp=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=8Inc4zvizFSsimmBfVYenlv8ERA4tWCEPlVron7XXWI=; b=O75OPcTc6hcpsCT94/TQGi+xsky6kzGg/x47MAw3x21GfG3Shay10VrNFo 5VfSMZOt5FAxgkWt/rNEw3lJsG/BqlI6saZDQvbcnDXav6baieiTIVzUzh54 keSHKMRdJvf9S+aXEiftZYLjRdPadHqtZx4bwGVeOPXAEeZbHMhcU=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: OAuth WG Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 20:35:04 -0000 John Kemp wrote: >> I can tell you from experience that Android absolutely doesn't check anything of this >> sort, and it would take extremely deep voodoo for Apple to do the same: they never see >> source. > > I believe that both Apple and Google *do attempt* to prevent malware from getting into their stores. No, seriously, they don't. Google has no review process at all, just a kill switch after the fact. Apple doesn't have source, so the amount of testing they can do is limited, and is about 99 & 44/100% marketing hype in any case. >>> But I'm being told that use cases aren't the problem of oauth. I'd say that >>>> there has all along been a hidden assumption that the browser was >>>> a trusted entity. >>> The point is simply that if you can subvert the actual platform, then OAuth problems are the least of your worries (as a user). >> People keep saying that to deflect criticism, but I don't buy it. Other protocols aren't >> availing an attacker to user credentials to third party servers by simply snooping on the >> webview key traffic in an otherwise completely normal use pattern. > > HTTP Auth? Web form login? When an app asks for your login credentials, it looks like the app itself asking if it's on the up and up. With OAuth, it looks like it's twitter, or facebook, or whichever trusted service you're logging into. That's why I say that this situation is worse: as a user, I have no idea which apps are good and which are sending your credentials to a broker in Romania. At least I have some clue that it *might* do that in the first case, but with OAuth I'm being told that that's why it exists so that I don't *have* to trust that app. Except that I do as it turns out. >> Have you ever signed on to facebook in an app before? > > Frankly, not too often, no, since these apps usually ask for far more authority than I believe is necessary for the purpose of using the app. But even if you did it once, how did you know that you didn't reveal your credentials to a bad guy? And I'm being told that this isn't even worthy of any mention anywhere? I came here hoping to hear that the attack wasn't possible, or could be mitigated. Zoicks. Mike From john@jkemp.net Tue Sep 6 13:57: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 417AD21F8C66 for ; Tue, 6 Sep 2011 13:57:11 -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 V78M2l63WYjg for ; Tue, 6 Sep 2011 13:57:10 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id AD16B21F8BE5 for ; Tue, 6 Sep 2011 13:57:10 -0700 (PDT) Received: (qmail 14930 invoked by uid 0); 6 Sep 2011 20:58:57 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by oproxy9.bluehost.com with SMTP; 6 Sep 2011 20:58:57 -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=w3xqyW0wqNQG2o+NoIg/9VveiFhZJx4wAZm5Z83nC8I=; b=DZJYof+8zqcFyybLZkvY9M4syfy9e+qoiZIADi/1AC0HXr+38O+0FT2VUOjmafCF+EzX8YMskHG+Jnsbw9306fjGAYBmLB7EQLm3lIl2e0FO8NrLOjWCLM5mgfjDOcQq; Received: from cpe-74-67-30-101.nycap.res.rr.com ([74.67.30.101] helo=[192.168.1.110]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1R12jQ-0002az-V6; Tue, 06 Sep 2011 14:58:57 -0600 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: John Kemp In-Reply-To: <4E66845E.7090906@mtcc.com> Date: Tue, 6 Sep 2011 16:59:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> To: Michael Thomas 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 Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 20:57:11 -0000 On Sep 6, 2011, at 4:36 PM, Michael Thomas wrote: [=85] > But even if you did it once, how did you know that you didn't reveal = your credentials > to a bad guy? >=20 > And I'm being told that this isn't even worthy of any mention = anywhere? I came > here hoping to hear that the attack wasn't possible, or could be = mitigated. The attack can be mitigated, but it cannot be prevented through = protocols like OAuth (or any other protocol that I know of) alone. The point is that you have a point.=20 But OAuth alone cannot address your point - it provides a different -- = and still useful, mitigation for attacks on user credentials sent over a = network. It's not a superhero though. - John > Zoicks. >=20 > Mike From melinda.shore@gmail.com Tue Sep 6 15:20: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 5B8CC21F8F72 for ; Tue, 6 Sep 2011 15:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 WF+HrhFCly-j for ; Tue, 6 Sep 2011 15:20:57 -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 C52EA21F8F71 for ; Tue, 6 Sep 2011 15:20:57 -0700 (PDT) Received: by gwb20 with SMTP id 20so4491007gwb.31 for ; Tue, 06 Sep 2011 15:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Kgqz8nB9TzFNcskrvqrFkkXRFzQSRxzJ5qVlgCPpa1k=; b=WWpnAzgkigXim/obPfknL1jEQpL4JLokXQ5XDu7oKwskq/51pFfCmPefO4SAqAql8f ueUsPCwyA+9O3ZJfebSsuca5lCYwC6hQW4q5GZZTLsCSAS0xXngqA/y3YTh8J1yyGzJX He9iMPcIAJqNjxrJlHm9jfXMrkpEffaYlnyCg= Received: by 10.68.54.39 with SMTP id g7mr10684480pbp.487.1315347764779; Tue, 06 Sep 2011 15:22:44 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu. [137.229.12.236]) by mx.google.com with ESMTPS id jl4sm80857pbc.10.2011.09.06.15.22.43 (version=SSLv3 cipher=OTHER); Tue, 06 Sep 2011 15:22:43 -0700 (PDT) Message-ID: <4E669D3C.5000900@gmail.com> Date: Tue, 06 Sep 2011 14:22:52 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: oauth@ietf.org References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 22:20:58 -0000 On 09/06/2011 12:59 PM, John Kemp wrote: > The point is that you have a point. He does, and that's in some large part why I don't fully understand the temperature of the responses. I do not think it's a particularly big deal to stick a couple of sentences in the security considerations underscoring the fact that OAUTH can't do anything about a compromised host or a malicious application. I've learned to live with the fact that sometimes people implementing or deploying security technologies don't fully understand them and it's my impression that there's some number of people out there who think that OAUTH and other third-party protocols provide sufficient protection against password snagging. Melinda From eran@hueniverse.com Tue Sep 6 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 BD54A21F8F5D for ; Tue, 6 Sep 2011 15:26:48 -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 VhFYEQ0IiyoI for ; Tue, 6 Sep 2011 15:26:48 -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 EED7221F8F5C for ; Tue, 6 Sep 2011 15:26:47 -0700 (PDT) Received: (qmail 10768 invoked from network); 6 Sep 2011 22:28:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Sep 2011 22:28:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Sep 2011 15:27:55 -0700 From: Eran Hammer-Lahav To: Melinda Shore Date: Tue, 6 Sep 2011 15:27:46 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: Acxs5Dk0gFFOz1oSQnOy+Uz4hOYinA== Message-ID: <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> In-Reply-To: <4E669D3C.5000900@gmail.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 22:26:48 -0000 It is a problem. For a few months now we have been going through this over = and over again. The longer we work on this draft the more of this two-sente= nce changes people suggest. They don't make the document any better, create= a false sense of comprehensiveness, and just further delay being done.=20 So yeah, unless you can prove that there is an actual problem, we are done.= =20 EHL On Sep 6, 2011, at 15:22, "Melinda Shore" wrote: > On 09/06/2011 12:59 PM, John Kemp wrote: >> The point is that you have a point. >=20 > He does, and that's in some large part why I don't > fully understand the temperature of the responses. > I do not think it's a particularly big deal to stick > a couple of sentences in the security considerations > underscoring the fact that OAUTH can't do anything > about a compromised host or a malicious application. > I've learned to live with the fact that sometimes > people implementing or deploying security technologies > don't fully understand them and it's my impression that > there's some number of people out there who think that > OAUTH and other third-party protocols provide sufficient > protection against password snagging. >=20 > Melinda > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From aiden449@gmail.com Tue Sep 6 16:10: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 0C04921F8F47 for ; Tue, 6 Sep 2011 16:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.276 X-Spam-Level: X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AWL=0.322, 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 xpf9XPfMicbn for ; Tue, 6 Sep 2011 16:10:28 -0700 (PDT) Received: from mail-qw0-f52.google.com (mail-qw0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id E518521F8EB2 for ; Tue, 6 Sep 2011 16:10:27 -0700 (PDT) Received: by qwb8 with SMTP id 8so5932895qwb.25 for ; Tue, 06 Sep 2011 16:12:15 -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 :content-type; bh=M9dAJC4/QegdO4U/uw+kILLBxQ7ND/cAZT8VJhyuCCI=; b=QkeJeWuihNN+u8i81FmcXNI4vwo+x84zgkAjsFrwkdRBFUvHgb8gfvs7HUV0J5Bkhj PuNZGmTUlis8mV2FNAwlSWmI4CfWTcerxMSejqdvaWsdNmovhET+PNSGvKcsvi/m2uDp 3KH+/mz2anjg7suLY9cPA7NzyvDoSs0ibCZk8= MIME-Version: 1.0 Received: by 10.229.222.85 with SMTP id if21mr255785qcb.124.1315350734274; Tue, 06 Sep 2011 16:12:14 -0700 (PDT) Received: by 10.229.249.71 with HTTP; Tue, 6 Sep 2011 16:12:14 -0700 (PDT) In-Reply-To: <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> Date: Wed, 7 Sep 2011 00:12:14 +0100 Message-ID: From: Aiden Bell To: Eran Hammer-Lahav , OAuth WG Content-Type: multipart/alternative; boundary=001636284bda457fbb04ac4df50c Subject: Re: [OAUTH-WG] problem statement 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, 06 Sep 2011 23:10:29 -0000 --001636284bda457fbb04ac4df50c Content-Type: text/plain; charset=ISO-8859-1 Perhaps a solution is to push OAuth.net as more of a "everything you ever wanted to know about OAuth" and direct non-core issues there for a page of good content to be created. This way the RFC can focus on the issue at hand and broader scope can be taken care of without having a 40+ thread on something like this. Developers can still have a voice on these things, even if it isn't directly through the RFC. I feel strongly enough that I would be willing to help here. Let me know if I can be of any assistance in having these things dealt with more appropriately through something like that. Aiden On 6 September 2011 23:27, Eran Hammer-Lahav wrote: > It is a problem. For a few months now we have been going through this over > and over again. The longer we work on this draft the more of this > two-sentence changes people suggest. They don't make the document any > better, create a false sense of comprehensiveness, and just further delay > being done. > > So yeah, unless you can prove that there is an actual problem, we are done. > > EHL > > On Sep 6, 2011, at 15:22, "Melinda Shore" wrote: > > > On 09/06/2011 12:59 PM, John Kemp wrote: > >> The point is that you have a point. > > > > He does, and that's in some large part why I don't > > fully understand the temperature of the responses. > > I do not think it's a particularly big deal to stick > > a couple of sentences in the security considerations > > underscoring the fact that OAUTH can't do anything > > about a compromised host or a malicious application. > > I've learned to live with the fact that sometimes > > people implementing or deploying security technologies > > don't fully understand them and it's my impression that > > there's some number of people out there who think that > > OAUTH and other third-party protocols provide sufficient > > protection against password snagging. > > > > Melinda > > _______________________________________________ > > 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 --001636284bda457fbb04ac4df50c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps a solution is to push OAuth.net as more of a "everything you e= ver wanted to know about OAuth"
and direct non-core issues there fo= r a page of good content to be created. This way the RFC can focus on the issue at hand and broader scope can be taken care of without having a 40+ t= hread on something like this.

Developers can still have a voice on t= hese things, even if it isn't directly through the RFC.

I feel s= trongly enough that I would be willing to help here. Let me know if I can b= e of any assistance
in having these things dealt with more appropriately through something like= that.

Aiden

On 6 September 2011 2= 3:27, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
It is a problem. For a few months now we ha= ve been going through this over and over again. The longer we work on this = draft the more of this two-sentence changes people suggest. They don't = make the document any better, create a false sense of comprehensiveness, an= d just further delay being done.

So yeah, unless you can prove that there is an actual problem, we are done.=

EHL

On Sep 6, 2011, at 15:22, "Melinda Shore" <melinda.shore@gmail.com> wrote:

> On 09/06/2011 12:59 PM, John Kemp wrote:
>> The point is that you have a point.
>
> He does, and that's in some large part why I don't
> fully understand the temperature of the responses.
> I do not think it's a particularly big deal to stick
> a couple of sentences in the security considerations
> underscoring the fact that OAUTH can't do anything
> about a compromised host or a malicious application.
> I've learned to live with the fact that sometimes
> people implementing or deploying security technologies
> don't fully understand them and it's my impression that
> there's some number of people out there who think that
> OAUTH and other third-party protocols provide sufficient
> protection against password snagging.
>
> Melinda
> _______________________________________________
> 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 sensi= tive or private information via email unless it is encrypted. http://www.gnupg.org
--001636284bda457fbb04ac4df50c-- From mike@mtcc.com Tue Sep 6 17:00: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 CB9A921F8F99 for ; Tue, 6 Sep 2011 17:00:22 -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 aav51VomKxMS for ; Tue, 6 Sep 2011 17:00:22 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1F72521F8E62 for ; Tue, 6 Sep 2011 17:00:22 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87024UF018206 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 17:02:05 -0700 Message-ID: <4E66B47C.2020909@mtcc.com> Date: Tue, 06 Sep 2011 17:02:04 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Melinda Shore References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> In-Reply-To: <4E669D3C.5000900@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1744; t=1315353727; x=1316217727; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Melinda=20Shore=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=GSoVFHWBQfKrI0fgVc6m/eqyRi2hUlccmedr+d/ewEo=; b=Jp3FQj2PifWGN1mYrKTf33SnclAsrFEwmvs3yPk+w3qRlNL5IJQhVTStny 7tSFRu9qRbVQ9IC8hiC0g/64FHQbYxjEpEsuejVhQOReVm71Tp0OgZE++9Xe w4FrJvCi657Li070RteaEFWrXsI2ExQXIiEO9Z9MoM+1wBjF5PXjQ=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 00:00:22 -0000 On 09/06/2011 03:22 PM, Melinda Shore wrote: > On 09/06/2011 12:59 PM, John Kemp wrote: >> The point is that you have a point. > > He does, and that's in some large part why I don't > fully understand the temperature of the responses. > I do not think it's a particularly big deal to stick > a couple of sentences in the security considerations > underscoring the fact that OAUTH can't do anything > about a compromised host or a malicious application. > I've learned to live with the fact that sometimes > people implementing or deploying security technologies > don't fully understand them and it's my impression that > there's some number of people out there who think that > OAUTH and other third-party protocols provide sufficient > protection against password snagging. The thing that was baffling to me is that there is no mention at all about the assumptions anywhere I could find. I knew of the "trusted" web browser assumption because it appears that oauth predates the widespread phenomenon of phone apps, and I kind of understood where oauth was coming from. So to *not* have that assumption discussed or even listed as an assumption is very surprising -- does this play well in the scenario I outlined or not? As it turns out, not. Barry thought this was "obvious", but it wasn't obvious to me. I suspect that this will come as quite a surprise to the uninitiated who would roll this out to the masses. It's not even clear to me that Twitter or Facebook even realize that this attack exists. Or are they cool with the fact that anybody with an app and a webview can ship their credentials to Romania? My guess is that it's pretty uncool. So no, I don't get all of the hostility either. Mike From mike@mtcc.com Tue Sep 6 17:03: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 D141821F8CC8 for ; Tue, 6 Sep 2011 17:03:30 -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 yBfXDYWKzo95 for ; Tue, 6 Sep 2011 17:03:30 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 45F4D21F8CB1 for ; Tue, 6 Sep 2011 17:03:30 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p8705E8I019247 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 17:05:14 -0700 Message-ID: <4E66B53A.9030609@mtcc.com> Date: Tue, 06 Sep 2011 17:05:14 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> In-Reply-To: <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=264; t=1315353915; x=1316217915; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=GOqoUJ5w4h0mwJnHJy4Obukm6Z7X5CJLsloycIR1Bkk=; b=nB3CnJ/FNlOYJvJhfJc8WRWWyUkTFaIQjwFXv94J5wpVQqXOaTEY68apkE y59n15pWtgJYsAoyDG+QcX5QeaNb1R9J6Sf25U5Z6MABYNFBX226uF+fYD+M 0M+3UDrdngqgEGG3inAeV+Eb5LXhciG8pY+8tuo785Id9CoIpbDI4=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 00:03:30 -0000 On 09/06/2011 03:27 PM, Eran Hammer-Lahav wrote: > So yeah, unless you can prove that there is an actual problem, we are done. > I will point out that the chairs make that determination based on working group consensus, not the document editor. Mike From eran@hueniverse.com Tue Sep 6 17:06: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 6F67621F8ABE for ; Tue, 6 Sep 2011 17:06:09 -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 ICoLaI-7Vp71 for ; Tue, 6 Sep 2011 17:06:08 -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 843FC21F8AB0 for ; Tue, 6 Sep 2011 17:06:08 -0700 (PDT) Received: (qmail 20687 invoked from network); 7 Sep 2011 00:07:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 00:07:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Sep 2011 17:07:45 -0700 From: Eran Hammer-Lahav To: Aiden Bell Date: Tue, 6 Sep 2011 17:07:37 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: Acxs8isnEL2PlvMMQzST9oaf1ZGMCQ== Message-ID: <0D972529-49A4-4762-B2D3-5922F9EB444E@hueniverse.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@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_0D97252949A44762B2D35922F9EB444Ehueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 00:06:09 -0000 --_000_0D97252949A44762B2D35922F9EB444Ehueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V3JpdGUgY29udGVudCBhbmQgcGluZyBtZSBvZmYgbGlzdC4gVG8gYXZvaWQgY29uZnVzaW9uLCBu b3RlIHRoYXQgb2F1dGgubmV0PGh0dHA6Ly9vYXV0aC5uZXQ+IGhhcyBub3RoaW5nIHRvIGRvIHdp dGggdGhpcyBsaXN0IGFuZCB0aGUgSUVURi4NCg0KRUhMDQoNCk9uIFNlcCA2LCAyMDExLCBhdCAx NjoxMiwgIkFpZGVuIEJlbGwiIDxhaWRlbjQ0OUBnbWFpbC5jb208bWFpbHRvOmFpZGVuNDQ5QGdt YWlsLmNvbT4+IHdyb3RlOg0KDQpQZXJoYXBzIGEgc29sdXRpb24gaXMgdG8gcHVzaCBPQXV0aC5u ZXQ8aHR0cDovL09BdXRoLm5ldD4gYXMgbW9yZSBvZiBhICJldmVyeXRoaW5nIHlvdSBldmVyIHdh bnRlZCB0byBrbm93IGFib3V0IE9BdXRoIg0KYW5kIGRpcmVjdCBub24tY29yZSBpc3N1ZXMgdGhl cmUgZm9yIGEgcGFnZSBvZiBnb29kIGNvbnRlbnQgdG8gYmUgY3JlYXRlZC4gVGhpcyB3YXkgdGhl IFJGQyBjYW4gZm9jdXMgb24gdGhlDQppc3N1ZSBhdCBoYW5kIGFuZCBicm9hZGVyIHNjb3BlIGNh biBiZSB0YWtlbiBjYXJlIG9mIHdpdGhvdXQgaGF2aW5nIGEgNDArIHRocmVhZCBvbiBzb21ldGhp bmcgbGlrZSB0aGlzLg0KDQpEZXZlbG9wZXJzIGNhbiBzdGlsbCBoYXZlIGEgdm9pY2Ugb24gdGhl c2UgdGhpbmdzLCBldmVuIGlmIGl0IGlzbid0IGRpcmVjdGx5IHRocm91Z2ggdGhlIFJGQy4NCg0K SSBmZWVsIHN0cm9uZ2x5IGVub3VnaCB0aGF0IEkgd291bGQgYmUgd2lsbGluZyB0byBoZWxwIGhl cmUuIExldCBtZSBrbm93IGlmIEkgY2FuIGJlIG9mIGFueSBhc3Npc3RhbmNlDQppbiBoYXZpbmcg dGhlc2UgdGhpbmdzIGRlYWx0IHdpdGggbW9yZSBhcHByb3ByaWF0ZWx5IHRocm91Z2ggc29tZXRo aW5nIGxpa2UgdGhhdC4NCg0KQWlkZW4NCg0KT24gNiBTZXB0ZW1iZXIgMjAxMSAyMzoyNywgRXJh biBIYW1tZXItTGFoYXYgPDxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT5lcmFuQGh1ZW5pdmVy c2UuY29tPG1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPj4gd3JvdGU6DQpJdCBpcyBhIHByb2Js ZW0uIEZvciBhIGZldyBtb250aHMgbm93IHdlIGhhdmUgYmVlbiBnb2luZyB0aHJvdWdoIHRoaXMg b3ZlciBhbmQgb3ZlciBhZ2Fpbi4gVGhlIGxvbmdlciB3ZSB3b3JrIG9uIHRoaXMgZHJhZnQgdGhl IG1vcmUgb2YgdGhpcyB0d28tc2VudGVuY2UgY2hhbmdlcyBwZW9wbGUgc3VnZ2VzdC4gVGhleSBk b24ndCBtYWtlIHRoZSBkb2N1bWVudCBhbnkgYmV0dGVyLCBjcmVhdGUgYSBmYWxzZSBzZW5zZSBv ZiBjb21wcmVoZW5zaXZlbmVzcywgYW5kIGp1c3QgZnVydGhlciBkZWxheSBiZWluZyBkb25lLg0K DQpTbyB5ZWFoLCB1bmxlc3MgeW91IGNhbiBwcm92ZSB0aGF0IHRoZXJlIGlzIGFuIGFjdHVhbCBw cm9ibGVtLCB3ZSBhcmUgZG9uZS4NCg0KRUhMDQoNCk9uIFNlcCA2LCAyMDExLCBhdCAxNToyMiwg Ik1lbGluZGEgU2hvcmUiIDw8bWFpbHRvOm1lbGluZGEuc2hvcmVAZ21haWwuY29tPm1lbGluZGEu c2hvcmVAZ21haWwuY29tPG1haWx0bzptZWxpbmRhLnNob3JlQGdtYWlsLmNvbT4+IHdyb3RlOg0K DQo+IE9uIDA5LzA2LzIwMTEgMTI6NTkgUE0sIEpvaG4gS2VtcCB3cm90ZToNCj4+IFRoZSBwb2lu dCBpcyB0aGF0IHlvdSBoYXZlIGEgcG9pbnQuDQo+DQo+IEhlIGRvZXMsIGFuZCB0aGF0J3MgaW4g c29tZSBsYXJnZSBwYXJ0IHdoeSBJIGRvbid0DQo+IGZ1bGx5IHVuZGVyc3RhbmQgdGhlIHRlbXBl cmF0dXJlIG9mIHRoZSByZXNwb25zZXMuDQo+IEkgZG8gbm90IHRoaW5rIGl0J3MgYSBwYXJ0aWN1 bGFybHkgYmlnIGRlYWwgdG8gc3RpY2sNCj4gYSBjb3VwbGUgb2Ygc2VudGVuY2VzIGluIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KPiB1bmRlcnNjb3JpbmcgdGhlIGZhY3QgdGhhdCBPQVVU SCBjYW4ndCBkbyBhbnl0aGluZw0KPiBhYm91dCBhIGNvbXByb21pc2VkIGhvc3Qgb3IgYSBtYWxp Y2lvdXMgYXBwbGljYXRpb24uDQo+IEkndmUgbGVhcm5lZCB0byBsaXZlIHdpdGggdGhlIGZhY3Qg dGhhdCBzb21ldGltZXMNCj4gcGVvcGxlIGltcGxlbWVudGluZyBvciBkZXBsb3lpbmcgc2VjdXJp dHkgdGVjaG5vbG9naWVzDQo+IGRvbid0IGZ1bGx5IHVuZGVyc3RhbmQgdGhlbSBhbmQgaXQncyBt eSBpbXByZXNzaW9uIHRoYXQNCj4gdGhlcmUncyBzb21lIG51bWJlciBvZiBwZW9wbGUgb3V0IHRo ZXJlIHdobyB0aGluayB0aGF0DQo+IE9BVVRIIGFuZCBvdGhlciB0aGlyZC1wYXJ0eSBwcm90b2Nv bHMgcHJvdmlkZSBzdWZmaWNpZW50DQo+IHByb3RlY3Rpb24gYWdhaW5zdCBwYXNzd29yZCBzbmFn Z2luZy4NCj4NCj4gTWVsaW5kYQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA8aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KPG1haWx0bzpPQXV0aEBpZXRmLm9y Zz5PQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo8aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpOZXZlciBzZW5kIHNlbnNpdGl2 ZSBvciBwcml2YXRlIGluZm9ybWF0aW9uIHZpYSBlbWFpbCB1bmxlc3MgaXQgaXMgZW5jcnlwdGVk LiA8aHR0cDovL3d3dy5nbnVwZy5vcmc+IGh0dHA6Ly93d3cuZ251cGcub3JnDQo= --_000_0D97252949A44762B2D35922F9EB444Ehueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5Xcml0ZSBjb250ZW50IGFuZCBwaW5n IG1lIG9mZiBsaXN0LiBUbyBhdm9pZCBjb25mdXNpb24sIG5vdGUgdGhhdCA8YSBocmVmPSJodHRw Oi8vb2F1dGgubmV0Ij5vYXV0aC5uZXQ8L2E+IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhpcyBs aXN0IGFuZCB0aGUgSUVURi4mbmJzcDs8YnI+PGJyPjwvZGl2PjxkaXY+RUhMPC9kaXY+PGRpdj48 YnI+T24gU2VwIDYsIDIwMTEsIGF0IDE2OjEyLCAiQWlkZW4gQmVsbCIgJmx0OzxhIGhyZWY9Im1h aWx0bzphaWRlbjQ0OUBnbWFpbC5jb20iPmFpZGVuNDQ5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj48YnI+PC9kaXY+PGRpdj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PlBl cmhhcHMgYSBzb2x1dGlvbiBpcyB0byBwdXNoIDxhIGhyZWY9Imh0dHA6Ly9PQXV0aC5uZXQiPk9B dXRoLm5ldDwvYT4gYXMgbW9yZSBvZiBhICJldmVyeXRoaW5nIHlvdSBldmVyIHdhbnRlZCB0byBr bm93IGFib3V0IE9BdXRoIjxicj5hbmQgZGlyZWN0IG5vbi1jb3JlIGlzc3VlcyB0aGVyZSBmb3Ig YSBwYWdlIG9mIGdvb2QgY29udGVudCB0byBiZSBjcmVhdGVkLiBUaGlzIHdheSB0aGUgUkZDIGNh biBmb2N1cyBvbiB0aGU8YnI+DQppc3N1ZSBhdCBoYW5kIGFuZCBicm9hZGVyIHNjb3BlIGNhbiBi ZSB0YWtlbiBjYXJlIG9mIHdpdGhvdXQgaGF2aW5nIGEgNDArIHRocmVhZCBvbiBzb21ldGhpbmcg bGlrZSB0aGlzLjxicj48YnI+RGV2ZWxvcGVycyBjYW4gc3RpbGwgaGF2ZSBhIHZvaWNlIG9uIHRo ZXNlIHRoaW5ncywgZXZlbiBpZiBpdCBpc24ndCBkaXJlY3RseSB0aHJvdWdoIHRoZSBSRkMuPGJy Pjxicj5JIGZlZWwgc3Ryb25nbHkgZW5vdWdoIHRoYXQgSSB3b3VsZCBiZSB3aWxsaW5nIHRvIGhl bHAgaGVyZS4gTGV0IG1lIGtub3cgaWYgSSBjYW4gYmUgb2YgYW55IGFzc2lzdGFuY2U8YnI+DQpp biBoYXZpbmcgdGhlc2UgdGhpbmdzIGRlYWx0IHdpdGggbW9yZSBhcHByb3ByaWF0ZWx5IHRocm91 Z2ggc29tZXRoaW5nIGxpa2UgdGhhdC48YnI+PGJyPkFpZGVuPGJyPjxicj48ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+T24gNiBTZXB0ZW1iZXIgMjAxMSAyMzoyNywgRXJhbiBIYW1tZXItTGFoYXYg PHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+ PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20iPmVyYW5AaHVlbml2ZXJzZS5jb208 L2E+PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXg7Ij5JdCBpcyBhIHByb2JsZW0uIEZvciBhIGZldyBtb250aHMgbm93 IHdlIGhhdmUgYmVlbiBnb2luZyB0aHJvdWdoIHRoaXMgb3ZlciBhbmQgb3ZlciBhZ2Fpbi4gVGhl IGxvbmdlciB3ZSB3b3JrIG9uIHRoaXMgZHJhZnQgdGhlIG1vcmUgb2YgdGhpcyB0d28tc2VudGVu Y2UgY2hhbmdlcyBwZW9wbGUgc3VnZ2VzdC4gVGhleSBkb24ndCBtYWtlIHRoZSBkb2N1bWVudCBh bnkgYmV0dGVyLCBjcmVhdGUgYSBmYWxzZSBzZW5zZSBvZiBjb21wcmVoZW5zaXZlbmVzcywgYW5k IGp1c3QgZnVydGhlciBkZWxheSBiZWluZyBkb25lLjxicj4NCg0KPGJyPg0KU28geWVhaCwgdW5s ZXNzIHlvdSBjYW4gcHJvdmUgdGhhdCB0aGVyZSBpcyBhbiBhY3R1YWwgcHJvYmxlbSwgd2UgYXJl IGRvbmUuPGJyPg0KPGZvbnQgY29sb3I9IiM4ODg4ODgiPjxicj4NCkVITDxicj4NCjwvZm9udD48 ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPjxicj4NCk9uIFNlcCA2LCAyMDExLCBhdCAx NToyMiwgIk1lbGluZGEgU2hvcmUiICZsdDs8YSBocmVmPSJtYWlsdG86bWVsaW5kYS5zaG9yZUBn bWFpbC5jb20iPjxhIGhyZWY9Im1haWx0bzptZWxpbmRhLnNob3JlQGdtYWlsLmNvbSI+bWVsaW5k YS5zaG9yZUBnbWFpbC5jb208L2E+PC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBPbiAw OS8wNi8yMDExIDEyOjU5IFBNLCBKb2huIEtlbXAgd3JvdGU6PGJyPg0KJmd0OyZndDsgVGhlIHBv aW50IGlzIHRoYXQgeW91IGhhdmUgYSBwb2ludC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBIZSBkb2Vz LCBhbmQgdGhhdCdzIGluIHNvbWUgbGFyZ2UgcGFydCB3aHkgSSBkb24ndDxicj4NCiZndDsgZnVs bHkgdW5kZXJzdGFuZCB0aGUgdGVtcGVyYXR1cmUgb2YgdGhlIHJlc3BvbnNlcy48YnI+DQomZ3Q7 IEkgZG8gbm90IHRoaW5rIGl0J3MgYSBwYXJ0aWN1bGFybHkgYmlnIGRlYWwgdG8gc3RpY2s8YnI+ DQomZ3Q7IGEgY291cGxlIG9mIHNlbnRlbmNlcyBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnM8YnI+DQomZ3Q7IHVuZGVyc2NvcmluZyB0aGUgZmFjdCB0aGF0IE9BVVRIIGNhbid0IGRvIGFu eXRoaW5nPGJyPg0KJmd0OyBhYm91dCBhIGNvbXByb21pc2VkIGhvc3Qgb3IgYSBtYWxpY2lvdXMg YXBwbGljYXRpb24uPGJyPg0KJmd0OyBJJ3ZlIGxlYXJuZWQgdG8gbGl2ZSB3aXRoIHRoZSBmYWN0 IHRoYXQgc29tZXRpbWVzPGJyPg0KJmd0OyBwZW9wbGUgaW1wbGVtZW50aW5nIG9yIGRlcGxveWlu ZyBzZWN1cml0eSB0ZWNobm9sb2dpZXM8YnI+DQomZ3Q7IGRvbid0IGZ1bGx5IHVuZGVyc3RhbmQg dGhlbSBhbmQgaXQncyBteSBpbXByZXNzaW9uIHRoYXQ8YnI+DQomZ3Q7IHRoZXJlJ3Mgc29tZSBu dW1iZXIgb2YgcGVvcGxlIG91dCB0aGVyZSB3aG8gdGhpbmsgdGhhdDxicj4NCiZndDsgT0FVVEgg YW5kIG90aGVyIHRoaXJkLXBhcnR5IHByb3RvY29scyBwcm92aWRlIHN1ZmZpY2llbnQ8YnI+DQom Z3Q7IHByb3RlY3Rpb24gYWdhaW5zdCBwYXNzd29yZCBzbmFnZ2luZy48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBNZWxpbmRhPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9hPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L2E+PGJyPg0KPC9k aXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxi cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+TmV2ZXIgc2VuZCBzZW5zaXRpdmUgb3IgcHJpdmF0ZSBpbmZvcm1hdGlv biB2aWEgZW1haWwgdW5sZXNzIGl0IGlzIGVuY3J5cHRlZC4gPGEgaHJlZj0iaHR0cDovL3d3dy5n bnVwZy5vcmciPjxhIGhyZWY9Imh0dHA6Ly93d3cuZ251cGcub3JnIj5odHRwOi8vd3d3LmdudXBn Lm9yZzwvYT48L2E+PGJyPg0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --_000_0D97252949A44762B2D35922F9EB444Ehueniversecom_-- From mike@mtcc.com Tue Sep 6 17:07: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 CE4A321F8DEC for ; Tue, 6 Sep 2011 17:07:18 -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 BYakbZu6dAXP for ; Tue, 6 Sep 2011 17:07:18 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 30AC021F8DEE for ; Tue, 6 Sep 2011 17:07:18 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87094x3020496 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 17:09:05 -0700 Message-ID: <4E66B620.9020604@mtcc.com> Date: Tue, 06 Sep 2011 17:09:04 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: John Kemp References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1068; t=1315354146; x=1316218146; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20John=20Kemp=20 |Content-Type:=20text/plain=3B=20charset=3Dwindows-1252=3B= 20format=3Dflowed |Content-Transfer-Encoding:=208bit |MIME-Version:=201.0; bh=Wa13IINnf8wyFiAxYkSMmiN815w3DjwIA3hTpAIoXRk=; b=Khhyqi0J75N2MpNZZRFaFyWd7QKlBwEKxa9bhmiwkkxsrFbYiR4l3zjv3p PKwDmI/21VXBGIQKNqeqoQv1EfjIeSV9s/ZHMFZSkIOU9rL44nr6/LQcEFt8 BzsMls1f7/uca/UV1QDYOJF/4ocxXjgdD0l+5gwJXS5FZGJiB1bUo=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: OAuth WG Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 00:07:18 -0000 On 09/06/2011 01:59 PM, John Kemp wrote: > On Sep 6, 2011, at 4:36 PM, Michael Thomas wrote: > > […] > > >> But even if you did it once, how did you know that you didn't reveal your credentials >> to a bad guy? >> >> And I'm being told that this isn't even worthy of any mention anywhere? I came >> here hoping to hear that the attack wasn't possible, or could be mitigated. >> > The attack can be mitigated, but it cannot be prevented through protocols like OAuth (or any other protocol that I know of) alone. > Even mitigation would be a big improvement, especially mitigation on the server side which has access to better resources to find and toss out bad guys. If you know of some, I for one would be interested in hearing about it. Mike > The point is that you have a point. > > But OAuth alone cannot address your point - it provides a different -- and still useful, mitigation for attacks on user credentials sent over a network. It's not a superhero though. > > - John > > >> Zoicks. >> >> Mike >> From eran@hueniverse.com Tue Sep 6 17: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 8F14421F8DFA for ; Tue, 6 Sep 2011 17:07:35 -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 hd-82epB22a7 for ; Tue, 6 Sep 2011 17:07: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 067B121F8DF7 for ; Tue, 6 Sep 2011 17:07:35 -0700 (PDT) Received: (qmail 15904 invoked from network); 7 Sep 2011 00:09:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 00:09:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 6 Sep 2011 17:09:22 -0700 From: Eran Hammer-Lahav To: Michael Thomas Date: Tue, 6 Sep 2011 17:09:15 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: Acxs8mU0ffDMPy2vRWOI3Vodp8uEaA== Message-ID: <04958686-64CE-46C5-B095-F70BE7225BAA@hueniverse.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E66B53A.9030609@mtcc.com> In-Reply-To: <4E66B53A.9030609@mtcc.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 00:07:35 -0000 Wg consensus is clearly to do nothing here.=20 EHL On Sep 6, 2011, at 17:05, "Michael Thomas" wrote: > On 09/06/2011 03:27 PM, Eran Hammer-Lahav wrote: >> So yeah, unless you can prove that there is an actual problem, we are do= ne. >>=20 >=20 > I will point out that the chairs make that determination based on > working group consensus, not the document editor. >=20 > Mike From melinda.shore@gmail.com Tue Sep 6 17:11: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 ACCF221F8CF5 for ; Tue, 6 Sep 2011 17:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 XPqsJ33bFsJT for ; Tue, 6 Sep 2011 17:11:38 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 36AA321F8CE4 for ; Tue, 6 Sep 2011 17:11:38 -0700 (PDT) Received: by pzk33 with SMTP id 33so17307618pzk.18 for ; Tue, 06 Sep 2011 17:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aCBChLoHWxYoEHKGo4pZZTwN0ef89BEMY+4AxqwwRMM=; b=RELSKZkQ+pJ0CF0LUGYE637V8UrJpJIpWy3AU5LG1JXJUYHPL7zrtwcovtz7V67AMn Tc17GAeOgXvkNInRaPVwdkJ4nmLvlNHmDcs1unXMRArgQAHzxkR3xRsLVI2c5ssUNHcD T8jE2YPQsy1n+mzq96C9pQ3kPnvO7/kCkXeZw= Received: by 10.68.33.98 with SMTP id q2mr10952323pbi.449.1315354405903; Tue, 06 Sep 2011 17:13:25 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu. [137.229.12.236]) by mx.google.com with ESMTPS id e8sm735217pbc.8.2011.09.06.17.13.23 (version=SSLv3 cipher=OTHER); Tue, 06 Sep 2011 17:13:24 -0700 (PDT) Message-ID: <4E66B72D.9070207@gmail.com> Date: Tue, 06 Sep 2011 16:13:33 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E66B53A.9030609@mtcc.com> <04958686-64CE-46C5-B095-F70BE7225BAA@hueniverse.com> In-Reply-To: <04958686-64CE-46C5-B095-F70BE7225BAA@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 00:11:38 -0000 On 09/06/2011 04:09 PM, Eran Hammer-Lahav wrote: > Wg consensus is clearly to do nothing here. ?? No, it clearly is not, unless you're laboring under the misconception that "consensus" means "voting." At any rate the job of calling consensus *explicitly* belongs to working group chairs, not editors. Melinda From mike@mtcc.com Tue Sep 6 17:14: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 0192521F8D97 for ; Tue, 6 Sep 2011 17:14:07 -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 VD22PZ+X225y for ; Tue, 6 Sep 2011 17:14:06 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54821F8CB1 for ; Tue, 6 Sep 2011 17:14:06 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p870FoTr022796 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 17:15:51 -0700 Message-ID: <4E66B7B6.6080305@mtcc.com> Date: Tue, 06 Sep 2011 17:15:50 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E66B53A.9030609@mtcc.com> <04958686-64CE-46C5-B095-F70BE7225BAA@hueniverse.com> In-Reply-To: <04958686-64CE-46C5-B095-F70BE7225BAA@hueniverse.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=669; t=1315354551; x=1316218551; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=2E3J2DPqvYtIxXPMRoMyhJ3IYfzA222yje1iQ/Ccfzk=; b=sNLYQ3R/SUVEPQTUpuc6i6B85GAQcMsm1p8fTajZa1j2nEleaqxajLGtCS 3PBcQWTzMgWEL1/TzcwAcY2oMMj/XCnSdtfeHku0IJGoVlZ/A2n8h+ls5iQi Dlv1FHW0rXoyLCMw1YF1vxr1w5kir9Y2AOj0BDG8YtdLa8mq3jXew=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 00:14:07 -0000 On 09/06/2011 05:09 PM, Eran Hammer-Lahav wrote: > Wg consensus is clearly to do nothing here. > Perhaps you are new to IETF process, but your job is to put into the document what the chairs call as consensus. Even if you disagree. Even vehemently. Mike > EHL > > On Sep 6, 2011, at 17:05, "Michael Thomas" wrote: > > >> On 09/06/2011 03:27 PM, Eran Hammer-Lahav wrote: >> >>> So yeah, unless you can prove that there is an actual problem, we are done. >>> >>> >> I will point out that the chairs make that determination based on >> working group consensus, not the document editor. >> >> Mike >> From eran@hueniverse.com Tue Sep 6 17:19: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 BCADF21F8D03 for ; Tue, 6 Sep 2011 17:19:54 -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 4UTzQoIRqX8e for ; Tue, 6 Sep 2011 17:19:54 -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 47AA021F8CF3 for ; Tue, 6 Sep 2011 17:19:54 -0700 (PDT) Received: (qmail 2340 invoked from network); 7 Sep 2011 00:21:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 00:21:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 6 Sep 2011 17:21:36 -0700 From: Eran Hammer-Lahav To: Melinda Shore Date: Tue, 6 Sep 2011 17:21:28 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: Acxs9BpIGNinp8nkRjivt3v/uEP9wg== Message-ID: <31B64F7F-5BDD-445A-8456-8EE04D21D078@hueniverse.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E66B53A.9030609@mtcc.com> <04958686-64CE-46C5-B095-F70BE7225BAA@hueniverse.com> <4E66B72D.9070207@gmail.com> In-Reply-To: <4E66B72D.9070207@gmail.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 00:19:54 -0000 The chairs have the final say, not a monopoly on making observations. The e= ditor role *is* to distill wg discussion onto proposed changes. So saying I= have no intention on making changes is clearly within my authority and the= chair have the right to override that call.=20 EHL On Sep 6, 2011, at 17:13, "Melinda Shore" wrote: > On 09/06/2011 04:09 PM, Eran Hammer-Lahav wrote: >> Wg consensus is clearly to do nothing here. >=20 > ?? No, it clearly is not, unless you're laboring > under the misconception that "consensus" means "voting." > At any rate the job of calling consensus *explicitly* > belongs to working group chairs, not editors. >=20 > Melinda From stpeter@stpeter.im Tue Sep 6 17:21: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 52E1421F8D2F for ; Tue, 6 Sep 2011 17:21:18 -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 EWGz8c1oOhNn for ; Tue, 6 Sep 2011 17:21:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEC821F8ABE for ; Tue, 6 Sep 2011 17:21:14 -0700 (PDT) Received: from squire.local (unknown [216.17.251.17]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 77746418BB; Tue, 6 Sep 2011 18:25:56 -0600 (MDT) Message-ID: <4E66B964.2060808@stpeter.im> Date: Tue, 06 Sep 2011 18:23:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Melinda Shore References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> In-Reply-To: <4E669D3C.5000900@gmail.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] problem statement 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, 07 Sep 2011 00:21:18 -0000 On 9/6/11 4:22 PM, Melinda Shore wrote: > On 09/06/2011 12:59 PM, John Kemp wrote: >> The point is that you have a point. > > He does, and that's in some large part why I don't > fully understand the temperature of the responses. > I do not think it's a particularly big deal to stick > a couple of sentences in the security considerations > underscoring the fact that OAUTH can't do anything > about a compromised host or a malicious application. > I've learned to live with the fact that sometimes > people implementing or deploying security technologies > don't fully understand them and it's my impression that > there's some number of people out there who think that > OAUTH and other third-party protocols provide sufficient > protection against password snagging. I just looked at the most recent specifications for TLS (RFC 5246) and secure shell (RFC 4253), which I think we'd all agree are two quite successful security technologies. Neither of those specs says anything about not protecting humans users from malicious clients that perform keylogging to capture security-critical data the user might enter. Not only is OAuth "not a superhero" as John Kemp said, but I fail to see why we need to document exactly which superhero powers OAuth lacks (given that it's not reasonable to expect *any* security protocol to have those powers). IMHO this is gilding the documentation lily. Peter -- Peter Saint-Andre https://stpeter.im/ From melinda.shore@gmail.com Tue Sep 6 17:49: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 D896921F8D6F for ; Tue, 6 Sep 2011 17:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 fdLcSCOuqHiL for ; Tue, 6 Sep 2011 17:49:01 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 605E221F8D66 for ; Tue, 6 Sep 2011 17:49:01 -0700 (PDT) Received: by pzk33 with SMTP id 33so17352456pzk.18 for ; Tue, 06 Sep 2011 17:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lnOWJui2t/FPLK0tZS8SPX0K6+1/iasGYGVLN7uo6kc=; b=ojFZrqjf7uTFGnJhcZvtPqVfrt1IMPmN7Gey4QDT/vWNd6cMCyVORmrRd8/pcHGl/Z FQWjWEtBIwViy6NySP+Okh/pnpyorKLaNrg4fFe21mag6q/NMyBB1tk67Xg1w/84LOFh xkB7Yehr88u69XFrG04+EBHivig2h3QltVai4= Received: by 10.68.2.196 with SMTP id 4mr237676pbw.156.1315356649196; Tue, 06 Sep 2011 17:50:49 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu. [137.229.12.236]) by mx.google.com with ESMTPS id jl4sm941445pbc.10.2011.09.06.17.50.47 (version=SSLv3 cipher=OTHER); Tue, 06 Sep 2011 17:50:48 -0700 (PDT) Message-ID: <4E66BFF0.9020008@gmail.com> Date: Tue, 06 Sep 2011 16:50:56 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> In-Reply-To: <4E66B964.2060808@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 00:49:02 -0000 On 09/06/2011 04:23 PM, Peter Saint-Andre wrote: > I just looked at the most recent specifications for TLS (RFC 5246) and > secure shell (RFC 4253), which I think we'd all agree are two quite > successful security technologies. Neither of those specs says anything > about not protecting humans users from malicious clients that perform > keylogging to capture security-critical data the user might enter. I think there's an argument to be made that the user interface is sufficiently different that those might not be a great model. But it's also the case that there have been security problems with both that may or may not have been avoided in part by putting in warnings not to trust every crappy, random CA certificate that wafts by, or not to respond "Sure - thanks!" to every ssh host key you're offered. Melinda From stpeter@stpeter.im Tue Sep 6 18:01: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 4C4F221F86DF for ; Tue, 6 Sep 2011 18:01:24 -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 RVT2BbF+ng9d for ; Tue, 6 Sep 2011 18:01:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A5A3021F86AA for ; Tue, 6 Sep 2011 18:01:23 -0700 (PDT) Received: from squire.local (unknown [216.17.251.17]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5E768418BB; Tue, 6 Sep 2011 19:06:06 -0600 (MDT) Message-ID: <4E66C2CE.5040101@stpeter.im> Date: Tue, 06 Sep 2011 19:03:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Michael Thomas , OAuth WG References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BBD7.1000703@mtcc.com> In-Reply-To: <4E66BBD7.1000703@mtcc.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 Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 01:01:24 -0000 On 9/6/11 6:33 PM, Michael Thomas wrote: > On 09/06/2011 05:23 PM, Peter Saint-Andre wrote: >> On 9/6/11 4:22 PM, Melinda Shore wrote: >> >>> On 09/06/2011 12:59 PM, John Kemp wrote: >>> >>>> The point is that you have a point. >>>> >>> He does, and that's in some large part why I don't >>> fully understand the temperature of the responses. >>> I do not think it's a particularly big deal to stick >>> a couple of sentences in the security considerations >>> underscoring the fact that OAUTH can't do anything >>> about a compromised host or a malicious application. >>> I've learned to live with the fact that sometimes >>> people implementing or deploying security technologies >>> don't fully understand them and it's my impression that >>> there's some number of people out there who think that >>> OAUTH and other third-party protocols provide sufficient >>> protection against password snagging. >>> >> I just looked at the most recent specifications for TLS (RFC 5246) and >> secure shell (RFC 4253), which I think we'd all agree are two quite >> successful security technologies. Neither of those specs says anything >> about not protecting humans users from malicious clients that perform >> keylogging to capture security-critical data the user might enter. Not >> only is OAuth "not a superhero" as John Kemp said, but I fail to see why >> we need to document exactly which superhero powers OAuth lacks (given >> that it's not reasonable to expect *any* security protocol to have those >> powers). IMHO this is gilding the documentation lily. >> > > That is because neither TLS or SSH are trying to allow access > but protect you from a third party that is not necessarily > trustworthy. OAuth is. When the eve literally has access to > the to-be protected data in many cases, that's noteworthy. > That is not the case of either TLS or SSH. TLS and ssh are controlling access to things like my bank account and my VPS. Those are less important than my Flickr photos? Peter -- Peter Saint-Andre https://stpeter.im/ From eran@hueniverse.com Tue Sep 6 18:03: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 2F1D121F8DBA for ; Tue, 6 Sep 2011 18:03: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 pGZ7ItcjEMFu for ; Tue, 6 Sep 2011 18:03:54 -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 BFCA521F8DB7 for ; Tue, 6 Sep 2011 18:03:54 -0700 (PDT) Received: (qmail 537 invoked from network); 7 Sep 2011 01:05:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 01:05:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Sep 2011 18:05:41 -0700 From: Eran Hammer-Lahav To: Melinda Shore Date: Tue, 6 Sep 2011 18:05:34 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: Acxs+kN/rCnmTHhRQu+pvozfCFH1TA== Message-ID: <6CA555E2-D08C-4707-AFB1-8763EE23BF0A@hueniverse.com> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> In-Reply-To: <4E66BFF0.9020008@gmail.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 01:03:56 -0000 What do you think such a warning would accomplish? There are no ways to mit= igate malware (bad client or otherwise), and using passwords make it even e= asier.=20 End users are not going to read the specification and service providers hav= e absolutely no alternatives. As for the example, the issue you described with accepting every CA is comp= letely irrelavent because changing the root certificates will be done in se= crecy by the installed malware.=20 I have not seen any argument showing how such a warming makes any differenc= e in deploying OAuth (or not). Can you propose text and show how it mau affect implementation? EHL On Sep 6, 2011, at 17:50, "Melinda Shore" wrote: > On 09/06/2011 04:23 PM, Peter Saint-Andre wrote: >> I just looked at the most recent specifications for TLS (RFC 5246) and >> secure shell (RFC 4253), which I think we'd all agree are two quite >> successful security technologies. Neither of those specs says anything >> about not protecting humans users from malicious clients that perform >> keylogging to capture security-critical data the user might enter. >=20 > I think there's an argument to be made that the user interface > is sufficiently different that those might not be a great model. > But it's also the case that there have been security problems > with both that may or may not have been avoided in part by > putting in warnings not to trust every crappy, random CA > certificate that wafts by, or not to respond "Sure - thanks!" > to every ssh host key you're offered. >=20 > Melinda > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Tue Sep 6 18:06: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 3A4A121F8B3D for ; Tue, 6 Sep 2011 18:06:44 -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 hQehkpLcd7VB for ; Tue, 6 Sep 2011 18:06:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3E121F8B39 for ; Tue, 6 Sep 2011 18:06:43 -0700 (PDT) Received: from squire.local (unknown [216.17.251.17]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3845D418BB; Tue, 6 Sep 2011 19:11:26 -0600 (MDT) Message-ID: <4E66C407.9090209@stpeter.im> Date: Tue, 06 Sep 2011 19:08:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Melinda Shore References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> In-Reply-To: <4E66BFF0.9020008@gmail.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] problem statement 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, 07 Sep 2011 01:06:44 -0000 On 9/6/11 6:50 PM, Melinda Shore wrote: > On 09/06/2011 04:23 PM, Peter Saint-Andre wrote: >> I just looked at the most recent specifications for TLS (RFC 5246) and >> secure shell (RFC 4253), which I think we'd all agree are two quite >> successful security technologies. Neither of those specs says anything >> about not protecting humans users from malicious clients that perform >> keylogging to capture security-critical data the user might enter. > > I think there's an argument to be made that the user interface > is sufficiently different that those might not be a great model. > But it's also the case that there have been security problems > with both that may or may not have been avoided in part by > putting in warnings not to trust every crappy, random CA > certificate that wafts by, or not to respond "Sure - thanks!" > to every ssh host key you're offered. Put me in the "may not have been avoided" camp. We can't legislate common sense (which, sadly, is all too uncommon). Look, I spent months working on RFC 6125, which has a title too long to quote here but basically spends many dozens of pages defining what it means to check that you're connecting to the right TLS server. That advice at least is something positive that clients can operationalize. Documenting a lack of superhero powers seems like a waste of time to me, but if someone wants to propose a few sentences of text that's up to them. Peter -- Peter Saint-Andre https://stpeter.im/ From mike@mtcc.com Tue Sep 6 18:11: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 443C921F8C00 for ; Tue, 6 Sep 2011 18:11:21 -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 X5JPMzX6nqNf for ; Tue, 6 Sep 2011 18:11:20 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 76E6721F8BF7 for ; Tue, 6 Sep 2011 18:11:20 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p871D5DP009749 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 18:13:05 -0700 Message-ID: <4E66C521.5070804@mtcc.com> Date: Tue, 06 Sep 2011 18:13:05 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> In-Reply-To: <4E66C407.9090209@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=443; t=1315357985; x=1316221985; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Peter=20Saint-Andre=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=tgL12cUtZNSumS4TbORQ9UCJwXU5xPSpNwCS011zxNY=; b=nk8qW7E1/Z+0t4ReABHv7QOA4+RlwcTdLyKpbi5KogA3H8lhTmqbVFWNaR 2HZNQFdmU1NK4DHudhn8TqTixdPSYKehm2oxs9OPsgZCQ3R4xI55LXFF9GDh XPUDcC3bDknng11+Ga33nZ2dVnXeRMMCcGDGxX7xNQ2zybLBjw6KY=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 01:11:21 -0000 On 09/06/2011 06:08 PM, Peter Saint-Andre wrote: > Put me in the "may not have been avoided" camp. We can't legislate > common sense (which, sadly, is all too uncommon). > Can somebody show me in the archives where this has been discussed before? Specifically about oauth clients that also have control of the web UA? In any case, you site this as common sense. It's not. You are close to the problem. Nobody else is. Mike From eran@hueniverse.com Tue Sep 6 18:23: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 AB19621F8D5C for ; Tue, 6 Sep 2011 18:23:06 -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 Y5raKHUFfFeJ for ; Tue, 6 Sep 2011 18:23: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 23C0221F8D56 for ; Tue, 6 Sep 2011 18:23:06 -0700 (PDT) Received: (qmail 26573 invoked from network); 7 Sep 2011 01:24:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 01:24:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 6 Sep 2011 18:24:54 -0700 From: Eran Hammer-Lahav To: Michael Thomas Date: Tue, 6 Sep 2011 18:24:46 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: Acxs/PJaPKy49eoGR5OTmXzHoJKpmg== Message-ID: References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> <4E66C521.5070804@mtcc.com> In-Reply-To: <4E66C521.5070804@mtcc.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 01:23:06 -0000 You clearly feel strongly about this. The only way forward if you want to p= ursue this is to suggest text and show how providing it will lead to more s= ecure implementations. Otherwise this is just going in circles.=20 EHL On Sep 6, 2011, at 18:13, "Michael Thomas" wrote: > On 09/06/2011 06:08 PM, Peter Saint-Andre wrote: >> Put me in the "may not have been avoided" camp. We can't legislate >> common sense (which, sadly, is all too uncommon). >>=20 >=20 > Can somebody show me in the archives where this has been > discussed before? Specifically about oauth clients that also > have control of the web UA? >=20 > In any case, you site this as common sense. It's not. You are > close to the problem. Nobody else is. >=20 > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Tue Sep 6 18:25: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 95F3121F8D5C for ; Tue, 6 Sep 2011 18:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.374 X-Spam-Level: X-Spam-Status: No, score=-17.374 tagged_above=-999 required=5 tests=[AWL=0.224, 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 I0nGjJJ8ZQ3K for ; Tue, 6 Sep 2011 18:25:40 -0700 (PDT) Received: from nm27-vm4.bullet.mail.ne1.yahoo.com (nm27-vm4.bullet.mail.ne1.yahoo.com [98.138.91.187]) by ietfa.amsl.com (Postfix) with SMTP id 8235121F8D56 for ; Tue, 6 Sep 2011 18:25:40 -0700 (PDT) Received: from [98.138.90.50] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 07 Sep 2011 01:27:28 -0000 Received: from [98.138.88.237] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 07 Sep 2011 01:27:28 -0000 Received: from [127.0.0.1] by omp1037.mail.ne1.yahoo.com with NNFMP; 07 Sep 2011 01:27:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 188185.27879.bm@omp1037.mail.ne1.yahoo.com Received: (qmail 27197 invoked by uid 60001); 7 Sep 2011 01:27:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1315358847; bh=XiGI7SgQJyAYDoQj6juCX8zwS11HCcdORTuu18wgGm4=; 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=IVQR7nBRFiw8vfm5Di3JCkIb2PyKfY1cHwlPdpJLn2dtsGp0XYKeZi6IOetACHMVo8T/HrwphPKfLW2EtoADROzDHZE5f32mW1BApJu/fwXiCR2uGLuIVmCOveOkQEMkO6U1aVBU7AmuPzGpRxiC6XZiIUeNRtM+6x/Tf2R4bxw= 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=LOpX6+I5SpS81Wbr+ffpZyz1klarADJiXyp2dQahWLTCa8F8LAkl3fnHytYnhWc9ERm0Uw/ogG2XIIkjlm8FQxiPaH2IA9OKXbV2eeJocvckhM9Zn1f1Q3koX4VNMOiq77ujJh5lXIfgs2W54qiaLySwbv4M/Dp6uqGoeWEcp3g=; X-YMail-OSG: nvVcKokVM1nMob2Jpee1hJAPNV4vHGmcdZYYkodrPjj8SbC svPFTETcgaVMrVw_BqO50B26mYlbT7Yg6VK4tlD_8PXo6ehNSSd89irQBacs 6ZMcRK_9jE.T.Htd4X1G6DCK0gUT11HE58N0VJilE90VraAZkByufSZdo_8W _pZt9CEmtcIufHnoAZnTY7ofwnJTwFdx0GcVQIf1DwTjeeDkvYBmepyJrg02 Jv63b7c415.iV_G0tUkSDPN3y_41PsEGd2iSKTkoGHcggG0kQDMBs4CCAvQM YD0DC3qsjTK5ogYBJ9h9nOo3dGdAZK4.4Kq0yza941a7YJSo03jlrFTy0fnH jFsqScSIPM0M3TnNo44FhcVl4mmISwKE8kjP9av0k4YpbArzTr.8yc64HQJd 2p3SLDXlnL.uBu_xgY44u0O59KUJkWEmhjzCDzSe1CA-- Received: from [209.131.62.113] by web31809.mail.mud.yahoo.com via HTTP; Tue, 06 Sep 2011 18:27:27 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.114.317681 References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> <4E66C521.5070804@mtcc.com> Message-ID: <1315358847.25169.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Tue, 6 Sep 2011 18:27:27 -0700 (PDT) From: William Mills To: Michael Thomas , Peter Saint-Andre In-Reply-To: <4E66C521.5070804@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1781685922-1315358847=:25169" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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: Wed, 07 Sep 2011 01:25:41 -0000 --0-1781685922-1315358847=:25169 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I think the only potential mitigation OAuth can offer is that the authentic= ating sites can do more due dilligence about the clients they allow.=A0 I s= ay this knowing that it's not likely to happen in most cases, but it's poss= ible.=A0 Sites *can* limit the clients they allow, *but* it doesn't really = work for installed clients on the desktop, software copy protection being t= he hard problem that it has proved to be.=0A=0ANobody dismisses the problem= you're talking about, it's definitely a problem.=A0 What you have not do i= s provided any concrete way in which OAuth can mitigate it beyond it's pres= ent state.=0A=0AI personally want OAuth 2.0 to get out the door.=A0 What yo= u seem to be asking for (if we really go there) is a far more comprehensive= and general security considerations section that's goign to cover a huge s= wath of space not specific to OAuth.=A0 I don't think what you're asking fo= r is specific to OAuth, so I don't think it's appropriate to take this spec= there.=0A=0AIf you really think you've got something here, draft language = and propose it.=A0 That takes this from the theory of the problem to specif= ics.=A0 It's got to be concrete though and actionable.=A0 The recent discus= sions around CSRF identified a problem of CSRF in the auth server, and the = new language addresses that in an actionable way.=0A=0A=0A=0A______________= __________________=0AFrom: Michael Thomas =0ATo: Peter Saint= -Andre =0ACc: oauth@ietf.org=0ASent: Tuesday, September= 6, 2011 6:13 PM=0ASubject: Re: [OAUTH-WG] problem statement=0A=0AOn 09/06/= 2011 06:08 PM, Peter Saint-Andre wrote:=0A> Put me in the "may not have bee= n avoided" camp. We can't legislate=0A> common sense (which, sadly, is all = too uncommon).=0A>=A0 =A0 =0A=0ACan somebody show me in the archives where = this has been=0Adiscussed before? Specifically about oauth clients that als= o=0Ahave control of the web UA?=0A=0AIn any case, you site this as common s= ense. It's not. You are=0Aclose to the problem. Nobody else is.=0A=0AMike= =0A_______________________________________________=0AOAuth mailing list=0AO= Auth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth --0-1781685922-1315358847=:25169 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I think the only potential mitigation OAuth can offer is that the authent= icating sites can do more due dilligence about the clients they allow. = ; I say this knowing that it's not likely to happen in most cases, but it's= possible.  Sites *can* limit the clients they allow, *but* it doesn't= really work for installed clients on the desktop, software copy protection= being the hard problem that it has proved to be.

Nobody dismisses the problem you're talking about= , it's definitely a problem.  What you have not do is provided any con= crete way in which OAuth can mitigate it beyond it's present state.<= /div>

I personally want OAuth 2.0 to = get out the door.  What you seem to be asking for (if we really go there) is a far more comprehensive and general security considerations = section that's goign to cover a huge swath of space not specific to OAuth.&= nbsp; I don't think what you're asking for is specific to OAuth, so I don't= think it's appropriate to take this spec there.

If you really think you've got something here, dra= ft language and propose it.  That takes this from the theory of the pr= oblem to specifics.  It's got to be concrete though and actionable.&nb= sp; The recent discussions around CSRF identified a problem of CSRF in the = auth server, and the new language addresses that in an actionable way.
<= /span>

From: Michael Thomas <mike@mtcc.= com>
To: Peter Saint= -Andre <stpeter@stpeter.im>
= Cc: oauth@ietf.org
Sent= : Tuesday, September 6, 2011 6:13 PM
Subject: Re: [OAUTH-WG] problem statement

On 09/06/2011 06:08 PM, Peter Saint-Andre wrote:
> Put me in th= e "may not have been avoided" camp. We can't legislate
> common sense= (which, sadly, is all too uncommon).
>   

Can some= body show me in the archives where this has been
discussed before? Speci= fically about oauth clients that also
have control of the web UA?
In any case, you site this as common sense. It's not. You are
close to = the problem. Nobody else is.

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


--0-1781685922-1315358847=:25169-- From mike@mtcc.com Tue Sep 6 18:26: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 F2A5821F8C89 for ; Tue, 6 Sep 2011 18:26:05 -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 sVsTUU4ShtcG for ; Tue, 6 Sep 2011 18:26:05 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA0F21F8E03 for ; Tue, 6 Sep 2011 18:26:05 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p871Rpqp014708 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 18:27:52 -0700 Message-ID: <4E66C897.703@mtcc.com> Date: Tue, 06 Sep 2011 18:27:51 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> <4E66C521.5070804@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=488; t=1315358872; x=1316222872; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ZD1EOIh2yoQFHqbSgDhs9CnDAM9FlV36HX96fb8weGw=; b=UZggSLO+DJFfOzsMjSg//POd4t9JAbK12X/hkBkf3DRBAZX+FEgGtuY5HJ L/l07qp62GmuQPDsbyK1h4nxVs1y446jYKrEj5FB6IGD3hGsv7htUjyYXPZH ezmZWC27vf6eu3D3U2tz7wigO4e5GIXIr0O2PPl5HhD/Vjl8+4EdM=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 01:26:06 -0000 On 09/06/2011 06:24 PM, Eran Hammer-Lahav wrote: > You clearly feel strongly about this. The only way forward if you want to pursue this is to suggest text and show how providing it will lead to more secure implementations. Otherwise this is just going in circles. > Didn't you just get done announcing how you weren't going to do anything under any circumstances unless you were forced to by the chairs? I think I'll wait for them to chime in before I waste my time. Mike From eran@hueniverse.com Tue Sep 6 18:34: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 B441821F8DC8 for ; Tue, 6 Sep 2011 18:34:54 -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 rLhOMiEUvWVg for ; Tue, 6 Sep 2011 18:34:54 -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 4545A21F8DC5 for ; Tue, 6 Sep 2011 18:34:54 -0700 (PDT) Received: (qmail 28434 invoked from network); 7 Sep 2011 01:36:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 01:36:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 6 Sep 2011 18:36:42 -0700 From: Eran Hammer-Lahav To: Michael Thomas Date: Tue, 6 Sep 2011 18:36:35 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: Acxs/phTBunCH+5ARXiEhTuW2h1K3g== Message-ID: <7A070C60-14E3-46B0-95DD-BC9335EF6D10@hueniverse.com> References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> <4E66C521.5070804@mtcc.com> <4E66C897.703@mtcc.com> In-Reply-To: <4E66C897.703@mtcc.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 01:34:54 -0000 *I* am not going to do anything to move this forward which means nothing wi= ll happen unless someone propose text. Even the chairs can't instruct the e= ditor to produce new prose. All the chairs are going to do is give you the same answer. If you want the= wg to consider anything at this point you must provide text. In fact, they= already issued this clear instructions.=20 Now, the overwhelming resistance to such a change would make *me* reconside= r spending my time on this of I was in your position, but proposing text is= the only advise the chairs can offer you at this point.=20 If you think you can offer text that will win wg consensus you should. Argu= ing with me as a participant is, unfortunately, part of the deal.=20 EHL On Sep 6, 2011, at 18:27, "Michael Thomas" wrote: > On 09/06/2011 06:24 PM, Eran Hammer-Lahav wrote: >> You clearly feel strongly about this. The only way forward if you want t= o pursue this is to suggest text and show how providing it will lead to mor= e secure implementations. Otherwise this is just going in circles. >>=20 >=20 > Didn't you just get done announcing how you weren't going to do anything > under any circumstances unless you were forced to by the chairs? I think > I'll wait for them to chime in before I waste my time. >=20 > Mike From mike@mtcc.com Tue Sep 6 18:56: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 5D20921F8E4B for ; Tue, 6 Sep 2011 18:56:00 -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 VuAH8w9+U04b for ; Tue, 6 Sep 2011 18:55:59 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id A485C21F8E53 for ; Tue, 6 Sep 2011 18:55:59 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p871vkx0024515 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Sep 2011 18:57:46 -0700 Message-ID: <4E66CF9A.8000905@mtcc.com> Date: Tue, 06 Sep 2011 18:57:46 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: William Mills References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> <4E66C521.5070804@mtcc.com> <1315358847.25169.YahooMailNeo@web31809.mail.mud.yahoo.com> In-Reply-To: <1315358847.25169.YahooMailNeo@web31809.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2557; t=1315360667; x=1316224667; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20William=20Mills=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=vh45YxbmDbVRsOqCC69q6ZJLXEbfhZ5OqY4VsaIR+2s=; b=enhvbIIUdreqLrk4jzcm4OY2omzse+7nIcptUpIOk20uewghqA8ZTTs/+s 435KyeCxXtnsgjqKL2feAc7F8z5EBSHNF055LMKkauWnCtPcGTz4BdfrfM2X mwP1Bs2Cl5996vdhc1FnNs5GtcI1OWxUtID6UiO0eth0McRvwAAEU=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 01:56:00 -0000 On 09/06/2011 06:27 PM, William Mills wrote: > I think the only potential mitigation OAuth can offer is that the > authenticating sites can do more due dilligence about the clients they > allow. I say this knowing that it's not likely to happen in most > cases, but it's possible. Sites *can* limit the clients they allow, > *but* it doesn't really work for installed clients on the desktop, > software copy protection being the hard problem that it has proved to be. Yeah, I agree that it would be hard for the authenticating side to do much, mainly because it's hard for them to tell if the app is doing something untoward. I wonder if triggering DOM keypress events gets propagated up to external webview code and you could set some honeypots or steganography... hmm. I'm sorry but I'm still very new to thinking about this problem space. > > Nobody dismisses the problem you're talking about, it's definitely a > problem. What you have not do is provided any concrete way in which > OAuth can mitigate it beyond it's present state. At this point, it would be just nice for the industry to know that the issue even *exists*. Hence my puzzlement at the overt hostility from some quarters. > > I personally want OAuth 2.0 to get out the door. What you seem to be > asking for (if we really go there) is a far more comprehensive and > general security considerations section that's goign to cover a huge > swath of space not specific to OAuth. I don't think what you're > asking for is specific to OAuth, so I don't think it's appropriate to > take this spec there. I have no dog in this race. I was just very puzzled by the lack of discussion about the lack of applicability of the protocol in either the protocol document or in the threats. It made me wonder whether this scenario had even been considered. I'm still not sure if it had been. > If you really think you've got something here, draft language and > propose it. That takes this from the theory of the problem to > specifics. It's got to be concrete though and actionable. The recent > discussions around CSRF identified a problem of CSRF in the auth > server, and the new language addresses that in an actionable way. > Like I said in my first message: the documents lack any clear description of the problem they are trying to address, any implicit assumptions about the trust of the various elements, and the applicability of the protocol. That should be part of the abstract and introduction, IMO. Mike From phil.hunt@oracle.com Tue Sep 6 20:41: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 7B14621F8D9E for ; Tue, 6 Sep 2011 20:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.157 X-Spam-Level: X-Spam-Status: No, score=-5.157 tagged_above=-999 required=5 tests=[AWL=1.442, 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 BsGGT2lYY8fX for ; Tue, 6 Sep 2011 20:41:01 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id D380021F8DB7 for ; Tue, 6 Sep 2011 20:41:00 -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 p873gj1R030302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 03:42:47 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p873ghw8025491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 03:42:44 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p873garL002917; Tue, 6 Sep 2011 22:42:36 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 20:42:36 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 6 Sep 2011 20:42:38 -0700 Content-Transfer-Encoding: quoted-printable 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> <1314299478.57208.YahooMailNeo@web31812.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D8@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.0A090209.4E66E838.0026,ss=1,re=-2.300,fgs=0 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 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 03:41:02 -0000 Eran, Just took a look at the text. This new version looks much improved. I = think this is a good compromise. Thanks, Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-09-04, at 4:25 PM, Eran Hammer-Lahav wrote: > The corresponding 'state' parameter definition: >=20 > RECOMMENDED. 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 parameter SHOULD be = used for preventing > cross-site request forgery as described in section = 10.12. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Eran Hammer-Lahav >> Sent: Sunday, September 04, 2011 4:20 PM >> To: William J. Mills; Anthony Nadalin; Torsten Lodderstedt >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>=20 >> This is my proposed text for -21 (based on Bill's text as a starting = point): >>=20 >> 10.12. Cross-Site Request Forgery >>=20 >> Cross-site request forgery (CSRF) is an exploit in which an = attacker >> causes the user-agent of a victim end-user to follow a malicious = URI >> (e.g. provided to the user-agent as a misleading link, image, or >> redirection) to a trusting server (usually established via the >> presence of a valid session cookie). >>=20 >> A CSRF attack against the client's redirection URI allows 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 protected resources rather than the victim's (e.g. save >> the victim's bank account information to a protected resource >> controlled by the attacker). >>=20 >> The client MUST implement CSRF protection for its redirection URI. >> This is typically accomplished by requiring any request sent to the >> redirection URI endpoint to include a value that binds the request = to >> the user-agent's authenticated state (e.g. a hash of the session >> cookie used to authentication the user-agent). The client SHOULD >> utilize the "state" request parameter to deliver this value to the >> authorization server when making an authorization request. >>=20 >> Once authorization has been obtained from the end-user, the >> authorization server redirects the end-user's user-agent back to = the >> client with the required binding value contained in the "state" >> parameter. The binding value enables the client to validate the >> validity of the request by matching the binding value to the user- >> agent's authenticated state. The binding value used for CSRF >> protection MUST contain a non-guessable value, and the user-agent's >> authenticated state (e.g. session cookie, HTML5 local storage) MUST >> be kept in a location accessible only to the client and the user- >> agent (i.e., protected by same-origin policy). >>=20 >> A CSRF attack against the against the authorization server's >> authorization endpoint can result in an attacker obtaining end-user >> authorization for a malicious client without involving or alerting >> the end-user. >>=20 >> The authorization server MUST implement CSRF protection for its >> authorization endpoint, and ensure that a malicious client cannot >> obtain authorization without the awareness and explicit consent of >> the resource owner. >>=20 >> EHL >>=20 >>=20 >> From: William J. Mills [mailto:wmills@yahoo-inc.com] >> Sent: Thursday, August 25, 2011 12:11 PM >> To: Anthony Nadalin; Eran Hammer-Lahav; Torsten Lodderstedt >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>=20 >> I had proposed text, and I'll reprise it here with a modification to = make the >> authorizaton server related explicit. >>=20 >> 10.12. Cross-Site Request Forgery >>=20 >> Cross-site request forgery (CSRF) is 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 user-agent the server trusts or has = authenticated. >> The most commonly exploited mechanism for this is credentials held in >> cookies automatically presented by a web browser. CSRF attacks = against the >> client's redirection URI allow 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 rather than the victim's. = CSRF attacks >> are also possible against an authorization endpoint resulting in = delivering a >> user credential to an attacker. >>=20 >> Client applications MUST implement CSRF protection for the = redirection >> URI. CSRF protection for a request is data included in the request = that ties >> that request to the user's authenticated state, i.e. a cryptographic = signature >> of the user credential and the redirection URI path. Upon receipt of = a >> request the client application computes the CSRF data based on the >> presented credential and compares that to the CSRF protection data >> presented in the request. CSRF protection data MUST contain a non- >> guessable value, 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). = The >> "state" redirection URI parameter is provided as one method of = carrying >> CSRF protection data, and is RECOMMENDED to provide the greatest >> compatibility with systems implementing strong redirection URI = validation. >>=20 >> Authorization servers MUST implement CSRF protection for = authorization >> requests, use of the "state" parameter is RECOMMENDED as the way to >> transmit the CSRF protection data. The CSRF protection data MUST = contain a >> non-guessable value, and MUST be presented as part of the = authorization >> request data (e.g. not as a cookie). Authorization servers MAY use = proof of >> previous authorization by a user for a client in lieu of explicit = CSRF protection. >>=20 >> 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 which = MUST >> then validate the received value against the stored value, or by = recomputing >> the expected value of the CSRF protection data and comparing that to = the >> value presented. >>=20 >>=20 >>=20 >> ________________________________________ >> From: Anthony Nadalin >> To: Eran Hammer-Lahav ; Torsten Lodderstedt >> >> Cc: "OAuth WG (oauth@ietf.org)" >> Sent: Thursday, August 25, 2011 8:11 AM >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack 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] >> 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] >> 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 >> 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 >> _______________________________________________ >> 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 >> _______________________________________________ >> 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 James.H.Manger@team.telstra.com Tue Sep 6 20:51: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 ABD7021F8DA3 for ; Tue, 6 Sep 2011 20:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[AWL=-2.424, 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 QQjJ-7ZIRI0w for ; Tue, 6 Sep 2011 20:51:15 -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 CFB4221F8D45 for ; Tue, 6 Sep 2011 20:51:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,343,1312120800"; d="scan'208";a="45178623" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 07 Sep 2011 13:52:44 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6461"; a="36340485" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcavi.tcif.telstra.com.au with ESMTP; 07 Sep 2011 13:52:44 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Wed, 7 Sep 2011 13:52:43 +1000 From: "Manger, James H" To: Michael Thomas , "oauth@ietf.org" Date: Wed, 7 Sep 2011 13:52:41 +1000 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: AcxtAZcWUMDKVDxYROayx8MDCxxCCAADppjQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1128DF46CA4@WSMSG3153V.srv.dir.telstra.com> References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> <4E66C521.5070804@mtcc.com> <1315358847.25169.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E66CF9A.8000905@mtcc.com> In-Reply-To: <4E66CF9A.8000905@mtcc.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 03:51:15 -0000 A strange aspects of this thread is that the current draft already talks ab= out exactly this issue: draft-ietf-oauth-v2-21 section 9 "Native Applications" "...Native applications can invoke an external user-agent or embed a user-agent within the application ... Embedded user-agents pose a security challenge because resource owners are authenticating in an unidentified window without access to the visual protections found in most external user-agents. Embedded user-agents educate end-user to trust unidentified requests for authentication (making phishing attacks easier to execute)." The webView that Michael Thomas talks about is an "embedded user-agent". -- James Manger ---------- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ichael Thomas ... At this point, it would be just nice for the industry to know that the issu= e even *exists*. From eran@hueniverse.com Tue Sep 6 20:58: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 C10CA21F8DFA for ; Tue, 6 Sep 2011 20:58:06 -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 ZYKyMUqlrYXX for ; Tue, 6 Sep 2011 20:58:05 -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 58B2721F8DB3 for ; Tue, 6 Sep 2011 20:58:05 -0700 (PDT) Received: (qmail 7169 invoked from network); 7 Sep 2011 03:59:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 03:59:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 6 Sep 2011 20:59:50 -0700 From: Eran Hammer-Lahav To: Phil Hunt Date: Tue, 6 Sep 2011 20:58:24 -0700 Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxtEpgHkl91LYgtR36F7fPWX7/4RA== Message-ID: <89E432D5-6322-44A8-A1AB-DEEADE0FADE4@hueniverse.com> 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> <1314299478.57208.YahooMailNeo@web31812.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D8@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 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 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 03:58:06 -0000 UGVyZmVjdC4gVGhhbmtzIFBoaWwuDQoNCkVITA0KDQpPbiBTZXAgNiwgMjAxMSwgYXQgMjA6NDIs ICJQaGlsIEh1bnQiIDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4gd3JvdGU6DQoNCj4gRXJhbiwNCj4N Cj4gSnVzdCB0b29rIGEgbG9vayBhdCB0aGUgdGV4dC4gVGhpcyBuZXcgdmVyc2lvbiBsb29rcyBt dWNoIGltcHJvdmVkLiBJIHRoaW5rIHRoaXMgaXMgYSBnb29kIGNvbXByb21pc2UuDQo+DQo+IFRo YW5rcywNCj4NCj4gUGhpbA0KPg0KPiBAaW5kZXBlbmRlbnRpZA0KPiB3d3cuaW5kZXBlbmRlbnRp ZC5jb20NCj4gcGhpbC5odW50QG9yYWNsZS5jb20NCj4NCj4NCj4NCj4NCj4NCj4gT24gMjAxMS0w OS0wNCwgYXQgNDoyNSBQTSwgRXJhbiBIYW1tZXItTGFoYXYgd3JvdGU6DQo+DQo+PiBUaGUgY29y cmVzcG9uZGluZyAnc3RhdGUnIHBhcmFtZXRlciBkZWZpbml0aW9uOg0KPj4NCj4+ICAgICAgICAg ICAgICAgUkVDT01NRU5ERUQuIEFuIG9wYXF1ZSB2YWx1ZSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8g bWFpbnRhaW4gc3RhdGUgYmV0d2VlbiB0aGUgcmVxdWVzdA0KPj4gICAgICAgICAgICAgICBhbmQg Y2FsbGJhY2suIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbmNsdWRlcyB0aGlzIHZhbHVlIHdo ZW4gcmVkaXJlY3RpbmcgdGhlDQo+PiAgICAgICAgICAgICAgIHVzZXItYWdlbnQgYmFjayB0byB0 aGUgY2xpZW50LiBUaGUgcGFyYW1ldGVyIFNIT1VMRCBiZSB1c2VkIGZvciBwcmV2ZW50aW5nDQo+ PiAgICAgICAgICAgICAgIGNyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IGFzIGRlc2NyaWJlZCBp biBzZWN0aW9uIDEwLjEyLg0KPj4NCj4+IEVITA0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+PiBPZiBFcmFuIEhhbW1lci1MYWhhdg0KPj4+ IFNlbnQ6IFN1bmRheSwgU2VwdGVtYmVyIDA0LCAyMDExIDQ6MjAgUE0NCj4+PiBUbzogV2lsbGlh bSBKLiBNaWxsczsgQW50aG9ueSBOYWRhbGluOyBUb3JzdGVuIExvZGRlcnN0ZWR0DQo+Pj4gQ2M6 IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBB dXRoIENvZGUgU3dhcCBBdHRhY2sNCj4+Pg0KPj4+IFRoaXMgaXMgbXkgcHJvcG9zZWQgdGV4dCBm b3IgLTIxIChiYXNlZCBvbiBCaWxsJ3MgdGV4dCBhcyBhIHN0YXJ0aW5nIHBvaW50KToNCj4+Pg0K Pj4+IDEwLjEyLiAgQ3Jvc3MtU2l0ZSBSZXF1ZXN0IEZvcmdlcnkNCj4+Pg0KPj4+ICBDcm9zcy1z aXRlIHJlcXVlc3QgZm9yZ2VyeSAoQ1NSRikgaXMgYW4gZXhwbG9pdCBpbiB3aGljaCBhbiBhdHRh Y2tlcg0KPj4+ICBjYXVzZXMgdGhlIHVzZXItYWdlbnQgb2YgYSB2aWN0aW0gZW5kLXVzZXIgdG8g Zm9sbG93IGEgbWFsaWNpb3VzIFVSSQ0KPj4+ICAoZS5nLiBwcm92aWRlZCB0byB0aGUgdXNlci1h Z2VudCBhcyBhIG1pc2xlYWRpbmcgbGluaywgaW1hZ2UsIG9yDQo+Pj4gIHJlZGlyZWN0aW9uKSB0 byBhIHRydXN0aW5nIHNlcnZlciAodXN1YWxseSBlc3RhYmxpc2hlZCB2aWEgdGhlDQo+Pj4gIHBy ZXNlbmNlIG9mIGEgdmFsaWQgc2Vzc2lvbiBjb29raWUpLg0KPj4+DQo+Pj4gIEEgQ1NSRiBhdHRh Y2sgYWdhaW5zdCB0aGUgY2xpZW50J3MgcmVkaXJlY3Rpb24gVVJJIGFsbG93cyBhbiBhdHRhY2tl cg0KPj4+ICB0byBpbmplY3QgdGhlaXIgb3duIGF1dGhvcml6YXRpb24gY29kZSBvciBhY2Nlc3Mg dG9rZW4sIHdoaWNoIGNhbg0KPj4+ICByZXN1bHQgaW4gdGhlIGNsaWVudCB1c2luZyBhbiBhY2Nl c3MgdG9rZW4gYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPj4+ICBhdHRhY2tlcidzIHByb3RlY3RlZCBy ZXNvdXJjZXMgcmF0aGVyIHRoYW4gdGhlIHZpY3RpbSdzIChlLmcuIHNhdmUNCj4+PiAgdGhlIHZp Y3RpbSdzIGJhbmsgYWNjb3VudCBpbmZvcm1hdGlvbiB0byBhIHByb3RlY3RlZCByZXNvdXJjZQ0K Pj4+ICBjb250cm9sbGVkIGJ5IHRoZSBhdHRhY2tlcikuDQo+Pj4NCj4+PiAgVGhlIGNsaWVudCBN VVNUIGltcGxlbWVudCBDU1JGIHByb3RlY3Rpb24gZm9yIGl0cyByZWRpcmVjdGlvbiBVUkkuDQo+ Pj4gIFRoaXMgaXMgdHlwaWNhbGx5IGFjY29tcGxpc2hlZCBieSByZXF1aXJpbmcgYW55IHJlcXVl c3Qgc2VudCB0byB0aGUNCj4+PiAgcmVkaXJlY3Rpb24gVVJJIGVuZHBvaW50IHRvIGluY2x1ZGUg YSB2YWx1ZSB0aGF0IGJpbmRzIHRoZSByZXF1ZXN0IHRvDQo+Pj4gIHRoZSB1c2VyLWFnZW50J3Mg YXV0aGVudGljYXRlZCBzdGF0ZSAoZS5nLiBhIGhhc2ggb2YgdGhlIHNlc3Npb24NCj4+PiAgY29v a2llIHVzZWQgdG8gYXV0aGVudGljYXRpb24gdGhlIHVzZXItYWdlbnQpLiAgVGhlIGNsaWVudCBT SE9VTEQNCj4+PiAgdXRpbGl6ZSB0aGUgInN0YXRlIiByZXF1ZXN0IHBhcmFtZXRlciB0byBkZWxp dmVyIHRoaXMgdmFsdWUgdG8gdGhlDQo+Pj4gIGF1dGhvcml6YXRpb24gc2VydmVyIHdoZW4gbWFr aW5nIGFuIGF1dGhvcml6YXRpb24gcmVxdWVzdC4NCj4+Pg0KPj4+ICBPbmNlIGF1dGhvcml6YXRp b24gaGFzIGJlZW4gb2J0YWluZWQgZnJvbSB0aGUgZW5kLXVzZXIsIHRoZQ0KPj4+ICBhdXRob3Jp emF0aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIGVuZC11c2VyJ3MgdXNlci1hZ2VudCBiYWNrIHRv IHRoZQ0KPj4+ICBjbGllbnQgd2l0aCB0aGUgcmVxdWlyZWQgYmluZGluZyB2YWx1ZSBjb250YWlu ZWQgaW4gdGhlICJzdGF0ZSINCj4+PiAgcGFyYW1ldGVyLiAgVGhlIGJpbmRpbmcgdmFsdWUgZW5h YmxlcyB0aGUgY2xpZW50IHRvIHZhbGlkYXRlIHRoZQ0KPj4+ICB2YWxpZGl0eSBvZiB0aGUgcmVx dWVzdCBieSBtYXRjaGluZyB0aGUgYmluZGluZyB2YWx1ZSB0byB0aGUgdXNlci0NCj4+PiAgYWdl bnQncyBhdXRoZW50aWNhdGVkIHN0YXRlLiAgVGhlIGJpbmRpbmcgdmFsdWUgdXNlZCBmb3IgQ1NS Rg0KPj4+ICBwcm90ZWN0aW9uIE1VU1QgY29udGFpbiBhIG5vbi1ndWVzc2FibGUgdmFsdWUsIGFu ZCB0aGUgdXNlci1hZ2VudCdzDQo+Pj4gIGF1dGhlbnRpY2F0ZWQgc3RhdGUgKGUuZy4gc2Vzc2lv biBjb29raWUsIEhUTUw1IGxvY2FsIHN0b3JhZ2UpIE1VU1QNCj4+PiAgYmUga2VwdCBpbiBhIGxv Y2F0aW9uIGFjY2Vzc2libGUgb25seSB0byB0aGUgY2xpZW50IGFuZCB0aGUgdXNlci0NCj4+PiAg YWdlbnQgKGkuZS4sIHByb3RlY3RlZCBieSBzYW1lLW9yaWdpbiBwb2xpY3kpLg0KPj4+DQo+Pj4g IEEgQ1NSRiBhdHRhY2sgYWdhaW5zdCB0aGUgYWdhaW5zdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIncw0KPj4+ICBhdXRob3JpemF0aW9uIGVuZHBvaW50IGNhbiByZXN1bHQgaW4gYW4gYXR0YWNr ZXIgb2J0YWluaW5nIGVuZC11c2VyDQo+Pj4gIGF1dGhvcml6YXRpb24gZm9yIGEgbWFsaWNpb3Vz IGNsaWVudCB3aXRob3V0IGludm9sdmluZyBvciBhbGVydGluZw0KPj4+ICB0aGUgZW5kLXVzZXIu DQo+Pj4NCj4+PiAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgaW1wbGVtZW50IENTUkYg cHJvdGVjdGlvbiBmb3IgaXRzDQo+Pj4gIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIGFuZCBlbnN1 cmUgdGhhdCBhIG1hbGljaW91cyBjbGllbnQgY2Fubm90DQo+Pj4gIG9idGFpbiBhdXRob3JpemF0 aW9uIHdpdGhvdXQgdGhlIGF3YXJlbmVzcyBhbmQgZXhwbGljaXQgY29uc2VudCBvZg0KPj4+ICB0 aGUgcmVzb3VyY2Ugb3duZXIuDQo+Pj4NCj4+PiBFSEwNCj4+Pg0KPj4+DQo+Pj4gRnJvbTogV2ls bGlhbSBKLiBNaWxscyBbbWFpbHRvOndtaWxsc0B5YWhvby1pbmMuY29tXQ0KPj4+IFNlbnQ6IFRo dXJzZGF5LCBBdWd1c3QgMjUsIDIwMTEgMTI6MTEgUE0NCj4+PiBUbzogQW50aG9ueSBOYWRhbGlu OyBFcmFuIEhhbW1lci1MYWhhdjsgVG9yc3RlbiBMb2RkZXJzdGVkdA0KPj4+IENjOiBPQXV0aCBX RyAob2F1dGhAaWV0Zi5vcmcpDQo+Pj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQXV0aCBDb2Rl IFN3YXAgQXR0YWNrDQo+Pj4NCj4+PiBJIGhhZCBwcm9wb3NlZCB0ZXh0LCBhbmQgSSdsbCByZXBy aXNlIGl0IGhlcmUgd2l0aCBhIG1vZGlmaWNhdGlvbiB0byBtYWtlIHRoZQ0KPj4+IGF1dGhvcml6 YXRvbiBzZXJ2ZXIgcmVsYXRlZCBleHBsaWNpdC4NCj4+Pg0KPj4+IDEwLjEyLiAgQ3Jvc3MtU2l0 ZSBSZXF1ZXN0IEZvcmdlcnkNCj4+Pg0KPj4+IENyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IChD U1JGKSBpcyBhbiBhdHRhY2sgd2hlcmVieSBtYWxpY2lvdXMgVVJMcyBhcmUNCj4+PiBzZW50IHRv IHRoZSB1c2VyLWFnZW50IG9mIGFuIGVuZCB1c2VyIChnZW5lcmFsbHkgYXMgaGlkZGVuIGxpbmtz IG9yIGltYWdlcykNCj4+PiBhbmQgdHJhbnNtaXR0ZWQgZnJvbSB0aGUgdXNlci1hZ2VudCB0aGUg c2VydmVyIHRydXN0cyBvciBoYXMgYXV0aGVudGljYXRlZC4NCj4+PiBUaGUgbW9zdCBjb21tb25s eSBleHBsb2l0ZWQgbWVjaGFuaXNtIGZvciB0aGlzIGlzIGNyZWRlbnRpYWxzIGhlbGQgaW4NCj4+ PiBjb29raWVzIGF1dG9tYXRpY2FsbHkgcHJlc2VudGVkIGJ5IGEgd2ViIGJyb3dzZXIuICBDU1JG IGF0dGFja3MgYWdhaW5zdCB0aGUNCj4+PiBjbGllbnQncyByZWRpcmVjdGlvbiBVUkkgYWxsb3cg YW4gYXR0YWNrZXIgdG8gaW5qZWN0IHRoZWlyIG93biBhdXRob3JpemF0aW9uDQo+Pj4gY29kZSBv ciBhY2Nlc3MgdG9rZW4sIHdoaWNoIGNhbiByZXN1bHQgaW4gdGhlIGNsaWVudCB1c2luZyBhbiBh Y2Nlc3MgdG9rZW4NCj4+PiBhc3NvY2lhdGVkIHdpdGggdGhlIGF0dGFja2VyJ3MgYWNjb3VudCBy YXRoZXIgdGhhbiB0aGUgdmljdGltJ3MuICBDU1JGIGF0dGFja3MNCj4+PiBhcmUgYWxzbyBwb3Nz aWJsZSBhZ2FpbnN0IGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcmVzdWx0aW5nIGluIGRlbGl2 ZXJpbmcgYQ0KPj4+IHVzZXIgY3JlZGVudGlhbCB0byBhbiBhdHRhY2tlci4NCj4+Pg0KPj4+IENs aWVudCBhcHBsaWNhdGlvbnMgTVVTVCBpbXBsZW1lbnQgQ1NSRiBwcm90ZWN0aW9uIGZvciB0aGUg cmVkaXJlY3Rpb24NCj4+PiBVUkkuICBDU1JGIHByb3RlY3Rpb24gZm9yIGEgcmVxdWVzdCBpcyBk YXRhIGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0IHRoYXQgdGllcw0KPj4+IHRoYXQgcmVxdWVzdCB0 byB0aGUgdXNlcidzIGF1dGhlbnRpY2F0ZWQgc3RhdGUsIGkuZS4gYSBjcnlwdG9ncmFwaGljIHNp Z25hdHVyZQ0KPj4+IG9mIHRoZSB1c2VyIGNyZWRlbnRpYWwgYW5kIHRoZSByZWRpcmVjdGlvbiBV UkkgcGF0aC4gIFVwb24gcmVjZWlwdCBvZiBhDQo+Pj4gcmVxdWVzdCB0aGUgY2xpZW50IGFwcGxp Y2F0aW9uIGNvbXB1dGVzIHRoZSBDU1JGIGRhdGEgYmFzZWQgb24gdGhlDQo+Pj4gcHJlc2VudGVk IGNyZWRlbnRpYWwgYW5kIGNvbXBhcmVzIHRoYXQgdG8gdGhlIENTUkYgcHJvdGVjdGlvbiBkYXRh DQo+Pj4gcHJlc2VudGVkIGluIHRoZSByZXF1ZXN0LiAgQ1NSRiBwcm90ZWN0aW9uIGRhdGEgTVVT VCBjb250YWluIGEgbm9uLQ0KPj4+IGd1ZXNzYWJsZSB2YWx1ZSwgYW5kIHRoZSBjbGllbnQgTVVT VCBrZWVwIGl0IGluIGEgbG9jYXRpb24gYWNjZXNzaWJsZSBvbmx5IGJ5DQo+Pj4gdGhlIGNsaWVu dCBvciB0aGUgdXNlci1hZ2VudCAoaS5lLiwgcHJvdGVjdGVkIGJ5IHNhbWUtb3JpZ2luIHBvbGlj eSkuIFRoZQ0KPj4+ICJzdGF0ZSIgcmVkaXJlY3Rpb24gVVJJIHBhcmFtZXRlciBpcyBwcm92aWRl ZCBhcyBvbmUgbWV0aG9kIG9mIGNhcnJ5aW5nDQo+Pj4gQ1NSRiBwcm90ZWN0aW9uIGRhdGEsIGFu ZCBpcyBSRUNPTU1FTkRFRCB0byBwcm92aWRlIHRoZSBncmVhdGVzdA0KPj4+IGNvbXBhdGliaWxp dHkgd2l0aCBzeXN0ZW1zIGltcGxlbWVudGluZyBzdHJvbmcgcmVkaXJlY3Rpb24gVVJJIHZhbGlk YXRpb24uDQo+Pj4NCj4+PiBBdXRob3JpemF0aW9uIHNlcnZlcnMgTVVTVCBpbXBsZW1lbnQgQ1NS RiBwcm90ZWN0aW9uIGZvciBhdXRob3JpemF0aW9uDQo+Pj4gcmVxdWVzdHMsIHVzZSBvZiB0aGUg InN0YXRlIiBwYXJhbWV0ZXIgaXMgUkVDT01NRU5ERUQgYXMgdGhlIHdheSB0bw0KPj4+IHRyYW5z bWl0IHRoZSBDU1JGIHByb3RlY3Rpb24gZGF0YS4gIFRoZSBDU1JGIHByb3RlY3Rpb24gZGF0YSBN VVNUIGNvbnRhaW4gYQ0KPj4+IG5vbi1ndWVzc2FibGUgdmFsdWUsIGFuZCBNVVNUIGJlIHByZXNl bnRlZCBhcyBwYXJ0IG9mIHRoZSBhdXRob3JpemF0aW9uDQo+Pj4gcmVxdWVzdCBkYXRhIChlLmcu IG5vdCBhcyBhIGNvb2tpZSkuICBBdXRob3JpemF0aW9uIHNlcnZlcnMgTUFZIHVzZSBwcm9vZiBv Zg0KPj4+IHByZXZpb3VzICBhdXRob3JpemF0aW9uIGJ5IGEgdXNlciBmb3IgYSBjbGllbnQgaW4g bGlldSBvZiBleHBsaWNpdCBDU1JGIHByb3RlY3Rpb24uDQo+Pj4NCj4+PiBGb3IgZXhhbXBsZSwg dXNpbmcgYSBET00gdmFyaWFibGUsIEhUVFAgY29va2llLCBvciBIVE1MNSBjbGllbnQtc2lkZQ0K Pj4+IHN0b3JhZ2UuICBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5jbHVkZXMgdGhlIHZhbHVl IG9mIHRoZSAic3RhdGUiDQo+Pj4gcGFyYW1ldGVyIHdoZW4gcmVkaXJlY3RpbmcgdGhlIHVzZXIt YWdlbnQgYmFjayB0byB0aGUgY2xpZW50IHdoaWNoIE1VU1QNCj4+PiB0aGVuIHZhbGlkYXRlIHRo ZSByZWNlaXZlZCB2YWx1ZSBhZ2FpbnN0IHRoZSBzdG9yZWQgdmFsdWUsIG9yIGJ5IHJlY29tcHV0 aW5nDQo+Pj4gdGhlIGV4cGVjdGVkIHZhbHVlIG9mIHRoZSBDU1JGIHByb3RlY3Rpb24gZGF0YSBh bmQgY29tcGFyaW5nIHRoYXQgdG8gdGhlDQo+Pj4gdmFsdWUgcHJlc2VudGVkLg0KPj4+DQo+Pj4N Cj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBG cm9tOiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NCj4+PiBUbzogRXJh biBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb20+OyBUb3JzdGVuIExvZGRlcnN0ZWR0 DQo+Pj4gPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KPj4+IENjOiAiT0F1dGggV0cgKG9hdXRo QGlldGYub3JnKSIgPG9hdXRoQGlldGYub3JnPg0KPj4+IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3Qg MjUsIDIwMTEgODoxMSBBTQ0KPj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEF1dGggQ29kZSBT d2FwIEF0dGFjayBJIGhhdmUgbm90IHNlZW4gYW55DQo+Pj4gdXBkYXRlZCB0ZXh0LCBzbyBJIGRv buKAmXQgYmVsaWV2ZSB3ZSBoYXZlIGNvbnNlbnN1cy4gQWxzbyB3ZSBoYXZlIGEgZmxhd2VkDQo+ Pj4gcHJvdG9jb2wgYW5kIHdlIGFyZSBub3QgcHJvdmlkaW5nIGEgZml4LCBzdWdnZXN0IHRoYXQg TVVTVCBiZSBvbiB0aGUgc3RhdGUNCj4+PiBhbHNvIHVubGVzcyBzb21lb25lIGhhcyBhIGJldHRl ciBmaXgNCj4+Pg0KPj4+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+PiBPZiBFcmFuIEhhbW1lci1MYWhhdg0K Pj4+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI0LCAyMDExIDc6NTQgQU0NCj4+PiBUbzogVG9y c3RlbiBMb2RkZXJzdGVkdA0KPj4+IENjOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQo+Pj4g U3ViamVjdDogUmU6IFtPQVVUSC1XR10gQXV0aCBDb2RlIFN3YXAgQXR0YWNrDQo+Pj4NCj4+PiBJ IGJlbGlldmUgd2UgaGF2ZSBmdWxsIGNvbnNlbnN1cyBvbiB0aGlzIGFwcHJvYWNoLg0KPj4+DQo+ Pj4gRUhMDQo+Pj4NCj4+PiBGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXRdDQo+Pj4gU2VudDogVHVlc2RheSwgQXVndXN0IDIzLCAyMDExIDEx OjA2IFBNDQo+Pj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2DQo+Pj4gQ2M6IE9BdXRoIFdHIChvYXV0 aEBpZXRmLm9yZykNCj4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBdXRoIENvZGUgU3dhcCBB dHRhY2sNCj4+Pg0KPj4+IG1ha2luZyBDU1JGIHByZXZlbnRpb24gYSBNVVNUIGFuZCByZWNvbW1l bmRpbmcgdGhlIHN0YXRlIHBhcmFtZXRlciBhcw0KPj4+IGltcGxlbWVudGF0aW9uIHBhdHRlcm4g aXMgb2sgd2l0aCBtZS4NCj4+Pg0KPj4+IHJlZ2FyZHMsDQo+Pj4gVG9yc3Rlbi4NCj4+Pg0KPj4+ IEFtIDIxLjA4LjIwMTEgMjE6MDIsIHNjaHJpZWIgRXJhbiBIYW1tZXItTGFoYXY6DQo+Pj4gSSBs aWdodCB0byB0aGUgcmVjZW50IGRpc2N1c3Npb24sIGRvIHlvdSBzdGlsbCBmZWVsIHRoYXQgY2hh bmdpbmcg4oCYc3RhdGXigJkgZnJvbQ0KPj4+IG9wdGlvbmFsIHRvIHJlcXVpcmVkIGlzIHRoZSBi ZXN0IGFwcHJvYWNoPw0KPj4+DQo+Pj4gRUhMDQo+Pj4NCj4+PiBGcm9tOiBUb3JzdGVuIExvZGRl cnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdDQo+Pj4gU2VudDogU3VuZGF5 LCBBdWd1c3QgMjEsIDIwMTEgMTE6MDQgQU0NCj4+PiBUbzogRXJhbiBIYW1tZXItTGFoYXYNCj4+ PiBDYzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPj4+IFN1YmplY3Q6IFJlOiBbT0FVVEgt V0ddIEF1dGggQ29kZSBTd2FwIEF0dGFjaw0KPj4+DQo+Pj4gTXkgaW50ZW50aW9uIGlzIHRvIHJl cXVpcmUgY2xpZW50cyB0byBpbXBsZW1lbnQgQ1NSRiBwcmV2ZW50aW9uLiBJIHRob3VnaHQNCj4+ PiBtYWtpbmcgdGhlIHN0YXRlIHBhcmFtZXRlciBtYW5kYXRvcnkgd291bGQgYmUgdGhlIHN0cmFp Z2h0Zm9yd2FyZCB3YXkuDQo+Pj4NCj4+PiByZWdhcmRzLA0KPj4+IFRvcnN0ZW4uDQo+Pj4NCj4+ PiBBbSAxOC4wOC4yMDExIDA4OjA0LCBzY2hyaWViIEVyYW4gSGFtbWVyLUxhaGF2Og0KPj4+IEkg d291bGQgbGlrZSB0byBoZWFyIGZyb20gdGhlIG90aGVyIDMgYXV0aG9ycyBvZiB0aGUgcHJvcG9z ZWQgY2hhbmdlIGFib3V0DQo+Pj4gdGhlaXIgcmVhc29ucyBmb3IgY2hhbmdpbmcgdGhlIHVzZSBv ZiDigJhzdGF0ZeKAmSBmcm9tIHJlY29tbWVuZGVkIHRvIHJlcXVpcmVkDQo+Pj4gZm9yIENTUkYg cHJldmVudGlvbi4gSXQgd291bGQgYWxzbyBoZWxwIG1vdmluZyB0aGlzIGlzc3VlIGZvcndhcmQg aWYgdGhlIDQNCj4+PiBhdXRob3JzIGNhbiBwcm92aWRlIGFuc3dlcnMgb3IgY2xhcmlmaWNhdGlv bnMgb24gdGhlIGlzc3VlcyByYWlzZWQgYmVsb3cuDQo+Pj4NCj4+PiBBc3N1bWluZyB3ZSBjYW4g Y291bnQgYWxsIDQgYXV0aG9ycyBhcmUgaW4gZmF2b3Igb2YgbWFraW5nIHRoZSBjaGFuZ2UsIEkN Cj4+PiBiZWxpZXZlIHdlIGhhdmUgYSB0aWUgKDQ6NCkgYW5kIHRoZXJlZm9yZSBubyBjb25zZW5z dXMgZm9yIG1ha2luZyBpdCAoYXMgb2YNCj4+PiB0aGlzIHBvaW50KS4gSG93ZXZlciwgd2UgZGlk IGlkZW50aWZ5IGlzc3VlcyB3aXRoIHRoZSBzZWN0aW9u4oCZcyBsYW5ndWFnZSBhbmQNCj4+PiBj bGFyaXR5IHdoaWNoIHdlIHNob3VsZCBhZGRyZXNzIGVpdGhlciB3YXkuDQo+Pj4NCj4+PiBUbyBj bGFyaWZ5IOKAkyBJIGFtIG5vdCBwcm9wb3Npbmcgd2UgY2xvc2UgdGhpcyBpc3N1ZSBqdXN0IHll dC4NCj4+Pg0KPj4+IEVITA0KPj4+DQo+Pj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+IE9mIEVyYW4gSGFt bWVyLUxhaGF2DQo+Pj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMTUsIDIwMTEgOTozNSBBTQ0KPj4+ IFRvOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQo+Pj4gU3ViamVjdDogUmU6IFtPQVVUSC1X R10gQXV0aCBDb2RlIFN3YXAgQXR0YWNrDQo+Pj4NCj4+PiBUbyBkZW1vbnN0cmF0ZSB3aHkgbWFr aW5nIHN0YXRlIHJlcXVpcmVkIGFzIHByb3Bvc2VkIGlzbuKAmXQgdmVyeSBoZWxwZnVsLA0KPj4+ IGhlcmUgaXMgYW4gaW5jb21wbGV0ZSBsaXN0IG9mIG90aGVyIHJlcXVpcmVtZW50cyBuZWVkZWQg dG8gbWFrZSBhbg0KPj4+IGVmZmVjdGl2ZSBDU1JGOg0KPj4+DQo+Pj4gKiBTdGF0ZSB2YWx1ZSBt dXN0IG5vdCBiZSBlbXB0eSAoYSBjb21tb24gYnVnIGluIG1hbnkgaW1wbGVtZW50YXRpb25zDQo+ Pj4gdXNpbmcgc2ltcGxlIHZhbHVlIGNvbXBhcmlzb24pLg0KPj4+DQo+Pj4gKiDigJhOb24tZ3Vl c3NhYmxl4oCZIGlzbuKAmXQgc3VmZmljaWVudCBhcyBtb3N0IGRldmVsb3BlcnMgd2lsbCBzaW1w bHkgdXNlIGEgaGFzaCBvZg0KPj4+IHRoZSBzZXNzaW9uIGNvb2tpZSwgd2l0aCBvciB3aXRob3V0 IHNhbHQgd2hpY2ggaXNu4oCZdCBzdWZmaWNpZW50LiBXZSB1c2Ug4oCcY2Fubm90DQo+Pj4gYmUg Z2VuZXJhdGVkLCBtb2RpZmllZCwgb3IgZ3Vlc3NlZCB0byBwcm9kdWNlIHZhbGlkIHZhbHVlc+KA nSBlbHNld2hlcmUgaW4NCj4+PiB0aGUgZG9jdW1lbnQsIGJ1dCB0aGlzIGlzIG11Y2ggZWFzaWVy IHRvIGdldCByaWdodCBmb3IgYWNjZXNzIHRva2VucyBhbmQNCj4+PiByZWZyZXNoIHRva2VucyB0 aGFuIENTUkYgdG9rZW5zIHdoaWNoIGFyZSBvZnRlbiBqdXN0IHNvbWUgYWxnb3JpdGhtIG9uIHRv cA0KPj4+IG9mIHRoZSBzZXNzaW9uIGNvb2tpZS4NCj4+Pg0KPj4+ICogU3RhdGUgQ1NSRiB2YWx1 ZSBzaG91bGQgYmUgc2hvcnQtbGl2ZWQgb3IgYmFzZWQgb24gYSBzaG9ydC1saXZlZCBzZXNzaW9u DQo+Pj4gY29va2llIHRvIHByZXZlbnQgdGhlIHVzZSBvZiBhIGxlYWtlZCBzdGF0ZSB2YWx1ZSBp biBtdWx0aXBsZSBhdHRhY2tzIG9uIHRoZQ0KPj4+IHNhbWUgdXNlciBzZXNzaW9uIG9uY2UgdGhl IGxlYWsgaXMgbm8gbG9uZ2VyIHZpYWJsZS4NCj4+Pg0KPj4+IEluIGFkZGl0aW9uLCB0aGlzIGlz IG5vdCB3aGF0IOKAnHN0YXRl4oCdIHdhcyBvcmlnaW5hbGx5IGludGVuZGVkIGZvci4gSWYgdGhl IHdvcmtpbmcNCj4+PiBncm91cCBkZWNpZGVzIHRvIG1hbmRhdGUgYSBDU1JGIHBhcmFtZXRlciwg aXQgc2hvdWxkIHByb2JhYmx5IGJlIGEgbmV3DQo+Pj4gcGFyYW1ldGVyIHdpdGggYSBtb3JlIGFw cHJvcHJpYXRlIG5hbWUgKGUuZy4g4oCYY3NyZuKAmSkuIEJ5IGZvcmNpbmcgY2xpZW50cyB0bw0K Pj4+IHVzZSDigJxzdGF0ZeKAnSBmb3IgdGhpcyBwdXJwb3NlLCBkZXZlbG9wZXJzIHdpbGwgbmVl ZCB0byB1c2UgZHluYW1pYyBxdWVyaWVzIGZvcg0KPj4+IG90aGVyIHN0YXRlIGluZm9ybWF0aW9u IHdoaWNoIGZ1cnRoZXIgcmVkdWNlcyB0aGUgc2VjdXJpdHkgb2YgdGhlIHByb3RvY29sDQo+Pj4g KGFzIHRoZSBkcmFmdCByZWNvbW1lbmRzIG5vdCB1c2luZyBkeW5hbWljIGNhbGxiYWNrIHF1ZXJ5 IGNvbXBvbmVudHMpLg0KPj4+IEVuY29kaW5nIGJvdGggQ1NSRiB0b2tlbnMgYW5kIG90aGVyIHN0 YXRlIGluZm9ybWF0aW9uIGNhbiBiZSBub24taW50dWl0aXZlDQo+Pj4gb3IgY29tcGxpY2F0ZWQg Zm9yIHNvbWUgZGV2ZWxvcGVycy9wbGF0Zm9ybXMuDQo+Pj4NCj4+PiBFSEwNCj4+Pg0KPj4+DQo+ Pj4NCj4+Pg0KPj4+IEZyb206IEVyYW4gSGFtbWVyLUxhaGF2DQo+Pj4gU2VudDogRnJpZGF5LCBB dWd1c3QgMTIsIDIwMTEgMjo1MyBQTQ0KPj4+IFRvOiBBbnRob255IE5hZGFsaW47IE9BdXRoIFdH IChvYXV0aEBpZXRmLm9yZykNCj4+PiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBdXRoIENvZGUg U3dhcCBBdHRhY2sNCj4+Pg0KPj4+IFRoaXMgaXMgcmVhbGx5IGp1c3QgYSBmbGF2b3Igb2YgQ1NS RiBhdHRhY2tzLiBJIGhhdmUgbm8gb2JqZWN0aW9ucyB0byBiZXR0ZXINCj4+PiBkb2N1bWVudGlu ZyBpdCAodGhvdWdoIEkgZmVlbCB0aGUgY3VycmVudCB0ZXh0IGlzIGFscmVhZHkgc3VmZmljaWVu dCksIGJ1dCB3ZQ0KPj4+IGNhbid0IHJlYWxpc3RpY2FsbHkgZXhwZWN0IHRvIGlkZW50aWZ5IGFu ZCBjbG9zZSBldmVyeSBwb3NzaWJsZSBicm93c2VyLWJhc2VkDQo+Pj4gYXR0YWNrLiBBIG5ldyBv bmUgaXMgaW52ZW50ZWQgZXZlcnkgb3RoZXIgd2Vlay4NCj4+Pg0KPj4+IFRoZSBwcm9ibGVtIHdp dGggdGhpcyB0ZXh0IGlzIHRoYXQgZGV2ZWxvcGVycyB3aG8gZG8gbm8gdW5kZXJzdGFuZCBDU1JG DQo+Pj4gYXR0YWNrcyBhcmUgbm90IGxpa2VseSB0byBpbXBsZW1lbnQgaXQgY29ycmVjdGx5IHdp dGggdGhpcyBpbmZvcm1hdGlvbi4gVGhvc2UNCj4+PiB3aG8gdW5kZXJzdGFuZCBpdCBkbyBub3Qg bmVlZCB0aGUgZXh0cmEgdmVyYmlhZ2Ugd2hpY2ggaXMgbW9yZSBjb25mdXNpbmcNCj4+PiB0aGFu IGhlbHBmdWwuDQo+Pj4NCj4+PiBBcyBmb3IgdGhlIG5ldyByZXF1aXJlbWVudHMsIHRoZXkgYXJl IGluc3VmZmljaWVudCB0byBhY3R1YWxseSBhY2NvbXBsaXNoDQo+Pj4gd2hhdCB0aGUgYXV0aG9y cyBwcm9wb3NlIHdpdGhvdXQgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgb24gc3RhdGUgbG9jYWwN Cj4+PiBzdG9yYWdlIGFuZCB2ZXJpZmljYXRpb24gdG8gY29tcGxldGUgdGhlIGZsb3cuIEFsc28s IHRoZSBwcm9wb3NlZCB0ZXh0IG5lZWRzDQo+Pj4gY2xhcmlmaWNhdGlvbnMgYXMgbm90ZWQgYmVs b3cuDQo+Pj4NCj4+Pg0KPj4+IEZyb206IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3Nv ZnQuY29tPg0KPj4+IERhdGU6IEZyaSwgMTIgQXVnIDIwMTEgMTI6MDY6MzYgLTA3MDANCj4+PiBU bzogIk9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykiIDxvYXV0aEBpZXRmLm9yZz4NCj4+PiBTdWJq ZWN0OiBbT0FVVEgtV0ddIEF1dGggQ29kZSBTd2FwIEF0dGFjaw0KPj4+DQo+Pj4NCj4+Pg0KPj4+ IFJlY29tbWVuZGVkIENoYW5nZXMgdG8gZHJhZnQtaWV0Zi1vYXV0aC12Mg0KPj4+DQo+Pj4gSW4g c2VjdGlvbiA0LCByZXF1ZXN0IG9wdGlvbnMgKGUuZy4gNC4xLjEpIGZlYXR1cmluZyAic3RhdGUi IHNob3VsZCBjaGFuZ2UNCj4+PiBmcm9tOg0KPj4+DQo+Pj4gc3RhdGUNCj4+PiBPUFRJT05BTC4g QW4gb3BhcXVlIHZhbHVlIHVzZWQgYnkgdGhlIGNsaWVudCB0byBtYWludGFpbiBzdGF0ZSBiZXR3 ZWVuDQo+Pj4gdGhlIHJlcXVlc3QgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuDQo+Pj4gcmVkaXJlY3RpbmcgdGhlIHVzZXItYWdl bnQgYmFjayB0byB0aGUgY2xpZW50Lg0KPj4+DQo+Pj4gdG86DQo+Pj4NCj4+PiBzdGF0ZQ0KPj4+ IFJFUVVJUkVELiBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xpZW50IHRvIG1haW50YWlu IHN0YXRlIGJldHdlZW4NCj4+PiB0aGUgcmVxdWVzdCBhbmQgY2FsbGJhY2suIFRoZSBhdXRob3Jp emF0aW9uIHNlcnZlciBpbmNsdWRlcyB0aGlzIHZhbHVlIHdoZW4NCj4+PiByZWRpcmVjdGluZyB0 aGUgdXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBlbmNvZGVkIHZhbHVlIFNIT1VM RA0KPj4+IGVuYWJsZSB0aGUgY2xpZW50IGFwcGxpY2F0aW9uIHRvIGRldGVybWluZSB0aGUgdXNl ci1jb250ZXh0IHRoYXQgd2FzIGFjdGl2ZSBhdA0KPj4+IHRoZSB0aW1lIG9mIHRoZSAgcmVxdWVz dCAoc2VlIHNlY3Rpb24gMTAuMTIpLiBUaGUgdmFsdWUgTVVTVCBOT1QgYmUNCj4+PiBndWVzc2Fi bGUgb3IgcHJlZGljdGFibGUsIGFuZCBNVVNUIGJlIGtlcHQgY29uZmlkZW50aWFsLg0KPj4+DQo+ Pj4NCj4+PiBNYWtpbmcgdGhlIHBhcmFtZXRlciByZXF1aXJlZCB3aXRob3V0IG1ha2luZyBpdHMg dXNhZ2UgcmVxdWlyZWQgKEkuZS4NCj4+PiAidmFsdWUgU0hPVUxEIGVuYWJsZSIpIGFjY29tcGxp c2hlcyBub3RoaW5nLiBBbHNvLCB3aGF0IGRvZXMgIk1VU1QgYmUNCj4+PiBrZXB0IGNvbmZpZGVu dGlhbCIgbWVhbj8gQ29uZmlkZW50aWFsIGZyb20gd2hhdD8gV2h5IHNwZWNpZnkgYW4gImVuY29k ZWQNCj4+PiB2YWx1ZSI/DQo+Pj4NCj4+Pg0KPj4+IFNlY3Rpb24gMTAuMTIgQ3Jvc3MtU2l0ZSBS ZXF1ZXN0IEZvcmdlcnkNCj4+Pg0KPj4+IENoYW5nZSB0bzoNCj4+Pg0KPj4+IENyb3NzLXNpdGUg cmVxdWVzdCBmb3JnZXJ5IChDU1JGKSBpcyBhIHdlYi1iYXNlZCBhdHRhY2sgd2hlcmVieSBIVFRQ DQo+Pj4gcmVxdWVzdHMgYXJlIHRyYW5zbWl0dGVkIGZyb20gdGhlIHVzZXItYWdlbnQgb2YgYW4g ZW5kLXVzZXIgdGhlIHNlcnZlcg0KPj4+IHRydXN0cyBvciBoYXMgYXV0aGVudGljYXRlZC4gQ1NS RiBhdHRhY2tzIGVuYWJsZSB0aGUgYXR0YWNrZXIgdG8gaW50ZXJtaXggdGhlDQo+Pj4gYXR0YWNr ZXIncyBzZWN1cml0eSBjb250ZXh0IHdpdGggdGhhdCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIgcmVz dWx0aW5nIGluIGENCj4+PiBjb21wcm9taXNlIG9mIGVpdGhlciB0aGUgcmVzb3VyY2Ugc2VydmVy IG9yIG9mIHRoZSBjbGllbnQgYXBwbGljYXRpb24gaXRzZWxmLiBJbg0KPj4+IHRoZSBPQXV0aCBj b250ZXh0LCBzdWNoIGF0dGFja3MgYWxsb3cgYW4gYXR0YWNrZXIgdG8gaW5qZWN0IHRoZWlyIG93 bg0KPj4+IGF1dGhvcml6YXRpb24gY29kZSBvciBhY2Nlc3MgdG9rZW4gaW50byBhIGNsaWVudCwg d2hpY2ggY2FuIHJlc3VsdCBpbiB0aGUgY2xpZW50DQo+Pj4gdXNpbmcgYW4gYWNjZXNzIHRva2Vu IGFzc29jaWF0ZWQgd2l0aCB0aGUgYXR0YWNrZXIncyBhY2NvdW50IHJhdGhlciB0aGFuIHRoZQ0K Pj4+IHZpY3RpbSdzLiBEZXBlbmRpbmcgb24gdGhlIG5hdHVyZSBvZiB0aGUgY2xpZW50IGFuZCB0 aGUgcHJvdGVjdGVkIHJlc291cmNlcywNCj4+PiB0aGlzIGNhbiBoYXZlIHVuZGVzaXJhYmxlIGFu ZCBkYW1hZ2luZyBlZmZlY3RzLg0KPj4+DQo+Pj4gSW4gb3JkZXIgdG8gcHJldmVudCBzdWNoIGF0 dGFja3MsIHRoZSBjbGllbnQgYXBwbGljYXRpb24gTVVTVCBlbmNvZGUgYSBub24tDQo+Pj4gZ3Vl c3NhYmxlLCBjb25maWRlbnRpYWwgZW5kLXVzZXIgYXJ0aWZhY3QgYW5kIHN1Ym1pdCBhcyB0aGUg InN0YXRlIiBwYXJhbWV0ZXINCj4+PiB0byBhdXRob3JpemF0aW9uIGFuZCBhY2Nlc3MgdG9rZW4g cmVxdWVzdHMgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUNCj4+PiBjbGllbnQgTVVT VCBrZWVwIHRoZSBzdGF0ZSB2YWx1ZSBpbiBhIGxvY2F0aW9uIGFjY2Vzc2libGUgb25seSBieSB0 aGUgY2xpZW50IG9yDQo+Pj4gdGhlIHVzZXItYWdlbnQgKGkuZS4sIHByb3RlY3RlZCBieSBzYW1l LW9yaWdpbiBwb2xpY3kpLCBmb3IgZXhhbXBsZSwgdXNpbmcgYQ0KPj4+IERPTSB2YXJpYWJsZSwg SFRUUCBjb29raWUsIG9yIEhUTUw1IGNsaWVudC1zaWRlIHN0b3JhZ2UuDQo+Pj4NCj4+PiBUaGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5jbHVkZXMgdGhlIHZhbHVlIG9mIHRoZSAic3RhdGUiIHBh cmFtZXRlciB3aGVuDQo+Pj4gcmVkaXJlY3RpbmcgdGhlIHVzZXItYWdlbnQgYmFjayB0byB0aGUg Y2xpZW50LiBVcG9uIHJlY2VpdmluZyBhIHJlZGlyZWN0LCB0aGUNCj4+PiBjbGllbnQgYXBwbGlj YXRpb24gTVVTVCBjb25maXJtIHRoYXQgcmV0dXJuZWQgdmFsdWUgb2YgInN0YXRlIiBjb3JyZXNw b25kcw0KPj4+IHRvIHRoZSBzdGF0ZSB2YWx1ZSBvZiB0aGUgdXNlci1hZ2VudCdzIHVzZXIgc2Vz c2lvbi4gSWYgdGhlIGVuZC11c2VyIHNlc3Npb24NCj4+PiByZXByZXNlbnRzIGFuIGF1dGhlbnRp Y2F0ZWQgdXNlci1pZGVudGl0eSwgdGhlIGNsaWVudCBNVVNUIGVuc3VyZSB0aGF0IHRoZQ0KPj4+ IHVzZXItaWRlbnRpdHkgaGFzIE5PVCBjaGFuZ2VkLg0KPj4+DQo+Pj4NCj4+PiBUaGUgYWJvdmUg dGV4dCB1c2VzICd1c2VyLWNvbnRleHQnIGFuZCB0aGlzICd1c2VyLWlkZW50aXR5Jy4gTmVpdGhl ciB0ZXJtIGlzDQo+Pj4gZGVmaW5lZC4NCj4+Pg0KPj4+IEVITA0KPj4+DQo+Pj4NCj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1h aWxpbmcgbGlzdA0KPj4+IE9BdXRoQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4+ IE9BdXRoQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+PiBPQXV0aEBpZXRmLm9yZw0KPj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBPQXV0aCBtYWlsaW5n IGxpc3QNCj4+IE9BdXRoQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoDQo+DQo= From jricher@mitre.org Wed Sep 7 07:16: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 7648821F8B27 for ; Wed, 7 Sep 2011 07:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 i6nweUjnx55N for ; Wed, 7 Sep 2011 07:16:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C3E9121F8B2D for ; Wed, 7 Sep 2011 07:16:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB29D21B08DB; Wed, 7 Sep 2011 10:18:17 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E424421B08B9; Wed, 7 Sep 2011 10:18:17 -0400 (EDT) Received: from [129.83.50.1] (129.83.31.55) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.270.1; Wed, 7 Sep 2011 10:18:17 -0400 From: Justin Richer To: "Manger, James H" In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128DF46CA4@WSMSG3153V.srv.dir.telstra.com> References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> <4E66C521.5070804@mtcc.com> <1315358847.25169.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E66CF9A.8000905@mtcc.com> <255B9BB34FB7D647A506DC292726F6E1128DF46CA4@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 7 Sep 2011 10:17:14 -0400 Message-ID: <1315405034.3136.53.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 14:16:29 -0000 Ah, guess that settles it then. Mike, if you have any suggested text to make this point clearer in the spec, this is probably the best place to put it. -- Justin On Tue, 2011-09-06 at 23:52 -0400, Manger, James H wrote: > A strange aspects of this thread is that the current draft already talks about exactly this issue: > > draft-ietf-oauth-v2-21 section 9 "Native Applications" > > "...Native applications can invoke an external user-agent or > embed a user-agent within the application > ... > Embedded user-agents pose a security challenge because resource > owners are authenticating in an unidentified window without access > to the visual protections found in most external user-agents. > Embedded user-agents educate end-user to trust unidentified > requests for authentication (making phishing attacks easier to > execute)." > > The webView that Michael Thomas talks about is an "embedded user-agent". > > -- > James Manger > > > ---------- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Michael Thomas > > ... > At this point, it would be just nice for the industry to know that the issue > even *exists*. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mike@mtcc.com Wed Sep 7 07:52: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 4076421F8C48 for ; Wed, 7 Sep 2011 07:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, SARE_ADULT2=1.42] 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 WKxYU1X+I6lm for ; Wed, 7 Sep 2011 07:52:35 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id CC73021F8C40 for ; Wed, 7 Sep 2011 07:52:35 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87EsNk2029683 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 07:54:23 -0700 Message-ID: <4E67859F.9050908@mtcc.com> Date: Wed, 07 Sep 2011 07:54:23 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: "Manger, James H" References: <4E665B25.6090709@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> <4E66C521.5070804@mtcc.com> <1315358847.25169.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E66CF9A.8000905@mtcc.com> <255B9BB34FB7D647A506DC292726F6E1128DF46CA4@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128DF46CA4@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2385; t=1315407265; x=1316271265; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20=22Manger,=20James=20H=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=FF5zyF/5GhwK7mKUPFvI4BhfOxK01EIUXgMt3yEDw8E=; b=Iwjm9/IyjB2MscpucJqckwnwyT9hX2Aw3wJTqEd164Qd2EtsigUNtaGwRZ ZKztdXXSZPvLI6cGOtmV8j1T319YRXw5KeruOE+aBoatUXhC7KclV8oqJlmR XaJykD8LpXWYj0FDd/riZ7B5YPjdyLFpmv2jsYJjm7yakD47smPOY=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 14:52:40 -0000 On 09/06/2011 08:52 PM, Manger, James H wrote: > A strange aspects of this thread is that the current draft already talks about exactly this issue: > > draft-ietf-oauth-v2-21 section 9 "Native Applications" > > "...Native applications can invoke an external user-agent or > embed a user-agent within the application > ... > Embedded user-agents pose a security challenge because resource > owners are authenticating in an unidentified window without access > to the visual protections found in most external user-agents. > Embedded user-agents educate end-user to trust unidentified > requests for authentication (making phishing attacks easier to > execute)." > > The webView that Michael Thomas talks about is an "embedded user-agent". > First, thank you for finding this -- this is far more useful than the snarls I've received. Second, I'd say that this is a good first step, but the text there should be explicit and not pussy-foot around the fact that it means embedded UA's in phone apps and other examples. It should also make clear that the "challenge" (ack, ptui) involves untrusted apps stealing the user's credentials by simply snooping on the UA itself. If there is reasonable mitigation, then by all means add text about it. This is important because I do not think that many people grok the seriousness of the issue, and most especially people who would deploy oauth authentication services. Third, I think that the introduction needs to have an applicability statement of *when/where/what* oauth can be used. That is, do not beat around the bush about the need for the UA to be trustable because that is a basic the assumption that oauth makes. As inconvenient as that may be, it would be far worse for people in the industry to not fully understand the threat. Fourth, it would be *really* nice to hear from folks at Facebook and Twitter who have deployed oauth and oauth-like flows with their experience here, and most especially if they understood the threat ahead of their deployment, and what they do to mitigate it if anything. Mike > -- > James Manger > > > ---------- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Michael Thomas > > ... > At this point, it would be just nice for the industry to know that the issue > even *exists*. > From barryleiba@gmail.com Wed Sep 7 08:57: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 426A921F8C97 for ; Wed, 7 Sep 2011 08:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.023 X-Spam-Level: X-Spam-Status: No, score=-103.023 tagged_above=-999 required=5 tests=[AWL=-0.046, 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 PFlYLgCaF8Mx for ; Wed, 7 Sep 2011 08:57:21 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id AF07421F8C95 for ; Wed, 7 Sep 2011 08:57:21 -0700 (PDT) Received: by gxk9 with SMTP id 9so6491157gxk.40 for ; Wed, 07 Sep 2011 08:59:11 -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:content-type; bh=etLzfZ9CASWHPUDPqZuYfh7dtN7gZHh8nmFvXTeAOow=; b=lGj7HyuT2T5aVV1E5J5zPGhFU/OS7mjrg6O8blIiAPZlhX0FO7kVDzDPz57SjRLF9f LeK2C3btB7Tp5U/33Y3RjNoce5wpu0LNG8nbeWffxn03GibkPqpxlnTOzn9g8F36Qw5R I30op9gbKSAiXYWdQNEFH3otEfeVTF2JxxKhk= MIME-Version: 1.0 Received: by 10.236.181.137 with SMTP id l9mr28272560yhm.56.1315411150729; Wed, 07 Sep 2011 08:59:10 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.203.68 with HTTP; Wed, 7 Sep 2011 08:59:10 -0700 (PDT) Date: Wed, 7 Sep 2011 11:59:10 -0400 X-Google-Sender-Auth: rKGtJhEM4LHWjMb1d4hWOjR2jmo Message-ID: From: Barry Leiba To: oauth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Reviewing draft-ietf-oauth-v2-21 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, 07 Sep 2011 15:57:22 -0000 As you've all probably seen, Eran has posted version 21 of the OAuth base spec, in which he believes he's addressed all comments and issues that came up in the review of version 20. We should be ready to send this to the IESG. Everyone who had comments or issues, please review -21 and make sure that your concerns have been handled to your satisfaction (or that there was no consensus to make a change). And we encourage everyone to review the changes from -20 to -21, to make sure Eran didn't inadvertently break anything along the way. The -21 is here: http://tools.ietf.org/html/draft-ietf-oauth-v2-21 And diffs from -20 can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-21.txt We'll give it until the end of next week, while I work on the shepherd writeup. Comments, please, by 16 September. A few affirmative notes saying, "Yes, I reviewed it and it looks good," will also be helpful. Keep in mind, as you review, that pet changes are out of scope at this point. We're just reviewing -21 to make sure (1) it doesn't break anything from -20, and (2) it isn't missing anything that was brought up in WGLC. New issues will have to be very serious, indeed, in order to be considered now. Also, a note on the thread that Mike Thomas started about the OAuth problem statement and threats: I did encourage him to start the discussion, and I think it can be a useful conversation. I do NOT think it will or should result in a change to the base spec, but it might feed into the threat model document (draft-ietf-oauth-v2-threatmodel), as Torsten, et al, move that toward completion. Remember that the base spec encourages readers to refer to the threat model document for more detailed descriptions of threats and attacks. Barry, as chair From igor.faynberg@alcatel-lucent.com Wed Sep 7 10:15: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 A4AAE21F8D0A for ; Wed, 7 Sep 2011 10:15:17 -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 O0TqxUtKsqCB for ; Wed, 7 Sep 2011 10:15:17 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id DB66121F8D32 for ; Wed, 7 Sep 2011 10:15:16 -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 p87HH66a021443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Sep 2011 12:17:06 -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 p87HH58Z013132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Sep 2011 12:17:06 -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 p87HH4jb029469; Wed, 7 Sep 2011 12:17:05 -0500 (CDT) Message-ID: <4E67A710.9070505@alcatel-lucent.com> Date: Wed, 07 Sep 2011 13:17:04 -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: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> In-Reply-To: <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> 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.11 Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 17:15:17 -0000 +300 (if I can do that) to indicate my strong agreement. But if somehow it is decided to add a few sentences on saying that OAuth cannot deal with key-logging, I will insist on adding two sentences each on OAuth being unable to deal with 1) earthquakes, 2) certain contageous diseases, etc., and I will invite others to complete that list. And encouraged by the precedent, I will require similar changes to TLS as well as the whole list of password-authenticated key exchange protocols. Melinda, in my reading the "temperature of the responses" is explained by a huge amount of work achieved by this group, which involved many, many real protocol issues on which it was hard to build the consensus. Now that the consenus has been pretty much achieved, it is important to complete OAuth 2.0, which means concentrating on real outstanding issues--Barry has dutifully documented and enumerated them. I myself got beaten up unjustly for pushing the use cases, but in order to complete the protocol, I accepted the beating and agreed to wait until the next rechartering. This is a matter of priorities. My opinion is that we just cannot go off on a tangent to deal with something that is not OAuth's concern. Because, if we do, someone will bring the earthquakes, too. Igor On 9/6/2011 6:27 PM, Eran Hammer-Lahav wrote: > It is a problem. For a few months now we have been going through this over and over again. The longer we work on this draft the more of this two-sentence changes people suggest. They don't make the document any better, create a false sense of comprehensiveness, and just further delay being done. > > So yeah, unless you can prove that there is an actual problem, we are done. > > EHL > > On Sep 6, 2011, at 15:22, "Melinda Shore" wrote: > >> On 09/06/2011 12:59 PM, John Kemp wrote: >>> The point is that you have a point. >> He does, and that's in some large part why I don't >> fully understand the temperature of the responses. >> I do not think it's a particularly big deal to stick >> a couple of sentences in the security considerations >> underscoring the fact that OAUTH can't do anything >> about a compromised host or a malicious application. >> I've learned to live with the fact that sometimes >> people implementing or deploying security technologies >> don't fully understand them and it's my impression that >> there's some number of people out there who think that >> OAUTH and other third-party protocols provide sufficient >> protection against password snagging. >> >> Melinda >> _______________________________________________ >> 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 mike@mtcc.com Wed Sep 7 10:24: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 320D321F8C9D for ; Wed, 7 Sep 2011 10:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_53=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 mkJGzMSMvVhf for ; Wed, 7 Sep 2011 10:24:39 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD3021F8C90 for ; Wed, 7 Sep 2011 10:24:39 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87HQQhb022671 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 10:26:27 -0700 Message-ID: <4E67A942.1070200@mtcc.com> Date: Wed, 07 Sep 2011 10:26:26 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> In-Reply-To: <4E67A710.9070505@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=815; t=1315416387; x=1316280387; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20igor.faynberg@alcatel-lucent.com |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=28Foki0dnoIMHCAN1v0Wyshyrz1gjV/OBzN2GfaRCMg=; b=eOUEf78/RXKqSjPhZ54WB8/ES/6vaz999WSRpdYY7J3k1/WQaS58kH+iL9 cY+fxlbIAFJW3EJxC13WzP0ZoKac82nyz9q2DSO7CbpjcEIrM+hw+a3eZm6c VmvNrcnOwQz0U8NXVmElnEUAQywzXTBMCD+X2xVvoptxmhcXqrGSk=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 17:24:40 -0000 On 09/07/2011 10:17 AM, Igor Faynberg wrote: > +300 (if I can do that) to indicate my strong agreement. But if > somehow it is decided to add a few sentences on saying that OAuth > cannot deal with key-logging, I will insist on adding two sentences > each on OAuth being unable to deal with 1) earthquakes, 2) certain > contageous diseases, etc., [...] Please, enough of the hyperbole. It is not clear or obvious whether this is a protocol issue or not. It brings into question whether the protocol is worth deploying at all, and that is surely an issue. As far as I can tell, there is very little upside to deploying OAuth in the general case over, say, Basic+TLS. In fact, you guys have convinced me that OAuth gives inferior protection at considerable expense for all concerned. Mike From john@jkemp.net Wed Sep 7 10:47: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 A786521F8CCE for ; Wed, 7 Sep 2011 10:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.439 X-Spam-Level: X-Spam-Status: No, score=0.439 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, J_CHICKENPOX_53=0.6, 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 MqSltZlNROkd for ; Wed, 7 Sep 2011 10:47:15 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 0262421F8CC8 for ; Wed, 7 Sep 2011 10:47:14 -0700 (PDT) Received: (qmail 20124 invoked by uid 0); 7 Sep 2011 17:49:04 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy3.bluehost.com with SMTP; 7 Sep 2011 17:49:04 -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=YtGTdaT0Qwheiwyfe+1mA8GUWx+VqMc8e0GyvvDCEpk=; b=IsBQyPRJAfuOiLpy7Qcp0JGIcLg7JzhBNzt7gJ025sPt3waMyZUCWqVl00Zn1F7/jIehMSd7q5xDYFdKHPrdAmdwsAUERzlEttdYdgs8FjqOk1Ovgr1zqojdgN8oPlw9; Received: from c-107-3-99-170.hsd1.vt.comcast.net ([107.3.99.170] helo=[192.168.0.102]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1R1MFE-0002hG-Bu; Wed, 07 Sep 2011 11:49:04 -0600 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <4E67A942.1070200@mtcc.com> Date: Wed, 7 Sep 2011 13:49:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1244.3) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 107.3.99.170 authed with john+jkemp.net} Cc: OAuth WG Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 17:47:15 -0000 Mike, On Sep 7, 2011, at 1:26 PM, Michael Thomas wrote: > On 09/07/2011 10:17 AM, Igor Faynberg wrote: >> +300 (if I can do that) to indicate my strong agreement. But if = somehow it is decided to add a few sentences on saying that OAuth cannot = deal with key-logging, I will insist on adding two sentences each on = OAuth being unable to deal with 1) earthquakes, 2) certain contageous = diseases, etc., [...] >=20 > Please, enough of the hyperbole. It is not clear or obvious whether = this is > a protocol issue or not. It brings into question whether the protocol = is worth > deploying at all, and that is surely an issue. As far as I can tell, = there is very > little upside to deploying OAuth in the general case over, say, = Basic+TLS. In > fact, you guys have convinced me that OAuth gives inferior protection = at > considerable expense for all concerned. I'm sorry that you haven't received an easy introduction to the OAuth = WG. But that's no reason to spout nonsense. OAuth seeks to replace = something that was once rather common - the need for a user to type = (and/or store) his password for site A at site B, to let site B get = their content from site A. Now, site B gets a token in the common case, = rather than the user's password for site A. This doesn't remove the need = for a user to exercise common sense in deciding where to type her = password. But it does, in the common case, mitigate the password being = shared among websites, or across networks multiple times.=20 You are right that OAuth doesn't mitigate key logging or other similar = attacks on the client OS/platform itself. But that doesn't make it = inferior to other methods of web authorization. - John >=20 > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mike@mtcc.com Wed Sep 7 11:00: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 AC5CC21F8C9C for ; Wed, 7 Sep 2011 11:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_53=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 ExB2KsSK9nxP for ; Wed, 7 Sep 2011 11:00:54 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 13C3C21F8C95 for ; Wed, 7 Sep 2011 11:00:54 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87I2hpg003800 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 11:02:43 -0700 Message-ID: <4E67B1C3.60306@mtcc.com> Date: Wed, 07 Sep 2011 11:02:43 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: John Kemp References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2051; t=1315418564; x=1316282564; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20John=20Kemp=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=LFDmKpjLLETkiBUHWfm/yfj43OOu0KAvYeR8++bYdIM=; b=V3Ti6VsDX8GefIl1hsiHB5fe5ApQBSrkKOszIqOPTRLZVdin9lDU8ZpZGT Mr+66pIZAr/u3YTu1jfXwE33l1ghvJoFMYYhwChXVt75I+YLuy3b17+v2xx9 GXfbt9PWLbBZM/ptN/QMzhzG5F5DxcFLGYRXd3bTO8ZIrvbNPQAi0=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: OAuth WG Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 18:00:54 -0000 On 09/07/2011 10:49 AM, John Kemp wrote: > Mike, > > On Sep 7, 2011, at 1:26 PM, Michael Thomas wrote: > > >> On 09/07/2011 10:17 AM, Igor Faynberg wrote: >> >>> +300 (if I can do that) to indicate my strong agreement. But if somehow it is decided to add a few sentences on saying that OAuth cannot deal with key-logging, I will insist on adding two sentences each on OAuth being unable to deal with 1) earthquakes, 2) certain contageous diseases, etc., [...] >>> >> Please, enough of the hyperbole. It is not clear or obvious whether this is >> a protocol issue or not. It brings into question whether the protocol is worth >> deploying at all, and that is surely an issue. As far as I can tell, there is very >> little upside to deploying OAuth in the general case over, say, Basic+TLS. In >> fact, you guys have convinced me that OAuth gives inferior protection at >> considerable expense for all concerned. >> > I'm sorry that you haven't received an easy introduction to the OAuth WG. But that's no reason to spout nonsense. OAuth seeks to replace something that was once rather common - the need for a user to type (and/or store) his password for site A at site B, to let site B get their content from site A. Now, site B gets a token in the common case, rather than the user's password for site A. This doesn't remove the need for a user to exercise common sense in deciding where to type her password. But it does, in the common case, mitigate the password being shared among websites, or across networks multiple times. > > You are right that OAuth doesn't mitigate key logging or other similar attacks on the client OS/platform itself. But that doesn't make it inferior to other methods of web authorization. > > It's not nonsense: 1) App prompts me for my credentials to Facebook -- I wonder whether I trust the app. 2) App puts me in a Facebook login window -- I figure that it's secure and don't wonder whether I trust the app. #2 sure looks worse than #1. Mike From igor.faynberg@alcatel-lucent.com Wed Sep 7 11:07: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 D176F21F8CF9 for ; Wed, 7 Sep 2011 11:07:16 -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 Y7BHq8-VDks3 for ; Wed, 7 Sep 2011 11:07:16 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D96DC21F8C9B for ; Wed, 7 Sep 2011 11:07:15 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p87I952q014733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Sep 2011 13:09:05 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87I94eX011709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Sep 2011 13:09:04 -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 p87I947V016142; Wed, 7 Sep 2011 13:09:04 -0500 (CDT) Message-ID: <4E67B340.3020508@alcatel-lucent.com> Date: Wed, 07 Sep 2011 14:09:04 -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: <4E665B25.6090709@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <4E66B964.2060808@stpeter.im> <4E66BFF0.9020008@gmail.com> <4E66C407.9090209@stpeter.im> <4E66C521.5070804@mtcc.com> <1315358847.25169.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E66CF9A.8000905@mtcc.com> <255B9BB34FB7D647A506DC292726F6E1128DF46CA4@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128DF46CA4@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 18:07:17 -0000 Good eye! Seeing this now, I agree, but I admit I never fully understood what "embedded uses-agents" were before. Igor On 9/6/2011 11:52 PM, Manger, James H wrote: > A strange aspects of this thread is that the current draft already talks about exactly this issue: > > draft-ietf-oauth-v2-21 section 9 "Native Applications" > > "...Native applications can invoke an external user-agent or > embed a user-agent within the application > ... > Embedded user-agents pose a security challenge because resource > owners are authenticating in an unidentified window without access > to the visual protections found in most external user-agents. > Embedded user-agents educate end-user to trust unidentified > requests for authentication (making phishing attacks easier to > execute)." > > The webView that Michael Thomas talks about is an "embedded user-agent". > > -- > James Manger > > > ---------- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Michael Thomas > > ... > At this point, it would be just nice for the industry to know that the issue > even *exists*. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From david@alkaline-solutions.com Wed Sep 7 11: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 5AC1421F8CA9 for ; Wed, 7 Sep 2011 11:18:26 -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 fVkJ2vSzNHim for ; Wed, 7 Sep 2011 11:18:25 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id C42D921F8CB3 for ; Wed, 7 Sep 2011 11:18:23 -0700 (PDT) Received: from [10.1.1.80] (unknown [205.169.68.218]) by alkaline-solutions.com (Postfix) with ESMTPSA id 05D05315E9; Wed, 7 Sep 2011 18:20:15 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_220EC92F-48DD-4F29-A384-E19B9A191429"; protocol="application/pkcs7-signature"; micalg=sha1 From: David Waite In-Reply-To: <4E67B1C3.60306@mtcc.com> Date: Wed, 7 Sep 2011 12:20:01 -0600 Message-Id: <36ACF4D0-50DA-46B9-84A4-3B4193D79334@alkaline-solutions.com> References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <4E67B1C3.60306@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1244.3) Cc: OAuth WG Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 18:18:26 -0000 --Apple-Mail=_220EC92F-48DD-4F29-A384-E19B9A191429 Content-Type: multipart/alternative; boundary="Apple-Mail=_7C377318-4B18-485F-B971-4D919C38257D" --Apple-Mail=_7C377318-4B18-485F-B971-4D919C38257D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 7, 2011, at 12:02 PM, Michael Thomas wrote: >=20 > It's not nonsense: >=20 > 1) App prompts me for my credentials to Facebook -- I wonder whether > I trust the app. > 2) App puts me in a Facebook login window -- I figure that it's secure = and > don't wonder whether I trust the app. >=20 The assumption for #1 is that the app gave you a user experience for = entering your facebook credentials that looks different than the actual = facebook login window. If the app is malicious, this will most likely = not be the case. The advantage OAuth provides is that it can vet/ban clients which are = doing malicious things. However, even a client with no oauth support at = all is still capable of providing a realistic-looking login window using = an embedded user agent, and capturing the real username/password. -DW= --Apple-Mail=_7C377318-4B18-485F-B971-4D919C38257D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

It's not = nonsense:

1) App prompts me for my credentials to Facebook -- I = wonder whether
   I trust the app.
2) App puts me = in a Facebook login window -- I figure that it's secure and
=    don't wonder whether I trust the = app.

The assumption for #1 is that the = app gave you a user experience for entering your facebook credentials = that looks different than the actual facebook login window. If the app = is malicious, this will most likely not be the = case.

The advantage OAuth provides is that it = can vet/ban clients which are doing malicious things. However, even a = client with no oauth support at all is still capable of providing a = realistic-looking login window using an embedded user agent, and = capturing the real = username/password.

-DW
= --Apple-Mail=_7C377318-4B18-485F-B971-4D919C38257D-- --Apple-Mail=_220EC92F-48DD-4F29-A384-E19B9A191429 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM/jCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGwjCCBaqg AwIBAgIDAnw3MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTEwNDI5MTYwMDA1WhcNMTIwNDI5MDk0MTQ1WjBPMSAwHgYDVQQNExc0MTUzODYtOTg4TWcyb1h3 eDl2N0RpVDErMCkGCSqGSIb3DQEJARYcZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMoVPfjKn04Z9FqHOInDmpmwVy2q2Ah9fckK7EOl aav/NzExRFFm7GyrCPRnZ4wbfKXi1fwTiZhukHErRWpwE19SF7uO5/oAXzAAADwM7RFZfu03XuOg dndZx3yEaGAw5nhm2BcsQa4hCA7/bsyAFCD0J3O92V95kbQUy+aY6aERgKxplCjQ3gGj6ywDfi0t 6DSNJSd8f9op3bBPAPaQWKvVBFJiUBw9ty1DUcQbrvolCrYcJcm8UOoK3pCUIl3GXbft8DQkTS7g LThCqyqYHOGHHXKj0tQGUtu6CuybmUX6dVUsvDmKvFjFvRSpLRKHNHxwlK9kyqq8l/7B3w1BbVMC AwEAAaOCA2cwggNjMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQULDXoErIVeC/Ev5d69RG2HcZQHvYwHwYDVR0jBBgwFoAUU3Lt kpzg2ssBXHx+ljVO8tS4UYIwJwYDVR0RBCAwHoEcZGF2aWRAYWxrYWxpbmUtc29sdXRpb25zLmNv bTCCAdEGA1UdIASCAcgwggHEMIIBwAYLKwYBBAGBtTcBAgIwggGvMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIIBRQYIKwYBBQUHAgIwggE3MCcWIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEaggEKVGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNz dWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgcG9saWN5IGFuZCBtYXkgYmUgcmVs aWVkIHVwb24gb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgYW5kIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuIExpYWJpbGl0eSBhbmQgd2FycmFudGll cyBhcmUgbGltaXRlZCEwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20v Y3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Au c3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBx/ziwxBnt5gAl0eBV Nj+1xFrXwC27uD9gUwFuJGeDjWj1ZmDGTMQ2G1f4eyVqr8+MHPADyKAdtuF/Sm6Isvt2pH8Oxjf7 IbFcGudXH92NvYoPrAC0TwVeahxk87qc6ojxJ5oe82LPkkFtwYl5xuZmUlfstqEBJvnffaxe9BY/ CxLIbNRQoeOrVHtlqcM3vQcmhEF9yhuXurqpSELVr4rSNOzbFem/ZxKK0ZmNVybh675BNwS3BGWk 56SiEaUXHYJe8GRk0Bb6P44g2rZWe7G0NRFyt8qXuia9fN4I89wpOn6S1LrPDD1QdRpTrEMM85Wh sszTXYW6fCMTlyVH+wBQMYIDbzCCA2sCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBD QQIDAnw3MAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTExMDkwNzE4MjAwMlowIwYJKoZIhvcNAQkEMRYEFId3oqosN5KMaTR+NYtiGnOHZQzW MIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAnw3MIGn BgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMCfDcwDQYJ KoZIhvcNAQEBBQAEggEAsSQeJTs+mjJ+qVDcH7k6RkaWBp/an31ROB32eygYIqHzSQB3P+N2SQ9d bAJxr2qMvCXqYMhMYopVG7kBxIZmxNUmoOgJld1J5BSl1ZFifDgrw3R6PffTcCo2xmrPagGOk9wh UAGao2SdJoXjzvoIqCndrFzAc9pVCYxN5MqPm1fezwWTsC3+vqAztiBjSTRJupYJiqgzAHGhYtkM 2/8EXL7ikc0LBIuWf2tzBa6vT41PDW3smOBxkK35LjCfb3qSAfiaS/RyXVgkz5XpojFx7hJ0rm5m V3EpXwozJpbjmpHh5GNTB5Ro3OyISKK2kl9IVyF7X0VGIQhp/4wMkyV90wAAAAAAAA== --Apple-Mail=_220EC92F-48DD-4F29-A384-E19B9A191429-- From phil.hunt@oracle.com Wed Sep 7 11:21: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 3843F21F8D16 for ; Wed, 7 Sep 2011 11:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.878 X-Spam-Level: X-Spam-Status: No, score=-4.878 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, J_CHICKENPOX_53=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 RRtV98KjvxXx for ; Wed, 7 Sep 2011 11:20:59 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4C47821F8CF2 for ; Wed, 7 Sep 2011 11:20:59 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p87IMkYA030719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 18:22:48 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p87IMj1L003316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 18:22:46 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87IMeYv013481; Wed, 7 Sep 2011 13:22:40 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 11:22:40 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <4E67B1C3.60306@mtcc.com> Date: Wed, 7 Sep 2011 11:22:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2DEC7481-6359-4E6D-9F98-D97F42AF1A19@oracle.com> References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <4E67B1C3.60306@mtcc.com> To: Michael Thomas 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.0A090206.4E67B678.0111:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: OAuth WG Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 18:21:00 -0000 Michael, You should read the threat model document. This document has more = editorial on these kinds of issues. The core spec deals in specific items implementors must do or not do = from an inter-op perspective. The threat model document goes into some details about the need for = authenticating clients, etc and the counter-measures that should be = considered. This is likely more in line with your concerns. In my opinion, the issue of malware and of component "trust" is to me = something that belongs in whitepapers, product manuals, etc and does not = belong in the protocol specification. In a sense the issue is the kind = of thing a "consultant" would provide and thus this type of consultative = information fits into broader best practices of desktops and servers = management and has no direct relevance on OAuth. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-09-07, at 11:02 AM, Michael Thomas wrote: > On 09/07/2011 10:49 AM, John Kemp wrote: >> Mike, >>=20 >> On Sep 7, 2011, at 1:26 PM, Michael Thomas wrote: >>=20 >> =20 >>> On 09/07/2011 10:17 AM, Igor Faynberg wrote: >>> =20 >>>> +300 (if I can do that) to indicate my strong agreement. But if = somehow it is decided to add a few sentences on saying that OAuth cannot = deal with key-logging, I will insist on adding two sentences each on = OAuth being unable to deal with 1) earthquakes, 2) certain contageous = diseases, etc., [...] >>>> =20 >>> Please, enough of the hyperbole. It is not clear or obvious whether = this is >>> a protocol issue or not. It brings into question whether the = protocol is worth >>> deploying at all, and that is surely an issue. As far as I can tell, = there is very >>> little upside to deploying OAuth in the general case over, say, = Basic+TLS. In >>> fact, you guys have convinced me that OAuth gives inferior = protection at >>> considerable expense for all concerned. >>> =20 >> I'm sorry that you haven't received an easy introduction to the OAuth = WG. But that's no reason to spout nonsense. OAuth seeks to replace = something that was once rather common - the need for a user to type = (and/or store) his password for site A at site B, to let site B get = their content from site A. Now, site B gets a token in the common case, = rather than the user's password for site A. This doesn't remove the need = for a user to exercise common sense in deciding where to type her = password. But it does, in the common case, mitigate the password being = shared among websites, or across networks multiple times. >>=20 >> You are right that OAuth doesn't mitigate key logging or other = similar attacks on the client OS/platform itself. But that doesn't make = it inferior to other methods of web authorization. >>=20 >> =20 >=20 > It's not nonsense: >=20 > 1) App prompts me for my credentials to Facebook -- I wonder whether > I trust the app. > 2) App puts me in a Facebook login window -- I figure that it's secure = and > don't wonder whether I trust the app. >=20 > #2 sure looks worse than #1. >=20 > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mike@mtcc.com Wed Sep 7 11:26: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 0D24A21F8B38 for ; Wed, 7 Sep 2011 11:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 w4XCgXm4pIvH for ; Wed, 7 Sep 2011 11:26:28 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2517321F8B20 for ; Wed, 7 Sep 2011 11:26:18 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87IS6E2013131 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 11:28:07 -0700 Message-ID: <4E67B7B6.2010506@mtcc.com> Date: Wed, 07 Sep 2011 11:28:06 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: David Waite References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <4E67B1C3.60306@mtcc.com> <36ACF4D0-50DA-46B9-84A4-3B4193D79334@alkaline-solutions! .com> In-Reply-To: <36ACF4D0-50DA-46B9-84A4-3B4193D79334@alkaline-solutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1499; t=1315420087; x=1316284087; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20David=20Waite=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=0BKP2qNmWGU1UdMJD8jpmIMRh34O/SJ7n15iOCpGfNY=; b=Riaxn4M77L+k1Vhr9uHYtOnL4/UeQNcFcVvbkZfmhICYzxVk8XsasoP7aT HX1o51yQDhVsa7qmWOIisO91KcNz3phIxfAYjLGQCx3PcoSSx6jfaOTUlFK9 v1f8WdFnTHKTPBFbHEdwaIKrAPH1C6WTs/AYS/4MvTXoRjHRXPtKs=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: OAuth WG Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 18:26:29 -0000 On 09/07/2011 11:20 AM, David Waite wrote: > > On Sep 7, 2011, at 12:02 PM, Michael Thomas wrote: >> >> It's not nonsense: >> >> 1) App prompts me for my credentials to Facebook -- I wonder whether >> I trust the app. >> 2) App puts me in a Facebook login window -- I figure that it's >> secure and >> don't wonder whether I trust the app. >> > The assumption for #1 is that the app gave you a user experience for > entering your facebook credentials that looks different than the > actual facebook login window. If the app is malicious, this will most > likely not be the case. > > The advantage OAuth provides is that it can vet/ban clients which are > doing malicious things. However, even a client with no oauth support > at all is still capable of providing a realistic-looking login window > using an embedded user agent, and capturing the real username/password. > Absolutely. But before facebook started doing this oauth-like authentication (from the UX standpoint), there wasn't any reason why a user would expect to see that facebook-like authentication page. But now users are getting taught to trust that facebook authentication page inside untrusted apps. So it's the whole ecosystem that's problematic, but it doesn't seem right to tout oauth as a solution which is how it's coming across on the outside. Not wanting to very clearly fess up in the protocol document makes it sound like some people view that as a feature, not a bug. Mike From melinda.shore@gmail.com Wed Sep 7 11:32: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 24CD421F8C45 for ; Wed, 7 Sep 2011 11:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 Xym6XQsjWjv4 for ; Wed, 7 Sep 2011 11:32:40 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 999B721F8C34 for ; Wed, 7 Sep 2011 11:32:40 -0700 (PDT) Received: by gwb17 with SMTP id 17so4797452gwb.15 for ; Wed, 07 Sep 2011 11:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ns/bt2ichiC+R/2/fcU/gc3OndN/0GoZtHiYOsBIJp0=; b=tkmjMZ55l7qcsALxpyNPZMjyv8ZgLPdiRuJyATFoSUKlZdCHMKD0XSHaHnaEmVW8Fj qZwEpaNN1MCnFtGA8p0dzwNKCwJFN4oSa9vLLZGtMTooFqoMcQzFP0hC4ts+/bqYdAYw lK4OvnwcKJ7sKlomFLpU12x17AP/TVFgMysfE= Received: by 10.68.33.201 with SMTP id t9mr254894pbi.148.1315420470117; Wed, 07 Sep 2011 11:34:30 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu. [137.229.12.236]) by mx.google.com with ESMTPS id x6sm7284578pba.5.2011.09.07.11.34.27 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 11:34:28 -0700 (PDT) Message-ID: <4E67B93C.3060909@gmail.com> Date: Wed, 07 Sep 2011 10:34:36 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: oauth@ietf.org References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <4E67B1C3.60306@mtcc.com> <2DEC7481-6359-4E6D-9F98-D97F42AF1A19@oracle.com> In-Reply-To: <2DEC7481-6359-4E6D-9F98-D97F42AF1A19@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 18:32:41 -0000 On 09/07/2011 10:22 AM, Phil Hunt wrote: > You should read the threat model document. This document has more editorial on these kinds of issues. This seems reasonable to me, and thank you so much for departing from what seems to be standard working group mode by dealing with this like an adult. It seems to me that there are some usability problems that while not being unique to oauth, really aren't that much like what we usually run into with on-the-wire protocols. Documents in the security area have typically not dealt with usability issues even when, perhaps, they should, given their impact on how secure a technology is in the field. Getting that into a threat model document sounds about right to me. Melinda From stpeter@stpeter.im Wed Sep 7 11:40: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 8B4C921F8C7E for ; Wed, 7 Sep 2011 11:40:24 -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 IpP2ymHYeH3U for ; Wed, 7 Sep 2011 11:40:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E264521F8C79 for ; Wed, 7 Sep 2011 11:40:23 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A4424418BB; Wed, 7 Sep 2011 12:45:10 -0600 (MDT) Message-ID: <4E67BB03.3080904@stpeter.im> Date: Wed, 07 Sep 2011 12:42:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Melinda Shore References: <4E665B25.6090709@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <4E67B1C3.60306@mtcc.com> <2DEC7481-6359-4E6D-9F98-D97F42AF1A19@oracle.com> <4E67B93C.3060909@gmail.com> In-Reply-To: <4E67B93C.3060909@gmail.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] problem statement 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, 07 Sep 2011 18:40:24 -0000 On 9/7/11 12:34 PM, Melinda Shore wrote: > On 09/07/2011 10:22 AM, Phil Hunt wrote: >> You should read the threat model document. This document has more >> editorial on these kinds of issues. > > This seems reasonable to me, and thank you so much for departing > from what seems to be standard working group mode by dealing with > this like an adult. Is it really juvenile to point out that specs for widely-deployed security technologies also don't cover threats like keyloggers? > It seems to me that there are some usability problems that while > not being unique to oauth, really aren't that much like what > we usually run into with on-the-wire protocols. Documents in > the security area have typically not dealt with usability issues > even when, perhaps, they should, given their impact on how > secure a technology is in the field. Getting that into a threat > model document sounds about right to me. Agreed. In fact, I hope that we'll all be able to turn more attention to the threat-model document soon, because it's quite comprehensive and useful. The usability issues are indeed a bit different here, although usability is not exactly easy in the case of, say, TLS with PKI certs issued by certification authorities (as witness recent events -- have you scrubbed your root cert store lately?). Peter -- Peter Saint-Andre https://stpeter.im/ From eran@hueniverse.com Wed Sep 7 12:13: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 D12A221F8D56 for ; Wed, 7 Sep 2011 12:13:23 -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 MDdd5PM8HzR7 for ; Wed, 7 Sep 2011 12:13:23 -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 33FFD21F8D57 for ; Wed, 7 Sep 2011 12:13:23 -0700 (PDT) Received: (qmail 28985 invoked from network); 7 Sep 2011 19:15:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 19:15:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 7 Sep 2011 12:14:50 -0700 From: Eran Hammer-Lahav To: Michael Thomas Date: Wed, 7 Sep 2011 12:12:54 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: Acxtg1Jf+aH1E+O0RTCtfUK/dHOnbAACMKow Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> In-Reply-To: <4E67A942.1070200@mtcc.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 19:13:23 -0000 Michael, I suggest you go back and read the entire thread again: http://www.ietf.org/mail-archive/web/oauth/current/maillist.html I don't think you have been listening to the 11 (!) people who all complete= ly disagree with you and dismiss your suggestions (on technical grounds). T= he one person who supported your plea didn't actually make any technical co= ntribution. If anyone wants to make accusations about behaving like adults, that should= be the 11 people who tried to explain why you are simply wrong and were co= mpletely ignored by you. Any perceived hostility is easily justified by hav= ing to explain the same thing over and over again to someone who refuses to= list and insists on labeling this work as lacking and insecure. We take re= al security pretty seriously here. You asked a question as someone "very new to thinking about this problem sp= ace" and was answered by experts. The fact that you refuse to accept their = answers is while being , at this point, your problem. You were given multip= le opportunities to present an alternative text and technical justification= to support it, but refused to do so. =20 You might not like my tone, but I consider making a statement like this: > In fact, you guys have convinced me that OAuth gives inferior protection = at > considerable expense for all concerned. an irresponsible and serious offense - the kind of baseless FUD that can ca= use real damage to important work. EHL From aiden449@gmail.com Wed Sep 7 12:22: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 146A321F8B28 for ; Wed, 7 Sep 2011 12:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=0.298, 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 X+FWOswu40VK for ; Wed, 7 Sep 2011 12:22:01 -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 E43CB21F8B16 for ; Wed, 7 Sep 2011 12:22:00 -0700 (PDT) Received: by qyk35 with SMTP id 35so4854985qyk.10 for ; Wed, 07 Sep 2011 12:23: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:date:message-id:subject:from:to :cc:content-type; bh=xQn+oc5U0blMbznTmRTmeGjBp0K+tVaCxq1trxDn7aM=; b=MdWOB2uNaMK29E3BS8HH0dn5dRSYA4IHFrAgxwXjiH/25GAblfp9C+GNBUTzbAxVSh z/bDNkEz1EbtjmGeD0C+yW6Wb95HlsPa4vqOfBCbyBepCtkuAjOEp1NbYucovnLGON29 IoVuMXdfu9/Zuq8k1eDZf4hz9V/NqY8qSeqCA= MIME-Version: 1.0 Received: by 10.229.71.161 with SMTP id h33mr5063535qcj.276.1315423430630; Wed, 07 Sep 2011 12:23:50 -0700 (PDT) Received: by 10.229.249.71 with HTTP; Wed, 7 Sep 2011 12:23:50 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E665B25.6090709@mtcc.com> <4E6661FA.7050804@alcatel-lucent.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 7 Sep 2011 20:23:50 +0100 Message-ID: From: Aiden Bell To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e65058104fdbad04ac5ee283 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 19:22:02 -0000 --0016e65058104fdbad04ac5ee283 Content-Type: text/plain; charset=ISO-8859-1 I'm gonna ditch the (lengthy) reply I was drafting and agree with the below. Personally, my communication with the OAuth WG has been spot on. Warm welcome, open minds and a very good process to getting my requirements/concerns heard and pragmatic change enacted. All I saw here was foot stomping and a counter-productive approach to communicating by those not getting their way. On 7 September 2011 20:12, Eran Hammer-Lahav wrote: > Michael, > > I suggest you go back and read the entire thread again: > > http://www.ietf.org/mail-archive/web/oauth/current/maillist.html > > I don't think you have been listening to the 11 (!) people who all > completely disagree with you and dismiss your suggestions (on technical > grounds). The one person who supported your plea didn't actually make any > technical contribution. > > If anyone wants to make accusations about behaving like adults, that should > be the 11 people who tried to explain why you are simply wrong and were > completely ignored by you. Any perceived hostility is easily justified by > having to explain the same thing over and over again to someone who refuses > to list and insists on labeling this work as lacking and insecure. We take > real security pretty seriously here. > > You asked a question as someone "very new to thinking about this problem > space" and was answered by experts. The fact that you refuse to accept their > answers is while being , at this point, your problem. You were given > multiple opportunities to present an alternative text and technical > justification to support it, but refused to do so. > > You might not like my tone, but I consider making a statement like this: > > > In fact, you guys have convinced me that OAuth gives inferior protection > at > > considerable expense for all concerned. > > an irresponsible and serious offense - the kind of baseless FUD that can > cause real damage to important work. > > EHL > > _______________________________________________ > 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 --0016e65058104fdbad04ac5ee283 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm gonna ditch the (lengthy) reply I was drafting and agree with the b= elow.

Personally, my communication with the OAuth WG has been spot o= n. Warm welcome, open minds
and a very good process to getting my requir= ements/concerns heard and pragmatic change enacted.

All I saw here was foot stomping and a counter-productive approach to c= ommunicating by those
not getting their way.

On 7 September 2011 20:12, Eran Hammer-Lahav <<= a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com> wr= ote:
Michael,

I suggest you go back and read the entire thread again:

http://www.ietf.org/mail-archive/web/oauth/current/mail= list.html

I don't think you have been listening to the 11 (!) people who all comp= letely disagree with you and dismiss your suggestions (on technical grounds= ). The one person who supported your plea didn't actually make any tech= nical contribution.

If anyone wants to make accusations about behaving like adults, that should= be the 11 people who tried to explain why you are simply wrong and were co= mpletely ignored by you. Any perceived hostility is easily justified by hav= ing to explain the same thing over and over again to someone who refuses to= list and insists on labeling this work as lacking and insecure. We take re= al security pretty seriously here.

You asked a question as someone "very new to thinking about this probl= em space" and was answered by experts. The fact that you refuse to acc= ept their answers is while being , at this point, your problem. You were gi= ven multiple opportunities to present an alternative text and technical jus= tification to support it, but refused to do so.

You might not like my tone, but I consider making a statement like this:

> In fact, you guys have convinced me that OAuth gives inferior protecti= on at
> considerable expense for all concerned.

an irresponsible and serious offense - the kind of baseless FUD that = can cause real damage to important work.

EHL

_______________________________________________
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
--0016e65058104fdbad04ac5ee283-- From mike@mtcc.com Wed Sep 7 12: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 97DAF21F8C34 for ; Wed, 7 Sep 2011 12:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 i4IH7F7Fq+CU for ; Wed, 7 Sep 2011 12:23:01 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 068BC21F8B28 for ; Wed, 7 Sep 2011 12:23:00 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87JOnvD002235 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 12:24:49 -0700 Message-ID: <4E67C501.3060001@mtcc.com> Date: Wed, 07 Sep 2011 12:24:49 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=522; t=1315423490; x=1316287490; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Eran=20Hammer-Lahav=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=GJSlYvXIYMU6ixLFgChQkGz4LDp/FffxWb49anRiQ9E=; b=hME7D4Ekt3T8hu/VO14vmNMG4iTVuLSZsTeb6Q71q2ssu2fdpbSyeyplKC +ldLVnJzAoFh9VpuTEsQ4nLv/dA+Lud7c8POkmybL4HrAdjMJWnuwA2EJ4xq 2qpNjWrarSl6O2sQH+yRHHeFT1LB5K8ULFCM5E7/PXiHGwPg53abQ=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 19:23:01 -0000 On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote: [more browbeating elided] > In fact, you guys have convinced me that OAuth gives inferior > protection at >> considerable expense for all concerned. >> > an irresponsible and serious offense - the kind of baseless FUD that can cause real damage to important work. > I have written down at least 3 or 4 times why I think it's inferior. Nobody attacking the messenger including yourself has answered it. There's FUD here, but not from me. Mike From mike@mtcc.com Wed Sep 7 12:25: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 16EBE21F8C34 for ; Wed, 7 Sep 2011 12:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 kXQCaD4yAi81 for ; Wed, 7 Sep 2011 12:25:36 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 51C8221F8B28 for ; Wed, 7 Sep 2011 12:25:36 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87JRMOj003366 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 12:27:23 -0700 Message-ID: <4E67C59A.10904@mtcc.com> Date: Wed, 07 Sep 2011 12:27:22 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Aiden Bell References: <4E665B25.6090709@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2679; t=1315423643; x=1316287643; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Aiden=20Bell=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=n0ylsdmhQ1NgNo5j7iWMXLTH5P7o98HDa72pfNAd0jI=; b=acEXPpoF9A6W3BkG8eAVtWzHg/BGKqCYwDQ/By59pGplFCcDCAk4hukdgB ZpHFjvFUtaTIBJhHFUAheCQ2tpGAEwoGEMSn5/PzyEQhCFal0vm6OiLMhKD3 GGTFga5If19i60QtDTdY+eCdpYry1OaHaJXxTTpTh3VgY6Y4jXCI0=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 19:25:37 -0000 I would ask the chairs to keep personal attacks in check. Thank you. Mike On 09/07/2011 12:23 PM, Aiden Bell wrote: > I'm gonna ditch the (lengthy) reply I was drafting and agree with the > below. > > Personally, my communication with the OAuth WG has been spot on. Warm > welcome, open minds > and a very good process to getting my requirements/concerns heard and > pragmatic change enacted. > > All I saw here was foot stomping and a counter-productive approach to > communicating by those > not getting their way. > > On 7 September 2011 20:12, Eran Hammer-Lahav > wrote: > > Michael, > > I suggest you go back and read the entire thread again: > > http://www.ietf.org/mail-archive/web/oauth/current/maillist.html > > I don't think you have been listening to the 11 (!) people who all > completely disagree with you and dismiss your suggestions (on > technical grounds). The one person who supported your plea didn't > actually make any technical contribution. > > If anyone wants to make accusations about behaving like adults, > that should be the 11 people who tried to explain why you are > simply wrong and were completely ignored by you. Any perceived > hostility is easily justified by having to explain the same thing > over and over again to someone who refuses to list and insists on > labeling this work as lacking and insecure. We take real security > pretty seriously here. > > You asked a question as someone "very new to thinking about this > problem space" and was answered by experts. The fact that you > refuse to accept their answers is while being , at this point, > your problem. You were given multiple opportunities to present an > alternative text and technical justification to support it, but > refused to do so. > > You might not like my tone, but I consider making a statement like > this: > > > In fact, you guys have convinced me that OAuth gives inferior > protection at > > considerable expense for all concerned. > > an irresponsible and serious offense - the kind of baseless FUD > that can cause real damage to important work. > > EHL > > _______________________________________________ > 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 From aiden449@gmail.com Wed Sep 7 12:29: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 3B5FD21F8D0C for ; Wed, 7 Sep 2011 12:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.322 X-Spam-Level: X-Spam-Status: No, score=-3.322 tagged_above=-999 required=5 tests=[AWL=0.276, 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 2TvkMCUtf0J0 for ; Wed, 7 Sep 2011 12:29:05 -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 7D8BC21F8CF3 for ; Wed, 7 Sep 2011 12:29:05 -0700 (PDT) Received: by qyk35 with SMTP id 35so4859230qyk.10 for ; Wed, 07 Sep 2011 12:30: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; bh=UIBybwgtnHnl4Jvqek1lIGzkxaXI2CQKIDEbZWxJc2o=; b=EuUXke3t9p6y99OsokDgUfIifjILYwY/KYwTLa7OHzC3gNxMWPXlRzQqORWksjHN7Z pR4buOSns5DLF6CZFKDsdIOrcyrKtaowDdk+8LHcUkMq2VNuAGPOWr3LpNjf+utC1ijr Rh4GNGYOT/P2U5BsmDZgoE/O3A+unBa5viWXk= MIME-Version: 1.0 Received: by 10.224.221.147 with SMTP id ic19mr5157041qab.293.1315423855358; Wed, 07 Sep 2011 12:30:55 -0700 (PDT) Received: by 10.229.249.71 with HTTP; Wed, 7 Sep 2011 12:30:55 -0700 (PDT) In-Reply-To: <4E67C501.3060001@mtcc.com> References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> Date: Wed, 7 Sep 2011 20:30:55 +0100 Message-ID: From: Aiden Bell To: Michael Thomas Content-Type: multipart/alternative; boundary=20cf306f733aa0b12604ac5efb4b Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 19:29:06 -0000 --20cf306f733aa0b12604ac5efb4b Content-Type: text/plain; charset=ISO-8859-1 On 7 September 2011 20:24, Michael Thomas wrote: > On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote: > > [more browbeating elided] > > > In fact, you guys have convinced me that OAuth gives inferior protection >> at >> >>> considerable expense for all concerned. >>> >>> >> an irresponsible and serious offense - the kind of baseless FUD that can >> cause real damage to important work. >> >> > > I have written down at least 3 or 4 times why I think it's inferior. > But no proposed solution or anything constructive past arguing with people who understand and are only here to help. Helping people who don't listen or appear to show any tact in the face of opposing concensus is hard. -- ------------------------------------------------------------------ Never send sensitive or private information via email unless it is encrypted. http://www.gnupg.org --20cf306f733aa0b12604ac5efb4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 7 September 2011 20:24, Michael Thoma= s <mike@mtcc.com&= gt; wrote:
On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote:

[more browbeating elided]


In fact, you guys have convinced me that OAuth gives inferior protection at=
considerable expense for all concerned.
=A0 =A0
an irresponsible and serious offense - the kind of baseless FUD that can ca= use real damage to important work.
=A0

I have written down at least 3 or 4 times why I think it's inferior.
But no proposed solution or anything constructive past a= rguing with people who understand and are only here to help.
Helping peo= ple who don't listen or appear to show any tact in the face of opposing= concensus is hard.


--
----------------------------------= --------------------------------
Never send sensitive or private informa= tion via email unless it is encrypted. htt= p://www.gnupg.org
--20cf306f733aa0b12604ac5efb4b-- From stpeter@stpeter.im Wed Sep 7 12:30: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 908BC21F8D0C for ; Wed, 7 Sep 2011 12:30: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=[AWL=0.000, 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 1olViZfO04Bo for ; Wed, 7 Sep 2011 12:30:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DC1F121F8CF3 for ; Wed, 7 Sep 2011 12:30:36 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BEAC540E87; Wed, 7 Sep 2011 13:35:23 -0600 (MDT) Message-ID: <4E67C6C9.1070704@stpeter.im> Date: Wed, 07 Sep 2011 13:32:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Michael Thomas References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> In-Reply-To: <4E67C501.3060001@mtcc.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] problem statement 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, 07 Sep 2011 19:30:37 -0000 On 9/7/11 1:24 PM, Michael Thomas wrote: > On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote: > > [more browbeating elided] > >> In fact, you guys have convinced me that OAuth gives inferior >> protection at >>> considerable expense for all concerned. >>> >> an irresponsible and serious offense - the kind of baseless FUD that >> can cause real damage to important work. >> > > I have written down at least 3 or 4 times why I think it's inferior. > Nobody attacking the messenger including yourself has answered > it. There's FUD here, but not from me. Mike, did you propose text to address the concern? Per recent discussion I think the threat-model document is the right place for it, so please take a look at that spec to see where your proposed text can slot in. Peter -- Peter Saint-Andre https://stpeter.im/ From mike@mtcc.com Wed Sep 7 12:38: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 3A36F21F8B22 for ; Wed, 7 Sep 2011 12:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599, SARE_ADULT2=1.42] 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 8lok0OooGShs for ; Wed, 7 Sep 2011 12:38:14 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 94A1321F8B17 for ; Wed, 7 Sep 2011 12:38:14 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87Je3DP008377 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 12:40:03 -0700 Message-ID: <4E67C893.5060505@mtcc.com> Date: Wed, 07 Sep 2011 12:40:03 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> <4E67C6C9.1070704@stpete! r.im> In-Reply-To: <4E67C6C9.1070704@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2535; t=1315424403; x=1316288403; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Peter=20Saint-Andre=20 |Content-Type:=20text/plain=3B=20charset=3DUTF-8=3B=20forma t=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=ukT4i9yvtQkFYm1mIQcPtDKLfLEPSUzKEi0steP+I2E=; b=DZp/ig+XLwxvJPANDl6EZxykdwyq2gMx+Tu3VZVaFtQMJNfBqHWsMWsSDn JkpANsAYQQTN33VE1GjFPdDzJb9YKwhTuai0Ot2JW8pJinaoO2+rbZDXKkh9 nORv+d4mLcxbc3cMioPy8ohlPNP5r3rfNF+MEG0hAG6L1xNVjMe7s=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 19:38:15 -0000 On 09/07/2011 12:32 PM, Peter Saint-Andre wrote: > On 9/7/11 1:24 PM, Michael Thomas wrote: > >> On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote: >> >> [more browbeating elided] >> >> >>> In fact, you guys have convinced me that OAuth gives inferior >>> protection at >>> >>>> considerable expense for all concerned. >>>> >>>> >>> an irresponsible and serious offense - the kind of baseless FUD that >>> can cause real damage to important work. >>> >>> >> I have written down at least 3 or 4 times why I think it's inferior. >> Nobody attacking the messenger including yourself has answered >> it. There's FUD here, but not from me. >> > Mike, did you propose text to address the concern? Per recent discussion > I think the threat-model document is the right place for it, so please > take a look at that spec to see where your proposed text can slot in. > Yes, I outlined what I think should be done at a minimum. I've also been told by the editor that he won't consider it. Barry has said that he won't consider it either. Unless the working group is open to changes, I'm not going to waste my time crafting the actual changes. So this is your call. Here's what I wrote previously: [...] Second, I'd say that [section 9] is a good first step, but the text there should be explicit and not pussy-foot around the fact that it means embedded UA's in phone apps and other examples. It should also make clear that the "challenge" (ack, ptui) involves untrusted apps stealing the user's credentials by simply snooping on the UA itself. If there is reasonable mitigation, then by all means add text about it. This is important because I do not think that many people grok the seriousness of the issue, and most especially people who would deploy oauth authentication services. Third, I think that the introduction needs to have an applicability statement of *when/where/what* oauth can be used. That is, do not beat around the bush about the need for the UA to be trustable because that is a basic the assumption that oauth makes. As inconvenient as that may be, it would be far worse for people in the industry to not fully understand the threat. Fourth, it would be *really* nice to hear from folks at Facebook and Twitter who have deployed oauth and oauth-like flows with their experience here, and most especially if they understood the threat ahead of their deployment, and what they do to mitigate it if anything. Mike From eran@hueniverse.com Wed Sep 7 13:03: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 18DC321F8CE0 for ; Wed, 7 Sep 2011 13:03:30 -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 tYJgP0lQAPyX for ; Wed, 7 Sep 2011 13:03:29 -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 3159221F8CDB for ; Wed, 7 Sep 2011 13:03:28 -0700 (PDT) Received: (qmail 25797 invoked from network); 7 Sep 2011 20:05:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 20:05:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 7 Sep 2011 13:05:02 -0700 From: Eran Hammer-Lahav To: Melinda Shore Date: Wed, 7 Sep 2011 13:03:06 -0700 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: AcxtjMuEbqjRG3iRQl6wXpxvi4bS/wABWcng Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F277D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E665B25.6090709@mtcc.com> <4E666512.7010701@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <4E67B1C3.60306@mtcc.com> <2DEC7481-6359-4E6D-9F98-D97F42AF1A19@oracle.com> <4E67B93C.3060909@gmail.com> In-Reply-To: <4E67B93C.3060909@gmail.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@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 20:03:30 -0000 Melinda, We clearly have different views on what it means to "[deal] with this like = an adult". I would like to address what I *think* were your two main points= : the lack of civility in addressing the feedback provided by Mr. Thomas, a= nd the alleged IETF process violation by me as editor. I have not seen any = actual technical argument coming from you in support of this change other t= han 'why not'. While the 11 people who replied to this thread did dismiss the claim and th= e need to address it, the conversation was pretty calm and polite. I sugges= t you go back and read the entire thread: http://www.ietf.org/mail-archive/web/oauth/current/maillist.html Any hints of hostility you find can be justly explained by the frustration = of trying to talk to someone who refuses to listen and insists on making a = change that everyone else objects to. Given that this is a technical workin= g group, I can safely state that this objection was unanimous based on tech= nical arguments. Process-wise, we are operating under clear and explicit directions from the= chairs to only consider changes to the document based on *proposed text* a= nd consensus. As editor, it is completely within my authority to dismiss pr= oposals and changes not matching the criteria set by the chairs, and it is = my stated responsibility to reject changes where there clearly is no consen= sus. While the chairs can change their instructions, someone still has to p= rovide text, which is the only way you can reach consensus. And for the record, in this case, there is clear cut IETF consensus not to = make any changes (1 in support, 11 against, and 1 'why not'). That's a clos= e as the IETF gets to unanimity. I agree that the editor is not empowered t= o make such final declarations, but everyone is free to make that observati= on, including the editor. I have never refused to make a change in face of = clear guidance from the chairs, nor have I ever suggested I have the author= ity to make such final calls. I find that suggestion disrespectful to my un= paralleled contribution to this work over 4 years. Your entire argument is basically 'why not, it's only a few lines in the in= troduction'. I find this both counter-productive and harmful. The suggested= change boils down to explaining to the reader that installing untrusted cl= ients on a user device can have wide repercussions to the security properti= es of this protocol. But such a claim is both obvious (to everyone but one)= and incomplete. It is the incompleteness part that most people objected to, and the fact th= at any attempt at a comprehensive text would mean significant and open-ende= d delay. The number of potential ways for malicious code to find its way on= to a user device are practically unlimited, and every single one of them wi= ll lead to the same security degradation described in this thread. There are certain things we have to take for granted when writing a specifi= cation like this. One of them is the reader's understanding that there are = many factors outside the scope of the protocol, and malware is one of the m= ost obvious factors. I am completely serious when I say that earthquakes (a= s suggested jokingly by others) present equal thread to the security model = of this protocol because the user hand might shake when trying to deny clie= nt access and hitting the approve button instead. So following your login, why not discuss the potential impact of a physical= disruption to the user interaction with the authorization endpoint? I am d= ead serious as I consider the two threats to be of equal relevance to this = document. There are many examples of over-specification causing more harm t= han good and this is clearly one of those cases. 'Why not' is never an acce= ptable argument for making changes, especially at this stage and for a secu= rity protocol. I would also note that every example you tried to give for w= hy accommodating this is the right thing based on past protocols was proved= to be misleading or misguided. I would also note that the proposed changes (guessing based on the informat= ion provided in lieu of actual text) will not result in *any* actionable re= sult by anyone, if only because there is nothing to do about it other than = educate users not to install untrusted software of any kind on any device. Trying to portray the answer below as a more adult response is interesting.= If you note, no one actually suggested we change the security thread model= document, only that it provides a comprehensive description of the protoco= l. I am pretty sure most WG participants will still object to this change m= ade in that document for the same reasons. As editor, I consider this matter closed and will not make any changes base= d on the information presented. You are free ask the chairs to open an issu= e block the progress of the draft until this is resolved to your satisfacti= on. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Melinda Shore > Sent: Wednesday, September 07, 2011 11:35 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] problem statement >=20 > On 09/07/2011 10:22 AM, Phil Hunt wrote: > > You should read the threat model document. This document has more > editorial on these kinds of issues. >=20 > This seems reasonable to me, and thank you so much for departing from > what seems to be standard working group mode by dealing with this like an > adult. >=20 > It seems to me that there are some usability problems that while not bein= g > unique to oauth, really aren't that much like what we usually run into wi= th > on-the-wire protocols. Documents in the security area have typically not > dealt with usability issues even when, perhaps, they should, given their > impact on how secure a technology is in the field. Getting that into a t= hreat > model document sounds about right to me. >=20 > Melinda > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mike@mtcc.com Wed Sep 7 13:15: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 7BF5621F8CF0 for ; Wed, 7 Sep 2011 13:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, SARE_ADULT2=1.42] 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 yRqDuNGqV964 for ; Wed, 7 Sep 2011 13:15:27 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id BC37C21F8AD9 for ; Wed, 7 Sep 2011 13:15:27 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p87KHDHa022635 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 13:17:14 -0700 Message-ID: <4E67D149.8080200@mtcc.com> Date: Wed, 07 Sep 2011 13:17:13 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Kristoph References: <4E665B25.6090709@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> <4E67C6C9.1070704@stpete! r.im> <4E67C893.5060505@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3859; t=1315426635; x=1316290635; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Kristoph=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=EcLeK9UrxgXTPkZovhKC9qBoLdDxJy1ZJ9p873rFT1Y=; b=ZwONiG7aZZUXXp1kPXAg1QCNQ6NIonmQb4NEkP0J1HcUjKHhrq0LKGzaI8 7WApccm2Ro5modQ/OGdoyCQLymKEILZRU7R06QgWlR1vWLgmnRVQBgMR+FoY Yk+CapAWTkOJg5qQl4SWvEz1hYVUAL8b7NMiCSFalmnbeGlOXGjG4=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 20:15:28 -0000 On 09/07/2011 12:56 PM, Kristoph wrote: > Mike, > > I am an implementer of this specification. I am struggling to understand what it is you are trying to communicate. > > The only thing I can discern is that you believe there is a large cadre of software architects / developers who you think have the skill to read and understand this specification, design and implement an OAuth 2.0 server, and yet not understand that a rogue embedded UA would compromise the end users credentials. Is that basically your concern? > I think that the fine point of a rogue embedded UA will be lost on people, yes. Especially those who are specing out the higher level authentication service deployment. We have both Twitter and Facebook out there in the wild who are subject to this attack right now. Are they aware of the attack? I really don't know. Mike > ]{ > > On Sep 7, 2011, at 12:40 PM, Michael Thomas wrote: > > >> On 09/07/2011 12:32 PM, Peter Saint-Andre wrote: >> >>> On 9/7/11 1:24 PM, Michael Thomas wrote: >>> >>> >>>> On 09/07/2011 12:12 PM, Eran Hammer-Lahav wrote: >>>> >>>> [more browbeating elided] >>>> >>>> >>>> >>>>> In fact, you guys have convinced me that OAuth gives inferior >>>>> protection at >>>>> >>>>> >>>>>> considerable expense for all concerned. >>>>>> >>>>>> >>>>>> >>>>> an irresponsible and serious offense - the kind of baseless FUD that >>>>> can cause real damage to important work. >>>>> >>>>> >>>>> >>>> I have written down at least 3 or 4 times why I think it's inferior. >>>> Nobody attacking the messenger including yourself has answered >>>> it. There's FUD here, but not from me. >>>> >>>> >>> Mike, did you propose text to address the concern? Per recent discussion >>> I think the threat-model document is the right place for it, so please >>> take a look at that spec to see where your proposed text can slot in. >>> >>> >> Yes, I outlined what I think should be done at a minimum. I've >> also been told by the editor that he won't consider it. Barry >> has said that he won't consider it either. Unless the working >> group is open to changes, I'm not going to waste my time crafting >> the actual changes. So this is your call. >> >> Here's what I wrote previously: >> >> [...] >> >> Second, I'd say that [section 9] is a good first step, but the text there >> should be explicit and not pussy-foot around the fact that it >> means embedded UA's in phone apps and other examples. It >> should also make clear that the "challenge" (ack, ptui) involves >> untrusted apps stealing the user's credentials by simply snooping >> on the UA itself. If there is reasonable mitigation, then by all means >> add text about it. This is important because I do not think that >> many people grok the seriousness of the issue, and most especially >> people who would deploy oauth authentication services. >> >> Third, I think that the introduction needs to have an applicability >> statement of *when/where/what* oauth can be used. That is, >> do not beat around the bush about the need for the UA to be >> trustable because that is a basic the assumption that oauth makes. >> As inconvenient as that may be, it would be far worse for people >> in the industry to not fully understand the threat. >> >> Fourth, it would be *really* nice to hear from folks at Facebook >> and Twitter who have deployed oauth and oauth-like flows with >> their experience here, and most especially if they understood the >> threat ahead of their deployment, and what they do to mitigate >> it if anything. >> >> >> Mike >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From melinda.shore@gmail.com Wed Sep 7 13:18: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 48C0521F8D4A for ; Wed, 7 Sep 2011 13:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Z+FVBGRGti4d for ; Wed, 7 Sep 2011 13:18:11 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id B798321F8D49 for ; Wed, 7 Sep 2011 13:18:11 -0700 (PDT) Received: by gxk9 with SMTP id 9so223273gxk.40 for ; Wed, 07 Sep 2011 13:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=laVLjnBHe4du92Ipc9Z/taelCO7eLIvHOKxSUfdZHSk=; b=FDupr2k9xoP7izw+zSGIYg5g7SbMnn8fbH9rzTCaLg9IkLFVs3Cpr5yxBkK0kb7LRe /l6r1qDc6Gm5Kgw+lsyP3JbI7I6i1e/k76i9zgNowvmrgqxeh9LVpGO5JroTeNWpse8m jrP6bO0Tu+CKgU0t9BAuSw/awiLi5r2iAQoeE= Received: by 10.231.68.144 with SMTP id v16mr8123726ibi.27.1315426801629; Wed, 07 Sep 2011 13:20:01 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu [137.229.12.236]) by mx.google.com with ESMTPS id df21sm1286104ibb.9.2011.09.07.13.19.59 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 13:20:00 -0700 (PDT) Message-ID: <4E67D1F8.7010008@gmail.com> Date: Wed, 07 Sep 2011 12:20:08 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4E665B25.6090709@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <4E67B1C3.60306@mtcc.com> <2DEC7481-6359-4E6D-9F98-D97F42AF1A19@oracle.com> <4E67B93C.3060909@gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F277D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A4F277D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 07 Sep 2011 20:18:12 -0000 On 09/07/2011 12:03 PM, Eran Hammer-Lahav wrote: > We clearly have different views on what it means to "[deal] with this like an adult". Very possibly. What bothered me was the reflexive dismissal of usability issues without consideration, and the nasty tone of some of the responses. When someone suggests that Mike Thomas doesn't understand trusted third-party authentication protocols, someone just blew it, big time. But aside from the personal attacks, usability is a huge, huge problem in security, and often protocols that are "secure" under ideal circumstances are actually riddled with vulnerabilities in the field. While you can't prevent users from making bad choices, you should probably try to minimize their ability to do so or at least try to understand where things can go wrong. I think it's not *that* long since entirely too many people were nailed by a MITM attack against ssh on an IETF meeting wireless network, when they were presented with a new host key and rather than wondering why the key had changed they said "Gee, thanks!" and accepted it. Even very sophisticated users can make bad choices that lead directly to compromise. It's not possible to catalog every possible usability issue, but I do think that it's a worthwhile exercise to give at least some thought to what choices are being presented to users that are peculiar to the technology in question, and I think a threats document is an ideal place to do that. Melinda From tonynad@microsoft.com Wed Sep 7 13:25: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 0CE7121F8D84 for ; Wed, 7 Sep 2011 13:25: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.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 j3+Vb5oMLYAM for ; Wed, 7 Sep 2011 13:25:17 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id B633421F8D03 for ; Wed, 7 Sep 2011 13:25:17 -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, 7 Sep 2011 13:27:08 -0700 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.339.2; Wed, 7 Sep 2011 13:27:07 -0700 Received: from mail105-ch1-R.bigfish.com (216.32.181.171) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Sep 2011 20:27:06 +0000 Received: from mail105-ch1 (localhost.localdomain [127.0.0.1]) by mail105-ch1-R.bigfish.com (Postfix) with ESMTP id 79DF3F70462 for ; Wed, 7 Sep 2011 20:27:06 +0000 (UTC) X-SpamScore: -25 X-BigFish: PS-25(zz9371Kc89bh542Mzz1202h1082kzz8275ch1033IL8275bh8275dhz31h2a8h668h839h93fh61h) 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 (mail105-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 mail105-ch1 (localhost.localdomain [127.0.0.1]) by mail105-ch1 (MessageSwitch) id 1315427225864763_23464; Wed, 7 Sep 2011 20:27:05 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail105-ch1.bigfish.com (Postfix) with ESMTP id BC1FE6E804D; Wed, 7 Sep 2011 20:27:05 +0000 (UTC) Received: from SN2PRD0302HT001.namprd03.prod.outlook.com (207.46.4.139) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 7 Sep 2011 20:26:59 +0000 Received: from SN2PRD0302MB137.namprd03.prod.outlook.com ([169.254.4.36]) by SN2PRD0302HT001.namprd03.prod.outlook.com ([10.27.50.84]) with mapi id 14.01.0225.067; Wed, 7 Sep 2011 20:26:50 +0000 From: Anthony Nadalin To: Eran Hammer-Lahav , "William J. Mills" , Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Auth Code Swap Attack Thread-Index: AcxZImYoC2iZvOhxR/+zEXUukLHDogAF8TGAAIvI14AAgNyjAACwAFgAAAIJGIAAe8GCAAAScGQAADLTUAAACHI+AAH/lWkAAJDQ2SA= Date: Wed, 7 Sep 2011 20:26:49 +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> <1314299478.57208.YahooMailNeo@web31812.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D6@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="utf-8" Content-Transfer-Encoding: base64 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%YAHOO-INC.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: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.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: Wed, 07 Sep 2011 20:25:19 -0000 QWNjZXB0YWJsZSwgYnV0IG5vdCBpZGVhbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogRXJhbiBIYW1tZXItTGFoYXYgW21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXSANClNl bnQ6IFN1bmRheSwgU2VwdGVtYmVyIDA0LCAyMDExIDQ6MjAgUE0NClRvOiBXaWxsaWFtIEouIE1p bGxzOyBBbnRob255IE5hZGFsaW47IFRvcnN0ZW4gTG9kZGVyc3RlZHQNCkNjOiBPQXV0aCBXRyAo b2F1dGhAaWV0Zi5vcmcpDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBBdXRoIENvZGUgU3dhcCBB dHRhY2sNCg0KVGhpcyBpcyBteSBwcm9wb3NlZCB0ZXh0IGZvciAtMjEgKGJhc2VkIG9uIEJpbGwn cyB0ZXh0IGFzIGEgc3RhcnRpbmcgcG9pbnQpOg0KDQoxMC4xMi4gIENyb3NzLVNpdGUgUmVxdWVz dCBGb3JnZXJ5DQoNCiAgIENyb3NzLXNpdGUgcmVxdWVzdCBmb3JnZXJ5IChDU1JGKSBpcyBhbiBl eHBsb2l0IGluIHdoaWNoIGFuIGF0dGFja2VyDQogICBjYXVzZXMgdGhlIHVzZXItYWdlbnQgb2Yg YSB2aWN0aW0gZW5kLXVzZXIgdG8gZm9sbG93IGEgbWFsaWNpb3VzIFVSSQ0KICAgKGUuZy4gcHJv dmlkZWQgdG8gdGhlIHVzZXItYWdlbnQgYXMgYSBtaXNsZWFkaW5nIGxpbmssIGltYWdlLCBvcg0K ICAgcmVkaXJlY3Rpb24pIHRvIGEgdHJ1c3Rpbmcgc2VydmVyICh1c3VhbGx5IGVzdGFibGlzaGVk IHZpYSB0aGUNCiAgIHByZXNlbmNlIG9mIGEgdmFsaWQgc2Vzc2lvbiBjb29raWUpLg0KDQogICBB IENTUkYgYXR0YWNrIGFnYWluc3QgdGhlIGNsaWVudCdzIHJlZGlyZWN0aW9uIFVSSSBhbGxvd3Mg YW4gYXR0YWNrZXINCiAgIHRvIGluamVjdCB0aGVpciBvd24gYXV0aG9yaXphdGlvbiBjb2RlIG9y IGFjY2VzcyB0b2tlbiwgd2hpY2ggY2FuDQogICByZXN1bHQgaW4gdGhlIGNsaWVudCB1c2luZyBh biBhY2Nlc3MgdG9rZW4gYXNzb2NpYXRlZCB3aXRoIHRoZQ0KICAgYXR0YWNrZXIncyBwcm90ZWN0 ZWQgcmVzb3VyY2VzIHJhdGhlciB0aGFuIHRoZSB2aWN0aW0ncyAoZS5nLiBzYXZlDQogICB0aGUg dmljdGltJ3MgYmFuayBhY2NvdW50IGluZm9ybWF0aW9uIHRvIGEgcHJvdGVjdGVkIHJlc291cmNl DQogICBjb250cm9sbGVkIGJ5IHRoZSBhdHRhY2tlcikuDQoNCiAgIFRoZSBjbGllbnQgTVVTVCBp bXBsZW1lbnQgQ1NSRiBwcm90ZWN0aW9uIGZvciBpdHMgcmVkaXJlY3Rpb24gVVJJLg0KICAgVGhp cyBpcyB0eXBpY2FsbHkgYWNjb21wbGlzaGVkIGJ5IHJlcXVpcmluZyBhbnkgcmVxdWVzdCBzZW50 IHRvIHRoZQ0KICAgcmVkaXJlY3Rpb24gVVJJIGVuZHBvaW50IHRvIGluY2x1ZGUgYSB2YWx1ZSB0 aGF0IGJpbmRzIHRoZSByZXF1ZXN0IHRvDQogICB0aGUgdXNlci1hZ2VudCdzIGF1dGhlbnRpY2F0 ZWQgc3RhdGUgKGUuZy4gYSBoYXNoIG9mIHRoZSBzZXNzaW9uDQogICBjb29raWUgdXNlZCB0byBh dXRoZW50aWNhdGlvbiB0aGUgdXNlci1hZ2VudCkuICBUaGUgY2xpZW50IFNIT1VMRA0KICAgdXRp bGl6ZSB0aGUgInN0YXRlIiByZXF1ZXN0IHBhcmFtZXRlciB0byBkZWxpdmVyIHRoaXMgdmFsdWUg dG8gdGhlDQogICBhdXRob3JpemF0aW9uIHNlcnZlciB3aGVuIG1ha2luZyBhbiBhdXRob3JpemF0 aW9uIHJlcXVlc3QuDQoNCiAgIE9uY2UgYXV0aG9yaXphdGlvbiBoYXMgYmVlbiBvYnRhaW5lZCBm cm9tIHRoZSBlbmQtdXNlciwgdGhlDQogICBhdXRob3JpemF0aW9uIHNlcnZlciByZWRpcmVjdHMg dGhlIGVuZC11c2VyJ3MgdXNlci1hZ2VudCBiYWNrIHRvIHRoZQ0KICAgY2xpZW50IHdpdGggdGhl IHJlcXVpcmVkIGJpbmRpbmcgdmFsdWUgY29udGFpbmVkIGluIHRoZSAic3RhdGUiDQogICBwYXJh bWV0ZXIuICBUaGUgYmluZGluZyB2YWx1ZSBlbmFibGVzIHRoZSBjbGllbnQgdG8gdmFsaWRhdGUg dGhlDQogICB2YWxpZGl0eSBvZiB0aGUgcmVxdWVzdCBieSBtYXRjaGluZyB0aGUgYmluZGluZyB2 YWx1ZSB0byB0aGUgdXNlci0NCiAgIGFnZW50J3MgYXV0aGVudGljYXRlZCBzdGF0ZS4gIFRoZSBi aW5kaW5nIHZhbHVlIHVzZWQgZm9yIENTUkYNCiAgIHByb3RlY3Rpb24gTVVTVCBjb250YWluIGEg bm9uLWd1ZXNzYWJsZSB2YWx1ZSwgYW5kIHRoZSB1c2VyLWFnZW50J3MNCiAgIGF1dGhlbnRpY2F0 ZWQgc3RhdGUgKGUuZy4gc2Vzc2lvbiBjb29raWUsIEhUTUw1IGxvY2FsIHN0b3JhZ2UpIE1VU1QN CiAgIGJlIGtlcHQgaW4gYSBsb2NhdGlvbiBhY2Nlc3NpYmxlIG9ubHkgdG8gdGhlIGNsaWVudCBh bmQgdGhlIHVzZXItDQogICBhZ2VudCAoaS5lLiwgcHJvdGVjdGVkIGJ5IHNhbWUtb3JpZ2luIHBv bGljeSkuDQoNCiAgIEEgQ1NSRiBhdHRhY2sgYWdhaW5zdCB0aGUgYWdhaW5zdCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIncw0KICAgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBjYW4gcmVzdWx0IGlu IGFuIGF0dGFja2VyIG9idGFpbmluZyBlbmQtdXNlcg0KICAgYXV0aG9yaXphdGlvbiBmb3IgYSBt YWxpY2lvdXMgY2xpZW50IHdpdGhvdXQgaW52b2x2aW5nIG9yIGFsZXJ0aW5nDQogICB0aGUgZW5k LXVzZXIuDQoNCiAgIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIGltcGxlbWVudCBDU1JG IHByb3RlY3Rpb24gZm9yIGl0cw0KICAgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgYW5kIGVuc3Vy ZSB0aGF0IGEgbWFsaWNpb3VzIGNsaWVudCBjYW5ub3QNCiAgIG9idGFpbiBhdXRob3JpemF0aW9u IHdpdGhvdXQgdGhlIGF3YXJlbmVzcyBhbmQgZXhwbGljaXQgY29uc2VudCBvZg0KICAgdGhlIHJl c291cmNlIG93bmVyLg0KDQpFSEwNCg0KDQpGcm9tOiBXaWxsaWFtIEouIE1pbGxzIFttYWlsdG86 d21pbGxzQHlhaG9vLWluYy5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDI1LCAyMDExIDEy OjExIFBNDQpUbzogQW50aG9ueSBOYWRhbGluOyBFcmFuIEhhbW1lci1MYWhhdjsgVG9yc3RlbiBM b2RkZXJzdGVkdA0KQ2M6IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNClN1YmplY3Q6IFJlOiBb T0FVVEgtV0ddIEF1dGggQ29kZSBTd2FwIEF0dGFjaw0KDQpJIGhhZCBwcm9wb3NlZCB0ZXh0LCBh bmQgSSdsbCByZXByaXNlIGl0IGhlcmUgd2l0aCBhIG1vZGlmaWNhdGlvbiB0byBtYWtlIHRoZSBh dXRob3JpemF0b24gc2VydmVyIHJlbGF0ZWQgZXhwbGljaXQuDQoNCjEwLjEyLsKgwqBDcm9zcy1T aXRlIFJlcXVlc3QgRm9yZ2VyeSANCg0KQ3Jvc3Mtc2l0ZSByZXF1ZXN0IGZvcmdlcnkgKENTUkYp IGlzIGFuIGF0dGFjayB3aGVyZWJ5IG1hbGljaW91cyBVUkxzIGFyZSBzZW50IHRvIHRoZSB1c2Vy LWFnZW50IG9mIGFuIGVuZCB1c2VyIChnZW5lcmFsbHkgYXMgaGlkZGVuIGxpbmtzIG9yIGltYWdl cykgYW5kIHRyYW5zbWl0dGVkIGZyb20gdGhlIHVzZXItYWdlbnQgdGhlIHNlcnZlciB0cnVzdHMg b3IgaGFzIGF1dGhlbnRpY2F0ZWQuIFRoZSBtb3N0IGNvbW1vbmx5IGV4cGxvaXRlZCBtZWNoYW5p c20gZm9yIHRoaXMgaXMgY3JlZGVudGlhbHMgaGVsZCBpbiBjb29raWVzIGF1dG9tYXRpY2FsbHkg cHJlc2VudGVkIGJ5IGEgd2ViIGJyb3dzZXIuwqAgQ1NSRiBhdHRhY2tzIGFnYWluc3QgdGhlIGNs aWVudCdzIHJlZGlyZWN0aW9uIFVSSSBhbGxvdyBhbiBhdHRhY2tlciB0byBpbmplY3QgdGhlaXIg b3duIGF1dGhvcml6YXRpb24gY29kZSBvciBhY2Nlc3MgdG9rZW4sIHdoaWNoIGNhbiByZXN1bHQg aW4gdGhlIGNsaWVudCB1c2luZyBhbiBhY2Nlc3MgdG9rZW4gYXNzb2NpYXRlZCB3aXRoIHRoZSBh dHRhY2tlcidzIGFjY291bnQgcmF0aGVyIHRoYW4gdGhlIHZpY3RpbSdzLsKgIENTUkYgYXR0YWNr cyBhcmUgYWxzbyBwb3NzaWJsZSBhZ2FpbnN0IGFuIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgcmVz dWx0aW5nIGluIGRlbGl2ZXJpbmcgYSB1c2VyIGNyZWRlbnRpYWwgdG8gYW4gYXR0YWNrZXIuIMKg IA0KDQpDbGllbnQgYXBwbGljYXRpb25zIE1VU1QgaW1wbGVtZW50IENTUkYgcHJvdGVjdGlvbiBm b3IgdGhlIHJlZGlyZWN0aW9uIFVSSS7CoCBDU1JGIHByb3RlY3Rpb24gZm9yIGEgcmVxdWVzdCBp cyBkYXRhIGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0IHRoYXQgdGllcyB0aGF0IHJlcXVlc3QgdG8g dGhlIHVzZXIncyBhdXRoZW50aWNhdGVkIHN0YXRlLCBpLmUuIGEgY3J5cHRvZ3JhcGhpYyBzaWdu YXR1cmUgb2YgdGhlIHVzZXIgY3JlZGVudGlhbCBhbmQgdGhlIHJlZGlyZWN0aW9uIFVSSSBwYXRo LsKgIFVwb24gcmVjZWlwdCBvZiBhIHJlcXVlc3QgdGhlIGNsaWVudCBhcHBsaWNhdGlvbiBjb21w dXRlcyB0aGUgQ1NSRiBkYXRhIGJhc2VkIG9uIHRoZSBwcmVzZW50ZWQgY3JlZGVudGlhbCBhbmQg Y29tcGFyZXMgdGhhdCB0byB0aGUgQ1NSRiBwcm90ZWN0aW9uIGRhdGEgcHJlc2VudGVkIGluIHRo ZSByZXF1ZXN0LsKgIENTUkYgcHJvdGVjdGlvbiBkYXRhIE1VU1QgY29udGFpbiBhIG5vbi1ndWVz c2FibGUgdmFsdWUsIGFuZCB0aGUgY2xpZW50IE1VU1Qga2VlcCBpdCBpbiBhIGxvY2F0aW9uIGFj Y2Vzc2libGUgb25seSBieSB0aGUgY2xpZW50IG9yIHRoZSB1c2VyLWFnZW50IChpLmUuLCBwcm90 ZWN0ZWQgYnkgc2FtZS1vcmlnaW4gcG9saWN5KS4gVGhlICJzdGF0ZSIgcmVkaXJlY3Rpb24gVVJJ IHBhcmFtZXRlciBpcyBwcm92aWRlZCBhcyBvbmUgbWV0aG9kIG9mIGNhcnJ5aW5nIENTUkYgcHJv dGVjdGlvbiBkYXRhLCBhbmQgaXMgUkVDT01NRU5ERUQgdG8gcHJvdmlkZSB0aGUgZ3JlYXRlc3Qg Y29tcGF0aWJpbGl0eSB3aXRoIHN5c3RlbXMgaW1wbGVtZW50aW5nIHN0cm9uZyByZWRpcmVjdGlv biBVUkkgdmFsaWRhdGlvbi7CoCANCg0KQXV0aG9yaXphdGlvbiBzZXJ2ZXJzIE1VU1QgaW1wbGVt ZW50IENTUkYgcHJvdGVjdGlvbiBmb3IgYXV0aG9yaXphdGlvbiByZXF1ZXN0cywgdXNlIG9mIHRo ZSAic3RhdGUiIHBhcmFtZXRlciBpcyBSRUNPTU1FTkRFRCBhcyB0aGUgd2F5IHRvIHRyYW5zbWl0 IHRoZSBDU1JGIHByb3RlY3Rpb24gZGF0YS7CoMKgVGhlIENTUkYgcHJvdGVjdGlvbiBkYXRhIE1V U1QgY29udGFpbiBhIG5vbi1ndWVzc2FibGUgdmFsdWUsIGFuZCBNVVNUIGJlIHByZXNlbnRlZCBh cyBwYXJ0IG9mIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgZGF0YSAoZS5nLiBub3QgYXMgYSBj b29raWUpLsKgIEF1dGhvcml6YXRpb24gc2VydmVycyBNQVkgdXNlIHByb29mIG9mIHByZXZpb3Vz wqAgYXV0aG9yaXphdGlvbiBieSBhIHVzZXIgZm9yIGEgY2xpZW50IGluIGxpZXUgb2YgZXhwbGlj aXQgQ1NSRiBwcm90ZWN0aW9uLg0KDQpGb3IgZXhhbXBsZSwgdXNpbmcgYSBET00gdmFyaWFibGUs IEhUVFAgY29va2llLCBvciBIVE1MNSBjbGllbnQtc2lkZSBzdG9yYWdlLsKgwqBUaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgaW5jbHVkZXMgdGhlIHZhbHVlIG9mIHRoZSAic3RhdGUiIHBhcmFtZXRl ciB3aGVuIHJlZGlyZWN0aW5nIHRoZSB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudCB3aGlj aCBNVVNUIHRoZW4gdmFsaWRhdGUgdGhlIHJlY2VpdmVkIHZhbHVlIGFnYWluc3QgdGhlIHN0b3Jl ZCB2YWx1ZSwgb3IgYnkgcmVjb21wdXRpbmcgdGhlIGV4cGVjdGVkIHZhbHVlIG9mIHRoZSBDU1JG IHByb3RlY3Rpb24gZGF0YSBhbmQgY29tcGFyaW5nIHRoYXQgdG8gdGhlIHZhbHVlIHByZXNlbnRl ZC4gDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9t OiBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NClRvOiBFcmFuIEhhbW1l ci1MYWhhdiA8ZXJhbkBodWVuaXZlcnNlLmNvbT47IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0 ZW5AbG9kZGVyc3RlZHQubmV0Pg0KQ2M6ICJPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpIiA8b2F1 dGhAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDI1LCAyMDExIDg6MTEgQU0NClN1 YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEF1dGggQ29kZSBTd2FwIEF0dGFjayBJIGhhdmUgbm90IHNl ZW4gYW55IHVwZGF0ZWQgdGV4dCwgc28gSSBkb27igJl0IGJlbGlldmUgd2UgaGF2ZSBjb25zZW5z dXMuIEFsc28gd2UgaGF2ZSBhIGZsYXdlZCBwcm90b2NvbCBhbmQgd2UgYXJlIG5vdCBwcm92aWRp bmcgYSBmaXgsIHN1Z2dlc3QgdGhhdCBNVVNUIGJlIG9uIHRoZSBzdGF0ZSBhbHNvIHVubGVzcyBz b21lb25lIGhhcyBhIGJldHRlciBmaXgNCsKgDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyYW4gSGFtbWVy LUxhaGF2DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwgMjAxMSA3OjU0IEFNDQpUbzogVG9y c3RlbiBMb2RkZXJzdGVkdA0KQ2M6IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNClN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIEF1dGggQ29kZSBTd2FwIEF0dGFjaw0KwqANCkkgYmVsaWV2ZSB3ZSBo YXZlIGZ1bGwgY29uc2Vuc3VzIG9uIHRoaXMgYXBwcm9hY2guDQrCoA0KRUhMDQrCoA0KRnJvbTog VG9yc3RlbiBMb2RkZXJzdGVkdCBbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0XQ0KU2Vu dDogVHVlc2RheSwgQXVndXN0IDIzLCAyMDExIDExOjA2IFBNDQpUbzogRXJhbiBIYW1tZXItTGFo YXYNCkNjOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSBBdXRoIENvZGUgU3dhcCBBdHRhY2sNCsKgDQptYWtpbmcgQ1NSRiBwcmV2ZW50aW9uIGEgTVVT VCBhbmQgcmVjb21tZW5kaW5nIHRoZSBzdGF0ZSBwYXJhbWV0ZXIgYXMgaW1wbGVtZW50YXRpb24g cGF0dGVybiBpcyBvayB3aXRoIG1lLg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQW0gMjEuMDgu MjAxMSAyMTowMiwgc2NocmllYiBFcmFuIEhhbW1lci1MYWhhdjogDQpJIGxpZ2h0IHRvIHRoZSBy ZWNlbnQgZGlzY3Vzc2lvbiwgZG8geW91IHN0aWxsIGZlZWwgdGhhdCBjaGFuZ2luZyDigJhzdGF0 ZeKAmSBmcm9tIG9wdGlvbmFsIHRvIHJlcXVpcmVkIGlzIHRoZSBiZXN0IGFwcHJvYWNoPw0KwqAN CkVITA0KwqANCkZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldF0NClNlbnQ6IFN1bmRheSwgQXVndXN0IDIxLCAyMDExIDExOjA0IEFNDQpUbzog RXJhbiBIYW1tZXItTGFoYXYNCkNjOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBBdXRoIENvZGUgU3dhcCBBdHRhY2sNCsKgDQpNeSBpbnRlbnRpb24g aXMgdG8gcmVxdWlyZSBjbGllbnRzIHRvIGltcGxlbWVudCBDU1JGIHByZXZlbnRpb24uIEkgdGhv dWdodCBtYWtpbmcgdGhlIHN0YXRlIHBhcmFtZXRlciBtYW5kYXRvcnkgd291bGQgYmUgdGhlIHN0 cmFpZ2h0Zm9yd2FyZCB3YXkuDQoNCnJlZ2FyZHMsDQpUb3JzdGVuLg0KDQpBbSAxOC4wOC4yMDEx IDA4OjA0LCBzY2hyaWViIEVyYW4gSGFtbWVyLUxhaGF2OiANCkkgd291bGQgbGlrZSB0byBoZWFy IGZyb20gdGhlIG90aGVyIDMgYXV0aG9ycyBvZiB0aGUgcHJvcG9zZWQgY2hhbmdlIGFib3V0IHRo ZWlyIHJlYXNvbnMgZm9yIGNoYW5naW5nIHRoZSB1c2Ugb2Yg4oCYc3RhdGXigJkgZnJvbSByZWNv bW1lbmRlZCB0byByZXF1aXJlZCBmb3IgQ1NSRiBwcmV2ZW50aW9uLiBJdCB3b3VsZCBhbHNvIGhl bHAgbW92aW5nIHRoaXMgaXNzdWUgZm9yd2FyZCBpZiB0aGUgNCBhdXRob3JzIGNhbiBwcm92aWRl IGFuc3dlcnMgb3IgY2xhcmlmaWNhdGlvbnMgb24gdGhlIGlzc3VlcyByYWlzZWQgYmVsb3cuDQrC oA0KQXNzdW1pbmcgd2UgY2FuIGNvdW50IGFsbCA0IGF1dGhvcnMgYXJlIGluIGZhdm9yIG9mIG1h a2luZyB0aGUgY2hhbmdlLCBJIGJlbGlldmUgd2UgaGF2ZSBhIHRpZSAoNDo0KSBhbmQgdGhlcmVm b3JlIG5vIGNvbnNlbnN1cyBmb3IgbWFraW5nIGl0IChhcyBvZiB0aGlzIHBvaW50KS4gSG93ZXZl ciwgd2UgZGlkIGlkZW50aWZ5IGlzc3VlcyB3aXRoIHRoZSBzZWN0aW9u4oCZcyBsYW5ndWFnZSBh bmQgY2xhcml0eSB3aGljaCB3ZSBzaG91bGQgYWRkcmVzcyBlaXRoZXIgd2F5Lg0KwqANClRvIGNs YXJpZnkg4oCTIEkgYW0gbm90IHByb3Bvc2luZyB3ZSBjbG9zZSB0aGlzIGlzc3VlIGp1c3QgeWV0 Lg0KwqANCkVITA0KwqANCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJhbiBIYW1tZXItTGFoYXYNClNlbnQ6 IE1vbmRheSwgQXVndXN0IDE1LCAyMDExIDk6MzUgQU0NClRvOiBPQXV0aCBXRyAob2F1dGhAaWV0 Zi5vcmcpDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBdXRoIENvZGUgU3dhcCBBdHRhY2sNCsKg DQpUbyBkZW1vbnN0cmF0ZSB3aHkgbWFraW5nIHN0YXRlIHJlcXVpcmVkIGFzIHByb3Bvc2VkIGlz buKAmXQgdmVyeSBoZWxwZnVsLCBoZXJlIGlzIGFuIGluY29tcGxldGUgbGlzdCBvZiBvdGhlciBy ZXF1aXJlbWVudHMgbmVlZGVkIHRvIG1ha2UgYW4gZWZmZWN0aXZlIENTUkY6DQrCoA0KKiBTdGF0 ZSB2YWx1ZSBtdXN0IG5vdCBiZSBlbXB0eSAoYSBjb21tb24gYnVnIGluIG1hbnkgaW1wbGVtZW50 YXRpb25zIHVzaW5nIHNpbXBsZSB2YWx1ZSBjb21wYXJpc29uKS4NCsKgDQoqIOKAmE5vbi1ndWVz c2FibGXigJkgaXNu4oCZdCBzdWZmaWNpZW50IGFzIG1vc3QgZGV2ZWxvcGVycyB3aWxsIHNpbXBs eSB1c2UgYSBoYXNoIG9mIHRoZSBzZXNzaW9uIGNvb2tpZSwgd2l0aCBvciB3aXRob3V0IHNhbHQg d2hpY2ggaXNu4oCZdCBzdWZmaWNpZW50LiBXZSB1c2Ug4oCcY2Fubm90IGJlIGdlbmVyYXRlZCwg bW9kaWZpZWQsIG9yIGd1ZXNzZWQgdG8gcHJvZHVjZSB2YWxpZCB2YWx1ZXPigJ0gZWxzZXdoZXJl IGluIHRoZSBkb2N1bWVudCwgYnV0IHRoaXMgaXMgbXVjaCBlYXNpZXIgdG8gZ2V0IHJpZ2h0IGZv ciBhY2Nlc3MgdG9rZW5zIGFuZCByZWZyZXNoIHRva2VucyB0aGFuIENTUkYgdG9rZW5zIHdoaWNo IGFyZSBvZnRlbiBqdXN0IHNvbWUgYWxnb3JpdGhtIG9uIHRvcCBvZiB0aGUgc2Vzc2lvbiBjb29r aWUuDQrCoA0KKiBTdGF0ZSBDU1JGIHZhbHVlIHNob3VsZCBiZSBzaG9ydC1saXZlZCBvciBiYXNl ZCBvbiBhIHNob3J0LWxpdmVkIHNlc3Npb24gY29va2llIHRvIHByZXZlbnQgdGhlIHVzZSBvZiBh IGxlYWtlZCBzdGF0ZSB2YWx1ZSBpbiBtdWx0aXBsZSBhdHRhY2tzIG9uIHRoZSBzYW1lIHVzZXIg c2Vzc2lvbiBvbmNlIHRoZSBsZWFrIGlzIG5vIGxvbmdlciB2aWFibGUuDQrCoA0KSW4gYWRkaXRp b24sIHRoaXMgaXMgbm90IHdoYXQg4oCcc3RhdGXigJ0gd2FzIG9yaWdpbmFsbHkgaW50ZW5kZWQg Zm9yLiBJZiB0aGUgd29ya2luZyBncm91cCBkZWNpZGVzIHRvIG1hbmRhdGUgYSBDU1JGIHBhcmFt ZXRlciwgaXQgc2hvdWxkIHByb2JhYmx5IGJlIGEgbmV3IHBhcmFtZXRlciB3aXRoIGEgbW9yZSBh cHByb3ByaWF0ZSBuYW1lIChlLmcuIOKAmGNzcmbigJkpLiBCeSBmb3JjaW5nIGNsaWVudHMgdG8g dXNlIOKAnHN0YXRl4oCdIGZvciB0aGlzIHB1cnBvc2UsIGRldmVsb3BlcnMgd2lsbCBuZWVkIHRv IHVzZSBkeW5hbWljIHF1ZXJpZXMgZm9yIG90aGVyIHN0YXRlIGluZm9ybWF0aW9uIHdoaWNoIGZ1 cnRoZXIgcmVkdWNlcyB0aGUgc2VjdXJpdHkgb2YgdGhlIHByb3RvY29sIChhcyB0aGUgZHJhZnQg cmVjb21tZW5kcyBub3QgdXNpbmcgZHluYW1pYyBjYWxsYmFjayBxdWVyeSBjb21wb25lbnRzKS4g RW5jb2RpbmcgYm90aCBDU1JGIHRva2VucyBhbmQgb3RoZXIgc3RhdGUgaW5mb3JtYXRpb24gY2Fu IGJlIG5vbi1pbnR1aXRpdmUgb3IgY29tcGxpY2F0ZWQgZm9yIHNvbWUgZGV2ZWxvcGVycy9wbGF0 Zm9ybXMuDQrCoA0KRUhMDQrCoA0KwqANCsKgDQrCoA0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYN ClNlbnQ6IEZyaWRheSwgQXVndXN0IDEyLCAyMDExIDI6NTMgUE0NClRvOiBBbnRob255IE5hZGFs aW47IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEF1 dGggQ29kZSBTd2FwIEF0dGFjaw0KwqANClRoaXMgaXMgcmVhbGx5IGp1c3QgYSBmbGF2b3Igb2Yg Q1NSRiBhdHRhY2tzLiBJIGhhdmUgbm8gb2JqZWN0aW9ucyB0byBiZXR0ZXIgZG9jdW1lbnRpbmcg aXQgKHRob3VnaCBJIGZlZWwgdGhlIGN1cnJlbnQgdGV4dCBpcyBhbHJlYWR5IHN1ZmZpY2llbnQp LCBidXQgd2UgY2FuJ3QgcmVhbGlzdGljYWxseSBleHBlY3QgdG8gaWRlbnRpZnkgYW5kIGNsb3Nl IGV2ZXJ5IHBvc3NpYmxlIGJyb3dzZXItYmFzZWQgYXR0YWNrLiBBIG5ldyBvbmUgaXMgaW52ZW50 ZWQgZXZlcnkgb3RoZXIgd2Vlay4NCsKgDQpUaGUgcHJvYmxlbSB3aXRoIHRoaXMgdGV4dCBpcyB0 aGF0IGRldmVsb3BlcnMgd2hvIGRvIG5vIHVuZGVyc3RhbmQgQ1NSRiBhdHRhY2tzIGFyZSBub3Qg bGlrZWx5IHRvIGltcGxlbWVudCBpdCBjb3JyZWN0bHkgd2l0aCB0aGlzIGluZm9ybWF0aW9uLiBU aG9zZSB3aG8gdW5kZXJzdGFuZCBpdCBkbyBub3QgbmVlZCB0aGUgZXh0cmEgdmVyYmlhZ2Ugd2hp Y2ggaXMgbW9yZSBjb25mdXNpbmcgdGhhbiBoZWxwZnVsLg0KwqANCkFzIGZvciB0aGUgbmV3IHJl cXVpcmVtZW50cywgdGhleSBhcmUgaW5zdWZmaWNpZW50IHRvIGFjdHVhbGx5IGFjY29tcGxpc2gg d2hhdCB0aGUgYXV0aG9ycyBwcm9wb3NlIHdpdGhvdXQgYWRkaXRpb25hbCByZXF1aXJlbWVudHMg b24gc3RhdGUgbG9jYWwgc3RvcmFnZSBhbmQgdmVyaWZpY2F0aW9uIHRvIGNvbXBsZXRlIHRoZSBm bG93LiBBbHNvLCB0aGUgcHJvcG9zZWQgdGV4dCBuZWVkcyBjbGFyaWZpY2F0aW9ucyBhcyBub3Rl ZCBiZWxvdy4NCsKgDQrCoA0KRnJvbTogQW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29m dC5jb20+DQpEYXRlOiBGcmksIDEyIEF1ZyAyMDExIDEyOjA2OjM2IC0wNzAwDQpUbzogIk9BdXRo IFdHIChvYXV0aEBpZXRmLm9yZykiIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFtPQVVUSC1X R10gQXV0aCBDb2RlIFN3YXAgQXR0YWNrDQrCoA0KwqANCsKgDQpSZWNvbW1lbmRlZCBDaGFuZ2Vz IHRvIGRyYWZ0LWlldGYtb2F1dGgtdjINCsKgDQpJbiBzZWN0aW9uIDQsIHJlcXVlc3Qgb3B0aW9u cyAoZS5nLiA0LjEuMSkgZmVhdHVyaW5nICJzdGF0ZSIgc2hvdWxkIGNoYW5nZSBmcm9tOg0KwqAN CnN0YXRlDQpPUFRJT05BTC4gQW4gb3BhcXVlIHZhbHVlIHVzZWQgYnkgdGhlIGNsaWVudCB0byBt YWludGFpbiBzdGF0ZSBiZXR3ZWVuIHRoZSByZXF1ZXN0IGFuZCBjYWxsYmFjay4gVGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGluY2x1ZGVzIHRoaXMgdmFsdWUgd2hlbiByZWRpcmVjdGluZyB0aGUg dXNlci1hZ2VudCBiYWNrIHRvIHRoZSBjbGllbnQuDQrCoA0KdG86DQrCoA0Kc3RhdGUNClJFUVVJ UkVELiBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xpZW50IHRvIG1haW50YWluIHN0YXRl IGJldHdlZW4gdGhlIHJlcXVlc3QgYW5kIGNhbGxiYWNrLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRoZSB1c2VyLWFnZW50IGJh Y2sgdG8gdGhlIGNsaWVudC4gVGhlIGVuY29kZWQgdmFsdWUgU0hPVUxEIGVuYWJsZSB0aGUgY2xp ZW50IGFwcGxpY2F0aW9uIHRvIGRldGVybWluZSB0aGUgdXNlci1jb250ZXh0IHRoYXQgd2FzIGFj dGl2ZSBhdCB0aGUgdGltZSBvZiB0aGUgwqByZXF1ZXN0IChzZWUgc2VjdGlvbiAxMC4xMikuIFRo ZSB2YWx1ZSBNVVNUIE5PVCBiZSBndWVzc2FibGUgb3IgcHJlZGljdGFibGUsIGFuZCBNVVNUIGJl IGtlcHQgY29uZmlkZW50aWFsLg0KwqANCsKgDQpNYWtpbmcgdGhlIHBhcmFtZXRlciByZXF1aXJl ZCB3aXRob3V0IG1ha2luZyBpdHMgdXNhZ2UgcmVxdWlyZWQgKEkuZS4gInZhbHVlIFNIT1VMRCBl bmFibGUiKSBhY2NvbXBsaXNoZXMgbm90aGluZy4gQWxzbywgd2hhdCBkb2VzICJNVVNUIGJlIGtl cHQgY29uZmlkZW50aWFsIiBtZWFuPyBDb25maWRlbnRpYWwgZnJvbSB3aGF0PyBXaHkgc3BlY2lm eSBhbiAiZW5jb2RlZCB2YWx1ZSI/DQrCoA0KwqANClNlY3Rpb24gMTAuMTIgQ3Jvc3MtU2l0ZSBS ZXF1ZXN0IEZvcmdlcnkNCsKgDQpDaGFuZ2UgdG86DQrCoA0KQ3Jvc3Mtc2l0ZSByZXF1ZXN0IGZv cmdlcnkgKENTUkYpIGlzIGEgd2ViLWJhc2VkIGF0dGFjayB3aGVyZWJ5IEhUVFAgcmVxdWVzdHMg YXJlIHRyYW5zbWl0dGVkIGZyb20gdGhlIHVzZXItYWdlbnQgb2YgYW4gZW5kLXVzZXLCoHRoZSBz ZXJ2ZXIgdHJ1c3RzIG9yIGhhcyBhdXRoZW50aWNhdGVkLiBDU1JGIGF0dGFja3MgZW5hYmxlIHRo ZSBhdHRhY2tlciB0byBpbnRlcm1peCB0aGUgYXR0YWNrZXIncyBzZWN1cml0eSBjb250ZXh0IHdp dGggdGhhdCBvZiB0aGXCoHJlc291cmNlIG93bmVyIHJlc3VsdGluZyBpbiBhIGNvbXByb21pc2Ug b2YgZWl0aGVyIHRoZSByZXNvdXJjZSBzZXJ2ZXIgb3Igb2YgdGhlIGNsaWVudCBhcHBsaWNhdGlv biBpdHNlbGYuIEluIHRoZSBPQXV0aCBjb250ZXh0LCBzdWNowqBhdHRhY2tzIGFsbG93IGFuIGF0 dGFja2VyIHRvIGluamVjdCB0aGVpciBvd24gYXV0aG9yaXphdGlvbiBjb2RlIG9yIGFjY2VzcyB0 b2tlbiBpbnRvIGEgY2xpZW50LCB3aGljaCBjYW4gcmVzdWx0IGluIHRoZSBjbGllbnQgdXNpbmcg YW7CoGFjY2VzcyB0b2tlbiBhc3NvY2lhdGVkIHdpdGggdGhlIGF0dGFja2VyJ3MgYWNjb3VudCBy YXRoZXIgdGhhbiB0aGUgdmljdGltJ3MuIERlcGVuZGluZyBvbiB0aGUgbmF0dXJlIG9mIHRoZSBj bGllbnQgYW5kIHRoZSBwcm90ZWN0ZWTCoHJlc291cmNlcywgdGhpcyBjYW4gaGF2ZSB1bmRlc2ly YWJsZSBhbmQgZGFtYWdpbmcgZWZmZWN0cy4NCg0KSW4gb3JkZXIgdG8gcHJldmVudCBzdWNoIGF0 dGFja3MsIHRoZSBjbGllbnQgYXBwbGljYXRpb24gTVVTVCBlbmNvZGUgYSBub24tZ3Vlc3NhYmxl LCBjb25maWRlbnRpYWwgZW5kLXVzZXIgYXJ0aWZhY3QgYW5kIHN1Ym1pdCBhc8KgdGhlICJzdGF0 ZSIgcGFyYW1ldGVyIHRvIGF1dGhvcml6YXRpb24gYW5kIGFjY2VzcyB0b2tlbiByZXF1ZXN0cyB0 byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoZSBjbGllbnQgTVVTVCBrZWVwIHRoZSBzdGF0 ZSB2YWx1ZSBpbsKgYSBsb2NhdGlvbiBhY2Nlc3NpYmxlIG9ubHkgYnkgdGhlIGNsaWVudCBvciB0 aGUgdXNlci1hZ2VudCAoaS5lLiwgcHJvdGVjdGVkIGJ5IHNhbWUtb3JpZ2luIHBvbGljeSksIGZv ciBleGFtcGxlLCB1c2luZyBhIERPTSB2YXJpYWJsZSzCoEhUVFAgY29va2llLCBvciBIVE1MNSBj bGllbnQtc2lkZSBzdG9yYWdlLg0KDQpUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW5jbHVkZXMg dGhlIHZhbHVlIG9mIHRoZSAic3RhdGUiIHBhcmFtZXRlciB3aGVuIHJlZGlyZWN0aW5nIHRoZSB1 c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudC4gVXBvbsKgcmVjZWl2aW5nIGEgcmVkaXJlY3Qs IHRoZSBjbGllbnQgYXBwbGljYXRpb24gTVVTVCBjb25maXJtIHRoYXQgcmV0dXJuZWQgdmFsdWUg b2YgInN0YXRlIiBjb3JyZXNwb25kcyB0byB0aGUgc3RhdGUgdmFsdWUgb2YgdGhlIHVzZXItYWdl bnQncyB1c2VyIHNlc3Npb24uIElmIHRoZSBlbmQtdXNlciBzZXNzaW9uIHJlcHJlc2VudHMgYW4g YXV0aGVudGljYXRlZCB1c2VyLWlkZW50aXR5LCB0aGUgY2xpZW50IE1VU1QgZW5zdXJlIHRoYXQg dGhlIHVzZXItaWRlbnRpdHnCoGhhcyBOT1QgY2hhbmdlZC4NCsKgDQrCoA0KVGhlIGFib3ZlIHRl eHQgdXNlcyAndXNlci1jb250ZXh0JyBhbmQgdGhpcyAndXNlci1pZGVudGl0eScuIE5laXRoZXIg dGVybSBpcyBkZWZpbmVkLg0KwqANCkVITA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQrCoA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aA0KDQo= From daver@quizlet.com Wed Sep 7 14: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 D380921F8D38 for ; Wed, 7 Sep 2011 14:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 OSlV47w7gT1s for ; Wed, 7 Sep 2011 14:14:30 -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 BFF4E21F8D02 for ; Wed, 7 Sep 2011 14:14:30 -0700 (PDT) Received: by yxj20 with SMTP id 20so81957yxj.31 for ; Wed, 07 Sep 2011 14:16:21 -0700 (PDT) Received: by 10.101.144.18 with SMTP id w18mr5294913ann.133.1315430180898; Wed, 07 Sep 2011 14:16:20 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by mx.google.com with ESMTPS id 11sm2252896ant.0.2011.09.07.14.16.19 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 14:16:20 -0700 (PDT) Received: by gxk9 with SMTP id 9so286216gxk.40 for ; Wed, 07 Sep 2011 14:16:19 -0700 (PDT) Received: by 10.101.176.12 with SMTP id d12mr19332anp.100.1315430179214; Wed, 07 Sep 2011 14:16:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.164.3 with HTTP; Wed, 7 Sep 2011 14:15:59 -0700 (PDT) X-Originating-IP: [67.169.69.75] In-Reply-To: References: From: Dave Rochwerger Date: Wed, 7 Sep 2011 14:15:59 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001636c9274b8f158c04ac607430 Cc: Quizlet Dev Team Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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: Wed, 07 Sep 2011 21:14:31 -0000 --001636c9274b8f158c04ac607430 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: ========== * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the "authorization code" flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). Our architecture: ============ * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say they must verify the state for CSRF mitigation). * We enforce that every client must register a redirect URI. * We validate the redirect_uri used to request an access token is the same that was used to obtain the auth code. * The only time a request is not made over SSL is the redirect with the auth_code which is very short-lived (30 seconds) and is tied to a verified redirect URI. * We enforce that access tokens must be provided using the Authorization header only (and of course, over SSL). * We have guidelines saying that all mobile apps must use the native browser (and not an embedded web UI). Questions: ======== 1. Given the above scenario, what use are refresh tokens? - Access tokens can not leak because every request (to resource and authz server) containing an access token is done over SSL. We control both the authz and resource servers, so tokens in logs (and other suggested reasons in the archives) are not an issue. - Long-lived refresh tokens and short-lived access tokens are supposed to provide security due to possible access token leakage... but in our 100% SSL scenario, if access tokens are able to leak, then so would the client id, secret and refresh token. - Having a long-lived refresh token that can be exchanged for another access token adds a level of complexity (a second HTTPS request every so often) and seems to provide no benefit for our case. 2. What is the point of the client secret (in our scenario)? - We originally were treating the clients as confidential, but after re-reading the native-application section, it seems we really should treat them as public (phone apps can be decompiled and the secret discovered). - The spec says that the authz server should authenticate confidential clients, but public clients are allowed to just send their public client id (and no secret). - The only verification then, is to enforce redirect URI registration and to validate the redirect URI between authorization and token steps. So, the question is, assuming that we, one: "enforce redirect-URI registration" and two: "validate that URI" - why can't we treat all clients as public and not worry about a secret? What is the benefit of having confidential clients (and a secret) at all? Our API source is not available, but the oauth2 server implementation can be seen here: https://github.com/quizlet/oauth2-php Regards, Dave --001636c9274b8f158c04ac607430 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi a= ll,

I have been implementing OAuth2 based on the various= drafts for our new API. Initially, I implemented everything as per the spe= c, but due to our particular scenario and restrictions we have in place, th= ere are some fundamental questions that I am unable to defend.

I am hoping this group could help answer them for me.

Our scenario:
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
* We are implementing an API to allow 3rd party developers to access= users' protected resources via their applications. The applications wi= ll mostly be native phone apps, but some will have web server backends (jav= ascript-only applications are not a concern at the moment).
* We want to provide very long-lived (forever) tokens.
* We = are implementing the "authorization code" flow as that seems best= suited to us (we don't want the=A0implicit=A0flow because end-users wo= uld have to re-authorize every hour).

Our architecture:
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
* We control both the API server and the authorization = server.
* All requests to=A0protected=A0resources (ie: to the API= server) are always done over SSL.
* All requests to the authz server (token and authorize endpoints) are= always done over SSL.
* We enforce that every client must supply= the state parameter (and our guidelines say they must verify the state for= CSRF mitigation).
* We enforce that every client must register a redirect URI.
* We validate the redirect_uri used to request an access token is the same= that was used to obtain the auth code.
* The only time a request= is not made over SSL is the redirect with the auth_code which is very shor= t-lived (30 seconds) and is tied to a verified redirect URI.
* We enforce that access tokens must be provided using the Authorizati= on header only (and of course, over SSL).
* We have guidelines sa= ying that all mobile apps must use the native browser (and not an embedded = web UI).

Questions:
=3D=3D=3D=3D=3D=3D=3D=3D
1. Given the above scenario, what use are refresh tokens?
=A0 - = Access tokens can not leak because every request (to resource and authz ser= ver) containing an access token is done over SSL. We control both the authz= and resource servers, so tokens in logs (and other suggested reasons in th= e archives) are not an issue.
=A0 - Long-lived refresh tokens and short-lived access tokens are supp= osed to provide security due to possible access token leakage... but in our= 100% SSL=A0scenario, if access tokens are able to leak, then so would the = client id, secret and refresh token.
=A0 - Having a long-lived refresh token that can be exchanged for anot= her access token adds a level of complexity (a second HTTPS request every s= o often) and seems to provide no benefit for our case.


2. What is the point of the client secret (in our scena= rio)?=A0
- We origi= nally were treating the clients as=A0confidential, but after re-reading the= native-application section, it seems we really=A0should=A0treat them as pu= blic (phone apps can be decompiled and the secret discovered).
- The spec says that the a= uthz server should authenticate=A0confidential=A0clients, but public client= s are allowed to just send their public client id (and no secret).
- The only verification then, is to enforce redirect URI registration = and to validate the redirect URI between authorization and token steps.

So, the questi= on is, assuming that we, one: "enforce redirect-URI registration"= and two: "validate that URI" - why can't we treat all client= s as public and not worry about a secret?
What is the benefit of hav= ing=A0confidential=A0clients (and a secret) at all?=A0


Our API source is not available, but the oaut= h2 server implementation can be seen here:=A0https://github.com/quizlet/oauth2-php=

Regards,
Dave

--001636c9274b8f158c04ac607430-- From wmills@yahoo-inc.com Wed Sep 7 15:25: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 1AB4821F8E23 for ; Wed, 7 Sep 2011 15:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.385 X-Spam-Level: X-Spam-Status: No, score=-17.385 tagged_above=-999 required=5 tests=[AWL=0.213, 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 2zJK2MlQbI-s for ; Wed, 7 Sep 2011 15:25:50 -0700 (PDT) Received: from web31816.mail.mud.yahoo.com (web31816.mail.mud.yahoo.com [68.142.206.169]) by ietfa.amsl.com (Postfix) with SMTP id B5CCC21F8E17 for ; Wed, 7 Sep 2011 15:25:50 -0700 (PDT) Received: (qmail 78697 invoked by uid 60001); 7 Sep 2011 22:27:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1315434455; bh=BAFpB/BAydmMadzzQmHqjpyStxGCF2AoEjNM9I8ufgs=; 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=CO84wbFoSR+nBxmZ9x/MKiy5utQGUZ2CUnY15zT24eEjZM4G0E+T082Cw8AkZKHxrF9l1uHmkaPGf8geBw0q614AfmhZ4T4EbzsWlWZ7oZAxW13NiKLncO3mf0C0zUICYbYawHHRcurbjqXG6SY97y5USSQr0qQUBMKBoOwNy3Q= 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=Aa45ZHVP45Xt5JDye2R0sdDHgg5G9Mxy7CGA0RQcRTudzdreT8Tbncyrkg3n1r8CoMdkoYuupANbhMV4OMm2v1sCPx++Ua6K9jOrctYQZjjve3WL9fJJDg89d4zJbbZTy3jHIK6qQ9iGPh0gP4NVQXvvl+3PyCLtkPQYbkwlrB8=; X-YMail-OSG: IMnOSAIVM1mFB81aECrWmGf8nx.OodUs.0oMP3ujGYo9UdO XHGC5q5SiIMg7NTF30gCLXsrDLakZGD1w72GlgvhMCTVQkAJ93xe78tT6qaG kXbUONxKrlTUpA8tAxD2K5mfaQNd9j_0Kkfs4iyXjJj8pg2RdwHzC3kGwh8d F.52qsObracXbMJgFK2GMomLd5UzyOho5GqfoE4uw695ecloZaAkdL0lO9iO 1YJnjkENnpDJP4BA.nRqL251lPRi_fm8yXjH5oXk9UrZAXd69pWzv2MFLpcy guKvewW1lt88zkMbBh0etW3BCV.MJsrWiuGSWOr1esxp2bBBloyZh_qMXu6j faggWVU.oSLPAEv.HcJiYdSHaHjAez9BlLrA2CeSY3_hm1STP0LJ9IaiuoLJ f_nfJzl2of4AGDolL_IELW7tPgv5pVnW9RuRBTfWMSEbxRqXwutLdcy2VNUk KkPty8WxVIF2hWirdZfKIKyJ8g8yR4f5tB5elNKC_Q6As1PTcWXXAsTUxLtH fidM- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Wed, 07 Sep 2011 15:27:34 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.113.313619 References: Message-ID: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Wed, 7 Sep 2011 15:27:34 -0700 (PDT) From: William Mills To: Dave Rochwerger , "oauth@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1244837766-1315434454=:76681" Cc: Quizlet Dev Team Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) 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: Wed, 07 Sep 2011 22:25:52 -0000 --0-1244837766-1315434454=:76681 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I'll talk to the refresh token question:=A0 they give you a hook for extens= ibility and key rotation.=A0 If you want to rotate your encryption keys or = extend the data carried in the token in any way then you want to be able to= cleanly refresh your tokens.=A0 Note that the refresh flow allows you to i= ssue a new refresh token at the same time.=A0 It also allows a clean path t= o convert tokens in a new client if you decide you want SAML tokens instead= of MAC for example.=0A=0AIf you want those things you want to use refresh = tokens.=A0 You can have long lived access tokens too, and just use the refr= esh tokens when you want to do something new with the access tokens.=0A=0A= =0A-bill=0A=0A=0A=0A________________________________=0AFrom: Dave Rochwerge= r =0ATo: oauth@ietf.org=0ACc: Quizlet Dev Team =0ASent: Wednesday, September 7, 2011 2:15 PM=0ASubject: [OAUTH= -WG] OAuth2 Implementation questions (client secret and refresh tokens)=0A= =0A=0AHi all,=0A=0AI have been implementing OAuth2 based on the various dra= fts for our new API. Initially, I implemented everything as per the spec, b= ut due to our particular scenario and restrictions we have in place, there = are some fundamental questions that I am unable to defend.=0A=0AI am hoping= this group could help answer them for me.=0A=0AOur scenario:=0A=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=0A* We are implementing an API to allow 3rd party dev= elopers to access users' protected resources via their applications. The ap= plications will mostly be native phone apps, but some will have web server = backends (javascript-only applications are not a concern at the moment).=0A= * We want to provide very long-lived (forever) tokens.=0A* We are implement= ing the "authorization code" flow as that seems best suited to us (we don't= want the=A0implicit=A0flow because end-users would have to re-authorize ev= ery hour).=0A=0AOur architecture:=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= * We control both the API server and the authorization server.=0A* All requ= ests to=A0protected=A0resources (ie: to the API server) are always done ove= r SSL.=0A* All requests to the authz server (token and authorize endpoints)= are always done over SSL.=0A* We enforce that every client must supply the= state parameter (and our guidelines say they must verify the state for CSR= F mitigation).=0A* We enforce that every client must register a redirect UR= I.=0A* We validate the redirect_uri used to request an access token is the = same that was used to obtain the auth code.=0A* The only time a request is = not made over SSL is the redirect with the auth_code which is very short-li= ved (30 seconds) and is tied to a verified redirect URI.=0A* We enforce tha= t access tokens must be provided using the Authorization header only (and o= f course, over SSL).=0A* We have guidelines saying that all mobile apps mus= t use the native browser (and not an embedded web UI).=0A=0AQuestions:=0A= =3D=3D=3D=3D=3D=3D=3D=3D=0A1. Given the above scenario, what use are refres= h tokens?=0A=A0 - Access tokens can not leak because every request (to reso= urce and authz server) containing an access token is done over SSL. We cont= rol both the authz and resource servers, so tokens in logs (and other sugge= sted reasons in the archives) are not an issue.=0A=A0 - Long-lived refresh = tokens and short-lived access tokens are supposed to provide security due t= o possible access token leakage... but in our 100% SSL=A0scenario, if acces= s tokens are able to leak, then so would the client id, secret and refresh = token.=0A=A0 - Having a long-lived refresh token that can be exchanged for = another access token adds a level of complexity (a second HTTPS request eve= ry so often) and seems to provide no benefit for our case.=0A=0A=0A2. What = is the point of the client secret (in our scenario)?=A0- We originally were= treating the clients as=A0confidential, but after re-reading the native-ap= plication section, it seems we really=A0should=A0treat them as public (phon= e apps can be decompiled and the secret discovered).=0A- The spec says that= the authz server should authenticate=A0confidential=A0clients, but public = clients are allowed to just send their public client id (and no secret).=0A= - The only verification then, is to enforce redirect URI registration and t= o validate the redirect URI between authorization and token steps.=0ASo, th= e question is, assuming that we, one: "enforce redirect-URI registration" a= nd two: "validate that URI" - why can't we treat all clients as public and = not worry about a secret?=0AWhat is the benefit of having=A0confidential=A0= clients (and a secret) at all?=A0=0A=0A=0AOur API source is not available, = but the oauth2 server implementation can be seen here:=A0https://github.com= /quizlet/oauth2-php=0A=0ARegards,=0ADave=0A=0A_____________________________= __________________=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf= .org/mailman/listinfo/oauth --0-1244837766-1315434454=:76681 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I'll talk to the refresh token question:  they give you a hook for e= xtensibility and key rotation.  If you want to rotate your encryption = keys or extend the data carried in the token in any way then you want to be= able to cleanly refresh your tokens.  Note that the refresh flow allo= ws you to issue a new refresh token at the same time.  It also allows = a clean path to convert tokens in a new client if you decide you want SAML = tokens instead of MAC for example.

If you w= ant those things you want to use refresh tokens.  You can have long li= ved access tokens too, and just use the refresh tokens when you want to do = something new with the access tokens.

-b= ill

From: Dave Rochwerger <daver@quizlet.com>
= To: oauth@ietf.org
Cc: Quizlet Dev Team <devteam@= quizlet.com>
Sent: W= ednesday, September 7, 2011 2:15 PM
Hi all,

I have been implementing OAuth2 based on the various drafts for our = new API. Initially, I implemented everything as per the spec, but due to ou= r particular scenario and restrictions we have in place, there are some fun= damental questions that I am unable to defend.
=0A=0A=0A

I am hoping this group could help answer them for me.

<= /div>
Our scenario:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* We ar= e implementing an API to allow 3rd party developers to access users' protec= ted resources via their applications. The applications will mostly be nativ= e phone apps, but some will have web server backends (javascript-only appli= cations are not a concern at the moment).
=0A=0A=0A
* We want to p= rovide very long-lived (forever) tokens.
* We are implementing th= e "authorization code" flow as that seems best suited to us (we don't want = the implicit flow because end-users would have to re-authorize ev= ery hour).
=0A=0A=0A

Our architecture:
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* We control both the API se= rver and the authorization server.
* All requests to protect= ed resources (ie: to the API server) are always done over SSL.
= =0A=0A=0A
* All requests to the authz server (token and authorize endpo= ints) are always done over SSL.
* We enforce that every client mu= st supply the state parameter (and our guidelines say they must verify the = state for CSRF mitigation).
=0A=0A=0A
* We enforce that every clie= nt must register a redirect URI.
* We validate the redirect_uri u= sed to request an access token is the same that was used to obtain the auth= code.
* The only time a request is not made over SSL is the redi= rect with the auth_code which is very short-lived (30 seconds) and is tied = to a verified redirect URI.
=0A=0A=0A
* We enforce that access tok= ens must be provided using the Authorization header only (and of course, ov= er SSL).
* We have guidelines saying that all mobile apps must us= e the native browser (and not an embedded web UI).
=0A=0A=0A

<= /div>
Questions:
=3D=3D=3D=3D=3D=3D=3D=3D
1. Given = the above scenario, what use are refresh tokens?
  - Access = tokens can not leak because every request (to resource and authz server) co= ntaining an access token is done over SSL. We control both the authz and re= source servers, so tokens in logs (and other suggested reasons in the archi= ves) are not an issue.
=0A=0A=0A
  - Long-lived refresh token= s and short-lived access tokens are supposed to provide security due to pos= sible access token leakage... but in our 100% SSL scenario, if access = tokens are able to leak, then so would the client id, secret and refresh to= ken.
=0A=0A=0A
  - Having a long-lived refresh token that can= be exchanged for another access token adds a level of complexity (a second= HTTPS request every so often) and seems to provide no benefit for our case= .

=0A=0A=0A

2. What is the point of = the client secret (in our scenario)? 
- We originally were treating the clients as = confidential, but after re-reading the native-application section, it seems= we really should treat them as public (phone apps can be decompi= led and the secret discovered).
=0A=0A=0A
- The spec says that the authz server should aut= henticate confidential clients, but public clients are allowed to= just send their public client id (and no secret).
=0A=0A=0A
- The= only verification then, is to enforce redirect URI registration and to val= idate the redirect URI between authorization and token steps.
<= span style=3D"color:rgb(34, 34, 34);font-family:arial, sans-serif;font-size= :13px;background-color:rgb(255, 255, 255);">
=0A=0A=0A
So, the question is, assuming = that we, one: "enforce redirect-URI registration" and two: "validate that U= RI" - why can't we treat all clients as public and not worry about a secret= ?
=0A=0A=0A
Wh= at is the benefit of having confidential clients (and a secret) a= t all? 
=0A=0A= =0A

Our API source is not available, but the o= auth2 server implementation can be seen here: https://github= .com/quizlet/oauth2-php
=0A=0A

=0A
Regards,
Dave
=0A


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


--0-1244837766-1315434454=:76681-- From phil.hunt@oracle.com Wed Sep 7 16:22: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 6801921F8C93 for ; Wed, 7 Sep 2011 16:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 DJedblwwrrVl for ; Wed, 7 Sep 2011 16:22:34 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id F3EB821F8C92 for ; Wed, 7 Sep 2011 16:22:33 -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 p87NOL8O022945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 23:24:23 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 p87NOKwp025060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 23:24:20 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p87NOEqJ020301; Wed, 7 Sep 2011 18:24:14 -0500 Received: from [192.168.1.67] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 16:24:14 -0700 References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--24278826 Message-Id: <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> X-Mailer: iPhone Mail (8L1) From: Phillip Hunt Date: Wed, 7 Sep 2011 16:24:11 -0700 To: William Mills X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090206.4E67FD28.006B,ss=1,re=-2.300,fgs=0 Cc: Quizlet Dev Team , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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: Wed, 07 Sep 2011 23:22:35 -0000 --Apple-Mail-1--24278826 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You can also use a long lived refresh token in combination with a short acce= ss token. The client is then forced to periodically reauthenticate (without t= he user) before getting a new access token.=20 Refresh also gives the authzn server a chance to revoke access. Hence it is b= etter to use shorter lived access tokens with long lived refresh tokens.=20 Phil On 2011-09-07, at 15:27, William Mills wrote: > I'll talk to the refresh token question: they give you a hook for extensi= bility and key rotation. If you want to rotate your encryption keys or exte= nd the data carried in the token in any way then you want to be able to clea= nly refresh your tokens. Note that the refresh flow allows you to issue a n= ew refresh token at the same time. It also allows a clean path to convert t= okens in a new client if you decide you want SAML tokens instead of MAC for e= xample. >=20 > If you want those things you want to use refresh tokens. You can have lon= g lived access tokens too, and just use the refresh tokens when you want to d= o something new with the access tokens. >=20 > -bill >=20 > From: Dave Rochwerger > To: oauth@ietf.org > Cc: Quizlet Dev Team > Sent: Wednesday, September 7, 2011 2:15 PM > Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret and ref= resh tokens) >=20 > Hi all, >=20 > I have been implementing OAuth2 based on the various drafts for our new AP= I. Initially, I implemented everything as per the spec, but due to our parti= cular scenario and restrictions we have in place, there are some fundamental= questions that I am unable to defend. >=20 > I am hoping this group could help answer them for me. >=20 > Our scenario: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * We are implementing an API to allow 3rd party developers to access users= ' protected resources via their applications. The applications will mostly b= e native phone apps, but some will have web server backends (javascript-only= applications are not a concern at the moment). > * We want to provide very long-lived (forever) tokens. > * We are implementing the "authorization code" flow as that seems best sui= ted to us (we don't want the implicit flow because end-users would have to r= e-authorize every hour). >=20 > Our architecture: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * We control both the API server and the authorization server. > * All requests to protected resources (ie: to the API server) are always d= one over SSL. > * All requests to the authz server (token and authorize endpoints) are alw= ays done over SSL. > * We enforce that every client must supply the state parameter (and our gu= idelines say they must verify the state for CSRF mitigation). > * We enforce that every client must register a redirect URI. > * We validate the redirect_uri used to request an access token is the same= that was used to obtain the auth code. > * The only time a request is not made over SSL is the redirect with the au= th_code which is very short-lived (30 seconds) and is tied to a verified red= irect URI. > * We enforce that access tokens must be provided using the Authorization h= eader only (and of course, over SSL). > * We have guidelines saying that all mobile apps must use the native brows= er (and not an embedded web UI). >=20 > Questions: > =3D=3D=3D=3D=3D=3D=3D=3D > 1. Given the above scenario, what use are refresh tokens? > - Access tokens can not leak because every request (to resource and auth= z server) containing an access token is done over SSL. We control both the a= uthz and resource servers, so tokens in logs (and other suggested reasons in= the archives) are not an issue. > - Long-lived refresh tokens and short-lived access tokens are supposed t= o provide security due to possible access token leakage... but in our 100% S= SL scenario, if access tokens are able to leak, then so would the client id,= secret and refresh token. > - Having a long-lived refresh token that can be exchanged for another ac= cess token adds a level of complexity (a second HTTPS request every so often= ) and seems to provide no benefit for our case. >=20 >=20 > 2. What is the point of the client secret (in our scenario)?=20 > - We originally were treating the clients as confidential, but after re-re= ading the native-application section, it seems we really should treat them a= s public (phone apps can be decompiled and the secret discovered). > - The spec says that the authz server should authenticate confidential cli= ents, but public clients are allowed to just send their public client id (an= d no secret). > - The only verification then, is to enforce redirect URI registration and t= o validate the redirect URI between authorization and token steps. >=20 > So, the question is, assuming that we, one: "enforce redirect-URI registra= tion" and two: "validate that URI" - why can't we treat all clients as publi= c and not worry about a secret? > What is the benefit of having confidential clients (and a secret) at all?=20= >=20 >=20 > Our API source is not available, but the oauth2 server implementation can b= e seen here: https://github.com/quizlet/oauth2-php >=20 > Regards, > Dave >=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 --Apple-Mail-1--24278826 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
You can also use a long lived refresh t= oken in combination with a short access token. The client is then forced to p= eriodically reauthenticate (without the user) before getting a new access to= ken. 

Refresh also gives the authzn server a c= hance to revoke access. Hence it is better to use shorter lived access token= s with long lived refresh tokens. 

Phil

On 2= 011-09-07, at 15:27, William Mills <wmills@yahoo-inc.com> wrote:

= I'll talk to the refresh token question:  they give you a hook fo= r extensibility and key rotation.  If you want to rotate your encryptio= n keys or extend the data carried in the token in any way then you want to b= e able to cleanly refresh your tokens.  Note that the refresh flow allo= ws you to issue a new refresh token at the same time.  It also allows a= clean path to convert tokens in a new client if you decide you want SAML to= kens instead of MAC for example.

If you want= those things you want to use refresh tokens.  You can have long lived a= ccess tokens too, and just use the refresh tokens when you want to do someth= ing new with the access tokens.

-bill
=

From: Dave Rochwerger <daver@quizlet.com>
To: oauth@ietf.org
Cc:<= /b> Quizlet Dev Team <devteam@quiz= let.com>
Sent: We= dnesday, September 7, 2011 2:15 PM
= Subject: [OAUTH-WG] OAuth2 Implementation questions (client secre= t and refresh tokens)

Hi all,

I= have been implementing OAuth2 based on the various drafts for our new API. I= nitially, I implemented everything as per the spec, but due to our particula= r scenario and restrictions we have in place, there are some fundamental que= stions that I am unable to defend.

I am hoping this group could help answer them for me.

Our scenario:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
* We are implementing an API to allow 3rd party developers to access use= rs' protected resources via their applications. The applications will mostly= be native phone apps, but some will have web server backends (javascript-on= ly applications are not a concern at the moment).
* We want to provide very long-lived (forever) tokens.
* We a= re implementing the "authorization code" flow as that seems best suited to u= s (we don't want the implicit flow because end-users would have to= re-authorize every hour).

Our architecture:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
* We control both the API server and the authorization serv= er.
* All requests to protected resources (ie: to the AP= I server) are always done over SSL.
* All requests to the authz server (token and authorize endpoints) are a= lways done over SSL.
* We enforce that every client must supply th= e state parameter (and our guidelines say they must verify the state for CSR= F mitigation).
* We enforce that every client must register a redirect URI.
= * We validate the redirect_uri used to request an access token is the same t= hat was used to obtain the auth code.
* The only time a request is= not made over SSL is the redirect with the auth_code which is very short-li= ved (30 seconds) and is tied to a verified redirect URI.
* We enforce that access tokens must be provided using the Authorizatio= n header only (and of course, over SSL).
* We have guidelines sayi= ng that all mobile apps must use the native browser (and not an embedded web= UI).

Questions:
=3D=3D=3D=3D=3D=3D=3D=3D
= 1. Given the above scenario, what use are refresh tokens?
  -= Access tokens can not leak because every request (to resource and authz ser= ver) containing an access token is done over SSL. We control both the authz a= nd resource servers, so tokens in logs (and other suggested reasons in the a= rchives) are not an issue.
  - Long-lived refresh tokens and short-lived access tokens are su= pposed to provide security due to possible access token leakage... but in ou= r 100% SSL scenario, if access tokens are able to leak, then so would t= he client id, secret and refresh token.
  - Having a long-lived refresh token that can be exchanged for an= other access token adds a level of complexity (a second HTTPS request every s= o often) and seems to provide no benefit for our case.


2. What is the point of the client secret (in our scenar= io)? 
- We orig= inally were treating the clients as confidential, but after re-reading t= he native-application section, it seems we really should treat the= m as public (phone apps can be decompiled and the secret discovered).=
- The spec says that the au= thz server should authenticate confidential clients, but public cl= ients are allowed to just send their public client id (and no secret).
=
- The only verification then, is to enforce redirect URI registration a= nd to validate the redirect URI between authorization and token steps.
=

So, the questio= n is, assuming that we, one: "enforce redirect-URI registration" and two: "v= alidate that URI" - why can't we treat all clients as public and not worry a= bout a secret?
What is the benefit of havi= ng confidential clients (and a secret) at all? 


Our API source is not available, but the oauth= 2 server implementation can be seen here: https://github.com/quizlet/oauth2-php<= /div>

Regards,
Dave


_______________________________________________
OAuth maili= ng list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth=
= --Apple-Mail-1--24278826-- From eran@hueniverse.com Wed Sep 7 16:24: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 D667921F8DC8 for ; Wed, 7 Sep 2011 16:24:01 -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 T6uHD3Cfv2HQ for ; Wed, 7 Sep 2011 16:24: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 8FB4621F8CA2 for ; Wed, 7 Sep 2011 16:24:00 -0700 (PDT) Received: (qmail 14858 invoked from network); 7 Sep 2011 23:25:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Sep 2011 23:25:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 7 Sep 2011 16:25:47 -0700 From: Eran Hammer-Lahav To: Phillip Hunt , William Mills Date: Wed, 7 Sep 2011 16:23:51 -0700 Thread-Topic: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Thread-Index: AcxttU7Eqjw/ZqU6Q/eHO/7BjfbqogAADUMg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A4F281D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> In-Reply-To: <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@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_90C41DD21FB7C64BB94121FBBC2E7234518A4F281DP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Quizlet Dev Team , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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: Wed, 07 Sep 2011 23:24:02 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234518A4F281DP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGNhbiByZXZva2UgYWNjZXNzIHRva2VucyBidXQgb25seSBpZiB0aGV5IGFyZSBTdGF0ZWZ1 bCAod2hpY2ggdXN1YWxseSBtZWFucyBhIERCIGxvb2t1cCBmb3IgZXZlcnkgQVBJIGNhbGwgd2hp Y2ggZG9lc27igJl0IHNjYWxlIGFzIHdlbGwpLg0KDQpFSEwNCg0KRnJvbTogb2F1dGgtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQ aGlsbGlwIEh1bnQNClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDA3LCAyMDExIDQ6MjQgUE0N ClRvOiBXaWxsaWFtIE1pbGxzDQpDYzogUXVpemxldCBEZXYgVGVhbTsgb2F1dGhAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoMiBJbXBsZW1lbnRhdGlvbiBxdWVzdGlvbnMg KGNsaWVudCBzZWNyZXQgYW5kIHJlZnJlc2ggdG9rZW5zKQ0KDQpZb3UgY2FuIGFsc28gdXNlIGEg bG9uZyBsaXZlZCByZWZyZXNoIHRva2VuIGluIGNvbWJpbmF0aW9uIHdpdGggYSBzaG9ydCBhY2Nl c3MgdG9rZW4uIFRoZSBjbGllbnQgaXMgdGhlbiBmb3JjZWQgdG8gcGVyaW9kaWNhbGx5IHJlYXV0 aGVudGljYXRlICh3aXRob3V0IHRoZSB1c2VyKSBiZWZvcmUgZ2V0dGluZyBhIG5ldyBhY2Nlc3Mg dG9rZW4uDQoNClJlZnJlc2ggYWxzbyBnaXZlcyB0aGUgYXV0aHpuIHNlcnZlciBhIGNoYW5jZSB0 byByZXZva2UgYWNjZXNzLiBIZW5jZSBpdCBpcyBiZXR0ZXIgdG8gdXNlIHNob3J0ZXIgbGl2ZWQg YWNjZXNzIHRva2VucyB3aXRoIGxvbmcgbGl2ZWQgcmVmcmVzaCB0b2tlbnMuDQoNClBoaWwNCg0K T24gMjAxMS0wOS0wNywgYXQgMTU6MjcsIFdpbGxpYW0gTWlsbHMgPHdtaWxsc0B5YWhvby1pbmMu Y29tPG1haWx0bzp3bWlsbHNAeWFob28taW5jLmNvbT4+IHdyb3RlOg0KSSdsbCB0YWxrIHRvIHRo ZSByZWZyZXNoIHRva2VuIHF1ZXN0aW9uOiAgdGhleSBnaXZlIHlvdSBhIGhvb2sgZm9yIGV4dGVu c2liaWxpdHkgYW5kIGtleSByb3RhdGlvbi4gIElmIHlvdSB3YW50IHRvIHJvdGF0ZSB5b3VyIGVu Y3J5cHRpb24ga2V5cyBvciBleHRlbmQgdGhlIGRhdGEgY2FycmllZCBpbiB0aGUgdG9rZW4gaW4g YW55IHdheSB0aGVuIHlvdSB3YW50IHRvIGJlIGFibGUgdG8gY2xlYW5seSByZWZyZXNoIHlvdXIg dG9rZW5zLiAgTm90ZSB0aGF0IHRoZSByZWZyZXNoIGZsb3cgYWxsb3dzIHlvdSB0byBpc3N1ZSBh IG5ldyByZWZyZXNoIHRva2VuIGF0IHRoZSBzYW1lIHRpbWUuICBJdCBhbHNvIGFsbG93cyBhIGNs ZWFuIHBhdGggdG8gY29udmVydCB0b2tlbnMgaW4gYSBuZXcgY2xpZW50IGlmIHlvdSBkZWNpZGUg eW91IHdhbnQgU0FNTCB0b2tlbnMgaW5zdGVhZCBvZiBNQUMgZm9yIGV4YW1wbGUuDQoNCklmIHlv dSB3YW50IHRob3NlIHRoaW5ncyB5b3Ugd2FudCB0byB1c2UgcmVmcmVzaCB0b2tlbnMuICBZb3Ug Y2FuIGhhdmUgbG9uZyBsaXZlZCBhY2Nlc3MgdG9rZW5zIHRvbywgYW5kIGp1c3QgdXNlIHRoZSBy ZWZyZXNoIHRva2VucyB3aGVuIHlvdSB3YW50IHRvIGRvIHNvbWV0aGluZyBuZXcgd2l0aCB0aGUg YWNjZXNzIHRva2Vucy4NCg0KLWJpbGwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkZyb206IERhdmUgUm9jaHdlcmdlciA8ZGF2ZXJAcXVpemxldC5jb208bWFpbHRvOmRhdmVy QHF1aXpsZXQuY29tPj4NClRvOiBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ DQpDYzogUXVpemxldCBEZXYgVGVhbSA8ZGV2dGVhbUBxdWl6bGV0LmNvbTxtYWlsdG86ZGV2dGVh bUBxdWl6bGV0LmNvbT4+DQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciA3LCAyMDExIDI6MTUg UE0NClN1YmplY3Q6IFtPQVVUSC1XR10gT0F1dGgyIEltcGxlbWVudGF0aW9uIHF1ZXN0aW9ucyAo Y2xpZW50IHNlY3JldCBhbmQgcmVmcmVzaCB0b2tlbnMpDQpIaSBhbGwsDQoNCkkgaGF2ZSBiZWVu IGltcGxlbWVudGluZyBPQXV0aDIgYmFzZWQgb24gdGhlIHZhcmlvdXMgZHJhZnRzIGZvciBvdXIg bmV3IEFQSS4gSW5pdGlhbGx5LCBJIGltcGxlbWVudGVkIGV2ZXJ5dGhpbmcgYXMgcGVyIHRoZSBz cGVjLCBidXQgZHVlIHRvIG91ciBwYXJ0aWN1bGFyIHNjZW5hcmlvIGFuZCByZXN0cmljdGlvbnMg d2UgaGF2ZSBpbiBwbGFjZSwgdGhlcmUgYXJlIHNvbWUgZnVuZGFtZW50YWwgcXVlc3Rpb25zIHRo YXQgSSBhbSB1bmFibGUgdG8gZGVmZW5kLg0KDQpJIGFtIGhvcGluZyB0aGlzIGdyb3VwIGNvdWxk IGhlbHAgYW5zd2VyIHRoZW0gZm9yIG1lLg0KDQpPdXIgc2NlbmFyaW86DQo9PT09PT09PT09DQoq IFdlIGFyZSBpbXBsZW1lbnRpbmcgYW4gQVBJIHRvIGFsbG93IDNyZCBwYXJ0eSBkZXZlbG9wZXJz IHRvIGFjY2VzcyB1c2VycycgcHJvdGVjdGVkIHJlc291cmNlcyB2aWEgdGhlaXIgYXBwbGljYXRp b25zLiBUaGUgYXBwbGljYXRpb25zIHdpbGwgbW9zdGx5IGJlIG5hdGl2ZSBwaG9uZSBhcHBzLCBi dXQgc29tZSB3aWxsIGhhdmUgd2ViIHNlcnZlciBiYWNrZW5kcyAoamF2YXNjcmlwdC1vbmx5IGFw cGxpY2F0aW9ucyBhcmUgbm90IGEgY29uY2VybiBhdCB0aGUgbW9tZW50KS4NCiogV2Ugd2FudCB0 byBwcm92aWRlIHZlcnkgbG9uZy1saXZlZCAoZm9yZXZlcikgdG9rZW5zLg0KKiBXZSBhcmUgaW1w bGVtZW50aW5nIHRoZSAiYXV0aG9yaXphdGlvbiBjb2RlIiBmbG93IGFzIHRoYXQgc2VlbXMgYmVz dCBzdWl0ZWQgdG8gdXMgKHdlIGRvbid0IHdhbnQgdGhlIGltcGxpY2l0IGZsb3cgYmVjYXVzZSBl bmQtdXNlcnMgd291bGQgaGF2ZSB0byByZS1hdXRob3JpemUgZXZlcnkgaG91cikuDQoNCk91ciBh cmNoaXRlY3R1cmU6DQo9PT09PT09PT09PT0NCiogV2UgY29udHJvbCBib3RoIHRoZSBBUEkgc2Vy dmVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQoqIEFsbCByZXF1ZXN0cyB0byBwcm90 ZWN0ZWQgcmVzb3VyY2VzIChpZTogdG8gdGhlIEFQSSBzZXJ2ZXIpIGFyZSBhbHdheXMgZG9uZSBv dmVyIFNTTC4NCiogQWxsIHJlcXVlc3RzIHRvIHRoZSBhdXRoeiBzZXJ2ZXIgKHRva2VuIGFuZCBh dXRob3JpemUgZW5kcG9pbnRzKSBhcmUgYWx3YXlzIGRvbmUgb3ZlciBTU0wuDQoqIFdlIGVuZm9y Y2UgdGhhdCBldmVyeSBjbGllbnQgbXVzdCBzdXBwbHkgdGhlIHN0YXRlIHBhcmFtZXRlciAoYW5k IG91ciBndWlkZWxpbmVzIHNheSB0aGV5IG11c3QgdmVyaWZ5IHRoZSBzdGF0ZSBmb3IgQ1NSRiBt aXRpZ2F0aW9uKS4NCiogV2UgZW5mb3JjZSB0aGF0IGV2ZXJ5IGNsaWVudCBtdXN0IHJlZ2lzdGVy IGEgcmVkaXJlY3QgVVJJLg0KKiBXZSB2YWxpZGF0ZSB0aGUgcmVkaXJlY3RfdXJpIHVzZWQgdG8g cmVxdWVzdCBhbiBhY2Nlc3MgdG9rZW4gaXMgdGhlIHNhbWUgdGhhdCB3YXMgdXNlZCB0byBvYnRh aW4gdGhlIGF1dGggY29kZS4NCiogVGhlIG9ubHkgdGltZSBhIHJlcXVlc3QgaXMgbm90IG1hZGUg b3ZlciBTU0wgaXMgdGhlIHJlZGlyZWN0IHdpdGggdGhlIGF1dGhfY29kZSB3aGljaCBpcyB2ZXJ5 IHNob3J0LWxpdmVkICgzMCBzZWNvbmRzKSBhbmQgaXMgdGllZCB0byBhIHZlcmlmaWVkIHJlZGly ZWN0IFVSSS4NCiogV2UgZW5mb3JjZSB0aGF0IGFjY2VzcyB0b2tlbnMgbXVzdCBiZSBwcm92aWRl ZCB1c2luZyB0aGUgQXV0aG9yaXphdGlvbiBoZWFkZXIgb25seSAoYW5kIG9mIGNvdXJzZSwgb3Zl ciBTU0wpLg0KKiBXZSBoYXZlIGd1aWRlbGluZXMgc2F5aW5nIHRoYXQgYWxsIG1vYmlsZSBhcHBz IG11c3QgdXNlIHRoZSBuYXRpdmUgYnJvd3NlciAoYW5kIG5vdCBhbiBlbWJlZGRlZCB3ZWIgVUkp Lg0KDQpRdWVzdGlvbnM6DQo9PT09PT09PQ0KMS4gR2l2ZW4gdGhlIGFib3ZlIHNjZW5hcmlvLCB3 aGF0IHVzZSBhcmUgcmVmcmVzaCB0b2tlbnM/DQogIC0gQWNjZXNzIHRva2VucyBjYW4gbm90IGxl YWsgYmVjYXVzZSBldmVyeSByZXF1ZXN0ICh0byByZXNvdXJjZSBhbmQgYXV0aHogc2VydmVyKSBj b250YWluaW5nIGFuIGFjY2VzcyB0b2tlbiBpcyBkb25lIG92ZXIgU1NMLiBXZSBjb250cm9sIGJv dGggdGhlIGF1dGh6IGFuZCByZXNvdXJjZSBzZXJ2ZXJzLCBzbyB0b2tlbnMgaW4gbG9ncyAoYW5k IG90aGVyIHN1Z2dlc3RlZCByZWFzb25zIGluIHRoZSBhcmNoaXZlcykgYXJlIG5vdCBhbiBpc3N1 ZS4NCiAgLSBMb25nLWxpdmVkIHJlZnJlc2ggdG9rZW5zIGFuZCBzaG9ydC1saXZlZCBhY2Nlc3Mg dG9rZW5zIGFyZSBzdXBwb3NlZCB0byBwcm92aWRlIHNlY3VyaXR5IGR1ZSB0byBwb3NzaWJsZSBh Y2Nlc3MgdG9rZW4gbGVha2FnZS4uLiBidXQgaW4gb3VyIDEwMCUgU1NMIHNjZW5hcmlvLCBpZiBh Y2Nlc3MgdG9rZW5zIGFyZSBhYmxlIHRvIGxlYWssIHRoZW4gc28gd291bGQgdGhlIGNsaWVudCBp ZCwgc2VjcmV0IGFuZCByZWZyZXNoIHRva2VuLg0KICAtIEhhdmluZyBhIGxvbmctbGl2ZWQgcmVm cmVzaCB0b2tlbiB0aGF0IGNhbiBiZSBleGNoYW5nZWQgZm9yIGFub3RoZXIgYWNjZXNzIHRva2Vu IGFkZHMgYSBsZXZlbCBvZiBjb21wbGV4aXR5IChhIHNlY29uZCBIVFRQUyByZXF1ZXN0IGV2ZXJ5 IHNvIG9mdGVuKSBhbmQgc2VlbXMgdG8gcHJvdmlkZSBubyBiZW5lZml0IGZvciBvdXIgY2FzZS4N Cg0KDQoyLiBXaGF0IGlzIHRoZSBwb2ludCBvZiB0aGUgY2xpZW50IHNlY3JldCAoaW4gb3VyIHNj ZW5hcmlvKT8NCi0gV2Ugb3JpZ2luYWxseSB3ZXJlIHRyZWF0aW5nIHRoZSBjbGllbnRzIGFzIGNv bmZpZGVudGlhbCwgYnV0IGFmdGVyIHJlLXJlYWRpbmcgdGhlIG5hdGl2ZS1hcHBsaWNhdGlvbiBz ZWN0aW9uLCBpdCBzZWVtcyB3ZSByZWFsbHkgc2hvdWxkIHRyZWF0IHRoZW0gYXMgcHVibGljIChw aG9uZSBhcHBzIGNhbiBiZSBkZWNvbXBpbGVkIGFuZCB0aGUgc2VjcmV0IGRpc2NvdmVyZWQpLg0K LSBUaGUgc3BlYyBzYXlzIHRoYXQgdGhlIGF1dGh6IHNlcnZlciBzaG91bGQgYXV0aGVudGljYXRl IGNvbmZpZGVudGlhbCBjbGllbnRzLCBidXQgcHVibGljIGNsaWVudHMgYXJlIGFsbG93ZWQgdG8g anVzdCBzZW5kIHRoZWlyIHB1YmxpYyBjbGllbnQgaWQgKGFuZCBubyBzZWNyZXQpLg0KLSBUaGUg b25seSB2ZXJpZmljYXRpb24gdGhlbiwgaXMgdG8gZW5mb3JjZSByZWRpcmVjdCBVUkkgcmVnaXN0 cmF0aW9uIGFuZCB0byB2YWxpZGF0ZSB0aGUgcmVkaXJlY3QgVVJJIGJldHdlZW4gYXV0aG9yaXph dGlvbiBhbmQgdG9rZW4gc3RlcHMuDQoNClNvLCB0aGUgcXVlc3Rpb24gaXMsIGFzc3VtaW5nIHRo YXQgd2UsIG9uZTogImVuZm9yY2UgcmVkaXJlY3QtVVJJIHJlZ2lzdHJhdGlvbiIgYW5kIHR3bzog InZhbGlkYXRlIHRoYXQgVVJJIiAtIHdoeSBjYW4ndCB3ZSB0cmVhdCBhbGwgY2xpZW50cyBhcyBw dWJsaWMgYW5kIG5vdCB3b3JyeSBhYm91dCBhIHNlY3JldD8NCldoYXQgaXMgdGhlIGJlbmVmaXQg b2YgaGF2aW5nIGNvbmZpZGVudGlhbCBjbGllbnRzIChhbmQgYSBzZWNyZXQpIGF0IGFsbD8NCg0K DQpPdXIgQVBJIHNvdXJjZSBpcyBub3QgYXZhaWxhYmxlLCBidXQgdGhlIG9hdXRoMiBzZXJ2ZXIg aW1wbGVtZW50YXRpb24gY2FuIGJlIHNlZW4gaGVyZTogaHR0cHM6Ly9naXRodWIuY29tL3F1aXps ZXQvb2F1dGgyLXBocA0KDQpSZWdhcmRzLA0KRGF2ZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aA0K --_000_90C41DD21FB7C64BB94121FBBC2E7234518A4F281DP3PW5EX1MB01E_ 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 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29sb3I9d2hpdGUg bGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24x PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPllvdSBjYW4gcmV2b2tl IGFjY2VzcyB0b2tlbnMgYnV0IG9ubHkgaWYgdGhleSBhcmUgU3RhdGVmdWwgKHdoaWNoIHVzdWFs bHkgbWVhbnMgYSBEQiBsb29rdXAgZm9yIGV2ZXJ5IEFQSSBjYWxsIHdoaWNoIGRvZXNu4oCZdCBz Y2FsZSBhcyB3ZWxsKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2Jv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+UGhpbGxpcCBIdW50PGJyPjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIFNlcHRlbWJlciAwNywgMjAxMSA0OjI0IFBNPGJyPjxiPlRvOjwvYj4gV2lsbGlh bSBNaWxsczxicj48Yj5DYzo8L2I+IFF1aXpsZXQgRGV2IFRlYW07IG9hdXRoQGlldGYub3JnPGJy PjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBPQXV0aDIgSW1wbGVtZW50YXRpb24gcXVl c3Rpb25zIChjbGllbnQgc2VjcmV0IGFuZCByZWZyZXNoIHRva2Vucyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPllvdSBjYW4gYWxzbyB1c2UgYSBsb25nIGxpdmVkIHJl ZnJlc2ggdG9rZW4gaW4gY29tYmluYXRpb24gd2l0aCBhIHNob3J0IGFjY2VzcyB0b2tlbi4gVGhl IGNsaWVudCBpcyB0aGVuIGZvcmNlZCB0byBwZXJpb2RpY2FsbHkgcmVhdXRoZW50aWNhdGUgKHdp dGhvdXQgdGhlIHVzZXIpIGJlZm9yZSBnZXR0aW5nIGEgbmV3IGFjY2VzcyB0b2tlbi4mbmJzcDs8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5SZWZyZXNoIGFsc28gZ2l2ZXMg dGhlIGF1dGh6biBzZXJ2ZXIgYSBjaGFuY2UgdG8gcmV2b2tlIGFjY2Vzcy4gSGVuY2UgaXQgaXMg YmV0dGVyIHRvIHVzZSBzaG9ydGVyIGxpdmVkIGFjY2VzcyB0b2tlbnMgd2l0aCBsb25nIGxpdmVk IHJlZnJlc2ggdG9rZW5zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxicj5QaGlsPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+T24gMjAxMS0wOS0wNywgYXQg MTU6MjcsIFdpbGxpYW0gTWlsbHMgJmx0OzxhIGhyZWY9Im1haWx0bzp3bWlsbHNAeWFob28taW5j LmNvbSI+d21pbGxzQHlhaG9vLWluYy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48 L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Jz48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNr Jz5JJ2xsIHRhbGsgdG8gdGhlIHJlZnJlc2ggdG9rZW4gcXVlc3Rpb246Jm5ic3A7IHRoZXkgZ2l2 ZSB5b3UgYSBob29rIGZvciBleHRlbnNpYmlsaXR5IGFuZCBrZXkgcm90YXRpb24uJm5ic3A7IElm IHlvdSB3YW50IHRvIHJvdGF0ZSB5b3VyIGVuY3J5cHRpb24ga2V5cyBvciBleHRlbmQgdGhlIGRh dGEgY2FycmllZCBpbiB0aGUgdG9rZW4gaW4gYW55IHdheSB0aGVuIHlvdSB3YW50IHRvIGJlIGFi bGUgdG8gY2xlYW5seSByZWZyZXNoIHlvdXIgdG9rZW5zLiZuYnNwOyBOb3RlIHRoYXQgdGhlIHJl ZnJlc2ggZmxvdyBhbGxvd3MgeW91IHRvIGlzc3VlIGEgbmV3IHJlZnJlc2ggdG9rZW4gYXQgdGhl IHNhbWUgdGltZS4mbmJzcDsgSXQgYWxzbyBhbGxvd3MgYSBjbGVhbiBwYXRoIHRvIGNvbnZlcnQg dG9rZW5zIGluIGEgbmV3IGNsaWVudCBpZiB5b3UgZGVjaWRlIHlvdSB3YW50IFNBTUwgdG9rZW5z IGluc3RlYWQgb2YgTUFDIGZvciBleGFtcGxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dy b3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6 YmxhY2snPklmIHlvdSB3YW50IHRob3NlIHRoaW5ncyB5b3Ugd2FudCB0byB1c2UgcmVmcmVzaCB0 b2tlbnMuJm5ic3A7IFlvdSBjYW4gaGF2ZSBsb25nIGxpdmVkIGFjY2VzcyB0b2tlbnMgdG9vLCBh bmQganVzdCB1c2UgdGhlIHJlZnJlc2ggdG9rZW5zIHdoZW4geW91IHdhbnQgdG8gZG8gc29tZXRo aW5nIG5ldyB3aXRoIHRoZSBhY2Nlc3MgdG9rZW5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s b3I6YmxhY2snPi1iaWxsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PGRpdj48ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9 J3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48 aHIgc2l6ZT0xIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+PC9zcGFuPjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSc+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+ IERhdmUgUm9jaHdlcmdlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmVyQHF1aXpsZXQuY29tIj5k YXZlckBxdWl6bGV0LmNvbTwvYT4mZ3Q7PGJyPjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+PGI+Q2M6PC9iPiBRdWl6bGV0IERl diBUZWFtICZsdDs8YSBocmVmPSJtYWlsdG86ZGV2dGVhbUBxdWl6bGV0LmNvbSI+ZGV2dGVhbUBx dWl6bGV0LmNvbTwvYT4mZ3Q7PGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIFNlcHRlbWJlciA3 LCAyMDExIDI6MTUgUE08YnI+PGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gT0F1dGgyIEltcGxl bWVudGF0aW9uIHF1ZXN0aW9ucyAoY2xpZW50IHNlY3JldCBhbmQgcmVmcmVzaCB0b2tlbnMpPC9z cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPkkgaGF2ZSBiZWVuIGltcGxlbWVudGlu ZyBPQXV0aDIgYmFzZWQgb24gdGhlIHZhcmlvdXMgZHJhZnRzIGZvciBvdXIgbmV3IEFQSS4gSW5p dGlhbGx5LCBJIGltcGxlbWVudGVkIGV2ZXJ5dGhpbmcgYXMgcGVyIHRoZSBzcGVjLCBidXQgZHVl IHRvIG91ciBwYXJ0aWN1bGFyIHNjZW5hcmlvIGFuZCByZXN0cmljdGlvbnMgd2UgaGF2ZSBpbiBw bGFjZSwgdGhlcmUgYXJlIHNvbWUgZnVuZGFtZW50YWwgcXVlc3Rpb25zIHRoYXQgSSBhbSB1bmFi bGUgdG8gZGVmZW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzIyMjIyMjtiYWNr Z3JvdW5kOndoaXRlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMyMjIy MjI7YmFja2dyb3VuZDp3aGl0ZSc+SSBhbSBob3BpbmcgdGhpcyBncm91cCBjb3VsZCBoZWxwIGFu c3dlciB0aGVtIGZvciBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7 YmFja2dyb3VuZDp3aGl0ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPk91ciBzY2VuYXJpbzo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+PT09PT09PT09PTxicj4qIFdl IGFyZSBpbXBsZW1lbnRpbmcgYW4gQVBJIHRvIGFsbG93IDNyZCBwYXJ0eSBkZXZlbG9wZXJzIHRv IGFjY2VzcyB1c2VycycgcHJvdGVjdGVkIHJlc291cmNlcyB2aWEgdGhlaXIgYXBwbGljYXRpb25z LiBUaGUgYXBwbGljYXRpb25zIHdpbGwgbW9zdGx5IGJlIG5hdGl2ZSBwaG9uZSBhcHBzLCBidXQg c29tZSB3aWxsIGhhdmUgd2ViIHNlcnZlciBiYWNrZW5kcyAoamF2YXNjcmlwdC1vbmx5IGFwcGxp Y2F0aW9ucyBhcmUgbm90IGEgY29uY2VybiBhdCB0aGUgbW9tZW50KS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+KiBXZSB3YW50IHRvIHBy b3ZpZGUgdmVyeSBsb25nLWxpdmVkIChmb3JldmVyKSB0b2tlbnMuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRl Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPiogV2UgYXJlIGltcGxlbWVu dGluZyB0aGUgJnF1b3Q7YXV0aG9yaXphdGlvbiBjb2RlJnF1b3Q7IGZsb3cgYXMgdGhhdCBzZWVt cyBiZXN0IHN1aXRlZCB0byB1cyAod2UgZG9uJ3Qgd2FudCB0aGUmbmJzcDtpbXBsaWNpdCZuYnNw O2Zsb3cgYmVjYXVzZSBlbmQtdXNlcnMgd291bGQgaGF2ZSB0byByZS1hdXRob3JpemUgZXZlcnkg aG91cikuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6 d2hpdGUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzIyMjIyMjtiYWNr Z3JvdW5kOndoaXRlJz5PdXIgYXJjaGl0ZWN0dXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlJz49PT09PT09PT09PT08bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+KiBXZSBjb250cm9s IGJvdGggdGhlIEFQSSBzZXJ2ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+KiBBbGwg cmVxdWVzdHMgdG8mbmJzcDtwcm90ZWN0ZWQmbmJzcDtyZXNvdXJjZXMgKGllOiB0byB0aGUgQVBJ IHNlcnZlcikgYXJlIGFsd2F5cyBkb25lIG92ZXIgU1NMLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlJz4qIEFsbCByZXF1ZXN0cyB0byB0aGUg YXV0aHogc2VydmVyICh0b2tlbiBhbmQgYXV0aG9yaXplIGVuZHBvaW50cykgYXJlIGFsd2F5cyBk b25lIG92ZXIgU1NMLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzIyMjIyMjtiYWNr Z3JvdW5kOndoaXRlJz4qIFdlIGVuZm9yY2UgdGhhdCBldmVyeSBjbGllbnQgbXVzdCBzdXBwbHkg dGhlIHN0YXRlIHBhcmFtZXRlciAoYW5kIG91ciBndWlkZWxpbmVzIHNheSB0aGV5IG11c3QgdmVy aWZ5IHRoZSBzdGF0ZSBmb3IgQ1NSRiBtaXRpZ2F0aW9uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+KiBXZSBlbmZvcmNlIHRoYXQgZXZl cnkgY2xpZW50IG11c3QgcmVnaXN0ZXIgYSByZWRpcmVjdCBVUkkuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRl Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPiogV2UgdmFsaWRhdGUgdGhl IHJlZGlyZWN0X3VyaSB1c2VkIHRvIHJlcXVlc3QgYW4gYWNjZXNzIHRva2VuIGlzIHRoZSBzYW1l IHRoYXQgd2FzIHVzZWQgdG8gb2J0YWluIHRoZSBhdXRoIGNvZGUuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRl Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPiogVGhlIG9ubHkgdGltZSBh IHJlcXVlc3QgaXMgbm90IG1hZGUgb3ZlciBTU0wgaXMgdGhlIHJlZGlyZWN0IHdpdGggdGhlIGF1 dGhfY29kZSB3aGljaCBpcyB2ZXJ5IHNob3J0LWxpdmVkICgzMCBzZWNvbmRzKSBhbmQgaXMgdGll ZCB0byBhIHZlcmlmaWVkIHJlZGlyZWN0IFVSSS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+KiBXZSBlbmZvcmNlIHRoYXQgYWNjZXNzIHRv a2VucyBtdXN0IGJlIHByb3ZpZGVkIHVzaW5nIHRoZSBBdXRob3JpemF0aW9uIGhlYWRlciBvbmx5 IChhbmQgb2YgY291cnNlLCBvdmVyIFNTTCkuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPiogV2UgaGF2ZSBndWlkZWxpbmVzIHNheWluZyB0 aGF0IGFsbCBtb2JpbGUgYXBwcyBtdXN0IHVzZSB0aGUgbmF0aXZlIGJyb3dzZXIgKGFuZCBub3Qg YW4gZW1iZWRkZWQgd2ViIFVJKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMyMjIy MjI7YmFja2dyb3VuZDp3aGl0ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPlF1ZXN0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+PT09PT09PT08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+MS4gR2l2ZW4g dGhlIGFib3ZlIHNjZW5hcmlvLCB3aGF0IHVzZSBhcmUgcmVmcmVzaCB0b2tlbnM/PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3Jv dW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPiZuYnNwOyAt IEFjY2VzcyB0b2tlbnMgY2FuIG5vdCBsZWFrIGJlY2F1c2UgZXZlcnkgcmVxdWVzdCAodG8gcmVz b3VyY2UgYW5kIGF1dGh6IHNlcnZlcikgY29udGFpbmluZyBhbiBhY2Nlc3MgdG9rZW4gaXMgZG9u ZSBvdmVyIFNTTC4gV2UgY29udHJvbCBib3RoIHRoZSBhdXRoeiBhbmQgcmVzb3VyY2Ugc2VydmVy cywgc28gdG9rZW5zIGluIGxvZ3MgKGFuZCBvdGhlciBzdWdnZXN0ZWQgcmVhc29ucyBpbiB0aGUg YXJjaGl2ZXMpIGFyZSBub3QgYW4gaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPiZuYnNwOyAtIExvbmctbGl2ZWQgcmVmcmVzaCB0 b2tlbnMgYW5kIHNob3J0LWxpdmVkIGFjY2VzcyB0b2tlbnMgYXJlIHN1cHBvc2VkIHRvIHByb3Zp ZGUgc2VjdXJpdHkgZHVlIHRvIHBvc3NpYmxlIGFjY2VzcyB0b2tlbiBsZWFrYWdlLi4uIGJ1dCBp biBvdXIgMTAwJSBTU0wmbmJzcDtzY2VuYXJpbywgaWYgYWNjZXNzIHRva2VucyBhcmUgYWJsZSB0 byBsZWFrLCB0aGVuIHNvIHdvdWxkIHRoZSBjbGllbnQgaWQsIHNlY3JldCBhbmQgcmVmcmVzaCB0 b2tlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3 aGl0ZSc+Jm5ic3A7IC0gSGF2aW5nIGEgbG9uZy1saXZlZCByZWZyZXNoIHRva2VuIHRoYXQgY2Fu IGJlIGV4Y2hhbmdlZCBmb3IgYW5vdGhlciBhY2Nlc3MgdG9rZW4gYWRkcyBhIGxldmVsIG9mIGNv bXBsZXhpdHkgKGEgc2Vjb25kIEhUVFBTIHJlcXVlc3QgZXZlcnkgc28gb2Z0ZW4pIGFuZCBzZWVt cyB0byBwcm92aWRlIG5vIGJlbmVmaXQgZm9yIG91ciBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6 d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNr Z3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPjIuIFdo YXQgaXMgdGhlIHBvaW50IG9mIHRoZSBjbGllbnQgc2VjcmV0IChpbiBvdXIgc2NlbmFyaW8pPyZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+ LSBXZSBvcmlnaW5hbGx5IHdlcmUgdHJlYXRpbmcgdGhlIGNsaWVudHMgYXMmbmJzcDtjb25maWRl bnRpYWwsIGJ1dCBhZnRlciByZS1yZWFkaW5nIHRoZSBuYXRpdmUtYXBwbGljYXRpb24gc2VjdGlv biwgaXQgc2VlbXMgd2UgcmVhbGx5Jm5ic3A7c2hvdWxkJm5ic3A7dHJlYXQgdGhlbSBhcyBwdWJs aWMgKHBob25lIGFwcHMgY2FuIGJlIGRlY29tcGlsZWQgYW5kIHRoZSBzZWNyZXQgZGlzY292ZXJl ZCkuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+LSBUaGUgc3BlYyBzYXlzIHRoYXQg dGhlIGF1dGh6IHNlcnZlciBzaG91bGQgYXV0aGVudGljYXRlJm5ic3A7Y29uZmlkZW50aWFsJm5i c3A7Y2xpZW50cywgYnV0IHB1YmxpYyBjbGllbnRzIGFyZSBhbGxvd2VkIHRvIGp1c3Qgc2VuZCB0 aGVpciBwdWJsaWMgY2xpZW50IGlkIChhbmQgbm8gc2VjcmV0KS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSc+LSBUaGUgb25seSB2ZXJpZmlj YXRpb24gdGhlbiwgaXMgdG8gZW5mb3JjZSByZWRpcmVjdCBVUkkgcmVnaXN0cmF0aW9uIGFuZCB0 byB2YWxpZGF0ZSB0aGUgcmVkaXJlY3QgVVJJIGJldHdlZW4gYXV0aG9yaXphdGlvbiBhbmQgdG9r ZW4gc3RlcHMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMjIyMjIyO2JhY2tncm91 bmQ6d2hpdGUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dy b3VuZDp3aGl0ZSc+U28sIHRoZSBxdWVzdGlvbiBpcywgYXNzdW1pbmcgdGhhdCB3ZSwgb25lOiAm cXVvdDtlbmZvcmNlIHJlZGlyZWN0LVVSSSByZWdpc3RyYXRpb24mcXVvdDsgYW5kIHR3bzogJnF1 b3Q7dmFsaWRhdGUgdGhhdCBVUkkmcXVvdDsgLSB3aHkgY2FuJ3Qgd2UgdHJlYXQgYWxsIGNsaWVu dHMgYXMgcHVibGljIGFuZCBub3Qgd29ycnkgYWJvdXQgYSBzZWNyZXQ/PC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMjIyMjIy O2JhY2tncm91bmQ6d2hpdGUnPldoYXQgaXMgdGhlIGJlbmVmaXQgb2YgaGF2aW5nJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7Y2xpZW50cyAoYW5kIGEgc2VjcmV0KSBhdCBhbGw/Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0 ZSc+T3VyIEFQSSBzb3VyY2UgaXMgbm90IGF2YWlsYWJsZSwgYnV0IHRoZSBvYXV0aDIgc2VydmVy IGltcGxlbWVudGF0aW9uIGNhbiBiZSBzZWVuIGhlcmU6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL3F1aXpsZXQvb2F1dGgyLXBocCI+aHR0cHM6Ly9naXRodWIuY29tL3F1aXpsZXQv b2F1dGgyLXBocDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMyMjIyMjI7YmFj a2dyb3VuZDp3aGl0ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMjIy MjIyO2JhY2tncm91bmQ6d2hpdGUnPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUnPkRhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxicj48 YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1 dGggbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhA aWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQnPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj48YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_90C41DD21FB7C64BB94121FBBC2E7234518A4F281DP3PW5EX1MB01E_-- From daver@quizlet.com Wed Sep 7 17:06: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 4E4F521F87C5 for ; Wed, 7 Sep 2011 17:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Lavp6aeN5V5E for ; Wed, 7 Sep 2011 17:06: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 EF39D21F8797 for ; Wed, 7 Sep 2011 17:06:14 -0700 (PDT) Received: by gyd12 with SMTP id 12so195560gyd.31 for ; Wed, 07 Sep 2011 17:08:05 -0700 (PDT) Received: by 10.150.157.3 with SMTP id f3mr193716ybe.386.1315440485225; Wed, 07 Sep 2011 17:08:05 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by mx.google.com with ESMTPS id 9sm105167ybb.1.2011.09.07.17.08.03 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 17:08:04 -0700 (PDT) Received: by gwb17 with SMTP id 17so290665gwb.15 for ; Wed, 07 Sep 2011 17:08:03 -0700 (PDT) Received: by 10.100.151.9 with SMTP id y9mr28961and.56.1315440483185; Wed, 07 Sep 2011 17:08:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.164.3 with HTTP; Wed, 7 Sep 2011 17:07:43 -0700 (PDT) X-Originating-IP: [67.169.69.75] In-Reply-To: <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> From: Dave Rochwerger Date: Wed, 7 Sep 2011 17:07:43 -0700 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=0016e6461542b934c304ac62da14 Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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, 08 Sep 2011 00:06:16 -0000 --0016e6461542b934c304ac62da14 Content-Type: text/plain; charset=ISO-8859-1 Hi Phil, >> The client is then forced to periodically reauthenticate (without the user) before getting a new access token. What benefit does that have? >> Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. That doesn't follow - we can just as easily revoke the single long-lived access token. Dave. On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: > You can also use a long lived refresh token in combination with a short > access token. The client is then forced to periodically reauthenticate > (without the user) before getting a new access token. > > Refresh also gives the authzn server a chance to revoke access. Hence it is > better to use shorter lived access tokens with long lived refresh tokens. > > Phil > > On 2011-09-07, at 15:27, William Mills wrote: > > I'll talk to the refresh token question: they give you a hook for > extensibility and key rotation. If you want to rotate your encryption keys > or extend the data carried in the token in any way then you want to be able > to cleanly refresh your tokens. Note that the refresh flow allows you to > issue a new refresh token at the same time. It also allows a clean path to > convert tokens in a new client if you decide you want SAML tokens instead of > MAC for example. > > If you want those things you want to use refresh tokens. You can have long > lived access tokens too, and just use the refresh tokens when you want to do > something new with the access tokens. > > -bill > > ------------------------------ > *From:* Dave Rochwerger > *To:* oauth@ietf.org > *Cc:* Quizlet Dev Team > *Sent:* Wednesday, September 7, 2011 2:15 PM > *Subject:* [OAUTH-WG] OAuth2 Implementation questions (client secret and > refresh tokens) > > Hi all, > > I have been implementing OAuth2 based on the various drafts for our new > API. Initially, I implemented everything as per the spec, but due to our > particular scenario and restrictions we have in place, there are some > fundamental questions that I am unable to defend. > > I am hoping this group could help answer them for me. > > Our scenario: > ========== > * We are implementing an API to allow 3rd party developers to access users' > protected resources via their applications. The applications will mostly be > native phone apps, but some will have web server backends (javascript-only > applications are not a concern at the moment). > * We want to provide very long-lived (forever) tokens. > * We are implementing the "authorization code" flow as that seems best > suited to us (we don't want the implicit flow because end-users would have > to re-authorize every hour). > > Our architecture: > ============ > * We control both the API server and the authorization server. > * All requests to protected resources (ie: to the API server) are always > done over SSL. > * All requests to the authz server (token and authorize endpoints) are > always done over SSL. > * We enforce that every client must supply the state parameter (and our > guidelines say they must verify the state for CSRF mitigation). > * We enforce that every client must register a redirect URI. > * We validate the redirect_uri used to request an access token is the same > that was used to obtain the auth code. > * The only time a request is not made over SSL is the redirect with the > auth_code which is very short-lived (30 seconds) and is tied to a verified > redirect URI. > * We enforce that access tokens must be provided using the Authorization > header only (and of course, over SSL). > * We have guidelines saying that all mobile apps must use the native > browser (and not an embedded web UI). > > Questions: > ======== > 1. Given the above scenario, what use are refresh tokens? > - Access tokens can not leak because every request (to resource and authz > server) containing an access token is done over SSL. We control both the > authz and resource servers, so tokens in logs (and other suggested reasons > in the archives) are not an issue. > - Long-lived refresh tokens and short-lived access tokens are supposed to > provide security due to possible access token leakage... but in our 100% > SSL scenario, if access tokens are able to leak, then so would the client > id, secret and refresh token. > - Having a long-lived refresh token that can be exchanged for another > access token adds a level of complexity (a second HTTPS request every so > often) and seems to provide no benefit for our case. > > > 2. What is the point of the client secret (in our scenario)? > - We originally were treating the clients as confidential, but after > re-reading the native-application section, it seems we really should treat > them as public (phone apps can be decompiled and the secret discovered). > - The spec says that the authz server should > authenticate confidential clients, but public clients are allowed to just > send their public client id (and no secret). > - The only verification then, is to enforce redirect URI registration and > to validate the redirect URI between authorization and token steps. > > So, the question is, assuming that we, one: "enforce redirect-URI > registration" and two: "validate that URI" - why can't we treat all clients > as public and not worry about a secret? > What is the benefit of having confidential clients (and a secret) at all? > > > Our API source is not available, but the oauth2 server implementation can > be seen here: > https://github.com/quizlet/oauth2-php > > Regards, > Dave > > > _______________________________________________ > 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 > > --0016e6461542b934c304ac62da14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Phil,

>> The client is then forced to periodically reauthenticate= (without the user) before getting a new access token.=A0
What be= nefit does that have?

>>=A0Refresh also gives the authzn server a chance to revoke acc= ess. Hence it is better to use shorter lived access tokens with long lived = refresh tokens.=A0
That doesn't follow - we can just as= easily revoke the single long-lived access token.

Dave.

On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt <phil.hunt@oracle.c= om> wrote:
You can also = use a long lived refresh token in combination with a short access token. Th= e client is then forced to periodically reauthenticate (without the user) b= efore getting a new access token.=A0

Refresh also gives the authzn server a chance to revoke= access. Hence it is better to use shorter lived access tokens with long li= ved refresh tokens.=A0

Phil

On 2011-09-07, at 15:27, William Mills <wmills@yahoo-inc.com> wrote:
<= br>
I'll talk to the refresh token question:=A0 they give you a = hook for extensibility and key rotation.=A0 If you want to rotate your encr= yption keys or extend the data carried in the token in any way then you wan= t to be able to cleanly refresh your tokens.=A0 Note that the refresh flow = allows you to issue a new refresh token at the same time.=A0 It also allows= a clean path to convert tokens in a new client if you decide you want SAML= tokens instead of MAC for example.

If you want those things you want to use refresh tokens= .=A0 You can have long lived access tokens too, and just use the refresh to= kens when you want to do something new with the access tokens.

-bill

From: Dave Rochwerger <daver@quizlet.com>
To: oauth@ietf.o= rg
Cc: Quizlet Dev Team <devteam@quizlet.com>
Sent: Wednesday, S= eptember 7, 2011 2:15 PM
Subject: [OAUTH-WG] OAuth2 I= mplementation questions (client secret and refresh tokens)

Hi all,

I have been implementing OAuth2 based on th= e various drafts for our new API. Initially, I implemented everything as pe= r the spec, but due to our particular scenario and restrictions we have in = place, there are some fundamental questions that I am unable to defend.

I am hoping this group could help answer them for me.

Our scenario:
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
* We are implementing an API to allow 3rd party developers to access= users' protected resources via their applications. The applications wi= ll mostly be native phone apps, but some will have web server backends (jav= ascript-only applications are not a concern at the moment).
* We want to provide very long-lived (forever) tokens.
* We = are implementing the "authorization code" flow as that seems best= suited to us (we don't want the=A0implicit=A0flow because end-users wo= uld have to re-authorize every hour).

Our architecture:
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
* We control both the API server and the authorization = server.
* All requests to=A0protected=A0resources (ie: to the API= server) are always done over SSL.
* All requests to the authz server (token and authorize endpoints) are= always done over SSL.
* We enforce that every client must supply= the state parameter (and our guidelines say they must verify the state for= CSRF mitigation).
* We enforce that every client must register a redirect URI.
* We validate the redirect_uri used to request an access token is the same= that was used to obtain the auth code.
* The only time a request= is not made over SSL is the redirect with the auth_code which is very shor= t-lived (30 seconds) and is tied to a verified redirect URI.
* We enforce that access tokens must be provided using the Authorizati= on header only (and of course, over SSL).
* We have guidelines sa= ying that all mobile apps must use the native browser (and not an embedded = web UI).

Questions:
=3D=3D=3D=3D=3D=3D=3D=3D
1. Given the above scenario, what use are refresh tokens?
=A0 - = Access tokens can not leak because every request (to resource and authz ser= ver) containing an access token is done over SSL. We control both the authz= and resource servers, so tokens in logs (and other suggested reasons in th= e archives) are not an issue.
=A0 - Long-lived refresh tokens and short-lived access tokens are supp= osed to provide security due to possible access token leakage... but in our= 100% SSL=A0scenario, if access tokens are able to leak, then so would the = client id, secret and refresh token.
=A0 - Having a long-lived refresh token that can be exchanged for anot= her access token adds a level of complexity (a second HTTPS request every s= o often) and seems to provide no benefit for our case.


2. What is the point of the client secret (in our scena= rio)?=A0
- We origi= nally were treating the clients as=A0confidential, but after re-reading the= native-application section, it seems we really=A0should=A0treat them as pu= blic (phone apps can be decompiled and the secret discovered).

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


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

--0016e6461542b934c304ac62da14-- From daver@quizlet.com Wed Sep 7 17:06: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 77CD921F87C5 for ; Wed, 7 Sep 2011 17:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 R0NQcqEb4pRv for ; Wed, 7 Sep 2011 17:06:57 -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 DAF5B21F8B77 for ; Wed, 7 Sep 2011 17:06:56 -0700 (PDT) Received: by yxj20 with SMTP id 20so196900yxj.31 for ; Wed, 07 Sep 2011 17:08:47 -0700 (PDT) Received: by 10.151.46.19 with SMTP id y19mr129371ybj.124.1315440527182; Wed, 07 Sep 2011 17:08:47 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id m3sm758038ybg.11.2011.09.07.17.08.45 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 17:08:46 -0700 (PDT) Received: by ywe9 with SMTP id 9so191210ywe.31 for ; Wed, 07 Sep 2011 17:08:45 -0700 (PDT) Received: by 10.100.230.11 with SMTP id c11mr10104anh.144.1315440525157; Wed, 07 Sep 2011 17:08:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.164.3 with HTTP; Wed, 7 Sep 2011 17:08:25 -0700 (PDT) X-Originating-IP: [67.169.69.75] In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A4F281D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F281D@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Dave Rochwerger Date: Wed, 7 Sep 2011 17:08:25 -0700 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=00163691febe39a75f04ac62ddab Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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, 08 Sep 2011 00:06:58 -0000 --00163691febe39a75f04ac62ddab Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All our access tokens are currently stateless. All API calls are going to have to make DB/memcache calls to do anything interesting anyway, one extra call to check the access token shouldn't have a drastic effect. At the very least, we need to lookup/confirm the user exists, so we are going to make at least a couple of DB/memcache calls on every API request anyway. We do use caching, so we could potentially cache access tokens just like other data we use. As a (slight) aside, I did have the thought of keeping only refresh tokens in the DB and using a non-persistant caching layer like memcache to hold short-lived access tokens (so, in the event of loosing the cache, clients simply need to refresh and get new access tokens). But even the benefit of this did not outweigh the cost of the extra complication for 3rd party developers to have to implement the extra work of handling refresh tokens and the refresh process. Dave. On Wed, Sep 7, 2011 at 4:23 PM, Eran Hammer-Lahav wrot= e: > You can revoke access tokens but only if they are Stateful (which usually > means a DB lookup for every API call which doesn=92t scale as well).**** > > ** ** > > EHL**** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Phillip Hunt > *Sent:* Wednesday, September 07, 2011 4:24 PM > *To:* William Mills > *Cc:* Quizlet Dev Team; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth2 Implementation questions (client secret > and refresh tokens)**** > > ** ** > > You can also use a long lived refresh token in combination with a short > access token. The client is then forced to periodically reauthenticate > (without the user) before getting a new access token. **** > > ** ** > > Refresh also gives the authzn server a chance to revoke access. Hence it = is > better to use shorter lived access tokens with long lived refresh tokens. > **** > > > Phil**** > > > On 2011-09-07, at 15:27, William Mills wrote:**** > > I'll talk to the refresh token question: they give you a hook for > extensibility and key rotation. If you want to rotate your encryption ke= ys > or extend the data carried in the token in any way then you want to be ab= le > to cleanly refresh your tokens. Note that the refresh flow allows you to > issue a new refresh token at the same time. It also allows a clean path = to > convert tokens in a new client if you decide you want SAML tokens instead= of > MAC for example.**** > > ** ** > > If you want those things you want to use refresh tokens. You can have lo= ng > lived access tokens too, and just use the refresh tokens when you want to= do > something new with the access tokens.**** > > ** ** > > -bill**** > > ** ** > ------------------------------ > > *From:* Dave Rochwerger > *To:* oauth@ietf.org > *Cc:* Quizlet Dev Team > *Sent:* Wednesday, September 7, 2011 2:15 PM > *Subject:* [OAUTH-WG] OAuth2 Implementation questions (client secret and > refresh tokens)**** > > Hi all,**** > > ** ** > > I have been implementing OAuth2 based on the various drafts for our new > API. Initially, I implemented everything as per the spec, but due to our > particular scenario and restrictions we have in place, there are some > fundamental questions that I am unable to defend.**** > > ** ** > > I am hoping this group could help answer them for me.**** > > ** ** > > Our scenario:**** > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * We are implementing an API to allow 3rd party developers to access user= s' > protected resources via their applications. The applications will mostly = be > native phone apps, but some will have web server backends (javascript-onl= y > applications are not a concern at the moment).**** > > * We want to provide very long-lived (forever) tokens.**** > > * We are implementing the "authorization code" flow as that seems best > suited to us (we don't want the implicit flow because end-users would hav= e > to re-authorize every hour).**** > > ** ** > > Our architecture:**** > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D**** > > * We control both the API server and the authorization server.**** > > * All requests to protected resources (ie: to the API server) are always > done over SSL.**** > > * All requests to the authz server (token and authorize endpoints) are > always done over SSL.**** > > * We enforce that every client must supply the state parameter (and our > guidelines say they must verify the state for CSRF mitigation).**** > > * We enforce that every client must register a redirect URI.**** > > * We validate the redirect_uri used to request an access token is the sam= e > that was used to obtain the auth code.**** > > * The only time a request is not made over SSL is the redirect with the > auth_code which is very short-lived (30 seconds) and is tied to a verifie= d > redirect URI.**** > > * We enforce that access tokens must be provided using the Authorization > header only (and of course, over SSL).**** > > * We have guidelines saying that all mobile apps must use the native > browser (and not an embedded web UI).**** > > ** ** > > Questions:**** > > =3D=3D=3D=3D=3D=3D=3D=3D**** > > 1. Given the above scenario, what use are refresh tokens?**** > > - Access tokens can not leak because every request (to resource and aut= hz > server) containing an access token is done over SSL. We control both the > authz and resource servers, so tokens in logs (and other suggested reason= s > in the archives) are not an issue.**** > > - Long-lived refresh tokens and short-lived access tokens are supposed = to > provide security due to possible access token leakage... but in our 100% > SSL scenario, if access tokens are able to leak, then so would the client > id, secret and refresh token.**** > > - Having a long-lived refresh token that can be exchanged for another > access token adds a level of complexity (a second HTTPS request every so > often) and seems to provide no benefit for our case.**** > > ** ** > > ** ** > > 2. What is the point of the client secret (in our scenario)? **** > > - We originally were treating the clients as confidential, but after > re-reading the native-application section, it seems we really should trea= t > them as public (phone apps can be decompiled and the secret discovered).*= * > ** > > - The spec says that the authz server should > authenticate confidential clients, but public clients are allowed to just > send their public client id (and no secret).**** > > - The only verification then, is to enforce redirect URI registration and > to validate the redirect URI between authorization and token steps.**** > > ** ** > > So, the question is, assuming that we, one: "enforce redirect-URI > registration" and two: "validate that URI" - why can't we treat all clien= ts > as public and not worry about a secret?**** > > What is the benefit of having confidential clients (and a secret) at all? > **** > > ** ** > > ** ** > > Our API source is not available, but the oauth2 server implementation can > be seen here: https://github.com/quizlet/oauth2-php**** > > ** ** > > Regards,**** > > Dave**** > > > > _______________________________________________ > 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**** > > --00163691febe39a75f04ac62ddab Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
All our access tokens are currently stateless.

All API calls are going to have to make DB/memcache calls to do anything in= teresting anyway, one extra call to check the access token shouldn't ha= ve a drastic effect.
At the very least, we need to lookup/confirm the u= ser exists, so we are going to make at least a couple of DB/memcache calls = on every API request anyway.

We do use caching, so we could potentially cache access= tokens just like other data we use.


As a (slight) aside,=A0I did have the thought of keeping only refresh tok= ens in the DB and using a non-persistant caching layer like memcache to hol= d short-lived access tokens (so, in the event of loosing the cache, clients= simply need to refresh and get new access tokens). But even the benefit of= this did not outweigh the cost of the extra complication for 3rd party dev= elopers to have to implement the extra work of handling refresh tokens and = the refresh process.

Dave.

On Wed, Sep 7, 2011 at 4:23 PM, Eran Hammer-Lahav = <eran@huenivers= e.com> wrote:

You can revoke access tokens but only if they ar= e Stateful (which usually means a DB lookup for every API call which doesn= =92t scale as well).

=A0

EHL

=A0

From: oauth-bounces@ietf.org [mailto:= oauth-bounces@i= etf.org] On Behalf Of Phillip Hunt
Sent: Wednesday, September 07, 2011 4:24 PM
To: William Mi= lls
Cc: Quizlet Dev Team; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth2 Im= plementation questions (client secret and refresh tokens)

=A0

You can also use a long lived re= fresh token in combination with a short access token. The client is then fo= rced to periodically reauthenticate (without the user) before getting a new= access token.=A0

=A0

Refresh also gives the authzn server a chance to revoke acce= ss. Hence it is better to use shorter lived access tokens with long lived r= efresh tokens.=A0


Phil


On 2011-09-07, at 15:= 27, William Mills <wmills@yahoo-inc.com> wrote:

=

I'll talk to the refresh to= ken question:=A0 they give you a hook for extensibility and key rotation.= =A0 If you want to rotate your encryption keys or extend the data carried i= n the token in any way then you want to be able to cleanly refresh your tok= ens.=A0 Note that the refresh flow allows you to issue a new refresh token = at the same time.=A0 It also allows a clean path to convert tokens in a new= client if you decide you want SAML tokens instead of MAC for example.

=A0<= /p>

If you want those thin= gs you want to use refresh tokens.=A0 You can have long lived access tokens= too, and just use the refresh tokens when you want to do something new wit= h the access tokens.

=A0<= /p>

-bill

=A0<= /p>

F= rom: Dave Rochwerge= r <daver@quizlet.= com>
To: oauth@ietf.o= rg
Cc: Quizlet Dev Team <devteam@quizlet.com>
Sent: Wednesd= ay, September 7, 2011 2:15 PM
Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret a= nd refresh tokens)<= /p>

Hi all,=

=A0

I have been implementing OAu= th2 based on the various drafts for our new API. Initially, I implemented e= verything as per the spec, but due to our particular scenario and restricti= ons we have in place, there are some fundamental questions that I am unable= to defend.

=A0<= /p>

I am hoping this group= could help answer them for me.

=A0<= /p>

Our scenario:

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
* We are implementing an API to allow 3rd party developers to acc= ess users' protected resources via their applications. The applications= will mostly be native phone apps, but some will have web server backends (= javascript-only applications are not a concern at the moment).

* We want to provide very= long-lived (forever) tokens.

* We are im= plementing the "authorization code" flow as that seems best suite= d to us (we don't want the=A0implicit=A0flow because end-users would ha= ve to re-authorize every hour).

=A0<= /p>

Our architecture:

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

* We control both the API server and the authorization server.<= u>

* All requests to=A0prote= cted=A0resources (ie: to the API server) are always done over SSL.

* All requests to the aut= hz server (token and authorize endpoints) are always done over SSL.<= u>

* We enforce that every c= lient must supply the state parameter (and our guidelines say they must ver= ify the state for CSRF mitigation).

* We enforce that every c= lient must register a redirect URI.

* We valida= te the redirect_uri used to request an access token is the same that was us= ed to obtain the auth code.

* The only = time a request is not made over SSL is the redirect with the auth_code whic= h is very short-lived (30 seconds) and is tied to a verified redirect URI.<= u>

* We enforce that access = tokens must be provided using the Authorization header only (and of course,= over SSL).

* We have guidelines sayi= ng that all mobile apps must use the native browser (and not an embedded we= b UI).

=A0<= /p>

Questions:

=3D=3D=3D=3D=3D=3D=3D=3D<= u>

1= . Given the above scenario, what use are refresh tokens?

=A0 - Access tokens can n= ot leak because every request (to resource and authz server) containing an = access token is done over SSL. We control both the authz and resource serve= rs, so tokens in logs (and other suggested reasons in the archives) are not= an issue.

=A0 - Long-lived refresh = tokens and short-lived access tokens are supposed to provide security due t= o possible access token leakage... but in our 100% SSL=A0scenario, if acces= s tokens are able to leak, then so would the client id, secret and refresh = token.

=A0 - Having a long-lived= refresh token that can be exchanged for another access token adds a level = of complexity (a second HTTPS request every so often) and seems to provide = no benefit for our case.

=A0<= /p>

=A0

2. What is the point of t= he client secret (in our scenario)?=A0

- We origin= ally were treating the clients as=A0confidential, but after re-reading the = native-application section, it seems we really=A0should=A0treat them as pub= lic (phone apps can be decompiled and the secret discovered).

- The spec says that the a= uthz server should authenticate=A0confidential=A0clients, but public client= s are allowed to just send their public client id (and no secret).

- The only verification t= hen, is to enforce redirect URI registration and to validate the redirect U= RI between authorization and token steps.

=A0<= /p>

So, the question is, assumi= ng that we, one: "enforce redirect-URI registration" and two: &qu= ot;validate that URI" - why can't we treat all clients as public a= nd not worry about a secret?

What is the benefit of ha= ving=A0confidential=A0clients (and a secret) at all?=A0

=A0

=A0

Our API source is not ava= ilable, but the oauth2 server implementation can be seen here:=A0https://github.co= m/quizlet/oauth2-php

=A0<= /p>

Regards,=

Dave=



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

_______________________________________________
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


--00163691febe39a75f04ac62ddab-- From phil.hunt@oracle.com Wed Sep 7 17:07: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 50AFC21F8D2D for ; Wed, 7 Sep 2011 17:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=1.395, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hapkI72u-iiM for ; Wed, 7 Sep 2011 17:07:17 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id CFB3721F8D21 for ; Wed, 7 Sep 2011 17:07:13 -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 p88091rB003930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 00:09:03 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 p8808xnp011441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 00:09:00 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8808sIR014551; Wed, 7 Sep 2011 19:08:54 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 17:08:53 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-20--21596376 From: Phil Hunt In-Reply-To: Date: Wed, 7 Sep 2011 17:08:56 -0700 Message-Id: <59CDCC16-44BA-4626-B744-F1169A13A542@oracle.com> References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> To: Dave Rochwerger X-Mailer: Apple Mail (2.1084) X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090205.4E6807A0.0060,ss=1,re=-2.300,fgs=0 Cc: Quizlet Dev Team , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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, 08 Sep 2011 00:07:19 -0000 --Apple-Mail-20--21596376 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii See below... Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: > Hi Phil, >=20 > >> The client is then forced to periodically reauthenticate (without = the user) before getting a new access token.=20 > What benefit does that have? The user does not have to be present. =20 >=20 > >> Refresh also gives the authzn server a chance to revoke access. = Hence it is better to use shorter lived access tokens with long lived = refresh tokens.=20 > That doesn't follow - we can just as easily revoke the single = long-lived access token. As Eran points out, you'd have to have do a DB lookup to have true = revocation. But, by having a short expiration time on the access token = (say 1 hour or less), you get quasi-revocation which has to be = re-validated after the access token expires and the client has to = re-authenticate and provide a valid refresh token. In this sense you = get the best of a long-lived credential, combined with good key rotation = and authorization re-verification without having to re-involve the = end-user. >=20 > Dave. >=20 > On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt = wrote: > You can also use a long lived refresh token in combination with a = short access token. The client is then forced to periodically = reauthenticate (without the user) before getting a new access token.=20 >=20 > Refresh also gives the authzn server a chance to revoke access. Hence = it is better to use shorter lived access tokens with long lived refresh = tokens.=20 >=20 > Phil >=20 > On 2011-09-07, at 15:27, William Mills wrote: >=20 >> I'll talk to the refresh token question: they give you a hook for = extensibility and key rotation. If you want to rotate your encryption = keys or extend the data carried in the token in any way then you want to = be able to cleanly refresh your tokens. Note that the refresh flow = allows you to issue a new refresh token at the same time. It also = allows a clean path to convert tokens in a new client if you decide you = want SAML tokens instead of MAC for example. >>=20 >> If you want those things you want to use refresh tokens. You can = have long lived access tokens too, and just use the refresh tokens when = you want to do something new with the access tokens. >>=20 >> -bill >>=20 >> From: Dave Rochwerger >> To: oauth@ietf.org >> Cc: Quizlet Dev Team >> Sent: Wednesday, September 7, 2011 2:15 PM >> Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret = and refresh tokens) >>=20 >> Hi all, >>=20 >> I have been implementing OAuth2 based on the various drafts for our = new API. Initially, I implemented everything as per the spec, but due to = our particular scenario and restrictions we have in place, there are = some fundamental questions that I am unable to defend. >>=20 >> I am hoping this group could help answer them for me. >>=20 >> Our scenario: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> * We are implementing an API to allow 3rd party developers to access = users' protected resources via their applications. The applications will = mostly be native phone apps, but some will have web server backends = (javascript-only applications are not a concern at the moment). >> * We want to provide very long-lived (forever) tokens. >> * We are implementing the "authorization code" flow as that seems = best suited to us (we don't want the implicit flow because end-users = would have to re-authorize every hour). >>=20 >> Our architecture: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> * We control both the API server and the authorization server. >> * All requests to protected resources (ie: to the API server) are = always done over SSL. >> * All requests to the authz server (token and authorize endpoints) = are always done over SSL. >> * We enforce that every client must supply the state parameter (and = our guidelines say they must verify the state for CSRF mitigation). >> * We enforce that every client must register a redirect URI. >> * We validate the redirect_uri used to request an access token is the = same that was used to obtain the auth code. >> * The only time a request is not made over SSL is the redirect with = the auth_code which is very short-lived (30 seconds) and is tied to a = verified redirect URI. >> * We enforce that access tokens must be provided using the = Authorization header only (and of course, over SSL). >> * We have guidelines saying that all mobile apps must use the native = browser (and not an embedded web UI). >>=20 >> Questions: >> =3D=3D=3D=3D=3D=3D=3D=3D >> 1. Given the above scenario, what use are refresh tokens? >> - Access tokens can not leak because every request (to resource and = authz server) containing an access token is done over SSL. We control = both the authz and resource servers, so tokens in logs (and other = suggested reasons in the archives) are not an issue. >> - Long-lived refresh tokens and short-lived access tokens are = supposed to provide security due to possible access token leakage... but = in our 100% SSL scenario, if access tokens are able to leak, then so = would the client id, secret and refresh token. >> - Having a long-lived refresh token that can be exchanged for = another access token adds a level of complexity (a second HTTPS request = every so often) and seems to provide no benefit for our case. >>=20 >>=20 >> 2. What is the point of the client secret (in our scenario)?=20 >> - We originally were treating the clients as confidential, but after = re-reading the native-application section, it seems we really should = treat them as public (phone apps can be decompiled and the secret = discovered). >> - The spec says that the authz server should authenticate = confidential clients, but public clients are allowed to just send their = public client id (and no secret). >> - The only verification then, is to enforce redirect URI registration = and to validate the redirect URI between authorization and token steps. >>=20 >> So, the question is, assuming that we, one: "enforce redirect-URI = registration" and two: "validate that URI" - why can't we treat all = clients as public and not worry about a secret? >> What is the benefit of having confidential clients (and a secret) at = all?=20 >>=20 >>=20 >> Our API source is not available, but the oauth2 server implementation = can be seen here: https://github.com/quizlet/oauth2-php >>=20 >> Regards, >> Dave >>=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 --Apple-Mail-20--21596376 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii See = below...
Phil

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





On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote:

Hi = Phil,

>> The client is then forced to = periodically reauthenticate (without the user) before getting a new = access token. 
What benefit does that = have?

The user does not have to be = present.  

>> Refresh also gives the = authzn server a chance to revoke access. Hence it is better to use = shorter lived access tokens with long lived refresh tokens. 
That doesn't follow - we can just as easily revoke the single = long-lived access token.

As Eran points = out, you'd have to have do a DB lookup to have true revocation. But, by = having a short expiration time on the access token (say 1 hour or less), = you get quasi-revocation which has to be re-validated after the access = token expires and the client has to re-authenticate and provide a valid = refresh token.  In this sense you get the best of a long-lived = credential, combined with good key rotation and authorization = re-verification without having to re-involve the = end-user.


Dave.

On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt <phil.hunt@oracle.com> = wrote:
You can also use a long lived refresh token in = combination with a short access token. The client is then forced to = periodically reauthenticate (without the user) before getting a new = access token. 

Refresh also gives the authzn server a chance to = revoke access. Hence it is better to use shorter lived access tokens = with long lived refresh = tokens. 

Phil

On 2011-09-07, at 15:27, William Mills <wmills@yahoo-inc.com> = wrote:

I'll talk to the refresh token question:  they give you = a hook for extensibility and key rotation.  If you want to rotate = your encryption keys or extend the data carried in the token in any way = then you want to be able to cleanly refresh your tokens.  Note that = the refresh flow allows you to issue a new refresh token at the same = time.  It also allows a clean path to convert tokens in a new = client if you decide you want SAML tokens instead of MAC for = example.

If you want those things you want to use refresh = tokens.  You can have long lived access tokens too, and just use = the refresh tokens when you want to do something new with the access = tokens.

-bill

From: Dave Rochwerger <daver@quizlet.com>
To: oauth@ietf.org
Cc: Quizlet Dev Team = <devteam@quizlet.com>
Sent: Wednesday, September 7, 2011 = 2:15 PM
Subject: [OAUTH-WG] = OAuth2 Implementation questions (client secret and refresh tokens)

Hi = all,

I have been implementing OAuth2 based on the = various drafts for our new API. Initially, I implemented everything as = per the spec, but due to our particular scenario and restrictions we = have in place, there are some fundamental questions that I am unable to = defend.

I am hoping this group could help answer them for = me.

Our scenario:
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
* We are implementing an API to allow 3rd party developers = to access users' protected resources via their applications. The = applications will mostly be native phone apps, but some will have web = server backends (javascript-only applications are not a concern at the = moment).
* We want to provide very long-lived (forever) tokens.
* = We are implementing the "authorization code" flow as that seems best = suited to us (we don't want the implicit flow because = end-users would have to re-authorize every hour).

Our architecture:
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
* We control both the API server and the = authorization server.
* All requests = to protected resources (ie: to the API server) are always done = over SSL.
* All requests to the authz server (token and authorize endpoints) = are always done over SSL.
* We enforce that every client must = supply the state parameter (and our guidelines say they must verify the = state for CSRF mitigation).
* We enforce that every client must register a redirect = URI.
* We validate the redirect_uri used to request an access = token is the same that was used to obtain the auth code.
* The = only time a request is not made over SSL is the redirect with the = auth_code which is very short-lived (30 seconds) and is tied to a = verified redirect URI.
* We enforce that access tokens must be provided using the = Authorization header only (and of course, over SSL).
* We have = guidelines saying that all mobile apps must use the native browser (and = not an embedded web UI).

Questions:
=3D=3D=3D=3D=3D=3D=3D=3D
1. Given the above scenario, what use are refresh = tokens?
  - Access tokens can not leak because every = request (to resource and authz server) containing an access token is = done over SSL. We control both the authz and resource servers, so tokens = in logs (and other suggested reasons in the archives) are not an = issue.
  - Long-lived refresh tokens and short-lived access tokens = are supposed to provide security due to possible access token leakage... = but in our 100% SSL scenario, if access tokens are able to leak, = then so would the client id, secret and refresh token.
  - Having a long-lived refresh token that can be exchanged = for another access token adds a level of complexity (a second HTTPS = request every so often) and seems to provide no benefit for our = case.


2. What is the point of the client secret (in our = scenario)? 
- We = originally were treating the clients as confidential, but after = re-reading the native-application section, it seems we = really should treat them as public (phone apps can be = decompiled and the secret discovered).
- = The spec says that the authz server should = authenticate confidential clients, but public clients are = allowed to just send their public client id (and no secret).
- The only verification then, is to enforce redirect URI = registration and to validate the redirect URI between authorization and = token steps.

So, the question is, assuming that we, one: = "enforce redirect-URI registration" and two: "validate that URI" - why = can't we treat all clients as public and not worry about a = secret?
What is = the benefit of having confidential clients (and a secret) at = all? 


Our API source is not available, but the = oauth2 server implementation can be seen here: https://github.com/quizlet/oauth2-php

Regards,
Dave


_______________________________________________
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-20--21596376-- From daver@oldschoolindustriesllc.com Wed Sep 7 17: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 6889021F8A7A for ; Wed, 7 Sep 2011 17:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Ysf8C0T0UmVO for ; Wed, 7 Sep 2011 17:03:49 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id B421721F87FC for ; Wed, 7 Sep 2011 17:03:48 -0700 (PDT) Received: by gwb17 with SMTP id 17so288011gwb.15 for ; Wed, 07 Sep 2011 17:05:39 -0700 (PDT) Received: by 10.100.151.9 with SMTP id y9mr27607and.56.1315440339129; Wed, 07 Sep 2011 17:05:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.164.3 with HTTP; Wed, 7 Sep 2011 17:05:19 -0700 (PDT) X-Originating-IP: [67.169.69.75] In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A4F281D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F281D@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Dave Rochwerger Date: Wed, 7 Sep 2011 17:05:19 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e646154223156b04ac62d224 X-Mailman-Approved-At: Wed, 07 Sep 2011 17:12:11 -0700 Cc: "oauth@ietf.org" , Quizlet Dev Team Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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, 08 Sep 2011 00:07:34 -0000 --0016e646154223156b04ac62d224 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All our access tokens are currently stateless. All API calls are going to have to make DB/memcache calls to do anything interesting anyway, one extra call to check the access token shouldn't have a drastic effect. At the very least, we need to lookup/confirm the user exists, so we are going to make at least a couple of DB/memcache calls on every API request anyway. We do use caching, so we could potentially cache access tokens just like other data we use. As a (slight) aside, I did have the thought of keeping only refresh tokens in the DB and using a non-persistant caching layer like memcache to hold short-lived access tokens (so, in the event of loosing the cache, clients simply need to refresh and get new access tokens). But even the benefit of this did not outweigh the cost of the extra complication for 3rd party developers to have to implement the extra work of handling refresh tokens and the refresh process. Dave. On Wed, Sep 7, 2011 at 4:23 PM, Eran Hammer-Lahav wrot= e: > You can revoke access tokens but only if they are Stateful (which usually > means a DB lookup for every API call which doesn=92t scale as well).**** > > ** ** > > EHL**** > > ** ** > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Phillip Hunt > *Sent:* Wednesday, September 07, 2011 4:24 PM > *To:* William Mills > *Cc:* Quizlet Dev Team; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth2 Implementation questions (client secret > and refresh tokens)**** > > ** ** > > You can also use a long lived refresh token in combination with a short > access token. The client is then forced to periodically reauthenticate > (without the user) before getting a new access token. **** > > ** ** > > Refresh also gives the authzn server a chance to revoke access. Hence it = is > better to use shorter lived access tokens with long lived refresh tokens. > **** > > > Phil**** > > > On 2011-09-07, at 15:27, William Mills wrote:**** > > I'll talk to the refresh token question: they give you a hook for > extensibility and key rotation. If you want to rotate your encryption ke= ys > or extend the data carried in the token in any way then you want to be ab= le > to cleanly refresh your tokens. Note that the refresh flow allows you to > issue a new refresh token at the same time. It also allows a clean path = to > convert tokens in a new client if you decide you want SAML tokens instead= of > MAC for example.**** > > ** ** > > If you want those things you want to use refresh tokens. You can have lo= ng > lived access tokens too, and just use the refresh tokens when you want to= do > something new with the access tokens.**** > > ** ** > > -bill**** > > ** ** > ------------------------------ > > *From:* Dave Rochwerger > *To:* oauth@ietf.org > *Cc:* Quizlet Dev Team > *Sent:* Wednesday, September 7, 2011 2:15 PM > *Subject:* [OAUTH-WG] OAuth2 Implementation questions (client secret and > refresh tokens)**** > > Hi all,**** > > ** ** > > I have been implementing OAuth2 based on the various drafts for our new > API. Initially, I implemented everything as per the spec, but due to our > particular scenario and restrictions we have in place, there are some > fundamental questions that I am unable to defend.**** > > ** ** > > I am hoping this group could help answer them for me.**** > > ** ** > > Our scenario:**** > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * We are implementing an API to allow 3rd party developers to access user= s' > protected resources via their applications. The applications will mostly = be > native phone apps, but some will have web server backends (javascript-onl= y > applications are not a concern at the moment).**** > > * We want to provide very long-lived (forever) tokens.**** > > * We are implementing the "authorization code" flow as that seems best > suited to us (we don't want the implicit flow because end-users would hav= e > to re-authorize every hour).**** > > ** ** > > Our architecture:**** > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D**** > > * We control both the API server and the authorization server.**** > > * All requests to protected resources (ie: to the API server) are always > done over SSL.**** > > * All requests to the authz server (token and authorize endpoints) are > always done over SSL.**** > > * We enforce that every client must supply the state parameter (and our > guidelines say they must verify the state for CSRF mitigation).**** > > * We enforce that every client must register a redirect URI.**** > > * We validate the redirect_uri used to request an access token is the sam= e > that was used to obtain the auth code.**** > > * The only time a request is not made over SSL is the redirect with the > auth_code which is very short-lived (30 seconds) and is tied to a verifie= d > redirect URI.**** > > * We enforce that access tokens must be provided using the Authorization > header only (and of course, over SSL).**** > > * We have guidelines saying that all mobile apps must use the native > browser (and not an embedded web UI).**** > > ** ** > > Questions:**** > > =3D=3D=3D=3D=3D=3D=3D=3D**** > > 1. Given the above scenario, what use are refresh tokens?**** > > - Access tokens can not leak because every request (to resource and aut= hz > server) containing an access token is done over SSL. We control both the > authz and resource servers, so tokens in logs (and other suggested reason= s > in the archives) are not an issue.**** > > - Long-lived refresh tokens and short-lived access tokens are supposed = to > provide security due to possible access token leakage... but in our 100% > SSL scenario, if access tokens are able to leak, then so would the client > id, secret and refresh token.**** > > - Having a long-lived refresh token that can be exchanged for another > access token adds a level of complexity (a second HTTPS request every so > often) and seems to provide no benefit for our case.**** > > ** ** > > ** ** > > 2. What is the point of the client secret (in our scenario)? **** > > - We originally were treating the clients as confidential, but after > re-reading the native-application section, it seems we really should trea= t > them as public (phone apps can be decompiled and the secret discovered).*= * > ** > > - The spec says that the authz server should > authenticate confidential clients, but public clients are allowed to just > send their public client id (and no secret).**** > > - The only verification then, is to enforce redirect URI registration and > to validate the redirect URI between authorization and token steps.**** > > ** ** > > So, the question is, assuming that we, one: "enforce redirect-URI > registration" and two: "validate that URI" - why can't we treat all clien= ts > as public and not worry about a secret?**** > > What is the benefit of having confidential clients (and a secret) at all? > **** > > ** ** > > ** ** > > Our API source is not available, but the oauth2 server implementation can > be seen here: https://github.com/quizlet/oauth2-php**** > > ** ** > > Regards,**** > > Dave**** > > > > _______________________________________________ > 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**** > > --0016e646154223156b04ac62d224 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
All our access tokens are currently stateless.

All= API calls are going to have to make DB/memcache calls to do anything inter= esting anyway, one extra call to check the access token shouldn't have = a drastic effect.
At the very least, we need to lookup/confirm the user exists, so we are goi= ng to make at least a couple of DB/memcache calls on every API request anyw= ay.

We do use caching, so we could potentially cac= he access tokens just like other data we use.


As a (slight) aside,=A0I did have the th= ought of keeping only refresh tokens in the DB and using a non-persistant c= aching layer like memcache to hold short-lived access tokens (so, in the ev= ent of loosing the cache, clients simply need to refresh and get new access= tokens). But even the benefit of this did not outweigh the cost of the ext= ra complication for 3rd party developers to have to implement the extra wor= k of handling refresh tokens and the refresh process.

Dave.


On Wed, Sep 7, 2011 at 4:23 PM, Eran Hammer-Lahav = <eran@hueniverse.com> wrote:

You can revoke access tokens but only if they ar= e Stateful (which usually means a DB lookup for every API call which doesn= =92t scale as well).

=A0

EHL

=A0

From: oauth-bounces@ietf.org [mailto:= oauth-bounces@i= etf.org] On Behalf Of Phillip Hunt
Sent: Wednesday, September 07, 2011 4:24 PM
To: William Mi= lls
Cc: Quizlet Dev Team; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth2 Im= plementation questions (client secret and refresh tokens)

=A0

You can also use a long lived re= fresh token in combination with a short access token. The client is then fo= rced to periodically reauthenticate (without the user) before getting a new= access token.=A0

=A0

Refresh also gives the authzn server a chance to revoke acce= ss. Hence it is better to use shorter lived access tokens with long lived r= efresh tokens.=A0


Phil


On 2011-09-07, at 15:= 27, William Mills <wmills@yahoo-inc.com> wrote:

=

I'll talk to the refresh to= ken question:=A0 they give you a hook for extensibility and key rotation.= =A0 If you want to rotate your encryption keys or extend the data carried i= n the token in any way then you want to be able to cleanly refresh your tok= ens.=A0 Note that the refresh flow allows you to issue a new refresh token = at the same time.=A0 It also allows a clean path to convert tokens in a new= client if you decide you want SAML tokens instead of MAC for example.

=A0<= /p>

If you want those thin= gs you want to use refresh tokens.=A0 You can have long lived access tokens= too, and just use the refresh tokens when you want to do something new wit= h the access tokens.

=A0<= /p>

-bill

=A0<= /p>

F= rom: Dave Rochwerge= r <daver@quizlet.= com>
To: oauth@ietf.o= rg
Cc: Quizlet Dev Team <devteam@quizlet.com>
Sent: Wednesd= ay, September 7, 2011 2:15 PM
Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret a= nd refresh tokens)<= /p>

Hi all,=

=A0

I have been implementing OAu= th2 based on the various drafts for our new API. Initially, I implemented e= verything as per the spec, but due to our particular scenario and restricti= ons we have in place, there are some fundamental questions that I am unable= to defend.

=A0<= /p>

I am hoping this group= could help answer them for me.

=A0<= /p>

Our scenario:

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
* We are implementing an API to allow 3rd party developers to acc= ess users' protected resources via their applications. The applications= will mostly be native phone apps, but some will have web server backends (= javascript-only applications are not a concern at the moment).

* We want to provide very= long-lived (forever) tokens.

* We are im= plementing the "authorization code" flow as that seems best suite= d to us (we don't want the=A0implicit=A0flow because end-users would ha= ve to re-authorize every hour).

=A0<= /p>

Our architecture:

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

* We control both the API server and the authorization server.<= u>

* All requests to=A0prote= cted=A0resources (ie: to the API server) are always done over SSL.

* All requests to the aut= hz server (token and authorize endpoints) are always done over SSL.<= u>

* We enforce that every c= lient must supply the state parameter (and our guidelines say they must ver= ify the state for CSRF mitigation).

* We enforce that every c= lient must register a redirect URI.

* We valida= te the redirect_uri used to request an access token is the same that was us= ed to obtain the auth code.

* The only = time a request is not made over SSL is the redirect with the auth_code whic= h is very short-lived (30 seconds) and is tied to a verified redirect URI.<= u>

* We enforce that access = tokens must be provided using the Authorization header only (and of course,= over SSL).

* We have guidelines sayi= ng that all mobile apps must use the native browser (and not an embedded we= b UI).

=A0<= /p>

Questions:

=3D=3D=3D=3D=3D=3D=3D=3D<= u>

1= . Given the above scenario, what use are refresh tokens?

=A0 - Access tokens can n= ot leak because every request (to resource and authz server) containing an = access token is done over SSL. We control both the authz and resource serve= rs, so tokens in logs (and other suggested reasons in the archives) are not= an issue.

=A0 - Long-lived refresh = tokens and short-lived access tokens are supposed to provide security due t= o possible access token leakage... but in our 100% SSL=A0scenario, if acces= s tokens are able to leak, then so would the client id, secret and refresh = token.

=A0 - Having a long-lived= refresh token that can be exchanged for another access token adds a level = of complexity (a second HTTPS request every so often) and seems to provide = no benefit for our case.

=A0<= /p>

=A0

2. What is the point of t= he client secret (in our scenario)?=A0

- We origin= ally were treating the clients as=A0confidential, but after re-reading the = native-application section, it seems we really=A0should=A0treat them as pub= lic (phone apps can be decompiled and the secret discovered).

- The spec says that the a= uthz server should authenticate=A0confidential=A0clients, but public client= s are allowed to just send their public client id (and no secret).

- The only verification t= hen, is to enforce redirect URI registration and to validate the redirect U= RI between authorization and token steps.

=A0<= /p>

So, the question is, assumi= ng that we, one: "enforce redirect-URI registration" and two: &qu= ot;validate that URI" - why can't we treat all clients as public a= nd not worry about a secret?

What is the benefit of ha= ving=A0confidential=A0clients (and a secret) at all?=A0

=A0

=A0

Our API source is not ava= ilable, but the oauth2 server implementation can be seen here:=A0https://github.co= m/quizlet/oauth2-php

=A0<= /p>

Regards,=

Dave=



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

_______________________________________________
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


--0016e646154223156b04ac62d224-- From ben@niven-jenkins.co.uk Wed Sep 7 17:17: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 EDF5021F8D87 for ; Wed, 7 Sep 2011 17:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 3zkGqEuC4SGe for ; Wed, 7 Sep 2011 17:17:17 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id E739521F8CB3 for ; Wed, 7 Sep 2011 17:17:16 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1R1SKg-0000nK-BC; Thu, 08 Sep 2011 01:19:06 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <4E67D149.8080200@mtcc.com> Date: Thu, 8 Sep 2011 01:19:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E665B25.6090709@mtcc.com> <4E6667D1.3080404@mtcc.com> <1315334677.26387.YahooMailNeo@web31809.mail.mud.yahoo.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> <4E67C6C9.1070704@stpete! r.im> <4E67C893.5060505@mtcc.com> <4E67D149.8080200@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] problem statement 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, 08 Sep 2011 00:17:19 -0000 Mike, On 7 Sep 2011, at 21:17, Michael Thomas wrote: > On 09/07/2011 12:56 PM, Kristoph wrote: >> Mike, >>=20 >> I am an implementer of this specification. I am struggling to = understand what it is you are trying to communicate. >>=20 >> The only thing I can discern is that you believe there is a large = cadre of software architects / developers who you think have the skill = to read and understand this specification, design and implement an OAuth = 2.0 server, and yet not understand that a rogue embedded UA would = compromise the end users credentials. Is that basically your concern? >> =20 >=20 > I think that the fine point of a rogue embedded UA will be lost on > people, yes. Especially those who are specing out the higher level > authentication service deployment. I've been observing this thread as well as the OAuth mailing list = without participating for some time and I think what you write above = gets to the heart of the matter. I have some sympathy for the issue you are trying to raise but it is a = common issue across many security protocols and the document to discuss = it in is not the protocol specification which (IME in IETF) is typically = focussed on how to implement (inter-operably) the protocol itself, not = on best practices for deploying an implementation of the protocol. IMO articulating the concerns you have are best placed either in the = "threats" document (which I will admit I have not read) or a separate = informational document (or possibly a BCP if there is sufficient = deployment experience). Your original e-mail that started this thread was not targeted at a = specific document and my interpretation is that some of the hostility = you have experienced is due to a frustration that your request is seen = as a potential obstacle to getting the protocol specification out the = door because the issue you want to discuss is not directly related to = how a developer might implement the protocol. If I may be so bold, could I suggest that you propose some text that = articulates the issue that you would like to see documented and then the = group can assess that text on its merits and try to reach consensus on = which document, if any, it is best placed to reside within. At the risk of offending you or others, I would suggest that if you're = not willing to propose text for whatever reason then I'd suggest we put = an end to this thread as it is reminding me of this Dilbert cartoon: = http://www.dilbert.com/2010-12-22/ Regards Ben From daver@quizlet.com Wed Sep 7 17:20: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 6DA5321F8DA1 for ; Wed, 7 Sep 2011 17:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Ztw3GvlAql1b for ; Wed, 7 Sep 2011 17:20:49 -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 C3E7321F8DB4 for ; Wed, 7 Sep 2011 17:20:45 -0700 (PDT) Received: by yie12 with SMTP id 12so206757yie.31 for ; Wed, 07 Sep 2011 17:22:36 -0700 (PDT) Received: by 10.91.47.30 with SMTP id z30mr38210agj.58.1315441356024; Wed, 07 Sep 2011 17:22:36 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by mx.google.com with ESMTPS id o39sm2913073ani.17.2011.09.07.17.22.34 (version=SSLv3 cipher=OTHER); Wed, 07 Sep 2011 17:22:35 -0700 (PDT) Received: by gxk9 with SMTP id 9so447950gxk.40 for ; Wed, 07 Sep 2011 17:22:34 -0700 (PDT) Received: by 10.101.176.12 with SMTP id d12mr26842anp.100.1315441354142; Wed, 07 Sep 2011 17:22:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.164.3 with HTTP; Wed, 7 Sep 2011 17:22:14 -0700 (PDT) X-Originating-IP: [67.169.69.75] In-Reply-To: <59CDCC16-44BA-4626-B744-F1169A13A542@oracle.com> References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> <59CDCC16-44BA-4626-B744-F1169A13A542@oracle.com> From: Dave Rochwerger Date: Wed, 7 Sep 2011 17:22:14 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001636c9274ba2f23c04ac630e0d Cc: Quizlet Dev Team , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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, 08 Sep 2011 00:20:50 -0000 --001636c9274ba2f23c04ac630e0d Content-Type: text/plain; charset=ISO-8859-1 1. "The user does not have to be present." Maybe I should be more clear. What benefit does that have over just a long-lived (forever) access token? The cost is the extra complication for 3rd party developers to have to worry about refresh tokens. I can not see a benefit in our model (everything over SSL, etc) to use refresh tokens. I want to use refresh tokens - but only if there is a reason for them, which I can not see at the moment. 2. "As Eran points out, you'd have to have do a DB lookup to have true revocation." The act of revoking tokens is not a common occurrence, DB lookups to revoke tokens is not a concern as there is more time spent by the user navigating the UI (or network latency, etc) than the cost of the DB call. 3. "In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user." That all sounds good, but in our situation (all SSL, etc) - what do we want key rotation and re-verification for? I fail to see a reasonable vector for access token leakage to warrant any of this in our case. On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: > See below... > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: > > Hi Phil, > > >> The client is then forced to periodically reauthenticate (without the > user) before getting a new access token. > What benefit does that have? > > > The user does not have to be present. > > > >> Refresh also gives the authzn server a chance to revoke access. Hence it > is better to use shorter lived access tokens with long lived refresh > tokens. > That doesn't follow - we can just as easily revoke the single long-lived > access token. > > > As Eran points out, you'd have to have do a DB lookup to have true > revocation. But, by having a short expiration time on the access token (say > 1 hour or less), you get quasi-revocation which has to be re-validated after > the access token expires and the client has to re-authenticate and provide a > valid refresh token. In this sense you get the best of a long-lived > credential, combined with good key rotation and authorization > re-verification without having to re-involve the end-user. > > > Dave. > > On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: > >> You can also use a long lived refresh token in combination with a short >> access token. The client is then forced to periodically reauthenticate >> (without the user) before getting a new access token. >> >> Refresh also gives the authzn server a chance to revoke access. Hence it >> is better to use shorter lived access tokens with long lived refresh >> tokens. >> >> Phil >> >> On 2011-09-07, at 15:27, William Mills wrote: >> >> I'll talk to the refresh token question: they give you a hook for >> extensibility and key rotation. If you want to rotate your encryption keys >> or extend the data carried in the token in any way then you want to be able >> to cleanly refresh your tokens. Note that the refresh flow allows you to >> issue a new refresh token at the same time. It also allows a clean path to >> convert tokens in a new client if you decide you want SAML tokens instead of >> MAC for example. >> >> If you want those things you want to use refresh tokens. You can have >> long lived access tokens too, and just use the refresh tokens when you want >> to do something new with the access tokens. >> >> -bill >> >> ------------------------------ >> *From:* Dave Rochwerger >> *To:* oauth@ietf.org >> *Cc:* Quizlet Dev Team >> *Sent:* Wednesday, September 7, 2011 2:15 PM >> *Subject:* [OAUTH-WG] OAuth2 Implementation questions (client secret and >> refresh tokens) >> >> Hi all, >> >> I have been implementing OAuth2 based on the various drafts for our new >> API. Initially, I implemented everything as per the spec, but due to our >> particular scenario and restrictions we have in place, there are some >> fundamental questions that I am unable to defend. >> >> I am hoping this group could help answer them for me. >> >> Our scenario: >> ========== >> * We are implementing an API to allow 3rd party developers to access >> users' protected resources via their applications. The applications will >> mostly be native phone apps, but some will have web server backends >> (javascript-only applications are not a concern at the moment). >> * We want to provide very long-lived (forever) tokens. >> * We are implementing the "authorization code" flow as that seems best >> suited to us (we don't want the implicit flow because end-users would have >> to re-authorize every hour). >> >> Our architecture: >> ============ >> * We control both the API server and the authorization server. >> * All requests to protected resources (ie: to the API server) are always >> done over SSL. >> * All requests to the authz server (token and authorize endpoints) are >> always done over SSL. >> * We enforce that every client must supply the state parameter (and our >> guidelines say they must verify the state for CSRF mitigation). >> * We enforce that every client must register a redirect URI. >> * We validate the redirect_uri used to request an access token is the same >> that was used to obtain the auth code. >> * The only time a request is not made over SSL is the redirect with the >> auth_code which is very short-lived (30 seconds) and is tied to a verified >> redirect URI. >> * We enforce that access tokens must be provided using the Authorization >> header only (and of course, over SSL). >> * We have guidelines saying that all mobile apps must use the native >> browser (and not an embedded web UI). >> >> Questions: >> ======== >> 1. Given the above scenario, what use are refresh tokens? >> - Access tokens can not leak because every request (to resource and >> authz server) containing an access token is done over SSL. We control both >> the authz and resource servers, so tokens in logs (and other suggested >> reasons in the archives) are not an issue. >> - Long-lived refresh tokens and short-lived access tokens are supposed >> to provide security due to possible access token leakage... but in our 100% >> SSL scenario, if access tokens are able to leak, then so would the client >> id, secret and refresh token. >> - Having a long-lived refresh token that can be exchanged for another >> access token adds a level of complexity (a second HTTPS request every so >> often) and seems to provide no benefit for our case. >> >> >> 2. What is the point of the client secret (in our scenario)? >> - We originally were treating the clients as confidential, but after >> re-reading the native-application section, it seems we really should treat >> them as public (phone apps can be decompiled and the secret discovered). >> - The spec says that the authz server should >> authenticate confidential clients, but public clients are allowed to just >> send their public client id (and no secret). >> - The only verification then, is to enforce redirect URI registration and >> to validate the redirect URI between authorization and token steps. >> >> So, the question is, assuming that we, one: "enforce redirect-URI >> registration" and two: "validate that URI" - why can't we treat all clients >> as public and not worry about a secret? >> What is the benefit of having confidential clients (and a secret) at all? >> >> >> Our API source is not available, but the oauth2 server implementation can >> be seen here: >> https://github.com/quizlet/oauth2-php >> >> Regards, >> Dave >> >> >> _______________________________________________ >> 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 >> >> > > --001636c9274ba2f23c04ac630e0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1. "The user does not have to be present."
<= div>Maybe I should be more clear. What benefit does that have over just a l= ong-lived (forever) access token? The cost is the extra complication for 3r= d party developers to have to worry about refresh tokens. I can not see a b= enefit in our model (everything over SSL, etc) to use refresh tokens.
I want to use refresh tokens - but only if there is a reason for them,= which I can not see at the moment.

2. "As Er= an points out, you'd have to have do a DB lookup to have true revocatio= n."
The act of revoking tokens is not a common occurrence, DB lookups to r= evoke tokens is not a concern as there is more time spent by the user navig= ating the UI (or network latency, etc) than the cost of the DB call.=A0

3. "In this sense you get the best of a long-lived= credential, combined with good key rotation and authorization re-verificat= ion without having to re-involve the end-user."
That all sou= nds good, but in our situation (all SSL, etc) - what do we want key rotatio= n and re-verification for? I fail to see a reasonable vector for access tok= en leakage to warrant any of this in our case.


On Wed, Sep 7, 2011 at 5:08 PM, Phi= l Hunt <phil.h= unt@oracle.com> wrote:
See below...

On 2011-09-07, at 4:57 PM, Dave Rochwerger = wrote:

Hi Phil,

>> The client is then forced to periodically reauthenticate (without= the user) before getting a new access token.=A0
What benefit does that have?

The= user does not have to be present. =A0


>>=A0Refresh also gives the authzn ser= ver a chance to revoke access. Hence it is better to use shorter lived acce= ss tokens with long lived refresh tokens.=A0
That doesn't follow - we can just as easily revoke the single long= -lived access token.

As Eran points = out, you'd have to have do a DB lookup to have true revocation. But, by= having a short expiration time on the access token (say 1 hour or less), y= ou get quasi-revocation which has to be re-validated after the access token= expires and the client has to re-authenticate and provide a valid refresh = token. =A0In this sense you get the best of a long-lived credential, combin= ed with good key rotation and authorization re-verification without having = to re-involve the end-user.


Dave.

On = Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt <phil.hunt@oracle.com>= wrote:
You can also u= se a long lived refresh token in combination with a short access token. The= client is then forced to periodically reauthenticate (without the user) be= fore getting a new access token.=A0

Refresh also gives the authzn server a chance to revoke= access. Hence it is better to use shorter lived access tokens with long li= ved refresh tokens.=A0

Phil

On 2011-09-07, at 15:27, William Mills <wmills@yahoo-inc.com> wrote:
<= br>
I'll talk to the refresh token question:=A0 they give you a = hook for extensibility and key rotation.=A0 If you want to rotate your encr= yption keys or extend the data carried in the token in any way then you wan= t to be able to cleanly refresh your tokens.=A0 Note that the refresh flow = allows you to issue a new refresh token at the same time.=A0 It also allows= a clean path to convert tokens in a new client if you decide you want SAML= tokens instead of MAC for example.

If you want those things you want to use refresh tokens= .=A0 You can have long lived access tokens too, and just use the refresh to= kens when you want to do something new with the access tokens.

-bill

From: Dave Rochwerger <daver@quizlet.com>
To: oauth@ietf.o= rg
Cc: Quizlet Dev Team <devteam@quizlet.com>
Sent: Wednesday, S= eptember 7, 2011 2:15 PM
Subject: [OAUTH-WG] OAuth2 I= mplementation questions (client secret and refresh tokens)

Hi all,

I have been implementing OAuth2 based on th= e various drafts for our new API. Initially, I implemented everything as pe= r the spec, but due to our particular scenario and restrictions we have in = place, there are some fundamental questions that I am unable to defend.

I am hoping this group could help answer them for me.

Our scenario:
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
* We are implementing an API to allow 3rd party developers to access= users' protected resources via their applications. The applications wi= ll mostly be native phone apps, but some will have web server backends (jav= ascript-only applications are not a concern at the moment).
* We want to provide very long-lived (forever) tokens.
* We = are implementing the "authorization code" flow as that seems best= suited to us (we don't want the=A0implicit=A0flow because end-users wo= uld have to re-authorize every hour).

Our architecture:
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
* We control both the API server and the authorization = server.
* All requests to=A0protected=A0resources (ie: to the API= server) are always done over SSL.
* All requests to the authz server (token and authorize endpoints) are= always done over SSL.
* We enforce that every client must supply= the state parameter (and our guidelines say they must verify the state for= CSRF mitigation).
* We enforce that every client must register a redirect URI.
* We validate the redirect_uri used to request an access token is the same= that was used to obtain the auth code.
* The only time a request= is not made over SSL is the redirect with the auth_code which is very shor= t-lived (30 seconds) and is tied to a verified redirect URI.
* We enforce that access tokens must be provided using the Authorizati= on header only (and of course, over SSL).
* We have guidelines sa= ying that all mobile apps must use the native browser (and not an embedded = web UI).

Questions:
=3D=3D=3D=3D=3D=3D=3D=3D
1. Given the above scenario, what use are refresh tokens?
=A0 - = Access tokens can not leak because every request (to resource and authz ser= ver) containing an access token is done over SSL. We control both the authz= and resource servers, so tokens in logs (and other suggested reasons in th= e archives) are not an issue.
=A0 - Long-lived refresh tokens and short-lived access tokens are supp= osed to provide security due to possible access token leakage... but in our= 100% SSL=A0scenario, if access tokens are able to leak, then so would the = client id, secret and refresh token.
=A0 - Having a long-lived refresh token that can be exchanged for anot= her access token adds a level of complexity (a second HTTPS request every s= o often) and seems to provide no benefit for our case.


2. What is the point of the client secret (in our scena= rio)?=A0
- We origi= nally were treating the clients as=A0confidential, but after re-reading the= native-application section, it seems we really=A0should=A0treat them as pu= blic (phone apps can be decompiled and the secret discovered).

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


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



--001636c9274ba2f23c04ac630e0d-- From phil.hunt@oracle.com Wed Sep 7 17:52: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 CC47321F8CB0 for ; Wed, 7 Sep 2011 17:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.222 X-Spam-Level: X-Spam-Status: No, score=-5.222 tagged_above=-999 required=5 tests=[AWL=1.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SvPH8XdQvM4d for ; Wed, 7 Sep 2011 17:52:43 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29221F8CAE for ; Wed, 7 Sep 2011 17:52:43 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p880sVpx018262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 00:54:32 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p880sU2O007479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 00:54:30 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p880sPdg014557; Wed, 7 Sep 2011 19:54:25 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Sep 2011 17:54:24 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-21--18865378 From: Phil Hunt In-Reply-To: Date: Wed, 7 Sep 2011 17:54:27 -0700 Message-Id: <541644BD-931A-4E68-932C-2F54133E05CE@oracle.com> References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> <59CDCC16-44BA-4626-B744-F1169A13A542@oracle.com> To: Dave Rochwerger 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.0A090206.4E681249.008D:SCFMA922111,ss=1,re=-6.300,fgs=0 Cc: Quizlet Dev Team , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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, 08 Sep 2011 00:52:44 -0000 --Apple-Mail-21--18865378 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree, it is a matter of tradeoffs, but I think you have the idea. As for your question in 3, think of rotation as following the same = practice as periodic re-authentication of browser based users. If you = never do that, you probably don't care to re-authenticate client apps = either. But if you do it hourly, you probably want your access tokens = to expire hourly too. In that case refresh is useful since it keeps = clients from having to go through re-authorization (which usually = involves the end-users). One other thought. If you are using bearer tokens, then a compromise of = your token db would lead to more exposure than a compromise of refresh = tokens. Why? Because refresh tokens require authentication from the = client before they can be used. It is just another layer of protection = that again may or may not have value for you. Hope that helps! Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-09-07, at 5:22 PM, Dave Rochwerger wrote: > 1. "The user does not have to be present." > Maybe I should be more clear. What benefit does that have over just a = long-lived (forever) access token? The cost is the extra complication = for 3rd party developers to have to worry about refresh tokens. I can = not see a benefit in our model (everything over SSL, etc) to use refresh = tokens. > I want to use refresh tokens - but only if there is a reason for them, = which I can not see at the moment. >=20 > 2. "As Eran points out, you'd have to have do a DB lookup to have true = revocation." > The act of revoking tokens is not a common occurrence, DB lookups to = revoke tokens is not a concern as there is more time spent by the user = navigating the UI (or network latency, etc) than the cost of the DB = call.=20 >=20 > 3. "In this sense you get the best of a long-lived credential, = combined with good key rotation and authorization re-verification = without having to re-involve the end-user." > That all sounds good, but in our situation (all SSL, etc) - what do we = want key rotation and re-verification for? I fail to see a reasonable = vector for access token leakage to warrant any of this in our case. >=20 >=20 > On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt = wrote: > See below... > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: >=20 >> Hi Phil, >>=20 >> >> The client is then forced to periodically reauthenticate (without = the user) before getting a new access token.=20 >> What benefit does that have? >=20 > The user does not have to be present. =20 >=20 >>=20 >> >> Refresh also gives the authzn server a chance to revoke access. = Hence it is better to use shorter lived access tokens with long lived = refresh tokens.=20 >> That doesn't follow - we can just as easily revoke the single = long-lived access token. >=20 > As Eran points out, you'd have to have do a DB lookup to have true = revocation. But, by having a short expiration time on the access token = (say 1 hour or less), you get quasi-revocation which has to be = re-validated after the access token expires and the client has to = re-authenticate and provide a valid refresh token. In this sense you = get the best of a long-lived credential, combined with good key rotation = and authorization re-verification without having to re-involve the = end-user. >=20 >>=20 >> Dave. >>=20 >> On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt = wrote: >> You can also use a long lived refresh token in combination with a = short access token. The client is then forced to periodically = reauthenticate (without the user) before getting a new access token.=20 >>=20 >> Refresh also gives the authzn server a chance to revoke access. Hence = it is better to use shorter lived access tokens with long lived refresh = tokens.=20 >>=20 >> Phil >>=20 >> On 2011-09-07, at 15:27, William Mills wrote: >>=20 >>> I'll talk to the refresh token question: they give you a hook for = extensibility and key rotation. If you want to rotate your encryption = keys or extend the data carried in the token in any way then you want to = be able to cleanly refresh your tokens. Note that the refresh flow = allows you to issue a new refresh token at the same time. It also = allows a clean path to convert tokens in a new client if you decide you = want SAML tokens instead of MAC for example. >>>=20 >>> If you want those things you want to use refresh tokens. You can = have long lived access tokens too, and just use the refresh tokens when = you want to do something new with the access tokens. >>>=20 >>> -bill >>>=20 >>> From: Dave Rochwerger >>> To: oauth@ietf.org >>> Cc: Quizlet Dev Team >>> Sent: Wednesday, September 7, 2011 2:15 PM >>> Subject: [OAUTH-WG] OAuth2 Implementation questions (client secret = and refresh tokens) >>>=20 >>> Hi all, >>>=20 >>> I have been implementing OAuth2 based on the various drafts for our = new API. Initially, I implemented everything as per the spec, but due to = our particular scenario and restrictions we have in place, there are = some fundamental questions that I am unable to defend. >>>=20 >>> I am hoping this group could help answer them for me. >>>=20 >>> Our scenario: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> * We are implementing an API to allow 3rd party developers to access = users' protected resources via their applications. The applications will = mostly be native phone apps, but some will have web server backends = (javascript-only applications are not a concern at the moment). >>> * We want to provide very long-lived (forever) tokens. >>> * We are implementing the "authorization code" flow as that seems = best suited to us (we don't want the implicit flow because end-users = would have to re-authorize every hour). >>>=20 >>> Our architecture: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> * We control both the API server and the authorization server. >>> * All requests to protected resources (ie: to the API server) are = always done over SSL. >>> * All requests to the authz server (token and authorize endpoints) = are always done over SSL. >>> * We enforce that every client must supply the state parameter (and = our guidelines say they must verify the state for CSRF mitigation). >>> * We enforce that every client must register a redirect URI. >>> * We validate the redirect_uri used to request an access token is = the same that was used to obtain the auth code. >>> * The only time a request is not made over SSL is the redirect with = the auth_code which is very short-lived (30 seconds) and is tied to a = verified redirect URI. >>> * We enforce that access tokens must be provided using the = Authorization header only (and of course, over SSL). >>> * We have guidelines saying that all mobile apps must use the native = browser (and not an embedded web UI). >>>=20 >>> Questions: >>> =3D=3D=3D=3D=3D=3D=3D=3D >>> 1. Given the above scenario, what use are refresh tokens? >>> - Access tokens can not leak because every request (to resource = and authz server) containing an access token is done over SSL. We = control both the authz and resource servers, so tokens in logs (and = other suggested reasons in the archives) are not an issue. >>> - Long-lived refresh tokens and short-lived access tokens are = supposed to provide security due to possible access token leakage... but = in our 100% SSL scenario, if access tokens are able to leak, then so = would the client id, secret and refresh token. >>> - Having a long-lived refresh token that can be exchanged for = another access token adds a level of complexity (a second HTTPS request = every so often) and seems to provide no benefit for our case. >>>=20 >>>=20 >>> 2. What is the point of the client secret (in our scenario)?=20 >>> - We originally were treating the clients as confidential, but after = re-reading the native-application section, it seems we really should = treat them as public (phone apps can be decompiled and the secret = discovered). >>> - The spec says that the authz server should authenticate = confidential clients, but public clients are allowed to just send their = public client id (and no secret). >>> - The only verification then, is to enforce redirect URI = registration and to validate the redirect URI between authorization and = token steps. >>>=20 >>> So, the question is, assuming that we, one: "enforce redirect-URI = registration" and two: "validate that URI" - why can't we treat all = clients as public and not worry about a secret? >>> What is the benefit of having confidential clients (and a secret) at = all?=20 >>>=20 >>>=20 >>> Our API source is not available, but the oauth2 server = implementation can be seen here: https://github.com/quizlet/oauth2-php >>>=20 >>> Regards, >>> Dave >>>=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 --Apple-Mail-21--18865378 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = agree, it is a matter of tradeoffs, but I think you have the = idea.

As for your question in 3, think of rotation as = following the same practice as periodic re-authentication of browser = based users. If you never do that, you probably don't care to = re-authenticate client apps either.  But if you do it hourly, you = probably want your access tokens to expire hourly too. In that case = refresh is useful since it keeps clients from having to go through = re-authorization (which usually involves the = end-users).

One other thought. If you are using = bearer tokens, then a compromise of your token db would lead to more = exposure than a compromise of refresh tokens.  Why?  Because = refresh tokens require authentication from the client before they can be = used. It is just another layer of protection that again may or may not = have value for you.

Hope that = helps!

Phil

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





On 2011-09-07, at 5:22 PM, Dave Rochwerger wrote:

1.= "The user does not have to be present."
Maybe I should = be more clear. What benefit does that have over just a long-lived = (forever) access token? The cost is the extra complication for 3rd party = developers to have to worry about refresh tokens. I can not see a = benefit in our model (everything over SSL, etc) to use refresh = tokens.
I want to use refresh tokens - but only if there is a reason for = them, which I can not see at the moment.

2. "As = Eran points out, you'd have to have do a DB lookup to have true = revocation."
The act of revoking tokens is not a common occurrence, DB lookups = to revoke tokens is not a concern as there is more time spent by the = user navigating the UI (or network latency, etc) than the cost of the DB = call. 

3. "In this sense you get the best of a long-lived = credential, combined with good key rotation and authorization = re-verification without having to re-involve the = end-user."
That all sounds good, but in our situation (all = SSL, etc) - what do we want key rotation and re-verification for? I fail = to see a reasonable vector for access token leakage to warrant any of = this in our case.


On Wed, Sep 7, 2011 at 5:08 PM, = Phil Hunt <phil.hunt@oracle.com> = wrote:
See below...

On 2011-09-07, at 4:57 PM, Dave = Rochwerger wrote:

Hi = Phil,

>> The client is then forced to = periodically reauthenticate (without the user) before getting a new = access token. 
What benefit does that = have?

The user does not have = to be present.  


>> Refresh also gives the = authzn server a chance to revoke access. Hence it is better to use = shorter lived access tokens with long lived refresh tokens. 
That doesn't follow - we can just as easily revoke the single = long-lived access token.

As Eran = points out, you'd have to have do a DB lookup to have true revocation. = But, by having a short expiration time on the access token (say 1 hour = or less), you get quasi-revocation which has to be re-validated after = the access token expires and the client has to re-authenticate and = provide a valid refresh token.  In this sense you get the best of a = long-lived credential, combined with good key rotation and authorization = re-verification without having to re-involve the end-user.


Dave.

On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt <phil.hunt@oracle.com> wrote:
You can also use a long lived refresh token in = combination with a short access token. The client is then forced to = periodically reauthenticate (without the user) before getting a new = access token. 

Refresh also gives the authzn server a chance to = revoke access. Hence it is better to use shorter lived access tokens = with long lived refresh = tokens. 

Phil

On 2011-09-07, at 15:27, William Mills <wmills@yahoo-inc.com> = wrote:

I'll talk to the refresh token question:  they give you = a hook for extensibility and key rotation.  If you want to rotate = your encryption keys or extend the data carried in the token in any way = then you want to be able to cleanly refresh your tokens.  Note that = the refresh flow allows you to issue a new refresh token at the same = time.  It also allows a clean path to convert tokens in a new = client if you decide you want SAML tokens instead of MAC for = example.

If you want those things you want to use refresh = tokens.  You can have long lived access tokens too, and just use = the refresh tokens when you want to do something new with the access = tokens.

-bill

From: Dave Rochwerger <daver@quizlet.com>
To: oauth@ietf.org
Cc: Quizlet Dev Team = <devteam@quizlet.com>
Sent: Wednesday, September 7, 2011 = 2:15 PM
Subject: [OAUTH-WG] = OAuth2 Implementation questions (client secret and refresh tokens)

Hi = all,

I have been implementing OAuth2 based on the = various drafts for our new API. Initially, I implemented everything as = per the spec, but due to our particular scenario and restrictions we = have in place, there are some fundamental questions that I am unable to = defend.

I am hoping this group could help answer them for = me.

Our scenario:
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
* We are implementing an API to allow 3rd party developers = to access users' protected resources via their applications. The = applications will mostly be native phone apps, but some will have web = server backends (javascript-only applications are not a concern at the = moment).
* We want to provide very long-lived (forever) tokens.
* = We are implementing the "authorization code" flow as that seems best = suited to us (we don't want the implicit flow because = end-users would have to re-authorize every hour).

Our architecture:
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
* We control both the API server and the = authorization server.
* All requests = to protected resources (ie: to the API server) are always done = over SSL.
* All requests to the authz server (token and authorize endpoints) = are always done over SSL.
* We enforce that every client must = supply the state parameter (and our guidelines say they must verify the = state for CSRF mitigation).
* We enforce that every client must register a redirect = URI.
* We validate the redirect_uri used to request an access = token is the same that was used to obtain the auth code.
* The = only time a request is not made over SSL is the redirect with the = auth_code which is very short-lived (30 seconds) and is tied to a = verified redirect URI.
* We enforce that access tokens must be provided using the = Authorization header only (and of course, over SSL).
* We have = guidelines saying that all mobile apps must use the native browser (and = not an embedded web UI).

Questions:
=3D=3D=3D=3D=3D=3D=3D=3D
1. Given the above scenario, what use are refresh = tokens?
  - Access tokens can not leak because every = request (to resource and authz server) containing an access token is = done over SSL. We control both the authz and resource servers, so tokens = in logs (and other suggested reasons in the archives) are not an = issue.
  - Long-lived refresh tokens and short-lived access tokens = are supposed to provide security due to possible access token leakage... = but in our 100% SSL scenario, if access tokens are able to leak, = then so would the client id, secret and refresh token.
  - Having a long-lived refresh token that can be exchanged = for another access token adds a level of complexity (a second HTTPS = request every so often) and seems to provide no benefit for our = case.


2. What is the point of the client secret (in our = scenario)? 
- We = originally were treating the clients as confidential, but after = re-reading the native-application section, it seems we = really should treat them as public (phone apps can be = decompiled and the secret discovered).
- = The spec says that the authz server should = authenticate confidential clients, but public clients are = allowed to just send their public client id (and no secret).
- The only verification then, is to enforce redirect URI = registration and to validate the redirect URI between authorization and = token steps.

So, the question is, assuming that we, one: = "enforce redirect-URI registration" and two: "validate that URI" - why = can't we treat all clients as public and not worry about a = secret?
What is = the benefit of having confidential clients (and a secret) at = all? 


Our API source is not available, but the = oauth2 server implementation can be seen here: https://github.com/quizlet/oauth2-php

Regards,
Dave


_______________________________________________
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-21--18865378-- From mike@mtcc.com Wed Sep 7 18:02: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 E7D8C21F8CF7 for ; Wed, 7 Sep 2011 18:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 wcBdPf7h8v-r for ; Wed, 7 Sep 2011 18:02:10 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id DA07A21F8CA0 for ; Wed, 7 Sep 2011 18:02:09 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id p8813wVO031130 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Sep 2011 18:03:58 -0700 Message-ID: <4E68147E.8000300@mtcc.com> Date: Wed, 07 Sep 2011 18:03:58 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ben Niven-Jenkins , "oauth@ietf.org" References: <4E665B25.6090709@mtcc.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> <4E67C6C9.1070704@stpete! r.im> <4E67C893.5060505@mtcc.com> <4E67D149.8080200@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1316; t=1315443838; x=1316307838; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[OAUTH-WG]=20problem=20statement |Sender:=20 |To:=20Ben=20Niven-Jenkins=20,=20= 0A=20=22oauth@ietf.org=22=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=u+hDxlUblwzZAZULJeM5IbQ74UjIsr0DYY3knSXwO3w=; b=Tg1Cj95Togi9bugk0d9bcHEyLOoVLiGV0M4ynIT/MhNYiq2c8Cbl7p2O+P rjJRDQmX2zfu60dVxazaA2F51rh/RWzOMvqJPiTRnUbyligjKGhUbupaebp3 4+FaEV0x6qrvpZtD8/+bxxG+YGFF8SEVZ3apE/+bErrDdCpXkYFbU=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [OAUTH-WG] problem statement 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, 08 Sep 2011 01:02:11 -0000 On 09/07/2011 05:19 PM, Ben Niven-Jenkins wrote: > Your original e-mail that started this thread was not targeted at a specific document and my interpretation is that some of the hostility you have experienced is due to a frustration that your request is seen as a potential obstacle to getting the protocol specification out the door because the issue you want to discuss is not directly related to how a developer might implement the protocol. > I had no idea where in the ietf process the protocol document is. I'm still not sure whether it's been through wg last call, ietf last call, etc. > If I may be so bold, could I suggest that you propose some text that articulates the issue that you would like to see documented and then the group can assess that text on its merits and try to reach consensus on which document, if any, it is best placed to reside within. > Basically, in the protocol document's introduction I think it should be clearly explained that the UA functionality is expected to be "trusted", ie not be under the control of a potential attacker. I think that for the uninitiated that is anything but obvious. There has been a sea-change since 2007 making this an important point. Had that been in the introduction, we would not be having this conversation. Mike From eran@hueniverse.com Fri Sep 9 16:05: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 F005E11E8083 for ; Fri, 9 Sep 2011 16:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 CyM4knZ3dmki for ; Fri, 9 Sep 2011 16:05:28 -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 784DF11E8073 for ; Fri, 9 Sep 2011 16:05:28 -0700 (PDT) Received: (qmail 5481 invoked from network); 9 Sep 2011 23:07:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Sep 2011 23:07:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 9 Sep 2011 16:06:33 -0700 From: Eran Hammer-Lahav To: =?utf-8?B?QW5kcsOpIERlTWFycmU=?= Date: Fri, 9 Sep 2011 16:06:29 -0700 Thread-Topic: Authorization code use in draft-ietf-oauth-v2-21 Thread-Index: AcxvRR4XY4qdDqUCQEGA2vnS4w7g3g== Message-ID: <8A78E766-3A1D-4534-B336-3084A182EFD0@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code use in draft-ietf-oauth-v2-21 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, 09 Sep 2011 23:05:29 -0000 U2VuZGluZyB0byB0aGUgcmlnaHQgYWRkcmVzcy4gDQoNCkVITA0KDQpPbiBTZXAgOSwgMjAxMSwg YXQgMTU6MzEsICJBbmRyw6kgRGVNYXJyZSIgPGFuZHJlZGVtYXJyZUBnbWFpbC5jb20+IHdyb3Rl Og0KDQo+IEdyZWV0aW5ncyBFdmVyeW9uZSwNCj4gDQo+IEkgaG9wZSB0aGUgZHJhZnQgaXNuJ3Qg dG9vIGZhciBhbG9uZyBmb3IgdGhlc2UgY29tbWVudHMuDQo+IChkcmFmdC1pZXRmLW9hdXRoLXYy LTIxKQ0KPiANCj4gMS4gQVVUSE9SSVpBVElPTiBDT0RFIFJFU1RSSUNUSU9OUw0KPiANCj4gVGhl IHNwZWNpZmljYXRpb24gKHBhcnRpY3VsYXJseSBTZWN0aW9uIDQuMSkgZG9lcyBub3Qgc2F5IGlm IHRoZQ0KPiBhdXRob3JpemF0aW9uIHNlcnZlciBtYXkgb3IgbWF5IG5vdCBhbGxvdyBhbiBhdXRo b3JpemF0aW9uIGNvZGUgdG8gYmUNCj4gdXNlZCBtb3JlIHRoYW4gb25jZSBpbiBleGNoYW5nZSBm b3IgYW4gYWNjZXNzIHRva2VuLiAoU2VjdGlvbiA0LjEuMykNCj4gDQo+IFdpdGggdGhpcyBhbWJp Z3VpdHksIHNvbWUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIG1pZ2h0DQo+ IGFsbG93IGF1dGhvcml6YXRpb24gY29kZXMgdG8gYmUgcmV1c2VkIGJ5IHRoZSBjbGllbnQgKHdo ZXRoZXINCj4gaW50ZW50aW9uYWxseSBvciBub3QpLiBJIGRvbid0IHNlZSBhbnkgYmVuZWZpdCBp biBhbGxvd2luZyB0aGlzIGFuZA0KPiB0aGluayBpdCBzaG91bGQgYmUgZm9yYmlkZGVuIGZvciBz ZXZlcmFsIHJlYXNvbnMuDQo+IA0KPiBBbGxvd2luZyB0aGlzIGVuYWJsZXMgYSBzY2VuYXJpbyB3 aGVyZSBhbiBhdXRob3JpemF0aW9uIGNvZGUgbWF5IGJlDQo+IHJldXNlZCB3aGVuIHRoZSBjbGll bnQgc2hvdWxkIHVzZSB0aGUgcmVmcmVzaCB0b2tlbiBpbnN0ZWFkLiBUaGUNCj4gcmVmcmVzaCB0 b2tlbiBoYXMgbW9yZSBkZXNpcmFibGUgc2VjdXJpdHkgcHJvcGVydGllcy4NCj4gDQo+IFRoZSB1 c2VmdWxuZXNzIG9mIGF1dGhvcml6YXRpb24gY29kZXMgc2hvdWxkIGJlIHJlc3RyaWN0ZWQgd2hl cmV2ZXINCj4gcG9zc2libGUgYmVjYXVzZSB0aGV5IGFyZSByZXZlYWxlZCB0byByZXNvdXJjZSBv d25lcnMgYW5kIGNhbiBiZSBzZW50DQo+IG92ZXIgdW5zZWN1cmUgY29ubmVjdGlvbnMgd2hlbiB0 aGUgY2xpZW50IGRvZXMgbm90IHJlcXVpcmUgVExTIG9uIGl0cw0KPiByZWRpcmVjdGlvbiBVUkku IFRoZXNlIHByb3BlcnRpZXMgY29tYmluZWQgd2l0aCB0aGUgcG9zc2liaWxpdHkgdGhhdA0KPiB0 aGUgYXV0aG9yaXphdGlvbiBjb2RlIGZsb3cgbWF5IGJlIHVzZWQgYnkgcHVibGljIGNsaWVudHMg bWlnaHQgb3Blbg0KPiBtb3JlIHNldmVyZSBhdHRhY2sgdmVjdG9ycy4NCj4gDQo+IEkgdGhpbmsg aXQgc2hvdWxkIGJlIGNsZWFybHkgc3RhdGVkIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IE1VU1QNCj4gTk9UIGlzc3VlIG1vcmUgdGhhbiBvbmUgYWNjZXNzIHRva2VuIHBlciBhdXRob3Jp emF0aW9uIGNvZGUgZ3JhbnQuIEFuDQo+IGF1dGhvcml6YXRpb24gY29kZSBzaG91bGQgYmUgZGlz Y2FyZGVkIGFmdGVyIGl0cyBmaXJzdCB1c2UgYW5kIG5ldw0KPiBhY2Nlc3MgdG9rZW5zIHNob3Vs ZCBvbmx5IGJlIGlzc3VlZCB3aGVuIGV4Y2hhbmdlZCBmb3IgcmVmcmVzaCB0b2tlbnMuDQo+IA0K PiANCj4gMi4gQVVUSE9SSVpBVElPTiBDT0RFIFZTLiBUT0tFTj8NCj4gDQo+IE11Y2ggbGVzcyBp bXBvcnRhbnQsIGFuZCBwbGVhc2UgZm9yZ2l2ZSBtZSBpZiB0aGlzIGhhcyBhbHJlYWR5IGJlZW4N Cj4gZGlzY3Vzc2VkLCBidXQgd2h5IGlzbid0IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgY2FsbGVk IGFuDQo+IGF1dGhvcml6YXRpb24gdG9rZW4/IEl0IGlzIHNpbWlsYXIgdG8gdGhlIHJlZnJlc2gg dG9rZW4gaW4gdGhhdCBpdCBjYW4NCj4gYmUgcHJlc2VudGVkIGluIGV4Y2hhbmdlIGZvciBhbiBh Y2Nlc3MgdG9rZW4gYXQgdGhlIHRva2VuIGVuZHBvaW50LiBJDQo+IHNlZSBpdCBhcyBhbm90aGVy IHR5cGUgb2YgdG9rZW4gYW5kIHdvbmRlciBpZiB0aGUgbGFuZ3VhZ2UgdXNlZCBzaG91bGQNCj4g cGVyaGFwcyByZWZsZWN0IHRoYXQgYXMgd2VsbC4NCj4gDQo+IA0KPiAzLiBHUkFNTUFSIENPUlJF Q1RJT04gSU4gU0VDVElPTiAxMC4xMg0KPiANCj4gSW4gU2VjdGlvbiAxMC4xMiBwYXJhZ3JhcGgg dGhyZWUgaXQgc2F5cyAiKGUuZy4gYSBoYXNoIG9mIHRoZSBzZXNzaW9uDQo+IGNvb2tpZSB1c2Vk IHRvIGF1dGhlbnRpY2F0aW9uIHRoZSB1c2VyLWFnZW50KS4iIFRoaXMgc2hvdWxkIHNheQ0KPiAi YXV0aGVudGljYXRlIiBpbnN0ZWFkIG9mICJhdXRoZW50aWNhdGlvbiIuDQo+IA0KPiBSZWdhcmRz LA0KPiBBbmRyZSBEZU1hcnJlDQoNCg== From recordond@gmail.com Sat Sep 10 10:27: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 4323C21F8510 for ; Sat, 10 Sep 2011 10:27:10 -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 2M+r1KZ0NnBq for ; Sat, 10 Sep 2011 10:27:09 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3BD21F84CF for ; Sat, 10 Sep 2011 10:27:09 -0700 (PDT) Received: by gwb17 with SMTP id 17so3261562gwb.15 for ; Sat, 10 Sep 2011 10:29:07 -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=s64L7Oe8LbDo44hq5vRr23fWGQhxO/QfoL/S+2yQxPQ=; b=lPxaQoGpqJttwDClzM7g5xnogHnfdb74ObEiED2PBj9b6JWJQVDony6gyD2O6zzsok n5KA4LFWQiStYKPQiwpQRrsOPsvKh9FfBPFAA449Tr67e/gqravemtTwfb1PKAxktR+F 5j4HAs00aS8CQy9TkyfiOPxutLiqMl6Z2mvgg= MIME-Version: 1.0 Received: by 10.42.134.130 with SMTP id l2mr440467ict.399.1315675745811; Sat, 10 Sep 2011 10:29:05 -0700 (PDT) Received: by 10.231.14.9 with HTTP; Sat, 10 Sep 2011 10:29:05 -0700 (PDT) In-Reply-To: <4E68147E.8000300@mtcc.com> References: <4E665B25.6090709@mtcc.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> <4E67C893.5060505@mtcc.com> <4E67D149.8080200@mtcc.com> <4E68147E.8000300@mtcc.com> Date: Sat, 10 Sep 2011 10:29:05 -0700 Message-ID: From: David Recordon To: Michael Thomas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 10 Sep 2011 17:27:10 -0000 Hey Mike, I think this has been said a few times by Eran and Peter but you really need to propose actual sentences that you want to see included in the specification at this point. Saying "I think it should be clearly explained" isn't actionable text. That said, I strongly don't believe this is an issue specific to OAuth. --David On Wed, Sep 7, 2011 at 6:03 PM, Michael Thomas wrote: > On 09/07/2011 05:19 PM, Ben Niven-Jenkins wrote: >> >> Your original e-mail that started this thread was not targeted at a >> specific document and my interpretation is that some of the hostility yo= u >> have experienced is due to a frustration that your request is seen as a >> potential obstacle to getting the protocol specification out the door >> because the issue you want to discuss is not directly related to how a >> developer might implement the protocol. >> > > I had no idea where in the ietf process the protocol document is. I'm > still not sure whether it's been through wg last call, ietf last call, et= c. > >> If I may be so bold, could I suggest that you propose some text that >> articulates the issue that you would like to see documented and then the >> group can assess that text on its merits and try to reach consensus on w= hich >> document, if any, it is best placed to reside within. >> > > Basically, in the protocol document's introduction I think it should > be clearly explained that the UA functionality is expected to be "trusted= ", > ie not be under the control of a potential attacker. I think that for the > uninitiated that is anything but obvious. There has been a sea-change > since 2007 making this an important point. Had that been in the > introduction, we would not be having =A0this conversation. > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From hardjono@mit.edu Mon Sep 12 10:56: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 3E24F21F8C22 for ; Mon, 12 Sep 2011 10:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 p4m2viQZmacr for ; Mon, 12 Sep 2011 10:56:51 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3A621F85F2 for ; Mon, 12 Sep 2011 10:56:50 -0700 (PDT) X-AuditID: 1209190f-b7b44ae000000a24-90-4e6e47c2d503 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 4A.6D.02596.2C74E6E4; Mon, 12 Sep 2011 13:56:18 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p8CHwrOF025521; Mon, 12 Sep 2011 13:58:53 -0400 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id p8CHwq4N019343; Mon, 12 Sep 2011 13:58:53 -0400 Received: from w92exhub5.exchange.mit.edu (18.7.73.11) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 12 Sep 2011 10:57:57 -0700 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub5.exchange.mit.edu ([18.7.73.11]) with mapi; Mon, 12 Sep 2011 13:58:51 -0400 From: Thomas Hardjono To: David Recordon , Michael Thomas Date: Mon, 12 Sep 2011 13:58:51 -0400 Thread-Topic: [OAUTH-WG] problem statement Thread-Index: Acxv3ygPlMWlltrhTq2d5KspgKxVsQBleFog Message-ID: References: <4E665B25.6090709@mtcc.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> <4E67C893.5060505@mtcc.com> <4E67D149.8080200@mtcc.com> <4E68147E.8000300@mtcc.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTcRTnv3u33a3dvJva/r4CJ5ZZ8/1BImQU1igYGgXVF726q1tt0+6d MkeY9UWwAjX90Ex8MCMfOWeQ9lQXBoqaIoFoJcpKWaYJYUkg3bvrdN9+h9/jnMM5GKL4JYzE jBYrRVtIk0okRRWS8Di155xFl/J3JTGzs84pyhz76RNl3l/7jmoQ7UvHF7HW6dwWaLt7P4pz kGvSU3rKZCyn6OSsfKlhfjK7tO+wzd37QFgFemENkGCQyIATs9sojw/B6a8uUQ2QYgriHYAP 3y+jfDHMFi0dAr74AGDXyMau7AWAQ+sbYr6oBdB5bw3hwkREApz691bM4TBCC92rXj9GiHjo 6p4RcBhlcUffUz8OJY7BRccMq8FYfSJs3DnLW9NgzeNVvwQncuD6XPPuFLUYXOz3+geXELlw Z/aZHwN2iT/jPQK+lxLOe1sE/HJy2N70BgksuvNqScTrw+Hnahfg9UlwrrFBxOPj8EnbD4Rv LIdjj7xoLYhwBMU6giyOIIsjyNIK0C4Qozfb1WbSaGKoQjVTSFosFK3OSDIbrUmUvqwf+A8b ETIItkZUHkBgQCXDbfEWnUJIljMVZg+IwASqcLyTvbviYEGJvsJAMoY8usxEMR4AMUQVhl/O ZjlcT1bYKbokQEVhqEqJ3xnU6BREMWmlblBUKUUH2GgMU0F8gAuV01QxZSsymqz7tACTcOEy NjyF0+BMKWlmjMU8Pw5iI5X4E44gOMJQZtnzBh7VB5TsKqH4MKeSsW+85/axwQI2+EqHmQu2 kvtUZBVIpUbrsNah0y0Xc/p7qis/RYmvL5zMGnI3P78wPaDIurt5a+qmoW0yJDo3f6sjdTZ/ dN5lr6o8sSlJMJK0jZlrdxetVGqQkAOLQvem7szt37Hnl+N839bTZQ3ygrZLPqtGGnNU13Sk Eegsaxqcrk8m0qLSqbyrr+sXlieW7CqUMZCpiQjNkP8Bn8m734MDAAA= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 12 Sep 2011 17:56:52 -0000 > > Basically, in the protocol document's introduction I think it should > > be clearly explained that the UA functionality is expected to be > > "trusted", ie not be under the control of a potential attacker. I > > think that for the uninitiated that is anything but obvious. There has > > been a sea-change since 2007 making this an important point. Had that > > been in the introduction, we would not be having this conversation. > > > > Mike Mike, I have found that the Security Considerations doc helps a lot in understand= ing the expected deployment conditions of OAUTH (see draft-lodderstedt-oaut= h-securityconsiderations-02.txt). For example, Section 2.2 (about Malicious Client) goes a long way towards a= nswering your concerns: Assumption: It is not the task of the authorization server to protect the end-user's device from malicious software. This is the responsibility of the platform running on the particular device probably in cooperation with other components of the respective ecosystem (e.g. an application management infrastructure). The sole responsibility of the authorization server is to control access to the end-user's resources living in resource servers and to prevent unauthorized access to them. Based on this assumption, the following countermeasures are recommended. Hope this helps. /thomas/ __________________________________________ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of David Recordon > Sent: Saturday, September 10, 2011 1:29 PM > To: Michael Thomas > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] problem statement >=20 > Hey Mike, I think this has been said a few times by Eran and Peter but > you really need to propose actual sentences that you want to see > included in the specification at this point. Saying "I think it should > be clearly explained" isn't actionable text. >=20 > That said, I strongly don't believe this is an issue specific to OAuth. >=20 > --David >=20 >=20 > On Wed, Sep 7, 2011 at 6:03 PM, Michael Thomas wrote: > > On 09/07/2011 05:19 PM, Ben Niven-Jenkins wrote: > >> > >> Your original e-mail that started this thread was not targeted at a > >> specific document and my interpretation is that some of the > hostility > >> you have experienced is due to a frustration that your request is > >> seen as a potential obstacle to getting the protocol specification > >> out the door because the issue you want to discuss is not directly > >> related to how a developer might implement the protocol. > >> > > > > I had no idea where in the ietf process the protocol document is. I'm > > still not sure whether it's been through wg last call, ietf last > call, etc. > > > >> If I may be so bold, could I suggest that you propose some text that > >> articulates the issue that you would like to see documented and then > >> the group can assess that text on its merits and try to reach > >> consensus on which document, if any, it is best placed to reside > within. > >> > > > > Basically, in the protocol document's introduction I think it should > > be clearly explained that the UA functionality is expected to be > > "trusted", ie not be under the control of a potential attacker. I > > think that for the uninitiated that is anything but obvious. There > has > > been a sea-change since 2007 making this an important point. Had that > > been in the introduction, we would not be having =A0this conversation. > > > > Mike > > _______________________________________________ > > 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 Mon Sep 12 11:20: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 AF77E21F8B56 for ; Mon, 12 Sep 2011 11:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.241 X-Spam-Level: X-Spam-Status: No, score=-5.241 tagged_above=-999 required=5 tests=[AWL=1.358, 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 uNuyMVOCiqFv for ; Mon, 12 Sep 2011 11:20:29 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7421F21F8B55 for ; Mon, 12 Sep 2011 11:20:29 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8CIMUn5027092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Sep 2011 18:22:32 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 p8CIMUpN021131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 18:22:30 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8CIMORX010923; Mon, 12 Sep 2011 13:22:24 -0500 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Sep 2011 11:22:24 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Mon, 12 Sep 2011 11:22:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E665B25.6090709@mtcc.com> <4E666B65.30701@mtcc.com> <29815937-0FB9-463B-B6E4-8FCAF7B3CD8C@hueniverse.com> <4E666E73.3050502@mtcc.com> <4E6671FA.3090503@gmail.com> <4E667469.2040007@mtcc.com> <1315337809.3136.38.camel@ground> <4E667953.9020906@mtcc.com> <71A460EE-1E2C-4165-99A8-5A97D6E9365C@jkemp.net> <4E667E2E.7090304@mtcc.com> <80A88920-A1EF-4A1C-A97E-F99379923CFB@jkemp.net> <4E66845E.7090906@mtcc.com> <4E669D3C.5000900@gmail.com> <7D4DF72E-B211-4D41-B447-4CF04E9CB1D8@hueniverse.com> <4E67A710.9070505@alcatel-lucent.com> <4E67A942.1070200@mtcc.com> <90C41DD21FB7C64BB94121FBBC2E7234518A4F274E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E67C501.3060001@mtcc.com> <4E67C893.5060505@mtcc.com> <4E67D149.8080200@mtcc.com> <4E68147E.8000300@mtcc.com> To: Thomas Hardjono 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.0A02020A.4E6E4DE8.01E9:SCFMA922111,ss=1,re=-4.000,fgs=0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] problem statement 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, 12 Sep 2011 18:20:31 -0000 Note that the security considerations doc was replaced with the Threat = Models WG draft, http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 While that paragraph is not in the Threat Model document, there are = numerous threats discussed regarding malicious clients and what the = recommended counter measures are. I believe these threats go well beyond = Michael's original concerns. I invite Michael to take a look at the Threat Model spec and suggest = whether he would either prefer to describe a new threat (and propose = text), or whether new introductory text is warranted such as the = assumption from the security considerations draft below. Let us know if you have any specific comments on the Threat Model doc, = in particular referencing sections/paragraphs which may need refinement = to address the concerns. The easiest way to do this, as always, is to = suggest edits and proposed replacement text to this mature document. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-09-12, at 10:58 AM, Thomas Hardjono wrote: >>> Basically, in the protocol document's introduction I think it should >>> be clearly explained that the UA functionality is expected to be >>> "trusted", ie not be under the control of a potential attacker. I >>> think that for the uninitiated that is anything but obvious. There = has >>> been a sea-change since 2007 making this an important point. Had = that >>> been in the introduction, we would not be having this conversation. >>>=20 >>> Mike >=20 >=20 > Mike, >=20 > I have found that the Security Considerations doc helps a lot in = understanding the expected deployment conditions of OAUTH (see = draft-lodderstedt-oauth-securityconsiderations-02.txt). >=20 > For example, Section 2.2 (about Malicious Client) goes a long way = towards answering your concerns: >=20 > Assumption: It is not the task of the authorization server to = protect > the end-user's device from malicious software. This is the > responsibility of the platform running on the particular device > probably in cooperation with other components of the respective > ecosystem (e.g. an application management infrastructure). The sole > responsibility of the authorization server is to control access to > the end-user's resources living in resource servers and to prevent > unauthorized access to them. Based on this assumption, the = following > countermeasures are recommended. >=20 > Hope this helps. >=20 > /thomas/ >=20 > __________________________________________ >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of David Recordon >> Sent: Saturday, September 10, 2011 1:29 PM >> To: Michael Thomas >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] problem statement >>=20 >> Hey Mike, I think this has been said a few times by Eran and Peter = but >> you really need to propose actual sentences that you want to see >> included in the specification at this point. Saying "I think it = should >> be clearly explained" isn't actionable text. >>=20 >> That said, I strongly don't believe this is an issue specific to = OAuth. >>=20 >> --David >>=20 >>=20 >> On Wed, Sep 7, 2011 at 6:03 PM, Michael Thomas wrote: >>> On 09/07/2011 05:19 PM, Ben Niven-Jenkins wrote: >>>>=20 >>>> Your original e-mail that started this thread was not targeted at a >>>> specific document and my interpretation is that some of the >> hostility >>>> you have experienced is due to a frustration that your request is >>>> seen as a potential obstacle to getting the protocol specification >>>> out the door because the issue you want to discuss is not directly >>>> related to how a developer might implement the protocol. >>>>=20 >>>=20 >>> I had no idea where in the ietf process the protocol document is. = I'm >>> still not sure whether it's been through wg last call, ietf last >> call, etc. >>>=20 >>>> If I may be so bold, could I suggest that you propose some text = that >>>> articulates the issue that you would like to see documented and = then >>>> the group can assess that text on its merits and try to reach >>>> consensus on which document, if any, it is best placed to reside >> within. >>>>=20 >>>=20 >>> Basically, in the protocol document's introduction I think it should >>> be clearly explained that the UA functionality is expected to be >>> "trusted", ie not be under the control of a potential attacker. I >>> think that for the uninitiated that is anything but obvious. There >> has >>> been a sea-change since 2007 making this an important point. Had = that >>> been in the introduction, we would not be having this conversation. >>>=20 >>> Mike >>> _______________________________________________ >>> 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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From paul.madsen@gmail.com Mon Sep 12 13:27: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 2CA1B21F8D6D for ; Mon, 12 Sep 2011 13:27:19 -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 zBgJdMboJAY2 for ; Mon, 12 Sep 2011 13:27:18 -0700 (PDT) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8DB21F8D6B for ; Mon, 12 Sep 2011 13:27:18 -0700 (PDT) Received: by ewy1 with SMTP id 1so2806648ewy.27 for ; Mon, 12 Sep 2011 13:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=PZC6ottGPFc/kE/LgSWfisa7WpMoeB5cuELPuYL+pVw=; b=Oc788ACvgMGbv+c61oLtTjwblCJSuvrpDcA68ywqj+++u395xq0LQgIqaeZBH5flf8 qekOuKUTX1T6fFv2kHGObRww11PUHRbTTPgFFuNyZHy+iOaFbfeKvhC13raBk/5sioHX H6b02v1w/gYEqkd7/9TreptY36Gyo80Vc6otQ= Received: by 10.213.31.75 with SMTP id x11mr546667ebc.6.1315859362135; Mon, 12 Sep 2011 13:29:22 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id x45sm8739119eeh.11.2011.09.12.13.29.19 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 13:29:20 -0700 (PDT) Message-ID: <4E6E6BDF.1040009@gmail.com> Date: Mon, 12 Sep 2011 16:30:23 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="------------000203050001040007070308" Subject: [OAUTH-WG] Typo in Sec 5.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, 12 Sep 2011 20:27:19 -0000 This is a multi-part message in MIME format. --------------000203050001040007070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit scope OPTIONAL. The scope of the access request as described by Section 3.3 . presumably this should be 'access token' paul --------------000203050001040007070308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
scope
         OPTIONAL.  The scope of the access request as described by
         Section 3.3.

presumably this should be 'access token'

paul
--------------000203050001040007070308-- From andredemarre@gmail.com Mon Sep 12 12:02: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 091D321F8CA8 for ; Mon, 12 Sep 2011 12:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 bPgknuuHbuVG for ; Mon, 12 Sep 2011 12:02:44 -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 54D0121F8BFE for ; Mon, 12 Sep 2011 12:02:44 -0700 (PDT) Received: by ywa6 with SMTP id 6so2215199ywa.31 for ; Mon, 12 Sep 2011 12:04:48 -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=wCOzrN0fqQ84jcgAicB4E1acTRoCrN/SBg7WAPNtRX8=; b=CIQ7B5v1L4o3C82m6pCAF7ak+aJ2Nko6LDybP9Ow0sJxchjPm+oZ+2xReQ1+ZyIxtV 4cwyh1bN1w505Fkp7Ot9wJW9BJ6+QIA9sYGqSXnQnTutQ6503B4yV6IcODUfVHD52BUA gYdr0PQM/3t/GqnYbMBDZeuP425nzFqDRk9o8= MIME-Version: 1.0 Received: by 10.42.96.65 with SMTP id i1mr875036icn.275.1315854288110; Mon, 12 Sep 2011 12:04:48 -0700 (PDT) Received: by 10.42.18.129 with HTTP; Mon, 12 Sep 2011 12:04:48 -0700 (PDT) In-Reply-To: <8A78E766-3A1D-4534-B336-3084A182EFD0@hueniverse.com> References: <8A78E766-3A1D-4534-B336-3084A182EFD0@hueniverse.com> Date: Mon, 12 Sep 2011 12:04:48 -0700 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 12 Sep 2011 13:27:38 -0700 Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code use in draft-ietf-oauth-v2-21 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, 12 Sep 2011 19:07:58 -0000 I overlooked section 10.5 paragraph 3, which addresses my first point below, but I think enforcing single use authentication codes should also be included at the bottom of section 4.1.3 in the "authorization server MUST" list. Proposed text for item 3: "verify that the authorization code is valid and has not yet been used to acquire an access token, and". It is stated in 10.5 that authorization codes must be short lived, but it might be good to state that the lifetime of authorization codes should be included in the authorization server documentation. Andre DeMarre On Fri, Sep 9, 2011 at 4:06 PM, Eran Hammer-Lahav wro= te: > Sending to the right address. > > EHL > > On Sep 9, 2011, at 15:31, "Andr=E9 DeMarre" wrot= e: > >> Greetings Everyone, >> >> I hope the draft isn't too far along for these comments. >> (draft-ietf-oauth-v2-21) >> >> 1. AUTHORIZATION CODE RESTRICTIONS >> >> The specification (particularly Section 4.1) does not say if the >> authorization server may or may not allow an authorization code to be >> used more than once in exchange for an access token. (Section 4.1.3) >> >> With this ambiguity, some authorization server implementations might >> allow authorization codes to be reused by the client (whether >> intentionally or not). I don't see any benefit in allowing this and >> think it should be forbidden for several reasons. >> >> Allowing this enables a scenario where an authorization code may be >> reused when the client should use the refresh token instead. The >> refresh token has more desirable security properties. >> >> The usefulness of authorization codes should be restricted wherever >> possible because they are revealed to resource owners and can be sent >> over unsecure connections when the client does not require TLS on its >> redirection URI. These properties combined with the possibility that >> the authorization code flow may be used by public clients might open >> more severe attack vectors. >> >> I think it should be clearly stated that the authorization server MUST >> NOT issue more than one access token per authorization code grant. An >> authorization code should be discarded after its first use and new >> access tokens should only be issued when exchanged for refresh tokens. >> >> >> 2. AUTHORIZATION CODE VS. TOKEN? >> >> Much less important, and please forgive me if this has already been >> discussed, but why isn't the authorization code called an >> authorization token? It is similar to the refresh token in that it can >> be presented in exchange for an access token at the token endpoint. I >> see it as another type of token and wonder if the language used should >> perhaps reflect that as well. >> >> >> 3. GRAMMAR CORRECTION IN SECTION 10.12 >> >> In Section 10.12 paragraph three it says "(e.g. a hash of the session >> cookie used to authentication the user-agent)." This should say >> "authenticate" instead of "authentication". >> >> Regards, >> Andre DeMarre > > From pmadsen@pingidentity.com Mon Sep 12 13:25: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 0AFF921F8D2D for ; Mon, 12 Sep 2011 13:25:42 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 690FuRNHfWRf for ; Mon, 12 Sep 2011 13:25:41 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6007721F8CAA for ; Mon, 12 Sep 2011 13:25:39 -0700 (PDT) Received: from mail-ew0-f42.google.com ([209.85.215.42]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKTm5rN6FCQ0jOaAcTM9Dz/+vZCCmfOHnJ@postini.com; Mon, 12 Sep 2011 13:27:45 PDT Received: by mail-ew0-f42.google.com with SMTP id 2so2209418ewy.15 for ; Mon, 12 Sep 2011 13:27:35 -0700 (PDT) Received: by 10.213.21.148 with SMTP id j20mr1645183ebb.18.1315859254604; Mon, 12 Sep 2011 13:27:34 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id z54sm20859250eef.2.2011.09.12.13.27.32 (version=SSLv3 cipher=OTHER); Mon, 12 Sep 2011 13:27:33 -0700 (PDT) Message-ID: <4E6E6B74.6000106@pingidentity.com> Date: Mon, 12 Sep 2011 16:28:36 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="------------020503060604020304070703" X-Mailman-Approved-At: Mon, 12 Sep 2011 13:27:38 -0700 Subject: [OAUTH-WG] Typo in Section 5.1 of 21 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, 12 Sep 2011 20:25:42 -0000 This is a multi-part message in MIME format. --------------020503060604020304070703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit scope OPTIONAL. The scope of the access request as described by Section 3.3 . presumably this should be 'access token' paul -- *Paul Madsen* *Ping Identity* www.pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *O:* 3033966209 *M:* 3038180185 *Email:* pmadsen@pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *Connect with Ping* Twitter: @pingidentity LinkedIn Group: Ping's Identity Cloud Facebook.com/pingidentitypage *Connect with me* Twitter: @paulmadsen connectid.blogspot.com --------------020503060604020304070703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
scope
         OPTIONAL.  The scope of the access request as described by
         Section 3.3.

presumably this should be 'access token'

paul
--

Paul Madsen

Ping Identity www.pingidentity.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

O: 3033966209   M: 3038180185


Email: pmadsen@pingidentity.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Connect with Ping

Twitter: @pingidentity

LinkedIn Group: Ping's Identity Cloud

Facebook.com/pingidentitypage

Connect with me

Twitter: @paulmadsen

connectid.blogspot.com
--------------020503060604020304070703-- From nivstein@gmail.com Mon Sep 12 13:59: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 D096421F8E34 for ; Mon, 12 Sep 2011 13:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 opZfZ1Lbl2VA for ; Mon, 12 Sep 2011 13:59:04 -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 3291221F8E26 for ; Mon, 12 Sep 2011 13:59:04 -0700 (PDT) Received: by qyk32 with SMTP id 32so2162731qyk.10 for ; Mon, 12 Sep 2011 14:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=0Tdep8PXbUVL8WOYtvgaPk9+wNkosm8QoZqKODI8jGY=; b=U6gCtkTgYB4k/4TM3lG5uGUgqgvG2qcBOCw1cbm08jp4U0exVJaRB5gOW2TkUfJAZF QJniG85J9oKuPElgxtWOnn26FsgsR2+Dn3gSajtXZAXPXXB47pq6R8PIBYOxjt9j+5Xm 0wuKpBMVyWfBF9zMzzOAiAs7OgPS4g4ALgHaE= Received: by 10.52.65.242 with SMTP id a18mr2300614vdt.341.1315861268067; Mon, 12 Sep 2011 14:01:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.29.207 with HTTP; Mon, 12 Sep 2011 14:00:48 -0700 (PDT) From: Niv Steingarten Date: Tue, 13 Sep 2011 00:00:48 +0300 Message-ID: To: OAuth WG Content-Type: text/plain; charset=UTF-8 Subject: [OAUTH-WG] Typos and language in -21 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, 12 Sep 2011 20:59:04 -0000 In section 10.12 (CSRF): 5th paragraph: "A CSRF attack against the against the authorization server's authorization endpoint" One "against the" is redundant. 4th paragraph: "The binding value enables the client to validate the validity of the request by matching the binding value to the user-agent's authenticated state." The phrase "validate the validity of the request" sounds a bit awkward in my opinion. I'd personally go with either "establish the validity of the request" or simply "validate the request". -- Niv From stephen.farrell@cs.tcd.ie Mon Sep 12 14:00: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 9BDA321F8E4A for ; Mon, 12 Sep 2011 14:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.761 X-Spam-Level: X-Spam-Status: No, score=-104.761 tagged_above=-999 required=5 tests=[AWL=1.838, 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 KjmuXWEwUH2t for ; Mon, 12 Sep 2011 14:00:35 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id B8CA721F8E48 for ; Mon, 12 Sep 2011 14:00:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B278A153582; Mon, 12 Sep 2011 22:02:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1315861353; bh=LK0bmPeyklxFtj ScFxmq3/lwAHb4EVPA+rcMi9XiS54=; b=4dt3AUJONkLITFRfwiC57o8tpscFdM Vqykzl1T1mCNYw+MpQpM8IgZd9auGJ+EThJmoQI5L1vYz+7Gp4XG2/B3OiY1vklD Mo4FMoMFebEf2+ATxRe/sxua/hnsbQ0vHRX5ddXuRTrG6VX3ZRO2NRt41DoZJ7VJ 6SeMzNAN0hbv5x7gcKcQFSRCa5JvajSnNmyMaJLJD9Zazam8Pav56g8WFxaAJyTd j/UlNAnJe0eu3kmtbdzIM3jWIEHb8X8MYSqgkRuXxGNdvD8fUPIps3q83TmUkeji yoSyEF3fOaI33v3+FTDM3ZKPtYYcv5YAPMVnU/pSqQ1swcFpmKZTV1NA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 2c32PRVpQmKm; Mon, 12 Sep 2011 22:02:33 +0100 (IST) Received: from [10.87.48.6] (unknown [86.41.7.243]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 015BA171C2B; Mon, 12 Sep 2011 22:02:31 +0100 (IST) Message-ID: <4E6E735D.3050806@cs.tcd.ie> Date: Mon, 12 Sep 2011 22:02:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "oauth@ietf.org" References: <4E6E4FEA.7090100@sunet.se> In-Reply-To: <4E6E4FEA.7090100@sunet.se> X-Forwarded-Message-Id: <4E6E4FEA.7090100@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Leif Johansson Subject: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 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, 12 Sep 2011 21:00:36 -0000 FYI, probably best for the WG to see/process these secdir comments as appropriate. I've not read 'em in detail myself yet, so as Leif says, feel free to react as appropriate. S. PS: Thanks Leif for reviewing this. -------- Original Message -------- Subject: secdir review of draft-ietf-oauth-v2 Date: Mon, 12 Sep 2011 20:31:06 +0200 From: Leif Johansson To: draft-ietf-oauth-v2@tools.ietf.org, secdir@ietf.org, iesg@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This review is rather lengthy. This should not be interpreted as anything beyond a desire to do a thorough review. It may well be that I have stumbled on things already covered on the list. If so I apologize and ask that you silently ignore such bits. Also I have included things that are not directly security related but that I found problematic for other reasons. The notes are presented in the order I wrote them down. ** General observations: POST and/or GET Examples are sometimes POST and sometimes GET. In many cases it is not clear to me from the surrounding text if both POST and GET are allowed or if only one is mandated. Illustrating with both a GET _and_ POST example in the cases where both are supported would help or make the method explicit in the text before the example. The P-word The term 'password' is sprinkled throughout the document, sometimes as in "client password" or "resource owner password credentials" and I suspect that sometimes it is password as in 'an example of a credential type' and in other cases it is password as in 'plain old password'. This needs to be cleared up throughout (I've included some examples below). Normative Language I've often found myself wanting more normative language often to replace existing but less precise text. I've called out some important cases below. Unknown parameters The sentence "The client SHOULD ignore unrecognized response parameters" occurs in several places. First of all I would argue that this has to be a MUST if you want to be able to guarantee extensibility. Secondly there are some error responses that are triggered by unsupported request parameters. This seems like an inconsistency. ** Specifics 1.1 Roles Forward references to the sections where the roles are defined would improve readability. As an illustration of an alternative model for the authorization server maybe an informative reference to UMA would be illustrative here. 1.2 Protocol Flow (A) talks about 'an intermediary such as an authorization server.' it isn't clear it me if this refers to a separate authorization server or if it is the same authorization server that is referenced in (B). 1.3.3 Resource Owner Password Credentials When I first read this I thought - why not talk about Resource Owner Credentials - in fact there is a parenthesis there "(e.g a username and password)" that seems to indicate that other credentials could be supported. This needs to be cleared up. Either its username and password and nothing else or there is a way to support things like Negotiate or X.509-based credentials in which case it should really be Resource Owner Credentials with no reference to passwords other than as as an example of one possible credential type. 1.4 Access Token first paragraph: "The string is usually opaque". This should be reformulated as normative language. In fact I would have liked guidance on generating those tokens (which has been brought up on the list) possibly as part of an implementation-guide. 1.5 Refresh Token Why is the refresh token not simply treated as an access token for the access token resource in the authorization server? This would seem to simplify the model a bit by removing a type of token whose semantic (at least to this reviewer) is a duplication of a normal access token for a particular type of resource. Also in the first paragraph: "(access tokens may have a shorter lifetime and fewer permissions". Why not try to write normative language here - there are security implications of allowing a refresh token to get more permissions (say) than the original access token. 2.1 Client types I find the terminology public/confidential somewhat counter-intuitive. An app you have on your personal device is 'public' while a shared cloud service is 'confidential'...hmm... This section also lacks normative language which isn't good. There should be language defining the behavior of public and confidential client aswell as the three profiles. For instance under native application we have "It is assumed that any client authentication credentials included in the application can be extracted". This should really be normative language. Some of what I am looking for can be found in section 2.3 but it isn't clear to me that it covers the definition of the profiles. 2.3.1 Client Password There is also some confusion here about what the client must implement and what the server must implement wrt the use of client_id. I read the text as trying to say that Servers SHOULD support both and clients SHOULD only do Basic. This section also seems to have been the product of a partial s/password/credential/g operation. Either OAUTH is only meant to use Basic and passwords or we want to cover all/most HTTP authentication methods and credentials and then section 2.3.2 (which feels like an afterthought) needs to get folded into 2.3.1 and the normative language (and examples!) need some work to cover at least X.509s and perhaps even Negotiate. Personally I would try to fold 2.3.1 and 2.3.2 into one section and say that servers MUST support Basic and client_id+client_password. Servers MAY support any HTTP authentication method with a mapping to client_id. If a client supports username+passwords it SHOULD do Basic and if it supports other HTTP authentication methods it MUST NOT use client_password for anything and MUST follow normal HTTP authentication method negotiation. Finally, everywhere there is negotiation there must imho be some mention/discussion/protection of downgrade attacks. 3.1 Authorization Endpoints 6th paragraph: "The authorization server SHOULD ignore unrecognized request parameters". This formulation returns in several places in the document and I don't understand why it isn't a MUST - after all doesn't extensibility depend on this? 3.1.1 Response Type The response_type parameter is REQURED but its absence SHOULD result in an error. Why not MUST? 3.1.2 Redirection Endpoint There should be a clear normative specification for how to match endpoints. There are traces of this in various parts of the document when matching is discussed. I recommend making a concise definition in one place (namely here) and referencing this throughout. Since this comparison has security implications it should be a priority for the specification to be air-tight. 3.1.2.2 Registration Requirements "(the client MAY use the state request parameter to achieve per-request customization)". Doesn't this overload its use for CSRF-protection? 3.1.2.4 Invalid Endpoint "The authorization server SHOULD NOT redirect...". Why isn't this a MUST NOT? 3.1.2.5 Endpoint Content This section basically seems to say "Serve with server-side code not with html or client-side code". If this is the case then I suggest reformulate to say precisely that using normative language. The use of the word "script" could perhaps also be made less ambiguous since in this case it could refer to both server-side code aswell as in-browser code. 3.2.1 Client Authentication The phrase "clients issued client credentials" could be rephrased to make less violence on English - perhaps "clients that have been issued with client credentials", unless that is not the intended meaning in which case I argue for something easier to understand ;-) The second bullet: Using client credentials more often also exposes them more which might be worth mentioning aswell. 4. Obtaining Authorization Perhaps not critical but the term 'password credentials' occurs in the first paragraph and this doesn't seem compatible with resource owner authentication being out of scope. It could just be that it should read 'resource owner credentials' but it could also signal an underlying assumption about username and password being used for resource owner authentication. In either case I thing its best to avoid the use of the word 'password' to avoid any confusion. 4.1 Authorization Code (C) - "using the redirection URI provided earlier" should perhaps read "using the redirection URI provided earlier or associated with the client in client registration" 4.1.1 and 4.1.2 Authorization Request/Authorization Response The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but there is no mention in 4.1.2 how to handle the case when the redirect_uri is not present. I believe the assumption is that the redirect_uri is either resent or part of client registration but that needs to be made explicit in that case. This may apply to other uses of the redirect_uri parameter eg in 4.2.1. Furthermore in 4.2.2 "code" I suggest the following re-formulatation of the last sentence: "The client MUST NOT use an authorization code for more than one request. If an authorization code is re-used, the authorization server should treat that as a replay attack and SHOULD revoke all tokens associated with the client." (i.e loose the "attempt" bit which carries no real meaning) Also note that this is potentially a DOS attack should a single authz code leak. 4.1.2.1 Error Response First paragraph, last sentence "and MUST NOT automatically redirect". In the light of how willing users normally are to click on links presented to them I would strengthen this to "MUST prevent the user from following the redirect URI" In the definition of the invalid_request parameter I don't understand how unsupported parameters can generate an error since endpoints should ignore unsupported parameters (in order to support extensibility). 4.1.3 Access Token Request "require client authentication for confidential clients or for any client issued client credentials (or with other authentication requirements)" This text seems unnecessarily convoluted. Isn't enough to say that if you have issued credentials to a client you MUST require authentication from that client? This applies equally to the other sections where client authentication is an issue (eg 4.3.2). Also cf my comment on 3.1.2 for the discussion of matching redirect_uri in the last bullet: ".. and that their values are identical". Is this really meant to mean identical? 4.2 Implicit Grant The parenthesis "(it does not support the issuance of refresh tokens)" sounds like it should really be normative language, "refresh tokens MUST NOT be issues for implicit grant" because afaiu you could easily extend "fragment-transport" to include a refresh-token, so it isn't a technically motivated constraint, right? In (D) I would like to have a normative reference to a document that specifies browser behavior for URL fragments since this is a critical security dependency for this grant type. 4.4 Client Credentials I think the text should note that this model effectively implies that the client is able to impersonate all users which has the potential for worse security problems than if the client has access to individual user passwords. 6 Refreshing an Access Token scope - The term "lesser than" is intuitive but imprecise. I suggest "MUST NOT include any scope not originally granted by the resource owner". 7.1 and 8.1 Access Token Types The section 7.1 lists two definitions of access token types and provides a couple of examples but doesn't provide any constraints on future development of access tokens except in 8.1 where it is implied that not all access token types would be associated with HTTP authentication mechanisms. Are there really no constraints on access token types that should be captured? 10.6 Authorization Code Redirection URI Manipulation Suggest replace the word 'familiar' with 'trusted' in the first sentence of the second paragraph. The notion of trust opens up several boat loads of worm but it is the correct term here I think. In the third paragraph "the same as" wrt redirection URIs occur and this needs to be defined (cf comments on 3.1.2 above). Finally "The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URI". I am missing a discussion of why the two types of client differ wrt this attack vector. 10.10 Credentials Guessing Attack I found myself wanting implementation advice for how to generate good tokens at this point. This has been raised on the list too. The same goes for how to generate good CSRF cookies where the "(eg a hash of the session cookie..." feels like it is implementation advice yearning to come out of the closet. Thats it. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5uT+YACgkQ8Jx8FtbMZncXQgCfZmTlzuESq0plfpkceQN1ontE a1QAoIEcg06GYK+6Fn4y40cTL1jQ+KmS =ox42 -----END PGP SIGNATURE----- From dilehn@gmail.com Mon Sep 12 14:16: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 BE76321F8C2D for ; Mon, 12 Sep 2011 14:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Ft1iaWOf+mpu for ; Mon, 12 Sep 2011 14:16:48 -0700 (PDT) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4D34D21F8B82 for ; Mon, 12 Sep 2011 14:16:45 -0700 (PDT) Received: by gxk28 with SMTP id 28so4175609gxk.27 for ; Mon, 12 Sep 2011 14:18:49 -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:content-type; bh=3QOhBlRpGyYTlMonxWMDkUNxzBeaK+2MoXfsCYTV0ik=; b=j8J4ndbpN2xSV4xPV4n02XgKdDh7FFHhtX5MRN6F7z3xoP7KgjqabEmgVK+IxfZFND p6p6NUJx6Fpv+fDrhkWinnPqWmRw1SBoTn5T4KoUV7wEvSE/fOf/B/MXbNjYYVNGBmYn RF6+umdFHXhxsUwDNahL/J3rxe0HKySP9NjMk= MIME-Version: 1.0 Received: by 10.42.189.70 with SMTP id dd6mr1421393icb.389.1315862329499; Mon, 12 Sep 2011 14:18:49 -0700 (PDT) Sender: dilehn@gmail.com Received: by 10.42.223.129 with HTTP; Mon, 12 Sep 2011 14:18:49 -0700 (PDT) Date: Mon, 12 Sep 2011 17:18:49 -0400 X-Google-Sender-Auth: KZ_CTU3gBGnkDNxSq4-75tW9xbA Message-ID: From: "David I. Lehn" To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Typos in Section 1.3.1 of -21 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, 12 Sep 2011 21:21:04 -0000 Section 1.3.1, last paragraph: - "the the" should be "the" - "user-agnet" should be "user-agent" -dave From colm.divilly@oracle.com Tue Sep 13 09:05: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 934AD21F8C45 for ; Tue, 13 Sep 2011 09:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 f8tCOPfo2Az6 for ; Tue, 13 Sep 2011 09:05:37 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 156E921F8C42 for ; Tue, 13 Sep 2011 09:05:37 -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 p8DG7fj3005052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Sep 2011 16:07:43 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 p8DG7e6w028160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Sep 2011 16:07:41 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8DG7YjL015798 for ; Tue, 13 Sep 2011 11:07:34 -0500 Received: from [141.144.10.84] (/141.144.10.84) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 09:07:34 -0700 Message-ID: <4E6F7FC3.1020600@oracle.com> Date: Tue, 13 Sep 2011 09:07:31 -0700 From: Colm Divilly User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 OracleBeehiveExtension/1.0.0.2-OracleInternal ObetStats/LAFCAT_1292347119411-757469839 Thunderbird/3.1.13 MIME-Version: 1.0 To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A020203.4E6F7FCF.0122,ss=1,re=0.000,fgs=0 Subject: [OAUTH-WG] Section 4.3. Resource Owner Password Credentials: Invalid Credentials Error Handling 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, 13 Sep 2011 16:05:37 -0000 Apologies if this has been covered before, a cursory search of the archives and issue tracker didn't turn up anything. What is the expected error response when performing a Resource Owner Password Credentials flow, if the resource owner provides incorrect credentials? From reading the spec it looks like the expectation is that a response like the following should be generated: HTTP/1.1 400 Bad Request Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "error":"invalid_request" } Which is not terribly helpful for a user-agent trying to determine that it is the user supplied credentials at fault (and therefore be able to re-prompt the user for credentials). Perhaps something like the following would be more useful: HTTP/1.1 400 Bad Request Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "error":"invalid_resource_owner_credentials" } A bit verbose perhaps, any alternative suggestions? Regards, Colm Divilly From greg@apigee.com Tue Sep 13 16:50: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 4B91521F8BF9 for ; Tue, 13 Sep 2011 16:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FFizuunYP9Ef for ; Tue, 13 Sep 2011 16:50:38 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE0721F8BE5 for ; Tue, 13 Sep 2011 16:50:37 -0700 (PDT) Received: by wyg24 with SMTP id 24so1109529wyg.31 for ; Tue, 13 Sep 2011 16:52:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.58.75 with SMTP id f11mr3097819wbh.106.1315957963880; Tue, 13 Sep 2011 16:52:43 -0700 (PDT) Received: by 10.227.156.3 with HTTP; Tue, 13 Sep 2011 16:52:43 -0700 (PDT) In-Reply-To: <4E6E735D.3050806@cs.tcd.ie> References: <4E6E4FEA.7090100@sunet.se> <4E6E735D.3050806@cs.tcd.ie> Date: Tue, 13 Sep 2011 16:52:43 -0700 Message-ID: From: Greg Brail To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 14 Sep 2011 04:34:05 -0700 Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 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, 13 Sep 2011 23:51:22 -0000 I would like to add my support to the comments below on section 2.3, specifically 2.3.1. It is clear to me from reading section 2.3 that clients MAY use HTTP basic, or they MAY include client_id and client_secret in the request body -- however, the latter is not recommended. It is not clear what the authorization server MUST support. IMHO, that leads us to a situation in which there is no universally-agreed set of authentication technology that all programmers can assume is going to work, which means that interoperability will be difficult as some authorization servers will support Basic, others will support the request body, and others will do neither in favor of something else. I would prefer that we make both HTTP basic AND the request body mechanisms in this section both required on the server side, thus giving the client the option of choosing one or the other. That would mean re-writing the beginning of section 2.3.1 as shown below. If I have missed other discussion on this topic I apologize. If there is already consensus to make the "message body" authentication optional rather than required for the authorization SERVER then I would still recommend that we make HTTP Basic a MUST in order to allow easier interop. Proposed change to 2.3.1: ---- The authorization server MUST support the HTTP Basic authentication scheme as defined in [RFC2617] as a way to identify clients. The client identifier is used as the username, and the client password is used as the password. For example (extra line breaks are for display purposes only): =A0 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Alternatively, the authorization server MUST also allow the client to include the=A0client credentials in the request body using the following parameters: =A0 client_id =A0 =A0 =A0 =A0 REQUIRED. =A0The client identifier issued to the client dur= ing =A0 =A0 =A0 =A0 the registration process described by Section 2.2. =A0 client_secret =A0 =A0 =A0 =A0 REQUIRED. =A0The client secret. =A0The client MAY omit the =A0 =A0 =A0 =A0 parameter if the client secret is an empty string. Clients in possession of a client password MAY use either mechanism in order to authenticate with the authorization server. However, including the client credentials in the request body using the two parameters is NOT RECOMMENDED, and should be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes). =A0(Rest of section remains as-is with the paragraph beginning "For example= ...") Gregory Brail=A0=A0 |=A0=A0 Technology=A0=A0 |=A0=A0 Apigee=A0=A0 | =A0=A0+= 1-650-937-9302 On Mon, Sep 12, 2011 at 2:02 PM, Stephen Farrell wrote: > > FYI, probably best for the WG to see/process these secdir > comments as appropriate. I've not read 'em in detail myself > yet, so as Leif says, feel free to react as appropriate. > > S. > > PS: Thanks Leif for reviewing this. > > -------- Original Message -------- > Subject: secdir review of draft-ietf-oauth-v2 > Date: Mon, 12 Sep 2011 20:31:06 +0200 > From: Leif Johansson > To: draft-ietf-oauth-v2@tools.ietf.org, secdir@ietf.org, iesg@ietf.org > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 > > Do not be alarmed. =A0I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents being > processed by the IESG. =A0These comments were written primarily > for the benefit of the security area directors. =A0Document editors > and WG chairs should treat these comments just like any other last > call comments. > > This review is rather lengthy. This should not be interpreted as > anything beyond a desire to do a thorough review. > > It may well be that I have stumbled on things already covered on the > list. If so I apologize and ask that you silently ignore such bits. > Also I have included things that are not directly security related > but that I found problematic for other reasons. > > The notes are presented in the order I wrote them down. > > ** General observations: > > POST and/or GET > > Examples are sometimes POST and sometimes GET. In many cases it is not > clear to me from the surrounding text if both POST and GET are allowed > or if only one is mandated. Illustrating with both a GET _and_ POST > example in the cases where both are supported would help or make the > method explicit in the text before the example. > > The P-word > > The term 'password' is sprinkled throughout the document, sometimes > as in "client password" or "resource owner password credentials" and > I suspect that sometimes it is password as in 'an example of a > credential type' and in other cases it is password as in 'plain old > password'. This needs to be cleared up throughout (I've included some > examples below). > > Normative Language > > I've often found myself wanting more normative language often to replace > existing but less precise text. I've called out some important cases > below. > > Unknown parameters > > The sentence "The client SHOULD ignore unrecognized response parameters" > occurs in several places. First of all I would argue that this has to > be a MUST if you want to be able to guarantee extensibility. Secondly > there are some error responses that are triggered by unsupported request > parameters. This seems like an inconsistency. > > ** Specifics > > 1.1 Roles > > Forward references to the sections where the roles are defined would > improve readability. > > As an illustration of an alternative model for the authorization server > maybe an informative reference to UMA would be illustrative here. > > 1.2 Protocol Flow > > (A) talks about 'an intermediary such as an authorization server.' it > isn't clear it me if this refers to a separate authorization server > or if it is the same authorization server that is referenced in (B). > > 1.3.3 Resource Owner Password Credentials > > When I first read this I thought - why not talk about Resource Owner > Credentials - in fact there is a parenthesis there "(e.g a username > and password)" that seems to indicate that other credentials could > be supported. > > This needs to be cleared up. Either its username and password and > nothing else or there is a way to support things like Negotiate or > X.509-based credentials in which case it should really be Resource > Owner Credentials with no reference to passwords other than as as > an example of one possible credential type. > > 1.4 Access Token > > first paragraph: "The string is usually opaque". This should be > reformulated as normative language. In fact I would have liked > guidance on generating those tokens (which has been brought up > on the list) possibly as part of an implementation-guide. > > 1.5 Refresh Token > > Why is the refresh token not simply treated as an access token > for the access token resource in the authorization server? This > would seem to simplify the model a bit by removing a type of > token whose semantic (at least to this reviewer) is a duplication > of a normal access token for a particular type of resource. > > Also in the first paragraph: "(access tokens may have a shorter > lifetime and fewer permissions". Why not try to write normative > language here - there are security implications of allowing > a refresh token to get more permissions (say) than the original > access token. > > 2.1 Client types > > I find the terminology public/confidential somewhat counter-intuitive. > An app you have on your personal device is 'public' while a shared > cloud service is 'confidential'...hmm... > > This section also lacks normative language which isn't good. There > should be language defining the behavior of public and confidential > client aswell as the three profiles. > > For instance under native application we have "It is assumed that > any client authentication credentials included in the application > can be extracted". This should really be normative language. Some > of what I am looking for can be found in section 2.3 but it isn't > clear to me that it covers the definition of the profiles. > > 2.3.1 Client Password > > There is also some confusion here about what the client must implement > and what the server must implement wrt the use of client_id. I read the > text as trying to say that Servers SHOULD support both and clients SHOULD > only do Basic. > > This section also seems to have been the product of a partial > s/password/credential/g operation. Either OAUTH is only meant to use > Basic and passwords or we want to cover all/most HTTP authentication > methods and credentials and then section 2.3.2 (which feels like an > afterthought) needs to get folded into 2.3.1 and the normative language > (and examples!) need some work to cover at least X.509s and perhaps > even Negotiate. > > Personally I would try to fold 2.3.1 and 2.3.2 into one section and say > that servers MUST support Basic and client_id+client_password. Servers > MAY support any HTTP authentication method with a mapping to client_id. > If a client supports username+passwords it SHOULD do Basic and if it > supports other HTTP authentication methods it MUST NOT use > client_password for anything and MUST follow normal HTTP authentication > method negotiation. > > Finally, everywhere there is negotiation there must imho be some > mention/discussion/protection of downgrade attacks. > > 3.1 Authorization Endpoints > > 6th paragraph: "The authorization server SHOULD ignore unrecognized > request parameters". This formulation returns in several places in the > document and I don't understand why it isn't a MUST - after all doesn't > extensibility depend on this? > > 3.1.1 Response Type > > The response_type parameter is REQURED but its absence SHOULD result in > an error. Why not MUST? > > 3.1.2 Redirection Endpoint > > There should be a clear normative specification for how to =A0match > endpoints. There are traces of this in various parts of the document > when matching is discussed. I recommend making a concise definition > in one place (namely here) and referencing this throughout. Since > this comparison has security implications it should be a priority > for the specification to be air-tight. > > 3.1.2.2 Registration Requirements > > "(the client MAY use the state request parameter to achieve per-request > customization)". Doesn't this overload its use for CSRF-protection? > > 3.1.2.4 Invalid Endpoint > > "The authorization server SHOULD NOT redirect...". Why isn't this a > MUST NOT? > > 3.1.2.5 Endpoint Content > > This section basically seems to say "Serve with server-side code not > with html or client-side code". If this is the case then I suggest > reformulate to say precisely that using normative language. > > The use of the word "script" could perhaps also be made less ambiguous > since in this case it could refer to both server-side code aswell as > in-browser code. > > 3.2.1 Client Authentication > > The phrase "clients issued client credentials" could be rephrased to > make less violence on English - perhaps "clients that have been issued > with client credentials", unless that is not the intended meaning in > which case I argue for something easier to understand ;-) > > The second bullet: Using client credentials more often also exposes them > more which might be worth mentioning aswell. > > 4. Obtaining Authorization > > Perhaps not critical but the term 'password credentials' occurs in the > first paragraph and this doesn't seem compatible with resource owner > authentication being out of scope. It could just be that it should read > 'resource owner credentials' but it could also signal an underlying > assumption about username and password being used for resource owner > authentication. In either case I thing its best to avoid the use of the > word 'password' to avoid any confusion. > > 4.1 Authorization Code > > (C) - "using the redirection URI provided earlier" should perhaps read > "using the redirection URI provided earlier or associated with the > client in client registration" > > > 4.1.1 and 4.1.2 Authorization Request/Authorization Response > > The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but > there is no mention in 4.1.2 how to handle the case when the > redirect_uri is not present. I believe the assumption is that the > redirect_uri is either resent or part of client registration but that > needs to be made explicit in that case. > > This may apply to other uses of the redirect_uri parameter eg in 4.2.1. > > Furthermore in 4.2.2 "code" I suggest the following re-formulatation of > the last sentence: "The client MUST NOT use an authorization code for > more than one request. If an authorization code is re-used, the > authorization server should treat that as a replay attack and SHOULD > revoke all tokens associated with the client." (i.e loose the "attempt" > bit which carries no real meaning) > > Also note that this is potentially a DOS attack should a single authz > code leak. > > 4.1.2.1 Error Response > > First paragraph, last sentence "and MUST NOT automatically redirect". In > the light of how willing users normally are to click on links presented > to them I would strengthen this to "MUST prevent the user from following > the redirect URI" > > In the definition of the invalid_request parameter I don't understand > how unsupported parameters can generate an error since endpoints should > ignore unsupported parameters (in order to support extensibility). > > 4.1.3 Access Token Request > > "require client authentication for confidential clients or for any > client issued client credentials (or with other authentication > requirements)" > > This text seems unnecessarily convoluted. Isn't enough to say that if > you have issued credentials to a client you MUST require authentication > from that client? This applies equally to the other sections where > client authentication is an issue (eg 4.3.2). > > Also cf my comment on 3.1.2 for the discussion of matching redirect_uri > in the last bullet: ".. and that their values are identical". Is this > really meant to mean identical? > > 4.2 Implicit Grant > > The parenthesis "(it does not support the issuance of refresh tokens)" > sounds like it should really be normative language, "refresh tokens > MUST NOT be issues for implicit grant" because afaiu you could easily > extend "fragment-transport" to include a refresh-token, so it isn't > a technically motivated constraint, right? > > In (D) I would like to have a normative reference to a document that > specifies browser behavior for URL fragments since this is a critical > security dependency for this grant type. > > 4.4 Client Credentials > > I think the text should note that this model effectively implies > that the client is able to impersonate all users which has the potential > for worse security problems than if the client has access to individual > user passwords. > > 6 Refreshing an Access Token > > scope - The term "lesser than" is intuitive but imprecise. I suggest > "MUST NOT include any scope not originally granted by the resource owner"= . > > 7.1 and 8.1 Access Token Types > > The section 7.1 lists two definitions of access token types and provides > a couple of examples but doesn't provide any constraints on future > development of access tokens except in 8.1 where it is implied that not > all access token types would be associated with HTTP authentication > mechanisms. Are there really no constraints on access token types > that should be captured? > > 10.6 Authorization Code Redirection URI Manipulation > > Suggest replace the word 'familiar' with 'trusted' in the first sentence > of the second paragraph. The notion of trust opens up several boat loads > of worm but it is the correct term here I think. > > In the third paragraph "the same as" wrt redirection URIs occur and > this needs to be defined (cf comments on 3.1.2 above). > > Finally "The authorization server MUST require public clients and SHOULD > require confidential clients to register their redirection URI". I am > missing a discussion of why the two types of client differ wrt this > attack vector. > > 10.10 Credentials Guessing Attack > > I found myself wanting implementation advice for how to generate good > tokens at this point. This has been raised on the list too. The same > goes for how to generate good CSRF cookies where the "(eg a hash of the > session cookie..." feels like it is implementation advice yearning to > come out of the closet. > > > Thats it. > > =A0 =A0 =A0 =A0Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk5uT+YACgkQ8Jx8FtbMZncXQgCfZmTlzuESq0plfpkceQN1ontE > a1QAoIEcg06GYK+6Fn4y40cTL1jQ+KmS > =3Dox42 > -----END PGP SIGNATURE----- > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From greg@apigee.com Tue Sep 13 16:22: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 77B9321F8B58 for ; Tue, 13 Sep 2011 16:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, 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 g7AnVzAvTAH3 for ; Tue, 13 Sep 2011 16:22:59 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B945921F8B57 for ; Tue, 13 Sep 2011 16:22:58 -0700 (PDT) Received: by wyg24 with SMTP id 24so1095554wyg.31 for ; Tue, 13 Sep 2011 16:25:05 -0700 (PDT) Received: by 10.227.10.139 with SMTP id p11mr169065wbp.61.1315956305553; Tue, 13 Sep 2011 16:25:05 -0700 (PDT) From: Greg Brail MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxybF9R2lxnY4gAQ9mG3bxIvG1BJA== Date: Tue, 13 Sep 2011 16:25:06 -0700 Message-ID: <63404c9b49bccfbff551bb973679b77d@mail.gmail.com> To: oauth@ietf.org Content-Type: multipart/alternative; boundary=002215974dfa21e9f904acdaf4be X-Mailman-Approved-At: Wed, 14 Sep 2011 04:34:05 -0700 Subject: [OAUTH-WG] Nit: Language in section 1.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: Tue, 13 Sep 2011 23:51:58 -0000 --002215974dfa21e9f904acdaf4be Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This part of section 1.1 is confusing to me and I stumble whenever I read i= t =96 I see that Brian Eaton suggested looking at it a while back but I don= =92t think it got changed: =93OAuth includes four roles working together to grant and provide access to protected resources - access restricted resources requiring authentication:=94 I would suggest something simpler, such as: =93OAuth includes four roles that work together to grant and provide access= to protected resources that require authentication.=94 Gregory Brail | Technology | Apigee | +1-650-937-9302 --002215974dfa21e9f904acdaf4be Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

This part of section 1.1 is confusing to me an= d I stumble whenever I read it =96 I see that Brian Eaton suggested looking= at it a while back but I don=92t think it got changed:

=A0

=93OAuth includes four roles working together to = grant and provide

=A0=A0 access to protected resources - access restricted resources re= quiring

=A0=A0 authentication:=94

=A0

I would suggest something simple= r, such as:

=A0

=93OAuth includes four roles that work together t= o grant and provide access to protected resources that require authenticati= on.=94

=A0

=A0

Gregory Brail=A0=A0 |=A0=A0 Technology=A0= =A0 |=A0=A0 Apigee=A0=A0 |=A0=A0 +1-650-937-9302

=A0

--002215974dfa21e9f904acdaf4be-- From jricher@mitre.org Wed Sep 14 06:03: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 0942F21F8CC2 for ; Wed, 14 Sep 2011 06:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 W5wK5jFKYL8q for ; Wed, 14 Sep 2011 06:03:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8A19C21F8C99 for ; Wed, 14 Sep 2011 06:03:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4667921B0BED; Wed, 14 Sep 2011 09:05:16 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3ECE621B0A65; Wed, 14 Sep 2011 09:05:16 -0400 (EDT) Received: from [129.83.50.1] (129.83.31.55) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server id 14.1.270.1; Wed, 14 Sep 2011 09:05:15 -0400 From: Justin Richer To: Greg Brail In-Reply-To: <63404c9b49bccfbff551bb973679b77d@mail.gmail.com> References: <63404c9b49bccfbff551bb973679b77d@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 14 Sep 2011 09:04:05 -0400 Message-ID: <1316005445.9516.35.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 8bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Nit: Language in section 1.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: Wed, 14 Sep 2011 13:03:10 -0000 +1, this wording is much clearer to me, too -- justin On Tue, 2011-09-13 at 19:25 -0400, Greg Brail wrote: > This part of section 1.1 is confusing to me and I stumble whenever I > read it – I see that Brian Eaton suggested looking at it a while back > but I don’t think it got changed: > > > > “OAuth includes four roles working together to grant and provide > > access to protected resources - access restricted resources > requiring > > authentication:†> > > > I would suggest something simpler, such as: > > > > “OAuth includes four roles that work together to grant and provide > access to protected resources that require authentication.†> > > > > > Gregory Brail | Technology | Apigee | +1-650-937-9302 > > > > From torsten@lodderstedt.net Wed Sep 14 06: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 3413321F8BC5 for ; Wed, 14 Sep 2011 06:48:33 -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 2RhC+60Cz8Uj for ; Wed, 14 Sep 2011 06:48:32 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3A53921F8B9D for ; Wed, 14 Sep 2011 06:48:31 -0700 (PDT) Received: from [80.67.16.112] (helo=webmail.df.eu) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1R3prL-0004p6-8R; Wed, 14 Sep 2011 15:50:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 14 Sep 2011 15:50:39 +0200 From: Torsten Lodderstedt To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D0@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> <4E514770.7040405@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail/0.5.2 X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= 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: Wed, 14 Sep 2011 13:48:33 -0000 Hi Eran, >> 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. >A textbook CSRF attack is when an attacker constructs a URI and then > manipulate a user-agent with an active session to call that. In the > simplest example, an >attacker constructs a URI that transfers a > million dollars from the current account to its, then tricks the user > to click on that link or automatically >redirects the user to that URI. > Because the user is already signed in and has an active session token, > the request goes through. >To prevent it, the request URI must include an artifact that binds the > request to the active session. Since the attacker has no way of > accessing the session >information, it cannot construct as a URI. In > practice, this means adding a hidden form parameter to the button with > some hash of the session information >that the server can verify. So I would conclude we have the same understanding of what CSRF means. >> 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. >Of course it matters. >The only way the attacker can get access is by calling the 'I agree' > button action via an active user session. The attacker cannot access > the hidden form >value with the session hash (or whatever the server is > using for CSRF protection). So whatever URI it constructs will not work > when called with the active >user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and "just" uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. >> 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. >I'm having a hard time following all these scenarios. But the > important part is that OAuth assumes the 'user-agent' is a compliant > and secure web browser. If >the user-agent does not enforce cookie > boundaries, XSS, CORS policy, etc. there isn't much we can do. In other > words, if the user installs a poorly design >native application which > has its own user-agent implementation opened to known web attacks, all > bets are off. > >The security model behind all these is pretty simple. The active user > session has to be protected from any external access by attackers and > enforce same-origin policy. What didn't you understand? I would be happy to improve my description. What I basically try to get across: a malicious piece of software running on the resource owners device can simulate her consent. As a pre-requisite the attacker must be able to either abuse an existing session or to create a new one. I gave four examples of how this could be achieved. At least the last has obviously nothing to do with browser security features. The threat also has nothing to do with poor design or user-agent implementation flaws. It is a deliberate attack against the resource owner. One could argue that prevention of malicous software is not the responsibility of the authz server. I could agree with that. But people seem to expect an OAuth authz server to cope with such attacks. That's why I believe we either clearly draw this boundary in the spec or give a hint on how to prevent this kind of threat. regards, Torsten. >I still don't see the need to add the proposed section. >EHL From eran@hueniverse.com Wed Sep 14 06:59: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 D77A721F8C12 for ; Wed, 14 Sep 2011 06:59: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 fS65lLGdEjJ9 for ; Wed, 14 Sep 2011 06:59: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 EEF9E21F8C10 for ; Wed, 14 Sep 2011 06:59:55 -0700 (PDT) Received: (qmail 20827 invoked from network); 14 Sep 2011 14:02:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Sep 2011 14:02:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 14 Sep 2011 07:01:53 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Wed, 14 Sep 2011 06:59:47 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: Acxy5Uxqq4O01wZBTpW3AoKm4C137AAARjzg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D9237C@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> <4E514770.7040405@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D0@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: Wed, 14 Sep 2011 13:59:56 -0000 SXMgdGhpcyBtYWxpY2lvdXMgcGllY2Ugb2Ygc29mdHdhcmUgZXh0ZXJuYWwgYSBuYXRpdmUgYXBw bGljYXRpb24gZWl0aGVyIHBhc3Qgb2YgYSBuYXRpdmUgY2xpZW50IG9yIGV4dGVybmFsIHRvIHRo ZSBicm93c2VyPw0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdDQo+ IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDE0LCAyMDExIDY6NTEgQU0NCj4gVG86IEVyYW4g SGFtbWVyLUxhaGF2DQo+IENjOiBOaXYgU3RlaW5nYXJ0ZW47IG9hdXRoQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJFOiBbT0FVVEgtV0ddIERyYWZ0IDIwIGxhc3QgY2FsbCBjb21tZW50IChSZXNvdXJj ZSBPd25lcg0KPiBJbXBlcnNvbmF0aW9uKQ0KPiANCj4gSGkgRXJhbiwNCj4gDQo+ID4+IEFzIGZh ciBhcyBJIHVuZGVyc3Rvb2QsIGluIGEgdGV4dGJvb2sgQ1NSRiBhdHRhY2sgdGhlIGF0dGFja2Vy IHdvdWxkDQo+ID4+IGNyZWF0ZSBoaXMgb3duIHJlcXVlc3RzIGluIG9yZGVyIHRvIGFidXNlIGEg dXNlcidzIHNlc3Npb24uIFRoaXMgY2FuDQo+ID4+IGJlIHByZXZlbnRlZCBieSB1dGlsaXppbmcg c3RhbmRhcmQgQ1NSRiBjb3V0ZXJtZWFzdXJlcyAocGFnZSB0b2tlbiwNCj4gPj4gbm91bmNlLCBz aWduYXR1cmUgYXMgcGFyYW1ldGVyIG9uIGV2ZXJ5IHJlcXVlc3QgVVJMKSwgd2hpY2ggYmluZCBV UkxzDQo+ID4+IHRvIGEgY2VydGFpbiBzZXNzaW9uLg0KPiANCj4gPkEgdGV4dGJvb2sgQ1NSRiBh dHRhY2sgaXMgd2hlbiBhbiBhdHRhY2tlciBjb25zdHJ1Y3RzIGEgVVJJIGFuZCB0aGVuDQo+ID5t YW5pcHVsYXRlIGEgdXNlci1hZ2VudCB3aXRoIGFuIGFjdGl2ZSBzZXNzaW9uIHRvIGNhbGwgdGhh dC4gSW4gdGhlDQo+ID5zaW1wbGVzdCBleGFtcGxlLCBhbiA+YXR0YWNrZXIgY29uc3RydWN0cyBh IFVSSSB0aGF0IHRyYW5zZmVycyBhDQo+ID5taWxsaW9uIGRvbGxhcnMgZnJvbSB0aGUgY3VycmVu dCBhY2NvdW50IHRvIGl0cywgdGhlbiB0cmlja3MgdGhlIHVzZXINCj4gPnRvIGNsaWNrIG9uIHRo YXQgbGluayBvciBhdXRvbWF0aWNhbGx5ID5yZWRpcmVjdHMgdGhlIHVzZXIgdG8gdGhhdCBVUkku DQo+ID4gQmVjYXVzZSB0aGUgdXNlciBpcyBhbHJlYWR5IHNpZ25lZCBpbiBhbmQgaGFzIGFuIGFj dGl2ZSBzZXNzaW9uIHRva2VuLA0KPiA+dGhlIHJlcXVlc3QgZ29lcyB0aHJvdWdoLg0KPiANCj4g PlRvIHByZXZlbnQgaXQsIHRoZSByZXF1ZXN0IFVSSSBtdXN0IGluY2x1ZGUgYW4gYXJ0aWZhY3Qg dGhhdCBiaW5kcyB0aGUNCj4gPnJlcXVlc3QgdG8gdGhlIGFjdGl2ZSBzZXNzaW9uLiBTaW5jZSB0 aGUgYXR0YWNrZXIgaGFzIG5vIHdheSBvZg0KPiA+YWNjZXNzaW5nIHRoZSBzZXNzaW9uID5pbmZv cm1hdGlvbiwgaXQgY2Fubm90IGNvbnN0cnVjdCBhcyBhIFVSSS4gSW4NCj4gPnByYWN0aWNlLCB0 aGlzIG1lYW5zIGFkZGluZyBhIGhpZGRlbiBmb3JtIHBhcmFtZXRlciB0byB0aGUgYnV0dG9uIHdp dGgNCj4gPnNvbWUgaGFzaCBvZiB0aGUgc2Vzc2lvbiBpbmZvcm1hdGlvbiA+dGhhdCB0aGUgc2Vy dmVyIGNhbiB2ZXJpZnkuDQo+IA0KPiBTbyBJIHdvdWxkIGNvbmNsdWRlIHdlIGhhdmUgdGhlIHNh bWUgdW5kZXJzdGFuZGluZyBvZiB3aGF0IENTUkYgbWVhbnMuDQo+IA0KPiA+PiBCdXQgd2h5IHNo b3VsZCB0aGUgYXR0YWNrZXIgY3JlYXRlIHJlcXVlc3RzIGV0IGFsbD8gQWxsIGhlIG5lZWRzIGlz DQo+ID4+IGFscmVhZHkgcHJvdmlkZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRoZW1z ZWx2ZXMuIFRoZQ0KPiA+PiBtYWxpY2lvdXMgY2xpZW50IGNhbiBkb3dubG9hZCB0aGUgSFRNTCBw YWdlcyBjb21wcmlzaW5nIHRoZQ0KPiA+PiBhdXRob3JpemF0aW9uIGZsb3cgZnJvbSB0aGUgYXV0 aHogc2VydmVyIGFuZCB1c2UgdGhlIGVtYmVkZGVkIFVSTHMgdG8NCj4gPj4gaXNzdWUgdGhlIHJl cXVlc3RzIHdoaWNoIG5vcm1hbHkgd291bGQgaGF2ZSBiZWVuIGlzc3VlZCBieSB0aGUNCj4gPj4g cmVzb3VyY2Ugb3duZXIgaGVyc2VsZiAodXNpbmcgdGhlIHVzZSBhZ2VudCBpbmRlZWQpLiBJdCdz IG1vcmUgb3INCj4gPj4gbGVzcyB0aGUgcHVzaCBvbiBhICJJIGFncmVlIg0KPiA+PiBidXR0b24g d2UgYXJlIHRhbGtpbmcgYWJvdXQuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBtYXkgYWRkIGEg cGFnZQ0KPiA+PiB0b2tlbiB0byB0aGUgcmVzcGVjdGl2ZSBmb3JtIFVSTC4gQnV0IGl0IGRvZXMg bm90IG1hdHRlciBzaW5jZSB0aGUNCj4gPj4gY2xpZW50IGp1c3QgdXNlcyB0aGUgYXV0aHogc2Vy dmVyIG1hbnVmYWN0dXJlZCBVUkwgdG8gcG9zdCB0aGUgZm9ybS4NCj4gDQo+ID5PZiBjb3Vyc2Ug aXQgbWF0dGVycy4NCj4gDQo+ID5UaGUgb25seSB3YXkgdGhlIGF0dGFja2VyIGNhbiBnZXQgYWNj ZXNzIGlzIGJ5IGNhbGxpbmcgdGhlICdJIGFncmVlJw0KPiA+IGJ1dHRvbiBhY3Rpb24gdmlhIGFu IGFjdGl2ZSB1c2VyIHNlc3Npb24uIFRoZSBhdHRhY2tlciBjYW5ub3QgYWNjZXNzDQo+ID50aGUg aGlkZGVuIGZvcm0gPnZhbHVlIHdpdGggdGhlIHNlc3Npb24gaGFzaCAob3Igd2hhdGV2ZXIgdGhl IHNlcnZlciBpcw0KPiA+dXNpbmcgZm9yIENTUkYgcHJvdGVjdGlvbikuIFNvIHdoYXRldmVyIFVS SSBpdCBjb25zdHJ1Y3RzIHdpbGwgbm90IHdvcmsNCj4gPndoZW4gY2FsbGVkIHdpdGggdGhlIGFj dGl2ZSA+dXNlciBzZXNzaW9uLg0KPiANCj4gTXkgcG9pbnQgaXM6IHRoZSBhdHRhY2tlciBpbiB0 aGUgdGhyZWF0IEknbSB0cnlpbmcgdG8gZGVzY3JpYmUgZG9lcyBub3QgbmVlZCB0bw0KPiBjcmVh dGUgYW55IFVSTCBzaW5jZSBpdCBqdXN0IHJlbW90ZSBjb250cm9scyB0aGUgdXNlci1hZ2VudC4g VGhlIG1hbGljb3VzDQo+IGNvZGUgcnVucyBvdXRzaWRlIG9mIHRoZSBicm93c2VyIGFuZCAianVz dCIgdXNlcyB0aGUgVVJMcyBwcm92aWRlZCBieSB0aGUNCj4gYXV0aHogc2VydmVyLiBZZXMsIHRo ZXJlIG5lZWQgdG8gYmUgYSBzZXNzaW9uLiBObywgdGhlIGF0dGFja2VyIGRvZXMgbm90DQo+IG5l ZWQgdG8gaW5qZWN0IGFueSBVUkwgaGUgbWFkZSB1cC4NCj4gDQo+ID4+IFNvIGxldCdzIGFzc3Vt ZSB0aGUgYXR0YWNrZXIgaGFzIHRvIHByb2dyYW1tYXRpY2FsbHkgaGFuZGxlIEhUTUwNCj4gPj4g Zm9ybXMgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRlbGl2ZXJzIHRvIHRoZSB1c2VyIGFnZW50 LiBBcyB5b3UNCj4gPj4gY29ycmVjdGx5IHBvaW50ZWQgb3V0LCB0aGUgcHJlLXJlcXVpc2l0ZSBm b3Igc3VjaCBhbiBhdHRhY2sgdG8NCj4gPj4gc3VjY2VlZCBpcyB0aGF0IHRoZSByZXNvdXJjZSBv d25lciBtdXN0IGJlIGF1dGhlbnRpY2F0ZWQgc29tZWhvdywNCj4gPj4gZS5nLiBiYXNlZCBvbiBh IHNlc3Npb24gY29va2llLiBXaGljaCBhbHNvIG1lYW5zLCB3ZSBhcmUgdGFsa2luZw0KPiA+PiBh Ym91dCBjbGllbnRzIHJ1bm5pbmcgb24gdGhlIHZpY3RpbSdzIGRldmljZSwgd2l0aGluIHRoZSB1 c2VyIGFnZW50DQo+ID4+IG9yIGFzIG5hdGl2ZSBhcHAuDQo+ID4+DQo+ID4+IEkgc2VlIHRoZSBm b2xsb3dpbmcgcG9zc2libGUgc2NlbmFyaW9zOg0KPiA+Pg0KPiA+PiAxKSBleHRlcm5hbCBzeXN0 ZW0gYnJvd3NlciAtIFRoZSBhcHAgY291bGQgdXRpbGl6ZSBhbiBleGlzdGluZw0KPiA+PiBzZXNz aW9uIHdpdGhpbiB0aGUgc3lzdGVtIGJyb3dzZXIgb24gdGhlIHZpY3RpbSdzIGRldmljZS4gSXQg Y291bGQNCj4gPj4gdGhlbiByZW1vdGUgY29udHJvbCBhIGJyb3dzZXIgd2luZG93LCBlLmcuIHVz aW5nIGxvdy1sZXZlbCBvcGVyYXRpbmcNCj4gPj4gc3lzdGVtIG1lc3NhZ2VzICgic2VuZCBtb3Vz ZSBjbGljayIpIG9yIGNvbXBvbmVudCB0ZWNobmlxdWVzIHN1Y2ggYXMNCj4gPj4gQWN0aXZlWC4g VGhlcmUgYXJlIHRvb2xzIGF2YWlsYWJsZSB0byBjcmVhdGUgbWFjcm9zIHdoaWNoDQo+ID4+IGF1 dG9tYXRpY2FsbHkgY29udHJvbCBhbmQgb2J0YWluIGRhdGEgZnJvbSBzdWNoIGFwcGxpY2F0aW9u cy4gU28gdGhpcw0KPiA+PiBzaG91bGQgYmUgZmVhc2libGUuDQo+ID4+DQo+ID4+IDIpIGludGVy bmFsIGJyb3dzZXIgKGNyb3NzLWJyb3dzZXIgY29va2llcykgLSBJZiB0aGUgYXV0aG9yaXphdGlv bg0KPiA+PiBzZXJ2ZXIgdXNlcyBjcm9zcy1icm93c2VyIGNvb2tpZSB0ZWNobmlxdWVzLCBzdWNo IGFzIGZsYXNoIGNvb2tpZXMsDQo+ID4+IHRoZSBhdHRhY2tlciBjb3VsZCBpbnN0YW50aWF0ZSBh biBpbnRlcm5hbCAoaW52aXNpYmxlKSBicm93c2VyIGFuZA0KPiA+PiB0cnkgdG8gdXRpbGl6ZSBh IHNlc3Npb24gYXNzb2NpYXRlZCB3aXRoIHN1Y2ggYSBjb29raWUuIEkgYXNzdW1lDQo+ID4+IGNv bnRyb2xsaW5nIHN1Y2ggYSBicm93c2VyIGluc3RhbmNlIHdpbGwgYmUgZXZlbiBzaW1wbGVyIHRo ZW4gaW4gKDEpLg0KPiA+Pg0KPiA+PiAzKSBpbnRlcm5hbCBicm93c2VyIChzaWxlbnQgYXV0aHog ZmxvdykgLSBUaGlzIGlzIGEgc2NlbmFyaW8gd2hlcmUNCj4gPj4gdGhlIGF0dGFja2VyIGlzIHVu YWJsZSB0byBhYnVzZSBhbiBleGlzdGluZyBzZXNzaW9uIG9uIHRoZSBkZXZpY2UuIEl0DQo+ID4+ IGNvdWxkIGluc3RlYWQgY3JlYXRlIGFuIGludGVybmFsIGJyb3dzZXIgYW5kIHBlcmZvcm0gYW4g YXV0aG9yaXphdGlvbg0KPiA+PiBmbG93IHdpdGggdGhlIHJlc291cmNlIG93bmVyIGZvciBvbmUg cGFydGljdWxhciBzY29wZS4gVXNpbmcgdGhlIHNhbWUNCj4gPj4gYnJvd3NlciBpbnN0YW5jZSBh bmQgYmFzZWQgb24gdGhlIGNvb2tpZXMgb2J0YWluZWQgaW4gdGhlIGZpcnN0IHJ1biwNCj4gPj4g aXQgY291bGQgc2lsZW50bHkgcGVyZm9ybSBhZGRpdGlvbmFsIGF1dGhvcml6YXRpb24gZmxvd3Mg Zm9yIG90aGVyDQo+ID4+IHNjb3Blcy4NCj4gPj4NCj4gPj4gNCkgaW50ZXJuYWwgYnJvd3NlciAo bm9uLWludGVyYWN0aXZlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMpIC0gVGhlcmUNCj4gPj4gYXJl IGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgYXZhaWxhYmxlIHcvbyB0aGUgbmVlZCBmb3INCj4gPj4g dXNlci1pbnRlcmFjdGlvbiwgZm9yIGV4YW1wbGVzIFNJTSBjYXJkIGF1dGhlbnRpY2F0aW9uIG9y DQo+ID4+IGNlcnRpZmljYXRlLWJhc2VkIGF1dGhlbnRpY2F0aW9uLg0KPiA+PiBUaGUgYXR0YWNr ZXIgY291bGQgdXRpbGl6ZSBhbiBpbnRlcm5hbCwgaW52aXNpYmxlIGJyb3dzZXIgaW5zdGFuY2Ug aW4NCj4gPj4gY29tYmluYXRpb24gd2l0aCBzdWNoIGFuIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBp biBvcmRlciB0byBwZXJmb3JtDQo+ID4+IHRoZSBhdXRob3JpemF0aW9uIHByb2Nlc3MuDQo+ID4+ DQo+ID4+IEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSBzY2VuYXJpb3MgZGVzY3JpYmVkIGFib3Zl IGNhbiBiZSBjbGFzc2lmaWVkDQo+ID4+IGFzIENTUkYuDQo+IA0KPiA+SSdtIGhhdmluZyBhIGhh cmQgdGltZSBmb2xsb3dpbmcgYWxsIHRoZXNlIHNjZW5hcmlvcy4gQnV0IHRoZQ0KPiA+aW1wb3J0 YW50IHBhcnQgaXMgdGhhdCBPQXV0aCBhc3N1bWVzIHRoZSAndXNlci1hZ2VudCcgaXMgYSBjb21w bGlhbnQNCj4gPmFuZCBzZWN1cmUgd2ViIGJyb3dzZXIuIElmID50aGUgdXNlci1hZ2VudCBkb2Vz IG5vdCBlbmZvcmNlIGNvb2tpZQ0KPiA+Ym91bmRhcmllcywgWFNTLCBDT1JTIHBvbGljeSwgZXRj LiB0aGVyZSBpc24ndCBtdWNoIHdlIGNhbiBkby4gSW4gb3RoZXINCj4gPndvcmRzLCBpZiB0aGUg dXNlciBpbnN0YWxscyBhIHBvb3JseSBkZXNpZ24gPm5hdGl2ZSBhcHBsaWNhdGlvbiB3aGljaA0K PiA+aGFzIGl0cyBvd24gdXNlci1hZ2VudCBpbXBsZW1lbnRhdGlvbiBvcGVuZWQgdG8ga25vd24g d2ViIGF0dGFja3MsIGFsbA0KPiA+YmV0cyBhcmUgb2ZmLg0KPiA+DQo+ID5UaGUgc2VjdXJpdHkg bW9kZWwgYmVoaW5kIGFsbCB0aGVzZSBpcyBwcmV0dHkgc2ltcGxlLiBUaGUgYWN0aXZlIHVzZXIN Cj4gPnNlc3Npb24gaGFzIHRvIGJlIHByb3RlY3RlZCBmcm9tIGFueSBleHRlcm5hbCBhY2Nlc3Mg YnkgYXR0YWNrZXJzIGFuZA0KPiA+ZW5mb3JjZSBzYW1lLW9yaWdpbiBwb2xpY3kuDQo+IA0KPiBX aGF0IGRpZG4ndCB5b3UgdW5kZXJzdGFuZD8gSSB3b3VsZCBiZSBoYXBweSB0byBpbXByb3ZlIG15 IGRlc2NyaXB0aW9uLg0KPiBXaGF0IEkgYmFzaWNhbGx5IHRyeSB0byBnZXQgYWNyb3NzOiBhIG1h bGljaW91cyBwaWVjZSBvZiBzb2Z0d2FyZSBydW5uaW5nIG9uIHRoZQ0KPiByZXNvdXJjZSBvd25l cnMgZGV2aWNlIGNhbiBzaW11bGF0ZSBoZXIgY29uc2VudC4gQXMgYSBwcmUtcmVxdWlzaXRlIHRo ZQ0KPiBhdHRhY2tlciBtdXN0IGJlIGFibGUgdG8gZWl0aGVyIGFidXNlIGFuIGV4aXN0aW5nIHNl c3Npb24gb3IgdG8gY3JlYXRlIGEgbmV3DQo+IG9uZS4gSSBnYXZlIGZvdXIgZXhhbXBsZXMgb2Yg aG93IHRoaXMgY291bGQgYmUgYWNoaWV2ZWQuIEF0IGxlYXN0IHRoZSBsYXN0IGhhcw0KPiBvYnZp b3VzbHkgbm90aGluZyB0byBkbyB3aXRoIGJyb3dzZXIgc2VjdXJpdHkgZmVhdHVyZXMuIFRoZSB0 aHJlYXQgYWxzbyBoYXMNCj4gbm90aGluZyB0byBkbyB3aXRoIHBvb3IgZGVzaWduIG9yIHVzZXIt YWdlbnQgaW1wbGVtZW50YXRpb24gZmxhd3MuIEl0IGlzIGENCj4gZGVsaWJlcmF0ZSBhdHRhY2sg YWdhaW5zdCB0aGUgcmVzb3VyY2Ugb3duZXIuDQo+IA0KPiBPbmUgY291bGQgYXJndWUgdGhhdCBw cmV2ZW50aW9uIG9mIG1hbGljb3VzIHNvZnR3YXJlIGlzIG5vdCB0aGUNCj4gcmVzcG9uc2liaWxp dHkgb2YgdGhlIGF1dGh6IHNlcnZlci4gSSBjb3VsZCBhZ3JlZSB3aXRoIHRoYXQuIEJ1dCBwZW9w bGUgc2VlbSB0bw0KPiBleHBlY3QgYW4gT0F1dGggYXV0aHogc2VydmVyIHRvIGNvcGUgd2l0aCBz dWNoIGF0dGFja3MuIFRoYXQncyB3aHkgSSBiZWxpZXZlDQo+IHdlIGVpdGhlciBjbGVhcmx5IGRy YXcgdGhpcyBib3VuZGFyeSBpbiB0aGUgc3BlYyBvciBnaXZlIGEgaGludCBvbiBob3cgdG8NCj4g cHJldmVudCB0aGlzIGtpbmQgb2YgdGhyZWF0Lg0KPiANCj4gcmVnYXJkcywNCj4gVG9yc3Rlbi4N Cj4gPkkgc3RpbGwgZG9uJ3Qgc2VlIHRoZSBuZWVkIHRvIGFkZCB0aGUgcHJvcG9zZWQgc2VjdGlv bi4NCj4gDQo+ID5FSEwNCj4gDQo+IA0KPiANCg0K From eran@hueniverse.com Wed Sep 14 07:01: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 A5ACB21F8C4D for ; Wed, 14 Sep 2011 07:01:47 -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 VAKkKxWVDLUk for ; Wed, 14 Sep 2011 07:01: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 A130D21F8B9B for ; Wed, 14 Sep 2011 07:01:43 -0700 (PDT) Received: (qmail 23948 invoked from network); 14 Sep 2011 14:03:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.46) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 14 Sep 2011 14:03:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 14 Sep 2011 07:03:25 -0700 From: Eran Hammer-Lahav To: Justin Richer , Greg Brail Date: Wed, 14 Sep 2011 07:01:18 -0700 Thread-Topic: [OAUTH-WG] Nit: Language in section 1.1 Thread-Index: Acxy3vgstdagmI99Rt6KM5E5ZEOanwAB8FfA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D9237D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <63404c9b49bccfbff551bb973679b77d@mail.gmail.com> <1316005445.9516.35.camel@ground> In-Reply-To: <1316005445.9516.35.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: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Nit: Language in section 1.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: Wed, 14 Sep 2011 14:01:47 -0000 SSBoYXZlIG5vIG9iamVjdGlvbiwgYnV0ICJtdWNoIGNsZWFyZXIiPyA6LSkNCg0KRUhMDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBKdXN0aW4g UmljaGVyDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDE0LCAyMDExIDY6MDQgQU0NCj4g VG86IEdyZWcgQnJhaWwNCj4gQ2M6IG9hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbT0FV VEgtV0ddIE5pdDogTGFuZ3VhZ2UgaW4gc2VjdGlvbiAxLjENCj4gDQo+ICsxLCB0aGlzIHdvcmRp bmcgaXMgbXVjaCBjbGVhcmVyIHRvIG1lLCB0b28NCj4gDQo+ICAtLSBqdXN0aW4NCj4gDQo+IE9u IFR1ZSwgMjAxMS0wOS0xMyBhdCAxOToyNSAtMDQwMCwgR3JlZyBCcmFpbCB3cm90ZToNCj4gPiBU aGlzIHBhcnQgb2Ygc2VjdGlvbiAxLjEgaXMgY29uZnVzaW5nIHRvIG1lIGFuZCBJIHN0dW1ibGUg d2hlbmV2ZXIgSQ0KPiA+IHJlYWQgaXQg4oCTIEkgc2VlIHRoYXQgQnJpYW4gRWF0b24gc3VnZ2Vz dGVkIGxvb2tpbmcgYXQgaXQgYSB3aGlsZSBiYWNrDQo+ID4gYnV0IEkgZG9u4oCZdCB0aGluayBp dCBnb3QgY2hhbmdlZDoNCj4gPg0KPiA+DQo+ID4NCj4gPiDigJxPQXV0aCBpbmNsdWRlcyBmb3Vy IHJvbGVzIHdvcmtpbmcgdG9nZXRoZXIgdG8gZ3JhbnQgYW5kIHByb3ZpZGUNCj4gPg0KPiA+ICAg IGFjY2VzcyB0byBwcm90ZWN0ZWQgcmVzb3VyY2VzIC0gYWNjZXNzIHJlc3RyaWN0ZWQgcmVzb3Vy Y2VzDQo+ID4gcmVxdWlyaW5nDQo+ID4NCj4gPiAgICBhdXRoZW50aWNhdGlvbjrigJ0NCj4gPg0K PiA+DQo+ID4NCj4gPiBJIHdvdWxkIHN1Z2dlc3Qgc29tZXRoaW5nIHNpbXBsZXIsIHN1Y2ggYXM6 DQo+ID4NCj4gPg0KPiA+DQo+ID4g4oCcT0F1dGggaW5jbHVkZXMgZm91ciByb2xlcyB0aGF0IHdv cmsgdG9nZXRoZXIgdG8gZ3JhbnQgYW5kIHByb3ZpZGUNCj4gPiBhY2Nlc3MgdG8gcHJvdGVjdGVk IHJlc291cmNlcyB0aGF0IHJlcXVpcmUgYXV0aGVudGljYXRpb24u4oCdDQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+IEdyZWdvcnkgQnJhaWwgICB8ICAgVGVjaG5vbG9neSAgIHwgICBBcGln ZWUgICB8ICAgKzEtNjUwLTkzNy05MzAyDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBt YWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0K From torsten@lodderstedt.net Wed Sep 14 07:18: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 27ACC21F8B85 for ; Wed, 14 Sep 2011 07:18:36 -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 iwAkrKvuje+2 for ; Wed, 14 Sep 2011 07:18:31 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.98]) by ietfa.amsl.com (Postfix) with ESMTP id 16CA321F8B66 for ; Wed, 14 Sep 2011 07:18:30 -0700 (PDT) Received: from [80.67.16.112] (helo=webmail.df.eu) by smtprelay05.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1R3qKM-0007uT-Pz for oauth@ietf.org; Wed, 14 Sep 2011 16:20:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 14 Sep 2011 16:20:38 +0200 From: Torsten Lodderstedt To: In-Reply-To: References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> <59CDCC16-44BA-4626-B744-F1169A13A542@oracle.com> Message-ID: <55876c26dbad646336c557dc22d67c40@lodderstedt-online.de> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail/0.5.2 X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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: Wed, 14 Sep 2011 14:18:36 -0000 Hi Dave, On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote: > 1. "The user does not have to be present." > Maybe I should be more clear. What benefit does that have over just a > long-lived (forever) access token? The cost is the extra complication > for > 3rd party developers to have to worry about refresh tokens. I can not > see > a benefit in our model (everything over SSL, etc) to use refresh > tokens. > I want to use refresh tokens - but only if there is a reason for > them, > which I can not see at the moment. The benefit of refresh tokens significantly depends on your access token design. If your access tokens are just a pointer to a database you lookup on any API call, the only benefit if token rotation (coming back to this topic below). But your access tokens could also directly contain all user data you need to actually authorize API access. That way you could save DB lookups, which scales much better. In this model, revocation is much can be easier implement using refresh tokens. I think this is what Eran refered to. > 2. "As Eran points out, you'd have to have do a DB lookup to have > true > revocation." > The act of revoking tokens is not a common occurrence, DB lookups to > revoke tokens is not a concern as there is more time spent by the > user > navigating the UI (or network latency, etc) than the cost of the DB > call. > > 3. "In this sense you get the best of a long-lived credential, > combined > with good key rotation and authorization re-verification without > having > to re-involve the end-user." > That all sounds good, but in our situation (all SSL, etc) - what do > we > want key rotation and re-verification for? I fail to see a reasonable > vector for access token leakage to warrant any of this in our case. rotation is a mean to detect tokem theft from the device (see also http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2). regards, Torsten. > > On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: > >> See below... >> >> Phil >> @independentid >> www.independentid.com [11] phil.hunt@oracle.com [12] >> >> On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: >> >>> Hi Phil, >> The client is then forced to periodically >>> reauthenticate >>> (without the user) before getting a new access token. >>> What benefit does that have? >> The user does not have to be present. >> >>>>> Refresh also gives the authzn server a chance to revoke access. >>> Hence it is better to use shorter lived access tokens with long >>> lived >>> refresh tokens. >>> That doesn't follow - we can just as easily revoke the single >>> long-lived access token. >> As Eran points out, you'd have to have do a DB lookup to have true >> revocation. But, by having a short expiration time on the access >> token >> (say 1 hour or less), you get quasi-revocation which has to be >> re-validated after the access token expires and the client has to >> re-authenticate and provide a valid refresh token. In this sense you >> get the best of a long-lived credential, combined with good key >> rotation and authorization re-verification without having to >> re-involve >> the end-user. >> >> Dave.> >>> On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: >>> >>>> You can also use a long lived refresh token in combination with a >>>> short access token. The client is then forced to periodically >>>> reauthenticate (without the user) before getting a new access >>>> token. >>>> Refresh also gives the authzn server a chance to revoke access. >>>> Hence it is better to use shorter lived access tokens with long >>>> lived refresh tokens. >>>> >>>> Phil >>>> >>>> On 2011-09-07, at 15:27, William Mills wrote: >>>> >>>>> I'll talk to the refresh token question: they give you a hook for >>>>> extensibility and key rotation. If you want to rotate your >>>>> encryption keys or extend the data carried in the token in any >>>>> way then you want to be able to cleanly refresh your tokens. Note >>>>> that the refresh flow allows you to issue a new refresh token at >>>>> the same time. It also allows a clean path to convert tokens in a >>>>> new client if you decide you want SAML tokens instead of MAC for >>>>> example. >>>>> If you want those things you want to use refresh tokens. You can >>>>> have long lived access tokens too, and just use the refresh >>>>> tokens when you want to do something new with the access tokens. >>>>> -bill >>>>> >>>>> ------------------------- >>>>> FROM: Dave Rochwerger >>>>> TO: oauth@ietf.org [2] >>>>> CC: Quizlet Dev Team >>>>> SENT: Wednesday, September 7, 2011 2:15 PM >>>>> SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client >>>>> secret and refresh tokens) >>>>> >>>>> Hi all, >>>>> I have been implementing OAuth2 based on the various drafts for >>>>> our new API. Initially, I implemented everything as per the spec, >>>>> but due to our particular scenario and restrictions we have in >>>>> place, there are some fundamental questions that I am unable to >>>>> defend. >>>>> I am hoping this group could help answer them for me. >>>>> Our scenario: >>>>> ========== >>>>> * We are implementing an API to allow 3rd party developers to >>>>> access users' protected resources via their applications. The >>>>> applications will mostly be native phone apps, but some will have >>>>> web server backends (javascript-only applications are not a >>>>> concern at the moment). >>>>> * We want to provide very long-lived (forever) tokens. >>>>> * We are implementing the "authorization code" flow as that seems >>>>> best suited to us (we don't want the implicit flow because >>>>> end-users would have to re-authorize every hour). >>>>> Our architecture: >>>>> ============ >>>>> * We control both the API server and the authorization server. >>>>> * All requests to protected resources (ie: to the API server) are >>>>> always done over SSL. >>>>> * All requests to the authz server (token and authorize >>>>> endpoints) are always done over SSL. >>>>> * We enforce that every client must supply the state parameter >>>>> (and our guidelines say they must verify the state for CSRF >>>>> mitigation). >>>>> * We enforce that every client must register a redirect URI. >>>>> * We validate the redirect_uri used to request an access token is >>>>> the same that was used to obtain the auth code. >>>>> * The only time a request is not made over SSL is the redirect >>>>> with the auth_code which is very short-lived (30 seconds) and is >>>>> tied to a verified redirect URI. >>>>> * We enforce that access tokens must be provided using the >>>>> Authorization header only (and of course, over SSL). >>>>> * We have guidelines saying that all mobile apps must use the >>>>> native browser (and not an embedded web UI). >>>>> Questions: >>>>> ======== >>>>> 1. Given the above scenario, what use are refresh tokens? >>>>> - Access tokens can not leak because every request (to resource >>>>> and authz server) containing an access token is done over SSL. We >>>>> control both the authz and resource servers, so tokens in logs >>>>> (and other suggested reasons in the archives) are not an issue. >>>>> - Long-lived refresh tokens and short-lived access tokens are >>>>> supposed to provide security due to possible access token >>>>> leakage... but in our 100% SSL scenario, if access tokens are >>>>> able to leak, then so would the client id, secret and refresh >>>>> token. >>>>> - Having a long-lived refresh token that can be exchanged for >>>>> another access token adds a level of complexity (a second HTTPS >>>>> request every so often) and seems to provide no benefit for our >>>>> case. >>>>> 2. What is the point of the client secret (in our scenario)? - >>>>> We originally were treating the clients as confidential, but >>>>> after re-reading the native-application section, it seems we >>>>> really should treat them as public (phone apps can be decompiled >>>>> and the secret discovered). >>>>> >>>>> - The spec says that the authz server should authenticate >>>>> confidential clients, but public clients are allowed to just send >>>>> their public client id (and no secret). >>>>> - The only verification then, is to enforce redirect URI >>>>> registration and to validate the redirect URI between >>>>> authorization and token steps. >>>>> >>>>> So, the question is, assuming that we, one: "enforce >>>>> redirect-URI registration" and two: "validate that URI" - why >>>>> can't we treat all clients as public and not worry about a >>>>> secret? >>>>> What is the benefit of having confidential clients (and a secret) >>>>> at all? >>>>> Our API source is not available, but the oauth2 server >>>>> implementation can be seen here: >>>>> https://github.com/quizlet/oauth2-php [4] >>>>> Regards, >>>>> Dave >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org [5] >>>>> https://www.ietf.org/mailman/listinfo/oauth [6] >>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org [7] >>>>> https://www.ietf.org/mailman/listinfo/oauth [8] Links: ------ [1] mailto:daver@quizlet.com [2] mailto:oauth@ietf.org [3] mailto:devteam@quizlet.com [4] https://github.com/quizlet/oauth2-php [5] mailto:OAuth@ietf.org [6] https://www.ietf.org/mailman/listinfo/oauth [7] mailto:OAuth@ietf.org [8] https://www.ietf.org/mailman/listinfo/oauth [9] mailto:wmills@yahoo-inc.com [10] mailto:phil.hunt@oracle.com [11] http://www.independentid.com [12] mailto:phil.hunt@oracle.com [13] mailto:phil.hunt@oracle.com From torsten@lodderstedt.net Wed Sep 14 07:23: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 B6D7321F8B88 for ; Wed, 14 Sep 2011 07:23:29 -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 pwJZekug1OSr for ; Wed, 14 Sep 2011 07:23:29 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id 7887221F8B06 for ; Wed, 14 Sep 2011 07:23:28 -0700 (PDT) Received: from [80.67.16.112] (helo=webmail.df.eu) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1R3qP8-0004qG-Ml; Wed, 14 Sep 2011 16:25:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 14 Sep 2011 16:25:34 +0200 From: Torsten Lodderstedt To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345213D9237C@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> <4E514770.7040405@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345213D9237C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail/0.5.2 X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= 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: Wed, 14 Sep 2011 14:23:29 -0000 It is a native app and it is external wrt the browser. regards, Torsten. On Wed, 14 Sep 2011 06:59:47 -0700, Eran Hammer-Lahav wrote: > Is this malicious piece of software external a native application > either past of a native client or external to the browser? > > EHL > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Wednesday, September 14, 2011 6:51 AM >> To: Eran Hammer-Lahav >> Cc: Niv Steingarten; oauth@ietf.org >> Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> >> Hi Eran, >> >> >> 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. >> >> >A textbook CSRF attack is when an attacker constructs a URI and >> then >> >manipulate a user-agent with an active session to call that. In the >> >simplest example, an >attacker constructs a URI that transfers a >> >million dollars from the current account to its, then tricks the >> user >> >to click on that link or automatically >redirects the user to that >> URI. >> > Because the user is already signed in and has an active session >> token, >> >the request goes through. >> >> >To prevent it, the request URI must include an artifact that binds >> the >> >request to the active session. Since the attacker has no way of >> >accessing the session >information, it cannot construct as a URI. >> In >> >practice, this means adding a hidden form parameter to the button >> with >> >some hash of the session information >that the server can verify. >> >> So I would conclude we have the same understanding of what CSRF >> means. >> >> >> 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. >> >> >Of course it matters. >> >> >The only way the attacker can get access is by calling the 'I >> agree' >> > button action via an active user session. The attacker cannot >> access >> >the hidden form >value with the session hash (or whatever the >> server is >> >using for CSRF protection). So whatever URI it constructs will not >> work >> >when called with the active >user session. >> >> My point is: the attacker in the threat I'm trying to describe does >> not need to >> create any URL since it just remote controls the user-agent. The >> malicous >> code runs outside of the browser and "just" uses the URLs provided >> by the >> authz server. Yes, there need to be a session. No, the attacker does >> not >> need to inject any URL he made up. >> >> >> 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. >> >> >I'm having a hard time following all these scenarios. But the >> >important part is that OAuth assumes the 'user-agent' is a >> compliant >> >and secure web browser. If >the user-agent does not enforce cookie >> >boundaries, XSS, CORS policy, etc. there isn't much we can do. In >> other >> >words, if the user installs a poorly design >native application >> which >> >has its own user-agent implementation opened to known web attacks, >> all >> >bets are off. >> > >> >The security model behind all these is pretty simple. The active >> user >> >session has to be protected from any external access by attackers >> and >> >enforce same-origin policy. >> >> What didn't you understand? I would be happy to improve my >> description. >> What I basically try to get across: a malicious piece of software >> running on the >> resource owners device can simulate her consent. As a pre-requisite >> the >> attacker must be able to either abuse an existing session or to >> create a new >> one. I gave four examples of how this could be achieved. At least >> the last has >> obviously nothing to do with browser security features. The threat >> also has >> nothing to do with poor design or user-agent implementation flaws. >> It is a >> deliberate attack against the resource owner. >> >> One could argue that prevention of malicous software is not the >> responsibility of the authz server. I could agree with that. But >> people seem to >> expect an OAuth authz server to cope with such attacks. That's why I >> believe >> we either clearly draw this boundary in the spec or give a hint on >> how to >> prevent this kind of threat. >> >> regards, >> Torsten. >> >I still don't see the need to add the proposed section. >> >> >EHL >> >> >> From torsten@lodderstedt.net Wed Sep 14 07:26: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 66B6521F8B9D for ; Wed, 14 Sep 2011 07:26:31 -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 mSO7n4vhWTWf for ; Wed, 14 Sep 2011 07:26:29 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id 65FD521F8B64 for ; Wed, 14 Sep 2011 07:26:29 -0700 (PDT) Received: from [80.67.16.112] (helo=webmail.df.eu) by smtprelay06.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1R3qS3-00068c-U1; Wed, 14 Sep 2011 16:28:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 14 Sep 2011 16:28:35 +0200 From: Torsten Lodderstedt To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72345021F37877@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2DAAEA.7090304@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234502498CDDE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E498313.3080009@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: <47afa9b25ff9b1ceb506b723c2bbe95e@lodderstedt-online.de> X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail/0.5.2 X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= 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: Wed, 14 Sep 2011 14:26:31 -0000 ok with me. On Sun, 4 Sep 2011 15:13:01 -0700, Eran Hammer-Lahav wrote: > That's not complete. A valid redirection URI is not enough to verify > client identity at the time it is presented, but it is enough in many > cases to prevent leaking credentials later on. > > How about a slight change: > > A valid redirection URI is not sufficient to verify the > client's identity when asking for > end-user authorization, but can be used to prevent > delivering credentials to a > counterfeit client after obtaining end-user authorization. > > EHL > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Monday, August 15, 2011 1:36 PM >> To: Eran Hammer-Lahav >> Cc: eran@sled.com; oauth@ietf.org >> Subject: Re: [OAUTH-WG] redirect uri validation >> >> 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 eran@hueniverse.com Wed Sep 14 07:31: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 E0C5421F84A6 for ; Wed, 14 Sep 2011 07:31: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 cjFcx8ru5imC for ; Wed, 14 Sep 2011 07:31: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 EDEDE21F8CE3 for ; Wed, 14 Sep 2011 07:31:20 -0700 (PDT) Received: (qmail 22255 invoked from network); 14 Sep 2011 14:33:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 14 Sep 2011 14:33:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 14 Sep 2011 07:33:01 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Wed, 14 Sep 2011 07:30:56 -0700 Thread-Topic: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Thread-Index: Acxy6jdRM3bWynLBRC+/Gnm23aBjwQAAIObg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92398@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> <4E514770.7040405@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345213D9237C@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: Wed, 14 Sep 2011 14:31:22 -0000 SSBzdWdnZXN0IHdlIGFkZHJlc3MgdGhpcyBwYXJ0aWN1bGFyIHNjZW5hcmlvIGluIHRoZSB0aHJl YWQgbW9kZWwgZG9jdW1lbnQuDQoNCkVITA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldF0NCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTQsIDIwMTEgNzoyNiBBTQ0KPiBU bzogRXJhbiBIYW1tZXItTGFoYXYNCj4gQ2M6IE5pdiBTdGVpbmdhcnRlbjsgb2F1dGhAaWV0Zi5v cmcNCj4gU3ViamVjdDogUkU6IFtPQVVUSC1XR10gRHJhZnQgMjAgbGFzdCBjYWxsIGNvbW1lbnQg KFJlc291cmNlIE93bmVyDQo+IEltcGVyc29uYXRpb24pDQo+IA0KPiBJdCBpcyBhIG5hdGl2ZSBh cHAgYW5kIGl0IGlzIGV4dGVybmFsIHdydCB0aGUgYnJvd3Nlci4NCj4gDQo+IHJlZ2FyZHMsDQo+ IFRvcnN0ZW4uDQo+IA0KPiBPbiBXZWQsIDE0IFNlcCAyMDExIDA2OjU5OjQ3IC0wNzAwLCBFcmFu IEhhbW1lci1MYWhhdiB3cm90ZToNCj4gPiBJcyB0aGlzIG1hbGljaW91cyBwaWVjZSBvZiBzb2Z0 d2FyZSBleHRlcm5hbCBhIG5hdGl2ZSBhcHBsaWNhdGlvbg0KPiA+IGVpdGhlciBwYXN0IG9mIGEg bmF0aXZlIGNsaWVudCBvciBleHRlcm5hbCB0byB0aGUgYnJvd3Nlcj8NCj4gPg0KPiA+IEVITA0K PiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IFRvcnN0ZW4g TG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0NCj4gPj4gU2VudDog V2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTQsIDIwMTEgNjo1MSBBTQ0KPiA+PiBUbzogRXJhbiBIYW1t ZXItTGFoYXYNCj4gPj4gQ2M6IE5pdiBTdGVpbmdhcnRlbjsgb2F1dGhAaWV0Zi5vcmcNCj4gPj4g U3ViamVjdDogUkU6IFtPQVVUSC1XR10gRHJhZnQgMjAgbGFzdCBjYWxsIGNvbW1lbnQgKFJlc291 cmNlIE93bmVyDQo+ID4+IEltcGVyc29uYXRpb24pDQo+ID4+DQo+ID4+IEhpIEVyYW4sDQo+ID4+ DQo+ID4+ID4+IEFzIGZhciBhcyBJIHVuZGVyc3Rvb2QsIGluIGEgdGV4dGJvb2sgQ1NSRiBhdHRh Y2sgdGhlIGF0dGFja2VyDQo+ID4+IHdvdWxkDQo+ID4+ID4+IGNyZWF0ZSBoaXMgb3duIHJlcXVl c3RzIGluIG9yZGVyIHRvIGFidXNlIGEgdXNlcidzIHNlc3Npb24uIFRoaXMNCj4gPj4gY2FuDQo+ ID4+ID4+IGJlIHByZXZlbnRlZCBieSB1dGlsaXppbmcgc3RhbmRhcmQgQ1NSRiBjb3V0ZXJtZWFz dXJlcyAocGFnZQ0KPiA+PiB0b2tlbiwNCj4gPj4gPj4gbm91bmNlLCBzaWduYXR1cmUgYXMgcGFy YW1ldGVyIG9uIGV2ZXJ5IHJlcXVlc3QgVVJMKSwgd2hpY2ggYmluZA0KPiA+PiBVUkxzDQo+ID4+ ID4+IHRvIGEgY2VydGFpbiBzZXNzaW9uLg0KPiA+Pg0KPiA+PiA+QSB0ZXh0Ym9vayBDU1JGIGF0 dGFjayBpcyB3aGVuIGFuIGF0dGFja2VyIGNvbnN0cnVjdHMgYSBVUkkgYW5kDQo+ID4+IHRoZW4N Cj4gPj4gPm1hbmlwdWxhdGUgYSB1c2VyLWFnZW50IHdpdGggYW4gYWN0aXZlIHNlc3Npb24gdG8g Y2FsbCB0aGF0LiBJbiB0aGUNCj4gPj4gPnNpbXBsZXN0IGV4YW1wbGUsIGFuID5hdHRhY2tlciBj b25zdHJ1Y3RzIGEgVVJJIHRoYXQgdHJhbnNmZXJzIGENCj4gPj4gPm1pbGxpb24gZG9sbGFycyBm cm9tIHRoZSBjdXJyZW50IGFjY291bnQgdG8gaXRzLCB0aGVuIHRyaWNrcyB0aGUNCj4gPj4gdXNl cg0KPiA+PiA+dG8gY2xpY2sgb24gdGhhdCBsaW5rIG9yIGF1dG9tYXRpY2FsbHkgPnJlZGlyZWN0 cyB0aGUgdXNlciB0byB0aGF0DQo+ID4+IFVSSS4NCj4gPj4gPiBCZWNhdXNlIHRoZSB1c2VyIGlz IGFscmVhZHkgc2lnbmVkIGluIGFuZCBoYXMgYW4gYWN0aXZlIHNlc3Npb24NCj4gPj4gdG9rZW4s DQo+ID4+ID50aGUgcmVxdWVzdCBnb2VzIHRocm91Z2guDQo+ID4+DQo+ID4+ID5UbyBwcmV2ZW50 IGl0LCB0aGUgcmVxdWVzdCBVUkkgbXVzdCBpbmNsdWRlIGFuIGFydGlmYWN0IHRoYXQgYmluZHMN Cj4gPj4gdGhlDQo+ID4+ID5yZXF1ZXN0IHRvIHRoZSBhY3RpdmUgc2Vzc2lvbi4gU2luY2UgdGhl IGF0dGFja2VyIGhhcyBubyB3YXkgb2YNCj4gPj4gPmFjY2Vzc2luZyB0aGUgc2Vzc2lvbiA+aW5m b3JtYXRpb24sIGl0IGNhbm5vdCBjb25zdHJ1Y3QgYXMgYSBVUkkuDQo+ID4+IEluDQo+ID4+ID5w cmFjdGljZSwgdGhpcyBtZWFucyBhZGRpbmcgYSBoaWRkZW4gZm9ybSBwYXJhbWV0ZXIgdG8gdGhl IGJ1dHRvbg0KPiA+PiB3aXRoDQo+ID4+ID5zb21lIGhhc2ggb2YgdGhlIHNlc3Npb24gaW5mb3Jt YXRpb24gPnRoYXQgdGhlIHNlcnZlciBjYW4gdmVyaWZ5Lg0KPiA+Pg0KPiA+PiBTbyBJIHdvdWxk IGNvbmNsdWRlIHdlIGhhdmUgdGhlIHNhbWUgdW5kZXJzdGFuZGluZyBvZiB3aGF0IENTUkYNCj4g Pj4gbWVhbnMuDQo+ID4+DQo+ID4+ID4+IEJ1dCB3aHkgc2hvdWxkIHRoZSBhdHRhY2tlciBjcmVh dGUgcmVxdWVzdHMgZXQgYWxsPyBBbGwgaGUgbmVlZHMNCj4gPj4gaXMNCj4gPj4gPj4gYWxyZWFk eSBwcm92aWRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdGhlbXNlbHZlcy4gVGhlDQo+ ID4+ID4+IG1hbGljaW91cyBjbGllbnQgY2FuIGRvd25sb2FkIHRoZSBIVE1MIHBhZ2VzIGNvbXBy aXNpbmcgdGhlDQo+ID4+ID4+IGF1dGhvcml6YXRpb24gZmxvdyBmcm9tIHRoZSBhdXRoeiBzZXJ2 ZXIgYW5kIHVzZSB0aGUgZW1iZWRkZWQNCj4gPj4gVVJMcyB0bw0KPiA+PiA+PiBpc3N1ZSB0aGUg cmVxdWVzdHMgd2hpY2ggbm9ybWFseSB3b3VsZCBoYXZlIGJlZW4gaXNzdWVkIGJ5IHRoZQ0KPiA+ PiA+PiByZXNvdXJjZSBvd25lciBoZXJzZWxmICh1c2luZyB0aGUgdXNlIGFnZW50IGluZGVlZCku IEl0J3MgbW9yZSBvcg0KPiA+PiA+PiBsZXNzIHRoZSBwdXNoIG9uIGEgIkkgYWdyZWUiDQo+ID4+ ID4+IGJ1dHRvbiB3ZSBhcmUgdGFsa2luZyBhYm91dC4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVy IG1heSBhZGQgYQ0KPiA+PiBwYWdlDQo+ID4+ID4+IHRva2VuIHRvIHRoZSByZXNwZWN0aXZlIGZv cm0gVVJMLiBCdXQgaXQgZG9lcyBub3QgbWF0dGVyIHNpbmNlDQo+ID4+IHRoZQ0KPiA+PiA+PiBj bGllbnQganVzdCB1c2VzIHRoZSBhdXRoeiBzZXJ2ZXIgbWFudWZhY3R1cmVkIFVSTCB0byBwb3N0 IHRoZQ0KPiA+PiBmb3JtLg0KPiA+Pg0KPiA+PiA+T2YgY291cnNlIGl0IG1hdHRlcnMuDQo+ID4+ DQo+ID4+ID5UaGUgb25seSB3YXkgdGhlIGF0dGFja2VyIGNhbiBnZXQgYWNjZXNzIGlzIGJ5IGNh bGxpbmcgdGhlICdJDQo+ID4+IGFncmVlJw0KPiA+PiA+IGJ1dHRvbiBhY3Rpb24gdmlhIGFuIGFj dGl2ZSB1c2VyIHNlc3Npb24uIFRoZSBhdHRhY2tlciBjYW5ub3QNCj4gPj4gYWNjZXNzDQo+ID4+ ID50aGUgaGlkZGVuIGZvcm0gPnZhbHVlIHdpdGggdGhlIHNlc3Npb24gaGFzaCAob3Igd2hhdGV2 ZXIgdGhlDQo+ID4+IHNlcnZlciBpcw0KPiA+PiA+dXNpbmcgZm9yIENTUkYgcHJvdGVjdGlvbiku IFNvIHdoYXRldmVyIFVSSSBpdCBjb25zdHJ1Y3RzIHdpbGwgbm90DQo+ID4+IHdvcmsNCj4gPj4g PndoZW4gY2FsbGVkIHdpdGggdGhlIGFjdGl2ZSA+dXNlciBzZXNzaW9uLg0KPiA+Pg0KPiA+PiBN eSBwb2ludCBpczogdGhlIGF0dGFja2VyIGluIHRoZSB0aHJlYXQgSSdtIHRyeWluZyB0byBkZXNj cmliZSBkb2VzDQo+ID4+IG5vdCBuZWVkIHRvIGNyZWF0ZSBhbnkgVVJMIHNpbmNlIGl0IGp1c3Qg cmVtb3RlIGNvbnRyb2xzIHRoZQ0KPiA+PiB1c2VyLWFnZW50LiBUaGUgbWFsaWNvdXMgY29kZSBy dW5zIG91dHNpZGUgb2YgdGhlIGJyb3dzZXIgYW5kICJqdXN0Ig0KPiA+PiB1c2VzIHRoZSBVUkxz IHByb3ZpZGVkIGJ5IHRoZSBhdXRoeiBzZXJ2ZXIuIFllcywgdGhlcmUgbmVlZCB0byBiZSBhDQo+ ID4+IHNlc3Npb24uIE5vLCB0aGUgYXR0YWNrZXIgZG9lcyBub3QgbmVlZCB0byBpbmplY3QgYW55 IFVSTCBoZSBtYWRlIHVwLg0KPiA+Pg0KPiA+PiA+PiBTbyBsZXQncyBhc3N1bWUgdGhlIGF0dGFj a2VyIGhhcyB0byBwcm9ncmFtbWF0aWNhbGx5IGhhbmRsZSBIVE1MDQo+ID4+ID4+IGZvcm1zIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBkZWxpdmVycyB0byB0aGUgdXNlciBhZ2VudC4gQXMgeW91 DQo+ID4+ID4+IGNvcnJlY3RseSBwb2ludGVkIG91dCwgdGhlIHByZS1yZXF1aXNpdGUgZm9yIHN1 Y2ggYW4gYXR0YWNrIHRvDQo+ID4+ID4+IHN1Y2NlZWQgaXMgdGhhdCB0aGUgcmVzb3VyY2Ugb3du ZXIgbXVzdCBiZSBhdXRoZW50aWNhdGVkIHNvbWVob3csDQo+ID4+ID4+IGUuZy4gYmFzZWQgb24g YSBzZXNzaW9uIGNvb2tpZS4gV2hpY2ggYWxzbyBtZWFucywgd2UgYXJlIHRhbGtpbmcNCj4gPj4g Pj4gYWJvdXQgY2xpZW50cyBydW5uaW5nIG9uIHRoZSB2aWN0aW0ncyBkZXZpY2UsIHdpdGhpbiB0 aGUgdXNlcg0KPiA+PiBhZ2VudA0KPiA+PiA+PiBvciBhcyBuYXRpdmUgYXBwLg0KPiA+PiA+Pg0K PiA+PiA+PiBJIHNlZSB0aGUgZm9sbG93aW5nIHBvc3NpYmxlIHNjZW5hcmlvczoNCj4gPj4gPj4N Cj4gPj4gPj4gMSkgZXh0ZXJuYWwgc3lzdGVtIGJyb3dzZXIgLSBUaGUgYXBwIGNvdWxkIHV0aWxp emUgYW4gZXhpc3RpbmcNCj4gPj4gPj4gc2Vzc2lvbiB3aXRoaW4gdGhlIHN5c3RlbSBicm93c2Vy IG9uIHRoZSB2aWN0aW0ncyBkZXZpY2UuIEl0DQo+ID4+IGNvdWxkDQo+ID4+ID4+IHRoZW4gcmVt b3RlIGNvbnRyb2wgYSBicm93c2VyIHdpbmRvdywgZS5nLiB1c2luZyBsb3ctbGV2ZWwNCj4gPj4g b3BlcmF0aW5nDQo+ID4+ID4+IHN5c3RlbSBtZXNzYWdlcyAoInNlbmQgbW91c2UgY2xpY2siKSBv ciBjb21wb25lbnQgdGVjaG5pcXVlcyBzdWNoDQo+ID4+IGFzDQo+ID4+ID4+IEFjdGl2ZVguIFRo ZXJlIGFyZSB0b29scyBhdmFpbGFibGUgdG8gY3JlYXRlIG1hY3JvcyB3aGljaA0KPiA+PiA+PiBh dXRvbWF0aWNhbGx5IGNvbnRyb2wgYW5kIG9idGFpbiBkYXRhIGZyb20gc3VjaCBhcHBsaWNhdGlv bnMuIFNvDQo+ID4+IHRoaXMNCj4gPj4gPj4gc2hvdWxkIGJlIGZlYXNpYmxlLg0KPiA+PiA+Pg0K PiA+PiA+PiAyKSBpbnRlcm5hbCBicm93c2VyIChjcm9zcy1icm93c2VyIGNvb2tpZXMpIC0gSWYg dGhlDQo+ID4+IGF1dGhvcml6YXRpb24NCj4gPj4gPj4gc2VydmVyIHVzZXMgY3Jvc3MtYnJvd3Nl ciBjb29raWUgdGVjaG5pcXVlcywgc3VjaCBhcyBmbGFzaA0KPiA+PiBjb29raWVzLA0KPiA+PiA+ PiB0aGUgYXR0YWNrZXIgY291bGQgaW5zdGFudGlhdGUgYW4gaW50ZXJuYWwgKGludmlzaWJsZSkg YnJvd3Nlcg0KPiA+PiBhbmQNCj4gPj4gPj4gdHJ5IHRvIHV0aWxpemUgYSBzZXNzaW9uIGFzc29j aWF0ZWQgd2l0aCBzdWNoIGEgY29va2llLiBJIGFzc3VtZQ0KPiA+PiA+PiBjb250cm9sbGluZyBz dWNoIGEgYnJvd3NlciBpbnN0YW5jZSB3aWxsIGJlIGV2ZW4gc2ltcGxlciB0aGVuIGluDQo+ID4+ ICgxKS4NCj4gPj4gPj4NCj4gPj4gPj4gMykgaW50ZXJuYWwgYnJvd3NlciAoc2lsZW50IGF1dGh6 IGZsb3cpIC0gVGhpcyBpcyBhIHNjZW5hcmlvDQo+ID4+IHdoZXJlDQo+ID4+ID4+IHRoZSBhdHRh Y2tlciBpcyB1bmFibGUgdG8gYWJ1c2UgYW4gZXhpc3Rpbmcgc2Vzc2lvbiBvbiB0aGUNCj4gPj4g ZGV2aWNlLiBJdA0KPiA+PiA+PiBjb3VsZCBpbnN0ZWFkIGNyZWF0ZSBhbiBpbnRlcm5hbCBicm93 c2VyIGFuZCBwZXJmb3JtIGFuDQo+ID4+IGF1dGhvcml6YXRpb24NCj4gPj4gPj4gZmxvdyB3aXRo IHRoZSByZXNvdXJjZSBvd25lciBmb3Igb25lIHBhcnRpY3VsYXIgc2NvcGUuIFVzaW5nIHRoZQ0K PiA+PiBzYW1lDQo+ID4+ID4+IGJyb3dzZXIgaW5zdGFuY2UgYW5kIGJhc2VkIG9uIHRoZSBjb29r aWVzIG9idGFpbmVkIGluIHRoZSBmaXJzdA0KPiA+PiBydW4sDQo+ID4+ID4+IGl0IGNvdWxkIHNp bGVudGx5IHBlcmZvcm0gYWRkaXRpb25hbCBhdXRob3JpemF0aW9uIGZsb3dzIGZvcg0KPiA+PiBv dGhlcg0KPiA+PiA+PiBzY29wZXMuDQo+ID4+ID4+DQo+ID4+ID4+IDQpIGludGVybmFsIGJyb3dz ZXIgKG5vbi1pbnRlcmFjdGl2ZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzKSAtDQo+ID4+IFRoZXJl DQo+ID4+ID4+IGFyZSBhdXRoZW50aWNhdGlvbiBtZXRob2RzIGF2YWlsYWJsZSB3L28gdGhlIG5l ZWQgZm9yDQo+ID4+ID4+IHVzZXItaW50ZXJhY3Rpb24sIGZvciBleGFtcGxlcyBTSU0gY2FyZCBh dXRoZW50aWNhdGlvbiBvcg0KPiA+PiA+PiBjZXJ0aWZpY2F0ZS1iYXNlZCBhdXRoZW50aWNhdGlv bi4NCj4gPj4gPj4gVGhlIGF0dGFja2VyIGNvdWxkIHV0aWxpemUgYW4gaW50ZXJuYWwsIGludmlz aWJsZSBicm93c2VyDQo+ID4+IGluc3RhbmNlIGluDQo+ID4+ID4+IGNvbWJpbmF0aW9uIHdpdGgg c3VjaCBhbiBhdXRoZW50aWNhdGlvbiBtZXRob2QgaW4gb3JkZXIgdG8NCj4gPj4gcGVyZm9ybQ0K PiA+PiA+PiB0aGUgYXV0aG9yaXphdGlvbiBwcm9jZXNzLg0KPiA+PiA+Pg0KPiA+PiA+PiBJJ20g bm90IHN1cmUgd2hldGhlciB0aGUgc2NlbmFyaW9zIGRlc2NyaWJlZCBhYm92ZSBjYW4gYmUNCj4g Pj4gY2xhc3NpZmllZA0KPiA+PiA+PiBhcyBDU1JGLg0KPiA+Pg0KPiA+PiA+SSdtIGhhdmluZyBh IGhhcmQgdGltZSBmb2xsb3dpbmcgYWxsIHRoZXNlIHNjZW5hcmlvcy4gQnV0IHRoZQ0KPiA+PiA+ aW1wb3J0YW50IHBhcnQgaXMgdGhhdCBPQXV0aCBhc3N1bWVzIHRoZSAndXNlci1hZ2VudCcgaXMg YQ0KPiA+PiBjb21wbGlhbnQNCj4gPj4gPmFuZCBzZWN1cmUgd2ViIGJyb3dzZXIuIElmID50aGUg dXNlci1hZ2VudCBkb2VzIG5vdCBlbmZvcmNlIGNvb2tpZQ0KPiA+PiA+Ym91bmRhcmllcywgWFNT LCBDT1JTIHBvbGljeSwgZXRjLiB0aGVyZSBpc24ndCBtdWNoIHdlIGNhbiBkby4gSW4NCj4gPj4g b3RoZXINCj4gPj4gPndvcmRzLCBpZiB0aGUgdXNlciBpbnN0YWxscyBhIHBvb3JseSBkZXNpZ24g Pm5hdGl2ZSBhcHBsaWNhdGlvbg0KPiA+PiB3aGljaA0KPiA+PiA+aGFzIGl0cyBvd24gdXNlci1h Z2VudCBpbXBsZW1lbnRhdGlvbiBvcGVuZWQgdG8ga25vd24gd2ViIGF0dGFja3MsDQo+ID4+IGFs bA0KPiA+PiA+YmV0cyBhcmUgb2ZmLg0KPiA+PiA+DQo+ID4+ID5UaGUgc2VjdXJpdHkgbW9kZWwg YmVoaW5kIGFsbCB0aGVzZSBpcyBwcmV0dHkgc2ltcGxlLiBUaGUgYWN0aXZlDQo+ID4+IHVzZXIN Cj4gPj4gPnNlc3Npb24gaGFzIHRvIGJlIHByb3RlY3RlZCBmcm9tIGFueSBleHRlcm5hbCBhY2Nl c3MgYnkgYXR0YWNrZXJzDQo+ID4+IGFuZA0KPiA+PiA+ZW5mb3JjZSBzYW1lLW9yaWdpbiBwb2xp Y3kuDQo+ID4+DQo+ID4+IFdoYXQgZGlkbid0IHlvdSB1bmRlcnN0YW5kPyBJIHdvdWxkIGJlIGhh cHB5IHRvIGltcHJvdmUgbXkNCj4gPj4gZGVzY3JpcHRpb24uDQo+ID4+IFdoYXQgSSBiYXNpY2Fs bHkgdHJ5IHRvIGdldCBhY3Jvc3M6IGEgbWFsaWNpb3VzIHBpZWNlIG9mIHNvZnR3YXJlDQo+ID4+ IHJ1bm5pbmcgb24gdGhlIHJlc291cmNlIG93bmVycyBkZXZpY2UgY2FuIHNpbXVsYXRlIGhlciBj b25zZW50LiBBcyBhDQo+ID4+IHByZS1yZXF1aXNpdGUgdGhlIGF0dGFja2VyIG11c3QgYmUgYWJs ZSB0byBlaXRoZXIgYWJ1c2UgYW4gZXhpc3RpbmcNCj4gPj4gc2Vzc2lvbiBvciB0byBjcmVhdGUg YSBuZXcgb25lLiBJIGdhdmUgZm91ciBleGFtcGxlcyBvZiBob3cgdGhpcw0KPiA+PiBjb3VsZCBi ZSBhY2hpZXZlZC4gQXQgbGVhc3QgdGhlIGxhc3QgaGFzIG9idmlvdXNseSBub3RoaW5nIHRvIGRv IHdpdGgNCj4gPj4gYnJvd3NlciBzZWN1cml0eSBmZWF0dXJlcy4gVGhlIHRocmVhdCBhbHNvIGhh cyBub3RoaW5nIHRvIGRvIHdpdGgNCj4gPj4gcG9vciBkZXNpZ24gb3IgdXNlci1hZ2VudCBpbXBs ZW1lbnRhdGlvbiBmbGF3cy4NCj4gPj4gSXQgaXMgYQ0KPiA+PiBkZWxpYmVyYXRlIGF0dGFjayBh Z2FpbnN0IHRoZSByZXNvdXJjZSBvd25lci4NCj4gPj4NCj4gPj4gT25lIGNvdWxkIGFyZ3VlIHRo YXQgcHJldmVudGlvbiBvZiBtYWxpY291cyBzb2Z0d2FyZSBpcyBub3QgdGhlDQo+ID4+IHJlc3Bv bnNpYmlsaXR5IG9mIHRoZSBhdXRoeiBzZXJ2ZXIuIEkgY291bGQgYWdyZWUgd2l0aCB0aGF0LiBC dXQNCj4gPj4gcGVvcGxlIHNlZW0gdG8gZXhwZWN0IGFuIE9BdXRoIGF1dGh6IHNlcnZlciB0byBj b3BlIHdpdGggc3VjaA0KPiA+PiBhdHRhY2tzLiBUaGF0J3Mgd2h5IEkgYmVsaWV2ZSB3ZSBlaXRo ZXIgY2xlYXJseSBkcmF3IHRoaXMgYm91bmRhcnkgaW4NCj4gPj4gdGhlIHNwZWMgb3IgZ2l2ZSBh IGhpbnQgb24gaG93IHRvIHByZXZlbnQgdGhpcyBraW5kIG9mIHRocmVhdC4NCj4gPj4NCj4gPj4g cmVnYXJkcywNCj4gPj4gVG9yc3Rlbi4NCj4gPj4gPkkgc3RpbGwgZG9uJ3Qgc2VlIHRoZSBuZWVk IHRvIGFkZCB0aGUgcHJvcG9zZWQgc2VjdGlvbi4NCj4gPj4NCj4gPj4gPkVITA0KPiA+Pg0KPiA+ Pg0KPiA+Pg0KDQo= From torsten@lodderstedt.net Wed Sep 14 07:37: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 4065C21F8CEE for ; Wed, 14 Sep 2011 07:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 UgubQjdztYml for ; Wed, 14 Sep 2011 07:37:39 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by ietfa.amsl.com (Postfix) with ESMTP id EC9DC21F8C2A for ; Wed, 14 Sep 2011 07:37:38 -0700 (PDT) Received: from [80.67.16.112] (helo=webmail.df.eu) by smtprelay05.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1R3qct-0008De-Dn; Wed, 14 Sep 2011 16:39:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 14 Sep 2011 16:39:47 +0200 From: Torsten Lodderstedt To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345213D92398@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> <4E514770.7040405@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A4F23D0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345213D9237C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345213D92398@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-ID: X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail/0.5.2 X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= 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: Wed, 14 Sep 2011 14:37:40 -0000 ok regards, Torsten. On Wed, 14 Sep 2011 07:30:56 -0700, Eran Hammer-Lahav wrote: > I suggest we address this particular scenario in the thread model > document. > > EHL > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Wednesday, September 14, 2011 7:26 AM >> To: Eran Hammer-Lahav >> Cc: Niv Steingarten; oauth@ietf.org >> Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner >> Impersonation) >> >> It is a native app and it is external wrt the browser. >> >> regards, >> Torsten. >> >> On Wed, 14 Sep 2011 06:59:47 -0700, Eran Hammer-Lahav wrote: >> > Is this malicious piece of software external a native application >> > either past of a native client or external to the browser? >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> >> Sent: Wednesday, September 14, 2011 6:51 AM >> >> To: Eran Hammer-Lahav >> >> Cc: Niv Steingarten; oauth@ietf.org >> >> Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource >> Owner >> >> Impersonation) >> >> >> >> Hi Eran, >> >> >> >> >> 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. >> >> >> >> >A textbook CSRF attack is when an attacker constructs a URI and >> >> then >> >> >manipulate a user-agent with an active session to call that. In >> the >> >> >simplest example, an >attacker constructs a URI that transfers a >> >> >million dollars from the current account to its, then tricks the >> >> user >> >> >to click on that link or automatically >redirects the user to >> that >> >> URI. >> >> > Because the user is already signed in and has an active session >> >> token, >> >> >the request goes through. >> >> >> >> >To prevent it, the request URI must include an artifact that >> binds >> >> the >> >> >request to the active session. Since the attacker has no way of >> >> >accessing the session >information, it cannot construct as a >> URI. >> >> In >> >> >practice, this means adding a hidden form parameter to the >> button >> >> with >> >> >some hash of the session information >that the server can >> verify. >> >> >> >> So I would conclude we have the same understanding of what CSRF >> >> means. >> >> >> >> >> 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. >> >> >> >> >Of course it matters. >> >> >> >> >The only way the attacker can get access is by calling the 'I >> >> agree' >> >> > button action via an active user session. The attacker cannot >> >> access >> >> >the hidden form >value with the session hash (or whatever the >> >> server is >> >> >using for CSRF protection). So whatever URI it constructs will >> not >> >> work >> >> >when called with the active >user session. >> >> >> >> My point is: the attacker in the threat I'm trying to describe >> does >> >> not need to create any URL since it just remote controls the >> >> user-agent. The malicous code runs outside of the browser and >> "just" >> >> uses the URLs provided by the authz server. Yes, there need to be >> a >> >> session. No, the attacker does not need to inject any URL he made >> up. >> >> >> >> >> 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. >> >> >> >> >I'm having a hard time following all these scenarios. But the >> >> >important part is that OAuth assumes the 'user-agent' is a >> >> compliant >> >> >and secure web browser. If >the user-agent does not enforce >> cookie >> >> >boundaries, XSS, CORS policy, etc. there isn't much we can do. >> In >> >> other >> >> >words, if the user installs a poorly design >native application >> >> which >> >> >has its own user-agent implementation opened to known web >> attacks, >> >> all >> >> >bets are off. >> >> > >> >> >The security model behind all these is pretty simple. The active >> >> user >> >> >session has to be protected from any external access by >> attackers >> >> and >> >> >enforce same-origin policy. >> >> >> >> What didn't you understand? I would be happy to improve my >> >> description. >> >> What I basically try to get across: a malicious piece of software >> >> running on the resource owners device can simulate her consent. >> As a >> >> pre-requisite the attacker must be able to either abuse an >> existing >> >> session or to create a new one. I gave four examples of how this >> >> could be achieved. At least the last has obviously nothing to do >> with >> >> browser security features. The threat also has nothing to do with >> >> poor design or user-agent implementation flaws. >> >> It is a >> >> deliberate attack against the resource owner. >> >> >> >> One could argue that prevention of malicous software is not the >> >> responsibility of the authz server. I could agree with that. But >> >> people seem to expect an OAuth authz server to cope with such >> >> attacks. That's why I believe we either clearly draw this >> boundary in >> >> the spec or give a hint on how to prevent this kind of threat. >> >> >> >> regards, >> >> Torsten. >> >> >I still don't see the need to add the proposed section. >> >> >> >> >EHL >> >> >> >> >> >> From daver@oldschoolindustriesllc.com Wed Sep 14 10:10: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 C049D21F8C5D for ; Wed, 14 Sep 2011 10:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 mvDRRnI5GFws for ; Wed, 14 Sep 2011 10:10:43 -0700 (PDT) Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.161.170]) by ietfa.amsl.com (Postfix) with ESMTP id 69CA321F8C57 for ; Wed, 14 Sep 2011 10:10:43 -0700 (PDT) Received: by gxk27 with SMTP id 27so2755032gxk.15 for ; Wed, 14 Sep 2011 10:12:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.27.17 with SMTP id a17mr103775ana.12.1316020372527; Wed, 14 Sep 2011 10:12:52 -0700 (PDT) Received: by 10.100.197.4 with HTTP; Wed, 14 Sep 2011 10:12:52 -0700 (PDT) X-Originating-IP: [67.169.69.75] In-Reply-To: <55876c26dbad646336c557dc22d67c40@lodderstedt-online.de> References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> <59CDCC16-44BA-4626-B744-F1169A13A542@oracle.com> <55876c26dbad646336c557dc22d67c40@lodderstedt-online.de> Date: Wed, 14 Sep 2011 10:12:52 -0700 Message-ID: From: Dave Rochwerger To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 14 Sep 2011 10:39:32 -0700 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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: Wed, 14 Sep 2011 17:10:44 -0000 Thanks for the follow up, Torsten. Whilst I have your attention - any thoughts on my second question, about the use of a client secret? If for all clients we mandated registered URIs and verified them (whether they are private and public), what additional security does the client secret actually provide for private clients in the authorization code flow? Thanks, Dave On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt wrote: > > Hi Dave, > > > On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote: > >> 1. "The user does not have to be present." >> Maybe I should be more clear. What benefit does that have over just a >> long-lived (forever) access token? The cost is the extra complication fo= r >> 3rd party developers to have to worry about refresh tokens. I can not se= e >> a benefit in our model (everything over SSL, etc) to use refresh tokens. >> I want to use refresh tokens - but only if there is a reason for them, >> which I can not see at the moment. > > > The benefit of refresh tokens significantly depends on your access token = design. If your access tokens are just a pointer to a database you lookup o= n any API call, the only benefit if token rotation (coming back to this top= ic below). But your access tokens could also directly contain all user data= you need to actually authorize API access. That way you could save DB look= ups, which scales much better. In this model, revocation is much can be eas= ier implement using refresh tokens. I think this is what Eran refered to. > > >> 2. "As Eran points out, you'd have to have do a DB lookup to have true >> revocation." >> The act of revoking tokens is not a common occurrence, DB lookups to >> revoke tokens is not a concern as there is more time spent by the user >> navigating the UI (or network latency, etc) than the cost of the DB call= . >> >> 3. "In this sense you get the best of a long-lived credential, combined >> with good key rotation and authorization re-verification without having >> to re-involve the end-user." >> That all sounds good, but in our situation (all SSL, etc) - what do we >> want key rotation and re-verification for? I fail to see a reasonable >> vector for access token leakage to warrant any of this in our case. > > > rotation is a mean to detect tokem theft from the device (see also http:/= /tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2). > > regards, > Torsten. > >> >> On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: >> >>> See below... >>> >>> Phil >>> @independentid >>> www.independentid.com [11] phil.hunt@oracle.com [12] >>> >>> >>> On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: >>> >>>> Hi Phil, >> The client is then forced to periodically reauthenticate >>>> (without the user) before getting a new access token. >>>> What benefit does that have? >>> >>> The user does not have to be present. >>> >>>>>> Refresh also gives the authzn server a chance to revoke access. >>>> >>>> Hence it is better to use shorter lived access tokens with long lived >>>> refresh tokens. >>>> That doesn't follow - we can just as easily revoke the single >>>> long-lived access token. >>> >>> As Eran points out, you'd have to have do a DB lookup to have true >>> revocation. But, by having a short expiration time on the access token >>> (say 1 hour or less), you get quasi-revocation which has to be >>> re-validated after the access token expires and the client has to >>> re-authenticate and provide a valid refresh token. In this sense you >>> get the best of a long-lived credential, combined with good key >>> rotation and authorization re-verification without having to re-involve >>> the end-user. >>> >>> Dave.> >>>> >>>> On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: >>>> >>>>> You can also use a long lived refresh token in combination with a >>>>> short access token. The client is then forced to periodically >>>>> reauthenticate (without the user) before getting a new access >>>>> token. >>>>> Refresh also gives the authzn server a chance to revoke access. >>>>> Hence it is better to use shorter lived access tokens with long >>>>> lived refresh tokens. >>>>> >>>>> Phil >>>>> >>>>> On 2011-09-07, at 15:27, William Mills wrote: >>>>> >>>>>> I'll talk to the refresh token question: they give you a hook for >>>>>> extensibility and key rotation. If you want to rotate your >>>>>> encryption keys or extend the data carried in the token in any >>>>>> way then you want to be able to cleanly refresh your tokens. Note >>>>>> that the refresh flow allows you to issue a new refresh token at >>>>>> the same time. It also allows a clean path to convert tokens in a >>>>>> new client if you decide you want SAML tokens instead of MAC for >>>>>> example. >>>>>> If you want those things you want to use refresh tokens. You can >>>>>> have long lived access tokens too, and just use the refresh >>>>>> tokens when you want to do something new with the access tokens. >>>>>> -bill >>>>>> >>>>>> ------------------------- >>>>>> FROM: Dave Rochwerger >>>>>> TO: oauth@ietf.org [2] >>>>>> CC: Quizlet Dev Team >>>>>> SENT: Wednesday, September 7, 2011 2:15 PM >>>>>> SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client >>>>>> >>>>>> secret and refresh tokens) >>>>>> >>>>>> Hi all, >>>>>> I have been implementing OAuth2 based on the various drafts for >>>>>> our new API. Initially, I implemented everything as per the spec, >>>>>> but due to our particular scenario and restrictions we have in >>>>>> place, there are some fundamental questions that I am unable to >>>>>> defend. >>>>>> I am hoping this group could help answer them for me. >>>>>> Our scenario: >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> * We are implementing an API to allow 3rd party developers to >>>>>> access users' protected resources via their applications. The >>>>>> applications will mostly be native phone apps, but some will have >>>>>> web server backends (javascript-only applications are not a >>>>>> concern at the moment). >>>>>> * We want to provide very long-lived (forever) tokens. >>>>>> * We are implementing the "authorization code" flow as that seems >>>>>> best suited to us (we don't want the implicit flow because >>>>>> end-users would have to re-authorize every hour). >>>>>> Our architecture: >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> * We control both the API server and the authorization server. >>>>>> * All requests to protected resources (ie: to the API server) are >>>>>> always done over SSL. >>>>>> * All requests to the authz server (token and authorize >>>>>> endpoints) are always done over SSL. >>>>>> * We enforce that every client must supply the state parameter >>>>>> (and our guidelines say they must verify the state for CSRF >>>>>> mitigation). >>>>>> * We enforce that every client must register a redirect URI. >>>>>> * We validate the redirect_uri used to request an access token is >>>>>> the same that was used to obtain the auth code. >>>>>> * The only time a request is not made over SSL is the redirect >>>>>> with the auth_code which is very short-lived (30 seconds) and is >>>>>> tied to a verified redirect URI. >>>>>> * We enforce that access tokens must be provided using the >>>>>> Authorization header only (and of course, over SSL). >>>>>> * We have guidelines saying that all mobile apps must use the >>>>>> native browser (and not an embedded web UI). >>>>>> Questions: >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D >>>>>> 1. Given the above scenario, what use are refresh tokens? >>>>>> - Access tokens can not leak because every request (to resource >>>>>> and authz server) containing an access token is done over SSL. We >>>>>> control both the authz and resource servers, so tokens in logs >>>>>> (and other suggested reasons in the archives) are not an issue. >>>>>> - Long-lived refresh tokens and short-lived access tokens are >>>>>> supposed to provide security due to possible access token >>>>>> leakage... but in our 100% SSL scenario, if access tokens are >>>>>> able to leak, then so would the client id, secret and refresh >>>>>> token. >>>>>> - Having a long-lived refresh token that can be exchanged for >>>>>> another access token adds a level of complexity (a second HTTPS >>>>>> request every so often) and seems to provide no benefit for our >>>>>> case. >>>>>> 2. What is the point of the client secret (in our scenario)? - >>>>>> We originally were treating the clients as confidential, but >>>>>> after re-reading the native-application section, it seems we >>>>>> really should treat them as public (phone apps can be decompiled >>>>>> and the secret discovered). >>>>>> >>>>>> - The spec says that the authz server should authenticate >>>>>> confidential clients, but public clients are allowed to just send >>>>>> their public client id (and no secret). >>>>>> - The only verification then, is to enforce redirect URI >>>>>> registration and to validate the redirect URI between >>>>>> authorization and token steps. >>>>>> >>>>>> So, the question is, assuming that we, one: "enforce >>>>>> redirect-URI registration" and two: "validate that URI" - why >>>>>> can't we treat all clients as public and not worry about a >>>>>> secret? >>>>>> What is the benefit of having confidential clients (and a secret) >>>>>> at all? >>>>>> Our API source is not available, but the oauth2 server >>>>>> implementation can be seen here: >>>>>> https://github.com/quizlet/oauth2-php [4] >>>>>> >>>>>> Regards, >>>>>> Dave >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org [5] >>>>>> https://www.ietf.org/mailman/listinfo/oauth [6] >>>>> >>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org [7] >>>>>> https://www.ietf.org/mailman/listinfo/oauth [8] > > > > > Links: > ------ > [1] mailto:daver@quizlet.com > [2] mailto:oauth@ietf.org > [3] mailto:devteam@quizlet.com > [4] https://github.com/quizlet/oauth2-php > [5] mailto:OAuth@ietf.org > [6] https://www.ietf.org/mailman/listinfo/oauth > [7] mailto:OAuth@ietf.org > [8] https://www.ietf.org/mailman/listinfo/oauth > [9] mailto:wmills@yahoo-inc.com > [10] mailto:phil.hunt@oracle.com > [11] http://www.independentid.com > [12] mailto:phil.hunt@oracle.com > [13] mailto:phil.hunt@oracle.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Sep 14 12:49: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 F170721F8726 for ; Wed, 14 Sep 2011 12:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.094, 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 OKIhexVkvdof for ; Wed, 14 Sep 2011 12:49:34 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) by ietfa.amsl.com (Postfix) with ESMTP id 63E7721F86DD for ; Wed, 14 Sep 2011 12:49:33 -0700 (PDT) Received: from [79.253.45.13] (helo=[192.168.71.35]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1R3vUk-0007yx-DK; Wed, 14 Sep 2011 21:51:42 +0200 Message-ID: <4E7105DD.7030507@lodderstedt.net> Date: Wed, 14 Sep 2011 21:51:57 +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: Dave Rochwerger References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> <59CDCC16-44BA-4626-B744-F1169A13A542@oracle.com> <55876c26dbad646336c557dc22d67c40@lodderstedt-online.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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: Wed, 14 Sep 2011 19:49:36 -0000 Hi Dave, redirect URI validation does not authenticate a client. For example, a URI registered for a private web client could be used by a (malicious) native app to assume the web app's identity. The client secret, in contrast, can be used to authenticate it. regards, Torsten. Am 14.09.2011 19:12, schrieb Dave Rochwerger: > Thanks for the follow up, Torsten. > > Whilst I have your attention - any thoughts on my second question, > about the use of a client secret? > If for all clients we mandated registered URIs and verified them > (whether they are private and public), what additional security does > the client secret actually provide for private clients in the > authorization code flow? > > > Thanks, > Dave > > On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt > wrote: >> Hi Dave, >> >> >> On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote: >> >>> 1. "The user does not have to be present." >>> Maybe I should be more clear. What benefit does that have over just a >>> long-lived (forever) access token? The cost is the extra complication for >>> 3rd party developers to have to worry about refresh tokens. I can not see >>> a benefit in our model (everything over SSL, etc) to use refresh tokens. >>> I want to use refresh tokens - but only if there is a reason for them, >>> which I can not see at the moment. >> >> The benefit of refresh tokens significantly depends on your access token design. If your access tokens are just a pointer to a database you lookup on any API call, the only benefit if token rotation (coming back to this topic below). But your access tokens could also directly contain all user data you need to actually authorize API access. That way you could save DB lookups, which scales much better. In this model, revocation is much can be easier implement using refresh tokens. I think this is what Eran refered to. >> >> >>> 2. "As Eran points out, you'd have to have do a DB lookup to have true >>> revocation." >>> The act of revoking tokens is not a common occurrence, DB lookups to >>> revoke tokens is not a concern as there is more time spent by the user >>> navigating the UI (or network latency, etc) than the cost of the DB call. >>> >>> 3. "In this sense you get the best of a long-lived credential, combined >>> with good key rotation and authorization re-verification without having >>> to re-involve the end-user." >>> That all sounds good, but in our situation (all SSL, etc) - what do we >>> want key rotation and re-verification for? I fail to see a reasonable >>> vector for access token leakage to warrant any of this in our case. >> >> rotation is a mean to detect tokem theft from the device (see also http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2). >> >> regards, >> Torsten. >> >>> On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: >>> >>>> See below... >>>> >>>> Phil >>>> @independentid >>>> www.independentid.com [11] phil.hunt@oracle.com [12] >>>> >>>> >>>> On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: >>>> >>>>> Hi Phil,>> The client is then forced to periodically reauthenticate >>>>> (without the user) before getting a new access token. >>>>> What benefit does that have? >>>> The user does not have to be present. >>>> >>>>>>> Refresh also gives the authzn server a chance to revoke access. >>>>> Hence it is better to use shorter lived access tokens with long lived >>>>> refresh tokens. >>>>> That doesn't follow - we can just as easily revoke the single >>>>> long-lived access token. >>>> As Eran points out, you'd have to have do a DB lookup to have true >>>> revocation. But, by having a short expiration time on the access token >>>> (say 1 hour or less), you get quasi-revocation which has to be >>>> re-validated after the access token expires and the client has to >>>> re-authenticate and provide a valid refresh token. In this sense you >>>> get the best of a long-lived credential, combined with good key >>>> rotation and authorization re-verification without having to re-involve >>>> the end-user. >>>> >>>> Dave.> >>>>> On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: >>>>> >>>>>> You can also use a long lived refresh token in combination with a >>>>>> short access token. The client is then forced to periodically >>>>>> reauthenticate (without the user) before getting a new access >>>>>> token. >>>>>> Refresh also gives the authzn server a chance to revoke access. >>>>>> Hence it is better to use shorter lived access tokens with long >>>>>> lived refresh tokens. >>>>>> >>>>>> Phil >>>>>> >>>>>> On 2011-09-07, at 15:27, William Mills wrote: >>>>>> >>>>>>> I'll talk to the refresh token question: they give you a hook for >>>>>>> extensibility and key rotation. If you want to rotate your >>>>>>> encryption keys or extend the data carried in the token in any >>>>>>> way then you want to be able to cleanly refresh your tokens. Note >>>>>>> that the refresh flow allows you to issue a new refresh token at >>>>>>> the same time. It also allows a clean path to convert tokens in a >>>>>>> new client if you decide you want SAML tokens instead of MAC for >>>>>>> example. >>>>>>> If you want those things you want to use refresh tokens. You can >>>>>>> have long lived access tokens too, and just use the refresh >>>>>>> tokens when you want to do something new with the access tokens. >>>>>>> -bill >>>>>>> >>>>>>> ------------------------- >>>>>>> FROM: Dave Rochwerger >>>>>>> TO: oauth@ietf.org [2] >>>>>>> CC: Quizlet Dev Team >>>>>>> SENT: Wednesday, September 7, 2011 2:15 PM >>>>>>> SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client >>>>>>> >>>>>>> secret and refresh tokens) >>>>>>> >>>>>>> Hi all, >>>>>>> I have been implementing OAuth2 based on the various drafts for >>>>>>> our new API. Initially, I implemented everything as per the spec, >>>>>>> but due to our particular scenario and restrictions we have in >>>>>>> place, there are some fundamental questions that I am unable to >>>>>>> defend. >>>>>>> I am hoping this group could help answer them for me. >>>>>>> Our scenario: >>>>>>> ========== >>>>>>> * We are implementing an API to allow 3rd party developers to >>>>>>> access users' protected resources via their applications. The >>>>>>> applications will mostly be native phone apps, but some will have >>>>>>> web server backends (javascript-only applications are not a >>>>>>> concern at the moment). >>>>>>> * We want to provide very long-lived (forever) tokens. >>>>>>> * We are implementing the "authorization code" flow as that seems >>>>>>> best suited to us (we don't want the implicit flow because >>>>>>> end-users would have to re-authorize every hour). >>>>>>> Our architecture: >>>>>>> ============ >>>>>>> * We control both the API server and the authorization server. >>>>>>> * All requests to protected resources (ie: to the API server) are >>>>>>> always done over SSL. >>>>>>> * All requests to the authz server (token and authorize >>>>>>> endpoints) are always done over SSL. >>>>>>> * We enforce that every client must supply the state parameter >>>>>>> (and our guidelines say they must verify the state for CSRF >>>>>>> mitigation). >>>>>>> * We enforce that every client must register a redirect URI. >>>>>>> * We validate the redirect_uri used to request an access token is >>>>>>> the same that was used to obtain the auth code. >>>>>>> * The only time a request is not made over SSL is the redirect >>>>>>> with the auth_code which is very short-lived (30 seconds) and is >>>>>>> tied to a verified redirect URI. >>>>>>> * We enforce that access tokens must be provided using the >>>>>>> Authorization header only (and of course, over SSL). >>>>>>> * We have guidelines saying that all mobile apps must use the >>>>>>> native browser (and not an embedded web UI). >>>>>>> Questions: >>>>>>> ======== >>>>>>> 1. Given the above scenario, what use are refresh tokens? >>>>>>> - Access tokens can not leak because every request (to resource >>>>>>> and authz server) containing an access token is done over SSL. We >>>>>>> control both the authz and resource servers, so tokens in logs >>>>>>> (and other suggested reasons in the archives) are not an issue. >>>>>>> - Long-lived refresh tokens and short-lived access tokens are >>>>>>> supposed to provide security due to possible access token >>>>>>> leakage... but in our 100% SSL scenario, if access tokens are >>>>>>> able to leak, then so would the client id, secret and refresh >>>>>>> token. >>>>>>> - Having a long-lived refresh token that can be exchanged for >>>>>>> another access token adds a level of complexity (a second HTTPS >>>>>>> request every so often) and seems to provide no benefit for our >>>>>>> case. >>>>>>> 2. What is the point of the client secret (in our scenario)? - >>>>>>> We originally were treating the clients as confidential, but >>>>>>> after re-reading the native-application section, it seems we >>>>>>> really should treat them as public (phone apps can be decompiled >>>>>>> and the secret discovered). >>>>>>> >>>>>>> - The spec says that the authz server should authenticate >>>>>>> confidential clients, but public clients are allowed to just send >>>>>>> their public client id (and no secret). >>>>>>> - The only verification then, is to enforce redirect URI >>>>>>> registration and to validate the redirect URI between >>>>>>> authorization and token steps. >>>>>>> >>>>>>> So, the question is, assuming that we, one: "enforce >>>>>>> redirect-URI registration" and two: "validate that URI" - why >>>>>>> can't we treat all clients as public and not worry about a >>>>>>> secret? >>>>>>> What is the benefit of having confidential clients (and a secret) >>>>>>> at all? >>>>>>> Our API source is not available, but the oauth2 server >>>>>>> implementation can be seen here: >>>>>>> https://github.com/quizlet/oauth2-php [4] >>>>>>> >>>>>>> Regards, >>>>>>> Dave >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org [5] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth [6] >>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org [7] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth [8] >> >> >> >> Links: >> ------ >> [1] mailto:daver@quizlet.com >> [2] mailto:oauth@ietf.org >> [3] mailto:devteam@quizlet.com >> [4] https://github.com/quizlet/oauth2-php >> [5] mailto:OAuth@ietf.org >> [6] https://www.ietf.org/mailman/listinfo/oauth >> [7] mailto:OAuth@ietf.org >> [8] https://www.ietf.org/mailman/listinfo/oauth >> [9] mailto:wmills@yahoo-inc.com >> [10] mailto:phil.hunt@oracle.com >> [11] http://www.independentid.com >> [12] mailto:phil.hunt@oracle.com >> [13] mailto:phil.hunt@oracle.com >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From daver@quizlet.com Wed Sep 14 13:43: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 DB62821F8AB8 for ; Wed, 14 Sep 2011 13:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, 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 r7xf0GYW-Avv for ; Wed, 14 Sep 2011 13:43:56 -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 DB87321F8A57 for ; Wed, 14 Sep 2011 13:43:55 -0700 (PDT) Received: by yie12 with SMTP id 12so1980144yie.31 for ; Wed, 14 Sep 2011 13:46:05 -0700 (PDT) Received: by 10.90.24.26 with SMTP id 26mr301535agx.114.1316033164965; Wed, 14 Sep 2011 13:46:04 -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 b4sm9837249ank.3.2011.09.14.13.46.02 (version=SSLv3 cipher=OTHER); Wed, 14 Sep 2011 13:46:03 -0700 (PDT) Received: by gyd12 with SMTP id 12so1973068gyd.31 for ; Wed, 14 Sep 2011 13:46:02 -0700 (PDT) Received: by 10.100.27.17 with SMTP id a17mr323354ana.12.1316033162158; Wed, 14 Sep 2011 13:46:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.197.4 with HTTP; Wed, 14 Sep 2011 13:45:42 -0700 (PDT) X-Originating-IP: [67.169.69.75] In-Reply-To: <4E7105DD.7030507@lodderstedt.net> References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com> <0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> <59CDCC16-44BA-4626-B744-F1169A13A542@oracle.com> <55876c26dbad646336c557dc22d67c40@lodderstedt-online.de> <4E7105DD.7030507@lodderstedt.net> From: Dave Rochwerger Date: Wed, 14 Sep 2011 13:45:42 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001485f7757c24a3e604acecd9f5 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and 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: Wed, 14 Sep 2011 20:43:58 -0000 --001485f7757c24a3e604acecd9f5 Content-Type: text/plain; charset=ISO-8859-1 Is this a security issue in the OAuth2 process then (for mobile apps using the authorization code flow)? 1. The draft says that mobile apps should be considered public clients because mobile apps can be decompiled and can not keep their credentials private. 2. In this case then, the draft says for these mobile apps to not authenticate with the secret and instead for the server to verify the redirect URI (and make it mandatory). 3. You said that verifying the redirect URI is not good enough to verify the client's identity. What am I missing? Thanks, Dave On Wed, Sep 14, 2011 at 12:51 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi Dave, > > redirect URI validation does not authenticate a client. For example, a URI > registered for a private web client could be used by a (malicious) native > app to assume the web app's identity. The client secret, in contrast, can be > used to authenticate it. > > regards, > Torsten. > > Am 14.09.2011 19:12, schrieb Dave Rochwerger: > > Thanks for the follow up, Torsten. >> >> Whilst I have your attention - any thoughts on my second question, >> about the use of a client secret? >> If for all clients we mandated registered URIs and verified them >> (whether they are private and public), what additional security does >> the client secret actually provide for private clients in the >> authorization code flow? >> >> >> Thanks, >> Dave >> >> On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt >> wrote: >> >>> Hi Dave, >>> >>> >>> On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote: >>> >>> 1. "The user does not have to be present." >>>> Maybe I should be more clear. What benefit does that have over just a >>>> long-lived (forever) access token? The cost is the extra complication >>>> for >>>> 3rd party developers to have to worry about refresh tokens. I can not >>>> see >>>> a benefit in our model (everything over SSL, etc) to use refresh tokens. >>>> I want to use refresh tokens - but only if there is a reason for them, >>>> which I can not see at the moment. >>>> >>> >>> The benefit of refresh tokens significantly depends on your access token >>> design. If your access tokens are just a pointer to a database you lookup on >>> any API call, the only benefit if token rotation (coming back to this topic >>> below). But your access tokens could also directly contain all user data you >>> need to actually authorize API access. That way you could save DB lookups, >>> which scales much better. In this model, revocation is much can be easier >>> implement using refresh tokens. I think this is what Eran refered to. >>> >>> >>> 2. "As Eran points out, you'd have to have do a DB lookup to have true >>>> revocation." >>>> The act of revoking tokens is not a common occurrence, DB lookups to >>>> revoke tokens is not a concern as there is more time spent by the user >>>> navigating the UI (or network latency, etc) than the cost of the DB >>>> call. >>>> >>>> 3. "In this sense you get the best of a long-lived credential, combined >>>> with good key rotation and authorization re-verification without having >>>> to re-involve the end-user." >>>> That all sounds good, but in our situation (all SSL, etc) - what do we >>>> want key rotation and re-verification for? I fail to see a reasonable >>>> vector for access token leakage to warrant any of this in our case. >>>> >>> >>> rotation is a mean to detect tokem theft from the device (see also >>> http://tools.ietf.org/html/**draft-lodderstedt-oauth-** >>> security-01#section-4.1.2 >>> ). >>> >>> regards, >>> Torsten. >>> >>> On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: >>>> >>>> See below... >>>>> >>>>> Phil >>>>> @independentid >>>>> www.independentid.com [11] phil.hunt@oracle.com [12] >>>>> >>>>> >>>>> On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: >>>>> >>>>> Hi Phil,>> The client is then forced to periodically reauthenticate >>>>>> (without the user) before getting a new access token. >>>>>> What benefit does that have? >>>>>> >>>>> The user does not have to be present. >>>>> >>>>> Refresh also gives the authzn server a chance to revoke access. >>>>>>>> >>>>>>> Hence it is better to use shorter lived access tokens with long lived >>>>>> refresh tokens. >>>>>> That doesn't follow - we can just as easily revoke the single >>>>>> long-lived access token. >>>>>> >>>>> As Eran points out, you'd have to have do a DB lookup to have true >>>>> revocation. But, by having a short expiration time on the access token >>>>> (say 1 hour or less), you get quasi-revocation which has to be >>>>> re-validated after the access token expires and the client has to >>>>> re-authenticate and provide a valid refresh token. In this sense you >>>>> get the best of a long-lived credential, combined with good key >>>>> rotation and authorization re-verification without having to re-involve >>>>> the end-user. >>>>> >>>>> Dave.> >>>>> >>>>>> On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: >>>>>> >>>>>> You can also use a long lived refresh token in combination with a >>>>>>> short access token. The client is then forced to periodically >>>>>>> reauthenticate (without the user) before getting a new access >>>>>>> token. >>>>>>> Refresh also gives the authzn server a chance to revoke access. >>>>>>> Hence it is better to use shorter lived access tokens with long >>>>>>> lived refresh tokens. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On 2011-09-07, at 15:27, William Mills wrote: >>>>>>> >>>>>>> I'll talk to the refresh token question: they give you a hook for >>>>>>>> extensibility and key rotation. If you want to rotate your >>>>>>>> encryption keys or extend the data carried in the token in any >>>>>>>> way then you want to be able to cleanly refresh your tokens. Note >>>>>>>> that the refresh flow allows you to issue a new refresh token at >>>>>>>> the same time. It also allows a clean path to convert tokens in a >>>>>>>> new client if you decide you want SAML tokens instead of MAC for >>>>>>>> example. >>>>>>>> If you want those things you want to use refresh tokens. You can >>>>>>>> have long lived access tokens too, and just use the refresh >>>>>>>> tokens when you want to do something new with the access tokens. >>>>>>>> -bill >>>>>>>> >>>>>>>> ------------------------- >>>>>>>> FROM: Dave Rochwerger >>>>>>>> TO: oauth@ietf.org [2] >>>>>>>> CC: Quizlet Dev Team >>>>>>>> SENT: Wednesday, September 7, 2011 2:15 PM >>>>>>>> SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client >>>>>>>> >>>>>>>> secret and refresh tokens) >>>>>>>> >>>>>>>> Hi all, >>>>>>>> I have been implementing OAuth2 based on the various drafts for >>>>>>>> our new API. Initially, I implemented everything as per the spec, >>>>>>>> but due to our particular scenario and restrictions we have in >>>>>>>> place, there are some fundamental questions that I am unable to >>>>>>>> defend. >>>>>>>> I am hoping this group could help answer them for me. >>>>>>>> Our scenario: >>>>>>>> ========== >>>>>>>> * We are implementing an API to allow 3rd party developers to >>>>>>>> access users' protected resources via their applications. The >>>>>>>> applications will mostly be native phone apps, but some will have >>>>>>>> web server backends (javascript-only applications are not a >>>>>>>> concern at the moment). >>>>>>>> * We want to provide very long-lived (forever) tokens. >>>>>>>> * We are implementing the "authorization code" flow as that seems >>>>>>>> best suited to us (we don't want the implicit flow because >>>>>>>> end-users would have to re-authorize every hour). >>>>>>>> Our architecture: >>>>>>>> ============ >>>>>>>> * We control both the API server and the authorization server. >>>>>>>> * All requests to protected resources (ie: to the API server) are >>>>>>>> always done over SSL. >>>>>>>> * All requests to the authz server (token and authorize >>>>>>>> endpoints) are always done over SSL. >>>>>>>> * We enforce that every client must supply the state parameter >>>>>>>> (and our guidelines say they must verify the state for CSRF >>>>>>>> mitigation). >>>>>>>> * We enforce that every client must register a redirect URI. >>>>>>>> * We validate the redirect_uri used to request an access token is >>>>>>>> the same that was used to obtain the auth code. >>>>>>>> * The only time a request is not made over SSL is the redirect >>>>>>>> with the auth_code which is very short-lived (30 seconds) and is >>>>>>>> tied to a verified redirect URI. >>>>>>>> * We enforce that access tokens must be provided using the >>>>>>>> Authorization header only (and of course, over SSL). >>>>>>>> * We have guidelines saying that all mobile apps must use the >>>>>>>> native browser (and not an embedded web UI). >>>>>>>> Questions: >>>>>>>> ======== >>>>>>>> 1. Given the above scenario, what use are refresh tokens? >>>>>>>> - Access tokens can not leak because every request (to resource >>>>>>>> and authz server) containing an access token is done over SSL. We >>>>>>>> control both the authz and resource servers, so tokens in logs >>>>>>>> (and other suggested reasons in the archives) are not an issue. >>>>>>>> - Long-lived refresh tokens and short-lived access tokens are >>>>>>>> supposed to provide security due to possible access token >>>>>>>> leakage... but in our 100% SSL scenario, if access tokens are >>>>>>>> able to leak, then so would the client id, secret and refresh >>>>>>>> token. >>>>>>>> - Having a long-lived refresh token that can be exchanged for >>>>>>>> another access token adds a level of complexity (a second HTTPS >>>>>>>> request every so often) and seems to provide no benefit for our >>>>>>>> case. >>>>>>>> 2. What is the point of the client secret (in our scenario)? - >>>>>>>> We originally were treating the clients as confidential, but >>>>>>>> after re-reading the native-application section, it seems we >>>>>>>> really should treat them as public (phone apps can be decompiled >>>>>>>> and the secret discovered). >>>>>>>> >>>>>>>> - The spec says that the authz server should authenticate >>>>>>>> confidential clients, but public clients are allowed to just send >>>>>>>> their public client id (and no secret). >>>>>>>> - The only verification then, is to enforce redirect URI >>>>>>>> registration and to validate the redirect URI between >>>>>>>> authorization and token steps. >>>>>>>> >>>>>>>> So, the question is, assuming that we, one: "enforce >>>>>>>> redirect-URI registration" and two: "validate that URI" - why >>>>>>>> can't we treat all clients as public and not worry about a >>>>>>>> secret? >>>>>>>> What is the benefit of having confidential clients (and a secret) >>>>>>>> at all? >>>>>>>> Our API source is not available, but the oauth2 server >>>>>>>> implementation can be seen here: >>>>>>>> https://github.com/quizlet/**oauth2-php[4] >>>>>>>> >>>>>>>> Regards, >>>>>>>> Dave >>>>>>>> >>>>>>>> ______________________________**_________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org [5] >>>>>>>> https://www.ietf.org/mailman/**listinfo/oauth[6] >>>>>>>> >>>>>>> >>>>>>> ______________________________**_________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org [7] >>>>>>>> https://www.ietf.org/mailman/**listinfo/oauth[8] >>>>>>>> >>>>>>> >>> >>> >>> Links: >>> ------ >>> [1] mailto:daver@quizlet.com >>> [2] mailto:oauth@ietf.org >>> [3] mailto:devteam@quizlet.com >>> [4] https://github.com/quizlet/**oauth2-php >>> [5] mailto:OAuth@ietf.org >>> [6] https://www.ietf.org/mailman/**listinfo/oauth >>> [7] mailto:OAuth@ietf.org >>> [8] https://www.ietf.org/mailman/**listinfo/oauth >>> [9] mailto:wmills@yahoo-inc.com >>> [10] mailto:phil.hunt@oracle.com >>> [11] http://www.independentid.com >>> [12] mailto:phil.hunt@oracle.com >>> [13] mailto:phil.hunt@oracle.com >>> >>> ______________________________**_________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/**listinfo/oauth >>> >> --001485f7757c24a3e604acecd9f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Is this a security issue in the OAuth2 process then (for mobile apps u= sing the authorization code flow)?

1. The draft sa= ys that mobile apps should be considered public clients because mobile apps= can be decompiled and can not keep their credentials private.
2. In this case then, the draft says for these mobile apps to not auth= enticate with the secret and instead for the server to verify the redirect = URI (and make it mandatory).
3. You said that verifying the redir= ect URI is not good enough to verify the client's identity.

What am I missing?

Thanks,
Dave


On Wed, Sep 14, 20= 11 at 12:51 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Dave,

redirect URI validation does not authenticate a client. For example, a URI = registered for a private web client could be used by a (malicious) native a= pp to assume the web app's identity. The client secret, in contrast, ca= n be used to authenticate it.

regards,
Torsten.

Am 14.09.2011 19:12, schrieb Dave Rochwerger:

Thanks for the follow up, Torsten.

Whilst I have your attention - any thoughts on my second question,
about the use of a client secret?
If for all clients we mandated registered URIs and verified them
(whether they are private and public), what additional security does
the client secret actually provide for private clients in the
authorization code flow?


Thanks,
Dave

On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt
<torsten@lo= dderstedt.net> =A0wrote:
Hi Dave,


On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote:

1. "The user does not have to be present."
Maybe I should be more clear. What benefit does that have over just a
long-lived (forever) access token? The cost is the extra complication for 3rd party developers to have to worry about refresh tokens. I can not see a benefit in our model (everything over SSL, etc) to use refresh tokens. I want to use refresh tokens - but only if there is a reason for them,
which I can not see at the moment.

The benefit of refresh tokens significantly depends on your access token de= sign. If your access tokens are just a pointer to a database you lookup on = any API call, the only benefit if token rotation (coming back to this topic= below). But your access tokens could also directly contain all user data y= ou need to actually authorize API access. That way you could save DB lookup= s, which scales much better. In this model, revocation is much can be easie= r implement using refresh tokens. I think this is what Eran refered to.


2. "As Eran points out, you'd have to have do a DB lookup to have = true
revocation."
The act of revoking tokens is not a common occurrence, DB lookups to
revoke tokens is not a concern as there is more time spent by the user
navigating the UI (or network latency, etc) than the cost of the DB call.
3. "In this sense you get the best of a long-lived credential, combine= d
with good key rotation and authorization re-verification without having
to re-involve the end-user."
That all sounds good, but in our situation (all SSL, etc) - what do we
want key rotation and re-verification for? I fail to see a reasonable
vector for access token leakage to warrant any of this in our case.

rotation is a mean to detect tokem theft from the device (see also http://tools.ietf.org/html/draft-loddersted= t-oauth-security-01#section-4.1.2).

regards,
Torsten.

On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote:

See below...

Phil
@independentid
www.independenti= d.com [11] ph= il.hunt@oracle.com [12]


On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote:

Hi Phil,>> =A0The client is then forced to periodically reauthenticat= e
(without the user) before getting a new access token.
What benefit does that have?
The user does not have to be present.

Refresh also gives the authzn server a chance to revoke access.
Hence it is better to use shorter lived access tokens with long lived
refresh tokens.
That doesn't follow - we can just as easily revoke the single
long-lived access token.
As Eran points out, you'd have to have do a DB lookup to have true
revocation. But, by having a short expiration time on the access token
(say 1 hour or less), you get quasi-revocation which has to be
re-validated after the access token expires and the client has to
re-authenticate and provide a valid refresh token. In this sense you
get the best of a long-lived credential, combined with good key
rotation and authorization re-verification without having to re-involve
the end-user.

Dave.>
On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote:

You can also use a long lived refresh token in combination with a
short access token. The client is then forced to periodically
reauthenticate (without the user) before getting a new access
token.
Refresh also gives the authzn server a chance to revoke access.
Hence it is better to use shorter lived access tokens with long
lived refresh tokens.

Phil

On 2011-09-07, at 15:27, William Mills wrote:

I'll talk to the refresh token question: they give you a hook for
extensibility and key rotation. If you want to rotate your
encryption keys or extend the data carried in the token in any
way then you want to be able to cleanly refresh your tokens. Note
that the refresh flow allows you to issue a new refresh token at
the same time. It also allows a clean path to convert tokens in a
new client if you decide you want SAML tokens instead of MAC for
example.
If you want those things you want to use refresh tokens. You can
have long lived access tokens too, and just use the refresh
tokens when you want to do something new with the access tokens.
-bill

-------------------------
FROM: Dave Rochwerger
TO: oauth@ietf.org = [2]
CC: Quizlet Dev Team
SENT: Wednesday, September 7, 2011 2:15 PM
SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client

secret and refresh tokens)

Hi all,
I have been implementing OAuth2 based on the various drafts for
our new API. Initially, I implemented everything as per the spec,
but due to our particular scenario and restrictions we have in
place, there are some fundamental questions that I am unable to
defend.
I am hoping this group could help answer them for me.
Our scenario:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* We are implementing an API to allow 3rd party developers to
access users' protected resources via their applications. The
applications will mostly be native phone apps, but some will have
web server backends (javascript-only applications are not a
concern at the moment).
* We want to provide very long-lived (forever) tokens.
* We are implementing the "authorization code" flow as that seems=
best suited to us (we don't want the implicit flow because
end-users would have to re-authorize every hour).
Our architecture:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* We control both the API server and the authorization server.
* All requests to protected resources (ie: to the API server) are
always done over SSL.
* All requests to the authz server (token and authorize
endpoints) are always done over SSL.
* We enforce that every client must supply the state parameter
(and our guidelines say they must verify the state for CSRF
mitigation).
* We enforce that every client must register a redirect URI.
* We validate the redirect_uri used to request an access token is
the same that was used to obtain the auth code.
* The only time a request is not made over SSL is the redirect
with the auth_code which is very short-lived (30 seconds) and is
tied to a verified redirect URI.
* We enforce that access tokens must be provided using the
Authorization header only (and of course, over SSL).
* We have guidelines saying that all mobile apps must use the
native browser (and not an embedded web UI).
Questions:
=3D=3D=3D=3D=3D=3D=3D=3D
1. Given the above scenario, what use are refresh tokens?
- Access tokens can not leak because every request (to resource
and authz server) containing an access token is done over SSL. We
control both the authz and resource servers, so tokens in logs
(and other suggested reasons in the archives) are not an issue.
- Long-lived refresh tokens and short-lived access tokens are
supposed to provide security due to possible access token
leakage... but in our 100% SSL scenario, if access tokens are
able to leak, then so would the client id, secret and refresh
token.
- Having a long-lived refresh token that can be exchanged for
another access token adds a level of complexity (a second HTTPS
request every so often) and seems to provide no benefit for our
case.
2. What is the point of the client secret (in our scenario)? -
We originally were treating the clients as confidential, but
after re-reading the native-application section, it seems we
really should treat them as public (phone apps can be decompiled
and the secret discovered).

- The spec says that the authz server should authenticate
confidential clients, but public clients are allowed to just send
their public client id (and no secret).
- The only verification then, is to enforce redirect URI
registration and to validate the redirect URI between
authorization and token steps.

So, the question is, assuming that we, one: "enforce
redirect-URI registration" and two: "validate that URI" - wh= y
can't we treat all clients as public and not worry about a
secret?
What is the benefit of having confidential clients (and a secret)
at all?
Our API source is not available, but the oauth2 server
implementation can be seen here:
https:/= /github.com/quizlet/oauth2-php [4]

Regards,
Dave

_______________________________________________
OAuth mailing list
OAuth@ietf.org [5]<= br> h= ttps://www.ietf.org/mailman/listinfo/oauth [6]

_______________________________________________
OAuth mailing list
OAuth@ietf.org [7]<= br> h= ttps://www.ietf.org/mailman/listinfo/oauth [8]



Links:
------
[1] mailto:daver@qui= zlet.com
[2] mailto:oauth@ietf.o= rg
[3] mailto:devteam= @quizlet.com
[4] htt= ps://github.com/quizlet/oauth2-php
[5] mailto:OAuth@ietf.o= rg
[6] https://www.ietf.org/mailman/listinfo/oauth
[7] mailto:OAuth@ietf.o= rg
[8] https://www.ietf.org/mailman/listinfo/oauth
[9] mailto:wmills= @yahoo-inc.com
[10] mailto:phil.= hunt@oracle.com
[11] http://www.= independentid.com
[12] mailto:phil.= hunt@oracle.com
[13] mailto:phil.= hunt@oracle.com

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

--001485f7757c24a3e604acecd9f5-- From andredemarre@gmail.com Wed Sep 14 17:22: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 A94A821F8C0C for ; Wed, 14 Sep 2011 17:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 dQT1wJxzml4E for ; Wed, 14 Sep 2011 17:22:54 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B97DB21F8C10 for ; Wed, 14 Sep 2011 17:22:54 -0700 (PDT) Received: by iaby26 with SMTP id y26so730402iab.31 for ; Wed, 14 Sep 2011 17:25:05 -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 :content-type:content-transfer-encoding; bh=2IIP6vPtbtbZKmijxqsyTzocaaS7dD24yQ1L71Z01QI=; b=IMQKLutUaZ7d78xBQYFKRaeDoIAhqGaZEEnYMRjwj1VImITKQ+rvd3XX/UlRqScgbN zfFdi6m6sHoiYePX5tmjx0gQX/HrACCnQErJsCn92XEBhNxa6hyhaRuiXE3VkvhiT9wy 8QXjsfQ3vT5/c8effMMAaFBdxQyIUtvbuhm1k= MIME-Version: 1.0 Received: by 10.42.243.134 with SMTP id lm6mr24603icb.141.1316046303980; Wed, 14 Sep 2011 17:25:03 -0700 (PDT) Received: by 10.42.18.129 with HTTP; Wed, 14 Sep 2011 17:25:03 -0700 (PDT) In-Reply-To: References: <4E6E4FEA.7090100@sunet.se> <4E6E735D.3050806@cs.tcd.ie> Date: Wed, 14 Sep 2011 17:25:03 -0700 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 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, 15 Sep 2011 00:22:57 -0000 I agree that stating "Clients in possession of a client password MAY use the HTTP Basic authentication scheme" [Section 2.3.1 paragraph 1] implies that authorization servers MUST support HTTP basic authentication, but such is never asserted. Instead, it says "The authorization server MAY accept any form of client authentication meeting its security requirements." [Section 2.3 paragraph 1] This is somewhat contradictory. I can understand that requiring a specific method of client authentication is desirable for maximum interoperability, but this would be problematic for authorization server implementations that wish to enforce stronger security than HTTP Basic. Such implementations would be forced to deviate from the specification. In particular, implementations which choose MAC access tokens instead of Bearer tokens may wish to add a layer of security to defend against improperly configured TLS connections, or to protect clients who connect to the wrong server. [http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/] Such implementations will also find HTTP Basic undesirable for client authentication. To require a form of client authentication that isn't universally sufficient could become a source of criticism and deter adoption of OAuth 2.0. I think the best solution is to clarify section 2.3.1 as follows: --- Clients in possession of client credentials MAY use any form of authentication scheme supported by the authorization server. --- And then follow with the existing example that demonstrates HTTP Basic. Regards, Andre DeMarre On Tue, Sep 13, 2011 at 4:52 PM, Greg Brail wrote: > I would like to add my support to the comments below on section 2.3, > specifically 2.3.1. > > It is clear to me from reading section 2.3 that clients MAY use HTTP > basic, or they MAY include client_id and client_secret in the request > body -- however, the latter is not recommended. > > It is not clear what the authorization server MUST support. IMHO, that > leads us to a situation in which there is no universally-agreed set of > authentication technology that all programmers can assume is going to > work, which means that interoperability will be difficult as some > authorization servers will support Basic, others will support the > request body, and others will do neither in favor of something else. > > I would prefer that we make both HTTP basic AND the request body > mechanisms in this section both required on the server side, thus > giving the client the option of choosing one or the other. That would > mean re-writing the beginning of section 2.3.1 as shown below. > > If I have missed other discussion on this topic I apologize. If there > is already consensus to make the "message body" authentication > optional rather than required for the authorization SERVER then I > would still recommend that we make HTTP Basic a MUST in order to allow > easier interop. > > Proposed change to 2.3.1: > > ---- > > The authorization server MUST support the HTTP Basic authentication > scheme as defined in [RFC2617] as a way to identify clients. The > client identifier is used as the username, and the client password is > used as the password. > > For example (extra line breaks are for display purposes only): > > =A0 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > Alternatively, the authorization server MUST also allow the client to > include the=A0client credentials in the request body using the following > parameters: > > =A0 client_id > =A0 =A0 =A0 =A0 REQUIRED. =A0The client identifier issued to the client d= uring > =A0 =A0 =A0 =A0 the registration process described by Section 2.2. > =A0 client_secret > =A0 =A0 =A0 =A0 REQUIRED. =A0The client secret. =A0The client MAY omit th= e > =A0 =A0 =A0 =A0 parameter if the client secret is an empty string. > > Clients in possession of a client password MAY use either mechanism in > order to authenticate with the authorization server. However, > including the client credentials in the request body using the two > parameters is NOT RECOMMENDED, and should be limited to clients unable > to directly utilize the HTTP Basic authentication scheme (or other > password-based HTTP authentication schemes). > > =A0(Rest of section remains as-is with the paragraph beginning "For examp= le...") > > Gregory Brail=A0=A0 |=A0=A0 Technology=A0=A0 |=A0=A0 Apigee=A0=A0 | =A0= =A0+1-650-937-9302 > > On Mon, Sep 12, 2011 at 2:02 PM, Stephen Farrell > wrote: >> >> FYI, probably best for the WG to see/process these secdir >> comments as appropriate. I've not read 'em in detail myself >> yet, so as Leif says, feel free to react as appropriate. >> >> S. >> >> PS: Thanks Leif for reviewing this. >> >> -------- Original Message -------- >> Subject: secdir review of draft-ietf-oauth-v2 >> Date: Mon, 12 Sep 2011 20:31:06 +0200 >> From: Leif Johansson >> To: draft-ietf-oauth-v2@tools.ietf.org, secdir@ietf.org, iesg@ietf.org >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 >> >> Do not be alarmed. =A0I have reviewed this document as part of the >> security directorate's ongoing effort to review all IETF documents being >> processed by the IESG. =A0These comments were written primarily >> for the benefit of the security area directors. =A0Document editors >> and WG chairs should treat these comments just like any other last >> call comments. >> >> This review is rather lengthy. This should not be interpreted as >> anything beyond a desire to do a thorough review. >> >> It may well be that I have stumbled on things already covered on the >> list. If so I apologize and ask that you silently ignore such bits. >> Also I have included things that are not directly security related >> but that I found problematic for other reasons. >> >> The notes are presented in the order I wrote them down. >> >> ** General observations: >> >> POST and/or GET >> >> Examples are sometimes POST and sometimes GET. In many cases it is not >> clear to me from the surrounding text if both POST and GET are allowed >> or if only one is mandated. Illustrating with both a GET _and_ POST >> example in the cases where both are supported would help or make the >> method explicit in the text before the example. >> >> The P-word >> >> The term 'password' is sprinkled throughout the document, sometimes >> as in "client password" or "resource owner password credentials" and >> I suspect that sometimes it is password as in 'an example of a >> credential type' and in other cases it is password as in 'plain old >> password'. This needs to be cleared up throughout (I've included some >> examples below). >> >> Normative Language >> >> I've often found myself wanting more normative language often to replace >> existing but less precise text. I've called out some important cases >> below. >> >> Unknown parameters >> >> The sentence "The client SHOULD ignore unrecognized response parameters" >> occurs in several places. First of all I would argue that this has to >> be a MUST if you want to be able to guarantee extensibility. Secondly >> there are some error responses that are triggered by unsupported request >> parameters. This seems like an inconsistency. >> >> ** Specifics >> >> 1.1 Roles >> >> Forward references to the sections where the roles are defined would >> improve readability. >> >> As an illustration of an alternative model for the authorization server >> maybe an informative reference to UMA would be illustrative here. >> >> 1.2 Protocol Flow >> >> (A) talks about 'an intermediary such as an authorization server.' it >> isn't clear it me if this refers to a separate authorization server >> or if it is the same authorization server that is referenced in (B). >> >> 1.3.3 Resource Owner Password Credentials >> >> When I first read this I thought - why not talk about Resource Owner >> Credentials - in fact there is a parenthesis there "(e.g a username >> and password)" that seems to indicate that other credentials could >> be supported. >> >> This needs to be cleared up. Either its username and password and >> nothing else or there is a way to support things like Negotiate or >> X.509-based credentials in which case it should really be Resource >> Owner Credentials with no reference to passwords other than as as >> an example of one possible credential type. >> >> 1.4 Access Token >> >> first paragraph: "The string is usually opaque". This should be >> reformulated as normative language. In fact I would have liked >> guidance on generating those tokens (which has been brought up >> on the list) possibly as part of an implementation-guide. >> >> 1.5 Refresh Token >> >> Why is the refresh token not simply treated as an access token >> for the access token resource in the authorization server? This >> would seem to simplify the model a bit by removing a type of >> token whose semantic (at least to this reviewer) is a duplication >> of a normal access token for a particular type of resource. >> >> Also in the first paragraph: "(access tokens may have a shorter >> lifetime and fewer permissions". Why not try to write normative >> language here - there are security implications of allowing >> a refresh token to get more permissions (say) than the original >> access token. >> >> 2.1 Client types >> >> I find the terminology public/confidential somewhat counter-intuitive. >> An app you have on your personal device is 'public' while a shared >> cloud service is 'confidential'...hmm... >> >> This section also lacks normative language which isn't good. There >> should be language defining the behavior of public and confidential >> client aswell as the three profiles. >> >> For instance under native application we have "It is assumed that >> any client authentication credentials included in the application >> can be extracted". This should really be normative language. Some >> of what I am looking for can be found in section 2.3 but it isn't >> clear to me that it covers the definition of the profiles. >> >> 2.3.1 Client Password >> >> There is also some confusion here about what the client must implement >> and what the server must implement wrt the use of client_id. I read the >> text as trying to say that Servers SHOULD support both and clients SHOUL= D >> only do Basic. >> >> This section also seems to have been the product of a partial >> s/password/credential/g operation. Either OAUTH is only meant to use >> Basic and passwords or we want to cover all/most HTTP authentication >> methods and credentials and then section 2.3.2 (which feels like an >> afterthought) needs to get folded into 2.3.1 and the normative language >> (and examples!) need some work to cover at least X.509s and perhaps >> even Negotiate. >> >> Personally I would try to fold 2.3.1 and 2.3.2 into one section and say >> that servers MUST support Basic and client_id+client_password. Servers >> MAY support any HTTP authentication method with a mapping to client_id. >> If a client supports username+passwords it SHOULD do Basic and if it >> supports other HTTP authentication methods it MUST NOT use >> client_password for anything and MUST follow normal HTTP authentication >> method negotiation. >> >> Finally, everywhere there is negotiation there must imho be some >> mention/discussion/protection of downgrade attacks. >> >> 3.1 Authorization Endpoints >> >> 6th paragraph: "The authorization server SHOULD ignore unrecognized >> request parameters". This formulation returns in several places in the >> document and I don't understand why it isn't a MUST - after all doesn't >> extensibility depend on this? >> >> 3.1.1 Response Type >> >> The response_type parameter is REQURED but its absence SHOULD result in >> an error. Why not MUST? >> >> 3.1.2 Redirection Endpoint >> >> There should be a clear normative specification for how to =A0match >> endpoints. There are traces of this in various parts of the document >> when matching is discussed. I recommend making a concise definition >> in one place (namely here) and referencing this throughout. Since >> this comparison has security implications it should be a priority >> for the specification to be air-tight. >> >> 3.1.2.2 Registration Requirements >> >> "(the client MAY use the state request parameter to achieve per-request >> customization)". Doesn't this overload its use for CSRF-protection? >> >> 3.1.2.4 Invalid Endpoint >> >> "The authorization server SHOULD NOT redirect...". Why isn't this a >> MUST NOT? >> >> 3.1.2.5 Endpoint Content >> >> This section basically seems to say "Serve with server-side code not >> with html or client-side code". If this is the case then I suggest >> reformulate to say precisely that using normative language. >> >> The use of the word "script" could perhaps also be made less ambiguous >> since in this case it could refer to both server-side code aswell as >> in-browser code. >> >> 3.2.1 Client Authentication >> >> The phrase "clients issued client credentials" could be rephrased to >> make less violence on English - perhaps "clients that have been issued >> with client credentials", unless that is not the intended meaning in >> which case I argue for something easier to understand ;-) >> >> The second bullet: Using client credentials more often also exposes them >> more which might be worth mentioning aswell. >> >> 4. Obtaining Authorization >> >> Perhaps not critical but the term 'password credentials' occurs in the >> first paragraph and this doesn't seem compatible with resource owner >> authentication being out of scope. It could just be that it should read >> 'resource owner credentials' but it could also signal an underlying >> assumption about username and password being used for resource owner >> authentication. In either case I thing its best to avoid the use of the >> word 'password' to avoid any confusion. >> >> 4.1 Authorization Code >> >> (C) - "using the redirection URI provided earlier" should perhaps read >> "using the redirection URI provided earlier or associated with the >> client in client registration" >> >> >> 4.1.1 and 4.1.2 Authorization Request/Authorization Response >> >> The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but >> there is no mention in 4.1.2 how to handle the case when the >> redirect_uri is not present. I believe the assumption is that the >> redirect_uri is either resent or part of client registration but that >> needs to be made explicit in that case. >> >> This may apply to other uses of the redirect_uri parameter eg in 4.2.1. >> >> Furthermore in 4.2.2 "code" I suggest the following re-formulatation of >> the last sentence: "The client MUST NOT use an authorization code for >> more than one request. If an authorization code is re-used, the >> authorization server should treat that as a replay attack and SHOULD >> revoke all tokens associated with the client." (i.e loose the "attempt" >> bit which carries no real meaning) >> >> Also note that this is potentially a DOS attack should a single authz >> code leak. >> >> 4.1.2.1 Error Response >> >> First paragraph, last sentence "and MUST NOT automatically redirect". In >> the light of how willing users normally are to click on links presented >> to them I would strengthen this to "MUST prevent the user from following >> the redirect URI" >> >> In the definition of the invalid_request parameter I don't understand >> how unsupported parameters can generate an error since endpoints should >> ignore unsupported parameters (in order to support extensibility). >> >> 4.1.3 Access Token Request >> >> "require client authentication for confidential clients or for any >> client issued client credentials (or with other authentication >> requirements)" >> >> This text seems unnecessarily convoluted. Isn't enough to say that if >> you have issued credentials to a client you MUST require authentication >> from that client? This applies equally to the other sections where >> client authentication is an issue (eg 4.3.2). >> >> Also cf my comment on 3.1.2 for the discussion of matching redirect_uri >> in the last bullet: ".. and that their values are identical". Is this >> really meant to mean identical? >> >> 4.2 Implicit Grant >> >> The parenthesis "(it does not support the issuance of refresh tokens)" >> sounds like it should really be normative language, "refresh tokens >> MUST NOT be issues for implicit grant" because afaiu you could easily >> extend "fragment-transport" to include a refresh-token, so it isn't >> a technically motivated constraint, right? >> >> In (D) I would like to have a normative reference to a document that >> specifies browser behavior for URL fragments since this is a critical >> security dependency for this grant type. >> >> 4.4 Client Credentials >> >> I think the text should note that this model effectively implies >> that the client is able to impersonate all users which has the potential >> for worse security problems than if the client has access to individual >> user passwords. >> >> 6 Refreshing an Access Token >> >> scope - The term "lesser than" is intuitive but imprecise. I suggest >> "MUST NOT include any scope not originally granted by the resource owner= ". >> >> 7.1 and 8.1 Access Token Types >> >> The section 7.1 lists two definitions of access token types and provides >> a couple of examples but doesn't provide any constraints on future >> development of access tokens except in 8.1 where it is implied that not >> all access token types would be associated with HTTP authentication >> mechanisms. Are there really no constraints on access token types >> that should be captured? >> >> 10.6 Authorization Code Redirection URI Manipulation >> >> Suggest replace the word 'familiar' with 'trusted' in the first sentence >> of the second paragraph. The notion of trust opens up several boat loads >> of worm but it is the correct term here I think. >> >> In the third paragraph "the same as" wrt redirection URIs occur and >> this needs to be defined (cf comments on 3.1.2 above). >> >> Finally "The authorization server MUST require public clients and SHOULD >> require confidential clients to register their redirection URI". I am >> missing a discussion of why the two types of client differ wrt this >> attack vector. >> >> 10.10 Credentials Guessing Attack >> >> I found myself wanting implementation advice for how to generate good >> tokens at this point. This has been raised on the list too. The same >> goes for how to generate good CSRF cookies where the "(eg a hash of the >> session cookie..." feels like it is implementation advice yearning to >> come out of the closet. >> >> >> Thats it. >> >> =A0 =A0 =A0 =A0Cheers Leif >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk5uT+YACgkQ8Jx8FtbMZncXQgCfZmTlzuESq0plfpkceQN1ontE >> a1QAoIEcg06GYK+6Fn4y40cTL1jQ+KmS >> =3Dox42 >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 greg@apigee.com Thu Sep 15 13:06: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 B296921F85BB for ; Thu, 15 Sep 2011 13:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 fkw8sXWc6J4P for ; Thu, 15 Sep 2011 13:06:32 -0700 (PDT) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5AB21F84FC for ; Thu, 15 Sep 2011 13:06:31 -0700 (PDT) Received: by wyh15 with SMTP id 15so4993483wyh.27 for ; Thu, 15 Sep 2011 13:08:43 -0700 (PDT) Received: by 10.227.208.137 with SMTP id gc9mr158165wbb.91.1316117323331; Thu, 15 Sep 2011 13:08:43 -0700 (PDT) From: Greg Brail References: <4E6E4FEA.7090100@sunet.se> <4E6E735D.3050806@cs.tcd.ie> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxzPfBhFPgsYj1LTxagEIsENWK6wwApPK1g Date: Thu, 15 Sep 2011 13:08:47 -0700 Message-ID: <095f76831bcc353b2e44abc354a1b300@mail.gmail.com> To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 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, 15 Sep 2011 20:06:33 -0000 I understand and thanks for clarifying. I agree that there may be services that do not want to support HTTP Basic at all for their authorization flows and that requiring it would weaken the security of OAuth 2.0 and prevent its usage by some applications. Still, the spec, to me, implies that authorization servers MUST support Basic because it says that the client MAY use it. So instead of my proposal, I think it's important to clarify the spec as Andre suggests, and change 2.3.1 as he proposes below. Gregory Brail | Technology | Apigee | +1-650-937-9302 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Andr=E9 DeMarre Sent: Wednesday, September 14, 2011 5:25 PM To: OAuth WG Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 I agree that stating "Clients in possession of a client password MAY use the HTTP Basic authentication scheme" [Section 2.3.1 paragraph 1] implies that authorization servers MUST support HTTP basic authentication, but such is never asserted. Instead, it says "The authorization server MAY accept any form of client authentication meeting its security requirements." [Section 2.3 paragraph 1] This is somewhat contradictory. I can understand that requiring a specific method of client authentication is desirable for maximum interoperability, but this would be problematic for authorization server implementations that wish to enforce stronger security than HTTP Basic. Such implementations would be forced to deviate from the specification. In particular, implementations which choose MAC access tokens instead of Bearer tokens may wish to add a layer of security to defend against improperly configured TLS connections, or to protect clients who connect to the wrong server. [http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/] Such implementations will also find HTTP Basic undesirable for client authentication. To require a form of client authentication that isn't universally sufficient could become a source of criticism and deter adoption of OAuth 2.0. I think the best solution is to clarify section 2.3.1 as follows: --- Clients in possession of client credentials MAY use any form of authentication scheme supported by the authorization server. --- And then follow with the existing example that demonstrates HTTP Basic. Regards, Andre DeMarre On Tue, Sep 13, 2011 at 4:52 PM, Greg Brail wrote: > I would like to add my support to the comments below on section 2.3, > specifically 2.3.1. > > It is clear to me from reading section 2.3 that clients MAY use HTTP > basic, or they MAY include client_id and client_secret in the request > body -- however, the latter is not recommended. > > It is not clear what the authorization server MUST support. IMHO, that > leads us to a situation in which there is no universally-agreed set of > authentication technology that all programmers can assume is going to > work, which means that interoperability will be difficult as some > authorization servers will support Basic, others will support the > request body, and others will do neither in favor of something else. > > I would prefer that we make both HTTP basic AND the request body > mechanisms in this section both required on the server side, thus > giving the client the option of choosing one or the other. That would > mean re-writing the beginning of section 2.3.1 as shown below. > > If I have missed other discussion on this topic I apologize. If there > is already consensus to make the "message body" authentication > optional rather than required for the authorization SERVER then I > would still recommend that we make HTTP Basic a MUST in order to allow > easier interop. > > Proposed change to 2.3.1: > > ---- > > The authorization server MUST support the HTTP Basic authentication > scheme as defined in [RFC2617] as a way to identify clients. The > client identifier is used as the username, and the client password is > used as the password. > > For example (extra line breaks are for display purposes only): > > =A0 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > Alternatively, the authorization server MUST also allow the client to > include the=A0client credentials in the request body using the following > parameters: > > =A0 client_id > =A0 =A0 =A0 =A0 REQUIRED. =A0The client identifier issued to the client d= uring > =A0 =A0 =A0 =A0 the registration process described by Section 2.2. > =A0 client_secret > =A0 =A0 =A0 =A0 REQUIRED. =A0The client secret. =A0The client MAY omit th= e > =A0 =A0 =A0 =A0 parameter if the client secret is an empty string. > > Clients in possession of a client password MAY use either mechanism in > order to authenticate with the authorization server. However, > including the client credentials in the request body using the two > parameters is NOT RECOMMENDED, and should be limited to clients unable > to directly utilize the HTTP Basic authentication scheme (or other > password-based HTTP authentication schemes). > > =A0(Rest of section remains as-is with the paragraph beginning "For example...") > > Gregory Brail=A0=A0 |=A0=A0 Technology=A0=A0 |=A0=A0 Apigee=A0=A0 | =A0= =A0+1-650-937-9302 > > On Mon, Sep 12, 2011 at 2:02 PM, Stephen Farrell > wrote: >> >> FYI, probably best for the WG to see/process these secdir >> comments as appropriate. I've not read 'em in detail myself >> yet, so as Leif says, feel free to react as appropriate. >> >> S. >> >> PS: Thanks Leif for reviewing this. >> >> -------- Original Message -------- >> Subject: secdir review of draft-ietf-oauth-v2 >> Date: Mon, 12 Sep 2011 20:31:06 +0200 >> From: Leif Johansson >> To: draft-ietf-oauth-v2@tools.ietf.org, secdir@ietf.org, iesg@ietf.org >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 >> >> Do not be alarmed. =A0I have reviewed this document as part of the >> security directorate's ongoing effort to review all IETF documents being >> processed by the IESG. =A0These comments were written primarily >> for the benefit of the security area directors. =A0Document editors >> and WG chairs should treat these comments just like any other last >> call comments. >> >> This review is rather lengthy. This should not be interpreted as >> anything beyond a desire to do a thorough review. >> >> It may well be that I have stumbled on things already covered on the >> list. If so I apologize and ask that you silently ignore such bits. >> Also I have included things that are not directly security related >> but that I found problematic for other reasons. >> >> The notes are presented in the order I wrote them down. >> >> ** General observations: >> >> POST and/or GET >> >> Examples are sometimes POST and sometimes GET. In many cases it is not >> clear to me from the surrounding text if both POST and GET are allowed >> or if only one is mandated. Illustrating with both a GET _and_ POST >> example in the cases where both are supported would help or make the >> method explicit in the text before the example. >> >> The P-word >> >> The term 'password' is sprinkled throughout the document, sometimes >> as in "client password" or "resource owner password credentials" and >> I suspect that sometimes it is password as in 'an example of a >> credential type' and in other cases it is password as in 'plain old >> password'. This needs to be cleared up throughout (I've included some >> examples below). >> >> Normative Language >> >> I've often found myself wanting more normative language often to replace >> existing but less precise text. I've called out some important cases >> below. >> >> Unknown parameters >> >> The sentence "The client SHOULD ignore unrecognized response parameters" >> occurs in several places. First of all I would argue that this has to >> be a MUST if you want to be able to guarantee extensibility. Secondly >> there are some error responses that are triggered by unsupported request >> parameters. This seems like an inconsistency. >> >> ** Specifics >> >> 1.1 Roles >> >> Forward references to the sections where the roles are defined would >> improve readability. >> >> As an illustration of an alternative model for the authorization server >> maybe an informative reference to UMA would be illustrative here. >> >> 1.2 Protocol Flow >> >> (A) talks about 'an intermediary such as an authorization server.' it >> isn't clear it me if this refers to a separate authorization server >> or if it is the same authorization server that is referenced in (B). >> >> 1.3.3 Resource Owner Password Credentials >> >> When I first read this I thought - why not talk about Resource Owner >> Credentials - in fact there is a parenthesis there "(e.g a username >> and password)" that seems to indicate that other credentials could >> be supported. >> >> This needs to be cleared up. Either its username and password and >> nothing else or there is a way to support things like Negotiate or >> X.509-based credentials in which case it should really be Resource >> Owner Credentials with no reference to passwords other than as as >> an example of one possible credential type. >> >> 1.4 Access Token >> >> first paragraph: "The string is usually opaque". This should be >> reformulated as normative language. In fact I would have liked >> guidance on generating those tokens (which has been brought up >> on the list) possibly as part of an implementation-guide. >> >> 1.5 Refresh Token >> >> Why is the refresh token not simply treated as an access token >> for the access token resource in the authorization server? This >> would seem to simplify the model a bit by removing a type of >> token whose semantic (at least to this reviewer) is a duplication >> of a normal access token for a particular type of resource. >> >> Also in the first paragraph: "(access tokens may have a shorter >> lifetime and fewer permissions". Why not try to write normative >> language here - there are security implications of allowing >> a refresh token to get more permissions (say) than the original >> access token. >> >> 2.1 Client types >> >> I find the terminology public/confidential somewhat counter-intuitive. >> An app you have on your personal device is 'public' while a shared >> cloud service is 'confidential'...hmm... >> >> This section also lacks normative language which isn't good. There >> should be language defining the behavior of public and confidential >> client aswell as the three profiles. >> >> For instance under native application we have "It is assumed that >> any client authentication credentials included in the application >> can be extracted". This should really be normative language. Some >> of what I am looking for can be found in section 2.3 but it isn't >> clear to me that it covers the definition of the profiles. >> >> 2.3.1 Client Password >> >> There is also some confusion here about what the client must implement >> and what the server must implement wrt the use of client_id. I read the >> text as trying to say that Servers SHOULD support both and clients SHOULD >> only do Basic. >> >> This section also seems to have been the product of a partial >> s/password/credential/g operation. Either OAUTH is only meant to use >> Basic and passwords or we want to cover all/most HTTP authentication >> methods and credentials and then section 2.3.2 (which feels like an >> afterthought) needs to get folded into 2.3.1 and the normative language >> (and examples!) need some work to cover at least X.509s and perhaps >> even Negotiate. >> >> Personally I would try to fold 2.3.1 and 2.3.2 into one section and say >> that servers MUST support Basic and client_id+client_password. Servers >> MAY support any HTTP authentication method with a mapping to client_id. >> If a client supports username+passwords it SHOULD do Basic and if it >> supports other HTTP authentication methods it MUST NOT use >> client_password for anything and MUST follow normal HTTP authentication >> method negotiation. >> >> Finally, everywhere there is negotiation there must imho be some >> mention/discussion/protection of downgrade attacks. >> >> 3.1 Authorization Endpoints >> >> 6th paragraph: "The authorization server SHOULD ignore unrecognized >> request parameters". This formulation returns in several places in the >> document and I don't understand why it isn't a MUST - after all doesn't >> extensibility depend on this? >> >> 3.1.1 Response Type >> >> The response_type parameter is REQURED but its absence SHOULD result in >> an error. Why not MUST? >> >> 3.1.2 Redirection Endpoint >> >> There should be a clear normative specification for how to =A0match >> endpoints. There are traces of this in various parts of the document >> when matching is discussed. I recommend making a concise definition >> in one place (namely here) and referencing this throughout. Since >> this comparison has security implications it should be a priority >> for the specification to be air-tight. >> >> 3.1.2.2 Registration Requirements >> >> "(the client MAY use the state request parameter to achieve per-request >> customization)". Doesn't this overload its use for CSRF-protection? >> >> 3.1.2.4 Invalid Endpoint >> >> "The authorization server SHOULD NOT redirect...". Why isn't this a >> MUST NOT? >> >> 3.1.2.5 Endpoint Content >> >> This section basically seems to say "Serve with server-side code not >> with html or client-side code". If this is the case then I suggest >> reformulate to say precisely that using normative language. >> >> The use of the word "script" could perhaps also be made less ambiguous >> since in this case it could refer to both server-side code aswell as >> in-browser code. >> >> 3.2.1 Client Authentication >> >> The phrase "clients issued client credentials" could be rephrased to >> make less violence on English - perhaps "clients that have been issued >> with client credentials", unless that is not the intended meaning in >> which case I argue for something easier to understand ;-) >> >> The second bullet: Using client credentials more often also exposes them >> more which might be worth mentioning aswell. >> >> 4. Obtaining Authorization >> >> Perhaps not critical but the term 'password credentials' occurs in the >> first paragraph and this doesn't seem compatible with resource owner >> authentication being out of scope. It could just be that it should read >> 'resource owner credentials' but it could also signal an underlying >> assumption about username and password being used for resource owner >> authentication. In either case I thing its best to avoid the use of the >> word 'password' to avoid any confusion. >> >> 4.1 Authorization Code >> >> (C) - "using the redirection URI provided earlier" should perhaps read >> "using the redirection URI provided earlier or associated with the >> client in client registration" >> >> >> 4.1.1 and 4.1.2 Authorization Request/Authorization Response >> >> The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but >> there is no mention in 4.1.2 how to handle the case when the >> redirect_uri is not present. I believe the assumption is that the >> redirect_uri is either resent or part of client registration but that >> needs to be made explicit in that case. >> >> This may apply to other uses of the redirect_uri parameter eg in 4.2.1. >> >> Furthermore in 4.2.2 "code" I suggest the following re-formulatation of >> the last sentence: "The client MUST NOT use an authorization code for >> more than one request. If an authorization code is re-used, the >> authorization server should treat that as a replay attack and SHOULD >> revoke all tokens associated with the client." (i.e loose the "attempt" >> bit which carries no real meaning) >> >> Also note that this is potentially a DOS attack should a single authz >> code leak. >> >> 4.1.2.1 Error Response >> >> First paragraph, last sentence "and MUST NOT automatically redirect". In >> the light of how willing users normally are to click on links presented >> to them I would strengthen this to "MUST prevent the user from following >> the redirect URI" >> >> In the definition of the invalid_request parameter I don't understand >> how unsupported parameters can generate an error since endpoints should >> ignore unsupported parameters (in order to support extensibility). >> >> 4.1.3 Access Token Request >> >> "require client authentication for confidential clients or for any >> client issued client credentials (or with other authentication >> requirements)" >> >> This text seems unnecessarily convoluted. Isn't enough to say that if >> you have issued credentials to a client you MUST require authentication >> from that client? This applies equally to the other sections where >> client authentication is an issue (eg 4.3.2). >> >> Also cf my comment on 3.1.2 for the discussion of matching redirect_uri >> in the last bullet: ".. and that their values are identical". Is this >> really meant to mean identical? >> >> 4.2 Implicit Grant >> >> The parenthesis "(it does not support the issuance of refresh tokens)" >> sounds like it should really be normative language, "refresh tokens >> MUST NOT be issues for implicit grant" because afaiu you could easily >> extend "fragment-transport" to include a refresh-token, so it isn't >> a technically motivated constraint, right? >> >> In (D) I would like to have a normative reference to a document that >> specifies browser behavior for URL fragments since this is a critical >> security dependency for this grant type. >> >> 4.4 Client Credentials >> >> I think the text should note that this model effectively implies >> that the client is able to impersonate all users which has the potential >> for worse security problems than if the client has access to individual >> user passwords. >> >> 6 Refreshing an Access Token >> >> scope - The term "lesser than" is intuitive but imprecise. I suggest >> "MUST NOT include any scope not originally granted by the resource owner". >> >> 7.1 and 8.1 Access Token Types >> >> The section 7.1 lists two definitions of access token types and provides >> a couple of examples but doesn't provide any constraints on future >> development of access tokens except in 8.1 where it is implied that not >> all access token types would be associated with HTTP authentication >> mechanisms. Are there really no constraints on access token types >> that should be captured? >> >> 10.6 Authorization Code Redirection URI Manipulation >> >> Suggest replace the word 'familiar' with 'trusted' in the first sentence >> of the second paragraph. The notion of trust opens up several boat loads >> of worm but it is the correct term here I think. >> >> In the third paragraph "the same as" wrt redirection URIs occur and >> this needs to be defined (cf comments on 3.1.2 above). >> >> Finally "The authorization server MUST require public clients and SHOULD >> require confidential clients to register their redirection URI". I am >> missing a discussion of why the two types of client differ wrt this >> attack vector. >> >> 10.10 Credentials Guessing Attack >> >> I found myself wanting implementation advice for how to generate good >> tokens at this point. This has been raised on the list too. The same >> goes for how to generate good CSRF cookies where the "(eg a hash of the >> session cookie..." feels like it is implementation advice yearning to >> come out of the closet. >> >> >> Thats it. >> >> =A0 =A0 =A0 =A0Cheers Leif >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk5uT+YACgkQ8Jx8FtbMZncXQgCfZmTlzuESq0plfpkceQN1ontE >> a1QAoIEcg06GYK+6Fn4y40cTL1jQ+KmS >> =3Dox42 >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> 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 leifj@mnt.se Thu Sep 15 14:37: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 95A5421F8B7A for ; Thu, 15 Sep 2011 14:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.842 X-Spam-Level: X-Spam-Status: No, score=-2.842 tagged_above=-999 required=5 tests=[AWL=-0.243, 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 D38urx8EudY8 for ; Thu, 15 Sep 2011 14:37:26 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 6175A21F8B6D for ; Thu, 15 Sep 2011 14:37:26 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p8FLdTaE014927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Sep 2011 23:39:37 +0200 (CEST) Message-ID: <4E727091.6090005@mnt.se> Date: Thu, 15 Sep 2011 23:39:29 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: oauth@ietf.org References: <4E6E4FEA.7090100@sunet.se> <4E6E735D.3050806@cs.tcd.ie> <095f76831bcc353b2e44abc354a1b300@mail.gmail.com> In-Reply-To: <095f76831bcc353b2e44abc354a1b300@mail.gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 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, 15 Sep 2011 21:37:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/15/2011 10:08 PM, Greg Brail wrote: > I understand and thanks for clarifying. I agree that there may be services > that do not want to support HTTP Basic at all for their authorization > flows and that requiring it would weaken the security of OAuth 2.0 and > prevent its usage by some applications. Thats why I said that whenever you have negotiation you must think about downgrade attacks. There are ways to mitigate those - for instance by re-examining the available methods/mechanisms once a secure channel has been established. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5ycJEACgkQ8Jx8FtbMZneO6QCfRWB6q7W7P5fZFOsNJKd6NT91 9E4AoJI3h6sB2O0ZZAQqt4OT4B4HG5T3 =+/QY -----END PGP SIGNATURE----- From torsten@lodderstedt.net Fri Sep 16 11:59: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 C5E4621F8B6F for ; Fri, 16 Sep 2011 11:59:00 -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, 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 ZOALJCduuad4 for ; Fri, 16 Sep 2011 11:58:58 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id 0705321F8B5B for ; Fri, 16 Sep 2011 11:58:57 -0700 (PDT) Received: from [87.142.251.121] (helo=[192.168.71.26]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1R4dex-00021w-3x; Fri, 16 Sep 2011 21:01:11 +0200 Message-ID: <4E739D06.2020309@lodderstedt.net> Date: Fri, 16 Sep 2011 21:01:26 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Dave Rochwerger References: <1315434454.76681.YahooMailNeo@web31816.mail.mud.yahoo.com><0F38FE37-5F91-48ED-AD9E-1F08B7AA8DA6@oracle.com> <59CDCC16-44BA-4626-B744-F1169A13A542@oracle.com> <55876c26dbad646336c557dc22d67c40@lodderstedt-online.de> <4E7105DD.7030507@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080907050807020602040607" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret andrefresh 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, 16 Sep 2011 18:59:00 -0000 This is a multi-part message in MIME format. --------------080907050807020602040607 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Dave, there has been a long debate about native client security and you can also find a comprehensive analysis in the security document. It's just a fact that such clients cannot reliably be authenticated in a public environment (even if malicious clients can be detected in some cases). So it is the responsibility of the resource owner to validate the authenticity/trustworthiness of an app before using it. The authz server's task is to authz access to cloud resources, so it asks the resource owner for consent. Once the consent is given, the refresh token itself represents the fact that the holder should be a legitimate client. regards, Torsten. ------------------------------------------------------------------------ *From: * Dave Rochwerger *Date: *Wed, 14 Sep 2011 13:45:42 -0700 *To: *Torsten Lodderstedt *Cc: * *Subject: *Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Is this a security issue in the OAuth2 process then (for mobile apps using the authorization code flow)? 1. The draft says that mobile apps should be considered public clients because mobile apps can be decompiled and can not keep their credentials private. 2. In this case then, the draft says for these mobile apps to not authenticate with the secret and instead for the server to verify the redirect URI (and make it mandatory). 3. You said that verifying the redirect URI is not good enough to verify the client's identity. What am I missing? Thanks, Dave On Wed, Sep 14, 2011 at 12:51 PM, Torsten Lodderstedt > wrote: Hi Dave, redirect URI validation does not authenticate a client. For example, a URI registered for a private web client could be used by a (malicious) native app to assume the web app's identity. The client secret, in contrast, can be used to authenticate it. regards, Torsten. Am 14.09.2011 19:12, schrieb Dave Rochwerger: Thanks for the follow up, Torsten. Whilst I have your attention - any thoughts on my second question, about the use of a client secret? If for all clients we mandated registered URIs and verified them (whether they are private and public), what additional security does the client secret actually provide for private clients in the authorization code flow? Thanks, Dave On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt > wrote: Hi Dave, On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote: 1. "The user does not have to be present." Maybe I should be more clear. What benefit does that have over just a long-lived (forever) access token? The cost is the extra complication for 3rd party developers to have to worry about refresh tokens. I can not see a benefit in our model (everything over SSL, etc) to use refresh tokens. I want to use refresh tokens - but only if there is a reason for them, which I can not see at the moment. The benefit of refresh tokens significantly depends on your access token design. If your access tokens are just a pointer to a database you lookup on any API call, the only benefit if token rotation (coming back to this topic below). But your access tokens could also directly contain all user data you need to actually authorize API access. That way you could save DB lookups, which scales much better. In this model, revocation is much can be easier implement using refresh tokens. I think this is what Eran refered to. 2. "As Eran points out, you'd have to have do a DB lookup to have true revocation." The act of revoking tokens is not a common occurrence, DB lookups to revoke tokens is not a concern as there is more time spent by the user navigating the UI (or network latency, etc) than the cost of the DB call. 3. "In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user." That all sounds good, but in our situation (all SSL, etc) - what do we want key rotation and re-verification for? I fail to see a reasonable vector for access token leakage to warrant any of this in our case. rotation is a mean to detect tokem theft from the device (see also http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2). regards, Torsten. On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: See below... Phil @independentid www.independentid.com [11] phil.hunt@oracle.com [12] On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: Hi Phil,>> The client is then forced to periodically reauthenticate (without the user) before getting a new access token. What benefit does that have? The user does not have to be present. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. That doesn't follow - we can just as easily revoke the single long-lived access token. As Eran points out, you'd have to have do a DB lookup to have true revocation. But, by having a short expiration time on the access token (say 1 hour or less), you get quasi-revocation which has to be re-validated after the access token expires and the client has to re-authenticate and provide a valid refresh token. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. Dave.> On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill ------------------------- FROM: Dave Rochwerger TO: oauth@ietf.org [2] CC: Quizlet Dev Team SENT: Wednesday, September 7, 2011 2:15 PM SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: ========== * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want to provide very long-lived (forever) tokens. * We are implementing the "authorization code" flow as that seems best suited to us (we don't want the implicit flow because end-users would have to re-authorize every hour). Our architecture: ============ * We control both the API server and the authorization server. * All requests to protected resources (ie: to the API server) are always done over SSL. * All requests to the authz server (token and authorize endpoints) are always done over SSL. * We enforce that every client must supply the state parameter (and our guidelines say they must verify the state for CSRF mitigation). * We enforce that every client must register a redirect URI. * We validate the redirect_uri used to request an access token is the same that was used to obtain the auth code. * The only time a request is not made over SSL is the redirect with the auth_code which is very short-lived (30 seconds) and is tied to a verified redirect URI. * We enforce that access tokens must be provided using the Authorization header only (and of course, over SSL). * We have guidelines saying that all mobile apps must use the native browser (and not an embedded web UI). Questions: ======== 1. Given the above scenario, what use are refresh tokens? - Access tokens can not leak because every request (to resource and authz server) containing an access token is done over SSL. We control both the authz and resource servers, so tokens in logs (and other suggested reasons in the archives) are not an issue. - Long-lived refresh tokens and short-lived access tokens are supposed to provide security due to possible access token leakage... but in our 100% SSL scenario, if access tokens are able to leak, then so would the client id, secret and refresh token. - Having a long-lived refresh token that can be exchanged for another access token adds a level of complexity (a second HTTPS request every so often) and seems to provide no benefit for our case. 2. What is the point of the client secret (in our scenario)? - We originally were treating the clients as confidential, but after re-reading the native-application section, it seems we really should treat them as public (phone apps can be decompiled and the secret discovered). - The spec says that the authz server should authenticate confidential clients, but public clients are allowed to just send their public client id (and no secret). - The only verification then, is to enforce redirect URI registration and to validate the redirect URI between authorization and token steps. So, the question is, assuming that we, one: "enforce redirect-URI registration" and two: "validate that URI" - why can't we treat all clients as public and not worry about a secret? What is the benefit of having confidential clients (and a secret) at all? Our API source is not available, but the oauth2 server implementation can be seen here: https://github.com/quizlet/oauth2-php [4] Regards, Dave _______________________________________________ OAuth mailing list OAuth@ietf.org [5] https://www.ietf.org/mailman/listinfo/oauth [6] _______________________________________________ OAuth mailing list OAuth@ietf.org [7] https://www.ietf.org/mailman/listinfo/oauth [8] Links: ------ [1] mailto:daver@quizlet.com [2] mailto:oauth@ietf.org [3] mailto:devteam@quizlet.com [4] https://github.com/quizlet/oauth2-php [5] mailto:OAuth@ietf.org [6] https://www.ietf.org/mailman/listinfo/oauth [7] mailto:OAuth@ietf.org [8] https://www.ietf.org/mailman/listinfo/oauth [9] mailto:wmills@yahoo-inc.com [10] mailto:phil.hunt@oracle.com [11] http://www.independentid.com [12] mailto:phil.hunt@oracle.com [13] mailto:phil.hunt@oracle.com _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --------------080907050807020602040607 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Dave,

there has been a long debate about native client security and you can also find a comprehensive analysis in the security document.

It's just a fact that such clients cannot reliably be authenticated in a public environment (even if malicious clients can be detected in some cases). So it is the responsibility of the resource owner to validate the authenticity/trustworthiness of an app before using it. The authz server's task is to authz access to cloud resources, so it asks the resource owner for consent. Once the consent is given, the refresh token itself represents the fact that the holder should be a legitimate client.

regards,
Torsten.
From: Dave Rochwerger <daver@quizlet.com>
Date: Wed, 14 Sep 2011 13:45:42 -0700
To: Torsten Lodderstedt<torsten@lodderstedt.net>
Subject: Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)

Is this a security issue in the OAuth2 process then (for mobile apps using the authorization code flow)?

1. The draft says that mobile apps should be considered public clients because mobile apps can be decompiled and can not keep their credentials private.
2. In this case then, the draft says for these mobile apps to not authenticate with the secret and instead for the server to verify the redirect URI (and make it mandatory).
3. You said that verifying the redirect URI is not good enough to verify the client's identity.

What am I missing?

Thanks,
Dave


On Wed, Sep 14, 2011 at 12:51 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Dave,

redirect URI validation does not authenticate a client. For example, a URI registered for a private web client could be used by a (malicious) native app to assume the web app's identity. The client secret, in contrast, can be used to authenticate it.

regards,
Torsten.

Am 14.09.2011 19:12, schrieb Dave Rochwerger:

Thanks for the follow up, Torsten.

Whilst I have your attention - any thoughts on my second question,
about the use of a client secret?
If for all clients we mandated registered URIs and verified them
(whether they are private and public), what additional security does
the client secret actually provide for private clients in the
authorization code flow?


Thanks,
Dave

On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt
<torsten@lodderstedt.net>  wrote:
Hi Dave,


On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote:

1. "The user does not have to be present."
Maybe I should be more clear. What benefit does that have over just a
long-lived (forever) access token? The cost is the extra complication for
3rd party developers to have to worry about refresh tokens. I can not see
a benefit in our model (everything over SSL, etc) to use refresh tokens.
I want to use refresh tokens - but only if there is a reason for them,
which I can not see at the moment.

The benefit of refresh tokens significantly depends on your access token design. If your access tokens are just a pointer to a database you lookup on any API call, the only benefit if token rotation (coming back to this topic below). But your access tokens could also directly contain all user data you need to actually authorize API access. That way you could save DB lookups, which scales much better. In this model, revocation is much can be easier implement using refresh tokens. I think this is what Eran refered to.


2. "As Eran points out, you'd have to have do a DB lookup to have true
revocation."
The act of revoking tokens is not a common occurrence, DB lookups to
revoke tokens is not a concern as there is more time spent by the user
navigating the UI (or network latency, etc) than the cost of the DB call.

3. "In this sense you get the best of a long-lived credential, combined
with good key rotation and authorization re-verification without having
to re-involve the end-user."
That all sounds good, but in our situation (all SSL, etc) - what do we
want key rotation and re-verification for? I fail to see a reasonable
vector for access token leakage to warrant any of this in our case.

rotation is a mean to detect tokem theft from the device (see also http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2).

regards,
Torsten.

On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote:

See below...

Phil
@independentid
www.independentid.com [11] phil.hunt@oracle.com [12]


On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote:

Hi Phil,>>  The client is then forced to periodically reauthenticate
(without the user) before getting a new access token.
What benefit does that have?
The user does not have to be present.

Refresh also gives the authzn server a chance to revoke access.
Hence it is better to use shorter lived access tokens with long lived
refresh tokens.
That doesn't follow - we can just as easily revoke the single
long-lived access token.
As Eran points out, you'd have to have do a DB lookup to have true
revocation. But, by having a short expiration time on the access token
(say 1 hour or less), you get quasi-revocation which has to be
re-validated after the access token expires and the client has to
re-authenticate and provide a valid refresh token. In this sense you
get the best of a long-lived credential, combined with good key
rotation and authorization re-verification without having to re-involve
the end-user.

Dave.>
On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote:

You can also use a long lived refresh token in combination with a
short access token. The client is then forced to periodically
reauthenticate (without the user) before getting a new access
token.
Refresh also gives the authzn server a chance to revoke access.
Hence it is better to use shorter lived access tokens with long
lived refresh tokens.

Phil

On 2011-09-07, at 15:27, William Mills wrote:

I'll talk to the refresh token question: they give you a hook for
extensibility and key rotation. If you want to rotate your
encryption keys or extend the data carried in the token in any
way then you want to be able to cleanly refresh your tokens. Note
that the refresh flow allows you to issue a new refresh token at
the same time. It also allows a clean path to convert tokens in a
new client if you decide you want SAML tokens instead of MAC for
example.
If you want those things you want to use refresh tokens. You can
have long lived access tokens too, and just use the refresh
tokens when you want to do something new with the access tokens.
-bill

-------------------------
FROM: Dave Rochwerger
TO: oauth@ietf.org [2]
CC: Quizlet Dev Team
SENT: Wednesday, September 7, 2011 2:15 PM
SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client

secret and refresh tokens)

Hi all,
I have been implementing OAuth2 based on the various drafts for
our new API. Initially, I implemented everything as per the spec,
but due to our particular scenario and restrictions we have in
place, there are some fundamental questions that I am unable to
defend.
I am hoping this group could help answer them for me.
Our scenario:
==========
* We are implementing an API to allow 3rd party developers to
access users' protected resources via their applications. The
applications will mostly be native phone apps, but some will have
web server backends (javascript-only applications are not a
concern at the moment).
* We want to provide very long-lived (forever) tokens.
* We are implementing the "authorization code" flow as that seems
best suited to us (we don't want the implicit flow because
end-users would have to re-authorize every hour).
Our architecture:
============
* We control both the API server and the authorization server.
* All requests to protected resources (ie: to the API server) are
always done over SSL.
* All requests to the authz server (token and authorize
endpoints) are always done over SSL.
* We enforce that every client must supply the state parameter
(and our guidelines say they must verify the state for CSRF
mitigation).
* We enforce that every client must register a redirect URI.
* We validate the redirect_uri used to request an access token is
the same that was used to obtain the auth code.
* The only time a request is not made over SSL is the redirect
with the auth_code which is very short-lived (30 seconds) and is
tied to a verified redirect URI.
* We enforce that access tokens must be provided using the
Authorization header only (and of course, over SSL).
* We have guidelines saying that all mobile apps must use the
native browser (and not an embedded web UI).
Questions:
========
1. Given the above scenario, what use are refresh tokens?
- Access tokens can not leak because every request (to resource
and authz server) containing an access token is done over SSL. We
control both the authz and resource servers, so tokens in logs
(and other suggested reasons in the archives) are not an issue.
- Long-lived refresh tokens and short-lived access tokens are
supposed to provide security due to possible access token
leakage... but in our 100% SSL scenario, if access tokens are
able to leak, then so would the client id, secret and refresh
token.
- Having a long-lived refresh token that can be exchanged for
another access token adds a level of complexity (a second HTTPS
request every so often) and seems to provide no benefit for our
case.
2. What is the point of the client secret (in our scenario)? -
We originally were treating the clients as confidential, but
after re-reading the native-application section, it seems we
really should treat them as public (phone apps can be decompiled
and the secret discovered).

- The spec says that the authz server should authenticate
confidential clients, but public clients are allowed to just send
their public client id (and no secret).
- The only verification then, is to enforce redirect URI
registration and to validate the redirect URI between
authorization and token steps.

So, the question is, assuming that we, one: "enforce
redirect-URI registration" and two: "validate that URI" - why
can't we treat all clients as public and not worry about a
secret?
What is the benefit of having confidential clients (and a secret)
at all?
Our API source is not available, but the oauth2 server
implementation can be seen here:
https://github.com/quizlet/oauth2-php [4]

Regards,
Dave

_______________________________________________
OAuth mailing list
OAuth@ietf.org [5]
https://www.ietf.org/mailman/listinfo/oauth [6]

_______________________________________________
OAuth mailing list
OAuth@ietf.org [7]
https://www.ietf.org/mailman/listinfo/oauth [8]



Links:
------
[1] mailto:daver@quizlet.com
[2] mailto:oauth@ietf.org
[3] mailto:devteam@quizlet.com
[4] https://github.com/quizlet/oauth2-php
[5] mailto:OAuth@ietf.org
[6] https://www.ietf.org/mailman/listinfo/oauth
[7] mailto:OAuth@ietf.org
[8] https://www.ietf.org/mailman/listinfo/oauth
[9] mailto:wmills@yahoo-inc.com
[10] mailto:phil.hunt@oracle.com
[11] http://www.independentid.com
[12] mailto:phil.hunt@oracle.com
[13] mailto:phil.hunt@oracle.com

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

--------------080907050807020602040607-- From torsten@lodderstedt.net Fri Sep 16 12:06: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 1077421F8509 for ; Fri, 16 Sep 2011 12:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 77X0QLaRTdNc for ; Fri, 16 Sep 2011 12:06:27 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1C121F8C47 for ; Fri, 16 Sep 2011 12:06:27 -0700 (PDT) Received: from [87.142.251.121] (helo=[192.168.71.26]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1R4dmC-000768-TU; Fri, 16 Sep 2011 21:08:41 +0200 Message-ID: <4E739EC8.4080309@lodderstedt.net> Date: Fri, 16 Sep 2011 21:08:56 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth WG Subject: Re: [OAUTH-WG] Reviewing draft-ietf-oauth-v2-21 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, 16 Sep 2011 19:06:28 -0000 I reviewed the diffs and it looks ok. regards, Torsten. Am 07.09.2011 17:59, schrieb Barry Leiba: > As you've all probably seen, Eran has posted version 21 of the OAuth > base spec, in which he believes he's addressed all comments and issues > that came up in the review of version 20. We should be ready to send > this to the IESG. > > Everyone who had comments or issues, please review -21 and make sure > that your concerns have been handled to your satisfaction (or that > there was no consensus to make a change). And we encourage everyone > to review the changes from -20 to -21, to make sure Eran didn't > inadvertently break anything along the way. > > The -21 is here: http://tools.ietf.org/html/draft-ietf-oauth-v2-21 > And diffs from -20 can be found here: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-21.txt > > We'll give it until the end of next week, while I work on the shepherd > writeup. Comments, please, by 16 September. A few affirmative notes > saying, "Yes, I reviewed it and it looks good," will also be helpful. > Keep in mind, as you review, that pet changes are out of scope at this > point. We're just reviewing -21 to make sure (1) it doesn't break > anything from -20, and (2) it isn't missing anything that was brought > up in WGLC. New issues will have to be very serious, indeed, in order > to be considered now. > > Also, a note on the thread that Mike Thomas started about the OAuth > problem statement and threats: > I did encourage him to start the discussion, and I think it can be a > useful conversation. I do NOT think it will or should result in a > change to the base spec, but it might feed into the threat model > document (draft-ietf-oauth-v2-threatmodel), as Torsten, et al, move > that toward completion. Remember that the base spec encourages > readers to refer to the threat model document for more detailed > descriptions of threats and attacks. > > Barry, as chair > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Fri Sep 16 12:29: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 CE2B221F8D15 for ; Fri, 16 Sep 2011 12:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.060, 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 200h0thsCEaG for ; Fri, 16 Sep 2011 12:29:35 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id 0996521F8D13 for ; Fri, 16 Sep 2011 12:29:34 -0700 (PDT) Received: from [87.142.251.121] (helo=[192.168.71.26]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1R4e8Y-0008Lu-RC; Fri, 16 Sep 2011 21:31:47 +0200 Message-ID: <4E73A431.2020205@lodderstedt.net> Date: Fri, 16 Sep 2011 21:32:01 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: OAuth WG , Stefanie Dronia , Marius Scurtescu References: <20110916192014.6501.87499.idtracker@ietfa.amsl.com> In-Reply-To: <20110916192014.6501.87499.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110916192014.6501.87499.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020407000808000409030000" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.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, 16 Sep 2011 19:29:35 -0000 This is a multi-part message in MIME format. --------------020407000808000409030000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec. We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom. regards, Torsten. -------- Original-Nachricht -------- Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt Datum: Fri, 16 Sep 2011 12:20:14 -0700 Von: internet-drafts@ietf.org An: torsten@lodderstedt.net CC: sdronia@gmx.de, torsten@lodderstedt.net, mscurtescu@google.com A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. Filename: draft-lodderstedt-oauth-revocation Revision: 03 Title: Token Revocation Creation date: 2011-09-16 WG ID: Individual Submission Number of pages: 6 Abstract: This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. The IETF Secretariat --------------020407000808000409030000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all,

I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec.

We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom.

regards,
Torsten.

-------- Original-Nachricht --------
Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt
Datum: Fri, 16 Sep 2011 12:20:14 -0700
Von: internet-drafts@ietf.org
An: torsten@lodderstedt.net
CC: sdronia@gmx.de, torsten@lodderstedt.net, mscurtescu@google.com 


A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository.

Filename:	 draft-lodderstedt-oauth-revocation
Revision:	 03
Title:		 Token Revocation
Creation date:	 2011-09-16
WG ID:		 Individual Submission
Number of pages: 6

Abstract:
   This draft proposes an additional endpoint for OAuth authorization
   servers for revoking tokens.

                                                                                  


The IETF Secretariat
--------------020407000808000409030000-- From phil.hunt@oracle.com Fri Sep 16 12:49: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 35D2121F8CF5 for ; Fri, 16 Sep 2011 12:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.259 X-Spam-Level: X-Spam-Status: No, score=-5.259 tagged_above=-999 required=5 tests=[AWL=1.340, 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 UaMQIuWJGpWw for ; Fri, 16 Sep 2011 12:49:10 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id F2D0921F8CF1 for ; Fri, 16 Sep 2011 12:49:09 -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 p8GJpG17030565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Sep 2011 19:51:18 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8GJpFug023727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2011 19:51:16 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8GJp904032184; Fri, 16 Sep 2011 14:51:10 -0500 Received: from [192.168.1.67] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Sep 2011 12:51:09 -0700 References: <4E739EC8.4080309@lodderstedt.net> In-Reply-To: <4E739EC8.4080309@lodderstedt.net> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8L1) From: Phillip Hunt Date: Fri, 16 Sep 2011 12:51:06 -0700 To: Torsten Lodderstedt X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090205.4E73A8B7.0027,ss=1,re=0.000,fgs=0 Cc: Barry Leiba , oauth WG Subject: Re: [OAUTH-WG] Reviewing draft-ietf-oauth-v2-21 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, 16 Sep 2011 19:49:11 -0000 Agreed. Phil On 2011-09-16, at 12:08, Torsten Lodderstedt wrote: > I reviewed the diffs and it looks ok. > > regards, > Torsten. > > Am 07.09.2011 17:59, schrieb Barry Leiba: >> As you've all probably seen, Eran has posted version 21 of the OAuth >> base spec, in which he believes he's addressed all comments and issues >> that came up in the review of version 20. We should be ready to send >> this to the IESG. >> >> Everyone who had comments or issues, please review -21 and make sure >> that your concerns have been handled to your satisfaction (or that >> there was no consensus to make a change). And we encourage everyone >> to review the changes from -20 to -21, to make sure Eran didn't >> inadvertently break anything along the way. >> >> The -21 is here: http://tools.ietf.org/html/draft-ietf-oauth-v2-21 >> And diffs from -20 can be found here: >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-21.txt >> >> We'll give it until the end of next week, while I work on the shepherd >> writeup. Comments, please, by 16 September. A few affirmative notes >> saying, "Yes, I reviewed it and it looks good," will also be helpful. >> Keep in mind, as you review, that pet changes are out of scope at this >> point. We're just reviewing -21 to make sure (1) it doesn't break >> anything from -20, and (2) it isn't missing anything that was brought >> up in WGLC. New issues will have to be very serious, indeed, in order >> to be considered now. >> >> Also, a note on the thread that Mike Thomas started about the OAuth >> problem statement and threats: >> I did encourage him to start the discussion, and I think it can be a >> useful conversation. I do NOT think it will or should result in a >> change to the base spec, but it might feed into the threat model >> document (draft-ietf-oauth-v2-threatmodel), as Torsten, et al, move >> that toward completion. Remember that the base spec encourages >> readers to refer to the threat model document for more detailed >> descriptions of threats and attacks. >> >> 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 cmortimore@salesforce.com Fri Sep 16 13:04: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 B98DE21F8D56 for ; Fri, 16 Sep 2011 13:04: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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vD4bJCsbzesC for ; Fri, 16 Sep 2011 13:04:59 -0700 (PDT) Received: from exprod8og112.obsmtp.com (exprod8og112.obsmtp.com [64.18.3.24]) by ietfa.amsl.com (Postfix) with SMTP id B6D1B21F8D15 for ; Fri, 16 Sep 2011 13:04:58 -0700 (PDT) Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob112.postini.com ([64.18.7.12]) with SMTP ID DSNKTnOsajgrUjnMSPI77qUCxrw4a8yafrDi@postini.com; Fri, 16 Sep 2011 13:07:14 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.46]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Fri, 16 Sep 2011 13:07:05 -0700 From: Chuck Mortimore To: Torsten Lodderstedt Date: Fri, 16 Sep 2011 13:06:54 -0700 Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt Thread-Index: Acx0rDTu6ZzDG/sxS8KUqnbWrhBpcQ== Message-ID: <19099790-0E64-4F08-80D5-FC2DFD903AD2@salesforce.com> References: <20110916192014.6501.87499.idtracker@ietfa.amsl.com> <4E73A431.2020205@lodderstedt.net> In-Reply-To: <4E73A431.2020205@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_190997900E644F0880D5FC2DFD903AD2salesforcecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.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, 16 Sep 2011 20:04:59 -0000 --_000_190997900E644F0880D5FC2DFD903AD2salesforcecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgaXQncyBub3QgYWxyZWFkeSBpbXBsaWNpdCBieSBvdXIgaW1wbGVtZW50YXRpb24sIEknbSB2 b2ljaW5nIG91ciBzdXBwb3J0IGZvciB0aGlzIGJlY29taW5nIGEgd29ya2luZyBncm91cCBpdGVt Lg0KDQotIGNtb3J0DQoNCk9uIFNlcCAxNiwgMjAxMSwgYXQgMTI6MzEgUE0sICJUb3JzdGVuIExv ZGRlcnN0ZWR0IiA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVy c3RlZHQubmV0Pj4gd3JvdGU6DQoNCkhpIGFsbCwNCg0KSSBqdXN0IHB1Ymxpc2hlZCBhIG5ldyBy ZXZpc2lvbiBvZiB0aGUgdG9rZW4gcmV2b2NhdGlvbiBkcmFmdC4gV2UgYWRkZWQgSlNPTlAgc3Vw cG9ydCAodGhhbmtzIHRvIE1hcml1cykgYW5kIGFsaWduZWQgdGhlIHRleHQgd2l0aCBkcmFmdCAy MSBvZiB0aGUgY29yZSBzcGVjLg0KDQpXZSB3b3VsZCBsaWtlIHRvIGJyaW5nIHRoaXMgZHJhZnQg Zm9yd2FyZCBhcyB3b3JraW5nIGdyb3VwIGl0ZW0gKG9uY2UgdGhlIFdHIGlzIHJlYWR5KS4gV2Ug dGhpbmsgaXRzIHJlbGV2YW5jZSBpcyBpbGx1c3RyYXRlZCBieSB0aGUgZmFjdCB0aGF0IHRoaXMg ZHJhZnQgKG9yIGl0cyBwcmVkZWNlc3NvcikgaGFzIGFscmVhZHkgYmVlbiBpbXBsZW1lbnRlZCBi eSBHb29nbGUsIFNhbGVzZm9yY2UsIGFuZCBEZXV0c2NoZSBUZWxla29tLg0KDQpyZWdhcmRzLA0K VG9yc3Rlbi4NCg0KLS0tLS0tLS0gT3JpZ2luYWwtTmFjaHJpY2h0IC0tLS0tLS0tDQpCZXRyZWZm OiAgICAgICAgTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sb2RkZXJzdGVkdC1v YXV0aC1yZXZvY2F0aW9uLTAzLnR4dA0KRGF0dW06ICBGcmksIDE2IFNlcCAyMDExIDEyOjIwOjE0 IC0wNzAwDQpWb246ICAgIDxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCkFuOiAg ICAgPG1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gdG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQ8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KQ0M6ICAgICA8bWFpbHRvOnNkcm9u aWFAZ214LmRlPiBzZHJvbmlhQGdteC5kZTxtYWlsdG86c2Ryb25pYUBnbXguZGU+LCA8bWFpbHRv OnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+LCA8bWFpbHRvOm1zY3VydGVzY3VAZ29vZ2xlLmNvbT4g bXNjdXJ0ZXNjdUBnb29nbGUuY29tPG1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20+DQoNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmV2b2NhdGlv bi0wMy50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUb3JzdGVuIExvZGRl cnN0ZWR0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAg ICAgICBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yZXZvY2F0aW9uDQpSZXZpc2lvbjogICAgICAg IDAzDQpUaXRsZTogICAgICAgICAgIFRva2VuIFJldm9jYXRpb24NCkNyZWF0aW9uIGRhdGU6ICAg MjAxMS0wOS0xNg0KV0cgSUQ6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJl ciBvZiBwYWdlczogNg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgcHJvcG9zZXMgYW4gYWRk aXRpb25hbCBlbmRwb2ludCBmb3IgT0F1dGggYXV0aG9yaXphdGlvbg0KICAgc2VydmVycyBmb3Ig cmV2b2tpbmcgdG9rZW5zLg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg== --_000_190997900E644F0880D5FC2DFD903AD2salesforcecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5JZiBpdCdzIG5vdCBhbHJlYWR5IGlt cGxpY2l0IGJ5IG91ciBpbXBsZW1lbnRhdGlvbiwgSSdtIHZvaWNpbmcgb3VyIHN1cHBvcnQgZm9y IHRoaXMgYmVjb21pbmcgYSB3b3JraW5nIGdyb3VwIGl0ZW0uICZuYnNwOyZuYnNwOzxicj48YnI+ LSBjbW9ydDwvZGl2PjxkaXY+PGJyPk9uIFNlcCAxNiwgMjAxMSwgYXQgMTI6MzEgUE0sICJUb3Jz dGVuIExvZGRlcnN0ZWR0IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQu bmV0Ij50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+ PGRpdj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pg0KICAgIEhpIGFsbCw8YnI+ DQogICAgPGJyPg0KICAgIEkganVzdCBwdWJsaXNoZWQgYSBuZXcgcmV2aXNpb24gb2YgdGhlIHRv a2VuIHJldm9jYXRpb24gZHJhZnQuIFdlDQogICAgYWRkZWQgSlNPTlAgc3VwcG9ydCAodGhhbmtz IHRvIE1hcml1cykgYW5kIGFsaWduZWQgdGhlIHRleHQgd2l0aA0KICAgIGRyYWZ0IDIxIG9mIHRo ZSBjb3JlIHNwZWMuPGJyPg0KICAgIDxicj4NCiAgICBXZSB3b3VsZCBsaWtlIHRvIGJyaW5nIHRo aXMgZHJhZnQgZm9yd2FyZCBhcyB3b3JraW5nIGdyb3VwIGl0ZW0NCiAgICAob25jZSB0aGUgV0cg aXMgcmVhZHkpLiBXZSB0aGluayBpdHMgcmVsZXZhbmNlIGlzIGlsbHVzdHJhdGVkIGJ5IHRoZQ0K ICAgIGZhY3QgdGhhdCB0aGlzIGRyYWZ0IChvciBpdHMgcHJlZGVjZXNzb3IpIGhhcyBhbHJlYWR5 IGJlZW4NCiAgICBpbXBsZW1lbnRlZCBieSBHb29nbGUsIFNhbGVzZm9yY2UsIGFuZCBEZXV0c2No ZSBUZWxla29tLjxicj4NCiAgICA8YnI+DQogICAgcmVnYXJkcyw8YnI+DQogICAgVG9yc3Rlbi48 YnI+DQogICAgPGJyPg0KICAgIC0tLS0tLS0tIE9yaWdpbmFsLU5hY2hyaWNodCAtLS0tLS0tLQ0K ICAgIDx0YWJsZSBjbGFzcz0ibW96LWVtYWlsLWhlYWRlcnMtdGFibGUiIGJvcmRlcj0iMCIgY2Vs bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4NCiAgICAgIDx0Ym9keT4NCiAgICAgICAgPHRy Pg0KICAgICAgICAgIDx0aCBhbGlnbj0iUklHSFQiIG5vd3JhcD0ibm93cmFwIiB2YWxpZ249IkJB U0VMSU5FIj5CZXRyZWZmOiA8L3RoPg0KICAgICAgICAgIDx0ZD5OZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yDQogICAgICAgICAgICBkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1yZXZvY2F0aW9u LTAzLnR4dDwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICAgIDx0cj4NCiAgICAgICAgICA8dGgg YWxpZ249IlJJR0hUIiBub3dyYXA9Im5vd3JhcCIgdmFsaWduPSJCQVNFTElORSI+RGF0dW06IDwv dGg+DQogICAgICAgICAgPHRkPkZyaSwgMTYgU2VwIDIwMTEgMTI6MjA6MTQgLTA3MDA8L3RkPg0K ICAgICAgICA8L3RyPg0KICAgICAgICA8dHI+DQogICAgICAgICAgPHRoIGFsaWduPSJSSUdIVCIg bm93cmFwPSJub3dyYXAiIHZhbGlnbj0iQkFTRUxJTkUiPlZvbjogPC90aD4NCiAgICAgICAgICA8 dGQ+PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwvYT48L3RkPg0KICAgICAgICA8L3Ry Pg0KICAgICAgICA8dHI+DQogICAgICAgICAgPHRoIGFsaWduPSJSSUdIVCIgbm93cmFwPSJub3dy YXAiIHZhbGlnbj0iQkFTRUxJTkUiPkFuOiA8L3RoPg0KICAgICAgICAgIDx0ZD48YSBjbGFzcz0i bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQiPjxhIGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBs b2RkZXJzdGVkdC5uZXQ8L2E+PC9hPjwvdGQ+DQogICAgICAgIDwvdHI+DQogICAgICAgIDx0cj4N CiAgICAgICAgICA8dGggYWxpZ249IlJJR0hUIiBub3dyYXA9Im5vd3JhcCIgdmFsaWduPSJCQVNF TElORSI+Q0M6IDwvdGg+DQogICAgICAgICAgPHRkPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJi cmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpzZHJvbmlhQGdteC5kZSI+PGEgaHJlZj0ibWFpbHRvOnNk cm9uaWFAZ214LmRlIj5zZHJvbmlhQGdteC5kZTwvYT48L2E+LCA8YSBjbGFzcz0ibW96LXR4dC1s aW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiPjxh IGhyZWY9Im1haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCI+dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXQ8L2E+PC9hPiwNCiAgICAgICAgICAgIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2 aWF0ZWQiIGhyZWY9Im1haWx0bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iPjxhIGhyZWY9Im1haWx0 bzptc2N1cnRlc2N1QGdvb2dsZS5jb20iPm1zY3VydGVzY3VAZ29vZ2xlLmNvbTwvYT48L2E+PC90 ZD4NCiAgICAgICAgPC90cj4NCiAgICAgIDwvdGJvZHk+DQogICAgPC90YWJsZT4NCiAgICA8YnI+ DQogICAgPGJyPg0KICAgIDxwcmU+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxvZGRlcnN0 ZWR0LW9hdXRoLXJldm9jYXRpb24tMDMudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgVG9yc3RlbiBMb2RkZXJzdGVkdCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtbG9kZGVyc3RlZHQtb2F1dGgtcmV2b2NhdGlvbg0KUmV2 aXNpb246CSAwMw0KVGl0bGU6CQkgVG9rZW4gUmV2b2NhdGlvbg0KQ3JlYXRpb24gZGF0ZToJIDIw MTEtMDktMTYNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2Vz OiA2DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBwcm9wb3NlcyBhbiBhZGRpdGlvbmFsIGVu ZHBvaW50IGZvciBPQXV0aCBhdXRob3JpemF0aW9uDQogICBzZXJ2ZXJzIGZvciByZXZva2luZyB0 b2tlbnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KPC9wcmU+DQogIA0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvc3Bhbj48YnI+PHNwYW4+T0F1dGggbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bh bj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvc3Bh bj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48 L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --_000_190997900E644F0880D5FC2DFD903AD2salesforcecom_-- From jricher@mitre.org Mon Sep 19 05:46: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 374F221F8BCB for ; Mon, 19 Sep 2011 05:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 clmksl0KpcVW for ; Mon, 19 Sep 2011 05:46:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9158B21F8BC5 for ; Mon, 19 Sep 2011 05:46:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B352021B176C; Mon, 19 Sep 2011 08:48:37 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A510121B09F0; Mon, 19 Sep 2011 08:48:37 -0400 (EDT) Received: from [129.83.50.1] (129.83.31.55) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server id 14.1.270.1; Mon, 19 Sep 2011 08:48:37 -0400 From: Justin Richer To: Chuck Mortimore In-Reply-To: <19099790-0E64-4F08-80D5-FC2DFD903AD2@salesforce.com> References: <20110916192014.6501.87499.idtracker@ietfa.amsl.com> <4E73A431.2020205@lodderstedt.net> <19099790-0E64-4F08-80D5-FC2DFD903AD2@salesforce.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 19 Sep 2011 08:47:20 -0400 Message-ID: <1316436440.9516.121.camel@ground> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.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, 19 Sep 2011 12:46:18 -0000 I also want to voice support for this. We've implemented an earlier version of this on a few of our projects as well. -- Justin On Fri, 2011-09-16 at 16:06 -0400, Chuck Mortimore wrote: > If it's not already implicit by our implementation, I'm voicing our > support for this becoming a working group item. > > - cmort > > On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt" > wrote: > > > > > Hi all, > > > > I just published a new revision of the token revocation draft. We > > added JSONP support (thanks to Marius) and aligned the text with > > draft 21 of the core spec. > > > > We would like to bring this draft forward as working group item > > (once the WG is ready). We think its relevance is illustrated by the > > fact that this draft (or its predecessor) has already been > > implemented by Google, Salesforce, and Deutsche Telekom. > > > > regards, > > Torsten. > > > > -------- Original-Nachricht -------- > > Betreff: > > New Version Notification for > > draft-lodderstedt-oauth-revocation-03.txt > > Datum: > > Fri, 16 Sep 2011 12:20:14 -0700 > > Von: > > internet-drafts@ietf.org > > An: > > torsten@lodderstedt.net > > CC: > > sdronia@gmx.de, > > torsten@lodderstedt.net, > > mscurtescu@google.com > > > > > > A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. > > > > Filename: draft-lodderstedt-oauth-revocation > > Revision: 03 > > Title: Token Revocation > > Creation date: 2011-09-16 > > WG ID: Individual Submission > > Number of pages: 6 > > > > Abstract: > > This draft proposes an additional endpoint for OAuth authorization > > servers for revoking tokens. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From aanganes@mitre.org Mon Sep 19 08:20: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 4F21421F8C52 for ; Mon, 19 Sep 2011 08:20:17 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 A9Dg7UUJnZ0Q for ; Mon, 19 Sep 2011 08:20:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7C78521F8C5E for ; Mon, 19 Sep 2011 08:20:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BC95421B17AA for ; Mon, 19 Sep 2011 11:22:35 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id ABF0821B0E9E for ; Mon, 19 Sep 2011 11:22:35 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 19 Sep 2011 11:22:35 -0400 From: "Anganes, Amanda L" To: "oauth@ietf.org" Date: Mon, 19 Sep 2011 11:22:34 -0400 Thread-Topic: OAuth 2.0 v21 Nits and Typos Thread-Index: Acx23/QyH/ollQzMTvycxaih82WAow== Message-ID: <235AEAA316C791418CE9E8FEFC77306110D6FFB801@IMCMBX3.MITRE.ORG> 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_235AEAA316C791418CE9E8FEFC77306110D6FFB801IMCMBX3MITREO_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 19 Sep 2011 08:40:47 -0700 Subject: [OAUTH-WG] OAuth 2.0 v21 Nits and Typos 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, 19 Sep 2011 15:21:20 -0000 --_000_235AEAA316C791418CE9E8FEFC77306110D6FFB801IMCMBX3MITREO_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lots of minor grammar and wording catches here. I apologize if any of these= were already brought up and addressed. 1.2.3, second paragraph: "When issuing an implicit grant, the authorization= server does not authenticate the client and in some cases, the client iden= tity can be verified..." should be "When issuing an implicit grant, the aut= horization server does not authenticate the client. In some cases, the clie= nt identity can be verified..." 1.5, first paragraph. Last sentence should be changed to "Issuing a refresh= token is optional. If an authorization server issues a refresh token, it i= s included when issuing an access token." 2.1, definition of public client: last sentence ends with "via any other me= an" which should be "via any other means". 2.1, definition of native applications: "On the other hand, dynamically iss= ued credentials such as access tokens or refresh tokens, can receive an acc= eptable level of protection" should be "On the other hand, dynamically issu= ed credentials such as access tokens or refresh tokens can receive an accep= table level of protection" (final comma is unnecessary). 3.1, second paragraph. Add a comma after "beyond the scope of this specific= ation", so it reads "The means through which the client obtains the locatio= n of the authorization endpoint are beyond the scope of this specification,= but the location is typically provided in the service documentation". 3.2.1, first sentence. Unnecessary comma between "requirements" and "MUST";= should read "Confidential clients, clients issued client credentials, or c= lients assigned other authentication requirements MUST authenticate..." 4.1, section (E): last sentence is missing a subject. "If valid, responds b= ack with an..." should read "If valid, the authorization server responds ba= ck with an..." 4.1.2 and 4.1.2.1, also 4.2.2 and 4.2.2.1, state description: last sentence= is missing a MUST. Should read "REQUIRED if the state parameter was presen= t in the client authorization request. The state parameter MUST be set to t= he exact value received from the client." 4.1.3, redirect_uri description: Change "REQUIRED, if the redirect_uri para= meter was included in the authorization request described in Section 4.1.1,= and their values MUST be identical" to "REQUIRED, if the redirect_uri para= meter was included in the authorization request as described in Section 4.1= .1. If included, the two values MUST be identical". 4.1.3, final paragraph ("The authorization server MUST: ..."). Is any addit= ional normative language required for lists such as this in order to specif= y that the AS must do ALL of the items in the list? Similar MUST lists appe= ar elsewhere throughout the rest of the document. Also, final bullet should be reworded; suggest "ensure that the redirect_ur= i parameter is present if the redirect_uri parameter was included in the in= itial authorization request as described in Section 4.1.1, and if included = ensure that their values are identical". 4.2, first paragraph: clarify that implicit grants can be used only for acc= ess tokens by including the word "only" here: "The implicit grant type is u= sed to obtain access tokens only..." 4.3.2, paragraph after term parameter descriptions: "If the client type is = confidential or was issued client credentials" should be reworded to "If th= e client type is confidential or the client was issued client credentials". 9, bullets following second paragraph: Change this to a definition list for= mat instead of a bulleted list. 9, final bullet following "when choosing between an external or embedded us= er-agent...": Last sentence starts "Embedded user-agent educate..." but sho= uld be "Embedded user-agents educate..." 10.2, second paragraph: last sentence is a fragment. Reword to "For example= , the authorization server should engage the resource owner to assist in id= entify the client and its origin." 10.5, second paragraph, first sentence: extraneous comma between "authoriza= tion server" and "is". Should be "...verify that the resource owner who gra= nted authorization at the authorization server is the same resource owner..= ." 10.6, last paragraph, first sentence: extraneous comma between "authorizati= on code" and "is the same". Should be "... the authorization server MUST en= sure that the redirection URI used to obtain the authorization code is the = same as the redirection URI provided ..." Last sentence should be reworded; suggest "The authorization server MUST re= quire public clients and SHOULD require confidential clients to register th= eir redirection URIs. If a redirection URI is provided in the authorization= request, the authorization server MUST validate the URI received against t= he registered value." 10.14, first sentence. Reads awkwardly and should be reworded; suggest "A c= ode injection attack occurs when an unsanitized input or otherwise external= variable is used to modify application logic." 11.1, 11.2, 11.3, 11.4: second to last paragraph is missing "(s)" on the en= d of "Designated Expert" : "Decisions (or lack thereof) made by the Designa= ted Expert can be..." should be "Decisions (or lack thereof) made by the De= signated Expert(s) can be..." 11.2, second paragraph has extraneous comma after "or the token endpoint re= sponse" : "...the token endpoint request, or the token endpoint response, a= re registered" should be "...the token endpoint request, or the token endpo= int response are registered". 11.2.1, "Parameter usage location" description should have references to th= e relevant sections of this spec, as 11.4.1 does. --Amanda Anganes The MITRE Corporation --_000_235AEAA316C791418CE9E8FEFC77306110D6FFB801IMCMBX3MITREO_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lots of minor gr= ammar and wording catches here. I apologize if any of these were already br= ought up and addressed.

 

1.2.3, second paragraph: “When issuing an i= mplicit grant, the authorization server does not authenticate the client an= d in some cases, the client identity can be verified…” should b= e “When issuing an implicit grant, the authorization server does not = authenticate the client. In some cases, the client identity can be verified= …”

 

1.5, first paragraph. Last sentence should be changed to &= #8220;Issuing a refresh token is optional. If an authorization server issue= s a refresh token, it is included when issuing an access token.”=

 

2.= 1, definition of public client: last sentence ends with “via any othe= r mean” which should be “via any other means”.=

2.1, definition of native applications: “On = the other hand, dynamically issued credentials such as access tokens or ref= resh tokens, can receive an acceptable level of protection” should be= “On the other hand, dynamically issued credentials such as access to= kens or refresh tokens can receive an acceptable level of protection”= (final comma is unnecessary).

&nbs= p;

3.1, second paragraph. Add a comma after &= #8220;beyond the scope of this specification”, so it reads “The= means through which the client obtains the location of the authorization e= ndpoint are beyond the scope of this specification, but the location is typ= ically provided in the service documentation”.

 

3.2.1, first sentenc= e. Unnecessary comma between “requirements” and “MUSTR= 21;; should read “Confidential clients, clients issued client credent= ials, or clients assigned other authentication requirements MUST authentica= te…”

 

4.1, section (E): last sentence is missing a subject. &#= 8220;If valid, responds back with an…” should read “If va= lid, the authorization server responds back with an…”

 

4.1.2 a= nd 4.1.2.1, also 4.2.2 and 4.2.2.1, state description: last sentence is mis= sing a MUST. Should read “REQUIRED if the state parameter was present= in the client authorization request. The state parameter MUST be set to th= e exact value received from the client.”

 

4.1.3, redirect_uri descri= ption: Change “REQUIRED, if the redirect_uri parameter was included i= n the authorization request described in Section 4.1.1, and their values MU= ST be identical” to “REQUIRED, if the redirect_uri parameter wa= s included in the authorization request as described in Section 4.1.1. If i= ncluded, the two values MUST be identical”.

 

4.1.3, final paragraph = (“The authorization server MUST: …”). Is any additional n= ormative language required for lists such as this in order to specify that = the AS must do ALL of the items in the list? Similar MUST lists appear else= where throughout the rest of the document.

Also, final bullet should be reworded; suggest “ensure that the r= edirect_uri parameter is present if the redirect_uri parameter was included= in the initial authorization request as described in Section 4.1.1, and if= included ensure that their values are identical”.

 

4.2, first parag= raph: clarify that implicit grants can be used only for access tokens by in= cluding the word “only” here: “The implicit grant type is= used to obtain access tokens only…”

 

4.3.2, paragraph after t= erm parameter descriptions: “If the client type is confidential or wa= s issued client credentials” should be reworded to “If the clie= nt type is confidential or the client was issued client credentials”.=

 

9, bullets following second paragraph: Change this to a definition list = format instead of a bulleted list.

9, fi= nal bullet following “when choosing between an external or embedded u= ser-agent…”: Last sentence starts “Embedded user-agent ed= ucate…” but should be “Embedded user-agents educate…= ;”

 

10.2, second paragraph: last sentence is a fragment. Reword to= “For example, the authorization server should engage the resource ow= ner to assist in identify the client and its origin.”

<= p class=3DMsoNormal> 

10.5, second = paragraph, first sentence: extraneous comma between “authorization se= rver” and “is”. Should be “…verify that the r= esource owner who granted authorization at the authorization server is the = same resource owner…”

&= nbsp;

10.6, last paragraph, first sentence: e= xtraneous comma between “authorization code” and “is the = same”. Should be “… the authorization server MUST ensure = that the redirection URI used to obtain the authorization code is the same = as the redirection URI provided …”

Last sentence should be reworded; suggest “The authorization = server MUST require public clients and SHOULD require confidential clients = to register their redirection URIs. If a redirection URI is provided in the= authorization request, the authorization server MUST validate the URI rece= ived against the registered value.”

 

10.14, first sentence. Reads aw= kwardly and should be reworded; suggest “A code injection attack occu= rs when an unsanitized input or otherwise external variable is used to modi= fy application logic.”

 =

11.1, 11.2, 11.3, 11.4: second to last parag= raph is missing “(s)” on the end of “Designated Expert= 221; : “Decisions (or lack thereof) made by the Designated Expert can= be…” should be “Decisions (or lack thereof) made by the = Designated Expert(s) can be…”

 

11.2, second paragraph has extr= aneous comma after “or the token endpoint response” : “&#= 8230;the token endpoint request, or the token endpoint response, are regist= ered” should be “…the token endpoint request, or the toke= n endpoint response are registered”.

 

11.2.1, “Parameter usage= location” description should have references to the relevant section= s of this spec, as 11.4.1 does.

&nb= sp;

--Amanda Anganes

The MITRE Corporation

= --_000_235AEAA316C791418CE9E8FEFC77306110D6FFB801IMCMBX3MITREO_-- From mscurtescu@google.com Mon Sep 19 11:45: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 DB2E321F8C6C for ; Mon, 19 Sep 2011 11:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.177 X-Spam-Level: X-Spam-Status: No, score=-106.177 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 jBfRDxq1BYsS for ; Mon, 19 Sep 2011 11:45:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C456C21F8C65 for ; Mon, 19 Sep 2011 11:45:58 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p8JImKq6019778 for ; Mon, 19 Sep 2011 11:48:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316458101; bh=OC8Bum514wCz3YFCBFMBs5/VvjE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Q/h1b5iPdOgysHqGQvB4igPdh5ay6Yynr1LYRb/oD4b5h/gm35tMBX7D0T1/1mV31 DUhbKMCrBPqHvpgrg3o7w== 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:x-system-of-record; b=WcuBJLs2pe9zL4DE9zqOu1btdlcj5//0XATf70y4i85U2ef8mWECxKwtukkDCWfMA sbQ+762fKeKTrZm8WlKsg== Received: from qwg2 (qwg2.prod.google.com [10.241.194.130]) by wpaz21.hot.corp.google.com with ESMTP id p8JIjFFx002947 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 19 Sep 2011 11:48:19 -0700 Received: by qwg2 with SMTP id 2so6709861qwg.4 for ; Mon, 19 Sep 2011 11:48:19 -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; bh=ozGx1fZJdJAblcCyQkBDhGu5edle+eJjQ4I4why8ZHs=; b=w0GKcA8HydCpvC7h/SyBwd+X/zE8HCEexDte8DwLGmvY2KvCTf5o4AjYiqfkVF+oM4 ez5W/tX2xMrBg3ZuOfvg== Received: by 10.229.179.232 with SMTP id br40mr1686188qcb.218.1316458099433; Mon, 19 Sep 2011 11:48:19 -0700 (PDT) Received: by 10.229.179.232 with SMTP id br40mr1686177qcb.218.1316458099080; Mon, 19 Sep 2011 11:48:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.139.148 with HTTP; Mon, 19 Sep 2011 11:47:59 -0700 (PDT) In-Reply-To: <19099790-0E64-4F08-80D5-FC2DFD903AD2@salesforce.com> References: <20110916192014.6501.87499.idtracker@ietfa.amsl.com> <4E73A431.2020205@lodderstedt.net> <19099790-0E64-4F08-80D5-FC2DFD903AD2@salesforce.com> From: Marius Scurtescu Date: Mon, 19 Sep 2011 11:47:59 -0700 Message-ID: To: Chuck Mortimore Content-Type: multipart/alternative; boundary=0016369fa2135b7cc704ad4fc926 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.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, 19 Sep 2011 18:46:00 -0000 --0016369fa2135b7cc704ad4fc926 Content-Type: text/plain; charset=ISO-8859-1 +1 On Fri, Sep 16, 2011 at 1:06 PM, Chuck Mortimore wrote: > If it's not already implicit by our implementation, I'm voicing our support > for this becoming a working group item. > > - cmort > > On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt" < > torsten@lodderstedt.net> wrote: > > Hi all, > > I just published a new revision of the token revocation draft. We added > JSONP support (thanks to Marius) and aligned the text with draft 21 of the > core spec. > > We would like to bring this draft forward as working group item (once the > WG is ready). We think its relevance is illustrated by the fact that this > draft (or its predecessor) has already been implemented by Google, > Salesforce, and Deutsche Telekom. > > regards, > Torsten. > > -------- Original-Nachricht -------- Betreff: New Version Notification > for draft-lodderstedt-oauth-revocation-03.txt Datum: Fri, 16 Sep 2011 > 12:20:14 -0700 Von: internet-drafts@ietf.org An: > torsten@lodderstedt.net CC: > sdronia@gmx.de, torsten@lodderstedt.net, > mscurtescu@google.com > > A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. > > Filename: draft-lodderstedt-oauth-revocation > Revision: 03 > Title: Token Revocation > Creation date: 2011-09-16 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > This draft proposes an additional endpoint for OAuth authorization > servers for revoking tokens. > > > > > The IETF Secretariat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016369fa2135b7cc704ad4fc926 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1


On Fri, Sep 16, 2011= at 1:06 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:
If it's not already implicit by our imple= mentation, I'm voicing our support for this becoming a working group it= em. =A0=A0

- cmort

O= n Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt" <torsten@lodderstedt.net<= /a>> wrote:

Hi all,

I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec.

We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom.

regards,
Torsten.

-------- Original-Nachricht --------
Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt
Datum: Fri, 16 Sep 2011 12:20:14 -0700
Von: internet= -drafts@ietf.org
An: = torsten@lo= dderstedt.net
CC: sdronia@gmx.de, torsten@lodderstedt.net, = mscurtescu@googl= e.com 


A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt ha=
s been successfully submitted by Torsten Lodderstedt and posted to the IETF=
 repository.

Filename:	 draft-lodderstedt-oauth-revocation
Revision:	 03
Title:		 Token Revocation
Creation date:	 2011-09-16
WG ID:		 Individual Submission
Number of pages: 6

Abstract:
   This draft proposes an additional endpoint for OAuth authorization
   servers for revoking tokens.

                                                                           =
      =20


The IETF Secretariat
=20

--0016369fa2135b7cc704ad4fc926-- From eran@hueniverse.com Mon Sep 19 11:50: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 0388721F8CBB for ; Mon, 19 Sep 2011 11:50:33 -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 hBNg4iKM4eNb for ; Mon, 19 Sep 2011 11:50: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 0769621F8C71 for ; Mon, 19 Sep 2011 11:50:30 -0700 (PDT) Received: (qmail 18938 invoked from network); 19 Sep 2011 18:52:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Sep 2011 18:52:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 19 Sep 2011 11:52:44 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , Chuck Mortimore Date: Mon, 19 Sep 2011 11:52:37 -0700 Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt Thread-Index: Acx2/Nm6pT3jkKb6Rz6IQePqNBuuqAAACTsA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92A5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110916192014.6501.87499.idtracker@ietfa.amsl.com> <4E73A431.2020205@lodderstedt.net> <19099790-0E64-4F08-80D5-FC2DFD903AD2@salesforce.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_90C41DD21FB7C64BB94121FBBC2E72345213D92A5DP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.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, 19 Sep 2011 18:50:33 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345213D92A5DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a general note: you don't need every spec to become a working group it= em. If you get an area director to sponsor your draft, you can push it thro= ugh sooner as an individual submission. Sometimes you don't even need spons= orship. I'm not saying this out of any objection to the WG taking on this work, jus= t that I don't see a reason to wait. If you feel this simple document is re= ady and has consensus, you should find a sponsor and move to IETF LC. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= arius Scurtescu Sent: Monday, September 19, 2011 11:48 AM To: Chuck Mortimore Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt= -oauth-revocation-03.txt +1 On Fri, Sep 16, 2011 at 1:06 PM, Chuck Mortimore > wrote: If it's not already implicit by our implementation, I'm voicing our support= for this becoming a working group item. - cmort On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt" > wrote: Hi all, I just published a new revision of the token revocation draft. We added JSO= NP support (thanks to Marius) and aligned the text with draft 21 of the cor= e spec. We would like to bring this draft forward as working group item (once the W= G is ready). We think its relevance is illustrated by the fact that this dr= aft (or its predecessor) has already been implemented by Google, Salesforce= , and Deutsche Telekom. regards, Torsten. -------- Original-Nachricht -------- Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt Datum: Fri, 16 Sep 2011 12:20:14 -0700 Von: internet-drafts@ietf.org An: torsten@lodderstedt.net CC: sdronia@gmx.de, torsten@lodderstedt.net, mscurtescu@google.com A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been su= ccessfully submitted by Torsten Lodderstedt and posted to the IETF reposito= ry. Filename: draft-lodderstedt-oauth-revocation Revision: 03 Title: Token Revocation Creation date: 2011-09-16 WG ID: Individual Submission Number of pages: 6 Abstract: This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72345213D92A5DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a ge= neral note: you don’t need every spec to become a working group item.= If you get an area director to sponsor your draft, you can push it through= sooner as an individual submission. Sometimes you don’t even need sp= onsorship.

 

I’m not saying this out of a= ny objection to the WG taking on this work, just that I don’t see a r= eason to wait. If you feel this simple document is ready and has consensus,= you should find a sponsor and move to IETF LC.

 

EHL

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bo= unces@ietf.org] On Behalf Of Marius Scurtescu
Sent: Monday= , September 19, 2011 11:48 AM
To: Chuck Mortimore
Cc: O= Auth WG
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for= draft-lodderstedt-oauth-revocation-03.txt

 

+1

On Fri, Sep 16, 2011 at 1:06 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:

If it's not already implicit by our i= mplementation, I'm voicing our support for this becoming a working group it= em.   

- cmort


On Sep 16, 2011, at 12:31 P= M, "Torsten Lodderstedt" <torsten@lodderstedt.net> wrote:<= /p>

Hi all,

I just published a new revision of the to= ken revocation draft. We added JSONP support (thanks to Marius) and aligned= the text with draft 21 of the core spec.

We would like to bring thi= s draft forward as working group item (once the WG is ready). We think its = relevance is illustrated by the fact that this draft (or its predecessor) h= as already been implemented by Google, Salesforce, and Deutsche Telekom.
regards,
Torsten.

-------- Original-Nachricht -------- =

<= td nowrap valign=3Dtop style=3D'padding:0in 0in 0in 0in'>

Von:

Betreff: <= /o:p>

New Version Notification for draft-lodderstedt-oauth-revocation-03.txt

D= atum:

Fri, 16 Sep 2011 12:20:14 -0700

internet-drafts@ietf.org=

<= b>An:

= torsten@lodderstedt.net

CC:

sdronia@gmx.de, torsten@lodderstedt.net, mscurtescu@google.com=

<= o:p> 

A new version of I-D, draft-lodderstedt-oauth-revo=
cation-03.txt has been successfully submitted by Torsten Lodderstedt and po=
sted to the IETF repository.
 
Filename:       draft-lodderstedt-oauth-r= evocation
Revision:      =
;  03
Title:       =
    Token Revocation
Creation date:   2=
011-09-16
WG ID:      &n=
bsp;    Individual Submission
Number of page=
s: 6
 
Abstract:<=
/pre>
   This draft proposes an additional endpoint for OAuth=
 authorization
   servers for revoking token=
s.
 
    =
;            &n=
bsp;            =
;             &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;  
 
 =

The IETF Secretariat
<= p class=3DMsoNormal>_______________________________________________
OAut= h mailing list
OAuth= @ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /p>

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72345213D92A5DP3PW5EX1MB01E_-- From bcampbell@pingidentity.com Mon Sep 19 13:00: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 F1C8D21F8D52 for ; Mon, 19 Sep 2011 13:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.075, 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 7KlitQs2vz5a for ; Mon, 19 Sep 2011 13:00:57 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 2B69E21F8CE6 for ; Mon, 19 Sep 2011 13:00:56 -0700 (PDT) Received: from mail-qy0-f182.google.com ([209.85.216.182]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTnef+4hplV43kOUjp2M6AjEWkDz6bRU4@postini.com; Mon, 19 Sep 2011 13:03:21 PDT Received: by mail-qy0-f182.google.com with SMTP id 4so5873687qyk.20 for ; Mon, 19 Sep 2011 13:03:07 -0700 (PDT) Received: by 10.224.206.6 with SMTP id fs6mr2482113qab.17.1316462586164; Mon, 19 Sep 2011 13:03:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.74.10 with HTTP; Mon, 19 Sep 2011 13:02:36 -0700 (PDT) From: Brian Campbell Date: Mon, 19 Sep 2011 14:02:36 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: [OAUTH-WG] Extensions example update (was Draft -21 next steps) 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, 19 Sep 2011 20:00:58 -0000 Although this isn't related to changes made since -20, it should probably still be done (unless it's something for the final RFC editors?) and shouldn't be much of a change. The example in section 4.5 [1] uses the "old" grant type URI for the SAML grant type (http://oauth.net/grant_type/saml/2.0/bearer) and it should probably be updated to use the "new" and hopefully final and stable one (urn:ietf:params:oauth:grant-type:saml2-bearer). Here's the example from the latest SAML draft [2]: POST /token.oauth2 HTTP/1.1 Host: authz.example.net Content-Type: application/x-www-form-urlencoded grant_type=3Durn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- bearer&assertion=3DPEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- Also the source xml, if that's useful: Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-21#section-4.5 [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-08#section-4 On Sun, Sep 4, 2011 at 5:49 PM, Eran Hammer-Lahav wro= te: > I=92d like to ask the chairs to declare a 2 weeks review period limited t= o > changes made since -20 after which we will either declare -21 as the fina= l > WG draft or publish a quick -22 with all changes agreed prior on the list > and no additional WG review period. Of course, the chairs can change all > these rules as they see fit. > > > > EHL > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From bcampbell@pingidentity.com Mon Sep 19 13:29: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 2C2A121F8CAD for ; Mon, 19 Sep 2011 13:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.904 X-Spam-Level: X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=0.073, 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 IxwhCd9X+9BN for ; Mon, 19 Sep 2011 13:29:03 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9663421F8C44 for ; Mon, 19 Sep 2011 13:28:58 -0700 (PDT) Received: from mail-qy0-f182.google.com ([209.85.216.182]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTnemmZuvMEIZu7a9PKTHsRNswLWm7396@postini.com; Mon, 19 Sep 2011 13:31:22 PDT Received: by qyk4 with SMTP id 4so6886444qyk.13 for ; Mon, 19 Sep 2011 13:31:21 -0700 (PDT) Received: by 10.224.197.6 with SMTP id ei6mr2602939qab.67.1316464281095; Mon, 19 Sep 2011 13:31:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.74.10 with HTTP; Mon, 19 Sep 2011 13:30:51 -0700 (PDT) In-Reply-To: <4E6F7FC3.1020600@oracle.com> References: <4E6F7FC3.1020600@oracle.com> From: Brian Campbell Date: Mon, 19 Sep 2011 14:30:51 -0600 Message-ID: To: Colm Divilly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Section 4.3. Resource Owner Password Credentials: Invalid Credentials Error Handling 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, 19 Sep 2011 20:29:16 -0000 The error should be invalid_grant as it is the grant (the resource owner's username and password) that is invalid. On Tue, Sep 13, 2011 at 10:07 AM, Colm Divilly wr= ote: > Apologies if this has been covered before, a cursory search of the archiv= es > and issue tracker didn't turn up anything. > > What is the expected error response when performing a Resource Owner > Password Credentials flow, if the resource owner provides incorrect > credentials? > > From reading the spec it looks like the expectation is that a response li= ke > the following should be generated: > > =A0 =A0 HTTP/1.1 400 Bad Request > =A0 =A0 Content-Type: application/json;charset=3DUTF-8 > =A0 =A0 Cache-Control: no-store > =A0 =A0 Pragma: no-cache > > =A0 =A0 { > =A0 =A0 =A0 "error":"invalid_request" > =A0 =A0 } > > Which is not terribly helpful for a user-agent trying to determine that i= t > is the user supplied credentials at fault (and therefore be able to > re-prompt the user for credentials). Perhaps something like the following > would be more useful: > > =A0 =A0 HTTP/1.1 400 Bad Request > =A0 =A0 Content-Type: application/json;charset=3DUTF-8 > =A0 =A0 Cache-Control: no-store > =A0 =A0 Pragma: no-cache > > =A0 =A0 { > =A0 =A0 =A0 "error":"invalid_resource_owner_credentials" > =A0 =A0 } > > A bit verbose perhaps, any alternative suggestions? > > Regards, > Colm Divilly > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Tue Sep 20 11:35: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 D36421F0C68 for ; Tue, 20 Sep 2011 11:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 dhKk9DuH7ghr for ; Tue, 20 Sep 2011 11:35: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 368171F0C57 for ; Tue, 20 Sep 2011 11:35:40 -0700 (PDT) Received: (qmail 620 invoked from network); 20 Sep 2011 18:38:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Sep 2011 18:38:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 20 Sep 2011 11:38:02 -0700 From: Eran Hammer-Lahav To: "eran@sled.com" , =?utf-8?B?QW5kcsOpIERlTWFycmU=?= Date: Tue, 20 Sep 2011 11:37:54 -0700 Thread-Topic: Authorization code use in draft-ietf-oauth-v2-21 Thread-Index: AcxvRR4XY4qdDqUCQEGA2vnS4w7g3gIflqNw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92C95@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <8A78E766-3A1D-4534-B336-3084A182EFD0@hueniverse.com> In-Reply-To: <8A78E766-3A1D-4534-B336-3084A182EFD0@hueniverse.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code use in draft-ietf-oauth-v2-21 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, 20 Sep 2011 18:35:40 -0000 DQoNCj4gT24gU2VwIDksIDIwMTEsIGF0IDE1OjMxLCAiQW5kcsOpIERlTWFycmUiIDxhbmRyZWRl bWFycmVAZ21haWwuY29tPg0KPiB3cm90ZToNCj4gDQo+ID4gR3JlZXRpbmdzIEV2ZXJ5b25lLA0K PiA+DQo+ID4gSSBob3BlIHRoZSBkcmFmdCBpc24ndCB0b28gZmFyIGFsb25nIGZvciB0aGVzZSBj b21tZW50cy4NCj4gPiAoZHJhZnQtaWV0Zi1vYXV0aC12Mi0yMSkNCj4gPg0KPiA+IDEuIEFVVEhP UklaQVRJT04gQ09ERSBSRVNUUklDVElPTlMNCj4gPg0KPiA+IFRoZSBzcGVjaWZpY2F0aW9uIChw YXJ0aWN1bGFybHkgU2VjdGlvbiA0LjEpIGRvZXMgbm90IHNheSBpZiB0aGUNCj4gPiBhdXRob3Jp emF0aW9uIHNlcnZlciBtYXkgb3IgbWF5IG5vdCBhbGxvdyBhbiBhdXRob3JpemF0aW9uIGNvZGUg dG8gYmUNCj4gPiB1c2VkIG1vcmUgdGhhbiBvbmNlIGluIGV4Y2hhbmdlIGZvciBhbiBhY2Nlc3Mg dG9rZW4uIChTZWN0aW9uIDQuMS4zKQ0KPiA+DQo+ID4gV2l0aCB0aGlzIGFtYmlndWl0eSwgc29t ZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgbWlnaHQNCj4gPiBhbGxvdyBh dXRob3JpemF0aW9uIGNvZGVzIHRvIGJlIHJldXNlZCBieSB0aGUgY2xpZW50ICh3aGV0aGVyDQo+ ID4gaW50ZW50aW9uYWxseSBvciBub3QpLiBJIGRvbid0IHNlZSBhbnkgYmVuZWZpdCBpbiBhbGxv d2luZyB0aGlzIGFuZA0KPiA+IHRoaW5rIGl0IHNob3VsZCBiZSBmb3JiaWRkZW4gZm9yIHNldmVy YWwgcmVhc29ucy4NCj4gPg0KPiA+IEFsbG93aW5nIHRoaXMgZW5hYmxlcyBhIHNjZW5hcmlvIHdo ZXJlIGFuIGF1dGhvcml6YXRpb24gY29kZSBtYXkgYmUNCj4gPiByZXVzZWQgd2hlbiB0aGUgY2xp ZW50IHNob3VsZCB1c2UgdGhlIHJlZnJlc2ggdG9rZW4gaW5zdGVhZC4gVGhlDQo+ID4gcmVmcmVz aCB0b2tlbiBoYXMgbW9yZSBkZXNpcmFibGUgc2VjdXJpdHkgcHJvcGVydGllcy4NCj4gPg0KPiA+ IFRoZSB1c2VmdWxuZXNzIG9mIGF1dGhvcml6YXRpb24gY29kZXMgc2hvdWxkIGJlIHJlc3RyaWN0 ZWQgd2hlcmV2ZXINCj4gPiBwb3NzaWJsZSBiZWNhdXNlIHRoZXkgYXJlIHJldmVhbGVkIHRvIHJl c291cmNlIG93bmVycyBhbmQgY2FuIGJlIHNlbnQNCj4gPiBvdmVyIHVuc2VjdXJlIGNvbm5lY3Rp b25zIHdoZW4gdGhlIGNsaWVudCBkb2VzIG5vdCByZXF1aXJlIFRMUyBvbiBpdHMNCj4gPiByZWRp cmVjdGlvbiBVUkkuIFRoZXNlIHByb3BlcnRpZXMgY29tYmluZWQgd2l0aCB0aGUgcG9zc2liaWxp dHkgdGhhdA0KPiA+IHRoZSBhdXRob3JpemF0aW9uIGNvZGUgZmxvdyBtYXkgYmUgdXNlZCBieSBw dWJsaWMgY2xpZW50cyBtaWdodCBvcGVuDQo+ID4gbW9yZSBzZXZlcmUgYXR0YWNrIHZlY3RvcnMu DQo+ID4NCj4gPiBJIHRoaW5rIGl0IHNob3VsZCBiZSBjbGVhcmx5IHN0YXRlZCB0aGF0IHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBNVVNUDQo+ID4gTk9UIGlzc3VlIG1vcmUgdGhhbiBvbmUgYWNj ZXNzIHRva2VuIHBlciBhdXRob3JpemF0aW9uIGNvZGUgZ3JhbnQuIEFuDQo+ID4gYXV0aG9yaXph dGlvbiBjb2RlIHNob3VsZCBiZSBkaXNjYXJkZWQgYWZ0ZXIgaXRzIGZpcnN0IHVzZSBhbmQgbmV3 DQo+ID4gYWNjZXNzIHRva2VucyBzaG91bGQgb25seSBiZSBpc3N1ZWQgd2hlbiBleGNoYW5nZWQg Zm9yIHJlZnJlc2ggdG9rZW5zLg0KDQpUd2Vha2VkIHRoZSBjb2RlIGRlc2NyaXB0aW9uIHNsaWdo dGx5Og0KDQogICAgICAgICAgICAgICAgUkVRVUlSRUQuIFRoZSBhdXRob3JpemF0aW9uIGNvZGUg Z2VuZXJhdGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlDQogICAgICAgICAgICAg ICAgYXV0aG9yaXphdGlvbiBjb2RlIE1VU1QgZXhwaXJlIHNob3J0bHkgYWZ0ZXIgaXQgaXMgaXNz dWVkIHRvIG1pdGlnYXRlIHRoZSByaXNrIG9mDQogICAgICAgICAgICAgICAgbGVha3MuIEEgbWF4 aW11bSBhdXRob3JpemF0aW9uIGNvZGUgbGlmZXRpbWUgb2YgMTAgbWludXRlcyBpcyBSRUNPTU1F TkRFRC4gVGhlDQogICAgICAgICAgICAgICAgY2xpZW50IE1VU1QgTk9UIHVzZSB0aGUgYXV0aG9y aXphdGlvbiBjb2RlIG1vcmUgdGhhbiBvbmNlLiBJZiBhbiBhdXRob3JpemF0aW9uIGNvZGUNCiAg ICAgICAgICAgICAgICBpcyB1c2VkIG1vcmUgdGhhbiBvbmNlLCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTVVTVCBkZW55IHRoZSByZXF1ZXN0IGFuZCBTSE9VTEQNCiAgICAgICAgICAgICAgICBh dHRlbXB0IHRvIHJldm9rZSBhbGwgdG9rZW5zIHByZXZpb3VzbHkgaXNzdWVkIGJhc2VkIG9uIHRo YXQgYXV0aG9yaXphdGlvbiBjb2RlLg0KICAgICAgICAgICAgICAgIFRoZSBhdXRob3JpemF0aW9u IGNvZGUgaXMgYm91bmQgdG8gdGhlIGNsaWVudCBpZGVudGlmaWVyIGFuZCByZWRpcmVjdGlvbiBV UkkuDQoNCj4gPiAyLiBBVVRIT1JJWkFUSU9OIENPREUgVlMuIFRPS0VOPw0KPiA+DQo+ID4gTXVj aCBsZXNzIGltcG9ydGFudCwgYW5kIHBsZWFzZSBmb3JnaXZlIG1lIGlmIHRoaXMgaGFzIGFscmVh ZHkgYmVlbg0KPiA+IGRpc2N1c3NlZCwgYnV0IHdoeSBpc24ndCB0aGUgYXV0aG9yaXphdGlvbiBj b2RlIGNhbGxlZCBhbg0KPiA+IGF1dGhvcml6YXRpb24gdG9rZW4/IEl0IGlzIHNpbWlsYXIgdG8g dGhlIHJlZnJlc2ggdG9rZW4gaW4gdGhhdCBpdCBjYW4NCj4gPiBiZSBwcmVzZW50ZWQgaW4gZXhj aGFuZ2UgZm9yIGFuIGFjY2VzcyB0b2tlbiBhdCB0aGUgdG9rZW4gZW5kcG9pbnQuIEkNCj4gPiBz ZWUgaXQgYXMgYW5vdGhlciB0eXBlIG9mIHRva2VuIGFuZCB3b25kZXIgaWYgdGhlIGxhbmd1YWdl IHVzZWQgc2hvdWxkDQo+ID4gcGVyaGFwcyByZWZsZWN0IHRoYXQgYXMgd2VsbC4NCg0KSXQncyBi YWQgZW5vdWdoIHRoZSByZWZyZXNoIHRva2VuIHVzZXMgJ3Rva2VuJy4gQWRkaW5nIGFub3RoZXIg J3Rva2VuJyB3aWxsIGJlIHRvbyBjb25mdXNpbmcuDQoNCj4gPiAzLiBHUkFNTUFSIENPUlJFQ1RJ T04gSU4gU0VDVElPTiAxMC4xMg0KPiA+DQo+ID4gSW4gU2VjdGlvbiAxMC4xMiBwYXJhZ3JhcGgg dGhyZWUgaXQgc2F5cyAiKGUuZy4gYSBoYXNoIG9mIHRoZSBzZXNzaW9uDQo+ID4gY29va2llIHVz ZWQgdG8gYXV0aGVudGljYXRpb24gdGhlIHVzZXItYWdlbnQpLiIgVGhpcyBzaG91bGQgc2F5DQo+ ID4gImF1dGhlbnRpY2F0ZSIgaW5zdGVhZCBvZiAiYXV0aGVudGljYXRpb24iLg0KDQpUaGFua3Ms DQoNCkVITA0KDQoNCg== From eran@hueniverse.com Tue Sep 20 11:41: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 2DB1C1F0C68 for ; Tue, 20 Sep 2011 11:41:34 -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 D8TAQZZPgX-K for ; Tue, 20 Sep 2011 11:41: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 8D1CA1F0C57 for ; Tue, 20 Sep 2011 11:41:33 -0700 (PDT) Received: (qmail 3801 invoked from network); 20 Sep 2011 18:43:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Sep 2011 18:43:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 20 Sep 2011 11:43:42 -0700 From: Eran Hammer-Lahav To: Paul Madsen , "oauth@ietf.org" Date: Tue, 20 Sep 2011 11:43:32 -0700 Thread-Topic: [OAUTH-WG] Typo in Sec 5.1 Thread-Index: AcxxiqwskkKIfHu3T3qmfoaNQEmoygGOoAUg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92C9D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E6E6BDF.1040009@gmail.com> In-Reply-To: <4E6E6BDF.1040009@gmail.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_90C41DD21FB7C64BB94121FBBC2E72345213D92C9DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Typo in Sec 5.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: Tue, 20 Sep 2011 18:41:34 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72345213D92C9DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks. Fixed in a few other places too. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul Madsen Sent: Monday, September 12, 2011 1:30 PM To: oauth@ietf.org Subject: [OAUTH-WG] Typo in Sec 5.1 scope OPTIONAL. The scope of the access request as described by Section 3.3. presumably this should be 'access token' paul --_000_90C41DD21FB7C64BB94121FBBC2E72345213D92C9DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Thanks. Fixed in a few other places too.

 

EHL

 

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Paul Madsen
Sent: Monday, September 12, 2011 1:30 P= M
To: oauth@ietf.org
Subject: [OAUTH-WG] Typo in Sec 5.= 1

 

scope
       =
;  OPTIONAL.  The scope of the access request as described by
         Section =
3.3.
 
presumably this s=
hould be 'access token'
 
pa=
ul
= --_000_90C41DD21FB7C64BB94121FBBC2E72345213D92C9DP3PW5EX1MB01E_-- From eran@hueniverse.com Tue Sep 20 11:46: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 7A5481F0C57 for ; Tue, 20 Sep 2011 11:46:25 -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 BuiBgsUQA3Mb for ; Tue, 20 Sep 2011 11:46: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 C66741F0C3E for ; Tue, 20 Sep 2011 11:46:24 -0700 (PDT) Received: (qmail 23907 invoked from network); 20 Sep 2011 18:47:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Sep 2011 18:47:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 20 Sep 2011 11:47:04 -0700 From: Eran Hammer-Lahav To: Niv Steingarten , OAuth WG Date: Tue, 20 Sep 2011 11:46:55 -0700 Thread-Topic: [OAUTH-WG] Typos and language in -21 Thread-Index: Acxxjx5k25dHaeFxQkS0cB5JxH/z2QGNnYlw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92CA3@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] Typos and language in -21 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, 20 Sep 2011 18:46:25 -0000 Thanks. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Niv Steingarten > Sent: Monday, September 12, 2011 2:01 PM > To: OAuth WG > Subject: [OAUTH-WG] Typos and language in -21 >=20 > In section 10.12 (CSRF): >=20 > 5th paragraph: "A CSRF attack against the against the authorization serve= r's > authorization endpoint" >=20 > One "against the" is redundant. >=20 > 4th paragraph: "The binding value enables the client to validate the vali= dity of > the request by matching the binding value to the user-agent's authenticat= ed > state." >=20 > The phrase "validate the validity of the request" sounds a bit awkwar= d in > my opinion. I'd personally go with either "establish the validity of the > request" or simply "validate the request". >=20 >=20 > -- Niv > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From trac+oauth@trac.tools.ietf.org Tue Sep 20 12:23: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 462E61F0C4C for ; Tue, 20 Sep 2011 12:23:44 -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=[AWL=-0.000, 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 KH2oEaPknTus for ; Tue, 20 Sep 2011 12:23:28 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id BC9E81F0C43 for ; Tue, 20 Sep 2011 12:23:28 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R65x3-0007Mn-CA; Tue, 20 Sep 2011 15:25:53 -0400 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: Tue, 20 Sep 2011 19:25:53 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/19#comment:1 Message-ID: <072.93123aabde121433e9db3cc4fbbc0866@trac.tools.ietf.org> References: <063.83e0a64b804112fed778d56c49a61e23@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <063.83e0a64b804112fed778d56c49a61e23@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 gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #19: Missing example from security section 10.4 Refresh Tokens 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: Tue, 20 Sep 2011 19:23:44 -0000 #19: Missing example from security section 10.4 Refresh Tokens Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Tue Sep 20 12:23: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 6EE4C1F0C75 for ; Tue, 20 Sep 2011 12:23:44 -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=[AWL=-0.000, 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 vyB-AGVQeC6k for ; Tue, 20 Sep 2011 12:23:36 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A8D141F0C36 for ; Tue, 20 Sep 2011 12:23:36 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R65xD-0008QC-7s; Tue, 20 Sep 2011 15:26:03 -0400 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: Tue, 20 Sep 2011 19:26:03 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/20#comment:1 Message-ID: <072.69e51a04a04ee351153f3d000d3c6976@trac.tools.ietf.org> References: <063.d2e3e177c42cab82db1b04c4a7864fa6@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <063.d2e3e177c42cab82db1b04c4a7864fa6@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 gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #20: Missing reference to DOM variable example in section 10.12 Cross-Site Request Forgery 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: Tue, 20 Sep 2011 19:23:44 -0000 #20: Missing reference to DOM variable example in section 10.12 Cross-Site Request Forgery Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From eran@hueniverse.com Tue Sep 20 12:33: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 8A92911E80B3 for ; Tue, 20 Sep 2011 12:33:26 -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 RqOsCIFaYfY0 for ; Tue, 20 Sep 2011 12:33:25 -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 A621011E8086 for ; Tue, 20 Sep 2011 12:33:25 -0700 (PDT) Received: (qmail 1767 invoked from network); 20 Sep 2011 19:35:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Sep 2011 19:35:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 20 Sep 2011 12:35:39 -0700 From: Eran Hammer-Lahav To: Colm Divilly , "oauth@ietf.org" Date: Tue, 20 Sep 2011 12:35:30 -0700 Thread-Topic: [OAUTH-WG] Section 4.3. Resource Owner Password Credentials: Invalid Credentials Error Handling Thread-Index: AcxyL021mf0Yy/C9RieMdxNP1ThbWwFnRhag Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92CCF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E6F7FC3.1020600@oracle.com> In-Reply-To: <4E6F7FC3.1020600@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 Subject: Re: [OAUTH-WG] Section 4.3. Resource Owner Password Credentials: Invalid Credentials Error Handling 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, 20 Sep 2011 19:33:26 -0000 'invalid_grant'. Added (e.g.) to the error code to make it more explicit. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Colm Divilly > Sent: Tuesday, September 13, 2011 9:08 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Section 4.3. Resource Owner Password Credentials: > Invalid Credentials Error Handling >=20 > Apologies if this has been covered before, a cursory search of the archiv= es > and issue tracker didn't turn up anything. >=20 > What is the expected error response when performing a Resource Owner > Password Credentials flow, if the resource owner provides incorrect > credentials? >=20 > From reading the spec it looks like the expectation is that a response l= ike the > following should be generated: >=20 > HTTP/1.1 400 Bad Request > Content-Type: application/json;charset=3DUTF-8 > Cache-Control: no-store > Pragma: no-cache >=20 > { > "error":"invalid_request" > } >=20 > Which is not terribly helpful for a user-agent trying to determine that i= t is the > user supplied credentials at fault (and therefore be able to re-prompt th= e > user for credentials). Perhaps something like the following would be more > useful: >=20 > HTTP/1.1 400 Bad Request > Content-Type: application/json;charset=3DUTF-8 > Cache-Control: no-store > Pragma: no-cache >=20 > { > "error":"invalid_resource_owner_credentials" > } >=20 > A bit verbose perhaps, any alternative suggestions? >=20 > Regards, > Colm Divilly > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From trac+oauth@trac.tools.ietf.org Tue Sep 20 13:06: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 E49761F0C88 for ; Tue, 20 Sep 2011 13:06:19 -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=[AWL=-0.000, 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 8D+ISHYFmQEd for ; Tue, 20 Sep 2011 13:06:19 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 72C351F0C84 for ; Tue, 20 Sep 2011 13:06:19 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R65yA-0002D0-Ak; Tue, 20 Sep 2011 15:27:02 -0400 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: Tue, 20 Sep 2011 19:27:02 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/25#comment:1 Message-ID: <072.d0be0659bbfacb6fbe80727beecde49d@trac.tools.ietf.org> References: <063.c133e18b72fd00182857db8e365e916c@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <063.c133e18b72fd00182857db8e365e916c@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 gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [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: Tue, 20 Sep 2011 20:06:20 -0000 #25: Clarifying reference to refresh tokens in section 1.4.3 of -20 Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Tue Sep 20 13:06: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 20A071F0C84 for ; Tue, 20 Sep 2011 13:06:20 -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=[AWL=-0.000, 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 F9alyQNBo1Yn for ; Tue, 20 Sep 2011 13:06:19 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A92981F0C85 for ; Tue, 20 Sep 2011 13:06:19 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R65xW-00013A-Df; Tue, 20 Sep 2011 15:26:22 -0400 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: Tue, 20 Sep 2011 19:26:22 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/24#comment:1 Message-ID: <072.3dea5b00820e93f1b921e57cca178c6e@trac.tools.ietf.org> References: <063.ec10a0cb7f5a7aa6d2a4806ad1847869@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <063.ec10a0cb7f5a7aa6d2a4806ad1847869@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 gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [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: Tue, 20 Sep 2011 20:06:20 -0000 #24: Resource Owner Impersonation Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From trac+oauth@trac.tools.ietf.org Tue Sep 20 13:06: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 5EEDF1F0C84 for ; Tue, 20 Sep 2011 13:06:20 -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=[AWL=-0.000, 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 kSq+MVTX8xVB for ; Tue, 20 Sep 2011 13:06:19 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D7A151F0C87 for ; Tue, 20 Sep 2011 13:06:19 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1R65xL-0000f5-Od; Tue, 20 Sep 2011 15:26:11 -0400 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: Tue, 20 Sep 2011 19:26:11 -0000 X-URL: http://tools.ietf.org/oauth/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/oauth/trac/ticket/21#comment:1 Message-ID: <072.a7eae7d96f848c52d6e2dfda2c2668eb@trac.tools.ietf.org> References: <063.a5b67cd27194276b9cd4b4569e7ec6b6@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <063.a5b67cd27194276b9cd4b4569e7ec6b6@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 gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] [oauth] #21: Need editing for 10.13 Clickjacking to better align with the protocol terminology, missing reference for x-frame-options header 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: Tue, 20 Sep 2011 20:06:20 -0000 #21: Need editing for 10.13 Clickjacking to better align with the protocol terminology, missing reference for x-frame-options header Changes (by barryleiba@…): * status: new => closed * resolution: => fixed -- -------------------------------------+-------------------------------------- Reporter: barryleiba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Deliver OAuth 2.0 spec Component: v2 | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+-------------------------------------- Ticket URL: oauth From eran@hueniverse.com Tue Sep 20 13:17: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 687A321F8C09 for ; Tue, 20 Sep 2011 13:17:54 -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 AqTCOZJ7xQp9 for ; Tue, 20 Sep 2011 13:17:53 -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 A2F1C21F8C06 for ; Tue, 20 Sep 2011 13:17:53 -0700 (PDT) Received: (qmail 16452 invoked from network); 20 Sep 2011 20:20:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Sep 2011 20:20:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 20 Sep 2011 13:19:37 -0700 From: Eran Hammer-Lahav To: "Anganes, Amanda L" , "oauth@ietf.org" Date: Tue, 20 Sep 2011 13:19:27 -0700 Thread-Topic: OAuth 2.0 v21 Nits and Typos Thread-Index: Acx23/QyH/ollQzMTvycxaih82WAowA7WQkw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92CEB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <235AEAA316C791418CE9E8FEFC77306110D6FFB801@IMCMBX3.MITRE.ORG> In-Reply-To: <235AEAA316C791418CE9E8FEFC77306110D6FFB801@IMCMBX3.MITRE.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 Subject: Re: [OAUTH-WG] OAuth 2.0 v21 Nits and Typos 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, 20 Sep 2011 20:17:54 -0000 Thanks. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Anganes, Amanda L > Sent: Monday, September 19, 2011 8:23 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] OAuth 2.0 v21 Nits and Typos >=20 > Lots of minor grammar and wording catches here. I apologize if any of the= se > were already brought up and addressed. >=20 > 1.2.3, second paragraph: "When issuing an implicit grant, the authorizati= on > server does not authenticate the client and in some cases, the client ide= ntity > can be verified..." should be "When issuing an implicit grant, the author= ization > server does not authenticate the client. In some cases, the client identi= ty can > be verified..." > > 1.5, first paragraph. Last sentence should be changed to "Issuing a refre= sh > token is optional. If an authorization server issues a refresh token, it = is > included when issuing an access token." > > 2.1, definition of public client: last sentence ends with "via any other = mean" > which should be "via any other means". > > 2.1, definition of native applications: "On the other hand, dynamically i= ssued > credentials such as access tokens or refresh tokens, can receive an > acceptable level of protection" should be "On the other hand, dynamically > issued credentials such as access tokens or refresh tokens can receive an > acceptable level of protection" (final comma is unnecessary). > > 3.1, second paragraph. Add a comma after "beyond the scope of this > specification", so it reads "The means through which the client obtains t= he > location of the authorization endpoint are beyond the scope of this > specification, but the location is typically provided in the service > documentation". > > 3.2.1, first sentence. Unnecessary comma between "requirements" and > "MUST"; should read "Confidential clients, clients issued client credenti= als, or > clients assigned other authentication requirements MUST authenticate..." > > 4.1, section (E): last sentence is missing a subject. "If valid, responds= back > with an..." should read "If valid, the authorization server responds back= with > an..." > > 4.1.2 and 4.1.2.1, also 4.2.2 and 4.2.2.1, state description: last senten= ce is > missing a MUST. Should read "REQUIRED if the state parameter was present > in the client authorization request. The state parameter MUST be set to t= he > exact value received from the client." > > 4.1.3, redirect_uri description: Change "REQUIRED, if the redirect_uri > parameter was included in the authorization request described in Section > 4.1.1, and their values MUST be identical" to "REQUIRED, if the redirect_= uri > parameter was included in the authorization request as described in Secti= on > 4.1.1. If included, the two values MUST be identical". > > 4.1.3, final paragraph ("The authorization server MUST: ..."). Is any add= itional > normative language required for lists such as this in order to specify th= at the > AS must do ALL of the items in the list? Similar MUST lists appear elsewh= ere > throughout the rest of the document. The entire list is required. > Also, final bullet should be reworded; suggest "ensure that the redirect_= uri > parameter is present if the redirect_uri parameter was included in the in= itial > authorization request as described in Section 4.1.1, and if included ensu= re > that their values are identical". >=20 > 4.2, first paragraph: clarify that implicit grants can be used only for a= ccess > tokens by including the word "only" here: "The implicit grant type is use= d to > obtain access tokens only..." That might not be accurate with extensions. > 4.3.2, paragraph after term parameter descriptions: "If the client type i= s > confidential or was issued client credentials" should be reworded to "If = the > client type is confidential or the client was issued client credentials". >=20 > 9, bullets following second paragraph: Change this to a definition list f= ormat > instead of a bulleted list. This is not definitions. > 9, final bullet following "when choosing between an external or embedded > user-agent...": Last sentence starts "Embedded user-agent educate..." but > should be "Embedded user-agents educate..." >=20 > 10.2, second paragraph: last sentence is a fragment. Reword to "For > example, the authorization server should engage the resource owner to > assist in identify the client and its origin." >=20 > 10.5, second paragraph, first sentence: extraneous comma between > "authorization server" and "is". Should be "...verify that the resource o= wner > who granted authorization at the authorization server is the same resourc= e > owner..." >=20 > 10.6, last paragraph, first sentence: extraneous comma between > "authorization code" and "is the same". Should be "... the authorization > server MUST ensure that the redirection URI used to obtain the > authorization code is the same as the redirection URI provided ..." > Last sentence should be reworded; suggest "The authorization server MUST > require public clients and SHOULD require confidential clients to registe= r their > redirection URIs. If a redirection URI is provided in the authorization r= equest, > the authorization server MUST validate the URI received against the > registered value." >=20 > 10.14, first sentence. Reads awkwardly and should be reworded; suggest "A > code injection attack occurs when an unsanitized input or otherwise exter= nal > variable is used to modify application logic." >=20 > 11.1, 11.2, 11.3, 11.4: second to last paragraph is missing "(s)" on the = end of > "Designated Expert" : "Decisions (or lack thereof) made by the Designated > Expert can be..." should be "Decisions (or lack thereof) made by the > Designated Expert(s) can be..." >=20 > 11.2, second paragraph has extraneous comma after "or the token endpoint > response" : "...the token endpoint request, or the token endpoint respons= e, > are registered" should be "...the token endpoint request, or the token > endpoint response are registered". >=20 > 11.2.1, "Parameter usage location" description should have references to = the > relevant sections of this spec, as 11.4.1 does. No similar references available. EHL From eran@hueniverse.com Tue Sep 20 15:11: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 3159021F8C55 for ; Tue, 20 Sep 2011 15:11:00 -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 1lu7fgxeWzdA for ; Tue, 20 Sep 2011 15:10:58 -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 2C4BA21F8C33 for ; Tue, 20 Sep 2011 15:10:56 -0700 (PDT) Received: (qmail 9653 invoked from network); 20 Sep 2011 22:13:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Sep 2011 22:13:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 20 Sep 2011 15:12:55 -0700 From: Eran Hammer-Lahav To: Leif Johansson , OAuth WG Date: Tue, 20 Sep 2011 15:12:45 -0700 Thread-Topic: secdir review of draft-ietf-oauth-v2 Thread-Index: AcxxejcLK5M7cRirTtqV4b97NCZawwGWSTgQAAPAPYA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92D5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E6E4FEA.7090100@sunet.se> 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] secdir review of draft-ietf-oauth-v2 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, 20 Sep 2011 22:11:00 -0000 (+OAuth WG, -everyone else) Thanks Leif. See comments inline. Whatever issues are still open will be addressed along= with the rest of the IETF LC feedback. EHL > -----Original Message----- > From: Leif Johansson [mailto:leifj@sunet.se] > Sent: Monday, September 12, 2011 11:31 AM > ** General observations: > > POST and/or GET > > Examples are sometimes POST and sometimes GET. In many cases it is not > clear to me from the surrounding text if both POST and GET are allowed > or if only one is mandated. Illustrating with both a GET _and_ POST > example in the cases where both are supported would help or make the > method explicit in the text before the example. > > The P-word > > The term 'password' is sprinkled throughout the document, sometimes as > in "client password" or "resource owner password credentials" and I > suspect that sometimes it is password as in 'an example of a > credential type' and in other cases it is password as in 'plain old > password'. This needs to be cleared up throughout (I've included some exa= mples below). > > Normative Language > > I've often found myself wanting more normative language often to > replace existing but less precise text. I've called out some important ca= ses below. > > Unknown parameters > > The sentence "The client SHOULD ignore unrecognized response > parameters" > occurs in several places. First of all I would argue that this has to > be a MUST if you want to be able to guarantee extensibility. Secondly > there are some error responses that are triggered by unsupported > request parameters. This seems like an inconsistency. > > ** Specifics > > 1.1 Roles > > Forward references to the sections where the roles are defined would > improve readability. What sections? That's the only place these roles are defined. > As an illustration of an alternative model for the authorization > server maybe an informative reference to UMA would be illustrative here. A reference to UMA would be confusing in this document. > 1.2 Protocol Flow > > (A) talks about 'an intermediary such as an authorization server.' it > isn't clear it me if this refers to a separate authorization server or > if it is the same authorization server that is referenced in (B). Changed to: (A) The client requests authorization from the resource owner= . The authorization request can be made directly to the resource owner (as shown), or pre= ferably indirectly via the authorization server as an intermediary. > 1.3.3 Resource Owner Password Credentials > > When I first read this I thought - why not talk about Resource Owner > Credentials - in fact there is a parenthesis there "(e.g a username > and password)" that seems to indicate that other credentials could be sup= ported. > > This needs to be cleared up. Either its username and password and > nothing else or there is a way to support things like Negotiate or > X.509-based credentials in which case it should really be Resource > Owner Credentials with no reference to passwords other than as as an > example of one possible credential type. Changed to: (i.e. username and password) This is explicitly just for username and password. Other types require an e= xtension. > 1.4 Access Token > > first paragraph: "The string is usually opaque". This should be > reformulated as normative language. In fact I would have liked > guidance on generating those tokens (which has been brought up on the > list) possibly as part of an implementation-guide. There is not requirement for the string to be opaque, but the general archi= tecture assumes it is. Otherwise, please suggest language. > 1.5 Refresh Token > > Why is the refresh token not simply treated as an access token for the > access token resource in the authorization server? This would seem to > simplify the model a bit by removing a type of token whose semantic > (at least to this > reviewer) is a duplication of a normal access token for a particular > type of resource. Simpler architecture but probably more confusing to many developers. > Also in the first paragraph: "(access tokens may have a shorter > lifetime and fewer permissions". Why not try to write normative > language here - there are security implications of allowing a refresh > token to get more permissions > (say) than the original access token. This was discussed before and we could not reach consensus. > 2.1 Client types > > I find the terminology public/confidential somewhat counter-intuitive. > An app you have on your personal device is 'public' while a shared > cloud service is 'confidential'...hmm... These are the best terms we could come up with. Not intuitive but well defi= ned. > This section also lacks normative language which isn't good. There > should be language defining the behavior of public and confidential > client aswell as the three profiles. > > For instance under native application we have "It is assumed that any > client authentication credentials included in the application can be > extracted". This should really be normative language. Some of what I > am looking for can be found in section 2.3 but it isn't clear to me > that it covers the definition of the profiles. Please suggest text. > 2.3.1 Client Password > > There is also some confusion here about what the client must implement > and what the server must implement wrt the use of client_id. I read > the text as trying to say that Servers SHOULD support both and clients > SHOULD only do Basic. We could not reach consensus beyond this. This language was carefully craft= ed to work around the disagreements about what is required and what is not. > This section also seems to have been the product of a partial > s/password/credential/g operation. Either OAUTH is only meant to use > Basic and passwords or we want to cover all/most HTTP authentication > methods and credentials and then section 2.3.2 (which feels like an > afterthought) needs to get folded into 2.3.1 and the normative > language (and examples!) need some work to cover at least X.509s and > perhaps even Negotiate. When we say password we mean 'plain old password'. Any other types of crede= ntials are not covered by design. > Personally I would try to fold 2.3.1 and 2.3.2 into one section and > say that servers MUST support Basic and client_id+client_password. > Servers MAY support any HTTP authentication method with a mapping to clie= nt_id. > If a client supports username+passwords it SHOULD do Basic and if it > supports other HTTP authentication methods it MUST NOT use > client_password for anything and MUST follow normal HTTP > authentication method negotiation. > > Finally, everywhere there is negotiation there must imho be some > mention/discussion/protection of downgrade attacks. Downgrade attacks security section sounds useful. Text? > 3.1 Authorization Endpoints > > 6th paragraph: "The authorization server SHOULD ignore unrecognized > request parameters". This formulation returns in several places in the > document and I don't understand why it isn't a MUST - after all > doesn't extensibility depend on this? I don't have an objection, but extensibility isn't currently required. > 3.1.1 Response Type > > The response_type parameter is REQURED but its absence SHOULD result > in an error. Why not MUST? This is an OAuth 1.0 legacy of not mandating a particular error behavior. M= UST seems like the right language - any objections? > 3.1.2 Redirection Endpoint > > There should be a clear normative specification for how to match endpoin= ts. > There are traces of this in various parts of the document when > matching is discussed. I recommend making a concise definition in one > place (namely > here) and referencing this throughout. Since this comparison has > security implications it should be a priority for the specification to be= air-tight. This has been discussed by the WG and no consensus was reached. We can reco= nsider if someone submits proposed text. > 3.1.2.2 Registration Requirements > > "(the client MAY use the state request parameter to achieve > per-request customization)". Doesn't this overload its use for CSRF-prote= ction? Yep. That's intentional. > 3.1.2.4 Invalid Endpoint > > "The authorization server SHOULD NOT redirect...". Why isn't this a > MUST NOT? I'm ok with MUST NOT - any objections? > 3.1.2.5 Endpoint Content > > This section basically seems to say "Serve with server-side code not > with html or client-side code". If this is the case then I suggest > reformulate to say precisely that using normative language. > > The use of the word "script" could perhaps also be made less ambiguous > since in this case it could refer to both server-side code aswell as > in-browser code. This is only about the HTML response sent back to the user-agent. This is a= bout including something like 'Share on Twitter/Facebook' widget on a page = with an access token in the URI fragment (which has caused tokens to leak t= o Twitter in some cases). > 3.2.1 Client Authentication > > The phrase "clients issued client credentials" could be rephrased to > make less violence on English - perhaps "clients that have been issued > with client credentials", unless that is not the intended meaning in > which case I argue for something easier to understand ;-) Ok. > The second bullet: Using client credentials more often also exposes > them more which might be worth mentioning aswell. Proposed text? > 4. Obtaining Authorization > > Perhaps not critical but the term 'password credentials' occurs in the > first paragraph and this doesn't seem compatible with resource owner > authentication being out of scope. It could just be that it should > read 'resource owner credentials' but it could also signal an > underlying assumption about username and password being used for > resource owner authentication. In either case I thing its best to > avoid the use of the word 'password' to avoid any confusion. Password is intentional. This is a special case for passwords. > 4.1 Authorization Code > > (C) - "using the redirection URI provided earlier" should perhaps read > "using the redirection URI provided earlier or associated with the > client in client registration" Changed to: Assuming the resource owner grants access, the authorization = server redirects the user-agent back to the client using the redirection URI provi= ded earlier (in the request or during client registration). The redirection URI i= ncludes an authorization code and any local state provided by the client earlier. > 4.1.1 and 4.1.2 Authorization Request/Authorization Response > > The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but > there is no mention in 4.1.2 how to handle the case when the > redirect_uri is not present. I believe the assumption is that the > redirect_uri is either resent or part of client registration but that nee= ds to be made explicit in that case. 3.1.2 describe how to handle this parameter. > This may apply to other uses of the redirect_uri parameter eg in 4.2.1. > > Furthermore in 4.2.2 "code" I suggest the following re-formulatation > of the last sentence: "The client MUST NOT use an authorization code > for more than one request. If an authorization code is re-used, the > authorization server should treat that as a replay attack and SHOULD > revoke all tokens associated with the client." (i.e loose the "attempt" > bit which carries no real meaning) Changed to server MUST not allow reuse based on previous feedback. Not sure= treating it as an attack is the right language, but the normative language= is the same either way (about revoking tokens). > Also note that this is potentially a DOS attack should a single authz cod= e leak. Explain? > 4.1.2.1 Error Response > > First paragraph, last sentence "and MUST NOT automatically redirect". > In the light of how willing users normally are to click on links > presented to them I would strengthen this to "MUST prevent the user > from following the redirect URI" Not sure what you mean. > In the definition of the invalid_request parameter I don't understand > how unsupported parameters can generate an error since endpoints > should ignore unsupported parameters (in order to support extensibility). Good catch. Dropped 'unsupported parameter' part. > 4.1.3 Access Token Request > > "require client authentication for confidential clients or for any > client issued client credentials (or with other authentication requiremen= ts)" > > This text seems unnecessarily convoluted. Isn't enough to say that if > you have issued credentials to a client you MUST require > authentication from that client? This applies equally to the other > sections where client authentication is an issue (eg 4.3.2). I felt it was important to call out confidential clients explicitly, but I = agree that if we require issuing credentials to such clients, this can be m= ade simpler. What do other think? The same end result, but different emphas= is. > Also cf my comment on 3.1.2 for the discussion of matching > redirect_uri in the last bullet: ".. and that their values are > identical". Is this really meant to mean identical? Here yes. String comparison. > 4.2 Implicit Grant > > The parenthesis "(it does not support the issuance of refresh tokens)" > sounds like it should really be normative language, "refresh tokens > MUST NOT be issues for implicit grant" because afaiu you could easily > extend "fragment-transport" to include a refresh-token, so it isn't a > technically motivated constraint, right? Instead I added this to 4.2.2: The authorization server MUST NOT issue a refresh token. > In (D) I would like to have a normative reference to a document that > specifies browser behavior for URL fragments since this is a critical > security dependency for this grant type. That's RFC2616. Seems odd to reference it here. > 4.4 Client Credentials > > I think the text should note that this model effectively implies that > the client is able to impersonate all users which has the potential > for worse security problems than if the client has access to individual u= ser passwords. Worse how? You can't use this with resource owner password. > 6 Refreshing an Access Token > > scope - The term "lesser than" is intuitive but imprecise. I suggest > "MUST NOT include any scope not originally granted by the resource owner"= . Ok. > 7.1 and 8.1 Access Token Types > > The section 7.1 lists two definitions of access token types and > provides a couple of examples but doesn't provide any constraints on > future development of access tokens except in 8.1 where it is implied > that not all access token types would be associated with HTTP > authentication mechanisms. Are there really no constraints on access > token types that should be captured? None suggested. > 10.6 Authorization Code Redirection URI Manipulation > > Suggest replace the word 'familiar' with 'trusted' in the first > sentence of the second paragraph. The notion of trust opens up several > boat loads of worm but it is the correct term here I think. Ok. > In the third paragraph "the same as" wrt redirection URIs occur and > this needs to be defined (cf comments on 3.1.2 above). Changed to identical. > Finally "The authorization server MUST require public clients and > SHOULD require confidential clients to register their redirection > URI". I am missing a discussion of why the two types of client differ wrt= this attack vector. Public clients rely on the registration to provide a minimal level of clien= t identification while confidential clients are later authenticated which c= an mitigate redirection URI manipulation. > 10.10 Credentials Guessing Attack > > I found myself wanting implementation advice for how to generate good > tokens at this point. This has been raised on the list too. The same > goes for how to generate good CSRF cookies where the "(eg a hash of > the session cookie..." feels like it is implementation advice yearning > to come out of the closet. Need someone to suggest text. EHL From eran@hueniverse.com Tue Sep 20 15:18: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 927DB21F8CCD for ; Tue, 20 Sep 2011 15:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 UKHb3fa5Tjhj for ; Tue, 20 Sep 2011 15:18: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 8302721F8CCC for ; Tue, 20 Sep 2011 15:18:12 -0700 (PDT) Received: (qmail 22732 invoked from network); 20 Sep 2011 22:20:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 20 Sep 2011 22:20:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 20 Sep 2011 15:20:31 -0700 From: Eran Hammer-Lahav To: =?iso-8859-1?Q?Andr=E9_DeMarre?= , OAuth WG Date: Tue, 20 Sep 2011 15:20:21 -0700 Thread-Topic: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 Thread-Index: AcxzPfGfSs8yqUrwQFaLTybLs42epAEpT8jA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92D60@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E6E4FEA.7090100@sunet.se> <4E6E735D.3050806@cs.tcd.ie> 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] Fwd: secdir review of draft-ietf-oauth-v2 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, 20 Sep 2011 22:18:14 -0000 If the server issues clients with password credentials it MUST support HTTP= Basic (this is the flip side of 'the client MAY use HTTP Basic') and shoul= d only support the client_secret parameter if it has clients incapable of u= sing HTTP Basic. This language has been tweaked to reach a delicate balance. I'm not incline= d to touch it. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Andr=E9 DeMarre > Sent: Wednesday, September 14, 2011 5:25 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 > > I agree that stating "Clients in possession of a client password MAY use = the > HTTP Basic authentication scheme" [Section 2.3.1 paragraph 1] implies tha= t > authorization servers MUST support HTTP basic authentication, but such is > never asserted. Instead, it says "The authorization server MAY accept any > form of client authentication meeting its security requirements." [Sectio= n 2.3 > paragraph 1] This is somewhat contradictory. > > I can understand that requiring a specific method of client authenticatio= n is > desirable for maximum interoperability, but this would be problematic for > authorization server implementations that wish to enforce stronger securi= ty > than HTTP Basic. Such implementations would be forced to deviate from the > specification. In particular, implementations which choose MAC access > tokens instead of Bearer tokens may wish to add a layer of security to > defend against improperly configured TLS connections, or to protect clien= ts > who connect to the wrong server. > [http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/] > Such implementations will also find HTTP Basic undesirable for client > authentication. To require a form of client authentication that isn't uni= versally > sufficient could become a source of criticism and deter adoption of OAuth > 2.0. > > I think the best solution is to clarify section 2.3.1 as follows: > --- > Clients in possession of client credentials MAY use any form of authentic= ation > scheme supported by the authorization server. > --- > And then follow with the existing example that demonstrates HTTP Basic. > > Regards, > Andre DeMarre > > On Tue, Sep 13, 2011 at 4:52 PM, Greg Brail wrote: > > I would like to add my support to the comments below on section 2.3, > > specifically 2.3.1. > > > > It is clear to me from reading section 2.3 that clients MAY use HTTP > > basic, or they MAY include client_id and client_secret in the request > > body -- however, the latter is not recommended. > > > > It is not clear what the authorization server MUST support. IMHO, that > > leads us to a situation in which there is no universally-agreed set of > > authentication technology that all programmers can assume is going to > > work, which means that interoperability will be difficult as some > > authorization servers will support Basic, others will support the > > request body, and others will do neither in favor of something else. > > > > I would prefer that we make both HTTP basic AND the request body > > mechanisms in this section both required on the server side, thus > > giving the client the option of choosing one or the other. That would > > mean re-writing the beginning of section 2.3.1 as shown below. > > > > If I have missed other discussion on this topic I apologize. If there > > is already consensus to make the "message body" authentication > > optional rather than required for the authorization SERVER then I > > would still recommend that we make HTTP Basic a MUST in order to allow > > easier interop. > > > > Proposed change to 2.3.1: > > > > ---- > > > > The authorization server MUST support the HTTP Basic authentication > > scheme as defined in [RFC2617] as a way to identify clients. The > > client identifier is used as the username, and the client password is > > used as the password. > > > > For example (extra line breaks are for display purposes only): > > > > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > > > Alternatively, the authorization server MUST also allow the client to > > include the client credentials in the request body using the following > > parameters: > > > > client_id > > REQUIRED. The client identifier issued to the client during > > the registration process described by Section 2.2. > > client_secret > > REQUIRED. The client secret. The client MAY omit the > > parameter if the client secret is an empty string. > > > > Clients in possession of a client password MAY use either mechanism in > > order to authenticate with the authorization server. However, > > including the client credentials in the request body using the two > > parameters is NOT RECOMMENDED, and should be limited to clients unable > > to directly utilize the HTTP Basic authentication scheme (or other > > password-based HTTP authentication schemes). > > > > (Rest of section remains as-is with the paragraph beginning "For > > example...") > > > > Gregory Brail | Technology | Apigee | +1-650-937-9302 > > > > On Mon, Sep 12, 2011 at 2:02 PM, Stephen Farrell > > wrote: > >> > >> FYI, probably best for the WG to see/process these secdir comments as > >> appropriate. I've not read 'em in detail myself yet, so as Leif says, > >> feel free to react as appropriate. > >> > >> S. > >> > >> PS: Thanks Leif for reviewing this. > >> > >> -------- Original Message -------- > >> Subject: secdir review of draft-ietf-oauth-v2 > >> Date: Mon, 12 Sep 2011 20:31:06 +0200 > >> From: Leif Johansson > >> To: draft-ietf-oauth-v2@tools.ietf.org, secdir@ietf.org, > >> iesg@ietf.org > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> > >> Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 > >> > >> Do not be alarmed. I have reviewed this document as part of the > >> security directorate's ongoing effort to review all IETF documents > >> being processed by the IESG. These comments were written primarily > >> for the benefit of the security area directors. Document editors and > >> WG chairs should treat these comments just like any other last call > >> comments. > >> > >> This review is rather lengthy. This should not be interpreted as > >> anything beyond a desire to do a thorough review. > >> > >> It may well be that I have stumbled on things already covered on the > >> list. If so I apologize and ask that you silently ignore such bits. > >> Also I have included things that are not directly security related > >> but that I found problematic for other reasons. > >> > >> The notes are presented in the order I wrote them down. > >> > >> ** General observations: > >> > >> POST and/or GET > >> > >> Examples are sometimes POST and sometimes GET. In many cases it is > >> not clear to me from the surrounding text if both POST and GET are > >> allowed or if only one is mandated. Illustrating with both a GET > >> _and_ POST example in the cases where both are supported would help > >> or make the method explicit in the text before the example. > >> > >> The P-word > >> > >> The term 'password' is sprinkled throughout the document, sometimes > >> as in "client password" or "resource owner password credentials" and > >> I suspect that sometimes it is password as in 'an example of a > >> credential type' and in other cases it is password as in 'plain old > >> password'. This needs to be cleared up throughout (I've included some > >> examples below). > >> > >> Normative Language > >> > >> I've often found myself wanting more normative language often to > >> replace existing but less precise text. I've called out some > >> important cases below. > >> > >> Unknown parameters > >> > >> The sentence "The client SHOULD ignore unrecognized response > parameters" > >> occurs in several places. First of all I would argue that this has to > >> be a MUST if you want to be able to guarantee extensibility. Secondly > >> there are some error responses that are triggered by unsupported > >> request parameters. This seems like an inconsistency. > >> > >> ** Specifics > >> > >> 1.1 Roles > >> > >> Forward references to the sections where the roles are defined would > >> improve readability. > >> > >> As an illustration of an alternative model for the authorization > >> server maybe an informative reference to UMA would be illustrative > here. > >> > >> 1.2 Protocol Flow > >> > >> (A) talks about 'an intermediary such as an authorization server.' it > >> isn't clear it me if this refers to a separate authorization server > >> or if it is the same authorization server that is referenced in (B). > >> > >> 1.3.3 Resource Owner Password Credentials > >> > >> When I first read this I thought - why not talk about Resource Owner > >> Credentials - in fact there is a parenthesis there "(e.g a username > >> and password)" that seems to indicate that other credentials could be > >> supported. > >> > >> This needs to be cleared up. Either its username and password and > >> nothing else or there is a way to support things like Negotiate or > >> X.509-based credentials in which case it should really be Resource > >> Owner Credentials with no reference to passwords other than as as an > >> example of one possible credential type. > >> > >> 1.4 Access Token > >> > >> first paragraph: "The string is usually opaque". This should be > >> reformulated as normative language. In fact I would have liked > >> guidance on generating those tokens (which has been brought up on the > >> list) possibly as part of an implementation-guide. > >> > >> 1.5 Refresh Token > >> > >> Why is the refresh token not simply treated as an access token for > >> the access token resource in the authorization server? This would > >> seem to simplify the model a bit by removing a type of token whose > >> semantic (at least to this reviewer) is a duplication of a normal > >> access token for a particular type of resource. > >> > >> Also in the first paragraph: "(access tokens may have a shorter > >> lifetime and fewer permissions". Why not try to write normative > >> language here - there are security implications of allowing a refresh > >> token to get more permissions (say) than the original access token. > >> > >> 2.1 Client types > >> > >> I find the terminology public/confidential somewhat counter-intuitive. > >> An app you have on your personal device is 'public' while a shared > >> cloud service is 'confidential'...hmm... > >> > >> This section also lacks normative language which isn't good. There > >> should be language defining the behavior of public and confidential > >> client aswell as the three profiles. > >> > >> For instance under native application we have "It is assumed that any > >> client authentication credentials included in the application can be > >> extracted". This should really be normative language. Some of what I > >> am looking for can be found in section 2.3 but it isn't clear to me > >> that it covers the definition of the profiles. > >> > >> 2.3.1 Client Password > >> > >> There is also some confusion here about what the client must > >> implement and what the server must implement wrt the use of > >> client_id. I read the text as trying to say that Servers SHOULD > >> support both and clients SHOULD only do Basic. > >> > >> This section also seems to have been the product of a partial > >> s/password/credential/g operation. Either OAUTH is only meant to use > >> Basic and passwords or we want to cover all/most HTTP authentication > >> methods and credentials and then section 2.3.2 (which feels like an > >> afterthought) needs to get folded into 2.3.1 and the normative > >> language (and examples!) need some work to cover at least X.509s and > >> perhaps even Negotiate. > >> > >> Personally I would try to fold 2.3.1 and 2.3.2 into one section and > >> say that servers MUST support Basic and client_id+client_password. > >> Servers MAY support any HTTP authentication method with a mapping to > client_id. > >> If a client supports username+passwords it SHOULD do Basic and if it > >> supports other HTTP authentication methods it MUST NOT use > >> client_password for anything and MUST follow normal HTTP > >> authentication method negotiation. > >> > >> Finally, everywhere there is negotiation there must imho be some > >> mention/discussion/protection of downgrade attacks. > >> > >> 3.1 Authorization Endpoints > >> > >> 6th paragraph: "The authorization server SHOULD ignore unrecognized > >> request parameters". This formulation returns in several places in > >> the document and I don't understand why it isn't a MUST - after all > >> doesn't extensibility depend on this? > >> > >> 3.1.1 Response Type > >> > >> The response_type parameter is REQURED but its absence SHOULD result > >> in an error. Why not MUST? > >> > >> 3.1.2 Redirection Endpoint > >> > >> There should be a clear normative specification for how to match > >> endpoints. There are traces of this in various parts of the document > >> when matching is discussed. I recommend making a concise definition > >> in one place (namely here) and referencing this throughout. Since > >> this comparison has security implications it should be a priority for > >> the specification to be air-tight. > >> > >> 3.1.2.2 Registration Requirements > >> > >> "(the client MAY use the state request parameter to achieve > >> per-request customization)". Doesn't this overload its use for CSRF- > protection? > >> > >> 3.1.2.4 Invalid Endpoint > >> > >> "The authorization server SHOULD NOT redirect...". Why isn't this a > >> MUST NOT? > >> > >> 3.1.2.5 Endpoint Content > >> > >> This section basically seems to say "Serve with server-side code not > >> with html or client-side code". If this is the case then I suggest > >> reformulate to say precisely that using normative language. > >> > >> The use of the word "script" could perhaps also be made less > >> ambiguous since in this case it could refer to both server-side code > >> aswell as in-browser code. > >> > >> 3.2.1 Client Authentication > >> > >> The phrase "clients issued client credentials" could be rephrased to > >> make less violence on English - perhaps "clients that have been > >> issued with client credentials", unless that is not the intended > >> meaning in which case I argue for something easier to understand ;-) > >> > >> The second bullet: Using client credentials more often also exposes > >> them more which might be worth mentioning aswell. > >> > >> 4. Obtaining Authorization > >> > >> Perhaps not critical but the term 'password credentials' occurs in > >> the first paragraph and this doesn't seem compatible with resource > >> owner authentication being out of scope. It could just be that it > >> should read 'resource owner credentials' but it could also signal an > >> underlying assumption about username and password being used for > >> resource owner authentication. In either case I thing its best to > >> avoid the use of the word 'password' to avoid any confusion. > >> > >> 4.1 Authorization Code > >> > >> (C) - "using the redirection URI provided earlier" should perhaps > >> read "using the redirection URI provided earlier or associated with > >> the client in client registration" > >> > >> > >> 4.1.1 and 4.1.2 Authorization Request/Authorization Response > >> > >> The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but > >> there is no mention in 4.1.2 how to handle the case when the > >> redirect_uri is not present. I believe the assumption is that the > >> redirect_uri is either resent or part of client registration but that > >> needs to be made explicit in that case. > >> > >> This may apply to other uses of the redirect_uri parameter eg in 4.2.1= . > >> > >> Furthermore in 4.2.2 "code" I suggest the following re-formulatation > >> of the last sentence: "The client MUST NOT use an authorization code > >> for more than one request. If an authorization code is re-used, the > >> authorization server should treat that as a replay attack and SHOULD > >> revoke all tokens associated with the client." (i.e loose the "attempt= " > >> bit which carries no real meaning) > >> > >> Also note that this is potentially a DOS attack should a single authz > >> code leak. > >> > >> 4.1.2.1 Error Response > >> > >> First paragraph, last sentence "and MUST NOT automatically redirect". > >> In the light of how willing users normally are to click on links > >> presented to them I would strengthen this to "MUST prevent the user > >> from following the redirect URI" > >> > >> In the definition of the invalid_request parameter I don't understand > >> how unsupported parameters can generate an error since endpoints > >> should ignore unsupported parameters (in order to support extensibilit= y). > >> > >> 4.1.3 Access Token Request > >> > >> "require client authentication for confidential clients or for any > >> client issued client credentials (or with other authentication > >> requirements)" > >> > >> This text seems unnecessarily convoluted. Isn't enough to say that if > >> you have issued credentials to a client you MUST require > >> authentication from that client? This applies equally to the other > >> sections where client authentication is an issue (eg 4.3.2). > >> > >> Also cf my comment on 3.1.2 for the discussion of matching > >> redirect_uri in the last bullet: ".. and that their values are > >> identical". Is this really meant to mean identical? > >> > >> 4.2 Implicit Grant > >> > >> The parenthesis "(it does not support the issuance of refresh tokens)" > >> sounds like it should really be normative language, "refresh tokens > >> MUST NOT be issues for implicit grant" because afaiu you could easily > >> extend "fragment-transport" to include a refresh-token, so it isn't a > >> technically motivated constraint, right? > >> > >> In (D) I would like to have a normative reference to a document that > >> specifies browser behavior for URL fragments since this is a critical > >> security dependency for this grant type. > >> > >> 4.4 Client Credentials > >> > >> I think the text should note that this model effectively implies that > >> the client is able to impersonate all users which has the potential > >> for worse security problems than if the client has access to > >> individual user passwords. > >> > >> 6 Refreshing an Access Token > >> > >> scope - The term "lesser than" is intuitive but imprecise. I suggest > >> "MUST NOT include any scope not originally granted by the resource > owner". > >> > >> 7.1 and 8.1 Access Token Types > >> > >> The section 7.1 lists two definitions of access token types and > >> provides a couple of examples but doesn't provide any constraints on > >> future development of access tokens except in 8.1 where it is implied > >> that not all access token types would be associated with HTTP > >> authentication mechanisms. Are there really no constraints on access > >> token types that should be captured? > >> > >> 10.6 Authorization Code Redirection URI Manipulation > >> > >> Suggest replace the word 'familiar' with 'trusted' in the first > >> sentence of the second paragraph. The notion of trust opens up > >> several boat loads of worm but it is the correct term here I think. > >> > >> In the third paragraph "the same as" wrt redirection URIs occur and > >> this needs to be defined (cf comments on 3.1.2 above). > >> > >> Finally "The authorization server MUST require public clients and > >> SHOULD require confidential clients to register their redirection > >> URI". I am missing a discussion of why the two types of client differ > >> wrt this attack vector. > >> > >> 10.10 Credentials Guessing Attack > >> > >> I found myself wanting implementation advice for how to generate good > >> tokens at this point. This has been raised on the list too. The same > >> goes for how to generate good CSRF cookies where the "(eg a hash of > >> the session cookie..." feels like it is implementation advice > >> yearning to come out of the closet. > >> > >> > >> Thats it. > >> > >> Cheers Leif > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.11 (GNU/Linux) > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> > >> > iEYEARECAAYFAk5uT+YACgkQ8Jx8FtbMZncXQgCfZmTlzuESq0plfpkceQN1ont > E > >> a1QAoIEcg06GYK+6Fn4y40cTL1jQ+KmS > >> =3Dox42 > >> -----END PGP SIGNATURE----- > >> > >> _______________________________________________ > >> 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 andredemarre@gmail.com Tue Sep 20 19:09: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 65D1321F8997 for ; Tue, 20 Sep 2011 19:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 W7hUuGG1Z4xy for ; Tue, 20 Sep 2011 19:09:19 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB2721F86FF for ; Tue, 20 Sep 2011 19:09:19 -0700 (PDT) Received: by iaby26 with SMTP id y26so1477848iab.31 for ; Tue, 20 Sep 2011 19:11:46 -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 :content-type:content-transfer-encoding; bh=6ghL+s3ZQ6GfbByvj0gi7rs27eOfbxN/Nu+mP1/JoVQ=; b=QvuHqrJZG4WSO6A5CPxkMa0hu0OsL0TpraqdVHLneydBv2+wVT+W7XkF6C+DEBHRna cgZ36Ux/pPOjcCwQcPaSSNO/GwS66qKf6RD1jYvkpuT7uHqaLmhlG+FSBruUC3O83ykD teiY1qxwg2WcFLHCrY5bPxA1eXGH5kxhSei84= MIME-Version: 1.0 Received: by 10.231.29.141 with SMTP id q13mr203491ibc.58.1316571106258; Tue, 20 Sep 2011 19:11:46 -0700 (PDT) Received: by 10.42.18.129 with HTTP; Tue, 20 Sep 2011 19:11:46 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345213D92D60@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E6E4FEA.7090100@sunet.se> <4E6E735D.3050806@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72345213D92D60@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 20 Sep 2011 19:11:46 -0700 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: Eran Hammer-Lahav , OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 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, 21 Sep 2011 02:09:24 -0000 X-List-Received-Date: Wed, 21 Sep 2011 02:09:24 -0000 > If the server issues clients with password credentials it MUST support HT= TP Basic (this is the flip side of 'the client MAY use HTTP Basic') and sho= uld only support the client_secret parameter if it has clients incapable of= using HTTP Basic. Very well. Without changing the meaning, I think the community would be well served by appending paragraph 2 of Section 2.3 as follows: ---- Confidential clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g. password, public/private key pair). If clients are issued passwords, the authorization server MUST support the HTTP Basic authentication scheme as defined in [RFC2617] and described by Section 2.3.1. ---- This helps to communicate that authorization servers are only required to support HTTP Basic if they issue client passwords. Andre On Tue, Sep 20, 2011 at 3:20 PM, Eran Hammer-Lahav wr= ote: > If the server issues clients with password credentials it MUST support HT= TP Basic (this is the flip side of 'the client MAY use HTTP Basic') and sho= uld only support the client_secret parameter if it has clients incapable of= using HTTP Basic. > > This language has been tweaked to reach a delicate balance. I'm not incli= ned to touch it. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Andr=E9 DeMarre >> Sent: Wednesday, September 14, 2011 5:25 PM >> To: OAuth WG >> Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 >> >> I agree that stating "Clients in possession of a client password MAY use= the >> HTTP Basic authentication scheme" [Section 2.3.1 paragraph 1] implies th= at >> authorization servers MUST support HTTP basic authentication, but such i= s >> never asserted. Instead, it says "The authorization server MAY accept an= y >> form of client authentication meeting its security requirements." [Secti= on 2.3 >> paragraph 1] This is somewhat contradictory. >> >> I can understand that requiring a specific method of client authenticati= on is >> desirable for maximum interoperability, but this would be problematic fo= r >> authorization server implementations that wish to enforce stronger secur= ity >> than HTTP Basic. Such implementations would be forced to deviate from th= e >> specification. In particular, implementations which choose MAC access >> tokens instead of Bearer tokens may wish to add a layer of security to >> defend against improperly configured TLS connections, or to protect clie= nts >> who connect to the wrong server. >> [http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/] >> Such implementations will also find HTTP Basic undesirable for client >> authentication. To require a form of client authentication that isn't un= iversally >> sufficient could become a source of criticism and deter adoption of OAut= h >> 2.0. >> >> I think the best solution is to clarify section 2.3.1 as follows: >> --- >> Clients in possession of client credentials MAY use any form of authenti= cation >> scheme supported by the authorization server. >> --- >> And then follow with the existing example that demonstrates HTTP Basic. >> >> Regards, >> Andre DeMarre >> >> On Tue, Sep 13, 2011 at 4:52 PM, Greg Brail wrote: >> > I would like to add my support to the comments below on section 2.3, >> > specifically 2.3.1. >> > >> > It is clear to me from reading section 2.3 that clients MAY use HTTP >> > basic, or they MAY include client_id and client_secret in the request >> > body -- however, the latter is not recommended. >> > >> > It is not clear what the authorization server MUST support. IMHO, that >> > leads us to a situation in which there is no universally-agreed set of >> > authentication technology that all programmers can assume is going to >> > work, which means that interoperability will be difficult as some >> > authorization servers will support Basic, others will support the >> > request body, and others will do neither in favor of something else. >> > >> > I would prefer that we make both HTTP basic AND the request body >> > mechanisms in this section both required on the server side, thus >> > giving the client the option of choosing one or the other. That would >> > mean re-writing the beginning of section 2.3.1 as shown below. >> > >> > If I have missed other discussion on this topic I apologize. If there >> > is already consensus to make the "message body" authentication >> > optional rather than required for the authorization SERVER then I >> > would still recommend that we make HTTP Basic a MUST in order to allow >> > easier interop. >> > >> > Proposed change to 2.3.1: >> > >> > ---- >> > >> > The authorization server MUST support the HTTP Basic authentication >> > scheme as defined in [RFC2617] as a way to identify clients. The >> > client identifier is used as the username, and the client password is >> > used as the password. >> > >> > For example (extra line breaks are for display purposes only): >> > >> > =A0 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW >> > >> > Alternatively, the authorization server MUST also allow the client to >> > include the client credentials in the request body using the following >> > parameters: >> > >> > =A0 client_id >> > =A0 =A0 =A0 =A0 REQUIRED. =A0The client identifier issued to the clien= t during >> > =A0 =A0 =A0 =A0 the registration process described by Section 2.2. >> > =A0 client_secret >> > =A0 =A0 =A0 =A0 REQUIRED. =A0The client secret. =A0The client MAY omit= the >> > =A0 =A0 =A0 =A0 parameter if the client secret is an empty string. >> > >> > Clients in possession of a client password MAY use either mechanism in >> > order to authenticate with the authorization server. However, >> > including the client credentials in the request body using the two >> > parameters is NOT RECOMMENDED, and should be limited to clients unable >> > to directly utilize the HTTP Basic authentication scheme (or other >> > password-based HTTP authentication schemes). >> > >> > =A0(Rest of section remains as-is with the paragraph beginning "For >> > example...") >> > >> > Gregory Brail =A0 | =A0 Technology =A0 | =A0 Apigee =A0 | =A0 +1-650-9= 37-9302 >> > >> > On Mon, Sep 12, 2011 at 2:02 PM, Stephen Farrell >> > wrote: >> >> >> >> FYI, probably best for the WG to see/process these secdir comments as >> >> appropriate. I've not read 'em in detail myself yet, so as Leif says, >> >> feel free to react as appropriate. >> >> >> >> S. >> >> >> >> PS: Thanks Leif for reviewing this. >> >> >> >> -------- Original Message -------- >> >> Subject: secdir review of draft-ietf-oauth-v2 >> >> Date: Mon, 12 Sep 2011 20:31:06 +0200 >> >> From: Leif Johansson >> >> To: draft-ietf-oauth-v2@tools.ietf.org, secdir@ietf.org, >> >> iesg@ietf.org >> >> >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA1 >> >> >> >> >> >> Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 >> >> >> >> Do not be alarmed. =A0I have reviewed this document as part of the >> >> security directorate's ongoing effort to review all IETF documents >> >> being processed by the IESG. =A0These comments were written primarily >> >> for the benefit of the security area directors. =A0Document editors a= nd >> >> WG chairs should treat these comments just like any other last call >> >> comments. >> >> >> >> This review is rather lengthy. This should not be interpreted as >> >> anything beyond a desire to do a thorough review. >> >> >> >> It may well be that I have stumbled on things already covered on the >> >> list. If so I apologize and ask that you silently ignore such bits. >> >> Also I have included things that are not directly security related >> >> but that I found problematic for other reasons. >> >> >> >> The notes are presented in the order I wrote them down. >> >> >> >> ** General observations: >> >> >> >> POST and/or GET >> >> >> >> Examples are sometimes POST and sometimes GET. In many cases it is >> >> not clear to me from the surrounding text if both POST and GET are >> >> allowed or if only one is mandated. Illustrating with both a GET >> >> _and_ POST example in the cases where both are supported would help >> >> or make the method explicit in the text before the example. >> >> >> >> The P-word >> >> >> >> The term 'password' is sprinkled throughout the document, sometimes >> >> as in "client password" or "resource owner password credentials" and >> >> I suspect that sometimes it is password as in 'an example of a >> >> credential type' and in other cases it is password as in 'plain old >> >> password'. This needs to be cleared up throughout (I've included some >> >> examples below). >> >> >> >> Normative Language >> >> >> >> I've often found myself wanting more normative language often to >> >> replace existing but less precise text. I've called out some >> >> important cases below. >> >> >> >> Unknown parameters >> >> >> >> The sentence "The client SHOULD ignore unrecognized response >> parameters" >> >> occurs in several places. First of all I would argue that this has to >> >> be a MUST if you want to be able to guarantee extensibility. Secondly >> >> there are some error responses that are triggered by unsupported >> >> request parameters. This seems like an inconsistency. >> >> >> >> ** Specifics >> >> >> >> 1.1 Roles >> >> >> >> Forward references to the sections where the roles are defined would >> >> improve readability. >> >> >> >> As an illustration of an alternative model for the authorization >> >> server maybe an informative reference to UMA would be illustrative >> here. >> >> >> >> 1.2 Protocol Flow >> >> >> >> (A) talks about 'an intermediary such as an authorization server.' it >> >> isn't clear it me if this refers to a separate authorization server >> >> or if it is the same authorization server that is referenced in (B). >> >> >> >> 1.3.3 Resource Owner Password Credentials >> >> >> >> When I first read this I thought - why not talk about Resource Owner >> >> Credentials - in fact there is a parenthesis there "(e.g a username >> >> and password)" that seems to indicate that other credentials could be >> >> supported. >> >> >> >> This needs to be cleared up. Either its username and password and >> >> nothing else or there is a way to support things like Negotiate or >> >> X.509-based credentials in which case it should really be Resource >> >> Owner Credentials with no reference to passwords other than as as an >> >> example of one possible credential type. >> >> >> >> 1.4 Access Token >> >> >> >> first paragraph: "The string is usually opaque". This should be >> >> reformulated as normative language. In fact I would have liked >> >> guidance on generating those tokens (which has been brought up on the >> >> list) possibly as part of an implementation-guide. >> >> >> >> 1.5 Refresh Token >> >> >> >> Why is the refresh token not simply treated as an access token for >> >> the access token resource in the authorization server? This would >> >> seem to simplify the model a bit by removing a type of token whose >> >> semantic (at least to this reviewer) is a duplication of a normal >> >> access token for a particular type of resource. >> >> >> >> Also in the first paragraph: "(access tokens may have a shorter >> >> lifetime and fewer permissions". Why not try to write normative >> >> language here - there are security implications of allowing a refresh >> >> token to get more permissions (say) than the original access token. >> >> >> >> 2.1 Client types >> >> >> >> I find the terminology public/confidential somewhat counter-intuitive= . >> >> An app you have on your personal device is 'public' while a shared >> >> cloud service is 'confidential'...hmm... >> >> >> >> This section also lacks normative language which isn't good. There >> >> should be language defining the behavior of public and confidential >> >> client aswell as the three profiles. >> >> >> >> For instance under native application we have "It is assumed that any >> >> client authentication credentials included in the application can be >> >> extracted". This should really be normative language. Some of what I >> >> am looking for can be found in section 2.3 but it isn't clear to me >> >> that it covers the definition of the profiles. >> >> >> >> 2.3.1 Client Password >> >> >> >> There is also some confusion here about what the client must >> >> implement and what the server must implement wrt the use of >> >> client_id. I read the text as trying to say that Servers SHOULD >> >> support both and clients SHOULD only do Basic. >> >> >> >> This section also seems to have been the product of a partial >> >> s/password/credential/g operation. Either OAUTH is only meant to use >> >> Basic and passwords or we want to cover all/most HTTP authentication >> >> methods and credentials and then section 2.3.2 (which feels like an >> >> afterthought) needs to get folded into 2.3.1 and the normative >> >> language (and examples!) need some work to cover at least X.509s and >> >> perhaps even Negotiate. >> >> >> >> Personally I would try to fold 2.3.1 and 2.3.2 into one section and >> >> say that servers MUST support Basic and client_id+client_password. >> >> Servers MAY support any HTTP authentication method with a mapping to >> client_id. >> >> If a client supports username+passwords it SHOULD do Basic and if it >> >> supports other HTTP authentication methods it MUST NOT use >> >> client_password for anything and MUST follow normal HTTP >> >> authentication method negotiation. >> >> >> >> Finally, everywhere there is negotiation there must imho be some >> >> mention/discussion/protection of downgrade attacks. >> >> >> >> 3.1 Authorization Endpoints >> >> >> >> 6th paragraph: "The authorization server SHOULD ignore unrecognized >> >> request parameters". This formulation returns in several places in >> >> the document and I don't understand why it isn't a MUST - after all >> >> doesn't extensibility depend on this? >> >> >> >> 3.1.1 Response Type >> >> >> >> The response_type parameter is REQURED but its absence SHOULD result >> >> in an error. Why not MUST? >> >> >> >> 3.1.2 Redirection Endpoint >> >> >> >> There should be a clear normative specification for how to =A0match >> >> endpoints. There are traces of this in various parts of the document >> >> when matching is discussed. I recommend making a concise definition >> >> in one place (namely here) and referencing this throughout. Since >> >> this comparison has security implications it should be a priority for >> >> the specification to be air-tight. >> >> >> >> 3.1.2.2 Registration Requirements >> >> >> >> "(the client MAY use the state request parameter to achieve >> >> per-request customization)". Doesn't this overload its use for CSRF- >> protection? >> >> >> >> 3.1.2.4 Invalid Endpoint >> >> >> >> "The authorization server SHOULD NOT redirect...". Why isn't this a >> >> MUST NOT? >> >> >> >> 3.1.2.5 Endpoint Content >> >> >> >> This section basically seems to say "Serve with server-side code not >> >> with html or client-side code". If this is the case then I suggest >> >> reformulate to say precisely that using normative language. >> >> >> >> The use of the word "script" could perhaps also be made less >> >> ambiguous since in this case it could refer to both server-side code >> >> aswell as in-browser code. >> >> >> >> 3.2.1 Client Authentication >> >> >> >> The phrase "clients issued client credentials" could be rephrased to >> >> make less violence on English - perhaps "clients that have been >> >> issued with client credentials", unless that is not the intended >> >> meaning in which case I argue for something easier to understand ;-) >> >> >> >> The second bullet: Using client credentials more often also exposes >> >> them more which might be worth mentioning aswell. >> >> >> >> 4. Obtaining Authorization >> >> >> >> Perhaps not critical but the term 'password credentials' occurs in >> >> the first paragraph and this doesn't seem compatible with resource >> >> owner authentication being out of scope. It could just be that it >> >> should read 'resource owner credentials' but it could also signal an >> >> underlying assumption about username and password being used for >> >> resource owner authentication. In either case I thing its best to >> >> avoid the use of the word 'password' to avoid any confusion. >> >> >> >> 4.1 Authorization Code >> >> >> >> (C) - "using the redirection URI provided earlier" should perhaps >> >> read "using the redirection URI provided earlier or associated with >> >> the client in client registration" >> >> >> >> >> >> 4.1.1 and 4.1.2 Authorization Request/Authorization Response >> >> >> >> The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but >> >> there is no mention in 4.1.2 how to handle the case when the >> >> redirect_uri is not present. I believe the assumption is that the >> >> redirect_uri is either resent or part of client registration but that >> >> needs to be made explicit in that case. >> >> >> >> This may apply to other uses of the redirect_uri parameter eg in 4.2.= 1. >> >> >> >> Furthermore in 4.2.2 "code" I suggest the following re-formulatation >> >> of the last sentence: "The client MUST NOT use an authorization code >> >> for more than one request. If an authorization code is re-used, the >> >> authorization server should treat that as a replay attack and SHOULD >> >> revoke all tokens associated with the client." (i.e loose the "attemp= t" >> >> bit which carries no real meaning) >> >> >> >> Also note that this is potentially a DOS attack should a single authz >> >> code leak. >> >> >> >> 4.1.2.1 Error Response >> >> >> >> First paragraph, last sentence "and MUST NOT automatically redirect". >> >> In the light of how willing users normally are to click on links >> >> presented to them I would strengthen this to "MUST prevent the user >> >> from following the redirect URI" >> >> >> >> In the definition of the invalid_request parameter I don't understand >> >> how unsupported parameters can generate an error since endpoints >> >> should ignore unsupported parameters (in order to support extensibili= ty). >> >> >> >> 4.1.3 Access Token Request >> >> >> >> "require client authentication for confidential clients or for any >> >> client issued client credentials (or with other authentication >> >> requirements)" >> >> >> >> This text seems unnecessarily convoluted. Isn't enough to say that if >> >> you have issued credentials to a client you MUST require >> >> authentication from that client? This applies equally to the other >> >> sections where client authentication is an issue (eg 4.3.2). >> >> >> >> Also cf my comment on 3.1.2 for the discussion of matching >> >> redirect_uri in the last bullet: ".. and that their values are >> >> identical". Is this really meant to mean identical? >> >> >> >> 4.2 Implicit Grant >> >> >> >> The parenthesis "(it does not support the issuance of refresh tokens)= " >> >> sounds like it should really be normative language, "refresh tokens >> >> MUST NOT be issues for implicit grant" because afaiu you could easily >> >> extend "fragment-transport" to include a refresh-token, so it isn't a >> >> technically motivated constraint, right? >> >> >> >> In (D) I would like to have a normative reference to a document that >> >> specifies browser behavior for URL fragments since this is a critical >> >> security dependency for this grant type. >> >> >> >> 4.4 Client Credentials >> >> >> >> I think the text should note that this model effectively implies that >> >> the client is able to impersonate all users which has the potential >> >> for worse security problems than if the client has access to >> >> individual user passwords. >> >> >> >> 6 Refreshing an Access Token >> >> >> >> scope - The term "lesser than" is intuitive but imprecise. I suggest >> >> "MUST NOT include any scope not originally granted by the resource >> owner". >> >> >> >> 7.1 and 8.1 Access Token Types >> >> >> >> The section 7.1 lists two definitions of access token types and >> >> provides a couple of examples but doesn't provide any constraints on >> >> future development of access tokens except in 8.1 where it is implied >> >> that not all access token types would be associated with HTTP >> >> authentication mechanisms. Are there really no constraints on access >> >> token types that should be captured? >> >> >> >> 10.6 Authorization Code Redirection URI Manipulation >> >> >> >> Suggest replace the word 'familiar' with 'trusted' in the first >> >> sentence of the second paragraph. The notion of trust opens up >> >> several boat loads of worm but it is the correct term here I think. >> >> >> >> In the third paragraph "the same as" wrt redirection URIs occur and >> >> this needs to be defined (cf comments on 3.1.2 above). >> >> >> >> Finally "The authorization server MUST require public clients and >> >> SHOULD require confidential clients to register their redirection >> >> URI". I am missing a discussion of why the two types of client differ >> >> wrt this attack vector. >> >> >> >> 10.10 Credentials Guessing Attack >> >> >> >> I found myself wanting implementation advice for how to generate good >> >> tokens at this point. This has been raised on the list too. The same >> >> goes for how to generate good CSRF cookies where the "(eg a hash of >> >> the session cookie..." feels like it is implementation advice >> >> yearning to come out of the closet. >> >> >> >> >> >> Thats it. >> >> >> >> =A0 =A0 =A0 =A0Cheers Leif >> >> -----BEGIN PGP SIGNATURE----- >> >> Version: GnuPG v1.4.11 (GNU/Linux) >> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> >> >> >> iEYEARECAAYFAk5uT+YACgkQ8Jx8FtbMZncXQgCfZmTlzuESq0plfpkceQN1ont >> E >> >> a1QAoIEcg06GYK+6Fn4y40cTL1jQ+KmS >> >> =3Dox42 >> >> -----END PGP SIGNATURE----- >> >> >> >> _______________________________________________ >> >> 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 Sep 20 20:50: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 69BD45E8001 for ; Tue, 20 Sep 2011 20:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 oPi+95qgZUwV for ; Tue, 20 Sep 2011 20:50:15 -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 9B4F41F0C36 for ; Tue, 20 Sep 2011 20:50:15 -0700 (PDT) Received: (qmail 7647 invoked from network); 21 Sep 2011 03:52:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Sep 2011 03:52:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Tue, 20 Sep 2011 20:52:41 -0700 From: Eran Hammer-Lahav To: =?iso-8859-1?Q?Andr=E9_DeMarre?= , OAuth WG Date: Tue, 20 Sep 2011 20:52:31 -0700 Thread-Topic: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 Thread-Index: Acx4A9ErG1XoqpU8S1iuvVokuiykZQADgQaA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92DE2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E6E4FEA.7090100@sunet.se> <4E6E735D.3050806@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72345213D92D60@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 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, 21 Sep 2011 03:50:17 -0000 This will go into the IETF LC feedback loop. EHL > -----Original Message----- > From: Andr=E9 DeMarre [mailto:andredemarre@gmail.com] > Sent: Tuesday, September 20, 2011 7:12 PM > To: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 > > > If the server issues clients with password credentials it MUST support = HTTP > Basic (this is the flip side of 'the client MAY use HTTP Basic') and shou= ld only > support the client_secret parameter if it has clients incapable of using = HTTP > Basic. > > Very well. Without changing the meaning, I think the community would be > well served by appending paragraph 2 of Section 2.3 as follows: > ---- > Confidential clients are typically issued (or establish) a set of > client credentials used for authenticating with the authorization > server (e.g. password, public/private key pair). If clients are > issued passwords, the authorization server MUST support the HTTP > Basic authentication scheme as defined in [RFC2617] and described > by Section 2.3.1. > ---- > This helps to communicate that authorization servers are only required to > support HTTP Basic if they issue client passwords. > > Andre > > On Tue, Sep 20, 2011 at 3:20 PM, Eran Hammer-Lahav > wrote: > > If the server issues clients with password credentials it MUST support = HTTP > Basic (this is the flip side of 'the client MAY use HTTP Basic') and shou= ld only > support the client_secret parameter if it has clients incapable of using = HTTP > Basic. > > > > This language has been tweaked to reach a delicate balance. I'm not > inclined to touch it. > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Andr=E9 DeMarre > >> Sent: Wednesday, September 14, 2011 5:25 PM > >> To: OAuth WG > >> Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2 > >> > >> I agree that stating "Clients in possession of a client password MAY > >> use the HTTP Basic authentication scheme" [Section 2.3.1 paragraph 1] > >> implies that authorization servers MUST support HTTP basic > >> authentication, but such is never asserted. Instead, it says "The > >> authorization server MAY accept any form of client authentication > >> meeting its security requirements." [Section 2.3 paragraph 1] This is > somewhat contradictory. > >> > >> I can understand that requiring a specific method of client > >> authentication is desirable for maximum interoperability, but this > >> would be problematic for authorization server implementations that > >> wish to enforce stronger security than HTTP Basic. Such > >> implementations would be forced to deviate from the specification. In > >> particular, implementations which choose MAC access tokens instead of > >> Bearer tokens may wish to add a layer of security to defend against > >> improperly configured TLS connections, or to protect clients who conne= ct > to the wrong server. > >> [http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-ide > >> a/] Such implementations will also find HTTP Basic undesirable for > >> client authentication. To require a form of client authentication > >> that isn't universally sufficient could become a source of criticism > >> and deter adoption of OAuth 2.0. > >> > >> I think the best solution is to clarify section 2.3.1 as follows: > >> --- > >> Clients in possession of client credentials MAY use any form of > >> authentication scheme supported by the authorization server. > >> --- > >> And then follow with the existing example that demonstrates HTTP Basic= . > >> > >> Regards, > >> Andre DeMarre > >> > >> On Tue, Sep 13, 2011 at 4:52 PM, Greg Brail wrote: > >> > I would like to add my support to the comments below on section > >> > 2.3, specifically 2.3.1. > >> > > >> > It is clear to me from reading section 2.3 that clients MAY use > >> > HTTP basic, or they MAY include client_id and client_secret in the > >> > request body -- however, the latter is not recommended. > >> > > >> > It is not clear what the authorization server MUST support. IMHO, > >> > that leads us to a situation in which there is no > >> > universally-agreed set of authentication technology that all > >> > programmers can assume is going to work, which means that > >> > interoperability will be difficult as some authorization servers > >> > will support Basic, others will support the request body, and others= will > do neither in favor of something else. > >> > > >> > I would prefer that we make both HTTP basic AND the request body > >> > mechanisms in this section both required on the server side, thus > >> > giving the client the option of choosing one or the other. That > >> > would mean re-writing the beginning of section 2.3.1 as shown below. > >> > > >> > If I have missed other discussion on this topic I apologize. If > >> > there is already consensus to make the "message body" > >> > authentication optional rather than required for the authorization > >> > SERVER then I would still recommend that we make HTTP Basic a MUST > >> > in order to allow easier interop. > >> > > >> > Proposed change to 2.3.1: > >> > > >> > ---- > >> > > >> > The authorization server MUST support the HTTP Basic authentication > >> > scheme as defined in [RFC2617] as a way to identify clients. The > >> > client identifier is used as the username, and the client password > >> > is used as the password. > >> > > >> > For example (extra line breaks are for display purposes only): > >> > > >> > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > >> > > >> > Alternatively, the authorization server MUST also allow the client > >> > to include the client credentials in the request body using the > >> > following > >> > parameters: > >> > > >> > client_id > >> > REQUIRED. The client identifier issued to the client > >> > during > >> > the registration process described by Section 2.2. > >> > client_secret > >> > REQUIRED. The client secret. The client MAY omit the > >> > parameter if the client secret is an empty string. > >> > > >> > Clients in possession of a client password MAY use either mechanism > >> > in order to authenticate with the authorization server. However, > >> > including the client credentials in the request body using the two > >> > parameters is NOT RECOMMENDED, and should be limited to clients > >> > unable to directly utilize the HTTP Basic authentication scheme (or > >> > other password-based HTTP authentication schemes). > >> > > >> > (Rest of section remains as-is with the paragraph beginning "For > >> > example...") > >> > > >> > Gregory Brail | Technology | Apigee | +1-650-937-9302 > >> > > >> > On Mon, Sep 12, 2011 at 2:02 PM, Stephen Farrell > >> > wrote: > >> >> > >> >> FYI, probably best for the WG to see/process these secdir comments > >> >> as appropriate. I've not read 'em in detail myself yet, so as Leif > >> >> says, feel free to react as appropriate. > >> >> > >> >> S. > >> >> > >> >> PS: Thanks Leif for reviewing this. > >> >> > >> >> -------- Original Message -------- > >> >> Subject: secdir review of draft-ietf-oauth-v2 > >> >> Date: Mon, 12 Sep 2011 20:31:06 +0200 > >> >> From: Leif Johansson > >> >> To: draft-ietf-oauth-v2@tools.ietf.org, secdir@ietf.org, > >> >> iesg@ietf.org > >> >> > >> >> -----BEGIN PGP SIGNED MESSAGE----- > >> >> Hash: SHA1 > >> >> > >> >> > >> >> Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 > >> >> > >> >> Do not be alarmed. I have reviewed this document as part of the > >> >> security directorate's ongoing effort to review all IETF documents > >> >> being processed by the IESG. These comments were written > >> >> primarily for the benefit of the security area directors. > >> >> Document editors and WG chairs should treat these comments just > >> >> like any other last call comments. > >> >> > >> >> This review is rather lengthy. This should not be interpreted as > >> >> anything beyond a desire to do a thorough review. > >> >> > >> >> It may well be that I have stumbled on things already covered on > >> >> the list. If so I apologize and ask that you silently ignore such b= its. > >> >> Also I have included things that are not directly security related > >> >> but that I found problematic for other reasons. > >> >> > >> >> The notes are presented in the order I wrote them down. > >> >> > >> >> ** General observations: > >> >> > >> >> POST and/or GET > >> >> > >> >> Examples are sometimes POST and sometimes GET. In many cases it is > >> >> not clear to me from the surrounding text if both POST and GET are > >> >> allowed or if only one is mandated. Illustrating with both a GET > >> >> _and_ POST example in the cases where both are supported would > >> >> help or make the method explicit in the text before the example. > >> >> > >> >> The P-word > >> >> > >> >> The term 'password' is sprinkled throughout the document, > >> >> sometimes as in "client password" or "resource owner password > >> >> credentials" and I suspect that sometimes it is password as in 'an > >> >> example of a credential type' and in other cases it is password as > >> >> in 'plain old password'. This needs to be cleared up throughout > >> >> (I've included some examples below). > >> >> > >> >> Normative Language > >> >> > >> >> I've often found myself wanting more normative language often to > >> >> replace existing but less precise text. I've called out some > >> >> important cases below. > >> >> > >> >> Unknown parameters > >> >> > >> >> The sentence "The client SHOULD ignore unrecognized response > >> parameters" > >> >> occurs in several places. First of all I would argue that this has > >> >> to be a MUST if you want to be able to guarantee extensibility. > >> >> Secondly there are some error responses that are triggered by > >> >> unsupported request parameters. This seems like an inconsistency. > >> >> > >> >> ** Specifics > >> >> > >> >> 1.1 Roles > >> >> > >> >> Forward references to the sections where the roles are defined > >> >> would improve readability. > >> >> > >> >> As an illustration of an alternative model for the authorization > >> >> server maybe an informative reference to UMA would be illustrative > >> here. > >> >> > >> >> 1.2 Protocol Flow > >> >> > >> >> (A) talks about 'an intermediary such as an authorization server.' > >> >> it isn't clear it me if this refers to a separate authorization > >> >> server or if it is the same authorization server that is referenced= in (B). > >> >> > >> >> 1.3.3 Resource Owner Password Credentials > >> >> > >> >> When I first read this I thought - why not talk about Resource > >> >> Owner Credentials - in fact there is a parenthesis there "(e.g a > >> >> username and password)" that seems to indicate that other > >> >> credentials could be supported. > >> >> > >> >> This needs to be cleared up. Either its username and password and > >> >> nothing else or there is a way to support things like Negotiate or > >> >> X.509-based credentials in which case it should really be Resource > >> >> Owner Credentials with no reference to passwords other than as as > >> >> an example of one possible credential type. > >> >> > >> >> 1.4 Access Token > >> >> > >> >> first paragraph: "The string is usually opaque". This should be > >> >> reformulated as normative language. In fact I would have liked > >> >> guidance on generating those tokens (which has been brought up on > >> >> the > >> >> list) possibly as part of an implementation-guide. > >> >> > >> >> 1.5 Refresh Token > >> >> > >> >> Why is the refresh token not simply treated as an access token for > >> >> the access token resource in the authorization server? This would > >> >> seem to simplify the model a bit by removing a type of token whose > >> >> semantic (at least to this reviewer) is a duplication of a normal > >> >> access token for a particular type of resource. > >> >> > >> >> Also in the first paragraph: "(access tokens may have a shorter > >> >> lifetime and fewer permissions". Why not try to write normative > >> >> language here - there are security implications of allowing a > >> >> refresh token to get more permissions (say) than the original acces= s > token. > >> >> > >> >> 2.1 Client types > >> >> > >> >> I find the terminology public/confidential somewhat counter-intuiti= ve. > >> >> An app you have on your personal device is 'public' while a shared > >> >> cloud service is 'confidential'...hmm... > >> >> > >> >> This section also lacks normative language which isn't good. There > >> >> should be language defining the behavior of public and > >> >> confidential client aswell as the three profiles. > >> >> > >> >> For instance under native application we have "It is assumed that > >> >> any client authentication credentials included in the application > >> >> can be extracted". This should really be normative language. Some > >> >> of what I am looking for can be found in section 2.3 but it isn't > >> >> clear to me that it covers the definition of the profiles. > >> >> > >> >> 2.3.1 Client Password > >> >> > >> >> There is also some confusion here about what the client must > >> >> implement and what the server must implement wrt the use of > >> >> client_id. I read the text as trying to say that Servers SHOULD > >> >> support both and clients SHOULD only do Basic. > >> >> > >> >> This section also seems to have been the product of a partial > >> >> s/password/credential/g operation. Either OAUTH is only meant to > >> >> use Basic and passwords or we want to cover all/most HTTP > >> >> authentication methods and credentials and then section 2.3.2 > >> >> (which feels like an > >> >> afterthought) needs to get folded into 2.3.1 and the normative > >> >> language (and examples!) need some work to cover at least X.509s > >> >> and perhaps even Negotiate. > >> >> > >> >> Personally I would try to fold 2.3.1 and 2.3.2 into one section > >> >> and say that servers MUST support Basic and > client_id+client_password. > >> >> Servers MAY support any HTTP authentication method with a mapping > >> >> to > >> client_id. > >> >> If a client supports username+passwords it SHOULD do Basic and if > >> >> it supports other HTTP authentication methods it MUST NOT use > >> >> client_password for anything and MUST follow normal HTTP > >> >> authentication method negotiation. > >> >> > >> >> Finally, everywhere there is negotiation there must imho be some > >> >> mention/discussion/protection of downgrade attacks. > >> >> > >> >> 3.1 Authorization Endpoints > >> >> > >> >> 6th paragraph: "The authorization server SHOULD ignore > >> >> unrecognized request parameters". This formulation returns in > >> >> several places in the document and I don't understand why it isn't > >> >> a MUST - after all doesn't extensibility depend on this? > >> >> > >> >> 3.1.1 Response Type > >> >> > >> >> The response_type parameter is REQURED but its absence SHOULD > >> >> result in an error. Why not MUST? > >> >> > >> >> 3.1.2 Redirection Endpoint > >> >> > >> >> There should be a clear normative specification for how to match > >> >> endpoints. There are traces of this in various parts of the > >> >> document when matching is discussed. I recommend making a concise > >> >> definition in one place (namely here) and referencing this > >> >> throughout. Since this comparison has security implications it > >> >> should be a priority for the specification to be air-tight. > >> >> > >> >> 3.1.2.2 Registration Requirements > >> >> > >> >> "(the client MAY use the state request parameter to achieve > >> >> per-request customization)". Doesn't this overload its use for > >> >> CSRF- > >> protection? > >> >> > >> >> 3.1.2.4 Invalid Endpoint > >> >> > >> >> "The authorization server SHOULD NOT redirect...". Why isn't this > >> >> a MUST NOT? > >> >> > >> >> 3.1.2.5 Endpoint Content > >> >> > >> >> This section basically seems to say "Serve with server-side code > >> >> not with html or client-side code". If this is the case then I > >> >> suggest reformulate to say precisely that using normative language. > >> >> > >> >> The use of the word "script" could perhaps also be made less > >> >> ambiguous since in this case it could refer to both server-side > >> >> code aswell as in-browser code. > >> >> > >> >> 3.2.1 Client Authentication > >> >> > >> >> The phrase "clients issued client credentials" could be rephrased > >> >> to make less violence on English - perhaps "clients that have been > >> >> issued with client credentials", unless that is not the intended > >> >> meaning in which case I argue for something easier to understand > >> >> ;-) > >> >> > >> >> The second bullet: Using client credentials more often also > >> >> exposes them more which might be worth mentioning aswell. > >> >> > >> >> 4. Obtaining Authorization > >> >> > >> >> Perhaps not critical but the term 'password credentials' occurs in > >> >> the first paragraph and this doesn't seem compatible with resource > >> >> owner authentication being out of scope. It could just be that it > >> >> should read 'resource owner credentials' but it could also signal > >> >> an underlying assumption about username and password being used > >> >> for resource owner authentication. In either case I thing its best > >> >> to avoid the use of the word 'password' to avoid any confusion. > >> >> > >> >> 4.1 Authorization Code > >> >> > >> >> (C) - "using the redirection URI provided earlier" should perhaps > >> >> read "using the redirection URI provided earlier or associated > >> >> with the client in client registration" > >> >> > >> >> > >> >> 4.1.1 and 4.1.2 Authorization Request/Authorization Response > >> >> > >> >> The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 > >> >> but there is no mention in 4.1.2 how to handle the case when the > >> >> redirect_uri is not present. I believe the assumption is that the > >> >> redirect_uri is either resent or part of client registration but > >> >> that needs to be made explicit in that case. > >> >> > >> >> This may apply to other uses of the redirect_uri parameter eg in 4.= 2.1. > >> >> > >> >> Furthermore in 4.2.2 "code" I suggest the following > >> >> re-formulatation of the last sentence: "The client MUST NOT use an > >> >> authorization code for more than one request. If an authorization > >> >> code is re-used, the authorization server should treat that as a > >> >> replay attack and SHOULD revoke all tokens associated with the clie= nt." > (i.e loose the "attempt" > >> >> bit which carries no real meaning) > >> >> > >> >> Also note that this is potentially a DOS attack should a single > >> >> authz code leak. > >> >> > >> >> 4.1.2.1 Error Response > >> >> > >> >> First paragraph, last sentence "and MUST NOT automatically redirect= ". > >> >> In the light of how willing users normally are to click on links > >> >> presented to them I would strengthen this to "MUST prevent the > >> >> user from following the redirect URI" > >> >> > >> >> In the definition of the invalid_request parameter I don't > >> >> understand how unsupported parameters can generate an error since > >> >> endpoints should ignore unsupported parameters (in order to support > extensibility). > >> >> > >> >> 4.1.3 Access Token Request > >> >> > >> >> "require client authentication for confidential clients or for any > >> >> client issued client credentials (or with other authentication > >> >> requirements)" > >> >> > >> >> This text seems unnecessarily convoluted. Isn't enough to say that > >> >> if you have issued credentials to a client you MUST require > >> >> authentication from that client? This applies equally to the other > >> >> sections where client authentication is an issue (eg 4.3.2). > >> >> > >> >> Also cf my comment on 3.1.2 for the discussion of matching > >> >> redirect_uri in the last bullet: ".. and that their values are > >> >> identical". Is this really meant to mean identical? > >> >> > >> >> 4.2 Implicit Grant > >> >> > >> >> The parenthesis "(it does not support the issuance of refresh token= s)" > >> >> sounds like it should really be normative language, "refresh > >> >> tokens MUST NOT be issues for implicit grant" because afaiu you > >> >> could easily extend "fragment-transport" to include a > >> >> refresh-token, so it isn't a technically motivated constraint, righ= t? > >> >> > >> >> In (D) I would like to have a normative reference to a document > >> >> that specifies browser behavior for URL fragments since this is a > >> >> critical security dependency for this grant type. > >> >> > >> >> 4.4 Client Credentials > >> >> > >> >> I think the text should note that this model effectively implies > >> >> that the client is able to impersonate all users which has the > >> >> potential for worse security problems than if the client has > >> >> access to individual user passwords. > >> >> > >> >> 6 Refreshing an Access Token > >> >> > >> >> scope - The term "lesser than" is intuitive but imprecise. I > >> >> suggest "MUST NOT include any scope not originally granted by the > >> >> resource > >> owner". > >> >> > >> >> 7.1 and 8.1 Access Token Types > >> >> > >> >> The section 7.1 lists two definitions of access token types and > >> >> provides a couple of examples but doesn't provide any constraints > >> >> on future development of access tokens except in 8.1 where it is > >> >> implied that not all access token types would be associated with > >> >> HTTP authentication mechanisms. Are there really no constraints on > >> >> access token types that should be captured? > >> >> > >> >> 10.6 Authorization Code Redirection URI Manipulation > >> >> > >> >> Suggest replace the word 'familiar' with 'trusted' in the first > >> >> sentence of the second paragraph. The notion of trust opens up > >> >> several boat loads of worm but it is the correct term here I think. > >> >> > >> >> In the third paragraph "the same as" wrt redirection URIs occur > >> >> and this needs to be defined (cf comments on 3.1.2 above). > >> >> > >> >> Finally "The authorization server MUST require public clients and > >> >> SHOULD require confidential clients to register their redirection > >> >> URI". I am missing a discussion of why the two types of client > >> >> differ wrt this attack vector. > >> >> > >> >> 10.10 Credentials Guessing Attack > >> >> > >> >> I found myself wanting implementation advice for how to generate > >> >> good tokens at this point. This has been raised on the list too. > >> >> The same goes for how to generate good CSRF cookies where the "(eg > >> >> a hash of the session cookie..." feels like it is implementation > >> >> advice yearning to come out of the closet. > >> >> > >> >> > >> >> Thats it. > >> >> > >> >> Cheers Leif > >> >> -----BEGIN PGP SIGNATURE----- > >> >> Version: GnuPG v1.4.11 (GNU/Linux) > >> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> >> > >> >> > >> > iEYEARECAAYFAk5uT+YACgkQ8Jx8FtbMZncXQgCfZmTlzuESq0plfpkceQN1ont > >> E > >> >> a1QAoIEcg06GYK+6Fn4y40cTL1jQ+KmS > >> >> =3Dox42 > >> >> -----END PGP SIGNATURE----- > >> >> > >> >> _______________________________________________ > >> >> 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 internet-drafts@ietf.org Wed Sep 21 20:15: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 F168021F8D0A; Wed, 21 Sep 2011 20:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 e5EKC5hTuMaE; Wed, 21 Sep 2011 20:15:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7B521F8D04; Wed, 21 Sep 2011 20:15:19 -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: <20110922031519.4268.64364.idtracker@ietfa.amsl.com> Date: Wed, 21 Sep 2011 20:15:19 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-22.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: Thu, 22 Sep 2011 03:15:20 -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 : The OAuth 2.0 Authorization Protocol Author(s) : Eran Hammer-Lahav David Recordon Dick Hardt Filename : draft-ietf-oauth-v2-22.txt Pages : 63 Date : 2011-09-21 The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-22.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-v2-22.txt From barryleiba@gmail.com Thu Sep 22 06:45: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 28D4521F8CE0 for ; Thu, 22 Sep 2011 06:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.002 X-Spam-Level: X-Spam-Status: No, score=-103.002 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 Cfyetm7M26c7 for ; Thu, 22 Sep 2011 06:45:44 -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 882D521F8CAD for ; Thu, 22 Sep 2011 06:45:44 -0700 (PDT) Received: by gxk19 with SMTP id 19so2393248gxk.31 for ; Thu, 22 Sep 2011 06:48:16 -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; bh=GnOY+8aPsSmjw7lyuMdzizSaODFzF5EG81ZuWW/7ask=; b=Z/xXQbr8bwOo+n696j/DQPDL81GzBQV5CHNJESRJRgHfPM1W5uZB8xQqxXSdgTTLM8 tXh/YIAjdBg98qya4ElhoOLDuBz3AEHHBPY9qAXIITWYcqKFPajA5597UIsM19H99R08 gVcml0RvLNdJUjTJlVooR4peecke1zqK7EXRE= MIME-Version: 1.0 Received: by 10.236.181.137 with SMTP id l9mr13535863yhm.56.1316699295896; Thu, 22 Sep 2011 06:48:15 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.203.68 with HTTP; Thu, 22 Sep 2011 06:48:15 -0700 (PDT) Date: Thu, 22 Sep 2011 09:48:15 -0400 X-Google-Sender-Auth: o7adiBp4AMgRllOh-AKtmnhwYCQ Message-ID: From: Barry Leiba To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth WG Subject: [OAUTH-WG] Publication requested for draft-ietf-oauth-v2-22 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, 22 Sep 2011 13:45:45 -0000 Stephen, The OAuth working group requests publication of draft-ietf-oauth-v2-22 as Proposed Standard. The PROTO writeup is in the tracker: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ Barry From stephen.farrell@cs.tcd.ie Fri Sep 23 04:46: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 2FC9221F8C00 for ; Fri, 23 Sep 2011 04:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 hnnQLzrqFTv7 for ; Fri, 23 Sep 2011 04:46:04 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 67EA821F8C0A for ; Fri, 23 Sep 2011 04:46:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3EB75171CEC; Fri, 23 Sep 2011 12:48:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1316778512; bh=8S31EIB2fqb7On ZNHEkKMz+VqJKgta9lHxPYJtOokVg=; b=aa0jaq+0IrGZGGMQTFmrnTOm3AGNIN /SZVUyfxl13idino73B4MbfX/m2dCg9S5I8fJ/vDrTByQjTukUaIEiTrK/hGwmoU 7sIzAfbvamo7TTf8Gudl3363ycFegArHlMV3sPpimLuYu2dGq8NhnWK5ZCPJ+KHK CjKyn3YyOrSlRe5rrMwWSrY1nZ2TAYxGTy2s9rMzcpYBmMypGHF93HRBYdWpv1Fm SMUVP0h69WS/DgZukqWGxLJCa8ymShLH2h0r+I6otMu0itxUf2ouvezp4RMZ/XN/ /JAewdRAfOm2deLyW4ImQ7h+/gnwkTMcAOPCIaUPow/3QBQ/x/+vcTkA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id eu8nshBPGa-p; Fri, 23 Sep 2011 12:48:32 +0100 (IST) Received: from [10.87.48.8] (unknown [86.46.30.134]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 845DC171C6A; Fri, 23 Sep 2011 12:48:30 +0100 (IST) Message-ID: <4E7C720E.7030209@cs.tcd.ie> Date: Fri, 23 Sep 2011 12:48:30 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth WG Subject: Re: [OAUTH-WG] Publication requested for draft-ietf-oauth-v2-22 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, 23 Sep 2011 11:46:05 -0000 Thanks Barry and all for getting this to this stage. I'll get you my AD review as soon as I can (though I'll be out of contact next week). We can then kick off the IETF LC assuming all's well. Cheers, S. On 09/22/2011 02:48 PM, Barry Leiba wrote: > Stephen, > The OAuth working group requests publication of draft-ietf-oauth-v2-22 > as Proposed Standard. > > The PROTO writeup is in the tracker: > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > > Barry > From Michael.Jones@microsoft.com Fri Sep 23 06:57: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 7C31821F8B26 for ; Fri, 23 Sep 2011 06:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.137, 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 5TNSyugDRZ1F for ; Fri, 23 Sep 2011 06:57:35 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id E651821F8B1E for ; Fri, 23 Sep 2011 06:57:34 -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; Fri, 23 Sep 2011 07:00:08 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.142]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0339.002; Fri, 23 Sep 2011 07:00:08 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Proposed resolution for issue 26 Thread-Index: Acx5+RoYuC5sLQs0Spy/pi+T441Q9A== Date: Fri, 23 Sep 2011 14:00:08 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.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_4E1F6AAD24975D4BA5B16804296739435C1FC6A1TK5EX14MBXC285r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Proposed resolution for issue 26 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, 23 Sep 2011 13:57:36 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C1FC6A1TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue #26 http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 asks whether t= he semantics of scope strings should be changed to require that the % chara= cter be interpreted as introducing a percent-encoded character that follows= . My proposed resolution is that %-encoding not be required in the specifi= cation; therefore no textual change would be made to the specification in r= esponse to this issue. The reasoning behind this resolution is as follows: 1. Interpretation of scope strings already requires semantic agreement on = the meaning of the scope strings between the parties participating the OAut= h flow. Should an encoding be used for scope strings in a particularly dep= loyment context, it is reasonable for participants to have agreed upon that= encoding, just as they agree on other OAuth configuration parameters. 2. More than one encoding methodology could reasonably be employed in scop= e strings. For instance, base64url encoding of scope values could be used = in some contexts. Quoting characters with '\' is another possibility. I s= ee no compelling reason to mandate %-encoding over other potential encoding= methods. 3. Mandating %-encoding unnecessarily complicates implementations without = providing a clear compensating benefit sufficient warrant the additional co= mplexity. For example, it seems unnecessary to mandate that the scope stri= ngs "email" and "%65mail" MUST compare as being equal in all implementation= s. 4. If an encoding methodology for scope strings is mandated, this should b= e done in the OAuth Core specification - not the OAuth Bearer Token specifi= cation. 5. I am aware of no existing practice that utilizes %-encoding of scope va= lues. -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435C1FC6A1TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Issue #26 http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 asks whether the sem= antics of scope strings should be changed to require that the % character b= e interpreted as introducing a percent-encoded character that follows. = ; My proposed resolution is that %-encoding not be required in the specification; therefore no textual change would be= made to the specification in response to this issue.  The reasoning b= ehind this resolution is as follows:

 

1.  Interpretation of scope strings already req= uires semantic agreement on the meaning of the scope strings between the pa= rties participating the OAuth flow.  Should an encoding be used for sc= ope strings in a particularly deployment context, it is reasonable for participants to have agreed upon that encoding, just = as they agree on other OAuth configuration parameters.

 

2.  More than one encoding methodology could re= asonably be employed in scope strings.  For instance, base64url encodi= ng of scope values could be used in some contexts.  Quoting characters= with ‘\’ is another possibility.  I see no compelling reason to mandate %-encoding over other potential encoding methods.

 

3.  Mandating %-encoding unnecessarily complica= tes implementations without providing a clear compensating benefit sufficie= nt warrant the additional complexity.  For example, it seems unnecessa= ry to mandate that the scope strings "email" and "%65mail" MUST compare as being equal in all implementations= .

 

4.  If an encoding methodology for scope string= s is mandated, this should be done in the OAuth Core specification – = not the OAuth Bearer Token specification.

 

5.  I am aware of no existing practice that uti= lizes %-encoding of scope values.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435C1FC6A1TK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Sep 23 06:57: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 12D0521F8B1E for ; Fri, 23 Sep 2011 06:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.132, 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 pVJrfKDVtevN for ; Fri, 23 Sep 2011 06:57:53 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 805EC21F8507 for ; Fri, 23 Sep 2011 06:57:53 -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; Fri, 23 Sep 2011 07:00:27 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.142]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0339.002; Fri, 23 Sep 2011 07:00:27 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Bearer token credentials syntax Thread-Index: Acx5+SDF4XDgMhWhRvqJf4Zf4AdI8A== Date: Fri, 23 Sep 2011 14:00:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C1FC6B7@TK5EX14MBXC285.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_4E1F6AAD24975D4BA5B16804296739435C1FC6B7TK5EX14MBXC285r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Bearer token credentials syntax 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, 23 Sep 2011 13:57:54 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C1FC6B7TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James Manger and others pointed out that the current credentials syntax doe= s not comply with RFC 2617, nor does it match the updated credentials synta= x contained in HTTPbis, part 7: Authentication. The current syntax in the bearer token draf= t is: credentials =3D "Bearer" RWS access-token access-token =3D 1*( quoted-char / <"> ) quoted-char =3D ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" The syntax in HTTPbis is: credentials =3D auth-scheme [ 1*SP ( b64token / #auth-param ) ] (Note that some of the BNF elements used by part 7 are defined in HTTPbis, = part 1: Messaging.) To resolve this comment, I plan to change the Bearer Token draft to use thi= s syntax for credentials, matching HTTPbis: credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) Are people good with this approach? Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435C1FC6B7TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James Manger and others pointed out that the current= credentials syntax does not comply with RFC 2617, nor does it match the up= dated credentials syntax contained in HTTPbi= s, part 7: Authentication.  The current syntax in the bearer= token draft is:

  = ; credentials     =3D "Bearer" RWS access-tok= en

  = ; access-token    =3D 1*( quoted-char / <"> )

 =

  = ; quoted-char     =3D ALPHA / DIGIT /=

  = ;            &n= bsp;      "!" / "#" / "$&= quot; / "%" / "&" / "'" / "(" /= ")" /

  = ;            &n= bsp;      "*" / "+" / &quo= t;-" / "." / "/" / ":" / "<"= ; / "=3D" /

  = ;            &n= bsp;      ">" / "?" / "= ;@" / "[" / "]" / "^" / "_" / = "`" /

  = ;            &n= bsp;      "{" / "|" / "}&= quot; / "~" / "\" / "," / ";"<= /o:p>

 =

The syntax in HTTPbis is:

  = ;  credentials =3D auth-scheme [ 1*SP ( b64token / #auth-param ) ]

 

(Note that some of the BNF elements used by part 7 a= re defined in H= TTPbis, part 1: Messaging.)

 

To resolve this comment, I plan to change the Bearer= Token draft to use this syntax for credentials, matching HTTPbis:

  = ; credentials =3D "Bearer" 1*SP ( b64token / #auth-param )

 

Are people good with this approach?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Thanks,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435C1FC6B7TK5EX14MBXC285r_-- From mscurtescu@google.com Fri Sep 23 10:13: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 9BA7821F8C78 for ; Fri, 23 Sep 2011 10:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.144 X-Spam-Level: X-Spam-Status: No, score=-106.144 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pN+-3scZWQcH for ; Fri, 23 Sep 2011 10:13:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 84B1021F8C75 for ; Fri, 23 Sep 2011 10:13:23 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p8NHFvqN020504 for ; Fri, 23 Sep 2011 10:15:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316798157; bh=M1HCoBbOTpXH3F+v+hleL+GqIIc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=nmcNK1ixUwrNVBpvq91IDTZ24AUnWtICPlSJt7Sf0jWvs9QkwYRXcFd3MDZeCv8iQ uEt3bBIocm8JLzWdrMDig== 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=QTOWfJQCoJ6B7NTRrFjs1DAYsHRPssZDU3e5oHPl1/mkULrFWzMYm55d3seV/xcjp GNi/cctQFUQk1wIy7gWSQ== Received: from ywm39 (ywm39.prod.google.com [10.192.13.39]) by hpaq1.eem.corp.google.com with ESMTP id p8NHFt7E016654 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 23 Sep 2011 10:15:56 -0700 Received: by ywm39 with SMTP id 39so3714302ywm.18 for ; Fri, 23 Sep 2011 10:15:55 -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=saIXH01Zce2V7CtkfpcFcLSblBlPmZvUSDkpysX8R+M=; b=sGp7CvZuxCfnG6siQanhQkjE/0bBgQ0Ax8nm+m47arPymiYlrxRc5mZ0gHk7RhAnaZ EjvOIxfqtn3Dyb25m3wA== Received: by 10.101.89.17 with SMTP id r17mr220726anl.123.1316798155256; Fri, 23 Sep 2011 10:15:55 -0700 (PDT) Received: by 10.101.89.17 with SMTP id r17mr220721anl.123.1316798155097; Fri, 23 Sep 2011 10:15:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.1.12 with HTTP; Fri, 23 Sep 2011 10:15:35 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C1FC6B7@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FC6B7@TK5EX14MBXC285.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Fri, 23 Sep 2011 10:15:35 -0700 Message-ID: To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token credentials syntax 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, 23 Sep 2011 17:13:24 -0000 On Fri, Sep 23, 2011 at 7:00 AM, Mike Jones w= rote: > James Manger and others pointed out that the current credentials syntax d= oes > not comply with RFC 2617, nor does it match the updated credentials synta= x > contained in HTTPbis, part 7: Authentication.=A0 The current syntax in th= e > bearer token draft is: > > =A0=A0 credentials=A0=A0=A0=A0 =3D "Bearer" RWS access-token > > =A0=A0 access-token=A0=A0=A0 =3D 1*( quoted-char / <"> ) > > > > =A0=A0 quoted-char=A0=A0=A0=A0 =3D ALPHA / DIGIT / > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "!" / "#" / = "$" / "%" / "&" / "'" / "(" / ")" / > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "*" / "+" / = "-" / "." / "/" / ":" / "<" / "=3D" / > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ">" / "?" / = "@" / "[" / "]" / "^" / "_" / "`" / > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "{" / "|" / = "}" / "~" / "\" / "," / ";" > > > > The syntax in HTTPbis is: > > =A0=A0=A0 credentials =3D auth-scheme [ 1*SP ( b64token / #auth-param ) ] > > > > (Note that some of the BNF elements used by part 7 are defined in HTTPbis= , > part 1: Messaging.) > > > > To resolve this comment, I plan to change the Bearer Token draft to use t= his > syntax for credentials, matching HTTPbis: > > =A0=A0=A0credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) > > > > Are people good with this approach? +1 From ve7jtb@ve7jtb.com Fri Sep 23 10:20: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 1C6B821F8C12 for ; Fri, 23 Sep 2011 10:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.053, 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 Tv1dhDAwF5ZC for ; Fri, 23 Sep 2011 10:20:45 -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 C3F9B21F8B61 for ; Fri, 23 Sep 2011 10:20:20 -0700 (PDT) Received: by gxk19 with SMTP id 19so3501976gxk.31 for ; Fri, 23 Sep 2011 10:22:55 -0700 (PDT) Received: by 10.236.185.37 with SMTP id t25mr11617367yhm.131.1316798575298; Fri, 23 Sep 2011 10:22:55 -0700 (PDT) Received: from [192.168.1.213] ([190.22.119.251]) by mx.google.com with ESMTPS id o48sm17266738yhl.4.2011.09.23.10.22.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Sep 2011 10:22:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_C02F994A-6EAB-4FD7-91C3-807B553D1A5F"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C1FC6B7@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Fri, 23 Sep 2011 14:22:50 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739435C1FC6B7@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1244.3) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token credentials syntax 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, 23 Sep 2011 17:20:46 -0000 --Apple-Mail=_C02F994A-6EAB-4FD7-91C3-807B553D1A5F Content-Type: multipart/alternative; boundary="Apple-Mail=_F238F43C-79ED-4429-9209-B20232BAFC68" --Apple-Mail=_F238F43C-79ED-4429-9209-B20232BAFC68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 On 2011-09-23, at 11:00 AM, Mike Jones wrote: > James Manger and others pointed out that the current credentials = syntax does not comply with RFC 2617, nor does it match the updated = credentials syntax contained in HTTPbis, part 7: Authentication. The = current syntax in the bearer token draft is: > credentials =3D "Bearer" RWS access-token > access-token =3D 1*( quoted-char / <"> ) > =20 > quoted-char =3D ALPHA / DIGIT / > "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / > "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / > ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / > "{" / "|" / "}" / "~" / "\" / "," / ";" > =20 > The syntax in HTTPbis is: > credentials =3D auth-scheme [ 1*SP ( b64token / #auth-param ) ] > =20 > (Note that some of the BNF elements used by part 7 are defined in = HTTPbis, part 1: Messaging.) > =20 > To resolve this comment, I plan to change the Bearer Token draft to = use this syntax for credentials, matching HTTPbis: > credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) > =20 > Are people good with this approach? > =20 > = Thanks, > -- = Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_F238F43C-79ED-4429-9209-B20232BAFC68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1

On 2011-09-23, at 11:00 AM, = Mike Jones wrote:

James Manger and others = pointed out that the current credentials syntax does not comply with RFC = 2617, nor does it match the updated credentials syntax contained in HTTPbis, part 7: = Authentication.  The current syntax in the bearer token = draft is:
   = credentials     =3D "Bearer" RWS = access-token
   access-token    =3D 1*( quoted-char = / <"> )
 
   quoted-char     =3D ALPHA / = DIGIT /
            =          "!" / "#" / "$" / "%" / = "&" / "'" / "(" / ")" /
 
The syntax in HTTPbis = is:
 
(Note that some of the BNF elements used by part 7 are = defined in HTTPbis, part 1: = Messaging.)
 
To resolve this comment, I plan to change the Bearer Token = draft to use this syntax for credentials, matching = HTTPbis:
 
Are people good with this approach?
 
Subject: Re: [OAUTH-WG] Bearer token credentials syntax 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, 23 Sep 2011 18:34:27 -0000 --Apple-Mail-90--806695406 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2011-09-23, at 7:00 AM, Mike Jones wrote: > James Manger and others pointed out that the current credentials = syntax does not comply with RFC 2617, nor does it match the updated = credentials syntax contained in HTTPbis, part 7: Authentication. The = current syntax in the bearer token draft is: > credentials =3D "Bearer" RWS access-token > access-token =3D 1*( quoted-char / <"> ) > =20 > quoted-char =3D ALPHA / DIGIT / > "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / > "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / > ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / > "{" / "|" / "}" / "~" / "\" / "," / ";" > =20 > The syntax in HTTPbis is: > credentials =3D auth-scheme [ 1*SP ( b64token / #auth-param ) ] > =20 > (Note that some of the BNF elements used by part 7 are defined in = HTTPbis, part 1: Messaging.) > =20 > To resolve this comment, I plan to change the Bearer Token draft to = use this syntax for credentials, matching HTTPbis: > credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) > =20 > Are people good with this approach? > =20 > = Thanks, > -- = Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-90--806695406 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Phil

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





On 2011-09-23, at 7:00 AM, Mike Jones wrote:

James Manger and others = pointed out that the current credentials syntax does not comply with RFC = 2617, nor does it match the updated credentials syntax contained in HTTPbis, part 7: = Authentication.  The current syntax in the bearer token = draft is:
   = credentials     =3D "Bearer" RWS = access-token
   access-token    =3D 1*( quoted-char = / <"> )
 
   quoted-char     =3D ALPHA / = DIGIT /
            =          "!" / "#" / "$" / "%" / = "&" / "'" / "(" / ")" /
 
The syntax in HTTPbis = is:
 
(Note that some of the BNF elements used by part 7 are = defined in HTTPbis, part 1: = Messaging.)
 
To resolve this comment, I plan to change the Bearer Token = draft to use this syntax for credentials, matching = HTTPbis:
 
Are people good with this approach?
 
To: "'Marius Scurtescu'" , Chuck Mortimore Date: Fri, 23 Sep 2011 16:00:52 -0500 Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt Thread-Index: Acx2/LctJLh/xOBQRn6pAvgnXeJcowDNyRJw Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058FBA48BF@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> References: <20110916192014.6501.87499.idtracker@ietfa.amsl.com> <4E73A431.2020205@lodderstedt.net> <19099790-0E64-4F08-80D5-FC2DFD903AD2@salesforce.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_0E96A74B7DFCF844A9BE2A0BBE2C425F058FBA48BFUSNAVSXCHMBSB_" 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.11 Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.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, 23 Sep 2011 20:58:22 -0000 --_000_0E96A74B7DFCF844A9BE2A0BBE2C425F058FBA48BFUSNAVSXCHMBSB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Huilan Lu From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= arius Scurtescu Sent: Monday, September 19, 2011 2:48 PM To: Chuck Mortimore Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt= -oauth-revocation-03.txt +1 On Fri, Sep 16, 2011 at 1:06 PM, Chuck Mortimore > wrote: If it's not already implicit by our implementation, I'm voicing our support= for this becoming a working group item. - cmort On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt" > wrote: Hi all, I just published a new revision of the token revocation draft. We added JSO= NP support (thanks to Marius) and aligned the text with draft 21 of the cor= e spec. We would like to bring this draft forward as working group item (once the W= G is ready). We think its relevance is illustrated by the fact that this dr= aft (or its predecessor) has already been implemented by Google, Salesforce= , and Deutsche Telekom. regards, Torsten. -------- Original-Nachricht -------- Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt Datum: Fri, 16 Sep 2011 12:20:14 -0700 Von: internet-drafts@ietf.org An: torsten@lodderstedt.net CC: sdronia@gmx.de, torsten@lodderstedt.net, mscurtescu@google.com A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been su= ccessfully submitted by Torsten Lodderstedt and posted to the IETF reposito= ry. Filename: draft-lodderstedt-oauth-revocation Revision: 03 Title: Token Revocation Creation date: 2011-09-16 WG ID: Individual Submission Number of pages: 6 Abstract: This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_0E96A74B7DFCF844A9BE2A0BBE2C425F058FBA48BFUSNAVSXCHMBSB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Huilan Lu

 

= From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Marius Scurtescu
Sent: Monday, September 19, 2011 2:48 PM
= To: Chuck Mortimore
Cc: OAuth WG
Subject: Re: [O= AUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocati= on-03.txt

 =

+1

On Fri, Sep 16, 2011 at 1:0= 6 PM, Chuck Mortimore <cmor= timore@salesforce.com> wrote:

If it's not already implicit by our implementation, I'm voicing our = support for this becoming a working group item.   

- cmort=


On Sep 16, 2011, at 12:31 PM, "Torsten Lodderstedt&qu= ot; <torste= n@lodderstedt.net> wrote:

Hi all,
<= br>I just published a new revision of the token revocation draft. We added = JSONP support (thanks to Marius) and aligned the text with draft 21 of the = core spec.

We would like to bring this draft forward as working grou= p item (once the WG is ready). We think its relevance is illustrated by the= fact that this draft (or its predecessor) has already been implemented by = Google, Salesforce, and Deutsche Telekom.

regards,
Torsten.
-------- Original-Nachricht --------

<= td nowrap valign=3Dtop style=3D'padding:0in 0in 0in 0in'>

Datum:

Betreff:

New Version Notification = for draft-lodderstedt-oauth-revocation-03.txt

Fri, 16 Sep 2= 011 12:20:14 -0700

Von:

internet-drafts@ietf.org

An:

torsten@lodderstedt.net=

<= b>CC:

sdronia@g= mx.de, tor= sten@lodderstedt.net, mscurtescu@google.com

 

A =
new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been succ=
essfully submitted by Torsten Lodderstedt and posted to the IETF repository=
.
 
Filename:  &nb=
sp;     draft-lodderstedt-oauth-revocation
<= pre>Revision:       03
=
Title:           Token Revocat=
ion
Creation date:   2011-09-16
<= pre>WG ID:          Individua= l Submission
Number of pages: 6
<=
o:p> 
Abstract:
   This=
 draft proposes an additional endpoint for OAuth authorization
   servers for revoking tokens.
 
        &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;           
 
 
The IETF S=
ecretariat

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

 

= --_000_0E96A74B7DFCF844A9BE2A0BBE2C425F058FBA48BFUSNAVSXCHMBSB_-- From dick.hardt@gmail.com Fri Sep 23 14:09: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 9D15021F8C91 for ; Fri, 23 Sep 2011 14:09:26 -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 2KvGj9Vlri4Y for ; Fri, 23 Sep 2011 14:09:26 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1C0D21F8C79 for ; Fri, 23 Sep 2011 14:09:25 -0700 (PDT) Received: by iaby26 with SMTP id y26so5346821iab.31 for ; Fri, 23 Sep 2011 14:12:01 -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=sIkyO8NGDxJdRl64lnk9vDgFzT4XZll3gJ3iW5sJ2ws=; b=KfwfDHXfiYckmlK0Qln33x97L5phYviLh5Dbc4GpcVXgAg74Rh2R7I4gejiJa2Z3ng 9ilFLe8R6wt8PSQyGY1MBgOV67FDR1v5wUhOfDB3+kfDlTe8F0C1IP6CsaG2ABKJIhQ1 GmCQpT3DfqK7QomZDTtp7W85HR6PIYxXPDFVs= Received: by 10.42.140.9 with SMTP id i9mr3648108icu.148.1316812315955; Fri, 23 Sep 2011 14:11:55 -0700 (PDT) Received: from [192.168.1.34] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id by18sm17158997ibb.1.2011.09.23.14.11.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Sep 2011 14:11:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4--797661589 From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C1FC6B7@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Fri, 23 Sep 2011 14:05:54 -0700 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739435C1FC6B7@TK5EX14MBXC285.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Bearer token credentials syntax 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, 23 Sep 2011 21:09:26 -0000 --Apple-Mail-4--797661589 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1.1 On 2011-09-23, at 7:00 AM, Mike Jones wrote: > James Manger and others pointed out that the current credentials = syntax does not comply with RFC 2617, nor does it match the updated = credentials syntax contained in HTTPbis, part 7: Authentication. The = current syntax in the bearer token draft is: > credentials =3D "Bearer" RWS access-token > access-token =3D 1*( quoted-char / <"> ) > =20 > quoted-char =3D ALPHA / DIGIT / > "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / > "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / > ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / > "{" / "|" / "}" / "~" / "\" / "," / ";" > =20 > The syntax in HTTPbis is: > credentials =3D auth-scheme [ 1*SP ( b64token / #auth-param ) ] > =20 > (Note that some of the BNF elements used by part 7 are defined in = HTTPbis, part 1: Messaging.) > =20 > To resolve this comment, I plan to change the Bearer Token draft to = use this syntax for credentials, matching HTTPbis: > credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) > =20 > Are people good with this approach? > =20 > = Thanks, > -- = Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4--797661589 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1.1

On 2011-09-23, at 7:00 AM, = Mike Jones wrote:

James Manger and others = pointed out that the current credentials syntax does not comply with RFC = 2617, nor does it match the updated credentials syntax contained in HTTPbis, part 7: = Authentication.  The current syntax in the bearer token = draft is:
   = credentials     =3D "Bearer" RWS = access-token
   access-token    =3D 1*( quoted-char = / <"> )
 
   quoted-char     =3D ALPHA / = DIGIT /
            =          "!" / "#" / "$" / "%" / = "&" / "'" / "(" / ")" /
 
The syntax in HTTPbis = is:
 
(Note that some of the BNF elements used by part 7 are = defined in HTTPbis, part 1: = Messaging.)
 
To resolve this comment, I plan to change the Bearer Token = draft to use this syntax for credentials, matching = HTTPbis:
 
Are people good with this approach?
 
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 22:48:58 -0000 This is a multi-part message in MIME format. --------------020801030507080507090602 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Yes, this is high time to have this a WG item! Igor On 9/16/2011 3:32 PM, Torsten Lodderstedt wrote: > Hi all, > > I just published a new revision of the token revocation draft. We > added JSONP support (thanks to Marius) and aligned the text with draft > 21 of the core spec. > > We would like to bring this draft forward as working group item (once > the WG is ready). We think its relevance is illustrated by the fact > that this draft (or its predecessor) has already been implemented by > Google, Salesforce, and Deutsche Telekom. > > regards, > Torsten. > > -------- Original-Nachricht -------- > Betreff: New Version Notification for > draft-lodderstedt-oauth-revocation-03.txt > Datum: Fri, 16 Sep 2011 12:20:14 -0700 > Von: internet-drafts@ietf.org > An: torsten@lodderstedt.net > CC: sdronia@gmx.de, torsten@lodderstedt.net, mscurtescu@google.com > > > > A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. > > Filename: draft-lodderstedt-oauth-revocation > Revision: 03 > Title: Token Revocation > Creation date: 2011-09-16 > WG ID: Individual Submission > Number of pages: 6 > > Abstract: > This draft proposes an additional endpoint for OAuth authorization > servers for revoking tokens. > > > > > The IETF Secretariat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020801030507080507090602 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Yes, this is high time to have this a WG item!

Igor

On 9/16/2011 3:32 PM, Torsten Lodderstedt wrote:
Hi all,

I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec.

We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom.

regards,
Torsten.

-------- Original-Nachricht --------
Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt
Datum: Fri, 16 Sep 2011 12:20:14 -0700
Von: internet-drafts@ietf.org
An: torsten@lodderstedt.net
CC: sdronia@gmx.de, torsten@lodderstedt.net, mscurtescu@google.com 


A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository.

Filename:	 draft-lodderstedt-oauth-revocation
Revision:	 03
Title:		 Token Revocation
Creation date:	 2011-09-16
WG ID:		 Individual Submission
Number of pages: 6

Abstract:
   This draft proposes an additional endpoint for OAuth authorization
   servers for revoking tokens.

                                                                                  


The IETF Secretariat


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------020801030507080507090602-- From internet-drafts@ietf.org Fri Sep 23 17:06: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 6573321F8C78; Fri, 23 Sep 2011 17:06:38 -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 bg3nbPe3xmV6; Fri, 23 Sep 2011 17:06:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E985721F8B2F; Fri, 23 Sep 2011 17:06:37 -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: <20110924000637.4972.21254.idtracker@ietfa.amsl.com> Date: Fri, 23 Sep 2011 17:06:37 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-09.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: Sat, 24 Sep 2011 00:06:38 -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 : The OAuth 2.0 Authorization Protocol: Bearer Tokens Author(s) : Michael B. Jones Dick Hardt David Recordon Filename : draft-ietf-oauth-v2-bearer-09.txt Pages : 18 Date : 2011-09-23 This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-09.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-v2-bearer-09.txt From Michael.Jones@microsoft.com Fri Sep 23 17:07: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 D778121F8BAE for ; Fri, 23 Sep 2011 17:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, 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 PdixEQsXBI-t for ; Fri, 23 Sep 2011 17:07:42 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 671E921F8BAA for ; Fri, 23 Sep 2011 17:07:42 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 23 Sep 2011 17:10:17 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.142]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Fri, 23 Sep 2011 17:10:17 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: New Version Notification for draft-ietf-oauth-v2-bearer-09.txt Thread-Index: AQHMek4yS2nHxKTAqUOhirAhA/qwj5Vbp/nw Date: Sat, 24 Sep 2011 00:10:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C1FD5C2@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <20110924000638.4972.23225.idtracker@ietfa.amsl.com> In-Reply-To: <20110924000638.4972.23225.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-v2-bearer-09.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: Sat, 24 Sep 2011 00:07:43 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBT ZXB0ZW1iZXIgMjMsIDIwMTEgNTowNyBQTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBNaWtlIEpvbmVz OyBkckBmYi5jb207IGRpY2suaGFyZHRAZ21haWwuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTA5LnR4dA0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMDkudHh0IGhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWljaGFlbCBKb25lcyBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1vYXV0aC12Mi1i ZWFyZXINClJldmlzaW9uOgkgMDkNClRpdGxlOgkJIFRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlv biBQcm90b2NvbDogQmVhcmVyIFRva2Vucw0KQ3JlYXRpb24gZGF0ZToJIDIwMTEtMDktMjINCldH IElEOgkJIG9hdXRoDQpOdW1iZXIgb2YgcGFnZXM6IDE4DQoNCkFic3RyYWN0Og0KICAgVGhpcyBz cGVjaWZpY2F0aW9uIGRlc2NyaWJlcyBob3cgdG8gdXNlIGJlYXJlciB0b2tlbnMgaW4gSFRUUA0K ICAgcmVxdWVzdHMgdG8gYWNjZXNzIE9BdXRoIDIuMCBwcm90ZWN0ZWQgcmVzb3VyY2VzLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From Michael.Jones@microsoft.com Fri Sep 23 17:08: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 565B121F8C07 for ; Fri, 23 Sep 2011 17:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, 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 RZZ9s0PSawLO for ; Fri, 23 Sep 2011 17:08:03 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 9092C21F8C00 for ; Fri, 23 Sep 2011 17:08:03 -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; Fri, 23 Sep 2011 17:10:39 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.142]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0339.002; Fri, 23 Sep 2011 17:10:38 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -09 Thread-Index: Acx6TmCFonAm13/nQwKYivVtbUEGDQ== Date: Sat, 24 Sep 2011 00:10:38 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C1FD5E4@TK5EX14MBXC285.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.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C1FD5E4TK5EX14MBXC285r_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -09 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, 24 Sep 2011 00:08:04 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C1FD5E4TK5EX14MBXC285r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RHJhZnQgMDk8aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLW9hdXRoLXYy LWJlYXJlci0wOS5odG1sPiBvZiB0aGUgT0F1dGggMi4wIEJlYXJlciBUb2tlbiBTcGVjaWZpY2F0 aW9uPGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFy ZXIuaHRtbD4gaGFzIGJlZW4gcHVibGlzaGVkLCB3aGljaCBpbmNvcnBvcmF0ZXMgV29ya2luZyBH cm91cCBMYXN0IENhbGwgZmVlZGJhY2suICBJdCBjb250YWlucyB0aGUgZm9sbG93aW5nIGNoYW5n ZXM6DQoNCg0KwrcgICAgICAgICBVc2UgZGVmaW5pdGlvbnMgZnJvbSBbSeKAkUQuaWV0ZuKAkWh0 dHBiaXPigJFwN+KAkWF1dGhdIHJhdGhlciB0aGFuIFtSRkMyNjE3XS4NCg0KwrcgICAgICAgICBV cGRhdGUgY3JlZGVudGlhbHMgZGVmaW5pdGlvbiB0byBjb25mb3JtIHRvIFtJ4oCRRC5pZXRm4oCR aHR0cGJpc+KAkXA34oCRYXV0aF0uDQoNCsK3ICAgICAgICAgRnVydGhlciBjbGFyaWZpZWQgdGhh dCBxdWVyeSBwYXJhbWV0ZXJzIG1heSBvY2N1ciBpbiBhbnkgb3JkZXIuDQoNCsK3ICAgICAgICAg U3BlY2lmeSB0aGF0IGVycm9yX2Rlc2NyaXB0aW9uIGlzIFVURi04IGVuY29kZWQgKG1hdGNoaW5n IHRoZSBjb3JlIHNwZWNpZmljYXRpb24pLg0KDQrCtyAgICAgICAgIFJlZ2lzdGVyZWQgIkJlYXJl ciIgQXV0aGVudGljYXRpb24gU2NoZW1lIGluIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSBSZWdpc3Ry eSBkZWZpbmVkIGJ5IFtJ4oCRRC5pZXRm4oCRaHR0cGJpc+KAkXA34oCRYXV0aF0uDQoNCsK3ICAg ICAgICAgVXBkYXRlZCByZWZlcmVuY2VzIHRvIG9hdXRoLXYyLCBodHRwYmlzLXAxLW1lc3NhZ2lu ZywgYW5kIGh0dHBiaXMtcDctYXV0aCBkcmFmdHMuDQoNCsK3ICAgICAgICAgT3RoZXIgd29yZGlu ZyBpbXByb3ZlbWVudHMgbm90IGludHJvZHVjaW5nIG5vcm1hdGl2ZSBjaGFuZ2VzLg0KDQpUaGUg ZHJhZnQgaXMgYXZhaWxhYmxlIGF0IHRoZXNlIGxvY2F0aW9uczoNCg0KwrcgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJl ci0wOS5wZGYNCg0KwrcgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wOS50eHQNCg0KwrcgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0w OS54bWwNCg0KwrcgICAgICAgICBodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWll dGYtb2F1dGgtdjItYmVhcmVyLTA5Lmh0bWwNCg0KwrcgICAgICAgICBodHRwOi8vc2VsZi1pc3N1 ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTA5LnBkZg0KDQrCtyAgICAg ICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFy ZXItMDkudHh0DQoNCsK3ICAgICAgICAgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFm dC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wOS54bWwNCg0KwrcgICAgICAgICBodHRwOi8vc2VsZi1p c3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLmh0bWwgKHdpbGwgcG9p bnQgdG8gbmV3IHZlcnNpb25zIGFzIHRoZXkgYXJlIHBvc3RlZCkNCg0KwrcgICAgICAgICBodHRw Oi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLnBkZiAo d2lsbCBwb2ludCB0byBuZXcgdmVyc2lvbnMgYXMgdGhleSBhcmUgcG9zdGVkKQ0KDQrCtyAgICAg ICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFy ZXIudHh0ICh3aWxsIHBvaW50IHRvIG5ldyB2ZXJzaW9ucyBhcyB0aGV5IGFyZSBwb3N0ZWQpDQoN CsK3ICAgICAgICAgaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLW9hdXRo LXYyLWJlYXJlci54bWwgKHdpbGwgcG9pbnQgdG8gbmV3IHZlcnNpb25zIGFzIHRoZXkgYXJlIHBv c3RlZCkNCg0KwrcgICAgICAgICBodHRwOi8vc3ZuLm9wZW5pZC5uZXQvcmVwb3Mvc3BlY2lmaWNh dGlvbnMvb2F1dGgvMi4wLyAoU3VidmVyc2lvbiByZXBvc2l0b3J5LCB3aXRoIGh0bWwsIHBkZiwg dHh0LCBhbmQgaHRtbCB2ZXJzaW9ucyBhdmFpbGFibGUpDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739435C1FD5E4TK5EX14MBXC285r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjEzOTIyNzI0MzA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yNjMyODEyMDAgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6MTkxMzI3MTg1MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6MzY5Mjc0OTg2IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8v c2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTA5Lmh0bWwi PkRyYWZ0IDA5PC9hPiBvZiB0aGUNCjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2Rv Y3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXIuaHRtbCI+T0F1dGggMi4wIEJlYXJlciBUb2tl biBTcGVjaWZpY2F0aW9uPC9hPiBoYXMgYmVlbiBwdWJsaXNoZWQsIHdoaWNoIGluY29ycG9yYXRl cyBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmZWVkYmFjay4mbmJzcDsgSXQgY29udGFpbnMgdGhl IGZvbGxvd2luZyBjaGFuZ2VzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlVzZSBkZWZpbml0aW9ucyBmcm9t IFtJPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+4oCRPC9z cGFuPkQuaWV0ZjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsi PuKAkTwvc3Bhbj5odHRwYmlzPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhp YyZxdW90OyI+4oCRPC9zcGFuPnA3PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdv dGhpYyZxdW90OyI+4oCRPC9zcGFuPmF1dGhdDQogcmF0aGVyIHRoYW4gW1JGQzI2MTddLiA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VXBkYXRlIGNyZWRlbnRpYWxzIGRlZmluaXRpb24g dG8gY29uZm9ybSB0byBbSTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMm cXVvdDsiPuKAkTwvc3Bhbj5ELmlldGY8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMg R290aGljJnF1b3Q7Ij7igJE8L3NwYW4+aHR0cGJpczxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuKAkTwvc3Bhbj5wNzxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuKAkTwvc3Bhbj5hdXRoXS4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT5GdXJ0aGVyIGNsYXJpZmllZCB0aGF0IHF1ZXJ5IHBhcmFtZXRlcnMg bWF5IG9jY3VyIGluIGFueSBvcmRlci4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1i b2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5T cGVjaWZ5IHRoYXQgZXJyb3JfZGVzY3JpcHRpb24gaXMgVVRGLTggZW5jb2RlZCAobWF0Y2hpbmcg dGhlIGNvcmUgc3BlY2lmaWNhdGlvbikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJv bCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlJl Z2lzdGVyZWQgJnF1b3Q7QmVhcmVyJnF1b3Q7IEF1dGhlbnRpY2F0aW9uIFNjaGVtZSBpbiBBdXRo ZW50aWNhdGlvbiBTY2hlbWUgUmVnaXN0cnkgZGVmaW5lZCBieSBbSTxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuKAkTwvc3Bhbj5ELmlldGY8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7igJE8L3NwYW4+aHR0cGJpczxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuKAkTwvc3Bhbj5w NzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuKAkTwvc3Bh bj5hdXRoXS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VXBkYXRlZCByZWZlcmVuY2Vz IHRvIG9hdXRoLXYyLCBodHRwYmlzLXAxLW1lc3NhZ2luZywgYW5kIGh0dHBiaXMtcDctYXV0aCBk cmFmdHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPk90aGVyIHdvcmRpbmcgaW1wcm92 ZW1lbnRzIG5vdCBpbnRyb2R1Y2luZyBub3JtYXRpdmUgY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBhdCB0aGVzZSBsb2NhdGlvbnM6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTA5LnBkZjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LW9hdXRoLXYyLWJlYXJlci0wOS50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBs Zm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9s Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+aHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFy ZXItMDkueG1sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPmh0dHA6Ly9zZWxmLWlzc3Vl ZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMDkuaHRtbDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWll dGYtb2F1dGgtdjItYmVhcmVyLTA5LnBkZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1i b2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5o dHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTA5 LnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5odHRwOi8vc2VsZi1pc3N1ZWQuaW5m by9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTA5LnhtbDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1 dGgtdjItYmVhcmVyLmh0bWwgKHdpbGwgcG9pbnQgdG8gbmV3IHZlcnNpb25zIGFzIHRoZXkgYXJl IHBvc3RlZCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+aHR0cDovL3NlbGYtaXNzdWVk LmluZm8vZG9jcy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci5wZGYgKHdpbGwgcG9pbnQgdG8g bmV3IHZlcnNpb25zIGFzIHRoZXkgYXJlIHBvc3RlZCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omwx IGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJl YXJlci50eHQgKHdpbGwgcG9pbnQgdG8gbmV3IHZlcnNpb25zIGFzIHRoZXkgYXJlIHBvc3RlZCk8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9j cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci54bWwgKHdpbGwgcG9pbnQgdG8gbmV3IHZlcnNp b25zIGFzIHRoZXkgYXJlIHBvc3RlZCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBs Zm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9s Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+aHR0 cDovL3N2bi5vcGVuaWQubmV0L3JlcG9zL3NwZWNpZmljYXRpb25zL29hdXRoLzIuMC8gKFN1YnZl cnNpb24gcmVwb3NpdG9yeSwgd2l0aCBodG1sLCBwZGYsIHR4dCwgYW5kIGh0bWwgdmVyc2lvbnMg YXZhaWxhYmxlKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739435C1FD5E4TK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Sep 23 17:09: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 8DCA521F8CC4 for ; Fri, 23 Sep 2011 17:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.120, 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 7afxEm3+UE5b for ; Fri, 23 Sep 2011 17:09:18 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id A766B21F8CB6 for ; Fri, 23 Sep 2011 17:09:18 -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, 23 Sep 2011 17:11:54 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.142]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0339.002; Fri, 23 Sep 2011 17:11:53 -0700 From: Mike Jones To: Peter Saint-Andre , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments Thread-Index: Acx6Tou493l7dscKSVmBOsgzVXPouQ== Date: Sat, 24 Sep 2011 00:11:53 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C1FD629@TK5EX14MBXC285.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.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C1FD629TK5EX14MBXC285r_" MIME-Version: 1.0 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: Sat, 24 Sep 2011 00:09:19 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C1FD629TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your comment, Peter. Done. Is there any estimated timeline for publication of the HTTPbis specs as RFC= s? -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= eter Saint-Andre Sent: Tuesday, August 09, 2011 11:58 AM To: Julian Reschke Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments 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 >=3D 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/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739435C1FD629TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your com= ment, Peter.  Done.

 

Is there any estima= ted timeline for publication of the HTTPbis specs as RFCs?

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

-----Original Message-= ----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= eter Saint-Andre
Sent: Tuesday, August 09, 2011 11:58 AM
To: Julian Reschke
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments<= o:p>

 

On 8/9/11 6:06 AM, Jul= ian Reschke wrote:

 

> 1.1.  Notati= onal Conventions

>

>   = ...

>

>    = ;This document uses the Augmented Backus-Naur Form (ABNF) notation of<= /o:p>

>   = [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 re= alm should come from I-D.ietf-httpbis-p7-auth

> (optimally from a= version >=3D 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 au= thors 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 bear= er token format spec...

 

Peter

 

--

Peter Saint-Andre=

https://stp= eter.im/

 

 

______________________= _________________________

OAuth mailing list

OAuth@iet= f.org

https://www.ietf.org/mailman/listinfo/oauth

 

--_000_4E1F6AAD24975D4BA5B16804296739435C1FD629TK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Sep 23 17:10: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 73E7B21F8C11 for ; Fri, 23 Sep 2011 17:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.117, 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 Kbu6o7rJ32w6 for ; Fri, 23 Sep 2011 17:10:22 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0AB21F8BF9 for ; Fri, 23 Sep 2011 17:10:22 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 23 Sep 2011 17:12:23 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.142]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0339.002; Fri, 23 Sep 2011 17:12:21 -0700 From: Mike Jones To: James H Manger , "oauth@ietf.org" Thread-Topic: draft-ietf-oauth-v2-bearer-08.txt WGLC comments Thread-Index: Acx6Tpeny1K/xh9MT/SOIxoZOJyoXQ== Date: Sat, 24 Sep 2011 00:12:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C1FD64E@TK5EX14MBXC285.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.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C1FD64ETK5EX14MBXC285r_" 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: Sat, 24 Sep 2011 00:10:25 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C1FD64ETK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your comments, James. Responses to them, which reflect the cont= ent of draft 09, follow inline. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Thursday, July 28, 2011 8:51 PM To: oauth@ietf.org 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.] I revised the abstract wording, per your suggestion. I also added the word= "Authorization" to the title so that it is exactly parallel with the core = OAuth 2.0 spec. This parallelism clearly tying the two specifications toge= ther is likely more important for adopters of the specification than includ= ing "HTTP Authentication" in the title. 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]. Thanks for pointing this out. I changed the credentials syntax to the foll= owing, which directly uses the syntax in draft-ietf-httpbis-p7-auth-16 (and= so invents no new syntax): credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) 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 N/A 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 \ The place to make syntax changes to the scope value is in the OAuth 2.0 cor= e spec - not the bearer token spec. No change made. 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. This comment does not include a specific recommendation for a change to the= spec, and so is not actionable. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739435C1FD64ETK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your commen= ts, James.  Responses to them, which reflect the content of draft 09, = follow inline.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

-----Original Message-= ----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H
Sent: Thursday, July 28, 2011 8:51 PM
To: oauth@ietf.org
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 thi= s is an HTTP 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 spec= ification describes how to use bearer tokens in

   HTTP requ= ests to access OAuth 2 protected resources."

 

[Personally, I wouldn'= t bother mentioning OAuth at all here, but others seem to want this context= restriction.]

 

I revised the abstract= wording, per your suggestion.  I also added the word “Authoriza= tion” to the title so that it is exactly parallel with the core OAuth= 2.0 spec.  This parallelism clearly tying the two specifications together is likely more important for adopters of the specification than i= ncluding “HTTP Authentication” in the title.<= /p>

 

2. The ABNF for <cr= edentials> 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 the more likely fixes proposed for HTTPbis [draft-ietf-httpbis-p7-auth].=

I expect HTTPbis to al= low a base64-like-blob consistently in Authorization and WWW-Authenticate h= eaders (to accommodate BASIC and NTLM). Multiple WWW-Authenticate headers c= an have their values combined, separated by commas. They can also have quoted-string parameters. To be able to pars= e this, requires disallowing commas and double-quotes from the base64-like-= blob (and hence from <access-token>) at a minimum; only allowing equa= ls at the end also helps.

The current approach i= n the 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= ) 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 someone's XML somewhere, for no benef= it).

 

Suggestion:

  access-tok= en =3D 1*( ALPHA / DIGIT / "-" / "." / "_" / = "~" / "+" / "/" ) *"=3D"

 

  <access-toke= n> includes the 66 unreserved URI characters plus a few others.

  It can hold a b= ase64, base64url (URL and filename safe alphabet),

  base32, or base= 16 (hex) encoding, with or without padding, but

  excluding white= space [RFC4648].

 

Thanks for pointing th= is out.  I changed the credentials syntax to the following, which dire= ctly uses the syntax in draft-ietf-httpbis-p7-auth-16 (and so invents no ne= w syntax):

  = ;  credentials =3D "Bearer" 1*SP ( b64token / #auth-param )<= o:p>

 

2b. If 2 is not accept= ed (and assuming HTTPbis will allow any content after the scheme name in a = Authorization header) can we please not misuse the <quoted-char> labe= l when no quoting is going on. The following is a better equivalent:

 

  access-token = =3D 1*(%x21-7E) ; ASCII, except controls, space, or delete

 

N/A<= /p>

 

3. Drop '\' from the a= llowed chars in a scope value, to avoid clashing with the HTTP quoted-strin= g escaping mechanism (and don't use the <quoted-char> label when no q= uoting is going on).

  scope-v =3D 1*(= %x21 / %x23-5B / %x5D-7E); excludes space and " and \

 

The place to make synt= ax changes to the scope value is in the OAuth 2.0 core spec – not the= bearer token spec.  No change made.

 

4. Section 3.3 "S= ummary of Recommendations" sensibly says clients "MUST ensure tha= t bearer tokens are not leaked to *unintended parties*" and correctly = notes that this is "the primary security consideration" that underlies all the others. So it is a glaring hole that OAuth2 fails t= o tell the client who the intended parties are when issuing a bearer token.=

 

This comment does not = include a specific recommendation for a change to the spec, and so is not a= ctionable.

 

--

James Manger

______________________= _________________________

OAuth mailing list

OAuth@iet= f.org

https://www.ietf.org/mailman/listinfo/oauth

 

--_000_4E1F6AAD24975D4BA5B16804296739435C1FD64ETK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Sep 23 17:10: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 8AFAA21F8564 for ; Fri, 23 Sep 2011 17:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.114, 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 Ktqinn74TfCh for ; Fri, 23 Sep 2011 17:10:34 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 32B3821F8CF1 for ; Fri, 23 Sep 2011 17:10:33 -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; Fri, 23 Sep 2011 17:13:08 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.142]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0339.002; Fri, 23 Sep 2011 17:13:07 -0700 From: Mike Jones To: Julian Reschke , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments Thread-Index: Acx6TrJmwcQz5MGcQbCm3dgw87x/xA== Date: Sat, 24 Sep 2011 00:13:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C1FD669@TK5EX14MBXC285.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.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C1FD669TK5EX14MBXC285r_" MIME-Version: 1.0 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: Sat, 24 Sep 2011 00:10:37 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C1FD669TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your comments, Julian. Responses to them, which reflect the con= tent of draft 09, follow inline. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Tuesday, August 09, 2011 5:07 AM To: OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments Hi there, below a few comments on dependencies to HTTPbis, and the actual header fiel= d 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 f= rom a version >=3D 16 which we should get out before the end of the month). Done 2. Authenticated Requests Clients SHOULD make authenticated requests with a bearer token using the "Authorization" request header field defined by [RFC2617]. -> HTTPbis P7 Done 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 =3D "Bearer" RWS access-token access-token =3D 1*( quoted-char / <"> ) quoted-char =3D ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" This is incompatible with the RFC2617 grammar which requires auth-params. HTTPbis P7 will introduce an alternative syntax ("b64token"), but that is r= estricted to a single instance and thus not extensible. I recommend to use auth-param syntax instead. Thanks for pointing this out. I changed the credentials syntax to the foll= owing, which directly uses the syntax in draft-ietf-httpbis-p7-auth-16 (and= so invents no new syntax): credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) 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? Is there specific language either allowing or ruling out parameters to the = content-type value that you believe would be appropriate? Can you provide = a concrete motivating example? 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. Changed sentence to "The HTTP request method is one for which the request b= ody has defined semantics", per your suggestion in a private thread. 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 Done challenge =3D "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. I have changed the RWS to 1*SP to match httpbis-p7-auth. I retained the "p= aram" definition so as to be able to clearly syntactically limit the accept= able set of parameters. param =3D realm / scope / error / error-desc / error-uri / auth-param scope =3D "scope" "=3D" <"> scope-v *( SP scope-v ) <"> scope-v =3D 1*quoted-char -> This seems to override the quoted-string syntax. Don't. Generic parsers *will* use the quoted-string syntax. quoted-char =3D ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" This issue is tracked as issue #26. The proposed resolution to this issue = is being discussed in a separate thread. error =3D "error" "=3D" quoted-string error-desc =3D "error_description" "=3D" quoted-string error-uri =3D "error_uri" "=3D" <"> URI-reference <"> -> missing I18N considerations The draft now contains: "the resource server MAY include the error_descrip= tion attribute to provide developers a UTF-8 encoded human-readable explana= tion". (The UTF-8 language now matches the core spec.) There was an explicit working decision not to include language codes. This= is recorded in the meeting minutes sent to the list by Hannes Tschofenig o= n 6/3/11. The key part of the minutes is: *** Error Description *** Agreement among the participants that the error codes are m= eant for consumption by the developer rather than the end user. Hence, lang= uage codes are not important nor a human readable version that is supposed = to be understood by end users. -> weird syntax (why underscore?) The OAuth specs have always used underscores to separate words in protocol = messages. -> the generic syntax allows token in addition to quoted-string; it's pointless to rule that out here The reply syntax is intentionally restricted to simplify implementations. 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. Done --_000_4E1F6AAD24975D4BA5B16804296739435C1FD669TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your commen= ts, Julian.  Responses to them, which reflect the content of draft 09,= follow inline.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

-----Original Message-= ----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke
Sent: Tuesday, August 09, 2011 5:07 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments=

 

Hi there,

 

below a few comments o= n dependencies to HTTPbis, and the actual header field syntax.

 

Best regards,

 

Julian

 

-- snip --<= /p>

 

1.1.  Notational = Conventions

 

    ...=

 

    Thi= s document uses the Augmented Backus-Naur Form (ABNF) notation of

    [I-= D.ietf-httpbis-p1-messaging], which is based upon the Augmented<= /p>

    Bac= kus-Naur Form (ABNF) notation of [RFC5234].  Additionally, the

    fol= lowing rules are included from [RFC2617]: auth-param and realm;<= /p>

    fro= m [RFC3986]: URI-Reference; and from

    [I-= D.ietf-httpbis-p1-messaging]: RWS and quoted-string.

 

auth-param and realm s= hould come from I-D.ietf-httpbis-p7-auth (optimally from a version >=3D = 16 which we should get out before the end of the month).

 

Done=

 

2.  Authenticated= Requests

 

    Cli= ents SHOULD make authenticated requests with a bearer token using

    the= "Authorization" request header field defined by [RFC2617].<= /o:p>

 

-> HTTPbis P7<= /o:p>

 

Done=

 

2.1.  The Authori= zation Request Header Field

 

    The= "Authorization" request header field is used by clients to make<= o:p>

    aut= henticated requests with bearer tokens.  The client uses the

    &qu= ot;Bearer" authentication scheme to transmit the access token in the

    req= uest.

 

    For= example:

 

    GET= /resource HTTP/1.1

    Hos= t: server.example.com

    Aut= horization: Bearer vF9dft4qmT

 

    The= "Authorization" header field uses the framework defined by<= /o:p>

    [RF= C2617] as follows:

 

    cre= dentials     =3D "Bearer" RWS access-token

    acc= ess-token    =3D 1*( quoted-char / <"> )

 

    quo= ted-char     =3D ALPHA / DIGIT /

   &nbs= p;            &= nbsp;     "!" / "#" / "$"= / "%" / "&" / "'" / "(" / &quo= t;)" /

   &nbs= p;            &= nbsp;     "*" / "+" / "-&q= uot; / "." / "/" / ":" / "<" / &= quot;=3D" /

   &nbs= p;            &= nbsp;     ">" / "?" / "@&qu= ot; / "[" / "]" / "^" / "_" / "= ;`" /

   &nbs= p;            &= nbsp;     "{" / "|" / "}"= / "~" / "\" / "," / ";"=

 

This is incompatible w= ith the RFC2617 grammar which requires auth-params.

 

HTTPbis P7 will introd= uce an alternative syntax ("b64token"), but that is restricted to= a single instance and thus not extensible.

 

I recommend to use aut= h-param syntax instead.

 

Thanks for pointing th= is out.  I changed the credentials syntax to the following, which dire= ctly uses the syntax in draft-ietf-httpbis-p7-auth-16 (and so invents no ne= w syntax):

  = ;  credentials =3D "Bearer" 1*SP ( b64token / #auth-param )<= o:p>

 

2.2.  Form-Encode= d Body Parameter

 

    ...=

 

    o&n= bsp; The entity-body follows the encoding requirements of the

   &nbs= p;   "application/x-www-form-urlencoded" content-type a= s defined by

   &nbs= p;   [W3C.REC-html401-19991224].

 

    o&n= bsp; The HTTP request entity-header includes the "Content-Type" h= eader

   &nbs= p;   field set to "application/x-www-form-urlencoded".<= o:p>

 

What about parameters?=

 

Is there specific lang= uage either allowing or ruling out parameters to the content-type value tha= t you believe would be appropriate?  Can you provide a concrete motiva= ting example?

 

    o&n= bsp; The HTTP request method is one for which a body is permitted to be

   &nbs= p;   present in the request.  In particular, this means that= the "GET"

   &nbs= p;   method MUST NOT be used.

 

GET permits a body; it= 's just not useful.

 

Changed sentence to &#= 8220;The HTTP request method is one for which the request body has defined = semantics”, per your suggestion in a private thread.

 

2.4.  The WWW-Aut= henticate Response Header Field

 

    If = the protected resource request does not include authentication

    cre= dentials 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

    &qu= ot;WWW-Authenticate" header field uses the framework defined by

    [RF= C2617] as follows:

 

-> HTTPbis P7<= /o:p>

 

Done=

 

    cha= llenge       =3D "Bearer" [ RWS 1#p= aram ]

 

-> please stick to = the syntax defined in the authentication framework,

so use "auth-para= m", and just define the allowed parameters separately.

 

I have changed the RWS= to 1*SP to match httpbis-p7-auth.  I retained the “param”= definition so as to be able to clearly syntactically limit the acceptable = set of parameters.

 

    par= am           =3D realm / = scope /

   &nbs= p;            &= nbsp;     error / error-desc / error-uri /

   &nbs= p;            &= nbsp;     auth-param

 

    sco= pe           =3D "sc= ope" "=3D" <"> scope-v *( SP scope-v ) <"= >

    sco= pe-v         =3D 1*quoted-char=

 

-> This seems to ov= erride the quoted-string syntax. Don't. Generic

parsers *will* use the= quoted-string syntax.

 

    quo= ted-char     =3D ALPHA / DIGIT /

   &nbs= p;             =      "!" / "#" / "$"= / "%" / "&" / "'" / "(" / &quo= t;)" /

   &nbs= p;            &= nbsp;     "*" / "+" / "-&q= uot; / "." / "/" / ":" / "<" / &= quot;=3D" /

   &nbs= p;            &= nbsp;     ">" / "?" / "@&qu= ot; / "[" / "]" / "^" / "_" / "= ;`" /

   &nbs= p;            &= nbsp;     "{" / "|" / "}"= / "~" / "\" / "," / ";"=

 

This issue is tracked = as issue #26.  The proposed resolution to this issue is being discusse= d in a separate thread.

 

    err= or           =3D "er= ror" "=3D" quoted-string

    err= or-desc      =3D "error_description" &qu= ot;=3D" quoted-string

    err= or-uri       =3D "error_uri" "= =3D" <"> URI-reference <">

 

-> missing I18N con= siderations

 

The draft now contains= : "the resource server MAY  include the error_description attribu= te to provide developers a UTF-8 encoded human-readable explanation".&= nbsp; (The UTF-8 language now matches the core spec.)

 

There was an explicit = working decision not to include language codes.  This is recorded in t= he meeting minutes sent to the list by Hannes Tschofenig on 6/3/11.  T= he key part of the minutes is:

   &nbs= p;            *** Er= ror Description ***

 

   &nbs= p;            Agreem= ent among the participants that the error codes are meant for consumption b= y the developer rather than the end user. Hence, language codes are not imp= ortant nor a human readable version that is supposed to be understood by end users.

 

-> weird syntax (wh= y underscore?)

 

The OAuth specs have a= lways used underscores to separate words in protocol messages.

 

-> the generic synt= ax allows token in addition to quoted-string; it's

pointless to rule that= out here

 

The reply syntax is in= tentionally restricted to simplify implementations.

 

4.  IANA Consider= ations

 

-> If you have a de= pendency on HTTPbis then you should also add the

registration for the a= uthentication scheme as defined in HTTPbis P7.

 

Done=

 

--_000_4E1F6AAD24975D4BA5B16804296739435C1FD669TK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Fri Sep 23 17:11: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 36AC421F8CEB for ; Fri, 23 Sep 2011 17:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.110, 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 RLViZ4jHPgMU for ; Fri, 23 Sep 2011 17:11:01 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 1987D21F8CD5 for ; Fri, 23 Sep 2011 17:11:01 -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; Fri, 23 Sep 2011 17:13:36 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.142]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0339.002; Fri, 23 Sep 2011 17:13:36 -0700 From: Mike Jones To: Yaron Goland , "oauth@ietf.org" Thread-Topic: Last call comments on bearer draft 08 from Yaron Goland Thread-Index: Acx6TsZdh7K8dsRlTYacfDLcY2+2Dg== Date: Sat, 24 Sep 2011 00:13:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C1FD686@TK5EX14MBXC285.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.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C1FD686TK5EX14MBXC285r_" MIME-Version: 1.0 Subject: Re: [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: Sat, 24 Sep 2011 00:11:05 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C1FD686TK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your comments, Yaron. Responses to them, which reflect the cont= ent of draft 09, follow inline. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Wednesday, August 10, 2011 2:39 PM To: oauth@ietf.org Subject: [OAUTH-WG] Last call comments on bearer draft 08 from Yaron Goland 1. Introduction: Adding the word "directly" after "rather than using the = resource owner's credentials". Done 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." Added the sentence: "In some cases, a client can directly present its own = credentials to an authorization server to obtain an access token without ha= ving to first obtain an access grant from a resource owner." and also quali= fied the phrase "Before a client can access a protect resource" by prefixin= g it with the words "In the general case,". 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." Added the sentence: "Use of this specification also requires that the acce= ss token returned in step (D) must be a Bearer token." 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." Not done, in the interest of brevity. 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?" Clarified the text and example to make it clear that order doesn't matter. 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." I've changed this language to "If the protected resource request does not i= nclude authentication credentials or does not contain an access token that = enables access to the protected resource, the resource server MUST include = ...". I decided not to pare it down to the degree you suggested, as I beli= eve that there is value to developers in explaining the conditions under wh= ich a WWW-Authenticate response would be used. 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." As the bearer token spec has included these features since its inception, a= nd since removing or changing these features would be a breaking change, I = have not made this change. 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". I've changed this to: "An attacker uses a token generated for consumption b= y a particular resource server to gain access to a different resource serve= r that mistakenly 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". Given that the replay attack is defined in NIST Special Publication 800-63,= I am reluctant to change this attack description from "token replay" to "t= oken capture". 3.2 Threat Mitigation: Add at end of first paragraph: "The mechanics of s= uch an interaction are not defined by this specification." Done 3.2. Threat Mitigation: Delete "and replay" from paragraph 5. Not done, as it is related to the change not made in 3.1. 3.2. Threat Mitigation: Change "has to be" to "MUST". Done 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." Done 3.3. Summary of Recommendations: Validate SSL certificate chains: Change "m= ust" to "MUST". Done 3.3. Summary of Recommendations: Always use TLS (https): Add "or equivalen= t transport security" after TLS reference. Done 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." Done 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." It's not clear where this would fit into the flow of 3.2, so I've let the d= escription stand as-is in 3.3. Appendix A. Acknowledgements: Change "Yaron Goland" to "Yaron Y. Goland". Done --_000_4E1F6AAD24975D4BA5B16804296739435C1FD686TK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your commen= ts, Yaron.  Responses to them, which reflect the content of draft 09, = follow inline.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Wednesday, August 10, 2011 2:39 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Last call comments on bearer draft 08 from Yaron= Goland

 

1.  Introduction:&nb= sp; Adding the word “directly” after “rather than using t= he resource owner's credentials”.

 

Done=

 

1.3. Overview:  Comm= ent on first sentence:  “OAuth also supports having a client dir= ectly provide its own credentials to get an access token. It would seem use= ful to refer to this as well less the reader think that OAuth is only for delegation. That was true with OAuth 1.0 but not 2.0.= 221;

 

Added the sentence:&nb= sp; “In some cases, a client can directly present its own credentials= to an authorization server to obtain an access token without having to fir= st obtain an access grant from a resource owner.” and also qualified the phrase “Before a client can access a protect = resource” by prefixing it with the words “In the general case,&= #8221;.

 

1.3. Overview, paragraph = 3:  Commented on “The following steps are specified within this = document”: “Actually you also specify the token type returned i= n step D. I think this is worth explicitly calling out.”

 

Added the sentence:&nb= sp; “Use of this specification also requires that the access token re= turned in step (D) must be a Bearer token.”

 

2.  Authenticated Re= quests:  Commented “It would seem appropriate to begin with an e= xample of step D showing that the returned access token is of type bearer.&= #8221;

 

Not done, in the inter= est of brevity.

 

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 because order is = irrelevant?”

 

Clarified the text and= example to make it clear that order doesn’t matter.

 

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 Ba= d Request and would not require a www-authenticate response header field. Or invalid= can mean ‘supported but not the right credentials’ in which ca= se the error is a 401 Unauthorized and a www-authenticate response is requi= red.  I would urge you to consider simplifying this text by just stating (without preamble) that if a www-authenticate re= sponse header is returned (either from a 401 Unauthorized or other reasons)= then support for the Bearer token type is specified as given below.”=

 

I’ve changed thi= s language to “If the protected resource request does not include aut= hentication credentials or does not contain an access token that enables ac= cess to the protected resource, the resource server MUST include …”.  I decided not to pare it down to the de= gree you suggested, as I believe that there is value to developers in expla= ining the conditions under which a WWW-Authenticate response would be used.=

 

2.4. The WWW-Authenticate= Response Header Field:  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>

 

As the bearer token sp= ec has included these features since its inception, and since removing or c= hanging these features would be a breaking change, I have not made this cha= nge.

 

3.1. Security Threats: To= ken redirect: Change “An attacker uses the token generated for consum= ption 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 mist= akenly believes the token to be for it”.

 

I’ve changed thi= s to: “An attacker uses a token generated for consumption by a partic= ular resource server to gain access to a different resource server that mis= takenly believes the token to be for it.”

 

3.1 Security Threads: Tok= en replay:  Change “replay” to “capture” and c= hange “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 protecte= d resources”.

 

Given that the replay = attack is defined in NIST Special Publication 800-63, I am reluctant to cha= nge this attack description from “token replay” to “token= capture”.

 

3.2 Threat Mitigation:&nb= sp; Add at end of first paragraph:  “The mechanics of such an in= teraction are not defined by this specification.”

 

Done=

 

3.2. Threat Mitigation:&n= bsp; Delete “and replay” from paragraph 5.

 

Not done, as it is rel= ated to the change not made in 3.1.

 

3.2. Threat Mitigation:&n= bsp; Change “has to be” to “MUST”.

 

Done=

 

3.2. Threat Mitigation:&n= bsp; Comment on “leaked” in paragraph 5:  “Significa= ntly? Really? In what way? Give me a token for a few hundred milliseconds a= nd 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.&= #8221;

 

Done=

 

3.3. Summary of Recommend= ations: Validate SSL certificate chains: Change “must” to ̶= 0;MUST”.

 

Done=

 

3.3. Summary of Recommend= ations: Always use TLS (https):  Add “or equivalent transport se= curity” after TLS reference.

 

Done=

 

3.3. Summary of Recommend= ations: Don't store bearer tokens in cookies:  Add sentence at end: &#= 8220;Implementations that do store bearer tokens in cookies MUST take preca= utions against cross site request forgery.”

 

Done=

 

3.3. Summary of Recommend= ations:  Comment on “Don't pass bearer tokens in page URLs”= ;: “It seems like this should also be mentioned in section 3.2.”= ;

 

It’s not clear w= here this would fit into the flow of 3.2, so I’ve let the description= stand as-is in 3.3.

 

Appendix A.  Acknowl= edgements:  Change “Yaron Goland” to “Yaron Y. Golan= d”.

 

Done=

 

--_000_4E1F6AAD24975D4BA5B16804296739435C1FD686TK5EX14MBXC285r_-- From julian.reschke@gmx.de Sat Sep 24 05:04: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 00B0C21F8B27 for ; Sat, 24 Sep 2011 05:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.134 X-Spam-Level: X-Spam-Status: No, score=-104.134 tagged_above=-999 required=5 tests=[AWL=-1.535, 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 rASF83BunliW for ; Sat, 24 Sep 2011 05:04:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CEDCE21F8B1F for ; Sat, 24 Sep 2011 05:04:21 -0700 (PDT) Received: (qmail invoked by alias); 24 Sep 2011 12:06:57 -0000 Received: from p508FC504.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.197.4] by mail.gmx.net (mp055) with SMTP; 24 Sep 2011 14:06:57 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+YSah39LWYnQNw/LpRF8T0+l9s47apolzj0phgNg eIkTUwa1Cgt7Ro Message-ID: <4E7DC7DD.5010407@gmx.de> Date: Sat, 24 Sep 2011 14:06:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C1FD669@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C1FD669@TK5EX14MBXC285.redmond.corp.microsoft.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 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: Sat, 24 Sep 2011 12:04:23 -0000 On 2011-09-24 02:13, Mike Jones wrote: > Thanks for your comments, Julian. Responses to them, which reflect the > content of draft 09, follow inline. Thanks! > ... > 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. > > Thanks for pointing this out. I changed the credentials syntax to the > following, which directly uses the syntax in > draft-ietf-httpbis-p7-auth-16 (and so invents no new syntax): > > credentials = "Bearer" 1*SP ( b64token / #auth-param ) The b64token is always there, right? So you won't be able to use additional parameters, and thus the syntax is effectively credentials = "Bearer" 1*SP b64token Is that intended and acceptable? > 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? > > Is there specific language either allowing or ruling out parameters to > the content-type value that you believe would be appropriate? Can you > provide a concrete motivating example? The text as currently written makes it impossible to add parameters to the type. However, the rule of thumb for unknown media type parameters is to ignore them, not to reject them. Maybe: "The HTTP Content-Type" header field indicates a media type of "application/x-www-form-urlencoded"." > ... > 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. > > I have changed the RWS to 1*SP to match httpbis-p7-auth. I retained the > “param” definition so as to be able to clearly syntactically limit the > acceptable set of parameters. But the acceptable set of parameters is open-ended anyway, right? > 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 / > > "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / > > "*" / "+" / "-" / "." / "/" / ":" / "<" / "=" / > > ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / > > "{" / "|" / "}" / "~" / "\" / "," / ";" > > This issue is tracked as issue #26. The proposed resolution to this > issue is being discussed in a separate thread. OK. > error = "error" "=" quoted-string > > error-desc = "error_description" "=" quoted-string > > error-uri = "error_uri" "=" <"> URI-reference <"> > > -> missing I18N considerations > > The draft now contains: "the resource server MAY include the > error_description attribute to provide developers a UTF-8 encoded > human-readable explanation". (The UTF-8 language now matches the core > spec.) UTF-8 is uncommon in HTTP header fields. It's not strictly forbidden, but most code I've seen assumes ISO-8859-1 (see, for instance, XHR or Java servlet API). You *can* use UTF-8, but may encounter strange problems caused by software components in between. > There was an explicit working decision not to include language codes. I didn't ask for language codes :-) > This is recorded in the meeting minutes sent to the list by Hannes > Tschofenig on 6/3/11. The key part of the minutes is: > > *** Error Description *** > > Agreement among the participants that the error codes are meant for > consumption by the developer rather than the end user. Hence, language > codes are not important nor a human readable version that is supposed to > be understood by end users. In which case I recommend to stick to plain ASCII. > -> weird syntax (why underscore?) > > The OAuth specs have always used underscores to separate words in > protocol messages. Well, it looks strange in an HTTP message. > -> the generic syntax allows token in addition to quoted-string; it's > > pointless to rule that out here > > The reply syntax is intentionally restricted to simplify implementations. Special-casing the syntax *complicates* implementations. Using common constructs allows re-using existing parsing code and thus make things easier. Consider a browser seeing the credentials. It needs to parse the field value for multiple challenges, and the only way for this to work is to have predictable syntax for parameters. > 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. > > Done Thanks. Now that you have switched to HTTPbis you probably can get rid of the reference to RFC 2617. Best regards, Julian From barryleiba.mailing.lists@gmail.com Sat Sep 24 06:30: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 8C2B321F8B1D for ; Sat, 24 Sep 2011 06:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 RyMJ+97uGJfd for ; Sat, 24 Sep 2011 06:30:30 -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 E59EC21F8B1A for ; Sat, 24 Sep 2011 06:30:29 -0700 (PDT) Received: by yxt33 with SMTP id 33so4086778yxt.31 for ; Sat, 24 Sep 2011 06:33: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:cc:content-type; bh=wyWiHBzIxv95m86To1HwH/b4GdVI2zQ3+8Jd/u/34xQ=; b=hp2F7e367fOiM34fpaATsgw293+0iOR92MrisIjaBiJxlPZupk9NaGCtigj+qxjq/r SWLK7s6Paxq+SZaPwm4TOvQVihwDsEmlqmaKxcdNH6nJiXCI0nRuVuINQ2gRYl0crn1t oUpl7SsEUaaJYxFUhWOxDo0gOe+GlkOVCbXXM= MIME-Version: 1.0 Received: by 10.236.185.228 with SMTP id u64mr28334231yhm.91.1316871186845; Sat, 24 Sep 2011 06:33:06 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Sat, 24 Sep 2011 06:33:06 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Sat, 24 Sep 2011 09:33:06 -0400 X-Google-Sender-Auth: 4qJ5GVOv3tBqB8vu4myAXhWthYM Message-ID: From: Barry Leiba To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 24 Sep 2011 13:30:30 -0000 > My proposed resolution is that %-encoding not be required in the > specification I agree with your analysis, now that I see it laid out clearly. I would feel better, though, if there were text in the document that explained that to others, who read it later. Perhaps, using your words, we could make this change to section 2.4: OLD The "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. The "scope" attribute MUST NOT appear more than once. NEW The "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. The "scope" attribute MUST NOT appear more than once. Interpretation of scope strings requires semantic agreement on the meaning of the scope strings between the parties participating the OAuth flow. Should an encoding be used for scope strings in a particular deployment context, participants have to have agreed upon that encoding, just as they agree on other OAuth configuration parameters. Does that work? Barry From James.H.Manger@team.telstra.com Sat Sep 24 07:38: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 0AE8821F8AF0 for ; Sat, 24 Sep 2011 07:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=-2.238, 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 Hzkhz9fsTP5E for ; Sat, 24 Sep 2011 07:38:16 -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 CDC0F21F8AEC for ; Sat, 24 Sep 2011 07:38:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,435,1312120800"; d="scan'208";a="46501327" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 25 Sep 2011 00:40:47 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6478"; a="37673651" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdvi.tcif.telstra.com.au with ESMTP; 25 Sep 2011 00:40:46 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Sun, 25 Sep 2011 00:40:47 +1000 From: "Manger, James H" To: Mike Jones , "oauth@ietf.org" Date: Sun, 25 Sep 2011 00:40:44 +1000 Thread-Topic: Proposed resolution for issue 26 Thread-Index: Acx5+RoYuC5sLQs0Spy/pi+T441Q9AAxktNw Message-ID: <255B9BB34FB7D647A506DC292726F6E1128E5D883D@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 24 Sep 2011 14:38:17 -0000 > From: Mike Jones > > Issue #26 http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 asks whether= the semantics of scope strings should be changed to require that the % cha= racter be interpreted as introducing a percent-encoded character that follo= ws.=A0 My proposed resolution is that %-encoding not be required in the spe= cification; therefore no textual change would be made to the specification = in response to this issue.=A0 The reasoning behind this resolution is as fo= llows: I disagree. This does not resolve the ambiguity. I think there is some conf= usion between 1) the internal structure (eg encoding) of a scope string, an= d 2) escaping done when transporting the scope string in a protocol element= . > 1.=A0 Interpretation of scope strings already requires semantic agreement= on the meaning of the scope strings between the parties participating the = OAuth flow.=A0 Should an encoding be used for scope strings in a particular= ly deployment context, it is reasonable for participants to have agreed upo= n that encoding, just as they agree on other OAuth configuration parameters= . A client app does NOT always need semantic agreement on the meaning of scop= e strings. Consider a client app that makes a request to a server and gets a 401 respo= nse with 'WWW-Authenticate: Bearer ... scope=3D"XXXXX"'. The client app now= knows it can run an OAuth exchange to get the required permission to retry= the request, and it should ask for the given scope during that OAuth excha= nge. The client app needs to copy XXXXXX from the response header into an OAuth = exchange. It does not need to know anything more "semantics" about this sco= pe value. XXXXXXX can be opaque to the client app. The client app does need= to know any decode/encode steps involved in transferring this HTTP Bearer = response value to an OAuth exchange value. If "XXXXXXX" is "1%2A2", should the client app redirect the user to https://example.org/authz?scope=3D1%2A2&... or https://example.org/authz?scope=3D1%252A2&... (or can the answer vary between different servers!!) > 2.=A0 More than one encoding methodology could reasonably be employed in = scope strings.=A0 For instance, base64url encoding of scope values could be= used in some contexts.=A0 Quoting characters with '\' is another possibili= ty.=A0 I see no compelling reason to mandate %-encoding over other potentia= l encoding methods. Servers can choose any encoding they want (including none) when defining th= eir own scope values (as logical Unicode strings). That is a separate choice to the encoding that is used in the HTTP Bearer r= esponse header when transporting a scope value. > 3.=A0 Mandating %-encoding unnecessarily complicates implementations with= out providing a clear compensating benefit sufficient warrant the additiona= l complexity.=A0 For example, it seems unnecessary to mandate that the scop= e strings "email" and "%65mail" MUST compare as being equal in all implemen= tations. When the scope string "email" is transported in JSON the receiver MUST comp= are "\u0065mail" as equal. When it is transported as a URI query parameter = the receiver MUST compare "%65mail" as equal. This is normal JSON and query= parameter processing. > 4.=A0 If an encoding methodology for scope strings is mandated, this shou= ld be done in the OAuth Core specification - not the OAuth Bearer Token spe= cification. The core spec implies that a scope value can consist of any Unicode charact= ers except space. The core spec transports scope values in JSON or url-encoded fields that ha= ve well-defined escaping mechanisms that are sufficient to handle all Unico= de string, hence all possible scope values. The Bearer spec transports scope values in an HTTP response header paramete= r. It defines no escaping mechanism so it cannot handle all Unicode strings= (ie it cannot handle all scope values that are possible in core). It is strange for the Bearer spec to restrict scope values. It should leave= that to the core. Hence the Bearer spec should be able to transport any sc= ope value allowed in the core (ie any Unicode string). Hence an escaping me= chanism needs to be specified for the HTTP response header scope field.=20 > 5.=A0 I am aware of no existing practice that utilizes %-encoding of scop= e values. Then a solution that avoids defining an escaping mechanism might work. It r= equires the Bearer spec to explicitly say "The Bearer mechanism only works = with scope values that are limited to these ~90 ASCII characters (that can = be transported in an HTTP response header field without an escaping mechani= sm), which is more restrictive than OAuth core". Or better still if you lik= e this approach, apply this restriction in core to all scope values. -- James Manger From James.H.Manger@team.telstra.com Sat Sep 24 08:01: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 9D6D521F8AB8 for ; Sat, 24 Sep 2011 08:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-2.079, 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 Gfz0tqMsIBbp for ; Sat, 24 Sep 2011 08:01:31 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABCC21F8AF5 for ; Sat, 24 Sep 2011 08:01:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,435,1312120800"; d="scan'208,217";a="46538185" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 25 Sep 2011 01:04:07 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6478"; a="38275086" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcani.tcif.telstra.com.au with ESMTP; 25 Sep 2011 01:04:07 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Sun, 25 Sep 2011 01:04:05 +1000 From: "Manger, James H" To: Mike Jones , "oauth@ietf.org" Date: Sun, 25 Sep 2011 01:04:03 +1000 Thread-Topic: Bearer token credentials syntax Thread-Index: Acx5+SDF4XDgMhWhRvqJf4Zf4AdI8AAz5M0A Message-ID: <255B9BB34FB7D647A506DC292726F6E1128E5D883F@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FC6B7@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C1FC6B7@TK5EX14MBXC285.redmond.corp.microsoft.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_255B9BB34FB7D647A506DC292726F6E1128E5D883FWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bearer token credentials syntax 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, 24 Sep 2011 15:01:32 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1128E5D883FWSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -1 credentials =3D "Bearer" 1*SP b64token would make sense. credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) does not make sense as the spec doesn't define a way to carry the bearer to= ken in the #auth-param choice. -- James Manger From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Saturday, 24 September 2011 12:00 AM To: oauth@ietf.org Subject: [OAUTH-WG] Bearer token credentials syntax James Manger and others pointed out that the current credentials syntax doe= s not comply with RFC 2617, nor does it match the updated credentials synta= x contained in HTTPbis, part 7: Authentication. The current syntax in the bearer token draf= t is: credentials =3D "Bearer" RWS access-token access-token =3D 1*( quoted-char / <"> ) quoted-char =3D ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / "\" / "," / ";" The syntax in HTTPbis is: credentials =3D auth-scheme [ 1*SP ( b64token / #auth-param ) ] (Note that some of the BNF elements used by part 7 are defined in HTTPbis, = part 1: Messaging.) To resolve this comment, I plan to change the Bearer Token draft to use thi= s syntax for credentials, matching HTTPbis: credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) Are people good with this approach? Thanks, -- Mike --_000_255B9BB34FB7D647A506DC292726F6E1128E5D883FWSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

-1

 

   credentials =3D "Bearer" 1*SP = b64token

would make sense.

 

   credentials =3D "Bearer"= ; 1*SP ( b64token / #auth-param )

does not make sense as the spec doesn’= t define a way to carry the bearer token in the #auth-param choice.

 = ;

&= nbsp;

--

James Manger

 

From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike Jones
Sent: Saturday, 2= 4 September 2011 12:00 AM
To: oauth@ietf.org
Subject: [= OAUTH-WG] Bearer token credentials syntax

=

 

James Manger and others pointed out that the current credentials s= yntax does not comply with RFC 2617, nor does it match the updated credenti= als syntax contained in HTTPbis, part 7: Authentication.  The current sy= ntax in the bearer token draft is:

   credentials   &nbs= p; =3D "Bearer" RWS access-token

   access-token  = ;  =3D 1*( quoted-char / <"> )

 

   quoted-char&nb= sp;    =3D ALPHA / DIGIT /

      &= nbsp;           &nbs= p;  "!" / "#" / "$" / "%" / &q= uot;&" / "'" / "(" / ")" /

  &= nbsp;           &nbs= p;      "*" / "+" / "-&qu= ot; / "." / "/" / ":" / "<" / &q= uot;=3D" /

          &nb= sp;          ">" = / "?" / "@" / "[" / "]" / "^&q= uot; / "_" / "`" /

      &nbs= p;            &= nbsp; "{" / "|" / "}" / "~" / "= ;\" / "," / ";"

 

The syntax in HTTPbis is:=

    cr= edentials =3D auth-scheme [ 1*SP ( b64token / #auth-param ) ]

 

(Note that some of the BNF element= s used by part 7 are defined in HTTPbis, part 1: Messaging.)<= /span>

 <= /p>

To resolve this comment, I plan = to change the Bearer Token draft to use this syntax for credentials, matchi= ng HTTPbis:

   credentials =3D "Bearer" 1*SP ( b64toke= n / #auth-param )

 

Are= people good with this approach?

=  

          &nb= sp;            =             &nb= sp;            =             &nb= sp;   Thanks,

           = ;            &n= bsp;            = ;            &n= bsp;            = ;   -- Mike

 

= --_000_255B9BB34FB7D647A506DC292726F6E1128E5D883FWSMSG3153Vsrv_-- From stephen.farrell@cs.tcd.ie Sat Sep 24 09:19: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 23A4321F8B55 for ; Sat, 24 Sep 2011 09:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 rw14n6waT8UB for ; Sat, 24 Sep 2011 09:19:41 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0483721F8A91 for ; Sat, 24 Sep 2011 09:19:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 26DEC171C5B for ; Sat, 24 Sep 2011 17:22:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1316881332; bh=JJu6njNeIMcp9IE+gREoHxTU ZSBpXAhBqhAB5DI2m6o=; b=Oybs9787Yhe2PqW0GA1uwwIqcM6A0sy+a/laVpQM Jdw7N04DcZuEr+dZq6gyyrSQs3N9oUOXNrMQ8ZRI3WKkkD6wcxJzSx7DfuJexbRH KrzfNGBi2/pfYiwjWOU3KB8ZNq8NTabbAIHTEz4pYsmzkxGYhTn5OL5NP/ZqBmQz u0ac0WxEwy7W0oVTyKQSpnZFmfIx6lSBFySD5DtPuy2P/0lh3pf9In954lvNstqe dDCg+Ptihj4ds5M1CpGLydpKZ6REmrHhg6ObJSiAcy3+qhmZ8/AP0/4XFzaP6CfL PD5NQVYmFGcRepz4Nx3cZBlnhuh8KFaBebdj1Vp3a/f2qg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id pNTQXubdQFY3 for ; Sat, 24 Sep 2011 17:22:12 +0100 (IST) Received: from [10.87.48.6] (unknown [86.41.7.145]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BC614171C04 for ; Sat, 24 Sep 2011 17:22:12 +0100 (IST) Message-ID: <4E7E03B4.4000404@cs.tcd.ie> Date: Sat, 24 Sep 2011 17:22:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "oauth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] Chairing change 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, 24 Sep 2011 16:19:42 -0000 Hi all, Now that you've broken the back of the work on oauth 2.0 and before we get into re-chartering discussions, I think its a good time to make any chairing changes that are needed. For a while now, Blaine hasn't really had the required cycles or e.g. travel support to chair an IETF group and so it makes sense to regularise that situation so that we have chairs with sufficient time for the upcoming re-chartering discussion. So Blaine has agreed to step down as oauth co-chair. Barry and Hannes will continue as before. I'm sure you'll all join me in thanking Blaine for all his excellent work in bringing oauth into and getting it (almost) through the IETF process. Regards, Stephen. From leifj@mnt.se Mon Sep 26 00:35: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 DDCE221F8AF7 for ; Mon, 26 Sep 2011 00:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.625, 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 hxGnv3EeCZ7a for ; Mon, 26 Sep 2011 00:35:04 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id A64F121F8AF2 for ; Mon, 26 Sep 2011 00:35:03 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p8Q7bgmi003580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Sep 2011 09:37:45 +0200 (CEST) Message-ID: <4E802BC6.5010405@mnt.se> Date: Mon, 26 Sep 2011 09:37:42 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: oauth@ietf.org References: <4E7E03B4.4000404@cs.tcd.ie> In-Reply-To: <4E7E03B4.4000404@cs.tcd.ie> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Chairing change 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, 26 Sep 2011 07:35:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'm sure you'll all join me in thanking Blaine for all his > excellent work in bringing oauth into and getting it (almost) > through the IETF process. Thanks Blaine! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6AK8YACgkQ8Jx8FtbMZneEUACgxrWJP5Lnyzcmyzg6EXUR71El NbgAoJqzlrTY0HQ7GgktVfvKx7r8SlDx =Ak0F -----END PGP SIGNATURE----- From Michael.Jones@microsoft.com Mon Sep 26 12:00: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 7F80E1F0C5E for ; Mon, 26 Sep 2011 12:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.107, 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 jj0BBzpof0WP for ; Mon, 26 Sep 2011 12:00:44 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id AC08C1F0C77 for ; Mon, 26 Sep 2011 12:00:29 -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, 26 Sep 2011 12:03:11 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.193]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0339.002; Mon, 26 Sep 2011 12:03:11 -0700 From: Mike Jones To: Julian Reschke Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments Thread-Index: Acx6TrJmwcQz5MGcQbCm3dgw87x/xAAnmxuAAGM0rVA= Date: Mon, 26 Sep 2011 19:03:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C2148AE@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FD669@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E7DC7DD.5010407@gmx.de> In-Reply-To: <4E7DC7DD.5010407@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C2148AETK5EX14MBXC285r_" MIME-Version: 1.0 Cc: "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: Mon, 26 Sep 2011 19:00:48 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C2148AETK5EX14MBXC285r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your note, Julian. Responses follow inline... -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Saturday, September 24, 2011 5:07 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments On 2011-09-24 02:13, Mike Jones wrote: > Thanks for your comments, Julian. Responses to them, which reflect the > content of draft 09, follow inline. Thanks! > ... > 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 =3D "Bearer" RWS access-token > > access-token =3D 1*( quoted-char / <"> ) > > quoted-char =3D ALPHA / DIGIT / > > "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / > > "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / > > ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / > > "{" / "|" / "}" / "~" / "\" / "," / ";" > > 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. > > Thanks for pointing this out. I changed the credentials syntax to the > following, which directly uses the syntax in > draft-ietf-httpbis-p7-auth-16 (and so invents no new syntax): > > credentials =3D "Bearer" 1*SP ( b64token / #auth-param ) The b64token is always there, right? So you won't be able to use additional parameters, and thus the syntax is e= ffectively credentials =3D "Bearer" 1*SP b64token Is that intended and acceptable? No, b64token isn't always there; the syntax specifies that either a b64toke= n OR one or more auth-params will be present. Yes, that's intended. > 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? > > Is there specific language either allowing or ruling out parameters to > the content-type value that you believe would be appropriate? Can you > provide a concrete motivating example? The text as currently written makes it impossible to add parameters to the = type. However, the rule of thumb for unknown media type parameters is to ig= nore them, not to reject them. Maybe: "The HTTP Content-Type" header field indicates a media type of "application= /x-www-form-urlencoded"." What do others think of this change that is intended to allow additional co= ntent-type parameters? > ... > challenge =3D "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. > > I have changed the RWS to 1*SP to match httpbis-p7-auth. I retained > the "param" definition so as to be able to clearly syntactically limit > the acceptable set of parameters. But the acceptable set of parameters is open-ended anyway, right? > param =3D realm / scope / > > error / error-desc / error-uri / > > auth-param > > scope =3D "scope" "=3D" <"> scope-v *( SP scope-v ) <"> > > scope-v =3D 1*quoted-char > > -> This seems to override the quoted-string syntax. Don't. Generic > > parsers *will* use the quoted-string syntax. > > quoted-char =3D ALPHA / DIGIT / > > "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / > > "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" / > > ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" / > > "{" / "|" / "}" / "~" / "\" / "," / ";" > > This issue is tracked as issue #26. The proposed resolution to this > issue is being discussed in a separate thread. OK. > error =3D "error" "=3D" quoted-string > > error-desc =3D "error_description" "=3D" quoted-string > > error-uri =3D "error_uri" "=3D" <"> URI-reference <"> > > -> missing I18N considerations > > The draft now contains: "the resource server MAY include the > error_description attribute to provide developers a UTF-8 encoded > human-readable explanation". (The UTF-8 language now matches the core > spec.) UTF-8 is uncommon in HTTP header fields. It's not strictly forbidden, but m= ost code I've seen assumes ISO-8859-1 (see, for instance, XHR or Java servl= et API). You *can* use UTF-8, but may encounter strange problems caused by software = components in between. This was the working group decision at the interim meeting and is used in b= oth the core and bearer drafts. I believe that UTF-8 is a reasonable outco= me. Unless there's a clear consensus to change both specifications, I beli= eve that this should stay as-is. > There was an explicit working decision not to include language codes. I didn't ask for language codes :-) OK. Others had been asking for them before the interim meeting, hence my c= onfusion. > This is recorded in the meeting minutes sent to the list by Hannes > Tschofenig on 6/3/11. The key part of the minutes is: > > *** Error Description *** > > Agreement among the participants that the error codes are meant for > consumption by the developer rather than the end user. Hence, language > codes are not important nor a human readable version that is supposed > to be understood by end users. In which case I recommend to stick to plain ASCII. Again, the working group explicitly decided to move from plain ASCII to UTF= -8. > -> weird syntax (why underscore?) > > The OAuth specs have always used underscores to separate words in > protocol messages. Well, it looks strange in an HTTP message. It may, but these names reflect working group consensus. > -> the generic syntax allows token in addition to quoted-string; it's > > pointless to rule that out here > > The reply syntax is intentionally restricted to simplify implementations. Special-casing the syntax *complicates* implementations. Using common const= ructs allows re-using existing parsing code and thus make things easier. Consider a browser seeing the credentials. It needs to parse the field valu= e for multiple challenges, and the only way for this to work is to have pre= dictable syntax for parameters. The philosophy behind the syntax restriction is that interoperability is of= ten increased if implementations are prepared to handle all the cases that = may arise. Having these cases be part of a fixed, enumerated set helps ach= ieve this. Parsing is the easy part; understanding and meaningfully handli= ng the semantics of the messages is the harder part, which is why this rest= riction intentionally imposes boundaries - so as to limit the cases that im= plementations need to be prepared handle. > 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. > > Done Thanks. Now that you have switched to HTTPbis you probably can get rid of the refer= ence to RFC 2617. The remaining reference is informational - not normative. Best regards, Julian Thanks agai= n, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435C2148AETK5EX14MBXC285r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your note, = Julian.  Responses follow inline…

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

-----Original Message-= ----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Saturday, September 24, 2011 5:07 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments<= /p>

 

On 2011-09-24 02:13, M= ike Jones wrote:

> Thanks for your c= omments, Julian. Responses to them, which reflect the

> content of draft = 09, follow inline.

 

Thanks!

 

> ...

> 2.1. The Authoriz= ation Request Header Field

> <= /p>

> The "Authori= zation" request header field is used by clients to make

> <= /p>

> authenticated req= uests with bearer tokens. The client uses the

> <= /p>

> "Bearer"= ; authentication scheme to transmit the access token in the

> <= /p>

> request.

> <= /p>

> For example:=

> <= /p>

> GET /resource HTT= P/1.1

> <= /p>

> Host: server.exam= ple.com

> <= /p>

> Authorization: Be= arer vF9dft4qmT

> <= /p>

> The "Authori= zation" header field uses the framework defined by

> <= /p>

> [RFC2617] as foll= ows:

> <= /p>

> credentials =3D &= quot;Bearer" RWS access-token

> <= /p>

> access-token =3D = 1*( quoted-char / <"> )

> <= /p>

> quoted-char =3D A= LPHA / DIGIT /

> <= /p>

> "!" / &= quot;#" / "$" / "%" / "&" / "'&= quot; / "(" / ")" /

> <= /p>

> "*" / &= quot;+" / "-" / "." / "/" / ":&= quot; / "<" / "=3D" /

> <= /p>

> ">" = / "?" / "@" / "[" / "]" / "^&q= uot; / "_" / "`" /

> <= /p>

> "{" / &= quot;|" / "}" / "~" / "\" / ","= ; / ";"

> <= /p>

> This is incompati= ble with the RFC2617 grammar which requires auth-params.

> <= /p>

> HTTPbis P7 will i= ntroduce an alternative syntax ("b64token"), but that

> is restricted to = a single instance and thus not extensible.

> <= /p>

> I recommend to us= e auth-param syntax instead.

> <= /p>

> Thanks for pointi= ng this out. I changed the credentials syntax to the

> following, which = directly uses the syntax in

> draft-ietf-httpbi= s-p7-auth-16 (and so invents no new syntax):

> <= /p>

> credentials =3D &= quot;Bearer" 1*SP ( b64token / #auth-param )

 

The b64token is always= there, right?

 

So you won't be able t= o use additional parameters, and thus the syntax is effectively<= /p>

 

    cre= dentials =3D "Bearer" 1*SP b64token

 

Is that intended and a= cceptable?

 

No, b64token isn’= ;t always there; the syntax specifies that either a b64token OR one or more= auth-params will be present.  Yes, that’s intended.<= /span>

 

> 2.2. Form-Encoded= Body Parameter

> <= /p>

> ...

> <= /p>

> o The entity-body= follows the encoding requirements of the

> <= /p>

> "application= /x-www-form-urlencoded" content-type as defined by

> <= /p>

> [W3C.REC-html401-= 19991224].

> <= /p>

> o The HTTP reques= t entity-header includes the "Content-Type" header

> <= /p>

> field set to &quo= t;application/x-www-form-urlencoded".

> <= /p>

> What about parame= ters?

> <= /p>

> Is there specific= language either allowing or ruling out parameters to

> the content-type = value that you believe would be appropriate? Can you

> provide a concret= e motivating example?

 

The text as currently = written makes it impossible to add parameters to the type. However, the rul= e of thumb for unknown media type parameters is to ignore them, not to reje= ct them.

 

Maybe:

 

"The HTTP Content= -Type" header field indicates a media type of "application/x-www-= form-urlencoded"."

 

What do others think o= f this change that is intended to allow additional content-type parameters?=

 

> ...

> challenge =3D &qu= ot;Bearer" [ RWS 1#param ]

> <= /p>

> -> please stic= k to the syntax defined in the authentication framework,

> <= /p>

> so use "auth= -param", and just define the allowed parameters separately.=

> <= /p>

> I have changed th= e RWS to 1*SP to match httpbis-p7-auth. I retained

> the “param&= #8221; definition so as to be able to clearly syntactically limit

> the acceptable se= t of parameters.

 

But the acceptable set= of parameters is open-ended anyway, right?

 

> param =3D realm /= scope /

> <= /p>

> error / error-des= c / error-uri /

> <= /p>

> auth-param

> <= /p>

> scope =3D "s= cope" "=3D" <"> scope-v *( SP scope-v ) <"= ;>

> <= /p>

> scope-v =3D 1*quo= ted-char

> <= /p>

> -> This seems = to override the quoted-string syntax. Don't. Generic

> <= /p>

> parsers *will* us= e the quoted-string syntax.

> <= /p>

> quoted-char =3D A= LPHA / DIGIT /

> <= /p>

> "!" / &= quot;#" / "$" / "%" / "&" / "'&= quot; / "(" / ")" /

> <= /p>

> "*" / &= quot;+" / "-" / "." / "/" / ":&= quot; / "<" / "=3D" /

> <= /p>

> ">" = / "?" / "@" / "[" / "]" / "^&q= uot; / "_" / "`" /

> <= /p>

> "{" / &= quot;|" / "}" / "~" / "\" / ","= ; / ";"

> <= /p>

> This issue is tra= cked as issue #26. The proposed resolution to this

> issue is being di= scussed in a separate thread.

 

OK.

 

> error =3D "e= rror" "=3D" quoted-string

> <= /p>

> error-desc =3D &q= uot;error_description" "=3D" quoted-string

> <= /p>

> error-uri =3D &qu= ot;error_uri" "=3D" <"> URI-reference <"&= gt;

> <= /p>

> -> missing I18= N considerations

> <= /p>

> The draft now con= tains: "the resource server MAY include the

> error_description= attribute to provide developers a UTF-8 encoded

> human-readable ex= planation". (The UTF-8 language now matches the core

> spec.)=

 

UTF-8 is uncommon in H= TTP header fields. It's not strictly forbidden, but most code I've seen ass= umes ISO-8859-1 (see, for instance, XHR or Java servlet API).

 

You *can* use UTF-8, b= ut may encounter strange problems caused by software components in between.=

 

This was the working g= roup decision at the interim meeting and is used in both the core and beare= r drafts.  I believe that UTF-8 is a reasonable outcome.  Unless = there’s a clear consensus to change both specifications, I believe that this should stay as-is.

 

> There was an expl= icit working decision not to include language codes.

 

I didn't ask for langu= age codes :-)

 

OK.  Others had b= een asking for them before the interim meeting, hence my confusion.

 

> This is recorded = in the meeting minutes sent to the list by Hannes

> Tschofenig on 6/3= /11. The key part of the minutes is:

> <= /p>

> *** Error Descrip= tion ***

> <= /p>

> Agreement among t= he participants that the error codes are meant for

> consumption by th= e developer rather than the end user. Hence, language

> codes are not imp= ortant nor a human readable version that is supposed

> to be understood = by end users.

 

In which case I recomm= end to stick to plain ASCII.

 

Again, the working gro= up explicitly decided to move from plain ASCII to UTF-8.<= /p>

 

> -> weird synta= x (why underscore?)

> <= /p>

> The OAuth specs h= ave always used underscores to separate words in

> protocol messages= .

 

Well, it looks strange= in an HTTP message.

 

It may, but these name= s reflect working group consensus.

 

> -> the generic= syntax allows token in addition to quoted-string; it's

> <= /p>

> pointless to rule= that out here

> <= /p>

> The reply syntax = is intentionally restricted to simplify implementations.

 

Special-casing the syn= tax *complicates* implementations. Using common constructs allows re-using = existing parsing code and thus make things easier.

 

Consider a browser see= ing the credentials. It needs to parse the field value for multiple challen= ges, and the only way for this to work is to have predictable syntax for pa= rameters.

 

The philosophy behind = the syntax restriction is that interoperability is often increased if imple= mentations are prepared to handle all the cases that may arise.  Havin= g these cases be part of a fixed, enumerated set helps achieve this.  Parsing is the easy part; understanding and = meaningfully handling the semantics of the messages is the harder part, whi= ch is why this restriction intentionally imposes boundaries – so as t= o limit the cases that implementations need to be prepared handle.

 

> 4. IANA Considera= tions

> <= /p>

> -> If you have= a dependency on HTTPbis then you should also add the

> <= /p>

> registration for = the authentication scheme as defined in HTTPbis P7.

> <= /p>

> Done

 

Thanks.

 

Now that you have swit= ched to HTTPbis you probably can get rid of the reference to RFC 2617.=

 

The remaining referenc= e is informational – not normative.

 

Best regards, Julian

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Thanks again,=

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

--_000_4E1F6AAD24975D4BA5B16804296739435C2148AETK5EX14MBXC285r_-- From Michael.Jones@microsoft.com Mon Sep 26 12:00: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 93B081F0C68 for ; Mon, 26 Sep 2011 12:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, 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 ucLWTBLYZi4E for ; Mon, 26 Sep 2011 12:00:49 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 776A01F0CEE for ; Mon, 26 Sep 2011 12:00:37 -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; Mon, 26 Sep 2011 12:03:20 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.193]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Mon, 26 Sep 2011 12:03:20 -0700 From: Mike Jones To: Barry Leiba Thread-Topic: [OAUTH-WG] Proposed resolution for issue 26 Thread-Index: Acx5+RoYuC5sLQs0Spy/pi+T441Q9ABABAUAAGEPyiA= Date: Mon, 26 Sep 2011 19:03:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 26 Sep 2011 19:00:50 -0000 Sounds good to me. Are others good with this wording? -- Mike -----Original Message----- From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g= mail.com] On Behalf Of Barry Leiba Sent: Saturday, September 24, 2011 6:33 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 > My proposed resolution is that %-encoding not be required in the=20 > specification I agree with your analysis, now that I see it laid out clearly. I would fe= el better, though, if there were text in the document that explained that t= o others, who read it later. Perhaps, using your words, we could make this= change to section 2.4: OLD The "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. The "scope" attribute MUST NOT appear more than once. NEW The "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. The "scope" attribute MUST NOT appear more than once. Interpretation of scope strings requires semantic agreement on the meaning of the scope strings between the parties participating the OAuth flow. Should an encoding be used for scope strings in a particular deployment context, participants have to have agreed upon that encoding, just as they agree on other OAuth configuration parameters. Does that work? Barry From Michael.Jones@microsoft.com Mon Sep 26 12:02: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 4143D1F0C65 for ; Mon, 26 Sep 2011 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.497 X-Spam-Level: X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, 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 3dTalxPFo+nZ for ; Mon, 26 Sep 2011 12:02:58 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 657C71F0C5E for ; Mon, 26 Sep 2011 12:02:58 -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, 26 Sep 2011 12:05:41 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.193]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0339.002; Mon, 26 Sep 2011 12:05:41 -0700 From: Mike Jones To: "Manger, James H" , "oauth@ietf.org" Thread-Topic: Proposed resolution for issue 26 Thread-Index: Acx5+RoYuC5sLQs0Spy/pi+T441Q9AAxktNwAG+nNNA= Date: Mon, 26 Sep 2011 19:05:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C214906@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128E5D883D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128E5D883D@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.74] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 26 Sep 2011 19:02:59 -0000 While you take the viewpoint that the bearer spec is restricting scope valu= es, in fact, the spec intentionally allows all characters that can be safel= y communicated in an HTTP response header parameter to be used. About whet= her those characters employ an encoding methodology to sometimes represent = other characters or abstractions, I believe that Barry's proposed wording h= its the nail on the head: Interpretation of scope strings requires semantic agreement on the meaning of the scope strings between the parties participating the OAuth flow. Should an encoding be used for scope strings in a particular deployment context, participants have to have agreed upon that encoding, just as they agree on other OAuth configuration parameters. Best wishes, -- Mike -----Original Message----- From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20 Sent: Saturday, September 24, 2011 7:41 AM To: Mike Jones; oauth@ietf.org Subject: RE: Proposed resolution for issue 26 > From: Mike Jones > > Issue #26 http://trac.tools.ietf.org/wg/oauth/trac/ticket/26 asks whether= the semantics of scope strings should be changed to require that the % cha= racter be interpreted as introducing a percent-encoded character that follo= ws.=A0 My proposed resolution is that %-encoding not be required in the spe= cification; therefore no textual change would be made to the specification = in response to this issue.=A0 The reasoning behind this resolution is as fo= llows: I disagree. This does not resolve the ambiguity. I think there is some conf= usion between 1) the internal structure (eg encoding) of a scope string, an= d 2) escaping done when transporting the scope string in a protocol element= . > 1.=A0 Interpretation of scope strings already requires semantic agreement= on the meaning of the scope strings between the parties participating the = OAuth flow.=A0 Should an encoding be used for scope strings in a particular= ly deployment context, it is reasonable for participants to have agreed upo= n that encoding, just as they agree on other OAuth configuration parameters= . A client app does NOT always need semantic agreement on the meaning of scop= e strings. Consider a client app that makes a request to a server and gets a 401 respo= nse with 'WWW-Authenticate: Bearer ... scope=3D"XXXXX"'. The client app now= knows it can run an OAuth exchange to get the required permission to retry= the request, and it should ask for the given scope during that OAuth excha= nge. The client app needs to copy XXXXXX from the response header into an OAuth = exchange. It does not need to know anything more "semantics" about this sco= pe value. XXXXXXX can be opaque to the client app. The client app does need= to know any decode/encode steps involved in transferring this HTTP Bearer = response value to an OAuth exchange value. If "XXXXXXX" is "1%2A2", should the client app redirect the user to https://example.org/authz?scope=3D1%2A2&... or https://example.org/authz?scope=3D1%252A2&... (or can the answer vary between different servers!!) > 2.=A0 More than one encoding methodology could reasonably be employed in = scope strings.=A0 For instance, base64url encoding of scope values could be= used in some contexts.=A0 Quoting characters with '\' is another possibili= ty.=A0 I see no compelling reason to mandate %-encoding over other potentia= l encoding methods. Servers can choose any encoding they want (including none) when defining th= eir own scope values (as logical Unicode strings). That is a separate choice to the encoding that is used in the HTTP Bearer r= esponse header when transporting a scope value. > 3.=A0 Mandating %-encoding unnecessarily complicates implementations with= out providing a clear compensating benefit sufficient warrant the additiona= l complexity.=A0 For example, it seems unnecessary to mandate that the scop= e strings "email" and "%65mail" MUST compare as being equal in all implemen= tations. When the scope string "email" is transported in JSON the receiver MUST comp= are "\u0065mail" as equal. When it is transported as a URI query parameter = the receiver MUST compare "%65mail" as equal. This is normal JSON and query= parameter processing. > 4.=A0 If an encoding methodology for scope strings is mandated, this shou= ld be done in the OAuth Core specification - not the OAuth Bearer Token spe= cification. The core spec implies that a scope value can consist of any Unicode charact= ers except space. The core spec transports scope values in JSON or url-encoded fields that ha= ve well-defined escaping mechanisms that are sufficient to handle all Unico= de string, hence all possible scope values. The Bearer spec transports scope values in an HTTP response header paramete= r. It defines no escaping mechanism so it cannot handle all Unicode strings= (ie it cannot handle all scope values that are possible in core). It is strange for the Bearer spec to restrict scope values. It should leave= that to the core. Hence the Bearer spec should be able to transport any sc= ope value allowed in the core (ie any Unicode string). Hence an escaping me= chanism needs to be specified for the HTTP response header scope field.=20 > 5.=A0 I am aware of no existing practice that utilizes %-encoding of scop= e values. Then a solution that avoids defining an escaping mechanism might work. It r= equires the Bearer spec to explicitly say "The Bearer mechanism only works = with scope values that are limited to these ~90 ASCII characters (that can = be transported in an HTTP response header field without an escaping mechani= sm), which is more restrictive than OAuth core". Or better still if you lik= e this approach, apply this restriction in core to all scope values. -- James Manger From wmills@yahoo-inc.com Mon Sep 26 12:18: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 7B2DE1F0C4F for ; Mon, 26 Sep 2011 12:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.395 X-Spam-Level: X-Spam-Status: No, score=-17.395 tagged_above=-999 required=5 tests=[AWL=0.203, 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 JcdJJrw-GMuU for ; Mon, 26 Sep 2011 12:18:03 -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 BA0CD1F0C4D for ; Mon, 26 Sep 2011 12:18:03 -0700 (PDT) Received: from [98.139.91.66] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 26 Sep 2011 19:20:47 -0000 Received: from [98.139.91.25] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 26 Sep 2011 19:20:47 -0000 Received: from [127.0.0.1] by omp1025.mail.sp2.yahoo.com with NNFMP; 26 Sep 2011 19:20:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 108921.86783.bm@omp1025.mail.sp2.yahoo.com Received: (qmail 42879 invoked by uid 60001); 26 Sep 2011 19:20:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1317064846; bh=rkkTnT8PBNclpyBTzPRxUgr6GxgTRK+EvcyeGbBQu/g=; 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=ck2rikYXITYtuNX6GpTJa5ZF2sOWitPvsNNSalf8ZISDh0LE3vHOQrvdIY/jbvZGVnAmBJRW5InU1m+XcGSSKgtK5GpitbnuSHw34HnNVH7jwf52kau9qNZ9NDaRHCw9gYzSiDuUvsxdfcgM5U2oL4Oo1ShEM6AHENpx7fn0FDA= 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=RUsW8ZqRPwCM/9uq4WASxKcRfPyNr3weZFhqSAHbz8h+stXtMOUOKKwIP5T4JN5HQI/mWgx2rLZTQ+HtO2eduF4zCDwDhXrTvOcNZTPf5mL2UsARo0eY6Uz+DouKub69x7JN3pfk4maKeXkTMYLSy1wPEJlZUGMhfSSv9BPgR14=; X-YMail-OSG: l6L1lFcVM1mCUTmkM7MAR1XTjYw7V7QDisVlJT5UwPC6vj9 B64nCQ4ab4JxiBAO7HXoncZTo5YRsuzzTylGrFlQgfi_0BgqnYOlHbqADHSs rrmrBgcRcZ.QEJNuFcBSGUaMzfSkmTHhydaiEPJhjQjfY8g0f.lzTZ0Fw_Kf ThA_qO16PythI3u_0I1NB.cTYm5WdUPk8E.sEuEr6a0h5PaZOhrJs3SIwLu5 92fizOdw5mMkMRFvW1kWqtJAhWD1OLzaQoNg8QbJeX3Xhfuf4evw4LQ8.scs OC8MLlRM_QmIslUMT8uON5RWoo3VQbPMtMRsHeuPiM0ArEf0V7HgXIaiCh5u dwUPVW3UUBBHQaly3OHSs1J95qRXAVH7GqcxhTkhS7LUXf7lbXBoDJpMYX8e .afT3HC15LkX.4My7XCJectc1XgFqcVJgU6ftw1CIMDia8ooVkntJtJuHQxP zPW8PCZWW6uCrjYL_lzzsEp2Sr4tYIYRxPENHuJXiTbCv0yL2zh71 Received: from [209.131.62.113] by web31805.mail.mud.yahoo.com via HTTP; Mon, 26 Sep 2011 12:20:46 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.114.317681 References: <4E1F6AAD24975D4BA5B16804296739435C1FD669@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E7DC7DD.5010407@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C2148AE@TK5EX14MBXC285.redmond.corp.microsoft.com> Message-ID: <1317064846.35814.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Mon, 26 Sep 2011 12:20:46 -0700 (PDT) From: William Mills To: Mike Jones , Julian Reschke In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C2148AE@TK5EX14MBXC285.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-115005696-1317064846=:35814" Cc: "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 Reply-To: William Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 19:18:05 -0000 --0-115005696-1317064846=:35814 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm gonna top reply...=0A=0A>> Is that intended and acceptable?=0A> =0A=0A>= No, =0Ab64token isn=E2=80=99t always there; the syntax specifies that eith= er a b64token OR one or more auth-params will be present.=C2=A0 Yes, that= =E2=80=99s intended.=0A=0AIf the token can be transported in auth-params th= en I think you must define how that will happen.=C2=A0 It's too loose other= wise.=C2=A0 Go with this obvious and say if auth-parames are used then ther= e must be a token=3D parameter that carries the token.=C2=A0 That way you a= re always guaranteed the token is present in the protocol.=0A=0A-bill=0A=0A= =0A=0A________________________________=0AFrom: Mike Jones =0ATo: Julian Reschke =0ACc: "oauth@ietf= .org" =0ASent: Monday, September 26, 2011 12:03 PM=0ASubjec= t: Re: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments=0A=0A= =0A =0AThanks for your note, Julian.=C2=A0 Responses follow inline=E2=80=A6= =0A=C2=A0=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 -- Mike=0A=C2=A0=0A-----Original Message-----=0AFrom: Julia= n Reschke [mailto:julian.reschke@gmx.de] =0ASent: Saturday, September 24, 2= 011 5:07 AM=0ATo: Mike Jones=0ACc: oauth@ietf.org=0ASubject: Re: [OAUTH-WG]= draft-ietf-oauth-v2-bearer-08 HTTP syntax comments=0A=C2=A0=0AOn 2011-09-2= 4 02:13, Mike Jones wrote:=0A> Thanks for your comments, Julian. Responses = to them, which reflect the =0A> content of draft 09, follow inline.=0A=C2= =A0=0AThanks!=0A=C2=A0=0A> ...=0A> 2.1. The Authorization Request Header Fi= eld=0A> =C2=A0=0A> The "Authorization" request header field is used by clie= nts to make=0A> =C2=A0=0A> authenticated requests with bearer tokens. The c= lient uses the=0A> =C2=A0=0A> "Bearer" authentication scheme to transmit th= e access token in the=0A> =C2=A0=0A> request.=0A> =C2=A0=0A> For example:= =0A> =C2=A0=0A> GET /resource HTTP/1.1=0A> =C2=A0=0A> Host: server.example.= com=0A> =C2=A0=0A> Authorization: Bearer vF9dft4qmT=0A> =C2=A0=0A> The "Aut= horization" header field uses the framework defined by=0A> =C2=A0=0A> [RFC2= 617] as follows:=0A> =C2=A0=0A> credentials =3D "Bearer" RWS access-token= =0A> =C2=A0=0A> access-token =3D 1*( quoted-char / <"> )=0A> =C2=A0=0A> quo= ted-char =3D ALPHA / DIGIT /=0A> =C2=A0=0A> "!" / "#" / "$" / "%" / "&" / "= '" / "(" / ")" /=0A> =C2=A0=0A> "*" / "+" / "-" / "." / "/" / ":" / "<" / "= =3D" /=0A> =C2=A0=0A> ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" /=0A> = =C2=A0=0A> "{" / "|" / "}" / "~" / "\" / "," / ";"=0A> =C2=A0=0A> This is i= ncompatible with the RFC2617 grammar which requires auth-params.=0A> =C2=A0= =0A> HTTPbis P7 will introduce an alternative syntax ("b64token"), but that= =0A> is restricted to a single instance and thus not extensible.=0A> =C2= =A0=0A> I recommend to use auth-param syntax instead.=0A> =C2=A0=0A> Thanks= for pointing this out. I changed the credentials syntax to the =0A> follow= ing, which directly uses the syntax in=0A> draft-ietf-httpbis-p7-auth-16 (a= nd so invents no new syntax):=0A> =C2=A0=0A> credentials =3D "Bearer" 1*SP = ( b64token / #auth-param )=0A=C2=A0=0AThe b64token is always there, right?= =0A=C2=A0=0ASo you won't be able to use additional parameters, and thus the= syntax is effectively=0A=C2=A0=0A=C2=A0=C2=A0=C2=A0 credentials =3D "Beare= r" 1*SP b64token=0A=C2=A0=0AIs that intended and acceptable?=0A=C2=A0=0ANo,= b64token isn=E2=80=99t always there; the syntax specifies that either a b6= 4token OR one or more auth-params will be present.=C2=A0 Yes, that=E2=80=99= s intended.=0A=C2=A0=0A> 2.2. Form-Encoded Body Parameter=0A> =C2=A0=0A> ..= .=0A> =C2=A0=0A> o The entity-body follows the encoding requirements of the= =0A> =C2=A0=0A> "application/x-www-form-urlencoded" content-type as defined= by=0A> =C2=A0=0A> [W3C.REC-html401-19991224].=0A> =C2=A0=0A> o The HTTP re= quest entity-header includes the "Content-Type" header=0A> =C2=A0=0A> field= set to "application/x-www-form-urlencoded".=0A> =C2=A0=0A> What about para= meters?=0A> =C2=A0=0A> Is there specific language either allowing or ruling= out parameters to =0A> the content-type value that you believe would be ap= propriate? Can you =0A> provide a concrete motivating example?=0A=C2=A0=0AT= he text as currently written makes it impossible to add parameters to the t= ype. However, the rule of thumb for unknown media type parameters is to ign= ore them, not to reject them.=0A=C2=A0=0AMaybe:=0A=C2=A0=0A"The HTTP Conten= t-Type" header field indicates a media type of "application/x-www-form-urle= ncoded"."=0A=C2=A0=0AWhat do others think of this change that is intended t= o allow additional content-type parameters?=0A=C2=A0=0A> ...=0A> challenge = =3D "Bearer" [ RWS 1#param ]=0A> =C2=A0=0A> -> please stick to the syntax d= efined in the authentication framework,=0A> =C2=A0=0A> so use "auth-param",= and just define the allowed parameters separately.=0A> =C2=A0=0A> I have c= hanged the RWS to 1*SP to match httpbis-p7-auth. I retained =0A> the =E2=80= =9Cparam=E2=80=9D definition so as to be able to clearly syntactically limi= t =0A> the acceptable set of parameters.=0A=C2=A0=0ABut the acceptable set = of parameters is open-ended anyway, right?=0A=C2=A0=0A> param =3D realm / s= cope /=0A> =C2=A0=0A> error / error-desc / error-uri /=0A> =C2=A0=0A> auth-= param=0A> =C2=A0=0A> scope =3D "scope" "=3D" <"> scope-v *( SP scope-v ) <"= >=0A> =C2=A0=0A> scope-v =3D 1*quoted-char=0A> =C2=A0=0A> -> This seems to = override the quoted-string syntax. Don't. Generic=0A> =C2=A0=0A> parsers *w= ill* use the quoted-string syntax.=0A> =C2=A0=0A> quoted-char =3D ALPHA / D= IGIT /=0A> =C2=A0=0A> "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" /=0A> = =C2=A0=0A> "*" / "+" / "-" / "." / "/" / ":" / "<" / "=3D" /=0A> =C2=A0=0A>= ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" /=0A> =C2=A0=0A> "{" / "|" /= "}" / "~" / "\" / "," / ";"=0A> =C2=A0=0A> This issue is tracked as issue = #26. The proposed resolution to this =0A> issue is being discussed in a sep= arate thread.=0A=C2=A0=0AOK.=0A=C2=A0=0A> error =3D "error" "=3D" quoted-st= ring=0A> =C2=A0=0A> error-desc =3D "error_description" "=3D" quoted-string= =0A> =C2=A0=0A> error-uri =3D "error_uri" "=3D" <"> URI-reference <">=0A> = =C2=A0=0A> -> missing I18N considerations=0A> =C2=A0=0A> The draft now cont= ains: "the resource server MAY include the =0A> error_description attribute= to provide developers a UTF-8 encoded =0A> human-readable explanation". (T= he UTF-8 language now matches the core=0A> spec.)=0A=C2=A0=0AUTF-8 is uncom= mon in HTTP header fields. It's not strictly forbidden, but most code I've = seen assumes ISO-8859-1 (see, for instance, XHR or Java servlet API).=0A=C2= =A0=0AYou *can* use UTF-8, but may encounter strange problems caused by sof= tware components in between.=0A=C2=A0=0AThis was the working group decision= at the interim meeting and is used in both the core and bearer drafts.=C2= =A0 I believe that UTF-8 is a reasonable outcome.=C2=A0 Unless there=E2=80= =99s a clear consensus to change both specifications, I believe that this s= hould stay as-is.=0A=C2=A0=0A> There was an explicit working decision not t= o include language codes.=0A=C2=A0=0AI didn't ask for language codes :-)=0A= =C2=A0=0AOK.=C2=A0 Others had been asking for them before the interim meeti= ng, hence my confusion.=0A=C2=A0=0A> This is recorded in the meeting minute= s sent to the list by Hannes =0A> Tschofenig on 6/3/11. The key part of the= minutes is:=0A> =C2=A0=0A> *** Error Description ***=0A> =C2=A0=0A> Agreem= ent among the participants that the error codes are meant for =0A> consumpt= ion by the developer rather than the end user. Hence, language =0A> codes a= re not important nor a human readable version that is supposed =0A> to be u= nderstood by end users.=0A=C2=A0=0AIn which case I recommend to stick to pl= ain ASCII.=0A=C2=A0=0AAgain, the working group explicitly decided to move f= rom plain ASCII to UTF-8.=0A=C2=A0=0A> -> weird syntax (why underscore?)=0A= > =C2=A0=0A> The OAuth specs have always used underscores to separate words= in =0A> protocol messages.=0A=C2=A0=0AWell, it looks strange in an HTTP me= ssage.=0A=C2=A0=0AIt may, but these names reflect working group consensus.= =0A=C2=A0=0A> -> the generic syntax allows token in addition to quoted-stri= ng; it's=0A> =C2=A0=0A> pointless to rule that out here=0A> =C2=A0=0A> The = reply syntax is intentionally restricted to simplify implementations.=0A=C2= =A0=0ASpecial-casing the syntax *complicates* implementations. Using common= constructs allows re-using existing parsing code and thus make things easi= er.=0A=C2=A0=0AConsider a browser seeing the credentials. It needs to parse= the field value for multiple challenges, and the only way for this to work= is to have predictable syntax for parameters.=0A=C2=A0=0AThe philosophy be= hind the syntax restriction is that interoperability is often increased if = implementations are prepared to handle all the cases that may arise.=C2=A0 = Having these cases be part of a fixed, enumerated set helps achieve this.= =C2=A0 Parsing is the easy part; understanding and meaningfully handling th= e semantics of the messages is the harder part, which is why this restricti= on intentionally imposes boundaries =E2=80=93 so as to limit the cases that= implementations need to be prepared handle.=0A=C2=A0=0A> 4. IANA Considera= tions=0A> =C2=A0=0A> -> If you have a dependency on HTTPbis then you should= also add the=0A> =C2=A0=0A> registration for the authentication scheme as = defined in HTTPbis P7.=0A> =C2=A0=0A> Done=0A=C2=A0=0AThanks.=0A=C2=A0=0ANo= w that you have switched to HTTPbis you probably can get rid of the referen= ce to RFC 2617.=0A=C2=A0=0AThe remaining reference is informational =E2=80= =93 not normative.=0A=C2=A0=0ABest regards, Julian=0A=C2=A0=0A=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks a= gain,=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 -- Mike=0A=C2=A0=0A___________________________________________= ____=0AOAuth mailing list=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/oauth --0-115005696-1317064846=:35814 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'm gonna top reply...

>> Is that intended and acceptable?
=0A
>
=0A
> No, =0Ab64token isn=E2=80=99t always there; the syntax specifie= s that either a b64token=0A OR one or more auth-params will be present.&nbs= p; Yes, that=E2=80=99s intended.

If the to= ken can be transported in auth-params then I think you must define how that= will happen.  It's too loose otherwise.  Go with this obvious an= d say if auth-parames are used then there must be a token=3D parameter that= carries the token.  That way you are always guaranteed the token is p= resent in the protocol.
-bill
=0A

=
From: Mike Jones <Michael.Jones@microsoft= .com>
To: Julian Res= chke <julian.reschke@gmx.de>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Sent: Monday, September 26, 2011 12:03 P= M
Subject: Re: [OAUTH-W= G] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments

=0A=0A =0A =0A=0A=0A
=0A
=0A
Thanks for your note, Julian.  Responses fol= low inline=E2=80=A6
=0A
 
=0A
     = ;            &n= bsp;            = ;            &n= bsp;            = ;         -- Mike
=0A<= div class=3D"yiv390414703MsoNormal">  <= /span>
=0A
-----Original Message-----
=0AFrom: Julian Reschke [mailto:juli= an.reschke@gmx.de]
=0ASent: Saturday, September 24, 2011 5:07 AM
=0A= To: Mike Jones
=0ACc: oauth@ietf.org
=0ASubject: Re: [OAUTH-WG] draft= -ietf-oauth-v2-bearer-08 HTTP syntax comments
=0A
 
=0A
On 2011-09-24 02:= 13, Mike Jones wrote:
=0A
> Thanks for your comments, Julian. Responses to= them, which reflect the=0A
=0A
> content of draft 09, follow inline. =0A
&= nbsp;
=0A
Thanks!
=0A
 
=0A
> ...
=0A
> 2.1. The Authorization Request = Header Field
=0A
>  
=0A
> The "Authorization" request header field = is used by clients to make
=0A
>  
=0A
> authenticated requests with= bearer tokens. The client uses the
=0A
>  
=0A
> "Bearer" authentic= ation scheme to transmit the access token in the
=0A
>  
=0A> reque= st.
=0A
>  
=0A
> For example:
=0A
>  
=0A
> GET /resource HT= TP/1.1
=0A
>  
=0A
> Host: server.example.com
=0A
>  
= =0A
>= Authorization: Bearer vF9dft4qmT
=0A
>  
=0A
> The "Authorization" = header field uses the framework defined by
=0A
>  
=0A
> [RFC2617] a= s follows:
=0A
>  
=0A
> credentials =3D "Bearer" RWS access-token =0A
>  
=0A
> access-token =3D 1*( quoted-char / <"> )
= =0A
>=  
=0A
> quoted-char =3D ALPHA / DIGIT /
=0A
>  
=0A
> "!" / "= #" / "$" / "%" / "&" / "'" / "(" / ")" /
=0A
>  
=0A
> "*" / "+"= / "-" / "." / "/" / ":" / "<" / "=3D" /
=0A
>  
=0A
> ">" / "= ?" / "@" / "[" / "]" / "^" / "_" / "`" /
=0A
>  
=0A
> "{" / "|" / = "}" / "~" / "\" / "," / ";"
=0A
>  
=0A
> This is incompatible with = the RFC2617 grammar which requires auth-params.
=0A
>  
=0A> HTTPbi= s P7 will introduce an alternative syntax ("b64token"), but that=0A
= =0A
>= is restricted to a single instance and thus not extensible.
=0A
>  <= /div> =0A
> I recommend to use auth-param syntax instead.
=0A
>  
= =0A
>= Thanks for pointing this out. I changed the credentials syntax to the=0A =0A
> following, which directly uses the syntax in
=0A
> draft-ietf-httpbi= s-p7-auth-16 (and so invents no new syntax):
=0A
>  
=0A
> credentia= ls =3D "Bearer" 1*SP ( b64token / #auth-param )
=0A
 
=0A
The b64token is= always there, right?
=0A
 
=0A
So you won't be able to use additional pa= rameters, and thus the syntax is effectively
=0A
 
=0A
   = ; credentials =3D "Bearer" 1*SP b64token
=0A
 
=0A
Is that intended and a= cceptable?
=0A
 
=0A
<= span style=3D"color:#002060;">No, b64token isn=E2=80=99t always there; the = syntax specifies that either a b64token OR one or more auth-params will be = present.  Yes, that=E2=80=99s intended.
=0A
 
= =0A
>= 2.2. Form-Encoded Body Parameter
=0A
>  
=0A
> ...
=0A
>   =0A
= > o The entity-body follows the encoding requirements of the
=0A> &nbs= p;
=0A
> "application/x-www-form-urlencoded" content-type as defined by =0A
= >  
=0A
> [W3C.REC-html401-19991224].
=0A
>  
=0A
> o The H= TTP request entity-header includes the "Content-Type" header
=0A
>  <= /div> =0A
> field set to "application/x-www-form-urlencoded".
=0A
>   =0A
&g= t; What about parameters?
=0A
>  
=0A
> Is there specific language e= ither allowing or ruling out parameters to=0A
=0A
> the content-type value= that you believe would be appropriate? Can you=0A
=0A
> provide a concret= e motivating example?
=0A
 
=0A
The text as currently written makes it im= possible to add parameters to the type. However, the rule of thumb for unkn= own media type parameters is to ignore them, not to reject them.
=0A<= div class=3D"yiv390414703MsoPlainText" style=3D"margin-left:.5in;">  <= /div> =0A
Maybe:
=0A
 
=0A
"The HTTP Content-Type" header field indicates a med= ia type of "application/x-www-form-urlencoded"."
=0A
 
=0A=
What do= others think of this change that is intended to allow additional content-t= ype parameters?
=0A
 
=0A
> ...
=0A
> challenge =3D "Bearer" [= RWS 1#param ]
=0A
>  
=0A
> -> please stick to the syntax define= d in the authentication framework,
=0A
>  
=0A
> so use "auth-param"= , and just define the allowed parameters separately.
=0A
>  
= =0A
>= I have changed the RWS to 1*SP to match httpbis-p7-auth. I retained=0A =0A
&= gt; the =E2=80=9Cparam=E2=80=9D definition so as to be able to clearly synt= actically limit=0A
=0A
> the acceptable set of parameters.
=0A   =0A
B= ut the acceptable set of parameters is open-ended anyway, right?
=0A<= div class=3D"yiv390414703MsoPlainText" style=3D"margin-left:.5in;">  <= /div> =0A
> param =3D realm / scope /
=0A
>  
=0A
> error / error-desc / = error-uri /
=0A
>  
=0A
> auth-param
=0A
>  
=0A
> scope =3D = "scope" "=3D" <"> scope-v *( SP scope-v ) <">
=0A
>   =0A
&= gt; scope-v =3D 1*quoted-char
=0A
>  
=0A
> -> This seems to over= ride the quoted-string syntax. Don't. Generic
=0A
>  
=0A
> parsers = *will* use the quoted-string syntax.
=0A
>  
=0A
> quoted-char =3D A= LPHA / DIGIT /
=0A
>  
=0A
> "!" / "#" / "$" / "%" / "&" / "'" /= "(" / ")" /
=0A
>  
=0A
> "*" / "+" / "-" / "." / "/" / ":" / "<= " / "=3D" /
=0A
>  
=0A
> ">" / "?" / "@" / "[" / "]" / "^" / "_"= / "`" /
=0A
>  
=0A
> "{" / "|" / "}" / "~" / "\" / "," / ";"
= =0A
>= ;  
=0A
> This issue is tracked as issue #26. The proposed resolution= to this=0A
=0A
> issue is being discussed in a separate thread.
=0A=
 =
=0A
OK.
=0A
 
=0A
> error =3D "error" "=3D" quoted-string
=0A>  =
=0A
> error-desc =3D "error_description" "=3D" quoted-string
=0A>  = ;
=0A
> error-uri =3D "error_uri" "=3D" <"> URI-reference <"><= /div> =0A
>  
=0A
> -> missing I18N considerations
=0A
>  
= =0A
>= ; The draft now contains: "the resource server MAY include the=0A
=0A=
> er= ror_description attribute to provide developers a UTF-8 encoded=0A
= =0A
>= human-readable explanation". (The UTF-8 language now matches the core =0A
&g= t; spec.)
=0A
 
=0A
UTF-8 is uncommon in HTTP header fields. It's not st= rictly forbidden, but most code I've seen assumes ISO-8859-1 (see, for inst= ance, XHR or Java servlet API).
=0A
 
=0A
You *can* use UTF-8, but may en= counter strange problems caused by software components in between.
= =0A
&nb= sp;
=0A
This was the working group decision at the interim meeting and= is used in both the core and bearer drafts.  I believe that UTF-8 is = a reasonable outcome.  Unless there=E2=80=99s a clear consensus to cha= nge both specifications,=0A I believe that this should stay as-is. =0A
 
=0A
> There was an explicit working decision not to includ= e language codes.
=0A
 
=0A
I didn't ask for language codes :-)
=0A=
 =
=0A
OK.  Others had been asking for them before the interim meet= ing, hence my confusion.
=0A
 
=0A
> This is recorded in= the meeting minutes sent to the list by Hannes=0A
=0A
> Tschofenig on 6/3= /11. The key part of the minutes is:
=0A
>  
=0A
> *** Error Descrip= tion ***
=0A
>  
=0A
> Agreement among the participants that the err= or codes are meant for=0A
=0A
> consumption by the developer rather than t= he end user. Hence, language=0A
=0A
> codes are not important nor a human = readable version that is supposed=0A
=0A
> to be understood by end users.<= /div> =0A
 
=0A
In which case I recommend to stick to plain ASCII.
=0A  
=0A
Again, the working group explicitly decided to move from plain ASCII= to UTF-8.
=0A
 
=0A
> -> weird syntax (why underscor= e?)
=0A
>  
=0A
> The OAuth specs have always used underscores to se= parate words in=0A
=0A
> protocol messages.
=0A
 
=0A
Well, it looks s= trange in an HTTP message.
=0A
 
=0A
It may, but these names refle= ct working group consensus.
=0A
 
=0A
> -> the generi= c syntax allows token in addition to quoted-string; it's
=0A
>   =0A
&g= t; pointless to rule that out here
=0A
>  
=0A
> The reply syntax is= intentionally restricted to simplify implementations.
=0A
 
=0A=
Special= -casing the syntax *complicates* implementations. Using common constructs a= llows re-using existing parsing code and thus make things easier.
=0A=
 =
=0A
Consider a browser seeing the credentials. It needs to parse the field v= alue for multiple challenges, and the only way for this to work is to have = predictable syntax for parameters.
=0A
 
=0A
The philosophy behind= the syntax restriction is that interoperability is often increased if impl= ementations are prepared to handle all the cases that may arise.  Havi= ng these cases be part of a fixed, enumerated=0A set helps achieve this.&nb= sp; Parsing is the easy part; understanding and meaningfully handling the s= emantics of the messages is the harder part, which is why this restriction = intentionally imposes boundaries =E2=80=93 so as to limit the cases that im= plementations need=0A to be prepared handle.
=0A
 
= =0A
>= 4. IANA Considerations
=0A
>  
=0A
> -> If you have a dependency= on HTTPbis then you should also add the
=0A
>  
=0A
> registration= for the authentication scheme as defined in HTTPbis P7.
=0A
>   =0A
&g= t; Done
=0A
 
=0A
Thanks.
=0A
 
=0A
Now that you have switched to HTTPb= is you probably can get rid of the reference to RFC 2617.
=0A
 <= /div> =0A
The remaining reference is informational =E2=80=93 not normative.<= /div> =0A
 
=0A
Best regards, Julian
=0A
 
=0A
  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           Thanks again= ,
=0A
          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   -- Mike
=0A
 
=0A
=0A
=0A= =0A

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

--0-115005696-1317064846=:35814-- From julian.reschke@gmx.de Mon Sep 26 12:22: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 29F531F0C80 for ; Mon, 26 Sep 2011 12:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.152 X-Spam-Level: X-Spam-Status: No, score=-104.152 tagged_above=-999 required=5 tests=[AWL=-1.553, 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 F+lkA2ppRXtq for ; Mon, 26 Sep 2011 12:22:31 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D5EEB1F0C77 for ; Mon, 26 Sep 2011 12:22:26 -0700 (PDT) Received: (qmail invoked by alias); 26 Sep 2011 19:24:59 -0000 Received: from p508F9B39.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.155.57] by mail.gmx.net (mp043) with SMTP; 26 Sep 2011 21:24:59 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Z1jITJmPZknAryWllILjmW+ch0C1uA98EiECY8O erMiPopK5TsCtW Message-ID: <4E80D189.8050005@gmx.de> Date: Mon, 26 Sep 2011 21:24:57 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C1FD669@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E7DC7DD.5010407@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C2148AE@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C2148AE@TK5EX14MBXC285.redmond.corp.microsoft.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 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: Mon, 26 Sep 2011 19:22:32 -0000 On 2011-09-26 21:03, Mike Jones wrote: > ... > No, b64token isn’t always there; the syntax specifies that either a > b64token OR one or more auth-params will be present. Yes, that’s intended. OK then; just checking :-) > ... > This was the working group decision at the interim meeting and is used > in both the core and bearer drafts. I believe that UTF-8 is a reasonable > outcome. Unless there’s a clear consensus to change both specifications, > I believe that this should stay as-is. > ... This is a serialization issue. Just because one encoding is right in one place doesn't mean it's right somewhere else. > > There was an explicit working decision not to include language codes. > > I didn't ask for language codes :-) > > OK. Others had been asking for them before the interim meeting, hence my > confusion. > > > This is recorded in the meeting minutes sent to the list by Hannes > > > Tschofenig on 6/3/11. The key part of the minutes is: > > > > > > *** Error Description *** > > > > > > Agreement among the participants that the error codes are meant for > > > consumption by the developer rather than the end user. Hence, language > > > codes are not important nor a human readable version that is supposed > > > to be understood by end users. > > In which case I recommend to stick to plain ASCII. > > Again, the working group explicitly decided to move from plain ASCII to > UTF-8. > ... I think you need to make a conscious decision about the purpose. If it needs to support non-ASCII then using raw UTF-8 in the param may cause problems as explained above. > ... > > The reply syntax is intentionally restricted to simplify > implementations. > > Special-casing the syntax *complicates* implementations. Using common > constructs allows re-using existing parsing code and thus make things > easier. > > Consider a browser seeing the credentials. It needs to parse the field > value for multiple challenges, and the only way for this to work is to > have predictable syntax for parameters. > > The philosophy behind the syntax restriction is that interoperability is > often increased if implementations are prepared to handle all the cases > that may arise. Having these cases be part of a fixed, enumerated set > helps achieve this. Parsing is the easy part; understanding and > meaningfully handling the semantics of the messages is the harder part, > which is why this restriction intentionally imposes boundaries – so as > to limit the cases that implementations need to be prepared handle. First of all: it's pretty clear that you haven't written a conforming parser for WWW-Authenticate yet; you may want to look at the test cases at . Parsing definitively is *not* simple, and adding special cases over the generic syntax will make it even harder. In particular, using double quotes for something that isn't a quoted string is incompatible with the base syntax. (Yes, this is a show-stopper). > > 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. > > > > > > Done > > Thanks. > > Now that you have switched to HTTPbis you probably can get rid of the > reference to RFC 2617. > > The remaining reference is informational – not normative. > ... Yes, but what is it for? Best regards, Julian From julian.reschke@gmx.de Mon Sep 26 12:24: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 715E91F0C79 for ; Mon, 26 Sep 2011 12:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.142 X-Spam-Level: X-Spam-Status: No, score=-104.142 tagged_above=-999 required=5 tests=[AWL=-1.543, 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 Chr4rSR8S1Jk for ; Mon, 26 Sep 2011 12:24:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6848B1F0C77 for ; Mon, 26 Sep 2011 12:24:12 -0700 (PDT) Received: (qmail invoked by alias); 26 Sep 2011 19:26:54 -0000 Received: from p508F9B39.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.155.57] by mail.gmx.net (mp002) with SMTP; 26 Sep 2011 21:26:54 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19VB49UdShVSx3hji6cvk59KwB2tMaVkcjsUyZtAE 4tTWjntAWfBRbA Message-ID: <4E80D1FD.5020305@gmx.de> Date: Mon, 26 Sep 2011 21:26:53 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: William Mills References: <4E1F6AAD24975D4BA5B16804296739435C1FD669@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E7DC7DD.5010407@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C2148AE@TK5EX14MBXC285.redmond.corp.microsoft.com> <1317064846.35814.YahooMailNeo@web31805.mail.mud.yahoo.com> In-Reply-To: <1317064846.35814.YahooMailNeo@web31805.mail.mud.yahoo.com> Content-Type: text/plain; charset=UTF-8; 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 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: Mon, 26 Sep 2011 19:24:13 -0000 On 2011-09-26 21:20, William Mills wrote: > I'm gonna top reply... > > >> Is that intended and acceptable? >> >> No, b64token isn’t always there; the syntax specifies that either a > b64token OR one or more auth-params will be present. Yes, that’s intended. > > If the token can be transported in auth-params then I think you must > define how that will happen. It's too loose otherwise. Go with this > obvious and say if auth-parames are used then there must be a token= > parameter that carries the token. That way you are always guaranteed the > token is present in the protocol. > ... +1 In which case the syntax can get rid of the b64token special case altogether. Best regards, Julian From Michael.Jones@microsoft.com Mon Sep 26 13:07: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 E429421F8C12 for ; Mon, 26 Sep 2011 13:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 w6+dmhxIo0zk for ; Mon, 26 Sep 2011 13:07:36 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 69DD721F8C10 for ; Mon, 26 Sep 2011 13:07:36 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Sep 2011 13:10:15 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.193]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0339.002; Mon, 26 Sep 2011 13:10:15 -0700 From: Mike Jones To: Julian Reschke , William Mills Thread-Topic: [OAUTH-WG] draft-ietf-oauth-v2-bearer-08 HTTP syntax comments Thread-Index: Acx6TrJmwcQz5MGcQbCm3dgw87x/xAAnmxuAAGM0rVAAEIfAAAAANrCAAA0tbNA= Date: Mon, 26 Sep 2011 20:10:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C214CFE@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FD669@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E7DC7DD.5010407@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C2148AE@TK5EX14MBXC285.redmond.corp.microsoft.com> <1317064846.35814.YahooMailNeo@web31805.mail.mud.yahoo.com> <4E80D1FD.5020305@gmx.de> In-Reply-To: <4E80D1FD.5020305@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "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: Mon, 26 Sep 2011 20:07:37 -0000 R2V0dGluZyByaWQgb2YgdGhlIGI2NHRva2VuIHdvdWxkIGJlIGFuIHVubmVjZXNzYXJ5IGJyZWFr aW5nIGNoYW5nZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEp1bGlhbiBS ZXNjaGtlIFttYWlsdG86anVsaWFuLnJlc2Noa2VAZ214LmRlXSANClNlbnQ6IE1vbmRheSwgU2Vw dGVtYmVyIDI2LCAyMDExIDEyOjI3IFBNDQpUbzogV2lsbGlhbSBNaWxscw0KQ2M6IE1pa2UgSm9u ZXM7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBkcmFmdC1pZXRmLW9h dXRoLXYyLWJlYXJlci0wOCBIVFRQIHN5bnRheCBjb21tZW50cw0KDQpPbiAyMDExLTA5LTI2IDIx OjIwLCBXaWxsaWFtIE1pbGxzIHdyb3RlOg0KPiBJJ20gZ29ubmEgdG9wIHJlcGx5Li4uDQo+DQo+ ICA+PiBJcyB0aGF0IGludGVuZGVkIGFuZCBhY2NlcHRhYmxlPw0KPj4NCj4+ICBObywgYjY0dG9r ZW4gaXNu4oCZdCBhbHdheXMgdGhlcmU7IHRoZSBzeW50YXggc3BlY2lmaWVzIHRoYXQgZWl0aGVy IGENCj4gYjY0dG9rZW4gT1Igb25lIG9yIG1vcmUgYXV0aC1wYXJhbXMgd2lsbCBiZSBwcmVzZW50 LiBZZXMsIHRoYXTigJlzIGludGVuZGVkLg0KPg0KPiBJZiB0aGUgdG9rZW4gY2FuIGJlIHRyYW5z cG9ydGVkIGluIGF1dGgtcGFyYW1zIHRoZW4gSSB0aGluayB5b3UgbXVzdCANCj4gZGVmaW5lIGhv dyB0aGF0IHdpbGwgaGFwcGVuLiBJdCdzIHRvbyBsb29zZSBvdGhlcndpc2UuIEdvIHdpdGggdGhp cyANCj4gb2J2aW91cyBhbmQgc2F5IGlmIGF1dGgtcGFyYW1lcyBhcmUgdXNlZCB0aGVuIHRoZXJl IG11c3QgYmUgYSB0b2tlbj0gDQo+IHBhcmFtZXRlciB0aGF0IGNhcnJpZXMgdGhlIHRva2VuLiBU aGF0IHdheSB5b3UgYXJlIGFsd2F5cyBndWFyYW50ZWVkIA0KPiB0aGUgdG9rZW4gaXMgcHJlc2Vu dCBpbiB0aGUgcHJvdG9jb2wuDQo+IC4uLg0KDQorMQ0KDQpJbiB3aGljaCBjYXNlIHRoZSBzeW50 YXggY2FuIGdldCByaWQgb2YgdGhlIGI2NHRva2VuIHNwZWNpYWwgY2FzZSBhbHRvZ2V0aGVyLg0K DQpCZXN0IHJlZ2FyZHMsIEp1bGlhbg0KDQo= From julian.reschke@gmx.de Mon Sep 26 13:15: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 5CD711F0CD9 for ; Mon, 26 Sep 2011 13:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.132 X-Spam-Level: X-Spam-Status: No, score=-104.132 tagged_above=-999 required=5 tests=[AWL=-1.533, 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 zWxOtuffRvaj for ; Mon, 26 Sep 2011 13:15:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6F4BA1F0CDC for ; Mon, 26 Sep 2011 13:15:23 -0700 (PDT) Received: (qmail invoked by alias); 26 Sep 2011 20:18:06 -0000 Received: from p508F9B39.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.155.57] by mail.gmx.net (mp015) with SMTP; 26 Sep 2011 22:18:06 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18t9GsPdaQtMH0i910G8dGlfZTDVr7Vg7Otueu6Xh 6W7q02vbS6Whg+ Message-ID: <4E80DDFC.90607@gmx.de> Date: Mon, 26 Sep 2011 22:18:04 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B16804296739435C1FD669@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E7DC7DD.5010407@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C2148AE@TK5EX14MBXC285.redmond.corp.microsoft.com> <1317064846.35814.YahooMailNeo@web31805.mail.mud.yahoo.com> <4E80D1FD.5020305@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C214CFE@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C214CFE@TK5EX14MBXC285.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "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: Mon, 26 Sep 2011 20:15:24 -0000 On 2011-09-26 22:10, Mike Jones wrote: > Getting rid of the b64token would be an unnecessary breaking change. > ... You're at draft state, right? If you want to keep b64token *and* be able to use params, then you'll need an alternate syntax that puts the token into param (which, arguably, would have been the better choice anyway). Best regards, Julian From James.H.Manger@team.telstra.com Mon Sep 26 17:17: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 31B6811E80AA for ; Mon, 26 Sep 2011 17:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[AWL=-1.939, 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 fl+zpTroHVYM for ; Mon, 26 Sep 2011 17:17:53 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 09D9211E808A for ; Mon, 26 Sep 2011 17:17:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,447,1312120800"; d="scan'208";a="46732315" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 27 Sep 2011 10:20:33 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6481"; a="38075200" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccni.tcif.telstra.com.au with ESMTP; 27 Sep 2011 10:20:33 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 27 Sep 2011 10:20:33 +1000 From: "Manger, James H" To: Mike Jones , "oauth@ietf.org" Date: Tue, 27 Sep 2011 10:20:31 +1000 Thread-Topic: Proposed resolution for issue 26 Thread-Index: Acx5+RoYuC5sLQs0Spy/pi+T441Q9AAxktNwAG+nNNAACm0CwA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1128FE19FB2@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128E5D883D@WSMSG3153V.srv.dir.telstra.com> <4E1F6AAD24975D4BA5B16804296739435C214906@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C214906@TK5EX14MBXC285.redmond.corp.microsoft.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 27 Sep 2011 00:17:54 -0000 > While you take the viewpoint that the bearer spec is restricting scope va= lues, in fact, > the spec intentionally allows all characters that can be safely communica= ted in an HTTP > response header parameter to be used. But "all characters that can be safely communicated in an HTTP response hea= der parameter" is only a subset of the characters that OAuth Core allows in= a scope value (any Unicode string excluding space). I don't understand how= this isn't the Bearer spec restricting scope values. P.S. You recognize here that non-ASCII chars cannot be safely communicated = in an HTTP response header parameter. This is why Julian was concerned abou= t the spec saying the error_description holds raw UTF-8. [Actually the ABNF for error_description restricts it to 93 ASCII chars so = when the text says it is UTF-8 encoded it is raising the potential problem = of arbitrary UTF-8 in HTTP headers unnecessarily.] -- James Manger From andredemarre@gmail.com Mon Sep 26 18:30: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 D5FDF21F8E82 for ; Mon, 26 Sep 2011 18:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 NFLdDKaT5Ewu for ; Mon, 26 Sep 2011 18:30:24 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 34EA921F8E81 for ; Mon, 26 Sep 2011 18:30:24 -0700 (PDT) Received: by iaby26 with SMTP id y26so6377052iab.31 for ; Mon, 26 Sep 2011 18:33:06 -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=YyGJHYW7sCjsjcjhfO42TaUiyk/sm0uj8M4jr2KBijk=; b=bQKmNINo1PZocjLqgTNG8pdMVLdF0swMobe2QXXzCMwL/5PPMf9iKDRxDidimdW72R M/Td0gYoNVVKm1aQd0a1obHPbk6oK7JtaP9eC3pBAI7WSCEOb/Nn2/FTWJUFahfu1fqi +4UA9W5TtHFKzR8lHldtIdpu3CSvn0cx3Uf3Y= MIME-Version: 1.0 Received: by 10.42.108.2 with SMTP id f2mr8457629icp.130.1317087186606; Mon, 26 Sep 2011 18:33:06 -0700 (PDT) Received: by 10.42.18.129 with HTTP; Mon, 26 Sep 2011 18:33:06 -0700 (PDT) Date: Mon, 26 Sep 2011 18:33:06 -0700 Message-ID: From: =?ISO-8859-1?Q?Andr=E9_DeMarre?= To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] draft-ietf-oauth-v2-22 Section 8.4 Typo 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, 27 Sep 2011 01:30:24 -0000 draft-ietf-oauth-v2-22 section 8.4 says: "If a response type contains one of more space characters". I'm pretty sure that should be "one or more". Regards, Andre DeMarre From James.H.Manger@team.telstra.com Tue Sep 27 20:48: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 5397F21F8BDC for ; Tue, 27 Sep 2011 20:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-1.531, 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 0IqI3YSGY3qj for ; Tue, 27 Sep 2011 20:48:21 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2E21B21F8CBD for ; Tue, 27 Sep 2011 20:48:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,453,1312120800"; d="scan'208";a="49041916" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 28 Sep 2011 13:50:54 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6482"; a="37866575" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbvi.tcif.telstra.com.au with ESMTP; 28 Sep 2011 13:50:54 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Wed, 28 Sep 2011 13:50:53 +1000 From: "Manger, James H" To: Mike Jones , "oauth@ietf.org" Date: Wed, 28 Sep 2011 13:50:52 +1000 Thread-Topic: [OAUTH-WG] Proposed resolution for issue 26 Thread-Index: Acx5+RoYuC5sLQs0Spy/pi+T441Q9ABABAUAAGEPyiAAQvblAA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 28 Sep 2011 03:48:22 -0000 I'll have another go trying to explain the problem I see with the scope par= ameter in the Bearer spec. Consider a French social network that decides to offer an API using OAuth2.= It chooses 3 scope values for parts of the API related to family, friends,= and business colleagues: * "famille" * "ami" * "coll=E8gues" Let's focus on the last scope. The site describes the scope and its semantics in HTML developer docs. That= works.
collègues
...
Client apps construct authorization URIs to which users are sent. That work= s. https://example.fr/authz?scope=3Dcoll%C3%A8gues... The authorization server issues credentials in a JSON token response. That = works. { "access_token":"SlAV32hkKG", "scope":"coll\u00E8gues", ...} The authorization server also supports implicit grants. That works. Location: https://app.client.org/callback#scope=3Dcoll%C3%A8gues... Client apps request protected resources (without needing to mention scope).= That works. Authorization: Bearer vF9dft4qmT A protected resource server responds with a 401 error when a bearer token i= s wrong. They don't know what to put in the HTTP response header scope para= meter: "coll=E8gues" does not fit. One server knows HTTP headers have historically used ISO-8859-1. WWW-Authenticate: Bearer scope=3D"collgues", error_description=3D"opp= s"... Another server sees that error_description is specified as UTF-8 so uses th= at. WWW-Authenticate: Bearer scope=3D"collgues", error_description=3D= "opps"... A third server reasons that the value will be copied to an authz URI so use= s URI-escaping. WWW-Authenticate: Bearer scope=3D"coll%C3%A8gues", error_description=3D"o= pps"... A fourth server thinks JSON-escaping looks most like HTTP's quoted-string q= uoting (both use '\'). WWW-Authenticate: Bearer scope=3D"coll\u00E8gues", error_description=3D"o= pps"... A fifth uses RFC 5987 "Character Set and Language Encoding for HTTP Header = Field Parameters": WWW-Authenticate: Bearer scope*=3DUTF-8''coll%C3%A8gues, error_descriptio= n=3D"opps"... It is a total interoperability failure for the client apps. The paragraph i= n the Bearer spec saying the encoding of the scope values is up to each "pa= rticular deployment context" looks like a cruel joke to the app and library= developers. -- James Manger -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Tuesday, 27 September 2011 5:03 AM To: Barry Leiba Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 Sounds good to me. Are others good with this wording? -- Mike -----Original Message----- From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g= mail.com] On Behalf Of Barry Leiba Sent: Saturday, September 24, 2011 6:33 AM To: Mike Jones Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 > My proposed resolution is that %-encoding not be required in the=20 > specification I agree with your analysis, now that I see it laid out clearly. I would fe= el better, though, if there were text in the document that explained that t= o others, who read it later. Perhaps, using your words, we could make this= change to section 2.4: OLD The "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. The "scope" attribute MUST NOT appear more than once. NEW The "scope" attribute is a space-delimited list of scope values indicating the required scope of the access token for accessing the requested resource. The "scope" attribute MUST NOT appear more than once. Interpretation of scope strings requires semantic agreement on the meaning of the scope strings between the parties participating the OAuth flow. Should an encoding be used for scope strings in a particular deployment context, participants have to have agreed upon that encoding, just as they agree on other OAuth configuration parameters. Does that work? Barry From barryleiba.mailing.lists@gmail.com Wed Sep 28 06:37: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 18CEE21F87C2 for ; Wed, 28 Sep 2011 06:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.967 X-Spam-Level: X-Spam-Status: No, score=-102.967 tagged_above=-999 required=5 tests=[AWL=0.010, 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 Ord5Lc6YBAt8 for ; Wed, 28 Sep 2011 06:37:13 -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 EEE9921F87D6 for ; Wed, 28 Sep 2011 06:37:12 -0700 (PDT) Received: by yic13 with SMTP id 13so7574068yic.31 for ; Wed, 28 Sep 2011 06:40:01 -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=od3BlrOxT1zVj7j4Y+rVUGBXJOIfGIyR21YN2lvL4tQ=; b=OrgyQW499M4tZinwfWOZN/iFjZvFawoVqNvspZ4ag83eDddWKJolvhpOVD7WbkEb// sHDNaq67TW4B7bECDO5O39xJue4ry8M6Zy8ACingg4kOwwI9BISH8lSmPJSDPmFNTlz0 hrXb3pxcahLIMEizSC1YEVJlqeBHxhsNjdZjk= MIME-Version: 1.0 Received: by 10.236.187.36 with SMTP id x24mr55353734yhm.74.1317217201004; Wed, 28 Sep 2011 06:40:01 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Wed, 28 Sep 2011 06:40:00 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 28 Sep 2011 09:40:00 -0400 X-Google-Sender-Auth: NI4GrMPBgXTP1v-9wLHmWZlWQPM Message-ID: From: Barry Leiba To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 28 Sep 2011 13:37:14 -0000 I'd like to see more participation in this thread, besides just from Mike and James. What do others think? Barry, as chair On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones w= rote: > While you take the viewpoint that the bearer spec is restricting scope > values, in fact, the spec intentionally allows all characters that can be > safely communicated in an HTTP response header parameter to be > used. =A0About whether those characters employ an encoding > methodology to sometimes represent other characters or abstractions, > I believe that Barry's proposed wording hits the nail on the head: > > =A0 Interpretation of scope strings requires semantic agreement on the > =A0 meaning of the scope strings between the parties participating the > =A0 OAuth flow. =A0Should an encoding be used for scope strings in a > =A0 particular deployment context, participants have to have agreed > =A0 upon that encoding, just as they agree on other OAuth configuration > =A0 parameters. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Best wishe= s, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike On Mon, Sep 26, 2011 at 8:20 PM, Manger, James H wrote: >> While you take the viewpoint that the bearer spec is restricting scope v= alues, in fact, >> the spec intentionally allows all characters that can be safely communic= ated in an HTTP >> response header parameter to be used. > > But "all characters that can be safely communicated in an HTTP response > header parameter" is only a subset of the characters that OAuth Core > allows in a scope value (any Unicode string excluding space). I don't > understand how this isn't the Bearer spec restricting scope values. > > > P.S. You recognize here that non-ASCII chars cannot be safely > communicated in an HTTP response header parameter. This is why > Julian was concerned about the spec saying the error_description holds > raw UTF-8. > [Actually the ABNF for error_description restricts it to 93 ASCII chars s= o > when the text says it is UTF-8 encoded it is raising the potential proble= m > of arbitrary UTF-8 in HTTP headers unnecessarily.] > > -- > James Manger On Tue, Sep 27, 2011 at 11:50 PM, Manger, James H wrote: > I'll have another go trying to explain the problem I see with the scope > parameter in the Bearer spec. > > Consider a French social network that decides to offer an API using OAuth= 2. > It chooses 3 scope values for parts of the API related to family, friends= , and > business colleagues: > * "famille" > * "ami" > * "coll=E8gues" > Let's focus on the last scope. > > The site describes the scope and its semantics in HTML developer docs. > That works. > =A0
collègues
...
> > Client apps construct authorization URIs to which users are sent. > That works. > =A0https://example.fr/authz?scope=3Dcoll%C3%A8gues... > > The authorization server issues credentials in a JSON token response. > That works. > =A0{ "access_token":"SlAV32hkKG", "scope":"coll\u00E8gues", ...} > > The authorization server also supports implicit grants. That works. > =A0Location: https://app.client.org/callback#scope=3Dcoll%C3%A8gues... > > Client apps request protected resources (without needing to mention scope= ). > That works. > =A0Authorization: Bearer vF9dft4qmT > > A protected resource server responds with a 401 error when a bearer token > is wrong. They don't know what to put in the HTTP response header scope > parameter: "coll=E8gues" does not fit. > > One server knows HTTP headers have historically used ISO-8859-1. > =A0WWW-Authenticate: Bearer scope=3D"collgues", error_description=3D"= opps"... > > Another server sees that error_description is specified as UTF-8 so uses = that. > =A0WWW-Authenticate: Bearer scope=3D"collgues", error_description= =3D"opps"... > > A third server reasons that the value will be copied to an authz URI so u= ses > URI-escaping. > =A0WWW-Authenticate: Bearer scope=3D"coll%C3%A8gues", error_description= =3D"opps"... > > A fourth server thinks JSON-escaping looks most like HTTP's quoted-string > quoting (both use '\'). > =A0WWW-Authenticate: Bearer scope=3D"coll\u00E8gues", error_description= =3D"opps"... > > A fifth uses RFC 5987 "Character Set and Language Encoding for HTTP Heade= r > Field Parameters": > =A0WWW-Authenticate: Bearer scope*=3DUTF-8''coll%C3%A8gues, error_descrip= tion=3D"opps"... > > It is a total interoperability failure for the client apps. The paragraph= in the Bearer > spec saying the encoding of the scope values is up to each "particular > deployment context" looks like a cruel joke to the app and library develo= pers. > > -- > James Manger From julian.reschke@gmx.de Wed Sep 28 06:43: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 3F1A421F8CEA for ; Wed, 28 Sep 2011 06:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.368 X-Spam-Level: X-Spam-Status: No, score=-104.368 tagged_above=-999 required=5 tests=[AWL=-1.769, 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 rsVZPH3igjkZ for ; Wed, 28 Sep 2011 06:43:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2AF6A21F8CE8 for ; Wed, 28 Sep 2011 06:43:40 -0700 (PDT) Received: (qmail invoked by alias); 28 Sep 2011 13:46:24 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp059) with SMTP; 28 Sep 2011 15:46:24 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX198lbFkz7J8oZcmiUqUH8OExqO77bPZ8o873o27bS 2sviYsTT1ES0hL Message-ID: <4E83252F.40308@gmx.de> Date: Wed, 28 Sep 2011 15:46:23 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Barry Leiba References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 28 Sep 2011 13:43:42 -0000 On 2011-09-28 15:40, Barry Leiba wrote: > I'd like to see more participation in this thread, besides just from > Mike and James. What do others think? > > Barry, as chair > ... I agree that if a protocol element needs to support non-ASCII characters, the spec should be *crystal clear* how it's going to be transported over the wire. Note that before James' mail I wasn't even beware that the same the problem I noticed for error_description also affects much more relevant protocol elements. With my HTTPbis-editor hat on: - use a consistent way of encoding in all parts of the header fields, - and try to avoid raw UTF-8. There are alternatives, such as applying another round of percent-encoding, or using RFC 5987 encoding in the first place. Finally, what's best in other wire formats may not be the best in header fields; insisting to use the same encoding will cause pain. Best regards, Julian From Michael.Jones@microsoft.com Wed Sep 28 08:55: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 B640811E80BD for ; Wed, 28 Sep 2011 08:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.502 X-Spam-Level: X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, 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 TXys8xgE3l7m for ; Wed, 28 Sep 2011 08:55:48 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id B651A11E80C1 for ; Wed, 28 Sep 2011 08:55:48 -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, 28 Sep 2011 08:58:37 -0700 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.193]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0339.002; Wed, 28 Sep 2011 08:58:36 -0700 From: Mike Jones To: Barry Leiba , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Proposed resolution for issue 26 Thread-Index: Acx5+RoYuC5sLQs0Spy/pi+T441Q9ABABAUAAGEPyiAAQvblAAAlYWwAAAnX4mA= Date: Wed, 28 Sep 2011 15:58:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C21877F@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 28 Sep 2011 15:55:49 -0000 I'd also like to see more working group participation in this discussion. Thanks, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= arry Leiba Sent: Wednesday, September 28, 2011 6:40 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 I'd like to see more participation in this thread, besides just from Mike a= nd James. What do others think? Barry, as chair On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones w= rote: > While you take the viewpoint that the bearer spec is restricting scope=20 > values, in fact, the spec intentionally allows all characters that can=20 > be safely communicated in an HTTP response header parameter to be=20 > used. =A0About whether those characters employ an encoding methodology=20 > to sometimes represent other characters or abstractions, I believe=20 > that Barry's proposed wording hits the nail on the head: > > =A0 Interpretation of scope strings requires semantic agreement on the > =A0 meaning of the scope strings between the parties participating the > =A0 OAuth flow. =A0Should an encoding be used for scope strings in a > =A0 particular deployment context, participants have to have agreed > =A0 upon that encoding, just as they agree on other OAuth configuration > =A0 parameters. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Best wishe= s, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike On Mon, Sep 26, 2011 at 8:20 PM, Manger, James H wrote: >> While you take the viewpoint that the bearer spec is restricting=20 >> scope values, in fact, the spec intentionally allows all characters=20 >> that can be safely communicated in an HTTP response header parameter to = be used. > > But "all characters that can be safely communicated in an HTTP=20 > response header parameter" is only a subset of the characters that=20 > OAuth Core allows in a scope value (any Unicode string excluding=20 > space). I don't understand how this isn't the Bearer spec restricting sco= pe values. > > > P.S. You recognize here that non-ASCII chars cannot be safely=20 > communicated in an HTTP response header parameter. This is why Julian=20 > was concerned about the spec saying the error_description holds raw=20 > UTF-8. > [Actually the ABNF for error_description restricts it to 93 ASCII=20 > chars so when the text says it is UTF-8 encoded it is raising the=20 > potential problem of arbitrary UTF-8 in HTTP headers unnecessarily.] > > -- > James Manger On Tue, Sep 27, 2011 at 11:50 PM, Manger, James H wrote: > I'll have another go trying to explain the problem I see with the=20 > scope parameter in the Bearer spec. > > Consider a French social network that decides to offer an API using OAuth= 2. > It chooses 3 scope values for parts of the API related to family,=20 > friends, and business colleagues: > * "famille" > * "ami" > * "coll=E8gues" > Let's focus on the last scope. > > The site describes the scope and its semantics in HTML developer docs. > That works. > =A0
collègues
...
> > Client apps construct authorization URIs to which users are sent. > That works. > =A0https://example.fr/authz?scope=3Dcoll%C3%A8gues... > > The authorization server issues credentials in a JSON token response. > That works. > =A0{ "access_token":"SlAV32hkKG", "scope":"coll\u00E8gues", ...} > > The authorization server also supports implicit grants. That works. > =A0Location: https://app.client.org/callback#scope=3Dcoll%C3%A8gues... > > Client apps request protected resources (without needing to mention scope= ). > That works. > =A0Authorization: Bearer vF9dft4qmT > > A protected resource server responds with a 401 error when a bearer=20 > token is wrong. They don't know what to put in the HTTP response=20 > header scope > parameter: "coll=E8gues" does not fit. > > One server knows HTTP headers have historically used ISO-8859-1. > =A0WWW-Authenticate: Bearer scope=3D"collgues", error_description=3D"= opps"... > > Another server sees that error_description is specified as UTF-8 so uses = that. > =A0WWW-Authenticate: Bearer scope=3D"collgues", error_description= =3D"opps"... > > A third server reasons that the value will be copied to an authz URI=20 > so uses URI-escaping. > =A0WWW-Authenticate: Bearer scope=3D"coll%C3%A8gues", error_description= =3D"opps"... > > A fourth server thinks JSON-escaping looks most like HTTP's=20 > quoted-string quoting (both use '\'). > =A0WWW-Authenticate: Bearer scope=3D"coll\u00E8gues", error_description= =3D"opps"... > > A fifth uses RFC 5987 "Character Set and Language Encoding for HTTP=20 > Header Field Parameters": > =A0WWW-Authenticate: Bearer scope*=3DUTF-8''coll%C3%A8gues, error_descrip= tion=3D"opps"... > > It is a total interoperability failure for the client apps. The=20 > paragraph in the Bearer spec saying the encoding of the scope values=20 > is up to each "particular deployment context" looks like a cruel joke to = the app and library developers. > > -- > James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Wed Sep 28 09:33: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 00E9B1F0C86 for ; Wed, 28 Sep 2011 09:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 OYoL6KAxrcC7 for ; Wed, 28 Sep 2011 09:33:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2188D1F0C76 for ; Wed, 28 Sep 2011 09:33:54 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p8SGagmG009285 for ; Wed, 28 Sep 2011 09:36:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317227803; bh=1wwetPRcJrHWab3aky/3ocsTYH4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=VVO0IEZqtIYI+1qOQ7a0fZtsy8Z68yF8RdzOiLFkUd6xTri+K080dUN4B+qoe7nOR 8dkh01vhIb9oLLgzSyUuA== 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:x-system-of-record; b=ImjPKmPN5azpoF6ys0Ha4FPd1sjGUlAn/yNnUIGDukuF0BOIYdD6N7B29ivklHwWV W2cTiDQ43aRUkEMB3zNBg== Received: from ywp31 (ywp31.prod.google.com [10.192.16.31]) by hpaq7.eem.corp.google.com with ESMTP id p8SGVhIw015424 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 28 Sep 2011 09:36:41 -0700 Received: by ywp31 with SMTP id 31so10051846ywp.11 for ; Wed, 28 Sep 2011 09:36:41 -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; bh=4hNJrkq/Sce9L/Vf9wHcfkC+NPYt6zauUvdArUdbTz4=; b=ynKhTu/bAD79Nb5JVI8AzXXs79/rL7X7S4/bwzEzx2VHx6OqcIGJsvO9A7PvvOHc7Y 3UKy8Qy/5ltN0qCe2tnQ== Received: by 10.100.17.30 with SMTP id 30mr689210anq.79.1317227801230; Wed, 28 Sep 2011 09:36:41 -0700 (PDT) Received: by 10.100.17.30 with SMTP id 30mr689203anq.79.1317227801095; Wed, 28 Sep 2011 09:36:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.142.14 with HTTP; Wed, 28 Sep 2011 09:36:20 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> From: Marius Scurtescu Date: Wed, 28 Sep 2011 09:36:20 -0700 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=0016e6475cca2c2d1c04ae02ff6b X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 28 Sep 2011 16:33:59 -0000 --0016e6475cca2c2d1c04ae02ff6b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 28, 2011 at 6:40 AM, Barry Leiba wrote= : > I'd like to see more participation in this thread, besides just from > Mike and James. What do others think? > I think James made it pretty clear that we have a problem and that we have to solve it. One solution would be for the core spec to limit the characters that can be used in a scope, such that scopes are HTTP header safe. I think this would be pretty limiting and fragile. Another solution would be for the bearer spec to specify what escaping should be used. RFC 5987 seems like the only good choice. Marius > Barry, as chair > > On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones > wrote: > > While you take the viewpoint that the bearer spec is restricting scope > > values, in fact, the spec intentionally allows all characters that can = be > > safely communicated in an HTTP response header parameter to be > > used. About whether those characters employ an encoding > > methodology to sometimes represent other characters or abstractions, > > I believe that Barry's proposed wording hits the nail on the head: > > > > Interpretation of scope strings requires semantic agreement on the > > meaning of the scope strings between the parties participating the > > OAuth flow. Should an encoding be used for scope strings in a > > particular deployment context, participants have to have agreed > > upon that encoding, just as they agree on other OAuth configuration > > parameters. > > > > Best wishes, > > -- Mike > > > On Mon, Sep 26, 2011 at 8:20 PM, Manger, James H > wrote: > >> While you take the viewpoint that the bearer spec is restricting scope > values, in fact, > >> the spec intentionally allows all characters that can be safely > communicated in an HTTP > >> response header parameter to be used. > > > > But "all characters that can be safely communicated in an HTTP response > > header parameter" is only a subset of the characters that OAuth Core > > allows in a scope value (any Unicode string excluding space). I don't > > understand how this isn't the Bearer spec restricting scope values. > > > > > > P.S. You recognize here that non-ASCII chars cannot be safely > > communicated in an HTTP response header parameter. This is why > > Julian was concerned about the spec saying the error_description holds > > raw UTF-8. > > [Actually the ABNF for error_description restricts it to 93 ASCII chars > so > > when the text says it is UTF-8 encoded it is raising the potential > problem > > of arbitrary UTF-8 in HTTP headers unnecessarily.] > > > > -- > > James Manger > > > On Tue, Sep 27, 2011 at 11:50 PM, Manger, James H > wrote: > > I'll have another go trying to explain the problem I see with the scope > > parameter in the Bearer spec. > > > > Consider a French social network that decides to offer an API using > OAuth2. > > It chooses 3 scope values for parts of the API related to family, > friends, and > > business colleagues: > > * "famille" > > * "ami" > > * "coll=E8gues" > > Let's focus on the last scope. > > > > The site describes the scope and its semantics in HTML developer docs. > > That works. > >
collègues
...
> > > > Client apps construct authorization URIs to which users are sent. > > That works. > > https://example.fr/authz?scope=3Dcoll%C3%A8gues... > > > > The authorization server issues credentials in a JSON token response. > > That works. > > { "access_token":"SlAV32hkKG", "scope":"coll\u00E8gues", ...} > > > > The authorization server also supports implicit grants. That works. > > Location: https://app.client.org/callback#scope=3Dcoll%C3%A8gues... > > > > Client apps request protected resources (without needing to mention > scope). > > That works. > > Authorization: Bearer vF9dft4qmT > > > > A protected resource server responds with a 401 error when a bearer tok= en > > is wrong. They don't know what to put in the HTTP response header scope > > parameter: "coll=E8gues" does not fit. > > > > One server knows HTTP headers have historically used ISO-8859-1. > > WWW-Authenticate: Bearer scope=3D"collgues", > error_description=3D"opps"... > > > > Another server sees that error_description is specified as UTF-8 so use= s > that. > > WWW-Authenticate: Bearer scope=3D"collgues", > error_description=3D"opps"... > > > > A third server reasons that the value will be copied to an authz URI so > uses > > URI-escaping. > > WWW-Authenticate: Bearer scope=3D"coll%C3%A8gues", > error_description=3D"opps"... > > > > A fourth server thinks JSON-escaping looks most like HTTP's quoted-stri= ng > > quoting (both use '\'). > > WWW-Authenticate: Bearer scope=3D"coll\u00E8gues", > error_description=3D"opps"... > > > > A fifth uses RFC 5987 "Character Set and Language Encoding for HTTP > Header > > Field Parameters": > > WWW-Authenticate: Bearer scope*=3DUTF-8''coll%C3%A8gues, > error_description=3D"opps"... > > > > It is a total interoperability failure for the client apps. The paragra= ph > in the Bearer > > spec saying the encoding of the scope values is up to each "particular > > deployment context" looks like a cruel joke to the app and library > developers. > > > > -- > > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e6475cca2c2d1c04ae02ff6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 28, 2011 at 6:40 AM, Barry Leiba <barryleiba@co= mputer.org> wrote:
I'd like to see more participation in this thread, besides just from Mike and James. =A0What do others think?

I think James made it pretty clear that we have a problem and that we hav= e to solve it.

One solution would be for the core = spec to limit the characters that can be used in a scope, such that scopes = are HTTP header safe. I think this would be pretty limiting and fragile.

Another solution would be for the bearer spec to specif= y what escaping should be used.=A0RFC 5987 seems like the only good choice.

Marius


Barry, as chair

On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> While you take the viewpoint that the bearer spec is restricting scope=
> values, in fact, the spec intentionally allows all characters that can= be
> safely communicated in an HTTP response header parameter to be
> used. =A0About whether those characters employ= an encoding
> methodology to sometimes represent other characters or abstractions, > I believe that Barry's proposed wording hits the nail on the head:=
>
> =A0 Interpretation of scope strings requires s= emantic agreement on the
> =A0 meaning of the scope strings between the parties participating the=
> =A0 OAuth flow. =A0Should an encoding be used for scope strings in a > =A0 particular deployment context, participants have to have agreed > =A0 upon that encoding, just as they agree on other OAuth configuratio= n
> =A0 parameters.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0B= est wishes,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike=


On Mon, Sep 26, 2011 at 8:20 PM, Manger, James H
<James.H.Manger@team.= telstra.com> wrote:
>> While you take the viewpoint that the bearer spec is restricting s= cope values, in fact,
>> the spec intentionally allows all characters that can be safely co= mmunicated in an HTTP
>> response header parameter to be used.
>
> But "all characters that can be safely communicated in an HTTP re= sponse
> header parameter" is only a subset of the characters that OAuth C= ore
> allows in a scope value (any Unicode string excluding space). I don= 9;t
> understand how this isn't the Bearer spec restricting scope values= .
>
>
> P.S. You recognize here that non-ASCII chars cannot be safely
> communicated in an HTTP response header parameter. This is why
> Julian was concerned about the spec saying the error_description holds=
> raw UTF-8.
> [Actually the ABNF for error_description restricts it to 93 ASCII char= s so
> when the text says it is UTF-8 encoded it is raising the potential pro= blem
> of arbitrary UTF-8 in HTTP headers unnecessarily.]
>
> --
> James Manger


On Tue, Sep 27, 2011 at 11:50= PM, Manger, James H
<James.H.Manger@team.= telstra.com> wrote:
> I'll have another go trying to explain the problem I see with the = scope
> parameter in the Bearer spec.
>
> Consider a French social network that decides to offer an API using OA= uth2.
> It chooses 3 scope values for parts of the API related to family, frie= nds, and
> business colleagues:
> * "famille"
> * "ami"
> * "coll=E8gues"
> Let's focus on the last scope.
>
> The site describes the scope and its semantics in HTML developer docs.=
> That works.
> =A0<dt>coll&#xE8;gues</dt><dd>...</dd>
>
> Client apps construct authorization URIs to which users are sent.
> That works.
> =A0https://example.fr/authz?scope=3Dcoll%C3%A8gues...
>
> The authorization server issues credentials in a JSON token response.<= br> > That works.
> =A0{ "access_token":"SlAV32hkKG", "scope"= ;:"coll\u00E8gues", ...}
>
> The authorization server also supports implicit grants. That works. > =A0Location: https://app.client.org/callback#scope=3Dcoll%C= 3%A8gues...
>
> Client apps request protected resources (without needing to mention sc= ope).
> That works.
> =A0Authorization: Bearer vF9dft4qmT
>
> A protected resource server responds with a 401 error when a bearer to= ken
> is wrong. They don't know what to put in the HTTP response header = scope
> parameter: "coll=E8gues" does not fit.
>
> One server knows HTTP headers have historically used ISO-8859-1.
> =A0WWW-Authenticate: Bearer scope=3D"coll<E8>gues", er= ror_description=3D"opps"...
>
> Another server sees that error_description is specified as UTF-8 so us= es that.
> =A0WWW-Authenticate: Bearer scope=3D"coll<C3><A8>gues= ", error_description=3D"opps"...
>
> A third server reasons that the value will be copied to an authz URI s= o uses
> URI-escaping.
> =A0WWW-Authenticate: Bearer scope=3D"coll%C3%A8gues", error_= description=3D"opps"...
>
> A fourth server thinks JSON-escaping looks most like HTTP's quoted= -string
> quoting (both use '\').
> =A0WWW-Authenticate: Bearer scope=3D"coll\u00E8gues", error_= description=3D"opps"...
>
> A fifth uses RFC 5987 "Character Set and Language Encoding for HT= TP Header
> Field Parameters":
> =A0WWW-Authenticate: Bearer scope*=3DUTF-8''coll%C3%A8gues, er= ror_description=3D"opps"...
>
> It is a total interoperability failure for the client apps. The paragr= aph in the Bearer
> spec saying the encoding of the scope values is up to each "parti= cular
> deployment context" looks like a cruel joke to the app and librar= y developers.
>
> --
> James Manger
_______________________= ________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e6475cca2c2d1c04ae02ff6b-- From bcampbell@pingidentity.com Thu Sep 29 06:54: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 A72C421F8D66 for ; Thu, 29 Sep 2011 06:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.071, 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 tUS3vZvWCQxz for ; Thu, 29 Sep 2011 06:54:22 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAA521F8D68 for ; Thu, 29 Sep 2011 06:54:20 -0700 (PDT) Received: from mail-qy0-f169.google.com ([209.85.216.169]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKToR5MSc0rTXX+hyLF6IeIl8xKe79tfWl@postini.com; Thu, 29 Sep 2011 06:57:13 PDT Received: by mail-qy0-f169.google.com with SMTP id 38so4188856qyl.14 for ; Thu, 29 Sep 2011 06:57:05 -0700 (PDT) Received: by 10.224.212.8 with SMTP id gq8mr7794060qab.377.1317304624102; Thu, 29 Sep 2011 06:57:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.19.196 with HTTP; Thu, 29 Sep 2011 06:56:33 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> From: Brian Campbell Date: Thu, 29 Sep 2011 07:56:33 -0600 Message-ID: To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Barry Leiba , oauth@ietf.org Subject: Re: [OAUTH-WG] Proposed resolution for issue 26 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, 29 Sep 2011 13:54:25 -0000 +1 to "I think James made it pretty clear that we have a problem and that we have to solve it." On Wed, Sep 28, 2011 at 10:36 AM, Marius Scurtescu wrote: > On Wed, Sep 28, 2011 at 6:40 AM, Barry Leiba > wrote: >> >> I'd like to see more participation in this thread, besides just from >> Mike and James. =A0What do others think? > > I think James made it pretty clear that we have a problem and that we hav= e > to solve it. > One solution would be for the core spec to limit the characters that can = be > used in a scope, such that scopes are HTTP header safe. I think this woul= d > be pretty limiting and fragile. > Another solution would be for the bearer spec to specify what escaping > should be used.=A0RFC 5987 seems like the only good choice. > Marius >> >> Barry, as chair >> >> On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones >> wrote: >> > While you take the viewpoint that the bearer spec is restricting scope >> > values, in fact, the spec intentionally allows all characters that can >> > be >> > safely communicated in an HTTP response header parameter to be >> > used. =A0About whether those characters employ an encoding >> > methodology to sometimes represent other characters or abstractions, >> > I believe that Barry's proposed wording hits the nail on the head: >> > >> > =A0 Interpretation of scope strings requires semantic agreement on the >> > =A0 meaning of the scope strings between the parties participating the >> > =A0 OAuth flow. =A0Should an encoding be used for scope strings in a >> > =A0 particular deployment context, participants have to have agreed >> > =A0 upon that encoding, just as they agree on other OAuth configuratio= n >> > =A0 parameters. >> > >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Best wi= shes, >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike >> >> >> On Mon, Sep 26, 2011 at 8:20 PM, Manger, James H >> wrote: >> >> While you take the viewpoint that the bearer spec is restricting scop= e >> >> values, in fact, >> >> the spec intentionally allows all characters that can be safely >> >> communicated in an HTTP >> >> response header parameter to be used. >> > >> > But "all characters that can be safely communicated in an HTTP respons= e >> > header parameter" is only a subset of the characters that OAuth Core >> > allows in a scope value (any Unicode string excluding space). I don't >> > understand how this isn't the Bearer spec restricting scope values. >> > >> > >> > P.S. You recognize here that non-ASCII chars cannot be safely >> > communicated in an HTTP response header parameter. This is why >> > Julian was concerned about the spec saying the error_description holds >> > raw UTF-8. >> > [Actually the ABNF for error_description restricts it to 93 ASCII char= s >> > so >> > when the text says it is UTF-8 encoded it is raising the potential >> > problem >> > of arbitrary UTF-8 in HTTP headers unnecessarily.] >> > >> > -- >> > James Manger >> >> >> On Tue, Sep 27, 2011 at 11:50 PM, Manger, James H >> wrote: >> > I'll have another go trying to explain the problem I see with the scop= e >> > parameter in the Bearer spec. >> > >> > Consider a French social network that decides to offer an API using >> > OAuth2. >> > It chooses 3 scope values for parts of the API related to family, >> > friends, and >> > business colleagues: >> > * "famille" >> > * "ami" >> > * "coll=E8gues" >> > Let's focus on the last scope. >> > >> > The site describes the scope and its semantics in HTML developer docs. >> > That works. >> > =A0
collègues
...
>> > >> > Client apps construct authorization URIs to which users are sent. >> > That works. >> > =A0https://example.fr/authz?scope=3Dcoll%C3%A8gues... >> > >> > The authorization server issues credentials in a JSON token response. >> > That works. >> > =A0{ "access_token":"SlAV32hkKG", "scope":"coll\u00E8gues", ...} >> > >> > The authorization server also supports implicit grants. That works. >> > =A0Location: https://app.client.org/callback#scope=3Dcoll%C3%A8gues... >> > >> > Client apps request protected resources (without needing to mention >> > scope). >> > That works. >> > =A0Authorization: Bearer vF9dft4qmT >> > >> > A protected resource server responds with a 401 error when a bearer >> > token >> > is wrong. They don't know what to put in the HTTP response header scop= e >> > parameter: "coll=E8gues" does not fit. >> > >> > One server knows HTTP headers have historically used ISO-8859-1. >> > =A0WWW-Authenticate: Bearer scope=3D"collgues", >> > error_description=3D"opps"... >> > >> > Another server sees that error_description is specified as UTF-8 so us= es >> > that. >> > =A0WWW-Authenticate: Bearer scope=3D"collgues", >> > error_description=3D"opps"... >> > >> > A third server reasons that the value will be copied to an authz URI s= o >> > uses >> > URI-escaping. >> > =A0WWW-Authenticate: Bearer scope=3D"coll%C3%A8gues", >> > error_description=3D"opps"... >> > >> > A fourth server thinks JSON-escaping looks most like HTTP's >> > quoted-string >> > quoting (both use '\'). >> > =A0WWW-Authenticate: Bearer scope=3D"coll\u00E8gues", >> > error_description=3D"opps"... >> > >> > A fifth uses RFC 5987 "Character Set and Language Encoding for HTTP >> > Header >> > Field Parameters": >> > =A0WWW-Authenticate: Bearer scope*=3DUTF-8''coll%C3%A8gues, >> > error_description=3D"opps"... >> > >> > It is a total interoperability failure for the client apps. The >> > paragraph in the Bearer >> > spec saying the encoding of the scope values is up to each "particular >> > deployment context" looks like a cruel joke to the app and library >> > developers. >> > >> > -- >> > James Manger >> _______________________________________________ >> 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 Thu Sep 29 11:49: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 602E121F8EA4 for ; Thu, 29 Sep 2011 11:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.095, 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 rzFICKsogPxL for ; Thu, 29 Sep 2011 11:49:51 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 460D821F8E93 for ; Thu, 29 Sep 2011 11:49:51 -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, 29 Sep 2011 11:52:43 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0339.002; Thu, 29 Sep 2011 11:52:36 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Possible alternative resolution to issue 26 Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8g== Date: Thu, 29 Sep 2011 18:52:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.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.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C21DD2CTK5EX14MBXC284r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Possible alternative resolution to issue 26 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, 29 Sep 2011 18:49:52 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C21DD2CTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There seems to now be more working group interest in representing non-ASCII= characters in scope strings than had previously been in evidence. If we d= ecide to define a standard representation for doing so, using RFC 5987 (Character Set and Language Encoding for Hy= pertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the c= lear choice. I'd be interested in knowing how many working group members a= re in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying = UTF-8 encoding of the error_description value, requesting the use of RFC 59= 87 encoding instead. I'd also be interested in knowing how many working gr= oup members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description paramete= r. (As editor, I would make the observation that if we choose RFC 5987 encodin= g for either of these parameters, it would be logical to do so for the othe= r one as well.) In the interest of finishing the specification in a way that meets everyone= 's needs, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435C21DD2CTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There seems to now be more working group interest in= representing non-ASCII characters in scope strings than had previously bee= n in evidence.  If we decide to define a standard representation for d= oing so, using RFC 5987 (Character Set = and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field P= arameters) seems to be the clear choice.  I’d be interested in k= nowing how many working group members are in favor of either:

 

1.  Using RFC 5987 encoding for the scope param= eter.

2.  Continuing to specify no non-ASCII encoding= for scope parameter values.

 

As a related issue, some working group members have = objected to specifying UTF-8 encoding of the error_description value, reque= sting the use of RFC 5987 encoding instead.  I’d also be interes= ted in knowing how many working group members are in favor of either:

 

A.  Using RFC 5987 encoding for the error_descr= iption parameter.

B.  Continuing to specify UTF-8 encoding for th= e error_description parameter.

 

(As editor, I would make the observation that if we = choose RFC 5987 encoding for either of these parameters, it would be logica= l to do so for the other one as well.)

 

In the interest of finishing the specification in a = way that meets everyone’s needs,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435C21DD2CTK5EX14MBXC284r_-- From buhake@googlemail.com Fri Sep 30 05:00: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 58A4521F8B3C for ; Fri, 30 Sep 2011 05:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 InHVKkY-31C0 for ; Fri, 30 Sep 2011 05:00:57 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E48921F8B3A for ; Fri, 30 Sep 2011 05:00:56 -0700 (PDT) Received: by fxd18 with SMTP id 18so3105373fxd.31 for ; Fri, 30 Sep 2011 05:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sBR7wZRFX0OV/UJUUdxFr7Q2jp8fb+5baZFUTcWFYpQ=; b=i+op2B5QGWJTzA6V2Z7DsANZvXo4cIlFBdJkxt7rfa2bBHaJwAW/kUqchgnFF/nsZm 719cZd4jrL1J5YnDaNHvxKT+tXVirBRcFUICoPwWE+1K2dJWP0K6wkRiY4dXruCvq0ef v6zL40UXfmjDSpBDZnhUBHZZfekMeRT0r68xI= Received: by 10.223.56.67 with SMTP id x3mr12875050fag.64.1317384230313; Fri, 30 Sep 2011 05:03:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.24.98 with HTTP; Fri, 30 Sep 2011 05:03:30 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Buhake Sindi Date: Fri, 30 Sep 2011 14:03:30 +0200 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001517448904149f6004ae276b52 X-Mailman-Approved-At: Fri, 30 Sep 2011 06:07:51 -0700 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 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, 30 Sep 2011 12:09:14 -0000 --001517448904149f6004ae276b52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everyone, As for encoding, my understanding is that the scope parameter were scope fields provided by the service provider and that scope should match the service provider scope. Fair enough, we could argue that non-UTF-8 characters can't be sent over HTTP response headers, so a better solution, = I would suggest is illustrated in section 4.2, Error Handling, of RFC 5987. My solution: add an encoding as a value of the scope and error-desc, followed by a colon (:) and then the percentage-encoded message. So, the message, is first encoded to the encoding specified, and then percentage-encoded: Example: error-descr=3D"UTF-8: " The client would then: 1. Percentage decode the string and get the string based on the encoding= . Problem is though, the length of the string value. Any thoughts? On 29 September 2011 20:52, Mike Jones wrote: > There seems to now be more working group interest in representing > non-ASCII characters in scope strings than had previously been in evidenc= e. > If we decide to define a standard representation for doing so, using RFC > 5987 (Character Set and Language > Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters) > seems to be the clear choice. I=E2=80=99d be interested in knowing how m= any working > group members are in favor of either:**** > > ** ** > > 1. Using RFC 5987 encoding for the scope parameter.**** > > 2. Continuing to specify no non-ASCII encoding for scope parameter value= s. > **** > > ** ** > > As a related issue, some working group members have objected to specifyin= g > UTF-8 encoding of the error_description value, requesting the use of RFC > 5987 encoding instead. I=E2=80=99d also be interested in knowing how man= y working > group members are in favor of either:**** > > ** ** > > A. Using RFC 5987 encoding for the error_description parameter.**** > > B. Continuing to specify UTF-8 encoding for the error_description > parameter.**** > > ** ** > > (As editor, I would make the observation that if we choose RFC 5987 > encoding for either of these parameters, it would be logical to do so for > the other one as well.)**** > > ** ** > > In the interest of finishing the specification in a way that meets > everyone=E2=80=99s needs,**** > > -- Mike**** > > ** ** > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 The Elite Gentleman --001517448904149f6004ae276b52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everyone,

As for encoding, my understanding is that the scope par= ameter were scope fields provided by the service provider and that scope sh= ould match the service provider scope. Fair enough, we could argue that non= -UTF-8 characters can't be sent over HTTP response headers, so a better= solution, I would suggest is illustrated in section 4.2, Error Handling, o= f RFC 5987.

My solution: add an encoding as a value of the scope and error-desc, fo= llowed by a colon (:) and then the percentage-encoded message.

So, t= he message, is first encoded to the encoding specified, and then percentage= -encoded:

Example:

error-descr=3D"UTF-8: <percentage-encoded of an= UTF-8 message>"

The client would then:
  1. Percentag= e decode the string and get the string based on the encoding.
Prob= lem is though, the length of the string value.


Any thoughts?

On 29 September 201= 1 20:52, Mike Jones <Michael.Jones@microsoft.com> wrote:

There seems to now be more working group interest in= representing non-ASCII characters in scope strings than had previously bee= n in evidence.=C2=A0 If we decide to define a standard representation for d= oing so, using RFC 5987 (Character Set and Language Encoding for Hypertext Transfer Protocol (HT= TP) Header Field Parameters) seems to be the clear choice.=C2=A0 I=E2=80=99= d be interested in knowing how many working group members are in favor of either:

=C2=A0

1.=C2=A0 Using RFC 5987 encoding for the scope param= eter.

2.=C2=A0 Continuing to specify no non-ASCII encoding= for scope parameter values.

=C2=A0

As a related issue, some working group members have = objected to specifying UTF-8 encoding of the error_description value, reque= sting the use of RFC 5987 encoding instead.=C2=A0 I=E2=80=99d also be inter= ested in knowing how many working group members are in favor of either:

=C2=A0

A.=C2=A0 Using RFC 5987 encoding for the error_descr= iption parameter.

B.=C2=A0 Continuing to specify UTF-8 encoding for th= e error_description parameter.

=C2=A0

(As editor, I would make the observation that if we = choose RFC 5987 encoding for either of these parameters, it would be logica= l to do so for the other one as well.)

=C2=A0

In the interest of finishing the specification in a = way that meets everyone=E2=80=99s needs,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 -- Mike

=C2=A0


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




--
The Elite Gentleman=
--001517448904149f6004ae276b52-- From julian.reschke@gmx.de Fri Sep 30 06: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 DE0C121F8B5B for ; Fri, 30 Sep 2011 06:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.347 X-Spam-Level: X-Spam-Status: No, score=-104.347 tagged_above=-999 required=5 tests=[AWL=-1.748, 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 0vjZlbtjob00 for ; Fri, 30 Sep 2011 06:19:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 794D621F8B57 for ; Fri, 30 Sep 2011 06:19:13 -0700 (PDT) Received: (qmail invoked by alias); 30 Sep 2011 13:22:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 30 Sep 2011 15:22:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19zSUMeQHZz3dU3l3pd8RrNSc3Dy2ss8+wwfkzv1a lrZBWqGqThz9Y1 Message-ID: <4E85C27C.3030909@gmx.de> Date: Fri, 30 Sep 2011 15:22:04 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Buhake Sindi References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 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, 30 Sep 2011 13:19:15 -0000 On 2011-09-30 14:03, Buhake Sindi wrote: > Hi everyone, > > As for encoding, my understanding is that the scope parameter were scope > fields provided by the service provider and that scope should match the > service provider scope. Fair enough, we could argue that non-UTF-8 > characters can't be sent over HTTP response headers, so a better > solution, I would suggest is illustrated in section 4.2, Error Handling, > of RFC 5987. > > My solution: add an encoding as a value of the scope and error-desc, > followed by a colon (:) and then the percentage-encoded message. Why invent yet another format that's close to RFC 5987 but not the same? > So, the message, is first encoded to the encoding specified, and then > percentage-encoded: > > Example: > > error-descr="UTF-8: " > > The client would then: > > 1. Percentage decode the string and get the string based on the encoding. > > Problem is though, the length of the string value. How is that a problem? > ... Best regards, Julian From Michael.Jones@microsoft.com Fri Sep 30 08:17: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 515E421F8AC9 for ; Fri, 30 Sep 2011 08:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.092, 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 XmDQOrlJwyci for ; Fri, 30 Sep 2011 08:17:13 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 6826121F8A55 for ; Fri, 30 Sep 2011 08:17:13 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 30 Sep 2011 08:20:07 -0700 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.142]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Fri, 30 Sep 2011 08:20:07 -0700 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Possible alternative resolution to issue 26 Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8gAq0NMw Date: Fri, 30 Sep 2011 15:20:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739435C21FB70@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.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.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739435C21FB70TK5EX14MBXC284r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 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, 30 Sep 2011 15:17:15 -0000 --_000_4E1F6AAD24975D4BA5B16804296739435C21FB70TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thus far, I've received no responses preferring 1 or 2 or preferring A or B= . Could people please weigh in so that the working group has data to base = a decision on to close this issue? Thanks, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Thursday, September 29, 2011 11:53 AM To: oauth@ietf.org Subject: [OAUTH-WG] Possible alternative resolution to issue 26 There seems to now be more working group interest in representing non-ASCII= characters in scope strings than had previously been in evidence. If we d= ecide to define a standard representation for doing so, using RFC 5987 (Character Set and Language Encoding for Hy= pertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the c= lear choice. I'd be interested in knowing how many working group members a= re in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying = UTF-8 encoding of the error_description value, requesting the use of RFC 59= 87 encoding instead. I'd also be interested in knowing how many working gr= oup members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description paramete= r. (As editor, I would make the observation that if we choose RFC 5987 encodin= g for either of these parameters, it would be logical to do so for the othe= r one as well.) In the interest of finishing the specification in a way that meets everyone= 's needs, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739435C21FB70TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thus far, I’ve r= eceived no responses preferring 1 or 2 or preferring A or B.  Could pe= ople please weigh in so that the working group has data to base a decision = on to close this issue?

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Thanks,

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      -- Mike

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, September 29, 2011 11:53 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Possible alternative resolution to issue 26=

 

There seems to now be more working group interest in= representing non-ASCII characters in scope strings than had previously bee= n in evidence.  If we decide to define a standard representation for d= oing so, using RFC 5987 (Character Set = and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field P= arameters) seems to be the clear choice.  I’d be interested in k= nowing how many working group members are in favor of either:

 

1.  Using RFC 5987 encoding for the scope param= eter.

2.  Continuing to specify no non-ASCII encoding= for scope parameter values.

 

As a related issue, some working group members have = objected to specifying UTF-8 encoding of the error_description value, reque= sting the use of RFC 5987 encoding instead.  I’d also be interes= ted in knowing how many working group members are in favor of either:

 

A.  Using RFC 5987 encoding for the error_descr= iption parameter.

B.  Continuing to specify UTF-8 encoding for th= e error_description parameter.

 

(As editor, I would make the observation that if we = choose RFC 5987 encoding for either of these parameters, it would be logica= l to do so for the other one as well.)

 

In the interest of finishing the specification in a = way that meets everyone’s needs,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike

 

--_000_4E1F6AAD24975D4BA5B16804296739435C21FB70TK5EX14MBXC284r_-- From eran@hueniverse.com Fri Sep 30 08:40: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 4184B21F8BF8 for ; Fri, 30 Sep 2011 08:40:07 -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 eyHYwM4m6Fkb for ; Fri, 30 Sep 2011 08:40: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 C9A1821F8BDE for ; Fri, 30 Sep 2011 08:40:04 -0700 (PDT) Received: (qmail 4294 invoked from network); 30 Sep 2011 15:36:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Sep 2011 15:36:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 30 Sep 2011 08:36:07 -0700 From: Eran Hammer-Lahav To: Mike Jones , "oauth@ietf.org" Date: Fri, 30 Sep 2011 08:35:57 -0700 Thread-Topic: Possible alternative resolution to issue 26 Thread-Index: Acx+2PHmt3CFeZd3Q9qsd+qVAY1q8gAq0NMwAABIBOA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452602A4B2F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739435C21FB70@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435C21FB70@TK5EX14MBXC284.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_90C41DD21FB7C64BB94121FBBC2E723452602A4B2FP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 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, 30 Sep 2011 15:40:07 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723452602A4B2FP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Two observations: - I doubt anyone is going to implement RFC 5987 in most OAuth 2.0 = libraries, mostly because it offers little value and, - No one really needs scope values other than limited ASCII or URI= s There should not be any interoperability issues with the error_description = value as long as it is valid for HTTP transport because it is for debugging= only. If a provider returns some other character set than plain ASCII in t= here, it is safe to assume the developer will figure it out. The fact that the v2 spec allows a wide range of characters in scope was un= intentional. The design was limited to allow simple ASCII strings and URIs.= Crossing the boundaries of v2 into the bearer spec is the first place wher= e this flexibility has been tested. Scope are machine-readable strings and URIs already provide a way to includ= e internationalization. OAuth parameters are all in English and it is reaso= nable to expect most providers to craft their scope values within those und= eclared boundaries. I am not expressing a strong opinion because I don't think this is a real i= ssue. Internationalization matters when it comes to end-user interaction, n= ot developers. But the most consistent choice based on the past 2 years of = use cases and examples is to simply limit the scope character-set in v2 and= avoid all this. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, September 30, 2011 8:20 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 Thus far, I've received no responses preferring 1 or 2 or preferring A or B= . Could people please weigh in so that the working group has data to base = a decision on to close this issue? Thanks, -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Mike = Jones Sent: Thursday, September 29, 2011 11:53 AM To: oauth@ietf.org Subject: [OAUTH-WG] Possible alternative resolution to issue 26 There seems to now be more working group interest in representing non-ASCII= characters in scope strings than had previously been in evidence. If we d= ecide to define a standard representation for doing so, using RFC 5987 (Character Set and Language Encoding for Hy= pertext Transfer Protocol (HTTP) Header Field Parameters) seems to be the c= lear choice. I'd be interested in knowing how many working group members a= re in favor of either: 1. Using RFC 5987 encoding for the scope parameter. 2. Continuing to specify no non-ASCII encoding for scope parameter values. As a related issue, some working group members have objected to specifying = UTF-8 encoding of the error_description value, requesting the use of RFC 59= 87 encoding instead. I'd also be interested in knowing how many working gr= oup members are in favor of either: A. Using RFC 5987 encoding for the error_description parameter. B. Continuing to specify UTF-8 encoding for the error_description paramete= r. (As editor, I would make the observation that if we choose RFC 5987 encodin= g for either of these parameters, it would be logical to do so for the othe= r one as well.) In the interest of finishing the specification in a way that meets everyone= 's needs, -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E723452602A4B2FP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Two observations:

<= span style=3D'color:#1F497D'> 

-     &nb= sp;    I doubt anyone is going to implement RFC 598= 7 in most OAuth 2.0 libraries, mostly because it offers little value and,

-          <= /span>No one= really needs scope values other than limited ASCII or URIs

 <= /span>

There should n= ot be any interoperability issues with the error_description value as long = as it is valid for HTTP transport because it is for debugging only. If a pr= ovider returns some other character set than plain ASCII in there, it is sa= fe to assume the developer will figure it out.

 

The fact that the v2 spec a= llows a wide range of characters in scope was unintentional. The design was= limited to allow simple ASCII strings and URIs. Crossing the boundaries of= v2 into the bearer spec is the first place where this flexibility has been= tested.

 

Scope are machine-readable strings and URIs already provide a way= to include internationalization. OAuth parameters are all in English and i= t is reasonable to expect most providers to craft their scope values within= those undeclared boundaries.

 

I am not expressing a strong opinion because= I don’t think this is a real issue. Internationalization matters whe= n it comes to end-user interaction, not developers. But the most consistent= choice based on the past 2 years of use cases and examples is to simply li= mit the scope character-set in v2 and avoid all this.

=

 =

EHL

 

 

From: oauth-bounces@ie= tf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, September 30, 2011 8:20 AM
To: oauth@ietf.org<= br>Subject: Re: [OAUTH-WG] Possible alternative resolution to issue = 26

 <= /p>

Thus far, I’ve = received no responses preferring 1 or 2 or preferring A or B.  Could p= eople please weigh in so that the working group has data to base a decision= on to close this issue?

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; Thanks,

          &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           -- Mike

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] O= n Behalf Of Mike Jones
Sent: Thursday, September 29, 2011 11:= 53 AM
To: oauth@ietf.orgSubject: [OAUTH-WG] Possible alternative resolution to issue 26

 

There seems to now be more working group interest in repr= esenting non-ASCII characters in scope strings than had previously been in = evidence.  If we decide to define a standard representation for doing = so, using RFC 5987 (Char= acter Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Head= er Field Parameters) seems to be the clear choice.  I’d be inter= ested in knowing how many working group members are in favor of either:

 

1= .  Using RFC 5987 encoding for the scope parameter.

2.  Continuing to specify no non-ASCII encoding for s= cope parameter values.

 =

As a related issue, some working group members hav= e objected to specifying UTF-8 encoding of the error_description value, req= uesting the use of RFC 5987 encoding instead.  I’d also be inter= ested in knowing how many working group members are in favor of either:

 

A= .  Using RFC 5987 encoding for the error_description parameter.

B.  Continuing to specify UTF-8 encoding = for the error_description parameter.

 

(As editor, I would make the observa= tion that if we choose RFC 5987 encoding for either of these parameters, it= would be logical to do so for the other one as well.)

 

In the interest of= finishing the specification in a way that meets everyone’s needs,

       =             &nb= sp;            =             &nb= sp;            =    -- Mike

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723452602A4B2FP3PW5EX1MB01E_-- From d.tangren@gmail.com Fri Sep 30 11:24: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 447E821F8BE4 for ; Fri, 30 Sep 2011 11:24:58 -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, TVD_PH_SUBJ_META=0] 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 lZFq5G4Q1ypX for ; Fri, 30 Sep 2011 11:24:57 -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 B42E421F8B29 for ; Fri, 30 Sep 2011 11:24:57 -0700 (PDT) Received: by ywa6 with SMTP id 6so2160125ywa.31 for ; Fri, 30 Sep 2011 11:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=7OILZFDUbyICWaV4vYcIymwZ5W5pOaClqqA6nSjAsb4=; b=nWFQyO8/SSPN7n1fHCYOYHpvfKnaZ5hVkeSjwhnyoviA5BM97wEHDENy73oNKmPv+e elEJHvTzlUibzcVxlHDKvU2fI9P83vyxq5LUbzHad3J8W1O/9CKdfHd8+JJiHWsQPab2 XrexZbax3IdiJnIc6/LvVdTOfHAa78rXkU/Jk= Received: by 10.101.8.22 with SMTP id l22mr10742557ani.90.1317407272057; Fri, 30 Sep 2011 11:27:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.254.6 with HTTP; Fri, 30 Sep 2011 11:27:32 -0700 (PDT) From: Doug Tangren Date: Fri, 30 Sep 2011 14:27:32 -0400 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001636b2b03979b9fe04ae2cc855 Subject: [OAUTH-WG] Secure storage of access for clients of the implicit flow 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, 30 Sep 2011 18:24:58 -0000 --001636b2b03979b9fe04ae2cc855 Content-Type: text/plain; charset=UTF-8 What is the recommended practice for storing access tokens for clients of the implicit flow. You don't really want to store it in a cookie because it will be send with every request to the server. There is html local storage but I don't know how sandboxed that is from other scripts on a given page. -Doug Tangren http://lessis.me --001636b2b03979b9fe04ae2cc855 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What is the recommended practice for storing access tokens for clients of t= he implicit flow. You don't really want to store it in a cookie because= it will be send with every request to the server. There is html local stor= age but I don't know how sandboxed that is from other scripts on a give= n page.

-Doug Tangren
http://lessis.me
--001636b2b03979b9fe04ae2cc855--