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

On Fri, Sep 24, 2010 at 9:06 AM, Eran Hammer-Lahav <eran@hueniverse.com>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
>
> 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.
> >>
> >> This is certainly correct ...
> >>
> >>
> >>> 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.
> >>
> >> ... but this does not follow.  The signer can specify what was signed
> >> without sending the data...
> >>
> >>> Even OpenID states which of the parameters on
> >>> the request were signed, which makes it easier to validate.
> >>
> >> ... 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]
> >
> > 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! :)
> >
> >> 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.
> >
> > 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
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>