Subject: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01

From: Timothy Carlin <[email-masked]>
Date: Wed, 11 Jan 2017 17:26:16 -0500

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 Jan 2017 15:02:40 +0200

Timothy Carlin writes:
> 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)?

Yes, I think this is inconsistancy caused by last edits, i.e., when we
changed the 256-bit keys to MUST, we only edited the footnote, and
missed the text in section 4.

So correct change is:

OLD:

		In that sense 256 bit keys
   status has been raised from MAY in RFC7321 to SHOULD.

NEW:

		In that sense 256 bit keys
   status has been raised from MAY in RFC7321 to MUST.

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

No. It is MAY level algorithm, just like the AUTH_AES_128_GMAC and
AUTH_AES_256_GMAC algorithms. The reason those AUTH_AES_{128,256}_GMAC
algorithms are listed here is, that they used to be SHOULD+, and are
now downgraded to MAY.

The ENCR_NULL_AUTH_AES_GMAC has been MAY, and will be MAY, so it is
not mentioned in the section 4.

Your text edits seemed to be fine.
-- 
[email-masked]

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 30 Jan 2017 20:54:50 +0000

>From what I can tell, addressing this feedback is the only thing that needs to be done before progressing this draft to the IESG for publication.

Tim,

Did Tero's response address your concerns?

Tero,

Are you or the other authors planning to post an update based on this feedback?

Thanks,
Dave

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Tero Kivinen
> Sent: Thursday, January 12, 2017 8:03 AM
> To: Timothy Carlin <[email-masked]>
> Cc: [email-masked]
> Subject: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01
> 
> Timothy Carlin writes:
> > My comments:
> >
> > 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)?
> 
> Yes, I think this is inconsistancy caused by last edits, i.e., when we changed
> the 256-bit keys to MUST, we only edited the footnote, and missed the text
> in section 4.
> 
> So correct change is:
> 
> OLD:
> 
> referenced
> AUTH_AES_256_GMAC algorithms. The reason those
> AUTH_AES_{128,256}_GMAC algorithms are listed here is, that they used to
> be SHOULD+, and are now downgraded to MAY.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Timothy Carlin <[email-masked]>
Date: Mon, 30 Jan 2017 16:04:53 -0500

Hi Dave,

Yes, I believe they have been addressed.  Thanks for checking in, my
apologies for not confirming sooner.

Best Regards,
Tim Carlin

On Mon, Jan 30, 2017 at 3:54 PM, Waltermire, David A. (Fed) <
[email-masked]> wrote:

> >From what I can tell, addressing this feedback is the only thing that
> needs to be done before progressing this draft to the IESG for publication.
>
> Tim,
>
> changed

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 30 Jan 2017 21:33:51 +0000

Not a problem. Thanks for the feedback!

Dave

From: Timothy Carlin [mailto:[email-masked]]
Sent: Monday, January 30, 2017 4:05 PM
To: Waltermire, David A. (Fed) <[email-masked]>
Cc: Tero Kivinen <[email-masked]>; [email-masked]
Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01

Hi Dave,

Yes, I believe they have been addressed.  Thanks for checking in, my apologies for not confirming sooner.

Best Regards,
Tim Carlin

Tim,

Tero,

Thanks,
Dave

> From: IPsec [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tero Kivinen
> To: Timothy Carlin <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec