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