GDOI

The GDOI [6] of ISAKMP represents an effort to specify a ‘‘domain of interpretation’’ over the more general ISAKMP key management framework [17]. In essence, the GDOI protocol is a GSA management protocol. The notion of domains of interpretation was introduced in ISAKMP

as a way to allow a more specific usage of ISAKMP for certain areas of application, which may require the addition of extensions to the plain ISAKMP to fulfill those specific needs. More specifically, the GDOI protocol borrows definitions from GSAKMP [5], incorporates the Phase 1 SA of the Internet DOI [18, 19], and proposes new payloads and exchanges according to the ISAKMP and IKE standards.

Although ISAKMP [17] allows for such interpretations, in reality the process is not so straightforward. This fact, together with the reality that the IKE [19] protocol is the de facto Internet key exchange protocol used by over 70 vendors, led the authors of the GDOI protocol to build the protocol using IKE, rather than ISAKMP. The GDOI protocol has its origins in SMuG, which is a research group that was established under the auspices of the IRTF, a sister organization of the IETF. After going through a number of revisions, the GDOI protocol was submitted to the MSEC Working Group in the IETF for formal standardization. At the time of this writing, two major vendors are in the final stages of completing their respective implementations, which have been tested against each other for interoperability.

Mapping GDOI to the GSA Model

Recall that in Section 4.4 the notion of a GSA was described and then defined. A GSA is defined to consist of three categories or types of SAs. The three categories of SAs are called Category 1 SA (or SA1), Category 2 SA (or SA2) and Category 3 SA (or SA3), and they are shown in Figure 4.3. The entities involved are the Group Controller Key Server (GCKS) and the members. Note that in Figure 4.3 the GCKS is also referred to as the KD.

Looking at Figure 4.3, the following provides a mapping between the conceptual SAs in Section 4.4 and how they are implemented in GDOI:

w _{Category 1 SA: This SA is also referred to as SA1 or pull SA (since the}

member pulls it down from the GCKS). In some literature, this SA is also called registration, since it mimics the registration process that the member has to conduct with the GCKS for the particular multicast group.

In GDOI, this is implemented as the GDOI Phase 1 and Phase 2 ex- changes. As will be explained later, the GDOI Phase 1 is similar to IKE Phase 1, while the GDOI Phase 2 is newly defined to cater for the GSA. GDOI refers to this new Phase 2 as the GROUPKEY-PULL exchange.

w _{Category 2 SA: In Section 4.4 this SA is defined to be used for control}

messages sent or pushed by the GCKS to the members. Such control

118 Architectures and protocols for group key management

TEAM

FLY

messages may in fact include rekeying messages and SA updates. GDOI refers to this SA as the push SA or rekey SA.

In GDOI, this is implemented as the GROUPKEY-PUSH data- gram, where the message is pushed from the GCKS to the members.

w _{Category 3 SA: GDOI refers to this SA as the data security SA since it is}

used by the application to secure the data traffic (e.g., IPsec).

GDOI and IKE

The ISAKMP protocol [17] is a key management framework for transferring key and authentication data, independent of the key generation process. ISAKMP defines a set of protocol exchanges that set up a secure channel for key management, as well as the exchange of key and authentication data. Generalized payloads for exchanging key generation and authentication data are defined by ISAKMP. These payloads are combined with a DOI, which defines the specifics of key exchange protocol. ISAKMP is intended to support the negotiation of SAs for security protocols at all layers of the network stack, although in practice it is commonly used at the network layer.

The IKE protocol [19] is a widely deployed key exchange protocol. It is primarily used as a key exchange protocol for IPsec, but can be used for other security protocols as well. Hence, the authors of the GDOI protocol saw a number of advantages to making use of existing support for ISAKMP as a key management framework and IKE for the secure channel (namely, the Category 1 SA):

w _{Reusing much of the existing key management protocol promotes a}

single key management framework.

w _{Systems that provide network-layer protection of unicast data will}

have the same market needs to provide network-layer protection for multicast data.

w _{Using the same underlying protocol will reduce both the complexity}

and size of the key management code.

