[WG-UMA] Step 3

[Eve Maler]

This email closes my AI around providing explanations of the "step 3 problem". What I discovered, in short, was:

1. The only relevant emails I could find predate modern UMA. I could forward them, but believe they'll be more confusing than helpful, since they refer to ProtectServe-era terminology and OAuth 1.0-based solutions.

2. The problem I thought we had doesn't actually seem to be a problem. (This is a good thing.)

Here, therefore, is a fresh explanation of the situation and the problems related to step 3 that we still do have to solve. Special thanks go to Domenico and Christian, with whom I consulted over the last few days; Christian has agreed to provide a proposed spec solution for the "new" problems by Wednesday so that we can consider it in time for Thursday's telecon.

The problem we don't have (feel free to ignore if you don't care :-):

I misunderstood a written analysis of step 3 that was floating around, and I thought the requester needs to present its client credentials over and above the access token in step 3. The token or message might in fact be signed using the requester's client-of-AM credentials, but in fact it definitely doesn't provide its client-of-AM ID and secret in "clear text" parameters to the host (OAuth 2.0 draft 10 section 5 makes this clear). If it had to, this would be Bad because a host in a different administrative domain from the AM could then impersonate the requester at that AM for some other purpose. Mea culpa -- I'm sorry for having caused confusion!

The much more ordinary problems we do have:

OAuth separates the resource server and authorization server, but puts their trust relationship out of scope. UMA needs to solve some minimal set of requirements around establishing that trust relationship, such that an incorrect grant of access can "unroll" correctly to let the user take the proper party to court (to be blunt about it).

Imagine it like this: If a host gives access inappropriately to some requesting party, the user might first complain to the AM. If the AM can prove that it issued the access token correctly according to the user's policy (and the user turned out not to be at fault because she wrote the policy wrong), it will point the finger at the host. The host will need to show that it evaluated and validated the access token correctly and also correctly handled the surrounding circumstances of the token's presentation. If a malicious requesting party turned out to have wielded a token it had no right to, the user could attempt to seek damages against them. (And if the requesting party believed it was acting in good faith, it could try and sue its third-party requester app company on the side to recover damages.) Legal subteam members, feel free to comment...

So, in a nutshell, I would submit that the following security requirements obtain for the access token and the circumstances of its presentation (provable by the AM and/or the host as appropriate):

- Issued by the correct AM for that protected resource
- Has a scope that applies to that protected resource
- Is still valid (e.g., if it can expire)
- Was presented by "the same party" to which it was originally issued (to some degree of certainty)

I put together a few thoughts on solutions, but Christian's proposal will no doubt be better-formed and take into account the latest OAuth signature proposals. That last requirement is the hardest one, but I think it's tractable.

Feel free to blast away with any questions or comments, and expect to see more on this topic soon. Thanks,

Eve

Eve Maler
http://www.xmlgrrl.com/blog
http://www.twitter.com/xmlgrrl
http://www.linkedin.com/in/evemaler

_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

[Christian Scholz]

Hi!

Unfortuanately I am bit swamped again with work but I tried to at
least scribble it down:

http://openetherpad.com/uma

(see step 3 and the new questions below).

I left the signature stuff out though as I mostly delegated this to
OAuth ;-) The main points are:

- The Host only receives an access token the AM gave to the Requester
in step 2.
- The access token is bound to a scope and client (credentials) which
the Requester received when registering with the AM
- The Host will never see the client credentials. It will always ask
the AM if the access token (and eventually a signature from signing)
is correct.
- The AM will know if the access token has timed out
- The AM will not know though if the access token leaked from the
Requester to some other party (OAuth has the same problem though). It
should log IPs though. It should maybe also issue short lived tokens
if that's a fear so the Requester needs to ask again first.
- On token verification the Host will use it's own access token to do
so. Thus the AM knows the identity of the Host and the Requester in
that step.

For the requirements Eve mentioned I would like to have some more
detailed scenarios which describe what credential/token/... can be
misused how.

(and as we use OAuth we also automatically say "use SSL" so access
tokens should be safe on transfer. If it's stolen from the requester's
hard drive somebody could also steal the client credentials though)

I hope that helps! :-)

-- Christian

2010/9/7 Eve Maler <e...@xmlgrrl.com>:

--
Christian Scholz, COM.lounge GmbH, tel. +49 241 400 730 0, http://comlounge.net
Blog: http://mrtopf.de/blog, Twitter: http://twitter.com/mrtopf

