Hello All,
I have reviewed this draft and have a couple of comments and small text
nits below as a diff.
The addition of Section 3 regarding Manual Keying is good for providing
guidance for compliance testing programs and ultimately to strongly
discourage its use.
My comments:
* Section 4 mentions that that 256-bit keys are raised to the SHOULD
level. Should this read as these are now the MUST level as ENCR_AES_CBC
and ENCR_AES_GCM_16 are at the MUST level according to Table 1 (with the
[1] endnote)?
* Section 5 mentions ENCR_NULL_AUTH_AES_GMAC, which is not referenced
anywhere in the document. Should it be added to Table 1 at the MUST level?
Tim Carlin
UNH-IOL
==============================================
--- draft-ietf-ipsecme-rfc7321bis-01.txt 2017-01-08 14:19:52.000000000 -0500
+++ draft-ietf-ipsecme-rfc7321bis-01-carlin-review.txt 2017-01-11
17:06:09.000000000 -0500
@@ -118,7 +118,7 @@
The field of cryptography evolves continuously. New stronger
algorithms appear and existing algorithms are found to be less secure
- then originally thought. Therefore, algorithm implementation
+ than originally thought. Therefore, algorithm implementation
requirements and usage guidance need to be updated from time to time
to reflect the new reality. The choices for algorithms must be
conservative to minimize the risk of algorithm compromise.
@@ -143,7 +143,7 @@
completely broken before this document is updated.
This document only provides recommendations for the mandatory-to-
- implement algorithms or algorithms too weak that are recommended not
+ implement algorithms and algorithms too weak that are recommended not
to be implemented. As a result, any algorithm listed at the IPsec
IANA registry not mentioned in this document MAY be implemented. As
[RFC7321] omitted most of the algorithms mentioned by the IPsec IANA
@@ -241,7 +241,7 @@
3. Manual Keying
- Manual Keying is not be used as it is inherently dangerous. Without
+ Manual Keying is not to be used as it is inherently dangerous. Without
any keying protocol, it does not offer Perfect Forward Secrecy
("PFS") protection. Deployments tend to never be reconfigured with
fresh session keys. It also fails to scale and keeping SPI's unique
@@ -269,6 +269,7 @@
| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309]IoT] |
| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |
+ | ENCR_NULL_AUTH_AES_GMAC | MUST | Yes | [RFC4543][1] |
+-------------------------+------------+---------+---------------+
@@ -291,9 +292,12 @@
IPsec sessions may have very long life time, and carry multiple
packets, so there is a need to move 256-bit keys in the long term.
- For that purpose requirement level is for 128 bit keys and 256 bit
- keys are at SHOULD (when applicable). In that sense 256 bit keys
- status has been raised from MAY in RFC7321 to SHOULD.
+ For that purpose the requirement level for 128 bit keys and 256 bit
+ keys is MUST (when applicable). In that sense 256 bit keys
+ * status has been raised from MAY in RFC7321 to MUST.
+ * [TJC Comment - ENCR_AES_CBC, ENCR_AES_GCM_16, and
ENCR_NULL_AUTH_AES_GMAC,
+ each have 128 and 256 bit key sizes at the MUST level, according to
+ Table 1 above]
IANA has allocated codes for cryptographic algorithms that have not
been specified by the IETF. Such algorithms are noted as
@@ -319,7 +323,7 @@
ENCR_BLOWFISH has been downgraded to MUST NOT as it has been
deprecated for years by TWOFISH, which is not standarized for ESP and
- therefor not listed in this document. Some implementations support
+ therefore not listed in this document. Some implementations support
TWOFISH using a private range number.
ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to
@@ -327,9 +331,9 @@
over AH due to NAT traversal. ENCR_NULL is expected to remain MUST
by protocol requirements.
- ENCR_AES_CBC status remains to MUST. ENCR_AES_CBC MUST be
+ ENCR_AES_CBC status remains as MUST. ENCR_AES_CBC MUST be
implemented in order to enable interoperability between
- implementation that followed RFC7321. However, there is a trend for
+ implementations that followed RFC7321. However, there is a trend for
@@ -402,9 +406,9 @@
AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The
only reason NULL is acceptable is when authenticated encryption
- algorithms are selected from Section 4. In all other case, NULL MUST
- NOT be selected. As ESP and AH provides both authentication, one may
- be tempted to combine these protocol to provide authentication. As
+ algorithms are selected from Section 4. In all other cases, NULL MUST
+ NOT be selected. As ESP and AH both provide authentication, one may
+ be tempted to combine these protocols to provide authentication. As
mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL
authentication - with non authenticated encryption - in conjunction
with AH; some configurations of this combination of services have
@@ -421,18 +425,20 @@
AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be
vulnerable, it MUST NOT be used.
- AUTH_AES_XCBC_96 is only recommended in the scope of IoT, as Internet
- of Things deployments tend to prefer AES based HMAC functions in
- order to avoid implementing SHA2. For the wide VPN deployment, as it
- has not been widely adopted, it has been downgraded from SHOULD to
+ AUTH_AES_XCBC_96 status is set as SHOULD only in the scope of IoT,
+ as Internet of Things deployments tend to prefer AES based HMAC
functions
+ in order to avoid implementing SHA2. For the wide VPN deployment, as it
+ has not been widely adopted, it is downgraded from SHOULD to
MAY.
AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY.
Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms
- should only be used for AH not for ESP. If using ENCR_NULL,
- AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using GMAC
- without authentication, ENCR_NULL_AUTH_AES_GMAC is recommended.
+ should only be used for AH and not for ESP. If using ENCR_NULL,
+ AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES-GMAC
+ in ESP without confidentiality, ENCR_NULL_AUTH_AES_GMAC is recommended.
Therefore, these ciphers are kept at MAY.
+ * [TJC Comment - ENCR_NULL_AUTH_AES_GMAC did not appear in this
document,
+ I added it to Table 1.]
AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, as no SHA2 based
authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
