I think I understand both of your points. Phil is saying that the client must run over HTTPS to be secure so not being able to take an HTTP endpoint is a non-starter anyway. Eran is saying security is a holistic evaluation, and since all secure clients would be HTTPS anyway (as Phil also asserts) why bother concerning the spec with this.
I'd have to agree with Eran on this especially as I think Phil's argument assumes popular use cases but not all possible applications. So, imagine a website secured inside a corporate firewall. This service needs to access the provider's services via OAuth and thus exposes one callback open to the world for purposes of the OAuth handshake. The redirect URI is HTTP since the corporation is having trouble acquiring or setting up a certificate for HTTPS - in any case, the provider does not requrire it. In this case, the auth code flows into the firewall via HTTP, but is further validated by client credentials over TLS in access token requests. Valid tokens return to the web application inside the corporate firewall over TLS and the information is still secure from outside threats. So, my point is that the use of client credentials (always kept secret and inside the firewall) secures the auth code exchange and use of HTTP doesn't create a vulnerability. It is actually more criti cal that the user-interface portion of the app (not the callback URI, on whichever server it may reside) be secured than the actual callback URI itself. However, all points are taken that developers should be encourage to develop secure apps and that in most cases, that means deploying common-case consumer web apps over HTTPS. I don't think we'll be using our API to force this shift in the web, however. Given that some companies represented in the working group still have developer web sites that transmit all secrets and application data over HTTP, we have to assume the developers habits will trail the examples of the industry. Instead, we'll use developer education to help them make secure products and thus earn the trust of our users. But enforcing a best-practice via the API won't ensure secure apps. Only careful auditing and approval of the clients will help increase security of our app ecosystem. Currently we don't have the bandwidth to do this. We can only promise to shut down or disable misleading or careless apps as we find them. To access certain kinds of data we may have increased expectations around app security or encryption. (Not all of our data is financial, much of it is more social-private like Facebook or Twitter.) For the more sensitive apps we would review the apps more closely and regularly to see they preform to our stated Terms of Service, expectations, or partner contract. Still, we can't ensure that level of compliance just by requiring TLS at one leg of the Auth handshake. I understand the desire to establish a minimum level of tenacity in fighting for overall protocol strength. I just feel that if you require TLS on the callback URI for web apps you'll have a fair number of violations due to the state of the art today and will exclude alternative use cases like the one I described. Furthermore the requirement of TLS here isn't required to ensure security, so much as the need for TLS on web app server itself (which may be different from that of the callback). (Apps without client credentials, if allowed, would also need TLS). skylar On Mar 31, 2011, at 2:10 PM, Phil Hunt wrote: > Unfortunately these aren't just "aspirations". We're talking about what are > the *necessary* minimums. > > Yes, I have been focusing on a couple of very specific aspects of > authorization and I agree, the whole spec is important. But I disagree that > that would be justification not to fix authorization as you suggest. After > all if the first step, authorization, is insecure or hijackable, the rest of > the specification is kind of pointless isn't it? > > Having contributed to the security considerations, I have grown concerned > that the lassie faire approach is actually making the spec more complex. > Because of all the options, the security considerations have had to explain > all of the issues (and there are many) and what the remediations are. Further > with so many specific deployment options, inter-operability seems to be a big > question. With so many specifics, what would an inter-operable specification > be? My conclusion? The OAuth 2 spec is bogged down by too much choice > resulting to too much practical complexity. > > ==> Conclusion: Current implementors will find it challenging to ensure their > deployment is secure. <== I can't make this point strongly enough! > > I think we are in agreement on most things (hence my +1). But I think we are > simply at a stage where refinement is key to success. A good specification > should focus on what are the key options keeping choice to a minimum. We just > aren't there yet - and we may need some substantive changes to fix this (I > hope not). > > Phil > phil.h...@oracle.com > > > > > On 2011-03-31, at 10:43 AM, Eran Hammer-Lahav wrote: > >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
