draft-ietf-httpstate-cookie-21.txt   draft-ietf-httpstate-cookie-22.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2965 (if approved) January 20, 2011 Obsoletes: 2965 (if approved) February 18, 2011
Intended status: Standards Track Intended status: Standards Track
Expires: July 24, 2011 Expires: August 22, 2011
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-21 draft-ietf-httpstate-cookie-22
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a (called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol. Although stateful session over the mostly stateless HTTP protocol. Although
cookies have many historical infelicities that degrade their security cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet. on the Internet.
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 24, 2011. This Internet-Draft will expire on August 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 17 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 17
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 19 5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 19
5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 19 5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 19
5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 19 5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 19
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 20 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 20
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 22 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 22
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 23 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 23
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 23 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 23
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 23 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 24
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 24 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 24
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 24 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 24
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 24 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 24
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 28 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 28
6. Implementation Considerations . . . . . . . . . . . . . . . . 30 6. Implementation Considerations . . . . . . . . . . . . . . . . 30
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Application Programming Interfaces . . . . . . . . . . . . 30 6.2. Application Programming Interfaces . . . . . . . . . . . . 30
6.3. IDNA dependency and migration . . . . . . . . . . . . . . 30 6.3. IDNA dependency and migration . . . . . . . . . . . . . . 30
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 32 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 32
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 32 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 32
skipping to change at page 5, line 46 skipping to change at page 5, line 46
generating cookies. generating cookies.
User agents MUST implement the more liberal processing rules defined User agents MUST implement the more liberal processing rules defined
in Section 5, in order to maximize interoperability with existing in Section 5, in order to maximize interoperability with existing
servers that do not conform to the well-behaved profile defined in servers that do not conform to the well-behaved profile defined in
Section 4. Section 4.
This document specifies the syntax and semantics of these headers as This document specifies the syntax and semantics of these headers as
they are actually used on the Internet. In particular, this document they are actually used on the Internet. In particular, this document
does not create new syntax or semantics beyond those in use today. does not create new syntax or semantics beyond those in use today.
The recommendations for cookie generation provided in The recommendations for cookie generation provided in Section 4
Section 4represent a preferred subset of current server behavior, and represent a preferred subset of current server behavior, and even the
even the more liberal cookie processing algorithm provided in more liberal cookie processing algorithm provided in Section 5 does
Section 5 does not recommend all of the syntactic and semantic not recommend all of the syntactic and semantic variations in use
variations in use today. Where some existing software differs from today. Where some existing software differs from the recommended
the recommended protocol in significant ways, the document contains a protocol in significant ways, the document contains a note explaining
note explaining the difference. the difference.
Prior to this document, there were at least three descriptions of Prior to this document, there were at least three descriptions of
cookies: the so-called "Netscape cookie specification" [Netscape], cookies: the so-called "Netscape cookie specification" [Netscape],
RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these RFC 2109 [RFC2109], and RFC 2965 [RFC2965]. However, none of these
documents describe how the Cookie and Set-Cookie headers are actually documents describe how the Cookie and Set-Cookie headers are actually
used on the Internet (see [Kri2001] for historical context). In used on the Internet (see [Kri2001] for historical context). In
relation to previous IETF specifications of HTTP state management relation to previous IETF specifications of HTTP state management
mechanisms, this document requests the following actions: mechanisms, this document requests the following actions:
1. Change the status of [RFC2109] to Historic (it has already been 1. Change the status of [RFC2109] to Historic (it has already been
skipping to change at page 9, line 18 skipping to change at page 9, line 18
information to a user agent and for the user agent to return the information to a user agent and for the user agent to return the
state information to the origin server. state information to the origin server.
To store state, the origin server includes a Set-Cookie header in an To store state, the origin server includes a Set-Cookie header in an
HTTP response. In subsequent requests, the user agent returns a HTTP response. In subsequent requests, the user agent returns a
Cookie request header to the origin server. The Cookie header Cookie request header to the origin server. The Cookie header
contains cookies the user agent received in previous Set-Cookie contains cookies the user agent received in previous Set-Cookie
headers. The origin server is free to ignore the Cookie header or headers. The origin server is free to ignore the Cookie header or
use its contents for an application-defined purpose. use its contents for an application-defined purpose.
Origin servers can send a Set-Cookie response header with any Origin servers MAY send a Set-Cookie response header with any
response. An origin server can include multiple Set-Cookie header response. User agents MAY ignore Set-Cookie headers contained in
fields in a single response. The presence of a Cookie or a Set- responses with 100-level status codes but MUST process Set-Cookie
Cookie header field does not preclude HTTP caches from storing and headers contained in other responses (including responses with 400-
reusing a response. and 500-level status codes). An origin server can include multiple
Set-Cookie header fields in a single response. The presence of a
Cookie or a Set-Cookie header field does not preclude HTTP caches
from storing and reusing a response.
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into Origin servers SHOULD NOT fold multiple Set-Cookie header fields into
a single header field. The usual mechanism for folding HTTP headers a single header field. The usual mechanism for folding HTTP headers
fields (i.e., as defined in [RFC2616]) might change the semantics of fields (i.e., as defined in [RFC2616]) might change the semantics of
the Set-Cookie header field because the %x2C (",") character is used the Set-Cookie header field because the %x2C (",") character is used
by Set-Cookie in a way that conflicts with such folding. by Set-Cookie in a way that conflicts with such folding.
3.1. Examples 3.1. Examples
Using the Set-Cookie header, a server can send the user agent a short Using the Set-Cookie header, a server can send the user agent a short
skipping to change at page 12, line 27 skipping to change at page 12, line 27
Informally, the Set-Cookie response header contains the header name Informally, the Set-Cookie response header contains the header name
"Set-Cookie" followed by a ":" and a cookie. Each cookie begins with "Set-Cookie" followed by a ":" and a cookie. Each cookie begins with
a name-value pair, followed by zero or more attribute-value pairs. a name-value pair, followed by zero or more attribute-value pairs.
Servers SHOULD NOT send Set-Cookie headers that fail to conform to Servers SHOULD NOT send Set-Cookie headers that fail to conform to
the following grammar: the following grammar:
set-cookie-header = "Set-Cookie:" SP set-cookie-string set-cookie-header = "Set-Cookie:" SP set-cookie-string
set-cookie-string = cookie-pair *( ";" SP cookie-av ) set-cookie-string = cookie-pair *( ";" SP 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 / *base64-character
base64-character = ALPHA / DIGIT / "+" / "/" / "="
token = <token, defined in [RFC2616], Section 2.2> token = <token, defined in [RFC2616], Section 2.2>
cookie-av = expires-av / max-age-av / domain-av / cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av / path-av / secure-av / httponly-av /
extension-av extension-av
expires-av = "Expires=" sane-cookie-date expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1> sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT max-age-av = "Max-Age=" non-zero-digit *DIGIT
; In practice, both expires-av and max-age-av are limited ; In practice, both expires-av and max-age-av are limited
; to dates representable by the user agent. ; to dates representable by the user agent.
skipping to change at page 12, line 49 skipping to change at page 13, line 4
; digits 1 through 9 ; digits 1 through 9
domain-av = "Domain=" domain-value domain-av = "Domain=" domain-value
domain-value = <subdomain> domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as ; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1 ; enhanced by [RFC1123], Section 2.1
path-av = "Path=" path-value path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";"> path-value = <any CHAR except CTLs or ";">
secure-av = "Secure" secure-av = "Secure"
httponly-av = "HttpOnly" httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";"> extension-av = <any CHAR except CTLs or ";">
Note that some of the grammatical terms above reference documents Note that some of the grammatical terms above reference documents
that use different grammatical notations than this document (which that use different grammatical notations than this document (which
uses ABNF from [RFC5234]). uses ABNF from [RFC5234]).
The semantics of the cookie-value are not defined by this document. The semantics of the cookie-value are not defined by this document.
To maximize compatibility with user agents, servers that wish to To maximize compatibility with user agents, servers that wish to
store arbitrary data in a cookie-value SHOULD encode that data, for store arbitrary data in a cookie-value SHOULD encode that data, for
example, using Base 16 [RFC4648]. example, using Base64 [RFC4648].
The portions of the set-cookie-string produced by the cookie-av term The portions of the set-cookie-string produced by the cookie-av term
are known as attributes. To maximize compatibility with user agents, are known as attributes. To maximize compatibility with user agents,
servers SHOULD NOT produce two attributes with the same name in the servers SHOULD NOT produce two attributes with the same name in the
same set-cookie-string. (See Section 5.3 for how user agents handle same set-cookie-string. (See Section 5.3 for how user agents handle
this case.) this case.)
Servers SHOULD NOT include more than one Set-Cookie header field in Servers SHOULD NOT include more than one Set-Cookie header field in
the same response with the same cookie-name. (See Section 5.2 for the same response with the same cookie-name. (See Section 5.2 for
how user agents handle this case.) how user agents handle this case.)
skipping to change at page 17, line 10 skipping to change at page 17, line 10
if the Cookie header contains two cookies with the same name (e.g., if the Cookie header contains two cookies with the same name (e.g.,
that were set with different Path or Domain attributes), servers that were set with different Path or Domain attributes), servers
SHOULD NOT rely upon the order in which these cookies appear in the SHOULD NOT rely upon the order in which these cookies appear in the
header. header.
5. User Agent Requirements 5. User Agent Requirements
This section specifies the Cookie and Set-Cookie headers in This section specifies the Cookie and Set-Cookie headers in
sufficient detail that a user agent implementing these requirements sufficient detail that a user agent implementing these requirements
precisely can interoperate with existing servers (even those that do precisely can interoperate with existing servers (even those that do
not conform to the well-behaved profile described in Section 4. not conform to the well-behaved profile described in Section 4).
A user agent could enforce more restrictions than those specified
herein (e.g., for the sake of improved security); however,
experiments have shown that such strictness reduces the likelihood
that a user agent will be able to interoperate with existing servers.
5.1. Subcomponent Algorithms 5.1. Subcomponent Algorithms
This section defines some algorithms used by user agents to process This section defines some algorithms used by user agents to process
specific subcomponents of the Cookie and Set-Cookie headers. specific subcomponents of the Cookie and Set-Cookie headers.
5.1.1. Dates 5.1.1. Dates
The user agent MUST use an algorithm equivalent to the following The user agent MUST use an algorithm equivalent to the following
algorithm to parse a cookie-date. Note that the various boolean algorithm to parse a cookie-date. Note that the various boolean
skipping to change at page 35, line 41 skipping to change at page 35, line 41
not set the Secure attribute, the protection provided by the secure not set the Secure attribute, the protection provided by the secure
channel will be largely moot. channel will be largely moot.
For example, consider a webmail server that stores a session For example, consider a webmail server that stores a session
identifier in a cookie and is typically accessed over HTTPS. If the identifier in a cookie and is typically accessed over HTTPS. If the
server does not set the Secure attribute on its cookies, an active server does not set the Secure attribute on its cookies, an active
network attacker can intercept any outbound HTTP request from the network attacker can intercept any outbound HTTP request from the
user agent and redirect that request to the webmail server over HTTP. user agent and redirect that request to the webmail server over HTTP.
Even if the webmail server is not listening for HTTP connections, the Even if the webmail server is not listening for HTTP connections, the
user agent will still include cookies in the request. The active user agent will still include cookies in the request. The active
network attacker can intercept these cookies, reply them against the network attacker can intercept these cookies, replay them against the
server, and learn the contents of the user's email. If, instead, the server, and learn the contents of the user's email. If, instead, the
server had set the Secure attribute on its cookies, the user agent server had set the Secure attribute on its cookies, the user agent
would not have included the cookies in the clear-text request. would not have included the cookies in the clear-text request.
8.4. Session Identifiers 8.4. Session Identifiers
Instead of storing session information directly in a cookie (where it Instead of storing session information directly in a cookie (where it
might be exposed to or replayed by an attacker), servers commonly might be exposed to or replayed by an attacker), servers commonly
store a nonce (or "session identifier") in a cookie. When the server store a nonce (or "session identifier") in a cookie. When the server
receives an HTTP request with a nonce, the server can look up state receives an HTTP request with a nonce, the server can look up state
 End of changes. 12 change blocks. 
22 lines changed or deleted 30 lines changed or added

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