We have consensus to change issue one to a MUST. Basically, the authorization endpoint MUST always use TLS regardless of its output.
We are still debating mandating TLS for the redirection URI (registered or dynamic) for any non-localhost transmission. The issue is not limited to sending the authorization code, but also when receiving HTML/JS code used to extract the token from the fragment in the implicit grant case. The issue is not whether there is a security risk, but what language we should use to warn against it (i.e. make insecure a violation of the spec via a MUST, or clearly explain the risks via a SHOULD). EHL From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Wednesday, March 30, 2011 11:09 AM To: Dick Hardt Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt I believe there are really two separate issues in this thread - hence the confusion. This is a fairly complex interchange since it involves re-directs, message confidentiality, and server authentication issues. ONE: I believe the text Dick is referring to is: "If the response includes an access token, the authorization server MUST require TLS 1.2 as defined in [RFC5246] and MAY support additional transport- layer mechanisms meeting its security requirements. If the response does not include an access token, the authorization server SHOULD require TLS 1.2 and any additional transport-layer mechanism meeting its security requirements." I believe the contentious part is the second part "If the response does not include an access token...". 1. Should we further clarify as "either within the redirect URL" or within a response document since some might argue that a redirect URL is not the response document when in this case it still carries information. 2. If no data is present, "state" is still available. How much of a concern do we have? Some are arguing that there is no need to secure this. In my opinion the MUST is required for reasons other than leakage. Note that we are talking about a RESPONSE message to a REQUEST that definitely should have been secure because in this case TLS authenticates the authorization server. Reverting to a SHOULD implies the original REQUEST need not be secure -- which means the client app has not authenticated the authorization service. If this is the case, then security depends solely on the integrity of the authorization code (artifact) not being spoofed since the whole authorization step is not secured from the perspective of the client. Given the variety of token systems out there, I would rather not depend on security of the authz code alone. TWO: There is a second issue that people are raising regarding the redirect that would force clients to implement TLS server side security. I'm not seeing where this is covered in the spec. The exception we are discussing is that if the redirect endpoint is local to the user-agent, then TLS is not required. However, if it is remote (such as an OAuth client that is a web service), then TLS is a MUST. Maybe this point needs to be discussed in section 2.1.1? Further, from section 2.2: "Since requests to the token endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the authorization server MUST require the use of a transport-layer security mechanism when sending requests to the token endpoints. The authorization server MUST support TLS 1.2 as defined in [RFC5246], and MAY support additional transport-layer mechanisms meeting its security requirements" This paragraph seems to indicate that the transmission of the authz code in 2.1 is unsecure. I think the first phrase (Since requests to the token endpoint result in the transmission of clear-text credentials (in the HTTP request and response)) should be removed as it isn't quite in sync with even the current 2.1 endpoint behaviour. Cheers, Phil phil.h...@oracle.com<mailto:phil.h...@oracle.com> On 2011-03-30, at 9:25 AM, Dick Hardt wrote: Phil I'd suggest you review the spec so that you understand what Eran and I are saying. No code has been granted in the redirect to a web client, where implementing TLS server side is a major barrier. -- Dick On 2011-03-30, at 9:15 AM, Phil Hunt wrote: Developers of say a mobile app would not have to deploy it since the redirect endpoint would be local per the specific exception proposed. There should be NO requirement to make a client app implement TLS server side security. The concern here is that all "network" paths are secured to prevent impersonation or theft of the session. Remember that in many cases, once the code is granted, the subsequent token is often good for a LONG time and thus this becomes the weak point in this protocol. Re: Justin's comments on SHOULD, I find SHOULD is just too broad, it does not define when it is acceptable not to have security. I prefer clear specification text that says the network paths must be protected. Re: Eran's comments about impact on the existing community. I don't think you are grasping the broadness of acceptance of OAuth 2.0. The existing OAuth 1.0 users are primarily social networks. I haven't heard them object. In fact, I've noticed almost all have started enabling HTTPS everywhere (at least as a user option). But OAuth2 has a much broader community now that I would argue is VERY concerned about risks of impersonation and real financial loss. Phil phil.h...@oracle.com<mailto:phil.h...@oracle.com> On 2011-03-30, at 8: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
