Subject: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

From: Eric Sachs <[email-masked]>
Date: Thu, 23 Sep 2010 17:30:05 -0700

Google wanted to re-state our long standing opinions on HTTP signature
mechanisms in the OAuth2 spec.  The short version is that standards for
signing parts of an HTTP request have value in use-cases other than OAuth2,
and thus they should be defined outside the spec, and just referenced from
the spec similar to how we reference other Internet security building blocks
like SSL.  Those signature standards are likely to in turn reference
optional mechanisms for key rotation and discovery, as well as reference
different crypto schemes like HMAC or RSA.

There are already people in the identity community working on specs that are
related to OAuth2, but which have value in other use-cases.  For example,
there are people working on defining standards around token formats, signing
blobs of different types (such as a token and/or HTTP request), key
discovery/rotation, and consumer-key namespaces across vendors.  Dirk
Balfanz from Google recently sent out updated drafts of some of those specs,
and they also leverage specs that John Panzer from Google has worked on for
Magic Signatures, as well as input from people in the community who are not
at Google.

However even though Google is working on those specs, we still believe it is
a mistake to delay the OAuth2 core spec standard to wait on broad agreement
for a "signature proposal," just as it would be a mistake to delay the
OAuth2 core spec to wait on the standards efforts around token formats,
token signing, key discovery/rotation, consumer-key naming, etc.

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 24 Sep 2010 00:45:46 +0000

Eric, Microsoft shares some of the same views, we would like to see the WG charter expanded to cover these additional items (so we have a home for these), we would like to see that proposed and agreed upon at the November meeting if at all possible.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Sachs
Sent: Thursday, September 23, 2010 5:30 PM
To: OAuth WG
Subject: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

Google wanted to re-state our long standing opinions on HTTP signature mechanisms in the OAuth2 spec.  The short version is that standards for signing parts of an HTTP request have value in use-cases other than OAuth2, and thus they should be defined outside the spec, and just referenced from the spec similar to how we reference other Internet security building blocks like SSL.  Those signature standards are likely to in turn reference optional mechanisms for key rotation and discovery, as well as reference different crypto schemes like HMAC or RSA.

There are already people in the identity community working on specs that are related to OAuth2, but which have value in other use-cases.  For example, there are people working on defining standards around token formats, signing blobs of different types (such as a token and/or HTTP request), key discovery/rotation, and consumer-key namespaces across vendors.  Dirk Balfanz from Google recently sent out updated drafts of some of those specs, and they also leverage specs that John Panzer from Google has worked on for Magic Signatures, as well as input from people in the community who are not at Google.

However even though Google is working on those specs, we still believe it is a mistake to delay the OAuth2 core spec standard to wait on broad agreement for a "signature proposal," just as it would be a mistake to delay the OAuth2 core spec to wait on the standards efforts around token formats, token signing, key discovery/rotation, consumer-key naming, etc.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 23 Sep 2010 18:11:31 -0700

It is pretty clear from the recent public response that a core specification without signatures is going to be viewed as weak and insecure. This has been my position for over a year, and if it wasn't clear, I am going to continue expressing it.

We have enough interest to get a basic signature support in the core specification, one that is not driven by enterprise use cases, complex identity solutions, or large distributed systems. Given the recent Twitter migration to OAuth 1.0a proved that with a big enough carrot (or stick, depending on your view), developers figure it out. I believe that an OAuth 1.0a style signature can be easily developed and added to the core specification as an optional feature.

This is not new. This was agreed upon at the Anaheim meeting. I took the signature language out of the draft in order to focus the discussion on the other components. Now that -10 is pretty solid (normative language-wise), it is time to bring it back in.

Draft -11 will include a signature proposal, even if that means a short delay.

The arguments about delaying the core spec are meritless, given that a growing number of companies are releasing OAuth 2.0 APIs using the latest stable draft. We can easily do a WGLC for the current stable components, and add signatures without changing those. This working group does not make technical and architectural decisions based on the timeline needs of any company. We do what is best for the web and we take as much time as necessary.

As an aside, while companies can certainly express their corporate position on matters, this is a working group of individuals, and consensus is based solely on individual voices.

EHL

On 9/23/10 5:30 PM, "Eric Sachs" <[email-masked]> wrote:

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 24 Sep 2010 01:19:24 +0000

I have not seen the support to bring signature support back into core, have not seen the public response either, all I have seen is you raising this as an issue. We should keep the original agreement to move signatures out of core, there is enough activity on signatures that we are confident that it will proceed as a separate item.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, September 23, 2010 6:12 PM
To: Eric Sachs; OAuth WG
Subject: Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec

