Subject: [OAUTH-WG] signatures, v2

From: Dirk Balfanz <[email-masked]>
Date: Thu, 15 Jul 2010 17:43:47 -0700

Hi guys,

after reading through the feedback, we did a pass over the OAuth signature
proposals.

As a reminder, there are three documents:

- a document (called "JSON Tokens") that just explains how to sign something
and verify the signature:
http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4

- an extension of JSON Tokens that can be used for signed OAuth
tokens:<http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU>
http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU

- a different extension of JSON Tokens that can be used whenever the spec
calls for an "assertion":
http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc
(When used in the assertion flow, this last token can also be used to do
"2-legged" OAuth)

A summary of the (scant) changes:

- we spelled out what we mean by RSA-SHA256.* Ben Laurie *- can you
double-check that that sounds good?
- we decided on unpadded websafe-base64 throughout.
- some changes to parameter names.
- some small changes I might be forgetting now...

As explained in my message to the previous thread, there is still no
envelope in there to help with encrypted tokens (b/c we don't understand
well enough what the envelopes for encrypted tokens would look like).

One question: What's the deal with having the signature go first? If you can
explain to me why that is a good idea, I'm happy to oblige.

Cheers,

Dirk & Marius.

---

From: Naitik Shah <[email-masked]>
Date: Thu, 15 Jul 2010 18:45:56 -0700

On Thu, Jul 15, 2010 at 5:43 PM, Dirk Balfanz <[email-masked]> wrote:

>
> One question: What's the deal with having the signature go first? If you
> can explain to me why that is a good idea, I'm happy to oblige.
>
>
When we were talking about base64url or not, putting the signature before
the dot meant it was okay for a dot to show up in the payload in an
unencoded fashion, which was coupled with the fact that lsplit or split with
a limit are more common in standard libraries based on some rough
exploration. But that's not relevant anymore.

Is there a downside to having the signature first? I like it better because
the signature length is predictable, meaning the first X chars will be the
sig, and then the X+1 char will be the dot. I like the consistency it
provides :)

-Naitik

---

From: Dick Hardt <[email-masked]>
Date: Thu, 15 Jul 2010 21:53:56 -0700

On 2010-07-15, at 6:45 PM, Naitik Shah wrote:

> One question: What's the deal with having the signature go first? If you can explain to me why that is a good idea, I'm happy to oblige.
> 
> 
> When we were talking about base64url or not, putting the signature before the dot meant it was okay for a dot to show up in the payload in an unencoded fashion, which was coupled with the fact that lsplit or split with a limit are more common in standard libraries based on some rough exploration. But that's not relevant anymore.
> 
> Is there a downside to having the signature first? I like it better because the signature length is predictable, meaning the first X chars will be the sig, and then the X+1 char will be the dot. I like the consistency it provides :)

If we put the envelope first, then we know what to do with the token. Signatures don't exist in an encrypted token. Think of the envelope like HTTP headers. They makes sense to go first. After the envelope, I don't have a preference between signature and payload or payload and signature.

btw: signature length is not predictable -- it is dependant on the algorithm. *when* a different hash algorithm is used the length will likely change. The only way to know this is to look at algorithm first.

-- Dick

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 18 Jul 2010 17:20:03 +0200

Hi Dirk,

I have some questions concerning your proposal:

- As far as I understand, the difference to "magic signatures" lays in 
the usage of a JSON token carrying issuer, not_before, not_after and 
audience. While such properties are important for security tokens 
(assertions), I cannot see an advantage of using this format for 
signatures of HTTP requests. Would you please explain?

- Key management
 From my point of view, your proposal does cover key management for web 
applications using RSA signatures. What about web applications intending 
to sign resource server requests using HMAC (for performance reasons)? 
Do they need to exchange secrets with the resource server?

What about installed applications (mobile, desktop, set top boxes, 
gaming devices)?
  1) RSA: Do they need to provide their public key on a web server? This 
would be an additional requirement for such applications.
  2) HMAC: Same as for web apps, but even harder because either (a) the 
installed app has a static secret burned
into source code or (b) it needs to use a protocol for dynamic key 
management the resource server has to implement. Is this the plan?

