On 16.04.26 12:18, lilun (F) wrote: > 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."/
The important part there is "responder's choice". It's perfectly fine to configure as well as send the same algorithms in ADDKEs as initiator. The responder just has to make sure its proposal selection process does result in a unique algorithm for each ADDKE (except for 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. Yes, we have simplified the process a bit in so far that we only check individual ADDKEs (sequentially) and avoid duplicates overall. So we currently can't handle situations like ADDKE1[A, B], ADDKE2[B, C] with a local config of ADDKE1[B, A], ADDKE2[B, A]. We'd select ADDKE1[B] (preferring the local config and order by default) but that prevents selecting it for ADDKE2, so no valid proposal results. However, ADDKE1[A], ADDKE2[B] would technically be acceptable by both peers (in this particular example disabling prefer_configured_proposals would make it work). Regards, Tobias _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