EHL

---

From: Eric Sachs <[email-masked]>
Date: Thu, 23 Sep 2010 18:27:57 -0700

>> I believe that an OAuth 1.0a style signature
How about we start with exactly an OAuth 1.0a style signature?  It may be
tricky, but there are still client libraries and some web-services that
handle them.

Like Tony, I also have not heard requests for a new signature approach, but
one of the reasons is that there are already developers who are using OAuth2
& WRAP style approaches combined with OAuth1 signatures.  So why not simply
have a section in the core spec that mentions the option of using signatures
and gives OAuth1 as one of the possible approaches?

That avoids the potential concern of any large delay in the core spec to get
agreement on a new signature mechanism, but gives an option that can quickly
be used by developers, and provides a place to hook in other signature
schemes in the future.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 23 Sep 2010 18:30:16 -0700

I agree with your point that consensus is based on individual voices.

I agree with Eric's points that signatures are a generic security mechanism and that signatures should be in a separate spec. 

-- Dick

On 2010-09-23, at 6:11 PM, Eran Hammer-Lahav wrote:

> It is pretty clear from the recent public response that a core specification without signatures is going to be viewed as weak and insecure. This has been my position for over a year, and if it wasn’t clear, I am going to continue expressing it.
> 
> This is not new. This was agreed upon at the Anaheim meeting. I took the signature language out of the draft in order to focus the discussion on the other components. Now that –10 is pretty solid (normative language-wise), it is time to bring it back in.
> 
> Draft –11 will include a signature proposal, even if that means a short delay.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 23 Sep 2010 22:38:22 -0400

I also agree with the observation about consensus being based on  
individual voices.

I don't think it's accurate to say that signatures are a generic  
security mechanism.  As I would think we learned from OAuth 1.0[a], it  
can actually be pretty subtle to define how signatures are used in a  
given context.

I doubt that a spec that only includes a "bearer token" model will not  
have enough of a security story to get past SECDIR and IESG review,  
especially without some careful thinking about when TLS is required  
and how it is negotiated (for example, you may need something like  
HSTS [1]).

On the other hand, it seems like a sensible compromise approach to re- 
use the signature scheme from OAuth 1.0a.  If there is interest in  
some other type of signing scheme, then of course the cost of this  
approach is having some sort of versioning / negotiation for signature  
algorithms.  But this may already be necessary to distinguish between  
signed requests and bearer-token requests.

--Richard

[1] <http://tools.ietf.org/html/draft-hodges-strict-transport-sec>

On Sep 23, 2010, at 9:30 PM, Dick Hardt wrote:

> I agree with Eric's points that signatures are a generic security  
> mechanism and that signatures should be in a separate spec.
>
> -- Dick
>
>
>> It is pretty clear from the recent public response that a core  
>> specification without signatures is going to be viewed as weak and  
>> insecure. This has been my position for over a year, and if it  
>> wasn’t clear, I am going to continue expressing it.
>>
>> We have enough interest to get a basic signature support in the  
>> core specification, one that is not driven by enterprise use cases,  
>> complex identity solutions, or large distributed systems. Given the  
>> recent Twitter migration to OAuth 1.0a proved that with a big  
>> enough carrot (or stick, depending on your view), developers figure  
>> it out. I believe that an OAuth 1.0a style signature can be easily  
>> developed and added to the core specification as an optional feature.
>>
>> This is not new. This was agreed upon at the Anaheim meeting. I  
>> took the signature language out of the draft in order to focus the  
>> discussion on the other components. Now that –10 is pretty solid  
>> (normative language-wise), it is time to bring it back in.
>>
>> The arguments about delaying the core spec are meritless, given  
>> that a growing number of companies are releasing OAuth 2.0 APIs  
>> using the latest stable draft. We can easily do a WGLC for the  
>> current stable components, and add signatures without changing  
>> those. This working group does not make technical and architectural  
>> decisions based on the timeline needs of any company. We do what is  
>> best for the web and we take as much time as necessary.
>>
>> As an aside, while companies can certainly express their corporate  
>> position on matters, this is a working group of individuals, and  
>> consensus is based solely on individual voices.
>>
>> EHL
>>
>>
>>
>>
>>
>>
>> Google wanted to re-state our long standing opinions on HTTP  
>> signature mechanisms in the OAuth2 spec.  The short version is that  
>> standards for signing parts of an HTTP request have value in use- 
>> cases other than OAuth2, and thus they should be defined outside  
>> the spec, and just referenced from the spec similar to how we  
>> reference other Internet security building blocks like SSL.  Those  
>> signature standards are likely to in turn reference optional  
>> mechanisms for key rotation and discovery, as well as reference  
>> There are already people in the identity community working on specs  
>> that are related to OAuth2, but which have value in other use- 
>> cases.  For example, there are people working on defining standards  
>> around token formats, signing blobs of different types (such as a  
>> token and/or HTTP request), key discovery/rotation, and consumer- 
>> key namespaces across vendors.  Dirk Balfanz from Google recently  
>> sent out updated drafts of some of those specs, and they also  
>> leverage specs that John Panzer from Google has worked on for Magic  
>> Signatures, as well as input from people in the community who are  
>> not at Google.
>>
>> However even though Google is working on those specs, we still  
>> believe it is a mistake to delay the OAuth2 core spec standard to  
>> wait on broad agreement for a "signature proposal," just as it  
>> would be a mistake to delay the OAuth2 core spec to wait on the  
>> standards efforts around token formats, token signing, key  
>> discovery/rotation, consumer-key naming, etc.
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 23 Sep 2010 19:51:19 -0700

