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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
