draft-ietf-httpstate-cookie-22.txt   draft-ietf-httpstate-cookie-23.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2965 (if approved) February 18, 2011 Obsoletes: 2965 (if approved) March 1, 2011
Intended status: Standards Track Intended status: Standards Track
Expires: August 22, 2011 Expires: September 2, 2011
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-22 draft-ietf-httpstate-cookie-23
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. This document obsoletes [RFC2965].
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
If you have suggestions for improving this document, please send If you have suggestions for improving this document, please send
email to <mailto:http-state@ietf.org>. Suggestions with test cases email to <mailto:http-state@ietf.org>. Suggestions with test cases
are especially appreciated. Further Working Group information is are especially appreciated. Further Working Group information is
available from <https://tools.ietf.org/wg/httpstate/>. available from <https://tools.ietf.org/wg/httpstate/>.
Status of this Memo Status of this Memo
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 August 22, 2011. This Internet-Draft will expire on September 2, 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 23 skipping to change at page 3, line 23
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 12 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 12
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 13 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 13
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 17 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 18
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 17 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 18
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 19 5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 20
5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 19 5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 20
5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 19 5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 20
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 20 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 21
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 22 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 23
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 23 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 24
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 23 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 24
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 24 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 25
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 24 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 25
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 24 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 25
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 24 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 25
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 28 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 29
6. Implementation Considerations . . . . . . . . . . . . . . . . 30 6. Implementation Considerations . . . . . . . . . . . . . . . . 31
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Application Programming Interfaces . . . . . . . . . . . . 30 6.2. Application Programming Interfaces . . . . . . . . . . . . 31
6.3. IDNA dependency and migration . . . . . . . . . . . . . . 30 6.3. IDNA dependency and migration . . . . . . . . . . . . . . 31
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 32 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 33
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 32 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 33
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 32 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 33
7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . . 33 7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 34 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 35
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 35 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 36
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 35 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 36
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 36 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 37
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 37 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 38
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 37 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 38
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 38 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 39
9.3. Cookie2 . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.3. Cookie2 . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.4. Set-Cookie2 . . . . . . . . . . . . . . . . . . . . . . . 38 9.4. Set-Cookie2 . . . . . . . . . . . . . . . . . . . . . . . 39
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.1. Normative References . . . . . . . . . . . . . . . . . . . 40 10.1. Normative References . . . . . . . . . . . . . . . . . . . 41
10.2. Informative References . . . . . . . . . . . . . . . . . . 40 10.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 42 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
Using the Set-Cookie header field, an HTTP server can pass name/value Using the Set-Cookie header field, an HTTP server can pass name/value
pairs and associated metadata (called cookies) to a user agent. When pairs and associated metadata (called cookies) to a user agent. When
the user agent makes subsequent requests to the server, the user the user agent makes subsequent requests to the server, the user
agent uses the metadata and other information to determine whether to agent uses the metadata and other information to determine whether to
return the name/value pairs in the Cookie header. return the name/value pairs in the Cookie header.
skipping to change at page 7, line 34 skipping to change at page 7, line 34
2.2. Syntax Notation 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), NUL (null octet), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet),
OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB
(horizontal tab), CHAR (any US-ASCII character), VCHAR (any visible (horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible
US-ASCII character), and WSP (whitespace). [USASCII] character), and WSP (whitespace).
The OWS (optional whitespace) rule is used where zero or more linear The OWS (optional whitespace) rule is used where zero or more linear
whitespace characters MAY appear: whitespace characters MAY appear:
OWS = *( [ obs-fold ] WSP ) OWS = *( [ obs-fold ] WSP )
; "optional" whitespace ; "optional" whitespace
obs-fold = CRLF obs-fold = CRLF
OWS SHOULD either not be produced or be produced as a single SP OWS SHOULD either not be produced or be produced as a single SP
character. character.
skipping to change at page 12, line 23 skipping to change at page 12, line 23
server to the user agent. server to the user agent.
4.1.1. Syntax 4.1.1. Syntax
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 / *base64-character cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
base64-character = ALPHA / DIGIT / "+" / "/" / "=" cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
token = <token, defined in [RFC2616], Section 2.2> ; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
token = <token, defined in [RFC2616], Section 2.2>
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av /
extension-av
expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT
; In practice, both expires-av and max-age-av
; are limited to dates representable by the
; user agent.
non-zero-digit = %x31-39
; digits 1 through 9
domain-av = "Domain=" domain-value
domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1
path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";">
secure-av = "Secure"
httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";">
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av /
extension-av
expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT
; In practice, both expires-av and max-age-av are limited
; to dates representable by the user agent.
non-zero-digit = %x31-39
; digits 1 through 9
domain-av = "Domain=" domain-value
domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1
path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";">
secure-av = "Secure"
httponly-av = "HttpOnly"
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 Base64 [RFC4648]. example, using Base64 [RFC4648].
skipping to change at page 33, line 22 skipping to change at page 34, line 22
Some user agents provide users with the ability to approve individual Some user agents provide users with the ability to approve individual
writes to the cookie store. In many common usage scenarios, these writes to the cookie store. In many common usage scenarios, these
controls generate a large number of prompts. However, some privacy- controls generate a large number of prompts. However, some privacy-
conscious users find these controls useful nonetheless. conscious users find these controls useful nonetheless.
7.3. Expiration Dates 7.3. Expiration Dates
Although servers can set the expiration date for cookies to the Although servers can set the expiration date for cookies to the
distant future, most user agents do not actually retain cookies for distant future, most user agents do not actually retain cookies for
multiple decades. Rather than chosing gratiously long expiration multiple decades. Rather than chosing gratuitously long expiration
periods, servers SHOULD promote user privacy by selecting reasonable periods, servers SHOULD promote user privacy by selecting reasonable
cookie expiration periods based on the purpose of the cookie. For cookie expiration periods based on the purpose of the cookie. For
example, a typical session identifier might reasonably be set to example, a typical session identifier might reasonably be set to
expire in two weeks. expire in two weeks.
8. Security Considerations 8. Security Considerations
8.1. Overview 8.1. Overview
Cookies have a number of security pitfalls. This section overviews a Cookies have a number of security pitfalls. This section overviews a
skipping to change at page 40, line 36 skipping to change at page 41, line 36
See Section 6.3 for an explanation why the normative See Section 6.3 for an explanation why the normative
reference to an obsoleted specification is needed. reference to an obsoleted specification is needed.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, Application Protocol Collation Registry", RFC 4790,
March 2007. March 2007.
[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
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, August 2010.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
10.2. Informative References 10.2. Informative References
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997. Mechanism", RFC 2109, February 1997.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. Mechanism", RFC 2965, October 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
 End of changes. 12 change blocks. 
78 lines changed or deleted 84 lines changed or added

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