+1
I agree this is not just about setting one TLS setting to mandatory.
I believe we need language that is simple and clear. Terms like SHOULD are
loopholes that create risk as they are too broad. They also have served to make
the security considerations incredibly long and complex since we had to explain
all the risks exposed. In this respect, I think the overall specification needs
to be tightened up considerably in order to get back to a simple specification.
Folks this is an AUTHORIZATION protocol! Our default position 'should' be that
TLS is a MUST unless it can be demonstrated why there is absolutely no risk to
turning it off. For example, I agree that if a redirect end-point is local, it
does not need to be on. There are relatively few exceptions.
In my opinion, most OAuth sites in production today do not do enough to protect
authorization codes and are currently open to relatively simple hijacking
attacks. The current OAuth usage in my opinion is not only a mark of success of
OAuth but rather a demonstration that tightening requirements is critical to
keeping OAuth successful.
As deployers of OAuth come on board supporting higher-risk data (e.g.
financial, trading, etc) the tolerance for OAuth failures will be low. We've
got a good acceptance now, and I would not like to see it jeopardized by some
deployers taking short-cuts because of lack of effort or lack of proper funds
to support a secure deployment. If I were a charity, the last thing I would
want is to risk the confidentiality of my donors.
If however, there is a strong community here that disagrees because they don't
see any risk, then maybe there is a strong case to be made for a second RFC
that defines a tighter set of requirements ("Secure OAuth"). In a sense, this
is starting to happen now with regards to security considerations - they are
just too long. I would rather avoid this if we can.
Phil
phil.h...@oracle.com
On 2011-03-31, at 9:42 AM, Eran Hammer-Lahav wrote:
> It is important to distinguish between securing the resource server and
> securing the client. I think this is where this conversation has been
> somewhat broken.
>
> If the client is user-agent based or web server based, it MUST user TLS 100%
> of the time when authenticating its users or delivering any scripts that may
> have access to any OAuth credentials (tokens, code, etc.). This goes far
> beyond just securing the redirection call.
>
> For example, a JS client running in the browser will not leak the access
> token received from the authorization server using the implicit grant because
> it is delivered over TLS and is in the fragment which will not be send to the
> server containing the script. However, if that script is served without TLS,
> it can be manipulated by a MITM and changed to send the access token anywhere.
>
> Same with server based clients using cookies for their own user
> authentication. If they don't use TLS exclusively, sessions can be hijacked
> and any protected resources they have access to are now potentially
> compromised.
>
> IOW, if the client isn't perfect all around, securing the redirection URI
> does not increase its security. It's like putting an armed guard at one
> entrance to a building with 100 other wide-open doors. It is hypocritical and
> irresponsible to create the illusion of client security by focusing solely on
> the redirection URI.
>
> IMO, a strong warning with a comprehensive explanation of the overall client
> security model will do much more good than putting horse blinds on and
> pretending that what the client does right after the callback is 'not OAuth'
> and something we should not care about.
>
> A MUST use TLS focused narrowly on the redirection URI does not make the web
> better. At best, it make one door secure, but it also has the potential of
> creating a false sense of security which is typically where things go
> terribly wrong.
>
> BTW, a profile of OAuth used primarily for login such as the proposed OpenID
> Connect, should make the callback use of TLS required. In that context, it is
> a logical extension of the server's use of TLS to provide a secure login
> experience.
>
> EHL
>
>> -----Original Message-----
>> From: Skylar Woodward [mailto:sky...@kiva.org]
>> Sent: Thursday, March 31, 2011 7:32 AM
>> To: Dick Hardt
>> Cc: Eran Hammer-Lahav; OAuth WG
>> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
>>
>> A requirement for TLS on the callback would make OAuth prohibitive for
>> many of our developers. The developers are usually volunteers and they are
>> already donating their own resources to help a non-profit (from which US law
>> mandates the developers cannot profit). In other cases the developers are
>> small firms operating in developing counties where establishing and
>> maintaing a valid certificate may still be a imperfect art.
>>
>> In short, a requirement like this puts the nail in the coffin of many
>> would-be
>> efforts to help out.
>>
>> So as Dick identifies here, we have sufficient security around the
>> authorization grant by tying it client credentials. I would thus be opposed
>> to
>> the term "MUST." I also think it's helpful to have the language limit the
>> SHOULD to the non-user-agent cases. There's no reason we should suggest a
>> callback URI designed for client-side intercept to use an HTTPS url - so
>> this is
>> in the spirit of Phil's response to Justin's comment on limiting the scope of
>> SHOULD.
>>
>> skylar
>>
>>
>>
>> On Mar 30, 2011, at 11:19 AM, Dick Hardt wrote:
>>
>>> Thanks for pointing out my misunderstanding. I was thinking client in the
>> sense of the side of TLS initiating a request.
>>>
>>> I agree that requiring TLS on the callback is an unexpected change.
>>>
>>> I recall reviewing the security implications of an unsecured callback as
>>> being
>> nominal if the authorization grant is linked to the client credentials.
>>>
>>>
>>> On 2011-03-29, at 10:07 PM, Eran Hammer-Lahav wrote:
>>>
>>>> I think you got this backwards. We're talking about forcing developers
>> using the Facebook (or any other service) API to deploy their own TLS
>> endpoint for the incoming callback (via redirection). Every developer will
>> need to get a cert and deploy an HTTPS endpoint.
>>>>
>>>> That's has never been discussed.
>>>>
>>>> EHL
>>>>
>>>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>>>> Sent: Tuesday, March 29, 2011 9:02 PM
>>>> To: Eran Hammer-Lahav
>>>> Cc: WG
>>>> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
>>>>
>>>>
>>>> On 2011-03-29, at 4:40 PM, Eran Hammer-Lahav wrote:
>>>>
>>>>
>>>> To clarify, I am not opposed to mandating TLS on the callback, just that if
>> we do, we can't ship the protocol the way it is without coming up with some
>> other alternative that does not require TLS deployment on the client side.
>> OAuth 1.0 has no such requirement and adding it in 2.0 is completely
>> unexpected by the community at large.
>>>>
>>>> I only recall the concern with TLS to be on the server side, not the client
>> side -- and I don't think that it is unexpected at all.
>>>>
>>>>
>>>>
>>>> It would be helpful to hear from some companies with large 1.0 or 2.0
>> deployment on this matter? Anyone from Google, Facebook, Yahoo, Twitter,
>> etc.?
>>>>
>>>> When working on OAuth-WRAP, I talked to all of those companies about
>> using TLS, and only Facebook said that they wanted an option to be able to
>> not require TLS. Since then, all Facebook's new APIs which are essentially
>> using OAuth 2.0 run on TLS.
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
