>> There have been suggestions that the MAC calculation could/should cover
>> the key id. In that situation it is even more crucial that the id field
>> isn't just a
>> name referring to the real value elsewhere - as then the security changes
>> based on the syntax used to issue the credentials.
>What suggestions? We could not come up with any reason to include the key
>identifier in the >normalized string.
Adam Barth said "one possibility is to include the value of the Cookie header
in the MAC". That was in response to Robert Sayre's suggestion of a
server-provided nonce ("opaque" parameter) that would be covered by the MAC,
which Adam said could go into the key id. Adam did go on to say he hadn't seen
much demand for this feature from site operators he has talked to.
[http://www.ietf.org/mail-archive/web/oauth/current/msg06631.html]
So not a complete suggestion with proposed text for the spec -- just a hint
that it was a possible design. HTTP Digest signs the username, for instance. I
don't have a specific reason to sign the key id. I don't think it would be
harmful. Perhaps it could help where the key id is actually a combination of
complicated assertions (eg SAML) by giving a bit more protection against
attacks that modify the Authorization header. Various PKI specs include a cert
id in the data they sign, purportedly for security/legal reasons.
The point was that an id field that is sometimes the key id, but at other times
just a pointer to the key id (with no indication of which mode is in use), does
not feel like a good design -- at least not until I understand the compelling
reason for keeping the Cookie header when using MAC with Cookie-issued
credentials.
Adam provides an ok argument for why tacking MAC-... attributes on to an
existing cookie will be the simplest implementation choice. (Thanks)
>Most folks who run web sites use cookies to generate sessions. These
>folks will layer the MAC protections on top of their existing systems
>by adding a couple cookie attributes and verifying an HMAC. If we
>removed the MAC cookie from the Cookie header, the Cookie header would
>be different in supporting and legacy user agents, causing pain and
>misery.
>
>It might be instructive to try using MAC in a real deployment. You'll
>see immediately why this behavior is preferable.
Perhaps omitting the id parameter from the Authorization header would be an
even better approach than using the cookie name. It avoids that minor
repetition, and is an unambiguous signal that the key id comes from elsewhere
(ie from a cookie value).
--
James Manger
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
