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

[Adam Barth <[e-mail]>]

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