idnits 2.17.1 draft-west-origin-cookies-01.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 (April 20, 2015) is 3294 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) April 20, 2015 5 Intended status: Standards Track 6 Expires: October 22, 2015 8 Origin Cookies 9 draft-west-origin-cookies-01 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 October 22, 2015. 36 Copyright Notice 38 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . 4 56 3. Server Requirements . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Semantics of the "Origin" Attribute (Non-Normative) . . . 4 59 3.3. The Origin-Cookie header . . 5 60 3.3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 5 62 4. User Agent Requirements . . . . . . . . . . . . . . . . . . . 5 63 4.1. The "Origin" attribute . . . . . . . . . . . . . . . . . 5 64 4.2. Monkey-patching the Storage Model . . . . . . . . . . . . 5 65 4.3. Monkey-patching the "Cookie" header . . . . . . . . . . . 7 66 4.4. The "Origin-Cookie" header field . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 5.1. Paths are ignored . . . . . . . . . . . . . . . . . . . . 8 69 5.2. Downgrade attacks . . . . . . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 6.1. Origin-Cookie . . . . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 7.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Cookies, as defined by [RFC6265], diverge from the web's general 81 security policy in a number of ways which may be surprising to 82 implementers and authors who haven't carefully read that document's 83 discussion of "domain matching", and "path matching", or who ignored 84 the admonitions regarding "Weak Confidentiality" and "Weak 85 Integrity". 87 This document updates [RFC6265], describing a mechanism by which 88 servers can opt-in to harmonizing cookies' security policy with the 89 same-origin policy, as described in [RFC6454]. User agents that 90 support these "origin cookies" will ignore a "Set-Cookie" header's 91 value's "Path", "Domain", and "Secure" attributes if an "Origin" 92 attribute is present, instead tying the cookie to the origin that set 93 it. These "origin cookies" will be returned in a new "Origin-Cookie" 94 header field (see Section 4.4 for detail), separating them from non- 95 origin cookies in a way a server can easily distinguish. 97 Harmonizing with the same-origin policy mitigates the confidentiality 98 and integrity risks noted above by ensuring that origin cookies are 99 not influenced by malicious code running on a server's subdomain or a 100 non-standard port or scheme. 102 Note that the mechanism outlined here is backwards compatible with 103 the existing cookie syntax. Servers may serve origin cookies to all 104 user agents; those that do not support the "Origin" attribute will 105 simply store a non-origin cookie, just as they do today. 107 1.1. Examples 109 Origin cookies are set via the "Origin" attribute in the "Set-Cookie" 110 header field. That is, given a server's response to a user agent 111 which contains the following header field: 113 Set-Cookie: SID=31d4d96e407aad42; Secure; HttpOnly; Origin 115 Subsequent requests from that user agent can be expected to contain 116 the following header field: 118 Origin-Cookie: SID=31d4d96e407aad42 120 Non-origin cookies are returned in the "Cookie" header field as 121 usual. If both non-origin and origin cookies are present for an 122 origin, then both a "Cookie" and "Origin-Cookie" header field will be 123 present. That is, given a server's response to a user agent which 124 contains the following header fields: 126 Set-Cookie: SID=31d4d96e407aad42; Origin 127 Set-Cookie: lang=en-US; 129 Subsequent requests from that user agent can be expected to contain 130 the following header fields: 132 Cookie: lang=en-US 133 Origin-Cookie: SID=31d4d96e407aad42 135 User agents that support origin cookies are required to advertise 136 their support for such by sending an "Origin-Cookie" header whenever 137 a "Cookie" header is sent. That is, given the following server 138 response: 140 Set-Cookie: lang=en-US; Secure; HttpOnly 142 Subsequent requests from a user agent that supports origin cookies 143 can be expected to contain the following header fields: 145 Cookie: lang=en-US 146 Origin-Cookie: 148 Note that the "Origin-Cookie" field is empty. 150 2. Terminology and notation 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 This specification uses the Augmented Backus-Naur Form (ABNF) 157 notation of [RFC5234]. 159 Two sequences of octets are said to case-insensitively match each 160 other if and only if they are equivalent under the "i;ascii-casemap" 161 collation defined in [RFC4790]. 163 3. Server Requirements 165 This section describes extensions to [RFC6265] necessary to implement 166 the server-side requirements of the "Origin" attribute. 168 3.1. Grammar 170 Add "Origin" to the list of accepted attributes in the "Set-Cookie" 171 header field's value by replacing the "cookie-av" token definition in 172 Section 4.1.1 of [RFC6265] with the following ABNF grammar: 174 cookie-av = expires-av / max-age-av / domain-av / 175 path-av / secure-av / httponly-av / 176 origin-av / extension-av 177 origin-av = "origin" 179 3.2. Semantics of the "Origin" Attribute (Non-Normative) 181 The "Origin" attribute limits the scope of the cookie such that it 182 will only be attached to requests if those request match the origin 183 which set the cookie. For example, requests for 184 "https://example.com/" will attach origin cookies if and only if 185 those cookies were set by "https://example.com/". 187 The changes to the "Cookie" header field suggested in Section 4.3 188 provide additional detail. 190 3.3. The Origin-Cookie header 192 3.3.1. Syntax 194 The user agent sends stored origin cookies to the origin server in 195 the "Origin-Cookie" header. If the server conforms to the 196 requirements in Section 3 (and the user agent conforms to the 197 requirements in Section 4), the user agent will send an "Origin- 198 Cookie" header which conforms to the following grammar: 200 origin-cookie-header = "Origin-Cookie:" OWS [ cookie-string ] OWS 202 3.3.2. Semantics 204 The semantics of the "cookie-string" are the same as those of the 205 same token in the "Cookie" header. 207 Note, however, that the "Origin-Cookie" header MAY be empty, and MUST 208 be sent with every request, even if no origin cookies are present in 209 the cookie store. This allows conformant servers to detect a user 210 agent's support for origin cookies, and therefore to make a secure 211 decision about whether or not to fallback to searching through the 212 "Cookie" header for specific cookies. See Section 5.2 for details. 214 4. User Agent Requirements 216 This section describes extensions to [RFC6265] necessary in order to 217 implement the client-side requirements of the "Origin" attribute and 218 "Origin-Cookie" header field. 220 4.1. The "Origin" attribute 222 The following attribute definition should be considered part of the 223 the "Set-Cookie" algorithm as described in Section 5.2 of [RFC6265]: 225 If the attribute-name case-insensitively matches the string "Origin", 226 the user agent MUST append an attribute to the cookie-attribute-list 227 with an attribute-name of "Origin" and an empty attribute-value. 229 4.2. Monkey-patching the Storage Model 231 Note: There's got to be a better way to specify this. Until I figure 232 out what that is, monkey-patching! 234 Alter Section 5.3 of [RFC6265] as follows: 236 1. Add "origin" and "origin-flag" to the list of fields stored about 237 each cookie. 239 2. Before step 11 of the current algorithm, add the following: 241 1. If the "cookie-attribute-list" contains an attribute with an 242 "attribute-name" of "Origin": 244 1. Set the cookie's "domain" attribute to the empty string. 246 2. Set the cookie's "host-only-flag" to true. 248 3. Set the cookie's "origin" to the origin of "request-uri", 249 as defined by Section 4 of [RFC6454]. 251 4. Set the cookie's "origin-flag" to true. 253 5. Set the cookie's "path" attribute to the empty string. 255 6. Set the cookie's "secure-only-flag" to false. 257 Otherwise: set the cookie's "origin-flag" to false, and its 258 "origin" to "null". 260 2. If the newly created cookie's "origin-flag" is set to true, 261 and the cookie store contains a cookie with the same"name", 262 "origin", and "origin-flag" as the newly created cookie: 264 1. Let "old-cookie" be the existing cookie with the same 265 "name", "origin", and "origin-flag" as the newly created 266 cookie. 268 2. Update the "creation-time" of the newly created cookie to 269 match the "creation-time" of "old-cookie". 271 3. Remove "old-cookie" from the cookie store. 273 3. Change the priority order for excess cookie removal to the 274 following: 276 1. Expired cookies. 278 2. Cookies whose "origin-flag" is false that share a "domain" 279 field with more than a predetermined number of other cookies. 281 3. Cookies whose "origin-flag" is true that share a "domain" 282 field with more than a predetermined number of other cookies. 284 4. Cookies whose "origin-flag" is false. 286 5. All cookies. 288 4.3. Monkey-patching the "Cookie" header 290 Note: There's got to be a better way to specify this. Until I figure 291 out what that is, monkey-patching! 293 Alter Section 5.4 of [RFC6265] as follows: 295 1. Add the following requirement to the list in step 1: 297 * The cookie's "origin-flag" is false. 299 4.4. The "Origin-Cookie" header field 301 The user agent includes stored cookies whose "origin-flag" is set in 302 the "Origin-Cookie" request header. When the user agent generates an 303 HTTP request, it MUST NOT attach more than one "Origin-Cookie" header 304 field. 306 A user agent MAY omit the "Origin-Cookie" header in its entirety. 307 For example, the user agent may wish to block sending cookies during 308 "third-party" requests. If, however, a "Cookie" header is sent, a 309 user agent MUST send an "Origin-Cookie" header. 311 If the user agent does attach an "Origin-Cookie" header field to an 312 HTTP request, the user agent MUST send the "cookie-string" as defined 313 below as the value of the header field. 315 The user agent MUST use an algorithm equivalent to the following 316 algorithm to compute the "cookie-string" from a cookie store and a 317 "request-uri": 319 1. Let "cookie-list" be the set of cookies from the cookie store 320 that meets all the following requirements: 322 * The cookie's "origin-flag" is true. 324 * The cookie's "origin" matches the origin of "request-uri". 325 [RFC6454] 327 2. The user agent SHOULD sort the "cookie-list" in the following 328 order: 330 * Cookies with earlier "creation-time"s are listed before 331 cookies with later "creation-time"s. 333 3. Update the "last-access-time" of each cookie in the "cookie-list" 334 to the current date and time. 336 4. Serialize the "cookie-list" into a "cookie-string" by processing 337 each cookie in the "cookie-list" in order: 339 1. Output the cookie's "name", the %x3D ("=") character, and the 340 cookie's "value". 342 2. If there is an unprocessed cookie in the "cookie-list", 343 output the characters %x3B and %x20 ("; "). 345 5. Security Considerations 347 The security considerations listed in Section 8 of [RFC6265] apply 348 equally to origin cookies, with the exceptions of Sections 8.6 ("Weak 349 Confidentiality") and Sections 8.7 ("Weak Isolation"), both of which 350 are substantially improved if the "Origin" attribute is set. 351 Further: 353 5.1. Paths are ignored 355 Origin cookies will break the (flawed) "Path"-based isolation 356 strategy which some servers may be attempting to implement. If a 357 server has used the "Path" attribute to limit cookies to specific 358 areas of a site (say "/admin"), then they may be surprised by origin 359 cookies' pathless behavior. 361 That said, paths offer little to no protection against malicious 362 code. The origin is the only security boundry enforced rigorously by 363 user agents; it is therefore the only security boundry that server 364 operators ought to rely on for isolation. 366 5.2. Downgrade attacks 368 If a server chooses to scan both the "Origin-Cookie" and "Cookie" 369 headers in order to provide backwards compatibility with user agents 370 that don't support origin cookies, it ought to be done carefully. 371 Careless fallback strategies can provide a window of opportunity for 372 an attacker to inject cookies with the same name as origin cookies 373 from a subdomain, bypassing origin cookies' main advantage. 375 o If the "Origin-Cookie" header is present, servers SHOULD NOT check 376 the "Cookie" header for cookies which it set as origin cookies. 378 o If a user agent is known to support origin cookies, servers SHOULD 379 check only the "Origin-Cookie" header for origin cookies, and 380 SHOULD NOT fallback to the "Cookie" header if the "Origin-Cookie" 381 header is not present, or if a particular cookie is not found 382 there. 384 6. IANA Considerations 386 The permanent message header field registry (see [RFC3864]) shall be 387 updated with the following registration: 389 6.1. Origin-Cookie 391 o Header field name: Origin-Cookie 393 o Applicable protocol: http 395 o Status: standard 397 o Author/Change controller: IETF 399 o Specification document: This specification (see Section 4.4) 401 7. References 403 7.1. Normative References 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 409 Application Protocol Collation Registry", RFC 4790, March 410 2007. 412 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 413 Specifications: ABNF", STD 68, RFC 5234, January 2008. 415 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 416 April 2011. 418 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 419 2011. 421 7.2. Informative References 423 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 424 Procedures for Message Header Fields", BCP 90, RFC 3864, 425 September 2004. 427 [draft-abarth-cake-01] 428 Barth, A., "Origin Cookies", September 2011, 429 . 431 [origin-cookies-w2sp] 432 Bortz,, A., Barth, A., and A. Czeskis, "Origin Cookies: 433 Session Integrity for Web Applications", 2011, 434 . 436 Appendix A. Acknowledgements 438 The origin cookie concept documented here is heavily indebted to and 439 based upon Adam Barth's [draft-abarth-cake-01] document, as well as 440 Andrew Bortz, Adam Barth, and Alexei Czeskis' paper 441 [origin-cookies-w2sp]. 443 Author's Address 445 Mike West 446 Google, Inc 448 Email: mkwst@google.com 449 URI: https://mikewest.org/