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

["Richard L. Barnes" <[e-mail]>]

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.

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.  An example would also help, just to illustrate the  
overall structure of the token.

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