draft-ietf-msec-arch-00.txt   draft-ietf-msec-arch-01.txt 
Internet Engineering Task Force Thomas Hardjono (VeriSign) Internet Engineering Task Force Thomas Hardjono (VeriSign)
INTERNET-DRAFT Brian Weis (Cisco) INTERNET-DRAFT Brian Weis (Cisco)
draft-ietf-msec-arch-00.txt Expires May 2003 draft-ietf-msec-arch-01.txt Expires November 2003
November 2002 May 2003
The Multicast Security (MSEC) Architecture The Multicast Security Architecture
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 32 skipping to change at line 32
Drafts as reference material or to cite them other than as Drafts as reference material or to cite them other than as
"work in progress." "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document provides a foundation for the protocols developed by This document provides an overview and rationale of the multicast
the Multicast Security (MSEC) group. The document begins by security architecture used for large multicast groups. The document
introducing a Reference Framework, and proceeds to identify begins by introducing a Multicast Security Reference Framework, and
functional areas which must be addressed as part of a secure proceeds to identify the security services may be part of a secure
multicast solution. multicast solution.
Hardjono, Weis Expires May, 2003 1 Hardjono, Weis Expires November, 2003 1
MSEC Architecture October, 2002 MSEC Architecture May, 2003
Table of Contents Table of Contents
1. Introduction.......................................................2 1. Introduction.......................................................2
1.1 Summary of Contents of Document.................................2 1.1 Summary of Contents of Document.................................3
1.2 Audience........................................................3 1.2 Audience........................................................3
1.3 Related Documents...............................................3 1.3 Terminology.....................................................3
2. Architectural Design: The MSEC Reference Framework.................4 2. Architectural Design: The Multicast Security Reference Framework...4
2.1 A Reference Framework...........................................4 2.1 The Reference Framework.........................................4
2.2 Elements of the Reference Framework.............................5 2.2 Elements of the Reference Framework.............................5
2.2.1 Group Controller and Key Server.............................5 2.2.1 Group Controller and Key Server.............................6
2.2.2 Sender and Receiver.........................................6 2.2.2 Sender and Receiver.........................................6
2.2.3 Policy Server...............................................6 2.2.3 Policy Server...............................................7
2.2.4 Centralized and Distributed Designs.........................7 2.2.4 Centralized and Distributed Designs.........................7
3. Functional Areas...................................................7 3. Functional Areas...................................................7
3.1 Multicast Data..................................................7 3.1 Multicast Data..................................................8
3.2 Management of Keying Material...................................8 3.2 Management of Keying Material...................................8
3.3 Multicast Security Policies.....................................8 3.3 Multicast Security Policies.....................................9
4. Group Security Associations (GSA).................................10 4. Group Security Associations (GSA).................................10
4.1 SAs and Multicast..............................................10 4.2 Structure of a GSA: Introduction...............................11
4.1 Structure of a GSA: Reasoning..................................11 4.3 Structure of a GSA: Reasoning..................................12
5. Security Services.................................................14 4.4 Definition of GSA..............................................12
5.2.1 Multicast Data Confidentiality.............................14 4.5 Typical Compositions of a GSA..................................14
5.2.2 Multicast Source Authentication and Data Integrity.........15 5. Security Services.................................................15
5.2.3. Multicast Group Authentication............................15 5.2.1 Multicast Data Confidentiality.............................15
5.2.4 Multicast Group Membership Management......................16 5.2.2 Multicast Source Authentication and Data Integrity.........16
5.2.5 Multicast Key Management...................................16 5.2.3 Multicast Group Authentication.............................16
5.2.6 Multicast Policy Management................................17 5.2.4 Multicast Group Membership Management......................17
6. MSEC Documents Roadmap............................................18 5.2.5 Multicast Key Management...................................17
7. Conclusion........................................................19 5.2.6 Multicast Policy Management................................18
8. Acknowledgments...................................................19 8. Security Considerations...........................................19
9. References........................................................19 9. Acknowledgments...................................................19
9.1 Normative References...........................................19 10. References.......................................................19
9.2 Informative References.........................................20 10.1 Normative References..........................................19
Authors Addresses....................................................21 10.2 Informative References........................................19
Authors Addresses....................................................20
1. Introduction 1. Introduction
Securing IP multicast communication is a complex task that involves Securing IP multicast communication is a complex task that involves
many aspects. Consequently, a secure IP multicast protocol suite must many aspects. Consequently, a secure IP multicast protocol suite must
have a number of functional areas that address different aspects of have a number of functional areas that address different aspects of
the problem. This document describes those functional areas, and the solution. This document describes those functional areas, and how
protocols which have been developed which fit into those component they are related.
areas.
1.1 Summary of Contents of Document This architecture is concerned with the securing of large multicast
groups. Whereas it can also be used for smaller groups, it is not
necessarily the most efficient means. For example, the Cliques
Hardjono, Weis Expires May, 2003 2 Hardjono, Weis Expires November, 2003 2
MSEC Architecture October, 2002 MSEC Architecture May, 2003
This document provides an architectural overview of the work being architecture [STW] is an efficient for small ad-hoc group
conducted in the MSEC Working Group. It provides a Reference communication.
Framework for covering the scope of the problems in multicast
security, and explains the elements of the Reference Framework.
The Reference Framework, in turn, provides the division of labor 1.1 Summary of Contents of Document
This document provides an architectural overview that outlines the
security services required to secure large multicast groups. It
provides a Reference Framework for organizing the various elements
within the architecture, and explains the elements of the Reference
Framework.
The Reference Framework organizes the elements of the architecture
along three Functional Areas pertaining to security. These cover the along three Functional Areas pertaining to security. These cover the
treatment of data from a security perspective when it is to be sent treatment of data from a security perspective when it is to be sent
to a group, the management of keying material used to protect the to a group, the management of keying material used to protect the
data and the policies governing a group. data, and the 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.2 Audience 1.2 Audience
This document is addressed to the technical community and This document is addressed to the technical community, implementers
implementers of IP multicast security technology others interested in of IP multicast security technology, and others interested in gaining
gaining a general background understanding of multicast security. a general background understanding of multicast security. This
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. IPsec, IKE, ISAKMP), Protocol, the IPsec suite of protocols (e.g. IPsec [RFC2401], IKE
related networking technology, and general security terms and [RFC2409], ISAKMP [RFC2408]), related networking technology, and
concepts. general security terms and concepts.
1.3 Related Documents 1.3 Terminology
Other documents provide detailed explanations of the Functional Areas The following key terms are used throughout this document.
within the MSEC Reference Framework. These include the following set
of documents:
a. "Group Key Management Architecture" document [BCDL] -- a document 1-to-N
that provides the key management architecture for multicast
security, building on the Group Security Association (GSA)
concept defined in the current document.
b. "Group Domain of Interpretation" [BHHW] and "GSAKMP Light" [HSC], A group which has one sender and many receivers.
which are two instances of protocols implementing the group key
management function.
c. "Multicast Encapsulating Security Payload" [BCCR], which provides Group Security Association (GSA)
the definition for Multicast ESP, for data traffic.
d. "Multicast Source Authentication Transform Specification" [PCW], A bundling of Security Associations (SAs) that together define
which defines the use of the TESLA algorithm for source how a group communicates securely. The GSA may include an
authentication in multicast. registration protocol SA, a rekey protocol SA, and one or more
data security protocol SAs.
Hardjono, Weis Expires May, 2003 3 M-to-N
MSEC Architecture October, 2002
2. Architectural Design: The MSEC Reference Framework A group which has many senders and many receivers, where M and N
are not necessarily the same value.
This section considers the complex problems of multicast security in Hardjono, Weis Expires November, 2003 3
the context of a heuristic device, the Reference Framework diagram, MSEC Architecture May, 2003
shown in Figure 1. The Reference Framework is used to classify
functional areas, functional elements, and interfaces.
2.1 A Reference Framework Security Association (SA)
Based on the three broad functional areas, a reference framework is A set of policy and cryptographic keys that provide security
proposed (Figure 1). The reference framework attempts to incorporate services to network traffic that matches that policy.
the main entities and functions relating to multicast security, and
to depict the inter-relations among them. At the same time, it also 2. Architectural Design: The Multicast Security Reference Framework
tries to express the complex multicast security question from the
perspective of problem classification (i.e., the three functional This section considers the complex issues of multicast security in
areas), from the perspective of architectures (centralized the context of the Reference Framework diagram, shown in Figure 1.
distributed), of multicast types (1-to-M or M-to-N), and protocols The Reference Framework is used to classify functional areas,
(the exchanged messages). functional elements, and interfaces.
2.1 The Reference Framework
The reference framework is based on three broad functional areas
(Figure 1). The reference framework incorporates the main entities
and functions relating to multicast security, and depicts the inter-
relations among them. It also expresses multicast security from the
perspective of architectures (centralized and distributed), of
multicast group types (1-to-N and M-to-N), and classes of protocols
(the exchanged messages) needed to secure multicast packets.
The aim of the reference framework is to provide some general context The aim of the reference framework is to provide some general context
within which functional areas can be identified and classified and around the functional areas, and the relationships between the
the relationships among the functional areas can be recognized. Note functional areas. Note that some issues span more than one so-called
that some issues span more than one so-called functional area. In functional area. In fact, the framework encourages the precise
fact, the framework encourages the precise identification and identification and formulation of issues that involve more than one
formulation of issues that involve more than one functional area or functional area or those which are difficult to express in terms of a
those which are difficult to express in terms of a single functional single functional area. An example of such a case is the expression
area. An example of such a case is the expression of policies of policies concerning group keys, which involves both the functional
concerning group keys, which involves both the functional areas of areas of group key management and multicast policies.
group key management and multicast policies.
When considering the reference framework (Figure 1) it is important When considering Figure 1, it is important to realize that the
to realize that the singular "boxes" in the framework do not singular "boxes" in the framework do not necessarily imply a
necessarily imply a corresponding singular entity implementing a corresponding singular entity implementing a given function. Rather,
given function. Rather, a box in the framework should be interpreted a box in the framework should be interpreted loosely as pertaining to
loosely as pertaining to a given function related to a functional a given function related to a functional area. Whether that function
area. Whether that function is in reality implemented as one or more is in reality implemented as one or more physical entities is
physical entities is dependent on the particular solution. As an dependent on the particular solution. As an example, the box labeled
example, the box labeled "Key Server" must be interpreted in broad "Key Server" must be interpreted in broad terms as referring to the
terms as referring to the functions of key management. Similarly, functions of key management.
the Reference Framework acknowledges that some implementations may in
fact merge a number of the "boxes" into a single physical entity. Similarly, the Reference Framework acknowledges that some
implementations may in fact merge a number of the "boxes" into a
single physical entity. This could be true even across functional
areas. For example, an entity in a group could act as both a Group
Controller and a Sender to a group.
The reference framework can be viewed horizontally and vertically. The reference framework can be viewed horizontally and vertically.
Horizontally, it displays both the entities and functions as singular Horizontally, it displays both the entities and functions as singular
boxes, expressing each of the three broad functional areas. boxes, expressing each of the three broad functional areas.
Vertically, it expresses the basic architecture designs for Vertically, it expresses the basic architecture designs for
Hardjono, Weis Expires November, 2003 4
MSEC Architecture May, 2003
solutions, namely a centralized architecture and a distributed solutions, namely a centralized architecture and a distributed
architecture. architecture.
The protocols to be standardized are depicted in Figure 1 by the The protocols to be standardized are depicted in Figure 1 by the
arrows that connect the various boxes. See more details in Section 4, arrows that connect the various boxes. See more details in Section 4,
below. below.
Hardjono, Weis Expires May, 2003 4
MSEC Architecture October, 2002
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
| CENTRALIZED \ DISTRIBUTED | | CENTRALIZED \ DISTRIBUTED |
| DESIGNS \ DESIGNS | | DESIGNS \ DESIGNS |
| FUNCTIONAL \ | | FUNCTIONAL \ |
| AREAS \ | | AREAS \ |
| +------+ \ +------+ | | +------+ \ +------+ |
| Multicast |Policy|<-------\------------------------>|Policy| | | Multicast |Policy|<-------\------------------------>|Policy| |
| Security |Server| \ |Server| | | Security |Server| \ |Server| |
| Policies +------+ \ +------+ | | Policies +------+ \ +------+ |
| ^ \ ^ | | ^ \ ^ |
skipping to change at line 223 skipping to change at line 236
| Key |Ctrl/ |<---------+ \ |Ctlr/ | | | Key |Ctrl/ |<---------+ \ |Ctlr/ | |
| Management |Key | | \ |Key | | | Management |Key | | \ |Key | |
| |Server| V \ |Server| | | |Server| V \ |Server| |
| +------+ +--------+ \ +------+ | | +------+ +--------+ \ +------+ |
| ^ | | \ ^ | | ^ | | \ ^ |
| | |Receiver| \ | | | | |Receiver| \ | |
| | | | | | | | | | | | | |
| v +--------+ | | | | v +--------+ | | |
| +------+ ^ | V | | +------+ ^ | V |
| | | | | +--------+ | | | | | | +--------+ |
| Multicast |Sender|<---------+ | | | | | Multicast |Sender|----------+ | | | |
| Data | |<--------------------- |-------->|Receiver| | | Data | |---------------------- |-------->|Receiver| |
| Handling | | | | | | | Handling | | | | | |
| +------+ | +--------+ | | +------+ | +--------+ |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
Figure 1: MSEC Reference Framework Figure 1: Multicast Security Reference Framework
2.2 Elements of the Reference Framework 2.2 Elements of the 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. There are three sets of functional entities in functional entities.
both centralized and distributed designs as discussed below.
In some cases, a system implementing the multicast security
architecture may not need to implement protocols to account for every
interface. Rather, those interfaces may be satisfied through the use
Hardjono, Weis Expires November, 2003 5
MSEC Architecture May, 2003
of manual configuration, or even omitted if they are not necessary
for the application.
There are three sets of functional entities in both centralized and
distributed designs as discussed below.
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, which is subject to the
user-authentication and authorization checks conducted on the user-authentication and authorization checks conducted on the
candidate member of the multicast group. candidate member of the multicast group.
Hardjono, Weis Expires May, 2003 5
MSEC Architecture October, 2002
In a distributed architecture the GCKS entity also interacts with In a distributed architecture the GCKS entity also interacts with
other GCKS entities to achieve scalability in the key management other GCKS entities to achieve scalability in the key management
related services. In such a case, each member of a multicast group related services. In such a case, each member of a multicast group
may interact with one or more GCKS entity (say, the "nearest" GCKS may interact with one or more GCKS entity (say, the "nearest" GCKS
entity, measured in terms of a well-defined and consistent metric). entity, measured in terms of a well-defined and consistent metric).
Similarly, in a distributed architecture a GCKS entity may interact Similarly, in a distributed architecture a GCKS entity may interact
with one or more Policy Servers, also arranged in a distributed with one or more Policy Servers, also arranged in a distributed
architecture. architecture.
We remark that the Key Server (KS) and the Group Controller (GC) have The Key Server (KS) and the Group Controller (GC) have somewhat
somewhat different functionality and may in principle be regarded as different functionality and may in principle be regarded as separate
separate entities. Currently the framework regards the two entities entities. Currently the framework regards the two entities as one
as one "box" in order to simplify the design, and in order not to "box" in order to simplify the design, and in order not to mandate
mandate standardization of the protocol between the KS and the GC. It standardization of the protocol between the KS and the GC. It is
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 allowed 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, many (or even all) data to the group. In an M-to-N multicast group, many (or even all)
group members can transmit data to the group. group members are authorized to transmit data to the group.
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-authentication, the purpose of key management. This includes user and/or device
obtaining of keying material in accordance with some key management authentication, user and/or device authorization, the obtaining of
policies for the group, obtaining new keys during key-updates, and keying material in accordance with some key management policies for
obtaining other messages relating to the management of keying the group, obtaining new keys during key-updates, and obtaining other
material and security parameters. messages relating to the management of keying material and security
parameters.
The influence of policies on both Senders and Receivers is seen as Senders and Receivers may receive much of their policy from the GCKS
coming indirectly through the GCKS entities, since the event of entities. The event of joining a multicast group is typically coupled
joining a multicast group is typically coupled with the with the Sender/Receiver obtaining keying material from a GCKS
Sender/Receiver obtaining keying material from a GCKS entity. This entity. This does not preclude the direct interaction between the
does not preclude the direct interaction between the Sender/Receiver Sender/Receiver and the Policy Server.
and the Policy Server.
Hardjono, Weis Expires November, 2003 6
MSEC Architecture May, 2003
The reference framework displays two Receiver boxes corresponding to The reference framework displays two Receiver boxes corresponding to
the situation where both the Sender and Receiver employ the same the situation where both the Sender and Receiver employ the same GCKS
GCKS entity (centralized architecture) and where the Sender and entity (centralized architecture) and where the Sender and Receiver
Receiver employ different GCKS entities (distributed architecture). employ different GCKS entities (distributed architecture).
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.
Hardjono, Weis Expires May, 2003 6
MSEC Architecture October, 2002
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.
2.2.4 Centralized and Distributed Designs 2.2.4 Centralized and Distributed Designs
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. This implies framework to also function as a distributed system.
that a GCKS entity must be able to interact securely with other
GCKS entities in a different location. Similarly, Policy Servers This implies that a GCKS entity must be able to interact securely
must interact with each other securely to allow the communication and with other GCKS entities in a different location. These GCKS entities
enforcement of policies across the Internet. will require a means of authenticating their peer GCKS entities, a
means of authorization (e.g., delegation certificates), and a means
of interacting securely to pass keys and policy.
Similarly, Policy Servers must interact with each other securely to
allow the communication and enforcement of policies across the
Internet.
3. Functional Areas 3. Functional Areas
In order to begin to address the problems in securing IP multicast, The Reference Framework identifies three functional areas. They are:
we identify three functional area emanating from the reference
framework. The three functional area are:
Multicast data handling. This area covers problems concerning Multicast data handling. This area covers the security-related
the security-related treatments of multicast data by the sender treatments of multicast data by the sender and the receiver.
and the receiver. This functional area is further discussed in This functional area is further discussed in Section 3.1.
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 functional
area is further discussed in Section 3.2. area is further discussed in Section 3.2.
Multicast security policies. This area covers aspects of policy Multicast security policies. This area covers aspects of policy
in the context of multicast security, taking into consideration in the context of multicast security, taking into consideration
the fact that policies may be expressed in different ways, that the fact that policies may be expressed in different ways, that
they may exist at different levels in a given multicast security they may exist at different levels in a given multicast security
architecture and that they may be interpreted differently architecture, and that they may be interpreted differently
according to the context in which they are specified and according to the context in which they are specified and
Hardjono, Weis Expires November, 2003 7
MSEC Architecture May, 2003
implemented. This functional area is further discussed in implemented. This functional area is further discussed in
Section 3.3. Section 3.3.
3.1 Multicast Data 3.1 Multicast Data
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:
2.1 Source authentication and data integrity. This a. Source authentication and data integrity. This
functionality guarantees that the data originate 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
Hardjono, Weis Expires May, 2003 7
MSEC Architecture October, 2002
2.2 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 some group member. It does not guarantee data integrity by 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 point-to-point
communication, source authentication for multicast is considerably communication, source authentication for multicast is considerably
more involved. Consequently, off-the-shelf solutions (e.g., taken more involved. Consequently, off-the-shelf solutions (e.g., taken
from IPSec [RFC2406], TLS [RFC2246]) may be sufficient for from IPSec [RFC2406]) may be sufficient for encryption and group
encryption. For source authentication, however, special-purpose authentication. For source authentication, however, special-purpose
transformations are necessary. See [CP99] for further elaboration transformations are necessary. See [CCPRRS] for further
on the concerns regarding the data transforms, on present solutions elaboration on the concerns regarding the data transforms.
and remaining challenges.
Multicast data encrypted and/or authenticated by a sender should be
handled the same way by both centralized and distributed receivers,
(as shown in Figure 1).
The "Multicast Encapsulating Security Payload" [BCCR] provides the
definition for Multicast ESP for data traffic. The "Multicast Source
Authentication Transform Specification" [PCW] defines the use of the
TESLA algorithm for source authentication in multicast.
3.2 Management of Keying Material 3.2 Management of Keying Material
The term "keying material" refers to the cryptographic key belonging The term "keying material" refers to the cryptographic keys belonging
to a group, the state associated with the keys and the other security to a group, the state associated with the keys, and the other
parameters related to the keys. Hence, the management of the security parameters related to the keys. Hence, the management of
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 problems 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.
Hardjono, Weis Expires November, 2003 8
MSEC Architecture May, 2003
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 Methods to establish a long-term secure channel between one GCKS
GCKS entity and another, for the purpose of distributing entity and another, for the purpose of distributing shorter-term
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 Methods to detect and signal failures and perceived compromises
to keys and keying material to keys and keying material
The needs related to the management of keying material must be seen The needs related to the management of keying material must be seen
in the context of the policies that prevail within the given in the context of the policies that prevail within the given
circumstance. circumstance.
Core to the problem 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
the key management architecture for multicast security. It builds on
the Group Security Association (GSA) concept, and further defines the
roles of the Key Server and Group Controller.
"The Group Domain of Interpretation" [BHHW], "GSAKMP" [HSMC], and
"MIKEY" [ACLNM] are three instances of protocols implementing the
group key management function.
3.3 Multicast Security Policies 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. While much of the the other elements of the Reference Framework. Security Policies may
work for the Multicast Security Policy area is focused in the Policy be distributed in an ad-hoc fashion in some instances. However,
Controller, there are potential areas for work in the application of better coordination and higher levels of assurance are achieved if a
policy at the Group Controller element and the member (sender and Policy Controller distributes Security Policies policy to the group.
receiver) elements. While there is already a basis for security
policy management in the IETF between the Policy Working Group and
Hardjono, Weis Expires May, 2003 8 Multicast security policies must represent, or contain, more
MSEC Architecture October, 2002 information than a traditional peer-to-peer policy. In addition to
representing the security mechanisms for the group communication, the
policy must also represent the rules for the governance of the secure
group. For example, policy would specify the authorization level
necessary in order for an entity to join a group. More advanced
operations would include the conditions when a group member must be
forcibly removed from the group, and what to do if the group members
need to resynchronize because of lost key management messages.
the IP Security Policy Working Group, multicast security policy The application of policy at the Group Controller element and the
management will extend the concepts developed for unicast member (sender and receiver) elements must be described. While there
communication in the areas of: is already a basis for security policy management in the IETF,
multicast security policy management extends the concepts developed
for unicast communication in the areas of:
Policy creation, Policy creation,
High-level policy translation, and High-level policy translation, and
Policy representation. Policy representation.
Hardjono, Weis Expires November, 2003 9
MSEC Architecture May, 2003
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 explored for 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 coherent group security policy. They include a top-down specification
specification of the group policy from the group initiator and of the group policy from the group initiator and negotiation of the
negotiation of the policy between the group members (or prospective policy between the group members (or prospective members).
members). Negotiation can be as simple as a strict intersection of Negotiation can be as simple as a strict intersection of the policies
the policies of the members or extremely complicated using weighted of the members or extremely complicated using weighted voting
voting systems. systems.
High-level policy translation is much more difficult in a multicast
group environment, especially when group membership spans multiple
administrative domains. When policies are specified at a high level
with a Policy Management tool, they must then be translated into more
precise rules that the available security mechanisms can both
understand and implement. When dealing with multicast communication
and its multiple participants, it is essential that the individual
translation performed for each participant result in the use of a
mechanism that is interoperable with the results of all of the other
translations. Typically, the translation from high-level policy to
implementation mechanisms must result in the same mechanism in order
to achieve communication between all of the group members. The
requirement that policy translation results in the same mechanism
places constraints on the use and representations in the high-level
policies. It is also important that policy negotiation and
translation be performed as an integral part of joining a group.
Adding a member to a group is meaningless if they will not be able to
participate in the group communications.
Multicast security policies must represent, or contain, more The translation of policy rules from one data model to another is
information than a traditional peer-to-peer policy. In addition to much more difficult in a multicast group environment. This is
representing the security mechanisms for the group communication, the especially true when group membership spans multiple administrative
policy must also represent the rules for the governance of the secure domains. Policies specified at a high level with a Policy Management
group. Policy must be established for the basic group operations of tool must be translated into more precise rules that the available
add and remove, as well as more advanced operations such as leave, security policy mechanisms can both understand and implement. When
rejoin, or resynchronize. dealing with multicast communication and its multiple participants,
it is essential that the individual translation performed for each
participant result in the use of a mechanism that is interoperable
with the results of all of the other translations. Typically, the
translation from high-level policy to specific policy objects must
result in the same objects in order to achieve communication between
all of the group members. The requirement that policy translation
results in the same objects places constraints on the use and
representations in the high-level policies.
Hardjono, Weis Expires May, 2003 9 It is also important that policy negotiation and translation be
MSEC Architecture October, 2002 performed as an integral part of joining a group. Adding a member to
a group is meaningless if they will not be able to participate in the
group communications.
4. Group Security Associations (GSA) 4. Group Security Associations (GSA)
4.1 SAs and Multicast 4.1 The Security Association
It is clear that the security associations (SA) for group key A security association is a commonly used term in cryptographic
management are more complex, or at least more numerous, than for systems [RFC2401, RFC2409]. It describes a set of policy and
Internet key management [RFC2409]. The latter establishes a key cryptographic keys that provide security services for the network
management SA to protect application SAs (where a minimum of two are traffic matching that policy. A Security Association usually
needed to key an Internet application process). However, group key contains the following attributes:
management requires at least three: There is a registration SA
between the group member and the GCKS, a rekey SA between the GCKS
and all the group members, and an SA to protect application data from
sender-members to receiver-members. In fact, each sender to the
group may use a unique key for their data and use a separate SA:
there may be more SAs than there are group senders.
Group key management, therefore, uses a different set of abstractions - selectors, such as source and destination transport addresses.
than ISAKMP and IKE. Notwithstanding, the abstractions used in our - properties, such as an security parameter index (SPI) or cookie
Group Key Management functional area may be built from the ISAKMP pair, and identities.
abstractions. In our approach the Group Security Association (GSA)
includes the attributes of the Internet Security Architecture SA,
which is succinctly defined as the encapsulation of keys and policies
[RFC2409] as follows.
- An SA has selectors, such as source and destination transport Hardjono, Weis Expires November, 2003 10
addresses. MSEC Architecture May, 2003
- An SA has properties, such as an security parameter index (SPI)
or cookie pair, and identities. - cryptographic policy, such as the algorithms, modes, key
- An SA has cryptographic policy, such as the algorithms, modes, lifetimes, and key lengths used for authentication or
key lifetimes, and key lengths used for authentication or
confidentiality. confidentiality.
- An SA has keys, such as authentication, encryption and signing - keys, such as authentication, encryption and signing keys.
keys.
As is discussed in the next section of this memo, a GSA contains the Group key management uses a different set of abstractions than point-
SA attributes plus some additional ones. As shown in Figure 2 (a), to-point key management systems, such as IKE [RFC2409].
the GSA is a superset of the SA. Notwithstanding, the abstractions used in the Group Key Management
functional area may be built from the point-to-point key management
abstractions.
4.2 Structure of a GSA: Introduction
Security associations (SAs) for group key management are more
complex, and are usually more numerous, than for point-to-point key
management algorithms. The latter establishes a key management SA to
protect application SAs (usually one or two, depending on the
protocol). However, group key management may require up to three or
more SAs. These SAs are described in later sections.
A GSA contains all of the SA attributes identified in the previous
section, as well some additional attributes pertaining to the group.
As shown in Figure 2, the GSA builds on the SA in two distinct ways.
First, the GSA is a superset of an SA (Figure 2(a)).
A GSA has group policy attributes, such as the kind of signed A GSA has group policy attributes, such as the kind of signed
credential needed for group membership and whether the group credential needed for group membership, if group members will be
will be given new keys when a member is added (called "backward given new keys when a member is added (called "backward re-key"
re-key" below) or whether group members will be given new key below), or whether group members will be given new key when a
when a member is removed from the group ("forward re-key"). member is removed from the group ("forward re-key"). A GSA also
- A GSA has SAs as attributes. includes an SA as an attribute of itself.
Hardjono, Weis Expires May, 2003 10 Second, the GSA is an aggregation of SAs (Figure 2(b)). A GSA is
MSEC Architecture October, 2002 comprised of multiple SAs, and these SAs may be used for several
independent purposes.
+------------------------------------------------------------+ +------------------------------------------------------------+
| | | |
| +---------------+ +-------------------+ | | +---------------+ +-------------------+ |
| | GSA | | GSA | | | | GSA | | GSA | |
| | | | +-----+ +-----+ | | | | | | +-----+ +-----+ | |
| | | | | SA1 | | SA2 | | | | | | | | SA1 | | SA2 | | |
| | +----+ | | +-----+ +-----+ | | | | +----+ | | +-----+ +-----+ | |
| | | SA | | | +-----+ | | | | | SA | | | +-----+ | |
| | +----+ | | | SA3 | | | | | +----+ | | | SA3 | | |
| | | | +-----+ | | | | | | +-----+ | |
| +---------------+ +-------------------+ | | +---------------+ +-------------------+ |
| | | |
| (a) superset (b) aggregation | | (a) superset (b) aggregation |
| | | |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure 2: Relationship of GSA to SA Figure 2: Relationship of GSA to SA
4.1 Structure of a GSA: Reasoning Hardjono, Weis Expires November, 2003 11
MSEC Architecture May, 2003
There are three categories of SAs aggregated into a GSA in Figure
2(b). We choose this structure to better realize a GSA in our key
management environment. There is a need to maintain SAs between a Key
Server and a group member (either a sender, a receiver or both) and
among members. The Key Server is called the "GCKS," which is charged
with access control to the group keys, with policy distribution to
client members or prospective members, and with group key
dissemination to sender and receiver client members. This structure
is common in many group key management environments [HH, CP99,
RFC2627, BMS]. There are two SAs established between the GCKS and the
members, and there is an SA established among the sending and
receiving members as shown in Figure 3.
The first category of SA (namely REG in Figure 3, for "registration
SA") is initiated by the member to pull GSA information from the
GCKS. This is how the member requests to join the secure group or has
its GSA keys re-initialized after being disconnected from the group
(e.g., when its host computer has been turned off during re-key
operations as described below). The GSA information pulled down from
the GCKS include the SA, keys and policy used to secure the data
transmission between sending and receiving members; this is DATA in
Figure 3, "for data security SA". Note that DATA is a category of
SA, and this implies that there may be multiple SAs established
between member senders and member receivers - at least as an option.
There may exist, for example, a single DATA SA in which all senders
share common keys and associated information. On the other hand,
there may be one or more DATA SAs that are unique to the particular
sender. A DATA SA may be reestablished or have its keys modified
through re-key operations, which occur over a REKEY SA (for "rekey
SA). Keys are pushed through a REKEY SA to support subscription
groups.
Hardjono, Weis Expires May, 2003 11 4.3 Structure of a GSA: Reasoning
MSEC Architecture October, 2002
Thus, despite the fact that the data to be protected are multicast, Figure 3 shows three categories of SAs that can be aggregated into a
registration exchanges through a REG SA should be unicast or point- GSA. There is a need to maintain SAs between a Key Server and a group
to-point key determination exchanges. Some group key management member (both a sender and a receiver) and among the members
solutions rely solely point-to-point. Most others combine unicast themselves. There are two SAs established between the GCKS and the
exchanges for initialization with multicast distribution for re-key. members, and there is an SA established among the sending and
In some cases, such as in a pure "pay-per-session" application, all receiving members.
of the SA information needed for the session may be distributed at
the time of registration or selection of a session, i.e. over a REG
SA; re-key and re-initialization may not be necessary, so there is no
REKEY SA. For subscription groups where keying material is changed
as membership changes, a REKEY SA is needed to re-initialize a DATA
SA.
+------------------------------------------------------------+ +------------------------------------------------------------+
| | | |
| +------------------+ | | +------------------+ |
| | GCKS | | | | GCKS | |
| | | | | | | |
| | REG REG | | | | REG REG | |
| | / REKEY \ | | | | / REKEY \ | |
| +---/-----|----\---+ | | +---/-----|----\---+ |
| / | \ | | / | \ |
| / | \ | | / | \ |
| / | \ | | / | \ |
| / | \ | | / | \ |
| / | \ | | / | \ |
| +-------------/------+ | +------\-------------+ | | +----------/------+ | +------\----------+ |
| | REG | | | REG | | | | REG | | | REG | |
| | REKEY-----+----REKEY | | | | REKEY-----+----REKEY | |
| | MEMBER SENDER | | MEMBER RECEIVER| | | | SENDER | | RECEIVER | |
| | DATA----------DATA | | | | DATA----------DATA | |
| +--------------------+ +--------------------+ | | +-----------------+ +-----------------+ |
| | | |
| | | |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure 3: GSA Structure and 3 categories of SAs Figure 3: GSA Structure and 3 categories of SAs
4.2 Definition of GSA 4.4 Definition of GSA
The GSA includes an aggregate of the three aforementioned categories The GSA includes an aggregate of the three categories of SAs. The
of SAs. The three categories of SAs correspond to the three kinds of three categories of SAs correspond to the three kinds of
communications as seen from the point of view of the Receiver communications commonly required for group communications. The three
(Member). Figure 3 depicts this concept: categories of SAs depicted in Figure 3 are:
- Registration (REG) SA: Hardjono, Weis Expires November, 2003 12
MSEC Architecture May, 2003
- 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 policy distribution to members (or prospective members), and with policy distribution to members (or prospective members), and
with group key dissemination to Sender and Receiver members. This with group key dissemination to Sender and Receiver members. This
use of a (unicast) SA as a starting point for key management is use of a (unicast) SA as a starting point for key management is
common in a number of group key management environments [BHHW,
HSMC, CCPRRS, RFC2627, BMS,].
Hardjono, Weis Expires May, 2003 12 The Registration SA is initiated by the member to pull GSA
MSEC Architecture October, 2002 information from the GCKS. This is how the member requests to
join the secure group, or has its GSA keys re-initialized after
common in a number of group key management environments [HH, being disconnected from the group (e.g., when its host computer
CP99, RFC2627, BMS, Bris99]. has been turned off during re-key operations). The GSA
information pulled down from the GCKS is related to the other two
SAs defined as part of the GSA.
Note that this (unicast) SA is used to protect the other elements Note that this (unicast) SA is used to protect the other elements
of the GSA (such as the other following two categories of SAs), of the GSA. As such, the Registration SA is crucial and is
either in a "push" or "pull" model. As such, this SA is crucial inseparable from the other two SAs in the definition of a GSA.
and is inseparable from the other two SAs as the definition of a
GSA. However, the requirement of a registration SA does not imply the
need of a registration protocol to create that Registration SA.
The registration SA could instead be setup through some manual
means, such as distributed on a smart card. Thus, what is
important is that a Registration SA exists, and is used to
protect the other SAs.
From the perspective of one given GCKS, there are as many unique 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, so a registration SA may be used on-demand whereas applications. A registration SA may be established on-demand with
re-key and data security SAs are established at least for the a short lifetime, whereas re-key and data security SAs are
life of the sessions that they support. established at least for the life of the sessions that they
support.
- Re-key (REKEY) SA: Conversely the registration SA could be left in place for the
An SA is required for the multicast transmission of key duration of the group lifetime, if scalability is not an issue.
management messages (unidirectional) from the GCKS to all group Such a long term registration SA would be useful for re-
members. As such, this SA is known by the GCKS and by all members synchronization or deregistration purposes.
of the group.
- Re-key SA (REKEY):
In some cases, a GCKS needs the ability to "push" new SAs as part
of the GSA. These new SAs must be sent to all group members. In
other cases, the GCKS needs the ability to quickly revoke access
to one or more group members. Both of these needs are satisfied
with the Re-key SA.
This Re-key SA is a unidirectional multicast transmission of key
management messages from the GCKS to all group members. As such,
this SA is known by the GCKS and by all members of the group.
Hardjono, Weis Expires November, 2003 13
MSEC Architecture May, 2003
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.
From the perspective of each participant in a group (GCKS and all A rekey SA is not absolutely required to be part of a GSA. For
members), there is at least one registration SA for the group. example, the lifetime of some groups may be short enough such
Note that this allows for the possibility of the GCKS deploying that a rekey is not necessary. Conversely, the policy for the
multiple re-key SAs for group key management purposes. group could specify multiple rekey SAs of different types. For
example, if the GC and KS are separate entities, the GC may
deliver rekey messages that adjust the group membership, and the
KS may deliver rekey messages with new DATA SAs.
- Data Security SA (DATA):
The Data Security SA protects data between member senders and
member receivers.
- Data Security (DATA) SA:
One or more SAs are required for the multicast transmission of One or more SAs are required for the multicast transmission of
data-messages (unidirectional) from the Sender to other group data-messages from the Sender to other group members. This SA is
members. This SA is known by the GCKS and by all members of the known by the GCKS and by all members of the group.
group.
Similarly, regardless of the number of instances of this third Regardless of the number of instances of this third category of
category of SA, this SA is not negotiated. Rather, all group SA, this SA is not negotiated. Rather, all group members obtain
members obtain it from the GCKS. The GCKS itself does not use it from the GCKS. The GCKS itself does not use this category of
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. security SA for the member sender (one or more) in the group. If
This allows for the possibility of including group IDs (GID) in the group has more than one data security SA, the data security
transmission of data packets from the senders in the group. protocol must have a means of differentiating the SAs (e.g., with
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 and the use of Group IDs (GIDs): data security SAs:
(i) Each sender in the group could be assigned a unique dta 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
group. In this case, each sender may be verified using source
origin authentication techniques.
Hardjono, Weis Expires May, 2003 13 2. The entire group deploys a single data security SA for all
MSEC Architecture October, 2002 senders. Receivers would then be able to maintain only one data
security SA.
maintain as many data security SAs as there are senders in 3. A combination of 1. and 2.
the group.
(ii) The entire group deploys a single data security SA for all 4.5 Typical Compositions of a GSA
senders, together with the use of GIDs. Receivers would
then be able to filter based on the GIDs, whilst maintaining
only one data security SA.
(iii) A combination of (i) and (ii) above. Depending on the multicast group policy, many compositions of a GSA
are possible. For illustrative purposes, this section describes a few
possible compositions.
Hardjono, Weis Expires November, 2003 14
MSEC Architecture May, 2003
A group of memory-constrained members may require only a REG SA,
and a single DATA SA.
A "pay-per-session" application, where all of the SA information
needed for the session may be distributed over a REG SA. Re-key
and re-initialization of DATA SAs may not be necessary, so there
is no REKEY SA.
A subscription group, where keying material is changed as
membership changes. A REG SA is needed to distribute other SAs; a
REKEY SA is needed to re-initialize a DATA SA at the time
membership changes.
5. Security Services 5. Security Services
Referring to our Reference Diagram, this section identifies security Referring to the Reference Diagram, this section identifies security
services for designated interfaces of Figure 1. In this section, services for designated interfaces of Figure 1. In this section,
distinct security services are assigned to specific interfaces. For distinct security services are assigned to specific interfaces. For
example, multicast source authentication, data authentication, and example, multicast source authentication, data authentication, and
confidentiality occur on the multicast data interface between Senders confidentiality occur on the multicast data interface between Senders
and Receivers in Figure 1. Authentication and confidentiality and Receivers in Figure 1. Authentication and confidentiality
services may also be needed between the Key Server and key clients services may also be needed between the Key Server and key clients
(i.e., the Senders and Receivers of Figure 1), but the services that (i.e., the Senders and Receivers of Figure 1), but the services that
are needed for multicast key management may be unicast as well as are needed for multicast key management may be unicast as well as
multicast. A security service for multicast security, therefore, multicast. A security service for multicast security, therefore,
identifies a specific function along one or more Figure 1 interfaces. identifies a specific function along one or more Figure 1 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, we propose these application-layer multicast security. Instead, that work will occur
tasks as future work that will occur as the functional building as the security services are further defined and realized in
blocks are further defined and realized in algorithms and protocols. algorithms and protocols.
We identify a set of security services in the following sections.
This preliminary list of services is intended to serve as a basis for
discussion in the MSEC working group.
5.2.1 Multicast Data Confidentiality 5.2.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 future work on the Multicast Data An important part of the Multicast Data Confidentiality security
Confidentiality building block is in the identification of and service is in the identification of and motivation for specific
motivation for specific ciphers that should be used for multicast ciphers that should be used for multicast data. Obviously, not all
data. Obviously, not all ciphers will be suitable for IP multicast ciphers will be suitable for IP multicast and application-layer
and application-layer multicast traffic. Since this traffic will multicast traffic. Since this traffic will usually be connectionless
usually be connectionless UDP flows, stream ciphers may be unsuitable UDP flows, stream ciphers may be unsuitable, though hybrid
though hybrid stream/block ciphers may have advantages over some stream/block ciphers may have advantages over some block ciphers.
block ciphers. Those working on this security service will need to
evaluate the real-time and other requirements of multicast senders
and receivers, and recommend a small set of promising ciphers and
Hardjono, Weis Expires May, 2003 14
MSEC Architecture October, 2002
data protocols for IP multicast and application-layer multicast data
confidentiality.
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
Hardjono, Weis Expires November, 2003 15
MSEC Architecture May, 2003
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 in all senders and receivers. programs. Effects to both senders and receivers is considered.
In Figure 1, the Multicast Data Confidentiality security service is In Figure 1, 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 1 when multicast data confidentiality interfaces and areas of Figure 1 when multicast data confidentiality
is needed. is needed.
5.2.2 Multicast Source Authentication and Data Integrity 5.2.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 made
both at the Sender's end and at the Receiver's end. It assumes that both at the Sender's end and at the Receiver's end. It assumes that
the appropriate signature and verification keys are provided via 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. Work done by MSEC Working Group Management as described below. This is one of the harder areas of
members suggests that this is one of the harder areas of multicast multicast security due to the connectionless and real-time
security. This is 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 data-
packet integrity. A robust solution to multicast source and data packet integrity. A robust solution to multicast source and data
authentication, however, is necessary for a Whole Protocol solution authentication, however, is necessary for a complete solution to
to multicast security. multicast security.
In Figure 1, the Multicast Source and Data Authentication security In Figure 1, 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 building produced for this functional area may have applicability to security
blocks 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.2.3. Multicast Group Authentication 5.2.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.
Hardjono, Weis Expires May, 2003 15
MSEC Architecture October, 2002
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.
Hardjono, Weis Expires November, 2003 16
MSEC Architecture May, 2003
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.2.4 Multicast Group Membership Management 5.2.4 Multicast Group Membership Management
This security service describes the functionality of registration and This security service describes the functionality of registration of
de-registration of members. Registration includes member members with the Group Controller, and de-registration of members
authentication, notification and negotiation of security parameters, from the Group Controller. These are security functions, which are
and logging of information according to the policies of the group independent from IP multicast group "join" and "leave" operations
controller and the would-be member. (Typically, an out-of-band that the member may need to perform (i.e., IGMP [RFC3376], MLD
advertisement of group information would occur before the [RFC3019]).
registration takes place. The registration process will typically be
invoked by the would-be member.) Registration includes member authentication, notification and
negotiation of security parameters, and logging of information
according to the policies of the group controller and the would-be
member. (Typically, an out-of-band advertisement of group information
would occur before the registration takes place. The registration
process will typically be invoked by the would-be member.)
De-registration may occur either at the initiative of the member or 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 logging
of the de-registration event by the group controller and an 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.2.5). membership of the de-registering member (see Section 5.2.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 GC+KS communication related to group membership among different GCKS
servers in a distributed group design. servers in a distributed group design.
In Figure 1, the Multicast Group Membership security service is In Figure 1, 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.2.5 Multicast Key Management 5.2.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 building may include: group. Components of this security service may include:
- GC+KS to Client (Sender or Receiver) notification regarding - GCKS to Client (Sender or Receiver) notification regarding
current keying material (e.g. group encryption and 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.
Hardjono, Weis Expires May, 2003 16
MSEC Architecture October, 2002
- Termination of groups in a secure manner, including the - Termination of groups in a secure manner, including the
multicast group itself and the associated keying material. multicast group itself and the associated keying material.
Among the problems to be solved by this security service is the Among the responsibilities of this security service is the secure
secure management of keys between Key Servers and Clients, the management of keys between Key Servers and Clients, the addressing
addressing issues for the multicast distribution of keying material, issues for the multicast distribution of keying material, and the
and the scalability or other performance requirements for multicast
key management [RFC2627, BMS]. Hardjono, Weis Expires November, 2003 17
MSEC Architecture May, 2003
scalability or other performance requirements for multicast key
management [RFC2627, BMS].
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, work on this multicast key management needs to be considered. Thus, this security
security service must take into account the key management service takes into account the key management requirements for IP
requirements for IP multicast, the key management requirements for multicast, the key management requirements for application-layer
application-layer multicast, and to what degree specific realizations multicast, and to what degree specific realizations of a Multicast
of a Multicast Key Management security service can satisfy both. Key Management security service can satisfy both. ISAKMP, moreover,
ISAKMP, moreover, has been designed to be extensible to multicast key has been designed to be extensible to multicast key management for
management for both IP multicast and application-layer multicast both IP multicast and application-layer multicast security [RFC2408].
security [RFC2408]. Thus, multicast key management protocols may use Thus, multicast key management protocols may use the existing ISAKMP
the existing ISAKMP standard's Phase 1 and Phase 2 protocols, standard's Phase 1 and Phase 2 protocols, possibly with needed
possibly with needed extensions (such as an ISAKMP Domain of extensions (such as GDOI [BHHW] or application-layer multicast
Interpretation for IP multicast or application-layer multicast
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 GC+KS 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 1 and is placed in the Group distributed designs as shown in Figure 1 and is placed in the Group
Key Management Area. Key Management Area.
5.2.6 Multicast Policy Management 5.2.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. Multicast Policy Management includes the design of the policy
policy server for multicast security, the particular policy server for multicast security, the particular policy definitions that
definitions that will be used for IP multicast and application-layer will be used for IP multicast and application-layer multicast
multicast security, and the communication protocols between the security, and the communication protocols between the Policy Server
Policy Server and the Key Server. This security service may be and the Key Server. This security service may be realized using a
realized using a standard policy infrastructure such as a Policy standard policy infrastructure such as a Policy Decision Point (PDP)
Decision Point (PDP) and Policy Enforcement Point (PEP) architecture. and Policy Enforcement Point (PEP) architecture [RFC2748]. Thus, it
Thus, it may not be necessary to re-invent a separate architecture may not be necessary to re-invent a separate architecture for
for multicast security policy; we expect that this work will evaluate multicast security policy; this work will evaluate use of the
use of the products of IETF efforts in the areas of network and products of IETF efforts in the areas of network and security policy.
security policy. At minimum, however, this security service will be At minimum, however, this security service will be realized in a set
of policy definitions, such as multicast security conditions and
Hardjono, Weis Expires May, 2003 17 actions.
MSEC Architecture October, 2002
realized in a set of policy 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 GC+KS to functionality of the communication between an instance of a GCKS to
an instance the Policy Server. The information transmitted may an instance 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
Policy Servers. Thus, the Multicast Policy Management security
service is placed in Problem Area 3, along the interface between Key
Servers and Policy Servers. Group members are not expected to
directly participate in this security service. However, this option
is not ruled out.
6. MSEC Documents Roadmap Hardjono, Weis Expires November, 2003 18
MSEC Architecture May, 2003
The roadmap of MSEC WG documents is shown the in the following. security service also describes communication between and among
Policy Servers. Group members are not expected to directly
participate in this security service. However, this option is not
ruled out.
+--------------+ 8. Security Considerations
| MSEC |
| Requirements |
+--------------+
:
:
+--------------+
| MSEC |
| Architecture |
+--------------+
:
.....................:.......................
: : :
+--------------+ +--------------+ +--------------+
| Policy | | GKM | | Data Security|
| Architecture | | Architecture | | Architecture |
+--------------+ +--------------+ +--------------+
: : :
: : :
. +------------+ : +------------+ :
. | GDOI | : |TESLA/MESP | :
| Resolution |-: | |-:
| | : | | :
+------------+ : +------------+ :
: :
: :
+------------+ : +------------+ :
| GSAKMP- | : | | :
| Resolution |-: | TBD |-:
| | : | | :
+------------+ : +------------+ :
: :
Hardjono, Weis Expires May, 2003 18 This document describes methods and guidelines for protecting
MSEC Architecture October, 2002 multicast and group traffic with cryptographic protocols.
: : 9. Acknowledgments
+------------+ : +------------+ :
| | : | | :
| RE-KEY |-: | TBD |-:
| | : | | :
+------------+ : +------------+ :
: :
. .
. .
Figure 4: MSEC Document Roadmap Much of the text in this document was derived from two research
papers. The framework for this document came from a paper co-authored
by Thomas Hardjono, Ran Canetti, Mark Baugher, and Pete Dinsmore.
Description of the GSA came from a document co-authored by Hugh
Harney, Mark Baugher, and Thomas Hardjono.
7. Conclusion 10. References
This document has provided an architectural overview of the work 10.1 Normative References
being conducted in the MSEC Working Group and introduced several
important aspects of the standardization efforts in the MSEC WG.
A Reference Framework for covering the scope of the problems in [RFC2401] S. Kent, R. Atkinson, Security Architecture for the
multicast security was introduced, and a division of labor along Internet Protocol, November 1998.
three Functional Areas pertaining to security was discussed. These
cover the treatment of data from a security perspective when it is to
be sent to a group, the management of keying material used to protect
the data and the policies governing a group.
This document also defined the notion of Group Security Associations [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet
(GSA), which is the foundation of the work on group key management in Security Association and Key Management Protocol, November 1998.
the MSEC Working Group.
8. Acknowledgments [RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE),
November, 1998.
This document was derived from an IRTF SMuG Working Group draft that 10.2 Informative References
was originally co-authored by Thomas Hardjono, Ran Canetti, Mark
Baugher, and Pete Dinsmore.
9. References [ACLNM] J. Arkko, et. al., MIKEY: Multimedia Internet KEYing, draft-
ietf-msec-mikey-06.txt, February, 2003. Work in Progress.
9.1 Normative References [BCCR] M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, MESP: A
Multicast Framework for the Ipsec ESP, draft-ietf-msec-mesp-01.txt.
IETF, October 2002. Work in Progress.
[BCDL] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, Group Key [BCDL] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, Group Key
Management Architecture, draft-ietf-msec-gkmarch-03.txt. IETF, Management Architecture, draft-ietf-msec-gkmarch-04.txt. IETF, March
October 2002. Work in Progress. 2003. Work in Progress.
[HSC] H. Harney, A. Schuett, A. Colegrove, GSAKMP Light. draft-ietf-
msec-gsakmp-light-sec-01.txt. IETF, July 2002. Work in Progress.
[BHHW] M. Baugher, T. Hardjono, H. Harney, B. Weis, The Group Domain [BHHW] M. Baugher, T. Hardjono, H. Harney, B. Weis, The Group Domain
of Interpretation, draft-ietf-msec-gdoi-06.txt. IETF, February 2002. of Interpretation, draft-ietf-msec-gdoi-07.txt. IETF, December 2002.
Work in Progress. Work in Progress.
Hardjono, Weis Expires May, 2003 19
MSEC Architecture October, 2002
[BCCR] M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, MESP: Multicast
Encapsulating Security Payload, draft-ietf-msec-mesp-00.txt. IETF,
October 2002. Work in Progress.
[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.
9.2 Informative References
[BMS] D. Balenson, D. McGrew, A. Sherman, Key Management for Large [BMS] D. Balenson, D. McGrew, A. Sherman, Key Management for Large
Dynamic Groups: One-Way Function Trees and Amortized Initialization, Dynamic Groups: One-Way Function Trees and Amortized Initialization,
http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft- http://www.securemulticast.org/draft-balenson-groupkeymgmt-oft-
00.txt, February 1999, Work in Progress. 00.txt, February 1999, Work in Progress.
[CP99] R. Canetti and B. Pinkas, A taxonomy of multicast security Hardjono, Weis Expires November, 2003 19
issues, http://search.ietf.org/internet-drafts/draft-irtf-smug- MSEC Architecture May, 2003
taxonomy-01.txt, April 1999, Work in Progress.
[CCPRRS] Canetti, R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi
P., Saha D., "An architecture for secure IP multicast", NDSS 2000.
[Din] Dinsmore, P., Balenson, D., Heyman, M., Kruus, P., Scace, C., [Din] Dinsmore, P., Balenson, D., Heyman, M., Kruus, P., Scace, C.,
and Sherman, A., "Policy-Based Security Management for Large Dynamic and Sherman, A., "Policy-Based Security Management for Large Dynamic
Groups: An Oerview of the DCCM Project," DARPA Information Groups: An Overview of the DCCM Project," DARPA Information
Survivability Conference and Exposition, To Be Published. Survivability Conference and Exposition,
http://download.nai.com/products/media/nai/doc/discex-110199.doc.
[Har1] Harney, H., and Muckenhirn, C., "Group Key Management [Har1] Harney, H., and Muckenhirn, C., "Group Key Management
Protocol (GKMP) Specification," RFC 2093, July 1997. Protocol (GKMP) Specification," RFC 2093, July 1997.
[Har2] Harney, H., and Muckenhirn, C., "Group Key Management [Har2] Harney, H., and Muckenhirn, C., "Group Key Management
Protocol (GKMP) Architecture," RFC 2094, July 1997. Protocol (GKMP) Architecture," RFC 2094, July 1997.
[HH] H. Harney, E. Harder, Group Secure Association Key Management [HSMC] H. Harney, A. Schuett, U. Meth, A. Colegrove, GSAKMP. draft-
Protocol, http://search.ietf.org/internet-drafts/draft-harney- ietf-msec-gsakmp- sec-01.txt. IETF, February 2003. Work in Progress.
sparta-gsakmp-sec-00.txt, April 1999, Work in Progress.
[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," Proceedings of
the Eight USENIX Security Symposium, pp 99-113, August, 1999. the Eight USENIX Security Symposium, pp 99-113, August, 1999.
[RFC2246] Dierks, T. and C. Allen, The TLS Protocol Version 1.0, [PCW] A. Perrig, R. Canetti, B. Whillock, TESLA: Multicast Source
RFC 2246, January 1999. Authentication Transform Specification. draft-ietf-msec-tesla-spec-
00.txt. IETF, October 2002. Work in Progress.
[RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload [RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload
(ESP),November 1998. (ESP),November 1998.
[RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for
Security Association and Key Management Protocol, November 1998. Multicast: Issues and Architectures, September 1998.
[RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), [RFC2748] D. Durham, et. al., The COPS (Common Open Policy Service)
November, 1998. Protocol, January, 2000.
Hardjono, Weis Expires May, 2003 20 [RFC3019] B. Haberman, Worzella, R., IP Version 6 Management
MSEC Architecture October, 2002 Information Base for The Multicast Listener Discovery Protocol,
January, 2001.
[RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for [RFC3376] B. Cain, et. al., Internet Group Management Protocol,
Multicast: Issues and Architectures, September 1998. Version 3, October, 2002.
[STW] M. Steiner, Tsudik, G., Waidner, M., CLIQUES: A New Approach to
Group key Agreement, IEEE ICDCS'98 , May 1998.
Authors Addresses Authors Addresses
Hardjono, Weis Expires November, 2003 20
MSEC Architecture May, 2003
Thomas Hardjono Thomas Hardjono
VeriSign VeriSign
401 Edgewater Place, Suite 280 401 Edgewater Place, Suite 280
Wakefield, MA 01880 Wakefield, MA 01880
(781) 245-6996 (781) 245-6996
thardjono@verisign.com 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
(408) 526-4796 (408) 526-4796
bew@cisco.com bew@cisco.com
Hardjono, Weis Expires May, 2003 21 Hardjono, Weis Expires November, 2003 21
 End of changes. 

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