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
