idnits 2.17.1 draft-ietf-ipsec-intragkm-00.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: ---------------------------------------------------------------------------- ** 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. == 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 31 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 29 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([HCD98]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (July 1999) is 9045 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'HCD98' -- Possible downref: Non-RFC (?) normative reference: ref. 'HC98' -- Possible downref: Non-RFC (?) normative reference: ref. 'WGL98' ** Obsolete normative reference: RFC 1825 (ref. 'KA98a') (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. 'KA98b' -- Possible downref: Non-RFC (?) normative reference: ref. 'KA98c' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTE98' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Thomas Hardjono 2 INTERNET-DRAFT Brad Cain 3 Indermohan Monga 4 Nortel Networks 5 November 1998 6 Expires July 1999 8 Intra-Domain Group Key Management Protocol 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet-Drafts 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a 23 "working draft" or "work in progress." 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Distribution of this document is unlimited. 33 Copyright The Internet Society (1998). All Rights Reserved. 35 Abstract 37 This document describes a protocol for intra-domain group key 38 management for IP multicast security, based on the framework of 39 [HCD98]. In order to support multicast groups, the domain is divided 40 into a number of administratively-scoped "areas". A host-member of 41 a multicast group is defined to reside within one (and only one) of 42 these areas. The purpose of placing host-members in areas is to 43 achieve flexible and efficient key management, particularly in the 44 face of the problem of changes (joining, leaving, ejections) in the 45 membership of a multicast group. A separate administratively-scoped 46 area control-group is defined for each (data) multicast group, for 47 the express purpose of key management and other control-message 48 delivery. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1 Domains, Areas and Key Distributors . . . . . . . . . . . 4 56 3.2 Trust Relationships. . . . . . . . . . . . . . . . . . . . 5 57 3.3 Multicast Groups for Data and Control. . . . . . . . . . . 6 58 3.4 Keys: Multicast Groups and Control-Multicast Groups. . . . 7 59 3.5 Control-Multicast Groups: Address Allocation . . . . . . . 8 60 3.6 Group Security Associations . . . . . . . . . . . . . . . 10 61 3.7 Secure Channels. . . . . . . . . . . . . . . . . . . . . .11 62 3.8 Periodic Re-Keying . . . . . . . . . . . . . . . . . . . .11 63 3.9 Arrangement of Keys in the Domain. . . . . . . . . . . . .12 64 4. Creation of New Multicast Groups. . . . . . . . . . . . . . . 16 65 4.1 Initiation of New Internal-Origin Groups . . . . . . . . .16 66 4.2 Membership to External-Origin Groups. . . . . . . . . . .19 67 5. Re-Keying Approach . . . . . . . . . . . . . . . . . . . . . .20 68 5.1 Re-Keying of Multicast Keys . . . . . . . . . . . . . . .20 69 5.2 Re-Keying of Area Keys . . . . . . . . . . . . . . . . . .21 70 5.3 Re-Keying of the All-KD-Key. . . . . . . . . . . . . . . .22 71 6. Hosts Joining a Multicast Group. . . . . . . . . . . . . . . .23 72 6.1 Joining with Backward Confidentiality . . . . . . .. . . .24 73 6.2 Joining Without Backward Confidentiality . . . . . . . . .25 74 7. Host Leaving a Multicast Group . . . . . . . . . . . . . . . .27 75 8. Reliability in Key Management. . . . . . . . . . . . . . . . .28 76 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .30 77 10. References. . . . . . . . . . . . . . . . . . . . . . . . . .30 79 1. Introduction 81 This document describes a protocol for intra-domain group key 82 management for IP multicast security, based on the framework of 83 [HCD98]. In order to support multicast groups, the domain is divided 84 into a number of administratively-scoped "areas". A host-member of 85 a multicast group is defined to reside within one (and only one) of 86 these areas. The purpose of placing host-members in areas is to 87 achieve flexible and efficient key management, particularly in the 88 face of the problem of changes (joining, leaving, ejections) in the 89 membership of a multicast group. 91 A separate administratively-scoped area control-group is defined for 92 each (data) multicast group, for the express purpose of key 93 management and other control-message delivery. A unique 94 cryptographic key is associated with every (multicast group, 95 control-group) pair in a given area. The control-groups are used 96 for key management, following the re-keying behavior described in 97 [WGL98] and extending it over several key distributor entities. 99 2. Background 101 The current document follows from the group key management 102 framework proposal of [HCD98]. The framework of [HCD98] introduces 103 two planes corresponding to the network entities and functions 104 pertaining to multicasting ("network infrastructure plane") and to 105 security ("key management plane"). Within the key management plane 106 two hierarchies (levels) of regions are introduced, namely one 107 "trunk region" (inter-region) and one or more "leaf regions" (intra- 108 region). These regions are defined to have unique group keys and 109 are open to differing (inter-region or intra-region) group key 110 management protocols. 112 The current work introduces an "intra-region" (leaf-region) group 113 key management protocol, where the term "domain" in the current 114 work is taken to mean a single leaf region of [HCD98]. Although in 115 practice one leaf region of [HCD98] can consist on one or more of 116 our current "domains", for simplicity we assume that one leaf region 117 corresponds to one current domain. 119 The definition of a "domain" (leaf) here is viewed more from an 120 administrative perspective, in which the "domain" is administered 121 and controlled by one body. This single-administration perspective 122 is assumed both for multicasting and for key management. 124 The group key management behavior in the current document is 125 inspired by the work of [WGL98] which is based on a centralized 126 server. The current work extends it to cover multiple entities in a 127 distributed fashion. 129 The current document addresses group key management for multicast 130 security. The issue of how a cryptographic key is applied to data 131 in a multicast group is not addressed, although the current document 132 points to IPsec (ESP and AH) [KA98a, KA98b, KA98c] as a foremost 133 candidate, depending on the multicast application type. Although in 134 the document a key is used to "encipher" the multicast data to 135 control access by group members, the intent is clear that 136 authentication-only multicast applications may also employ the 137 current design. 139 The current document seeks to cover both the one-to-many and many- 140 to-many multicast application types. Hence, the protocol has 141 been described is the broadest way possible, without affecting the 142 security of key management in general. 144 3. Architecture 146 The current work aims to manage multicast group keys based 147 on well-defined domains. It also distinguishes between multicast 148 groups for the purpose of payload delivery and for the purpose of 149 key management. 151 The current document is concerned with the correct and secure 152 delivery of keys to members of a multicast group. It does not 153 prescribe how a key is to be used on the data being transmitted in 154 the multicast group. The reader is directed to methods such as 155 IPsec ESP [KA98b] for concrete possibilities. 157 |--------------R/TE-------------| 158 | | 159 | DKD DMAAE | 160 | | 161 | ----R---- ----R---- ----R---- | 162 | | | | | | | | 163 | | AKD | | AKD | | AKD | | 164 | | | | | | | | 165 | | R R | | 166 | | m m m | | m m m | | m m m | | 167 | --------- --------- --------- | 168 |_______________________________| 170 Figure 1: Intra-Domain Group Key Management Elements 172 3.1 Domains, Areas and Key Distributors 174 At the domain-level, a Domain Key Distributor (DKD) entity is 175 defined for the domain for the purpose of key management. 177 In order to support multicast groups, the domain is divided into a 178 number of administratively-scoped "areas" [Mey98]. A host-member of 179 a multicast group is defined to reside within one (and only one) of 180 these areas. The purpose of placing host-members in areas is to 181 achieve flexible and efficient key management, particularly in the 182 face of the problem of changes (joins and leaves) in the membership 183 of a multicast group. 185 At the area level, an Area Key Distributor (AKD) entity is defined 186 for each area for the purpose of key management. 188 Depending on the address allocation approach (see Section 3.4), each 189 area may be associated with one Area Multicast Address Allocation 190 Entity (AMAAE), such the MAAS of [HTE98], from which the Area Key 191 Distributor (AKD) of that area obtains area-wide multicast 192 addresses. In addition, at the domain-level, a Domain Multicast 193 Address Allocation Entity (DMAAE) must exist to cater for the 194 domain. 196 Within the domain, all Key Distributors (the DKD and AKDs) are 197 members of the domain-wide administratively-scoped multicast group, 198 called the "All-KD-group", which does not extend beyond the domain 199 and whose membership consists only of Key Distributors. 201 The Domain Key Distributor (DKD) communicates to Area Key 202 Distributors (AKD) either through secure one-to-one (unicast) 203 communications or through the All-KD-group. The All-KD-group is 204 independent of other multicast groups and it exists even when there 205 are no host-members of any multicast group in the domain. 207 The Area Key Distributor (AKD) communicates to host-members residing 208 in its area either through secure one-to-one (unicast) 209 communications or through a special (ie. control) multicast group 210 whose scope is limited to that area. 212 Should a multicast group originate from outside the domain and 213 should its traffic be enciphered under a foreign key, then 214 Translating Entity(s) (TE), such as a border-router(s), must be 215 specified in the domain. In such a case, the Domain Key Distributor 216 (DKD) is assumed to have a copy of the foreign key through other 217 methods (unspecified). The DKD will then supply the Translating 218 Entity(s) with a copy of the foreign key and a copy of a new 219 multicast key to be used on the traffic in the domain. 221 3.2 Trust Relationships 223 The trust relationship in the current work revolves around the Key 224 Distributors and does not extend beyond the domain. All Key 225 Distributors (DKD and AKDs) are configured and maintained by the 226 human administration in the domain. They must be implemented using 227 the most secure technology available, since they represent the best 228 point-of-attack. 230 All entities trust the Domain Key Distributor (DKD) as the primary 231 source of authentic parameters. The DKD can in fact also take-on 232 the role of a certification authority when the need arises. The 233 public-key of the DKD is well-known to (and/or is configured within) 234 each host and within the Area Key Distributors (AKDs). 236 A host residing within an area trusts the Area Key Distributor (AKD) 237 in that area. 239 3.3 Multicast Groups for Data and Control 241 The current work employs administratively-scoped multicast 242 groups for the purpose of key management. 244 To distinguish these administratively-scoped multicast groups for 245 control (ie. key management) from the multicast group for data, the 246 latter will be referred to as "data multicast groups", "data-groups" 247 or simply "multicast groups". A control-related group will be 248 referred to as "control-multicast group" or simply "control-group". 250 A "control-group" is an administratively-scoped multicast group 251 which is area-wide. It is initiated/owned by the Area Key 252 Distributor (AKD) of an area. The purpose of an area control-group 253 is for key management relating to an associated data-multicast 254 group. 256 An area control-group associated with a data-multicast group exists 257 so long as there are members of the corresponding data-multicast 258 group in the area. Once a data-multicast group ceases to have any 259 members in an area, the Area Key Distributor (AKD) of that area may 260 terminate that corresponding area control-group. 262 A special control-group is the All-KD-group. This is an 263 administratively-scoped multicast group which is domain-wide and 264 consists only of the Domain Key Distributor (DKD) and Area Key 265 Distributors (AKD). It has a fixed address and is initiated/owned by 266 the Domain Key Distributor (DKD). There is only one All-KD-group in 267 a domain, and it is a permanent group, independent of whether any 268 data multicast group members exists in the domain. Unless 269 specifically mentioned, in the remainder of this document all 270 control-groups are area control-groups. 272 Note that once a host (in an area within the domain) becomes a 273 member of a multicast group, it also must become a member of one of 274 the area control-groups of the area within which that host resides. 275 This allows the Area Key Distributor (AKD) to communicate with the 276 host-member through the area control-group. 278 From the perspective of an Area Key Distributor (AKD) of an area, 279 for a multicast group having a host-member in its area, the Key 280 Distributor (AKD) must assign that host-member to one of the area 281 control-groups in that area. 283 3.4 Keys: Multicast Groups and Control-Multicast Groups 285 A multicast group is associated with a domain-wide Multicast-Key 286 (MKey). The current work assumes that cryptographic keys are 287 used for the encipherment of the multicast traffic as a method to 288 provide receiver access-control, where only valid members of the 289 multicast group is provided with a copy of the cryptographic key. 290 This is true for data multicast groups and area control-groups. 292 For each multicast group having a member in the domain, a unique 293 Multicast-Key (MKey) is assigned by the Domain Key Distributor (DKD) 294 for that multicast group. 296 A multicast group having a member in an area in the domain is 297 associated with one control-group in the area by the Area Key 298 Distributor (AKD) of that area. All traffic within an area control- 299 group is enciphered in such a way that only the AKD of that area and 300 the intended receivers of the traffic will be able to decipher the 301 traffic. The cryptographic key associated with an area control- 302 group is referred to generally as the Area-Group-Key (AreaGroupKey). 303 An Area-Group-Key is selected by the Area Key Distributor (AKD). 304 The Area-Group-Key (AreaGroupKey) is unique for each (multicast 305 group, control-group) pair. 307 For the special All-KD-group, an All-KD-Key (AllKDKey) is assigned 308 by the Domain Key Distributor (DKD) for the All-KD-group. 310 Here, it is assumed (initially) that all payload 311 related to a multicast group travelling within a domain is encrypted 312 using the Multicast-Key (MKey). Should the sender of the multicast 313 group be located outside the domain, then a "Translating-Entity" 314 (TE), such as the border-router of the domain, must be employed to 315 decrypt the entering traffic (using some inter-domain cryptographic 316 key) and to re-encrypt it using the Multicast-Key (MKey) assigned in 317 the domain to that multicast group. Similarly, the Translating- 318 Entity must "translate" multicast group traffic (sent from a group 319 member in the current domain) when the traffic leaves the domain. 321 The "boot-strapping" process of each multicast group and control- 322 group relies on the establishment of a Security Association (SA) and 323 a shared private-key between a (candidate) member of the group with 324 the Key Distributor (DKD or AKDs) that controls the group. It is 325 through this one-to-one secure channel that the parameters for the 326 groups are then given to host-members by the Area Key Distributor in 327 the case of the multicast group and area control groups, or to the 328 Area Key Distributors (AKDs) by the Domain Key Distributor (DKD) in 329 the case of the All-KD-group. 331 3.5 Control-Multicast Groups: Address Allocation 333 Three possible approaches are available with regards to the use of 334 area control-groups (corresponding to a given multicast group) for 335 key management by the Area Key Distributor (AKD): 337 (a) One control-group per area per multicast group: 339 For each multicast group, having members in an area, a separate 340 control-group is created within the area. 342 Each separate area control-group is associated with a different 343 Area-Group-Key. 345 One disadvantage of this approach is the potential lack of 346 multicast addresses within the area. Another disadvantage is the 347 waste of resource related to area-wide multicasting if the area 348 only has very few members of the corresponding multicast group. 349 This approach requires the presence of an Area Multicast Address 350 Allocation Entity (AMAAE) in each area. 352 (b) One control-group per area for all multicast groups: 354 In this approach, for each multicast group, having members in an 355 area, only one control-group is created within the area. Hence, 356 the area control-group is shared among members of different 357 multicast groups. 359 Although there is only one (shared) area control-group, a 360 separate Area-Group-Key is used for each data multicast group. 361 When the AKD wishes to communicate with members of a particular 362 multicast group residing in its area, the AKD will encipher the 363 communications using the appropriate Area-Group-Key. Other non- 364 intended recipients will also receive the enciphered packets, but 365 will drop them since they will not be able to decipher them. 367 The advantage of this approach is that there is only one control- 368 group which can be long-lived and have a fixed address. Having 369 the fixed address obviates the Area Multicast Address Allocation 370 Entity (AMAAE), thereby simplifying the entire design. 372 The main disadvantage of this approach is that bandwidth within 373 the area is wasted when the AKD is performing key management 374 communications with only a small subset of group members residing 375 in the area, since all other unconcerned members are receiving 376 the (enciphered) packets and dropping them. Another related 377 disadvantage is increased opportunity for cryptanalysis of 378 enciphered packets of control-groups, since unconcerned members 379 are receiving these packets and may cryptanalyze them. 381 (c) One control-group per area for several multicast groups: 383 This approach attempts to bring together the advantages of the 384 previous two. For a fixed number of multicast groups, having 385 members in an area, a single control-group is created within the 386 area. 388 Thus, within a given area a set of N multicast addresses for N 389 control-groups can be selected and fixed. Each multicast group 390 having (one or more members in an area) is then mapped to one of 391 the N control-groups in that area (eg. by hashing the multicast 392 group address). 394 In terms of key management, each (multicast group, control-group) 395 pair will be associated with a unique Area-Group-Key 396 (AreaGroupKey). 398 Thus, for example, a host who is a member of two multicast groups 399 MG1 and MG2 may find that in its area both MG1 and MG2 are mapped 400 into one control-group CG1, with two Area-Group-Keys AGK1 and 401 AGK2 corresponding to the two multicast groups. Hence, for the 402 control-group CG1 the host must maintain the unique triplets 403 (MG1, CG1, AGK1) and (MG2, CG1, AGK2). The host must be able to 404 distinguish control-group packets in CG1 corresponding to the two 405 multicast groups, in order for it to apply the matching keys. 406 Tagging methods within control-packets may be employed to achieve 407 this effect, saving the host the effort of trying the keys. 409 In this manner, the design is simplified by obviating the 410 Area Multicast Address Allocation Entity (AMAAE) for each area, 411 and the problem of unintended members receiving and dropping 412 (enciphered) messages is also somewhat reduced. 414 The current work will employ the third approach due to its 415 simplicity. We specify that an Area Key Distributor 416 (AKD) maintains a mapping between a multicast group and its 417 corresponding control-group in the area. How this mapping is 418 established is implementation-specific, and thus outside the scope 419 of the document. Furthermore, we assume that each 420 control-group packet carries sufficient identification information 421 relating to the multicast group to which it corresponds, thereby 422 allowing non-intended receivers of the packets in the shared 423 control-group to drop the packets without attempting to decrypt it. 425 3.6 Group Security Associations 427 The IPsec security architecture [KA98a] defines the concept of a 428 Security Association (SA) between two communicating parties. An SA 429 is a simplex connection that affords security services to the 430 traffic carried by it. An SA is uniquely identified by the triple 431 consisting of the Security Parameter Index (SPI), an IP Destination 432 Address and a security protocol identifier. Thus, for a two way 433 communications, two Security Associations must be negotiated and 434 established. 436 The current work recognizes that for the many-to-many 437 multicast applications the basic IPsec Security Association as a 438 simplex connection does not suffice. Hence, it uses the notion of a 439 Multicast Group Security Association (GSA) derived from the simplex 440 Security Association. Note that the concept of a GSA for multicast 441 has previously been describe, albeit briefly, in the IPsec security 442 architecture document [KA98a] and other related documents. 444 In the current document we assume that a Group Security 445 Association (GSA) attributes is not negotiated between the 446 communicating parties, but rather selected by one party. The entity 447 that selects the GSA depends on the whether it is a multicast group 448 or a control-group. All members of the group would then use the one 449 same Group Security Parameter Index (GSPI) related to the GSA. 450 Similarly, when a re-keying occurs, a new Group Security Parameter 451 Index (GSPI) must selected for the GSA and a new key must be 452 generated by one entity and delivered to the group members. 454 The notion of a Group Security Association (GSA) selected by one 455 entity departs from the existing IPsec definition and has 456 implications on the ability of hosts to join multicast groups. 457 Recall that in the two-party communication scenario, each party 458 negotiates the Security Association (SA) depending on their 459 cryptographic capability (eg. cryptographic algorithms available). 460 In the case of a Group Security Association (GSA) selected by one 461 entity, the required capability (eg. minimal algorithms) demanded of 462 a potential member must be announced through other methods, such as 463 through the multicast session description protocol or other 464 protocols. In this way, a multicast group initiator or owner can 465 specify what cryptographic algorithm(s) can be used in the multicast 466 group. This approach is in-line with the one-to-many multicast 467 applications (eg. pay per view service owners) and is deemed 468 reasonable within the many-to-many multicast applications. 470 3.7 Secure Channels 472 The general term "secure channel" is used in the remainder of the 473 current document to mean communications between one sender and one 474 receiver (unicast), with authenticity and confidentiality. Secure 475 channels here will be based on IPsec (AH and/or ESP) [KA98a]. The 476 term implies the existence of a Secure Association (SA) and a 477 private-key shared between the sender and receiver before the two 478 begin communicating securely. The IKE protocol [HC98] can be used 479 to establish the Security Association and the shared private-key. 481 Independent of the Group Security Association (GSA) for the 482 multicast group, each host-member is assumed to have establish a 483 Security Association (SA) and a shared private-key with the Area Key 484 Distributor (AKD) of the area within which that host resides before 485 the host joins any groups. Similarly, each Area Key Distributor 486 (AKD) is assumed to have establish a Security Association (SA) and a 487 shared private-key with the Domain Key Distributor (DKD) before the 488 AKD serves any multicast groups. 490 A "secure channel" between one sender and one receiver implies that 491 the identity of the one is known to the other. Hence, in 492 communicating via a secure channel with a Key Distributor (AKD or 493 DKD) a host-member is by definition identified and authenticated by 494 the Key Distributor, and vice versa. 496 3.8 Periodic Re-Keying 498 It is commonly accepted that the longer a cryptographic key is being 499 employed, the higher the chances of that key being successfully 500 cryptanalyzed by an attacker (who is assumed to have collected 501 ciphertext of messages encrypted using the key). This is 502 particularly true for keys of symmetric cryptosystems. 504 The current document recognizes the importance of periodic re- 505 keying and attempts to provide a workable solution in the face of 506 the issue of re-keying due to a new host-member joining (backward 507 confidentiality) and the issue of an existing member leaving or 508 being ejected (forward confidentiality). 510 The approach of re-keying only when the group membership changes 511 suffers from the possibility that the membership does not in fact 512 change over long periods, and thus opening the possibility of 513 cryptanalysis of the multicast key. 515 Hence, the current design adopts the underlying philosophy 516 that periodic re-keying is necessary (even if the membership of the 517 multicast group does not change), independent of whether or not 518 immediate re-keying is performed when a host joins/leaves the 519 multicast group. In this way, the design provides flexibility 520 for the implementor to be "strict" (immediate re-key at each 521 membership change) or to be "loose" (wait until next periodic re- 522 key) with regards to multicast key re-keying. 524 In the following discussions on the group key management protocols, 525 the current work will observe the strict re-keying policy (ie. 526 immediate re-key at each membership change) since it represents a 527 more complex case. The loose re-keying can be established by 528 removing some steps from the protocols and executing other steps 529 only when the designated periodic re-keying occurs. Periodic re- 530 keying in the multicast group will be determined by the Domain Key 531 Distributor (DKD) and implemented with the aid of the Area Key 532 Distributors (AKDs). Periodic re-keying in a control-group (in an 533 area) associated with a multicast group will be determined by the 534 Area Key Distributor (AKD) of that area. 536 From the perspective of multicast reliability, the approach of using 537 periodic re-keying allows each Key Distributor (AKD and DKD) to 538 prepare for the re-keying, hence providing them with a window of 539 opportunity to obtain the next key. Having this window of 540 opportunity provides a context within which reliability mechanisms 541 for key delivery can be established, either through existing 542 reliable multicast protocols or through mechanisms specific to key 543 management. In either case, the current document recognizes that 544 reliability is paramount to group key management if multicast 545 security is to be achieved. 547 3.9 Arrangement of Keys in the Domain 549 The current protocol aims at delivering a multicast key, in the 550 form of a private-key (symmetric cryptography), to members of a 551 multicast group or a control-group. The fact that a host holds a 552 copy of the multicast key is taken to mean that the host has 553 previously been correctly identified by its Area Key Distributor 554 (AKD) and that it has established a Security Association with its 555 AKD. The private-key used in a multicast group or a control-group 556 affords confidentiality and "group authentication" in the sense that 557 the source of any information enciphered under the key is a valid 558 member of the group. Note, that this level of authentication (group 559 authentication) is implicit and does not provide irrefutable proof 560 of the singular identity of the sender. 562 The current document recognizes the benefits of a public key 563 certification infrastructure and is open to such an infrastructure 564 being deployed, with each entity being assigned a public key. 566 However, in order to render the protocol immediately deployable 567 in the near future, we assume that public keys are 568 assigned only to the Key Distributors (DKD and AKDs) and the Domain 569 Multicast Address Allocation Entity (DMAAE) to allow them to 570 digitally-sign information that is to be sent through the multicast 571 group or the control-groups. These public keys are valid only 572 within the domain, and may not be recognized outside the domain 573 (unless a certification infrastructure is employed). 575 3.9.1 Public Keys 577 The current protocol assumes that all Key Distributors (DKD and 578 AKDs) are assigned public-keys (asymmetric cryptography) in order 579 for these Key Distributors to digitally-sign certain information in 580 such a way that it is verifiable by all hosts in the domain. 582 A host-member residing in area is assumed to have a copy of the 583 public-key of its Area Key Distributor (AKD) and the public-key of 584 the Domain Key Distributor (DKD). 586 An Area Key Distributor (AKD) is assumed to have a copy of the 587 public-key of the Domain Key Distributor (DKD). An Area Key 588 Distributor (AKD) may obtain the public-keys of other Area Key 589 Distributors from the Domain Key Distributor (DKD), with the DKD 590 acting as a domain-wide certification authority. 592 Al the very least, the public key of the Domain Key Distributor 593 (DKD) must be advertised in a tamper-proof manner (eg. printed or 594 manually configured) to allow it to be used to vouch for the public 595 keys of the Area Key Distributors (AKDs). 597 3.9.2 Shared Private-Keys 599 Three types of group-oriented (ie. shared by a group) private-keys 600 (symmetric cryptography) are used: 602 - Multicast-Key (MKey): this is the private-key associated with a 603 multicast group that is used by all the group members in the 604 domain to encrypt/decrypt the multicast traffic in the multicast 605 group. This key is generated by the Domain Key Distributor (DKD) 606 of the domain. 608 This key is delivered securely to each Area Key Distributor 609 (AKD), who will in turn deliver the key securely to each group 610 member in their area. 612 - Area-Group-Key (AreaGroupKey): this is the private-key associated 613 with the (multicast group, control-group) pair, and used to 614 encipher the communications in the control-group. An Area-Group- 615 Key is generated by the Area Key Distributor (AKD) of that area 616 and delivered to each member through a secure-channel. An Area- 617 Group-Key is known only to the AKD of an area and the members (of 618 the corresponding multicast group) residing in that area. 620 - All-KD-Key (AllKDKey): this is the private-key associated with 621 the special All-KD-group. All the Area Key Distributors (AKDs) 622 and the Domain Key Distributor (DKD) hold a copy of the All-KD- 623 Key. This key is generated by the Domain Key Distributor (DKD) 624 and delivered to each AKD through a secure-channel. This key is 625 used to encipher the communications within the All-KD-group. 627 Two types of pair-oriented private-key are used in the current 628 work: 630 - Member-Private-Key (MbrPKey): Each host-member in an area pair- 631 wise shares a Security Association (SA) and a Member-Private-Key 632 (MbrPKey) with the Area Key Distributor (AKD) of that area. The 633 Security Association (SA) and the Member-Private-Key (MbrPKey) 634 are long-term and must be established before the host-member 635 joins (or initiates) any multicast groups and is given a copy of 636 that group's Multicast-Key (MKey). There is only one SA and one 637 MbrPKey shared between the host-member and the Area Key 638 Distributor (AKD), independent of the number of multicast groups 639 to which that host-member belongs. 641 - AKD-Private-Key (AKDPKey): Each Area Key Distributor (AKD) of an 642 area pair-wise shares a Security Association (SA) and a AKD- 643 Private-Key with the Domain Key Distributor (DKD). The Security 644 Association and the AKD-Private-Key (AKDPKey) are long-term and 645 must be established before any multicast group exists in the 646 domain. 648 In summary, the private-key arrangement from the point of view of 649 entities is as follows. 651 Hosts: 652 A host-member of a multicast group residing in an area holds a 653 copy of the Multicast-Key (MKey) and a copy of the Area-Group-Key 654 (AreaGroupKey) corresponding to the (multicast group, control- 655 group) pair. In addition, the host-member also holds its own 656 Member Private-Key (MbrPKey) independent of any multicast groups. 658 Area Key Distributors (AKD): 659 For each multicast group having a member in an area, the Area Key 660 Distributor (AKD) of the area holds a copy of the Multicast-Key 661 (MKey) of the multicast group and holds a unique Area-Group-Key 662 (AreaGroupKey) corresponding to each (multicast group, control- 663 group) pair. 665 In addition, an AKD also holds a copy of the current All-KD-Key 666 (AllKDKey), its own AKD-Private-Key (AKDPKey) and a copy of the 667 Member Private-Key (MbrPKey) of each member residing in its area. 668 These (the AllKDKey, AKDPKey and MbrPKeys) are independent of any 669 multicast groups to which a resident host-member belongs. 671 Domain Key Distributor (DKD): 672 The Domain Key Distributor (DKD) of a given domain holds the 673 Multicast-Key (MKey) for each multicast group, a copy of the 674 current All-KD-Key (AllKDKey), and a copy of the AKD-Private-Key 675 (AKDPKey) of each Area Key Distributor (AKD) in the domain. 677 -------------------------------------------------------- 678 Multicast access purposes: Multicast Key (MKey) 679 ======================================================== 680 Control purposes: 681 -------------------------------------------------------- 682 Pair-wise Shared Group-wise shared 683 ----------------------- ----------------------- 684 DKD Key: AKD-Private-Key Key: All-KD-Key 685 with - Long-term - Medium-term 686 AKD - Independent of groups - Independent of groups 688 AKD Key: Member-Private-Key Key: Area-Group-Key 689 with - Long-term - Medium-term 690 Hosts - Independent of groups - N per area 691 -------------------------------------------------------- 692 Table 1: Key arrangement 694 Note that the Domain Key Distributor (DKD) does not hold copies of 695 the Member-Private-Keys (MbrPKey). This is in contrast to the 696 approach in [WGL98] in which a central server holds the private-keys 697 of all members in the multicast group. If a host is in need of 698 communicating directly through a secure channel to the Domain Key 699 Distributor (DKD) or any other entity, then the host must establish 700 a Security Association and a shared private-key with the DKD or 701 entity. 703 Although currently not prescribed, depending on the reliability 704 mechanism to be employed, the Domain Key Distributor (DKD) may hold 705 copies of the Area-Group-Key (AreaGroupKey) within each area in the 706 domain. However, the intent is clear that the Domain Key 707 Distributor (DKD) is not to replace any Area Key Distributor (AKD). 709 Each key is assumed to be associated with a Key Identifier which 710 uniquely identifies the cryptographic key is question. 712 4. Creation of New Multicast Groups 714 Two possible scenarios with respect to new multicast groups exist. 715 In the first case, the new multicast group is initiated from the 716 current domain. In the second case, the multicast group was 717 initiated from outside the domain and has existed before a host in 718 the current domain joins it. 720 4.1 Initiation of New Internal-Origin Groups 722 When a host ("Initiator") in the current domain wishes to commence a 723 new multicast group, it must first initiate the creation of the 724 multicast group via the underlying multicast routing protocol and 725 some membership protocol (eg. IGMP). 727 If it has not already done so, the initiator host must establish a 728 Security Association (SA) and a shared Member Private-Key (MbrPKey) 729 with its Area Key Distributor (AKD). 731 The commencement of a new multicast group from the perspective of 732 group key management is described as follows, consisting two 733 inseparable parts. The first part is the generation and distribution 734 of the multicast-key, while the second part is the generation and 735 distribution of the Area-Group-Key. 737 Protocol-I: Generation and distribution of the multicast key 739 Step N1: The initiator in an area within the current domain creates 740 a new domain-wide multicast group (method unspecified) with 741 the aid of the Domain Multicast Address Allocation Entity 742 (DMAAE) at the domain level. The DMAAE returns to the 743 initiator the following parameters, digitally signed by the 744 DMAAE: 745 - a multicast group address 746 - a multicast group identity 747 - the identity of the initiator (as group owner) 749 Step N2: The initiator selects the Multicast Group Security 750 Association (MGSA) attributes (without the GSPI). The 751 initiator then authentically notifies its Area Key 752 Distributor (AKD) about the new multicast group and requests 753 a new multicast key for the new multicast group. The message 754 is sent through a secure channel and contains the signed 755 parameters from the DMAAE, the MGSA and an Access Control 756 List (ACL): 757 - the multicast group address 758 - the multicast group identity 759 - the identity of the initiator 760 - the Multicast Group Security Association (MGSA) 761 - the time-period for re-keying cycle 762 - an Access Control List (ACL) generated by the initiator 764 Step N3: The Area Key Distributor (AKD) of the initiator receives 765 the request from the initiator, notifies the Domain Key 766 Distributor (DKD) about the new multicast group and passes 767 the request message to the DKD through a secure channel. 769 Step N4: The Domain Key Distributor (DKD) receives the request and 770 performs the following steps: 772 Step N4.1: The Domain Key Distributor (DKD) verifies the digital 773 signature of the Domain Multicast Address Allocation Entity 774 (DMAAE). 776 Step N4.2: The Domain Key Distributor (DKD) generates: 777 - a Group Security Parameter Index (GSPI) for the MGSA 778 - a Multicast-Key (MKey) 779 - a multicast key identifier MKeyID 780 based on the MGSA selected by the initiator. 782 Step N4.3: The Domain Key Distributor (DKD) digitally-signs the 783 multicast group parameters: 784 - the multicast group address 785 - the multicast group identity 786 - the identity of the initiator 787 - the time-period for re-keying cycle 788 - the Access Control List (ACL) 789 - the Multicast Group Security Association (MGSA) 790 - the Multicast-Key (MKey) 791 - the multicast key identifier MKeyID 792 - a timestamp 794 Step N4.4: The Domain Key Distributor (DKD) securely delivers the 795 signed multicast group parameters to each Area Key 796 Distributor (AKD), either through the All-KD-group (encrypted 797 under the All-KD-Key) or through a one-to-one secure channel 798 to each Area Key Distributor (AKD). This message also serves 799 as an acknowledgment to the Area Key Distributor (AKD) of the 800 initiator. 802 The process of the creation of the All-KD-group is similar to 803 Protocol-I, with the exception that the multicast address is fixed 804 and the DKD selects the Group Security Association (GSA) for the 805 All-KD-group. The DKD also generates the All-KD-Key (AllKDKey) and 806 the All-KD-Key identifier AllKDKeyID for the multicast group, based 807 on the MGSA selected by the DKD. 809 Protocol-II Generation and distribution of the area key 811 Step N5: Upon receiving the signed multicast group parameters from 812 the DKD, the Area Key Distributor (AKD) of the initiator 813 performs the following steps: 815 Step N5.1: The Area Key Distributor (AKD) maps the multicast group 816 address to one of the area control-group addresses. The AKD 817 maintains the following information for the given multicast 818 group: 819 - an area control-group address 820 - an area control-group identity 821 - the identity of the AKD (as group owner) 823 Step N5.2: The Area Key Distributor (AKD) selects the Area Group 824 Security Association (AGSA) attributes and generates: 825 - a Group Security Parameter Index (GSPI) for the AGSA 826 - an Area-Group-Key (AreaGroupKey) 827 - an area key identifier AkeyID 828 based on the AGSA selected by the AKD. 830 Step N5.3: The Area Key Distributor (AKD) digitally-signs the area 831 control-group parameters: 832 - the multicast group address 833 - the multicast group identity 834 - the area control-group address 835 - the area control-group identity 836 - the identity of the AKD 837 - the time-period for re-keying cycle 838 - the Area Group Security Association (AGSA) 839 - the Area-Group-Key (AreaGroupKey) 840 - the area key identifier AKeyID 841 - a timestamp 843 Step N6: The Area Key Distributor (AKD) of the initiator returns to 844 the initiator, through a secure channel: 845 - the multicast group parameters (from Step N4) without the 846 ACL, signed by the AKD 847 - the area control-group parameters (from Step N5) signed by 848 the AKD 850 Step N7: The initiator joins the area control-group (method 851 unspecified). 853 Note that Step N4 above effectively provides each and every Area Key 854 Distributor (AKD) in the domain with the necessary parameters 855 related to the multicast group, regardless of whether or not the 856 area of an AKD actually contains any members of the multicast group. 857 This approach is chosen to allow for quick response by an AKD should 858 other hosts in other areas wish to join the multicast group. In 859 addition, the approach leaves open the possibility of the AKDs to 860 participate in the reliability mechanisms to be employed 861 (ie. as backups), since each of the AKDs holds the 862 parameters related to every multicast group in the domain. 864 The multicast group parameters are digitally signed by Domain Key 865 Distributor (DKD) in order to aid reliability protocols. That is, 866 in the case that the DKD goes down, the parameters can be obtained 867 by one AKD from another AKD through a one-to-one secure channel, 868 with the recipient being able to verify the authenticity of the 869 parameters as signed by the DKD. 871 4.2 Membership to External-Origin Groups 873 Although the current design focuses on intra-domain group key 874 management, it does not preclude the possibility of a multicast 875 group originated by a host external to the domain. However, unlike 876 multicast groups which originate from a host within the domain and 877 which is therefore known to the Domain Key Distributor (DKD), 878 multicast groups which originate from outside a domain must be 879 explicitly made known to the DKD. 881 Since the current protocol views the multicast distribution tree 882 used by a multicast routing protocol as a construct outside its 883 control, the Domain Key Distributor (DKD) can be notified (when a 884 host in domain joins the external-origin multicast group) through a 885 number of ways, among others: 886 - The joining host can explicitly notify its Area Key Distributor 887 (AKD) or the Domain Key Distributor (DKD). 889 - A domain border-router can notify the Domain Key Distributor 890 (DKD) when it senses a request from a host to join the 891 distribution tree 892 - The Domain Key Distributor (DKD) can by default be a member of 893 all external-origin multicast groups whose distribution tree 894 extend into the domain. 896 However, from the perspective of group key management, the Domain 897 Key Distributor (DKD) only plays a role when the external-origin 898 multicast traffic is enciphered for access control and the owner of 899 the group requires the aid of the DKD to enforce access control. 900 Hence, in this situation the DKD must obtain a copy of the key used 901 to encipher the multicast traffic as it enters the domain and assign 902 a new multicast key for that same traffic within its domain (method 903 unspecified). 905 The current document leaves the precise description and 906 specification of the group key management for external-origin 907 multicast groups to a later date. 909 5. Re-Keying Approach 911 The basic approach to re-keying is discussed first 912 in order to simplify later discussions on re-keying 913 due to membership changes and due to periodic re-keying. For 914 simplicity, the process is view from the perspective of the Domain 915 Key Distributor (DKD) and one Area Key Distributor (AKD). 917 It is the DKD who initiates and controls all re-keying events in the 918 domain related to multicast groups. Re-keying of Area-Group-Keys of 919 area control-groups are initiated and controlled by the respective 920 Area Key Distributors (AKD). 922 Note that it is important to have "cycle-over" period in which all 923 host-members are in possession of the new re-key parameters, but is 924 still employing the existing/old parameters. 926 5.1 Re-Keying of Multicast Keys 928 In the following, all re-key steps are related to a given multicast 929 group. The protocol is initiated and controlled by the Domain Key 930 Distributor (DKD). 932 Protocol-III: Re-keying the multicast key 934 Step RM1: The Domain Key Distributor (DKD) issues an authentic 935 prepare-to-rekey message to all Area Key Distributors (AKD) 936 through the All-KD-group. The message contains: 937 - an existing multicast group address 938 - a existing multicast group identity 939 of the multicast group being re-keyed 941 Step RM2: The Domain Key Distributor (DKD) generates: 942 - a new Group Security Parameter Index (GSPI) for the MGSA 943 - a new Multicast-Key (MKey) 944 - a new multicast key identifier MKeyID 945 based on the MGSA selected by the initiator. 947 Step RM3: The Domain Key Distributor (DKD) digitally-signs the 948 multicast group parameters: 949 - the existing multicast group address 950 - the existing multicast group identity 951 - the Multicast Group Security Association (MGSA) 952 - the new Multicast-Key (MKey) 953 - the new multicast key identifier MKeyID 954 - a timestamp 956 Step RM4: The Domain Key Distributor (DKD) securely delivers the 957 signed parameters to each Area Key Distributor (AKD), either 958 through the All-KD-group (encrypted under the All-KD-Key) or 959 through a one-to-one secure channel to each Area Key 960 Distributor (AKD). 962 Step RM5: The Area Key Distributor (AKD) securely delivers the 963 signed multicast group parameters to each host-member (of the 964 multicast group) in its area using one of the following 965 methods (depending on the cause of the re-keying event): 966 (a) through the area control-group related to the multicast 967 group (encrypted under the AreaGroupKey) 968 (b) through a one-to-one secure channel to each concerned 969 host-member. 971 5.2 Re-Keying of Area Keys 973 In the following, all re-key steps by the Area Key Distributor (AKD) 974 are related to a given multicast group. The protocol is initiated 975 and controlled by the Area Key Distributor (AKD). 977 Protocol-IV: Re-keying the area key 979 Step RA1: The Area Key Distributor (AKD) issues an authentic 980 prepare-to-rekey message to all members of the multicast 981 group within the area through the relevant area control- 982 group. The message contains: 983 - an existing area control-group address 984 - an existing area control-group identity 985 of the area control-group being re-keyed 987 Step RA2: The Area Key Distributor (AKD) generates: 988 - a new Group Security Parameter Index (GSPI) for the AGSA 989 - a new Area-Group-Key (AreaGroupKey) 990 - a new area key identifier AkeyID 991 based on the AGSA selected by the AKD. 993 Step RA3: The Area Key Distributor (AKD) digitally-signs the area 994 control-group parameters: 995 - the existing area control-group address 996 - the existing area control-group identity 997 - the Area Group Security Association (AGSA) 998 - the new Area-Group-Key (AreaGroupKey) 999 - the new area key identifier AKeyID 1000 - a timestamp 1002 Step RA4: The Area Key Distributor (AKD) securely delivers the 1003 signed control-group parameters to each host-member (of the 1004 multicast group) in its area, using one of the following 1005 methods (depending on the cause of the re-keying event): 1006 (a) through the area control-group related to the multicast 1007 group (encrypted under the old/current AreaGroupKey) 1008 (b) through a one-to-one secure channel to each concerned 1009 host-member. 1011 5.3 Re-Keying of the All-KD-Key 1013 The following describes the protocol to be employed when the All-KD- 1014 Key (AllKDKey) is to be re-keyed. All the Area Key Distributors 1015 (AKDs) and the Domain Key Distributor (DKD) share an All-KD-Key. 1016 This key is used to encrypt traffic within the All-KD-group. Note, 1017 that unlike host-members, Key Distributors never leave the All-KD- 1018 group, and hence its membership is static. 1020 Protocol-V: Re-keying the All-KD-Key 1022 Step RK1: The Domain Key Distributor (DKD) issues an authentic 1023 prepare-to-rekey message to all Area Key Distributors (AKD) 1024 through the All-KD-group. The message contains: 1025 - the existing All-KD-group address 1026 - the existing All-KD-group identity 1028 Step RK2: The Domain Key Distributor (DKD) generates: 1029 - a new Group Security Parameter Index (GSPI) for the MGSA 1030 - a new All-KD-Key (AllKDKey) 1031 - a new All-KD-Key identifier AllKDKeyID 1032 based on the MGSA selected by the DKD 1034 Step RK3: The Domain Key Distributor (DKD) digitally-signs the All- 1035 KD-group parameters: 1036 - the existing multicast group address 1037 - the existing multicast group identity 1038 - the Multicast Group Security Association (MGSA) 1039 - the new All-KD-Key (AllKDKey) 1040 - the new All-KD-Key identifier (AllKDKeyID) 1041 - a timestamp 1043 Step RK4: The Domain Key Distributor (DKD) securely delivers the 1044 signed All-KD-group parameters to each Area Key Distributor 1045 (AKD) using one of the following methods, depending on the 1046 status of the AKD and the network condition: 1047 (a) through the All-KD-group (encrypted under the 1048 existing/old All-KD-Key) 1049 (b) through a one-to-one secure channel to each Area Key 1050 Distributor (AKD). 1052 6. Hosts Joining a Multicast Group 1054 When a host within a domain wishes to join a multicast group having 1055 already (at least) a member in the domain, the two possible 1056 approaches can be adopted in admitting the host to become a group 1057 member. In the first case, the host is disallowed from accessing 1058 (reading) traffic previous to its joining the group. In the second 1059 case, no such access restriction apply. The choice between the two 1060 approaches is dictated by policy, and hence beyond the scope of 1061 the current document. 1063 In the following, the strict re-keying policy is adopted, in which a 1064 re-keying of the Multicast-Key and the re-keying of the AreaGroupKey 1065 (of the area within which the new host joins) is conducted 1066 immediately. In the loose re-keying policy, the task is postponed 1067 until the next periodic re-keying, at which point the new member is 1068 able access (decipher) the data of the multicast group. 1070 In the following, it is assumed that when a host in an area (first 1071 member or otherwise) joins a multicast group the Area Key 1072 Distributor (AKD) has already created the necessary area control- 1073 groups in its area. To conserve resources, an AKD may postpone the 1074 control-group creation (corresponding to a given multicast group) 1075 until such time that a first member of the multicast group appears 1076 in its area. 1078 6.1 Joining with Backward Confidentiality 1080 When a new host joining a multicast group is to be prevented from 1081 accessing (reading) previous traffic (which it may have intercepted 1082 and stored), then Multicast-Key (MKey) of the multicast group in the 1083 domain must be re-keyed each time a host joins the multicast group. 1085 Note that even when a host is the first member of a multicast group 1086 in its area, all the other areas having a member must be re-keyed to 1087 reduce the possibility of that new host having access to previous 1088 traffic which it obtained (intercepted) in other areas. 1090 Protocol-VI: Host joining with backward confidentiality 1092 Step JB1: The host sends an authentic join-request message for the 1093 multicast group to its Area Key Distributor (AKD). 1095 Step JB2: The Area Key Distributor (AKD) checks the host against the 1096 Access Control List (ACL) of the multicast group. If the 1097 host is permitted to join, then the Area Key Distributor 1098 (AKD) authentically notifies the Domain Key Distributor (DKD) 1099 and the other Area Key Distributors (AKD) of the membership 1100 change (new host-member). Otherwise, the AKD returns a join- 1101 reject message to the host 1103 Step JB3: The Domain Key Distributor (DKD) initiates an immediate 1104 re-keying (Protocol-III: Re-keying the multicast key). This 1105 results in all Area Key Distributor (AKD) and all existing 1106 members of the multicast group obtaining the following 1107 multicast group parameters: 1108 - the existing multicast group address 1109 - the existing multicast group identity 1110 - the Multicast Group Security Association (MGSA) 1111 - the new Multicast-Key (MKey) 1112 - the new multicast key identifier MKeyID 1113 - a timestamp 1115 Step JB4: The Area Key Distributor (AKD) of the area (within which 1116 the host resides) must re-key its Area-Group-Key, and thus 1117 generates: 1118 - a new Group Security Parameter Index (GSPI) for the AGSA 1119 - a new Area-Group-Key (AreaGroupKey) 1120 - a new area key identifier AkeyID 1121 based on the AGSA selected by the AKD. 1123 Step JB5: The Area Key Distributor (AKD) digitally signs the area 1124 control-group parameters: 1125 - the existing area control-group address 1126 - the existing area control-group identity 1127 - the Multicast Group Security Association (MGSA) 1128 - the new Area-Group-Key (AreaGroupKey) 1129 - the new area key identifier AKeyID 1130 - a timestamp 1132 Step JB6: If there are existing host-members in the area, the Area 1133 Key Distributor (AKD) securely delivers the signed control- 1134 group parameters to each existing host-member (of the 1135 multicast group) in its area, using one of the following 1136 methods: 1137 (a) through the area control-group related to the multicast 1138 group (encrypted under the old/current AreaGroupKey) 1139 (b) through a one-to-one secure channel to each existing 1140 host-member. 1142 Step JB7: The Area Key Distributor (AKD) of the new host-member 1143 securely delivers the signed multicast group parameters (from 1144 Step JB3) and the signed control-group parameters (from Step 1145 JB5) to the new host-member through a one-to-one secure 1146 channel to the new host-member. 1148 Step JB8: The new host joins the multicast group (method 1149 unspecified). 1151 Step JB9: The new host joins the area control-group (method 1152 unspecified). 1154 6.2 Joining Without Backward Confidentiality 1156 Here, when a host joins a multicast group, the Multicast-Key need 1157 not be re-keyed since backward confidentiality is not required. The 1158 Area Key Distributor (AKD) of the host is already in possession of 1159 all the parameters related to the multicast group. 1161 Protocol-VII: Host joining without backward confidentiality 1163 Step JW1: The host sends an authentic join-request message for the 1164 multicast group to its Area Key Distributor (AKD). 1166 Step JW2: The Area Key Distributor (AKD) checks the host against the 1167 Access Control List (ACL) of the multicast group. If the 1168 host is permitted to join, then the Area Key Distributor 1169 (AKD) proceeds with the next step, otherwise it returns a 1170 join-reject message to the host. 1172 Step JW3: The Area Key Distributor (AKD) looks-up the following 1173 multicast group parameters which it previously digitally- 1174 signed: 1175 - the existing multicast group address 1176 - the existing multicast group identity 1177 - the Multicast Group Security Association (MGSA) 1178 - the new Multicast-Key (MKey) 1179 - the new multicast key identifier MKeyID 1180 - a timestamp 1182 Step JW4: The Area Key Distributor (AKD) looks-up the following 1183 control-group parameters which it previously digitally- 1184 signed: 1185 - the existing area control-group address 1186 - the existing area control-group identity 1187 - the Multicast Group Security Association (MGSA) 1188 - the existing Area-Group-Key (AreaGroupKey) 1189 - the existing area key identifier AKeyID 1190 - a timestamp 1192 Step JW5: The Area Key Distributor (AKD) of the new host-member 1193 securely delivers the signed multicast group parameters (from 1194 Step JW3) and the signed control-group parameters (from Step 1195 JW4) to the new host-member through a one-to-one secure 1196 channel to the new host-member. 1198 Step JW6: The new host joins the multicast group (method 1199 unspecified). 1201 Step JW7: The new host joins the area control-group (method 1202 unspecified). 1204 7. Host Leaving a Multicast Group 1206 The case of a host leaving a multicast group can be caused by a 1207 number of reasons depending on the policy dictating group membership 1208 and on the multicast application in question. 1210 From the perspective of the current design, re-keying must be 1211 conducted to preserve forward confidentiality. That is, re-keying 1212 must be conducted to prevent the ex-member from further accessing 1213 (deciphering) the data in the multicast group, even if the ex-member 1214 persists in being a part of the multicast distribution tree. 1216 In the following, the strict re-keying policy is adopted, in which a 1217 re-keying of the Multicast-Key and the re-keying of the Area-Group- 1218 Key (AreaGroupKey) of the area within which the new host joins are 1219 conducted immediately. In the loose re-keying policy, the task is 1220 postponed until the next periodic re-keying, at which point the ex- 1221 member ceases to be able to decipher traffic in the multicast group 1222 and its corresponding control-group in the area. 1224 Note that in the current design, when a host leaves a 1225 multicast group it must also (by default) depart from the associated 1226 control-group. In general, it makes no sense for a host to join a 1227 control-group without joining the corresponding multicast group. 1229 Protocol VIII: Host leaving a multicast group and control-group 1231 Step LB1: The leaving-host sends an authentic leave-request message 1232 for the multicast group to its Area Key Distributor (AKD). 1233 Alternatively, the Domain Key Distributor (DKD) notifies the 1234 AKD through an authentic eject-host-request message to the 1235 AKD. 1237 Step LB2: The Domain Key Distributor (DKD) of the affected area 1238 authentically notifies the other Area Key Distributors (AKD) 1239 of the membership change (host-member leaving). 1241 Step LB3: The Domain Key Distributor (DKD) initiates an immediate 1242 re-keying (Protocol-III: Re-keying the multicast key). This 1243 results in all Area Key Distributors (AKDs) and all host- 1244 members of the multicast group, except host-members in the 1245 affected area, obtaining the following multicast group 1246 parameters: 1247 - the existing multicast group address 1248 - the existing multicast group identity 1249 - the Multicast Group Security Association (MGSA) 1250 - the new Multicast-Key (MKey) 1251 - the new multicast key identifier MKeyID 1252 - a timestamp 1254 Step LB4: The Area Key Distributor (AKD) of the affected area 1255 (within which the leaving-host resides) must re-key its Area- 1256 Group-Key, and thus generates: 1257 - a new Group Security Parameter Index (GSPI) for the AGSA 1258 - a new Area-Group-Key (AreaGroupKey) 1259 - a new area key identifier AkeyID 1260 based on the AGSA selected by the AKD. 1262 Step LB5: The Area Key Distributor (AKD) digitally signs the area 1263 control-group parameters: 1264 - the existing area control-group address 1265 - the existing area control-group identity 1266 - the Multicast Group Security Association (MGSA) 1267 - the new Area-Group-Key (AreaGroupKey) 1268 - the new area key identifier AKeyID 1269 - a timestamp 1270 and digitally-signs the multicast group parameters that the 1271 AKD received from the DKD in Step LB3: 1272 - the existing multicast group address 1273 - the existing multicast group identity 1274 - the Multicast Group Security Association (MGSA) 1275 - the new Multicast-Key (MKey) 1276 - the new multicast key identifier MKeyID 1277 - a timestamp 1279 Step LB6: The Area Key Distributor (AKD) securely delivers the 1280 signed multicast group parameters and control-group 1281 parameters to each remaining host-member (of the multicast 1282 group) in its area, through a one-to-one secure channel to 1283 each existing host-member. 1285 Step LB7: The leaving-host leaves the multicast group (method 1286 unspecified). 1288 Step LB8: The leaving-host leaves the area control-group (method 1289 unspecified). 1291 8. Reliability in Key Management 1293 The current document recognizes that key management be conducted 1294 in a reliable manner, due to the sensitivity of cryptographic keys 1295 and the basic necessity that a host-member obtain the multicast key 1296 before it can access (decipher) the multicast data. Reliability is 1297 also important in the re-keying of the keys used in the multicast 1298 group and in the area control-groups. This is true particularly if 1299 in the re-keying process, the control-group itself is used to 1300 transmit the new parameters (for either the multicast group or the 1301 same control-group) to the members of the group. 1303 However, the current document views reliability of transmission, 1304 particularly in the control-groups, as more of a multicast- 1305 reliability issue. That is, reliability should not be expected from 1306 and should not be part of key management. This is also true for the 1307 one-to-one "secure channels", in which confidential and authentic 1308 communications is created between a sender and a receiver through 1309 the previously-established Security Association (SA) and the shared 1310 private-key. 1312 Note that in the re-keying of a Multicast-Key (MKey), it is 1313 important that each Area Key Distributor (AKD) first reliably 1314 obtains the new parameters (including the new key) of the multicast 1315 group. This is because without the new parameters, the AKD will not 1316 be able to even begin to re-key its area. Once each AKD obtains the 1317 new parameters of the multicast group, the re-key of the Multicast- 1318 Key in each area is independent of one another. 1320 The current work currently does not specify how or what 1321 manner reliability in key management is to be achieved. However, 1322 when a control-group (either the All-KD-group or an area control- 1323 group) is used for key management from a sender to a number of 1324 recipients (eg. delivery of new key and new parameters) several 1325 basic approaches can be used: 1327 (a) ACKs from members 1329 When a control-group is used to transmit re-keying parameters, the 1330 recipients simply return an acknowledgment (ACK) to the Key 1331 Distributor through the secure channel previously established with 1332 the Key Distributor. Should the Key Distributor fail to receive 1333 such an ACK from a recipient within specified time, it will then 1334 query the recipient through the secure channel previously 1335 established. Depending on the frequency of key management and the 1336 number of host-members, this approach may cause an ACK-implosion on 1337 the AKDs. 1339 (b) Timeouts 1341 When some period after a prepare-to-rekey message is received, some 1342 recipients fail to receive the actual new key and parameters through 1343 the control-group, those recipients query the sender (AKD or DKD). 1345 When nothing is heard after both the due time for the prepare-to- 1346 rekey message and due time for the actual key/parameters to be 1347 received, the recipients query the sender (AKD or DKD). 1349 (c) Explicit Reliable Multicast (RM) protocol 1351 Employ a specific RM protocol to establish reliability within the 1352 All-KD-group and/or the area control-groups. Each control-group can 1353 in fact employ different RM protocols. 1355 9. Packet Formats 1357 To be decided. 1359 10. References 1361 [HCD98] T. Hardjono, B. Cain and N. Doraswamy, "A Framework for 1362 Group Key Management for Multicast Security", Internet Draft, July 1363 1998. 1365 [HC98] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", 1366 Internet Draft, June 1998. 1368 [WGL98] C. K. Wong, M. Gouda and S. Lam, "Secure Group 1369 Communications Using Key Graphs", in Proceedings of SIGCOMM'98. 1371 [KA98a] S. Kent and R. Atkinson, "Security Architecture for the 1372 Internet Protocol", IETF, RFC 1825, 1998. 1374 [KA98b] S. Kent and R. Atkinson, "IP Encapsulating Security Payload 1375 (ESP)", Internet Draft, July 1998. 1377 [KA98c] S. Kent and R. Atkinson, "IP Authentication Header", 1378 Internet Draft, July 1998. 1380 [Mey98] D. Meyer, "Administratively Scoped IP Multicast", IETF, RFC 1381 2365, July 1998. 1383 [HTE98] M. Handley, D. Thaler, and D. Estrin, "The Internet 1384 Multicast Address Allocation Architecture", Internet Draft, June 1385 1998. 1387 11. Author Addresses 1389 Thomas Hardjono 1390 Email: thardjono@baynetworks.com 1392 Brad Cain 1393 Email: bcain@baynetworks.com 1395 Inder Monga 1396 Email: imonga@baynetworks.com 1398 Nortel Networks 1399 3 Federal Street, Bl3-03 1400 Billerica, MA 01821, USA 1401 Tel: +1-978-916-4538 1403 12. Full Copyright Statement 1405 Copyright (C) The Internet Society (1998). All Rights Reserved. 1407 This document and translations of it may be copied and furnished to 1408 others, and derivative works that comment on or otherwise explain it 1409 or assist in its implementation may be prepared, copied, published 1410 and distributed, in whole or in part, without restriction of any 1411 kind, provided that the above copyright notice and this paragraph 1412 are included on all such copies and derivative works. However, this 1413 document itself may not be modified in any way, such as by removing 1414 the copyright notice or references to the Internet Society or other 1415 Internet organizations, except as needed for the purpose of 1416 developing Internet standards in which case the procedures for 1417 copyrights defined in the Internet Standards process must be 1418 followed, or as required to translate it into languages other than 1419 English. 1421 The limited permissions granted above are perpetual and will not be 1422 revoked by the Internet Society or its successors or assigns. 1424 This document and the information contained herein is provided on an 1425 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1426 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1427 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1428 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1429 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.