INTERNET-DRAFT A. Megacz draft-megacz-x-requestorigin-00.txt The XWT Foundation Category: Informational D. Meketa Macromedia Corporation 06 Jun 2003 X-RequestOrigin draft-megacz-x-requestorigin-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 6, 2003. Copyright Notice Copyright (C) The Internet Society 2003. All Rights Reserved. Abstract Security policies are often implemented by network intermediaries such as routers and proxies. These intermediaries are unable to distinguish between requests from requests initiated by a user and requests initiated by untrusted mobile code running on the user's machine. This document describes the X-RequestOrigin hop-by-hop HTTP header, which an HTTP client uses to allow intermediate proxies to make this distinction. Table of Contents 1. Introduction 1.1 Implementation of Security Policies 1.2 The Problem 1.3 Suboptimal Solutions 1.3.1 Same Origin Policy and Domain-Based Security 1.3.2 Same IP Policy 1.3.3 RFC 1918 Based Security 2. Criteria for a Solution 3. The X-RequestOrigin header 3.1 Client 3.2 Proxy 4. Current Implementations 4.1 XWT Nitrogen 4.2 Squid 3.0 1. Introduction 1.1 Implementation of Security Policies Security policies are often implemented by network intermediaries such as routers and proxies. These intermediaries decide to permit or deny certain kinds of traffic based on many factors, including the origin of the request and the current security policy set by the administrator. 1.2 The Problem The intermediary is often only aware of the *topological* origin of the traffic. For example, a router does not know if a UDP packet or HTTP request was generated at the request of the user operating a client machine or by an untrusted piece of mobile code running on that machine. In other words, mobile code downloaded from a remote site is given the permissions of the machine it runs on, not the entity which created it. 1.3. Suboptimal Solutions Because intermediaries lack detailed information about the entity that generated the content, programs capable of running mobile code often err on the side of caution and place cumbersome limitations on the network traffic that untrusted mobile code can generate. Unfortunately, even these approximations of the desired security policy are not sufficiently secure. 1.3.1 Same Origin Policy and Domain-Based Security JavaScript restricts the set of sites that mobile code can read responses from according to the Same Origin Policy [3]. This policy has numerous flaws [1] which are beyond the scope of this RFC. The Macromedia Flash plugin implements a form of domain-based security [2] which is very similar to the Same Origin Policy. [[ FIXME: Deneb, once Macromedia's new domain-based security policy is made public, do you want to mention it here? ]] One problem with this class of security measures is that it prevents mobile code from one organization from accessing public servers operated by another organization unless the latter explicitly adds a DNS entry for the former. This is often not possible, for example in the case of a large organization which has no incentive to assist smaller organizations (for example, a research team demonstrating a new product based on Google's or Amazon's SOAP interfaces). The other problem with this measure is that so far, no mechanism has been discovered for protecting clients that rely on their proxy for hostname resolution from the "Quick-Swap DNS Attack" [1]. 1.3.2 Same IP Policy Java Applets restrict untrusted mobile code to only communicating with the IP address it originated from. This is an extremely restrictive policy, and severely limits the applications of mobile code, particularly in peer-to-peer scenarios. In addition, clients which rely on a proxy for hostname resolution cannot fully implement this policy since they do not know the mobile code's origin IP. In this situation, most Java implementations use the originating hostname as a substitute, but this leaves the user open to a Quick-Swap DNS Attack. 1.3.3 RFC 1918 Based Security XWT surmounts the first problem with domain-based security by restricting access to those IP spaces declared to be private in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16). Some organizations squander scarce publicly-routable addresses by using them behind firewalls; these organizations are left vulnerable by this policy. At one time, XWT also protected proxied clients without DNS access against Quick-Swap DNS Attacks by using a trusted public service (xmlrpc.xwt.org) to perform DNS lookups for clients who are unable to do so. This policy was later dropped as it did not work on private networks with no gateway to the Internet, and because it introduced a single point of failure. 2. Criteria for a Solution In order for a fine-grained security policy to be implemented, a permit/deny decision must be made by a network element with knowledge of both: - the network's security policy - the true origin of the entity generating the traffic One approach is to push the security policy out to the clients and perform the permit/deny decision there. The other alternative, which this RFC uses, is for the client (which knows the true origin of the entity generating the traffic) to transmit this knowledge to the network intermediary, which knows the security policy. The remainder of this RFC outlines a protocol for transmitting this information in the specific case where the traffic in question is an HTTP request and the network intermediary is an HTTP proxy. 3. The X-RequestOrigin header 3.1 Client Clients which support this RFC MUST transmit an additional header, "X-RequestOrigin" with every request they send through a proxy. This header is a hop-by-hop header; it MUST be passed from the client to its proxy, and MAY be passed from a downstream proxy to an upstream proxy, but it MUST NOT be transmitted in the final hop to the ultimate destination of the request. If the entity which generated the HTTP request is running locally on the client and is trusted to act on the user's behalf, the value of this header is the nine-octet ASCII string "127.0.0.1". If the entity which generated the HTTP request is not fully trusted to act on the user's behalf, the value of the header is the domain name or IP address from which the entity was retrieved. 3.2 Proxy A proxy which receives a request with an X-RequestOrigin header MAY choose to deny the request based on the value of the header. The response to a particular value of the X-RequestOrigin header is site-dependent. 4. Current Implementations 4.1 XWT Nitrogen The Nitrogen release of XWT implements this RFC when sending HTTP requests via a proxy. 4.2 Squid 3.0 A patch to implement this protocol in Squid 3.0 is available from: http://xwt.org/x-requestorigin.html Informative References [1] Megacz, Adam, "XWT Foundation Security Advisory: JavaScript Same Origin Policy", http://www.megacz.com/sop.txt [2] Macromedia Flash MX Security, http://www.macromedia.com/desdev/mx/flash/whitepapers/security.pdf [3] JavaScript Same Origin Policy http://www.mozilla.org/projects/security/components/same-origin.html Author's Addresses Adam Megacz The XWT Foundation Email: adam@xwt.org Deneb Meketa Macromedia Corporation Email: meketa@macromedia.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society.