RFC 9395 | IKEv1 Deprecation | April 2023 |
Wouters | Standards Track | [Page] |
Internet Key Exchange Version 1 (IKEv1) has been deprecated, and RFCs 2407, 2408, and 2409 have been moved to Historic status. This document updates RFCs 8221 and 8247 to reflect the usage guidelines of old algorithms that are associated with IKEv1 and are not specified or commonly implemented for IKEv2. This document further updates the IANA registries for IKEv2 "Transform Type Values" by adding a "Status" column where the deprecation status can be listed.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9395.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
IKEv1 has been moved to Historic status. IKEv1 [RFC2409] and its related documents for the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408] and IPsec DOI [RFC2407] were obsoleted by IKEv2 [RFC4306] in December 2005. The latest version of IKEv2 at the time of writing was published in 2014 [RFC7296]. Since IKEv2 replaced IKEv1 over 15 years ago, IKEv2 has now seen wide deployment, and it provides a full replacement for all IKEv1 functionality. No new modifications or new algorithms have been accepted for IKEv1 for at least a decade. IKEv2 addresses various issues present in IKEv1, such as IKEv1 being vulnerable to amplification attacks.¶
Algorithm implementation requirements and usage guidelines for IKEv2 [RFC8247] and Encapsulating Security Payload (ESP) and Authentication Header (AH) [RFC8221] gives guidance to implementors but limits that guidance to avoid broken or weak algorithms. These two RFCs do not deprecate algorithms that have aged and are not in use. Instead, they leave these algorithms in a state of "MAY be used" by not mentioning them. This document deprecates those unmentioned algorithms that are no longer advised but for which there are no known attacks resulting in their earlier deprecation.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
As IKEv1 is deprecated, systems running IKEv1 should be upgraded and reconfigured to run IKEv2. Systems that support IKEv1 but not IKEv2 are most likely also unsuitable candidates for continued operation for the following reasons:¶
IKEv2 is a more secure protocol than IKEv1. For example, IKEv2 offers more modern cryptographic primitives, proper defense against denial-of-service attacks, improved authentication via Extensible Authentication Protocol (EAP) methods, and password-authenticated key exchange (PAKE) support. Also, IKEv2 is actively worked on with respect to defending against quantum-computer attacks.¶
IKEv1-only systems should be upgraded or replaced by systems supporting IKEv2. IKEv2 implementations SHOULD NOT directly import IKEv1 configurations without updating the cryptographic algorithms used.¶
A few notable IKEv1 features are not present in the IKEv2 core specification [RFC7296] but are available for IKEv2 via an additional specification.¶
IKEv1 and its way of using Preshared Keys (PSKs) protects against quantum-computer-based attacks. IKEv2 updated its use of PSKs to improve the error reporting but at the expense of post-quantum security. If post-quantum security is required, these systems should be migrated to use IKEv2 Post-quantum Preshared Keys (PPKs) [RFC8784].¶
Some IKEv1 implementations support Labeled IPsec, a method to negotiate an additional Security Context selector to the Security Policy Database (SPD), but this method was never standardized in IKEv1. Those IKEv1 systems that require Labeled IPsec should migrate to an IKEv2 system supporting Labeled IPsec as specified in [LABELED-IPSEC].¶
The Group Domain of Interpretation (GDOI) protocol [RFC6407], which is based on IKEv1, defines the support for Multicast Group SAs. For IKEv2, this work is currently in progress via [G-IKEV2].¶
This document deprecates the following algorithms:¶
There are only security benefits if IKEv1 is deprecated and IKEv2 is used.¶
The deprecated algorithms have long been in disuse and are no longer actively deployed or researched; this presents an unknown security risk that is best avoided. Additionally, these algorithms not being supported in implementations simplifies those implementations and reduces the accidental use of deprecated algorithms through misconfiguration or downgrade attacks.¶
IANA has added the following line at the top of the Notes section of the "Internet Key Exchange (IKE) Attributes" and '"Magic Numbers" for ISAKMP Protocol' registries: "All registries listed below have been closed. See RFC 9395." In addition, this document has been added to the "Reference" column in these two registries, and their registration procedures have been changed to "Registry closed".¶
IANA has added a "Status" column to the following IKEv2 "Transform Type Values" registries:¶
Also, the following entries have been marked as DEPRECATED:¶
Number | Name | Status |
---|---|---|
1 | ENCR_DES_IV64 | DEPRECATED (RFC 9395) |
2 | ENCR_DES | DEPRECATED [RFC8247] |
4 | ENCR_RC5 | DEPRECATED (RFC 9395) |
5 | ENCR_IDEA | DEPRECATED (RFC 9395) |
6 | ENCR_CAST | DEPRECATED (RFC 9395) |
7 | ENCR_BLOWFISH | DEPRECATED (RFC 9395) |
8 | ENCR_3IDEA | DEPRECATED (RFC 9395) |
9 | ENCR_DES_IV32 | DEPRECATED (RFC 9395) |
Number | Name | Status |
---|---|---|
1 | PRF_HMAC_MD5 | DEPRECATED [RFC8247] |
3 | PRF_HMAC_TIGER | DEPRECATED (RFC 9395) |
Number | Name | Status |
---|---|---|
1 | AUTH_HMAC_MD5_96 | DEPRECATED [RFC8247] |
3 | AUTH_DES_MAC | DEPRECATED [RFC8247] |
4 | AUTH_KPDK_MD5 | DEPRECATED [RFC8247] |
6 | AUTH_HMAC_MD5_128 | DEPRECATED (RFC 9395) |
7 | AUTH_HMAC_SHA1_160 | DEPRECATED (RFC 9395) |
Number | Name | Status |
---|---|---|
1 | 768-bit MODP Group | DEPRECATED [RFC8247] |
22 | 1024-bit MODP Group with 160-bit Prime Order Subgroup | DEPRECATED [RFC8247] |
All entries not mentioned here should receive no value in the new Status field.¶