I wanted to start conversation on implementing RFC 9370 support. strongSwan implements this within the propoals = stanza. They use keX_<algo>, where X is an integer between 1 and 7 and the algorithm is one of the support key exchange methods.
keX_none is supported to allow for a specific key exchange to be optional.
strongSwan documentation says there can be gaps in X, and give the example "x25519-ke7_mlkem768" as being perfectly valid.
9370 is required to support the larger key sizes of ML-KEM. Generally a traditional DH/ECDH exchange happens since IKE_INIT can't be fragmented, then the use of additional key exchanges would provide the post-quantum protection of the shared secret key.
I propose as an initial config change the introduction of something like the following
set proposal 10 mke 1 mlkem1024 set proposal 10 mke 2 x25519 set proposal 20 mke 1 mlkem1024 set proposal 20 mke 2 none set proposal 30 mke 1 none set proposal 30 mke 2 none
This would yield a configuration that looks similar to the following
proposal 10 {
dh-group 20
encryption aes256gcm128
hash sha384
mke {
1 mlkem1024
2 x25519
}
}
proposal 20 {
dh-group 20
encryption aes256gcm128
hash sha384
mke {
1 mlkem1024
2 none
}
}
proposal 30 {
dh-group 20
encryption aes256gcm128
hash sha384
mke {
1 none
2 none
}
}Resulting jinja (peer.j2) template would need to create something similar to the following.
proposals = aes256gcm128-ecp384-sha384-ke1_mlkem1024-ke2_x25519,aes256gcm128-ecp384-sha384-ke1_mlkem1024-ke2_none,aes256gcm128-ecp384-sha384-ke1_none-ke2_none
strongSwan docs on key exchanges: https://docs.strongswan.org/docs/latest/config/proposals.html#_key_exchange_methods
strongSwan example road-warrior config with ML-KEM: https://www.strongswan.org/testing/testresults/ikev2/rw-mlkem/moon.swanctl.conf
Very open to feedback on how to best work the configuration. The strongSwan side is pretty straight forward, but I'm not sure the best way for a user to define the values.