w _{Implementation can be achieved more expediently.}

In attempting to understand GDOI, it is worth reviewing the two phases of IKE, since GDOI uses much of IKE Phase 1. Recall that IKE is logically divided into two exchanges, referred to as Phase 1 and Phase 2. A Phase 1 exchange must be completed before any Phase 2 exchanges are attempted.

Once the Phase 1 exchange has completed, there is no limit to the number of Phase 2 exchanges that can take place, and there may be simultaneous Phase 2 exchanges occurring between IKE peers.

w _{Phase 1: In Phase 1, two peers establish a bidirectional, secure,}

authenticated channel using payloads and semantics defined in ISAKMP. Several different authentication methods are defined for use in IKE (i.e., manually shared keys, digital signatures, or public key encryption). The two peers negotiate a mutually acceptable set of cryptographic policies, and derive keying material using the Diffie- Hellman or public key encryption algorithms. At the end of Phase 1, the two peers have fully authenticated each other, and have exchanged adequate keying material used to create a secure authenticated channel for Phase 2.

w _{Phase 2: In Phase 2, the two peers negotiate SAs on behalf of IPsec (or}

other security protocols if another DOI has been defined). IKE Phase 1 provides confidentiality, integrity, replay protection, and the gen- eration of key exchange protocol keying material (i.e., using keying material exchanged during Phase 1).

The secure channel defined by an IKE Phase 1 is used by GDOI to protect GDOI keying material. This is because it can directly provide confidentiality and integrity. Furthermore, the IKE exchanges protect against man-in-the middle, connection hijacking, reflection, and replay attacks. IKE offers some protection against DoS attacks as well.

Although GDOI uses IKE Phase 1, it defines a new Phase 2 exchange called GROUPKEY-PULL. In fact, GDOI uses the IKE Phase 1 to protect the new Phase 2 exchange. This new Phase 2 exchange is discussed further below. New elements in GDOI

The GDOI protocol implements the GSA concept. Thus, although borrowing Phase 1 from IKE (which is a unicast protocol), GDOI by necessity introduced a number of new elements to cater for multicast-related interactions between the GCKS and the members.

The GDOI protocol introduced several new payloads. These are as follows (see Figure 5.7):

w _{GDOI SA;}

w _{SA KEK (SAK), which follows the SA payload, where the KEK is the}

key encryption key;

w _{SA TEK (SAT), which follows the SA payload, where the TEK is the}

traffic encryption key;

w _{KD Array (denoted as KD, or key download, as borrowed from}

GSAKMP);

w _{Sequence number (SEQ);} w _{Proof of possession (POP).}

In addition, the GDOI protocol introduced two new exchanges:

w _{A Phase 2 exchange to create Category 2 and Category 3 SAs.}

The new Phase 2 exchange called GROUPKEY-PULL, downloads KEK and/or TEK keying material, policy, and attributes for the group member. The GROUPKEY-PULL exchange uses pull behavior, since the member initiates the retrieval of these parameters from the

Figure 5.7 GDOI Phase 2 exchange.

GCKS. The member is aware of the group through some announce- ment scheme (such as the SDP), and initiates the pull.

w _{A datagram to create or modify the Category 2 and Category 3 SAs.}

The GROUPKEY-PUSH datagram is pushed from the GCKS to the members. The KEK or KEK array protects the GROUPKEY-PUSH message, which creates a new Category 3 or Category 2 SA. When the GROUPKEY-PUSH carries a TEK, it creates a new Category 3 SA. Multiple Category 3 SAs can be specified through the SAT.

Note that the GCKS creates each Category 3 SA with a TEK on behalf of the security protocol that multicasts data. The security protocol is the protocol that will use the TEK for enciphering multicast data before it is transmitted through IP multicast.

A security protocol uses the TEK and ‘‘owns’’ the Category 3 SA in the same way that IPsec ESP uses the IKE Phase 2 keys and owns the Phase 2 SA. When the GROUPKEY-PUSH message carries a KEK array (or key hierarchy), it effectively dictates the creation of a new Category 2 SA. The GCKS creates a new Category 2 SA with a KEK array in order to add or remove group members, or to refresh the SAK or SAT [4, 5, 20]. Alternatively, membership may expire when the KEK expires [21], and the GROUPKEY-PUSH message is not used to create Category 2 SAs for the particular group. Use of LKH-style membership management (see Chapter 6) is an option in GDOI.

