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.

Editorial Note (To be removed by RFC Editor)

If you have suggestions for improving this document, please send email to mailto:http-state@ietf.org. Further Working Group information is available from https://tools.ietf.org/wg/httpstate/.

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://datatracker.ietf.org/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 February 23, 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://trustee.ietf.org/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
2.  Conventions
    2.1.  Conformance Criteria
    2.2.  Syntax Notation
    2.3.  Terminology
3.  Overview
4.  Server Requirements
5.  User Agent Requirements
6.  Privacy Considerations
7.  Security Considerations
8.  IANA Considerations
    8.1.  Cake
    8.2.  Set-Cake-Key
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  Acknowledgements
§  Author's Address

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.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.).

The following core rules are included by reference, as defined in [RFC5234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.), 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).

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

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

OWS SHOULD either not be produced or be produced as a single SP character.

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] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), 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] (Newman, C., Duerst, M., and A. Gulbrandsen, “Internet Application Protocol Collation Registry,” March 2007.).

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

TODO

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

TODO

6.  Privacy Considerations

TODO

7.  Security Considerations

TODO

8.  IANA Considerations

The permanent message header registry (see [RFC3864] (Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields,” September 2004.)) 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

9.2. Informative References

Appendix A.  Acknowledgements

TODO

Author's Address