Internet-Draft IKEv2 PQTH Auth June 2026
Hu, et al. Expires 28 December 2026 [Page]
Workgroup:
ipsecme
Internet-Draft:
draft-hu-ipsecme-pqt-hybrid-auth-05
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Hu
Nokia
Y. Morioka
NTT DOCOMO, INC.
G. Wang
Huawei

Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2)

Abstract

One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA, which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptographic (PQC) algorithms for digital signature like NIST [ML-DSA], However, it takes time for new cryptographic algorithms to mature, There is security risk to use only the new algorithm before it is field proven. This document describes a hybrid PKI authentication scheme for IKEv2 that incorporates both traditional and PQC digital signature algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure.

About This Document

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

The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-hu-ipsecme-pqt-hybrid-auth/.

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

Source for this draft and an issue tracker can be found at https://github.com/USER/REPO.

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 28 December 2026.

▲

Table of Contents

1. Change log

1.1. changes in -05

  • rework announcement section to reuse RFC9593 existing multi-octet format; no protocol format changes

  • add Certificate Request section for type-1 and type-2 CERTREQ payload usage

  • add Verification subsection with step-by-step AUTH payload verification procedure

  • add Downgrade Attack Prevention subsection in Security Considerations

  • strengthen RelatedCertificate verification from SHOULD to MUST

  • update IANA Considerations to clarify only type-2 needs a new IANA AUTH_METHOD value

  • editorial changes

1.2. changes in -04

  • align to draft-ietf-lamps-pq-composite-sigs-14

  • add text to clarify two setup types

  • add text to describe the example exchange in section 5

  • clarify using of pre-hash alg

  • clarify sign operation in type-2

  • ietf-lamps-cert-binding-for-multi-auth is now RFC9763

  • ietf-lamps-dilithium-certificates is now RFC9881

  • editorial changes

1.3. changes in -03

  • version bump to keep doc alive

1.4. Changes in -02

  • clarify the approach in the document is general

  • dropping support for PreHash ML-DSA, change example to Pure Signature ML-DSA

  • adding more details in signing process to align with ietf-lamps-pq-composite-sigs-04

  • add text in Security Considerations to emphasize prohibit of key reuse

  • clarify the both C and S bit MAY be 1 at the same time

  • clarify the receiver behavior when the announcement contains no algid

  • typo fixes

1.5. Changes in -01

  • Only use SUPPORTED_AUTH_METHODS for algorithm combination announcement, no longer use SIGNATURE_HASH_ALGORITHMS

  • add flag field in the announcement

  • clarify two types of PKI setup

  • add some clarifications on how AUTH payload is computed

2. Introduction

A Cryptographically Relevant Quantum Computer (CRQC) could break traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA, which are widely deployed authentication options of IKEv2. New Post-Quantum Cryptographic (PQC) algorithms for digital signature were recently published like NIST [ML-DSA], However, by considering potential flaws in the new algorithm's specifications and implementations, it will take time for these new PQC algorithms to be field proven. So it is risky to only use PQC algorithms before they are mature. There is more detailed discussion on motivation of a hybrid approach for authentication in Section 1.2 of [I-D.ietf-pquip-hybrid-signature-spectrums].

This document describes a post-quantum traditional (PQ/T) hybrid digital signature authentication scheme for IKEv2 that incorporates both traditional and PQC digital signature algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure.

Each IPsec peer announces the support of hybrid authentication via SUPPORTED_AUTH_METHODS notification as defined in [RFC9593], generates and verifies AUTH payload using composite signature using the procedures defined in [I-D.ietf-lamps-pq-composite-sigs].

The approach specified in this document is a general framework for all PQC and traditional algorithms. The combinations of ML-DSA variants and traditional algorithms given in this document are instantiations of the general framework.

