Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC
draft-ietf-ipsecme-ikev2-pqc-auth-02

ipsecme                                                         T. Reddy
Internet-Draft                                                     Nokia
Intended status: Standards Track                              V. Smyslov
Expires: 14 October 2025                                      ELVIS-PLUS
                                                              S. Fluhrer
                                                           Cisco Systems
                                                           12 April 2025

Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
                               using PQC
                  draft-ietf-ipsecme-ikev2-pqc-auth-02

Abstract

   Signature-based authentication methods are utilized in IKEv2
   [RFC7296].  The current version of the Internet Key Exchange Version
   2 (IKEv2) protocol supports traditional digital signatures.

   This document specifies a generic mechanism for integrating post-
   quantum cryptographic (PQC) digital signature algorithms into the
   IKEv2 protocol.  The approach allows for seamless inclusion of any
   PQC signature scheme within the existing authentication framework of
   IKEv2.  Additionally, it outlines how Module-Lattice-Based Digital
   Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH-
   DSA), can be employed as authentication methods within the IKEv2
   protocol, as they have been standardized by NIST.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-pqc/.

   Discussion of this document takes place on the ipsecme Working Group
   mailing list (mailto:ipsecme@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/ipsec/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/ipsecme/.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Reddy, et al.            Expires 14 October 2025                [Page 1]
Internet-Draft         PQC Authentication in IKEv2            April 2025

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 14 October 2025.

Copyright Notice

   Copyright (c) 2025 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  General Framework for PQC Authentication in IKEv2 . . . . . .   4
     3.1.  Specifying PQC Signature Algorithms . . . . . . . . . . .   4
     3.2.  Signature Generation and Verification . . . . . . . . . .   4
       3.2.1.  Handling PQC Signatures in IKEv2  . . . . . . . . . .   5
     3.3.  Mechanisms for Signaling Supported Key Pair Types . . . .   6
   4.  Specifying ML-DSA within IKEv2  . . . . . . . . . . . . . . .   7
   5.  Specifying SLH-DSA within IKEv2 . . . . . . . . . . . . . . .   7
   6.  Implementation Alternatives for ML-DSA  . . . . . . . . . . .   9
   7.  Discussion of ML-DSA and SLH-DSA and Prehashing . . . . . . .   9
   8.  Use of ML-DSA and SLH-DSA . . . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     Normative References  . . . . . . . . . . . . . . . . . . . . .  12
     Informative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

Reddy, et al.            Expires 14 October 2025                [Page 2]
Internet-Draft         PQC Authentication in IKEv2            April 2025

1.  Introduction

   The Internet Key Exchange, or IKEv2 [RFC7296], is a key agreement and
   security negotiation protocol; it is used for key establishment in
   IPsec.  In the IKE_AUTH exchange, the initiator and responder
   independently select and use their preferred authentication method,
   which may differ between peers.  The most common authentication
   method is digital signatures using asymmetric cryptography.
   Currently, traditional digital signatures are defined for use within
   IKE_AUTH: RSA signatures, Digital Signature Algorithm (DSA) Digital
   Signature Standard (DSS) and ECDSA.

   The existence of a Cryptographically Relevant Quantum Computer (CRQC)
   would render state-of-the-art traditional asymmetric algorithms
   obsolete and insecure.  This is because the assumptions about the
   intractability of the mathematical problems these algorithms rely on,
   which offer confident levels of security today, no longer apply in
   the existence of a CRQC.  Consequently, there is a requirement to
   update protocols and infrastructure to use post-quantum algorithms.
   Post-quantum algorithms are asymmetric algorithms designed to be
   secure against CRQCs as well as classical computers.  The traditional
   cryptographic primitives that need to be replaced by PQC algorithms
   are discussed in [I-D.ietf-pquip-pqc-engineers].

   This document defines a general approach to incorporating PQC digital
   signature algorithms into IKEv2 while maintaining interoperability
   and backward compatibility.  Additionally, it outlines how Module-
   Lattice-Based Digital Signatures (ML-DSA) [FIPS204] and Stateless
   Hash-Based Digital Signatures (SLH-DSA) [FIPS205] can be employed as
   authentication methods within IKEv2, as they have been standardized
   the US National Institute of Standards and Technology (NIST) PQC
   project.

2.  Conventions and Definitions

   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.

   This document uses terms defined in
   [I-D.ietf-pquip-pqt-hybrid-terminology].  For the purposes of this
   document, it is helpful to be able to divide cryptographic algorithms
   into two classes:

Reddy, et al.            Expires 14 October 2025                [Page 3]
Internet-Draft         PQC Authentication in IKEv2            April 2025

   "Asymmetric Traditional Cryptographic Algorithm": An asymmetric
   cryptographic algorithm based on integer factorisation, finite field
   discrete logarithms or elliptic curve discrete logarithms, elliptic
   curve discrete logarithms, or related mathematical problems.

   "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that
   is believed to be secure against attacks using quantum computers as
   well as classical computers.  Post-quantum algorithms can also be
   called quantum-resistant or quantum-safe algorithms.  Examples of
   quantum-resistant digital signature schemes include ML-DSA and SLH-
   DSA.

3.  General Framework for PQC Authentication in IKEv2

   IKEv2 authentication commonly relies on digital signatures to verify
   the identity of communicating peers.  The mechanism described in this
   document enables the use of any PQC digital signature algorithm
   without modifying core IKEv2 operations.

3.1.  Specifying PQC Signature Algorithms

   *  IKEv2 can use arbitrary signature algorithms as described in
      [RFC7427], where the "Digital Signature" authentication method
      supersedes previously defined signature authentication methods.
      Any PQC digital signature algorithm can be incorporated using the
      "Signature Algorithm" field in authentication payloads, as defined
      in [RFC7427].

   *  AlgorithmIdentifier ASN.1 objects will be used to uniquely
      identify PQC signature algorithm scheme and the parameter set
      associated with it.

3.2.  Signature Generation and Verification

   PQC signatures may be generated in either deterministic or hedged
   modes.  In the deterministic mode, the signature is derived entirely
   from the message and the signer’s private key, without introducing
   fresh randomness at signing time.  While this eliminates reliance on
   an external random number generator (RNG), it increases
   susceptibility to side-channel attacks, particularly fault injection
   attacks.  The terms deterministic and hedged used in this document
   are in accordance with [FIPS204] and [FIPS205], which define the ML-
   DSA and SLH-DSA algorithms.  Future PQC signature algorithms may
   adopt different nomenclature, but will be expected to follow the same
   principles.

Reddy, et al.            Expires 14 October 2025                [Page 4]
Internet-Draft         PQC Authentication in IKEv2            April 2025

   The hedged mode mitigates this risk by including precomputed
   randomness in the signer's private key and incorporating fresh
   randomness generated at signing time.  This approach ensures
   protection against side-channel attacks.

   In the context of signature-based authentication in IKEv2, the data
   used for generating a digital signature is unique for each session,
   as it includes session-specific information such as nonces,
   cryptographic parameters, and identifiers.  PQC signature algorithms
   can leverage the hedged variant within IKEv2 to enhance security
   against side-channel attacks.  The choice between deterministic and
   hedged signing modes does not impact interoperability because the
   verification process remains the same for both variants.

   If the PQC signature algorithm uses a 'context' input parameter, it
   MUST be set to an empty string.

   Certain digital signature algorithms support two modes: "pure" mode
   and "pre-hash" mode.  For example, ML-DSA and SLH-DSA support both
   modes.  In pure mode, the content is signed directly along with some
   domain separation information.  In contrast, pre-hash mode involves
   signing a digest of the message.  This document specifies the use of
   pure mode for signature-based authentication in IKEv2, where the
   message is signed directly along with domain separation information.
   The data used for authentication in IKEv2, as described in
   Section 2.15 of [RFC7296], consists of elements such as nonces, SPIs,
   and initial exchange messages (messages preceding IKE_AUTH), which
   are typically within device memory constraints.  While pre-hash mode
   can help in scenarios with memory constraints, the IKEv2
   authentication data is generally small, and combined with other
   practical challenges (discussed in Section 7), this document only
   specifies pure mode.

3.2.1.  Handling PQC Signatures in IKEv2

   For integrating PQC signature algorithms into IKEv2, the approach
   used in [RFC8420] is followed.

   As specified in [RFC7427], both the initiator and responder MUST send
   the SIGNATURE_HASH_ALGORITHMS notify payload in the IKE_SA_INIT
   exchange to indicate the set of hash algorithms they support for
   signature generation and verification.  The SIGNATURE_HASH_ALGORITHMS
   notify payload contains a list of 2-octet hash algorithm identifiers,
   defined in the IANA "IKEv2 Hash Algorithms" registry.

   For PQC signature algorithms that inherently operate directly on the
   raw message without hashing, such as ML-DSA and SLH-DSA, only the
   'Identity' hash function is applicable.  The 'Identity' hash function

Reddy, et al.            Expires 14 October 2025                [Page 5]
Internet-Draft         PQC Authentication in IKEv2            April 2025

   (value 5) is defined in Section 2 of [RFC8420] and indicates that the
   input message is used as-is, without any hash function applied.
   Therefore, implementations supporting such PQC signature algorithms
   MUST include the 'Identity' hash (5) in the SIGNATURE_HASH_ALGORITHMS
   notify.  Furthermore, PQC signature algorithms requiring the
   'Identity' hash MUST NOT be used with a peer that has not indicated
   support for the Identity hash in its notify payload.

   When generating a signature with a PQC signature algorithm, the IKEv2
   implementation takes the InitiatorSignedOctets string or the
   ResponderSignedOctets string (as appropriate), logically sends it to
   the identity hash (which leaves it unchanged), and then passes it
   into the PQC signer as the message to be signed (with empty context
   string, if applicable).  The resulting signature is placed into the
   Signature Value field of the Authentication Payload.

   When verifying a signature with a PQC signature algorithm, the IKEv2
   implementation takes the InitiatorSignedOctets string or the
   ResponderSignedOctets string (as appropriate), logically sends it to
   the identity hash (which leaves it unchanged), and then passes it
   into the PQC signature verifier as the message to be verified (with
   empty context string, if applicable).

3.3.  Mechanisms for Signaling Supported Key Pair Types

   The following mechanisms can be used by peers to signal the types of
   digital signature algorithms and parameters they support:

   *  Certificate Request Payload: One method to ascertain that the key
      pair type the initiator wants the responder to use is through a
      Certificate Request payload (defined in Section 3.7 of [RFC7296])
      sent by the initiator.  For example, the initiator can specify
      that it trusts certificates issued by a certificate authority (CA)
      that signs with a particular post-quantum cryptographic (PQC)
      signature algorithm.  This implies that the initiator can process
      signatures generated using that algorithm, thereby allowing the
      responder to authenticate itself using a key pair associated with
      the specified PQC signature scheme.

   *  Authentication Method Announcement: Another method is to utilize
      [RFC9593],
      which enables peers to declare their supported authentication
      methods.  This improves interoperability when IKEv2 peers are
      configured with multiple credential types of different type to
      authenticate each other.  The responder includes a
      SUPPORTED_AUTH_METHODS notification in the IKE_SA_INIT response
      message, listing the PQC signature scheme(s) it supports.  The
      initiator includes the SUPPORTED_AUTH_METHODS notification in

Reddy, et al.            Expires 14 October 2025                [Page 6]
Internet-Draft         PQC Authentication in IKEv2            April 2025

      either the IKE_AUTH request message or in the IKE_INTERMEDIATE
      request.  This notification lists the PQC digital signature
      scheme(s) supported by the initiator, ordered by preference.

   In traditional IKEv2 deployments, peers often implicitly know the
   signature algorithms in use based on pre-configured certificates,
   trusted CAs, and IKEv2 policies.  However, cryptographic agility, the
   ability to negotiate and use different cryptographic algorithms
   without requiring software or configuration updates is increasingly
   important for long-term security and interoperability.  This
   requirement becomes even more relevant with the introduction of PQC
   algorithms, where multiple signature algorithms with varying security
   levels and performance characteristics may need to be supported over
   time.

4.  Specifying ML-DSA within IKEv2

   ML-DSA [FIPS204] is a digital signature algorithm based on the
   hardness lattice problems over module lattices (i.e., the Module
   Learning with Errors problem (MLWE)).  The design of the algorithm is
   based on the "Fiat-Shamir with Aborts" [Lyu09] framework introduced
   by Lyubashevsky that leverages rejection sampling to render lattice-
   based FS schemes compact and secure.  ML-DSA uses a uniform
   distribution over small integers for computing coefficients in error
   vectors, which makes the scheme easier to implement.

   ML-DSA is instantiated with 3 parameter sets for the security
   categories 2, 3, and 5 (see Table 2 in Section 10 of
   [I-D.ietf-pquip-pqc-engineers]).  Security properties of ML-DSA are
   discussed in Section 9 of [I-D.ietf-lamps-dilithium-certificates].
   This document specifies the use of the ML-DSA algorithm in IKEv2 at
   three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87.

5.  Specifying SLH-DSA within IKEv2

   SLH-DSA [FIPS205] utilizes the concept of stateless hash-based
   signatures.  In contrast to stateful signature algorithms, SLH-DSA
   eliminates the need for maintaining state information during the
   signing process.  SLH-DSA is designed to sign up to 2^64 messages and
   it offers three security levels.  The parameters for security levels
   1, 3, and 5 were chosen to provide AES-128, AES-192, and AES-256 bits
   of security respectively (see Table 2 in Section 10 of
   [I-D.ietf-pquip-pqc-engineers]).  This document specifies the use of
   the SLH-DSA algorithm in IKEv2 at each level.

   Each security level (1, 3, and 5) defines two variants of the
   algorithm: a small (S) version and a fast (F) version.  The small
   version prioritizes smaller signature sizes, making them suitable for

Reddy, et al.            Expires 14 October 2025                [Page 7]
Internet-Draft         PQC Authentication in IKEv2            April 2025

   resource-constrained environments IoT devices.  Conversely, the fast
   version prioritizes speed over signature size, minimizing the time
   required to generate signatures.  However, signature verification
   with the small version is faster than with the fast version.  For
   hash function selection, the algorithm uses SHA-256 ([FIPS180]) for
   security level 1 and SHA-512 ([FIPS180]) for security levels 3 and 5.
   Alternatively, SHAKE256 ([FIPS202]) can be used across all security
   levels.

   ML-DSA outperforms SLH-DSA in both signature generation and
   validation time, as well as signature size.  SLH-DSA, in contrast,
   offers smaller key sizes but larger signature sizes.

   The following combinations are defined in SLH-DSA [FIPS205]:

   *  SLH-DSA-128S-SHA2

   *  SLH-DSA-128F-SHA2

   *  SLH-DSA-192S-SHA2

   *  SLH-DSA-192F-SHA2

   *  SLH-DSA-256S-SHA2

   *  SLH-DSA-256F-SHA2

   *  SLH-DSA-128S-SHAKE

   *  SLH-DSA-128F-SHAKE

   *  SLH-DSA-192S-SHAKE

   *  SLH-DSA-192F-SHAKE

   *  SLH-DSA-256S-SHAKE

   *  SLH-DSA-256F-SHAKE

Reddy, et al.            Expires 14 October 2025                [Page 8]
Internet-Draft         PQC Authentication in IKEv2            April 2025

   SLH-DSA does not introduce a new hardness assumption beyond those
   inherent to the underlying hash functions.  It builds upon
   established foundations in cryptography, making it a reliable and
   robust digital signature scheme in the face of a CRQC.  While attacks
   on lattice-based schemes like ML-DSA are currently hypothetical at
   the time of writing this document, such attacks, if realized, could
   compromise their security.  SLH-DSA would remain unaffected by these
   attacks due to its distinct mathematical foundations.  This ensures
   the continued security of systems and protocols that utilize SLH-DSA
   for digital signatures.

6.  Implementation Alternatives for ML-DSA

   With ML-DSA, there are two different approaches to implementing the
   signature process.  The first one is to simply hand the SignedOctets
   string to the cryptographic library to generate the full signature;
   this works for SLH-DSA as well.

   The second approach involves using the ExternalMu-ML-DSA API defined
   in [I-D.ietf-lamps-dilithium-certificates].  In this method, the
   implementation calls the ExternalMU-ML-DSA.Prehash API with the
   SignedOctets string and the ML-DSA public key, generating a hash.
   This hash is then passed to the cryptographic library to execute the
   ExternalMU-ML-DSA.Sign API, which uses the hash and the ML-DSA
   private key to produce the signature.

   Both methods produce the same ML-DSA signature and are fully
   interoperable.  The choice between them depends on implementation
   preferences, such as whether the pre-hashing step is handled
   internally by the cryptographic module or performed explicitly by the
   IKEv2 implementation.

7.  Discussion of ML-DSA and SLH-DSA and Prehashing

   This section discusses various approaches for integrating ML-DSA and
   SLH-DSA into IKEv2 other than those proposed above.

   The signature architecture within IKE was designed around RSA (and
   later extended to ECDSA).  In this architecture, the actual message
   (the SignedOctets) are first hashed (using a hash that the verifier
   has indicated support for), and then passed for the remaining part of
   the signature generation processing.  That is, it is designed for
   signature algorithms that first apply a hash function to the message
   and then perform processing on that hash.  Neither ML-DSA nor SLH-DSA
   fits cleanly into this architecture.

   We see three ways to address this mismatch.

Reddy, et al.            Expires 14 October 2025                [Page 9]
Internet-Draft         PQC Authentication in IKEv2            April 2025

   The first consideration is that both ML-DSA and SLH-DSA provide
   prehashed parameter sets, which are designed to sign messages that
   have already been hashed by an external source.  At first glance,
   this might seem like an ideal solution.  However, several practical
   challenges arise:

   1.  The prehashed versions of ML-DSA and SLH-DSA appear to be rarely
       used, making it likely that support for them in cryptographic
       libraries is limited or unavailable.

   2.  The public keys for the prehashed variants use different OIDs,
       which means that certificates for IKEv2 would differ from those
       used in other protocols.  This not only complicates certificate
       management but also adds protocol complexity if a peer needs to
       support both pure and prehashed variants.  Additionally, some
       certificate authorities (CAs) may not support issuing
       certificates for prehashed ML-DSA or SLH-DSA due to their limited
       adoption.

   3.  Some users have explicitly indicated a preference not to use the
       prehashed parameter sets.

   The second is to note that, while IKEv2 normally follows the 'hash
   and then sign' paradigm, it doesn't always.  EdDSA has a similar
   constraint on not working cleanly with the standard 'hash and then
   sign' paradigm, and so the existing [RFC8420] provides an alternative
   method, which ML-DSA would cleanly fit into.  We could certainly
   adopt this same strategy; our concern would be that it might be more
   difficult for IKEv2 implementors which do not already have support
   for EdDSA.

   The third way is what we can refer to as 'fake prehashing'; IKEv2
   would generate the hash as specified by the pre-hash modes in
   [FIPS204] and [FIPS205], but instead of running ML-DSA or SLH-DSA in
   prehash mode, the hash is signed as if it were the unhashed message,
   as is done in pure mode.  This is a violation of the spirit, if not
   the letter of FIPS 204, 205.  However, it is secure (assuming the
   hash function is strong), and fits in cleanly with both the existing
   IKEv2 architecture, and what crypto libraries provide.  Additionally,
   for SLH-DSA, this means that we're now dependent on collision
   resistance (while the rest of the SLH-DSA architecture was carefully
   designed not to be).

Reddy, et al.            Expires 14 October 2025               [Page 10]
Internet-Draft         PQC Authentication in IKEv2            April 2025

8.  Use of ML-DSA and SLH-DSA

   Both ML-DSA and SLH-DSA offer deterministic and hedged signing modes.
   By default, ML-DSA uses a hedged approach, where the random value rnd
   is a 256-bit string generated by an Random Bit Generator (RBG).  The
   signature generation function utilizes this randomness along with the
   private key and the preprocessed message.  In the deterministic
   variant, rnd is instead set to a constant 256-bit zero string.
   Similarly, SLH-DSA can operate in either deterministic or hedged
   mode.  The mode is determined by the value of opt_rand, when opt_rand
   is set to a fixed value (e.g., the public seed from the public key),
   SLH-DSA generates deterministic signatures, ensuring that signing the
   same message twice produces the same signature.  In hedged mode,
   opt_rand is a fresh random value, introducing additional entropy to
   enhance security and mitigate potential side-channel risks.

   IKEv2 peers can use either the hedged or deterministic variants of
   ML-DSA and SLH-DSA for authentication in IKEv2, with a preference for
   using the hedged mode (Section 3.2).

   The three security levels of ML-DSA are identified via
   AlgorithmIdentifier ASN.1 objects, as specified in
   [I-D.ietf-lamps-dilithium-certificates].  The different combinations
   of SLH-DSA are identified via AlgorithmIdentifier ASN.1 objects, as
   specified in [I-D.ietf-lamps-x509-slhdsa].  Both ML-DSA and SLH-DSA
   define two signature modes: pure mode and pre-hash mode, as specified
   in [FIPS204] and [FIPS205], respectively.  Both [FIPS204] and
   [FIPS205] prefer pure mode over pre-hash mode, and neither
   [I-D.ietf-lamps-dilithium-certificates] nor
   [I-D.ietf-lamps-x509-slhdsa] discusses pre-hash mode.

9.  Security Considerations

   PQC signature algorithms are modeled under strong unforgeability
   against an adaptive chosen message attack (SUF-CMA).  Examples
   include ML-DSA and SLH-DSA, which adhere to this security model.

   Different PQC signature schemes are designed to provide security
   levels comparable to well-established cryptographic primitives.  For
   example, some schemes align with the security of AES-128, AES-192,
   and AES-256, while others correspond to the security levels of
   SHA-256 or SHA3-256.  The choice of a PQC signature algorithm should
   be guided by the desired security level and performance requirements.

Reddy, et al.            Expires 14 October 2025               [Page 11]
Internet-Draft         PQC Authentication in IKEv2            April 2025

   ML-DSA-44, ML-DSA-65, and ML-DSA-87 are designed to offer security
   comparable with the SHA-256/SHA3-256, AES-192, and AES-256
   respectively.  Similarly, SLH-DSA-128{S,F}-{SHA2,SHAKE}, SLH-DSA-
   192{S,F}-{SHA2,SHAKE}, and SLH-DSA-256{S,F}-{SHA2,SHAKE} are designed
   to offer security comparable with the AES-128, AES-192, and AES-256
   respectively.

   The Security Considerations section of
   [I-D.ietf-lamps-dilithium-certificates] and
   [I-D.ietf-lamps-x509-slhdsa] apply to this specification as well.

Acknowledgements

   Thanks to Stefaan De Cnodder, Loganaden Velvindron, Paul Wouters,
   Andreas Steffen, Dan Wing, Rebecca Guthrie and Daniel Van Geest for
   the discussion and comments.

References

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/rfc/rfc2119>.

   [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/rfc/rfc7296>.

   [RFC7427]  Kivinen, T. and J. Snyder, "Signature Authentication in
              the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
              DOI 10.17487/RFC7427, January 2015,
              <https://www.rfc-editor.org/rfc/rfc7427>.

   [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/rfc/rfc8174>.

   [RFC9593]  Smyslov, V., "Announcing Supported Authentication Methods
              in the Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 9593, DOI 10.17487/RFC9593, July 2024,
              <https://www.rfc-editor.org/rfc/rfc9593>.

Informative References

Reddy, et al.            Expires 14 October 2025               [Page 12]
Internet-Draft         PQC Authentication in IKEv2            April 2025

   [FIPS180]  "NIST, Secure Hash Standard (SHS), FIPS PUB 180-4, August
              2015", <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.180-4.pdf>.

   [FIPS202]  "NIST, SHA-3 Standard: Permutation-Based Hash and
              Extendable-Output Functions, FIPS PUB 202, August 2015.",
              <https://nvlpubs.nist.gov/nistpubs/fips/
              nist.fips.202.pdf>.

   [FIPS204]  "FIPS 204: Module-Lattice-Based Digital Signature
              Standard", <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.204.pdf>.

   [FIPS205]  "FIPS 205: Stateless Hash-Based Digital Signature
              Standard", <https://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.205.pdf>.

   [I-D.ietf-lamps-dilithium-certificates]
              Massimo, J., Kampanakis, P., Turner, S., and B.
              Westerbaan, "Internet X.509 Public Key Infrastructure:
              Algorithm Identifiers for ML-DSA", Work in Progress,
              Internet-Draft, draft-ietf-lamps-dilithium-certificates-
              07, 2 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              dilithium-certificates-07>.

   [I-D.ietf-lamps-x509-slhdsa]
              Bashiri, K., Fluhrer, S., Gazdag, S., Van Geest, D., and
              S. Kousidis, "Internet X.509 Public Key Infrastructure:
              Algorithm Identifiers for SLH-DSA", Work in Progress,
              Internet-Draft, draft-ietf-lamps-x509-slhdsa-04, 17 March
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              lamps-x509-slhdsa-04>.

   [I-D.ietf-pquip-pqc-engineers]
              Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
              T., and M. Ounsworth, "Post-Quantum Cryptography for
              Engineers", Work in Progress, Internet-Draft, draft-ietf-
              pquip-pqc-engineers-09, 13 February 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-09>.

   [I-D.ietf-pquip-pqt-hybrid-terminology]
              D, F., P, M., and B. Hale, "Terminology for Post-Quantum
              Traditional Hybrid Schemes", Work in Progress, Internet-
              Draft, draft-ietf-pquip-pqt-hybrid-terminology-06, 10
              January 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-pquip-pqt-hybrid-terminology-06>.

Reddy, et al.            Expires 14 October 2025               [Page 13]
Internet-Draft         PQC Authentication in IKEv2            April 2025

   [Lyu09]    "V. Lyubashevsky, “Fiat-Shamir With Aborts: Applications
              to Lattice and Factoring-Based Signatures“, ASIACRYPT
              2009", <https://www.iacr.org/archive/
              asiacrypt2009/59120596/59120596.pdf>.

   [RFC8420]  Nir, Y., "Using the Edwards-Curve Digital Signature
              Algorithm (EdDSA) in the Internet Key Exchange Protocol
              Version 2 (IKEv2)", RFC 8420, DOI 10.17487/RFC8420, August
              2018, <https://www.rfc-editor.org/rfc/rfc8420>.

Authors' Addresses

   Tirumaleswar Reddy
   Nokia
   Bangalore
   Karnataka
   India
   Email: kondtir@gmail.com

   Valery Smyslov
   ELVIS-PLUS
   Russian Federation
   Email: svan@elvis.ru

   Scott Fluhrer
   Cisco Systems
   Email: sfluhrer@cisco.com

Reddy, et al.            Expires 14 October 2025               [Page 14]