idnits 2.17.1 draft-ietf-rmt-sec-discussion-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1079. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1085. 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 : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (July 2, 2007) is 6137 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) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 3450 (Obsoleted by RFC 5775) ** Obsolete normative reference: RFC 3452 (Obsoleted by RFC 5052, RFC 5445) ** Obsolete normative reference: RFC 3926 (Obsoleted by RFC 6726) ** Obsolete normative reference: RFC 3940 (Obsoleted by RFC 5740) ** Downref: Normative reference to an Experimental RFC: RFC 4654 Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMT B. Adamson 3 Internet-Draft Naval Research Laboratory 4 Intended status: Standards Track V. Roca 5 Expires: January 3, 2008 INRIA 6 July 2, 2007 8 Security and Reliable Multicast Transport Protocols: Discussions and 9 Guidelines 10 draft-ietf-rmt-sec-discussion-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 3, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes some security risks of the Reliable Multicast 44 Transport (RMT) Working Group set of building blocks and protocols. 45 An emphasis is placed on risks that might be resolved in the scope of 46 transport protocol design. However, relevant security issues related 47 to IP Multicast control-plane and other concerns not strictly within 48 the scope of reliable transport protocol design are also discussed. 50 The document also begins an exploration of approaches that could be 51 embraced to mitigate these risks. The purpose of this document is to 52 provide a consolidated security discussion and provide a basis for 53 further discussion and potential resolution of any significant 54 security issues that may exist in the current set of RMT standards. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Conventions Used in this Document . . . . . . . . . . . . 5 60 1.2. Terminology and Notations . . . . . . . . . . . . . . . . 5 61 2. Quick Introduction to RMT Protocols and their Use . . . . . . 5 62 2.1. The Two Families of CDP . . . . . . . . . . . . . . . . . 5 63 2.2. RMT Protocol Specificities . . . . . . . . . . . . . . . . 5 64 2.3. Target Use Case Specificities . . . . . . . . . . . . . . 6 65 3. Known Security Threats . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Control-Plane Attacks . . . . . . . . . . . . . . . . . . 8 67 3.1.1. Control Plane Monitoring . . . . . . . . . . . . . . . 8 68 3.1.2. Unauthorized (or Malicious) Group Membership . . . . . 8 69 3.2. Data-Plane Attacks . . . . . . . . . . . . . . . . . . . . 9 70 3.2.1. Rogue Traffic Generation . . . . . . . . . . . . . . . 10 71 3.2.2. Sender Message Spoofing . . . . . . . . . . . . . . . 10 72 3.2.3. Receiver Message Spoofing . . . . . . . . . . . . . . 11 73 3.2.4. Replay Attacks . . . . . . . . . . . . . . . . . . . . 11 74 4. General Security Goals . . . . . . . . . . . . . . . . . . . . 12 75 4.1. Network Protection . . . . . . . . . . . . . . . . . . . . 13 76 4.2. Protocol Protection . . . . . . . . . . . . . . . . . . . 13 77 4.3. Content Protection . . . . . . . . . . . . . . . . . . . . 13 78 5. Elementary Security Services . . . . . . . . . . . . . . . . . 13 79 6. Technological Building Blocks . . . . . . . . . . . . . . . . 15 80 6.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 6.1.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 15 82 6.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 16 83 6.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 16 84 6.2. Use of TESLA within RMT . . . . . . . . . . . . . . . . . 17 85 6.2.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 17 86 6.2.2. Requirements . . . . . . . . . . . . . . . . . . . . . 17 87 6.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 17 88 6.3. Use of Group MAC within CDP . . . . . . . . . . . . . . . 18 89 6.3.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 18 90 6.3.2. Requirements . . . . . . . . . . . . . . . . . . . . . 18 91 6.3.3. Limitations . . . . . . . . . . . . . . . . . . . . . 18 92 6.4. Use of Digital Signatures within CDP . . . . . . . . . . . 18 93 6.4.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 18 94 6.4.2. Requirements . . . . . . . . . . . . . . . . . . . . . 19 95 6.4.3. Limitations . . . . . . . . . . . . . . . . . . . . . 19 96 6.5. SSM Multicast Routing . . . . . . . . . . . . . . . . . . 19 97 6.5.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 19 98 6.5.2. Requirements . . . . . . . . . . . . . . . . . . . . . 20 99 6.5.3. Limitations . . . . . . . . . . . . . . . . . . . . . 20 100 6.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 7. Global Security Infrastructure . . . . . . . . . . . . . . . . 20 102 7.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 21 103 7.1.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 21 104 7.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 21 105 7.1.3. Limitations . . . . . . . . . . . . . . . . . . . . . 21 106 7.2. Group Key Management and Re-keying Protocols . . . . . . . 21 107 7.2.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . 21 108 7.2.2. Requirements . . . . . . . . . . . . . . . . . . . . . 21 109 7.2.3. Limitations . . . . . . . . . . . . . . . . . . . . . 21 110 8. New Threats Introduced by the Security Scheme Itself . . . . . 21 111 9. Consequences for the RMT and MSEC Working Group . . . . . . . 21 112 9.1. RMT Transport Message Security Encapsulation Header . . . 21 113 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 114 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 115 12. Normative References . . . . . . . . . . . . . . . . . . . . . 22 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 117 Intellectual Property and Copyright Statements . . . . . . . . . . 24 119 1. Introduction 121 The Reliable Multicast Transport (RMT) Working Group has produced a 122 set of building blocks (BB) and protocol instantiation (PI) 123 specifications for reliable multicast data transport. The two PIs 124 defined within the scope of RMT: ALC 125 [RFC3450][draft-ietf-rmt-pi-alc-revised] and NORM [RFC3940], as well 126 as the FLUTE application [RFC3926] built on top of ALC, are "Content 127 Delivery Protocols" (CDP). In this document the term CDP will refer 128 indifferently to either ALC or NORM, with their associated BBs. 130 The use of these BBs and PIs raises new security risks. For 131 instance, these protocols share a novel set of Forward Error 132 Correction (FEC) and congestion control building blocks that present 133 some new capabilities for Internet transport, but may also pose some 134 new security risks. Yet some security risks are not related to the 135 particular BBs used by the PIs, but are more general. Reliable 136 multicast transport sessions are expected to involve at least one 137 sender and multiple receivers. Thus, the risk of and avenues to 138 attack are implicitly greater than that of point-to-point (unicast) 139 transport sessions. Also the nature of IP multicast can expose other 140 coexistent network flows and services to risk if malicious users 141 exploit it. The classic any-source multicast (ASM) model of 142 multicast routing allows any host to join an IP multicast group and 143 send traffic to that group. This poses many potential security 144 challenges. And, while the emerging single-source multicast (SSM) 145 model that allows only a single sender to send traffic to a group 146 simplifies some challenges, there remain some specific issues. For 147 instance, possible areas of attack include those against the control 148 plane where malicious hosts join IP multicast groups to cause 149 multicast traffic to be directed to parts of the network where it is 150 not needed or desired. This can indirectly cause denial-of-service 151 (DoS) to other network flows. Also, attackers may transmit erroneous 152 or corrupt messages to the group or employ strategies such as replay 153 attack within the "data plane" of protocol operation. 155 The goals of this document are therefore: 157 1. to define the possible general security goals. Defining what we 158 want to protect, i.e. the network itself, and/or the protocol, 159 and/or the content, is the first step. 161 2. to list the possible elementary security services that will make 162 it possible to fulfill the general security goals. Some of these 163 services are generic (e.g. object and/or packet integrity), while 164 others are specific to RMT protocols (e.g. congestion control 165 specific security schemes). 167 3. to list some technological building blocks and solutions that can 168 provide the desired security services. 170 4. last but not least, to highlight the CDP specificities that will 171 impact security and define some use-cases. Indeed, the set of 172 solutions proposed to fulfill the security goals will greatly be 173 impacted by the target use case. 175 In some cases, the existing RMT documents already discuss the risks 176 and outline approaches to solve them, at least partially. The 177 purpose of this document is to consolidate this content and provide a 178 basis for further discussion and potential resolution of any 179 significant security issues that may exist. 181 1.1. Conventions Used in this Document 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. 187 1.2. Terminology and Notations 189 2. Quick Introduction to RMT Protocols and their Use 191 2.1. The Two Families of CDP 193 TODO: a quick introduction to the two families of solutions: ALC/LCT 194 and NORM. 196 2.2. RMT Protocol Specificities 198 This section focuses on the RMT protocol specificities that will 199 impact the choice of the technological building blocks, and the way 200 they can be applied. 202 Both ALC and NORM have been designed with scalability in mind (in 203 terms of the number of receivers). Yet if ALC targets massively 204 scalable sessions (e.g. with millions of receivers), NORM is less 205 ambitious, essentially because of the use of feedback messages to the 206 source. Ideally, the use of security mechanisms should not break 207 this scalability feature. 209 The ALC and NORM protocols differ in the communication paths: 211 o sender to receivers: ALC and NORM, for bulk data transfer and 212 signaling messages; 214 o receivers to sender: NORM only, for feedback messages; 216 o receivers to receivers: NORM only for control messages; 218 But the fact that ALC is capable of working on top of purely 219 unidirectional networks does not mean that no back-channel will be 220 available (see Section 2.3). 222 ALC defines an on-demand content delivery model where receivers can 223 arrive at any time, at their own discretion, download the content and 224 leave the session. This delivery model is not supported by NORM The 225 push and streaming content delivery models are supported by both ALC 226 and NORM. 228 2.3. Target Use Case Specificities 230 This section focuses on the target use cases and their specificities. 231 These specificities will impact both the choice of the technological 232 building blocks and the way they can be applied. One can distinguish 233 the following use case features: 235 o Purely unidirectional transport versus symmetric bidirectional 236 transport versus asymmetric bidirectional transport. Most of the 237 time, the amount of traffic flowing to the source is limited, and 238 one can overlook whether the transport channel is symmetric or 239 not. The nature of the underlying transport channel is of 240 paramount importance, since many security building blocks will 241 require a bidirectional communication; 243 o Massively scalable versus moderately scalable session. Here we do 244 not define precisely what the terms "massively scalable" and 245 "moderately scalable" mean. 247 o Known set of receivers versus unknown set of receivers: does the 248 source know at any point of time the set of receivers or not? Of 249 course, knowing the set of receivers is usually not compatible 250 with massively scalable sessions; 252 o Dynamic set of receivers versus fixed set of receivers: does the 253 source know at some point of time the maximum set of receivers or 254 will it evolve dynamically? In case of a dynamic set of 255 receivers, the source might desire to provide 257 o High rate data flow versus small rate data flow: some security 258 building blocks are CPU intensive and are therefore incompatible 259 with high data rate sessions (e.g. this is the case of solutions 260 that digitally sign all the packets sent). 262 o Protocol stack available at both ends: a solution that requires 263 some non-usual features within the protocol stack will not always 264 be usable. Some target environments (e.g. embedded systems) only 265 provide a minimum set of features and extending them (e.g. to add 266 IPsec) is not necessarily realistic; 268 o Multicast routing and other layer-3 protocols in use: for 269 instance, SSM multicast routing is often seen as one of the key 270 service to improve the security within multicast sessions, and 271 some security building blocks require specialized versions of 272 layer-3 protocols (e.g. IGMP/MLD with security extensions). 273 Depending on the target use case, these assumptions might or not 274 be realistic; 276 o (TBD) more items? 278 Depending on the target goal and the associated security building 279 block used, other features, related to the use case, might be of 280 importance. For instance TESLA requires a loose time synchronization 281 between the source and the receivers. Several possibilities exist to 282 that purpose, some of them being only feasible if the target use case 283 provides the appropriate features. 285 3. Known Security Threats 287 Reliable multicast transport sessions are expected to involve at 288 least one sender and multiple receivers. Thus, the risk of and 289 avenues to attack are implicitly greater than that of point-to-point 290 (unicast) transport sessions. Also the nature of IP multicast can 291 expose other coexistent network flows and services to risk if 292 malicious users exploit it. The classic any-source multicast (ASM) 293 model of multicast routing allows any host to join an IP multicast 294 group and send traffic to that group. This poses many potential 295 security challenges. And, while the emerging single-source multicast 296 (SSM) model that allows only a single sender to send traffic to a 297 group simplifies some challenges, there remain some specific issues 298 with respect to adopting standard Internet security mechanisms such 299 as IPSec[RFC2401]. Possible areas of attack include those against 300 the control plane where malicious hosts join IP multicast groups to 301 cause multicast traffic to be directed to parts of the network where 302 it is not needed or desired. This can indirectly cause denial-of- 303 service (DoS) to other network flows. Also, attackers may transmit 304 erroneous or corrupt messages to the group or employ strategies such 305 as replay attack within the "data plane" of protocol operation. 307 CDP integrate several BBs. The TCP-Friendly Multicast Congestion 308 Control (TFMCC) [RFC4654] building block specifies protocol 309 mechanisms where senders and receivers exchange messages to manage 310 sender transmission rate. 312 The IP architecture provides common access to notional control and 313 data planes to both end and intermediate systems. For the purposes 314 of discussion here, the "control plane" mechanisms are considered 315 those with message exchanges between end systems (typically 316 computers) and intermediate systems (typically routers) and while the 317 "data plane" encompasses messages exchanged among end systems, 318 usually pertaining to the transfer of application data. 320 3.1. Control-Plane Attacks 322 While control-plane attacks may be considered outside of the scope of 323 the transport protocol specifications discussed here, it is important 324 to understand the potential impact of such attacks with respect to 325 the deployment and operation of these protocols. For example, 326 awareness of possible IP Multicast control-plane manipulation that 327 can lead to unauthorized (or unexpected) monitoring of data plane 328 traffic by malicious users may lead a transport application or 329 protocol implementation to support encryption to ensure data 330 confidentiality and/or privacy. Also, these types of attack also 331 have bearing on assessing the real risks of potentially more complex 332 attacks against the transport mechanisms themselves. In some cases, 333 the solutions to these control-plane risk areas may reduce the impact 334 or possibility of some data-plane attacks that are discussed in this 335 document. 337 3.1.1. Control Plane Monitoring 339 While this may not be a direct attack on the transport system, it may 340 be possible for an attacker to gain useful information in advancing 341 attack goals by monitoring IP Multicast control plane traffic 342 including group membership and multicast routing information. 343 Identification of hosts and/or routers participating in specific 344 multicast groups may readily identify systems vulnerable to protocol- 345 specific exploitation. And, with regards to user privacy concerns, 346 such "side information" may be relevant to this emerging aspect of 347 network security. 349 3.1.2. Unauthorized (or Malicious) Group Membership 351 One of the simplest attacks is that where a malicious host joins an 352 IP multicast group so that potentially unwanted traffic is routed to 353 the host's network interface. This type of attack can turn a 354 legitimate source of IP traffic into a "attacker" without requiring 355 any access privileges to the source host or routers involved. This 356 type of attack can be used for denial-of-service purposes or for the 357 real attacker (the malicious joiner) to gain access to the 358 information content being sent. Similarly, some routing protocols 359 may permit any sender (whether joined to the specific group or not) 360 to transmit messages to a multicast group. 362 It is possible that malicious hosts could also spoof IGMP messages, 363 joining groups posing as legitimate hosts (or spoof source traffic 364 from legitimate hosts). This may be done at intermediate locations 365 in the network or by hosts co-resident with the authorized hosts on 366 local area networks. Such spoofing could be done by raw packet 367 generation or with replay of previously-recorded control messages. 368 For the sake of completeness, it should be noted that multicast 369 routing protocol control messaging may be subject to similar threats 370 if insufficient protocol security mechanisms are enabled in the 371 routing infrastructure. 373 The presence of these types of attack may necessitate that policy- 374 based controls be emplaced in routers to limit the distribution 375 (including transmission and reception) of multicast traffic (on a 376 group-wise and/or traffic volume basis) to different parts of the 377 network. Such policy-based controls are beyond the scope of the RMT 378 protocol specifications. However, such network protection mechanisms 379 may reduce the opportunities for or effectiveness of of some of the 380 data-plane attacks discussed later. For example, reverse-path checks 381 can significantly limit opportunities for attackers to conduct replay 382 attacks when hosts actually do use IPSec. Also, future IP Multicast 383 control protocols may wish to consider providing security mechanism 384 to prevent unauthorized monitoring or manipulation of messages 385 related to group membership, routing, and activity. 387 3.2. Data-Plane Attacks 389 This section discusses some types of active attacks that might be 390 conducted "in-band" with respect to the reliable multicast transport 391 protocol operating within the data plane of network data transfer. 392 The passive attack of unauthorized data-plan monitoring is discussed 393 above since such activity might be made possible by the 394 vulnerabilities of the IP Multicast control plane. To cover the two 395 classes of RMT protocols, the active data-plane attacks are 396 categorized as 1) those where the attacker generates messages posing 397 as a data sender, and 2) those where the attacker generates messages 398 posing as a receiver providing feedback to the sender(s) or group. 399 Additionally, a common threat to protocol operation is that of brute- 400 force, rogue packet generation. This is discussed briefly below, but 401 the more subtle attacks that might be conducted are given more 402 attention as those fall within the scope of the RMT transport 403 protocol design. Additionally, special consideration is given to 404 that of the "replay attack" [see Section 3.2.4], as it can be applied 405 across these different categories. 407 3.2.1. Rogue Traffic Generation 409 If an attacker is able to successfully inject packets into the 410 multicast distribution tree, the most obvious denial-of-service 411 attack is for the attacker to generate a large volume of apparently 412 authenticate (when authentication mechanisms are used, a "replay" 413 attack strategy might be used ) traffic. The impact of this type of 414 attack can be significant since the potential for routers to relay 415 the traffic to multiple portions of a networks (as compared to a 416 single unicast routing path). However, other than the amplified 417 negative impact to the network, this type of attack is no different 418 than what is possible with rogue unicast packet generation and 419 similar measures used to protect the network from such attacks could 420 be used to contain this type of brute-force attack. Of course, the 421 pragmatic question of whether current implementations of such 422 protection mechanisms support IP Multicast should be considered. 424 3.2.2. Sender Message Spoofing 426 These types of attacks are applicable to both general types of RMT 427 protocols: ALC (sender-only transmission) and NORM (sender-receiver 428 exchanges). Without an authentication mechanism, an attacker can 429 easily generate sender messages that could disrupt a reliable 430 multicast transfer session. And with FEC-based transport mechanisms, 431 a single packet with an apparently-correct FEC payload identifier 432 [RFC3452] but a corrupted FEC payload could potentially render an 433 entire block of transported data invalid. Thus, a modest injection 434 rate of corrupt traffic could cause severe impairment of data 435 transport. Additionally, such invalid sender packets could convey 436 out-of-bound indices (e.g. bad symbol or block identifiers) that can 437 lead to buffer overflow exploits or similar issues in implementations 438 that insufficient check for invalid data. 440 An indirect use of sender message spoofing would be to generate 441 messages that would cause receivers to take inappropriate congestion- 442 control action. In the case of the layered congestion control 443 mechanisms proposed for ALC use, this could lead to the receivers 444 erroneously leaving groups associated with higher bandwidth transport 445 layers and suffering unnecessarily low transport rates. Similarly, 446 receivers may be misled to join inappropriate groups directing 447 unwanted traffic to their part of the network. Attacks with similar 448 effect could be conducted against the TFMCC approach proposed for 449 NORM operation with spoofing of sender messages carrying congestion 450 control state to receivers. 452 3.2.3. Receiver Message Spoofing 454 These attacks are limited to RMT protocols that use feedback from 455 receivers in the group to influence sender and other receiver 456 operation. In the NORM protocol, this includes negative- 457 acknowledgment (NACK) messages fed back to the sender to achieve 458 reliable transfer, congestion control feedback content, and the 459 optional positive acknowledgment features of the specification. It 460 is also important to note that for ASM operation, NORM receivers pay 461 attention to the messages of other receivers for the purpose of 462 suppression to avoid feedback implosion as group size grows large. 464 An attacker that can generate false feedback can manipulate the NORM 465 sender to unnecessarily transmit repair information and reduce the 466 goodput of the reliable transfer regardless of the sender's transmit 467 rate. Contrived congestion control feedback could also cause the 468 sender to transmit at an unfairly low rate. 470 As mentioned, spoofed receiver messaging may not be directed only at 471 senders, but also at receivers participating in the session. For 472 example, an attacker may direct phony receiver feedback messages to 473 selected receivers in the group causing those receivers to suppress 474 feedback that might have otherwise been transmitted. This attack 475 could compromise the ability of those receivers to achieve reliable 476 transfer. Also, suppressed congestion control feedback could cause 477 the sender to perhaps transmit at a rate unfair to those attacked 478 receivers if their fair congestion control rate were lower than other 479 receivers in the group. 481 3.2.4. Replay Attacks 483 The infamous "replay attack" (injection of a previously transmitted 484 packet (or at least its payload) into the reliable transport group or 485 directly to one or more of its participants) is given special 486 attention here because of the special consequences it can have on RMT 487 protocol operation. Without specific protection mechanisms against 488 replay (e.g. duplicate message detection), it is possible for these 489 attacks to be successful even when security mechanisms such as packet 490 authentication and/or encryption are employed. 492 3.2.4.1. Replay of Sender Messages 494 Generally, replay of recent protocol messages from the sender will 495 not harm transport, and could potentially assist it, unless it is of 496 sufficient volume to result in the same type of impact as the "rogue 497 traffic generation" described above. However, it is possible that 498 replay of sufficiently old messages may cause receivers to think they 499 are "out of sync" with the sender and reset state, compromising the 500 transfer. Also, if sender transport data identifiers are reused 501 (object identifiers, FEC payload identifiers, etc), it is possible 502 that replay of old messages could corrupt data of a current transfer. 504 3.2.4.2. Replay of Receiver Messages 506 Replay of receiver messages are problematic for the NORM protocol, 507 because replay of NACK messages could cause the sender unnecessarily 508 transmit repair information for an FEC coding block. Similarly, the 509 sender transmission rate might be manipulated by replay of congestion 510 control feedback messages from receivers in the group. And the way 511 that NORM senders estimate group round-trip timing (GRTT) could allow 512 a replay attack to manipulate the senders' GRTT estimate to an 513 unnecessarily large value, adding latency to the reliable transport 514 process. 516 4. General Security Goals 518 The term "security" is extremely vast and encompasses many different 519 meanings. The goal of this section is to clarify what "security" 520 means when considering the reliable multicast transport (RMT) 521 protocols being defined in the IETF RMT working group. The scope can 522 also encompass additional group communication applications, for 523 instance streaming applications. This section only focuses on the 524 desired general goals. The following sections will then discuss the 525 possible elementary services that will be required to fulfill these 526 general goals, as well as the underlying technological building 527 blocks. 529 The possible final goals include, in decreasing order of importance: 531 o network protection: the goal is to protect the network from 532 attacks, no matter whether these attacks are voluntary (i.e. 533 launched by one or several attackers) or non voluntary (i.e. 534 caused by a misbehaving system, where "system" can designate a 535 building block, a protocol, an application, or a user); 537 o protocol protection: the goal is to protect the RMT protocol 538 itself, e.g. to avoid that a misbehaving receiver prevents other 539 receivers to get the content, no matter whether this is done 540 intentionally or not; 542 o and content protection: to goal is to protect the content itself, 543 for instance to guaranty the integrity of the content, or to make 544 sure that only authorized clients can access the content. 546 4.1. Network Protection 548 Protecting the network is of course of primary importance. An 549 attacker should not be able to damage the whole infrastructure by 550 exploiting some features of the RMT protocol. Unfortunately, recent 551 past has shown that the multicast routing infrastructure is 552 relatively fragile, as well as the applications built on top of it. 554 (TBD) develop... 556 4.2. Protocol Protection 558 Protecting the protocols is also importance, since the higher the 559 number of clients, the more serious the consequences of an attack. 560 This is all the more true as scalability is often one of the desired 561 goals of RMT protocols. Ideally, receivers should be sufficiently 562 isolated from one another, so that a single misbehaving receiver does 563 not affect others. Similarly, an external attacker should not be 564 able to break the system. 566 (TBD) develop... 568 4.3. Content Protection 570 Finally, the content itself should be protected when meaningful. 571 This level of security is often the concern of the content provider 572 (and its responsibility). For instance, in case of confidential (or 573 non-free) content, the typical solution consists in encrypting the 574 content. It can be done within the upper application, i.e. above the 575 RMT protocol, or within the transport system. 577 But other requirements may exist, like verifying the integrity of a 578 received object, or authenticating the sender of the received 579 packets. To that goal, one can rely on the use of building blocks 580 integrated within, or above, or beneath the RMT protocol. 582 One may also consider that offering the packet sender authentication 583 and content integrity services are basic requirements that should 584 fulfill any RMT system that operates within an open network, where 585 any attacker can easily inject spurious traffic in an ongoing NORM or 586 ALC session. In that case this goal is not the responsibility of the 587 content provider but the responsibility of the administrator who 588 deploys the RMT system itself. 590 5. Elementary Security Services 592 The goals defined in Section 4 will be fulfilled by means of 593 underlying elementary services, provided by one or several 594 technological building blocks. This section only focuses on these 595 elementary services. 597 The services traditionally listed are: 599 o packet source authentication and integrity: the goal is to enable 600 a receiver to verify the source of a packet and that the packet 601 has not been modified in transit; 603 o packet group authentication and integrity: the goal is to enable a 604 receiver to verify that a packet originated within the group and 605 has not been modified by nonmembers in transit; 607 o packet non-repudiation: the goal is to enable any third party to 608 verify the source of a packet. In that case the source cannot 609 repudiate having sent the packet; 611 o packet anti-replay: the goal is to enable a receiver to detect 612 that a given packet has already been received; 614 o object sender and object integrity: the goal is to enable a 615 receiver to verify the identity of the sender of the object and 616 the integrity of the whole object; 618 o object confidentiality: the goal is to enable a source to guaranty 619 that only authorized receivers can access the object data; 621 o (TBD) more items? 623 To this list, one must add the services specific to the RMT 624 protocols: 626 o congestion control security: the goal is to prevent an attacker 627 from modifying the congestion control protocol normal behavior 628 (e.g. by reducing the transmission (NORM) or reception (ALC) rate, 629 or on the opposite increasing this rate up to a point where 630 congestion occurs); 632 o group management: the goal is to make sure that only authorized 633 receivers (as defined by a certain group management policy), join 634 the RMT session and possibly inform the source; 636 o backward group secrecy: the goal is to prevent a new group member 637 to access the information in clear sent to the group before he 638 joined the group; 640 o forward group secrecy: the goal is to prevent a former group 641 member to access the information in clear sent to the group after 642 he left the group; 644 o (TBD) more items? 646 These services are usually achieved by means of one or several 647 technological building blocks. The target use case where the RMT 648 system will be deployed will greatly impact the choice of the 649 technological building block(s) used to provide these services, as 650 explained in Section 2.3. 652 6. Technological Building Blocks 654 Here is a list of techniques and building blocks that are likely to 655 fulfill one or several of the goals listed above: 657 o IPsec; 659 o Use of TESLA within RMT; 661 o Use of Group MAC within RMT; 663 o Use of Digital signatures within RMT; 665 o use of SSM (Source Specific Multicast) multicast routing; 667 o Digital Signature; 669 o (TBD) add other BBs 671 Each of them is now quickly discussed. In particular we identify 672 what service it can offer, its limitations, and its field of 673 application (adequacy W.R.T. the CDP and the target use case). 675 6.1. IPsec 677 6.1.1. Benefits 679 One direct approach using existing standards is to apply IPSec 680 [RFC2401] to achieve the following properties for message 681 transmission: 683 1. Authentication (IPSec AH or ESP) 685 2. Confidentiality (IPSec ESP) 687 6.1.2. Requirements 689 It is expected that the approach to apply IPSec for reliable 690 multicast transport sessions is similar to that described for OSPFv3 691 security[RFC4552]. The following list proposes the IPSec 692 capabilities needed to support a similar approach to RMT protocol 693 security: 695 1. Mode - Transport mode IPSec security is required; 697 2. Selectors - source and destination addresses and ports, protocol. 699 3. For some uses, preplaced manual key support may be required to 700 support application deployment and operation. For automated key 701 management for group communication the Group Secure Association 702 Key Management Protocol (GSAKMP) described in [RFC4535] may be 703 used to emplace the keys for IPSec operation. 705 Note that a periodic rekeying procedure similar to that described in 706 RFC 4552 can also be applied with the additional benefit that the 707 reliable transport aspects of the RMT protocols provide robustness to 708 any message loss that might occur due to ANY timing discrepancies 709 among the participants in the reliable multicast session. 711 6.1.3. Limitations 713 It should be noted that current IPSec implementations may not provide 714 the capability for anti-replay protection for multicast operation. 715 In the case of the NORM protocol, a sequence number is provided for 716 packet loss measurement to support congestion control operation. 717 This sequence number can also be used within a NORM implementation 718 for detecting duplicate (replayed) messages from sources (senders or 719 receivers) within the transport session group. In this way, 720 protection against replay attack can be achieved in conjunction with 721 the authentication and possibly confidentiality properties provided 722 by an IPSec encapsulation of NORM messages. NORM receivers generate 723 a very low volume of feedback traffic and it is expected that the 16- 724 bit sequence space provided by NORM will be sufficient for replay 725 attack protection. When a NORM session is long-lived, the limits of 726 the sender repair window are expected to provide protection from 727 replayed NACKs as they would typically be outside of the sender's 728 current repair window. It is suggested that IPSec implementations 729 that can provide anti-replay protection for IP Multicast traffic, 730 even when there are multiple senders within a group, be adopted. The 731 GSAKMP document has some discussion in this area. 733 6.2. Use of TESLA within RMT 735 6.2.1. Benefits 737 The use of TESLA [TESLA_4_ALC_NORM] within the RMT protocols offers a 738 loss tolerant, lightweight, authentication/integrity service for the 739 packets generated by the session's sender. Depending on the time 740 synchronization method and bootstrap method used, TESLA is compatible 741 with massively scalable sessions. Because TESLA heavily relies on 742 fast symmetric cryptographic building blocks, CPU processing remains 743 limited both at the sender and receiver sides, which makes it 744 suitable for high data rate transmissions, and/or lightweight 745 terminals. Finally, the transmission overhead remains limited. 747 6.2.2. Requirements 749 The security offered by TESLA relies heavily on time. Therefore the 750 session's sender and each receiver need to be loosely synchronized in 751 a secure way. To that purpose, several methods exist, depending on 752 the use case: direct time synchronization (which requires a 753 bidirectional transport channel), using a secure NTP infrastructure 754 (which also requires a bidirectional transport channel), or a GPS 755 device, or a clock with a time-drift that is negligible in front of 756 the TESLA time accuracy requirements. 758 The various bootstrap parameters must also be communicated to the 759 receivers, using either an in-band or out-of-band mechanism, 760 sometimes requiring bidirectional communications. 762 So, depending on the time synchronization scheme and the bootstrap 763 mechanism method, TESLA can be used with either bidirectional or 764 unidirectional transport channels. 766 6.2.3. Limitations 768 A first limitation is that TESLA does not protect the packets that 769 are generated by receivers, for instance the feedback packets of 770 NORM. These packets must be protected by other means. 772 Another limitation is that TESLA requires some buffering capabilities 773 at the receivers in order to enable the delayed authentication 774 feature. This is not considered though as a major issue in the 775 general case (e.g. FEC decoding of objects within an ALC session 776 already requires some buffering capabilities, that often exceed that 777 of TESLA), but it might be one in case of embedded environments. 779 6.3. Use of Group MAC within CDP 781 6.3.1. Benefits 783 The use of Group MAC (Message Authentication Codes) within the CDP 784 [SIMPLE_AUTH_4_ALC_NORM] is a simple solution to provide a loss 785 tolerant group authentication/integrity service for all the packets 786 exchanged within a session (i.e. the packets generated by the 787 session's sender and the session's receivers). This scheme is easy 788 to deploy since it only requires that all the group members share a 789 common secret key. Because Group MAC heavily relies on fast 790 symmetric cryptographic building blocks, CPU processing remains 791 limited both at the sender and receiver sides, which makes it 792 suitable for high data rate transmissions, and/or lightweight 793 terminals. Finally, the transmission overhead remains limited. 795 6.3.2. Requirements 797 This scheme only requires that all the group members share a common 798 secret key, possibly associated to a re-keying mechanism (e.g. each 799 time the group membership changes, or on a periodic basis). 801 6.3.3. Limitations 803 This scheme cannot protect against attacks coming from inside the 804 group, where a group member impersonates the sender and sends forged 805 messages to other receivers. It only provides a group-level 806 authentication/integrity service, unlike the TESLA and Digital 807 Signature schemes. 809 Note that the Group MAC and Digital Signature schemes can be 810 advantageously used together, as explained in 811 [SIMPLE_AUTH_4_ALC_NORM]. 813 6.4. Use of Digital Signatures within CDP 815 6.4.1. Benefits 817 The use of Digital Signatures within the CDP [SIMPLE_AUTH_4_ALC_NORM] 818 is a simple solution to provide a loss tolerant authentication/ 819 integrity service for all the packets exchanged within a session 820 (i.e. the packets generated by the session's sender and the session's 821 receivers). This scheme is easy to deploy since it only requires 822 that the participants know the packet sender's public key, which can 823 be achieved either thanks to a PKI or by pre-deploying these keys. 825 6.4.2. Requirements 827 This scheme is easy to deploy since it only requires that the 828 participants know the packet sender's public key, which can be 829 achieved either thanks to a PKI or by pre-deploying these keys. 831 6.4.3. Limitations 833 When RSA asymmetric cryptography is used, digital signatures has two 834 major shortcomings: 836 o it is limited by high computational costs, especially at the 837 sender, and 839 o it is limited by high transmission overheads. 841 This scheme is well suited to low data rate flows, when transmission 842 overheads are not a major issue. For instance it can be used as a 843 complement to TESLA for the feedback traffic coming from the 844 session's receivers. 846 The use of ECC ("Elliptic Curve Cryptography") significantly relaxes 847 these constraints, especially when seeking for higher security 848 levels. For instance, the following key size provide equivalent 849 security: 851 +--------------------+--------------+--------------+ 852 | Symmetric Key Size | RSA Key Size | ECC Key Size | 853 +--------------------+--------------+--------------+ 854 | 80 bits | 1024 bits | 160 bits | 855 | 112 bits | 2048 bits | 224 bits | 856 +--------------------+--------------+--------------+ 858 However ECC is heavily patented, notably by the Certicom Inc. 859 company. 861 Note that the Group MAC and Digital Signature schemes can be 862 advantageously used together, as explained in 863 [SIMPLE_AUTH_4_ALC_NORM]. 865 6.5. SSM Multicast Routing 867 6.5.1. Benefits 868 6.5.2. Requirements 870 6.5.3. Limitations 872 6.6. Summary 874 The following table summarizes the pros/cons of each authentication/ 875 integrity scheme used at application/transport level: 877 +----------------+-------------+--------------+-------------+-------+ 878 | | RSA Digital | ECC Digital | Group MAC | TESLA | 879 | | Signature | Signature | | | 880 +----------------+-------------+--------------+-------------+-------+ 881 | True auth and | Yes | Yes | No (group | Yes | 882 | integrity | | | security) | | 883 | Immediate auth | Yes | Yes | Yes | No | 884 | Processing | -- | + | ++ | + | 885 | load | | | | | 886 | Transmission | -- | + | ++ | + | 887 | overhead | | | | | 888 | Complexity | ++ | ++ | ++ | -- | 889 +----------------+-------------+--------------+-------------+-------+ 891 7. Global Security Infrastructure 893 Deploying the elementary technological building blocks often requires 894 that a global security infrastructure exists. This security 895 infrastructure: 897 o can provide a PKI (Public Key Infrastructure): this PKI provides 898 for trusted third party vetting of, and vouching for, user 899 identities. It also allows the binding of public keys to users, 900 usually by means of certificates. 902 o can provide a group key management service: this service usually 903 provides rekeying schemes, either periodic or triggered by some 904 higher level event. It is required in particular when the group 905 is dynamic and forward/backward secrecy are important. This is 906 also required to improve the scalability of the CDP (since key 907 management is done automatically, using a key server topology), or 908 the security provided by the CDP (since the underlying 909 cryptographic keys will be changed frequently). 911 o (TBD): add more... 913 TBD: more information on group key management, etc. 915 7.1. Public Key Infrastructure 917 7.1.1. Benefits 919 7.1.2. Requirements 921 7.1.3. Limitations 923 7.2. Group Key Management and Re-keying Protocols 925 7.2.1. Benefits 927 7.2.2. Requirements 929 7.2.3. Limitations 931 8. New Threats Introduced by the Security Scheme Itself 933 Introducing a security scheme, as a side effect, can sometimes 934 introduce new security threats. For instance, signing all packets 935 with asymmetric cryptographic schemes (to provide a source 936 authentication/content integrity/anti-replay service) opens the door 937 to DoS attacks. Indeed, verifying asymmetric-based cryptographic 938 signatures is a CPU intensive task. Therefore an attacker can easily 939 overload a receiver (or a sender in case of NORM) by injecting a 940 significant number of faked packets. 942 XXX: TODO... 944 9. Consequences for the RMT and MSEC Working Group 946 (TBD) discuss here the possible recommendations for the RMT and MSEC 947 groups... Or remove this section altogether... 949 9.1. RMT Transport Message Security Encapsulation Header 951 An alternative approach to using IPSec to provide the necessary 952 properties to protect RMT protocol operation from the application 953 attacks described earlier, is to extend the RMT protocol message set 954 to include a message encapsulation option. This encapsulation header 955 could be used to provide authentication, confidentiality, and anti- 956 replay protection as needed. Since this would be independent of the 957 IP layer, the header might need to provide a source identifier to be 958 used as a "selector" for recalling security state (including 959 authentication certificate(s), sequence state, etc) for a given 960 message. In the case of the NORM protocol, a NormNodeId field exists 961 that could be used for this purpose. In the case of ALC, the 962 security encapsulation mechanism would need to add this function. 963 The security encapsulation mechanism, although resident "above" the 964 IP layer, could use GSAKMP [RFC4535] or a similar approach for 965 automated key management. 967 10. Security Considerations 969 Not applicable since this document does not introduce any new 970 technique. 972 11. Acknowledgments 974 12. Normative References 976 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 977 Requirement Levels", BCP 14, RFC 2119, March 1997. 979 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 980 Internet Protocol", RFC 2401, November 1998. 982 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J. 983 Crowcroft, "Asynchronous Layered Coding (ALC) Protocol 984 Instantiation", RFC 3450, December 2002. 986 [RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 987 M., and J. Crowcroft, "Forward Error Correction (FEC) 988 Building Block", RFC 3452, December 2002. 990 [RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, 991 "FLUTE - File Delivery over Unidirectional Transport", 992 RFC 3926, October 2004. 994 [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, 995 "Negative-acknowledgment (NACK)-Oriented Reliable 996 Multicast (NORM) Protocol", RFC 3940, November 2004. 998 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 999 "GSAKMP: Group Secure Association Key Management 1000 Protocol", RFC 4535, June 2006. 1002 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1003 for OSPFv3", RFC 4552, June 2006. 1005 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 1006 Congestion Control (TFMCC): Protocol Specification", 1007 RFC 4654, August 2006. 1009 [SIMPLE_AUTH_4_ALC_NORM] 1010 Roca, V., "Simple Authentication Schemes for the ALC and 1011 NORM Protocols", 1012 draft-roca-rmt-simple_auth-for-alc-norm-00.txt (work in 1013 progress), June 2007. 1015 [TESLA_4_ALC_NORM] 1016 Roca, V., Francillon, A., and S. Faurite, "The Use of 1017 TESLA in the ALC and NORM Protocols", 1018 draft-ietf-msec-tesla-for-alc-norm-02.txt (work in 1019 progress), July 2007. 1021 [draft-ietf-rmt-pi-alc-revised] 1022 Luby, M., Watson, M., and L. Vicisano, "Asynchronous 1023 Layered Coding (ALC) Protocol Instantiation", 1024 draft-ietf-rmt-pi-alc-revised-04.txt (work in progress), 1025 February 2007. 1027 Authors' Addresses 1029 Brian Adamson 1030 Naval Research Laboratory 1031 Washingtown, DC 20375 1032 USA 1034 Email: adamson@itd.nrl.navy.mil 1035 URI: http://cs.itd.nrl.navy.mil 1037 Vincent Roca 1038 INRIA 1039 655, av. de l'Europe 1040 Zirst; Montbonnot 1041 ST ISMIER cedex 38334 1042 France 1044 Email: vincent.roca@inrialpes.fr 1045 URI: http://planete.inrialpes.fr/~roca/ 1047 Full Copyright Statement 1049 Copyright (C) The IETF Trust (2007). 1051 This document is subject to the rights, licenses and restrictions 1052 contained in BCP 78, and except as set forth therein, the authors 1053 retain all their rights. 1055 This document and the information contained herein are provided on an 1056 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1057 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1058 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1059 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1060 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1061 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1063 Intellectual Property 1065 The IETF takes no position regarding the validity or scope of any 1066 Intellectual Property Rights or other rights that might be claimed to 1067 pertain to the implementation or use of the technology described in 1068 this document or the extent to which any license under such rights 1069 might or might not be available; nor does it represent that it has 1070 made any independent effort to identify any such rights. Information 1071 on the procedures with respect to rights in RFC documents can be 1072 found in BCP 78 and BCP 79. 1074 Copies of IPR disclosures made to the IETF Secretariat and any 1075 assurances of licenses to be made available, or the result of an 1076 attempt made to obtain a general license or permission for the use of 1077 such proprietary rights by implementers or users of this 1078 specification can be obtained from the IETF on-line IPR repository at 1079 http://www.ietf.org/ipr. 1081 The IETF invites any interested party to bring to its attention any 1082 copyrights, patents or patent applications, or other proprietary 1083 rights that may cover technology that may be required to implement 1084 this standard. Please address the information to the IETF at 1085 ietf-ipr@ietf.org. 1087 Acknowledgment 1089 Funding for the RFC Editor function is provided by the IETF 1090 Administrative Support Activity (IASA).