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

[Adam Barth <[e-mail]>]

On Sun, Aug 22, 2010 at 4:39 PM, Thomson, Martin
<[e-mail]> wrote:
> 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


>> -----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
>