Cryptographic Suites for IPsec
Extracted elements (14)
Although UI suites are optional to implement, the document is on the standards track because implementers who use these suite names must conform to the exact values defined here, ensuring that the names have consistent meaning across implementations.
The suites listed are intended specifically for VPN use of IPsec; other IPsec use cases are expected to define their own suites with different names rather than reusing VPN-A or VPN-B.
UI suites are optional named configurations introduced because implementation experience showed that the large number of algorithm choices in IPsec made it difficult for administrators to achieve interoperability without careful pre-agreement. A small number of named suites covering typical security policies simplifies administration.
Use of UI suites does not change the IPsec, IKE, or IKEv2 protocols; the transform substructure in IKE and IKEv2 must still be used to convey each option value regardless of whether UI suites are used.
Implementations that use UI suites SHOULD also provide a management interface for specifying values for individual cryptographic options, since UI suites alone are unlikely to cover all security policy needs.
In VPN-A, if the initiator includes a new Diffie-Hellman key during rekeying, it MUST be of type 1024-bit MODP, and the responder MUST also include a Diffie-Hellman key of type 1024-bit MODP.
In VPN-B, if the initiator includes a new Diffie-Hellman key during rekeying, it MUST be of type 2048-bit MODP, and the responder MUST also include a Diffie-Hellman key of type 2048-bit MODP.
IPsec implementations that use these UI suites SHOULD use the suite names listed in this document, SHOULD NOT use different names for the described suites, and MUST NOT use the listed names for suites that do not match these values.
Rekeying of Phase 2 (IKEv1) or CREATE_CHILD_SA (IKEv2) MUST be supported by both parties in the VPN-B suite.
Systems using IKEv1 with either VPN-A or VPN-B MUST use an SA lifetime of 86400 seconds (1 day) for Phase 1 and 28800 seconds (8 hours) for Phase 2.
Suite 'VPN-A' defines a named cryptographic configuration for IPsec VPNs matching commonly used corporate VPN security at the time of publication. IPsec uses ESP with TripleDES-CBC encryption and HMAC-SHA1-96 integrity; IKE/IKEv2 uses TripleDES-CBC encryption, HMAC-SHA1 PRF, HMAC-SHA1-96 integrity, and 1024-bit MODP Diffie-Hellman.
Suite 'VPN-B' defines a named cryptographic configuration expected to represent next-generation corporate VPN security. IPsec uses ESP with AES-128-CBC encryption and AES-XCBC-MAC-96 integrity; IKE/IKEv2 uses AES-128-CBC encryption, AES-XCBC-PRF-128 PRF, AES-XCBC-MAC-96 integrity, and 2048-bit MODP Diffie-Hellman.
IANA created a registry called 'Cryptographic Suites for IKEv1, IKEv2, and IPsec' consisting of a text string identifier and an RFC number listing associated transforms. New entries require RFC publication and approval by an IESG-designated expert. Initial entries are VPN-A and VPN-B, both defined in RFC 4308.
Some security options specified in these suites may be found in the future to have properties significantly weaker than those believed at the time of this document's production. This document inherits all security considerations of the IPsec, IKE, and IKEv2 documents.