operation. To protect against such an attack, a MAC may be sent as
part of the rekey message. Members verify the signature only upon
successful verification of the MAC.
Rekey messages contain group key updates corresponding to a single
[RFC2627,OFT] or multiple membership changes [SD1,SD2,BatchRekey] and
may contain group key initialization messages [OFT].
5.3. Reliable Transport of Rekey Messages
The GCKS must ensure that all members have the current Data Security
and Rekey SAs. Otherwise, authorized members may be inadvertently
excluded from receiving group communications. Thus, the GCKS needs
to use a rekey algorithm that is inherently reliable or employ a
reliable transport mechanism to send rekey messages.
There are two dimensions to the problem. Messages that update group
keys may be lost in transit or may be missed by a host when it is
offline. LKH and OFT group key management algorithms rely on past
history of updates being received by the host. If the host goes
offline, it will need to resynchronize its group-key state when it
comes online; this may require a unicast exchange with the GCKS. The
Subset Difference algorithm, however, conveys all the necessary state
in its rekey messages and does not need members to be always online
or keeping state. The Subset Difference algorithm does not require a
back channel and can operate on a broadcast network. If a rekey
message is lost in transmission, the Subset Difference algorithm
cannot decrypt messages encrypted with the TPK sent via the lost
rekey message. There are self-healing GKMAs proposed in the
literature that allow a member to recover lost rekey messages, as
long as rekey messages before and after the lost rekey message are
received.
Rekey messages are typically short (for single membership change as
well as for small groups), which makes it easy to design a reliable
delivery protocol. On the other hand, the security requirements may
add an additional dimension to address. There are some special cases
in which membership changes are processed as a batch, reducing the
frequency of rekey messages but increasing their size. Furthermore,
among all the KEKs sent in a rekey message, as many as half the
members need only a single KEK. We may take advantage of these
properties in designing a rekey message(s) and a protocol for their
reliable delivery.
Three categories of solutions have been proposed:
1. Repeatedly transmit the rekey message. In many cases rekey
messages translate to only one or two IP packets.
2. Use an existing reliable multicast protocol/infrastructure.
3. Use FEC for encoding rekey packets (with NACKs as feedback)
[BatchRekey].
Note that for small messages, category 3 is essentially the same as
category 1.
The group member might be out of synchrony with the GCKS if it
receives a rekey message having a sequence number that is more than
one greater than the last sequence number processed. This is one
means by which the GCKS member detects that it has missed a rekey
message. Alternatively, the data-security application, upon
detecting that it is using an out-of-date key, may notify the group
key management module. The action taken by the GCKS member is a
matter of group policy. The GCKS member should log the condition and
may contact the GCKS to rerun the re-registration protocol to obtain
a fresh group key. The group policy needs to take into account
boundary conditions, such as reordered rekey messages when rekeying
is so frequent that two messages might get reordered in an IP
network. The group key policy also needs to take into account the
potential for denial of service attacks where an attacker delays or
deletes a rekey message in order to force a subnetwork or subset of
the members to simultaneously contact the GCKS.
If a group member becomes out-of-synch with the GSA then it should
re-register with the GCKS. However, in many cases there are other,
simpler methods for re-synching with the group:
o The member can open a simple unprotected connection (e.g., TCP)
with the GCKS and obtain the current (or several recent) rekey
messages. Note that there is no need for authentication or
encryption here, since the rekey message is already signed and
is multicast in the clear. One may think that this opens the
GCKS to DoS attacks by many bogus such requests. This,
however, does not seem to worsen the situation; in fact,
bombarding the GCKS with bogus resynch requests would be much
more problematic.
o The GCKS can post the rekey messages on some public site (e.g.,
a web site) and the out-of-synch member can obtain the rekey
messages from that site.
The GCKS may always provide all three ways of resynching (i.e., re-
registration, simple TCP, and public posting). This way, the member
may choose how to resynch; it also avoids adding yet another field to
the policy token [GSPT]. Alternatively, a policy token may contain a
field specifying one or more methods supported for resynchronization
of a GSA.
5.4. State-of-the-art on Reliable Multicast Infrastructure
The rekey message may be sent using reliable multicast. There are
several types of reliable multicast protocols with different
properties. However, there are no standards track reliable multicast
protocols published at this time, although IETF consensus has been
reached on two protocols that are intended to go into the standards
track [NORM,RFC3450]. Thus, this document does not recommend a
particular reliable multicast protocol or set of protocols for the
purpose of reliable group rekeying. The suitability of NAK-based,
ACK-based or other reliable multicast methods is determined by the
application needs and operational environment. In the future, group
key management protocols may choose to use particular standards-based
approaches that meet the needs of the particular application. A
secure announcement facility may be needed to signal the use of a
reliable multicast protocol, which could be specified as part of
group policy. The reliable multicast announcement and policy
specification, however, can only follow the establishment of reliable
multicast standards and are not considered further in this document.
Today, the several MSEC group key management protocols support
sequencing of the rekey messages through a sequence number, which is
authenticated along with the rekey message. A sender of rekey
messages may re-transmit multiple copies of the message provided that
they have the same sequence number. Thus, re-sending the message is
a rudimentary means of overcoming loss along the network path. A
member who receives the rekey message will check the sequence number
to detect duplicate and missing rekey messages. The member receiver
will discard duplicate messages that it receives. Large rekey
messages, such as those that contain LKH or OFT tree structures,
might benefit from transport-layer FEC in the future, when
standards-based methods become available. It is unlikely that
forward error correction (FEC) methods will benefit short rekey
messages that fit within a single message. In this case, FEC
degenerates to simple retransmission of the message.
5.5. Implosion
Implosion may occur due to one of two reasons. First, recall that
one of the goals of the rekey protocol is to synchronize a GSA. When
a rekey or Data SA expires, members may contact the GCKS for an
update. If all, or even many, members contact the GCKS at about the
same time, the GCKS might not be able to handle all those messages.
We refer to this as an out-of-sync implosion.
The second case is in the reliable delivery of rekey messages.
Reliable multicast protocols use feedback (NACK or ACK) to determine
which packets must be retransmitted. Packet losses may result in
many members sending NACKs to the GCKS. We refer to this as feedback
implosion.
The implosion problem has been studied extensively in the context of
reliable multicasting. The proposed feedback suppression and
aggregation solutions might be useful in the GKM context as well.
Members may wait a random time before sending an out-of-sync or
feedback message. Meanwhile, members might receive the necessary key
updates and therefore not send a feedback message. An alternative
solution is to have the members contact one of several registration
servers when they are out-of-sync. This requires GSA synchronization
between the multiple registration servers.
Feedback aggregation and local recovery employed by some reliable
multicast protocols are not easily adaptable to transport of rekey
messages. Aggregation raises authentication issues. Local recovery
is more complex because members need to establish SAs with the local
repair server. Any member of the group or a subordinate GCKS may
serve as a repair server, which can be responsible for resending
rekey messages.
Members may use the group SA, more specifically the Rekey SA, to
authenticate requests sent to the repair server. However, replay
protection requires maintaining state at members as well as repair
servers. Authentication of repair requests is meant to protect
against DoS attacks. Note also that an out-of-sync member may use an
expired Rekey SA to authenticate repair requests, which requires
repair servers to accept messages protected by old SAs.
Alternatively, a simple mechanism may be employed to achieve local
repair efficiently. Each member receives a set of local repair
server addresses as part of group operation policy information. When
a member does not receive a rekey message, it can send a "Retransmit
replay message(s) with sequence number n and higher" message to one
of the local repair servers. The repair server can either ignore the
request if it is busy or retransmit the requested rekey messages as
received from the GCKS. The repair server, which is also another
member may choose to serve only m requests in a given time period
(i.e., rate limits responses) or per a given rekey message. Rate
limiting the requests and responses protects the repair servers as
well as other members of the group from DoS attacks.
5.6. Incorporating Group Key Management Algorithms
Group key management algorithms make rekeying scalable. Large group
rekeying without employing GKMAs is prohibitively expensive.
Following are some considerations in selecting a GKMA:
o Protection against collusion.
Members (or non-members) should not be able to collaborate to
deduce keys for which they are not privileged (following the
GKMA key distribution rules).
o Forward access control
The GKMA should ensure that departing members cannot get access
to future group data.
o Backward access control
The GKMA should ensure that joining members cannot decrypt past
data.
5.7. Stateless, Stateful, and Self-healing Rekeying Algorithms
We classify group key management algorithms into three categories:
stateful, stateless, and self-healing.
Stateful algorithms [RFC2627,OFT] use KEKs from past rekeying
instances to encrypt (protect) KEKs corresponding to the current and
future rekeying instances. The main disadvantage in these schemes is
that if a member were offline or otherwise failed to receive KEKs
from a past rekeying instance, it may no longer be able to
synchronize its GSA even though it can receive KEKs from all future
rekeying instances. The only solution is to contact the GCKS
explicitly for resynchronization. Note that the KEKs for the first
rekeying instance are protected by the Registration SA. Recall that
communication in that phase is one to one, and therefore it is easy
to ensure reliable delivery.
Stateless GKMAs [SD1,SD2] encrypt rekey messages with KEKs sent
during the registration protocol. Since rekey messages are
independent of any past rekey messages (i.e., that are not protected
by KEKs therein), a member may go offline but continue to decipher
future communications. However, stateless GKMAs offer no mechanisms
to recover past rekeying messages. Stateless rekeying may be
relatively inefficient, particularly for immediate (not batch)
rekeying in highly dynamic groups.
In self-healing schemes [Self-Healing], a member can reconstruct a
lost rekey message as long as it receives some past and some future
rekey messages.
5.8. Interoperability of a GKMA
Most GKMA specifications do not specify packet formats, although many
group key management algorithms need format specification for
interoperability. There are several alternative ways to manage key
trees and to number nodes within key trees. The following
information is needed during initialization of a Rekey SA or included
with each GKMA packet.
o GKMA name (e.g., LKH, OFT, Subset Difference)
o GKMA version number (implementation specific). Version may
imply several things such as the degree of a key tree,
proprietary enhancements, and qualify another field such as a
key ID.
o Number of keys or largest ID
o Version-specific data
o Per-key information:
- key ID,
- key lifetime (creation/expiration data) ,
- encrypted key, and
- encryption key’s ID (optional).
Key IDs may change in some implementations in which case one needs to
send:
o List of <old id, new id> pairs.
6. Group Security Association
The GKM architecture defines the interfaces between the registration,
rekey, and data security protocols in terms of the Security
Associations (SAs) of those protocols. By isolating these protocols
behind a uniform interface, the architecture allows implementations
to use protocols best suited to their needs. For example, a rekey
protocol for a small group could use multiple unicast transmissions
with symmetric authentication, while a rekey protocol for a large
group could use IP Multicast with packet-level Forward Error
Correction and source authentication.
The group key management architecture provides an interface between
the security protocols and the group SA (GSA). The GSA consists of
three SAs: Registration SA, Rekey SA, and Data SA. The Rekey SA is
optional. There are two cases in defining the relationships between
the three SAs. In both cases, the Registration SA protects the
registration protocol.
Case 1: Group key management is done WITHOUT using a Rekey SA. The
registration protocol initializes and updates one or more Data SAs
(having TPKs to protect files or streams). Each Data SA
corresponds to a single group, which may have more than one Data
SA.
Case 2: Group key management is done WITH a Rekey SA to protect the
rekey protocol. The registration protocol initializes the one or
more Rekey SAs as well as zero or more Data SAs, upon successful
completion. When a Data SA is not initialized in the registration
protocol, initialization is done in the rekey protocol. The rekey
protocol updates Rekey SA(s) AND establishes Data SA(s).
6.1. Group Policy
Group policy is described in detail in the Group Security Policy
Token document [GSPT]. Group policy can be distributed through group
announcements, key management protocols, and other out-of-band means
(e.g., via a web page). The group key management protocol carries
cryptographic policies of the SAs and the keys it establishes, as
well as additional policies for the secure operation of the group.
The acceptable cryptographic policies for the registration protocol,
which may run over TLS [TLS], IPsec, or IKE, are not conveyed in the
group key management protocol since they precede any of the key
management exchanges. Thus, a security policy repository having some
access protocol may need to be queried prior to establishing the
key-management session, to determine the initial cryptographic
policies for that establishment. This document assumes the existence
of such a repository and protocol for GCKS and member policy queries.
Thus group security policy will be represented in a policy repository
and accessible using a policy protocol. Policy distribution may be a
push or a pull operation.
The group key management architecture assumes that the following
group policy information may be externally managed, e.g., by the
content owner, group conference administrator or group owner:
o the identity of the Group owner, the authentication method, and
the delegation method for identifying a GCKS for the group;
o the group GCKS, authentication method, and delegation method
for any subordinate GCKSs for the group;
o the group membership rules or list and authentication method.
There are two additional policy-related requirements external to
group key management.
o There is an authentication and authorization infrastructure
such as X.509 [RFC3280], SPKI [RFC2693], or a pre-shared key
scheme, in accordance with the group policy for a particular
group.
o There is an announcement mechanism for secure groups and
events, which operates according to group policy for a
particular group.
Group policy determines how the registration and rekey protocols
initialize or update Rekey and Data SAs. The following sections
describe potential information sent by the GCKS for the Rekey and
Data SAs. A member needs the information specified in the next
sections to establish Rekey and Data SAs.
6.2. Contents of the Rekey SA
The Rekey SA protects the rekey protocol. It contains cryptographic
policy, Group Identity, and Security Parameter Index (SPI) [RFC2401]
to uniquely identify an SA, replay protection information, and key
protection keys.
6.2.1. Rekey SA Policy
o GROUP KEY MANAGEMENT ALGORITHM
This represents the group key revocation algorithm that
enforces forward and backward access control. Examples of key
revocation algorithms include LKH, LKH+, OFT, OFC, and Subset
Difference [RFC2627,OFT,TAXONOMY,SD1,SD2]. If the key
revocation algorithm is NULL, the Rekey SA contains only one
KEK, which serves as the group KEK. The rekey messages
initialize or update Data SAs as usual. However, the Rekey SA
itself can be updated (the group KEK can be rekeyed) when
members join or the KEK is about to expire. Leave rekeying is
done by re-initializing the Rekey SA through the rekey
protocol.
o KEK ENCRYPTION ALGORITHM
This specifies a standard encryption algorithm such as 3DES or
AES, and also the KEK KEY LENGTH.
o AUTHENTICATION ALGORITHM
This algorithm uses digital signatures for GCKS authentication
(since all shared secrets are known to some or all members of
the group), or some symmetric secret in computing MACs for
group authentication. Symmetric authentication provides weaker
authentication in that any group member can impersonate a
particular source. The AUTHENTICATION KEY LENGTH is also to be
specified.
o CONTROL GROUP ADDRESS
This address is used for multicast transmission of rekey
messages. This information is sent over the control channel
such as in an ANNOUNCEMENT protocol or call setup message. The
degree to which the control group address is protected is a
matter of group policy.
o REKEY SERVER ADDRESS
This address allows the registration server to be a different
entity from the server used for rekeying, such as for future
invocations of the registration and rekey protocols. If the
registration server and the rekey server are two different
entities, the registration server sends the rekey server’s
address as part of the Rekey SA.
6.2.2. Group Identity
The group identity accompanies the SA (payload) information as an
identifier if the specific group key management protocol allows
multiple groups to be initialized in a single invocation of the
registration protocol, or multiple groups to be updated in a single
rekey message. It is often simpler to restrict each registration
invocation to a single group, but such a restriction is unnecessary.
It is always necessary to identify the group when establishing a
Rekey SA, either implicitly through an SPI or explicitly as an SA
parameter.
6.2.3. KEKs
Corresponding to the key management algorithm, the Rekey SA contains
one or more KEKs. The GCKS holds the key encrypting keys of the
group, while the members receive keys following the specification of
the key management algorithm. When there are multiple KEKs for a
group (as in an LKH tree), each KEK needs to be associated with a Key
ID, which is used to identify the key needed to decrypt it. Each KEK
has a LIFETIME associated with it, after which the KEK expires.
6.2.4. Authentication Key
The GCKS provides a symmetric or public key for authentication of its
rekey messages. Symmetric key authentication is appropriate only
when all group members can be trusted not to impersonate the GCKS.
The architecture does not rule out methods for deriving symmetric
authentication keys at the member [RFC2409] rather than pushing them
from the GCKS.
6.2.5. Replay Protection
Rekey messages need to be protected from replay/reflection attacks.
Sequence numbers are used for this purpose, and the Rekey SA (or
protocol) contains this information.
6.2.6. Security Parameter Index (SPI)
The tuple <Group identity, SPI> uniquely identifies a Rekey SA. The
SPI changes each time the KEKs change.
6.3. Contents of the Data SA
The GCKS specifies the data security protocol used for secure
transmission of data from sender(s) to receiving members. Examples
of data security protocols include IPsec ESP [RFC2401] and SRTP
[RFC3711]. While the contents of each of these protocols are out of
the scope of this document, we list the information sent by the
registration protocol (or the rekey protocol) to initialize or update
the Data SA.
6.3.1. Group Identity
The Group identity accompanies SA information when Data SAs are
initialized or rekeyed for multiple groups in a single invocation of
the registration protocol or in a single Rekey message.
6.3.2. Source Identity
The SA includes source identity information when the group owner
chooses to reveal source identity to authorized members only. A
public channel such as the announcement protocol is only appropriate
when there is no need to protect source or group identities.
6.3.3. Traffic Protection Keys
Regardless of the data security protocol used, the GCKS supplies the
TPKs, or information to derive TPKs for traffic protection.
6.3.4. Data Authentication Keys
Depending on the data authentication method used by the data security
protocol, group key management may pass one or more keys, functions
(e.g., TESLA [TESLA-INFO,TESLA-SPEC]), or other parameters used for
authenticating streams or files.
6.3.5. Sequence Numbers
The GCKS passes sequence numbers when needed by the data security
protocol, for SA synchronization and replay protection.
6.3.6. Security Parameter Index (SPI)
The GCKS may provide an identifier as part of the Data SA contents
for data security protocols that use an SPI or similar mechanism to
identify an SA or keys within an SA.
6.3.7. Data SA policy
The Data SA parameters are specific to the data security protocol but
generally include encryption algorithm and parameters, the source