]> Ericsson

magnus.westerlund@ericsson.com

Ericsson

john.mattsson@ericsson.com

ART Audio/Video Transport Core Maintenance Cipher Suite GCM-SST SRTP This document defines how the GCM-SST (Galois Counter Mode with Strong Secure Tags) Authenticated Encryption with Associated Data (AEAD) algorithm family can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP). GCM-SST addresses known weaknesses in AES-GCM for short authentication tags, making it well suited for media encryption use cases where low overhead is critical. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Audio/Video Transport Core Maintenance (AVTCORE) Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Secure Real-time Transport Protocol (SRTP) is a profile of the Real-time Transport Protocol (RTP) , which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). Authenticated Encryption with Associated Data (AEAD) provides both confidentiality and integrity in a single cryptographic operation. This specification makes use of the GCM-SST (Galois Counter Mode with Strong Secure Tags) AEAD algorithm family defined in . AES-GCM is widely used but has known weaknesses when used with short authentication tags. The forgery probability for AES-GCM is significantly worse than ideal, and a successful forgery reveals the authentication subkey H, enabling an attacker to forge all subsequent messages. GCM-SST addresses these weaknesses by introducing an additional subkey H2 and deriving fresh subkeys H and H2 for each nonce, resulting in near-ideal forgery probabilities even for short tags and even after multiple forgery attempts. Short authentication tags are common in media encryption. 32-bit tags are standard in most radio link layers, 64-bit tags are common in IoT transport and application layers, and 32-, 64-, and 80-bit tags are common in media encryption applications. Audio packets are small, numerous, and ephemeral, making them highly sensitive to cryptographic overhead. GCM-SST enables the use of short tags with strong security guarantees, avoiding the need to either use larger-than-necessary tags or fall back to slower constructions such as AES-CTR combined with HMAC. This document defines how to use the AES-128-GCM-SST, AES-256-GCM-SST, and Rijndael-GCM-SST AEAD algorithms in SRTP and SRTCP, with authentication tag lengths of 48, 96, and 112 bits. The following cipher suites are defined:

When using cipher suites with 48-bit (6-octet) tags for SRTP, SRTCP uses 96-bit (12-octet) tags. This provides adequate security for the less frequent SRTCP packets while minimizing overhead for the more numerous SRTP packets. The Rijndael-GCM-SST cipher suites use Rijndael-256 (256-bit key, 256-bit block) in counter mode as the keystream generator. Rijndael-256 uses a 28-octet (224-bit) nonce, which requires a different IV formation than the AES-based cipher suites (see and ).

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms have specific meanings in this document:

Instantiation:

In AEAD, an instantiation is an (Encryption_key, salt) pair together with all data structures needed for it to function properly. In SRTP/SRTCP, each endpoint needs two instantiations of the AEAD algorithm for each master key: one for SRTP traffic and one for SRTCP traffic.

Invocation:

SRTP/SRTCP data streams are broken into packets. Each packet is processed by a single invocation of the appropriate instantiation of the AEAD algorithm.

Associated Data:

Data that is authenticated but not encrypted.

Plaintext:

Data that is both encrypted and authenticated.

Ciphertext:

The output of the AEAD encryption function, consisting of the encrypted Plaintext followed by the authentication tag.

Raw Data:

Data that is neither encrypted nor authenticated.

Overview of the SRTP/SRTCP AEAD Security Architecture SRTP/SRTCP AEAD security is based upon the following principles: a. Both privacy and authentication are based upon the use of symmetric algorithms. An AEAD algorithm such as GCM-SST combines privacy and authentication into a single process. b. A secret master key is shared by all participating endpoints. Any given master key MAY be used simultaneously by several endpoints to originate SRTP/SRTCP packets. c. A Key Derivation Function (KDF) is applied to the shared master key to form separate encryption keys and salting keys for SRTP and SRTCP. Since AEAD algorithms combine encryption and authentication into a single process, AEAD algorithms do not make use of separate authentication keys. d. The details of how the master key is established and shared between participants are outside the scope of this document. Any mechanism for rekeying an existing session is also outside the scope of this document. e. Each time GCM-SST is invoked to encrypt and authenticate an SRTP or SRTCP packet, a new Initialization Vector (IV) is used. For AES-based cipher suites, SRTP combines the 4-octet Synchronization Source (SSRC) identifier, the 4-octet Rollover Counter (ROC), and the 2-octet Sequence Number (SEQ) with the 12-octet encryption salt to form a 12-octet IV (see ). SRTCP combines the SSRC and 31-bit SRTCP index with the encryption salt to form a 12-octet IV (see ). For Rijndael-GCM-SST cipher suites, the same packet fields are combined with a 28-octet encryption salt to form a 28-octet IV (see and ).

