draft-mglt-ipsecme-rfc7321bis-02.txt   draft-mglt-ipsecme-rfc7321bis-03.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Intended status: Standards Track P. Wouters Intended status: Standards Track P. Wouters
Expires: March 5, 2017 Red Hat Expires: March 5, 2017 Red Hat
Y. Nir Y. Nir
Check Point Check Point
T. Kivinen T. Kivinen
INSIDE Secure INSIDE Secure
September 1, 2016 September 1, 2016
Cryptographic Algorithm Implementation Requirements and Usage Guidance Cryptographic Algorithm Implementation Requirements and Usage Guidance
for Encapsulating Security Payload (ESP) and Authentication Header (AH) for Encapsulating Security Payload (ESP) and Authentication Header (AH)
draft-mglt-ipsecme-rfc7321bis-02 draft-mglt-ipsecme-rfc7321bis-03
Abstract Abstract
This document updates the Cryptographic Algorithm Implementation This document updates the Cryptographic Algorithm Implementation
Requirements for ESP and AH. The goal of these document is to enable Requirements for ESP and AH. The goal of these document is to enable
ESP and AH to benefit from cryptography that is up to date while ESP and AH to benefit from cryptography that is up to date while
making IPsec interoperable. making IPsec interoperable.
This document obsoletes RFC 7321 on the cryptographic recommendations This document obsoletes RFC 7321 on the cryptographic recommendations
only. only.
skipping to change at page 5, line 15 skipping to change at page 5, line 15
Following [RFC4835], we define some additional key words: Following [RFC4835], we define some additional key words:
MUST- This term means the same as MUST. However, we expect that at MUST- This term means the same as MUST. However, we expect that at
some point in the future this algorithm will no longer be a MUST. some point in the future this algorithm will no longer be a MUST.
SHOULD+ This term means the same as SHOULD. However, it is likely SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at some that an algorithm marked as SHOULD+ will be promoted at some
future time to be a MUST. future time to be a MUST.
3. ESP Encryption Algorithms 3. ESP Encryption Algorithms
+-------------------------+------------+--------+-------------------+ +-------------------------+------------+---------+---------------+
| Name | Status | AEAD | Comment | | Name | Status | AEAD | Comment |
+-------------------------+------------+--------+-------------------+ +-------------------------+------------+---------+---------------+
| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED | | ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED |
| ENCR_DES | MUST NOT | No | [RFC2405] | | ENCR_DES | MUST NOT | No | [RFC2405] |
| ENCR_3DES | SHOULD NOT | No | [RFC2451] | | ENCR_3DES | SHOULD NOT | No | [RFC2451] |
| ENCR_BLOWFISH | MUST NOT | No | [RFC2451] | | ENCR_BLOWFISH | MUST NOT | No | [RFC2451] |
| ENCR_3IDEA | MUST NOT | No | UNSPECIFIED | | ENCR_3IDEA | MUST NOT | No | UNSPECIFIED |
| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED | | ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED |
| ENCR_NULL | MUST | No | [RFC2410] | | ENCR_NULL | MUST | No | [RFC2410] |
| ENCR_AES_CBC | MUST | No | [RFC3602][1] | | ENCR_AES_CBC | MUST | No | [RFC3602][1] |
| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309][1][IoT] | | ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309]IoT] |
| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] | | ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] | | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |
+-------------------------+------------+--------+-------------------+ +-------------------------+------------+---------+---------------+
[1] - This requirement level is for 128-bit keys. 256-bit keys are at [1] - This requirement level is for 128-bit and 256-bit keys.
SHOULD. 192-bit keys can safely be ignored. [IoT] - This 192-bit keys remain at MAY level. [IoT] - This requirement is for
requirement is for interoperability with IoT. interoperability with IoT. Only 128-bit keys are at MUST level.
192-bit and 256-bit keys are at the MAY level.
IPsec sessions may have very long life time, and carry multiple 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. 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 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 keys are at SHOULD (when applicable). In that sense 256 bit keys
status has been raised from MAY in RFC7321 to SHOULD. status has been raised from MAY in RFC7321 to SHOULD.
IANA has allocated codes for cryptographic algorithms that have not IANA has allocated codes for cryptographic algorithms that have not
been specified by the IETF. Such algorithms are noted as been specified by the IETF. Such algorithms are noted as
UNSPECIFIED. Usually, the use of theses algorithms is limited to UNSPECIFIED. Usually, the use of theses algorithms is limited to
 End of changes. 3 change blocks. 
19 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/