Thanks Richard.

FWIW, RFC 5849 was stuck in IESG discuss until I the language regarding the use of HTTPS with plaintext secrets was changed from SHOULD to MUST. Before the change, the security consideration section clearly highlighted the danger in not using HTTPS. OAuth 2.0 adds support for short-lived tokens which addresses *some* of these concerns, but completely lacks any requirements for issuing short-lived bearer tokens, or provides any guidance on what short-lived is.

I am happy to include the signature scheme from 1.0a as-is, but I think we can easily simplify it, as draft -05 demonstrated using less than 4 pages. It can be made even simpler.

I think draft -05 went too far in terms of additional parameters for requesting tokens with secrets. Since the core spec lacks any form of discovery, I think servers should simply issue whatever token they deem appropriate to the client (bearer, with secret, etc.). Other extensions can define parameters to allow the client to ask, and the server to advertise whaich schemes are supported.

My approach is for the server to issue a token with two additional parameters: signature algorithm and secret. Based on that, the client will send requests with a few additional parameters (nonce, timestamp, signature - maybe combined into one).

If it wasn't clear, the reason why I am back at fighting for this after taking a break for a few months, is based on the recent positive experience from the Twitter migration. To me, it completely voids the arguments that normalization on the client side is too hard.

EHL

On 9/23/10 7:38 PM, "Richard Barnes" <[email-masked]> wrote:

I also agree with the observation about consensus being based on individual voices.

I don't think it's accurate to say that signatures are a generic security mechanism.  As I would think we learned from OAuth 1.0[a], it can actually be pretty subtle to define how signatures are used in a given context.

I doubt that a spec that only includes a "bearer token" model will not have enough of a security story to get past SECDIR and IESG review, especially without some careful thinking about when TLS is required and how it is negotiated (for example, you may need something like HSTS [1]).

On the other hand, it seems like a sensible compromise approach to re-use the signature scheme from OAuth 1.0a.  If there is interest in some other type of signing scheme, then of course the cost of this approach is having some sort of versioning / negotiation for signature algorithms.  But this may already be necessary to distinguish between signed requests and bearer-token requests.

--Richard

-- Dick

 EHL

 On 9/23/10 5:30 PM, "Eric Sachs" <[email-masked] <x-msg://483/[email-masked]> > wrote:

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Sep 2010 09:44:28 -0400

> If it wasn’t clear, the reason why I am back at fighting for this
> after taking a break for a few months, is based on the recent positive
> experience from the Twitter migration. To me, it completely voids the
> arguments that normalization on the client side is too hard.

I wholeheartedly disagree with this statement. OAuth 1.0(a) libraries
have been around for a few years, and are now available on most every
platform. The bugs have already been ironed out, and that wasn't easy to
do. Even so, it can still be tricky to get client libraries to behave in
some frameworks, and the biggest problem is the fact that the server has
to guess what the client thought it signed when trying to build the
signature. 

I think that any signature method that we end up using needs to rely
less on magic and anecdote and more on explicit declaration. I think
that Brian Eaton's approach of sending the bare string that was signed,
which was also a JSON element that could be parsed and validated, was an
essential simplification. Even OpenID states which of the parameters on
the request were signed, which makes it easier to validate. 

In short, I am against anything that requires guessing on the part of
the receiver of a request. 

 -- Justin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Sep 2010 10:10:34 -0400

> less on magic and anecdote and more on explicit declaration.

This is certainly correct ...

> I think
> essential simplification.

