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

ipsecme                                                         T. Reddy
Internet-Draft                                                     Nokia
Intended status: Standards Track                              V. Smyslov
Expires: 18 May 2025                                          ELVIS-PLUS
                                                              S. Fluhrer
                                                           Cisco Systems
                                                        14 November 2024

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

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 outlines how post-quantum digital signatures,
   specifically 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.  It introduces ML-
   DSA and SLH-DSA capability to IKEv2 without necessitating any
   alterations to existing IKE operations.

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

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

Reddy, et al.              Expires 18 May 2025                  [Page 1]
Internet-Draft   Signature Authentication in IKEv2 using   November 2024

   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 18 May 2025.

Copyright Notice

   Copyright (c) 2024 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
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Specifying ML-DSA within IKEv2  . . . . . . . . . . . . . . .   4
   4.  Specifying SLH-DSA within IKEv2 . . . . . . . . . . . . . . .   4
   5.  Signature Algorithm Use and Hashing in IKEv2 with ML-DSA and
           SLH-DSA . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Mechanisms for Signaling Supported Key Pair Types . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     Normative References  . . . . . . . . . . . . . . . . . . . . .   7
     Informative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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 initial set of exchanges, both parties independently
   select and use their preferred authentication method, which may even
   differ between the initiator and the responder.  In IKEv2, it occurs
   in the exchange called IKE_AUTH.  One option for the authentication
   method is digital signatures using public key cryptography.
   Currently, traditional digital signatures are defined for use within
   IKE_AUTH: RSA signatures, Digital Signature Algorithm (DSA) Digital

Reddy, et al.              Expires 18 May 2025                  [Page 2]
Internet-Draft   Signature Authentication in IKEv2 using   November 2024

   Signature Standard (DSS) and ECDSA.

   The presence of a Cryptographically Relevant Quantum Computer (CRQC)
   would render state-of-the-art traditional public-key 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 presence of a CRQC.  Consequently, there is a requirement to
   update protocols and infrastructure to use post-quantum algorithms.
   Post-quantum algorithms are public-key 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].

   Module-Lattice-Based Digital Signatures (ML-DSA) [FIPS204] and
   Stateless Hash-Based Digital Signatures (SLH-DSA) [FIPS205] are
   quantum-resistant digital signature schemes standardized by the US
   National Institute of Standards and Technology (NIST) PQC project.
   This document specifies the use of the ML-DSA and SLH-DSA algorithms
   in IKEv2.

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:

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

Reddy, et al.              Expires 18 May 2025                  [Page 3]
Internet-Draft   Signature Authentication in IKEv2 using   November 2024

3.  Specifying ML-DSA within IKEv2

   ML-DSA [FIPS204] is a digital signature algorithm (part of the
   CRYSTALS suite) 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 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.  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.

4.  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 each of the
   security levels were chosen to provide 128 bits of security, 192 bits
   of security, and 256 bits of security.  This document specifies the
   use of the SLH-DSA algorithm in IKEv2 at three security levels.  It
   includes the small (S) or fast (F) versions of the algorithm.  For
   security level 1, SHA-256 ([FIPS180]) is used.  For security levels 3
   and 5, SHA-512 ([FIPS180]) is used.  SHAKE256 ([FIPS202]) is
   applicable for all security levels.  The small version prioritizes
   smaller signature sizes, making them suitable for 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.  On the other
   hand, 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

Reddy, et al.              Expires 18 May 2025                  [Page 4]
Internet-Draft   Signature Authentication in IKEv2 using   November 2024

   *  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

   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 for a post-quantum world.  While
   attacks on lattice-based schemes like ML-DSA can compromise their
   security, SLH-DSA will 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.

