GSAKMP

GSAKMP [5] was developed as a framework for creating groups that share cryptographic keys. The framework provides mechanisms to disseminate group security policy, perform access control based upon PKI certificates, generate group keys, and recover from compromise of keys within a group. GSAKMP introduced the notion of a policy token, which is a signed collection of policy information related to a given group.

GSAKMP defines its own header and message format, which is similar to the ISAKMP framework for pair-wise key management. The authors perceived ISAKMP as being insufficient for the needs of dynamic secure group creation and maintenance; hence the definition of GSAKMP. The

dynamic aspect of GSAKMP is the notion that group members, when provided with enough authority, should be able to take on the function of the GC. This provides scalability and resilience against the GC crashing, or network partitions occurring.

Entities in GSAKMP

GSAKMP defines a number of entities, starting with the GC as the most prominent entity. One important underlying concept within GSAKMP is the notion that the GC can be any member of the group that has (been given) the authority to perform some critical tasks. Among others, the GC is distinguished from ordinary members by its ability to:

w _{Create and disseminate keys;}

w _{Maintain the rekeying infrastructure;}

w _{Create and maintain a logical key hierarchy or a key array for the}

purpose of rekeying members.

GSAKMP looks ahead by allowing the group key management infrastructure to evolve into a multiGC arrangement where several members can be a GC within a group, each even with a more specific task of being a

rekey-GC. These are referred to as subordinate controllers (SCs) by GSAKMP. The distinction between a GC and SC reflects GSAKMP’s understanding of the need for managing large groups by dividing them into subgroups; each managed by one or more SCs. The policy token, which is known by all members, mentions the members that are delegated to become a SC, and therefore allows new or prospective members to contact their local (or closest) SC to initiate a group join.

Furthermore, GSAKMP reflects an N-tier thinking by introducing the notion of ‘‘subordinate logical key hierarchy’’ (or subordinate LKH arrays), which essentially points to each subgroup having its own logical key hierarchy with the aim of protecting and managing the group key.

Group establishment and protocol flows in GSAKMP

GSAKMP recognizes a group life cycle consisting of group definition, group establishment, group maintenance, and group removal. The activities involved in creating a group include:

w _{Determining access policies for the host/users to join the group;} w _{Determining authorization policies for entities involved in key}

dissemination and other actions requiring higher trust levels;

w _{Determining security mechanisms and algorithms used by members}

in the group;

w _{Determining the topology of membership according to the LKHs and}

compromise recovery algorithms;

w _{Creation of the policy token containing some or all of the information}

previously determined.

There are several phases involving differing protocol flows in the creation of a GSAKMP-based group (Figure 5.6).

1. Group establishment.

In GSAKMP the establishment of a group begins when a (potential) member issues arequest to join (RTJ) message to GC.

The scheme assumes that at the very least the GC is already in operation, and that group establishment in actuality begins when the first member issues the RTJ. In terms of the group establishment protocol, the GC could in fact issue an invitation (i.e., the push model) and the member could issue a request (i.e., the pull model).

The RTJ must indicate the GID that the member is referring to, and the message must be digitally signed by the member.

The GC then responds to the member with an invitation

message, which contains among others, the policy token pertaining to the GID that the member requested to join. The message also contains other elements for protection against replay attacks (e.g., nonces), and the identity of the member who requested to join. The GC digitally signs the message and optionally attaches its own certificate.

After the member verifies the signature of the GC on the invitation message (and verifies the GC’s certificate), the member verifies the authorization of the GC.2 Assuming the member has

2. The published GSAKMP documents assume that some authorization mechanism exists for the members to allow them to verify the authority of the GC or subordinate GCs.

Figure 5.6 GSAKMP flow.

verified the authorization of the GC to act on behalf of the group, the member sends back aninvitation response(IR) message to the GC. This IR message must return the nonces that were contained in the previous invitation message, and the member must sign the IR message.

In return, the GC will create and send a signed key download

