Subject: [OAUTH-WG] RSA signing and web delegation

From: Brian Eaton <[email-masked]>
Date: Thu, 5 Nov 2009 17:31:42 -0800

I spent a bit of time today wondering how to integrate RSA signing in
OAuth (which has obvious key distribution advantages) with requests
that only send access tokens (which has obvious usability advantages).

The only way I can think of to resolve these conflicts goes like this:

1) Initial requests for user approval (using the web delegation flow)
are signed using RSA.

2) Data requests are either not signed, or are signed only with the
token secret using HMAC.

3) Requests to renew access tokens (if we adopt something like the
scalable OAuth extension) are again signed using RSA.

Thoughts?

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 5 Nov 2009 20:35:03 -0700

I like this approach. It keeps the RSA signing in the delegation flow and not in the generic authentication method. This keeps the token as the sole authentication tool when making protected resources requests (no client credentials or RSA keys).

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Eaton
> Sent: Thursday, November 05, 2009 5:32 PM
> To: [email-masked]
> Subject: [OAUTH-WG] RSA signing and web delegation
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 05 Nov 2009 22:49:52 -0500

One question: Is RSA is really essential here? I  think not (why not use 
ECC or any other PKI algorithm instead?). So, I would agree with Brian 
so long as RSA is replaced with PKI.

Igor

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 6 Nov 2009 15:15:25 +1100

Brian,

> 1) Initial requests for user approval .. are signed using RSA.
> 2) Data requests .. are signed only with the token secret using HMAC.

Why do you need to use the RSA key during token renewal?

If renewal can be occur at any time at the discretion of the server, then the client will always need the RSA key handy. It sounds like it will be hard for a client to get any benefit from not needing the RSA key for resource requests if, at any moment, it needs the RSA key to renew the token to complete a resource request. It seems to make it tough to hand a user-specific token to javascript running in that user's browser, for instance.

If I remember correctly, the threat that the Scalable OAuth extension addresses is that many content services accept tokens issued by one security server then one content server is compromised. Security for the other content servers should be restored in the short (eg 5 min) token lifetime.

It should be sufficient for the security server to be able to distinguish the original client that a token was returned to, from a malicious party that learnt the token details from a compromised content server. Two quick ideas:

1. A cookie set by the security server when issuing the token would be sufficient. The client would return the cookie during renewal; the compromised content server never sees this cookie.

2. A better alternative might be for the security server to provide a renewal URL when issuing a token. The renewal URL can be unique to the token. A compromised content server never sees the renewal URL so it cannot renew a token.

Both these ideas tackle the Scalable OAuth issue, while keeping the benefits of not needing the RSA key after the initial interactive delegation involving the user.

James Manger
[email-masked]
Identity and security team — Chief Technology Office — Telstra

---

From: John Panzer <[email-masked]>
Date: Thu, 5 Nov 2009 21:52:38 -0800

What about 2 legged OAuth?

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 5 Nov 2009 23:20:46 -0700

We need to stop using this term (2 legged) and instead describe the exact use case. This term can mean using OAuth without user-context but in an overall scenario where there still is a user (for example, a server offering both protected resources APIs as well as client admin APIs that are not specific to any resource owner). It can also be used to mean using OAuth as a more secure replacement for Basic auth in which the username and password are sent as the client credentials (and no token).

We are going to address the second case by providing a new direct authentication method modeled after whatever we come up for the token-based case (or delegation, whatever we call it) - somehow...

I am not sure what to do about the first case yet, but it will need to be resolved as part of the delegation flow for sending authenticated requests to obtain a token when there is still no token present.

EHL

> Of John Panzer
> Sent: Thursday, November 05, 2009 9:53 PM
> To: Brian Eaton
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] RSA signing and web delegation
>

---

From: John Panzer <[email-masked]>
Date: Thu, 5 Nov 2009 22:30:16 -0800

My query was about case #2.  These cases need better names.
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

On Thu, Nov 5, 2009 at 10:20 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> We need to stop using this term (2 legged) and instead describe the exact
> use case. This term can mean using OAuth without user-context but in an
> overall scenario where there still is a user (for example, a server offering
> both protected resources APIs as well as client admin APIs that are not
> specific to any resource owner). It can also be used to mean using OAuth as
> a more secure replacement for Basic auth in which the username and password
> are sent as the client credentials (and no token).
>
> We are going to address the second case by providing a new direct
> authentication method modeled after whatever we come up for the token-based
> case (or delegation, whatever we call it) - somehow...
>
> I am not sure what to do about the first case yet, but it will need to be
> resolved as part of the delegation flow for sending authenticated requests
> to obtain a token when there is still no token present.
>
> EHL
>
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 5 Nov 2009 23:33:23 -0700

Do you need an RSA option for the "Basic Auth Alternative" case?

EHL

From: John Panzer [mailto:[email-masked]]
Sent: Thursday, November 05, 2009 10:30 PM
To: Eran Hammer-Lahav
Cc: Brian Eaton; [email-masked]
Subject: Re: [OAUTH-WG] RSA signing and web delegation

My query was about case #2.  These cases need better names.
--
John Panzer / Google
[email-masked]<mailto:[email-masked]> / abstractioneer.org<http://abstractioneer.org> / @jpanzer

On Thu, Nov 5, 2009 at 10:20 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
We need to stop using this term (2 legged) and instead describe the exact use case. This term can mean using OAuth without user-context but in an overall scenario where there still is a user (for example, a server offering both protected resources APIs as well as client admin APIs that are not specific to any resource owner). It can also be used to mean using OAuth as a more secure replacement for Basic auth in which the username and password are sent as the client credentials (and no token).