The new GDOI Phase 2

The new GDOI Phase 2 is shown in Figure 5.7. The goal of the GDOI Phase 2 (or GROUPKEY-PULL exchange) is to establish a Category 2 and/or Category 3 SA at the member for a particular group. The GDOI Phase 2 is protected by the Phase 1 (which is in fact an IKE Phase 1). Furthermore, multiple GROUPKEY-PULL exchanges may occur under a given Phase 1 SA. One of the items transferred within the GROUPKEY-PULL exchange is the KEK for the group. Since the KEK can in fact contain an array of keys, it is also referred to a KEK array (which reflects the fact that it is a sequence of keys made up from the keys of an LKH or a key tree).

Looking at Figure 5.7, the GROUPKEY-PULL exchange uses many IKE definitions:

w _{SKEYID. IKE Phase 1 computes SKEYID a from the Diffie-Hellman}

keying material exchanged in Phase 1. SKEYID a is the ‘‘key’’ in the

keyed hash used in the GROUPKEY-PULL HASH payloads. As with the IKE HASH payload generation (RFC 2409 section 5.5), each GROUPKEY-PULL message hashes a uniquely defined set of values. Nonces permute the HASH and provide some protection against replay attacks. Replay protection is important to protect the GCKS from attacks that a key management server will attract.

w _{Nonces. The GROUPKEY-PULL exchange uses nonces to guarantee}

‘‘liveliness,’’ or that someone is not replaying a recent GROUPKEY- PULL message. The replay attack is only useful in the context of the current Phase 1. If a GROUPKEY-PULL message is replayed based on a previous IKE Phase 1, the HASH calculation will fail due to a wrong SKEYID a. The message will fail processing before the nonce is ever evaluated. In order for either peer to get the benefit of the replay protection, it must postpone as much processing as possible until it receives the message in the protocol that proves the peer is live. For example, the responder must not compute the shared Diffie-Hellman number (if key exchange payloads were included) or install the new SAs, until it receives a message with Nr included properly in the HASH payload.

Nonces require an additional message in the protocol exchange to ensure that the GCKS does not add a group member until it proves liveliness. The GROUPKEY-PULL member-initiator expects to find its nonce, Ni, in the HASH of a returned message. Furthermore, the GROUPKEY-PULL GCKS-responder expects to see its nonce, Nr, in the HASH of a returned message before providing group keying material as in the following exchange.

w _{HDR. In Figure 5.7 HDR is an ISAKMP header payload that uses the}

Phase 1 cookies and a message identifier (M-ID) as in IKE [19]. Note that nonces are included in the first two exchanges, with the GCKS returning only the SA policy payload before liveliness is proven. The HASH payloads prove that the peer has the Phase 1 secret (SKEYID a) and the nonce for the exchange identified by M-ID. Once liveliness is established, the last message completes the real processing of downloading the KD payload.

w _{ID payload. In addition to the nonce and HASH payloads, the member}

initiator identifies the group it wishes to join through the ISAKMP ID payload. The GCKS-responder informs the member-initiator of the current value of the sequence number in the SEQ payload. The sequence number orders the GROUPKEY-PUSH datagrams.

w _{SA payload, DOI, TEK, KEK, and SPI. The GCKS-responder informs the}

member-initiator of the cryptographic policies of the group in the SA payload, which describes the DOI, KEK, and/or TEK keying material, and authentication transforms. The SPIs are also determined by the GCKS, and downloaded in the SA payload chain.

w _{KD payload. The KEK SA contains the ISAKMP cookie pair for the}

Category 2 SA, which is not negotiated, but downloaded. The TEK SA also contains an SPI. The second message downloads this SA payload. If a Category 2 SA is defined in the SA payload, then KD will contain the KEK. If one or more Category 3 SAs is defined in the SA payload, then KD will contain the TEKs. This is useful if there is an initial set of TEKs for the particular group, and can obviate the need for future TEK GROUPKEY-PUSH messages.

