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