The point of this message is to help people choose between the two options, not to promote one over the other. I have tried to present a balanced view, given that a MUST is the easy way out (specification wise) since it moves the problem elsewhere.
Not sure what you 'totally disagree' with regarding the two options. Clearly, both options state that TLS is required in order to prevent this kind of attack, they just communicate this differently (one saying you have to use it, the other that you should and here is why). The end result is the same, since a MUST is not going to cause those who can't enforce it obey. I'm not dismissing the importance of this message, just that these *are* the two options and they both provide the *same* technical solution. It's a political difference (conformance where interop is of no real consequence). As for the added exception to #1, it is pretty meaningless. TLS is required to avoid this attack for any communication that may be susceptible to a MITM attach. This is not limited to HTTP over non-localhost. There are other URI scheme out there which result in an insecure channel. Given that there is nothing HTTP specific to the redirection URI, the exception has to be pretty narrow, and not focused on HTTP + localhost or custom schemes. It must be framed that the MUST can only be ignored if the communication is safe from MITM (and we can give localhost HTTP as one example). EHL From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Thursday, March 31, 2011 5:43 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) Sadly, see below. Phil phil.h...@oracle.com<mailto:phil.h...@oracle.com> On 2011-03-31, at 5:09 PM, Eran Hammer-Lahav wrote: (The previous thread is became completely inaccessible to anyone not following it carefully for the past week or so. For the sake of reaching a conclusion, I am going to sum up the issue and try to start over with a more narrow focus.) * The security issue is very simple: The authorization code is the only artifact binding the resource owner granting access at the authorization endpoint to the resource owner being redirected back to the client. OAuth 1.0a added the verification code for this sole purpose. If the authorization code is intercepted by a MITM (e.g. fake airport wifi), the attacker can take over the session and pretend to be the real resource owner. Since the client has no way to detect this, it will grant the attacker access to the client application which usually includes data obtain via the access token (received using the compromise authorization code). The attack does not give the attacker any direct access to the access token, the client credentials, or anything other than the client application itself. However, the client application is typically considered an extension of the resource server. Another variation of this attack is related to the implicit grant (user-agent flow). If a MITM can intercept the response in figure 4 step E, it can manipulate the script to obtain the access token (and any secret or other properties is included). In other words, the client redirection URI must use a secure channel to completely prevent these issues. However, it is important to note that this is not OAuth specific. It is a general security concern regarding all other aspects of the client if it is not fully secure. For example, if the client uses insecure cookies or provides authentication via other means not using TLS. If the client is insecure, well, it's insecure including its OAuth redirection endpoint. * The two solutions The debate is which of the following two language alternative we want to include in the specification: 1. Include a normative MUST use TLS for the client redirection URI endpoint. WITH the exception that if the redirection URI is local, the redirection only has to be passed back to the user-agent securely. There is NO need for the client app to implement server-side TLS. This is an important exception and makes 1 specific compared to 2 (too broad). 2. Include a normative SHOULD use TLS for the client redirection URI endpoint with strong language explaining the various attacks possible if the endpoint is not made secure. Both options reflect the same security issue, but *communicate* the *same* solution differently. Since this is just a specification (no standard police), this is just a manual, not an actual defense. Totally disagree. --- You can stop reading here if you are short on time. This should give you all the information you need to know --- * The difficulty There is no debate that this is a valid security concern, and that the only solution is to apply a MITM protection (i.e. TLS). However, given the current web landscape and OAuth history (or any other web API), requiring TLS is an unexpected change to the *ecosystem*. From unofficial discussions I had with Yahoo!, Facebook, and Google today, all three indicated they have no plans to enforce such a restriction. None of the major OAuth 1.0 providers today enforce such a requirement, even though the exact same issue is present in OAuth 1.0a. The challenge is to find the right *language* balance between reflecting reality and reflecting the ideal security configuration. This is not a question of what is appropriate in certain situation, or the unique attack vectors of individual deployments. It is about how we talk about security, and how to best push the web towards better security without pushing too hard too fast. To me, the challenge is how to effectively communicate the issue, without forcing companies to knowingly violate the specification. The problem with that is that experience shows it's a slippery slope. Once you are no longer fully compliant, it is easier to let other MUSTs slide. In the consumer web space - which originated and is still the primary audience for this work (no matter how much the enterprise folks here protest) - enforcing such a requirement on client developers is impractical. Very few providers can afford to alienate their developers by making such a requirement today. It will also completely undo all the other work done to make this specification more accessible and easier to deploy. Hands down, deploying server-side TLS is much harder for client developers than figuring OAuth 1.0 signatures. EHL Respectfully, -1 It may be true for the current group of social media apps using OAuth that the biggest risk is someone making a practical joke update. For that, your corporate management obviously don't see the value of protecting their customers. They've stated this publicly many times (directly and indirectly). Completely understandable and I would agree on their position for just the moment. BUT, for those of you getting into gradually more personal information and getting into real financial and legal consequences, I'm betting your risk profiles are already changing dramatically. Many on the list in a couple short years have stated that TLS is now no big deal. So why kill security now? TLS and OAuth are likely THE back bone of REST services going forwards. Why doom the specification now? For the vast quantity of new adopters, such as business, financial, telecom, medical, etc, this would be a MAJOR deviation from basic security practices. Let me put it this way, would you want your broker company using OAuth without MITM protection? If so, I'll be happy to meet with you in a local coffee shop some time. :-) None of this should be new to anyone. This is hardly idealism. The bottom line, and I do apologize, but the fact is that the current spec won't stand up to security review and that puts a total road block out there against using OAuth at this time. My apologies to the list. I've sent far far too many messages detailing the importance of this issue. Let me know what the group consensus is. I'm prepared to work for, as Eran puts it, "an idealistic" fix or drop it. _______________________________________________ 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