Remark on 
(https://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4):
"To obtain an HMAC verification key, the client has to exchange, in an 
out-of-band fashion, shared keys with the issuer."

I assume "client" should be "verifier", shouldn't it?

regards,
Torsten.

Am 16.07.2010 02:43, schrieb Dirk Balfanz:
> Hi guys,
>
> after reading through the feedback, we did a pass over the OAuth 
> signature proposals.
>
> - a document (called "JSON Tokens") that just explains how to sign 
> something and verify the signature:
> - an extension of JSON Tokens that can be used for signed OAuth tokens:
> - a different extension of JSON Tokens that can be used whenever the 
> spec calls for an "assertion":
> (When used in the assertion flow, this last token can also be used to 
> do "2-legged" OAuth)
>
> envelope in there to help with encrypted tokens (b/c we don't 
> understand well enough what the envelopes for encrypted tokens would 
> look like).
>
> One question: What's the deal with having the signature go first? If 
> you can explain to me why that is a good idea, I'm happy to oblige.
>
> Cheers,
>
> Dirk & Marius.
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 19 Jul 2010 17:22:42 -0700

On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> - As far as I understand, the difference to "magic signatures" lays in the
> usage of a JSON token carrying issuer, not_before, not_after and audience.
> While such properties are important for security tokens (assertions), I
> cannot see an advantage of using this format for signatures of HTTP
> requests. Would you please explain?
>

You mean advantage over magic signatures? It's really a similar idea - it's
just that magic signatures as is don't quite fit the bill. For example, they
have newlines in them:
http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5

> applications using RSA signatures. What about web applications intending to
> sign resource server requests using HMAC (for performance reasons)? Do they
> need to exchange secrets with the resource server?
>

Correct - I'm not saying how HMAC keys are being distributed. Presumably,
you would use a similar system to what many platform providers use today -
you sign up as a developer, and they give you a "developer key" (or "API
key").

> What about installed applications (mobile, desktop, set top boxes, gaming
> devices)?
>

I don't think that installed apps can ever authenticate themselves (i.e.,
prove the statement "I am a copy of the FooBar app"), so I'm not trying to
solve that. What we _can_ do is deliver OAuth tokens to an installed app of
the user's choice, but the server won't know who received the token - only
the user does.

> Remark on (
> https://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4
> ):

Yes. Thanks - fixed!

Dirk.

> [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 21 Jul 2010 17:26:23 +0900

Hi Dirk,

Inline:

On Tue, Jul 20, 2010 at 9:22 AM, Dirk Balfanz <[email-masked]> wrote:
>
>
> On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt
> <[email-masked]> wrote:
>>
>> Hi Dirk,
>>
> have newlines in
> them: http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5

Well, they MAY, but they do not have to. Would not profiling Magic
Signatures so that it does not contain newlines do?

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 21 Jul 2010 17:50:25 +0900

> Signatures so that it does not contain newlines do?

e.g., base64url_encode(magic_sig_envelope).

Downside of course is that it is one more base64url_encode.
I really do not have much preference of one over another, but I have
some preference on the convergence of the two.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 21 Jul 2010 12:27:19 +0100

On 16 July 2010 01:43, Dirk Balfanz <[email-masked]> wrote:
> - we spelled out what we mean by RSA-SHA256. Ben Laurie - can you

Nearly missed this, somehow. Yes, looks good to me. A reference would
be nice (RFC 3447, for example).

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 22 Jul 2010 03:22:13 +0900

> be nice (RFC 3447, for example).

Magic Signatures is using EMSA-PKCS1-v1_5 instead of PSS because it has
wider library supports, I believe. For example, OpenSSL library
interface in PHP
does not seem to support PSS.

>> well enough what the envelopes for encrypted tokens would look like).

Perhaps http://tools.ietf.org/html/draft-sakimura-jsonenc-00 help?

>> explain to me why that is a good idea, I'm happy to oblige.

With Sign + Encrypt, you are signing the (almost) plain text, while
with Encrypt + Sign, you are sining the cypher text so you would have to
have full trust on the Encrypt process that it did not tamper the
original text.
Also, with Sign + Encrypt, you can store the decrypted text and still
verify the
integrity of the data at a later date, but with Encrypt + Sign, you cannot.
Thus, to me, Sign + Encrypt seem to be a better approach.

---

From: Greg Brail <[email-masked]>
Date: Thu, 22 Jul 2010 14:57:58 -0400

I apologize since I have a feeling that this decision was made long ago but
I'd like to understand...

OAuth 1.0 had a secret associated with every token and used an HMAC to
generate the signature. So, there is no way for an intermediary to see the
token secret, regardless of whether SSL is used.

OAuth 2.0 removed the token secret, which means that SSL must be used and
any "legitimate" intermediaries like proxies and load balancers can see the
token. We all agreed that this was a good thing and it greatly simplifies
OAuth but it does eliminate some of the old OAuth 1.0 use cases.

Are there still cases in which an API provider wishes to *avoid* using SSL,
but still wants to ensure that a network eavesdropper or a legitimate
intermediary cannot deduce the token and secret?

I can imagine that such a mechanism might still be useful in environments
where SSL is cost-prohibitive, such as for storage APIs that return very
large data sets that are not sensitive enough to require SSL.

For instance, Amazon uses something like OAuth 1.0 signatures in their AWS
APIs. Does anyone have an idea whether they are still happy with that
decision, or do they wish that they had just required SSL for everything?

Is there any proposal to introduce an extension that works like the "old"
OAuth 1.0 signature mechanism, including the usage of a token secret? Is
that idea totally dead or just dormant?

*From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
*Dirk Balfanz
*Sent:* Thursday, July 15, 2010 8:44 PM
*To:* OAuth WG
*Subject:* [OAUTH-WG] signatures, v2

Hi guys,

Cheers,

Dirk & Marius.

---

From: Greg Brail <[email-masked]>
Date: Thu, 22 Jul 2010 15:01:34 -0400

Looks like I didn't read all the specs before writing such a long e-mail.
Sorry!

"JSON Signatures" does indeed support a key and says that, for HMAC and RSA,
there should be an out-of-band mechanism for a client to retrieve a key to
go along with a particular token.

Should we have a spec that specifies how an OAuth 2.0 client can securely
retrieve a key for each token in a way that makes sense for OAuth 2.0 and is
easy to implement? Or is this already specified somewhere else?

*From:* Greg Brail [mailto:[email-masked]]
*Sent:* Thursday, July 22, 2010 2:58 PM
*To:* 'OAuth WG'
*Subject:* RE: [OAUTH-WG] signatures, v2

Hi guys,

Cheers,

Dirk & Marius.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 23 Jul 2010 00:01:54 +0200

> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Dirk,
>
>     - As far as I understand, the difference to "magic signatures"
>     lays in the usage of a JSON token carrying issuer, not_before,
>     not_after and audience. While such properties are important for
>     security tokens (assertions), I cannot see an advantage of using
>     this format for signatures of HTTP requests. Would you please explain?
>
>
> You mean advantage over magic signatures? It's really a similar idea - 
> it's just that magic signatures as is don't quite fit the bill. For 
> example, they have newlines in them: 

I mean, what is the reason for including issuer, not_before, not_after 
and audience into a signature?

>     - Key management
>     From my point of view, your proposal does cover key management for
>     web applications using RSA signatures. What about web applications
>     intending to sign resource server requests using HMAC (for
>     performance reasons)? Do they need to exchange secrets with the
>     resource server?
>
>
> Correct - I'm not saying how HMAC keys are being distributed. 
> Presumably, you would use a similar system to what many platform 
> providers use today - you sign up as a developer, and they give you a 
> "developer key" (or "API key").

Such a system will work for a relatively static relation between client 
and server only. Do you suggest a client should register with every 
resource server in advance?

What about dynamic clients? Suppose a client is just configured with a 
URL pointing to a PortableContacts resource. The client discovers the 
respective authz server and obtains a token. What if the client wants to 
sign the messages to the resource server?

> I don't think that installed apps can ever authenticate themselves 
> (i.e., prove the statement "I am a copy of the FooBar app"), so I'm 
> not trying to solve that. What we _can_ do is deliver OAuth tokens to 
> an installed app of the user's choice, but the server won't know who 
> received the token - only the user does.

I think we can do more. Even installed applications can use signatures 
to protect messages on transport. What about that use case? Clearly they 
need appropriate key material. The token secret  issued by the 
authorization server could server that purpose.

>      1) RSA: Do they need to provide their public key on a web server?
>     This would be an additional requirement for such applications.
>      2) HMAC: Same as for web apps, but even harder because either (a)
>     the installed app has a static secret burned

