Daniel Herzinger writes: > the fact is that accepting a significantly increased amount of data > from an unauthenticated peer also significantly increases the > surface to DoS attacks.
Accepting data is not a DoS attack problem. If the other end sends you lots of packets, you will have to cope with that, there is nothing you can do to limit it sending you data. Sending data back is where we might get DoS amplification factor, but what the amplification factor is depends on the size of packets initiator sends you and what is size of packets you send back. With normal Diffie-Hellman those both are same, so there is no amplification factor. Also amplification factor is really important only when you can do it as (D)DoS attack against third party. I.e., you use source attack of the intended victim on your message and send the message to some real server on the network who will send bigger reply back to the victim, not to the attacker. If the attacker can send small packet and get much bigger packet back then he gains amplification and he is better of using this kind of reflected attack instead of sending packets to victim himself. Of course if he can use lots of reflectors on the network he can do even better, i.e., make a DDoS attack... In IKEv2 this is only possible with the IKE_SA_INIT, because all later packets do require you to be on the path to see the response packets from the server to victim to be able to continue exchange. In the IKEv2 we do have protection against that, so the responders IKE_SA_INIT response is usually smaller than the request from the initiator. The SA payload will be either same or smaller, nonce payloads can be bit different lengths, but they are limited to 64 bytes, KE payloads are of same size, optional CERTREQ from the server is usually only few hashes thus few tens of bytes. Also the initiator usually adds several notify payloads and responder only reflects back those it supports. And if responder decideds to send back cookie request, to verify the source address of the initiator, then the response packet is much smaller. > Even without surpassing the 64KB limit, this must be a concern. > IKEv2's cookie mechanism and puzzles try to increase the cost of the > attacker per each connection. Now, an attacker must still accept > these costs but can use one connection to trigger several key > exchanges, all significantly larger than what we had with DH, making > the trade-off way better for them compared to non-pqc IKEv2. No it cannot. Attacker can use cookie only once, and will only get one exchange created by each cookie exchange, thus it needs to do puzzles and cookies again for every single attack packet it wants to send. Immediately when he sends the packet after the IKE_SA_INIT (i.e., IKE_AUTH or IKE_INTERMEDIATE) the SPIi is consumed, thus if he tries to send another IKE_AUTH/IKE_INTERMEDIATE with same SPIi the responder will assume it is just retransmission of the previous IKE_AUTH/IKE_INTERMEDIATE (if it is identical than last time) and then it will retransmit its response from last time. If the attacker modifies the IKE_AUTH/IKE_INTERMEDIATE request it sends, the initiator will ignore it as it is not retransmission and it is not valid message to the existing IKE SA. And to be able to send valid IKE_AUTH/IKE_INTERMEDIATE that will cause any action on the initiator will again require the attacker to be on path i.e., be somewhere where it can see the IKE_SA_INIT response the initiator sent, thus attacker in a position where it can do much more harm than simple DoS using reflection attack. So I do not think DoS attack properties of the IKEv2 is at all modified with addition to the multiple ke, or beyond 64k limit drafts. > So, the attacker could, e.g., negotiate several FrodoKEMs (all with > different parameters to circumvent the rule that all key exchange > methods must be different). Compared to classical non-hybrid (EC)DH, > such a DoS attack requires significantly less cost to have the same > effect. Why should the responder accept such proposal? What benefits is there to do multiple FrodoKEMs with different parameters in normal case? I would assume responder would simply pick one of the FrodoKEMs with the parameters that match its security requirements, and only use that, and if initiator does not offer a way to pick only one, the initiator will rejecte the whole proposal. The SAi and SAr exchange in the IKE_SA_INIT is a agreement protocol where initiator proposes list of algorithms, and responder picks suitable (sub)set of algorithms. Initiator of course only proposes algorithms that are acceptable for him based on his security policy, and responder will only pick algorithm sets which are acceptable for his security policy. > The introduction of MB-sized key exchanges just amplifies this > problem even further (also allowing several McEliece KEMs with > different parameters circumventing this constraint). I would assume most implementors do consider the constraint that each KEM must be different in a such way that parameters are not considered at all. I.e., even if you propose McEliece with multiple parameter sets, implementation will check its policy whether McEliece is acceptable, and if so then pick one of the parameter sets that match their security needs, and do not consider McEliece anymore for later rounds, i.e., it would not allow multiple McEliece with different parameter sets, because draft says you do not do same KEM multiple times. > Thus, while we > should already thoroughly asses and mitigate the risk of this > possible weakness for > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, > we definitely must do it for > https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/. Actually I do not think it belongs to them, it belongs to whatever draft that defines McEliece to be used with those two. Tha draft should note that there are issues using large keys in IKEv2, and most likely it should say SHOULD NOT do that using IKE_INTERMEDIATE, and only use the large keys after the IKE SA has been authenticated. > Currently, there is no place defined where a McEliece-sized key > exchange can take place. So, at least one of the two drafts > (probably beyond-64k or multiple-ke) or better both should make this > clear. At the moment, beyond-64k defines how the transmission of > such key exchanges could look like but the question of where these > ideas could be put into action are left to the reader, leading to > inevitable confusion. The fact that there are several drafts aiming > at the same problem, without really defining their contact points or > interactions, further exacerbates this. We do not have draft at all for McEliece where this kind of discussion belongs. > The most obvious way to prevent an attacker from exploiting the new > attack surface is to accept the larger key exchanges only from an > already authenticated peer. As mentioned before, we think childless > IKEv2 with immediate rekeying would be a good compromise to achieve > that. McEliece draft should most likely have strong recommendation to do just that. > The introduction of new Transform-IDs like SNTRUP761X25519 is a good > short-term solution, as it addresses the problem without requiring > much effort in terms of standardization or implementation. I think IKE_INTERMEDIATE is better solution, and you doing normal X25519 in IKE_SA_INIT and then SNTRUP761 in IKE_INTERMEDIATE will solve the issue with just one extra round trip, and still keep the IKE_SA_INIT packet small enough that it does not get fragmented (i.e., less than 1280). > This becomes even more important, as intermediate exchanges and > their high complexity, due to their interconnectedness with > authentication, mean that especially the IKEv2 implementations of > smaller projects will take their time for its integration. Thus, > having an easier short-term solution at hand means a real advantage. I do not think implementing IKE_INTERMEDIATE is that hard, especially if you limit yourself to just very limited subset of algorithms you support. > Also, the constrained size of such transforms mostly eliminates the > aforementioned DoS risks. I do not think there are any new DoS risks, so there is no need to eliminate them.... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
