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

From: "Manger, James H" <[email-masked]>
Date: Wed, 15 Jun 2011 00:25:12 +1000

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

---

From: Adam Barth <[email-masked]>
Date: Tue, 14 Jun 2011 10:05:25 -0700

> 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 lea…

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.

> 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 k…

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 14 Jun 2011 11:06:54 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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
> 
> >>> 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.
> 
> 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)
> >
> > 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).
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 15 Jun 2011 12:06:15 +1000

>>> Perhaps omitting the id parameter from the Authorization header
>>> would be an even better approach [when a cookie provides the key id]

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

How does the server know if a particular request with a "Authorization: MAC ..." header is using credentials from OAuth 2.0 or from Set-Cookie?

P.S. id=<cookie-name> is not ideal for indicating which MAC cookie is being used as there can be multiple cookies with the same cookie-name (eg set from sibling domains).

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 14 Jun 2011 22:00:30 -0700

> Of Manger, James H
> Sent: Tuesday, June 14, 2011 7:06 PM
> To: oauth
> >> 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.
> 
> How does the server know if a particular request with a "Authorization: MAC
> ..." header is using credentials from OAuth 2.0 or from Set-Cookie?

This should be pretty easy to resolve with a common-sense deployment and key identifiers.

> P.S. id=<cookie-name> is not ideal for indicating which MAC cookie is being
> used as there can be multiple cookies with the same cookie-name (eg set
> from sibling domains).

I'll let Adam answer that.

EHL

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 15 Jun 2011 15:39:24 +1000

> This should be pretty easy to resolve with a common-sense deployment and key identifiers.

You are right, Eran. Though putting a cookie-name in a key id field is a bit hacky, in practice a server can work this out with a little bit of code, perhaps a little config, and a little bit of sense choosing names.

I withdraw my suggestion for using the cookie-value as the key id.

--
James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 14 Jun 2011 22:48:07 -0700

This whole cookie thing is a 'a bit hacky'... that's part of what we're working with... :-)

EHL

> From: Manger, James H [mailto:[email-masked]]
> Sent: Tuesday, June 14, 2011 10:39 PM
> To: Eran Hammer-Lahav; oauth
> Subject: RE: [OAUTH-WG] FW: MAC: Cookie name or value as MAC key id
> 
> >> How does the server know if a particular request with a
> >> "Authorization: MAC ..." header is using credentials from OAuth 2.0 or
> from Set-Cookie?
> 
> You are right, Eran. Though putting a cookie-name in a key id field is a bit
> hacky, in practice a server can work this out with a little bit of code, perhaps a
> little config, and a little bit of sense choosing names.
>

---

From: Adam Barth <[email-masked]>
Date: Tue, 14 Jun 2011 23:30:45 -0700

> I'll let Adam answer that.

Yeah, that's a corner case that sucks.  Turns out cookie suck in a lot
of ways like that.  :)

Adam