draft-ietf-msec-arch-02.txt   draft-ietf-msec-arch-03.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-02.txt Expires January 2004 draft-ietf-msec-arch-03.txt Expires February 2004
July 2003 August 2003
The Multicast Security 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
skipping to change at line 35 skipping to change at line 35
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 an overview and rationale of the multicast This document provides an overview and rationale of the multicast
security architecture used for large multicast groups. The document security architecture used for large multicast groups. The document
begins by introducing a Multicast Security Reference Framework, and begins by introducing a Multicast Security Reference Framework, and
proceeds to identify the security services may be part of a secure proceeds to identify the security services that may be part of a
multicast solution. secure multicast solution.
Hardjono, Weis Expires January, 2004 1 Hardjono, Weis Expires February, 2004 1
MSEC Architecture July, 2003 MSEC Architecture August, 2003
Table of Contents Table of Contents
1. Introduction.......................................................2 1. Introduction.......................................................2
1.1 Scope...........................................................3 1.1 Scope...........................................................3
1.2 Summary of Contents of Document.................................3 1.2 Summary of Contents of Document.................................3
1.3 Audience........................................................4 1.3 Audience........................................................4
1.4 Terminology.....................................................4 1.4 Terminology.....................................................4
2. Architectural Design: The Multicast Security Reference Framework...4 2. Architectural Design: The Multicast Security Reference Framework...5
2.1 The Reference Framework.........................................5 2.1 The Reference Framework.........................................5
2.2 Elements of the Reference Framework.............................6 2.2 Elements of the Reference Framework.............................6
2.2.1 Group Controller and Key Server.............................7 2.2.1 Group Controller and Key Server.............................7
2.2.2 Sender and Receiver.........................................7 2.2.2 Sender and Receiver.........................................7
2.2.3 Policy Server...............................................8 2.2.3 Policy Server...............................................8
2.2.4 Centralized and Distributed Designs.........................8 2.2.4 Centralized and Distributed Designs.........................8
3. Functional Areas...................................................8 3. Functional Areas...................................................8
3.1 Multicast Data..................................................8 3.1 Multicast Data Handling.........................................9
3.2 Management of Keying Material...................................9 3.2 Group Key Management............................................9
3.3 Multicast Security Policies....................................10 3.3 Multicast Security Policies....................................10
4. Group Security Associations (GSA).................................11 4. Group Security Associations (GSA).................................11
4.1 The Security Association.......................................11 4.1 The Security Association.......................................11
4.2 Structure of a GSA: Introduction...............................12 4.2 Structure of a GSA: Introduction...............................12
4.3 Structure of a GSA: Reasoning..................................12 4.3 Structure of a GSA: Reasoning..................................13
4.4 Definition of GSA..............................................13 4.4 Definition of GSA..............................................13
4.5 Typical Compositions of a GSA..................................15 4.5 Typical Compositions of a GSA..................................15
5. Security Services.................................................16 5. Security Services.................................................16
5.1 Multicast Data Confidentiality.................................16 5.1 Multicast Data Confidentiality.................................16
5.2 Multicast Source Authentication and Data Integrity.............17 5.2 Multicast Source Authentication and Data Integrity.............17
5.3 Multicast Group Authentication.................................17 5.3 Multicast Group Authentication.................................17
5.4 Multicast Group Membership Management..........................18 5.4 Multicast Group Membership Management..........................18
5.5 Multicast Key Management.......................................18 5.5 Multicast Key Management.......................................18
5.6 Multicast Policy Management....................................19 5.6 Multicast Policy Management....................................19
6. Security Considerations...........................................20 6. Security Considerations...........................................20
6.1 Multicast Data Handling........................................20
6.2 Group Key Management...........................................20
6.3 Multicast Security Policies....................................20
7. Acknowledgments...................................................20 7. Acknowledgments...................................................20
8. References........................................................20 8. References........................................................21
8.1 Normative References...........................................20 8.1 Normative References...........................................21
8.2 Informative References.........................................20 8.2 Informative References.........................................21
Authors Addresses....................................................22 Authors Addresses....................................................22
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
Hardjono, Weis Expires February, 2004 2
MSEC Architecture August, 2003
the solution. This document describes those functional areas, and how the solution. This document describes those functional areas, and how
they are related. they are related.
Hardjono, Weis Expires January, 2004 2
MSEC Architecture July, 2003
1.1 Scope 1.1 Scope
This architecture is concerned with the securing of large multicast This architecture is concerned with the securing of large multicast
groups. Whereas it can also be used for smaller groups, it is not groups. Whereas it can also be used for smaller groups, it is not
necessarily the most efficient means. Other architectures (e.g., the necessarily the most efficient means. Other architectures (e.g., the
Cliques architecture [STW]) can be more efficient for small ad-hoc Cliques architecture [STW]) can be more efficient for small ad-hoc
group communication. group communication.
This architecture is "end to end", and does not require multicast This architecture is "end to end", and does not require multicast
routing protocols (e.g., PIM [RFC2362]) to participate in this routing protocols (e.g., PIM [RFC2362]) to participate in this
architecture. Inappropriate routing may cause denial of service to architecture. Inappropriate routing may cause denial of service to
application layer groups that conform to this architecture, however application layer groups conforming to this architecture. However the
the routing cannot affect the authenticity or secrecy of group data routing cannot affect the authenticity or secrecy of group data or
or management packets. The multicast routing protocols could management packets. The multicast routing protocols could themselves
themselves use this architecture to protect their own multicast and use this architecture to protect their own multicast and group
group packets. However, this would be independent of any secure packets. However, this would be independent of any secure application
application layer group. layer group.
This architecture does not require IP multicast admission control This architecture does not require IP multicast admission control
protocols (e.g., IGMP [RFC3376], MLD [RFC3019]) to participate in protocols (e.g., IGMP [RFC3376], MLD [RFC3019]) to participate in
this architecture. As such, a "join" or "leave" operation for a this architecture. As such, a "join" or "leave" operation for a
secure group is independent of a "join" or "leave" of an IP multicast secure group is independent of a "join" or "leave" of an IP multicast
group. For example, the process of joining a secure group requires group. For example, the process of joining a secure group requires
being authenticated and authorized by a security device, while the being authenticated and authorized by a security device, while the
process of joining an IP multicast group entails contacting a process of joining an IP multicast group entails contacting a
multicast-aware router. Admission control protocols could themselves multicast-aware router. Admission control protocols could themselves
use this architecture to protect their own multicast packets. use this architecture to protect their own multicast packets.
However, this would be independent of any secure application layer However, this would be independent of any secure application layer
group. group.
This architecture does not explicitly describe how secure multicast This architecture does not explicitly describe how secure multicast
groups deal with Network Address Translation (NAT) [RFC2663]. groups deal with Network Address Translation (NAT) [RFC2663].
Generally speaking, NAT is not a problem with IP multicast traffic Generally speaking, NAT is not a problem with IP multicast traffic.
because multicast routing protocols often require the source of an IP This is true because multicast routing protocols generally require
multicast packet to remain unchanged in order to create distribution the source of an IP multicast packet to remain unchanged in order to
trees. However, if NAT is deployed in a network for IP multicast create distribution trees. However, if NAT is deployed in a network
packets, perhaps between administrative entities, then the for IP multicast packets (e.g., between administrative entities),
connectivity of senders and receivers may be affected. then the connectivity of senders and receivers may be adversely
affected.
This architecture dos not require the use of reliable mechanisms, for This architecture does not require the use of reliable mechanisms,
either data or management protocols. The use of reliable multicast for either data or management protocols. The use of reliable
routing techniques (e.g., FEC [RFC3453]) enhance the availability of multicast routing techniques (e.g., FEC [RFC3453]) enhance the
secure multicast groups, however the authenticity or secrecy of group availability of secure multicast groups. However the authenticity or
data or management packets is not affected by a lack of availability. secrecy of group data or management packets is not affected by the
omission of that capability from a deployment.
1.2 Summary of Contents of Document 1.2 Summary of Contents of Document
Hardjono, Weis Expires February, 2004 3
MSEC Architecture August, 2003
This document provides an architectural overview that outlines the This document provides an architectural overview that outlines the
security services required to secure large multicast groups. It security services required to secure large multicast groups. It
provides a Reference Framework for organizing the various elements provides a Reference Framework for organizing the various elements
within the architecture, and explains the elements of the Reference within the architecture, and explains the elements of the Reference
Framework. Framework.
Hardjono, Weis Expires January, 2004 3
MSEC Architecture July, 2003
The Reference Framework organizes the elements of the architecture The Reference Framework organizes the elements of the architecture
along three Functional Areas pertaining to security. These cover the along three Functional Areas pertaining to security. These elements
treatment of data from a security perspective when it is to be sent cover the treatment of data when it is to be sent to a group, the
to a group, the management of keying material used to protect the management of keying material used to protect the data, and the
data, and the policies governing a group. policies governing a group.
Another important item in this document is the definition and Another important item in this document is the definition and
explanation of Group Security Associations (GSA), which is the explanation of Group Security Associations (GSA), which is the
multicast counterpart of the unicast Security Association (SA). The multicast counterpart of the unicast Security Association (SA). The
GSA is specific to multicast security, and is the foundation of the GSA is specific to multicast security, and is the foundation of the
work on group key management. work on group key management.
1.3 Audience 1.3 Audience
This document is addressed to the technical community, implementers This document is addressed to the technical community, implementers
skipping to change at line 188 skipping to change at line 194
A bundling of Security Associations (SAs) that together define A bundling of Security Associations (SAs) that together define
how a group communicates securely. The GSA may include an how a group communicates securely. The GSA may include an
registration protocol SA, a rekey protocol SA, and one or more registration protocol SA, a rekey protocol SA, and one or more
data security protocol SAs. data security protocol SAs.
M-to-N M-to-N
A group which has many senders and many receivers, where M and N A group which has many senders and many receivers, where M and N
are not necessarily the same value. are not necessarily the same value.
Hardjono, Weis Expires February, 2004 4
MSEC Architecture August, 2003
Security Association (SA) Security Association (SA)
A set of policy and cryptographic keys that provide security A set of policy and cryptographic keys that provide security
services to network traffic that matches that policy. services to network traffic that matches that policy.
2. Architectural Design: The Multicast Security Reference Framework 2. Architectural Design: The Multicast Security Reference Framework
This section considers the complex issues of multicast security in This section considers the complex issues of multicast security in
the context of the Reference Framework diagram, shown in Figure 1. the context of the Reference Framework diagram, shown in Figure 1.
Hardjono, Weis Expires January, 2004 4
MSEC Architecture July, 2003
The Reference Framework is used to classify functional areas, The Reference Framework is used to classify functional areas,
functional elements, and interfaces. functional elements, and interfaces.
2.1 The Reference Framework 2.1 The Reference Framework
The reference framework is based on three broad functional areas The reference framework is based on three broad functional areas
(Figure 1). The reference framework incorporates the main entities (Figure 1). The reference framework incorporates the main entities
and functions relating to multicast security, and depicts the inter- and functions relating to multicast security, and depicts the inter-
relations among them. It also expresses multicast security from the relations among them. It also expresses multicast security from the
perspective of architectures (centralized and distributed), of perspective of architectures (centralized and distributed), of
skipping to change at line 244 skipping to change at line 249
Similarly, the Reference Framework acknowledges that some Similarly, the Reference Framework acknowledges that some
implementations may in fact merge a number of the "boxes" into a implementations may in fact merge a number of the "boxes" into a
single physical entity. This could be true even across functional single physical entity. This could be true even across functional
areas. For example, an entity in a group could act as both a Group areas. For example, an entity in a group could act as both a Group
Controller and a Sender to a group. Controller and a Sender to a group.
The 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 February, 2004 5
MSEC Architecture August, 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 January, 2004 5
MSEC Architecture July, 2003
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
| 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 297 skipping to change at line 303
The Reference Framework diagram of Figure 1 contains boxes and The Reference Framework diagram of Figure 1 contains boxes and
arrows. The boxes are the functional entities and the arrows are the arrows. The boxes are the functional entities and the arrows are the
interfaces between them. Standard protocols are needed for the interfaces between them. Standard protocols are needed for the
interfaces, which support the multicast services between the interfaces, which support the multicast services between the
functional entities. functional entities.
In some cases, a system implementing the multicast security In some cases, a system implementing the multicast security
architecture may not need to implement protocols to account for every architecture may not need to implement protocols to account for every
interface. Rather, those interfaces may be satisfied through the use interface. Rather, those interfaces may be satisfied through the use
Hardjono, Weis Expires February, 2004 6
MSEC Architecture August, 2003
of manual configuration, or even omitted if they are not necessary of manual configuration, or even omitted if they are not necessary
for the application. for the application.
There are three sets of functional entities in both centralized and There are three sets of functional entities in both centralized and
distributed designs as discussed below. distributed designs as discussed below.
Hardjono, Weis Expires January, 2004 6
MSEC Architecture July, 2003
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.
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 a primary GCKS entity (e.g., 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.
The Key Server (KS) and the Group Controller (GC) have somewhat The Key Server (KS) and the Group Controller (GC) have somewhat
different functionality and may in principle be regarded as separate different functionality and may in principle be regarded as separate
entities. Currently the framework regards the two entities as one entities. Currently the framework regards the two entities as one
"box" in order to simplify the design, and in order not to mandate "box" in order to simplify the design, and in order not to mandate
standardization of the protocol between the KS and the GC. It is standardization of the protocol between the KS and the GC. It is
skipping to change at line 353 skipping to change at line 360
the group, obtaining new keys during key-updates, and obtaining other the group, obtaining new keys during key-updates, and obtaining other
messages relating to the management of keying material and security messages relating to the management of keying material and security
parameters. parameters.
Senders and Receivers may receive much of their policy from the GCKS Senders and Receivers may receive much of their policy from the GCKS
entities. The event of joining a multicast group is typically coupled entities. The event of joining a multicast group is typically coupled
with the Sender/Receiver obtaining keying material from a GCKS with the Sender/Receiver obtaining keying material from a GCKS
entity. This does not preclude the direct interaction between the entity. This does not preclude the direct interaction between the
Sender/Receiver and the Policy Server. Sender/Receiver and the Policy Server.
Hardjono, Weis Expires February, 2004 7
MSEC Architecture August, 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 GCKS the situation where both the Sender and Receiver employ the same GCKS
entity (centralized architecture) and where the Sender and Receiver entity (centralized architecture) and where the Sender and Receiver
employ different GCKS entities (distributed architecture). employ different GCKS entities (distributed architecture).
Hardjono, Weis Expires January, 2004 7
MSEC Architecture July, 2003
2.2.3 Policy Server 2.2.3 Policy Server
The Policy Server represents both the entity and functions used to The Policy Server represents both the entity and functions used to
create and manage security policies specific to a multicast group. create and manage security policies specific to a multicast group.
The Policy Server interacts with the GCKS entity in order to install The Policy Server interacts with the GCKS entity in order to install
and manage the security policies related to the membership of a given and manage the security policies related to the membership of a given
multicast group and those related to keying material for a multicast multicast group and those related to keying material for a multicast
group. group.
The interactions between the Policy Server and other entities in the The interactions between the Policy Server and other entities in the
skipping to change at line 398 skipping to change at line 405
Internet. Internet.
3. Functional Areas 3. Functional Areas
The Reference Framework identifies three functional areas. They are: The Reference Framework identifies three functional areas. They are:
- Multicast data handling. This area covers the security-related - Multicast data handling. This area covers the security-related
treatments of multicast data by the sender and the receiver. This treatments of multicast data by the sender and the receiver. This
functional area is further discussed in Section 3.1. functional area is further discussed in Section 3.1.
Group Key Management. This area is concerned with the secure - Group Key Management. This area is concerned with the secure
distribution and refreshment of keying material. This functional distribution and refreshment of keying material. This 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 in - Multicast security policies. This area covers aspects of policy in
the context of multicast security, taking into consideration the the context of multicast security, taking into consideration the
fact that policies may be expressed in different ways, that they fact that policies may be expressed in different ways, that they
may exist at different levels in a given multicast security 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 February, 2004 8
MSEC Architecture August, 2003
implemented. This functional area is further discussed in Section implemented. This functional area is further discussed in Section
3.3. 3.3.
3.1 Multicast Data 3.1 Multicast Data Handling
In a secure multicast group, the data typically needs to be: In a secure multicast group, the data typically needs to be:
Hardjono, Weis Expires January, 2004 8
MSEC Architecture July, 2003
1. Encrypted using the group key, mainly for access control and 1. Encrypted using the group key, mainly for access control and
possibly also for confidentiality. possibly also for confidentiality.
2. Authenticated, for verifying the source and integrity of the 2. Authenticated, for verifying the source and integrity of the
data. Authentication takes two flavors: data. Authentication takes two flavors:
a. Source authentication and data integrity. This a. Source authentication and data integrity. This
functionality guarantees that the data originated with the functionality guarantees that the data originated with the
claimed source and was not modified en route (either by a claimed source and was not modified en route (either by a
group member or an external attacker). group member or an external attacker).
b. Group authentication. This type of authentication only b. Group authentication. This type of authentication only
skipping to change at line 450 skipping to change at line 458
Multicast data encrypted and/or authenticated by a sender should be Multicast data encrypted and/or authenticated by a sender should be
handled the same way by both centralized and distributed receivers, handled the same way by both centralized and distributed receivers,
(as shown in Figure 1). (as shown in Figure 1).
The "Multicast Encapsulating Security Payload" [BCCR] provides the The "Multicast Encapsulating Security Payload" [BCCR] provides the
definition for Multicast ESP for data traffic. The "Multicast Source definition for Multicast ESP for data traffic. The "Multicast Source
Authentication Transform Specification" [PCW] defines the use of the Authentication Transform Specification" [PCW] defines the use of the
TESLA algorithm for source authentication in multicast. TESLA algorithm for source authentication in multicast.
3.2 Management of Keying Material 3.2 Group Key Management
The term "keying material" refers to the cryptographic keys belonging The term "keying material" refers to the cryptographic keys belonging
to a group, the state associated with the keys, and the other to a group, the state associated with the keys, and the other
security parameters related to the keys. Hence, the management of security parameters related to the keys. Hence, the management of
the cryptographic keys belonging to a group necessarily requires the the cryptographic keys belonging to a group necessarily requires the
management of their associated state and parameters. A number of management of their associated state and parameters. A number of
solutions for specific issues must be addressed. These may include solutions for specific issues must be addressed. These may include
the following: the following:
Methods for member identification and authentication. - Methods for member identification and authentication.
Methods to verify the membership to groups. - Methods to verify the membership to groups.
Methods to establish a secure channel between a GCKS entity and
Hardjono, Weis Expires February, 2004 9
MSEC Architecture August, 2003
- Methods to establish a secure channel between a GCKS entity and
the member, for the purpose of delivery of shorter-term keying the member, for the purpose of delivery of shorter-term keying
material pertaining to a group. material pertaining to a group.
Methods to establish a long-term secure channel between one GCKS - Methods to establish a long-term secure channel between one GCKS
entity and another, for the purpose of distributing shorter-term entity and another, for the purpose of distributing shorter-term
keying material pertaining to a group. keying material pertaining to a group.
Methods to effect the changing of keys and keying material - Methods to effect the changing of keys and keying material
- Methods to detect and signal failures and perceived compromises to
Hardjono, Weis Expires January, 2004 9
MSEC Architecture July, 2003
Methods to detect and signal failures and perceived compromises to
keys and keying material keys and keying material
The requirements related to the management of keying material must be The requirements related to the management of keying material must be
seen in the context of the policies that prevail within the given seen in the context of the policies that prevail within the given
circumstance. circumstance.
Core to the area of key management is Security Association (SA) Core to the area of key management is Security Association (SA)
Management, which will be discussed further below. Management, which will be discussed further below.
A "Group Key Management Architecture" document [BCDL] further defines A "Group Key Management Architecture" document [BCDL] further defines
the key management architecture for multicast security. It builds on the key management architecture for multicast security. It builds on
the Group Security Association (GSA) concept, and further defines the the Group Security Association (GSA) concept, and further defines the
roles of the Key Server and Group Controller. roles of the Key Server and Group Controller.
"The Group Domain of Interpretation" [BHHW], "GSAKMP" [HSMC], and "The Group Domain of Interpretation" [RFC3547], "GSAKMP" [HSMC], and
"MIKEY" [ACLNM] are three instances of protocols implementing the "MIKEY" [ACLNM] are three instances of protocols implementing the
group key management function. 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. Security Policies may the other elements of the Reference Framework. Security Policies may
be distributed in an ad-hoc fashion in some instances. However, be distributed in an ad-hoc fashion in some instances. However,
better coordination and higher levels of assurance are achieved if a better coordination and higher levels of assurance are achieved if a
Policy Controller distributes Security Policies policy to the group. Policy Controller distributes Security Policies policy to the group.
skipping to change at line 516 skipping to change at line 524
operations would include the conditions when a group member must be operations would include the conditions when a group member must be
forcibly removed from the group, and what to do if the group members forcibly removed from the group, and what to do if the group members
need to resynchronize because of lost key management messages. need to resynchronize because of lost key management messages.
The application of policy at the Group Controller element and the The application of policy at the Group Controller element and the
member (sender and receiver) elements must be described. While there member (sender and receiver) elements must be described. While there
is already a basis for security policy management in the IETF, is already a basis for security policy management in the IETF,
multicast security policy management extends the concepts developed multicast security policy management extends the concepts developed
for unicast communication in the areas of: 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 February, 2004 10
MSEC Architecture August, 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
Hardjono, Weis Expires January, 2004 10
MSEC Architecture July, 2003
unicast policy frameworks. Secure multicast groups are usually large unicast policy frameworks. Secure multicast groups are usually large
and by their very nature extend over several administrative domains, and by their very nature extend over several administrative domains,
if not spanning a different domain for each user. There are several if not spanning a different domain for each user. There are several
methods that need to be considered in the creation of a single, methods that need to be considered in the creation of a single,
coherent group security policy. They include a top-down specification coherent group security policy. They include a top-down specification
of the group policy from the group initiator and negotiation of the of the group policy from the group initiator and negotiation of the
policy between the group members (or prospective members). policy between the group members (or prospective members).
Negotiation can be as simple as a strict intersection of the policies Negotiation can be as simple as a strict intersection of the policies
of the members or extremely complicated using weighted voting of the members or extremely complicated using weighted voting
systems. systems.
skipping to change at line 567 skipping to change at line 574
It is also important that policy negotiation and translation be It is also important that policy negotiation and translation be
performed as an integral part of joining a group. Adding a member to performed as an integral part of joining a group. Adding a member to
a group is meaningless if they will not be able to participate in the a group is meaningless if they will not be able to participate in the
group communications. group communications.
4. Group Security Associations (GSA) 4. Group Security Associations (GSA)
4.1 The Security Association 4.1 The Security Association
A security association is a commonly used term in cryptographic A security association is a commonly used term in cryptographic
systems (e.g., [RFC2401, [RFC2406bis], RFC2409]). This document uses systems (e.g., [RFC2401, RFC2406bis, RFC2409]). This document uses
the term to mean any set of policy and cryptographic keys that the term to mean any set of policy and cryptographic keys that
provide security services for the network traffic matching that provide security services for the network traffic matching that
policy. A Security Association usually contains the following policy. A Security Association usually contains the following
attributes: attributes:
- selectors, such as source and destination transport addresses. - selectors, such as source and destination transport addresses.
- properties, such as an security parameter index (SPI) or cookie - properties, such as an security parameter index (SPI) or cookie
pair, and identities. pair, and identities.
Hardjono, Weis Expires February, 2004 11
MSEC Architecture August, 2003
- cryptographic policy, such as the algorithms, modes, key - cryptographic policy, such as the algorithms, modes, key
lifetimes, and key lengths used for authentication or lifetimes, and key lengths used for authentication or
confidentiality. confidentiality.
- keys, such as authentication, encryption and signing keys. - keys, such as authentication, encryption and signing keys.
Group key management uses a different set of abstractions than point- Group key management uses a different set of abstractions than point-
to-point key management systems, such as IKE [RFC2409]. to-point key management systems (such as IKE [RFC2409]).
Hardjono, Weis Expires January, 2004 11
MSEC Architecture July, 2003
Notwithstanding, the abstractions used in the Group Key Management Notwithstanding, the abstractions used in the Group Key Management
functional area may be built from the point-to-point key management functional area may be built from the point-to-point key management
abstractions. abstractions.
4.2 Structure of a GSA: Introduction 4.2 Structure of a GSA: Introduction
Security associations (SAs) for group key management are more Security associations (SAs) for group key management are more
complex, and are usually more numerous, than for point-to-point key complex, and are usually more numerous, than for point-to-point key
management algorithms. The latter establishes a key management SA to management algorithms. The latter establishes a key management SA to
protect application SAs (usually one or two, depending on the protect application SAs (usually one or two, depending on the
protocol). However, group key management may require up to three or protocol). However, group key management may require up to three or
more SAs. These SAs are described in later sections. more SAs. These SAs are described in later sections.
A GSA contains all of the SA attributes identified in the previous A GSA contains all of the SA attributes identified in the previous
section, as well some additional attributes pertaining to the group. section, as well some additional attributes pertaining to the group.
As shown in Figure 2, the GSA builds on the SA in two distinct ways. 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 - First, the GSA is a superset of an SA (Figure 2(a)). A GSA has
group policy attributes, such as the kind of signed credential group policy attributes. For example, the kind of signed
needed for group membership, if group members will be given new credential needed for group membership, whether group members will
keys when a member is added (called "backward re-key" below), or be given new keys when a member is added (called "backward re-key"
whether group members will be given new key when a member is below), or whether group members will be given new key when a
removed from the group ("forward re-key"). A GSA also includes an member is removed from the group ("forward re-key"). A GSA also
SA as an attribute of itself. includes an SA as an attribute of itself.
Second, the GSA is an aggregation of SAs (Figure 2(b)). A GSA is - Second, the GSA is an aggregation of SAs (Figure 2(b)). A GSA is
comprised of multiple SAs, and these SAs may be used for several comprised of multiple SAs, and these SAs may be used for several
independent purposes. independent purposes.
+------------------------------------------------------------+ +------------------------------------------------------------+
| | | |
| +---------------+ +-------------------+ | | +---------------+ +-------------------+ |
| | GSA | | GSA | | | | GSA | | GSA | |
| | | | +-----+ +-----+ | | | | | | +-----+ +-----+ | |
| | | | | SA1 | | SA2 | | | | | | | | SA1 | | SA2 | | |
| | +----+ | | +-----+ +-----+ | | | | +----+ | | +-----+ +-----+ | |
| | | SA | | | +-----+ | | | | | SA | | | +-----+ | |
| | +----+ | | | SA3 | | | | | +----+ | | | SA3 | | |
| | | | +-----+ | | | | | | +-----+ | |
| +---------------+ +-------------------+ | | +---------------+ +-------------------+ |
| | | |
| (a) superset (b) aggregation | | (a) superset (b) aggregation |
| | | |
+------------------------------------------------------------+ +------------------------------------------------------------+
Figure 2: Relationship of GSA to SA Figure 2: Relationship of GSA to SA
Hardjono, Weis Expires February, 2004 12
MSEC Architecture August, 2003
4.3 Structure of a GSA: Reasoning 4.3 Structure of a GSA: Reasoning
Figure 3 shows three categories of SAs that can be aggregated into a Figure 3 shows three categories of SAs that can be aggregated into a
GSA. GSA.
Hardjono, Weis Expires January, 2004 12
MSEC Architecture July, 2003
+------------------------------------------------------------+ +------------------------------------------------------------+
| | | |
| +------------------+ | | +------------------+ |
| | GCKS | | | | GCKS | |
| | | | | | | |
| | REG REG | | | | REG REG | |
| | / REKEY \ | | | | / REKEY \ | |
| +---/-----|----\---+ | | +---/-----|----\---+ |
| / | \ | | / | \ |
| / | \ | | / | \ |
skipping to change at line 667 skipping to change at line 674
| | SENDER | | 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
The three categories of SAs are: The three categories of SAs are:
Registration SA (REG): A separate unicast SA between the GCKS and - Registration SA (REG): A separate unicast SA between the GCKS and
each group member, regardless of whether the group member is a each group member, regardless of whether the group member is a
sender or a receiver or acting in both roles. sender or a receiver or acting in both roles.
Re-key SA (REKEY): A single multicast SA between the GCKS and all - Re-key SA (REKEY): A single multicast SA between the GCKS and all
of the group members. of the group members.
Data Security SA (DATA): A multicast SA between each multicast - Data Security SA (DATA): A multicast SA between each multicast
source speaker and the group's receivers. There are as many data source speaker and the group's receivers. There are as many data
SA as there are multicast sources allowed by the group's policy. SA as there are multicast sources allowed by the group's policy.
Each of these SAs are defined in more detail in the next section. Each of these SAs are defined in more detail in the next section.
4.4 Definition of GSA 4.4 Definition of GSA
The three categories of SAs correspond to three different kinds of The three categories of SAs correspond to three different kinds of
communications commonly required for group communications. This communications commonly required for group communications. This
section describes the SAs depicted in Figure 3 in detail. section describes the SAs depicted in Figure 3 in detail.
Hardjono, Weis Expires January, 2004 13 Hardjono, Weis Expires February, 2004 13
MSEC Architecture July, 2003 MSEC Architecture August, 2003
- Registration SA (REG): - Registration SA (REG):
An SA is required for (bi-directional) unicast communications An SA is required for (bi-directional) unicast communications
between the GCKS and a group member (be it a Sender or Receiver). between the GCKS and a group member (be it a Sender or Receiver).
This SA is established only between the GCKS and a Member. The This SA is established only between the GCKS and a Member. The
GCKS entity is charged with access control to the group keys, GCKS entity is charged with access control to the group keys,
with 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, common in a number of group key management environments [RFC3547,
HSMC, CCPRRS, RFC2627, BMS,]. HSMC, CCPRRS, RFC2627, BMS,].
The Registration SA is initiated by the member to pull GSA The Registration SA is initiated by the member to pull GSA
information from the GCKS. This is how the member requests to information from the GCKS. This is how the member requests to
join the secure group, or has its GSA keys re-initialized after join the secure group, or has its GSA keys re-initialized after
being disconnected from the group (e.g., when its host computer being disconnected from the group (e.g., when its host computer
has been turned off during re-key operations). The GSA has been turned off during re-key operations). The GSA
information pulled down from the GCKS is related to the other two information pulled down from the GCKS is related to the other two
SAs defined as part of the GSA. SAs defined as part of the GSA.
skipping to change at line 743 skipping to change at line 750
In some cases, a GCKS needs the ability to "push" new SAs as part 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 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 other cases, the GCKS needs the ability to quickly revoke access
to one or more group members. Both of these needs are satisfied to one or more group members. Both of these needs are satisfied
with the Re-key SA. with the Re-key SA.
This Re-key SA is a unidirectional multicast transmission of key This Re-key SA is a unidirectional multicast transmission of key
management messages from the GCKS to all group members. As such, management messages from the GCKS to all group members. As such,
this SA is known by the GCKS and by all members of the group. this SA is known by the GCKS and by all members of the group.
Hardjono, Weis Expires January, 2004 14 Hardjono, Weis Expires February, 2004 14
MSEC Architecture July, 2003 MSEC Architecture August, 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.
A rekey SA is not absolutely required to be part of a GSA. For A rekey SA is not absolutely required to be part of a GSA. For
example, the lifetime of some groups may be short enough such example, the lifetime of some groups may be short enough such
that a rekey is not necessary. Conversely, the policy for the that a rekey is not necessary. Conversely, the policy for the
group could specify multiple rekey SAs of different types. For group could specify multiple rekey SAs of different types. For
example, if the GC and KS are separate entities, the GC may example, if the GC and KS are separate entities, the GC may
skipping to change at line 798 skipping to change at line 805
security SA. security SA.
3. A combination of 1. and 2. 3. A combination of 1. and 2.
4.5 Typical Compositions of a GSA 4.5 Typical Compositions of a GSA
Depending on the multicast group policy, many compositions of a GSA Depending on the multicast group policy, many compositions of a GSA
are possible. For illustrative purposes, this section describes a few are possible. For illustrative purposes, this section describes a few
possible compositions. possible compositions.
Hardjono, Weis Expires January, 2004 15 Hardjono, Weis Expires February, 2004 15
MSEC Architecture July, 2003 MSEC Architecture August, 2003
A group of memory-constrained members may require only a REG SA, - A group of memory-constrained members may require only a REG SA,
and a single DATA SA. and a single DATA SA.
A "pay-per-session" application, where all of the SA information - A "pay-per-session" application, where all of the SA information
needed for the session may be distributed over a REG SA. Re-key needed for the session may be distributed over a REG SA. Re-key
and re-initialization of DATA SAs may not be necessary, so there and re-initialization of DATA SAs may not be necessary, so there
is no REKEY SA. is no REKEY SA.
A subscription group, where keying material is changed as - A subscription group, where keying material is changed as
membership changes. A REG SA is needed to distribute other SAs; a membership changes. A REG SA is needed to distribute other SAs; a
REKEY SA is needed to re-initialize a DATA SA at the time REKEY SA is needed to re-initialize a DATA SA at the time
membership changes. membership changes.
5. Security Services 5. Security Services
Referring to the Reference Diagram, this section identifies security This section identifies security services for designated interfaces
services for designated interfaces of Figure 1. In this section, of Figure 1. Distinct security services are assigned to specific
distinct security services are assigned to specific interfaces. For interfaces. For example, multicast source authentication, data
example, multicast source authentication, data authentication, and authentication, and confidentiality occur on the multicast data
confidentiality occur on the multicast data interface between Senders interface between Senders and Receivers in Figure 1. Authentication
and Receivers in Figure 1. Authentication and confidentiality and confidentiality services may also be needed between the Key
services may also be needed between the Key Server and key clients Server and key clients (i.e., the Senders and Receivers of Figure 1),
(i.e., the Senders and Receivers of Figure 1), but the services that but the services that are needed for multicast key management may be
are needed for multicast key management may be unicast as well as unicast as well as multicast. A security service in the Multicast
multicast. A security service for multicast security, therefore, Security Reference Framework therefore identifies a specific function
identifies a specific function along one or more Figure 1 interfaces. 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, that work will occur application-layer multicast security. Instead, that work will occur
as the security services are further defined and realized in as the security services are further defined and realized in
algorithms and protocols. algorithms and protocols.
5.1 Multicast Data Confidentiality 5.1 Multicast Data Confidentiality
skipping to change at line 855 skipping to change at line 862
multicast traffic. Since this traffic will usually be connectionless multicast traffic. Since this traffic will usually be connectionless
UDP flows, stream ciphers may be unsuitable, though hybrid UDP flows, stream ciphers may be unsuitable, though hybrid
stream/block ciphers may have advantages over some block ciphers. stream/block ciphers may have advantages over some block ciphers.
Regarding application-layer multicast, some consideration is needed Regarding application-layer multicast, some consideration is needed
to consider the effects of sending encrypted data in a multicast to consider the effects of sending encrypted data in a multicast
environment lacking admission-control, where practically any environment lacking admission-control, where practically any
application program can join a multicast event independently of its application program can join a multicast event independently of its
participation in a multicast security protocol. Thus, this security participation in a multicast security protocol. Thus, this security
Hardjono, Weis Expires January, 2004 16 Hardjono, Weis Expires February, 2004 16
MSEC Architecture July, 2003 MSEC Architecture August, 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. Effects to both senders and receivers is considered. 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
skipping to change at line 909 skipping to change at line 916
are not trusted. are not trusted.
The advantage of group authentication is that it is guaranteed via The advantage of group authentication is that it is guaranteed via
relatively simple and efficient cryptographic transforms. Therefore, relatively simple and efficient cryptographic transforms. Therefore,
when source authentication is not paramount, group authentication when source authentication is not paramount, group authentication
becomes useful. In addition, performing group authentication is becomes useful. In addition, performing group authentication is
useful even when source authentication is later performed: it useful even when source authentication is later performed: it
provides a simple-to-verify weak integrity check that is useful as a provides a simple-to-verify weak integrity check that is useful as a
measure against denial-of-service attacks. measure against denial-of-service attacks.
Hardjono, Weis Expires January, 2004 17 Hardjono, Weis Expires February, 2004 17
MSEC Architecture July, 2003 MSEC Architecture August, 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.4 Multicast Group Membership Management 5.4 Multicast Group Membership Management
This security service describes the functionality of registration of This security service describes the functionality of registration of
members with the Group Controller, and de-registration of members members with the Group Controller, and de-registration of members
from the Group Controller. These are security functions, which are from the Group Controller. These are security functions, which are
skipping to change at line 966 skipping to change at line 973
- Updating of current keying material, depending on circumstances - Updating of current keying material, depending on circumstances
and policies. and policies.
- Termination of groups in a secure manner, including the - Termination of groups in a secure manner, including the
multicast group itself and the associated keying material. multicast group itself and the associated keying material.
Among the responsibilities of this security service is the secure Among the responsibilities of this security service is the secure
management of keys between Key Servers and Clients, the addressing management of keys between Key Servers and Clients, the addressing
issues for the multicast distribution of keying material, and the issues for the multicast distribution of keying material, and the
scalability or other performance requirements for multicast key scalability or other performance requirements for multicast key
Hardjono, Weis Expires January, 2004 18 Hardjono, Weis Expires February, 2004 18
MSEC Architecture July, 2003 MSEC Architecture August, 2003
management [RFC2627, BMS]. Key Servers and Clients may take advantage management [RFC2627, BMS]. Key Servers and Clients may take advantage
of a common Public Key Infrastructure (PKI) for increased scalability of a common Public Key Infrastructure (PKI) for increased scalability
of authentication and authorization. of authentication and authorization.
To allow for an interoperable and secure IP multicast security To allow for an interoperable and secure IP multicast security
protocol, this security service may need to specify host abstractions protocol, this security service may need to specify host abstractions
such as a group security association database (GSAD) and a group such as a group security association database (GSAD) and a group
security policy database (GSPD) for IP multicast security. The security policy database (GSPD) for IP multicast security. The
degree of overlap between IP multicast and application-layer degree of overlap between IP multicast and application-layer
multicast key management needs to be considered. Thus, this security multicast key management needs to be considered. Thus, this security
service takes into account the key management requirements for IP service takes into account the key management requirements for IP
multicast, the key management requirements for application-layer multicast, the key management requirements for application-layer
multicast, and to what degree specific realizations of a Multicast multicast, and to what degree specific realizations of a Multicast
Key Management security service can satisfy both. ISAKMP, moreover, Key Management security service can satisfy both. ISAKMP, moreover,
has been designed to be extensible to multicast key management for has been designed to be extensible to multicast key management for
both IP multicast and application-layer multicast security [RFC2408]. both IP multicast and application-layer multicast security [RFC2408].
Thus, multicast key management protocols may use the existing ISAKMP Thus, multicast key management protocols may use the existing ISAKMP
standard's Phase 1 and Phase 2 protocols, possibly with needed standard's Phase 1 and Phase 2 protocols, possibly with needed
extensions (such as GDOI [BHHW] or application-layer multicast extensions (such as GDOI [RFC3547] 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 GCKS servers communication related to key management among different GCKS servers
in a distributed group design. in a distributed group design.
Multicast Key Management appears in both the centralized and Multicast Key Management appears in both the centralized and
distributed designs as shown in Figure 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.
skipping to change at line 1012 skipping to change at line 1019
policy. Indeed, one of the first tasks in further defining this policy. Indeed, one of the first tasks in further defining this
security service is identifying the different areas of multicast security service is identifying the different areas of multicast
policy. Multicast Policy Management includes the design of the policy policy. Multicast Policy Management includes the design of the policy
server for multicast security, the particular policy definitions that server for multicast security, the particular policy definitions that
will be used for IP multicast and application-layer multicast will be used for IP multicast and application-layer multicast
security, and the communication protocols between the Policy Server security, and the communication protocols between the Policy Server
and the Key Server. This security service may be realized using a and the Key Server. This security service may be realized using a
standard policy infrastructure such as a Policy Decision Point (PDP) standard policy infrastructure such as a Policy Decision Point (PDP)
and Policy Enforcement Point (PEP) architecture [RFC2748]. Thus, it and Policy Enforcement Point (PEP) architecture [RFC2748]. Thus, it
may not be necessary to re-invent a separate architecture for may not be necessary to re-invent a separate architecture for
multicast security policy; this work will evaluate use of the multicast security policy. At minimum, however, this security service
products of IETF efforts in the areas of network and security policy. will be realized in a set of policy definitions, such as multicast
At minimum, however, this security service will be realized in a set security conditions and actions.
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 GCKS 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
Hardjono, Weis Expires January, 2004 19
MSEC Architecture July, 2003
definition and their permissible uses, and other information. This definition and their permissible uses, and other information. This
security service also describes communication between and among security service also describes communication between and among
Hardjono, Weis Expires February, 2004 19
MSEC Architecture August, 2003
Policy Servers. Group members are not expected to directly Policy Servers. Group members are not expected to directly
participate in this security service. However, this option is not participate in this security service. However, this option is not
ruled out. ruled out.
6. Security Considerations 6. Security Considerations
This document describes methods and guidelines for protecting This document describes an architectural framework for protecting
multicast and group traffic with cryptographic protocols. multicast and group traffic with cryptographic protocols. Three
functional areas are identified within the framework. Each functional
area has unique security considerations, and these are discussed
below.
This architectural framework is end-to-end, and does not rely upon
the network that connects group controllers and group members. As
such, denial of service, message deletion, and other active attacks
on the unicast or multicast routing infrastructures are not addressed
by this framework.
6.1 Multicast Data Handling
Cryptographic protocols protecting multicast data are responsible for
providing confidentiality, group authentication, and replay
protection. They should also be able to provide source authentication
to uniquely identify senders to the group. Section 3.1 elaborates on
the security requirements for this area.
6.2 Group Key Management
Group key management protocols provide cryptographic keys and policy
to group members. They are responsible for authenticating and
authorizing group members before revealing those keys, and for
providing confidentiality and authentication of those keys during
transit. They are also responsible for providing a means for rekeying
the group, in the case that the policy specifies a lifetime for the
keys. They also are responsible for revocation of group membership,
once one or more group members have had their authorization to be a
group member revoked. Section 3.2 describes the security requirements
of this area in more detail.
6.3 Multicast Security Policies
Cryptographic protocols providing multicast security policies are
responsible for distributing that policy such that the integrity of
the policy is maintained. If the policy itself is confidential, they
also are responsible for authenticating group controllers and group
members, and providing confidentiality of the policy during transit.
7. Acknowledgments 7. Acknowledgments
Much of the text in this document was derived from two research Much of the text in this document was derived from two research
papers. The framework for this document came from a paper co-authored papers. The framework for this document came from a paper co-authored
by Thomas Hardjono, Ran Canetti, Mark Baugher, and Pete Dinsmore. by Thomas Hardjono, Ran Canetti, Mark Baugher, and Pete Dinsmore.
Description of the GSA came from a document co-authored by Hugh Description of the GSA came from a document co-authored by Hugh
Harney, Mark Baugher, and Thomas Hardjono.
Hardjono, Weis Expires February, 2004 20
MSEC Architecture August, 2003
Harney, Mark Baugher, and Thomas Hardjono. George Gross suggested a
number of improvements that were included in later versions of this
document.
8. References 8. References
8.1 Normative References 8.1 Normative References
[RFC2401] S. Kent, R. Atkinson, Security Architecture for the [RFC2401] S. Kent, R. Atkinson, Security Architecture for the
Internet Protocol, November 1998. Internet Protocol, November 1998.
[RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet
Security Association and Key Management Protocol, November 1998. Security Association and Key Management Protocol, November 1998.
[RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), [RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE),
November, 1998. November, 1998.
[RFC3552] E. Rescorla, et. al., Guidelines for Writing RFC Text on
Security Considerations, RFC 3552, July 2003.
8.2 Informative References 8.2 Informative References
[ACLNM] J. Arkko, et. al., MIKEY: Multimedia Internet KEYing, draft- [ACLNM] J. Arkko, et. al., MIKEY: Multimedia Internet KEYing, draft-
ietf-msec-mikey-06.txt, February, 2003. Work in Progress. ietf-msec-mikey-06.txt, February, 2003. Work in Progress.
[BCCR] M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, MESP: A [BCCR] M. Baugher, R. Canetti, P. Cheng, P. Rohatgi, MESP: A
Multicast Framework for the Ipsec ESP, draft-ietf-msec-mesp-01.txt. Multicast Framework for the Ipsec ESP, draft-ietf-msec-mesp-01.txt.
IETF, October 2002. Work in Progress. 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-04.txt. IETF, March Management Architecture, draft-ietf-msec-gkmarch-04.txt. March 2003.
2003. Work in Progress.
[BHHW] M. Baugher, T. Hardjono, H. Harney, B. Weis, The Group Domain
of Interpretation, draft-ietf-msec-gdoi-07.txt. IETF, December 2002.
Work in Progress. Work in Progress.
Hardjono, Weis Expires January, 2004 20
MSEC Architecture July, 2003
[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.securemulticast.org/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.
[CCPRRS] Canetti, R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi [CCPRRS] Canetti, R., Cheng P. C., Pendarakis D., Rao, J., Rohatgi
P., Saha D., "An IPSec-based Host Architecture for Secure Internet P., Saha D., "An IPSec-based Host Architecture for Secure Internet
Multicast", Multicast",
www.isoc.org/isoc/conferences/ndss/2000/proceedings/028.pdf, NDSS http://www.isoc.org/isoc/conferences/ndss/2000/proceedings/028.pdf,
2000. 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 Overview of the DCCM Project," DARPA Information Groups: An Overview of the DCCM Project," DARPA Information
Survivability Conference and Exposition, Survivability Conference and Exposition,
http://download.nai.com/products/media/nai/doc/discex-110199.doc. 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.
Hardjono, Weis Expires February, 2004 21
MSEC Architecture August, 2003
[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.
[HSMC] H. Harney, A. Schuett, U. Meth, A. Colegrove, GSAKMP. draft- [HSMC] H. Harney, A. Schuett, U. Meth, A. Colegrove, GSAKMP. draft-
ietf-msec-gsakmp-sec-01.txt. IETF, February 2003. Work in Progress. ietf-msec-gsakmp-sec-01.txt. February 2003. 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.
[PCW] A. Perrig, R. Canetti, B. Whillock, TESLA: Multicast Source [PCW] A. Perrig, R. Canetti, B. Whillock, TESLA: Multicast Source
Authentication Transform Specification. draft-ietf-msec-tesla-spec- Authentication Transform Specification. draft-ietf-msec-tesla-spec-
00.txt. IETF, October 2002. Work in Progress. 00.txt. IETF, October 2002. Work in Progress.
[RFC2362] Estrin, D., et. al., Protocol Independent Multicast-Sparse [RFC2362] Estrin, D., et. al., Protocol Independent Multicast-Sparse
Mode (PIM-SM): Protocol Specification, RFC 2362, June, 1998. Mode (PIM-SM): Protocol Specification, RFC 2362, June, 1998.
[RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload [RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload
(ESP), RFC 2406, November 1998. (ESP), RFC 2406, November 1998.
[RFC2406bis] S. Kent, IP Encapsulating Security Payload (ESP), [RFC2406bis] S. Kent, IP Encapsulating Security Payload (ESP),
draft-ietf-ipsec-esp-v3-04.txt, IETF, March 2003. Work In Progress. draft-ietf-ipsec-esp-v3-04.txt, March 2003. Work In Progress.
[RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for
Multicast: Issues and Architectures, September 1998. Multicast: Issues and Architectures, RFC 2627, September 1998.
[RFC2663] P. Srisuresh, M. Holdrege, IP Network Address Translator [RFC2663] P. Srisuresh, M. Holdrege, IP Network Address Translator
(NAT) Terminology and Considerations, RFC 2663, August 1999. (NAT) Terminology and Considerations, RFC 2663, August 1999.
Hardjono, Weis Expires January, 2004 21
MSEC Architecture July, 2003
[RFC2748] D. Durham, et. al., The COPS (Common Open Policy Service) [RFC2748] D. Durham, et. al., The COPS (Common Open Policy Service)
Protocol, January, 2000. Protocol, RFC 2748, January, 2000.
[RFC3019] B. Haberman, Worzella, R., IP Version 6 Management [RFC3019] B. Haberman, Worzella, R., IP Version 6 Management
Information Base for The Multicast Listener Discovery Protocol, Information Base for The Multicast Listener Discovery Protocol, RFC
January, 2001. 3019, January, 2001.
[RFC3376] B. Cain, et. al., Internet Group Management Protocol, [RFC3376] B. Cain, et. al., Internet Group Management Protocol,
Version 3, October, 2002. Version 3, RFC 3376, October, 2002.
[RFC3453] M. Luby, et. al., The Use of Forward Error Correction [RFC3453] M. Luby, et. al., The Use of Forward Error Correction
(FEC) in Reliable Multicast, RFC 3453, December 2002. (FEC) in Reliable Multicast, RFC 3453, December 2002.
[RFC3547] M. Baugher, B. Weis, T. Hardjono, H. Harney, , The Group
Domain of Interpretation, RFC 3547, December 2002.
[STW] M. Steiner, Tsudik, G., Waidner, M., CLIQUES: A New Approach to [STW] M. Steiner, Tsudik, G., Waidner, M., CLIQUES: A New Approach to
Group key Agreement, IEEE ICDCS'98 , May 1998. Group key Agreement, IEEE ICDCS'98 , May 1998.
Authors Addresses Authors Addresses
Hardjono, Weis Expires February, 2004 22
MSEC Architecture August, 2003
Thomas Hardjono Thomas Hardjono
VeriSign VeriSign
401 Edgewater Place, Suite 280 487 E. Middlefield Rd.
Wakefield, MA 01880 Mountain view, CA 94043
(781) 245-6996
thardjono@verisign.com Phone:(650) 426-3204
EMail: thardjono@verisign.com
Brian Weis Brian Weis
Cisco Systems Cisco Systems
170 W. Tasman Drive, 170 W. Tasman Drive,
San Jose, CA 95134-1706, USA San Jose, CA 95134-1706, USA
(408) 526-4796
bew@cisco.com
Hardjono, Weis Expires January, 2004 22 Phone: (408) 526-4796
EMail: bew@cisco.com
Hardjono, Weis Expires February, 2004 23
 End of changes. 

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