Aiven

paul.wouters@aiven.io

sec ipsecme IKEv1 IKEv2 IPsec IKE 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 .

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 () 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

• .  Introduction
• .  Requirements Language
• .  RFCs 2407, 2408, and 2409 Are Historic
• .  IKEv1 Feature Equivalents for IKEv2
  • .  IKEv2 Post-Quantum Support
  • .  IKEv2 Labeled IPsec Support
  • .  IKEv2 Group SA and Multicast Support
• .  Deprecating Obsolete Algorithms
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Author's Address

Introduction IKEv1 has been moved to Historic status. IKEv1 and its related documents for the Internet Security Association and Key Management Protocol (ISAKMP) and IPsec DOI were obsoleted by IKEv2 in December 2005. The latest version of IKEv2 at the time of writing was published in 2014 . 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 and Encapsulating Security Payload (ESP) and Authentication Header (AH) 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.

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 when, and only when, they appear in all capitals, as shown here.

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 .
• 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.

IKEv1 Feature Equivalents for IKEv2 A few notable IKEv1 features are not present in the IKEv2 core specification but are available for IKEv2 via an additional specification.

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) .

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 .

IKEv2 Group SA and Multicast Support The Group Domain of Interpretation (GDOI) protocol , which is based on IKEv1, defines the support for Multicast Group SAs. For IKEv2, this work is currently in progress via .

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

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.

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: Transform Type 1 - Encryption Algorithm Transform IDs

Number	Name	Status
1	ENCR_DES_IV64	DEPRECATED (RFC 9395)
2	ENCR_DES	DEPRECATED
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)

Transform Type 2 - Pseudorandom Function Transform IDs

Number	Name	Status
1	PRF_HMAC_MD5	DEPRECATED
3	PRF_HMAC_TIGER	DEPRECATED (RFC 9395)

Transform Type 3 - Integrity Algorithm Transform IDs

Number	Name	Status
1	AUTH_HMAC_MD5_96	DEPRECATED
3	AUTH_DES_MAC	DEPRECATED
4	AUTH_KPDK_MD5	DEPRECATED
6	AUTH_HMAC_MD5_128	DEPRECATED (RFC 9395)
7	AUTH_HMAC_SHA1_160	DEPRECATED (RFC 9395)

Transform Type 4 - Key Exchange Method Transform IDs

Number	Name	Status
1	768-bit MODP Group	DEPRECATED
22	1024-bit MODP Group with 160-bit Prime Order Subgroup	DEPRECATED

All entries not mentioned here should receive no value in the new Status field.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP). Informative References NIST National Vulnerability Database ELVIS-PLUS Independent This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components require a Group Controller/Key Server to download IPsec group security associations to authorized members of a group. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. This documents also updates RFC 7296 by renaming a transform type 5 from "Extended Sequence Numbers (ESN)" to the "Replay Protection (RP)" and by renaming IKEv2 authentication method 0 from "Reserved" to "NONE". Work in Progress Aiven Red Hat This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. Work in Progress This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK] This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. [STANDARDS-TRACK] This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK] This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. [STANDARDS-TRACK] This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547. [STANDARDS-TRACK] This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.

Author's Address Aiven

paul.wouters@aiven.io