Hi Paul, > 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 :)
My guess is that if strong crypto primitives are used, then this attack is infeasible, but I definitely let more competent in cryptography people comment on this. > We also need to keep around two sets of SK_* payloads, which is > also pretty ugly. I guess by SK_* payloads you mean SK_* keys? Yes, this extension has its cost (and you forgot to mention that the initiator needs to compute AUTH content twice, that is costly). However, it is optional for both initiator and responder. If initiator's policy is strict and it is OK for him/her to fail communication in case the responder is not (yet) configured with proper PPK, then he/she won't use this extension. However, in a transient period, when not all hosts in the network are configured with proper PPKs, this extension allows the network to continue operate without disruption. > Second, since the PPK notify is in the IKE_INIT, couldn't an > attack perform a downgrade attack by stripping this out of > the IKE_INIT before forwarding the packet? Surely, if she can forge the AUTH payload in real time (since IKE_SA_INIT is authenticated). So basically you need QC for that. And this attack is mentioned in the Security Considerations. > > In general I think that if protocol allows more flexible operational > > conditions, then it is a good thing. > > I am not sure. For example, libreswan allows configurations to be > IKEv1only, IKEv2only, or Either. This causes us a lot of weird code > now, eg when someone configures MOBIKE or AES_GCM for IKE, both of > which are not valid for IKEv1 but are for IKEv2. Also, almost > no one else implemented this v1 to v2 migration support, We did :-) Those things in our configuration that are not valid for IKEv1 are just sorted out when it is used. > and required > administrators to configure two separate connections for these two > cases during the migration. We are now in the process of removing this > support to make our code a lot simpler again. I think this is a pure implementation problem. Get rid of IKEv1 :-) > 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. > Gateways on dynamic IPs is basically the same use case as the > access vpn clients described above - you must update the responding > gateway first and then there is no issue. What about full mesh? > In summary, I'm not convinced we need as much complexity as the > draft now brings in. I would really like to go back to something > simpler. This feature is optional. You are not required to implement it. However, if implemented, it allows the transient period to go more smoothly in some use cases. > Paul Regards, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
