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

[Dan Harkins <[e-mail]>]

On 5/6/21 12:21 PM, Paul Wouters wrote:
> 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 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.

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

   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.

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

   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.

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

   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.

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

   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.

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

   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.

>> Other than that, good work.
>
> Thanks.

   regards,

   Dan.

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