Subject: Duplicating request component in an HTTP authentication scheme

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 27 May 2010 16:11:15 -0700

The OAuth working group is debating how to make signed authenticated requests. The two main questions is what do sign, and what to sign it with. On the 'what to sign part' we know we want to sign the request URI, HTTP method, and host name (among other cryptographic attributes such as timestamp and nonce).

OAuth 1.0 includes a normalization process taking the request and serializing it into a base string (which is then signed). For OAuth 2.0, we have two competing proposals:

1. Normalize the request and send just the signature
2. Normalize the request and send both the signature and the signed string

The advantage of #2 is that is moves the complexity from the client to the server. It is up to the server to figure out if the signed blob matches the request itself. The issue is that by doing so, the HTTP request is duplicated (HTTP request and authentication blob). Server will be required to compare the request with the blob to make sure they match. In practice, servers can ignore the request and just respond to the blob because it's the authenticated copy.

The ramification of #2 is that it moves the HTTP request bits to another layer, creating a sort of wrapper.

However, this approach should make it easier for client developers (who proved themselves to be extremely incompetent with the 1.0 specification) to get signatures right. It also allows for signing arbitrary data in addition to the HTTP request.

Thoughts?

EHL

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 27 May 2010 16:48:25 -0700

> The ramification of #2 is that it moves the HTTP request bits to another layer, creating a sort of wrapper.

And a security hole that you can drive a truck through.  If you are
going to sign the routing bits, then you have to verify that the
route is the same in both the blob and the message so that the
blob is not being used to bypass route security (e.g., firewalls)
to access internal paths.

If the server doesn't check the actual message, then don't bother
to sign anything.  In other words, I say #1, or at least I would
if this were not heading down the exact same road as S-HTTP.

> However, this approach should make it easier for client developers (who proved themselves to be extremely incompetent with the 1.0 specification) to get signatures right. It also allows for signing…

The same client developers will have the same competence issues
with regard to any new spec.  Just make sure that the protocol
breaks visibly if anything is done wrong, and then they can fix
their own protocol stacks if they want to implement this signing.

....Roy

---

From: Henrik Nordström <[email-masked]>
Date: Sun, 30 May 2010 19:19:24 +0200

tor 2010-05-27 klockan 16:11 -0700 skrev Eran Hammer-Lahav:
> The OAuth working group is debating how to make signed authenticated
> requests. The two main questions is what do sign, and what to sign it
> with. On the 'what to sign part' we know we want to sign the request
> URI, HTTP method, and host name (among other cryptographic attributes
> such as timestamp Tand nonce).

Sounds almost like HTTP Digest auth to me..

Regards
Henrik