IPSEC Working Group Jeffrey I. Schiller INTERNET-DRAFT draft-ietf-ipsec-ikev2-algorithms-00.txt May 2003 Cryptographic Algorithms for use in the Internet Key Exchange Version 2 Status of this Memo This document is a submission by the IPSEC Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@lists.tislabs.com mailing list. Distribution of this memo is unlimited. This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Australia), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. 2. Introduction The Internet Key Exchange protocol provides for the negotiation of cryptographic algorithms between both end points 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. This requires that some set of algorithms be specified as "mandatory to implement." 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 IKEv2 Algorithms [Page 1] draft-ietf-ipsec-algorithms-00.txt May 2003 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. 3. 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]. In addition we will 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 terms 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-. 4. Algorithm Selection 4.1. IKEv2 Algorithm Selection 4.1.1. Encrypted Payload Algorithms The IKEv2 Encrypted Payload requires both a confidentiality algorithm and an integrity algorithm. For Confidentiality AES-128-CBC is a MUST implement. For integrity IKEv2 Algorithms [Page 2] draft-ietf-ipsec-algorithms-00.txt May 2003 HMAC-SHA1 is a MUST implement. 4.1.2. Diffie-Hellman Groups There are several 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 references by group number. Group Number Bit Length Status 1 768 MAY 2 1024 SHOULD 3 155 (Elliptic Curve) MAY 4 185 (Elliptic Curve) MAY 5 1536 MUST 4.1.3. IKEv2 Transfer 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_DES_IV64 1 [RFC1827] SHOULD- ENCR_DES 2 [RFC2405] SHOULD- ENCR_3DES 3 [RFC2451] SHOULD ENCR_RC5 4 [RFC2451] MAY ENCR_IDEA 5 [RFC2451] MAY ENCR_CAST 6 [RFC2451] MAY ENCR_BLOWFISH 7 [RFC2451] MAY ENCR_3IDEA 8 [RFC2451] MAY ENCR_DES_IV32 9 MAY ENCR_RC4 10 MAY ENCR_NULL 11 [RFC2410] MAY ENCR_AES_128_CBC 12 MUST ENCR_AES_128_CTR 13 SHOULD 4.1.4. IKEv2 Transfer Type 2 Algorithms Transfer Type 2 Algorithms are pseudo-random functions used to generate random values when needed. IKEv2 Algorithms [Page 3] draft-ietf-ipsec-algorithms-00.txt May 2003 Name Number Defined In Status RESERVED 0 PRF_HMAC_MD5 1 [RFC2104] SHOULD PRF_HMAC_SHA1 2 [RFC2104] MUST PRF_HMAC_TIGER 3 [RFC2104] MAY PRF_AES128_CBC 4 MAY 4.1.5. IKEv2 Transfer 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_DES_MAC 3 MAY AUTH_KPDK_MD5 4 [RFC1826] MAY AUTH_AES_XCBC_96 5 SHOULD 5. Security Considerations The security of cryptographic based systems depends on both the strength of the cryptographic algorithms chosen, the strength of the keys used with those algorithms and 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. 6. IANA Considerations This document does not define any new registries nor elements in existing registries. Values given here for various algorithms are assigned in other documents and referenced here for convenience and IKEv2 Algorithms [Page 4] draft-ietf-ipsec-algorithms-00.txt May 2003 clarity. 7. Normative References [IKEv2] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol ", [RFC1826] R. Atkinson, "IP Authentication Header", 1995 [RFC1827] R. Atkinson., "IP Encapsulating Security Payload (ESP)", 1995 [RFC2026] S. Bradner, "RFC2026 The Internet Standards Process -- Revision 3", 1996 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", 1997 [RFC2119] S. Bradner, "RFC2119 Key words for use in RFCs to Indicate Requirement Levels.", 1997 [RFC2403] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", 1998 [RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", 1998 [RFC2405] C. Madson, N. Doraswamy., "The ESP DES-CBC Cipher Algorithm With Explicit IV", 1998 [RFC2409] Harkins, D., Carrel, D., "RFC 2409 The Internet Key Exchange (IKE)", 1998 [RFC2410] R. Glenn, S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", 1998 [RFC2451] R. Pereira, R. Adams, "The ESP CBC-Mode Cipher Algorithms", 1998 8. Authors Contact Information Jeffrey I. Schiller Massachusetts Institute of Technology Room W92-190 77 Massachusetts Avenue Cambridge, MA 02139-4307 USA Phone: +1 (617) 253-0161 E-mail: jis@mit.edu 9. Full Copyright Statement "Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other IKEv2 Algorithms [Page 5] draft-ietf-ipsec-algorithms-00.txt May 2003 Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." IKEv2 Algorithms [Page 6]