draft-ietf-httpstate-cookie-04.txt   draft-ietf-httpstate-cookie-05.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2109 (if approved) February 23, 2010 Obsoletes: 2109 (if approved) March 7, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: August 27, 2010 Expires: September 8, 2010
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-04 draft-ietf-httpstate-cookie-05
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 that degrade its security and privacy.
HTTP.
NOTE: If you have suggestions for improving the draft, please send NOTE: If you have suggestions for improving the draft, please send
email to http-state@ietf.org. Suggestions with test cases are email to http-state@ietf.org. Suggestions with test cases are
especially appreciated. especially appreciated.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 46 skipping to change at page 1, line 45
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 August 27, 2010. This Internet-Draft will expire on September 8, 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 35 skipping to change at page 3, line 35
5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.3. Paths . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 17 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 17
5.2.1. The Max-Age Attribute . . . . . . . . . . . . . . . . 19 5.2.1. The Max-Age Attribute . . . . . . . . . . . . . . . . 19
5.2.2. The Expires Attribute . . . . . . . . . . . . . . . . 19 5.2.2. The Expires Attribute . . . . . . . . . . . . . . . . 19
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 20 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 20
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 20 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 20
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 21 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 21
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 21 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 21
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 21 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 21
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 24 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 24
6. Implementation Considerations . . . . . . . . . . . . . . . . 26 6. Implementation Considerations . . . . . . . . . . . . . . . . 27
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2. Application Programmer Interfaces . . . . . . . . . . . . 26 6.2. Application Programmer Interfaces . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. General Recommendations . . . . . . . . . . . . . . . . . 27 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 27 7.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 28
7.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 27 7.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 29
7.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 28 7.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 29
7.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 28 7.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 30
7.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 29 7.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 30
7.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 30 7.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 31 8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
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 16, line 19 skipping to change at page 16, line 19
5.1.2. Domains 5.1.2. Domains
A *canonicalized* host-name is the host-name converted to lower case. A *canonicalized* host-name is the host-name converted to lower case.
A request-host *domain-matches* a cookie-domain if at least one of A request-host *domain-matches* a cookie-domain if at least one of
the following conditions hold: the following conditions hold:
o The cookie-domain and the canonicalized request-host are o The cookie-domain and the canonicalized request-host are
identical. identical.
o The cookie-domain is a suffix of the canonicalized request-host, o All of the following conditions hold:
the last character of the canonicalized request-host that is not
included in the cookie-domain is a U+002E (".") character, and * The cookie-domain is a suffix of the canonicalized request-
request-host is a host name (i.e., not an IP address). [TODO: Is host.
this the right way to spec this???]
* The last character of the canonicalized request-host that is
not included in the cookie-domain is a U+002E (".") character.
* The request-host is a host name (i.e., not an IP address).
5.1.3. Paths 5.1.3. Paths
The user agent MUST use the following algorithm to compute the The user agent MUST use the following algorithm to compute the
*default-path* of a cookie: *default-path* of a cookie:
1. Let uri-path be the path portion of the Request-URI. 1. Let uri-path be the path portion of the Request-URI.
2. If the first character of the uri-path is not a U+002F ("/") 2. If the first character of the uri-path is not a U+002F ("/")
character, output U+002F ("/") and skip the remaining steps. character, output U+002F ("/") and skip the remaining steps.
3. If the uri-path contains only a single U+002F ("/") character, 3. If the uri-path contains only a single U+002F ("/") character,
output U+002F ("/") and skip the remaining steps. output U+002F ("/") and skip the remaining steps.
4. Output the characters of the uri-path from the first character up 4. Output the characters of the uri-path from the first character up
to, but not including, the right-most U+002F ("/"). to, but not including, the right-most U+002F ("/").
A request-path *path-matches* a cookie-path if at least one of the A request-path *path-matches* a cookie-path if at least one of the
following conditions hold: [TODO: This isn't exactly what IE or following conditions hold:
Firefox does.]
o The cookie-path and the request-path are identical. o The cookie-path and the request-path are identical.
o The cookie-path is a prefix of the request-path and the last o The cookie-path is a prefix of the request-path and the last
character of the cookie-path is U+002F ("/"). character of the cookie-path is U+002F ("/").
o The cookie-path is a prefix of the request-path and the first o The cookie-path is a prefix of the request-path and the first
character of the request-path that is not included in the cookie- character of the request-path that is not included in the cookie-
path is a U+002F ("/") character. path is a U+002F ("/") character.
skipping to change at page 19, line 23 skipping to change at page 19, line 23
If the remainder of attribute-value contains a non-DIGIT character, If the remainder of attribute-value contains a non-DIGIT character,
ignore the cookie-av. ignore the cookie-av.
Let delta-seconds be the attribute-value converted to an integer. Let delta-seconds be the attribute-value converted to an integer.
If delta-seconds is less than or equal to zero (0), let expiry-time If delta-seconds is less than or equal to zero (0), let expiry-time
be the current date and time. Otherwise, let the expiry-time be the be the current date and time. Otherwise, let the expiry-time be the
current date and time plus delta-seconds seconds. current date and time plus delta-seconds seconds.
Append an attribute to the cookie-attribute-list with an attribute- Append an attribute to the cookie-attribute-list with an attribute-
name of Expires (note the name conversion) and an attribute-value of name of Max-Age and an attribute-value of expiry-time.
expiry-time.
5.2.2. The Expires Attribute 5.2.2. The Expires Attribute
If the attribute-name case-insensitively matches the string If the attribute-name case-insensitively matches the string
"Expires", the user agent MUST process the cookie-av as follows. "Expires", the user agent MUST process the cookie-av as follows.
Let the parsed-cookie-date be the result of parsing the attribute- Let the parsed-cookie-date be the result of parsing the attribute-
value as cookie-date. value as cookie-date.
If the attribute-value failed to parse as a cookie date, ignore the If the attribute-value failed to parse as a cookie date, ignore the
skipping to change at page 20, line 37 skipping to change at page 20, line 37
Let cookie-domain be the attribute-value without the leading Let cookie-domain be the attribute-value without the leading
U+002E (".") character. U+002E (".") character.
Otherwise: Otherwise:
Let cookie-domain be the entire attribute-value. Let cookie-domain be the entire attribute-value.
Convert the cookie-domain to lower case. Convert the cookie-domain to lower case.
[TODO: Test ".127.0.0.1" and "127.0.0.1"]
Append an attribute to the cookie-attribute-list with an attribute- Append an attribute to the cookie-attribute-list with an attribute-
name of Domain and an attribute-value of cookie-domain. name of Domain and an attribute-value of cookie-domain.
5.2.4. The Path Attribute 5.2.4. The Path Attribute
If the attribute-name case-insensitively matches the string "Path", If the attribute-name case-insensitively matches the string "Path",
the user agent MUST process the cookie-av as follows. the user agent MUST process the cookie-av as follows.
If the attribute-value is empty or if the first character of the If the attribute-value is empty or if the first character of the
attribute-value is not U+002F ("/"): attribute-value is not U+002F ("/"):
Let cookie-path be the default-path. [TODO: We need more tests Let cookie-path be the default-path.
for this, including with " characters and with multiple Path
attributes.]
Otherwise: Otherwise:
Let cookie-path be the attribute-value. Let cookie-path be the attribute-value.
Append an attribute to the cookie-attribute-list with an attribute- Append an attribute to the cookie-attribute-list with an attribute-
name of Path and an attribute-value of cookie-path. name of Path and an attribute-value of cookie-path.
5.2.5. The Secure Attribute 5.2.5. The Secure Attribute
skipping to change at page 21, line 49 skipping to change at page 21, line 47
When the user agent receives a cookie from a Request-URI with name When the user agent receives a cookie from a Request-URI with name
cookie-name, value cookie-value, and attributes cookie-attribute- cookie-name, value cookie-value, and attributes cookie-attribute-
list, the user agent MUST process the cookie as follows: list, the user agent MUST process the cookie as follows:
1. Create a new cookie with name cookie-name, value cookie-value. 1. Create a new cookie with name cookie-name, value cookie-value.
Set the creation-time and the last-access-time to the current Set the creation-time and the last-access-time to the current
date and time. date and time.
2. If the cookie-attribute-list contains an attribute with an 2. If the cookie-attribute-list contains an attribute with an
attribute-name of "Expires": attribute-name of "Max-Age":
Set the cookie's persistent-flag to true. Set the cookie's persistent-flag to true.
Set the cookie's expiry-time to attribute-value of the last Set the cookie's expiry-time to 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 "Expires". [TODO: Test that this really works when mixing of "Max-Age".
Max-Age and Expires.]
Otherwise, if the cookie-attribute-list contains an attribute
with an attribute-name of "Expires" (and does not contain an
attribute with an attribute-name of "Max-Age"):
Set the cookie's persistent-flag to true.
Set the cookie's expiry-time to attribute-value of the last
attribute in the cookie-attribute-list with an attribute-name
of "Expires".
Otherwise: Otherwise:
Set the cookie's persistent-flag to false. Set the cookie's persistent-flag to false.
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":
skipping to change at page 23, line 32 skipping to change at page 23, line 37
default-path of the Request-URI. default-path of the Request-URI.
7. 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.
8. 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.
9. Remove from the cookie store all cookies that share the same 9. If the cookie's name and value are both empty, abort these steps
name, domain, path, and host-only-flag as the newly created and ignore the cookie entirely.
cookie. [TODO: Validate this list!] [TODO: There's some funny
business around http-only here.]
10. If the cookie's name and value are both empty, abort these 10. If the cookie's expiry-time is not in the future, abort these
steps. steps and ignore the cookie entirely.
11. If the cookie's expiry-time is not in the future, abort these 11. If the cookie was received from a non-HTTP context and the
steps. cookie's http-only-flag is set, abort these steps and ignore the
cookie entirely.
12. Insert the newly created cookie into the cookie store. 12. If the cookie store contains a cookie with the same name,
domain, and path as the newly created cookie:
1. Let old-cookie be the existing cookie with the same name,
domain, and path as the newly created cookie. (Notice that
this algorithm maintains the invariant that there is at most
one such cookie.)
2. If the newly created cookie was received from an non-HTTP
context and the old-cookie's host-only-flag is set, abort
these steps and ignore the newly created cookie entirely.
3. Update the creation-time of the newly created cookie to
match the creation-time of the old-cookie.
4. Remove the old-cookie from the cookie store.
13. 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 25, line 7 skipping to change at page 25, line 28
The cookie's host-only-flag is true and the canonicalized The cookie's host-only-flag is true and the canonicalized
request-host is identical to the cookie's domain. request-host is identical to the cookie's domain.
Or: Or:
The cookie's host-only-flag is false and the request-host The cookie's host-only-flag is false and the request-host
domain-matches cookie's domain. domain-matches cookie's domain.
* The Request-URI's path patch-matches cookie's path. * The Request-URI's path patch-matches cookie's path.
* If the cookie's secure-only field is true, then the Request- * If the cookie's secure-only-flag is true, then the Request-
URI's scheme must denote a "secure" protocol (as defined by URI's scheme must denote a "secure" protocol (as defined by
the user agent). the user agent).
NOTE: The notion of a "secure" protocol is not defined by NOTE: The notion of a "secure" protocol is not defined by
this document. Typically, user agents consider a protocol this document. Typically, user agents consider a protocol
secure if the protocol makes use of transport-layer secure if the protocol makes use of transport-layer
security, such as TLS. For example, most user agents security, such as TLS. For example, most user agents
consider "https" to be a scheme that denotes a secure consider "https" to be a scheme that denotes a secure
protocol. protocol.
* If the cookie's http-only field is true, then exclude the * If the cookie's http-only-flag is true, then exclude the
cookie unless the cookie-string is being generated for an cookie unless the cookie-string is being generated for an
"HTTP" API (as defined by the user agent). "HTTP" API (as defined by the user agent).
2. Sort the cookie-list in the following order: 2. Sort the cookie-list in the following order:
* Cookies with longer paths are listed before cookies with * Cookies with longer paths are listed before cookies with
shorter paths. shorter paths.
* Among cookies that have equal length path fields, cookies with * Among cookies that have equal length path fields, cookies with
earlier creation-times are listed before cookies with later earlier creation-times are listed before cookies with later
skipping to change at page 26, line 5 skipping to change at page 26, line 19
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 ("; ").
Note: Despite its name, the cookie-string is actually a sequence of
octets, not a sequence of characters. To convert the cookie-string
into a sequence of characters (e.g., for presentation to the user),
the user agent SHOULD use the UTF-8 character encoding [RFC3629].
6. Implementation Considerations 6. Implementation Considerations
6.1. Limits 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).
skipping to change at page 27, line 7 skipping to change at page 28, line 7
by the cookie protocol. by the cookie protocol.
Instead of providing string-based APIs to the cookie protocols, Instead of providing string-based APIs to the cookie protocols,
implementations would be well-served by providing more semantic APIs. implementations would be well-served by providing more semantic APIs.
It is beyond the scope of this document to recommend specific API It is beyond the scope of this document to recommend specific API
designs, but there are clear benefits to accepting a abstract "Date" designs, but there are clear benefits to accepting a abstract "Date"
object instead of a serialized date string. object instead of a serialized date string.
7. Security Considerations 7. Security Considerations
7.1. General Recommendations 7.1. Overview
The cookie protocol is NOT RECOMMENDED for new applications. The cookie protocol has a number of security and privacy pitfalls.
For applications that do use the cookie protocol, servers SHOULD NOT In particular, cookies encourage developers to rely on ambient
rely upon cookies for security. authority for authentication, often creating vulnerabilities such as
cross-site request forgery. When storing session identifiers in
cookies, developers often create session fixation vulnerabilities.
Transport-layer encryption, such as that employed in HTTPS, is
insufficient to prevent a network attacker from obtaining or altering
a victim's cookies because the cookie protocol itself has various
vulnerabilities (see "Weak Confidentiality" and "Weak Integrity",
below). In addition, by default, the cookie protocol does not
provide confidentiality or integrity from network attackers, even
when used in conjunction with HTTPS.
7.2. Ambient Authority 7.2. Ambient Authority
A server that uses cookies to authenticate users can suffer security A server that uses cookies to authenticate users can suffer security
vulnerabilities because some user agents let remote parties issue vulnerabilities because some user agents let remote parties issue
HTTP requests from the user agent (e.g., via HTTP redirects and HTML HTTP requests from the user agent (e.g., via HTTP redirects and HTML
forms). When issuing those requests, user agent attaches cookies forms). When issuing those requests, user agent attaches cookies
even if the entity does not know the contents of the cookies, even if the entity does not know the contents of the cookies,
possibly letting the remote entity exercise authority at an unwary possibly letting the remote entity exercise authority at an unwary
server. server.
skipping to change at page 29, line 43 skipping to change at page 31, line 7
Domain attribute of ".example.com" (possibly overwriting an existing Domain attribute of ".example.com" (possibly overwriting an existing
".example.com" cookie set by bar.example.com), and the user agent ".example.com" cookie set by bar.example.com), and the user agent
will include that cookie in HTTP requests to bar.example.com. In the will include that cookie in HTTP requests to bar.example.com. In the
worst case, bar.example.com will be unable to distinguish this cookie worst case, bar.example.com will be unable to distinguish this cookie
from a cookie it set itself. The foo.example.com server might be from a cookie it set itself. The foo.example.com server might be
able to leverage this ability to mount an attack against able to leverage this ability to mount an attack against
bar.example.com. bar.example.com.
Even though the cookie protocol supports the Path attribute, the Path Even though the cookie protocol supports the Path attribute, the Path
attribute does not provide any integrity protection because the user attribute does not provide any integrity protection because the user
agent with accept an arbitrary Path attribute in a Set-Cookie header. agent will accept an arbitrary Path attribute in a Set-Cookie header.
For example, an HTTP response to a request for For example, an HTTP response to a request for
http://example.com/foo/bar can set a cookie with a Path attribute of http://example.com/foo/bar can set a cookie with a Path attribute of
"/qux". Consequently, servers SHOULD NOT both run mutually "/qux". Consequently, servers SHOULD NOT both run mutually
distrusting services on different paths of the same host and use distrusting services on different paths of the same host and use
cookies store security sensitive information. cookies store security sensitive information.
An active network attacker can also inject cookies into the Cookie An active network attacker can also inject cookies into the Cookie
header sent to https://example.com/ by impersonating a response from header sent to https://example.com/ by impersonating a response from
http://example.com/ and injecting a Set-Cookie header. The HTTPS http://example.com/ and injecting a Set-Cookie header. The HTTPS
server at example.com will be unable to distinguish these cookies server at example.com will be unable to distinguish these cookies
skipping to change at page 31, line 16 skipping to change at page 32, line 16
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[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.
8.2. Informative References 8.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.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This document borrows heavily from RFC 2109 [RFC2109]. [TODO: Figure This document borrows heavily from RFC 2109 [RFC2109]. We are
out the proper way to credit the authors of RFC 2109.] indebted to David M. Kristol and Lou Montulli for their efforts to
specify the cookie protocol. David M. Kristol, in particular,
provided invaluable advice on navigating the IETF process. We would
also like to thank Thomas Broyer, Tyler Close, Bil Corry, corvid, Roy
T. Fielding, Blake Frantz, Eran Hammer-Lahav, Jeff Hodges, Achim
Hoffmann, Georg Koppen, Dean McNamee, Mark Miller, Yngve N.
Pettersen, Julian Reschke, Mark Seaborn, Maciej Stachowiak, Daniel
Stenberg, David Wagner, Dan Winship, and Dan Witte for their valuable
feedback on this document.
Author's Address Author's Address
Adam Barth Adam Barth
University of California, Berkeley University of California, Berkeley
Email: abarth@eecs.berkeley.edu Email: abarth@eecs.berkeley.edu
URI: http://www.adambarth.com/ URI: http://www.adambarth.com/
 End of changes. 26 change blocks. 
57 lines changed or deleted 105 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/