EHL

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of John Panzer
> Cc: [email-masked]<mailto:[email-masked]>
> On Thursday, November 5, 2009, Brian Eaton <[email-masked]<mailto:[email-masked]>> wrote:
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]> / abstractioneer.org<http://abstractioneer.org> / @jpanzer
> [email-masked]<mailto:[email-masked]>

---

From: Brian Eaton <[email-masked]>
Date: Fri, 6 Nov 2009 09:16:34 -0800

> Why do you need to use the RSA key during token renewal?

Requiring the consumer secret (whether is an HMAC secret or an RSA
private key) during renewal helps you recover from compromise.

For example, consider this scenario:
1) Client receives permission to access data on behalf of thousands of users.
2) Client gets hacked.  Attacker steals all of the delegation tokens.
3) How do you recover?

If access token renewal does not require the consumer secret, you're
screwed.  You have to revoke all of the delegation tokens for all of
the users, and they need to reapprove.

If access token renewal *does* require the consumer secret, recovery
is much simpler.  You rotate the consumer secret, and the attacker
loses access to user data.

> If renewal can be occur at any time at the discretion of the server, then the client will always need
> the RSA key handy. It sounds like it will be hard for a client to get any benefit from not needing
> the RSA key for resource requests if, at any moment, it needs the RSA key to renew the token
> to complete a resource request. It seems to make it tough to hand a user-specific token to
> javascript running in that user's browser, for instance.

This is a good point.  Well behaved service providers should have
predictable and usable session lifetimes.  For example, the client web
site can get a session token that is good for one hour, and hand it to
some javascript to use for one hour.  At the end of that hour, the
client web site needs to refresh the token.

> It should be sufficient for the security server to be able to distinguish the original
> client that a token was returned to, from a malicious party that learnt the token
> details from a compromised content server. Two quick ideas:
>
> 1. A cookie set by the security server when issuing the token would be
> sufficient. The client would return the cookie during renewal; the compromised
> content server never sees this cookie.

IMHO, web APIs should not use cookies.  (This is mostly a matter of
opinion on my part, based on problems I've had with distributed cookie
jar management and general annoyance in the past.  I suspect if you
ask application developers they'll tell you the same thing).

> 2. A better alternative might be for the security server to provide a renewal
> URL when issuing a token. The renewal URL can be unique to the token.
> A compromised content server never sees the renewal URL so it cannot renew a token.

I like this idea, particularly if renewal requires both the renewal
secret and the consumer secret.

The consumer secret is useful because of the issues I mentioned above
with recovering from compromise.

The renewal secret is useful because it acts as a long-lived
capability to access user data.  This is particularly important for
installed applications, where the consumer secret isn't really a
secret.

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Fri, 6 Nov 2009 09:23:04 -0800

On Thu, Nov 5, 2009 at 10:33 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Do you need an RSA option for the “Basic Auth Alternative” case?

Yes.  I've been thinking of it as "role account authentication with
OAuth", because that's the main place I see it being really useful.

Here's how I would model it:

- send an RSA-signed message to an authorization server
- authorization server returns an access token (and possibly a secret)
to the client
- client uses the access token for data access

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 6 Nov 2009 13:16:54 -0700

The "Basic auth alternative" would be a single request flow with shared secret (either symmetric or asymmetric). I am not sure how the flow below applies (when compared to Basic auth).

EHL

> From: Brian Eaton [mailto:[email-masked]]
> Sent: Friday, November 06, 2009 9:23 AM
> To: Eran Hammer-Lahav
> Cc: John Panzer; [email-masked]

---

From: Brian Eaton <[email-masked]>
Date: Fri, 6 Nov 2009 13:34:15 -0800

On Fri, Nov 6, 2009 at 12:16 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> The "Basic auth alternative" would be a single request flow with shared
> secret (either symmetric or asymmetric). I am not sure how the flow below
> applies (when compared to Basic auth).

I don't think a basic auth flow based on a single secret is all that
interesting, or even possible to implement.  The problem is how you
bootstrap the secret.

Is the secret the user's password?  That doesn't work with any
well-designed password authentication system (See [1]).  It won't get
deployed.

Is the secret a session cookie?  That could work, but you need an
answer for bootstrapping the session cookie.

Is the secret an OAuth token?  That could also work, but you still
need an answer for bootstrapping the token.

I think RSA is one of many possible answers to the bootstrapping
problem.  Ideally we'll have a bunch of different ways to bootstrap a
session secret, and then using the session secret will be easy.

Cheers,
Brian

[1] http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 6 Nov 2009 15:01:10 -0700

What this means is that there really is just one scenario:

- Client obtains a set token credentials using some shared secret (symmetric or otherwise).
- If the resources are owned by someone other than the client, authorization must be obtained.
- Client uses the token credentials (alone) to access protected resources.

In case where there is sometimes a resource owner other than the client, the client can reuse the same shared secret for both tokens (self and resource owner). In cases where there is no resource owner other than the client (the simple client-server model), the client's shared secret (can be username/password) is used to obtain a token. 

Either way, there is always a token present and we are not attempting to directly replace the Basic auth flow.

This seems reasonable (and much easier) to me.

It does mean we need to define two sets of authentication methods, one for shared-secret based (symmetric or asymmetric) and one for token-based. We will be able to reuse some of the flow between the two, but it sounds to me like one will need to support more options (RSA) than the other (just HMAC and Plain).

Comments?

EHL

> Sent: Friday, November 06, 2009 1:34 PM
> To: Eran Hammer-Lahav
> [1] http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-
> rainbow-tables-what-you-need-to-know-about-s.html

---

From: Brian Eaton <[email-masked]>
Date: Fri, 6 Nov 2009 14:37:50 -0800

> It does mean we need to define two sets of authentication methods, one for shared-secret based (symmetric or asymmetric) and one for token-based. We will be able to reuse some of the flow between t…

+1.