Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)
Extracted elements (16)
AES-GMAC can be computed using an AES-GCM implementation by supplying the content-authentication key as the AES key, the nonce as the IV, zero-length plaintext, and the content to authenticate as AAD. The encryption step is skipped when no plaintext is provided, so no ciphertext is produced.
The DEFAULT and RECOMMENDED values in GMACParameters were chosen to align with AES-GCM parameters defined in Section 3.2 of RFC 5084, ensuring consistency across CMS authenticated encryption algorithms.
The ASN.1 module CryptographicMessageSyntaxGMACAlgorithms imports MAC-ALGORITHM and AlgorithmIdentifier from AlgorithmInformation-2009 (RFC 5912), ensuring compatibility with existing CMS infrastructure.
A nonce value of 12 octets is RECOMMENDED for processing efficiency.
For all three AES-GMAC algorithm identifier values (128, 192, 256-bit), the AlgorithmIdentifier parameters field MUST be present and MUST contain GMACParameters.
The GMACParameters length field MUST match the size in octets of the value in the AuthenticatedData mac field. A length of 12 octets is RECOMMENDED.
The GMACParameters nonce field MUST be a multiple of 8 bits. Within the scope of any content-authentication key, the nonce value MUST be unique.
AES-GMAC algorithm identifiers for use in CMS AuthenticatedData macAlgorithm field: id-aes128-GMAC (aes 9), id-aes192-GMAC (aes 29), and id-aes256-GMAC (aes 49), corresponding to 128-bit, 192-bit, and 256-bit AES keys respectively.
IANA registered OID decimal 72 (id-mod-aes-gmac-alg-2020) in the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry, referencing RFC 9044.
If AES-GMAC is used as a building block in another algorithm (e.g., as a pseudorandom function), AES-GMAC MUST be used only one time. For instance, AES-GMAC MUST NOT be used as the pseudorandom function for PBKDF2.
Implementations must randomly generate message-authentication keys using adequate PRNGs. Use of inadequate PRNGs can result in little or no security, as an attacker may reproduce the PRNG environment rather than brute-force the key space.
The probability of a successful forgery is close to 2^(-t), where t is the number of bits in the authentication tag (MACLength*8). Implementations SHOULD use 16-octet authentication tags for messages over 2^64 octets, as GMAC strength degrades with message length.
When IV lengths other than 96 bits are used, the GHASH function processes the IV, introducing potential for IV collisions. This is not a concern with CMS AuthenticatedData because a fresh content-authentication key is usually generated per message.
When more than two parties share the same message-authentication key, data origin authentication is not provided; any party knowing the key can compute a valid MAC. The key management technique must itself provide authentication.
Within the scope of any content-authentication key, the authentication tag length (MACLength) MUST be fixed.
GMACParameters is an ASN.1 SEQUENCE containing a nonce (OCTET STRING, recommended 12 octets) and length (MACLength, DEFAULT 12). MACLength is constrained to INTEGER values 12, 13, 14, 15, or 16 octets.