Subject: [http-state] draft-abarth-cake-00 posted

From: Adam Barth <[email-masked]>
Date: Sun, 22 Aug 2010 00:16:15 -0700

People of http-state:

I've posted an updated draft of the Cake HTTP state management
mechanism for your review:

http://www.ietf.org/staging/draft-abarth-cake-00.txt

This draft improves on the original cake proposal in two ways:

1) The mechanism is now robust to cross-site request forgery.  (For an
overview of CSRF attacks, please see
<http://en.wikipedia.org/wiki/Cross-site_request_forgery>.)
2) The server can now specify the max-age of the session.

The draft is just an overview of the protocol.  I can fill in the
server and user agent requirements, etc, if there is sufficient
interest in moving forward with this approach.  Please find below the
salient pieces of the document.

Let me know if you have any feedback!

Kind regards,
Adam

                 Simple HTTP State Management Mechanism
                          draft-abarth-cake-00

Abstract

   This document describes a simple HTTP state management mechanism,
   called cake, that lets HTTP servers maintain stateful sessions with
   HTTP user agents.  This mechanism is harmonized with the same-origin
   security model and provides both confidentiality and integrity
   protection against active network attackers.  In addition, the
   mechanism is robust to cross-site request forgery attacks.

1.  Introduction

   HTTP does not provide servers with a robust mechanism for tracking
   state between requests.  The dominant HTTP state management mechanism
   in use on the Internet, known as cookies, has a number of historical
   infelicities that impair its security.  In particular, cookies have
   the following serious defects:

   1.  Cookies provide no integrity protection against active network
       attackers.  Even if the example.com HTTP server always employs
       TLS, a network attacker manipulate the server's cookies by
       spoofing responses from http://example.com/ (assuming the user
       agent makes a single non-TLS protected HTTP request, which, of
       course, the attacker can redirect to http://example.com/).

   2.  Cookies assume that a given host name trusts all of its
       superdomains and siblings.  In particular, students.example.edu
       can manipulate the cookies used by grades.example.edu,
       potentially resulting in security vulnerabilities.

   3.  Cookies indicate only which user agent issued a given HTTP
       request.  They provide no information about why the user agent
       issued that request.  This design flaw leads many HTTP servers to
       be vulnerable to cross-site request forgery attacks, in which the
       attacker tricks the server into performing an action on behalf of
       the user by causing the user agent to issue an HTTP request to
       the server with the user's cookies.

   This document defines a simple HTTP state management mechanism that
   addresses these shortcommings of cookies.  In this mechanism, the
   server stores a secret key at the user agent, called the cake-key.
   When the user agent issues subsequent HTTP requests to the server,
   the user agent sends a string, called a cake, containing a HMAC
   (using the cake-key) of the security-origin that generated the
   request.  By whitelisting expected cakes, the server can accept
   requests from origins of its choice, mitigating cross-site request
   forgery vulnerabilities.

   Unlike cookies, which can leak from one host to another and from one
   scheme to another, the cake-key is scoped to a security-origin.  In
   particular, http://students.example.edu and http://grades.example.edu
   have independent cake-keys.  Likewise, http://example.com and
   https://example.com have independent cake-keys.  Therefore, an active
   network attacker (who can compromise http://example.com) cannot
   manipulate the state for https://example.com.

3.  Overview

   The cake state management mechanism consists of two HTTP headers, an
   HTTP response header named Set-Cake-Key and an HTTP request header
   named Cake.

   The server can use the Set-Cake-Key response header to store a secret
   key at the user agent.  For example, the following header instructs
   the user agent to store a 128-bit secret key for two weeks:

   Set-Cake-Key: 515BYea21GY7xRbZTLCekQ==; Max-Age=1209600

   Notice that the server can easily generate a base64-encoded random
   number using the openssl library:

   $ openssl rand -base64 16

   The user agent then associated the given cake-key with the security-
   origin from which it received the Set-Cake-Key header.  When making
   subsequent HTTP requests to that security-origin, the user agent
   includes the Cake request header, which contains a SHA-1 HMAC (keyed
   by the cake-key) of the security-origin that generated the request.
   For example, if the request was generated by the user agent on behalf
   of http://example.com, the user agent sends the following header:

   Cake: Z32dI5wav1Cqj07ToG++DRXV18c=

   Notice that the server can easily generate the cake it will receive
   for a given security-origins using the openssl library:

   $ echo "Origin: http://example.com" |
     openssl dgst -hmac 515BYea21GY7xRbZTLCekQ== -sha1 -binary |
     openssl enc -base64

   By pre-computing the cake for the security-origins the server expects
   to receive requests from, the server can whitelist the security-
   origins that have access to its session state.  Notice that if the
   server does not whitelist a particular security-origin, the server
   will not link the request with the session, making it difficult for
   the attacker to mount a cross-site request forgery attack.

4.  Server Requirements

   set-cake-key-header = "Set-Cake-Key:" OWS set-cake-key-string OWS
   set-cake-key-string = cake-key *( ";" SP cake-av )
   cake-key            = 1*BASE64CHAR
   BASE64CHAR          = ALPHA / DIGIT / "+" / "/" / "="
   cake-av             = max-age-av / extension-av
   max-age-av          = "Max-Age=" 1*DIGIT
   extension-av        = <any CHAR except CTLs or ";">

   cake-header         = "Cake:" OWS cake OWS
   cake                = 1*BASE64CHAR

---

From: Adam Barth <[email-masked]>
Date: Sun, 22 Aug 2010 10:02:15 -0700

Oops.  That "staging" link isn't permanent.  This one should be better:

http://www.ietf.org/id/draft-abarth-cake-00.txt

Adam

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 23 Aug 2010 07:39:58 +0800

No real comments about the mechanism.  You should provide more analysis and description on how this addresses CSRF.

There doesn't seem to be much point in prefixing the origin with "Origin: ".  It only seems to invite errors (looks like an HTTP header, but variation isn't accepted).

