Subject: [IPsec] use of IKE_AUX vs rekey of IKE Parent SA in draft-smyslov-ipsecme-ikev2-aux

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Apr 2018 17:23:16 -0400

Tero Kivinen <[email-masked]> wrote:
    > 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.

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.

This would work far better today as it would resist all sorts of resource
exhaustion attacks that we currently defend easily against.  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.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 5 Apr 2018 14:21:18 +0300

Hi Michael,

> IKEv2 already defends against today.

Please, elaborate, where do you think it fails to do this.

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

> 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

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.