doc: Add RFC documents

1 files changed, 368 insertions, 0 deletions

diff --git a/doc/rfc/rfc9395.txt b/doc/rfc/rfc9395.txt
new file mode 100644
index 0000000..a3870e2
--- /dev/null
+++ b/doc/rfc/rfc9395.txt
@@ -0,0 +1,368 @@
+
+
+
+
+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