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

["Thomson, Martin" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> 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
> 
> Oops.  That "staging" link isn't permanent.  This one should be better:
> 
> http://www.ietf.org/id/draft-abarth-cake-00.txt
> 
> Adam
> 
> 
> On Sun, Aug 22, 2010 at 12:16 AM, Adam Barth <[e-mail]>
> wrote:
> > 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
> >
> _______________________________________________
> http-state mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-state