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
