Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id

[Adam Barth <[e-mail]>]

On Tue, Jun 14, 2011 at 7:25 AM, Manger, James H
<[e-mail]> wrote:
>>> 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.

Oh, we'd put that in the ext field because it's specific to the Cookie
instantiating of the protocol.  If you're using a SAML or whatever
other instantiation of the protocol, you'll want to put that stuff in
the ext field rather than cluttering up the base protocol.

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

Yeah, I've often wondered whether we should remove the id parameter
from the Authorization header.  My understanding is that it plays some
important role in the OAuth instantiation of the protocol.  There's
also the question about what to do when you have multiple cookies with
MAC attributes.  In that case, having the id to disambiguate seems
useful.

Adam