GSAKMP: Group Secure Association Key Management Protocol
Extracted elements (31)
Cookie mode is adapted from IKEv2 and the Photuris concept (Karn and Simpson, RFC 2522) to defeat IP-spoofed RTJ flooding DoS attacks. The GC/KS commits no state until it can verify the prospective GM can receive packets at its claimed source address, eliminating the CPU and state exhaustion attack vector.
The Request to Join Error message is deliberately unsigned for two reasons: at denial time the GM has no knowledge of who is an authorized GC/KS so the signature would be meaningless, and signing denial responses would create a denial-of-service vector by forcing the GC/KS to expend resources signing messages for unauthorized requesters.
GSAKMP supports three multicast speaker configurations, all with different anti-replay properties: single authorized speaker (sequence number checking feasible, default), all GMs as speakers sharing one GTPK (anti-replay sequence checking not feasible), and authorized subset with per-speaker SA state (supports anti-replay but does not scale to large speaker counts). Implementations MUST support the first two; the third is optional.
A GC/KS MUST process no more than one (1) valid RTJ message from a given GM per group at any one time until its pending registration protocol exchange concludes.
Compliant GSAKMP implementations MUST support Diffie-Hellman key exchange for two-party key creation. Implementations supporting the optional rekey capability MUST also support retransmission of rekey messages to ensure high availability.
Diffie-Hellman exponents MUST NOT be derived from long-lived secrets such as the seed to a pseudo-random generator that is not erased after use. It is assumed that DH exponents are erased from memory after use.
Group Policy MUST be commonly understood and enforced by the group for coherent secure operations. The policy token completely describes the protection mechanisms and security-relevant behaviors of the group.
GSAKMP implementations MUST support Terse Mode (the three mandatory messages: RTJ, Key Download, Key Download Ack/Failure) and MAY support Verbose Mode (which adds the optional RTJ-Error and Lack_of_Ack messages). All (S-)GC/KSes in a Verbose Mode group MUST support Verbose Mode.
GSAKMP requires that its supporting PKI implementations MUST be compliant with RFC 3280 for certificate path validation. If a GM's public key certificate is revoked, the issuing entity SHOULD signal the GO to expel that GM.
If any error occurs during KeyDL message processing, regardless of Terse or Verbose Mode, the registration session MUST be terminated, the GM MUST send a Key Download Ack/Failure message, and all saved state information MUST be cleared.
If the GC/KS does not receive a valid KeyDL-A/F message within its locally configured timeout, it MUST evict the GM from the group in the next policy-defined Rekey Event. The GC/KS MAY optionally send a Lack_of_Ack message in Verbose Mode.
Nonces MUST be present in GSAKMP messages unless synchronization time is available to the system. The Nonce_I value generated in the RTJ MUST be saved for potential later use in freshness verification of subsequent messages.
The identity of each party in the Group Secure Association establishment process MUST be unambiguously asserted and authenticated. It MUST also be verified that each party is authorized, as defined by the policy token, to function in its role in the protocol (e.g., GM or GC/KS).
The Policy Token sequence number must never be reset to a lower value (no rollover to zero) as long as the group identifier remains valid and in use. The GO MUST preserve this sequence number across reboots to prevent replay attacks.
The Cookie Download message (exchange type 10) is sent in Cookie Mode by the GC/KS in response to an RTJ without cookie information. It includes a cookie in a Notification payload of type Cookie_Required; the GM MUST retry the RTJ with this supplied cookie to prove IP address reachability.
The Group Controller Key Server (GC/KS) role covers key creation, key distribution, rekey operations, and group membership management (registration, eviction, de-registration). It creates the Group Traffic Protection Keys (GTPKs) and first-tier rekey key trees and enforces the policy token's access control rules.
The Key Download Ack/Failure (KeyDL-A/F) message (exchange type 4) is a GM-signed message containing the Nonce_C value and a Notification payload of type ACK or NACK, confirming or denying successful receipt and processing of the Key Download.
The Key Download (KeyDL) message (exchange type 9) is sent by the GC/KS to an accepted GM. It contains the GM's identification, Nonce_R and combined Nonce_C values, key creation material, and the encrypted policy token and key material signed by the GC/KS.
The Policy Token (PT) is a CMS-signed data structure issued and signed by the Group Owner that disseminates group policy. It contains identification, access control rules, authorization rules, security mechanisms, compromise recovery policy, and data protection mechanisms; all GMs MUST verify and enforce it.
The Rekey Event message distributes a new GTPK and optionally a new Policy Token to group members via multicast. In distributed operation, S-GC/KSes receive rekey from the primary GC/KS and relay it to their sub-groups using LKH-wrapped key arrays, realizing forward and backward secrecy.
The Request to Join (RTJ) message (exchange type 8) is sent from a potential GM to the GC/KS to request group admission. It contains a Key Creation payload for KEK determination, a Nonce_I for freshness, an optional Mechanism Choices notification, an optional Cookie notification, and the GM's signature with optional certificates.
IANA assigned UDP and TCP port 8825 to GSAKMP (Section 9.1). New IANA registries created include: Group Identification Types, Payload Types, Exchange Types, Policy Token Types, Key Download Data Item Types, Cryptographic Key Types, Rekey Event Types, Identification Types, Certificate Payload Types, Signature Types, Notification Types, Acknowledgement Types, and Nonce Types.
Compromise of the Group Owner forces termination of the entire group. Compromise of an S-GC/KS forces re-registration of all GMs under its control. GMs detect either compromise by finding the relevant party's certificate on a Certificate Revocation List (CRL) supplied by a service such as LDAP.
GSAKMP does not provide identity protection; participant identities are exposed in the clear during protocol exchanges. The multicast routing infrastructure is not secured by GSAKMP, making multicast flooding DoS attacks possible from insiders (rogue GMs) or non-members directing routers to spray data at a victim.
GSAKMP security is critically dependent on the unpredictability of nonce values (per RFC 4086) and the accuracy of the system clock. The maximum allowable clock skew across group membership is policy-configurable with a default of 5 minutes; if a network time service is used it MUST be secured against attackers.
The GSAKMP state diagram (Table 28) defines states: Start, Await_RTJ (GC/KS listening), Await_KeyDL (GM waiting for response), Await_KeyDL-A/F (GC/KS waiting for acknowledgement), and Member (fully established). Transitions are triggered by receipt of RTJ, KeyDL, KeyDL-A/F, LOA, RTJ-Err, Rekey Event, and Departure messages, or by timeout events.
The Generic Payload Header is prepended to every GSAKMP payload and contains: Next Payload type (1 octet identifying the following payload), a Reserved octet, and Payload Length (2 octets including the header). It enables chaining of heterogeneous payload types within a single message.
The GSAKMP Header contains a version field, GroupID Type (1 octet) and variable-length GroupID, Exchange Type (1 octet identifying the message type), a Next Payload field, and a Sequence-ID. GroupID variants are: UTF-8 string, Octet String, IPv4 (4-octet), and IPv6 (16-octet).
The Key Download Payload contains one or more Key Download Data Items, each carrying a Key Datum Structure (Key Type, Key Handle, Key ID, Wrapping KeyID, Wrapping Key Handle, and encrypted key material) and optionally a Rekey Array Structure for LKH-based rekey arrays.
The Notification Payload carries a Notification Type (from 22 defined types including ACK, NACK, Cookie_Required, Cookie, Mechanism_Choices, Invalid-Payload-Type, Authentication-Failed, Unauthorized-Request, etc.) plus variable-length type-specific Notification Data.
The Signature Payload contains a Signature Type field, a Timestamp (used for replay protection when nonces are not used), the signer's identity reference, and the signature value computed over the defined scope of preceding payload fields.