view Side-By-Side changes
Internet Draft Mark Baugher (Cisco)
IETF MSEC WG Ran Canetti (IBM)
Expires: December 2003 Mar 2004 Lakshminath Dondeti (Nortel)
Category: Informational Fredrik Lindholm (Ericsson)
June 27,
September 08, 2003
MSEC Group Key Management Architecture
<draft-ietf-msec-gkmarch-05.txt>
<draft-ietf-msec-gkmarch-06.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 work in progress." 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.
http://www.ietf.org/shadow.html
Abstract
This document presents the group key management architecture for
MSEC. The purpose of this document is to define defines the common architecture for MSEC group key-management Multicast Security
(MSEC) key management protocols that support a variety of
application, transport, and internetwork network layer security protocols. To address these diverse uses, MSEC may need to
standardize two or more It
also defines the group SA (GSA), and describes the key management
protocols that have
common requirements, abstractions, overall design, and messages. help establish a GSA. The framework and guidelines
described in this document allow for a modular and flexible design of
group key management protocols for a variety of different settings
that are specialized to application applications needs. MSEC key management
protocols may be used to facilitate secure 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 September 2003
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
1.0 Introduction: Purpose of this Document.........................3
2.0 Requirements for of a group key management protocol...............4 Group Key Management Protocol................4
3.0 Overall Design.................................................6 Design of the Group Key Management Architecture........6
3.1 Overview.....................................................6
3.2 Detailed description.........................................8 Description of the GKM Architecture.................8
3.3 Properties of the design....................................10 Design....................................11
3.4 Implementation Diagram......................................11 Group Key Management Block Diagram..........................11
4.0 Registration Protocol.........................................13
4.1 Registration Protocol Message Exchange......................13 via Piggybacking or Protocol Reuse....13
4.2 Properties of Alternative Registration Exchange Types.......14
4.3 Infrastructure for Alternative Registration Exchange Types..15
4.2
4.4 De-Registration Exchange....................................15 Exchange....................................16
5.0 Rekey protocol................................................16
5.1 Goals of the Rekey protocol.................................16 protocol.................................17
5.2 Rekey messages..............................................17 Messages..............................................17
5.3 Reliable transport Transport of rekey messages........................17 Rekey Messages........................18
5.4 Implosion...................................................18 State-of-the-art on Reliable Multicast Infrastructure.......20
5.5 Implosion...................................................20
5.6 Issues in incorporating group key management algorithms....19
5.5.1 Stateless vs. stateful rekeying..........................19
5.6 Incorporating Group Key Management Algorithms.....21
5.7 Stateless, Stateful, and Self-healing Rekeying Algorithms...21
5.8 Interoperability of a GKMA..................................20 GKMA..................................22
6.0 Group Security Association....................................21 Association....................................23
6.1 Group policy................................................21 Policy................................................23
6.2 Contents of the Re-key SA...................................22 Rekey SA....................................24
6.2.1 Re-key Rekey SA policy.........................................22 Policy..........................................24
6.2.2 Group identity...........................................23 Identity...........................................25
6.2.3 Key encrypting key(s)....................................23 KEKs.....................................................25
6.2.4 Authentication key.......................................23 Key.......................................25
6.2.5 Replay protection information............................24 Protection........................................26
6.2.6 Security Parameter Index (SPI)...........................24 (SPI)...........................26
6.3 Contents of the Data SA.....................................24 SA.....................................26
6.3.1 Group identity...........................................24 Identity...........................................26
6.3.2 Source identity..........................................24 Identity..........................................26
6.3.3 Traffic encrypting key...................................24 Erotection Keys..................................26
6.3.4 Data Authentication key.......................................24 Keys.................................26
6.3.5 Sequence numbers.........................................25 Numbers.........................................27
6.3.6 Security Parameter Index (SPI)...........................25 (SPI)...........................27
6.3.7 Data SA policy...........................................25 policy...........................................27
7.0 Scalability Considerations....................................25 Considerations....................................27
8.0 Security Considerations.......................................29
8.0
9.0 Acknowledgments...............................................30
10.0 References and Bibliography...................................31
9.0 Authors' Addresses............................................34 Bibliography..................................30
11.0 Authors Addresses............................................35
Appendix: MSEC Security Documents Roadmap.........................35 Roadmap.........................36
Internet Draft Group Key Management Architecture [PAGE 2]
Baugher, Canetti, Dondeti, Lindholm June September 2003
1.0 Introduction: Purpose of this Document
Group and multicast applications have diverse requirements in IP
networks [CP00]. Their key management requirements, which are requirements - briefly
reviewed below (see in Section 2.0), 2.0 - include support for internetwork,
transport, and application-layer protocols. In
particular, while ISAKMP and IKE protocols purport to manage keys for
any and all services in a host, some Some applications may
achieve simpler operation by running key-management messaging over a
pre-established secure channel (e.g., TLS, IPsec). Other security
protocols may benefit from a key management protocol that can run
over already deployed session initiation or management protocol
(e.g., SIP or RTSP). Finally, some may benefit from a light-weight keye
key management protocol that finishes in fewest round trips. For
these reasons, different application, transport, and internetwork-layer internetwork-
layer data security protocols
such as SRTP, IPsec, (e.g., SRTP [SRTP] and AMESP IPsec [RFC2401])
may benefit from using different group key management systems. The most popular key management protocols
deployed today provide support for a number of real-world scenarios
such as NAT traversal (e.g., IKE). Thus any general purpose group
key management protocol might also need to provide such
functionalities. The
purpose of this document is to define a common architecture and
design for these different group key-management protocols for internet, transport,
and application services.
The common architecture for group key management is called the "MSEC MSEC
Key Management Architecture" Architecture and 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 [McGrew and
Sherman], SDR [NNL], [OFT], and MARKS. MARKS
[MARKS]. There are other approaches that are not considered in this
architecture such as the highly distributed Cliques group key
management protocol [Tsudik, et. al.] [CLIQUES] and broadcast key management schemes [Fiat & Naor,
[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 integration of MSEC group
key management with Cliques, broadcast key management and other
group key systems is not considered in this document, which seeks to provide a group key
management framework for the MSEC suite of multicast security
protocols. document.
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 specialized for different uses.
This document builds on and extends the Group Key Management Building
Block document of the IRTF SMuG research group [HBH01] [GKMBB] 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.
Internet Draft Group Key Management The MSEC Architecture [PAGE 3]
Baugher, Canetti, Dondeti, Lindholm June 2003
Section 2 discusses the security, performance and architectural
requirements [MSEC-Arch] is
another reference for 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
Internet Draft Group Key Management Architecture [PAGE 3]
Baugher, Canetti, Dondeti, Lindholm September 2003
architectural design principles. Section 4 describes the Registration
protocol in detail and Section 5 does the same for Rekey protocol.
Section 6 considers the interface to the Group Security Association (GSA) using the standard keywords of RFC 2119.
(GSA). Section 7 reviews the scalability issues for group key
management protocols and Section 8 discusses Security Considerations.
2.0 Requirements for of a group key management protocol Group Key Management Protocol
A group key management protocol supports multicast applications that
need protected communication
between members of a secure group. A "secure group" secure group is a collection of
principals, called "members," 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 group key management protocol" protocol
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, typically have the following key-management requirements
(see also [CP00]). Note that the list is neither applicable to all
applications nor exhaustive.
1. The group members receive "security associations" security associations including
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 GCKS may define and enforce group membership, key
management, data security and other policies that may or may not
be communicated to the membership-at-large.
3. Keys will have a predetermined lifetime and will may be periodically
refreshed.
3.
4. Key material are should be delivered securely to members of the group
so that they are secret, integrity-protected and can be verified
as coming from an authorized source.
4.
5. The key-management protocol is also should be secure against replay
attacks and Denial of Service(DoS)attacks(see Service(DoS) attacks (see the Security
Considerations section of this memo).
5.
6. The protocol adds should facilitate addition and removes removal of group
members so that members who are added may optionally be denied
access to the key material used before they joined the group, and
Internet Draft Group Key Management Architecture [PAGE 4]
Baugher, Canetti, Dondeti, Lindholm September 2003
that removed members lose access to the key material following
their departure.
6.
7. The protocol supports should support a scalable group re-key Rekey operation
without
Internet Draft Group Key Management Architecture [PAGE 4]
Baugher, Canetti, Dondeti, Lindholm June 2003 unicast exchange exchanges between members and a group
controller/key server, which might overwhelm to avoid overwhelming a GCKS when the group is large.
7. managing a
large group.
8. The protocol is should be compatible with the infrastructure and
performance needs of the data-security application, such as IPsec
security protocols, AH and ESP, and/or application-layer security
protocols, AMESP and such as SRTP. (note: needs further clarification)
8.
9. The key management protocol offers should offer a framework for replacing
or renewing transforms, authorization infrastructure and
authentication systems.
9.
10. The key management protocol must should be secure against collusions collusion
among excluded members and non-members. Specifically, collusions collusion
must not result in attackers gaining any additional group secrets
than the
colluding entities themselves each of them individually are privy to.
10. In other words,
combining the knowledge of the colluding entities must not result
in revealing additional group secrets.
12. The key management protocol must should provide a mechanism to
securely recover from a compromise of some or all of the key
material.
Although it is not a requirement for a multicast security protocol,
the group key
13. Key management protocol protocols may also be useful need to unicast
applications that share many of the requirements of multicast address real-world
deployment issues such as NAT-traversal and may need to interface
with legacy authentication mechanisms already deployed.
In contrast to typical unicast key and SA negotiation protocols such
as TLS and IKE, group key management protocols provide SA and key
download capability. This feature may be useful for point-to-point
communication as well. Thus, a group key management protocol may
also be useful to unicast applications. In other words words, group key
management protocols may be used for protecting multicast
communications, or unicast communications in
groups where between members communicate among themselves mainly via unicast. of a secure
group. In other words, secure sub-group communication is plausible
using the group SA.
There are other requirements for small group operation where there
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 single group controller (or GCKS) may not be the best design for
small, interactive groups. However, large single-source multicast
groups generally may benefit from the use of a specialized GCKS.
Large distributed simulations, moreover, may combine the need for
large-group operation with many senders.
We also take as a requirement the support of
The current key management architecture covers secure communication
in 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 Scalable operation to a range of group sizes is also a
Internet Draft Group Key Management Architecture [PAGE 5]
Baugher, Canetti, Dondeti, Lindholm September 2003
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. The group key
management architecture allows two or more key management protocols,
where each protocol is suitable to a different scenario such large
single-source groups or small interactive groups.
Internet Draft Group Key Management Architecture [PAGE 5]
Baugher, Canetti, Dondeti, Lindholm June 2003
In addition to these requirements, it is useful to emphasize two non-
requirements, namely, 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 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" tamper-resistant store using various types of hardware or software
to implement TPM. The
group However, for simplicity, MSEC key management
architecture described in this document,
however, is for key management protocols and not a design document considers design for
technical protection measures, which are outside the scope measures out of this
document. scope.
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 a digital videodisk player. We assume IP network operation
where there is two-way communication, however asymmetric, and that
authenticated key-exchange procedures can be used for member
registration. It is possible that broadcast applications can make
use of a one-way Internet group key management protocol message, and
a one-way Re-key Rekey message is as described below.
3.0 Overall Design of the Group Key Management Architecture
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] RFC3547]
with a single group owner as the root-of-trust. The group owner
designates a group controller for member registration and re-key. Rekey.
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 Data
Security Protocol SA", SA, or "Data SA" 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 group controller/key server
(GCKS) and a joining group member. In this protocol the GCKS and
joining member mutually authenticate each other. If the
Internet Draft Group Key Management Architecture [PAGE 6]
Baugher, Canetti, Dondeti, Lindholm June September 2003
authentication succeeds and the GCKS finds that the joining member is
authorized, then the GCKS supplies the joining member with the
following information:
(a) Sufficient information to initialize a "Re-key Protocol SA" the Data Security
SA within the joining member (see more details about this SA below). member. This information is given only in the
case that the group security policy calls for using a Re-key protocol. initializing the Data
Security SA at Registration, instead of or in addition to at Rekey.
(b) Sufficient information to initialize the Data Security
Protocol a Rekey SA
within the joining member. member (see more details about this SA below).
This information is given only 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. 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 Protocol SA".
Registration SA. A complementary "De-registration
protocol" De-registration protocol serves to
explicitly remove Registration Protocol SA state. Members may choose to
delete Registration SA state on their own volition
(2) Re-key Rekey protocol.
================
This is an optional protocol where a
A GCKS may periodically sends re-key update or change the data security SA by
sending Rekey information to the group members. Re-key Rekey messages may
result from group membership changes, change in group security
policy, the creation of new traffic-encrypting traffic-protection keys (TPKs, see next
section) for the particular Group, or from key expiration. Re-key Rekey
messages are protected by the Re-key protocol Rekey SA, which is initialized in the
Registration protocol. The Re-key Rekey message includes information for
updating both the Re-key protocol Rekey SA and/or the Data Security Protocol SA. The Re-key Rekey messages
can be sent via multicast to group members or unicast from the GCKS
to a particular group member.
The Re-key protocol is optional as
Note that there are other means for managing (e.g. expiring or
refreshing) the keys locally data security SA without interaction between the GCKS
and member [MARKS]. The Re-key SA that is
established includes authentication data the members. For example in MARKS [MARKS], the GCKS pre-
determines TPKs for different periods in the re-key. There 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 security SA are also
possible, although this type of operation is typically limited to
small groups.
Rekey messages are authenticated using one of the two cases. following
options:
o The first and the primary option is to use source authentication.
That is, each group member verifies that Re-key Rekey data originates
with the GCKS and none other.
Internet Draft Group Key Management Architecture [PAGE 7]
Baugher, Canetti, Dondeti, Lindholm September 2003
o The second option is to use only group-based authentication using
a symmetric key, such as a message authentication code. key. Members can only be assured that the Re-key Rekey
messages originated within the group. Therefore, this is
applicable only when all members of the group are trusted not to
impersonate the GCKS. Group authentication for Re-key Rekey messages is
typically used when public-
Internet Draft Group Key Management Architecture [PAGE 7]
Baugher, Canetti, Dondeti, Lindholm June 2003
key public-key cryptography is not suitable for
the particular group.
The Re-key Rekey protocol ensures that all members receive the re-key Rekey
information in a timely manner. In addition, the Re-key Rekey protocol
specifies mechanisms for the parties to contact the GCKS and "re-
synch" re-synch
in case that their keys expired and an updated key has not yet been
received. The Re-key Rekey protocol for large-scale groups offers
mechanisms to avoid implosion problems and ensure the needed
reliability in its delivery of keying material.
The Re-key Rekey message is protected by a Re-key Rekey SA, which is established by
the Registration Protocol. It is a recommended practice that a
member who leaves the group destroys the Re-key SA, one or more Data
SAs, and the Registration SA to which these SAs belong. groups SAs. Use of a De-
Registration message is often may be an efficient mechanisms for a member to
inform the GCKS that it has destroyed it the 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.
3.2 Detailed description Description of the GKM Architecture
Figure 1 depicts the overall design [HBH01]. [GKMBB] of a GKM protocol. Each
group member, sender or receiver, uses 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) key
encryption keys (KEKs) and the Traffic Protection Keys traffic encryption keys (TEKs). For
group authentication of rekey messages or TPKs (TPKs data, key integrity keys or
traffic integrity keys may be used as well. We use the term
protection keys to refer to both Traffic
Encryption Keys or TPKs, and Traffic integrity keys and the encryption
keys. For example, the term traffic protection keys). key (TPK) is used to
denote the combination of a TEK and a traffic integrity key, or key
material used to generate them.
The KEK may be a single key that encrypts protects the TPKs or it rekey message,
typically containing a new rekey SA (containing a KEK) and/or data
security SA (containing a TEK). A rekey SA may be also contain a vector
of keys in that are part of a group key membership algorithm [RFC2627,
OFT, CP00, LNN01, SD] that encrypts the TPKs and other KEKs. The KEK is used by
the Re-key protocol. SD]. The TPKs are used by the Data Security
Protocol to protect streams, files, or other data sent and received
by the Data Security Protocol. Thus the Registration Protocol and/or
the
Re-key Rekey Protocol establish the KEK and KEK(s) and/or the TPKs.
There are a few, distinct outcomes to a successful Registration
Protocol exchange.
o If the GCKS uses Re-key messages, then the admitted member
receives the Group KEK; if it uses a group key management
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 TPKs (in SAs) that are passed to
the member's Data Security Protocol (as IKE does for IPsec).
o The GCKS may pass one or more TPKs to the member even if Re-
key messages are used, for efficiency reasons according to
Internet Draft
Internet Draft Group Key Management Architecture [PAGE 8]
Baugher, Canetti, Dondeti, Lindholm June September 2003
group policy.
+------------------------------------------------------------------+
| +-----------------+ +-----------------+ |
| | POLICY | | AUTHORIZATION | |
| | INFRASTRUCTURE | | INFRASTRUCTURE | |
| +-----------------+ +-----------------+ |
| ^ ^ |
| | | |
| v v |
| +--------------------------------------------------------------+ |
| | | |
| | +--------------------+ | |
| | +------>| GCKS |<------+ | |
| | | +--------------------+ | | |
| | REGISTRATION or | REGISTRATION or | |
| | DE-REGISTRATION | DE-REGISTRATION | |
| | PROTOCOL | PROTOCOL | |
| | | | | | |
| | v RE-KEY REKEY v | |
| | +-----------------+ PROTOCOL +-----------------+ | |
| | | | (OPTIONAL) | | | |
| | | SENDER(S) |<-------+-------->| RECEIVER(S) | | |
| | | | | | | |
| | +-----------------+ +-----------------+ | |
| | | ^ | |
| | v | | |
| | +-------DATA SECURITY PROTOCOL-------+ | |
| | | |
| +--------------------------------------------------------------+ |
| |
+------------------------------------------------------------------+
FIGURE 1: Group Security Association Model
There are a 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
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 a group key integrity key, and if the group
uses a group key management algorithm, a set of KEKs (or key
material used to derive the KEKs) according to the particular
algorithm.
o If Rekey messages are not used for the Group, then the
Internet Draft Group Key Management Architecture [PAGE 9]
Baugher, Canetti, Dondeti, Lindholm September 2003
admitted member will receive TPKs (as part of the Data
Security SAs) that are passed to the members Data Security
Protocol (as IKE does for IPsec).
o The GCKS may pass one or more TPKs to the member even if Re-
key messages are used, for efficiency reasons according to
group policy.
The GCKS creates the KEK and TPKs and downloads them to each member -
as the KEK and TPKs are common to the entire Group. The 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 GCKS MAY present a credential to the Group member that is
signed by the Group Owner so the member can check the GCKS's GCKSs
authorization. The GCKS, which may be co-located with a member or be
a separate physical entity, runs the Re-key Rekey Protocol to push Re-key Rekey
messages of containing refreshed KEKs, new TPKs, and 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 Re-key Rekey messages on behalf of the
GCKS when it uses a credential mechanism that supports delegation.
Thus, it is possible for the sender or (or other member members) to source
keying material (a - TPKs encrypted in the Group KEK) KEK - as it sources
multicast or unicast data. As mentioned above, the Re-key
Internet Draft Group Key Management Architecture [PAGE 9]
Baugher, Canetti, Dondeti, Lindholm June 2003 Rekey message can
be sent using unicast or multicast delivery. Upon receipt of a TPKs TPK
(as part of a Data Security SA) from a Re-key Rekey Message or a
Registration protocol exchange, the member's members group key management
functional block will provide a the new or updated security association
(SA) to a the Data Security Protocol for to protect the data sent from
sender to receiver.
The "Security Protocol SA" Data Security SA protects the data sent on the arc labeled
"DATA DATA
SECURITY PROTOCOL" PROTOCOL shown in Figure 1. A second SA, the "Re-key
SA," Rekey SA, is
optionally established by the key-management protocol for Re-
key Rekey
messages, and the arc labeled "RE-KEY PROTOCOL" REKEY PROTOCOL in Figure 1 depicts
this. The Re-key Rekey message is optional because all keys, KEK 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, symmetric, unicast unicast, SA between
the GCKS and each member; this is called the "Registration
Protocol SA." Registration SA. There
may be no need for the Registration Protocol SA to remain in place after the
completion of the Registration Protocol exchanges. The De-registration De-
registration protocol is also optional and is may be used when explicit teardown or of the SA is
desirable (such as when a phone call or conference terminates). The
three SAs comprise compose the Group Security Association. Only one SA is
optional and that is the Re-key Rekey SA.
Internet Draft Group Key Management Architecture [PAGE 10]
Baugher, Canetti, Dondeti, Lindholm September 2003
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].
3.3 Properties of the design Design
The design of Section 3.2 achieves scalable operation by (1) allowing
the de-coupling of authenticated key exchange in a "Registration
Protocol" Registration
Protocol from a "Re-key Protocol," Rekey Protocol, (2) allowing the Re-key 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 unicast push or multicast
distribution of symmetric group and data keys, and (3) supporting key
revocation algorithms such as LKH [RFC2627, OFT, LNN01] 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
Internet Draft Group Key Management Architecture [PAGE 10]
Baugher, Canetti, Dondeti, Lindholm June 2003 over the life of
the group KEK: A Data Security SA can be established without the use
of asymmetric cryptography - the TPKs are simply encrypted in the
symmetric KEK and sent unicast or multicast in the
Re-key Rekey protocol.
The design of the Registration and Re-key Rekey Protocols is flexible. The
Registration protocol establishes either a Rekey SA or one KEK or multiple TPKs more
Data Security SAs or both
KEK and TPKs. The TPKs(or ôdata keyö) types of SAs. At least one of the SAs is associated with a data
security protocol SA;
present (otherwise, there may in fact be multiple keys pushed with
or derived from is no purpose to the TPKs. Registration SA). The Re-key Protocol establishes KEKs
Rekey SA may update the Rekey SA, or
TPKs establish or both. update one or more
Data Security SAs. Individual protocols or configurations may take
advantage of this flexibility for efficient operation.
3.4 Implementation 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 Security Protocol SA, an
optional Re-key Rekey SA, and a Registration Protocol SA. The GCKS MAY use a
delegated principal, such as an SRTP [SRTP] the sender, which has a delegation
credential signed by the GCKS. The "Member" 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," GKM, and there are two arcs
between them depicting the group key-management Registration ("reg") (reg)
Internet Draft Group Key Management Architecture [PAGE 11]
Baugher, Canetti, Dondeti, Lindholm September 2003
and Re-key ("rek") Rekey (rek) protocols. The message exchanges are the GSA
establishment protocols, which are the Registration Protocol and the Re-key
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
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" CRED in Figure 2.
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 is subject to Group
Policy [HH], but how | |
| +------^------+ +------|-----+ +--------+ |
| | | +-----| 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 a host computer
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 is subject to Group
Policy [GSPT], but how this is done is specific to the GCKS
implementation. CONTROL may be a telephony signaling protocol such
as SIP with the GCKS function operating on a caller's phone. For large-scale multicast sessions, CONTROL could
perform session announcement functions to inform a potential group
member that it may join a group or receive group 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
Internet Draft Group Key Management Architecture [PAGE 11] 12]
Baugher, Canetti, Dondeti, Lindholm June September 2003
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 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 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 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 SAs on behalf of a Security Protocol in which
members join secure groups and receive keys for streams, files or
other data.
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| | 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 a host computer
The goal of the exchanges is to establish a GSA through updates to
the SAD of a key-management implementation and particular Security
Protocol. The "Security Protocol" Data Security Protocol of Figure 2 may span
internetwork and application layers [AMESP] or operate at the internetwork
layer, such as AH and ESP.
Internet Draft Group Key Management Architecture [PAGE 12]
Baugher, Canetti, Dondeti, Lindholm June 2003
4.0 Registration Protocol
The design of the Registration is flexible. The Registration protocol establishes one Rekey SA or multiple Data Security SAs or
both Rekey is flexible, and Data Security SAs. Traffic protection keys (or "data
keys") associated with a data security protocol SA; there may in
fact be multiple keys pushed with or derived from the TPKs. A
particular group key management protocol MAY restrict these many
options according to its particular requirements.
Each registration protocol supports 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 [GSAKMP]. However, registration
protocols that address other scenarios, [tGSAKMP]. GDOI [RFC3547] reuses IKE phase1 as the
secure channel to download Rekey and/or Data Security SAs. Other
protocols, such as GDOI [GDOI] and MIKEY [MIKEY], and GSAKMP, use other methods authenticated Diffie-
Hellman exchanges similar to secure SA establishment. Some of IKE Phase1, but specifically tailored
for key download to achieve efficient operation. We discuss the different solutions that arise from specific scenarios are
discussed in the sections below. This document also refers
design of a registration protocol in more detail to the specific registration protocols GDOI and MIKEY, and
shows how these fit within in the general architecture. rest of this
section.
4.1 Registration Protocol Message Exchange via Piggybacking or Protocol Reuse
Some registration protocols need "tunnel" to tunnel through a data-signaling
protocol. The reason may e.g. be
protocol to take advantage of already existing (security) security
functionality, and/or to optimize the total session setup time. For
example, a telephone call has strict bounds for delay in setup time;
we donÆt dont like to wait a second longer than we have to. It is not
feasible to run security exchanges in parallel with call setup since
the latter often resolves the address: Call setup must complete
before the caller knows the address of the callee. A better solution is In this case, it
may be advantageous to tunnel the key exchange procedures inside
call establishment [H.235, MIKEY] so both can complete (or fail, see
below) at the same time.
Internet Draft Group Key Management Architecture [PAGE 13]
Baugher, Canetti, Dondeti, Lindholm September 2003
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.
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.
Internet Draft Group Key Management Architecture [PAGE 13]
Baugher, Canetti, Dondeti, Lindholm June 2003
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. two messages). This is also desirable requirement from RTSP
as well.
The GDOI approach takes advantage of the already defined ISAKMP
phase 1 exchange [RFC2409], and extends the phase 2 exchange for the
registration. This The advantage here is a good example the reuse of reusing security
functionality, a successfully
deployed protocol and the code base, where the defined phase 2
exchange is protected by the SA created by phase 1. The GDOI will also inherent
inherits other functionality of the ISAKMP. This may e.g. make the solution very ISAKMP, and thus it is readily
suitable for running IPsec protocols over IP multicast services.
4.2 Properties of Alternative Registration Exchange Types
The required design properties of a registration protocol has have
different tradeoffs. A protocol that provides perfect forward
secrecy and identity protection trades security for performance or
efficiency, efficiency for
better security, while a protocol that completes in one or two
messages may trade security functionality (e.g. identity protection)
for efficiency.
In a one- or two-message protocol, replay
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 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". 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-provision the replay cache.
However, this may lead to a large replay cache. Another solution is
Internet Draft Group Key Management Architecture [PAGE 14]
Baugher, Canetti, Dondeti, Lindholm September 2003
to let the allowable clock skew be changed dynamically during
runtime. During a suspected DoS attack, the allowable clock skew is then
decreased so that the replay cache becomes manageable.
A challenge-response mechanism (using Nonce) Nonces) obviates the need for
synchronized clocks for replay protection when the exchange uses
three or more messages [MVV]. This does not guarantee the replay
protection of individual messages (unless the protocols record all
Nonce), but on the exchange itself. "Cookies", such as stateless
cookies are means to protect against the replay of individual
messages [Photuris].
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
Internet Draft Group Key Management Architecture [PAGE 14]
Baugher, Canetti, Dondeti, Lindholm June 2003
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 Infrastructure for Alternative Registration Exchange Types
The registration protocols protocol may need external infrastructures to be
able to handle authentication, authentication and authorization, replay protection,
protocol-run integrity,
authorization and potentially other security services such
as secure, synchronized clocks. These For example, authentication and
authorization may be solved by e.g. deploying need a PKI deployment (with either authorization-based authorization-
based certificates or a separate management for this). Other existing solutions this) or may be employed such
as
handled by using AAA infrastructure. Depending on the registration protocol and
its application, other external infrastructures may also be needed
e.g. timestamp-based protocols may need Replay protection using
timestamps requires an external infrastructure to
synchronize the clocks. or protocol for clock
synchronization.
However, external infrastructures may not always be needed. This
could be the case when e.g. needed, if for
example pre-shared keys are used for authentication and
authorization; this may be the case if the subscription base is very
relatively small. In a conversational multimedia scenario (e.g. (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.
In general, protocols that use fewer messages require more Thus, infrastructure (such as synchronized clocks) or fewer security
features such as PFS or identity protection.
4.2 support may not be
required in that case.
Internet Draft Group Key Management Architecture [PAGE 15]
Baugher, Canetti, Dondeti, Lindholm September 2003
4.4 De-Registration Exchange
The session-establishment protocol (e.g. (e.g., SIP, RTSP) that conveys a
Registration exchange often has a session-disestablishment protocol
such as RTSP TEARDOWN [RFC2326] or SIP BYE [RFC2543]. The session-
disestablishment exchange between endpoints offers an opportunity to
signal the end of the GSA state at the endpoints. This "exchange" exchange
need only be a uni-directional notification by one side that the GSA
is to be destroyed. Authentication For authentication of this notification can notification, we may
use a
Internet Draft Group Key Management Architecture [PAGE 15]
Baugher, Canetti, Dondeti, Lindholm June 2003 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. 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 Rekey protocol
Group
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 Security 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 Security SA.
The following are some desirable properties of the Rekey protocol:
o Rekey protocol ensures that all members receive the rekey
information in a timely manner.
o Rekey protocol specifies mechanisms for the parties
involved, to contact the GCKS and re-sync when their keys expire
and no updates have been received.
o 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 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.
Internet Draft Group Key Management Architecture [PAGE 16]
Baugher, Canetti, Dondeti, Lindholm September 2003
5.1 Goals of the Rekey protocol
The goals of the Rekey protocol are:
o to synchronize a GSA
o to provide privacy and (symmetric or asymmetric)
authentication,
Internet Draft Group Key Management Architecture [PAGE 16]
Baugher, Canetti, Dondeti, Lindholm June 2003
o efficient rekeying after changes in group membership, or when
keys (KEKs) expire,
o (optional) reliable delivery of rekey messages messages,
o provide methods for members to recover from an out-of-sync GSA,
o high throughput and low latency, and
o to use IP Multicast or multi-unicast.
We identify five six major issues in the design of a rekey protocol:
1. rekey message format
2. reliable transport of rekey messages
3. implosion
4. recovery from out-of-sync GSA
5. incorporating GKMAs in rekey messages
5.
6. interoperability of GKMAs
Note that for a GCKS to successfully rekey a group, it is not
sufficient that Rekey protocol implementations interoperate. We also
need to ensure that the GKMA also interoperates. interoperates, i.e., standards
versions of group key management algorithms, such as LKH, OFT, subset
difference and others need to be used.
In the rest of this section we discuss these issues in detail.
5.2 Rekey messages Messages
Rekey messages are at the core of the rekey protocol. They contain
Rekey and/or Data Security SAs along with KEKs and TPKs. These
Internet Draft Group Key Management Architecture [PAGE 17]
Baugher, Canetti, Dondeti, Lindholm September 2003
messages need to be confidential, authenticated, and protected
against replay attacks.
Rekey messages contain group key updates corresponding to a
single[LKH,OFT] single
[RFC2627, OFT] or multiple membership changes[Subset, changes[SD, BatchRekey] and often may
contain group key initialization messages [OFT].
5.3 Reliable transport Transport of rekey messages Rekey Messages
The GCKS needs to 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 reliable transport mechanism to send rekey messages.
There are two dimensions to the problem: Messages that update group
keys may be lost in transit or may be missed by a host when it is
Internet Draft Group Key Management Architecture [PAGE 17]
Baugher, Canetti, Dondeti, Lindholm June 2003
offline. LKH and OFT group key management algorithms rely on past
history of updates being received by the host. If the host is goes
offline, then it will need to resynchronize its group-key state,
which probably requires state when it
comes online; this may require a unicast exchange with the GCKS.
The Subset Difference algorithm, however, conveys all the needed
state in its re-key message Rekey messages and does not need members to be always on
online, nor
always connected. keeping state. Subset difference algorithm does not
require a backchannel and can operate on a broadcast network. Subset difference, however,
does need to have its key management If a
rekey message received by the member.
Thus Subset difference, LKH and OFT are not inherently reliable.
Reliable multicasting is a hard problem, but there are several
solutions lost in transmission, subset difference algorithm
cannot decrypt messages encrypted with the literature. We discuss reliable transport of TPK sent via the lost
rekey
messages message. There are self-healing GKMAs proposed in this section. 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.
Rekey messages are typically short (for single membership change as
well as for small 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 are some
special cases where membership changes are processed as a batch,
which reduces the frequency of rekey messages, but increases their
size. Furthermore, among all the KEKs sent in a rekey message,
as many as half the members need only a single KEK. We need to may take
advantage of these properties in designing a rekey message(s) and
a protocol for their reliable delivery.
Three categories of solutions have been proposed:
1. Repeatedly transmit the rekey message: Recall that in many
cases rekey messages translate to only one or two IP packets.
2. Use an existing reliable multicast protocol/infrastructure
Internet Draft Group Key Management Architecture [PAGE 18]
Baugher, Canetti, Dondeti, Lindholm September 2003
3. Use FEC for encoding rekey packets (with NACKs as
feedback) [BatchRekey]
Note that for small messages, category 3 is essentially the same as
category 1.
5.4 Implosion
Implosion may occur due to one
The group member might be out of two reasons. First, recall synchrony with the GCKS if it
receives a Rekey message having a sequence number that is more than
one of the goals of greater than the rekey protocol last sequence number processed. This is to "synchronize a GSA."
When a rekey or data security SA expires, members may contact one
means by which the GCKS for member detects that it has missed a Rekey
message. Alternatively, the data-security application might detect
that it is using an update. If all or even many members contact out-of-date key and notifies group key
management BB of this condition. What action the GCKS at
about member takes
is a matter of group policy: The GCKS member should log the same time,
condition and may contact the GCKS cannot handle all those messages. We
refer to this as an "out-of-sync implosion."
Internet Draft Group Key Management Architecture [PAGE 18]
Baugher, Canetti, Dondeti, Lindholm June 2003 re-run the re-registration
protocol to obtain a fresh group key. The second case group policy needs to
take into account boundary conditions, such as re-ordered 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 reliable delivery potential for denial of rekey messages.
Reliable multicast protocols use feedback (NACK service attacks where
an attacker delays or ACK) deletes a Rekey message in order to determine
which packets must be retransmitted. Packet losses may result in
many force a
subnetwork or subset of the members sending NACKs to synchronously contact the
GCKS. We refer to this as feedback
implosion.
The implosion problem has been studied extensively in
If a group member becomes out-of-synch with the context of
reliable multicasting. Some of GSA then it should
re-register with the proposed solutions viz., feedback
suppression and aggregation, might be useful GCKS. However, in this context as well. many cases there are other,
simpler methods for re-synching with the group:
o The GCKS might send each receiver a random number to be used as time
to wait before sending member can open a NACK or out-of-sync message. Meanwhile,
members might receive simple, unprotected connection (say, TCP)
with the key updates they need GCKS and therefore will
not send a feedback message.
An alternative solution is to have obtain the members contact one of current (or several
registration servers when they are out-of-sync. This results in
repetition of the registration process for those members.
Furthermore, recent) rekey
messages. Note that there is the no need to setup multiple registration servers
and synchronize them.
Feedback aggregation for authentication or
encryption here, since the rekey message is already signed and local recovery employed
is anyway multicasted in the clear. One may think that this
opens the GCKS to DoS attacks by some reliable
multicast protocols are many bogus such requests. But
this does not easily adaptable to transport of rekey
messages. There are authentication issues seem to address worsen the situation: in aggregation.
Local recovery is fact, bombarding
the GCKS with bogus resynch requests would be much more complex in
problematic.
o The GCKS can post the rekey messages on some public site (say,
web site) and the out-of-synch memeber can obtain the rekey
messages from that site.
It is suggested that members need to establish SAs
with the local repair server.
5.5 Issues in incorporating group key management algorithms
Group key management algorithms make re-keying scalable. Large group
re-keying without employing GKMAs GCKS always provide all three ways of
resynching (i.e., re-registration, simple TCP, and public posting).
This way, it is prohibitively expensive.
First we list some requirements up to consider in selecting a GKMA:
o Collusion: Members (or non members) should not be able the member to
collaborate choose how to deduce keys that they are resynch and we do
not privileged
(following need any additional fields in the GKMA key distribution rules) to.
o Forward access control: Ensure that departing members cannot get
access to future group data.
o Backward access control: Ensure that joining members cannot
decrypt past data.
5.5.1 Stateless vs. stateful rekeying
We classify group key management algorithms into two categories,
viz., stateful and stateless algorithms. policy token. Alternatively,
we may add a field in the policy token specifying which method(s)
should be used for re-synching.
Internet Draft Group Key Management Architecture [PAGE 19]
Baugher, Canetti, Dondeti, Lindholm June September 2003
Stateful algorithms use KEKs from the ith rekeying instance to
encrypt (protect) KEKS corresponding to the i+1st rekeying instance.
5.4 State-of-the-art on Reliable Multicast Infrastructure
The main disadvantage in these schemes is that if a member was
offline or otherwise fails to receive KEKs from a rekeying instance
i, it can Rekey message may be sent using reliable multicast. There are
multiple types of reliable multicast protocols and products, which
have different properties. However, there are no longer synchronize its GSA even though it can receive
KEKs from all future rekeying instances starting standard reliable
multicast protocols at i+1. The only
solution is to contact the GCKS explicitly present time. Thus, this document makes
no recommendation for resynchronization.
Note that the KEKs use of a particular reliable multicast
protocol or set of protocols for the first rekeying instance are protected purposes group key management.
The suitability of NAK-based, ACK-based, or other reliable multicast
methods are determined by the registration SA. Recall that communication in particular needs of the group key
management application and environment. In the future, group key
management protocols may choose to use particular standards-based
approaches that phase meet the needs of the particular application. A
secure announcement facility is one needed to one, signal the use of a
reliable multicast protocol, which must be specified as part of
group policy. The reliable multicast announcement and therefore it is easy to ensure policy
specification, however, can only follow the establishment of
reliable delivery.
Stateless GKMAs encrypt rekey 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 KEKs sent during the
registration protocol. Since rekey messages are independent Rekey message. A sender of any
past rekey Rekey
messages (i.e. not protected by KEKs therein), 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
may go offline, but continue to be able who receives the Rekey message will check the
sequence number to decipher future
communications. detect duplicate and missing Rekey messages. The catch however
member receiver will discard duplicate messages that it receives.
Large Rekey messages, such as those that contain LKH or OFT tree
structures, might benefit from transport-layer FEC when standard
methods are available in the future. It is unlikely that members can never decrypt
any forward
error correction (FEC) methods will benefit Rekey messages sent while they were offline, even though there that are
eligible
short and fit within a single message. In this case, FEC
degenerates to (i.e. paid for that content as well). Stateless rekeying simple retransmission of the message.
5.5 Implosion
Implosion may be relatively inefficient, particularly for immediate (in
contrast occur due to batch) rekeying in highly dynamic groups.
5.6 Interoperability one of a GKMA
Most GKMA specifications do not specify packet formats although any
group key management algorithms needs two reasons. First, recall that
one of the goals of the rekey protocol is to synchronize a GSA. When
a rekey or data security SA expires, members may contact the GCKS for
an update. If all or even many members contact the purposes of
interoperability. In particular there are several alternative ways GCKS at about the
same time, the GCKS cannot handle all those messages. We refer to managing key trees and numbering nodes within key trees.
this as an out-of-sync implosion.
The
following information second case is generally needed during initialization in the reliable delivery of a rekey SA messages.
Reliable multicast protocols use feedback (NACK or included with each GKMA packet.
o GKMA name (e.g. LKH, OFT, Subset difference)
o GKMA version number (implementation specific). Version ACK) to determine
which packets must be retransmitted. Packet losses may imply
several things such as result in
many members sending NACKs to the degree of a key tree, proprietary
enhancements, and qualify another field such GCKS. We refer to this as a key id.
o Number of keys or Largest ID
o Version specific data
o Per key information
- Key ID
- Key lifetime (creation/expiration data)
- Encrypted key
- encryption key's ID (optional) feedback
implosion.
Internet Draft Group Key Management Architecture [PAGE 20]
Baugher, Canetti, Dondeti, Lindholm June September 2003
Key IDs may change in some implementations
The implosion problem has been studied extensively in which case we need to
send:
o List of <old id, new id>
6.0 Group Security Association
The GKM Architecture defines the interfaces between context of
reliable multicasting. Some of the Registration,
Re-key, proposed solutions viz., feedback
suppression and Data Security protocols aggregation, might be useful 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 GKM context as
well.
Members may wait for a large group could use
IP Multicast with packet-level Forward Error Correction and source
authentication.
The Group Key Management Architecture provides random time before sending an interface between out-of-sync or
feedback message. Meanwhile, members might receive the security protocols key updates
they need and therefore will not send a feedback message.
An alternative solution is to have the group SA (GSA), which consists members contact one of
three SAs, viz., Registration SA, Re-key SA several
registration servers when they are out-of-sync. This requires
GSA synchronization between the multiple registration servers.
Feedback aggregation and Data SA. The Re-key
SA is optional. local recovery employed by some reliable
multicast protocols are not easily adaptable to transport of rekey
messages. There are two cases authentication issues to address in defining the relationships
between the three SAs. In both cases, the Registration SA protects aggregation.
Local recovery is more complex in that members need to establish SAs
with the Registration protocol.
In Case 1, local repair server.
5.6 Issues in Incorporating Group Key Management Algorithms
Group key management algorithms make Rekeying scalable. Large group
Rekeying without employing GKMAs is done WITHOUT using prohibitively expensive.
First we list some requirements to consider in selecting a Re-key SA.
The Registration protocol initializes and updates one or more Data
SAs (having TPKs GKMA:
o Collusion: Members (or non members) should not be able to protect files or streams). Each Data SA
corresponds
collaborate to a single group û and a deduce keys that they are not privileged to
(following the GKMA key distribution rules).
o Forward access control: Ensure that departing members cannot get
access to future group may have more than one
data SA.
In Case 2, data.
o Backward access control: Ensure that joining members cannot
decrypt past data.
5.7 Stateless, Stateful, and Self-healing Rekeying Algorithms
We classify group key management USES a Re-key SA algorithms into three categories,
viz., stateful, stateless, and self-healing algorithms.
Stateful algorithms [RFC2627,OFT] use KEKs from past rekeying
instances to encrypt (protect) KEKS corresponding to protect the Re-
key protocol. current and
future rekeying instances. The Registration protocol initializes the Re-key SAs
(one or more) as well as zero or more Data SAs upon successful
completion. When a Data SA is not initialized in the Registration
protocol, this is done main disadvantage in the Re-key protocol. The Re-key protocol
updates Re-key SA(s) AND establishes Data SA(s).
6.1 Group policy
Group-policy these schemes is currently being defined [GSPT]. It can
that if a member were offline or otherwise fails to receive KEKs from
a past rekeying instance, it may no longer be
distributed through announcement, key management protocols, and other
means. able to synchronize its
GSA even though it can receive KEKs from all future rekeying
instances. The group key management protocol carries cryptographic
policies of only solution is to contact the SA keys it establishes as well as additional policies GCKS explicitly 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
Internet Draft Group Key Management Architecture [PAGE 21]
Baugher, Canetti, Dondeti, Lindholm June September 2003
exchanges. Thus, a security policy repository having some access
protocol may need to be queried prior to key-management session
establishment to determine what
resynchronization. Note that the initial cryptographic policies
are KEKs for the first rekeying
instance are protected by the registration SA. Recall that establishment. This document assumes
communication in that phase is one to one, and therefore it is easy
to ensure reliable delivery.
Stateless GKMAs [SD] encrypt rekey messages with KEKs sent during the existence
registration protocol. Since rekey messages are independent of
such any
past rekey messages (i.e. not protected by KEKs therein), a repository and protocol for GCKS and member policy queries.
Thus group security policy will
may go offline, but continue to be represented able to decipher future
communications. However, they offer no mechanisms to recover past
rekeying messages. Stateless rekeying may be relatively inefficient,
particularly for immediate (in contrast to batch) rekeying in highly
dynamic groups.
In self-healing schemes [Self-healing], a policy repository member can reconstruct a
lost rekey message, as long as it receives some past rekey messages
and accessible using some future rekey messages.
5.8 Interoperability of a policy protocol.
This memo assumes that at least GKMA
Most GKMA specifications do not specify packet formats although any
group key management algorithms need to, for the purposes of
interoperability. In particular there are several alternative ways
to managing key trees and numbering nodes within key trees. The
following group-policy information is externally managed.
o Group owner, authentication method, and delegation method for
identifying generally needed during initialization of a GCKS for the group
rekey SA or included with each GKMA packet.
o Group GCKS, authentication method, and any method used for
delegating other GCKSs for the group GKMA name (e.g. LKH, OFT, Subset difference)
o Group membership rules or list and authentication method
There are also two additional policy-related requirements external to
group GKMA version number (implementation specific). Version may imply
several things such as the degree of a key management.
o There is an authorization tree, proprietary
enhancements, and authentication infrastructure qualify another field such as X.509, SPKI, a key id.
o Number of keys or pre-shared Largest ID
o Version specific data
o Per key scheme information
- Key ID
- Key lifetime (creation/expiration data)
- Encrypted key
- encryption keys ID (optional)
Key IDs may change in accordance with the
group policy for a particular group.
o There is an announcement mechanism for secure groups and events
that operates according some implementations in which case we need to group policy for a particular group.
send:
Internet Draft Group policy determines how the Registration and Re-key protocols
initialize or update Re-key and Data SAs. Key Management Architecture [PAGE 22]
Baugher, Canetti, Dondeti, Lindholm September 2003
o List of <old id, new id>
6.0 Group Security Association
The following sections
describe the information that is sent by GKM Architecture defines the GCKS for interfaces between the Re-key Registration,
Rekey, and Data SAs. A member needs to have the information specified Security protocols in the
next sections to establish Re-key and Data SAs.
6.2 Contents terms of the Re-key SA
The Re-key SA protects the Re-key protocol. It contains
cryptographic policy, Security Parameter Index (SPI) [RFC2401]
Associations (SAs) of those protocols. By isolating these protocols
behind a uniform interface, the architecture allows implementations
to
uniquely identify an SA, replay protection information, 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 for a large group could use
IP Multicast with packet-level Forward Error Correction and secret
keys.
6.2.1 Re-key SA policy source
authentication.
The MEMBERSHIP MANAGEMENT ALGORITHM represents Group Key Management Architecture provides an interface between
the group key
revocation algorithm that enforces forward security protocols and backward access
control. Examples the group SA (GSA), which consists of key revocation algorithms include LKH, LKH+,
OFT, OFC
three SAs, viz., Registration SA, Rekey SA and Subset Difference [RFC2627, OFT, CP00, LNN01]. Data SA. The key
revocation algorithm could also be NULL. Rekey SA
is optional. There are two cases in defining the relationships
between the three SAs. In that case, both cases, the Re-key Registration SA
contains only one KEK, which serves as protects
the group KEK. Registration protocol.
In Case 1, Group key management is done WITHOUT using a Rekey SA. The Re-key
messages initialize
Registration protocol initializes and updates one or update more Data SAs as usual. But, the Re-key SA
itself can be updated (group KEK can be re-keyed) when members join
Internet Draft Group Key Management Architecture [PAGE 22]
Baugher, Canetti, Dondeti, Lindholm June 2003
or the KEK is about
(having TPKs to expire. Leave re-keying is done by re-
initializing the Re-key protect files or streams). Each Data SA through the Re-key Protocol.
The KEK ENCRYPTION ALGORITHM uses corresponds
to a standard encryption algorithm
such as 3DES or AES. The KEK KEY LENGTH single group - and a group may have more than one data SA.
In Case 2, group key management is also specified.
The AUTHENTICATION ALGORITHM uses digital signatures for GCKS
authentication (since all shared secrets are known done WITH a Rekey SA to some or all
members of protect
the group), Rekey protocol. The Registration protocol initializes the Rekey
SAs (one or some symmetric secret more) as well as zero or more Data SAs upon successful
completion. When a Data SA is not initialized in computing MACs for
group authentication. Symmetric authentication provides weaker
authentication the Registration
protocol, this is done in that any group member can impersonate a particular
source. the Rekey protocol. The AUTHENTICATION KEY LENGTH Rekey protocol
updates Rekey SA(s) AND establishes Data SA(s).
6.1 Group Policy
Group Policy is also currently being defined [GSPT]. It can be specified.
The CONTROL GROUP ADDRESS is used for multicast transmission of Re-
distributed through announcement, key messages. This information is sent over the control channel such
as in an ANNOUNCEMENT protocol or call setup message. management protocols, and other
means (e.g., via a web page). The degree to
which the control group address is protected is a matter key management protocol
carries cryptographic policies of group
policy.
The REKEY SERVER ADDRESS allows the registration server to be a
different entity from the server used SAs and keys it establishes as
well as additional policies for re-key, such the group as well.
The acceptable cryptographic policies for future
invocations of the Registration and Re-key protocols. If Protocol,
which may run over TLS, IPsec, or IKE, are not conveyed in the
registration server and the re-key server are two different entities,
the registration server sends the re-key server's address as part group
key-management protocol since they precede any of the Re-key SA.
6.2.2 Group identity
The Group identity accompanies the SA (payload) information as an
identifier if the specific group key management protocol allows
multiple groups to be initialized in
exchanges. Thus, a single invocation of the
Registration security policy repository having some access
protocol or multiple groups may need to be updated in a single
Re-key message. It is often 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 queried prior to
identify the group when establishing a Re-key SA either implicitly
through an SPI or explicitly as an SA parameter.
6.2.3 Key encrypting key(s)
Corresponding key-management session
establishment to determine the key management algorithm, the Re-key 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 algorithm. When there are multiple KEKs initial cryptographic policies for a
group (as in an LKH tree), each KEK needs to be associated with a Key
ID, which is used to identify
that establishment. This document assumes the key needed to decrypt it. Each KEK
has existence of such a LIFETIME associated with it, after which the KEK expires.
6.2.4 Authentication key
repository and protocol for GCKS and member policy queries.
Internet Draft Group Key Management Architecture [PAGE 23]
Baugher, Canetti, Dondeti, Lindholm June September 2003
The GCKS provides a symmetric or public key for authentication of its
Re-key messages. Symmetric-key authentication is appropriate only
when all
Thus group members can security policy will be trusted not to impersonate the GCKS. represented in a policy repository
and accessible using a policy protocol.
The group key management architecture does not rule out methods for deriving symmetric
authentication keys assumes that at least the member [RFC2409] rather than being pushed
from the GCKS.
6.2.5 Replay protection
following group-policy information
Re-key messages need to be protected from replay/reflection attacks.
Sequence numbers are used for this purpose is externally managed.
o Group owner, authentication method, and the Re-key SA (or
protocol) contains this information.
6.2.6 Security Parameter Index (SPI)
The triple (Group identity, SPI, an identifier delegation method for "Re-key SA")
uniquely identifies an SA. The SPI changes each time the KEKs
change.
6.3 Contents of the Data SA
The
identifying a GCKS specifies for the Data Security protocol group
o Group GCKS, authentication method, and any method used for secure
transmission of data from sender(s)
delegating other GCKSs for the group
o Group membership rules or list and authentication method
There are also two additional policy-related requirements external to receiving members. Examples
of Data Security protocols include IPsec ESP, SRTP, MESP,
group key management.
o There is an authorization and AMESP.
While authentication infrastructure such
as X.509, SPKI, or pre-shared key scheme in accordance with the content of each of these protocols
group policy for a particular group.
o There is out of the scope of
this document, we list the information sent by an announcement mechanism for secure groups and events
that operates according to group policy for a particular group.
Group policy determines how the Registration
protocol (or the Re-key Protocol) to and Rekey protocols
initialize or update the Rekey and Data
SA.
6.3.1 Group identity SAs. The Group identity accompanies SA information when Data SAs are
initialized or re-keyed following sections
describe potential information sent by the GCKS for multiple groups the Rekey and
Data SAs. A member needs to have the information specified in a single invocation the
next sections to establish Rekey and Data SAs.
6.2 Contents of the Registration protocol or in a single Re-key message (see 4.2.2).
6.3.2 Source identity Rekey SA
The Rekey SA includes source identity information when protects the Group Owner
chooses to reveal Source identity to authorized members only. A
public channel such as announcement protocol is only appropriate when
there is no need Rekey protocol. It contains cryptographic
policy, Security Parameter Index (SPI) [RFC2401] to protect source or uniquely identify
an SA, replay protection information, and secret keys.
6.2.1 Rekey SA Policy
The GROUP KEY MANAGEMENT ALGORITHM represents the group identities.
6.3.3 Traffic encrypting key
Irrespective
revocation algorithm that enforces forward and backward access
control. Examples of key revocation algorithms include LKH, LKH+,
OFT, OFC and Subset Difference [RFC2627, OFT, CP00, LNN01]. The key
revocation algorithm could also be NULL. In that case, the Rekey SA
contains only one KEK, which serves as the group KEK. The Rekey
messages initialize or update Data Security Protocol used, SAs as usual. But, the GCKS supplies Rekey SA
itself can be updated (group KEK can be Rekeyed) when members join or
the TPKs (or information KEK is about to derive TPKs) used in secure data
transmission, source and group authentication.
6.3.4 Authentication key expire. Leave Rekeying is done by re-
initializing the Rekey SA through the Rekey Protocol.
Internet Draft Group Key Management Architecture [PAGE 24]
Baugher, Canetti, Dondeti, Lindholm June September 2003
Depending on the data-authentication method used by the Data Security
protocol, group key management may pass one or more keys, functions
(e.g., TESLA), or other parameters used for authenticating streams
The KEK ENCRYPTION ALGORITHM uses a standard encryption algorithm
such as 3DES or
files.
6.3.5 Sequence numbers AES. The GCKS passes sequence numbers when needed by the Data Security
protocol, for replay protection.
6.3.6 Security Parameter Index (SPI) KEK KEY LENGTH is also specified.
The AUTHENTICATION ALGORITHM uses digital signatures for GCKS sends provides an identifier as part
authentication (since all shared secrets are known to some or all
members of the Data SA contents group), or some symmetric secret in computing MACs for data security protocols
group authentication. Symmetric authentication provides weaker
authentication in that use an SPI or similar mechanism to
identify any group member can impersonate a particular
source. The AUTHENTICATION KEY LENGTH is also be specified.
The CONTROL GROUP ADDRESS is used for multicast transmission of Rekey
messages. This information is sent over the control channel such as
in an SA ANNOUNCEMENT protocol or keys within an SA.
6.3.7 Data SA policy call setup message. The Data SA parameters are specific degree to
which 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.
Generally, specification of source or control group authentication address is
mutually exclusive.
7.0 Scalability Considerations
Group communications protected is quite diverse. In commercial
teleconferencing, a multipoint control unit (MCU) may be used matter of group
policy.
The REKEY SERVER ADDRESS allows the registration server to
aggregate be a number
different entity from the server used for Rekey, such as for future
invocations 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 the Registration and end-to-end. Teleconferencing sessions tend to
have at most dozens of participants whereas video broadcast, which
uses multicast communications, Rekey protocols. If the
registration server and media on demand, which uses
unicast, the Rekey server are large-scale groups numbering hundreds to millions of
participants.
As described in two different entities,
the Requirements section above, registration server sends the group key
management architecture supports source-specific multicast. One-to-
many (single-sender) applications are well suited to source-specific
multicast, which tend to have large numbers Rekey servers address as part of participants and
problems with synchronization among
the participants. Flash crowds
are one manifestation of Rekey SA.
6.2.2 Group Identity
The Group identity accompanies the problem with synchronized participants
who make concurrent request for group data with concomitant requests
for secure group keys. Thus, a SA (payload) information as an
identifier if the specific group key management protocol
designed for single-source multicast applications must support large-
scale operation. The architecture described in this paper supports
large-scale operation through the following features.
Internet Draft Group Key Management Architecture [PAGE 25]
Baugher, Canetti, Dondeti, Lindholm June 2003
1. There is no need for a unicast exchange to provide data keys allows
multiple groups to a
security protocol for members who have previously-registered in the
particular group; data keys can be pushed in the Re-key protocol.
2. The Registration and Re-key protocols are separable to allow
flexibility initialized in how members get group secrets. A group can use a
smart-card based system in place single invocation of the
Registration protocol, for
example, to allow the Re-key protocol or multiple groups to be used with no back channel
for broadcast applications updated in a single
Rekey message. It is often much simpler to restrict each
Registration invocation to a single group; no such restriction is
necessary. There is always a need to identify the group when
establishing a Rekey SA either implicitly through an SPI or
explicitly as television conditional access
systems.
3. an SA parameter.
6.2.3 KEKs
Corresponding to the key management algorithm, the Rekey SA contains
one or more KEKs. The Registration and Re-key protocols support new keys,
algorithms, authorization infrastructures and authentication
mechanisms in GCKS holds the architecture. key encrypting keys of the
group, while the members receive keys following the specification of
the 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 authorization
infrastructure supports delegation, as does X.509 and SPKI, key needed to decrypt it. Each KEK
has a LIFETIME associated with it, after which the KEK expires.
6.2.4 Authentication Key
The GCKS
function provides a symmetric or public key for authentication of its
Rekey messages. Symmetric-key authentication is appropriate only
when all group members can be distributed as shown in Figure 3.
+----------------------------------------+
| +-------+ |
| | GCKS | |
| +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| +-------------+ |
| | | |
| v ... v |
| +-------+ +-------+ |
| | GCKS | | GCKS | |
| +-------+ +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| ... |
+----------------------------------------+
Figure 3: Hierarchically-organized Key Distribution trusted not to impersonate the GCKS.
Internet Draft Group Key Management Architecture [PAGE 26] 25]
Baugher, Canetti, Dondeti, Lindholm June September 2003
The first feature in the list allows fast keying of Data Security
protocols when architecture does not rule out methods for deriving symmetric
authentication keys at the member already belongs to [RFC2409] rather than being pushed
from the group. While this
is realistic for subscriber groups and customers of service providers
who offer content events, it may GCKS.
6.2.5 Replay Protection
Rekey messages need to be too restrictive protected from replay/reflection attacks.
Sequence numbers are used for applications
that allow member enrollment at this purpose and the Rekey SA (or
protocol) contains this information.
6.2.6 Security Parameter Index (SPI)
The triple, <Group identity, SPI, an identifier for Rekey SA>,
uniquely identifies an SA. The SPI changes each time the KEKs
change.
6.3 Contents of the event. Data SA
The recourse GCKS specifies the Data Security protocol used for handling member registration in secure
transmission of data from sender(s) to receiving members. Examples
of Data Security protocols include IPsec ESP, SRTP, and MESP. While
the context content of a "flash crowd" each of these protocols is
Figure 3, which will require out of the use scope of many GCKSs to accommodate this
document, we list the
load. 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 on information sent by the Registration protocol
instantiations of
(or the Group Key Management architecture Rekey Protocol) to determine
how effectively and securely initialize or update the architecture can operate Data SA.
6.3.1 Group Identity
The Group identity accompanies SA information when Data SAs are
initialized or Rekeyed for multiple groups in large-
scale environments such as source-specific multicast and video on
demand. Specifically, a single invocation of
the requirements for Registration protocol or in a Figure 3 configuration
must be determined single Rekey message.
6.3.2 Source Identity
The SA includes source identity information when the Group Owner
chooses to reveal Source identity to authorized members only. A
public channel such as the announcement protocol is only appropriate when
there is no need for additional protocols between to protect source or group identities.
6.3.3 Traffic Erotection Keys
Irrespective of the Data Security Protocol used, the GCKS designated by supplies
the Group Owner and GCKSs that have been
delegated TEKs or information to serve keys derive TEKs, used for data encryption.
6.3.4 Data Authentication Keys
Depending on behalf of the designated GCKS.
8.0 GKM protocolsÆ applicability
Several protocols for data-authentication method used by the Data Security
protocol, group key management have been proposed at the
IETF. A few of them are already RFCs may pass one or more keys, functions
(e.g., GKMP) and a few others
are on their way to become RFCs. Three protocols, viz., GDOI,
GSAKMP, MIKEY, are expected to become standards track RFCs. In this
section, we discuss the applicability of these protocols to real-
world applications.
A common theme to group key management protocols proposed at the IETF
is that they all facilitate "download" TESLA), or push of a common key from a
server to a member. The data security SA (or the rekey SA, where
applicable) is not negotiated, but unilaterally selected by the GCKS.
Key download must be protected from eavesdropping, and from active
attacks such as message modification, MiTM, and replay attacks.
Different protocols may use different mechanisms to provide these
security features, and not all may provide all features. Next,
operational environments have a number of expectations on key
distribution protocols. For example, the unicast key exchange
protocol, IKE, supports remote legacy authentication, and client
configuration (e.g., IP address assignment). The end goal is to
establish a data security SA and an optional rekey SA. Another
requirement is to finish in fewest round trips other parameters used for efficient
operation. Optionally, protocols may provide protection against
identity attacks and denial of service attacks. authenticating streams or
files.
Internet Draft Group Key Management Architecture [PAGE 27] 26]
Baugher, Canetti, Dondeti, Lindholm June September 2003
8.1 GDOI
GDOI is based on ISAKMP model of key establishment. In Phase 1, the
DOI field indicates
6.3.5 Sequence Numbers
The GCKS passes sequence numbers when needed by the nature Data Security
protocol, for SA synchronization and replay protection.
6.3.6 Security Parameter Index (SPI)
The GCKS may provide an identifier as part of the protocol, viz., group key
download. Other than Data SA contents
for data security protocols that there is no change use an SPI or similar mechanism to ISAKMP Phase 1;
using main/aggressive mode, a secure channel is established using
identify an
authenticated DH exchange. At the end of the exchange SA or keys within an IKE SA.
6.3.7 Data SA is
established. policy
The member is expected to request to join a group,
optionally prove its authorization Data SA parameters are specific to join the group, Data Security Protocol but
generally include encryption algorithm and prove the
liveness of the exchange. Under the protection of the IKE SA, the
GCKS downloads parameters, the rekey SA source
authentication algorithm and parameters, the data security SAs to the member.
GDOI has a rekey exchange to update the rekey group authentication
algorithm and parameters, and/or the data
security SAs. replay protection information.
7.0 Scalability Considerations
The data security SA can be an IPsec SA or an SRTP SA.
8.1.1 GDOI's Applicability:
GDOI area of group communications is similar to IKE, owing to the fact that both are derived from
ISAKMP. Thus any proposed/deployed/standardized extensions quite diverse. In
teleconferencing, a multipoint control unit (MCU) may be used to IKE
aggregate a number of teleconferencing members into a single session;
MCUs may generally work for GDOI be hierarchically organized as well. For example, GDOI supports the
use 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 pre-shared keys for end-point authentication, NAT traversal, participants whereas video broadcast, which
uses multicast communications, and client configuration. GDOI policy download capabilities media on demand, which uses
unicast, are
similar large-scale groups numbering hundreds to that millions of ISAKMP/IKE. In addition to IPsec policy,
participants.
As described in the GCKS
may download rekey SA and rekey algorithm (e.g., LKH, SDR) policy.
GDOI assumes that there is Requirements section above, the group key
management architecture supports multicast applications with a single GCKS that downloads
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 any
number of members. Multiple servers may a
security protocol for members who have previously-registered in the
particular group; data keys can be used pushed in the Rekey protocol.
2. The Registration and Rekey protocols are separable to provide allow
flexibility in how members get group secrets. A group can use a
smart-card based system in place of the GCKS
service, but they would all serve Registration protocol, for
example, to allow the same membership. Subordinate
GCKSs serving subgroups is not supported 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,
authorization infrastructures and authentication mechanisms in GDOI.
GDOI's Phase 1 provides all of the listed security features earlier;
however it requires too many round trips (Aggressive mode requires
1.5 + 2 round trips;
Internet Draft Group Key Management Architecture [PAGE 27]
Baugher, Canetti, Dondeti, Lindholm September 2003
architecture. When the authorization infrastructure supports
delegation, as in X.509 and main mode requires 3 + 2 round trips SPKI, the GCKS function can be
distributed as shown in Figure 3.
+----------------------------------------+
| +-------+ |
| | GCKS | |
| +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| +-------------+ |
| | | |
| v ... v |
| +-------+ +-------+ |
| | GCKS | | GCKS | |
| +-------+ +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| ... |
+----------------------------------------+
Figure 3: Hierarchically-organized Key Distribution
The first feature in
providing identity protection) compared to the other two protocols.
Some list allows fast keying of Data Security
protocols when the additional complexity is due member already belongs to the rich feature set;
however ISAKMPÆs model of establishing a secure tunnel before
downloading the rekey and data security SAs group. While this
is also responsible realistic for
the complexity.
8.2 GSAKMP
GSAKMP uses an authenticated (using digital signatures) DH exchange,
downloads keys and a policy token, subscriber groups and supports the concept customers of a
member ACK for auditing or billing purposes. The policy token can service providers
who offer content events, it may be
transformed into a data security SA, such as an IPsec SA (and perhaps
Internet Draft Group Key Management Architecture [PAGE 28]
Baugher, Canetti, Dondeti, Lindholm June 2003
an SRTP SA). GSAKMP assumes controlled operational environments and
supports DoS avoidance as an optional feature.
GSAKMP supports too restrictive for applications
that allow member enrollment at the concept of subordinate GCKSs and allows members
to be authorized as GCKSs. GSAKMP does not have provisions to
support PSKs and identity protection (active or passive). The policy
token needs to be translated into an IPsec SA, which is out of scope time of the document. GSAKMP requires fewer RTs compared to GDOI, and
allows members 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 designated as SGCKSs. GSAKMP requires only 1.5
round trips, however the efficiency comes at the expense of lack of
DoS protection needed when conventional
clustering and lack load-balancing solutions of support for legacy client authentication
methods.
8.2.1 tGSAKMP <to be added>
8.3 MIKEY
MIKEY provides a single message key download using preshared keys or
public keys. It is designed for peer-to-peer key download, or key
download for small one-many or many-to-many interactive groups. It
defines a registration SA central GCKS site cannot
meet customer requirements. Unlike conventional caching and a data content-
distribution networks, however, the configuration shown in Figure 3
Internet Draft Group Key Management Architecture [PAGE 28]
Baugher, Canetti, Dondeti, Lindholm September 2003
has additional security SA only; MIKEY does not
specify a rekey SA.
MIKEY also supports key download using DH exchange via ramifications for physical security of a single RTT
exchange. Replay protection is provided using timestamps,
GCKS.
More analysis and work needs to keep be done on the
latency low. MIKEY is specifically designed protocol
instantiations of the Group Key Management architecture to determine
how effectively and securely the architecture can operate in large-
scale environments such as video on demand. Specifically, the
requirements for multimedia call
setup, where low latency is a requirement. MIKEY cannot seem to Figure 3 configuration must be
sufficient determined such as
the need for general purpose group key management. GDOI or GSAKMP
should be used instead.
9.0 additional protocols between the GCKS designated by the
Group Owner and GCKSs that have been delegated to serve keys on
behalf of the designated GCKS.
8.0 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 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.
Internet Draft Group Key Management Architecture [PAGE 29]
Baugher, Canetti, Dondeti, Lindholm June 2003
This memo does not address attacks against key management or security
protocol implementations such as so-called "type attacks" 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 GCKS
should not be authenticated using shared symmetric secrets unless all
members of the group can be trusted not to impersonate the GCKS. GCKS or
each other. Similarly, members who disclose group secrets undermine
the security of the entire group. Group Owners and GCKS
administrators must be aware of these inherent limitations of group
key management.
Another limitation of group key management is policy complexity:
Whereas peer-to-peer security policy is an intersection of the policy
of the individual peers, a Group Owner sets group security policy
Internet Draft Group Key Management Architecture [PAGE 29]
Baugher, Canetti, Dondeti, Lindholm September 2003
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 trust, authenticity and confidentiality 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 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 Rekey protocol, is new
and has unknown risks associated with it. The source-authentication
risks describe 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
attacks based upon the use of multicast. The Re-key Rekey protocol
specification (see Appendix A for the drafts roadmap) needs to offer secure solutions to these problems.
Each instantiation of the Re-key Rekey protocol, such as the GSAKMP Re-key Rekey or
the GDOI Groupkey-push operations, need to validate the security of
their Re-key Rekey specifications.
Novelty and complexity are the biggest risks to group key management
protocols. Much more analysis and experience are needed to ensure
Internet Draft Group Key Management Architecture [PAGE 30]
Baugher, Canetti, Dondeti, Lindholm June 2003
that the architecture described in this document can provide a well-
articulate standard for security and risks of group key management.
9.0 Acknowledgments
The GKM Building Block [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, and several others provided valuable comments
that helped improve this document. The authors appreciate their
review of this document.
10.0 References and Bibliography
[AMESP] R. Bibliography
[BatchRekey] Yang, Y. R., et al., Reliable Group Rekeying: Design and
Performance Analysis, in Proc. of ACM SIGCOMM, San Diego, CA, August
2001.
Internet Draft Group Key Management Architecture [PAGE 30]
Baugher, 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. Dondeti, Lindholm September 2003
[CLIQUES] M. Steiner, G. Tsudik and M. Waidner, CLIQUES: A New
Approach to Group Key Agreement, IEEE ICDCS97, May 1997
[CP00] R. Canetti, B. Pinkas, A taxonomy of multicast security
issues, http://www.ietf.org/internet-drafts/draft-irtf-smug-
taxonomy-01.txt, Work in Progress, August 2000.
[FN93]A.
[FN93] A. Fiat, M. Naor, Broadcast Encryption, Advances in
Cryptology - CRYPTO Æ93 93 Proceedings, Lecture Notes in Computer
Science, Vol. 773, 1994, pp. 480û491.
[FS00] N. Ferguson and B. Schneier, A Cryptographic Evaluation of
IPsec, CounterPane, http://www.counterpane.com/ipsec.html.
[GDOI] 480 -- 491.
[GKMBB] Harney, H., M. Baugher, and T. Hardjono, H. Harney, B. Weis, The Hardjono., GKM Building
Block: Group Domain
of Interpretation, http://www.ietf.org/internet-drafts/draft-ietf-
msec-gdoi-08.txt, May 2003, Work in Progress. Security Association (GSA) Definition, draft-irtf-smug-
gkmbb-gsadef-01.txt, Sep 2000, Expired.
[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-
http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-msec-gsakmp-sec-
01.txt, February 2003, Work in Progress.
[GSPT] Hardjono, T., H. Harney, P. McDaniel, A. Colegrove, and P.
Dinsmore, The MSEC Group Security Policy Token, draft-ietf-msec-gspt-
02.txt, August 2003, Work in Progress.
[H.235] ITU, Security and encryption for H-Series (H.323 and other
H.245-based) multimedia terminals, ITU-T Recommendation H.235 Version
3, 2001, Work in progress.
[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.
[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.
[MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K.
Norrman, "MIKEY: Multimedia Internet KEYing", Internet Draft,
http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-06.txt,
February 2003,
[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. Progress,
2001.
[MARKS] B. Briscoe, B., MARKS: Zero Side Effect Multicast Key
Management
using Using Arbitrarily Revealed Key Sequences, Proceedings in Proc. of NGC'99,
rbriscoe@bt.co.uk.
First International Workshop on Networked Group Communication (NGC),
Pisa, Italy, November 1999.
[MESP] Baugher, M., R. Canetti, P. Cheng, and P. Rohatgi, MESP:
Multicast Encapsulating Security Payload, Internet Draft,
Internet Draft Group Key Management Architecture [PAGE 31]
Baugher, Canetti, Dondeti, Lindholm June September 2003
[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
http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-msec-mesp-
00.txt, October 2002, Work in Progress.
[MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and Phonograms Treaty (WPPT), World Intellectual
Property Organization, Geneva, December 6 K.
Norrman, 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.
[MSEC-Arch] T. Hardjono, and 7, 1999
(http://www.wipo.org/eng/meetings/1999/wct_wppt/pdf/imp99_3.pdf). B. Weis, The Multicast Security
Architecture, Internet Draft, http://www.ietf.org/internet-
drafts/draft-ietf-msec-arch-03.txt, August 2003, Work in progress.
[MVV] A.J.Menzes, P.C.van Oorschot, S.A. Vanstone, Handbook of
Applied Cryptography, CRC Press, 1996.
[OFT] D. Balenson, D., D. McGrew, and 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. draft-irtf-smug-groupkeymgmt-oft-00.txt, IRTF, August
2000, Work in progress.
[RFC2093] Harney, H., and C. Muckenhirn, C., "Group Group Key Management
Protocol (GKMP) Specification," Specification, RFC 2093, 2093 (experimental), July 1997.
[RFC2094] Harney, H., and C. Muckenhirn, C., "Group Group Key Management
Protocol (GKMP) Architecture," Architecture, RFC 2094, 2094 (experimental), July 1997.
[RFC2326] ftp://ftp.isi.edu/in-notes/rfc2326.txt Schulzrinee, H., A. Rao, and R. Lanphier, Real Time
Streaming Protocol (RTSP), RFC 2326 (Proposed Standard), April 1998.
[RFC2327] M. Handley, M., and V. Jacobson, SDP: Session Description
Protocol, RFC 2327 (Proposed Standard), April 1998.
[RFC2367] D. McDonald, D., C. Metz, and B. Phan, PF_KEY Key Management
API, Version 2, RFC 2367 (Informational), July 1998.
[RFC2401] S. Kent, S., and R. Atkinson, Security Architecture for the
Internet Protocol, RFC 2401 (proposed standard), November 1998 1998.
[RFC2406] S. Kent, S., and R. Atkinson, IP Encapsulating Security
Payload (ESP), November 1998.
[RFC2407] D. Piper, The Internet IP Domain of Interpretation for
ISAKMP, RFC 2406 (proposed standard), November 1998.
[RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, D., et al., Internet Security Association and Key
Management Protocol, Protocol (ISAKMP), RFC 2408 (proposed standard), November
1998.
[RFC2409] D. Harkins, D., and D. Carrel, The Internet Key Exchange
(IKE),
November, RFC 2409 (proposed standard), November 1998.
[RFC2412] H. Orman, The OAKLEY Key Determination Protocol, RFC 2412
(Informational), November 1998.
Internet Draft Group Key Management Architecture [PAGE 32]
Baugher, Canetti, Dondeti, Lindholm June September 2003
[RFC2522] P. Karn, P., and W. Simpson, Photuris: Session-Key Management
Protocol, RFC 2522 (Informational), March 1999.
[RFC2543] ftp://ftp.isi.edu/in-notes/rfc2543.txt Handley, M., et. al., SIP: Session Initiation Protocol,
RFC 2543 (Proposed Standard), March 1999.
[RFC2627] D. M. Wallner, D., E. Harder, and R. C. Agee, Key Management for
Multicast: Issues and Architectures, September 1998. RFC 2627(informational), IETF,
June 1999.
[RFC3547] M. Baugher, T. Hardjono, H. Harney, B. Weis, The Group
Domain of Interpretation, RFC 3547 (Proposed Standard), July 2003.
[RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP:
A Transport Protocol for Real-Time Applications, RFC 3550 (Proposed
Standard), July 2003.
[SD] Naor, D., M. Naor, and J. Lotspiech, Revocation and Tracing
Schemes for Stateless Receivers, in Advances in Cryptology - CRYPTO,
Santa Barbara, CA: Springer-Verlag Inc., LNCS 2139, August 2001.
[Self-Healing] Staddon, J., et. al., Self-healing Key Distribution
with Revocation, In proceedings of the 2002 IEEE Symposium on
Security and Privacy, Oakland, CA, May 2002.
[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, Baugher, M., et. al., The Secure Real Time Transport
Protocol,
http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-00.txt,
February 2001, http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-avt-
srtp-05.txt, December 2002, Work in Progress.
[TESLA-INFO] Perrig, A., R. Canetti, D. Song, D. Tygar, and B.
Briscoe, TESLA: Multicast Source Authentication Transform
Introduction, http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-
msec-tesla-intro-01.txt, October 2002, Work in Progress.
[TESLA-SPEC] Perrig, A., R. Canetti, and Whillock, TESLA: Multicast
Source Authentication Transform Specification,
http://www.ietf.org/proceedings/03mar/I-D/draft-ietf-msec-tesla-spec-
00.txt, April 2002, Work in Progress.
Internet Draft Group Key Management Architecture [PAGE 33]
Baugher, Canetti, Dondeti, Lindholm June September 2003
[tGSAKMP] Harney, H., et. al., Tunneled Group Secure Association Key
Management Protocol, http://www.ietf.org/internet-drafts/draft-ietf-
msec-tgsakmp-00.txt, May 2003, Work in Progress.
[TPM] 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).
[Wool] Wool. A., Key Management for Encrypted broadcast, 5th ACM
Conference on Computer and Communications Security, San Francisco,
CA, Nov. 1998.
Internet Draft Group Key Management Architecture [PAGE 34]
Baugher, Canetti, Dondeti, Lindholm September 2003
11.0 Authors' Authors Addresses
Mark Baugher
Cisco Systems
5510 SW Orchid St.
Portland, OR 97219, USA
+1 408-853-4418
mbaugher@cisco.com
Ran Canetti
IBM Research
30 Saw Mill River Road
Hawthorne, NY 10532, USA
+1 914-784-7076
canetti@watson.ibm.com
Lakshminath R. Dondeti
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821, USA
+1 978-288-6406
ldondeti@nortelnetworks.com
Fredrik Lindholm
Ericsson Research
SE-16480 Stockholm, Sweden
+46 8 58531705
fredrik.lindholm@era.ericsson.se
fredrik.lindholm@ericsson.com
Internet Draft Group Key Management Architecture [PAGE 34] 35]
Baugher, Canetti, Dondeti, Lindholm June September 2003
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 REKEY |-: | TBD |-:
| | : | | :
+------------+ : +------------+ :
: :
. .
. .
FIGURE A: Graphic rendition of the inter-relations between the I-D's I-Ds
of MSEC. Note that some of these drafts are still in the process of
being written.
Internet Draft Group Key Management Architecture [PAGE 35] 36]
----