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/