WDIFF

draft-ietf-msec-gkmarch-00.txt --> draft-ietf-msec-gkmarch-01.txt

Internet Engineering Task Force Mark Baugher (Cisco)
INTERNET-DRAFT Ran Canetti (IBM)
Lakshminath Dondeti (Nortel)

June

October 23, 2001

Group Key Management Architecture
<draft-ietf-msec-gkmarch-00.txt>
<draft-ietf-msec-gkmarch-01.txt>

Status of 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 the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet Drafts.

Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.

Abstract

This document presents a group key-management architecture for MSEC.
The purpose of this document is to define the common architecture for
MSEC group key-management protocols that support a variety of
application, transport, and internetwork security protocols. To
address these diverse uses, MSEC may need to standardize two or more
group key management protocols that have common requirements,
abstractions, overall design, and messages. The framework and
guidelines in this document allow for a modular and flexible design
of group key management protocols for a variety different settings
that are specialized to application needs.

Comments on this document should be sent to msec@securemulticast.org.

Table of Contents

1.0 Introduction: Purpose of this Document....................3 Document 3
2.0 Requirements for a group key management protocol..........3 protocol 3
3.0 Overall Design............................................5 Design 5
3.1 Overview..............................................6 Overview 5
3.2 Detailed description..................................7 description 7
3.3 Properties of the design..............................9 design 9
3.4 Implementation Diagram...............................10 Diagram 9
4.0 Group Security Association...............................11 Association 11
4.1 Pre-distributed group policy.........................12 Group policy 11
4.2 Contents of the Re-key SA............................12 SA 12
4.3 Contents of the Data Security SA.....................14 SA 14
5.0 Scalability Considerations...............................15 Considerations 15
6.0 Security Considerations..................................17 Considerations 17
7.0 References and Bibliography..............................18 Bibliography 18
8.0 Authors' Addresses.......................................21 Addresses 20
Appendix: MSEC Security Documents Roadmap....................22

Baugher, Canetti, Dondeti [Page 2]
Internet Draft Group Key Management Architecture June 2001 Roadmap 22

1.0 Introduction: Purpose of this Document

Group and multicast applications have diverse requirements in IP
networks [CP00]. Their key-management requirements, which are
briefly reviewed below (see "Requirements"), include support for
internetwork, transport, and application-layer protocols. In
particular, while Internet-standard ISAKMP and IKE protocols purport
to manage keys for any and all services in a host, some applications
may achieve simpler operation by running key-management messaging
over TLS or IPsec security services. For these reasons, application,
transport, and internetwork-layer security protocols such as SRTP,
IPsec, and AMESP may benefit from using different group key
management systems. Some security protocols will benefit from a key
management protocol that can run over IPsec or TLS [GSAKMP]. Other
security protocols may run over SIP or RTSP [KMMS]. Extensions to IKE, however, are probably IKE
may be the best solution for running IPsec protocols over IP
multicast services [GDOI]. The purpose of this document is to define
a common architecture and design for these different group key-management protocols. key-
management protocols for internet, transport, and application
services.

Indeed, key-management protocols are difficult to design and
validate. The common architecture described in this document eases
this burden by defining common abstractions and overall design that
can be specialize specialized for different uses.

This document builds on and extends the Group Key Management Building
Block document of the IRTF SMuG research group [HBH01]. [HBH01] and is part of
the MSEC document roadmap. To correctly place the current document in
the context of the MSEC literature we include a copy of the MSEC
draft tree in the appendix.

Section 2 discusses the security, performance and architectural
requirements for a group key management protocol. Section 3 presents
the overall architectural design. Section 4 outlines specifies the structure of interface
to the Group Security Association (GSA). (GSA) using the standard keywords
of RFC 2119. Section 5 discusses scalability issues and Section 6
discusses Security Considerations.
2.0 Requirements for a group key management protocol

A group key management protocol supports multicast applications that
need a secure group. A "secure group" is a collection of principals,
called "members," who may be senders, receivers or both receivers and
senders to other members of the group. (Note that group membership
may vary over time.) A "group key management protocol" ensures helps to
ensure that only members of a secure group 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.

Multicast applications, such as video broadcast and multicast file
transfer, have the following key-management requirements (see also
[CP00]).

Baugher, Canetti, Dondeti [Page 3]
Internet Draft Group Key Management Architecture June 2001

1. The group members must receive "security associations" including
encryption keys, authentication/integrity keys, metadata
describing cryptographic
policy that describes the keys (also called "policy") keys, and attributes such as
an index for referencing the security association.
2. Keys will have a predetermined lifetime and will be periodically
refreshed.
3. Key material must be delivered securely to members of the
group so that they are secret and authenticated to group members
during the key lifetime and refreshed securely at the end of
the key lifetime.
4. The key-management protocol must be secure against man-in-the-
middle, connection-hijacking, and reflection/replay attacks; it
must use best-known practices to thwart denial-of-service attacks. attacks
(see Security Considerations section of this memo).
5. It must be possible to add and remove group members so that
members who are added may optionally be denied access to the key
material used before they joined the group, and that members who
are removed lose access to the key material following their
departure.
6. It must be possible to provide re-key for the group without
requiring unicast exchange between a key distribution center (KDC) group controller/key server
(GCKS) and individual members, which would overwhelm a KDC GCKS when
the group is large.
7. The key management protocol must be suitable for IPsec security
protocols, AH and ESP, and/or application-layer security protocols
such as AMESP and SRTP.
8. The key management protocol should allow keys and algorithms to be
renewed and the trust authorization infrastructure and authentication
systems to be replaced.

