| |
| |
| |
| |
| |
| |
| Network Working Group J. Schiller |
| Request for Comments: 4307 Massachusetts Institute of Technology |
| Category: Standards Track December 2005 |
| |
| |
| Cryptographic Algorithms for Use in the |
| Internet Key Exchange Version 2 (IKEv2) |
| |
| 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 Internet Society (2005). |
| |
| Abstract |
| |
| The IPsec series of protocols makes use of various cryptographic |
| algorithms in order to provide security services. The Internet Key |
| Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate |
| which algorithms should be used in any given association. However, |
| 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 |
| algorithms that are mandatory to implement as part of IKEv2, as well |
| as algorithms that should be implemented because they may be promoted |
| to mandatory at some future time. |
| |
| 1. Introduction |
| |
| The Internet Key Exchange protocol provides for the negotiation of |
| cryptographic algorithms between both endpoints of a cryptographic |
| |
| association. Different implementations of IPsec and IKE may provide |
| different algorithms. However, the IETF desires that all |
| implementations should have some way to interoperate. In particular, |
| this requires that IKE define a set of mandatory-to-implement |
| algorithms because IKE itself uses such algorithms as part of its own |
| negotiations. This requires that some set of algorithms be specified |
| as "mandatory-to-implement" for IKE. |
| |
| |
| |
| |
| |
| Schiller Standards Track [Page 1] |
| |
| RFC 4307 IKEv2 Cryptographic Algorithms December 2005 |
| |
| |
| 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 was removed from the main IKEv2 specification and 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 |
| those algorithms (that are known today) in this document. There is |
| no guarantee that the algorithms we believe today 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 |
| |
| Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and |
| "MAY" that appear in this document are to be interpreted as described |
| in [RFC2119]. |
| |
| 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, an algorithm |
| marked as SHOULD- may be deprecated to a MAY in a future |
| version of this document. |
| |
| MUST- This term means the same as MUST. However, we expect at |
| some point that this algorithm will no longer be a MUST in |
| a future document. Although its status will be determined |
| at a later time, it is reasonable to expect that if a |
| future revision of a document alters the status of a MUST- |
| algorithm, it will remain at least a SHOULD or a SHOULD-. |
| |
| |
| |
| |
| |
| Schiller Standards Track [Page 2] |
| |
| RFC 4307 IKEv2 Cryptographic Algorithms December 2005 |
| |
| |
| 3. Algorithm Selection |
| |
| 3.1. IKEv2 Algorithm Selection |
| |
| 3.1.1. Encrypted Payload Algorithms |
| |
| The IKEv2 Encrypted Payload requires both a confidentiality algorithm |
| and an integrity algorithm. For confidentiality, implementations |
| MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For |
| integrity, HMAC-SHA1 MUST be implemented. |
| |
| 3.1.2. Diffie-Hellman Groups |
| |
| There are several Modular Exponential (MODP) groups that are defined |
| for use in IKEv2. They are defined in both the [IKEv2] base document |
| and in the MODP extensions document. They are identified by group |
| number. Any groups not listed here are considered as "MAY be |
| implemented". |
| |
| Group Number Bit Length Status Defined |
| 2 1024 MODP Group MUST- [RFC2409] |
| 14 2048 MODP Group SHOULD+ [RFC3526] |
| |
| 3.1.3. IKEv2 Transform Type 1 Algorithms |
| |
| IKEv2 defines several possible algorithms for Transfer Type 1 |
| (encryption). These are defined below with their implementation |
| status. |
| |
| Name Number Defined In Status |
| RESERVED 0 |
| ENCR_3DES 3 [RFC2451] MUST- |
| ENCR_NULL 11 [RFC2410] MAY |
| ENCR_AES_CBC 12 [AES-CBC] SHOULD+ |
| ENCR_AES_CTR 13 [AES-CTR] SHOULD |
| |
| 3.1.4. IKEv2 Transform Type 2 Algorithms |
| |
| Transfer Type 2 Algorithms are pseudo-random functions used to |
| generate random values when needed. |
| |
| Name Number Defined In Status |
| RESERVED 0 |
| PRF_HMAC_MD5 1 [RFC2104] MAY |
| PRF_HMAC_SHA1 2 [RFC2104] MUST |
| PRF_AES128_CBC 4 [AESPRF] SHOULD+ |
| |
| |
| |
| |
| |
| Schiller Standards Track [Page 3] |
| |
| RFC 4307 IKEv2 Cryptographic Algorithms December 2005 |
| |
| |
| 3.1.5. IKEv2 Transform Type 3 Algorithms |
| |
| Transfer Type 3 Algorithms are Integrity algorithms used to protect |
| data against tampering. |
| |
| Name Number Defined In Status |
| NONE 0 |
| AUTH_HMAC_MD5_96 1 [RFC2403] MAY |
| AUTH_HMAC_SHA1_96 2 [RFC2404] MUST |
| AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ |
| |
| 4. Security Considerations |
| |
| The security of cryptographic-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 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 IKEv2, 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 isn't 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. Normative References |
| |
| [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange |
| (IKE)", RFC 2409, November 1998. |
| |
| [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) |
| Protocol", RFC 4306, December 2005. |
| |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |
| |
| [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential |
| (MODP) Diffie-Hellman groups for Internet Key Exchange |
| (IKE)", RFC 3526, May 2003. |
| |
| [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher |
| Algorithms", RFC 2451, November 1998. |
| |
| |
| |
| Schiller Standards Track [Page 4] |
| |
| RFC 4307 IKEv2 Cryptographic Algorithms December 2005 |
| |
| |
| [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm |
| and Its Use With IPsec", RFC 2410, November 1998. |
| |
| [AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC |
| Cipher Algorithm and Its Use with IPsec", RFC 3602, |
| September 2003. |
| |
| [AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES) |
| Counter Mode With IPsec Encapsulating Security Payload |
| (ESP)", RFC 3686, January 2004. |
| |
| [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: |
| Keyed-Hashing for Message Authentication", RFC 2104, |
| February 1997. |
| |
| [AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the |
| Internet Key Exchange Protocol (IKE)", RFC 3664, January |
| 2004. |
| |
| [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. |
| |
| [AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 |
| Algorithm and Its Use With IPsec", RFC 3566, September |
| 2003. |
| |
| Author's Address |
| |
| Jeffrey I. Schiller |
| Massachusetts Institute of Technology |
| Room W92-190 |
| 77 Massachusetts Avenue |
| Cambridge, MA 02139-4307 |
| USA |
| |
| Phone: +1 (617) 253-0161 |
| EMail: jis@mit.edu |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Schiller Standards Track [Page 5] |
| |
| RFC 4307 IKEv2 Cryptographic Algorithms December 2005 |
| |
| |
| Full Copyright Statement |
| |
| Copyright (C) The Internet Society (2005). |
| |
| 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 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 currently provided by the |
| Internet Society. |
| |
| |
| |
| |
| |
| |
| |
| Schiller Standards Track [Page 6] |
| |