There are two types of PQ/T hybrid PKI setup:

  1. Type-1: A single certificate that has a composite key as defined in [I-D.ietf-lamps-pq-composite-sigs], which contains two component keys: one traditional key + one PQC key.

  2. Type-2: Two certificates, one certificate with traditional algorithm key and one certificate with PQC algorithm key as described in [RFC9763], Each certificate MAY contain RelatedCertificate extension to associate with the other certificate.

A given deployment could use either type to provide PQ/T hybrid PKI. This document supports both types.

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

Cryptographically Relevant Quantum Computer (CRQC): A quantum computer that is capable of breaking real world cryptographic systems.

Post-Quantum Cryptographic (PQC) algorithms: Asymmetric Cryptographic algorithms are thought to be secure against CRQC.

Traditional Cryptographic algorithms: Existing asymmetric Cryptographic algorithms could be broken by CRQC, like RSA, ECDSA ..etc.

4. IKEv2 Key Exchange

There is no changes introduced in this document to the IKEv2 key exchange process, although it MUST be also resilient to CRQC when using along with the PQ/T hybrid authentication, for example key exchange using the PPK as defined in [RFC8784], or hybrid key exchanges that includes PQC algorithm like [ML-KEM] via multiple key exchange process as defined in [I-D.ietf-ipsecme-ikev2-mlkem].

5. Exchanges

The hybrid authentication exchanges is illustrated in an example depicted in Figure 1, using PPK as defined in [RFC8784] during key exchange. However, other PQC key exchanges could also be used since how key exchange is done is independent from authentication.

Initiator                         Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni,
          N(USE_PPK) -->
                  <--  HDR, SAr1, KEr, Nr, [CERTREQ,] N(USE_PPK),
                                      N(SUPPORTED_AUTH_METHODS)

HDR, SK {IDi, CERT+, [CERTREQ,]
        [IDr,] AUTH, SAi2,
        TSi, TSr, N(PPK_IDENTITY, PPK_ID),
        N(SUPPORTED_AUTH_METHODS)} -->
                            <--  HDR, SK {IDr, CERT+, [CERTREQ,]
                                      AUTH, [N(PPK_IDENTITY)]}
Figure 1: Hybrid Authentication Exchanges with RFC8784 Key Exchange

  1. Responder announces the hybrid authentication support via SUPPORTED_AUTH_METHODS notification in IKE_SA_INIT response message. The notification includes the combinations of PQC, traditional, hash algorithm and type of hybrid PKI setup that responder supports.

  2. Initiator chooses a combination from responder's SUPPORTED_AUTH_METHODS, uses the combination to generate the AUTH payload, along with corresponding signing certificate(s) in CERT payload(s), and includes its support of hybrid combinations in SUPPORTED_AUTH_METHODS notification of IKE_AUTH request message.

  3. Responder chooses a combination from initiator's SUPPORTED_AUTH_METHODS, uses the combination to generate the AUTH payload, and includes corresponding signing certificate(s) in CERT payload(s) of IKE_AUTH response message.

5.1. Announcement

Announcement of support for hybrid authentication is through the SUPPORTED_AUTH_METHODS notification as defined in [RFC9593], using multi-octet announcements. This document uses the existing multi-octet announcement format from [RFC9593] with the following AUTH_METHOD values:

  1. For type-1 (composite key certificate): use AUTH_METHOD value 14 (Digital Signature, as defined in [RFC7427]) together with the composite signature AlgorithmIdentifier as defined in Section 7 of [I-D.ietf-lamps-pq-composite-sigs].

  2. For type-2 (two separate certificates): use a new IANA-assigned AUTH_METHOD value together with the composite signature AlgorithmIdentifier corresponding to the combination of the two certificates. If the Cert Link field contains a non-zero value N, it means the method is intended to be used with the N-th and N+1-th trust anchor CA from the Certificate Request payload(s). see Section 5.2.2 for more details.

There is no change to the existing multi-octet announcement protocol format defined in [RFC9593]. The only new protocol element introduced by this document is the new IANA-assigned AUTH_METHOD value for type-2.

