draft-mglt-ipsecme-rfc7321bis-03.txt   draft-mglt-ipsecme-rfc7321bis-04.txt 
Network Working Group D. Migault Network Working Group D. Migault
Internet-Draft J. Mattsson Internet-Draft J. Mattsson
Obsoletes: 7321 (if approved) Ericsson Obsoletes: 7321 (if approved) Ericsson
Intended status: Standards Track P. Wouters Intended status: Standards Track P. Wouters
Expires: March 5, 2017 Red Hat Expires: March 13, 2017 Red Hat
Y. Nir Y. Nir
Check Point Check Point
T. Kivinen T. Kivinen
INSIDE Secure INSIDE Secure
September 1, 2016 September 9, 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-03 draft-mglt-ipsecme-rfc7321bis-04
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 1, line 43 skipping to change at page 1, line 43
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 March 5, 2017. This Internet-Draft will expire on March 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 26 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Updating Algorithm Implementation Requirements and Usage 1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5 3. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5
4. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7 4. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7
5. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 8 5. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Encapsulating Security Payload (ESP) [RFC4303] and the The Encapsulating Security Payload (ESP) [RFC4303] and the
Authentication Header (AH) [RFC4302] are the mechanisms for applying Authentication Header (AH) [RFC4302] are the mechanisms for applying
cryptographic protection to data being sent over an IPsec Security cryptographic protection to data being sent over an IPsec Security
Association (SA) [RFC4301]. Association (SA) [RFC4301].
This document provides guidance and recommendations so that ESP and This document provides guidance and recommendations so that ESP and
skipping to change at page 9, line 5 skipping to change at page 9, line 5
| IPCOMP_DEFLATE | MAY | [RFC2393] | | IPCOMP_DEFLATE | MAY | [RFC2393] |
| IPCOMP_LZS | MAY | [RFC2395] | | IPCOMP_LZS | MAY | [RFC2395] |
| IPCOMP_LZJH | MAY | [RFC3051] | | IPCOMP_LZJH | MAY | [RFC3051] |
+----------------+----------+-------------+ +----------------+----------+-------------+
[IoT] - This requirement is for interoperability with IoT [IoT] - This requirement is for interoperability with IoT
Compression was not mentioned in RFC7321. As it is not widely Compression was not mentioned in RFC7321. As it is not widely
deployed, it remains optional and at the MAY-level. deployed, it remains optional and at the MAY-level.
6. Acknowledgements 6. Summary of Changes from RFC 7321
The following table summarizes the changes from RFC 7321.
RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE
TABLE BELOW WITH THE NUMBER OF THIS RFC
+-------------------+----------+-----------------+
| Algorithm | RFC 7321 | RFC XXXX |
+-------------------+----------+-----------------+
| ENCR_AES_GCM_16 | SHOULD+ | MUST |
| ENCR_AES_CCM_8 | MAY | SHOULD |
| ENCR_AES_CTR | MAY | (*) |
| ENCR_3DES | MAY | SHOULD NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_128_GMAC | SHOULD+ | MAY |
| AUTH_NONE | MAY | MUST / MUST NOT |
+-------------------+----------+-----------------+
(*) This algorithm is not mentioned in the above sections, so it
defaults to MAY.
7. Acknowledgements
Some of the wording in this document was adapted from [RFC7321], the Some of the wording in this document was adapted from [RFC7321], the
document that this one obsoletes, which was written by D. McGrew and document that this one obsoletes, which was written by D. McGrew and
P. Hoffman. P. Hoffman.
7. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
8. Security Considerations 9. Security Considerations
The security of a system that uses cryptography depends on both the The security of a system that uses cryptography depends on both the
strength of the cryptographic algorithms chosen and the strength of strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on the keys used with those algorithms. The security also depends on
the engineering and administration of the protocol used by the system the engineering and administration of the protocol used by the system
to ensure that there are no non-cryptographic ways to bypass the to ensure that there are no non-cryptographic ways to bypass the
security of the overall system. security of the overall system.
This document concerns itself with the selection of cryptographic This document concerns itself with the selection of cryptographic
algorithms for the use of ESP and AH, specifically with the selection algorithms for the use of ESP and AH, specifically with the selection
skipping to change at page 9, line 31 skipping to change at page 10, line 4
to ensure that there are no non-cryptographic ways to bypass the to ensure that there are no non-cryptographic ways to bypass the
security of the overall system. security of the overall system.
This document concerns itself with the selection of cryptographic This document concerns itself with the selection of cryptographic
algorithms for the use of ESP and AH, specifically with the selection algorithms for the use of ESP and AH, specifically with the selection
of mandatory-to-implement algorithms. The algorithms identified in of mandatory-to-implement algorithms. The algorithms identified in
this document as "MUST implement" or "SHOULD implement" are not known this document as "MUST implement" or "SHOULD implement" are not known
to be broken at the current time, and cryptographic research to date to be broken at the current time, and cryptographic research to date
leads us to believe that they will likely remain secure into the leads us to believe that they will likely remain secure into the
foreseeable future. However, this is not necessarily forever. foreseeable future. However, this is not necessarily forever.
Therefore, we expect that revisions of that document will be issued Therefore, we expect that revisions of that document will be issued
from time to time to reflect the current best practice in this area. from time to time to reflect the current best practice in this area.
9. References 10. References
9.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>. December 2005, <http://www.rfc-editor.org/info/rfc4301>.
skipping to change at page 10, line 20 skipping to change at page 10, line 40
Implementation Requirements and Usage Guidance for Implementation Requirements and Usage Guidance for
Encapsulating Security Payload (ESP) and Authentication Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014,
<http://www.rfc-editor.org/info/rfc7321>. <http://www.rfc-editor.org/info/rfc7321>.
[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>.
9.2. Informative References 10.2. Informative References
[PD10] Paterson, K. and J. Degabriele, "On the (in)security of [PD10] Paterson, K. and J. Degabriele, "On the (in)security of
IPsec in MAC-then-encrypt configurations (ACM Conference IPsec in MAC-then-encrypt configurations (ACM Conference
on Computer and Communications Security, ACM CCS)", 2010. on Computer and Communications Security, ACM CCS)", 2010.
[RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, Payload Compression Protocol (IPComp)", RFC 2393,
DOI 10.17487/RFC2393, December 1998, DOI 10.17487/RFC2393, December 1998,
<http://www.rfc-editor.org/info/rfc2393>. <http://www.rfc-editor.org/info/rfc2393>.
 End of changes. 12 change blocks. 
16 lines changed or deleted 40 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/