My primary concern is that when the authorization code is handed back to the target app (in this case by way of redirect through a user-agent/browser), then the return path to the browser is at least secure. If the browser/user-agent is redirecting to a local app, then no big deal. BUT, if the app is redirecting back to a web service, then that path too must be secure.
So both #1 and #2 (described earlier) MUST be secure unless redirect is local in which case 2 (outgoing GET by user agent) is optional since it cannot be scanned. I think SHOULD is too weak (too broad). I'd rather have a MUST with an appropriate specific exception to cover the local portion of the redirect. Phil phil.h...@oracle.com On 2011-03-29, at 10:55 AM, George Fletcher wrote: > Hi Francisco, > > So the examples that Justin gave were either localhost or non HTTP based > schemes. If OAuth2 is to support these other schemes (often used in mobile > clients) then I'm not sure how TLS can be a MUST unless it's qualified to > apply to HTTP based URLs only. > > Is it sufficient to document this possible exposure in the security section > such that the spec doesn't preclude the use of OAuth2 with non HTTP based > redirect_uri? > > Thanks, > George > > On 3/29/11 1:05 PM, Francisco Corella wrote: >> >> Eran, >> >> It's not a reasonable compromise. #2 MUST use tls UNLESS of course it >> targets localhost. If #2 is sent without TLS to a Web server, the >> authorization code can be easily intercepted by an attacker. The attacker >> can then use it to obtain protected resources by submitting the >> authorization code to the client. (This is independent of whether the >> client authenticates itself when exchanging the authorization code for an >> access token or not.) In the Facebook use case, the attacker can use the >> authorization code to log in to the client using the user's Facebook >> identity. I believe this vulnerability exists in many implementations of >> the Facebook login button today. >> >> Btw, I've pointed this out before three or four times on this mailing list, >> including in a response to the WGLC that you never replied to. >> >> Francisco >> >> --- On Mon, 3/28/11, Eran Hammer-Lahav <e...@hueniverse.com> wrote: >> >> From: Eran Hammer-Lahav <e...@hueniverse.com> >> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt >> To: "Phil Hunt" <phil.h...@oracle.com>, "Justin Richer" <jric...@mitre.org> >> Cc: "OAuth WG" <oauth@ietf.org> >> Date: Monday, March 28, 2011, 10:28 PM >> >> 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 >> >> _______________________________________________ >> 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
