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

[Eran Hammer-Lahav <eran at hueniverse.com>]

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: oauth-bounces at ietf.org [mailto:oauth-bounces at ietf.org] On Behalf
> Of Manger, James H
> Sent: Sunday, October 04, 2009 6:21 PM
> To: oauth at ietf.org
> Subject: Re: [OAUTH-WG] [oauth] Re: Need for timestamp and nonce over
> HTTPS
> 
> Richard,
> 
> > 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.
> 
> 
> 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
> James.H.Manger at team.telstra.com
> Identity and security team — Chief Technology Office — Telstra
> 
> _______________________________________________
> OAuth mailing list
> OAuth at ietf.org
> https://www.ietf.org/mailman/listinfo/oauth