view Side-By-Side changes
Internet Draft Mark
Network Working Group M. Baugher (Cisco)
IETF MSEC WG Ran Canetti (IBM)
Expires: December 08, 2004 Lakshminath Dondeti (Nortel)
Request for Comments: 4046 Cisco
Category: Informational Fredrik R. Canetti
IBM
L. Dondeti
Qualcomm
F. Lindholm (Ericsson)
June 09, 2004
MSEC
Ericsson
April 2005
Multicast Security (MSEC) Group Key Management Architecture
<draft-ietf-msec-gkmarch-08.txt>
Status of this This Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of memo provides information for the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum community. It does
not specify an Internet standard of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as work in progress.
The list kind. Distribution of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt this
memo is unlimited.
Copyright Notice
Copyright (C) The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html Internet Society (2005).
Abstract
This document defines the common architecture for Multicast Security
(MSEC) key management protocols that 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 allow for 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, one-to-many, many-to-many,
or one-to-one communication.
Comments on this document should be sent to msec@securemulticast.org.
Baugher, Canetti, Dondeti, Lindholm June 2004
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1.0
1. Introduction: Purpose of this Document.........................3
2.0 Document ..........................2
2. Requirements of a Group Key Management Protocol................4
3.0 Protocol .................4
3. Overall Design of the Group Key Management Architecture........6
3.1 Overview.......................................................6
3.2 Architecture .............6
3.1. Overview ...................................................6
3.2. Detailed Description of the GKM Architecture...................8
3.3 Architecture ...............8
3.3. Properties of the Design .....................................11
3.4 ..................................11
3.4. Group Key Management Block Diagram............................11
4.0 Diagram ........................11
4. Registration protocol.........................................13
4.1 Protocol ..........................................13
4.1. Registration protocol Protocol via Piggybacking or Protocol Reuse......13
4.2 Reuse ..13
4.2. Properties of Alternative registration Registration Exchange Types.........14
4.3 Types .....14
Baugher, et al. Informational [Page 1]
RFC 4046 MSEC Group Key Management Architecture April 2005
4.3. Infrastructure for Alternative registration Registration
Exchange Types....15
4.4 Types ............................................15
4.4. De-registration Exchange......................................15
5.0 Exchange ..................................16
5. Rekey protocol................................................16
5.1 Protocol .................................................16
5.1. Goals of the rekey protocol...................................16
5.2 Rekey message Protocol ...............................17
5.2. Rekey Message Transport and Protection........................17
5.3 Protection ....................17
5.3. Reliable Transport of rekey messages..........................18
5.4 Rekey Messages ......................18
5.4. State-of-the-art on Reliable Multicast Infrastructure.........20
5.5 Implosion.....................................................20
5.6 Issues in Infrastructure .....20
5.5. Implosion .................................................21
5.6. Incorporating Group Key Management Algorithms.......22
5.7 Algorithms .............22
5.7. Stateless, Stateful, and Self-healing Rekeying Algorithms.....22
5.8
Algorithms ................................................22
5.8. Interoperability of a GKMA....................................23
6.0 GKMA ................................23
6. Group Security Association....................................23
6.1 Association .....................................24
6.1. Group policy..................................................24
6.2 Policy ..............................................24
6.2. Contents of the Rekey SA......................................25
6.2.1 SA ..................................25
6.2.1. Rekey SA Policy.............................................25
6.2.2 Policy ....................................26
6.2.2. Group Identity..............................................26
6.2.3 KEKs........................................................26
6.2.4 Identity .....................................27
6.2.3. KEKs ...............................................27
6.2.4. Authentication Key..........................................26
6.2.5 Key .................................27
6.2.5. Replay Protection...........................................26
6.2.6 Protection ..................................27
6.2.6. Security Parameter Index (SPI)..............................26
6.3 (SPI) .....................27
6.3. Contents of the Data SA.......................................27
6.3.1 SA ...................................27
6.3.1. Group Identity..............................................27
6.3.2 Identity .....................................28
6.3.2. Source Identity.............................................27
6.3.3 Identity ....................................28
6.3.3. Traffic Protection Keys.....................................27
6.3.4 Keys ............................28
6.3.4. Data Authentication Keys....................................27
6.3.5 Keys ...........................28
6.3.5. Sequence Numbers............................................27
6.3.6 Numbers ...................................28
6.3.6. Security Parameter Index (SPI)..............................27
6.3.7 (SPI) .....................28
6.3.7. Data SA policy..............................................28
7.0 Policy .....................................28
7. Scalability Considerations....................................28
8.0 Considerations .....................................29
8. Security Considerations.......................................30
9.0 Acknowledgments...............................................31
10.0 Considerations ........................................31
9. Acknowledgments ................................................32
10. Informative References and Bibliography..................................32
11.0 Authors' Addresses...........................................36
Internet Draft Group Key Management Architecture [PAGE 2]
Baugher, Canetti, Dondeti, Lindholm June 2004
1.0 ........................................33
1. Introduction: Purpose of this Document
Group and multicast applications have diverse requirements in IP
networks [TAXONOMY]. Their
This document defines a common architecture for Multicast Security
(MSEC) key management requirements - briefly
reviewed in Section 2.0 - include protocols to support for internetwork,
transport, 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.
Baugher, et al. Informational [Page 2]
RFC 4046 MSEC Group Key Management Architecture April 2005
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 may achieve simpler operation by running key-management key management
messaging over a pre-established secure channel (e.g., TLS, TLS or IPsec).
Other security protocols may benefit from a key management protocol that
can run over already deployed an already-deployed session initiation or management
protocol (e.g., SIP or RTSP). Finally, some may benefit from a light-weight
lightweight key management protocol that finishes in fewest requires few round trips.
For all these reasons, different application, transport, application-, transport-, and internetwork-
layer IP-layer data
security protocols (e.g., SRTP [RFC3711] and IPsec [RFC2401]) may benefit
from using different group key management systems. The purpose of this This document is to define defines a
common architecture and design for all group key-management protocols for
internet, transport, and application services.
The key management (GKM)
protocols.
This common architecture for group key management is called the MSEC
group key management architecture and 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
architecture, such as the highly distributed Cliques group key
management protocol [CLIQUES] and or broadcast key management schemes
[FN93, Wool].
[FN93,Wool]. MSEC (Multicast Security) key management may in fact be complementary to
other group key management designs, but these
are not considered in this document. The the integration of MSEC group
key management with Cliques, broadcast key management and management, or other group
key systems is not considered in this document.
Indeed, key-management
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] is a
reference for 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 detail, and Section 5 does the same for
rekey protocol. Section 6 considers the interface to the Group
Security Association
Internet Draft Group Key Management Architecture [PAGE 3]
Baugher, Canetti, Dondeti, Lindholm June 2004 (GSA). Section 7 reviews the scalability issues
for group key management protocols and Section 8 discusses security
considerations.
2.0
Baugher, et al. Informational [Page 3]
RFC 4046 MSEC Group Key Management Architecture April 2005
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
receivers, or both receivers and senders to other members of the
group. (Note that group Group membership may vary over time.) 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 their secrecy and authenticity requirements. authentication.
Multicast applications, such as video broadcast and multicast file
transfer, typically have the following key-management key management requirements
(see also [TAXONOMY]). Note that the list is neither applicable to
all applications, applications nor exhaustive.
1. The group Group members receive security associations including 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 security, and other
policies that may or may not be communicated to the
membership-at-large. entire
membership.
3. Keys will have a predetermined 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 can be
verified as coming verifiably
obtained from an authorized source.
5. The key-management 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 so that members
members. Members who are added may optionally be denied access to
the key material used before they joined the group, and that removed
members should lose access to the key material following their
departure.
Internet Draft
Baugher, et al. Informational [Page 4]
RFC 4046 MSEC Group Key Management Architecture [PAGE 4]
Baugher, Canetti, Dondeti, Lindholm June 2004 April 2005
7. The protocol should support a scalable group rekey operation
without unicast exchanges between members and a group
controller/key server, to avoid overwhelming 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 data security application, such as the
IPsec security protocols, protocols AH and ESP, and/or application-layer application layer
security protocols, protocols such as SRTP. SRTP [RFC3711].
9. The key management protocol should offer a framework for replacing
or renewing transforms, authorization infrastructure 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.
12.
11. The key management protocol should provide a mechanism to
securely recover from a compromise of some or all of the key
material.
13. Key
12. The key management protocols protocol may need to address real-world
deployment issues such as NAT-traversal and may need to
interface interfacing with
legacy authentication mechanisms already
deployed. 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
communication point-
to-point as well. Thus, well as multicast communication, so that a group key
management protocol may
also be useful to for unicast applications. In other words, group Group
key management protocols may be used for protecting multicast
communications, 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 where there
will be with many senders or in which all
members may potentially be 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
Internet Draft Group Key Management Architecture [PAGE 5]
Baugher, Canetti, Dondeti, Lindholm June 2004
support large, single-sender groups as well as groups that have many
Baugher, et al. Informational [Page 5]
RFC 4046 MSEC Group Key Management Architecture April 2005
senders. It may be that no single key management protocol can
satisfy the scalability requirements of all group-security
applications.
In addition to these requirements, it
It is useful to emphasize two non-
requirements, namely, non-requirements: technical protection
measures (TPM) [TPM] and broadcast key management. TPM are used for
such things as copy protection by preventing the user of a device to get 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 store, using various types of
hardware or software to implement TPM. However, for For simplicity, however, the
MSEC key management architecture described in this document considers does not
consider design for technical protection measures out of scope. protection.
The second non-requirement is broadcast key management where when there is
no back channel [FN93, JKKV94] [FN93,JKKV94] or where the device is not on for a
network, non-networked device such as a
digital videodisk videodisc player. We assume IP network operation where there is two-way with two-
way communication, however asymmetric, and that authenticated key-exchange
procedures that can be used for member registration. It is possible that broadcast Broadcast
applications can make may use of a one-way Internet group key management protocol message,
message and a one-way rekey message message, as described below.
3.0
3. Overall Design of the Group Key Management Architecture
This section describes the
The overall structure of a group key management protocol. The design architecture is based upon a group
controller model [RFC2093, RFC2094, RFC2627, OFT, GSAKMP, and RFC3547] [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
3.1. Overview
The main goal of a group key management protocol is to securely
provide the 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 group key management architecture
defines the following protocols.
(1) Registration protocol.
===================== Protocol
This is a unicast protocol between the group controller/key server 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:
Internet Draft
Baugher, et al. Informational [Page 6]
RFC 4046 MSEC Group Key Management Architecture [PAGE 6]
Baugher, Canetti, Dondeti, Lindholm June 2004 April 2005
(a) Sufficient information to initialize the Data SA within the
joining member. This information is given only in the case that if the group
security policy calls for initializing the Data SA at
registration, instead of of, or in addition to 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 only in case that if the group security policy calls for using 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 on their own volition. state.
(2) Rekey protocol.
============== 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, change 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. Rekey messages 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. (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 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 type of operation is typically limited to
small groups.
Rekey messages are authenticated using one of the two following
options:
o The first option is to use
(1) Using source authentication [TAXONOMY], that
is to enable is, enabling each
group member to verify that a rekey message originates with
the GCKS and none other.
o The second option is to use only group-based authentication
using a symmetric key. Members can
Baugher, et al. Informational [Page 7]
RFC 4046 MSEC Group Key Management Architecture April 2005
(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
Internet Draft Group Key Management Architecture [PAGE 7]
Baugher, Canetti, Dondeti, Lindholm June 2004 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
in case that re-
synch if their keys expired and an updated key has not yet been
received. The rekey protocol for large-scale groups offers
mechanisms to avoid implosion problems and to ensure the needed reliability
in its delivery of keying material.
Although the Rekey messages are protected by a Rekey SA, which SA is established by the registration protocol, and
it is updated using a rekey protocol. When a member leaves the
group, it destroys its local copy of the GSA. Use
of Using a de-registration de-
registration message may be an efficient mechanisms way for a member to
inform the GCKS that it has destroyed the SAs, destroyed, or is about to destroy them. 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 has the
potential to can potentially
cause implosion at the GCKS.
3.2
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,
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 keys or
traffic integrity keys may be used used, as well. We use the term
protection keys to refer to both integrity keys and the 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 TEK). 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].
[RFC2627,OFT,TAXONOMY,SD1,SD2]. The TPKs are used by the data security protocol uses TPKs
to protect streams, files, or other data sent and received by
Baugher, et al. Informational [Page 8]
RFC 4046 MSEC Group Key Management Architecture April 2005
the data security protocol. Thus the registration protocol and/or
the rekey protocol establish the KEK(s) and/or the TPKs.
Internet Draft Group Key Management Architecture [PAGE 8]
Baugher, Canetti, Dondeti, Lindholm June 2004
+------------------------------------------------------------------+
| +-----------------+ +-----------------+ |
| | 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) | | |
| | | | | | | |
| | +-----------------+ +-----------------+ | |
| | | ^ | |
| | v | | |
| | +-------DATA SECURITY PROTOCOL-------+ | |
| | | |
| +--------------------------------------------------------------+ |
| |
+------------------------------------------------------------------+
FIGURE
Figure 1: Group Security Association Model
There are a few, few distinct outcomes to a successful registration
Protocol exchange.
o If the GCKS uses rekey messages, then the admitted member
receives the Rekey SA. The Rekey SA contains the groups group's rekey
policy (note that not all of the policy need to be revealed to
members), and at least a group KEK. In addition, the GCKS may send
sends a group key integrity key, and
if the group uses key for integrity protection of
rekey messages. If a group key management algorithm, a set
of KEKs (or key material algorithm is used to derive
for efficient rekeying, the KEKs) according
to GCKS also sends one or more KEKs as
specified by the particular key distribution policy of the group key
management algorithm.
Baugher, et al. Informational [Page 9]
RFC 4046 MSEC Group Key Management Architecture April 2005
o If rekey messages are not used for the Group, then the admitted
member will receive receives TPKs (as part of the Data Security SAs) that
are passed to the members member's Data Security Protocol (as IKE does
for IPsec).
Internet Draft Group Key Management Architecture [PAGE 9]
Baugher, Canetti, Dondeti, Lindholm June 2004
o The GCKS may pass one or more TPKs to the member even if rekey
messages are used, for efficiency reasons and according to
group policy.
The GCKS creates the KEK and TPKs and downloads them to each member - member,
as the KEK and TPKs are common to the entire group. The GCKS is a
separate,
separate logical entity that performs member authentication and
authorization according to the group policy that is set by the group
owner. The GCKS may present a credential to the group member that is signed by the group owner so
to the group member, so that member can check the GCKSs GCKS's
authorization. The GCKS, which may be co-located with a member or be
a separate physical entity,
physically separate, runs the rekey protocol to push rekey messages
containing refreshed KEKs, new TPKs, and/or refreshed TPKs to
members. Note that some group key management algorithms refresh any
of the KEKs (potentially), whereas others only refresh the group KEK.
Alternatively, the sender may forward rekey messages on behalf of the
GCKS when it uses a credential mechanism that supports delegation.
Thus, it is possible for the sender (or sender, or other members) members, to source
keying material - TPKs (TPKs encrypted in the Group KEK - KEK) as it sources
multicast or unicast data. As mentioned above, the rekey message can
be sent using unicast or multicast delivery. Upon receipt of a TPK
(as part of a Data SA) from via a rekey message or a registration protocol
exchange, the members member's group key management functional block will
provide the new or updated security association (SA) to the data
security protocol to protect protocol. This protects the data sent from sender to
receiver.
The Data SA protects the data sent on the arc labeled DATA SECURITY
PROTOCOL shown in Figure 1. A second SA, the Rekey SA, is optionally
established by the key-management key management protocol for rekey messages as
shown in Figure 1 by the arc labeled REKEY PROTOCOL. The rekey
message is optional because all keys, KEKs and TPKs, can be delivered
by the registration protocol exchanges shown in Figure 1, and those
keys may not need to be updated. The registration protocol is
protected by a third, unicast, SA between the GCKS and each member;
this member.
This is called the Registration SA. There may be no need for the
Registration SA to remain in place after the completion of the
registration protocol exchanges. The de-registration protocol may be
used when explicit teardown of the SA is desirable (such as when a
phone call or conference terminates). The three SAs compose the GSA.
Only one SA is
The only optional and that SA is the Rekey SA.
Figure 1 shows two blocks that are external to
Baugher, et al. Informational [Page 10]
RFC 4046 MSEC Group Key Management Architecture April 2005
Figure 1 shows two blocks that are external to the group key
management protocol: The policy and authorization infrastructures
are discussed in Section 6.1. The Multicast Security Architecture
document further clarifies the SAs and their use as part of the
complete architecture of a multicast security solution [MSEC-Arch].
Internet Draft Group Key Management Architecture [PAGE 10]
Baugher, Canetti, Dondeti, Lindholm June 2004
3.3
3.3. Properties of the Design
The design of Section 3.2 achieves scalable operation by (1) allowing
the de-coupling of authenticated key exchange in a registration
protocol from a rekey protocol, (2) allowing the rekey protocol to
use unicast push or multicast distribution of group and data keys as
an option, (3) allowing all keys to be obtained by the unicast
registration protocol, and (4) delegating the functionality of the
GCKS among multiple entities, i.e., to permit distributed operation
of the GCKS.
High-capacity operation is obtained by (1) amortizing
computationally-expensive asymmetric cryptography over multiple data
keys used by data security protocols, (2) supporting multicast
distribution of symmetric group and data keys, and (3) supporting key
revocation algorithms such as LKH [RFC2627, OFT, SDR] [RFC2627,OFT,SD1,SD2] that allow
members to be added or removed at logarithmic rather than linear
space/time complexity. The registration protocol may use asymmetric
cryptography to authenticate joining members and optionally establish
the group KEK. Asymmetric cryptography such as Diffie-Hellman key
agreement and/or digital signatures are amortized over the life of
the group KEK: KEK. A Data SA can be established without the use of
asymmetric cryptography - cryptography; the TPKs are simply encrypted in the
symmetric KEK and sent unicast or multicast in the rekey protocol.
The design of the registration and rekey protocols is flexible. The
registration protocol establishes either a Rekey SA or one or more Data SAs
or both types of SAs. At least one of the SAs is present (otherwise,
there is no purpose to the Registration SA). The Rekey SA may update
the Rekey SA, or establish or update one or more Data SAs.
Individual protocols or configurations may take advantage of use this flexibility for to
obtain efficient operation.
3.4
3.4. Group Key Management Block Diagram
In the block diagram of Figure 2, group key management protocols run
between a GCKS and member principal to establish a Group Security
Association (GSA). The GSA consists of a Data SA, an optional Rekey
SA, and a Registration SA. The GCKS may use a delegated principal,
such as the sender, which has a delegation credential signed by the
GCKS. The Member of Figure 2 may be a sender or receiver of
multicast or unicast data. There are two functional blocks in Figure
Baugher, et al. Informational [Page 11]
RFC 4046 MSEC Group Key Management Architecture April 2005
2 labeled GKM, and there are two arcs between them depicting the
group key-management registration (reg) and rekey (rek) protocols.
The message exchanges are in the GSA establishment protocols, which
are the registration protocol and the rekey protocol described above.
Figure 2 shows that a complete group-key management functional
specification includes much more than the message exchange. Some of
these functional blocks and the arcs between them are peculiar to an
Internet Draft Group Key Management Architecture [PAGE 11]
Baugher, Canetti, Dondeti, Lindholm June 2004
operating system (OS) or vendor product, such as vendor
specifications for products that support updates to the IPsec
Security Association Database (SAD) and Security Policy Database
(SPD) [RFC2367]. Various vendors also define the functions and
interface of credential stores, CRED in Figure 2.
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| | CONTROL | | CONTROL | |
| +------^------+ +------|-----+ +--------+ |
| | | +-----| CRED | |
| | | | +--------+ |
| +----v----+ +----v--v-+ +--------+ |
| | <-----Reg-----> |<->| SAD | |
| | GKM -----Rek-----> GKM | +--------+ |
| | | | | +--------+ |
| | ------+ | |<->| SPD | |
| +---------+ | +-^-------+ +--------+ |
| +--------+ | | | | |
| | CRED |----->+ | | +-------------------+ |
| +--------+ | | +--------------------+ | |
| +--------+ | +-V-------+ +--------+ | | |
| | SAD <----->+ | |<->| SAD <-+ | |
| +--------+ | |SECURITY | +--------+ | |
| +--------+ | |PROTOCOL | +--------+ | |
| | SPD <----->+ | |<->| SPD <----+ |
| +--------+ +---------+ +--------+ |
| |
| (A) GCKS (B) MEMBER |
+----------------------------------------------------------+
Figure 2: Group key management block diagram for Key Management Block in a host computer Host
The CONTROL function directs the GCKS to establish a group, admit a
member, or remove a member, or it directs a member to join or leave a
group. CONTROL includes authorization, which authorization that is subject to group
policy [GSPT], [GSPT] but how this is done its implementation is specific to the GCKS
implementation. GCKS. For large-scale
large scale multicast sessions, CONTROL could perform session
Baugher, et al. Informational [Page 12]
RFC 4046 MSEC Group Key Management Architecture April 2005
announcement functions to inform a potential group member that it may
join a group or receive group data (e.g. (e.g., a stream of file transfer
protected by a data security protocol). Announcements notify group
members to establish multicast SAs in advance of secure multicast
data transmission. Session Description Protocol (SDP) is one form
that the announcements might take [RFC2327]. The announcement
function may be implemented in a
session-directory session directory tool, an
electronic program guide (EPG), or by other means. The Data Security
or the announcement function directs group key management using an application-programming
application programming interface (API), which is peculiar to the
host OS in its specifics. A generic
Internet Draft Group Key Management Architecture [PAGE 12]
Baugher, Canetti, Dondeti, Lindholm June 2004 API for group key management is
for further study, but this function is necessary to allow Group
(KEK) and Data (TPKs) key establishment to be done in a way that is scalable to the
particular application. A GCKS application program will use the API
to initiate the procedures to establish for establishing SAs on behalf of a
Security Protocol in which members join secure groups and receive
keys for streams, files files, or other data.
The goal of the exchanges is to establish a GSA through updates to
the SAD of a key-management key management implementation and particular Security
Protocol. The data security protocol Data Security Protocol ("SECURITY PROTOCOL") of Figure
2 may span internetwork and application layers or operate at the
internetwork layer, such as AH and ESP.
4.0
4. Registration protocol Protocol
The design of the registration protocol is flexible, flexible and can support
different application scenarios. The chosen registration protocol
solution reflects the specific requirements of specific scenarios.
In principle, it is possible to base a registration protocol on any
secure-channel protocol, such as IPsec and TLS, which is the case in
tunneled GSAKMP [tGSAKMP]. GDOI [RFC3547] reuses IKE Phase 1 as the
secure channel to download Rekey and/or Data SAs. Other protocols,
such as MIKEY and GSAKMP, use authenticated Diffie-Hellman exchanges
similar to IKE Phase 1, but they are specifically tailored for key
download to achieve efficient operation. We discuss the design of a
registration protocol in detail in the rest of this section.
4.1
4.1. Registration protocol Protocol via Piggybacking or Protocol Reuse
Some registration protocols need to tunnel through a data-signaling
protocol to take advantage of already existing security
functionality, and/or to optimize the total session setup time. For
example, a telephone call has strict bounds for delay in setup time.
It is not feasible to run security exchanges in parallel with call
setup
setup, since the latter often resolves the address: address. Call setup must
complete before the caller knows the address of the callee. callee's address. In this case,
it may be advantageous to tunnel the key exchange procedures inside
Baugher, et al. Informational [Page 13]
RFC 4046 MSEC Group Key Management Architecture April 2005
call establishment [H.235, MIKEY] [H.235,MIKEY], so that both can complete (or fail,
see below) at the same time.
The registration protocol has different requirements depending on the
particular integration/tunneling approach. These requirements are
not necessarily security requirements, but will have an impact on the
chosen security solution. For example, the security association will
certainly fail if the call setup fails in the case of IP telephony.
Internet Draft Group Key Management Architecture [PAGE 13]
Baugher, Canetti, Dondeti, Lindholm June 2004
Conversely, the registration protocol imposes requirements on the
protocol that tunnels it. In the case of IP telephony, the call
setup usually will fail when the security association is not
successfully established. In the case of video-on-demand, protocols
such as RTSP that convey key management data will fail when a needed
security association cannot be established.
Both GDOI and MIKEY use this approach, but in different ways. MIKEY
can be tunneled in SIP and RTSP. It takes advantage of the session
information contained in these protocols and the possibility to
optimize the setup time for the registration procedure. SIP requires
that a tunneled protocol must use at most one roundtrip
(i.e. (i.e., two
messages). This is also a desirable requirement from RTSP
as well. RTSP.
The GDOI approach takes advantage of the already defined ISAKMP phase
1 exchange [RFC2409], and extends the phase 2 exchange for the
registration. The advantage here is the reuse of a successfully
deployed protocol and the code base, where the defined phase 2
exchange is protected by the SA created by phase 1. GDOI also
inherits other functionality of the ISAKMP, and thus it is readily
suitable for running IPsec protocols over IP multicast services.
4.2
4.2. Properties of Alternative registration Registration Exchange Types
The required design properties of a registration protocol have
different tradeoffs. trade-offs. A protocol that provides perfect forward
secrecy and identity protection trades performance or efficiency for
better security, while a protocol that completes in one or two
messages may trade security functionality (e.g. (e.g., identity protection)
for efficiency.
Replay protection generally uses either a timestamp or a sequence
number. The first requires synchronized clocks, while the latter
requires that it is possible to keep retention of state. In a timestamp-based protocol, a replay
cache is needed to store the authenticated messages (or the hashes of
the messages) received within the allowable clock skew. The size of
the replay cache depends on the number of authenticated messages
received during the allowable clock skew. During a DoS attack, the
replay cache might become overloaded. One solution is to over-provision over-
Baugher, et al. Informational [Page 14]
RFC 4046 MSEC Group Key Management Architecture April 2005
provision the replay cache.
However, cache, but this may lead to a large replay
cache. Another solution is to let the allowable clock skew be
changed dynamically during runtime. During a suspected DoS attack,
the allowable clock skew is decreased so that the replay cache
becomes manageable.
A challenge-response mechanism (using Nonces) obviates the need for
synchronized clocks for replay protection when the exchange uses
three or more messages [MVV].
Internet Draft Group Key Management Architecture [PAGE 14]
Baugher, Canetti, Dondeti, Lindholm June 2004
Additional security functions become possible as the number of
allowable messages in the registration protocol increase. ISAKMP
offers identity protection, for example, as part of a six-message
exchange. With additional security features, however, comes added
complexity: Identity protection, for example, not only requires
additional messages, but may result in DoS vulnerabilities since
authentication is performed in a late stage of the exchange after
resources already have been devoted.
In all cases, there are tradeoffs with the number of message
exchanged, the desired security services, and the amount of
infrastructure that is needed to support the group key management
service. Whereas protocols that use two or even one-message setup
have low latency and computation requirements, they may require more
infrastructure such as secure time or offer less security such as the
absence of identity protection. What tradeoffs are acceptable and
what are not is very much dictated by the application and application
environment.
4.3
4.3. Infrastructure for Alternative registration Registration Exchange Types
The registration protocol may need external infrastructures to be
able to handle
authentication and authorization, replay protection, protocol-run
integrity, and potentially possibly other security services such as secure, secure
synchronized clocks. For example, authentication and authorization
may need a PKI deployment (with either authorization-
based authorization-based
certificates or a separate management for this) management) or may be handled by using AAA
infrastructure. Replay protection using timestamps requires an
external infrastructure or protocol for clock synchronization.
However, external infrastructures may not always be needed, if needed; for
example pre-shared keys are used for authentication and
authorization; this
authorization. This may be the case if the subscription base is
relatively small. In a conversational multimedia scenario (e.g., a
VoIP call between two or more people), it may very well be the end user who
handles the authorization by manually accepting/rejecting the
incoming calls. Thus, In that case, infrastructure support may not be
required in that case.
4.4
required.
Baugher, et al. Informational [Page 15]
RFC 4046 MSEC Group Key Management Architecture April 2005
4.4. De-registration Exchange
The session-establishment protocol (e.g., SIP, RTSP) that conveys a
registration exchange often has a session-disestablishment protocol
such as RTSP TEARDOWN [RFC2326] or SIP BYE [RFC2543]. [RFC3261]. The session-
disestablishment exchange between endpoints offers an opportunity to
signal the end of the GSA state at the endpoints. This exchange need
only be a uni-directional unidirectional notification by one side that the GSA is to
be destroyed. For authentication of this notification, we may
Internet Draft Group Key Management Architecture [PAGE 15]
Baugher, Canetti, Dondeti, Lindholm June 2004 use a
proof-of-possession of the group key(s) by one side to the other.
Some applications benefit from acknowledgement in a mutual,
two-message two-
message exchange signaling disestablishment of the GSA concomitant
with disestablishment of the session, e.g., RTSP or SIP session. In
this case, a two-way proof-of-possession might serve for mutual
acknowledgement of the GSA disestablishment.
5.0
5. Rekey protocol Protocol
The group rekey protocol is for transport of keys and SAs between a
GCKS and the members of a secure communications group. The GCKS
sends rekey messages to update a Rekey SA, or initialize/update a
Data SA or both. Rekey messages are protected by a Rekey SA. The
GCKS may update the Rekey SA when group membership changes or when
KEKs or TPKs expire. Recall that KEKs correspond to a Rekey SA and
TPKs correspond to a Data SA.
The following are some desirable properties of the rekey protocol: protocol.
o Rekey The rekey protocol ensures that all members receive the rekey
information in a timely manner.
o Rekey The rekey protocol specifies mechanisms for allowing the parties
involved, to
contact the GCKS and re-sync when their keys expire and no
updates have been received.
o Rekey The rekey protocol avoids implosion problems and ensures the
needed
reliability in delivering Rekey information.
We further note that the rekey protocol is primarily responsible for
scalability of the group key management architecture. Hence Hence, it is
imperative that we provide the above listed properties in a scalable
manner. Note that solutions exist in the literature (both IETF
standards and research articles) for parts of the problem. For
instance, the rekey protocol may use a scalable group key management
algorithm (GKMA) to reduce the number of keys sent in a rekey
message. Examples of a GKMA include LKH, OFT, Subset difference
based schemes etc.
5.1
Baugher, et al. Informational [Page 16]
RFC 4046 MSEC Group Key Management Architecture April 2005
5.1. Goals of the rekey protocol Rekey Protocol
The goals of the rekey protocol are:
o to synchronize a GSA GSA,
o to provide privacy and (symmetric or asymmetric)
authentication, replay protection and DoS protection
Internet Draft Group Key Management Architecture [PAGE 16]
Baugher, Canetti, Dondeti, Lindholm June 2004 protection,
o efficient rekeying after changes in group membership, membership or when
keys (KEKs) expire,
o reliable delivery of rekey messages,
o provide methods for members to recover member recovery from an out-of-sync GSA,
o high throughput and low latency, and
o to use support IP Multicast or multi-unicast.
We identify several major issues in the design of a rekey protocol:
1. rekey message format format,
2. reliable transport of rekey messages messages,
3. implosion implosion,
4. recovery from out-of-sync GSA GSA,
5. incorporating GKMAs in rekey messages messages, and
6. interoperability of GKMAs GKMAs.
Note that interoperation of rekey protocol implementations is
insufficient for a GCKS to successfully rekey a group, it is not
sufficient that rekey protocol implementations interoperate. We also
need to ensure that the group. The GKMA must
also interoperates, interoperate, i.e., standards standard versions of the group key
management algorithms, algorithms such as LKH, OFT, subset
difference and others need to or Subset Difference must be
used.
In the
The rest of this section we discuss discusses these topics in detail.
5.2
5.2. Rekey message Message Transport and Protection
Rekey messages contain Rekey and/or Data SAs along with KEKs and
TPKs. These messages need to be confidential, authenticated, and
protected against replay and DoS attacks. They are sent via
multicast or multi-unicast from the GCKS to the members.
Baugher, et al. Informational [Page 17]
RFC 4046 MSEC Group Key Management Architecture April 2005
Rekey messages are encrypted with the Group KEK for confidentiality.
When used in conjunction with a GKMA, portions of the rekey message
are first encrypted with the appropriate KEKs as specified by the
GKMA. The GCKS authenticates rekey messages using either a MAC - MAC,
computed using the group Authentication key - key, or a digital signature.
In both cases, a sequence number is included in computation of the
MAC or the signature to protect against replay attacks.
Internet Draft Group Key Management Architecture [PAGE 17]
Baugher, Canetti, Dondeti, Lindholm June 2004
When group authentication is provided - with a symmetric key - key, rekey
messages are vulnerable to attacks by other members of the group.
Rekey messages are digitally signed when group members do not trust
each other. When asymmetric authentication is used, members
receiving rekey messages are vulnerable to DoS attacks. An external
adversary may send a bogus rekey message, which a member cannot
identify until after it performs an expensive digital signature
operation. To protect against such an attack, a MAC may be sent as
part of the rekey message. Members verify the signature only upon
successful verification of the MAC.
Rekey messages contain group key updates corresponding to a single
[RFC2627, OFT]
[RFC2627,OFT] or multiple membership changes [SD, BatchRekey] [SD1,SD2,BatchRekey] and
may contain group key initialization messages [OFT].
5.3
5.3. Reliable Transport of rekey messages Rekey Messages
The GCKS needs to must ensure that all members have the current Data Security
and Rekey SAs. Otherwise, authorized members may be inadvertently
excluded from receiving group communications. Thus, the GCKS needs
to use a rekey algorithm that is inherently reliable or employ some a
reliable transport mechanism to send rekey messages.
There are two dimensions to the problem: problem. Messages that update group
keys may be lost in transit or may be missed by a host when it is
offline. LKH and OFT group key management algorithms rely on past
history of updates being received by the host. If the host goes
offline, it will need to resynchronize its group-key state when it
comes online; this may require a unicast exchange with the GCKS. The
Subset Difference algorithm, however, conveys all the needed necessary state
in its rekey messages and does not need members to be always
online, nor online
or keeping state. The Subset difference Difference algorithm does not require a backchannel
back channel and can operate on a broadcast network. If a rekey
message is lost in transmission, subset difference the Subset Difference algorithm
cannot decrypt messages encrypted with the TPK sent via the lost
rekey message. There are self-healing GKMAs proposed in the
literature that allow a member to recover lost rekey messages, as
long as rekey messages before and after the lost rekey message are
received.
Baugher, et al. Informational [Page 18]
RFC 4046 MSEC Group Key Management Architecture April 2005
Rekey messages are typically short (for single membership change as
well as for small groups) groups), which makes it easy to design a reliable
delivery protocol. On the other hand, the security requirements may
add an additional dimension to address. Also there There are some special cases where
in which membership changes are processed as a batch, which
reduces reducing the
frequency of rekey messages, messages but increases increasing their size. Furthermore,
among all the KEKs sent in a rekey message, as many as half the
members need only a single KEK. We may take advantage of these
properties in designing a rekey message(s) and a protocol for their
reliable delivery.
Internet Draft Group Key Management Architecture [PAGE 18]
Baugher, Canetti, Dondeti, Lindholm June 2004
Three categories of solutions have been proposed:
1. Repeatedly transmit the rekey message: Recall that in message. In many cases rekey
messages translate to only one or two IP packets.
2. Use an existing reliable multicast protocol/infrastructure protocol/infrastructure.
3. Use FEC for encoding rekey packets (with NACKs as feedback)
[BatchRekey]
[BatchRekey].
Note that for small messages, category 3 is essentially the same as
category 1.
The group member might be out of synchrony with the GCKS if it
receives a rekey message having a sequence number that is more than
one greater than the last sequence number processed. This is one
means by which the GCKS member detects that it has missed a rekey
message. Alternatively, the data-security application might detect application, upon
detecting that it is using an out-of-date key and notifies key, may notify the group
key management module of this condition. What module. The action taken by the GCKS member
takes is a
matter of group policy: policy. The GCKS member should log the condition and
may contact the GCKS to re-run rerun the re-registration protocol to obtain
a fresh group key. The group policy needs to take into account
boundary conditions, such as re-ordered reordered rekey messages when rekeying
is so frequent that two messages might get reordered in an IP
network. The group key policy also needs to take into account the
potential for denial of service attacks where an attacker delays or
deletes a rekey message in order to force a subnetwork or subset of
the members to synchronously simultaneously contact the GCKS.
If a group member becomes out-of-synch with the GSA then it should
re-register with the GCKS. However, in many cases there are other,
simpler methods for re-synching with the group:
o The member can open a simple, simple unprotected connection (say, (e.g., TCP)
with the GCKS and obtain the current (or several recent) rekey
messages. Note that there is no need for authentication or
Baugher, et al. Informational [Page 19]
RFC 4046 MSEC Group Key Management Architecture April 2005
encryption here, since the rekey message is already signed and
is anyway multicasted multicast in the clear. One may think that this opens the
GCKS to DoS attacks by many bogus such requests. But
this This,
however, does not seem to worsen the situation: situation; in fact,
bombarding the GCKS with bogus resynch requests would be much
more problematic.
o The GCKS can post the rekey messages on some public site (say, (e.g.,
a web site) and the out-of-synch memeber member can obtain the rekey
messages from that site.
Internet Draft Group Key Management Architecture [PAGE 19]
Baugher, Canetti, Dondeti, Lindholm June 2004
It is suggested that the
The GCKS may always provide all three ways of resynching (i.e., re-registration, re-
registration, simple TCP, and public posting). This way, it is up to the member to
may choose how to resynch; it also avoids adding yet another field to
the policy token [GSPT]. Alternatively, a policy token may contain a
field specifying one or more methods supported for resynchronization
of a GSA.
5.4
5.4. State-of-the-art on Reliable Multicast Infrastructure
The rekey message may be sent using reliable multicast. There are
multiple
several types of reliable multicast protocols and products, which
have with different
properties. However, there are no standard standards track reliable multicast
protocols published at this time, although IETF consensus has been
reached on two protocols that are intended to go into the present time. standards
track [NORM,RFC3450]. Thus, this document makes
no recommendation for use of does not recommend a
particular reliable multicast protocol or set of protocols for the purposes
purpose of reliable group key management. rekeying. The suitability of NAK-based,
ACK-based or other reliable multicast methods are is determined by the particular needs of the group key
management
application needs and operational environment. In the future, group
key management protocols may choose to use particular standards-based
approaches that meet the needs of the particular application. A
secure announcement facility is may be needed to signal the use of a
reliable multicast protocol, which must could be specified as part of
group policy. The reliable multicast announcement and policy
specification, however, can only follow the establishment of reliable
multicast standards and are not considered further in this document.
Today, the several MSEC group key management protocols support
sequencing of the rekey messages through a sequence number, which is
authenticated along with the rekey message. A sender of rekey
messages may re-transmit multiple copies of the message provided that
they have the same sequence number. Thus, re-sending the message is
a rudimentary means of overcoming loss along the network path. A
member who receives the rekey message will check the sequence number
to detect duplicate and missing rekey messages. The member receiver
will discard duplicate messages that it receives. Large rekey
messages, such as those that contain LKH or OFT tree structures,
Baugher, et al. Informational [Page 20]
RFC 4046 MSEC Group Key Management Architecture April 2005
might benefit from transport-layer FEC when standard
methods are available in the future. future, when
standards-based methods become available. It is unlikely that
forward error correction (FEC) methods will benefit short rekey
messages that are
short and fit within a single message. In this case, FEC
degenerates to simple retransmission of the message.
5.5
5.5. Implosion
Implosion may occur due to one of two reasons. First, recall that
one of the goals of the rekey protocol is to synchronize a GSA. When
a rekey or Data SA expires, members may contact the GCKS for an
update. If all all, or even many many, members contact the GCKS at about the
Internet Draft Group Key Management Architecture [PAGE 20]
Baugher, Canetti, Dondeti, Lindholm June 2004
same time, the GCKS cannot might not be able to handle all those messages.
We refer to this as an out-of-sync implosion.
The second case is in the reliable delivery of rekey messages.
Reliable multicast protocols use feedback (NACK or ACK) to determine
which packets must be retransmitted. Packet losses may result in
many members sending NACKs to the GCKS. We refer to this as feedback
implosion.
The implosion problem has been studied extensively in the context of
reliable multicasting. Some of the The proposed solutions viz., feedback suppression and aggregation,
aggregation solutions might be useful in the GKM context as well.
Members may wait for a random time before sending an out-of-sync or
feedback message. Meanwhile, members might receive the necessary key
updates
they need and therefore will not send a feedback message. An alternative
solution is to have the members contact one of several registration
servers when they are out-of-sync. This requires GSA synchronization
between the multiple registration servers.
Feedback aggregation and local recovery employed by some reliable
multicast protocols are not easily adaptable to transport of rekey
messages. There are Aggregation raises authentication issues to address in aggregation. issues. Local recovery
is more complex in that because members need to establish SAs with the local
repair server (Any server. Any member of the group or a subordinate GCKS might may
serve as a repair server. Repair servers may server, which can be responsible for resending
rekey messages). messages.
Members may use the group SA, more specifically the Rekey SA, to
authenticate requests sent to the repair server; however, server. However, replay
protection requires maintaining state at members as well as repair
servers. Authentication of repair requests is meant to protect
against DoS attacks. Note also that an out-of-sync member may use an
expired Rekey SA to authenticate repair requests, which requires
repair servers to accept messages protected by old SAs.
Baugher, et al. Informational [Page 21]
RFC 4046 MSEC Group Key Management Architecture April 2005
Alternatively, a simple mechanism may be employed to achieve local
repair efficiently. Each member receives a set of local repair
server addresses as part of group operation policy information. When
a member does not receive a rekey message, it can send a "retransmit "Retransmit
replay message(s) with sequence number n and higher" message to one
of the local repair servers. The repair server can do one of two things: either ignore the
request if it is busy, busy or retransmit the requested rekey messages as
received from the GCKS. The repair server, which is also another
member may choose to serve only m requests in a given time period
(i.e., rate limits responses) or per a given rekey message. Rate
limiting the requests and responses protects the repair servers
Internet Draft Group Key Management Architecture [PAGE 21]
Baugher, Canetti, Dondeti, Lindholm June 2004 as
well as other members of the group from being vulnerable to DoS attacks.
5.6 Issues in
5.6. Incorporating Group Key Management Algorithms
Group key management algorithms make Rekeying rekeying scalable. Large group
Rekeying
rekeying without employing GKMAs is prohibitively expensive.
First we list
Following are some requirements to consider considerations in selecting a GKMA:
o Protection against Collusion: collusion.
Members (or non members) non-members) should not be able to collaborate to
deduce keys that for which they are not privileged to (following the
GKMA key distribution rules).
o Forward access control: Ensure control
The GKMA should ensure that departing members cannot get access
to future group data.
o Backward access control: Ensure control
The GKMA should ensure that joining members cannot decrypt past
data.
5.7
5.7. Stateless, Stateful, and Self-healing Rekeying Algorithms
We classify group key management algorithms into three categories,
viz., categories:
stateful, stateless, and self-healing algorithms. self-healing.
Stateful algorithms [RFC2627, OFT] [RFC2627,OFT] use KEKs from past rekeying
instances to encrypt (protect) KEKS KEKs corresponding to the current and
future rekeying instances. The main disadvantage in these schemes is
that if a member were offline or otherwise fails failed to receive KEKs
from a past rekeying instance, it may no longer be able to
synchronize its GSA even though it can receive KEKs from all future
rekeying instances. The only solution is to contact the GCKS
Baugher, et al. Informational [Page 22]
RFC 4046 MSEC Group Key Management Architecture April 2005
explicitly for resynchronization. Note that the KEKs for the first
rekeying instance are protected by the Registration SA. Recall that
communication in that phase is one to one, and therefore it is easy
to ensure reliable delivery.
Stateless GKMAs [SD1, SD2] [SD1,SD2] encrypt rekey messages with KEKs sent
during the registration protocol. Since rekey messages are
independent of any past rekey messages (i.e. (i.e., that are not protected
by KEKs therein), a member may go offline, offline but continue to be able to decipher
future communications. However, they stateless GKMAs offer no mechanisms
to recover past rekeying messages. Stateless rekeying may be
relatively inefficient, particularly for immediate (in contrast to (not batch)
rekeying in highly dynamic groups.
In self-healing schemes [Self-healing], [Self-Healing], a member can reconstruct a
lost rekey message, message as long as it receives some past rekey messages and some future
rekey messages.
Internet Draft Group Key Management Architecture [PAGE 22]
Baugher, Canetti, Dondeti, Lindholm June 2004
5.8
5.8. Interoperability of a GKMA
Most GKMA specifications do not specify packet formats formats, although any many
group key management algorithms need to, format specification for the purposes of
interoperability. In particular there There are several alternative ways to managing manage key
trees and numbering to number nodes within key trees. The following
information is generally needed during initialization of a Rekey SA or included
with each GKMA packet.
o GKMA name (e.g. (e.g., LKH, OFT, Subset difference) Difference)
o GKMA version number (implementation specific). Version may
imply several things such as the degree of a key tree,
proprietary enhancements, and qualify another field such as a
key id. ID.
o Number of keys or Largest largest ID
o Version specific Version-specific data
o Per key information Per-key information:
- Key ID key ID,
- Key key lifetime (creation/expiration data) ,
- Encrypted key encrypted key, and
- Encryption encryption key's ID (optional) (optional).
Baugher, et al. Informational [Page 23]
RFC 4046 MSEC Group Key Management Architecture April 2005
Key IDs may change in some implementations in which case we need one needs to
send:
o List of <old id, new id>
6.0 pairs.
6. Group Security Association
The GKM Architecture architecture defines the interfaces between the registration,
Rekey,
rekey, and data security protocols in terms of the Security
Associations (SAs) of those protocols. By isolating these protocols
behind a uniform interface, the architecture allows implementations
to use protocols best suited to their needs. For example, a rekey
protocol for a small group could use multiple unicast transmissions
with symmetric authentication, while that a rekey protocol for a large
group could use IP Multicast with packet-level Forward Error
Correction and source authentication.
The Group Key Management Architecture group key management architecture provides an interface between
the security protocols and the group SA (GSA), which (GSA). The GSA consists of
Internet Draft Group Key Management Architecture [PAGE 23]
Baugher, Canetti, Dondeti, Lindholm June 2004
three SAs, viz., SAs: Registration SA, Rekey SA SA, and Data SA. The Rekey SA is
optional. There are two cases in defining the relationships between
the three SAs. In both cases, the Registration SA protects the
registration protocol.
In
Case 1, group 1: Group key management is done WITHOUT using a Rekey SA. The
registration protocol initializes and updates one or more Data SAs
(having TPKs to protect files or streams). Each Data SA
corresponds to a single group - and a group group, which may have more than one Data
SA.
In
Case 2, group 2: Group key management is done WITH a Rekey SA to protect the
rekey protocol. The registration protocol initializes the one or
more Rekey SAs (one or more) as well as zero or more Data SAs SAs, upon successful
completion. When a Data SA is not initialized in the registration
protocol, this initialization is done in the rekey protocol. The rekey
protocol updates Rekey SA(s) AND establishes Data SA(s).
6.1
6.1. Group policy Policy
Group policy is described in detail in the Group Security Policy
Token document [GSPT]. Group policy can be distributed through group
announcements, key management protocols, and other out-of-band means
(e.g., via a web page). The group key management protocol carries
cryptographic policies of the SAs and the keys it establishes establishes, as
well as additional policies for the secure operation of the group.
Baugher, et al. Informational [Page 24]
RFC 4046 MSEC Group Key Management Architecture April 2005
The acceptable cryptographic policies for the registration protocol,
which may run over TLS [TLS], IPsec, or IKE, are not conveyed in the
group key-management key management protocol since they precede any of the key
management exchanges. Thus, a security policy repository having some
access protocol may need to be queried prior to establishing the
key-management
session establishment session, to determine the initial cryptographic
policies for that establishment. This document assumes the existence
of such a repository and protocol for GCKS and member policy queries.
Thus group security policy will be represented in a policy repository
and accessible using a policy protocol. Policy distribution may be a
push or a pull operation.
The group key management architecture assumes that the following
group-policy
group policy information may be externally managed, e.g., by the
content owner, group conference administrator or group owner. owner:
o Identity the identity of the Group owner, and the authentication method, and
the delegation method for identifying a GCKS for the group group;
o Group the group GCKS, authentication method, and delegation method
for any subordinate GCKSs for the group group;
o Group the group membership rules or list and authentication method
Internet Draft Group Key Management Architecture [PAGE 24]
Baugher, Canetti, Dondeti, Lindholm June 2004 method.
There are also two additional policy-related requirements external to
group key management.
o There is an authentication and authorization infrastructure
such as X.509 [RFC 2459], [RFC3280], SPKI [RFC 2693], [RFC2693], or a pre-shared key scheme
scheme, in accordance with the group policy for a particular
group.
o There is an announcement mechanism for secure groups and events
that
events, which operates according to group policy for a
particular group.
Group policy determines how the registration and rekey protocols
initialize or update Rekey and Data SAs. The following sections
describe potential information sent by the GCKS for the Rekey and
Data SAs. A member needs to have the information specified in the next
sections to establish Rekey and Data SAs.
6.2
6.2. Contents of the Rekey SA
The Rekey SA protects the rekey protocol. It contains cryptographic
policy, Group Identity Identity, and Security Parameter Index (SPI) [RFC2401]
to uniquely identify an SA, replay protection information, and key
protection keys.
6.2.1
Baugher, et al. Informational [Page 25]
RFC 4046 MSEC Group Key Management Architecture April 2005
6.2.1. Rekey SA Policy
The
o GROUP KEY MANAGEMENT ALGORITHM
This represents the group key revocation algorithm that
enforces forward and backward access control. Examples of key
revocation algorithms include LKH, LKH+, OFT, OFC OFC, and Subset
Difference [RFC2627, OFT, TAXONOMY, SDR]. The [RFC2627,OFT,TAXONOMY,SD1,SD2]. If the key
revocation algorithm could also be NULL. In that case, is NULL, the Rekey SA contains only one
KEK, which serves as the group KEK. The rekey messages
initialize or update Data SAs as usual. But, However, the Rekey SA
itself can be updated (group (the group KEK can be Rekeyed) rekeyed) when
members join or the KEK is about to expire. Leave Rekeying rekeying is
done by re-
initializing re-initializing the Rekey SA through the rekey
protocol.
The
o KEK ENCRYPTION ALGORITHM uses
This specifies a standard encryption algorithm such as 3DES or AES. The
AES, and also the KEK KEY LENGTH is also specified.
The LENGTH.
o AUTHENTICATION ALGORITHM
This algorithm uses digital signatures for GCKS authentication
(since all shared secrets are known to some or all members of
the group), or some symmetric secret in computing MACs for
group authentication. Symmetric authentication provides weaker
authentication in that any group member can impersonate a
particular source. The AUTHENTICATION KEY LENGTH is also to be
specified.
The
o CONTROL GROUP ADDRESS
This address is used for multicast transmission of rekey
messages. This information is sent over the control channel
such as in an ANNOUNCEMENT protocol or call setup message. The
degree to
Internet Draft Group Key Management Architecture [PAGE 25]
Baugher, Canetti, Dondeti, Lindholm June 2004 which the control group address is protected is a
matter of group policy.
The
o REKEY SERVER ADDRESS
This address allows the registration server to be a different
entity from the server used for Rekey, rekeying, such as for future
invocations of the registration and rekey protocols. If the
registration server and the Rekey rekey server are two different
entities, the registration server sends the Rekey servers rekey server's
address as part of the Rekey SA.
6.2.2
Baugher, et al. Informational [Page 26]
RFC 4046 MSEC Group Key Management Architecture April 2005
6.2.2. Group Identity
The Group group identity accompanies the SA (payload) information as an
identifier if the specific group key management protocol allows
multiple groups to be initialized in a single invocation of the
registration protocol protocol, or multiple groups to be updated in a single
rekey message. It is often much simpler to restrict each registration
invocation to a single group; no group, but such a restriction is
necessary. There unnecessary.
It is always a need necessary to identify the group when establishing a
Rekey SA SA, either implicitly through an SPI or explicitly as an SA
parameter.
6.2.3
6.2.3. KEKs
Corresponding to the key management algorithm, the Rekey SA contains
one or more KEKs. The GCKS holds the key encrypting keys of the
group, while the members receive keys following the specification of
the key-management key management algorithm. When there are multiple KEKs for a
group (as in an LKH tree), each KEK needs to be associated with a Key
ID, which is used to identify the key needed to decrypt it. Each KEK
has a LIFETIME associated with it, after which the KEK expires.
6.2.4
6.2.4. Authentication Key
The GCKS provides a symmetric or public key for authentication of its
rekey messages. Symmetric-key authentication Symmetric key authentication is appropriate only
when all group members can be trusted not to impersonate the GCKS.
The architecture does not rule out methods for deriving symmetric
authentication keys at the member [RFC2409] rather than being pushed pushing them
from the GCKS.
6.2.5
6.2.5. Replay Protection
Rekey messages need to be protected from replay/reflection attacks.
Sequence numbers are used for this purpose purpose, and the Rekey SA (or
protocol) contains this information.
6.2.6
6.2.6. Security Parameter Index (SPI)
Internet Draft Group Key Management Architecture [PAGE 26]
Baugher, Canetti, Dondeti, Lindholm June 2004
The tuple <Group identity, SPI > SPI> uniquely identifies a Rekey SA. The
SPI changes each time the KEKs change.
6.3
6.3. Contents of the Data SA
The GCKS specifies the data security protocol used for secure
transmission of data from sender(s) to receiving members. Examples
of data security protocols include IPsec ESP [RFC 2401] [RFC2401] and SRTP [RFC
3711].
[RFC3711]. While the content contents of each of these protocols is are out of
Baugher, et al. Informational [Page 27]
RFC 4046 MSEC Group Key Management Architecture April 2005
the scope of this document, we list the information sent by the
registration protocol (or the rekey protocol) to initialize or update
the Data SA.
6.3.1
6.3.1. Group Identity
The Group identity accompanies SA information when Data SAs are
initialized or Rekeyed rekeyed for multiple groups in a single invocation of
the registration protocol or in a single rekey Rekey message.
6.3.2
6.3.2. Source Identity
The SA includes source identity information when the group owner
chooses to reveal Source source identity to authorized members only. A
public channel such as the announcement protocol is only appropriate
when there is no need to protect source or group identities.
6.3.3
6.3.3. Traffic Protection Keys
Irrespective
Regardless of the data security protocol used, the GCKS supplies the TEKs
TPKs, or information to derive TEKs, used TPKs for data encryption.
6.3.4 traffic protection.
6.3.4. Data Authentication Keys
Depending on the data-authentication data authentication method used by the data security
protocol, group key management may pass one or more keys, functions
(e.g., TESLA [TESLA]), [TESLA-INFO,TESLA-SPEC]), or other parameters used for
authenticating streams or files.
6.3.5
6.3.5. Sequence Numbers
The GCKS passes sequence numbers when needed by the data security
protocol, for SA synchronization and replay protection.
6.3.6
6.3.6. Security Parameter Index (SPI)
The GCKS may provide an identifier as part of the Data SA contents
for data security protocols that use an SPI or similar mechanism to
identify an SA or keys within an SA.
Internet Draft Group Key Management Architecture [PAGE 27]
Baugher, Canetti, Dondeti, Lindholm June 2004
6.3.7
6.3.7. Data SA policy
The Data SA parameters are specific to the data security protocol but
generally include encryption algorithm and parameters, the source
authentication algorithm and parameters, the group authentication
algorithm and parameters, and/or replay protection information.
7.0
Baugher, et al. Informational [Page 28]
RFC 4046 MSEC Group Key Management Architecture April 2005
7. Scalability Considerations
The area of group communications is quite diverse. In
teleconferencing, a multipoint control unit (MCU) may be used to
aggregate a number of teleconferencing members into a single session;
MCUs may be hierarchically organized as well. A loosely coupled
teleconferencing session [RFC3550] has no central controller but is
fully distributed and end-to-end. Teleconferencing sessions tend to
have at most dozens of participants whereas participants. However, video broadcast, which broadcast that
uses multicast communications, communications and media on demand, which media-on-demand that uses
unicast, unicast
are large-scale groups numbering hundreds to millions of
participants.
As described in the Requirements section above, section, Section 2, the group key
management architecture supports multicast applications with a single
sender. The architecture described in this paper supports large-
scale operation through the following features.
1. There is no need for a unicast exchange to provide data keys to a
security protocol for members who have previously-registered previously registered in
the particular group; data keys can be pushed in the rekey
protocol.
2. The registration and rekey protocols are separable to allow
flexibility in how members receive group secrets. A group can may use
a smart-card based system in place of the registration protocol,
for example, to allow the rekey protocol to be used with no back
channel for broadcast applications such as television conditional
access systems.
3. The registration and rekey protocols support new keys, algorithms,
authentication mechanisms and authorization infrastructures in the
architecture. When the authorization infrastructure supports
delegation, as in X.509 and SPKI, the GCKS function can be
distributed as shown in Figure 3.
Internet Draft 3 below.
The first feature in the list allows fast keying of data security
protocols when the member already belongs to the group. While this
is realistic for subscriber groups and customers of service providers
who offer content events, it may be too restrictive for applications
that allow member enrollment at the time of the event. The MSEC
group key management architecture suggests hierarchically organized
key distribution to handle potential mass simultaneous registration
requests. The Figure 3 configuration may be needed when conventional
clustering and load balancing solutions of a central GCKS site cannot
meet customer requirements. Unlike conventional caching and content
Baugher, et al. Informational [Page 29]
RFC 4046 MSEC Group Key Management Architecture [PAGE 28]
Baugher, Canetti, Dondeti, Lindholm June 2004 April 2005
distribution networks, however, the configuration shown in Figure 3
has additional security ramifications for physical security of a
GCKS.
+----------------------------------------+
| +-------+ |
| | GCKS | |
| +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| +-------------+ |
| | | |
| v ... v |
| +-------+ +-------+ |
| | GCKS | | GCKS | |
| +-------+ +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| ... |
+----------------------------------------+
Figure 3: Hierarchically-organized Hierarchically Organized Key Distribution
The first feature in the list allows fast keying of data security
protocols when the member already belongs to the group. While this
is realistic for subscriber groups and customers of service providers
who offer content events, it may be too restrictive for applications
that allow member enrollment at the time of the event. The MSEC
group key management architecture suggests hierarchically organized
key distribution to handle potential mass simultaneous registration
requests. The Figure 3 configuration may be needed when conventional
clustering and load-balancing solutions of a central GCKS site cannot
meet customer requirements. Unlike conventional caching and content-
distribution networks, however, the configuration shown in Figure 3
has additional security ramifications for physical security of a
GCKS.
More analysis and work needs to be done is needed on the protocol instantiations of
the group key management architecture architecture, to determine how effectively
and securely the architecture can support large-
scale large-scale multicast
applications. In addition to being as secure as
Internet Draft Group Key Management Architecture [PAGE 29]
Baugher, Canetti, Dondeti, Lindholm June 2004 addition to being as secure as pairwise key
management against man-in-the-middle, replay, and reflection attacks,
group key management protocols have additional security needs.
Unlike pairwise key management, group key management needs to be
secure against attacks not only by non-
members but by group members who may attempt to impersonate a
GCKS or disrupt the operation of a GCKS. GCKS, as well as by non-members.
Baugher, et al. Informational [Page 30]
RFC 4046 MSEC Group Key Management Architecture April 2005
Thus, secure groups need to converge to a common group key under the conditions of when
members are attacking the group, joining and leaving the group, and or
being evicted from the group. Group key management protocols also
need to be robust when denial of service DoS attacks or network partitions lead partition leads to
large numbers of synchronized requests. An instantiation of group
key management, therefore, needs to consider how GCKS operation might
be distributed across multiple GCKS as GCKSs designated by the group owner to
serve keys on behalf of a designated GCKS. GSAKMP [GSAKMP] protocol
uses the policy token and allows designating some of the members as
subordinate GCKSs to address this scalability issue.
8.0
8. Security Considerations
This memo describes MSEC key management architecture. This
architecture will be instantiated in one or more group key management
protocols, which must be protected against man-in-the-middle,
connection hijacking, replay replay, or reflection of past messages, and
denial of service attacks.
Authenticated key exchange [STS, SKEME, RFC2408, RFC2412, RFC2409] [STS,SKEME,RFC2408,RFC2412,RFC2409]
techniques limit the effects of man-in-the-middle and connection- connection
hijacking attacks. Sequence numbers and low-computation message
authentication techniques can be effective against replay and
reflection attacks. Cookies [RFC2522], when properly implemented,
provide an efficient means to reduce the effects of denial of service
attacks.
This memo does not address attacks against key management or security
protocol implementations such as so-called type attacks that aim to
disrupt an implementation by such means as buffer overflow. The
focus of this memo is on securing the protocol, not an implementation
of on implementing
the protocol.
While classical techniques of authenticated key exchange can be
applied to group key management, new problems arise with the sharing
of secrets among a group of members: Group group secrets may be disclosed
by a member of the group group, and group senders may be impersonated by
other members of the group. Key management messages from the GCKS
should not be authenticated using shared symmetric secrets unless all
members of the group can be trusted not to impersonate the GCKS or
each other. Similarly, members who disclose group secrets undermine
the security of the entire group. group Group owners and GCKS
Internet Draft Group Key Management Architecture [PAGE 30]
Baugher, Canetti, Dondeti, Lindholm June 2004
administrators must be aware of these inherent limitations of group
key management.
Another limitation of group key management is policy complexity:
Whereas complexity.
While peer-to-peer security policy is an intersection of the policy
of the individual peers, a group owner sets group security policy
Baugher, et al. Informational [Page 31]
RFC 4046 MSEC Group Key Management Architecture April 2005
externally in secure groups. This document assumes there is no
negotiation of cryptographic or other security parameters in group
key management. Group security policy, therefore, poses new risks to
members who send and receive data from secure groups. Security
administrators, GCKS operators, and users need to determine minimal
acceptable levels of security (e.g., authentication and admission
policy of the group, key lengths, cryptographic algorithms and
protocols used etc.) used) when joining secure groups.
Given the limitations and risks of group security, the security of
the group key management registration protocol should be as good as
the base protocols on which it is developed developed, such as IKE, IPsec, TLS,
or SSL. The particular instantiations of this Group Key Management group key management
architecture must ensure that the high standards for authenticated
key exchange are preserved in their protocol specifications, which
will be Internet standards-track documents that are subject to
review, analysis analysis, and testing.
The second protocol, the group key management rekey protocol, is new
and has unknown risks associated with it. risks. The source-authentication risks described
above are obviated by the use of public-key cryptography. The use of
multicast delivery may raise additional security issues such as
reliability, implosion, and denial of service denial-of-service attacks based upon the
use of multicast. The rekey protocol specification needs to offer
secure solutions to these problems. Each instantiation of the rekey
protocol, such as the GSAKMP Rekey or the GDOI Groupkey-push
operations, need to validate the security of their Rekey rekey
specifications.
Novelty and complexity are the biggest risks to group key management
protocols. Much more analysis and experience are needed to ensure
that the architecture described in this document can provide a well-
articulate
articulated standard for security and risks of group key management.
9.0
9. Acknowledgments
The GKM Building Block [GKMBB) [GKMBB] I-D by SMuG was a precursor to this
document; thanks to Thomas Hardjono and Hugh Harney for their
efforts. During the course of preparing this document, Andrea
Colegrove, Brian Weis, George Gross Gross, and several others in the MSEC
WG and GSEC and SMuG research groups provided valuable comments that
helped improve this document. The authors appreciate their
contributions to this document.
Internet Draft
Baugher, et al. Informational [Page 32]
RFC 4046 MSEC Group Key Management Architecture [PAGE 31]
Baugher, Canetti, Dondeti, Lindholm June 2004
10.0 April 2005
10. Informative References and Bibliography
[BatchRekey] Yang, Y. R., et al., Reliable "Reliable Group Rekeying: Design
and Performance Analysis, in Analysis", Proc. of ACM SIGCOMM, San
Diego, CA, August 2001.
[CLIQUES] M. Steiner, G. Tsudik M., Tsudik, G., and M. Waidner, CLIQUES: "CLIQUES: A
New Approach to Group Key Agreement, Agreement", IEEE ICDCS 97,
May 1997
[FN93] A. Fiat, A. and M. Naor, Broadcast "Broadcast Encryption, Advances
in
Cryptology - Cryptology", CRYPTO 93 Proceedings, Lecture Notes
in Computer Science, Vol. 773, 1994, pp. 480 -- 491.
[GSAKMP] H.Harney, A.Colegrove, E.Harder, U.Meth, R.Fleischer, 480-491, 1994.
[GKMBB] Harney, H., M. Baugher, and T. Hardjono, "GKM
Building Block: Group Security Association (GSA)
Definition," Work in Progress, September 2000.
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and
R. Fleischer, "Group Secure Association Key
Management Protocol,
http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-msec-gsakmp-sec-
01.txt, February 2003, Protocol", Work in Progress. Progress, February
2003.
[GSPT] Hardjono, T., H. Harney, P. H., McDaniel, A. P., Colegrove,
A., and P. Dinsmore, The "The MSEC Group Security Policy Token, draft-ietf-msec-gspt-
02.txt, August 2003,
Token", Work in Progress. Progress, August 2003.
[H.235] ITU, Security International Telecommunications Union, "Security and encryption
Encryption for H-Series (H.323 and other H.245-based) multimedia terminals,
Multimedia Terminals", ITU-T Recommendation H.235
Version 3, 2001, Work in progress. progress, 2001.
[JKKV94] M. Just, E. M., Kranakis, D. E., Krizanc, D., and P. van
Oorschot, On "On Key Distribution via True Broadcasting. In Proceedings of
Broadcasting", Proc. 2nd ACM Conference on Computer
and Communications Security, November 1994, pp. 81--88. 81-88, November
1994.
[MARKS] Briscoe, B., MARKS: "MARKS: Zero Side Effect Multicast Key
Management Using Arbitrarily Revealed Key Sequences, in Sequences",
Proc. of First International Workshop on Networked
Group Communication (NGC), Pisa, Italy, November
1999.
[MIKEY] J. Arkko, E. J., Carrara, F. E., Lindholm, M. F., Naslund, M.,
and K. Norrman, MIKEY: "MIKEY: Multimedia Internet KEYing, Internet Draft,
http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-msec-mikey-
06.txt, February 2003, Work in progress. KEYing",
RFC 3830, August 2004.
Baugher, et al. Informational [Page 33]
RFC 4046 MSEC Group Key Management Architecture April 2005
[MSEC-Arch] Hardjono, T., T. and B. Weis, The "The Multicast Group
Security
Architecture, Architecture", RFC 3740 (Informational), 3740, March 2004.
[MVV] A.J.Menzes, P.C.van Menzes, A.J., van Oorschot, P.C., and S.A. Vanstone, Handbook
"Handbook of Applied Cryptography, Cryptography", CRC Press, 1996.
Internet Draft Group Key Management Architecture [PAGE 32]
Baugher, Canetti, Dondeti, Lindholm June 2004
[NORM] Adamon, B., Bormann, C., Handley, M., and J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol", RFC 3940, November 2004.
[OFT] Balenson, D., D. McGrew, P.C., and A. Sherman, Key "Key
Management for Large Dynamic Groups: One-Way Function
Trees and Amortized
Initialization, draft-irtf-smug-groupkeymgmt-oft-00.txt, IRTF, August
2000, Initialization", IRTF Work in progress.
Progress, August 2000.
[RFC2093] Harney, H., H. and C. Muckenhirn, Group "Group Key Management
Protocol (GKMP) Specification, Specification", RFC 2093 (experimental), 2093, July 1997.
[RFC2094] Harney, H., and C. Muckenhirn, Group "Group Key Management
Protocol (GKMP) Architecture, Architecture" RFC 2094 (experimental), 2094, July 1997.
[RFC2326] Schulzrinee, Schulzrinne, H., A. Rao, A., and R. Lanphier, Real "Real Time
Streaming Protocol (RTSP), (RTSP)", RFC 2326 (Proposed Standard), 2326, April 1998.
[RFC2327] Handley, M., M. and V. Jacobson, SDP: "SDP: Session
Description
Protocol, Protocol", RFC 2327 (Proposed Standard), 2327, April 1998.
[RFC2367] McDonald, D., C. Metz, C., and B. Phan, PF_KEY "PF_KEY Key
Management API, Version 2, 2", RFC 2367 (Informational), 2367, July 1998.
[RFC2401] Kent, S., S. and R. Atkinson, Security "Security Architecture for
the Internet Protocol, RFC 2401 (proposed standard), November 1998.
[RFC2406] Kent, S., and R. Atkinson, IP Encapsulating Security
Payload (ESP), Protocol", RFC 2406 (proposed standard), 2401, November 1998.
[RFC2408] Maughan, D., et al., Internet Schertler, M., Schneider, M., and J.
Turner, "Internet Security Association and Key
Management Protocol (ISAKMP), (ISAKMP)", RFC 2408 (proposed standard), 2408, November
1998.
[RFC2409] Harkins, D., D. and D. Carrel, The "The Internet Key Exchange
(IKE),
(IKE)", RFC 2409 (proposed standard), 2409, November 1998.
[RFC2412] H. Orman, The H., "The OAKLEY Key Determination Protocol, Protocol",
RFC 2412
(Informational), 2412, November 1998.
[RFC2522] Karn, P., P. and W. Simpson, Photuris: "Photuris: Session-Key
Management
Protocol, Protocol", RFC 2522 (Informational), 2522, March 1999.
[RFC2543]
Baugher, et al. Informational [Page 34]
RFC 4046 MSEC Group Key Management Architecture April 2005
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R.,
Thomas, B., and T. Ylonen, "SPKI Certificate Theory",
RFC 2693, September 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M., et. al., SIP:
and E. Schooler, "SIP: Session Initiation Protocol, Protocol",
RFC 2543 (Proposed Standard), March 1999. 3261, June 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC
3280, April 2002.
[RFC2627] Wallner, D., E. Harder, E., and R. Agee, Key "Key Management
for Multicast: Issues and Architectures, Architectures", RFC 2627(informational), IETF, 2627,
June 1999.
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and
J. Crowcroft, "Asynchronous Layered Coding (ALC)
Protocol Instantiation", RFC 3450, December 2002.
[RFC3547] M. Baugher, T. M., Weis, B., Hardjono, T., and H. Harney, B. Weis, The
"The Group Domain of Interpretation, Interpretation", RFC 3547 (Proposed Standard), 3547, July
2003.
Internet Draft Group Key Management Architecture [PAGE 33]
Baugher, Canetti, Dondeti, Lindholm June 2004
[RFC3550] H. Schulzrinne, S. H., Casner, R. S., Frederick, R., and V.
Jacobson, RTP: "RTP: A Transport Protocol for Real-Time Applications,
Applications", STD 64, RFC 3550 (Proposed
Standard), 3550, July 2003.
[RFC3711] Baugher, M., et. al., The McGrew, D., Naslund, M., Carrara, E.,
and K. Norrman, "The Secure Real Time Real-time Transport
Protocol,
Protocol (SRTP)", RFC 3711 (Proposed Standard), 3711, March 2004.
[SD1] Naor, D., M. Naor, M., and J. Lotspiech, Revocation "Revocation and
Tracing Schemes for Stateless Receivers, in Receiver", Advances in
Cryptology - CRYPTO, Santa Barbara, CA: Springer-Verlag Springer-
Verlag Inc., LNCS 2139, August 2001.
[SD2] Moni Naor Naor, M. and Benny B. Pinkas, Efficient "Efficient Trace and Revoke
Schemes, In
Schemes", Proceedings of Financial Cryptography 2000,
Anguilla, British West Indies, February 2000.
[Self-Healing] Staddon, J., et. al., Self-healing "Self-healing Key Distribution
with Revocation, In proceedings of the Revocation", Proc. 2002 IEEE Symposium on
Security and Privacy, Oakland, CA, May 2002.
Baugher, et al. Informational [Page 35]
RFC 4046 MSEC Group Key Management Architecture April 2005
[SKEME] H. Krawczyk, SKEME: "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet, Internet", ISOC Secure Networks and
Distributed Systems Symposium, San Diego, 1996.
[STS] Diffie, P. van Oorschot, M. M., and J. Wiener, Authentication
"Authentication and Authenticated Key Exchanges, Exchanges",
Designs, Codes and Cryptography, 2, 107-125 (1992),
Kluwer Academic Publishers.
[TAXONOMY] R. Canetti et al, Multicast Canetti, R., et. al., "Multicast Security: A taxonomy Taxonomy
and some Efficient Constructions, Constructions", IEEE INFOCOM,
1999.
[TESLA-INFO] Perrig, A., R. Canetti, D. R., Song, D. D., Tygar, D., and B.
Briscoe, TESLA: "TESLA: Multicast Source Authentication
Transform
Introduction, http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-
msec-tesla-intro-01.txt, October 2002, Introduction", Work in Progress. Progress, December
2004.
[TESLA-SPEC] Perrig, A., R. Canetti, and Whillock, TESLA: "TESLA:
Multicast Source Authentication Transform Specification,
http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-msec-tesla-spec-
00.txt, April 2002,
Specification", Work in Progress. Progress, April 2002.
[tGSAKMP] Harney, H., et. al., Tunneled "Tunneled Group Secure
Association Key Management Protocol, http://www.ietf.org/internet-drafts/draft-ietf-
msec-tgsakmp-00.txt, May 2003, Protocol", Work in Progress.
Progress, May 2003.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0," RFC 2246, January 1999.
[TPM] D.S. Marks, B.H. D. and B. Turnbull, Technical "Technical protection
measures: The
intersection Intersection of technology, law, Technology, Law, and commercial licenses,
Commercial Licenses", Workshop on Implementation
Issues of the WIPO Copyright Treaty (WCT) and the
WIPO Performances and Phonograms Treaty (WPPT), World
Intellectual Property Organization, Geneva, December
6 and 7, 1999
(http://www.wipo.org/eng/meetings/1999/wct_wppt/pdf/imp99_3.pdf).
Internet Draft Group Key Management Architecture [PAGE 34]
Baugher, Canetti, Dondeti, Lindholm June 2004 1999.
[Wool] Wool. Wool, A., Key "Key Management for Encrypted broadcast, broadcast",
5th ACM Conference on Computer and Communications
Security, San Francisco, CA, Nov. 1998.
Internet Draft
Baugher, et al. Informational [Page 36]
RFC 4046 MSEC Group Key Management Architecture [PAGE 35]
Baugher, Canetti, Dondeti, Lindholm June 2004
11.0 April 2005
Authors' Addresses
Mark Baugher
Cisco Systems
5510 SW Orchid St.
Portland, OR 97219, USA
Phone: +1 408-853-4418
EMail: mbaugher@cisco.com
Ran Canetti
IBM Research
30 Saw Mill River Road
Hawthorne, NY 10532, USA
Phone: +1 914-784-7076
EMail: canetti@watson.ibm.com
Lakshminath R. Dondeti
Nortel Networks
600 Technology Park
Qualcomm
5775 Morehouse Drive
Billerica, MA 01821, USA
San Diego, CA 92121
Phone: +1 978-288-6406
ldondeti@nortelnetworks.com 858 845 1267
EMail: ldondeti@qualcomm.com
Fredrik Lindholm
Ericsson Research
SE-16480 Stockholm, Sweden
Phone: +46 8 58531705
EMail: fredrik.lindholm@ericsson.com
Baugher, et al. Informational [Page 37]
RFC 4046 MSEC Group Key Management Architecture April 2005
Full Copyright Statement
Copyright (C) The Internet Society (2004). (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
Internet Draft Group Key Management Architecture [PAGE 36]
Baugher, Canetti, Dondeti, Lindholm June 2004
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Additional Acknowledgements
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Internet Draft Group Key Management Architecture [PAGE 37]
Baugher, Canetti, Dondeti, Lindholm June 2004
Internet Draft Group Key Management Architecture [PAGE et al. Informational [Page 38]
----