Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic
Extracted elements (19)
Fixed-length SIDs were mandated (rather than allowing variable-length prefix-free codes such as Huffman codes) to favor implementation simplicity over theoretical optimality. Variable-length prefix-free codes would be secure but would complicate parsing.
The SID was placed in the explicit IV field rather than in the Salt so that a receiver can read it directly from the packet, without inferring the sender's identity from the IP source address or from an alternate transport (e.g., UDP for NAT traversal). Using the explicit IV avoids sender-inference complexity entirely.
Counter-mode transforms (AES-CTR, AES-GCM, AES-CCM, GMAC) as originally specified for point-to-point IKEv2-keyed SAs guarantee IV uniqueness only for a single sender. Group applications sharing one SA across multiple senders require the additional SID mechanism defined in this document.
If multiple GKMS entities independently distribute SIDs, the sets of identifiers distributed by each entity MUST NOT overlap, requiring coordination among GKMS entities before deployment.
A conforming implementation MUST support SID lengths of 8, 12, and 16 bits to facilitate interoperability. All SIDs used with a given SA MUST have the same length.
A group member that reaches the end of its IV space MUST stop sending data traffic on that SA and should re-register with the GCKS to obtain a new SID or SA.
If the entire set of sender identifiers has been exhausted, the GKMS MUST refuse to allow new group members to join, or alternatively distribute replacement SAs (potentially with larger SID values) to all group members.
The GKMS MUST NOT give the same sender identifier to more than one active group member for a given SA. If the GKMS is uncertain about a member's SID, it MUST allocate a new one.
The GKMS SHOULD allocate a single sender identifier for each group member and issue this value for all group SAs for which that member is a sender, simplifying management and rekeying.
The value of the SID MUST be unique for each sender across all senders sharing a particular Security Association.
The value of the SSIV field MUST be unique for each IV constructed by a particular sender for use with a particular SA.
This document RECOMMENDS that the GKMS both allocate unique SIDs to group members and distribute them using a GKM protocol such as GDOI or GSAKMP.
When a GKMS re-allocates a departing member's SID to a new member, it MUST first delete and replace any active AH or ESP SAs with which the SID may have been used, to avoid IV reuse with the same cipher key.
Each IV for a group SA is formed by concatenating a Sender Identifier (SID) field with a Sender-Specific IV (SSIV) field. The leftmost bits of the IV hold the SID; the remaining bits hold the SSIV. This partitions the IV space among senders so that no two senders ever produce the same IV under a shared key.
A cryptographic device that persists keying material across reboots must also store the SID and SSIV values used with each IPsec SA so that it never re-uses those values after resumption.
Any group member that uses an SID not allocated to it may reduce the security of the entire group by producing IV collisions with the legitimate holder of that SID.
This specification does not address virtual machine rollbacks, which could cause a cryptographic device to re-use nonce values and thereby violate IV uniqueness.
When recommendations in this specification are followed, the security of the counter-mode cryptographic algorithms is equivalent to the conventional single-sender case because the IV space is partitioned so each sender has exclusive use of a disjoint set of IV values.
The IV is a bit string whose leftmost N bits are the SID and whose remaining bits are the SSIV. SID width N may be 8, 12, or 16 bits; all SIDs used with a given SA MUST have the same length. An 8-bit SID with a 64-bit IV leaves 56 bits for the SSIV (Figure 1).