Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt

From: Dan Harkins <[email-masked]>
Date: Wed, 05 May 2021 20:08:35 -0700

Paul,

   Thanks for doing this. A few comments:

   - the first two bullet points in section 3 are basically speculation,
     "a number of..." is meaningless. These bullet points are ultimately
     not even necessary to make the case being made. Delete these, please.

   - fourth bullet in section 3 should be rewritten. The "Often, IKEv1..."
     sentence should be removed but the remainder is a decent point. IKEv1
     was standardized before modern ciphers were designed, to get support
     for modern, accepted ciphers use IKEv2.

   - there is another IKEv1 feature not available in IKEv2: a deniable
     authentication method. IKEv1 had a very cool deniable exchange
     involving encrypted nonces. IKEv2 decided to not support that for
     whatever reason. Lack of support for a cool and usefu authentication
     method doesn't really make the case to send IKEv1 to historic, but
     then, oh well. As an aside, I suggested a way to add an exchange
     such an exchange using HPKE [1]. Not that I'm saying this needs to
     be added to IKEv2, but if you're gonna talk about IKEv1 features
     missing in IKEv2 you should be complete.

Other than that, good work.

   regards,

   Dan.

[1] https://mailarchive.ietf.org/arch/msg/cfrg/zjQLxV2u1wUZMFraDuy6KRPIaqU/

On 4/28/21 8:48 AM, Paul Wouters wrote:
> On Wed, 28 Apr 2021, [email-masked] wrote:
>
>> Subject: [IPsec] I-D Action: 
>> draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt
>
> Looks like the datatracker email does not post the diff between
> different document names :P
>
> The diff is:
>
> https://tools.ietf.org/rfcdiff?url1=draft-pwouters-ikev1-ipsec-graveyard-06.txt&url2=https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt 
>
>
> Basically, it removes the IANA request to close the IKEv1 registries,
> changes draft name / title to avoid "graveyard" and lists some items
> as bullet points and sections, and changes some subjective wording to
> more objective language.
>
> I'm not saying this is ready for WGLC, but ....
>
> Paul
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 May 2021 15:21:53 -0400 (EDT)

>     not even necessary to make the case being made. Delete these, please.

I have heard from vendors, so I don't think this is speculation.

I think it is important to get these points across. Especially the
second bullet point, as people might think IKEv1 is still being
supported because their devices are still seeing regular updates,
without realizing that the IKEv1 code on those devices in fact will
not receive any further updates.

>     for modern, accepted ciphers use IKEv2.

How about:

OLD:

   *  IKEv1 systems most likely do not support modern cryptographic
       algorithms.  AES-GCM is only defined for ESP and not IKE, and
       often not implemented for ESP.  And CHACHA20_POLY1305 is not
       defined for IKEv1.  Often, IKEv1 is configured with the very weak
       Diffie-Hellman Groups 2 and 5 and some implementatipons do not
       support any stronger alternatives.
NEW:

    * The IKEv1 protocol pre-dates modern cryptographic algorithms. While
      a limited number of more modern cryptographic algorithms were added
      to the IKEv1 specification, interoperability concerns means that the defacto
      algorithms deployed for IKEv1, AES-CBC, SHA1, DH2 and DH5, are no longer
      recommended and a migration to IKEv2 is the best method to deploy
      modern cryptographic algorithms with the IKE and IPsec protocols.

Or if you have an altnerative proposal, I'm happy to hear it.

>     method doesn't really make the case to send IKEv1 to historic

Can you clarify this a bit further for me? Is this deniable
authentication method part of all IKEv1 auth methods? Or is this a
specific feature that needed to be specifically enabled?

That said, if the WG deemed this feature no longer required when
specifying IKEv2, then I do not think we need to mention this here when
we are talking about motivations for people to move from IKEv1 to IKEv2.

If there is a good reason and people are prevented from upgrading to
IKEv2 because of this, I would be expecting an IKEv2 draft to be
developed to address this shortcoming. But it seems to me (I wasn't here
when these decisions were made) that the WG did not think this issue was
a concern ?

>     missing in IKEv2 you should be complete.

I was mostly listing the features in IKEv1 that were missing in IKEv2
that actually were motivations for certain people to not upgrade to
IKEv2. It is surely not meant as a list of IKEv1 vs IKEv2 features.

> Other than that, good work.

Thanks.

Paul

