Skylar, > I'm going to summarize (hopefully faithfully) the attacks > referenced here, with the hope of attempting to sum up the > scope of attacks being documented.
Thank you for reading and summarizing the attacks. > On Apr 1, 2011, at 1:29 PM, Francisco Corella wrote: > > > Skylar, > > > > > Right, but just so we are clear, the only case you are > > > discussing here is the MITM attack, which George, I and > > > others have recently outlined. > > > > There several flavors of MITM attacks, and a passive attack. > > See > > This document describes the MITM attack, similar to the one > I just described. Furthermore, it goes on to describe the > vulnerabilities of users on unsecured or public networks > (particularly WiFi and malicious rouge WiFi access points) > to MITM attacks. > > > http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html, > > This document references the above attack, but emphasizes > the risk to applications using a provider service for > Authentication who also fail to secure their application > (including redirect) with TLS. > > > http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html, The difference between 4894 and 4900 is that, whereas in 4900 the attacker intercepts the authorization code, as we've been discussing, in 4894 the attacker interecpts a session cookie. But yes, both are attacks against the same callback endpoint unprotected by TLS. > This document briefly describes attacks from the first > document and mentions also a "passive" attack where the > attacker "sniffs" the auth code rather than performing a > MITM attack. The attack can only be successful if providers > fail to revoke tokens/sessions for which the provider sees a > replay of auth codes. When the same authorization code is received twice, the specification suggests revoking the access token that was issued first. If the suggestion is followed, the attack is most likely to succeed. > However, for all implementations > (again, assuming no TLS on the callback) it can "annoy" the > user by disrupting or breaking their sessions by use of > auth-code replay. > > > and the last two paragraphs of page 4 of > > http://pomcor.com/techreports/DoubleRedirection.pdf. > > So for all attacks, I assume you would agree that risk is > all but mitigated for applications running on a trusted > corporate intranet (where Bob and client C are within the > corporate intranet) Placing all participants within a corporate intranet does not by itself mitigate the attacks, unless you assume all intranet users are trusted. But that may not be case. The WiFi attacks that I described can be mounted against an intranet from a company parking lot. > or VPN on a public network. In this > case, there would be no risk of MITM attacks unless the > corporate network itself was compromised (in which case, the > victim may have larger issues). Also, for the "cafe attack" > the risks would be nominal for users accessing the public > service through a protective VPN (in which case the MITM > attack would be much more expensive/difficult). Would requiring use of a VPN be less of a burden than requiring TLS for the callback endpoint? Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