regards,
Torsten.

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 23 Jul 2010 10:58:31 -0700

On Wed, Jul 21, 2010 at 1:26 AM, Nat Sakimura <[email-masked]> wrote:

> the
> it's
> > them:

I'll look into it. There are some other differences, like HMAC signatures in
addition to RSA, X.509 encodings of certs, but perhaps those differences can
be smoothed over in favor for a common spec. I'll talk to John Panzer.

Dirk.

---

From: Dirk Balfanz <[email-masked]>
Date: Fri, 23 Jul 2010 11:45:30 -0700

On Thu, Jul 22, 2010 at 3:01 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> it's just that magic signatures as is don't quite fit the bill. For example,
> they have newlines in them:
> I mean, what is the reason for including issuer, not_before, not_after and
> audience into a signature?
>

If the attacker could change the audience field without invalidating the
token, then parties other than the one for which the token is intended could
be tricked into accepting it.
Similarly, if the attacker could change the not_before and not_after fields
without invalidating the token, then the attacker could re-use an old token
without detection.
I'm not sure what would happen if the issuer field was outside the signed
payload, but I'd rather be safe than sorry, and include it in the signature.

> Such a system will work for a relatively static relation between client and
> server only. Do you suggest a client should register with every resource
> server in advance?
>

I'm personally in favor of using RSA keys and not requiring registration,
but there are legitimate reasons for taking the opposite approach - for
example, resource servers might require registration because they want
developers to sign ToSs and such.

> What about dynamic clients? Suppose a client is just configured with a URL
> pointing to a PortableContacts resource. The client discovers the respective
> authz server and obtains a token. What if the client wants to sign the
> messages to the resource server?
>

I would propose to use RSA signing in this case.

> I think we can do more. Even installed applications can use signatures to
> protect messages on transport. What about that use case? Clearly they need
> appropriate key material. The token secret  issued by the authorization
> server could server that purpose.
>

What would the purpose of that signature be? Let's look at a few
possibilities:

- "I prove that I'm really a copy of the FooBar app"? You're just not gonna
be able to do that, because client apps can't keep secrets.
- "I prove that I'm the legitimate holder of this token"? If you don't leak
the token, then presenting the token itself proves this. Use SSL if you're
worried about leaking the token in transport.
- "I prove that the request wasn't tampered with in transport."? Use SSL.

What do you think?

Dirk.