httpstate A. Barth
Internet-Draft Google, Inc.
Intended status: Standards Track August 22, 2010
Expires: February 23, 2011
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.
Barth Expires February 23, 2011 [Page 1]
Internet-Draft Simple HTTP State Management Mechanism August 2010
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 BSD License.
Barth Expires February 23, 2011 [Page 2]
Internet-Draft Simple HTTP State Management Mechanism August 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 8
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 9
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. Cake . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Set-Cake-Key . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Barth Expires February 23, 2011 [Page 3]
Internet-Draft Simple HTTP State Management Mechanism August 2010
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.
Barth Expires February 23, 2011 [Page 4]
Internet-Draft Simple HTTP State Management Mechanism August 2010
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).
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], Section
1.3).
Barth Expires February 23, 2011 [Page 5]
Internet-Draft Simple HTTP State Management Mechanism August 2010
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].
Barth Expires February 23, 2011 [Page 6]
Internet-Draft Simple HTTP State Management Mechanism August 2010
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.
Barth Expires February 23, 2011 [Page 7]
Internet-Draft Simple HTTP State Management Mechanism August 2010
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
Barth Expires February 23, 2011 [Page 8]
Internet-Draft Simple HTTP State Management Mechanism August 2010
5. User Agent Requirements
TODO
Barth Expires February 23, 2011 [Page 9]
Internet-Draft Simple HTTP State Management Mechanism August 2010
6. Privacy Considerations
TODO
Barth Expires February 23, 2011 [Page 10]
Internet-Draft Simple HTTP State Management Mechanism August 2010
7. Security Considerations
TODO
Barth Expires February 23, 2011 [Page 11]
Internet-Draft Simple HTTP State Management Mechanism August 2010
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
Barth Expires February 23, 2011 [Page 12]
Internet-Draft Simple HTTP State Management Mechanism August 2010
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., Ed. 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.
Barth Expires February 23, 2011 [Page 13]
Internet-Draft Simple HTTP State Management Mechanism August 2010
Appendix A. Acknowledgements
TODO
Barth Expires February 23, 2011 [Page 14]
Internet-Draft Simple HTTP State Management Mechanism August 2010
Author's Address
Adam Barth
Google, Inc.
Email: ietf@adambarth.com
URI: http://www.adambarth.com/
Barth Expires February 23, 2011 [Page 15]