idnits 2.17.1 draft-ietf-ipsec-gkmframework-03.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 18) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages 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.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (August 2000) is 8648 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1-4' on line 186 looks like a reference -- Missing reference section? '5-7' on line 186 looks like a reference -- Missing reference section? '8' on line 1046 looks like a reference -- Missing reference section? '9' on line 1049 looks like a reference -- Missing reference section? '10-13' on line 216 looks like a reference -- Missing reference section? '11' on line 1053 looks like a reference -- Missing reference section? '12' on line 1055 looks like a reference -- Missing reference section? '10' on line 1051 looks like a reference -- Missing reference section? '13' on line 1057 looks like a reference -- Missing reference section? '14' on line 1060 looks like a reference -- Missing reference section? '15' on line 1062 looks like a reference -- Missing reference section? '2' on line 1026 looks like a reference -- Missing reference section? '16' on line 1065 looks like a reference -- Missing reference section? '1' on line 1023 looks like a reference -- Missing reference section? '3' on line 1029 looks like a reference -- Missing reference section? '4' on line 1033 looks like a reference -- Missing reference section? '5' on line 1036 looks like a reference -- Missing reference section? '6' on line 1038 looks like a reference -- Missing reference section? '7' on line 1042 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force T. Hardjono (Nortel) 2 INTERNET-DRAFT B. Cain (Mirror Image) 3 draft-ietf-ipsec-gkmframework-03.txt N. Doraswamy (Photonex) 4 August 2000 5 Expires: February 2001 7 A Framework for Group Key Management for Multicast Security 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 provides a framework for group key management for 35 multicast security, motivated by three main considerations, namely 36 the multicast application, scalability and trust-relationships among 37 entities. It introduces two planes corresponding to the network 38 entities and functions important to multicasting and to security. The 39 key management plane consists of two hierarchy-levels in the form of 40 a single "trunk region" (inter-region) and one or more "leaf regions" 41 (intra-region). The advantages of the framework among others 42 are that it is scalable, it has reduced complexity and allows the 43 independence in regions of group key management. 45 Table of Contents 47 1. Scope of Document and Philosophy . . . . . . . . . . . . . . . 3 48 2. Group Key Management: Background . . . . . . . . . . . . . . . 5 49 3. Group Key Management: Issues . . . . . . . . . . . . . . . . . 6 50 3.1 Multicast Application Types. . . . . . . . . . . . . . . . 7 51 3.1.1 One-to-Many Multicast Applications . . . . . . . . . 7 52 3.1.2 Many-to-Many Multicast Applications. . . . . . . . . 8 53 3.2 Size and Distribution of Group Members . . . . . . . . . . 8 54 3.3 Scalability of Protocols and Membership Management . . . . 9 55 3.4 Independence of GKM Protocols . . . . . . . . . . . . . . 10 56 3.5 Trust-Relationships . . . . . . . . . . . . . . . . . . . 10 57 3.6 Group Authentication and Sender Authentication. . . . . . 11 58 3.7 Identities and Anonymity. . . . . . . . . . . . . . . . . 11 59 3.8 Access Control. . . . . . . . . . . . . . . . . . . . . . 12 60 3.9 Membership Verification . . . . . . . . . . . . . . . . . 13 61 3.10 Failure of Systems . . . . . . . . . . . . . . . . . . . 13 62 3.11 Other Issues . . . . . . . . . . . . . . . . . . . . . . 14 63 4. Framework: Basic Model. . . . . . . . . . . . . . . . . . . . 15 64 4.1 Basic Model . . . . . . . . . . . . . . . . . . . . . . . 15 65 4.2 Trunk-Keys and Leaf-Keys. . . . . . . . . . . . . . . . . 17 66 4.3 Interpretations of Regions. . . . . . . . . . . . . . . . 18 67 4.4 Security Associations and Secure Channels . . . . . . . . 18 68 4.5 Advantages of the Framework . . . . . . . . . . . . . . . 18 69 5. Example of Framework Application. . . . . . . . . . . . . . . 19 70 5.1 One-to-Many Multicast Example . . . . . . . . . . . . . . 19 71 5.1.1 Scope of Leaf Regions . . . . . . . . . . . . . . . 19 72 5.1.2 Location of Key Managers. . . . . . . . . . . . . . 20 73 5.1.3 Advertising Key Managers. . . . . . . . . . . . . . 21 74 5.2 Many-to-Many Multicast Example. . . . . . . . . . . . . . 21 75 5.2.1 Location of Key Managers. . . . . . . . . . . . . . 21 76 5.2.2 Scope of Leaf Regions . . . . . . . . . . . . . . . 21 77 5.2.3 Advertising Key Managers. . . . . . . . . . . . . . 22 78 6. References. . . . . . . . . . . . . . . . . . . . . . . . . . 22 79 7. Authors Addresses . . . . . . . . . . . . . . . . . . . . . . 23 80 1. Scope of Document and Philosophy 82 This document proposes a framework for group key management (GKM) for 83 multicast security on the Internet. The objective of the framework 84 is to foster the development of an Internet-wide solution while 85 encouraging innovations in solving the many problems that are related 86 to multicast security. Since multicast security has many complex 87 facets, related to multicast technologies and security technologies 88 respectively, the following two-pronged approach is recommended 89 corresponding to a two level hierarchy: 91 1. Encourage the growth and evolution of novel secure solutions for 92 group key management within pre-defined key management "regions" 93 ("domains") whose scope is determined on a per-case basis. 94 Regions can be defined to be size of subnets, autonomous systems 95 (AS), or larger. This will allow for the development of 96 independent and innovative solutions that are addressed for 97 specifically for such regions, taking into consideration the 98 multicast application being employed. 100 2. Encourage secure, simple, consistent and stable interactions 101 between the key management regions that implement the various 102 group key management solutions. This will allow for the 103 development of innovative "inter-region" ("inter-domain") 104 solutions that can consistently and securely tie together the 105 various regions deploying "intra-region" ("intra-domain") group 106 key management protocols. 108 By defining "regions" of group key management, various schemes can be 109 used for each region independent of one another, with only the 110 requirement that they can interact with a common, and simple, "inter- 111 region" group key management protocol. In this way, the need of a 112 single all-encompassing scheme for Internet-wide group key management 113 will be removed. This will allow for different region-scoped group 114 key management schemes to be developed concurrently while an "inter- 115 region" scheme and architecture is being developed. 117 The aim of this document is to describe a simple framework for group 118 key management that addresses some issues specific to multicast 119 security. In doing so, the framework relies on existing security 120 technologies, notably IPsec and its related protocols for unicast key 121 management. It is not the aim of the document to specify the details 122 of a group key management scheme or architecture. Nor is it an 123 objective to specify the details of the interactions of group key 124 management schemes between regions that implement them. On the 125 region level, the goal is to develop basic GKM requirements, while 126 allowing maximum freedom for the development of solutions. On the 127 Internet-wide scale, the aim is to identify basic GKM functions and 128 facilitate the development of a protocol (or enhancement of an 129 existing GKM protocol) that allows relatively simple interactions 130 between regions of group key management. 132 The framework proposed in this document approaches the multicast 133 security problem, and more specifically, the group key management 134 problem, by first introducing two planes corresponding to the network 135 entities and functions pertaining to multicasting and to security. 136 The first plane, called network infrastructure plane, encompasses the 137 entities and functions that define the network, which in the case of 138 IP multicasting includes the various protocols (eg. routing 139 protocols) and the entities that implement them (eg. routers, hosts). 140 The second plane, called the key management plane, encompasses the 141 entities and functions of the network define and establish security 142 in the network, which in the case of IP multicasting includes 143 security-related protocols (ie. GKM protocols, IPsec and its related 144 protocols, cryptosystems) and entities that implement them (eg. key 145 generators, key managers, policy server, routers). 147 Within the key management plane two hierarchy of regions are 148 introduced, namely one "trunk region" and one or more "leaf regions". 149 The trunk region is bounded by certain key manager entities and does 150 not contain any member hosts (senders/receivers). All member hosts 151 are defined to exist within leaf regions, each of which is associated 152 with (at least) one key manager entity. The purpose of introducing 153 leaf regions and a trunk region is for the framework to inherently 154 promote scalability by allowing regions to be defined according to 155 the available entities and protocols in underlying network 156 infrastructure plane and according to the multicast application under 157 consideration. 159 Since the current framework also aims at promoting the clear 160 identification of trust-relationships that exists (both explicitly 161 and implicitly) among entities in the network that are involved in 162 securing multicast, it has identified two general multicast 163 application types that have differing trust-relationships. These are 164 the One-to-Many multicast applications and the Many-to-Many multicast 165 applications. 167 From the security perspective, the identification of the two 168 multicast application types is aimed at distinguishing the different 169 possible mappings between the two planes, which in turn determines 170 the trusted entities involved in securing the multicast transmission 171 and also determines the trust-relationships among the entities. This 172 process in turn determines the jurisdictions over the key managers in 173 the two respective multicast applications, and thus the physical 174 locations of the key managers. 176 The jurisdiction over the key managers and the locations of the key 177 managers will then determine to a large extent the applicable "intra- 178 region" group key management within each leaf region and the suitable 179 "inter-region" solution that binds the leaf regions together 180 securely. 182 2. Group Key Management: Background 184 The topic of group-oriented security has been researched for over two 185 decades now, particularly in the area of cryptology in the context of 186 secure conferences (eg. [1-4]), secret-sharing (eg. [5-7]) and 187 digital multi-signatures (eg. [8]). Most of the results of such 188 research has been theoretical, which are valuable in the long term, 189 but which are too difficult or too computationally-intensive to be 190 implemented as a solution to the current pressing multicast security 191 needs. 193 The IETF has provided security standards for the Internet by 194 introducing the IPsec standard and its related technologies [9]. 195 Although these technologies satisfy to a large extent the needs of 196 secure communications in the Internet, they are aimed mainly at 197 unicast transmissions between one sender and one receiver. 199 More recent efforts to address the security needs multicast have 200 taken the form of group key management protocols with the aim of 201 securely delivering a common key to all members of a multicast group. 202 Having such a key allows group members to encipher the traffic 203 within the multicast group. Thus, the group key also affords 204 membership-enforcement by only allowing key holders to decipher the 205 multicast traffic. A sender must encipher all traffic that it sends 206 to the group. 208 The advantage of having a group key is that a sender avoids having to 209 encipher traffic individually for each receiver. However, related to 210 this is the issue of re-keying of the group key should a member 211 ceases membership of a new host takes-on membership. 213 Although group-authentication is implicitly provided through the 214 possession of the key, sender-authentication must be provided through 215 other means (eg. signature of individual sender). Examples of GKM 216 protocols can be found in [10-13]. Some, if not all, of these 217 proposals suffer from one drawback or another, the most common being 218 scalability in the context of re-keying. 220 The work of [11] employs a Group Controller which works in 221 conjunction with group members in creating and delivering keys to the 222 members. The group controller also performs checking on the 223 permission of candidate members. The use of a centralized entity to 224 control key management presents limitations from the perspective of 225 scalability. 227 The problem of scalability is directly addressed by the work of [12], 228 where a hierarchical ordering of subgroups is employed to limit the 229 effects of re-keying. The key management at different levels of the 230 hierarchy is carried-out by different controller entities. Thus, when 231 re-keying occurs to a member within a subgroup, only the members in 232 that subgroup will be affected. Although the scheme points to an 233 attractive direction in terms of limiting the effects of re-keying, 234 it suffers the drawback of needing a decryption/re-encryption of 235 traffic as it enters or leaves a subgroup. (This drawback can be 236 limited to a certain extent if the controller entities perform their 237 decryptions and re-encryptions using cryptographic hardware). 239 The work of [10] follows from the work on the Core Based Trees (CBT) 240 multicast routing protocol. Here, the idea is to employ the core of 241 the tree to distribute keys to candidate members, who must contact 242 certain routers that are connected to the core. These routers then 243 carry-out membership checks and key distribution to the candidate 244 members. Although the scheme maybe scalable, it is dependent on CBT 245 as the multicast routing protocol and hence poses difficulties when 246 used with other multicast routing protocols. 248 The recent proposal of [13] addresses the scalability problem by 249 separating the key generation entity from the key distribution 250 entity. The key distribution entity can be dynamically added by 251 requesting their participation. Authority would then be delegated to 252 such key distribution entities together with access control lists. 253 Candidate members can then request membership and a copy of the group 254 key from the key managers. Although promising and can be 255 hierarchically organized, the extent of the scalability of the 256 approach remains to be seen due to the problem of re-keying in the 257 case of hosts joining/leaving. 259 One promising direction has been the recent work of [14]. Here, a 260 logical tree of keys is created at a server that generates all the 261 keys and coordinates the key management among the members of the 262 group. The members are divided into subgroups, each being assigned a 263 key. Depending on the need, the keys at different levels in the 264 logical tree would then be applied. Although attractive, as it stands 265 the scheme of does not scale well due to the dependence on a 266 centralized server for all aspects of key management. More 267 specifically, the need of the server to hold the private-key of each 268 member may prove to be too burdensome for the server. 270 3. Group Key Management: Issues 272 There are a number of issues related to multicast security in 273 general, and more specifically group key management. These issues are 274 listed (non-exhaustive) in the following and are discussed in the 275 ensuing sections. 277 - Multicast application types 278 - Size and distribution of members 279 - Scalability of protocols and membership management 280 - Independence of GKM protocol 281 - Trust-relationships 282 - Group authentication and sender authentication 283 - Identities and anonymity 284 - Access control and membership verification 285 - Security and practicality of protocols 286 - Failure of systems 287 - Denial of service (DOS) attacks 289 3.1 Multicast Application Types 291 The current framework recognizes that an all-encompassing solution 292 for multicast security is difficult, if not impossible, to achieve 293 (and even undesirable) due the various multicast applications that 294 exist today and may emerge in the future. To this end, two general 295 multicast application types have been identified in the effort to 296 provide a common ground for discussing the issues related to 297 multicast security and group key management. 299 3.1.1 One-to-Many Multicast Applications 301 The first multicast application type covers the cases where the 302 multicast group has one sender and multiple receivers. Transmission 303 is unidirectional from one sender to many receivers. The receivers 304 are assumed to be passive consumers of the data, while the single 305 sender is the producer of the data. The initiator of the group is 306 assumed to be its owner, and for simplicity it is also assumed to be 307 the sender. Examples this multicast application includes Pay Per View 308 (PPV) programs (eg. Internet TV, Radio, Video) and other real-time 309 data (eg. news, stock prices, etc). 311 The One-to-Many multicast applications correspond to the cases where 312 the transmitted data carries an immediate value for which the 313 receivers must also be subscribers. Hence, they would be of interest 314 to commercial companies seeking to use multicast as a medium for 315 transmitting data over the Internet to as wider audience as possible. 317 Two general cases exist with respect to the data being transmitted. 318 In the first case, the group is concerned more about the authenticity 319 and integrity of the data, and not so much its confidentiality. An 320 example would be subscriptions to publicly available data (eg. stock 321 market data, government publications). These desired effects can be 322 achieved using public key techniques and message integrity 323 techniques, leaving the data itself readable to non-members. 325 Of more concern here is the second case, where the aim is to prevent 326 non-members from accessing the data. An example would be 327 subscriptions to subscribers-only transmissions (eg. pay per view 328 Internet TV). Here, encryption techniques can be used for 329 controlling access to the data. 331 It is in the interest of the initiator/sender to ensure that only 332 legitimate members (subscribers) of the group obtain access to the 333 contents of the multicast, by encrypting the contents. It is also in 334 the interest of the initiator/sender to ensure that only legitimate 335 members of the group obtain a copy of the encryption key. 336 Consequently, it is in the interest of the sender/initiator to be in 337 control over the entities that implement group key management (eg. 338 key managers). 340 3.1.2 Many-to-Many Multicast Applications 342 The Many-to-Many multicast application type refers to the case where 343 the relationship between the sender and receiver(s) is equal 344 (democratic) and where the data is of immediate value only to the 345 members of the group. Every member of the multicast group is both a 346 sender and a receiver. An example of this multicast application would 347 be conferencing. 349 Membership of the group maybe Open or Closed. In the Open Many-to- 350 Many multicast anyone can join the conference provided that the 351 identity of the member is known. In the Closed Many-to-Many 352 multicast only a predefined number of members can join, and the 353 identities of the members are known in advance. 355 The aim in the Many-to-Many multicast application type is to prevent 356 non-members from accessing the data. Hence, encryption (in addition 357 to message authenticity and integrity techniques) is used for 358 controlling access to the data that is of immediate value only to the 359 members of the group. 361 It is in the interest of all members of the group to ensure that only 362 legitimate members obtain access to the contents of the multicast. 363 Consequently, it is in the interest of members to select the entity 364 it controls under its jurisdiction to participate in the group key 365 management. 367 3.2 Size and Distribution of Group Members 369 The IP multicast model is attractive because its membership can 370 extend throughout the Internet, subject only the capability of the 371 multicast routing protocol and the availability of resources. One of 372 the main attractive points about the IP multicast model is that, in 373 effect, a large numbers of host members can be reached without the 374 sender needing to know the size of the group and the distribution of 375 the group. 377 In the context of security, however, the identity of the 378 communicating parties is an inherent requirement of authentic and 379 confidential communications. In IPsec it is the basis of the 380 security association between two communicating parties, which leads 381 to the secure key-agreement between them. Hence, in GKM protocols 382 that employ secured unicast communications, the size and distribution 383 of the members become issues that have a direct impact on the 384 scalability of the protocols. 386 The effectiveness of a group key management protocol and its 387 underlying multicast routing protocol is dependent to a certain 388 extent on the size of the group and on the distribution of the group 389 (dense or sparse). Related to this is also the issue of the 390 frequency of changes to the membership, which may lead to the need of 391 re-keying and other changes in the security parameters of the group. 393 3.3 Scalability of Protocols and Membership Management 395 One of the primary issues in group key management is that of the 396 scalability of the protocols it employs. Often these protocols rely 397 on one (or few) security-managing entity (eg. key server) that is 398 assumed to be trusted by all other entities in the entire Internet. 399 Furthermore, the protocols often require host members to communicate 400 securely with the entity (unicast). Not only does the entity (or 401 entities) become a bottleneck in the scheme, it also becomes the 402 "best" point of attack by intruders since it necessarily holds 403 security parameters pertaining to the host members. 405 Also impacting scalability of protocols is the method used to perform 406 a re-keying of the group key due a host member leaving the group or a 407 new one joining. Re-keying of the group key involves a new group key 408 being delivered to the (affected) members of the group. Ideally, a 409 protocol should strive to minimize the number of affected host 410 members in the case of re-keying and to minimize the number of 411 messages exchanged during the re-key process, particularly if secure 412 (authentic and confidential) unicast messages must be exchanged. The 413 work of [12] on the Iolus system represent a conscious attempt 414 address this problem by specifically designating areas that would be 415 affected by a re-keying event due to changes in the membership of the 416 group. 418 Other issues related to membership management include specifying how 419 the decision regarding members joining or leaving (or ejection) is 420 reached. This issue is largely dependent on the multicast 421 application being employed. 423 3.4 Independence of GKM Protocols 425 Regardless of the scope of a group key management protocol, such a 426 protocol must be independent of (or decoupled from) the underlying 427 multicast routing protocol, thereby allowing it to be used in 428 conjunction with various multicast routing protocols. This, however, 429 does not exclude the use of GKM protocols that are tightly coupled 430 with a given multicast routing protocol should it be chosen for 431 certain areas or organizations in the Internet. 433 For a GKM protocol to be independent from multicast routing 434 protocols, the GKM protocol must not rely on the structures (eg. 435 distribution tree) and mechanisms inherent to any particular routing 436 protocol. A GKM protocol must also be separate from the session 437 advertisement protocol (eg. SAP). However, sufficient information 438 about a group and its related GKM protocol security parameters must 439 be advertised in order for a host wishing to become a member to 440 engage in the GKM protocol. 442 3.5 Trust-Relationships 444 Many group key management protocols for multicast security have 445 proposed the use of certain entities to manage security-related 446 information and parameters without specifying: 448 - on what basis such an entity is accorded trust 449 - who accorded the trust to the entity 450 - under whose jurisdiction (administrative or otherwise) the 451 entity resides 452 - who else in the Internet is assumed to trust that entity 454 The problem of trust-relationship is a difficult one and several 455 factors influence it, among others: 457 - the multicast application and the definition of regions may 458 influence one another, which may also influence the 459 applicable group key management protocols 461 - the distribution of the members over the Internet may 462 influence which entities are trusted by the members 463 (eg. a member may only trust entities physically within 464 its country) 466 - the availability (or lack) of a certification infrastructure 467 that allows for certificates specifying trust to be widely 468 accessible on the Internet and for delegations to occur 470 - historical records about attacks to certain areas or 471 organizations on the Internet may deter host members from 472 trusting entities in that area/organization 474 Research on this issue has been continuing for a number of years. 475 However, a practical approach embodying trust-relationships 476 specifically for multicast security on the Internet has yet to be 477 proposed. 479 In the long term, one possible solution to this problem may consist 480 of the codification within certificates of the trust between 481 organizations in the manner of Service Level Agreements (SLA). Such 482 certificates may then be the basis for accepting or rejecting 483 entities that manage security-related information and parameters. 485 3.6 Group Authentication and Sender Authentication 487 In schemes in which a group key is used to encrypt the group traffic 488 to afford membership control the decipherability of a multicast 489 packet implies its origination from one of the members of the 490 multicast group. That is, group authentication is achieved at the 491 same time as data confidentiality. 493 This level of authentication, although sufficient for some multicast 494 applications, may not be enough for other applications in which the 495 precise identity of the sender of the multicast packet needs to be 496 known by the receivers of the packet. That is, sender authentication 497 must be provided in addition to group authentication. 499 One simple approach to sender authentication within a multicast group 500 would be for each member of the group to digitally sign the messages 501 it sends, before the message is enciphered using the group key. This 502 approach requires the use of public key cryptography, and depending 503 on the multicast application, it may also require the existence of a 504 public key infrastructure for its scalability. 506 3.7 Identities and Anonymity 508 As referred to previously, one of the attractive points about the IP 509 multicast model is that, in effect, a large numbers of host members 510 could be reached without the sender knowing identity of the 511 receivers. IGMP Membership-reports are used by the receivers to 512 report about memberships. The presence or absence of (at least) a 513 member determines whether the router joins onto the multicast 514 distribution tree. The identity of a member (eg. IP address) is 515 never relayed by the router to the sender, and hence the sender never 516 knows the identity of the receiver. 518 In secure communications between a sender a receiver, the identity of 519 each of the communicating parties is an important parameter which 520 must be convincingly verified by the other. This is typically 521 achieved by resorting to certificates that embody the identity, 522 supported by a certification infrastructure. In the context of 523 multicast at the network layer the certificate for a host must 524 contain the Distinguished Name (DN) or other equivalent unique 525 identification information corresponding to the host. This 526 verifiable identity becomes the basis for a host being admitted into 527 a multicast group and for the host to be given the group key through 528 the appropriate GKM protocol. 530 Since the current framework views IPsec and its related technologies 531 for unicast security as the building blocks for multicast security 532 (and that IPsec requires the identities to be known) it makes little 533 sense to discuss anonymity of hosts at the network layer (or lower). 534 The issue of anonymity is better addressed at the application layer. 535 It must be pointed-out, however, that anonymity does not imply non- 536 identification. That is, even in systems that feature anonymity (eg. 537 electronic payment systems) a unique pseudonym [15] is used to 538 identify one user from another. It is the mapping of the pseudonym to 539 the user's personal information that must remain secret. 541 3.8 Access Control 543 The IP multicast model allows for any host to become a member of the 544 group simply by requesting to join the group. Other group members 545 may not necessarily be aware of the existence of other members in the 546 group. 548 Although the IP multicast model may be attractive in its native form 549 to some applications, from the perspective of security such unlimited 550 membership may be undesirable. The current framework views access 551 control policies and their implementation to be an issue tightly 552 related to the multicast application type. 554 Similar to the independence (decoupling) of the group key management 555 protocol from the underlying multicast routing protocol, the current 556 framework proposes the independence of the group key management 557 protocol from the access control model and implementation. This does 558 not, however, preclude the possible developments (or extensions) of 559 multicast routing protocols that exhibit some form of (limited) 560 access control. 562 3.9 Membership Verification 564 Related to access control and member identities is the need for 565 membership verification at the network layer. More specifically, 566 membership verification refers to the ability of a member of a 567 multicast group to request information and self-verify the 568 constituents of the group. Although this functionality may not be 569 necessary (or even undesirable) in certain multicast applications 570 (eg. pay per view transmissions), it may be highly desirable for 571 other applications (eg. conferencing). 573 Solutions to the membership verification issue have been suggested in 574 the context of cryptographic conference key distribution schemes, in 575 which membership verification is in-built into the scheme itself or 576 is a major feature of the scheme (eg. [2, 16]). However, the 577 complexity of these cryptography-based solutions may point to the 578 application layer as being the best place for them to be implemented. 580 In general, at the very minimal membership verification can be 581 achieved by a trusted party (eg. group initiator) vouching for a 582 membership-list by digitally-signing it and distributing it to all 583 group members. Such a trusted party may be one from which new 584 members must obtain group-keys when they join the group, and hence 585 will in fact hold security information pertaining to each member of 586 the group. 588 Another possible approach is to deploy a special membership 589 verification protocol, much in the spirit of IGMP, which reports in a 590 secure fashion about the membership identities within a given subnet 591 or a larger area. Such an approach will be related to the existence 592 of a certification infrastructure and have to address the issue of 593 the trustworthiness of the entities (eg. router) than implement the 594 membership verification protocol. 596 3.10 Failure of Systems 598 It is a requirement that when a network entity (eg. host or a router) 599 carrying security parameters fails, it must not divulge or allow the 600 security parameters that it holds to be compromised in anyway. The 601 security of the entity must not be lessened when the entity 602 experiences failure. Hence, the entity must exhibit a "fail-closed" 603 behaviour with respect to security. 605 Although to a large extent this issue is one related to systems 606 implementation, the awareness of potential vulnerabilities that may 607 exist when an entity boots-up or fails should lead protocol designers 608 and implementers to take this matter into consideration when 609 developing hardware and software for network elements. 611 3.11 Other Issues 613 There are other issues related to the security of multicast and to 614 group key management. These are listed as follows (not exhaustive): 616 - Denial of service (DOS) attacks 617 - Authenticity of multicast routing exchanges 618 - Non-repudiation of group membership and key possession 619 - Frequency of periodic re-keying 620 - Tamper-proof storage on network entities (eg. routers) 621 - Secure boot-up of multicast-related network entities 623 4. Framework: Basic Model 625 Although there are a variety of multicast security issues that must 626 be resolved, the current framework is motivated by three main 627 considerations, namely the multicast application, scalability and 628 trust-relationships among entities. The framework aims at being as 629 general as possible while remaining practical and useful. 631 The framework proposed in this document approaches the multicast 632 security problem, and more specifically, the group key management 633 problem, by first introducing two planes corresponding to the network 634 entities and functions pertaining to multicasting and to security. 635 The first plane, called "network infrastructure plane", encompasses 636 the entities and functions that define the network, which in the case 637 of IP multicasting includes the various protocols (eg. routing 638 protocols) and the entities that implement them (eg. routers, hosts). 639 The second plane, called the key management plane, encompasses the 640 entities and functions of the network define and establish security 641 in the network, which in the case of IP multicasting includes 642 security-related protocols (ie. GKM protocols, IPsec and its related 643 protocols, cryptosystems) and entities that implement them (eg. key 644 generators, key managers, policy server, routers). 646 Within the key management plane two hierarchies (levels) of regions 647 are introduced, namely one "trunk region" and one or more "leaf 648 regions". The trunk region is bounded by certain key manager 649 entities and does not contain any member hosts (senders/receivers). 650 All member hosts are defined to exist within leaf regions, each of 651 which is associated with (at least) one key manager entity. The 652 purpose of introducing leaf regions and a trunk region is for the 653 framework to inherently promote scalability by allowing regions to be 654 defined according to the available entities and protocols in 655 underlying network infrastructure plane and according to the 656 multicast application under consideration. 658 Although the current framework proposes a two-level hierarchy (namely 659 a trunk region and leaf regions) in the key management plane, it does 660 not preclude the use of a single-level arrangement. In a single- 661 level arrangement the framework essentially consists of a large leaf- 662 region. The usability of a single-level region from the perspective 663 of scalability would be dependent on the multicast application type 664 and the size/distribution of the group members. 666 4.1 Basic Model 668 Network infrastructure plane: 670 This view is a physical/topological view. The Internet is seen 671 a collection of autonomous systems (AS), some being Stub ASs 672 and others being Transit ASs (ie. ISPs) and various backbone 673 connections. 675 This plane identifies the entities and functions that define 676 the network, which in the case of IP multicasting includes the 677 various protocols (eg. routing protocols) and the entities that 678 implement them (eg. routers, hosts). 680 Key management plane: 682 This plane encompasses the entities and functions of the 683 network that promote and implement security in the network. 684 For multicast security these include security-related protocols 685 (ie. GKM protocols, IPsec and its related protocols, 686 cryptosystems) and the entities that implement them 687 (eg. key generators, key managers, policy server, routers). 689 Key management regions: 690 This plane also introduces the logical structure consisting 691 of a key management "trunk region" and one or more key 692 management "leaf regions" (Figure 1). This size/scope of 693 these regions is determined by multicast application in 694 question. 696 Key Managers (KMs): 697 One important entity in the current model is the 698 Key Manager (KM) entity. Two kinds of KMs are assumed to 699 exist, namely Border KMs and Non-Border KMs. 701 The trunk region is bounded by Border KMs and does not 702 contain any member hosts (ie. no sender/producer or 703 receiver/consumer of the multicast traffic). 704 Each leaf region is associated with (at least) 705 one Border KM. 707 Non-Border KMs may reside inside the trunk region or inside 708 leaf regions. However, they do not participate in the 709 definition of the boundary (scope) between the trunk region 710 and leaf regions. 712 Member hosts are defined to exist within leaf regions. A 713 leaf region is defined to contain a member host (at least 714 one) and one (or more) multicast-capable routers. 716 As an example, the mapping of the two planes may result in 717 an instance where a leaf region maps to a Stub AS and the 718 trunk region maps to a set of Transit ASs. 720 If there are multiple KMs then a method of election for the 721 principal KM for the region is assumed to be employed (the 722 method of election beyond the scope of this document). 724 Leaf 725 ----------- 726 | m m m | 727 | | 728 | R KT| 729 ----------- 730 KM 731 -------------------- 732 | | 733 ----------- | KM R KM | ----------- 734 | m | | | | m | 735 | m R|KM| R R |KM|R m | 736 | m KT| | | |KT m | 737 ----------- | KM R KM | ----------- 738 Leaf | | leaf 739 -------------------- 740 Trunk 742 Figure 1: Framework � Key Management Plane 744 Key Translators (KTs): 745 Another important entity in the current model is the 746 Key Translator (KT) entity. The function of the KT entity 747 is to "translate" payload (which can be either multicast 748 data or the group key) from being encrypted under one key 749 to another key. The process of decrypting payload 750 (ciphertext) using one key and enciphering the resulting 751 plaintext using another key is must be atomic, reliable and 752 tamper-free. Each leaf region is associated with one (or 753 more) KT entity. Such a KT entity may be implemented in the 754 form of a fast router or server, containing high-capacity 755 cryptographic hardware or software. The translation may 756 be applied to multicast data or used for key management 757 purposes (eg. delivering a group key). 759 4.2 Trunk-Keys and Leaf-Keys 761 In the current framework each key management region (trunk region and 762 leaf regions) is assumed to be associated with a different 763 cryptographic key. A leaf region is assumed to be associated with a 764 unique leaf-key, while the trunk region is associated with a trunk- 765 key. 767 The trunk-key is only known among the Border KMs. The trunk-key is 768 generated through an (inter-region) group key management protocol in 769 the trunk region among the Border KMs. 771 Leaf-keys are generated through the local group key management (GKM) 772 protocol (such as [13]), whose scope of key distribution is defined 773 to be limited to the size of the leaf region. 775 Since the Border KMs demarcate the boundary between the trunk region 776 and the leaf regions, the Border KM associated with a given leaf 777 region also holds a copy of the leaf-key of that leaf region. The 778 Border KM associated with a leaf region is assumed to be involved in 779 the local GKM protocol of that leaf region. 781 In summary, a Border KM associated with a leaf region holds a copy of 782 the trunk-key which it shares only with the other Border KMs and it 783 holds a copy of the leaf-key of the leaf region with which it is 784 associated. A Border KM does not share the copy its leaf-key with 785 entities outside its associated leaf region. 787 For simplicity, in the remainder of the work the term "key manager" 788 or "KM" will refer to Border KMs. For any multicast group, the KM 789 (ie. Border KM) associated with the leaf region of the group 790 initiator will be called the Initiator KM (IKM). The leaf region 791 where the initiator resides will correspondingly be called the 792 Initiator Leaf, while the other leaf regions will be referred to as 793 Remote Leafs. The KM associated with a Remote Leaf will be referred 794 to as the Remote KM (RKM). 796 4.3 Interpretations of Regions 798 From the point of view of the application of cryptographic keys 799 (namely trunk-keys and leaf-keys), the logical structuring into 800 regions (trunk region and leaf regions) leads to (at least) two 801 possible interpretations: 803 (a) Regions for delivering a group key: 804 The region-based key management to create secure channels for 805 the purpose of the distribution of a (group-wide) group key. 806 The group key is then applied to the multicast data 807 in the group from Source/Sender to the Receiver (end-to-end), 808 without translations. The keys to create this channel must 809 in-turn be securely managed and are treated on a per-region 810 basis. Thus, the regions pertains to the secure channels. 812 (b) Regions for delivering multicast data: 813 Here, each region applies a different key to the multicast 814 data as it transits across regions (from the sender's 815 leaf region into the trunk region, and finally into the 816 receiver's leaf region). Hence, translations in the form 817 of decryption and re-encryption of the multicast data at 818 borders of regions occur. 820 These two interpretations do not contradict the scalability 821 requirement, since they both still produce the desired result of 822 limiting the effects of re-keying to that of regions. 823 Combinations of the two interpretations can also be conceived. 825 4.4 Security Associations and Secure Channels 827 A primary assumption in the current framework is that all security- 828 sensitive communications between entities is carried-out through 829 "secure channels" (with mutual authentication, data confidentiality 830 and data integrity). The secure channels are based on security 831 associations (SA) and are implemented using IPsec and its related 832 technologies. Also assumed in the use of certificates (and thus the 833 existence of a certification infrastructure) that underlies the 834 establishment of security associations and thus secure channels. 836 4.5 Advantages of the Framework 838 The current framework has a number of advantages. These are discussed 839 in the following. 841 Scalable: By design the framework promotes scalability since it 842 allows new leaf regions to be added, independent of existing 843 leaf regions and independent of the population of members in 844 each leaf region. 846 Reduced Complexity: By employing a limited level (2 level) of key 847 management regions, the complexity of key management for 848 multicast security is greatly reduced. Each leaf region can 849 perform its leaf-scoped key management functions independent of 850 other leaf regions. Key management among the KMs in the trunk 851 region can be performed independent of the key management in 852 leaf regions. 854 Long life of trunk keys: Due to the fact that the trunk region 855 employs a different key (trunk-key) from the leaf regions, the 856 KMs need not re-key the trunk-key immediately when a member of 857 a multicast group in the leaf region leaves or is ejected. The 858 KM can keep its copy of the trunk-key even after its associated 859 leaf region ceases to have any members of the multicast group. 861 Grafting new members: Since the KM associated with a leaf region does 862 not need to immediately discard its copy of the trunk-key after 863 the associated leaf region ceases to have any members, the KM 864 is ready for the grafting of the new members in the associated 865 leaf region. The KM does not have to obtain a copy of the 866 trunk-key associated with a multicast group every time its 867 previously non-empty leaf region becomes devoid of members, and 868 then becomes populated again. 870 Independent Re-key Period: The trunk region and the leaf regions are 871 free to set their own periodic re-key period. Varied opinions 872 have been voiced in the field of computer and network security 873 regarding the need of periodic re-keying in any scenario where 874 communicating parties share a common "private" (symmetric) key. 875 This need is due to the increased vulnerability of frequently 876 used keys to cryptanalysis. 878 5. Examples of Framework Application 880 As mentioned previously, the size/scope of regions is influenced by 881 multicast application in question. The mapping between the network 882 infrastructure plane and the key management plane also defines the 883 entities involved in the multicast instance, most notably the Key 884 Managers (KMs). The physical location of the KMs and the 885 jurisdiction under which it functions is dependent on the multicast 886 application in question. In the following, two examples are given 887 based on the two multicast application type previously identified. 889 5.1 One-to-Many Multicast Example 891 5.1.1 Scope of Leaf Regions 893 The One-to-Many multicast application corresponds to the situation 894 where: 896 - the group has one sender and multiple receivers 897 - the multicast traffic carries direct value to non-members 898 - the attacker's gain lies in illegally re-distributing the 899 traffic to the widest audience 900 - example: Pay Per View (PPV) and other subscriber services 902 It is therefore in the interest of the initiator/sender to ensure 903 that only legitimate members (subscribers) of the group obtain access 904 to the contents of the multicast. Hence, it is in the interest of 905 the sender/initiator to be in control over the entities that 906 implement group key management. 908 Since the initiator/sender is the producer of the data, and 909 effectively the owner, and since there can be a variety of 910 configurations involving other parties (eg. ISPs), the 911 initiator/sender itself must: 913 - define the scope/size of each leaf region 914 - define the physical location of the key managers 915 - define the trust-relationships among the entities involved in 916 securing the multicast 918 The initiator may choose to define leaf regions to be the size of an 919 autonomous system, a larger region composed of several autonomous 920 system, a geographic state, geographic region of the country, or 921 larger. It may define leaf regions to be a function of the 922 accessibility provided by an Internet Service Provider or similar 923 organizations. 925 5.1.2 Location of Key Managers 927 The issue of selecting key managers that can be accorded trust is 928 largely determined on whether the initiator (producer) has control 929 (directly or indirectly) over the entity being the key manager: 931 Direct control: the initiator may choose to have several key managers 932 (eg. server farm), all physically within its own leaf region. 933 Each key manager would be associated one (remote) leaf region. 935 Indirect control: the initiator may choose to employ other parties 936 trusted to provide a given level of service based on some 937 agreement (ie. outsourcing). This is analogous to the concept 938 of trusted certification organizations where the notion of 939 trust is codified in the form of legally-binding contractual 940 agreements, in such a way that it is economically 941 disadvantageous for a trusted certification organization to 942 cheat. In the current context, the trusted third party can be 943 organizations such as Internet service providers (ISPs) to 944 which the initiator/sender is directly connected, trusted 945 certification organizations or other organizations offering 946 security management services. 948 5.1.3 Advertising Key Managers 950 The current framework is not concerned about how key managers are 951 advertised, but rather about what information is advertised about the 952 key managers. The list of available key managers can be made known to 953 hosts wishing to become a member through session advertisements (ie. 954 SAP/SDP) using one of two methods: 956 The advertisement carries not only the identity of the 957 Initiator KM (IKM), but also the list of the available KMs 958 associated with the multicast group. 960 The advertisement carries only the identity of the IKM. 961 Interested hosts must send the join-request to the advertised 962 IKM that will then forward it to the appropriate KM 963 (ie. IKM or RKM). 965 5.2 Many-to-Many Multicast Example 967 5.2.2 Location of Key Managers 969 The Many-to-Many multicast application corresponds to the situation 970 where: 972 - the group members are both senders and receivers 973 - the multicast traffic carries indirect value to non-members 974 - the attacker's gain lies in providing the contents of the 975 multicast to a limited audience 976 - Example: Confidential company conference meeting 978 The distribution of rights and obligations within the Many-to-Many 979 multicast application type is more democratic. It is in the interest 980 of each member to maintain the security of the multicast. Hence, it 981 is in the interest of each member to select the most trustworthy 982 entity under its jurisdiction to be the KM associated with the 983 member's leaf region and for that entity to be securely administered. 985 5.2.2 Scope of Leaf Regions 987 Here the implication is that the key manager associated with a leaf 988 region should be under the jurisdiction and administration of that 989 leaf region. This further implies that for Many-to-Many multicast 990 application type the most suitable size of a leaf region may be that 991 of an autonomous system (AS) corresponding to the members' 992 organization. Only by its own organization administering the key 993 manager can a member be assured that its interests are best served. 995 5.2.3 Advertising Key Managers 997 As mentioned previously, the current framework is not concerned about 998 how key managers are advertised, but rather about what information is 999 advertised about the key managers. The session advertisement (ie. 1000 SAP/SDP) for the Many-to-Many multicast application type must always 1001 carry the identity of the IKM. 1003 Depending on the openness of the membership of the group (ie. open or 1004 closed membership), upon creating a new multicast group the initiator 1005 host must provide the Initiator KM (IKM) with additional information: 1007 Open Many-to-Many: since anyone can join the multicast provided 1008 that the identity of the member is known, the initiator 1009 provides an Access Control List (ACL) for the group. 1011 Closed Many-to-Many: since only a predefined number of members 1012 can join, the initiator provides the IKM with a list of 1013 allowable members. 1015 A host wishing to join must send the join-request (containing the its 1016 identity) to the RKM it selects. The RKM in turn will forward the 1017 request to the IKM together with the identity of the RKM. It is then 1018 up to the IKM to decide membership using on the identities of the 1019 host and its associated RKM. 1021 6.References 1023 [1] I. Ingemarsson, D. T. Tang, and C. K. Wong, "A Conference Key 1024 Distribution System," IEEE Transactions on Information Theory, 1025 vol. IT-28, pp. 714-720, 1982. 1026 [2] K. Koyama and K. Ohta, "Identity-based Conference Key 1027 Distribution Systems," presented at Advances in Cryptology - 1028 CRYPTO'87 (Lecture Notes in Computer Science No. 293), 1987. 1029 [3] M. Steiner, G. Tsudik, and M. Waidner, "Diffie-Hellman Key 1030 Distribution Extended to Group Communications," presented at 1031 Proceedings of the 3rd ACM Conference on Computer and 1032 Communications Security, New Delhi, 1996. 1033 [4] M. Burmester and Y. Desmedt, "Efficient and Secure Conference Key 1034 Distribution," presented at Security Protocols (Lecture Notes in 1035 Computer Science No. 1189), 1996. 1036 [5] A. Shamir, "How to share a secret," Communications of the ACM, 1037 vol. 22, pp. 612-613, 1979. 1038 [6] G. J. Simmons, "An Introduction to Shared Secret and/or Shared 1039 Control Schemes and Their Application," in Contemporary 1040 Cryptology: The Science of Information Integrity, 1041 G. J. Simmons, Ed., 1992, pp. 441-497. 1042 [7] Y. Zheng, T. Hardjono, and J. Seberry, "Reusing Shares in Secret 1043 Sharing Schemes," The Computer Journal, vol. 17, 1044 pp. 199-205, 1994. 1046 [8] T. Okamoto, "A Digital Multisignature Scheme Using Bijective 1047 Public-Key Cryptosystems," ACM Transactions on Computer Systems, 1048 vol. 6, pp. 432-441, 1988. 1049 [9] S. Kent and R. Atkinson, "Security Architecture for the Internet 1050 Protocol," IETF, RFC 1825 1998. 1051 [10] T. Ballardie, "Scalable Multicast Key Distribution," IETF, RFC 1052 1949, 1996. 1053 [11] H. Harney and C. Muckenhirn, "Group Key Management Protocol 1054 (GKMP) Architecture," IETF, RFC 2094, July 1997. 1055 [12] S. Mittra, "The Iolus Framework for Scalable Secure 1056 Multicasting," presented at Proceedings of ACM SIGCOMM'97, 1997. 1057 [13] D. Harkins and N. Doraswamy, "A Secure Scalable Multicast Key 1058 Management Protocol," IETF, IETF Draft 1059 draft-ietf-ipsecond-00.txt, November 1997. 1060 [14] C. K. Wong, M. Gouda, and S. Lam, "Secure Group Communications 1061 Using Key Graphs," presented at Proceedings of SIGCOMM'98, 1998. 1062 [15] D. Chaum, "Untraceable Electronic Mail, Return Addresses, and 1063 Digital Pseudonyms," Communications of the ACM, 1064 vol. 24, pp. 84-88, 1981. 1065 [16] K. Ohta, T. Okamoto, and K. Koyama, "Membership authentication 1066 for hierarchical multigroup using the extended Fiat-Shamir 1067 scheme," presented at Advances in Cryptology - Proceedings of 1068 EUROCRYPT'90 (Lecture Notes in Computer Science No. 473), 1069 Aarhus, Denmark, 1990. 1071 7. Authors Addresses 1073 Thomas Hardjono 1074 Nortel Networks 1075 600 Technology Park Drive 1076 Billerica, MA 01821, USA 1077 Email: thardjono@baynetworks.com 1079 Brad Cain 1080 Mirror Image 1081 49 Dragon Court 1082 Woburn, MA 01801 1083 Email: brad.cain@mirror-image.com 1085 Naganand Doraswamy 1086 Photonex 1087 8C Preston Court 1088 Bedfod, MA 01730 1089 Email: naganand@photonex.com