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.
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, 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. 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) 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). I'm not trying to downplay the validity of any of the attacks, I'm just trying to understand the cases being described and contexts which will most likely bring attacks to bear. I do feel like in most cases the security of the user's computer or the client app itself is more in question than the security of the redirect step (getting back to the difficult debate of scope/role of the OAuth spec). skylar _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
