Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
obsoleted by
- rfc-4835 — Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
obsoletes
Extracted elements (21)
DES-CBC is marked SHOULD NOT (downgraded from MUST in RFC 2406) because the IETF deprecated single DES years ago; this document is the first standards-track recognition of that deprecation. NIST also formally proposed withdrawal of single DES in July 2004.
Future mandatory algorithms are identified today (marked SHOULD+) so they will already be widely implemented by the time they are promoted to MUST, facilitating smooth transitions.
HMAC-MD5-96 was downgraded from MUST (in RFC 2402/2406) to MAY because weaknesses have appeared in MD5, even though those weaknesses are not considered to directly affect HMAC-MD5.
Mandatory-to-implement algorithm requirements are placed in this separate document rather than the main IPsec, ESP, or AH specifications so that as algorithm choices change over time, only this document needs to be updated.
The choice of mandatory-to-implement algorithms should be conservative to minimize the likelihood of compromise, while also considering performance since many IPsec deployments are performance-sensitive.
For IPsec implementations to interoperate, they must support one or more security algorithms in common; this document defines the minimum common set for ESP and AH to guarantee at least one shared algorithm across all conformant implementations.
This document obsoletes RFC 2404 and RFC 2406, consolidating algorithm requirements for both AH and ESP that were previously split across the two protocol specifications.
AH implementations MAY implement HMAC-MD5-96 (RFC 2403); MD5 weaknesses are noted but do not affect HMAC-MD5.
AH implementations MUST support HMAC-SHA1-96 (RFC 2404) for authentication.
AH implementations SHOULD+ implement AES-XCBC-MAC-96 (RFC 3566), which is likely to be promoted to MUST in a future revision.
ESP implementations MAY implement HMAC-MD5-96 (RFC 2403) for authentication; weaknesses in MD5 are noted but considered not to affect the HMAC construction.
ESP implementations MUST support HMAC-SHA1-96 for authentication and MUST support NULL authentication.
ESP implementations MUST support the NULL encryption algorithm to maintain consistency with service negotiation, but encryption and authentication MUST NOT both be NULL simultaneously.
ESP implementations MUST- support TripleDES-CBC encryption (RFC 2451); this algorithm is currently mandatory but expected to eventually lose that status.
ESP implementations SHOULD+ implement AES-CBC with 128-bit keys (RFC 3602), indicating this algorithm is likely to be promoted to MUST in the future.
ESP implementations SHOULD implement AES-CTR (RFC 3686) for encryption.
ESP implementations SHOULD+ implement AES-XCBC-MAC-96 (RFC 3566) for authentication, as it is likely to be promoted to MUST.
ESP implementations SHOULD NOT implement DES-CBC (RFC 2405) due to its small key size and demonstrated vulnerability to special-purpose cracking hardware.
Algorithm selection for a particular ESP or AH security association is determined by a negotiation mechanism such as IKE (RFC 2409, IKEv2) or pre-establishment, not hardcoded.
ESP combined mode algorithms provide both confidentiality and authentication in a single algorithm, requiring proper ESP implementation structuring. No combined algorithm is currently required, but AES-CCM is identified as likely to be of near-future interest.
Security of cryptographic systems depends on both the strength of the chosen algorithms and the keys used; it also depends on correct protocol engineering to eliminate non-cryptographic bypass paths. All algorithms currently specified are believed unbroken but may be compromised in the future, necessitating periodic document updates.