Generic AEAD Processing

AEAD Invocation Inputs and Outputs

Encrypt Mode

The ciphertext consists of the encrypted Plaintext followed by the authentication tag.

Decrypt Mode

Handling of AEAD Authentication 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. Should the AEAD authentication tag prove to be invalid, the packet MUST be discarded.

GCM-SST Processing for SRTP

SRTP IV Formation for GCM-SST

(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ ]]>

The 12-octet IV used by AES-GCM-SST SRTP is formed by first concatenating 2 octets of zeroes, the 4-octet SSRC, the 4-octet rollover counter (ROC), and the 2-octet sequence number (SEQ). The resulting 12-octet value is then XORed with the 12-octet salt to form the IV.

SRTP IV Formation for Rijndael-GCM-SST

(+) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Initialization Vector (28 octets) |<--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

The 28-octet IV used by Rijndael-GCM-SST SRTP is formed by first concatenating 18 octets of zeroes, the 4-octet SSRC, the 4-octet rollover counter (ROC), and the 2-octet sequence number (SEQ). The resulting 28-octet value is then XORed with the 28-octet salt to form the IV. The larger salt provides significantly greater security against precomputation and multi-key attacks compared to the AES-based cipher suites.

Data Types in SRTP Packets All SRTP packets MUST be both authenticated and encrypted. The data fields within RTP packets are broken into Associated Data, Plaintext, and Raw Data as follows:

Associated Data:

The RTP header fields: version V (2 bits), padding flag P (1 bit), extension flag X (1 bit), CSRC count CC (4 bits), marker M (1 bit), Payload Type PT (7 bits), sequence number (16 bits), timestamp (32 bits), SSRC (32 bits), optional CSRC identifiers, and optional RTP extension.

Plaintext:

The RTP payload, RTP padding (if used), and RTP pad count (if used).

Raw Data:

The optional SRTP Master Key Identifier (MKI) and SRTP authentication tag (whose use is NOT RECOMMENDED).

Handling Header Extensions When is in use, a separate keystream is generated to encrypt selected RTP header extension elements. For GCM-SST cipher suites using AES-128 keys, this keystream MUST be generated using the AES_128_CM transform. For GCM-SST cipher suites using AES-256 keys (including the Rijndael-GCM-SST cipher suites), the keystream MUST be generated using the AES_256_CM transform. The originator MUST perform any required header extension encryption before the AEAD algorithm is invoked. Both encrypted and unencrypted header extensions are treated by the AEAD algorithm as Associated Data. The AEAD algorithm therefore provides integrity and authentication for header extensions but no additional privacy beyond what RFC 6904 provides.

Prevention of SRTP IV Reuse To prevent IV reuse, the (ROC, SEQ, SSRC) triple MUST never be used twice with the same master key. A rekey MUST be performed before the (ROC, SEQ) pair cycles back to its original value. For a given master key, the set of all SSRC values MUST be partitioned into disjoint pools, one per originating endpoint, and each endpoint MUST only use SSRC values from its assigned pool.

GCM-SST Processing for SRTCP All SRTCP compound packets MUST be authenticated. SRTCP packet encryption is optional and indicated by a 1-bit Encryption flag located just before the 31-bit SRTCP index. When using the AEAD_AES_128_GCM_SST_6, AEAD_AES_256_GCM_SST_6, or AEAD_RIJNDAEL_GCM_SST_6 cipher suites (which use 48-bit tags for SRTP), implementations MUST use 96-bit (12-octet) authentication tags for SRTCP packets. For all other cipher suites, the SRTCP tag length MUST match the SRTP tag length.

SRTCP IV Formation for AES-GCM-SST

(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ ]]>

The 12-octet IV used by AES-GCM-SST SRTCP is formed by concatenating 2 octets of zeroes, the 4-octet SSRC, 2 octets of zeroes, a single "0" bit, and the 31-bit SRTCP index. The resulting 12-octet value is then XORed with the 12-octet salt to form the IV.

SRTCP IV Formation for Rijndael-GCM-SST

