Subject: [IPsec] draft-ietf-ipsecme-qr-ikev2-00 complexity

From: Paul Wouters <[email-masked]>
Date: Mon, 30 Oct 2017 03:42:43 -0400 (EDT)

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 30 Oct 2017 11:29:28 +0300

Hi Paul,

> attacker in this scenario of course has a quantum computer to

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

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.

> 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.

> 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

I think this is a pure implementation problem.  Get rid of IKEv1 :-)

> gateway first and then there is no issue.

What about full mesh?

> draft now brings in. I would really like to go back to something

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.