Subject: [websec] Smart Cookies

From: Trevor Perrin <[email-masked]>
Date: Mon, 22 Jul 2013 01:02:21 -0700

Hi,

Here's an attempt to combine the benefits of a couple cookie
proposals.  I'm curious what people think...

"Smart cookies"
=============

Rationale
----------
The "Origin Cookie" proposal seems a good solution to cookie scoping.
The "ChannelID" proposal seems a good approach to the "bearer token"
problem, but requires on-the-wire TLS changes and a client signature
for all TLS connections.

Smart cookies combine the benefits of both proposals, and don't
require TLS changes or client signatures.

Smart cookies are bound to the Origin, and cannot be read or written
from other Origins.  Smart cookies are also cryptographically bound to
two TLS connections:
 1)  The TLS connection on which the server set the cookie
 2)  The TLS connection on which the client is returning the cookie

This binding is done by a cryptographic "MAC" sent from browser to
server along with each smart cookie.

The "smart" attribute
----------------------
Smart cookies are set the same way as normal cookies, but have an
additional "smart" attribute:

  Set-Cookie: session=123; secure; smart;

Smart cookies SHALL only be set from HTTPS connections.  The "domain"
attribute MUST be omitted, and the "secure" attribute MUST be present.

Smart cookies are backwards-compatible.  Older browsers ignore the
"smart" attribute, and return it as a regular cookie.  A smart cookie
aware browser does two extra things:

 (1) The smart cookie is bound to the Origin that set it.  The smart
cookie is only returned to that Origin.  The smart cookie can only be
overwritten by that Origin.  If a smart cookie is being returned, any
cookies with the same name stored in parent domains are ignored.

 (2) When returning a smart cookie, the browser returns an associated MAC, e.g.

  Cookie: session=123
  Smart-Cookie-MAC: session=lMVoh17EQNE1Rd6nT+hh6A==

MAC calculation
----------------
The MAC is calculated as follows:

  - cookie_str: HTTP Request line for cookie ("Cookie: session=123")
  - cookie_key: 32 byte secret key derived from the TLS master secret
for the connection on which the server sent the cookie.
  - cookie_binding: 32 byte value derived from the TLS master secret
for the connection on which the client is returning the cookie.

(The key and binding values are derived using RFC 5705 with labels
"smart_cookie_key" and "smart_cookie_binding".)

  MAC = HMAC-SHA256(cookie_key, cookie_binding || cookie_str)[0:16]

Key handling
-------------
The browser can easily calculate the key and binding values for every
TLS connection.  For every smart cookie the browser receives in a TLS
connection, the browser stores the connection's cookie_key with the
cookie.  For every smart cookie returned to the server in a TLS
connection, the browser uses the cookie's key along with the
connection's binding value to calculate the MAC.

The cookie_key values are secrets which the browser MUST never send
over the network, or make accessible to javascript.

Advertising support
--------------------
Browsers MUST advertise support for smart cookies in every HTTP
Request with "Smart-Cookies: true".  This lets the website allow
legacy clients to use old cookies, while requiring smart cookies for
capable clients so they are protected from cookie forcing.

Misc
-----
 * A website can have stateless smart cookies by including the
cookie_key in the cookie, and encrypting the cookie to itself.  On
receiving such a cookie, the website will decrypt it, then check its
MAC.
 * A website could ignore the MAC values, and just use smart cookies
for their origin-binding properties.
 * An attacker who somehow observes a transmitted smart cookie and MAC
can't replay it on a different TLS connection (as it's tied to its
connection's binding value), and can't calculate the MAC for a
different connection without the cookie_key.

Trevor

---

From: Tobias Gondrom <[email-masked]>
Date: Mon, 22 Jul 2013 16:55:09 +0800

Hi Trevor,

<no hats>

interesting.
But am not totally sure, I understand what specific threat you want to
protect against with the smart cookie?
- CSRF?
Don't see how this would exactly help here?

- MitM?
IMHO, today people who put a MitM of a SSL communication to steal the
cookie and abuse it, are using either SSL Stripping, SSL downgrading or
actualyl have a fake certificate impersonating the server and then open
a second line with the right cert to the server. So also not sure how
this would help here?

Maybe you could explain a little the specific risk/attack scenario that
you want to protect against?

Best regards, Tobias

On 22/07/13 16:02, Trevor Perrin wrote:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 22 Jul 2013 10:13:15 -0700

> protect against with the smart cookie?

The threats mentioned here:

http://www.ietf.org/mail-archive/web/websec/current/msg01719.html

Not CSRF.

The "bearer token" issue is solved because an intercepted smart cookie
can't be used in a different TLS connection (the MAC will fail).

The "cookie scoping" issues are solved because smart cookies for an
Origin can only be read / written by that Origin.

> a second line with the right cert to the server. So also not sure how

It would prevent that because the transmitted cookie from the
legitimate browser is bound to that browser's TLS connection, via a
MAC.  So the MITM can't reuse the cookie.

Trevor

---

From: Joseph Bonneau <[email-masked]>
Date: Mon, 22 Jul 2013 13:20:33 -0400