... but this does not follow.  The signer can specify what was signed  
without sending the data...

> Even OpenID states which of the parameters on

... as in this pattern.  There are some other examples of elements of  
the signed object being conditionally included:
1. HTTP Digest authentication [1]
2. The IKEv2 key exchange messages [2]

As has been pointed out before, there is a security risk in sending  
the signed request data itself (as opposed to metadata that allows the  
recipient to reconstruct the data), because the recipient can choose  
not to verify the binding between the signed data and the request.

--Richard

[1] <http://tools.ietf.org/html/rfc2617#section-3.2.2>
[2] <http://tools.ietf.org/html/rfc4306#section-1.2>

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Sep 2010 10:51:08 -0400

> 2. The IKEv2 key exchange messages [2]

And I'm marginally OK with either pattern, though I think that the
former is a much cleaner way to do it. I believe either case to be
worlds better than the OAuth 1.0 method, which has caused countless
problems. I actually had to help someone debug between sending that
first email and this one, so I can attest that the problem has not gone
away! :)

> not to verify the binding between the signed data and the request.

Yes, there is certainly a risk if someone just checks the signature and
does not verify the content of the message. This is a bad implementation
of an authorization system, to be sure, and it's an issue that people
need to be aware of. But simply signing metadata doesn't completely
solve the problem, either. In both cases there can be parameters that
are outside of the signed request that need to be checked and treated
appropriately. 

 -- Justin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Sep 2010 11:26:25 -0400

> are outside of the signed request that need to be checked and treated

Ah, perhaps I was unclear.  I didn't mean *signing* metadata, I meant  
*sending* metadata.  Using a completely made-up syntax:

1. Signer computes signature sig_val over data object:
    { user_agent: "Mozilla", method: "GET" }
2. Signer sends { signed_fields: ['user_agent', 'method'], sig:  
sig_val }
3. Recipient reconstructs data object using signed_fields
4. Recipient verifies sig_val == sign(reconstructed_object)

--Richard

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 24 Sep 2010 09:06:10 -0700

Validating the signed data delivered with the request is as much magic as the current 1.0 approach. Go write the validation rules and see.

I'm getting really tired of this argument because it is not grounded in reality. Any attempt to compare the HTTP request to what was signed, whether it is sent with the request or not, is as difficult. Sending the signed data just makes it easier for the server to make bad assumptions and be flexible in an insecure way. 

EHL

---

From: John Panzer <[email-masked]>
Date: Fri, 24 Sep 2010 09:11:32 -0700

Richard,

I'm a bit confused because the made-up example you give below is,
essentially, what Magic Signatures does.  The algorithm you present is
basically the correct one IMHO.  Are you assuming that the recipient is
_also_ using the HTTP-level method and URL path for some  important security
decision?

(Note:  I'm assuming it's fine to use this unverified host/path data for
tentative routing to an intended recipient, because the worst thing a MITM
attacker can possibly do is to route it to the wrong recipient.  As long as
the recipient uses only signed information to decide whether it will
actually ACCEPT the data, it will be fine.  MITM attackers can always
mis-route even signed messages of course, given that firewalls etc. are not
aware of signatures, so I don't see this as a distinction.)

--
John Panzer / Google
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Fri, Sep 24, 2010 at 8:26 AM, Richard L. Barnes <[email-masked]> wrote:

> 2. Signer sends { signed_fields: ['user_agent', 'method'], sig: sig_val }

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Sep 2010 12:20:31 -0400

Maybe I've misunderstood the Magic Signatures proposal.  I thought  
that the MagicSig blob actually contained the data that was signed, so  
that step (3) below would be unnecessary.  (Note that the object in  
Step 2 has only field *names*, not *values*.)  Including the data is  
the part of that scheme that causes some heartburn, since the  
recipient can choose not to verify the match against the original data  
(the HTTP request).

Like I said earlier, though, Magic Signatures / JSON token could  
probably still be useful, as long as the signed data is reconstructed,  
not provided in the token.  The correspondence in my example was  
deliberate :)

--Richard

On Sep 24, 2010, at 12:11 PM, John Panzer wrote:

> essentially, what Magic Signatures does.  The algorithm you present  
> is basically the correct one IMHO.  Are you assuming that the  
> recipient is _also_ using the HTTP-level method and URL path for  
> some  important security decision?
>
> (Note:  I'm assuming it's fine to use this unverified host/path data  
> for tentative routing to an intended recipient, because the worst  
> thing a MITM attacker can possibly do is to route it to the wrong  
> recipient.  As long as the recipient uses only signed information to  
> decide whether it will actually ACCEPT the data, it will be fine.   
> MITM attackers can always mis-route even signed messages of course,  
> given that firewalls etc. are not aware of signatures, so I don't  
> see this as a distinction.)
>
> --
> John Panzer / Google
> [email-masked] / abstractioneer.org / @jpanzer
>
>
>
> Ah, perhaps I was unclear.  I didn't mean *signing* metadata, I  
> meant *sending* metadata.  Using a completely made-up syntax:
>

