draft-ietf-ipsecme-rfc7321bis-06.txt   rfc8221.txt 
Network Working Group P. Wouters Internet Engineering Task Force (IETF) P. Wouters
Internet-Draft Red Hat Request for Comments: 8221 Red Hat
Obsoletes: 7321 (if approved) D. Migault Obsoletes: 7321 D. Migault
Intended status: Standards Track J. Mattsson Category: Standards Track J. Mattsson
Expires: December 21, 2017 Ericsson ISSN: 2070-1721 Ericsson
Y. Nir Y. Nir
Check Point Check Point
T. Kivinen T. Kivinen
INSIDE Secure October 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-06
Abstract Abstract
This document updates the Cryptographic Algorithm Implementation This document replaces RFC 7321, "Cryptographic Algorithm
Requirements for ESP and AH. The goal of these document is to enable Implementation Requirements and Usage Guidance for Encapsulating
ESP and AH to benefit from cryptography that is up to date while Security Payload (ESP) and Authentication Header (AH)". The goal of
making IPsec interoperable. this document is to enable ESP and AH to benefit from cryptography
that is up to date while making IPsec interoperable.
This document obsoletes RFC 7321.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on December 21, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8221.
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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Updating Algorithm Implementation Requirements and Usage 1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . 5
3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Encryption must be Authenticated . . . . . . . . . . . . . . 5 4. Encryption Must Be Authenticated . . . . . . . . . . . . . . 6
5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 6 5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 7
6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 8 6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 9
7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9 7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 10
8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 10 8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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
AH can be used with a cryptographic algorithms that are up to date. AH can be used with cryptographic algorithms that are up to date.
The challenge of such document is to make sure that over the time The challenge of such documents is making sure that, over time, IPsec
IPsec implementations can use secure and up-to-date cryptographic implementations can use secure and up-to-date cryptographic
algorithms while keeping IPsec interoperable. algorithms while keeping IPsec interoperable.
1.1. Updating Algorithm Implementation Requirements and Usage Guidance 1.1. Updating Algorithm Implementation Requirements and Usage Guidance
The field of cryptography evolves continuously. New stronger The field of cryptography evolves continuously: new, stronger
algorithms appear and existing algorithms are found to be less secure algorithms appear, and existing algorithms are found to be less
than originally thought. Therefore, algorithm implementation secure than originally thought. Therefore, algorithm implementation
requirements and usage guidance need to be updated from time to time requirements and usage guidance need to be updated from time to time
to reflect the new reality. The choices for algorithms must be to reflect the new reality. The choices for algorithms must be
conservative to minimize the risk of algorithm compromise. conservative to minimize the risk of algorithm compromise.
Algorithms need to be suitable for a wide variety of CPU Algorithms need to be suitable for a wide variety of CPU
architectures and device deployments ranging from high end bulk architectures and device deployments ranging from high-end bulk
encryption devices to small low-power IoT devices. encryption devices to small, low-power Internet of Things (IoT)
devices.
The algorithm implementation requirements and usage guidance may need The algorithm implementation requirements and usage guidance may need
to change over time to adapt to the changing world. For this reason, to change over time to adapt to the changing world. For this reason,
the selection of mandatory-to-implement algorithms was removed from the selection of mandatory-to-implement algorithms was removed from
the main IKEv2 specification and placed in a separate document. the main Internet Key Exchange Protocol Version 2 (IKEv2)
specification [RFC7296] and placed in a separate document.
1.2. Updating Algorithm Requirement Levels 1.2. Updating Algorithm Requirement Levels
The mandatory-to-implement algorithm of tomorrow should already be The mandatory-to-implement algorithm of tomorrow should already be
available in most implementations of AH/ESP by the time it is made available in most implementations of AH/ESP by the time it is made
mandatory. This document attempts to identify and introduce those mandatory. This document attempts to identify and introduce those
algorithms for future mandatory-to-implement status. There is no algorithms for future mandatory-to-implement status. There is no
guarantee that the algorithms in use today may become mandatory in guarantee that the algorithms in use today may become mandatory in
the future. Published algorithms are continuously subjected to the future. Published algorithms are continuously subjected to
cryptographic attack and may become too weak or could become cryptographic attack and may become too weak or could become
completely broken before this document is updated. completely broken before this document is updated.
This document only provides recommendations for the mandatory-to- This document only provides recommendations for the mandatory-to-
implement algorithms and algorithms too weak that are recommended not implement algorithms and "too weak" algorithms that are recommended
to be implemented. As a result, any algorithm listed at the IPsec not to be implemented. As a result, any algorithm listed at the
IANA registry not mentioned in this document MAY be implemented. It IPsec IANA registry that is not mentioned in this document MAY be
is expected that this document will be updated over time and next implemented. It is expected that this document will be updated over
versions will only mention algorithms which status has evolved. For time and future versions will only mention algorithms that have
clarification when an algorithm has been mentioned in [RFC7321], this evolved in status. For clarification, when an algorithm has been
document states explicitly the update of the status. mentioned in [RFC7321], this document states explicitly the update of
the status.
Although this document updates the algorithms to keep the AH/ESP Although this document updates the algorithms to keep the AH/ESP
communication secure over time, it also aims at providing communication secure over time, it also aims at providing
recommendations so that AH/ESP implementations remain interoperable. recommendations so that AH/ESP implementations remain interoperable.
AH/ESP interoperability is addressed by an incremental introduction AH/ESP interoperability is addressed by an incremental introduction
or deprecation of algorithms. In addition, this document also or deprecation of algorithms. In addition, this document also
considers the new use cases for AH/ESP deployment, such as Internet considers the new use cases for AH/ESP deployment, such as IoT.
of Things (IoT).
It is expected that deprecation of an algorithm is performed It is expected that deprecation of an algorithm be performed
gradually. This provides time for various implementations to update gradually. This provides time for various implementations to update
their implemented algorithms while remaining interoperable. Unless their implemented algorithms while remaining interoperable. Unless
there are strong security reasons, an algorithm is expected to be there are strong security reasons, an algorithm is expected to be
downgraded from MUST to MUST- or SHOULD, instead of MUST NOT. downgraded from MUST to MUST- or SHOULD, instead of MUST NOT (see
Similarly, an algorithm that has not been mentioned as mandatory-to- Section 2). Similarly, an algorithm that has not been mentioned as
implement is expected to be introduced with a SHOULD instead of a mandatory-to-implement is expected to be introduced with a SHOULD
MUST. instead of a MUST.
The current trend toward Internet of Things and its adoption of AH/ The current trend toward IoT and its adoption of AH/ESP requires this
ESP requires this specific use case to be taken into account as well. specific use case to be taken into account as well. IoT devices are
IoT devices are resource constrained devices and their choice of resource-constrained devices, and their choice of algorithms is
algorithms are motivated by minimizing the footprint of the code, the motivated by minimizing the footprint of the code, the computation
computation effort and the size of the messages to send. This effort, and the size of the messages to send. This document
document indicates "(IoT)" when a specified algorithm is specifically indicates "(IoT)" when a specified algorithm is specifically listed
listed for IoT devices. Requirement levels that are marked as "IoT" for IoT devices. Requirement levels that are marked as "IoT" apply
apply to IoT devices and to server-side implementations that might to IoT devices and to server-side implementations that might
presumably need to interoperate with them, including any general- presumably need to interoperate with them, including any general-
purpose VPN gateways. purpose VPN gateways.
1.3. Document Audience 1.3. Document Audience
The recommendations of this document mostly target AH/ESP The recommendations of this document mostly target AH/ESP
implementers as implementations need to meet both high security implementers as implementations need to meet both high security
expectations as well as high interoperability between various vendors expectations as well as high interoperability between various vendors
and with different versions. Interoperability requires a smooth move and with different versions. Interoperability requires a smooth move
to more secure cipher suites. This may differ from a user point of to more secure cipher suites. This may differ from a user point of
view that may deploy and configure AH/ESP with only the safest cipher view that may deploy and configure AH/ESP with only the safest cipher
suite. suite.
This document does not give any recommendations for the use of This document does not give any recommendations for the use of
algorithms, it only gives implementation recommendations for algorithms, it only gives recommendations for implementations. The
implementations. The use of algorithms by users is dictated by the use of algorithms by a specific user is dictated by their own
security policy requirements for that specific user, and are outside security policy requirements, which are outside the scope of this
the scope of this document. document.
The algorithms considered here are listed by the IANA as part of the The algorithms considered here are listed by IANA as part of the
IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is
deprecated and the recommendations of this document must not be deprecated; the recommendations of this document must not be
considered for IKEv1, nor IKEv1 parameters be considered by this considered for IKEv1, nor may IKEv1 parameters be considered by this
document. document.
The IANA registry for Internet Key Exchange Version 2 (IKEv2) The IANA registry for "Internet Key Exchange Version 2 (IKEv2)
Parameters contains some entries that are not for use with ESP or AH. Parameters" contains some entries that are not for use with ESP or
This document does not modify the status of those algorithms. AH. This document does not modify the status of those algorithms.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
We define some additional terms here: We define some additional terms here:
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 that an algorithm marked as SHOULD+ will be promoted at
some future time to be a MUST. some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm SHOULD- This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future marked as SHOULD- may be deprecated to a MAY in a future
version of this document. version of this document.
MUST- This term means the same as MUST. However, we expect at MUST- This term means the same as MUST. However, we expect at
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 The Internet of Things.
3. Manual Keying 3. Manual Keying
Manual Keying SHOULD NOT be used as it is inherently dangerous. Manual keying SHOULD NOT be used, as it is inherently dangerous.
Without any secure keying protocol such a IKE, IPsec does not offer Without any secure keying protocol, such as IKE, IPsec does not offer
Perfect Forward Secrecy ("PFS") protection and there is no entity to Perfect Forward Secrecy (PFS) protection; there is no entity to
ensure refreshing of session keys, tracking SPI uniqueness and ensure the refreshing of session keys, the tracking of Security
ensuring nonces, IVs and counters are never re-used. This document Parameter Index (SPI) uniqueness, and the single use of nonces,
was written for deploying ESP/AH using IKE ([RFC7296]) and assumes Initialization Vectors (IVs), and counters. This document was
that keying happens using IKE version 2 or higher. written for deploying ESP/AH using IKE [RFC7296] and assumes that
keying happens using IKEv2 or higher.
If Manual Keying is used regardless, Counter Mode algorithms such as If manual keying is used regardless, Counter Mode algorithms such as
ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM, and ENCR_CHACHA20_POLY1305
MUST NOT be used as it is incompatible with a secure and persistent MUST NOT be used, as it is incompatible with a secure and persistent
handling of the counter, as explained in the Security Considerations handling of the counter (as explained in the Security Considerations
Section of [RFC3686]. This particularly applies to IoT devices that section of [RFC3686]). This particularly applies to IoT devices that
have no state across reboots. As of publication date of this have no state across reboots. At the time of writing, ENCR_AES_CBC
document, ENCR_AES_CBC is the only Mandatory-To-Implement encryption is the only mandatory-to-implement encryption algorithm suitable for
algorithm suitable for Manual Keying. 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 Authenticated Encryption with Associated Data (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
The fastest and most modern method is to use ESP with a combined mode The fastest and most modern method is to use ESP with a combined mode
cipher such as an AEAD cipher that handles encryption/decryption and cipher, such as an AEAD cipher, that handles encryption/decryption
authentication in a single step. In this case, the AEAD cipher is and authentication in a single step. In this case, the AEAD cipher
set as the encryption algorithm and the authentication algorithm is is set as the encryption algorithm, and the authentication algorithm
set to none. Examples of this are ENCR_AES_GCM_16 and is set to none. Examples of this are ENCR_AES_GCM_16 and
ENCR_CHACHA20_POLY1305. ENCR_CHACHA20_POLY1305.
A more traditional approach is to use ESP with an encryption and an A more traditional approach is to use ESP with an encryption and an
authentication algorithm. This approach is slower, as the data has authentication algorithm. This approach is slower, as the data has
to be processed twice, once for encryption/decryption and once for to be processed twice: once for encryption/decryption and once for
authentication. An example of this is ENCR_AES_CBC combined with authentication. An example of this is ENCR_AES_CBC combined with
AUTH_HMAC_SHA2_512_256. AUTH_HMAC_SHA2_512_256.
The last method that can be used is ESP+AH. This method is NOT The last method that can be used is ESP+AH. This method is NOT
RECOMMENDED. It is the slowest method and also takes up more octets RECOMMENDED. It is the slowest method and also takes up more octets
due to the double header of ESP+AH, resulting in a smaller effective due to the double header of ESP+AH. This results in a smaller
MTU for the encrypted data. With this method, ESP is only used for effective MTU for the encrypted data. With this method, ESP is only
confidentiality without an authentication algorithm and a second used for confidentiality without an authentication algorithm, and a
IPsec protocol of type AH is used for authentication. An example of second IPsec protocol of type AH is used for authentication. An
this is ESP with ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256. example of this is ESP with ENCR_AES_CBC with AH with
AUTH_HMAC_SHA2_512_256.
5. ESP Encryption Algorithms 5. 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(IoT) | Yes | [RFC4309] | | 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 and 256-bit keys. [1] - This requirement level is for 128-bit and 256-bit keys. 192-bit
192-bit keys remain at MAY level. (IoT) - This requirement is for keys remain at the MAY level.
interoperability with IoT. Only 128-bit keys are at the given level.
IPsec sessions may have very long life time, and carry multiple (IoT) - This requirement is for interoperability with IoT. Only
128-bit keys are at the given level.
IPsec sessions may have very long lifetime and carry multiple
packets, so there is a need to move to 256-bit keys in the long term. packets, so there is a need to move to 256-bit keys in the long term.
For that purpose the requirement level for 128 bit keys and 256 bit For that purpose, the requirement level for 128-bit keys and 256-bit
keys are at MUST (when applicable). In that sense 256 bit keys keys is MUST (when applicable). In that sense, the status for
status has been raised from MAY in RFC7321 to MUST. 256-bit keys has been raised from MAY in [RFC7321] to MUST.
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 these algorithms is limited to
specific cases, and the absence of specification makes specific cases, and the absence of specification makes
interoperability difficult for IPsec communications. These interoperability difficult for IPsec communications. These
algorithms were not been mentioned in [RFC7321] and this document algorithms were not mentioned in [RFC7321], and this document
clarify that such algorithms MUST NOT be implemented for IPsec clarifies that such algorithms MUST NOT be implemented for IPsec
communications. communications.
Similarly IANA also allocated code points for algorithms that are not Similarly, IANA also allocated code points for algorithms that are
expected to be used to secure IPsec communications. Such algorithms not expected to be used to secure IPsec communications. Such
are noted as Non IPsec. As a result, these algorithms MUST NOT be algorithms are noted as non-IPsec. As a result, these algorithms
implemented. MUST NOT be implemented.
Various older and not well tested and never widely implemented Various ciphers that are older, not well tested, and never widely
ciphers have been changed to MUST NOT. implemented have been changed to MUST NOT.
ENCR_3DES status has been downgraded from MAY in RFC7321 to SHOULD ENCR_3DES status has been downgraded from MAY in [RFC7321] to SHOULD
NOT. ENCR_CHACHA20_POLY1305 is a more modern approach alternative NOT. ENCR_CHACHA20_POLY1305 is a more modern approach and
for ENCR_3DES than ENCR_AES_CBC and so it expected to be favored to alternative for ENCR_3DES than ENCR_AES_CBC, and so it is expected to
replace ENCR_3DES. be favored to replace ENCR_3DES.
ENCR_BLOWFISH has been downgraded to MUST NOT as it has been ENCR_BLOWFISH has been downgraded to MUST NOT as it has been
deprecated for years by TWOFISH, which is not standarized for ESP and deprecated for years by TWOFISH, which is not standardized for ESP
therefore not listed in this document. Some implementations support and therefore not listed in this document. Some implementations
TWOFISH using a private range number. support TWOFISH using a private range number.
ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to ENCR_NULL status was set to MUST in [RFC7321] and remains a MUST to
enable the use of ESP with only authentication which is preferred enable the use of ESP with only authentication, which is preferred
over AH due to NAT traversal. ENCR_NULL is expected to remain MUST over AH due to NAT traversal. ENCR_NULL is expected to remain MUST
by protocol requirements. by protocol requirements.
ENCR_AES_CBC status remains at MUST. ENCR_AES_CBC MUST be ENCR_AES_CBC status remains at MUST. ENCR_AES_CBC MUST be
implemented in order to enable interoperability between implemented in order to enable interoperability between
implementations that followed RFC7321. However, there is a trend for implementations that followed [RFC7321]. However, there is a trend
the industry to move to AEAD encryption, and the overhead of for the industry to move to AEAD encryption, and the overhead of
ENCR_AES_CBC remains quite large so it is expected to be replaced by ENCR_AES_CBC remains quite large, so it is expected to be replaced by
AEAD algorithms in the long term. AEAD algorithms in the long term.
ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised ENCR_AES_CCM_8 status was set to MAY in [RFC7321] and has been raised
from MAY to SHOULD in order to interact with Internet of Things from MAY to SHOULD in order to interact with IoT devices. As this
devices. As this case is not a general use case for VPNs, its status case is not a general use case for VPNs, its status is expected to
is expected to remain as SHOULD. remain as SHOULD.
ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order
to favor the use of authenticated encryption and AEAD algorithms. to favor the use of authenticated encryption and AEAD algorithms.
ENCR_AES_GCM_16 has been widely implemented for ESP due to its ENCR_AES_GCM_16 has been widely implemented for ESP due to its
increased performance and key longevity compared to ENCR_AES_CBC. increased performance and key longevity compared to ENCR_AES_CBC.
ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of
RFC7321. It has been recommended by the CRFG and others as an [RFC7321]. It has been recommended by the Crypto Forum Research
alternative to AES-CBC and AES-GCM. It is also being standardized Group (CFRG) and others as an alternative to AES-CBC and AES-GCM. At
for ESP for the same reasons. At the time of writing, there are not the time of writing, there are not enough ESP implementations of
enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to ENCR_CHACHA20_POLY1305 to be able to introduce it at the SHOULD+
introduce it at the SHOULD+ level. Its status has been set to SHOULD level. Its status has been set to SHOULD and is expected to become
and is expected to become MUST in the long term. MUST in the long term.
6. ESP and AH Authentication Algorithms 6. ESP and AH Authentication Algorithms
Authentication algorithm recommendations in this section are Authentication algorithm recommendations in this section are
targeting two types of communications: targeting two types of communications:
o Authenticated only communications without encryption, such as ESP o Authenticated-only communications without encryption, such as ESP
with NULL encryption or AH communications. with NULL encryption or AH communications.
o Communications that are encrypted with non-AEAD algorithm which
o Communications that are encrypted with a non-AEAD algorithm that
MUST be combined with an authentication algorithm. MUST be combined with an authentication algorithm.
+------------------------+------------------+-----------------------+ +------------------------+----------------+-------------------------+
| Name | Status | Comment | | Name | Status | Comment |
+------------------------+------------------+-----------------------+ +------------------------+----------------+-------------------------+
| AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD | | AUTH_NONE | MUST / | [RFC7296][RFC5282] |
| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] | | | MUST NOT | AEAD-only |
| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] | | AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] | | AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] | | AUTH_DES_MAC | MUST NOT | UNSPECIFIED |
| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] | | AUTH_KPDK_MD5 | MUST NOT | UNSPECIFIED |
| | | (IoT) | | AUTH_AES_XCBC_96 | SHOULD / MAY | [RFC3566][RFC7296] |
| AUTH_AES_128_GMAC | MAY | [RFC4543] | | | | (IoT) |
| AUTH_AES_256_GMAC | MAY | [RFC4543] | | AUTH_AES_128_GMAC | MAY | [RFC4543] |
| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] | | AUTH_AES_256_GMAC | MAY | [RFC4543] |
| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] | | AUTH_HMAC_SHA2_256_128 | MUST | [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 case where AUTH_NONE is acceptable is when authenticated only case where AUTH_NONE is acceptable is when authenticated
encryption algorithms are selected from Section 5. In all other encryption algorithms are selected from Section 5. In all other
cases, AUTH_NONE MUST NOT be selected. As ESP and AH both provide cases, AUTH_NONE MUST NOT be selected. As ESP and AH both provide
authentication, one may be tempted to combine these protocols to authentication, one may be tempted to combine these protocols to
provide authentication. As mentioned by RFC7321, it is NOT provide authentication. As mentioned by [RFC7321], it is NOT
RECOMMENDED to use ESP with NULL authentication - with non RECOMMENDED to use ESP with NULL authentication (with non-
authenticated encryption - in conjunction with AH; some authenticated encryption) in conjunction with AH; some configurations
configurations of this combination of services have been shown to be of this combination of services have been shown to be insecure
insecure [PD10]. In addition, AUTH_NONE authentication cannot be [PD10]. In addition, AUTH_NONE authentication cannot be combined
combined with ESP NULL encryption. 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].
MD5 is known to be vulnerable to collisions, these algorithms MUST As 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.
AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, as AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT, as IoT
Internet of Things deployments tend to prefer AES based HMAC deployments tend to prefer AES-based Hashed Message Authentication
functions in order to avoid implementing SHA2. For the wide VPN Code (HMAC) functions in order to avoid implementing SHA2. For the
deployment, as it has not been widely adopted, it has been downgraded wide VPN deployment, as it has not been widely adopted, it has been
from SHOULD to MAY. downgraded from SHOULD to MAY.
AUTH_AES_128_GMAC status has been 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 Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms
should only be used for AH and not for ESP. If using ENCR_NULL, 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- AUTH_HMAC_SHA2_256_128 is recommended for integrity. If using AES-
GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is
recommended. Therefore, these ciphers are kept at MAY. recommended. Therefore, these algorithms are kept at MAY.
AUTH_HMAC_SHA2_256_128 was not mentioned in RFC7321, as no SHA2 based AUTH_HMAC_SHA2_256_128 was not mentioned in [RFC7321], as no
authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be SHA2-based authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST
implemented in order to replace AUTH_HMAC_SHA1_96. Note that due to be implemented in order to replace AUTH_HMAC_SHA1_96. Note that due
a long standing common implementation bug of this algorithm that to a long standing common implementation bug of this algorithm that
truncates the hash at 96-bits instead of 128-bits, it is recommended truncates the hash at 96 bits instead of 128 bits, it is recommended
that implementations prefer AUTH_HMAC_SHA2_512_256 over that implementations prefer AUTH_HMAC_SHA2_512_256 over
AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256. AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256.
AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement
of AUTH_HMAC_SHA2_256_128 or when stronger security is required. of AUTH_HMAC_SHA2_256_128 or when stronger security is required.
This value has been preferred to AUTH_HMAC_SHA2_384, as the This value has been preferred to AUTH_HMAC_SHA2_384, as the
additional overhead of AUTH_HMAC_SHA2_512 is negligible. additional overhead of AUTH_HMAC_SHA2_512 is negligible.
7. ESP and AH Compression Algorithms 7. ESP and AH Compression Algorithms
+----------------+----------+-------------+ +----------------+----------+-------------+
| Name | Status | Comment | | Name | Status | Comment |
+----------------+----------+-------------+ +----------------+----------+-------------+
| IPCOMP_OUI | MUST NOT | UNSPECIFIED | | IPCOMP_OUI | MUST NOT | UNSPECIFIED |
| IPCOMP_DEFLATE | MAY | [RFC2393] | | IPCOMP_DEFLATE | MAY | [RFC3173] |
| IPCOMP_LZS | MAY | [RFC2395] | | IPCOMP_LZS | MAY | [RFC2395] |
| IPCOMP_LZJH | MAY | [RFC3051] | | IPCOMP_LZJH | MAY | [RFC3051] |
+----------------+----------+-------------+ +----------------+----------+-------------+
(IoT) - This requirement is for interoperability with IoT Compression was not mentioned in [RFC7321]. As it is not widely
deployed, it remains optional and at the MAY level.
Compression was not mentioned in RFC7321. As it is not widely
deployed, it remains optional and at the MAY-level.
8. Summary of Changes from RFC 7321 8. Summary of Changes from RFC 7321
The following table summarizes the 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 | | Algorithm | RFC 7321 | RFC 8221 |
+-------------------+----------+-----------------+ +-------------------+----------+-----------------+
| ENCR_AES_GCM_16 | SHOULD+ | MUST | | ENCR_AES_GCM_16 | SHOULD+ | MUST |
| ENCR_AES_CCM_8 | MAY | SHOULD | | ENCR_AES_CCM_8 | MAY | SHOULD |
| ENCR_AES_CTR | MAY | (*) | | ENCR_AES_CTR | MAY | MAY(*) |
| ENCR_3DES | MAY | SHOULD NOT | | ENCR_3DES | MAY | SHOULD NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- | | AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_128_GMAC | SHOULD+ | MAY | | AUTH_AES_128_GMAC | SHOULD+ | MAY |
| AUTH_NONE | MAY | MUST / MUST NOT | | AUTH_NONE | MAY | MUST / MUST NOT |
+-------------------+----------+-----------------+ +-------------------+----------+-----------------+
(*) This algorithm is not mentioned in the above sections, so it (*) This algorithm is not mentioned in the above sections, so it
defaults to MAY. defaults to MAY.
9. Acknowledgements
Some of the wording in this document was adapted from [RFC7321], the
document that this one obsoletes, which was written by D. McGrew and
P. Hoffman.
10. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document does not require any IANA actions.
11. Security Considerations 10. 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
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.
12. References 11. References
12.1. Normative References 11.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>. <https://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, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm
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>. <https://www.rfc-editor.org/info/rfc7321>.
12.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[PD10] Paterson, K. and J. Degabriele, "On the (in)security of 11.2. Informative References
IPsec in MAC-then-encrypt configurations (ACM Conference
on Computer and Communications Security, ACM CCS)", 2010.
[RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP [PD10] Paterson, K. and J. Degabriele, "On the (in)security of
Payload Compression Protocol (IPComp)", RFC 2393, IPsec in MAC-then-encrypt configurations", Proceedings of
DOI 10.17487/RFC2393, December 1998, the 17th ACM Conference on Computer and Communications
<http://www.rfc-editor.org/info/rfc2393>. Security (ACM CCS), DOI 10.1145/1866307.1866363, 2010.
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using
LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998, LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998,
<http://www.rfc-editor.org/info/rfc2395>. <https://www.rfc-editor.org/info/rfc2395>.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November
1998, <http://www.rfc-editor.org/info/rfc2403>. 1998, <https://www.rfc-editor.org/info/rfc2403>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <http://www.rfc-editor.org/info/rfc2404>. 1998, <https://www.rfc-editor.org/info/rfc2404>.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, Algorithm With Explicit IV", RFC 2405,
DOI 10.17487/RFC2405, November 1998, DOI 10.17487/RFC2405, November 1998,
<http://www.rfc-editor.org/info/rfc2405>. <https://www.rfc-editor.org/info/rfc2405>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,
November 1998, <http://www.rfc-editor.org/info/rfc2410>. November 1998, <https://www.rfc-editor.org/info/rfc2410>.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, DOI 10.17487/RFC2451, November Algorithms", RFC 2451, DOI 10.17487/RFC2451, November
1998, <http://www.rfc-editor.org/info/rfc2451>. 1998, <https://www.rfc-editor.org/info/rfc2451>.
[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using [RFC3051] Heath, J. and J. Border, "IP Payload Compression Using
ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051, ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051,
January 2001, <http://www.rfc-editor.org/info/rfc3051>. January 2001, <https://www.rfc-editor.org/info/rfc3051>.
[RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173,
DOI 10.17487/RFC3173, September 2001,
<https://www.rfc-editor.org/info/rfc3173>.
[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, <https://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>. <https://www.rfc-editor.org/info/rfc3602>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
<http://www.rfc-editor.org/info/rfc3686>. <https://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>. <https://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>. <https://www.rfc-editor.org/info/rfc4309>.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
DOI 10.17487/RFC4543, May 2006, DOI 10.17487/RFC4543, May 2006,
<http://www.rfc-editor.org/info/rfc4543>. <https://www.rfc-editor.org/info/rfc4543>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<http://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282,
DOI 10.17487/RFC5282, August 2008,
<https://www.rfc-editor.org/info/rfc5282>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(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, <https://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>. <https://www.rfc-editor.org/info/rfc7634>.
Acknowledgements
Some of the wording in this document was adapted from [RFC7321], the
document that this one obsoletes, which was written by D. McGrew and
P. Hoffman.
Authors' Addresses Authors' Addresses
Paul Wouters Paul Wouters
Red Hat Red Hat
Email: pwouters@redhat.com Email: pwouters@redhat.com
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8275 Trans Canada Route
Montreal, QC H4P 2N2 Saint-Laurent, QC H4S 0B6
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
skipping to change at page 14, line 4 skipping to change at page 15, line 33
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
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
Eerikinkatu 28
HELSINKI FI-00180
FI
Email: kivinen@iki.fi Email: kivinen@iki.fi
 End of changes. 104 change blocks. 
265 lines changed or deleted 275 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/