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