RFC 9395 PROPOSED STANDARD IPSEC · DEPRECATION · CRYPTOGRAPHY
Deprecate IKEv1: Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms
IKEv1 is retired for good, and a batch of old, unused algorithms are marked deprecated in the IKEv2 registries.
RFC EDITOR
Wouters, P., Ed., "Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms", RFC 9395, DOI 10.17487/RFC9395, April 2023, <https://www.rfc-editor.org/info/rfc9395>.
BIBTEX
@misc{rfc9395,
series = {Request for Comments},
number = 9395,
howpublished = {RFC 9395},
publisher = {RFC Editor},
doi = {10.17487/RFC9395},
url = {https://www.rfc-editor.org/info/rfc9395},
author = {P. Wouters},
title = {{Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms}},
pagetotal = 7,
year = 2023,
month = apr,
} LINEAGE · FROM THE RFC INDEXOpen full graph →
RFC text
Contents
Internet Engineering Task Force (IETF) P. Wouters, Ed.
Request for Comments: 9395 Aiven
Updates: 8221, 8247 April 2023
Category: Standards Track
ISSN: 2070-1721
Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and
Obsoleted Algorithms
Abstract
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.
Status of This Memo
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 Notice
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.
Table of Contents
1. Introduction
2. Requirements Language
3. RFCs 2407, 2408, and 2409 Are Historic
4. IKEv1 Feature Equivalents for IKEv2
4.1. IKEv2 Post-Quantum Support
4.2. IKEv2 Labeled IPsec Support
4.3. IKEv2 Group SA and Multicast Support
5. Deprecating Obsolete Algorithms
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Author's Address
1. Introduction
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.
2. Requirements Language
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.
3. RFCs 2407, 2408, and 2409 Are Historic
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:
* IKEv1 development ceased over a decade ago, and no new work will
happen. This poses the risk of unmaintained code in an otherwise
supported product, which can result in security vulnerabilities.
* A number of IKEv1 systems have reached their End of Life and,
therefore, will never be patched by the vendor if a vulnerability
is found.
* There are vendors that still provide updates for their equipment
that supports IKEv1 and IKEv2 but have "frozen" their IKEv1
implementation. Such users might not be aware that they are
running unmaintained code with its associated security risks.
* IKEv1 systems can be abused for packet amplification attacks, as
documented in the Security Bulletin [CVE-2016-5361].
* Great strides have been made in cryptography since IKEv1
development ceased. While some modern cryptographic algorithms
were added to IKEv1, interoperability concerns mean that the
defacto algorithms negotiated by IKEv1 will consist of dated or
deprecated algorithms, like AES-CBC, SHA1, and Diffie-Hellman
groups 1 or 2. IKEv2 provides a state-of-the-art suite of
cryptographic algorithms that IKEv1 lacks.
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.
4. IKEv1 Feature Equivalents for IKEv2
A few notable IKEv1 features are not present in the IKEv2 core
specification [RFC7296] but are available for IKEv2 via an additional
specification.
4.1. IKEv2 Post-Quantum Support
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].
4.2. IKEv2 Labeled IPsec Support
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].
4.3. IKEv2 Group SA and Multicast Support
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].
5. Deprecating Obsolete Algorithms
This document deprecates the following algorithms:
* Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the
unspecified 3IDEA, ENCR_DES_IV64, and ENCR_DES_IV32
* PRF Algorithms: the unspecified PRF_HMAC_TIGER
* Integrity Algorithms: HMAC-MD5-128
* Diffie-Hellman groups: none
6. Security Considerations
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.
7. IANA Considerations
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:
Transform Type 1 - Encryption Algorithm Transform IDs
Transform Type 2 - Pseudorandom Function Transform IDs
Transform Type 3 - Integrity Algorithm Transform IDs
Transform Type 4 - Key Exchange Method Transform IDs
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) |
+--------+---------------+-----------------------+
Table 1: Transform Type 1 - Encryption
Algorithm Transform IDs
+========+================+=======================+
| Number | Name | Status |
+========+================+=======================+
| 1 | PRF_HMAC_MD5 | DEPRECATED [RFC8247] |
+--------+----------------+-----------------------+
| 3 | PRF_HMAC_TIGER | DEPRECATED (RFC 9395) |
+--------+----------------+-----------------------+
Table 2: Transform Type 2 - Pseudorandom
Function Transform IDs
+========+====================+=======================+
| 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) |
+--------+--------------------+-----------------------+
Table 3: Transform Type 3 - Integrity Algorithm
Transform IDs
+========+==============================+======================+
| Number | Name | Status |
+========+==============================+======================+
| 1 | 768-bit MODP Group | DEPRECATED [RFC8247] |
+--------+------------------------------+----------------------+
| 22 | 1024-bit MODP Group with | DEPRECATED [RFC8247] |
| | 160-bit Prime Order Subgroup | |
+--------+------------------------------+----------------------+
Table 4: Transform Type 4 - Key Exchange Method Transform IDs
All entries not mentioned here should receive no value in the new
Status field.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
"Algorithm Implementation Requirements and Usage Guidance
for the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8247, DOI 10.17487/RFC8247, September 2017,
<https://www.rfc-editor.org/info/rfc8247>.
8.2. Informative References
[CVE-2016-5361]
NIST National Vulnerability Database, "CVE-2016-5361
Detail", 16 June 2016,
<https://nvd.nist.gov/vuln/detail/CVE-2016-5361>.
[G-IKEV2] Smyslov, V. and B. Weis, "Group Key Management using
IKEv2", Work in Progress, Internet-Draft, draft-ietf-
ipsecme-g-ikev2-09, 19 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
g-ikev2-09>.
[LABELED-IPSEC]
Wouters, P. and S. Prasad, "Labeled IPsec Traffic Selector
support for IKEv2", Work in Progress, Internet-Draft,
draft-ietf-ipsecme-labeled-ipsec-11, 10 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
labeled-ipsec-11>.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407,
DOI 10.17487/RFC2407, November 1998,
<https://www.rfc-editor.org/info/rfc2407>.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998,
<https://www.rfc-editor.org/info/rfc2408>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005,
<https://www.rfc-editor.org/info/rfc4306>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
Kivinen, "Cryptographic Algorithm Implementation
Requirements and Usage Guidance for Encapsulating Security
Payload (ESP) and Authentication Header (AH)", RFC 8221,
DOI 10.17487/RFC8221, October 2017,
<https://www.rfc-editor.org/info/rfc8221>.
[RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
"Mixing Preshared Keys in the Internet Key Exchange
Protocol Version 2 (IKEv2) for Post-quantum Security",
RFC 8784, DOI 10.17487/RFC8784, June 2020,
<https://www.rfc-editor.org/info/rfc8784>.
Author's Address
Paul Wouters (editor)
Aiven
Email: paul.wouters@aiven.io
AI ELI5
On this page
PROBLEMIKEv1 was replaced by IKEv2 long ago but still lingers in unmaintained code, and many aged algorithms were left in a vague 'MAY be used' state because RFCs 8221 and 8247 never mentioned them.
MECHANISMThe RFC declares IKEv1 and its related documents Historic, lists the IKEv1 features that now have IKEv2 equivalents, deprecates the unmentioned old algorithms, and adds a Status column to the IKEv2 Transform Type registries.
WHY IT MATTERSSystems that only speak IKEv1 should be upgraded or replaced, and the deprecated algorithm names are now flagged DEPRECATED in IANA's IKEv2 registries.
§1Why IKEv1 Is Being Retired
IKEv1 and its related documents (ISAKMP in RFC 2408 and the IPsec DOI in RFC 2407, together with RFC 2409) were obsoleted by IKEv2 in RFC 4306 in December 2005. The latest IKEv2 specification at the time of writing was RFC 7296, published in 2014.
The RFC says IKEv2 replaced IKEv1 more than 15 years ago, has seen wide deployment, and is a full replacement for all IKEv1 functionality. No new modifications or algorithms had been accepted for IKEv1 for at least a decade, and IKEv2 fixes problems such as IKEv1 being vulnerable to amplification attacks.
The newer way of setting up secure connections has been around for a very long time and does everything the old way did. The old way has not been improved in years, so it is time to retire it.
§3RFCs 2407, 2408 and 2409 Are Historic
Systems that run IKEv1 should be upgraded and reconfigured to run IKEv2. The RFC gives several reasons why IKEv1-only systems are poor candidates for continued operation.
- IKEv1 development ceased over a decade ago, so unmaintained code may hide security vulnerabilities.
- Some IKEv1 systems have reached End of Life and will never be patched.
- Some vendors have 'frozen' their IKEv1 implementation, and users may not realise it is unmaintained.
- IKEv1 systems can be abused for packet amplification attacks, as documented in CVE-2016-5361.
- The algorithms IKEv1 commonly negotiates are dated, such as AES-CBC, SHA1 and Diffie-Hellman groups 1 or 2.
IKEv2 offers more modern cryptographic primitives, proper defense against denial-of-service attacks, improved authentication through EAP methods, and password-authenticated key exchange (PAKE) support. IKEv2 implementations SHOULD NOT directly import IKEv1 configurations without updating the cryptographic algorithms used.
Old equipment that nobody fixes can have holes bad guys use. The new system is stronger, so everyone should move over and not just copy the old settings.
§4IKEv1 Features That Moved to IKEv2
A few IKEv1 features are not in the IKEv2 core specification but are available through additional specifications.
- Post-quantum protection (4.1). IKEv1's use of preshared keys (PSKs) protects against quantum-computer attacks. IKEv2 changed PSK use to improve error reporting, at the expense of post-quantum security. Systems that need it should use IKEv2 Post-quantum Preshared Keys (PPKs) from RFC 8784.
- Labeled IPsec (4.2). This negotiates an extra Security Context selector for the Security Policy Database, and was never standardized in IKEv1. IKEv2 support is specified in a separate Internet-Draft.
- Group SAs and multicast (4.3). The Group Domain of Interpretation in RFC 6407 is based on IKEv1. For IKEv2 this work was still in progress as a draft.
A few special tricks of the old system are not in the main new rulebook. They live in extra booklets, so people who need those tricks should look there.
§5Deprecated Algorithms
RFC 8247 and RFC 8221 avoid recommending broken or weak algorithms, but they leave old, unused ones in a 'MAY be used' state simply by not mentioning them. This RFC deprecates those unmentioned algorithms, which have no known attacks that would have led to earlier deprecation but are no longer advised.
- Encryption: RC5, IDEA, CAST, Blowfish, and the unspecified 3IDEA, ENCR_DES_IV64 and ENCR_DES_IV32.
- PRF: the unspecified PRF_HMAC_TIGER.
- Integrity: HMAC-MD5-128.
- Diffie-Hellman groups: none.
Some old tools were never officially banned, only forgotten. This list puts a clear 'please do not use' label on them.
§7Registry Changes at IANA
IANA closed the 'Internet Key Exchange (IKE) Attributes' and 'Magic Numbers for ISAKMP Protocol' registries, noting 'All registries listed below have been closed. See RFC 9395.' Their registration procedures became 'Registry closed'.
IANA also added a Status column to four IKEv2 Transform Type registries: Encryption Algorithm (type 1), Pseudorandom Function (type 2), Integrity Algorithm (type 3) and Key Exchange Method (type 4). Entries from this RFC are marked DEPRECATED (RFC 9395), and a few earlier deprecations are shown as DEPRECATED [RFC8247]. Entries not mentioned receive no value in the new column.
The list-keepers froze the old notebooks so nothing new can be added, and added a new column to the new notebooks saying which items are no longer recommended.
- 1ENCR_DES_IV64 — DEPRECATED (RFC 9395)
- 2ENCR_DES — DEPRECATED by RFC 8247
- 4ENCR_RC5 — DEPRECATED (RFC 9395)
- 5ENCR_IDEA — DEPRECATED (RFC 9395)
- 6ENCR_CAST — DEPRECATED (RFC 9395)
- 7ENCR_BLOWFISH — DEPRECATED (RFC 9395)
- 8ENCR_3IDEA — DEPRECATED (RFC 9395)
- 9ENCR_DES_IV32 — DEPRECATED (RFC 9395)
§6Security Considerations
The RFC states there are only security benefits if IKEv1 is deprecated and IKEv2 is used.
The deprecated algorithms have long been out of use and are no longer actively deployed or researched, which leaves an unknown security risk best avoided. Not supporting them also simplifies implementations and reduces accidental use through misconfiguration or downgrade attacks.
Fewer old, forgotten tools means fewer ways to trip up or to be tricked into using a weak one.
§7References
[RFC8247]RFC 8247Nir, Y., Kivinen, T., Wouters, P., and D. Migault, "Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8247, September 2017.September 2017[RFC8221]RFC 8221Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, October 2017.October 2017[RFC7296]RFC 7296Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014.October 2014[RFC4306]RFC 4306Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.December 2005[RFC2409]RFC 2409Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.November 1998[RFC8784]RFC 8784Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security", RFC 8784, June 2020.June 2020[RFC6407]RFC 6407Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011.October 2011