Podcasts:
Der OpenWeb-Podcast (http://openwebpodcast.de)
Data Without Borders (http://datawithoutborders.net)
Politisches: http://politfunk.de/

[Eve Maler]

I haven't read the notes yet, but your email description sounds like it confirms my suspicions about how simple this can be... I will try and catch up more fully tomorrow afternoon, and hope everyone will take a look before Thursday. Thanks!

Eve

[Ganem Herve]

Hi,

> So, in a nutshell, I would submit that the following security requirements obtain for the >access token and the circumstances of its presentation (provable by the AM and/or the host >as appropriate):

...
...

> - Was presented by "the same party" to which it was originally issued (to some degree of certainty)

I am wondering What are the risks that need to be covered on that point?
- theft of the token during transmission?
- long term theft of the token before expiration and after delivery to the requester?
- requester finding an interest in voluntarily giving or selling his token to someone else?

Thanks
herve

[Christian Scholz]

Hi!

2010/9/8 Ganem Herve <Herve...@gemalto.com>

Hi,

> So, in a nutshell, I would submit that the following security requirements obtain for the >access token and the circumstances of its presentation (provable by the AM and/or the host >as appropriate):

...
...

> - Was presented by "the same party" to which it was originally issued (to some degree of certainty)

I am wondering What are the risks that need to be covered on that point?

I would be, too ;-)

 

- theft of the token during transmission?

I think SSL should handle that part for the basic use case. Or siging.

 

- long term theft of the token before expiration and after delivery to the requester?

Here short lived tokens might help.

 

- requester finding an interest in voluntarily giving or selling his token to someone else?

Again short lived tokens might help. But if the Requester is that evil it can also sell the information and not the token ;-)

My take on this is: Do what OAuth has and if stronger requirements arise when people test out UMA for real problems, then solve them.

-- Christian

[George Fletcher]

Another case for OAuth 2 token leakage is log files. Many sites allow/require the token to be an URL parameter. This parameter gets logged in the access logs and anyone with access to the access logs can get tokens for any individual. So while the token is protected via transfer by SSL, it isn't protected for it's lifetime.

This brings up another point in that many deployments terminate SSL at the edge of their network which means that the tokens are NOT protected by SSL once within the boundary of the company.

While for many social based use cases this is more than adequate, I'm not sure it will meet with the more strict requirements of higher value (financial) use cases.

Note that it might be possible to leverage magic signatures for signing messages between the Client and the Host, and then ensuring that the token identifies the client in some way that can be matched with the client magic signature. However, I'd need to do a lot more research to validate that possibility.

Thanks,
George

_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

[Christian Scholz]

Hi!

Thanks for those good points! Comments inline.

2010/9/8 George Fletcher <gffl...@aol.com>

Another case for OAuth 2 token leakage is log files. Many sites allow/require the token to be an URL parameter. This parameter gets logged in the access logs and anyone with access to the access logs can get tokens for any individual. So while the token is protected via transfer by SSL, it isn't protected for it's lifetime.

Ok, but this affects the Host then, right? So some admin at the host can look into the logfiles, get the access token and use it on some user's behalf. 

 

This brings up another point in that many deployments terminate SSL at the edge of their network which means that the tokens are NOT protected by SSL once within the boundary of the company.

While for many social based use cases this is more than adequate, I'm not sure it will meet with the more strict requirements of higher value (financial) use cases.

I guess, this also only affects the Host then as I assume that an HTTP client will have to initiate an SSL connection directly?

 

Note that it might be possible to leverage magic signatures for signing messages between the Client and the Host, and then ensuring that the token identifies the client in some way that can be matched with the client magic signature. However, I'd need to do a lot more research to validate that possibility.

me, too ;-) But I assume if the client secret goes into the signature and it's only known to the Requester then it should be ok. Then Requester and AM know the secret and the Requester can create the sig while the AM can verify it. But I really have to read up on this.

-- Christian

[Eve Maler]

On 8 Sep 2010, at 12:50 PM, Christian Scholz wrote:

Hi!

2010/9/8 Ganem Herve <Herve...@gemalto.com>

Hi,

> So, in a nutshell, I would submit that the following security requirements obtain for the >access token and the circumstances of its presentation (provable by the AM and/or the host >as appropriate):

...
...

> - Was presented by "the same party" to which it was originally issued (to some degree of certainty)

I am wondering What are the risks that need to be covered on that point?

I would be, too ;-)

I was talking to an attorney colleague today who -- believe it or not :-) -- advised me not to obsess too much about questions of how to apportion liability in such systems. But liability in case of an erroneous access grant was my motivation for this item: If the AM can be shown to have acted correctly (gave out a token correctly based on the nature -- types and strengths -- of any claims presented to it), and the host can be shown to have acted correctly (accepted a correct token presented correctly), attention would turn to the requester/requesting party.

 

