idnits 2.17.1 draft-pettersen-cookie-origin-02.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 ([I-D.ietf-httpstate-cookie], [RFC2965], [NETSC], [RFC2109]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2109, updated by this document, for RFC5378 checks: 1997-02-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4792 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'NETSC' ** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 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 Updates: 2109,2965 March 14, 2011 5 (if approved) 6 Intended status: Standards Track 7 Expires: September 15, 2011 9 Identifying origin server of HTTP Cookies 10 draft-pettersen-cookie-origin-02 12 Abstract 14 HTTP Cookies, as originally defined by Netscape in [NETSC] and as 15 later updated by [RFC2109] , [RFC2965], and 16 [I-D.ietf-httpstate-cookie] did not address the issue of how to 17 restrict for which domains a server is allowed to set a cookie. This 18 is particularly a problem for servers hosted in top-level domains 19 having subdomains that are controlled by registries and not by domain 20 owners, e.g., "co.uk" and "city.state.us" domains. In such 21 situations, unless the client uses some kind of domain black-list, it 22 is possible for a malicious server to set cookies, so they are sent 23 to all servers in a domain the attacker does not control. These 24 cookies may adveresly affect the function of servers receiving them. 25 The primary reason this is a problem is that the server receiving the 26 cookie has no way of telling which server originally set it; 27 therefore it is not able to distinguish reliably an invalid cookie 28 from a valid one. 30 This document proposes a new attribute, "$Origin", that is associated 31 with each cookie and sent in all client cookie headers in the 32 requests sent to the server. Servers recognizing the attribute may 33 then check to see if the cookie was set by a server, which is allowed 34 to set cookies for the server and, if necessary, ignore the cookie. 36 This document updates RFC 2109 and RFC 2965. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of this Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on September 15, 2011. 61 Copyright Notice 63 Copyright (c) 2011 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. The $Origin attribute . . . . . . . . . . . . . . . . . . . . . 4 80 2.1. General syntax . . . . . . . . . . . . . . . . . . . . . . 4 81 2.2. Updated client processing of received cookies . . . . . . . 5 82 2.3. Updated Cookie header syntax . . . . . . . . . . . . . . . 5 83 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 86 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 89 1. Introduction 91 When originally defined, Netscape's HTTP Cookie specification 92 [NETSC], updated by [I-D.ietf-httpstate-cookie] did not extensively 93 specify how clients should check the domain of cookies. Although 94 [RFC2109] and [RFC2965] did put restrictions on the domains for which 95 a server setting cookies could set cookies, these policies have not 96 been widely implemented and are also not able to protect against all 97 possible abuses. 99 Clients have attempted to limit this problem by using heuristics and 100 domain blacklists to determine for which domains they can set 101 cookies. However, these workarounds have limits both in terms of 102 correctness, and the amount of data needed to implement them, as well 103 as in the timeliness of updates to the list. 105 Alternatively, servers have no way to determine whether a cookie it 106 receives from a client is one of the cookies it sent to the client, 107 or, if it came from another server, which server originally set it. 108 The server may include information in the cookie's value to determine 109 correctness. However, this does not guard against a malicious server 110 using a correctly generated cookie that was originally sent to a 111 different client. 113 A way to allow servers to learn whether received cookies are valid 114 and not set by an unauthorized server is to include the name or URL 115 of the server that originally set the cookie in an attribute, 116 "$Origin", associated with each cookie value in the Cookie header 117 sent to the server. This attribute would either identify the name of 118 the server that set the cookie, or if the name of this server is not 119 known, the domain for which the cookie has been set. This allows the 120 receiving server to remove or ignore cookies set by servers not 121 allowed to set cookies for its domain and also to log the information 122 about the incorrectly set cookies. 124 2. The $Origin attribute 126 2.1. General syntax 128 This specification uses the same syntax as is used by [RFC2109] , 129 [RFC2965] , and [RFC2616] 130 attr = token 131 value = token | quoted-string 133 2.2. Updated client processing of received cookies 135 When a client receives a Set-Cookie or Set-Cookie2 header, it will 136 process the header as specified by the appropriate specification, 137 which can be either [NETSC] , [I-D.ietf-httpstate-cookie], [RFC2109], 138 or [RFC2965] . When storing the cookie, it MUST also register 139 information about the host setting the cookie. This information MUST 140 include the hostname and SHOULD include parts of the, or the entire, 141 URI that set the cookie, including the scheme. 143 2.3. Updated Cookie header syntax 145 This specification updates the Cookie header as sent by the client by 146 associating each cookie value with a $Origin attribute that specifies 147 where the the cookie came from. 149 This specification does not change the way cookies are selected for 150 inclusion in the Cookie header. 152 The syntax for the header field is: 154 cookie = "Cookie:" cookie-value 0*(";" cookie-value) 155 cookie-value = NAME "=" VALUE ";" cookie-origin 157 NAME = attr 158 VALUE = value 159 cookie-origin = "$Origin" "=" <"> http_URL <"> 161 NAME and VALUE have the same meaning as 162 in[I-D.ietf-httpstate-cookie], [RFC2109] and [RFC2965]. 164 The http_URL value of the $Origin attribute MUST be the URI of the 165 resource setting the cookie, which SHOULD be restricted to the 166 default path (remove the query part and the last path segment). If 167 the client does not know the URI that originally set the cookie,such 168 as when the cookie was received by a version of the client that does 169 not support $Origin, it MUST instead send a generated default URL 170 "http:// "+domainname+"/", where domainname is the name of the domain 171 for which the cookie is set. This domain name MUST be preceded by a 172 single period (".") to differentiate the domain name from a hostname. 174 The http_URL value MUST be encoded as described in [RFC3986] . 176 When receiving a cookie header containing $Origin, servers 177 recognizing it SHOULD check if the identified host or domain from the 178 URI in the argument is acceptable to the server. If the cookie is 179 not from an acceptable host or domain, the cookie can be ignored and 180 optionally reported to the server administrator. The server SHOULD 181 also ignore all cookies that are not followed by a $Origin attribute, 182 if one cookie in the header has a $Origin attribute. 184 [[Open issue: An option for cases with unknown origin is to send an 185 empty $Origin attribute or no $Origin attribute for that cookie. An 186 argument against having a special dot prefix is that these cookies 187 will only exist for a limited time after a client has been updated to 188 set and send $Origin. The author thinks it is better to provide some 189 information to the server about the domain of the cookie, rather than 190 to provide no information. Either case would require special 191 handling in the server.]] 193 [[Open issue: An alternative requirement for the URI is to include 194 all of the original URI, except the query portion.]] 196 [[Open issue: Mention HTTPS URLs? What about including HTTPS URLs in 197 requests to unencrypted HTTP resources? Change to HTTP URL? 199 3. Examples 201 http://www.example.com/path1/resource?query sets the cookie: 203 Set-Cookie: foo=value1; domain=.example.com; path=/ 205 http://www2.example.com/path2/resource2?query1 sets the cookie: 207 Set-Cookie: bar=value2; domain=.example.com; path=/ 209 An unkown server set the cookie: 211 Set-Cookie: xyz=value3; domain=.example.com; path=/ 213 The resulting Cookie header is: 215 Cookie: foo=value1; $Origin="http://www.example.com/path1/"; 216 bar=value2; $Origin="http://www2.example.com/path2/"; 217 xyz=value3; $Origin="http://.example.com/" 219 4. IANA Considerations 221 This document makes no request of IANA. 223 Note to the RFC Editor: this section may be removed upon publication 224 as a RFC. 226 5. Security Considerations 228 This specification is intended to make the sharing of cookies across 229 domains detectable, whether the sharing is intentional, 230 unintentional, or with malicious intent. It can, therefore, also be 231 used to limit the potential for cookie spoofing, as discussed in the 232 security considerations of [RFC2109] and [RFC2965] . It is, however, 233 still possible for servers within a permitted group of servers to set 234 incorrect or malicioius cookies, which might adversely affect other 235 servers in the domain. 237 6. Normative References 239 [I-D.ietf-httpstate-cookie] 240 Barth, A., "HTTP State Management Mechanism", 241 draft-ietf-httpstate-cookie-23 (work in progress), 242 March 2011. 244 [NETSC] "Persistent Client State -- HTTP Cookies", 245 . 247 available at 248 250 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 251 Mechanism", RFC 2109, February 1997. 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 257 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 258 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 260 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 261 Mechanism", RFC 2965, October 2000. 263 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 264 Resource Identifier (URI): Generic Syntax", STD 66, 265 RFC 3986, January 2005. 267 Author's Address 269 Yngve N. Pettersen 270 Opera Software ASA 271 Waldemar Thranes gate 98 272 N-0175 OSLO, 273 Norway 275 Email: yngve@opera.com