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

Antonio Sanso <asanso@adobe.com> Thu, 21 June 2012 17:05 UTC

Return-Path: <asanso@adobe.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36921F875A for <oauth@ietfa.amsl.com>; Thu, 21 Jun 2012 10:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.998
X-Spam-Level:
X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D6bUDfQM1-y for <oauth@ietfa.amsl.com>; Thu, 21 Jun 2012 10:05:02 -0700 (PDT)
Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9073721F85E0 for <oauth@ietf.org>; Thu, 21 Jun 2012 10:04:51 -0700 (PDT)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKT+NULGgyqRSv/xqSSzHwnRWp4ajVkuUB@postini.com; Thu, 21 Jun 2012 10:04:57 PDT
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q5LH4hX9000488; Thu, 21 Jun 2012 10:04:43 -0700 (PDT)
Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q5LH4bYt007537; Thu, 21 Jun 2012 10:04:41 -0700 (PDT)
Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 21 Jun 2012 10:04:39 -0700
Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Thu, 21 Jun 2012 18:04:37 +0100
From: Antonio Sanso <asanso@adobe.com>
To: Eran Hammer <eran@hueniverse.com>
Date: Thu, 21 Jun 2012 18:04:35 +0100
Thread-Topic: [OAUTH-WG] proposal of a paragraph to add to the security considerations section
Thread-Index: Ac1Pz/A7LNaG+PzWSeKdTJkACLV6gw==
Message-ID: <059A62F5-A2F8-4274-A5A8-E36B5A9BBC78@adobe.com>
References: <854774286EF8A240BACC342973A86EAC016693D6@BL2PRD0310MB387.namprd03.prod.outlook.com> <484A13D0-7C9A-42CC-BB94-3657741834DE@ve7jtb.com> <82D95BA2-1697-4441-BBB3-B2AE480DC39E@gmail.com> <ABE3E533-3264-457C-8A57-1DDD6D27D3BA@ve7jtb.com> <EFBA9408-36A4-4205-AF87-207253B95FD4@gmx.net> <F6BD6460-15E7-440A-BD6F-B9C5A2B7EB92@ve7jtb.com> <0CBAEB56DDB3A140BA8E8C124C04ECA20107B405@P3PWEX2MB008.ex2.secureserver.net>
In-Reply-To: <0CBAEB56DDB3A140BA8E8C124C04ECA20107B405@P3PWEX2MB008.ex2.secureserver.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_059A62F5A2F84274A5A8E36B5A9BBC78adobecom_"
MIME-Version: 1.0
Cc: rui wang <wang63@indiana.edu>, Yuchen Zhou <t-yuzhou@microsoft.com>, "Shuo Chen \(MSR\)" <shuochen@microsoft.com>, Derek Atkins <derek@ihtfp.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jun 2012 17:05:05 -0000

Hi Eran,

as a potential user of the specification this is bit sad as well to hear.
If you really think this, being on of the editors, you might take a stab and trying to improve it (but I guess it is too late ....)

Regards

Antonio


On Jun 21, 2012, at 4:17 PM, Eran Hammer wrote:

The sad reality is, we've spent 3 years producing a specification that is less secure, more complex, and does not interoperate the way OAuth 1.0 does.

It does scale better for huge companies like Google, Microsoft, and Yahoo. No wonder they wanted it this way.

When asked, I tend to advise people using OAuth 1.0 to just keep using it.

Oh well.

EH

From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Thursday, June 21, 2012 6:47 AM
To: Hannes Tschofenig
Cc: rui wang; Yuchen Zhou; Shuo Chen (MSR); Derek Atkins; oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section

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:derek@ihtfp.com]<mailto:[mailto:derek@ihtfp.com]>
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)" <shuochen@microsoft.com<mailto:shuochen@microsoft.com>> 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 oauth@ietf.org<mailto:oauth@ietf.org> mailing list?

Thanks a lot.

-Shuo

-derek

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]<mailto:[mailto:Hannes.Tschofenig@gmx.net]>
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
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth