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

[Dan Witte <[e-mail]>]

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).
> 
> Given that this provides less state than a cookie, "wafer" might be a
> better use of the prevailing analogy.
> 
> --Martin
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Maciej Stachowiak
> > Sent: Tuesday, 24 August 2010 4:21 AM
> > To: Adam Barth
> > Cc: http-state
> > Subject: Re: [http-state] draft-abarth-cake-00 posted
> >
> >
> > 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
> >
> > On Aug 22, 2010, at 12:16 AM, Adam Barth 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
> >
> > _______________________________________________
> > http-state mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/http-state
> _______________________________________________
> http-state mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-state