For example, if a system supports the following authentication configurations:

  • A: MLDSA44 + RSA2048_PSS as type-1

  • B: MLDSA44 + ECDSA-P256 as type-1

  • C: MLDSA44 + RSA2048_PSS as type-2

It will include 3 multi-octet announcements in the SUPPORTED_AUTH_METHODS payload:

  • Auth-method 14 with AlgorithmIdentifier id-MLDSA44-RSA2048-PSS-SHA256, for A above

  • Auth-method 14 with AlgorithmIdentifier id-MLDSA44-ECDSA-P256-SHA256, for B above

  • Auth-method NEW_VAL_for_TYPE2 with AlgorithmIdentifier id-MLDSA44-RSA2048-PSS-SHA256, for C above

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Length (>3)  |      14       |   Cert Link   |               |  <- A
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    ~          id-MLDSA44-RSA2048-PSS-SHA256 (AlgorithmIdentifier)  ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Length (>3)  |      14       |   Cert Link   |               |  <- B
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    ~          id-MLDSA44-ECDSA-P256-SHA256 (AlgorithmIdentifier)   ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Length (>3)  | NEW_VAL_TYPE2 |   Cert Link   |               |  <- C
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    ~          id-MLDSA44-RSA2048-PSS-SHA256 (AlgorithmIdentifier)  ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example SUPPORTED_AUTH_METHODS Payload with 3 Announcements

Each AlgorithmIdentifier is the variable-length ASN.1 object encoded using Distinguished Encoding Rules (DER) [X.690] that identifies a composite signature algorithm as defined in Section 7 of [I-D.ietf-lamps-pq-composite-sigs], specifying a combination of:

  • a PQC algorithm (e.g. id-ML-DSA-44)

  • a traditional PKI algorithm (e.g. id-RSASA-PSS)

  • a pre-hash algorithm (e.g. id-sha256)

5.2. Certificate Request

This section describes how peers use Certificate Request (CERTREQ) payloads when performing hybrid authentication.

5.2.1. Type-1

For type-1 hybrid authentication, a single CERTREQ payload MAY be sent referencing the CA that issued the composite certificate. The CERTREQ uses the standard hash-of-CA-public-key format as defined in Section 3.7 of [RFC7296].

5.2.2. Type-2

For type-2 hybrid authentication, two CERTREQ payloads MAY be sent: the first hash refer to the PQC certificate CA (issuer of the PQC certificate), and directly follow by the hash refer to traditional certificate CA (issuer of the traditional certificate).

5.3. AUTH & CERT payload

The IKEv2 AUTH payload has following format as defined in Section 3.8 of [RFC7296]:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Next Payload  |C|  RESERVED   |         Payload Length        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Auth Method   |                RESERVED                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                      Authentication Data                      ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: AUTH payload

For hybrid authentication, the Auth Method is either value 14 (Digital Signature) for type-1 or the new IANA-assigned value for type-2, as defined in Section 5.1

The Authentication Data field follows format defined in Section 3 of [RFC7427]:

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | ASN.1 Length  | AlgorithmIdentifier ASN.1 object              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~        AlgorithmIdentifier ASN.1 object continuing            ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                         Signature Value                       ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Authentication Data in hybrid AUTH payload

Based on selected AlgorithmIdentifier and setup type, the Signature Value is created via procedure defined in Section 5.3.1, Section 5.3.2.

5.3.1. Type-1

Assume selected AlgorithmIdentifier is A.

  1. There is no change on data to be signed, e.g. InitiatorSignedOctets/ResponderSignedOctets as defined in Section 2.15 of [RFC7296]

  2. Follow Sign operation identified by A, e.g. Section 3.2 of [I-D.ietf-lamps-pq-composite-sigs]. The ctx input is the string of "IKEv2-PQT-Hybrid-Auth". This step outputs the composite signature, a CompositeSignatureValue.

  3. CompositeSignatureValue is serialized per Section 4.3 of [I-D.ietf-lamps-pq-composite-sigs], and the output is used as Signature Value in the Authentication Data field.