Although it is not a requirement for a multicast security protocol,
the group key management protocol may also be useful to unicast
applications that share many of the requirements of multicast
applications, such as for Internet entertainment applications that
exhibit a high degree of synchronization among receivers. For
example, consider a video on demand application scenario where the
top 10 movie movies are offered. On a Friday night, a large population of
users is likely to request any one of the small set of movies (files
or streams) and place great demand on the KDC GCKS for keys to the pre-encrypted pre-
encrypted data. If asymmetric cryptography is used to establish
security associations as is done in TLS or IKE, the KDC GCKS will
probably not be able to exceed 20-
60 20-60 key management sessions per
second (on a 500 MHz Pentium-class server with RSA, DSS, or EC-DSS
keys ranging from about 160 to 1024 bits in length). If the video-on-demand video-
on-demand community of users is modeled as a group, however, then a
key management implementation that supports requirement 6, above,
will satisfy the requirements of the VOD application as well.

There are other requirements for small group operation where there wil
will be many senders or in which all members may potentially be
senders. In this case, the group setup time may need to be optimized
to support a small, highly interactive group environment [RFC2627].
A centralized

Baugher, Canetti, Dondeti [Page 4]
Internet Draft Group Key Management Architecture June 2001 single group controller (or KDC) that is used in this architecture GCKS) may not be the best design for
small, interactive groups. But for large, single-
source single-source multicast
groups, it is generally undesirable to distribute key management
functions among group members: Unlike small, interactive groups,
large single-source multicast groups generally need a specialized KDC
GCKS to support large numbers of group members. Large distributed
simulations, moreover, may combine the need for large-grou large-group operation
with many senders.

We take as a basic requirement the support of large single-sender
groups, such as source-specific (single-source) multicast groups.
Thus, group key management should support high-capacity operation to
large groups that have one or very few senders. Nonetheless,
scalable operation to a range of group sizes is a desirable feature,
and a better group key management protocol will support large,
single-sender groups as well as groups that have many senders. It may
be that no single key management protocol can satisfy the scalability
requirements of all group-security applications. This In this case, this
architecture allows two or more key management protocols, where each
protocol is for further study. suitable to a different scenario such large single-source
groups or small interactive groups.

In addition to these requirements, it is useful to emphasize two non-
requirements, namely, technical protection measures (TPM) and broadcas
broadcast key management. TPM are used for such things as copy
protection by preventing the user of a device to get easy access to
the group keys. Although we should expect that a device under the
control of an attacker would lose its secrets to that attacker, some
TPM advocates see tamper-resistant technologies as a means to keep
honest people honest [MT] and want TPM for that purpose. There is no
reason why a group key management protocol cannot be used in an
environment where the keys are kept in a "tamper-resistant" store
using various types of hardware or software to implement TPM. The
group key management architecture described in this document,
however, is for key management protocols and not a design for
technical protection measures, which are outside the scope of this
document.

The second non-requirement is broadcast key management where there is
no back channel [FN93, JKKV94] or the device is not on a network,
such as DVD CSS [Stevenson]. a digital videodisk player. We assume IP network operation
where there is two-way communication, however asymmetric, and that
authenticated key-
exchange key-exchange procedures can be used for member
registration. It is possible that broadcast applications can make
use of an a one-way Internet group key management protocol message that is one-way, message, and
a one-way Re-key message is described below.
3.0 Overall Design

This section describes the overall structure of a group key
management protocol, and provides a reference implementation diagram
for group key management. This design is based upon a "group
controller" model [RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with
a single group owner as the root-of-trust. The group owner
designates a key
distribution center group controller for member registration and re-key.

Baugher, Canetti, Dondeti [Page 5]
Internet Draft Group Key Management Architecture June 2001
3.1 Overview

The main goal of a group key management protocol is to 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 Security Protocol
SA", or "Data SA" for short. In order to obtain this goal, the Group
Key Management Architecture consists of the following protocols.

(1) Registration protocol.
=====================
This is a two-way unicast protocol between the key distribution
center (KDC) group controller/key
server (GCKS) and a joining group member. In this protocol the KDC GCKS
and joining member mutually authenticate each other. If the
authentication succeeds and the KDC GCKS finds that the joining member is
authorized, then the KDC GCKS supplies the joining member with the
following information:

(a) Sufficient information to initialize a "Re-key Protocol SA"
within the joining member (see more details about this SA below).
This information is given only in case that the group security policy
calls for using a Re-key protocol.
(b) Sufficient information to initialize the Data Security
Protocol SA within the joining member. This information is given only
when
in the case that the group security policy calls for initializing the
Data Security Protocol SA at Registration, instead of or in addition
to at Re-key.

The Registration Protocol must ensure that the transfer of
information from KDC GCKS to member is done in a an authenticated and
confidential manner over a security association. We call this SA the
"Registration Protocol SA".

(2) Re-key protocol.
================
This is an optional protocol where the KDC GCKS periodically sends re-key re-
key information to the group members. Re-key messages may result from
group membership changes changes, the creation of new traffic-encrypting keys
(TEKs, see next section) for the particular Group, or from key
expiration. Re-key messages are protected by the Re-key protocol SA,
which is initialized in the Registration protocol. The Re-key message
includes information for updating both the Re-key protocol SA and/or
the Data Security Protocol SA. The Re-key messages can be sent
multicast to group members or unicast from the KDC GCKS to a particular
group member.

