Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (original) (raw)
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
Obsoleted by: 7321 PROPOSED STANDARD
Network Working Group V. Manral Request for Comments: 4835 IP Infusion Inc. Obsoletes: 4305 April 2007 Category: Standards Track
Cryptographic Algorithm Implementation Requirements forEncapsulating Security Payload (ESP) and Authentication Header (AH)
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time.
Manral Standards Track [Page 1]
RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Encapsulating Security Payload . . . . . . . . . . . . . . 4 3.1.1. ESP Encryption and Authentication Algorithms . . . . . 4 3.1.2. ESP Combined Mode Algorithms . . . . . . . . . . . . . 5 3.2. Authentication Header . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Changes from RFC 2402 and RFC 2406 to RFC 4305 . . . . . . . . 7 7. Changes from RFC 4305 . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Manral Standards Track [Page 2]
RFC 4835 Cryptographic Algorithms ESP and AH April 2007
1. Introduction
The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA) [[RFC4301](./rfc4301 ""Security Architecture for the Internet Protocol"")], [[RFC4302](./rfc4302 ""IP Authentication Header"")]. To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time.
The nature of cryptography is that new algorithms surface continuously and existing algorithms are continuously attacked. An algorithm believed to be strong today may be demonstrated to be weak tomorrow. Given this, the choice of mandatory-to-implement algorithm should be conservative so as to minimize the likelihood of it being compromised quickly. Thought should also be given to performance considerations as many uses of IPsec will be in environments where performance is a concern.
Finally, we need to recognize that the mandatory-to-implement algorithm(s) may need to change over time to adapt to the changing world. For this reason, the selection of mandatory-to-implement algorithms is not included in the main IPsec, ESP, or AH specifications. It is instead placed in this document. As the choice of algorithm changes, only this document should need to be updated.
Ideally, the mandatory-to-implement algorithm of tomorrow should already be available in most implementations of IPsec by the time it is made mandatory. To facilitate this, we will attempt to identify such algorithms (as they are known today) in this document. There is no guarantee that the algorithms that we (today) believe may be mandatory in the future will in fact become so. All algorithms known today are subject to cryptographic attack and may be broken in the future.
2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [[RFC2119](./rfc2119 ""Key words for use in RFCs to Indicate Requirement Levels"")].
Manral Standards Track [Page 3]
RFC 4835 Cryptographic Algorithms ESP and AH April 2007
We define some additional terms here:
SHOULD+ This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD+ will be
promoted at some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, it is
likely that an algorithm marked as SHOULD- will be
deprecated to a MAY or worse in a future version of
this document.
MUST- This term means the same as MUST. However, we
expect that at some point in the future this algorithm
will no longer be a MUST.3. Algorithm Selection
For IPsec implementations to interoperate, they must support one or more security algorithms in common. This section specifies the security algorithm implementation requirements for standards- conformant ESP and AH implementations. The security algorithms actually used for any particular ESP or AH security association are determined by a negotiation mechanism, such as the Internet Key Exchange (IKE [[RFC2409](./rfc2409 ""The Internet Key Exchange (IKE)"")], [[RFC4306](./rfc4306 ""Internet Key Exchange (IKEv2) Protocol"")]) or pre-establishment.
Of course, additional standard and proprietary algorithms beyond those listed below can be implemented.
3.1. Encapsulating Security Payload
The implementation conformance requirements for security algorithms for ESP are given in the tables below. See Section 2 for definitions of the values in the "Requirement" column.
3.1.1. ESP Encryption and Authentication Algorithms
These tables list encryption and authentication algorithms for the IPsec Encapsulating Security Payload protocol.
Requirement Encryption Algorithm (notes)
----------- --------------------------
MUST NULL [[RFC2410](./rfc2410 ""The NULL Encryption Algorithm and Its Use With IPsec"")] (1)
MUST AES-CBC with 128-bit keys [[RFC3602](./rfc3602 ""The AES-CBC Cipher Algorithm and Its Use with IPsec"")]
MUST- TripleDES-CBC [[RFC2451](./rfc2451 ""The ESP CBC-Mode Cipher Algorithms"")]
SHOULD AES-CTR [[RFC3686](./rfc3686 ""Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)"")]
SHOULD NOT DES-CBC [[RFC2405](./rfc2405 ""The ESP DES-CBC Cipher Algorithm With Explicit IV"")] (2)Manral Standards Track [Page 4]
RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Requirement Authentication Algorithm (notes)
----------- -----------------------------
MUST HMAC-SHA1-96 [[RFC2404](./rfc2404 ""The Use of HMAC-SHA-1-96 within ESP and AH"")] (3)
SHOULD+ AES-XCBC-MAC-96 [[RFC3566](./rfc3566 ""The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec"")]
MAY NULL (1)
MAY HMAC-MD5-96 [[RFC2403](./rfc2403 ""The Use of HMAC-MD5-96 within ESP and AH"")] (4)Notes:
(1) Since ESP encryption is optional, support for the "NULL"
algorithm is required to maintain consistency with the way
services are negotiated. Note that while authentication and
encryption can each be "NULL", they MUST NOT both be "NULL"
[[RFC4301](./rfc4301 ""Security Architecture for the Internet Protocol"")].
(2) DES, with its small key size and publicly demonstrated and
open-design special-purpose cracking hardware, is of questionable
security for general use.
(3) Weaknesses have become apparent in SHA-1 [[SHA1-COLL](#ref-SHA1-COLL ""Update on SHA-1"")]; however,
these should not affect the use of SHA1 with HMAC.
(4) Weaknesses have become apparent in MD5 [[MD5-COLL](#ref-MD5-COLL ""Finding MD5 Collisions - a Toy For a Notebook"")]; however,
these should not affect the use of MD5 with HMAC.3.1.2. ESP Combined Mode Algorithms
As specified in [[RFC4303](./rfc4303 ""IP Encapsulating Security Payload (ESP)"")], combined mode algorithms are supported that provide both confidentiality and authentication services. Support of such algorithms will require proper structuring of ESP implementations. Under many circumstances, combined mode algorithms provide significant efficiency and throughput advantages. Although there are no suggested or required combined algorithms at this time, AES-CCM [[RFC4309](./rfc4309 ""Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)"")] and AES-GCM [[RFC4106](./rfc4106 ""The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)"")] are of interest. AES-CCM has been adopted as the preferred mode in IEEE 802.11 [[802.11i](#ref-802.11i ""LAN/MAN Specific Requirements Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications"")], and AES- GCM has been adopted as the preferred mode in IEEE 802.1ae [[802.1ae](#ref-802.1ae ""Media Access Control (MAC) Security"")].
3.2. Authentication Header
The implementation conformance requirements for security algorithms for AH are given below. See Section 2 for definitions of the values in the "Requirement" column. As you would suspect, all of these algorithms are authentication algorithms.
Manral Standards Track [Page 5]
RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Requirement Algorithm (notes)
----------- ----------------
MUST HMAC-SHA1-96 [[RFC2404](./rfc2404 ""The Use of HMAC-SHA-1-96 within ESP and AH"")] (1)
SHOULD+ AES-XCBC-MAC-96 [[RFC3566](./rfc3566 ""The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec"")]
MAY HMAC-MD5-96 [[RFC2403](./rfc2403 ""The Use of HMAC-MD5-96 within ESP and AH"")] (2)Note:
(1) Weaknesses have become apparent in SHA-1 [[SHA1-COLL](#ref-SHA1-COLL ""Update on SHA-1"")]; however,
these should not affect the use of SHA1 with HMAC.
(2) Weaknesses have become apparent in MD5 [[MD5-COLL](#ref-MD5-COLL ""Finding MD5 Collisions - a Toy For a Notebook"")]; however,
these should not affect the use of MD5 with HMAC.4. Security Considerations
The security of cryptography-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering and administration of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system.
This document concerns itself with the selection of cryptographic algorithms for the use of ESP and AH, specifically with the selection of mandatory-to-implement algorithms. The algorithms identified in this document as "MUST implement" or "SHOULD implement" are not known to be broken at the current time, and cryptographic research so far leads us to believe that they will likely remain secure into the foreseeable future. However, this is not necessarily forever. We would therefore expect that new revisions of this document will be issued from time to time that reflect the current best practice in this area.
5. Acknowledgements
Much of the wording herein was adapted from RFC 4305, the parent document of this document. RFC 4305 itself borrows text from [[RFC4307](./rfc4307 ""Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)"")], "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2", by Jeffrey I. Schiller.
Thanks to the following people for reporting or responding to reports of the errors in RFC 4305: Paul Hoffman, Stephen Kent, Paul Koning, and Lars Volker. Helpful Last-Call comments were received from Russ Housley, Elwyn Davies, Nicolas Williams, and Alfred Hoenes.
Manral Standards Track [Page 6]
RFC 4835 Cryptographic Algorithms ESP and AH April 2007
6. Changes from RFC 2402 and RFC 2406 to RFC 4305
[RFC2402] and [[RFC2406](./rfc2406 ""IP Encapsulating Security Payload (ESP)"")] defined the IPsec Authentication Header and IPsec Encapsulating Security Payload. Each specified the implementation requirements for cryptographic algorithms for their respective protocols. They have now been replaced with [[RFC4302](./rfc4302 ""IP Authentication Header"")] and [[RFC4303](./rfc4303 ""IP Encapsulating Security Payload (ESP)"")], which do not specify cryptographic algorithm implementation requirements, and this document, which specifies such requirements for both [[RFC4302](./rfc4302 ""IP Authentication Header"")] and [[RFC4303](./rfc4303 ""IP Encapsulating Security Payload (ESP)"")].
The implementation requirements are compared below:
Old Old New
Req. RFC(s) Requirement Algorithm (notes)
---- ------ ----------- -----------------
MUST 2406 SHOULD NOT DES-CBC [[RFC2405](./rfc2405 ""The ESP DES-CBC Cipher Algorithm With Explicit IV"")] (1)
MUST 2402 2406 MAY HMAC-MD5-96 [[RFC2403](./rfc2403 ""The Use of HMAC-MD5-96 within ESP and AH"")]
MUST 2402 2406 MUST HMAC-SHA1-96 [[RFC2404](./rfc2404 ""The Use of HMAC-SHA-1-96 within ESP and AH"")]Note:
(1) The IETF deprecated the use of single DES years ago and has
not included it in any new standard for some time (see IESG note
on the first page of [[RFC2407](./rfc2407 ""The Internet IP Security Domain of Interpretation for ISAKMP"")]). [[RFC4305](./rfc4305 ""Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)"")] represented the first
standards-track recognition of that deprecation by specifying that
implementations SHOULD NOT provide single DES. The US Government
National Institute of Standards and Technology (NIST) has formally
recognized the weakness of single DES by a notice published
[[DES-WDRAW](#ref-DES-WDRAW ""Announcing Proposed Withdrawal of Federal Information Processing Standard (FIPS) for the Data Encryption Standard (DES) and Request for Comments"")] proposing to withdraw it as a US Government Standard.
Triple DES remains approved by both the IETF and NIST.This document obsoletes [[RFC4305](./rfc4305 ""Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)"")]. The document incorporates changes for the support for the NULL Authentication Algorithm making the support from a MUST to a MAY. This change is made to make this document consistent with [[RFC4301](./rfc4301 ""Security Architecture for the Internet Protocol"")]. Text for SHA-1 collision attacks as well as the future use of AES-GCM and AES-CCM is added.
Manral Standards Track [Page 7]
RFC 4835 Cryptographic Algorithms ESP and AH April 2007
The changed implementation requirement resulting from the above changes is listed below:
Old Old New
Req. RFC(s) Requirement Algorithm (notes)
---- ------ ----------- -----------------
MUST 2406 MAY NULL Authentication
MUST 2406 MUST NULL Encryption
SHOULD+ 4305 MUST AES-CBC Encryption8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP14, RFC2119, March 1997.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
Manral Standards Track [Page 8]
RFC 4835 Cryptographic Algorithms ESP and AH April 2007
December 2005.[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
8.2. Informative References
[802.11i] "LAN/MAN Specific Requirements Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications", IEEE Standard Medium Access Control (MAC) Security, IEEE Std 802.11i, June 2004.
[802.1ae] "Media Access Control (MAC) Security", IEEE Standard Medium Access Control (MAC) Security, IEEE Std 802.1ae, June 2006.
[DES-WDRAW] "Announcing Proposed Withdrawal of Federal Information Processing Standard (FIPS) for the Data Encryption Standard (DES) and Request for Comments", FIPS Notice Docket No. 040602169-4169-01, July 2004.
[MD5-COLL] Klima, V., "Finding MD5 Collisions - a Toy For a Notebook", Cryptology ePrint Archive Medium Report 2005/ 075, March 2005.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
Manral Standards Track [Page 9]
RFC 4835 Cryptographic Algorithms ESP and AH April 2007
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[SHA1-COLL] Rijmen, V. and E. Oswald, "Update on SHA-1", Cryptology ePrint Archive Report 2005/010, January 2005.
Author's Address
Vishwas Manral IP Infusion Inc. Bamankhola, Bansgali, Almora, Uttarakhand 263601 India
Phone: +91-98456-61911 EMail: vishwas@ipinfusion.com
Manral Standards Track [Page 10]
RFC 4835 Cryptographic Algorithms ESP and AH April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
Manral Standards Track [Page 11]