idnits 2.17.1 draft-ietf-ipsec-ikev2-algorithms-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC2409], [IKEv2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2004) is 7309 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEv2' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-CBC' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-CTR' ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'AESPRF' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-MAC' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSEC Working Group Jeffrey I. Schiller 2 INTERNET-DRAFT 3 draft-ietf-ipsec-ikev2-algorithms-05.txt April 2004 5 Cryptographic Algorithms for use in the 6 Internet Key Exchange Version 2 7 9 Status of this Memo 11 This document is a submission by the IPSEC Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the ipsec@lists.tislabs.com mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet Draft and is in full conformance with all 18 provisions of Section 10 of RFC2026 [RFC2026]. Internet Drafts are 19 working documents of the Internet Engineering Task Force (IETF), its 20 areas, and working groups. Note that other groups may also distribute 21 working documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet Drafts as reference material 26 or to cite them other than as "work in progress." 28 To learn the current status of any Internet Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Australia), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 1. Abstract 36 The IPSec series of protocols makes use of various cryptographic 37 algorithms in order to provide security services. The Internet Key 38 Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to 39 negotiate which algorithms should be used in any given association. 40 However to ensure interoperability between disparate implementations it 41 is necessary to specify a set of mandatory-to-implement algorithms to 42 ensure at least one algorithm that all implementations will have 43 available. This document defines the current set of algorithms that are 44 mandatory to implement as part of IKEv2, as well as algorithms that 45 should be implemented because they may be promoted to mandatory at some 46 future time. 48 2. Introduction 50 The Internet Key Exchange protocol provides for the negotiation of 51 cryptographic algorithms between both end points of a cryptographic 52 association. Different implementations of IPSec and IKE may provide 53 different algorithms. However the IETF desires that all implementations 54 should have some way to interoperate. In particular, 55 this requires that IKE define a set of mandatory-to-implement 56 algorithms, since IKE itself uses such algorithms as part of its own 57 negotiations. This requires that some set of algorithms be specified 58 as "mandatory-to-implement" for IKE. 60 The nature of cryptography is that new algorithms surface continuously 61 and existing algorithms are continuously attacked. An algorithm 62 believed to be strong today may be demonstrated to be weak tomorrow. 63 Given this, the choice of mandatory-to-implement algorithm should be 64 conservative so as to minimize the likelihood of it being compromised 65 quickly. Thought should also be given to performance considerations as 66 many uses of IPSec will be in environments where performance is a 67 concern. 69 Finally we need to recognize that the mandatory-to-implement 70 algorithm(s) may need to change over time to adapt to the changing 71 world. For this reason the selection of mandatory-to-implement 72 algorithms was removed from the main IKEv2 specification and placed in 73 this document. As the choice of algorithm changes, only this document 74 should need to be updated. 76 Ideally the mandatory-to-implement algorithm of tomorrow should already 77 be available in most implementations of IPSec by the time it is made 78 mandatory. To facilitate this we will attempt to identify those 79 algorithms (that are known today) in this document. There is no 80 guarantee that the algorithms we believe today may be mandatory in the 81 future will in fact become so. All algorithms known today are subject 82 to cryptographic attack, and may be broken. 84 3. Requirements Terminology 86 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 87 "MAY" that appear in this document are to be interpreted as described 88 in [RFC2119]. 90 In addition we will define some additional terms here: 92 SHOULD+ This term means the same as SHOULD. However it is 93 likely that an algorithm marked as SHOULD+ will be 94 promoted at some future time to be a MUST. 95 SHOULD- This terms means the same as SHOULD. However an 96 algorithm marked as SHOULD- may be deprecated to a 97 MAY in a future version of this document. 99 MUST- This term means the same as MUST. However we 100 expect at some point that this algorithm will no 101 longer be a MUST in a future document. Although 102 its status will be determined at a later time, it 103 is reasonable to expect that if a future revision 104 of a document alters the status of a MUST- 105 algorithm, it will remain at least a SHOULD or a 106 SHOULD-. 108 4. Algorithm Selection 110 4.1. IKEv2 Algorithm Selection 112 4.1.1. Encrypted Payload Algorithms 114 The IKEv2 Encrypted Payload requires both a confidentiality algorithm 115 and an integrity algorithm. 116 For confidentiality, implementations MUST implement 3DES-CBC and 117 SHOULD+ implement AES-128-CBC. For integrity, HMAC-SHA1 MUST be 118 implemented. 120 4.1.2. Diffie-Hellman Groups 122 There are several MODP groups that are defined for use in IKEv2. They 123 are defined in both the IKEv2 base document and in the MODP extensions 124 document. They are identified by group number. Any groups not listed 125 here are considered as "MAY be implemented". 127 Group Number Bit Length Status Defined 128 2 1024 MODP Group MUST- [RFC2409] 129 14 2048 MODP Group SHOULD+ [RFC3526] 131 4.1.3. IKEv2 Transform Type 1 Algorithms 133 IKEv2 Defines several possible algorithms for Transfer Type 1 134 (encryption). These are defined below with their implementation status. 136 Name Number Defined In Status 137 RESERVED 0 138 ENCR_3DES 3 [RFC2451] MUST- 139 ENCR_NULL 11 [RFC2410] MAY 140 ENCR_AES_CBC 12 [AES-CBC] SHOULD+ 141 ENCR_AES_CTR 13 [AES-CTR] SHOULD 143 4.1.4. IKEv2 Transform Type 2 Algorithms 145 Transfer Type 2 Algorithms are pseudo-random functions used to generate 146 random values when needed. 148 Name Number Defined In Status 149 RESERVED 0 150 PRF_HMAC_MD5 1 [RFC2104] MAY 151 PRF_HMAC_SHA1 2 [RFC2104] MUST 152 PRF_AES128_CBC 4 [AESPRF] SHOULD+ 154 4.1.5. IKEv2 Transform Type 3 Algorithms 156 Transfer Type 3 Algorithms are Integrity algorithms used to protect 157 data against tampering. 159 Name Number Defined In Status 160 NONE 0 161 AUTH_HMAC_MD5_96 1 [RFC2403] MAY 162 AUTH_HMAC_SHA1_96 2 [RFC2404] MUST 163 AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ 165 5. Security Considerations 167 The security of cryptographic based systems depends on both the 168 strength of the cryptographic algorithms chosen, the strength of the 169 keys used with those algorithms and the engineering of the protocol 170 used by the system to ensure that there are no non-cryptographic ways 171 to bypass the security of the overall system. 173 This document concerns itself with the selection of cryptographic 174 algorithms for the use of IKEv2, specifically with the selection of 175 "mandatory-to-implement" algorithms. The algorithms identified in this 176 document as "MUST implement" or "SHOULD implement" are not known to be 177 broken at the current time and cryptographic research so far leads us 178 to believe that they will likely remain secure into the foreseeable 179 future. However, this isn't necessarily forever. We would therefore 180 expect that new revisions of this document will be issued from time to 181 time that reflect the current best practice in this area. 183 6. IANA Considerations 185 This document does not define any new registries nor elements in 186 existing registries. Values given here for various algorithms are 187 assigned in other documents and referenced here for convenience and 188 clarity. 190 7. Normative References 191 [RFC2026] S. Bradner, "RFC2026 The Internet Standards Process -- 192 Revision 3", RFC2026, 1996 193 [RFC2409] Harkins, D., Carrel, D., "RFC 2409 The Internet Key 194 Exchange (IKE)", RFC2409, 1998 195 [IKEv2] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", 196 , 2003 197 [RFC2119] S. Bradner, "RFC2119 Key words for use in RFCs to Indicate 198 Requirement Levels.", RFC2119, 1997 199 [RFC3526] T. Kivinen, M. Kojo., "More Modular Exponential (MODP) 200 Diffie-Hellman groups for Internet Key Exch", , 2003 201 [RFC2451] R. Pereira, R. Adams, "The ESP CBC-Mode Cipher 202 Algorithms", RFC2451, 1998 203 [RFC2410] R. Glenn, S. Kent, "The NULL Encryption Algorithm and Its 204 Use With IPsec", RFC2410, 1998 205 [AES-CBC] S. Frankel, S. Kelly, R. Glenn, "The AES Cipher Algorithm 206 and Its Use With IPsec", , 2003 208 [AES-CTR] R. Housley, "Using AES Counter Mode With IPsec ESP", 209 , 2003 210 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 211 for Message Authentication", RFC2104, 1997 212 [AESPRF] P. Hoffman, "The AES-XCBC-PRF-128 algorithm for IKE", 213 , 2003 214 [RFC2403] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP 215 and AH", RFC2403, 1998 216 [RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 217 and AH", RFC2404, 1998 218 [AES-MAC] S. Frankel,H. Herbert, "The AES-XCBC-MAC-96 Algorithm and 219 Its Use With IPsec", , 2003 222 8. Author's Contact Information 224 Jeffrey I. Schiller 225 Massachusetts Institute of Technology 226 Room W92-190 227 77 Massachusetts Avenue 228 Cambridge, MA 02139-4307 229 USA 231 Phone: +1 (617) 253-0161 232 E-mail: jis@mit.edu 234 9. Full Copyright Statement 236 "Copyright (C) The Internet Society (2004). All Rights Reserved. 238 This document and translations of it may be copied and furnished to 239 others, and derivative works that comment on or otherwise explain it or 240 assist in its implementation may be prepared, copied, published and 241 distributed, in whole or in part, without restriction of any kind, 242 provided that the above copyright notice and this paragraph are 243 included on all such copies and derivative works. However, this 244 document itself may not be modified in any way, such as by removing the 245 copyright notice or references to the Internet Society or other 246 Internet organizations, except as needed for the purpose of developing 247 Internet standards in which case the procedures for copyrights defined 248 in the Internet Standards process must be followed, or as required to 249 translate it into languages other than English. 251 The limited permissions granted above are perpetual and will not be 252 revoked by the Internet Society or its successors or assigns. 254 This document and the information contained herein is provided on an 255 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 256 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 257 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 258 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 259 FITNESS FOR A PARTICULAR PURPOSE."