The Re-key protocol is optional as there are other means for managing
(e.g. expiring or refreshing) the keys locally without interaction
between the KDC GCKS and member [MARKS]. When Re-key is used, it MUST
include authentication data for the re-key. There are two cases.

o The first and primary option is to use source authentication.
That is, each group member MUST verify that Re-key data
originates with the GCKS and none other.

Baugher, Canetti, Dondeti [Page 6]
Internet Draft Group Key Management Architecture June 2001

o The second option is to use only group-based authentication using
a symmetric key, such as a message authentication code. Members
can only be assured that the Re-key messages originated within
the group. Therefore, this is applicable only when all members
of the group are trusted not to impersonate the KDC. GCKS. Group
authentication for Re-key messages is typically used when public-
key cryptography is not suitable for the particular group.

The Re-key protocol SHOULD ensure that all members receive the re-key
information in a timely manner. In addition, the Re-key protocol
SHOULD specify mechanisms for the parties to contact the KDC GCKS and
"re-synch" in case that their keys expired and an updated key has not
yet been received. The Re-key protocol must be able to avoid
implosion problems and ensure the needed reliability in its delivery
of keying material.

3.2

The Re-key message is protected by a Re-key SA, which may be
established by the Registration Protocol. The Re-key SA, one or more
Data SAs, and the Registration SA SHOULD be destroyed by a member who
leaves the particular Group to which these SAs belong. Alternatively,
a member MAY allow the SAs to expire. A particular group key
management protocol MAY provide a De-Registration message to inform
the GCKS that it has destroyed it SAs, or is about to destroy them.
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 cause
implosion at the GCKS. A De-registration message is not specified in
this document.
3.2 Detailed description

Figure 1 depicts the overall design [HBH01]. Each group member,
sender or receiver, uses MAY use the Registration Protocol to get
authorized, authenticated access to a particular Group, its policies,
and its keys. The two types of group keys are the KEK (key-encrypting
key) and the TEK (traffic-encrypting key). The KEK may be a single
key that encrypts the TEK or it may be a vector of keys in a membership
management key
revocation algorithm [RFC2627, OFT, CP00] CP00, LNN01] that encrypts the
TEK and other KEKs. The KEK is used by the Re-key protocol. The TEK
is used by the Data Security Protocol to protect streams, files, or
other data sent and received by the Data Security Protocol. The Thus the
Registration Protocol and/or the Re-key Protocol establish the KEK
and TEK.
There are a few, distinct outcomes to a successful Registration
Protocol exchange.
o If the KDC GCKS uses Re-key messages, then the admitted member
receives the Group KEK; if it uses a membership management key revocation
algorithm, then the member receives a set of KEKs according to
the particular algorithm.
o If Re-key messages are not used for the Group, then the
admitted member will receive TEKs (in SAs) that are passed to
the member's Data Security Protocol as IKE does for IPsec.
o The KDC GCKS may pass one or more TEKS to the member even if Re-key Re-
key messages are used, for efficiency reasons according to
group policy.

Baugher, Canetti, Dondeti [Page 7]
Internet Draft Group Key Management Architecture June 2001

+------------------------------------------------------------------+
| +-----------------+ +-----------------+ |
| | POLICY | | TRUST AUTHORIZATION | |
| | INFRASTRUCTURE | | INFRASTRUCTURE | |
| +-----------------+ +-----------------+ |
| ^ ^ |
| | | |
| v v |
| +--------------------------------------------------------------+ |
| | | |
| | +--------------------+ | |
| | +------>| KDC GCKS |<------+ | |
| | | +--------------------+ | | |
| | | | | | |
| | REGISTRATION | REGISTRATION | |
| | PROTOCOL | PROTOCOL | |
| | | | | | |
| | v RE-KEY v | |
| | +-----------------+ PROTOCOL +-----------------+ | |
| | | | | (OPTIONAL) | | | |
| | | SENDER(S) |<-------+-------->| RECEIVER(S) | | |
| | | | | | | |
| | +-----------------+ +-----------------+ | |
| | | ^ | |
| | v | | |
| | +-------DATA SECURITY PROTOCOL-------+ | |
| | | |
| +--------------------------------------------------------------+ |
| |
+------------------------------------------------------------------+
FIGURE 1: Group Security Association Model

The KDC GCKS creates the KEK and TEKs and downloads them to each member -
as the KEK and TEKs are common to the entire Group. The KDC GCKS is a
separate, logical entity that performs member authentication and
authorization according to the Group policy that is set by the Group
Owner. The KDC presents GCKS MAY present a credential to the Group member that is
signed by the Group Owner so the member can check the KDC's GCKS's
authorization. The KDC, GCKS, which may be co-located with a member or be
a separate physical entity, runs MAY run the Re-key Protocol to push Re-key Re-
key messages of refreshed KEKs, new TEKs, and refreshed TEKs to
members. Alternatively, the sender may forward Re-key messages on
behalf of the
KDC GCKS when it uses a credential mechanism that supports
delegation. Thus, it is possible for the sender or other member may to
source keying material (a TEK encrypted in the Group KEK) as it
sources multicast or unicast data. As mentioned above, the Re-key
message can be sent using unicast or multicast delivery. Upon
receipt of a TEK from a Re-key Message or a Registration protocol
exchange, the member's group key management will provide a security
association (SA) to a Data Security Protocol for the data sent from
sender to receiver.

Baugher, Canetti, Dondeti [Page 8]
Internet Draft Group Key Management Architecture June 2001

