Hi Everyone, Following our earlier research in the PQUIP WG regarding PQC migration in telecom systems, our team have recently been implementing IKEv2 migration based on RFC 9370. During this process, we encountered some negotiation failures related to ADDKEs that I would like to bring to the WG's attention for discussion.
During our PoC testing, we observed that IKE configuration errors-specifically, configuring the same algorithm redundantly in ADDKE payloads during IKE negotiation-frequently lead to negotiation failures. According to RFC 9370, Section 2.2.1 (which also references RFC 7296, Section 2.7), the implementation shall be strictly limited: "the responder MUST select one of the algorithms proposed using this type... the responder's choice MUST NOT contain duplicated algorithms (those with an identical Transform ID and attributes), except for the Transform ID of NONE." Based on feedback from our testing, some errors may be occurred frequently in the configuration, and they were negotiation failed. After troubleshooting, We found that the error was due to the same algorithm being configured in ADDKEs during IKE in a redundance. For example, placing ML-KEM-768 in multiple ADDKEs I would like to start a discussion on whether these strict in 2.2.1 limitations for ADDKEs could have consideration for future releases (for instance, in PQC-specific profiles like ML-KEM). Considering the real-world possibility of configuration redundancies. Interestingly, also as part of our research verification, we found that some open-source implementations (e.g., strongSwan) handle ADDKE differently. Instead of strict responder selection, the algorithm negotiation is often simplified to finding the intersection of multiple ADDKEs between peers. ------- I can explain more how this configuration error may happen. Let me know if someone may interested in the issue or have historical discussion on this. Best regards, Lun Li
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
