Thanks for the clarification. Yes, the compromise makes sense. Phil phil.h...@oracle.com
On 2011-03-28, at 3:28 PM, Eran Hammer-Lahav wrote: > The code is returned in two steps: > > 1. The authorization server replies to the user-agent request (providing > authorization) with a redirection instruction typically using the Location > response header field. > 2. The user-agent makes an HTTP GET request to the provided location (which > may be something other than an HTTP URI, or an HTTP URI to localhost). > > #1 is an HTTP response to a user-agent request to the authorization endpoint > (or a subsequent one if the server implementation has multiple authorization > steps). > > #2 is an HTTP request made by the user-agent. > > In order for the code to be secure end-to-end, both steps must use TLS. The > arguments made against making TLS required are based on use cases for #2. We > can make #1 (the authorization endpoint require TLS since it already has to > support it for the 'token' response type. We should make callbacks a SHOULD > for TLS. > > Does this sound like a reasonable compromise? > > EHL > >> -----Original Message----- >> From: Phil Hunt [mailto:phil.h...@oracle.com] >> Sent: Monday, March 28, 2011 2:28 PM >> To: Justin Richer >> Cc: Eran Hammer-Lahav; OAuth WG >> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt >> >> This was referring to section 2.1 that the authorization server must use TLS >> when returning an authorization code. >> >> If it doesn't use TLS then the code being returned to the client can be >> intercepted. >> >> Or did I miss something? >> >> Phil >> phil.h...@oracle.com >> >> >> >> >> On 2011-03-28, at 1:37 PM, Justin Richer wrote: >> >>> 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
