idnits 2.17.1 draft-ietf-msec-arch-05.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7222 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) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) == Outdated reference: A later version (-08) exists of draft-ietf-msec-gkmarch-06 == Outdated reference: A later version (-10) exists of draft-ietf-msec-gsakmp-sec-04 -- Obsolete informational reference (is this intentional?): RFC 2362 (Obsoleted by RFC 4601, RFC 5059) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-04 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3019 (Obsoleted by RFC 5519) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Thomas Hardjono (VeriSign) 3 INTERNET-DRAFT Brian Weis (Cisco) 4 draft-ietf-msec-arch-05.txt Expires July 2004 5 January 2004 7 The Multicast Group Security Architecture 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This document provides an overview and rationale of the multicast 37 security architecture used to secure data packets of large multicast 38 groups. The document begins by introducing a Multicast Security 39 Reference Framework, and proceeds to identify the security services 40 that may be part of a secure multicast solution. 42 The Multicast Group Security Architecture January, 2004 44 Table of Contents 46 1. Introduction.......................................................2 47 1.1 Scope...........................................................3 48 1.2 Summary of Contents of Document.................................4 49 1.3 Audience........................................................4 50 1.4 Terminology.....................................................4 51 2. Architectural Design: The Multicast Security Reference Framework...5 52 2.1 The Reference Framework.........................................5 53 2.2 Elements of the Centralized Reference Framework.................6 54 2.2.1 Group Controller and Key Server.............................7 55 2.2.2 Sender and Receiver.........................................7 56 2.2.3 Policy Server...............................................7 57 2.3 Elements of the Distributed Reference Framework.................8 58 3. Functional Areas...................................................9 59 3.1 Multicast Data Handling.........................................9 60 3.2 Group Key Management...........................................10 61 3.3 Multicast Security Policies....................................11 62 4. Group Security Associations (GSA).................................12 63 4.1 The Security Association.......................................12 64 4.2 Structure of a GSA: Introduction...............................12 65 4.3 Structure of a GSA: Reasoning..................................13 66 4.4 Definition of GSA..............................................14 67 4.5 Typical Compositions of a GSA..................................16 68 5. Security Services.................................................16 69 5.1 Multicast Data Confidentiality.................................17 70 5.2 Multicast Source Authentication and Data Integrity.............17 71 5.3 Multicast Group Authentication.................................18 72 5.4 Multicast Group Membership Management..........................18 73 5.5 Multicast Key Management.......................................19 74 5.6 Multicast Policy Management....................................20 75 6. Security Considerations...........................................20 76 6.1 Multicast Data Handling........................................20 77 6.2 Group Key Management...........................................21 78 6.3 Multicast Security Policies....................................21 79 7. Intellectual Property Rights Statement............................21 80 8. Acknowledgments...................................................21 81 9. References........................................................22 82 9.1 Normative References...........................................22 83 9.2 Informative References.........................................22 84 Authors Addresses....................................................24 85 Full Copyright Statement.............................................24 87 1. Introduction 88 The Multicast Group Security Architecture January, 2004 90 Securing IP multicast group communication is a complex task that 91 involves many aspects. Consequently, a secure IP multicast protocol 92 suite must have a number of functional areas that address different 93 aspects of the solution. This document describes those functional 94 areas, and how they are related. 96 1.1 Scope 98 This architecture is concerned with the securing of large multicast 99 groups. Whereas it can also be used for smaller groups, it is not 100 necessarily the most efficient means. Other architectures (e.g., the 101 Cliques architecture [STW]) can be more efficient for small ad-hoc 102 group communication. 104 This architecture is "end to end", and does not require multicast 105 routing protocols (e.g., PIM [RFC2362]) to participate in this 106 architecture. Inappropriate routing may cause denial of service to 107 application layer groups conforming to this architecture. However the 108 routing cannot affect the authenticity or secrecy of group data or 109 management packets. The multicast routing protocols could themselves 110 use this architecture to protect their own multicast and group 111 packets. However, this would be independent of any secure application 112 layer group. 114 This architecture does not require IP multicast admission control 115 protocols (e.g., IGMP [RFC3376], MLD [RFC3019]) to be a part of 116 secure multicast groups. As such, a "join" or "leave" operation for a 117 secure group is independent of a "join" or "leave" of an IP multicast 118 group. For example, the process of joining a secure group requires 119 being authenticated and authorized by a security device, while the 120 process of joining an IP multicast group entails contacting a 121 multicast-aware router. Admission control protocols could themselves 122 use this architecture to protect their own multicast packets. 123 However, this would be independent of any secure application layer 124 group. 126 This architecture does not explicitly describe how secure multicast 127 groups deal with Network Address Translation (NAT) [RFC2663]. 128 Multicast routing protocols generally require the source and 129 destination addresses and ports of an IP multicast packet to remain 130 unchanged. This allows consistent multicast distribution trees to be 131 created throughout the network. If NAT is used in a network, then the 132 connectivity of senders and receivers may be adversely affected. This 133 situation is neither improved or degraded as a result of deploying 134 this architecture. 136 This architecture does not require the use of reliable mechanisms, 137 for either data or management protocols. The use of reliable 138 multicast routing techniques (e.g., FEC [RFC3453]) enhance the 139 availability of secure multicast groups. However the authenticity or 140 secrecy of group data or management packets is not affected by the 141 omission of that capability from a deployment. 143 The Multicast Group Security Architecture January, 2004 145 1.2 Summary of Contents of Document 147 This document provides an architectural overview that outlines the 148 security services required to secure large multicast groups. It 149 provides a Reference Framework for organizing the various elements 150 within the architecture, and explains the elements of the Reference 151 Framework. 153 The Reference Framework organizes the elements of the architecture 154 along three Functional Areas pertaining to security. These elements 155 cover the treatment of data when it is to be sent to a group, the 156 management of keying material used to protect the data, and the 157 policies governing a group. 159 Another important item in this document is the definition and 160 explanation of Group Security Associations (GSA), which is the 161 multicast counterpart of the unicast Security Association (SA). The 162 GSA is specific to multicast security, and is the foundation of the 163 work on group key management. 165 1.3 Audience 167 This document is addressed to the technical community, implementers 168 of IP multicast security technology, and others interested in gaining 169 a general background understanding of multicast security. This 170 document assumes that the reader is familiar with the Internet 171 Protocol, the IPsec suite of protocols (e.g. [RFC2401]), related 172 networking technology, and general security terms and concepts. 174 1.4 Terminology 176 The following key terms are used throughout this document. 178 1-to-N 180 A group which has one sender and many receivers. 182 Group Security Association (GSA) 184 A bundling of Security Associations (SAs) that together define 185 how a group communicates securely. The GSA may include an 186 registration protocol SA, a rekey protocol SA, and one or more 187 data security protocol SAs. 189 M-to-N 191 A group which has many senders and many receivers, where M and N 192 are not necessarily the same value. 194 The Multicast Group Security Architecture January, 2004 196 Security Association (SA) 198 A set of policy and cryptographic keys that provide security 199 services to network traffic that matches that policy. 201 2. Architectural Design: The Multicast Security Reference Framework 203 This section considers the complex issues of multicast security in 204 the context of a Reference Framework. This reference framework is 205 used to classify functional areas, functional elements, and 206 interfaces. Two designs of the reference framework are shown: a 207 centralized design, and a distributed design that extends the 208 centralized design for very large groups. 210 2.1 The Reference Framework 212 The reference framework is based on three broad functional areas (as 213 shown in Figure 1). The reference framework incorporates the main 214 entities and functions relating to multicast security, and depicts 215 the inter-relations among them. It also expresses multicast security 216 from the perspective of multicast group types (1-to-N and M-to-N), 217 and classes of protocols (the exchanged messages) needed to secure 218 multicast packets. 220 The aim of the reference framework is to provide some general context 221 around the functional areas, and the relationships between the 222 functional areas. Note that some issues span more than one so-called 223 functional area. In fact, the framework encourages the precise 224 identification and formulation of issues that involve more than one 225 functional area or those which are difficult to express in terms of a 226 single functional area. An example of such a case is the expression 227 of policies concerning group keys, which involves both the functional 228 areas of group key management and multicast policies. 230 When considering the reference framework diagrams, it is important to 231 realize that the singular "boxes" in the framework do not necessarily 232 imply a corresponding singular entity implementing a given function. 233 Rather, a box in the framework should be interpreted loosely as 234 pertaining to a given function related to a functional area. Whether 235 that function is in reality implemented as one or more physical 236 entities is dependent on the particular solution. As an example, the 237 box labeled "Key Server" must be interpreted in broad terms as 238 referring to the functions of key management. 240 Similarly, the reference framework acknowledges that some 241 implementations may in fact merge a number of the "boxes" into a 242 single physical entity. This could be true even across functional 243 areas. For example, an entity in a group could act as both a Group 244 Controller and a Sender to a group. 246 The protocols to be standardized are depicted in the reference 247 framework diagrams by the arrows that connect the various boxes. See 248 more details in Section 4, below. 250 The Multicast Group Security Architecture January, 2004 252 2.2 Elements of the Centralized Reference Framework 254 The Reference Framework diagram of Figure 1 contains boxes and 255 arrows. The boxes are the functional entities and the arrows are the 256 interfaces between them. Standard protocols are needed for the 257 interfaces, which support the multicast services between the 258 functional entities. 260 In some cases, a system implementing the multicast security 261 architecture may not need to implement protocols to account for every 262 interface. Rather, those interfaces may be satisfied through the use 263 of manual configuration, or even omitted if they are not necessary 264 for the application. 266 There are three sets of functional entities. Each is discussed below. 267 +--------------------------------------+ 268 | | 269 | | 270 | FUNCTIONAL | 271 | AREAS | 272 | | 273 | +------+ | 274 | Multicast |Policy| | 275 | Security |Server| | 276 | Policies +------+ | 277 | ^ | 278 | | | 279 | | | 280 | v | 281 | +------+ | 282 | Group |Group | | 283 | Key |Ctrl/ |<---------+ | 284 | Management |Key | | | 285 | |Server| V | 286 | +------+ +--------+ | 287 | ^ | | | 288 | | |Receiver| | 289 | | | | | 290 | v +--------+ | 291 | +------+ ^ | 292 | | | | | 293 | Multicast |Sender|----------+ | 294 | Data | | | 295 | Handling | | | 296 | +------+ | 297 | | 298 +--------------------------------------+ 299 Figure 1: Centralized Multicast Security Reference Framework 300 The Multicast Group Security Architecture January, 2004 302 2.2.1 Group Controller and Key Server 304 The Group Controller and Key Server (GCKS) represent both the entity 305 and functions relating to the issuance and management of 306 cryptographic keys used by a multicast group, which is subject to the 307 user-authentication and authorization checks conducted on the 308 candidate member of the multicast group. 310 The Key Server (KS) and the Group Controller (GC) have somewhat 311 different functionality and may in principle be regarded as separate 312 entities. Currently the framework regards the two entities as one 313 "box" in order to simplify the design, and in order not to mandate 314 standardization of the protocol between the KS and the GC. It is 315 stressed that the KS and GC need not be co-located. Furthermore, 316 future designs may choose to standardize the protocol between the GC 317 and the KS, without altering other components. 319 2.2.2 Sender and Receiver 321 The Sender is an entity that sends data to the multicast group. In a 322 1-to-N multicast group only a single sender is authorized to transmit 323 data to the group. In an M-to-N multicast group, two or more group 324 members are authorized to be senders. In some groups all members are 325 authorized as senders. 327 Both Sender and Receiver must interact with the GCKS entity for the 328 purpose of key management. This includes user and/or device 329 authentication, user and/or device authorization, the obtaining of 330 keying material in accordance with some key management policies for 331 the group, obtaining new keys during key-updates, and obtaining other 332 messages relating to the management of keying material and security 333 parameters. 335 Senders and Receivers may receive much of their policy from the GCKS 336 entities. The event of joining a multicast group is typically coupled 337 with the Sender/Receiver obtaining keying material from a GCKS 338 entity. This does not preclude the direct interaction between the 339 Sender/Receiver and the Policy Server. 341 2.2.3 Policy Server 343 The Policy Server represents both the entity and functions used to 344 create and manage security policies specific to a multicast group. 345 The Policy Server interacts with the GCKS entity in order to install 346 and manage the security policies related to the membership of a given 347 multicast group and those related to keying material for a multicast 348 group. 350 The interactions between the Policy Server and other entities in the 351 reference framework is dependent to a large extent on the security 352 circumstances being addressed by a given policy. 354 The Multicast Group Security Architecture January, 2004 356 2.3 Elements of the Distributed Reference Framework 358 The need for solutions to be scalable to large groups across wide 359 geographic regions of the Internet requires the elements of the 360 framework to also function as a distributed system. Figure 2 shows 361 how distributed designs supporting large group scalability fit into 362 the Reference Framework. 364 +-----------------------------------------------------------------+ 365 | | 366 | | 367 | FUNCTIONAL | 368 | AREAS | 369 | +------+ +------+ | 370 | Multicast |Policy|<-------------------------------->|Policy| | 371 | Security |Server| |Server| | 372 | Policies +------+ +------+ | 373 | ^ ^ | 374 | | | | 375 | | | | 376 | v v | 377 | +------+ +------+ | 378 | Group |Group |<-------------------------------> |Group | | 379 | Key |Ctrl/ |<---------+ |Ctlr/ | | 380 | Management |Key | | |Key | | 381 | |Server| V |Server| | 382 | +------+ +--------+ +------+ | 383 | ^ | | ^ | 384 | | |Receiver| | | 385 | | | | | | 386 | v +--------+ | | 387 | +------+ ^ V | 388 | | | | +--------+ | 389 | Multicast |Sender|----------+ | | | 390 | Data | |-------------------------------->|Receiver| | 391 | Handling | | | | | 392 | +------+ +--------+ | 393 +-----------------------------------------------------------------+ 394 Figure 2: Distributed Multicast Security Reference Framework 396 In a distributed design the GCKS entity interacts with other GCKS 397 entities to achieve scalability in the key management related 398 services. GCKS entities will require a means of authenticating their 399 peer GCKS entities, a means of authorization, and a means of 400 interacting securely to pass keys and policy. 402 Similarly, Policy Servers must interact with each other securely to 403 allow the communication and enforcement of policies across the 404 Internet. 406 The Multicast Group Security Architecture January, 2004 408 Two Receiver boxes are displayed corresponding to the situation where 409 both the Sender and Receiver employ the same GCKS entity (centralized 410 architecture) and where the Sender and Receiver employ different GCKS 411 entities (distributed architecture). In the distributed design, all 412 Receivers must obtain identical keys and policy. Each member of a 413 multicast group may interact with a primary GCKS entity (e.g., the 414 "nearest" GCKS entity, measured in terms of a well-defined and 415 consistent metric). Similarly, a GCKS entity may interact with one or 416 more Policy Servers, also arranged in a distributed architecture. 418 3. Functional Areas 420 The Reference Framework identifies three functional areas. They are: 422 - Multicast data handling. This area covers the security-related 423 treatments of multicast data by the sender and the receiver. This 424 functional area is further discussed in Section 3.1. 426 - Group Key Management. This area is concerned with the secure 427 distribution and refreshment of keying material. This functional 428 area is further discussed in Section 3.2. 430 - Multicast security policies. This area covers aspects of policy in 431 the context of multicast security, taking into consideration the 432 fact that policies may be expressed in different ways, that they 433 may exist at different levels in a given multicast security 434 architecture, and that they may be interpreted differently 435 according to the context in which they are specified and 436 implemented. This functional area is further discussed in Section 437 3.3. 439 3.1 Multicast Data Handling 441 In a secure multicast group, the data typically needs to be: 443 1. Encrypted using the group key, mainly for access control and 444 possibly also for confidentiality. 446 2. Authenticated, for verifying the source and integrity of the 447 data. Authentication takes two flavors: 448 a. Source authentication and data integrity. This 449 functionality guarantees that the data originated with the 450 claimed source and was not modified en route (either by a 451 group member or an external attacker). 452 b. Group authentication. This type of authentication only 453 guarantees that the data was generated (or last modified) 454 by some group member. It does not guarantee data integrity 455 unless all group members are trusted. 457 While multicast encryption and group authentication are fairly 458 standard and similar to encrypting and authenticating point-to-point 459 communication, source authentication for multicast is considerably 460 more involved. Consequently, off-the-shelf solutions (e.g., taken 461 The Multicast Group Security Architecture January, 2004 463 from IPsec [RFC2406]) may be sufficient for encryption and group 464 authentication. For source authentication, however, special-purpose 465 transformations are necessary. See [CCPRRS] for further 466 elaboration on the concerns regarding the data transforms. 468 Multicast data encrypted and/or authenticated by a sender should be 469 handled the same way by both centralized and distributed receivers, 470 (as shown in Figure 2). 472 The "Multicast Encapsulating Security Payload" [BCCR] provides the 473 definition for Multicast ESP for data traffic. The "Multicast Source 474 Authentication Transform Specification" [PCW] defines the use of the 475 TESLA algorithm for source authentication in multicast. 477 3.2 Group Key Management 479 The term "keying material" refers to the cryptographic keys belonging 480 to a group, the state associated with the keys, and the other 481 security parameters related to the keys. Hence, the management of 482 the cryptographic keys belonging to a group necessarily requires the 483 management of their associated state and parameters. A number of 484 solutions for specific issues must be addressed. These may include 485 the following: 487 - Methods for member identification and authentication. 488 - Methods to verify the membership to groups. 489 - Methods to establish a secure channel between a GCKS entity and 490 the member, for the purpose of delivery of shorter-term keying 491 material pertaining to a group. 492 - Methods to establish a long-term secure channel between one GCKS 493 entity and another, for the purpose of distributing shorter-term 494 keying material pertaining to a group. 495 - Methods to effect the changing of keys and keying material 496 - Methods to detect and signal failures and perceived compromises to 497 keys and keying material 499 The requirements related to the management of keying material must be 500 seen in the context of the policies that prevail within the given 501 circumstance. 503 Core to the area of key management is Security Association (SA) 504 Management, which will be discussed further below. 506 A "Group Key Management Architecture" document [BCDL] further defines 507 the key management architecture for multicast security. It builds on 508 the Group Security Association (GSA) concept, and further defines the 509 roles of the Key Server and Group Controller. 511 "The Group Domain of Interpretation" [RFC3547], "GSAKMP" [GSAKMP], 512 and "MIKEY" [ACLNM] are three instances of protocols implementing the 513 group key management function. 515 The Multicast Group Security Architecture January, 2004 517 3.3 Multicast Security Policies 519 Multicast Security Policies must provide the rules for operation for 520 the other elements of the Reference Framework. Security Policies may 521 be distributed in an ad-hoc fashion in some instances. However, 522 better coordination and higher levels of assurance are achieved if a 523 Policy Controller distributes Security Policies policy to the group. 525 Multicast security policies must represent, or contain, more 526 information than a traditional peer-to-peer policy. In addition to 527 representing the security mechanisms for the group communication, the 528 policy must also represent the rules for the governance of the secure 529 group. For example, policy would specify the authorization level 530 necessary in order for an entity to join a group. More advanced 531 operations would include the conditions when a group member must be 532 forcibly removed from the group, and what to do if the group members 533 need to resynchronize because of lost key management messages. 535 The application of policy at the Group Controller element and the 536 member (sender and receiver) elements must be described. While there 537 is already a basis for security policy management in the IETF, 538 multicast security policy management extends the concepts developed 539 for unicast communication in the areas of: 541 - Policy creation, 542 - High-level policy translation, and 543 - Policy representation. 545 Examples of work in multicast security policies include the Dynamic 546 Cryptographic Context Management project [Din], Group Key Management 547 Protocol [Har1, Har2], and Antigone [McD]. 549 Policy creation for secure multicast has several more dimensions than 550 the single administrator specified policy assumed in the existing 551 unicast policy frameworks. Secure multicast groups are usually large 552 and by their very nature extend over several administrative domains, 553 if not spanning a different domain for each user. There are several 554 methods that need to be considered in the creation of a single, 555 coherent group security policy. They include a top-down specification 556 of the group policy from the group initiator and negotiation of the 557 policy between the group members (or prospective members). 558 Negotiation can be as simple as a strict intersection of the policies 559 of the members or extremely complicated using weighted voting 560 systems. 562 The translation of policy rules from one data model to another is 563 much more difficult in a multicast group environment. This is 564 especially true when group membership spans multiple administrative 565 domains. Policies specified at a high level with a Policy Management 566 tool must be translated into more precise rules that the available 567 security policy mechanisms can both understand and implement. When 568 dealing with multicast communication and its multiple participants, 569 it is essential that the individual translation performed for each 570 The Multicast Group Security Architecture January, 2004 572 participant result in the use of a mechanism that is interoperable 573 with the results of all of the other translations. Typically, the 574 translation from high-level policy to specific policy objects must 575 result in the same objects in order to achieve communication between 576 all of the group members. The requirement that policy translation 577 results in the same objects places constraints on the use and 578 representations in the high-level policies. 580 It is also important that policy negotiation and translation be 581 performed as an integral part of joining a group. Adding a member to 582 a group is meaningless if they will not be able to participate in the 583 group communications. 585 4. Group Security Associations (GSA) 587 4.1 The Security Association 589 A security association is a commonly used term in cryptographic 590 systems (e.g., [RFC2401, RFC2406bis, RFC2409]). This document uses 591 the term to mean any set of policy and cryptographic keys that 592 provide security services for the network traffic matching that 593 policy. A Security Association usually contains the following 594 attributes: 596 - selectors, such as source and destination transport addresses. 597 - properties, such as an security parameter index (SPI) or cookie 598 pair, and identities. 599 - cryptographic policy, such as the algorithms, modes, key 600 lifetimes, and key lengths used for authentication or 601 confidentiality. 602 - keys, such as authentication, encryption and signing keys. 604 Group key management uses a different set of abstractions than point- 605 to-point key management systems (such as IKE [RFC2409]). 606 Notwithstanding, the abstractions used in the Group Key Management 607 functional area may be built from the point-to-point key management 608 abstractions. 610 4.2 Structure of a GSA: Introduction 612 Security associations (SAs) for group key management are more 613 complex, and are usually more numerous, than for point-to-point key 614 management algorithms. The latter establishes a key management SA to 615 protect application SAs (usually one or two, depending on the 616 protocol). However, group key management may require up to three or 617 more SAs. These SAs are described in later sections. 619 A GSA contains all of the SA attributes identified in the previous 620 section, as well some additional attributes pertaining to the group. 621 As shown in Figure 3, the GSA builds on the SA in two distinct ways. 623 - First, the GSA is a superset of an SA (Figure 3(a)). A GSA has 624 group policy attributes. For example, the kind of signed 625 The Multicast Group Security Architecture January, 2004 627 credential needed for group membership, whether group members will 628 be given new keys when a member is added (called "backward re-key" 629 below), or whether group members will be given new key when a 630 member is removed from the group ("forward re-key"). A GSA also 631 includes an SA as an attribute of itself. 633 - Second, the GSA is an aggregation of SAs (Figure 3(b)). A GSA is 634 comprised of multiple SAs, and these SAs may be used for several 635 independent purposes. 637 +---------------+ +-------------------+ 638 | GSA | | GSA | 639 | | | +-----+ +-----+ | 640 | | | | SA1 | | SA2 | | 641 | +----+ | | +-----+ +-----+ | 642 | | SA | | | +-----+ | 643 | +----+ | | | SA3 | | 644 | | | +-----+ | 645 +---------------+ +-------------------+ 647 (a) superset (b) aggregation 649 Figure 3: Relationship of GSA to SA 651 4.3 Structure of a GSA: Reasoning 653 Figure 4 shows three categories of SAs that can be aggregated into a 654 GSA. 656 +------------------------------------------------------------+ 657 | | 658 | +------------------+ | 659 | | GCKS | | 660 | | | | 661 | | REG REG | | 662 | | / REKEY \ | | 663 | +---/-----|----\---+ | 664 | / | \ | 665 | / | \ | 666 | / | \ | 667 | / | \ | 668 | / | \ | 669 | +----------/------+ | +------\----------+ | 670 | | REG | | | REG | | 671 | | REKEY-----+----REKEY | | 672 | | SENDER | | RECEIVER | | 673 | | DATA----------DATA | | 674 | +-----------------+ +-----------------+ | 675 | | 676 | | 677 +------------------------------------------------------------+ 678 Figure 4: GSA Structure and 3 categories of SAs 679 The Multicast Group Security Architecture January, 2004 681 The three categories of SAs are: 683 - Registration SA (REG): A separate unicast SA between the GCKS and 684 each group member, regardless of whether the group member is a 685 sender or a receiver or acting in both roles. 687 - Re-key SA (REKEY): A single multicast SA between the GCKS and all 688 of the group members. 690 - Data Security SA (DATA): A multicast SA between each multicast 691 source speaker and the group's receivers. There are as many data 692 SA as there are multicast sources allowed by the group's policy. 694 Each of these SAs are defined in more detail in the next section. 696 4.4 Definition of GSA 698 The three categories of SAs correspond to three different kinds of 699 communications commonly required for group communications. This 700 section describes the SAs depicted in Figure 4 in detail. 702 - Registration SA (REG): 703 An SA is required for (bi-directional) unicast communications 704 between the GCKS and a group member (be it a Sender or Receiver). 705 This SA is established only between the GCKS and a Member. The 706 GCKS entity is charged with access control to the group keys, 707 with policy distribution to members (or prospective members), and 708 with group key dissemination to Sender and Receiver members. This 709 use of a (unicast) SA as a starting point for key management is 710 common in a number of group key management environments [RFC3547, 711 GSAKMP, CCPRRS, RFC2627, BMS,]. 713 The Registration SA is initiated by the member to pull GSA 714 information from the GCKS. This is how the member requests to 715 join the secure group, or has its GSA keys re-initialized after 716 being disconnected from the group (e.g., when its host computer 717 has been turned off during re-key operations). The GSA 718 information pulled down from the GCKS is related to the other two 719 SAs defined as part of the GSA. 721 Note that this (unicast) SA is used to protect the other elements 722 of the GSA. As such, the Registration SA is crucial and is 723 inseparable from the other two SAs in the definition of a GSA. 725 However, the requirement of a registration SA does not imply the 726 need of a registration protocol to create that Registration SA. 727 The registration SA could instead be setup through some manual 728 means, such as distributed on a smart card. Thus, what is 729 important is that a Registration SA exists, and is used to 730 protect the other SAs. 732 The Multicast Group Security Architecture January, 2004 734 From the perspective of one given GCKS, there are as many unique 735 registration SAs as there are members (Senders and/or Receivers) 736 in the group. This may constitute a scalability concern for some 737 applications. A registration SA may be established on-demand with 738 a short lifetime, whereas re-key and data security SAs are 739 established at least for the life of the sessions that they 740 support. 742 Conversely the registration SA could be left in place for the 743 duration of the group lifetime, if scalability is not an issue. 744 Such a long term registration SA would be useful for re- 745 synchronization or deregistration purposes. 747 - Re-key SA (REKEY): 748 In some cases, a GCKS needs the ability to "push" new SAs as part 749 of the GSA. These new SAs must be sent to all group members. In 750 other cases, the GCKS needs the ability to quickly revoke access 751 to one or more group members. Both of these needs are satisfied 752 with the Re-key SA. 754 This Re-key SA is a unidirectional multicast transmission of key 755 management messages from the GCKS to all group members. As such, 756 this SA is known by the GCKS and by all members of the group. 758 This SA is not negotiated, since all the group members must share 759 it. Thus, the GCKS must be the authentic source and act as the 760 sole point of contact for the group members to obtain this SA. 762 A rekey SA is not absolutely required to be part of a GSA. For 763 example, the lifetime of some groups may be short enough such 764 that a rekey is not necessary. Conversely, the policy for the 765 group could specify multiple rekey SAs of different types. For 766 example, if the GC and KS are separate entities, the GC may 767 deliver rekey messages that adjust the group membership, and the 768 KS may deliver rekey messages with new DATA SAs. 770 - Data Security SA (DATA): 771 The Data Security SA protects data between member senders and 772 member receivers. 774 One or more SAs are required for the multicast transmission of 775 data-messages from the Sender to other group members. This SA is 776 known by the GCKS and by all members of the group. 778 Regardless of the number of instances of this third category of 779 SA, this SA is not negotiated. Rather, all group members obtain 780 it from the GCKS. The GCKS itself does not use this category of 781 SA. 783 From the perspective of the Receivers, there is at least one data 784 security SA for the member sender (one or more) in the group. If 785 the group has more than one data security SA, the data security 786 The Multicast Group Security Architecture January, 2004 788 protocol must have a means of differentiating the SAs (e.g., with 789 a SPI). 791 There are a number of possibilities with respect to the number of 792 data security SAs: 794 1. Each sender in the group could be assigned a unique data 795 security SA, thereby resulting in each receiver having to 796 maintain as many data security SAs as there are senders in the 797 group. In this case, each sender may be verified using source 798 origin authentication techniques. 800 2. The entire group deploys a single data security SA for all 801 senders. Receivers would then be able to maintain only one data 802 security SA. 804 3. A combination of 1. and 2. 806 4.5 Typical Compositions of a GSA 808 Depending on the multicast group policy, many compositions of a GSA 809 are possible. For illustrative purposes, this section describes a few 810 possible compositions. 812 - A group of memory-constrained members may require only a REG SA, 813 and a single DATA SA. 814 - A "pay-per-session" application, where all of the SA information 815 needed for the session may be distributed over a REG SA. Re-key 816 and re-initialization of DATA SAs may not be necessary, so there 817 is no REKEY SA. 818 - A subscription group, where keying material is changed as 819 membership changes. A REG SA is needed to distribute other SAs; a 820 REKEY SA is needed to re-initialize a DATA SA at the time 821 membership changes. 823 5. Security Services 825 This section identifies security services for designated interfaces 826 of Figure 2. Distinct security services are assigned to specific 827 interfaces. For example, multicast source authentication, data 828 authentication, and confidentiality occur on the multicast data 829 interface between Senders and Receivers in Figure 2. Authentication 830 and confidentiality services may also be needed between the Key 831 Server and key clients (i.e., the Senders and Receivers of Figure 832 2), but the services that are needed for multicast key management may 833 be unicast as well as multicast. A security service in the Multicast 834 Security Reference Framework therefore identifies a specific function 835 along one or more Figure 2 interfaces. 837 This paper does not attempt to analyze the trust relationships, 838 detailed functional requirements, performance requirements, suitable 839 algorithms, and protocol specifications for IP multicast and 840 application-layer multicast security. Instead, that work will occur 841 The Multicast Group Security Architecture January, 2004 843 as the security services are further defined and realized in 844 algorithms and protocols. 846 5.1 Multicast Data Confidentiality 848 This security service handles the encryption of multicast data at the 849 Sender's end and the decryption at the Receiver's end. This security 850 service may also apply the keying material that is provided by 851 Multicast Key Management in accordance with Multicast Policy 852 Management, but it is independent of both. 854 An important part of the Multicast Data Confidentiality security 855 service is in the identification of and motivation for specific 856 ciphers that should be used for multicast data. Obviously, not all 857 ciphers will be suitable for IP multicast and application-layer 858 multicast traffic. Since this traffic will usually be connectionless 859 UDP flows, stream ciphers may be unsuitable, though hybrid 860 stream/block ciphers may have advantages over some block ciphers. 862 Regarding application-layer multicast, some consideration is needed 863 to consider the effects of sending encrypted data in a multicast 864 environment lacking admission-control, where practically any 865 application program can join a multicast event independently of its 866 participation in a multicast security protocol. Thus, this security 867 service is also concerned with the effects of multicast 868 confidentiality services (intended and otherwise) on application 869 programs. Effects to both senders and receivers is considered. 871 In Figure 2, the Multicast Data Confidentiality security service is 872 placed in Multicast Data Handling Area along the interface between 873 Senders and Receivers. The algorithms and protocols that are 874 realized from work on this security service may be applied to other 875 interfaces and areas of Figure 2 when multicast data confidentiality 876 is needed. 878 5.2 Multicast Source Authentication and Data Integrity 880 This security service handles source authentication and integrity 881 verification of multicast data. It includes the transforms to be made 882 both at the Sender's end and at the Receiver's end. It assumes that 883 the appropriate signature and verification keys are provided via 884 Multicast Key Management in accordance with Multicast Policy 885 Management as described below. This is one of the harder areas of 886 multicast security due to the connectionless and real-time 887 requirements of many IP multicast applications. There are classes of 888 application-layer multicast security, however, where offline source 889 and data authentication will suffice. As discussed previously, not 890 all multicast applications require real-time authentication and data- 891 packet integrity. A robust solution to multicast source and data 892 authentication, however, is necessary for a complete solution to 893 multicast security. 895 The Multicast Group Security Architecture January, 2004 897 In Figure 2, the Multicast Source and Data Authentication security 898 service is placed in Multicast Data Handling Area along the interface 899 between Senders and Receivers. The algorithms and protocols that are 900 produced for this functional area may have applicability to security 901 services in other functional area that use multicast services such as 902 Group Key Management. 904 5.3 Multicast Group Authentication 906 This security service provides a limited amount of authenticity of 907 the transmitted data: It only guarantees that the data originated 908 with (or was last modified by) one of the group members. It does not 909 guarantee authenticity of the data in case that other group members 910 are not trusted. 912 The advantage of group authentication is that it is guaranteed via 913 relatively simple and efficient cryptographic transforms. Therefore, 914 when source authentication is not paramount, group authentication 915 becomes useful. In addition, performing group authentication is 916 useful even when source authentication is later performed: it 917 provides a simple-to-verify weak integrity check that is useful as a 918 measure against denial-of-service attacks. 920 The Multicast Group Authentication security service is placed in the 921 Multicast Data Handling Area along the interface between Senders and 922 Receivers. 924 5.4 Multicast Group Membership Management 926 This security service describes the functionality of registration of 927 members with the Group Controller, and de-registration of members 928 from the Group Controller. These are security functions, which are 929 independent from IP multicast group "join" and "leave" operations 930 that the member may need to perform as a part of group admission 931 control protocols (i.e., IGMP [RFC3376], MLD [RFC3019]). 933 Registration includes member authentication, notification and 934 negotiation of security parameters, and logging of information 935 according to the policies of the group controller and the would-be 936 member. (Typically, an out-of-band advertisement of group information 937 would occur before the registration takes place. The registration 938 process will typically be invoked by the would-be member.) 940 De-registration may occur either at the initiative of the member or 941 at the initiative of the group controller. It would result in logging 942 of the de-registration event by the group controller and an 943 invocation of the appropriate mechanism for terminating the 944 membership of the de-registering member (see Section 5.5). 946 This security service also describes the functionality of the 947 communication related to group membership among different GCKS 948 servers in a distributed group design. 950 The Multicast Group Security Architecture January, 2004 952 In Figure 2, the Multicast Group Membership security service is 953 placed in the Group Key Management Area and has interfaces to Senders 954 and Receivers. 956 5.5 Multicast Key Management 958 This security service describes the functionality of distributing and 959 updating the cryptographic keying material throughout the life of the 960 group. Components of this security service may include: 962 - GCKS to Client (Sender or Receiver) notification regarding 963 current keying material (e.g. group encryption and 964 authentication keys, auxiliary keys used for group management, 965 keys for source authentication, etc). 966 - Updating of current keying material, depending on circumstances 967 and policies. 968 - Termination of groups in a secure manner, including the 969 multicast group itself and the associated keying material. 971 Among the responsibilities of this security service is the secure 972 management of keys between Key Servers and Clients, the addressing 973 issues for the multicast distribution of keying material, and the 974 scalability or other performance requirements for multicast key 975 management [RFC2627, BMS]. Key Servers and Clients may take advantage 976 of a common Public Key Infrastructure (PKI) for increased scalability 977 of authentication and authorization. 979 To allow for an interoperable and secure IP multicast security 980 protocol, this security service may need to specify host abstractions 981 such as a group security association database (GSAD) and a group 982 security policy database (GSPD) for IP multicast security. The 983 degree of overlap between IP multicast and application-layer 984 multicast key management needs to be considered. Thus, this security 985 service takes into account the key management requirements for IP 986 multicast, the key management requirements for application-layer 987 multicast, and to what degree specific realizations of a Multicast 988 Key Management security service can satisfy both. ISAKMP, moreover, 989 has been designed to be extensible to multicast key management for 990 both IP multicast and application-layer multicast security [RFC2408]. 991 Thus, multicast key management protocols may use the existing ISAKMP 992 standard's Phase 1 and Phase 2 protocols, possibly with needed 993 extensions (such as GDOI [RFC3547] or application-layer multicast 994 security). 996 This security service also describes the functionality of the 997 communication related to key management among different GCKS servers 998 in a distributed group design. 1000 Multicast Key Management appears in both the centralized and 1001 distributed designs as shown in Figure 2 and is placed in the Group 1002 Key Management Area. 1004 The Multicast Group Security Architecture January, 2004 1006 5.6 Multicast Policy Management 1008 This security service handles all matters related to multicast group 1009 policy including membership policy and multicast key management 1010 policy. Indeed, one of the first tasks in further defining this 1011 security service is identifying the different areas of multicast 1012 policy. Multicast Policy Management includes the design of the policy 1013 server for multicast security, the particular policy definitions that 1014 will be used for IP multicast and application-layer multicast 1015 security, and the communication protocols between the Policy Server 1016 and the Key Server. This security service may be realized using a 1017 standard policy infrastructure such as a Policy Decision Point (PDP) 1018 and Policy Enforcement Point (PEP) architecture [RFC2748]. Thus, it 1019 may not be necessary to re-invent a separate architecture for 1020 multicast security policy. At minimum, however, this security service 1021 will be realized in a set of policy definitions, such as multicast 1022 security conditions and actions. 1024 The Multicast Policy Management security service describes the 1025 functionality of the communication between an instance of a GCKS to 1026 an instance the Policy Server. The information transmitted may 1027 include policies concerning groups, memberships, keying material 1028 definition and their permissible uses, and other information. This 1029 security service also describes communication between and among 1030 Policy Servers. Group members are not expected to directly 1031 participate in this security service. However, this option is not 1032 ruled out. 1034 6. Security Considerations 1036 This document describes an architectural framework for protecting 1037 multicast and group traffic with cryptographic protocols. Three 1038 functional areas are identified within the framework. Each functional 1039 area has unique security considerations, and these are discussed 1040 below. 1042 This architectural framework is end-to-end, and does not rely upon 1043 the network that connects group controllers and group members. It 1044 also does not attempt to resolve security issues in the unicast or 1045 multicast routing infrastructures, or in multicast admission control 1046 protocols. As such, denial of service, message deletion, and other 1047 active attacks against the unicast or multicast routing 1048 infrastructures are not addressed by this framework. Section 1.1 1049 describes the relationship of the network infrastructure to the 1050 multicast group security architecture. 1052 6.1 Multicast Data Handling 1054 Cryptographic protocols protecting multicast data are responsible for 1055 providing confidentiality and group authentication. They should also 1056 be able to provide source authentication to uniquely identify senders 1057 to the group. Replay protection of multicast data is also desirable, 1058 but may not always be possible. This is due to the complexity of 1059 The Multicast Group Security Architecture January, 2004 1061 maintaining replay protection state for multiple senders. Section 3.1 1062 elaborates on the security requirements for this area. 1064 6.2 Group Key Management 1066 Group key management protocols provide cryptographic keys and policy 1067 to group members. They are responsible for authenticating and 1068 authorizing group members before revealing those keys, and for 1069 providing confidentiality and authentication of those keys during 1070 transit. They are also responsible for providing a means for rekeying 1071 the group, in the case that the policy specifies a lifetime for the 1072 keys. They also are responsible for revocation of group membership, 1073 once one or more group members have had their authorization to be a 1074 group member revoked. Section 3.2 describes the security requirements 1075 of this area in more detail. 1077 6.3 Multicast Security Policies 1079 Cryptographic protocols providing multicast security policies are 1080 responsible for distributing that policy such that the integrity of 1081 the policy is maintained. If the policy itself is confidential, they 1082 also are responsible for authenticating group controllers and group 1083 members, and providing confidentiality of the policy during transit. 1085 7. Intellectual Property Rights Statement 1087 The IETF takes no position regarding the validity or scope of any 1088 intellectual property or other rights that might be claimed to 1089 pertain to the implementation or use of the technology described in 1090 this document or the extent to which any license under such rights 1091 might or might not be available; neither does it represent that it 1092 has made any effort to identify any such rights. Information on the 1093 IETF's procedures with respect to rights in standards-track and 1094 standards-related documentation can be found in BCP-11. Copies of 1095 claims of rights made available for publication and any assurances 1096 of licenses to be made available, or the result of an attempt made 1097 to obtain a general license or permission for the use of such 1098 proprietary rights by implementors or users of this specification 1099 can be obtained from the IETF Secretariat. 1101 The IETF invites any interested party to bring to its attention any 1102 copyrights, patents or patent applications, or other proprietary 1103 rights which may cover technology that may be required to practice 1104 this standard. Please address the information to the IETF Executive 1105 Director. 1107 8. Acknowledgments 1109 Much of the text in this document was derived from two research 1110 papers. The framework for this document came from a paper co-authored 1111 by Thomas Hardjono, Ran Canetti, Mark Baugher, and Pete Dinsmore. 1112 Description of the GSA came from a document co-authored by Hugh 1113 Harney, Mark Baugher, and Thomas Hardjono. George Gross suggested a 1114 The Multicast Group Security Architecture January, 2004 1116 number of improvements that were included in later versions of this 1117 document. 1119 9. References 1121 9.1 Normative References 1123 [RFC2401] S. Kent, R. Atkinson, Security Architecture for the 1124 Internet Protocol, November 1998. 1126 [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet 1127 Security Association and Key Management Protocol, November 1998. 1129 9.2 Informative References 1131 [ACLNM] J. Arkko, et. al., MIKEY: Multimedia Internet KEYing, draft- 1132 ietf-msec-mikey-08.txt, December, 2003. Work in Progress. 1134 [BCCR] M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, MESP: A 1135 Multicast Framework for the IPsec ESP, draft-ietf-msec-mesp-01.txt. 1136 October 2002. Work in Progress. 1138 [BCDL] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, Group Key 1139 Management Architecture, draft-ietf-msec-gkmarch-06.txt. September 1140 08, 2003. Work in Progress. 1142 [BMS] D. Balenson, D. McGrew, A. Sherman, Key Management for Large 1143 Dynamic Groups: One-Way Function Trees and Amortized Initialization, 1144 http://www.securemulticast.org/draft-balenson-groupkeymgmt-oft- 1145 00.txt, February 1999, Work in Progress. 1147 [CCPRRS] Canetti, R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi 1148 P., Saha D., "An IPSec-based Host Architecture for Secure Internet 1149 Multicast", 1150 http://www.isoc.org/isoc/conferences/ndss/2000/proceedings/028.pdf, 1151 NDSS 2000. 1153 [Din] Dinsmore, P., Balenson, D., Heyman, M., Kruus, P., Scace, C., 1154 and Sherman, A., "Policy-Based Security Management for Large Dynamic 1155 Groups: An Overview of the DCCM Project," DARPA Information 1156 Survivability Conference and Exposition, 1157 http://download.nai.com/products/media/nai/doc/discex-110199.doc. 1159 [GSAKMP] H. Harney, et. al., GSAKMP. draft-ietf-msec-gsakmp-sec- 1160 04.txt. October 2003. Work in Progress. 1162 [Har1] Harney, H., and Muckenhirn, C., "Group Key Management 1163 Protocol (GKMP) Specification," RFC 2093, July 1997. 1165 [Har2] Harney, H., and Muckenhirn, C., "Group Key Management 1166 Protocol (GKMP) Architecture," RFC 2094, July 1997. 1168 The Multicast Group Security Architecture January, 2004 1170 [McD] McDaniel, P., Honeyman, P., and Prakash, A., "Antigone: 1171 A Flexible Framework for Secure Group Communication," Proceedings of 1172 the Eight USENIX Security Symposium, pp 99-113, August, 1999. 1174 [PCW] A. Perrig, R. Canetti, B. Whillock, TESLA: Multicast Source 1175 Authentication Transform Specification. draft-ietf-msec-tesla-spec- 1176 00.txt. IETF, October 2002. Work in Progress. 1178 [RFC2362] Estrin, D., et. al., Protocol Independent Multicast-Sparse 1179 Mode (PIM-SM): Protocol Specification, RFC 2362, June, 1998. 1181 [RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload 1182 (ESP), RFC 2406, November 1998. 1184 [RFC2406bis] S. Kent, IP Encapsulating Security Payload (ESP), 1185 draft-ietf-ipsec-esp-v3-04.txt, March 2003. Work In Progress. 1187 [RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), 1188 November, 1998. 1190 [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for 1191 Multicast: Issues and Architectures, RFC 2627, September 1998. 1193 [RFC2663] P. Srisuresh, M. Holdrege, IP Network Address Translator 1194 (NAT) Terminology and Considerations, RFC 2663, August 1999. 1196 [RFC2748] D. Durham, et. al., The COPS (Common Open Policy Service) 1197 Protocol, RFC 2748, January, 2000. 1199 [RFC3019] B. Haberman, Worzella, R., IP Version 6 Management 1200 Information Base for The Multicast Listener Discovery Protocol, RFC 1201 3019, January, 2001. 1203 [RFC3376] B. Cain, et. al., Internet Group Management Protocol, 1204 Version 3, RFC 3376, October, 2002. 1206 [RFC3453] M. Luby, et. al., The Use of Forward Error Correction 1207 (FEC) in Reliable Multicast, RFC 3453, December 2002. 1209 [RFC3547] M. Baugher, B. Weis, T. Hardjono, H. Harney, , The Group 1210 Domain of Interpretation, RFC 3547, December 2002. 1212 [STW] M. Steiner, Tsudik, G., Waidner, M., CLIQUES: A New Approach to 1213 Group key Agreement, IEEE ICDCS'98 , May 1998. 1215 The Multicast Group Security Architecture January, 2004 1217 Authors Addresses 1219 Thomas Hardjono 1220 VeriSign 1221 487 E. Middlefield Rd. 1222 Mountain View, CA 94043, USA 1224 Phone:(650) 426-3204 1225 EMail: thardjono@verisign.com 1227 Brian Weis 1228 Cisco Systems 1229 170 W. Tasman Drive, 1230 San Jose, CA 95134-1706, USA 1232 Phone: (408) 526-4796 1233 EMail: bew@cisco.com 1235 Full Copyright Statement 1237 Copyright (C) The Internet Society (2003). All Rights Reserved. 1239 This document and translations of it may be copied and furnished to 1240 others, and derivative works that comment on or otherwise explain it 1241 or assist in its implementation may be prepared, copied, published 1242 and distributed, in whole or in part, without restriction of any 1243 kind, provided that the above copyright notice and this paragraph 1244 are included on all such copies and derivative works. However, this 1245 document itself may not be modified in any way, such as by removing 1246 the copyright notice or references to the Internet Society or other 1247 Internet organizations, except as needed for the purpose of 1248 developing Internet standards in which case the procedures for 1249 copyrights defined in the Internet Standards process must be 1250 followed, or as required to translate it into languages other than 1251 English. 1253 The limited permissions granted above are perpetual and will not be 1254 revoked by the Internet Society or its successors or assigns. 1256 This document and the information contained herein is provided on an 1257 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1258 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1259 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1260 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1261 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1263 Acknowledgement 1265 Funding for the RFC Editor function is currently provided by the 1266 Internet Society.