Re: [OAUTH-WG] Report an authentication issue

[Torsten Lodderstedt <[e-mail]>]

Hi Adam,

what you describe is essentially a combination of 



Lewis Adam-CAL022 <[e-mail]> schrieb:

>Hi Torsten,
>
>Your option #2 below is the model I was first attracted to.  The
>architecture as you mention is clean.  But the need to run multiple
>round trips (one to get the SAML assertion, another to get the access
>token), plus the inherently large size of a SAML assertion (compared to
>an unstructured access token, or even a JWT), was producing too much
>latency.

Use OpenId Connect between IDPs and central AS.

>
>Hence I have moved my interest to option #1.  I think the easiest thing
>to do is have the user authenticate to the local AS, get in return a
>structured JWT access token (which will look a lot like the Connect
>id_token) and present that JWT access token to the RS in the different
>domain, and that RS will use that JWT access token to authenticate the
>user.  Ideally I would like to use the id_token from Connect, but I'm
>getting push back on that idea since the id_token has really been
>profiled for the client, not the RS.

You could even combine both ideas by using the central AS of option #2 as an intermediary. The local AS can issue a JWT token, which in turn is accepted by the central AS to authenticate the user. The JWT assertion profile can be used for that purpose. 

This is more or a less a I variant of my option #2. Instead of using SAML to transfer identity data from IDP to AS you use access tokens to do the same between your local AS (== IDP) and the central AS.

regards,
Torsten.

>
>-adam
>
>From: Torsten Lodderstedt [mailto:[e-mail]]
>Sent: Saturday, June 23, 2012 11:52 AM
>To: Lewis Adam-CAL022
>Cc: Nat Sakimura; [e-mail]
>Subject: Re: [OAUTH-WG] Report an authentication issue
>
>Hi Adam,
>
>let me explain why I don't see a need for a new profile.
>
>As far as I understand your scenario, you want to give users from
>different security domains access to the same RS.
>
>I see two ways to handle this without any need to extend OAuth:
>
>1) multiple AS (also performing authentication)
>
>You already mentioned this option. Every department runs its AS, which
>authenticates and authorizes access to the RS for the particular
>officer. As a pre-requisite, RS and ASs must use the same token design
>(self-contained vs. handle-based), token format (e.g. SAML or JWT) and
>the RS must _rely_ multiple ASs. This will be possible to implement
>with the drafts under consideration (namely JWT), but I consider this a
>substantial restrictions on the design of the RS!
>
>2) single AS relying on multiple IDPs for authenticaton
>
>The alternative is to let a dedicated AS issue the tokens for the
>central RS. This AS uses the IDPs of the different security domain for
>the purpose of authenticating the officers (e.g. using SAML or OpenID).
>The difference is that the RS only trusts this single AS, which is
>easier to implement because it is a nearly private relationship.
>
>best regards,
>Torsten.
>Am 21.06.2012 18:01, schrieb Lewis Adam-CAL022:
>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]<mailto:[e-mail]>;
>[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>",
>  "aud":" https://[e-mail]",
>  "iat":1300815780,
>  "exp":1300819380,
>  "acr":"password"}
>hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+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]>
>[mailto:[e-mail]<mailto:[e-mail]>] On
>Behalf Of Igor Faynberg
>Sent: Wednesday, June 20, 2012 2:39 PM
>To: [e-mail]<mailto:[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]>
>[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]<mailto:[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]<mailto:[e-mail]>>
>To: rui wang <[e-mail]<mailto:[e-mail]>>
>Cc: matake nov <[e-mail]<mailto:[e-mail]>>; Yuchen Zhou
><[e-mail]<mailto:[e-mail]>>; oauth
><[e-mail]<mailto:[e-mail]>>; Shuo Chen (MSR)
><[e-mail]<mailto:[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]<mailto:[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-personal-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]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>--
>Nat Sakimura (=nat)
>Chairman, OpenID Foundation
>http://nat.sakimura.org/
>@_nat_en
>
>
>_______________________________________________
>OAuth mailing list
>[e-mail]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>--
>Nat Sakimura (=nat)
>Chairman, OpenID Foundation
>http://nat.sakimura.org/
>@_nat_en
>
>_______________________________________________
>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
>
>
>
>--
>Nat Sakimura (=nat)
>Chairman, OpenID Foundation
>http://nat.sakimura.org/
>@_nat_en
>
>
>
>
>
>_______________________________________________
>
>OAuth mailing list
>
>[e-mail]<mailto:[e-mail]>
>
>https://www.ietf.org/mailman/listinfo/oauth