idnits 2.17.1 draft-srinivas-opes-threats-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 133 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 30 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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]. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7985 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) -- Missing reference section? 'RFC-2119' on line 37 looks like a reference -- Missing reference section? 'OPES-SCENE' on line 338 looks like a reference -- Missing reference section? 'OPES-CALLOUT' on line 345 looks like a reference -- Missing reference section? 'RFC3238' on line 341 looks like a reference -- Missing reference section? 'MIP-DOS' on line 349 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B.S. Srinivas 3 Internet Draft T. Chan 4 Expires: December 2002 Nokia 5 File: draft-srinivas-opes-threats-00.txt 6 June 2002 8 Security Threats and Risks for Open Pluggable Edge Services 10 draft-srinivas-opes-threats-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as ``work in 24 progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Conventions used in this document 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 36 this document are to be interpreted as described in [RFC-2119]. 38 1. Abstract 40 This Internet Draft is an attempt to define the security threats 41 against the OPES protocol. In addition to the threats, the effects 42 of such security threats on the underlying architecture as well as 43 the requirements of a security solution to mitigate such threats are 44 discussed. The threats and requirements identified herein and the 45 document should be considered as work in progress. 47 2. Introduction 49 The data stream flowing between a content provider and one or more 50 content consumers may be in need of modifications as a function of 51 the needs of the consumer, the constraints of her/his device, 52 her/his geographical location and numerous other factors. These 53 modifications to the traditional scenario (see Figure 1) are 54 engineered by means of other application entities. The functions 55 that we have in mind include language translation, virus scanning, 56 bit-rate reduction in compliance with limited bandwidth 57 availability, and many others (see Figure 2). 59 ------------ ------------ 60 | | /----------------\ | | 61 | Content | \ / \ \ | Content | 62 | Provider |--------/ IP \----------| Consumer | 63 | | / \ Network / / | | 64 ------------ \ / ------------ 65 \----------------/ 67 Figure 1: Traditional non-OPES scenario 69 ------------ 70 | | 71 | Content | 72 | Provider | 73 | | 74 ------------ 75 | | 76 | 77 /-|- -|----\ 78 / | \ 79 --------/ | | \---| 80 | | | 81 | IP n/w | | | ------------ 82 | ---------------| | | Callout | 83 | | OPES | |---------------------| Server | 84 | | Intermediary | |- - - - - - - - - - -| | 85 | | | | ------------ 86 | ---------------- | 87 | | | | 88 --------\ | /----- 89 \ | | / 90 \-|------/ 91 | | ------ Content flow 92 ------------ - - - Signaling flow 93 | | 94 | Content | 95 | Consumer | 96 | | 97 ------------ 99 Figure 2:OPES Network Architecture 100 Either the application entities, referred to in the preceding text, 101 may be collocated with either of the two ends of the data stream or 102 it may be a discrete entity situated elsewhere within the network. 103 The last scenario comprises a data stream scenario, which is 104 referred to as Open Pluggable Edge Services (OPES). Several such 105 provisioning scenarios are described in [OPES-SCENE]. 107 The document discusses several additional security threats, which 108 the data stream might be exposed to owing to the presence of a 109 discrete entity, the OPES intermediary (and call-out servers [OPES- 110 CALLOUT], if any), that provides the needed modification services. 111 Here by data stream, we imply both the content stream as well as the 112 signaling stream (to indicate the desired transformation). As 113 illustrated in Figure 2, the content stream flows from the content 114 provider to the OPES intermediary, which may further be forwarded to 115 a call-out server and returned, then finally delivered to the 116 content consumer after all the desired transformations are 117 performed. The signaling information (or transformation requests) 118 can originate from either the Content provider or consumer. 119 Moreover, the OPES intermediary may send transformation requests to 120 call-out servers as well. Attacks related to the signaling stream 121 and content stream may have different results and need to be 122 considered separately. 124 New functionality when added to a networking architecture invariably 125 creates new possibilities for tampering with some signaling 126 communications, as well as user data traffic. In other words, 127 various forms of protection including physical and/or programmatic 128 means are lowered, resulting in new security vulnerabilities. In 129 addition to the threats, the document also presents the impacts of 130 these threats as well as the requirements of the security solutions 131 to mitigate such threats. 133 Notice that the security threats corresponding to a content/services 134 delivery system without an OPES intermediary, as depicted in Figure 135 1, is considered out-of-scope and therefore will not be discussed in 136 this document. This document only focuses on threats that are 137 introduced by the existence of the OPES intermediary and call-out 138 servers. 140 The document is organized as follows: Section 3 discusses the 141 security threats introduced by the OPES functionality. Section 4 142 discusses the Intellectual Property rights issues if any. 144 3. Threats 146 With the incorporation of an additional application entity namely 147 the OPES intermediary, despite its operation on the data flow 148 between the content producer and consumer being authorized, a new 149 site for exposure to threats from malicious entities is introduced. 150 A whole array of threats, their effects and the suggested security 151 solutions are discussed herein. The threats discussed are congruent 152 with the security considerations raised in [RFC3238]. 154 In the traditional non-OPES scenario, the communicating end-points 155 (the content producer and consumer) have a direct one-to-one 156 association between them (see Figure 1). This direct association is 157 broken by the existence of OPES intermediaries or callout servers. 158 The secure operation of protocols, typically, depends on assumptions 159 regarding the identity of the endpoints and the continuity of 160 communication between them. The operation of OPES itself has 161 security implications and risks. 163 3.1. OPES device false registration/deregistration 165 Threat: In the event of the OPES intermediary being absent, a false 166 registration / deregistration could be sent by a malicious node on 167 behalf of the non-existent OPES intermediary. 169 Effect: A false registration / deregistration would result in the 170 end-system traffic being hijacked by the malicious node. The traffic 171 is then eavesdropped on by the attacker. Moreover, unwanted or 172 malicious transformation of the data traffic would occur. 173 Alternatively, the malicious node may simply refuse to forward the 174 data traffic to the content consumer, resulting in a Denial-of- 175 Service attack. 177 Solution: Either of the end-points MUST authenticate and authorize 178 the OPES intermediary before directing any traffic to it. The 179 content consumer MUST NOT accept any (modified) traffic, which has 180 been transformed by an unauthenticated or unauthorized entity. 182 3.2. OPES device spoofing 184 Threat: A malicious node could send false information about an 185 intermediate device masquerading as an OPES device. Alternatively, 186 despite the presence of a genuine OPES device which has been 187 authenticated, the actual data transformation could be performed in 188 a malicious call-out server. 189 Effect: Similar to the previous case, the malicious device would be 190 able to eavesdrop on all traffic (both data and signaling) between 191 the end-systems. In addition, unexpected and undesirable data 192 transformation by the malicious intermediary or call-out server 193 would result. For example, the malicious node could force the 194 consumer or producer to use the services of a malicious OPES 195 intermediary, which renders very expensive transformation services. 196 Finally, a malicious OPES intermediary may refuse to forward the 197 traffic, resulting in a Denial-of-Service attack. 199 Solution: The OPES intermediary device and the associated call-out 200 server (if any) MUST be authenticated and authorized before any 201 messages are sent through it. Notice that the transformation MAY 202 require more than one call-out server, in which case, all of them 203 need to be authenticated. 205 3.3. Malicious node performs a replay attack 207 Threat: A malicious node could passively eavesdrop on one of the 208 communication channels and replay the recorded message (signaling or 209 data) later. The signaling request from either the producer or the 210 consumer to the OPES intermediary is open to such a kind of replay 211 attack. Alternatively, a malicious nodethat serves as the OPES 212 intermediary for two distinct data flows could replay the message 213 from one data flow onto another. 215 Effect: False or spurious action is performed by the OPES device or 216 call-out server. A false transformation could be performed by the 217 OPES device by replaying a transformation request issued by the 218 consumer on a previous occasion. In addition, the transformed 219 content could be replayed to the consumer as genuine content. 221 Solution: Care, in the form of sequence numbers, or other 222 techniques, MUST be taken to prevent replay attacks. Authentication 223 of OPES intermediaries is required such that malicious OPES devices 224 will not be used, thereby reducing the possibility of content 225 replay. 227 3.4. Re-establishing end-device - OPES device security during failover 229 Threat: End-device (producer or consumer) fails over from OPES 230 intermediary A to OPES intermediary B. A trust relationship between 231 the end-device and A will not automatically translate into the same 232 relationship existing between the end-device and B. 234 Effect: If there was a trust relationship involving a security 235 context between the end-device and A, the equivalent trust 236 relationship between the end-device and B will not exist in the 237 event of a failover from A to B. The assumption of such a trust 238 relationship opens up security holes for malicious OPES 239 intermediaries to perform all kinds of attacks. 241 Solution: Either notify the application when failover occurs so that 242 the application MAY take appropriate action to establish a trust 243 relationship between the end-device and B or reestablish the 244 security context transparently. 246 3.5. Message Integrity 248 Threat: Message flow through the OPES device is corrupted. By being 249 corrupted, the implication is that, a message, which has been 250 subject to unauthorized modification prior to the OPES intermediary, 251 is inputted into the OPES intermediary (or call-out server). The 252 modification can be on the signaling information related to the 253 actions the OPES device needs to perform; or it can be on the 254 contents that need to be transformed. 256 Effect: Corrupted information is received which causes the OPES 257 device to either transform the content in a wrong way, or transform 258 the wrong content, generating a wrong output. 260 Solution: Integrity mechanism is needed to protect both the actions 261 specified as well as the contents of all the OPES messages. These 262 could include hashing functions, for instance. 264 3.6. Data Confidentiality 266 Threat: An eavesdropper is typically capable of snooping on fields 267 within messages in transit. Using various eavesdropping techniques, 268 he may be able to garner various kinds of information including 269 topology/location/IP addresses etc. that may not be desirable to 270 divulge. He also may be able to eavesdrop on the content messages 271 being delivered to the consumer. The delivery of the shared 272 encryption keys to the OPES intermediary is subject to the threat of 273 being eavesdropped on by a malicious entity. 275 Effect: Information that session participants or an administrator do 276 not wish to divulge is divulged. If shared encryption keys are 277 compromised during key distribution, attackers will be able to 278 decrypt encrypted content. 279 Solution: Data confidentiality service MUST be provisioned using 280 various kinds of encryption. This could be carried out using either 281 a shared key or PKI, for instance. Special care needs to be taken in 282 the delivery of the key information to the OPES intermediary and the 283 callout server (if present). 285 3.7. Denial-of-Service (DoS) 287 Threat: A hostile or malicious node MAY be able to block all traffic 288 on an unprotected link. The data traffic destined for the OPES 289 intermediary (or call-out server) MAY NOT be able to use the 290 services of the OPES device. The DoS MAY be achieved by preventing 291 the data traffic from reaching the intermediary or the call-out 292 server. Alternatively, the intermediary or the call-out server can 293 be overloaded by spurious service requests issued by a malicious 294 node, which denies the legal data traffic the necessary resources to 295 render service. The resources include CPU cycles, memory, network 296 interfaces, etc. In addition, a malicious node that successfully 297 spoofs as an OPES intermediary (or call-out server) can launch DoS 298 attacks simply by not forwarding the legitimate traffic to the 299 content consumers. A Denial-of-Service attack can be selective, 300 generic or random in terms of which communication streams are 301 affected [MIP-DOS]. 303 Distributed DoS is also possible when an attacker successfully 304 directs multiple nodes over the network to initiate spurious service 305 requests to an OPES intermediary (or call-out server) simultaneously 306 MIP-DOS]. 308 Effect: Legal data traffic is unable to acquire the services of the 309 OPES intermediary (or call-out server) to achieve the desired 310 transformation. 312 Solution: Malicious data traffic emanating from particular suspect 313 ports or IP addresses SHOULD be denied access to the OPES 314 intermediary. 316 3.8.Authorized entity later repudiates a request 318 Threat: An entity (producer or consumer) that is authorized to make 319 a certain request of the OPES intermediary claims, later, that it 320 did not make that request. 322 Effect: The entity that repudiates a valid request for 323 transformation by the OPES intermediary MAY be held liable for asked 324 for changes to the data flow. 326 Requirement: Non-repudiation of requests for transformation of a 327 data flow by an OPES intermediary or a call-out server needs to be 328 provided. This could be accomplished by, for instance, use of 329 private keys in encrypting the request for a transformation service. 331 4. Intellectual Property Rights 333 The authors are not aware of any intellectual property right issues 334 pertaining to this document. 336 5. References 338 [OPES-SCENE] McHenry, S., et. al, "OPES Scenarios and Use Cases", 339 Internet-Draft TBD, May 2002. 341 [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy 342 Considerations for Open Pluggable Edge Services", RFC 343 3238, January 2002. 345 [OPES-CALLOUT] Beck, A., et. al, "Requirements for OPES Callout 346 Protocols," work in progress, May 2002, . 349 [MIP-DOS] Nikander, P., et. al, "Threat Models introduced by Mobile 350 IPv6 and Requirements for Security in Mobile IPv6", work in progress, 351 December 2001, . 353 6. Authors' Addresses 355 Bindignavile S. Srinivas 356 Tat Chan 358 Nokia Research Center 359 5 Wayside Road 360 Burlington, MA 01803 361 USA 363 Email: {bindignavile.srinivas,tat.chan}@nokia.com 365 1. Abstract........................................................1 366 2. Introduction....................................................2 367 3. Threats.........................................................3 368 3.1. OPES device false registration/deregistration..............4 369 3.2. OPES device spoofing.......................................4 370 3.3. Malicious node performs a replay attack....................5 371 3.4. Re-establishing end-device - OPES device security during 372 failover........................................................5 373 3.5. Message Integrity..........................................5 374 3.6. Data Confidentiality.......................................6 375 3.7. Denial-of-Service (DoS)....................................6 376 3.8. Authorized entity later repudiates a request...............7 377 4. Intellectual Property Rights....................................7 378 5. References......................................................7 379 6. Authors' Addresses..............................................7 380 Full Copyright Statement...........................................8 382 Full Copyright Statement 384 Copyright (C) The Internet Society (2002). All Rights Reserved. 385 This document and translations of it may be copied and furnished to 386 others, and derivative works that comment on or otherwise explain it 387 or assist in its implementation may be prepared, copied, published 388 and distributed, in whole or in part, without restriction of any 389 kind, provided that the above copyright notice and this paragraph 390 are included on all such copies and derivative works. However, this 391 document itself may not be modified in any way, such as by removing 392 the copyright notice or references to the Internet Society or other 393 Internet organizations, except as needed for the purpose of 394 developing Internet standards in which case the procedures for 395 copyrights defined in the Internet Standards process must be 396 followed, or as required to translate it into languages other than 397 English. 399 The limited permissions granted above are perpetual and will not be 400 revoked by the Internet Society or its successors or assigns. 402 This document and the information contained herein is provided on an 403 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 404 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 405 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 406 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 407 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 409 Acknowledgement 410 Funding for the RFC Editor function is currently provided by the 411 Internet Society.