From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Justin Richer <jricher@mitre.org>
Date: Fri, 24 Sep 2010 09:06:10 -0700
Thread-Topic: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec
Thread-Index: ActcAtt7x3XPvXLOSvSMNggg+yObhA==
Message-ID: <51097F4B-C0C7-499E-BB51-C55E55D2291A@hueniverse.com>
References: <C8C16037.3AC75%eran@hueniverse.com>
 <1285335868.15179.98.camel@localhost.localdomain>
 <440E4C9A-41A2-4203-80B8-B6967D886A80@bbn.com>
 <1285339868.15179.139.camel@localhost.localdomain>
In-Reply-To: <1285339868.15179.139.camel@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Google's view on signatures in the core OAuth2 spec
Precedence: list

Validating the signed data delivered with the request is as much magic as t=
he 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 rea=
lity. Any attempt to compare the HTTP request to what was signed, whether i=
t 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 flexibl=
e in an insecure way.=20

EHL

On Sep 24, 2010, at 10:51, "Justin Richer" <jricher@mitre.org> wrote:

>>> I think that any signature method that we end up using needs to rely
>>> less on magic and anecdote and more on explicit declaration.
>>=20
>> This is certainly correct ...
>>=20
>>=20
>>> I think
>>> that Brian Eaton's approach of sending the bare string that was =20
>>> signed,
>>> which was also a JSON element that could be parsed and validated, =20
>>> was an
>>> essential simplification.
>>=20
>> ... but this does not follow.  The signer can specify what was signed =20
>> without sending the data...
>>=20
>>> Even OpenID states which of the parameters on
>>> the request were signed, which makes it easier to validate.
>>=20
>> ... as in this pattern.  There are some other examples of elements of =20
>> the signed object being conditionally included:
>> 1. HTTP Digest authentication [1]
>> 2. The IKEv2 key exchange messages [2]
>=20
> 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! :)
>=20
>> As has been pointed out before, there is a security risk in sending =20
>> the signed request data itself (as opposed to metadata that allows the =
=20
>> recipient to reconstruct the data), because the recipient can choose =20
>> not to verify the binding between the signed data and the request.
>=20
> 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.=20
>=20
> -- Justin
>=20