Hi Michael, > > Michael R.: > > - doesn't seem to be generic cause of the re-key. > > - why not do a re-key after IKE_AUTH > > - As DH is broken, this approach does not seem to protect it. > > I suggested in the mic line that the use of IKE_AUX seemed to introduce more > issues than it solved. It must defend against all the various attacks which > IKEv2 already defends against today.
Please, elaborate, where do you think it fails to do this. > Instead we should do some kind of IKE_AUTH round trip (without CHILDSA) > with "classic" authentication methods, and using "classic" DH methods. > Then use RFC7383 to get the larger QM exponents across, and then do > a IKE_AUTH "rekey" to switch to the QM exponents. > > This just feels cleaner to me. I can see some issues with this approach. First, currently there is no such thing as "IKE_AUTH rekey". IKE SA rekey via CREATE_CHILD_SA doesn't perform authentication of the peers. So, you need to modify protocol to add an additional authentication exchange after IKE SA is created. This is more serious modification than introducing IKE_AUX. Then, if you perform authentication twice (first with "classic methods" and then some kind of post-authentication) then you need to have two sets of credentials for the peers, or use AUTH_NULL in the initial IKE_AUTH. The former is problematic from operation point of view (see Section 5.2 of draft-ietf-ipsecme-qr-ikev2), the latter increases vulnerability to DoS attacks (see Section 10 of RFC8019). Third, your proposal adds more round trips and require more CPU resources (to perform additional authentication). > This would work far better today as it would resist all sorts of resource > exhaustion attacks that we currently defend easily against. Not exactly, please see above. > Of course, the way that we defend against them today is by use of DH methods > and > authentication methods that might be defeated by quantum computers. > > So the question becomes: in a post-QM world, do we think that the attackers > will be able to defeat our pre-QM methods in real time and thus attack us? > If the answer is no, then I think that we can use this multi-level security > mechanism to advantage. > > If the answer is yes (they can decrypt in real time), then we need to build > all the fragmentation protections into IKE_AUX anyway. If an attacker is equipped with a QC that can break initial (EC)DH in real time, then he/she will know the keys for the IKE_AUX and thus can modify its content and send bogus packets. However, this modification will be detected in the IKE_AUTH if auth method used is QC-safe (like hash based signatures). Cryptographers tell us that PQ authentication is much more well studied than PQ key exchange and that they are pretty sure in security of such schemes. I see no reason why these schemes cannot be used even in the current IKEv2, so I presume that even if an attacker breaks initial DH in the IKE_SA_INIT, it will be detected. So, the only real benefit the attacker gets in this case is that he/she can mount DoS attack, so in this regard the IKE_AUX is no worse than performing fragmentation in the IKE_SA_INIT. Moreover, in this case your proposal will be vulnerable as well (an attacker breaks classic (EC)DH and modifies IKE_AUTH messages; if it is also breaks classic auth, then DoS attacks would be even worse than in case of IKE_AUX). And I hope that by the time the attacker can break classical (EC)DH in real time, some PQ key exchange schemes with relatively small public key would appear, so that we could replace classical (EC)DH with one of such scheme. There is no need that this scheme be super-secure (since more PQ exchanges can be done in IKE_AUX) , it's enough if it withstands breaking in real time having relatively small public key. Regards, Valery. > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
