Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section

[Eran Hammer <[e-mail]>]

You must be joking. Have you ever read the spec?

It has been there from draft -00:

http://tools.ietf.org/html/draft-ietf-oauth-v2-00#section-3.5.1

EH


From: [e-mail] [mailto:[e-mail]] On Behalf Of Dick Hardt
Sent: Saturday, June 23, 2012 8:15 PM
To: John Bradley
Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; [e-mail]
Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section

Would someone enlighten me on why the implicit flow is needed? Is it the extra round trip? If so, I think that would be useful to call out both the advantages and disadvantages in the spec. (I did not realize this flow was in OAuth -- it was not in WRAP because of the security issue)

-- Dick

On Jun 23, 2012, at 11:54 AM, John Bradley wrote:


Yes it is probably best to keep it short in the main spec, but go into more detail in the security document.

OAuth is fine as it is.  If you use OAuth as part of another protocol that protocol should be taking responsibility for it's own security considerations and not assuming that OAuth will cover everything you are doing.

Like it or not once you do federated authentication with OAuth you have created a different protocol that needs different security considerations.

We all sort of know that, the problem is that some people confuse authentication and authorization as the same thing, so it is worth point ing out.

John B.

On 2012-06-23, at 2:24 PM, Torsten Lodderstedt wrote:


Hi John,

I fully agree with your assessment. This attack utilizes the fact that some clients rely on the result of a resource server request to login an user. It is not an attack on the OAuth protocol. And even if a similar attack on authorization codes will happen to fail for confidential clients does not mean OAuth is supposed to solve this problem.

We nevertheless should mention it in the security considerations section. To make things simple, I suggest to describe and ban this anti-pattern _in general_ in the security consideration section (similar to Shuo's initial proposal but more generalized). Additionally, the text should recommend to use an appropriate technique for id providing such as OpenID or SAML.

We also could add a detailed analaysis to the security document.

best regards,
Torsten.

Am 21.06.2012 15:47, schrieb John Bradley:
Hi Hannes,

MAC tokens protect resources against token leakage to third parties.  That is useful but a different threat.

The easiest way to get a access token for someone is to have them log into your site.

If you can do that the token type makes no difference unless we move to a asymmetric holder of key token (different discussion).

The bad client gets the access MAC token and token secret and can re use it just as it would a bearer token.

The origin of the post was a contention by someone at Facebook that profiling OAuth 2.0 on its own is sufficient to produce an Authentication protocol.

I was trying to point out that OAuth 2 without any extensions, only profiling is difficult to impossible to use for authentication as the attack surface and security considerations are different.

As it turned out Facebook had extended OAuth 2 with signed requests and token introspection techniques to address these issues for themselves.

The problem as it turned out was that individual apps and  app frameworks like the iOS one made some bad mistakes, by not using the perhaps under documented extensions.

The problem is not unique to Facebook in any way they are just a convenient example.

Oauth 2  is not surprisingly mostly about protecting the resource.

Authentication is about protecting the client.

Audience restriction from openID 2, SAML,  WS* etc prevents replay of tokens issued to one RP/SP at another.
That is sort of authentication protocol threat number 1.

OAuth has no way to do that with access tokens.

It can however do it with "code" if the client is confidential.

So my recommendation is that without extensions to OAuth like structured tokens (signed_request, id_token) or token introspection endpoints like
Facebook ( https://graph.facebook.com/app?access_token=[The<https://graph.facebook.com/app?access_token=%5bThe> Access Token]), there is no safe way to use an implicit flow for authentication.
A code flow where a native app exchanges code for the access token and then passes the access token back to it's server is also vulnerable (lots of this in circulation I understand)

The only safe flow (without extensions) is the code flow where the client is confidential and the code is directly exchanged for the access token.
This also requires the definition of a identity API that is protected by the access token, and out of scope for OAuth.

So at the end of the day the rational conclusion is that OAuth 2 is a authorization protocol.
It may be used by Authentication protocols, but it is up to other specs to define the security considerations for that.

That however doesn't remove the need to mention the token substitution attack that non confidential clients are subject to, do to there being no other mechanism for the client to know who the token was issued to.

John B.





On 2012-06-21, at 5:27 AM, Hannes Tschofenig wrote:


Hi John,

I read through your blog post. I am not sure whether I can entirely agree with your separation between authentication and authorization. I believe the core issue here is that

* anyone who has the token will get access to whatever the token entitles him or her to do (unless there are restrictions in the token)

* some attributes are different than others. With authentication you typically associate that the process took place recently (i.e., it is fresh) while other attributes do not require the user (as resource owner) to actively participate in the exchange and the same level of freshness is not implied.  For authentication in a three party protocol to be useful the three parties have to participate (see http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt).

I understand that one wants to avoid having tokens passed around from one application to the other one, as it is happening here.

I remember having some of these discussions with Eran a long time ago. He anticipated that implementers will not put any constraints in the tokens and hence they will be misused. This serves as an argument for him to propose the MAC token specification.

I proposed text for the security consideration section of the bearer document a while ago and it even talks about audience restriction as a recommendation.

There are two problems with the audience restriction:

1) There is no mandatory token format defined nor do we mandate token content either. Hence we do not strongly require anything specifically to be put into the tokens.

2) In the implicit grant flow the client isn't authenticated and hence what do you want to put into a token as an audience restriction?

