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
