From zeltsan@alcatel-lucent.com Fri Sep 4 13:18:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFEF3A6A8B for ; Fri, 4 Sep 2009 13:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MANGLED_LIST=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiN0tW9ZMDhU for ; Fri, 4 Sep 2009 13:18:43 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 70F993A6765 for ; Fri, 4 Sep 2009 13:18:43 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n84KJ1x5024377 for ; Fri, 4 Sep 2009 15:19:01 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n84KIxm8015291; Fri, 4 Sep 2009 15:18:59 -0500 (CDT) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 4 Sep 2009 15:18:59 -0500 From: "Zeltsan, Zachary (Zachary)" To: "oauth@ietf.org" Date: Fri, 4 Sep 2009 15:18:58 -0500 Thread-Topic: Draft Using OAuth for Recursive Delegation Thread-Index: AcotnB5FBELrD/UWRvKoZxVZyx/k1w== Message-ID: <5710F82C0E73B04FA559560098BF95B124EDC376C6@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_5710F82C0E73B04FA559560098BF95B124EDC376C6USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "Vrancken, Bart Bv \(Bart\)" Subject: [OAUTH-WG] Draft Using OAuth for Recursive Delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 20:18:45 -0000 --_004_5710F82C0E73B04FA559560098BF95B124EDC376C6USNAVSXCHMBSA_ Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B124EDC376C6USNAVSXCHMBSA_" --_000_5710F82C0E73B04FA559560098BF95B124EDC376C6USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following up on the discussion on the subject known as "four-legged" author= ization, we have prepared a draft describing a use case for re-delegation o= f authorization. I have just submitted the draft to the IETF (it is also attached). Your com= ments are welcome. Zachary Zeltsan --_000_5710F82C0E73B04FA559560098BF95B124EDC376C6USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Following up on the discussion on the subject known as "four-legg= ed" authorization, we have prepared a draft describing a use case for = re-delegation of authorization.
 
I have just submitted the draft to the IETF (it is also attached). You= r comments are welcome.
 
Zachary Zeltsan
 
 
 --_000_5710F82C0E73B04FA559560098BF95B124EDC376C6USNAVSXCHMBSA_-- --_004_5710F82C0E73B04FA559560098BF95B124EDC376C6USNAVSXCHMBSA_ Content-Type: text/plain; name="draft-vrancken-oauth-redelegation-00.txt" Content-Description: draft-vrancken-oauth-redelegation-00.txt Content-Disposition: attachment; filename="draft-vrancken-oauth-redelegation-00.txt"; size=24114; creation-date="Sat, 29 Aug 2009 04:35:09 GMT"; modification-date="Fri, 04 Sep 2009 14:52:23 GMT" Content-Transfer-Encoding: base64 DQoNCk9BVVRIIFdHICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBCLiBWcmFuY2tlbg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBaLiBaZWx0c2FuDQpJbnRlbmRlZCBzdGF0dXM6IElu Zm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgQWxjYXRlbC1MdWNlbnQNCkV4 cGlyZXM6IE1hcmNoIDUsIDIwMTAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT ZXB0ZW1iZXIgMjAwOQ0KDQoNCiAgICAgICAgICAgICAgICAgIFVzaW5nIE9BdXRoIGZvciBSZWN1 cnNpdmUgRGVsZWdhdGlvbg0KICAgICAgICAgICAgICAgICAgZHJhZnQtdnJhbmNrZW4tb2F1dGgt cmVkZWxlZ2F0aW9uLTAwDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5l dC1EcmFmdCBpcyBzdWJtaXR0ZWQgdG8gSUVURiBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhl DQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFm dHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAg VGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5v dGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUg ZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5k IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50 cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E cmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhh biBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRm LzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFk b3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3Jn L3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE1h cmNoIDUsIDIwMTAuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChjKSAyMDA5 IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQogICBkb2N1bWVu dCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBz dWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KICAgUHJvdmlzaW9u cyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cyBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNCiAg IHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xp Y2Vuc2UtaW5mbykuDQogICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyBjYXJlZnVsbHks IGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMNCiAgIGFuZCByZXN0cmljdGlvbnMgd2l0aCBy ZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGEgdXNlIGNhc2UgZm9yIGRlbGVnYXRpbmcgYXV0aG9yaXphdGlvbiBieSBhDQog ICBSZXNvdXJjZSBPd25lciB0byBhbm90aGVyIHVzZXIgdmlhIGEgQ2xpZW50IHVzaW5nIHRoZSBP QXV0aCBwcm90b2NvbC4NCiAgIE9BdXRoIGFsbG93cyBDbGllbnRzIHRvIGFjY2VzcyBzZXJ2ZXIg cmVzb3VyY2VzIG9uIGJlaGFsZiBvZiBhbm90aGVyDQoNCg0KDQpWcmFuY2tlbiAmIFplbHRzYW4g ICAgICAgIEV4cGlyZXMgTWFyY2ggNSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwN CkludGVybmV0LURyYWZ0ICAgIFVzaW5nIE9BdXRoIGZvciBSZWN1cnNpdmUgRGVsZWdhdGlvbiAg ICBTZXB0ZW1iZXIgMjAwOQ0KDQoNCiAgIHBhcnR5IChzdWNoIGFzIGEgZGlmZmVyZW50IENsaWVu dCBvciBhbiBlbmQtdXNlcikuICBUaGlzIGRvY3VtZW50DQogICBkZXNjcmliZXMgdGhlIHVzZSBv ZiBPQXV0aCBmb3IgZGVsZWdhdGluZyBvbmUgQ2xpZW50J3MgYXV0aG9yaXphdGlvbg0KICAgdG8g YW5vdGhlciBDbGllbnQgLSBhIHNjZW5hcmlvLCB3aGljaCBpcyBhbHNvIGtub3duIGFzIGZvdXIt bGVnZ2VkDQogICBhdXRob3JpemF0aW9uLg0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEu ICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMw0KICAgMi4gIE5vdGF0aW9uYWwgQ29udmVudGlvbnMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAzLiAgVXNlIG9mIHRoZSBPQXV0aCBwcm90 b2NvbCBmb3IgcmUtZGVsZWdhdGlvbiBvZiB0aGUgYWNjZXNzDQogICAgICAgcmlnaHRzIGZvciBh IHByb3RlY3RlZCByZXNvdXJjZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAg ICAgMy4xLiAgUmVkaXJlY3Rpb24tQmFzZWQgQXV0aG9yaXphdGlvbiAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgNA0KICAgICAzLjIuICBUaGUgUmVzb3VyY2UgT3duZXIgYXV0aG9yaXplcyBh IGZpcnN0IENsaWVudCB0byBzaGFyZQ0KICAgICAgICAgICBhIHJlc291cmNlIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgIDMuMy4gIFRoZSBm aXJzdCBDbGllbnQgYXV0aG9yaXplcyBhY2Nlc3MgdG8gdGhlIHJlc291cmNlIGJ5DQogICAgICAg ICAgIHRoZSBzZWNvbmQgQ2xpZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDUNCiAgIDQuICBNdWx0aS1sYXllcmVkIGRlbGVnYXRpb24gb2YgYXV0aG9yaXphdGlv biAgLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgIDUuMS4gIFVu bGltaXRlZCByZWN1cnNpdmUgZGVsZWdhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDgNCiAgICAgNS4yLiAgUGhpc2hpbmcgQXR0YWNrICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgNi4gIElBTkEgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICA3LiAgQWNrbm93bGVkZ2Vt ZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAg IDguICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgOQ0KICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAgIDguMi4gIEluZm9ybWF0aXZlIFJl ZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgIEFwcGVu ZGl4IEEuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAxMA0KICAgQXBwZW5kaXggQi4gIE90aGVyIGV4YW1wbGVzICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KVnJhbmNrZW4gJiBaZWx0c2FuICAgICAgICBF eHBpcmVzIE1hcmNoIDUsIDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICBVc2luZyBPQXV0aCBmb3IgUmVjdXJzaXZlIERlbGVnYXRpb24gICAgU2VwdGVt YmVyIDIwMDkNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBuZWVkIGZvciBkb2N1bWVu dGluZyBhIHVzZSBjYXNlIGZvciB0aGUgT0F1dGggbXVsdGktbGF5ZXJlZA0KICAgYXV0aG9yaXph dGlvbiB3YXMgZGlzY3Vzc2VkIG9uIHRoZSBPQXV0aCBtYWlsaW5nIGxpc3QgYW5kIGF0IHRoZSBi YXINCiAgIEJvRiBtZWV0aW5nIGF0IHRoZSBJRVRGIDc1LiAgVGhpcyBJbnRlcm5ldCBEcmFmdCBk ZXNjcmliZXMgc3VjaCBhIHVzZQ0KICAgY2FzZS4gIFdlIHByb3Bvc2UgdGhpcyBkb2N1bWVudCBh cyBhIHdvcmsgaXRlbSBvZiB0aGUgT0F1dGggd29ya2luZw0KICAgZ3JvdXAuICBEZXBlbmRpbmcg b24gdGhlIGdyb3VwJ3MgZGVjaXNpb24gaXQgY2FuIGJlY29tZSBhIHBhcnQgb2YNCiAgIGFub3Ro ZXIgSW50ZXJuZXQgRHJhZnQgb3IgYSBzZXBhcmF0ZSBkb2N1bWVudC4NCg0KDQoyLiAgTm90YXRp b25hbCBDb252ZW50aW9ucw0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwg IlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBO T1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9j dW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQoN Cg0KMy4gIFVzZSBvZiB0aGUgT0F1dGggcHJvdG9jb2wgZm9yIHJlLWRlbGVnYXRpb24gb2YgdGhl IGFjY2VzcyByaWdodHMgZm9yDQogICAgYSBwcm90ZWN0ZWQgcmVzb3VyY2UNCg0KICAgVGhlIE9B dXRoIHByb3RvY29sIHByb3ZpZGVzIGEgbWV0aG9kIGZvciBzZXJ2ZXJzIHRvIGFsbG93IHRoaXJk LXBhcnR5DQogICBhY2Nlc3MgdG8gcHJvdGVjdGVkIHJlc291cmNlcyB3aXRob3V0IGZvcmNpbmcg dGhlaXIgZW5kLXVzZXJzIHRvDQogICByZXZlYWwgdGhlaXIgYXV0aGVudGljYXRpb24gY3JlZGVu dGlhbHMuICBUaGlzIG1ldGhvZCBjYW4gYmUgZW1wbG95ZWQNCiAgIHRvIHN1cHBvcnQgb3JnYW5p emluZyBhbmQgc2hhcmluZyBpbmZvcm1hdGlvbiBhbW9uZyB0aGUgZW5kLXVzZXJzLg0KDQogICBG b3IgZXhhbXBsZSwgYSBXZWIgdXNlciAoUmVzb3VyY2UgT3duZXIpIGNhbiBncmFudCBkYXRhIGFj Y2VzcyB0byBhDQogICBwcmUtZGVmaW5lZCBzZXQgb2YgdXNlcnMuICBUaGlzIGNhbiBiZSBkb25l IHdpdGggdGhlIHVzZSBvZiBhIHNwZWNpYWwNCiAgIE9BdXRoIENsaWVudCAtIGNvbnRlbnQgbWFu YWdlciAtIHdoaWNoIHNlcnZlcyBhcyBhIHByb3h5IGJldHdlZW4gdGhlDQogICBlbmQtdXNlcnMg YW5kIHRoZSBXZWIgc2VydmVycyB0aGF0IGhvc3QgdGhlIHJlc291cmNlcyByZWxhdGVkIHRvIHRo ZQ0KICAgcHJvamVjdC4gIFRoZSBjb250ZW50IG1hbmFnZXIgYWxsb3dzIGEgdXNlciAodGhlIG93 bmVyIG9mIHRoZQ0KICAgcmVzb3VyY2VzKSB0byBzcGVjaWZ5IGEgc2V0IG9mIHRoZSByZXNvdXJj ZXMgcmVsYXRlZCB0byBhIHByb2plY3QNCiAgIChlLmcuLCBieSB0YWdnaW5nKSBhbmQgYSBzZXQg b2YgdGhlIHVzZXJzIGFuZCB0aGVpciBhY2Nlc3MgcmlnaHRzIGluDQogICByZXNwZWN0IHRvIHRo ZSByZXNvdXJjZXMuICBUaGUgY29udGVudCBtYW5hZ2VyIG1heSBhbHNvIGVuYWJsZQ0KICAgc2Vh cmNoaW5nIG9mIHRoZSByZWxhdGVkIG1hdGVyaWFscy4NCg0KICAgVGhlIG1ldGhvZHMgZm9yIG1h bmFnaW5nIHVzZXIgaW5mb3JtYXRpb24gYXJlIG91dCBvZiB0aGUgc2NvcGUgb2YNCiAgIHRoaXMg ZG9jdW1lbnQuICBUaGUgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBzdWNoIGNvbnRlbnQgbWFuYWdl cg0KICAgYXV0aG9yaXplcyB1c2VyIGFjY2VzcyB0byB0aGUgcmVzb3VyY2VzIHVzaW5nIHRoZSBP QXV0aCBwcm90b2NvbC4NCg0KICAgQXMgZmFyIGFzIGF1dGhvcml6YXRpb24gaXMgY29uY2VybmVk LCB0aGUgY29udGVudCBtYW5hZ2VyIGFuZCB0aGUNCiAgIHVzZXIgd2l0aCB3aG9tIHRoZSBSZXNv dXJjZSBPd25lciBzaGFyZXMgYSByZXNvdXJjZSBhcmUgdGhlIE9BdXRoDQogICBDbGllbnRzIGFz IGRlZmluZWQgaW4gW2RyYWZ0LWlldGYtb2F1dGgtYXV0aGVudGljYXRpb25dLiAgSW4gdGhpcw0K ICAgZG9jdW1lbnQgdGhlIGNvbnRlbnQgbWFuYWdlciwgd2hpY2ggaGFzIGJlZW4gYXV0aG9yaXpl ZCBieSBhIFJlc291cmNlDQogICBPd25lciB0byBzaGFyZSBhIHJlc291cmNlIHdpdGggYSB1c2Vy IGlzIGNhbGxlZCBmaXJzdCBDbGllbnQuICBUaGUNCiAgIHVzZXIgd2l0aCB3aG9tIHRoZSByZXNv dXJjZSBpcyB0byBiZSBzaGFyZWQgaXMgcmVmZXJyZWQgdG8gYXMgYQ0KICAgc2Vjb25kIENsaWVu dC4NCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHVzZSBvZiBPQXV0aCBmb3IgZW5h Ymxpbmcgc2hhcmluZyBhDQoNCg0KDQpWcmFuY2tlbiAmIFplbHRzYW4gICAgICAgIEV4cGlyZXMg TWFyY2ggNSwgMjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0 ICAgIFVzaW5nIE9BdXRoIGZvciBSZWN1cnNpdmUgRGVsZWdhdGlvbiAgICBTZXB0ZW1iZXIgMjAw OQ0KDQoNCiAgIHJlc291cmNlIHVuZGVyIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86DQoNCiAgIG8g IEZpcnN0IENsaWVudCBoYXMgYmVlbiBhdXRob3JpemVkIGJ5IHRoZSBSZXNvdXJjZSBPd25lciwg dG8gc2hhcmUgYQ0KICAgICAgcmVzb3VyY2UgKGUuZy4sIGZpbGUpIHdpdGggYSBzZWNvbmQgQ2xp ZW50Lg0KDQogICBvICBUaGUgZmlyc3QgQ2xpZW50IGhhcyBvYnRhaW5lZCBhY2Nlc3MgdG9rZW4g Y3JlZGVudGlhbHMgZm9yIHRoZQ0KICAgICAgcmVzb3VyY2UuDQoNCiAgIG8gIFRoZSBmaXJzdCBD bGllbnQgZW5hYmxlcyB0aGUgc2Vjb25kIENsaWVudCB0byBhY2Nlc3MgdGhlIHJlc291cmNlDQog ICAgICB3aXRob3V0IGdldHRpbmcgdGhlIFJlc291cmNlIE93bmVyIGludm9sdmVkIGluIGF1dGhv cml6YXRpb24NCiAgICAgIHByb2Nlc3MuDQoNCjMuMS4gIFJlZGlyZWN0aW9uLUJhc2VkIEF1dGhv cml6YXRpb24NCg0KICAgT0F1dGggdXNlcyBhIHNldCBvZiB0b2tlbiBjcmVkZW50aWFscyB0byBy ZXByZXNlbnQgdGhlIGF1dGhvcml6YXRpb24NCiAgIGdyYW50ZWQgdG8gdGhlIENsaWVudCBieSB0 aGUgUmVzb3VyY2UgT3duZXIuICBUeXBpY2FsbHksIHRva2VuDQogICBjcmVkZW50aWFscyBhcmUg aXNzdWVkIGJ5IHRoZSBTZXJ2ZXIgYXQgdGhlIFJlc291cmNlIE93bmVyJ3MgcmVxdWVzdCwNCiAg IGFmdGVyIGF1dGhlbnRpY2F0aW5nIHRoZSBSZXNvdXJjZSBPd25lcidzIGlkZW50aXR5IHVzaW5n IGl0cyBTZXJ2ZXINCiAgIGNyZWRlbnRpYWxzICh1c3VhbGx5IGEgdXNlcm5hbWUgYW5kIHBhc3N3 b3JkIHBhaXIpLg0KDQogICBUaGUgc3BlY2lmaWNhdGlvbiBbZHJhZnQtaWV0Zi1vYXV0aC13ZWIt ZGVsZWdhdGlvbl0gZGVmaW5lcyBhIG1ldGhvZA0KICAgZm9yIHByb3Zpc2lvbmluZyB0aGUgdG9r ZW4gY3JlZGVudGlhbHMgd2l0aCB0aGUgdXNlIG9mIHRoZSBIVFRQDQogICByZWRpcmVjdGlvbiBh bmQgdGhlIFJlc291cmNlIE93bmVyJ3MgdXNlciBhZ2VudC4gIFRoaXMgZG9jdW1lbnQNCiAgIGRl c2NyaWJlcyBob3cgdGhlIG1ldGhvZCBjYW4gYmUgZXhwYW5kZWQgdG8gYWxsb3cgYSBDbGllbnQg dG8gc2hhcmUgYQ0KICAgcmVzb3VyY2Ugd2l0aCBhbm90aGVyIENsaWVudCBhZnRlciBvYnRhaW5p bmcgdGhlIFJlc291cmNlIE93bmVyJ3MNCiAgIGF1dGhvcml6YXRpb24gdG8gZG8gc28uDQoNCiAg IFRoZSBzcGVjaWZpY2F0aW9uIFtkcmFmdC1pZXRmLW9hdXRoLXdlYi1kZWxlZ2F0aW9uXSBkZWZp bmVzIHRoZQ0KICAgZm9sbG93aW5nIFVSSXMgb2YgYSBXZWIgU2VydmVyOg0KDQogICBvICBUZW1w b3JhcnkgQ3JlZGVudGlhbCBSZXF1ZXN0DQoNCiAgIG8gIFJlc291cmNlIE93bmVyIEF1dGhvcml6 YXRpb24NCg0KICAgbyAgVG9rZW4gUmVxdWVzdA0KDQogICBJdCBhbHNvIGRlZmluZXMgdGhlIEhU VFAgbWV0aG9kcyAoR0VULCBQT1NULCBldGMuKSB1c2VkIHRvIG1ha2UgdGhlDQogICByZXF1ZXN0 cy4gIFRoaXMgc3BlY2lmaWNhdGlvbiByZWxpZXMgb24gdGhlc2UgZGVmaW5pdGlvbnMuDQoNCiAg IFRoZSBtZXRob2QgaW4gd2hpY2ggdGhlIHNlcnZlciBhZHZlcnRpc2VzIGl0cyB0aHJlZSBlbmRw b2ludHMgaXMNCiAgIGJleW9uZCB0aGUgc2NvcGUgb2YgW2RyYWZ0LWlldGYtb2F1dGgtd2ViLWRl bGVnYXRpb25dIGFuZCB0aGlzDQogICBkb2N1bWVudC4NCg0KMy4yLiAgVGhlIFJlc291cmNlIE93 bmVyIGF1dGhvcml6ZXMgYSBmaXJzdCBDbGllbnQgdG8gc2hhcmUgYSByZXNvdXJjZQ0KDQogICBJ biB0aGUgaW5pdGlhbCBzdGFnZSBvZiB0aGUgYXV0aG9yaXphdGlvbiBwcm9jZWR1cmUsIHRoZSBS ZXNvdXJjZQ0KICAgT3duZXIgYXV0aG9yaXplcyBhIENsaWVudCB0byBzaGFyZSB0aGUgcmVzb3Vy Y2Ugd2l0aCBhbm90aGVyIHVzZXIod2hvDQogICBpcyBqdXN0IGFub3RoZXIgQ2xpZW50IGluIHRl cm1zIG9mDQoNCg0KDQpWcmFuY2tlbiAmIFplbHRzYW4gICAgICAgIEV4cGlyZXMgTWFyY2ggNSwg MjAxMCAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgIFVzaW5n IE9BdXRoIGZvciBSZWN1cnNpdmUgRGVsZWdhdGlvbiAgICBTZXB0ZW1iZXIgMjAwOQ0KDQoNCiAg IFtkcmFmdC1pZXRmLW9hdXRoLXdlYi1kZWxlZ2F0aW9uXSkuDQoNCiAgIFRoZSBmaXJzdCBDbGll bnQgb2J0YWlucyAoYWZ0ZXIgdGhlIFJlc291cmNlIE93bmVyJ3MgYXV0aG9yaXphdGlvbikNCiAg IHRva2VuIGNyZWRlbnRpYWxzIHRoYXQgYWxsb3cgaXQgdG8gYWNjZXNzIChlLmcuLCByZWFkLCB1 cGRhdGUpIHRoZQ0KICAgcmVzb3VyY2UuICBJbiB0aGUgZGVzY3JpYmVkIHVzZSBjYXNlIHRoZSBh Y2Nlc3MgcmlnaHRzIGluY2x1ZGUgYQ0KICAgcmlnaHQgdG8gcmUtZGVsZWdhdGUgKGkuZS4sIHRv IHByb3h5KSB0aGUgb2J0YWluZWQgYXV0aG9yaXphdGlvbi4NCiAgIFRoZSBmaXJzdCBDbGllbnQs IHdoaWNoIGRvZXMgbm90IG5lZWQgdG8gYWNjZXNzIHRoZSByZXNvdXJjZSwgd2lsbA0KICAgdXNl IHRoZSBjcmVkZW50aWFscyBmb3IgYXV0aGVudGljYXRpbmcgdG8gdGhlIFNlcnZlciBhbmQgYXV0 aG9yaXppbmcNCiAgIGFjY2VzcyBieSB0aGUgc2Vjb25kIENsaWVudC4NCg0KICAgVGhlIGZpcnN0 IENsaWVudCBvYnRhaW5zIHRva2VuIGNyZWRlbnRpYWxzIHVzaW5nIGEgbWVjaGFuaXNtDQogICBz cGVjaWZpZWQgaW4gW2RyYWZ0LWlldGYtb2F1dGgtd2ViLWRlbGVnYXRpb25dLiAgVGhlIHN0ZXBz IHRoYXQNCiAgIGZvbGxvdyBhcmUgaWxsdXN0cmF0ZWQgYnkgRmlndXJlIDEgYmVsb3cgYW5kIGRl c2NyaWJlZCBpbiB0aGUgbmV4dA0KICAgc2VjdGlvbi4NCg0KMy4zLiAgVGhlIGZpcnN0IENsaWVu dCBhdXRob3JpemVzIGFjY2VzcyB0byB0aGUgcmVzb3VyY2UgYnkgdGhlIHNlY29uZA0KICAgICAg Q2xpZW50DQoNCiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIHN0ZXBzIG9mIHRoZSBwcm9j ZWR1cmUgdGhhdCBmb2xsb3cgdGhlDQogICBpbml0aWFsIHN0ZXBzOg0KDQogICBvICBSZXNvdXJj ZSBPd25lciBoYXMgcmVxdWVzdGVkIHRoZSBmaXJzdCBDbGllbnQgdG8gc2hhcmUgYSByZXNvdXJj ZQ0KICAgICAgd2l0aCBhbm90aGVyIHVzZXIgLSBhIHNlY29uZCBDbGllbnQNCg0KICAgbyAgVGhl IGZpcnN0IENsaWVudCBoYXMgb2J0YWluZWQgdGhlIHRva2VuIGNyZWRlbnRpYWxzIGZyb20gdGhl DQogICAgICBTZXJ2ZXIgZm9yIHRoZSByZXNvdXJjZS4NCg0KDQogICAgKy0tLS0tLS0tLS0tLS0r ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tKw0KICAgIHwg IDFzdCBDbGllbnQgfCAgICAgICAgICAgICAgICB8V2ViIHNlcnZlcnwgICAgICAgfDJuZCBDbGll bnR0IHwNCiAgICArLS0tLS0tKy0tLS0tLSsgICAgICAgICAgICAgICAgKy0tLS0tKy0tLS0rICAg ICAgICstLS0tLS0rLS0tLS0rDQogICAgICAgICAgIHwgMS4gMXN0IENsaWVudCBub3RpZmllcyB0 aGUgIHwgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICB8IDJuZCBDbGllbnQgb2YgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgfCB0aGUgcmVzb3Vy Y2Ugc2hhcmluZyAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgIHwtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwNCiAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg ICB8DQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwyLiBSZXF1ZXN0 IHJlc291cmNlfA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0t LS0tLS0tLS0tLS0tLS0tLXwNCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwzLiA0MDEsIGF1dGguIGZhaWwgfA0KICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfA0KICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IDQuIEVzdGFibGlzaCAgICAg IHwNCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBjb25zdW1lcl9r ZXkgYW5kICB8DQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgc2Vj cmV0ICAgICAgICAgICAgfA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8PC0tLS0tLS0tLS0tLS0tLS0tPnwNCg0KDQoNClZyYW5ja2VuICYgWmVsdHNhbiAgICAgICAg RXhwaXJlcyBNYXJjaCA1LCAyMDEwICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgVXNpbmcgT0F1dGggZm9yIFJlY3Vyc2l2ZSBEZWxlZ2F0aW9uICAgIFNlcHRl bWJlciAyMDA5DQoNCg0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfDUuIFJlcXVlc3QgICAgICAgICB8DQogICAgICAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHx0ZW1wb3JhcnkgICAgICAgICAgfA0KICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8Y3JlZGVudGlhbHMgICAgICAgIHwNCiAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw2 LiBUZW1wb3JhcnkgICAgICAgfA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8Y3JlZGVudGlhbHMgKHRva2VuIHwNCiAgICAgICAgICAgfDcuIDJuZCBDbGllbnQgYXNr cyB0aGUgMXN0ICAgfFQsIHNlY3JldCBUcykgICAgICB8DQogICAgICAgICAgIHxDbGllbnQgdG8g Z3JhbnQgYWNjZXNzIHRvIHRoZXwtLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgICAgICAgICB8cmVz b3VyY2Ugb24gdGhlIFdlYiBzZXJ2ZXIuICB8ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAg ICAgfFRoZSByZXF1ZXN0IGluY2x1ZGVzIFQgICAgICAgfCAgICAgICAgICAgICAgICAgICB8DQog ICAgICAgICAgfHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LS0tfA0KICAgICAgICAgIHx8IDcuICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgICB2fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAg ICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0rLS0tLS0tKyAgICAgICAgICAgIHwNCiAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICB8DQogICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgfEF1dGhlbnRpY2F0ZSB8ICAgICAgICAgICAgfA0KICAgICAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgIHxhbmQgZ2V0ICAgICAgfCAgICAgICAgICAgIHwNCiAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8YXV0aG9yaXphdGlvbnwgICAgICAgICAg ICB8DQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLSstLS0tLS0rICAg ICAgICAgICAgfA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgfDguIFJlZGlyZWN0IDFzdCBDbGllbnQgYmFj ayAgfCAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgIHx0byB0aGUgIDJuZCAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgIHx8PC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICB8fCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAg fHw4LiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfA0KICAg ICAgICAgIHYrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t PnwNCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8OS4gUmVxdWVzdCB0b2tlbiAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfGNyZWRlbnRpYWxzICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tfA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8MTAuIEdldCB0b2tlbiAgICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfGNyZWRlbnRpYWxzICAgICAgICB8DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0+ fA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8MTEuIFJlcXVlc3Qg ICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHJlc291 cmNlICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHw8LS0tLS0tLS0tLS0tLS0tLS0tfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAxMi4gUHJvdmlkZSB0aGUgICB8DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgcmVzb3VyY2UgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tPnwNCg0KDQoN Cg0KDQpWcmFuY2tlbiAmIFplbHRzYW4gICAgICAgIEV4cGlyZXMgTWFyY2ggNSwgMjAxMCAgICAg ICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgIFVzaW5nIE9BdXRoIGZv ciBSZWN1cnNpdmUgRGVsZWdhdGlvbiAgICBTZXB0ZW1iZXIgMjAwOQ0KDQoNCiAgIEZpZ3VyZSAx IC0gQXV0aG9yaXphdGlvbiBieSB0aGUgZmlyc3QgQ2xpZW50IG9mIHRoZSBzZWNvbmQgQ2xpZW50 IHRvDQogICAgICAgICAgICAgICAgICAgICAgICBvYnRhaW4gYWNjZXNzIHRvIGEgcmVzb3VyY2UN Cg0KICAgMS4gICBUaGUgZmlyc3QgQ2xpZW50IG5vdGlmaWVzIHRoZSBzZWNvbmQgQ2xpZW50IHRo YXQgYSByZXNvdXJjZQ0KICAgICAgICBhdmFpbGFibGUgZm9yIHNoYXJpbmcgb24gdGhlIHNlcnZl ci4gIFRoZSBmaXJzdCBjbGllbnQgTVVTVA0KICAgICAgICBwcm92aWRlIGZ1bGwgcGF0aCBVUkwg dG8gdGhlIHJlc291cmNlIG9uIHRoZSBXZWIgc2VydmVyLg0KDQogICAyLiAgIFRoZSBzZWNvbmQg Y2xpZW50IHJlcXVlc3RzIGFjY2VzcyB0byB0aGUgcmVzb3VyY2UuDQoNCiAgIDMuICAgVGhlIFdl YiBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCA0MDEgSFRUUCBlcnJvciBjb2RlIGRlbnlpbmcgYWNjZXNz DQogICAgICAgIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UuDQoNCiAgIDQuICAgVGhlIHNlY29u ZCBjbGllbnQgZXN0YWJsaXNoZXMgb2F1dGhfY29uc3VtZXJfa2V5IGFuZCBhIHNoYXJlZA0KICAg ICAgICBzZWNyZXQgLSB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIC0gYXMgc3BlY2lmaWVkIGluDQog ICAgICAgIFtkcmFmdC1pZXRmLW9hdXRoLWF1dGhlbnRpY2F0aW9uXS4NCg0KICAgNS4gICBUaGUg c2Vjb25kIENsaWVudCByZXF1ZXN0cyB0ZW1wb3JhcnkgY3JlZGVudGlhbHMgYXMgc3BlY2lmaWVk IGluDQogICAgICAgIFtkcmFmdC1pZXRmLW9hdXRoLXdlYi1kZWxlZ2F0aW9uXS4NCg0KICAgNi4g ICBUaGUgc2Vjb25kIGNsaWVudCByZWNlaXZlcyBmcm9tIHRoZSBXZWIgc2VydmVyIHRoZSB0ZW1w b3JhcnkNCiAgICAgICAgY3JlZGVudGlhbHMuDQoNCiAgIDcuICAgVGhlIHNlY29uZCBDbGllbnQg YXNrcyB0aGUgZmlyc3QgQ2xpZW50IHRvIGdyYW50IGFjY2VzcyB0byB0aGUNCiAgICAgICAgcmVx dWVzdGVkIHJlc291cmNlIG9uIHRoZSBXZWIgc2VydmVyLg0KDQogICAgICAgICAgIEFmdGVyIHRo aXMgc3RlcCB0aGUgZmlyc3QgQ2xpZW50IGF1dGhlbnRpY2F0ZXMgaXRzZWxmIHRvIHRoZQ0KICAg ICAgICAgICBXZWIgc2VydmVyIGFuZCBhdXRob3JpemVzIChvciBkZW5pZXMpIGFjY2VzcyB0byB0 aGUgcmVzb3VyY2UNCiAgICAgICAgICAgYnkgdGhlIHNlY29uZCBDbGllbnQuICBUbyBkZW1vbnN0 cmF0ZSB0aGF0IGl0IGhhcyBiZWVuDQogICAgICAgICAgIGF1dGhvcml6ZWQgYnkgdGhlIFJlc291 cmNlIE93bmVyIHRvIGFjY2VzcyB0aGUgcmVzb3VyY2UsIHRoZQ0KICAgICAgICAgICBmaXJzdCBD bGllbnQgdXNlcyBpdHMgdG9rZW4gY3JlZGVudGlhbHMgb2J0YWluZWQgYXMgYSByZXN1bHQNCiAg ICAgICAgICAgb2YgdGhlIHVzdWFsIE9BdXRoIHByb2NlZHVyZS4gIFRvIGRvIHRoYXQsIHRoZSBm aXJzdCBDbGllbnQNCiAgICAgICAgICAgZm9ybXMgYSByZXF1ZXN0IHRvIHRoZSBXZWIgU2VydmVy IGZvciB0aGUgcHJvdGVjdGVkIHJlc291cmNlDQogICAgICAgICAgIGFzIHNwZWNpZmllZCBpbiBb ZHJhZnQtaWV0Zi0gb2F1dGgtYXV0aGVudGljYXRpb25dIGFuZA0KICAgICAgICAgICBbZHJhZnQt aWV0Zi1vYXV0aC1kZWxlZ2F0aW9uXSB3aXRoIGEgbW9kaWZpY2F0aW9uLiAgVGhlDQogICAgICAg ICAgIHB1cnBvc2Ugb2YgdGhlIHJlcXVpcmVkIG1vZGlmaWNhdGlvbiBpcyB0byBpbmZvcm0gdGhl IFdlYg0KICAgICAgICAgICBTZXJ2ZXIgdGhhdCB0aGUgZmlyc3QgQ2xpZW50IGludGVuZHMgdG8g dXNlIGl0cyB0b2tlbg0KICAgICAgICAgICBjcmVkZW50aWFscyBmb3IgcHJvdmluZyB0aGF0IGl0 IGlzIGF1dGhvcml6ZWQgYnkgdGhlIFJlc291cmNlDQogICAgICAgICAgIE93bmVyIHRvIGFjY2Vz cyB0aGUgcmVzb3VyY2UgYW5kIGZvciBhdXRob3JpemluZyBhY2Nlc3MgYnkNCiAgICAgICAgICAg YW5vdGhlciBwYXJ0eSwgYnV0IG5vdCBmb3IgZ2V0dGluZyB0aGUgcmVzb3VyY2UgaXRzZWxmLg0K DQogICA4LiAgIEFmdGVyIHRoZSBmaXJzdCBDbGllbnQgaGFzIGF1dGhvcml6ZWQgYWNjZXNzIHRv IHRoZSByZXNvdXJjZSBmb3INCiAgICAgICAgdGhlIHNlY29uZCBDbGllbnQsIHRoZSBXZWIgc2Vy dmVyIHNlbmRzIGEgVVJMIGNvbnRhaW5pbmcgdGhlDQogICAgICAgIG9hdXRoX3Rva2VuIGFuZCBv YXV0aF92ZXJpZmllciBwYXJhbWV0ZXJzIGFzIHNwZWNpZmllZCBpbg0KICAgICAgICBbZHJhZnQt aWV0Zi1vYXV0aC13ZWItZGVsZWdhdGlvbl0uDQoNCiAgICAgICAgICAgQWZ0ZXIgdGhpcyBzdGVw IHRoZSBmaXJzdCBjbGllbnQgcmVzcG9uZHMgYmFjayB0byB0aGUgc2Vjb25kDQogICAgICAgICAg IGNsaWVudCwgY29uZmlybWluZyB0aGF0IHRoZSBhdXRob3JpemF0aW9uIGhhcyBiZWVuIGRvbmUu DQoNCg0KDQoNClZyYW5ja2VuICYgWmVsdHNhbiAgICAgICAgRXhwaXJlcyBNYXJjaCA1LCAyMDEw ICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgVXNpbmcgT0F1 dGggZm9yIFJlY3Vyc2l2ZSBEZWxlZ2F0aW9uICAgIFNlcHRlbWJlciAyMDA5DQoNCg0KICAgOS4g ICBUaGUgc2Vjb25kIENsaWVudCByZXF1ZXN0cyB0aGUgdG9rZW4gY3JlZGVudGlhbHMgKHNwZWNp ZmllZCBpbg0KICAgICAgICBbZHJhZnQtaWV0Zi1vYXV0aC13ZWItZGVsZWdhdGlvbl0pLg0KDQog ICAxMC4gIFRoZSBXZWIgc2VydmVyIHJlc3BvbmRzIHdpdGggdGhlIHRva2VuIGNyZWRlbnRpYWxz Lg0KDQogICAxMS4gIFRoZSBzZWNvbmQgQ2xpZW50IHJlcXVlc3RzIGFjY2VzcyB0byB0aGUgcHJv dGVjdGVkIHJlc291cmNlIGFzDQogICAgICAgIHNwZWNpZmllZCBpbiBbZHJhZnQtaWV0Zi1vYXV0 aC13ZWItZGVsZWdhdGlvbl0uDQoNCiAgIDEyLiAgQWZ0ZXIgdmVyaWZpY2F0aW9uIHRoZSBXZWIg U2VydmVyIHNhdGlzZmllcyB0aGUgcmVxdWVzdC4NCg0KDQo0LiAgTXVsdGktbGF5ZXJlZCBkZWxl Z2F0aW9uIG9mIGF1dGhvcml6YXRpb24NCg0KICAgU2VjdGlvbiAzIGRlc2NyaWJlcyBob3cgb25l IENsaWVudCAoaS5lLiwgZmlyc3QgQ2xpZW50KSBjYW4gZ3JhbnQNCiAgIGFjY2VzcyB0byBhIHJl c291cmNlIHRvIGFub3RoZXIgQ2xpZW50IChpLmUuLCBzZWNvbmQgQ2xpZW50KS4gIFRoZQ0KICAg ZGVzY3JpYmVkIG1ldGhvZCBjYW4gYmUgZXh0ZW5kZWQgZm9yIGdyYW50aW5nIGFjY2VzcyBieSB0 aGUgTnRoDQogICBDbGllbnQgdG8gYSBjbGllbnQgTisxLiAgSW4gc3VjaCBhIHNjZW5hcmlvIGVh Y2ggQ2xpZW50IGhhcyB0byBoYXZlIGENCiAgIGxpc3Qgb2YgYWxsIENsaWVudHMgdGhhdCBhcmUg cGVybWl0dGVkIHRvIGFjY2VzcyB0aGUgcmVzb3VyY2UuDQoNCiAgIEluZGVlZCwgdGhlIHNlY29u ZCBDbGllbnQsIGFmdGVyIG9idGFpbmluZyBhdXRob3JpemF0aW9uIGZyb20gdGhlDQogICBmaXJz dCBDbGllbnQsIGNhbiBub3RpZnkgYSB0aGlyZCBDbGllbnQgKGFzc3VtaW5nIHRoYXQgaXQgaXMg b24gdGhlDQogICBsaXN0KSBvZiB0aGUgaW50ZW50IHRvIHNoYXJlIHRoZSByZXNvdXJjZSAoYXMg ZGlkIHRoZSBmaXJzdCBDbGllbnQgaW4NCiAgIHN0ZXAgMSkuICBUaGVuIGJ5IHJlcGVhdGluZyB0 aGUgcmVzdCBvZiB0aGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbg0KICAgc2VjdGlvbiAzLCB0aGUg dGhpcmQgQ2xpZW50IGNhbiBvYnRhaW4gYXV0aG9yaXphdGlvbiB0byB0aGUgcmVzb3VyY2UuDQog ICBUaGUgcHJvY2VkdXJlIGNhbiBiZSByZXBlYXRlZCBOIHRpbWVzIHJlc3VsdGluZyBpbiB0aGUg cmVjdXJzaXZlDQogICBkZWxlZ2F0aW9uIG9mIGF1dGhvcml6YXRpb24uDQoNCiAgIEluIGdlbmVy YWwsIHRoZSBwcm9jZWR1cmUgYWxsb3dzIGEgQ2xpZW50IE4rMSB0byBkZW1vbnN0cmF0ZSB0byB0 aGUNCiAgIFdlYiBzZXJ2ZXIgdGhhdCBpdCBoYXMgYmVlbiBhdXRob3JpemVkIGJ5IGFuIE50aCBD bGllbnQgdG8gYWNjZXNzIHRoZQ0KICAgcmVzb3VyY2UuICBCZWZvcmUgbWFraW5nIGF1dGhvcml6 YXRpb24gdGhlIE50aCBDbGllbnQgTVVTVCB2ZXJpZnkNCiAgIHRoYXQgdGhlIENsaWVudCBOKzEg aXMgb24gdGhlIGxpc3Qgb2YgdGhlIENsaWVudHMgdGhhdCBhcmUgcGVybWl0dGVkDQogICB0byBh Y2Nlc3MgdGhlIHJlc291cmNlLg0KDQoNCjUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQog ICBBcyBzdGF0ZWQgaW4gW1JGQzI2MTddLCB0aGUgZ3JlYXRlc3Qgc291cmNlcyBvZiByaXNrcyBh cmUgdXN1YWxseQ0KICAgZm91bmQgbm90IGluIHRoZSBjb3JlIHByb3RvY29sIGl0c2VsZiBidXQg aW4gcG9saWNpZXMgYW5kIHByb2NlZHVyZXMNCiAgIHN1cnJvdW5kaW5nIGl0cyB1c2UuICBJbXBs ZW1lbnRlcnMgYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQgdG8gYXNzZXNzDQogICBob3cgdGhpcyBw cm90b2NvbCBhZGRyZXNzZXMgdGhlaXIgc2VjdXJpdHkgcmVxdWlyZW1lbnRzLiAgQmVjYXVzZSBv Zg0KICAgdGhlIG5hdHVyZSBvZiBtdWx0aS1sYXllciBkZWxlZ2F0aW9uLCB0aGUgc2FtZSBzZWN1 cml0eQ0KICAgY29uc2lkZXJhdGlvbnMgYXJlIGFwcGxpY2FibGUgYXMgaW4gdGhlIHNpbmdsZS1s YXllciBkZWxlZ2F0aW9uDQogICBbZHJhZnQtaWV0Zi1vYXV0aC13ZWItZGVsZWdhdGlvbl0uDQoN CjUuMS4gIFVubGltaXRlZCByZWN1cnNpdmUgZGVsZWdhdGlvbg0KDQogICBSZXNvdXJjZSBvd25l cnMgc2hvdWxkIGJlIGFibGUgdG8gZGVjaWRlIGlmIHRoZSBjbGllbnQgbWF5IHVzZQ0KICAgcmVj dXJzaXZlIGRlbGVnYXRpb24uICBDbGllbnRzIHNob3VsZCBpbmZvcm0gdGhlIHJlc291cmNlIG93 bmVyLCBhdA0KDQoNCg0KVnJhbmNrZW4gJiBaZWx0c2FuICAgICAgICBFeHBpcmVzIE1hcmNoIDUs IDIwMTAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBVc2lu ZyBPQXV0aCBmb3IgUmVjdXJzaXZlIERlbGVnYXRpb24gICAgU2VwdGVtYmVyIDIwMDkNCg0KDQog ICB3aG8gdGhleSB3b3VsZCBkZWxlZ2F0ZSBwZXJtaXNzaW9ucyB0by4gIEEgY2xpZW50IG1heSBu b3QgZGVsZWdhdGUNCiAgIHJlY3Vyc2l2ZWx5IHRvIGFueW9uZSBlbHNlIHRoYW4gcGVybWl0dGVk IGJ5IHRoZSB1c2VyLiAgVGhlIHJlc291cmNlDQogICBvd25lciBzaG91bGQgb25seSBhbGxvdyB0 cnVzdHdvcnRoeSBjbGllbnRzIHRvIGRvIHRoZSByZWN1cnNpdmUNCiAgIGRlbGVnYXRpb24uICBU aGUgcmVzb3VyY2Ugb3duZXIgc2hvdWxkIGJlIGFibGUgdG8gdHJhY2sgYWxsIHRoZQ0KICAgdHJh bnNhY3Rpb25zIHRvIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UgZnJvbSB0aGUgZGlmZmVyZW50IHRo ZQ0KICAgY2xpZW50cy91c2Vycy4gIFJlc291cmNlIG93bmVycyBzaG91bGQgYmUgYWJsZSB0byBj b21wbGFpbiBhYm91dA0KICAgY2xpZW50cyB0aGF0IGFidXNlIHRoaXMgdHJ1c3QgYXQgdGhlIHNl cnZlci4NCg0KNS4yLiAgUGhpc2hpbmcgQXR0YWNrDQoNCiAgIFNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIHJlbGF0ZWQgdG8gdGhlIHBoaXNoaW5nIGF0dGFjayBhcmUgZGVzY3JpYmVkDQogICBpbiBb ZHJhZnQtaWV0Zi1vYXV0aC13ZWItZGVsZWdhdGlvbl0uDQoNCg0KNi4gIElBTkEgQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhpcyBJbnRlcm5ldCBEcmFmdCBpbmNsdWRlcyBubyByZXF1ZXN0IHRvIElB TkEuDQoNCg0KNy4gIEFja25vd2xlZGdlbWVudHMNCg0KICAgVGhlIGF1dGhvcnMgYXJlIGdyYXRl ZnVsIHRvIElnb3IgRmF5bmJlcmcgYW5kIEh1aS1MYW4gTHUgZm9yIHRoZWlyDQogICBpbnZhbHVh YmxlIGhlbHAgd2l0aCBwcmVwYXJpbmcgdGhpcyBkb2N1bWVudC4NCg0KDQo4LiAgUmVmZXJlbmNl cw0KDQo4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIs IFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAg ICBSZXF1aXJlbWVudCBMZXZlbHMiLCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KICAgW1JGQzI2 MTZdICBGaWVsZGluZywgUi4sIEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgRnJ5c3R5aywgSC4sDQog ICAgICAgICAgICAgIE1hc2ludGVyLCBMLiwgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUs ICJIeXBlcnRleHQNCiAgICAgICAgICAgICAgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEi LCBSRkMgMjYxNiwgSnVuZSAxOTk5Lg0KDQogICBbZHJhZnQtaWV0Zi1vYXV0aC1hdXRoZW50aWNh dGlvbl0NCiAgICAgICAgICAgICAgSGFtbWVyLUxhaGF2LCBFLiwgIlRoZSBPQXV0aCBQcm90b2Nv bDogQXV0aGVudGljYXRpb24iLA0KICAgICAgICAgICAgICBkcmFmdC1pZXRmLW9hdXRoLWF1dGhl bnRpY2F0aW9uLTAxLnR4dCAod29yayBpbiBwcm9ncmVzcyksDQogICAgICAgICAgICAgIEp1bHkg MjAwOS4NCg0KICAgW2RyYWZ0LWlldGYtb2F1dGgtd2ViLWRlbGVnYXRpb25dDQogICAgICAgICAg ICAgIEhhbW1lci1MYWhhdiwgRS4sICJUaGUgT0F1dGggUHJvdG9jb2w6IFdlYiBEZWxlZ2F0aW9u IiwNCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1vYXV0aC13ZWItZGVsZWdhdGlvbi0wMS50eHQg KHdvcmsgaW4gcHJvZ3Jlc3MpLA0KICAgICAgICAgICAgICBKdWx5IDIwMDkuDQoNCg0KDQoNCg0K DQpWcmFuY2tlbiAmIFplbHRzYW4gICAgICAgIEV4cGlyZXMgTWFyY2ggNSwgMjAxMCAgICAgICAg ICAgICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgIFVzaW5nIE9BdXRoIGZvciBS ZWN1cnNpdmUgRGVsZWdhdGlvbiAgICBTZXB0ZW1iZXIgMjAwOQ0KDQoNCjguMi4gIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzI2MTddICBGcmFua3MsIFAuLCBIYWxsYW0tQmFrZXIs IEouLCBIb3N0ZXRsZXIsIEouLCBMYXdyZW5jZSwgUy4sDQogICAgICAgICAgICAgIExlYWNoLCBQ LiwgTHVvdG9uZW4sIEEuLCBhbmQgTC4gU3Rld2FydCwgIkhUVFANCiAgICAgICAgICAgICAgQXV0 aGVudGljYXRpb246IEJhc2ljIGFuZCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uIiwNCiAg ICAgICAgICAgICAgUkZDIDI2MTcsIEp1bmUgMTk5OS4NCg0KDQpBcHBlbmRpeCBBLiAgVGVybWlu b2xvZ3kNCg0KICAgVGhlIGZvbGxvd2luZyB0ZXJtcyBhcmUgdXNlZCBpbiB0aGlzIGRvY3VtZW50 IGFzIGRlZmluZWQgaW4gW2RyYWZ0LQ0KICAgaWV0Zi1vYXV0aC1hdXRoZW50aWNhdGlvbl06DQoN CiAgIENsaWVudA0KICAgICAgQW4gSFRUUCBjbGllbnQgKHBlciBbUkZDMjYxNl0pIGNhcGFibGUg b2YgbWFraW5nIE9BdXRoLQ0KICAgICAgYXV0aGVudGljYXRlZCByZXF1ZXN0cyBwZXIgW2RyYWZ0 LWlldGYtb2F1dGgtYXV0aGVudGljYXRpb25dLg0KDQogICBTZXJ2ZXINCiAgICAgIEFuIEhUVFAg c2VydmVyIChwZXIgW1JGQzI2MTZdKSBjYXBhYmxlIG9mIGFjY2VwdGluZyBPQXV0aC0NCiAgICAg IGF1dGhlbnRpY2F0ZWQgcmVxdWVzdHMgcGVyIFtkcmFmdC1pZXRmLW9hdXRoLWF1dGhlbnRpY2F0 aW9uXS4NCg0KICAgUHJvdGVjdGVkIFJlc291cmNlDQogICAgICBBbiBhY2Nlc3MtcmVzdHJpY3Rl ZCByZXNvdXJjZSAocGVyIFtSRkMyNjE2XSkgd2hpY2ggY2FuIGJlDQogICAgICBvYnRhaW5lZCBm cm9tIHRoZSBzZXJ2ZXIgdXNpbmcgYW4gT0F1dGgtYXV0aGVudGljYXRlZCByZXF1ZXN0IHBlcg0K ICAgICAgW2RyYWZ0LWlldGYtb2F1dGgtYXV0aGVudGljYXRpb25dLg0KDQogICBSZXNvdXJjZSBP d25lcg0KICAgICAgQW4gZW50aXR5IGNhcGFibGUgb2YgYWNjZXNzaW5nIGFuZCBjb250cm9sbGlu ZyBwcm90ZWN0ZWQgcmVzb3VyY2VzDQogICAgICBieSB1c2luZyBjcmVkZW50aWFscyB0byBhdXRo ZW50aWNhdGUgd2l0aCB0aGUgc2VydmVyLg0KDQogICBUb2tlbg0KICAgICAgQW4gdW5pcXVlIGlk ZW50aWZpZXIgaXNzdWVkIGJ5IHRoZSBzZXJ2ZXIgYW5kIHVzZWQgYnkgdGhlIGNsaWVudA0KICAg ICAgdG8gYXNzb2NpYXRlIGF1dGhlbnRpY2F0ZWQgcmVxdWVzdHMgd2l0aCB0aGUgcmVzb3VyY2Ug b3duZXIgd2hvc2UNCiAgICAgIGF1dGhvcml6YXRpb24gaXMgcmVxdWVzdGVkIG9yIGhhcyBiZWVu IG9idGFpbmVkIGJ5IHRoZSBjbGllbnQuDQogICAgICBUb2tlbnMgaGF2ZSBhIG1hdGNoaW5nIHNo YXJlZC1zZWNyZXQgdGhhdCBpcyB1c2VkIGJ5IHRoZSBjbGllbnQgdG8NCiAgICAgIGVzdGFibGlz aCBpdHMgb3duZXJzaGlwIG9mIHRoZSB0b2tlbiwgYW5kIGl0cyBhdXRob3JpdHkgdG8NCiAgICAg IHJlcHJlc2VudCB0aGUgcmVzb3VyY2Ugb3duZXIuDQoNCiAgIFRoZSBmb2xsb3dpbmcgdGVybXMg YXJlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudDoNCg0KICAgZmlyc3QgQ2xpZW50DQogICAgICBB IENsaWVudCB0aGF0IGhhcyBiZWVuIGF1dGhvcml6ZWQgdG8gYWNjZXNzIGEgUHJvdGVjdGVkIFJl c291cmNlDQogICAgICBieSB0aGUgUmVzb3VyY2UgT3duZXIuDQoNCiAgIHNlY29uZCBDbGllbnQN CiAgICAgIEEgQ2xpZW50IHRoYXQgaGFzIGJlZW4gYXV0aG9yaXplZCB0byBhY2Nlc3MgYSBQcm90 ZWN0ZWQgUmVzb3VyY2UNCiAgICAgIGJ5IHRoZSBGaXJzdCBDbGllbnQuDQoNCg0KDQoNClZyYW5j a2VuICYgWmVsdHNhbiAgICAgICAgRXhwaXJlcyBNYXJjaCA1LCAyMDEwICAgICAgICAgICAgICAg IFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgVXNpbmcgT0F1dGggZm9yIFJlY3Vyc2l2 ZSBEZWxlZ2F0aW9uICAgIFNlcHRlbWJlciAyMDA5DQoNCg0KQXBwZW5kaXggQi4gIE90aGVyIGV4 YW1wbGVzDQoNCiAgIFRoZSBSZXNvdXJjZSBvd25lciBjb3VsZCBkZWxlZ2F0ZSBhY2Nlc3MgYW5k IHRoZSByaWdodCB0byBkZWxlZ2F0ZSB0bw0KICAgYSBjb250ZW50IG1hbmFnZXIuICBUaGUgY29u dGVudCBtYW5hZ2VyIGNvdWxkIHByb3ZpZGUgc2V2ZXJhbCB0aGlyZA0KICAgcGFydHkgc2Vydmlj ZXMsIGxpa2UgYSBwaG90byBzZXJ2aWNlLiAgVGhlIGNvbnRlbnQgbWFuYWdlciBjb3VsZA0KICAg ZGVsZWdhdGUgYWNjZXNzIHRvIHRoZSBwaG90byBzZXJ2aWNlIG9uIGJlaGFsZiBvZiB0aGUgdXNl ciwgYWxsb3dpbmcNCiAgIHRoZSBwaG90byBzZXJ2aWNlIHRvIGdldCB0aGUgcHJvdGVjdGVkIHJl c291cmNlIGRpcmVjdGx5IGZyb20gdGhlDQogICBzZXJ2ZXIuDQoNCg0KQXV0aG9ycycgQWRkcmVz c2VzDQoNCiAgIEJhcnQgVnJhbmNrZW4NCiAgIEFsY2F0ZWwtTHVjZW50DQogICBDb3Blcm5pY3Vz bGFhbiA1MA0KICAgMjAxOCBBbnR3ZXJwLA0KICAgQmVsZ2l1bQ0KDQogICBQaG9uZTogKzMyIDMg MjQwOTgwNA0KICAgRW1haWw6IEJhcnQuYnYuVnJhbmNrZW5AYWxjYXRlbC1sdWNlbnQuYmUNCg0K DQogICBaYWNoYXJ5IFplbHRzYW4NCiAgIEFsY2F0ZWwtTHVjZW50DQogICA2MDAgTW91bnRhaW4g QXZlbnVlDQogICBNdXJyYXkgSGlsbCwgTmV3IEplcnN5DQogICBVU0ENCg0KICAgUGhvbmU6ICsx IDkwOCA1ODIgMjM1OQ0KICAgRW1haWw6IHplbHRzYW5AYWxjYXRlbC1sdWNlbnQuY29tDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpWcmFuY2tlbiAmIFplbHRzYW4g ICAgICAgIEV4cGlyZXMgTWFyY2ggNSwgMjAxMCAgICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwN Cg0K --_004_5710F82C0E73B04FA559560098BF95B124EDC376C6USNAVSXCHMBSA_-- From stpeter@stpeter.im Wed Sep 9 08:27:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF243A6A1F for ; Wed, 9 Sep 2009 08:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pp80Ou00QhaC for ; Wed, 9 Sep 2009 08:27:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 108263A6B4A for ; Wed, 9 Sep 2009 08:27:45 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2FEDA4007B for ; Wed, 9 Sep 2009 09:28:17 -0600 (MDT) Message-ID: <4AA7C986.9010701@stpeter.im> Date: Wed, 09 Sep 2009 09:28:06 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [Fwd: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:27:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. Please help the NomCom complete its work by nominating qualified folks for the open IETF-related positions listed at https://wiki.tools.ietf.org/group/nomcom/09/ -- visit https://wiki.tools.ietf.org/group/nomcom/09/nominate to complete the nomination process. Thanks! /psa - -------- Original Message -------- Subject: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available Date: Wed, 9 Sep 2009 07:37:59 -0700 (PDT) From: Mary Barnes To: IETF Announcement list CC: ietf@ietf.org Hi all, This is a 2nd reminder of the Call for Nominations that is underway. We *really* need more nominations in order to properly execute the task of selecting candidates for the open positions. At this time, the number of nominations for all the positions is about 1/2 of what is necessary for the Nomcom to do a conscientious job of evaluating the nominees and we are over 2/3 of the way through the nominations period. Nomcom cannot do their job without this important input from the community. So, please consider making nominations for the open positions - it takes just a few minutes of your time - the details are below. Right now, we just need the names/email addresses for the nominees - we'll be soliciting feedback later. Also, consider that over 1/2 the nominees are not able to accept the nominations for a variety of reasons - e.g., lack of funding, lack of sponsor support, etc. Thus, please consider nominating more than one individual for each of the positions. As well as the reminder for the call for nominations, this email also serves as a reminder for: 2) Local Office Hours 3) Questionnaires available for nominees Best Regards, Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com ========================================================================= 1) Call for Nominations - ------------------------ The nomination period ends in less than 2 weeks on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's fast, easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ Please consider that the sooner you make the nominations, the more time your nominee(s) will have to complete the necessary questionnaire (item 3 below). As well, please consider nominating more than one person for a particular position. You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination. 2) Local office hours - ----------------------- In order facilitate additional feedback, the Nomcom has decided to make themselves available for office areas at various geographic locations for 3 weeks in September, starting on the 8th. Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback. Belgium: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French) Boston, Mass, USA: Stephen Kent - kent@bbn.com (Sept 16-18) Boulder, CO, USA: Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: Mary Barnes - mary.h.barnes@gmail.com Lucy Yong - lucyyong@huawei.com (Languages: Chinese) Helsinki, Finland: Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) Ithaca, NY, USA: Scott Brim - scott.brim@gmail.com Montevideo, Uruguay: Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese) Montreal, Quebec, Canada Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested Paris, France: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA: Randall Gellens - rg+ietf@qualcomm.com Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA: Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees: For folks that have been notified that they have been nominated for any of the positions, the questionnaires are now available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire If you have any questions, please let me know. I will be contacting everyone individually, as well as sending reminders. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqnyYYACgkQNL8k5A2w/vyYtwCgqLpNYKgrEfQ1uxii94NCCiuz eqYAoNQ82XXiCfW1b3vIpdnxtE4/Xpko =Ksfq -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Sep 9 09:23:57 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBCC33A6934 for ; Wed, 9 Sep 2009 09:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5kzms0va2+x for ; Wed, 9 Sep 2009 09:23:56 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C44B63A67F9 for ; Wed, 9 Sep 2009 09:23:56 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 74B9A4007B for ; Wed, 9 Sep 2009 10:24:29 -0600 (MDT) Message-ID: <4AA7D6BA.9070406@stpeter.im> Date: Wed, 09 Sep 2009 10:24:26 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 16:23:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As seen on the i-d-announce@ietf.org list just now. Perhaps the authors would like to provide a friendly introduction to their work? :) /psa - -------- Original Message -------- Subject: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt Date: Wed, 9 Sep 2009 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using OAuth for Recursive Delegation Author(s) : B. Vrancken, Z. Zeltsan Filename : draft-vrancken-oauth-redelegation-00.txt Pages : 11 Date : 2009-9-4 This document describes a use case for delegating authorization by a Resource Owner to another user via a Client using the OAuth protocol. OAuth allows Clients to access server resources on behalf of another party (such as a different Client or an end-user). This document describes the use of OAuth for delegating one Client's authorization to another Client - a scenario, which is also known as four-legged authorization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vrancken-oauth-redelegation-00.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqn1roACgkQNL8k5A2w/vyW1wCeImOus7lIB1MV4wqQ1cF25mWz DZUAnjqmTRH8JX4vKFbkeOEHS1ahVijP =rPFC -----END PGP SIGNATURE----- From rbarnes@bbn.com Wed Sep 9 18:34:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE97D3A6AD7 for ; Wed, 9 Sep 2009 18:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7Z2inBXQQ8R for ; Wed, 9 Sep 2009 18:34:23 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E14CA3A6AC4 for ; Wed, 9 Sep 2009 18:34:19 -0700 (PDT) Received: from [128.89.255.242] (helo=col-rbarnes-l1.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MlYYl-0003D0-Aq; Wed, 09 Sep 2009 21:34:52 -0400 Message-ID: <4AA857B6.7020806@bbn.com> Date: Wed, 09 Sep 2009 21:34:46 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Peter Saint-Andre References: <4AA7D6BA.9070406@stpeter.im> In-Reply-To: <4AA7D6BA.9070406@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 01:34:23 -0000 Think they already did, to first order: Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > As seen on the i-d-announce@ietf.org list just now. Perhaps the authors > would like to provide a friendly introduction to their work? :) > > /psa > > - -------- Original Message -------- > Subject: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt > Date: Wed, 9 Sep 2009 09:15:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Using OAuth for Recursive Delegation > Author(s) : B. Vrancken, Z. Zeltsan > Filename : draft-vrancken-oauth-redelegation-00.txt > Pages : 11 > Date : 2009-9-4 > > This document describes a use case for delegating authorization by a > Resource Owner to another user via a Client using the OAuth protocol. > OAuth allows Clients to access server resources on behalf of another > party (such as a different Client or an end-user). This document > describes the use of OAuth for delegating one Client's authorization > to another Client - a scenario, which is also known as four-legged > authorization. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vrancken-oauth-redelegation-00.txt > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqn1roACgkQNL8k5A2w/vyW1wCeImOus7lIB1MV4wqQ1cF25mWz > DZUAnjqmTRH8JX4vKFbkeOEHS1ahVijP > =rPFC > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From faynberg@alcatel-lucent.com Thu Sep 10 10:53:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5F93A68D3 for ; Thu, 10 Sep 2009 10:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7YLnJMUSK+E for ; Thu, 10 Sep 2009 10:53:52 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id D904F28C1AB for ; Thu, 10 Sep 2009 10:53:41 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n8AHs4xe006739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2009 12:54:04 -0500 (CDT) Received: from alcatel-lucent.com (faynberg.lra.lucent.com [135.244.18.193]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n8AHs2Mq008995; Thu, 10 Sep 2009 12:54:03 -0500 (CDT) Message-ID: <4AA93D3A.30800@alcatel-lucent.com> Date: Thu, 10 Sep 2009 13:54:02 -0400 From: Igor Faynberg Organization: Bell Labs, Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en,el MIME-Version: 1.0 To: Richard Barnes References: <4AA7D6BA.9070406@stpeter.im> <4AA857B6.7020806@bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 17:53:53 -0000 Richard, The authors are traveling now, so I will be happy to chime-in. (Incidentally, Zachary had sent a notice to this list some time before.) In short, this is a follow-up on 1) an interesting discussion on the list Re: "four-legged" approach; and 2) the bar meeting at the last IETF, which Zachary attended. Here, in compliance with what appeared to be the consensus of the bar meeting, the term of "four-legged" was dropped. The concept has been described as "recursive delegation." The goal of the draft was to document it and provide a use case. With best regards, Igor On 9/9/2009 9:34 PM, Richard Barnes wrote: > Think they already did, to first order: > > > > Peter Saint-Andre wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >> >> >>As seen on the i-d-announce@ietf.org list just now. Perhaps the authors >>would like to provide a friendly introduction to their work? :) >> >>/psa >> >>- -------- Original Message -------- >>Subject: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt >>Date: Wed, 9 Sep 2009 09:15:01 -0700 (PDT) >>From: Internet-Drafts@ietf.org >>Reply-To: internet-drafts@ietf.org >>To: i-d-announce@ietf.org >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : Using OAuth for Recursive Delegation >> Author(s) : B. Vrancken, Z. Zeltsan >> Filename : draft-vrancken-oauth-redelegation-00.txt >> Pages : 11 >> Date : 2009-9-4 >> >> This document describes a use case for delegating authorization by a >> Resource Owner to another user via a Client using the OAuth protocol. >> OAuth allows Clients to access server resources on behalf of another >> party (such as a different Client or an end-user). This document >> describes the use of OAuth for delegating one Client's authorization >> to another Client - a scenario, which is also known as four-legged >> authorization. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-vrancken-oauth-redelegation-00.txt >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.8 (Darwin) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >>iEYEARECAAYFAkqn1roACgkQNL8k5A2w/vyW1wCeImOus7lIB1MV4wqQ1cF25mWz >>DZUAnjqmTRH8JX4vKFbkeOEHS1ahVijP >>=rPFC >>-----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 eran@hueniverse.com Fri Sep 11 00:09:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CEB43A694F for ; Fri, 11 Sep 2009 00:09:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -4.068 X-Spam-Level: X-Spam-Status: No, score=-4.068 tagged_above=-999 required=5 tests=[AWL=-1.469, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKVTglNOEDQG for ; Fri, 11 Sep 2009 00:09:35 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8F9F83A6820 for ; Fri, 11 Sep 2009 00:09:35 -0700 (PDT) Received: (qmail 11827 invoked from network); 11 Sep 2009 07:10:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Sep 2009 07:10:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 11 Sep 2009 00:08:10 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Fri, 11 Sep 2009 00:09:56 -0700 Thread-Topic: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt Thread-Index: AcoxaQnu9lTMsnhlQ46piSOoeTE4/ABRdDfA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784CB7264@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_90C41DD21FB7C64BB94121FBBC2E72343784CB7264P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] FW: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 07:09:36 -0000 --_003_90C41DD21FB7C64BB94121FBBC2E72343784CB7264P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, September 09, 2009 9:15 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Using OAuth for Recursive Delegation Author(s) : B. Vrancken, Z. Zeltsan Filename : draft-vrancken-oauth-redelegation-00.txt Pages : 11 Date : 2009-9-4 =09 This document describes a use case for delegating authorization by a Resource Owner to another user via a Client using the OAuth protocol. OAuth allows Clients to access server resources on behalf of another p= arty (such as a different Client or an end-user). This document describes the use of OAuth for delegating one Client's authorization to another Client - a scenario, which is also known as four-legged authorization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vrancken-oauth-redelegation-00.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --_003_90C41DD21FB7C64BB94121FBBC2E72343784CB7264P3PW5EX1MB01E_ Content-Type: message/external-body; name="draft-vrancken-oauth-redelegation-00.url" Content-Description: draft-vrancken-oauth-redelegation-00.url Content-Disposition: attachment; filename="draft-vrancken-oauth-redelegation-00.url"; size=101; creation-date="Wed, 09 Sep 2009 09:17:34 GMT"; modification-date="Wed, 09 Sep 2009 09:17:34 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC12cmFuY2tlbi1vYXV0aC1yZWRlbGVnYXRpb24tMDAudHh0DQo= --_003_90C41DD21FB7C64BB94121FBBC2E72343784CB7264P3PW5EX1MB01E_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=258; creation-date="Wed, 09 Sep 2009 09:17:34 GMT"; modification-date="Wed, 09 Sep 2009 09:17:34 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_003_90C41DD21FB7C64BB94121FBBC2E72343784CB7264P3PW5EX1MB01E_-- From stpeter@stpeter.im Wed Sep 16 18:18:06 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F1D28C158 for ; Wed, 16 Sep 2009 18:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOWJVEe6P+9G for ; Wed, 16 Sep 2009 18:18:05 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B12D23A6A7D for ; Wed, 16 Sep 2009 18:18:05 -0700 (PDT) Received: from squire.local (dsl-179-156.dynamic-dsl.frii.net [216.17.179.156]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E854440D12 for ; Wed, 16 Sep 2009 19:18:55 -0600 (MDT) Message-ID: <4AB18E7E.7000105@stpeter.im> Date: Wed, 16 Sep 2009 19:18:54 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [OAUTH-WG] [Fwd: [oauth] Re: Signing PUT request] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 01:18:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. - -------- Original Message -------- Subject: [oauth] Re: Signing PUT request Date: Wed, 16 Sep 2009 19:17:43 -0600 From: Peter Saint-Andre Reply-To: oauth@googlegroups.com To: oauth@googlegroups.com On 9/16/09 6:31 PM, Hannes Tydén wrote: > On Sep 17, 1:12 am, Hans Granqvist wrote: > >> seems to leave PUT requests with form-encoded name/value pairs in a >> bad spot, not covered by the core spec (which only deals with POSTs), >> nor covered by the body hash spec. > > I will rephrase my initial question: > Is it true that the base string for "application/x-www-form- > urlencoded" PUT requests should not contain the parameters in the > request body according to the 1.0 core specification? > > Section "9.1.1 Normalize Request Parameters" (http://oauth.net/core/ > 1.0#anchor14) says: > "Parameters in the HTTP POST request body (with a content-type of > application/x-www-form-urlencoded)." > > If "HTTP POST request body" should be interpreted as "the request body > if it is a POST request", "application/x-www-form-urlencoded" PUT > requests are wide open for man-in-the-middle attacks. > > If it should be interpreted as "the request body of any kind of > request", I'm fine with this and we could move along. That seems to be the most reasonable interpretation. > In any case the wording is too ambiguous, leaving room for > interpretation. I'd suggest that an amendment should be done to the > specification. IMHO this needs to be clarified in the Internet-Draft. I'll forward this message to oauth@ietf.org list. Peter - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en - -~----------~----~----~----~------~----~------~--~--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqxjn4ACgkQNL8k5A2w/vxcfQCggVPhFeyrgkktxtZyKRH0uHfO +VMAoPiltQS/Nv4hRM0kwrTqWaxMYXSJ =iCi/ -----END PGP SIGNATURE----- From eran@hueniverse.com Thu Sep 17 00:51:54 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD313A68F4 for ; Thu, 17 Sep 2009 00:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.659 X-Spam-Level: X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=-2.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8laGnwAOp45U for ; Thu, 17 Sep 2009 00:51:53 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 196233A68B7 for ; Thu, 17 Sep 2009 00:51:52 -0700 (PDT) Received: (qmail 31428 invoked from network); 17 Sep 2009 07:52:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Sep 2009 07:52:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 17 Sep 2009 00:48:38 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre , "oauth@ietf.org" Date: Thu, 17 Sep 2009 00:50:55 -0700 Thread-Topic: [OAUTH-WG] [Fwd: [oauth] Re: Signing PUT request] Thread-Index: Aco3NNYmKRQf2lzJStmmCWO2cIAhHgANrI0Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D57E88@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4AB18E7E.7000105@stpeter.im> In-Reply-To: <4AB18E7E.7000105@stpeter.im> 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 Subject: Re: [OAUTH-WG] [Fwd: [oauth] Re: Signing PUT request] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 07:51:54 -0000 Tm90IGFuIGlzc3VlLiBUaGUgY3VycmVudCBsYW5ndWFnZSBpczoNCg0KICAgVGhlIHJlcXVlc3Qg cGFyYW1ldGVycywgd2hpY2ggaW5jbHVkZSBib3RoIHByb3RvY29sIHBhcmFtZXRlcnMgYW5kDQog ICByZXF1ZXN0LXNwZWNpZmljIHBhcmFtZXRlcnMsIGFyZSBleHRyYWN0ZWQgYW5kIHJlc3RvcmVk IHRvIHRoZWlyDQogICBvcmlnaW5hbCB1bmVuY29kZWQgZm9ybSwgZnJvbSB0aGUgZm9sbG93aW5n IHNvdXJjZXM6DQoNCiAgIG8gIFRoZSBPQXV0aCBIVFRQIEF1dGhvcml6YXRpb24gaGVhZGVyIChT ZWN0aW9uIDcuMSkuICBUaGUgInJlYWxtIg0KICAgICAgcGFyYW1ldGVyIE1VU1QgYmUgZXhjbHVk ZWQgaWYgcHJlc2VudC4NCg0KICAgbyAgVGhlIEhUVFAgcmVxdWVzdCBlbnRpdHktYm9keSwgYnV0 IG9ubHkgaWY6DQoNCiAgICAgICogIFRoZSBlbnRpdHktYm9keSBpcyBzaW5nbGUtcGFydC4NCg0K ICAgICAgKiAgVGhlIGVudGl0eS1ib2R5IGZvbGxvd3MgdGhlIGVuY29kaW5nIHJlcXVpcmVtZW50 cyBvZiB0aGUNCiAgICAgICAgICJhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQiIGNv bnRlbnQtdHlwZSBhcyBkZWZpbmVkIGJ5DQogICAgICAgICBbVzNDLlJFQy1odG1sNDAtMTk5ODA0 MjRdLg0KDQogICAgICAqICBUaGUgSFRUUCByZXF1ZXN0IGVudGl0eS1oZWFkZXIgaW5jbHVkZXMg dGhlICJDb250ZW50LVR5cGUiDQogICAgICAgICBoZWFkZXIgc2V0IHRvICJhcHBsaWNhdGlvbi94 LXd3dy1mb3JtLXVybGVuY29kZWQiLg0KDQogICBvICBUaGUgcXVlcnkgY29tcG9uZW50IG9mIHRo ZSBIVFRQIHJlcXVlc3QgVVJJIGFzIGRlZmluZWQgYnkNCiAgICAgIFtSRkMzOTg2XSBzZWN0aW9u IDMuDQoNCiAgIFRoZSAib2F1dGhfc2lnbmF0dXJlIiBwYXJhbWV0ZXIgTVVTVCBiZSBleGNsdWRl ZCBpZiBwcmVzZW50Lg0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmDQo+IE9mIFBldGVyIFNhaW50LUFuZHJlDQo+IFNlbnQ6IFdlZG5lc2RheSwg U2VwdGVtYmVyIDE2LCAyMDA5IDY6MTkgUE0NCj4gVG86IG9hdXRoQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFtPQVVUSC1XR10gW0Z3ZDogW29hdXRoXSBSZTogU2lnbmluZyBQVVQgcmVxdWVzdF0NCj4g DQo+IC0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0NCj4gSGFzaDogU0hBMQ0KPiAN Cj4gRllJLg0KPiANCj4gLSAtLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQo+IFN1 YmplY3Q6IFtvYXV0aF0gUmU6IFNpZ25pbmcgUFVUIHJlcXVlc3QNCj4gRGF0ZTogV2VkLCAxNiBT ZXAgMjAwOSAxOToxNzo0MyAtMDYwMA0KPiBGcm9tOiBQZXRlciBTYWludC1BbmRyZSA8c3RwZXRl ckBzdHBldGVyLmltPg0KPiBSZXBseS1Ubzogb2F1dGhAZ29vZ2xlZ3JvdXBzLmNvbQ0KPiBUbzog b2F1dGhAZ29vZ2xlZ3JvdXBzLmNvbQ0KPiANCj4gDQo+IE9uIDkvMTYvMDkgNjozMSBQTSwgSGFu bmVzIFR5ZMOpbiB3cm90ZToNCj4gPiBPbiBTZXAgMTcsIDE6MTIgYW0sIEhhbnMgR3JhbnF2aXN0 IDxoLi4uQGdyYW5xdmlzdC5jb20+IHdyb3RlOg0KPiA+DQo+ID4+IHNlZW1zIHRvIGxlYXZlIFBV VCByZXF1ZXN0cyB3aXRoIGZvcm0tZW5jb2RlZCBuYW1lL3ZhbHVlIHBhaXJzIGluIGENCj4gPj4g YmFkIHNwb3QsIG5vdCBjb3ZlcmVkIGJ5IHRoZSBjb3JlIHNwZWMgKHdoaWNoIG9ubHkgZGVhbHMg d2l0aA0KPiBQT1NUcyksDQo+ID4+IG5vciBjb3ZlcmVkIGJ5IHRoZSBib2R5IGhhc2ggc3BlYy4N Cj4gPg0KPiA+IEkgd2lsbCByZXBocmFzZSBteSBpbml0aWFsIHF1ZXN0aW9uOg0KPiA+IElzIGl0 IHRydWUgdGhhdCB0aGUgYmFzZSBzdHJpbmcgZm9yICJhcHBsaWNhdGlvbi94LXd3dy1mb3JtLQ0K PiA+IHVybGVuY29kZWQiIFBVVCByZXF1ZXN0cyBzaG91bGQgbm90IGNvbnRhaW4gdGhlIHBhcmFt ZXRlcnMgaW4gdGhlDQo+ID4gcmVxdWVzdCBib2R5IGFjY29yZGluZyB0byB0aGUgMS4wIGNvcmUg c3BlY2lmaWNhdGlvbj8NCj4gPg0KPiA+IFNlY3Rpb24gIjkuMS4xIE5vcm1hbGl6ZSBSZXF1ZXN0 IFBhcmFtZXRlcnMiIChodHRwOi8vb2F1dGgubmV0L2NvcmUvDQo+ID4gMS4wI2FuY2hvcjE0KSBz YXlzOg0KPiA+ICJQYXJhbWV0ZXJzIGluIHRoZSBIVFRQIFBPU1QgcmVxdWVzdCBib2R5ICh3aXRo IGEgY29udGVudC10eXBlIG9mDQo+ID4gYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVk KS4iDQo+ID4NCj4gPiBJZiAiSFRUUCBQT1NUIHJlcXVlc3QgYm9keSIgc2hvdWxkIGJlIGludGVy cHJldGVkIGFzICJ0aGUgcmVxdWVzdA0KPiBib2R5DQo+ID4gaWYgaXQgaXMgYSBQT1NUIHJlcXVl c3QiLCAiYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkIiBQVVQNCj4gPiByZXF1ZXN0 cyBhcmUgd2lkZSBvcGVuIGZvciBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2tzLg0KPiA+DQo+ID4g SWYgaXQgc2hvdWxkIGJlIGludGVycHJldGVkIGFzICJ0aGUgcmVxdWVzdCBib2R5IG9mIGFueSBr aW5kIG9mDQo+ID4gcmVxdWVzdCIsIEknbSBmaW5lIHdpdGggdGhpcyBhbmQgd2UgY291bGQgbW92 ZSBhbG9uZy4NCj4gDQo+IFRoYXQgc2VlbXMgdG8gYmUgdGhlIG1vc3QgcmVhc29uYWJsZSBpbnRl cnByZXRhdGlvbi4NCj4gDQo+ID4gSW4gYW55IGNhc2UgdGhlIHdvcmRpbmcgaXMgdG9vIGFtYmln dW91cywgbGVhdmluZyByb29tIGZvcg0KPiA+IGludGVycHJldGF0aW9uLiBJJ2Qgc3VnZ2VzdCB0 aGF0IGFuIGFtZW5kbWVudCBzaG91bGQgYmUgZG9uZSB0byB0aGUNCj4gPiBzcGVjaWZpY2F0aW9u Lg0KPiANCj4gSU1ITyB0aGlzIG5lZWRzIHRvIGJlIGNsYXJpZmllZCBpbiB0aGUgSW50ZXJuZXQt RHJhZnQuIEknbGwgZm9yd2FyZA0KPiB0aGlzDQo+IG1lc3NhZ2UgdG8gb2F1dGhAaWV0Zi5vcmcg bGlzdC4NCj4gDQo+IFBldGVyDQo+IA0KPiANCj4gLSAtLX4tLX4tLS0tLS0tLS1+LS1+LS0tLX4t LS0tLS0tLS0tLS1+LS0tLS0tLX4tLX4tLS0tfg0KPiBZb3UgcmVjZWl2ZWQgdGhpcyBtZXNzYWdl IGJlY2F1c2UgeW91IGFyZSBzdWJzY3JpYmVkIHRvIHRoZSBHb29nbGUNCj4gR3JvdXBzICJPQXV0 aCIgZ3JvdXAuDQo+IFRvIHBvc3QgdG8gdGhpcyBncm91cCwgc2VuZCBlbWFpbCB0byBvYXV0aEBn b29nbGVncm91cHMuY29tDQo+IFRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBncm91cCwgc2VuZCBl bWFpbCB0bw0KPiBvYXV0aCt1bnN1YnNjcmliZUBnb29nbGVncm91cHMuY29tDQo+IEZvciBtb3Jl IG9wdGlvbnMsIHZpc2l0IHRoaXMgZ3JvdXAgYXQNCj4gaHR0cDovL2dyb3Vwcy5nb29nbGUuY29t L2dyb3VwL29hdXRoP2hsPWVuDQo+IC0gLX4tLS0tLS0tLS0tfi0tLS1+LS0tLX4tLS0tfi0tLS0t LX4tLS0tfi0tLS0tLX4tLX4tLS0NCj4gDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0t DQo+IFZlcnNpb246IEdudVBHIHYxLjQuOCAoRGFyd2luKQ0KPiBDb21tZW50OiBVc2luZyBHbnVQ RyB3aXRoIE1vemlsbGEgLSBodHRwOi8vZW5pZ21haWwubW96ZGV2Lm9yZy8NCj4gDQo+IGlFWUVB UkVDQUFZRkFrcXhqbjRBQ2drUU5MOGs1QTJ3L3Z4Y2ZRQ2dnVlBoRmV5cmdra3R4dFp5S1JIMHVI Zk8NCj4gK1ZNQW9QaWx0UVMvTnY0aFJNMGt3clRxV2F4TVlYU0oNCj4gPWlDaS8NCj4gLS0tLS1F TkQgUEdQIFNJR05BVFVSRS0tLS0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= From stpeter@stpeter.im Thu Sep 17 06:32:35 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5331E28C264 for ; Thu, 17 Sep 2009 06:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opL1kTj9MQdN for ; Thu, 17 Sep 2009 06:32:34 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6F49A28C25E for ; Thu, 17 Sep 2009 06:32:34 -0700 (PDT) Received: from squire.local (dsl-179-156.dynamic-dsl.frii.net [216.17.179.156]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0B9E340D12; Thu, 17 Sep 2009 07:33:15 -0600 (MDT) Message-ID: <4AB23A89.5040207@stpeter.im> Date: Thu, 17 Sep 2009 07:32:57 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4AB18E7E.7000105@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343784D57E88@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D57E88@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Fwd: [oauth] Re: Signing PUT request] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 13:32:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/17/09 1:50 AM, Eran Hammer-Lahav wrote: > Not an issue. Great. The fewer issues the better. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqyOokACgkQNL8k5A2w/vwnsQCffQVzFfzXvwSJ6Y6XoDC3Dmyn RNUAnAktFC6zlWr9vgW6DYupPy4ALVdh =fjqz -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Sep 17 12:18:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB623A68C3 for ; Thu, 17 Sep 2009 12:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4di82ksgWsrB for ; Thu, 17 Sep 2009 12:18:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A541B3A681F for ; Thu, 17 Sep 2009 12:18:48 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6F6C340D1C for ; Thu, 17 Sep 2009 13:19:30 -0600 (MDT) Message-ID: <4AB28BB7.4030206@stpeter.im> Date: Thu, 17 Sep 2009 13:19:19 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [Fwd: Nomcom 2009-10: FINAL Call for Nominations, Local Office hours, Nominee Questionnaires] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 19:18:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. Note that the NomCom does not have enough nominations for our area (Apps). Visit https://wiki.tools.ietf.org/group/nomcom/09/nominate to make nominations. Thanks! /psa - -------- Original Message -------- Subject: Nomcom 2009-10: FINAL Call for Nominations, Local Office hours, Nominee Questionnaires Date: Wed, 16 Sep 2009 20:07:03 -0700 (PDT) From: Mary Barnes To: IETF Announcement list CC: ietf@ietf.org Hi all, This is the Final Call for Nominations - the nominations period ends in two days on Sept 18, 2009. We do not have a sufficient number of nominations for the following AD positions: APP, OPS, RAI and SEC In addition, we have not received responses from almost half of the nominees. I will be sending reminders for all the outstanding nominations. We need Community input and participation!!! We cannot properly execute the task of selecting the best candidates for these positions with so few accepted nominations. So, please consider making nominations for the open positions, in particular those for which we have so few nominations - it takes just a few minutes of your time. Right now, we just need the names/email addresses - we'll be soliciting feedback later. Also, please note that although draft-dawkins-nomcom-openlist-06 has been approved, the 2009-10 Nomcom is NOT operating under these new guidelines. As well as the reminder for the call for nominations, this email also serves as a reminder for: 2) Local Office Hours through Sept. 25, 2009. 3) Questionnaires due from Nominees on Sept. 25, 2009. Best Regards, Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com ========================================================================= 1) Call for Nominations - ------------------------ The nomination period ends in less than 2 days on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's fast, easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination. 2) Local office hours - ----------------------- In order facilitate additional feedback, the Nomcom has decided to make themselves available for office areas at various geographic locations from September 8th through Sept. 25th. Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback. Belgium: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French) Boston, Mass, USA: Stephen Kent - kent@bbn.com (Sept 16-18) Boulder, CO, USA: Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: Mary Barnes - mary.h.barnes@gmail.com Lucy Yong - lucyyong@huawei.com (Languages: Chinese) Helsinki, Finland: Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) Ithaca, NY, USA: Scott Brim - scott.brim@gmail.com Montevideo, Uruguay: Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese) Montreal, Quebec, Canada Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested Paris, France: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA: Randall Gellens - rg+ietf@qualcomm.com Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA: Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees: For folks that have been notified that they have been nominated for any of the positions, the questionnaires are available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire The questionnaires are due no later than Sept. 25th, 2009. If you have any questions or concerns with meeting the deadline, please let me know. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqyi7YACgkQNL8k5A2w/vzMqACgo5WjXrZ3wHwXbzgap2zQMny9 MWIAoJAB+HnOqUlvbiET37tPf+s8MCnp =0IPN -----END PGP SIGNATURE----- From zeltsan@alcatel-lucent.com Fri Sep 18 00:53:30 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594B13A6AD9 for ; Fri, 18 Sep 2009 00:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7-pqrzxPOaa for ; Fri, 18 Sep 2009 00:53:29 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 2BC653A6AF3 for ; Fri, 18 Sep 2009 00:53:28 -0700 (PDT) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n8I7s9nH020891; Fri, 18 Sep 2009 02:54:09 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id n8I7s8OJ015092; Fri, 18 Sep 2009 02:54:09 -0500 (CDT) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 18 Sep 2009 02:54:08 -0500 From: "Zeltsan, Zachary (Zachary)" To: Peter Saint-Andre Date: Fri, 18 Sep 2009 02:54:06 -0500 Thread-Topic: [OAUTH-WG] [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] Thread-Index: AcoyP8X3nD1IZlrIR+m8bThcHTkRLgF9GyfA Message-ID: <5710F82C0E73B04FA559560098BF95B124EDD1B169@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4AA7D6BA.9070406@stpeter.im> <4AA857B6.7020806@bbn.com> <4AA93D3A.30800@alcatel-lucent.com> In-Reply-To: <4AA93D3A.30800@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 07:53:30 -0000 Peter, We briefly introduced the draft in the original email, which Richard has me= ntioned. As Igor has explained, the goal of the draft is to describe a use = case for the "four-legged" OAuth. (Richard's and Igor's messages are attach= ed). The term "four-legged" was criticized at the Breakfast BoF, so it is n= ot used (although is mentioned) in the draft. The draft also explains the u= se of the OAuth for the recursive ("n-legged") delegation. Zachary =20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Igor Faynberg > Sent: Thursday, September 10, 2009 1:54 PM > To: Richard Barnes > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] [Fwd: I-D=20 > ACTION:draft-vrancken-oauth-redelegation-00.txt] >=20 > Richard, >=20 > The authors are traveling now, so I will be happy to=20 > chime-in. (Incidentally, Zachary had sent a notice to this=20 > list some time before.) >=20 > In short, this is a follow-up on 1) an interesting discussion=20 > on the list Re: > "four-legged" approach; and 2) the bar meeting at the last=20 > IETF, which Zachary attended. >=20 > Here, in compliance with what appeared to be the consensus of=20 > the bar meeting, the term of "four-legged" was dropped. The=20 > concept has been described as "recursive delegation." The=20 > goal of the draft was to document it and provide a use case. >=20 > With best regards, >=20 > Igor >=20 > On 9/9/2009 9:34 PM, Richard Barnes wrote: > > Think they already did, to first order: > > > >=20 > >=20 > > Peter Saint-Andre wrote: > >=20 > >>-----BEGIN PGP SIGNED MESSAGE----- > >>Hash: SHA1 > >> > >> > >> > >>As seen on the i-d-announce@ietf.org list just now. Perhaps the=20 > >>authors would like to provide a friendly introduction to=20 > their work?=20 > >>:) > >> > >>/psa > >> > >>- -------- Original Message -------- > >>Subject: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt > >>Date: Wed, 9 Sep 2009 09:15:01 -0700 (PDT) > >>From: Internet-Drafts@ietf.org > >>Reply-To: internet-drafts@ietf.org > >>To: i-d-announce@ietf.org > >> > >>A New Internet-Draft is available from the on-line Internet-Drafts=20 > >>directories. > >> > >> > >> Title : Using OAuth for Recursive Delegation > >> Author(s) : B. Vrancken, Z. Zeltsan > >> Filename : draft-vrancken-oauth-redelegation-00.txt > >> Pages : 11 > >> Date : 2009-9-4 > >>=09 > >> This document describes a use case for delegating=20 > authorization by a > >> Resource Owner to another user via a Client using the=20 > OAuth protocol. > >> OAuth allows Clients to access server resources on behalf of=20 > >> another party (such as a different Client or an=20 > end-user). This document > >> describes the use of OAuth for delegating one Client's=20 > authorization > >> to another Client - a scenario, which is also known as=20 > four-legged > >> authorization. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-vrancken-oauth-red > elegation- > >>00.txt > >> > >>-----BEGIN PGP SIGNATURE----- > >>Version: GnuPG v1.4.8 (Darwin) > >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> > >>iEYEARECAAYFAkqn1roACgkQNL8k5A2w/vyW1wCeImOus7lIB1MV4wqQ1cF25mWz > >>DZUAnjqmTRH8JX4vKFbkeOEHS1ahVijP > >>=3DrPFC > >>-----END PGP SIGNATURE----- > >>_______________________________________________ > >>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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > = From esjewett@gmail.com Sat Sep 19 06:14:17 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F843A6359 for ; Sat, 19 Sep 2009 06:14:17 -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.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9hwufw70j30 for ; Sat, 19 Sep 2009 06:14:16 -0700 (PDT) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by core3.amsl.com (Postfix) with ESMTP id 1AFC13A681B for ; Sat, 19 Sep 2009 06:14:15 -0700 (PDT) Received: by fxm6 with SMTP id 6so1184097fxm.43 for ; Sat, 19 Sep 2009 06:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=jmUgrS3UfWEorotdQlKOkWvIUOgIvj9Yjq/MkmHQCRw=; b=OIbPdX44VYctBgq//1UQgVv/Asbcr/jAnQxzvFROAhLhrGjrlRI5+HFrzRbtlstAgw kUfry9xfUr7KTr8zXYP9/nXztid48TKVTvS9r5ZGfhaBZU5V2gBHieBNpwJI8TiqlPui WpzK2GFIdLDJteGh802odIORjGnQAtEmuXrx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oXBPHTTeVhzh9BzxDrOoURLKZY3g2QARRCBwoI56+j3BxYVy/lAFlhlVFN0O3D0k6R xhD6J1rZ2yOfGxeL+jir0h0BbUKNkBIta08Jh4HYQ0jfjS4eSMY/W/SwQ7gItIu2eirv FeXicgLHrGk9Wfr77hgk9oDxLPZXbOLEGVCD8= MIME-Version: 1.0 Received: by 10.239.184.147 with SMTP id y19mr197515hbg.60.1253366108293; Sat, 19 Sep 2009 06:15:08 -0700 (PDT) Date: Sat, 19 Sep 2009 08:15:08 -0500 Message-ID: <68f4a0e80909190615m757fae73qcf3a83b879b22baa@mail.gmail.com> From: Ethan Jewett To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Comments on draft-ietf-oauth-authentication-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 13:14:17 -0000 All, I was able to thoroughly read through draft-ietf-oauth-authentication-01 and my comments are below. Apologies if calling out typos and grammar issues is out of scope of this discussion, or if these topics have been addressed before. I've used a couple of OAuth libraries and tracked development of the community and IETF specs, but I'm by no means an expert on any of this or the IETF process. That said, these are my comments on draft-ietf-oauth-authentication-01 (http://tools.ietf.org/html/draft-ietf-oauth-authentication-01) split up by section: Abstract Typo/Grammar: "such a different client or an end user" should be "such as a different client or an end user" Introduction Typo/Grammar: In "Instead, the user authenticates directly with the photo sharing service and issue the printing service delegation-specific credentials", should be "issues" Authenticated Requests Typo/Grammar: In "Using these methods for delegation requires the client to pretend it was the resource owner.", "was" should be "is", or change the tense of the entire sentence to past. Typo/Grammar: In "The way in which clients discovery the required configuration is outside the scope of this specification.", "discovery" should be "discover". Nonce and Timestamp Comment: We still have a requirement for a monotonically increasing timestamp. What is the reason for this? There are two I can think of: 1. Backwards compatibility - I'm skeptical of the backwards compatibility argument in this case, as I thought it had been pretty well hashed out that this requirement is impossible to implement in large deployments (of either clients or servers). What library or client/server implementations actually include a check on this requirement? 2. Allow the server to discard nonces for previous timestamps - The server can now restrict the time period after which a request is rejected due to an old timestamp. I think this meets the need. If there is not a good reason for this requirement, then shouldn't we discard it. Signature Comment: I know there was previous discussion on the signature methods included in the spec and optional discovery/error-messaging for unsupported signature methods, but I don't think there was resolution. I'm wondering if it would be possible to drop signature methods. Does any existing provider require RSA-SHA1? (For example, Google provides the option and used to require it, but now allows HMAC-SHA1 as well.) Server Response Comment: "Ensure that the nonce / timestamp / token combination has not been used before, and MAY reject requests with stale timestamps." - It is probably impossible to ensure that a given nonce/timestamp/token combination has never been used before, so I don't think it makes sense to require that a server do this, as few servers will ever comply with the spec. I think "and MAY" should read "or MAY" in order to alleviate this requirement. Thanks, Ethan From eran@hueniverse.com Mon Sep 21 13:39:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA2D3A699F for ; Mon, 21 Sep 2009 13:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.55 X-Spam-Level: X-Spam-Status: No, score=-4.55 tagged_above=-999 required=5 tests=[AWL=-1.951, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IioQHQBFYOi6 for ; Mon, 21 Sep 2009 13:39:02 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 387F83A682D for ; Mon, 21 Sep 2009 13:39:02 -0700 (PDT) Received: (qmail 20606 invoked from network); 21 Sep 2009 20:40:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 21 Sep 2009 20:40:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 21 Sep 2009 13:37:47 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 21 Sep 2009 13:40:30 -0700 Thread-Topic: Request for feedback: OAuth IETF Drafts (Due 10/2) Thread-Index: Aco6+8J49gQ/lkwjS2GdWTAgSxxUjQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 20:39:03 -0000 http://tools.ietf.org/html/draft-ietf-oauth-authentication http://tools.ietf.org/html/draft-ietf-oauth-web-delegation I plan to publish new revisions of the above drafts to include: * Error codes and optional debug information * Cleanup of the authentication extensibility model * Change the version / protocol extensibility model In addition to general feedback about the drafts, I am looking for specific= feedback on the following items which I plan to address in the next drafts= : * Drop core support for the RSA-SHA1 method * Replace HMAC-SHA1 with HMAC-SHA256 * Define the authentication parameters as method-specific (for example, dro= p nonce and timestamp from PLAINTEXT) * The proposed Problem Reporting extension [1], its richness and complexity * Making the HMAC signature method required for all server implementations * Changing the delegation flow to require HTTP POST instead of recommending= it * Mandating server support for all three parameter transmission methods * Adding a token revocation endpoint * Adding the ability for servers to declare their configuration (methods, e= tc.) in the WWW-Authenticate header response * The value of the client credentials (Consumer Key) and feedback from actu= al implementation experience In order for your feedback to be included or considered for the next revisi= ons it must be received by 10/2 on the oauth@ietf.org list. EHL [1] http://wiki.oauth.net/ProblemReporting From eran@hueniverse.com Mon Sep 21 13:52:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1C423A6B10 for ; Mon, 21 Sep 2009 13:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.487 X-Spam-Level: X-Spam-Status: No, score=-4.487 tagged_above=-999 required=5 tests=[AWL=-1.888, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epuMqqOel2E0 for ; Mon, 21 Sep 2009 13:52:14 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 17A073A6989 for ; Mon, 21 Sep 2009 13:52:14 -0700 (PDT) Received: (qmail 30732 invoked from network); 21 Sep 2009 20:53:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Sep 2009 20:53:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 21 Sep 2009 13:53:15 -0700 From: Eran Hammer-Lahav To: Ethan Jewett , "oauth@ietf.org" Date: Mon, 21 Sep 2009 13:53:44 -0700 Thread-Topic: [OAUTH-WG] Comments on draft-ietf-oauth-authentication-01 Thread-Index: Aco5KzsZOkv4Ft24T+GsgHz2M0EWJQB0YmPw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58470@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <68f4a0e80909190615m757fae73qcf3a83b879b22baa@mail.gmail.com> In-Reply-To: <68f4a0e80909190615m757fae73qcf3a83b879b22baa@mail.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 Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-authentication-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 20:52:15 -0000 Thanks Ethan! > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Ethan Jewett > Sent: Saturday, September 19, 2009 6:15 AM > Abstract >=20 > Typo/Grammar: "such a different client or an end user" should be "such > as a different client or an end user" >=20 > Introduction >=20 > Typo/Grammar: In "Instead, the user authenticates directly with the > photo sharing service and issue the printing service > delegation-specific credentials", should be "issues" >=20 > Authenticated Requests >=20 > Typo/Grammar: In "Using these methods for delegation requires the > client to pretend it was the resource owner.", "was" should be "is", > or change the tense of the entire sentence to past. >=20 > Typo/Grammar: In "The way in which clients discovery the required > configuration is outside the scope of this specification.", > "discovery" should be "discover". Thanks. > Nonce and Timestamp >=20 > Comment: We still have a requirement for a monotonically increasing > timestamp. What is the reason for this? There are two I can think of: >=20 > 1. Backwards compatibility - I'm skeptical of the backwards > compatibility argument in this case, as I thought it had been pretty > well hashed out that this requirement is impossible to implement in > large deployments (of either clients or servers). What library or > client/server implementations actually include a check on this > requirement? >=20 > 2. Allow the server to discard nonces for previous timestamps - The > server can now restrict the time period after which a request is > rejected due to an old timestamp. I think this meets the need. >=20 > If there is not a good reason for this requirement, then shouldn't we > discard it. The entire section needs to be replaced with something better defined. This= is one of the sections most people struggle with and there is clear value = in replacing it with something that directly deals with timestamps, window = for delays, and clock syncing. > Signature >=20 > Comment: I know there was previous discussion on the signature methods > included in the spec and optional discovery/error-messaging for > unsupported signature methods, but I don't think there was resolution. > I'm wondering if it would be possible to drop signature methods. Does > any existing provider require RSA-SHA1? (For example, Google provides > the option and used to require it, but now allows HMAC-SHA1 as well.) Yes. I would like to see us drop the RSA method. In fact, I would like to d= rop all the methods and define new ones in order to allow the existing ones= to continue to work as is. =20 > Server Response >=20 > Comment: "Ensure that the nonce / timestamp / token combination has > not been used before, and MAY reject requests with stale timestamps." > - It is probably impossible to ensure that a given > nonce/timestamp/token combination has never been used before, so I > don't think it makes sense to require that a server do this, as few > servers will ever comply with the spec. I think "and MAY" should read > "or MAY" in order to alleviate this requirement. If we define the nonce requirements better, it should be even trivial to en= sure. EHL From eran@hueniverse.com Mon Sep 21 14:13:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E7628C0EA for ; Mon, 21 Sep 2009 14:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.428 X-Spam-Level: X-Spam-Status: No, score=-4.428 tagged_above=-999 required=5 tests=[AWL=-1.829, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o9GQZe95ffC for ; Mon, 21 Sep 2009 14:13:34 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E8FBB28C0CF for ; Mon, 21 Sep 2009 14:13:33 -0700 (PDT) Received: (qmail 22482 invoked from network); 21 Sep 2009 21:14:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Sep 2009 21:14:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 21 Sep 2009 14:12:20 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 21 Sep 2009 14:15:04 -0700 Thread-Topic: OAuth and HTTP caching Thread-Index: Aco7AJaujmQtYrT3QA6me3eD437feA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf-http-wg@w3.org Group" Subject: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:13:34 -0000 As currently written, OAuth use of the HTTP authentication headers is optio= nal at best. The reason for that was based on concerns that some platforms do not provid= e access to the HTTP header in either the request or the reply. However, th= is might have significant ramifications on caching and other parts of HTTP = where an indication of an authenticate interaction is needed. Before the OAuth WG spends any time on discussing the various methods of se= nding authentication parameters, I would like to find out if using the auth= entication headers is more of a requirement for such a protocol. EHL=20 From eran@hueniverse.com Mon Sep 21 14:24:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673813A68EE for ; Mon, 21 Sep 2009 14:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.409 X-Spam-Level: X-Spam-Status: No, score=-4.409 tagged_above=-999 required=5 tests=[AWL=-1.810, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DtSMqsD+sxj for ; Mon, 21 Sep 2009 14:23:59 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9309C3A6873 for ; Mon, 21 Sep 2009 14:23:59 -0700 (PDT) Received: (qmail 1425 invoked from network); 21 Sep 2009 21:25:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Sep 2009 21:25:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 21 Sep 2009 14:22:52 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 21 Sep 2009 14:25:29 -0700 Thread-Topic: Token expiration Thread-Index: Aco7Agrq7+KRP3QZSVi1Q6qx/yWvbg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Token expiration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:24:00 -0000 Should the core spec support the ability to indicate the duration of token = credentials? This would be an addition to the web delegation draft [1] in s= ection 6 (Token Credentials) in the form of a new response parameter, somet= hing like: oauth_token_duration The token duration specified in second from the time of the HTTP respon= se timestamp. This has been consistently at the top of missing core funcationality. EHL [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01 From stpeter@stpeter.im Mon Sep 21 14:24:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CF53A6999 for ; Mon, 21 Sep 2009 14:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.873 X-Spam-Level: X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSScW+dcn+cj for ; Mon, 21 Sep 2009 14:24:22 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4F9FC28C0E3 for ; Mon, 21 Sep 2009 14:24:22 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 45EA54007B; Mon, 21 Sep 2009 15:25:24 -0600 (MDT) Message-ID: <4AB7EF43.6010903@stpeter.im> Date: Mon, 21 Sep 2009 15:25:23 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:24:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/21/09 2:40 PM, Eran Hammer-Lahav wrote: > http://tools.ietf.org/html/draft-ietf-oauth-authentication > http://tools.ietf.org/html/draft-ietf-oauth-web-delegation > > I plan to publish new revisions of the above drafts to include: Great idea, and thanks for the push. To help move things forward, we might want to hold a real-time meeting in our WG chatroom: xmpp:oauth@jabber.ietf.org http://jabber.ietf.org/logs/oauth/ I think it would be productive to do that the week of October 5, after your October 2 deadline has passed, so that we can efficiently work through any remaining open issues. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq370MACgkQNL8k5A2w/vwGLwCcDUAvKui+gMcJD955bM0k06vj AdgAoIsI20q3W5uUlY9cnwJTlE7jYiaw =9uK2 -----END PGP SIGNATURE----- From hubertlvg@gmail.com Mon Sep 21 14:40:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52B83A68FB for ; Mon, 21 Sep 2009 14:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HK-ztNPMr22 for ; Mon, 21 Sep 2009 14:40:12 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id D25543A683F for ; Mon, 21 Sep 2009 14:40:09 -0700 (PDT) Received: by bwz6 with SMTP id 6so2244803bwz.37 for ; Mon, 21 Sep 2009 14:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7oyFhH79KrBt/GUTOzsqwMiZH+QjKD/IsDGoxYl94PQ=; b=ocHYybYoDHArANuQDyswk/CJdvxRQD+Mc0ke/DzM/NKpAYchcYzjosQLqmZKZDhcqg GrZZBj7b94cvcP8b67spnlRBXCyQW7dLupivPadxQFiT6tvRA/L/ZcYXpib92cMGq3Ji uionHxCH2rK+SdYNYDC8wrDv+p1fZyAJxeCog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=kxmGNUDgVPDaGb2aAoMlCbDjjub2Yfu4NLzHValuwwjuuNSV9PZlk9f0r1dDgcQ+fV I2go4EnictL7XHpvVQS2oSuv1VfU0m3mx5O9rkrUBrlzsftQuhNljfgYzD93hICFUmkg c514bl3knDeI2HiJPVhdEIR2Gu6ADACFgh2xo= MIME-Version: 1.0 Received: by 10.204.19.132 with SMTP id a4mr123740bkb.21.1253569268558; Mon, 21 Sep 2009 14:41:08 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 21 Sep 2009 23:41:08 +0200 Message-ID: <6c0fd2bc0909211441o3eacc564t2917cf5b94f99800@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Token expiration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:40:15 -0000 It is obviously useful to have. In fact it's so useful I'll bet most token format used do include one. Having it outside the token becomes redundant then but maybe it's not that bad. BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime)? Cheers, Hubert On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav w= rote: > Should the core spec support the ability to indicate the duration of toke= n credentials? This would be an addition to the web delegation draft [1] in= section 6 (Token Credentials) in the form of a new response parameter, som= ething like: > > oauth_token_duration > =A0 =A0The token duration specified in second from the time of the HTTP r= esponse timestamp. > > This has been consistently at the top of missing core funcationality. > > > EHL > > [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Mon Sep 21 14:43:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E7B3A68FB for ; Mon, 21 Sep 2009 14:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.357 X-Spam-Level: X-Spam-Status: No, score=-4.357 tagged_above=-999 required=5 tests=[AWL=-1.758, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+r7Wb-T38pG for ; Mon, 21 Sep 2009 14:43:31 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9871A3A68D0 for ; Mon, 21 Sep 2009 14:43:29 -0700 (PDT) Received: (qmail 22143 invoked from network); 21 Sep 2009 21:44:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Sep 2009 21:44:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 21 Sep 2009 14:42:16 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 21 Sep 2009 14:44:57 -0700 Thread-Topic: Support for additional methods for obtaining tokens Thread-Index: Aco7BMN2jvSjemkCQTuLHZix5fLXXA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D584AF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AD7k BLc+ BfNC EGBR EZfP EsPd FymM G7O1 HjFJ IH2f IK+H It/Y I0Kq JLFf JMo4 K6U0; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {4F1039D0-08BF-428F-8620-4ED61B4C27D3}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Mon, 21 Sep 2009 21:44:57 GMT; UwB1AHAAcABvAHIAdAAgAGYAbwByACAAYQBkAGQAaQB0AGkAbwBuAGEAbAAgAG0AZQB0AGgAbwBkAHMAIABmAG8AcgAgAG8AYgB0AGEAaQBuAGkAbgBnACAAdABvAGsAZQBuAHMA x-cr-puzzleid: {4F1039D0-08BF-428F-8620-4ED61B4C27D3} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Support for additional methods for obtaining tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:43:34 -0000 There is strong community consensus (not specifically WG consensus) that we= need more than one (browser-based) method for obtaining tokens. During the= chartering process people expressed the need to support mobile or other de= vices in which a browser is not readily available or a valid UI choice. My question is, should we publish a draft for each method or reposition the= web-delegation draft to a more general draft about methods for obtaining t= okens? This means we will have one spec for how to authenticate and another= spec for how to authorize. EHL From eran@hueniverse.com Mon Sep 21 14:45:35 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79F63A6879 for ; Mon, 21 Sep 2009 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.708 X-Spam-Level: X-Spam-Status: No, score=-3.708 tagged_above=-999 required=5 tests=[AWL=-2.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjiN7aK2jgKd for ; Mon, 21 Sep 2009 14:45:33 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7B0713A68D0 for ; Mon, 21 Sep 2009 14:45:33 -0700 (PDT) Received: (qmail 24313 invoked from network); 21 Sep 2009 21:46:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Sep 2009 21:46:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 21 Sep 2009 14:44:26 -0700 From: Eran Hammer-Lahav To: "Hallam-Baker, Phillip" , "oauth@ietf.org" Date: Mon, 21 Sep 2009 14:47:04 -0700 Thread-Topic: Algorithm choice (from the 'tother list) Thread-Index: AclT85WADWkukeBPRm2Sq0S0pagwaznEUk0A Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D584B0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <2788466ED3E31C418E9ACC5C316615572FFBC2@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C316615572FFBC2@mou1wnexmb09.vcorp.ad.vrsn.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_90C41DD21FB7C64BB94121FBBC2E72343784D584B0P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Algorithm choice (from the 'tother list) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:45:36 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343784D584B0P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there another standard we can use to chose the right crypto algorithm? I= would rather we avoid making our own decision about what qualifies as a su= fficient algorithm. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= allam-Baker, Phillip Sent: Monday, December 01, 2008 12:30 PM To: oauth@ietf.org Subject: [oauth] Algorithm choice (from the 'tother list) We should not specify SHA-1 as a required algorithm. This has nothing to do with the security arguments. It is just a matter of = it being one of those arguments that the security area has pretty much deci= ded not to have. The issue is not just the convenience or not of this parti= cular protocol deployment, it is the fact that the algorithm choice does ma= tter in some cases and arguing the difference is simply too much effort. In most cases HMAC-MD5 is perfectly adequate. DIGEST-MD5 is perfectly adequ= ate. But I would not specify them for a new standards proposal regardless o= f the cryptographic requirements. I regret not changing the MD5 requirement= to SHA. Not doing so has led to a huge amount of IETF bandwidth since as f= olk propose updating it even though the strength of the DIGEST construction= is much greater than the strength of SHA-1 (or come to that SHA-256). If we are only using MAC functions, CMAC-AES would be a better long term ch= oice than HMAC-SHA256 as we know that SHA256 is likely to change in future = while CMAC is a NIST approved standard. I seem to recall it will be slower,= but does that matter here? When HMAC was written we were confident about our hash functions and worrie= d about our encryption algorithms, in fact we had no encryption algorithm o= f choice at the time. Today that is not the case and CMAC offers the best p= ossible future proofing. I would like CFRG to periodically issue an RFC specifying a small set of pr= eferred crypto algorithms. This would allow folk to specify TLS+RFCxxxx cry= pto or IPSEC+RFCxxxx crypto as a requirement. It would allow us to update t= he mandatory crypto suites for every IETF protocol in one go (assuming the = protocol in question supported the new alg). It would also smooth the way f= or deployment of a coherent ECC based suite., just specify TLS+RFCxxxy or s= uch. If such a document were issued today the cipher suite recommendation would = clearly be: AES128/192/256, SHA2*, CMAC-AES, RSA2048 [or DSA2048 if compact signatur= es are required] The only questionable algorithm there is SHA2. I can well imagine in some i= nstances wanting to insist on SHA512 instead of SHA256 because you do get m= ore rounds with more key a well. The fact that SHA2 is a less preferred cho= ice means that HMAC-SHA2 is also less preferred. Not because we have any sp= ecific concern, but we have a choice and it is a liability. I think you could then make an argument for HMAC-SHA256 and Camilla being o= n a list of 'acceptable crypto' that may be supported but is not mandatory. --_000_90C41DD21FB7C64BB94121FBBC2E72343784D584B0P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Algorithm choice (from the 'tother list)

Is there another standard we can use to chose the right cryp= to algorithm? I would rather we avoid making our own decision about what quali= fies as a sufficient algorithm.

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Hallam-Baker, Phillip
Sent: Monday, December 01, 2008 12:30 PM
To: oauth@ietf.org
Subject: [oauth] Algorithm choice (from the 'tother list)=

 

We should not specify SHA-1 as a requir= ed algorithm.

This has nothing to do with the security arguments. It is just a matter of = it being one of those arguments that the security area has pretty much decided= not to have. The issue is not just the convenience or not of this particular protocol deployment, it is the fact that the algorithm choice does matter i= n some cases and arguing the difference is simply too much effort.

In most cases HMAC-MD5 is perfectly adequate. DIGEST-MD5 is perfectly adequ= ate. But I would not specify them for a new standards proposal regardless of the cryptographic requirements. I regret not changing the MD5 requirement to SH= A. Not doing so has led to a huge amount of IETF bandwidth since as folk propo= se updating it even though the strength of the DIGEST construction is much gre= ater than the strength of SHA-1 (or come to that SHA-256).


If we are only using MAC functions, CMAC-AES would be a better long term ch= oice than HMAC-SHA256 as we know that SHA256 is likely to change in future while CMAC is a NIST approved standard. I seem to recall it will be slower, but d= oes that matter here?

When HMAC was written we were confident about our hash functions and worrie= d about our encryption algorithms, in fact we had no encryption algorithm of choice at the time. Today that is not the case and CMAC offers the best possible future proofing.


I would like CFRG to periodically issue an RFC specifying a small set of preferred crypto algorithms. This would allow folk to specify TLS+RFCxxxx crypto or IPSEC+RFCxxxx crypto as a requirement. It would allow us to updat= e the mandatory crypto suites for every IETF protocol in one go (assuming the protocol in question supported the new alg). It would also smooth the way f= or deployment of a coherent ECC based suite., just specify TLS+RFCxxxy or such= .

If such a document were issued today the cipher suite recommendation would clearly be:
   AES128/192/256, SHA2*, CMAC-AES, RSA2048 [or DSA2048 if compac= t signatures are required]

The only questionable algorithm there is SHA2. I can well imagine in some instances wanting to insist on SHA512 instead of SHA256 because you do get = more rounds with more key a well. The fact that SHA2 is a less preferred choice means that HMAC-SHA2 is also less preferred. Not because we have any specif= ic concern, but we have a choice and it is a liability.

I think you could then make an argument for HMAC-SHA256 and Camilla being o= n a list of 'acceptable crypto' that may be supported but is not mandatory.

--_000_90C41DD21FB7C64BB94121FBBC2E72343784D584B0P3PW5EX1MB01E_-- From eran@hueniverse.com Mon Sep 21 14:49:18 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0B53A68FB for ; Mon, 21 Sep 2009 14:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.246 X-Spam-Level: X-Spam-Status: No, score=-4.246 tagged_above=-999 required=5 tests=[AWL=-1.647, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlljSa0bP-IY for ; Mon, 21 Sep 2009 14:49:17 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5465A3A680F for ; Mon, 21 Sep 2009 14:49:17 -0700 (PDT) Received: (qmail 28288 invoked from network); 21 Sep 2009 21:50:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Sep 2009 21:50:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 21 Sep 2009 14:50:18 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre Date: Mon, 21 Sep 2009 14:50:47 -0700 Thread-Topic: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) Thread-Index: Aco7Agkm04pTyWDDSZy61tD60+gBMQAAyNbw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D584B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AB7EF43.6010903@stpeter.im> In-Reply-To: <4AB7EF43.6010903@stpeter.im> 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] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:49:18 -0000 U291bmRzIGdvb2QuIENhbiB5b3UgcHJvcG9zZSBhIHRpbWU/DQoNCkVITA0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBldGVyIFNhaW50LUFuZHJlIFttYWlsdG86c3Rw ZXRlckBzdHBldGVyLmltXQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyMSwgMjAwOSAyOjI1 IFBNDQo+IFRvOiBFcmFuIEhhbW1lci1MYWhhdg0KPiBDYzogb2F1dGhAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gUmVxdWVzdCBmb3IgZmVlZGJhY2s6IE9BdXRoIElFVEYgRHJh ZnRzIChEdWUNCj4gMTAvMikNCj4gDQo+IC0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0t LS0NCj4gSGFzaDogU0hBMQ0KPiANCj4gPGhhdCB0eXBlPSJjaGFpciIvPg0KPiANCj4gT24gOS8y MS8wOSAyOjQwIFBNLCBFcmFuIEhhbW1lci1MYWhhdiB3cm90ZToNCj4gPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWF1dGhlbnRpY2F0aW9uDQo+ID4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC13ZWItZGVsZWdhdGlvbg0KPiA+ DQo+ID4gSSBwbGFuIHRvIHB1Ymxpc2ggbmV3IHJldmlzaW9ucyBvZiB0aGUgYWJvdmUgZHJhZnRz IHRvIGluY2x1ZGU6DQo+IA0KPiA8c25pcC8+DQo+IA0KPiBHcmVhdCBpZGVhLCBhbmQgdGhhbmtz IGZvciB0aGUgcHVzaC4NCj4gDQo+IFRvIGhlbHAgbW92ZSB0aGluZ3MgZm9yd2FyZCwgd2UgbWln aHQgd2FudCB0byBob2xkIGEgcmVhbC10aW1lIG1lZXRpbmcNCj4gaW4gb3VyIFdHIGNoYXRyb29t Og0KPiANCj4gICAgeG1wcDpvYXV0aEBqYWJiZXIuaWV0Zi5vcmcNCj4gDQo+ICAgIGh0dHA6Ly9q YWJiZXIuaWV0Zi5vcmcvbG9ncy9vYXV0aC8NCj4gDQo+IEkgdGhpbmsgaXQgd291bGQgYmUgcHJv ZHVjdGl2ZSB0byBkbyB0aGF0IHRoZSB3ZWVrIG9mIE9jdG9iZXIgNSwgYWZ0ZXINCj4geW91ciBP Y3RvYmVyIDIgZGVhZGxpbmUgaGFzIHBhc3NlZCwgc28gdGhhdCB3ZSBjYW4gZWZmaWNpZW50bHkg d29yaw0KPiB0aHJvdWdoIGFueSByZW1haW5pbmcgb3BlbiBpc3N1ZXMuDQo+IA0KPiBQZXRlcg0K PiANCj4gLSAtLQ0KPiBQZXRlciBTYWludC1BbmRyZQ0KPiBodHRwczovL3N0cGV0ZXIuaW0vDQo+ IA0KPiANCj4gLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCj4gVmVyc2lvbjogR251UEcg djEuNC44IChEYXJ3aW4pDQo+IENvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggTW96aWxsYSAtIGh0 dHA6Ly9lbmlnbWFpbC5tb3pkZXYub3JnLw0KPiANCj4gaUVZRUFSRUNBQVlGQWtxMzcwTUFDZ2tR Tkw4azVBMncvdndHTHdDY0RVQXZLdWkrZ01jSkQ5NTViTTBrMDZ2ag0KPiBBZGdBb0lzSTIwcTNX NXVVbFk5Y253SlRsRTdqWWlhdw0KPiA9OXVLMg0KPiAtLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS0NCg== From chiragshah1@gmail.com Mon Sep 21 14:49:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89023A69E7 for ; Mon, 21 Sep 2009 14:49:44 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb3tkw8rU59D for ; Mon, 21 Sep 2009 14:49:43 -0700 (PDT) Received: from mail-px0-f177.google.com (mail-px0-f177.google.com [209.85.216.177]) by core3.amsl.com (Postfix) with ESMTP id CE36A3A68FB for ; Mon, 21 Sep 2009 14:49:43 -0700 (PDT) Received: by pxi7 with SMTP id 7so306765pxi.17 for ; Mon, 21 Sep 2009 14:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZMfiJKqLpxuYDEYvvkYQumwa14jK1662JUC54uyBmt0=; b=Ys1GpgoNjJqVhb4Cm8Xc+pNoqXSwuBBqhS7trvMQgt4RWaRypP0AY50ZmsRkvDgrUb mcAp5bqNf57ZHcEs/OhtFlMZdz6QiC1YMybpJjDljJu4gcZm/WgfLh0j9A57a08piOI+ OHPhgcvGW1qkbKpwI+nJECnxjmMlLjKnbh8sA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bzGXi9W8sO2rEu5xJtkzC+wK/WmOCN7IqyTrrB/X+4h+iXPoHbuTFVyhVSYXMSZA0J sqV8nwT9AN1p897kfId8XXQc1DAwhNAVqoFrpPTte14vtf8YtUPNf3CeEBP1Mbyb2lfr A3ck/sDhUV/MqAseaKOrOh50uVqhRAixbRxQQ= MIME-Version: 1.0 Received: by 10.142.8.12 with SMTP id 12mr9291wfh.70.1253569843376; Mon, 21 Sep 2009 14:50:43 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 21 Sep 2009 14:50:43 -0700 Message-ID: <74462b20909211450kf19596eg2df35e13f4836c2d@mail.gmail.com> From: Chirag Shah To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:49:45 -0000 > * The proposed Problem Reporting extension [1], its richness and complexity I was curious if we could slightly update to the proposed problem reporting extension. The signature_invalid section in the Problem Reporting extension[1] should encourage service providers to include the signature_base_string they used in the error response. This information is valuable because the consumer can visually identify why their signature is invalid by comparing their signature_base string against the service provider's. If the service provider does not provide this information, the consumer is often guessing why their signature is invalid. [1] - http://wiki.oauth.net/ProblemReporting On Mon, Sep 21, 2009 at 1:40 PM, Eran Hammer-Lahav wrote: > http://tools.ietf.org/html/draft-ietf-oauth-authentication > http://tools.ietf.org/html/draft-ietf-oauth-web-delegation > > I plan to publish new revisions of the above drafts to include: > > * Error codes and optional debug information > * Cleanup of the authentication extensibility model > * Change the version / protocol extensibility model > > In addition to general feedback about the drafts, I am looking for specific feedback on the following items which I plan to address in the next drafts: > > * Drop core support for the RSA-SHA1 method > * Replace HMAC-SHA1 with HMAC-SHA256 > * Define the authentication parameters as method-specific (for example, drop nonce and timestamp from PLAINTEXT) > * The proposed Problem Reporting extension [1], its richness and complexity > * Making the HMAC signature method required for all server implementations > * Changing the delegation flow to require HTTP POST instead of recommending it > * Mandating server support for all three parameter transmission methods > * Adding a token revocation endpoint > * Adding the ability for servers to declare their configuration (methods, etc.) in the WWW-Authenticate header response > * The value of the client credentials (Consumer Key) and feedback from actual implementation experience > > In order for your feedback to be included or considered for the next revisions it must be received by 10/2 on the oauth@ietf.org list. > > EHL > > [1] http://wiki.oauth.net/ProblemReporting > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jpanzer@google.com Mon Sep 21 14:54:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A523A680F for ; Mon, 21 Sep 2009 14:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qQbFDVArsco for ; Mon, 21 Sep 2009 14:54:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 0E7963A6866 for ; Mon, 21 Sep 2009 14:54:11 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id n8LLtDdn009911 for ; Mon, 21 Sep 2009 14:55:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1253570114; bh=kL7/7cHK/ZTD6lxrWOJjX5ZRcQQ=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:X-System-Of-Record; b=Vnnm2g 4SNxxiX9wIzCcd3JZ09eLVi8tfFIbPBJioklKW02hj52bwNMbJy4ZPd+DpPiM5b8JHa fyH3wH7zSOl9A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=oBKEhpRVvOtM1i2jqUrnmny0/HnSMjEthAN/79IGMUpC25dPh9lX+HU83/nfMkP4l 9d9VUEg5nTJ06tQSjvNig== Received: from qw-out-2122.google.com (qwb9.prod.google.com [10.241.193.73]) by wpaz33.hot.corp.google.com with ESMTP id n8LLsqYT024723 for ; Mon, 21 Sep 2009 14:55:11 -0700 Received: by qw-out-2122.google.com with SMTP id 9so892089qwb.61 for ; Mon, 21 Sep 2009 14:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.54.149 with SMTP id q21mr26181qcg.60.1253570111230; Mon, 21 Sep 2009 14:55:11 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Mon, 21 Sep 2009 14:54:51 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00151773e4282e55a104741d8947 X-System-Of-Record: true Cc: "oauth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:54:14 -0000 --00151773e4282e55a104741d8947 Content-Type: text/plain; charset=ISO-8859-1 On the server side, one of the concerns in the past has been security in shared hosting systems where e.g., basic auth data should be handled by a secure container (Apache) and not passed on in raw form to hosted CGI scripts. So some of this comes back to what minimum level of hosting should be targeted by the specification -- and how much it should bend over backwards to deal with "challenged" environments. My $.02 is that we should follow the HTTP spec (Authorization: and WWW-Authenticate:) and take a minimum distance path to route around limited environments if necessary (X-Authorization: and X-WWW-Authenticate:, with exactly the same content, would be my proposal). -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav wrote: > As currently written, OAuth use of the HTTP authentication headers is > optional at best. > > The reason for that was based on concerns that some platforms do not > provide access to the HTTP header in either the request or the reply. > However, this might have significant ramifications on caching and other > parts of HTTP where an indication of an authenticate interaction is needed. > > Before the OAuth WG spends any time on discussing the various methods of > sending authentication parameters, I would like to find out if using the > authentication headers is more of a requirement for such a protocol. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00151773e4282e55a104741d8947 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On the server side, one of the concerns in the past has been security in sh= ared hosting systems where e.g., basic auth data should be handled by a sec= ure container (Apache) and not passed on in raw form to hosted CGI scripts.= =A0 So some of this comes back to what minimum level of hosting should be t= argeted by the specification -- and how much it should bend over backwards = to deal with "challenged" environments.

My $.02 is that we should follow the HTTP spec (Authorization: and WWW-= Authenticate:) and take a minimum distance path to route around limited env= ironments if necessary (X-Authorization: and X-WWW-Authenticate:, with exac= tly the same content, would be my proposal).

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org= / @jpanzer



On Mon, Sep 21, 2009 at 2:15 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
As currently written, OAuth use of the HTTP authentication headers is optio= nal at best.

The reason for that was based on concerns that some platforms do not provid= e access to the HTTP header in either the request or the reply. However, th= is might have significant ramifications on caching and other parts of HTTP = where an indication of an authenticate interaction is needed.

Before the OAuth WG spends any time on discussing the various methods of se= nding authentication parameters, I would like to find out if using the auth= entication headers is more of a requirement for such a protocol.

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

--00151773e4282e55a104741d8947-- From eran@hueniverse.com Mon Sep 21 14:55:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E723A67B1 for ; Mon, 21 Sep 2009 14:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[AWL=-1.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxdOyt4+Epog for ; Mon, 21 Sep 2009 14:55:57 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 821A23A6875 for ; Mon, 21 Sep 2009 14:55:57 -0700 (PDT) Received: (qmail 19565 invoked from network); 21 Sep 2009 21:56:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 21 Sep 2009 21:56:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 21 Sep 2009 14:56:57 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre Date: Mon, 21 Sep 2009 14:57:26 -0700 Thread-Topic: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) Thread-Index: Aco7Agkm04pTyWDDSZy61tD60+gBMQAAyNbwAABKJaA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D584B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AB7EF43.6010903@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343784D584B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D584B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:55:58 -0000 I misspoken. I am travelling 10/7-12. Not sure if the list is the best way to schedule such a meeting... :-) EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, September 21, 2009 2:51 PM > To: Peter Saint-Andre > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due > 10/2) >=20 > Sounds good. Can you propose a time? >=20 > EHL >=20 > > -----Original Message----- > > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > > Sent: Monday, September 21, 2009 2:25 PM > > To: Eran Hammer-Lahav > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due > > 10/2) > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > > > On 9/21/09 2:40 PM, Eran Hammer-Lahav wrote: > > > http://tools.ietf.org/html/draft-ietf-oauth-authentication > > > http://tools.ietf.org/html/draft-ietf-oauth-web-delegation > > > > > > I plan to publish new revisions of the above drafts to include: > > > > > > > > Great idea, and thanks for the push. > > > > To help move things forward, we might want to hold a real-time > meeting > > in our WG chatroom: > > > > xmpp:oauth@jabber.ietf.org > > > > http://jabber.ietf.org/logs/oauth/ > > > > I think it would be productive to do that the week of October 5, > after > > your October 2 deadline has passed, so that we can efficiently work > > through any remaining open issues. > > > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.8 (Darwin) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iEYEARECAAYFAkq370MACgkQNL8k5A2w/vwGLwCcDUAvKui+gMcJD955bM0k06vj > > AdgAoIsI20q3W5uUlY9cnwJTlE7jYiaw > > =3D9uK2 > > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Mon Sep 21 14:57:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FE233A6915 for ; Mon, 21 Sep 2009 14:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ6AIvl2uuVQ for ; Mon, 21 Sep 2009 14:57:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7E4B53A68F2 for ; Mon, 21 Sep 2009 14:57:48 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 96C5A4007B; Mon, 21 Sep 2009 15:58:50 -0600 (MDT) Message-ID: <4AB7F719.1020900@stpeter.im> Date: Mon, 21 Sep 2009 15:58:49 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AB7EF43.6010903@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343784D584B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D584B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:57:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How about Wednesday, October 7, at 17:00 UTC? That would be 10:00 on the U.S. West Coast, 13:00 on the U.S. East Coast, 18:00 in the UK, 19:00 in most of Western Europe, etc. On 9/21/09 3:50 PM, Eran Hammer-Lahav wrote: > Sounds good. Can you propose a time? > > EHL > >> -----Original Message----- >> From: Peter Saint-Andre [mailto:stpeter@stpeter.im] >> Sent: Monday, September 21, 2009 2:25 PM >> To: Eran Hammer-Lahav >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due >> 10/2) >> > > > On 9/21/09 2:40 PM, Eran Hammer-Lahav wrote: >>>> http://tools.ietf.org/html/draft-ietf-oauth-authentication >>>> http://tools.ietf.org/html/draft-ietf-oauth-web-delegation >>>> >>>> I plan to publish new revisions of the above drafts to include: > > > Great idea, and thanks for the push. > > To help move things forward, we might want to hold a real-time meeting > in our WG chatroom: > > xmpp:oauth@jabber.ietf.org > > http://jabber.ietf.org/logs/oauth/ > > I think it would be productive to do that the week of October 5, after > your October 2 deadline has passed, so that we can efficiently work > through any remaining open issues. > > Peter > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq39xkACgkQNL8k5A2w/vzqOACgxBIydjERves0ZEF+ubvP9HlP 8d0AoKQWgn6GtKOnjamLMrHyAsvmFBiv =5DLQ -----END PGP SIGNATURE----- From hubertlvg@gmail.com Mon Sep 21 14:58:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E2E3A6831 for ; Mon, 21 Sep 2009 14:58:15 -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.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4NJreFu5Jbn for ; Mon, 21 Sep 2009 14:58:14 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 5A3AD3A6B20 for ; Mon, 21 Sep 2009 14:58:14 -0700 (PDT) Received: by bwz6 with SMTP id 6so2253310bwz.37 for ; Mon, 21 Sep 2009 14:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=UkRK02IfKCQMHJGaRbkRtweiGyGL1xBgPbetJZ5iV4c=; b=gTJYjP22gKNs+hEyyL7ans9hCufMcjXA5NYikkPboQ9a5iLn6wGb1/lpU03uyIdu4c lEjHVacFJChF0o5STndd8s0vLp00ra3OEpVT4eCXG5IT+gsYTTSMcktOwxXdlVtg028P STCX6RB33CVKQ6NqjPvrsvpH+EmSqV4f5vmHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=SxWVyLTBsWltSbK0ez/HWP1paTv1T5hdivLNIwMVG9oFYrQph3XP1d00nE7Algyhco 1Xe4P7E6eKVKCgcgoP9pY+iFlthkb14oddSzMCJBfx6OouPpwEWkmyaVGIWiT5SjrSVC pk6jpeLxwbBaRXApoUxXngLMFfdN91ETQvmSQ= MIME-Version: 1.0 Received: by 10.204.161.197 with SMTP id s5mr137679bkx.8.1253570352839; Mon, 21 Sep 2009 14:59:12 -0700 (PDT) In-Reply-To: <74462b20909211450kf19596eg2df35e13f4836c2d@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <74462b20909211450kf19596eg2df35e13f4836c2d@mail.gmail.com> Date: Mon, 21 Sep 2009 23:59:12 +0200 Message-ID: <6c0fd2bc0909211459t647d0006s728b2630966cf603@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 21:58:15 -0000 I "hear your pain" but I'm not sure this is a good idea. What you describe sounds more like debugging to me. Not something I'd put in the protocol msgs. Hubert On Mon, Sep 21, 2009 at 11:50 PM, Chirag Shah wrote: >> * The proposed Problem Reporting extension [1], its richness and complexity > > I was curious if we could slightly update to the proposed problem > reporting extension. > > The signature_invalid section in the Problem Reporting extension[1] > should encourage service providers to include the > signature_base_string they used in the error response. > > This information is valuable because the consumer can visually > identify why their signature is invalid by comparing their > signature_base string against the service provider's. If the service > provider does not provide this information, the consumer is often > guessing why their signature is invalid. > > [1] - http://wiki.oauth.net/ProblemReporting > > On Mon, Sep 21, 2009 at 1:40 PM, Eran Hammer-Lahav wrote: >> http://tools.ietf.org/html/draft-ietf-oauth-authentication >> http://tools.ietf.org/html/draft-ietf-oauth-web-delegation >> >> I plan to publish new revisions of the above drafts to include: >> >> * Error codes and optional debug information >> * Cleanup of the authentication extensibility model >> * Change the version / protocol extensibility model >> >> In addition to general feedback about the drafts, I am looking for specific feedback on the following items which I plan to address in the next drafts: >> >> * Drop core support for the RSA-SHA1 method >> * Replace HMAC-SHA1 with HMAC-SHA256 >> * Define the authentication parameters as method-specific (for example, drop nonce and timestamp from PLAINTEXT) >> * The proposed Problem Reporting extension [1], its richness and complexity >> * Making the HMAC signature method required for all server implementations >> * Changing the delegation flow to require HTTP POST instead of recommending it >> * Mandating server support for all three parameter transmission methods >> * Adding a token revocation endpoint >> * Adding the ability for servers to declare their configuration (methods, etc.) in the WWW-Authenticate header response >> * The value of the client credentials (Consumer Key) and feedback from actual implementation experience >> >> In order for your feedback to be included or considered for the next revisions it must be received by 10/2 on the oauth@ietf.org list. >> >> EHL >> >> [1] http://wiki.oauth.net/ProblemReporting >> >> _______________________________________________ >> 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 stpeter@stpeter.im Mon Sep 21 15:00:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6533B3A6B28 for ; Mon, 21 Sep 2009 15:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJF+6YMANeRi for ; Mon, 21 Sep 2009 15:00:02 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AE67B3A68B8 for ; Mon, 21 Sep 2009 15:00:01 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D69F34007B; Mon, 21 Sep 2009 16:01:03 -0600 (MDT) Message-ID: <4AB7F79E.20906@stpeter.im> Date: Mon, 21 Sep 2009 16:01:02 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AB7EF43.6010903@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343784D584B2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D584B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D584B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:00:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Perhaps not, but I say we stipulate a time and just get it done. Whoever shows up, shows up. How about: Monday, October 5 @ 17:00 UTC? On 9/21/09 3:57 PM, Eran Hammer-Lahav wrote: > I misspoken. I am travelling 10/7-12. > > Not sure if the list is the best way to schedule such a meeting... :-) > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Eran Hammer-Lahav >> Sent: Monday, September 21, 2009 2:51 PM >> To: Peter Saint-Andre >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due >> 10/2) >> >> Sounds good. Can you propose a time? >> >> EHL >> >>> -----Original Message----- >>> From: Peter Saint-Andre [mailto:stpeter@stpeter.im] >>> Sent: Monday, September 21, 2009 2:25 PM >>> To: Eran Hammer-Lahav >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due >>> 10/2) >>> > > > On 9/21/09 2:40 PM, Eran Hammer-Lahav wrote: >>>>> http://tools.ietf.org/html/draft-ietf-oauth-authentication >>>>> http://tools.ietf.org/html/draft-ietf-oauth-web-delegation >>>>> >>>>> I plan to publish new revisions of the above drafts to include: > > > Great idea, and thanks for the push. > > To help move things forward, we might want to hold a real-time >>> meeting > in our WG chatroom: > > xmpp:oauth@jabber.ietf.org > > http://jabber.ietf.org/logs/oauth/ > > I think it would be productive to do that the week of October 5, >>> after > your October 2 deadline has passed, so that we can efficiently work > through any remaining open issues. > > Peter > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq3954ACgkQNL8k5A2w/vyhkACePkcT1YfmO/6DONsCeJpDihON xC4AoL9WYkG3Bc8e+5gGxGmbwgJG9nHc =38/r -----END PGP SIGNATURE----- From jpanzer@google.com Mon Sep 21 15:07:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B823A695F for ; Mon, 21 Sep 2009 15:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIfcge7lAtX9 for ; Mon, 21 Sep 2009 15:07:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 241283A68F1 for ; Mon, 21 Sep 2009 15:07:17 -0700 (PDT) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id n8LM8I6R023013 for ; Mon, 21 Sep 2009 23:08:18 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1253570899; bh=/xpcoVVL0KVdaJo7d0+xKPhgLuI=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:X-System-Of-Record; b=HjUfXE 18aa4xL5vyQSDlzgTKrqddA/2K76nVSSJYWcj4/2FBUuWMQhNzf2tukkg1ibkBAq3Vf K2ohD1t8L5w/A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=SmXpHznxb1Bhe804zn/QEieAgian5cvv9uQn2/DYZf+TuVoy4TcCaAkrGuQ5lHlXx ps+2yyJV81dOmMMUJy6Zw== Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by zps18.corp.google.com with ESMTP id n8LM8F9B029301 for ; Mon, 21 Sep 2009 15:08:15 -0700 Received: by qyk30 with SMTP id 30so307069qyk.7 for ; Mon, 21 Sep 2009 15:08:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.43.77 with SMTP id v13mr24251qce.82.1253570895117; Mon, 21 Sep 2009 15:08:15 -0700 (PDT) In-Reply-To: <74462b20909211450kf19596eg2df35e13f4836c2d@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <74462b20909211450kf19596eg2df35e13f4836c2d@mail.gmail.com> From: John Panzer Date: Mon, 21 Sep 2009 15:07:55 -0700 Message-ID: To: Chirag Shah Content-Type: multipart/alternative; boundary=001485354cc2e77de404741db786 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:07:19 -0000 --001485354cc2e77de404741db786 Content-Type: text/plain; charset=ISO-8859-1 I have one question about the Problem Reporting extension. The current text says: *user_refused*: The User (in most cases it's just user's IP) is temporarily unacceptable to the Service Provider. For example, the Service Provider may be rate limiting the IP based on number of requests. This error condition applies to the Authorization process where the user interacts with Service Provider directly. The Service Provider might return this error in the authorization response or in the Access Token request response. Q: Why is this (rate limiting) limited to the first two steps of the protocol, and not the Protected Resource request? I have many use cases where I also need to rate limit accesses, often based on the user or their IP, and user_refused is the only detail I coudl provide. But the PR extension seems to explicitly exclude this usage. Why? -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Sep 21, 2009 at 2:50 PM, Chirag Shah wrote: > > * The proposed Problem Reporting extension [1], its richness and > complexity > > I was curious if we could slightly update to the proposed problem > reporting extension. > > The signature_invalid section in the Problem Reporting extension[1] > should encourage service providers to include the > signature_base_string they used in the error response. > > This information is valuable because the consumer can visually > identify why their signature is invalid by comparing their > signature_base string against the service provider's. If the service > provider does not provide this information, the consumer is often > guessing why their signature is invalid. > > [1] - http://wiki.oauth.net/ProblemReporting > > On Mon, Sep 21, 2009 at 1:40 PM, Eran Hammer-Lahav > wrote: > > http://tools.ietf.org/html/draft-ietf-oauth-authentication > > http://tools.ietf.org/html/draft-ietf-oauth-web-delegation > > > > I plan to publish new revisions of the above drafts to include: > > > > * Error codes and optional debug information > > * Cleanup of the authentication extensibility model > > * Change the version / protocol extensibility model > > > > In addition to general feedback about the drafts, I am looking for > specific feedback on the following items which I plan to address in the next > drafts: > > > > * Drop core support for the RSA-SHA1 method > > * Replace HMAC-SHA1 with HMAC-SHA256 > > * Define the authentication parameters as method-specific (for example, > drop nonce and timestamp from PLAINTEXT) > > * The proposed Problem Reporting extension [1], its richness and > complexity > > * Making the HMAC signature method required for all server > implementations > > * Changing the delegation flow to require HTTP POST instead of > recommending it > > * Mandating server support for all three parameter transmission methods > > * Adding a token revocation endpoint > > * Adding the ability for servers to declare their configuration (methods, > etc.) in the WWW-Authenticate header response > > * The value of the client credentials (Consumer Key) and feedback from > actual implementation experience > > > > In order for your feedback to be included or considered for the next > revisions it must be received by 10/2 on the oauth@ietf.org list. > > > > EHL > > > > [1] http://wiki.oauth.net/ProblemReporting > > > > _______________________________________________ > > 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 > --001485354cc2e77de404741db786 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have one question about the Problem Reporting extension.=A0 The current t= ext says:

user_refused: The User (in most cases it's just= user's IP) is temporarily unacceptable to the Service Provider. For example, the Service Provider may be rate limiting the IP based on number of requests. This error condition applies to the Authorization process where the user interacts with Service Provider directly. The Service Provider might return this error in the authorization response or in the Access Token request response.

Q: Why is this (rate limiting) li= mited to the first two steps of the protocol, and not the Protected Resourc= e request?=A0 I have many use cases where I also need to rate limit accesse= s, often based on the user or their IP, and user_refused is the only detail= I coudl provide.=A0 But the PR extension seems to explicitly exclude this = usage.=A0 Why?=A0

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org= / @jpanzer



On Mon, Sep 21, 2009 at 2:50 PM, Chirag = Shah <chirags= hah1@gmail.com> wrote:
> * The proposed Problem Reporting extension [1], its = richness and complexity

I was curious if we could slightly update to the proposed problem
reporting extension.

The signature_invalid section in the Problem Reporting extension[1]
should encourage service providers to include the
signature_base_string they used in the error response.

This information is valuable because the consumer can visually
identify why their signature is invalid by comparing their
signature_base string against the service provider's. If the service provider does not provide this information, the consumer is often
guessing why their signature is invalid.

[1] - = http://wiki.oauth.net/ProblemReporting

On Mon, Sep 21, 2009 at 1:40 PM, Er= an Hammer-Lahav <eran@hueniverse.= com> wrote:
> http://tools.ietf.org/html/draft-ietf-oauth-authenticati= on
> http://tools.ietf.org/html/draft-ietf-oauth-web-delegati= on
>
> I plan to publish new revisions of the above drafts to include:
>
> * Error codes and optional debug information
> * Cleanup of the authentication extensibility model
> * Change the version / protocol extensibility model
>
> In addition to general feedback about the drafts, I am looking for spe= cific feedback on the following items which I plan to address in the next d= rafts:
>
> * Drop core support for the RSA-SHA1 method
> * Replace HMAC-SHA1 with HMAC-SHA256
> * Define the authentication parameters as method-specific (for example= , drop nonce and timestamp from PLAINTEXT)
> * The proposed Problem Reporting extension [1], its richness and compl= exity
> * Making the HMAC signature method required for all server implementat= ions
> * Changing the delegation flow to require HTTP POST instead of recomme= nding it
> * Mandating server support for all three parameter transmission method= s
> * Adding a token revocation endpoint
> * Adding the ability for servers to declare their configuration (metho= ds, etc.) in the WWW-Authenticate header response
> * The value of the client credentials (Consumer Key) and feedback from= actual implementation experience
>
> In order for your feedback to be included or considered for the next r= evisions it must be received by 10/2 on the oauth@ietf.org list.
>
> EHL
>
> [1] http://wiki.oauth.net/ProblemReporting
>
> _______________________________________________
> 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

--001485354cc2e77de404741db786-- From chris.messina@gmail.com Mon Sep 21 15:21:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244AD3A6866 for ; Mon, 21 Sep 2009 15:21:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YThnpd-FADry for ; Mon, 21 Sep 2009 15:21:14 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id D19E53A680A for ; Mon, 21 Sep 2009 15:21:13 -0700 (PDT) Received: by vws34 with SMTP id 34so2282042vws.32 for ; Mon, 21 Sep 2009 15:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OcsptvBkfJ+98MR+YBHpqDHNx+nr+wtCT9w+szM2DfY=; b=U+WCISvxkq9U0y99ZbryoD7hgi4VxxtpzpkLDUqGM+BL6NYj5XxEnKYxfBtFovEkCX jjdbwSOoDs5E6RX+G450y0JDyfKHSRXSLLK8Vt6QV+NDkZLI0C4TMryjeS1xGOvnZaJO kkctflkTB+bsEcx30ybX3z6evsmqnRHhmA7FM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=P7JqqKYc0TRcDSvTvnQz+0UTdZoQ9fNYW42jzRU4vbUES1fWjSKQ/UcoZsswsDPW8a XcTywnKMcoP0Wkn01cfRyYkTXEbfXwioNpG9yKwtF9uZCyFR3F5PLC3Rd6r87vs1Cii6 Fgcciq3ycWlwxOoIoFb8TUAGcJklnltWBwNrI= MIME-Version: 1.0 Received: by 10.220.88.23 with SMTP id y23mr289140vcl.94.1253571732903; Mon, 21 Sep 2009 15:22:12 -0700 (PDT) In-Reply-To: <6c0fd2bc0909211441o3eacc564t2917cf5b94f99800@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0909211441o3eacc564t2917cf5b94f99800@mail.gmail.com> Date: Mon, 21 Sep 2009 15:22:12 -0700 Message-ID: <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.gmail.com> From: Chris Messina To: Hubert Le Van Gong Content-Type: multipart/alternative; boundary=0016e64602a6d719e404741de953 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token expiration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:21:15 -0000 --0016e64602a6d719e404741de953 Content-Type: text/plain; charset=ISO-8859-1 Seems like it'd be worth documenting existing approaches to this... what do other similar APIs do? I know I harp on this approach to technology development, but that was how OAuth was developed (for better or worse): by looking at existing practices, extracting convention, and codifying ]ideally] best practices. If this is common and working elsewhere, can't we just imitate it? Chris On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong wrote: > It is obviously useful to have. In fact it's so useful I'll bet most > token format > used do include one. Having it outside the token becomes redundant then but > maybe it's not that bad. > > BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime)? > > Cheers, > Hubert > > > On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav > wrote: > > Should the core spec support the ability to indicate the duration of > token credentials? This would be an addition to the web delegation draft [1] > in section 6 (Token Credentials) in the form of a new response parameter, > something like: > > > > oauth_token_duration > > The token duration specified in second from the time of the HTTP > response timestamp. > > > > This has been consistently at the top of missing core funcationality. > > > > > > EHL > > > > [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01 > > > > _______________________________________________ > > 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 > -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --0016e64602a6d719e404741de953 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Seems like it'd be worth documenting existing approaches to this... wha= t do other similar APIs do?

I know I harp on this approa= ch to technology development, but that was how OAuth was developed (for bet= ter or worse): by looking at existing practices, extracting convention, and= codifying ]ideally] best practices.

If this is common and working elsewhere, can't we j= ust imitate it?

Chris

On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong <hubertlvg@gmail.com>= ; wrote:
It is obviously useful to have. In fact it&= #39;s so useful I'll bet most
token format
used do include one. Having it outside the token becomes redundant then but=
maybe it's not that bad.

BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime)?<= br>
Cheers,
Hubert


On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Should the core spec support the ability to indicate the duration of t= oken credentials? This would be an addition to the web delegation draft [1]= in section 6 (Token Credentials) in the form of a new response parameter, = something like:
>
> oauth_token_duration
> =A0 =A0The token duration specified in second from the time of the HTT= P response timestamp.
>
> This has been consistently at the top of missing core funcationality.<= br> >
>
> EHL
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-web-d= elegation-01
>
> _______________________________________________
> 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



--
Chris Messi= na
Open Web Advocate

Personal: = http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagen= cy.com
Diso Project: http://diso= -project.org
OpenID Foundation: http:/= /openid.net

This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private
--0016e64602a6d719e404741de953-- From hubertlvg@gmail.com Mon Sep 21 15:34:02 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F27F3A6B26 for ; Mon, 21 Sep 2009 15:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbWH-yl14JpW for ; Mon, 21 Sep 2009 15:34:01 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id A19EB3A6B2A for ; Mon, 21 Sep 2009 15:34:00 -0700 (PDT) Received: by bwz6 with SMTP id 6so2268943bwz.37 for ; Mon, 21 Sep 2009 15:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LpHrvw7+0RtLRifOwO/mJfCaEp3kfHXoy6ajueaLOX4=; b=ZXb0ytDeVeGezy3b3Gpxz885f3gI7ui+kwyRKgpqy8o0OH+jaUd8OJufZ7rdbSBuK7 bP66r3ecuQTtMRew421Yb8qmEo77oc50e5pVlyN/SUmlfgwDbR2n7ZtsqQxfLC6Qg3Rh pm7hJrl/L2X8RahUwMFgby3H8juWJXjFYbZfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s4KkG3s2M+8G12T/lGHMYW4Gz2VEoLnpr2ZT8On0nw5tB5e+w5YLVlZL0o3RK8VLHX VffG9k6oKBWNhjF3Jjx8JmG9AhtcZesHiovBUdemsjiZNQSUesKVE9r/O330P4ZXwI5N qTnaaFSN1/GWHPnZ4MmfIUYKzcXG0/Zz4yo8g= MIME-Version: 1.0 Received: by 10.204.34.83 with SMTP id k19mr158104bkd.96.1253572496943; Mon, 21 Sep 2009 15:34:56 -0700 (PDT) In-Reply-To: <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0909211441o3eacc564t2917cf5b94f99800@mail.gmail.com> <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.gmail.com> Date: Tue, 22 Sep 2009 00:34:56 +0200 Message-ID: <6c0fd2bc0909211534s1f2b79c6m7577dee31accf9c7@mail.gmail.com> From: Hubert Le Van Gong To: Chris Messina Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token expiration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:34:02 -0000 An interesting example (to me at least since we use it) is the SAML token. You have the ability to define three dates: - IssueInstant: the time of issue of the token [required] - NotBefore: time before which the token's invalid [optional] - NotOnOrAfter: time after which the token becomes invalid [optional] All are dateTime (in UTC form). Thanks, Hubert On Tue, Sep 22, 2009 at 12:22 AM, Chris Messina w= rote: > Seems like it'd be worth documenting existing approaches to this... what = do > other similar APIs do? > I know I harp on this approach to technology development, but that was ho= w > OAuth was developed (for better or worse): by looking at existing practic= es, > extracting convention, and codifying ]ideally] best practices. > If this is common and working elsewhere, can't we just imitate it? > Chris > > On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong > wrote: >> >> It is obviously useful to have. In fact it's so useful I'll bet most >> token format >> used do include one. Having it outside the token becomes redundant then >> but >> maybe it's not that bad. >> >> BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime)? >> >> Cheers, >> Hubert >> >> >> On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav >> wrote: >> > Should the core spec support the ability to indicate the duration of >> > token credentials? This would be an addition to the web delegation dra= ft [1] >> > in section 6 (Token Credentials) in the form of a new response paramet= er, >> > something like: >> > >> > oauth_token_duration >> > =A0 =A0The token duration specified in second from the time of the HTT= P >> > response timestamp. >> > >> > This has been consistently at the top of missing core funcationality. >> > >> > >> > EHL >> > >> > [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01 >> > >> > _______________________________________________ >> > 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 > > > > -- > Chris Messina > Open Web Advocate > > Personal: http://factoryjoe.com > Follow me on Twitter: http://twitter.com/chrismessina > > Citizen Agency: http://citizenagency.com > Diso Project: http://diso-project.org > OpenID Foundation: http://openid.net > > This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private > From sergent@google.com Mon Sep 21 15:46:54 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11F33A6AD7 for ; Mon, 21 Sep 2009 15:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APQI0v9jW0+w for ; Mon, 21 Sep 2009 15:46:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 793373A6982 for ; Mon, 21 Sep 2009 15:46:53 -0700 (PDT) Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id n8LMlrRZ018019 for ; Mon, 21 Sep 2009 23:47:53 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1253573273; bh=ydMozvcoIGCOZXj3l7Crp9zPnoI=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=KhwAannO/lO6h/44Bh /ZaeBn3MYM6ogS8TVM/rqvT6T2TKHWyNgC5KqrykUtXb9Pz6u136V+1UrEupS5x0wW5 w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=g1iTO2IpZ85J9yAMKSl5dK94fO+kUzgaCEI7t3hMy9JYi+xptzu3yRgINqBAy+l39 +fPiW4YUo25j40vTVIONQ== Received: from pxi33 (pxi33.prod.google.com [10.243.27.33]) by spaceape10.eur.corp.google.com with ESMTP id n8LMk5WU017795 for ; Mon, 21 Sep 2009 15:47:51 -0700 Received: by pxi33 with SMTP id 33so2740414pxi.28 for ; Mon, 21 Sep 2009 15:47:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.25.36 with SMTP id c36mr14448wfj.1.1253573270869; Mon, 21 Sep 2009 15:47:50 -0700 (PDT) In-Reply-To: <6c0fd2bc0909211534s1f2b79c6m7577dee31accf9c7@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0909211441o3eacc564t2917cf5b94f99800@mail.gmail.com> <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.gmail.com> <6c0fd2bc0909211534s1f2b79c6m7577dee31accf9c7@mail.gmail.com> Date: Mon, 21 Sep 2009 15:47:50 -0700 Message-ID: From: Jonathan Sergent To: Hubert Le Van Gong 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] Token expiration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:46:54 -0000 IMO, it's problematic that this relies on clock synchronization between the sender and the receiver to work. This is a constant source of problems in need of debugging for us today. Why not specify times like this using intervals? "This token is valid for the next n seconds." On Mon, Sep 21, 2009 at 3:34 PM, Hubert Le Van Gong w= rote: > An interesting example (to me at least since we use it) is the SAML token= . > You have the ability to define three dates: > - IssueInstant: the time of issue of the token [required] > - NotBefore: time before which the token's invalid [optional] > - NotOnOrAfter: time after which the token becomes invalid [optional] > > All are dateTime (in UTC form). > > Thanks, > Hubert > > > On Tue, Sep 22, 2009 at 12:22 AM, Chris Messina = wrote: >> Seems like it'd be worth documenting existing approaches to this... what= do >> other similar APIs do? >> I know I harp on this approach to technology development, but that was h= ow >> OAuth was developed (for better or worse): by looking at existing practi= ces, >> extracting convention, and codifying ]ideally] best practices. >> If this is common and working elsewhere, can't we just imitate it? >> Chris >> >> On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong >> wrote: >>> >>> It is obviously useful to have. In fact it's so useful I'll bet most >>> token format >>> used do include one. Having it outside the token becomes redundant then >>> but >>> maybe it's not that bad. >>> >>> BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime)= ? >>> >>> Cheers, >>> Hubert >>> >>> >>> On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav >>> wrote: >>> > Should the core spec support the ability to indicate the duration of >>> > token credentials? This would be an addition to the web delegation dr= aft [1] >>> > in section 6 (Token Credentials) in the form of a new response parame= ter, >>> > something like: >>> > >>> > oauth_token_duration >>> > =A0 =A0The token duration specified in second from the time of the HT= TP >>> > response timestamp. >>> > >>> > This has been consistently at the top of missing core funcationality. >>> > >>> > >>> > EHL >>> > >>> > [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01 >>> > >>> > _______________________________________________ >>> > 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 >> >> >> >> -- >> Chris Messina >> Open Web Advocate >> >> Personal: http://factoryjoe.com >> Follow me on Twitter: http://twitter.com/chrismessina >> >> Citizen Agency: http://citizenagency.com >> Diso Project: http://diso-project.org >> OpenID Foundation: http://openid.net >> >> This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From marcel@twitter.com Mon Sep 21 15:54:24 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9C0128C1E1 for ; Mon, 21 Sep 2009 15:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yauOEwAu04Ab for ; Mon, 21 Sep 2009 15:54:23 -0700 (PDT) Received: from mail-pz0-f180.google.com (mail-pz0-f180.google.com [209.85.222.180]) by core3.amsl.com (Postfix) with ESMTP id 937183A6403 for ; Mon, 21 Sep 2009 15:53:44 -0700 (PDT) Received: by pzk10 with SMTP id 10so2567650pzk.19 for ; Mon, 21 Sep 2009 15:54:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.5.39 with SMTP id 39mr12966wfe.81.1253573684616; Mon, 21 Sep 2009 15:54:44 -0700 (PDT) In-Reply-To: <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0909211441o3eacc564t2917cf5b94f99800@mail.gmail.com> <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.gmail.com> Date: Mon, 21 Sep 2009 15:54:44 -0700 Message-ID: From: Marcel Molina To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Token expiration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:56:30 -0000 As an example of what other APIs do, Amazon's S3 supports signed urls of protected objects. The signed url is given a time to live after which it's invalidated. It's specified in terms of number of seconds from the time the url was generated. That's dependent on the clock of the origin server I assume. Unless there is considerable drift between clocks and a very short time to live on the token, this shouldn't be a problem 99%+ of the time I'd assume... On Mon, Sep 21, 2009 at 3:22 PM, Chris Messina wr= ote: > Seems like it'd be worth documenting existing approaches to this... what = do > other similar APIs do? > I know I harp on this approach to technology development, but that was ho= w > OAuth was developed (for better or worse): by looking at existing practic= es, > extracting convention, and codifying ]ideally] best practices. > If this is common and working elsewhere, can't we just imitate it? > Chris > > On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong > wrote: >> >> It is obviously useful to have. In fact it's so useful I'll bet most >> token format >> used do include one. Having it outside the token becomes redundant then >> but >> maybe it's not that bad. >> >> BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime)? >> >> Cheers, >> Hubert >> >> >> On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav >> wrote: >> > Should the core spec support the ability to indicate the duration of >> > token credentials? This would be an addition to the web delegation dra= ft [1] >> > in section 6 (Token Credentials) in the form of a new response paramet= er, >> > something like: >> > >> > oauth_token_duration >> > =A0 =A0The token duration specified in second from the time of the HTT= P >> > response timestamp. >> > >> > This has been consistently at the top of missing core funcationality. >> > >> > >> > EHL >> > >> > [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01 >> > >> > _______________________________________________ >> > 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 > > > > -- > Chris Messina > Open Web Advocate > > Personal: http://factoryjoe.com > Follow me on Twitter: http://twitter.com/chrismessina > > Citizen Agency: http://citizenagency.com > Diso Project: http://diso-project.org > OpenID Foundation: http://openid.net > > This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Marcel Molina Twitter Platform Team http://twitter.com/noradio From hubertlvg@gmail.com Mon Sep 21 16:00:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25273A689A for ; Mon, 21 Sep 2009 16:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94PhRyOtpW2O for ; Mon, 21 Sep 2009 16:00:00 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 36CA63A67F7 for ; Mon, 21 Sep 2009 16:00:00 -0700 (PDT) Received: by bwz6 with SMTP id 6so2278958bwz.37 for ; Mon, 21 Sep 2009 16:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=phQeQ8o7a2V9mMLVM2SiODNAIZi9p3IaMb2pwlqGCBU=; b=kkLvtms1Dh5QXmW8YnqBGPQe7v/ZELGK2++J4CfQqXf39GkeNv+AGZFvGvOWXMieHu rqOUbwdA+1BErkRxrOgk8jCco+E64M92eyJnyf6WkJ7gjNu9c5qXs+7dmm1CC5Xp6AA6 x+4O3ozYzumWkQUFyGHbOpMTxCAnfvplcdoMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=rarXgmGeJFem+0yzmgPsEgnzWIJMB/ROguX+JKDCCuJb8Bs76sFIVIXEBAKpZMOgD1 GtrymZDRd62yGBAkpF4SBEso20mqgqWBePBIC5ZhFUjZMcox9qb0acu8nxYE92WAopVI hBPuM1SeHXEhA+cQByURw3bsMgrnKBrzbPMMc= MIME-Version: 1.0 Received: by 10.204.157.24 with SMTP id z24mr132209bkw.208.1253574058086; Mon, 21 Sep 2009 16:00:58 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0909211441o3eacc564t2917cf5b94f99800@mail.gmail.com> <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.gmail.com> <6c0fd2bc0909211534s1f2b79c6m7577dee31accf9c7@mail.gmail.com> Date: Tue, 22 Sep 2009 01:00:58 +0200 Message-ID: <6c0fd2bc0909211600n541ef6d8g402c8596062e14f8@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Token expiration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 23:00:01 -0000 In theory I'd agree with you but... (1) there are ways of achieving reasonable clock sync nowadays (2) usually the validity period is long enough that the clocks are considered roughly in sync. (3) the n seconds means I can keep the token for a very long period of time and present it? Unless you meant seconds starting from the sender's clock, in which case we're back to the same issue. If the token is for a sensitive resource, one can still impose a one time u= se... My 2 cents, Hubert On Tue, Sep 22, 2009 at 12:47 AM, Jonathan Sergent wro= te: > IMO, it's problematic that this relies on clock synchronization > between the sender and the receiver to work. =A0This is a constant > source of problems in need of debugging for us today. =A0Why not specify > times like this using intervals? =A0"This token is valid for the next n > seconds." > > On Mon, Sep 21, 2009 at 3:34 PM, Hubert Le Van Gong = wrote: >> An interesting example (to me at least since we use it) is the SAML toke= n. >> You have the ability to define three dates: >> - IssueInstant: the time of issue of the token [required] >> - NotBefore: time before which the token's invalid [optional] >> - NotOnOrAfter: time after which the token becomes invalid [optional] >> >> All are dateTime (in UTC form). >> >> Thanks, >> Hubert >> >> >> On Tue, Sep 22, 2009 at 12:22 AM, Chris Messina wrote: >>> Seems like it'd be worth documenting existing approaches to this... wha= t do >>> other similar APIs do? >>> I know I harp on this approach to technology development, but that was = how >>> OAuth was developed (for better or worse): by looking at existing pract= ices, >>> extracting convention, and codifying ]ideally] best practices. >>> If this is common and working elsewhere, can't we just imitate it? >>> Chris >>> >>> On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong >>> wrote: >>>> >>>> It is obviously useful to have. In fact it's so useful I'll bet most >>>> token format >>>> used do include one. Having it outside the token becomes redundant the= n >>>> but >>>> maybe it's not that bad. >>>> >>>> BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime= )? >>>> >>>> Cheers, >>>> Hubert >>>> >>>> >>>> On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav >>>> wrote: >>>> > Should the core spec support the ability to indicate the duration of >>>> > token credentials? This would be an addition to the web delegation d= raft [1] >>>> > in section 6 (Token Credentials) in the form of a new response param= eter, >>>> > something like: >>>> > >>>> > oauth_token_duration >>>> > =A0 =A0The token duration specified in second from the time of the H= TTP >>>> > response timestamp. >>>> > >>>> > This has been consistently at the top of missing core funcationality= . >>>> > >>>> > >>>> > EHL >>>> > >>>> > [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01 >>>> > >>>> > _______________________________________________ >>>> > 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 >>> >>> >>> >>> -- >>> Chris Messina >>> Open Web Advocate >>> >>> Personal: http://factoryjoe.com >>> Follow me on Twitter: http://twitter.com/chrismessina >>> >>> Citizen Agency: http://citizenagency.com >>> Diso Project: http://diso-project.org >>> OpenID Foundation: http://openid.net >>> >>> This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From eran@hueniverse.com Mon Sep 21 16:17:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED51F3A67F0 for ; Mon, 21 Sep 2009 16:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.161 X-Spam-Level: X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[AWL=-1.563, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StmNVx9qQu2o for ; Mon, 21 Sep 2009 16:17:22 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8DDA93A67D6 for ; Mon, 21 Sep 2009 16:17:22 -0700 (PDT) Received: (qmail 18769 invoked from network); 21 Sep 2009 23:18:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Sep 2009 23:18:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 21 Sep 2009 16:18:23 -0700 From: Eran Hammer-Lahav To: Chris Messina , Hubert Le Van Gong Date: Mon, 21 Sep 2009 16:17:51 -0700 Thread-Topic: [OAUTH-WG] Token expiration Thread-Index: Aco7CfvaYrz575KkRp2bIIT+WUSeDAAB6GsA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D584D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0909211441o3eacc564t2917cf5b94f99800@mail.gmail.com> <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.gmail.com> In-Reply-To: <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.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_90C41DD21FB7C64BB94121FBBC2E72343784D584D3P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Token expiration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 23:17:28 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343784D584D3P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yahoo uses 'oauth_expires_in' as specified in the session extension [1] (wh= ich we plan to submit as an I-D shortly). EHL [1] http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C= hris Messina Sent: Monday, September 21, 2009 3:22 PM To: Hubert Le Van Gong Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token expiration Seems like it'd be worth documenting existing approaches to this... what do= other similar APIs do? I know I harp on this approach to technology development, but that was how = OAuth was developed (for better or worse): by looking at existing practices= , extracting convention, and codifying ]ideally] best practices. If this is common and working elsewhere, can't we just imitate it? Chris On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong > wrote: It is obviously useful to have. In fact it's so useful I'll bet most token format used do include one. Having it outside the token becomes redundant then but maybe it's not that bad. BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime)? Cheers, Hubert On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav > wrote: > Should the core spec support the ability to indicate the duration of toke= n credentials? This would be an addition to the web delegation draft [1] in= section 6 (Token Credentials) in the form of a new response parameter, som= ething like: > > oauth_token_duration > The token duration specified in second from the time of the HTTP respo= nse timestamp. > > This has been consistently at the top of missing core funcationality. > > > EHL > > [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01 > > _______________________________________________ > 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 -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --_000_90C41DD21FB7C64BB94121FBBC2E72343784D584D3P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yahoo uses ‘oauth_expires_in’ as specified in th= e session extension [1] (which we plan to submit as an I-D shortly).

 

EHL

 

[1] http://oauth.googlecode.com/svn/spec/ext/session/1.0/dra= fts/1/spec.html

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Chris Messina
Sent: Monday, September 21, 2009 3:22 PM
To: Hubert Le Van Gong
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Token expiration

 

Seems like it'd be worth documenting existing approach= es to this... what do other similar APIs do?

 

I know I harp on this approach to technology developme= nt, but that was how OAuth was developed (for better or worse): by looking at existing practices, extracting convention, and codifying ]ideally] best practices.

 

If this is common and working elsewhere, can't we just imitate it?

 

Chris

 

On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong &l= t;hubertlvg@gmail.com> wrote:=

It is obviously useful to have. In fact it's so useful= I'll bet most
token format
used do include one. Having it outside the token becomes redundant then but=
maybe it's not that bad.

BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime)?

Cheers,
Hubert



On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Should the core spec support the ability to indicate the duration of t= oken credentials? This would be an addition to the web delegation draft [1] in section 6 (Token Credentials) in the form of a new response parameter, something like:
>
> oauth_token_duration
>    The token duration specified in second from the time of t= he HTTP response timestamp.
>
> This has been consistently at the top of missing core funcationality.<= br> >
>
> EHL
>
> [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegatio= n-01
>
> _______________________________________________
> 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




--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://tw= itter.com/chrismessina

Citizen Agency: http://citizenagency.c= om
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private

--_000_90C41DD21FB7C64BB94121FBBC2E72343784D584D3P3PW5EX1MB01E_-- From sergent@google.com Mon Sep 21 16:22:41 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC48F3A67AC for ; Mon, 21 Sep 2009 16:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWNmuMSDBnuL for ; Mon, 21 Sep 2009 16:22:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id A53573A6ADE for ; Mon, 21 Sep 2009 16:22:40 -0700 (PDT) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id n8LNNgoS005848 for ; Mon, 21 Sep 2009 16:23:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1253575423; bh=7zKu0q4vIKc+kINcK8EvolMjIWo=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=E4Tg9AU0rH8gLjIKoS 4Qxrsp+cAwm4TlZFF6WVg39uy2ijdNRXIJboOEKc7YMNpbOGQPxOTjmoVdeLGIPxzib g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=OBk6dV0yFmk5DDkZSXC127wHhuUI/5DiFLVM7PVgDQ7Z7l87nzTGJgeawt4MVtz1h GRPkAkBx4VR5fNtse4YBw== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by spaceape11.eur.corp.google.com with ESMTP id n8LNN3cs006456 for ; Mon, 21 Sep 2009 16:23:39 -0700 Received: by pzk28 with SMTP id 28so2957191pzk.5 for ; Mon, 21 Sep 2009 16:23:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.154.17 with SMTP id g17mr15484wfo.247.1253575418740; Mon, 21 Sep 2009 16:23:38 -0700 (PDT) In-Reply-To: <6c0fd2bc0909211600n541ef6d8g402c8596062e14f8@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0909211441o3eacc564t2917cf5b94f99800@mail.gmail.com> <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.gmail.com> <6c0fd2bc0909211534s1f2b79c6m7577dee31accf9c7@mail.gmail.com> <6c0fd2bc0909211600n541ef6d8g402c8596062e14f8@mail.gmail.com> Date: Mon, 21 Sep 2009 16:23:38 -0700 Message-ID: From: Jonathan Sergent To: Hubert Le Van Gong 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] Token expiration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 23:22:41 -0000 I meant n seconds from when the response was sent by the server. On Mon, Sep 21, 2009 at 4:00 PM, Hubert Le Van Gong w= rote: > In theory I'd agree with you but... > (1) there are ways of achieving reasonable clock sync nowadays > (2) usually the validity period is long enough that the clocks are > =A0 =A0 considered roughly in sync. > (3) the n seconds means I can keep the token for a very long period > =A0 =A0of time and present it? Unless you meant seconds starting from > =A0 =A0the sender's clock, in which case we're back to the same issue. > > If the token is for a sensitive resource, one can still impose a one time= use... > > My 2 cents, > Hubert > > > On Tue, Sep 22, 2009 at 12:47 AM, Jonathan Sergent w= rote: >> IMO, it's problematic that this relies on clock synchronization >> between the sender and the receiver to work. =A0This is a constant >> source of problems in need of debugging for us today. =A0Why not specify >> times like this using intervals? =A0"This token is valid for the next n >> seconds." >> >> On Mon, Sep 21, 2009 at 3:34 PM, Hubert Le Van Gong wrote: >>> An interesting example (to me at least since we use it) is the SAML tok= en. >>> You have the ability to define three dates: >>> - IssueInstant: the time of issue of the token [required] >>> - NotBefore: time before which the token's invalid [optional] >>> - NotOnOrAfter: time after which the token becomes invalid [optional] >>> >>> All are dateTime (in UTC form). >>> >>> Thanks, >>> Hubert >>> >>> >>> On Tue, Sep 22, 2009 at 12:22 AM, Chris Messina wrote: >>>> Seems like it'd be worth documenting existing approaches to this... wh= at do >>>> other similar APIs do? >>>> I know I harp on this approach to technology development, but that was= how >>>> OAuth was developed (for better or worse): by looking at existing prac= tices, >>>> extracting convention, and codifying ]ideally] best practices. >>>> If this is common and working elsewhere, can't we just imitate it? >>>> Chris >>>> >>>> On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong >>>> wrote: >>>>> >>>>> It is obviously useful to have. In fact it's so useful I'll bet most >>>>> token format >>>>> used do include one. Having it outside the token becomes redundant th= en >>>>> but >>>>> maybe it's not that bad. >>>>> >>>>> BTW why not using dateTime (http://www.w3.org/TR/xmlschema-2/#dateTim= e)? >>>>> >>>>> Cheers, >>>>> Hubert >>>>> >>>>> >>>>> On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav >>>>> wrote: >>>>> > Should the core spec support the ability to indicate the duration o= f >>>>> > token credentials? This would be an addition to the web delegation = draft [1] >>>>> > in section 6 (Token Credentials) in the form of a new response para= meter, >>>>> > something like: >>>>> > >>>>> > oauth_token_duration >>>>> > =A0 =A0The token duration specified in second from the time of the = HTTP >>>>> > response timestamp. >>>>> > >>>>> > This has been consistently at the top of missing core funcationalit= y. >>>>> > >>>>> > >>>>> > EHL >>>>> > >>>>> > [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01 >>>>> > >>>>> > _______________________________________________ >>>>> > 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 >>>> >>>> >>>> >>>> -- >>>> Chris Messina >>>> Open Web Advocate >>>> >>>> Personal: http://factoryjoe.com >>>> Follow me on Twitter: http://twitter.com/chrismessina >>>> >>>> Citizen Agency: http://citizenagency.com >>>> Diso Project: http://diso-project.org >>>> OpenID Foundation: http://openid.net >>>> >>>> This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private >>>> >>> _______________________________________________ >>> 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 Mon Sep 21 16:30:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5C43A6919 for ; Mon, 21 Sep 2009 16:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.122 X-Spam-Level: X-Spam-Status: No, score=-4.122 tagged_above=-999 required=5 tests=[AWL=-1.523, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no8sxMVdVzDJ for ; Mon, 21 Sep 2009 16:30:41 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C42CA3A67B8 for ; Mon, 21 Sep 2009 16:30:41 -0700 (PDT) Received: (qmail 13783 invoked from network); 21 Sep 2009 23:31:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 21 Sep 2009 23:31:43 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 21 Sep 2009 16:31:42 -0700 From: Eran Hammer-Lahav To: Hubert Le Van Gong , "oauth@ietf.org" Date: Mon, 21 Sep 2009 16:31:10 -0700 Thread-Topic: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) Thread-Index: Aco7BsYlJ5JyPIyXRoS+vNatfrCBiQADJqRA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D584DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <74462b20909211450kf19596eg2df35e13f4836c2d@mail.gmail.com> <6c0fd2bc0909211459t647d0006s728b2630966cf603@mail.gmail.com> In-Reply-To: <6c0fd2bc0909211459t647d0006s728b2630966cf603@mail.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 Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 23:30:43 -0000 Is there any past experience with protocols adding explicit debugging suppo= rt? If we make it optional, it would be very useful. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hubert Le Van Gong > Sent: Monday, September 21, 2009 2:59 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due > 10/2) >=20 > I "hear your pain" but I'm not sure this is a good idea. > What you describe sounds more like debugging to me. > Not something I'd put in the protocol msgs. >=20 > Hubert >=20 >=20 > On Mon, Sep 21, 2009 at 11:50 PM, Chirag Shah > wrote: > >> * The proposed Problem Reporting extension [1], its richness and > complexity > > > > I was curious if we could slightly update to the proposed problem > > reporting extension. > > > > The signature_invalid section in the Problem Reporting extension[1] > > should encourage service providers to include the > > signature_base_string they used in the error response. > > > > This information is valuable because the consumer can visually > > identify why their signature is invalid by comparing their > > signature_base string against the service provider's. If the service > > provider does not provide this information, the consumer is often > > guessing why their signature is invalid. > > > > [1] - http://wiki.oauth.net/ProblemReporting > > > > On Mon, Sep 21, 2009 at 1:40 PM, Eran Hammer-Lahav > wrote: > >> http://tools.ietf.org/html/draft-ietf-oauth-authentication > >> http://tools.ietf.org/html/draft-ietf-oauth-web-delegation > >> > >> I plan to publish new revisions of the above drafts to include: > >> > >> * Error codes and optional debug information > >> * Cleanup of the authentication extensibility model > >> * Change the version / protocol extensibility model > >> > >> In addition to general feedback about the drafts, I am looking for > specific feedback on the following items which I plan to address in the > next drafts: > >> > >> * Drop core support for the RSA-SHA1 method > >> * Replace HMAC-SHA1 with HMAC-SHA256 > >> * Define the authentication parameters as method-specific (for > example, drop nonce and timestamp from PLAINTEXT) > >> * The proposed Problem Reporting extension [1], its richness and > complexity > >> * Making the HMAC signature method required for all server > implementations > >> * Changing the delegation flow to require HTTP POST instead of > recommending it > >> * Mandating server support for all three parameter transmission > methods > >> * Adding a token revocation endpoint > >> * Adding the ability for servers to declare their configuration > (methods, etc.) in the WWW-Authenticate header response > >> * The value of the client credentials (Consumer Key) and feedback > from actual implementation experience > >> > >> In order for your feedback to be included or considered for the next > revisions it must be received by 10/2 on the oauth@ietf.org list. > >> > >> EHL > >> > >> [1] http://wiki.oauth.net/ProblemReporting > >> > >> _______________________________________________ > >> 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 chiragshah1@gmail.com Mon Sep 21 17:04:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750D53A67F0 for ; Mon, 21 Sep 2009 17:04: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB9ewRqretnN for ; Mon, 21 Sep 2009 17:04:36 -0700 (PDT) Received: from mail-px0-f177.google.com (mail-px0-f177.google.com [209.85.216.177]) by core3.amsl.com (Postfix) with ESMTP id 686233A659B for ; Mon, 21 Sep 2009 17:04:36 -0700 (PDT) Received: by pxi7 with SMTP id 7so370428pxi.17 for ; Mon, 21 Sep 2009 17:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bE5DuUtLWI+vd3/tnAGakK9DeTzW9l9iP9GfvqzWpiQ=; b=orpbMYPMRnFS/tmrc9v5YnzK2rGHNytOBbllIOaVd6im/pav7m5dQnAbSMxDzURx17 dSyWpjjcEWzcswHSGKRwGuXlExjWfjZ/pYNMSfnKHpcVJUFqzbNyHW6RRibFpeNWOqEv Z641oLZXI2nZ6DPasx7hbxlxwwOHGFE/7Eve8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sWI70Ng9U4waRtQlA4gzrKgv4wE3H2/Yf9xE2ltu10gr6/ncc3hMqXGUVwDPWPLzIr ynZHkU6smQQ5M1nCALqhJqPKjcANaUQ7usXC+xqHMmQGRLx258FsRGJYpz6Ljqu/9uPN cl30NuWG+Oc+FxRshW8w/7qy7Xr20VotKCOBU= MIME-Version: 1.0 Received: by 10.143.26.39 with SMTP id d39mr16725wfj.223.1253577936534; Mon, 21 Sep 2009 17:05:36 -0700 (PDT) In-Reply-To: <6c0fd2bc0909211459t647d0006s728b2630966cf603@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <74462b20909211450kf19596eg2df35e13f4836c2d@mail.gmail.com> <6c0fd2bc0909211459t647d0006s728b2630966cf603@mail.gmail.com> Date: Mon, 21 Sep 2009 17:05:36 -0700 Message-ID: <74462b20909211705s78ed9895je7d00411bb6e2a80@mail.gmail.com> From: Chirag Shah To: Hubert Le Van Gong Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 00:04:37 -0000 Isn't the purpose of the Problem Reporting extension is to help developers debug OAuth issues? Currently the text "signature_invalid" isn't very meaningful to developers debugging their applications because they want to know the exact reason why. On Mon, Sep 21, 2009 at 2:59 PM, Hubert Le Van Gong wrote: > I "hear your pain" but I'm not sure this is a good idea. > What you describe sounds more like debugging to me. > Not something I'd put in the protocol msgs. > > Hubert > > > On Mon, Sep 21, 2009 at 11:50 PM, Chirag Shah wrote: >>> * The proposed Problem Reporting extension [1], its richness and complexity >> >> I was curious if we could slightly update to the proposed problem >> reporting extension. >> >> The signature_invalid section in the Problem Reporting extension[1] >> should encourage service providers to include the >> signature_base_string they used in the error response. >> >> This information is valuable because the consumer can visually >> identify why their signature is invalid by comparing their >> signature_base string against the service provider's. If the service >> provider does not provide this information, the consumer is often >> guessing why their signature is invalid. >> >> [1] - http://wiki.oauth.net/ProblemReporting >> >> On Mon, Sep 21, 2009 at 1:40 PM, Eran Hammer-Lahav wrote: >>> http://tools.ietf.org/html/draft-ietf-oauth-authentication >>> http://tools.ietf.org/html/draft-ietf-oauth-web-delegation >>> >>> I plan to publish new revisions of the above drafts to include: >>> >>> * Error codes and optional debug information >>> * Cleanup of the authentication extensibility model >>> * Change the version / protocol extensibility model >>> >>> In addition to general feedback about the drafts, I am looking for specific feedback on the following items which I plan to address in the next drafts: >>> >>> * Drop core support for the RSA-SHA1 method >>> * Replace HMAC-SHA1 with HMAC-SHA256 >>> * Define the authentication parameters as method-specific (for example, drop nonce and timestamp from PLAINTEXT) >>> * The proposed Problem Reporting extension [1], its richness and complexity >>> * Making the HMAC signature method required for all server implementations >>> * Changing the delegation flow to require HTTP POST instead of recommending it >>> * Mandating server support for all three parameter transmission methods >>> * Adding a token revocation endpoint >>> * Adding the ability for servers to declare their configuration (methods, etc.) in the WWW-Authenticate header response >>> * The value of the client credentials (Consumer Key) and feedback from actual implementation experience >>> >>> In order for your feedback to be included or considered for the next revisions it must be received by 10/2 on the oauth@ietf.org list. >>> >>> EHL >>> >>> [1] http://wiki.oauth.net/ProblemReporting >>> >>> _______________________________________________ >>> 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 Mon Sep 21 17:14:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81153A6805 for ; Mon, 21 Sep 2009 17:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.085 X-Spam-Level: X-Spam-Status: No, score=-4.085 tagged_above=-999 required=5 tests=[AWL=-1.486, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZFfsuPZAzAA for ; Mon, 21 Sep 2009 17:14:51 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BEAD03A67C2 for ; Mon, 21 Sep 2009 17:14:51 -0700 (PDT) Received: (qmail 8033 invoked from network); 22 Sep 2009 00:15:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Sep 2009 00:15:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 21 Sep 2009 17:13:36 -0700 From: Eran Hammer-Lahav To: Chirag Shah , Hubert Le Van Gong Date: Mon, 21 Sep 2009 17:15:19 -0700 Thread-Topic: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due 10/2) Thread-Index: Aco7GG2FH9NdrF2rQHebJeF/HA1kygAAPcCA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D584E8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58457@P3PW5EX1MB01.EX1.SECURESERVER.NET> <74462b20909211450kf19596eg2df35e13f4836c2d@mail.gmail.com> <6c0fd2bc0909211459t647d0006s728b2630966cf603@mail.gmail.com> <74462b20909211705s78ed9895je7d00411bb6e2a80@mail.gmail.com> In-Reply-To: <74462b20909211705s78ed9895je7d00411bb6e2a80@mail.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] Request for feedback: OAuth IETF Drafts (Due 10/2) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 00:14:53 -0000 I think we need to clean up the problem reporting proposal and separate bet= ween codes that help debug and codes that call for an action. All the error= s which cannot be handled automatically by an application should be just ma= rked as fail. The specifics of such fail are only useful for human debuggin= g and while valuable, should be part of exactly that - debugging capabiliti= es. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Chirag Shah > Sent: Monday, September 21, 2009 5:06 PM > To: Hubert Le Van Gong > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Request for feedback: OAuth IETF Drafts (Due > 10/2) >=20 > Isn't the purpose of the Problem Reporting extension is to help > developers debug OAuth issues? >=20 > Currently the text "signature_invalid" isn't very meaningful to > developers debugging their applications because they want to know the > exact reason why. >=20 >=20 > On Mon, Sep 21, 2009 at 2:59 PM, Hubert Le Van Gong > wrote: > > I "hear your pain" but I'm not sure this is a good idea. > > What you describe sounds more like debugging to me. > > Not something I'd put in the protocol msgs. > > > > Hubert > > > > > > On Mon, Sep 21, 2009 at 11:50 PM, Chirag Shah > wrote: > >>> * The proposed Problem Reporting extension [1], its richness and > complexity > >> > >> I was curious if we could slightly update to the proposed problem > >> reporting extension. > >> > >> The signature_invalid section in the Problem Reporting extension[1] > >> should encourage service providers to include the > >> signature_base_string they used in the error response. > >> > >> This information is valuable because the consumer can visually > >> identify why their signature is invalid by comparing their > >> signature_base string against the service provider's. If the service > >> provider does not provide this information, the consumer is often > >> guessing why their signature is invalid. > >> > >> [1] - http://wiki.oauth.net/ProblemReporting > >> > >> On Mon, Sep 21, 2009 at 1:40 PM, Eran Hammer-Lahav > wrote: > >>> http://tools.ietf.org/html/draft-ietf-oauth-authentication > >>> http://tools.ietf.org/html/draft-ietf-oauth-web-delegation > >>> > >>> I plan to publish new revisions of the above drafts to include: > >>> > >>> * Error codes and optional debug information > >>> * Cleanup of the authentication extensibility model > >>> * Change the version / protocol extensibility model > >>> > >>> In addition to general feedback about the drafts, I am looking for > specific feedback on the following items which I plan to address in the > next drafts: > >>> > >>> * Drop core support for the RSA-SHA1 method > >>> * Replace HMAC-SHA1 with HMAC-SHA256 > >>> * Define the authentication parameters as method-specific (for > example, drop nonce and timestamp from PLAINTEXT) > >>> * The proposed Problem Reporting extension [1], its richness and > complexity > >>> * Making the HMAC signature method required for all server > implementations > >>> * Changing the delegation flow to require HTTP POST instead of > recommending it > >>> * Mandating server support for all three parameter transmission > methods > >>> * Adding a token revocation endpoint > >>> * Adding the ability for servers to declare their configuration > (methods, etc.) in the WWW-Authenticate header response > >>> * The value of the client credentials (Consumer Key) and feedback > from actual implementation experience > >>> > >>> In order for your feedback to be included or considered for the > next revisions it must be received by 10/2 on the oauth@ietf.org list. > >>> > >>> EHL > >>> > >>> [1] http://wiki.oauth.net/ProblemReporting > >>> > >>> _______________________________________________ > >>> 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 Mon Sep 21 18:40:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37473A69AF for ; Mon, 21 Sep 2009 18:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.05 X-Spam-Level: X-Spam-Status: No, score=-4.05 tagged_above=-999 required=5 tests=[AWL=-1.451, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg3NuBzd2Edj for ; Mon, 21 Sep 2009 18:40:47 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C2D443A6800 for ; Mon, 21 Sep 2009 18:40:44 -0700 (PDT) Received: (qmail 8548 invoked from network); 22 Sep 2009 01:41:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Sep 2009 01:41:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 21 Sep 2009 18:39:33 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Mon, 21 Sep 2009 18:41:42 -0700 Thread-Topic: Reevaluating Assumptions (Important!) Thread-Index: Aco7JdXiSQ9CsHH0QP6jHQceSIuH1A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 01:40:55 -0000 OAuth has been designed over 2 years ago based on many assumptions that wer= e true at that time. The most significant assumptions were: * HTTPS cannot be required due to deployment limitations * OAuth will be mostly used with proprietary APIs * Many web platforms do not provide access to the wire HTTP request URI (ei= ther on the client or server side) I strongly believe it would be a mistake to continue this work without ques= tioning these assumptions and making sure we are not producing a lesser sol= ution by trying to accommodate them. The first two assumptions are easy: * HTTPS cannot be required due to deployment limitations This still holds true. OAuth security cannot be based solely on using HTTPS= due to deployment limitations. However, the protocol must easily support d= eployments that have HTTPS easily available and not make them waste resourc= es will timestamps, nonces, and other security elements. While PLAINTEXT pr= ovides such support, it doesn't go far enough and still requires the presen= ce of such parameters. * OAuth will be mostly used with proprietary APIs This has proved to be false. With new open APIs there is a greater need to = enable clients to interact with a protected resource that it has not encoun= tered before or one it has been coded explicitly for. What this means is th= at we need more discovery features built into the core protocol or more req= uired portions to promote interoperability. There should be a minimum that = any client facing an OAuth 404 should be able to handle. The third item: * Many web platforms do not provide access to the wire HTTP request URI (ei= ther on the client or server side) requires more research but it also holds the key to much of the protocol de= sign, namely: - The canonicalization of the HTTP request parameter and URI - this was don= e due to the fact that at the time, many popular web platforms did not prov= ide easy access to the raw HTTP request URI and headers. If this is no long= er the case, OAuth can be significantly simplified to remove the need to pr= ocess the parameters and only treat the request URI. - The inclusion of multiple parameter transmission methods - this was done = due to lack of access to the Authorization header in some clients and serve= r environment. If this is no longer a requirement or if we come to the conc= lusion that HTTP caching requires that we use the header in all requests, t= he need to support parameters in places other than the header will also go = away. If we come to the conclusion that the last assumption is either incorrect o= r irrelevant (the requirement to use HTTP auth headers), we will be able to= significantly simplify the protocol which will also accomplish improving i= nteroperability and security. ACTION ITEM: We need to conduct a quick survey of web platforms to figure out if they pr= ovide access to the RAW HTTP request (client and server), and if they provi= de access to the HTTP auth headers (client and server). If you know, please= reply with the information for the platforms you use. EHL From mnot@mnot.net Mon Sep 21 18:47:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A473A69C9 for ; Mon, 21 Sep 2009 18:47:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABENCAupuqQv for ; Mon, 21 Sep 2009 18:47:31 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 0155D3A6942 for ; Mon, 21 Sep 2009 18:47:30 -0700 (PDT) Received: from [10.250.3.108] (unknown [120.152.89.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 86BC522E256; Mon, 21 Sep 2009 21:48:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 22 Sep 2009 11:48:15 +1000 Content-Transfer-Encoding: 7bit Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1076) Cc: "oauth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 01:47:32 -0000 From a quick look, it looks like you use GET to the user authorisation URL, at least, so in this case the response could be cached. However, if Cache-Control, Expires and Last-Modified are all absent, it will only be stored by a few shared caches (e.g., IIS) and only reused in unusual circumstances (e.g., the origin is not available any more). As I have said many times before, I don't buy arguments that we have to consider environments where people don't have access to HTTP headers; while they exist, the intersection of people who want to use OAuth and those who absolutely under any condition cannot find a way to influence HTTP headers (including changing hosting environments) is vanishingly small. All that accommodating these situations does is make the argument that people don't need access to headers stronger, thereby weakening the Web overall. That said, the usual approach here is to use a nonce in the URL. Completely disallowing caching of a GET response without any access to headers isn't possible. BTW, how does authentication help? Presumably if you can send credentials, you can set other headers as well. Cheers, On 22/09/2009, at 7:15 AM, Eran Hammer-Lahav wrote: > As currently written, OAuth use of the HTTP authentication headers > is optional at best. > > The reason for that was based on concerns that some platforms do not > provide access to the HTTP header in either the request or the > reply. However, this might have significant ramifications on caching > and other parts of HTTP where an indication of an authenticate > interaction is needed. > > Before the OAuth WG spends any time on discussing the various > methods of sending authentication parameters, I would like to find > out if using the authentication headers is more of a requirement for > such a protocol. > > EHL > -- Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Mon Sep 21 20:02:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C723A69C6 for ; Mon, 21 Sep 2009 20:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.016 X-Spam-Level: X-Spam-Status: No, score=-4.016 tagged_above=-999 required=5 tests=[AWL=-1.417, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEjS1HxOBlsW for ; Mon, 21 Sep 2009 20:02:30 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 286B63A697D for ; Mon, 21 Sep 2009 20:02:30 -0700 (PDT) Received: (qmail 21590 invoked from network); 22 Sep 2009 03:03:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Sep 2009 03:03:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 21 Sep 2009 20:01:15 -0700 From: Eran Hammer-Lahav To: Mark Nottingham Date: Mon, 21 Sep 2009 20:03:30 -0700 Thread-Topic: OAuth and HTTP caching Thread-Index: Aco7JswGYhJIXfHoSNatzdTHX7pcUgACa2xQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58500@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@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@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 03:02:31 -0000 The call can be anything (not just GET), since OAuth is used for accessing = resources, not just during the delegation workflow. EHL > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Monday, September 21, 2009 6:48 PM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org; ietf-http-wg@w3.org Group > Subject: Re: OAuth and HTTP caching >=20 > From a quick look, it looks like you use GET to the user > authorisation URL, at least, so in this case the response could be > cached. However, if Cache-Control, Expires and Last-Modified are all > absent, it will only be stored by a few shared caches (e.g., IIS) and > only reused in unusual circumstances (e.g., the origin is not > available any more). >=20 > As I have said many times before, I don't buy arguments that we have > to consider environments where people don't have access to HTTP > headers; while they exist, the intersection of people who want to use > OAuth and those who absolutely under any condition cannot find a way > to influence HTTP headers (including changing hosting environments) is > vanishingly small. All that accommodating these situations does is > make the argument that people don't need access to headers stronger, > thereby weakening the Web overall. >=20 > That said, the usual approach here is to use a nonce in the URL. > Completely disallowing caching of a GET response without any access to > headers isn't possible. >=20 > BTW, how does authentication help? Presumably if you can send > credentials, you can set other headers as well. >=20 > Cheers, >=20 >=20 > On 22/09/2009, at 7:15 AM, Eran Hammer-Lahav wrote: >=20 > > As currently written, OAuth use of the HTTP authentication headers > > is optional at best. > > > > The reason for that was based on concerns that some platforms do not > > provide access to the HTTP header in either the request or the > > reply. However, this might have significant ramifications on caching > > and other parts of HTTP where an indication of an authenticate > > interaction is needed. > > > > Before the OAuth WG spends any time on discussing the various > > methods of sending authentication parameters, I would like to find > > out if using the authentication headers is more of a requirement for > > such a protocol. > > > > EHL > > >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ From chris.messina@gmail.com Mon Sep 21 22:34:29 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089973A68F4 for ; Mon, 21 Sep 2009 22:34:29 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4F25VZLMC8l for ; Mon, 21 Sep 2009 22:34:27 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id 0D7183A6831 for ; Mon, 21 Sep 2009 22:34:26 -0700 (PDT) Received: by vws34 with SMTP id 34so2452933vws.32 for ; Mon, 21 Sep 2009 22:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Nga9nIfAiylHpZ3lzsb6fwPrezorMcXiWXicjNl6q04=; b=Pfj7r5VdlYi1uHRzAkEZh7QrrFRjyynO8so4/ZE+P4IxqMXqHSR/AXFQ7wnpDD8kIu 1KOFuztTGuZDZV4xr6Mftd8DYOrnSCB6dc+k2q/+Z8DUB3GCWvVCvrHPR+H15A+LaXtq WjveQ9j+RM38sg/C0tKstEJlsYU3yvK0o9gNk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dlwCH01rZ4TSV7cNh0uqePHAhzBRqGVdNMI6rZkMsqe5XCrWHS3I2KUgaHGe9bONk2 Ov7IQKFUJ4TKZEUzGuFOqBEyhYZSaRXfOLhgfXKhNbyTNcNjOgavX20OYZlkjsIrOCa4 9buPqyjFS4wNUWToY36r0PWRoznwXrPaUq1rc= MIME-Version: 1.0 Received: by 10.220.108.163 with SMTP id f35mr793719vcp.86.1253597724702; Mon, 21 Sep 2009 22:35:24 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343784D584A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0909211441o3eacc564t2917cf5b94f99800@mail.gmail.com> <1bc4603e0909211522h2f659866v48ff9dcee9294b7a@mail.gmail.com> <6c0fd2bc0909211534s1f2b79c6m7577dee31accf9c7@mail.gmail.com> <6c0fd2bc0909211600n541ef6d8g402c8596062e14f8@mail.gmail.com> Date: Mon, 21 Sep 2009 22:35:24 -0700 Message-ID: <1bc4603e0909212235n29b65ef3s8144c31ee293b1b2@mail.gmail.com> From: Chris Messina To: Jonathan Sergent Content-Type: multipart/alternative; boundary=00c09f8de08f127b5e047423f76a Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Token expiration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 05:34:29 -0000 --00c09f8de08f127b5e047423f76a Content-Type: text/plain; charset=ISO-8859-1 It'd be great if we could document all these techniques on the wiki: http://wiki.oauth.net Mailing lists is where good research like this goes to die! Chris On Mon, Sep 21, 2009 at 4:23 PM, Jonathan Sergent wrote: > I meant n seconds from when the response was sent by the server. > > On Mon, Sep 21, 2009 at 4:00 PM, Hubert Le Van Gong > wrote: > > In theory I'd agree with you but... > > (1) there are ways of achieving reasonable clock sync nowadays > > (2) usually the validity period is long enough that the clocks are > > considered roughly in sync. > > (3) the n seconds means I can keep the token for a very long period > > of time and present it? Unless you meant seconds starting from > > the sender's clock, in which case we're back to the same issue. > > > > If the token is for a sensitive resource, one can still impose a one time > use... > > > > My 2 cents, > > Hubert > > > > > > On Tue, Sep 22, 2009 at 12:47 AM, Jonathan Sergent > wrote: > >> IMO, it's problematic that this relies on clock synchronization > >> between the sender and the receiver to work. This is a constant > >> source of problems in need of debugging for us today. Why not specify > >> times like this using intervals? "This token is valid for the next n > >> seconds." > >> > >> On Mon, Sep 21, 2009 at 3:34 PM, Hubert Le Van Gong < > hubertlvg@gmail.com> wrote: > >>> An interesting example (to me at least since we use it) is the SAML > token. > >>> You have the ability to define three dates: > >>> - IssueInstant: the time of issue of the token [required] > >>> - NotBefore: time before which the token's invalid [optional] > >>> - NotOnOrAfter: time after which the token becomes invalid [optional] > >>> > >>> All are dateTime (in UTC form). > >>> > >>> Thanks, > >>> Hubert > >>> > >>> > >>> On Tue, Sep 22, 2009 at 12:22 AM, Chris Messina < > chris.messina@gmail.com> wrote: > >>>> Seems like it'd be worth documenting existing approaches to this... > what do > >>>> other similar APIs do? > >>>> I know I harp on this approach to technology development, but that was > how > >>>> OAuth was developed (for better or worse): by looking at existing > practices, > >>>> extracting convention, and codifying ]ideally] best practices. > >>>> If this is common and working elsewhere, can't we just imitate it? > >>>> Chris > >>>> > >>>> On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong < > hubertlvg@gmail.com> > >>>> wrote: > >>>>> > >>>>> It is obviously useful to have. In fact it's so useful I'll bet most > >>>>> token format > >>>>> used do include one. Having it outside the token becomes redundant > then > >>>>> but > >>>>> maybe it's not that bad. > >>>>> > >>>>> BTW why not using dateTime ( > http://www.w3.org/TR/xmlschema-2/#dateTime)? > >>>>> > >>>>> Cheers, > >>>>> Hubert > >>>>> > >>>>> > >>>>> On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav < > eran@hueniverse.com> > >>>>> wrote: > >>>>> > Should the core spec support the ability to indicate the duration > of > >>>>> > token credentials? This would be an addition to the web delegation > draft [1] > >>>>> > in section 6 (Token Credentials) in the form of a new response > parameter, > >>>>> > something like: > >>>>> > > >>>>> > oauth_token_duration > >>>>> > The token duration specified in second from the time of the HTTP > >>>>> > response timestamp. > >>>>> > > >>>>> > This has been consistently at the top of missing core > funcationality. > >>>>> > > >>>>> > > >>>>> > EHL > >>>>> > > >>>>> > [1] http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01 > >>>>> > > >>>>> > _______________________________________________ > >>>>> > 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 > >>>> > >>>> > >>>> > >>>> -- > >>>> Chris Messina > >>>> Open Web Advocate > >>>> > >>>> Personal: http://factoryjoe.com > >>>> Follow me on Twitter: http://twitter.com/chrismessina > >>>> > >>>> Citizen Agency: http://citizenagency.com > >>>> Diso Project: http://diso-project.org > >>>> OpenID Foundation: http://openid.net > >>>> > >>>> This email is: [ ] shareable [X] ask first [ ] private > >>>> > >>> _______________________________________________ > >>> 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 > -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --00c09f8de08f127b5e047423f76a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It'd be great if we could document all these techniques on the wiki:


Chris

On Mon, Sep 21,= 2009 at 4:23 PM, Jonathan Sergent <sergent@google.com> wrote:
I meant n seconds from when the response was sent by the server.

On Mon, Sep 21, 2009 at 4:00 PM, Hubert Le Van Gong <hubertlvg@gmail.com> wrote:
> In theory I'd agree with you but...
> (1) there are ways of achieving reasonable clock sync nowadays
> (2) usually the validity period is long enough that the clocks are
> =A0 =A0 considered roughly in sync.
> (3) the n seconds means I can keep the token for a very long period > =A0 =A0of time and present it? Unless you meant seconds starting from<= br> > =A0 =A0the sender's clock, in which case we're back to the sam= e issue.
>
> If the token is for a sensitive resource, one can still impose a one t= ime use...
>
> My 2 cents,
> Hubert
>
>
> On Tue, Sep 22, 2009 at 12:47 AM, Jonathan Sergent <sergent@google.com> wrote:
>> IMO, it's problematic that this relies on clock synchronizatio= n
>> between the sender and the receiver to work. =A0This is a constant=
>> source of problems in need of debugging for us today. =A0Why not s= pecify
>> times like this using intervals? =A0"This token is valid for = the next n
>> seconds."
>>
>> On Mon, Sep 21, 2009 at 3:34 PM, Hubert Le Van Gong <hubertlvg@gmail.com> wrote:
>>> An interesting example (to me at least since we use it) is the= SAML token.
>>> You have the ability to define three dates:
>>> - IssueInstant: the time of issue of the token [required]
>>> - NotBefore: time before which the token's invalid [option= al]
>>> - NotOnOrAfter: time after which the token becomes invalid [op= tional]
>>>
>>> All are dateTime (in UTC form).
>>>
>>> Thanks,
>>> Hubert
>>>
>>>
>>> On Tue, Sep 22, 2009 at 12:22 AM, Chris Messina <chris.messina@gmail.com> wrote:
>>>> Seems like it'd be worth documenting existing approach= es to this... what do
>>>> other similar APIs do?
>>>> I know I harp on this approach to technology development, = but that was how
>>>> OAuth was developed (for better or worse): by looking at e= xisting practices,
>>>> extracting convention, and codifying ]ideally] best practi= ces.
>>>> If this is common and working elsewhere, can't we just= imitate it?
>>>> Chris
>>>>
>>>> On Mon, Sep 21, 2009 at 2:41 PM, Hubert Le Van Gong <hubertlvg@gmail.com>
>>>> wrote:
>>>>>
>>>>> It is obviously useful to have. In fact it's so us= eful I'll bet most
>>>>> token format
>>>>> used do include one. Having it outside the token becom= es redundant then
>>>>> but
>>>>> maybe it's not that bad.
>>>>>
>>>>> BTW why not using dateTime (http://www.w3.org/TR/xmlsche= ma-2/#dateTime)?
>>>>>
>>>>> Cheers,
>>>>> Hubert
>>>>>
>>>>>
>>>>> On Mon, Sep 21, 2009 at 11:25 PM, Eran Hammer-Lahav &l= t;eran@hueniverse.com>
>>>>> wrote:
>>>>> > Should the core spec support the ability to indic= ate the duration of
>>>>> > token credentials? This would be an addition to t= he web delegation draft [1]
>>>>> > in section 6 (Token Credentials) in the form of a= new response parameter,
>>>>> > something like:
>>>>> >
>>>>> > oauth_token_duration
>>>>> > =A0 =A0The token duration specified in second fro= m the time of the HTTP
>>>>> > response timestamp.
>>>>> >
>>>>> > This has been consistently at the top of missing = core funcationality.
>>>>> >
>>>>> >
>>>>> > EHL
>>>>> >
>>>>> > [1] http://tools.ietf.org/html/d= raft-ietf-oauth-web-delegation-01
>>>>> >
>>>>> > _______________________________________________ >>>>> > OAuth mailing list
>>>>> > OAuth@ietf.org<= /a>
>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>> >
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> --
>>>> Chris Messina
>>>> Open Web Advocate
>>>>
>>>> Personal: http://factoryjoe.com
>>>> Follow me on Twitter: http://twitter.com/chrismessina
>>>>
>>>> Citizen Agency: http://citizenagency.com
>>>> Diso Project: http://diso-project.org
>>>> OpenID Foundation: http://openid.net
>>>>
>>>> This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 = [ ] private
>>>>
>>> _______________________________________________
>>> 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
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
Chris Messi= na
Open Web Advocate

Personal: = http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagen= cy.com
Diso Project: http://diso= -project.org
OpenID Foundation: http:/= /openid.net

This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private
--00c09f8de08f127b5e047423f76a-- From mnot@mnot.net Tue Sep 22 00:55:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1053A6986 for ; Tue, 22 Sep 2009 00:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.877 X-Spam-Level: X-Spam-Status: No, score=-4.877 tagged_above=-999 required=5 tests=[AWL=-2.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1h2WYL451bl for ; Tue, 22 Sep 2009 00:55:45 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id AB2C53A688B for ; Tue, 22 Sep 2009 00:55:45 -0700 (PDT) Received: from [10.168.48.118] (unknown [123.208.6.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 86373509B3; Tue, 22 Sep 2009 03:56:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: Date: Tue, 22 Sep 2009 17:56:27 +1000 Content-Transfer-Encoding: 7bit Message-Id: <32C79DCD-0427-4253-98A0-1734BAB35C2D@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: John Panzer X-Mailer: Apple Mail (2.1076) Cc: "oauth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 07:55:46 -0000 On 22/09/2009, at 7:56 AM, John Panzer wrote: > On the server side, one of the concerns in the past has been > security in shared hosting systems where e.g., basic auth data > should be handled by a secure container (Apache) and not passed on > in raw form to hosted CGI scripts. So some of this comes back to > what minimum level of hosting should be targeted by the > specification -- and how much it should bend over backwards to deal > with "challenged" environments. That's a good discussion to have. > My $.02 is that we should follow the HTTP spec (Authorization: and > WWW-Authenticate:) and take a minimum distance path to route around > limited environments if necessary (X-Authorization: and X-WWW- > Authenticate:, with exactly the same content, would be my proposal). Ugh. By allowing other resources on the same server to see authentication credentials, wouldn't that just re-open these attacks? > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > > On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav > wrote: > As currently written, OAuth use of the HTTP authentication headers > is optional at best. > > The reason for that was based on concerns that some platforms do not > provide access to the HTTP header in either the request or the > reply. However, this might have significant ramifications on caching > and other parts of HTTP where an indication of an authenticate > interaction is needed. > > Before the OAuth WG spends any time on discussing the various > methods of sending authentication parameters, I would like to find > out if using the authentication headers is more of a requirement for > such a protocol. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Mark Nottingham http://www.mnot.net/ From hubertlvg@gmail.com Tue Sep 22 06:33:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FF828C118 for ; Tue, 22 Sep 2009 06:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHP0HoDZ0YGo for ; Tue, 22 Sep 2009 06:33:54 -0700 (PDT) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id 651F228C0E5 for ; Tue, 22 Sep 2009 06:33:54 -0700 (PDT) Received: by fxm27 with SMTP id 27so766184fxm.42 for ; Tue, 22 Sep 2009 06:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=kt+1KS1RLGH9Xi7VGgeD3lAnngedBi4ps3OQ8zOQnIA=; b=YaPtfhaYFtX9SkeDTaYAPBIbJZQH0swYcIWzCvticCRS7J0aFhBTtjaTq2trZqhzY9 GZ9ib5aIgv92MsYp/3Viwvd1Y1UPIolcoPtmDqy3A7trDQikHBRaW/PT+nTL93HuBpnR JFwVY59/tV5xRlavyvAo9FHbCtqqQOgHS3Dow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TvjTBAEuBflE5Zxu7hHpW6yGrP/a3sJ1CSJ7MZHFSnpwbsICnvCO+JMPMFx8YEtMsX EH/IB5UPvoch0WZ2blmelCa74wPIouFI2nVeefnm6cK0wBkicSMnCaQ9VQphyY0z/xyC +Wd9gynVVmptHuVD9OpA+Q1VgBHZIclLz3DHk= MIME-Version: 1.0 Received: by 10.204.162.143 with SMTP id v15mr840798bkx.50.1253626494823; Tue, 22 Sep 2009 06:34:54 -0700 (PDT) Date: Tue, 22 Sep 2009 15:34:54 +0200 Message-ID: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 13:33:55 -0000 Reading the latest draft I see we do not mandate a minimum set of signature algorithms. I think we should mandate a few (at least one) so we get a minimum of interoperability out of the box. Thoughts? Cheers, Hubert From eran@hueniverse.com Tue Sep 22 08:18:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01A0B3A6A9B for ; Tue, 22 Sep 2009 08:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.02 X-Spam-Level: X-Spam-Status: No, score=-4.02 tagged_above=-999 required=5 tests=[AWL=-1.421, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DSdW875ZW0O for ; Tue, 22 Sep 2009 08:18:24 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3B2FB3A6A96 for ; Tue, 22 Sep 2009 08:18:24 -0700 (PDT) Received: (qmail 3847 invoked from network); 22 Sep 2009 15:19:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Sep 2009 15:19:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 22 Sep 2009 08:17:11 -0700 From: Eran Hammer-Lahav To: Hubert Le Van Gong , "oauth@ietf.org" Date: Tue, 22 Sep 2009 08:19:28 -0700 Thread-Topic: [OAUTH-WG] Mandatory signature algorithms? Thread-Index: Aco7iX2sCphffwerSU+yM2ry27xa+wADnWKw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> In-Reply-To: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.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 Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 15:18:25 -0000 Yes, it is right there on my list of proposed changes I am seeking feedback= on. I think we need to pick one and make it required. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Hubert Le Van Gong > Sent: Tuesday, September 22, 2009 6:35 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Mandatory signature algorithms? >=20 > Reading the latest draft I see we do not mandate a minimum set of > signature algorithms. > I think we should mandate a few (at least one) so we get a minimum of > interoperability > out of the box. > Thoughts? >=20 > Cheers, > Hubert > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Tue Sep 22 08:45:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0A23A6A08 for ; Tue, 22 Sep 2009 08:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K2ZnG5KPKNz for ; Tue, 22 Sep 2009 08:45:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id B8FFD3A6958 for ; Tue, 22 Sep 2009 08:45:46 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id n8MFkovN024829 for ; Tue, 22 Sep 2009 08:46:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1253634410; bh=6IKzr+JDW8zn1p4D10z0ecCeleY=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=IpxIPS52jpzwE04Go4 1n4sKKpA+53+qkyZ8u2uNB5THmqL8xtPNxNf1mU4icT8b8Rz6LB91vWE7cfpcMHBzuD Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=trG+oiKMOYFNjAph7afn3BpchrDXy1PmB/t9N6HweMlESNMcfygNPI5+QFqUpK7W/ 6FTr/nlb0Z+nvPqLAvm7Q== Received: from qyk1 (qyk1.prod.google.com [10.241.83.129]) by wpaz29.hot.corp.google.com with ESMTP id n8MFkla2028819 for ; Tue, 22 Sep 2009 08:46:48 -0700 Received: by qyk1 with SMTP id 1so2963608qyk.22 for ; Tue, 22 Sep 2009 08:46:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.23 with SMTP id 23mr411056qch.87.1253634407453; Tue, 22 Sep 2009 08:46:47 -0700 (PDT) In-Reply-To: <32C79DCD-0427-4253-98A0-1734BAB35C2D@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <32C79DCD-0427-4253-98A0-1734BAB35C2D@mnot.net> Date: Tue, 22 Sep 2009 08:46:47 -0700 Message-ID: From: John Panzer To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 15:45:49 -0000 Inline... On Tuesday, September 22, 2009, Mark Nottingham wrote: > > On 22/09/2009, at 7:56 AM, John Panzer wrote: > > > On the server side, one of the concerns in the past has been security in = shared hosting systems where e.g., basic auth data should be handled by a s= ecure container (Apache) and not passed on in raw form to hosted CGI script= s. =A0So some of this comes back to what minimum level of hosting should be= targeted by the specification -- and how much it should bend over backward= s to deal with "challenged" environments. > > > That's a good discussion to have. > > > My $.02 is that we should follow the HTTP spec (Authorization: and WWW-Au= thenticate:) and take a minimum distance path to route around limited envir= onments if necessary (X-Authorization: and X-WWW-Authenticate:, with exactl= y the same content, would be my proposal). > > > Ugh. By allowing other resources on the same server to see authentication= credentials, wouldn't that just re-open these attacks? > > 1. Oauth, at least when accessing protected resources, is designed to be used over insecure connections, so the password sniffing attacks don't apply. 2. The alternative on the table is to pass these as URL params, which are more sniffable and also makes the web cry. > > > -- > John Panzer / Google > jpanzer@google.com=A0/ abstractioneer.org / @jpanzer > > > > On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav = wrote: > As currently written, OAuth use of the HTTP authentication headers is opt= ional at best. > > The reason for that was based on concerns that some platforms do not prov= ide access to the HTTP header in either the request or the reply. However, = this might have significant ramifications on caching and other parts of HTT= P where an indication of an authenticate interaction is needed. > > Before the OAuth WG spends any time on discussing the various methods of = sending authentication parameters, I would like to find out if using the au= thentication headers is more of a requirement for such a protocol. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Mark Nottingham =A0 =A0 http://www.mnot.net/ > > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From eran@hueniverse.com Tue Sep 22 08:47:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FFF53A6A49 for ; Tue, 22 Sep 2009 08:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 tagged_above=-999 required=5 tests=[AWL=-1.390, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy2fG5JCi3YS for ; Tue, 22 Sep 2009 08:47:47 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id B52ED3A697F for ; Tue, 22 Sep 2009 08:47:47 -0700 (PDT) Received: (qmail 30483 invoked from network); 22 Sep 2009 15:48:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Sep 2009 15:48:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 22 Sep 2009 08:48:43 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Tue, 22 Sep 2009 08:48:41 -0700 Thread-Topic: Publishing OAuth Core 1.0a as IETF Info RFC Thread-Index: Aco7nCiIjvct6ZYJSoWffwLsrp4qKg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D585AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: 9R0= B+Nh CWxK D2cw HULT Ij6t KTto Kn6O KuRO Nv+I ORJW Pblw QHbC QxyV Q3y0 SErc; 2; bABpAHMAYQAuAGQAdQBzAHMAZQBhAHUAbAB0AEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBvAGEAdQB0AGgAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {AB5789F7-F286-4F63-8D0F-E9E6A6206FF5}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Tue, 22 Sep 2009 15:48:41 GMT; UAB1AGIAbABpAHMAaABpAG4AZwAgAE8AQQB1AHQAaAAgAEMAbwByAGUAIAAxAC4AMABhACAAYQBzACAASQBFAFQARgAgAEkAbgBmAG8AIABSAEYAQwA= x-cr-puzzleid: {AB5789F7-F286-4F63-8D0F-E9E6A6206FF5} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 15:47:48 -0000 What do people think about the idea of publishing the current OAuth 1.0a as= an Informational RFC? This will mean simply taking the pre-WG draft [1] an= d applying the Revision A changes [2] (as has been done to the WG drafts). There is currently a lot of confusion about which spec people should be rea= ding. The OAuth Core 1.0a spec also suffers from poor structure, uses a dif= ferent set of terms from the WG draft, and contains bugs. By quickly publis= hing the I-D as an informational RFC which clearly states it is just a docu= mentation of existing behavior, we will accomplish: 1. Clarity in the market with regard to which specs should be used 2. An easier upgrade path as the RFC will be marked as obsolete once the ne= w work is completed 3. Reduce the need to preserve some features of the protocol because the in= fo RFC will cover that for use cases the new spec will drop 4. Provide a consistent experience across the different protocol specificat= ions, with common terminology, improving our ability to discuss old vs. new= and reduce the learning curve for those transitioning This will not be a working group deliverable. If enough people here feel th= is is a good idea, I will get this ready in a couple of days and post if fo= r last call. The work is already done, we just need to decide if we want to= push it out. I am very much in support for such a publication. EHL [1] http://tools.ietf.org/html/draft-hammer-oauth [2] http://code.google.com/p/oauth/source/diff?spec=3Dsvn1058&old=3D991&r= =3D1058&format=3Dunidiff&path=3D%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml From eran@hueniverse.com Tue Sep 22 10:23:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0CB63A67C0 for ; Tue, 22 Sep 2009 10:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.96 X-Spam-Level: X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[AWL=-1.361, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQAaKXIeVOgk for ; Tue, 22 Sep 2009 10:23:27 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D5A713A67AF for ; Tue, 22 Sep 2009 10:23:26 -0700 (PDT) Received: (qmail 14867 invoked from network); 22 Sep 2009 17:24:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Sep 2009 17:24:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 22 Sep 2009 10:22:13 -0700 From: Eran Hammer-Lahav To: "Roy T. Fielding" , John Panzer Date: Tue, 22 Sep 2009 10:24:30 -0700 Thread-Topic: [OAUTH-WG] OAuth and HTTP caching Thread-Index: Aco7p3bE6qFcDswhQV6ti28cv2dZvwAAZ5nQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com> In-Reply-To: <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.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" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 17:23:28 -0000 > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@gbiv.com] > Sent: Tuesday, September 22, 2009 10:09 AM > Just follow the HTTP spec. That what I am trying to figure out... Does the HTTP spec mandates that new authentication protocols use the WWW-A= uthenticate and Authorization headers? Are the headers required for existin= g caches and servers to operate properly? If they are not included in authe= nticated requests, are there other requirements to make sure it doesn't bre= ak existing deployment? Thanks, HEL From stpeter@stpeter.im Tue Sep 22 10:28:51 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DB83A6972 for ; Tue, 22 Sep 2009 10:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC7AwShO1I75 for ; Tue, 22 Sep 2009 10:28:50 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3A4443A6931 for ; Tue, 22 Sep 2009 10:28:50 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4D75B4007B for ; Tue, 22 Sep 2009 11:29:54 -0600 (MDT) Message-ID: <4AB90992.6010003@stpeter.im> Date: Tue, 22 Sep 2009 11:29:54 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] [Fwd: Re: OAuth and HTTP caching] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 17:28:51 -0000 Sorry, the list administrators mistakenly discarded this message from the moderation queue... -------- Original Message -------- Subject: Re: [OAUTH-WG] OAuth and HTTP caching Resent-Date: Tue, 22 Sep 2009 17:10:21 +0000 Resent-From: ietf-http-wg@w3.org Date: Tue, 22 Sep 2009 10:09:16 -0700 From: Roy T. Fielding To: John Panzer CC: Eran Hammer-Lahav , "oauth@ietf.org" , "ietf-http-wg@w3.org Group" References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> On Sep 21, 2009, at 2:56 PM, John Panzer wrote: > On the server side, one of the concerns in the past has been > security in shared hosting systems where e.g., basic auth data > should be handled by a secure container (Apache) and not passed on > in raw form to hosted CGI scripts. So some of this comes back to > what minimum level of hosting should be targeted by the > specification -- and how much it should bend over backwards to deal > with "challenged" environments. That is only a concern for Basic auth, AFAIK. Apache could tweak it to only forward unhandled non-Basic credentials to CGI or just a summary of what has been validated, though some indication of what needs to be forwarded would be useful. > My $.02 is that we should follow the HTTP spec (Authorization: and > WWW-Authenticate:) and take a minimum distance path to route around > limited environments if necessary (X-Authorization: and X-WWW- > Authenticate:, with exactly the same content, would be my proposal). Just follow the HTTP spec. Someone will implement it. If people try to bypass HTTP extensibility mechanisms with stupid hacks that get shipped in production software, Apache will add code to strip their information from the stream before anyone sees it. ....Roy From fielding@gbiv.com Tue Sep 22 10:46:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372D928C0D8 for ; Tue, 22 Sep 2009 10:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.14 X-Spam-Level: X-Spam-Status: No, score=-5.14 tagged_above=-999 required=5 tests=[AWL=-2.541, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJMhCfhBZ0xn for ; Tue, 22 Sep 2009 10:46:57 -0700 (PDT) Received: from spaceymail-a1.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 85CCC28C0CE for ; Tue, 22 Sep 2009 10:46:57 -0700 (PDT) Received: from [192.168.0.101] (ip72-211-202-154.oc.oc.cox.net [72.211.202.154]) by spaceymail-a1.g.dreamhost.com (Postfix) with ESMTP id B7CB08077F; Tue, 22 Sep 2009 10:48:01 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Date: Tue, 22 Sep 2009 10:47:58 -0700 To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.753.1) X-Mailman-Approved-At: Tue, 22 Sep 2009 10:49:04 -0700 Cc: "oauth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 17:46:58 -0000 On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: >> -----Original Message----- >> From: Roy T. Fielding [mailto:fielding@gbiv.com] >> Sent: Tuesday, September 22, 2009 10:09 AM > >> Just follow the HTTP spec. > > That what I am trying to figure out... > > Does the HTTP spec mandates that new authentication protocols use > the WWW-Authenticate and Authorization headers? HTTP is not aware of any other kinds of authentication. There is no reason to specify anything else. > Are the headers required for existing caches and servers to operate > properly? Yes (and for user agents as well). Don't forget about Proxy-Auth*. > If they are not included in authenticated requests, are there other > requirements to make sure it doesn't break existing deployment? Cache-control: private is probably needed if the Auth headers are not being used but the response depends on something like cookies for authentication. ....Roy From eran@hueniverse.com Tue Sep 22 13:29:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7893A6AB6 for ; Tue, 22 Sep 2009 13:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.966 X-Spam-Level: X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb9VFRysap1i for ; Tue, 22 Sep 2009 13:29:30 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2A8823A699F for ; Tue, 22 Sep 2009 13:29:24 -0700 (PDT) Received: (qmail 20104 invoked from network); 22 Sep 2009 20:30:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Sep 2009 20:30:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 22 Sep 2009 13:28:05 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Tue, 22 Sep 2009 13:30:23 -0700 Thread-Topic: Publishing OAuth Core 1.0a as IETF Info RFC Thread-Index: Aco7nCiIjvct6ZYJSoWffwLsrp4qKgAJl8og Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D586D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D585AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D585AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 20:29:32 -0000 I have submitted a new version of the OAuth Core 1.0 draft: http://www.ietf.org/id/draft-hammer-oauth-03.txt This should be the last update to the 1.0 (based on revision A) draft. This= is NOT an working group item and is only submitted to document the current= protocol. I plan to request a last call by the end of the week. If approved, this document will replace the specification currently publish= ed at http://oauth.net/core/1.0 and http://oauth.net/core/1.0a. It will bec= ome the official specification for OAuth Core 1.0. Other than a complete editorial rewrite of the entire specification, it inc= ludes the following protocol changes: o Adjusted nonce language to indicate it is unique per token / timestamp / client combination. o Extended signature base string coverage which includes "application/x-www-form-urlencoded" entity-body parameters when the HTTP method used is other than POST and URI query parameters when the HTTP method used is other than GET. o Requirement to normalize empty request URI paths as "/". o Corrections to the instructions in each signature method to encode the signature value before inserting it into the "oauth_signature" parameter, removing errors which would have caused double-encoded values. These changes were made with wide consensus from the OAuth community, shoul= d be considered errata, and for the most part reflect how existing implemen= tations work. Some small changes will be required in some libraries to full= y comply with this new edition. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, September 22, 2009 8:49 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC >=20 > What do people think about the idea of publishing the current OAuth > 1.0a as an Informational RFC? This will mean simply taking the pre-WG > draft [1] and applying the Revision A changes [2] (as has been done to > the WG drafts). >=20 > There is currently a lot of confusion about which spec people should be > reading. The OAuth Core 1.0a spec also suffers from poor structure, > uses a different set of terms from the WG draft, and contains bugs. By > quickly publishing the I-D as an informational RFC which clearly states > it is just a documentation of existing behavior, we will accomplish: >=20 > 1. Clarity in the market with regard to which specs should be used > 2. An easier upgrade path as the RFC will be marked as obsolete once > the new work is completed > 3. Reduce the need to preserve some features of the protocol because > the info RFC will cover that for use cases the new spec will drop > 4. Provide a consistent experience across the different protocol > specifications, with common terminology, improving our ability to > discuss old vs. new and reduce the learning curve for those > transitioning >=20 > This will not be a working group deliverable. If enough people here > feel this is a good idea, I will get this ready in a couple of days and > post if for last call. The work is already done, we just need to decide > if we want to push it out. >=20 > I am very much in support for such a publication. >=20 > EHL >=20 >=20 >=20 > [1] http://tools.ietf.org/html/draft-hammer-oauth > [2] > http://code.google.com/p/oauth/source/diff?spec=3Dsvn1058&old=3D991&r=3D1= 058& > format=3Dunidiff&path=3D%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hallam@gmail.com Tue Sep 22 20:14:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914433A6869 for ; Tue, 22 Sep 2009 20:14: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLQWKWvc3u1Z for ; Tue, 22 Sep 2009 20:14:35 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id EA0493A67F2 for ; Tue, 22 Sep 2009 20:14:34 -0700 (PDT) Received: by yxe30 with SMTP id 30so500735yxe.29 for ; Tue, 22 Sep 2009 20:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hqvU8wod21svNIPokKvKP1jNRVHX+6hCHJudDFJCZJ4=; b=ZpvGlUW6pdvvCcDE8nevsHmdJOVhYUlLDMg24bDUUhvR/u2zgQxZ6OUpTpEU4TOPrZ i9kWNnZU37ecXOUS+z3LHU3L1CqQ6TwtnVrynGfTcvgik+ebj0ys3VE8z+n10q3Xi0+W KaxMjjcPfNUV3izPMugOOSPi0brbrA8y6ft0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=D8mlwmTGR3T/JJlUeTNYF073u1BYfF2SGVlZ6Z37+oleafaYD0GW+3ABm5+1AYJKbi tNoyQLGzIPbVohyVhxAgtJD/BmuuFSOkoh13fCv4Iif+GRdWuVFOIsOSdc0y1NeKZW87 KiaoqWp5mYKq3KAWtYAkRsoRdTVjrDawJ9kLw= MIME-Version: 1.0 Received: by 10.91.154.17 with SMTP id g17mr1021519ago.40.1253675737123; Tue, 22 Sep 2009 20:15:37 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 22 Sep 2009 23:15:37 -0400 Message-ID: From: Phillip Hallam-Baker To: John Panzer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 22 Sep 2009 20:15:33 -0700 Cc: "oauth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 03:14:36 -0000 HTTP is designed the way it is for a reason. Every single piece of infrastructure that people are using on the Web today was developed after the authenticate headers were designed. If people have designed a scripting host in such a fashion that the information does not make it through, that is clearly either a deliberate decision on their part or the system is so clueless that you probably don't want to use it for any security related application in any case. If you try to do a work around you may allow maybe a few legacy applications to work that would otherwise not. But you will do so by making OATH one of the obstacles that future designers have to work around. Part of the whole point of standards organizations is to help people to know what parts of the specs they can depend on being constant and which may change. That all changes if people start to make random choices and second guess. At the end of the day, this is a security spec. Every step we take that adds complexity reduces the security we will deliver. Every extra quotient of complexity is another opportunity for us to screw up or for implementers. On Mon, Sep 21, 2009 at 5:54 PM, John Panzer wrote: > On the server side, one of the concerns in the past has been security in > shared hosting systems where e.g., basic auth data should be handled by a > secure container (Apache) and not passed on in raw form to hosted CGI > scripts.=A0 So some of this comes back to what minimum level of hosting s= hould > be targeted by the specification -- and how much it should bend over > backwards to deal with "challenged" environments. > > My $.02 is that we should follow the HTTP spec (Authorization: and > WWW-Authenticate:) and take a minimum distance path to route around limit= ed > environments if necessary (X-Authorization: and X-WWW-Authenticate:, with > exactly the same content, would be my proposal). > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav > wrote: >> >> As currently written, OAuth use of the HTTP authentication headers is >> optional at best. >> >> The reason for that was based on concerns that some platforms do not >> provide access to the HTTP header in either the request or the reply. >> However, this might have significant ramifications on caching and other >> parts of HTTP where an indication of an authenticate interaction is need= ed. >> >> Before the OAuth WG spends any time on discussing the various methods of >> sending authentication parameters, I would like to find out if using the >> authentication headers is more of a requirement for such a protocol. >> >> 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 > > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From hallam@gmail.com Tue Sep 22 20:52:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50AC03A690A for ; Tue, 22 Sep 2009 20:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.606 X-Spam-Level: X-Spam-Status: No, score=-3.606 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5F2Dc6Wp6lE for ; Tue, 22 Sep 2009 20:52:46 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 5D7003A6874 for ; Tue, 22 Sep 2009 20:52:46 -0700 (PDT) Received: by ywh26 with SMTP id 26so201034ywh.29 for ; Tue, 22 Sep 2009 20:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NYl9azVPN9uW836dYzzyils8aEgUID2a6wHTQmZBsQ0=; b=qtJAtqLuFHyTrv8bcR8M6Byxvw5dPlyekLKkQpacn6s6cS/ilMkjamYw8SJsaW4WOF up/IQrQgg1p7PZVRb+U6z+6UZ6TNhiCdsqzliWl2UCFrw+shXfIwoACEMGcm5Ol+5pXD +d6Ea9SaPVDjQv8k31g5L7zEnVaXdLdPBaK4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cM1eqFdilB8xT79k9ipdxKCyOtKWobfFOUHSLA7voDb2X0E1O/yywPwBSwDWopu4pu 4a3gMc1A1xJz+86FbszszM2FlTQ0tGEm5tXQnllOTu8YKoEUQtcyhLnanTLJyoC8lBwh 6KOdi7RE3b8+gDgMjcMFuwyasAexM0shn9FCg= MIME-Version: 1.0 Received: by 10.91.154.17 with SMTP id g17mr1041168ago.40.1253678028093; Tue, 22 Sep 2009 20:53:48 -0700 (PDT) In-Reply-To: <4AB90992.6010003@stpeter.im> References: <4AB90992.6010003@stpeter.im> Date: Tue, 22 Sep 2009 23:53:48 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 22 Sep 2009 20:59:41 -0700 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Fwd: Re: OAuth and HTTP caching] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 03:52:48 -0000 I am really confused about the security issues here. If you are going to hand data off to a CGI script on a typical server, you are going to have 'interesting' security issues such as code injection. But I really don't see how not handing BASIC auth data to the script helps there. If an attacker has found a CGI hole that allows them to inject code, then they are going to go to privilege escalation and rootshell the machine anyway. Compartmentalization is not going to help. Very early in the history of the Web it was common to have a single Web site server shared by multiple users who would put scripts in their home directory. That may still happen in some university settings, but it is hardly typical commercial usage. Commercial servers hosting 1000 web sites are hosting them on 1000 separate domains. Each domain has unitary administration authority in at least 99% of cases. I don't see how the single Web site with multiple script provider issue can be safely handled unless the server design is dictatorial as Roy suggests. It is at this point an edge case though. On Tue, Sep 22, 2009 at 1:29 PM, Peter Saint-Andre wro= te: > Sorry, the list administrators mistakenly discarded this message from > the moderation queue... > > -------- Original Message -------- > Subject: Re: [OAUTH-WG] OAuth and HTTP caching > Resent-Date: Tue, 22 Sep 2009 17:10:21 +0000 > Resent-From: ietf-http-wg@w3.org > Date: Tue, 22 Sep 2009 10:09:16 -0700 > From: Roy T. Fielding > To: John Panzer > CC: Eran Hammer-Lahav , =A0 =A0"oauth@ietf.org" > , =A0 =A0 =A0 "ietf-http-wg@w3.org Group" > References: > <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER= .NET> > > > On Sep 21, 2009, at 2:56 PM, John Panzer wrote: > >> On the server side, one of the concerns in the past has been >> security in shared hosting systems where e.g., basic auth data >> should be handled by a secure container (Apache) and not passed on >> in raw form to hosted CGI scripts. =A0So some of this comes back to >> what minimum level of hosting should be targeted by the >> specification -- and how much it should bend over backwards to deal >> with "challenged" environments. > > That is only a concern for Basic auth, AFAIK. =A0Apache could tweak it > to only forward unhandled non-Basic credentials to CGI or just a summary > of what has been validated, though some indication of what needs to be > forwarded would be useful. > >> My $.02 is that we should follow the HTTP spec (Authorization: and >> WWW-Authenticate:) and take a minimum distance path to route around >> limited environments if necessary (X-Authorization: and X-WWW- >> Authenticate:, with exactly the same content, would be my proposal). > > Just follow the HTTP spec. =A0Someone will implement it. =A0If people try= to > bypass HTTP extensibility mechanisms with stupid hacks that get shipped > in production software, Apache will add code to strip their information > from the stream before anyone sees it. > > ....Roy > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From mnot@mnot.net Tue Sep 22 21:02:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85EDB3A6805 for ; Tue, 22 Sep 2009 21:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[AWL=-1.971, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVK5rvefjue9 for ; Tue, 22 Sep 2009 21:02:29 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 0E5EC3A679F for ; Tue, 22 Sep 2009 21:02:29 -0700 (PDT) Received: from [10.188.48.114] (unknown [123.208.174.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8D53B509DB; Wed, 23 Sep 2009 00:03:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: Date: Wed, 23 Sep 2009 14:03:15 +1000 Content-Transfer-Encoding: 7bit Message-Id: <90B6F372-B312-46F5-B9E8-9F4BAE547283@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <32C79DCD-0427-4253-98A0-1734BAB35C2D@mnot.net> To: John Panzer X-Mailer: Apple Mail (2.1076) Cc: "oauth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 04:02:32 -0000 That works -- provided OAuth is completely proof against replay attacks. However, are new headers really necessary? Reading in various places about this issue, it seems like a common workaround is to use mod_rewrite to expose the authorization header in the environment; e.g., RewriteEngine on RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L] Isn't that enough to get the 80% case of those who have trouble with getting direct access? Specifying two different headers to be used on the wire will lead people to always use the more conservative one (X- whatever, blech) and thereby lead us directly back into the situation Eran's concerned about (intermediaries not realising that this is protected content). The workaround for that will be having the header duplicated, with both names (double blech). Cheers, On 23/09/2009, at 1:46 AM, John Panzer wrote: > Inline... > > On Tuesday, September 22, 2009, Mark Nottingham wrote: >> >> On 22/09/2009, at 7:56 AM, John Panzer wrote: >> >> >> On the server side, one of the concerns in the past has been >> security in shared hosting systems where e.g., basic auth data >> should be handled by a secure container (Apache) and not passed on >> in raw form to hosted CGI scripts. So some of this comes back to >> what minimum level of hosting should be targeted by the >> specification -- and how much it should bend over backwards to deal >> with "challenged" environments. >> >> >> That's a good discussion to have. >> >> >> My $.02 is that we should follow the HTTP spec (Authorization: and >> WWW-Authenticate:) and take a minimum distance path to route around >> limited environments if necessary (X-Authorization: and X-WWW- >> Authenticate:, with exactly the same content, would be my proposal). >> >> >> Ugh. By allowing other resources on the same server to see >> authentication credentials, wouldn't that just re-open these attacks? >> >> > > 1. Oauth, at least when accessing protected resources, is designed to > be used over insecure connections, so the password sniffing attacks > don't apply. > > 2. The alternative on the table is to pass these as URL params, which > are more sniffable and also makes the web cry. > >> >> >> -- >> John Panzer / Google >> jpanzer@google.com / abstractioneer.org / @jpanzer >> >> >> >> On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav > > wrote: >> As currently written, OAuth use of the HTTP authentication headers >> is optional at best. >> >> The reason for that was based on concerns that some platforms do >> not provide access to the HTTP header in either the request or the >> reply. However, this might have significant ramifications on >> caching and other parts of HTTP where an indication of an >> authenticate interaction is needed. >> >> Before the OAuth WG spends any time on discussing the various >> methods of sending authentication parameters, I would like to find >> out if using the authentication headers is more of a requirement >> for such a protocol. >> >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer -- Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Tue Sep 22 21:15:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225683A6844 for ; Tue, 22 Sep 2009 21:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCRiog7ftr+4 for ; Tue, 22 Sep 2009 21:15:51 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BE0193A683F for ; Tue, 22 Sep 2009 21:15:51 -0700 (PDT) Received: from squire.local (dsl-179-156.dynamic-dsl.frii.net [216.17.179.156]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 431264007B; Tue, 22 Sep 2009 22:16:56 -0600 (MDT) Message-ID: <4AB9A136.4050201@stpeter.im> Date: Tue, 22 Sep 2009 22:16:54 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Mark Nottingham References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <32C79DCD-0427-4253-98A0-1734BAB35C2D@mnot.net> <90B6F372-B312-46F5-B9E8-9F4BAE547283@mnot.net> In-Reply-To: <90B6F372-B312-46F5-B9E8-9F4BAE547283@mnot.net> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 04:15:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/22/09 10:03 PM, Mark Nottingham wrote: > That works -- provided OAuth is completely proof against replay attacks. > > However, are new headers really necessary? I think not. > Reading in various places > about this issue, it seems like a common workaround is to use > mod_rewrite to expose the authorization header in the environment; e.g., > > RewriteEngine on > RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L] > > Isn't that enough to get the 80% case of those who have trouble with > getting direct access? Specifying two different headers to be used on > the wire will lead people to always use the more conservative one > (X-whatever, blech) and thereby lead us directly back into the situation > Eran's concerned about (intermediaries not realising that this is > protected content). The workaround for that will be having the header > duplicated, with both names (double blech). Blech blech blech. Going back to Eran's original message, he said: As currently written, OAuth use of the HTTP authentication headers is optional at best. The reason for that was based on concerns that some platforms do not provide access to the HTTP header in either the request or the reply. Do we have a sense of what those platforms are? Minimal HTTP clients of some kind? Do we really need to design around those, especially given that the alternatives seem to be unpalatable? Peter > > Cheers, > > > On 23/09/2009, at 1:46 AM, John Panzer wrote: > >> Inline... >> >> On Tuesday, September 22, 2009, Mark Nottingham wrote: >>> >>> On 22/09/2009, at 7:56 AM, John Panzer wrote: >>> >>> >>> On the server side, one of the concerns in the past has been security >>> in shared hosting systems where e.g., basic auth data should be >>> handled by a secure container (Apache) and not passed on in raw form >>> to hosted CGI scripts. So some of this comes back to what minimum >>> level of hosting should be targeted by the specification -- and how >>> much it should bend over backwards to deal with "challenged" >>> environments. >>> >>> >>> That's a good discussion to have. >>> >>> >>> My $.02 is that we should follow the HTTP spec (Authorization: and >>> WWW-Authenticate:) and take a minimum distance path to route around >>> limited environments if necessary (X-Authorization: and >>> X-WWW-Authenticate:, with exactly the same content, would be my >>> proposal). >>> >>> >>> Ugh. By allowing other resources on the same server to see >>> authentication credentials, wouldn't that just re-open these attacks? >>> >>> >> >> 1. Oauth, at least when accessing protected resources, is designed to >> be used over insecure connections, so the password sniffing attacks >> don't apply. >> >> 2. The alternative on the table is to pass these as URL params, which >> are more sniffable and also makes the web cry. >> >>> >>> >>> -- >>> John Panzer / Google >>> jpanzer@google.com / abstractioneer.org / @jpanzer >>> >>> >>> >>> On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav >>> wrote: >>> As currently written, OAuth use of the HTTP authentication headers is >>> optional at best. >>> >>> The reason for that was based on concerns that some platforms do not >>> provide access to the HTTP header in either the request or the reply. >>> However, this might have significant ramifications on caching and >>> other parts of HTTP where an indication of an authenticate >>> interaction is needed. >>> >>> Before the OAuth WG spends any time on discussing the various methods >>> of sending authentication parameters, I would like to find out if >>> using the authentication headers is more of a requirement for such a >>> protocol. >>> >>> EHL >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq5oTYACgkQNL8k5A2w/vzZ4ACgqgKa/CZSYJxQS1BuKf1ZOCDZ 1iUAoIVHMxNppDGq9smMLkFKB67x7I3z =ztVA -----END PGP SIGNATURE----- From jpanzer@google.com Tue Sep 22 21:19:20 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB87D3A6853 for ; Tue, 22 Sep 2009 21:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYjUby3k1cpi for ; Tue, 22 Sep 2009 21:19:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 21AD83A6844 for ; Tue, 22 Sep 2009 21:19:16 -0700 (PDT) Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id n8N4KL3O006157 for ; Wed, 23 Sep 2009 05:20:21 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1253679621; bh=ko5mTfN/zV4FiF7DmniGj43anVw=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:X-System-Of-Record; b=wKDL5j wPvH4IsI3y5DKO8Hp4SBCFXHUFQRfsGTgOAlRH+u/wprNyTkzS+lqwdnapYXzXma9c9 UxmeaKGqGWm/A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=mUsCqNg0MXG7wFH2fdRjtvJca3cmdxYnxuPDOkDWsmr8Pd1mt51Xzlt8bPf0+uNmZ lNjlBFrPXQHSOSEykDtTA== Received: from qw-out-1920.google.com (qwk4.prod.google.com [10.241.195.132]) by spaceape10.eur.corp.google.com with ESMTP id n8N4KDDX009942 for ; Tue, 22 Sep 2009 21:20:18 -0700 Received: by qw-out-1920.google.com with SMTP id 4so133383qwk.30 for ; Tue, 22 Sep 2009 21:20:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.10.229 with SMTP id q37mr734732qcq.106.1253679618306; Tue, 22 Sep 2009 21:20:18 -0700 (PDT) In-Reply-To: <90B6F372-B312-46F5-B9E8-9F4BAE547283@mnot.net> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <32C79DCD-0427-4253-98A0-1734BAB35C2D@mnot.net> <90B6F372-B312-46F5-B9E8-9F4BAE547283@mnot.net> From: John Panzer Date: Tue, 22 Sep 2009 21:19:58 -0700 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=0016364ed7dc4fb5260474370854 X-System-Of-Record: true Cc: "oauth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 04:19:20 -0000 --0016364ed7dc4fb5260474370854 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 22, 2009 at 9:03 PM, Mark Nottingham wrote: > That works -- provided OAuth is completely proof against replay attacks. > > However, are new headers really necessary? Reading in various places about > this issue, it seems like a common workaround is to use mod_rewrite to > expose the authorization header in the environment; e.g., > > RewriteEngine on > RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L] > > Isn't that enough to get the 80% case of those who have trouble with > getting direct access? Specifying two different headers to be used on the > wire will lead people to always use the more conservative one (X-whatever, > blech) and thereby lead us directly back into the situation Eran's concerned > about (intermediaries not realising that this is protected content). The > workaround for that will be having the header duplicated, with both names > (double blech). > Yes, if there is a way to just use the HTTP spec that would be vastly preferable. (You could send the X- headers only after an initial 401 failure, but that cure may be worse than the disease.) Cheers, > > > > On 23/09/2009, at 1:46 AM, John Panzer wrote: > > Inline... > > On Tuesday, September 22, 2009, Mark Nottingham wrote: > > > On 22/09/2009, at 7:56 AM, John Panzer wrote: > > > On the server side, one of the concerns in the past has been security in > shared hosting systems where e.g., basic auth data should be handled by a > secure container (Apache) and not passed on in raw form to hosted CGI > scripts. So some of this comes back to what minimum level of hosting should > be targeted by the specification -- and how much it should bend over > backwards to deal with "challenged" environments. > > > That's a good discussion to have. > > > My $.02 is that we should follow the HTTP spec (Authorization: and > WWW-Authenticate:) and take a minimum distance path to route around limited > environments if necessary (X-Authorization: and X-WWW-Authenticate:, with > exactly the same content, would be my proposal). > > > Ugh. By allowing other resources on the same server to see authentication > credentials, wouldn't that just re-open these attacks? > > > > 1. Oauth, at least when accessing protected resources, is designed to > be used over insecure connections, so the password sniffing attacks > don't apply. > > 2. The alternative on the table is to pass these as URL params, which > are more sniffable and also makes the web cry. > > > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > > On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav > wrote: > As currently written, OAuth use of the HTTP authentication headers is > optional at best. > > The reason for that was based on concerns that some platforms do not > provide access to the HTTP header in either the request or the reply. > However, this might have significant ramifications on caching and other > parts of HTTP where an indication of an authenticate interaction is needed. > > Before the OAuth WG spends any time on discussing the various methods of > sending authentication parameters, I would like to find out if using the > authentication headers is more of a requirement for such a protocol. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Mark Nottingham http://www.mnot.net/ > > > > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > > -- > Mark Nottingham http://www.mnot.net/ > > --0016364ed7dc4fb5260474370854 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 22, 2009 at 9:03 PM, Mark Nottingham <mnot@mnot.net> wrote:
That works -- provided OAuth is completely proof against replay attacks.
However, are new headers really necessary? Reading in various places about = this issue, it seems like a common workaround is to use mod_rewrite to expo= se the authorization header in the environment; e.g.,

RewriteEngine on
RewriteRule .* - [E=3DHTTP_AUTHORIZATION:%{HTTP:Authorization},L]

Isn't that enough to get the 80% case of those who have trouble with ge= tting direct access? Specifying two different headers to be used on the wir= e will lead people to always use the more conservative one (X-whatever, ble= ch) and thereby lead us directly back into the situation Eran's concern= ed about (intermediaries not realising that this is protected content). The= workaround for that will be having the header duplicated, with both names = (double blech).

Yes, if there is a way to just use the HTTP spec that= would be vastly preferable.=A0 (You could send the X- headers only after a= n initial 401 failure, but that cure may be worse than the disease.)

Cheers,



On 23/09/2009, at 1:46 AM, John Panzer wrote:

Inline...

On Tuesday, September 22, 2009, Mark Nottingham <mnot@mnot.net> wrote:

On 22/09/2009, at 7:56 AM, John Panzer wrote:


On the server side, one of the concerns in the past has been security in sh= ared hosting systems where e.g., basic auth data should be handled by a sec= ure container (Apache) and not passed on in raw form to hosted CGI scripts.= =A0So some of this comes back to what minimum level of hosting should be t= argeted by the specification -- and how much it should bend over backwards = to deal with "challenged" environments.


That's a good discussion to have.


My $.02 is that we should follow the HTTP spec (Authorization: and WWW-Auth= enticate:) and take a minimum distance path to route around limited environ= ments if necessary (X-Authorization: and X-WWW-Authenticate:, with exactly = the same content, would be my proposal).


Ugh. By allowing other resources on the same server to see authentication c= redentials, wouldn't that just re-open these attacks?



1. Oauth, at least when accessing protected resources, is designed to
be used over insecure connections, so the password sniffing attacks
don't apply.

2. The alternative on the table is to pass these as URL params, which
are more sniffable and also makes the web cry.



--
John Panzer / Google
jpanzer@google.com<= /a> / abstractionee= r.org / @jpanzer



On Mon, Sep 21, 2009 at 2:15 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
As currently written, OAuth use of the HTTP authentication headers is optio= nal at best.

The reason for that was based on concerns that some platforms do not provid= e access to the HTTP header in either the request or the reply. However, th= is might have significant ramifications on caching and other parts of HTTP = where an indication of an authenticate interaction is needed.

Before the OAuth WG spends any time on discussing the various methods of se= nding authentication parameters, I would like to find out if using the auth= entication headers is more of a requirement for such a protocol.

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




--
Mark Nottingham =A0 =A0 = http://www.mnot.net/



--
--
John Panzer / Google
jpanzer@google.com<= /a> / abstractionee= r.org / @jpanzer


--
Mark Nottingham =A0 =A0 = http://www.mnot.net/


--0016364ed7dc4fb5260474370854-- From stpeter@stpeter.im Wed Sep 23 07:02:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17163A690F for ; Wed, 23 Sep 2009 07:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiJqWj8GX0oj for ; Wed, 23 Sep 2009 07:02:10 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0A8943A68A0 for ; Wed, 23 Sep 2009 07:02:09 -0700 (PDT) Received: from squire.local (dsl-179-156.dynamic-dsl.frii.net [216.17.179.156]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DA0F74007B; Wed, 23 Sep 2009 08:03:15 -0600 (MDT) Message-ID: <4ABA2AA2.8070500@stpeter.im> Date: Wed, 23 Sep 2009 08:03:14 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343784D585AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D586D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D586D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:02:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/22/09 2:30 PM, Eran Hammer-Lahav wrote: > I have submitted a new version of the OAuth Core 1.0 draft: > > http://www.ietf.org/id/draft-hammer-oauth-03.txt > > This should be the last update to the 1.0 (based on revision A) > draft. This is NOT an working group item and is only submitted to > document the current protocol. Thanks. I think it is a good idea to codify existing practice in an informational RFC so that developers have a good, stable reference in the RFC series. Then we can continue moving ahead with the standards track work on "OAuth 1.1" or whatever we end up calling it. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq6KqIACgkQNL8k5A2w/vzBtQCfXkwiYD83UQMLG5wVFqKhG2ZW 8zoAnjC/YP9o0OEbO5dLFkxh1Uy1ZNkH =FLs3 -----END PGP SIGNATURE----- From James.H.Manger@team.telstra.com Wed Sep 23 07:27:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D233A6A0F for ; Wed, 23 Sep 2009 07:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIfk5VV5bjQ0 for ; Wed, 23 Sep 2009 07:27:12 -0700 (PDT) Received: from mailipao.vtcif.telstra.com.au (mailipao.vtcif.telstra.com.au [202.12.144.27]) by core3.amsl.com (Postfix) with ESMTP id 5B8E93A6A2B for ; Wed, 23 Sep 2009 07:27:12 -0700 (PDT) Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipai.vtcif.telstra.com.au with ESMTP; 24 Sep 2009 00:28:16 +1000 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 4B6421DA82 for ; Thu, 24 Sep 2009 00:28:16 +1000 (EST) Received: from WSMSG3751.srv.dir.telstra.com (wsmsg3751.srv.dir.telstra.com [172.49.40.172]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id AAA16788 for ; Thu, 24 Sep 2009 00:28:16 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 24 Sep 2009 00:28:15 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Thu, 24 Sep 2009 00:28:13 +1000 Thread-Topic: Publishing OAuth Core 1.0a as IETF Info RFC Thread-Index: Aco7nCiIjvct6ZYJSoWffwLsrp4qKgAJl8ogAA1MCKA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1122F17E78D@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343784D585AC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D586D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D586D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 14:27:13 -0000 SSBhZ3JlZSB0aGF0IHB1Ymxpc2hpbmcgT0F1dGggMS4wYSBhcyBhbiBJbmZvcm1hdGlvbmFsIFJG QyB3b3VsZCBiZSBoZWxwZnVsLg0KDQoNCkl0IG5lZWRzIGEgYml0IG1vcmUgdGV4dCBleHBsYWlu aW5nIHRoZSBoaXN0b3J5IGFuZCByZWxhdGlvbnNoaXAgdG8gdGhlIG9yaWdpbmFsIDEuMCBhbmQg MS4wYSBzcGVjcy4gVGhlIGFic3RyYWN0IHNheXMg4oCcdGhpcyBkb2N1bWVudCBpcyBiYXNlZCBv biByZXZpc2lvbiBBIG9mIHRoZSBjb21tdW5pdHkgc3BlY2lmaWNhdGlvbiBhbmQgaW5jbHVkZXMg YSBmZXcgY2xhcmlmaWNhdGlvbnPigJ0uIFRoZSBlbmQgb2YgdGhlIGludHJvZHVjdGlvbiBhZGRz IGEgYml0IG1vcmUgKOKAnFtbIFRoaXMgZHJhZnQgaXMgc3VibWl0dGVkIGZvciBpbmZvcm1hdGlv bmFsIHB1cnBvc2VzIHRvIGRvY3VtZW50IHRoZSBjdXJyZW50IHVzZSBvZiB0aGUgcHJvdG9jb2wu ICBJdCBpcyBub3QgYW4gaXRlbSBvZiB0aGUgT0FVVEggd29ya2luZyBncm91cOKApiBdXeKAnSks IGhvd2V2ZXIgdGhlIGJyYWNrZXRzIOKAnFtbIOKApiBdXeKAnSBzdWdnZXN0cyB0aGlzIHRleHQg d2lsbCBiZSByZW1vdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KUGVyaGFwcyBhIHBhcmFncmFw aCBsaWtlIHRoZSBmb2xsb3dpbmcgY291bGQgYmUgaW5jbHVkZWQgaW4gdGhlIGludHJvZHVjdGlv bi4gQWx0ZXJuYXRpdmVseSwgdGhlIGxpc3Qgb2YgNCBwcm90b2NvbCBjaGFuZ2VzIGluIEVyYW4n cyBlbWFpbCBjb3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgZG9jdW1lbnQuDQoNCuKAnFRoaXMgZG9j dW1lbnQgaXMgYmFzZWQgb24gdGhlIG9yaWdpbmFsIE9BdXRoIENvcmUgMS4wIGRvY3VtZW50IHB1 Ymxpc2hlZCBpbiBEZWNlbWJlciAyMDA3IGFuZCBSZXZpc2lvbiBBIChjb3JyZWN0aW5nIGEgc2Vz c2lvbiBmaXhhdGlvbiBhdHRhY2spIHB1Ymxpc2hlZCBpbiBKdW5lIDIwMDkgLS0gYm90aCBkZXZl bG9wZWQgYnkgdGhlIE9BdXRoIGNvbW11bml0eSAoaHR0cDovL29hdXRoLm5ldC8pLiBUaGUgY2hh bmdlcyBpbiB0aGlzIGRvY3VtZW50IGFyZSBwcmltYXJpbHkgZWRpdG9yaWFsOiBhIG1vcmUgc2Vu c2libGUgZG9jdW1lbnQgc3RydWN0dXJlIGFuZCBjbGVhcmVyIHRlcm1pbm9sb2d5LiBBIGZldyBl cnJhdGEgYXJlIGluY29ycG9yYXRlZCBpbiB0aGlzIGRvY3VtZW50IHJlZmxlY3RpbmcgaG93IGV4 aXN0aW5nIGltcGxlbWVudGF0aW9ucyB3b3JrLuKAnQ0KDQoNCkEgZmV3IG90aGVyIHN1Z2dlc3Rl ZCBjaGFuZ2VzOg0KDQpSZWFsbTogQXBwZW5kaXggQS4xLg0KQ2hhbmdlIHRoZSByZWFsbSBwYXJh bWV0ZXIgdmFsdWUgZnJvbSAiaHR0cDovL3Bob3Rvcy5leGFtcGxlLmNvbS8iIHRvLCBzYXksICJw aG90b3MiLg0KVGhlIGh0dHA6Ly9waG90b3MuLi4gdmFsdWUgaXMgdGhlIHNhbWUgYXMgdGhlIGV4 YW1wbGUgaW4gQ29yZSAxLjAgYW5kIFJldiBBLCBob3dldmVyIHRob3NlIGRvY3VtZW50cyB1c2Vk IGh0dHAgcmVxdWVzdHMsIHdoZXJlYXMgdGhpcyBkb2MgdXNlcyBodHRwcy4gQ29uc2VxdWVudGx5 IHRoZSBodHRwIHJlYWxtIGlzIG1pc2xlYWRpbmcuDQpUaGUgcmVhbG0gZG9lcyBub3QgaGF2ZSB0 byBiZSBhIFVSTCBhcyBpdHMgZGVmaW5pdGlvbiBpbiBSRkMgMjYxNyBzZWN0aW9uIDEuMiAod2hp Y2ggT0F1dGggcmVmZXJzIHRvKSBpcyBxdWl0ZSBjbGVhciB0aGF0IGEgcmVhbG0gdmFsdWUgaXMg Y29uc2lkZXJlZCAiaW4gY29tYmluYXRpb24gd2l0aCB0aGUgY2Fub25pY2FsIHJvb3QgVVJMIi4N Cg0KDQpFZGl0b3JpYWw6IEFwcGVuZGl4IEEuMg0KQ2hhbmdlICJKYW5lIGFwcHJvdmVzIHRoZSBy ZXF1ZXN0IGFuZCBpcyByZWRpcmVjdHMgaGVyIGJhY2sgdG8iDQpUbyAgICAgIkphbmUgYXBwcm92 ZXMgdGhlIHJlcXVlc3QgYW5kIGlzIHJlZGlyZWN0ZWQgYmFjayB0byINCg0KDQoNCkphbWVzIE1h bmdlcg0KSmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbQ0KSWRlbnRpdHkgYW5kIHNlY3Vy aXR5IHRlYW0g4oCUIENoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlIOKAlCBUZWxzdHJhDQoNCg== From eran@hueniverse.com Wed Sep 23 10:25:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC883A6924 for ; Wed, 23 Sep 2009 10:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.938 X-Spam-Level: X-Spam-Status: No, score=-3.938 tagged_above=-999 required=5 tests=[AWL=-1.340, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqLZ1tu11fC5 for ; Wed, 23 Sep 2009 10:25:09 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 8261B3A688D for ; Wed, 23 Sep 2009 10:25:09 -0700 (PDT) Received: (qmail 20922 invoked from network); 23 Sep 2009 17:26:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 23 Sep 2009 17:26:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 23 Sep 2009 10:23:53 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Wed, 23 Sep 2009 10:26:09 -0700 Thread-Topic: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC Thread-Index: Aco7nCiIjvct6ZYJSoWffwLsrp4qKgAJl8ogAA1MCKAAHs4jbQ== Message-ID: In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1122F17E78D@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6DFA841245D9eranhueniversecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 17:25:14 -0000 --_000_C6DFA841245D9eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is the new appendix with list of changes not enough? EHL On 9/23/09 7:28 AM, "Manger, James H" wro= te: I agree that publishing OAuth 1.0a as an Informational RFC would be helpful= . It needs a bit more text explaining the history and relationship to the ori= ginal 1.0 and 1.0a specs. The abstract says "this document is based on revi= sion A of the community specification and includes a few clarifications". T= he end of the introduction adds a bit more ("[[ This draft is submitted for= informational purposes to document the current use of the protocol. It is= not an item of the OAUTH working group... ]]"), however the brackets "[[ .= .. ]]" suggests this text will be removed before publication. Perhaps a paragraph like the following could be included in the introductio= n. Alternatively, the list of 4 protocol changes in Eran's email could be i= ncluded in the document. "This document is based on the original OAuth Core 1.0 document published i= n December 2007 and Revision A (correcting a session fixation attack) publi= shed in June 2009 -- both developed by the OAuth community (http://oauth.ne= t/). The changes in this document are primarily editorial: a more sensible = document structure and clearer terminology. A few errata are incorporated i= n this document reflecting how existing implementations work." A few other suggested changes: Realm: Appendix A.1. Change the realm parameter value from "http://photos.example.com/" to, say,= "photos". The http://photos... value is the same as the example in Core 1.0 and Rev A= , however those documents used http requests, whereas this doc uses https. = Consequently the http realm is misleading. The realm does not have to be a URL as its definition in RFC 2617 section 1= .2 (which OAuth refers to) is quite clear that a realm value is considered = "in combination with the canonical root URL". Editorial: Appendix A.2 Change "Jane approves the request and is redirects her back to" To "Jane approves the request and is redirected back to" James Manger James.H.Manger@team.telstra.com Identity and security team - Chief Technology Office - Telstra _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C6DFA841245D9eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC Is the new appendix with list of changes not enough?

EHL


On 9/23/09 7:28 AM, "Manger, James H" <James.H.Manger@team.telstra.com> wrote:

I agree that publishing OAuth 1.0a as an In= formational RFC would be helpful.


It needs a bit more text explaining the history and relationship to the ori= ginal 1.0 and 1.0a specs. The abstract says “this document is based o= n revision A of the community specification and includes a few clarificatio= ns”. The end of the introduction adds a bit more (“[[ This draf= t is submitted for informational purposes to document the current use of th= e protocol.  It is not an item of the OAUTH working group… ]]= 221;), however the brackets “[[ … ]]” suggests this text = will be removed before publication.

Perhaps a paragraph like the following could be included in the introductio= n. Alternatively, the list of 4 protocol changes in Eran's email could be i= ncluded in the document.

“This document is based on the original OAuth Core 1.0 document publi= shed in December 2007 and Revision A (correcting a session fixation attack)= published in June 2009 -- both developed by the OAuth community (http://oauth.net/). The changes in this document= are primarily editorial: a more sensible document structure and clearer te= rminology. A few errata are incorporated in this document reflecting how ex= isting implementations work.”


A few other suggested changes:

Realm: Appendix A.1.
Change the realm parameter value from "http://photos.example.com/" to, say, "photos". The http://photos... value is the same as t= he example in Core 1.0 and Rev A, however those documents used http request= s, whereas this doc uses https. Consequently the http realm is misleading.<= BR> The realm does not have to be a URL as its definition in RFC 2617 section 1= .2 (which OAuth refers to) is quite clear that a realm value is considered = "in combination with the canonical root URL".


Editorial: Appendix A.2
Change "Jane approves the request and is redirects her back to" To     "Jane approves the request and is redirecte= d back to"



James Manger
James.H.Manger@team.telstra.com=
Identity and security team — Chief Technology Office — Telstra<= BR>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C6DFA841245D9eranhueniversecom_-- From James.H.Manger@team.telstra.com Wed Sep 23 16:19:22 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514A33A6767 for ; Wed, 23 Sep 2009 16:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1Yjns+jppVz for ; Wed, 23 Sep 2009 16:19:21 -0700 (PDT) Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by core3.amsl.com (Postfix) with ESMTP id F3FEE3A6818 for ; Wed, 23 Sep 2009 16:19:20 -0700 (PDT) Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipbi.vtcif.telstra.com.au with ESMTP; 24 Sep 2009 09:19:24 +1000 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 8DB8A1DA85 for ; Thu, 24 Sep 2009 09:19:24 +1000 (EST) Received: from wsmsg3757.srv.dir.telstra.com (wsmsg3757.srv.dir.telstra.com [172.49.40.85]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id JAA29174 for ; Thu, 24 Sep 2009 09:19:24 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 24 Sep 2009 09:19:22 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Thu, 24 Sep 2009 09:19:20 +1000 Thread-Topic: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC Thread-Index: Aco7nCiIjvct6ZYJSoWffwLsrp4qKgAJl8ogAA1MCKAAHs4jbQAMHn/Q Message-ID: <255B9BB34FB7D647A506DC292726F6E1122F17E988@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1122F17E78D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1122F17E988WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 23:19:22 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1122F17E988WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gSXQgbmVlZHMgYSBiaXQgbW9yZSB0ZXh0IGV4cGxhaW5pbmcgdGhlIGhpc3RvcnkgYW5kIHJl bGF0aW9uc2hpcCB0byB0aGUgb3JpZ2luYWwgMS4wIGFuZCAxLjBhIHNwZWNzLg0KDQoNCg0KPiBJ cyB0aGUgbmV3IGFwcGVuZGl4IHdpdGggbGlzdCBvZiBjaGFuZ2VzIG5vdCBlbm91Z2g/DQoNCg0K DQoNCg0KSSBzYXcgdGhlIGxpc3Qgb2YgY2hhbmdlcyBpbiBBcHBlbmRpeCBEIOKAnERvY3VtZW50 IEhpc3RvcnnigJ0sIHdoaWNoIHdpbGwgYmUgcmVtb3ZlZCBiZWZvcmUgcHVibGljYXRpb24uDQoN CkkgaGFkbuKAmXQgbm90aWNlZCBBcHBlbmRpeCBCIOKAnERpZmZlcmVuY2VzIGZyb20gdGhlIENv bW11bml0eSBFZGl0aW9u4oCdLiBPcHBzLiBUaGF0IGlzIHN1ZmZpY2llbnQuDQoNCg0KDQpKYW1l cyBNYW5nZXINCkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208bWFpbHRvOkphbWVzLkgu TWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+DQpJZGVudGl0eSBhbmQgc2VjdXJpdHkgdGVhbSDigJQg Q2hpZWYgVGVjaG5vbG9neSBPZmZpY2Ug4oCUIFRlbHN0cmENCg0K --_000_255B9BB34FB7D647A506DC292726F6E1122F17E988WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHRpdGxl PlJlOiBbT0FVVEgtV0ddIFB1Ymxpc2hpbmcgT0F1dGggQ29yZSAxLjBhIGFzIElFVEYgSW5mbyBS RkM8L3RpdGxlPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMg NSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFo b21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LlNlY3Rp b24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPiZndDsmZ3Q7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J dCBuZWVkcyBhIGJpdCBtb3JlIHRleHQgZXhwbGFpbmluZyB0aGUgaGlzdG9yeSBhbmQgcmVsYXRp b25zaGlwIHRvIHRoZSBvcmlnaW5hbCAxLjAgYW5kIDEuMGEgc3BlY3MuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJcyB0aGUgbmV3IGFwcGVu ZGl4IHdpdGggbGlzdCBvZiBjaGFuZ2VzIG5vdCBlbm91Z2g/PGJyPg0KPGJyPg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi Pkkgc2F3IHRoZSBsaXN0IG9mIGNoYW5nZXMgaW4gQXBwZW5kaXggRCDigJxEb2N1bWVudCBIaXN0 b3J54oCdLCB3aGljaCB3aWxsIGJlIHJlbW92ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkkgaGFkbuKAmXQgbm90aWNlZCBBcHBlbmRpeCBCIOKA nERpZmZlcmVuY2VzIGZyb20gdGhlIENvbW11bml0eSBFZGl0aW9u4oCdLiBPcHBzLiBUaGF0IGlz IHN1ZmZpY2llbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SmFtZXMgTWFuZ2VyPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+DQo8YnI+DQo8YSBocmVmPSJtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVh bS50ZWxzdHJhLmNvbSI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkphbWVz LkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L3NwYW4+PC9hPg0KPGJyPg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5JZGVudGl0eSBhbmQgc2VjdXJp dHkgdGVhbTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCUPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+IENoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4gVGVsc3RyYTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_255B9BB34FB7D647A506DC292726F6E1122F17E988WSMSG3153Vsrv_-- From seth@mojodna.net Wed Sep 23 18:29:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C953A67AE for ; Wed, 23 Sep 2009 18:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGVEE9D+QOVm for ; Wed, 23 Sep 2009 18:29:19 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 43FBF3A67A3 for ; Wed, 23 Sep 2009 18:29:19 -0700 (PDT) Received: by pxi3 with SMTP id 3so1215621pxi.31 for ; Wed, 23 Sep 2009 18:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.13.19 with SMTP id q19mr182643rvi.31.1253755823207; Wed, 23 Sep 2009 18:30:23 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1122F17E78D@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 23 Sep 2009 18:30:23 -0700 Message-ID: <1d7d37050909231830n112403a8t55a362a7e9b7ee6@mail.gmail.com> From: Seth Fitzsimmons To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Publishing OAuth Core 1.0a as IETF Info RFC X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 01:29:20 -0000 > Is the new appendix with list of changes not enough? Thank you thank you thank you. Including such an appendix is immensely useful, even if the list of changes is minimal (in this case). seth From breno.demedeiros@gmail.com Thu Sep 24 09:46:51 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A0128C118 for ; Thu, 24 Sep 2009 09:46:51 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcZT50XHbor8 for ; Thu, 24 Sep 2009 09:46:49 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id 4C92C28C105 for ; Thu, 24 Sep 2009 09:46:49 -0700 (PDT) Received: by qyk33 with SMTP id 33so1553660qyk.29 for ; Thu, 24 Sep 2009 09:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=CzQmncm8KKUZExgd1PjlCWUqhr3uhGynLt5HeJ8QvG4=; b=Fh8AnuTUDUqhR57K3V6mwksBgb7BSxU7/F1em1hjfM4+e05MlIxBQl34/VDTptfltj 1wqPdulmB91anQnD6ds1ZbFvuDmXF6G2/RUkWO3JkM5qkhNc/a6Wna4Xn6n897QTbsDf pEBcEiMwoWvoA+yt261KwRUowwxwBqAW60Ni4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VoixnQTOVC/3XUTGZPmSHyhOK48j29wxLZfbc7pTlSypH/eoV/FsNvjE8y4879ExjZ zRJM+SwEK25BzSzckywISGbIHcwXv4qPBp1cDMrIeeK9SJSIkhvC9H2/u2Hs4IMmkc6R MIfzNaQ9lhZQh4UM3ymaB9APVXR7ULIK77MUU= MIME-Version: 1.0 Received: by 10.229.43.79 with SMTP id v15mr1659233qce.40.1253810874590; Thu, 24 Sep 2009 09:47:54 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 24 Sep 2009 09:47:54 -0700 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00148536e6dacba83e04745597c5 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 16:46:51 -0000 --00148536e6dacba83e04745597c5 Content-Type: text/plain; charset=ISO-8859-1 We should follow the SSL model where the cryptographic primitives are explicitly negotiated, or use discovery of the supported crypto primitives. It is no burden for libraries to support multiple ciphers (even dozens of them). If someone is rolling their own crypto to do OAuth that is VERY VERY BAD, and OAuth libraries will just include other crypto libraries that already support everything reasonable or not, and it is OpenSSL in many cases anyways. The difficulty with crypto is how to normalize the string to sign, not how to employ the crypto primitives. The spec needs to define how a client can find which algorithms the server support. The spec should not mandate algorithms, and if anything is to be said about algorithms, I would suggest that it be recommended that the existing schemes RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, using a grandfather clause. OAuth should not be in the business of certifying cryptography. That is a whole different industry. On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav wrote: > Yes, it is right there on my list of proposed changes I am seeking feedback > on. I think we need to pick one and make it required. > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Hubert Le Van Gong > > Sent: Tuesday, September 22, 2009 6:35 AM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Mandatory signature algorithms? > > > > Reading the latest draft I see we do not mandate a minimum set of > > signature algorithms. > > I think we should mandate a few (at least one) so we get a minimum of > > interoperability > > out of the box. > > Thoughts? > > > > Cheers, > > Hubert > > _______________________________________________ > > 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 > -- Breno de Medeiros --00148536e6dacba83e04745597c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We should follow the SSL model where the cryptographic primitives are expli= citly negotiated, or use discovery of the supported crypto primitives. It i= s no burden for libraries to support multiple ciphers (even dozens of them)= . If someone is rolling their own crypto to do OAuth that is VERY VERY BAD,= and OAuth libraries will just include other crypto libraries that already = support everything reasonable or not, and it is OpenSSL in many cases anywa= ys. The difficulty with crypto is how to normalize the string to sign, not = how to employ the crypto primitives.

The spec needs to define how a client can find which algorithms the ser= ver support.

The spec should not mandate algorithms, and if anything= is to be said about algorithms, I would suggest that it be recommended tha= t the existing schemes RSA-SHA1 and HMAC-SHA1 be supported for the next N y= ears, where N > 2, using a grandfather clause.

OAuth should not be in the business of certifying cryptography. That is= a whole different industry.


On Tue, = Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Yes, it is right = there on my list of proposed changes I am seeking feedback on. I think we n= eed to pick one and make it required.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of Hubert Le Van Gong
> Sent: Tuesday, September 22, 2009 6:35 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Mandatory signature algorithms?
>
> Reading the latest draft I see we do not mandate a minimum set of
> signature algorithms.
> I think we should mandate a few (at least one) so we get a minimum of<= br> > interoperability
> out of the box.
> Thoughts?
>
> Cheers,
> Hubert
> _______________________________________________
> 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



--
Breno de Me= deiros

--00148536e6dacba83e04745597c5-- From eran@hueniverse.com Thu Sep 24 10:47:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96993A68F8 for ; Thu, 24 Sep 2009 10:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.939 X-Spam-Level: X-Spam-Status: No, score=-3.939 tagged_above=-999 required=5 tests=[AWL=-1.341, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvTCjqpy-F13 for ; Thu, 24 Sep 2009 10:47:00 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9A4DE3A68C9 for ; Thu, 24 Sep 2009 10:47:00 -0700 (PDT) Received: (qmail 10716 invoked from network); 24 Sep 2009 17:48:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Sep 2009 17:48:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 24 Sep 2009 10:45:49 -0700 From: Eran Hammer-Lahav To: Breno Date: Thu, 24 Sep 2009 10:47:59 -0700 Thread-Topic: [OAUTH-WG] Mandatory signature algorithms? Thread-Index: Aco9NsQ4wdhDltWBTNCUZbUu+webSAACB+6g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343784D58B6BP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 17:47:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343784D58B6BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This goes against our goal of ensuring that any two OAuth compliant client/= server can interoperate. We must declare at least one algorithm for that. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, September 24, 2009 9:48 AM To: Eran Hammer-Lahav Cc: Hubert Le Van Gong; oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? We should follow the SSL model where the cryptographic primitives are expli= citly negotiated, or use discovery of the supported crypto primitives. It i= s no burden for libraries to support multiple ciphers (even dozens of them)= . If someone is rolling their own crypto to do OAuth that is VERY VERY BAD,= and OAuth libraries will just include other crypto libraries that already = support everything reasonable or not, and it is OpenSSL in many cases anywa= ys. The difficulty with crypto is how to normalize the string to sign, not = how to employ the crypto primitives. The spec needs to define how a client can find which algorithms the server = support. The spec should not mandate algorithms, and if anything is to be said about= algorithms, I would suggest that it be recommended that the existing schem= es RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, u= sing a grandfather clause. OAuth should not be in the business of certifying cryptography. That is a w= hole different industry. On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav > wrote: Yes, it is right there on my list of proposed changes I am seeking feedback= on. I think we need to pick one and make it required. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Hubert Le Van Gong > Sent: Tuesday, September 22, 2009 6:35 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Mandatory signature algorithms? > > Reading the latest draft I see we do not mandate a minimum set of > signature algorithms. > I think we should mandate a few (at least one) so we get a minimum of > interoperability > out of the box. > Thoughts? > > Cheers, > Hubert > _______________________________________________ > 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 -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E72343784D58B6BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This goes against our goal of ensuring that any two OAuth compliant client/server can interoperate. We must declare at least one algorithm for that.

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, September 24, 2009 9:48 AM
To: Eran Hammer-Lahav
Cc: Hubert Le Van Gong; oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

 

We should follow the SS= L model where the cryptographic primitives are explicitly negotiated, or use discov= ery of the supported crypto primitives. It is no burden for libraries to suppor= t multiple ciphers (even dozens of them). If someone is rolling their own cry= pto to do OAuth that is VERY VERY BAD, and OAuth libraries will just include ot= her crypto libraries that already support everything reasonable or not, and it = is OpenSSL in many cases anyways. The difficulty with crypto is how to normali= ze the string to sign, not how to employ the crypto primitives.

The spec needs to define how a client can find which algorithms the server support.

The spec should not mandate algorithms, and if anything is to be said about algorithms, I would suggest that it be recommended that the existing scheme= s RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, u= sing a grandfather clause.

OAuth should not be in the business of certifying cryptography. That is a w= hole different industry.

On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:=

Yes, it is right there on my list of proposed changes = I am seeking feedback on. I think we need to pick one and make it required.

EHL


> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.org] On Behalf
> Of Hubert Le Van Gong
> Sent: Tuesday, September 22, 2009 6:35 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Mandatory signature algorithms?
>
> Reading the latest draft I see we do not mandate a minimum set of
> signature algorithms.
> I think we should mandate a few (at least one) so we get a minimum of<= br> > interoperability
> out of the box.
> Thoughts?
>
> Cheers,
> Hubert
> _______________________________________________
> 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




--
Breno de Medeiros

--_000_90C41DD21FB7C64BB94121FBBC2E72343784D58B6BP3PW5EX1MB01E_-- From eran@hueniverse.com Thu Sep 24 10:54:20 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B3E43A6407 for ; Thu, 24 Sep 2009 10:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.914 X-Spam-Level: X-Spam-Status: No, score=-3.914 tagged_above=-999 required=5 tests=[AWL=-1.315, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xApoDI1zLcmc for ; Thu, 24 Sep 2009 10:54:19 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3505E3A6814 for ; Thu, 24 Sep 2009 10:54:19 -0700 (PDT) Received: (qmail 18606 invoked from network); 24 Sep 2009 17:55:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Sep 2009 17:55:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 24 Sep 2009 10:55:25 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 24 Sep 2009 10:55:17 -0700 Thread-Topic: [OAUTH-WG] OAuth and HTTP caching Thread-Index: Aco7rNVqs0aKc96FSmexLq/eIWy2wABkocNA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58B72@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58619@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: "Roy T. Fielding" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 17:54:20 -0000 This means that we really only have two options: 1. Use only the HTTP Authorization header to pass authentication parameters= from the client to the server. This means dropping support for URI query p= arameters and form-encoded body parameters. 2. Drop support for form-encoded parameters, recommend using HTTP headers o= r require additional headers when using URI query parameters. Of course, #2 defeats the purpose because the only reason to keep URI query= parameters is to avoid the need to set headers... Are there any *documented* reasons why we should not just limit OAuth to tr= ansmit parameters over HTTP Authorization headers? EHL > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@gbiv.com] > Sent: Tuesday, September 22, 2009 10:48 AM > To: Eran Hammer-Lahav > Cc: John Panzer; oauth@ietf.org; ietf-http-wg@w3.org Group > Subject: Re: [OAUTH-WG] OAuth and HTTP caching >=20 > On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: >=20 > >> -----Original Message----- > >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > >> Sent: Tuesday, September 22, 2009 10:09 AM > > > >> Just follow the HTTP spec. > > > > That what I am trying to figure out... > > > > Does the HTTP spec mandates that new authentication protocols use > > the WWW-Authenticate and Authorization headers? >=20 > HTTP is not aware of any other kinds of authentication. There is no > reason > to specify anything else. >=20 > > Are the headers required for existing caches and servers to operate > > properly? >=20 > Yes (and for user agents as well). Don't forget about Proxy-Auth*. >=20 > > If they are not included in authenticated requests, are there other > > requirements to make sure it doesn't break existing deployment? >=20 > Cache-control: private >=20 > is probably needed if the Auth headers are not being used but the > response depends on something like cookies for authentication. >=20 > ....Roy From esjewett@gmail.com Thu Sep 24 11:02:43 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972E728C16A for ; Thu, 24 Sep 2009 11:02:43 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjcZg7abyQIC for ; Thu, 24 Sep 2009 11:02:42 -0700 (PDT) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by core3.amsl.com (Postfix) with ESMTP id B1C2C3A6891 for ; Thu, 24 Sep 2009 11:02:42 -0700 (PDT) Received: by pxi13 with SMTP id 13so2060557pxi.6 for ; Thu, 24 Sep 2009 11:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=JQ6HPzAvMnbiOd1wgK2JnHkRj1OPfRNm4U8leoO3NAo=; b=srXNsd9fWQ6mR2sruGdTACokrFFr3UFRre38Ljlkr8uRuwJhSUmw3SUKNJ+74wdxIt WFrED0BNCWBBVFGKJu9b465SPcVyhtgwloJzEXi43UfUIyUCDvXoPF5aKC4Not2Q39ga niJq33xbeKTLgnB1RYKIl41h4vqQHXO+d7B5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Vzui10ZW2kSJo8ikSdNhABECKDN7F2LibWgGErcgG7Z/PglRG3vFUDb0amCyq3hfCQ PQ5F9B/TmKsInMz6eB3EZl5vtTRT+A7JR7gKWp7jJu3aXKw6QgPtAHJhBhdpLitER6vo dmVkQ11CgHDUHGP5s9l2qOs3hX07tRULvZVhE= MIME-Version: 1.0 Received: by 10.140.165.7 with SMTP id n7mr220620rve.182.1253815428394; Thu, 24 Sep 2009 11:03:48 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58B72@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B72@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 24 Sep 2009 14:03:48 -0400 Message-ID: <68f4a0e80909241103v4d3bffacyed7e74efe6922d00@mail.gmail.com> From: Ethan Jewett To: "oauth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:02:43 -0000 Thinking back ... wasn't one of the primary reasons for having a way to pass the authentication parameters that didn't involve the headers because in-browser javascript doesn't have access to the headers? Now, I don't think there are a lot of applications currently using OAuth to authenticate an in-browser client application directly to a server, but with the advent of mechanisms for cross-domain requests in HTML5 and through hacks like iFrame proxies, this might become more common. If we require authorization headers are we precluding the use of OAuth on the browser platform? Ethan On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav wr= ote: > This means that we really only have two options: > > 1. Use only the HTTP Authorization header to pass authentication paramete= rs from the client to the server. This means dropping support for URI query= parameters and form-encoded body parameters. > 2. Drop support for form-encoded parameters, recommend using HTTP headers= or require additional headers when using URI query parameters. > > Of course, #2 defeats the purpose because the only reason to keep URI que= ry parameters is to avoid the need to set headers... > > Are there any *documented* reasons why we should not just limit OAuth to = transmit parameters over HTTP Authorization headers? > > EHL > >> -----Original Message----- >> From: Roy T. Fielding [mailto:fielding@gbiv.com] >> Sent: Tuesday, September 22, 2009 10:48 AM >> To: Eran Hammer-Lahav >> Cc: John Panzer; oauth@ietf.org; ietf-http-wg@w3.org Group >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching >> >> On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: >> >> >> -----Original Message----- >> >> From: Roy T. Fielding [mailto:fielding@gbiv.com] >> >> Sent: Tuesday, September 22, 2009 10:09 AM >> > >> >> Just follow the HTTP spec. >> > >> > That what I am trying to figure out... >> > >> > Does the HTTP spec mandates that new authentication protocols use >> > the WWW-Authenticate and Authorization headers? >> >> HTTP is not aware of any other kinds of authentication. =A0There is no >> reason >> to specify anything else. >> >> > Are the headers required for existing caches and servers to operate >> > properly? >> >> Yes (and for user agents as well). =A0Don't forget about Proxy-Auth*. >> >> > If they are not included in authenticated requests, are there other >> > requirements to make sure it doesn't break existing deployment? >> >> Cache-control: private >> >> is probably needed if the Auth headers are not being used but the >> response depends on something like cookies for authentication. >> >> ....Roy > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Sep 24 11:23:04 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163183A694E for ; Thu, 24 Sep 2009 11:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.89 X-Spam-Level: X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[AWL=-1.291, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBZSNrsWu-Yq for ; Thu, 24 Sep 2009 11:23:03 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 281BC3A68E8 for ; Thu, 24 Sep 2009 11:23:03 -0700 (PDT) Received: (qmail 18132 invoked from network); 24 Sep 2009 18:24:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Sep 2009 18:24:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 24 Sep 2009 11:24:09 -0700 From: Eran Hammer-Lahav To: Ethan Jewett , "oauth@ietf.org" Date: Thu, 24 Sep 2009 11:24:00 -0700 Thread-Topic: [OAUTH-WG] OAuth and HTTP caching Thread-Index: Aco9QWFv74kGAqEaQ8iDn5Xnt74rvQAAopTQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58B9F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B72@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80909241103v4d3bffacyed7e74efe6922d00@mail.gmail.com> In-Reply-To: <68f4a0e80909241103v4d3bffacyed7e74efe6922d00@mail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:23:04 -0000 No, we are simply sending a message to browser vendors that they should add= native support. It is one thing when a small community comes out with a sp= ec and a whole other thing when the IETF publishes a new internet standard. Also, the fact that we will have the 1.0 spec published as an information R= FC will help because it will give an alternative to this new work in cases = where it is not possible to implement. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Ethan Jewett > Sent: Thursday, September 24, 2009 11:04 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth and HTTP caching >=20 > Thinking back ... wasn't one of the primary reasons for having a way > to pass the authentication parameters that didn't involve the headers > because in-browser javascript doesn't have access to the headers? >=20 > Now, I don't think there are a lot of applications currently using > OAuth to authenticate an in-browser client application directly to a > server, but with the advent of mechanisms for cross-domain requests in > HTML5 and through hacks like iFrame proxies, this might become more > common. If we require authorization headers are we precluding the use > of OAuth on the browser platform? >=20 > Ethan >=20 > On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav > wrote: > > This means that we really only have two options: > > > > 1. Use only the HTTP Authorization header to pass authentication > parameters from the client to the server. This means dropping support > for URI query parameters and form-encoded body parameters. > > 2. Drop support for form-encoded parameters, recommend using HTTP > headers or require additional headers when using URI query parameters. > > > > Of course, #2 defeats the purpose because the only reason to keep URI > query parameters is to avoid the need to set headers... > > > > Are there any *documented* reasons why we should not just limit OAuth > to transmit parameters over HTTP Authorization headers? > > > > EHL > > > >> -----Original Message----- > >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > >> Sent: Tuesday, September 22, 2009 10:48 AM > >> To: Eran Hammer-Lahav > >> Cc: John Panzer; oauth@ietf.org; ietf-http-wg@w3.org Group > >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching > >> > >> On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: > >> > >> >> -----Original Message----- > >> >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > >> >> Sent: Tuesday, September 22, 2009 10:09 AM > >> > > >> >> Just follow the HTTP spec. > >> > > >> > That what I am trying to figure out... > >> > > >> > Does the HTTP spec mandates that new authentication protocols use > >> > the WWW-Authenticate and Authorization headers? > >> > >> HTTP is not aware of any other kinds of authentication. =A0There is no > >> reason > >> to specify anything else. > >> > >> > Are the headers required for existing caches and servers to > operate > >> > properly? > >> > >> Yes (and for user agents as well). =A0Don't forget about Proxy-Auth*. > >> > >> > If they are not included in authenticated requests, are there > other > >> > requirements to make sure it doesn't break existing deployment? > >> > >> Cache-control: private > >> > >> is probably needed if the Auth headers are not being used but the > >> response depends on something like cookies for authentication. > >> > >> ....Roy > > > > _______________________________________________ > > 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 jthelin@microsoft.com Thu Sep 24 11:28:04 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D113A67BD for ; Thu, 24 Sep 2009 11:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD18tWO5WCxV for ; Thu, 24 Sep 2009 11:27:58 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 713B23A6816 for ; Thu, 24 Sep 2009 11:27:58 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 24 Sep 2009 11:29:07 -0700 Received: from TK5EX14MBXC120.redmond.corp.microsoft.com ([169.254.11.164]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi; Thu, 24 Sep 2009 11:29:06 -0700 From: Jorgen Thelin To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Mandatory signature algorithms? Thread-Index: AQHKO4mbyYPsewRfOkOeV+RWk45DCJDjLmwAgAM9XwCAABDJgP//jQfQ Date: Thu, 24 Sep 2009 18:28:17 +0000 Message-ID: <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3628627928A9154A9556BAD87E30C6F4025265B5TK5EX14MBXC120r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:28:04 -0000 --_000_3628627928A9154A9556BAD87E30C6F4025265B5TK5EX14MBXC120r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Which one would we choose, Eran? This group is not set up to be crypto exp= erts, so we should not be in the business of recommending one universal cry= pto algorithm - which is effectively what we would be doing if we declared = any mandatory algorithm(s). The choice of crypto algorithm will always depends on the specific scenario= , and will also evolve over time (years, not necessarily months). The goal of a wire protocol should be to support "crypto agility" - i.e. th= e ability to somehow specify which algorithm is being used, and drop in new= ones if/when necessary, rather than baking that choice into the core proto= col spec itself. I completely agree with Breno - this question nets out to a "discovery" pro= blem for this WG to solve, and definitely not an "algorithm choice" problem= . From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, September 24, 2009 10:48 AM To: Breno Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? This goes against our goal of ensuring that any two OAuth compliant client/= server can interoperate. We must declare at least one algorithm for that. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, September 24, 2009 9:48 AM To: Eran Hammer-Lahav Cc: Hubert Le Van Gong; oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? We should follow the SSL model where the cryptographic primitives are expli= citly negotiated, or use discovery of the supported crypto primitives. It i= s no burden for libraries to support multiple ciphers (even dozens of them)= . If someone is rolling their own crypto to do OAuth that is VERY VERY BAD,= and OAuth libraries will just include other crypto libraries that already = support everything reasonable or not, and it is OpenSSL in many cases anywa= ys. The difficulty with crypto is how to normalize the string to sign, not = how to employ the crypto primitives. The spec needs to define how a client can find which algorithms the server = support. The spec should not mandate algorithms, and if anything is to be said about= algorithms, I would suggest that it be recommended that the existing schem= es RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, u= sing a grandfather clause. OAuth should not be in the business of certifying cryptography. That is a w= hole different industry. On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav > wrote: Yes, it is right there on my list of proposed changes I am seeking feedback= on. I think we need to pick one and make it required. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Hubert Le Van Gong > Sent: Tuesday, September 22, 2009 6:35 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Mandatory signature algorithms? > > Reading the latest draft I see we do not mandate a minimum set of > signature algorithms. > I think we should mandate a few (at least one) so we get a minimum of > interoperability > out of the box. > Thoughts? > > Cheers, > Hubert > _______________________________________________ > 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 -- Breno de Medeiros --_000_3628627928A9154A9556BAD87E30C6F4025265B5TK5EX14MBXC120r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Which one would we choose, Eran?  This group is not set= up to be crypto experts, so we should not be in the business of recommending o= ne universal crypto algorithm – which is effectively what we would be do= ing if we declared any mandatory algorithm(s).

 

The choice of crypto algorithm will always depends on the sp= ecific scenario, and will also evolve over time (years, not necessarily months).

 

The goal of a wire protocol should be to support “cryp= to agility” – i.e. the ability to somehow specify which algorithm = is being used, and drop in new ones if/when necessary, rather than baking that= choice into the core protocol spec itself.

 

I completely agree with Breno – this question nets out= to a “discovery” problem for this WG to solve, and definitely not an= “algorithm choice” problem.

 

 

From: oauth-bounces= @ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, September 24, 2009 10:48 AM
To: Breno
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

 

This goes against our goal of ensuring that any two OAuth compliant client/server can interoperate. We must declare at least one algorithm for that.

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, September 24, 2009 9:48 AM
To: Eran Hammer-Lahav
Cc: Hubert Le Van Gong; oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

 

We should follow the SS= L model where the cryptographic primitives are explicitly negotiated, or use discov= ery of the supported crypto primitives. It is no burden for libraries to suppor= t multiple ciphers (even dozens of them). If someone is rolling their own cry= pto to do OAuth that is VERY VERY BAD, and OAuth libraries will just include ot= her crypto libraries that already support everything reasonable or not, and it = is OpenSSL in many cases anyways. The difficulty with crypto is how to normali= ze the string to sign, not how to employ the crypto primitives.

The spec needs to define how a client can find which algorithms the server support.

The spec should not mandate algorithms, and if anything is to be said about algorithms, I would suggest that it be recommended that the existing scheme= s RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, u= sing a grandfather clause.

OAuth should not be in the business of certifying cryptography. That is a w= hole different industry.

On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:=

Yes, it is right there on my list of proposed changes = I am seeking feedback on. I think we need to pick one and make it required.

EHL


> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.org] On Behalf
> Of Hubert Le Van Gong
> Sent: Tuesday, September 22, 2009 6:35 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Mandatory signature algorithms?
>
> Reading the latest draft I see we do not mandate a minimum set of
> signature algorithms.
> I think we should mandate a few (at least one) so we get a minimum of<= br> > interoperability
> out of the box.
> Thoughts?
>
> Cheers,
> Hubert
> _______________________________________________
> 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




--
Breno de Medeiros

--_000_3628627928A9154A9556BAD87E30C6F4025265B5TK5EX14MBXC120r_-- From eran@hueniverse.com Thu Sep 24 11:36:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08B7D28C17A for ; Thu, 24 Sep 2009 11:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[AWL=-1.268, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoWfsvlr-Gqh for ; Thu, 24 Sep 2009 11:36:18 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BA77F3A6A45 for ; Thu, 24 Sep 2009 11:36:18 -0700 (PDT) Received: (qmail 26173 invoked from network); 24 Sep 2009 18:37:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 24 Sep 2009 18:37:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 24 Sep 2009 11:34:56 -0700 From: Eran Hammer-Lahav To: Jorgen Thelin , "oauth@ietf.org" Date: Thu, 24 Sep 2009 11:36:59 -0700 Thread-Topic: [OAUTH-WG] Mandatory signature algorithms? Thread-Index: AQHKO4mbyYPsewRfOkOeV+RWk45DCJDjLmwAgAM9XwCAABDJgP//jQfQgAAJsBA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> In-Reply-To: <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.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_90C41DD21FB7C64BB94121FBBC2E72343784D58BAEP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:36:26 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343784D58BAEP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But the IETF is set up to provide crypto expertise. RFC 2617 had no problem= providing two algorithms and allowing extensibility. I disagree that we cannot find a reasonable crypto algorithm for normal web= usage that can be made obsolete when needed. We did it with HMAC-SHA1 in 1= .0 and we should be doing it again in this new effort. If we do not guarant= ee interoperability and provide clear guidance on security for the majority= of developers who are not experts, what's the point? EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= orgen Thelin Sent: Thursday, September 24, 2009 11:28 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? Which one would we choose, Eran? This group is not set up to be crypto exp= erts, so we should not be in the business of recommending one universal cry= pto algorithm - which is effectively what we would be doing if we declared = any mandatory algorithm(s). The choice of crypto algorithm will always depends on the specific scenario= , and will also evolve over time (years, not necessarily months). The goal of a wire protocol should be to support "crypto agility" - i.e. th= e ability to somehow specify which algorithm is being used, and drop in new= ones if/when necessary, rather than baking that choice into the core proto= col spec itself. I completely agree with Breno - this question nets out to a "discovery" pro= blem for this WG to solve, and definitely not an "algorithm choice" problem= . From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, September 24, 2009 10:48 AM To: Breno Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? This goes against our goal of ensuring that any two OAuth compliant client/= server can interoperate. We must declare at least one algorithm for that. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Thursday, September 24, 2009 9:48 AM To: Eran Hammer-Lahav Cc: Hubert Le Van Gong; oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? We should follow the SSL model where the cryptographic primitives are expli= citly negotiated, or use discovery of the supported crypto primitives. It i= s no burden for libraries to support multiple ciphers (even dozens of them)= . If someone is rolling their own crypto to do OAuth that is VERY VERY BAD,= and OAuth libraries will just include other crypto libraries that already = support everything reasonable or not, and it is OpenSSL in many cases anywa= ys. The difficulty with crypto is how to normalize the string to sign, not = how to employ the crypto primitives. The spec needs to define how a client can find which algorithms the server = support. The spec should not mandate algorithms, and if anything is to be said about= algorithms, I would suggest that it be recommended that the existing schem= es RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, u= sing a grandfather clause. OAuth should not be in the business of certifying cryptography. That is a w= hole different industry. On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav > wrote: Yes, it is right there on my list of proposed changes I am seeking feedback= on. I think we need to pick one and make it required. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Hubert Le Van Gong > Sent: Tuesday, September 22, 2009 6:35 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Mandatory signature algorithms? > > Reading the latest draft I see we do not mandate a minimum set of > signature algorithms. > I think we should mandate a few (at least one) so we get a minimum of > interoperability > out of the box. > Thoughts? > > Cheers, > Hubert > _______________________________________________ > 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 -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E72343784D58BAEP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

But the IETF is set up to provide crypto expertise. RFC 2617= had no problem providing two algorithms and allowing extensibility.<= /span>

 

I disagree that we cannot find a reasonable crypto algorithm= for normal web usage that can be made obsolete when needed. We did it with HMAC-SHA1 in 1.0 and we should be doing it again in this new effort. If we = do not guarantee interoperability and provide clear guidance on security for t= he majority of developers who are not experts, what’s the point?

 

EHL

 

From: oauth-bounces= @ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Jorgen Thelin
Sent: Thursday, September 24, 2009 11:28 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

 

Which one would we choose, Eran?  This group is not set= up to be crypto experts, so we should not be in the business of recommending o= ne universal crypto algorithm – which is effectively what we would be do= ing if we declared any mandatory algorithm(s).

 

The choice of crypto algorithm will always depends on the specific scenario, and will also evolve over time (years, not necessarily months).

 

The goal of a wire protocol should be to support “cryp= to agility” – i.e. the ability to somehow specify which algorithm = is being used, and drop in new ones if/when necessary, rather than baking that choice into the core protocol spec itself.

 

I completely agree with Breno – this question nets out= to a “discovery” problem for this WG to solve, and definitely not = an “algorithm choice” problem.

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Thursday, September 24, 2009 10:48 AM
To: Breno
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

 

This goes against our goal of ensuring that any two OAuth compliant client/server can interoperate. We must declare at least one algorithm for that.

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Thursday, September 24, 2009 9:48 AM
To: Eran Hammer-Lahav
Cc: Hubert Le Van Gong; oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

 

We should follow the SS= L model where the cryptographic primitives are explicitly negotiated, or use discov= ery of the supported crypto primitives. It is no burden for libraries to suppor= t multiple ciphers (even dozens of them). If someone is rolling their own cry= pto to do OAuth that is VERY VERY BAD, and OAuth libraries will just include ot= her crypto libraries that already support everything reasonable or not, and it = is OpenSSL in many cases anyways. The difficulty with crypto is how to normali= ze the string to sign, not how to employ the crypto primitives.

The spec needs to define how a client can find which algorithms the server support.

The spec should not mandate algorithms, and if anything is to be said about algorithms, I would suggest that it be recommended that the existing scheme= s RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, u= sing a grandfather clause.

OAuth should not be in the business of certifying cryptography. That is a w= hole different industry.

On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:=

Yes, it is right there on my list of proposed changes = I am seeking feedback on. I think we need to pick one and make it required.

EHL


> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.org] On Behalf
> Of Hubert Le Van Gong
> Sent: Tuesday, September 22, 2009 6:35 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Mandatory signature algorithms?
>
> Reading the latest draft I see we do not mandate a minimum set of
> signature algorithms.
> I think we should mandate a few (at least one) so we get a minimum of<= br> > interoperability
> out of the box.
> Thoughts?
>
> Cheers,
> Hubert
> _______________________________________________
> 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




--
Breno de Medeiros

--_000_90C41DD21FB7C64BB94121FBBC2E72343784D58BAEP3PW5EX1MB01E_-- From esjewett@gmail.com Thu Sep 24 11:50:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997713A68A0 for ; Thu, 24 Sep 2009 11:50:59 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3k91SBLCYZP for ; Thu, 24 Sep 2009 11:50:58 -0700 (PDT) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by core3.amsl.com (Postfix) with ESMTP id A6E303A67AF for ; Thu, 24 Sep 2009 11:50:58 -0700 (PDT) Received: by pxi13 with SMTP id 13so2116590pxi.6 for ; Thu, 24 Sep 2009 11:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2OAdcdu7q7L0vjWUuG4keIxHCGuipU2FpdZOoHj8GqM=; b=naeJcUKkGWEez+bEAdJVHR425p5e/ruWv3s9uE/LcERHruleeFmiLDw4D3T4U8Pzgh 9lwpkKAJhjc+9HAafjURL5QOArFBOZhurqGH3c29yBfV44fH9XLIbTbc0z3ZazoZtmTD bDk99D2qDaZ/V8XU6U+efVHN0lBbmNI8kv1Ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=v7EwYJkpF+ZgRJpi8ecjOQQGr2Hcxq5IoQ9OAAh6W5ru0CPJbaCmR1mDA+xdw2l7x5 EhTna9MFUnHNulM/mj+a4eO8Td49bZL4rWZsITUzQNGj1hlVm2RyCPB0PagSlbUP+vHz MTplZo8g807X6Vbe4RNmIYMFHEBAoa3gvtN88= MIME-Version: 1.0 Received: by 10.140.165.7 with SMTP id n7mr224322rve.182.1253818325295; Thu, 24 Sep 2009 11:52:05 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58B9F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B72@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80909241103v4d3bffacyed7e74efe6922d00@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58B9F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 24 Sep 2009 14:52:05 -0400 Message-ID: <68f4a0e80909241152m207f9f40ob017ece2facb36b4@mail.gmail.com> From: Ethan Jewett To: Eran Hammer-Lahav , "oauth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 18:50:59 -0000 In that case I can't think of another reason not to simply go with the standard headers and drop the URL and form-encoded options. Ethan On Thu, Sep 24, 2009 at 2:24 PM, Eran Hammer-Lahav wr= ote: > No, we are simply sending a message to browser vendors that they should a= dd native support. It is one thing when a small community comes out with a = spec and a whole other thing when the IETF publishes a new internet standar= d. > > Also, the fact that we will have the 1.0 spec published as an information= RFC will help because it will give an alternative to this new work in case= s where it is not possible to implement. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Ethan Jewett >> Sent: Thursday, September 24, 2009 11:04 AM >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching >> >> Thinking back ... wasn't one of the primary reasons for having a way >> to pass the authentication parameters that didn't involve the headers >> because in-browser javascript doesn't have access to the headers? >> >> Now, I don't think there are a lot of applications currently using >> OAuth to authenticate an in-browser client application directly to a >> server, but with the advent of mechanisms for cross-domain requests in >> HTML5 and through hacks like iFrame proxies, this might become more >> common. If we require authorization headers are we precluding the use >> of OAuth on the browser platform? >> >> Ethan >> >> On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav >> wrote: >> > This means that we really only have two options: >> > >> > 1. Use only the HTTP Authorization header to pass authentication >> parameters from the client to the server. This means dropping support >> for URI query parameters and form-encoded body parameters. >> > 2. Drop support for form-encoded parameters, recommend using HTTP >> headers or require additional headers when using URI query parameters. >> > >> > Of course, #2 defeats the purpose because the only reason to keep URI >> query parameters is to avoid the need to set headers... >> > >> > Are there any *documented* reasons why we should not just limit OAuth >> to transmit parameters over HTTP Authorization headers? >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: Roy T. Fielding [mailto:fielding@gbiv.com] >> >> Sent: Tuesday, September 22, 2009 10:48 AM >> >> To: Eran Hammer-Lahav >> >> Cc: John Panzer; oauth@ietf.org; ietf-http-wg@w3.org Group >> >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching >> >> >> >> On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: >> >> >> >> >> -----Original Message----- >> >> >> From: Roy T. Fielding [mailto:fielding@gbiv.com] >> >> >> Sent: Tuesday, September 22, 2009 10:09 AM >> >> > >> >> >> Just follow the HTTP spec. >> >> > >> >> > That what I am trying to figure out... >> >> > >> >> > Does the HTTP spec mandates that new authentication protocols use >> >> > the WWW-Authenticate and Authorization headers? >> >> >> >> HTTP is not aware of any other kinds of authentication. =A0There is n= o >> >> reason >> >> to specify anything else. >> >> >> >> > Are the headers required for existing caches and servers to >> operate >> >> > properly? >> >> >> >> Yes (and for user agents as well). =A0Don't forget about Proxy-Auth*. >> >> >> >> > If they are not included in authenticated requests, are there >> other >> >> > requirements to make sure it doesn't break existing deployment? >> >> >> >> Cache-control: private >> >> >> >> is probably needed if the Auth headers are not being used but the >> >> response depends on something like cookies for authentication. >> >> >> >> ....Roy >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From GFFletch@aol.com Thu Sep 24 12:08:24 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4FA3A6975 for ; Thu, 24 Sep 2009 12:08:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQOZ6LQXfKs1 for ; Thu, 24 Sep 2009 12:08:23 -0700 (PDT) Received: from imr-mb01.mx.aol.com (imr-mb01.mx.aol.com [64.12.207.164]) by core3.amsl.com (Postfix) with ESMTP id 0265C3A69F5 for ; Thu, 24 Sep 2009 12:08:22 -0700 (PDT) Received: from imo-da01.mx.aol.com (imo-da01.mx.aol.com [205.188.169.199]) by imr-mb01.mx.aol.com (8.14.1/8.14.1) with ESMTP id n8OJ9AIE013172; Thu, 24 Sep 2009 15:09:10 -0400 Received: from GFFletch@aol.com by imo-da01.mx.aol.com (mail_out_v42.5.) id 7.d28.52f3e7a2 (43906); Thu, 24 Sep 2009 15:09:07 -0400 (EDT) Received: from palantir-2.local ([10.172.3.58]) by cia-dc07.mx.aol.com (v125.7) with ESMTP id MAILCIADC073-ab824abbc3b410e; Thu, 24 Sep 2009 15:09:06 -0400 Message-ID: <4ABBC3B4.9040504@aol.com> Date: Thu, 24 Sep 2009 15:08:36 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B72@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80909241103v4d3bffacyed7e74efe6922d00@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58B9F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58B9F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------070806080902070506030401" X-AOL-IP: 10.172.3.58 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 19:08:24 -0000 --------------070806080902070506030401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Not just browsers. I suspect we have the same issues with Flash and Silverlight or any other browser plugins that provide app/dev support. It's also a little harder to script if just playing with curl, but maybe that's not a big issue. Thanks, George On 9/24/09 2:24 PM, Eran Hammer-Lahav wrote: > No, we are simply sending a message to browser vendors that they should add native support. It is one thing when a small community comes out with a spec and a whole other thing when the IETF publishes a new internet standard. > > Also, the fact that we will have the 1.0 spec published as an information RFC will help because it will give an alternative to this new work in cases where it is not possible to implement. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Ethan Jewett >> Sent: Thursday, September 24, 2009 11:04 AM >> To: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching >> >> Thinking back ... wasn't one of the primary reasons for having a way >> to pass the authentication parameters that didn't involve the headers >> because in-browser javascript doesn't have access to the headers? >> >> Now, I don't think there are a lot of applications currently using >> OAuth to authenticate an in-browser client application directly to a >> server, but with the advent of mechanisms for cross-domain requests in >> HTML5 and through hacks like iFrame proxies, this might become more >> common. If we require authorization headers are we precluding the use >> of OAuth on the browser platform? >> >> Ethan >> >> On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav >> wrote: >> >>> This means that we really only have two options: >>> >>> 1. Use only the HTTP Authorization header to pass authentication >>> >> parameters from the client to the server. This means dropping support >> for URI query parameters and form-encoded body parameters. >> >>> 2. Drop support for form-encoded parameters, recommend using HTTP >>> >> headers or require additional headers when using URI query parameters. >> >>> Of course, #2 defeats the purpose because the only reason to keep URI >>> >> query parameters is to avoid the need to set headers... >> >>> Are there any *documented* reasons why we should not just limit OAuth >>> >> to transmit parameters over HTTP Authorization headers? >> >>> EHL >>> >>> >>>> -----Original Message----- >>>> From: Roy T. Fielding [mailto:fielding@gbiv.com] >>>> Sent: Tuesday, September 22, 2009 10:48 AM >>>> To: Eran Hammer-Lahav >>>> Cc: John Panzer; oauth@ietf.org; ietf-http-wg@w3.org Group >>>> Subject: Re: [OAUTH-WG] OAuth and HTTP caching >>>> >>>> On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: Roy T. Fielding [mailto:fielding@gbiv.com] >>>>>> Sent: Tuesday, September 22, 2009 10:09 AM >>>>>> >>>>> >>>>>> Just follow the HTTP spec. >>>>>> >>>>> That what I am trying to figure out... >>>>> >>>>> Does the HTTP spec mandates that new authentication protocols use >>>>> the WWW-Authenticate and Authorization headers? >>>>> >>>> HTTP is not aware of any other kinds of authentication. There is no >>>> reason >>>> to specify anything else. >>>> >>>> >>>>> Are the headers required for existing caches and servers to >>>>> >> operate >> >>>>> properly? >>>>> >>>> Yes (and for user agents as well). Don't forget about Proxy-Auth*. >>>> >>>> >>>>> If they are not included in authenticated requests, are there >>>>> >> other >> >>>>> requirements to make sure it doesn't break existing deployment? >>>>> >>>> Cache-control: private >>>> >>>> is probably needed if the Auth headers are not being used but the >>>> response depends on something like cookies for authentication. >>>> >>>> ....Roy >>>> >>> _______________________________________________ >>> 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 > > --------------070806080902070506030401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Not just browsers. I suspect we have the same issues with Flash and Silverlight or any other browser plugins that provide app/dev support. It's also a little harder to script if just playing with curl, but maybe that's not a big issue.

Thanks,
George

On 9/24/09 2:24 PM, Eran Hammer-Lahav wrote: 
No, we are simply sending a message to browser vendors that they should add native support. It is one thing when a small community comes out with a spec and a whole other thing when the IETF publishes a new internet standard.

Also, the fact that we will have the 1.0 spec published as an information RFC will help because it will give an alternative to this new work in cases where it is not possible to implement.

EHL

  
-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of Ethan Jewett
Sent: Thursday, September 24, 2009 11:04 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth and HTTP caching

Thinking back ... wasn't one of the primary reasons for having a way
to pass the authentication parameters that didn't involve the headers
because in-browser javascript doesn't have access to the headers?

Now, I don't think there are a lot of applications currently using
OAuth to authenticate an in-browser client application directly to a
server, but with the advent of mechanisms for cross-domain requests in
HTML5 and through hacks like iFrame proxies, this might become more
common. If we require authorization headers are we precluding the use
of OAuth on the browser platform?

Ethan

On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav
<eran@hueniverse.com> wrote:
    
This means that we really only have two options:

1. Use only the HTTP Authorization header to pass authentication
      
parameters from the client to the server. This means dropping support
for URI query parameters and form-encoded body parameters.
    
2. Drop support for form-encoded parameters, recommend using HTTP
      
headers or require additional headers when using URI query parameters.
    
Of course, #2 defeats the purpose because the only reason to keep URI
      
query parameters is to avoid the need to set headers...
    
Are there any *documented* reasons why we should not just limit OAuth
      
to transmit parameters over HTTP Authorization headers?
    
EHL

      
-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com]
Sent: Tuesday, September 22, 2009 10:48 AM
To: Eran Hammer-Lahav
Cc: John Panzer; oauth@ietf.org; ietf-http-wg@w3.org Group
Subject: Re: [OAUTH-WG] OAuth and HTTP caching

On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote:

        
-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com]
Sent: Tuesday, September 22, 2009 10:09 AM
            
          
Just follow the HTTP spec.
            
That what I am trying to figure out...

Does the HTTP spec mandates that new authentication protocols use
the WWW-Authenticate and Authorization headers?
          
HTTP is not aware of any other kinds of authentication.  There is no
reason
to specify anything else.

        
Are the headers required for existing caches and servers to
          
operate
    
properly?
          
Yes (and for user agents as well).  Don't forget about Proxy-Auth*.

        
If they are not included in authenticated requests, are there
          
other
    
requirements to make sure it doesn't break existing deployment?
          
Cache-control: private

is probably needed if the Auth headers are not being used but the
response depends on something like cookies for authentication.

....Roy
        
_______________________________________________
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
--------------070806080902070506030401-- From breno.demedeiros@gmail.com Thu Sep 24 12:53:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62EE43A68C8 for ; Thu, 24 Sep 2009 12:53:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOBmZp8m79Wz for ; Thu, 24 Sep 2009 12:53:36 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id B786C3A6859 for ; Thu, 24 Sep 2009 12:53:35 -0700 (PDT) Received: by qyk33 with SMTP id 33so1699000qyk.29 for ; Thu, 24 Sep 2009 12:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SLKVvLusAJVXd+LMHZWGvacINers8z1Cacv5EOQR3mA=; b=kXcdslDnsZh3sFyCCLbpHQ9Z2bz20lW1+NaT3jbw4KkttXuKp9WN5xhtEH+/jASAnl UgDJ9JBsbPBcfxe01q8gtqxxjdbXIpJYBer54vMYm6+jeX02Xed2BBBPn1cWySwEaPtJ 20htwKGnDCw6mk3EmjzhMlmq0AZ8kPjJujzw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xF99ZPcgg4cwBy4y5d749Hi2gNaS7d/6rmk+t6xw0tvPu/7v0axyxR5xSXviI5g+Qq vgZePDOdLa5A8t9QEN6C9O5yUTPwoH2sI1r7lyToZFHMLdgW7EaM97UuaqrtbaYmZlMa q4hhL1yXnCRcqfsDHEIRYo0lJl0MOHYFJ4PCI= MIME-Version: 1.0 Received: by 10.229.43.211 with SMTP id x19mr1907627qce.3.1253822078872; Thu, 24 Sep 2009 12:54:38 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 24 Sep 2009 12:54:38 -0700 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016364c64c19f712104745833fa Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 19:53:37 -0000 --0016364c64c19f712104745833fa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable SSL does not provide such guidance and yet there is wide interoperability. The recommendation should be that clients support as many crypto suites as they feel comfortable using, and so should servers. I have never heard that SSL has an interoperability problem. We could go the other way and say that SSL is too promiscuous (true) and that we aim for higher security. However, aiming security above SSL is really wishful thinking. What is protecting the user authentication anyway? I am a crypto expert and I see no reason to fret about using HMAC-SHA1 in the next 2-3 years at least. Even threat against RSA-SHA1 are probably not going to materialize in this time-frame. Crypto agility has been on the whole a very good thing for SSL. On Thu, Sep 24, 2009 at 11:36 AM, Eran Hammer-Lahav wr= ote: > But the IETF is set up to provide crypto expertise. RFC 2617 had no > problem providing two algorithms and allowing extensibility. > > > > I disagree that we cannot find a reasonable crypto algorithm for normal w= eb > usage that can be made obsolete when needed. We did it with HMAC-SHA1 in = 1.0 > and we should be doing it again in this new effort. If we do not guarante= e > interoperability and provide clear guidance on security for the majority = of > developers who are not experts, what=92s the point? > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Jorgen Thelin > *Sent:* Thursday, September 24, 2009 11:28 AM > *To:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Mandatory signature algorithms? > > > > Which one would we choose, Eran? This group is not set up to be crypto > experts, so we should not be in the business of recommending one universa= l > crypto algorithm =96 which is effectively what we would be doing if we > declared any mandatory algorithm(s). > > > > The choice of crypto algorithm will always depends on the specific > scenario, and will also evolve over time (years, not necessarily months). > > > > The goal of a wire protocol should be to support =93crypto agility=94 =96= i.e. > the ability to somehow specify which algorithm is being used, and drop in > new ones if/when necessary, rather than baking that choice into the core > protocol spec itself. > > > > I completely agree with Breno =96 this question nets out to a =93discover= y=94 > problem for this WG to solve, and definitely not an =93algorithm choice= =94 > problem. > > > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Eran Hammer-Lahav > *Sent:* Thursday, September 24, 2009 10:48 AM > *To:* Breno > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Mandatory signature algorithms? > > > > This goes against our goal of ensuring that any two OAuth compliant > client/server can interoperate. We must declare at least one algorithm fo= r > that. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Thursday, September 24, 2009 9:48 AM > *To:* Eran Hammer-Lahav > *Cc:* Hubert Le Van Gong; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Mandatory signature algorithms? > > > > We should follow the SSL model where the cryptographic primitives are > explicitly negotiated, or use discovery of the supported crypto primitive= s. > It is no burden for libraries to support multiple ciphers (even dozens of > them). If someone is rolling their own crypto to do OAuth that is VERY VE= RY > BAD, and OAuth libraries will just include other crypto libraries that > already support everything reasonable or not, and it is OpenSSL in many > cases anyways. The difficulty with crypto is how to normalize the string = to > sign, not how to employ the crypto primitives. > > The spec needs to define how a client can find which algorithms the serve= r > support. > > The spec should not mandate algorithms, and if anything is to be said abo= ut > algorithms, I would suggest that it be recommended that the existing sche= mes > RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, us= ing > a grandfather clause. > > OAuth should not be in the business of certifying cryptography. That is a > whole different industry. > > On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav > wrote: > > Yes, it is right there on my list of proposed changes I am seeking feedba= ck > on. I think we need to pick one and make it required. > > EHL > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Hubert Le Van Gong > > Sent: Tuesday, September 22, 2009 6:35 AM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Mandatory signature algorithms? > > > > Reading the latest draft I see we do not mandate a minimum set of > > signature algorithms. > > I think we should mandate a few (at least one) so we get a minimum of > > interoperability > > out of the box. > > Thoughts? > > > > Cheers, > > Hubert > > _______________________________________________ > > 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 > > > > > -- > Breno de Medeiros > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Breno de Medeiros --0016364c64c19f712104745833fa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable SSL does not provide such guidance and yet there is wide interoperability.<= br>
The recommendation should be that clients support as many crypto sui= tes as they feel comfortable using, and so should servers. I have never hea= rd that SSL has an interoperability problem.

We could go the other way and say that SSL is too promiscuous (true) an= d that we aim for higher security. However, aiming security above SSL is re= ally wishful thinking. What is protecting the user authentication anyway?
I am a crypto expert and I see no reason to fret about using HMAC-SHA1 = in the next 2-3 years at least. Even threat against RSA-SHA1 are probably n= ot going to materialize in this time-frame.

Crypto agility has been = on the whole a very good thing for SSL.


On Thu, Sep 24, 2009 at 11:36 AM, Eran H= ammer-Lahav <er= an@hueniverse.com> wrote:

But the IETF is set up to provide crypto expertise. RFC 2617 had no problem providing two algorithms and allowing extensibility.

=A0

I disagree that we cannot find a reasonable crypto algorithm for normal web usage that can be made obsolete when needed. We did it with HMAC-SHA1 in 1.0 and we should be doing it again in this new effort. If we = do not guarantee interoperability and provide clear guidance on security for t= he majority of developers who are not experts, what=92s the point?

=A0

EHL

=A0

From:= oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Jorgen Thelin
Sent: Thursday, September 24, 2009 11:28 AM
To: oauth@ietf.o= rg


Subject: Re: [OAUTH-WG] Mandatory signature algorithms?
<= /span>

=A0

Which one would we choose, Eran? =A0This group is not set up to be crypto experts, so we should not be in the business of recommending o= ne universal crypto algorithm =96 which is effectively what we would be doing if we declared any mandatory algorithm(s).

=A0

The choice of crypto algorithm will always depends on the specific scenario, and will also evolve over time (years, not necessarily months).

=A0

The goal of a wire protocol should be to support =93crypto agility=94 =96 i.e. the ability to somehow specify which algorithm is being used, and drop in new ones if/when necessary, rather than baking that choice into the core protocol spec itself.

=A0

I completely agree with Breno =96 this question nets out to a =93discovery=94 problem for this WG to solve, and definitely not an =93algorithm choice=94 problem.

=A0

=A0

From:= oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, September 24, 2009 10:48 AM
To: Breno
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

=A0

This goes against our goal of ensuring that any two OAuth compliant client/server can interoperate. We must declare at least one algorithm for that.

=A0

EHL

=A0

From:= Breno [mailto:bre= no.demedeiros@gmail.com]
Sent: Thursday, September 24, 2009 9:48 AM
To: Eran Hammer-Lahav
Cc: Hubert Le Van Gong; oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

=A0

We should follow the = SSL model where the cryptographic primitives are explicitly negotiated, or use discov= ery of the supported crypto primitives. It is no burden for libraries to suppor= t multiple ciphers (even dozens of them). If someone is rolling their own cry= pto to do OAuth that is VERY VERY BAD, and OAuth libraries will just include ot= her crypto libraries that already support everything reasonable or not, and it = is OpenSSL in many cases anyways. The difficulty with crypto is how to normali= ze the string to sign, not how to employ the crypto primitives.

The spec needs to define how a client can find which algorithms the server support.

The spec should not mandate algorithms, and if anything is to be said about algorithms, I would suggest that it be recommended that the existing scheme= s RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where N > 2, u= sing a grandfather clause.

OAuth should not be in the business of certifying cryptography. That is a w= hole different industry.

On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav &= lt;eran@hueniverse= .com> wrote:

Yes, it is right there on my list of proposed change= s I am seeking feedback on. I think we need to pick one and make it required.

EHL


> -----Original Message-----
> From: oaut= h-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf
> Of Hubert Le Van Gong
> Sent: Tuesday, September 22, 2009 6:35 AM
> To: oauth@ietf.org=
> Subject: [OAUTH-WG] Mandatory signature algorithms?
>
> Reading the latest draft I see we do not mandate a minimum set of
> signature algorithms.
> I think we should mandate a few (at least one) so we get a minimum of<= br> > interoperability
> out of the box.
> Thoughts?
>
> Cheers,
> Hubert
> _______________________________________________
> 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




--
Breno de Medeiros


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




--
Breno de Medeiros
--0016364c64c19f712104745833fa-- From hubertlvg@gmail.com Thu Sep 24 14:32:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587CD3A683E for ; Thu, 24 Sep 2009 14:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-Z+hW+Eb-3H for ; Thu, 24 Sep 2009 14:32:05 -0700 (PDT) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id 211093A6774 for ; Thu, 24 Sep 2009 14:32:04 -0700 (PDT) Received: by fxm27 with SMTP id 27so7925fxm.42 for ; Thu, 24 Sep 2009 14:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8/Q/jQBN2HvgaCnzh5nZT75JiFwnHZU4LwOBfgh/Zb0=; b=AowSjgk+NIcYvpyic3GMmOulVPxAzqB+tEixf1hpPUJUnFMU7vd+azHDjtKgYMlGuy 2+9ncQ1p4OsG1ZK032K4hqvIY3GhHpL6xBf/wg6/Tk/wmwaD3r5xwMG81WXfT1Qb3t4V YSFv6WekP93Tcv7jh1MCq9sKsqzZ7hgxGewvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VMDUrXnv3cZPpbZOCFeWYEHdo/TMGGT47J0+zTRLuX+Ila3LyJGFP/juDgI4ONOvYy bR3pBd+95Y2Dt1dmztwGpGWLf/iaHsjl/XUFkv1w/8UE4iNtQlGxhoeKs+tzcAHyKLBu rdSxK8DK3fyn9XRpKrrCaHKaaBO0MEPRbgUjc= MIME-Version: 1.0 Received: by 10.204.3.10 with SMTP id 10mr3474115bkl.196.1253827986387; Thu, 24 Sep 2009 14:33:06 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 24 Sep 2009 23:33:06 +0200 Message-ID: <6c0fd2bc0909241433q4a56fa63w58de498a36c42d1d@mail.gmail.com> From: Hubert Le Van Gong To: Breno Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 21:32:07 -0000 I don't think the goal is to certify cryptography but rather ensure reasona= ble security and agility. The latter point is key since OAuth is a young protoc= ol and crypto requirements are very likely to evolve throughout its lifetime. SHA1 has now known weaknesses. It is not a good policy to base a new standard on such algorithm. I don't claim to be a security expert (maybe I do know enough to be dangerous though) but the beauty of working at Sun Micro is that there's a whole bunch of security maniacs that I can consult. Their advise was unanimous: At the very least HMAC-SHA256 and RSA-SHA256 should be supported, and we need to make sure the protocol has algorithm (cipher-suite actually) agility so that it can move to the winner of the SHA3 competition when it becomes available or, why not, an elliptic curve cipher suite. Also I'm told it is common for IETF standards to mandate at least one cipher-suite and recommend additional ones. So SHA256 seems like a good starting point (and it is really not much more work than SHA1). Cheers, Hubert On Thu, Sep 24, 2009 at 9:54 PM, Breno wrote: > SSL does not provide such guidance and yet there is wide interoperability= . > > The recommendation should be that clients support as many crypto suites a= s > they feel comfortable using, and so should servers. I have never heard th= at > SSL has an interoperability problem. > > We could go the other way and say that SSL is too promiscuous (true) and > that we aim for higher security. However, aiming security above SSL is > really wishful thinking. What is protecting the user authentication anywa= y? > > I am a crypto expert and I see no reason to fret about using HMAC-SHA1 in > the next 2-3 years at least. Even threat against RSA-SHA1 are probably no= t > going to materialize in this time-frame. > > Crypto agility has been on the whole a very good thing for SSL. > > > On Thu, Sep 24, 2009 at 11:36 AM, Eran Hammer-Lahav > wrote: >> >> But the IETF is set up to provide crypto expertise. RFC 2617 had no >> problem providing two algorithms and allowing extensibility. >> >> >> >> I disagree that we cannot find a reasonable crypto algorithm for normal >> web usage that can be made obsolete when needed. We did it with HMAC-SHA= 1 in >> 1.0 and we should be doing it again in this new effort. If we do not >> guarantee interoperability and provide clear guidance on security for th= e >> majority of developers who are not experts, what=92s the point? >> >> >> >> EHL >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Jorgen Thelin >> Sent: Thursday, September 24, 2009 11:28 AM >> To: oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] Mandatory signature algorithms? >> >> >> >> Which one would we choose, Eran? =A0This group is not set up to be crypt= o >> experts, so we should not be in the business of recommending one univers= al >> crypto algorithm =96 which is effectively what we would be doing if we >> declared any mandatory algorithm(s). >> >> >> >> The choice of crypto algorithm will always depends on the specific >> scenario, and will also evolve over time (years, not necessarily months)= . >> >> >> >> The goal of a wire protocol should be to support =93crypto agility=94 = =96 i.e. >> the ability to somehow specify which algorithm is being used, and drop i= n >> new ones if/when necessary, rather than baking that choice into the core >> protocol spec itself. >> >> >> >> I completely agree with Breno =96 this question nets out to a =93discove= ry=94 >> problem for this WG to solve, and definitely not an =93algorithm choice= =94 >> problem. >> >> >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> Eran Hammer-Lahav >> Sent: Thursday, September 24, 2009 10:48 AM >> To: Breno >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Mandatory signature algorithms? >> >> >> >> This goes against our goal of ensuring that any two OAuth compliant >> client/server can interoperate. We must declare at least one algorithm f= or >> that. >> >> >> >> EHL >> >> >> >> From: Breno [mailto:breno.demedeiros@gmail.com] >> Sent: Thursday, September 24, 2009 9:48 AM >> To: Eran Hammer-Lahav >> Cc: Hubert Le Van Gong; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Mandatory signature algorithms? >> >> >> >> We should follow the SSL model where the cryptographic primitives are >> explicitly negotiated, or use discovery of the supported crypto primitiv= es. >> It is no burden for libraries to support multiple ciphers (even dozens o= f >> them). If someone is rolling their own crypto to do OAuth that is VERY V= ERY >> BAD, and OAuth libraries will just include other crypto libraries that >> already support everything reasonable or not, and it is OpenSSL in many >> cases anyways. The difficulty with crypto is how to normalize the string= to >> sign, not how to employ the crypto primitives. >> >> The spec needs to define how a client can find which algorithms the serv= er >> support. >> >> The spec should not mandate algorithms, and if anything is to be said >> about algorithms, I would suggest that it be recommended that the existi= ng >> schemes RSA-SHA1 and HMAC-SHA1 be supported for the next N years, where = N > >> 2, using a grandfather clause. >> >> OAuth should not be in the business of certifying cryptography. That is = a >> whole different industry. >> >> On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav >> wrote: >> >> Yes, it is right there on my list of proposed changes I am seeking >> feedback on. I think we need to pick one and make it required. >> >> EHL >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Hubert Le Van Gong >> > Sent: Tuesday, September 22, 2009 6:35 AM >> > To: oauth@ietf.org >> > Subject: [OAUTH-WG] Mandatory signature algorithms? >> > >> > Reading the latest draft I see we do not mandate a minimum set of >> > signature algorithms. >> > I think we should mandate a few (at least one) so we get a minimum of >> > interoperability >> > out of the box. >> > Thoughts? >> > >> > Cheers, >> > Hubert >> > _______________________________________________ >> > 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 >> >> >> -- >> Breno de Medeiros >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Breno de Medeiros > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From john@jkemp.net Thu Sep 24 14:44:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B126F3A694A for ; Thu, 24 Sep 2009 14:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ1Afal5MGNG for ; Thu, 24 Sep 2009 14:43:56 -0700 (PDT) Received: from outbound-mail-125.bluehost.com (outbound-mail-125.bluehost.com [67.222.38.25]) by core3.amsl.com (Postfix) with SMTP id F11CA3A68B9 for ; Thu, 24 Sep 2009 14:43:55 -0700 (PDT) Received: (qmail 4220 invoked by uid 0); 24 Sep 2009 21:45:05 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy4.bluehost.com with SMTP; 24 Sep 2009 21:45:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Jkb39Iz5HSASDzVHRglzqOyuexoqmwPpKMqVXaaHKfQ95j3rRU/JW6qKOs29PKcP1lXFC3aw+6VAwogDtXxPRTrwlt235lokRq9qDxlAO60n3xoPypDRSDP2c9cfRnPl; Received: from 31-33-227.wireless.csail.mit.edu ([128.31.33.227]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mqw7d-0003VJ-3v; Thu, 24 Sep 2009 15:45:05 -0600 Message-ID: <4ABBE85C.3030301@jkemp.net> Date: Thu, 24 Sep 2009 17:45:00 -0400 From: John Kemp User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hubert Le Van Gong References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> In-Reply-To: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 128.31.33.227 authed with john+jkemp.net} Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 21:44:00 -0000 Hubert Le Van Gong wrote: > Reading the latest draft I see we do not mandate a minimum set of > signature algorithms. Does the "minimum set" include PLAINTEXT (ie. unsigned)? Regards, - johnk > I think we should mandate a few (at least one) so we get a minimum of > interoperability > out of the box. > Thoughts? > > Cheers, > Hubert > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hubertlvg@gmail.com Thu Sep 24 14:49:22 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E243A6889 for ; Thu, 24 Sep 2009 14:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2LZqsRJhbA7 for ; Thu, 24 Sep 2009 14:49:21 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id C19C23A6839 for ; Thu, 24 Sep 2009 14:49:20 -0700 (PDT) Received: by bwz6 with SMTP id 6so1661395bwz.37 for ; Thu, 24 Sep 2009 14:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=FUGACIGPirmjB4o4IOntGbJ09Gxlkgbfa5SjRDuDRxg=; b=jokUuBHvVQniOcBNm518gza0wUcGhEGm8A112C+0CUDtjtTvDSWh/I7KXRbyXxUCsE vl7ji3zW6DNstdAQXDj3b1WMJNUDRUBszOmk7dEEkTtIfif4PZn6NVscIpL7bPxx6fUq tGirWj2V9GVVLjM96BKSmy/e37Dl8VD8vH968= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YvXNFzME5JhPho0ibpPgK2yEpwEf+9RJleV/oa1Lr8nsn81oZLD5LXwt6Duqio4HbR 14RLoNClAG4FomwjPHdtVUUjqt9JZZ/yp+XJfgQdXh9LuffI6Opprh4eGKGdHfch2fZO vdE0GC6LD9rYGkhbUvtChFnKn8XzZxSLX5oRU= MIME-Version: 1.0 Received: by 10.204.20.143 with SMTP id f15mr3546268bkb.49.1253829025818; Thu, 24 Sep 2009 14:50:25 -0700 (PDT) In-Reply-To: <4ABBE85C.3030301@jkemp.net> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> Date: Thu, 24 Sep 2009 23:50:25 +0200 Message-ID: <6c0fd2bc0909241450g2a51856bsa7598df677a969a0@mail.gmail.com> From: Hubert Le Van Gong To: John Kemp Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 21:49:22 -0000 For the use cases where security isn't a concern then sure we'd need plaintext. Which would bring the bare minimum to 2 :) Hubert On Thu, Sep 24, 2009 at 11:45 PM, John Kemp wrote: > Hubert Le Van Gong wrote: >> >> Reading the latest draft I see we do not mandate a minimum set of >> signature algorithms. > > Does the "minimum set" include PLAINTEXT (ie. unsigned)? > > Regards, > > - johnk > >> I think we should mandate a few (at least one) so we get a minimum of >> interoperability >> out of the box. >> Thoughts? >> >> Cheers, >> Hubert >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > From john@jkemp.net Thu Sep 24 15:06:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1F23A6853 for ; Thu, 24 Sep 2009 15:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKR60itLUU3C for ; Thu, 24 Sep 2009 15:06:31 -0700 (PDT) Received: from outbound-mail-312.bluehost.com (outbound-mail-312.bluehost.com [67.222.54.5]) by core3.amsl.com (Postfix) with SMTP id 835A33A6839 for ; Thu, 24 Sep 2009 15:06:31 -0700 (PDT) Received: (qmail 17285 invoked by uid 0); 24 Sep 2009 22:07:40 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by outboundproxy6.bluehost.com with SMTP; 24 Sep 2009 22:07:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=uwdQ7bSozZIUBjh+AqmJmiPeEbZb2xfCGH+PhU+iRqFqlieifo2AcTDiwmB7LyvAWMh92dyCIrBpEfBikOjANTmEs5Kh4C6Fl5z5Oz804acpmgPIj5UXmuFn3jskJjgx; Received: from 31-33-227.wireless.csail.mit.edu ([128.31.33.227]) by box320.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MqwTU-0004k0-IK; Thu, 24 Sep 2009 16:07:40 -0600 Message-ID: <4ABBEDA8.6090506@jkemp.net> Date: Thu, 24 Sep 2009 18:07:36 -0400 From: John Kemp User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Breno References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 128.31.33.227 authed with john+jkemp.net} Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 22:06:32 -0000 Breno wrote: > SSL does not provide such guidance and yet there is wide interoperability. Indeed, see http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 There are "default sets" of algorithms, but these are not mandated. Instead, if the client either a) supports more algorithms than the default set, or b) doesn't support the "default set" it can send an extension parameter describing the algorithms it does support. > > The recommendation should be that clients support as many crypto suites > as they feel comfortable using, and so should servers. I have never > heard that SSL has an interoperability problem. I too like the SSL approach, which suggests that OAuth should define (one or more) "default algorithm sets", without mandating it/them. I would note further that SSL/TLS decouples hashing algorithm from signature algorithm in its text, and as a sidenote, I'd like to see us do that too. Regards, - johnk > > We could go the other way and say that SSL is too promiscuous (true) and > that we aim for higher security. However, aiming security above SSL is > really wishful thinking. What is protecting the user authentication anyway? > > I am a crypto expert and I see no reason to fret about using HMAC-SHA1 > in the next 2-3 years at least. Even threat against RSA-SHA1 are > probably not going to materialize in this time-frame. > > Crypto agility has been on the whole a very good thing for SSL. > > > On Thu, Sep 24, 2009 at 11:36 AM, Eran Hammer-Lahav > wrote: > > But the IETF is set up to provide crypto expertise. RFC 2617 had no > problem providing two algorithms and allowing extensibility. > > > > I disagree that we cannot find a reasonable crypto algorithm for > normal web usage that can be made obsolete when needed. We did it > with HMAC-SHA1 in 1.0 and we should be doing it again in this new > effort. If we do not guarantee interoperability and provide clear > guidance on security for the majority of developers who are not > experts, what’s the point? > > > > EHL > > > > *From:* oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] *On > Behalf Of *Jorgen Thelin > *Sent:* Thursday, September 24, 2009 11:28 AM > *To:* oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Mandatory signature algorithms? > > > > Which one would we choose, Eran? This group is not set up to be > crypto experts, so we should not be in the business of recommending > one universal crypto algorithm – which is effectively what we would > be doing if we declared any mandatory algorithm(s). > > > > The choice of crypto algorithm will always depends on the specific > scenario, and will also evolve over time (years, not necessarily > months). > > > > The goal of a wire protocol should be to support “crypto agility” – > i.e. the ability to somehow specify which algorithm is being used, > and drop in new ones if/when necessary, rather than baking that > choice into the core protocol spec itself. > > > > I completely agree with Breno – this question nets out to a > “discovery” problem for this WG to solve, and definitely not an > “algorithm choice” problem. > > > > > > *From:* oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] *On > Behalf Of *Eran Hammer-Lahav > *Sent:* Thursday, September 24, 2009 10:48 AM > *To:* Breno > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Mandatory signature algorithms? > > > > This goes against our goal of ensuring that any two OAuth compliant > client/server can interoperate. We must declare at least one > algorithm for that. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com > ] > *Sent:* Thursday, September 24, 2009 9:48 AM > *To:* Eran Hammer-Lahav > *Cc:* Hubert Le Van Gong; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Mandatory signature algorithms? > > > > We should follow the SSL model where the cryptographic primitives > are explicitly negotiated, or use discovery of the supported crypto > primitives. It is no burden for libraries to support multiple > ciphers (even dozens of them). If someone is rolling their own > crypto to do OAuth that is VERY VERY BAD, and OAuth libraries will > just include other crypto libraries that already support everything > reasonable or not, and it is OpenSSL in many cases anyways. The > difficulty with crypto is how to normalize the string to sign, not > how to employ the crypto primitives. > > The spec needs to define how a client can find which algorithms the > server support. > > The spec should not mandate algorithms, and if anything is to be > said about algorithms, I would suggest that it be recommended that > the existing schemes RSA-SHA1 and HMAC-SHA1 be supported for the > next N years, where N > 2, using a grandfather clause. > > OAuth should not be in the business of certifying cryptography. That > is a whole different industry. > > On Tue, Sep 22, 2009 at 8:19 AM, Eran Hammer-Lahav > > wrote: > > Yes, it is right there on my list of proposed changes I am seeking > feedback on. I think we need to pick one and make it required. > > EHL > > > > -----Original Message----- > > From: oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] On > Behalf > > Of Hubert Le Van Gong > > Sent: Tuesday, September 22, 2009 6:35 AM > > To: oauth@ietf.org > > Subject: [OAUTH-WG] Mandatory signature algorithms? > > > > Reading the latest draft I see we do not mandate a minimum set of > > signature algorithms. > > I think we should mandate a few (at least one) so we get a minimum of > > interoperability > > out of the box. > > Thoughts? > > > > Cheers, > > Hubert > > _______________________________________________ > > 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 > > > > > -- > Breno de Medeiros > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Breno de Medeiros > > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From breno.demedeiros@gmail.com Thu Sep 24 15:12:35 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FA883A68C4 for ; Thu, 24 Sep 2009 15:12:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKL1ZKBr0TWG for ; Thu, 24 Sep 2009 15:12:34 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 04F343A685D for ; Thu, 24 Sep 2009 15:12:33 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 8so841031qwh.31 for ; Thu, 24 Sep 2009 15:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nhdo2A21l1Jh/tERNLgO8GYvPVDoQq27VD5gqSRVegw=; b=svWoBCdkF/JKa/D0FzHR7YLge8qw2M40TSjgHLZwJ9uU9n5mD0Lkx3Skm8IO59eg+k ZY8+Tf7WkRvzRZY3Y95E8OOpBPhsOiJkkQn4kGrgPM+/G90FwyiiQM0SaFwdcNhhkZgO vDu67BRExUMZUxcl3lZ/7WDsmRc0YD0T7cP1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fuf9beAiEJN6qE/YCZj8fawTguPPMAnI8VTcVL9ONPXic/O2gPIkRl0VjyYQcAUSrx YJekoJKbaFv9kTJAPOZ24BCtlyBFyQ3eqH5L/GXgfPKTbb87WKSpZ02bC4BX24xBvk3T 5AeolifGB/1/Vf/lc9iH1o9AYaDM+oxcz3OwM= MIME-Version: 1.0 Received: by 10.229.9.130 with SMTP id l2mr2043945qcl.41.1253830420630; Thu, 24 Sep 2009 15:13:40 -0700 (PDT) In-Reply-To: <4ABBEDA8.6090506@jkemp.net> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4ABBEDA8.6090506@jkemp.net> Date: Thu, 24 Sep 2009 15:13:40 -0700 Message-ID: From: Breno To: John Kemp Content-Type: multipart/alternative; boundary=00163683269cd48fbf04745a24f7 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 22:12:35 -0000 --00163683269cd48fbf04745a24f7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 24, 2009 at 3:07 PM, John Kemp wrote: > Breno wrote: > >> SSL does not provide such guidance and yet there is wide interoperability. >> > I think the word guidance was to strong. SSL does not _mandate_ anything as minimum support. > > Indeed, see http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 > > There are "default sets" of algorithms, but these are not mandated. > Instead, if the client either a) supports more algorithms than the default > set, or b) doesn't support the "default set" it can send an extension > parameter describing the algorithms it does support. > > >> The recommendation should be that clients support as many crypto suites as >> they feel comfortable using, and so should servers. I have never heard that >> SSL has an interoperability problem. >> > > I too like the SSL approach, which suggests that OAuth should define (one > or more) "default algorithm sets", without mandating it/them. > > I would note further that SSL/TLS decouples hashing algorithm from > signature algorithm in its text, and as a sidenote, I'd like to see us do > that too. > > Regards, > > -- Breno de Medeiros --00163683269cd48fbf04745a24f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 24, 2009 at 3:07 PM, John Ke= mp <john@jkemp.net> wrote:
Breno wrote:
SSL does not provide such guidance and yet there is wide interoperability.<= br>

I think the word guidance was t= o strong. SSL does not _mandate_ anything as minimum support.
=A0

Indeed, see http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1

There are "default sets" of algorithms, but these are not mandate= d. Instead, if the client either a) supports more algorithms than the defau= lt set, or b) doesn't support the "default set" it can send a= n extension parameter describing the algorithms it does support.



The recommendation should be that clients support as many crypto suites as = they feel comfortable using, and so should servers. I have never heard that= SSL has an interoperability problem.

I too like the SSL approach, which suggests that OAuth should define (one o= r more) "default algorithm sets", without mandating it/them.

I would note further that SSL/TLS decouples hashing algorithm from signatur= e algorithm in its text, and as a sidenote, I'd like to see us do that = too.

Regards,


--
Breno de Medeiros

--00163683269cd48fbf04745a24f7-- From breno.demedeiros@gmail.com Thu Sep 24 15:13:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB1D3A67D7 for ; Thu, 24 Sep 2009 15:13:58 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEYdeOkp11IM for ; Thu, 24 Sep 2009 15:13:57 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 42F883A683A for ; Thu, 24 Sep 2009 15:13:57 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 8so841420qwh.31 for ; Thu, 24 Sep 2009 15:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jyFlBjcoEQsL8TxxzIpSTLnqDlbkLhxMqEiaGzLogmE=; b=aQdqZn6sRXWBtKAXnWZJVhljETdQyI74kd51XYPjDrYE6TcDaB/vvxV4hRotLyUpxa oRhyEGnMtH/0RUzf2seked2DZHnbM0TI0Xyc44lLdCNbvWPxW3gDjTHr7+0M5NeKJevl P6TnTvJsWzA+AxtDI+sDaRcjzIDRzAAcXkpIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MjgVEUuNWDBJz7kDpw/VfPnYR6MjoSTuZiMfvq+60qAPTDcH9sBklT4KDDJfESEQgp sxy90xsVSEPPrI+9Tj1m71secYZKUgNfRyhjYcvTmMXNkHz6KJI9GqAsKIjLVeXA2o2P 3P539o/dYbns4HjkFTLZJI8CJAkogptHepzFE= MIME-Version: 1.0 Received: by 10.229.93.41 with SMTP id t41mr2038240qcm.81.1253830504152; Thu, 24 Sep 2009 15:15:04 -0700 (PDT) In-Reply-To: <6c0fd2bc0909241433q4a56fa63w58de498a36c42d1d@mail.gmail.com> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0909241433q4a56fa63w58de498a36c42d1d@mail.gmail.com> Date: Thu, 24 Sep 2009 15:15:03 -0700 Message-ID: From: Breno To: Hubert Le Van Gong Content-Type: multipart/alternative; boundary=000e0cd6aa62cefe3504745a29f9 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 22:13:58 -0000 --000e0cd6aa62cefe3504745a29f9 Content-Type: text/plain; charset=ISO-8859-1 > > > I don't claim to be a security expert (maybe I do know enough to be > dangerous though) but the beauty of working at Sun Micro is that > there's a whole bunch of security maniacs that I can consult. > Their advise was unanimous: At the very least HMAC-SHA256 and > RSA-SHA256 should be supported, and we need to make sure the > protocol has algorithm (cipher-suite actually) agility so that it can > move to the winner of the SHA3 competition when it becomes > available or, why not, an elliptic curve cipher suite. > > > > I have nothing against adding either of this protocols to a suggested cipher suite such as SSL does. I do think that banning HMAC-SHA1 at this point is fairly premature. -- Breno de Medeiros --000e0cd6aa62cefe3504745a29f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


I don't claim to be a security expert (maybe I do know enough to be
dangerous though) but the beauty of working at Sun Micro is that
there's a whole bunch of security maniacs that I can consult.
Their advise was unanimous: At the very least HMAC-SHA256 and
RSA-SHA256 should be supported, and we need to make sure the
protocol has algorithm (cipher-suite actually) agility so that it can
move to the winner of the SHA3 competition when it becomes
available or, why not, an elliptic curve cipher suite.




I have nothing against adding either = of this protocols to a suggested cipher suite such as SSL does. I do think = that banning HMAC-SHA1 at this point is fairly premature.
=A0


--
Breno de Medeiros

--000e0cd6aa62cefe3504745a29f9-- From breno.demedeiros@gmail.com Thu Sep 24 15:19:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20DE83A6972 for ; Thu, 24 Sep 2009 15:19:50 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu7agaogIt-J for ; Thu, 24 Sep 2009 15:19:49 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id F3D223A694A for ; Thu, 24 Sep 2009 15:19:48 -0700 (PDT) Received: by qyk33 with SMTP id 33so1812556qyk.29 for ; Thu, 24 Sep 2009 15:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=zavYm67+goiFnjLcmwYmGm7uG9nKHVjb6ltaUSlJ+yw=; b=MPRnZ2ZvTbQe8+4/Va+FZEIgp4uF3Nf6Qd3n4dDbtMc8Rb48KotlCnNAGeApMlYDtP Za8bVd2AGBiGMZTvnBmTsShNBr9UOQB12uidMy9wIS6TtnnP1G+4WKRp8G8Z3eqWQIDf EpLOUBRBKlcUZFGKN3zShMkxnVmjFyR8KtRT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=u1Bw5fDmZcGfUjwNJ32sxGbttlVNg37h8bEVbCqqAEwuz/uT56Hqm6dud0e8J/pQ6j 222u7fBUpqfgDjjO4Kp8wVWhZWHu/D0cDxA4XpGUXnw4/tnjpHsMkOydX7Bv8a9rhN6L jZYQCkIfmLdJ/KB2qmq6MH5vWemi/3H+Pjn3s= MIME-Version: 1.0 Received: by 10.229.43.79 with SMTP id v15mr2020439qce.40.1253830853340; Thu, 24 Sep 2009 15:20:53 -0700 (PDT) In-Reply-To: <4ABBF00E.5030702@jkemp.net> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4ABBEDA8.6090506@jkemp.net> <4ABBF00E.5030702@jkemp.net> Date: Thu, 24 Sep 2009 15:20:53 -0700 Message-ID: From: Breno To: oauth@ietf.org Content-Type: multipart/alternative; boundary=00148536e6da9f2cc904745a3e7d Subject: [OAUTH-WG] Fwd: Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 22:19:50 -0000 --00148536e6da9f2cc904745a3e7d Content-Type: text/plain; charset=ISO-8859-1 Just to make sure that my answer is understood as endoring John's suggestion. We should do EXACTLY what SSL/TLS does. ---------- Forwarded message ---------- From: John Kemp Date: Thu, Sep 24, 2009 at 3:17 PM Subject: Re: [OAUTH-WG] Mandatory signature algorithms? To: Breno Hi Breno, I was roughly agreeing with you and suggesting that we should do EXACTLY what SSL/TLS does - create a default set, and an extension mechanism for those which don't support the default set. See the referenced link in my previous email. Cheers, - johnk Breno wrote: > > On Thu, Sep 24, 2009 at 3:07 PM, John Kemp john@jkemp.net>> wrote: > > Breno wrote: > > SSL does not provide such guidance and yet there is wide > interoperability. > > > I think the word guidance was to strong. SSL does not _mandate_ anything as > minimum support. > > > Indeed, see http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 > > There are "default sets" of algorithms, but these are not mandated. > Instead, if the client either a) supports more algorithms than the > default set, or b) doesn't support the "default set" it can send an > extension parameter describing the algorithms it does support. > > > > The recommendation should be that clients support as many crypto > suites as they feel comfortable using, and so should servers. I > have never heard that SSL has an interoperability problem. > > > I too like the SSL approach, which suggests that OAuth should define > (one or more) "default algorithm sets", without mandating it/them. > > I would note further that SSL/TLS decouples hashing algorithm from > signature algorithm in its text, and as a sidenote, I'd like to see > us do that too. > > Regards, > > > -- > Breno de Medeiros > > -- Breno de Medeiros --00148536e6da9f2cc904745a3e7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just to make sure that my answer is understood as endoring John's sugge= stion. We should do EXACTLY what SSL/TLS does.

---------- Forwarded message ----------
From: John Kemp <john@jkemp.net>
Date: Thu, Sep 24, 2009 at 3:17 PM
Subject: Re: [OAUTH-WG] Mandatory sig= nature algorithms?
To: Breno <breno.demedeiros@gmail.com>


Hi Breno,

I was roughly agreeing with you and suggesting that we should do EXACTLY wh= at SSL/TLS does - create a default set, and an extension mechanism for thos= e which don't support the default set. See the referenced link in my pr= evious email.

Cheers,

- johnk

Breno wrote:



On Thu, Sep 24, 2009 at 3:07 PM, John Kemp <john@jkemp.net <mailto:john@jkemp.net>> wrote:

=A0 =A0Breno wrote:

=A0 =A0 =A0 =A0SSL does not provide such guidance and yet there is wide =A0 =A0 =A0 =A0interoperability.


I think the word guidance was to strong. SSL does not _mandate_ anything as= minimum support.
=A0

=A0 =A0Indeed, see http://tools.ietf.org/html/rfc5246#section-7.4.= 1.4.1

=A0 =A0There are "default sets" of algorithms, but these are not= mandated.
=A0 =A0Instead, if the client either a) supports more algorithms than the<= br> =A0 =A0default set, or b) doesn't support the "default set" = it can send an
=A0 =A0extension parameter describing the algorithms it does support.



=A0 =A0 =A0 =A0The recommendation should be that clients support as many c= rypto
=A0 =A0 =A0 =A0suites as they feel comfortable using, and so should server= s. I
=A0 =A0 =A0 =A0have never heard that SSL has an interoperability problem.<= br>

=A0 =A0I too like the SSL approach, which suggests that OAuth should defin= e
=A0 =A0(one or more) "default algorithm sets", without mandating= it/them.

=A0 =A0I would note further that SSL/TLS decouples hashing algorithm from<= br> =A0 =A0signature algorithm in its text, and as a sidenote, I'd like to= see
=A0 =A0us do that too.

=A0 =A0Regards,


--
Breno de Medeiros





--
Breno de Medeiros
--00148536e6da9f2cc904745a3e7d-- From hallam@gmail.com Thu Sep 24 19:34:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9D53A681D for ; Thu, 24 Sep 2009 19:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=-0.755, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0qiAR6oTgRI for ; Thu, 24 Sep 2009 19:33:53 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 5AD7E3A6879 for ; Thu, 24 Sep 2009 19:33:53 -0700 (PDT) Received: by ywh26 with SMTP id 26so498963ywh.29 for ; Thu, 24 Sep 2009 19:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MxMiZ6Zg8WMfh/p8Dy0Pi3jSz1vTCY+NRogCotmb5e4=; b=vDSk1GExN0jtcK9x4gTe+kJkcuvMiOmAPa6JwzMjHNdxcEuIkPzTAzaQZBLb3/blap 5OhCJMS2iF40OZTLyIDJbg5APUMWuv+4Nm+URA5NPWGhO+xfXF19i4C52i4ClxvltJK1 7wp1c47o8LdJLxNa1NkTYO43dAwe0wJ3yWsnw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o9UpLExBKzjMGpV9gQHV8+dlwJw/g8yd23O8ePhHAbhU2B6qpu/hDB4wGIZ9Jko9ya Gv+Qr/5KmtIHMudRbbHO0VmrkTzuU5IzRtTWM+Vpv/+9R90GGAtKRzI/ZMFwIZx9EG1s 4Q3Kka61rnKwym5CmNCBiOO5AqneoXD5YMU08= MIME-Version: 1.0 Received: by 10.90.220.4 with SMTP id s4mr425285agg.3.1253846099712; Thu, 24 Sep 2009 19:34:59 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4ABBEDA8.6090506@jkemp.net> <4ABBF00E.5030702@jkemp.net> Date: Thu, 24 Sep 2009 22:34:59 -0400 Message-ID: From: Phillip Hallam-Baker To: Breno Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 02:34:00 -0000 There is many years of experience doing this in the IETF. The SSL approach is not recommended. In fact it is a PITA, ask the TLS working group. Cipher suites are a bit better than mix and match crypto algs. But there is huge complexity there that ONLY REDUCES SECURITY. Case in point is MD5, the fact that browsers must support MD5 despite the fact that it was broken in 1995 enabled a cryptanalytic attack of real certs 18 months back. As it happens you have no real choice here since you can't mandate an algorithm we already have issues with (MD2, MD4, MD5 and SHA-1 are out) and we don't have SHA3 yet. So that leaves SHA2 and HMAC-SHA2. On public key, your options are RSA, DSA and Eliptic Curve variations there= of. Now I know that the weakness of SHA1 does not affect HMAC-SHA1, but you still can't use it for the same reason that you can't use my HTTP-DIGEST algorithm based on MD5 but not vulnerable to the MD5 compression weakness. Even if you can prove it is secure, it is just too expensive to keep having to prove it over and over again. On Thu, Sep 24, 2009 at 6:20 PM, Breno wrote: > Just to make sure that my answer is understood as endoring John's > suggestion. We should do EXACTLY what SSL/TLS does. > > ---------- Forwarded message ---------- > From: John Kemp > Date: Thu, Sep 24, 2009 at 3:17 PM > Subject: Re: [OAUTH-WG] Mandatory signature algorithms? > To: Breno > > > Hi Breno, > > I was roughly agreeing with you and suggesting that we should do EXACTLY > what SSL/TLS does - create a default set, and an extension mechanism for > those which don't support the default set. See the referenced link in my > previous email. > > Cheers, > > - johnk > > Breno wrote: >> >> >> On Thu, Sep 24, 2009 at 3:07 PM, John Kemp > > wrote: >> >> =A0 =A0Breno wrote: >> >> =A0 =A0 =A0 =A0SSL does not provide such guidance and yet there is wide >> =A0 =A0 =A0 =A0interoperability. >> >> >> I think the word guidance was to strong. SSL does not _mandate_ anything >> as minimum support. >> >> >> =A0 =A0Indeed, see http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 >> >> =A0 =A0There are "default sets" of algorithms, but these are not mandate= d. >> =A0 =A0Instead, if the client either a) supports more algorithms than th= e >> =A0 =A0default set, or b) doesn't support the "default set" it can send = an >> =A0 =A0extension parameter describing the algorithms it does support. >> >> >> >> =A0 =A0 =A0 =A0The recommendation should be that clients support as many= crypto >> =A0 =A0 =A0 =A0suites as they feel comfortable using, and so should serv= ers. I >> =A0 =A0 =A0 =A0have never heard that SSL has an interoperability problem= . >> >> >> =A0 =A0I too like the SSL approach, which suggests that OAuth should def= ine >> =A0 =A0(one or more) "default algorithm sets", without mandating it/them= . >> >> =A0 =A0I would note further that SSL/TLS decouples hashing algorithm fro= m >> =A0 =A0signature algorithm in its text, and as a sidenote, I'd like to s= ee >> =A0 =A0us do that too. >> >> =A0 =A0Regards, >> >> >> -- >> Breno de Medeiros >> > > > > > -- > Breno de Medeiros > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From eran@hueniverse.com Thu Sep 24 19:52:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B085D3A6405 for ; Thu, 24 Sep 2009 19:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.844 X-Spam-Level: X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-1.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stqA+ySJpPdr for ; Thu, 24 Sep 2009 19:52:42 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E79433A680A for ; Thu, 24 Sep 2009 19:52:41 -0700 (PDT) Received: (qmail 10012 invoked from network); 25 Sep 2009 02:53:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Sep 2009 02:53:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 24 Sep 2009 19:53:50 -0700 From: Eran Hammer-Lahav To: John Kemp , Hubert Le Van Gong Date: Thu, 24 Sep 2009 19:53:40 -0700 Thread-Topic: [OAUTH-WG] Mandatory signature algorithms? Thread-Index: Aco9YE2LLRYtph5rR7a/9u5+1VSIagAKuL7Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> In-Reply-To: <4ABBE85C.3030301@jkemp.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@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 02:52:42 -0000 The one method I am sure we are going to support is a plaintext method. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of John Kemp > Sent: Thursday, September 24, 2009 2:45 PM > To: Hubert Le Van Gong > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Mandatory signature algorithms? >=20 > Hubert Le Van Gong wrote: > > Reading the latest draft I see we do not mandate a minimum set of > > signature algorithms. >=20 > Does the "minimum set" include PLAINTEXT (ie. unsigned)? >=20 > Regards, >=20 > - johnk >=20 > > I think we should mandate a few (at least one) so we get a minimum of > > interoperability > > out of the box. > > Thoughts? > > > > Cheers, > > Hubert > > _______________________________________________ > > 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 rbarnes@bbn.com Thu Sep 24 20:14:20 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A013A6847 for ; Thu, 24 Sep 2009 20:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Jyu9KpPwu0V for ; Thu, 24 Sep 2009 20:14:19 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 858003A680F for ; Thu, 24 Sep 2009 20:14:19 -0700 (PDT) Received: from [128.89.253.54] (helo=col-rbarnes-l1.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Mr0LH-0004VA-DY; Thu, 24 Sep 2009 22:15:27 -0400 Message-ID: <4ABC35CE.5010309@bbn.com> Date: Thu, 24 Sep 2009 23:15:26 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 03:14:20 -0000 Eran, Naïve question: What advantage would that have over HTTP Basic authentication? Not requiring Base64? --Richard Eran Hammer-Lahav wrote: > The one method I am sure we are going to support is a plaintext method. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of John Kemp >> Sent: Thursday, September 24, 2009 2:45 PM >> To: Hubert Le Van Gong >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Mandatory signature algorithms? >> >> Hubert Le Van Gong wrote: >>> Reading the latest draft I see we do not mandate a minimum set of >>> signature algorithms. >> Does the "minimum set" include PLAINTEXT (ie. unsigned)? >> >> Regards, >> >> - johnk >> >>> I think we should mandate a few (at least one) so we get a minimum of >>> interoperability >>> out of the box. >>> Thoughts? >>> >>> Cheers, >>> Hubert >>> _______________________________________________ >>> 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 Pasi.Eronen@nokia.com Thu Sep 24 22:46:54 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47F028C0D7 for ; Thu, 24 Sep 2009 22:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBHYznQY1C4I for ; Thu, 24 Sep 2009 22:46:53 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 39E693A67B0 for ; Thu, 24 Sep 2009 22:46:52 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8P5lePs027167; Fri, 25 Sep 2009 08:47:44 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 08:47:39 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 08:47:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 08:47:30 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 25 Sep 2009 07:47:29 +0200 From: To: Date: Fri, 25 Sep 2009 07:47:27 +0200 Thread-Topic: [OAUTH-WG] Mandatory signature algorithms? Thread-Index: Aco9ZEt+1mOiVwLgQo2EwxE/SEh2wwAPvDfw Message-ID: <808FD6E27AD4884E94820BC333B2DB773C096DD112@NOK-EUMSG-01.mgdnok.nokia.com> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D5858F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4ABBEDA8.6090506@jkemp.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_808FD6E27AD4884E94820BC333B2DB773C096DD112NOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Sep 2009 05:47:30.0476 (UTC) FILETIME=[ABCCA6C0:01CA3DA3] X-Nokia-AV: Clean Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 05:46:54 -0000 --_000_808FD6E27AD4884E94820BC333B2DB773C096DD112NOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Breno, RFC 5246 does specify a mandatory-to-implement cipher suite: http://tools.ietf.org/html/rfc5246#section-9 Best regards, Pasi From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of e= xt Breno Sent: 25 September, 2009 01:14 To: John Kemp Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? On Thu, Sep 24, 2009 at 3:07 PM, John Kemp > wrote: Breno wrote: SSL does not provide such guidance and yet there is wide interoperability. I think the word guidance was to strong. SSL does not _mandate_ anything as= minimum support. Indeed, see http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 There are "default sets" of algorithms, but these are not mandated. Instead= , if the client either a) supports more algorithms than the default set, or= b) doesn't support the "default set" it can send an extension parameter de= scribing the algorithms it does support. The recommendation should be that clients support as many crypto suites as = they feel comfortable using, and so should servers. I have never heard that= SSL has an interoperability problem. I too like the SSL approach, which suggests that OAuth should define (one o= r more) "default algorithm sets", without mandating it/them. I would note further that SSL/TLS decouples hashing algorithm from signatur= e algorithm in its text, and as a sidenote, I'd like to see us do that too. Regards, -- Breno de Medeiros --_000_808FD6E27AD4884E94820BC333B2DB773C096DD112NOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Breno,

 

RFC 5246 does specify a mandatory-to-implement cipher suite:=

http://tools.ietf.org/html/rfc5246#section-9

 

Best regards,

Pasi

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = ext Breno
Sent: 25 September, 2009 01:14
To: John Kemp
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Mandatory signature algorithms?

 

 

On Thu, Sep 24, 2009 at 3:07 PM, John Kemp <john@jkemp.net> wrote:

Breno wrote:

SSL does not provide such guidance and yet there is wi= de interoperability.


I think the word guidance was to strong. SSL does not _mandate_ anything as minimum support.
 

 

Indeed, see http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1

There are "default sets" of algorithms, but these are not mandate= d. Instead, if the client either a) supports more algorithms than the default = set, or b) doesn't support the "default set" it can send an extension parameter describing the algorithms it does support.

 


The recommendation should be that clients support as many crypto suites as = they feel comfortable using, and so should servers. I have never heard that SSL = has an interoperability problem.

 

I too like the SSL appr= oach, which suggests that OAuth should define (one or more) "default algorit= hm sets", without mandating it/them.

I would note further that SSL/TLS decouples hashing algorithm from signatur= e algorithm in its text, and as a sidenote, I'd like to see us do that too.
Regards,


--
Breno de Medeiros

--_000_808FD6E27AD4884E94820BC333B2DB773C096DD112NOKEUMSG01mgd_-- From eran@hueniverse.com Thu Sep 24 23:12:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD7A28C114 for ; Thu, 24 Sep 2009 23:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.822 X-Spam-Level: X-Spam-Status: No, score=-3.822 tagged_above=-999 required=5 tests=[AWL=-1.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7be-c73l0JL8 for ; Thu, 24 Sep 2009 23:12:13 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EAA4528C0F3 for ; Thu, 24 Sep 2009 23:12:12 -0700 (PDT) Received: (qmail 3479 invoked from network); 25 Sep 2009 06:13:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Sep 2009 06:13:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 24 Sep 2009 23:11:03 -0700 From: Eran Hammer-Lahav To: Richard Barnes Date: Thu, 24 Sep 2009 23:13:05 -0700 Thread-Topic: [OAUTH-WG] Mandatory signature algorithms? Thread-Index: Aco9jnAjdZdqCjZpRHKaW0w6MDDjuwAGFJ5w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D58C8A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4ABC35CE.5010309@bbn.com> In-Reply-To: <4ABC35CE.5010309@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 06:12:14 -0000 At a minimum you need to send over the token credentials and client credent= ials. It doesn't make much sense to abuse Basic auth and force all this inf= ormation into the username:password pattern. In addition, a resource may su= pport multiple authentication methods in which both Basic auth is available= using the actual username and password, as well as OAuth using a token. It is just a completely different task (direct access vs. delegated access)= . EHL > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, September 24, 2009 8:15 PM > To: Eran Hammer-Lahav > Cc: John Kemp; Hubert Le Van Gong; oauth@ietf.org > Subject: Re: [OAUTH-WG] Mandatory signature algorithms? >=20 > Eran, >=20 > Na=EFve question: What advantage would that have over HTTP Basic > authentication? Not requiring Base64? >=20 > --Richard >=20 >=20 >=20 > Eran Hammer-Lahav wrote: > > The one method I am sure we are going to support is a plaintext > method. > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> Of John Kemp > >> Sent: Thursday, September 24, 2009 2:45 PM > >> To: Hubert Le Van Gong > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Mandatory signature algorithms? > >> > >> Hubert Le Van Gong wrote: > >>> Reading the latest draft I see we do not mandate a minimum set of > >>> signature algorithms. > >> Does the "minimum set" include PLAINTEXT (ie. unsigned)? > >> > >> Regards, > >> > >> - johnk > >> > >>> I think we should mandate a few (at least one) so we get a minimum > of > >>> interoperability > >>> out of the box. > >>> Thoughts? > >>> > >>> Cheers, > >>> Hubert > >>> _______________________________________________ > >>> 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 breno.demedeiros@gmail.com Thu Sep 24 23:56:33 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01FC28C0D7 for ; Thu, 24 Sep 2009 23:56:33 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akQ4BcLQH6IP for ; Thu, 24 Sep 2009 23:56:32 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 386FE3A68B5 for ; Thu, 24 Sep 2009 23:56:32 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 8so957602qwh.31 for ; Thu, 24 Sep 2009 23:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZjurqJiPV5IKlv/A5SaVA6xXsqO1MuL4xrePbO6X5fk=; b=r8JK0m31sgyuzEBR1oGG83LJkXUmEQKtE8DbI8mZURQOBYuV2f1njoSkSg264boWEb bkK2phtLolSXUMXMaMVcNjS9e3iX0LKBWqpYFGug6JATuh9ByyUgYI8jerHmq/M7jf09 QNQL4xw5AKCUM9joagOPUhddDVcUsyI3sM86s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y7M3Gh6WrZcqhFs0EAuvcTbge03DtusRFQTWSSdvPhFuR9xsuwB3uc+wYGzybJfb76 5F5aIBjI5BqxjP57vH85uhluv682B6IWlf4uNztnZS0BBk0GCH5N3Hp2l47eTTx5Zzpd G4zC3Bxcnjcrf8ck65aMQCMPTSpbWtTNDA3a4= MIME-Version: 1.0 Received: by 10.229.23.4 with SMTP id p4mr2087444qcb.84.1253861858866; Thu, 24 Sep 2009 23:57:38 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58B6B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3628627928A9154A9556BAD87E30C6F4025265B5@TK5EX14MBXC120.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58BAE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4ABBEDA8.6090506@jkemp.net> <4ABBF00E.5030702@jkemp.net> Date: Thu, 24 Sep 2009 23:57:38 -0700 Message-ID: From: Breno To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=0016364ed1d8b1f75904746176a0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Fwd: Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 06:56:34 -0000 --0016364ed1d8b1f75904746176a0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 24, 2009 at 7:34 PM, Phillip Hallam-Baker wrote: > There is many years of experience doing this in the IETF. > > The SSL approach is not recommended. In fact it is a PITA, ask the TLS > working group. Cipher suites are a bit better than mix and match > crypto algs. But there is huge complexity there that ONLY REDUCES > SECURITY. > > I am not arguing that it enhances security. I am arguing that we need a way to update clients and servers, and without negotiation or crypto agility this is cumbersome. Recently we did witness a debacle about updating the OAuth workflow from 1.0 to 1.0a without stepping the protocol version. It can be easier to adopt more secure cryptography as it becomes available as well. > > Case in point is MD5, the fact that browsers must support MD5 despite > the fact that it was broken in 1995 enabled a cryptanalytic attack of > real certs 18 months back. > You mean the fact that browsers engage in a race to the bottom to work with sites no matter how broken they are. As many of us have noticed, restricting the set of algorithms in our browsers (must browsers allow you to do this) still allow use of the vast majority of the sites in the Internet. > > As it happens you have no real choice here since you can't mandate an > algorithm we already have issues with (MD2, MD4, MD5 and SHA-1 are > out) and we don't have SHA3 yet. So that leaves SHA2 and HMAC-SHA2. > > SHA-1 is broken in theory because it has shown to have less security than the precise bound given by its length. Unlike attacks against MD-5, they are impractical. I would not recommend RSA-SHA1 which uses SHA-1 as a pure hash function, but HMAC-SHA1 seems quite safe at this point. > On public key, your options are RSA, DSA and Eliptic Curve variations > thereof. > > You mean everything :) > > Now I know that the weakness of SHA1 does not affect HMAC-SHA1, but > you still can't use it for the same reason that you can't use my > HTTP-DIGEST algorithm based on MD5 but not vulnerable to the MD5 > compression weakness. Even if you can prove it is secure, it is just > too expensive to keep having to prove it over and over again. > Unlike HTTP-DIGEST algorithm, the conditions under which HMAC are secure are quite well understood. No new proofs are needed. > > > On Thu, Sep 24, 2009 at 6:20 PM, Breno wrote: > > Just to make sure that my answer is understood as endoring John's > > suggestion. We should do EXACTLY what SSL/TLS does. > > > > ---------- Forwarded message ---------- > > From: John Kemp > > Date: Thu, Sep 24, 2009 at 3:17 PM > > Subject: Re: [OAUTH-WG] Mandatory signature algorithms? > > To: Breno > > > > > > Hi Breno, > > > > I was roughly agreeing with you and suggesting that we should do EXACTLY > > what SSL/TLS does - create a default set, and an extension mechanism for > > those which don't support the default set. See the referenced link in my > > previous email. > > > > Cheers, > > > > - johnk > > > > Breno wrote: > >> > >> > >> On Thu, Sep 24, 2009 at 3:07 PM, John Kemp >> > wrote: > >> > >> Breno wrote: > >> > >> SSL does not provide such guidance and yet there is wide > >> interoperability. > >> > >> > >> I think the word guidance was to strong. SSL does not _mandate_ anything > >> as minimum support. > >> > >> > >> Indeed, see http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 > >> > >> There are "default sets" of algorithms, but these are not mandated. > >> Instead, if the client either a) supports more algorithms than the > >> default set, or b) doesn't support the "default set" it can send an > >> extension parameter describing the algorithms it does support. > >> > >> > >> > >> The recommendation should be that clients support as many crypto > >> suites as they feel comfortable using, and so should servers. I > >> have never heard that SSL has an interoperability problem. > >> > >> > >> I too like the SSL approach, which suggests that OAuth should define > >> (one or more) "default algorithm sets", without mandating it/them. > >> > >> I would note further that SSL/TLS decouples hashing algorithm from > >> signature algorithm in its text, and as a sidenote, I'd like to see > >> us do that too. > >> > >> Regards, > >> > >> > >> -- > >> Breno de Medeiros > >> > > > > > > > > > > -- > > Breno de Medeiros > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > -- > -- > New Website: http://hallambaker.com/ > View Quantum of Stupid podcasts, Tuesday and Thursday each week, > http://quantumofstupid.com/ > -- Breno de Medeiros --0016364ed1d8b1f75904746176a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 24, 2009 at 7:34 PM, Phillip= Hallam-Baker <hal= lam@gmail.com> wrote:
There is many years of experience doing this in the IETF.

The SSL approach is not recommended. In fact it is a PITA, ask the TLS
working group. Cipher suites are a bit better than mix and match
crypto algs. But there is huge complexity there that ONLY REDUCES
SECURITY.


I am not arguing that it enhances secu= rity. I am arguing that we need a way to update clients and servers, and wi= thout negotiation or crypto agility this is cumbersome. Recently we did wit= ness a debacle about updating the OAuth workflow from 1.0 to 1.0a without s= tepping the protocol version. It can be easier to adopt more secure cryptog= raphy as it becomes available as well.

=A0

Case in point is MD5, the fact that browsers must support MD5 despite
the fact that it was broken in 1995 enabled a cryptanalytic attack of
real certs 18 months back.

You mean the= fact that browsers engage in a race to the bottom to work with sites no ma= tter how broken they are. As many of us have noticed, restricting the set o= f algorithms in our browsers (must browsers allow you to do this) still all= ow use of the vast majority of the sites in the Internet.
=A0

As it happens you have no real choice here since you can't mandate an algorithm we already have issues with (MD2, MD4, MD5 and SHA-1 are
out) and we don't have SHA3 yet. So that leaves SHA2 and HMAC-SHA2.


SHA-1 is broken in theory because it h= as shown to have less security than the precise bound given by its length. = Unlike attacks against MD-5, they are impractical.

I would not recommend RSA-SHA1 which uses SHA-1 as a pure hash functio= n, but HMAC-SHA1 seems quite safe at this point.
=A0
On public key, your options are RSA, DSA and Eliptic Curve variations there= of.


You mean everything :)
=A0

Now I know that the weakness of SHA1 does not affect HMAC-SHA1, but
you still can't use it for the same reason that you can't use my HTTP-DIGEST algorithm based on MD5 but not vulnerable to the MD5
compression weakness. Even if you can prove it is secure, it is just
too expensive to keep having to prove it over and over again.

Unlike HTTP-DIGEST algorithm, the conditions under w= hich HMAC are secure are quite well understood. No new proofs are needed.
=A0


On Thu, Sep 24, 2009 at 6:20 PM, Breno <breno.demedeiros@gmail.com> wrote:
> Just to make sure that my answer is understood as endoring John's<= br> > suggestion. We should do EXACTLY what SSL/TLS does.
>
> ---------- Forwarded message ----------
> From: John Kemp <john@jkemp.net>
> Date: Thu, Sep 24, 2009 at 3:17 PM
> Subject: Re: [OAUTH-WG] Mandatory signature algorithms?
> To: Breno <breno.deme= deiros@gmail.com>
>
>
> Hi Breno,
>
> I was roughly agreeing with you and suggesting that we should do EXACT= LY
> what SSL/TLS does - create a default set, and an extension mechanism f= or
> those which don't support the default set. See the referenced link= in my
> previous email.
>
> Cheers,
>
> - johnk
>
> Breno wrote:
>>
>>
>> On Thu, Sep 24, 2009 at 3:07 PM, John Kemp <john@jkemp.net
>> <mailto:john@jkemp.net>= ;> wrote:
>>
>> =A0 =A0Breno wrote:
>>
>> =A0 =A0 =A0 =A0SSL does not provide such guidance and yet there is= wide
>> =A0 =A0 =A0 =A0interoperability.
>>
>>
>> I think the word guidance was to strong. SSL does not _mandate_ an= ything
>> as minimum support.
>>
>>
>> =A0 =A0Indeed, see http://tools.ietf.org/html/rfc5246#sect= ion-7.4.1.4.1
>>
>> =A0 =A0There are "default sets" of algorithms, but these= are not mandated.
>> =A0 =A0Instead, if the client either a) supports more algorithms t= han the
>> =A0 =A0default set, or b) doesn't support the "default se= t" it can send an
>> =A0 =A0extension parameter describing the algorithms it does suppo= rt.
>>
>>
>>
>> =A0 =A0 =A0 =A0The recommendation should be that clients support a= s many crypto
>> =A0 =A0 =A0 =A0suites as they feel comfortable using, and so shoul= d servers. I
>> =A0 =A0 =A0 =A0have never heard that SSL has an interoperability p= roblem.
>>
>>
>> =A0 =A0I too like the SSL approach, which suggests that OAuth shou= ld define
>> =A0 =A0(one or more) "default algorithm sets", without m= andating it/them.
>>
>> =A0 =A0I would note further that SSL/TLS decouples hashing algorit= hm from
>> =A0 =A0signature algorithm in its text, and as a sidenote, I'd= like to see
>> =A0 =A0us do that too.
>>
>> =A0 =A0Regards,
>>
>>
>> --
>> Breno de Medeiros
>>
>
>
>
>
> --
> Breno de Medeiros
>
>
> ________________________________________= _______
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>



--
--
New Website: http://h= allambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofs= tupid.com/



--
Breno de Me= deiros

--0016364ed1d8b1f75904746176a0-- From breno.demedeiros@gmail.com Fri Sep 25 08:08:24 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E1228C123 for ; Fri, 25 Sep 2009 08:08:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS2sDIXTeJE7 for ; Fri, 25 Sep 2009 08:08:23 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id DA0B828C15D for ; Fri, 25 Sep 2009 08:08:22 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so52216qwi.31 for ; Fri, 25 Sep 2009 08:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WoyzRuKJclKA2bq/mXbWPj1v+THS9bmsdobkR0kjL04=; b=XkbOVyS/rgfmqIa7HNp2f0EkzykWEH3LTYpHMhvhhHb6IiK+HuW+Qj9avt0/ACnxB2 DS+VDGcHw4URc9JkEYVYWz35IeNbU1NRV3fnI0LFHwKQ4xCRaYxDOgcsOm+8i06xo7JH 3/TqVw4l/DzuNNALMcUJIZqTTlnPDHlfLDqMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cvONQ8sgI3lUfe4qlTFYs57jgNPIm29V3PECe7bcHsPBITScNI7XucbtwoPVN4to7A 7qKvo4lP6UoKPfzsYFT3M65vBzwUdFNiaDoiKNjSxn4hg53JZv6uioTeCkXsX9QirmbT y3MENDDjkIkDaUqlidaVy9NR94WjtZ8ZJa0aM= MIME-Version: 1.0 Received: by 10.229.43.79 with SMTP id v15mr210264qce.40.1253891369442; Fri, 25 Sep 2009 08:09:29 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 25 Sep 2009 08:09:29 -0700 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00148536e6daa9a04d0474685530 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 15:08:24 -0000 --00148536e6daa9a04d0474685530 Content-Type: text/plain; charset=ISO-8859-1 This is another argument against trying to do better than TLS, since OAuth does not define its own encryption transport mechanism. Insecurity concerns about TLS are quite manageable by those who care about security. You can profile TLS at your will. For instance, to make your FF compliant with FIPS-140-2 TLS profile, follow the instructions here: http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-2?style_mode=inproduct&s=cipher%20suites On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav wrote: > The one method I am sure we are going to support is a plaintext method. > > -- Breno de Medeiros --00148536e6daa9a04d0474685530 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is another argument against trying to do better than TLS, since OAuth = does not define its own encryption transport mechanism.

Insecurity c= oncerns about TLS are quite manageable by those who care about security. Yo= u can profile TLS at your will. For instance, to make your FF compliant wit= h FIPS-140-2 TLS profile, follow the instructions here:

http://support.m= ozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-2?style_mode=3Dinprodu= ct&s=3Dcipher%20suites

On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer= -Lahav <eran@hu= eniverse.com> wrote:
The one method I am sure we are going to support is a plaintext method.



--
Breno de Medeiros
--00148536e6daa9a04d0474685530-- From jricher@mitre.org Fri Sep 25 10:41:02 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7970F3A6939 for ; Fri, 25 Sep 2009 10:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9uu5iCJzCBU for ; Fri, 25 Sep 2009 10:41:01 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 4A7643A68A7 for ; Fri, 25 Sep 2009 10:41:01 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n8PHgBGf002159 for ; Fri, 25 Sep 2009 13:42:12 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n8PHgBHN002156; Fri, 25 Sep 2009 13:42:11 -0400 Received: from [129.83.50.47] (129.83.50.47) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.1.375.2; Fri, 25 Sep 2009 13:42:11 -0400 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D58B9F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B72@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80909241103v4d3bffacyed7e74efe6922d00@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58B9F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain Date: Fri, 25 Sep 2009 13:42:11 -0400 Message-ID: <1253900531.4748.18.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 17:41:02 -0000 It is significantly easier to script a client library like these using HTTP parameters, and I have had a couple cases where all I had was a "get" style request to work with on my client. Using URLparams I was able to script this quite well, but if I needed to get into the headers, I wouldn't be able to do it. I vote for having the auth headers be the recommended mode but for the parameters to stay around. -- justin On Thu, 2009-09-24 at 14:24 -0400, Eran Hammer-Lahav wrote: > No, we are simply sending a message to browser vendors that they should add native support. It is one thing when a small community comes out with a spec and a whole other thing when the IETF publishes a new internet standard. > > Also, the fact that we will have the 1.0 spec published as an information RFC will help because it will give an alternative to this new work in cases where it is not possible to implement. > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Ethan Jewett > > Sent: Thursday, September 24, 2009 11:04 AM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth and HTTP caching > > > > Thinking back ... wasn't one of the primary reasons for having a way > > to pass the authentication parameters that didn't involve the headers > > because in-browser javascript doesn't have access to the headers? > > > > Now, I don't think there are a lot of applications currently using > > OAuth to authenticate an in-browser client application directly to a > > server, but with the advent of mechanisms for cross-domain requests in > > HTML5 and through hacks like iFrame proxies, this might become more > > common. If we require authorization headers are we precluding the use > > of OAuth on the browser platform? > > > > Ethan > > > > On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav > > wrote: > > > This means that we really only have two options: > > > > > > 1. Use only the HTTP Authorization header to pass authentication > > parameters from the client to the server. This means dropping support > > for URI query parameters and form-encoded body parameters. > > > 2. Drop support for form-encoded parameters, recommend using HTTP > > headers or require additional headers when using URI query parameters. > > > > > > Of course, #2 defeats the purpose because the only reason to keep URI > > query parameters is to avoid the need to set headers... > > > > > > Are there any *documented* reasons why we should not just limit OAuth > > to transmit parameters over HTTP Authorization headers? > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > > >> Sent: Tuesday, September 22, 2009 10:48 AM > > >> To: Eran Hammer-Lahav > > >> Cc: John Panzer; oauth@ietf.org; ietf-http-wg@w3.org Group > > >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching > > >> > > >> On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: > > >> > > >> >> -----Original Message----- > > >> >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > > >> >> Sent: Tuesday, September 22, 2009 10:09 AM > > >> > > > >> >> Just follow the HTTP spec. > > >> > > > >> > That what I am trying to figure out... > > >> > > > >> > Does the HTTP spec mandates that new authentication protocols use > > >> > the WWW-Authenticate and Authorization headers? > > >> > > >> HTTP is not aware of any other kinds of authentication. There is no > > >> reason > > >> to specify anything else. > > >> > > >> > Are the headers required for existing caches and servers to > > operate > > >> > properly? > > >> > > >> Yes (and for user agents as well). Don't forget about Proxy-Auth*. > > >> > > >> > If they are not included in authenticated requests, are there > > other > > >> > requirements to make sure it doesn't break existing deployment? > > >> > > >> Cache-control: private > > >> > > >> is probably needed if the Auth headers are not being used but the > > >> response depends on something like cookies for authentication. > > >> > > >> ....Roy > > > > > > _______________________________________________ > > > 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 esjewett@gmail.com Fri Sep 25 11:14:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D55D3A6A7E for ; Fri, 25 Sep 2009 11:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ+PT95y1PLT for ; Fri, 25 Sep 2009 11:14:45 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id 474863A6A7A for ; Fri, 25 Sep 2009 11:14:45 -0700 (PDT) Received: by vws34 with SMTP id 34so2004303vws.32 for ; Fri, 25 Sep 2009 11:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BR8syKDcSvvREycYjnnkVWG3MexhskH3r02EqG8IEtA=; b=ZYau/0I2Ls6TGz2Fu7gx28gIfMuvpW3WPQBor2oeZ7xFZqy2FlZ45f5fbsKyAy56DU 3SyexJNZkq3lAs44a/B+WRrQIGYZREPNELcXP36P0Eg1gXhfaGvkN0oUNWVYBI1a2gKz XcrB2jERamwf66sYtDJXRkYfe6jaSDPVm6OZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=d4OA+UQaFwixzLTp1WVNseasSvAy9cSE3LGjSdWHJRY4Z/6GteDcmqV/lSyJTbkbzD 4oRcxYxk/VB8BEB7m6NF2SAPTsuBzkqpwwAjBVIF+EpGYxIQNtnif0f+pyCzpi/hHbod cJZL6/nk/6eQdpjK6sh5qEFjJFaVrHVsrFBOI= MIME-Version: 1.0 Received: by 10.220.78.205 with SMTP id m13mr795754vck.61.1253902552742; Fri, 25 Sep 2009 11:15:52 -0700 (PDT) In-Reply-To: References: <5ad3ea8b-1c05-471d-8c77-2d3404302623@l34g2000vba.googlegroups.com> <29fb00360909250848k722c308dv2ec1f76b5f1e104d@mail.gmail.com> <68f4a0e80909251039h1dd3f2e4ud33a27c3982cc371@mail.gmail.com> Date: Fri, 25 Sep 2009 13:15:52 -0500 Message-ID: <68f4a0e80909251115j556c73e0yd9166afe9ef50e4e@mail.gmail.com> From: Ethan Jewett To: oauth@googlegroups.com, oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] [oauth] Re: Consideration about oauth_verifier X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 18:14:46 -0000 Hi Breno, True, and I'd forgotten about that nuance.So I suppose consumers/clients should no longer relying on cookies at their callback URLs, but actually requiring the user to log in again over a protected connection (outside of the OAuth flow). I'm starting to think that there might not be enough guidance on this topic in the actual spec as there are a lot of places that a client/consumer implementor can still go wrong and appear to be in compliance. I'm cc'ing the IETF list, as it seems that would be the forum to get further guidance into the spec. Ethan On Fri, Sep 25, 2009 at 1:03 PM, Breno wrote: > Hi Ethan, > > I agree with the assessment, i.e., that XSRF protections can in theory > prevent against interception attacks. In practice, however, a MitM attacker > would typically have access to cookies and so in practice would 'own' the > user's account at the consumer already. No matter how you look at it, a MitM > attacker is too powerful a scenario. > > On Fri, Sep 25, 2009 at 10:39 AM, Ethan Jewett wrote: >> >> Hi Breno and Simone, >> >> I disagree. I believe that in order to perform a MITM attack against >> properly implemented 1.0a, the MITM would need to intercept the >> response *and* be able to prove to the consumer that it is the user >> that originally requested access. In other words, it would have to >> already own the user account on the consumer, meaning that a MITM >> attack would not be necessary at all. >> >> By "properly implemented", I mean that the consumer application checks >> that the user who is redirected back to the consumer is the same user >> that initiated the authentication request, usually by requiring the >> user to be logged in at the callback URL. >> >> Looking back at the spec, this is probably not clear in the body of >> the spec, but is addressed in the security considerations section. For >> example: >> http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01#section-8.6 >> >> Ethan >> >> On Fri, Sep 25, 2009 at 10:48 AM, Breno de Medeiros >> wrote: >> > >> > Hi Simone, >> > >> > Yes, interception is possible. Note, however, that the URL to return >> > the user to is signed in the consumer's initial request, so it is not >> > possible to mis-direct the user. So to intercept the response the >> > attacker needs to perform a Man-in-the-Middle attack. Typical >> > protections against MitM can then be used (e.g., use SSL at the >> > provider and consumer endpoints). >> > >> > >> > >> > On Fri, Sep 25, 2009 at 7:46 AM, Simone wrote: >> >> >> >> Hi. I would ask you a thing about the unguessable parameter >> >> oauth_verifier. >> >> In the attack at the core 1.0 specification the intruder not have to >> >> intercept anything but only constructs a link for the victim. >> >> In the new version of the protocol core 1.0A, when the service >> >> provider redirects the user to the consumer with the parameter >> >> oauth_verifier, if an intruder intercepts this message with the >> >> oauth_verifier, since the message is in clear, cannot the intruder use >> >> the oauth_verifier and come back him to the consumer for continue a >> >> previous session of the protocol, realizing an attack similar to the >> >> that found in the core 1.0 specification? Is there the assumption that >> >> the message in the redirection (from the user to the consumer) is not >> >> intercepted? >> >> Sure the attack is more difficult than the first one because now are >> >> need some interceptions, but is possible, or not? >> >> > >> >> >> > >> > >> > >> > -- >> > --Breno >> > >> > +1 (650) 214-1007 desk >> > +1 (408) 212-0135 (Grand Central) >> > MTV-41-3 : 383-A >> > PST (GMT-8) / PDT(GMT-7) >> > >> > > >> > >> >> > > > > -- > Breno de Medeiros > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To post to this group, send email to oauth@googlegroups.com > To unsubscribe from this group, send email to > oauth+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/oauth?hl=en > -~----------~----~----~----~------~----~------~--~--- > > From jpanzer@google.com Fri Sep 25 11:31:33 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9E93A6765 for ; Fri, 25 Sep 2009 11:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aju3zoTTYDxx for ; Fri, 25 Sep 2009 11:31:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 950793A6A06 for ; Fri, 25 Sep 2009 11:31:31 -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 n8PIWckR004587 for ; Fri, 25 Sep 2009 11:32:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1253903560; bh=bdxTEoF7hFsFaGnsCguHW71iZ/4=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:X-System-Of-Record; b=cKVx5/ EOgddArO4ok3OoeDuTpyNVuJWTNPJbhKLQSM0ZP5h7BnrVqCH6Z9MNXfzgCpSBvYlnB 3THpdxQo3kUvg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=KtgwIFrx171n3kIrJ24sLRYbf/PrlbrSkcGArOHXB4czst/cZxPS8f1JREntS11I+ Q3lSXrfj5IlPX8umQSB/g== Received: from qw-out-1920.google.com (qwa14.prod.google.com [10.241.193.14]) by wpaz21.hot.corp.google.com with ESMTP id n8PIWamM016733 for ; Fri, 25 Sep 2009 11:32:36 -0700 Received: by qw-out-1920.google.com with SMTP id 14so1061127qwa.38 for ; Fri, 25 Sep 2009 11:32:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.119.7 with SMTP id x7mr504467qcq.22.1253903556184; Fri, 25 Sep 2009 11:32:36 -0700 (PDT) In-Reply-To: <1253900531.4748.18.camel@localhost.localdomain> References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET> <02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784D58B72@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80909241103v4d3bffacyed7e74efe6922d00@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58B9F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1253900531.4748.18.camel@localhost.localdomain> From: John Panzer Date: Fri, 25 Sep 2009 11:32:16 -0700 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=000e0cd5f2500c8fc304746b2c5a X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 18:31:33 -0000 --000e0cd5f2500c8fc304746b2c5a Content-Type: text/plain; charset=ISO-8859-1 Can we get specific? Data points: curl -H (command line) sends any arbitrary header, including Authorization: The client library has similar functionality. There's no reason to do anything special for curl. (Though it'd be awesome to get native OAuth support into curl, of course.) Flash used to be a headache. I'm not up on the newer versions, nor on the market share of the various versions. Javascript can of course use XHR with arbitrary headers, but only to same domain. The HTTP WG's cross domain XHR proposal has a lot of restrictions on headers that can and cannot be sent, but that spec is still in flux and could be changed presumably. Also client side JS on its own is problematic from the standpoint of keeping consumer secrets anyway, and it's not an installed desktop app, so it would probably rely on a proxy for security anyway (as OpenSocial does) thus its limitations don't matter as it would be its proxy that is charged with doing OAuth. Others? -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Fri, Sep 25, 2009 at 10:42 AM, Justin Richer wrote: > It is significantly easier to script a client library like these using > HTTP parameters, and I have had a couple cases where all I had was a > "get" style request to work with on my client. Using URLparams I was > able to script this quite well, but if I needed to get into the headers, > I wouldn't be able to do it. > > I vote for having the auth headers be the recommended mode but for the > parameters to stay around. > > -- justin > > On Thu, 2009-09-24 at 14:24 -0400, Eran Hammer-Lahav wrote: > > No, we are simply sending a message to browser vendors that they should > add native support. It is one thing when a small community comes out with a > spec and a whole other thing when the IETF publishes a new internet > standard. > > > > Also, the fact that we will have the 1.0 spec published as an information > RFC will help because it will give an alternative to this new work in cases > where it is not possible to implement. > > > > EHL > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > > Of Ethan Jewett > > > Sent: Thursday, September 24, 2009 11:04 AM > > > To: oauth@ietf.org > > > Subject: Re: [OAUTH-WG] OAuth and HTTP caching > > > > > > Thinking back ... wasn't one of the primary reasons for having a way > > > to pass the authentication parameters that didn't involve the headers > > > because in-browser javascript doesn't have access to the headers? > > > > > > Now, I don't think there are a lot of applications currently using > > > OAuth to authenticate an in-browser client application directly to a > > > server, but with the advent of mechanisms for cross-domain requests in > > > HTML5 and through hacks like iFrame proxies, this might become more > > > common. If we require authorization headers are we precluding the use > > > of OAuth on the browser platform? > > > > > > Ethan > > > > > > On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav > > > wrote: > > > > This means that we really only have two options: > > > > > > > > 1. Use only the HTTP Authorization header to pass authentication > > > parameters from the client to the server. This means dropping support > > > for URI query parameters and form-encoded body parameters. > > > > 2. Drop support for form-encoded parameters, recommend using HTTP > > > headers or require additional headers when using URI query parameters. > > > > > > > > Of course, #2 defeats the purpose because the only reason to keep URI > > > query parameters is to avoid the need to set headers... > > > > > > > > Are there any *documented* reasons why we should not just limit OAuth > > > to transmit parameters over HTTP Authorization headers? > > > > > > > > EHL > > > > > > > >> -----Original Message----- > > > >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > > > >> Sent: Tuesday, September 22, 2009 10:48 AM > > > >> To: Eran Hammer-Lahav > > > >> Cc: John Panzer; oauth@ietf.org; ietf-http-wg@w3.org Group > > > >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching > > > >> > > > >> On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: > > > >> > > > >> >> -----Original Message----- > > > >> >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > > > >> >> Sent: Tuesday, September 22, 2009 10:09 AM > > > >> > > > > >> >> Just follow the HTTP spec. > > > >> > > > > >> > That what I am trying to figure out... > > > >> > > > > >> > Does the HTTP spec mandates that new authentication protocols use > > > >> > the WWW-Authenticate and Authorization headers? > > > >> > > > >> HTTP is not aware of any other kinds of authentication. There is no > > > >> reason > > > >> to specify anything else. > > > >> > > > >> > Are the headers required for existing caches and servers to > > > operate > > > >> > properly? > > > >> > > > >> Yes (and for user agents as well). Don't forget about Proxy-Auth*. > > > >> > > > >> > If they are not included in authenticated requests, are there > > > other > > > >> > requirements to make sure it doesn't break existing deployment? > > > >> > > > >> Cache-control: private > > > >> > > > >> is probably needed if the Auth headers are not being used but the > > > >> response depends on something like cookies for authentication. > > > >> > > > >> ....Roy > > > > > > > > _______________________________________________ > > > > 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 > --000e0cd5f2500c8fc304746b2c5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can we get specific?

Data points:=A0 curl -H (command line) sends an= y arbitrary header, including Authorization:=A0 The client library has simi= lar functionality.=A0 There's no reason to do anything special for curl= .=A0 (Though it'd be awesome to get native OAuth support into curl, of = course.)

Flash used to be a headache.=A0 I'm not up on the newer versions, n= or on the market share of the various versions.

Javascript can of co= urse use XHR with arbitrary headers, but only to same domain.=A0 The HTTP W= G's cross domain XHR proposal has a lot of restrictions on headers that= can and cannot be sent, but that spec is still in flux and could be change= d presumably.=A0 Also client side JS on its own is problematic from the sta= ndpoint of keeping consumer secrets anyway, and it's not an installed d= esktop app, so it would probably rely on a proxy for security anyway (as Op= enSocial does) thus its limitations don't matter as it would be its pro= xy that is charged with doing OAuth.

Others?

--
John Panzer / Googl= e
jpanzer@google= .com / abs= tractioneer.org / @jpanzer



On Fri, Sep 25, 2009 at 10:42 AM, Justin= Richer <jricher@= mitre.org> wrote:
It is significantly easier to script a client library like these using
HTTP parameters, and I have had a couple cases where all I had was a
"get" style request to work with on my client. Using URLparams I = was
able to script this quite well, but if I needed to get into the headers, I wouldn't be able to do it.

I vote for having the auth headers be the recommended mode but for the
parameters to stay around.

=A0-- justin

On Thu, 2009-09-24 at 14:24 -0400, Eran Hammer-Lahav wrote:
> No, we are simply sending a message to browser vendors that they shoul= d add native support. It is one thing when a small community comes out with= a spec and a whole other thing when the IETF publishes a new internet stan= dard.
>
> Also, the fact that we will have the 1.0 spec published as an informat= ion RFC will help because it will give an alternative to this new work in c= ases where it is not possible to implement.
>
> EHL
>
> > -----Original Message-----
> > From: oauth-bounces@iet= f.org [mailto:oauth-bounces@i= etf.org] On Behalf
> > Of Ethan Jewett
> > Sent: Thursday, September 24, 2009 11:04 AM
> > To: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] OAuth and HTTP caching
> >
> > Thinking back ... wasn't one of the primary reasons for havin= g a way
> > to pass the authentication parameters that didn't involve the= headers
> > because in-browser javascript doesn't have access to the head= ers?
> >
> > Now, I don't think there are a lot of applications currently = using
> > OAuth to authenticate an in-browser client application directly t= o a
> > server, but with the advent of mechanisms for cross-domain reques= ts in
> > HTML5 and through hacks like iFrame proxies, this might become mo= re
> > common. If we require authorization headers are we precluding the= use
> > of OAuth on the browser platform?
> >
> > Ethan
> >
> > On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav
> > <eran@hueniverse.com> wrote:
> > > This means that we really only have two options:
> > >
> > > 1. Use only the HTTP Authorization header to pass authentica= tion
> > parameters from the client to the server. This means dropping sup= port
> > for URI query parameters and form-encoded body parameters.
> > > 2. Drop support for form-encoded parameters, recommend using= HTTP
> > headers or require additional headers when using URI query parame= ters.
> > >
> > > Of course, #2 defeats the purpose because the only reason to= keep URI
> > query parameters is to avoid the need to set headers...
> > >
> > > Are there any *documented* reasons why we should not just li= mit OAuth
> > to transmit parameters over HTTP Authorization headers?
> > >
> > > EHL
> > >
> > >> -----Original Message-----
> > >> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> > >> Sent: Tuesday, September 22, 2009 10:48 AM
> > >> To: Eran Hammer-Lahav
> > >> Cc: John Panzer; oauth= @ietf.org; ietf-http-wg@w3.org Group
> > >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching
> > >>
> > >> On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: > > >>
> > >> >> -----Original Message-----
> > >> >> From: Roy T. Fielding [mailto:fielding@gbiv.com]
> > >> >> Sent: Tuesday, September 22, 2009 10:09 AM
> > >> >
> > >> >> Just follow the HTTP spec.
> > >> >
> > >> > That what I am trying to figure out...
> > >> >
> > >> > Does the HTTP spec mandates that new authentication= protocols use
> > >> > the WWW-Authenticate and Authorization headers?
> > >>
> > >> HTTP is not aware of any other kinds of authentication. = =A0There is no
> > >> reason
> > >> to specify anything else.
> > >>
> > >> > Are the headers required for existing caches and se= rvers to
> > operate
> > >> > properly?
> > >>
> > >> Yes (and for user agents as well). =A0Don't forget a= bout Proxy-Auth*.
> > >>
> > >> > If they are not included in authenticated requests,= are there
> > other
> > >> > requirements to make sure it doesn't break exis= ting deployment?
> > >>
> > >> Cache-control: private
> > >>
> > >> is probably needed if the Auth headers are not being use= d but the
> > >> response depends on something like cookies for authentic= ation.
> > >>
> > >> ....Roy
> > >
> > > _______________________________________________
> > > 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
h= ttps://www.ietf.org/mailman/listinfo/oauth

--000e0cd5f2500c8fc304746b2c5a-- From Bart.bv.Vrancken@alcatel-lucent.be Sun Sep 27 23:16:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7933A6807 for ; Sun, 27 Sep 2009 23:16:25 -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_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sXh6+iMqLSc for ; Sun, 27 Sep 2009 23:16:24 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 35AE33A67D2 for ; Sun, 27 Sep 2009 23:16:23 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n8S6Hce7007706 for ; Mon, 28 Sep 2009 08:17:39 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Sep 2009 08:17:38 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 28 Sep 2009 08:17:37 +0200 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E03FAB5E5@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <1253900531.4748.18.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] OAuth and HTTP caching Thread-Index: Aco+B4ebWjgFykLMTsyPbjey/rhJRQB+krrw References: <90C41DD21FB7C64BB94121FBBC2E72343784D58490@P3PW5EX1MB01.EX1.SECURESERVER.NET><02F0580C-C72D-402B-9734-8CC6648E6485@gbiv.com><90C41DD21FB7C64BB94121FBBC2E72343784D58619@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343784D58B72@P3PW5EX1MB01.EX1.SECURESERVER.NET><68f4a0e80909241103v4d3bffacyed7e74efe6922d00@mail.gmail.com><90C41DD21FB7C64BB94121FBBC2E72343784D58B9F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1253900531.4748.18.camel@localhost.localdomain> From: "Vrancken Bart bv" To: X-OriginalArrivalTime: 28 Sep 2009 06:17:38.0254 (UTC) FILETIME=[608EEEE0:01CA4003] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 X-Mailman-Approved-At: Mon, 28 Sep 2009 05:10:51 -0700 Subject: Re: [OAUTH-WG] OAuth and HTTP caching X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 06:29:58 -0000 I agree with Justin to keep the Request URI Query method in the spec, but we should indicate here the disadvantage to use it, like the problem with caching. If there are different methods that can be used in the spec with a difference in preference, it should be good that the reason is indicated, why a method is preferred or not. Bart Vrancken Bell Labs -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Justin Richer Sent: vrijdag 25 september 2009 19:42 To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth and HTTP caching It is significantly easier to script a client library like these using HTTP parameters, and I have had a couple cases where all I had was a "get" style request to work with on my client. Using URLparams I was able to script this quite well, but if I needed to get into the headers, I wouldn't be able to do it.=20 I vote for having the auth headers be the recommended mode but for the parameters to stay around. -- justin On Thu, 2009-09-24 at 14:24 -0400, Eran Hammer-Lahav wrote: > No, we are simply sending a message to browser vendors that they should add native support. It is one thing when a small community comes out with a spec and a whole other thing when the IETF publishes a new internet standard. >=20 > Also, the fact that we will have the 1.0 spec published as an information RFC will help because it will give an alternative to this new work in cases where it is not possible to implement. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Ethan Jewett > > Sent: Thursday, September 24, 2009 11:04 AM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] OAuth and HTTP caching > >=20 > > Thinking back ... wasn't one of the primary reasons for having a way > > to pass the authentication parameters that didn't involve the headers > > because in-browser javascript doesn't have access to the headers? > >=20 > > Now, I don't think there are a lot of applications currently using > > OAuth to authenticate an in-browser client application directly to a > > server, but with the advent of mechanisms for cross-domain requests in > > HTML5 and through hacks like iFrame proxies, this might become more > > common. If we require authorization headers are we precluding the use > > of OAuth on the browser platform? > >=20 > > Ethan > >=20 > > On Thu, Sep 24, 2009 at 1:55 PM, Eran Hammer-Lahav > > wrote: > > > This means that we really only have two options: > > > > > > 1. Use only the HTTP Authorization header to pass authentication > > parameters from the client to the server. This means dropping support > > for URI query parameters and form-encoded body parameters. > > > 2. Drop support for form-encoded parameters, recommend using HTTP > > headers or require additional headers when using URI query parameters. > > > > > > Of course, #2 defeats the purpose because the only reason to keep URI > > query parameters is to avoid the need to set headers... > > > > > > Are there any *documented* reasons why we should not just limit OAuth > > to transmit parameters over HTTP Authorization headers? > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > > >> Sent: Tuesday, September 22, 2009 10:48 AM > > >> To: Eran Hammer-Lahav > > >> Cc: John Panzer; oauth@ietf.org; ietf-http-wg@w3.org Group > > >> Subject: Re: [OAUTH-WG] OAuth and HTTP caching > > >> > > >> On Sep 22, 2009, at 10:24 AM, Eran Hammer-Lahav wrote: > > >> > > >> >> -----Original Message----- > > >> >> From: Roy T. Fielding [mailto:fielding@gbiv.com] > > >> >> Sent: Tuesday, September 22, 2009 10:09 AM > > >> > > > >> >> Just follow the HTTP spec. > > >> > > > >> > That what I am trying to figure out... > > >> > > > >> > Does the HTTP spec mandates that new authentication protocols use > > >> > the WWW-Authenticate and Authorization headers? > > >> > > >> HTTP is not aware of any other kinds of authentication. There is no > > >> reason > > >> to specify anything else. > > >> > > >> > Are the headers required for existing caches and servers to > > operate > > >> > properly? > > >> > > >> Yes (and for user agents as well). Don't forget about Proxy-Auth*. > > >> > > >> > If they are not included in authenticated requests, are there > > other > > >> > requirements to make sure it doesn't break existing deployment? > > >> > > >> Cache-control: private > > >> > > >> is probably needed if the Auth headers are not being used but the > > >> response depends on something like cookies for authentication. > > >> > > >> ....Roy > > > > > > _______________________________________________ > > > 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 hallam@gmail.com Mon Sep 28 06:27:09 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF19C3A6853 for ; Mon, 28 Sep 2009 06:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=-1.970, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J-B8hVPPAXT for ; Mon, 28 Sep 2009 06:27:08 -0700 (PDT) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id B7CEC3A6958 for ; Mon, 28 Sep 2009 06:27:08 -0700 (PDT) Received: by gxk4 with SMTP id 4so2612352gxk.8 for ; Mon, 28 Sep 2009 06:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=0PDuZWBAy0R/oTDi8mWU9jliigtSBTS1GxwM7ieFkz8=; b=Ig3wDSzrfQMwjIybDglZWUnHOYVD89AIoeq6B7MLsLOE2O4rkDmnXThAXn6yQFCAnu ZDYbNGJIPU01SMlvSyJ6iba8PXlNAzetKMgX8YHe1xdddq/go6WZBhSudEtJCpjce53v ZUhl+kRw3js8IicRE20YIFmn0WJgguHhglqbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FhQvFpwEqA570YL7VK56+9MWZNHHQztZoTITCYJ/jN0aKlBEM5M/6M4ajPhh4EVyvt DcoT9oSMN4L2ku317fpB7r6XqBHL7CVKzTasHBYVZdxVfcM0Jt9spOonT8H8wV/iN/Mo gRdZ2NdgSEx0ZRfC837TXSaydZ9OTaXahgvPI= MIME-Version: 1.0 Received: by 10.90.58.35 with SMTP id g35mr2967669aga.17.1254144504363; Mon, 28 Sep 2009 06:28:24 -0700 (PDT) Date: Mon, 28 Sep 2009 09:28:23 -0400 Message-ID: From: Phillip Hallam-Baker To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Is OAUTH actually open X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 13:27:09 -0000 I have been using a number of OAUTH enabled Web Sites, mostly through use of my Twitter account. What worries me a lot, and what currently disqualifies OAUTH deployments as 'open' is the fact that I can only use the one or two providers that are supported by the relying party site. This would be OK if it was a choice on the part of the relying party site, but as currently specified the scheme does not allow for open selection of identity providers. Only the small number of providers supported by the site will work. I suggest adding one extra dimension to the OAUTH user experience, a box that allows the user to specify their account and provider in RFC822 form - i.e. I would type hallam@twitter.com to use my twitter account. OK so this might not be OAUTH at issue here, but if OAUTH is going to be a security protocol that is designed to interface with users it had better encompass the entire user interface. Yes, I know that this is not the way OpenID do it. They have this strange notion that it is easier to teach every one of the billion Internet users to type in funky URLs than to use the account identifier that they are familiar with. I find the idea that Joe Random User is going to want to log into their fuzzypegs account using their blog ID quite bizarre. At best that would be an edge case. The list of blogs (I have twenty) that the user maintains is at best metadata that might be retrieved along with other identity attributes. And yes, I know that XRI is purportedly there to solve a problem that the IETF has solved just great thirty years ago, and build out a registry for our convenience and their profit. I see zero advantage to XRI. We have a name infrastructure for the Internet, we do not need a second. While I have no particular issue with the way twitter is run today, I want to own and control my own Internet name. The only infrastructure on offer today that allows that is the DNS. Consequently I own hallambaker.com. Playing spymaster with my twitter account is OK, but it puts my ability to play the game at the whim of twitter, a company that has no business model. Clearly they will find a business model at some point, and it might not be one I agree with. All we need to do in the OAUTH specs is to state how to deal with 'everything else'. One big advantage of using the RFC822 address is that many site already use it as a username. They understand that most people who come to their site have forgotten their account name which inevitably varies from site to site. The password on the other hand, is always the same. So people forget account names more often than passwords. Such a site could easily convert to using OAUTH authentication with RFC822 ids. Say I am logging into the dalek enthusiasts site and have forgotten my account info. I give my email address, but instead of doing the usual email callback loop, the site checks to see if gmail.com supports OAUTH and if so lets me use OAUTH for the login and deletes its local password checks altogether. From danbri@danbri.org Mon Sep 28 06:34:38 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECD03A67B4 for ; Mon, 28 Sep 2009 06:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+6qwTUnLBVf for ; Mon, 28 Sep 2009 06:34:37 -0700 (PDT) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id 48EB93A6884 for ; Mon, 28 Sep 2009 06:34:37 -0700 (PDT) Received: by fxm27 with SMTP id 27so1817490fxm.42 for ; Mon, 28 Sep 2009 06:35:51 -0700 (PDT) Received: by 10.204.160.86 with SMTP id m22mr771136bkx.82.1254144950228; Mon, 28 Sep 2009 06:35:50 -0700 (PDT) Received: from ?95.98.200.222? ([95.98.200.222]) by mx.google.com with ESMTPS id 2sm3786407fks.33.2009.09.28.06.35.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Sep 2009 06:35:49 -0700 (PDT) References: Message-Id: <7C2EFD06-F7A8-4525-84CC-50F0848A0821@danbri.org> From: Dan Brickley To: Phillip Hallam-Baker In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7C144) Mime-Version: 1.0 (iPhone Mail 7C144) Date: Mon, 28 Sep 2009 15:35:46 +0200 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is OAUTH actually open X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 13:34:38 -0000 > > Hi Phillip, Re user@domain instead of http:// I suspect you are pushing at an open door. Many in the openid scene seem to have arrived at the same conclusion - search for 'webfinger' for details of a proposal for an email-style account identifier notation, discovery/lookup protocol and draft uri scheme. Cheers, danbri@danbri.org From chris.messina@gmail.com Mon Sep 28 07:18:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC893A6983 for ; Mon, 28 Sep 2009 07:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCjf1U2qTCLR for ; Mon, 28 Sep 2009 07:18:57 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 63C023A681B for ; Mon, 28 Sep 2009 07:18:57 -0700 (PDT) Received: by pxi3 with SMTP id 3so6019416pxi.31 for ; Mon, 28 Sep 2009 07:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YEhnsoxVBDYkuAR/QdWXE3XQPazOjimg0rRwLIn/lOM=; b=UlvUl6jsvwFFed4j7T3xJAF1Xaw/lCW+k1/wc9Y6nPkl0s+5dog+ohsbPj7y000c0r FGGv1frSwKHRz1Y9kS1tWZuokCWDKgcI0R7fXIvD0TmcuWOsowPxm2R0d4nIgKrcux5m 7nldaPyELUdRJA3Cq/wv0mIGQbvtUskqt3AZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OMrOoAMm9UNZffPDkUf0vzAO6IOHFbc3mL0depEDUiAVshS7jQNMOAbEIX7cM16QOZ 6uxsSXO6Icwv86WLKczYDdihM1NzaH+53O8BWuY+S1Is5viWYulh7rCMrzd3STzFR7Bf JYbh66KBUBc/MBIyY09MxduVXKA807oOQ8DVw= MIME-Version: 1.0 Received: by 10.114.252.14 with SMTP id z14mr5942198wah.84.1254147612324; Mon, 28 Sep 2009 07:20:12 -0700 (PDT) In-Reply-To: <7C2EFD06-F7A8-4525-84CC-50F0848A0821@danbri.org> References: <7C2EFD06-F7A8-4525-84CC-50F0848A0821@danbri.org> Date: Mon, 28 Sep 2009 17:20:12 +0300 Message-ID: <1bc4603e0909280720v2070a99fm6c32985bf18d3684@mail.gmail.com> From: Chris Messina To: Dan Brickley Content-Type: multipart/alternative; boundary=0016e687872aedb3600474a3fe0f Cc: Phillip Hallam-Baker , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is OAUTH actually open X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 14:18:58 -0000 --0016e687872aedb3600474a3fe0f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Indeed, the problem is less with OAuth or forcing the use of email-style identifiers for discovery (again, Webfinger is the right thing to point to at this stage, though we already attempted to solve this once before with the less-well-named EAUT ("email-addres to URL translation")) than the problem that OAuth only deals with signatures and tokens =97 not with the design of the API itself. That is, even if you could identify yourself by an email address to some third party advertising using only your email address, and they provided OAuth as the means to do an in-browser request for a token to interact with your account =97 the third party and your data provider still have to speak the same input-output language. Now, perhaps that's using the Twitter API, but what if it isn't? You may have granted the third party a token to acces= s your data, but they have no idea how to speak to your particular data provider. Therefore you have to go much deeper than how you discover your data provider and what form your identifier is in. Presuming we get widespread adoption of an agreed-upon identifier format (which is increasingly looks like URLs and email-style identifiers), you still have to deal with getting parties to use the same API nomenclature. That, it would seem, is the much harder, longer term problem. Chris On Mon, Sep 28, 2009 at 4:35 PM, Dan Brickley wrote: > >> Hi Phillip, >> > > Re user@domain instead of http:// I suspect you are pushing at an open > door. Many in the openid scene seem to have arrived at the same conclusio= n - > search for 'webfinger' for details of a proposal for an email-style accou= nt > identifier notation, discovery/lookup protocol and draft uri scheme. > > Cheers, > > danbri@danbri.org > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --0016e687872aedb3600474a3fe0f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Indeed, the problem is less with OAuth or forcing the use of email-style id= entifiers for discovery (again, Webfinger is the right thing to point to at= this stage, though we already attempted to solve this once before with the= less-well-named EAUT ("email-addres to URL translation")) than t= he problem that OAuth only deals with signatures and tokens =97 not with th= e design of the API itself.

That is, even if you could identify yourself by an email add= ress to some third party advertising using only your email address, and the= y provided OAuth as the means to do an in-browser request for a token to in= teract with your account =97 the third party and your data provider still h= ave to speak the same input-output language. Now, perhaps that's using = the Twitter API, but what if it isn't? You may have granted the third p= arty a token to access your data, but they have no idea how to speak to you= r particular data provider.

Therefore you have to go much deeper than how you disco= ver your data provider and what form your identifier is in. Presuming we ge= t widespread adoption of an agreed-upon identifier format (which is increas= ingly looks like URLs and email-style identifiers), you still have to deal = with getting parties to use the same API nomenclature.

That, it would seem, is the much harder, longer term pr= oblem.

Chris

On = Mon, Sep 28, 2009 at 4:35 PM, Dan Brickley <danbri@danbri.org> wrote:

Hi Phillip,

Re user@domain instead of http:// I suspect you are pushing at an open door= . Many in the openid scene seem to have arrived at the same conclusion - se= arch for 'webfinger' for details of a proposal for an email-style a= ccount identifier notation, discovery/lookup protocol and draft uri scheme.=

Cheers,

danbri@danbri.org



--
Chris Messi= na
Open Web Advocate

Personal: = http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagen= cy.com
Diso Project: http://diso= -project.org
OpenID Foundation: http:/= /openid.net

This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private
--0016e687872aedb3600474a3fe0f-- From eran@hueniverse.com Mon Sep 28 11:25:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1912E28C0FA for ; Mon, 28 Sep 2009 11:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.801 X-Spam-Level: X-Spam-Status: No, score=-3.801 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP-c-wWMDQc4 for ; Mon, 28 Sep 2009 11:25:45 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EF6B53A6A07 for ; Mon, 28 Sep 2009 11:25:44 -0700 (PDT) Received: (qmail 26305 invoked from network); 28 Sep 2009 15:51:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Sep 2009 15:51:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 28 Sep 2009 08:49:34 -0700 From: Eran Hammer-Lahav To: Phillip Hallam-Baker Date: Mon, 28 Sep 2009 08:51:28 -0700 Thread-Topic: [OAUTH-WG] Is OAUTH actually open Thread-Index: AcpAU5cKrDSCcqPATAqxJrQBnLixQw== Message-ID: 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 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is OAUTH actually open X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 18:25:46 -0000 This is completely out of scope. OAuth is closer to HTTP Basic than to =20 OpenID. Either way, how the user authenticate is out of scope. EHL On Sep 28, 2009, at 6:28, "Phillip Hallam-Baker" =20 wrote: > I have been using a number of OAUTH enabled Web Sites, mostly through > use of my Twitter account. > > What worries me a lot, and what currently disqualifies OAUTH > deployments as 'open' is the fact that I can only use the one or two > providers that are supported by the relying party site. This would be > OK if it was a choice on the part of the relying party site, but as > currently specified the scheme does not allow for open selection of > identity providers. Only the small number of providers supported by > the site will work. > > I suggest adding one extra dimension to the OAUTH user experience, a > box that allows the user to specify their account and provider in > RFC822 form - i.e. I would type hallam@twitter.com to use my twitter > account. > > > OK so this might not be OAUTH at issue here, but if OAUTH is going to > be a security protocol that is designed to interface with users it had > better encompass the entire user interface. > > > Yes, I know that this is not the way OpenID do it. They have this > strange notion that it is easier to teach every one of the billion > Internet users to type in funky URLs than to use the account > identifier that they are familiar with. > > I find the idea that Joe Random User is going to want to log into > their fuzzypegs account using their blog ID quite bizarre. At best > that would be an edge case. The list of blogs (I have twenty) that the > user maintains is at best metadata that might be retrieved along with > other identity attributes. > > And yes, I know that XRI is purportedly there to solve a problem that > the IETF has solved just great thirty years ago, and build out a > registry for our convenience and their profit. I see zero advantage to > XRI. We have a name infrastructure for the Internet, we do not need a > second. > > > While I have no particular issue with the way twitter is run today, I > want to own and control my own Internet name. The only infrastructure > on offer today that allows that is the DNS. Consequently I own > hallambaker.com. > > Playing spymaster with my twitter account is OK, but it puts my > ability to play the game at the whim of twitter, a company that has no > business model. Clearly they will find a business model at some point, > and it might not be one I agree with. > > > All we need to do in the OAUTH specs is to state how to deal with > 'everything else'. > > > One big advantage of using the RFC822 address is that many site > already use it as a username. They understand that most people who > come to their site have forgotten their account name which inevitably > varies from site to site. The password on the other hand, is always > the same. So people forget account names more often than passwords. > > Such a site could easily convert to using OAUTH authentication with > RFC822 ids. Say I am logging into the dalek enthusiasts site and have > forgotten my account info. I give my email address, but instead of > doing the usual email callback loop, the site checks to see if > gmail.com supports OAUTH and if so lets me use OAUTH for the login and > deletes its local password checks altogether. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Mon Sep 28 11:35:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8BB28C104 for ; Mon, 28 Sep 2009 11:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8mbHGI6aDrd for ; Mon, 28 Sep 2009 11:35:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id B74E228C10E for ; Mon, 28 Sep 2009 11:35:21 -0700 (PDT) Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id n8SIadML025291 for ; Mon, 28 Sep 2009 11:36:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254163000; bh=uvBhwE/LV9AN/a4Lqoju2NlYWTE=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:X-System-Of-Record; b=yCpRVK 9CeCd3ut5E/7HzNW51ZpBPBm5wMLBMF/JdFTYq4O7RGgCavO8NjvpkW0sQ3sIeM6DAf aecEEZ6aoJTxQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=CCcLmy40rIQ6qwPDAqthTHDfRdszE/QJFM+/xVI1vqX3bEJvZCUIe8ooz5lDLuMPX ao7r/UQFD1JT1NxYEWTNw== Received: from qyk38 (qyk38.prod.google.com [10.241.83.166]) by spaceape7.eur.corp.google.com with ESMTP id n8SIaaew006683 for ; Mon, 28 Sep 2009 11:36:36 -0700 Received: by qyk38 with SMTP id 38so3975255qyk.27 for ; Mon, 28 Sep 2009 11:36:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.118.135 with SMTP id v7mr1390244qcq.62.1254162995915; Mon, 28 Sep 2009 11:36:35 -0700 (PDT) In-Reply-To: References: From: John Panzer Date: Mon, 28 Sep 2009 11:36:15 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd6d132dcac4f0474a79374 X-System-Of-Record: true Cc: Phillip Hallam-Baker , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is OAUTH actually open X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 18:35:23 -0000 --000e0cd6d132dcac4f0474a79374 Content-Type: text/plain; charset=ISO-8859-1 This is out of scope for OAuth. As a redirect, please see this extension: http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html Query: Where should discussion of such extensions live? Especially ones that are, um, hybrids across two WGs :) -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Sep 28, 2009 at 8:51 AM, Eran Hammer-Lahav wrote: > This is completely out of scope. OAuth is closer to HTTP Basic than to > OpenID. Either way, how the user authenticate is out of scope. > > EHL > > On Sep 28, 2009, at 6:28, "Phillip Hallam-Baker" > wrote: > > > I have been using a number of OAUTH enabled Web Sites, mostly through > > use of my Twitter account. > > > > What worries me a lot, and what currently disqualifies OAUTH > > deployments as 'open' is the fact that I can only use the one or two > > providers that are supported by the relying party site. This would be > > OK if it was a choice on the part of the relying party site, but as > > currently specified the scheme does not allow for open selection of > > identity providers. Only the small number of providers supported by > > the site will work. > > > > I suggest adding one extra dimension to the OAUTH user experience, a > > box that allows the user to specify their account and provider in > > RFC822 form - i.e. I would type hallam@twitter.com to use my twitter > > account. > > > > > > OK so this might not be OAUTH at issue here, but if OAUTH is going to > > be a security protocol that is designed to interface with users it had > > better encompass the entire user interface. > > > > > > Yes, I know that this is not the way OpenID do it. They have this > > strange notion that it is easier to teach every one of the billion > > Internet users to type in funky URLs than to use the account > > identifier that they are familiar with. > > > > I find the idea that Joe Random User is going to want to log into > > their fuzzypegs account using their blog ID quite bizarre. At best > > that would be an edge case. The list of blogs (I have twenty) that the > > user maintains is at best metadata that might be retrieved along with > > other identity attributes. > > > > And yes, I know that XRI is purportedly there to solve a problem that > > the IETF has solved just great thirty years ago, and build out a > > registry for our convenience and their profit. I see zero advantage to > > XRI. We have a name infrastructure for the Internet, we do not need a > > second. > > > > > > While I have no particular issue with the way twitter is run today, I > > want to own and control my own Internet name. The only infrastructure > > on offer today that allows that is the DNS. Consequently I own > > hallambaker.com. > > > > Playing spymaster with my twitter account is OK, but it puts my > > ability to play the game at the whim of twitter, a company that has no > > business model. Clearly they will find a business model at some point, > > and it might not be one I agree with. > > > > > > All we need to do in the OAUTH specs is to state how to deal with > > 'everything else'. > > > > > > One big advantage of using the RFC822 address is that many site > > already use it as a username. They understand that most people who > > come to their site have forgotten their account name which inevitably > > varies from site to site. The password on the other hand, is always > > the same. So people forget account names more often than passwords. > > > > Such a site could easily convert to using OAUTH authentication with > > RFC822 ids. Say I am logging into the dalek enthusiasts site and have > > forgotten my account info. I give my email address, but instead of > > doing the usual email callback loop, the site checks to see if > > gmail.com supports OAUTH and if so lets me use OAUTH for the login and > > deletes its local password checks altogether. > > _______________________________________________ > > 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 > --000e0cd6d132dcac4f0474a79374 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is out of scope for OAuth. =A0As a redirect, please see this extension= :


Query: =A0Where should discussion of such extensions li= ve? =A0Especially ones that are, um, hybrids across two WGs :)



On Mon, Sep 28, 2009 at 8:51 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
This is completely out of scope. OAuth is closer to HTTP Basic than to
OpenID. =A0Either way, how the user authenticate is out of scope.

EHL

On Sep 28, 2009, at 6:28, "Phillip Hallam-Baker" <hallam@gmail.com>
wrote:

> I have been using a number of OAUTH enabled Web Sites, mostly through<= br> > use of my Twitter account.
>
> What worries me a lot, and what currently disqualifies OAUTH
> deployments as 'open' is the fact that I can only use the one = or two
> providers that are supported by the relying party site. This would be<= br> > OK if it was a choice on the part of the relying party site, but as > currently specified the scheme does not allow for open selection of > identity providers. Only the small number of providers supported by > the site will work.
>
> I suggest adding one extra dimension to the OAUTH user experience, a > box that allows the user to specify their account and provider in
> RFC822 form - i.e. I would type = hallam@twitter.com to use my twitter
> account.
>
>
> OK so this might not be OAUTH at issue here, but if OAUTH is going to<= br> > be a security protocol that is designed to interface with users it had=
> better encompass the entire user interface.
>
>
> Yes, I know that this is not the way OpenID do it. They have this
> strange notion that it is easier to teach every one of the billion
> Internet users to type in funky URLs than to use the account
> identifier that they are familiar with.
>
> I find the idea that Joe Random User is going to want to log into
> their fuzzypegs account using their blog ID quite bizarre. At best
> that would be an edge case. The list of blogs (I have twenty) that the=
> user maintains is at best metadata that might be retrieved along with<= br> > other identity attributes.
>
> And yes, I know that XRI is purportedly there to solve a problem that<= br> > the IETF has solved just great thirty years ago, and build out a
> registry for our convenience and their profit. I see zero advantage to=
> XRI. We have a name infrastructure for the Internet, we do not need a<= br> > second.
>
>
> While I have no particular issue with the way twitter is run today, I<= br> > want to own and control my own Internet name. The only infrastructure<= br> > on offer today that allows that is the DNS. Consequently I own
> hallambaker.com.
>
> Playing spymaster with my twitter account is OK, but it puts my
> ability to play the game at the whim of twitter, a company that has no=
> business model. Clearly they will find a business model at some point,=
> and it might not be one I agree with.
>
>
> All we need to do in the OAUTH specs is to state how to deal with
> 'everything else'.
>
>
> One big advantage of using the RFC822 address is that many site
> already use it as a username. They understand that most people who
> come to their site have forgotten their account name which inevitably<= br> > varies from site to site. The password on the other hand, is always > the same. So people forget account names more often than passwords. >
> Such a site could easily convert to using OAUTH authentication with > RFC822 ids. Say I am logging into the dalek enthusiasts site and have<= br> > forgotten my account info. I give my email address, but instead of
> doing the usual email callback loop, the site checks to see if
> gmail.com supports = OAUTH and if so lets me use OAUTH for the login and
> deletes its local password checks altogether.
> _______________________________________________
> 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

--000e0cd6d132dcac4f0474a79374-- From eran@hueniverse.com Mon Sep 28 14:33:54 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3536128C0E3 for ; Mon, 28 Sep 2009 14:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.78 X-Spam-Level: X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnpFiNMWcc6z for ; Mon, 28 Sep 2009 14:33:52 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 430193A63EC for ; Mon, 28 Sep 2009 14:33:51 -0700 (PDT) Received: (qmail 6055 invoked from network); 28 Sep 2009 18:58:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Sep 2009 18:58:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 28 Sep 2009 11:55:50 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Mon, 28 Sep 2009 11:58:17 -0700 Thread-Topic: [OAUTH-WG] Is OAUTH actually open Thread-Index: AcpAap9wcy99f6xQRaqszerdGIU+TQAAtbrg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF1EA6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343784DF1EA6P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Phillip Hallam-Baker , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is OAUTH actually open X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 21:33:54 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343784DF1EA6P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would suggest the OpenID foundation since between OpenID and OAuth, OpenI= D is the more limiting technology (OpenID providers are more likely to adop= t OAuth than OAuth providers to adopt OpenID). EHL From: John Panzer [mailto:jpanzer@google.com] Sent: Monday, September 28, 2009 11:36 AM To: Eran Hammer-Lahav Cc: Phillip Hallam-Baker; oauth@ietf.org Subject: Re: [OAUTH-WG] Is OAUTH actually open This is out of scope for OAuth. As a redirect, please see this extension: http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_o= auth_extension.html Query: Where should discussion of such extensions live? Especially ones t= hat are, um, hybrids across two WGs :) -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Sep 28, 2009 at 8:51 AM, Eran Hammer-Lahav > wrote: This is completely out of scope. OAuth is closer to HTTP Basic than to OpenID. Either way, how the user authenticate is out of scope. EHL On Sep 28, 2009, at 6:28, "Phillip Hallam-Baker" > wrote: > I have been using a number of OAUTH enabled Web Sites, mostly through > use of my Twitter account. > > What worries me a lot, and what currently disqualifies OAUTH > deployments as 'open' is the fact that I can only use the one or two > providers that are supported by the relying party site. This would be > OK if it was a choice on the part of the relying party site, but as > currently specified the scheme does not allow for open selection of > identity providers. Only the small number of providers supported by > the site will work. > > I suggest adding one extra dimension to the OAUTH user experience, a > box that allows the user to specify their account and provider in > RFC822 form - i.e. I would type hallam@twitter.com to use my twitter > account. > > > OK so this might not be OAUTH at issue here, but if OAUTH is going to > be a security protocol that is designed to interface with users it had > better encompass the entire user interface. > > > Yes, I know that this is not the way OpenID do it. They have this > strange notion that it is easier to teach every one of the billion > Internet users to type in funky URLs than to use the account > identifier that they are familiar with. > > I find the idea that Joe Random User is going to want to log into > their fuzzypegs account using their blog ID quite bizarre. At best > that would be an edge case. The list of blogs (I have twenty) that the > user maintains is at best metadata that might be retrieved along with > other identity attributes. > > And yes, I know that XRI is purportedly there to solve a problem that > the IETF has solved just great thirty years ago, and build out a > registry for our convenience and their profit. I see zero advantage to > XRI. We have a name infrastructure for the Internet, we do not need a > second. > > > While I have no particular issue with the way twitter is run today, I > want to own and control my own Internet name. The only infrastructure > on offer today that allows that is the DNS. Consequently I own > hallambaker.com. > > Playing spymaster with my twitter account is OK, but it puts my > ability to play the game at the whim of twitter, a company that has no > business model. Clearly they will find a business model at some point, > and it might not be one I agree with. > > > All we need to do in the OAUTH specs is to state how to deal with > 'everything else'. > > > One big advantage of using the RFC822 address is that many site > already use it as a username. They understand that most people who > come to their site have forgotten their account name which inevitably > varies from site to site. The password on the other hand, is always > the same. So people forget account names more often than passwords. > > Such a site could easily convert to using OAUTH authentication with > RFC822 ids. Say I am logging into the dalek enthusiasts site and have > forgotten my account info. I give my email address, but instead of > doing the usual email callback loop, the site checks to see if > gmail.com supports OAUTH and if so lets me use OAUTH fo= r the login and > deletes its local password checks altogether. > _______________________________________________ > 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_90C41DD21FB7C64BB94121FBBC2E72343784DF1EA6P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would suggest the OpenID foundation since between OpenID a= nd OAuth, OpenID is the more limiting technology (OpenID providers are more li= kely to adopt OAuth than OAuth providers to adopt OpenID).

 

EHL

 

From: John Panzer [mailto:jpanzer@google.com]
Sent: Monday, September 28, 2009 11:36 AM
To: Eran Hammer-Lahav
Cc: Phillip Hallam-Baker; oauth@ietf.org
Subject: Re: [OAUTH-WG] Is OAUTH actually open

 

This is out of scope for OAuth.  As a redirect, p= lease see this extension:

 

 

Query:  Where should discussion of such extension= s live?  Especially ones that are, um, hybrids across two WGs :)


--
John Panzer / Google
jpanzer@google.com<= /a> / abstractioneer.or= g / @jpanzer



On Mon, Sep 28, 2009 at 8:51 AM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:=

This is completely out of scope. OAuth is closer to HT= TP Basic than to
OpenID.  Either way, how the user authenticate is out of scope.

EHL

On Sep 28, 2009, at 6:28, "Phillip Hallam-Baker" <hallam@gmail.com>
wrote:


> I have been using a number of OAUTH enabled Web Sites, mostly through<= br> > use of my Twitter account.
>
> What worries me a lot, and what currently disqualifies OAUTH
> deployments as 'open' is the fact that I can only use the one or two > providers that are supported by the relying party site. This would be<= br> > OK if it was a choice on the part of the relying party site, but as > currently specified the scheme does not allow for open selection of > identity providers. Only the small number of providers supported by > the site will work.
>
> I suggest adding one extra dimension to the OAUTH user experience, a > box that allows the user to specify their account and provider in
> RFC822 form - i.e. I would type = hallam@twitter.com to use my twitter
> account.
>
>
> OK so this might not be OAUTH at issue here, but if OAUTH is going to<= br> > be a security protocol that is designed to interface with users it had=
> better encompass the entire user interface.
>
>
> Yes, I know that this is not the way OpenID do it. They have this
> strange notion that it is easier to teach every one of the billion
> Internet users to type in funky URLs than to use the account
> identifier that they are familiar with.
>
> I find the idea that Joe Random User is going to want to log into
> their fuzzypegs account using their blog ID quite bizarre. At best
> that would be an edge case. The list of blogs (I have twenty) that the=
> user maintains is at best metadata that might be retrieved along with<= br> > other identity attributes.
>
> And yes, I know that XRI is purportedly there to solve a problem that<= br> > the IETF has solved just great thirty years ago, and build out a
> registry for our convenience and their profit. I see zero advantage to=
> XRI. We have a name infrastructure for the Internet, we do not need a<= br> > second.
>
>
> While I have no particular issue with the way twitter is run today, I<= br> > want to own and control my own Internet name. The only infrastructure<= br> > on offer today that allows that is the DNS. Consequently I own
> hallambaker.com.
>
> Playing spymaster with my twitter account is OK, but it puts my
> ability to play the game at the whim of twitter, a company that has no=
> business model. Clearly they will find a business model at some point,=
> and it might not be one I agree with.
>
>
> All we need to do in the OAUTH specs is to state how to deal with
> 'everything else'.
>
>
> One big advantage of using the RFC822 address is that many site
> already use it as a username. They understand that most people who
> come to their site have forgotten their account name which inevitably<= br> > varies from site to site. The password on the other hand, is always > the same. So people forget account names more often than passwords. >
> Such a site could easily convert to using OAUTH authentication with > RFC822 ids. Say I am logging into the dalek enthusiasts site and have<= br> > forgotten my account info. I give my email address, but instead of
> doing the usual email callback loop, the site checks to see if
> gmail.com supports = OAUTH and if so lets me use OAUTH for the login and
> deletes its local password checks altogether.
> _______________________________________________
> 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

 

--_000_90C41DD21FB7C64BB94121FBBC2E72343784DF1EA6P3PW5EX1MB01E_-- From romeda@gmail.com Tue Sep 29 05:39:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990903A68B5 for ; Tue, 29 Sep 2009 05:39:46 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isX7wfoU9PFf for ; Tue, 29 Sep 2009 05:39:45 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 2003D3A6778 for ; Tue, 29 Sep 2009 05:39:44 -0700 (PDT) Received: by bwz6 with SMTP id 6so1957108bwz.37 for ; Tue, 29 Sep 2009 05:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=DeyW54js/wZF0uUVryHAYWnfm5vJfqYqsRcO28BPQ9k=; b=pUE75rHMTkM3lLfu3kEYtX8gLfWsFa2S8yQcvxql+Zmi86t533bAlHAIf+drD6xtGH 1/vX2pHQH4U+StodJ4i9QVhchuYVxYKUONJs3Nn87zunop7CpFIFONUf5cMrr1F4HGHF F7OVrCKV/ryBvHoDkrGoCtT/YKz/1njIJi/rU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=UTELHhoMy92+xRCNzvTC7gPa0RDZPIWWLuhQ+HK+70oP+aeabQ0rQ/byCjCQuufje5 6duylWQpukEHk4I1MUwumjKrptpKo4wDA3WiyTBB1REEcoiz8RlZSRPkVZYBZaZnCsie LDKGW5ib82T79w19JSNX1ZEI9XB/HIQLjHF6s= MIME-Version: 1.0 Received: by 10.204.8.199 with SMTP id i7mr633939bki.37.1254228057298; Tue, 29 Sep 2009 05:40:57 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Tue, 29 Sep 2009 13:40:37 +0100 Message-ID: To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 12:39:46 -0000 I'm not sure what the consensus is here, but it seems that at a minimum, we need a way to determine which algorithms are available, to allow for negotiation of the cipher suite between a consumer and service provider. Ideally the following would be true: 1. A service provider must be able to specify a set of acceptable ciphers (please correct me if "cipher" is the wrong word to use here). 2. A consumer must be able to specify a set of acceptable ciphers. 3. There must be some simple way to determine the strongest common cipher. Any takers? Would an ordered list in the HTTP headers (e.g., X-OAuth-Supported-Ciphers) be sufficient? As to the question of a minimum set of supported ciphers, what about creating a separate RFC (or other document?) that (a) specifies required and optional ciphers, and (b) can be deprecated and point to a new document as needed, without needing to update the OAuth Core RFC? b. 2009/9/25 Breno : > This is another argument against trying to do better than TLS, since OAuth > does not define its own encryption transport mechanism. > > Insecurity concerns about TLS are quite manageable by those who care about > security. You can profile TLS at your will. For instance, to make your FF > compliant with FIPS-140-2 TLS profile, follow the instructions here: > > http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-2?style_mode=inproduct&s=cipher%20suites > > On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav > wrote: >> >> The one method I am sure we are going to support is a plaintext method. >> > > > -- > Breno de Medeiros > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From hubertlvg@gmail.com Tue Sep 29 07:34:04 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE0F3A6945 for ; Tue, 29 Sep 2009 07:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5ctXTBng5eS for ; Tue, 29 Sep 2009 07:34:03 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 5786C28C15F for ; Tue, 29 Sep 2009 07:34:03 -0700 (PDT) Received: by bwz6 with SMTP id 6so2046285bwz.37 for ; Tue, 29 Sep 2009 07:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=A7I/O7nOQstXZP+O+ruJfrDdU7ArqVZeB9p3yuexjvk=; b=kst/rWRi8TChxStQT/z2lh4K4sU+HBEZdQRNDESB+JKbq2ObjNIbih24sE0jO9bTan ZhJT10ugBhZdCmZ9TgRgNNBXw2tl2MEpJd9EgOQU4W/K8KTO7AJoLjf4iTU1SvLT+HCn FyDtazIzh+g86n57xXNslYJeyvPZbtu3KcFy0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=s6rxn+4qqakIqcdulnwUQzBmvjLQRKD+8R5wv7wwV5EhiN/j9Fxi61cBscDNIRPWEZ 6cNmwixhrh1AfEjpGv47EPGz6aUK+LL7jKRpj4lC73CUraIuZEKpNHeWv+JY4JuRWHWc zhvMShtgPf+JOFTeRiUOswU7+BQI4ICEWEQ0E= MIME-Version: 1.0 Received: by 10.204.15.3 with SMTP id i3mr4238148bka.71.1254234919881; Tue, 29 Sep 2009 07:35:19 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 29 Sep 2009 16:35:19 +0200 Message-ID: <6c0fd2bc0909290735h2e310f1dpdd95b068b90b9b25@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 14:34:05 -0000 If a separate document is easier to maintain then let's do that, provided that document remains normative (i.e. compatibility with the IETF OAuth spec includes compatibility with this doc). Would that be an RFC though? I think having a basic cipher-suite negotiation embedded in the protocol is great to have. If not, then at the very least additional messaging capability to that end should be added to the problem reporting extension (but that's kind of stretching the meaning of problem reporting IMO). Cheers, Hubert On Tue, Sep 29, 2009 at 2:40 PM, Blaine Cook wrote: > I'm not sure what the consensus is here, but it seems that at a > minimum, we need a way to determine which algorithms are available, to > allow for negotiation of the cipher suite between a consumer and > service provider. > > Ideally the following would be true: > > 1. A service provider must be able to specify a set of acceptable > ciphers (please correct me if "cipher" is the wrong word to use here). > 2. A consumer must be able to specify a set of acceptable ciphers. > 3. There must be some simple way to determine the strongest common cipher. > > Any takers? Would an ordered list in the HTTP headers (e.g., > X-OAuth-Supported-Ciphers) be sufficient? > > As to the question of a minimum set of supported ciphers, what about > creating a separate RFC (or other document?) that (a) specifies > required and optional ciphers, and (b) can be deprecated and point to > a new document as needed, without needing to update the OAuth Core > RFC? > > b. > > 2009/9/25 Breno : >> This is another argument against trying to do better than TLS, since OAuth >> does not define its own encryption transport mechanism. >> >> Insecurity concerns about TLS are quite manageable by those who care about >> security. You can profile TLS at your will. For instance, to make your FF >> compliant with FIPS-140-2 TLS profile, follow the instructions here: >> >> http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-2?style_mode=inproduct&s=cipher%20suites >> >> On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav >> wrote: >>> >>> The one method I am sure we are going to support is a plaintext method. >>> >> >> >> -- >> Breno de Medeiros >> >> >> _______________________________________________ >> 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 rbarnes@bbn.com Tue Sep 29 07:49:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7C03A6868 for ; Tue, 29 Sep 2009 07:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCfidXtX60OM for ; Tue, 29 Sep 2009 07:49:26 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 210CC3A67B8 for ; Tue, 29 Sep 2009 07:49:25 -0700 (PDT) Received: from [192.1.255.181] (helo=col-dhcp-192-1-255-181.bbn.com) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Msd6K-0003mS-Ew; Tue, 29 Sep 2009 09:50:45 -0400 Message-ID: <4AC21EC4.7030608@bbn.com> Date: Tue, 29 Sep 2009 10:50:44 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Blaine Cook References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 14:49:27 -0000 Hey Blaine, You've got the general pattern right, but I'm not sure how well it maps to the general use of OAuth signatures: One of the main benefits of OAuth vs. Digest is that it can be done in a single HTTP round-trip -- the server doesn't need to issue a challenge in order for the client to construct the signature. That creates a problem for crypto agility because by the same token, the server doesn't have a chance to specify which cipher suites it supports. (Here I'm using client and server in the HTTP sense, which I think map to your "consumer" and "service provider" below.) A couple of work-arounds occur to me: 1. Allow the client to provide multiple signatures using different cipher suites, and let the server choose which one to validate (MUST use only one to prevent bid-down attacks). If the client provides all the signatures it knows how to do, then this is equivalent to a full negotiation. 2. Allow the server to reject signatures and specify which cipher suites it supports, so that the client can cache for future requests. --Richard Blaine Cook wrote: > I'm not sure what the consensus is here, but it seems that at a > minimum, we need a way to determine which algorithms are available, to > allow for negotiation of the cipher suite between a consumer and > service provider. > > Ideally the following would be true: > > 1. A service provider must be able to specify a set of acceptable > ciphers (please correct me if "cipher" is the wrong word to use here). > 2. A consumer must be able to specify a set of acceptable ciphers. > 3. There must be some simple way to determine the strongest common cipher. > > Any takers? Would an ordered list in the HTTP headers (e.g., > X-OAuth-Supported-Ciphers) be sufficient? > > As to the question of a minimum set of supported ciphers, what about > creating a separate RFC (or other document?) that (a) specifies > required and optional ciphers, and (b) can be deprecated and point to > a new document as needed, without needing to update the OAuth Core > RFC? > > b. > > 2009/9/25 Breno : >> This is another argument against trying to do better than TLS, since OAuth >> does not define its own encryption transport mechanism. >> >> Insecurity concerns about TLS are quite manageable by those who care about >> security. You can profile TLS at your will. For instance, to make your FF >> compliant with FIPS-140-2 TLS profile, follow the instructions here: >> >> http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-2?style_mode=inproduct&s=cipher%20suites >> >> On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav >> wrote: >>> The one method I am sure we are going to support is a plaintext method. >>> >> >> -- >> Breno de Medeiros >> >> >> _______________________________________________ >> 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 hubertlvg@gmail.com Tue Sep 29 08:00:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1503A6AC9 for ; Tue, 29 Sep 2009 08:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02gA10V1o2vK for ; Tue, 29 Sep 2009 08:00:58 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id E2A0E3A6995 for ; Tue, 29 Sep 2009 08:00:57 -0700 (PDT) Received: by bwz6 with SMTP id 6so2069226bwz.37 for ; Tue, 29 Sep 2009 08:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=g1g+KPDwKx+TGuinxH0Wcf/lS+WmttdfYzZPmKI91e4=; b=ePIWy8EoT+b96W6V9KDa0qIgT8IfZgTzfIU3FrhT0J03g/c2gURh2hcXnolR6A5AU1 gIiOhnkuerakWatUPs7kBiJnQzMpQWzJp5JHkICMEjRWLT6qC+2rIQCDZKAG+3Nedt7K J07SQ7v+mlvSFRX6r3doBXcGubS5EtiLClHLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ZpDnb3FUnyUJlQbA4a7Y/9OX3PVge0MoSu2Q7nWzzEL/6mmjlgN5+QCInNrBhfipIE vNDjOzW2mB9sAlvM2W38LZ7OKOB7ohCgnXRs/Fbs9NMhDTgQgoMHhe/joOMZ8VpK60Qv LZOw0Jmt9HuwBzDaMiE9oadxX84sCd4KHWjcI= MIME-Version: 1.0 Received: by 10.204.154.82 with SMTP id n18mr4264697bkw.128.1254236536509; Tue, 29 Sep 2009 08:02:16 -0700 (PDT) In-Reply-To: <4AC21EC4.7030608@bbn.com> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC21EC4.7030608@bbn.com> Date: Tue, 29 Sep 2009 17:02:16 +0200 Message-ID: <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 15:00:59 -0000 An alternative would be to say that the OOB initiation phase that takes pla= ce prior to the OAuth dance is the right time to perform such negotiation... After all it is about discovering each other's capabilities. We would then only need some simple error message in the problem reporting = ext. Just a thought. Hubert On Tue, Sep 29, 2009 at 4:50 PM, Richard Barnes wrote: > Hey Blaine, > > You've got the general pattern right, but I'm not sure how well it maps t= o > the general use of OAuth signatures: One of the main benefits of OAuth vs= . > Digest is that it can be done in a single HTTP round-trip -- the server > doesn't need to issue a challenge in order for the client to construct th= e > signature. =A0That creates a problem for crypto agility because by the sa= me > token, the server doesn't have a chance to specify which cipher suites it > supports. =A0 (Here I'm using client and server in the HTTP sense, which = I > think map to your "consumer" and "service provider" below.) > > A couple of work-arounds occur to me: > > 1. Allow the client to provide multiple signatures using different cipher > suites, and let the server choose which one to validate (MUST use only on= e > to prevent bid-down attacks). =A0If the client provides all the signature= s it > knows how to do, then this is equivalent to a full negotiation. > > 2. Allow the server to reject signatures and specify which cipher suites = it > supports, so that the client can cache for future requests. > > --Richard > > > > Blaine Cook wrote: >> >> I'm not sure what the consensus is here, but it seems that at a >> minimum, we need a way to determine which algorithms are available, to >> allow for negotiation of the cipher suite between a consumer and >> service provider. >> >> Ideally the following would be true: >> >> 1. A service provider must be able to specify a set of acceptable >> ciphers (please correct me if "cipher" is the wrong word to use here). >> 2. A consumer must be able to specify a set of acceptable ciphers. >> 3. There must be some simple way to determine the strongest common ciphe= r. >> >> Any takers? Would an ordered list in the HTTP headers (e.g., >> X-OAuth-Supported-Ciphers) be sufficient? >> >> As to the question of a minimum set of supported ciphers, what about >> creating a separate RFC (or other document?) that (a) specifies >> required and optional ciphers, and (b) can be deprecated and point to >> a new document as needed, without needing to update the OAuth Core >> RFC? >> >> b. >> >> 2009/9/25 Breno : >>> >>> This is another argument against trying to do better than TLS, since >>> OAuth >>> does not define its own encryption transport mechanism. >>> >>> Insecurity concerns about TLS are quite manageable by those who care >>> about >>> security. You can profile TLS at your will. For instance, to make your = FF >>> compliant with FIPS-140-2 TLS profile, follow the instructions here: >>> >>> >>> http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-2?= style_mode=3Dinproduct&s=3Dcipher%20suites >>> >>> On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav >>> wrote: >>>> >>>> The one method I am sure we are going to support is a plaintext method= . >>>> >>> >>> -- >>> Breno de Medeiros >>> >>> >>> _______________________________________________ >>> 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 rbarnes@bbn.com Tue Sep 29 08:19:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 711F33A687F for ; Tue, 29 Sep 2009 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjucBpDZexjN for ; Tue, 29 Sep 2009 08:19:38 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3B68C3A6922 for ; Tue, 29 Sep 2009 08:19:38 -0700 (PDT) Received: from [192.1.255.181] (helo=col-dhcp-192-1-255-181.bbn.com) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MsdZX-00044w-FE; Tue, 29 Sep 2009 10:20:55 -0400 Message-ID: <4AC225D8.9090302@bbn.com> Date: Tue, 29 Sep 2009 11:20:56 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hubert Le Van Gong References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC21EC4.7030608@bbn.com> <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> In-Reply-To: <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 15:19:39 -0000 That could work in the "OAuth delegation" use case, where the parties are going to go to the effort of provisioning. Even in that case, though, you would also have to provision algorithms into the Resource Owner (i.e., the User), since he also needs to sign requests (to the Client/Consumer) as part of the dance. I'm more worried about the general usage of OAuth signatures to sign HTTP requests. Again making the analogy to Digest, there is an assumption there that keys are pre-provisioned (=tokens for OAuth), but not algorithms (See Section 3.2.1). --Richard Hubert Le Van Gong wrote: > An alternative would be to say that the OOB initiation phase that takes place > prior to the OAuth dance is the right time to perform such negotiation... > After all it is about discovering each other's capabilities. > We would then only need some simple error message in the problem reporting ext. > > Just a thought. > > Hubert > > > On Tue, Sep 29, 2009 at 4:50 PM, Richard Barnes wrote: >> Hey Blaine, >> >> You've got the general pattern right, but I'm not sure how well it maps to >> the general use of OAuth signatures: One of the main benefits of OAuth vs. >> Digest is that it can be done in a single HTTP round-trip -- the server >> doesn't need to issue a challenge in order for the client to construct the >> signature. That creates a problem for crypto agility because by the same >> token, the server doesn't have a chance to specify which cipher suites it >> supports. (Here I'm using client and server in the HTTP sense, which I >> think map to your "consumer" and "service provider" below.) >> >> A couple of work-arounds occur to me: >> >> 1. Allow the client to provide multiple signatures using different cipher >> suites, and let the server choose which one to validate (MUST use only one >> to prevent bid-down attacks). If the client provides all the signatures it >> knows how to do, then this is equivalent to a full negotiation. >> >> 2. Allow the server to reject signatures and specify which cipher suites it >> supports, so that the client can cache for future requests. >> >> --Richard >> >> >> >> Blaine Cook wrote: >>> I'm not sure what the consensus is here, but it seems that at a >>> minimum, we need a way to determine which algorithms are available, to >>> allow for negotiation of the cipher suite between a consumer and >>> service provider. >>> >>> Ideally the following would be true: >>> >>> 1. A service provider must be able to specify a set of acceptable >>> ciphers (please correct me if "cipher" is the wrong word to use here). >>> 2. A consumer must be able to specify a set of acceptable ciphers. >>> 3. There must be some simple way to determine the strongest common cipher. >>> >>> Any takers? Would an ordered list in the HTTP headers (e.g., >>> X-OAuth-Supported-Ciphers) be sufficient? >>> >>> As to the question of a minimum set of supported ciphers, what about >>> creating a separate RFC (or other document?) that (a) specifies >>> required and optional ciphers, and (b) can be deprecated and point to >>> a new document as needed, without needing to update the OAuth Core >>> RFC? >>> >>> b. >>> >>> 2009/9/25 Breno : >>>> This is another argument against trying to do better than TLS, since >>>> OAuth >>>> does not define its own encryption transport mechanism. >>>> >>>> Insecurity concerns about TLS are quite manageable by those who care >>>> about >>>> security. You can profile TLS at your will. For instance, to make your FF >>>> compliant with FIPS-140-2 TLS profile, follow the instructions here: >>>> >>>> >>>> http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-2?style_mode=inproduct&s=cipher%20suites >>>> >>>> On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav >>>> wrote: >>>>> The one method I am sure we are going to support is a plaintext method. >>>>> >>>> -- >>>> Breno de Medeiros >>>> >>>> >>>> _______________________________________________ >>>> 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 29 09:33:30 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18C8B3A6AF5 for ; Tue, 29 Sep 2009 09:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.761 X-Spam-Level: X-Spam-Status: No, score=-3.761 tagged_above=-999 required=5 tests=[AWL=-1.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xut4DwIlGHkz for ; Tue, 29 Sep 2009 09:33:29 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E873C3A6AF9 for ; Tue, 29 Sep 2009 09:33:28 -0700 (PDT) Received: (qmail 31664 invoked from network); 29 Sep 2009 16:34:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Sep 2009 16:34:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 29 Sep 2009 09:32:23 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Tue, 29 Sep 2009 09:34:54 -0700 Thread-Topic: Reevaluating Assumptions (Important!) Thread-Index: Aco7JdXiSQ9CsHH0QP6jHQceSIuH1AF++Fpw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF2054@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 16:33:30 -0000 Reminder: Please help conduct the platform survey. Please answer this about the platf= orms you use for developing HTTP applications. Does it provide access to: * the raw HTTP request URI * HTTP authentication headers (WWW-Authenticate, Authorize) * the Host HTTP header * the raw HTTP request entity-body If we have wide enough support (3 years later) for these items, we can sign= ificantly simplify the signature workflow. If no one is going to reply with= information about the platforms they use I am going to assume that they ca= n (both client and server side) access all of the above. Please reply back by 10/6. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, September 21, 2009 6:42 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Reevaluating Assumptions (Important!) >=20 > OAuth has been designed over 2 years ago based on many assumptions that > were true at that time. The most significant assumptions were: >=20 > * HTTPS cannot be required due to deployment limitations > * OAuth will be mostly used with proprietary APIs > * Many web platforms do not provide access to the wire HTTP request URI > (either on the client or server side) >=20 > I strongly believe it would be a mistake to continue this work without > questioning these assumptions and making sure we are not producing a > lesser solution by trying to accommodate them. >=20 > The first two assumptions are easy: >=20 > * HTTPS cannot be required due to deployment limitations >=20 > This still holds true. OAuth security cannot be based solely on using > HTTPS due to deployment limitations. However, the protocol must easily > support deployments that have HTTPS easily available and not make them > waste resources will timestamps, nonces, and other security elements. > While PLAINTEXT provides such support, it doesn't go far enough and > still requires the presence of such parameters. >=20 > * OAuth will be mostly used with proprietary APIs >=20 > This has proved to be false. With new open APIs there is a greater need > to enable clients to interact with a protected resource that it has not > encountered before or one it has been coded explicitly for. What this > means is that we need more discovery features built into the core > protocol or more required portions to promote interoperability. There > should be a minimum that any client facing an OAuth 404 should be able > to handle. >=20 > The third item: >=20 > * Many web platforms do not provide access to the wire HTTP request URI > (either on the client or server side) >=20 > requires more research but it also holds the key to much of the > protocol design, namely: >=20 > - The canonicalization of the HTTP request parameter and URI - this was > done due to the fact that at the time, many popular web platforms did > not provide easy access to the raw HTTP request URI and headers. If > this is no longer the case, OAuth can be significantly simplified to > remove the need to process the parameters and only treat the request > URI. >=20 > - The inclusion of multiple parameter transmission methods - this was > done due to lack of access to the Authorization header in some clients > and server environment. If this is no longer a requirement or if we > come to the conclusion that HTTP caching requires that we use the > header in all requests, the need to support parameters in places other > than the header will also go away. >=20 > If we come to the conclusion that the last assumption is either > incorrect or irrelevant (the requirement to use HTTP auth headers), we > will be able to significantly simplify the protocol which will also > accomplish improving interoperability and security. >=20 > ACTION ITEM: >=20 > We need to conduct a quick survey of web platforms to figure out if > they provide access to the RAW HTTP request (client and server), and if > they provide access to the HTTP auth headers (client and server). If > you know, please reply with the information for the platforms you use. >=20 > EHL >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Tue Sep 29 09:46:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4227728C19C for ; Tue, 29 Sep 2009 09:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu0jzsCJE8Hd for ; Tue, 29 Sep 2009 09:45:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 2808E28C173 for ; Tue, 29 Sep 2009 09:45:54 -0700 (PDT) Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id n8TGlCfW028170 for ; Tue, 29 Sep 2009 17:47:14 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254242834; bh=hGIS5y3K7bBu/ApMYoZASpJwTEg=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Content-Type:Content-Transfer-Encoding: X-System-Of-Record; b=KAgcHL2emwYgTCjsYbpW0KSsWKyH9pvHEWF8KKy12fbx sO7DDyI7rlD0vN1WtTMrOPFKC+EL5vpXw8fiN821mQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: content-type:content-transfer-encoding:x-system-of-record; b=nePzfLtOkqEO1CZmyAPN8Z/JwJwcLFGNaWA9fPZlLQwUMziqhbZRhVSPGZ2FnR+0l HwfAmnSPlWprIWgKTuDMA== Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by zps78.corp.google.com with ESMTP id n8TGkom9019003 for ; Tue, 29 Sep 2009 09:47:10 -0700 Received: by qyk9 with SMTP id 9so8636901qyk.30 for ; Tue, 29 Sep 2009 09:47:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.10.229 with SMTP id q37mr2083533qcq.106.1254242829728; Tue, 29 Sep 2009 09:47:09 -0700 (PDT) In-Reply-To: <4AC225D8.9090302@bbn.com> References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC21EC4.7030608@bbn.com> <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> <4AC225D8.9090302@bbn.com> Date: Tue, 29 Sep 2009 09:47:09 -0700 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 16:46:01 -0000 Wow, this is a great discussion. I'd like to make a few comments on the goals... There are attacks against the kinds of protocols being discussed here where a MITM or a malicious server can force a client to the weakest signing algorithm supported by client. I don't think we should worry about a man-in-the-middle. https is adequate prevention against MITM attacks, and if the client isn't requiring https they probably have bigger concerns than HMAC-SHA1 vs HMAC-SHA256. I'm not sure whether we should worry about malicious servers. For example, imagine a client is tricked into sending a signed OAuth request to a malicious server, e.g. a client is tricked into sending a request to https://evil.com using an access token originally issued by https://good.com. Note that this is NOT a man-in-the-middle attack. The client is really talking to evil.com. The client is confused and is sending authentication credentials issued by/for good.com to evil.com. There are various real-world situations where this can happen. Imagine a client following links or redirects and trying to authenticate with OAuth. If we're using plaintext, this is a disaster. The client just leaked credentials to evil.com. If we're using HMAC-SHA1, this is less of a big deal. The request is signed for evil.com, and evil.com cannot replay it anywhere else. Both the consumer secret and the token secret provide some security. Even if the consumer secret leaks (e.g. it's embedded in a desktop application), evil.com gains nothing. If we're using RSA-SHA1, the situation is better than plaintext, but worse than HMAC-SHA1. The token secret doesn't provide any additional security for the RSA signatures. evil.com would know the access token, and if they somehow manage to steal the consumer secret, they have everything they need to impersonate the client. I'm making some assumptions about the problem domain here. Is it reasonable to think about the problem of signature method choice using this type of analysis? Cheers, Brian On Tue, Sep 29, 2009 at 8:20 AM, Richard Barnes wrote: > That could work in the "OAuth delegation" use case, where the parties are > going to go to the effort of provisioning. =A0Even in that case, though, = you > would also have to provision algorithms into the Resource Owner (i.e., th= e > User), since he also needs to sign requests (to the Client/Consumer) as p= art > of the dance. > > I'm more worried about the general usage of OAuth signatures to sign HTTP > requests. =A0Again making the analogy to Digest, there is an assumption t= here > that keys are pre-provisioned (=3Dtokens for OAuth), but not algorithms (= See > Section 3.2.1). > > --Richard > > > > Hubert Le Van Gong wrote: >> >> An alternative would be to say that the OOB initiation phase that takes >> place >> prior to the OAuth dance is the right time to perform such negotiation..= . >> After all it is about discovering each other's capabilities. >> We would then only need some simple error message in the problem reporti= ng >> ext. >> >> Just a thought. >> >> Hubert >> >> >> On Tue, Sep 29, 2009 at 4:50 PM, Richard Barnes wrote: >>> >>> Hey Blaine, >>> >>> You've got the general pattern right, but I'm not sure how well it maps >>> to >>> the general use of OAuth signatures: One of the main benefits of OAuth >>> vs. >>> Digest is that it can be done in a single HTTP round-trip -- the server >>> doesn't need to issue a challenge in order for the client to construct >>> the >>> signature. =A0That creates a problem for crypto agility because by the = same >>> token, the server doesn't have a chance to specify which cipher suites = it >>> supports. =A0 (Here I'm using client and server in the HTTP sense, whic= h I >>> think map to your "consumer" and "service provider" below.) >>> >>> A couple of work-arounds occur to me: >>> >>> 1. Allow the client to provide multiple signatures using different ciph= er >>> suites, and let the server choose which one to validate (MUST use only >>> one >>> to prevent bid-down attacks). =A0If the client provides all the signatu= res >>> it >>> knows how to do, then this is equivalent to a full negotiation. >>> >>> 2. Allow the server to reject signatures and specify which cipher suite= s >>> it >>> supports, so that the client can cache for future requests. >>> >>> --Richard >>> >>> >>> >>> Blaine Cook wrote: >>>> >>>> I'm not sure what the consensus is here, but it seems that at a >>>> minimum, we need a way to determine which algorithms are available, to >>>> allow for negotiation of the cipher suite between a consumer and >>>> service provider. >>>> >>>> Ideally the following would be true: >>>> >>>> 1. A service provider must be able to specify a set of acceptable >>>> ciphers (please correct me if "cipher" is the wrong word to use here). >>>> 2. A consumer must be able to specify a set of acceptable ciphers. >>>> 3. There must be some simple way to determine the strongest common >>>> cipher. >>>> >>>> Any takers? Would an ordered list in the HTTP headers (e.g., >>>> X-OAuth-Supported-Ciphers) be sufficient? >>>> >>>> As to the question of a minimum set of supported ciphers, what about >>>> creating a separate RFC (or other document?) that (a) specifies >>>> required and optional ciphers, and (b) can be deprecated and point to >>>> a new document as needed, without needing to update the OAuth Core >>>> RFC? >>>> >>>> b. >>>> >>>> 2009/9/25 Breno : >>>>> >>>>> This is another argument against trying to do better than TLS, since >>>>> OAuth >>>>> does not define its own encryption transport mechanism. >>>>> >>>>> Insecurity concerns about TLS are quite manageable by those who care >>>>> about >>>>> security. You can profile TLS at your will. For instance, to make you= r >>>>> FF >>>>> compliant with FIPS-140-2 TLS profile, follow the instructions here: >>>>> >>>>> >>>>> >>>>> http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140-= 2?style_mode=3Dinproduct&s=3Dcipher%20suites >>>>> >>>>> On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav >>>>> >>>>> wrote: >>>>>> >>>>>> The one method I am sure we are going to support is a plaintext >>>>>> method. >>>>>> >>>>> -- >>>>> Breno de Medeiros >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 beaton@google.com Tue Sep 29 09:50:18 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3615328C19F for ; Tue, 29 Sep 2009 09:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbCkHcUt1nc6 for ; Tue, 29 Sep 2009 09:50:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 55B5228C1A6 for ; Tue, 29 Sep 2009 09:50:16 -0700 (PDT) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id n8TGpa1K020853 for ; Tue, 29 Sep 2009 09:51:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254243097; bh=7M9KYTZJ61sGN24G0EFnmxFkwOI=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=V 6UHgug2PFwosQV3oarUDJ2dpLJosr6012BJFWA7F1ZfsX1qRnYOBf3LdqdDcIvU1p82 uRG07fkMYOBsqMLfdA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=R3ZwbaXv8DQgh9w2lZCpv3Q5nyz9v13nziZMXKgt3nrP1paN36ZjOeZJrX6TI19u7 LCfkzUFunG/BB/d7Qz7bA== Received: from qw-out-2122.google.com (qwb9.prod.google.com [10.241.193.73]) by spaceape11.eur.corp.google.com with ESMTP id n8TGpXPo019893 for ; Tue, 29 Sep 2009 09:51:34 -0700 Received: by qw-out-2122.google.com with SMTP id 9so1120894qwb.15 for ; Tue, 29 Sep 2009 09:51:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.119.154 with SMTP id z26mr1946878qcq.38.1254243093257; Tue, 29 Sep 2009 09:51:33 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2054@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2054@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 29 Sep 2009 09:51:33 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 16:50:18 -0000 On Tue, Sep 29, 2009 at 9:34 AM, Eran Hammer-Lahav wrote: > * the raw HTTP request URI Usually. > * HTTP authentication headers (WWW-Authenticate, Authorize) Almost always. There are a few cases where OAuth signatures have been used to sign URLs embedded in web pages, but those aren't core use cases. All the other use cases I've seen allow HTTP headers. > * the Host HTTP header Always. > * the raw HTTP request entity-body Rarely. I don't think OAuth should attempt to provide bullet-proof security for deployments that can't use https. HTTP cookies are widely used in such deployments. So long as OAuth is as good as or better than HTTP cookies, we're probably fine. Cheers, Brian From eran@hueniverse.com Tue Sep 29 09:54:05 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053C73A68BB for ; Tue, 29 Sep 2009 09:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4amv3w-NkMD for ; Tue, 29 Sep 2009 09:54:04 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id DD9933A6ADC for ; Tue, 29 Sep 2009 09:54:03 -0700 (PDT) Received: (qmail 32767 invoked from network); 29 Sep 2009 16:55:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Sep 2009 16:55:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 29 Sep 2009 09:52:58 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 29 Sep 2009 09:55:29 -0700 Thread-Topic: [OAUTH-WG] Reevaluating Assumptions (Important!) Thread-Index: AcpBJRzAdjbvMRPURd6C/+V7qiHKZgAAGqjg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF2061@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2054@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@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 16:54:05 -0000 Can you name the platforms this is applicable for? (i.e. PHP5, Java, etc.) Not sure how the last comment relates to this thread... EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Tuesday, September 29, 2009 9:52 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >=20 > On Tue, Sep 29, 2009 at 9:34 AM, Eran Hammer-Lahav > wrote: > > * the raw HTTP request URI >=20 > Usually. >=20 > > * HTTP authentication headers (WWW-Authenticate, Authorize) >=20 > Almost always. There are a few cases where OAuth signatures have been > used to sign URLs embedded in web pages, but those aren't core use > cases. All the other use cases I've seen allow HTTP headers. >=20 > > * the Host HTTP header >=20 > Always. >=20 > > * the raw HTTP request entity-body >=20 > Rarely. >=20 > I don't think OAuth should attempt to provide bullet-proof security > for deployments that can't use https. HTTP cookies are widely used in > such deployments. So long as OAuth is as good as or better than HTTP > cookies, we're probably fine. >=20 > Cheers, > Brian From hallam@gmail.com Tue Sep 29 10:16:29 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E513A694D for ; Tue, 29 Sep 2009 10:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwXhPO1W08E2 for ; Tue, 29 Sep 2009 10:16:28 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 65E6F3A63C9 for ; Tue, 29 Sep 2009 10:16:28 -0700 (PDT) Received: by yxe30 with SMTP id 30so7660687yxe.29 for ; Tue, 29 Sep 2009 10:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ktd/SSdFBFglub61C3VNs9FGHpJCR0avCx9jl+0Z8m8=; b=Vx7C+ENiTy7tgRyO9F4Zc/wBPLzuJUm7/SujeBwjen95DhO/9OyuKIzslSS1kU7e29 pfQrDqDaDzOYzh4JV8paUy2V82d300bQbgJppoTYkKl5p4/GkxsSwtMHW7GEutSpqLuh l7HGStnmSMoxltP8VdKppvEmLJ69Ir947WKAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rkjmiHKSkN9odmpF6O7rnoY4wT8FoFD9v6dhuIa3/kQnvzdGgEJ0dOZ3ohIzFPg0fz BFCT+xCHTzxjdkvBXRqFlyYHIdIk8fbjwQ6Z/lfeHIATZ4QBtwMqaWfAeSR3w7OcTvVM LipZy9tovxEfSZO25mnDsof0XgyXwMAK8RY+Y= MIME-Version: 1.0 Received: by 10.90.153.10 with SMTP id a10mr3777450age.121.1254244666367; Tue, 29 Sep 2009 10:17:46 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC21EC4.7030608@bbn.com> <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> <4AC225D8.9090302@bbn.com> Date: Tue, 29 Sep 2009 13:17:45 -0400 Message-ID: From: Phillip Hallam-Baker To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 17:16:30 -0000 The problem with HMAC-SHA1 is not the security of the algorithm, it is the ongoing cost of explaining why it is safe. Relying on SSL is no solution as the SSL negotiation algorithm will fail completely if SHA1 is broken. There is a deployment trap, merchants are not going to tell their customers that they have to upgrade their browser to buy from them, CAs are not going to refuse to sell the only certs that the merchants will buy and the browser providers are not going to tell customers that they can't use SHA1 merchants if they upgrade. The MD5 transition was easy because every browser supported both algorithms= . The security area reviewer is going to insist that HMAC-SHA2 is a mandatory algorithm. There is no particular performance advantage to SHA1. We are going to have to make SHA1 obsolete at some point, why not now? I see no particular difficulty in making SHA1 a MUST support algorithm for backwards compatibility purposes and deprecate it as far as future revisions of the spec are concerned, i.e. if we end up with a backwards incompatible revision to the spec, clients MUST NOT offer SHA1 with the new version of the spec. On Tue, Sep 29, 2009 at 12:47 PM, Brian Eaton wrote: > Wow, this is a great discussion. =A0I'd like to make a few comments on > the goals... > > There are attacks against the kinds of protocols being discussed here > where a MITM or a malicious server can force a client to the weakest > signing algorithm supported by client. =A0I don't think we should worry > about a man-in-the-middle. =A0https is adequate prevention against MITM > attacks, and if the client isn't requiring https they probably have > bigger concerns than HMAC-SHA1 vs HMAC-SHA256. > > I'm not sure whether we should worry about malicious servers. =A0For > example, imagine a client is tricked into sending a signed OAuth > request to a malicious server, e.g. a client is tricked into sending a > request to https://evil.com using an access token originally issued by > https://good.com. =A0Note that this is NOT a man-in-the-middle attack. > The client is really talking to evil.com. The client is confused and > is sending authentication credentials issued by/for good.com to > evil.com. =A0There are various real-world situations where this can > happen. =A0Imagine a client following links or redirects and trying to > authenticate with OAuth. > > If we're using plaintext, this is a disaster. =A0The client just leaked > credentials to evil.com. > > If we're using HMAC-SHA1, this is less of a big deal. =A0The request is > signed for evil.com, and evil.com cannot replay it anywhere else. > Both the consumer secret and the token secret provide some security. > Even if the consumer secret leaks (e.g. it's embedded in a desktop > application), evil.com gains nothing. > > If we're using RSA-SHA1, the situation is better than plaintext, but > worse than HMAC-SHA1. =A0The token secret doesn't provide any additional > security for the RSA signatures. =A0evil.com would know the access > token, and if they somehow manage to steal the consumer secret, they > have everything they need to impersonate the client. > > I'm making some assumptions about the problem domain here. =A0Is it > reasonable to think about the problem of signature method choice using > this type of analysis? > > Cheers, > Brian > > > > > > > > > On Tue, Sep 29, 2009 at 8:20 AM, Richard Barnes wrote: >> That could work in the "OAuth delegation" use case, where the parties ar= e >> going to go to the effort of provisioning. =A0Even in that case, though,= you >> would also have to provision algorithms into the Resource Owner (i.e., t= he >> User), since he also needs to sign requests (to the Client/Consumer) as = part >> of the dance. >> >> I'm more worried about the general usage of OAuth signatures to sign HTT= P >> requests. =A0Again making the analogy to Digest, there is an assumption = there >> that keys are pre-provisioned (=3Dtokens for OAuth), but not algorithms = (See >> Section 3.2.1). >> >> --Richard >> >> >> >> Hubert Le Van Gong wrote: >>> >>> An alternative would be to say that the OOB initiation phase that takes >>> place >>> prior to the OAuth dance is the right time to perform such negotiation.= .. >>> After all it is about discovering each other's capabilities. >>> We would then only need some simple error message in the problem report= ing >>> ext. >>> >>> Just a thought. >>> >>> Hubert >>> >>> >>> On Tue, Sep 29, 2009 at 4:50 PM, Richard Barnes wrote= : >>>> >>>> Hey Blaine, >>>> >>>> You've got the general pattern right, but I'm not sure how well it map= s >>>> to >>>> the general use of OAuth signatures: One of the main benefits of OAuth >>>> vs. >>>> Digest is that it can be done in a single HTTP round-trip -- the serve= r >>>> doesn't need to issue a challenge in order for the client to construct >>>> the >>>> signature. =A0That creates a problem for crypto agility because by the= same >>>> token, the server doesn't have a chance to specify which cipher suites= it >>>> supports. =A0 (Here I'm using client and server in the HTTP sense, whi= ch I >>>> think map to your "consumer" and "service provider" below.) >>>> >>>> A couple of work-arounds occur to me: >>>> >>>> 1. Allow the client to provide multiple signatures using different cip= her >>>> suites, and let the server choose which one to validate (MUST use only >>>> one >>>> to prevent bid-down attacks). =A0If the client provides all the signat= ures >>>> it >>>> knows how to do, then this is equivalent to a full negotiation. >>>> >>>> 2. Allow the server to reject signatures and specify which cipher suit= es >>>> it >>>> supports, so that the client can cache for future requests. >>>> >>>> --Richard >>>> >>>> >>>> >>>> Blaine Cook wrote: >>>>> >>>>> I'm not sure what the consensus is here, but it seems that at a >>>>> minimum, we need a way to determine which algorithms are available, t= o >>>>> allow for negotiation of the cipher suite between a consumer and >>>>> service provider. >>>>> >>>>> Ideally the following would be true: >>>>> >>>>> 1. A service provider must be able to specify a set of acceptable >>>>> ciphers (please correct me if "cipher" is the wrong word to use here)= . >>>>> 2. A consumer must be able to specify a set of acceptable ciphers. >>>>> 3. There must be some simple way to determine the strongest common >>>>> cipher. >>>>> >>>>> Any takers? Would an ordered list in the HTTP headers (e.g., >>>>> X-OAuth-Supported-Ciphers) be sufficient? >>>>> >>>>> As to the question of a minimum set of supported ciphers, what about >>>>> creating a separate RFC (or other document?) that (a) specifies >>>>> required and optional ciphers, and (b) can be deprecated and point to >>>>> a new document as needed, without needing to update the OAuth Core >>>>> RFC? >>>>> >>>>> b. >>>>> >>>>> 2009/9/25 Breno : >>>>>> >>>>>> This is another argument against trying to do better than TLS, since >>>>>> OAuth >>>>>> does not define its own encryption transport mechanism. >>>>>> >>>>>> Insecurity concerns about TLS are quite manageable by those who care >>>>>> about >>>>>> security. You can profile TLS at your will. For instance, to make yo= ur >>>>>> FF >>>>>> compliant with FIPS-140-2 TLS profile, follow the instructions here: >>>>>> >>>>>> >>>>>> >>>>>> http://support.mozilla.com/en-US/kb/Configuring+Firefox+for+FIPS+140= -2?style_mode=3Dinproduct&s=3Dcipher%20suites >>>>>> >>>>>> On Thu, Sep 24, 2009 at 7:53 PM, Eran Hammer-Lahav >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> The one method I am sure we are going to support is a plaintext >>>>>>> method. >>>>>>> >>>>>> -- >>>>>> Breno de Medeiros >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From beaton@google.com Tue Sep 29 10:17:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28E73A68DB for ; Tue, 29 Sep 2009 10:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFaP94pjbVGk for ; Tue, 29 Sep 2009 10:17:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 6034A3A6938 for ; Tue, 29 Sep 2009 10:17:10 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id n8THIS2v006731 for ; Tue, 29 Sep 2009 18:18:29 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254244709; bh=iEHrAyRv+heSIUfo7WEDB6liEzs=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=AlufnbSN1RDbHqII0k 1u15awu2bwpVWwsWy9MUnu693/rxLWy+yksFyg5vfDVUBH0/Y/z7CdvwYA2ZScRWOHC A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=sCJh73854arFunxgI12KLZ7jTRR5vFhm4CglwYztVdufrmxFk2RqwNK3+g5aPvHMD 70K7g8NKvQZjcPzV3FDLw== Received: from qyk32 (qyk32.prod.google.com [10.241.83.160]) by wpaz1.hot.corp.google.com with ESMTP id n8THIQGT002291 for ; Tue, 29 Sep 2009 10:18:26 -0700 Received: by qyk32 with SMTP id 32so4236657qyk.1 for ; Tue, 29 Sep 2009 10:18:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.9 with SMTP id w9mr2053608qcc.17.1254244689039; Tue, 29 Sep 2009 10:18:09 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2061@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2054@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2061@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 29 Sep 2009 10:18:08 -0700 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav 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] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 17:17:12 -0000 The SSL comment relates to your initial e-mail. You wrote "HTTPS cannot be required due to deployment limitations", and had some quite sensible remarks about not basing OAuth security solely on https. I just wanted to add that most deployments that don't use https don't have perfect security *anyway*, and that we shouldn't bend over backwards trying to give it to them with OAuth. The other comments are really not platform specific. Raw HTTP request URI: this is almost always available, but is sometimes a bit tricky to get ahold of. For example, a reverse proxy may rewrite the URL, or various thick frameworks might hide the URL. I don't know of any platforms where this is out-and-out impossible, but I do know of several where it is annoying. Raw entity body: this is actually really hard to capture, on almost any platform. The problem is that most frameworks implement some form of streaming for request bodies, for performance and scalability reasons. If one piece of code reads the request body, that might cause problems for another piece of code down the line that also needs to read the request body. Buffering the entire request body is feasible for small requests, but causes problems for larger ones. It can be done in some circumstances, but developers need to shuck and jive to do it. And it might not be feasible at all in complicated environments where proxies are used. Cheers, Brian On Tue, Sep 29, 2009 at 9:55 AM, Eran Hammer-Lahav wr= ote: > Can you name the platforms this is applicable for? (i.e. PHP5, Java, etc.= ) > > Not sure how the last comment relates to this thread... > > EHL > >> -----Original Message----- >> From: Brian Eaton [mailto:beaton@google.com] >> Sent: Tuesday, September 29, 2009 9:52 AM >> To: Eran Hammer-Lahav >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) >> >> On Tue, Sep 29, 2009 at 9:34 AM, Eran Hammer-Lahav >> wrote: >> > * the raw HTTP request URI >> >> Usually. >> >> > * HTTP authentication headers (WWW-Authenticate, Authorize) >> >> Almost always. =A0There are a few cases where OAuth signatures have been >> used to sign URLs embedded in web pages, but those aren't core use >> cases. =A0All the other use cases I've seen allow HTTP headers. >> >> > * the Host HTTP header >> >> Always. >> >> > * the raw HTTP request entity-body >> >> Rarely. >> >> I don't think OAuth should attempt to provide bullet-proof security >> for deployments that can't use https. =A0HTTP cookies are widely used in >> such deployments. =A0So long as OAuth is as good as or better than HTTP >> cookies, we're probably fine. >> >> Cheers, >> Brian > From eran@hueniverse.com Tue Sep 29 10:25:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949713A67FC for ; Tue, 29 Sep 2009 10:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.723 X-Spam-Level: X-Spam-Status: No, score=-3.723 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukIxqRhYBWj3 for ; Tue, 29 Sep 2009 10:25:11 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BBBD93A69AF for ; Tue, 29 Sep 2009 10:25:11 -0700 (PDT) Received: (qmail 26526 invoked from network); 29 Sep 2009 17:26:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Sep 2009 17:26:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 29 Sep 2009 10:24:14 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 29 Sep 2009 10:26:38 -0700 Thread-Topic: [OAUTH-WG] Reevaluating Assumptions (Important!) Thread-Index: AcpBKN5A4eh7lUyfRI+EEee/h8UrAgAAHjFw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF2082@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2054@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2061@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@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 17:25:12 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Tuesday, September 29, 2009 10:18 AM > Raw HTTP request URI: this is almost always available, but is > sometimes a bit tricky to get ahold of. For example, a reverse proxy > may rewrite the URL, or various thick frameworks might hide the URL. > I don't know of any platforms where this is out-and-out impossible, > but I do know of several where it is annoying. I am looking for ways to simplify the request normalization part which is w= here 99% of the problems people have are. At a minimum, OAuth should guarantee the integrity of the request URI (whic= h includes the Host request header) and provide some support for the entity= -body. There are generally three ways to do it: 1. Assume the raw data is available and just define how to put it together = (i.e. URI&Host&Body-hash) and sign/hash/etc. that. 2. Assume the raw data is not available and: a. Repeat what is being signed, to be compared to the actual request by t= he server b. Normalize what is being signed by using the bits we know are always av= ailable Today we have 2b. I would like to use 1. EHL From beaton@google.com Tue Sep 29 10:30:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800A33A697D for ; Tue, 29 Sep 2009 10:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cN1F0RJkU3i4 for ; Tue, 29 Sep 2009 10:30:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id B180C3A697B for ; Tue, 29 Sep 2009 10:30:52 -0700 (PDT) Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id n8THWCOM016855 for ; Tue, 29 Sep 2009 10:32:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254245532; bh=XBMjwWNzXDeFGDGRCducPirZr/Y=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=i hyWYE4UhQyMMxkYwc0L6Uj8yNjwijBbighwYVtz+3rJgkVzJH+oTr6JTI/MMqX/rW++ WcV75+jnOu+Hc9gxPQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=xooOe8ZwZRta3Rk087xNOaUEKxkYDYyDtYK79ezzYsfbfFPsob8hEblsb7qLC8KbE 7xOdiQXJjoD9DklBX5dPQ== Received: from qw-out-2122.google.com (qwb9.prod.google.com [10.241.193.73]) by spaceape8.eur.corp.google.com with ESMTP id n8THW9Fu014315 for ; Tue, 29 Sep 2009 10:32:09 -0700 Received: by qw-out-2122.google.com with SMTP id 9so1649460qwb.61 for ; Tue, 29 Sep 2009 10:32:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.41.74 with SMTP id n10mr2046640qce.13.1254245528902; Tue, 29 Sep 2009 10:32:08 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4ABBE85C.3030301@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC21EC4.7030608@bbn.com> <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> <4AC225D8.9090302@bbn.com> Date: Tue, 29 Sep 2009 10:32:08 -0700 Message-ID: From: Brian Eaton To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 17:30:53 -0000 On Tue, Sep 29, 2009 at 10:17 AM, Phillip Hallam-Baker wrote: > Relying on SSL is no solution as the SSL negotiation algorithm will > fail completely if SHA1 is broken. OAuth is not going to save us if SSL is broken. > The security area reviewer is going to insist that HMAC-SHA2 is a > mandatory algorithm. The security reviewer is going to lose that fight, because we cannot mandate deployment decisions for consumers or service providers. Saying that HMAC-SHA2 must be supported is equivalent to saying that service providers must use passwords to authenticate users, or must use https, or must support openid. Those are not spec decisions. They are deployment decisions. Some service providers might choose to only support RSA public keys, for example. Forcing those service providers to violate a "must" in the spec is not useful. > There is no particular performance advantage to > SHA1. We are going to have to make SHA1 obsolete at some point, why > not now? This I agree with. I think it's reasonable (even important!) for the spec to offer a simple means of upgrading from HMAC-SHA1 to HMAC-SHA2. I'm just not wild about the idea of the spec saying that anyone has to support any cryptographic scheme. Cheers, Brian From hallam@gmail.com Tue Sep 29 10:46:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5554F3A69B6 for ; Tue, 29 Sep 2009 10:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWtqD679OLuI for ; Tue, 29 Sep 2009 10:46:38 -0700 (PDT) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 294DA3A69A3 for ; Tue, 29 Sep 2009 10:46:37 -0700 (PDT) Received: by gxk4 with SMTP id 4so4037816gxk.8 for ; Tue, 29 Sep 2009 10:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qGseURl5X8z7jPcJTmzlqgLE3Ds+bG+JHTC/Q+kVltM=; b=laxEevor7rPQ9X4byaT7TjTJnqPnnYwiHl2TFpZrBRf31lR2bi93JA1AYI0nIlYIim ni0hRSbIWAp37rDxXJue+07/oKWa3Sx5E0LZWj6unySamDjBOjpL0Ht4GBplM2DZ/IOp if01ODMrjxhVckTTUihYcDistmOGf3XlhYf64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gCv0sH1bfiTQwdVdWwSuNGBKgFLOXQyIk6hD2EwpsVe0C1ZgHhuCnBFCLM4olANzkR DG/LbsdymycGnkW65BWO5DTToKfZDn1O4HK2aTlXLai2pIrQVgS6HB6MSziVY/2VJbDc rSuCHhIjzt155jfdj6hGe/KbODasVS6RB89Dg= MIME-Version: 1.0 Received: by 10.90.233.16 with SMTP id f16mr1781506agh.35.1254246475341; Tue, 29 Sep 2009 10:47:55 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343784D58C87@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4AC21EC4.7030608@bbn.com> <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> <4AC225D8.9090302@bbn.com> Date: Tue, 29 Sep 2009 13:47:54 -0400 Message-ID: From: Phillip Hallam-Baker To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 17:46:39 -0000 I think you don't quite appreciate what is meant by mandatory in this context. Mandatory is mandatory to implement, not mandatory to use. All that making an algorithm mandatory means is that an implementation that advertises itself as RFCxxxx compliant MUST support it. So if someone buys a framework that advertises OATH support the algorithm must be one of the ones in the box. It does not mean that anyone has to use it, or for that matter that every person who codes up an implementation for private purposes has to implement it. It is the same with the HTTP spec, a HTTP client MUST implement GET, PUT and POST. But that does not mean that people have to use those methods. And if someone was writing a single purpose bit of code they could implement only GET if that is all their implementation needed. Now it gets a little trickier if we are talking about advertising algorithms in the context of negotiations as there is a policy layer as well. If OATH is being used in an NSA context they would probably want to require use of a Suite-A algorithm. In that case they don't have to offer the mandatory to implement algorithm, but they do have to implement enough to be able to negotiate use of their secure algorithm. That does not affect OATH but does affect IPSEC. This is an argument that we end up going through in every security working group. We really should just write a paper and get the IAB to stamp it. On Tue, Sep 29, 2009 at 1:32 PM, Brian Eaton wrote: > On Tue, Sep 29, 2009 at 10:17 AM, Phillip Hallam-Baker = wrote: >> Relying on SSL is no solution as the SSL negotiation algorithm will >> fail completely if SHA1 is broken. > > OAuth is not going to save us if SSL is broken. > >> The security area reviewer is going to insist that HMAC-SHA2 is a >> mandatory algorithm. > > The security reviewer is going to lose that fight, because we cannot > mandate deployment decisions for consumers or service providers. > > Saying that HMAC-SHA2 must be supported is equivalent to saying that > service providers must use passwords to authenticate users, or must > use https, or must support openid. =A0Those are not spec decisions. > They are deployment decisions. =A0Some service providers might choose to > only support RSA public keys, for example. =A0Forcing those service > providers to violate a "must" in the spec is not useful. > >> There is no particular performance advantage to >> SHA1. We are going to have to make SHA1 obsolete at some point, why >> not now? > > This I agree with. =A0I think it's reasonable (even important!) for the > spec to offer a simple means of upgrading from HMAC-SHA1 to HMAC-SHA2. > =A0I'm just not wild about the idea of the spec saying that anyone has > to support any cryptographic scheme. > > Cheers, > Brian > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From beaton@google.com Tue Sep 29 10:55:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDF73A68EF for ; Tue, 29 Sep 2009 10:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FpwZNbWAxor for ; Tue, 29 Sep 2009 10:55:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 87E8E3A67F8 for ; Tue, 29 Sep 2009 10:55:10 -0700 (PDT) Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id n8THuSWU014457 for ; Tue, 29 Sep 2009 18:56:30 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254246990; bh=3UGmLUWUU89kDSXjKmzau8wnf30=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=L U9+uH8dXZyXtQOkxtuzUBPiLmUwRD4ib9f+kMp94yyKaAPX3A3S3j39qAIlgwTR/ei1 hRCDRnB4G0el+91isw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=kiYb2eR4wxxyD/B34FNunZUgs1jG6eSKfaiWaiyrQ1l6tFUL1nKux1h287MZcbctt RtOIVKe0hkbA5SozHvGrQ== Received: from qyk29 (qyk29.prod.google.com [10.241.83.157]) by zps75.corp.google.com with ESMTP id n8THu3Gk022751 for ; Tue, 29 Sep 2009 10:56:26 -0700 Received: by qyk29 with SMTP id 29so4168933qyk.32 for ; Tue, 29 Sep 2009 10:56:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.10.229 with SMTP id q37mr2186551qcq.106.1254246985082; Tue, 29 Sep 2009 10:56:25 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4AC21EC4.7030608@bbn.com> <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> <4AC225D8.9090302@bbn.com> Date: Tue, 29 Sep 2009 10:56:25 -0700 Message-ID: From: Brian Eaton To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 17:55:11 -0000 On Tue, Sep 29, 2009 at 10:47 AM, Phillip Hallam-Baker wrote: > All that making an algorithm mandatory means is that an implementation > that advertises itself as RFCxxxx compliant MUST support it. So if > someone buys a framework that advertises OATH support the algorithm > must be one of the ones in the box. > > It does not mean that anyone has to use it, or for that matter that > every person who codes up an implementation for private purposes has > to implement it. Gotcha. That makes perfect sense to me. How about the following scheme for the negotiation piece of the protocol? 1) Client attempts a signature with the best algorithm they believe the server supports. 2) If the server does not support that algorithm, the server returns with an error response listing the algorithms they are willing to accept. 3) Clients may retry with other algorithms in the list. That seems like it would give us a smooth upgrade path from SHA1 to SHA2. Cheers, Brian From romeda@gmail.com Tue Sep 29 11:57:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBBF28C0D9 for ; Tue, 29 Sep 2009 11:57: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NUIHfriAO6M for ; Tue, 29 Sep 2009 11:57:37 -0700 (PDT) Received: from mail-bw0-f227.google.com (mail-bw0-f227.google.com [209.85.218.227]) by core3.amsl.com (Postfix) with ESMTP id 7A3003A67EE for ; Tue, 29 Sep 2009 11:57:37 -0700 (PDT) Received: by bwz27 with SMTP id 27so4119543bwz.43 for ; Tue, 29 Sep 2009 11:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=Za4ancS1AvgU//zIeuaXXDOpiQsPhsXMxoRV6+G+XEI=; b=SZkKD0i4wBE/2wUeb30gEmuOExd2VwzRrS6mboQ/hvrPoUY7JQp6YcclJJAS8p+LIY X53SwFFLab5rXxmV/o3oerIVbKH55XYStAkDGw7qeZdyot8xgnzlYEe12EHtPt/jIDcs Ti6T0WEzNAnm2lj3fZybkXrgw+9Iel8z/C9EY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=g3UyejED3pYzmk2zNtwjCl+eANSon7tr/O7vqhUymq43jPZFBuACcu9tK4bJH5sUE7 M3pGRUPa3O4+yQ3U04uxOyFpCTYA3B58zvMpp+qzBy8NIKcjRWu3Jo4znTdJ2CXgTdwb A/XfTB8VpG4HTaH5hFqTyUJnTZlVKGlcLCy3s= MIME-Version: 1.0 Received: by 10.204.154.203 with SMTP id p11mr4424482bkw.180.1254250735286; Tue, 29 Sep 2009 11:58:55 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4AC21EC4.7030608@bbn.com> <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> <4AC225D8.9090302@bbn.com> From: Blaine Cook Date: Tue, 29 Sep 2009 19:58:35 +0100 Message-ID: To: Brian Eaton Content-Type: text/plain; charset=UTF-8 Cc: Phillip Hallam-Baker , oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 18:57:39 -0000 2009/9/29 Brian Eaton : > How about the following scheme for the negotiation piece of the protocol? > > 1) Client attempts a signature with the best algorithm they believe > the server supports. > 2) If the server does not support that algorithm, the server returns > with an error response listing the algorithms they are willing to > accept. > 3) Clients may retry with other algorithms in the list. > > That seems like it would give us a smooth upgrade path from SHA1 to SHA2. +1. This nicely supports the server being able to say "no" to PLAINTEXT requests made over non-SSL HTTP (and probably delete the token if the client makes such a request). In the interests of moving this along, any opposition? Additional support? b. From romeda@gmail.com Tue Sep 29 12:05:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95E73A6831 for ; Tue, 29 Sep 2009 12:05: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8avX6n--lqN for ; Tue, 29 Sep 2009 12:05:06 -0700 (PDT) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by core3.amsl.com (Postfix) with ESMTP id 830A53A6803 for ; Tue, 29 Sep 2009 12:05:06 -0700 (PDT) Received: by fxm27 with SMTP id 27so2924544fxm.42 for ; Tue, 29 Sep 2009 12:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=5i0m8ni102R7I1qsweEf2aUYpU2E9xjgz4LNyHtfNp0=; b=q84yX25tYb5U9d6GPnnVnCz1kKUpedWrbfWdGxUJNrNPnc+ewGrhf4P36nH3ptrptL ocMUIi/1xRNNizheW1VFi3BuavazYXw9z72AQ2SYHDYBeSVlJ+Ir/zHqGBE1xRpxD3o6 WsZPsOOLAv9E5W/h92OQT3jMxa38LXQFAtzRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=QOkNxxrwBiaY/hin5a5xskFdsDyRX5Kh2YeFHL4TuDMg73rHgAUlKSnQeOL1cl2ljB R4F4Aojuax6Q8vvRZPctePzbrmlHZd+agh4Ira32NpQefJA76RW06O3xGUX6AINBG9tX YUjAgFgNwRgAtShxrSHC9PDOAlkkhgfdApva0= MIME-Version: 1.0 Received: by 10.204.34.71 with SMTP id k7mr4432355bkd.206.1254251184134; Tue, 29 Sep 2009 12:06:24 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Tue, 29 Sep 2009 20:06:04 +0100 Message-ID: To: "oauth@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 19:05:07 -0000 2009/9/22 Eran Hammer-Lahav : > * HTTPS cannot be required due to deployment limitations > > This still holds true. OAuth security cannot be based solely on using HTT= PS due to deployment limitations. However, the protocol must easily support= deployments that have HTTPS easily available and not make them waste resou= rces will timestamps, nonces, and other security elements. While PLAINTEXT = provides such support, it doesn't go far enough and still requires the pres= ence of such parameters. I want to point out that it is not mandatory that deployments with HTTPS use (or check) timestamps or nonces; it's not even mandatory for those without HTTPS. If resource usage is a concern, the provider can (and should) evaluate the security/resource trade-offs involved. > * OAuth will be mostly used with proprietary APIs > > This has proved to be false. With new open APIs there is a greater need t= o enable clients to interact with a protected resource that it has not enco= untered before or one it has been coded explicitly for. What this means is = that we need more discovery features built into the core protocol or more r= equired portions to promote interoperability. There should be a minimum tha= t any client facing an OAuth 404 should be able to handle. An action item here is to collect examples of APIs that rely on OAuth that are hampered or complicated by the lack of discovery of endpoints and consumer key negotiation. Examples of APIs that provide discovery are particularly useful. > The third item: > > * Many web platforms do not provide access to the wire HTTP request URI (= either on the client or server side) Server side request libraries are often more forgiving here. Ruby's Net::HTTP library makes it almost impossible to get access to the raw request that will be sent; it's possible to do some extensive surgery to gain access to the outgoing request, but it's very seriously not code that you'd want to put into production. Higher level HTTP request libraries (e.g., Ruby's open-uri[1]) make it nearly impossible to get at the outgoing request. It's also very much not clear how one would intercept the composed request from, for example, the Apache Java HttpClient library. b. [1] http://www.ruby-doc.org/stdlib/libdoc/open-uri/rdoc/ From hubertlvg@gmail.com Tue Sep 29 13:21:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC5E3A68F0 for ; Tue, 29 Sep 2009 13:21:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j2Wp2w+UjFa for ; Tue, 29 Sep 2009 13:21:30 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 769913A68B4 for ; Tue, 29 Sep 2009 13:21:30 -0700 (PDT) Received: by bwz6 with SMTP id 6so2322124bwz.37 for ; Tue, 29 Sep 2009 13:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=CBJvhqg0qFuYnhFPWPFNfZz70CPxJ42OiBgn0zolEMs=; b=xIWfe3UGkBfwHEaRhTNCB7iFDczDVj2VS99616n8fLHW7RWjTuY0vk61q0rIalKH5T k1eZoBWX+4aulQYOTLy4HHIRBHSbqUntKuUdYQKe6fgvDXi8F6Z08BCg+ekqksR7DRKw 128yKCRGayWic78MR+wHaYDreOIsgf7XnoZX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=A2lhA5L+8iuaSz5Dr+xAihELhTqTdMd7J1cckAOGFTj3/UnIYuc6VMrHWHKMjZsM4Y VOmodvN/D65AK8wAIpa6mH4icSdSfzfEfEtckJ30UK3UB3I+6rRVtTD0lCgJ6TZnkX2t 9ZZd55dgV4glI5RYmnq7guFi9Ax+yw+xS+Di4= MIME-Version: 1.0 Received: by 10.204.155.69 with SMTP id r5mr4538025bkw.136.1254255766338; Tue, 29 Sep 2009 13:22:46 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4AC21EC4.7030608@bbn.com> <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> <4AC225D8.9090302@bbn.com> Date: Tue, 29 Sep 2009 22:22:46 +0200 Message-ID: <6c0fd2bc0909291322w630a044frbcf374f3fe28be8c@mail.gmail.com> From: Hubert Le Van Gong To: Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 Cc: Phillip Hallam-Baker , oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 20:21:31 -0000 +1 on the negotiation protocol. Do we also have consensus on a must-implement list of protocols that would list: - plaintext - SHA1 cipher suite - SHA2 cipher suite Cheers, Hubert On Tue, Sep 29, 2009 at 8:58 PM, Blaine Cook wrote: > 2009/9/29 Brian Eaton : >> How about the following scheme for the negotiation piece of the protocol? >> >> 1) Client attempts a signature with the best algorithm they believe >> the server supports. >> 2) If the server does not support that algorithm, the server returns >> with an error response listing the algorithms they are willing to >> accept. >> 3) Clients may retry with other algorithms in the list. >> >> That seems like it would give us a smooth upgrade path from SHA1 to SHA2. > > +1. This nicely supports the server being able to say "no" to > PLAINTEXT requests made over non-SSL HTTP (and probably delete the > token if the client makes such a request). > > In the interests of moving this along, any opposition? Additional support? > > b. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jpanzer@google.com Tue Sep 29 13:59:17 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819843A6863 for ; Tue, 29 Sep 2009 13:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW6Gp7jtIoey for ; Tue, 29 Sep 2009 13:59:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 561353A6358 for ; Tue, 29 Sep 2009 13:59:16 -0700 (PDT) Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id n8TL0XpZ026752 for ; Tue, 29 Sep 2009 22:00:34 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1254258034; bh=fbnSJ1jV+UnN3PXE0FCP5vTyvEQ=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:X-System-Of-Record; b=qXySMa nY0ltVhTSN9OeM8EOm8b3f2+3ZVbkh5mgDX1gmNhhx5XApKI7Coy0qvaw4+3IJxpl8D 7uVzlElHq1doA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=PH8cB6W1HHO89AoMRCT6Czm1UGMuyXbOegPhtkUuJQBYw4IlbNpLx524IYnQSpzOI sbJZLoMlinChTcDyiPlZw== Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by spaceape12.eur.corp.google.com with ESMTP id n8TL06QL013771 for ; Tue, 29 Sep 2009 14:00:31 -0700 Received: by qyk9 with SMTP id 9so9022587qyk.30 for ; Tue, 29 Sep 2009 14:00:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.32.82 with SMTP id b18mr2352805qcd.10.1254258029689; Tue, 29 Sep 2009 14:00:29 -0700 (PDT) In-Reply-To: References: <6c0fd2bc0909220634sb5334fcw1890569fd84ece09@mail.gmail.com> <4AC21EC4.7030608@bbn.com> <6c0fd2bc0909290802k64d66fe9s44346d435e108fa0@mail.gmail.com> <4AC225D8.9090302@bbn.com> From: John Panzer Date: Tue, 29 Sep 2009 14:00:09 -0700 Message-ID: To: Blaine Cook Content-Type: multipart/alternative; boundary=0016364c650950fb590474bdb4a8 X-System-Of-Record: true Cc: Phillip Hallam-Baker , oauth@ietf.org Subject: Re: [OAUTH-WG] Mandatory signature algorithms? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 20:59:17 -0000 --0016364c650950fb590474bdb4a8 Content-Type: text/plain; charset=ISO-8859-1 +1; note that fits perfectly into RFC2617. (Though obviously a client that ends up sending anything secret over an insecure connection has possibly given up the game before the server has a chance to reject it. But hopefully this would help discourage such clients from even being deployed.) -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Tue, Sep 29, 2009 at 11:58 AM, Blaine Cook wrote: > 2009/9/29 Brian Eaton : > > How about the following scheme for the negotiation piece of the protocol? > > > > 1) Client attempts a signature with the best algorithm they believe > > the server supports. > > 2) If the server does not support that algorithm, the server returns > > with an error response listing the algorithms they are willing to > > accept. > > 3) Clients may retry with other algorithms in the list. > > > > That seems like it would give us a smooth upgrade path from SHA1 to SHA2. > > +1. This nicely supports the server being able to say "no" to > PLAINTEXT requests made over non-SSL HTTP (and probably delete the > token if the client makes such a request). > > In the interests of moving this along, any opposition? Additional support? > > b. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016364c650950fb590474bdb4a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1; note that fits perfectly into RFC2617. =A0

(Though o= bviously a client that ends up sending anything secret over an insecure con= nection has possibly given up the game before the server has a chance to re= ject it. =A0But hopefully this would help discourage such clients from even= being deployed.)

--
John Panzer / Google
jpanzer@google.com /= abstractionee= r.org / @jpanzer



On Tue, Sep 29, 2009 at 11:58 AM, Blaine= Cook <romeda@gmai= l.com> wrote:
2009/9/29 Brian Eaton <beaton@googl= e.com>:
> How about the following scheme for the negotiation p= iece of the protocol?
>
> 1) Client attempts a signature with the best algorithm they believe > the server supports.
> 2) If the server does not support that algorithm, the server returns > with an error response listing the algorithms they are willing to
> accept.
> 3) Clients may retry with other algorithms in the list.
>
> That seems like it would give us a smooth upgrade path from SHA1 to SH= A2.

+1. This nicely supports the server being able to say "no" = to
PLAINTEXT requests made over non-SSL HTTP (and probably delete the
token if the client makes such a request).

In the interests of moving this along, any opposition? Additional support?<= br>
b.
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016364c650950fb590474bdb4a8-- From hubertlvg@gmail.com Tue Sep 29 14:23:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEE9D3A6918 for ; Tue, 29 Sep 2009 14:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhFbeU0cEXze for ; Tue, 29 Sep 2009 14:23:10 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 35CDF3A67AA for ; Tue, 29 Sep 2009 14:23:10 -0700 (PDT) Received: by bwz6 with SMTP id 6so2363540bwz.37 for ; Tue, 29 Sep 2009 14:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z+htucXceEKlOnNJXwEnoCkSrHeAMtyutSaL8Tg8El4=; b=abRQ54woyZyhvC4ysh2/YpmMHfQYQ8sssNvBuVn30D5s8BtJr6/wICBPoCkqzl4nQ0 l2ZdXMVhY2i88DpmrMS0D0KZVvrHZHJw+R3bfnVz3fqBErWkSaorxy3fGYvygx+mhQ4S peufXjf86ew+eBWsJSnRSBHCNF0FFOdh29GqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YZ9AU4DQ2zz9FBBX3ZxjSj+ZSAS66uTlRzgWCFBw3Ea44k3mnup6ZGtqAYcucJRYxU 43nIG1Llnn9Bmn+sbRMvmm+ixBOs4zfmBUKI46+rHZGgWCF7z+EFFDcxPNOddzMN+DJC /siIg6shCD+FOzuzSAwxaLaKlmuoLO14sXYdk= MIME-Version: 1.0 Received: by 10.204.32.209 with SMTP id e17mr4663953bkd.84.1254259468103; Tue, 29 Sep 2009 14:24:28 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2054@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2054@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 29 Sep 2009 23:24:28 +0200 Message-ID: <6c0fd2bc0909291424i7567030bj3285521d5e74e7a6@mail.gmail.com> From: Hubert Le Van Gong To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2009 21:23:11 -0000 We use Jersey [1] and you can see on the feature list on the right of the front page that we've added OAuth support :) All the features you mentioned below are supported in Jersey. Cheers, Hubert [1] https://jersey.dev.java.net/ On Tue, Sep 29, 2009 at 6:34 PM, Eran Hammer-Lahav wr= ote: > Reminder: > > Please help conduct the platform survey. Please answer this about the pla= tforms you use for developing HTTP applications. Does it provide access to: > > * the raw HTTP request URI > * HTTP authentication headers (WWW-Authenticate, Authorize) > * the Host HTTP header > * the raw HTTP request entity-body > > If we have wide enough support (3 years later) for these items, we can si= gnificantly simplify the signature workflow. If no one is going to reply wi= th information about the platforms they use I am going to assume that they = can (both client and server side) access all of the above. > > Please reply back by 10/6. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Eran Hammer-Lahav >> Sent: Monday, September 21, 2009 6:42 PM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Reevaluating Assumptions (Important!) >> >> OAuth has been designed over 2 years ago based on many assumptions that >> were true at that time. The most significant assumptions were: >> >> * HTTPS cannot be required due to deployment limitations >> * OAuth will be mostly used with proprietary APIs >> * Many web platforms do not provide access to the wire HTTP request URI >> (either on the client or server side) >> >> I strongly believe it would be a mistake to continue this work without >> questioning these assumptions and making sure we are not producing a >> lesser solution by trying to accommodate them. >> >> The first two assumptions are easy: >> >> * HTTPS cannot be required due to deployment limitations >> >> This still holds true. OAuth security cannot be based solely on using >> HTTPS due to deployment limitations. However, the protocol must easily >> support deployments that have HTTPS easily available and not make them >> waste resources will timestamps, nonces, and other security elements. >> While PLAINTEXT provides such support, it doesn't go far enough and >> still requires the presence of such parameters. >> >> * OAuth will be mostly used with proprietary APIs >> >> This has proved to be false. With new open APIs there is a greater need >> to enable clients to interact with a protected resource that it has not >> encountered before or one it has been coded explicitly for. What this >> means is that we need more discovery features built into the core >> protocol or more required portions to promote interoperability. There >> should be a minimum that any client facing an OAuth 404 should be able >> to handle. >> >> The third item: >> >> * Many web platforms do not provide access to the wire HTTP request URI >> (either on the client or server side) >> >> requires more research but it also holds the key to much of the >> protocol design, namely: >> >> - The canonicalization of the HTTP request parameter and URI - this was >> done due to the fact that at the time, many popular web platforms did >> not provide easy access to the raw HTTP request URI and headers. If >> this is no longer the case, OAuth can be significantly simplified to >> remove the need to process the parameters and only treat the request >> URI. >> >> - The inclusion of multiple parameter transmission methods - this was >> done due to lack of access to the Authorization header in some clients >> and server environment. If this is no longer a requirement or if we >> come to the conclusion that HTTP caching requires that we use the >> header in all requests, the need to support parameters in places other >> than the header will also go away. >> >> If we come to the conclusion that the last assumption is either >> incorrect or irrelevant (the requirement to use HTTP auth headers), we >> will be able to significantly simplify the protocol which will also >> accomplish improving interoperability and security. >> >> ACTION ITEM: >> >> We need to conduct a quick survey of web platforms to figure out if >> they provide access to the RAW HTTP request (client and server), and if >> they provide access to the HTTP auth headers (client and server). If >> you know, please reply with the information for the platforms you use. >> >> 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 Tue Sep 29 21:43:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7123A67F5 for ; Tue, 29 Sep 2009 21:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.705 X-Spam-Level: X-Spam-Status: No, score=-3.705 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYkW1h1HRmck for ; Tue, 29 Sep 2009 21:43:32 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B00E83A67A4 for ; Tue, 29 Sep 2009 21:43:32 -0700 (PDT) Received: (qmail 6940 invoked from network); 30 Sep 2009 04:44:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Sep 2009 04:44:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 29 Sep 2009 21:42:29 -0700 From: Eran Hammer-Lahav To: Blaine Cook , "oauth@ietf.org" Date: Tue, 29 Sep 2009 21:45:01 -0700 Thread-Topic: [OAUTH-WG] Reevaluating Assumptions (Important!) Thread-Index: AcpBN/gYdRFC66bIR8eGeSrr6e6HoQAUIkkA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF21C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@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 Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 04:43:34 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Blaine Cook > Sent: Tuesday, September 29, 2009 12:06 PM =20 > Server side request libraries are often more forgiving here. Ruby's > Net::HTTP library makes it almost impossible to get access to the raw > request that will be sent; it's possible to do some extensive surgery > to gain access to the outgoing request, but it's very seriously not > code that you'd want to put into production. >=20 > Higher level HTTP request libraries (e.g., Ruby's open-uri[1]) make it > nearly impossible to get at the outgoing request. >=20 > It's also very much not clear how one would intercept the composed > request from, for example, the Apache Java HttpClient library. Do they give access to the request URI and Host? That is, the information t= hat is going to be included in: GET /request_uri HTTP/1.1 Host: example.com Or does Ruby do something stupid and changes the request URI, encode it, et= c.? EHL From romeda@gmail.com Wed Sep 30 08:06:02 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3E2F3A6932 for ; Wed, 30 Sep 2009 08:06: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6t-4pell6el for ; Wed, 30 Sep 2009 08:06:02 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 775133A68AC for ; Wed, 30 Sep 2009 08:06:01 -0700 (PDT) Received: by bwz6 with SMTP id 6so2864628bwz.37 for ; Wed, 30 Sep 2009 08:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=KwHUaT7QwglGMV1Yg51u2yV2tOkN9JHDfkLC4mOBBiI=; b=umAxZkQF9GTKBbyYLCLpQdh0calyIio6m3l3kNoKMM6SdmJrTvQ6QX+b3CaGOGFxV1 IcpxeF0XjWtTmHpVWC5T6K8uB95FUeL8U+p9YeraqZTOE/WFwGECV6+eBfEFnOkOzpaA PnKH3T8QOb+5DOLV9b1T2k2bqegKJ6Q+3a24o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=G5IPhLw9RA8+a9CtSFfXm+cSqW4O45SjjcSPAgxrLJn+4g/wOsG3G/106db6RPW+Mp kYe3n91HceQH9pbk3BCQhplnlcr0m4IEJ2ruAgBQ7qdjcogk5lxW8WB5PEzDmTgU1j9n uwDLl9SzBfp3We1mU+sPoMWNoJDXzUEvbtbVU= MIME-Version: 1.0 Received: by 10.204.34.200 with SMTP id m8mr5574574bkd.73.1254323239267; Wed, 30 Sep 2009 08:07:19 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF21C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF21C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Blaine Cook Date: Wed, 30 Sep 2009 16:06:59 +0100 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=UTF-8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 15:06:02 -0000 2009/9/30 Eran Hammer-Lahav : >> Server side request libraries are often more forgiving here. Ruby's >> Net::HTTP library makes it almost impossible to get access to the raw >> request that will be sent; it's possible to do some extensive surgery >> to gain access to the outgoing request, but it's very seriously not >> code that you'd want to put into production. >> >> Higher level HTTP request libraries (e.g., Ruby's open-uri[1]) make it >> nearly impossible to get at the outgoing request. >> >> It's also very much not clear how one would intercept the composed >> request from, for example, the Apache Java HttpClient library. > > Do they give access to the request URI and Host? That is, the information that is going to be included in: > > GET /request_uri HTTP/1.1 > Host: example.com > > Or does Ruby do something stupid and changes the request URI, encode it, etc.? Well, generally (and this goes for client libs in all languages), a request will be constructed like so: === request myRequest = MakeNewRequest(path, parameters, headers) httpClient myClient = MakeNewClient(host, port) result myResult = httpClient.sendRequest(myRequest) === or some variation on that, but the underlying libraries almost always do it that way. The problem is that "parameters" and "headers" is usually some kind of hash that gets translated into a query string and/or request body. The translation normally happens with a private method in the request class or worse in the httpClient; sometimes (mostly) you can get the request data out of the request object, but you have no guarantee that the httpClient is going to munge it (which would be *hell* to debug). Worse is that wrappers (like open-uri) often take the above code and simplify it, like so: === simpleHttpClient.get(host, port, path, parameters, headers) === or even: === simpleHttpClient.post("http://example.com/path/", { "parameter" => "value" }, { "Accept" => "text/html" }) === since everything happens internally, you have to add OAuth support to simpleHttpClient, or choose a different client, in order to use OAuth. The approach taken by the existing OAuth spec means that developers can add OAuth support irrespective of the client they're using. It's worth noting that this has enabled OAuth support in virtually every major language --- this, despite the fact that I'm not aware of a single "primary" HTTP client library supporting OAuth "natively" I'm not sure what the right approach is here, but I do know that while figuring out the Signature Base String is difficult, it's *much* easier (and safer) than hacking the internals of your [least] favourite HTTP client. b. From onyxraven@gmail.com Wed Sep 30 08:40:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0120428C124 for ; Wed, 30 Sep 2009 08:40:55 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZL15LeBUKhX for ; Wed, 30 Sep 2009 08:40:53 -0700 (PDT) Received: from mail-yw0-f202.google.com (mail-yw0-f202.google.com [209.85.211.202]) by core3.amsl.com (Postfix) with ESMTP id 41B323A699C for ; Wed, 30 Sep 2009 08:40:53 -0700 (PDT) Received: by ywh40 with SMTP id 40so6534582ywh.32 for ; Wed, 30 Sep 2009 08:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=RTlWOt1tvuD6gxTfkR/oTtZHb078gL2oHrwTINfGKVg=; b=wfDZUZfGeOeP9Cy5NAZBf7sZRmUksLgQnefEiatpqKEcah/EGz2OP7IvBAStQyR/pp J7tF2Lfb0emNqXZ5p26jMcFWkKY9J3/wrHX+UGYjMFOfFxzfLLWyCCvyyRbcWNrOidoQ HJv/TVTs/vM7cZktxcSibN3fdsfsjMMiIpfHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gziy+luvHH8r8UPcQIbyU9W4IF/U/zQ5zlRd09m8NzMsR4e8rEqXSOoZiC3bTuNB8w HwWQyevVIJ9Hz9g3FkzX9M9OceoPjg7EcimgSoAz9+iipILDt0U3kg/vu/YStZKOdNQR dczlajrU0RssjfMp7D/Zy1XOe5g2kexVVbGBs= MIME-Version: 1.0 Received: by 10.150.44.27 with SMTP id r27mr133421ybr.263.1254325333779; Wed, 30 Sep 2009 08:42:13 -0700 (PDT) Date: Wed, 30 Sep 2009 09:42:13 -0600 Message-ID: From: Justin Hart To: oauth@ietf.org Content-Type: multipart/alternative; boundary=000e0cd59c96f3e5ab0474cd5f9e Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 15:40:55 -0000 --000e0cd59c96f3e5ab0474cd5f9e Content-Type: text/plain; charset=ISO-8859-1 PHP, all of the above are possible (client and server) when using curl, 'raw' fsockopen, HttpRequest (almost all libraries like PEAR http request and Zend Http Client use one of these) Clients with HTTP libraries based on a browser (Javascript in a browser, Flash (Air?), Java applets, Apache HttpClient, .NET, iPhone etc) the response body is hidden (the headers too? ) for anything other than a 200. This has, in my experience, made using these technologies hard to use at times. With the discussion on hashing methods - should we figure out which platforms have acceptable (fast enough and working) implementations of the other algorithms as well? (It looks like at least PHP5 supports sha256 it with hash_hmac, and theres a js impl by Paul Johnston (same as the google code oauth lib uses for sha1)). ---------- Forwarded message ---------- From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Tue, 29 Sep 2009 09:34:54 -0700 Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) Please help conduct the platform survey. Please answer this about the platforms you use for developing HTTP applications. Does it provide access to: * the raw HTTP request URI * HTTP authentication headers (WWW-Authenticate, Authorize) * the Host HTTP header * the raw HTTP request entity-body If we have wide enough support (3 years later) for these items, we can significantly simplify the signature workflow. If no one is going to reply with information about the platforms they use I am going to assume that they can (both client and server side) access all of the above. Please reply back by 10/6. EHL --000e0cd59c96f3e5ab0474cd5f9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable PHP, all of the above are possible (client and server) when using curl, = 9;raw' fsockopen, HttpRequest (almost all libraries like PEAR http requ= est and Zend Http Client use one of these)

Clients with HTTP librari= es based on a browser (Javascript in a browser, Flash (Air?), Java applets,= Apache HttpClient, .NET, iPhone etc) the response body is hidden (the head= ers too? ) for anything other than a 200.=A0 This has, in my experience, ma= de using these technologies hard to use at times.

With the discussion on hashing methods - should we figure out which pla= tforms have acceptable (fast enough and working) implementations of the oth= er algorithms as well?=A0 (It looks like at least PHP5 supports sha256 it w= ith hash_hmac, and theres a js impl by Paul Johnston (same as the google co= de oauth lib uses for sha1)).

---------- Forwarded message ----------
From:=A0Eran Hammer-Lahav &l= t;eran@hueniverse.= com>
To:=A0"oauth@ietf.org" <oauth@ietf.org>
Date:=A0Tue, 29 Sep 2009 09:34:54 -0700
Subject:=A0Re: [OAUTH-WG] Reeval= uating Assumptions (Important!)

Please help conduct the platform survey. Please answer this about the platforms you use for developing HTTP applications. Does it provide access to:

* the raw HTTP request URI
* HTTP authentication headers (WWW-Authenticate, Authorize)
* the Host HTTP header
* the raw HTTP request entity-body

If we have wide enough support (3 years later) for these items, we can significantly simplify the signature workflow. If no one is going to reply with information about the platforms they use I am going to assume that they can (both client and server side) access all of the above.

Please reply back by 10/6.

EHL
--000e0cd59c96f3e5ab0474cd5f9e-- From owen@bgeek.net Wed Sep 30 12:22:47 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699613A69C8 for ; Wed, 30 Sep 2009 12:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BLWarKxJ09u for ; Wed, 30 Sep 2009 12:22:46 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id E802D3A69CD for ; Wed, 30 Sep 2009 12:22:45 -0700 (PDT) Received: by bwz6 with SMTP id 6so3072221bwz.37 for ; Wed, 30 Sep 2009 12:24:04 -0700 (PDT) Received: by 10.86.251.6 with SMTP id y6mr335884fgh.24.1254338644303; Wed, 30 Sep 2009 12:24:04 -0700 (PDT) Received: from ?172.19.105.191? (xerown1-rt1.fx.net.nz [131.203.100.45]) by mx.google.com with ESMTPS id e11sm15337fga.8.2009.09.30.12.23.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 30 Sep 2009 12:24:02 -0700 (PDT) Sender: Owen Evans Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Owen Evans In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784DF2054@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 1 Oct 2009 08:23:51 +1300 Content-Transfer-Encoding: 7bit Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF2054@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1076) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 19:24:02 -0000 .net provides access to all of the listed components. O On 30/09/2009, at 5:34 AM, Eran Hammer-Lahav wrote: > Reminder: > > Please help conduct the platform survey. Please answer this about > the platforms you use for developing HTTP applications. Does it > provide access to: > > * the raw HTTP request URI > * HTTP authentication headers (WWW-Authenticate, Authorize) > * the Host HTTP header > * the raw HTTP request entity-body > > If we have wide enough support (3 years later) for these items, we > can significantly simplify the signature workflow. If no one is > going to reply with information about the platforms they use I am > going to assume that they can (both client and server side) access > all of the above. > > Please reply back by 10/6. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf >> Of Eran Hammer-Lahav >> Sent: Monday, September 21, 2009 6:42 PM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Reevaluating Assumptions (Important!) >> >> OAuth has been designed over 2 years ago based on many assumptions >> that >> were true at that time. The most significant assumptions were: >> >> * HTTPS cannot be required due to deployment limitations >> * OAuth will be mostly used with proprietary APIs >> * Many web platforms do not provide access to the wire HTTP request >> URI >> (either on the client or server side) >> >> I strongly believe it would be a mistake to continue this work >> without >> questioning these assumptions and making sure we are not producing a >> lesser solution by trying to accommodate them. >> >> The first two assumptions are easy: >> >> * HTTPS cannot be required due to deployment limitations >> >> This still holds true. OAuth security cannot be based solely on using >> HTTPS due to deployment limitations. However, the protocol must >> easily >> support deployments that have HTTPS easily available and not make >> them >> waste resources will timestamps, nonces, and other security elements. >> While PLAINTEXT provides such support, it doesn't go far enough and >> still requires the presence of such parameters. >> >> * OAuth will be mostly used with proprietary APIs >> >> This has proved to be false. With new open APIs there is a greater >> need >> to enable clients to interact with a protected resource that it has >> not >> encountered before or one it has been coded explicitly for. What this >> means is that we need more discovery features built into the core >> protocol or more required portions to promote interoperability. There >> should be a minimum that any client facing an OAuth 404 should be >> able >> to handle. >> >> The third item: >> >> * Many web platforms do not provide access to the wire HTTP request >> URI >> (either on the client or server side) >> >> requires more research but it also holds the key to much of the >> protocol design, namely: >> >> - The canonicalization of the HTTP request parameter and URI - this >> was >> done due to the fact that at the time, many popular web platforms did >> not provide easy access to the raw HTTP request URI and headers. If >> this is no longer the case, OAuth can be significantly simplified to >> remove the need to process the parameters and only treat the request >> URI. >> >> - The inclusion of multiple parameter transmission methods - this was >> done due to lack of access to the Authorization header in some >> clients >> and server environment. If this is no longer a requirement or if we >> come to the conclusion that HTTP caching requires that we use the >> header in all requests, the need to support parameters in places >> other >> than the header will also go away. >> >> If we come to the conclusion that the last assumption is either >> incorrect or irrelevant (the requirement to use HTTP auth headers), >> we >> will be able to significantly simplify the protocol which will also >> accomplish improving interoperability and security. >> >> ACTION ITEM: >> >> We need to conduct a quick survey of web platforms to figure out if >> they provide access to the RAW HTTP request (client and server), >> and if >> they provide access to the HTTP auth headers (client and server). If >> you know, please reply with the information for the platforms you >> use. >> >> 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 James.H.Manger@team.telstra.com Wed Sep 30 12:43:47 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD65D3A6982 for ; Wed, 30 Sep 2009 12:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=-1.688, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsTHYXr-fbMU for ; Wed, 30 Sep 2009 12:43:41 -0700 (PDT) Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by core3.amsl.com (Postfix) with ESMTP id C2D393A699E for ; Wed, 30 Sep 2009 12:43:34 -0700 (PDT) Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipbi.vtcif.telstra.com.au with ESMTP; 01 Oct 2009 00:21:14 +1000 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 303771DA81 for ; Thu, 1 Oct 2009 00:21:14 +1000 (EST) Received: from WSMSG3704.srv.dir.telstra.com (wsmsg3704.in.telstra.com.au [172.49.40.197]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id AAA24299 for ; Thu, 1 Oct 2009 00:21:13 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 1 Oct 2009 00:21:13 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Thu, 1 Oct 2009 00:21:11 +1000 Thread-Topic: A token/secret alone is sufficient to authenticate a client as a delegate Thread-Index: AcpB2UK6aTngnhT4QwG3P3RqQuUVeg== Message-ID: <255B9BB34FB7D647A506DC292726F6E11231C36908@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [OAUTH-WG] A token/secret alone is sufficient to authenticate a client as a delegate X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 19:43:47 -0000 T0F1dGggYXV0aGVudGljYXRpb24gd291bGQgYmUgc2lnbmlmaWNhbnRseSBpbXByb3ZlZCBieSB1 c2luZyBhIHNpbmdsZSBpZC9zZWNyZXQsIGluc3RlYWQgb2YgYSBwYWlyIChjb25zdW1lcl9rZXkv c2VjcmV0IGFuZCB0b2tlbi9zZWNyZXQpLg0KDQpUaGlzIGRvZXMgbm90IHJlZHVjZSBhbnkgZnVu Y3Rpb25hbGl0eS4gVGhlIHNlcnZlciBoYXMgYXV0aGVudGljYXRlZCB0aGUgY2xpZW50IHdoZW4g aXQgaXNzdWVzIHRoZSBhY2Nlc3MgdG9rZW4gc28gaXQgY2FuIGluY29ycG9yYXRlIHRoZSBjbGll bnQgaWQgKGNvbnN1bWVyX2tleSkgaW50byB0aGUgdG9rZW4gaWYgaXQgd2FudHMuIFRoZSB0b2tl biBzZWNyZXQgaXMgb25seSByZXR1cm5lZCBpbiByZXNwb25zZSB0byBhIHJlcXVlc3QgYXV0aGVu dGljYXRlZCB3aXRoIHRoZSBjbGllbnQgc2VjcmV0LiBIZW5jZSwgc3Vic2VxdWVudGx5IGF1dGhl bnRpY2F0aW9uIHdpdGgganVzdCB0aGUgdG9rZW4gc2VjcmV0IGlzIHN0aWxsIGF1dGhlbnRpY2F0 aW5nIHRoZSBjbGllbnQuDQoNClRoZXJlIGFyZSBzb21lIHN1YnN0YW50aWFsIGFkdmFudGFnZXM6 DQoNCjEuIEF1dGhlbnRpY2F0ZWQgcmVxdWVzdHMgY2FuIGJlIG1hZGUgZnJvbSBsZXNzIHRydXN0 ZWQgZW52aXJvbm1lbnRzLCBhcyB0aGV5IG9ubHkgcmVxdWlyZSBhIHNlY3JldCBzcGVjaWZpYyB0 byBvbmUgZGVsZWdhdGlvbiAob25lIHVzZXIpIC0tIHRoZXkgZG8gbm90IHJlcXVpcmUgY29udGlu dWVkIGFjY2VzcyB0byB0aGUgY2xpZW50J3MgbG9uZyB0ZXJtIHNlY3JldC4NCkl0IHNob3VsZCBl dmVuIGJlIHBvc3NpYmxlIGZvciBhIGNsaWVudCB0byBiZSBwYXJ0bHkgaW1wbGVtZW50ZWQgb24g YSB3ZWIgc2l0ZSAod2hlcmUgdGhlIGNsaWVudCBzZWNyZXQgY2FuIGJlIHByb3RlY3RlZCkgYW5k IHBhcnRseSBpbiBqYXZhc2NyaXB0IGRlbGl2ZXJlZCB0byBhIHVzZXIncyBicm93c2VyLiBUaGF0 IGlzLCBkbyBPQXV0aCB3ZWIgZGVsZWdhdGlvbiBhdCB0aGUgY2xpZW50IHdlYiBzaXRlLCB0aGVu IHRoZSBjbGllbnQgY2FuIHVzZSB0aGF0IHVzZXIncyB0b2tlbiBzZWNyZXQgZnJvbSBqYXZhc2Ny aXB0IGluIHRoYXQgdXNlcidzIGJyb3dzZXIuIFRoZSBjbGllbnQgc2VjcmV0IGlzIG5ldmVyIGV4 cG9zZWQgdG8gYW55IHVzZXIncyBicm93c2VyLg0KDQoyLiBTcGVjaWFsIGNhc2VzIHRvIGhhbmRs ZSBzaXR1YXRpb25zIHdoZXJlIHRoZXJlIGlzIG5vIHRva2VuL3NlY3JldCBhcmUgZWxpbWluYXRl ZC4gVGhlc2UgY2FzZXMgdXNlIHRoZSBzaW5nbGUgY2xpZW50IGlkL3NlY3JldCB0aGF0IHRoZXkg aGF2ZS4gVGhpcyBjb3ZlcnMgdGhlIGluaXRpYWwgcmVxdWVzdCBmb3IgdGVtcG9yYXJ5IGNyZWRl bnRpYWxzLCBhbmQgYWxzbyAyLWxlZ2dlZCBzY2VuYXJpb3MuDQoNCjMuIFNwZWNpYWwgY2FzZXMg dG8gaGFuZGxlIHNpdHVhdGlvbnMgd2hlcmUgdGhlcmUgaXMgbm8gY2xpZW50IGlkL3NlY3JldCBh cmUgZWxpbWluYXRlZC4gRm9yIGNsaWVudHMgdGhhdCBjYW5ub3QgYmUgYXV0aGVudGljYXRlZCAo ZWcgZGVza3RvcCBjbGllbnRzKSwgT0F1dGggYXV0aGVudGljYXRpb24gd291bGQganVzdCB1c2Ug dGhlIHRva2VuL3NlY3JldCB3aXRob3V0IG5lZWRpbmcgdG8gZW5jb2RlIGJsYW5rIG9yIGR1bW15 IHZhbHVlcyBpbnRvIHRoZSBwcm90b2NvbC4NCg0KNC4gRml0cyBtdWNoIG1vcmUgZWFzaWx5IHdp dGggZXZlcnkgb3RoZXIgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtLCB3aGljaCBpbnZhcmlhYmxl IHVzZSBhIHNpbmdsZSBpZC9zZWNyZXQuDQoNCg0KQXMgYW4gYWRkZWQgYm9udXMgdGhpcyB3b3Vs ZCBhbGxvdyBPQXV0aCB0byBnZXQgcmlkIG9mIHRoZSBvYXV0aF9jb25zdW1lcl9rZXkgcGFyYW1l dGVyIHdpdGggaXRzIG9sZCAmIGF3a3dhcmQgdGVybWlub2xvZ3kgKCJjb25zdW1lciIgdnMgImNs aWVudCIsIGFuZCAia2V5IiB2cyAiaWQiKS4NCg0KDQpUaGUgc3BlYyBjaGFuZ2VzIGRvbid0IGxv b2sgaHVnZTogcmVtb3ZlIHRoZSBvYXV0aF9jb25zdW1lcl9rZXkgcGFyYW1ldGVyLCBzaW1wbGlm eSB0aGUgSE1BQyBrZXksIHNpbXBsaWZ5IHRoZSBQTEFJTlRFWFQgc2lnbmF0dXJlLCBhZGp1c3Qg dGhlIGV4YW1wbGVzLiBbSSB3aWxsIG9mZmVyIHRvIGhlbHAgbWFrZSB0aGUgdGV4dCBjaGFuZ2Vz IGlmIGl0IHdpbGwgaGVscF0NCg0KDQoNCkphbWVzIE1hbmdlcg0KSmFtZXMuSC5NYW5nZXJAdGVh bS50ZWxzdHJhLmNvbQ0KSWRlbnRpdHkgYW5kIHNlY3VyaXR5IHRlYW0g4oCUIENoaWVmIFRlY2hu b2xvZ3kgT2ZmaWNlIOKAlCBUZWxzdHJhDQo= From eran@hueniverse.com Wed Sep 30 12:48:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596083A686B for ; Wed, 30 Sep 2009 12:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.688 X-Spam-Level: X-Spam-Status: No, score=-3.688 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxxhbb+gH1UK for ; Wed, 30 Sep 2009 12:48:38 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7B3F13A6982 for ; Wed, 30 Sep 2009 12:48:38 -0700 (PDT) Received: (qmail 4075 invoked from network); 30 Sep 2009 19:50:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Sep 2009 19:50:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 30 Sep 2009 12:49:57 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "oauth@ietf.org" Date: Wed, 30 Sep 2009 12:50:09 -0700 Thread-Topic: [OAUTH-WG] A token/secret alone is sufficient to authenticate a client as a delegate Thread-Index: AcpB2UK6aTngnhT4QwG3P3RqQuUVegALcxZg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF235B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <255B9BB34FB7D647A506DC292726F6E11231C36908@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11231C36908@WSMSG3153V.srv.dir.telstra.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 Subject: Re: [OAUTH-WG] A token/secret alone is sufficient to authenticate a client as a delegate X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 19:48:39 -0000 VGhpcyBpcyBleGFjdGx5IHdoZXJlIEkgYW0gZ29pbmcgd2l0aCB0aGUgdXBjb21pbmcgZHJhZnQu IEl0IG1vdmVzIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgb3V0IG9mIHRoZSBhdXRoZW50aWNhdGlv biBwYXJ0IGFuZCBpbnRvIHRoZSBkZWxlZ2F0aW9uIHBhcnQuDQoNCkVITA0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgTWFuZ2VyLCBKYW1lcyBI DQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDMwLCAyMDA5IDc6MjEgQU0NCj4gVG86IG9h dXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IFtPQVVUSC1XR10gQSB0b2tlbi9zZWNyZXQgYWxvbmUg aXMgc3VmZmljaWVudCB0byBhdXRoZW50aWNhdGUNCj4gYSBjbGllbnQgYXMgYSBkZWxlZ2F0ZQ0K PiANCj4gT0F1dGggYXV0aGVudGljYXRpb24gd291bGQgYmUgc2lnbmlmaWNhbnRseSBpbXByb3Zl ZCBieSB1c2luZyBhIHNpbmdsZQ0KPiBpZC9zZWNyZXQsIGluc3RlYWQgb2YgYSBwYWlyIChjb25z dW1lcl9rZXkvc2VjcmV0IGFuZCB0b2tlbi9zZWNyZXQpLg0KPiANCj4gVGhpcyBkb2VzIG5vdCBy ZWR1Y2UgYW55IGZ1bmN0aW9uYWxpdHkuIFRoZSBzZXJ2ZXIgaGFzIGF1dGhlbnRpY2F0ZWQNCj4g dGhlIGNsaWVudCB3aGVuIGl0IGlzc3VlcyB0aGUgYWNjZXNzIHRva2VuIHNvIGl0IGNhbiBpbmNv cnBvcmF0ZSB0aGUNCj4gY2xpZW50IGlkIChjb25zdW1lcl9rZXkpIGludG8gdGhlIHRva2VuIGlm IGl0IHdhbnRzLiBUaGUgdG9rZW4gc2VjcmV0DQo+IGlzIG9ubHkgcmV0dXJuZWQgaW4gcmVzcG9u c2UgdG8gYSByZXF1ZXN0IGF1dGhlbnRpY2F0ZWQgd2l0aCB0aGUgY2xpZW50DQo+IHNlY3JldC4g SGVuY2UsIHN1YnNlcXVlbnRseSBhdXRoZW50aWNhdGlvbiB3aXRoIGp1c3QgdGhlIHRva2VuIHNl Y3JldA0KPiBpcyBzdGlsbCBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50Lg0KPiANCj4gVGhlcmUg YXJlIHNvbWUgc3Vic3RhbnRpYWwgYWR2YW50YWdlczoNCj4gDQo+IDEuIEF1dGhlbnRpY2F0ZWQg cmVxdWVzdHMgY2FuIGJlIG1hZGUgZnJvbSBsZXNzIHRydXN0ZWQgZW52aXJvbm1lbnRzLA0KPiBh cyB0aGV5IG9ubHkgcmVxdWlyZSBhIHNlY3JldCBzcGVjaWZpYyB0byBvbmUgZGVsZWdhdGlvbiAo b25lIHVzZXIpIC0tDQo+IHRoZXkgZG8gbm90IHJlcXVpcmUgY29udGludWVkIGFjY2VzcyB0byB0 aGUgY2xpZW50J3MgbG9uZyB0ZXJtIHNlY3JldC4NCj4gSXQgc2hvdWxkIGV2ZW4gYmUgcG9zc2li bGUgZm9yIGEgY2xpZW50IHRvIGJlIHBhcnRseSBpbXBsZW1lbnRlZCBvbiBhDQo+IHdlYiBzaXRl ICh3aGVyZSB0aGUgY2xpZW50IHNlY3JldCBjYW4gYmUgcHJvdGVjdGVkKSBhbmQgcGFydGx5IGlu DQo+IGphdmFzY3JpcHQgZGVsaXZlcmVkIHRvIGEgdXNlcidzIGJyb3dzZXIuIFRoYXQgaXMsIGRv IE9BdXRoIHdlYg0KPiBkZWxlZ2F0aW9uIGF0IHRoZSBjbGllbnQgd2ViIHNpdGUsIHRoZW4gdGhl IGNsaWVudCBjYW4gdXNlIHRoYXQgdXNlcidzDQo+IHRva2VuIHNlY3JldCBmcm9tIGphdmFzY3Jp cHQgaW4gdGhhdCB1c2VyJ3MgYnJvd3Nlci4gVGhlIGNsaWVudCBzZWNyZXQNCj4gaXMgbmV2ZXIg ZXhwb3NlZCB0byBhbnkgdXNlcidzIGJyb3dzZXIuDQo+IA0KPiAyLiBTcGVjaWFsIGNhc2VzIHRv IGhhbmRsZSBzaXR1YXRpb25zIHdoZXJlIHRoZXJlIGlzIG5vIHRva2VuL3NlY3JldA0KPiBhcmUg ZWxpbWluYXRlZC4gVGhlc2UgY2FzZXMgdXNlIHRoZSBzaW5nbGUgY2xpZW50IGlkL3NlY3JldCB0 aGF0IHRoZXkNCj4gaGF2ZS4gVGhpcyBjb3ZlcnMgdGhlIGluaXRpYWwgcmVxdWVzdCBmb3IgdGVt cG9yYXJ5IGNyZWRlbnRpYWxzLCBhbmQNCj4gYWxzbyAyLWxlZ2dlZCBzY2VuYXJpb3MuDQo+IA0K PiAzLiBTcGVjaWFsIGNhc2VzIHRvIGhhbmRsZSBzaXR1YXRpb25zIHdoZXJlIHRoZXJlIGlzIG5v IGNsaWVudA0KPiBpZC9zZWNyZXQgYXJlIGVsaW1pbmF0ZWQuIEZvciBjbGllbnRzIHRoYXQgY2Fu bm90IGJlIGF1dGhlbnRpY2F0ZWQgKGVnDQo+IGRlc2t0b3AgY2xpZW50cyksIE9BdXRoIGF1dGhl bnRpY2F0aW9uIHdvdWxkIGp1c3QgdXNlIHRoZSB0b2tlbi9zZWNyZXQNCj4gd2l0aG91dCBuZWVk aW5nIHRvIGVuY29kZSBibGFuayBvciBkdW1teSB2YWx1ZXMgaW50byB0aGUgcHJvdG9jb2wuDQo+ IA0KPiA0LiBGaXRzIG11Y2ggbW9yZSBlYXNpbHkgd2l0aCBldmVyeSBvdGhlciBhdXRoZW50aWNh dGlvbiBtZWNoYW5pc20sDQo+IHdoaWNoIGludmFyaWFibGUgdXNlIGEgc2luZ2xlIGlkL3NlY3Jl dC4NCj4gDQo+IA0KPiBBcyBhbiBhZGRlZCBib251cyB0aGlzIHdvdWxkIGFsbG93IE9BdXRoIHRv IGdldCByaWQgb2YgdGhlDQo+IG9hdXRoX2NvbnN1bWVyX2tleSBwYXJhbWV0ZXIgd2l0aCBpdHMg b2xkICYgYXdrd2FyZCB0ZXJtaW5vbG9neQ0KPiAoImNvbnN1bWVyIiB2cyAiY2xpZW50IiwgYW5k ICJrZXkiIHZzICJpZCIpLg0KPiANCj4gDQo+IFRoZSBzcGVjIGNoYW5nZXMgZG9uJ3QgbG9vayBo dWdlOiByZW1vdmUgdGhlIG9hdXRoX2NvbnN1bWVyX2tleQ0KPiBwYXJhbWV0ZXIsIHNpbXBsaWZ5 IHRoZSBITUFDIGtleSwgc2ltcGxpZnkgdGhlIFBMQUlOVEVYVCBzaWduYXR1cmUsDQo+IGFkanVz dCB0aGUgZXhhbXBsZXMuIFtJIHdpbGwgb2ZmZXIgdG8gaGVscCBtYWtlIHRoZSB0ZXh0IGNoYW5n ZXMgaWYgaXQNCj4gd2lsbCBoZWxwXQ0KPiANCj4gDQo+IA0KPiBKYW1lcyBNYW5nZXINCj4gSmFt ZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbQ0KPiBJZGVudGl0eSBhbmQgc2VjdXJpdHkgdGVh bSDigJQgQ2hpZWYgVGVjaG5vbG9neSBPZmZpY2Ug4oCUIFRlbHN0cmENCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0 DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCg== From eran@hueniverse.com Wed Sep 30 13:16:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108C528C0EF for ; Wed, 30 Sep 2009 13:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.671 X-Spam-Level: X-Spam-Status: No, score=-3.671 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-w5gJhU2XoU for ; Wed, 30 Sep 2009 13:16:10 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3CFE43A69B6 for ; Wed, 30 Sep 2009 13:16:10 -0700 (PDT) Received: (qmail 2497 invoked from network); 30 Sep 2009 20:17:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Sep 2009 20:17:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 30 Sep 2009 13:15:04 -0700 From: Eran Hammer-Lahav To: Blaine Cook Date: Wed, 30 Sep 2009 13:17:41 -0700 Thread-Topic: [OAUTH-WG] Reevaluating Assumptions (Important!) Thread-Index: AcpB37YRnxXfPIk4QaKlRoGRbJjGbQAKO+5g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784DF2369@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343784D584F7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343784DF21C0@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] Reevaluating Assumptions (Important!) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 20:16:11 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCbGFpbmUgQ29vayBbbWFpbHRv OnJvbWVkYUBnbWFpbC5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDMwLCAyMDA5 IDg6MDcgQU0NCg0KPiBJJ20gbm90IHN1cmUgd2hhdCB0aGUgcmlnaHQgYXBwcm9hY2ggaXMgaGVy ZSwgYnV0IEkgZG8ga25vdyB0aGF0IHdoaWxlDQo+IGZpZ3VyaW5nIG91dCB0aGUgU2lnbmF0dXJl IEJhc2UgU3RyaW5nIGlzIGRpZmZpY3VsdCwgaXQncyAqbXVjaCoNCj4gZWFzaWVyIChhbmQgc2Fm ZXIpIHRoYW4gaGFja2luZyB0aGUgaW50ZXJuYWxzIG9mIHlvdXIgW2xlYXN0XQ0KPiBmYXZvdXJp dGUgSFRUUCBjbGllbnQuDQoNCkl0IG1hZGUgcGVyZmVjdCBzZW5zZSB0byBjb21lIHVwIHdpdGgg YWxsIHRoZSBkaWZmZXJlbnQgb3B0aW9ucyBpbiB0aGUgMS4wIHNwZWMgdG8gZW5hYmxlIHF1aWNr IGFkb3B0aW9uLiBOb3QgbmVlZGluZyBuYXRpdmUgc3VwcG9ydCBmcm9tIG1ham9yIHBsYXRmb3Jt IHdhcyBvbmUgb2YgdGhlIG1haW4gcmVhc29ucyBPQXV0aCBnb3QgYWRvcHRlZCBxdWlja2x5LiBI b3dldmVyLCBub3cgdGhhdCB3ZSBhcmUgbG9va2luZyBhdCBjcmVhdGluZyBhbiBpbnRlcm5ldCBz dGFuZGFyZCB3aXRoIHRoZSBhdHRlbnRpb24gb2YgdGhlIGVudGlyZSB3ZWIgY29tbXVuaXR5LCBh bmQgYSBzdWNjZXNzZnVsIG1vbWVudHVtLCBJIHRoaW5rIHdlIGNhbiBzd2l0Y2ggdGhlIGJ1cmRl biB0byB0aGUgcGxhdGZvcm1zIHRvIHByb3ZpZGUgbmF0aXZlIHN1cHBvcnQgZm9yIE9BdXRoLg0K DQpUbyBtYWtlIHRoaXMgd29yaywgd2UgbmVlZCB0byBjbGVhcmx5IHNlcGFyYXRlIHRoZSBhcHBs aWNhdGlvbi1sYXllciBwYXJ0cyBvZiB0aGUgcHJvdG9jb2wgZnJvbSB0aGUgdHJhbnNwb3J0LWxh eWVyIHBhcnRzLiBXZSBhbHJlYWR5IHN0YXJ0ZWQgZG9pbmcgdGhpcyB3aXRoIHRoZSB0d28gc3Bl Y3MsIGJ1dCB3ZSBuZWVkIHRvIHRha2UgaXQgZnVydGhlci4gVGhlIGF1dGhlbnRpY2F0aW9uIHNw ZWMgc2hvdWxkIG5vdCBpbmNsdWRlIGFueSBhcHBsaWNhdGlvbi1sYXllciBkZXBlbmRlbmNpZXMg YW5kIG9wZXJhdGUgYXQgdGhlIHNhbWUgbGV2ZWwgYXMgSFRUUCBCYXNpYyBhbmQgRGlnZXN0IGF1 dGgsIGJvdGggb2Ygd2hpY2ggYXJlIHN1cHBvcnRlZCBieSBwcmV0dHkgbXVjaCBhbnkgd2ViIHBs YXRmb3JtIGluIHRoZWlyIG5hdGl2ZSBIVFRQIGNsaWVudHMuIEFwcGxpY2F0aW9ucyBzaG91bGQg YmUgYWJsZSB0byBtYWtlIGEgc2ltcGxlIEhUVFAgcmVxdWVzdCBhbmQgcHJvdmlkZSB0aGVpciB0 b2tlbiBjcmVkZW50aWFscyBqdXN0IGxpa2UgYSB1c2VybmFtZSBhbmQgcGFzc3dvcmQuDQoNCkFz IGZvciBob3cgdGhleSBvYnRhaW4gYSB0b2tlbiAtIHRoaXMgaXMgd2hlcmUgdGhlIGFwcGxpY2F0 aW9uLWxheWVyIGxvZ2ljIHNob3VsZCBiZSwgYW5kIGluY2x1ZGUgdGhlIHVzZSBvZiBjbGllbnQg Y3JlZGVudGlhbHMsIGV4Y2hhbmdpbmcgdXNlcm5hbWVzIGZvciB0b2tlbnMsIG1hbmFnaW5nIHRv a2VuIHN0YXRlLCBzZXNzaW9ucywgZXRjLg0KDQpJIGFtIHB1Ymxpc2hpbmcgT0F1dGggMS4wIGFz IGFuIChpbmZvcm1hdGlvbmFsKSBSRkMgc28gdGhhdCB3ZSBoYXZlIGEgZG9jdW1lbnRlZCBwYXR0 ZXJuIGZvciBjYXNlcyB3aGVyZSBwbGF0Zm9ybSBsaW1pdGF0aW9ucyBwcmV2ZW50IGFkb3B0aW9u LiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gd29ycnkgYWJvdXQgdGhlc2UgbGltaXRhdGlvbnMg cmlnaHQgbm93IGFuZCB3b3JrIHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCB0aGlzIHdvcmsgd2ls bCBwcm9kdWNlIG5hdGl2ZSBzdXBwb3J0LiBXaGF0IHdlIE1VU1Qgd29ycnkgYWJvdXQsIGlzIHRo YXQgdGhlIGFyY2hpdGVjdHVyZSBvZiB0aGlzIHByb3RvY29sIGlzIGNvbXBhdGlibGUgd2l0aCBu YXRpdmUgc3VwcG9ydCBpbiB0aGUgdmFyaW91cyBsYXllcnMgd2UgZXhwZWN0IGl0IHRvIGJlIGFk ZGVkIGluLg0KDQpFSEwNCg== From James.H.Manger@team.telstra.com Wed Sep 30 23:59:44 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE3A3A685E for ; Wed, 30 Sep 2009 23:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-1.293, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbpqkuXW1UeY for ; Wed, 30 Sep 2009 23:59:43 -0700 (PDT) Received: from mailipao.ntcif.telstra.com.au (mailipao.ntcif.telstra.com.au [202.12.233.27]) by core3.amsl.com (Postfix) with ESMTP id 9C9D728C0D7 for ; Wed, 30 Sep 2009 23:59:42 -0700 (PDT) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipai.ntcif.telstra.com.au with ESMTP; 01 Oct 2009 17:01:04 +1000 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 94EBEFF84 for ; Thu, 1 Oct 2009 17:01:03 +1000 (EST) Received: from WSMSG3754.srv.dir.telstra.com (wsmsg3754.in.telstra.com.au [172.49.40.198]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 4845041E23 for ; Thu, 1 Oct 2009 17:00:48 +1000 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Thu, 1 Oct 2009 17:01:02 +1000 From: "Manger, James H" To: "oauth@ietf.org" Date: Thu, 1 Oct 2009 17:01:00 +1000 Thread-Topic: simplifying escaping Thread-Index: AcpCZO8H3Y+kZ8hMTWSTOwKCWoIuMw== Message-ID: <255B9BB34FB7D647A506DC292726F6E11231C3778A@WSMSG3153V.srv.dir.telstra.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_255B9BB34FB7D647A506DC292726F6E11231C3778AWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] simplifying escaping X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 06:59:44 -0000 --_000_255B9BB34FB7D647A506DC292726F6E11231C3778AWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXNjYXBpbmcgKG9yIGVuY29kaW5nKSBoYXMgc2VlbWVkIHRvIGJlIGEgYmlnIGhlYWRhY2hlIGZv ciBPQXV0aCBpbXBsZW1lbnRhdGlvbnMuDQoNCkkgYW0gYSBsaXR0bGUgcmVsdWN0YW50IHRvIGJy aW5nIGl0IHVwIGFnYWluIGFzIHRoZSB0ZXh0IGFuZCBleGFtcGxlcyBpbiB0aGUgc3BlYyBoYXZl IGdvdCBjbGVhcmVyLg0KDQpIb3dldmVyLCB0aGVyZSBpcyByb29tIHRvIG1ha2UgaXQgY29uc2lk ZXJhYmx5IHNpbXBsZXIuDQoNCg0KDQpWYXJpb3VzIHJlcXVlc3QgZmllbGRzIGFyZSBjb21iaW5l ZCBpbnRvIG9uZSBzdHJpbmcgdGhhdCBpcyBzaWduZWQ6IG1ldGhvZCwgdXJpLCBwYXJhbWV0ZXJz Lg0KDQpDdXJyZW50bHkg4oCYJuKAmSBjaGFyYWN0ZXJzIGFyZSB1c2VkIHRvIHNlcGFyYXRlIHRo ZXNlIGZpZWxkcy4gSG93ZXZlciwgZXNjYXBpbmcgaXMgcmVxdWlyZWQgc2luY2Ug4oCYJuKAmSBp cyBhbGxvd2VkIGluIHRoZSBjb250ZW50IG9mIHNvbWUgb2YgdGhlIGZpZWxkcyAoYW5kIGlzIHVz ZWQgYXMgYSBzZXBhcmF0b3Igd2l0aGluIHNvbWUgZmllbGRzKS4NCg0KDQoNCkJ5IGNob29zaW5n IGEgZGlmZmVyZW50IHNlcGFyYXRvciAtLSBzdWNoIGFzIG5ld2xpbmUgKFUrMDAwQSkgLS0gdGhh dCBpcyBub3QgYWxsb3dlZCBpbiB0aGUgaW5kaXZpZHVhbCBmaWVsZHMsIGEgd2hvbGUgbGF5ZXIg b2YgZXNjYXBpbmcgY2FuIGJlIGVsaW1pbmF0ZWQuIEFzIGEgYm9udXMsIHRoZSBzdHJpbmcgdG8g YmUgc2lnbmVkIGlzIGVhc2llciB0byByZWFkIGR1cmluZyBkZWJ1Z2dpbmcgYW5kIGluIHNwZWMg ZXhhbXBsZXMuDQoNCg0KDQpBbWF6b24gV2ViIFNlcnZpY2VzIChBV1MpIHN1cHBvcnQgSFRUUCBy ZXF1ZXN0IHNpZ25pbmcgd2l0aCBITUFDIGluIGEgdmVyeSBzaW1pbGFyIHdheSB0byBPQXV0aC4g SXQgdXNlcyBuZXdsaW5lIChVKzAwMEEpIHRvIHNlcGFyYXRlIGZpZWxkcy4gSXQgZG9lcyBub3Qg bmVlZCB0byBlc2NhcGUgdGhlIEhUVFAgbWV0aG9kLCBVUkksIG9yIHF1ZXJ5IHN0cmluZyBhcyBP QXV0aCBkb2VzLg0KDQpBV1MgUzM6IGh0dHA6Ly9kb2NzLmFtYXpvbndlYnNlcnZpY2VzLmNvbS9B bWF6b25TMy9sYXRlc3QvZGV2L1JFU1RBdXRoZW50aWNhdGlvbi5odG1sDQoNCkFXUyBFQzI6IGh0 dHA6Ly9kb2NzLmFtYXpvbndlYnNlcnZpY2VzLmNvbS9BV1NFQzIvbGF0ZXN0L0RldmVsb3Blckd1 aWRlL3VzaW5nLXF1ZXJ5LWFwaS5odG1sDQoNCg0KDQpQZXJoYXBzIE9BdXRoIGNvdWxkIHN3aXRj aCBmcm9tOg0KDQogZXNjKG1ldGhvZCkgJiBlc2ModXJpKSAmIGVzYyhlc2MobmFtZTEpPWVzYyh2 YWx1ZTEpICYgZXNjKG5hbWUyKT1lc2ModmFsdWUyKeKApikNCg0KdG8NCg0KIG1ldGhvZCBcbg0K DQogdXJpIFxuDQoNCiBlc2MobmFtZTEpPWVzYyh2YWx1ZTEpICYgZXNjKG5hbWUyKT1lc2ModmFs dWUyKeKApg0KDQoNCg0KDQoNClNvcnRpbmcgb2YgcGFyYW1ldGVycyBpcyBkb25lIGF0IGEgc2xp Z2h0bHkgYXdrd2FyZCBzdGFnZTogYWZ0ZXIgZXNjYXBpbmcgbmFtZXMgYW5kIHZhbHVlcywgYnV0 IGJlZm9yZSBjb21iaW5pbmcgdGhlbSBpbnRvIGEgbmFtZT12YWx1ZSBzdHJpbmcuIFRoaXMgbWVh bnMgeW91IGNhbm5vdCBzb3J0IHRoZSBtYXAgb2YgbmFtZS92YWx1ZSBwYWlycyB0aGF0IHRoZSBo aWdoZXIgbGF5ZXJzIG9mIHRoZSBjbGllbnQgd2lsbCBiZSB1c2luZyAoYXMgbm8gZXNjYXBpbmcg aGFzIGJlZW4gYXBwbGllZCkuIFlvdSBjYW7igJl0IHNpbXBseSBzb3J0IGEgbGlzdCBvZiBzdHJp bmdzIChhcyB0aGVyZSBhcmUgdHdvIHBhcnRzOiB0aGUgbmFtZSBpcyB0aGUgcHJpbWFyeSBrZXks IHRoZSB2YWx1ZSBpcyBhIHNlY29uZGFyeSBrZXkpLiBTb21lIE9BdXRoIGxpYnJhcmllcyB1c2Ug dHJpY2tzIGxpa2UgYnVpbGRpbmcg4oCcZXNjKG5hbWUpIGVzYyh2YWx1ZSnigJ0gZm9yIGVhY2gg cGFyYW1ldGVyICh3aXRoIGEgc3BhY2UgYmV0d2VlbiB0aGUgZXNjYXBlZCBwYXJ0cykgdGhhdCBj YW4gYmUgc29ydGVkIGFzIGEgc3RyaW5nIChzcGFjZSBVKzAwMjAgc29ydHMgYmVmb3JlIGFueSBw b3NzaWJsZSBlc2NhcGVkIGNoYXJhY3RlcikgLS0gdGhlbiB0aGUgbGlicmFyeSBuZWVkcyB0byBy ZWJ1aWxkIHRoZSBzdHJpbmdzIHdpdGgg4oCcPeKAnSBpbnN0ZWFkIG9mIHNwYWNlIHRvIGRvIHRo ZSByZXN0IG9mIHRoZSBjYWxjdWxhdGlvbi4NCg0KSSB3b3VsZCBzd2FwIHRoZSBvcmRlciBvZiBz dGVwcyAyICYgMyBpbiA2LjEuMi4g4oCcTm9ybWFsaXplIFJlcXVlc3QgUGFyYW1ldGVyc+KAnS4N Cg0KDQoNCg0KDQpPQXV0aCBjb3VsZCByZXF1aXJlIHNlcnZlcnMgdG8gb25seSBpc3N1ZSB0b2tl bnMgYW5kIHNlY3JldHMgdGhhdCB1c2UgdW5yZXNlcnZlZCBjaGFyYWN0ZXJzOiBBLVogYS16IDAt OSAtIC4gXyB+Lg0KDQpUaGF0IGVsaW1pbmF0ZXMgYSBmZXcgbW9yZSBwbGFjZXMgd2hlcmUgZXNj YXBpbmcgY2FuIGNhdXNlIGludGVyb3AgaGFzc2xlcy4NCg0KDQoNCkEgc2VydmVyIGNvdWxkIHVz ZSDigJxiYXNlNjQgd2l0aCBVUkwgYW5kIGZpbGVuYW1lIHNhZmUgYWxwaGFiZXTigJ0gKGFuZCBv bWl0dGluZyB0aGUgdW5uZWNlc3NhcnkgdHJhaWxpbmcg4oCcPeKAnSkgaWYgaXQgbmVlZHMgdG8g cmVwcmVzZW50IGFyYml0cmFyeSBieXRlcyBpbiBhIHRva2VuIG9yIHNlY3JldC4gVGhpcyB3b3Vs ZCBiZSBhbiBpbnRlcm5hbCBtYXR0ZXIgZm9yIHRoZSBzZXJ2aWNlLiBJdCBpcyBzcGVjaWZpZWQg aW4gUkZDIDM1NDgg4oCcVGhlIGJhc2UxNiwgQmFzZTMyLCBhbmQgQmFzZTY0IERhdGEgRW5jb2Rp bmdz4oCdICh3aGljaCBpcyBhIGJldHRlciByZWZlcmVuY2UgZm9yIGV2ZW4gbm9ybWFsIGJhc2U2 NCB0aGFuIFJGQyAyMDQ1KS4gVGhlIHNhZmUgYWxwaGFiZXQganVzdCBzdWJzdGl0dXRlcyDigJwt 4oCcIGFuZCDigJxf4oCdIGZvciDigJwr4oCdIGFuZCDigJwv4oCdLg0KDQpPQXV0aCBjb3VsZCB1 c2UgdGhpcyBtb2RpZmllZCBiYXNlNjQgZm9yIG9hdXRoX3NpZ25hdHVyZSAtLSB0aG91Z2ggSSBh bSBub3Qgc3VyZSBpZiB0aGF0IHdvdWxkIGJlDQoNCg0KDQpFc2NhcGluZyB2YWx1ZXMgYmVmb3Jl IHB1dHRpbmcgdGhlbSBpbiB0aGUgQXV0aG9yaXphdGlvbiBIVFRQIGhlYWRlciBjYW4gYmUgZWxp bWluYXRlZC4gSXQgaXMgYSBiaXQgc3RyYW5nZSBhdCB0aGUgbW9tZW50IHRoYXQgYSBVUkktZXNj YXBpbmcgbWVjaGFuaXNtICglLWVzY2FwaW5nKSBpcyB1c2VkIGluIGFuIEhUVFAgaGVhZGVyIHF1 b3RlZC1zdHJpbmcsIHdoaWNoIGhhcyBhIHNlcGFyYXRlIGVzY2FwaW5nIG1lY2hhbmlzbS4NCg0K DQoNCg0KDQpUaGVzZSBjaGFuZ2VzIGJyZWFrIGJhY2t3YXJkLWNvbXBhdGliaWxpdHkgd2l0aCBP QXV0aCAxLjAgLS0gYnV0IEkgYW0gZmFpcmx5IGNlcnRhaW4gdGhhdCB3YXMgYnJva2VuIGFueXdh eSAoZWcgaWYgd2UgZWxpbWluYXRlIFNIQS0xKS4NCg0KDQoNCkphbWVzIE1hbmdlcg0KSmFtZXMu SC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxz dHJhLmNvbT4NCklkZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtIOKAlCBDaGllZiBUZWNobm9sb2d5 IE9mZmljZSDigJQgVGVsc3RyYQ0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E11231C3778AWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVzY2FwaW5nIChvciBl bmNvZGluZykgaGFzIHNlZW1lZCB0byBiZSBhIGJpZyBoZWFkYWNoZSBmb3IgT0F1dGggaW1wbGVt ZW50YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBhIGxp dHRsZSByZWx1Y3RhbnQgdG8gYnJpbmcgaXQgdXAgYWdhaW4gYXMgdGhlIHRleHQgYW5kIGV4YW1w bGVzIGluIHRoZSBzcGVjIGhhdmUgZ290IGNsZWFyZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Ib3dldmVyLCB0aGVyZSBpcyByb29tIHRvIG1ha2UgaXQgY29uc2lkZXJh Ymx5IHNpbXBsZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlZhcmlvdXMgcmVxdWVzdCBmaWVs ZHMgYXJlIGNvbWJpbmVkIGludG8gb25lIHN0cmluZyB0aGF0IGlzIHNpZ25lZDogbWV0aG9kLCB1 cmksIHBhcmFtZXRlcnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DdXJy ZW50bHkg4oCYJmFtcDvigJkgY2hhcmFjdGVycyBhcmUgdXNlZCB0byBzZXBhcmF0ZSB0aGVzZSBm aWVsZHMuIEhvd2V2ZXIsIGVzY2FwaW5nIGlzIHJlcXVpcmVkIHNpbmNlIOKAmCZhbXA74oCZIGlz IGFsbG93ZWQgaW4gdGhlIGNvbnRlbnQgb2Ygc29tZSBvZiB0aGUgZmllbGRzIChhbmQgaXMgdXNl ZCBhcyBhIHNlcGFyYXRvciB3aXRoaW4gc29tZSBmaWVsZHMpLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CeSBjaG9vc2luZyBhIGRpZmZlcmVudCBzZXBhcmF0b3IgLS0gc3VjaCBhcyBuZXdsaW5l IChVJiM0MzswMDBBKSAtLSB0aGF0IGlzIG5vdCBhbGxvd2VkIGluIHRoZSBpbmRpdmlkdWFsIGZp ZWxkcywgYSB3aG9sZSBsYXllciBvZiBlc2NhcGluZyBjYW4gYmUgZWxpbWluYXRlZC4gQXMgYSBi b251cywgdGhlIHN0cmluZyB0byBiZSBzaWduZWQgaXMgZWFzaWVyIHRvIHJlYWQgZHVyaW5nIGRl YnVnZ2luZyBhbmQgaW4gc3BlYw0KIGV4YW1wbGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bWF6b24gV2ViIFNlcnZpY2VzIChBV1MpIHN1cHBvcnQgSFRUUCByZXF1ZXN0IHNpZ25pbmcgd2l0 aCBITUFDIGluIGEgdmVyeSBzaW1pbGFyIHdheSB0byBPQXV0aC4gSXQgdXNlcyBuZXdsaW5lIChV JiM0MzswMDBBKSB0byBzZXBhcmF0ZSBmaWVsZHMuIEl0IGRvZXMgbm90IG5lZWQgdG8gZXNjYXBl IHRoZSBIVFRQIG1ldGhvZCwgVVJJLCBvciBxdWVyeSBzdHJpbmcgYXMgT0F1dGggZG9lcy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFXUyBTMzogPGEgaHJlZj0iaHR0cDov L2RvY3MuYW1hem9ud2Vic2VydmljZXMuY29tL0FtYXpvblMzL2xhdGVzdC9kZXYvUkVTVEF1dGhl bnRpY2F0aW9uLmh0bWwiPg0KaHR0cDovL2RvY3MuYW1hem9ud2Vic2VydmljZXMuY29tL0FtYXpv blMzL2xhdGVzdC9kZXYvUkVTVEF1dGhlbnRpY2F0aW9uLmh0bWw8L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BV1MgRUMyOiA8YSBocmVmPSJodHRwOi8vZG9jcy5hbWF6 b253ZWJzZXJ2aWNlcy5jb20vQVdTRUMyL2xhdGVzdC9EZXZlbG9wZXJHdWlkZS91c2luZy1xdWVy eS1hcGkuaHRtbCI+DQpodHRwOi8vZG9jcy5hbWF6b253ZWJzZXJ2aWNlcy5jb20vQVdTRUMyL2xh dGVzdC9EZXZlbG9wZXJHdWlkZS91c2luZy1xdWVyeS1hcGkuaHRtbDwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UGVyaGFwcyBPQXV0aCBjb3VsZCBzd2l0Y2ggZnJvbTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO2VzYyhtZXRob2QpICZhbXA7IGVzYyh1cmkp ICZhbXA7IGVzYyhlc2MobmFtZTEpPWVzYyh2YWx1ZTEpICZhbXA7IGVzYyhuYW1lMik9ZXNjKHZh bHVlMinigKYpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50bzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7bWV0aG9kIFxuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDt1cmkgXG48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO2VzYyhuYW1lMSk9ZXNjKHZhbHVlMSkgJmFtcDsgZXNj KG5hbWUyKT1lc2ModmFsdWUyKeKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvcnRpbmcgb2YgcGFyYW1ldGVycyBp cyBkb25lIGF0IGEgc2xpZ2h0bHkgYXdrd2FyZCBzdGFnZTogYWZ0ZXIgZXNjYXBpbmcgbmFtZXMg YW5kIHZhbHVlcywgYnV0IGJlZm9yZSBjb21iaW5pbmcgdGhlbSBpbnRvIGEgbmFtZT12YWx1ZSBz dHJpbmcuIFRoaXMgbWVhbnMgeW91IGNhbm5vdCBzb3J0IHRoZSBtYXAgb2YgbmFtZS92YWx1ZSBw YWlycyB0aGF0IHRoZSBoaWdoZXIgbGF5ZXJzIG9mIHRoZSBjbGllbnQNCiB3aWxsIGJlIHVzaW5n IChhcyBubyBlc2NhcGluZyBoYXMgYmVlbiBhcHBsaWVkKS4gWW91IGNhbuKAmXQgc2ltcGx5IHNv cnQgYSBsaXN0IG9mIHN0cmluZ3MgKGFzIHRoZXJlIGFyZSB0d28gcGFydHM6IHRoZSBuYW1lIGlz IHRoZSBwcmltYXJ5IGtleSwgdGhlIHZhbHVlIGlzIGEgc2Vjb25kYXJ5IGtleSkuIFNvbWUgT0F1 dGggbGlicmFyaWVzIHVzZSB0cmlja3MgbGlrZSBidWlsZGluZyDigJxlc2MobmFtZSkgZXNjKHZh bHVlKeKAnSBmb3IgZWFjaCBwYXJhbWV0ZXINCiAod2l0aCBhIHNwYWNlIGJldHdlZW4gdGhlIGVz Y2FwZWQgcGFydHMpIHRoYXQgY2FuIGJlIHNvcnRlZCBhcyBhIHN0cmluZyAoc3BhY2UgVSYjNDM7 MDAyMCBzb3J0cyBiZWZvcmUgYW55IHBvc3NpYmxlIGVzY2FwZWQgY2hhcmFjdGVyKSAtLSB0aGVu IHRoZSBsaWJyYXJ5IG5lZWRzIHRvIHJlYnVpbGQgdGhlIHN0cmluZ3Mgd2l0aCDigJw94oCdIGlu c3RlYWQgb2Ygc3BhY2UgdG8gZG8gdGhlIHJlc3Qgb2YgdGhlIGNhbGN1bGF0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBzd2FwIHRoZSBvcmRlciBvZiBz dGVwcyAyICZhbXA7IDMgaW4gNi4xLjIuIOKAnE5vcm1hbGl6ZSBSZXF1ZXN0IFBhcmFtZXRlcnPi gJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T0F1dGggY291bGQgcmVxdWlyZSBzZXJ2ZXJzIHRvIG9ubHkgaXNzdWUg dG9rZW5zIGFuZCBzZWNyZXRzIHRoYXQgdXNlIHVucmVzZXJ2ZWQgY2hhcmFjdGVyczogQS1aIGEt eiAwLTkgLSAuIF8gfi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQg ZWxpbWluYXRlcyBhIGZldyBtb3JlIHBsYWNlcyB3aGVyZSBlc2NhcGluZyBjYW4gY2F1c2UgaW50 ZXJvcCBoYXNzbGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHNlcnZlciBjb3VsZCB1c2Ug 4oCcYmFzZTY0IHdpdGggVVJMIGFuZCBmaWxlbmFtZSBzYWZlIGFscGhhYmV04oCdIChhbmQgb21p dHRpbmcgdGhlIHVubmVjZXNzYXJ5IHRyYWlsaW5nIOKAnD3igJ0pIGlmIGl0IG5lZWRzIHRvIHJl cHJlc2VudCBhcmJpdHJhcnkgYnl0ZXMgaW4gYSB0b2tlbiBvciBzZWNyZXQuIFRoaXMgd291bGQg YmUgYW4gaW50ZXJuYWwgbWF0dGVyIGZvciB0aGUgc2VydmljZS4gSXQgaXMgc3BlY2lmaWVkDQog aW4gUkZDIDM1NDgg4oCcVGhlIGJhc2UxNiwgQmFzZTMyLCBhbmQgQmFzZTY0IERhdGEgRW5jb2Rp bmdz4oCdICh3aGljaCBpcyBhIGJldHRlciByZWZlcmVuY2UgZm9yIGV2ZW4gbm9ybWFsIGJhc2U2 NCB0aGFuIFJGQyAyMDQ1KS4gVGhlIHNhZmUgYWxwaGFiZXQganVzdCBzdWJzdGl0dXRlcyDigJwt 4oCcIGFuZCDigJxf4oCdIGZvciDigJwmIzQzO+KAnSBhbmQg4oCcL+KAnS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9BdXRoIGNvdWxkIHVzZSB0aGlzIG1vZGlmaWVkIGJh c2U2NCBmb3Igb2F1dGhfc2lnbmF0dXJlIC0tIHRob3VnaCBJIGFtIG5vdCBzdXJlIGlmIHRoYXQg d291bGQgYmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Fc2NhcGluZyB2YWx1ZXMgYmVmb3Jl IHB1dHRpbmcgdGhlbSBpbiB0aGUgQXV0aG9yaXphdGlvbiBIVFRQIGhlYWRlciBjYW4gYmUgZWxp bWluYXRlZC4gSXQgaXMgYSBiaXQgc3RyYW5nZSBhdCB0aGUgbW9tZW50IHRoYXQgYSBVUkktZXNj YXBpbmcgbWVjaGFuaXNtICglLWVzY2FwaW5nKSBpcyB1c2VkIGluIGFuIEhUVFAgaGVhZGVyIHF1 b3RlZC1zdHJpbmcsIHdoaWNoIGhhcyBhIHNlcGFyYXRlIGVzY2FwaW5nDQogbWVjaGFuaXNtLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZXNlIGNoYW5nZXMgYnJlYWsgYmFja3dhcmQtY29tcGF0aWJpbGl0eSB3aXRo IE9BdXRoIDEuMCAtLSBidXQgSSBhbSBmYWlybHkgY2VydGFpbiB0aGF0IHdhcyBicm9rZW4gYW55 d2F5IChlZyBpZiB3ZSBlbGltaW5hdGUgU0hBLTEpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmFtZXMgTWFuZ2VyPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPg0KPGJyPg0KPGEgaHJlZj0ibWFp bHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20iPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5j b208L3NwYW4+PC9hPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPklk ZW50aXR5IGFuZCBzZWN1cml0eSB0ZWFtPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAlDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ2hpZWYgVGVjaG5vbG9neSBPZmZpY2U8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+4oCUPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWxzdHJhPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E11231C3778AWSMSG3153Vsrv_--