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

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
jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Fri, Sep 24, 2010 at 8:26 AM, Richard L. Barnes <rbarnes@bbn.com> wrote:

>  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.
>>
>
> 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
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>