Network Working Group B.S. Srinivas Internet Draft T. Chan Expires: December 2002 Nokia File: draft-srinivas-opes-threats-00.txt June 2002 Security Threats and Risks for Open Pluggable Edge Services draft-srinivas-opes-threats-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. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 1. Abstract This Internet Draft is an attempt to define the security threats against the OPES protocol. In addition to the threats, the effects of such security threats on the underlying architecture as well as the requirements of a security solution to mitigate such threats are discussed. The threats and requirements identified herein and the document should be considered as work in progress. Internet Draft Security Threats for OPES June 2002 2. Introduction The data stream flowing between a content provider and one or more content consumers may be in need of modifications as a function of the needs of the consumer, the constraints of her/his device, her/his geographical location and numerous other factors. These modifications to the traditional scenario (see Figure 1) are engineered by means of other application entities. The functions that we have in mind include language translation, virus scanning, bit-rate reduction in compliance with limited bandwidth availability, and many others (see Figure 2). ------------ ------------ | | /----------------\ | | | Content | \ / \ \ | Content | | Provider |--------/ IP \----------| Consumer | | | / \ Network / / | | ------------ \ / ------------ \----------------/ Figure 1: Traditional non-OPES scenario ------------ | | | Content | | Provider | | | ------------ | | | /-|- -|----\ / | \ --------/ | | \---| | | | | IP n/w | | | ------------ | ---------------| | | Callout | | | OPES | |---------------------| Server | | | Intermediary | |- - - - - - - - - - -| | | | | | ------------ | ---------------- | | | | | --------\ | /----- \ | | / \-|------/ | | ------ Content flow ------------ - - - Signaling flow | | | Content | | Consumer | | | ------------ Figure 2:OPES Network Architecture Srinivas, Chan Expires December 2002 [Page 2] Internet Draft Security Threats for OPES June 2002 Either the application entities, referred to in the preceding text, may be collocated with either of the two ends of the data stream or it may be a discrete entity situated elsewhere within the network. The last scenario comprises a data stream scenario, which is referred to as Open Pluggable Edge Services (OPES). Several such provisioning scenarios are described in [OPES-SCENE]. The document discusses several additional security threats, which the data stream might be exposed to owing to the presence of a discrete entity, the OPES intermediary (and call-out servers [OPES- CALLOUT], if any), that provides the needed modification services. Here by data stream, we imply both the content stream as well as the signaling stream (to indicate the desired transformation). As illustrated in Figure 2, the content stream flows from the content provider to the OPES intermediary, which may further be forwarded to a call-out server and returned, then finally delivered to the content consumer after all the desired transformations are performed. The signaling information (or transformation requests) can originate from either the Content provider or consumer. Moreover, the OPES intermediary may send transformation requests to call-out servers as well. Attacks related to the signaling stream and content stream may have different results and need to be considered separately. New functionality when added to a networking architecture invariably creates new possibilities for tampering with some signaling communications, as well as user data traffic. In other words, various forms of protection including physical and/or programmatic means are lowered, resulting in new security vulnerabilities. In addition to the threats, the document also presents the impacts of these threats as well as the requirements of the security solutions to mitigate such threats. Notice that the security threats corresponding to a content/services delivery system without an OPES intermediary, as depicted in Figure 1, is considered out-of-scope and therefore will not be discussed in this document. This document only focuses on threats that are introduced by the existence of the OPES intermediary and call-out servers. The document is organized as follows: Section 3 discusses the security threats introduced by the OPES functionality. Section 4 discusses the Intellectual Property rights issues if any. 3. Threats With the incorporation of an additional application entity namely the OPES intermediary, despite its operation on the data flow between the content producer and consumer being authorized, a new site for exposure to threats from malicious entities is introduced. A whole array of threats, their effects and the suggested security solutions are discussed herein. The threats discussed are congruent with the security considerations raised in [RFC3238]. Srinivas, Chan Expires December 2002 [Page 3] Internet Draft Security Threats for OPES June 2002 In the traditional non-OPES scenario, the communicating end-points (the content producer and consumer) have a direct one-to-one association between them (see Figure 1). This direct association is broken by the existence of OPES intermediaries or callout servers. The secure operation of protocols, typically, depends on assumptions regarding the identity of the endpoints and the continuity of communication between them. The operation of OPES itself has security implications and risks. 3.1. OPES device false registration/deregistration Threat: In the event of the OPES intermediary being absent, a false registration / deregistration could be sent by a malicious node on behalf of the non-existent OPES intermediary. Effect: A false registration / deregistration would result in the end-system traffic being hijacked by the malicious node. The traffic is then eavesdropped on by the attacker. Moreover, unwanted or malicious transformation of the data traffic would occur. Alternatively, the malicious node may simply refuse to forward the data traffic to the content consumer, resulting in a Denial-of- Service attack. Solution: Either of the end-points MUST authenticate and authorize the OPES intermediary before directing any traffic to it. The content consumer MUST NOT accept any (modified) traffic, which has been transformed by an unauthenticated or unauthorized entity. 3.2. OPES device spoofing Threat: A malicious node could send false information about an intermediate device masquerading as an OPES device. Alternatively, despite the presence of a genuine OPES device which has been authenticated, the actual data transformation could be performed in a malicious call-out server. Effect: Similar to the previous case, the malicious device would be able to eavesdrop on all traffic (both data and signaling) between the end-systems. In addition, unexpected and undesirable data transformation by the malicious intermediary or call-out server would result. For example, the malicious node could force the consumer or producer to use the services of a malicious OPES intermediary, which renders very expensive transformation services. Finally, a malicious OPES intermediary may refuse to forward the traffic, resulting in a Denial-of-Service attack. Solution: The OPES intermediary device and the associated call-out server (if any) MUST be authenticated and authorized before any messages are sent through it. Notice that the transformation MAY Srinivas, Chan Expires December 2002 [Page 4] Internet Draft Security Threats for OPES June 2002 require more than one call-out server, in which case, all of them need to be authenticated. 3.3. Malicious node performs a replay attack Threat: A malicious node could passively eavesdrop on one of the communication channels and replay the recorded message (signaling or data) later. The signaling request from either the producer or the consumer to the OPES intermediary is open to such a kind of replay attack. Alternatively, a malicious nodethat serves as the OPES intermediary for two distinct data flows could replay the message from one data flow onto another. Effect: False or spurious action is performed by the OPES device or call-out server. A false transformation could be performed by the OPES device by replaying a transformation request issued by the consumer on a previous occasion. In addition, the transformed content could be replayed to the consumer as genuine content. Solution: Care, in the form of sequence numbers, or other techniques, MUST be taken to prevent replay attacks. Authentication of OPES intermediaries is required such that malicious OPES devices will not be used, thereby reducing the possibility of content replay. 3.4. Re-establishing end-device - OPES device security during failover Threat: End-device (producer or consumer) fails over from OPES intermediary A to OPES intermediary B. A trust relationship between the end-device and A will not automatically translate into the same relationship existing between the end-device and B. Effect: If there was a trust relationship involving a security context between the end-device and A, the equivalent trust relationship between the end-device and B will not exist in the event of a failover from A to B. The assumption of such a trust relationship opens up security holes for malicious OPES intermediaries to perform all kinds of attacks. Solution: Either notify the application when failover occurs so that the application MAY take appropriate action to establish a trust relationship between the end-device and B or reestablish the security context transparently. 3.5. Message Integrity Threat: Message flow through the OPES device is corrupted. By being corrupted, the implication is that, a message, which has been subject to unauthorized modification prior to the OPES intermediary, is inputted into the OPES intermediary (or call-out server). The modification can be on the signaling information related to the actions the OPES device needs to perform; or it can be on the contents that need to be transformed. Srinivas, Chan Expires December 2002 [Page 5] Internet Draft Security Threats for OPES June 2002 Effect: Corrupted information is received which causes the OPES device to either transform the content in a wrong way, or transform the wrong content, generating a wrong output. Solution: Integrity mechanism is needed to protect both the actions specified as well as the contents of all the OPES messages. These could include hashing functions, for instance. 3.6. Data Confidentiality Threat: An eavesdropper is typically capable of snooping on fields within messages in transit. Using various eavesdropping techniques, he may be able to garner various kinds of information including topology/location/IP addresses etc. that may not be desirable to divulge. He also may be able to eavesdrop on the content messages being delivered to the consumer. The delivery of the shared encryption keys to the OPES intermediary is subject to the threat of being eavesdropped on by a malicious entity. Effect: Information that session participants or an administrator do not wish to divulge is divulged. If shared encryption keys are compromised during key distribution, attackers will be able to decrypt encrypted content. Solution: Data confidentiality service MUST be provisioned using various kinds of encryption. This could be carried out using either a shared key or PKI, for instance. Special care needs to be taken in the delivery of the key information to the OPES intermediary and the callout server (if present). 3.7. Denial-of-Service (DoS) Threat: A hostile or malicious node MAY be able to block all traffic on an unprotected link. The data traffic destined for the OPES intermediary (or call-out server) MAY NOT be able to use the services of the OPES device. The DoS MAY be achieved by preventing the data traffic from reaching the intermediary or the call-out server. Alternatively, the intermediary or the call-out server can be overloaded 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. In addition, a malicious node that successfully spoofs as an OPES intermediary (or call-out server) can launch DoS attacks simply by not forwarding the legitimate traffic to the content consumers. A Denial-of-Service attack can be selective, generic or random in terms of which communication streams are affected [MIP-DOS]. Distributed DoS is also possible when an attacker successfully directs multiple nodes over the network to initiate spurious service requests to an OPES intermediary (or call-out server) simultaneously MIP-DOS]. Srinivas, Chan Expires December 2002 [Page 6] Internet Draft Security Threats for OPES June 2002 Effect: Legal data traffic is unable to acquire the services of the OPES intermediary (or call-out server) to achieve the desired transformation. Solution: Malicious data traffic emanating from particular suspect ports or IP addresses SHOULD be denied access to the OPES intermediary. 3.8.Authorized entity later repudiates a request Threat: An entity (producer or consumer) that is authorized to make a certain request of the OPES intermediary claims, later, that it did not make that request. Effect: The entity that repudiates a valid request for transformation by the OPES intermediary MAY be held liable for asked for changes to the data flow. Requirement: Non-repudiation of requests for transformation of a data flow by an OPES intermediary or a call-out server needs to be provided. This could be accomplished by, for instance, use of private keys in encrypting the request for a transformation service. 4. Intellectual Property Rights The authors are not aware of any intellectual property right issues pertaining to this document. 5. References [OPES-SCENE] McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet-Draft TBD, May 2002. [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [OPES-CALLOUT] Beck, A., et. al, "Requirements for OPES Callout Protocols," work in progress, May 2002, . [MIP-DOS] Nikander, P., et. al, "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", work in progress, December 2001, . 6. Authors' Addresses Bindignavile S. Srinivas Tat Chan Nokia Research Center Srinivas, Chan Expires December 2002 [Page 7] Internet Draft Security Threats for OPES June 2002 5 Wayside Road Burlington, MA 01803 USA Email: {bindignavile.srinivas,tat.chan}@nokia.com 1. Abstract........................................................1 2. Introduction....................................................2 3. Threats.........................................................3 3.1. OPES device false registration/deregistration..............4 3.2. OPES device spoofing.......................................4 3.3. Malicious node performs a replay attack....................5 3.4. Re-establishing end-device - OPES device security during failover........................................................5 3.5. Message Integrity..........................................5 3.6. Data Confidentiality.......................................6 3.7. Denial-of-Service (DoS)....................................6 3.8. Authorized entity later repudiates a request...............7 4. Intellectual Property Rights....................................7 5. References......................................................7 6. Authors' Addresses..............................................7 Full Copyright Statement...........................................8 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Acknowledgement Srinivas, Chan Expires December 2002 [Page 8] Internet Draft Security Threats for OPES June 2002 Funding for the RFC Editor function is currently provided by the Internet Society. Srinivas, Chan Expires December 2002 [Page 9]