RFC 9395

Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms

πŸ“… published April 2023, from ietf

Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms πŸ¦‹

  • RFC number: 9395
  • Series: Internet Engineering Task Force (IETF)
  • Author: P. Wouters, Ed., of Aiven πŸ’–
  • Category: Standards Track πŸŽ€
  • Date: April 2023 πŸ“…
  • Updates: RFCs 8221 and 8247 ✨
  • ISSN: 2070-1721

Abstract 🌸

okay so IKEv1 is officially deprecated 😭 and RFCs 2407, 2408, and 2409 got moved to Historic status. This doc updates RFCs 8221 and 8247 to say how to handle old algorithms that were tied to IKEv1 and aren't specified or commonly used for IKEv2. It also updates the IANA registries for IKEv2 "Transform Type Values" by adding a "Status" column so the deprecation status can be listed right there πŸ’…

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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841.

You can find the current status of this document, any errata, and how to give feedback 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) as they're in effect on the date this document was published. Please read these docs carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 ✨

okay so IKEv1 has been moved to Historic status πŸ•°οΈ IKEv1 [RFC2409], plus its companion docs for the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408] and the IPsec DOI [RFC2407], got obsoleted by IKEv2 [RFC4306] in December 2005. The latest version of IKEv2 when this was written was published in 2014 [RFC7296]. IKEv2 replaced IKEv1 over 15 years ago, it's now seriously widely deployed, and it's a full replacement for all IKEv1 functionality πŸ™Œ No new modifications or new algorithms have been accepted for IKEv1 for at least a decade. IKEv2 also fixes a bunch of problems IKEv1 had, like IKEv1 being vulnerable to amplification attacks πŸ’€

The algorithm implementation requirements and usage guidelines for IKEv2 [RFC8247], and for Encapsulating Security Payload (ESP) and Authentication Header (AH) [RFC8221], give implementors guidance, but that guidance is limited so it avoids broken or weak algorithms. These two RFCs don't deprecate algorithms that have aged and aren't in use. Instead they leave those algorithms in a state of "MAY be used" just by not mentioning them πŸ™ˆ This document deprecates those unmentioned algorithms that are no longer advised, but for which there are no known attacks that would've caused an 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 πŸ•°οΈ

okay bestie, since 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 bad candidates for continued operation, for these reasons:

  • IKEv1 development stopped over a decade ago, and no new work will happen. That means unmaintained code sitting inside an otherwise supported product, which can lead to security vulnerabilities 😬
  • A bunch of IKEv1 systems have hit their End of Life, so the vendor will never patch them if a vulnerability is found πŸ’€
  • Some vendors still ship updates for equipment that supports both IKEv1 and IKEv2 but have "frozen" their IKEv1 implementation. Users might not realize they're running unmaintained code with those security risks πŸ™ƒ
  • IKEv1 systems can be abused for packet amplification attacks, as documented in the Security Bulletin [CVE-2016-5361] πŸ”₯
  • Cryptography has made huge strides since IKEv1 development stopped. Some modern cryptographic algorithms were added to IKEv1, but interoperability concerns mean the defacto algorithms negotiated by IKEv1 will be dated or deprecated ones, like AES-CBC, SHA1, and Diffie-Hellman groups 1 or 2. IKEv2 has a state-of-the-art suite of cryptographic algorithms that IKEv1 just doesn't have ✨

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. IKEv2 is also being actively worked on to defend against quantum-computer attacks πŸ‘‘

IKEv1-only systems should be upgraded or replaced by systems that support 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 aren't in the IKEv2 core specification [RFC7296], but they're available for IKEv2 through an additional specification. Let's get into it πŸ’…

4.1. IKEv2 Post-Quantum Support 🌈

IKEv1 and the way it uses Preshared Keys (PSKs) protects against quantum-computer-based attacks. IKEv2 updated how it uses PSKs to improve error reporting, but that came 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). This method was never standardized in IKEv1, though πŸ™ˆ Those IKEv1 systems that require Labeled IPsec should migrate to an IKEv2 system that supports 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 support for Multicast Group SAs. For IKEv2, this work is currently in progress via [G-IKEV2]. 🧚

7. IANA Considerations ✨

okay so IANA did some housekeeping, and it's giving tidy desk energy πŸ’…. First, they put this line at the very top of the Notes section in the "Internet Key Exchange (IKE) Attributes" and "Magic Numbers" for ISAKMP Protocol registries: All registries listed below have been closed. See RFC 9395. πŸ”’ This document also got added to the "Reference" column in both of those registries, and their registration procedures are now "Registry closed". Totally final, bestie.

IANA also added a "Status" column to these 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

And these entries got marked as DEPRECATED πŸ’€. Here's the tea:

+========+===============+=======================+
| 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

Anything that isn't listed here gets no value in the new Status field, so leave it blank and don't overthink it 🫢.

8. References ✨

8.1. Normative References

These are the must-read ones πŸ“š:

8.2. Informative References

These are the extra-credit reads, iykyk 🧚:

Author's Address πŸŽ€

Paul Wouters (editor)
Aiven
Email: paul.wouters@aiven.io
πŸ“¦ where this page comes from