Note: [I-D.ietf-lamps-pq-composite-sigs] uses a pre-hash algorithm with [ML-DSA] pure mode (Algorithm 2), not the HashML-DSA as defined in [ML-DSA], see Section 2.1 of [I-D.ietf-lamps-pq-composite-sigs] for the rationale.

Following is an initiator example:

  1. A is id-MLDSA44-RSA2048-PSS-SHA256, which uses PQC ML-DSA-44 and traditional RSASSA-PSS with pre-hash function SHA256

  2. Follow Section 3.2 of [I-D.ietf-lamps-pq-composite-sigs] with following inputs:

    • sk is the private key of the signing composite key certificate

    • M is InitiatorSignedOctets

    • ctx is "IKEv2-PQT-Hybrid-Auth"

The signing composite certificate MUST be the first CERT payload.

5.3.2. Type-2

  1. Combine PQC key and traditional key into composite key using SerializePrivateKey operation as defined in Section 4.2 of [I-D.ietf-lamps-pq-composite-sigs].

  2. Follow Sign operation as Section 5.3.1

Note: Section 6 of [RFC9881] defines 3 options for ML-DSA private key storage, this document requires options that include seed since Sign operation of [I-D.ietf-lamps-pq-composite-sigs] only supports seed.

With example in Section 5.3.1:

  • sk is the combined private key, e.g. output of SerializePrivateKey

  • M is InitiatorSignedOctets

  • ctx is "IKEv2-PQT-Hybrid-Auth" (21 octets, no null terminator)

The signing PQC certificate MUST be the first CERT payload in the IKEv2 message, while traditional certificate MUST be the second CERT payload.

5.3.2.1. RelatedCertificate

In type-2 setup, the signing certificate MAY contain RelatedCertificate extension, then the receiver MUST verify the extension according to Section 4.2 of [RFC9763]. Failed verification MUST cause authentication to fail.

5.3.3. Verification

This section specifies how a receiver verifies the hybrid AUTH payload produced by the signing procedures defined in Section 5.3.1 and Section 5.3.1.

The receiver performs the following steps:

  1. Determine the setup type from the Auth Method and AlgorithmIdentifier:

    • Type-1: if Auth Method is 14 and the AlgorithmIdentifier is one of algorithms defined in [I-D.ietf-lamps-pq-composite-sigs]

    • Type-2: if Auth Method is the new IANA assigned value

  2. Verify that setup and AlgorithmIdentifier matches one of the combinations previously announced in the SUPPORTED_AUTH_METHODS notification. If no match is found, the receiver MUST reject the exchange with AUTHENTICATION_FAILED.

  3. Obtain public key from the CERT payload(s):

    • For type-1: obtain the composite public key from the composite certificate in the first CERT payload.

    • For type-2: obtain the PQC public key from the PQC certificate (first CERT payload) and the traditional public key from the traditional certificate (second CERT payload). Reconstruct the composite public key using the SerializePublicKey operation as defined in Section 4.1 of [I-D.ietf-lamps-pq-composite-sigs].

  4. Run the Verify operation as defined in Section 3.3 of [I-D.ietf-lamps-pq-composite-sigs] with the following inputs:

    • pk: the composite public key obtained in step 4

    • M: InitiatorSignedOctets or ResponderSignedOctets as defined in Section 2.15 of [RFC7296], depending on which peer's AUTH payload is being verified

    • ctx: the ASCII encoding of the string "IKEv2-PQT-Hybrid-Auth" (21 octets, no null terminator)

    • sig: the Signature Value from the Authentication Data field

  5. If the Verify operation returns failure, the receiver MUST reject the IKE_AUTH exchange with AUTHENTICATION_FAILED.

6. Security Considerations

