idnits 2.17.1 draft-pettersen-cookie-v2-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([Netscape], [RFC2965]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC2965, but the abstract doesn't seem to directly say this. It does mention RFC2965 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4789 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-httpstate-cookie' is defined on line 1344, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Netscape' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) -- Duplicate reference: RFC2965, mentioned in 'ERRATA2', was also mentioned in 'RFC2965'. -- Obsolete informational reference (is this intentional?): RFC 2965 (ref. 'ERRATA2') (Obsoleted by RFC 6265) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Pettersen 3 Internet-Draft Opera Software ASA 4 Obsoletes: 2965 (if approved) March 14, 2011 5 Intended status: Standards Track 6 Expires: September 15, 2011 8 HTTP State Management Mechanism v2 9 draft-pettersen-cookie-v2-06 11 Abstract 13 This document specifies a way to create a stateful session with 14 Hypertext Transfer Protocol (HTTP) requests and responses. It 15 describes three HTTP headers, Cookie, Cookie2, and Set-Cookie2, which 16 carry state information between participating origin servers and user 17 agents. The method described here differs from both Netscape's 18 Cookie proposal [Netscape], and [RFC2965], but it can, provided some 19 requirements are met, interoperate with HTTP/1.1 user agents that use 20 Netscape's method. (See the HISTORICAL section.) 22 This document defines new rules for how cookies can be shared between 23 servers within a domain. These new rules are intended to address 24 security and privacy concerns that are difficult to counter for 25 clients implementing Netscape's proposed rules or the rules specified 26 by RFC 2965. 28 This document reflects implementation experience with RFC 2965 and 29 obsoletes it. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 15, 2011. 54 Copyright Notice 56 Copyright (c) 2011 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 This document may contain material from IETF Documents or IETF 70 Contributions published or made publicly available before November 71 10, 2008. The person(s) controlling the copyright in some of this 72 material may not have granted the IETF Trust the right to allow 73 modifications of such material outside the IETF Standards Process. 74 Without obtaining an adequate license from the person(s) controlling 75 the copyright in such materials, this document may not be modified 76 outside the IETF Standards Process, and derivative works of it may 77 not be created outside the IETF Standards Process, except to format 78 it for publication as an RFC or to translate it into languages other 79 than English. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 3.1. Syntax: General . . . . . . . . . . . . . . . . . . . . . 7 87 3.2. Origin Server Role . . . . . . . . . . . . . . . . . . . . 8 88 3.3. User Agent Role . . . . . . . . . . . . . . . . . . . . . 12 89 3.4. How an Origin Server Interprets the Cookie Header . . . . 19 90 3.5. Caching Proxy Role . . . . . . . . . . . . . . . . . . . . 19 91 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 20 93 4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 22 94 5. Implementation Considerations . . . . . . . . . . . . . . . . 22 95 5.1. Set-Cookie2 Content . . . . . . . . . . . . . . . . . . . 23 96 5.2. Stateless Pages . . . . . . . . . . . . . . . . . . . . . 23 97 5.3. Implementation Limits . . . . . . . . . . . . . . . . . . 23 98 5.4. Backwards Compatibility . . . . . . . . . . . . . . . . . 24 99 6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 6.1. User Agent Control . . . . . . . . . . . . . . . . . . . . 24 101 6.2. Origin Server Role . . . . . . . . . . . . . . . . . . . . 25 102 6.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 26 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 105 8.1. Protocol Design . . . . . . . . . . . . . . . . . . . . . 26 106 8.2. Cookie Spoofing . . . . . . . . . . . . . . . . . . . . . 27 107 8.3. Unexpected Cookie Sharing . . . . . . . . . . . . . . . . 27 108 8.4. Cookies for Account Information . . . . . . . . . . . . . 27 109 9. Historical . . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 9.1. Compatibility with Existing Implementations . . . . . . . 28 111 9.2. Caching and HTTP/1.0 . . . . . . . . . . . . . . . . . . . 29 112 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 113 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 114 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 115 11.2. Non-normative References . . . . . . . . . . . . . . . . . 30 116 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . . 30 117 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 119 1. Introduction 121 HTTP cookies are widely used to maintain state across multiple HTTP 122 requests in a wide variety of HTTP based applications, such as 123 shopping carts for web shops, login credentials, preferences, 124 identity information, etc. While alternatives exists, they are more 125 cumbersome than HTTP cookies. The flexibility and ease of use of 126 cookies may therefore have assisted the rapid spread of the World 127 Wide Web. 129 Unfortunately, some of the flexibility of cookies, specifically how 130 cookies are shared among multiple hosts, is causing security and 131 privacy concerns. 133 [RFC2965] specifies that a cookie may be shared with any server 134 within the Reach of the host, that is, the parent domain of the host, 135 and the [Netscape] proposal allowed, within certain restrictions, 136 even wider sharing to servers in the entire second- or third-level 137 domain in which the request-host is part. 139 In some domain hierarchies, such as the generic Top Level Domain 140 (TLD) dotCOM domain this will work well, but in many TLDs such as the 141 Country-Code TLD (ccTLD) dotUK, this kind of sharing can cause 142 problems, unless severely restricted, because it makes assumptions 143 about what control and authorization has actually been granted the 144 request-host. The dotUK TLD and many other ccTLDs have numerous 145 subdomains that are treated as actual TLDs or registry like domains, 146 similar to dotCOM, dotNet and dotORG, such as the co.uk, org.uk and 147 ac.uk domains that are used to group otherwise unrelated domains into 148 categories based on their intended usage (e.g. commercial, non- 149 commercial, governmental, academic). 151 Permitting cookies to be shared across such registry-like domains may 152 result in undesirable datasharing, denial of service problems, even 153 security related problems. 155 The original rules in Netscape's proposal, one internal dot in domain 156 in the generic TLDs and two in domain name for non-generic TLDs, 157 turned out not to be good enough, nor were they properly implemented 158 in any client as they severely limited legitimate use of cookies; 159 RFC2965's one level up rule restricted the problem somewhat, but not 160 enough, as it was still possible to bypass the restrictions. Clients 161 have implemented or proposed various heuristics to limit the impact 162 of the problem, some by using a blacklist of second level domains 163 that the client is not permitted to accept cookies for, others use 164 DNS IP address lookups of the Set-Cookie header field's Domain 165 attribute as a heuristic method to determine the appropriateness of 166 permitting a cookie to be set, and a large database of domains that 167 should not be able to accept cookies have also been proposed. 169 Similarly, but less serious, the ability to set cookies to a parent 170 path can, under some circumstances, cause interference between 171 different applications in a given environment. In single application 172 environments such sharing is not dangerous, but could be problematic 173 when multiple independent administrators share the same service, such 174 as in shared hosting environments where all users are hosted in their 175 own path on the same server. In such environments a malicious user 176 can set a cookie that is shared by many users, and since most version 177 0 [Netscape] implementations do not enforce a prefix path restriction 178 it is also possible to limit the cookies to a path not controlled by 179 the user, but not visible to all the other users on the host. Such 180 cookies can interfere with the function of other applications on the 181 host or within the domain. 183 This document presents an alternative method for reducing these 184 problems by 186 o Removing the Domain attribute that permitted cookies to be 187 specified for the parent domain, and instead introduces the 188 SubDomain attribute that will permit servers to share cookies, but 189 only with servers whose name domain-matches the name of the 190 request-host that set the cookie, and not parent domains. 192 o Removing the Path attribute, replacing it by the SubPath attribute 193 that may be used to specify which resources under the request-path 194 will be allowed to receive the cookie, instead of specifying which 195 parent path is allowed to send the cookie. 197 This specification will not be able to accept cookies for hosts that 198 are using domain specifications for parent domains as defined by the 199 previous cookie specifications, but implementations using the older 200 specification will be able to accept cookies from hosts following 201 this specification. 203 This document also introduces new requirements for the contents of 204 the Cookie header field, specifically that the $Domain and $Path 205 attributes must always be sent, even when no domain or path has been 206 specified, as this will allow request-hosts to verify the domain of 207 the cookies even for cookies received from hosts using the older 208 specifications. 210 2. Terminology 212 The terms user agent, client, server, proxy, origin server, and 213 header field, and the tokens DIGIT, token, http_URL, and quoted- 214 string have the same meaning as in the HTTP/1.1 specification 215 [RFC2616]. The terms abs_path and absoluteURI have the same meaning 216 as in the URI Syntax specification [RFC3986]. 218 The grammar uses the notation from the HTTP/1.1 specification 219 [RFC2616] to describe the syntax of the HTTP header fields. 221 Host name (HN) means either the host domain name (HDN) or the numeric 222 Internet Protocol (IP) address or IP-literal of a host, as defined by 223 [RFC3986]. The fully qualified domain name is preferred; use of 224 numeric IP addresses or IP-literals is strongly discouraged. 226 The terms request-host and request-URI refer to the values the client 227 would send to the server as, respectively, the host (but not port) 228 and abs_path portions of the absoluteURI (http_URL) of the HTTP 229 request line. Note that request-host is a HN. 231 The term effective host name is related to host name. If a host name 232 is a host domain name and contains no dots, the effective host name 233 is that name with the string .local appended to it. Otherwise the 234 effective host name is the same as the host name. Note that all 235 effective host names contain at least one dot. 237 The term request-port refers to the port portion of the absoluteURI 238 (http_URL) of the HTTP request line. If the absoluteURI has no 239 explicit port, the request-port is the HTTP default, 80, for HTTP 240 URIs, and the HTTPS default, 443, for HTTPS URIs [RFC2818]. The 241 request-port of a cookie is the request-port of the request in which 242 a Set-Cookie2 response header field was returned to the user agent. 244 Host names can be specified either as an IP address, IP-literal or an 245 HDN string. Sometimes we compare one host name with another. (Such 246 comparisons SHALL be case-insensitive.) Host A's name domain-matches 247 host B's if 249 o their host name strings string-compare equal; or 251 o A is a HDN string and has the form NB, where N is a non-empty name 252 string, B has the form .B', and B' is a HDN string. (So, x.y.com 253 domain-matches .Y.com but not Y.com.) 255 Note that domain-match is not a commutative operation: a.b.c.com 256 domain-matches .c.com, but not the reverse. 258 The reach R of a host name H is defined as follows: 260 o If 261 * H is the host domain name of a host; and, 263 * H has the form A.B; and 265 * A has no embedded (that is, interior) dots; and 267 * B has at least one embedded dot, or B is the string "local". 268 then the reach of H is .B. 270 o Otherwise, the reach of H is H. 272 For two strings that represent paths, P1 and P2, P1 path-matches P2 273 if P2 is a prefix of P1 (including the case where P1 and P2 string- 274 compare equal). Thus, the string /tec/waldo path-matches /tec. 276 Because it was used in Netscape's original implementation of state 277 management, we will use the term cookie to refer to the state 278 information that passes between an origin server and user agent, and 279 that gets stored by the user agent. 281 3. Description 283 We describe here a way for an origin server to send state information 284 to the user agent, and for the user agent to return the state 285 information to the origin server. The goal is to have a minimal 286 impact on HTTP and user agents. 288 3.1. Syntax: General 290 The two state management header fields, Set-Cookie2 and Cookie, have 291 common syntactic properties involving attribute-value pairs. 293 av-pairs = av-pair *(";" av-pair) 294 av-pair = attr ["=" value] ; optional value 295 attr = token 296 value = token | quoted-string 298 Attributes (names) (attr) are case-insensitive. White space is 299 permitted between tokens. Note that while the above syntax 300 description shows value as optional, most attrs require them. Note 301 also that, unless prohibited, all values in the grammar below can be 302 represented as quoted string, even if the grammar does not directly 303 indicate it. 305 NOTE: The syntax above allows whitespace between the attribute name 306 and the = sign. 308 3.2. Origin Server Role 310 3.2.1. General 312 The origin server initiates a session, if it so desires. To do so, 313 it returns an extra HTTP response header to the client, Set-Cookie2, 314 described below. 316 A user agent returns a Cookie request header field (see below) to the 317 origin server if it chooses to continue the session. The origin 318 server MAY ignore it or use it to determine the current state of the 319 session. It MAY send back to the client a Set-Cookie2 response 320 header field with the same or different information, or it MAY send 321 no Set-Cookie2 header at all. The origin server effectively ends a 322 session by sending the client a Set-Cookie2 header field with Max- 323 Age=0. 325 Servers MAY return Set-Cookie2 response header fields with any 326 response. User agents SHOULD send Cookie request header fields, 327 subject to other rules detailed below, with every request. 329 An origin server MAY include multiple Set-Cookie2 header fields in a 330 response. Note that an intervening gateway could fold such multiple 331 headers into a single header, as described by [RFC2616]. 333 3.2.2. Set-Cookie2 Syntax 335 The syntax for the Set-Cookie2 response header field is 337 set-cookie = "Set-Cookie2:" cookies 338 cookies = 1#cookie 339 cookie = NAME "=" VALUE *(";" set-cookie-av) 340 NAME = attr 341 VALUE = value 342 set-cookie-av = "Comment" "=" value 343 | "CommentURL" "=" <"> http_URL <"> 344 | "Discard" 345 | "SubDomain" 346 | "Max-Age" "=" value 347 | "SubPath" "=" value 348 | "Port" [ "=" <"> portlist <"> ] 349 | "Unsecure" 350 | "Version" "=" 1*DIGIT 351 | "HttpOnly" 352 portlist = 1#portnum 353 portnum = 1*DIGIT 355 Informally, the Set-Cookie2 response header comprises the token "Set- 356 Cookie2:", followed by a comma-separated list of one or more cookies. 357 Each cookie begins with a NAME=VALUE pair, followed by zero or more 358 semi-colon-separated attribute-value pairs. The syntax for 359 attribute-value pairs was shown earlier. The specific attributes and 360 the semantics of their values follows. The NAME=VALUE attribute- 361 value pair MUST come first in each cookie. The others, if present, 362 can occur in any order. If an attribute appears more than once in a 363 cookie, the client SHALL use only the value associated with the first 364 appearance of the attribute; a client MUST ignore values after the 365 first. 367 The NAME of a cookie MAY be the same as one of the attributes in this 368 specification. However, because the cookie's NAME must come first in 369 a Set-Cookie2 response header field, the NAME and its VALUE cannot be 370 confused with an attribute-value pair. 372 NAME=VALUE REQUIRED. The name of the state information ("cookie") 373 is NAME, and its value is VALUE. NAMEs that begin with $ are 374 reserved and MUST NOT be used by applications. The VALUE is 375 opaque to the user agent and may be anything the origin server 376 chooses to send, possibly in a server-selected printable ASCII 377 encoding. "Opaque" implies that the content is of interest and 378 relevance only to the origin server. The content may, in fact, be 379 readable by anyone that examines the Set-Cookie2 header field. 381 Comment=value OPTIONAL. Because cookies can be used to derive or 382 store private information about a user, the value of the Comment 383 attribute allows an origin server to document how it intends to 384 use the cookie. The user can inspect the information to decide 385 whether to initiate or continue a session with this cookie. 386 Characters in value MUST be in UTF-8 encoding. [RFC3629] 388 CommentURL="http_URL" OPTIONAL. Because cookies can be used to 389 derive or store private information about a user, the CommentURL 390 attribute allows an origin server to document how it intends to 391 use the cookie. The user can inspect the information identified 392 by the URL to decide whether to initiate or continue a session 393 with this cookie. 395 Discard OPTIONAL. The Discard attribute instructs the user agent to 396 discard the cookie unconditionally when the user agent terminates. 398 SubDomain OPTIONAL. The SubDomain attribute specifies that the user 399 agent should share the cookie with any hosts that domain-matches 400 the name of the host sending the cookie 402 Max-Age=value OPTIONAL. The value of the Max-Age attribute is 403 delta-seconds, the lifetime of the cookie in seconds, a decimal 404 non-negative integer. To handle cached cookies correctly, a 405 client SHOULD calculate the age of the cookie according to the age 406 calculation rules in the HTTP/1.1 specification [RFC2616]. When 407 the age is greater than delta-seconds seconds, the client SHOULD 408 discard the cookie. A value of zero means the cookie SHOULD be 409 discarded immediately. 411 SubPath=value OPTIONAL. The value of the SubPath attribute 412 specifies the subset of URLs within the default path on the origin 413 server to which this cookie applies. 415 Port[="portlist"] OPTIONAL. The Port attribute restricts the port 416 to which a cookie may be returned in a Cookie request header 417 field. Note that the syntax REQUIREs quotes around the OPTIONAL 418 portlist even if there is only one portnum in portlist. 420 Unsecure OPTIONAL. The Unsecure attribute (with no value) is only 421 used for cookies sent over secure connections and directs the user 422 agent that the associated cookie can also be sent over an unsecure 423 connection, not just to over (unspecified) secure connections, to 424 the origin server whenever it sends back this cookie. The default 425 for cookies sent over a secure connection is to protect the 426 confidentiality and authenticity of the information in the cookie, 427 so the client MUST NOT send a cookie over an unsecure connection 428 if that cookie was received over a secure connection, but only 429 send it over a connection at least as secure as the one it was 430 received over unless the Unsecure flag was set for that cookie. 432 Version=value REQUIRED. The value of the Version attribute, a 433 decimal integer, identifies the version of the state management 434 specification to which the cookie conforms. For this 435 specification, Version=2 applies. 437 HttpOnly Cookies with this flag set MUST NOT be provided to non-HTTP 438 requestors, such as scripts. Additionally, non-HTTP updates that 439 would overwrite such cookies, or that includes this flag, MUST be 440 refused. 442 3.2.3. Controlling Caching 444 An origin server must be cognizant of the effect of possible caching 445 of both the returned resource and the Set-Cookie2 header field. 446 Caching "public" documents is desirable. For example, if the origin 447 server wants to use a public document such as a "front door" page as 448 a sentinel to indicate the beginning of a session for which a Set- 449 Cookie2 response header field must be generated, the page SHOULD be 450 stored in caches "pre-expired" so that the origin server will see 451 further requests. "Private documents", for example those that 452 contain information strictly private to a session, SHOULD NOT be 453 cached in shared caches. 455 If the cookie is intended for use by a single user, the Set-Cookie2 456 header field SHOULD NOT be cached. A Set-Cookie2 header field that 457 is intended to be shared by multiple users MAY be cached. 459 The origin server SHOULD send the following additional HTTP/1.1 460 response header fields, depending on circumstances: 462 o To suppress caching of the Set-Cookie2 header field: 464 Cache-control: no-cache="set-cookie2" 466 and one of the following: 468 o To suppress caching of a private document in shared caches: 470 Cache-control: private 472 o To allow caching of a document and require that it be validated 473 before returning it to the client: 475 Cache-Control: must-revalidate, max-age=0 477 o To allow caching of a document, but to require that proxy caches 478 (not user agent caches) validate it before returning it to the 479 client: 481 Cache-Control: proxy-revalidate, max-age=0 483 o To allow caching of a document and request that it be validated 484 before returning it to the client (by "pre-expiring" it): 486 Cache-control: max-age=0 487 Not all caches will revalidate the document in every case. 489 HTTP/1.1 servers MUST send Expires: old-date (where old-date is a 490 date long in the past) on responses containing Set-Cookie2 response 491 header fields unless they know for certain (by out of band means) 492 that there are no HTTP/1.0 proxies in the response chain. HTTP/1.1 493 servers MAY send other Cache-Control directives that permit caching 494 by HTTP/1.1 proxies in addition to the Expires: old-date directive; 495 the Cache-Control directive will override the Expires: old-date for 496 HTTP/1.1 proxies. 498 3.3. User Agent Role 500 3.3.1. Interpreting Set-Cookie2 502 The user agent keeps separate track of state information that arrives 503 via Set-Cookie2 response header fields from each origin server (as 504 distinguished by name or IP address and port). The user agent MUST 505 ignore attribute-value pairs whose attribute it does not recognize or 506 that contain invalid data, and if necessary ignore the entire header 507 field. The user agent applies these defaults for optional attributes 508 that are missing: 510 Discard The default behavior is dictated by the presence or absence 511 of a Max-Age attribute. 513 Domain Defaults to the effective request-host. (Note that because 514 there is no dot at the beginning of effective request-host, the 515 default Domain can only domain-match itself.) 517 Max-Age The default behavior is to discard the cookie when the user 518 agent exits. 520 Path Defaults to the path of the request URL that generated the Set- 521 Cookie2 response, up to and including the right-most /. 523 Port The default behavior is that a cookie MAY be returned to any 524 request-port. 526 Unsecure Only for cookies received over a secure connection: If 527 absent, the user agent MUST NOT send the cookie over an unsecure 528 channel. (Cookies received over an unsecure connection can be 529 sent to secure connections) 531 HttpOnly The default behavior is that a cookie can be included in 532 all listings of cookies for a given URL, also those requested by 533 non-HTTP requestors, e.g scripts. 535 The user agent MUST ignore the SubDomain attribute if the effective 536 request-host is an IP-address or IP-literal. 538 If the SubDomain attribute is present the state attribute Domain 539 becomes .H where H is the effective request-host. 541 If the SubPath attribute is present the state attribute Path becomes 542 Px where P is the default path, up to and including the right-most / 543 and x is the value of the attribute. 545 3.3.2. Rejecting Cookies 547 To prevent possible security or privacy violations, a user agent 548 rejects a cookie according to rules below. The goal of the rules is 549 to try to limit the set of servers for which a cookie is valid, based 550 on the values of the Path, Domain, and Port attributes and the 551 request-URI, request-host and request-port. 553 A user agent rejects (SHALL NOT store its information) if the Version 554 attribute is missing, or contains a value of 1 or higher. Moreover, 555 a user agent rejects (SHALL NOT store its information) if any of the 556 following is true of the attributes explicitly present in the Set- 557 Cookie2 response header field: 559 o The value for the SubPath attribute appended to the default path 560 is not a prefix of the request-URI. 562 o The Port attribute has a "port-list", and the request-port was not 563 in the list. 565 o The source of the cookie is non-HTTP, e.g. a script, that either 566 include the HttpOnly attribute, or would overwrite a cookie with 567 the HttpOnly attribute. 569 Examples: 571 o A Set-Cookie2 with Port="80,8000" will be accepted if the request 572 was made to port 80 or 8000 and will be rejected otherwise. 574 o A Set-Cookie2 from a path /example1/example1 for SubPath=exam will 575 be accepted for the path /example1/exam 577 o A Set-Cookie2 from a path /example1/example1 for SubPath=exor will 578 be rejected because exor is not a prefix of example1. 580 3.3.3. Cookie Management 582 If a user agent receives a Set-Cookie2 response header field whose 583 NAME is the same as that of a cookie it has previously stored, the 584 new cookie supersedes the old when: the old and new Domain attribute 585 values compare equal, using a case-insensitive string-compare; and, 586 the old and new Path attribute values string-compare equal (case- 587 sensitive). However, if the Set-Cookie2 has a value for Max-Age of 588 zero, the (old and new) cookie is discarded. Otherwise a cookie 589 persists (resources permitting) until whichever happens first, then 590 gets discarded: its Max-Age lifetime is exceeded; or, if the Discard 591 attribute is set, the user agent terminates the session. 593 Because user agents have finite space in which to store cookies, they 594 MAY also discard older cookies to make space for newer ones, using, 595 for example, a least-recently-used algorithm, along with constraints 596 on the maximum number of cookies that each origin server may set. 598 If a Set-Cookie2 response header field includes a Comment attribute, 599 the user agent SHOULD store that information in a human-readable form 600 with the cookie and SHOULD display the comment text as part of a 601 cookie inspection user interface. 603 If a Set-Cookie2 response header field includes a CommentURL 604 attribute, the user agent SHOULD store that information in a human- 605 readable form with the cookie, or, preferably, SHOULD allow the user 606 to follow the http_URL link as part of a cookie inspection user 607 interface. 609 The cookie inspection user interface may include a facility whereby a 610 user can decide, at the time the user agent receives the Set-Cookie2 611 response header field, whether or not to accept the cookie. A 612 potentially confusing situation could arise if the following sequence 613 occurs: 615 o the user agent receives a cookie that contains a CommentURL 616 attribute; 618 o the user agent's cookie inspection interface is configured so that 619 it presents a dialog to the user before the user agent accepts the 620 cookie; 622 o the dialog allows the user to follow the CommentURL link when the 623 user agent receives the cookie; and, 625 o when the user follows the CommentURL link, the origin server (or 626 another server, via other links in the returned content) returns 627 another cookie. 629 The user agent SHOULD NOT send any cookies in this context. The user 630 agent MAY discard any cookie it receives in this context that the 631 user has not, through some user agent mechanism, deemed acceptable. 633 User agents SHOULD allow the user to control cookie destruction, but 634 they MUST NOT extend the cookie's lifetime beyond that controlled by 635 the Discard and Max-Age attributes. An infrequently-used cookie may 636 function as a "preferences file" for network applications, and a user 637 may wish to keep it even if it is the least-recently-used cookie. 638 One possible implementation would be an interface that allows the 639 permanent storage of a cookie through a checkbox (or, conversely, its 640 immediate destruction). 642 Privacy considerations dictate that the user have considerable 643 control over cookie management. The PRIVACY section contains more 644 information. 646 3.3.4. Sending Cookies to the Origin Server 648 When it sends a request to an origin server, the user agent includes 649 a Cookie request header field if it has stored cookies that are 650 applicable to the request, based on 652 o the request-host and request-port; 654 o the request-URI; 656 o the cookie's age. 658 The syntax for the header field is: 660 cookie = "Cookie:" cookie-version 1*((";" | ",") cookie-value) 661 cookie-value = NAME "=" VALUE ";" cookie-path ";" cookie-domain 662 [";" cookie-port] [";" cookie-origin] 664 cookie-version = "$Version" "=" value 665 NAME = attr 666 VALUE = value 667 cookie-path = "$Path" "=" value 668 cookie-domain = "$Domain" "=" value 669 cookie-port = "$Port" [ "=" <"> port_list <"> ] 670 cookie-origin = "$Origin" "=" [ <"> http_URL <"> ] 672 cookie-version The value of the cookie-version attribute MUST be the 673 value from the Version attribute of the corresponding Set-Cookie2 674 response header field. Otherwise the value for cookie-version is 675 0. 677 name This is the verbatim name from the original Set-Cookie or Set- 678 Cookie2 header field setting the cookie item. 680 cookie-value This is a verbatim copy of the value from the original 681 Set-Cookie or Set-Cookie2 header field setting the cookie item. 682 Quotes MUST be included if they were originally used, and MUST NOT 683 be used if the original value did not contain them. 685 cookie-path The value for the cookie-path attribute MUST be the 686 value from the cookie's Path state attribute, as determined when 687 the corresponding Set-Cookie2 response header field was parsed. 688 If the cookie was set using a previous specification this value 689 MUST be the value of the Path attribute of the corresponding 690 response header field or, if the Path attribute was absent, the 691 default path of the URI used to set the cookie. 693 cookie-domain The value for the cookie-domain attribute MUST be the 694 value from the cookie's Domain state attribute, as determined when 695 the corresponding Set-Cookie2 response header field was parsed. 696 If the response header field used the SubDomain attribute the 697 domain value MUST be prefixed by a ".", if the Domain attribute is 698 a default domain the domain value MUST NOT be prefixed by a ".". 699 If the cookie was set by host supporting a previous version this 700 value MUST be the Domain attribute from the correponding header 701 field, including a preceding "." if the Domain attribute was 702 present; if it was not present the domain value must be the name 703 of the host setting the cookie, without being prefixed with a ".". 705 cookie-port The cookie-port attribute of the Cookie request header 706 field MUST be exactly the value of the Port attribute, if one was 707 present, in the corresponding Set-Cookie2 response header field. 708 That is, the port attribute MUST be present if the Port attribute 709 was present in the Set-Cookie2 header field, and it MUST have the 710 same value (the exact character sequence), if any. Otherwise, if 711 the Port attribute was absent from the Set-Cookie2 header field, 712 the attribute likewise MUST be omitted from the Cookie request 713 header field. 715 cookie-origin The cookie-origin attribute of the Cookie header field 716 MUST be sent for all cookies that were set according to [Netscape] 717 and [RFC2965], and the value MUST be at least the scheme, 718 authority and default path portion (as defined for the cookie path 719 attribute) of the URI that originally set the cookie. If the URI 720 is not known then the URI part of this attribute MUST be empty. 721 This attribute can be used by the server receiving the cookie to 722 determine if it is willing to trust the cookie, based on which 723 server (and path) originally set the cookie. The basic 724 information of this attribute, except the scheme, is implied by 725 the cookie-domain and cookie-path attributes when the cookie is 726 set according to this specification, and the client SHOULD NOT 727 send this attribute with cookies set according to this 728 specification. 730 Note that there is neither a Comment nor a CommentURL attribute in 731 the Cookie request header field corresponding to the ones in the Set- 732 Cookie2 response header field. The user agent does not return the 733 comment information to the origin server. 735 The user agent applies the following rules to choose applicable 736 cookie-values to send in a Cookie request header field from among all 737 the cookies it has received: 739 Domain Selection The origin server's effective host name MUST 740 domain-match the Domain state attribute of the cookie. 742 Port Selection There are three possible behaviors, depending on the 743 Port attribute in the Set-Cookie2 response header field: 745 1. By default (no Port attribute), the cookie MAY be sent to any 746 port. 748 2. If the attribute is present but has no value (e.g., Port), the 749 cookie MUST only be sent to the request-port it was received 750 from. 752 3. If the attribute has a port-list, the cookie MUST only be 753 returned if the new request-port is one of those listed in 754 port-list. 756 Path Selection The request-URI MUST path-match the Path state 757 attribute of the cookie. 759 Max-Age Selection Cookies that have expired should have been 760 discarded and thus are not forwarded to an origin server. 762 HttpOnly Cookies with the HttpOnly attribute MUST NOT be returned to 763 non-HTTP requestors, e.g. Javascript. 765 If multiple cookies satisfy the criteria above, they are ordered in 766 the Cookie header field such that those with more specific Path 767 attributes precede those with less specific. Ordering with respect 768 to other attributes (e.g., Domain) is unspecified. 770 Note: For backward compatibility, the separator in the Cookie header 771 field is semi-colon (;) everywhere. A server SHOULD also accept 772 comma (",") as the separator between cookie-values for future 773 compatibility. 775 A client MAY split a Cookie header field into multiple Cookie header 776 fields, but SHOULD NOT do this unless comma is used as the separator, 777 and the receiving server is expected to handle a multi-header Cookie 778 value. 780 3.3.5. Identifying What Version is Understood: Cookie2 782 The Cookie2 request header field facilitates interoperation between 783 clients and servers that understand different versions of the cookie 784 specification. When the client sends one or more cookies to an 785 origin server, if at least one of those cookies contains a $Version 786 attribute whose value is different from the version that the client 787 understands, then the client MUST also send a Cookie2 request header 788 field, the syntax for which is 790 cookie2 = "Cookie2:" cookie-version 792 Here the value for cookie-version is the highest version of cookie 793 specification (currently 2) that the client understands. The client 794 MUST only send at most one such request header field per request. 796 3.3.6. Sending Cookies in Unverifiable Transactions 798 Users MUST have control over sessions in order to ensure privacy. 799 (See PRIVACY section below.) To simplify implementation and to 800 prevent an additional layer of complexity where adequate safeguards 801 exist, however, this document distinguishes between transactions that 802 are verifiable and those that are unverifiable. A transaction is 803 verifiable if the user, or a user-designated agent, has the option to 804 review the request-URI prior to its use in the transaction. A 805 transaction is unverifiable if the user does not have that option. 806 Unverifiable transactions typically arise when a user agent 807 automatically requests inlined or embedded entities or when it 808 resolves redirection (3xx) responses from an origin server. 809 Typically the origin transaction, the transaction that the user 810 initiates, is verifiable, and that transaction may directly or 811 indirectly induce the user agent to make unverifiable transactions. 813 An unverifiable transaction is to a third-party host if its request- 814 host U does not domain-match the reach R of the request-host O in the 815 origin transaction. 817 When it makes an unverifiable transaction, a user agent MUST disable 818 all cookie processing (i.e., MUST NOT send cookies, and MUST NOT 819 accept any received cookies) if the transaction is to a third-party 820 host. 822 This restriction prevents a malicious service author from using 823 unverifiable transactions to induce a user agent to start or continue 824 a session with a server in a different domain. The starting or 825 continuation of such sessions could be contrary to the privacy 826 expectations of the user, and could also be a security problem. 828 User agents MAY offer configurable options that allow the user agent, 829 or any autonomous programs that the user agent executes, to ignore 830 the above rule, so long as these override options default to "off". 832 (NOTE: Mechanisms may be proposed that will automate overriding the 833 third-party restrictions under controlled conditions.) 835 Many current user agents already provide a review option that would 836 render many links verifiable. For instance, some user agents display 837 the URL that would be referenced for a particular link when the mouse 838 pointer is placed over that link. The user can therefore determine 839 whether to visit that site before causing the browser to do so. 840 (Though not implemented on current user agents, a similar technique 841 could be used for a button used to submit a form -- the user agent 842 could display the action to be taken if the user were to select that 843 button.) However, even this would not make all links verifiable; for 844 example, links to automatically loaded images would not normally be 845 subject to "mouse pointer" verification. 847 Many user agents also provide the option for a user to view the HTML 848 source of a document, or to save the source to an external file where 849 it can be viewed by another application. While such an option does 850 provide a crude review mechanism, some users might not consider it 851 acceptable for this purpose. 853 3.4. How an Origin Server Interprets the Cookie Header 855 A user agent returns much of the information in the Set-Cookie2 856 header field to the origin server when the request-URI path-matches 857 the Path attribute of the cookie. When it receives a Cookie header 858 field, the origin server SHOULD treat cookies with NAMEs whose prefix 859 is $ specially, as an attribute for the cookie. 861 3.5. Caching Proxy Role 863 One reason for separating state information from both a URL and 864 document content is to facilitate the scaling that caching permits. 865 To support cookies, a caching proxy MUST obey these rules already in 866 the HTTP specification: 868 o Honor requests from the cache, if possible, based on cache 869 validity rules. 871 o Pass along a Cookie request header field in any request that the 872 proxy must make of another server. 874 o Return the response to the client. Include any Set-Cookie2 875 response header field. 877 o Cache the received response subject to the control of the usual 878 header fields, such as Expires, 880 Cache-control: no-cache 881 and 883 Cache-control: private 885 o Cache the Set-Cookie2 subject to the control of the usual header 886 field, 888 Cache-control: no-cache="set-cookie2" 889 (The Set-Cookie2 header field should usually not be cached.) 891 Proxies MUST NOT introduce Set-Cookie2 (Cookie) header fields of 892 their own in proxy responses (requests). 894 4. Examples 896 4.1. Example 1 898 Most detail of request and response header fields has been omitted. 899 Assume the user agent has no stored cookies, and that the hostname is 900 www.example.com 902 1. User Agent -> Server 904 POST /acme/login HTTP/1.1 905 [form data] 907 User identifies self via a form. 909 2. Server -> User Agent 911 HTTP/1.1 200 OK 912 Set-Cookie2: Customer="WILE_E_COYOTE"; Version="2"; 914 Cookie reflects user's identity. 916 3. User Agent -> Server 918 POST /acme/pickitem HTTP/1.1 919 Cookie: $Version="2"; Customer="WILE_E_COYOTE"; 920 $Domain="www.example.com"; $Path="/acme/" 921 [form data] 923 User selects an item for "shopping basket". 925 4. Server -> User Agent 927 HTTP/1.1 200 OK 928 Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="2" 930 Shopping basket contains an item. 932 5. User Agent -> Server 934 POST /acme/shipping HTTP/1.1 935 Cookie: $Version="2"; 936 Customer="WILE_E_COYOTE"; 937 $Domain="www.example.com"; $Path="/acme/"; 938 Part_Number="Rocket_Launcher_0001"; 939 $Domain="www.example.com"; $Path="/acme/" 940 [form data] 942 User selects shipping method from form. 944 6. Server -> User Agent 946 HTTP/1.1 200 OK 947 Set-Cookie2: Shipping="FedEx"; Version="2" 949 New cookie reflects shipping method. 951 7. User Agent -> Server 953 POST /acme/process HTTP/1.1 954 Cookie: $Version="2"; 955 Customer="WILE_E_COYOTE"; 956 $Domain="www.example.com"; $Path="/acme/"; 957 Part_Number="Rocket_Launcher_0001"; 958 $Domain="www.example.com"; $Path="/acme/"; 959 Shipping="FedEx"; 960 $Domain="www.example.com"; $Path="/acme/" 961 [form data] 963 User chooses to process order. 965 8. Server -> User Agent 967 HTTP/1.1 200 OK 969 Transaction is complete. 971 The user agent makes a series of requests on the origin server, after 972 each of which it receives a new cookie. All the cookies have the 973 same Path attribute and (default) domain. Because the request-URIs 974 all path-match /acme/, the Path attribute of each cookie, each 975 request contains all the cookies received so far. 977 4.2. Example 2 979 This example illustrates the effect of the Path attribute. All 980 detail of request and response header fields has been omitted. 981 Assume the user agent has no stored cookies. 983 Imagine the user agent has received, in response to earlier requests, 984 the response header fields 986 Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="2" 988 and 990 Set-Cookie2: Part_Number="Riding_Rocket_0023"; Version="2"; 991 SubPath="ammo" 993 A subsequent request by the user agent to the (same) server for URLs 994 of the form /acme/ammo/... would include the following request header 995 field: 997 Cookie: $Version="2"; 998 Part_Number="Riding_Rocket_0023"; 999 $Domain="www.example.com"; $Path="/acme/ammo"; 1000 Part_Number="Rocket_Launcher_0001"; 1001 $Domain="www.example.com"; $Path="/acme/" 1003 Note that the NAME=VALUE pair for the cookie with the more specific 1004 Path attribute, /acme/ammo, comes before the one with the less 1005 specific Path attribute, /acme. Further note that the same cookie 1006 name appears more than once. 1008 A subsequent request by the user agent to the (same) server for a URL 1009 of the form /acme/parts/ would include the following request header 1010 field: 1012 Cookie: $Version="2"; Part_Number="Rocket_Launcher_0001"; 1013 $Domain="www.example.com"; $Path="/acme" 1015 Here, the second cookie's Path attribute /acme/ammo is not a prefix 1016 of the request URL, /acme/parts/, so the cookie does not get 1017 forwarded to the server. 1019 5. Implementation Considerations 1021 Here we provide guidance on likely or desirable details for an origin 1022 server that implements state management. 1024 5.1. Set-Cookie2 Content 1026 An origin server's content should probably be divided into disjoint 1027 application areas, some of which require the use of state 1028 information. The application areas can be distinguished by their 1029 request URLs. The Set-Cookie2 header field can incorporate 1030 information about the application areas by setting the Path attribute 1031 for each one. 1033 The session information can obviously be clear or encoded text that 1034 describes state. However, if it grows too large, it can become 1035 unwieldy. Therefore, an implementor might choose for the session 1036 information to be a key to a server-side resource. Of course, using 1037 a database creates some problems that this state management 1038 specification was meant to avoid, namely: 1040 1. keeping real state on the server side; 1042 2. how and when to garbage-collect the database entry, in case the 1043 user agent terminates the session by, for example, exiting. 1045 5.2. Stateless Pages 1047 Caching benefits the scalability of WWW. Therefore it is important 1048 to reduce the number of documents that have state embedded in them 1049 inherently. For example, if a shopping-basket-style application 1050 always displays a user's current basket contents on each page, those 1051 pages cannot be cached, because each user's basket's contents would 1052 be different. On the other hand, if each page contains just a link 1053 that allows the user to "Look at My Shopping Basket", the page can be 1054 cached. 1056 5.3. Implementation Limits 1058 Practical user agent implementations have limits on the number and 1059 size of cookies that they can store. In general, user agents' cookie 1060 support should have no fixed limits. They should strive to store as 1061 many frequently-used cookies as possible. Furthermore, general-use 1062 user agents SHOULD provide each of the following minimum capabilities 1063 individually, although not necessarily simultaneously: 1065 o at least 300 cookies 1067 o at least 4096 bytes per cookie (as measured by the characters that 1068 comprise the cookie non-terminal in the syntax description of the 1069 Set-Cookie2 header field, and as received in the Set-Cookie2 1070 header field) 1072 o at least 20 cookies per unique host or domain name 1074 User agents created for specific purposes or for limited-capacity 1075 devices SHOULD provide at least 20 cookies of 4096 bytes, to ensure 1076 that the user can interact with a session-based origin server. 1078 The information in a Set-Cookie2 response header field MUST be 1079 retained in its entirety. If for some reason there is inadequate 1080 space to store the cookie, it MUST be discarded, not truncated. 1082 Applications should use as few and as small cookies as possible, and 1083 they should cope gracefully with the loss of a cookie. 1085 5.3.1. Denial of Service Attacks 1087 User agents MAY choose to set an upper bound on the number of cookies 1088 to be stored from a given host or domain name or on the size of the 1089 cookie information. Otherwise a malicious server could attempt to 1090 flood a user agent with many cookies, or large cookies, on successive 1091 responses, which would force out cookies the user agent had received 1092 from other servers. However, the minima specified above SHOULD still 1093 be supported. 1095 5.4. Backwards Compatibility 1097 Servers that send cookies according to this specification and that 1098 wish to send cookies with the same properties to a client following 1099 the RFC2965 specification MAY send Domain and Path attributes in the 1100 same header field as the version 2 arguments. Clients following this 1101 specification MUST ignore these attributes. 1103 6. Privacy 1105 Informed consent should guide the design of systems that use cookies. 1106 A user should be able to find out how a web site plans to use 1107 information in a cookie and should be able to choose whether or not 1108 those policies are acceptable. Both the user agent and the origin 1109 server must assist informed consent. 1111 6.1. User Agent Control 1113 An origin server could create a Set-Cookie2 header field to track the 1114 path of a user through the server. Users may object to this behavior 1115 as an intrusive accumulation of information, even if their identity 1116 is not evident. (Identity might become evident, for example, if a 1117 user subsequently fills out a form that contains identifying 1118 information.) This state management specification therefore requires 1119 that a user agent give the user control over such a possible 1120 intrusion, although the interface through which the user is given 1121 this control is left unspecified. However, the control mechanisms 1122 provided SHALL at least allow the user 1124 o to completely disable the sending and saving of cookies. 1126 o to determine whether a stateful session is in progress. 1128 o to control the saving of a cookie on the basis of the cookie's 1129 Domain attribute. 1131 Such control could be provided, for example, by mechanisms 1133 o to notify the user when the user agent is about to send a cookie 1134 to the origin server, to offer the option not to begin a session. 1136 o to display a visual indication that a stateful session is in 1137 progress. 1139 o to let the user decide which cookies, if any, should be saved when 1140 the user concludes a window or user agent session. 1142 o to let the user examine and delete the contents of a cookie at any 1143 time. 1145 A user agent usually begins execution with no remembered state 1146 information. It SHOULD be possible to configure a user agent never 1147 to send a Cookie header field to an origin server, in which case it 1148 can never sustain state with an origin server. (The user agent would 1149 then behave like one that is unaware of how to handle Set-Cookie2 1150 response header fields.) 1152 When the user agent terminates execution, it SHOULD let the user 1153 discard all state information. Alternatively, the user agent MAY ask 1154 the user whether state information should be retained; the default 1155 should be "no". If the user chooses to retain state information, it 1156 would be restored the next time the user agent runs. 1158 NOTE: User agents should probably be cautious about using files to 1159 store cookies long-term. If a user runs more than one instance of 1160 the user agent, the cookies could be commingled or otherwise 1161 corrupted. 1163 6.2. Origin Server Role 1165 An origin server SHOULD promote informed consent by adding CommentURL 1166 or Comment information to the cookies it sends. CommentURL is 1167 preferred because of the opportunity to provide richer information in 1168 a multiplicity of languages. 1170 6.3. Clear Text 1172 The information transmitted in the Set-Cookie2 and Cookie header 1173 fields is unprotected. As a consequence: 1175 1. Any sensitive information that is conveyed in them is exposed to 1176 intruders. 1178 2. A malicious intermediary could alter the header fields as they 1179 travel in either direction, with unpredictable results. 1181 These facts imply that information of a personal and/or financial 1182 nature should only be sent over a secure channel. For less sensitive 1183 information, or when the content of the header field is a database 1184 key, an origin server should be vigilant to prevent a bad Cookie 1185 value from causing failures. 1187 A user agent in a shared user environment poses a further risk. 1188 Using a cookie inspection interface, User B could examine the 1189 contents of cookies that were saved when User A used the machine. 1191 7. IANA Considerations 1193 This document makes no request of IANA. 1195 Note to RFC Editor: this section may be removed on publication as an 1196 RFC. 1198 8. Security Considerations 1200 8.1. Protocol Design 1202 The restrictions on the value of the Domain state attribute by using 1203 the SubDomain attribute, and the rules concerning unverifiable 1204 transactions, are meant to reduce the ways that cookies can "leak" to 1205 the "wrong" site. The intent is to restrict cookies to one host, or 1206 a closely related set of hosts. We consider it acceptable for hosts 1207 host1.foo.com and host2.foo.com to share cookies, but not a.com and 1208 b.com. Because of the many hierarchies used to organize domain 1209 names, it is not possible to define a small set of rules that can 1210 tell the client if a domain name is in fact similar to .com, or not. 1211 For that reason, this specification introduces the "Subdomain" 1212 attribute as a replacement of the "Domain" attribute defined by 1214 [RFC2965], so that only hosts in the domain below the server 1215 top.example.com can receive the cookie. 1217 Similarly, a server can only share cookies with resource in 1218 subfolders of the default path derived from the request-URI. 1220 8.2. Cookie Spoofing 1222 Proper application design can avoid spoofing attacks from related 1223 domains. Consider: 1225 1. User agent makes request to victim.cracker.edu, gets back cookie 1226 session_id="1234" and sets the default domain victim.cracker.edu. 1228 2. User agent makes request to cracker.edu, gets back cookie 1229 session-id="1111", with a SubDomain attribute. 1231 3. User agent makes request to victim.cracker.edu again, and passes 1233 Cookie: $Version="1"; session_id="1234"; 1234 $Domain="victim.cracker.edu"; $Path="/example/" , 1235 $Version="1"; session_id="1111"; 1236 $Domain=".cracker.edu"; $Path="/" 1237 The server at victim.cracker.edu should detect that the second 1238 cookie was not one it originated by noticing that the Domain 1239 attribute is not for itself and ignore it. 1241 8.3. Unexpected Cookie Sharing 1243 A user agent SHOULD make every attempt to prevent the sharing of 1244 session information between hosts that are in different domains. 1245 Embedded or inlined objects may cause particularly severe privacy 1246 problems if they can be used to share cookies between disparate 1247 hosts. For example, a malicious server could embed cookie 1248 information for host a.com in a URI for a CGI on host b.com. User 1249 agent implementors are strongly encouraged to prevent this sort of 1250 exchange whenever possible. 1252 8.4. Cookies for Account Information 1254 While it is common practice to use them this way, cookies are not 1255 designed or intended to be used to hold authentication information, 1256 such as account names and passwords. Unless such cookies are 1257 exchanged over an encrypted path, the account information they 1258 contain is highly vulnerable to perusal and theft. 1260 9. Historical 1262 9.1. Compatibility with Existing Implementations 1264 Existing cookie implementations, based on the Netscape specification, 1265 use the Set-Cookie (not Set-Cookie2) header field. User agents that 1266 receive in the same response both a Set-Cookie and a Set-Cookie2 1267 response header field for the same cookie MUST discard the Set-Cookie 1268 information and use only the Set-Cookie2 information. Furthermore, a 1269 user agent MUST assume, if it received a Set-Cookie2 response header 1270 field, that the sending server complies with this document and will 1271 understand Cookie request header fields that also follow this 1272 specification. 1274 New cookies MUST replace both equivalent old- and new-style cookies. 1275 That is, if a user agent that follows both this specification and 1276 Netscape's original specification receives a Set-Cookie2 response 1277 header field, and the NAME and the Domain and Path state attributes 1278 match (per the Cookie Management section) a Netscape-style cookie, 1279 the Netscape-style cookie MUST be discarded, and the user agent MUST 1280 retain only the cookie adhering to this specification. 1282 Older user agents that do not understand this specification, but that 1283 do understand Netscape's original specification, will not recognize 1284 the Set-Cookie2 response header field and will receive and send 1285 cookies according to the older specification. 1287 A user agent that supports both this specification and Netscape-style 1288 cookies SHOULD still send a Cookie request header field that follows 1289 the format specified in this document, as the benefit of adding 1290 domain and path information to each cookie and thus providing even 1291 older server with the ability to detect incorrectly set cookies 1292 outweigh the potential problems unknown cookienames may cause. 1294 The client should also send this header field in requests to servers 1295 that receive cookies that are not of the version specified by this 1296 document 1298 Cookie2: $Version="2" 1300 The Cookie2 header field advises the server that the user agent 1301 understands new-style cookies. If the server understands new-style 1302 cookies, as well, it SHOULD continue the stateful session by sending 1303 a Set-Cookie2 response header field, rather than Set-Cookie. A 1304 server that does not understand new-style cookies will simply ignore 1305 the Cookie2 request header field. 1307 9.2. Caching and HTTP/1.0 1309 Some caches, such as those conforming to HTTP/1.0, will inevitably 1310 cache the Set-Cookie2 and Set-Cookie header fields, because there was 1311 no mechanism to suppress caching of headers prior to HTTP/1.1. This 1312 caching can lead to security problems. Documents transmitted by an 1313 origin server along with Set-Cookie2 and Set-Cookie header fields 1314 usually either will be uncachable, or will be "pre-expired". As long 1315 as caches obey instructions not to cache documents (following 1316 Expires: or Pragma: no-cache (HTTP/1.0), or 1317 Cache-control: no-cache (HTTP/1.1)) uncachable documents present no 1318 problem. However, pre-expired documents may be stored in caches. 1319 They require validation (a conditional GET) on each new request, but 1320 some cache operators loosen the rules for their caches, and sometimes 1321 serve expired documents without first validating them. This 1322 combination of factors can lead to cookies meant for one user later 1323 being sent to another user. The Set-Cookie2 and Set-Cookie header 1324 fields are stored in the cache, and, although the document is stale 1325 (expired), the cache returns the document in response to later 1326 requests, including cached header fields. 1328 10. Acknowledgements 1330 This document is based on [RFC2965] by David Kristol and Lou Montulli 1331 and the collective efforts of the HTTP Working Group of the IETF and, 1332 particularly, the following people, in addition to the authors of RFC 1333 2965: Roy Fielding, Yaron Goland, Marc Hedlund, Ted Hardie, Koen 1334 Holtman, Shel Kaphan, Rohit Khare, Foteos Macrides, David W. Morris. 1336 This document include some changes suggested by RFC 2965 errata 1337 drafts posted by Arne Thomassen [ERRATA1] and David Kristol 1338 [ERRATA2]. 1340 11. References 1342 11.1. Normative References 1344 [I-D.ietf-httpstate-cookie] 1345 Barth, A., "HTTP State Management Mechanism", 1346 draft-ietf-httpstate-cookie-23 (work in progress), 1347 March 2011. 1349 [Netscape] 1350 "Persistent Client State -- HTTP Cookies", 1351 . 1353 available at 1354 1356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1357 Requirement Levels", BCP 14, RFC 2119, March 1997. 1359 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1360 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1361 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1363 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1365 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 1366 Mechanism", RFC 2965, October 2000. 1368 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1369 10646", STD 63, RFC 3629, November 2003. 1371 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1372 Resource Identifier (URI): Generic Syntax", STD 66, 1373 RFC 3986, January 2005. 1375 11.2. Non-normative References 1377 [ERRATA1] "RFC Errata: HTTP State Management Mechanism (draft)", 1378 October 2000, 1379 . 1382 [ERRATA2] "[Draft of] Errata to RFC 2965", May 2003, 1383 . 1385 Appendix A. Open issues 1387 o Should cookies with cookie-values with unquoted whitespace be 1388 rejected? 1390 Author's Address 1392 Yngve N Pettersen 1393 Opera Software ASA 1394 Waldemar Thranes gate 98 1395 N-0175 OSLO, 1396 Norway 1398 Email: yngve@opera.com