idnits 2.17.1 draft-west-origin-cookies-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2014) is 3471 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis M. West 3 Internet-Draft Google, Inc 4 Updates: 6265 (if approved) October 22, 2014 5 Intended status: Standards Track 6 Expires: April 25, 2015 8 Origin Cookies 9 draft-west-origin-cookies-00 11 Abstract 13 This document updates RFC6265, defining the "origin" attribute for 14 cookies and the "Origin-Cookie" header field, which together allow 15 servers to choose to harmonize the security policy of their cookies 16 with the same-origin policy which governs other available client-side 17 storage mechanisms. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 25, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology and notation . . . . . . . . . . . . . . . . . . 3 56 3. User Agent Requirements . . . . . . . . . . . . . . . . . . . 4 57 3.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. The "Origin" attribute . . . . . . . . . . . . . . . . . 4 59 3.3. Monkey-patching the Storage Model . . . . . . . . . . . . 4 60 3.4. Monkey-patching the "Cookie" header . . . . . . . . . . . 5 61 3.5. The "Origin-Cookie" header field . . . . . . . . . . . . 6 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 4.1. "HttpOnly" . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2. Paths are ignored . . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Origin-Cookie . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 7.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Cookies, as defined by [RFC6265], diverge from the web's general 77 security policy in a number of ways which may be surprising to 78 implementers and authors who haven't carefully read that document's 79 discussion of "domain matching", and "path matching", or who ignored 80 the admonitions regarding "Weak Confidentiality" and "Weak 81 Integrity". 83 This document updates [RFC6265], describing a mechanism by which 84 servers can opt-in to harmonizing cookies' security policy with the 85 same-origin policy, as described in [RFC6454]. User agents that 86 support these "origin cookies" will ignore a "Set-Cookie" header's 87 value's "Path", "Domain", and "Secure" attributes if an "Origin" 88 attribute is present, instead tying the cookie to the origin that set 89 it. These "origin cookies" will be returned in a new "Origin-Cookie" 90 header field (see Section 3.5 for detail), separating them from non- 91 origin cookies in a way a server can easily distinguish. 93 Harmonizing with the same-origin policy mitigates the confidentiality 94 and integrity risks noted above by ensuring that origin cookies are 95 not influenced by malicious code running on a server's subdomain or a 96 non-standard port or scheme. 98 Note that the mechanism outlined here is backwards compatible with 99 the existing cookie syntax. Servers may serve origin cookies to all 100 user agents; those that do not support the "Origin" attribute will 101 simply store a non-origin cookie, just as they do today. 103 1.1. Examples 105 Origin cookies are set via the "Origin" attribute in the "Set-Cookie" 106 header field. That is, given a server's response to a user agent 107 which contains the following header field: 109 Set-Cookie: SID=31d4d96e407aad42; Origin 111 Subsequent requests from that user agent can be expected to contain 112 the following header field: 114 Origin-Cookie: SID=31d4d96e407aad42 116 Non-origin cookies are returned in the "Cookie" header field as 117 usual. If both non-origin and origin cookies are present for an 118 origin, then both a "Cookie" and "Origin-Cookie" header field will be 119 present. That is, given a server's response to a user agent which 120 contains the following header fields: 122 Set-Cookie: SID=31d4d96e407aad42; Origin 123 Set-Cookie: lang=en-US; Path=/; Domain=example.com 125 Subsequent requests from that user agent can be expected to contain 126 the following header fields: 128 Cookie: lang=en-US 129 Origin-Cookie: SID=31d4d96e407aad42 131 2. Terminology and notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 This specification uses the Augmented Backus-Naur Form (ABNF) 138 notation of [RFC5234]. 140 Two sequences of octets are said to case-insensitively match each 141 other if and only if they are equivalent under the "i;ascii-casemap" 142 collation defined in [RFC4790]. 144 3. User Agent Requirements 146 This section describes extensions to [RFC6265] necessary in order to 147 implement the client-side requirements of the "Origin" attribute and 148 "Origin-Cookie" header field. 150 3.1. Grammar 152 Replace the "cookie-av" token definition in [RFC6265] with the 153 following ABNF grammar: 155 cookie-av = expires-av / max-age-av / domain-av / 156 path-av / secure-av / httponly-av / 157 origin-av / extension-av 158 origin-av = "Origin" 160 3.2. The "Origin" attribute 162 The following attribute definition should be considered part of the 163 the "Set-Cookie" algorithm as described in Section 5.2 of [RFC6265]: 165 If the attribute-name case-insensitively matches the string "Origin", 166 the user agent MUST append an attribute to the cookie-attribute-list 167 with an attribute-name of "Origin" and an empty attribute-value. 169 3.3. Monkey-patching the Storage Model 171 Note: There's got to be a better way to specify this. Until I figure 172 out what that is, monkey-patching! 174 Alter Section 5.3 of [RFC6265] as follows: 176 1. Add "origin" and "origin-flag" to the list of fields stored about 177 each cookie. 179 2. Before step 11 of the current algorithm, add the following: 181 1. If the "cookie-attribute-list" contains an attribute with an 182 "attribute-name" of "Origin": 184 1. Set the cookie's "domain" attribute to the empty string. 186 2. Set the cookie's "http-only-flag" to true. 188 3. Set the cookie's "host-only-flag" to true. 190 4. Set the cookie's "origin" to the origin of "request-uri", 191 as defined by Section 4 of [RFC6454]. 193 5. Set the cookie's "origin-flag" to true. 195 6. Set the cookie's "path" attribute to the empty string. 197 7. Set the cookie's "secure-only-flag" to false. 199 Otherwise: set the cookie's "origin-flag" to false, and its 200 "origin" to "null". 202 2. If the newly created cookie's "origin-flag" is set to true, 203 and the cookie store contains a cookie with the same"name", 204 "origin", and "origin-flag" as the newly created cookie: 206 1. Let "old-cookie" be the existing cookie with the same 207 "name", "origin", and "origin-flag" as the newly created 208 cookie. 210 2. Update the "creation-time" of the newly created cookie to 211 match the "creation-time" of "old-cookie". 213 3. Remove "old-cookie" from the cookie store. 215 3. Change the priority order for excess cookie removal to the 216 following: 218 1. Expired cookies. 220 2. Cookies whose "origin-flag" is false that share a "domain" 221 field with more than a predetermined number of other cookies. 223 3. Cookies whose "origin-flag" is true that share a "domain" 224 field with more than a predetermined number of other cookies. 226 4. Cookies whose "origin-flag" is false. 228 5. All cookies. 230 3.4. Monkey-patching the "Cookie" header 232 Note: There's got to be a better way to specify this. Until I figure 233 out what that is, monkey-patching! 235 Alter Section 5.4 of [RFC6265] as follows: 237 1. Add the following requirement to the list in step 1: 239 * The cookie's "origin-flag" is false. 241 3.5. The "Origin-Cookie" header field 243 The user agent includes stored cookies whose "origin-flag" is set in 244 the "Origin-Cookie" request header. When the user agent generates an 245 HTTP request, it MUST NOT attach more than one "Origin-Cookie" header 246 field. 248 A user agent MAY omit the "Origin-Cookie" header in its entirety. 249 For example, the user agent may wish to block sending cookies during 250 "third-party" requests. 252 If the user agent does attach an "Origin-Cookie" header field to an 253 HTTP request, the user agent MUST send the "cookie-string" as defined 254 below as the value of the header field. 256 The user agent MUST use an algorithm equivalent to the following 257 algorithm to compute the "cookie-string" from a cookie store and a 258 "request-uri": 260 1. Let "cookie-list" be the set of cookies from the cookie store 261 that meets all the following requirements: 263 * The cookie's "origin-flag" is true. 265 * The cookie's "origin" matches the origin of "request-uri". 266 [RFC6454] 268 * The "cookie-string" is not being generated for a "non-HTTP" 269 API (as defined by the user agent). 271 2. The user agent SHOULD sort the "cookie-list" in the following 272 order: 274 * Cookies with earlier "creation-time"s are listed before 275 cookies with later "creation-time"s. 277 3. Update the "last-access-time" of each cookie in the "cookie-list" 278 to the current date and time. 280 4. Serialize the "cookie-list" into a "cookie-string" by processing 281 each cookie in the "cookie-list" in order: 283 1. Output the cookie's "name", the %x3D ("=") character, and the 284 cookie's "value". 286 2. If there is an unprocessed cookie in the "cookie-list", 287 output the characters %x3B and %x20 ("; "). 289 4. Security Considerations 291 The security considerations listed in Section 8 of [RFC6265] apply 292 equally to origin cookies, with the exceptions of Sections 8.6 ("Weak 293 Confidentiality") and Sections 8.7 ("Weak Isolation"), both of which 294 are substantially improved if the "Origin" attribute is set. 295 Further: 297 4.1. "HttpOnly" 299 Note that origin cookies are only accessible via HTTP. "Non-HTTP" 300 APIs like HTML's "document.cookie" cannot read these cookies' values. 302 4.2. Paths are ignored 304 Origin cookies will break the (flawed) "Path"-based isolation 305 strategy which some servers may be attempting to implement. If a 306 server has used the "Path" attribute to limit cookies to specific 307 areas of a site (say "/admin"), then they may be surprised by origin 308 cookies' pathless behavior. 310 That said, paths offer little to no protection against malicious 311 code. The origin is the only security boundry enforced rigorously by 312 user agents; it is therefore the only security boundry that server 313 operators ought to rely on for isolation. 315 5. IANA Considerations 317 The permanent message header field registry (see [RFC3864]) shall be 318 updated with the following registration: 320 5.1. Origin-Cookie 322 o Header field name: Origin-Cookie 324 o Applicable protocol: http 326 o Status: standard 328 o Author/Change controller: IETF 330 o Specification document: This specification (see Section 3.5) 332 6. Acknowledgements 334 The origin cookie concept documented here is heavily indebted to and 335 based upon Adam Barth's [draft-abarth-cake-01] document, as well as 336 Andrew Bortz, Adam Barth, and Alexei Czeskis' paper 337 [origin-cookies-w2sp]. 339 7. References 341 7.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 347 Application Protocol Collation Registry", RFC 4790, March 348 2007. 350 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 351 Specifications: ABNF", STD 68, RFC 5234, January 2008. 353 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 354 April 2011. 356 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 357 2011. 359 7.2. Informative References 361 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 362 Procedures for Message Header Fields", BCP 90, RFC 3864, 363 September 2004. 365 [draft-abarth-cake-01] 366 Barth, A., "Origin Cookies", September 2011, 367 . 369 [origin-cookies-w2sp] 370 Bortz,, A., Barth, A., and A. Czeskis, "Origin Cookies: 371 Session Integrity for Web Applications", 2011, 372 . 374 Appendix A. Open Issues 376 o Should origin cookies be settable via "document.cookie"? Does 377 that weaken the guarantees in any way we care about? 379 Author's Address 380 Mike West 381 Google, Inc 383 Email: mkwst@google.com 384 URI: https://mikewest.org/