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
- [http-state] draft-abarth-cake-00 posted Adam Barth
- Re: [http-state] draft-abarth-cake-00 posted Adam Barth
- Re: [http-state] draft-abarth-cake-00 posted Thomson, Martin
- Re: [http-state] draft-abarth-cake-00 posted Adam Barth
- Re: [http-state] draft-abarth-cake-00 posted Maciej Stachowiak
- Re: [http-state] draft-abarth-cake-00 posted Thomson, Martin
- Re: [http-state] draft-abarth-cake-00 posted Dan Witte
- Re: [http-state] draft-abarth-cake-00 posted David Morris
- Re: [http-state] draft-abarth-cake-00 posted Thomson, Martin
- Re: [http-state] draft-abarth-cake-00 posted Anne van Kesteren