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 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 >> >> >> >> >> 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 >>> https://www.ietf.org/mailman/listinfo/oauth >> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
