-----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
