idnits 2.17.1 draft-ietf-rmt-pi-track-security-01.txt: 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (Sep 4, 2001) is 8270 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) == Unused Reference: 'KCWP00' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'R92' is defined on line 774, but no explicit reference was found in the text == Unused Reference: 'RSA93' is defined on line 776, but no explicit reference was found in the text == Unused Reference: 'WBPM98' is defined on line 779, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'HCM98' == Outdated reference: A later version (-10) exists of draft-ietf-msec-gsakmp-sec-00 == Outdated reference: A later version (-03) exists of draft-kadansky-tram-02 -- Possible downref: Normative reference to a draft: ref. 'KCWP00' ** Obsolete normative reference: RFC 2401 (ref. 'KA98a') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. 'KA98b') (Obsoleted by RFC 4302, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'R92') -- Possible downref: Non-RFC (?) normative reference: ref. 'RSA93' -- Possible downref: Normative reference to a draft: ref. 'WBPM98' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Hardjono (Nortel) 3 INTERNET-DRAFT B. Whetten (Talarian) 4 draft-ietf-rmt-pi-track-security-01.txt 5 April 5, 2001 Expires Sep 4, 2001 7 Security Requirements For TRACK 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 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 Abstract 34 This document discusses the security issues within the TRee-based 35 ACKnowledgement (TRACK) reliable multicast protocol, and identifies some 36 constraints and requirements for security provisions for this protocol. 37 Based on the constraints and requirements, the document proposes a 38 separation of data packet confidentiality and authentication, from 39 transport layer protection. It proposes that TRACK be primarily 40 concerned with group authentication of control and data packets, to 41 protect against attacks on the transport infrastructure. It proposes 42 that data confidentiality and source authentication be provided 43 separately from this low level group authentication, ideally at the 44 application level. We show that this is particularly important for 45 TRACK, because of the requirement that the interior control nodes only 46 OPTIONALLY have access to the data packet payload. 48 Specifically, the current work RECOMMENDS that data and control packet 49 authentication be provided using IPsec-based authentication at the 50 network layer. This approach allows an interior control node to 51 authentically retransmit a lost data packet (which remains encrypted 52 under the separate data-encryption key) to its own children (a set of 53 Receivers), while making use of the IPsec features, such as protection 54 against replay attacks. 56 This document then provides a specific proposal for how group keys 57 SHOULD be divided up among group members, for control and data packet 58 authentication. While providing some rationale for divorcing this 59 proposal from that of source authentication and data confidentiality, it 60 does not provide a specific proposal for those pieces. 62 1. Background: The Multicast Security Problem 64 The problem of multicast security can be divided into three general 65 areas of concern: 66 - Data Encryption and Source Authentication. The method used to 67 encipher or scramble the multicast data, and verify the identity 68 of the sender of this data. 69 - Key Distribution. The method used to securely distribute group 70 keys and keying material to the members of a group, for use in 71 decrypting or authenticating the data or control packets. 72 - Infrastructure Protection. Mechanisms used to protect the 73 multicast infrastructure itself, and to minimize the ability of an 74 intruder to deny service to legitimate users. 76 The security of reliable multicast protocols falls primarily into the 77 third category of problems. Complete denial of service protection must 78 start at the network level (i.e. IP Multicast), with controls placed on 79 senders from overloading the network with brute force "spamming", as 80 well as with authentication of control packets, to keep users from 81 corrupting the state of the IP Multicast protocols. A transport 82 protocol needs to address the same issues, checking to make sure that 83 senders are not sending more data than they are allowed (such as with 84 enforceable congestion control), and authenticating control packets, to 85 protect the protocol state. Control packet authentication is 86 particularly important in TRACK, because of its use of interior control 87 nodes (Repair Heads, or RHs) to increase scalability. 89 An OPTIONAL extension to the requirement of infrastructure protection is 90 that of infrastructure privacy. Some applications require that the 91 headers of the network packets be encrypted, to provide protection from 92 network analysis attacks. 94 2. Conventions Used in this Document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 98 this document are to be interpreted as described in RFC-2119 [B97]. 100 3. Independence of RM Security 102 The security of reliable multicast (RM) protocols is part of the larger 103 problem of the security of the multicast infrastructure, which also 104 consists of the security of the multicast routing protocols. 106 Since RM protocols and multicast routing protocols exist at different 107 layers in the protocol stack, and since different RM protocols may be 108 employed with different multicast routing protocols, it is useful from a 109 security perspective to treat these two security problems separately. 110 In addition, although in many instances the topology of RM 111 infrastructure may coincide with that of the multicast routing protocol, 112 such symmetry cannot be assumed for all cases. 114 Similarly, from a design perspective, the problem of securing the data 115 stream (e.g. through content encryption) should be separated from the 116 issue of securing reliable multicast protocols. 118 Although we treat RM-security as an independent problem from other 119 multicast security problems, this does not preclude using the solutions 120 in other areas in order to solve the security needs of RM. For example, 121 the use of IPsec technology at the IP layer to authenticate multicast 122 routing protocol control-packets can also be used to authenticate RM 123 control-messages. However, the instance of deploying IPsec in both 124 cases MUST be distinguished and treated separately. 126 4. TRACK Overview 128 TRACK arranges Receivers (R) into local regions, where each region is 129 assigned to a Repair Head (RH). These groups are arranged 130 hierarchically as a tree rooted at a Sender (SD), with the RHs 131 representing the nodes of the tree, and the Receivers as the leaves. 132 The Receivers send periodic control messages (called ACKs or NACKs) to 133 their parent RH, selectively acknowledging the packets they have 134 received, and requesting the ones they have missed. Retransmission is 135 then performed by the parent RH. Each RH sends their control messages 136 to the RH at the next level up the hierarchy. This process is repeated 137 until the messages reach the sender, informing it of the status of the 138 group, and notifying it when it is allowed to advance its transmission 139 window. The RHs aggregate the selective positive acknowledgements from 140 the receivers, and suppress the redundant negative acknowledgements, in 141 order to solve the ACK/NACK implosion problem. 143 A RH maintains a local multicast group to just its children, and 144 subscribes to the local multicast group of its parent. A RH uses this 145 local multicast group for retransmissions to its children, which also 146 provides suppression of other negative retransmission requests for that 147 packet at other children. 149 TRACK distinguishes between a data channel and a control channel. A 150 data channel is a global multicast group created using the underlying 151 multicast routing protocol. A control channel is the interconnected 152 topology of control nodes, for handling error recovery and positive 153 packet acknowledgements. 155 In order to obtain data packets from the Sender, a Receiver in a given 156 TRACK region MUST join the multicast group (i.e. the data channel). The 157 RH of that region MUST join every multicast group that its descendants 158 have joined. Note that the RHs are not responsible for forwarding the 159 data packets multicast by the Sender, since that data stream is 160 propagated by the underlying multicast routing protocol. 162 The figure below illustrates a TRACK tree with multiple control nodes. 164 -------> SD (Sender node)----->| 165 ^^^ | 166 TRACKs / | \ Control | 167 and / | \ Tree | 168 NACKs / | \ | 169 / | \ (Repair | 170 / | \ Head | 171 / | \ nodes) v 172 RH RH RH <------------| 173 ^^ ^^^ ^^ | Data 174 / | / | \ | \ | Channel 175 / | / | \ | \ | 176 / | / | \ | \ v 177 R R R R R R R <--------- 178 (Receiver Nodes) 179 5. TRACK Protocol Security Issues and Requirements 181 This section details the security requirements for TRACK. These 182 requirements include general multicast transport requirements, as well 183 as some requirements specific to TRACK. 185 5.1 Background 187 In addressing the security issues specific to TRACK, it is useful to 188 consider the general aspects of security relating to reliable multicast. 190 - Layer in which security is applied: 191 The two layers in which security mechanisms are deployed are 192 typically the network layer and the application layer. In the 193 network layer the protocol that is the most commonly used is the 194 IPsec protocol, which provides authentication and/or encryption. In 195 either case, with IPsec the transport headers (and IP headers) are 196 protected. When authentication and/or encryption is applied at the 197 application layer, neither the transport headers nor the IP headers 198 are protected. 200 - Types of authentication: 201 - Source-authentication: If public key (asymmetric) cryptography is 202 deployed, where only the sender knows the secret-half of the 203 public key pair, then unique "source-authentication" can be 204 established. 205 - Group-authentication: If shared key (symmetric) cryptography is 206 deployed and the key is shared by more than two parties, then 207 only "group-authentication" can be established. This means that a 208 receiver in a group is only certain that the entity that sent the 209 message is in possession of the symmetric-key, and is thus 210 assumed to be a member of the group sharing the key. 212 In the following, the TRACK specific requirements are further 213 elaborated. 215 5.2 Authentication of Control Messages 217 As stated above, the directly relevant security concern for TRACK is 218 protection of the multicast infrastructure, particularly of the control 219 tree, in order to provide protection against replay or other attacks 220 which seek to corrupt the state of the transport protocol. The 221 authentication of control messages exchanged among TRACK protocol 222 entities represents the minimal security mechanisms necessary to do so. 224 Two types of authentication mechanisms can be adopted, corresponding to 225 the two basic types of cryptosystems. In the context of reliable 226 multicast, throughput and latency is typically of high importance, and 227 group-authentication based on symmetric cryptography appears to be 228 preferable. 230 Given this, the efficiencies of symmetric key based authentication 231 appear to outweigh the benefits of public key based authentication. 232 There are potentially cryptographic schemes that can provide the unique 233 source-authentication of public key cryptography while providing the 234 performance characteristics of symmetric key based authentication (e.g. 235 efficient digital signing of the hash-value of several data packets). 236 However, at the present time, for the general case of infrastructure 237 protection, the complexities of these options appear to outweigh the 238 benefits. 240 Thus, in summary, for TRACK protocol control-messages, explicit group- 241 authentication at the IP layer SHOULD be deployed using symmetric 242 cryptography. Although a number of technologies are available, we 243 propose specifically IPsec-based authentication using a keyed-hash 244 function [KA98b,MG98a,MG98b] due to its growing use and availability. 246 We denote the symmetric key used for control message authentication as 247 the InteriorNodeKey. The InteriorNodeKey is a symmetric key shared by 248 all RHs and the Sender within a given TRACK hierarchy. The key is 249 independent of any data stream, and is used to authenticate control 250 packets exchanged among the RHs/Senders. 252 5.3 Non-Decipherability of Data Packets by RHs 254 TRACK requires that a Repair Head Node (RH) join all of the multicast 255 groups that its descendants have joined. For TRACK it is preferable 256 that authentication methods based on a symmetric key be deployed due to 257 performance reasons. This may be achieved explicitly, such as by using 258 a keyed hash function, or implicitly using encryption (where a 259 successful decryption implies the ciphertext is both unmodified in 260 transit and was generated by a holder of the symmetric key). 262 However, TRACK has a further requirement, namely that the RHs be 263 OPTIONALLY prevented from reading the multicast data. More 264 specifically, we perceive that RHs may be administered as part of a 265 reliability service offered by third parties such as ISPs. These third 266 parties may refuse the ability to decipher data packets in order to 267 avoid the legal ramifications of having access to the data contents. 268 Thus, from the ISP perspective, TRACK SHOULD allow them to prove to the 269 content-owner that they do not posses the means to alter the contents 270 transmitted through the multicast groups. 272 Given the above requirement of the RHs and the need for fast 273 authentication, we propose: 275 - Data stream confidentiality, using either a symmetric or asymmetric 276 key, SHOULD be separated from data authentication, using a symmetric 277 key (i.e. explicit group-authentication). 279 - Data stream confidentiality SHOULD be conducted at the application 280 layer, while data authentication, using a symmetric key, SHOULD be 281 conducted at the network layer. 283 - Since the RHs MAY be prevented from reading the multicast data, two 284 (2) different keys SHOULD be deployed corresponding to the needs of 285 data stream confidentiality and data group-authentication. 287 5.4 Authentication of Data Retransmissions 289 In TRACK, retransmissions of data packets always come from a child's 290 parent, which may be either the original source or a RH node. This 291 local recovery is an important tool for increasing the scalability and 292 latency of a protocol. In the context of security, it raises the 293 question as to what authentication methods should be used on these 294 packets. 296 (a) If source authentication (using public key cryptography) and data 297 confidentiality (including implicit group authentication) is 298 applied at the application layer, the RH can simply replay the data 299 (i.e. payload) unmodified to the querying receivers via local 300 multicast. 302 (b) If, however, explicit group authentication (using a symmetric key) 303 was applied at the network layer (e.g. using IPsec), then the RH 304 could not simply replay the packet due to restrictions at the IP 305 layer. Thus, in this case the RH would have to re-apply the group- 306 authentication. 308 Since the retransmission is via multicast to a subgroup, then the 309 RH can either use the existing group-shared symmetric key or use a 310 separate symmetric key only for the subgroup of its children. We 311 propose the later approach be OPTIONALLY supported, which means 312 that a RH and its children (Receivers and in some cases other 313 Repair Heads) could have to share a separate symmetric key for 314 explicit group authentication at the IP layer. 316 5.5 Keys for Data Confidentiality and for Authentication 318 As mentioned above, we propose the separation of data stream 319 confidentiality using a symmetric key encryption (effecting an implicit 320 group-authentication) from data authentication using a symmetric key and 321 a keyed hash function (i.e. explicit group-authentication). 323 We now denote the symmetric key for data stream confidentiality at the 324 application layer as the GroupDataKey. Only the source and valid 325 receivers will have a copy of the GroupDataKey, which is delivered to 326 them through the appropriate Group Key Management (GKM) protocol that 327 identifies and verifies the members individually. In the case where the 328 RHs are not permitted to read the multicast data, they MUST be prevented 329 by the GKM protocol from obtaining the GroupDataKey. 331 We denote the symmetric key for explicit group-authentication at the 332 network layer as the GroupAuthKey. The GroupAuthKey is distinct from the 333 GroupDataKey. For TRACK, we propose, where feasible, the use of IPsec 334 with keyed hashing at the network layer to provide explicit group- 335 authentication using the GroupAuthKey. Unlike the GroupDataKey, the 336 GroupAuthKey is known by all entities involved in the multicast. This 337 includes all interior node entities (RHs), the Sender and the Receivers. 339 5.6 Authenticity of NACK and other Control Packets 341 In TRACK, a RH responds to a NACK from one its children (typically a 342 Receiver) by re-transmitting the lost packet via local multicast. This 343 basic behavior can be open to abuse by an attacker who injects spurious 344 NACK messages towards the RH, causing a local multicast to all children 345 of the RH. In itself this is a waste of bandwidth and may result in a 346 denial of resource to the group members. Other control packets such as 347 group membership requests, could directly impact the state of the group, 348 and could also be used in denial of service attacks. 350 To counter these types of attack, the control messages themselves SHOULD 351 be authenticated by the RH. Digital signatures using public key 352 cryptography could be applied to the control messages. However, this 353 approach would be inefficient due to the high CPU cost of public key 354 encryption. Also, it would require creating a separate security 355 association with each child of the RH. 357 Instead, we propose that NACK and other control messages from a child 358 (Receiver) to its RH be protected using symmetric IPsec based 359 authentication, where feasible. This requires the two parties to first 360 establish a Security Association (SA) and a shared symmetric key. The 361 symmetric key is uniform over a subgroup of receivers (i.e. those under 362 the RH). 364 5.7 Fault Recovery 366 If a child's connection to a RH or Sender fails, TRACK provides 367 automatic mechanisms for failing-over to another RH or to the Sender. 368 This reconnection needs to happen quickly, so that the child can rejoin 369 the data stream before too much data has been missed to recover from. 370 If a child needs to get a new key for that RH or Sender, this can be a 371 bottleneck. Given that the key distribution infrastructure may be 372 centralized, and a majority of receivers may need to fail over at the 373 same time, this presents a major opportunity for network congestion. 375 TRACK entities are expected to usually have the addresses of one or more 376 backup nodes. When implementing security features, each child SHOULD 377 keep the key for its primary backup parent. Optionally, it MAY need to 378 keep the keys for each of the backup parents it is using. 380 5.8 Implementation with Different Levels of OS Protection 382 A TRACK protocol can be implemented in (at least) one of three ways. 383 - Application level. Most implementations of TRACK for the near 384 future are expected to operate in the application level of the OS, 385 running on top of UDP. 386 - Kernel. As TRACK becomes bundled with standard operating systems, 387 it is expected to become a kernel module, and run directly over 388 IP. 389 - Virtual machine. Some TRACK entities (particularly senders and 390 receivers) will be run in virtual machines, such as when 391 implemented as a Java applet. 393 TRACK protocol security SHOULD accommodate all three of these options. 394 This raises the following issues. 395 - Application Level. One advantage of application level 396 implementations is their flexibility. These implementations could 397 use either IPsec routines, the application layer security functions, 398 or both. 400 - Virtual Machines. There are issues trying to use IPsec with 401 virtual machines such as Java, which have to date hindered the 402 support of IPsec through native Java applets. TRACK SHOULD be 403 able to OPTIONALLY use only application level security. 404 - Kernel Implementations. As a TRACK protocol becomes bundled with 405 operating systems, it is expected that IPsec will also become 406 bundled with the OS. To avoid having to use less trusted software 407 in the application level, the TRACK protocol SHOULD be able to use 408 a kernel level security system (such as IPsec) for its transport 409 level security needs. 411 5.9 Separate Regional Protection 413 TRACK is expected to be used for content distribution from a few senders 414 to many receivers. In the case of applications that distribute critical 415 data to many different organizations, it is not enough to trust all 416 receivers. For example, a market data feed provider could be using a 417 TRACK protocol to distribute live market data feeds to competing 418 financial institutions. In this situation, the data feed provider needs 419 to be able to protect individual companies from corrupted control 420 packets from other customers (which could be generated either 421 intentionally, or more likely, unintentionally) which would cause denial 422 of service. 424 As we have proposed, a TRACK protocol MAY provide separate regional keys 425 for the group-authentication of control packets sent from the receivers 426 of different RHs. This allows the authentication of control-messages 427 for each set of receivers (part of one customer) to be done separately 428 (from another set of receivers, as part of a different customer). Since 429 for each set of receivers a different key is used, this limits the 430 ability of a customer to perpetrate denial of service attacks against 431 other customers. 433 5.10 Piracy of Pay-Per-Use Data 435 A common scenario for TRACK involves pay-per-use data distribution, such 436 as live market data, pay-per-view video signals, or paid subscriptions 437 to software updates. In this scenario, a receiver cannot be trusted to 438 not give its group keys to outside entities that are trying to get free 439 service. We mention this requirement since it is different than point- 440 to-point security. However, this requirement is the responsibility of 441 the application level security. 443 6. Architecture Recommendations 445 The previous section detailed some of the specific requirements and 446 issues for TRACK protocol security, along with some individual 447 recommendations on handling each one. Given those requirements, we 448 propose the following architecture recommendations for implementing 449 security with TRACK. 451 6.1 Separation of Security Responsibilities 453 As detailed above, TRACK is primarily concerned with protection of the 454 network infrastructure, rather than with issues such as data 455 confidentiality and source-authentication. Therefore, we RECOMMEND that 456 TRACK SHOULD provide: 457 (a) group authentication of control packets, and 458 (b) OPTIONAL group authentication of data packets 459 TRACK MAY choose to provide: 460 (c) OPTIONAL privacy of data and of control packet headers. 461 To accomplish this, we RECOMMEND that, where feasible, TRACK use IPsec 462 technology at the network layer, while letting application level 463 security perform additional functions as needed. For implementations 464 that do not have access to IPsec, and are not implemented as part of the 465 OS, application level security can be used instead--although this of 466 course risks incompatibility with other implementations. 468 The separation of group-authentication of data from both data source- 469 authentication and data-confidentiality is tightly coupled to the choice 470 of recommending IPsec for the group authentication. These two choices 471 are motivated by the following: 473 (a) Non-Decipherability of data by interior control nodes: it is a 474 requirement of TRACK that in some deployments, its control entities 475 (RHs) be unable to decipher the data packet. Thus, the GroupDataKey 476 for data encryption and GroupAuthKey for group-authentication SHOULD 477 be distinct. It is not sufficient to simply use an identical key 478 (for the GroupDataKey and GroupAuthKey) and to instruct the TRACK 479 protocol entities to avoid deciphering the data packets. It SHOULD 480 be provably shown that the interior control nodes do not have the 481 ability to decipher the data packets (even if they wish to do so). 483 (b) Use of IPsec technologies: considerable effort has been invested in 484 developing the IPsec architecture and protocols [KA98a, KA98b], and 485 a growing number of vendors are supporting IPsec. The IPsec suite 486 offers a number of features, including some protection against 487 replay attacks. 489 (c) Multicast IPsec: the IPsec architecture has intentionally allowed 490 the use of IPsec for IP multicast without changes to the basic 491 constructs within the IPsec suite. Currently, work is proceeding 492 towards the establishment of a standard mechanism to select the 493 Group Security Association (Group SA or GSA) for multicast and a 494 method to disseminate the GSA to the valid members of the group 495 [HCM98,HH99a]. 497 (d) Appropriate Level: since the primary purpose of transport level 498 security is to secure the infrastructure at a transport level, using 499 a network or transport level security protocol allows each to be 500 implemented together--either in the OS, or in the application layer. 502 6.2 Division of Responsibilities 504 Given this fundamental division between application and transport 505 responsibilities, we divide the security responsibilities in to four 506 parts. 508 Network Responsibilities (IP and IP Multicast) 509 ---------------------------------------------- 511 - Admission controls on senders--to protect against "brute 512 force" spamming attacks. 513 - Authentication of routing control packets--to protect 514 the routing infrastructure from denial of service attacks. 516 Transport Responsibilities (TRACK) 517 ------------------------------------ 518 - Protection of the control messages from replay attacks 519 and other denial-of-service attacks. 520 - Optional: protection of data packets from replay attacks. 521 - Optional: encryption of data and control headers to minimize 522 network analysis by attackers. 524 End to End Responsibilities (Application) 525 ----------------------------------------- 526 - Source authentication--to verify the authenticity of data, 527 and provide OPTIONAL non-repudiation of data. 528 - Data encryption--to provide data confidentiality. 530 Key Management Infrastructure 531 ------------------------------- 532 - Distribution of transport and network layer keys: authentication 533 of individual hosts, and distribution of keys to those hosts 534 - Application level key distribution: authentication of 535 individual processes, and distribution of keys to those processes 536 - Optional: periodic rekeying--group keys periodically need 537 to be changed, both after a certain time limit has expired, 538 and/or after the group membership changes. 540 The figure below shows how these components relate to each other. TRACK 541 can be used without any additional security at the IP/IP Multicast 542 level, although this will not provide full protection from denial of 543 service attacks. TRACK will be able to be used on top of UDP or raw 544 IP/IP Multicast. A TRACK protocol can use either IPsec or application 545 level security for its network security requirements, although we 546 RECOMMEND using IPsec wherever possible. 548 +--------------------+ +----------+ 549 +--------------+<----->| Application |<----->| App Sec | 550 | | +--------------------+ |==>| | 551 | | | TRACK |<--| +----------+ 552 | Key |<----->+ +---------+ |-->| | 553 | Management | | | UDP | | IPsec | 554 | | +--------------------+ | | 555 | |<=====>| IP, IP Multicast |<=====>| | 556 +--------------+ +--------------------+ +----------| 558 <===> Optional 560 For example, when a data packet is to be sent to the multicast group, 561 the Sender/Source first (optionally) enciphers the data packet using the 562 GroupDataKey above the RM/transport layer. It is then passed to the 563 RM/transport layer, which attaches the necessary RM headers. The result 564 is then passed down to the IP layer where IPsec authentication is 565 established (using the GroupAuthKey). 567 A Receiver in the multicast group would be in possession of both the 568 GroupDataKey and the GroupAuthKey, and thus will be able to first 569 authenticate the data packet using the GroupAuthKey, and then continue 570 to decipher the data packet using the GroupDataKey. 572 A Repair Head Node (RH) will possess the GroupAuthKey (but not the 573 GroupDataKey), and thus will only be able to authenticate the packet 574 using the GroupAuthKey using IPsec. After verifying the authenticity of 575 a received data packet, a RH will be able to retransmit the (enciphered) 576 data packet to its children, either via unicast or region-based local 577 multicast. A retransmission of a lost data packet from a RH will be 578 authenticated using a SubgroupAuthKey (see below) which is a symmetric 579 key shared by a RH and all its children Receivers only. 581 Again, although the current work proposes the use of unicast IPsec and 582 multicast IPsec at the network layer, it does not preclude the use of 583 other authentication technologies at the network layer or at the 584 RM/transport layer. Such technologies, however, will have to address 585 much of the same issues faced by IPsec, including prevention of replays, 586 the creation and maintenance of state (i.e. "Security Associations") 587 associated with the GroupAuthKey, the Sender and Receiver(s), and other 588 features and supporting mechanisms. It is precisely the growing 589 availability of IPsec that motivates the current work to choose IPsec 590 for network layer authentication for both data and control packets. 592 6.3 TRACK Keys 594 In general, each node in the hierarchy MUST be able to authenticate 595 itself to the key management entity/server, before it will be allowed to 596 receive any of the below keys. We assume the implementation of a key 597 management infrastructure, which interfaces with the RHs, as well as the 598 Senders and Receivers. 600 We propose that this key management system be responsible for 601 distributing the following TRACK protocol keys: 603 - GroupDataKey: 604 The GroupDataKey is the unique symmetric key for data encryption 605 shared by all members of a multicast group, excluding the interior 606 tree entities. Typically, one GroupDataKey is associated with one 607 multicast group. The GroupDataKey is used to provide access control 608 to the data packet by way of the Sender/Source enciphering the data 609 packet. Since only the Receivers hold the copy of the GroupDataKey, 610 only the Receivers will be able to decipher the data packets. This 611 is an OPTIONAL application key, which does not directly concern the 612 TRACK transport. 614 - GroupAuthKey: 615 The GroupAuthKey is the unique symmetric key shared by all members 616 of a multicast group, including the interior control nodes. One 617 GroupAuthKey is associated with one multicast group. The purpose of 618 the GroupAuthKey is to provide authentication of the (possibly 619 enciphered) data packets. In the context of IPsec authentication, 620 this can be achieved using a keyed hash function, such as HMAC-MD5- 621 96 [MG98a] and HMAC-SHA-1-96 [MG98b]. 623 - SubgroupAuthKey: 624 The SubgroupAuthKey is the unique symmetric key shared only by 625 entities within a given local region, consisting of a RH and its 626 children (consisting of one or more Receivers, and possibly one 627 child RH). The SubgroupAuthKey is used by the parent in a local 628 region to provide group-authentication for the (lost) data packets 629 (still enciphered under the GroupDataKey) which are retransmitted to 630 the Receivers in the region via local multicast. The 631 SubgroupAuthKey is also used by the entities in a region to group- 632 authenticate control messages that are exchanged with each other. 633 Similar to the GroupAuthKey, we propose the use of IPsec based 634 authentication via keyed hash function. 636 Note that for region-based retransmission of lost packets and for 637 control-packet authentication, the SubgroupAuthKey is used instead 638 of the GroupAuthKey (not both). 640 Note that if a RH happens to be a child within a region and at the 641 same time a parent within its own region, then that RH will hold two 642 distinct SubgroupAuthKeys corresponding to the two regions. 644 - InteriorNodeKey: 645 The InteriorNodeKey is a symmetric key shared by all interior 646 control nodes within a given TRACK hierarchy. The key is 647 independent of any data stream, and is used to authenticate control 648 packets exchanged among the RHs. Should a child-RH request a 649 retransmission of a lost data packet from its parent-RH, then the 650 parent-RH will deliver the (encrypted) lost packet to the child-RH, 651 authenticated using the InteriorNodeKey. 653 Before the child-RH retransmits this lost data packet to its own 654 region, it MUST first authenticate the packet from the parent-RH 655 using the InteriorNodeKey. It MUST then use its own SubgroupAuthKey 656 of the region headed/parented by that child-RH to provide 657 authentication for the retransmitted data packet. 659 7. Limitations 661 The proposed security architecture has certain limitations. These 662 include: 664 (a) Brute Force Attacks. At the transport level, no admission controls 665 can be put in place to throttle a sender which is generating lots of 666 spurious packets to a multicast address. This is the requirement of 667 the network level. At the present time, no accepted standard exists 668 for doing so at the IP Multicast level. 670 (b) Key Corruption. The recommended group key architecture makes a 671 careful tradeoff between the need to distribute many keys, and the 672 need to localize the effects of a node which is compromised. This 673 proposal allows a local receiver to perpetrate denial of service 674 attacks to its local RH, and the receivers served by that RH. 676 (c) Privacy. In order to prevent network traffic analysis attacks, the 677 group keys can be used with IPsec to encrypt the packets sent to the 678 group, in addition to doing packet authentication. However, it must 679 be recognized that this is not a general solution for data privacy. 680 In particular, the group keys can easily be passed from a valid 681 receiver to an unauthorized receiver, to enable piracy of pay-per- 682 use services. This is reasonable, as data privacy is not considered 683 part of the scope of TRACK. 685 (d) Multicast IPsec. Although currently IPsec is generally implemented 686 for pair-wise (one-to-one) communications between one sender and one 687 receiver, the design of IPsec itself allows for usage in IP 688 multicast. Currently the Security Association (SA) definition 689 requires the Security Parameter Index (SPI) to be selected by the 690 receiver [KA98a]. However, since in IP multicast a group address 691 may be associated with multiple receivers, the existing method of 692 selecting the SPI must be re-interpreted. Hence, in the context of 693 "Multicast IPsec", a pre-defined entity (e.g. the source, or the key 694 server/manager) MUST first create the Group-SA (including selecting 695 the SPI) and deliver the Group-SA to all the members of the group 696 (by either the "push" or "pull" paradigm). Thus rather than being a 697 modification to the IPsec specification, this requirement simply 698 means that additional protocols are needed to establish a shared 699 Group-SA. One possible approach for the Group Key Management (GKM) 700 protocol is to also deliver the Group-SA (and other keying material) 701 to the receiver at the same time it delivers the GroupDataKey 702 [HCM98]. 704 8. Summary 706 In summary, in the current work we have proposed for TRACK the 707 separation of data stream confidentiality using a symmetric key (i.e. 708 implicit group-authentication) from data authentication using a 709 symmetric key (i.e. explicit group-authentication). Data stream 710 confidentiality using a symmetric key SHOULD be conducted at the 711 application layer, while data authentication using a symmetric key 712 SHOULD be conducted at the network layer. Since the RHs MAY be 713 prevented from reading the multicast data, two (2) different symmetric 714 keys SHOULD be deployed corresponding to the needs of data stream 715 confidentiality and data group-authentication. 717 This proposal follows a number of requirements, some of which are 718 specific to TRACK. The use of group-authentication at the network layer 719 is: 720 - for protection of the transport and IP headers. 721 - to allow a RH to authentically retransmit lost packets to 722 a destination address (unicast or local multicast) different 723 from the original multicast group address. 724 - to allow a separate symmetric key encryption to be applied 725 (at the application layer) in order prevent the RHs from 726 reading the data. 728 We assume encryption for confidentiality (using the GroupDataKey) has 729 been applied above the transport layer by the sender/source, in order to 730 prevent a RH from decrypting the data. The GroupDataKey is only 731 available to the group members, excluding the interior control nodes. 733 We propose the use of another key (GroupAuthKey) to provide group- 734 authentication from the source/sender at the network layer using 735 symmetric key cryptography. The GroupAuthKey is known by the members of 736 the group, as well as the interior control nodes. 738 For the retransmission of lost packets to regions within a group, either 739 via unicast or local multicast, we propose the use of a SubgroupAuthKey 740 (instead of the GroupAuthKey) which is known only to entities within a 741 region (RH and its children). The SubgroupAuthKey is also used by the 742 entities in a region to group-authenticate control messages that are 743 exchanged with each other. 745 9. References 747 [B97] Bradner, S., "Key words for use in RFCs to Indicate Requirement 748 Levels", BCP 14, RFC 2119, March 1997. 750 [HCM98] T. Hardjono, B. Cain and I. Monga, "Intra-Domain Group Key 751 Management Protocol", work in progress, draft-irtf-smug-intragkm-00.txt, 752 September 2000. 754 [HH99a] H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleischer, 755 "Group Security Association Key Management Protocol", work in progress, 756 draft-ietf-msec-gsakmp-sec-00.txt, March 2001. 758 [KCWP00] M. Kadansky, D. Chiu, J. Wesley, J. Provino. "Tree-based 759 Reliable Multicast (TRAM)", work in progress, draft-kadansky-tram- 760 02.txt, January 2000. 762 [KA98a] S. Kent and R. Atkinson, "Security Architecture for the Internet 763 Protocol", IETF, RFC 2401, November 1998. 765 [KA98b] S. Kent and R. Atkinson, "IP Authentication Header", IETF, RFC 766 2402, November 1998. 768 [MG98a] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", 769 IETF, RFC 2403, November 1998. 771 [MG98b] C. Madson, R Glenn, The Use of HMAC-SHA-1-96 within ESP and AH", 772 IETF, RFC 2404, November 1998. 774 [R92] R. Rivest, "MD5 Digest Algorithm", RFC 1321, April 1992. 776 [RSA93] RSA Laboratories, "PKCS#1: RSA Encryption Standard", Volume1.5, 777 No. 1993. 779 [WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, "RMTP-II 780 Specification". Work in progress, draft-whetten-rmtp-ii-00.txt, April 781 8, 1998.