---

From: Dan Harkins <[email-masked]>
Date: Thu, 06 May 2021 17:04:59 -0700

> I have heard from vendors, so I don't think this is speculation.

   I don't doubt that such vendors exist but the wording sounds very
speculative, "a number of IKEv1 systems...will never be patched."
It begs the question, who? which ones? and I don't think we need to
get into specifics like that.

> not receive any further updates.

   OK, for the second one how about if it's rewritten to say:

"* IKEv1 development ceased over a decade ago and no new work will
    happen. This poses the risk of unmaintained code in an otherwise
    supported product which can result in security vulnerabilities."

That way it's not talking about "a number of vendors" but still
gets the point across that dead code is not good.

> Or if you have an altnerative proposal, I'm happy to hear it.

   That's much better but its a bit tortured. How about:

    "* Great strides have been made in cryptography since IKEv1 development
       ceased. While some modern cryptographic algorithms were added to
       IKEv1, interoperability concerns mean that the defacto algorithms
       negotiated by IKEv1 will consist of dated or deprecated algorithms
       like AES-CBC, SHA1, and Diffie-Hellman groups 2 and 5. IKEv2 provides
       state-of-the-art suite of cryptographic algorithms that IKEv1 lacks."

Or maybe just make the whole bullet point be the last sentence. All that
needs to be said is that "IKEv2 provides state-of-the-art cryptographic
algorithms that IKEv1 lacks." That's the reason right there.

> specific feature that needed to be specifically enabled?

   It was one of the authentication methods: PSK, certs, encrypted
nonces. The encrypted nonce method was completely deniable. Honest
participants would get strong authentication but they could prove
to a court-of-law that the whole exchange could be fabricated by a
third party and deny ever taking part in it.

> when these decisions were made) that the WG did not think this issue was

   I walked away from the WG after I produced -02 of the draft that became
IKEv2 so I have no idea what the was thinking after April of 2002 (nearly
two decades! Yikes). There were a number of decisions that the WG made that
looking back were odd. This is just one of them. Deniability is a valuable
property and I don't know why it was ditched.

> IKEv2. It is surely not meant as a list of IKEv1 vs IKEv2 features.

   OK, well I'm not aware of anyone pining for that IKEv1 authentication
method, or using that as an excuse to not upgrade to IKEv2, so maybe
forget it.

   regards,

   Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 9 May 2021 14:21:32 +0300

> third party and deny ever taking part in it.

The draft-ietf-ipsec-ikev2-00.txt draft only included digital
signatures, -01 version added shared secret authentication, but
encrypted rsa was never even considered for IKEv2, i.e., it was never
explcitly removed, it was simply never taken in to the IKEv2.

If I remember correctly (this discussion happened around year 2002 or
so) the reason was that there were no requirement for it. While there
were IKEv1 implementations which supported authentication with public
key encryption mode, not all implementations had it. Also support for
the revised method of authentication with public key encryption was
even less common. Also VPN and remote access people did not consider
benefits from the authentication with public key encryption mode
useful for them.

Having two different keys, one for signing and one for encryption, for
authentication was considered complicated, and reusing same key for
both signing and for encryption was considered bad idea.

And also I think shared key authentication also offeres exactly same
benefits than authentication with public key encryption for the
deniability point of view (i.e., either end can calculate everything
as long as they know the shared secret).

> property and I don't know why it was ditched.

It was not ditched, it was never included. I.e. the public key
encryption was not in the -00 version. Shared secret (which provide
deniability) was added in version -01.
-- 
[email-masked]

---

From: Dan Harkins <[email-masked]>
Date: Mon, 10 May 2021 08:02:53 -0700

Hi Tero,

   Thanks for the clarification. I don't want to resurrect the idea
here but I feel compelled to respond to this:

> as long as they know the shared secret).

   With public key encryption, anyone is able to construct what looks
like a valid IKE conversation between any two participants by using
publicly available information (i.e. their certificates). For that
capability to be done with shared key authentication it would require
the shared key used for "authentication" to be known by everyone, which
sort of voids the whole security of the protocol.

   Basically, the shared key authentication mode would only be the
equivalent of public key encryption authentication mode when using
the Pre-shared Key for the Internet [1], which was an April Fools draft
and (I think this bears repeating these days) was not intended to be
taken seriously.

   regards,

   Dan.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-ipsec-internet-key