Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
obsoletes
- rfc-7321 — Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
updated by
- rfc-9395 — Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms
Extracted elements (30)
Algorithm deprecation is expected to be gradual (MUST → MUST- or SHOULD, not directly to MUST NOT) unless there are strong security reasons, to allow implementations time to update while remaining interoperable. New mandatory algorithms are introduced at SHOULD before MUST.
AUTH_HMAC_SHA2_512_256 is preferred over AUTH_HMAC_SHA2_384 because the additional overhead of SHA-512 over SHA-384 is negligible, while SHA-512 provides stronger security.
ENCR_AES_GCM_16 was promoted from SHOULD+ to MUST because it has been widely implemented for ESP due to increased performance and key longevity compared to ENCR_AES_CBC, and to favor authenticated encryption (AEAD) algorithms broadly.
ENCR_CHACHA20_POLY1305 was not ready for RFC 7321 but was subsequently recommended by the CFRG as an AES-CBC and AES-GCM alternative. Insufficient ESP implementations existed at time of writing to raise it above SHOULD; it is expected to become MUST long term.
The 256-bit key requirement for ENCR_AES_CBC and ENCR_AES_GCM_16 was raised from MAY (RFC 7321) to MUST because IPsec sessions may have very long lifetimes carrying multiple packets, necessitating longer keys for sustained security.
The document introduced IoT-specific requirement levels because IoT devices are resource-constrained and prioritize minimal code footprint, computation, and message size. Requirements marked '(IoT)' apply to IoT devices and server-side implementations that interoperate with them.
AUTH_HMAC_SHA2_256_128 has a long-standing common implementation bug that truncates the hash at 96 bits instead of 128 bits. Implementations that support AUTH_HMAC_SHA2_512_256 should prefer it over AUTH_HMAC_SHA2_256_128 to avoid this interoperability hazard.
ENCR_AES_CBC MUST be implemented to maintain interoperability with implementations that followed RFC 7321, even though the industry trend is toward AEAD algorithms and ENCR_AES_CBC is expected to be replaced in the long term.
IKEv1 is deprecated and out of scope for this document. The recommendations herein MUST NOT be considered for IKEv1, and IKEv1 parameters are not addressed. This document targets IKEv2-based deployments.
Algorithms allocated by IANA but unspecified by the IETF (marked UNSPECIFIED) and algorithms not intended for IPsec security (non-IPsec) MUST NOT be implemented for IPsec communications.
AUTH_AES_XCBC_96 is SHOULD for IoT deployments and MAY for general VPN use (downgraded from SHOULD in RFC 7321). AUTH_AES_128_GMAC and AUTH_AES_256_GMAC are MAY and should only be used for AH, not ESP.
AUTH_HMAC_SHA1_96 is MUST- (downgraded from MUST in RFC 7321) reflecting an industry-wide trend to deprecate its usage. AUTH_HMAC_MD5_96, AUTH_DES_MAC, and AUTH_KPDK_MD5 MUST NOT be used due to known vulnerabilities.
AUTH_HMAC_SHA2_256_128 MUST be implemented as the replacement for AUTH_HMAC_SHA1_96. AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement or when stronger security is required.
AUTH_NONE MUST NOT be selected except when AEAD authenticated encryption algorithms are used from Section 5. AUTH_NONE cannot be combined with ESP NULL encryption.
Compression algorithms IPCOMP_DEFLATE, IPCOMP_LZS, and IPCOMP_LZJH are all MAY as they are not widely deployed. IPCOMP_OUI MUST NOT be used (unspecified).
ENCR_3DES SHOULD NOT be implemented, downgraded from MAY in RFC 7321. ENCR_DES, ENCR_BLOWFISH, ENCR_DES_IV64, ENCR_DES_IV32, and ENCR_3IDEA MUST NOT be implemented.
ENCR_AES_CBC MUST be implemented for 128-bit and 256-bit keys to ensure interoperability with RFC 7321 implementations. 192-bit keys remain at MAY.
ENCR_AES_CCM_8 (AEAD) SHOULD be implemented at 128-bit keys for IoT interoperability, raised from MAY in RFC 7321. This requirement also applies to server-side implementations that need to interoperate with IoT devices.
ENCR_AES_GCM_16 (an AEAD cipher) MUST be implemented for 128-bit and 256-bit keys, upgraded from SHOULD+ in RFC 7321. 192-bit keys remain at MAY.
ENCR_CHACHA20_POLY1305 (AEAD) SHOULD be implemented as a modern alternative to AES-CBC and AES-GCM, recommended by the CFRG. It is expected to become MUST in the long term.
ENCR_NULL MUST be implemented to enable ESP with authentication-only (no encryption), which is preferred over AH due to NAT traversal compatibility.
Encryption without authentication MUST NOT be used. IPsec provides three valid combinations: ESP with AEAD cipher, ESP with non-AEAD cipher plus authentication, or ESP with non-AEAD cipher plus AH with authentication.
If manual keying is used, counter mode algorithms (ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM, ENCR_CHACHA20_POLY1305) MUST NOT be used, as they are incompatible with secure counter handling across reboots. ENCR_AES_CBC is the only mandatory-to-implement encryption algorithm suitable for manual keying.
Manual keying SHOULD NOT be used, as it lacks Perfect Forward Secrecy, session key refresh, SPI uniqueness tracking, and single-use enforcement of nonces, IVs, and counters. This document assumes keying uses IKEv2 or higher.
Using ESP+AH together (ESP for confidentiality only, AH for authentication) is NOT RECOMMENDED. It is the slowest method, increases header overhead, reduces effective MTU, and some configurations have been shown to be insecure.
ESP and AH authentication algorithm suite defines requirement levels for: AUTH_HMAC_SHA2_256_128 (MUST), AUTH_HMAC_SHA1_96 (MUST-), AUTH_HMAC_SHA2_512_256 (SHOULD), AUTH_AES_XCBC_96 (SHOULD/IoT or MAY), AUTH_AES_128/256_GMAC (MAY), and legacy algorithms (MUST NOT).
ESP encryption algorithm suite defines requirement levels for: ENCR_NULL (MUST), ENCR_AES_CBC (MUST), ENCR_AES_GCM_16 (MUST), ENCR_AES_CCM_8 (SHOULD/IoT), ENCR_CHACHA20_POLY1305 (SHOULD), ENCR_3DES (SHOULD NOT), and several legacy algorithms (MUST NOT).
Three valid methods of providing both encryption and authentication in IPsec: (1) ESP with AEAD cipher, (2) ESP with non-AEAD cipher plus authentication algorithm, (3) ESP with non-AEAD cipher plus AH (NOT RECOMMENDED).
Combining ESP NULL authentication (non-authenticated encryption) with AH is NOT RECOMMENDED; certain configurations have been shown to be insecure per Paterson and Degabriele (2010). AUTH_NONE cannot be combined with ESP NULL encryption.
The security of a cryptographic system depends on algorithm strength, key strength, and protocol engineering to prevent non-cryptographic bypass. Algorithms designated MUST or SHOULD in this document are not currently known to be broken but may require future revision.