The "Security Protocol SA" protects the data sent on the arc labeled
"DATA SECURITY PROTOCOL" in Figure 1. A second SA, the "Re-key
SA," is optionally established by the key-management protocol for Re-
key messages, and the arc labeled "RE-KEY PROTOCOL" in Figure 1
depicts this. The Re-key message is optional because all keys, KEK
and TEKs, can be delivered by the Registration Protocol exchanges
shown in Figure 1. 1, and those keys may not need to be updated. The
Registration Protocol is protected by a third, symmetric, unicast SA
between the KDC GCKS and each member; this is called the "Registration
Protocol SA." There may be no need for the Registration Protocol SA
to remain in place after the completion of the Registration Protocol
exchanges. The three SAs comprise the Group Security Association.
Only one SA is optional and that is the Re-key SA.

Figure 1 shows two blocks that are external to the group key
management protocol: The Policy and Trust Authorization Infrastructures
are discussed in Section 4.1.
3.3 Properties of the design

The above design of Section 3.2 achieves scalable operation by (1) allowing
the de-
coupling de-coupling of authenticated key exchange in a "Registration
Protocol" from a "Re-key Protocol," (2) allowing the Re-key Protocol
to use unicast push or multicast distribution of group and data keys
as an option, and (3) allowing all keys to be obtained by the unicast
Registration Protocol. The KDC, GCKS functionality, moreover, can be
delegated when the
trust authorization infrastructure supports delegation
to permit distributed operation of the KDC. GCKS.

High-capacity operation is obtained by (1) amortizing computationally-
expensive
computationally-expensive asymmetric cryptography over multiple data
keys used by a data security protocol, protocols, (2) supporting unicast push or
multicast distribution of symmetric group and data keys, and (3)
supporting
membership management key revocation algorithms such as LKH [RFC2627, OFT]. OFT,
LNN01] that allow members to be added or removed at logarithmic
rather than linear space/time complexity. The Registration protocol
often uses 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: A TEK SA can be
established without the use of asymmetric cryptography - the TEK is
simply encrypted in the symmetric KEK and sent unicast or multicast
in the Re-key protocol.

The design of the Registration and Re-key Protocols is flexible. The
Registration protocol establishes one KEK or multiple TEKs or both
KEK and TEKs. The TEK (or "data key") is associated with a data
security protocol SA; there may in fact be multiple keys pushed with
or derived from the TEK. The Re-key Protocol establishes KEKs or
TEKs or both. The
complexity of the various options can be reduced by an instantiation of
the group key management architecture that disallows or restricts the
options described here.

Baugher, Canetti, Dondeti [Page 9]
Internet Draft Group Key Management Architecture June 2001
3.4 Implementation Diagram

In the block diagram of Figure 2, group key management protocols run
between a KDC GCKS and member principals to establish a Group Security
Association (GSA) consisting of a Security Protocol SA, an optional Re-
key
Re-key SA, and a Registration Protocol SA. The KDC may GCKS MAY use a
delegated principal, such as an SRTP [SRTP] sender, which has a
delegation credential signed by the KDC. GCKS. The "Member" of Figure 2
may be a sender or receiver of multicast or unicast data [HCBD].
There are two functional blocks in Figure 2 labeled "GKM," and there
are two arcs between them depicting the group key-management
Registration ("reg") and Re-key ("rek") protocols. The message
exchanges are the GSA establishment protocols, which are the
Registration Protocol and the Re-key Protocol described above.

+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| |AUTHORIZATION| |ANNOUNCEMENT| |
| +------^------+ +------|-----+ +--------+ |
| | | +-----| CERTS CRED | |
| | | | +--------+ |
| +----v----+ +----v--v-+ +--------+ |
| | <-----Reg-----> |<->| SAD | |
| | GKM -----Rek-----> GKM | +--------+ |
| | | | | +--------+ |
| | ------+ | |<->| SPD | |
| +---------+ | +-^-------+ +--------+ |
| +--------+ | | | | |
| | CERTS CRED |----->+ | | +-------------------+ |
| +--------+ | | +--------------------+ | |
| +--------+ | +-V-------+ +--------+ | | |
| | SAD <----->+ | |<->| SAD <-+ | |
| +--------+ | |SECURITY | +--------+ | |
| +--------+ | |PROTOCOL | +--------+ | |
| | SPD <----->+ | |<->| SPD <----+ |
| +--------+ +---------+ +--------+ |
| |
| (A) KDC GCKS (B) MEMBER |
+----------------------------------------------------------+
Figure 2: Group key management block diagram for a host computer

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
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,
"CERTS" "CRED" in Figure 2. AUTHORIZATION is
subject to Group Policy [HH], but how this is done is specific to the KDC
GCKS implementation.

Baugher, Canetti, Dondeti [Page 10]
Internet Draft Group Key Management Architecture June 2001