Finally, I think that the "audience restriction" terminology is a bit fuzzy for this discussion either.
Audience restriction can mean two things:

* Allowing the client to verify that the access token has indeed been issued for him / her.
* Allowing the resource server verify that the received access token from a specific client has indeed been provided by that client.

My current believe is that the implicit grant flow is unsuitable for providing authentication functionality.

Ciao
Hannes

On Jun 19, 2012, at 5:50 AM, John Bradley wrote:


I can put something together.

It is mostly a warning about the token substitution attack that any implicit flow is vulnerable to if used for authentication of the presenter.
Otherwise known as why audience restriction is a good thing.

John B.

On 2012-06-18, at 8:20 PM, Dick Hardt wrote:

John

Do you have suggested text per your suggestion below?

-- Dick

On Jun 18, 2012, at 2:04 PM, John Bradley wrote:

I blogged about this in the hypothetical several months ago. http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

Nov Matake and others built some tests and found quite a number of deployments vulnerable.
http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html

The bottom line is that OAuth has no explicit audience restriction for tokens,  hence accepting any token outside of the code flow is subject to attack.

In general it is not a issue for authorization,  it is however a big issue then there is a presumption that the presenter of a token that grants a client access to resource x is the "resource owner" of resource x, when it is possible that the presenter is any client who has ever had a access token for resource x.

We might want to include the why it is insecure in the security consideration,  otherwise people reading the below will likely ignore the advice as it seems on the surface a touch extreme.

There are certainly OAuth flows that allow you to do authentication safely,  just not all of them without additional precautions.

That is why openID Connect has a audience restricted id_token similar to Facebook's signed request to allow the implicit flows to be safely used for authentication.

John B.




On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:

Hi OAuth group,

This is regarding the recent discussion about an implementation issue of some cloud services using OAuth for authentication.
Derek Atkins and Dick Hardt suggested the possibility to discuss with the group a paragraph to add to the security considerations section.

Derek's suggestion:
====   ===  ===  ===
Perhaps you could boil it down to a paragraph
or two for addition to the security considerations section that basically says
"beware of implementing it *this* way because it leads to *that* attack vector", etc.
====   ===  ===  ===


Here is out suggested text:
====   ===  ===  ===
It has been observed that in multiple occasions that the server-side
authentication logic takes an access token from the client, then
queries the user's profile data from the IdP in order to
"authenticate" the user. This implementation must be forbidden. It
will allow an untrusted app running on a victim's client device to
work with an attacker's device to sign into the victim's account on the server side.
====   ===  ===  ===


