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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/