Beside the AUTHORIZATION block in Figure 2, there is an ANNOUNCEMENT
block. The announcement function is needed to inform a potential
group member that it may join a group or upcoming receive group sessions data (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 sessions. 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 tool, an electronic program guide, guide (EPG), or by
other means. The Data Security or the announcement function directs GDOI
group key management using an application-programming interface
(API), which is peculiar to the host OS in its specifics. A generic
API for group key management is for further study, but this function
is necessary to allow Group (KEK) and Session Data (TEK) key establishment to
be done in a way that is scalable to the particular application. A KDC
GCKS application program will use the API to initiate the procedures
to establish SAs on behalf of a Security Protocol in which members
join secure groups and receive keys for streams, files or other data.

The goal of the exchanges is to establish a GSA through updates to
the SAD of a key-management implementation and a particular Security
Protocol. The "Security Protocol" of Figure 2 may span internetwork
and application layers [AMESP] or operate at the internetwork layer,
such as AH and ESP.
4.0 Group Security Association

The GKM Architecture defines the interfaces between the Registration,
Re-key, and Data Security protocols in terms of the Security
Associations (SAs) of those protocols. By isolating these protocols
behind a uniform interface, our architecture allows implementations
to use protocols best suited to their needs. For example, a Re-key
protocol for a small group could use multiple unicast transmissions
with symmetric authentication, while that for a large group could use
IP Multicast with packet-level Forward Error Correction and source
authentication.

The Group Key Management Architecture provides an interface between
the security protocols and the group SA (GSA), which consists of
three SAs SAs, viz., Registration SA, Re-key SA and Data Security SA. The Re-key
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 key management is done WITHOUT using a Re-key SA.
The Registration protocol initializes and updates one or more Data
Security
SAs (having TEKs to protect files or streams). Each Data
Security SA
corresponds to a single group. group � and a group may have more than one
data SA.

In Case 2, group key management USES a Re-key SA to protect the Re-key

Baugher, Canetti, Dondeti [Page 11]
Internet Draft Group Key Management Architecture June 2001 Re-
key protocol. The Registration protocol initializes the Re-key SAs
(one or more) as well as zero or more Data Security SAs upon successful
completion. When a Data Security SA is not initialized in the Registration
protocol, this is MUST be done in the Re-key protocol. The Re-key
protocol is responsible for updates to Re-key SA(s) AND updates as
well as initialization of establishes Data Security SA(s).
4.1 Pre-distributed group Group policy

Group-policy is currently being defined [GSPT]. It will likely be
distributed through both Announcement and Key Management protocols.
The group key management MUST carry cryptographic policies of the SA
keys it establishes and MAY carry additional policies for the group
as well.

The acceptable cryptographic policies for the Registration Protocol,
which may run over TLS, IPsec, or IKE, are not conveyed in the group
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 key-management session
establishment to determine what the initial cryptographic policies
are for that establishment. This document assumes the existence of
such a repository and protocol for KDC GCKS and member policy queries.
Thus group security policy will be represented in a policy repository
and accessible using a policy protocol.

MSEC

This memo assumes that at least the following group-policy
information is
externally managed.
o Group owner, authentication method, and delegation method for
identifying a KDC GCKS for the group
o Group KDC, GCKS, authentication method, and any method used for
delegating other KDCs GCKSs for the group
o Group membership rules or list and authentication method

There are also two additional policy-related requirements external to
group key management.

o There is an authorization and authentication infrastructure such
as X.509, SPKI, or pre-shared key scheme in accordance with the
group policy for a particular group.
o There is an announcement mechanism for secure groups and events
that operates according to group policy for a particular group.

Group policy determines how the Registration and Re-key protocols
initialize or update Re-key and Data Security SAs. The following sections
describe the information that are sent by the KDC GCKS for the Re-
key Re-key and
Data Security SAs. A member needs to have the information specified in the
next sections to establish Re-key and Data Security SAs.
4.2 Contents of the Re-key SA

The Re-key SA protects the Re-key protocol. It contains
cryptographic policy, Security Parameter Index (SPI) [RFC2401] to
uniquely identify an SA, replay protection information, and secret
keys.

Baugher, Canetti, Dondeti [Page 12]
Internet Draft Group Key Management Architecture June 2001

4.2.1 Re-key SA policy

The KEY MEMBERSHIP MANAGEMENT ALGORITHM represents the group key management
revocation algorithm that enforces forward and backward access
control. Examples of key management revocation algorithms include LKH, LKH+,
OFT, and OFC and Subset Difference [RFC2627, OFT, CP00]. CP00, LNN01]. The key management
revocation algorithm could also be NULL. In that case, the Re-key SA
contains only one KEK, which serves as the group KEK. The Re-key
messages initialize or update Data Security SAs as usual. But, the Re-key SA
itself can be updated (group KEK can be re-
keyed) re-keyed) when members join
or the KEK is about to expire. Leave re-
keying re-keying is done by re-initializing re-
initializing the Re-key SA through the Re-key Protocol.

The KEK ENCRYPTION ALGORITHM uses MUST use a standard encryption algorithm
such as 3DES or AES. The KEK KEY LENGTH must MUST also be specified.

The AUTHENTICATION ALGORITHM should SHOULD use digital signatures for KDC GCKS
authentication (since all shared secrets are known to some or all
members of the group), or it may MAY use a symmetric secret in computing
MACs for group authentication. authentication, which provides weaker authentication
meaning that any group member can impersonate a particular source.
The AUTHENTICATION KEY LENGTH must MUST also be specified.

The CONTROL GROUP ADDRESS is MUST be used for multicast transmission of
Re-key messages. This may MAY be sent via the ANNOUNCEMENT protocol.
However, the Group Owner may MAY decide to send this information only to
authorized members.

The REKEY SERVER ADDRESS allows the registration server to be a
different entity from the server used for re-key, such as for future
invocations of the Registration and Re-key protocols. If the
registration server and the re-key server are two different entities,
the registration server needs to MUST send the re-key server's address as part
of the Re-key SA.

4.2.2 Group identity

The Group identity may need to MUST accompany 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 or multiple groups to be updated in a single Re-
key
Re-key message. While it may MAY be much simpler to restrict each
Registration invocation to a single group, this Group Key Management
architecture mandates no such restriction. There is always a need to
identify the group when establishing a Re-key SA either implicitly
through an SPI or explicitly as an SA parameter.

