idnits 2.17.1 draft-nir-websec-extended-origin-02.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC6454, but the abstract doesn't seem to directly say this. It does mention RFC6454 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This means that all requests of the format "GET /something/..." will be considered as going to the origin defined by the combination of the RFC 6454 origin and the name. As such, cookies from the portal MUST not be returned in requests to the extended origin, and vice versa. Scripts from inside the extended origin MUST be prevented from executing requests against the main portal and against other extended origins within the same portal. -- The document date (March 6, 2012) is 4406 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nir, Ed. 3 Internet-Draft Check Point 4 Updates: 6454 (if approved) March 6, 2012 5 Intended status: Standards Track 6 Expires: September 7, 2012 8 A More Granular Web Origin Concept 9 draft-nir-websec-extended-origin-02 11 Abstract 13 This document defines an HTTP header that allows the partitioning of 14 a single origin (as defined in RFC 6454) into multiple origins, so 15 that the same origin policy applies among them. 17 The header introduced in this document allows a portal to specify 18 that resources that appear to be from the same origin should, in 19 fact, be treated as though they are from different origins, by 20 extending the 3-tuple of the origin to a 4-tuple. A compliant user 21 agent is expected to apply the same-origin policy according to the 22 4-tuple rather than the 3-tuple. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 7, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3 60 2. The Extended-Origin Header . . . . . . . . . . . . . . . . . . 3 61 2.1. Header Format . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Update to the Serialization Requirements . . . . . . . . . 4 63 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Determining the Extended Origin based on a URL . . . . . . . . 6 65 5. CORS interaction . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Other Methods of Encoding Server Identity . . . . . . . . . 7 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 71 10. Changes from Previous Versions . . . . . . . . . . . . . . . . 8 72 10.1. Changes in version -02 . . . . . . . . . . . . . . . . . . 8 73 10.2. Changes in version -01 . . . . . . . . . . . . . . . . . . 8 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Reverse proxies such as SSL VPN portals "flatten" part of the Web, by 82 providing access to multiple web sites through a single host. For 83 example, a company portal may be located at 84 https://sslvpn.example.com, and allow remote access to several 85 websites that form the corporate intranet as well as webified access 86 to the mail server. The different services are distinguised by 87 implementation-specific manipulation of the URL. For example, the 88 following three URLs may be respectively for the internal mail 89 server, for the internal wiki, and for Wikipedia: 90 1. https://sslvpn.example.com/link/my_web_mail/inbox/index.html 91 2. https://sslvpn.example.com/link/the_wiki/index.html 92 3. https://sslvpn.example.com/ext/wikipedia.org 94 The problem here is that although there are separate servers, they 95 all map to the same origin as defined in [RFC6454]. Scripts from any 96 of these sites can affect others. In fact, the Origin header as 97 defined in section 7 of RFC 6454 can leak information to the real web 98 server that it is located within the same flattened domain. 100 The HTTP header introduced in this document allows the portal to 101 specify that URLs that appear to be from the same origin are, in 102 fact, from different origins, by extending the 3-tuple of the origin 103 to a 4-tuple. The user agent would be expected to apply the same- 104 origin policy according to the 4-tuple rather than the 3-tuple. 106 1.1. Conventions Used in This Document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 2. The Extended-Origin Header 114 When a web portal hides multiple actual web sites behind its own 115 origin, it MUST add the new Extended-Origin header defined in the 116 next section. The name field need not be related to the actual web 117 origin, and is not meant for human consumption. The requirement is 118 only that different origins MUST have different names in the header. 120 If the response from the original web site already contains one or 121 more Extended-Origin headers, then the portal adds its own header 122 after the rest. 124 2.1. Header Format 126 The ABNF is to be added. 128 The header includes a name, which is not necessarily meant for human 129 consumption, and a path parameter. The general format is 131 Extended-Origin: name; path=/something 133 This means that all requests of the format "GET /something/..." will 134 be considered as going to the origin defined by the combination of 135 the RFC 6454 origin and the name. As such, cookies from the portal 136 MUST not be returned in requests to the extended origin, and vice 137 versa. Scripts from inside the extended origin MUST be prevented 138 from executing requests against the main portal and against other 139 extended origins within the same portal. 141 2.2. Update to the Serialization Requirements 143 Section 6 of RFC 6454 defines how to serialize an origin for 144 inclusion in the "Origin" header defined in section 7 of that RFC. 146 For serializing an extended origin, follow steps 1-3 of section 6.1 147 or 6.2 of RFC 6454. To the result, append the name from the 148 Extended-Origin header and a U+002E FULL STOP code points ("."). 149 Then continue with steps 4-6. 151 For example, if the host is sslvpn.example.com, and the name in the 152 extended origin header is webmail, then the serialized origin becomes 153 https://webmail.sslvpn.example.com 155 To avoid collisions between serialized extended origins and 156 serialized non-extended origins, servers SHOULD NOT use readable 157 origins such as "webmail". Instead they should choose random-looking 158 extended origin names, possibly obtained by hashing an internally 159 meaningful name. 161 3. Examples 163 Here's an example of a connection with both the Extended-Origin and 164 the Origin headers. 166 CONNECT https://sslvpn.example.com 168 GET / HTTP/1.1 170 HTTP/1.1 200 OK 171 Content-Type: application/octet-stream 172 Set-Cookie: session=1234 174 175 176 Welcome, you can read your mail 177 here 178 179 181 GET /link/my_web_mail/inbox/index.html HTTP/1.1 182 Referer: https://sslvpn.example.com/ 183 Cookie: session=1234 185 HTTP/1.1 200 OK 186 Content-Type: application/octet-stream 187 Extended-Origin: d41d8cd98f00b204; path=/link/my_web_mail 188 Set-Cookie: mailsession=5678 190 191 192 You have 1 unread message. Jumping in 5 seconds... 193 194 195 197 GET /link/my_web_mail/inbox/msg0945.html HTTP/1.1 198 Referer: https://sslvpn.example.com/link/my_web_mail/inbox/index.htm 199 Origin: https://d41d8cd98f00b204.sslvpn.example.com 200 Cookie: mailsession=5678 202 In this example, the first GET was the result of the user typing in 203 an address, or following a link. Therefore it has no Origin header. 204 It goes to the main page of the portal, so the response contains no 205 Extended-Origin. 207 The second GET also happened because of clicking a link, not by any 208 action of the page, so there's no need to send an Origin header. If 209 there had been such a header, it would be just as defined in RFC 210 6454: https://sslvpn.example.com 212 The third GET is caused by a script running on the mail page. This 213 page came with an Extended-Origin header, and so the user agent 214 constructs the Origin header in the request according to the new 215 rules in Section 2.2. 217 Note that the cookie set by the main portal was not sent in the third 218 request. The second reply marked all requests beginning with "/link/ 219 my_web_mail" as belonging to the extended origin, and the third 220 request matches that pattern. Cookies from the non-extended origin 221 are not forwarded to the extended origin. 223 The second request did include the portal cookie in a request to the 224 mail server. This is only an issue with the main portal cookies, not 225 among the extended origins. Some SSL VPN portals strip their own 226 cookies from requests going to the other servers, and this behavior 227 is RECOMMENDED. 229 4. Determining the Extended Origin based on a URL 231 This section defines an algorithm for converting a URL into an 232 origin. This section is not normative, and compliant browsers may 233 implement this in other ways. 235 For each visited site, the browser keeps a table mapping paths to 236 origin names. Initially, this table looks like this: 238 +------+------+ 239 | Path | Name | 240 +------+------+ 241 | / | | 242 +------+------+ 244 Table 1: Initial table 246 As Extended-Origin headers are encountered, entries are added to the 247 table. For example, after seeing the header in the example in 248 Section 3, the table will look like this: 250 +-------------------+------------------+ 251 | Path | Name | 252 +-------------------+------------------+ 253 | / | | 254 | /link/my_web_mail | d41d8cd98f00b204 | 255 | /link/SAP | 12c30f3bb3275376 | 256 +-------------------+------------------+ 258 Table 2: The table with 2 more entries 260 When presented with a URL, the browser can normally figure the 261 scheme, host and port. The name parameter can be figured out form 262 the path according to the closes match in the table. Here are some 263 URLs and the origins to which they map: 265 +------------------------------------+------------------------------+ 266 | URL | Extended Origin | 267 +------------------------------------+------------------------------+ 268 | https://sslvpn.example.com/index.h | https://sslvpn.example.com | 269 | tml | | 270 | https://sslvpn.example.com/link/my | https://d41d8cd98f00b204.ssl | 271 | _web_mail/msg0005.html | vpn.example.com | 272 | https://sslvpn.example.com/link/SA | https://sslvpn.example.com | 273 | PIENCE/index.html | | 274 | https://sslvpn.example.com/link/SA | https://12c30f3bb3275376.ssl | 275 | P/index.html | vpn.checkpoint.com | 276 | https://sslvpn.example.com/ext/wik | https://sslvpn.example.com | 277 | ipedia.org/index.html | | 278 +------------------------------------+------------------------------+ 280 Table 3: Extended origin examples 282 5. CORS interaction 284 The interaction between this draft and CORS ([CORS]) is to be added. 286 6. Open Issues 288 6.1. Other Methods of Encoding Server Identity 290 Some SSL-VPN products and configurations do not encode the server 291 identity using a prefix in the URL, as shown in the example in 292 Section 3. One such Method is this: 294 https://sslvpn.example.com/p/inb/msg0945.html,HOST=mail.example.com 296 The issue here is that the way the path parameter is defined, you 297 cannot use it to define what URLs belong to the extended origin. We 298 could replace it with a parameter that accepts a regular expression, 299 but that seems overly complex: 301 Extended-Origin: webmail; expr=/p/*,HOST=mail.example.com 303 7. Acknowledgements 305 Oren Souroujon contributed some of the text in this document, and 306 also came up with the original idea. Yehezkel Horowitz helped with 307 reviewing the draft and pointing out the issues with cookies and 308 paths. 310 Thanks to James Manger and Tobias Gondrom for reviewing the first 311 version of this draft. 313 8. Security Considerations 315 This document causes compliant clients to disallow certain actions 316 that are allowed today. In that sense, it reduces the attack 317 surface. 319 More to be added. 321 9. IANA Considerations 323 The permanent message header field registry (see [RFC3864]) should be 324 updated with the following registration: 325 o Header field name: Extended-Origin 326 o Applicable protocol: http 327 o Status: Standard 328 o Author/Change controller: IETF 329 o Specification document: this specification 331 10. Changes from Previous Versions 333 NOTE TO RFC EDITOR: Please remove this section before publication. 335 10.1. Changes in version -02 337 Added Section 4 about converting URLs to extended origins 339 10.2. Changes in version -01 341 Removed the special handling of portals behind portals. 343 Changed the syntax of the serialized origin from fragment-like to 344 subdomain-like. 346 Cleaned up some grammar. 348 11. References 350 11.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 356 December 2011. 358 11.2. Informative References 360 [CORS] van Kesteren, A., "Cross-Origin Resource Sharing", W3C 361 Working Draft WD-cors-20100727, July 2010. 363 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 364 Procedures for Message Header Fields", RFC 3864, BCP 90, 365 September 2004. 367 Author's Address 369 Yoav Nir (editor) 370 Check Point Software Technologies Ltd. 371 5 Hasolelim st. 372 Tel Aviv 67897 373 Israel 375 Email: ynir@checkpoint.com