Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt

From: Francisco Corella <[email-masked]>
Date: Fri, 1 Apr 2011 10:29:20 -0700 (PDT)

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 
http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html,
http://www.ietf.org/mail-archive/web/oauth/current/msg04900.html,
and the last two paragraphs of page 4 of
http://pomcor.com/techreports/DoubleRedirection.pdf.

Francisco

---

From: Skylar Woodward <[email-masked]>
Date: Fri, 1 Apr 2011 21:07:12 -0400

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.

> There several flavors of MITM attacks, and a passive attack.

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.

> 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

---

From: Phillip Hunt <[email-masked]>
Date: Fri, 1 Apr 2011 19:23:37 -0700

Sorry. I forgot to add it becomes a race if and only if the TS is smart enough to invalidate code after first use. 

Phil

Sent from my phone.

---

From: Francisco Corella <[email-masked]>
Date: Sat, 2 Apr 2011 08:32:15 -0700 (PDT)

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.

> 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.
> 
> 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.
> 

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.
> 
> 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

---

From: Dick Hardt <[email-masked]>
Date: Sat, 2 Apr 2011 08:55:16 -0700

As has been pointed out in the discussions, if a website does not employe TLS on connections on other connections, having TLS on the redirect does not add security.

Depending on the resource grant being given, the nature of the website, not running TLS may be an acceptable security tradeoff. No being an IETF security expert, I don't have an opinion on MUST or SHOULD language for TLS on the redirect.

This tradeoff should be well documented in the security considerations, and this language I feel strongly should be in the core spec so that implementors understand the risk.

Examples where this is an acceptable tradeoff could be where access to the resource is read-only, and the resource is publicly available information. In this case, the resource is enabling the contextually useful information for the user. A specific example of this would be blog comments.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 2 Apr 2011 09:41:16 -0700

Another example I mentioned earlier is when the client does not expose the protected resources back to the bearer of the code. For example, a Twitter application sending you emails when someone stops following you. Since all it does is get the code and then uses it internally (no user login functionality), TLS adds NOTHING.

In practice, the MUST use TLS is not really about the redirection endpoint, but about ANY client endpoint used for user authentication (which is what the code is used in all these attacks). A MUST means we take a stand on the one such endpoint that is within our scope, but it doesn't, by itself, offers full protection of the protected resources granted if the client doesn't match that security level to the redirection endpoint.

The only way to enforce that is with client certification by the authorization server vendor - something that is just completely impractical in the consumer web space. For example, Citibank can audit (well, pay someone to) Intuit tax products if they give them OAuth access, to make sure the entire tax product uses TLS without any exceptions (sometimes, a contract with a big liability sum will work too).

I am not expressing a position here, just want to make sure people understand that regardless of using a MUST or SHOULD language in the document, the complete security picture of the client matters much more.

EHL

> -----Original Message-----
> From: Dick Hardt [mailto:[email-masked]]
> Sent: Saturday, April 02, 2011 8:55 AM
> To: Francisco Corella; Eran Hammer-Lahav; Skylar Woodward; Phillip Hunt
> Cc: OAuth WG
> Subject: to TLS or not on redirect on consumer websites :: security
> considerations
> 
> 
> As has been pointed out in the discussions, if a website does not employe
> TLS on connections on other connections, having TLS on the redirect does not
> add security.
> 
> Depending on the resource grant being given, the nature of the website, not
> running TLS may be an acceptable security tradeoff. No being an IETF security
> expert, I don't have an opinion on MUST or SHOULD language for TLS on the
> redirect.
> 
> This tradeoff should be well documented in the security considerations, and
> this language I feel strongly should be in the core spec so that implementors
> understand the risk.
> 
> Examples where this is an acceptable tradeoff could be where access to the
> resource is read-only, and the resource is publicly available information. In
> this case, the resource is enabling the contextually useful information for the
> user. A specific example of this would be blog comments.

---

From: Francisco Corella <[email-masked]>
Date: Sat, 2 Apr 2011 11:13:45 -0700 (PDT)

> Another example I mentioned earlier is when the client does
> not expose the protected resources back to the bearer of the
> code. For example, a Twitter application sending you emails
> when someone stops following you. Since all it does is get
> the code and then uses it internally (no user login
> functionality), TLS adds NOTHING.

I'm not sure I understand the example.  Would the attacker
be able to get emails when someone stops following the user?
Would that be OK?

