summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3740.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3740.txt')
-rw-r--r--doc/rfc/rfc3740.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc3740.txt b/doc/rfc/rfc3740.txt
new file mode 100644
index 0000000..91da4d4
--- /dev/null
+++ b/doc/rfc/rfc3740.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group T. Hardjono
+Request for Comments: 3740 Verisign
+Category: Informational B. Weis
+ Cisco
+ March 2004
+
+
+ The Multicast Group Security Architecture
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document provides an overview and rationale of the multicast
+ security architecture used to secure data packets of large multicast
+ groups. The document begins by introducing a Multicast Security
+ Reference Framework, and proceeds to identify the security services
+ that may be part of a secure multicast solution.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.2. Summary of Contents of Document. . . . . . . . . . . . . 3
+ 1.3. Audience . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.4. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Architectural Design: The Multicast Security Reference
+ Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1. The Reference Framework. . . . . . . . . . . . . . . . . 4
+ 2.2. Elements of the Centralized Reference Framework. . . . . 5
+ 2.2.1. Group Controller and Key Server. . . . . . . . . 6
+ 2.2.2. Sender and Receiver. . . . . . . . . . . . . . . 7
+ 2.2.3. Policy Server. . . . . . . . . . . . . . . . . . 7
+ 2.3. Elements of the Distributed Reference Framework. . . . . 8
+ 3. Functional Areas . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 9
+ 3.2. Group Key Management . . . . . . . . . . . . . . . . . . 10
+ 3.3. Multicast Security Policies. . . . . . . . . . . . . . . 11
+ 4. Group Security Associations (GSA). . . . . . . . . . . . . . . 12
+ 4.1. The Security Association . . . . . . . . . . . . . . . . 12
+
+
+
+Hardjono & Weis Informational [Page 1]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ 4.2. Structure of a GSA: Introduction . . . . . . . . . . . . 13
+ 4.3. Structure of a GSA: Reasoning. . . . . . . . . . . . . . 14
+ 4.4. Definition of GSA. . . . . . . . . . . . . . . . . . . . 15
+ 4.5. Typical Compositions of a GSA. . . . . . . . . . . . . . 17
+ 5. Security Services. . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.1. Multicast Data Confidentiality . . . . . . . . . . . . . 18
+ 5.2. Multicast Source Authentication and Data Integrity . . . 18
+ 5.3. Multicast Group Authentication . . . . . . . . . . . . . 19
+ 5.4. Multicast Group Membership Management. . . . . . . . . . 19
+ 5.5. Multicast Key Management . . . . . . . . . . . . . . . . 20
+ 5.6. Multicast Policy Management. . . . . . . . . . . . . . . 21
+ 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
+ 6.1. Multicast Data Handling. . . . . . . . . . . . . . . . . 22
+ 6.2. Group Key Management . . . . . . . . . . . . . . . . . . 22
+ 6.3. Multicast Security Policies. . . . . . . . . . . . . . . 22
+ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 23
+ 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
+ 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
+
+1. Introduction
+
+ Securing IP multicast group communication is a complex task that
+ involves many aspects. Consequently, a secure IP multicast protocol
+ suite must have a number of functional areas that address different
+ aspects of the solution. This document describes those functional
+ areas and how they are related.
+
+1.1. Scope
+
+ This architecture is concerned with the securing of large multicast
+ groups. Whereas it can also be used for smaller groups, it is not
+ necessarily the most efficient means. Other architectures (e.g., the
+ Cliques architecture [STW]) can be more efficient for small ad-hoc
+ group communication.
+
+ This architecture is "end to end", and does not require multicast
+ routing protocols (e.g., PIM [RFC2362]) to participate in this
+ architecture. Inappropriate routing may cause denial of service to
+ application layer groups conforming to this architecture. However
+ the routing cannot affect the authenticity or secrecy of group data
+ or management packets. The multicast routing protocols could
+ themselves use this architecture to protect their own multicast and
+ group packets. However, this would be independent of any secure
+ application layer group.
+
+
+
+
+Hardjono & Weis Informational [Page 2]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ This architecture does not require IP multicast admission control
+ protocols (e.g., IGMP [RFC3376], MLD [RFC3019]) to be a part of
+ secure multicast groups. As such, a "join" or "leave" operation for
+ a secure group is independent of a "join" or "leave" of an IP
+ multicast group. For example, the process of joining a secure group
+ requires being authenticated and authorized by a security device,
+ while the process of joining an IP multicast group entails contacting
+ a multicast-aware router. Admission control protocols could
+ themselves use this architecture to protect their own multicast
+ packets. However, this would be independent of any secure
+ application layer group.
+
+ This architecture does not explicitly describe how secure multicast
+ groups deal with Network Address Translation (NAT) [RFC2663].
+ Multicast routing protocols generally require the source and
+ destination addresses and ports of an IP multicast packet to remain
+ unchanged. This allows consistent multicast distribution trees to be
+ created throughout the network. If NAT is used in a network, then
+ the connectivity of senders and receivers may be adversely affected.
+ This situation is neither improved or degraded as a result of
+ deploying this architecture.
+
+ This architecture does not require the use of reliable mechanisms,
+ for either data or management protocols. The use of reliable
+ multicast routing techniques (e.g., FEC [RFC3453]) enhance the
+ availability of secure multicast groups. However the authenticity or
+ secrecy of group data or management packets is not affected by the
+ omission of that capability from a deployment.
+
+1.2. Summary of Contents of Document
+
+ This document provides an architectural overview that outlines the
+ security services required to secure large multicast groups. It
+ provides a Reference Framework for organizing the various elements
+ within the architecture, and explains the elements of the Reference
+ Framework.
+
+ The Reference Framework organizes the elements of the architecture
+ along three Functional Areas pertaining to security. These elements
+ cover the treatment of data when it is to be sent to a group, the
+ management of keying material used to protect the data, and the
+ policies governing a group.
+
+ Another important item in this document is the definition and
+ explanation of Group Security Associations (GSA), which is the
+ multicast counterpart of the unicast Security Association (SA). The
+ GSA is specific to multicast security, and is the foundation of the
+ work on group key management.
+
+
+
+Hardjono & Weis Informational [Page 3]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+1.3. Audience
+
+ This document is addressed to the technical community, implementers
+ of IP multicast security technology, and others interested in gaining
+ a general background understanding of multicast security. This
+ document assumes that the reader is familiar with the Internet
+ Protocol, the IPsec suite of protocols (e.g., [RFC2401]), related
+ networking technology, and general security terms and concepts.
+
+1.4. Terminology
+
+ The following key terms are used throughout this document.
+
+ 1-to-N
+
+ A group which has one sender and many receivers.
+
+ Group Security Association (GSA)
+
+ A bundling of Security Associations (SAs) that together define how
+ a group communicates securely. The GSA may include a registration
+ protocol SA, a rekey protocol SA, and one or more data security
+ protocol SAs.
+
+ M-to-N
+
+ A group which has many senders and many receivers, where M and N
+ are not necessarily the same value.
+
+ Security Association (SA)
+
+ A set of policy and cryptographic keys that provide security
+ services to network traffic that matches that policy.
+
+2. Architectural Design: The Multicast Security Reference Framework
+
+ This section considers the complex issues of multicast security in
+ the context of a Reference Framework. This Reference Framework is
+ used to classify functional areas, functional elements, and
+ interfaces. Two designs of the Reference Framework are shown: a
+ centralized design, and a distributed design that extends the
+ centralized design for very large groups.
+
+2.1. The Reference Framework
+
+ The Reference Framework is based on three broad functional areas (as
+ shown in Figure 1). The Reference Framework incorporates the main
+ entities and functions relating to multicast security, and depicts
+
+
+
+Hardjono & Weis Informational [Page 4]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ the inter-relations among them. It also expresses multicast security
+ from the perspective of multicast group types (1-to-N and M-to-N),
+ and classes of protocols (the exchanged messages) needed to secure
+ multicast packets.
+
+ The aim of the Reference Framework is to provide some general context
+ around the functional areas, and the relationships between the
+ functional areas. Note that some issues span more than one
+ functional area. In fact, the framework encourages the precise
+ identification and formulation of issues that involve more than one
+ functional area or those which are difficult to express in terms of a
+ single functional area. An example of such a case is the expression
+ of policies concerning group keys, which involves both the functional
+ areas of group key management and multicast policies.
+
+ When considering the Reference Framework diagrams, it is important to
+ realize that the singular "boxes" in the framework do not necessarily
+ imply a corresponding singular entity implementing a given function.
+ Rather, a box in the framework should be interpreted loosely as
+ pertaining to a given function related to a functional area. Whether
+ that function is in reality implemented as one or more physical
+ entities is dependent on the particular solution. As an example, the
+ box labeled "Key Server" must be interpreted in broad terms as
+ referring to the functions of key management.
+
+ Similarly, the Reference Framework acknowledges that some
+ implementations may in fact merge a number of the "boxes" into a
+ single physical entity. This could be true even across functional
+ areas. For example, an entity in a group could act as both a Group
+ Controller and a Sender to a group.
+
+ The protocols to be standardized are depicted in the Reference
+ Framework diagrams by the arrows that connect the various boxes. See
+ more details in Section 4, below.
+
+2.2. Elements of the Centralized Reference Framework
+
+ The Reference Framework diagram of Figure 1 contains boxes and
+ arrows. The boxes are the functional entities and the arrows are the
+ interfaces between them. Standard protocols are needed for the
+ interfaces, which support the multicast services between the
+ functional entities.
+
+ In some cases, a system implementing the multicast security
+ architecture may not need to implement protocols to account for every
+ interface. Rather, those interfaces may be satisfied through the use
+ of manual configuration, or even omitted if they are not necessary
+ for the application.
+
+
+
+Hardjono & Weis Informational [Page 5]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ There are three sets of functional entities. Each is discussed
+ below.
+
+ +--------------------------------------+
+ | |
+ | |
+ | FUNCTIONAL |
+ | AREAS |
+ | |
+ | +------+ |
+ | Multicast |Policy| |
+ | Security |Server| |
+ | Policies +------+ |
+ | ^ |
+ | | |
+ | | |
+ | v |
+ | +------+ |
+ | Group |Group | |
+ | Key |Ctrl/ |<---------+ |
+ | Management |Key | | |
+ | |Server| V |
+ | +------+ +--------+ |
+ | ^ | | |
+ | | |Receiver| |
+ | | | | |
+ | v +--------+ |
+ | +------+ ^ |
+ | | | | |
+ | Multicast |Sender|----------+ |
+ | Data | | |
+ | Handling | | |
+ | +------+ |
+ | |
+ +--------------------------------------+
+
+ Figure 1: Centralized Multicast Security Reference Framework
+
+2.2.1. Group Controller and Key Server
+
+ The Group Controller and Key Server (GCKS) represent both the entity
+ and functions relating to the issuance and management of
+ cryptographic keys used by a multicast group. The GCKS also conducts
+ user-authentication and authorization checks on the candidate members
+ of the multicast group.
+
+
+
+
+
+
+Hardjono & Weis Informational [Page 6]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ The Key Server (KS) and the Group Controller (GC) have somewhat
+ different functionality and may in principle be regarded as separate
+ entities. Currently the framework regards the two entities as one
+ "box" in order to simplify the design, and in order not to mandate
+ standardization of the protocol between the KS and the GC. It is
+ stressed that the KS and GC need not be co-located. Furthermore,
+ future designs may choose to standardize the protocol between the GC
+ and the KS, without altering other components.
+
+2.2.2. Sender and Receiver
+
+ The Sender is an entity that sends data to the multicast group. In a
+ 1-to-N multicast group only a single sender is authorized to transmit
+ data to the group. In an M-to-N multicast group, two or more group
+ members are authorized to be senders. In some groups all members are
+ authorized as senders.
+
+ Both Sender and Receiver must interact with the GCKS entity for the
+ purpose of key management. This includes user and/or device
+ authentication, user and/or device authorization, the obtaining of
+ keying material in accordance with some key management policies for
+ the group, obtaining new keys during key-updates, and obtaining other
+ messages relating to the management of keying material and security
+ parameters.
+
+ Senders and Receivers may receive much of their policy from the GCKS
+ entities. The event of joining a multicast group is typically
+ coupled with the Sender/Receiver obtaining keying material from a
+ GCKS entity. This does not preclude the direct interaction between
+ the Sender/Receiver and the Policy Server.
+
+2.2.3. Policy Server
+
+ The Policy Server represents both the entity and functions used to
+ create and manage security policies specific to a multicast group.
+ The Policy Server interacts with the GCKS entity in order to install
+ and manage the security policies related to the membership of a given
+ multicast group and those related to keying material for a multicast
+ group.
+
+ The interactions between the Policy Server and other entities in the
+ Reference Framework is dependent to a large extent on the security
+ circumstances being addressed by a given policy.
+
+
+
+
+
+
+
+
+Hardjono & Weis Informational [Page 7]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+2.3. Elements of the Distributed Reference Framework
+
+ The need for solutions to be scalable to large groups across wide
+ geographic regions of the Internet requires the elements of the
+ framework to also function as a distributed system. Figure 2 shows
+ how distributed designs supporting large group scalability fit into
+ the Reference Framework.
+
+ +-----------------------------------------------------------------+
+ | |
+ | |
+ | FUNCTIONAL |
+ | AREAS |
+ | +------+ +------+ |
+ | Multicast |Policy|<-------------------------------->|Policy| |
+ | Security |Server| |Server| |
+ | Policies +------+ +------+ |
+ | ^ ^ |
+ | | | |
+ | | | |
+ | v v |
+ | +------+ +------+ |
+ | Group |Group |<-------------------------------> |Group | |
+ | Key |Ctrl/ |<---------+ |Ctlr/ | |
+ | Management |Key | | |Key | |
+ | |Server| V |Server| |
+ | +------+ +--------+ +------+ |
+ | ^ | | ^ |
+ | | |Receiver| | |
+ | | | | | |
+ | v +--------+ | |
+ | +------+ ^ V |
+ | | | | +--------+ |
+ | Multicast |Sender|----------+ | | |
+ | Data | |-------------------------------->|Receiver| |
+ | Handling | | | | |
+ | +------+ +--------+ |
+ +-----------------------------------------------------------------+
+
+ Figure 2: Distributed Multicast Security Reference Framework
+
+ In a distributed design the GCKS entity interacts with other GCKS
+ entities to achieve scalability in the key management related
+ services. GCKS entities will require a means of authenticating their
+ peer GCKS entities, a means of authorization, and a means of
+ interacting securely to pass keys and policy.
+
+
+
+
+
+Hardjono & Weis Informational [Page 8]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ Similarly, Policy Servers must interact with each other securely to
+ allow the communication and enforcement of policies across the
+ Internet.
+
+ Two Receiver boxes are displayed corresponding to the situation where
+ both the Sender and Receiver employ the same GCKS entity (centralized
+ architecture) and where the Sender and Receiver employ different GCKS
+ entities (distributed architecture). In the distributed design, all
+ Receivers must obtain identical keys and policy. Each member of a
+ multicast group may interact with a primary GCKS entity (e.g., the
+ "nearest" GCKS entity, measured in terms of a well-defined and
+ consistent metric). Similarly, a GCKS entity may interact with one
+ or more Policy Servers, also arranged in a distributed architecture.
+
+3. Functional Areas
+
+ The Reference Framework identifies three functional areas. They are:
+
+ - Multicast data handling. This area covers the security-related
+ treatments of multicast data by the sender and the receiver.
+ This functional area is further discussed in Section 3.1.
+
+ - Group Key Management. This area is concerned with the secure
+ distribution and refreshment of keying material. This
+ functional area is further discussed in Section 3.2.
+
+ - Multicast Security Policies. This area covers aspects of
+ policy in the context of multicast security, taking into
+ consideration the fact that policies may be expressed in
+ different ways: that they may exist at different levels in a
+ given multicast security architecture, and that they may be
+ interpreted differently according to the context in which they
+ are specified and implemented. This functional area is further
+ discussed in Section 3.3.
+
+3.1. Multicast Data Handling
+
+ In a secure multicast group, the data typically needs to be:
+
+ 1. Encrypted using the group key, mainly for access control and
+ possibly also for confidentiality.
+ 2. Authenticated, for verifying the source and integrity of the
+ data. Authentication takes two flavors:
+ a. Source authentication and data integrity. This
+ functionality guarantees that the data originated with the
+ claimed source and was not modified en route (either by a
+ group member or an external attacker).
+
+
+
+
+Hardjono & Weis Informational [Page 9]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ b. Group authentication. This type of authentication only
+ guarantees that the data was generated (or last modified) by
+ some group member. It does not guarantee data integrity
+ unless all group members are trusted.
+
+ While multicast encryption and group authentication are fairly
+ standard and similar to encrypting and authenticating a point-to-
+ point communication, source authentication for multicast is
+ considerably more involved. Consequently, off-the-shelf solutions
+ (e.g., taken from IPsec [RFC2406]) may be sufficient for encryption
+ and group authentication. For source authentication, however,
+ special-purpose transformations are necessary. See [CCPRRS] for
+ further elaboration on the concerns regarding the data transforms.
+
+ Multicast data encrypted and/or authenticated by a sender should be
+ handled the same way by both centralized and distributed receivers,
+ (as shown in Figure 2).
+
+ The "Multicast Encapsulating Security Payload" [BCCR] provides the
+ definition for Multicast ESP for data traffic. The "Multicast Source
+ Authentication Transform Specification" [PCW] defines the use of the
+ TESLA algorithm for source authentication in multicast.
+
+3.2. Group Key Management
+
+ The term "keying material" refers to the cryptographic keys belonging
+ to a group, the state associated with the keys, and the other
+ security parameters related to the keys. Hence, the management of
+ the cryptographic keys belonging to a group necessarily requires the
+ management of their associated state and parameters. A number of
+ solutions for specific issues must be addressed. These may include
+ the following:
+
+ - Methods for member identification and authentication.
+ - Methods to verify the membership to groups.
+ - Methods to establish a secure channel between a GCKS entity and
+ the member, for the purpose of delivery of shorter-term keying
+ material pertaining to a group.
+ - Methods to establish a long-term secure channel between one GCKS
+ entity and another, for the purpose of distributing shorter-term
+ keying material pertaining to a group.
+ - Methods to effect the changing of keys and keying material.
+ - Methods to detect and signal failures and perceived compromises to
+ keys and keying material.
+
+ The requirements related to the management of keying material must be
+ seen in the context of the policies that prevail within the given
+ circumstance.
+
+
+
+Hardjono & Weis Informational [Page 10]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ Core to the area of key management is Security Association (SA)
+ Management, which will be discussed further below.
+
+ A "Group Key Management Architecture" document [BCDL] further defines
+ the key management architecture for multicast security. It builds on
+ the Group Security Association (GSA) concept, and further defines the
+ roles of the Key Server and Group Controller.
+
+ "The Group Domain of Interpretation" [RFC3547], "GSAKMP" [GSAKMP],
+ and "MIKEY" [ACLNM] are three instances of protocols implementing the
+ group key management function.
+
+3.3. Multicast Security Policies
+
+ Multicast Security Policies must provide the rules for operation for
+ the other elements of the Reference Framework. Security Policies may
+ be distributed in an ad-hoc fashion in some instances. However,
+ better coordination and higher levels of assurance are achieved if a
+ Policy Controller distributes Security Policies policy to the group.
+
+ Multicast security policies must represent, or contain, more
+ information than a traditional peer-to-peer policy. In addition to
+ representing the security mechanisms for the group communication, the
+ policy must also represent the rules for the governance of the secure
+ group. For example, policy would specify the authorization level
+ necessary in order for an entity to join a group. More advanced
+ operations would include the conditions when a group member must be
+ forcibly removed from the group, and what to do if the group members
+ need to resynchronize because of lost key management messages.
+
+ The application of policy at the Group Controller element and the
+ member (sender and receiver) elements must be described. While there
+ is already a basis for security policy management in the IETF,
+ multicast security policy management extends the concepts developed
+ for unicast communication in the areas of:
+
+ - Policy creation,
+ - High-level policy translation, and
+ - Policy representation.
+
+ Examples of work in multicast security policies include the Dynamic
+ Cryptographic Context Management project [Din], Group Key Management
+ Protocol [Har1, Har2], and Antigone [McD].
+
+ Policy creation for secure multicast has several more dimensions than
+ the single administrator specified policy assumed in the existing
+ unicast policy frameworks. Secure multicast groups are usually large
+ and by their very nature extend over several administrative domains,
+
+
+
+Hardjono & Weis Informational [Page 11]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ if not spanning a different domain for each user. There are several
+ methods that need to be considered in the creation of a single,
+ coherent group security policy. They include a top-down
+ specification of the group policy from the group initiator and
+ negotiation of the policy between the group members (or prospective
+ members). Negotiation can be as simple as a strict intersection of
+ the policies of the members or extremely complicated using weighted
+ voting systems.
+
+ The translation of policy rules from one data model to another is
+ much more difficult in a multicast group environment. This is
+ especially true when group membership spans multiple administrative
+ domains. Policies specified at a high level with a Policy Management
+ tool must be translated into more precise rules that the available
+ security policy mechanisms can both understand and implement. When
+ dealing with multicast communication and its multiple participants,
+ it is essential that the individual translation performed for each
+ participant result in the use of a mechanism that is interoperable
+ with the results of all of the other translations. Typically, the
+ translation from high-level policy to specific policy objects must
+ result in the same objects in order to achieve communication between
+ all of the group members. The requirement that policy translation
+ results in the same objects places constraints on the use and
+ representations in the high-level policies.
+
+ It is also important that policy negotiation and translation be
+ performed as an integral part of joining a group. Adding a member to
+ a group is meaningless if they will not be able to participate in the
+ group communications.
+
+4. Group Security Associations (GSA)
+
+4.1. The Security Association
+
+ A security association is a commonly used term in cryptographic
+ systems (e.g., [RFC2401, RFC2406bis, RFC2409]). This document uses
+ the term to mean any set of policy and cryptographic keys that
+ provide security services for the network traffic matching that
+ policy. A Security Association usually contains the following
+ attributes:
+
+ - selectors, such as source and destination transport addresses.
+ - properties, such as an security parameter index (SPI) or cookie
+ pair, and identities.
+ - cryptographic policy, such as the algorithms, modes, key
+ lifetimes, and key lengths used for authentication or
+ confidentiality.
+ - keys, such as authentication, encryption and signing keys.
+
+
+
+Hardjono & Weis Informational [Page 12]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ Group key management uses a different set of abstractions than
+ point-to-point key management systems (such as IKE [RFC2409]).
+ Notwithstanding, the abstractions used in the Group Key Management
+ functional area may be built from the point-to-point key management
+ abstractions.
+
+4.2. Structure of a GSA: Introduction
+
+ Security associations (SAs) for group key management are more
+ complex, and are usually more numerous, than for point-to-point key
+ management algorithms. The latter establishes a key management SA to
+ protect application SAs (usually one or two, depending on the
+ protocol). However, group key management may require up to three or
+ more SAs. These SAs are described in later sections.
+
+ A GSA contains all of the SA attributes identified in the previous
+ section, as well some additional attributes pertaining to the group.
+ As shown in Figure 3, the GSA builds on the SA in two distinct ways.
+
+ - First, the GSA is a superset of an SA (Figure 3(a)). A GSA has
+ group policy attributes. For example, the kind of signed
+ credentials needed for group membership, whether group members
+ will be given new keys when a member is added (called "backward
+ re-key" below), or whether group members will be given new keys
+ when a member is removed from the group ("forward re-key"). A GSA
+ also includes an SA as an attribute of itself.
+
+ - Second, the GSA is an aggregation of SAs (Figure 3(b)). A GSA is
+ comprised of multiple SAs, and these SAs may be used for several
+ independent purposes.
+
+ +---------------+ +-------------------+
+ | GSA | | GSA |
+ | | | +-----+ +-----+ |
+ | | | | SA1 | | SA2 | |
+ | +----+ | | +-----+ +-----+ |
+ | | SA | | | +-----+ |
+ | +----+ | | | SA3 | |
+ | | | +-----+ |
+ +---------------+ +-------------------+
+
+ (a) superset (b) aggregation
+
+ Figure 3: Relationship of GSA to SA
+
+
+
+
+
+
+
+Hardjono & Weis Informational [Page 13]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+4.3. Structure of a GSA: Reasoning
+
+ Figure 4 shows three categories of SAs that can be aggregated into a
+ GSA.
+
+ +------------------------------------------------------------+
+ | |
+ | +------------------+ |
+ | | GCKS | |
+ | | | |
+ | | REG REG | |
+ | | / REKEY \ | |
+ | +---/-----|----\---+ |
+ | / | \ |
+ | / | \ |
+ | / | \ |
+ | / | \ |
+ | / | \ |
+ | +----------/------+ | +------\----------+ |
+ | | REG | | | REG | |
+ | | REKEY-----+----REKEY | |
+ | | Sender | | Receiver | |
+ | | DATA----------DATA | |
+ | +-----------------+ +-----------------+ |
+ | |
+ | |
+ +------------------------------------------------------------+
+
+ Figure 4: GSA Structure and 3 categories of SAs
+
+ The three categories of SAs are:
+
+ - Registration SA (REG): A separate unicast SA between the GCKS and
+ each group member, regardless of whether the group member is a
+ sender or a receiver or acting in both roles.
+
+ - Re-key SA (REKEY): A single multicast SA between the GCKS and all
+ of the group members.
+
+ - Data Security SA (DATA): A multicast SA between each multicast
+ source speaker and the group's receivers. There may be as many
+ data SAs as there are multicast sources allowed by the group's
+ policy.
+
+ Each of these SAs are defined in more detail in the next section.
+
+
+
+
+
+
+Hardjono & Weis Informational [Page 14]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+4.4. Definition of GSA
+
+ The three categories of SAs correspond to three different kinds of
+ communications commonly required for group communications. This
+ section describes the SAs depicted in Figure 4 in detail.
+
+ - Registration SA (REG):
+ An SA is required for (bi-directional) unicast communications
+ between the GCKS and a group member (be it a Sender or Receiver).
+ This SA is established only between the GCKS and a Member. The
+ GCKS entity is charged with access control to the group keys, with
+ policy distribution to members (or prospective members), and with
+ group key dissemination to Sender and Receiver members. This use
+ of a (unicast) SA as a starting point for key management is common
+ in a number of group key management environments [RFC3547, GSAKMP,
+ CCPRRS, RFC2627, BMS].
+
+ The Registration SA is initiated by the member to pull GSA
+ information from the GCKS. This is how the member requests to
+ join the secure group, or has its GSA keys re-initialized after
+ being disconnected from the group (e.g., when its host computer
+ has been turned off during re-key operations). The GSA
+ information pulled down from the GCKS is related to the other two
+ SAs defined as part of the GSA.
+
+ Note that this (unicast) SA is used to protect the other elements
+ of the GSA. As such, the Registration SA is crucial and is
+ inseparable from the other two SAs in the definition of a GSA.
+
+ However, the requirement of a registration SA does not imply the
+ need of a registration protocol to create that Registration SA.
+ The registration SA could instead be setup through some manual
+ means, such as distributed on a smart card. Thus, what is
+ important is that a Registration SA exists, and is used to protect
+ the other SAs.
+
+ From the perspective of one given GCKS, there are as many unique
+ registration SAs as there are members (Senders and/or Receivers)
+ in the group. This may constitute a scalability concern for some
+ applications. A registration SA may be established on-demand with
+ a short lifetime, whereas re-key and data security SAs are
+ established at least for the life of the sessions that they
+ support.
+
+ Conversely the registration SA could be left in place for the
+ duration of the group lifetime, if scalability is not an issue.
+ Such a long term registration SA would be useful for re-
+ synchronization or deregistration purposes.
+
+
+
+Hardjono & Weis Informational [Page 15]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ - Re-key SA (REKEY):
+ In some cases, a GCKS needs the ability to "push" new SAs as part
+ of the GSA. These new SAs must be sent to all group members. In
+ other cases, the GCKS needs the ability to quickly revoke access
+ to one or more group members. Both of these needs are satisfied
+ with the Re-key SA.
+
+ This Re-key SA is a unidirectional multicast transmission of key
+ management messages from the GCKS to all group members. As such,
+ this SA is known by the GCKS and by all members of the group.
+
+ This SA is not negotiated, since all the group members must share
+ it. Thus, the GCKS must be the authentic source and act as the
+ sole point of contact for the group members to obtain this SA.
+
+ A rekey SA is not absolutely required to be part of a GSA. For
+ example, the lifetime of some groups may be short enough such that
+ a rekey is not necessary. Conversely, the policy for the group
+ could specify multiple rekey SAs of different types. For example,
+ if the GC and KS are separate entities, the GC may deliver rekey
+ messages that adjust the group membership, and the KS may deliver
+ rekey messages with new DATA SAs.
+
+ - Data Security SA (DATA):
+ The Data Security SA protects data between member senders and
+ member receivers.
+
+ One or more SAs are required for the multicast transmission of
+ data-messages from the Sender to other group members. This SA is
+ known by the GCKS and by all members of the group.
+
+ Regardless of the number of instances of this third category of
+ SA, this SA is not negotiated. Rather, all group members obtain
+ it from the GCKS. The GCKS itself does not use this category of
+ SA.
+
+ From the perspective of the Receivers, there is at least one data
+ security SA for the member sender (one or more) in the group. If
+ the group has more than one data security SA, the data security
+ protocol must have a means of differentiating the SAs (e.g., with
+ a SPI).
+
+
+
+
+
+
+
+
+
+
+Hardjono & Weis Informational [Page 16]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ There are a number of possibilities with respect to the number of
+ data security SAs:
+
+ 1. Each sender in the group could be assigned a unique data
+ security SA, thereby resulting in each receiver having to
+ maintain as many data security SAs as there are senders in the
+ group. In this case, each sender may be verified using source
+ origin authentication techniques.
+
+ 2. The entire group deploys a single data security SA for all
+ senders. Receivers would then be able to maintain only one
+ data security SA.
+
+ 3. A combination of 1. and 2.
+
+4.5. Typical Compositions of a GSA
+
+ Depending on the multicast group policy, many compositions of a GSA
+ are possible. For illustrative purposes, this section describes a
+ few possible compositions.
+
+ - A group of memory-constrained members may require only a REG SA,
+ and a single DATA SA.
+ - A "pay-per-session" application, where all of the SA information
+ needed for the session may be distributed over a REG SA. Re-key
+ and re-initialization of DATA SAs may not be necessary, so there
+ is no REKEY SA.
+ - A subscription group, where keying material is changed as
+ membership changes. A REG SA is needed to distribute other SAs; a
+ REKEY SA is needed to re-initialize a DATA SA at the time
+ membership changes.
+
+5. Security Services
+
+ This section identifies security services for designated interfaces
+ of Figure 2. Distinct security services are assigned to specific
+ interfaces. For example, multicast source authentication, data
+ authentication, and confidentiality occur on the multicast data
+ interface between Senders and Receivers in Figure 2. Authentication
+ and confidentiality services may also be needed between the Key
+ Server and group members (i.e., the Senders and Receivers of Figure
+ 2), but the services that are needed for multicast key management may
+ be unicast as well as multicast. A security service in the Multicast
+ Security Reference Framework therefore identifies a specific function
+ along one or more Figure 2 interfaces.
+
+
+
+
+
+
+Hardjono & Weis Informational [Page 17]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ This paper does not attempt to analyze the trust relationships,
+ detailed functional requirements, performance requirements, suitable
+ algorithms, and protocol specifications for IP multicast and
+ application-layer multicast security. Instead, that work will occur
+ as the security services are further defined and realized in
+ algorithms and protocols.
+
+5.1. Multicast Data Confidentiality
+
+ This security service handles the encryption of multicast data at the
+ Sender's end and the decryption at the Receiver's end. This security
+ service may also apply the keying material that is provided by
+ Multicast Key Management in accordance with Multicast Policy
+ Management, but it is independent of both.
+
+ An important part of the Multicast Data Confidentiality security
+ service is in the identification of and motivation for specific
+ ciphers that should be used for multicast data. Obviously, not all
+ ciphers will be suitable for IP multicast and application-layer
+ multicast traffic. Since this traffic will usually be connectionless
+ UDP flows, stream ciphers may be unsuitable, though hybrid
+ stream/block ciphers may have advantages over some block ciphers.
+
+ Regarding application-layer multicast, some consideration is needed
+ to consider the effects of sending encrypted data in a multicast
+ environment lacking admission-control, where practically any
+ application program can join a multicast event independently of its
+ participation in a multicast security protocol. Thus, this security
+ service is also concerned with the effects of multicast
+ confidentiality services (intended and otherwise) on application
+ programs. Effects to both Senders and Receivers are considered.
+
+ In Figure 2, the Multicast Data Confidentiality security service is
+ placed in Multicast Data Handling Area along the interface between
+ Senders and Receivers. The algorithms and protocols that are
+ realized from work on this security service may be applied to other
+ interfaces and areas of Figure 2 when multicast data confidentiality
+ is needed.
+
+5.2. Multicast Source Authentication and Data Integrity
+
+ This security service handles source authentication and integrity
+ verification of multicast data. It includes the transforms to be
+ made both at the Sender's end and at the Receiver's end. It assumes
+ that the appropriate signature and verification keys are provided via
+ Multicast Key Management in accordance with Multicast Policy
+ Management as described below. This is one of the harder areas of
+ multicast security due to the connectionless and real-time
+
+
+
+Hardjono & Weis Informational [Page 18]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ requirements of many IP multicast applications. There are classes of
+ application-layer multicast security, however, where offline source
+ and data authentication will suffice. As discussed previously, not
+ all multicast applications require real-time authentication and
+ data-packet integrity. A robust solution to multicast source and
+ data authentication, however, is necessary for a complete solution to
+ multicast security.
+
+ In Figure 2, the Multicast Source and Data Authentication security
+ service is placed in Multicast Data Handling Area along the interface
+ between Senders and Receivers. The algorithms and protocols that are
+ produced for this functional area may have applicability to security
+ services in other functional area that use multicast services such as
+ Group Key Management.
+
+5.3. Multicast Group Authentication
+
+ This security service provides a limited amount of authenticity of
+ the transmitted data: It only guarantees that the data originated
+ with (or was last modified by) one of the group members. It does not
+ guarantee authenticity of the data in case that other group members
+ are not trusted.
+
+ The advantage of group authentication is that it is guaranteed via
+ relatively simple and efficient cryptographic transforms. Therefore,
+ when source authentication is not paramount, group authentication
+ becomes useful. In addition, performing group authentication is
+ useful even when source authentication is later performed: it
+ provides a simple-to-verify weak integrity check that is useful as a
+ measure against denial-of-service attacks.
+
+ The Multicast Group Authentication security service is placed in the
+ Multicast Data Handling Area along the interface between Senders and
+ Receivers.
+
+5.4. Multicast Group Membership Management
+
+ This security service describes the functionality of registration of
+ members with the Group Controller, and de-registration of members
+ from the Group Controller. These are security functions, which are
+ independent from IP multicast group "join" and "leave" operations
+ that the member may need to perform as a part of group admission
+ control protocols (i.e., IGMP [RFC3376], MLD [RFC3019]).
+
+ Registration includes member authentication, notification and
+ negotiation of security parameters, and logging of information
+ according to the policies of the group controller and the would-be
+
+
+
+
+Hardjono & Weis Informational [Page 19]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ member. (Typically, an out-of-band advertisement of group information
+ would occur before the registration takes place. The registration
+ process will typically be invoked by the would-be member.)
+
+ De-registration may occur either at the initiative of the member or
+ at the initiative of the group controller. It would result in
+ logging of the de-registration event by the group controller and an
+ invocation of the appropriate mechanism for terminating the
+ membership of the de-registering member (see Section 5.5).
+
+ This security service also describes the functionality of the
+ communication related to group membership among different GCKS
+ servers in a distributed group design.
+
+ In Figure 2, the Multicast Group Membership security service is
+ placed in the Group Key Management Area and has interfaces to Senders
+ and Receivers.
+
+5.5. Multicast Key Management
+
+ This security service describes the functionality of distributing and
+ updating the cryptographic keying material throughout the life of the
+ group. Components of this security service may include:
+
+ - GCKS to group member (Sender or Receiver) notification
+ regarding current keying material (e.g., group encryption and
+ authentication keys, auxiliary keys used for group management,
+ keys for source authentication, etc.).
+ - Updating of current keying material, depending on circumstances
+ and policies.
+ - Termination of groups in a secure manner, including the secure
+ group itself and the associated keying material.
+
+ Among the responsibilities of this security service is the secure
+ management of keys between Key Servers and group members, the
+ addressing issues for the multicast distribution of keying material,
+ and the scalability or other performance requirements for multicast
+ key management [RFC2627, BMS]. Key Servers and group members may
+ take advantage of a common Public Key Infrastructure (PKI) for
+ increased scalability of authentication and authorization.
+
+ To allow for an interoperable and secure IP multicast security
+ protocol, this security service may need to specify host abstractions
+ such as a group security association database (GSAD) and a group
+ security policy database (GSPD) for IP multicast security. The
+ degree of overlap between IP multicast and application-layer
+ multicast key management needs to be considered. Thus, this security
+ service takes into account the key management requirements for IP
+
+
+
+Hardjono & Weis Informational [Page 20]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ multicast, the key management requirements for application-layer
+ multicast, and to what degree specific realizations of a Multicast
+ Key Management security service can satisfy both. ISAKMP, moreover,
+ has been designed to be extensible to multicast key management for
+ both IP multicast and application-layer multicast security [RFC2408].
+ Thus, multicast key management protocols may use the existing ISAKMP
+ standard's Phase 1 and Phase 2 protocols, possibly with needed
+ extensions (such as GDOI [RFC3547] or application-layer multicast
+ security).
+
+ This security service also describes the functionality of the
+ communication related to key management among different GCKS servers
+ in a distributed group design.
+
+ Multicast Key Management appears in both the centralized and
+ distributed designs as shown in Figure 2 and is placed in the Group
+ Key Management Area.
+
+5.6. Multicast Policy Management
+
+ This security service handles all matters related to multicast group
+ policy including membership policy and multicast key management
+ policy. Indeed, one of the first tasks in further defining this
+ security service is identifying the different areas of multicast
+ policy. Multicast Policy Management includes the design of the
+ policy server for multicast security, the particular policy
+ definitions that will be used for IP multicast and application-layer
+ multicast security, and the communication protocols between the
+ Policy Server and the Key Server. This security service may be
+ realized using a standard policy infrastructure such as a Policy
+ Decision Point (PDP) and Policy Enforcement Point (PEP) architecture
+ [RFC2748]. Thus, it may not be necessary to re-invent a separate
+ architecture for multicast security policy. At minimum, however,
+ this security service will be realized in a set of policy
+ definitions, such as multicast security conditions and actions.
+
+ The Multicast Policy Management security service describes the
+ functionality of the communication between an instance of a GCKS to
+ an instance of the Policy Server. The information transmitted may
+ include policies concerning groups, memberships, keying material
+ definition and their permissible uses, and other information. This
+ security service also describes communication between and among
+ Policy Servers. Group members are not expected to directly
+ participate in this security service. However, this option is not
+ ruled out.
+
+
+
+
+
+
+Hardjono & Weis Informational [Page 21]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+6. Security Considerations
+
+ This document describes an architectural framework for protecting
+ multicast and group traffic with cryptographic protocols. Three
+ functional areas are identified within the framework. Each
+ functional area has unique security considerations, and these are
+ discussed below.
+
+ This architectural framework is end-to-end, and does not rely upon
+ the network that connects group controllers and group members. It
+ also does not attempt to resolve security issues in the unicast or
+ multicast routing infrastructures, or in multicast admission control
+ protocols. As such, denial of service, message deletion, and other
+ active attacks against the unicast or multicast routing
+ infrastructures are not addressed by this framework. Section 1.1
+ describes the relationship of the network infrastructure to the
+ multicast group security architecture.
+
+6.1. Multicast Data Handling
+
+ Cryptographic protocols protecting multicast data are responsible for
+ providing confidentiality and group authentication. They should also
+ be able to provide source authentication to uniquely identify senders
+ to the group. Replay protection of multicast data is also desirable,
+ but may not always be possible. This is due to the complexity of
+ maintaining replay protection state for multiple senders. Section
+ 3.1 elaborates on the security requirements for this area.
+
+6.2. Group Key Management
+
+ Group key management protocols provide cryptographic keys and policy
+ to group members. They are responsible for authenticating and
+ authorizing group members before revealing those keys, and for
+ providing confidentiality and authentication of those keys during
+ transit. They are also responsible for providing a means for
+ rekeying the group, in the case that the policy specifies a lifetime
+ for the keys. They also are responsible for revocation of group
+ membership, once one or more group members have had their
+ authorization to be a group member revoked. Section 3.2 describes
+ the security requirements of this area in more detail.
+
+6.3. Multicast Security Policies
+
+ Cryptographic protocols providing multicast security policies are
+ responsible for distributing that policy such that the integrity of
+ the policy is maintained. If the policy itself is confidential, they
+ also are responsible for authenticating group controllers and group
+ members, and providing confidentiality of the policy during transit.
+
+
+
+Hardjono & Weis Informational [Page 22]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+7. Acknowledgements
+
+ Much of the text in this document was derived from two research
+ papers. The framework for this document came from a paper co-
+ authored by Thomas Hardjono, Ran Canetti, Mark Baugher, and Pete
+ Dinsmore. Description of the GSA came from a document co-authored by
+ Hugh Harney, Mark Baugher, and Thomas Hardjono. George Gross
+ suggested a number of improvements that were included in later
+ versions of this document.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+ [RFC2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner,
+ "Internet Security Association and Key Management
+ Protocol", RFC 2408, November 1998.
+
+8.2. Informative References
+
+ [ACLNM] J. Arkko, et. al., "MIKEY: Multimedia Internet KEYing",
+ Work in Progress, December 2003.
+
+ [BCCR] M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, "MESP: A
+ Multicast Framework for the IPsec ESP", Work in
+ Progress, October 2002.
+
+ [BCDL] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Group
+ Key Management Architecture", Work in Progress,
+ September 2003.
+
+ [BMS] D. Balenson, D. McGrew, A. Sherman, Key Management for
+ Large Dynamic Groups: One-Way Function Trees and
+ Amortized Initialization,
+ http://www.securemulticast.org/draft-balenson-
+ groupkeymgmt-oft-00.txt, Work in Progress, February
+ 1999.
+
+ [CCPRRS] Canetti, R., Cheng P. C., Pendarakis D., Rao, J.,
+ Rohatgi P., Saha D., "An IPSec-based Host Architecture
+ for Secure Internet Multicast",
+ http://www.isoc.org/isoc/conferences/ndss/2000/
+ proceedings/028.pdf, NDSS 2000.
+
+
+
+
+
+Hardjono & Weis Informational [Page 23]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ [Din] Dinsmore, P., Balenson, D., Heyman, M., Kruus, P.,
+ Scace, C., and Sherman, A., "Policy-Based Security
+ Management for Large Dynamic Groups: An Overview of the
+ DCCM Project," DARPA Information Survivability
+ Conference and Exposition,
+ http://download.nai.com/products/media/nai/doc/discex-
+ 110199.doc.
+
+ [GSAKMP] H. Harney, et. al., "GSAKMP", Work in Progress, October
+ 2003.
+
+ [Har1] Harney, H. and C. Muckenhirn, "Group Key Management
+ Protocol (GKMP) Specification", RFC 2093, July 1997.
+
+ [Har2] Harney, H. and C. Muckenhirn, "Group Key Management
+ Protocol (GKMP) Architecture", RFC 2094, July 1997.
+
+ [McD] McDaniel, P., Honeyman, P., and Prakash, A., "Antigone:
+ A Flexible Framework for Secure Group Communication,"
+ Proceedings of the Eight USENIX Security Symposium, pp
+ 99-113, August, 1999.
+
+ [PCW] Perrig, A., Canetti, R. and B. Whillock, TESLA:
+ Multicast Source Authentication Transform
+ Specification", Work in Progress, October 2002.
+
+ [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D.,
+ Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma,
+ P. and L. Wei, "Protocol Independent Multicast-Sparse
+ Mode (PIM-SM): Protocol Specification", RFC 2362, June
+ 1998.
+
+ [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
+ Payload (ESP)", RFC 2406, November 1998.
+
+ [RFC2406bis] Kent, S., "IP Encapsulating Security Payload (ESP)",
+ Work in Progress, March 2003.
+
+ [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+ [RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for
+ Multicast: Issues and Architectures", RFC 2627,
+ September 1998.
+
+ [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations", RFC
+ 2663, August 1999.
+
+
+
+Hardjono & Weis Informational [Page 24]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+ [RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzong, S.,
+ Rajan, R. and A. Sastry, "COPS (Common Open Policy
+ Service) Protocol", RFC 2748, January 2000.
+
+ [RFC3019] Haberman, B. and R. Worzella, "IP Version 6 Management
+ Information Base for The Multicast Listener Discovery
+ Protocol", RFC 3019, January 2001.
+
+ [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
+ Thyagarajan, "Internet Group Management Protocol,
+ Version 3", RFC 3376, October 2002.
+
+ [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, M., Handley,
+ M. and J. Crowcroft, "The Use of Forward Error
+ Correction (FEC) in Reliable Multicast", RFC 3453,
+ December 2002.
+
+ [RFC3547] Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
+ Group Domain of Interpretation", RFC 3547, December
+ 2002.
+
+ [STW] M., Steiner, Tsudik, G., Waidner, M., CLIQUES: A New
+ Approach to Group key Agreement, IEEE ICDCS'98 , May
+ 1998.
+
+9. Authors' Addresses
+
+ Thomas Hardjono
+ VeriSign
+ 487 E. Middlefield Rd.
+ Mountain View, CA 94043, USA
+
+ Phone:(650) 426-3204
+ EMail: thardjono@verisign.com
+
+
+ Brian Weis
+ Cisco Systems
+ 170 W. Tasman Drive,
+ San Jose, CA 95134-1706, USA
+
+ Phone: (408) 526-4796
+ EMail: bew@cisco.com
+
+
+
+
+
+
+
+
+Hardjono & Weis Informational [Page 25]
+
+RFC 3740 Multicast Group Security Architecture March 2004
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Hardjono & Weis Informational [Page 26]
+