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

[Paul Wouters <[e-mail]>]

On Wed, 5 May 2021, Dan Harkins wrote:

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

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.

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

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.

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

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 ?

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

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