Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC (2024)

Internet-DraftSignature Authentication in IKEv2 using June 2024
Reddy, et al.Expires 27 December 2024[Page]
Workgroup:
ipsecme
Internet-Draft:
draft-reddy-ipsecme-ikev2-pqc-auth-01
Published:
Intended Status:
Standards Track
Expires:
Authors:

T. Reddy

Nokia

V. Smyslov

ELVIS-PLUS

S. Fluhrer

Cisco Systems

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

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 27 December 2024.

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

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 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 asdescribed in BCP14 [RFC2119] [RFC8174] when, and only when, theyappear 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 algorithmsinto 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.

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.

ML-DSA offers both deterministic and randomized signing. By default ML-DSA signatures are non-deterministic, the private random seed rho' is pseudorandomly derived from the signer’s private key, the message, and a 256-bit string, rnd - where rnd should be generated by an approved Random Bit Generator (RBG). In the deterministic version, rnd is instead a 256-bit constant string. In the context of signature-based authentication in IKEv2, the composition of the data used for generating a digital signature is unique for each IKEv2 session. This uniqueness arises because the data used for signature creation includes session-specific information such as nonces, cryptographic parameters, and identifiers. Therefore, if ML-DSA is used as an authentication method within the IKEv2 protocol, the deterministic version of ML-DSA can be utilized.

IKEv2 can use arbitrary signature algorithms as described in [RFC7427]. The "Digital Signature" authentication method, as defined in [RFC7427], supersedes previously defined signature authentication methods. In this case, the three security levels of ML-DSA are identified via AlgorithmIdentifier ASN.1 objects, as specified in [I-D.ietf-lamps-dilithium-certificates]. [RFC7427] defines the SIGNATURE_HASH_ALGORITHMS notification where each side of the IKE negotiation lists its supported hash algorithms. However, in the case of ML-DSA, it internally incorporates the necessary hash operation as part of its signing algorithm. ML-DSA directly takes the original message, applies a hash function to it internally, and then uses the resulting hash value for the signature generation process. 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. The data consists of nonces, SPIs, and the initial exchange messages, which are manageable in size. In order to signal within IKE that no pre-hashing needs to be done with ML-DSA, the "Identity" (5) value defined in [RFC8420] MUST be set in the SIGNATURE_HASH_ALGORITHMS notification to indicate that pre-hashing is not required.

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 and allows for the use of either SHA-256 [FIPS180] or SHAKE256 [FIPS202] as the hash function. 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 and verify signatures.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

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

SLH-DSA offers both deterministic and randomized signing, depending on whether opt_rand is set to a fixed value or a random value. If opt_rand is set to a public seed (an element in the public key), then signing will be deterministic — signing the same message twice will result in the same signature. In the context of signature-based authentication in IKEv2, the composition of the data used for generating a digital signature is unique for each IKEv2 session. This uniqueness arises because the data used for signature creation includes session-specific information such as nonces, cryptographic parameters, and identifiers. Therefore, if SLH-DSA is used as an authentication method within the IKEv2 protocol, the deterministic version of SLH-DSA can be utilized.

IKEv2 can use arbitrary signature algorithms as described in [RFC7427]. The "Digital Signature" authentication method, as defined in [RFC7427], supersedes previously defined signature authentication methods. In this case, the different combinations of SLH-DSA are identified via AlgorithmIdentifier ASN.1 objects, as specified in [I-D.ietf-lamps-cms-sphincs-plus]. The final version of SLH-DSA [FIPS205] is expected to define two signature modes: pure mode and predigest mode. This document only specifies the use of predigest mode for signature-based authentication in IKEv2. In case of predigest mode, SLH-DSA internally performs randomized message compression using a keyed hash function that can process arbitrary length messages. 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. The data consists of nonces, SPIs, and the initial exchange messages, which are manageable in size. In order to signal within IKE that no pre-hashing needs to be done with SLH-DSA, the "Identity" (5) value defined in [RFC8420] MUST be set in the SIGNATURE_HASH_ALGORITHMS notification to indicate that pre-hashing is not required.

5. 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 responderto use is through a Certificate Request payload sent by theinitiator. For example, the initiator could indicate in theCertificate Request payload that it trusts a certificate authoritycertificate 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] thatallows peers to announce their supported authentication methods. It improvesinteroperability when IKEv2 partners are configured with multiplecredentials 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.

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

Acknowledgements

TODO

