Subject: Re: [OAUTH-WG] [oauth] Re: Need for timestamp and nonce over HTTPS

From: Richard Barnes <[email-masked]>
Date: Mon, 5 Oct 2009 01:02:04 +0100

Hey James,

[copying IETF list since we're starting to get into protocol design stuff]

> Is there really a requirement to make sure a Consumer can't hand off the access token?

It's a question security requirements, i.e., what attacks the SP is
worried about, i.e., how strongly they want to protect their users'
data.  If they allow Consumers to hand off access tokens, then they're
opening themselves up to Consumers that hand off tokens to bad people.

> Of course, neither the Service nor the User can prevent the Consumer handing off the access token and Consumer credentials to another party.

That's true; the best a security protocol can ever do is reduce a
problem to the security of keys.  Usually this is enough, especially
if keys are hard for the Consumer to replace (e.g., if they're tied to
an expensive certificate).

> I am particularly interested as I believe request signing would be significantly improved if it only used the access token (and not the Consumer credentials). The Consumer is implied as they were authenticated when the access token was issued.

Again, it's a question of the SP's security requirements.  IMHO,
authenticating access requests makes for a more secure protocol with
not much more cost (the credentials are already there, since Consumer
already has to authenticate to the SP to get the request token).  But
YMMV.  Maybe we need an "OAuth Security Requirements" draft?  Or just
a rev/clarification to draft-barnes-oauth-model?

--Richard

>
>
> James Manger
> [email-masked]
> Identity and security team — Chief Technology Office — Telstra
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "OAuth" group.
> To post to this group, send email to [email-masked]
> To unsubscribe from this group, send email to [email-masked]
> For more options, visit this group at http://groups.google.com/group/oauth?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 5 Oct 2009 12:20:59 +1100

Richard,

> IMHO, authenticating access requests makes for a more secure protocol with
> already has to authenticate to the SP to get the request token).  But YMMV.

I would prefer the authentication PROTOCOL(S) only used the access token secret (after the delegation flow). If a particular Service wants to discourage Clients from handing off access tokens, that Service can deliberately include the Client's shared secret as part of the access token secret -- and tell the Clients this. Consequently, sharing access tokens is equivalent to sharing Client credentials for that Service, but Clients of other Services are not restricted -- and we don't need any explicit options (complexity) in the spec for this feature.

[Service documentation should be sufficient for this (no discovery necessary), as it is hard to imagine a Client dynamically deciding whether or not to hand off an access token.]

James Manger

---

From: Ben Laurie <[email-masked]>
Date: Sun, 4 Oct 2009 19:50:58 -0700

> opening themselves up to Consumers that hand off tokens to bad people.

Nothing can prevent a Consumer acting as a proxy for a third party.
So, in practice, once you've given the access token to the Consumer,
you've given him the ability to delegate - albeit painfully.

Given that reality, it might make sense to formalise delegation, and
allow a Consumer to generate a delegated token, perhaps with reduced
authority, e.g. a read-only token from a read-write one, which he
could then pass on to the third party.

Presumably from the keeping-the-user-informed perspective, requiring
the Consumer to go back to the SP would allow the SP to track (and
revoke) delegations.

> an expensive certificate).

Expensive certificates, I am told, are bought with stolen credit cards
by the bad guys. So, they're free, pretty much, for the bad guys and
expensive for the good guys. Which seems the wrong way round.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 4 Oct 2009 23:45:20 -0700

At last, something James and I agree on completely!

The idea that two secrets are better than one is silly since they are both needed for every signed request and therefore must be present in any client/server. There is nothing to stop a client from sharing its credentials together with its token/secret pair.

Using only the token credentials to access protected resources (i.e. no client credentials which are used only to get the token in the first place) offers a valuable simplification which by definition improves security (client credentials are no longer needed in every client and server and can be safeguard just in the parts that issue and request tokens).

I am generally skeptical of any proposal trying to solve re-delegation (so called 4th legged) that is offering security using something other than expensive lawyers. When a user is asked to approve access to a third party, they should be presented with information that will help them make smart decisions. Providers should make sure that their TOS requires full disclosure of such activities or forbid it. They should then use their lawyers to go after companies that mess with their users.

Keep in mind that the threats of re-delegation are not security related but simply a matter of trusting third parties not to be stupid about what they do with our data. There is no need for re-delegation to hurt a user... a client can do it all on its own.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Manger, James H
> Sent: Sunday, October 04, 2009 6:21 PM
> To: [email-masked]
> Subject: Re: [OAUTH-WG] [oauth] Re: Need for timestamp and nonce over
> HTTPS
> 
> Richard,
> 
> YMMV.
> I would prefer the authentication PROTOCOL(S) only used the access
> token secret (after the delegation flow). If a particular Service wants
> to discourage Clients from handing off access tokens, that Service can
> deliberately include the Client's shared secret as part of the access
> token secret -- and tell the Clients this. Consequently, sharing access
> tokens is equivalent to sharing Client credentials for that Service,
> but Clients of other Services are not restricted -- and we don't need
> any explicit options (complexity) in the spec for this feature.
> 
> [Service documentation should be sufficient for this (no discovery
> necessary), as it is hard to imagine a Client dynamically deciding
> whether or not to hand off an access token.]
> 
> 
> 
> James Manger
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Richard Barnes <[email-masked]>
Date: Mon, 05 Oct 2009 14:40:49 +0100

> The idea that two secrets are better than one is silly since they are
> both needed for every signed request and therefore must be present in
> any client/server. There is nothing to stop a client from sharing its
> credentials together with its token/secret pair.

No, there's nothing to stop it, but the incentives are way different for 
the two different types of credentials.  The client credentials are 
supposed to be long-lived, and tightly bound to the Client's identity 
(switching to IETF terminology here).  I think of identity certificates 
as the canonical example -- they last for O(years) and you use them to 
authenticated to multiple entities.  If you give one of these away, 
you're giving up a lot; you're enabling the recipient to masquerade as 
you on a large scale.

The token/secret pair is much, much lower-risk.  You give up your token 
credentials and all you're allowing the recipient to do is access the 
delegated resources.

> Using only the token credentials to access protected resources (i.e.
> no client credentials which are used only to get the token in the
> first place) offers a valuable simplification which by definition
> improves security (client credentials are no longer needed in every
> client and server and can be safeguard just in the parts that issue
> and request tokens).

This sounds like you're viewing Client hand-off of tokens as a 
requirement: Client's Delegation Agent does the OAuth dance to get the 
access token, then passes it off to the Client's Access Agent, who 
actually does the work.

If there is a requirement to support that deployment pattern, then 
you're right that you can't require Client authentication on every 
access.  But at the same time, you also can't prevent the Client from 
handing the token to some third party, so you'll have to document that 
risk.

> Keep in mind that the threats of re-delegation are not security
> related but simply a matter of trusting third parties not to be
> stupid about what they do with our data. There is no need for
> re-delegation to hurt a user... a client can do it all on its own.

I agree, the question here is how much the third party Client is 
trusted.  Authorizing someone to access to a resource and authorizing 
them to grant others authorization are two different things, though.  So 
it comes down to what the scope is of an OAuth authorization: If the 
user only wants to allow the Client to access data, then the Server MUST 
authenticate the Client on access requests.  If the user also allows 
re-delegation, then the Server MUST NOT authenticate the Client on 
access requests.

It seems like what we need here is to say that Client authentication on 
access requests is a MUST implement / SHOULD use.  Would that make sense?

--Richard