draft-ietf-httpstate-cookie-02.txt   draft-ietf-httpstate-cookie-03.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2109 (if approved) January 21, 2010 Obsoletes: 2109 (if approved) February 12, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: July 25, 2010 Expires: August 16, 2010
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-02 draft-ietf-httpstate-cookie-03
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie headers. These This document defines the HTTP Cookie and Set-Cookie headers. These
headers can be used by HTTP servers to store state on HTTP user headers can be used by HTTP servers to store state on HTTP user
agents, letting the servers maintain a stateful session over the agents, letting the servers maintain a stateful session over the
mostly stateless HTTP protocol. The cookie protocol has many mostly stateless HTTP protocol. The cookie protocol has many
historical infelicities and should be avoided for new applications of historical infelicities and should be avoided for new applications of
HTTP. HTTP.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 25, 2010. This Internet-Draft will expire on August 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 2. General Nonsense . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 5
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. A Well-Behaved Profile . . . . . . . . . . . . . . . . . . . . 7 4. A Well-Behaved Profile . . . . . . . . . . . . . . . . . . . . 7
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 8 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 8
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 10
5. The Cookie Protocol . . . . . . . . . . . . . . . . . . . . . 11 5. The Cookie Protocol . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 33 skipping to change at page 3, line 35
5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 14 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 14
5.2.1. The Max-Age Attribute . . . . . . . . . . . . . . . . 16 5.2.1. The Max-Age Attribute . . . . . . . . . . . . . . . . 16
5.2.2. The Expires Attribute . . . . . . . . . . . . . . . . 16 5.2.2. The Expires Attribute . . . . . . . . . . . . . . . . 16
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 17 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 17
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 17 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 17
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 18 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 18
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 18 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 18
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 18
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 21 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 21
6. Implementation Limits . . . . . . . . . . . . . . . . . . . . 23 6. Implementation Considerations . . . . . . . . . . . . . . . . 23
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Application Programmer Interfaces . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. General Recommendations . . . . . . . . . . . . . . . . . 24
7.2. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 24 7.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 24
7.3. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Normative References . . . . . . . . . . . . . . . . . . . . . 26 7.4. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 7.5. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.6. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 26
8. Normative References . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header. Using This document defines the HTTP Cookie and Set-Cookie header. Using
the Set-Cookie header, an HTTP server can store name/value pairs and the Set-Cookie header, an HTTP server can store name/value pairs and
associated metadata (called cookies) at the user agent. When the associated metadata (called cookies) at the user agent. When the
user agent makes subsequent requests to the server, the user agent user agent makes subsequent requests to the server, the user agent
uses the metadata to determine whether to return the name/value pairs uses the metadata to determine whether to return the name/value pairs
in the Cookie header. in the Cookie header.
skipping to change at page 4, line 30 skipping to change at page 5, line 5
For historical reasons, the cookie protocol contains a number of For historical reasons, the cookie protocol contains a number of
security and privacy infelicities. For example, a server can security and privacy infelicities. For example, a server can
indicate that a given cookie is intended for "secure" connections, indicate that a given cookie is intended for "secure" connections,
but the Secure attribute provides only confidentiality (not but the Secure attribute provides only confidentiality (not
integrity) from active network attackers. Similarly, cookies for a integrity) from active network attackers. Similarly, cookies for a
given host are shared across all the ports on that host, even though given host are shared across all the ports on that host, even though
the usual "same-origin policy" used by web browsers isolates content the usual "same-origin policy" used by web browsers isolates content
retrieved from different ports. retrieved from different ports.
1.1. Syntax Notation 2. General Nonsense
2.1. Conformance Criteria
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in 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.
2.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234]. notation of [RFC5234].
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (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 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), HTAB (horizontal tab), VCHAR (any sequence of data), SP (space), HTAB (horizontal tab), VCHAR (any
visible [USASCII] character), and WSP (whitespace). visible [USASCII] character), and WSP (whitespace).
2. Terminology 2.3. Terminology
The terms user agent, client, server, proxy, and origin server have The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification. the same meaning as in the HTTP/1.1 specification.
The terms request-host and request-URI refer to the values the user 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 agent would send to the server as, respectively, the host (but not
port) and abs_path portions of the absoluteURI (http_URL) of the HTTP port) and abs_path portions of the absoluteURI (http_URL) of the HTTP
Request-Line. Request-Line.
3. Overview 3. Overview
skipping to change at page 7, line 37 skipping to change at page 7, line 37
set-cookie-header = "Set-Cookie:" OWS set-cookie-string OWS set-cookie-header = "Set-Cookie:" OWS set-cookie-string OWS
set-cookie-string = cookie-pair *( ";" cookie-av ) set-cookie-string = cookie-pair *( ";" cookie-av )
cookie-pair = cookie-name "=" cookie-value cookie-pair = cookie-name "=" cookie-value
cookie-name = token cookie-name = token
cookie-value = token cookie-value = token
token = <token, as defined in RFC 2616> token = <token, as defined in RFC 2616>
cookie-av = expires-av / domain-av / path-av / cookie-av = expires-av / domain-av / path-av /
secure-av / httponly-av secure-av / httponly-av
expires-av = "Expires" "=" cookie-date expires-av = "Expires" "=" sane-cookie-date
cookie-date = <rfc1123-date, as defined in RFC 2616> sane-cookie-date = <rfc1123-date, as defined in RFC 2616>
domain-av = "Domain" "=" domain-value domain-av = "Domain" "=" domain-value
domain-value = token domain-value = token
path-av = "Path" "=" path-value path-av = "Path" "=" path-value
path-value = <abs_path, as defined in RFC 2616> path-value = <abs_path, as defined in RFC 2616>
secure-av = "Secure" secure-av = "Secure"
httponly-av = "HttpOnly" httponly-av = "HttpOnly"
Servers SHOULD NOT include two attributes with the same name. Servers SHOULD NOT include two attributes with the same name.
The cookie-value is opaque to the user agent and MAY be anything the The cookie-value is opaque to the user agent and MAY be anything the
origin server chooses to send, possibly in a server-selected origin server chooses to send. "Opaque" implies that the content is
printable ASCII encoding. "Opaque" implies that the content is of of interest and relevance only to the origin server. The content is,
interest and relevance only to the origin server. The content is, in in fact, readable by anyone who examines the Set-Cookie header.
fact, readable by anyone who examines the Set-Cookie header.
To maximize compatibility with user agents, servers that wish to
store non-ASCII data in a cookie-value SHOULD encode that data using
a printable ASCII encoding, such as base64.
NOTE: The syntax above allows whitespace between the attribute and NOTE: The syntax above allows whitespace between the attribute and
the U+003D ("=") character. Servers wishing to interoperate with the U+003D ("=") character. Servers wishing to interoperate with
some legacy user agents might wish to elide this whitespace. some legacy user agents might wish to elide this whitespace.
4.1.2. Semantics (Non-Normative) 4.1.2. Semantics (Non-Normative)
This section describes a simplified semantics of the Set-Cookie This section describes a simplified semantics of the Set-Cookie
header. These semantics are detailed enough to be useful for header. These semantics are detailed enough to be useful for
understanding the most common uses of the cookie protocol. The full understanding the most common uses of the cookie protocol. The full
skipping to change at page 9, line 5 skipping to change at page 9, line 8
4.1.2.2. Domain 4.1.2.2. Domain
The Domain attribute specifies those hosts for which the cookie will The Domain attribute specifies those hosts for which the cookie will
be sent. For example, if the Domain attribute contains the value be sent. For example, if the Domain attribute contains the value
".example.com", the user agent will include the cookie in the Cookie ".example.com", the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, www.example.com, and header when making HTTP requests to example.com, www.example.com, and
www.corp.example.com. (Note that a leading U+002E ("."), if present, www.corp.example.com. (Note that a leading U+002E ("."), if present,
is ignored.) If the server omits the Domain attribute, the user is ignored.) If the server omits the Domain attribute, the user
agent will return the cookie only to the origin server. agent will return the cookie only to the origin server.
WARNING: Some legacy user agents treat an absent Domain attribute
as if the Domain attribute were present and contained the current
host name. For example, if example.com returns a Set-Cookie
header without a Domain attribute, these user agents will send the
cookie to www.example.com.
The user agent will reject cookies (refuse to store them in the The user agent will reject cookies (refuse to store them in the
cookie store) unless the Domain attribute specifies a scope for the cookie store) unless the Domain attribute specifies a scope for the
cookie that would include the origin server. For example, the user cookie that would include the origin server. For example, the user
agent will accept a Domain attribute of ".example.com" or of agent will accept a Domain attribute of ".example.com" or of
".foo.example.com" from foo.example.com, but the user agent will not ".foo.example.com" from foo.example.com, but the user agent will not
accept a Domain attribute of ".bar.example.com" or of accept a Domain attribute of ".bar.example.com" or of
".baz.foo.example.com". ".baz.foo.example.com".
NOTE: For security reasons, some user agents are configured to reject NOTE: For security reasons, some user agents are configured to reject
Domain attributes that do not correspond to a "registry controlled" Domain attributes that do not correspond to a "registry controlled"
skipping to change at page 10, line 24 skipping to change at page 10, line 33
4.2.1. Syntax 4.2.1. Syntax
The user agent returns stored cookies to the origin server in the The user agent returns stored cookies to the origin server in the
Cookie header. If the server conforms to the requirements in this Cookie header. If the server conforms to the requirements in this
section, the requirements in the next section will cause the user section, the requirements in the next section will cause the user
agent to return a Cookie header that conforms to the following agent to return a Cookie header that conforms to the following
grammar: grammar:
cookie-header = "Cookie:" OWS cookie-string OWS cookie-header = "Cookie:" OWS cookie-string OWS
cookie-string = cookie-pair *( ";" cookie-pair ) cookie-string = cookie-pair *( ";" cookie-pair )
cookie-pair = cookie-name "=" cookie-value
cookie-name = token
cookie-value = token
token = <token, as defined in Section 2.2 of RFC 2616>
4.2.2. Semantics 4.2.2. Semantics
Each cookie-pair represents a cookie stored by the user agent. The Each cookie-pair represents a cookie stored by the user agent. The
cookie-name and the cookie-value are returned verbatim from the cookie-name and the cookie-value are returned verbatim from the
corresponding parts of the Set-Cookie header. corresponding parts of the Set-Cookie header.
Notice that the cookie attributes are not returned. In particular, Notice that the cookie attributes are not returned. In particular,
the server cannot determine from the Cookie header alone when a the server cannot determine from the Cookie header alone when a
cookie will expire, for which domains the cookie is valid, for which cookie will expire, for which domains the cookie is valid, for which
skipping to change at page 19, line 24 skipping to change at page 19, line 24
Set the cookie's expiry-time to the latest representable Set the cookie's expiry-time to the latest representable
date. date.
3. If the cookie-attribute-list contains an attribute with an 3. If the cookie-attribute-list contains an attribute with an
attribute-name of "Domain": attribute-name of "Domain":
Let the domain-attribute be the attribute-value of the last Let the domain-attribute be the attribute-value of the last
attribute in the cookie-attribute-list with an attribute-name attribute in the cookie-attribute-list with an attribute-name
of "Domain". of "Domain".
If the Request-URI's host does not domain-match the domain- Otherwise:
attribute, ignore the cookie entirely and abort these steps.
If the user agent is configured to use a "public suffix" list Let the domain-attribute be the empty string.
and the domain-attribute is a public suffix, ignore the
cookie entirely and abort these steps.
NOTE: A "public suffix" is a domain that is controlled by 4. If the user agent is configured to use a "public suffix" list
a public registry, such as "com", "co.uk", and and the domain-attribute is a public suffix:
"pvt.k12.wy.us". This step is essential for preventing
attacker.com from disrupting the integrity of example.com If the domain-attribute is identical to the canonicalized
by setting a cookie with a Domain attribute of "com". Request-URI's host:
Unfortunately, the set of public suffixes (also known as
"registry controlled domains") changes over time. If Let the domain-attribute be the empty string.
feasible, user agents SHOULD use an up-to-date public
suffix list, such as the one maintained by the Mozilla Otherwise:
project at http://publicsuffix.org/.
Ignore the cookie entirely and abort these steps
NOTE: A "public suffix" is a domain that is controlled by a
public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
This step is essential for preventing attacker.com from
disrupting the integrity of example.com by setting a cookie
with a Domain attribute of "com". Unfortunately, the set of
public suffixes (also known as "registry controlled domains")
changes over time. If feasible, user agents SHOULD use an
up-to-date public suffix list, such as the one maintained by
the Mozilla project at http://publicsuffix.org/.
5. If the domain-attribute is non-empty:
If the Request-URI's host does not domain-match the domain-
attribute, ignore the cookie entirely and abort these steps.
Set the cookie's host-only-flag to false. Set the cookie's host-only-flag to false.
Set the cookie's domain to the domain-attribute. Set the cookie's domain to the domain-attribute.
Otherwise: Otherwise:
Set the cookie's host-only-flag to true. Set the cookie's host-only-flag to true.
Set the cookie's domain to the host of the Request-URI. Set the cookie's domain to the host of the Request-URI.
4. If the cookie-attribute-list contains an attribute with an 6. If the cookie-attribute-list contains an attribute with an
attribute-name of "Path", set the cookie's path to attribute- attribute-name of "Path", set the cookie's path to attribute-
value of the last attribute in the cookie-attribute-list with an value of the last attribute in the cookie-attribute-list with an
attribute-name of "Path". Otherwise, set cookie's path to the attribute-name of "Path". Otherwise, set cookie's path to the
default-path of the Request-URI. default-path of the Request-URI.
5. If the cookie-attribute-list contains an attribute with an 7. If the cookie-attribute-list contains an attribute with an
attribute-name of "Secure", set the cookie's secure-only-flag to attribute-name of "Secure", set the cookie's secure-only-flag to
true. Otherwise, set cookie's secure-only-flag to false. true. Otherwise, set cookie's secure-only-flag to false.
6. If the cookie-attribute-list contains an attribute with an 8. If the cookie-attribute-list contains an attribute with an
attribute-name of "HttpOnly", set the cookie's http-only-flag to attribute-name of "HttpOnly", set the cookie's http-only-flag to
true. Otherwise, set cookie's http-only-flag to false. true. Otherwise, set cookie's http-only-flag to false.
7. Remove from the cookie store all cookies that share the same 9. Remove from the cookie store all cookies that share the same
name, domain, path, and host-only-flag as the newly created name, domain, path, and host-only-flag as the newly created
cookie. [TODO: Validate this list!] [TODO: There's some funny cookie. [TODO: Validate this list!] [TODO: There's some funny
business around http-only here.] business around http-only here.]
8. If the cookie's name and value are both empty, abort these 10. If the cookie's name and value are both empty, abort these
steps. steps.
9. If the cookie's expiry-time is not in the future, abort these 11. If the cookie's expiry-time is not in the future, abort these
steps. steps.
10. Insert the newly created cookie into the cookie store. 12. Insert the newly created cookie into the cookie store.
The user agent MUST evict a cookie from the cookie store if, at any The user agent MUST evict a cookie from the cookie store if, at any
time, a cookie exists in the cookie store with an expiry date in the time, a cookie exists in the cookie store with an expiry date in the
past. past.
The user agent MAY evict a cookie from the cookie store if the number The user agent MAY evict a cookie from the cookie store if the number
of cookies sharing a domain field exceeds some predetermined upper of cookies sharing a domain field exceeds some predetermined upper
bound (such as 50 cookies). bound (such as 50 cookies).
The user agent MAY evict a cookie from the cookie store if the cookie The user agent MAY evict a cookie from the cookie store if the cookie
skipping to change at page 23, line 5 skipping to change at page 23, line 5
cookie in the cookie-list in order: cookie in the cookie-list in order:
1. If the cookie's name is non-empty, output the cookie's name 1. If the cookie's name is non-empty, output the cookie's name
followed by the U+003D ("=") character. followed by the U+003D ("=") character.
2. Output the cookie's value. 2. Output the cookie's value.
3. If there is an unprocessed cookie in the cookie-list, output 3. If there is an unprocessed cookie in the cookie-list, output
the characters U+003B and U+0020 ("; "). the characters U+003B and U+0020 ("; ").
6. Implementation Limits 6. Implementation Considerations
6.1. Limits
Practical user agent implementations have limits on the number and Practical user agent implementations have limits on the number and
size of cookies that they can store. General-use user agents SHOULD size of cookies that they can store. General-use user agents SHOULD
provide each of the following minimum capabilities: provide each of the following minimum capabilities:
o At least 4096 bytes per cookie (as measured by the sum of the o At least 4096 bytes per cookie (as measured by the sum of the
length of the cookie's name, value, and attributes). length of the cookie's name, value, and attributes).
o At least 50 cookies per domain. o At least 50 cookies per domain.
o At least 3000 cookies total. o At least 3000 cookies total.
Servers SHOULD use as few and as small cookies as possible to avoid Servers SHOULD use as few and as small cookies as possible to avoid
reaching these implementation limits and to avoid network latency due reaching these implementation limits and to avoid network latency due
to the Cookie header being included in every request. to the Cookie header being included in every request.
Servers should gracefully degrade if the user agent fails to return Servers should gracefully degrade if the user agent fails to return
one or more cookies in the Cookie header because the user agent might one or more cookies in the Cookie header because the user agent might
evict any cookie at any time on orders from the user. evict any cookie at any time on orders from the user.
6.2. Application Programmer Interfaces
One reason the cookie protocol uses such an esoteric syntax is
because many platforms (both in servers and user agents) provide
string-based application programmer interfaces (APIs), requiring
application-layer programmers to generate and parse the syntax used
by the cookie protocol.
Instead of providing string-based APIs to the cookie protocols,
implementations would be well-served by providing more semantic APIs.
It is beyond the scope of this document to recommend specific API
designs, but there are clear benefits to accepting a abstract "Date"
object instead of a serialized date string.
7. Security Considerations 7. Security Considerations
7.1. Clear Text 7.1. General Recommendations
The information in the Set-Cookie and Cookie headers is transmitted The cookie protocol is NOT RECOMMENDED for new applications.
in the clear.
For applications that do use the cookie protocol, servers SHOULD NOT
rely upon cookies for security.
For servers that do use cookies for security, servers SHOULD use a
redundant form of authentication, such as HTTP authentication or TLS
client certificates.
7.2. Ambient Authority
A server that uses cookies to authenticate users can suffer security
vulnerabilities because some user agents let remote parties issue
HTTP requests from the user agent (e.g., via HTTP redirects and HTML
forms). When issuing those requests, user agent attaches cookies
even if the entity does not know the contents of the cookies,
possibly letting the remote entity exercise authority at an unwary
server. User agents can mitigate this issue to some degree by
providing APIs for suppressing the Cookie header on outgoing
requests.
Although this security concern goes by a number of names (e.g.,
cross-site scripting and cross-site request forgery), the issue stems
from cookies being a form of ambient authority. Cookies encourage
server operators to separate designation (in the form of URLs) from
authorization (in the form of cookies). Disentangling designation
and authorization can cause the server and its clients to become
confused deputies and undertake undesirable actions.
Instead of using cookies for authorization, server operators might
wish to consider entangling designation and authorization by treating
URLs as object-capabilities. Instead of storing secrets in cookies,
this approach stores secrets in URLs, requiring the remote entity to
supply the secret itself. ALthough this approach is not a panacea,
judicious use of these principles can lead to more robust security.
7.3. Clear Text
Unless sent over a secure channel (such as TLS), the information in
the Set-Cookie and Cookie headers is transmitted in the clear.
1. All sensitive information conveyed in these headers is exposed to 1. All sensitive information conveyed in these headers is exposed to
an eavesdropper. an eavesdropper.
2. A malicious intermediary could alter the headers as they travel 2. A malicious intermediary could alter the headers as they travel
in either direction, with unpredictable results. in either direction, with unpredictable results.
3. A malicious client could alter the Cookie header before 3. A malicious client could alter the Cookie header before
transmission, with unpredictable results. transmission, with unpredictable results.
Servers SHOULD encrypt and sign their cookies. However, encrypting Servers SHOULD encrypt and sign their cookies when transmitting them
and signing cookies does not prevent an attacker from transplanting a to the user agent (even when sending the cookies over a secure
cookie from one user agent to another. channel). However, encrypting and signing cookies does not prevent
an attacker from transplanting a cookie from one user agent to
another.
In addition to encrypting and signing the contents of every cookie, In addition to encrypting and signing the contents of every cookie,
servers that require a higher level of security SHOULD use the cookie servers that require a higher level of security SHOULD use the cookie
protocol only over a secure channel. protocol only over a secure channel.
7.2. Weak Confidentiality 7.4. Weak Confidentiality
Cookies do not provide isolation by port. If a cookie is readable by Cookies do not provide isolation by port. If a cookie is readable by
a service running on one port, the cookie is also readable by a a service running on one port, the cookie is also readable by a
service running on another port of the same server. If a cookie is service running on another port of the same server. If a cookie is
writable by a service on one port, the cookie is also writable by a writable by a service on one port, the cookie is also writable by a
service running on another port of the same server. For this reason, service running on another port of the same server. For this reason,
servers SHOULD NOT both run mutually distrusting services on servers SHOULD NOT both run mutually distrusting services on
different ports of the same machine and use cookies to store different ports of the same host and use cookies to store security-
security-sensitive information. sensitive information.
Cookies do not provide isolation by scheme. Although most commonly Cookies do not provide isolation by scheme. Although most commonly
used with the http and https schemes, the cookies for a given host used with the http and https schemes, the cookies for a given host
are also available to other schemes, such as ftp and gopher. This are also available to other schemes, such as ftp and gopher. This
lack of isolation is most easily seen when a user agent retrieves a lack of isolation is most easily seen when a user agent retrieves a
URI with a gopher scheme via HTTP, but the lack of isolation by URI with a gopher scheme via HTTP, but the lack of isolation by
scheme is also apparent via non-HTTP APIs that permit access to scheme is also apparent via non-HTTP APIs that permit access to
cookies, such as HTML's document.cookie API. cookies, such as HTML's document.cookie API.
7.3. Weak Integrity 7.5. Weak Integrity
Cookies do not provide integrity guarantees for sibling domains (and Cookies do not provide integrity guarantees for sibling domains (and
their subdomains). For example, consider foo.example.com and their subdomains). For example, consider foo.example.com and
bar.example.com. The foo.example.com server can set a cookie with a bar.example.com. The foo.example.com server can set a cookie with a
Domain attribute of ".example.com", and the user agent will include Domain attribute of ".example.com", and the user agent will include
that cookie in HTTP requests to bar.example.com. In the worst case, that cookie in HTTP requests to bar.example.com. In the worst case,
bar.example.com will be unable to distinguish this cookie from a bar.example.com will be unable to distinguish this cookie from a
cookie it set itself. The foo.example.com server might be able to cookie it set itself. The foo.example.com server might be able to
leverage this ability to mount an attack against bar.example.com. leverage this ability to mount an attack against bar.example.com.
skipping to change at page 26, line 5 skipping to change at page 26, line 17
active network attacker might be able to leverage this ability to active network attacker might be able to leverage this ability to
mount an attack against example.com even if example.com uses HTTPS mount an attack against example.com even if example.com uses HTTPS
exclusively. exclusively.
Servers can partially mitigate these attacks by encrypting and Servers can partially mitigate these attacks by encrypting and
signing their cookies. However, using cryptography does not mitigate signing their cookies. However, using cryptography does not mitigate
the issue completely because an attacker can replay a cookie he or the issue completely because an attacker can replay a cookie he or
she received from the authentic example.com server in the user's she received from the authentic example.com server in the user's
session, with unpredictable results. session, with unpredictable results.
7.6. Reliance on DNS
The cookie protocol relies upon the Domain Name System (DNS) for
security. If the DNS is partially or fully compromised, the cookie
protocol might fail to provide the security properties required by
applications.
8. Normative References 8. 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., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
 End of changes. 33 change blocks. 
58 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/