---

From: John Panzer <[email-masked]>
Date: Fri, 24 Sep 2010 09:21:34 -0700

On Fri, Sep 24, 2010 at 9:06 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> Validating the signed data delivered with the request is as much magic as
> the current 1.0 approach. Go write the validation rules and see.
>

Done that (for the specific case of Salmon).  The only trick is to write the
code so that if the message were delivered via a note tied to a rock thrown
through your window, it would have the same security properties as the ones
delivered via HTTP.  This is very amenable to static analysis.

Is there a specific attack vector that we could discuss that you're worried
about?

>
> I'm getting really tired of this argument because it is not grounded in
> reality. Any attempt to compare the HTTP request to what was signed, whether
> it is sent with the request or not, is as difficult. Sending the signed data
> just makes it easier for the server to make bad assumptions and be flexible
> in an insecure way.
>
> EHL
>

---

From: John Panzer <[email-masked]>
Date: Fri, 24 Sep 2010 09:34:56 -0700

Ah ok, I misread your field names as field values :).

Of course recipients can always choose to ignore the result of verifying
signatures (or not verify them at all) no matter what scheme you use.

Note that Magic Signatures is unabashedly an envelope, and well written
libraries make it hard to shoot yourself in the foot by opening an invalid
envelope.

Then there's the question of checking to see if the data in the envelope is
consistent with data outside the envelope.  A good way to do this is to
ignore the data outside the envelope and only use the verified, enveloped
data.  There are other ways if you have more complicated requirements; but
you only need to do complicated things if you have those complicated
requirements.

Of course, if some other part of your system is using data outside the
envelope to make important security decisions before your signature-aware
code gets to it, you may have issues.  But I think you have issues under ALL
these proposals in that case.

On Fri, Sep 24, 2010 at 9:20 AM, Richard L. Barnes <[email-masked]> wrote:

> Maybe I've misunderstood the Magic Signatures proposal.  I thought that the
> MagicSig blob actually contained the data that was signed, so that step (3)
> below would be unnecessary.  (Note that the object in Step 2 has only field
> *names*, not *values*.)  Including the data is the part of that scheme that
> causes some heartburn, since the recipient can choose not to verify the
> match against the original data (the HTTP request).
>
> Like I said earlier, though, Magic Signatures / JSON token could probably
> still be useful, as long as the signed data is reconstructed, not provided
> in the token.  The correspondence in my example was deliberate :)
>
> --Richard
>
>
>
>
> On Fri, Sep 24, 2010 at 8:26 AM, Richard L. Barnes <[email-masked]>wrote:
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Sep 2010 12:59:27 -0400

> Then there's the question of checking to see if the data in the  
> envelope is consistent with data outside the envelope.  A good way  
> to do this is to ignore the data outside the envelope and only use  
> the verified, enveloped data.

This is precisely the problem.  But think about what "only using the  
data inside the envelope" means in the context of OAuth -- stuffing  
all the relevant parts of the HTTP request inside the envelope.  I  
admit that I'm not up to speed on the latest OAuth specs, but in  
earlier versions, there were several parts of the HTTP request that  
were included under the OAuth signature, so this would amount to a lot  
of duplication.

The alternative is to somehow ensure that the data outside the  
envelope are the same as the data inside the envelope.  Which brings  
us back to the two mechanisms we were talking about before for doing  
that:
1. Send the enveloped data and checking that the inside matches the  
outside
2. Just send the envelope (not the data) and reconstruct the data from  
the request based on the outside information.

Just using a JSON token / Magic Signature object that includes all the  
relevant fields requires that you do (1), which has the risk that the  
recipient can skip the check.  You can do (2) with a "meta-MagicSig"  
where the content is included by reference (e.g., to field names) and  
the actual enveloped data structure is built and verified by the  
recipient.

As far as a specific attack vector, I think the idea is that a  
recipient could get a request like the following (again, with made-up  
syntax)...

POST /malevolent.php HTTP/1.1
Authorization: oauth { method: "GET", path: "innocuous.jpg", sig:  
valid_sig }

... and based on the validity of the signature, go ahead and grant the  
request.

--Richard