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

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/