Re: [OAUTH-WG] comments on draft-hammer-oauth-03
"Moore, Jonathan (CIM)" <Jonathan_Moore@Comcast.com> Tue, 10 November 2009 04:36 UTC
Return-Path: <jonathan_moore@comcast.com>
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 0D2633A6820 for <oauth@core3.amsl.com>; Mon, 9 Nov 2009 20:36:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.463
X-Spam-Level:
X-Spam-Status: No, score=-8.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 2QmBg4AXIKuO for <oauth@core3.amsl.com>; Mon, 9 Nov 2009 20:36:24 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 65C173A680F for <oauth@ietf.org>; Mon, 9 Nov 2009 20:36:24 -0800 (PST)
Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.60218675; Mon, 09 Nov 2009 23:36:48 -0500
Received: from PACORPEXCMB03.cable.comcast.com ([24.40.15.85]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 23:36:48 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 09 Nov 2009 23:36:48 -0500
Message-ID: <ED97F89464499E4D80A68CDCE1E3D1FF0248E348@PACORPEXCMB03.cable.comcast.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OAUTH-WG] comments on draft-hammer-oauth-03
Thread-Index: AcphigUd3nOpOpWCTPqrjpPzcGs23gANHuZ5
References: <4AF8943E.4050802@stpeter.im>
From: "Moore, Jonathan (CIM)" <Jonathan_Moore@Comcast.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, OAuth WG <oauth@ietf.org>
X-OriginalArrivalTime: 10 Nov 2009 04:36:48.0981 (UTC) FILETIME=[6AAC6050:01CA61BF]
Subject: Re: [OAUTH-WG] comments on draft-hammer-oauth-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2009 04:36:26 -0000
Peter Saint-Andre wrote: > 11. In Section 3.3.4, we say that PLAINTEXT method SHOULD be used with > SSL/TLS. Does that deserve to be a MUST? At least it might be worth a > mention in the Security Considerations. RFC2119 says "MUST" should be reserved for cases where it is required for interoperability (which I think isn't the case here) or where it might cause harm (maybe this is true here?), and that an implementer may only ignore a "SHOULD" at his/her peril (which is for sure the case here). I agree this is worth calling out the specific risks of ignoring this if we leave it as a SHOULD, though. Maybe we can say "REALLY REALLY SHOULD (NO I MEAN IT)"? :) Jon ........ Jon Moore Comcast Interactive Media -----Original Message----- From: oauth-bounces@ietf.org on behalf of Peter Saint-Andre Sent: Mon 11/9/2009 5:14 PM To: OAuth WG Subject: [OAUTH-WG] comments on draft-hammer-oauth-03 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <hat type='individual'/> On the flight to Japan for IETF 76, I finally got a chance to finish reviewing draft-hammer-oauth-03, the informational documentation of what's known as "OAUth Core 1.0 Revision A" in the community. Many of my comments are purely editorial, so I will send those directly to the document editor. Here are a few slightly more substantive issues... 1. I think it would be very helpful to provide a bit more context in the Introduction. Say, two or three sentences about the provenance of this technology, the community that developed it, and a link to oauth.net (along with something like the final paragraph of the current Introduction). Something like this: The OAuth protocol was originally created by a loose group of technologists from a variety of websites and other Internet services, who wanted to solve the common problem of enabling delegated access to protected resources. The resulting OAuth protocol was stabilized at version 1.0 in October 2007 and published at the oauth.net website. This specification provides informational documentation of OAuth Core 1.0 Revision A as finalized in June 2009, incorporating several errata reported since that time as well as numerous editorial clarifications. It is not an item of the IETF's OAuth Working Group, which at the time of writing is working on an OAuth version that can be appropriate for publication on the standards track. 2. In the Terminology section, I think it might be helpful to provide pointers to the old terminology, as in: "(In the community edition, a client was called a consumer.)" We might also want to point to RFC 4949 regarding terminology and check that our usage of key terms like "authorization" is consistent with that document. 3. Before jumping right into authenticated requests in section 3, I think it would be helpful to provide a bit more context about the overall protocol flow (similar to Section 6 of the community edition). 4. In Section 3.1, we might want to say explicitly which parameters are required and which are not. For example, "Protocol parameters MUST NOT appear more than once per request. The following parameters are REQUIRED unless otherwise noted." Then say that, for example, oauth_version is RECOMMENDED instead of REQUIRED (or whatever). 5. In Section 3.2, it's not completely clear that the timestamp value must be numerical instead of, say, in ISO 8601 format. It's also not clear how the server would specify that the timestamp is something other than "the number of seconds since January 1, 1970 00:00:00 GMT". 6. In Section 3.2, let's explicitly say that methods that enable the client to sync its clock with the server's clock are out of scope for OAuth. 7. In Section 3.3, let's refer to the Security Considerations from the paragraph about not mandating a particular signature method (since that's where we talk about the properties of various methods). 8. In Section 3.3.1.1, we might want to be more explicit about which parameters are included in the "specific set of request parameters" (see recent discussion on the community list). 9. In Section 3.3.1.1 second bullet point, we say "The HTTP request entity-body, but only if..." -- does this mean that all of the three listed conditions need to be met, or any one of the conditions? 10. In Section 3.3.1.1, the sentence The "oauth_signature" parameter MUST be excluded if present. might be taken to imply that all other oauth_* parameters MUST be included (if found in the request). Let's be explicit about that. 11. In Section 3.3.4, we say that PLAINTEXT method SHOULD be used with SSL/TLS. Does that deserve to be a MUST? At least it might be worth a mention in the Security Considerations. 12. In Section 3.6, we say that "Text values are first encoded as UTF-8" but it's not fully clear to me which values this applies to or exactly where in the protocol the encoding rules are applied. 13. In Section 4, I think that a brief flow diagram would be helpful to illustrate the authorization process (e.g., this would provide context for why the client obtains a set of temporary credentials, which might not otherwise be obivous to first-time readers of Section 4.1). 14. In Section 4.2 (or in a security consideration pointed to from Section 4.2), it might be helpful to describe why oauth_callback is important and the nature of the session fixation attach that it helps to prevent. 15. In Section 6.8, I think there is a non-sequitur. Just because a client is a freely available desktop application does not mean that an attacker will be able to recover the client credentials. Perhaps one step in the chain of reasoning is not spelled out here? 16. Section 6.15 says: Clients should prevent CSRF attacks on OAuth callback URIs by verifying that the resource owner at the client site intended to complete the OAuth negotiation with the server. No guidance is provided on how the client might be able to do so. Saying that "methods for doing so are out of scope for this specification" is probably acceptable. 17. In Appendix A.1 the phrase "HTTPS POST" is used, but I think that's more accurately an HTTP POST to an SSL-protected host. Overall the spec looks very good, and IMHO is a big improvement over the community edition! 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/ iEYEARECAAYFAkr4lD0ACgkQNL8k5A2w/vzkJwCfeOy6ZH1u8La20llLhgksyb4T mOYAoPrGjaVIL9w801IuguP3161i2X0/ =tN+p -----END PGP SIGNATURE----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] comments on draft-hammer-oauth-03 Peter Saint-Andre
- Re: [OAUTH-WG] comments on draft-hammer-oauth-03 Moore, Jonathan (CIM)
- Re: [OAUTH-WG] comments on draft-hammer-oauth-03 Eran Hammer-Lahav
- Re: [OAUTH-WG] comments on draft-hammer-oauth-03 Eran Hammer-Lahav
- Re: [OAUTH-WG] comments on draft-hammer-oauth-03 Peter Saint-Andre
- Re: [OAUTH-WG] comments on draft-hammer-oauth-03 Ethan Jewett
- Re: [OAUTH-WG] comments on draft-hammer-oauth-03 Peter Saint-Andre
- Re: [OAUTH-WG] comments on draft-hammer-oauth-03 Peter Saint-Andre