(+) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Initialization Vector (28 octets) |<--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

The 28-octet IV used by Rijndael-GCM-SST SRTCP is formed by concatenating 18 octets of zeroes, the 4-octet SSRC, 2 octets of zeroes, a single "0" bit, and the 31-bit SRTCP index. The resulting 28-octet value is then XORed with the 28-octet salt to form the IV.

Data Types in Encrypted SRTCP Packets When the Encryption flag is set to 1:

Associated Data:

Version V (2 bits), padding flag P (1 bit), reception report count RC (5 bits), Packet Type (8 bits), length (2 octets), SSRC (4 octets), Encryption flag (1 bit), and SRTCP index (31 bits).

Plaintext:

All other data.

Raw Data:

The optional SRTCP MKI and SRTCP authentication tag (NOT RECOMMENDED).

Data Types in Unencrypted SRTCP Packets When the Encryption flag is set to 0:

Plaintext:

None.

Associated Data:

All data except the optional SRTCP MKI and authentication tag.

Raw Data:

The optional SRTCP MKI and SRTCP authentication tag (NOT RECOMMENDED).

Prevention of SRTCP IV Reuse A new master key MUST be established before the 31-bit SRTCP index cycles back to its original value. The comments on SSRC management in also apply to SRTCP.

Unneeded SRTP/SRTCP Fields

SRTP/SRTCP Authentication Tag Field The AEAD message authentication mechanism MUST be the primary message authentication mechanism. Additional SRTP/SRTCP authentication mechanisms SHOULD NOT be used, and the optional SRTP/SRTCP authentication tags are NOT RECOMMENDED and SHOULD NOT be present.

RTP Padding GCM-SST does not require data to be padded to a specific block size. It is RECOMMENDED that the RTP padding mechanism not be used unless necessary to disguise the length of the underlying Plaintext.

Constraints on AEAD for SRTP and SRTCP All AEAD algorithms used with SRTP/SRTCP MUST satisfy the following constraints: Parameter Meaning Value A_MAX Maximum Associated Data length MUST be at least 12 octets N_MIN Minimum nonce (IV) length 12 octets (AES) or 28 octets (Rijndael) N_MAX Maximum nonce (IV) length 12 octets (AES) or 28 octets (Rijndael) P_MAX Maximum Plaintext length 2^15 octets (AES) or 2^16 octets (Rijndael) C_MAX Maximum ciphertext length P_MAX + tag_length Additional parameters: E_MAX (maximum number of encryption invocations per key): E_MAX is 2^48 for SRTP and 2^31 for SRTCP. SRTP and SRTCP use separate derived keys and therefore have independent invocation counts. D_MAX (maximum number of decryption invocations per key): For AES-GCM-SST cipher suites, D_MAX is 2^54. For Rijndael-GCM-SST cipher suites, D_MAX is 2^118. For AES-GCM-SST, recommends that protocols enforce E_MAX · P_MAX / 16 ⪅ 2^59. With E_MAX of 2^48 and P_MAX of 2^15 octets, the product E_MAX · P_MAX / 16 = 2^59, which satisfies this bound. If an application requires larger packets, P_MAX MAY be increased provided that E_MAX is reduced accordingly so that E_MAX · P_MAX / 16 ⪅ 2^59 remains satisfied, and a rekey MUST be performed before E_MAX is reached. For Rijndael-GCM-SST, the 256-bit block size guarantees δ ≈ 1 without requiring this constraint, and P_MAX is set to 2^16 octets with E_MAX of 2^48.

Key Derivation Functions A Key Derivation Function (KDF) is used to derive all required encryption keys and salts from the shared master key. The AES-128-GCM-SST cipher suites MUST use the AES_128_CM_PRF KDF described in . The AES-256-GCM-SST and Rijndael-GCM-SST cipher suites MUST use the AES_256_CM_PRF KDF described in . For the Rijndael-GCM-SST cipher suites, the KDF MUST derive a 256-bit encryption key and a 224-bit (28-octet) encryption salt. The master salt for Rijndael-GCM-SST is 224 bits.