The security of general PQ/T hybrid authentication is discussed in [I-D.ietf-pquip-hybrid-signature-spectrums].

This document uses mechanisms defined in [I-D.ietf-lamps-pq-composite-sigs], [RFC7427] and [RFC9593], so the security discussion in the corresponding RFCs also apply.

One important security consideration mentioned in [I-D.ietf-lamps-pq-composite-sigs] worth repeating here is that component key used in either Section 5.3.1 or Section 5.3.2 MUST NOT be reused in any other cases including single-algorithm case.

6.1. Downgrade Attack Prevention

The IKE_SA_INIT exchange is not integrity-protected, and an active attacker on the network path can modify or remove the SUPPORTED_AUTH_METHODS notification from an IKE_SA_INIT message. If such a notification is stripped from the responder's IKE_SA_INIT response, an initiator that supports both hybrid and non-hybrid authentication may fall back to traditional-only authentication without being aware of the attack.

To prevent downgrade attacks, for a system that is configured to require mutual hybrid authentication for a given peer MUST NOT accept peer's SUPPORTED_AUTH_METHODS that doesn't contain expected hybrid authentication method & algorithm, also MUST NOT accept an IKE_AUTH exchange in which the remote peer's AUTH payload uses a non-hybrid Auth Method.

7. IANA Considerations

This document requests a new value in the "IKEv2 Authentication Method" subregistry under the IANA "Internet Key Exchange Version 2 (IKEv2) Parameters" registry for the type-2 (two-certificate) PQ/T hybrid authentication method. Type-1 (composite key certificate) hybrid authentication reuses the existing AUTH_METHOD value 14 (Digital Signature) and requires no new IANA allocation.

8. References

8.1. Normative References

[I-D.ietf-lamps-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S. Fluhrer, "Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure", Work in Progress, Internet-Draft, draft-ietf-lamps-pq-composite-sigs-19, , <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-19>.
[I-D.ietf-pquip-hybrid-signature-spectrums]
Bindel, N., Hale, B., Connolly, D., and F. D, "Hybrid signature spectrums", Work in Progress, Internet-Draft, draft-ietf-pquip-hybrid-signature-spectrums-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-hybrid-signature-spectrums-07>.
[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>.
[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>.
[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>.
[RFC9593]
Smyslov, V., "Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9593, DOI 10.17487/RFC9593, , <https://www.rfc-editor.org/rfc/rfc9593>.
[RFC9763]
Becker, A., Guthrie, R., and M. Jenkins, "Related Certificates for Use in Multiple Authentications within a Protocol", RFC 9763, DOI 10.17487/RFC9763, , <https://www.rfc-editor.org/rfc/rfc9763>.
[RFC9881]
Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", RFC 9881, DOI 10.17487/RFC9881, , <https://www.rfc-editor.org/rfc/rfc9881>.
[X.690]
"Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2021 (E), ITU-T Recommendation X.690, .

8.2. Informative References

[I-D.ietf-ipsecme-ikev2-mlkem]
Kampanakis, P., "Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)", Work in Progress, Internet-Draft, draft-ietf-ipsecme-ikev2-mlkem-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-mlkem-07>.
[ML-DSA]
"Module-Lattice-Based Digital Signature Standard", NIST FIPS-204, , <https://csrc.nist.gov/pubs/fips/204/final>.
[ML-KEM]
"Module-Lattice-Based Key-Encapsulation Mechanism Standard", NIST FIPS-203, , <https://csrc.nist.gov/pubs/fips/203/final>.
[RFC8784]
Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security", RFC 8784, DOI 10.17487/RFC8784, , <https://www.rfc-editor.org/rfc/rfc8784>.
[RFC9370]
Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, , <https://www.rfc-editor.org/rfc/rfc9370>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Jun Hu
Nokia
United States of America
Yasufumi Morioka
NTT DOCOMO, INC.
Japan
Guilin Wang
Huawei
Singapore