Page MenuHomeVyOS Platform

RFC9370 Multiple Key Exchange Support in IPSEC
Open, LowPublicFEATURE REQUEST

Description

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.

Details

Version
-
Is it a breaking change?
Perfectly compatible
Issue type
Feature (new functionality)

Event Timeline

Viacheslav changed the subtype of this task from "Task" to "Feature Request".Wed, Oct 21, 11:50 AM