idnits 2.17.00 (12 Aug 2021) /tmp/idnits14890/draft-irtf-smug-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: ---------------------------------------------------------------------------- == 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 55 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([HCD00]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2001) is 7758 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. 'HCD00' -- 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: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Thomas Hardjono (Nortel) 2 INTERNET-DRAFT Brad Cain (Mirror Image) 3 draft-irtf-smug-intragkm-00.txt Indermohan Monga (Nortel) 4 September 2000 Expires February 2001 6 Intra-Domain Group Key Management Protocol 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes a protocol for intra-domain group key 35 management for IP multicast security, based on the framework of 36 [HCD00]. In order to support multicast groups, the domain is divided 37 into a number of administratively-scoped "areas". A host-member of 38 a multicast group is defined to reside within one (and only one) of 39 these areas. The purpose of placing host-members in areas is to 40 achieve flexible and efficient key management, particularly in the 41 face of the problem of changes (joining, leaving, ejections) in the 42 membership of a multicast group. A separate administratively-scoped 43 area control-group is defined for each (data) multicast group, for 44 the express purpose of key management and other control-message 45 delivery. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1 Domains, Areas and Key Distributors . . . . . . . . . . . 4 53 3.2 Trust Relationships. . . . . . . . . . . . . . . . . . . . 5 54 3.3 Multicast Groups for Data and Control. . . . . . . . . . . 6 55 3.4 Keys: Multicast Groups and Control-Multicast Groups. . . . 7 56 3.5 Control-Multicast Groups: Address Allocation . . . . . . . 8 57 3.6 Group Security Associations . . . . . . . . . . . . . . . 10 58 3.7 Secure Channels. . . . . . . . . . . . . . . . . . . . . .11 59 3.8 Periodic Re-Keying . . . . . . . . . . . . . . . . . . . .11 60 3.9 Arrangement of Keys in the Domain. . . . . . . . . . . . .12 61 4. Creation of New Multicast Groups. . . . . . . . . . . . . . . 16 62 4.1 Initiation of New Internal-Origin Groups . . . . . . . . .16 63 4.2 Membership to External-Origin Groups. . . . . . . . . . .19 64 5. Re-Keying Approach . . . . . . . . . . . . . . . . . . . . . .20 65 5.1 Re-Keying of Multicast Keys . . . . . . . . . . . . . . .20 66 5.2 Re-Keying of Area Keys . . . . . . . . . . . . . . . . . .21 67 5.3 Re-Keying of the All-KD-Key. . . . . . . . . . . . . . . .22 68 6. Hosts Joining a Multicast Group. . . . . . . . . . . . . . . .23 69 6.1 Joining with Backward Confidentiality . . . . . . .. . . .24 70 6.2 Joining Without Backward Confidentiality . . . . . . . . .25 71 7. Host Leaving a Multicast Group . . . . . . . . . . . . . . . .27 72 8. Reliability in Key Management. . . . . . . . . . . . . . . . .28 73 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .30 74 10. References. . . . . . . . . . . . . . . . . . . . . . . . . .30 76 1. Introduction 78 This document describes a protocol for intra-domain group key 79 management for IP multicast security, based on the framework of 80 [HCD00]. In order to support multicast groups, the domain is divided 81 into a number of administratively-scoped "areas". A host-member of 82 a multicast group is defined to reside within one (and only one) of 83 these areas. The purpose of placing host-members in areas is to 84 achieve flexible and efficient key management, particularly in the 85 face of the problem of changes (joining, leaving, ejections) in the 86 membership of a multicast group. 88 A separate administratively-scoped area control-group is defined for 89 each (data) multicast group, for the express purpose of key 90 management and other control-message delivery. A unique 91 cryptographic key is associated with every (multicast group, 92 control-group) pair in a given area. The control-groups are used 93 for key management, following the re-keying behavior described in 94 [WGL98] and extending it over several key distributor entities. 96 2. Background 98 The current document follows from the group key management 99 framework proposal of [HCD00]. The framework of [HCD00] introduces 100 two planes corresponding to the network entities and functions 101 pertaining to multicasting ("network infrastructure plane") and to 102 security ("key management plane"). Within the key management plane 103 two hierarchies (levels) of regions are introduced, namely one 104 "trunk region" (inter-region) and one or more "leaf regions" (intra- 105 region). These regions are defined to have unique group keys and 106 are open to differing (inter-region or intra-region) group key 107 management protocols. 109 The current work introduces an "intra-region" (leaf-region) group 110 key management protocol, where the term "domain" in the current 111 work is taken to mean a single leaf region of [HCD00]. Although in 112 practice one leaf region of [HCD00] can consist on one or more of 113 our current "domains", for simplicity we assume that one leaf region 114 corresponds to one current domain. 116 The definition of a "domain" (leaf) here is viewed more from an 117 administrative perspective, in which the "domain" is administered 118 and controlled by one body. This single-administration perspective 119 is assumed both for multicasting and for key management. 121 The group key management behavior in the current document is 122 inspired by the work of [WGL98] which is based on a centralized 123 server. The current work extends it to cover multiple entities in a 124 distributed fashion. 126 The current document addresses group key management for multicast 127 security. The issue of how a cryptographic key is applied to data 128 in a multicast group is not addressed, although the current document 129 points to IPsec (ESP and AH) [KA98a, KA98b, KA98c] as a foremost 130 candidate, depending on the multicast application type. Although in 131 the document a key is used to "encipher" the multicast data to 132 control access by group members, the intent is clear that 133 authentication-only multicast applications may also employ the 134 current design. 136 The current document seeks to cover both the one-to-many and many- 137 to-many multicast application types. Hence, the protocol has 138 been described is the broadest way possible, without affecting the 139 security of key management in general. 141 3. Architecture 143 The current work aims to manage multicast group keys based 144 on well-defined domains. It also distinguishes between multicast 145 groups for the purpose of payload delivery and for the purpose of 146 key management. 148 The current document is concerned with the correct and secure 149 delivery of keys to members of a multicast group. It does not 150 prescribe how a key is to be used on the data being transmitted in 151 the multicast group. The reader is directed to methods such as 152 IPsec ESP [KA98b] for concrete possibilities. 154 |--------------R/TE-------------| 155 | | 156 | DKD DMAAE | 157 | | 158 | ----R---- ----R---- ----R---- | 159 | | | | | | | | 160 | | AKD | | AKD | | AKD | | 161 | | | | | | | | 162 | | R R | | 163 | | m m m | | m m m | | m m m | | 164 | --------- --------- --------- | 165 |_______________________________| 167 Figure 1: Intra-Domain Group Key Management Elements 169 3.1 Domains, Areas and Key Distributors 171 At the domain-level, a Domain Key Distributor (DKD) entity is 172 defined for the domain for the purpose of key management. 174 In order to support multicast groups, the domain is divided into a 175 number of administratively-scoped "areas" [Mey98]. A host-member of 176 a multicast group is defined to reside within one (and only one) of 177 these areas. The purpose of placing host-members in areas is to 178 achieve flexible and efficient key management, particularly in the 179 face of the problem of changes (joins and leaves) in the membership 180 of a multicast group. 182 At the area level, an Area Key Distributor (AKD) entity is defined 183 for each area for the purpose of key management. 185 Depending on the address allocation approach (see Section 3.4), each 186 area may be associated with one Area Multicast Address Allocation 187 Entity (AMAAE), such the MAAS of [HTE98], from which the Area Key 188 Distributor (AKD) of that area obtains area-wide multicast 189 addresses. In addition, at the domain-level, a Domain Multicast 190 Address Allocation Entity (DMAAE) must exist to cater for the 191 domain. 193 Within the domain, all Key Distributors (the DKD and AKDs) are 194 members of the domain-wide administratively-scoped multicast group, 195 called the "All-KD-group", which does not extend beyond the domain 196 and whose membership consists only of Key Distributors. 198 The Domain Key Distributor (DKD) communicates to Area Key 199 Distributors (AKD) either through secure one-to-one (unicast) 200 communications or through the All-KD-group. The All-KD-group is 201 independent of other multicast groups and it exists even when there 202 are no host-members of any multicast group in the domain. 204 The Area Key Distributor (AKD) communicates to host-members residing 205 in its area either through secure one-to-one (unicast) 206 communications or through a special (ie. control) multicast group 207 whose scope is limited to that area. 209 Should a multicast group originate from outside the domain and 210 should its traffic be enciphered under a foreign key, then 211 Translating Entity(s) (TE), such as a border-router(s), must be 212 specified in the domain. In such a case, the Domain Key Distributor 213 (DKD) is assumed to have a copy of the foreign key through other 214 methods (unspecified). The DKD will then supply the Translating 215 Entity(s) with a copy of the foreign key and a copy of a new 216 multicast key to be used on the traffic in the domain. 218 3.2 Trust Relationships 220 The trust relationship in the current work revolves around the Key 221 Distributors and does not extend beyond the domain. All Key 222 Distributors (DKD and AKDs) are configured and maintained by the 223 human administration in the domain. They must be implemented using 224 the most secure technology available, since they represent the best 225 point-of-attack. 227 All entities trust the Domain Key Distributor (DKD) as the primary 228 source of authentic parameters. The DKD can in fact also take-on 229 the role of a certification authority when the need arises. The 230 public-key of the DKD is well-known to (and/or is configured within) 231 each host and within the Area Key Distributors (AKDs). 233 A host residing within an area trusts the Area Key Distributor (AKD) 234 in that area. 236 3.3 Multicast Groups for Data and Control 238 The current work employs administratively-scoped multicast 239 groups for the purpose of key management. 241 To distinguish these administratively-scoped multicast groups for 242 control (ie. key management) from the multicast group for data, the 243 latter will be referred to as "data multicast groups", "data-groups" 244 or simply "multicast groups". A control-related group will be 245 referred to as "control-multicast group" or simply "control-group". 247 A "control-group" is an administratively-scoped multicast group 248 which is area-wide. It is initiated/owned by the Area Key 249 Distributor (AKD) of an area. The purpose of an area control-group 250 is for key management relating to an associated data-multicast 251 group. 253 An area control-group associated with a data-multicast group exists 254 so long as there are members of the corresponding data-multicast 255 group in the area. Once a data-multicast group ceases to have any 256 members in an area, the Area Key Distributor (AKD) of that area may 257 terminate that corresponding area control-group. 259 A special control-group is the All-KD-group. This is an 260 administratively-scoped multicast group which is domain-wide and 261 consists only of the Domain Key Distributor (DKD) and Area Key 262 Distributors (AKD). It has a fixed address and is initiated/owned by 263 the Domain Key Distributor (DKD). There is only one All-KD-group in 264 a domain, and it is a permanent group, independent of whether any 265 data multicast group members exists in the domain. Unless 266 specifically mentioned, in the remainder of this document all 267 control-groups are area control-groups. 269 Note that once a host (in an area within the domain) becomes a 270 member of a multicast group, it also must become a member of one of 271 the area control-groups of the area within which that host resides. 272 This allows the Area Key Distributor (AKD) to communicate with the 273 host-member through the area control-group. 275 From the perspective of an Area Key Distributor (AKD) of an area, 276 for a multicast group having a host-member in its area, the Key 277 Distributor (AKD) must assign that host-member to one of the area 278 control-groups in that area. 280 3.4 Keys: Multicast Groups and Control-Multicast Groups 282 A multicast group is associated with a domain-wide Multicast-Key 283 (MKey). The current work assumes that cryptographic keys are 284 used for the encipherment of the multicast traffic as a method to 285 provide receiver access-control, where only valid members of the 286 multicast group is provided with a copy of the cryptographic key. 287 This is true for data multicast groups and area control-groups. 289 For each multicast group having a member in the domain, a unique 290 Multicast-Key (MKey) is assigned by the Domain Key Distributor (DKD) 291 for that multicast group. 293 A multicast group having a member in an area in the domain is 294 associated with one control-group in the area by the Area Key 295 Distributor (AKD) of that area. All traffic within an area control- 296 group is enciphered in such a way that only the AKD of that area and 297 the intended receivers of the traffic will be able to decipher the 298 traffic. The cryptographic key associated with an area control- 299 group is referred to generally as the Area-Group-Key (AreaGroupKey). 300 An Area-Group-Key is selected by the Area Key Distributor (AKD). 301 The Area-Group-Key (AreaGroupKey) is unique for each (multicast 302 group, control-group) pair. 304 For the special All-KD-group, an All-KD-Key (AllKDKey) is assigned 305 by the Domain Key Distributor (DKD) for the All-KD-group. 307 Here, it is assumed (initially) that all payload 308 related to a multicast group travelling within a domain is encrypted 309 using the Multicast-Key (MKey). Should the sender of the multicast 310 group be located outside the domain, then a "Translating-Entity" 311 (TE), such as the border-router of the domain, must be employed to 312 decrypt the entering traffic (using some inter-domain cryptographic 313 key) and to re-encrypt it using the Multicast-Key (MKey) assigned in 314 the domain to that multicast group. Similarly, the Translating- 315 Entity must "translate" multicast group traffic (sent from a group 316 member in the current domain) when the traffic leaves the domain. 318 The "boot-strapping" process of each multicast group and control- 319 group relies on the establishment of a Security Association (SA) and 320 a shared private-key between a (candidate) member of the group with 321 the Key Distributor (DKD or AKDs) that controls the group. It is 322 through this one-to-one secure channel that the parameters for the 323 groups are then given to host-members by the Area Key Distributor in 324 the case of the multicast group and area control groups, or to the 325 Area Key Distributors (AKDs) by the Domain Key Distributor (DKD) in 326 the case of the All-KD-group. 328 3.5 Control-Multicast Groups: Address Allocation 330 Three possible approaches are available with regards to the use of 331 area control-groups (corresponding to a given multicast group) for 332 key management by the Area Key Distributor (AKD): 334 (a) One control-group per area per multicast group: 336 For each multicast group, having members in an area, a separate 337 control-group is created within the area. 339 Each separate area control-group is associated with a different 340 Area-Group-Key. 342 One disadvantage of this approach is the potential lack of 343 multicast addresses within the area. Another disadvantage is the 344 waste of resource related to area-wide multicasting if the area 345 only has very few members of the corresponding multicast group. 346 This approach requires the presence of an Area Multicast Address 347 Allocation Entity (AMAAE) in each area. 349 (b) One control-group per area for all multicast groups: 351 In this approach, for each multicast group, having members in an 352 area, only one control-group is created within the area. Hence, 353 the area control-group is shared among members of different 354 multicast groups. 356 Although there is only one (shared) area control-group, a 357 separate Area-Group-Key is used for each data multicast group. 358 When the AKD wishes to communicate with members of a particular 359 multicast group residing in its area, the AKD will encipher the 360 communications using the appropriate Area-Group-Key. Other non- 361 intended recipients will also receive the enciphered packets, but 362 will drop them since they will not be able to decipher them. 364 The advantage of this approach is that there is only one control- 365 group which can be long-lived and have a fixed address. Having 366 the fixed address obviates the Area Multicast Address Allocation 367 Entity (AMAAE), thereby simplifying the entire design. 369 The main disadvantage of this approach is that bandwidth within 370 the area is wasted when the AKD is performing key management 371 communications with only a small subset of group members residing 372 in the area, since all other unconcerned members are receiving 373 the (enciphered) packets and dropping them. Another related 374 disadvantage is increased opportunity for cryptanalysis of 375 enciphered packets of control-groups, since unconcerned members 376 are receiving these packets and may cryptanalyze them. 378 (c) One control-group per area for several multicast groups: 380 This approach attempts to bring together the advantages of the 381 previous two. For a fixed number of multicast groups, having 382 members in an area, a single control-group is created within the 383 area. 385 Thus, within a given area a set of N multicast addresses for N 386 control-groups can be selected and fixed. Each multicast group 387 having (one or more members in an area) is then mapped to one of 388 the N control-groups in that area (eg. by hashing the multicast 389 group address). 391 In terms of key management, each (multicast group, control-group) 392 pair will be associated with a unique Area-Group-Key 393 (AreaGroupKey). 395 Thus, for example, a host who is a member of two multicast groups 396 MG1 and MG2 may find that in its area both MG1 and MG2 are mapped 397 into one control-group CG1, with two Area-Group-Keys AGK1 and 398 AGK2 corresponding to the two multicast groups. Hence, for the 399 control-group CG1 the host must maintain the unique triplets 400 (MG1, CG1, AGK1) and (MG2, CG1, AGK2). The host must be able to 401 distinguish control-group packets in CG1 corresponding to the two 402 multicast groups, in order for it to apply the matching keys. 403 Tagging methods within control-packets may be employed to achieve 404 this effect, saving the host the effort of trying the keys. 406 In this manner, the design is simplified by obviating the 407 Area Multicast Address Allocation Entity (AMAAE) for each area, 408 and the problem of unintended members receiving and dropping 409 (enciphered) messages is also somewhat reduced. 411 The current work will employ the third approach due to its 412 simplicity. We specify that an Area Key Distributor 413 (AKD) maintains a mapping between a multicast group and its 414 corresponding control-group in the area. How this mapping is 415 established is implementation-specific, and thus outside the scope 416 of the document. Furthermore, we assume that each 417 control-group packet carries sufficient identification information 418 relating to the multicast group to which it corresponds, thereby 419 allowing non-intended receivers of the packets in the shared 420 control-group to drop the packets without attempting to decrypt it. 422 3.6 Group Security Associations 424 The IPsec security architecture [KA98a] defines the concept of a 425 Security Association (SA) between two communicating parties. An SA 426 is a simplex connection that affords security services to the 427 traffic carried by it. An SA is uniquely identified by the triple 428 consisting of the Security Parameter Index (SPI), an IP Destination 429 Address and a security protocol identifier. Thus, for a two way 430 communications, two Security Associations must be negotiated and 431 established. 433 The current work recognizes that for the many-to-many 434 multicast applications the basic IPsec Security Association as a 435 simplex connection does not suffice. Hence, it uses the notion of a 436 Multicast Group Security Association (GSA) derived from the simplex 437 Security Association. Note that the concept of a GSA for multicast 438 has previously been describe, albeit briefly, in the IPsec security 439 architecture document [KA98a] and other related documents. 441 In the current document we assume that a Group Security 442 Association (GSA) attributes is not negotiated between the 443 communicating parties, but rather selected by one party. The entity 444 that selects the GSA depends on the whether it is a multicast group 445 or a control-group. All members of the group would then use the one 446 same Group Security Parameter Index (GSPI) related to the GSA. 447 Similarly, when a re-keying occurs, a new Group Security Parameter 448 Index (GSPI) must selected for the GSA and a new key must be 449 generated by one entity and delivered to the group members. 451 The notion of a Group Security Association (GSA) selected by one 452 entity departs from the existing IPsec definition and has 453 implications on the ability of hosts to join multicast groups. 454 Recall that in the two-party communication scenario, each party 455 negotiates the Security Association (SA) depending on their 456 cryptographic capability (eg. cryptographic algorithms available). 457 In the case of a Group Security Association (GSA) selected by one 458 entity, the required capability (eg. minimal algorithms) demanded of 459 a potential member must be announced through other methods, such as 460 through the multicast session description protocol or other 461 protocols. In this way, a multicast group initiator or owner can 462 specify what cryptographic algorithm(s) can be used in the multicast 463 group. This approach is in-line with the one-to-many multicast 464 applications (eg. pay per view service owners) and is deemed 465 reasonable within the many-to-many multicast applications. 467 3.7 Secure Channels 469 The general term "secure channel" is used in the remainder of the 470 current document to mean communications between one sender and one 471 receiver (unicast), with authenticity and confidentiality. Secure 472 channels here will be based on IPsec (AH and/or ESP) [KA98a]. The 473 term implies the existence of a Secure Association (SA) and a 474 private-key shared between the sender and receiver before the two 475 begin communicating securely. The IKE protocol [HC98] can be used 476 to establish the Security Association and the shared private-key. 478 Independent of the Group Security Association (GSA) for the 479 multicast group, each host-member is assumed to have establish a 480 Security Association (SA) and a shared private-key with the Area Key 481 Distributor (AKD) of the area within which that host resides before 482 the host joins any groups. Similarly, each Area Key Distributor 483 (AKD) is assumed to have establish a Security Association (SA) and a 484 shared private-key with the Domain Key Distributor (DKD) before the 485 AKD serves any multicast groups. 487 A "secure channel" between one sender and one receiver implies that 488 the identity of the one is known to the other. Hence, in 489 communicating via a secure channel with a Key Distributor (AKD or 490 DKD) a host-member is by definition identified and authenticated by 491 the Key Distributor, and vice versa. 493 3.8 Periodic Re-Keying 495 It is commonly accepted that the longer a cryptographic key is being 496 employed, the higher the chances of that key being successfully 497 cryptanalyzed by an attacker (who is assumed to have collected 498 ciphertext of messages encrypted using the key). This is 499 particularly true for keys of symmetric cryptosystems. 501 The current document recognizes the importance of periodic re- 502 keying and attempts to provide a workable solution in the face of 503 the issue of re-keying due to a new host-member joining (backward 504 confidentiality) and the issue of an existing member leaving or 505 being ejected (forward confidentiality). 507 The approach of re-keying only when the group membership changes 508 suffers from the possibility that the membership does not in fact 509 change over long periods, and thus opening the possibility of 510 cryptanalysis of the multicast key. 512 Hence, the current design adopts the underlying philosophy 513 that periodic re-keying is necessary (even if the membership of the 514 multicast group does not change), independent of whether or not 515 immediate re-keying is performed when a host joins/leaves the 516 multicast group. In this way, the design provides flexibility 517 for the implementor to be "strict" (immediate re-key at each 518 membership change) or to be "loose" (wait until next periodic re- 519 key) with regards to multicast key re-keying. 521 In the following discussions on the group key management protocols, 522 the current work will observe the strict re-keying policy (ie. 523 immediate re-key at each membership change) since it represents a 524 more complex case. The loose re-keying can be established by 525 removing some steps from the protocols and executing other steps 526 only when the designated periodic re-keying occurs. Periodic re- 527 keying in the multicast group will be determined by the Domain Key 528 Distributor (DKD) and implemented with the aid of the Area Key 529 Distributors (AKDs). Periodic re-keying in a control-group (in an 530 area) associated with a multicast group will be determined by the 531 Area Key Distributor (AKD) of that area. 533 From the perspective of multicast reliability, the approach of using 534 periodic re-keying allows each Key Distributor (AKD and DKD) to 535 prepare for the re-keying, hence providing them with a window of 536 opportunity to obtain the next key. Having this window of 537 opportunity provides a context within which reliability mechanisms 538 for key delivery can be established, either through existing 539 reliable multicast protocols or through mechanisms specific to key 540 management. In either case, the current document recognizes that 541 reliability is paramount to group key management if multicast 542 security is to be achieved. 544 3.9 Arrangement of Keys in the Domain 546 The current protocol aims at delivering a multicast key, in the 547 form of a private-key (symmetric cryptography), to members of a 548 multicast group or a control-group. The fact that a host holds a 549 copy of the multicast key is taken to mean that the host has 550 previously been correctly identified by its Area Key Distributor 551 (AKD) and that it has established a Security Association with its 552 AKD. The private-key used in a multicast group or a control-group 553 affords confidentiality and "group authentication" in the sense that 554 the source of any information enciphered under the key is a valid 555 member of the group. Note, that this level of authentication (group 556 authentication) is implicit and does not provide irrefutable proof 557 of the singular identity of the sender. 559 The current document recognizes the benefits of a public key 560 certification infrastructure and is open to such an infrastructure 561 being deployed, with each entity being assigned a public key. 563 However, in order to render the protocol immediately deployable 564 in the near future, we assume that public keys are 565 assigned only to the Key Distributors (DKD and AKDs) and the Domain 566 Multicast Address Allocation Entity (DMAAE) to allow them to 567 digitally-sign information that is to be sent through the multicast 568 group or the control-groups. These public keys are valid only 569 within the domain, and may not be recognized outside the domain 570 (unless a certification infrastructure is employed). 572 3.9.1 Public Keys 574 The current protocol assumes that all Key Distributors (DKD and 575 AKDs) are assigned public-keys (asymmetric cryptography) in order 576 for these Key Distributors to digitally-sign certain information in 577 such a way that it is verifiable by all hosts in the domain. 579 A host-member residing in area is assumed to have a copy of the 580 public-key of its Area Key Distributor (AKD) and the public-key of 581 the Domain Key Distributor (DKD). 583 An Area Key Distributor (AKD) is assumed to have a copy of the 584 public-key of the Domain Key Distributor (DKD). An Area Key 585 Distributor (AKD) may obtain the public-keys of other Area Key 586 Distributors from the Domain Key Distributor (DKD), with the DKD 587 acting as a domain-wide certification authority. 589 Al the very least, the public key of the Domain Key Distributor 590 (DKD) must be advertised in a tamper-proof manner (eg. printed or 591 manually configured) to allow it to be used to vouch for the public 592 keys of the Area Key Distributors (AKDs). 594 3.9.2 Shared Private-Keys 596 Three types of group-oriented (ie. shared by a group) private-keys 597 (symmetric cryptography) are used: 599 - Multicast-Key (MKey): this is the private-key associated with a 600 multicast group that is used by all the group members in the 601 domain to encrypt/decrypt the multicast traffic in the multicast 602 group. This key is generated by the Domain Key Distributor (DKD) 603 of the domain. 605 This key is delivered securely to each Area Key Distributor 606 (AKD), who will in turn deliver the key securely to each group 607 member in their area. 609 - Area-Group-Key (AreaGroupKey): this is the private-key associated 610 with the (multicast group, control-group) pair, and used to 611 encipher the communications in the control-group. An Area-Group- 612 Key is generated by the Area Key Distributor (AKD) of that area 613 and delivered to each member through a secure-channel. An Area- 614 Group-Key is known only to the AKD of an area and the members (of 615 the corresponding multicast group) residing in that area. 617 - All-KD-Key (AllKDKey): this is the private-key associated with 618 the special All-KD-group. All the Area Key Distributors (AKDs) 619 and the Domain Key Distributor (DKD) hold a copy of the All-KD- 620 Key. This key is generated by the Domain Key Distributor (DKD) 621 and delivered to each AKD through a secure-channel. This key is 622 used to encipher the communications within the All-KD-group. 624 Two types of pair-oriented private-key are used in the current 625 work: 627 - Member-Private-Key (MbrPKey): Each host-member in an area pair- 628 wise shares a Security Association (SA) and a Member-Private-Key 629 (MbrPKey) with the Area Key Distributor (AKD) of that area. The 630 Security Association (SA) and the Member-Private-Key (MbrPKey) 631 are long-term and must be established before the host-member 632 joins (or initiates) any multicast groups and is given a copy of 633 that group's Multicast-Key (MKey). There is only one SA and one 634 MbrPKey shared between the host-member and the Area Key 635 Distributor (AKD), independent of the number of multicast groups 636 to which that host-member belongs. 638 - AKD-Private-Key (AKDPKey): Each Area Key Distributor (AKD) of an 639 area pair-wise shares a Security Association (SA) and a AKD- 640 Private-Key with the Domain Key Distributor (DKD). The Security 641 Association and the AKD-Private-Key (AKDPKey) are long-term and 642 must be established before any multicast group exists in the 643 domain. 645 In summary, the private-key arrangement from the point of view of 646 entities is as follows. 648 Hosts: 649 A host-member of a multicast group residing in an area holds a 650 copy of the Multicast-Key (MKey) and a copy of the Area-Group-Key 651 (AreaGroupKey) corresponding to the (multicast group, control- 652 group) pair. In addition, the host-member also holds its own 653 Member Private-Key (MbrPKey) independent of any multicast groups. 655 Area Key Distributors (AKD): 656 For each multicast group having a member in an area, the Area Key 657 Distributor (AKD) of the area holds a copy of the Multicast-Key 658 (MKey) of the multicast group and holds a unique Area-Group-Key 659 (AreaGroupKey) corresponding to each (multicast group, control- 660 group) pair. 662 In addition, an AKD also holds a copy of the current All-KD-Key 663 (AllKDKey), its own AKD-Private-Key (AKDPKey) and a copy of the 664 Member Private-Key (MbrPKey) of each member residing in its area. 665 These (the AllKDKey, AKDPKey and MbrPKeys) are independent of any 666 multicast groups to which a resident host-member belongs. 668 Domain Key Distributor (DKD): 669 The Domain Key Distributor (DKD) of a given domain holds the 670 Multicast-Key (MKey) for each multicast group, a copy of the 671 current All-KD-Key (AllKDKey), and a copy of the AKD-Private-Key 672 (AKDPKey) of each Area Key Distributor (AKD) in the domain. 674 -------------------------------------------------------- 675 Multicast access purposes: Multicast Key (MKey) 676 ======================================================== 677 Control purposes: 678 -------------------------------------------------------- 679 Pair-wise Shared Group-wise shared 680 ----------------------- ----------------------- 681 DKD Key: AKD-Private-Key Key: All-KD-Key 682 with - Long-term - Medium-term 683 AKD - Independent of groups - Independent of groups 685 AKD Key: Member-Private-Key Key: Area-Group-Key 686 with - Long-term - Medium-term 687 Hosts - Independent of groups - N per area 688 -------------------------------------------------------- 689 Table 1: Key arrangement 691 Note that the Domain Key Distributor (DKD) does not hold copies of 692 the Member-Private-Keys (MbrPKey). This is in contrast to the 693 approach in [WGL98] in which a central server holds the private-keys 694 of all members in the multicast group. If a host is in need of 695 communicating directly through a secure channel to the Domain Key 696 Distributor (DKD) or any other entity, then the host must establish 697 a Security Association and a shared private-key with the DKD or 698 entity. 700 Although currently not prescribed, depending on the reliability 701 mechanism to be employed, the Domain Key Distributor (DKD) may hold 702 copies of the Area-Group-Key (AreaGroupKey) within each area in the 703 domain. However, the intent is clear that the Domain Key 704 Distributor (DKD) is not to replace any Area Key Distributor (AKD). 706 Each key is assumed to be associated with a Key Identifier which 707 uniquely identifies the cryptographic key is question. 709 4. Creation of New Multicast Groups 711 Two possible scenarios with respect to new multicast groups exist. 712 In the first case, the new multicast group is initiated from the 713 current domain. In the second case, the multicast group was 714 initiated from outside the domain and has existed before a host in 715 the current domain joins it. 717 4.1 Initiation of New Internal-Origin Groups 719 When a host ("Initiator") in the current domain wishes to commence a 720 new multicast group, it must first initiate the creation of the 721 multicast group via the underlying multicast routing protocol and 722 some membership protocol (eg. IGMP). 724 If it has not already done so, the initiator host must establish a 725 Security Association (SA) and a shared Member Private-Key (MbrPKey) 726 with its Area Key Distributor (AKD). 728 The commencement of a new multicast group from the perspective of 729 group key management is described as follows, consisting two 730 inseparable parts. The first part is the generation and distribution 731 of the multicast-key, while the second part is the generation and 732 distribution of the Area-Group-Key. 734 Protocol-I: Generation and distribution of the multicast key 736 Step N1: The initiator in an area within the current domain creates 737 a new domain-wide multicast group (method unspecified) with 738 the aid of the Domain Multicast Address Allocation Entity 739 (DMAAE) at the domain level. The DMAAE returns to the 740 initiator the following parameters, digitally signed by the 741 DMAAE: 742 - a multicast group address 743 - a multicast group identity 744 - the identity of the initiator (as group owner) 746 Step N2: The initiator selects the Multicast Group Security 747 Association (MGSA) attributes (without the GSPI). The 748 initiator then authentically notifies its Area Key 749 Distributor (AKD) about the new multicast group and requests 750 a new multicast key for the new multicast group. The message 751 is sent through a secure channel and contains the signed 752 parameters from the DMAAE, the MGSA and an Access Control 753 List (ACL): 754 - the multicast group address 755 - the multicast group identity 756 - the identity of the initiator 757 - the Multicast Group Security Association (MGSA) 758 - the time-period for re-keying cycle 759 - an Access Control List (ACL) generated by the initiator 761 Step N3: The Area Key Distributor (AKD) of the initiator receives 762 the request from the initiator, notifies the Domain Key 763 Distributor (DKD) about the new multicast group and passes 764 the request message to the DKD through a secure channel. 766 Step N4: The Domain Key Distributor (DKD) receives the request and 767 performs the following steps: 769 Step N4.1: The Domain Key Distributor (DKD) verifies the digital 770 signature of the Domain Multicast Address Allocation Entity 771 (DMAAE). 773 Step N4.2: The Domain Key Distributor (DKD) generates: 774 - a Group Security Parameter Index (GSPI) for the MGSA 775 - a Multicast-Key (MKey) 776 - a multicast key identifier MKeyID 777 based on the MGSA selected by the initiator. 779 Step N4.3: The Domain Key Distributor (DKD) digitally-signs the 780 multicast group parameters: 781 - the multicast group address 782 - the multicast group identity 783 - the identity of the initiator 784 - the time-period for re-keying cycle 785 - the Access Control List (ACL) 786 - the Multicast Group Security Association (MGSA) 787 - the Multicast-Key (MKey) 788 - the multicast key identifier MKeyID 789 - a timestamp 791 Step N4.4: The Domain Key Distributor (DKD) securely delivers the 792 signed multicast group parameters to each Area Key 793 Distributor (AKD), either through the All-KD-group (encrypted 794 under the All-KD-Key) or through a one-to-one secure channel 795 to each Area Key Distributor (AKD). This message also serves 796 as an acknowledgment to the Area Key Distributor (AKD) of the 797 initiator. 799 The process of the creation of the All-KD-group is similar to 800 Protocol-I, with the exception that the multicast address is fixed 801 and the DKD selects the Group Security Association (GSA) for the 802 All-KD-group. The DKD also generates the All-KD-Key (AllKDKey) and 803 the All-KD-Key identifier AllKDKeyID for the multicast group, based 804 on the MGSA selected by the DKD. 806 Protocol-II Generation and distribution of the area key 808 Step N5: Upon receiving the signed multicast group parameters from 809 the DKD, the Area Key Distributor (AKD) of the initiator 810 performs the following steps: 812 Step N5.1: The Area Key Distributor (AKD) maps the multicast group 813 address to one of the area control-group addresses. The AKD 814 maintains the following information for the given multicast 815 group: 816 - an area control-group address 817 - an area control-group identity 818 - the identity of the AKD (as group owner) 820 Step N5.2: The Area Key Distributor (AKD) selects the Area Group 821 Security Association (AGSA) attributes and generates: 822 - a Group Security Parameter Index (GSPI) for the AGSA 823 - an Area-Group-Key (AreaGroupKey) 824 - an area key identifier AkeyID 825 based on the AGSA selected by the AKD. 827 Step N5.3: The Area Key Distributor (AKD) digitally-signs the area 828 control-group parameters: 829 - the multicast group address 830 - the multicast group identity 831 - the area control-group address 832 - the area control-group identity 833 - the identity of the AKD 834 - the time-period for re-keying cycle 835 - the Area Group Security Association (AGSA) 836 - the Area-Group-Key (AreaGroupKey) 837 - the area key identifier AKeyID 838 - a timestamp 840 Step N6: The Area Key Distributor (AKD) of the initiator returns to 841 the initiator, through a secure channel: 842 - the multicast group parameters (from Step N4) without the 843 ACL, signed by the AKD 844 - the area control-group parameters (from Step N5) signed by 845 the AKD 847 Step N7: The initiator joins the area control-group (method 848 unspecified). 850 Note that Step N4 above effectively provides each and every Area Key 851 Distributor (AKD) in the domain with the necessary parameters 852 related to the multicast group, regardless of whether or not the 853 area of an AKD actually contains any members of the multicast group. 854 This approach is chosen to allow for quick response by an AKD should 855 other hosts in other areas wish to join the multicast group. In 856 addition, the approach leaves open the possibility of the AKDs to 857 participate in the reliability mechanisms to be employed 858 (ie. as backups), since each of the AKDs holds the 859 parameters related to every multicast group in the domain. 861 The multicast group parameters are digitally signed by Domain Key 862 Distributor (DKD) in order to aid reliability protocols. That is, 863 in the case that the DKD goes down, the parameters can be obtained 864 by one AKD from another AKD through a one-to-one secure channel, 865 with the recipient being able to verify the authenticity of the 866 parameters as signed by the DKD. 868 4.2 Membership to External-Origin Groups 870 Although the current design focuses on intra-domain group key 871 management, it does not preclude the possibility of a multicast 872 group originated by a host external to the domain. However, unlike 873 multicast groups which originate from a host within the domain and 874 which is therefore known to the Domain Key Distributor (DKD), 875 multicast groups which originate from outside a domain must be 876 explicitly made known to the DKD. 878 Since the current protocol views the multicast distribution tree 879 used by a multicast routing protocol as a construct outside its 880 control, the Domain Key Distributor (DKD) can be notified (when a 881 host in domain joins the external-origin multicast group) through a 882 number of ways, among others: 883 - The joining host can explicitly notify its Area Key Distributor 884 (AKD) or the Domain Key Distributor (DKD). 886 - A domain border-router can notify the Domain Key Distributor 887 (DKD) when it senses a request from a host to join the 888 distribution tree 889 - The Domain Key Distributor (DKD) can by default be a member of 890 all external-origin multicast groups whose distribution tree 891 extend into the domain. 893 However, from the perspective of group key management, the Domain 894 Key Distributor (DKD) only plays a role when the external-origin 895 multicast traffic is enciphered for access control and the owner of 896 the group requires the aid of the DKD to enforce access control. 897 Hence, in this situation the DKD must obtain a copy of the key used 898 to encipher the multicast traffic as it enters the domain and assign 899 a new multicast key for that same traffic within its domain (method 900 unspecified). 902 The current document leaves the precise description and 903 specification of the group key management for external-origin 904 multicast groups to a later date. 906 5. Re-Keying Approach 908 The basic approach to re-keying is discussed first 909 in order to simplify later discussions on re-keying 910 due to membership changes and due to periodic re-keying. For 911 simplicity, the process is view from the perspective of the Domain 912 Key Distributor (DKD) and one Area Key Distributor (AKD). 914 It is the DKD who initiates and controls all re-keying events in the 915 domain related to multicast groups. Re-keying of Area-Group-Keys of 916 area control-groups are initiated and controlled by the respective 917 Area Key Distributors (AKD). 919 Note that it is important to have "cycle-over" period in which all 920 host-members are in possession of the new re-key parameters, but is 921 still employing the existing/old parameters. 923 5.1 Re-Keying of Multicast Keys 925 In the following, all re-key steps are related to a given multicast 926 group. The protocol is initiated and controlled by the Domain Key 927 Distributor (DKD). 929 Protocol-III: Re-keying the multicast key 931 Step RM1: The Domain Key Distributor (DKD) issues an authentic 932 prepare-to-rekey message to all Area Key Distributors (AKD) 933 through the All-KD-group. The message contains: 934 - an existing multicast group address 935 - a existing multicast group identity 936 of the multicast group being re-keyed 938 Step RM2: The Domain Key Distributor (DKD) generates: 939 - a new Group Security Parameter Index (GSPI) for the MGSA 940 - a new Multicast-Key (MKey) 941 - a new multicast key identifier MKeyID 942 based on the MGSA selected by the initiator. 944 Step RM3: The Domain Key Distributor (DKD) digitally-signs the 945 multicast group parameters: 946 - the existing multicast group address 947 - the existing multicast group identity 948 - the Multicast Group Security Association (MGSA) 949 - the new Multicast-Key (MKey) 950 - the new multicast key identifier MKeyID 951 - a timestamp 953 Step RM4: The Domain Key Distributor (DKD) securely delivers the 954 signed parameters to each Area Key Distributor (AKD), either 955 through the All-KD-group (encrypted under the All-KD-Key) or 956 through a one-to-one secure channel to each Area Key 957 Distributor (AKD). 959 Step RM5: The Area Key Distributor (AKD) securely delivers the 960 signed multicast group parameters to each host-member (of the 961 multicast group) in its area using one of the following 962 methods (depending on the cause of the re-keying event): 963 (a) through the area control-group related to the multicast 964 group (encrypted under the AreaGroupKey) 965 (b) through a one-to-one secure channel to each concerned 966 host-member. 968 5.2 Re-Keying of Area Keys 970 In the following, all re-key steps by the Area Key Distributor (AKD) 971 are related to a given multicast group. The protocol is initiated 972 and controlled by the Area Key Distributor (AKD). 974 Protocol-IV: Re-keying the area key 976 Step RA1: The Area Key Distributor (AKD) issues an authentic 977 prepare-to-rekey message to all members of the multicast 978 group within the area through the relevant area control- 979 group. The message contains: 980 - an existing area control-group address 981 - an existing area control-group identity 982 of the area control-group being re-keyed 984 Step RA2: The Area Key Distributor (AKD) generates: 985 - a new Group Security Parameter Index (GSPI) for the AGSA 986 - a new Area-Group-Key (AreaGroupKey) 987 - a new area key identifier AkeyID 988 based on the AGSA selected by the AKD. 990 Step RA3: The Area Key Distributor (AKD) digitally-signs the area 991 control-group parameters: 992 - the existing area control-group address 993 - the existing area control-group identity 994 - the Area Group Security Association (AGSA) 995 - the new Area-Group-Key (AreaGroupKey) 996 - the new area key identifier AKeyID 997 - a timestamp 999 Step RA4: The Area Key Distributor (AKD) securely delivers the 1000 signed control-group parameters to each host-member (of the 1001 multicast group) in its area, using one of the following 1002 methods (depending on the cause of the re-keying event): 1003 (a) through the area control-group related to the multicast 1004 group (encrypted under the old/current AreaGroupKey) 1005 (b) through a one-to-one secure channel to each concerned 1006 host-member. 1008 5.3 Re-Keying of the All-KD-Key 1010 The following describes the protocol to be employed when the All-KD- 1011 Key (AllKDKey) is to be re-keyed. All the Area Key Distributors 1012 (AKDs) and the Domain Key Distributor (DKD) share an All-KD-Key. 1013 This key is used to encrypt traffic within the All-KD-group. Note, 1014 that unlike host-members, Key Distributors never leave the All-KD- 1015 group, and hence its membership is static. 1017 Protocol-V: Re-keying the All-KD-Key 1019 Step RK1: The Domain Key Distributor (DKD) issues an authentic 1020 prepare-to-rekey message to all Area Key Distributors (AKD) 1021 through the All-KD-group. The message contains: 1022 - the existing All-KD-group address 1023 - the existing All-KD-group identity 1025 Step RK2: The Domain Key Distributor (DKD) generates: 1026 - a new Group Security Parameter Index (GSPI) for the MGSA 1027 - a new All-KD-Key (AllKDKey) 1028 - a new All-KD-Key identifier AllKDKeyID 1029 based on the MGSA selected by the DKD 1031 Step RK3: The Domain Key Distributor (DKD) digitally-signs the All- 1032 KD-group parameters: 1033 - the existing multicast group address 1034 - the existing multicast group identity 1035 - the Multicast Group Security Association (MGSA) 1036 - the new All-KD-Key (AllKDKey) 1037 - the new All-KD-Key identifier (AllKDKeyID) 1038 - a timestamp 1040 Step RK4: The Domain Key Distributor (DKD) securely delivers the 1041 signed All-KD-group parameters to each Area Key Distributor 1042 (AKD) using one of the following methods, depending on the 1043 status of the AKD and the network condition: 1044 (a) through the All-KD-group (encrypted under the 1045 existing/old All-KD-Key) 1046 (b) through a one-to-one secure channel to each Area Key 1047 Distributor (AKD). 1049 6. Hosts Joining a Multicast Group 1051 When a host within a domain wishes to join a multicast group having 1052 already (at least) a member in the domain, the two possible 1053 approaches can be adopted in admitting the host to become a group 1054 member. In the first case, the host is disallowed from accessing 1055 (reading) traffic previous to its joining the group. In the second 1056 case, no such access restriction apply. The choice between the two 1057 approaches is dictated by policy, and hence beyond the scope of 1058 the current document. 1060 In the following, the strict re-keying policy is adopted, in which a 1061 re-keying of the Multicast-Key and the re-keying of the AreaGroupKey 1062 (of the area within which the new host joins) is conducted 1063 immediately. In the loose re-keying policy, the task is postponed 1064 until the next periodic re-keying, at which point the new member is 1065 able access (decipher) the data of the multicast group. 1067 In the following, it is assumed that when a host in an area (first 1068 member or otherwise) joins a multicast group the Area Key 1069 Distributor (AKD) has already created the necessary area control- 1070 groups in its area. To conserve resources, an AKD may postpone the 1071 control-group creation (corresponding to a given multicast group) 1072 until such time that a first member of the multicast group appears 1073 in its area. 1075 6.1 Joining with Backward Confidentiality 1077 When a new host joining a multicast group is to be prevented from 1078 accessing (reading) previous traffic (which it may have intercepted 1079 and stored), then Multicast-Key (MKey) of the multicast group in the 1080 domain must be re-keyed each time a host joins the multicast group. 1082 Note that even when a host is the first member of a multicast group 1083 in its area, all the other areas having a member must be re-keyed to 1084 reduce the possibility of that new host having access to previous 1085 traffic which it obtained (intercepted) in other areas. 1087 Protocol-VI: Host joining with backward confidentiality 1089 Step JB1: The host sends an authentic join-request message for the 1090 multicast group to its Area Key Distributor (AKD). 1092 Step JB2: The Area Key Distributor (AKD) checks the host against the 1093 Access Control List (ACL) of the multicast group. If the 1094 host is permitted to join, then the Area Key Distributor 1095 (AKD) authentically notifies the Domain Key Distributor (DKD) 1096 and the other Area Key Distributors (AKD) of the membership 1097 change (new host-member). Otherwise, the AKD returns a join- 1098 reject message to the host 1100 Step JB3: The Domain Key Distributor (DKD) initiates an immediate 1101 re-keying (Protocol-III: Re-keying the multicast key). This 1102 results in all Area Key Distributor (AKD) and all existing 1103 members of the multicast group obtaining the following 1104 multicast group parameters: 1105 - the existing multicast group address 1106 - the existing multicast group identity 1107 - the Multicast Group Security Association (MGSA) 1108 - the new Multicast-Key (MKey) 1109 - the new multicast key identifier MKeyID 1110 - a timestamp 1112 Step JB4: The Area Key Distributor (AKD) of the area (within which 1113 the host resides) must re-key its Area-Group-Key, and thus 1114 generates: 1115 - a new Group Security Parameter Index (GSPI) for the AGSA 1116 - a new Area-Group-Key (AreaGroupKey) 1117 - a new area key identifier AkeyID 1118 based on the AGSA selected by the AKD. 1120 Step JB5: The Area Key Distributor (AKD) digitally signs the area 1121 control-group parameters: 1122 - the existing area control-group address 1123 - the existing area control-group identity 1124 - the Multicast Group Security Association (MGSA) 1125 - the new Area-Group-Key (AreaGroupKey) 1126 - the new area key identifier AKeyID 1127 - a timestamp 1129 Step JB6: If there are existing host-members in the area, the Area 1130 Key Distributor (AKD) securely delivers the signed control- 1131 group parameters to each existing host-member (of the 1132 multicast group) in its area, using one of the following 1133 methods: 1134 (a) through the area control-group related to the multicast 1135 group (encrypted under the old/current AreaGroupKey) 1136 (b) through a one-to-one secure channel to each existing 1137 host-member. 1139 Step JB7: The Area Key Distributor (AKD) of the new host-member 1140 securely delivers the signed multicast group parameters (from 1141 Step JB3) and the signed control-group parameters (from Step 1142 JB5) to the new host-member through a one-to-one secure 1143 channel to the new host-member. 1145 Step JB8: The new host joins the multicast group (method 1146 unspecified). 1148 Step JB9: The new host joins the area control-group (method 1149 unspecified). 1151 6.2 Joining Without Backward Confidentiality 1153 Here, when a host joins a multicast group, the Multicast-Key need 1154 not be re-keyed since backward confidentiality is not required. The 1155 Area Key Distributor (AKD) of the host is already in possession of 1156 all the parameters related to the multicast group. 1158 Protocol-VII: Host joining without backward confidentiality 1160 Step JW1: The host sends an authentic join-request message for the 1161 multicast group to its Area Key Distributor (AKD). 1163 Step JW2: The Area Key Distributor (AKD) checks the host against the 1164 Access Control List (ACL) of the multicast group. If the 1165 host is permitted to join, then the Area Key Distributor 1166 (AKD) proceeds with the next step, otherwise it returns a 1167 join-reject message to the host. 1169 Step JW3: The Area Key Distributor (AKD) looks-up the following 1170 multicast group parameters which it previously digitally- 1171 signed: 1172 - the existing multicast group address 1173 - the existing multicast group identity 1174 - the Multicast Group Security Association (MGSA) 1175 - the new Multicast-Key (MKey) 1176 - the new multicast key identifier MKeyID 1177 - a timestamp 1179 Step JW4: The Area Key Distributor (AKD) looks-up the following 1180 control-group parameters which it previously digitally- 1181 signed: 1182 - the existing area control-group address 1183 - the existing area control-group identity 1184 - the Multicast Group Security Association (MGSA) 1185 - the existing Area-Group-Key (AreaGroupKey) 1186 - the existing area key identifier AKeyID 1187 - a timestamp 1189 Step JW5: The Area Key Distributor (AKD) of the new host-member 1190 securely delivers the signed multicast group parameters (from 1191 Step JW3) and the signed control-group parameters (from Step 1192 JW4) to the new host-member through a one-to-one secure 1193 channel to the new host-member. 1195 Step JW6: The new host joins the multicast group (method 1196 unspecified). 1198 Step JW7: The new host joins the area control-group (method 1199 unspecified). 1201 7. Host Leaving a Multicast Group 1203 The case of a host leaving a multicast group can be caused by a 1204 number of reasons depending on the policy dictating group membership 1205 and on the multicast application in question. 1207 From the perspective of the current design, re-keying must be 1208 conducted to preserve forward confidentiality. That is, re-keying 1209 must be conducted to prevent the ex-member from further accessing 1210 (deciphering) the data in the multicast group, even if the ex-member 1211 persists in being a part of the multicast distribution tree. 1213 In the following, the strict re-keying policy is adopted, in which a 1214 re-keying of the Multicast-Key and the re-keying of the Area-Group- 1215 Key (AreaGroupKey) of the area within which the new host joins are 1216 conducted immediately. In the loose re-keying policy, the task is 1217 postponed until the next periodic re-keying, at which point the ex- 1218 member ceases to be able to decipher traffic in the multicast group 1219 and its corresponding control-group in the area. 1221 Note that in the current design, when a host leaves a 1222 multicast group it must also (by default) depart from the associated 1223 control-group. In general, it makes no sense for a host to join a 1224 control-group without joining the corresponding multicast group. 1226 Protocol VIII: Host leaving a multicast group and control-group 1228 Step LB1: The leaving-host sends an authentic leave-request message 1229 for the multicast group to its Area Key Distributor (AKD). 1230 Alternatively, the Domain Key Distributor (DKD) notifies the 1231 AKD through an authentic eject-host-request message to the 1232 AKD. 1234 Step LB2: The Domain Key Distributor (DKD) of the affected area 1235 authentically notifies the other Area Key Distributors (AKD) 1236 of the membership change (host-member leaving). 1238 Step LB3: The Domain Key Distributor (DKD) initiates an immediate 1239 re-keying (Protocol-III: Re-keying the multicast key). This 1240 results in all Area Key Distributors (AKDs) and all host- 1241 members of the multicast group, except host-members in the 1242 affected area, obtaining the following multicast group 1243 parameters: 1244 - the existing multicast group address 1245 - the existing multicast group identity 1246 - the Multicast Group Security Association (MGSA) 1247 - the new Multicast-Key (MKey) 1248 - the new multicast key identifier MKeyID 1249 - a timestamp 1251 Step LB4: The Area Key Distributor (AKD) of the affected area 1252 (within which the leaving-host resides) must re-key its Area- 1253 Group-Key, and thus generates: 1254 - a new Group Security Parameter Index (GSPI) for the AGSA 1255 - a new Area-Group-Key (AreaGroupKey) 1256 - a new area key identifier AkeyID 1257 based on the AGSA selected by the AKD. 1259 Step LB5: The Area Key Distributor (AKD) digitally signs the area 1260 control-group parameters: 1261 - the existing area control-group address 1262 - the existing area control-group identity 1263 - the Multicast Group Security Association (MGSA) 1264 - the new Area-Group-Key (AreaGroupKey) 1265 - the new area key identifier AKeyID 1266 - a timestamp 1267 and digitally-signs the multicast group parameters that the 1268 AKD received from the DKD in Step LB3: 1269 - the existing multicast group address 1270 - the existing multicast group identity 1271 - the Multicast Group Security Association (MGSA) 1272 - the new Multicast-Key (MKey) 1273 - the new multicast key identifier MKeyID 1274 - a timestamp 1276 Step LB6: The Area Key Distributor (AKD) securely delivers the 1277 signed multicast group parameters and control-group 1278 parameters to each remaining host-member (of the multicast 1279 group) in its area, through a one-to-one secure channel to 1280 each existing host-member. 1282 Step LB7: The leaving-host leaves the multicast group (method 1283 unspecified). 1285 Step LB8: The leaving-host leaves the area control-group (method 1286 unspecified). 1288 8. Reliability in Key Management 1290 The current document recognizes that key management be conducted 1291 in a reliable manner, due to the sensitivity of cryptographic keys 1292 and the basic necessity that a host-member obtain the multicast key 1293 before it can access (decipher) the multicast data. Reliability is 1294 also important in the re-keying of the keys used in the multicast 1295 group and in the area control-groups. This is true particularly if 1296 in the re-keying process, the control-group itself is used to 1297 transmit the new parameters (for either the multicast group or the 1298 same control-group) to the members of the group. 1300 However, the current document views reliability of transmission, 1301 particularly in the control-groups, as more of a multicast- 1302 reliability issue. That is, reliability should not be expected from 1303 and should not be part of key management. This is also true for the 1304 one-to-one "secure channels", in which confidential and authentic 1305 communications is created between a sender and a receiver through 1306 the previously-established Security Association (SA) and the shared 1307 private-key. 1309 Note that in the re-keying of a Multicast-Key (MKey), it is 1310 important that each Area Key Distributor (AKD) first reliably 1311 obtains the new parameters (including the new key) of the multicast 1312 group. This is because without the new parameters, the AKD will not 1313 be able to even begin to re-key its area. Once each AKD obtains the 1314 new parameters of the multicast group, the re-key of the Multicast- 1315 Key in each area is independent of one another. 1317 The current work currently does not specify how or what 1318 manner reliability in key management is to be achieved. However, 1319 when a control-group (either the All-KD-group or an area control- 1320 group) is used for key management from a sender to a number of 1321 recipients (eg. delivery of new key and new parameters) several 1322 basic approaches can be used: 1324 (a) ACKs from members 1326 When a control-group is used to transmit re-keying parameters, the 1327 recipients simply return an acknowledgment (ACK) to the Key 1328 Distributor through the secure channel previously established with 1329 the Key Distributor. Should the Key Distributor fail to receive 1330 such an ACK from a recipient within specified time, it will then 1331 query the recipient through the secure channel previously 1332 established. Depending on the frequency of key management and the 1333 number of host-members, this approach may cause an ACK-implosion on 1334 the AKDs. 1336 (b) Timeouts 1338 When some period after a prepare-to-rekey message is received, some 1339 recipients fail to receive the actual new key and parameters through 1340 the control-group, those recipients query the sender (AKD or DKD). 1342 When nothing is heard after both the due time for the prepare-to- 1343 rekey message and due time for the actual key/parameters to be 1344 received, the recipients query the sender (AKD or DKD). 1346 (c) Explicit Reliable Multicast (RM) protocol 1348 Employ a specific RM protocol to establish reliability within the 1349 All-KD-group and/or the area control-groups. Each control-group can 1350 in fact employ different RM protocols. 1352 10. References 1354 [HCD00] T. Hardjono, B. Cain and N. Doraswamy, "A Framework for 1355 Group Key Management for Multicast Security", Internet Draft, 1356 August 2000. 1358 [HC98] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", 1359 Internet Draft, June 1998. 1361 [WGL98] C. K. Wong, M. Gouda and S. Lam, "Secure Group 1362 Communications Using Key Graphs", in Proceedings of SIGCOMM'98. 1364 [KA98a] S. Kent and R. Atkinson, "Security Architecture for the 1365 Internet Protocol", IETF, RFC 1825, 1998. 1367 [KA98b] S. Kent and R. Atkinson, "IP Encapsulating Security Payload 1368 (ESP)", Internet Draft, July 1998. 1370 [KA98c] S. Kent and R. Atkinson, "IP Authentication Header", 1371 Internet Draft, July 1998. 1373 [Mey98] D. Meyer, "Administratively Scoped IP Multicast", IETF, RFC 1374 2365, July 1998. 1376 [HTE98] M. Handley, D. Thaler, and D. Estrin, "The Internet 1377 Multicast Address Allocation Architecture", Internet Draft, June 1378 1998. 1380 11. Author Addresses 1382 Thomas Hardjono 1383 Nortel Networks 1384 600 Tech Park Drive 1385 Billerica, MA 01821, USA 1386 Email: thardjono@baynetworks.com 1388 Brad Cain 1389 Mirror Image 1390 49 Dragon Court 1391 Woburn, MA 01801 1392 Email: brad.cain@mirror-image.com 1394 Inder Monga 1395 Nortel Networks 1396 600 Tech Park Drive 1397 Billerica, MA 01821, USA 1398 Email: imonga@baynetworks.com 1400 --------------------------------------------------------------------