References

Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8174>.
[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, , <https://www.rfc-editor.org/rfc/rfc8420>.

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 (Initial Public Draft): Module-Lattice-Based Digital Signature Standard", <https://doi.org/10.6028/NIST.FIPS.204.ipd>.
[FIPS205]
"FIPS 205 (Initial Public Draft): Stateless Hash-Based Digital Signature Standard", <https://doi.org/10.6028/NIST.FIPS.205.ipd>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-auth-announce-10>.
[I-D.ietf-lamps-cms-sphincs-plus]
Housley, R., Fluhrer, S., Kampanakis, P., and B. Westerbaan, "Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", Work in Progress, Internet-Draft, draft-ietf-lamps-cms-sphincs-plus-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-sphincs-plus-05>.
[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-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-03>.
[I-D.ietf-pquip-pqc-engineers]
Banerjee, A., Reddy.K, T., Schoinianakis, D., and T. Hollebeek, "Post-Quantum Cryptography for Engineers", Work in Progress, Internet-Draft, draft-ietf-pquip-pqc-engineers-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqc-engineers-04>.
[I-D.ietf-pquip-pqt-hybrid-terminology]
D, F. and M. P, "Terminology for Post-Quantum Traditional Hybrid Schemes", Work in Progress, Internet-Draft, draft-ietf-pquip-pqt-hybrid-terminology-03, , <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqt-hybrid-terminology-03>.
[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, , <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

Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC (2024)

FAQs

What is the authentication method of IKEv2? ›

IKEv2 uses pre-shared key and Digital Signature for authentication. See RFC 4306. EAP-TLS. EAP-TLS is a certificate-based authentication method supporting mutual authentication, integrity-protected ciphersuite negotiation and key exchange between two endpoints.

What is the Internet Key Exchange IKEv2? ›

IKEv2 (Internet Key Exchange version 2) works as a tunneling protocol to establish a secure connection over the internet. Developed jointly by Cisco and Microsoft, it ensures that both VPN client and server authenticate each other and agree upon encryption methods for secure communication.

What are the protocols for digital signature authentication? ›

Ans.: A digital signature is an authentication mechanism that allows the sender to attach an electronic code with the message in order to ensure its authenticity and integrity. This electronic code acts as the signature of the sender and, hence, is named digital signature.

What is the username and password for IKEv2? ›

VPN Type – IKEv2 EAP (Username/Password). Username – your IVPN account ID that begins with letters 'ivpnXXXXXXXX' or 'i-XXXX-XXXX-XXXX' (case-sensitive). Password – ivpn .

How do I connect to IKEv2 VPN? ›

Select Network and Internet Options.
  1. On the VPN tab, click Add VPN Connection.
  2. In the Subscriptions section, look for domains of IKEv2 VPN servers, as well as the Username and Password VPN.
  3. Choose: Windows (Built-in) ...
  4. Connect to IKEv2 VPN server on Windows 10.
  5. Connection to IKEv2 VPN established successfully.

Is IKEv2 safe? ›

Highly secure as it encrypts with high-end cyphers, including AES and Camellia, and 256-bit encryption algorithms. Offers a strong and stable connection, allowing users to stay on the VPN connection when switching between networks.

What is the purpose of IKEv2? ›

IKEv2 enhances the function of negotiating the dynamic key exchange and authentication of the negotiating systems for VPN. IKEv2 also simplifies the key exchange flows and introduces measures to fix ambiguities and vulnerabilities inherent in IKEv1. IKEv2 provides a simpler message flow for key exchange negotiations.

Does IKEv2 require certificates? ›

When a Mobile VPN with IKEv2 tunnel is created, the identity of each endpoint must be verified with a certificate. Firebox certificates and third-party certificates are supported. If you use a certificate for authentication, it is important to track when the certificates expire.

How do I authenticate a digital signature? ›

5 Steps for Validating Digital Signatures In a PDF
  1. Open the digitally signed PDF that you need to validate using Power PDF.
  2. Locate the digital signature object within the document.
  3. Right click or command-click on the signature object.
  4. Select "Verify Signature" from the context menu.

What is the most common authentication protocol? ›

Let's explore some of the most popular authentication protocols.
  • Kerberos:
  • LDAP:
  • OAuth 2.0:
  • OpenID Connect:
Oct 22, 2023

What is the difference between signature and authentication? ›

Authentication is about verifying that the user is who he claims to be. A digital signature is about protecting the integrity of certain data and asserting that the data originated from a certain user.

What encryption does IKEv2 use? ›

For the technically minded, IKEv2/IPsec uses the AES-256-GCM cipher for encryption, coupled with SHA2-384 for integrity. In addition, IKEv2/IPsec uses Perfect Forward Secrecy (PFS) with 3072-bit Diffie-Hellman keys.

What is EAP authentication in IKEv2? ›

Abstract - IKEv2 is a protocol for exchanging keys in the IPsec architecture. In it's specification, EAP was proposed as one of the authentication mechanisms. EAP is extensible authentication protocol based on client/server architecture and allows introduction of additional EAP methods.

What are the authentication methods for SSL VPN? ›

SSL VPN authentication
  • SSL VPN with LDAP user authentication.
  • SSL VPN with LDAP user password renew.
  • SSL VPN with LDAP-integrated certificate authentication.
  • SSL VPN for remote users with MFA and user case sensitivity.
  • SSL VPN with FortiToken mobile push authentication.
  • SSL VPN with RADIUS on FortiAuthenticator.

What is the authentication method of SecurID? ›

SecurID requires users to both possess a token authenticator and to supply a PIN or password. Token authenticators generate one-time passwords that are synchronized to an RSA Authentication Manager (AM) and may come in the form of hardware or software.

References

Top Articles
Latest Posts
Recommended Articles
Article information

Author: Arline Emard IV

Last Updated:

Views: 6339

Rating: 4.1 / 5 (52 voted)

Reviews: 91% of readers found this page helpful

Author information

Name: Arline Emard IV

Birthday: 1996-07-10

Address: 8912 Hintz Shore, West Louie, AZ 69363-0747

Phone: +13454700762376

Job: Administration Technician

Hobby: Paintball, Horseback riding, Cycling, Running, Macrame, Playing musical instruments, Soapmaking

Introduction: My name is Arline Emard IV, I am a cheerful, gorgeous, colorful, joyous, excited, super, inquisitive person who loves writing and wants to share my knowledge and understanding with you.