Hi, in response to the new version of draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize the issue of DoS attacks during intermediate exchanges. The new version does address it by mentioning the option of simply avoiding intermediate exchanges altogether but still require additional key exchanges. Yet, this protects only against record-and-harvest attacks but not against an attacker with a strong quantum computer at the time of the handshake, regardless of quantum-resistant authentication (since they can break the initial shared secret and therefore recalculate the MAC which authenticates the followup exchanges, fully establishing a man-in-the-middle). We doubt that an attacker, even with a strong quantum computer, is able to break a key exchange in such a short time period. Still, this assumption is too theoretical to rely on. This, together with the fact that Group-IKE is incompatible with key exchanges during followup exchanges, makes the option seem inferior to just sticking to intermediate exchanges during the handshake. However, we must also consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt. An attacker who exploits the large key exchanges, e.g., by requesting seven additional maximum size McEliece key exchanges, can force a gateway to accept and process 1.4MB of data per McEliece KEM. This leaves us at a situation where we must pick one of the following options:
1. Accept the highly increased risk of DoS attacks. 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. 3. Prohibit the use of intermediate exchanges, leaving the IKE SA initially unprotected and being vulnerable to an attacker with a quantum computer during the handshake. To us, none of these options seems desirable. Thus, we propose another solution which sees one new transform type, e.g., SNTRUP761X25519, which then defines a combination of one classical algorithm (like ECDH based on curve25519) and one pqc algorithm which fits into IKE_SA_INIT without fragmentation (like sntruprime761). The two secrets get concatinated and then fed to a hash function. The resulting hash is used as the shared secret for further key derivation. This mechanism is low effort in terms of implementation and does not affect the state machine at all, but already offers a high level of protection against all attacks as long as there is no major break-through in cryptanalysis. Furthermore, it is the accepted approach for most of the applications of post-quantum key exchanges. For higher long-term security, it can be combined with other, more conventional algorithms which follow either in intermediate or followup exchanges. We then propose to restrict the use of large key exchanges to the context of option 3, which removes the risk of the described DoS attacks. Yet, to prevent the insecurities of plain option 3, we also propose to make it mandatory to combine it with the new hybrid transform type, i.e., SNTRUP761X25519. The only downside of this approach is that G-IKE is then incompatible with the McEliece exchange. However, the fact that G-IKE exchanges sensitive information before authentication makes it impossible to be not vulnerable against the discussed DoS attack and, at the same time, support the McEliece algorithm. Thus, we see that as a decision to be made in the G-IKE standardization track, not in IKEv2. Regards, Stefan-Lukas Gazdag, Daniel Herzinger
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