w _{Certificate and POP. The member may establish an identity in the}

GROUPKEY-PULL exchange in an optional certificate (CERT) pay- load that is separate from the Phase 1 identity.

When the member responder passes a new CERT, a POP payload accompanies it. The POP payload demonstrates that the member or GCKS principal has used the very secret that authenticates that principal (namely, the principal’s private key that corresponds to the public key used in the CERT payload). POP I is an ISAKMP signature (SIG) payload containing a hash of the concatenated noncesNiand

Nrsigned by the member, when the member passes a CERT signed by the group owner, to prove its authorization. POP R contains the hash of the concatenated nonces Ni and Nr signed by the GCKS, when the GCKS passes a CERT signed by the group owner, to prove its authority to provide keys for a particular group. The use of the nonce pair for the POP payload, transformed through the IKE pseudo random function (PRF), is designed to withstand compromise of the Category 1 (IKE Phase 1) key.

Updating SAs

One of the fundamental design aspects of the GSA model and GDOI is the use of multicast itself to distribute certain control messages. An example of this use of multicast is the updating of SAs using the GROUPKEY-PUSH message. Note that the message itself is not dependent on IP multicast, and as such can also be pushed using unicast delivery. The GROUPKEY-PUSH message replaces a Category 2 SA KEK (or KEK array), and/or creates a new Category 3 SA. See Figure 5.8.

As before, the SA defines the policy (e.g., crypto suite) and attributes (e.g., SPI) for a Category 2 and/or Category 3 SA. The GCKS optionally provides a CERT payload for verification of the SIG, which is a signature of a hash of the entire message before encryption (including the header and excluding the SIG payload itself). The KD is the key download payload (described above).

If the SA defines an LKH-style KEK array or single KEK, the KD payload contains a KEK or KEK array for a new Category 2 SA, which has a new cookie pair. When the KD payload carries a new KEK SA, a Category 2 SA is replaced with a new SA having the same group identifier and incrementing the same sequence counter, which is initialized in message 4 of Figure 5.7. If the SA defines an SA TEK payload, this informs the member that a new Category 3 SA has been created, with keying material carried in the KD payload.

Functional block diagram of GDOI

As further illustration of the GDOI protocol, Figure 5.9 shows the functional block diagram (FBD) of the GCKS and member.

Members may be senders or receivers of multicast data. There are two functional blocks in the figure which are labeled ‘‘GDOI,’’ and there is an arc between them depicting the GDOI 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 SAD and SPD. The AUTHORIZATION block

Figure 5.8 GDOI push message.

is subject to group policy [22], but how this is done is specific to the GCKS implementation. GDOI is open to supporting alternative authorization designs.

Besides the AUTHORIZATION block there is an ANNOUNCEMENT block. The announcement function is how a member receives announce- ments of secure groups and sessions. The SDP [23] is one form that the announcements might take. The announcement function may be implemented in a session directory tool, an electronic program guide (EPG), or by other means. The announcement function directs GDOI using an API, which is peculiar to the host OS in its specifics.

The reader is directed to the specifications of GDOI in [6] for further details on the GDOI protocol and to [24] for a formal analysis of the GDOI protocol.

5.5

Summary

This chapter has focused on two related and important aspects of multicast and group security; namely, architectures and protocols for group key

Figure 5.9 GDOI functional block diagram.

management. In the area of architectures, two designs have been described, representing two ends of a spectrum of possible architectures. These are the layered (or hierarchic) architecture (represented by [1]) and the Iolus architecture (represented by [2]).

The second part of the chapter sampled some group key management protocols that have focused on security, key management, and SA manage- ment to secure multicast and group communications. These are not meant to be comprehensive, but provide an insight into the complexity of designing protocols for group key management.

The chapter’s discussion on the issues and motivations for architectures and protocols points to the fact that group key management cannot be implemented independent of other factors in the wider environment, such as the application of multicast, topological aspects, membership dynamics, and others. These factors must be taken into consideration when architecting