Phil, The main difference is that it's a requirement on the *client* instead of the *provider* side of the equation, and clients aren't always even speaking HTTP. I agree that all client web servers SHOULD do it. A particular provider can even REQUIRE it for their registered clients, a step that is outside the scope of OAuth. But there are real, in-use patterns that don't require the client to make an HTTP request to an external service.
I don't see how Firesheep is relevant to this discussion -- if your browser is making a call to localhost to get the token, who outside of your machine is going to do it? I'm not talking about convenience for developers here (which I would argue should NOT be discounted, but that's another argument), I'm talking about cases where the browser isn't going outside of a trusted security boundary. There are also instances where there may not even be an HTTP transaction involved, let alone one that could support TLS. -- Justin On Mon, 2011-03-28 at 16:25 -0400, Phil Hunt wrote: > Justin, How is that so? Remember firesheep? I wouldn't want the > authorization code being exchanged without TLS in a cafe. Intercept is just > too easy. And as I mentioned earlier, client credentials are already very > weak in many cases. In contrast, two web servers are hard to sniff unless you > are able to gain access to their network communications path. > > As for testing, it seems more reasonable to put servers in temporary > non-compliance while testing rather then allow non-secure servers in > production because of the SHOULD loophole. > > Also, while it does seem convenient for the developer not to have to use TLS > for authz codes, note that the developer still has to have TLS enabled when > exchanging the code for an access token. So I'm not sure how relaxing TLS for > obtaining authorization actually simplifies the developer lifecycle since > they still have to set it up to test the other parts. In my view, it would > be ok for a developer to temporarily disable TLS everywhere during > development -- which places operation outside RFC compliance while developing > -- but forces compliance once they go into production. > > It seems like I had to give a pretty substantial justification and we backed > off because TLS is seen as inconvenient. I think we need more evidence that > there are safe cases that don't need TLS. > > Sorry for pushing hard on this one, but TLS is the backbone of OAuth security > at present. > > Phil > phil.h...@oracle.com > > > > > On 2011-03-28, at 12:52 PM, Eran Hammer-Lahav wrote: > > > No change then. But the security considerations section must reflect this. > > > > EHL > > > >> -----Original Message----- > >> From: Justin Richer [mailto:jric...@mitre.org] > >> Sent: Monday, March 28, 2011 10:05 AM > >> To: Eran Hammer-Lahav > >> Cc: Phil Hunt; OAuth WG > >> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt > >> > >> What about non-http return uri's, or client-localhost, such as > >> > >> someapp://app/?code=foo > >> > >> http://localhost:87345/?code=foo > >> > >> HTTPS makes sense when you're talking between two web servers, but it > >> seems to fall apart otherwise. I think SHOULD is appropriate here. > >> > >> -- Justin > >> > >> > >> On Fri, 2011-03-25 at 16:03 -0400, Eran Hammer-Lahav wrote: > >>> Unless someone has an objection, I'll make the change from SHOULD to > >> MUST. > >>> > >>> EHL > >>> > >>>> -----Original Message----- > >>>> From: Phil Hunt [mailto:phil.h...@oracle.com] > >>>> Sent: Friday, March 25, 2011 12:42 PM > >>>> To: Eran Hammer-Lahav > >>>> Cc: OAuth WG; Chuck & Mara Mortimore > >>>> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt > >>>> > >>>> Regarding the message: http://www.ietf.org/mail- > >>>> archive/web/oauth/current/msg05762.html (sorry I somehow lost the > >>>> message in my email). > >>>> > >>>> This issue is theft of the authorization code during the redirect. > >>>> Authenticating the client is an important feature and goes a long > >>>> way, but it is not sufficient since in many cases, the > >>>> client_id/client_secret will likely be hard coded and relatively > >>>> easy to deduce (e.g. mobile client apps). Of course a strong client > >>>> authentication won't have this issue. This makes many consumer > >>>> situations very susceptible to an attack where the authorization code is > >> intercepted. > >>>> > >>>> For more information look at the SAML Artifact issues in section 6.5 > >>>> (specifically stolen artifact, replay, etc) of this document: > >>>> http://docs.oasis- > >>>> open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf > >>>> > >>>> There are a number of remediations suggested (small lifetime, single > >>>> use), but the foundational one is confidentiality of the exchange > >>>> (TLS). Hence the recommendation that the return of an authorization > >>>> code be kept secure with a MUST for TLS. > >>>> > >>>> Phil > >>>> phil.h...@oracle.com > >>>> > >>>> > >>>> > >>>> > >>>> On 2011-03-24, at 7:22 PM, Chuck Mortimore wrote: > >>>> > >>>>> > >>>>> On Mar 24, 2011, at 6:36 PM, "Eran Hammer-Lahav" > >>>> <e...@hueniverse.com> wrote: > >>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >>>>>>> Behalf Of Chuck Mortimore > >>>>>>> Sent: Monday, March 14, 2011 6:10 PM > >>>>>> > >>>>>>> 1) I'd vote for dropping the following from 1.4.2. In turn I'd > >>>>>>> discuss > >> some > >>>> of > >>>>>>> the security considerations, such as difficulty of protecting a > >>>>>>> client_secret in almost all use-cases of this profile. > >>>>>>> > >>>>>>> "Implicit grants improve the responsiveness and efficiency of some > >>>>>>> clients (such as a client implemented as an in-browser application) > >>>>>>> since it reduces the number of round trips required to obtain an > >>>>>>> access token." > >>>>>> > >>>>>> Why drop it? What about it isn't accurate? > >>>>> > >>>>> It's accurate, but my opinion is it sends the wrong message. It's > >>>>> clearly > >> the > >>>> less secure of the response types. By positioning it as the most > >>>> performant people may find that attractive and make the wrong security > >> decision. > >>>>> > >>>>> > >>>>>> > >>>>>>> 2) Section 2.1, we should MUST TLS even for Authorization Code. > >>>>>> > >>>>>> Why? What's the attack vector? > >>>>> > >>>>> See Phils comment on past experience with artifact bindings. Spec > >>>>> should > >>>> default for security always on, and let deployments that don't want > >>>> to use HTTPs simply be non-conformant. > >>>>> > >>>>>> > >>>>>>> 3) Section 4.1.3 - not clear to me why redirect_uri is REQUIRED > >>>>>>> since in 4.1.1 it's "REQUIRED unless" > >>>>>> > >>>>>> The client should always confirm where the code was sent to. It > >>>>>> can omit > >>>> the redirection is one was provided but should tell the server where > >>>> it went to. This is more consistent on the verification side, but if > >>>> the original flow designers want to chime in (Dick, Brian, etc.?), I'm > >>>> open > >> to change this. > >>>>>> > >>>>>>> 4) Section 4.2.2 - when did we drop refresh_token? I assume this > >> goes > >>>>>>> back to disagreement on how best to handle native clients. I'd > >>>>>>> prefer it to simply reference 5.1 and leave what is issued up to > >>>>>>> the security profile of the particular deployment as to what is > >>>>>>> issued. > >>>>>> > >>>>>> -08 June 2010. > >>>>>> > >>>>>> This has been decided for a long time. I'm not eager to change it. > >>>>> > >>>>> Thanks - I can live with it. Unfortunately we still seem to be > >>>>> fragmenting on > >>>> the native client approach. Good topic for IIW I suspect > >>>>> > >>>>> -cmort > >>>>> > >>>>>> > >>>>>> EHL > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >> > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
