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

[John Panzer <[e-mail]>]

Ah ok, I misread your field names as field values :).

Of course recipients can always choose to ignore the result of verifying
signatures (or not verify them at all) no matter what scheme you use.

Note that Magic Signatures is unabashedly an envelope, and well written
libraries make it hard to shoot yourself in the foot by opening an invalid
envelope.

Then there's the question of checking to see if the data in the envelope is
consistent with data outside the envelope.  A good way to do this is to
ignore the data outside the envelope and only use the verified, enveloped
data.  There are other ways if you have more complicated requirements; but
you only need to do complicated things if you have those complicated
requirements.

Of course, if some other part of your system is using data outside the
envelope to make important security decisions before your signature-aware
code gets to it, you may have issues.  But I think you have issues under ALL
these proposals in that case.

--
John Panzer / Google
[e-mail] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer



On Fri, Sep 24, 2010 at 9:20 AM, Richard L. Barnes <[e-mail]> wrote:

> Maybe I've misunderstood the Magic Signatures proposal.  I thought that the
> MagicSig blob actually contained the data that was signed, so that step (3)
> below would be unnecessary.  (Note that the object in Step 2 has only field
> *names*, not *values*.)  Including the data is the part of that scheme that
> causes some heartburn, since the recipient can choose not to verify the
> match against the original data (the HTTP request).
>
> Like I said earlier, though, Magic Signatures / JSON token could probably
> still be useful, as long as the signed data is reconstructed, not provided
> in the token.  The correspondence in my example was deliberate :)
>
> --Richard
>
>
>
>
> On Sep 24, 2010, at 12:11 PM, John Panzer wrote:
>
> 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
> [e-mail] / abstractioneer.org <http://www.abstractioneer.org/> /
> @jpanzer
>
>
>
> On Fri, Sep 24, 2010 at 8:26 AM, Richard L. Barnes <[e-mail]>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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>