I don’t think a SHOULD leads to more than 2-3 lines clearly warning against a MITM attack on the authorization code or the returned script (implicit grant). The attack is simple and the warning is equally simple.
Different components of the protocol have different security issues and complexity. This is just the nature of the work where many different parties with vastly different needs are trying to create a single framework. The best example of this diversity are the two ways people are asking the protocol to support client authentication: password and an assertion method. It is trivial to write about the security considerations of a password, it is not to write a complete security consideration about client assertion authentication, unless the list of supported assertions is well defined (which would defeat the goals of those requesting this). This work leaves much unspecified and therefore will need to be profiled or extended. It is the nature of building a framework, not a finite protocol (which is what 1.0 is). By definition, a framework is just the foundation and has limited well-defined properties. <rant> Personally, I find most of the enterprise requirements for OAuth to be an abomination. The non-consumer web world has hijacked a successful community protocol and added so much crap to it so that they can whitewash their own proprietary protocols and appear more open and trendy. Since this is an IETF working group, there is nothing I can do about it here, other than try to keep stuff out of the v2 specification through consensus. But the enterprise world can’t complain about this protocol not measuring up to their security requirements when it was never meant to be an enterprise protocol. It was a *web* application protocol. The recent move from the application area to the security area is the most recent demonstration of how far this work has moved from its original use cases (when this WG was created). </rant> EHL From: Phillip Hunt [mailto:phil.h...@oracle.com] Sent: Saturday, April 02, 2011 12:20 PM To: Eran Hammer-Lahav Cc: fcore...@pomcor.com; Skylar Woodward; Oleg Gryb; OAuth WG; Karen P. Lewison Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) For the record, I can except SHOULD. But my very strong feeling is this leads to much more lengthy and complicated language. I believe we have already crossed the line where it is no longer easy for deployers to figure out if deployments are secure. It is now a spec challenging to even subject matter experts. If we take the current implementers as evidence it shows we have little or no security either due to misunderstandings or business decisions to accept risk for flexibility. It is not time to be idealistic but rather realistic. It looks to me that it is time to either redo authorization to avoid TLS (somehow) or consider splitting into secure/non-secure profiles to satisfy everyone's needs. (not my preference) Any other ideas? Phil Sent from my phone. On 2011-04-02, at 11:46, Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> wrote: I don’t think your statement that ‘the IETF should endorse lack of security’ is accurate or helpful. I completely rejects the notion that a SHOULD with strong language explaining the risk is any less “secure” than a MUST. The only impact of using a MUST vs. a SHOULD is that companies deploying it without requiring TLS on the redirection endpoint will not be able to claim full compliance if we use a MUST, but will be able to if we use a SHOULD. RFC 2616 defines compliance as follows: An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant." If we used a SHOULD for TLS, and added such a language, it will enable the definition of three classes of implementations: non-compliant, unconditionally compliant (your definition of secure), and conditionally compliant (what Facebook, Yahoo, Google, and Kiva are likely to deploy). But my point is that trying to paint the SHOULD option with strong security guidance as ‘the IETF endorsing an insecure protocol’ or ‘destroy the credibility of OAuth outside the silly social networking circle’ (I’m paraphrasing but the spirit of the comments is accurate) is just an overblown reaction and scare tactic. Both options are legitimate and produce the same deployment reality. They only differ in how the spec talks about security and how implementers can talk about their conformance. EHL From: Francisco Corella [mailto:fcore...@pomcor.com] Sent: Saturday, April 02, 2011 10:49 AM To: Skylar Woodward; Phil Hunt; Eran Hammer-Lahav Cc: Oleg Gryb; OAuth WG; Karen P. Lewison Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) Eran, > Google, Facebook, and Yahoo! already indicated they will not enforce > such a MUST. I could not get a clear answer from Twitter. > > However, no one representing this companies has bothered to express > this view on the list, and to express how they would like the > specification to handle this case. This is why I stopped advocating > for it (personally, my own product is already end-to-end TLS, and when > we open it up for developers, will not enforce it for personal > installations). Good. The IETF is not a consortium of companies. What the WG should debate is whether the IETF should endorse lack of security. Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
