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

[Hannes Tschofenig <[e-mail]>]

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]> 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] 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]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth