AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP)
Extracted elements (31)
AES-GCM does not require data to be padded to a specific block size, reducing the need for the RTP padding mechanism. It is RECOMMENDED that RTP padding not be used unless necessary to disguise the length of the underlying plaintext.
AES-GCM uses Counter Mode for encryption (efficiently pipelined) and Galois Message Authentication Code (GMAC) for authentication (operations particularly well-suited for efficient hardware implementation). This makes AES-GCM especially appealing for high-speed implementations or compact circuit designs.
The optional SRTP/SRTCP authentication tag field is retained (even though NOT RECOMMENDED) primarily to preserve compatibility with applications such as RFC 4771 that use the authentication tag as a means of conveying additional information.
This document's guidance that SRTCP authentication tags SHOULD NOT be present contradicts Section 3.4 of RFC 3711, which makes the SRTCP authentication tag field mandatory. The presence of AEAD authentication renders the older authentication methods redundant.
When RFC 6904 header extension encryption is in use, both encrypted and unencrypted header extensions are treated by the AEAD algorithm as Associated Data. The AEAD algorithm provides integrity and authentication for header extensions but does not provide additional privacy beyond any RFC 6904 encryption already applied.
A new master key MUST be established before the 31-bit SRTCP index cycles back to its original value. Ideally, rekeying should be performed well before the index cycles.
A rekey MUST be performed to establish a new master key before the (ROC,SEQ) pair cycles back to its original value. For GCM, the (ROC,SEQ) and SSRC values MUST be generated or checked by the SRTP implementation or an equally trustworthy module.
AEAD_AES_128_GCM MUST use the 128-bit AES_CM PRF Key Derivation Function described in RFC 3711. AEAD_AES_256_GCM MUST use the AES_256_CM_PRF KDF described in RFC 6188.
All incoming packets MUST pass AEAD authentication before any other action takes place. Plaintext and Associated Data MUST NOT be released until the AEAD authentication tag has been validated, and the ciphertext MUST NOT be decrypted until the AEAD tag has been validated.
All SRTCP compound packets MUST be authenticated, but unlike SRTP, SRTCP packet encryption is optional. A sender indicates the choice with a 1-bit Encryption flag located just before the 31-bit SRTCP index.
All SRTP packets MUST be both authenticated and encrypted. Even if the Plaintext field is empty, AEAD encryption must still be performed, resulting in a cipher consisting solely of the 16-octet authentication tag.
Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM and AEAD_AES_256_GCM.
At the start of each packet, the Block Counter MUST be reset to 1 and MUST NOT be allowed to exceed 2^32-1 for GCM. Processing MUST cease if either the 31-bit SRTCP index or the 48-bit SRTP packet index (ROC||SEQ) cycles back to its initial value; processing MUST NOT resume until a new session is established with a new master key.
For AEAD_AES_128_GCM, the keystream used for RFC 6904 header extension encryption MUST be generated using AES Counter Mode (AES-CM). For AEAD_AES_256_GCM, the keystream MUST be generated using the AES_256_CM transform. Header extension encryption must be performed before the AEAD algorithm is invoked.
SRTP using GCM with shared master keys MUST prevent an SSRC collision from happening even once. Each originating endpoint MUST only issue SSRC values from its assigned disjoint pool, MUST maintain a history of issued SSRCs, and MUST NOT reuse any previously issued SSRC identifier within the current master key lifetime.
The AEAD authentication tag MUST NOT be truncated; authentication tags MUST be a full 16 octets in length when AES-GCM is used in SRTP/SRTCP. Two configurations are defined: AEAD_AES_128_GCM (AES-128, 16-octet tag) and AEAD_AES_256_GCM (AES-256, 16-octet tag).
The AEAD message authentication mechanism MUST be the primary authentication mechanism for AEAD SRTP/SRTCP. Additional SRTP/SRTCP authentication mechanisms SHOULD NOT be used with any AEAD algorithm, and the optional SRTP/SRTCP authentication tags are NOT RECOMMENDED.
The master key MUST be at least as large as the encryption key derived from it. The master salt and all derived keys MUST be kept secret and properly erased when no longer needed.
AEAD algorithms used with SRTP/SRTCP must support: minimum Associated Data length of 12 octets, nonce (IV) length of exactly 12 octets, 16-octet authentication tag, GCM plaintext up to 2^36-32 octets per invocation, and a maximum of 2^48 invocations for SRTP or 2^31 for SRTCP per instantiation.
In an encrypted SRTCP packet (Encryption flag = 1), the RTCP common header fields, SSRC, Encryption flag, and SRTCP index are Associated Data; all RTCP payload data is Plaintext; the optional MKI and authentication tag are Raw Data. The AEAD ciphertext is exactly the length of the plaintext plus 16 octets for the tag.
In an SRTP packet, the RTP fixed header fields (V, P, X, CC, M, PT, sequence number, timestamp, SSRC, optional CSRC, optional RTP extension) are Associated Data (authenticated only); the RTP payload and any padding are Plaintext (encrypted and authenticated); the optional MKI and SRTP authentication tag are Raw Data appended after encryption.
In an unencrypted SRTCP packet (Encryption flag = 0), all RTCP data and the SRTCP index are Associated Data (authenticated only) and there is no Plaintext. GCM still produces a cipher consisting solely of the 16-octet authentication tag, placed before the Encryption flag and SRTCP index.
Two AES-GCM crypto suites are defined for SRTP/SRTCP: AEAD_AES_128_GCM (16-octet master key, 96-bit salt, AES_CM PRF KDF, 128-bit auth tag, lifetime up to 2^48 SRTP / 2^31 SRTCP packets) and AEAD_AES_256_GCM (32-octet key, same salt and tag sizes, AES_256_CM_PRF KDF, same lifetimes).
IANA registered two DTLS-SRTP protection profiles: SRTP_AEAD_AES_128_GCM = {0x00, 0x07} (128-bit key, 96-bit salt, 16-octet AEAD tag, no separate auth function) and SRTP_AEAD_AES_256_GCM = {0x00, 0x08} (256-bit key, same salt and tag).
IANA registered two entries in the SDP Security Descriptions 'SRTP Crypto Suite Registrations' subregistry: AEAD_AES_128_GCM and AEAD_AES_256_GCM.
IANA updated two MIKEY subregistries: added AEAD authentication tag length type 20 (value: 16 octets) to the 'MIKEY Security Protocol Parameters' subregistry, and added AES-GCM with value 6 (16-octet default key, 16-octet auth tag) to the 'Encryption algorithm (Value 0)' subregistry.
IV reuse is catastrophic for GCM: using the same (IV, Encryption_key) pair twice produces identical keystreams, compromising GCM's integrity mechanism not only for the current packet stream but for all future uses of the current encryption key.
The full 16-octet (128-bit) AEAD authentication tag is required to effectively eliminate the risk of an adversary successfully introducing fraudulent data. The risks associated with using truncated AES-GCM tags are deemed too high; truncated authentication tags are not permitted in SRTP/SRTCP.
When a rekey occurs, the initial values of both the 31-bit SRTCP index and the 48-bit SRTP packet index (ROC||SEQ) MUST be saved to prevent IV reuse. If either counter reaches its initial value, processing must cease and a new SRTP/SRTCP session must be established.
The 12-octet SRTCP IV for AES-GCM is formed by concatenating 2 zero octets, the 4-octet SSRC, 2 zero octets, a single '0' bit, and the 31-bit SRTCP index, then XORing the 12-octet result with the 12-octet encryption salt.
The 12-octet SRTP IV for AES-GCM is formed by concatenating 2 zero octets, the 4-octet SSRC, the 4-octet Rollover Counter (ROC), and the 2-octet sequence number (SEQ), then XORing the 12-octet result with the 12-octet encryption salt.