Summary of GCM-SST Cipher Suites in SRTP/SRTCP The following GCM-SST cipher suites are defined for use with SRTP/SRTCP: Name Key Size Tag Size AEAD_AES_128_GCM_SST_6 16 octets 6 octets AEAD_AES_128_GCM_SST_12 16 octets 12 octets AEAD_AES_128_GCM_SST_14 16 octets 14 octets AEAD_AES_256_GCM_SST_6 32 octets 6 octets AEAD_AES_256_GCM_SST_12 32 octets 12 octets AEAD_AES_256_GCM_SST_14 32 octets 14 octets AEAD_RIJNDAEL_GCM_SST_6 32 octets 6 octets AEAD_RIJNDAEL_GCM_SST_12 32 octets 12 octets AEAD_RIJNDAEL_GCM_SST_14 32 octets 14 octets Parameter AEAD_AES_128_GCM_SST_6 Master key length 128 bits Master salt length 96 bits Key Derivation Function AES_128_CM_PRF E_MAX (SRTP) 2^48 encryption invocations E_MAX (SRTCP) 2^31 encryption invocations D_MAX 2^54 decryption invocations AEAD authentication tag length 48 bits Parameter AEAD_AES_128_GCM_SST_12 Master key length 128 bits Master salt length 96 bits Key Derivation Function AES_128_CM_PRF E_MAX (SRTP) 2^48 encryption invocations E_MAX (SRTCP) 2^31 encryption invocations D_MAX 2^54 decryption invocations AEAD authentication tag length 96 bits Parameter AEAD_AES_128_GCM_SST_14 Master key length 128 bits Master salt length 96 bits Key Derivation Function AES_128_CM_PRF E_MAX (SRTP) 2^48 encryption invocations E_MAX (SRTCP) 2^31 encryption invocations D_MAX 2^54 decryption invocations AEAD authentication tag length 112 bits Parameter AEAD_AES_256_GCM_SST_6 Master key length 256 bits Master salt length 96 bits Key Derivation Function AES_256_CM_PRF E_MAX (SRTP) 2^48 encryption invocations E_MAX (SRTCP) 2^31 encryption invocations D_MAX 2^54 decryption invocations AEAD authentication tag length 48 bits Parameter AEAD_AES_256_GCM_SST_12 Master key length 256 bits Master salt length 96 bits Key Derivation Function AES_256_CM_PRF E_MAX (SRTP) 2^48 encryption invocations E_MAX (SRTCP) 2^31 encryption invocations D_MAX 2^54 decryption invocations AEAD authentication tag length 96 bits Parameter AEAD_AES_256_GCM_SST_14 Master key length 256 bits Master salt length 96 bits Key Derivation Function AES_256_CM_PRF E_MAX (SRTP) 2^48 encryption invocations E_MAX (SRTCP) 2^31 encryption invocations D_MAX 2^54 decryption invocations AEAD authentication tag length 112 bits Parameter AEAD_RIJNDAEL_GCM_SST_6 Master key length 256 bits Master salt length 224 bits Key Derivation Function AES_256_CM_PRF E_MAX (SRTP) 2^48 encryption invocations E_MAX (SRTCP) 2^31 encryption invocations D_MAX 2^118 decryption invocations AEAD authentication tag length 48 bits Parameter AEAD_RIJNDAEL_GCM_SST_12 Master key length 256 bits Master salt length 224 bits Key Derivation Function AES_256_CM_PRF E_MAX (SRTP) 2^48 encryption invocations E_MAX (SRTCP) 2^31 encryption invocations D_MAX 2^118 decryption invocations AEAD authentication tag length 96 bits Parameter AEAD_RIJNDAEL_GCM_SST_14 Master key length 256 bits Master salt length 224 bits Key Derivation Function AES_256_CM_PRF E_MAX (SRTP) 2^48 encryption invocations E_MAX (SRTCP) 2^31 encryption invocations D_MAX 2^118 decryption invocations AEAD authentication tag length 112 bits

Security Considerations

Handling of Security-Critical Parameters The following security-critical parameters must be handled properly: The master salt, if kept secret, MUST be properly erased when no longer needed. The secret master key and all keys derived from it MUST be kept secret and MUST be properly erased when no longer needed. Each time 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. Processing MUST cease if either the 31-bit SRTCP index or the 48-bit SRTP packet index cycles back to its initial value. Processing MUST NOT resume until a new session has been established using a new master key. GCM-SST MUST be used in a nonce-respecting setting. For a given key, a nonce MUST only be used once in the encryption function and only once in a successful decryption function call. Nonce reuse enables universal forgery.

