idnits 2.17.00 (12 Aug 2021) /tmp/idnits19186/draft-irtf-smug-gkmbb-gsadef-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 73 has weird spacing: '...the PIs imple...' == Line 469 has weird spacing: '.... This struc...' == Line 476 has weird spacing: '...mber to pull ...' == Line 478 has weird spacing: '...r being disco...' == Line 479 has weird spacing: '...as been turne...' == (4 more instances...) -- 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 (March 2001) is 7730 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'FS00' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'HCD00' is defined on line 751, but no explicit reference was found in the text == Unused Reference: 'RFC2407' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'WL98' is defined on line 801, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BF99' -- Possible downref: Non-RFC (?) normative reference: ref. 'BMS99' -- Possible downref: Non-RFC (?) normative reference: ref. 'BR93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bris99' -- Possible downref: Non-RFC (?) normative reference: ref. 'CP99' -- Possible downref: Non-RFC (?) normative reference: ref. 'DVW92' -- Possible downref: Non-RFC (?) normative reference: ref. 'FS00' -- Possible downref: Non-RFC (?) normative reference: ref. 'HCBD00' -- Possible downref: Non-RFC (?) normative reference: ref. 'HCD00' -- No information found for draft-harney-msmp-sec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HH99a' -- Possible downref: Non-RFC (?) normative reference: ref. 'HH99b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kraw96' ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Downref: Normative reference to an Experimental RFC: RFC 2093 ** Downref: Normative reference to an Experimental RFC: RFC 2094 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 ** Downref: Normative reference to an Experimental RFC: RFC 2522 ** Downref: Normative reference to an Informational RFC: RFC 2627 -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS88' -- Possible downref: Non-RFC (?) normative reference: ref. 'WL98' Summary: 17 errors (**), 0 flaws (~~), 12 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Research Task Force Hugh Harney (SPARTA) 2 INTERNET-DRAFT Mark Baugher (PassEdge) 3 September 2000 Thomas Hardjono (Nortel) 4 Expires March 2001 6 GKM Building Block: Group Security Association (GSA) Definition 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 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document provides a definition for Group Security Associations 34 (GSA) for the support of group key management in IP multicast security. 35 The reasoning behind the structure of the GSA is discussed, and a 36 definition of the GSA is provided. 38 1. Introduction 40 This document describes a Group Key Management Building Block (GKM-BB) 41 following the Secure IP Multicast Framework and Building Blocks document 42 [HCBD00]. In particular, the current document answers the need for 43 further definition of the multicast key management building block 44 [HCBD00]. The GKM-BB and its relationship with the other building 45 blocks is shown in Figure 1. 47 +------------------------------------------------------------+ 48 | Secure IP Multicast: | 49 | Framework, and Building Blocks | 50 | | 51 | /|\ | 52 | / | \ | 53 | / | \ | 54 | |------------ / | \------------| | 55 | | | | | 56 | | | | | 57 | | | | | 58 | | | | | 59 | Secure Group Secure | 60 | Multicast Key Multicast | 61 | Data Handling Management Policy | 62 | Building Block Building Block Building Block | 63 | (Problem Area 1) (Problem Area 2) (Problem Area 3) | 64 | | 65 +------------------------------------------------------------+ 66 Figure 1: Building blocks defined for Secure IP multicast 68 1.1 Group Key Management Building Block and Protocol Instantiations 70 Within the context of group key management for IP multicast security, 71 the current document seeks to provide the framework for group key 72 management Protocol Instantiations (PI). Following the concept of 73 building blocks in [HCBD00], the PIs implement group key management at 74 various layers of the protocol stack, answering the need of various 75 applications. The relationship between the group key management 76 framework and the PIs is shown in Figure 2. 78 1.2 Aim of the GKM Building Block 80 The aim of the current document is to define a GKM Building Block (GKM- 81 BB) for the establishment of a Group Security Association (GSA) and 82 Group-Key establishment. The notion of a GSA is described in Section 2. 84 A protocol that can establish and maintain GSAs provides a framework for 85 the design of group key management Protocol Instantiations. 87 To this end, the current document seeks to: 89 - Identify the entities involved, and define the functions to be 90 carried-out by these entities. 92 - Define the concepts and behaviors and explain their motivations. 94 - Define the constructs in the form of data items exchanged between any 95 two entities involved in the GKM-BB in sufficient detail so as to 96 enable different Protocol Instantiations (PI) to be developed from 97 them. 99 Above all, the current effort aims to define, develop and evolve the 100 GKM-BB in a manner that conforms to the original intent of the Building- 101 Blocks approach adopted in [HCBD00]. This includes the reuse of 102 existing technology and the introduction of newer technologies to 103 satisfy the requirements of Group Key Management, provide timely 104 delivery of technology through standardization of the GKM-BB, and to 105 validate the practical usefulness of the Building Block for a variety of 106 applications. 108 +---------------------------------------------------------+ 109 | | 110 | Group Key Management | 111 | Building Block | 112 | (GKM-BB) | 113 | /|\ | 114 | / | \ | 115 | / | \ | 116 | / | \ | 117 | / | \ | 118 | / | \ | 119 | / | \ | 120 | / | \ | 121 | GKM GKM | 122 | Protocol Protocol | 123 | Instantiation-1 Instantiation-n | 124 | (GKM-PI 1) . . . (GKM-PI n) | 125 | | 126 +---------------------------------------------------------+ 127 Figure 2: Relationship between the GKM-BB and GKM-PI 129 1.3 Elements of the Secure IP Multicast Framework 131 The Secure IP Multicast Framework and Building Blocks document [HCBD00] 132 describes a number of entities, which participate in the creation, 133 maintenance, and removal of secure multicast groups. Those that are 134 immediately of concern for group key management and membership 135 management are as follows. 137 1.3.1 Entities and functions 139 Group Controller and Key Server (GCKS) 140 The GCKS entity embodies both the physical entity and functions of 141 the group controller and the key server. Although two families of 142 functions can be distinguished, namely membership management and 143 group key management, for simplicity both families of functions 144 will be provided by a single physical entity. For any given 145 multicast group, a "Main" or "Root" GCKS must be identified using 146 methods and mechanisms related to a group's initial 147 definition/configuration. 149 Member (Receiver and Sender) 150 The member is the group member, defined for a particular instance 151 of group communications. The member entity can exist at different 152 layers (eg. user, host, process) and thus must be defined across 153 the group consistently and is best expressed through their 154 corresponding certificates. 156 Although not directly addressed in the current document, another entity 157 that is involved in group key management is the Remote GCKS. The Remote 158 GCKS expresses the scalability and inter-domain requirements of group 159 key management. A Remote GCKS is identical in functionality to the GCKS. 160 However, in terms of authorization level to perform the management of 161 group keys, a GCKS may possess a different relationship to another GCKS 162 within the same management regime. Examples include a peer relationship 163 among a set of GCKS, and a hierarchical relationship where a Root GCKS 164 is defined and the other GCKS are subordinates of the Root. 166 2. GROUP KEY MANAGEMENT REQUIREMENTS AND PROPERTIES 168 The requirements discussed in this section are for the most part not 169 original but come from a variety of sources. The Internet key 170 management literature is one source. Group key management must operate 171 over packet internetworks, particularly IP multicast internets. Thus 172 group key management has at least some of the properties of Internet key 173 management. Indeed, the very notion of "key management," as distinct 174 from "key exchange," is taken from work done on IPSec. Thus, the 175 Internet key management requirements presented in this memo are gleaned 176 from prior work done on IP security, key management for packet networks, 177 and authenticated key exchange [RFC2409, RFC2412, RFC2408, RFC2407, 178 RFC2522, Kraw96, SDNS88, DVW92]. Our second source of requirements is 179 taken from previous work on multicast security [RFC2627, CP99, HH99a, 180 HCD00]. 182 Group key management requires additional properties beyond those found 183 in the Internet key management work done to date. Group keying 184 material, for example, are not negotiated but sent to and shared by 185 groups of members, which must agree to common policies that are not 186 negotiated [CP99, HH99a]. Furthermore, the key exchange/distribution 187 architecture is not only peer-to-peer but also operates between key 188 server and key client [HCBD00]. The common and distinct properties of 189 Internet key management and group key management are the subject of this 190 section. 192 Section 2.2 discusses group key management. Section 2.1 is an overview 193 of internet key management and its applicability to group key 194 management. In both sections we consider the needed properties of a 195 group key management protocol. 197 2.1 Internet Key Management and Key Determination 199 "Authenticated key exchange" is basic to internet key management and key 200 determination protocols, which seek to thwart attacks that may occur on 201 an unsecured network. The types of attacks include man-in-the-middle, 202 connection-hijacking, and reflection/replay attacks, many of which can 203 be combated by mechanisms such as "direct authentication," which 204 integrate authentication into the key exchange, as described in the STS 205 protocol [DVW92]. Messages that are exchanged as part of a "run" should 206 be chained with authenticatable information, including random data that 207 is contributed by each party in a two-party key exchange. This 208 technique helps ensure that messages received by a peer match what the 209 other peer sent. Work has been done, moreover, to formally prove AKE 210 properties based upon the matching of messages sent and received by 211 peers in the exchange [BR93]. When session keys are used to protect 212 exchanges that determine other session keys, "perfect forward secrecy" 213 (PFS) can ensure that "...disclosure of long-term secret keying material 214 does not compromise the secrecy of the exchanged keys from earlier runs" 215 - so long as authentication is linked to the key exchange [DVW92]. The 216 PFS requirement, however, entails the performance penalty of a Diffie- 217 Hellman exchange, which may not be appropriate for all applications. 219 The notion of a "selectable level of security" is basic to key 220 management on internetworks, which are composed of diverse 221 communications networks and host computers. In this environment, some 222 applications may tradeoff better security for reduced communications and 223 computing costs. The security choices depend upon application need as 224 well as the capabilities of the hosts and network devices. In order to 225 support heterogeneous network and host devices, Internet key management 226 supports multiple types of exchanges that can be composed in various 227 ways; some exchanges may support identity protection and provide PFS, 228 for example, while others may not [Kraw96]. To accommodate diversity, a 229 versatile approach supports a variety of transforms and Diffie-Hellman 230 groups, all of which can be negotiated among communicating entities 231 [RFC2412, RFC2409]. Internet key management, moreover, supports a 232 "forward migration path" in the protocol so that new algorithms can be 233 introduced, as older methods need to be replaced [RFC2409, RFC2412, 234 RFC2408, Kraw96]. 236 In fact, the key establishment procedure itself may need to be replaced 237 over time, and the Internet Security Architecture has a key management 238 framework, the Internet Security Association and Key Management Protocol 239 (ISAKMP), which defines an abstract set of exchanges, organized by 240 "modes" and "phases" to provide a selectable level of protection 241 [RFC2408, Kraw96]. To provide a versatile solution for internet key 242 management, ISAKMP permits alternative authentication mechanisms in its 243 exchanges and is parameterized by a "domain of interpretation" (DOI) in 244 which specific key determination mechanisms are defined through the 245 specification of the name space, policy, specific payloads and, 246 optionally, new exchanges. In this way, ISAKMP is designed to be 247 extended for alternative uses and to allow a forward migration of key 248 exchange protocols and cryptographic transforms. Although the 249 flexibility of their approach may arguably result in more complexity, 250 which may in turn lead to weaker security [Ferguson & Schneier], the 251 ISAKMP authors recommend the use of ISAKMP as a single key management 252 framework for new uses such as group key management, as well as 253 transport and application key management [RFC2408]. New uses can be 254 realized through the specification of a DOI. 256 ISAKMP achieves its versatility by being more abstract than a key 257 determination protocol since it manages "security associations" (SA) and 258 not just keys. The SA abstraction [RFC2408, RFC2401, RFC2522, SDNS88] 259 encapsulates keys and information about keys, such as key lifetimes and 260 cryptographic policies, so as to allow all significant aspects of the 261 security to be modified to the needs of the application and environment. 262 In the current Internet Security Architecture, however, SA management is 263 peer to peer as depicted in the Figure 1. 265 +------------------------------------------------------------+ 266 | | 267 | +---------------+ +--------------+ | 268 | | Peer | | Peer | | 269 | | (Intiator) | | (Responder) | | 270 | | SA--------------------SA | | 271 | +---------------+ +--------------+ | 272 | | 273 +------------------------------------------------------------+ 274 Figure 3: A Security Association between two Internet computers 276 The SA is defined to be simplex in the Internet Security Architecture 277 [RFC2401] and is identified by a Security Parameter Index (SPI) 278 [RFC2401, RFC2522]. SAs are established according to local policy 279 [RFC2401, SDNS88] using exchanges that are designed to protect against 280 basic key establishment attacks, such as man in the middle, connection 281 hijacking, replay/reflection, and denial of service [RFC2408]. Although 282 the first three types of attacks are the subject of authenticated key 283 exchange mechanisms, protection against the denial-of-service attack 284 uses a pairwise cookie mechanism [RFC2522] between peer entities, which 285 appears used in the ISAKMP header for all exchanges [RFC2408, RFC2409]. 287 Since we assume that group key management must operate across diverse 288 internetworks, particularly IP multicast networks, then at least some of 289 the properties of Internet key management are required for group key 290 management. These properties, broadly stated, are summarized in the 291 points below. 293 1. Protection against man-in-the-middle, connection-hijacking, 294 replay/reflection, and denial-of-service attacks. 295 2. Selectable level of security protection in key establishment, 296 such as alternative transforms, optional PFS and identity 297 protection to support heterogeneous internet applications and 298 computers. 299 3. Alternative authentication mechanisms such as shared key, PKI, 300 and public key to support diverse trust models. 301 4. Forward migration path for new security mechanisms such as new 302 cryptographic transforms and even new exchanges. 303 5. A single key management framework to support the establishment 304 of Security Associations according to the local policies of 305 internet host and intermediate systems. 307 We assume that these properties should be properties of group key 308 management as well. As discussed in section 2.2, group key management 309 has additional needs beyond the five points summarized here. 311 2.2 Group Key Management 313 From the previous section, it is clear that many of the requirements and 314 design features of Internet key management are needed by group key 315 management. In fact, many of the payloads, exchanges, and transforms 316 found in ISAKMP and IKE may be suitable for group key management: Many 317 group key management protocols and algorithms, moreover, such as GKMP, 318 LKH, OFT, GSAKMP, NARK and MARKS assume a unique key for a member, which 319 is established using point-to-point procedures with a key server 320 [RFC2093, RFC2094, RFC2627, BMS99, HH99b, BF99, Bris99]. For the 321 purposes of authenticating a potential group member and initializing it 322 with keys, group-keying material must be "pulled" by an individual 323 client from the server. Group members whose computers are off-line 324 during key updates also must pull keying material to be re-initialized 325 (or to request re-initialization by the GCKS) in a secure, probably 326 point-to-point protocol. Use of IKE, unchanged with the IPSec DOI, 327 however, is out of the question owing to the need to support key 328 distribution in addition to exchange (i.e., an external key is given to 329 the member by the GCKS), the need for policy distribution rather than 330 policy negotiation, and the use of multicast communications to push key 331 updates to promulgate key changes needed to refresh keys that reach the 332 end of their cryptographic lifetime and to replace keys resulting from 333 changes in group membership. Several algorithms have been proposed to 334 efficiently accomplish group re-key and maintenance [RFC2627, BMS99, 335 HH99b, Bris99]. A versatile group key management building block will 336 support a variety of alternative algorithms to offer a forward migration 337 path when new algorithms are developed or flaws in existing algorithms 338 are uncovered. 340 The use of a multicast service to "push" key updates and other control 341 messages from the GCKS to members relieves the GCKS of the burden of 342 contacting each member individually to change the key or the 343 configuration of the group [CP99, HH99a, RFC2627, BMS99, HH99b]. In 344 this way, group key management can scale to very large numbers of 345 members. This ability to deploy multicast itself for group key 346 management is attractive for a variety of applications. This property 347 may be superfluous for pure "pay-per-view" sessions where the member is 348 keyed once and never again for duration of the session. But for 349 "subscription" sessions or sessions where keys must be changed, a good 350 multicast application design principles will protect the GCKS from being 351 the target of periodic, and possibly synchronized, requests from large 352 numbers of members attempting to pull keys. 354 Unlike large-scale subscription groups, short-lived, dynamic groups, 355 which are characterized by relatively small numbers of members, may need 356 group key management to minimize the time it takes to create and add 357 members to a group. Thus, group key management must be able to 358 efficiently maintain very large, secure groups, to support large numbers 359 of members, while not precluding fast initialization, maintenance, and 360 destruction for smaller groups that engage in impromptu group 361 communications [CP99, RFC2627, HH99b]. The need to support a range of 362 performance and scalability needs for diverse applications is very much 363 a goal of Internet key management that is shared by group key 364 management. 366 It is clear, however, that the security associations for group key 367 management are more complex, or at least more numerous, than for 368 Internet key management. Whereas the latter establishes a key 369 management SA to protect application SAs (where a minimum of two are 370 needed to key an Internet application process), group key management 371 requires at least three: There is a "pull" SA between the group member 372 and the GCKS, a "push" SA between the GCKS and all the group members, 373 and an SA to protect application data from sender-members to receiver- 374 members. In fact, each sender to the group may use a unique key for 375 their data and use a separate SA: there may be more SAs than there are 376 group senders. 378 Group key management, therefore, uses a different set of abstractions 379 than ISAKMP and IKE. The abstractions used in our Group Key Management 380 Building Block (GKM-BB), however, may be built from the ISAKMP 381 abstractions: in our approach, the Group Security Association (GSA) 382 includes the attributes of the Internet Security Architecture SA, which 383 is succinctly defined as the encapsulation of keys and policies 384 [RFC2409] as follows. 386 o An SA has selectors, such as source and destination transport 387 addresses. 388 o An SA has properties, such as an security parameter index (SPI) or 389 cookie pair, and identities. 390 o An SA has cryptographic policy, such as the algorithms, modes, key 391 lifetimes, and key lengths used for authentication or 392 confidentiality. 393 o An SA has keys, such as authentication, encryption and signing keys. 395 As is discussed in the next section of this memo, a GSA contains the SA 396 attributes plus some additional ones. As shown in Figure 4 (a), the GSA 397 is a superset of the SA. 399 o A GSA has group policy attributes, such as the kind of signed 400 credential needed for group membership and whether the group 401 will be given new keys when a member is added (called "backward 402 re-key" below) or whether group members will be given new keys when 403 a member is removed from the group ("backward re-key"). 404 o A GSA has SAs as attributes. 406 The final point, a GSA includes multiple SAs, is graphically depicted in 407 Figure 4 (b) and discussed more fully in the next section. 409 +------------------------------------------------------------+ 410 | | 411 | +---------------+ +-------------------+ | 412 | | GSA | | GSA | | 413 | | | | +-----+ +-----+ | | 414 | | | | | SA1 | | SA2 | | | 415 | | +----+ | | +-----+ +-----+ | | 416 | | | SA | | | +-----+ | | 417 | | +----+ | | | SA3 | | | 418 | | | | +-----+ | | 419 | +---------------+ +-------------------+ | 420 | | 421 | (a) superset (b) aggregation | 422 | | 423 +------------------------------------------------------------+ 424 Figure 4: Relationship of GSA to SA 426 The following lists summarize the desired properties of Internet group 427 key management. 429 1. The five properties of Internet key management as described in 430 the previous section. 431 2. Support for the IRTF Secure Multicast Reference Framework 432 having a GCKS that controls access to the group of sending and 433 receiving members according to the group policy it distributes. 434 3. Support for IP multicast applications where there may be one or 435 more senders to the group who may each have a unique SA to the 436 group or who may each share a common SA to the group. 437 4. Support for both receiver-initiated "pull" of policy and keying 438 material in addition to server-initiated "push" using a variety 439 of re-key algorithms. 440 5. Selectable level of performance for group key management, which 441 permits tradeoffs in startup latency, re-initialization 442 complexity, message overhead, join latency, leave latency, and 443 other security-related performance such as transforms. 445 Group key management requires a protocol with the five properties listed 446 above. The protocol must be capable of establishing security 447 relationships that are not just peer-to-peer but also between GCKS and a 448 group of members (e.g., for re-key) and among sending and receiving 449 members (e.g., for data protection). This section suggested that these 450 relationships might be built upon group security associations, which in 451 turn build upon the security association concept of IPSec and 452 ISAKMP/IKE, as described in the next section. 454 3. GROUP SECURITY ASSOCIATION: DEFINITION AND EXAMPLES 456 In this section we describe further the structure of a GSA and provide a 457 definition of a GSA. 459 3.1 Structure of a GSA: Reasoning 461 There are three categories of SAs aggregated into a GSA in Figure 4(b). 462 We choose this structure to better realize a GSA in our key management 463 environment, the SMuG Reference Framework [HCBD00]. There is a need to 464 maintain SAs between a Key Server and a group member (either a sender, a 465 receiver or both) and among members. In the SMuG Reference Framework, 466 the Key Server is called the "GCKS," which is charged with access 467 control to the group keys, with policy distribution to client members or 468 prospective members, and with group key dissemination to sender and 469 receiver client members. This structure is common in many group key 470 management environments [HH99a,HH99b, CP99, RFC2627, BMS99, Bris99]. 471 There are two SAs established between the GCKS and the members, and 472 there is an SA established among the sending and receiving members as 473 shown in Figure 5. 475 The first category of SA (namely SA1 in Figure 5) is initiated by the 476 member to pull GSA information from the GCKS; this is how the member 477 requests to join the secure group or has its GSA keys re-initialized 478 after being disconnected from the group (e.g., when its host computer 479 has been turned off during re-key operations as described below). The 480 GSA information pulled down from the GCKS include the SA, keys and 481 policy used to secure the data transmission between sending and 482 receiving members; this is SA3 in Figure 5. Note that SA3 is a category 483 of SA, and this implies that there may be multiple SAs established 484 between member senders and member receivers - at least as an option. 485 There may exist, for example, a single SA of category SA3 in which all 486 senders share common keys and associated information. Or there may be 487 one or more SAs of category SA3 that are unique to the particular 488 sender. An SA3 security association may be reestablished or have its 489 keys modified through re-key operations, which occur over an SA of 490 category SA2. Keys are pushed through an SA of category SA2 to support 491 subscription groups. 493 Thus, despite the fact that the data to be protected are multicast, pull 494 exchanges through an SA1 should be unicast or point-to-point key 495 determination exchanges. Some group key management solutions rely 496 solely point-to-point. Most others combine unicast exchanges for 497 initialization with multicast distribution for re-key. In some cases, 498 such as in a pure "pay-per-session" application, all of the SA 499 information needed for the session may be distributed at the time of 500 registration or selection of a session, i.e. over an SA1; re-key and re- 501 initialization may not be necessary, so there is no SA2. For 502 subscription groups where keying material is changed as membership 503 changes, an SA2 is needed to re-initialize an SA3. 505 +------------------------------------------------------------+ 506 | | 507 | +------------------+ | 508 | | | | 509 | | GCKS | | 510 | | SA1 SA1 | | 511 | | / SA2 \ | | 512 | +---/-----|----\---+ | 513 | / | \ | 514 | / | \ | 515 | / | \ | 516 | / | \ | 517 | / | \ | 518 | +-------------/------+ | +------\-------------+ | 519 | | SA1 | | | SA1 | | 520 | | SA2-----+----SA2 | | 521 | | MEMBER SENDER | | MEMBER RECEIVER | | 522 | | SA3----------SA3 | | 523 | +--------------------+ +--------------------+ | 524 | | 525 | | 526 +------------------------------------------------------------+ 527 Figure 5: GKM-BB GSA Structure and 3 categories of SAs 529 3.2 Definition of GSA 531 The current GKM Building Block defines a GSA to include an aggregate of 532 three (3) categories of SAs. The three categories of SAs correspond to 533 the three kinds of communications as seen from the point of view of the 534 Receiver (Member). Figure 5 depicts this concept: 536 - Category-1 SA: 537 a SA is required for (bi-directional) unicast communications between 538 the GCKS and a group member (be it a Sender or Receiver). This SA is 539 established only between the GCKS and a Member. In the SMuG Reference 540 Framework, the GCKS entity is charged with access control to the 541 group keys, with policy distribution to members (or prospective 542 members), and with group key dissemination to Sender and Receiver 543 members. This use of a (unicast) SA as a starting point for key 544 management is common in a number of group key management environments 545 [HH99a, HH99b, CP99, RFC2627, BMS99, Bris99]. 547 Note that this (unicast) SA is used to protect the other elements of 548 the GSA (such as the other following two categories of SAs), either 549 in a "push" or "pull" model. As such, this SA is crucial and is 550 inseparable from the other two SAs as the definition of a GSA. 552 From the perspective of one given GCKS, there are as many unique 553 Category-1 SAs as there are members (Senders and/or Receivers) in the 554 group. Thus there may be a scalability concern for some 555 applications, so a Category-1 SA may be used on-demand whereas 556 Category-2 and Category-3 SAs are established at least for the life 557 of the sessions that they support. 559 - Category-2 SA: 560 a SA is required for the multicast transmission of key-management 561 messages (unidirectional) from the GCKS to all group members. As 562 such, this SA is known by the GCKS and by all members of the group. 564 This SA is not negotiated, since all the group members must share it. 565 Thus, the GCKS must be the authentic source and act as the sole point 566 of contact for the group members to obtain this SA. 568 From the perspective of each participant in a group (GCKS and all 569 members), there is at least one (1) Category-2 SA for the group. Note 570 that this allows for the possibility of the GCKS deploying multiple 571 Category-2 SA for group key management purposes. 573 - Category-3 SA: 574 one or more SAs are required for the multicast transmission of data- 575 messages (unidirectional) from the Sender to other group members. 576 This SA is known by the GCKS and by all members of the group. 578 Similarly, regardless of the number of instances of this third 579 category of SA, this SA is not negotiated. Rather, all group members 580 obtain it from the GCKS. The GCKS itself does not use this category 581 of SA. 583 From the perspective of the Receivers, there is at least one 584 Category-3 SAs for the member sender (one or more) in the group. This 585 allows for the possibility of including group IDs (GID) in 586 transmission of data packets from the senders in the group. 588 There are a number of possibilities with respect to the number of 589 Category-3 SAs and the use of GIDs: 591 (i) Each sender in the group could be assigned a unique Category-3 592 SA, thereby resulting in each receiver having to maintain as many 593 Category-3 SA as there are senders in the group. 595 (ii) The entire group deploys a single Category-3 SA for all 596 senders, together with the use of GIDs. Receivers would then be 597 able to filter based on the GIDs, whilst maintaining only one 598 Category-3 SA. 600 (iii) A combination of (i) and (ii) above. 602 3.3 Forward and Backward Rekey 604 The re-key operation is needed to ensure that messages sent to the group 605 cannot be accessed by a former member whose membership has been revoked 606 by the GCKS; some applications may also require that a member who joins 607 a group be denied access to messages that were sent to the group prior 608 to its membership [CP99, HH99a, BMS99]. We call the first case, 609 "forward rekey," when a key change is prompted by a member leaving the 610 group, and the latter is called "backward rekey," when a re-key is 611 caused by a new member joining the group. Note that the terms 612 "forward/backward secrecy" and "forward/backward security" have been 613 used in the literature [CP99, HH99a, BMS99, HH99b]. 615 3.4 Group-Key Determination Algorithms 617 In order to efficiently implement re-key so that the complexity of 618 adding and removing members can be done in better than linear time, i.e. 619 without the need for unicast exchanges with each member, a structure may 620 be imposed on the SA2 keying material. The most efficient algorithms to 621 date achieve O(log n) complexity for the re-key operation [WL98, 622 RFC2627, BMS99, Bris99]. In such algorithms, SA2 has a tree structure 623 of keying material (beyond a list of keys as used in IKE), such as a 624 logical key hierarchy [RFC2627] or one-way function tree [BMS99]. These 625 approaches do not rely on a trusted execution environment, such as a 626 smart card installed on a member computer, so the member is trusted to 627 remove itself upon command from a key server [BF99]. Such a 'vertical' 628 approach, such as integrating a smart-card into the re-key operation 629 assumes too much about the operating environment for a general-purpose 630 internet solution. Instead, the SA2 structure (which is dependent on 631 the particular key determination algorithm), must change the keys of the 632 members of the group in a manner that is as efficient and free of 633 collusion [CP99, BMS99] as required by the particular application. 635 +------------------------------------------------------+ 636 | | 637 | DEPTH GTEK | 638 | ~~~~~ | 639 | 0 O KEK | 640 | / \ | 641 | / \ | 642 | 1 O O KEK | 643 | ... / \ | 644 | / \ | 645 | 2 ... O KEK | 646 | / \ | 647 | \ | 648 | ... ... | 649 | \ | 650 | O KEK | 651 | | | 652 | D Leaf (2**D)KEK | 653 | | 654 | | 655 +------------------------------------------------------+ 656 Figure 6: A GSA Key Structure 658 In RFC 2627 and one-way function trees, for example, each member has a 659 unique leaf key, the knowledge of which is shared only with the key 660 server, which generates the group traffic encrypting key or GTEK (the 661 "net key" in RFC 2627 parlance). In OFT, the key used to encrypt 662 session traffic is the root of structure, which is called the "root KEK" 663 in this memo). The KEK array of Figure 4 is an SA2. The GTEK belongs 664 to an SA3, and the SAs of category SA2 and SA3 are initialized over an 665 SA1, shown in Figure 3. The keys or material to create the keys of SA2 666 and SA3 are externally generated by the GCKS, which may be determined in 667 a manner similar to the IEXTKEY procedure of OAKLEY [RFC2412]. 669 4. SUMMARY AND FUTURE WORK 671 This memo contributes to the SMuG Reference Framework and Building 672 Blocks effort [HCBD00], which seeks to develop the foundations for 673 secure multicast standards in the near future. The group key building 674 block will provide a key management solution for Problem Area 2 of the 675 SMuG Reference Framework though this memo only proposed a set of 676 properties and abstractions for group key management. The ultimate goal 677 of this effort is to define the framework so it can be implemented in 678 one or more protocol instantiations. In order to progress to the point 679 of worthy specifications and working implementations, several questions 680 must be answered. 682 1. What framework should be used for the group key management 683 building block? 684 2. How many of each category of SA should be allowed in a GSA? 685 3. What transport should be used for Category-2 SA key management 686 control messages? 688 The first question asks whether the Internet key management framework, 689 ISAKMP, should be used or whether some invented framework should be used 690 to express, specify, and/or implement group key management. 692 The second question that must be answered is how many SAs of Category-2 693 and Category-3 must the group key management framework support? This 694 issue has ramifications for how complex the framework will be in terms 695 of messages and payloads. Multiple Category-3 SAs, for example, may be 696 used to bundle keying material for multiple, related groups such as for 697 multimedia sessions [RFC1889]. A related question concerns GSA updates: 698 are operations needed to modify existing SAs? Such operations may be 699 very complex and may entail changes to group policy, which may have 700 significant ramifications on access control. Re-key algorithms such as 701 LKH and OFT update SAs by modifying keys. Whereas TLS supports 702 operations to change the cipher, IKE requires that a new SA be created 703 and the old SA deleted as the means by which an SA is modified. 705 The third question is the transport to be used for Category-2 SA 706 messages which are multicast and which have reliability requirements. 707 Should a reliable multicast services be assumed? Should it be 708 integrated into the protocol? More consideration is needed on the 709 effects of providing a multicast key management services to groups of 710 members, large and small, static and dynamic. 712 It is our intention to address these questions in the process of 713 developing a specification for the group key management building block 714 in a subsequent draft. 716 REFERENCES 718 [BF99] B. Briscoe, I. Fairman, Nark: Receiver-based Multicast, Non- 719 repudiation and Key Management, Proceedings of ACM E-Commerce'99, 720 rbriscoe@bt.co.uk. 722 [BMS99] D. Balenson, D. McGrew, A. Sherman, Key Management for Large 723 Dynamic Groups: One-Way Function Trees and Amortized Initialization, 724 http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft- 725 00.txt, February 1999, Work in Progress. 727 [BR93] M. Bellare, P. Rogaway, Entity Authentication and Key 728 Distribution, Advances in Cryptology - Crypto '93 Proceedings, Springer- 729 Verlag, 1993. 731 [Bris99] B. Briscoe, MARKS: Zero Side Effect Multicast Key Management 732 using Arbitrarily Revealed Key Sequences, Proceedings of NGC'99, 733 rbriscoe@bt.co.uk. 735 [CP99] R. Canetti and B. Pinkas, A taxonomy of multicast security 736 issues, http://www.ietf.org/internet-drafts/draft-irtf-smug-taxonomy- 737 01.txt, August 2000, Work in Progress. 739 [DVW92] Diffie, P. van Oorschot, M. J. Wiener, Authentication and 740 Authenticated Key Exchanges, Designs, Codes and Cryptography, 2, 107-125 741 (1992), Kluwer Academic Publishers. 743 [FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of IPsec, 744 CounterPane, http://www.counterpane.com/ipsec.html. 746 [HCBD00] T. Hardjono, R. Canetti, M. Baugher, P. Disnmore, Secure IP 747 Multicast: Problem areas, Framework, and Building Blocks, 748 http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-01.txt, 749 Work in Progress, Sept 2000. 751 [HCD00] T. Hardjono, B. Cain, N. Doraswamy, A framework for group key 752 management for multicast security, http://www.ietf.org/internet- 753 drafts/draft-ietf-ipsec-gkmframework-03.txt, Aug 2000, Work in 754 Progress. 756 [HH99a] H. Harney, E. Harder, Multicast Security Management Protocol 757 (MSMP) Requirements and Policy, draft-harney-msmp-sec-00.txt, March 758 1999, Work in Progress. 760 [HH99b] H. Harney, E. Harder, Group Secure Association Key Management 761 Protocol, http://search.ietf.org/internet-drafts/draft-harney-sparta- 762 gsakmp-sec-00.txt, April 1999, Work in Progress. 764 [Kraw96] H. Krawczyk, SKEME: A Versatile Secure Key Exchange Mechanism 765 for Internet, ISOC Secure Networks and Distributed Systems Symposium, 766 San Diego, 1996. 768 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A 769 Transport Protocol for Real-Time Applications, January 1996. 771 [RFC2093] Harney, H., and Muckenhirn, C., "Group Key Management Protocol 772 (GKMP) Specification," RFC 2093, July 1997. 774 [RFC2094] Harney, H., and Muckenhirn, C., "Group Key Management Protocol 775 (GKMP) Architecture," RFC 2094, July 1997. 777 [RFC2401] S. Kent, R. Atkinson, Security Architecture for the Internet 778 Protocol, November 1998 780 [RFC2407] D. Piper, The Internet IP Domain of Interpretation for ISAKMP, 781 November 1998. 783 [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet 784 Security Association and Key Management Protocol, November 1998. 786 [RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), 787 November, 1998. 789 [RFC2412] H. Orman, The OAKLEY Key Determination Protocol, November 790 1998. 792 [RFC2522] P. Karn, W. Simpson, Photuris: Session-Key Management 793 Protocol, March 1999. 795 [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for 796 Multicast: Issues and Architectures, September 1998. 798 [SDNS88] H. L. Rogers, An Overview of the CANEWARE Program, 10th 799 National Security Conference, National Security Agency, 1988. 801 [WL98] C.K.Wong, S.S. Lam, Digital Signatures for Flows and Multicasts, 802 Proceedings of IEEE ICNP'98, October 14-16, 1998. 804 Authors Address: 806 Hugh Harney 807 SPARTA, Inc. 808 Secure Systems Engineering Division 809 9861 Broken Land Parkway, Suite 300 810 Columbia, MD 21046-1170, USA 811 +1 410 381 9400 (ext. 203) 812 hh@columbia.sparta.com 814 Mark Baugher 815 PassEdge 816 20400 NW Amberwood Drive 817 Beaverton, OR 97006, USA 818 (503) 466-8406 819 mbaugher@passedge.com 821 Thomas Hardjono 822 Nortel Networks 823 600 Technology Park Drive 824 Billerica, MA 01821, USA 825 (978) 288-4538 826 thardjono@baynetworks.com 828 -------------------------------------------------------------------