message containing the data key (or GTEK), together with the LKH or key tree/array for rekeying purposes later. Note that encryption is performed on all of the necessary fields of the message to protect the keying information from being read in transit. The LKH or key array is often described as ‘‘self protecting,’’ because in its delivery the nodes within the hierarchy will be encrypted using keys which are derived from the location of the node within the hierarchy. Furthermore, the key download itself is conducted through a pair-wise secure channel between the GC and the member.

Once the member verifies the authenticity of thekey download

message from the GC and obtains the keying information for the group, it responds to the GC by sending it an acknowledgment

message. The GC will verify the signature and freshness of the message.

The reader is directed to [5] for detailed information on the payloads of the messages discussed above.

2. Group maintenance.

GSAKMP uses the term maintenance to refer to the events and responses related to membership changes, rekeying events, and other emergency situations (such as key compromises).

The first ordinary event that is expected to occur is membership changes, whereby members leave and new members join. When a member joins, the procedure observed is that described above. When a member leaves, then rekeying must occur, based on the position of the member within the LKH. The member-leave event triggers the GC to send out a rekey message containing a (possibly revised) policy token and key array.3

Note that all group maintenance messages must be signed by the GC, since it affects all members of the group tied within the LKH.

3. A description of a rearrangement of an LKH can be found in Section 6.3.

Extraordinary events foreseen by GSAKMP includes the compromise of a current data key (or GTEK) and/or the compromise of part or all of the entries within the LKH being used within a group.

3. Group termination.

The termination of a group in GSAKMP is effected by the GC sending out a group removal/destruction message which is digitally signed. The understanding is that communications within the group will cease to exist, and that resources used to run the group may also cease to be available.

Group establishment without an underlying SA

GSAKMP allows for the creation of groups through the member-to-GC communication, without reliance on the existence of an underlying security association (Category 1 SA). This approach assumes that the data portion of the key download payload is encrypted, and that the details of the encryption of this data are provided in the key download payload itself.

The key determination for this encryption may be done through a two- party contributory system (a` la Diffie-Hellman) using the key creation payloads to carry the contributions of the participants to this key, or may be transferred with the encrypted contents using public key encryption and an enveloping scheme.

GSAKMP policy token

GSAKMP employs a data structure called the policy token to represent security mechanisms (and their parameters) that are used within a group. The elements of a policy token specify the policies that are to be followed by members of a group, and consist of the following:

w _{Policy identification. A group must have some means by which it can}

identify an instance of group security policy in an unambiguous manner. Failure to correctly identify the group policies, messages, and participants can lead to incorrect and insecure operation. In the simplest form, an instance of a policy token must be associated with a unique GID expressly found inside the policy token.

w _{Authorization for group actions. A group security policy must identify}

the entities allowed to perform actions that affect group members. Group authorization partially determines the trust embodied by the group as a whole, by defining the parties or entities that are allowed to participate in group activities. Because of the wide range of expected environments, flexible identification of entity authoriza- tions is highly desirable. Authorization given to an entity must be shown as being true and authentic, and coming from another entity that bequeathed that authority.

w _{Access control to group information. Access control policy defines the}

entities that will have authorization to hold the key protecting the group data.

w _{Mechanisms for group security services. Identification of the security}

services used to support group communication is required. For example, policy must state the algorithms used to derive session keys and the types of data transforms to be applied to the group content. Each security service can have parameters and policies specific to its implementation.

In order to establish that the entire GSA is adequate to protect the data, it is necessary to have the full specification of:

w _{The group establishment mechanism;} w _{The data protection mechanism;} w _{The group management mechanism.}

w _{Verification of group security policy. Each policy must present evidence}

of its validity. The means by which the origin, integrity, and freshness of the policy is asserted (for example, via digital signatures) must be known by each group member prior to its acquisition. In the simplest form, this consists of the policy token being digitally signed by the entity authorized to issue the group security policy (e.g., the group owner).