Subject: [saag] Fwd: [oss-security] Re: CVE Request: IKEv1 protocol is vulnerable to DoS amplification attack

From: Jeffrey Walton <[email-masked]>
Date: Tue, 18 Oct 2016 23:03:28 -0400

FYI...

---------- Forwarded message ----------
From: Kurt Seifried <[email-masked]>
Date: Tue, Oct 18, 2016 at 3:19 PM
Subject: Re: [oss-security] Re: CVE Request: IKEv1 protocol is
vulnerable to DoS amplification attack
To: oss-security <[email-masked]>
Cc: Huzaifa Sidhpurwala <[email-masked]>, CVE ID Requests
<[email-masked]>

On Tue, Jul 12, 2016 at 1:46 PM, Paul Wouters <[email-masked]> wrote:
>
> I have tested openswan and strongswan and confirmed it contains the same
> amplification that is inherent in being IKEv1 compliant.
>
> Neither implementation has applied the hardening that libreswan has
> applied for this that was the original information that caused
> CVE-2016-5361 to be issued for libreswan.
>
> I believe MITRE needs to fix the inconsistency in the issuance of
> CVE-2016-5361, expand it to be about the IKEv1 protocol, and gather
> the other vendor information and patches, or issue additional vendor
> specific CVE's. I believe the first solution is better.
>

So I had a chance to talk to Paul

Basically: the RFC doesn't define a specific way to handle this, as such a
CVE cannot be given to the RFC (currently CVEs will be given to
RFCs/protocols that say "do something bad" like using weak encryption
algorithms).

As such it was left up to all the IKE implementations themselves to
determine what to do with respect to retransmits.

I think it's safe to say an amplification of 1:10 or more qualifies as a
problem, I'm not sure what the exact amplification ratio to qualify for a
CVE is (1:3, 1:7?) but I think 1:10 or more should definitely qualify.

Thus a lot of other IKE implementations will be needing CVEs for this class
of problem (as well as other protocols).