> MAC.  So the MITM can't reuse the cookie.

Perhaps like Tobias I'm not seeing how this is enforced. You mention in
your proposal that "The browser can easily calculate the key and binding
values for every TLS connection" indicating that an attacker who steals the
cookie value "session=123" could simply start a new TLS connection and
send "session=123",
computing a new MAC based on the new TLS connection details and this would
appear legitimate to the server.

What prevents this, which seems like an attack the system is designed to
guard against?

Joe

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 22 Jul 2013 10:27:45 -0700

On Mon, Jul 22, 2013 at 10:20 AM, Joseph Bonneau <[email-masked]> wrote:
> Perhaps like Tobias I'm not seeing how this is enforced. You mention in your
> proposal that "The browser can easily calculate the key and binding values
> for every TLS connection" indicating that an attacker who steals the cookie
> value "session=123" could simply start a new TLS connection and send
> "session=123", computing a new MAC based on the new TLS connection details
> and this would appear legitimate to the server.
>

The "cookie_key", which is derived from the original TLS connection
where the server sent the cookie.

This key is never transmitted, so it won't be known to a MITM attacker.

Trevor

---

From: Joseph Bonneau <[email-masked]>
Date: Mon, 22 Jul 2013 13:48:41 -0400

> This key is never transmitted, so it won't be known to a MITM attacker.

Thanks, this makes more sense now. This seems to means the server either
needs to store (and verify) the correct cookie_key for every connection it
has ever sent a cookie on, or use the "stateless" variant you mentioned. I
think simplifying the proposal and only having the "stateless" variant
makes more sense-really this is just assuming the server has a long-lived
cookie-minting secret, which is also assumed in ChannelID and other
proposals. The difference here is that instead of binding to an
Origin-bound certificate to lock to a particular client, you're binding to
the original TLS master secret on which the cookie was set. Makes sense to
me now but I think this could be spelled out much more clearly.

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 22 Jul 2013 11:49:42 -0700

On Mon, Jul 22, 2013 at 10:48 AM, Joseph Bonneau <[email-masked]> wrote:
>> On Mon, Jul 22, 2013 at 10:20 AM, Joseph Bonneau <[email-masked]>
[...]
> has ever sent a cookie on, or use the "stateless" variant you mentioned.

The server can store the cookie_key with the user's session state -
either in a database, or in an encrypted cookie for stateless
operation.

The server can also ignore the cookie_key and MAC, and then these are
just "Origin cookies".

> I
> think simplifying the proposal and only having the "stateless" variant makes
> more sense

Whether to be stateful or stateless is up to the server.  I'm not sure
what simplification you're proposing?

> -really this is just assuming the server has a long-lived
> proposals. The difference here is that instead of binding to an Origin-bound
> certificate to lock to a particular client, you're binding to the original
> TLS master secret on which the cookie was set.

That's one difference.  The other difference is that these cookies
have Origin scope, so they protect against "cookie scoping" integrity
attacks that ChannelID does not:

Trevor

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 23 Jul 2013 11:27:43 +0800

Ok. Thanks for the explanation. I can see how this could help data
leakage against sub-domains.

As far as I understand the best solution would be HSTS incl subdomains
plus "secure" cookie. But if that is not feasible for some subdomains
for some reason, the smart cookie would allow to compensate?

Best regards, Tobias

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 22 Jul 2013 22:36:52 -0700

> for some reason, the smart cookie would allow to compensate?

"includeSubdomains" is often infeasible.  As a data point: Chrome has
preloaded HSTS for ~180 non-Google hostnames, but only ~100 use
"includeSubdomains" [1].

With key pinning, "includeSubdomains" will probably be used even less,
since subdomains and parent domains are likely to have different keys,
and even different CAs (hosting a subdomain on a CDN, for example).

And even if HSTS includeSubdomains and "secure" cookies are used, they
don't stop cookie forcing (an attacker logs you in to her session).
And they don't make stolen cookies unusable (like ChannelID's
channel-bound cookies, or smart cookies).

--

I think the best easy solution is probably just "Origin Cookies" [2].
This solves all the cookie-scoping problems, and brings cookies in
line with the "same-origin policy".

If we had that, then cookies would not be stealable unless there was
some TLS flaw, or some failure in cookie handling.  Adding
channel-bound cookies or smart cookies gives the additional assurance
that stolen cookies would be unusable, but that's more of a
"defense-in-depth" approach.

Anyways.  Are "Origin Cookies" in scope for this WG?

Trevor

[1] http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

[2]
http://w2spconf.com/2011/papers/session-integrity.pdf
http://tools.ietf.org/html/draft-abarth-cake-01

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Jul 2013 18:18:18 -0400

I guess I could replace the 'Set-Session' mechanism that I set out in my
session continuation draft with a scheme that encodes the same information
as Set-Cookie attributes. That would then mean that a browser that knows
how to do Macs on the session cookie can do so and those that don't will
simply send the cookie back and forth as per usual.

It has nice backwards compatibility properties.

-- 
Website: http://hallambaker.com/