Request for Comments: 4046 Cisco
Category: Informational R. Canetti
IBM
L. Dondeti
Qualcomm
F. Lindholm
Ericsson
April 2005
Multicast Security (MSEC) Group Key Management Architecture
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines the common architecture for Multicast Security
(MSEC) key management protocols to support a variety of application,
transport, and network layer security protocols. It also defines the
group security association (GSA), and describes the key management
protocols that help establish a GSA. The framework and guidelines
described in this document permit a modular and flexible design of
group key management protocols for a variety of different settings
that are specialized to applications needs. MSEC key management
protocols may be used to facilitate secure one-to-many, many-to-many,
or one-to-one communication.
Table of Contents
1. Introduction: Purpose of this Document ..........................2
2. Requirements of a Group Key Management Protocol .................4
3. Overall Design of Group Key Management Architecture .............6
3.1. Overview ...................................................6
3.2. Detailed Description of the GKM Architecture ...............8
3.3. Properties of the Design ..................................11
3.4. Group Key Management Block Diagram ........................11
4. Registration Protocol ..........................................13
4.1. Registration Protocol via Piggybacking or Protocol Reuse ..13
4.2. Properties of Alternative Registration Exchange Types .....14
4.3. Infrastructure for Alternative Registration
Exchange Types ............................................15
4.4. De-registration Exchange ..................................16
5. Rekey Protocol .................................................16
5.1. Goals of the Rekey Protocol ...............................17
5.2. Rekey Message Transport and Protection ....................17
5.3. Reliable Transport of Rekey Messages ......................18
5.4. State-of-the-art on Reliable Multicast Infrastructure .....20
5.5. Implosion .................................................21
5.6. Incorporating Group Key Management Algorithms .............22
5.7. Stateless, Stateful, and Self-healing Rekeying
Algorithms ................................................22
5.8. Interoperability of a GKMA ................................23
6. Group Security Association .....................................24
6.1. Group Policy ..............................................24
6.2. Contents of the Rekey SA ..................................25
6.2.1. Rekey SA Policy ....................................26
6.2.2. Group Identity .....................................27
6.2.3. KEKs ...............................................27
6.2.4. Authentication Key .................................27
6.2.5. Replay Protection ..................................27
6.2.6. Security Parameter Index (SPI) .....................27
6.3. Contents of the Data SA ...................................27
6.3.1. Group Identity .....................................28
6.3.2. Source Identity ....................................28
6.3.3. Traffic Protection Keys ............................28
6.3.4. Data Authentication Keys ...........................28
6.3.5. Sequence Numbers ...................................28
6.3.6. Security Parameter Index (SPI) .....................28
6.3.7. Data SA Policy .....................................28
7. Scalability Considerations .....................................29
8. Security Considerations ........................................31
9. Acknowledgments ................................................32
10. Informative References ........................................33
1. Introduction: Purpose of this Document
This document defines a common architecture for Multicast Security
(MSEC) key management protocols to support a variety of application-,
transport-, and network-layer security protocols. It also defines
the group security association (GSA) and describes the key management
protocols that help establish a GSA. The framework and guidelines
described in this document permit a modular and flexible design of
group key management protocols for a variety of different settings
that are specialized to applications needs. MSEC key management
protocols may be used to facilitate secure one-to-many, many-to-many,
or one-to-one communication.
Group and multicast applications in IP networks have diverse security
requirements [TAXONOMY]. Their key management requirements, briefly
reviewed in Section 2.0, include support for internetwork-,
transport- and application-layer security protocols. Some
applications achieve simpler operation by running key management
messaging over a pre-established secure channel (e.g., TLS or IPsec).
Other security protocols benefit from a key management protocol that
can run over an already-deployed session initiation or management
protocol (e.g., SIP or RTSP). Finally, some benefit from a
lightweight key management protocol that requires few round trips.
For all these reasons, application-, transport-, and IP-layer data
security protocols (e.g., SRTP [RFC3711] and IPsec [RFC2401]) benefit
from different group key management systems. This document defines a
common architecture and design for all group key management (GKM)
protocols.
This common architecture for group key management is called the MSEC
group key management architecture. It is based on the group control
or key server model developed in GKMP [RFC2094] and assumed by group
key management algorithms such as LKH [RFC2627], OFT [OFT], and MARKS
[MARKS]. There are other approaches that are not considered in this
architecture, such as the highly distributed Cliques group key
management protocol [CLIQUES] or broadcast key management schemes
[FN93,Wool]. MSEC key management may in fact be complementary to
other group key management designs, but the integration of MSEC group
key management with Cliques, broadcast key management, or other group
key systems is not considered in this document.
Key management protocols are difficult to design and validate. The
common architecture described in this document eases this burden by
defining common abstractions and an overall design that can be
specialized for different uses.
This document builds on and extends the Group Key Management Building
Block document of the IRTF SMuG research group [GKMBB] and is part of
the MSEC document roadmap. The MSEC architecture [MSEC-Arch] defines
a complete multicast or group security architecture, of which key
management is a component.
The rest of this document is organized as follows. Section 2
discusses the security, performance and architectural requirements
for a group key management protocol. Section 3 presents the overall
architectural design principles. Section 4 describes the
registration protocol in detail, and Section 5 does the same for
rekey protocol. Section 6 considers the interface to the Group
Security Association (GSA). Section 7 reviews the scalability issues
for group key management protocols and Section 8 discusses security
considerations.
2. Requirements of a Group Key Management Protocol
A group key management (GKM) protocol supports protected
communication between members of a secure group. A secure group is a
collection of principals, called members, who may be senders,
receivers, or both receivers and senders to other members of the
group. Group membership may vary over time. A group key management
protocol helps to ensure that only members of a secure group can gain
access to group data (by gaining access to group keys) and can
authenticate group data. The goal of a group key management protocol
is to provide legitimate group members with the up-to-date
cryptographic state they need for secrecy and authentication.
Multicast applications, such as video broadcast and multicast file
transfer, typically have the following key management requirements
(see also [TAXONOMY]). Note that the list is neither applicable to
all applications nor exhaustive.
1. Group members receive security associations that include
encryption keys, authentication/integrity keys, cryptographic
policy that describes the keys, and attributes such as an index
for referencing the security association (SA) or particular
objects contained in the SA.
2. In addition to the policy associated with group keys, the group
owner or the Group Controller and Key Server (GCKS) may define and
enforce group membership, key management, data security, and other
policies that may or may not be communicated to the entire
membership.
3. Keys will have a pre-determined lifetime and may be periodically
refreshed.
4. Key material should be delivered securely to members of the group
so that they are secret, integrity-protected and verifiably
obtained from an authorized source.
5. The key management protocol should be secure against replay
attacks and Denial of Service(DoS) attacks (see the Security
Considerations section of this memo).
6. The protocol should facilitate addition and removal of group
members. Members who are added may optionally be denied access to
the key material used before they joined the group, and removed
members should lose access to the key material following their
departure.
7. The protocol should support a scalable group rekey operation
without unicast exchanges between members and a Group Controller
and Key Server (GCKS), to avoid overwhelming a GCKS managing a
large group.
8. The protocol should be compatible with the infrastructure and
performance needs of the data security application, such as the
IPsec security protocols AH and ESP, and/or application layer
security protocols such as SRTP [RFC3711].
9. The key management protocol should offer a framework for replacing
or renewing transforms, authorization infrastructure, and
authentication systems.
10. The key management protocol should be secure against collusion
among excluded members and non-members. Specifically, collusion
must not result in attackers gaining any additional group secrets
than each of them individually are privy to. In other words,
combining the knowledge of the colluding entities must not result
in revealing additional group secrets.
11. The key management protocol should provide a mechanism to
securely recover from a compromise of some or all of the key
material.
12. The key management protocol may need to address real-world
deployment issues such as NAT-traversal and interfacing with
legacy authentication mechanisms.
In contrast to typical unicast key and SA negotiation protocols such
as TLS and IKE, multicast group key management protocols provide SA
and key download capability. This feature may be useful for point-
to-point as well as multicast communication, so that a group key
management protocol may be useful for unicast applications. Group
key management protocols may be used for protecting multicast or
unicast communications between members of a secure group. Secure
sub-group communication is also plausible using the group SA.
There are other requirements for small group operation with many all
members as potential senders. In this case, the group setup time may
need to be optimized to support a small, highly interactive group
environment [RFC2627].
The current key management architecture covers secure communication
in large single-sender groups, such as source-specific multicast
groups. Scalable operation to a range of group sizes is also a
desirable feature, and a better group key management protocol will
support large, single-sender groups as well as groups that have many
senders. It may be that no single key management protocol can
satisfy the scalability requirements of all group-security
applications.
It is useful to emphasize two non-requirements: technical protection
measures (TPM) [TPM] and broadcast key management. TPM are used for
such things as copy protection by preventing the device user from
getting easy access to the group keys. There is no reason why a
group key management protocol cannot be used in an environment where
the keys are kept in a tamper-resistant store, using various types of
hardware or software to implement TPM. For simplicity, however, the
MSEC key management architecture described in this document does not
consider design for technical protection.
The second non-requirement is broadcast key management when there is
no back channel [FN93,JKKV94] or for a non-networked device such as a
digital videodisc player. We assume IP network operation with two-
way communication, however asymmetric, and authenticated key-exchange
procedures that can be used for member registration. Broadcast
applications may use a one-way Internet group key management protocol
message and a one-way rekey message, as described below.
3. Overall Design of Group Key Management Architecture
The overall group key management architecture is based upon a group
controller model [RFC2093,RFC2094,RFC2627,OFT,GSAKMP,RFC3547] with a
single group owner as the root-of-trust. The group owner designates
a group controller for member registration and GSA rekeying.
3.1. Overview
The main goal of a group key management protocol is to securely
provide group members with an up-to-date security association (SA),
which contains the needed information for securing group
communication (i.e., the group data). We call this SA the Data SA.
In order to obtain this goal, the group key management architecture
defines the following protocols.
(1) Registration Protocol
This is a unicast protocol between the Group Controller and Key
Server (GCKS) and a joining group member. In this protocol, the
GCKS and joining member mutually authenticate each other. If the
authentication succeeds and the GCKS finds that the joining member
is authorized, then the GCKS supplies the joining member with the
following information:
(a) Sufficient information to initialize the Data SA within the
joining member. This information is given only if the group
security policy calls for initializing the Data SA at
registration, instead of, or in addition to, as part of the
rekey protocol.
(b) Sufficient information to initialize a Rekey SA within the
joining member (see more details about this SA below). This
information is given if the group security policy calls for a
rekey protocol.
The registration protocol must ensure that the transfer of
information from GCKS to member is done in an authenticated and
confidential manner over a security association. We call this SA
the Registration SA. A complementary de-registration protocol
serves to explicitly remove Registration SA state. Members may
choose to delete Registration SA state.
(2) Rekey Protocol
A GCKS may periodically update or change the Data SA, by sending
rekey information to the group members. Rekey messages may result
from group membership changes, from changes in group security
policy, from the creation of new traffic-protection keys (TPKs,
see next section) for the particular group, or from key
expiration. Rekey messages are protected by the Rekey SA, which
is initialized in the registration protocol. They contain
information for updating the Rekey SA and/or the Data SA and can
be sent via multicast to group members or via unicast from the
GCKS to a particular group member.
Note that there are other means for managing (e.g., expiring or
refreshing) the Data SA without interaction between the GCKS and
the members. For example in MARKS [MARKS], the GCKS pre-
determines TPKs for different periods in the lifetime of the
secure group and distributes keys to members based on their
membership periods. Alternative schemes such as the GCKS
disbanding the secure group and starting a new group with a new
Data SA are also possible, although this is typically limited to
small groups.
Rekey messages are authenticated using one of the two following
options:
(1) Using source authentication [TAXONOMY], that is, enabling each
group member to verify that a rekey message originates with
the GCKS and none other.
(2) Using only group-based authentication with a symmetric key.
Members can only be assured that the rekey messages originated
within the group. Therefore, this is applicable only when all
members of the group are trusted not to impersonate the GCKS.
Group authentication for rekey messages is typically used when
public-key cryptography is not suitable for the particular
group.
The rekey protocol ensures that all members receive the rekey
information in a timely manner. In addition, the rekey protocol
specifies mechanisms for the parties to contact the GCKS and re-
synch if their keys expired and an updated key has not been
received. The rekey protocol for large-scale groups offers
mechanisms to avoid implosion problems and to ensure reliability
in its delivery of keying material.
Although the Rekey SA is established by the registration protocol,
it is updated using a rekey protocol. When a member leaves the
group, it destroys its local copy of the GSA. Using a de-
registration message may be an efficient way for a member to
inform the GCKS that it has destroyed, or is about to destroy, the
SAs. Such a message may prompt the GCKS to cryptographically
remove the member from the group (i.e., to prevent the member from
having access to future group communication). In large-scale
multicast applications, however, de-registration can potentially
cause implosion at the GCKS.
3.2. Detailed Description of the GKM Architecture
Figure 1 depicts the overall design of a GKM protocol. Each group
member, sender or receiver, uses the registration protocol to get
authorized and authenticated access to a particular Group, its
policies, and its keys. The two types of group keys are the key
encryption keys (KEKs) and the traffic encryption keys (TEKs). For
group authentication of rekey messages or data, key integrity or
traffic integrity keys may be used, as well. We use the term
protection keys to refer to both integrity and encryption keys. For
example, the term traffic protection key (TPK) is used to denote the
combination of a TEK and a traffic integrity key, or the key material
used to generate them.
The KEK may be a single key that protects the rekey message,
typically containing a new Rekey SA (containing a KEK) and/or Data SA
(containing a TPK/TEK). A Rekey SA may also contain a vector of keys
that are part of a group key membership algorithm
[RFC2627,OFT,TAXONOMY,SD1,SD2]. The data security protocol uses TPKs
to protect streams, files, or other data sent and received by
the data security protocol. Thus the registration protocol and/or
the rekey protocol establish the KEK(s) and/or the TPKs.
+------------------------------------------------------------------+
| +-----------------+ +-----------------+ |
| | POLICY | | AUTHORIZATION | |
| | INFRASTRUCTURE | | INFRASTRUCTURE | |
| +-----------------+ +-----------------+ |
| ^ ^ |
| | | |
| v v |
| +--------------------------------------------------------------+ |
| | | |
| | +--------------------+ | |
| | +------>| GCKS |<------+ | |
| | | +--------------------+ | | |
| | REGISTRATION or | REGISTRATION or | |
| | DE-REGISTRATION | DE-REGISTRATION | |
| | PROTOCOL | PROTOCOL | |
| | | | | | |
| | v REKEY v | |
| | +-----------------+ PROTOCOL +-----------------+ | |
| | | | (OPTIONAL) | | | |
| | | SENDER(S) |<-------+-------->| RECEIVER(S) | | |