Re: Duplicating request component in an HTTP authentication scheme

On May 27, 2010, at 4:11 PM, Eran Hammer-Lahav wrote:

> 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.

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 arbitrary data in addition to the HTTP request.
> 
> Thoughts?

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

Received on Thursday, 27 May 2010 23:48:55 UTC