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
jpan...@google.com / abstractioneer.org / @jpanzer
On Fri, Sep 24, 2010 at 8:26 AM, Richard L. Barnes <rbar...@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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