5.  Signature Algorithm Use and Hashing in IKEv2 with ML-DSA and SLH-DSA

   Both ML-DSA and SLH-DSA offer deterministic and randomized signing
   options.  By default, ML-DSA uses a non-deterministic approach, where
   the private random seed rho' is derived pseudorandomly from the
   signer’s private key, the message, and a 256-bit string, rnd,
   generated by an approved Random Bit Generator (RBG).  In the
   deterministic version, rnd is instead a constant 256-bit string.
   Similarly, SLH-DSA can be deterministic or randomized, depending on
   whether opt_rand is set to a fixed value or a random one.  When
   opt_rand is set to a public seed (from the public key), SLH-DSA
   produces deterministic signatures, meaning signing the same message
   twice will result in the same signature.

Reddy, et al.              Expires 18 May 2025                  [Page 5]
Internet-Draft   Signature Authentication in IKEv2 using   November 2024

   In the context of signature-based authentication in IKEv2, the data
   used for generating a digital signature is unique for each IKEv2
   session, as it includes session-specific information like nonces,
   cryptographic parameters, and identifiers.  Thus, both ML-DSA and
   SLH-DSA can utilize their deterministic versions when used within
   IKEv2.  In both cases, the 'context' input parameter for the
   signature generation algorithm is set to an empty string.

   IKEv2 can use arbitrary signature algorithms as described in
   [RFC7427], where the "Digital Signature" authentication method
   supersedes previously defined signature authentication methods.  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.  This document specifies
   only the use of pure mode for signature-based authentication in
   IKEv2, where the content is signed directly along with some domain
   separation information.  In pre-hash mode, a digest of the message is
   signed instead.  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.  The data
   signed to prove the identity of the initiator and responder (as
   discussed in Section 2.15 of [RFC7427]) typically fits within the
   memory constraints of the devices involved in the IKEv2 exchange,
   consisting of nonces, SPIs, and the initial exchange messages, which
   are manageable in size.

6.  Mechanisms for Signaling Supported Key Pair Types

   The following mechanisms can be used by peers to signal the types of
   public/private key pairs they possess:

   *  One method to ascertain that the key pair type the initiator wants
      the responder to use is through a Certificate Request payload sent
      by the initiator.  For example, the initiator could indicate in
      the Certificate Request payload that it trusts a certificate
      authority certificate signed by an ML-DSA or SLH-DSA key.  This
      indication implies that the initiator can process ML-DSA or SLH-
      DSA signatures, which means that the responder can use ML-DSA or
      SLH-DSA keys when authenticating.

   *  Another method is to leverage
      [I-D.ietf-ipsecme-ikev2-auth-announce] that allows peers to
      announce their supported authentication methods.  It improves
      interoperability when IKEv2 partners are configured with multiple

Reddy, et al.              Expires 18 May 2025                  [Page 6]
Internet-Draft   Signature Authentication in IKEv2 using   November 2024

      credentials of different type to authenticate each other.  The
      responder includes a SUPPORTED_AUTH_METHODS notification in the
      IKE_SA_INIT response message containing the PQC digital signature
      scheme(s) it supports.  The initiator includes the
      SUPPORTED_AUTH_METHODS notification in 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.

7.  Security Considerations

   ML-DSA and SLH-DSA are modeled under existentially unforgeable
   digital signatures with respect to an adaptive chosen message attack
   (EUF-CMA).

   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] applies to this specification as well.

Acknowledgements

   Thanks to Stefaan De Cnodder 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>.

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

Reddy, et al.              Expires 18 May 2025                  [Page 7]
Internet-Draft   Signature Authentication in IKEv2 using   November 2024

Informative References

   [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-ipsecme-ikev2-auth-announce]
              Smyslov, V., "Announcing Supported Authentication Methods
              in IKEv2", Work in Progress, Internet-Draft, draft-ietf-
              ipsecme-ikev2-auth-announce-10, 18 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
              ikev2-auth-announce-10>.

   [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-
              05, 4 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              dilithium-certificates-05>.

   [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-02, 14
              October 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-lamps-x509-slhdsa-02>.

Reddy, et al.              Expires 18 May 2025                  [Page 8]
Internet-Draft   Signature Authentication in IKEv2 using   November 2024

   [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-06, 21 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-06>.

   [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-04, 10
              September 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-pquip-pqt-hybrid-terminology-04>.

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

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

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 18 May 2025                  [Page 9]