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

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Adam Barth
> Sent: Tuesday, June 14, 2011 10:05 AM
> To: Manger, James H
> Cc: oauth
> Subject: Re: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
> 
> 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.

With OAuth 2.0, the id is the access token. With cookies, it makes it clear which MAC cookie is being used. It's required.

EHL

> Adam
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth