Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
obsoleted by
- rfc-7321 — Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
obsoletes
- rfc-4305 — Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
Extracted elements (21)
AES-CBC encryption for ESP was promoted from SHOULD+ (RFC 4305) to MUST in this document, reflecting its maturation as a widely deployed and well-understood algorithm appropriate for mandatory status.
Mandatory-to-implement algorithm selection is placed in a separate document (this one) rather than the main IPsec, ESP, or AH specifications so that only this document needs updating as the choice of algorithms changes over time.
NULL Authentication for ESP was downgraded from MUST (RFC 4305) to MAY in this document to align with RFC 4301, which already permitted omitting authentication when using combined-mode algorithms.
The choice of mandatory-to-implement algorithms should be conservative to minimize the likelihood of compromise, while also considering performance in environments where it matters. Algorithms believed secure today may be demonstrated weak tomorrow.
DES-CBC was formerly MUST in RFC 2406 but is now SHOULD NOT; TripleDES-CBC remains MUST- pending future deprecation. HMAC-MD5-96 was formerly MUST in both RFC 2402 and RFC 2406 but is now MAY.
The security algorithms used for any particular ESP or AH SA are determined by a negotiation mechanism such as IKE (RFC 2409, RFC 4306) or pre-establishment; the mandatory algorithms ensure at least one common algorithm across all conformant implementations.
AH implementations MAY support HMAC-MD5-96 [RFC2403]; while MD5 collision weaknesses are known, these do not affect its use within HMAC.
AH implementations MUST support HMAC-SHA1-96 [RFC2404] as the mandatory authentication algorithm.
AH implementations SHOULD+ support AES-XCBC-MAC-96 [RFC3566], which is likely to be promoted to MUST in a future revision.
ESP implementations MAY support NULL authentication and MAY support HMAC-MD5-96 [RFC2403], but both encryption and authentication MUST NOT simultaneously be NULL [RFC4301].
ESP implementations MUST support AES-CBC with 128-bit keys [RFC3602] as a mandatory encryption algorithm.
ESP implementations MUST support HMAC-SHA1-96 [RFC2404] as the mandatory authentication algorithm.
ESP implementations MUST support the NULL encryption algorithm [RFC2410] to maintain consistency with service negotiation, since ESP encryption is optional.
ESP implementations MUST- support TripleDES-CBC [RFC2451]; this algorithm is currently mandatory but is expected to be demoted in the future.
ESP implementations SHOULD NOT use DES-CBC [RFC2405] due to its small key size and publicly demonstrated vulnerability to special-purpose cracking hardware.
ESP implementations SHOULD support AES-CTR [RFC3686] for encryption, as it may be promoted to MUST in the future.
ESP implementations SHOULD+ support AES-XCBC-MAC-96 [RFC3566] for authentication; this algorithm is likely to be promoted to MUST in a future revision.
ESP combined mode algorithms provide both confidentiality and authentication in a single pass. AES-CCM [RFC4309] and AES-GCM [RFC4106] are identified as algorithms of interest, adopted as preferred modes in IEEE 802.11i and IEEE 802.1ae respectively.
DES-CBC is of questionable security due to its small key size and the existence of publicly demonstrated, open-design special-purpose cracking hardware; implementations SHOULD NOT provide single DES.
Known collision weaknesses in SHA-1 and MD5 do not affect their use within HMAC constructions (HMAC-SHA1-96 and HMAC-MD5-96), but implementations should track cryptographic developments as these algorithms may be further weakened.
The security of cryptography-based systems depends on both the strength of chosen algorithms and the keys used with them, as well as proper engineering and administration to prevent non-cryptographic bypass. Algorithms identified as MUST or SHOULD implement are not known to be broken but may be broken in the future, necessitating periodic revision of this document.