4.2.3 Key encrypting key(s)

Corresponding to the key management algorithm, the Re-key SA contains
one or more KEKs. The KDC GCKS holds the key encrypting keys of the
group, while the members receive keys following the specification of
the key-

Baugher, Canetti, Dondeti [Page 13]
Internet Draft Group Key Management Architecture June 2001

management key-management algorithm. When there are multiple KEKs for a
group (as in an LKH tree), each KEK is MAY be associated with a Key ID,
which may MAY be used to identify the key needed to decrypt it. Each KEK also has
MUST have a LIFETIME associated with it, after which the KEK expires.

4.2.4 Authentication key

The KDC may GCKS MAY provide a symmetric or public key for authentication of
its Re-key messages. Symmetric-key authentication is appropriate
only when all group members can be trusted not to impersonate the KDC.
GCKS. The architecture does not rule out methods for deriving
symmetric authentication keys at the member [RFC2409] rather than
being pushed from the KDC. GCKS.

4.2.5 Replay protection information

Re-key messages need to MUST be protected from replay/reflection attacks.
Sequence numbers are used for this purpose and the Re-key SA (or
protocol) contains this information.

4.2.6 Security Parameter Index (SPI)

The triple (Group identity, SPI, an identifier for "Re-key SA")
uniquely identifies an SA. The SPI changes each time the KEKs
change.
4.3 Contents of the Data Security SA

The KDC 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, SRTP, MESP, and AMESP.
While the content of each of these protocols is out of the scope of
this document, we list the information sent by the Registration
protocol (or the Re-key Protocol) to initialize or update the Data
Security
SA.

4.3.1 Group identity

The Group identity must MUST accompany SA information when Data Security SAs are
initialized or re-keyed for multiple groups in a single invocation of
the Registration protocol or in a single Re-key message (see 4.2.2).
Otherwise, there is also a need for some means to identify the group in
a protocol that establishes a Data Security SA either implicitly
through an SPI or explicitly as an SA parameter. a single Re-key message (see 4.2.2).

4.3.2 Source identity

The Group Owner may MAY choose to reveal Source identity to authorized
members only. Alternatively, it may MAY choose the ANNOUNCEMENT protocol
to list the Source(s) corresponding to the Source identities.

Baugher, Canetti, Dondeti [Page 14]
Internet Draft Group Key Management Architecture June 2001 Thus
an SA MAY include source-identity information.

4.3.3 Traffic encrypting key

Irrespective of the Data Security Protocol used, the KDC GCKS supplies
the TEKs (or information to derive TEKs) used in secure data
transmission, source and group authentication.

4.3.4 Authentication key

Depending on the data-authentication method used by the Data Security
protocol, group key management may pass one or more keys, functions, functions
(e.g., TESLA), or other parameters used for authenticating streams or
files.

4.3.5 Sequence numbers

The KDC could GCKS MAY initialize and pass sequence numbers used by the Data
Security protocol, for replay protection.

4.3.6 Security Parameter Index (SPI)

In the event that a Data Security protocol uses an SPI, the KDC will GCKS MUST
send that information as part of the Data Security SA contents.

4.3.7 Data Security SA policy

The Data Security SA parameters are specific to the Data Security Protocol but will usually
SHOULD include encryption algorithm and parameters, the source
authentication algorithm and parameters, the group authentication
algorithm and parameters, and and/or replay protection information.
Generally, specification of source or group authentication is
mutually exclusive.
5.0 Scalability Considerations

Group communications is quite diverse. In commercial
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 [RFC 1889] has no central controller but is
fully distributed and end-to-end. Teleconferencing sessions tend to
have at most dozens of participants whereas video broadcast, which
uses multicast communications, and media on demand, which uses
unicast, are large-
scale large-scale groups numbering hundreds to millions of
participants.

As described in the Requirements section above, group key management
must support source-specific multicast, first and foremost. One-to-
many multicast. One-to-many (single-sender)
applications are well suited to source-specific multicast, which tend
to have large numbers of participants and problems with
synchronization among the participants. "Flash crowds" are one
manifestation of the problem with synchronized participants who make
concurrent request for group data with concomitant requests for
secure group keys. Thus, a group key management protocol designed
for single-source multicast

Baugher, Canetti, Dondeti [Page 15]
Internet Draft Group Key Management Architecture June 2001 applications must support large-scale
operation. The architecture described in this paper supports large-scale large-
scale operation through the following features.

1. No There is no need for a unicast exchange is needed to provide data keys to a
security protocol for members who have previously-registered in the
particular group; data security keys can be pushed in the Re-key protocol.

2. The Registration and Re-key protocols are separable to allow
flexibility in how members get group secrets. A group can use a smart-
card
smart-card based system in place of the Registration protocol, for
example, to allow the Re-key protocol to be used with no back channel
for broadcast applications such as television conditional access
systems.

3. The Registration and Re-key protocols should support new keys,
algorithms, trust authorization infrastructures and authentication
mechanisms in the architecture. When the trust authorization
infrastructure supports delegation, as does X.509 and SPKI, the KDC GCKS
function can be distributed as shown in Figure 3.

+----------------------------------------+
| +-------+ |
| | KDC GCKS | |
| +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| +-------------+ |
| | | |
| v ... v |
| +-------+ +-------+ |
| | KDC GCKS | | KDC GCKS | |
| +-------+ +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| ... |
+----------------------------------------+
Figure 3: Hierarchically-organized Key Distribution

