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

John Bradley <ve7jtb@ve7jtb.com> Thu, 21 June 2012 13:47 UTC

Return-Path: <ve7jtb@ve7jtb.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 9D26B21F8655 for <oauth@ietfa.amsl.com>; Thu, 21 Jun 2012 06:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.208
X-Spam-Level:
X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1]
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 Gesedbhg3ER3 for <oauth@ietfa.amsl.com>; Thu, 21 Jun 2012 06:47:38 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D03D821F8646 for <oauth@ietf.org>; Thu, 21 Jun 2012 06:47:37 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so527334ggn.31 for <oauth@ietf.org>; Thu, 21 Jun 2012 06:47:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=HfrJ9aMmvVEYSIJIEpkRtRoXVLcBadEtk8Wk+qv5W/E=; b=fYFz6nUdoJm4K5v1utx62hfKbOzV1Dm2/9aw86CgUKrt6pQ1AQ7xVhfwJ9NLllqPEq qkoBh7NQxBHPdmF+vFqsn14L55rMxWQ8yrJgdd/o9KgIUjyIqnQzjw87W8x/9qJxNdMS W5/zC+j08G4KU8O2lIUd+M2d7PVKA/n+RFbV1t4JEodFdoc6wlPjM4DOGSUZlcAQbZT7 NEtx5VNSkG8npC8kaS1NVkK9kP/ROPE8ikL8sERFrdCLQeIXSngV2OqNTexfeSCYFFuS pte03eiInMM+KfLYgZc+glTe3bokHUOKOVMxgPtzXdST+XZ6KtHxfMtvdWOjjW8luRSu vgKA==
Received: by 10.236.184.170 with SMTP id s30mr21531397yhm.122.1340286457265; Thu, 21 Jun 2012 06:47:37 -0700 (PDT)
Received: from [192.168.1.213] ([190.20.13.0]) by mx.google.com with ESMTPS id b58sm107396722yhh.16.2012.06.21.06.47.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jun 2012 06:47:36 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_F6FE03F2-F07D-428B-A233-4250B1F54163"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <EFBA9408-36A4-4205-AF87-207253B95FD4@gmx.net>
Date: Thu, 21 Jun 2012 09:47:23 -0400
Message-Id: <F6BD6460-15E7-440A-BD6F-B9C5A2B7EB92@ve7jtb.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>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1278)
X-Gm-Message-State: ALoCoQmN/UTvrR9lbFAnA9Nle66kb+Rjfhl3RN13nzSom55ez4+WbIUO7KilyCcMpO/J7s+X4rN9
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 13:47:40 -0000

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 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]
>>>>>> 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> 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 mailing list?
>>>>>> 
>>>>>>> Thanks a lot.
>>>>>>> 
>>>>>>> -Shuo
>>>>>> 
>>>>>> -derek
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Hannes Tschofenig [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
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>