ipsecme T. Reddy
Internet-Draft Nokia
Intended status: Standards Track V. Smyslov
Expires: 15 September 2025 ELVIS-PLUS
S. Fluhrer
Cisco Systems
14 March 2025
Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
using ML-DSA and SLH-DSA
draft-ietf-ipsecme-ikev2-pqc-auth-00
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 adds ML-DSA and
SLH-DSA capabilities to IKEv2 while preserving existing IKEv2
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-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.
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 15 September 2025 [Page 1]
Internet-Draft ML-DSA & SLH-DSA Authentication in IKEv2 March 2025
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 15 September 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 . . . . . . . . . . . . . . . . . . . . . . . . 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
5.1. Implementation Alternatives for ML-DSA . . . . . . . . . 6
5.2. Discussion of ML-DSA and SLH-DSA and Prehashing . . . . . 6
6. Use of ML-DSA and SLH-DSA . . . . . . . . . . . . . . . . . . 7
7. Mechanisms for Signaling Supported Key Pair Types . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . 9
Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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
Reddy, et al. Expires 15 September 2025 [Page 2]
Internet-Draft ML-DSA & SLH-DSA Authentication in IKEv2 March 2025
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
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 15 September 2025 [Page 3]
Internet-Draft ML-DSA & SLH-DSA Authentication in IKEv2 March 2025
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 15 September 2025 [Page 4]
Internet-Draft ML-DSA & SLH-DSA Authentication in IKEv2 March 2025
* 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
For integrating ML-DSA and SLH-DSA into IKEv2, the approach used in
[RFC8420] is followed.
The implementation MUST send a SIGNATURE_HASH_ALGORITHMS notify with
an "Identity" (5) hash function. ML-DSA and SLH-DSA are only defined
with the "Identity" hash and MUST NOT be sent to a receiver that has
not indicated support for the "Identity" hash.
When generating a signature with ML-DSA or SLH-DSA, the IKEv2
implementation would take the InitiatorSignedOctets string or the
ResponderSignedOctets string (as appropriate), logically send it to
the identity hash (which leaves it unchanged), and then pass it into
the ML-DSA or SLH-DSA signer as the message to be signed (with no
context string). The resulting signature is placed into the
Signature Value field of the Authentication Payload.
Reddy, et al. Expires 15 September 2025 [Page 5]
Internet-Draft ML-DSA & SLH-DSA Authentication in IKEv2 March 2025
When verifying a signature with ML-DSA or SLH-DSA, the IKEv2
implementation would take the InitiatorSignedOctets string or the
ResponderSignedOctets string (as appropriate), logically send it to
the identity hash (which leaves it unchanged), and then pass it into
the ML-DSA or SLH-DSA signer as the message to be verified (with no
context string).
5.1. 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 crypto 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 an hash.
This hash is then passed to the cryptographic library to execute the
ExternalMU-ML-DSA.Sign API, which takes the hash and the ML-DSA
private key to produce the signature.
These methods are equivalent, and so either may be used.
5.2. Discussion of ML-DSA and SLH-DSA and Prehashing
This section discusses various approaches for integrating ML-DSA and
SLH-DSA into IKEv2, not just the method 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 one of a number of hash
functions 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.
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:
Reddy, et al. Expires 15 September 2025 [Page 6]
Internet-Draft ML-DSA & SLH-DSA Authentication in IKEv2 March 2025
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. 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 acts this way, 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 current, but instead of running ML-DSA or
SLH-DSA in prehash mode, we have it sign it in pure mode as if it was
the message. 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).
6. Use of 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 15 September 2025 [Page 7]
Internet-Draft ML-DSA & SLH-DSA Authentication in IKEv2 March 2025
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 [RFC7296]) 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.
7. 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 15 September 2025 [Page 8]
Internet-Draft ML-DSA & SLH-DSA Authentication in IKEv2 March 2025
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.
8. 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, Loganaden Velvindron, Paul Wouters,
Andreas Steffen, 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>.
Reddy, et al. Expires 15 September 2025 [Page 9]
Internet-Draft ML-DSA & SLH-DSA Authentication in IKEv2 March 2025
[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>.
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-
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,
Reddy, et al. Expires 15 September 2025 [Page 10]
Internet-Draft ML-DSA & SLH-DSA Authentication in IKEv2 March 2025
Internet-Draft, draft-ietf-lamps-x509-slhdsa-03, 22
November 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-x509-slhdsa-03>.
[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>.
[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 15 September 2025 [Page 11]