Using Classic McEliece in the Internet Key Exchange Protocol Version 2 (IKEv2)

IKEv2 () is a protocol for authentication and for generating keys for IPsec (). Part of it is generating keys. Classic McEliece () provides a code-based Key Encapsulation Method (KEM) designed to be safe even against an adversary equipped with a quantum computer. The twelve parameter sets described in section 9 of offers different balances between performance and output sizes. The information needed for key agreement (in the case of McEliece this is a public key and a ciphertext) is carried in Key Exchange (KE) payloads. With the most common parameter set from the draft, mceliece6688128, the public key requires (see section 8.2.7 of the McEliece document) 1044992 octets to encode. This is almost 16 times as big as a standard KE payload (or any other payload) can carry, so we need to use a big payload, as specified in the big payload draft (). Because large payloads cannot be used in the IKE_SA_INIT exchange (see section 2.3 of ), the first key exchange has to use another algorithm, such as classic Diffie- Hellman or an elliptic curve variant. The McEliece exchange needs to be carried in an IKE_INTERMEDIATE exchange (), after negotiating in the IKE_SA_INIT both support for big payloads and the additional key exchange exchange through the INTERMEDIATE_EXCHANGE_SUPPORTED notify message (). The Classic Mceliece KEM can also be used in CREATE_CHILD_SA. For that, support for the intermediate exchange is not necessary. TBD if this document should make any recommendations about which DH group to use for the initial key exchange, or whether it should remain silent on the topic.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. It is assumed that readers are familiar with the IKEv2 protocol .

Classic McEliece is a code-based Key Encapsulation Mechanism (KEM) that is considered conservative and very thoroughly analysed. The document specifies 12 parameter sets. Should we just leave it at that, or specify just one? The current SSH candidate draft specifies only mceliece6688128. The current TLS candidate draft specifies 3: mceliece6688128, mceliece6960119, and mceliece8192128. Official Classic McEliece site lists 5 parameter sets. What should we do? This is up to the working group. Until this is decided, we added a comparison table between the parameter sets here. Ultimately, there is nothing special about IKEv2. What is fitting for TLS and SSH is likely fitting for IKEv2 as well.

Parameter Set	Claimed NIST Leve	Public key size (bytes)	Secret key size (bytes)	Ciphertext size (bytes)	Shared secret size (bytes)
mceliece348864	1	261120	6492	96	32
mceliece460896	3	524160	13608	156	32
mceliece6688128	5	1044992	13932	208	32
mceliece6960119	5	1047319	13948	194	32
mceliece8192128	5	1357824	14120	208	32

To negotiate the use of the McEliece KEM, an IKEv2 initiator and responder MUST negotiate three things in the IKE_SA_INIT exchange:

The support for big IKE payloads
Support for IKE fragmentation
The use of these groups, see , in an ADDKE* transform. This implies support for the IKE_INTERMEDIATE exchange

Since all of the above have to be specified in the IKE_SA_INIT request, the McEliece key exchange, cannot be used in the IKE_SA_INIT exchange and a Responder MUST reject any McEliece group offered in the KE transform. Additionally, it MUST reject any McEliece group offered in an ADDKE* transform if the initiator has not also proposed the use of three extensions: IKE_INTERMEDIATE exchange, big payloads and IKE fragmentation. Within the IKE_INTERMEDIATE exchange, such payloads will normally encode the large public keys. A diagram is provided here for illustration:. The format below is the big payload version of the Key Exchange payload from section 3.4 of .

L is 1, indicating that the length field is 32-bit.
The Key Exchange Method is TBD, the value assigned by IANA (see )
The McEliece KEM key data is as described in section 6.3 of .

Note that when the KE payload is used to carry ciphertext, it can fit with the short payload format. It is not required to always use the big payload format to use Classic McEliece.

The Classic McEliece KEM can also be used in the CREATE_CHILD_SA exchange (or in the IKE_FOLLOWUP_KE exchange as defined in ) to rekey IKE SA and to create/rekey IPsec SAs. The format and size are just the same, so doing this also requires support for big payloads and for IKE fragmentation. However, if Classic McEliece is only used in these exchanges, there is no need to negotiate the IKE_INTERMEDIATE exchange.

While an IKE SA that utilizes Classic McEliece can run over UDP, in most settings this will be problematic. The reason is that with tipical MTU size of 1500 bytes, an IKE message containing Classic McEliece public key will be splitted into several hundreds IKE fragment messages, which will be sent to the network at once. This may lead to network congestion causing loss of some messages, in which case all the fragment messages will be re-sent again (after timeout), since IKE fragment messages are not individually acknowledged. This will also lead to congestion and the process will repeat until all the fragment messages will be received, but this might not happen. For this reason peers may want to use TCP as a transport. Peers may choose between using TCP for both IKE and ESP as specified in or using separate transports for them . The latter allows to avoid performance degradation when tunnelling TCP trafic and thus is RECOMMENDED. Note, that despite the fact, that TCP can tranfer messages of any size without having problems with IP fragmentation, in case of Classic McEliece peers still have to negotiate IKE fragmentation as defined in , even when they choose to use TCP as a transport for IKE. This is due to the limitation imposed by that individual IKE message in TCP stream cannot exceed 64 Kbytes. Thus, larger IKE messages need to be be fragmented to this size by IKE fragmentation mechanism before sending over TCP.

This inherits the security of IKEv2, the additional key exchange extension, the big payload extension, and of course, classic McEliece. Some discussion about choice of group for the initial key exchange should be added here. Probably more about McEliece here.

IANA is requested to assign one (or is it three) values from the "Transform Type 4 - Key Exchange Method Transform IDs" registry with name "mceliece6688128" (and maybe also "mceliece6960119" and "mceliece8192128") and this document as reference.