Size of the Authentication Tag The GCM-SST tag_length SHOULD NOT be smaller than 4 octets. Unlike AES-GCM, GCM-SST provides near-ideal forgery probabilities even for short tags, making 48-bit tags suitable for applications such as audio packet encryption where overhead is critical. The 96-bit and 112-bit tag lengths provide higher security margins suitable for most other SRTP use cases. Implementations MUST use the tag length associated with the negotiated cipher suite and MUST NOT truncate or extend the tag.

Replay Protection GCM-SST MUST be used with replay protection. The SRTP sequence number and rollover counter, or the SRTCP index, provide the basis for replay protection. For examples of replay protection mechanisms, see and .

Rekeying Implementations SHOULD rekey well before reaching E_MAX. To minimize the impact of key compromise, rekeying via ephemeral key exchange providing forward secrecy SHOULD occur after at most 1 hour or 2^30 to 2^37 octets of data, whichever comes first.

Multicast and Broadcast Although GCM-SST offers stronger security than AES-GCM for short tags, it is not ideal in multicast or broadcast settings. A few successful forgeries against one or more recipients enable the attacker to create a new forgery targeting all other recipients sharing the same key. See Section 5.6 of for further details.

IANA Considerations

DTLS-SRTP DTLS-SRTP defines SRTP protection profiles. IANA is requested to register the following SRTP protection profiles:

The SRTP transform parameters for each protection profile are as follows:

MIKEY In accordance with , IANA is requested to add the following to the "Encryption algorithm (Value 0)" subregistry: SRTP Encr. Algorithm Value Default Session Encr. Key Length Default Auth. Tag Length AES-GCM-SST TBD10 16 octets variable RIJNDAEL-256-GCM-SST TBD11 32 octets variable

Parameters for Use with MIKEY MIKEY specifies the algorithm family separately from the key length and authentication tag length. AEAD Algorithm Encryption Algorithm Encryption Key Length AEAD Auth. Tag Length AEAD_AES_128_GCM_SST_6 AES-GCM-SST 16 octets 6 octets AEAD_AES_128_GCM_SST_12 AES-GCM-SST 16 octets 12 octets AEAD_AES_128_GCM_SST_14 AES-GCM-SST 16 octets 14 octets AEAD_AES_256_GCM_SST_6 AES-GCM-SST 32 octets 6 octets AEAD_AES_256_GCM_SST_12 AES-GCM-SST 32 octets 12 octets AEAD_AES_256_GCM_SST_14 AES-GCM-SST 32 octets 14 octets AEAD_RIJNDAEL_GCM_SST_6 RIJNDAEL-256-GCM-SST 32 octets 6 octets AEAD_RIJNDAEL_GCM_SST_12 RIJNDAEL-256-GCM-SST 32 octets 12 octets AEAD_RIJNDAEL_GCM_SST_14 RIJNDAEL-256-GCM-SST 32 octets 14 octets

This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real-time Transport Protocol is described in detail. Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. [STANDARDS-TRACK] This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK] This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure Realtime Transport Control Protocol (SRTCP) and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. [STANDARDS-TRACK] The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted. Amazon Web Services Ericsson Ericsson This document defines Galois Counter Mode with Strong Secure Tags (GCM-SST), an Authenticated Encryption with Associated Data (AEAD) algorithm that addresses several weaknesses of GCM. GCM-SST can be used with any keystream generator, not only 128-bit block ciphers. Main differences from GCM are the introduction of a second authentication subkey H_2, per-nonce derivation of both H and H_2, and stricter usage limits. Together, these changes yield authentication tags with near-ideal forgery probabilities, including reforgeability resistance. All registered instances have an expected number of forgeries E(F) ≈ v / 2^t, a property that GCM is far from providing. GCM-SST is designed for security protocols with replay protection such as TLS, QUIC, SRTP, and PDCP, and provides hardware and software performance comparable to GCM. This document registers nine AEAD algorithm instances using AES and Rijndael-256 in counter mode, with tag lengths of 48, 96, and 112 bits. GCM-SST has been standardized by 3GPP for use with SNOW 5G, AES-256, and ZUC-256. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) and Encapsulating Security Protocol (ESP). The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted. This document is not an Internet Standards Track specification; it is published for informational purposes.

Acknowledgments The authors would like to thank the authors of RFC 7714, David McGrew and Kevin Igoe, whose document structure this specification closely follows. The authors also thank the authors of , Matthew Campagna, Alexander Maximov, and John Preuß Mattsson, for defining the GCM-SST algorithm.