Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
obsoleted by
- rfc-8221 — Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
obsoletes
- rfc-4835 — Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
Extracted elements (24)
AES-CTR is demoted from SHOULD to MAY because AES-GCM has all the advantages of AES-CTR (efficient counter mode) while also providing authentication, making AES-CTR a strictly inferior choice when AES-GCM is available.
AES-XCBC-MAC-96 is downgraded from SHOULD+ to SHOULD because despite previous promotion in RFC 4835, it has not seen widespread deployment.
Authenticated encryption algorithms (like AES-GCM) are encouraged because they provide significant efficiency and throughput advantages, and the tight binding between authentication and encryption is a security advantage over separately applied transforms.
DES-CBC is elevated from SHOULD NOT to MUST NOT because of its small key size, small 64-bit block size, and the existence of publicly demonstrated open-design special-purpose cracking hardware.
HMAC-SHA-256/384/512 are not recommended for new implementations despite good security margins because HMAC-SHA-1 has widespread support and adequate security, AES-GMAC offers better performance, and authenticated encryption algorithms remove the need for separate authentication.
NULL encryption is required (MUST implement) to maintain consistency with the way services are negotiated in ESP, since ESP encryption is optional and negotiation must be able to express the no-encryption case.
The rationale for retaining Triple-DES to provide algorithm diversity against AES failure is disappearing because Triple-DES cannot serve as an AES alternative in high data rate environments or performance-constrained settings; backwards compatibility remains the sole justification.
Triple-DES is demoted from MUST- to MAY due to its small 64-bit block size causing information leakage above the birthday bound, worse performance than AES, and smaller key size than AES; it is retained only for backwards compatibility.
The IPsec community generally prefers ESP with NULL encryption over AH for authentication-only use cases. AH is still required in some protocols and environments where IP header options like source routing headers must be protected, since ESP inherently cannot protect those IP options.
This document obsoletes RFC 4835 and summarizes changes: AES-GCM and AES-GMAC are promoted from MAY to SHOULD+; TripleDES-CBC is demoted from MUST- to MAY; DES-CBC is promoted from SHOULD NOT to MUST NOT; AES-XCBC-MAC-96 is demoted from SHOULD+ to SHOULD; AES-CTR is demoted from SHOULD to MAY.
AES-GCM with a 16 octet ICV (RFC 4106) SHOULD+ be implemented for ESP authenticated encryption (combined mode). AES-CCM (RFC 4309) MAY be implemented.
AH authentication algorithm requirements are identical to ESP authentication algorithm requirements, except that NULL authentication is inapplicable to AH.
All AES mode requirements specified in this document are for 128-bit AES. 192-bit and 256-bit AES MAY be supported for those modes.
An encryption transform MUST NOT be used with a NULL authentication transform, unless the encryption transform is an authenticated encryption transform from Section 2.1. NULL authentication and NULL encryption MUST NOT both be used simultaneously.
Confidentiality without authentication SHOULD NOT be used because the lack of authentication undermines the trustworthiness of encryption.
For ESP authentication, HMAC-SHA1-96 (RFC 2404) MUST be implemented. AES-GMAC with AES-128 (RFC 4543) SHOULD+ be implemented. AES-XCBC-MAC-96 (RFC 3566) SHOULD be implemented. NULL authentication MAY be implemented.
For ESP encryption, NULL (RFC 2410) and AES-CBC (RFC 3602) MUST be implemented. AES-CTR (RFC 3686) and TripleDES-CBC (RFC 2451) MAY be implemented. DES-CBC (RFC 2405) MUST NOT be implemented.
It is NOT RECOMMENDED to use ESP with NULL authentication in conjunction with AH; some configurations of this combination have been shown to be insecure.
To provide both confidentiality and authentication, an authenticated encryption transform from Section 2.1 SHOULD be used in ESP with NULL authentication. Alternatively, an ESP encryption transform and ESP authentication transform MAY be used together.
Triple-DES SHOULD NOT be used in any scenario in which multiple gigabytes of data will be encrypted with a single key due to the birthday bound of its 64-bit block size.
ESP combined mode (authenticated encryption) algorithms provide both confidentiality and authentication in a single transform and are listed in the ESP encryption transforms IANA registry. These are preferred over separate encryption and authentication transforms.
The document defines extended requirement keywords MUST- (currently MUST but expected to be demoted) and SHOULD+ (currently SHOULD but likely to be promoted to MUST) to signal anticipated future changes in algorithm requirements.
SHA-1 has been found to not meet its collision resistance goal; however, HMAC-SHA-1 does not rely on collision resistance and is believed to remain secure. MD5's collision resistance is broken, making its use in digital signatures highly discouraged, though HMAC-MD5 has no known practical vulnerability.
The security of a cryptographic system depends on the strength of the chosen algorithms, the strength of the keys, and the engineering and administration of the protocol to prevent non-cryptographic bypasses. The algorithms identified as MUST or SHOULD implement are not known to be broken at time of publication but may need revision as cryptographic research advances.