> -----Original Message----- > From: Paul Wouters [mailto:p...@nohats.ca] > Sent: Monday, October 30, 2017 3:43 AM > To: Valery Smyslov <sva...@gmail.com> > Cc: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; Scott Fluhrer > (sfluhrer) <sfluh...@cisco.com>; ipsec@ietf.org; 'Vukasin Karadzic' > <vukasin.karad...@gmail.com> > Subject: draft-ietf-ipsecme-qr-ikev2-00 complexity > > On Wed, 23 Aug 2017, Valery Smyslov wrote: > > >> It is a good idea. A new optional notification that includes the > >> auth_data as it would be calculated without the PPK would work. With > >> that, the corner case of ' PPK_id configured on initiator but missing > >> on the responder' is addressed. There is an additional cost of the extra > notification message for every initiator that has no- mandatory ppk > configured for the responder. > > > > Yes, and there is also an extra cost for initiator of performing AUTH > > calculation (e.g. digital signature) twice - one with SK_p' and the > > other with SK_p. Good news are is that it is > > a) is performed by initiator only, so there is no risk of DoS attack > > on responder > > b) is needed only if initiator is configured in "permissive" mode - when its > policy allows both PPK and non-PPK > > SAs with the particular responder > > I've seen this in the -04 draft, and I'm not sure I like it. > > What attacks are we opening up by providing two AUTH payloads to a MITM > attacker? When they receive AUTH payloads with and without PPK, can they > use this as an oracle for the PPK somehow? The attacker in this scenario of > course has a quantum computer to perform the attack :)
If the attacker can enumerate the possible values of the PPK (possibly using Grover's algorithm), such attacks are already possible. For example, if the attacker acts as the responder, then he sees the PPK-influenced AUTH payload, which is a function of the PPK and data which the attacker knows. Hence, if the attacker can enumerate the possible PPK values, he can compute what the AUTH payload would be for each PPK, and thus deduce which is the correct one. And, yes, Grover's algorithm can be used for this search. Because of this, we recommend that the PPK have a minentropy of 256 bits; this prevents this attack, and other oracle attacks which you elude to. > > I think that PPK can be handled with seperate configurations as well. > > > Note also that the use case for this feature is very limited. For access VPNs > you would have the responder work with or without PPK, and it can just > respond to non-updated initiators without PPK and to updated initiators with > PPK. Initiators only need to have one configuration and stick to it. The only > use case is a set of gateways, for example for site-to-site connections, where > some gateways are updated and others are not. Due to PPK support signaling > being in the IKE_INIT packet, the gateway cannot know whether or not it > should use PPK or not. But in the real world, almost all those kind of > gateways are on static IPs, and the responding gateway can actually know for > which configuration the IKE_INIT packet is. This is often not true in my experience; sometimes, the responding gateway does not have preexisting configuration for every initiator it might be able to handle. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
