httpstate I. Ayadi Internet-Draft A. Serrouchni Intended status: Standards Track Telecom ParisTech Expires: April 20, 2011 G. Pujolle Laboratory of Computer Sciences, Paris 6 October 18, 2010 Integrity Cookie Management draft-iayadi-cookie-integrity-00 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 April 20, 2011. Copyright Notice This 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. I. A. & G. Expires April 20, 2011 [Page 1] Internet-Draft Integrity Cookie Management October 2010 Abstract This document defines an abstract syntax and semantic of HTTP cookies. This approach presents a new cookie attribute that ensures cookie integrity and improves source authentication of the cookie sent back to the server. Cookies are always used on the Web in order to store user identification data and sensible user information. Adversary can easily modify cookiesstored in the User Agent. Therefore, Origin Server has to be able to verify cookie integrity and ensure that the returned cookies are its own cookies. This document explains a way to calculate and apply the integrity attribute in HTTP cookie headers. Table of contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .3 4. Cookie management design . . . . . . . . . . . . . . . . . . .4 5. Syntax and Semantic of the cookie header . . . . . . . . . . .4 5.1. Set-cookie Header . . . . . . . . . . . . . . . . . . . . .5 5.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . .5 5.1.2. Semantics . . . . . . . . . . . . . . . . . . .5 5.2. Cookie Header . . . . . . . . . . . . . . . . . . . . . .6 5.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . .6 5.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . .6 6. Proposal Integrity Cookie Management . . . . . . . . . . . . .6 6.1. Calculating ICD attribute . . . . . . . . . . . . . . . . .7 6.2. Example of ICD Computation . . . . . . . . . . . . . . . .7 6.3. Validation and implementation . . . . . . . . . . . . . . .8 6.4. Security consideration and limitation . . . . . . . . . . .8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . .9 7.1. Normative References . . . . . . . . . . . . . . . . . . .9 7.2. Informative References . . . . . . . . . . . . . . . . . .9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .10 I. A. & G. Expires April 20, 2011 [Page 2] Internet-Draft Integrity Cookie Management October 2010 1. Introduction HTTP [RFC2616] is an applicative layer protocol, widely used in World Wide Web. Tracking user session is not possible because this protocol is a stateless protocol. Consequently, cookies are the common solution that provides a stateful session with HTTP protocol. Cookie specifications [RFC2965, RFC2109] implement two complementary HTTP headers, Set-cookie header and Cookie header. Set-cookie header is sent through a response from Origin Server, while Cookie header is sent within a request from the User Agent to the Origin Server. This document describes the syntax of a new cookie attribute that ensures the integrity of the cookie received from the User Agent. The main challenges of adding this new cookie attribute is enabling the Origin Server to verify that it is the owner of the received cookies. This new attribute will be called ICD (Integrity Cookie Digit). The present proposal follows the same cookies syntax represented in RFC 2965[RFC2965] specification. The implementation and validation of this new proposal is addressed in the last section of this document. 2. Terminology The terms User Agent, server, and Origin Server have the same meaning as in the HTTP/1.0 specification [RFC1945]. HTTP cookies are initially developed by Netscape in 1994. Netscape's cookies technology led the Internet Engineering Task Force to develop a precise technical standard for cookies (Kristol and Montulli, 2000) [RFC2965]. This work is based on the "HTTP State Management Mechanism" [RFC2965]. The concept of cookie used throughout this work has the same meaning defined in this standard [RFC2965]. 3. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. I. A. & G. Expires April 20, 2011 [Page 3] Internet-Draft Integrity Cookie Management October 2010 4. Cookie management design This section describes cookie headers implementation in order to maintain the context state of User Agent. User Agent uses HTTP request to access resources created on the Origin Server. The latter set up the user context information and initiates a new HTTP session by including a Set-cookie header in HTTP response. Cookie header is included in the next HTTP request from the User Agent to the same Origin Server. The server retrieves the client context information and sends the response to the User Agent. The Origin Server may modify the cookie content by returning a new Set-cookie header in HTTP response or it may send an HTTP response without Set-cookie Header. Client Server ------ ------ HTTP request --------> <-------- HTTP Response Set-cookie header Cookie stored in user browser HTTP Request Cookie Header --------> Retrieve user context information HTTP Response <-------> HTTP Response 5. Syntax and Semantic of the cookie header This section presents a grammatical definition of the cookie header in EBNF form HTTP/1.1 specification [RFC2616]. The proposal ICD attribute will be used with the same grammatical definition of the cookie header field presented in this standard. The following grammar is described in RFC 2965 and it represents the general syntax of Set-cookie and cookie headers. av-pairs = av-pair *(";" av-pair) av-pair = attr ["=" value] attr = token value = token | quoted-string I. A. & G. Expires April 20, 2011 [Page 4] Internet-Draft Integrity Cookie Management October 2010 5.1. Set-cookie Header This section defines the new syntax and semantic of Set-cookie attributes. 5.1.1. Syntax This section describes the field Set-cookie as it is defined in RFC 2965 [RFC2965]. Then, it shows the required field that should be added to maintain cookie integrity. set-cookie = "Set-Cookie:" cookies cookies = 1#cookie cookie = NAME "=" VALUE *(";" set-cookie-av) NAME = attr VALUE = value set-cookie-av = "Comment" "=" value | "CommentURL" "=" <"> http_URL <"> | "Discard" | "Domain" "=" value | "Max-Age" "=" value | "Path" "=" value | "Port" [ "=" <"> portlist <"> ] | "Secure" | "Version" "=" 1*DIGIT | "ICD" "=" value portlist = 1#portnum portnum = 1*DIGIT 5.1.2. Semantics Set-cookie response header defines a token 'cookie' that will be stored in the User Agent. The User Agent returns the cookie header in HTTP request to the same Origin Server if the domain or the path attributes are conformed to the URL path name. Otherwise it ignores the cookie header. The Set-cookie attributes are defined and well detailed in RFC 2965. The ICD value is optional. It will include in Set-cookie header to ensure cookie integrity. The next section describes a method to calculate the value of this new attribute. I. A. & G. Expires April 20, 2011 [Page 5] Internet-Draft Integrity Cookie Management October 2010 5.2. Cookie Header 5.2.1. Syntax This section describes the field Cookie as defined in RFC 2965. Then, it shows the ICD attribute that ensures cookie integrity. cookie = "Cookie:" cookie-version 1*((";" | ",") cookie -value) cookie-value = NAME "=" VALUE [";" path] [";" domain] [";" port] cookie-version = "$Version" "=" value NAME = attr VALUE = value path = "$Path" "=" value domain = "$Domain" "=" value port = "$Port" ["=" <"> value <">] ICD = "$ICD" "=" value 5.2.2. Semantics Cookie header attributes are described in the RFC 2965. This specification shows that the User Agent sends a cookie to the Origin Server whose domain matches the URL path. The Origin Server gets the ICD value and verifies the cookie integrity. It compares the ICD received in cookie header with the one calculated based on the received data. This method allows the Origin Server to detect if data is modified. By applying this attribute in cookie header, Origin Server can control the source authenticity of the received cookie. 6. Proposal Integrity Cookie Management This section details the new attribute (Integrity Cookie Digit) that ensures the integrity of cookie information. It provides an absolute level of security for the Origin Server. This value has six digits long so it helps to decrease the overhead of cookie header. I. A. & G. Expires April 20, 2011 [Page 6] Internet-Draft Integrity Cookie Management October 2010 6.1. Calculating ICD attribute The proposed attribute is based on a cryptographic hash function. Three steps are required to calculate it. First, a MAC (Message Authentication Code) value is generated by using HMAC [HMAC] function. This function uses a hash function and an Origin Server secret key. This key must be secret and known only by the Origin Server. Second, a 'truncation' function, inspired from HOTP standard [RFC4226], will be applied to the output of the HMAC function. Indeed, this function takes the last byte of MAC value. Then, it determines the decimal value of the lower four bits of this byte. It extracts four bytes starting at the byte whose number is the calculated decimal value. Finally, a 'modulo' function takes the output of truncation function, and generates the ICD value on six digits long. 6.2. Example of ICD computation This section presents an example of integrity value calculation. Assume that the HMAC-SHA1 [SHA] function will be used throughout this example and 'Ks' is the secret key of the Origin Server. Hash function will be applied to all data in cookie attributes. In the case of SHA1, the MAC size is 20 bytes. Then, note X the decimal value of the four least-significant-bit of the 19th byte. Thus, the truncated output takes four bytes long. Note Y the decimal value of the four bytes MAC starting at the Xth byte. The ICD is the result of applying modulo function (10^6) on Y. This attribute has six digits long. The following example illustrates a practical ICD calculation based on HMAC-SHA1: The initial Set-cookie header generated by the Origin Server is: server_sessionID=4jZmb5HFoXHe2xU6jKlqPkDD4GEdmUuZnlkROI9wXvIRQFFO h4QalBcvsWWwVTw; path=/; Assume that the 'value' attribute contains user password. Thus, the result of ICD calculation for this attribute is 879429. The new Set-cookie header includes the ICD attribute: server_sessionID=4jZmb5HFoXHe2xU6jKlqPkDD4GEdmUuZnlkROI9wXvIRQFFO h4QalBcvsWWwVTw; path=/; ICD=879429; I. A. & G. Expires April 20, 2011 [Page 7] Internet-Draft Integrity Cookie Management October 2010 6.3. Validation and implementation After the integrity control description of HTTP cookies, the implementation and verification were conducted. This contribution was practically tested on an 'AdminProxy' project certified by the competitiveness cluster System@tic Paris-Region. This project manages HTTP sessions under SSO architecture. It integrates an HTTP Reverse Proxy to protect internal servers under a common entry point. The Reverse Proxy acts as a session handler and uses cookies to maintain a session design. Checking cookie integrity has been validated by implementing the method described in this paper. This was done by developing a new Apache module that manages secure HTTP sessions. This module includes a running code that computes integrity value on a six digits length. The simulations were carried using this API in Apache core. Apache server was configured as a Reverse Proxy HTTP. It protects many Web servers located at the network perimeter. Many tests were carried out by modifying cookie attributes. The results illustrate clearly the validation of this method for calculating integrity cookie attributes. 6.4. Security consideration and limitation Cookie attributes may store private and sensitive user information such as credit card number, password, user identifier, etc. If the Origin Server activates the "secure" flag, forwarding data requires a secure channel. Thus cookie attributes are protected when they are transmitted. However, an intruder can consult User Agent computer and therefore he can intercept, read and alter data information stored in the cookie. The ICD attribute should be included in each cookie response header to ensure integrity cookie data. The ICD implementation protects the cookie integrity as well as its authenticity. The Origin Server detects the modification of cookie attributes by calculating the ICD value. Thus, Origin Server can verify if the received cookie was its owner cookie. However the server is not yet able to know if the present cookie received from the User Agent was the last one it sent. Thus, another issue to be considered is the replay attack problem of cookie management. I. A. & G. Expires April 20, 2011 [Page 8] Internet-Draft Integrity Cookie Management October 2010 7. References 7.1. Normative References [RFC1945] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 2616, June 1999. [RFC2119] S. Bradner,"Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997. 10.2. Informative References [RFC2109] D. Kristol et L. Montulli , "HTTP State Management Mechanism", Internet Engineering Task Force, February 1997. [RFC2965] D. Kristol et L. Montulli , "HTTP State Management Mechanism", Internet Engineering Task Force, October 2000. [HMAC] NIST, The Keyed-Hash Message Authentication Code (HMAC), Federal Information Prossessing Standards Publication, FIPS 198a, 6 mars 2002. [SHA] D. Eastlake 3rd and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)",RFC 4634, July 2006. [RFC4226] D. M'Raihi and all.: "HOTP: An HMAC-Based One-Time Password Algorithm", RFC4226, December 2005. I. A. & G. Expires April 20, 2011 [Page 9] Internet-Draft Integrity Cookie Management October 2010 Authors' Addresses AYADI Ines ENST, Telecom ParisTech. 46 rue Barrault - 75013 Paris. Email: iayadi@telecom-paristech.fr SERHROUCHNI Ahmed ENST, Telecom ParisTech. 46 rue Barrault - 75013 Paris. Email: Ahmed.Serhrouchni@enst.fr PUJOLLE Guy Lip6, Laboratory of computer Sciences, Paris 6. 104 Avenue du President Kennedy, 75016 Paris. Email: Guy.Pujolle@lip6.fr I. A. & G. Expires April 20, 2011 [Page 10]