Re: [IPsec] AD review of draft-ietf-ipsecme-ikev1-algo-to-historic-06

[Paul Wouters <[e-mail]>]

On Fri, Jul 15, 2022 at 6:06 PM Roman Danyliw <[e-mail]> wrote:

> Hi!
>
> I performed an AD review of draft-ietf-ipsecme-ikev1-algo-to-historic-06.
> Thanks for this work to formally move the community to IKEv2.
>

Sorry for the late reply. I thought I answered this, but I can't find a
trace of it, so I apparently did not.



> Based on the content of this document, I am assuming the WG intent is to
> follow option #3 of
> https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/.
> Please correct me if I have it wrong.  To repeat the salient parts of the
> process here, when this document goes to IETF LC, there will be a companion
> "status change document" which also will be sent to IETF LC.  That status
> change document will move RFC207/2408/2409 to historic status.  The IESG
> will need to ballot on both.
>

I believe so yes.


> Below is my feedback.  Some of the editorial changes are to support the
> process described above.
>
> ** Abstract.  As this document is formally updating other documents,
> please state that in this section.  From idnits:
>
>   -- The draft header indicates that this document updates RFC8247, but the
>      abstract doesn't seem to mention this, which it should.
>
>   -- The draft header indicates that this document updates RFC8221, but the
>      abstract doesn't seem to mention this, which it should.
>
>
Fixed in -07. I wondered about whether it really updates 8221 and 8247,
because those RFCs don't really make a statement
on these algorithms. But as they state that non mentioned algorithms remain
at MAY, I felt more inclined to call it a real Update:
so I changed the text in the abstract to reflect this.


** Abstract.  To sync the language up with the status change document,
> please:
>
> OLD
> Internet Key Exchange version 1 (IKEv1) is deprecated.
>
> NEW
> This document formally deprecates Internet Key Exchange version 1
> (IKEv1).  Accordingly, RFC2407, RFC2408 and RFC2409 which specify IKEv1 are
> moved to Historic status.
>

It is not "this document" that deprecates it to historic but the
independent IESG action. So instead, I changed it to:

 Internet Key Exchange version 1 (IKEv1) has been deprecated and its
specification in RFC2407, RFC2408 and RFC2409 have been moved to Historic
status.



> ** The document
>
> ** Section 1.  As above.
> OLD
> IKEv1 has been moved to Historic status
>
> NEW
> This document formally deprecates Internet Key Exchange version 1
> (IKEv1).  Accordingly, RFC2407, RFC2408 and RFC2409 which specify IKEv1 is
> moved to Historic status.
>

Same reasoning as above. I just pulled the last sentence up to the first
sentence for clarification.


> ** Section 1.
>    Algorithm implementation requirements and usage guidelines for IKEv2
>    [RFC8247] and ESP/AH [RFC8221] gives guidance to implementors but
>    limits that guidance to avoid broken or weak algorithms.  It does not
>    deprecate algorithms that have aged and are not in use, but leave
>    these algorithms in a state of "MAY be used".
>
> I'm not following the text saying that "algorithms [are left] in a state
> of 'MAY be used'".  For example, the following Type 3 transforms are
> deprecated in Section 7 of this document: AUTH_HMAC_MD5_96, AUTH_DES_MAC
> and AUTH_KPDK_MD5.  However, Section 2.3 of RFC8247 seems very clear that
> AUTH_HMAC_MD5_96, AUTH_DES_MAC and AUTH_KPDK_MD5 are already "MUST NOT".
> Where is the "MAY be used" flexibility coming from?
>

In your example sub registry, there was nothing left in the state
mentioned. But if you look at:


https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev1-algo-to-historic-06#section-5

then you can see a number of them.


>               +------------------------+----------+---------+
>               | Name                   | Status   | Comment |
>               +------------------------+----------+---------+
>               | AUTH_HMAC_SHA2_256_128 | MUST     |         |
>               | AUTH_HMAC_SHA2_512_256 | SHOULD   |         |
>               | AUTH_HMAC_SHA1_96      | MUST-    |         |
>               | AUTH_AES_XCBC_96       | SHOULD   | (IoT)   |
>               | AUTH_HMAC_MD5_96       | MUST NOT |         |
>               | AUTH_DES_MAC           | MUST NOT |         |
>               | AUTH_KPDK_MD5          | MUST NOT |         |
>
>
The reason for listing the entire table is that we ask IANA for the Status
column for population, and so we give the entire table even if there were
no entries for this specific table that changed between 8221 + 8247 and
this document.



> ** Section 1.  Explicitly state the update being made to RFC8247 and
> RFC8221.
>
>




> OLD
> This document deprecates those algorithms that are no longer advised ...
>
> NEW
>
> This document deprecates those algorithms from RFC8247 and RFC8221 that
> are no longer advised ...
>

Changed to:

       These two RFCs not deprecate algorithms that
       have aged and are not in use, but leave these algorithms in
       a state of "MAY be used" by not mentioning them. This document
deprecates
       those unmentioned algorithms that are no longer advised but for which
       there are no known attacks resulting in their earlier deprecation.


> ** Section 3.
>
>    A number of IKEv1 systems have reached their End of Life
>
> Is there a way to quantify that or support that claim?
>

No. We heard from a few vendors that they had frozen their IKEv1 stacks and
no new fixes would ever make it because they did not want to fix bugs
because of a need to re-certify
(eg FIPS) their implementation. From a practical point of view, IKEv1only
systems are now at a practical EOL because the market has pushed for IKEv2
(again, via some certifications)


> ** Section 3.  Please provide a reference for CVE-2016-5361.
>

Done.

** Section 3.
>
>    IKEv1 configurations SHOULD NOT be directly
>    translated to IKEv2 configurations without updating the cryptographic
>    algorithms used
>
> It seems odd to provide normative behavior for the technology that just
> got deprecated.  Consider rephrasing it to direct IKEv2 behavior.  Perhaps,
> "IKEv2 implementations SHOULD NOT directly import IKEv1 configurations
> without updating the cryptographic algorithms used."
>

Done.


> ** Section 5.
>
>    *  Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the
>       unspecified 3IDEA, ENCR_DES_IV64 and ENCR_DES_IV32
>
>    *  PRF Algorithms: the unspecified PRF_HMAC_TIGER
>
> Is it "unspecified" or "unstandardized" or "registered"?
>

It is unspecified. It is literally an entry in the IANA registry without
any RFC or non-RFC specification anywhere.


> ** Section 7.
>    All entries not mentioned here should receive no value in the new
>    Status field.
>
> Did the WG discuss a non-empty value?
>

The only value discussed for the status colum was "DEPRECATED". The WG
specifically did not want to add a RECOMMENDED value like TLS has done.

Diff can be seen at
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev1-algo-to-historic-07.txt

Paul