Re: [OAUTH-WG] Report an authentication issue

[Hannes Tschofenig <[e-mail]>]

Hi Adam, 

It takes a document to add new functionality to Oauth. Just write one and
submit it to the group.

Ciao
Hannes


On 6/21/12 7:01 PM, "ext Lewis Adam-CAL022"
<[e-mail]> wrote:

> Hi Nat,
>  
> I¹m beginning to wonder what it would take to add a new profile of sorts to
> either OAuth or Connect.
>  
> In the beginning there was SOAP, and the preferred method to secure SOAP API
> calls was WS-Trust.
>  
> Now the world is moving toward RESTful APIs Š and the preferred means to
> secure RESTful APIs is OAuth.
>  
> Except that OAuth is clearly written with the idea that the protected
> resources belong to the end user.
>  
> My use cases ­ and I imagine the use cases of many other enterprises ­ is that
> the Owner of the resources is the Enterprise.  An employee is trying to access
> a database or video resources.  The enterprise RS needs to be able to 1)
> identify the user, and 2) make authorization decisions based on what roles
> that user has within the enterprise.  So in my scenario, when a police officer
> attempts to access a criminal records database, the database needs to know who
> that officer is, and then decide if they have privilege to access the
> database, and at what level (e.g. CRUD).
>  
> WS-Trust fits this model well.  The user performs primary authentication to
> the enterprise STS, which then grants the application client a SAML assertion.
> When the user attempts to access a records database, the SAML assertion is
> included in the SOAP message.  The records server authenticates the user based
> on the SAML assertion and makes its authorization decisions.
>  
> This is the world I¹m trying to migrate from, and it really seems like I¹m
> sometimes trying to make a square peg fit in a round hole.  I¹m looking for
> OAuth/Connect to do for REST what WS-TRUST did for SOAP.  I would like a
> native client talking to a RS to be able to ask for an id_token, and then pass
> that id_token to the RS when making its RESTful API calls, to enable the RS to
> authenticate the user.  I think that this would be really useful for a lot of
> people besides me.  I keep hearing that there is nothing ³preventing² me from
> doing this Š but it hardly seems within the spirit of what OAuth was meant to
> do.  The id_token was clearly meant to enable a user to authenticate to a
> confidential client  / web server Š but was not meant for a native client to
> identity / authenticate the user to a RS.
>  
>  
> Would there be any interest in exploring this further?
> -adam
>  
>  
> 
> From: Nat Sakimura [mailto:[e-mail]]
> Sent: Wednesday, June 20, 2012 8:09 PM
> To: Lewis Adam-CAL022
> Cc: [e-mail]; [e-mail]
> Subject: Re: [OAUTH-WG] Report an authentication issue
>  
> Yes, OAuth can be profiled to enable authentication.
> 
> In fact, initial draft of OpenID Connect was just like you described.
> 
> Essentially, we were using structured access_token.
> 
> Later, we decided to separate the access token and id_token for several
> reasons such as: 
> 
>  
> 1. Better interop with existing OAuth implementations: by introducing
> id_token, they do not need to touch the supposedly opaque (which means AS-RS
> may be doing some proprietary thing inside it) access token.
> 2. Mixing up the audience (for id_token aka authn = client, and for
> access_token aka authz = resource server) probably is expanding the attack
> surface for security and privacy.
> Although we separated them out, a signed id_token includes the left hash of
> access_token so access_token is also protected.
> 
>  
> 
> Best, 
> 
>  
> 
> Nat
> 
>  
> 
> On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022
> <[e-mail]> wrote:
> 
> Hi Igor,
>  
> As Justin just pointed out, consider the case where the video server is hosted
> by the state (e.g. California) and is accessed by police agencies in Los
> Angeles, San Francisco, and San Diego.  The State of California¹s video server
> is the RS.  Each local police agency (LA/SF/SD) hosts an AS.  So when a police
> officer from LAPD launches the video client app on the iPhone, the client
> makes an OAuth request to the LAPD¹s AS, which authenticates the police
> officer using agency level credentials.  The access token issued to the video
> client app on the iPhone is a JWT, signed by the agency AS, which might look
> something like this:
>  
> {³typ²:²JWT²,"alg":"ES256"}
> {"iss":"https://as.lapd.california.gov",
>   "prn":"[e-mail]",
>   "aud":" https://[e-mail]",
>   "iat":1300815780,
>   "exp":1300819380,
>   "acr":²password²}
> hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P5
> 3BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7kl
> Iz3RqVL+wNmeWI4=
>  
> The JWT might be optionally encrypted using JWE.
>  
> I think what is becoming clear (and this is what I¹m trying to vet) is that
> while there is nothing in OAuth that specifies authentication, it *can* be
> used for Authentication, if done in the way that I describe.  If I¹m wrong
> about this, I really need to know.  I¹ve vetted this idea of mine with quite
> of few people now ­ both within context of the list and off-line ­ and I think
> I¹m okay. If you see any holes in what I describe, please point them out as I
> would prefer to uncover them now rather than after implementation or
> deployment!
>  
> Essentially I¹m using OAuth as a RESTful version of WS-Trust, where my client
> can exchange primary credentials for a token (JWT) and present that token to a
> server as secondary authentication.  It¹s just that it¹s RESTful instead of
> SOAP :-)
>  
> As Justin as pointed out Š I¹ve basically made the access-token look like the
> id_token of Connect.  I was actually hoping to lay a path to Connect, and use
> the id_token Š until it was also pointed out that the id_token is really meant
> for the consumption of the client, not the RS :-(
>  
>  
>  
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Igor
> Faynberg
> Sent: Wednesday, June 20, 2012 2:39 PM
> To: [e-mail]
> 
> 
> Subject: Re: [OAUTH-WG] Report an authentication issue
>  
> But this use case  does need OAuth, period:
> 
> 
> 
> The video server is under the control of a police agency, and police officers
> must logon to the video server in order to access video content.
> 
> There is no delegation here, and there is no need to use third party for
> authentication. 
> 
> Igor
> 
> On 6/20/2012 3:26 PM, Justin Richer wrote:
> 
> In case it wasn't clear, I want to restate the original problem as best as I
> understand it in a way that hopefully clears it up:
> 
> App A and app B are both valid registered OAuth clients to an OAuth protected
> service. 
> 
> The problem starts when app A gets handed a token that was issued for app B
> and uses it to call an identity API on the OAuth service. Since app B can get
> tokens just fine, they're bearer tokens, this is a fairly basic api call, this
> function works just fine and returns the user info. This makes sense, since
> anyone who holds A's tokens can do whatever A can do on behalf of that user.
> The issues start when app B then decides that since they can make a call to
> the identity API with a token then the user *must* be present. In other words,
> app B is confusing authorization to call an API with authentication of the
> session.
> 
> OpenID Connect fixes this missed assumption by binding the ID Token to the
> session and sending it along side the access token, but as you pointed out,
> it's meant for consumption at the client, not the resource server, in general.
> That doesn't mean you can't send it to a resource server for your own
> purposes, of course. That's actually how the session management endpoint works
> in Connect.
> 
> This isn't the only way to handle this problem -- if you put some structure in
> your tokens, such as with JWT or SAML, then app A can tell that this isn't a
> token issued to app A, but to app B, so it can call shenanigans and reject it
> then and there.
> 
>  -- Justin
> 
> On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote:
> I am entirely confused.
>  
> I understand what everybody is saying for confidential clients, no problem
> here.
>  
> I fall apart when thinking of iPhone apps.  Consider the scenario where I
> deploy a video server, and write an iPhone app to talk to the video server.
> The video server is under the control of a police agency, and police officers
> must logon to the video server in order to access video content.  So the
> police office launches their iPhone video client app.
>  
> If I wanted to solve authentication using ³traditional² client-server
> authentication, the user enters their username / password into the client, and
> the client sends the username / password off to the server, which
> authenticates it, or possibly uses HTTP digest.
> 
> If I wanted to use OpenID, the client would attempt to reach the video server
> (RP), the server would redirect the client to the OP, OP authenticates user,
> and OP redirects client back to the server/RP with an assertion that primary
> authentication was successful.
> 
> If I wanted to use OAuth, the client would send an authorization request to
> the server¹s AS, which would authenticate the user of the client, and
> ultimately result in the client possessing an access-token.  My thinking is
> that this access token (let¹s assume it¹s a JWT) would contain the user¹s
> identity, a statement of what type of primary authentication was used (auth
> context), an expiration, and an audience claim.  This sounds a lot like
> authentication to me, and it¹s where I get confused.  Is it just because OAuth
> does not explicitly define this?  Is there a threat in using OAuth as I
> describe? 
> 
> If I wanted to use Connect, well I¹m not even sure how the id_token as defined
> by Connect helps this use case.  The id_token seems to make sense when the
> client is a confidential web server, but it¹s not clear what an iPhone app
> would do with the id_token Š it¹s the server in the backend that needs to
> authenticate the user, the iPhone app is just an interface to talk to the
> server.  And it seems as I learn more about connect that the id_token is not
> meant to be sent from the iPhone app to the server, just the access token.  So
> it¹s really not clear how Connect helps solve authentication for an iPhone
> client app talking to a video server.  If I¹m sending access-tokens, it¹s just
> OAuth again.
> 
>  
> What am I still missing?
> adam
>  
>  
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Kristofor Selden
> Sent: Saturday, June 16, 2012 11:33 AM
> To: nov matake; oauth
> Cc: Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
> Subject: Re: [OAUTH-WG] Report an authentication issue
>  
> 
> Nov demonstrated the problem to us at Yapp and we used solution 4 (because the
> solution is server side and our app was in the app store).
> 
>  
> 
> FB Connect is authentication and authorization, where OAuth 2 is concerned
> only with authorization ­ I'm not sure that app developers appreciate this
> subtlety.
> 
>  
> 
> With OAuth 2 you authorize an app to use a protected resource.  With FB
> Connect, you do that, but also authenticate with the app you are authorizing.
> 
>  
> 
> So the access_token protects not just the FB resources but the auth end point
> of the authorized app (very common with apps that use the iOS SDK).  So now
> the app needs a way to verify that it was the app that was authorized to FB.
> 
>  
> 
> Solution 4 explanation: on FB you can register a iPhone app and a server app
> with the same client_id and get a client_secret for use on the server.  The
> server side API posts the access_token, client_id, and client_secret to
> https://graph.facebook.com/app
> <https://graph.facebook.com/app?access_token=YOUR_TOKEN>  to verify that the
> bearer token actually belongs to the app that is being authenticated before
> assuming they are authorized to the app's protected resources.
> 
>  
> 
> Kris
>  
> 
> On Jun 15, 2012, at 8:22 PM, nov matake wrote:
> 
> 
> There are 4 ways to fix this issue.
> 
>  
> 
> 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems best
> way for interoperability)
> 
> 2. Use singed_request (or some signed token like JWT)
> 
> 3. Use grant_type=fb_exchange_token (Facebook custom way)
> 
> 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN (Facebook
> custom way, moreover undocumented API)
> 
>  
> 
> Two iPhone app developers I reported this issue fixed it by using (4).
> 
>  
> 
> I also tried to use (1) for my own iPhone app implementation, but
> unfortunately it doesn't work when using authorization codes obtained via FB
> iOS SDK.
> 
> So I'm using (3) in my case.
> 
>  
> 
> nov
> 
>  
> 
> On 2012/06/16, at 9:16, Nat Sakimura wrote:
> 
> 
> 
> As to how the fix was done, Nov can provide more detail, but ...
> 
>  
> 
> 1. Properly verify the signature/HMAC of the "signed_request". This will
> essentially audience restricts the token.
> 
> 2. There is an undocumented API for Facebook which returns to whom the token
> was issued. This also audience restricts the token.
> 
>  
> 
> The service that fixed took these measures. Note that none of the above is
> defined in OAuth.
> 
> The same facility was called "id_token" and "check ID endpoint" for OpenID
> Connect. 
> 
>  
> 
> The scale of the impact is large, too large to disclose the actual names in
> the public list, though, eventually, we would publish them in a paper.
> 
>  
> 
> Nat
> 
> On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <[e-mail]>
> wrote:
> 
> Hi Nat and Rui,
> 
> Rui, you say that the vulnerability that you found was due to a
> "common misunderstanding among developers", but the attack you
> describe can be carried out against any app that uses the OAuth
> "implicit grant flow", which Facebook calls "client-side
> authentication".  No misunderstanding seems necessary.  What
> misunderstanding are you referring to?  I followed the link in your
> message to the Sophos post, and from there the link to the article in
> The Register.  The article in The Register says that Facebook had
> "fixed the vulnerability promptly".  How did they fix it?  The
> instructions that Facebook provides for implementing "Client-side
> authentication without the JS SDK" at
> https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
> still allows the attack.
> 
> Nat, I agree that the blog post by John Bradley that you link to
> refers to the same vulnerability reported by Rui.  You say that some
> apps have issued a patch to fix it.  Could you explain what the fix
> was?
> 
> Francisco
>> 
>>  
>> 
>> 
>> From: Nat Sakimura <[e-mail]>
>> To: rui wang <[e-mail]>
>> Cc: matake nov <[e-mail]>; Yuchen Zhou <[e-mail]>; oauth
>> <[e-mail]>; Shuo Chen (MSR) <[e-mail]>
>> Sent: Thursday, June 14, 2012 1:50 PM
>> Subject: Re: [OAUTH-WG] Report an authentication issue
>> 
>>  
>> 
>> This is a fairly well known (hopefully by now) issue. We, at the OpenID
>> Foundation, call it "access_token phishing" attack these days. See:
>> http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
>> 
>>  
>> 
>> Nov Matake has actually built the code on iPhone to verify the problem, and
>> has notified bunch of parties back in February including Facebook and Apple.
>> We have the code that actually runs on a phone, and we have successfully
>> logged in to bunch of apps, including very well known ones. They were all
>> informed of the issue. Some immediately issued a patch to fix it while others
>> have not.  
>> 
>>  
>> 
>> The problem is that even if these apps gets fixed, the problem does not go
>> away. As long as the attacker has the vulnerable version of the app, he still
>> can impersonate the victim. To stop it, the server side has to completely
>> disable the older version, which means the service has to cut off many users
>> pausing business problems.
>> 
>>  
>> 
>> Nat
>> 
>> On Fri, Jun 15, 2012 at 2:18 AM, rui wang <[e-mail]> wrote:
>> 
>> Dear Facebook Security Team and OAuth Standard group,
>> 
>> We are a research team in Microsoft Research. In January, 2011, we reported a
>> vulnerability in Facebook Connect which allowed everyone to sign into
>> Facebook-secured relying parties without password. It was promptly fixed
>> after reporting.
>> (http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-pers
>> onal-data/)
>> 
>> Recently, we found a common misunderstanding among developers of mobile/metro
>> apps when using OAuth (including Facebook¹s OAuth) for authentication. The
>> vulnerability resulted from this misunderstanding also allows an attacker to
>> log into a victim user's account without password.
>> 
>> Let's take Soluto's metro app as an example to describe the problem. The app
>> supports Facebook Login. As an attacker, we can write a regular Facebook app.
>> Once the victim user allows our app to access her Facebook data, we receive
>> an access_token from the traffic. Then, on our own machine (i.e., the
>> "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to
>> insert the victim's access_token into the traffic of Facebook login. Through
>> this way, we are able to log into the victim's Soluto account from our
>> machine. Other than Soluto, we also have confirmed the same issue on another
>> Windows 8 metro-app Givit.
>> 
>> The Facebook SDK for Android apps
>> (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to
>> have the possibility to mislead developers too. At least, the issue that we
>> found is not clearly mentioned. In the SDK, we ran the sample code called
>> "Hackbook" using Android Emulator (imagine it is an attacker device). Note
>> that we have already received the access token of the victim user from our
>> regular Facebook app. We then inject the token to the traffic of Hackbook.
>> Through this way, Hackbook app on our own machine recognizes us as the
>> victim. Note that this is not a convincing security exploit yet, because this
>> sample code does not include the server-side code. However, given that we
>> have seen real server-side code having this problem, such as Soluto, Givit
>> and others, we do believe that the sample code can mislead mobile/metro
>> developers. We also suspect that this may be a general issue of many OAuth
>> implementations on mobile platforms, so we send this message to OAuth
>> Standard group as well.
>> 
>> We have contacted the vendors of the two vulnerable metro-apps, Soluto and
>> Gavit.
>> 
>> Please kindly give us an ack when you receive this message. If you want to
>> know more details, please let us know.
>> 
>> Best Regards,
>> Yuchen Zhou, Rui Wang, and Shuo Chen
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>>