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 :)
We also need to keep around two sets of SK_* payloads, which is
also pretty ugly.
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?
My concerns is that we might be making it too complicated by potentially
introducing two separate SK_p's.
From an ops perspective, if we stated the rule that when we want to go
postquantum a PPK should be
populated on the responder first as Graham and others suggested, then the extra
complication of a new
notification can be avoided. Violation of that rule would lead to IKE_AUTH
failure for that initiator only.
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, 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 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.
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.
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.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
