[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/