Baugher, Canetti, Dondeti [Page 16]
Internet Draft Group Key Management Architecture June 2001

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 recourse
for handling member registration in the context of a "flash crowd" is
Figure 3, which will require the use of many KDCs GCKSs to accommodate the
load. The Figure 3 configuration may be needed when conventional
clustering and load-balancing solutions of a central KDC 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 KDC.
GCKS.

More analysis and work needs to be done on the protocol
instantiations of the Group Key Management architecture to determine
how effectively and securely the architecture can operate in large-scale large-
scale environments such as source-specific multicast and video on
demand. Specifically, the requirements for a Figure 3 configuration
must be determined such as the need for additional protocols between
the KDC GCKS designated by the Group Owner and KDCs GCKSs that have been
delegated to serve keys on behalf of the designated KDC. GCKS.

6.0 Security Considerations

This memo describes an architecture for group key management. 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 or reflection of past messages, and
denial of service attacks.

Authenticated key exchange [STS, SKEME, RFC2408, RFC2412, RFC2409]
techniques limit the effects of man-in-the-middle and 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 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 secrets may be disclosed
by a member of the group and group senders may be impersonated by
other members of the group. Key management messages from the KDC GCKS
should not be authenticated using shared symmetric secrets unless all
members of the group can be trusted not to impersonate the KDC. GCKS.
Similarly, members who disclose group secrets undermine the security
of the entire group. Group Owners and KDC GCKS administrators must be
aware of these inherent limitations of group key management.

Another limitation of group key management is policy complexity:

Baugher, Canetti, Dondeti [Page 17]
Internet Draft Group Key Management Architecture June 2001
Whereas peer-to-peer security policy is an intersection of the policy
of the individual peers, a Group Owner sets group security policy
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, KDC GCKS operators, and users need to determine minimal
acceptable levels of trust, authenticity and confidentiality when
joining secure groups. Unfortunately, group policy is at a very
early stage of development so little guidance is available to the
technical community at the present time.

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 such as IKE, IPsec, TLS,
or SSL. The particular instantiations of this 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 and testing.

The second protocol, the group key management Re-key protocol, is new
and has unknown risks associated with it. The source-authentication
risks describe above are obviated by the use of public-key
cryptography. The use of multicast delivery, however, is novel and
novelty is a problem for security protocols: Issues with reliable delivery of messages, may raise additional
security issues such as reliability, implosion, and the complexity denial of group
memberships management algorithms that run on service
attacks based upon the Re-key messages need
careful consideration. use of multicast. The Re-key protocol
specification (see Appendix A for the drafts roadmap) needs to offer
secure solutions to these problems. Each instantiation of the Re-key
protocol, such as the GSAKMP Re-key or the GDOI Groupkey-push
operations, need to validate the security of their Re-key
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 standard for security and risks of group key management.

7.0 References and Bibliography

[AMESP] R. Canetti, P. Rohatgi, Pau-Chen Cheng, Multicast Data
Security Transformations: Requirements, Considerations, and Prominent
Choices, http://search.ietf.org/internet-drafts/draft-irtf-smug-data-
transforms.txt, Work In Progress, 2000.

[CP00] R. Canetti, B. Pinkas, A taxonomy of multicast security
issues,
http://www.ietf.org/internet-drafts/draft-irtf-smug-taxonomy-01.txt, http://www.ietf.org/internet-drafts/draft-irtf-smug-taxonomy-
01.txt, Work in Progress, August 2000.

Baugher, Canetti, Dondeti [Page 18]
Internet Draft Group Key Management Architecture June 2001

[FN93]A. Fiat, M. Naor, Broadcast Encryption, Advances in Cryptology
- CRYPTO '93 Proceedings, Lecture Notes in Computer Science, Vol.
773, 1994, pp. 480-491. 480�491.

[FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of
IPsec, CounterPane, http://www.counterpane.com/ipsec.html.

[GDOI] M. Baugher, T. Hardjono, H. Harney, B. Weis, The Group Domain
of Interpretation, http://www.ietf.org/internet-drafts/draft-ietf-msec-
gdoi-00.txt, http://www.ietf.org/internet-drafts/draft-ietf-
msec-gdoi-00.txt, February 2001, Work in Progress.

[GSAKMP] H.Harney, A.Colegrove, E.Harder, U.Meth, R.Fleischer, Group
Secure Association Key Management Protocol,
http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-00.txt,
http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-
00.txt, March 2001, Work in Progress.

[GSPT] T.Hardjono, H.Harney, P.McDaniel, A.Colegrove, P.Dinsmore,
Group Security Policy Token, http://www.ietf.org/internet-
drafts/draft-ietf-msec-gspt-00.txt, Work in Progress, September 2001.

[HBH] H. Harney, M. Baugher, T. Hardjono, GKM Building Block: Group
Security Association (GSA) Definition,
http://www.ietf.org/internet-drafts/draft-irtf-smug-gkmbb-gsadef-
00.txt, Work in Progress 2000.

[HBH01] Group Security Association Management in IP Multicast, T.
Hardjono, M. Baugher, H. Harney, Proceedings of 16th IFIP/SEC
International Conference on Information Security, Paris, France May
2001.

[HCBD] T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore, Secure IP
Multicast: Problem areas, Framework, and Building Blocks,
http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt,
Work in Progress 1999.

[HH] H. Harney, E. Harder, Group Secure Association Key Management
Protocol, http://search.ietf.org/internet-drafts/draft-harney-sparta-
gsakmp-sec-02.txt, June 2000, Work in Progress.

[KMMS] E.Carrara, F.Lindholm, M.Naslund, K.Norman, J.Arko, Key
Management for Multimedia Sessions, draft-carrara-mm-key-mgt-sol-
00.txt, July 2001, Work in Progress

[LNN01] J.Lottspiech, M.Naor, D.Naor, Subset-Difference based Key
Management for Secure Multicast, http://search.ietf.org/internet-
drafts/draft-irtf-smug-subsetdifference-00.txt, Work in Progress,
2001.

[JKKV94] M. Just, E. Kranakis, D. Krizanc, P. van Oorschot, On Key
Distribution via True Broadcasting, On Key Distribution via True
Broadcasting. In Proceedings of 2nd ACM Conference on Computer and
Communications Security, November 1994, pp. 81--88.

[MARKS] B. Briscoe, MARKS: Zero Side Effect Multicast Key Management
using Arbitrarily Revealed Key Sequences, Proceedings of NGC'99,
rbriscoe@bt.co.uk.

[MT] D.S. Marks, B.H. Turnbull, Technical protection measures: The
intersection of technology, law, and 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).

