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.
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. 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. ** 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. ** 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. ** 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? +------------------------+----------+---------+ | 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 | | ** 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 ... ** Section 3. A number of IKEv1 systems have reached their End of Life Is there a way to quantify that or support that claim? ** Section 3. Please provide a reference for CVE-2016-5361. ** 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." ** 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"? ** Section 7. All entries not mentioned here should receive no value in the new Status field. Did the WG discuss a non-empty value? Thanks, Roman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