Anyway, an application that accesses Twitter on the user's
behalf is likely to be able to send tweets on the user's
behalf.  The attacks we've been discussing would allow the
attacker to send tweets on the user's behalf.  That's
definitely not cool.

User impersonation when Oauth is used for social login is
not the only consequence of not requiring TSL for the
callback endpoint.

Francisco

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 2 Apr 2011 12:06:54 -0700

> From: Francisco Corella [mailto:[email-masked]]
> Sent: Saturday, April 02, 2011 11:14 AM
> To: Dick Hardt; Skylar Woodward; Phillip Hunt; Eran Hammer-Lahav
> Cc: OAuth WG; Karen P. Lewison
> Subject: RE: to TLS or not on redirect on consumer websites :: security
> considerations
> 
> > Another example I mentioned earlier is when the client does not expose
> > the protected resources back to the bearer of the code. For example, a
> > Twitter application sending you emails when someone stops following
> > you. Since all it does is get the code and then uses it internally (no
> > user login functionality), TLS adds NOTHING.
> 
> I'm not sure I understand the example.  Would the attacker be able to get
> emails when someone stops following the user?
> Would that be OK?

No. The attacker will accomplish nothing other than to finish the flow on behalf of the legitimate user.

1. User is asked for email where to notify
2. User is redirected to Twitter to grant access
3. Someone comes back to the client with a valid code
4. Client uses code to get an access token and does not expose any data to the entity delivering the code

> Anyway, an application that accesses Twitter on the user's behalf is likely to
> be able to send tweets on the user's behalf.  The attacks we've been
> discussing would allow the attacker to send tweets on the user's
> behalf.  That's definitely not cool.
> 
> User impersonation when Oauth is used for social login is not the only
> consequence of not requiring TSL for the callback endpoint.

The only consequence is compromising the *client* login/authentication security. I'm not trying to play it down, but I we need to be clear. This is not a compromise of the protected resources or authorization server.

In your examples, it is done via stealing the authorization code. In other examples (due to the same lack of TLS security on the client) it is due to setting insecure session cookies. Any kind of incomplete client security is bad and will produce the exact same attack opportunities if it enables a MITM to interject itself into any of the client's login or authentication flows.

IOW, for this security hole to be closed, clients MUST use TLS throughout the entire site, not just their redirection. You are demanding that the entire web moved to use TLS for all login and authentication of bearer credentials. That's a good goal, but the issue at hand is not whether the attacks are valid - they are. It is only what is the best LANGUAGE to use in order to move the web forward.

Your solution is to force offenders to explicitly violate the protocol, but other's suggesting a more relax approach will produce the same result over time. The problem with your approach is that it already failed. Enough high profile companies on the consumer web front have said that they plan to ignore this MUST. I think it is much better for the future of web security for this document to reflect reality and find more productive ways to impact change.

EHL

---

From: Dick Hardt <[email-masked]>
Date: Sat, 2 Apr 2011 17:03:13 -0700

> be able to get emails when someone stops following the user?

I can do that without any authorization from the user. 

> attacker to send tweets on the user's behalf.  That's

Maybe you should stop using Twitter as anyone that can MITM your session can tweet as you since Twitter does not enforce HTTPS on twitter.com

Am I missing something in your statement? ... or did you respond without thinking this through?

-- Dick

---

From: Francisco Corella <[email-masked]>
Date: Mon, 4 Apr 2011 17:47:45 -0700 (PDT)

Eran,

> The only consequence is compromising the *client*
> login/authentication security. I'm not trying to play it
> down, but I we need to be clear. This is not a compromise of
> the protected resources or authorization server.

We are definitely talking about a compromise of the
protected resources.  The attacker can access the protected
resources through the client.  And George Fletcher described
an attack variant where the attacker does that without
logging in as the user.

Francisco

---

From: Francisco Corella <[email-masked]>
Date: Mon, 4 Apr 2011 17:49:54 -0700 (PDT)

Dick,

> Maybe you should stop using Twitter as anyone that can MITM your
> session can tweet as you since Twitter does not enforce HTTPS on
> twitter.com

Thanks for pointing that out.  I haven't looked at the security
posture of Twitter, I just mentioned Twitter because Eran did.  The
point I was trying to make is that unauthorized write access to
protected resources (e.g. sending tweets or updates) can do as much
damage as unauthorized read access.

Francisco