Baugher, Canetti, Dondeti [Page 19]
Internet Draft Group Key Management Architecture June 2001

[NAI] http://www.nai.com/media/pdf/products/tns/6_PGP_VPN_001.pdf

[OFT] D. Balenson, D. McGrew, A. Sherman, Key Management for Large
Dynamic Groups: One-Way Function Trees and Amortized Initialization,
http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft-
00.txt, February 1999, Work in Progress.

[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP:
A Transport Protocol for Real-Time Applications, January 1996.

[RFC2093] Harney, H., and Muckenhirn, C., "Group Key Management
Protocol (GKMP) Specification," RFC 2093, July 1997.

[RFC2094] Harney, H., and Muckenhirn, C., "Group Key Management
Protocol (GKMP) Architecture," RFC 2094, July 1997.

[RFC2327] M. Handley, V. Jacobson, SDP: Session Description Protocol,
April 1998.

[RFC2367] D. McDonald, C. Metz, B. Phan, PF_KEY Key Management API,
Version 2, July 1998.

[RFC2401] S. Kent, R. Atkinson, Security Architecture for the
Internet Protocol, November 1998

[RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload
(ESP), November 1998.

[RFC2407] D. Piper, The Internet IP Domain of Interpretation for
ISAKMP, November 1998.

[RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet
Security Association and Key Management Protocol, November 1998.

[RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE),
November, 1998.

[RFC2412] H. Orman, The OAKLEY Key Determination Protocol, November
1998.

[RFC2522] P. Karn, W. Simpson, Photuris: Session-Key Management
Protocol, March 1999.

[RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for
Multicast: Issues and Architectures, September 1998.

[Schneier] B. Schneier, Applied Cryptography, Second Edition, John
Wiley & Sons, 1996.

Baugher, Canetti, Dondeti [Page 20]
Internet Draft Group Key Management Architecture June 2001

[SKEME] H. Krawczyk, SKEME: A Versatile Secure Key Exchange Mechanism
for Internet, ISOC Secure Networks and Distributed Systems Symposium,
San Diego, 1996.

[STS] Diffie, P. van Oorschot, M. J. Wiener, Authentication and
Authenticated Key Exchanges, Designs, Codes and Cryptography, 2, 107-
125 (1992), Kluwer Academic Publishers.

[SRTP] R.Blom, E.Carrara, D.McGrew, M.Nasland, K.Norrman, D. Oran,
The Secure Real Time Transport Protocol, http://www.ietf.org/internet-
drafts/draft-ietf-avt-srtp-00.txt,
http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-00.txt,
February 2001, Work in Progress.

[Stevenson] F.M. Stevenson, Cryptonalysis of Content Scrambling System,
http:/lemuria.org/DeCSS/crypto.gq.nu, November 8, 1999.

8.0 Authors' Addresses

Mark Baugher
Cisco Systems
5510 SW Orchid St.
Portland, OR 97219
(503) 245-4543

Ran Canetti
IBM Research
30 Saw Mill river River Road
Hawthorne, NY 10532
(914) 784 7076
canetti@watson.ibm.com

Lakshminath R. Dondeti
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821, USA
(978) 288-6406
ldondeti@nortelnetworks.com

Baugher, Canetti, Dondeti [Page 21]
Internet Draft Group Key Management Architecture June 2001

Appendix: MSEC Security Documents Roadmap

+--------------+
| MSEC |
| Requirements |
+--------------+
:
:
+--------------+
| MSEC |
| Architecture |
+--------------+
:
.....................:.......................
: : :
+--------------+ +--------------+ +--------------+
| Policy | | GKM | | Data Security|
| Architecture | | Architecture | | Architecture |
+--------------+ +--------------+ +--------------+
: : :
: : :
. +------------+ : +------------+ :
. | GDOI | : |TESLA/MESP | :
| Resolution |-: | |-:
| | : | | :
+------------+ : +------------+ :
: :
: :
+------------+ : +------------+ :
| GSAKMP- | : | | :
| Resolution |-: | TBD |-:
| | : | | :
+------------+ : +------------+ :
: :
: :
+------------+ : +------------+ :
| | : | | :
| RE-KEY |-: | TBD |-:
| | : | | :
+------------+ : +------------+ :
: :
. .
. .

FIGURE A: Graphic rendition of the inter-relations between the I-D's
of MSEC. Note that some of these drafts are still in the process of
being written.

Internet Draft Group Key Management Architecture [Page 22]

----