| | | | | | | |
| | +-----------------+ +-----------------+ | |
| | | ^ | |
| | v | | |
| | +-------DATA SECURITY PROTOCOL-------+ | |
| | | |
| +--------------------------------------------------------------+ |
| |
+------------------------------------------------------------------+
Figure 1: Group Security Association Model
There are a few distinct outcomes to a successful registration
Protocol exchange.
o If the GCKS uses rekey messages, then the admitted member
receives the Rekey SA. The Rekey SA contains the group’s rekey
policy (note that not all of the policy need to be revealed to
members), and at least a group KEK. In addition, the GCKS
sends a group key integrity key for integrity protection of
rekey messages. If a group key management algorithm is used
for efficient rekeying, the GCKS also sends one or more KEKs as
specified by the key distribution policy of the group key
management algorithm.
o If rekey messages are not used for the Group, then the admitted
member receives TPKs (as part of the Data Security SAs) that
are passed to the member’s Data Security Protocol (as IKE does
for IPsec).
o The GCKS may pass one or more TPKs to the member even if rekey
messages are used, for efficiency reasons and according to
group policy.
The GCKS creates the KEK and TPKs and downloads them to each member,
as the KEK and TPKs are common to the entire group. The GCKS is a
separate logical entity that performs member authentication and
authorization according to the group policy that is set by the group
owner. The GCKS may present a credential signed by the group owner
to the group member, so that member can check the GCKS’s
authorization. The GCKS, which may be co-located with a member or be
physically separate, runs the rekey protocol to push rekey messages
containing refreshed KEKs, new TPKs, and/or refreshed TPKs to
members. Note that some group key management algorithms refresh any
of the KEKs (potentially), whereas others only refresh the group KEK.
Alternatively, the sender may forward rekey messages on behalf of the
GCKS when it uses a credential mechanism that supports delegation.
Thus, it is possible for the sender, or other members, to source
keying material (TPKs encrypted in the Group KEK) as it sources
multicast or unicast data. As mentioned above, the rekey message can
be sent using unicast or multicast delivery. Upon receipt of a TPK
(as part of a Data SA) via a rekey message or a registration protocol
exchange, the member’s group key management functional block will
provide the new or updated security association (SA) to the data
security protocol. This protects the data sent from sender to
receiver.
The Data SA protects the data sent on the arc labeled DATA SECURITY
PROTOCOL shown in Figure 1. A second SA, the Rekey SA, is optionally
established by the key management protocol for rekey messages as
shown in Figure 1 by the arc labeled REKEY PROTOCOL. The rekey
message is optional because all keys, KEKs and TPKs, can be delivered
by the registration protocol exchanges shown in Figure 1, and those
keys may not need to be updated. The registration protocol is
protected by a third, unicast, SA between the GCKS and each member.
This is called the Registration SA. There may be no need for the
Registration SA to remain in place after the completion of the
registration protocol exchanges. The de-registration protocol may be
used when explicit teardown of the SA is desirable (such as when a
phone call or conference terminates). The three SAs compose the GSA.
The only optional SA is the Rekey SA.
Figure 1 shows two blocks that are external to the group key
management protocol: The policy and authorization infrastructures
are discussed in Section 6.1. The Multicast Security Architecture
document further clarifies the SAs and their use as part of the
complete architecture of a multicast security solution [MSEC-Arch].
3.3. Properties of the Design
The design of Section 3.2 achieves scalable operation by (1) allowing
the de-coupling of authenticated key exchange in a registration
protocol from a rekey protocol, (2) allowing the rekey protocol to
use unicast push or multicast distribution of group and data keys as
an option, (3) allowing all keys to be obtained by the unicast
registration protocol, and (4) delegating the functionality of the
GCKS among multiple entities, i.e., to permit distributed operation
of the GCKS.
High-capacity operation is obtained by (1) amortizing
computationally-expensive asymmetric cryptography over multiple data
keys used by data security protocols, (2) supporting multicast
distribution of symmetric group and data keys, and (3) supporting key
revocation algorithms such as LKH [RFC2627,OFT,SD1,SD2] that allow
members to be added or removed at logarithmic rather than linear
space/time complexity. The registration protocol may use asymmetric
cryptography to authenticate joining members and optionally establish
the group KEK. Asymmetric cryptography such as Diffie-Hellman key
agreement and/or digital signatures are amortized over the life of
the group KEK. A Data SA can be established without the use of
asymmetric cryptography; the TPKs are simply encrypted in the
symmetric KEK and sent unicast or multicast in the rekey protocol.
The design of the registration and rekey protocols is flexible. The
registration protocol establishes a Rekey SA or one or more Data SAs
or both types of SAs. At least one of the SAs is present (otherwise,
there is no purpose to the Registration SA). The Rekey SA may update
the Rekey SA, or establish or update one or more Data SAs.
Individual protocols or configurations may use this flexibility to
obtain efficient operation.
3.4. Group Key Management Block Diagram
In the block diagram of Figure 2, group key management protocols run
between a GCKS and member principal to establish a Group Security
Association (GSA). The GSA consists of a Data SA, an optional Rekey
SA, and a Registration SA. The GCKS may use a delegated principal,
such as the sender, which has a delegation credential signed by the
GCKS. The Member of Figure 2 may be a sender or receiver of
multicast or unicast data. There are two functional blocks in Figure
2 labeled GKM, and there are two arcs between them depicting the
group key-management registration (reg) and rekey (rek) protocols.
The message exchanges are in the GSA establishment protocols, which
are the registration protocol and the rekey protocol described above.
Figure 2 shows that a complete group-key management functional
specification includes much more than the message exchange. Some of
these functional blocks and the arcs between them are peculiar to an
operating system (OS) or vendor product, such as vendor
specifications for products that support updates to the IPsec
Security Association Database (SAD) and Security Policy Database
(SPD) [RFC2367]. Various vendors also define the functions and
interface of credential stores, CRED in Figure 2.
+----------------------------------------------------------+
| |
| +-------------+ +------------+ |
| | CONTROL | | CONTROL | |
| +------^------+ +------|-----+ +--------+ |
| | | +-----| CRED | |
| | | | +--------+ |
| +----v----+ +----v--v-+ +--------+ |
| | <-----Reg-----> |<->| SAD | |
| | GKM -----Rek-----> GKM | +--------+ |
| | | | | +--------+ |
| | ------+ | |<->| SPD | |
| +---------+ | +-^-------+ +--------+ |
| +--------+ | | | | |
| | CRED |----->+ | | +-------------------+ |
| +--------+ | | +--------------------+ | |
| +--------+ | +-V-------+ +--------+ | | |
| | SAD <----->+ | |<->| SAD <-+ | |
| +--------+ | |SECURITY | +--------+ | |
| +--------+ | |PROTOCOL | +--------+ | |
| | SPD <----->+ | |<->| SPD <----+ |
| +--------+ +---------+ +--------+ |
| |
| (A) GCKS (B) MEMBER |
+----------------------------------------------------------+
Figure 2: Group Key Management Block in a Host
The CONTROL function directs the GCKS to establish a group, admit a
member, or remove a member, or it directs a member to join or leave a
group. CONTROL includes authorization that is subject to group
policy [GSPT] but its implementation is specific to the GCKS. For
large scale multicast sessions, CONTROL could perform session
announcement functions to inform a potential group member that it may
join a group or receive group data (e.g., a stream of file transfer
protected by a data security protocol). Announcements notify group
members to establish multicast SAs in advance of secure multicast
data transmission. Session Description Protocol (SDP) is one form
that the announcements might take [RFC2327]. The announcement
function may be implemented in a session directory tool, an
electronic program guide (EPG), or by other means. The Data Security
or the announcement function directs group key management using an
application programming interface (API), which is peculiar to the
host OS in its specifics. A generic API for group key management is
for further study, but this function is necessary to allow Group
(KEK) and Data (TPKs) key establishment to be scalable to the
particular application. A GCKS application program will use the API
to initiate the procedures for establishing SAs on behalf of a
Security Protocol in which members join secure groups and receive
keys for streams, files, or other data.
The goal of the exchanges is to establish a GSA through updates to
the SAD of a key management implementation and particular Security
Protocol. The Data Security Protocol ("SECURITY PROTOCOL") of Figure
2 may span internetwork and application layers or operate at the
internetwork layer, such as AH and ESP.
4. Registration Protocol
The design of the registration protocol is flexible and can support
different application scenarios. The chosen registration protocol
solution reflects the specific requirements of specific scenarios.
In principle, it is possible to base a registration protocol on any
secure-channel protocol, such as IPsec and TLS, which is the case in
tunneled GSAKMP [tGSAKMP]. GDOI [RFC3547] reuses IKE Phase 1 as the
secure channel to download Rekey and/or Data SAs. Other protocols,
such as MIKEY and GSAKMP, use authenticated Diffie-Hellman exchanges
similar to IKE Phase 1, but they are specifically tailored for key
download to achieve efficient operation. We discuss the design of a
registration protocol in detail in the rest of this section.
4.1. Registration Protocol via Piggybacking or Protocol Reuse
Some registration protocols need to tunnel through a data-signaling
protocol to take advantage of already existing security
functionality, and/or to optimize the total session setup time. For
example, a telephone call has strict bounds for delay in setup time.
It is not feasible to run security exchanges in parallel with call
setup, since the latter often resolves the address. Call setup must
complete before the caller knows the callee’s address. In this case,
it may be advantageous to tunnel the key exchange procedures inside
call establishment [H.235,MIKEY], so that both can complete (or fail,
see below) at the same time.
The registration protocol has different requirements depending on the
particular integration/tunneling approach. These requirements are
not necessarily security requirements, but will have an impact on the
chosen security solution. For example, the security association will
certainly fail if the call setup fails in the case of IP telephony.
Conversely, the registration protocol imposes requirements on the
protocol that tunnels it. In the case of IP telephony, the call
setup usually will fail when the security association is not
successfully established. In the case of video-on-demand, protocols
such as RTSP that convey key management data will fail when a needed
security association cannot be established.
Both GDOI and MIKEY use this approach, but in different ways. MIKEY
can be tunneled in SIP and RTSP. It takes advantage of the session
information contained in these protocols and the possibility to
optimize the setup time for the registration procedure. SIP requires
that a tunneled protocol must use at most one roundtrip (i.e., two
messages). This is also a desirable requirement from RTSP.
The GDOI approach takes advantage of the already defined ISAKMP phase
1 exchange [RFC2409], and extends the phase 2 exchange for the
registration. The advantage here is the reuse of a successfully
deployed protocol and the code base, where the defined phase 2
exchange is protected by the SA created by phase 1. GDOI also
inherits other functionality of the ISAKMP, and thus it is readily
suitable for running IPsec protocols over IP multicast services.
4.2. Properties of Alternative Registration Exchange Types
The required design properties of a registration protocol have
different trade-offs. A protocol that provides perfect forward
secrecy and identity protection trades performance or efficiency for
better security, while a protocol that completes in one or two
messages may trade security functionality (e.g., identity protection)
for efficiency.
Replay protection generally uses either a timestamp or a sequence
number. The first requires synchronized clocks, while the latter
requires retention of state. In a timestamp-based protocol, a replay
cache is needed to store the authenticated messages (or the hashes of
the messages) received within the allowable clock skew. The size of
the replay cache depends on the number of authenticated messages
received during the allowable clock skew. During a DoS attack, the
replay cache might become overloaded. One solution is to over-
provision the replay cache, but this may lead to a large replay
cache. Another solution is to let the allowable clock skew be
changed dynamically during runtime. During a suspected DoS attack,
the allowable clock skew is decreased so that the replay cache
becomes manageable.
A challenge-response mechanism (using Nonces) obviates the need for
synchronized clocks for replay protection when the exchange uses
three or more messages [MVV].
Additional security functions become possible as the number of
allowable messages in the registration protocol increase. ISAKMP
offers identity protection, for example, as part of a six-message
exchange. With additional security features, however, comes added
complexity: Identity protection, for example, not only requires
additional messages, but may result in DoS vulnerabilities since
authentication is performed in a late stage of the exchange after
resources already have been devoted.
In all cases, there are tradeoffs with the number of message
exchanged, the desired security services, and the amount of
infrastructure that is needed to support the group key management
service. Whereas protocols that use two or even one-message setup
have low latency and computation requirements, they may require more
infrastructure such as secure time or offer less security such as the
absence of identity protection. What tradeoffs are acceptable and
what are not is very much dictated by the application and application
environment.
4.3. Infrastructure for Alternative Registration Exchange Types
The registration protocol may need external infrastructures to handle
authentication and authorization, replay protection, protocol-run
integrity, and possibly other security services such as secure
synchronized clocks. For example, authentication and authorization
may need a PKI deployment (with either authorization-based
certificates or a separate management) or may be handled using AAA
infrastructure. Replay protection using timestamps requires an
external infrastructure or protocol for clock synchronization.
However, external infrastructures may not always be needed; for
example pre-shared keys are used for authentication and
authorization. This may be the case if the subscription base is
relatively small. In a conversational multimedia scenario (e.g., a
VoIP call between two or more people), it may be the end user who
handles the authorization by manually accepting/rejecting the
incoming calls. In that case, infrastructure support may not be
required.
4.4. De-registration Exchange
The session-establishment protocol (e.g., SIP, RTSP) that conveys a
registration exchange often has a session-disestablishment protocol
such as RTSP TEARDOWN [RFC2326] or SIP BYE [RFC3261]. The session-
disestablishment exchange between endpoints offers an opportunity to
signal the end of the GSA state at the endpoints. This exchange need
only be a unidirectional notification by one side that the GSA is to
be destroyed. For authentication of this notification, we may use a
proof-of-possession of the group key(s) by one side to the other.
Some applications benefit from acknowledgement in a mutual, two-
message exchange signaling disestablishment of the GSA concomitant
with disestablishment of the session, e.g., RTSP or SIP session. In
this case, a two-way proof-of-possession might serve for mutual
acknowledgement of the GSA disestablishment.
5. Rekey Protocol
The group rekey protocol is for transport of keys and SAs between a
GCKS and the members of a secure communications group. The GCKS
sends rekey messages to update a Rekey SA, or initialize/update a
Data SA or both. Rekey messages are protected by a Rekey SA. The
GCKS may update the Rekey SA when group membership changes or when
KEKs or TPKs expire. Recall that KEKs correspond to a Rekey SA and
TPKs correspond to a Data SA.
The following are some desirable properties of the rekey protocol.
o The rekey protocol ensures that all members receive the rekey
information in a timely manner.
o The rekey protocol specifies mechanisms allowing the parties to
contact the GCKS and re-sync when their keys expire and no
updates have been received.
o The rekey protocol avoids implosion problems and ensures
reliability in delivering Rekey information.
We further note that the rekey protocol is primarily responsible for
scalability of the group key management architecture. Hence, it is
imperative that we provide the above listed properties in a scalable
manner. Note that solutions exist in the literature (both IETF
standards and research articles) for parts of the problem. For
instance, the rekey protocol may use a scalable group key management
algorithm (GKMA) to reduce the number of keys sent in a rekey
message. Examples of a GKMA include LKH, OFT, Subset difference
based schemes etc.
5.1. Goals of the Rekey Protocol
The goals of the rekey protocol are:
o to synchronize a GSA,
o to provide privacy and (symmetric or asymmetric)
authentication, replay protection and DoS protection,
o efficient rekeying after changes in group membership or when
keys (KEKs) expire,
o reliable delivery of rekey messages,
o member recovery from an out-of-sync GSA,
o high throughput and low latency, and
o support IP Multicast or multi-unicast.
We identify several major issues in the design of a rekey protocol:
1. rekey message format,
2. reliable transport of rekey messages,
3. implosion,
4. recovery from out-of-sync GSA,
5. incorporating GKMAs in rekey messages, and
6. interoperability of GKMAs.
Note that interoperation of rekey protocol implementations is
insufficient for a GCKS to successfully rekey a group. The GKMA must
also interoperate, i.e., standard versions of the group key
management algorithms such as LKH, OFT, or Subset Difference must be
used.
The rest of this section discusses these topics in detail.
5.2. Rekey Message Transport and Protection
Rekey messages contain Rekey and/or Data SAs along with KEKs and
TPKs. These messages need to be confidential, authenticated, and
protected against replay and DoS attacks. They are sent via
multicast or multi-unicast from the GCKS to the members.
Rekey messages are encrypted with the Group KEK for confidentiality.
When used in conjunction with a GKMA, portions of the rekey message
are first encrypted with the appropriate KEKs as specified by the
GKMA. The GCKS authenticates rekey messages using either a MAC,
computed using the group Authentication key, or a digital signature.
In both cases, a sequence number is included in computation of the
MAC or the signature to protect against replay attacks.
When group authentication is provided with a symmetric key, rekey
messages are vulnerable to attacks by other members of the group.
Rekey messages are digitally signed when group members do not trust
each other. When asymmetric authentication is used, members
receiving rekey messages are vulnerable to DoS attacks. An external
adversary may send a bogus rekey message, which a member cannot
identify until after it performs an expensive digital signature