draft-ietf-ipsecme-rfc7321bis-05.txt   draft-ietf-ipsecme-rfc7321bis-06.txt 
Network Working Group D. Migault Network Working Group P. Wouters
Internet-Draft J. Mattsson Internet-Draft Red Hat
Obsoletes: 7321 (if approved) Ericsson Obsoletes: 7321 (if approved) D. Migault
Intended status: Standards Track P. Wouters Intended status: Standards Track J. Mattsson
Expires: August 31, 2017 Red Hat Expires: December 21, 2017 Ericsson
Y. Nir Y. Nir
Check Point Check Point
T. Kivinen T. Kivinen
INSIDE Secure INSIDE Secure
February 27, 2017 June 19, 2017
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-ietf-ipsecme-rfc7321bis-05 draft-ietf-ipsecme-rfc7321bis-06
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.
only.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 31, 2017. This Internet-Draft will expire on December 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 26 skipping to change at page 5, line 26
some point that this algorithm will no longer be a MUST in some point that this algorithm will no longer be a MUST in
a future document. Although its status will be determined a future document. Although its status will be determined
at a later time, it is reasonable to expect that if a at a later time, it is reasonable to expect that if a
future revision of a document alters the status of a MUST- future revision of a document alters the status of a MUST-
algorithm, it will remain at least a SHOULD or a SHOULD- algorithm, it will remain at least a SHOULD or a SHOULD-
level. level.
IoT stands for Internet of Things. IoT stands for Internet of Things.
3. Manual Keying 3. Manual Keying
Manual Keying is not to be used as it is inherently dangerous. Manual Keying SHOULD NOT be used as it is inherently dangerous.
Without any keying protocol, it does not offer Perfect Forward Without any secure keying protocol such a IKE, IPsec does not offer
Secrecy ("PFS") protection. Deployments tend to never be Perfect Forward Secrecy ("PFS") protection and there is no entity to
reconfigured with fresh session keys. It also fails to scale and ensure refreshing of session keys, tracking SPI uniqueness and
keeping SPI's unique amongst many servers is impractical. This ensuring nonces, IVs and counters are never re-used. This document
document was written for deploying ESP/AH using IKE ([RFC7296]) and was written for deploying ESP/AH using IKE ([RFC7296]) and assumes
assumes that keying happens using IKEv2. that keying happens using IKE version 2 or higher.
If manual keying is used anyway, ENCR_AES_CBC MUST be used, and If Manual Keying is used regardless, Counter Mode algorithms such as
ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305
used as these algorithms require IKE. MUST NOT be used as it is incompatible with a secure and persistent
handling of the counter, as explained in the Security Considerations
Section of [RFC3686]. This particularly applies to IoT devices that
have no state across reboots. As of publication date of this
document, ENCR_AES_CBC is the only Mandatory-To-Implement encryption
algorithm suitable for Manual Keying.
4. Encryption must be Authenticated 4. Encryption must be Authenticated
Encryption without authentication is not effective and MUST NOT be Encryption without authentication is not effective and MUST NOT be
used. IPsec offers three ways to provide both encryption and used. IPsec offers three ways to provide both encryption and
authentication: authentication:
o ESP with an AEAD cipher o ESP with an AEAD cipher
o ESP with a non-AEAD cipher + authentication o ESP with a non-AEAD cipher + authentication
o ESP with a non-AEAD cipher + AH with authentication o ESP with a non-AEAD cipher + AH with authentication
skipping to change at page 8, line 39 skipping to change at page 8, line 42
| | | (IoT) | | | | (IoT) |
| AUTH_AES_128_GMAC | MAY | [RFC4543] | | AUTH_AES_128_GMAC | MAY | [RFC4543] |
| AUTH_AES_256_GMAC | MAY | [RFC4543] | | AUTH_AES_256_GMAC | MAY | [RFC4543] |
| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | | AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |
| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] | | AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |
+------------------------+------------------+-----------------------+ +------------------------+------------------+-----------------------+
(IoT) - This requirement is for interoperability with IoT (IoT) - This requirement is for interoperability with IoT
AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The
only reason NULL is acceptable is when authenticated encryption only case where AUTH_NONE is acceptable is when authenticated
algorithms are selected from Section 5. In all other cases, NULL encryption algorithms are selected from Section 5. In all other
MUST NOT be selected. As ESP and AH both provide authentication, one cases, AUTH_NONE MUST NOT be selected. As ESP and AH both provide
may be tempted to combine these protocols to provide authentication. authentication, one may be tempted to combine these protocols to
As mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL provide authentication. As mentioned by RFC7321, it is NOT
authentication - with non authenticated encryption - in conjunction RECOMMENDED to use ESP with NULL authentication - with non
with AH; some configurations of this combination of services have authenticated encryption - in conjunction with AH; some
been shown to be insecure [PD10]. In addition, NULL authentication configurations of this combination of services have been shown to be
cannot be combined with ESP NULL encryption. insecure [PD10]. In addition, AUTH_NONE authentication cannot be
combined with ESP NULL encryption.
AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As
MD5 is known to be vulnerable to collisions, these algorithms MUST MD5 is known to be vulnerable to collisions, these algorithms MUST
NOT be used. NOT be used.
AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC7321 to MUST- AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC7321 to MUST-
as there is an industry-wide trend to deprecate its usage. as there is an industry-wide trend to deprecate its usage.
AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be AUTH_DES_MAC was not mentioned in RFC7321. As DES is known to be
vulnerable, it MUST NOT be used. vulnerable, it MUST NOT be used.
skipping to change at page 12, line 35 skipping to change at page 12, line 39
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566, and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566,
September 2003, <http://www.rfc-editor.org/info/rfc3566>. September 2003, <http://www.rfc-editor.org/info/rfc3566>.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, Algorithm and Its Use with IPsec", RFC 3602,
DOI 10.17487/RFC3602, September 2003, DOI 10.17487/RFC3602, September 2003,
<http://www.rfc-editor.org/info/rfc3602>. <http://www.rfc-editor.org/info/rfc3602>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
<http://www.rfc-editor.org/info/rfc3686>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", (GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, DOI 10.17487/RFC4106, June 2005, RFC 4106, DOI 10.17487/RFC4106, June 2005,
<http://www.rfc-editor.org/info/rfc4106>. <http://www.rfc-editor.org/info/rfc4106>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, DOI 10.17487/RFC4309, December 2005, RFC 4309, DOI 10.17487/RFC4309, December 2005,
<http://www.rfc-editor.org/info/rfc4309>. <http://www.rfc-editor.org/info/rfc4309>.
skipping to change at page 13, line 22 skipping to change at page 13, line 27
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the [RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the
Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,
DOI 10.17487/RFC7634, August 2015, DOI 10.17487/RFC7634, August 2015,
<http://www.rfc-editor.org/info/rfc7634>. <http://www.rfc-editor.org/info/rfc7634>.
Authors' Addresses Authors' Addresses
Paul Wouters
Red Hat
Email: pwouters@redhat.com
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8400 boulevard Decarie
Montreal, QC H4P 2N2 Montreal, QC H4P 2N2
Canada Canada
Phone: +1 514-452-2160 Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com Email: daniel.migault@ericsson.com
John Mattsson John Mattsson
Ericsson AB Ericsson AB
SE-164 80 Stockholm SE-164 80 Stockholm
Sweden Sweden
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Paul Wouters
Red Hat
Email: pwouters@redhat.com
Yoav Nir Yoav Nir
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim st. 5 Hasolelim st.
Tel Aviv 6789735 Tel Aviv 6789735
Israel Israel
Email: ynir.ietf@gmail.com Email: ynir.ietf@gmail.com
Tero Kivinen Tero Kivinen
INSIDE Secure INSIDE Secure
Eerikinkatu 28 Eerikinkatu 28
HELSINKI FI-00180 HELSINKI FI-00180
FI FI
Email: kivinen@iki.fi Email: kivinen@iki.fi
 End of changes. 12 change blocks. 
35 lines changed or deleted 45 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/