As a matter of practicality, requiring all clients to deploy server-side TLS is absurd. If we mandate redirections URIs to use https, we are basically making everyone ignore it. It’s like a speed limit sign of 5mph.
EHL From: George Fletcher [mailto:gffle...@aol.com] Sent: Tuesday, March 29, 2011 10:55 AM To: fcore...@pomcor.com Cc: Phil Hunt; Justin Richer; Eran Hammer-Lahav; OAuth WG; Karen P. Lewison Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt 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><mailto:e...@hueniverse.com> wrote: From: Eran Hammer-Lahav <e...@hueniverse.com><mailto:e...@hueniverse.com> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt To: "Phil Hunt" <phil.h...@oracle.com><mailto:phil.h...@oracle.com>, "Justin Richer" <jric...@mitre.org><mailto:jric...@mitre.org> Cc: "OAuth WG" <oauth@ietf.org><mailto: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</mc/compose?to=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</mc/compose?to=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</mc/compose?to=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</mc/compose?to=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</mc/compose?to=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</mc/compose?to=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</mc/compose?to=e...@hueniverse.com>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: oauth-boun...@ietf.org</mc/compose?to=oauth-boun...@ietf.org> > >>>>>>>>> [mailto:oauth- > boun...@ietf.org</mc/compose?to=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</mc/compose?to=OAuth@ietf.org> > >>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org</mc/compose?to=OAuth@ietf.org> > >>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>> > >> > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org</mc/compose?to=OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
