Daniel Herzinger writes: > 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.
Not really. There are several different attacks here and we have different protection against each of them. Firstly Diffie-Hellman, Intermediate exchanges etc are not really meant for DoS protection. For DoS protection we have cookies, puzzles (RFC8019), and the fact that that we know the source IP-address of the attacker (as cookies forces them to do full round trip before they can do anything else), and as we know the IP-address(es) we can force puzzles for all unknown IP-addresses, i.e. anything we have not seen before, and that will make attackers work much harder. We might allow anybody connecting from the known IP-addresses without puzzles, just use cookies to force full round trip, but do puzzles for everybody else. This does not depend at all whether the attacker has quantum computer or not (hmm... not sure if our puzzles are faster to calculate on quantum computer than on normal computer, but at least forcing attacker to use his quantum computer just to solve our puzzles, might be a win). Secondly only authentication type now which is really protected against quantum computers is the PPK (RFC8784), i.e., post-quantum preshared keys with strong and random shared secrets. Signatures etc can be attacked using quantum computer by find out the private key for them. This might change in the future, but I think that will happen in general PKIX / X.509 area, i.e., when the certificates can use methods that are quantum computer safe, we should be able to use them with just generic signature authentication method (RFC7427). So now we do IKE_INIT and have Diffie-Hellman done there and attacker does not even need to have Quantum computer to do attack that as on path attacker can simply do non-cryptographic attack to stay in the middle, and see all the traffic going through. This Diffie-Hellman and all following quantum safe key exchange methods are still unauthenticated ones. This means that attacker can force as to do those expensive KE methods. On the other hand this do require on path attacker, who can also simply wait for the real initiator to do everything and then simply block all messages to IKE SA going through the path, thus severing the IKEv2 connection, can causing reconnection. It can do that always and there is nothing we can do for that, no quantum computer needed... And blocking few packets is cheaper than attacking Diffie-Hellman or even acting as an attacker in the middle. If you want to protect against doing those quantum safe algorithms with attacker, you simply do normal childless IKEv2 with just traditional Diffie-Hellman and use PPK to make sure there is no attacker in the middle, and after that finishes you rekey that IKEv2 and then do the expensive operations only then. This should give you full protection of the REKEYed IKEv2 SA, if I have understood the protocol correctly. > 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 does not protect at all against the active on path attacker as it does not even need to use quantum computer to be able to do that attack, it simply acts in the middle doing separate connections, one for the initiator, and another for the responder, and then passes messages through after decrypting and reencrypting them. If it has already broken the private key used in the signature to authenticate the peers, it can successfully stay there after the authentication (unless PPK was used too). > 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. It does not affect the state machine, but it does affect the crypto calculations which has quite big impact on the protocol. On the other hand as this is just new Key Exchange algorithm, there is actually no need to change IKEv2 at all, as long as that new KE simply generates one shared secret (g^ir) that can be used on both ends, i.e., the combining of the separate secrets happens inside the key exchange algorithm not in the IKEv2 protocol. I myself think this is wasted effort, as it does not provide us any protection against active attackers (except that attacker need to implement that new algorithm too :-), and doing those algorithms as separate steps is easier and more modularized. > 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. Restricting algorithms is completely up to the policy you use. Even when using IKE_INTERMEDIATE exchange you can do so that you first do classical Diffie-Hellman, then do cheap quantum safe algorithm (like the sntruprime761 you mentioned) and then do the authentication in the IKE_AUTH using PPK, and after that do IKE SA rekey and during that you do the more expensive methods that were not allowed by policy earlier.. > 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. I do not think G-IKEv2 needs to exchange any sensitive information during the GSA_AUTH. In the GSA_AUTH SAg is optional, GSA, and KD are optional, only think that is mandatory is the IDg, which is identical to IDi, and IDr, i.e., indicates identity. We might want to make sure GSA_AUTH can use PPK as described in the RFC8784, i.e., mention N(USE_PPK) for IKE_SA_INIT and add optional N(PPK_IDENTITY, PPK_ID) to GSA_AUTH. We have already talked earlier that if we want to have proper identity protection against all attackers we need to use pseudonym method, i.e., the IDi (and IDg) would be pseudonym for the device, not the real identity. Then the IKEv2 does IKE SA rekey to create channel which is protected against all attackers when using PPK, and after that it can do pseudonym maintenance. In the simplist case the server simply sends client few dozen one use random unique pseudonyms that the client can use next time it connects over that channel. And next time when it connects the server updates new pseudonyms for future use etc. Also I think G-IKEv2 is written in a way where it should allow IKE_INTERMEDIATE exchanges between the IKE_SA_INIT and GSA_AUTH, but I have not verified whether there is something still missing there. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
