Subject: [OAUTH-WG] Thinking about our secrets for signatures

From: David Recordon <[email-masked]>
Date: Wed, 10 Mar 2010 23:58:07 -0800

Has anyone else put some thought into what secrets are used within the
signature algorithm for OAuth 2.0?

OAuth 1.0 combines the client secret and the token secret with an
ampersand in the middle.  WRAP doesn't support signatures and relies
on the fact that access tokens should remain secret via SSL or are
extremely short lived and thus lower risk.

Here are the options as far as I'm aware (without making changes to
WRAP's assumptions):

1) Sign using the client secret.  Doesn't work because the access
token would be sent over the wire in plaintext and some servers will
make them long lived in 2.0.

2) Issue an access token secret if an optional parameter is specified
by the client during the authorization profile request(s).  Doesn't
work for the same reason as #1 assuming that the same access token can
be used via SSL.

3) Instead of adding an optional parameter to each authorization
profile, have the client immediately refresh the access token and
support an optional parameter to request an access token secret.  This
lessons the impact of supporting signatures on most implementors when
reading the spec and given that most signature use cases have longer
lived tokens, the overhead of the extra HTTP request should be
infrequent compared to the number of protected resource requests
you'll make with it.  Doesn't work for the same reason as #1 assuming
that the same access token can be used via SSL.

While I'm not a crypto expert, it seems impossible to treat the same
access token as potentially public when using signatures but secret
when using SSL.  I believe that authorization servers will need to
keep track of the access tokens that the client has requested a secret
for and from that point on only allow the use of that particular
access token 1) via signatures or 2) via SSL when the access token
secret is passed in as well.

Thoughts?

Thanks,
--David

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 11 Mar 2010 21:38:58 +0100

Hi David,

let me first explain my thoughts in general before I fill in my replies 
to your questions.

In my opinion, all four combinations of transport and signature are 
valid and can be used in different scenarios:

-bearer token/http - comparable to session cockies over http (possibly 
very short token lifetime or/and token is a random number)
-signature/http - already discussed
-bearer token/https - already discussed
-signature/https - signature additionaly provides a) end-2-end 
message-level security b) holder of key verification

Thus I would not assume a dependency between token secret and http(s) 
communication.

 From my point of view, a service should define which combinations it 
supports/requires and announce this as part of the client discovery 
process (e.g. as properties of the WWW-Authenticate response). A client 
then requests a suitable access token w/ or w/o secrets from the 
authorization server. Services definitely need to know the corresponding 
secret in order to verify signatures. But there are different strategies 
I can imagine how it gets access to the secrets (e.g. shared database, 
add encrypted secret to token like Kerberos, push secrets to target 
services). Therefore I would suggest to left this point open to OAuth 
implementations.

I would suggest only to issue shared secrets because I don't see any 
need for public-key crypto here.
> make them long lived in 2.0.
Usage of client secrets to sign resource requests is one of the major 
issues in OAuth 1.0a from operation security and performance 
perspective. So I would discourage from this option.
> work for the same reason as #1 assuming that the same access token can
I would vote for this option. Can you please clarify why you think this 
option won't work?
> that the same access token can be used via SSL.
Why do you expect signature based use cases to have long-living tokens?
> secret is passed in as well.
I don't think an authorization server can (and should) enforce usage of 
access token secrets. It should just issue such secrets and ensure 
services get to know it. Whether the secret is required is a decision of 
the target service. To exaggerate a bit: a client could even request an 
access token w/ secret and just throw the secret away if the target 
service does not require signed requests.

regards,
Torsten.
> Thoughts?
>
> Thanks,
> --David
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Ethan Jewett <[email-masked]>
Date: Thu, 25 Mar 2010 20:54:01 -0600

Possibly this is a silly question, but why not #2 and have the bearer
token method (over SSL of course) include the token secret? The
provider would always issue a token and a token secret. If the client
is not interested in signing methods, it can discard the token and
keep the token secret. This secret is never sent in the clear using a
signing method. I believe that this is the approach taken in OAuth
1.0a and it seems like it should address this concern.

Ethan

---

From: Brian Eaton <[email-masked]>
Date: Thu, 25 Mar 2010 20:50:21 -0700

> 1.0a and it seems like it should address this concern.