Thank you.
-Shuo
p.s. below is the email thread giving a better context of the discussion.


-----Original Message-----
From: Derek Atkins [mailto:[e-mail]]
Sent: Monday, June 18, 2012 11:25 AM
To: Shuo Chen (MSR)
Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek
Atkins; Dick Hardt
Subject: Re: [OAUTH-WG] web sso study...

Hi,

"Shuo Chen (MSR)" <[e-mail]<mailto:[e-mail]>> writes:

Hi Hannes, Derek and Stephen,

Thank you for your replies.

First, let me ask whether it is OK if I share your post with the
OAuth WG

Yes, please feel free to share it.

Second, could you describe the attack in more details to me?

Let's consider the mobile+cloud scenario for concreteness (although
some other scenarios are also applicable). The attack steps are the
following: suppose Alice's tablet runs a Windows 8 Metro app written
by attacker Bob. This app is able to request and obtain an access
token from the IdP (associated with Alice). The app can then send the
access token to Bob's own tablet. Note that there is no security
problem up to this point. However the real problem is that some cloud
services use the access token to query the user's profile data from
the IdP in order to "authenticate" the user. In this case, Bob's
tablet will be able to sign into the cloud service as Alice. We have
confirmed that the cloud services for Soluto Metro App, Givit Metro
App and EuroCup2012 Metro App make this mistake. These are apps in
the official Windows 8 App Store. We actually sampled only a small portion of the available apps, but believe this is a vulnerability pattern.

We don't think there is anything wrong in the OAuth spec. It is
developers who didn't comprehensively understand the usage of the
access token. In the meanwhile, this vulnerability pattern is not explicitly excluded by the spec.
More importantly, it has been seen in the wild.

[from Derek's email] Perhaps you could boil it down to a paragraph
or two for
addition to the security considerations section that basically says
"beware of implementing it *this* way because it leads to *that* attack vector", etc.

This is a great idea. I think that although it is difficult to
anticipate in general all kinds of incomprehensive understandings of
average developers, it is very worthwhile to take any common existing
vulnerability pattern as a precious feedback to improve the
specification text. In this case, since we have already seen this
vulnerability pattern on multiple services in the wild, certainly we
should be explicit about it in the security considerations section.

Our suggested text:

It has been observed that in multiple occasions that the server-side
authentication logic takes an access token from the client, then
queries the user's profile data from the IdP in order to
"authenticate" the user. This implementation must be forbidden. It
will allow an untrusted app running on a victim's client device to
work with an attacker's device to sign into the victim's account on the server side.

Any questions or suggestions?

Could you please send this to the [e-mail]<mailto:[e-mail]> mailing list?

Thanks a lot.

-Shuo

-derek

-----Original Message-----
From: Hannes Tschofenig [mailto:[e-mail]]
Sent: Friday, June 15, 2012 11:36 AM
To: rui wang
Cc: Hannes Tschofenig; Stephen Farrell; Shuo Chen (MSR); Yuchen Zhou;
Derek Atkins
Subject: Re: [OAUTH-WG] web sso study...

Hi Rui,

let me independently respond (in addition to the previous responses
you had already gotten).

First, let me ask whether it is OK if I share your post with the
OAuth WG since it is more detailed than the one you distributed on the list mid April.

Second, could you describe the attack in more details to me? What I
would like to better understand whether this the raised issue is a
problem with one of our specifications, with a specific
implementation of the IETF OAuth specifications, a problem with other
OAuth related work (Facebook, as you know, implements far more than
just the IETF OAuth specifications), a violation of the IETF OAuth
specification in the way how the Websites use OAuth, whether this is
a configuration related aspect, or an aspect we already documented in the threats document.

The reason why I am so specific is to know where to put text to
address this issue or whether this is even an issue beyond the IETF
OAuth working group and needs to be tackled somewhere else.

Ciao

Hannes

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth






_______________________________________________

OAuth mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth