I agree. - Francisco
--- On Tue, 3/29/11, Phil Hunt <phil.h...@oracle.com> wrote:
From: Phil Hunt <phil.h...@oracle.com>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
To: "George Fletcher" <gffle...@aol.com>
Cc: fcore...@pomcor.com, "Justin Richer" <jric...@mitre.org>, "Eran
Hammer-Lahav" <e...@hueniverse.com>, "OAuth WG" <oauth@ietf.org>, "Karen P.
Lewison" <kplewi...@pomcor.com>
Date: Tuesday, March 29, 2011, 6:03 PM
My primary concern is that when the authorization code is handed back to the
target app (in this case by way of redirect through a user-agent/browser), then
the return path to the browser is at least secure. If the browser/user-agent
is redirecting to a local app, then no big deal. BUT, if the app is redirecting
back to a web service, then that path too must be secure.
So both #1 and #2 (described earlier) MUST be secure unless redirect is local
in which case 2 (outgoing GET by user agent) is optional since it cannot be
scanned.
I think SHOULD is too weak (too broad). I'd rather have a MUST with an
appropriate specific exception to cover the local portion of the redirect.
philphil.h...@oracle.com
On 2011-03-29, at 10:55 AM, George Fletcher wrote:
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>
wrote:
From: Eran Hammer-Lahav <e...@hueniverse.com>
Subject: Re: [OAUTH-WG] WGLC on
draft-ietf-oauth-v2-13.txt
To: "Phil Hunt" <phil.h...@oracle.com>, "Justin
Richer" <jric...@mitre.org>
Cc: "OAuth WG" <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]
> 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
_______________________________________________
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
