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