- theft of the token during transmission?

I think SSL should handle that part for the basic use case. Or siging.

If SSL is used between AM and requester, and then between requester and host, then this should be sufficient except in the case of a malicious requester.

 

- long term theft of the token before expiration and after delivery to the requester?

Here short lived tokens might help.

Yes, this seems like the "cheapest" solution.

 

- requester finding an interest in voluntarily giving or selling his token to someone else?

Again short lived tokens might help. But if the Requester is that evil it can also sell the information and not the token ;-)

This is where a solution that doesn't rely entirely on the good will of the requester would be useful.  And IETF processes will, no doubt, require us to have a credible Security Considerations section

My take on this is: Do what OAuth has and if stronger requirements arise when people test out UMA for real problems, then solve them.

Where we can borrow from, e.g., OAuth signature practices, so much the better.

-- Christian

Oops, I just belatedly saw George's contribution to this thread. +1 to his points about exposure of tokens at rest and inside administrative domains; hopefully signatures can be one good technique to recommend for higher security, without our having to rely on them in the absolute simplest (and lowest-security) case.

Eve

[Christian Scholz]

Hi!

2010/9/9 Ganem Herve <Herve...@gemalto.com>

hi,

 

>> long term theft of the token before expiration and after delivery to the requester?

 > Here short lived tokens might help

Yes, but is this always possible? what if the requester is an application, and the token is embedded in it? (cf recent article on ars technica you pointed us to) . The cycle of validation, distribution of a new version of the application is way too long to enable the use of short live tokens.

The usual method to address the pb of  long term threat of a token is to make possible with  the token to create a challenge that only the owner of the token will be able to answer using a secret obtained by an out of band mechanism. (I mean not given with the token; ex: digital signature) . My understanding is that the problem here is the management of this secret (private key). is this right?

I guess what will be stored in the application is not the access token (as this is bound to a user which first has to agree on it being issued) but the client credentials. So this is the secret to protect and you are right that somebody can simply inspect the app and get it. And here I am also not sure on how much signatures might help because having the client credentials means to be able to create those signatures.

So I wonder if this problem can be solved at all. What do security gurus say? ;-)

The problem might also be bigger than with plain OAuth as there usually the user controlling the app is also the user who wants to give that app access to his own data. But in our case the Requester app is out of the user's control. Still he needs to consent to some app requesting access to his data though. But then again it can be any other app asking as well so some sort of social engineering needs to take place as well I guess. 

-- Christian

 

rgrds

herve

---

From: Eve Maler [e...@xmlgrrl.com]
Sent: 09 September 2010 05:47
To: Christian Scholz
Cc: Ganem Herve; wg-...@kantarainitiative.org UMA

Subject: Re: [WG-UMA] Step 3

[Ganem Herve]

hi,

 

>> long term theft of the token before expiration and after delivery to the requester?

 > Here short lived tokens might help

Yes, but is this always possible? what if the requester is an application, and the token is embedded in it? (cf recent article on ars technica you pointed us to) . The cycle of validation, distribution of a new version of the application is way too long to enable the use of short live tokens.

The usual method to address the pb of  long term threat of a token is to make possible with  the token to create a challenge that only the owner of the token will be able to answer using a secret obtained by an out of band mechanism. (I mean not given with the token; ex: digital signature) . My understanding is that the problem here is the management of this secret (private key). is this right?

rgrds

herve

---

From: Eve Maler [e...@xmlgrrl.com]
Sent: 09 September 2010 05:47
To: Christian Scholz

Cc: Ganem Herve; wg-...@kantarainitiative.org UMA

Subject: Re: [WG-UMA] Step 3

[Eve Maler]

Excerpting just a portion of this great discussion:

On 9 Sep 2010, at 1:08 AM, Christian Scholz wrote:

The problem might also be bigger than with plain OAuth as there usually the user controlling the app is also the user who wants to give that app access to his own data. But in our case the Requester app is out of the user's control. Still he needs to consent to some app requesting access to his data though. But then again it can be any other app asking as well so some sort of social engineering needs to take place as well I guess. 

I believe we do have a problem that's bigger than OAuth because of our interest in having truly autonomous requesting parties (it's not just "Alice again"). In the cases where it really is "person-to-self sharing", like the location services scenario (which I keep referring to as "OAuth-like"), I'm actually much less worried about the security on the requester side since Alice herself would normally have to log in to that requester app. My suspicion is that we'll end up with an UMA profiling of one or more OAuth client profiles that take this into account, and these can be kept appropriately simple.