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 . Further Working Group information is available from . 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 = 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]