Internet DRAFT - draft-iayadi-cookie-integrity
draft-iayadi-cookie-integrity
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]