What about IDN?  (I assume that this uses the Unicode serialization, and that -origin will soon be updated to reference the latest IDN work.)

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Adam Barth
> Sent: Monday, 23 August 2010 3:02 AM
> To: http-state
> Subject: Re: [http-state] draft-abarth-cake-00 posted
> 
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state

---

From: Adam Barth <[email-masked]>
Date: Mon, 23 Aug 2010 10:42:24 -0700

> No real comments about the mechanism.  You should provide more analysis and description on how this addresses CSRF.

Thanks.  That's a good suggestion.  I'll add that to the introduction
and the security consideration section.

> There doesn't seem to be much point in prefixing the origin with "Origin: ".  It only seems to invite errors (looks like an HTTP header, but variation isn't accepted).

We'd like some sort of framing around the origin string so that we can
use the cake key for more things in the future.  What I have in the
draft is probably not ideal, but I'm sure we can find something that
works nicely.

> What about IDN?  (I assume that this uses the Unicode serialization, and that -origin will soon be updated to reference the latest IDN work.)

These details aren't in the draft yet, but we'll just reference the
definition of the ASCII serialization of an origin from the HASMAT
effort.  These strings are already used in a bunch of places in the
web platform, so we have lots of implementation experience with them
already (including IDN, etc).

Thanks!
Adam

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 23 Aug 2010 11:21:03 -0700

I know this is a trivial comment, but I'd like to suggest giving this mechanism a less silly name. How about "HTTP Session State" or some abbreviation thereof instead of "cake"?

Regards,
Maciej

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 24 Aug 2010 11:30:24 +0800

But to give it a sensible name would be...sensible...and a little dull.  That's contrary to a well-established tradition (YMMV).

Given that this provides less state than a cookie, "wafer" might be a better use of the prevailing analogy.

--Martin

> On Behalf Of Maciej Stachowiak
> Sent: Tuesday, 24 August 2010 4:21 AM
> To: Adam Barth
> Cc: http-state
> I know this is a trivial comment, but I'd like to suggest giving this
> mechanism a less silly name. How about "HTTP Session State" or some
> abbreviation thereof instead of "cake"?
> 
> Regards,
> Maciej
>

---

From: Dan Witte <[email-masked]>
Date: Mon, 23 Aug 2010 20:30:17 -0700 (PDT)

Indeed. Cake has my vote, all the way. :)

D.

----- Original Message -----
> But to give it a sensible name would be...sensible...and a little
> dull. That's contrary to a well-established tradition (YMMV).
> 
> > >       issued that request. This design flaw leads many HTTP
> > >       servers
> > to
> > >       be vulnerable to cross-site request forgery attacks, in
> > >       which
> > the
> > >       attacker tricks the server into performing an action on
> > >       behalf
> > of
> > >   The cake state management mechanism consists of two HTTP
> > >   headers,
> > an

---

From: David Morris <[email-masked]>
Date: Mon, 23 Aug 2010 21:23:24 -0700 (PDT)

On Tue, 24 Aug 2010, Thomson, Martin wrote:

> But to give it a sensible name would be...sensible...and a little dull.
> That's contrary to a well-established tradition (YMMV).
> 

hmmm ... I like wafer ... because it is a multiple use word which is
used in electronics for various layer like things. Frankly, everytime
I read 'cake' I have to to a mental search/translate to associate it
with cookie.  In my experience, a cake is a much more heavyweight
concept than cookie.

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 24 Aug 2010 12:34:18 +0800

> with cookie.  In my experience, a cake is a much more heavyweight

I'll confess, the idea that this is "wafer-thin"... http://en.wikipedia.org/wiki/Mr._Creosote ... appeals to me.

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 24 Aug 2010 09:28:05 +0200

> better use of the prevailing analogy.

I thought it was because cake beats cookies. :-)

-- 
Anne van Kesteren
http://annevankesteren.nl/