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

"Thomson, Martin" <Martin.Thomson@andrew.com> Tue, 24 August 2010 03:27 UTC

Return-Path: <Martin.Thomson@andrew.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C803A67EE for <http-state@core3.amsl.com>; Mon, 23 Aug 2010 20:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.945
X-Spam-Level:
X-Spam-Status: No, score=-2.945 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-ZYh00cTF7W for <http-state@core3.amsl.com>; Mon, 23 Aug 2010 20:27:32 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 0017A3A6403 for <http-state@ietf.org>; Mon, 23 Aug 2010 20:27:31 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:49310 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S413388Ab0HXD2E (ORCPT <rfc822; http-state@ietf.org>); Mon, 23 Aug 2010 22:28:04 -0500
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 23 Aug 2010 22:28:04 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 24 Aug 2010 11:28:01 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Maciej Stachowiak <mjs@apple.com>, Adam Barth <ietf@adambarth.com>
Date: Tue, 24 Aug 2010 11:30:24 +0800
Thread-Topic: [http-state] draft-abarth-cake-00 posted
Thread-Index: ActC8H8v1ExEwsZxTEOqJ0AUMFuJswAS9Uyw
Message-ID: <8B0A9FCBB9832F43971E38010638454F03EF266B47@SISPE7MB1.commscope.com>
References: <AANLkTi=c9i=gNFspyf4NC0Cm423JtH0v4FHR18Lm_GrB@mail.gmail.com> <F79FCB2B-2F28-46D0-AFB9-80875E27A9A2@apple.com>
In-Reply-To: <F79FCB2B-2F28-46D0-AFB9-80875E27A9A2@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] draft-abarth-cake-00 posted
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Aug 2010 03:27:35 -0000

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: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org]
> 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
> > http-state@ietf.org
> > https://www.ietf.org/mailman/listinfo/http-state
> 
> _______________________________________________
> http-state mailing list
> http-state@ietf.org
> https://www.ietf.org/mailman/listinfo/http-state