httpstate A. Barth
Internet-Draft Google, Inc.
Intended status: Standards Track August 2010
Expires: January 31, 2011

Simple HTTP State Management Mechanism


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.

Editorial Note (To be removed by RFC Editor)

If you have suggestions for improving this document, please send email to Further Working Group information is available from

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 31, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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 HTTP server always employs TLS, a network attacker manipulate the server's cookies by spoofing responses from (assuming the user agent makes a single non-TLS protected HTTP request, which, of course, the attacker can redirect to
  2. Cookies assume that a given host name trusts all of its superdomains and siblings. In particular, can manipulate the cookies used by, 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, and have independent cake-keys. Likewise, and have independent cake-keys. Therefore, an active network attacker (who can compromise cannot manipulate the state for

2. Conventions

2.1. Conformance Criteria

The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant.

2.2. Syntax Notation

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].

The following core rules are included by reference, as defined in [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US-ASCII character), VCHAR (any visible US-ASCII character), and WSP (whitespace).

OWS            = *( [ obs-fold ] WSP )
                 ; "optional" whitespace
obs-fold       = CRLF

The OWS (optional whitespace) rule is used where zero or more linear whitespace characters MAY appear:

2.3. Terminology

The terms user agent, client, server, proxy, and origin server have the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 1.3).

The terms request-host and request-uri refer to the values the user agent would send to the server as, respectively, the host (but not port) and the absoluteURI (http_URL) of the HTTP Request-Line.

Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap collation defined in [RFC4790].

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.

Set-Cake-Key: 515BYea21GY7xRbZTLCekQ==; Max-Age=1209600
$ openssl rand -base64 16

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:

Cake: Z32dI5wav1Cqj07ToG++DRXV18c=
$ echo "Origin:" |
  openssl dgst -hmac 515BYea21GY7xRbZTLCekQ== -sha1 -binary |
  openssl enc -base64

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, the user agent sends the following header:

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

5. User Agent Requirements


6. Privacy Considerations


7. Security Considerations


8. IANA Considerations

The permanent message header registry (see [RFC3864]) should be updated with the following registrations:

8.1. Cake

Header field name: Cake

Applicable protocol: http

Status: standard

Author/Change controller: IETF

Specification document: this specification

8.2. Set-Cake-Key

Header field name: Set-Cake-Key

Applicable protocol: http

Status: standard

Author/Change controller: IETF

Specification document: this specification

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels ", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4790] Newman, C., Duerst, M. and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF ", STD 68, RFC 5234, January 2008.

9.2. Informative References

[RFC3864] Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

Appendix A. Acknowledgements


Author's Address

Adam Barth Google, Inc. EMail: URI: