Seems like your +1 is for a different conclusion :-) My point is that specifications should reflect reality, not unattained aspirations. That leads to devaluation of the specification and dismissal of other - more important - security requirements. If the majority of members will confirm that they will not allow clients to register or provide a non HTTPS callback (excluding localhost), I will be much more inclined to support a MUST here. But without that, I don't want to write text knowing it will be ignored by many deployments.
Also, what should be the policy regarding non http/https schemes? What if the callback is using a local application handler which triggers sending the code over an insecure channel? This is another example where an explanation is much more valuable than a normative MUST. EHL > -----Original Message----- > From: Phil Hunt [mailto:phil.h...@oracle.com] > Sent: Thursday, March 31, 2011 10:30 AM > To: Eran Hammer-Lahav > Cc: Skylar Woodward; Dick Hardt; OAuth WG > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt > > +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
