idnits 2.17.1 draft-solinas-ui-suites-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 382. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (January 10, 2007) is 6278 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) == Unused Reference: 'RFC4308' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'AES' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'IANA-IKEv1' is defined on line 317, but no explicit reference was found in the text == Unused Reference: 'IANA-IKEv2' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC4634' is defined on line 325, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-Suites' ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4753 (Obsoleted by RFC 5903) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCxxxx' -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L. Law, NSA 3 INTERNET-DRAFT J. Solinas, NSA 4 Expires July 10, 2007 January 10, 2007 6 Suite B Cryptographic Suites for IPsec 7 9 {{{ RFC Editor: Please replace every occurrence of "RFC xxxx" and 10 "[RFCxxxx]" with the RFC number that is assigned to 11 draft-kelly-ipsec-ciph-sha2 once it is approved and published. }}} 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This document proposes four optional cryptographic user interface 38 suites ("UI suites") for IPsec similar to the two suites specified 39 in RFC 4308. The four new suites provide compatibility with the 40 United States National Security Agency's Suite B specifications. 42 Table of Contents 44 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 2 45 2. Requirements Terminology. . . . . . . . . . . . . . . . . . 2 46 3. New UI Suites . . . . . . . . . . . . . . . . . . . . . . . 2 47 3.1 Suite "Suite-B-GCM-128" . . . . . . . . . . . . . . . 2 48 3.2 Suite "Suite-B-GCM-256" . . . . . . . . . . . . . . . 3 49 3.3 Suite "Suite-B-GMAC-128". . . . . . . . . . . . . . . 4 50 3.4 Suite "Suite-B-GMAC-256". . . . . . . . . . . . . . . 5 51 4. Security Considerations . . . . . . . . . . . . . . . . . . 5 52 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 53 6. References. . . . . . . . . . . . . . . . . . . . . . . . . 6 54 6.1 Normative . . . . . . . . . . . . . . . . . . . . . . 6 55 6.2. Informative . . . . . . . . . . . . . . . . . . . . . 7 57 1. Introduction 59 RFC 4308 proposes two optional cryptographic user interface suites 60 ("UI suites") for IPsec. The two suites, VPN-A and VPN-B, represent 61 commonly used present-day corporate VPN security choices and 62 anticipated future choices, respectively. This document proposes 63 four new UI suites based on implementations of the United States 64 National Security Agency's Suite B algorithms (see [SuiteB]). 66 As with the VPN suites, the Suite B suites are simply collections of 67 values for some options in IPsec. Use of UI suites does not change 68 the IPsec protocols in any way. 70 2. Requirements Terminology 72 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 73 in this document are to be interpreted as described in [RFC2119]. 75 3. New UI Suites 77 Each of the following UI suites provides choices for ESP (see 78 [RFC4303]) and for IKEv1 and IKEv2 (see [RFC2409] and [RFC4306]). 79 The four suites are differentiated by the choice of cryptographic 80 algorithm strengths and a choice of whether ESP is to provide both 81 confidentiality and integrity or integrity only. The suite names 82 are based on the AES mode and AES key length specified for ESP. 84 IPsec implementations that use these UI suites SHOULD use the suite 85 names listed here. IPsec implementations SHOULD NOT use names 86 different than those listed here for the suites that are described, 87 and MUST NOT use the names listed here for suites that do not match 88 these values. These requirements are necessary for interoperability. 90 3.1 Suite "Suite-B-GCM-128" 92 This suite provides ESP integrity protection and confidentiality 93 using 128-bit AES-GCM (see [RFC4106]). This suite or the following 94 suite should be used when ESP integrity protection and encryption 95 are both needed. 97 ESP: 98 Encryption AES with 128-bit keys and 16 octet ICV in GCM mode 99 [RFC4106] 100 Integrity NULL 102 IKEv1: 103 Encryption AES with 128-bit keys in CBC mode 104 [RFC3602] 105 Pseudo-random function HMAC-SHA-256 [RFCxxxx] 106 Hash SHA-256 [FIPS-180-2] 107 Diffie-Hellman group 256-bit random ECP group [RFC4753] 108 Group Type ECP 110 For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST 111 support pre-shared key authentication [RFC2409] for 112 interoperability. The authentication method used with IKEv1 MAY be 113 either pre-shared key [RFC2409] or ECDSA-256 [RFC4754]. 115 IKEv2: 116 Encryption AES with 128-bit keys in CBC mode 117 [RFC3602] 118 Pseudo-random function HMAC-SHA-256 [RFCxxxx] 119 Integrity HMAC-SHA-256-128 [RFCxxxx] 120 Diffie-Hellman group 256-bit random ECP group [RFC4753] 121 Authentication ECDSA-256 [RFC4754] 123 Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) 124 MUST be supported by both parties in this suite. 126 3.2 Suite "Suite-B-GCM-256" 128 This suite provides ESP integrity protection and confidentiality 129 using 256-bit AES-GCM (see [RFC4106]). This suite or the preceding 130 suite should be used when ESP integrity protection and encryption 131 are both needed. 133 ESP: 134 Encryption AES with 256-bit keys and 16 octet ICV in GCM mode 135 [RFC4106] 136 Integrity NULL 138 IKEv1: 139 Encryption AES with 256-bit keys in CBC mode 140 [RFC3602] 141 Pseudo-random function HMAC-SHA-384 [RFCxxxx] 142 Hash SHA-384 [FIPS-180-2] 143 Diffie-Hellman group 384-bit random ECP group [RFC4753] 144 Group Type ECP 146 For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST 147 support pre-shared key authentication [RFC2409] for 148 interoperability. The authentication method used with IKEv1 MAY be 149 either pre-shared key [RFC2409] or ECDSA-384 [RFC4754]. 151 IKEv2: 152 Encryption AES with 256-bit keys in CBC mode 153 [RFC3602] 154 Pseudo-random function HMAC-SHA-384 [RFCxxxx] 155 Integrity HMAC-SHA-384-192 [RFCxxxx] 156 Diffie-Hellman group 384-bit random ECP group [RFC4753] 157 Authentication ECDSA-384 [RFC4754] 159 Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) 160 MUST be supported by both parties in this suite. 162 3.3 Suite "Suite-B-GMAC-128" 164 This suite provides ESP integrity protection using 128-bit AES-GMAC 165 (see [RFC4543]) but does not provide confidentiality. This suite 166 or the following suite should be used only when there is no need for 167 ESP encryption. 169 ESP: 170 Encryption NULL 171 Integrity AES with 128-bit keys in GMAC mode [RFC4543] 173 IKEv1: 174 Encryption AES with 128-bit keys in CBC mode 175 [RFC3602] 176 Pseudo-random function HMAC-SHA-256 [RFCxxxx] 177 Hash SHA-256 [FIPS-180-2] 178 Diffie-Hellman group 256-bit random ECP group [RFC4753] 179 Group Type ECP 181 For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST 182 support pre-shared key authentication [RFC2409] for 183 interoperability. The authentication method used with IKEv1 MAY be 184 either pre-shared key [RFC2409] or ECDSA-256 [RFC4754]. 186 IKEv2: 187 Encryption AES with 128-bit keys in CBC mode 188 [RFC3602] 189 Pseudo-random function HMAC-SHA-256 [RFCxxxx] 190 Integrity HMAC-SHA-256-128 [RFCxxxx] 191 Diffie-Hellman group 256-bit random ECP group [RFC4753] 192 Authentication ECDSA-256 [RFC4754] 194 Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) 195 MUST be supported by both parties in this suite. 197 3.4 Suite "Suite-B-GMAC-256" 199 This suite provides ESP integrity protection using 256-bit AES-GMAC 200 (see [RFC4543]) but does not provide confidentiality. This suite 201 or the preceding suite should be used only when there is no need for 202 ESP encryption. 204 ESP: 205 Encryption NULL 206 Integrity AES with 256-bit keys in GMAC mode [RFC4543] 208 IKEv1: 209 Encryption AES with 256-bit keys in CBC mode 210 [RFC3602] 211 Pseudo-random function HMAC-SHA-384 [RFCxxxx] 212 Hash SHA-384 [FIPS-180-2] 213 Diffie-Hellman group 384-bit random ECP group [RFC4753] 214 Group Type ECP 216 For IKEv1, Phase 1 SHOULD use Main mode. IKEv1 implementations MUST 217 support pre-shared key authentication [RFC2409] for 218 interoperability. The authentication method used with IKEv1 MAY be 219 either pre-shared key [RFC2409] or ECDSA-384 [RFC4754]. 221 IKEv2: 222 Encryption AES with 256-bit keys in CBC mode 223 [RFC3602] 224 Pseudo-random function HMAC-SHA-384 [RFCxxxx] 225 Integrity HMAC-SHA-384-192 [RFCxxxx] 226 Diffie-Hellman group 384-bit random ECP group [RFC4753] 227 Authentication ECDSA-384 [RFC4754] 229 Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2) 230 MUST be supported by both parties in this suite. 232 4. Security Considerations 234 This document inherits all of the security considerations of the 235 IPsec, IKEv1, and IKEv2 documents. See [CNSSP-15] for guidance on 236 the use of AES in these suites for the protection of U.S. Government 237 information. 239 Some of the security options specified in these suites may be found 240 in the future to have properties significantly weaker than those that 241 were believed at the time this document was produced. 243 5. IANA Considerations 245 IANA has created and will maintain a registry called, "Cryptographic 246 Suites for IKEv1, IKEv2, and IPsec" (see [IANA-Suites]). The 247 registry consists of a text string and an RFC number that lists the 248 associated transforms. The four new suites in this document should 249 be added to this registry after RFC publication and approval by an 250 expert designated by the IESG. 252 The new values for the registry are: 254 Identifier Defined in 255 Suite-B-GCM-128 RFC draft-solinas-ui-suites-00.txt 256 Suite-B-GCM-256 RFC draft-solinas-ui-suites-00.txt 257 Suite-B-GMAC-128 RFC draft-solinas-ui-suites-00.txt 258 Suite-B-GMAC-256 RFC draft-solinas-ui-suites-00.txt 260 6. References 262 6.1 Normative 264 [FIPS-180-2] FIPS 180-2 with change notice, "Secure Hash Standard", 265 National Institute of Standards and Technology, February 2004. 267 [IANA-Suites] Internet Assigned Numbers Authority, "Cryptographic 268 Suites for IKEv1, IKEv2, and IPsec", January 5, 2006. 269 (http://www.iana.org/assignments/crypto-suites) 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, March 1997. 274 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 275 (IKE)", RFC 2409, November 1998. 277 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 278 Algorithm and Its Use with IPsec", RFC 3602, September 2003. 280 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 281 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, 282 June 2005. 284 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 285 RFC 4303, December 2005. 287 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 288 RFC 4306, December 2005. 290 [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, 291 December 2005. 293 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 294 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 295 2006. 297 [RFC4753] Fu, D. and J. Solinas, "ECP Groups for IKE and IKEv2", 298 RFC 4753, November 2006. 300 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 301 ECDSA", RFC 4754, November 2006. 303 [RFCxxxx] Kelly, S., and S. Frankel, "Using HMAC-SHA-256, 304 HMAC-SHA-384, and HMAC-SHA-512 With IPsec", RFC xxxx, 2007. 306 6.2 Informative 308 [AES] U.S. Department of Commerce/National Institute of Standards 309 and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, 310 November 2001. (http://csrc.nist.gov/publications/fips/index.html) 312 [CNSSP-15] Committee on National Security Systems, "National Policy on 313 the Use of the Advanced Encryption Standard (AES) to Protect 314 National Security Systems and National Security Information", June 315 2003. (http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf) 317 [IANA-IKEv1] Internet Assigned Numbers Authority, Internet Key 318 Exchange (IKE) Attributes, 5 Jun 2006. 319 (http://www.iana.org/assignments/ipsec-registry) 321 [IANA-IKEv2] Internet Assigned Numbers Authority, IKEv2 Parameters, 26 322 September 2006. 323 (http://www.iana.org/assignments/ikev2-parameters) 325 [RFC4634] D. Eastlake 3rd and T. Hansen, "US Secure Hash Algorithms 326 (SHA and HMAC-SHA)", RFC 4634, July 2006. 328 [SuiteB] U.S. National Security Agency, "Fact Sheet NSA Suite B 329 Cryptography", July 2005. 330 (http://www.nsa.gov/ia/industry/crypto_Suite_b.cfm?MenuID=10.2.7) 332 Authors' Addresses 334 Laurie E. Law 335 National Information Assurance Research Laboratory 336 National Security Agency 337 EMail: lelaw@orion.ncsc.mil 339 Jerome A. Solinas 340 National Information Assurance Research Laboratory 341 National Security Agency 342 EMail: jasolin@orion.ncsc.mil 344 Full Copyright Statement 346 Copyright (C) The Internet Society (2007). 348 This document is subject to the rights, licenses and restrictions 349 contained in BCP 78, and except as set forth therein, the authors 350 retain all their rights. 352 This document and the information contained herein are provided on an 353 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 354 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 355 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 356 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 357 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 358 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 360 Intellectual Property 362 The IETF takes no position regarding the validity or scope of any 363 Intellectual Property Rights or other rights that might be claimed to 364 pertain to the implementation or use of the technology described in 365 this document or the extent to which any license under such rights 366 might or might not be available; nor does it represent that it has 367 made any independent effort to identify any such rights. Information 368 on the procedures with respect to rights in RFC documents can be 369 found in BCP 78 and BCP 79. 371 Copies of IPR disclosures made to the IETF Secretariat and any 372 assurances of licenses to be made available, or the result of an 373 attempt made to obtain a general license or permission for the use of 374 such proprietary rights by implementers or users of this 375 specification can be obtained from the IETF on-line IPR repository at 376 http://www.ietf.org/ipr. 378 The IETF invites any interested party to bring to its attention any 379 copyrights, patents or patent applications, or other proprietary 380 rights that may cover technology that may be required to implement 381 this standard. Please address the information to the IETF at ietf- 382 ipr@ietf.org. 384 Expires July 10, 2007