GKMP

GKMP was one of the earliest works addressing key management in the context of a group [3]. GKMP recognizes the creation of groups through

108 Architectures and protocols for group key management

TEAM

FLY

sender-initiated and receiver-initiated operations, and describes key management from the point of view of a group key management application. As part of the group key distribution process, protocol entities pass permission certificates, which contain access control information about a particular site. The access control information is given by a trusted higher authority, who signs the permission certificate. A protocol entity must verify the permissions in the permission certificate and verify the level of service requested, to ensure that it is within the allowable range.

GKMP employs a cooperative key generation process, which initially starts between two protocol entities. The Group Key Controller then distributes the group keys to qualified GKMP entities. This distribution process is a mutually suspicious process, where all actions and identities must be verified.

Compromise recovery is supported in GKMP by way of a signed compromise recovery list (CRL) of compromised entities being distributed at the same time as key distribution. Furthermore, GKMP delegates control of groups to specific group controllers to support the efficient dissemination of CRLs. Each CRL is given a version number, which is delivered during key management. The version number triggers the downloading of the most recent version of the CRL.

GKMP entities

GKMP employs a number of entities and constructs that are innovative and that have been carried over into more recent protocols (such as GSAKMP and GDOI). These entities are as follows:

w _{Group controller (GC). The group controller (GC) is the a group}

member with authority to perform critical protocol actions. These include creating keys, distributing keys, creating group rekey messages, and reporting on the progress of these actions.

An important requirement in GKMP is that all group members must have the capability to be a GC, and must assume this duty upon assignment.

w _{Group member (GM). A group member is any group host that is not}

acting as the GC. A group member is assumed to have the task of assisting the GC in the key creation process, validating the GC’s authorization for carry out actions, accepting/requesting keys from/to the GC, maintaining local CRLs, managing local keys, and other tasks.

GKMP introduces a number of important concepts in the engineering of secure groups in the Internet. One of these is the group token (GT) which contains information the members need to ensure that a controller is authorized to create a group and that the group has information pertaining to constraints. These include:

w _{Group identification;} w _{GC identification;}

w _{The group action (create, rekey, or delete);} w _{Group permissions (rules to guide access control);} w _{The rekey interval (the lifespan of the group key);}

w _{The token version (an identifier to identify the current token);} w _{The token signature (an asymmetric signature using the GC private}

key);

w _{The GC’s public key.}

GKMP uses various identifiers to address the number of keys used within a GKMP group. These include the Group ID to identify groups, the group TEK (GTEK) ID to identify the group TEK, and the group KEK (GKEK) ID to identify the group KEK. The key identifiers are needed when a key tree or LKH is implemented for the group.

Sender-initiated multicast

The basic operational concept for multicast key management for sender- initiated multicast consists of a number of operations:

w _{Identification of group key controller. The originator of the multicast}

group creates or obtains a group management certificate from its certi- fication hierarchy. The certificate identifies the holder as responsible for generation and distribution of the group key. The originator relays the membership list to the group key management application.

w _{Group key creation. When the application receives the list of members,}

it selects a member and initiates the creation of a group key packet (GKP). The packet contains the current group traffic encryption key (GTEK), and a key used to deliver the future GTEK. This key is called the group key encrypting key (GKEK). The packet also contains

additional parameters, selected by the originator’s group key management application, defining the actual usage of the keys.

w _{Group key distribution. When the GKP has been created, the GC goes}

through the list of all members and verifies their respective permissions level, using each member’s certificate. The GC then creates a session key package (SKP), which contains a session TEK (STEK) and session KEK (SKEK). To handle future rekeys, the GC then creates a digitally signed group rekey package (GRP), which consists of the earlier created GKP encrypted under the GKEK.

w _{Group rekey. For group rekeying, the originator group key manage-}

ment application selects a member and proceeds to create a new GKP containing a new GTEK. In addition, it creates a new GRP, which is encrypted under the earlier next GKEK.

Receiver-initiated multicast

The receiver-initiated model presents some interesting problems from a security viewpoint, since the end participants are not known a priori. Transferring the notion of GC from above into the receiver-initiated multicast, the following steps describe the process using the controller.

w _{Identification of group key controller. Since there is no a priori list of}

known members, this approach assumes that one member (e.g., the member that initiated the group) is responsible for initial group establishment, and periodic generation and dissemination of new GRPs. In effect, this member may become the controller, whose identity can be made known to the existing members and new- comers, through various means (e.g., broadcast).

w _{Group key creation. In the receiver-initiated operations, the GKP}

creation is similar to the sender-initiated case. As before, the controller creates a GKP with the first group member to initiate contact. The group key management application then makes itself know as the GC, which the member validates under the protection of the GTEK.

w _{Group key distribution. After creation of the GKP, as other members}

contact the controller, an SKP is created, member permissions are validated using their certificates, and a Session Rekey Package is loaded to the member.

w _{Group rekey. The rekeying procedure here is identical to that for the}

sender-initiated case. The controlling group key management application selects a member, creates a new GKP, creates a new GRP (which is encrypted in the previously distributed next GKEK), and broadcasts it to the group.