The label is just the same label specified in section 6 of draft-ietf-lamps-pq-composite-sigs-15<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-15#section-6> For other combinations that not defined the lamps draft, my current thinking is not support them to make thing simpler, since I don’t see too much value of using a combination that not supported by PKI because in the end you still need to do the certificate chain verification in addition to the IKEv2 authentication.
but I am open for discussion. From: Scott Fluhrer (sfluhrer) <[email protected]> Sent: Friday, February 27, 2026 2:38 PM To: Scott Fluhrer (sfluhrer) <[email protected]>; Jun Hu (Nokia) <[email protected]>; IPsecME WG <[email protected]> Subject: Re: New Version Notification for draft-hu-ipsecme-pqt-hybrid-auth-04.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Oh, and another question about type-2; you take the traditional signature algorithm, the postquantum one, and the hash function, and smoosh them together to generate a composite key. What's the label you're supposed to use to generate or verify the signatures (see section 2.2 of draft-ietf-lamps-pq-composite-sigs for an outline of what the label is)? That draft defines the label for the combinations it defines but is silent about any other combination. And, what if either of the traditional or the postquantum algorithms (or the hash function) isn't already given a label in draft-ietf-lamps-pq-composite-sigs? ________________________________ From: Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>> Sent: Friday, February 27, 2026 4:11 PM To: Jun Hu (Nokia) <[email protected]<mailto:[email protected]>>; IPsecME WG <[email protected]<mailto:[email protected]>> Subject: [IPsec] Re: New Version Notification for draft-hu-ipsecme-pqt-hybrid-auth-04.txt Two comments: * In section 5, "the initiator chooses a combination from the responder's SUPPORTED_AUTH_METHODS"; but no guidance is given about how to make this choice (and similarly for the responder). Ultimately, the proper choice would depend on the peer's policy, that is, what sets of signatures the peer would insist on as a proper validation, and no mechanism exists for communicating that for multiple certificates (currently, it is implied that any single supported signature algorithm with a valid certificate is sufficient). When multiple certificates are in play, then a peer might have either of these policies: "I'd prefer an RSA cert and an ML-DSA cert, but I'll accept only an RSA cert" (which the peer might do during a general upgrade), or your policy might be "You must have an RSA cert and an ML-DSA cert, or I won't talk to you" *which might be after you've upgraded all your peers). Now, I suppose you can say "choose the maximal set of certificates, and if that'd not sufficient, the IKE negotiation would fail" - I believe that a cleaner approach would be to inform the peer of the policy up front (and if we can't abide by that, the error is more apparent). * I personally disagree with bolting into the protocol any characterization of a cryptographical algorithm beyond the minimal ("it's a signature algorithm"). Your protocol makes an explicit distinction between "traditional" and "PQC"; in the future, that understanding may change or get more nuanced. I believe it would be wise if the protocol took a broader and more extensible view. ________________________________ From: Jun Hu (Nokia) <[email protected]<mailto:[email protected]>> Sent: Friday, February 27, 2026 3:22 PM To: IPsecME WG <[email protected]<mailto:[email protected]>> Subject: [IPsec] FW: New Version Notification for draft-hu-ipsecme-pqt-hybrid-auth-04.txt Hi, Here is an update to draft-hu-ipsecme-pqt-hybrid-auth, review and comments are appreciated What's changed in v04: * 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 -----Original Message----- From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Friday, February 27, 2026 11:20 AM To: Guilin WANG <[email protected]<mailto:[email protected]>>; Guilin Wang <[email protected]<mailto:[email protected]>>; Jun Hu (Nokia) <[email protected]<mailto:[email protected]>>; Yasufumi Morioka (森岡 康史) <[email protected]<mailto:[email protected]>> Subject: New Version Notification for draft-hu-ipsecme-pqt-hybrid-auth-04.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. A new version of Internet-Draft draft-hu-ipsecme-pqt-hybrid-auth-04.txt has been successfully submitted by Jun Hu and posted to the IETF repository. Name: draft-hu-ipsecme-pqt-hybrid-auth Revision: 04 Title: Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2) Date: 2026-02-27 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/archive/id/draft-hu-ipsecme-pqt-hybrid-auth-04.txt Status: https://datatracker.ietf.org/doc/draft-hu-ipsecme-pqt-hybrid-auth/ HTML: https://www.ietf.org/archive/id/draft-hu-ipsecme-pqt-hybrid-auth-04.html HTMLized: https://datatracker.ietf.org/doc/html/draft-hu-ipsecme-pqt-hybrid-auth Diff: https://author-tools.ietf.org/iddiff?url2=draft-hu-ipsecme-pqt-hybrid-auth-04 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. The IETF Secretariat _______________________________________________ IPsec mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
