+1 for the first The second is almost right, except some of us are suggesting a middle ground of using a 'MUST EXCEPT' for where the redirect is to a client local to the user-agent.
IMO, the phrasing below reflect positions that are too restrictive/too open. Phil phil.h...@oracle.com On 2011-03-30, at 11:23 AM, Eran Hammer-Lahav wrote: > 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 > > > > > 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
