idnits 2.17.1 draft-ietf-websec-origin-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 29, 2010) is 4866 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) == Unused Reference: 'RFC5246' is defined on line 465, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 websec A. Barth 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track December 29, 2010 5 Expires: July 2, 2011 7 The Web Origin Concept 8 draft-ietf-websec-origin-00 10 Abstract 12 This document defines the concept of an "origin", which represents a 13 web principal. Typically, user agents isolate content retrieved from 14 different origins to prevent a malicious web site operator from 15 interfering with the operation of benign web sites. In particular, 16 this document defines how to compute an origin from a URI, how to 17 serialize an origin to a string, and an HTTP header, named "Origin", 18 for indicating which origin caused the user agent to issue a 19 particular HTTP request. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on July 2, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 4 64 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Comparing Origins . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Serializing Origins . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Unicode Serialization of an Origin . . . . . . . . . . . . 9 70 5.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 9 71 6. The HTTP Origin header . . . . . . . . . . . . . . . . . . . . 11 72 6.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 11 74 6.3. User Agent Requirements . . . . . . . . . . . . . . . . . 11 75 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 10. Implementation Considerations . . . . . . . . . . . . . . . . 16 79 10.1. IDNA dependency and migration . . . . . . . . . . . . . . 16 80 11. Normative References . . . . . . . . . . . . . . . . . . . . . 17 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 User agents interact with content created by a large number of 87 authors. Although many of those authors are well-meaning, some 88 authors might be malicious. To the extent that user agents undertake 89 actions based on content they process, user agent implementors might 90 wish to restrict the ability of malicious authors to disrupt the 91 confidentiality or integrity of other content or servers. 93 As an example, consider an HTTP user agent that renders HTML content 94 retrieved from various servers. If the user agent executes scripts 95 contained in those documents, the user agent implementor might wish 96 to prevent scripts retrieved from a malicious server from reading 97 documents stored on an honest server, which might, for example, be 98 behind a firewall. 100 Traditionally, user agents have divided content according to its 101 "origin". More specifically, user agents allow content retrieved 102 from one origin to interact freely with other content retrieved from 103 that origin, but user agents restrict how that content can interact 104 with content from another origin. 106 This document does not describe the restrictions user agents ought to 107 impose on cross-origin interaction. Instead, this document defines 108 the origin concept itself in such a way that other specifications, 109 such for HTTP [cite] or for HTML [cite], can refer to this document 110 for a precise, common definition of the web origin concept. 112 Specifically, a user agent can compute the origin of a piece of 113 content based on the URI from which the user agent retrieved the 114 content. Given two origins computed in this way, the user agent can 115 compare the origins to determine if they are "the same", which is 116 useful for performing some security checks. Finally, given an 117 origin, the user agent can serialize that origin into either an ASCII 118 or a Unicode representation. 120 This document also defines one use of the ASCII serialization: the 121 HTTP Origin header. An Origin header attached to an HTTP request 122 contains the ASCII serializations of the origins that caused the user 123 agent to issue the HTTP request. The Origin header has a number of 124 uses, including for cross-origin resource sharing [cite]. 126 2. Conventions 128 2.1. Conformance Criteria 130 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 131 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 132 interpreted as described in [RFC2119]. 134 Requirements phrased in the imperative as part of algorithms (such as 135 "strip any leading space characters" or "return false and abort these 136 steps") are to be interpreted with the meaning of the key word 137 ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm. 139 Conformance requirements phrased as algorithms or specific steps can 140 be implemented in any manner, so long as the end result is 141 equivalent. In particular, the algorithms defined in this 142 specification are intended to be easy to understand and are not 143 intended to be performant. 145 2.2. Syntax Notation 147 This specification uses the Augmented Backus-Naur Form (ABNF) 148 notation of [RFC5234]. 150 The following core rules are included by reference, as defined in 151 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 152 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 153 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 154 sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US- 155 ASCII character), VCHAR (any visible US-ASCII character), and WSP 156 (whitespace). 158 The OWS (optional whitespace) rule is used where zero or more linear 159 whitespace characters MAY appear: 161 OWS = *( [ obs-fold ] WSP ) 162 ; "optional" whitespace 163 obs-fold = CRLF 165 OWS SHOULD either not be produced or be produced as a single SP 166 character. 168 2.3. Terminology 170 The terms user agent, client, server, proxy, and origin server have 171 the same meaning as in the HTTP/1.1 specification ([RFC2616], Section 172 1.3). 174 A globally unique identifier is a value which is different from all 175 other previously existing values. For example, a sufficiently long 176 random string is likely to be a globally unique identifier. 178 A idna-canonicalization host name is the string generated by the 179 following algorithm: 181 1. Convert the host name to a sequence of NR-LDH labels (see Section 182 2.3.2.2 of [RFC5890]) and/or A-labels according to the 183 appropriate IDNA specification [RFC5891] or [RFC3490] (see 184 Section 10.1 of this specification) 186 2. Convert the labels to lower case. 188 3. Concatenate the labels, separating each label from the next with 189 a %x2E (".") character. 191 3. Origin 193 An origin represents a web principal. Typically, user agents 194 determine the origin of a piece of content from the URI from which 195 they retrieved the content. In this section, we define how to 196 compute an origin from a URI. 198 The origin of a URI is the value computed by the following algorithm: 200 1. If the URI does not use a server-based naming authority, or if 201 the URI is not an absolute URI, then return a globally unique 202 identifier. 204 2. Let uri-scheme be the scheme component of the URI, converted to 205 lowercase. 207 3. If the implementation doesn't support the protocol given by uri- 208 scheme, then return a globally unique identifier. 210 4. If uri-scheme is "file", the implementation MAY return an 211 implementation-defined value. 213 1. NOTE: Historically, user agents have granted content from the 214 file scheme a tremendous number of privileges. However, 215 granting all local files such wide privileges can lead to 216 privilege escalation attacks. Some user agents have had 217 success granting local files directory-based privileges, but 218 this approach has not been widely adopted. Other user agent 219 use a globally unique identifier each file URI, which is the 220 most secure option. 222 5. Let uri-host be the idna-canonicalization of the host component 223 of the URI. 225 6. If there is no port component of the URI: 227 1. Let uri-port be the default port for the protocol given by 228 uri-scheme. 230 Otherwise: 232 2. Let uri-port be the port component of the URI. 234 7. Return the triple (uri-scheme, uri-host, uri-port). 236 Implementations MAY define other types of origins in addition to the 237 scheme/host/port triple type defined above. For example, an 238 implementation might define an origin based on a public key or an 239 implementation might append addition "sandbox" bits to a scheme/host/ 240 port triple. 242 4. Comparing Origins 244 To origins are "the same" if, and only if, they are identical. In 245 particular: 247 o If the two origins are scheme/host/port triple, the two origins 248 are the same if, and only if, they have identical schemes, hosts, 249 and ports. 251 o An origin that is globally unique identifier cannot be the same as 252 an origin that is a scheme/host/port triple. 254 o Two origins that are globally unique identifiers cannot be the 255 same if they were created at different times, even if they were 256 created for the same URI. 258 Two URIs are the same-origin if their origins are the same. 260 NOTE: A URI is not necessarily same-origin with itself. For 261 example, a data URI is not same-origin with itself because data 262 URIs do not use a server-based naming authority and therefore have 263 globally unique identifiers as origins. 265 5. Serializing Origins 267 This section defines how to serialize an origin to a unicode string 268 and to an ASCII string. 270 5.1. Unicode Serialization of an Origin 272 The unicode-serialization of an origin is the value returned by the 273 following algorithm: 275 1. If the origin is not a scheme/host/port triple, then return the 276 string 278 null 280 (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) 281 and abort these steps. 283 2. Otherwise, let result be the scheme part of the origin triple. 285 3. Append the string "://" to result. 287 4. Append the [TODO: IDNA ToUnicode] algorithm to each component of 288 the host part of the origin triple, and append the results of 289 each component, in the same order, separated by U+002E FULL STOP 290 code points (".") to result. 292 5. If the port part of the origin triple is different than the 293 default port for the protocol given by the scheme part of the 294 origin triple: 296 1. Append a U+003A COLON code point (":") and the given port, in 297 base ten, to result. 299 6. Return result. 301 [TODO: Check that we handle IPv6 literals correctly.] 303 5.2. ASCII Serialization of an Origin 305 The ascii-serialization of an origin is the value returned by the 306 following algorithm: 308 1. If the origin is not a scheme/host/port triple, then return the 309 string 311 null 313 (i.e., the code point sequence U+006E, U+0075, U+006C, U+006C) 314 and abort these steps. 316 2. Otherwise, let result be the scheme part of the origin triple. 318 3. Append the string "://" to result. 320 4. Append the host port of the origin triple to result. 322 5. If the port part of the origin triple is different than the 323 default port for the protocol given by the scheme part of the 324 origin triple: 326 1. Append a U+003A COLON code points (":") and the given port, 327 in base ten, to result. 329 6. Return result. 331 6. The HTTP Origin header 333 This section defines the HTTP Origin header. 335 6.1. Syntax 337 The Origin header has the following syntax: 339 origin = "Origin:" OWS origin-list-or-null OWS 340 origin-list-or-null = "null" / origin-list 341 origin-list = serialized-origin *( SP serialized-origin ) 342 serialized-origin = scheme "://" host [ ":" port ] 343 ; , , productions from RFC3986 345 6.2. Semantics 347 When included in an HTTP request, the Origin header indicates the 348 origin(s) that caused the user agent to issue the request. 350 For example, consider a user agent that executes scripts on behalf of 351 origins. If one of those scripts causes the user agent to issue an 352 HTTP request, the user agent might wish to use the Origin header to 353 inform the server that the request was issued by the script. 355 In some cases, a number of origins contribute to causing the user 356 agents to issue an HTTP request. In those cases, the user agent can 357 list all the origins in the Origin header. For example, if the HTTP 358 request was initially issued by one origin but then later redirected 359 by another origin, the user agent might wish to inform the server 360 that two origins were involved in causing the user agent to issue the 361 request. 363 6.3. User Agent Requirements 365 The user agent MAY include an Origin header in any HTTP request. 367 The user agent MUST NOT include more than one Origin header field in 368 any HTTP request. 370 Whenever a user agent issues an HTTP request from a "privacy- 371 sensitive" context, the user agent MUST send the value "null" in the 372 Origin header. 374 NOTE: This document does not define the notion of a privacy- 375 sensitive context. Applications that generate HTTP requests can 376 designate contexts as privacy-sensitive to impose restrictions on 377 how user agents generate Origin headers. 379 When generating an Origin header, the user agent MUST meet the 380 following requirements: 382 o Each of the serialized-origin productions in the grammar MUST be 383 the ascii-serialization of an origin. 385 o No two consecutive serialized-origin productions in the grammar 386 can be identical. In particular, if the user agent would generate 387 two consecutive serialized-origins, the user agent MUST NOT 388 generate the second one. 390 If the user agent issued an HTTP request current-request because the 391 user agent received 3xx Status Code response to another HTTP request 392 previous-request for URI previous-uri: 394 o The HTTP request current-request MUST include an Origin header. 396 o The value of the Origin header MUST be either: 398 * The string "null" (i.e., the byte sequence %x6E, %x75, %x6C, 399 %x6C). 401 * The value of the Origin header in the previous-request. The 402 user agent MUST NOT choose this option if the ascii- 403 serialization of previous-uri is not identical to the last 404 serialized-origin in the Origin header of the previous request. 406 * The value of the Origin header in previous header extended with 407 a space and the ascii-serialization of the origin of previous- 408 uri. The user agent MUST NOT choose this option if the ascii- 409 serialization of the origin of previous-uri is "null". 411 The user agent SHOULD include the Origin header in an HTTP request if 412 the user agent issues the HTTP request on behalf of an origin (e.g., 413 not by the user operating a trusted user interface surface). In this 414 case, the user agent SHOULD set the value of the Origin header to the 415 ascii-serialization of that origin. 417 NOTE: This behavior differs from the usual user agent behavior for 418 the HTTP Referer header, which user agents often suppress when an 419 origin with an "https" scheme issues a request for a URI with an 420 "http" scheme. 422 7. Privacy Considerations 424 [TODO: Privacy considerations.] 426 8. Security Considerations 428 [TODO: Security considerations.] 430 9. IANA Considerations 432 [TODO: Register the Origin header.] 434 10. Implementation Considerations 436 10.1. IDNA dependency and migration 438 IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not 439 backwards-compatible. For this reason, there will be a transition 440 period (possibly of a number of years). User agents SHOULD implement 441 IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46 442 ] in order to facilitate a smoother 443 IDNA transition. If a user agent does not implement IDNA2008, the 444 user agent MUST implement IDNA2003 [RFC3490]. 446 11. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 452 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 453 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 455 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 456 "Internationalizing Domain Names in Applications (IDNA)", 457 RFC 3490, March 2003. 459 See Section 10.1 for an explanation why the normative 460 reference to an obsoleted specification is needed. 462 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 463 Specifications: ABNF", STD 68, RFC 5234, January 2008. 465 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 466 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 468 [RFC5890] Klensin, J., "Internationalized Domain Names for 469 Applications (IDNA): Definitions and Document Framework", 470 RFC 5890, August 2010. 472 [RFC5891] Klensin, J., "Internationalized Domain Names in 473 Applications (IDNA): Protocol", RFC 5891, August 2010. 475 Appendix A. Acknowledgements 476 Author's Address 478 Adam Barth 479 Google, Inc. 481 Email: ietf@adambarth.com 482 URI: http://www.adambarth.com/