Re: [OAUTH-WG] Signatures spec proposal, take 2

[Dirk Balfanz <[e-mail]>]

On Thu, Sep 23, 2010 at 7:59 PM, Richard L. Barnes <[e-mail]> wrote:

> Basically, this argument comes down to which validation pattern you prefer.
>
> OPTION 1:
> 0. Input = object + signature
> 1. Verify match between object data and HTTP fields
> 2. Verify signature over the object
>
> OPTION 2:
> 0. Input = signature
> 1. Construct object data from HTTP fields
> 2. Verify signature over the object
>
> So the choice is between memcmp and memcpy :)
>
> As Eran noted, there is some security advantage in option 2, since it
> forces the data in the signed object to correspond to the actual HTTP
> request instead of relying on the recipient to verify.  I would prefer that
> pattern, for that reason.
>

I think it's more robust to verify than to generate. In option 2, you have
to "guess" what the signer actually signed. To be fair, you have pretty good
signals, like the HTTP request line, the Host: header, etc., but in the end,
you don't _know_ that the signer really saw the same thing when they
generated the signature. I can't help but feeling that that's a bit of a
hack. In option 1, you always know what the signer saw when they generated
the signature, and it's up to you (the verifier) to decide whether that
matches your idea of what your endpoint looks like.


>
> That's not to say that the JSON token proposal is without any utility.  For
> example, option 2 could take as input a JSON token with the 'data' element
> removed; the recipient would then reconstruct the 'data' element from the
> HTTP request and verify the  token.
>
> As an editorial note, it would be very helpful if the JSON token document
> could be made a little more stand-alone w.r.t. the Magic Signatures draft.
>

Yeah, we were going back and forth on this. Should we just reference Magic
Signatures? Should we copy-and-paste? etc. The MS spec itself is more
complex, allows for multiple signatures (although not in the compact
serialization, which we use), has other serializations, etc. I thought that
it would be a bit of work for the reader to figure out exactly which pieces
of the MS spec they would have to understand in order to implement JSON
Tokens. I agree, though, that it is a bit, umh, unusual, to put excerpts of
another spec into your spec (especially if that ends up being 80% of your
spec :-).


>  An example would also help, just to illustrate the overall structure of
> the token.
>

Agreed.

Dirk.



>
> --Richard
>
>
>
> On Sep 23, 2010, at 10:32 PM, Eran Hammer-Lahav wrote:
>
> First, thanks for putting this together. It provides a pretty comprehensive
> story about the signed tokens proposal. I don’t have much to add at this
> point to the drafts.
>
> My position, which I have expressed many times before about this approach
> is:
>
> Any solution involving repeating the HTTP request elements in some sort of
> envelope will require validation .In this case, you need to define all the
> rules for validating the ‘audience’ parameter.
>
> This approach makes it too tempting for server developers to ignore the
> HTTP request and only use the values of the ‘audience’ and ‘method’
> parameters. In order to validate those parameters, the server needs to
> perform some sort of normalization (which eventually leads to the same
> signature mismatch problems). Not looking at the HTTP request will lead to
> security problems because it will allow bypassing existing HTTP firewall
> rules which operate on the request URI and HTTP method.
>
> As a matter of personal taste, this smells too much like SOAP. And that’s a
> really bad thing.
>
> I am not in favor of any solution that replicates components of the HTTP
> request within the request (as is the case here). Recent experience shows
> that with a little help and good libraries, developers can figure out how to
> normalize and sign an HTTP request successfully, when motivated.
>
> EHL
>
>
> On 9/23/10 7:07 PM, "Dirk Balfanz" <[e-mail]> wrote:
>
>
>
> On Thu, Sep 23, 2010 at 6:51 PM, Eran Hammer-Lahav <[e-mail]>
> wrote:
>
> In part II, how is the signature bound to the HTTP request URI? I see the
> method and body, but not the request URI.
>
>
> The request URI goes in the audience parameter that's defined in part I.
>
> Dirk.
>
>
>
> EHL
>
>
>
> On 9/23/10 3:39 PM, "Dirk Balfanz" <[e-mail] <
> http://[e-mail]> > wrote:
>
> Hi guys,
>
> sorry it took a while, but here is an updated proposal. It's still in three
> parts:
>
> Part I is about "JSON Tokens" that can be used for all sorts of things, not
> just OAuth:
> http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html
>
> Part II is about how to embed an OAuth token and (some parts of) an HTTP
> request into a JSON Token:
> http://balfanz.github.com/jsontoken-spec/draft-balfanz-signedoauth2-00.html
>
> Part III is how to use signatures instead of client secrets for assertions
> in OAuth:
>
> http://balfanz.github.com/jsontoken-spec/draft-balfanz-clientassertions-00.html
>
> Diffs from the last specs are:
>
> - JSON Tokens are now just a profile of Magic Signatures, which John Panzer
> has helpfully extended for this purpose
> - There was a vulnerability to masquerading attacks in the last proposal,
> which is addressed in this proposal by adding a data_type parameter that is
> part of the signature, but _not_ part of the payload.
> - no more support of X.509 certs - the only supported format for discovered
> public keys is now the Magic Key format. We'll give people tools (which are
> quite easy to write) to convert their self-signed or CA-issued certs to
> magic keys.
> - The specs are now formatted as I-Ds.
>
> Comments, please!
>
> Dirk.
>
>
>
>
>  _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>