Well thought-out bearer tokens and well thought-out proof of
possession tokens rarely look the same.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Mar 2010 21:51:45 -0700

I agree.

Authorization servers should issue credentials (tokens) with clear semantics. If a token is to be used with a signature, its properties should reflect it. If a server doesn't require signatures, why waste storage and bandwidth with secrets.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Eaton
> Sent: Thursday, March 25, 2010 8:50 PM
> To: Ethan Jewett
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Thinking about our secrets for signatures
> 
> Well thought-out bearer tokens and well thought-out proof of possession
> tokens rarely look the same.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 26 Mar 2010 08:42:30 +0100

An interesting question is, who decides what kind of token to issue? 1) 
Is it the authorization server because it knows what tokens and 
signature algorithms are used by the targeted protected resource? 2) Or 
is it the client?  I would tend to #2 because I can imagine protected 
resources with multiple endpoints (e.g. http and https) using different 
token types. So it would be the task of the client to decide which way 
is better suited for its use case.
>> On Thu, Mar 25, 2010 at 7:54 PM, Ethan Jewett<[email-masked]>
>> wrote:
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 26 Mar 2010 08:09:19 -0700

The client can ask for a specific token type, but it is the server's decision. Either way, that decision should happen when the token is issued, not when using it to access a resource.

EHL

> From: Torsten Lodderstedt [mailto:[email-masked]]
> Sent: Friday, March 26, 2010 12:43 AM
> To: Eran Hammer-Lahav
> Cc: Brian Eaton; Ethan Jewett; OAuth WG
> An interesting question is, who decides what kind of token to issue? 1) Is it
> the authorization server because it knows what tokens and signature
> algorithms are used by the targeted protected resource? 2) Or is it the client?
> I would tend to #2 because I can imagine protected resources with multiple
> endpoints (e.g. http and https) using different token types. So it would be
> the task of the client to decide which way is better suited for its use case.
> > I agree.
> >
> > Authorization servers should issue credentials (tokens) with clear
> semantics. If a token is to be used with a signature, its properties should
> reflect it. If a server doesn't require signatures, why waste storage and
> bandwidth with secrets.
> >
> > EHL
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Brian Eaton
> >>> Possibly this is a silly question, but why not #2 and have the
> >>> bearer token method (over SSL of course) include the token secret?
> >>> The provider would always issue a token and a token secret. If the
> >>> client is not interested in signing methods, it can discard the
> >>> token and keep the token secret. This secret is never sent in the
> >>> clear using a signing method. I believe that this is the approach
> >>> taken in OAuth 1.0a and it seems like it should address this concern.
> >>>

---

From: Raffi Krikorian <[email-masked]>
Date: Fri, 26 Mar 2010 08:24:11 -0700

i concur that it should be the client that decides -- the client knows what
its access requirements are, and can (possibly) be trusted to better make
the choice.  of course, it could be possibly be the server's decision
whether to support signatures or not.

by "when the token is issued", do you mean that during each "flow" a secret
token could be issued, or (using recordon's notes above) is it #3 -- where
during the "refresh" you could say "please give me a secret with this token,
and then make this token impossible to use in a non-signature way".

On Fri, Mar 26, 2010 at 8:09 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> The client can ask for a specific token type, but it is the server's
> decision. Either way, that decision should happen when the token is issued,
> not when using it to access a resource.
>
> EHL
>
> Is it

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Raffi Krikorian <[email-masked]>
Date: Fri, 26 Mar 2010 08:24:11 -0700

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Ethan Jewett <[email-masked]>
Date: Fri, 26 Mar 2010 09:39:34 -0600

I agree with that approach, but in this case (where I read that we are
effectively binding tokens to resource access methods) I think we need
some indications during the delegation flow as far as what method the
token is meant to be used with. Possibly a parameter
oauth_token_method when a client requests an access, and then the same
parameter in the server response to indicate what token type the
server opted to provide.

We would probably also need at least a SHOULD in the resource access
part of the spec recommending that servers invalidate tokens that are
used with the wrong resource access method, as this could publicize
secrets that are vital to the security of a different method.

That is all assuming that I am understanding the suggestion.

Ethan

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 26 Mar 2010 08:41:53 -0700

When a token is issued, that's when a secret should be provided if the token is to be used with a signature. The specific mac algorithm can be provided either with the token or at the resource endpoint (I don't have a strong feeling since we are only talking about symmetric secrets at this point).

