Network Working Group A. Barbir Internet-Draft Nortel Networks Expires: June 7, 2004 O. Batuner Independent consultant B. Srinivas Nokia M. Hofmann Bell Labs/Lucent Technologies H. Orman Purple Streak Development December 8, 2003 Security Threats and Risks for OPES draft-ietf-opes-threats-03 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 June 7, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The document investigates the security threats associated with OPES. The effects of security threats on the underlying architecture are discussed. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. Barbir, et al. Expires June 7, 2004 [Page 1] Internet-Draft Security Threats and Risks for OPES December 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. OPES Data Flow Threats . . . . . . . . . . . . . . . . . . 5 2.1 OPES Flow Network Level Threats . . . . . . . . . . . . . 6 2.1.1 Connection-Flow Denial-of-Service (DoS) . . . . . . . . . 6 2.1.2 Threats to network robustness . . . . . . . . . . . . . . 7 2.2 OPES Flow Application Level Threats . . . . . . . . . . . 7 2.2.1 Unauthorized OPES entities . . . . . . . . . . . . . . . . 7 2.2.2 Unauthorized actions of legitimate OPES entities . . . . . 7 2.2.3 Unwanted content transformations . . . . . . . . . . . . . 8 2.2.4 Corrupted content . . . . . . . . . . . . . . . . . . . . 8 2.2.5 Threats to message structure integrity . . . . . . . . . . 8 2.2.6 Granularity of protection . . . . . . . . . . . . . . . . 9 2.2.7 Risks of hop-by-hop protection . . . . . . . . . . . . . . 9 2.2.8 Threats to integrity of complex data . . . . . . . . . . . 9 2.2.9 Denial of Service (DoS) . . . . . . . . . . . . . . . . . 9 2.2.10 Tracing and notification information . . . . . . . . . . . 10 2.2.11 Unauthenticated Communication in OPES Flow . . . . . . . . 10 3. Threats to out-of-band data . . . . . . . . . . . . . . . 11 3.1 Threats that endanger the OPES data flow . . . . . . . . . 11 3.2 Inaccurate Accounting Information . . . . . . . . . . . . 11 3.3 OPES service request repudiation . . . . . . . . . . . . . 12 3.4 Inconsistent privacy policy . . . . . . . . . . . . . . . 12 3.5 Exposure of privacy preferences . . . . . . . . . . . . . 12 3.6 Exposure of security settings . . . . . . . . . . . . . . 12 3.7 Improper enforcement of privacy and security policy . . . 13 3.8 DOS Attacks . . . . . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 16 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . 19 Barbir, et al. Expires June 7, 2004 [Page 2] Internet-Draft Security Threats and Risks for OPES December 2003 1. Introduction The Open Pluggable Edge Services (OPES) [1] architecture enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. The details of the OPES architecture can be found in [1]. Security threats with respect to OPES can be viewed from different angles. There are security risks that affect content consumer applications, and those that affect the data provider applications. These threats affect the quality and integrity of data that the applications either produce or consume. On the other hand, the security risks can also be categorized into trust within the system (i.e. OPES service providers) and protection of the system from threats imposed by outsiders such as hackers and attackers. Insiders are those parties that are part of the OPES system. Outsiders are those entities that are not participating in the OPES system. It must be noted that not everyone in an OPES delivery path is equally trusted. Each OPES administrative trust domain must protect itself from all outsiders. Furthermore, it may have limited trust relationship with another OPES administrative domain for certain purposes. OPES service provide must use authentication as the basis for building trust relationships between administrative domains. Insiders can intentionally or unintentionally inflict harm and damage on the data consumer and data provider applications. This can be through bad system configuration, execution of bad software or, if their networks are compromised, by inside or outside hackers. Depending on the deployment scenario, the trust within the OPES system is based on a set of transitive trust relationships between the data provider application, the OPES entities and the data consumer application. Threats to OPES entities can be at the OPES flow level and/or at the network level. In considering threats to the OPES system, the document will follow a threat analysis model that identifies the threats from the perspective of how they will affect the data consumer and the data provider applications. The main goal of this document is threat discovery and analysis. The Barbir, et al. Expires June 7, 2004 [Page 3] Internet-Draft Security Threats and Risks for OPES December 2003 document does not specify or recommend any solutions. It is important to mention that the OPES architecture has many similarities with other so called overlay networks, specifically web caches and content delivery networks (CDN) (see [2] , [4] ). This document focuses on threats that are introduced by the existence of the OPES processor and callout servers. Security threats specific to content services that do not use the OPES architecture are considered out-of-scope of this document. However, this document can be used as input when considering security implications for web caches and CDNs. The document is organized as follows: Section 2 discusses threats to OPES data flow on network and application level, section 3 discusses threats to other parts of the system and section 4 discusses security considerations. Barbir, et al. Expires June 7, 2004 [Page 4] Internet-Draft Security Threats and Risks for OPES December 2003 2. OPES Data Flow Threats Threats to OPES data flow can affect the data consumer and data provider applications. At the OPES flow level, threats can occur at Policy Enforcement Points and Policy Decision Points [3] and along the OPES flow path where network elements are used to process the data. A serious problem is posed by the very fact that the OPES architecture is based on widely adopted protocols (HTTP is used as an example). The architecture document specifically requires that "the presence of an OPES processor in the data request/response flow SHALL NOT interfere with the operations of non-OPES aware clients and servers". This greatly facilitates OPES deployment but on the other hand a vast majority of clients (browsers) will not be able to exploit any safeguards added as base protocol extensions. For the usual data consumer, who might have questions such as (Where does this content come from? Can I get it another way? What is the difference? Is it legitimate?). Even if there are facilities and technical expertise present to pursue these questions, such thorough examination of each result is prohibitively expensive in terms of time and effort. OPES-aware content providers may try to protect themselves by adding verification scripts and special page structures. OPES-aware end users may use special tools. In all other cases (non-OPES aware clients and servers) protection will rely on monitoring services and investigation of occasionally discovered anomalies. An OPES system poses a special danger as a possible base for classical man-in-the-middle attacks. One of the reasons why such attacks are relatively rare is the difficulty in finding an appropriate base: a combination of a traffic interception point controlling a large flow of data and an application codebase running on a high-performance hardware with sufficient performance to analyze and possible modify all passing data. An OPES processor meets this definition. This calls for special attention to protection measures at all levels of the system. Any compromise of an OPES processor or remote callout server can have a ripple effect on the integrity of the affected OPES services across all service providers that use the service. To mitigate this threat appropriate security procedures and tools (e.g., a firewall) should be applied. Specific threats can exist at the network level and at OPES data flow level. Barbir, et al. Expires June 7, 2004 [Page 5] Internet-Draft Security Threats and Risks for OPES December 2003 2.1 OPES Flow Network Level Threats OPES processor and callout servers are susceptible to network level attacks from outsiders or from the networks of other OPES service providers (i.e. if the network of a contracted OPES service is compromised). The OPES architecture is based on common application protocols that do not provide strong guarantees of privacy, authentication, or integrity. The IAB considerations [4] require that the IP address of an OPES processor be accessible to data consumer applications at the IP addressing level. This requirement limit the ability of service providers of positioning the OPES processor behind firewalls and may exposes the OPES processor, including remote callout servers, to network level attacks. For example, the use of TCP/IP as network level protocol makes OPES processors subject to many known attacks, such as IP spoofing and session stealing. The OPES system is also susceptible to a number of security threats that are commonly associated with network infrastructure. These threats include snooping, denial of service, sabotage, vandalism, industrial espionage and theft of service. There are best practice solutions to mitigate network level threats. It is recommended that the security of the OPES entities at the network level be enhanced using known techniques and methods that minimize the risks of IP spoofing, snooping, denial of service and session stealing. At the OPES Flow level, connection-level security between the OPES processor and callout servers is an important consideration. For example, it is possible to spoof the OPES processor or the remote callout server. There are threats to data confidentiality between the OPES processor and the remote callout server in an OPES flow. The next subsections covers possible DOS attack on OPES processor, remote callout server or data consumer application and network robustness. 2.1.1 Connection-Flow Denial-of-Service (DoS) OPES processors, or callout servers or data consumer applications can be vulnerable to DOS attacks. DOS attacks can be of various types. One example of DOS attacks is the overloading of OPES processors or callout servers by spurious service requests issued by a malicious node, which denies the legal data traffic the necessary resources to render service. The resources include CPU cycles, memory, network interfaces, etc. A Denial-of-Service attack can be selective, Barbir, et al. Expires June 7, 2004 [Page 6] Internet-Draft Security Threats and Risks for OPES December 2003 generic or random in terms of which communication streams are affected. Distributed DoS is also possible when an attacker successfully directs multiple nodes over the network to initiate spurious service requests to an OPES processor(or callout server) simultaneously. 2.1.2 Threats to network robustness If OPES implementation does violate end-to-end addressing principles, it could endanger the Internet infrastructure by complicating routing and connection management. If it does not use flow-control principles for managing connections, or if it interferes with end-to-end flow control of connections that it did not originate, then it could cause Internet congestion. An implementation that violates the IAB requirement of explicit IP level addressing (for example by adding OPES functional capabilities to an interception proxy) may defeat some of the protective mechanisms and safeguards built into the OPES architecture. 2.2 OPES Flow Application Level Threats At the content level, threats to the OPES system can come from outsiders or insiders. The threat from outsiders is frequently intentional. Threats from insiders can be intentional or due to inappropriate implementations such as programming and configuration errors that result in bad system behavior. Application level problems and threats to the OPES systems are discussed below: 2.2.1 Unauthorized OPES entities Although one party authorization is mandated by the OPES architecture, such authorization occurs out-of-band. Discovering the presence of an OPES entity and verifying authorization requires special actions and may present a problem. Adding notification and authorization information to the data messages (by using base protocol extensions) may help, especially if the data consumer's software is aware of such extensions. 2.2.2 Unauthorized actions of legitimate OPES entities According to the OPES architecture, the authorization is not tightly coupled with specific rules and procedures triggered by the rules. Even if a requirement to approve each particular rule and procedure Barbir, et al. Expires June 7, 2004 [Page 7] Internet-Draft Security Threats and Risks for OPES December 2003 was set, it looks at least impractical if not impossible to request such permission from the end user. The authorization is basically given for the class of transformations. The actual rules and triggered procedures may (maliciously or due to a programming error) perform actions that they are not authorized for. 2.2.3 Unwanted content transformations An authorized OPES service may perform actions that do not adhere to the expectations of the party that gave the authorization for the service. Examples may include ad flooding by a local ad insertion service or use of inappropriate policy by a content filtering service. On the other hand an OPES entity acting on behalf of one party may perform transformations that another party deems inappropriate. Examples may include replacing ads initially inserted by the content provider or applying filtering transformations that change the meaning of the text. 2.2.4 Corrupted content The OPES system may deliver outdated or otherwise distorted information due to programming problems or as a result of malicious attacks. For example, a compromised server, instead of performing OPES service, may inject bogus content. Such an action may be an act of cyber-vandalism (including virus injection) or intentional distribution of misleading information (such as manipulations with financial data). A compromised OPES server or malicious entity in the data flow may introduce changes specifically intended to cause improper actions in the OPES server or callout server. These changes may be in the message body, headers or both. This type of threat is discussed in more detail below. 2.2.5 Threats to message structure integrity An OPES server may add, remove or delete certain headers in a request and/or response message (for example to implement additional privacy protection or assist in content filtering). Such changes may violate end-to-end integrity requirements or defeat services that use information provided in such headers (for example some local filtering services or reference-based services). Barbir, et al. Expires June 7, 2004 [Page 8] Internet-Draft Security Threats and Risks for OPES December 2003 2.2.6 Granularity of protection OPES services have implicit permission to modify content. However, the permissions generally apply only to portions of the content, for example, URL's between particular HTML tags, or text in headlines, or URL's matching particular patterns. In order to express such policies, one must be able to refer to portions of messages and to detect modifications to message parts. Because there is currently very little support for policies that are expressed in terms of message parts, it will be difficult to attribute any particular modification to a particular OPES processor, or to automatically detect policy violations. A fine-grained policy language should be devised, and it could be enforced using digital signatures. This would avoid the problems inherent in hop-by-hop data integrity measures (see next section). 2.2.7 Risks of hop-by-hop protection OPES services cannot be applied to data protected with end-to-end encryption methods because, by definition, the decryption key cannot be shared with OPES processors. This means that if the endpoint policies permit OPES services, the data must either be transmitted without confidentiality protections or an alternative model to end-to-end (hop-by-hop) encryption be developed. Extending the end-to-end encryption model is out of scope of this work. In this work security is end-to-end. OPES services cannot be performed if endpoints need security. 2.2.8 Threats to integrity of complex data The OPES system may violate data integrity by applying inconsistent transformations to interrelated data objects or references within the data object. Problems may range from a broken reference structure (modified/missing targets, references to wrong locations or missing documents) to deliberate replacement/deletion/insertion of links that violate intentions of the content provider. 2.2.9 Denial of Service (DoS) The data consumer application may not be able to access data if the OPES system fails for any reason. A malicious or malfunctioning node may be able to block all traffic. The data traffic destined for the OPES processor (or callout server) may not be able to use the services of the OPES device. The DoS may Barbir, et al. Expires June 7, 2004 [Page 9] Internet-Draft Security Threats and Risks for OPES December 2003 be achieved by preventing the data traffic from reaching the processor or the callout server. 2.2.10 Tracing and notification information Inadequate or vulnerable implementation of the tracing and notification mechanisms may defeat safeguards built into the OPES architecture. Tracing and notification facilities may become a target of malicious attack. Such an attack may create problems in discovering and stopping other attacks. The absence of a standard for tracing and notification information may present an additional problem. This information is produced and consumed by the independent entities (OPES servers/user agents/ content provider facilities). This calls for a set of standards related to each base protocol in use. 2.2.11 Unauthenticated Communication in OPES Flow There are risks and threats that could arise from unauthenticated communication between the OPES server and callout servers. Lack of use of strong authentication between OPES processors and callout servers may open security holes whereby DOS and other types of attacks (see sections [2 and 3]) can be performed. Barbir, et al. Expires June 7, 2004 [Page 10] Internet-Draft Security Threats and Risks for OPES December 2003 3. Threats to out-of-band data The OPES architecture separates a data flow from a control information flow (loading rulesets, trust establishment, tracing, policy propagation, etc.). There are certain requirements set for the latter but no specific mechanism is prescribed. This gives more flexibility for implementations but creates more burden for implementers and potential customers to ensure that each specific implementation meets all requirements for data security, entity authentication and action authorization. In addition to performing correct actions on the OPES data flow, any OPES implementation has to provide an adequate mechanism to satisfy requirements for out-of-band data and signaling information integrity. Whatever the specific mechanism may be, it inevitably becomes subject to multiple security threats and possible attacks. The way the threats and attacks may be realized depends on implementation specifics but the resulting harm generally falls into two categories: threats to OPES data flow and threats to data integrity. The specific threats are: 3.1 Threats that endanger the OPES data flow Any weakness in the implementation of a security, authentication, or authorization mechanism may open the door to the attacks described in section 2. An OPES system implementation should address all these threats and prove its robustness and ability to withstand malicious attacks or networking and programming problems. 3.2 Inaccurate Accounting Information Collecting and reporting accurate accounting data may be vital when OPES servers are used to extend a business model of content provider, service provider or as a basis for third party service. Ability to collect and process accounting data is an important part of OPES system functionality. This functionality may be challenged by distortion or destruction of base accounting data (usually logs), processed accounting data, accounting parameters and reporting configuration. As a result a data consumer may be inappropriately charged for viewing content that was not successfully delivered, or a content provider or independent OPES services provider may not be compensated Barbir, et al. Expires June 7, 2004 [Page 11] Internet-Draft Security Threats and Risks for OPES December 2003 for the services performed. OPES system may use accounting information to distribute resources between different consumers or limit resource usage by a specific consumer. In this case an attack on accounting system (by distortion of data or issuing false configuration commands) may result in incorrect resource management and DoS by artificial resource starvation. 3.3 OPES service request repudiation An entity (producer or consumer) makes an authorized request and claim, later, that it did not make that request. As a result an OPES entity may be held liable for unauthorized changes to the data flow, or will be unable to receive compensation for a service. There should be a clear request that this service is required and there should be a clear course of action on the behalf of all parties. This action should have a request, and should have an action, and should have a means of repudiation of the request, and should have a means to specify the effect of the action. 3.4 Inconsistent privacy policy The OPES entities may have privacy policies that are not consistent with the data consumer application or content provider application. Privacy related problems may be further complicated if OPES entities, content providers and end users belong to different jurisdictions with different requirements and different levels of legal protection. As a result the end user may not be aware that he or she does not have the expected legal protection. The content provider may be exposed to legal risks due to a failure to comply with regulation which he is not even aware of. 3.5 Exposure of privacy preferences The OPES system may inadvertently or maliciously expose end user privacy settings and requirements. 3.6 Exposure of security settings There are risks that the OPES system may expose end user security settings when handling the request and responses. The user data must be handled as sensitive system information and protected against accidental and deliberate disclosure. Barbir, et al. Expires June 7, 2004 [Page 12] Internet-Draft Security Threats and Risks for OPES December 2003 3.7 Improper enforcement of privacy and security policy OPES entities are part of the content distribution system and as such take on certain obligations to support security and privacy policies mandated by content producer and/or end user. However there is a danger that these policies are not properly implemented and enforced. The data consumer application may not be aware that its protections are no longer in effect. There is also the possibility of security and privacy leaks due to the accidental misconfiguration or, due to missunderstanding what rules are in effect for a particular user or request. Privacy and security related parts of the systems can be targeted by malicious attacks and ability to withstand such attacks is of paramount importance. 3.8 DOS Attacks DOS attacks can be of various types. One type of DOS attacks can take effect by overloading the client. For example, an intruder can direct an OPES processor to issue numerous responses to a client. There is also additional DOS risk from a rule misconfiguration that would have the OPES processor ignore a data consumer application. Barbir, et al. Expires June 7, 2004 [Page 13] Internet-Draft Security Threats and Risks for OPES December 2003 4. Security Considerations This document discusses multiple security and privacy issues related to the OPES services. Barbir, et al. Expires June 7, 2004 [Page 14] Internet-Draft Security Threats and Risks for OPES December 2003 Normative References [1] A. Barbir et. al, "An Architecture for Open Pluggable Edge Services (OPES)", Internet-Draft: http://www.ietf.org/ internet-drafts/draft-ietf-opes-architecture-04.txt, Aug 2002. [2] A. Barbir et. al, "OPES Use Cases and Deployment Scenarios", Internet-Draft: http://www.ietf.org/ draft-ietf-opes-scenarios-01, July 2002. [3] A. Barbir et. al, "Requirements for Policy, Authorization and Enforcement of OPES Services", Internet-Draft: http:// www.ietf.org/internet- drafts/ draft-ietf-opes-authorization-00.txt , October 2002. Barbir, et al. Expires June 7, 2004 [Page 15] Internet-Draft Security Threats and Risks for OPES December 2003 Informative References [4] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Oskar Batuner Independent consultant EMail: batuner@attbi.com Bindignavile Srinivas Nokia 5 Wayside Road Burlington, MA 01803 USA EMail: bindignavile.srinivas@nokia.com Markus Hofmann Bell Labs/Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US Phone: +1 732 332 5983 EMail: hofmann@bell-labs.com Barbir, et al. Expires June 7, 2004 [Page 16] Internet-Draft Security Threats and Risks for OPES December 2003 Hilarie Orman Purple Streak Development Phone: EMail: ho@alum.mit.edu Barbir, et al. Expires June 7, 2004 [Page 17] Internet-Draft Security Threats and Risks for OPES December 2003 Appendix A. Acknowledgements Many thanks to T. Chan (Nokia) and A. Beck (Lucent) Barbir, et al. Expires June 7, 2004 [Page 18] Internet-Draft Security Threats and Risks for OPES December 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 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 assignees. 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 Barbir, et al. Expires June 7, 2004 [Page 19] Internet-Draft Security Threats and Risks for OPES December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir, et al. Expires June 7, 2004 [Page 20]