draft-ietf-ipsecme-rfc7321bis-04.txt   draft-ietf-ipsecme-rfc7321bis-05.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: August 19, 2017 Red Hat Expires: August 31, 2017 Red Hat
Y. Nir Y. Nir
Check Point Check Point
T. Kivinen T. Kivinen
INSIDE Secure INSIDE Secure
February 15, 2017 February 27, 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-04 draft-ietf-ipsecme-rfc7321bis-05
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 August 19, 2017. This Internet-Draft will expire on August 31, 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 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . . 4
3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
4. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5 4. Encryption must be Authenticated . . . . . . . . . . . . . . 5
5. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7 5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 6
6. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9 6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 8
7. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9 7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 5, line 38 skipping to change at page 5, line 38
Secrecy ("PFS") protection. Deployments tend to never be Secrecy ("PFS") protection. Deployments tend to never be
reconfigured with fresh session keys. It also fails to scale and reconfigured with fresh session keys. It also fails to scale and
keeping SPI's unique amongst many servers is impractical. This keeping SPI's unique amongst many servers is impractical. This
document was written for deploying ESP/AH using IKE ([RFC7296]) and document was written for deploying ESP/AH using IKE ([RFC7296]) and
assumes that keying happens using IKEv2. assumes that keying happens using IKEv2.
If manual keying is used anyway, ENCR_AES_CBC MUST be used, and If manual keying is used anyway, ENCR_AES_CBC MUST be used, and
ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be
used as these algorithms require IKE. used as these algorithms require IKE.
4. ESP Encryption Algorithms 4. Encryption must be Authenticated
Encryption without authentication is not effective and MUST NOT be
used. IPsec offers three ways to provide both encryption and
authentication:
o ESP with an AEAD cipher
o ESP with a non-AEAD cipher + 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
cipher such as an AEAD cipher that handles encryption/decryption and
authentication in a single step. In this case, the AEAD cipher is
set as the encryption algorithm and the authentication algorithm is
set to none. Examples of this are ENCR_AES_GCM_16 and
ENCR_CHACHA20_POLY1305.
A more traditional approach is to use ESP with an encryption and an
authentication algorithm. This approach is slower, as the data has
to be processed twice, once for encryption/decryption and once for
authentication. An example of this is ENCR_AES_CBC combined with
AUTH_HMAC_SHA2_512_256.
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
due to the double header of ESP+AH, resulting in a smaller effective
MTU for the encrypted data. With this method, ESP is only used for
confidentiality without an authentication algorithm and a second
IPsec protocol of type AH is used for authentication. An example of
this is ESP with ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256.
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] |
skipping to change at page 7, line 40 skipping to change at page 8, line 10
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 CRFG and others as an
alternative to AES-CBC and AES-GCM. It is also being standardized alternative to AES-CBC and AES-GCM. It is also being standardized
for ESP for the same reasons. At the time of writing, there are not for ESP for the same reasons. At the time of writing, there are not
enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to
introduce it at the SHOULD+ level. Its status has been set to SHOULD introduce it at the SHOULD+ level. Its status has been set to SHOULD
and is expected to become MUST in the long term. and is expected to become MUST in the long term.
5. ESP and AH Authentication Algorithms 6. ESP and AH Authentication Algorithms
Encryption without authentication MUST NOT be used. As a result, Authentication algorithm recommendations in this section are
authentication algorithm recommendations in this section are targeting two types of communications:
targeting two types of communications: Firstly authenticated only
communications without encryption. Such communications can be ESP o Authenticated only communications without encryption, such as ESP
with NULL encryption or AH communications. Secondly, communications with NULL encryption or AH communications.
that are encrypted with non AEAD encryption algorithms mentioned o Communications that are encrypted with non-AEAD algorithm which
above. In this case, they MUST be combined with an authentication MUST be combined with an authentication algorithm.
algorithm.
+------------------------+------------------+-----------------------+ +------------------------+------------------+-----------------------+
| Name | Status | Comment | | Name | Status | Comment |
+------------------------+------------------+-----------------------+ +------------------------+------------------+-----------------------+
| AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD | | AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD |
| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] | | AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] | | AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] | | AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] |
| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] | | AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] |
| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] | | AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] |
skipping to change at page 8, line 25 skipping to change at page 8, line 40
| 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 reason NULL is acceptable is when authenticated encryption
algorithms are selected from Section 4. In all other cases, NULL algorithms are selected from Section 5. In all other cases, NULL
MUST NOT be selected. As ESP and AH both provides authentication, MUST NOT be selected. As ESP and AH both provide authentication, one
one may be tempted to combine these protocols to provide may be tempted to combine these protocols to provide authentication.
authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to As mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL
use ESP with NULL authentication - with non authenticated encryption authentication - with non authenticated encryption - in conjunction
- in conjunction with AH; some configurations of this combination of with AH; some configurations of this combination of services have
services have been shown to be insecure [PD10]. In addition, NULL been shown to be insecure [PD10]. In addition, NULL authentication
authentication cannot be combined with ESP NULL encryption. 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 9, line 21 skipping to change at page 9, line 37
a long standing common implementation bug of this algorithm that 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.
6. 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 | [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.
7. 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 RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE
TABLE BELOW WITH THE NUMBER OF THIS RFC TABLE BELOW WITH THE NUMBER OF THIS RFC
+-------------------+----------+-----------------+ +-------------------+----------+-----------------+
| Algorithm | RFC 7321 | RFC XXXX | | Algorithm | RFC 7321 | RFC XXXX |
+-------------------+----------+-----------------+ +-------------------+----------+-----------------+
| 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 | (*) |
| 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 |
skipping to change at page 10, line 19 skipping to change at page 10, line 27
| ENCR_AES_CTR | MAY | (*) | | ENCR_AES_CTR | 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.
8. Acknowledgements 9. 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.
9. IANA Considerations 10. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. Security Considerations 11. 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 10, line 45 skipping to change at page 11, 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.
11. References 12. References
11.1. Normative References 12.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 11, line 32 skipping to change at page 11, line 35
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc7321>.
11.2. Informative References 12.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>.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
[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>.
[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>. <http://www.rfc-editor.org/info/rfc4543>.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835,
DOI 10.17487/RFC4835, April 2007,
<http://www.rfc-editor.org/info/rfc4835>.
[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>. <http://www.rfc-editor.org/info/rfc4868>.
[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, <http://www.rfc-editor.org/info/rfc7296>.
 End of changes. 20 change blocks. 
46 lines changed or deleted 74 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/