I don't think a token should be "upgraded" from bearer to a secret-enabled using the refresh process.

EHL

From: Raffi Krikorian [mailto:[email-masked]]
Sent: Friday, March 26, 2010 8:24 AM
To: Eran Hammer-Lahav
Cc: Torsten Lodderstedt; [email-masked]; WG
Subject: Re: [OAUTH-WG] Thinking about our secrets for signatures

i concur that it should be the client that decides -- the client knows what its access requirements are, and can (possibly) be trusted to better make the choice.  of course, it could be possibly be the server's decision whether to support signatures or not.

by "when the token is issued", do you mean that during each "flow" a secret token could be issued, or (using recordon's notes above) is it #3 -- where during the "refresh" you could say "please give me a secret with this token, and then make this token impossible to use in a non-signature way".
On Fri, Mar 26, 2010 at 8:09 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
The client can ask for a specific token type, but it is the server's decision. Either way, that decision should happen when the token is issued, not when using it to access a resource.

EHL

> From: Torsten Lodderstedt [mailto:[email-masked]<mailto:[email-masked]>]
> >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> >> Behalf Of Brian Eaton
> >> On Thu, Mar 25, 2010 at 7:54 PM, Ethan Jewett<[email-masked]<mailto:[email-masked]>>
> >> wrote:
> >>
> >> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 26 Mar 2010 08:41:53 -0700

EHL

EHL

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 26 Mar 2010 18:30:50 +0100

> When a token is issued, that's when a secret should be provided if the 
> token is to be used with a signature. The specific mac algorithm can 
> be provided either with the token or at the resource endpoint (I don't 
> have a strong feeling since we are only talking about symmetric 
> secrets at this point).
>
> I don't think a token should be "upgraded" from bearer to a 
> secret-enabled using the refresh process.
>
I agree. Independent of who actually decides the token type, this type 
should be constant in authz and refreshment process.

I think the resource endpoint should advertise the supported methods 
(e.g. by way of a WWW-Authenticate-Header-Parameter), the client can ask 
the authorization server for a specific token type incl. 
signature-method and the authorization server may refuse such a request 
if it is unable to provide an appropriate token type/secret.
>
> EHL
>
> *From:* Raffi Krikorian [mailto:[email-masked]]
> *Sent:* Friday, March 26, 2010 8:24 AM
> *To:* Eran Hammer-Lahav
> *Cc:* Torsten Lodderstedt; [email-masked]; WG
> *Subject:* Re: [OAUTH-WG] Thinking about our secrets for signatures
>
> i concur that it should be the client that decides -- the client knows 
> what its access requirements are, and can (possibly) be trusted to 
> better make the choice.  of course, it could be possibly be the 
> server's decision whether to support signatures or not.
>
> by "when the token is issued", do you mean that during each "flow" a 
> secret token could be issued, or (using recordon's notes above) is it 
> #3 -- where during the "refresh" you could say "please give me a 
> secret with this token, and then make this token impossible to use in 
> a non-signature way".
>
> On Fri, Mar 26, 2010 at 8:09 AM, Eran Hammer-Lahav 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> decision. Either way, that decision should happen when the token is 
> issued, not when using it to access a resource.
>
> EHL
>
>
> > >> From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] On
> > >> Behalf Of Brian Eaton
> > >> [email-masked] <mailto:[email-masked]>
> > > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 26 Mar 2010 18:30:50 +0100

---

From: Raffi Krikorian <[email-masked]>
Date: Fri, 26 Mar 2010 10:45:49 -0700

>
> When a token is issued, that’s when a secret should be provided if the
> token is to be used with a signature. The specific mac algorithm can be
> provided either with the token or at the resource endpoint (I don’t have a
> strong feeling since we are only talking about symmetric secrets at this
> point).
>
>
>
> I don’t think a token should be “upgraded” from bearer to a secret-enabled
> using the refresh process.
>
> I think the resource endpoint should advertise the supported methods (e.g.
> by way of a WWW-Authenticate-Header-Parameter), the client can ask the
> authorization server for a specific token type incl. signature-method and
> the authorization server may refuse such a request if it is unable to
> provide an appropriate token type/secret.
>

sure - so at the first request time, you can request.  it is still possible
to upgrade and download the token time during refresh (switch from non
signature to signature based on the refresh)?

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Raffi Krikorian <[email-masked]>
Date: Fri, 26 Mar 2010 10:45:49 -0700

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 26 Mar 2010 11:46:45 -0700

Why do you need to change the cryptographic properties of a token during refresh?

EHL

From: Raffi Krikorian [mailto:[email-masked]]
Sent: Friday, March 26, 2010 10:46 AM
To: Torsten Lodderstedt
Cc: Eran Hammer-Lahav; [email-masked]; WG
Subject: Re: [OAUTH-WG] Thinking about our secrets for signatures

I don't think a token should be "upgraded" from bearer to a secret-enabled using the refresh process.
I agree. Independent of who actually decides the token type, this type should be constant in authz and refreshment process.

I think the resource endpoint should advertise the supported methods (e.g. by way of a WWW-Authenticate-Header-Parameter), the client can ask the authorization server for a specific token type incl. signature-method and the authorization server may refuse such a request if it is unable to provide an appropriate token type/secret.

sure - so at the first request time, you can request.  it is still possible to upgrade and download the token time during refresh (switch from non signature to signature based on the refresh)?

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Raffi Krikorian <[email-masked]>
Date: Fri, 26 Mar 2010 11:50:05 -0700

i believe in normal operation an application will choose once, and be done
-- they will either signal that they want to use tokens under SSL, or use
signatures.  the only concern i have is if an application decides at a later
date that they would like to use a signature mechanism (or visa versa) they
they should have an upgrade path (otherwise they would have to deprecate
their tokens and re-authorize their users?).  its a (albeit remote)
possibility for web based operations, and i doubt that we'll ever see a
native application doing that.

On Fri, Mar 26, 2010 at 11:46 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> *Sent:* Friday, March 26, 2010 10:46 AM
> *To:* Torsten Lodderstedt
> *Cc:* Eran Hammer-Lahav; [email-masked]; WG
>

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 26 Mar 2010 11:55:45 -0700

It boils down to whatever parameter we add to request a token type being also available when refreshing a token. I am not sure there is a real justification for that, but I can go either way.

Anyone else with use cases for this?

EHL

From: Raffi Krikorian [mailto:[email-masked]]
Sent: Friday, March 26, 2010 11:50 AM
To: Eran Hammer-Lahav
Cc: WG
Subject: Re: [OAUTH-WG] Thinking about our secrets for signatures

i believe in normal operation an application will choose once, and be done -- they will either signal that they want to use tokens under SSL, or use signatures.  the only concern i have is if an application decides at a later date that they would like to use a signature mechanism (or visa versa) they they should have an upgrade path (otherwise they would have to deprecate their tokens and re-authorize their users?).  its a (albeit remote) possibility for web based operations, and i doubt that we'll ever see a native application doing that.

On Fri, Mar 26, 2010 at 11:46 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Why do you need to change the cryptographic properties of a token during refresh?

EHL

From: Raffi Krikorian [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 26, 2010 10:46 AM
To: Torsten Lodderstedt
Cc: Eran Hammer-Lahav; [email-masked]<mailto:[email-masked]>; WG

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 26 Mar 2010 19:59:05 +0100

I remember one scenario in the discussion "why signatures" in the 
context of pro/con HTTPS.

In this scenario, "normal" requests would be performed over HTTPS with 
bearer tokens, which is easy to implement and secure. But some requests 
(e.g. download large video files), where the penalty for encrypting the 
whole traffic would be to high, would be performed over a HTTP 
connection (probably with a signed  request).

Would that be a conclusive example for different cryptographical 
properties for access tokens based on the same refresh token?

regards,
Torsten.
> i believe in normal operation an application will choose once, and be 
> done -- they will either signal that they want to use tokens under 
> SSL, or use signatures.  the only concern i have is if an application 
> decides at a later date that they would like to use a signature 
> mechanism (or visa versa) they they should have an upgrade path 
> (otherwise they would have to deprecate their tokens and re-authorize 
> their users?).  its a (albeit remote) possibility for web based 
> operations, and i doubt that we'll ever see a native application doing 
> that.
>
> On Fri, Mar 26, 2010 at 11:46 AM, Eran Hammer-Lahav 
>     *From:* Raffi Krikorian [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* Eran Hammer-Lahav; [email-masked]
>     <mailto:[email-masked]>; WG
>
>
>             When a token is issued, that’s when a secret should be
>             provided if the token is to be used with a signature. The
>             specific mac algorithm can be provided either with the
>             token or at the resource endpoint (I don’t have a strong
>             feeling since we are only talking about symmetric secrets
>             at this point).
>
>             I don’t think a token should be “upgraded” from bearer to
>             a secret-enabled using the refresh process.
>
>         I agree. Independent of who actually decides the token type,
>         this type should be constant in authz and refreshment process.
>
>         I think the resource endpoint should advertise the supported
>         methods (e.g. by way of a WWW-Authenticate-Header-Parameter),
>         the client can ask the authorization server for a specific
>         token type incl. signature-method and the authorization server
>         may refuse such a request if it is unable to provide an
>         appropriate token type/secret.
>
>     sure - so at the first request time, you can request.  it is still
>     possible to upgrade and download the token time during refresh
>     (switch from non signature to signature based on the refresh)?
>
>     -- 
>     Raffi Krikorian
>     Twitter Platform Team
>     http://twitter.com/raffi
>
>
>
>
> -- 
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi
>
>

---

From: "Davis, Peter" <[email-masked]>
Date: Fri, 26 Mar 2010 15:21:25 -0400

On Mar 26, 2010, at 13:50 PM, Raffi Krikorian wrote:

> if an application decides at a later date that they would like to use a signature mechanism (or visa versa) they they should have an upgrade path (otherwise they would have to deprecate their tokens and re-authorize their users?)

Why is this not simply a new token request (rather than a change token from a to b)?  Does the use case require changing the token without the user being present?  In which case, i think you would be asking for a new security context without the users involvement, which might be an error, IMV.

=peterd

Peter Davis: Neustar, Inc.
Sr. Director & Distinguished Member of the Technical Staff
45980 Center Oak Plaza Sterling, VA 20166
[T] +1 571 434 5516 [E] [email-masked] [W] http://www.neustar.biz/ [X] xri://@neustar*pdavis [X] xri://=peterd
The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.

---

From: George Fletcher <[email-masked]>
Date: Fri, 26 Mar 2010 15:25:35 -0400

So I think that there are two different issues here in regards to 
up/down grading an access token.

1. Token re-use:
     Does it make sense to use the same access token for a while as a 
bearer and then switch to signing? My personal belief is no.

2. Token exchange:
     Can tokens be exchanged without the user having to re-authorize. I 
think the answer here is yes.

Given the example of using Bearer+SSL for most transactions and 
Signing+HTTP for large file downloads, why can't the client present the 
existing Bearer token, refresh_token and maybe something else to the AS 
and have the AS send back a new access token + secret to use for the 
large file download. All scoping would remain the same.

That way we don't mix token uses, but it's possible to seamlessly 
exchange one set for another so the user doesn't have to re-authorize 
the tokens.

Thanks,
George

On 3/26/10 2:55 PM, Eran Hammer-Lahav wrote:
>
> It boils down to whatever parameter we add to request a token type 
> being also available when refreshing a token. I am not sure there is a 
> real justification for that, but I can go either way.
>
> *Sent:* Friday, March 26, 2010 11:50 AM
> *To:* Eran Hammer-Lahav
> *Cc:* WG
>         specific mac algorithm can be provided either with the token
>         or at the resource endpoint (I don’t have a strong feeling
>         since we are only talking about symmetric secrets at this point).
>
>         I don’t think a token should be “upgraded” from bearer to a
>     I agree. Independent of who actually decides the token type, this
>     type should be constant in authz and refreshment process.
>
>     methods (e.g. by way of a WWW-Authenticate-Header-Parameter), the
>     client can ask the authorization server for a specific token type
>     incl. signature-method and the authorization server may refuse
>     such a request if it is unable to provide an appropriate token
>     type/secret.
>
> possible to upgrade and download the token time during refresh (switch 
> from non signature to signature based on the refresh)?
>
> -- 
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi
>
>
>
>
> -- 
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi
>
> =
>
>