idnits 2.17.1 draft-rescorla-tls-suiteb-07.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, updated by RFC 4748 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 445. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (October 2, 2008) is 5656 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Salter 3 Internet-Draft National Security Agency 4 Intended status: Informational E. Rescorla 5 Expires: April 5, 2009 Network Resonance 6 R. Housley 7 Vigil Security 8 October 2, 2008 10 Suite B Cipher Suites for TLS 11 draft-rescorla-tls-suiteb-07.txt 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 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 5, 2009. 38 Abstract 40 The United States Government has published guidelines for "NSA Suite 41 B Cryptography", which defines cryptographic algorithm policy for 42 national security applications. This document defines a profile of 43 TLS which is conformant with Suite B. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 49 3. Suite B Requirements . . . . . . . . . . . . . . . . . . . . . 3 50 4. Suite B Compliance Requirements . . . . . . . . . . . . . . . 4 51 4.1. Security Levels . . . . . . . . . . . . . . . . . . . . . 6 52 4.2. Acceptable Curves . . . . . . . . . . . . . . . . . . . . 7 53 4.3. Certificates . . . . . . . . . . . . . . . . . . . . . . . 7 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 59 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 61 Intellectual Property and Copyright Statements . . . . . . . . . . 11 63 1. Introduction 65 National Security Agency posted a Fact Sheet on Suite B Cryptography, 66 and at the time of this writing, it states: 68 To complement the existing policy for the use of the Advanced 69 Encryption Standard (AES) to protect national security systems 70 and information as specified in The National Policy on the use of 71 the Advanced Encryption Standard (AES) to Protect National 72 Security Systems and National Security Information (CNSSP-15), 73 the National Security Agency (NSA) announced Suite B Cryptography 74 at the 2005 RSA Conference. In addition to the AES, Suite B 75 includes cryptographic algorithms for hashing, digital 76 signatures, and key exchange. 78 Suite B only specifies the cryptographic algorithms to be 79 used. Many other factors need to be addressed in determining 80 whether a particular device implementing a particular set of 81 cryptographic algorithms should be used to satisfy a particular 82 requirement. 84 Among those factors are "requirements for interoperability both 85 domestically and internationally". 87 This document is a profile of TLS 1.2 [RFC5246] and of the cipher 88 suites defined in [RFC5289], but does not itself define any new 89 cipher suites. 91 2. Conventions Used In This Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Suite B Requirements 99 The Fact Sheet on Suite B Cryptography requires that key 100 establishment and authentication algorithms be based on Elliptic 101 Curve Cryptography, that the encryption algorithm be AES [AES], and 102 that the function used for key derivation and data integrity be SHA 103 [SHS]. It defines two security levels, of 128 and 192 bits. 105 In particular, Suite B includes: 107 Encryption: Advanced Encryption Standard (AES) [AES] - 108 FIPS 197 (with keys sizes of 128 and 256 109 bits) 111 Digital Signature: Elliptic Curve Digital Signature Algorithm 112 (ECDSA) [DSS] - FIPS 186-2 (using the 113 curves with 256 and 384-bit prime moduli) 115 Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) - NIST 116 Special Publication 800-56A [PWKE] (using the 117 curves with 256 and 384-bit prime moduli) 119 Hashing: Secure Hash Algorithm - FIPS 180-2 [SHS] 120 (using SHA-256 and SHA-384) 122 The 128-bit security level corresponds to an elliptic curve size of 123 256 bits, AES-128, and SHA-256. The 192-bit security level 124 corresponds to an elliptic curve size of 384 bits, AES-256, and SHA- 125 384. 127 Note: Some people refer to the two security levels based on the AES 128 key size that is employed. At the 128-bit security level, an AES key 129 length of 128 bits is used. However, at the 192-bit security level, 130 an AES key length of 256 bits is used. 132 4. Suite B Compliance Requirements 134 TLS version 1.1 [RFC4346] and earlier does not support Galois Counter 135 Mode (GCM) cipher suites [RFC5289]. However, TLS version 1.2 136 [RFC5246] and later does support GCM. For Suite B TLS compliance, 137 GCM cipher suites are REQUIRED to be used whenever possible. Also, 138 for Suite B TLS compliance, Cipher Block Chaining (CBC) cipher suites 139 are employed when GCM cipher suites cannot be employed. 141 For a client to be considered Suite B compliant, the following cipher 142 suite rules apply: 144 o A Suite B compliant TLS version 1.1 or earlier client MUST offer 145 one cipher suite for each supported security level. For the 128 146 bit security level, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MUST be 147 offered in the ClientHello message. For the 192 bit security 148 level, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MUST be offered in the 149 ClientHello message. One of these cipher suites MUST be the first 150 (most preferred) cipher suite in the ClientHello message. 151 o A Suite B compliant TLS version 1.2 or later client MUST offer at 152 least two cipher suites for each supported security level. For 153 the 128 bit security level, 154 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 155 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 MUST be offered in this 156 order in the ClientHello message. For the 192 bit security level, 157 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and 158 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 MUST be offered in this 159 order in the ClientHello message. 160 o A Suite B compliant TLS version 1.2 or later client that offers 161 backward compatibility with TLS version 1.1 or earlier servers MAY 162 offer an additional cipher suite for each supported security 163 level. If these cipher suites are offered, they MUST appear after 164 the ones discussed above. For the 128 bit security level, 165 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MAY be offered in the 166 ClientHello message. For the 192 bit security level, 167 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MAY be offered in the 168 ClientHello message. 169 o A Suite B compliant TLS (of any version) client that offers 170 interoperability with non-Suite B compliant servers MAY offer 171 additional cipher suites. If any additional cipher suites are 172 offered, they MUST appear after the ones discussed above in the 173 ClientHello message. 175 A Suite B compliant TLS server MUST be configured to support the 128- 176 bit security level, the 192-bit security level, or both security 177 levels. The cipher suite rules for each of these security levels is 178 described below. If a Suite B compliant TLS server is configured to 179 support both security levels, then the configuration MUST prefer one 180 security level over the other. In practice, this means that the 181 cipher suite rules associated with the cipher suites listed in 182 Section 4.1 for the preferred security level are processed before the 183 cipher suite rules for the less preferred security level. 185 For a server that is configured to support the 128-bit security level 186 to be considered Suite B compliant, the following cipher suite rules 187 apply: 189 o A Suite B compliant TLS version 1.1 or earlier server MUST accept 190 the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite if it is 191 offered. If the server is not offered this cipher suite and 192 interoperability with clients that are not compliant with Suite B 193 is desired, then the server MAY accept another offered cipher 194 suite that is considered acceptable by the server administrator. 195 o A Suite B compliant TLS version 1.2 or later server MUST accept 196 the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite if it is 197 offered. If this cipher suite is not offered, then the server 198 MUST accept the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 cipher 199 suite if it is offered. If neither of these cipher suites is 200 offered, then the server MUST accept the 201 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite if it is 202 offered. If the server is not offered any of those three cipher 203 suites and interoperability with clients that are not compliant 204 with Suite B is desired, then the server MAY accept another 205 offered cipher suite that is considered acceptable by the server 206 administrator. 208 For a server that is configured to support the 192-bit security level 209 to be considered Suite B compliant, the following cipher suite rules 210 apply: 212 o A Suite B compliant TLS version 1.1 or earlier server MUST accept 213 the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it is 214 offered. If the server is not offered this cipher suite and 215 interoperability with clients that are not compliant with Suite B 216 is desired, then the server MAY accept another offered cipher 217 suite that is considered acceptable by the server administrator. 218 o A Suite B compliant TLS version 1.2 or later server MUST accept 219 the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite if it is 220 offered. If this cipher suite is not offered, then the server 221 MUST accept the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 cipher 222 suite if it is offered. If neither of these cipher suites is 223 offered, then the server MUST accept the 224 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it is 225 offered. If the server is not offered any of those three cipher 226 suites and interoperability with clients that are not compliant 227 with Suite B is desired, then the server MAY accept another 228 offered cipher suite that is considered acceptable by the server 229 administrator. 231 Note that these rules explicitly permit the use of CBC cipher suites 232 in TLS version 1.2 connections in order to permit operation between 233 Suite B compliant and non-Suite B compliant implementations. For 234 instance, a Suite B compliant TLS version 1.2 client might offer TLS 235 version 1.2 with both GCM and CBC cipher suites when communicating 236 with a non-Suite B TLS version 1.2 server which then selected the CBC 237 cipher suites. This connection would nevertheless meet the 238 requirements of this specification. However, any two Suite B 239 compliant implementations will negotiate a GCM cipher suite when 240 doing TLS version 1.2. 242 4.1. Security Levels 244 As described in Section 1, Suite B specifies two security levels: 245 128 bit and 192 bit. The following table lists the cipher suites for 246 each security level. Within each security level, the cipher suites 247 are listed in their preferred order for selection by a TLS version 248 1.2 implementation. 250 +-----------------------------------------+----------------+ 251 | Cipher Suite | Security Level | 252 +-----------------------------------------+----------------+ 253 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128 | 254 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | 128 | 255 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | 128 | 256 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192 | 257 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | 192 | 258 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | 192 | 259 +-----------------------------------------+----------------+ 261 4.2. Acceptable Curves 263 RFC 4492 defines a variety of elliptic curves. For cipher suites 264 defined in this specification, only secp256r1(23) or secp384r1(24) 265 may be used. These are the same curves that appear in FIPS 186-2 266 [DSS] as P-256 and P-384, respectively. For cipher suites at the 267 128-bit security level, secp256r1 MUST be used. For cipher suites at 268 the 192-bit security level, secp384r1 MUST be used. RFC 4492 269 requires that uncompressed(0) form be supported. 270 ansiX962_compressed_prime(1) point formats MAY also be supported. 272 Clients desiring to negotiate only a Suite B-compliant connection 273 MUST generate a "Supported Elliptic Curves Extension" containing only 274 the allowed curves. These curves MUST match the cipher suite 275 security levels being offered. Clients which are willing to do both 276 Suite B-compliant and non-Suite B-compliant connections MAY omit the 277 extension or send the extension but offer other curves as well as the 278 appropriate Suite B ones. 280 Servers desiring to negotiate a Suite B-compliant connection SHOULD 281 check for the presence of the extension, but MUST NOT negotiate 282 inappropriate curves even if they are offered by the client. This 283 allows a Client which is willing to do either Suite B-compliant or 284 non-Suite B-compliant modes to interoperate with a server which will 285 only do Suite B-compliant modes. If the client does not advertise an 286 acceptable curve, the server MUST generate a fatal 287 "handshake_failure" alert and terminate the connection. Clients MUST 288 check the chosen curve to make sure it is acceptable. 290 4.3. Certificates 292 Server and client certificates used to establish a Suite B-compliant 293 connection MUST be signed with ECDSA. For certificates used at the 294 128-bit security level, the subject public key MUST use the P-256 295 curve, and the digital signature MUST be calculated using the P-256 296 curve and the SHA-256 hash algorithm. For certificates used at the 297 192-bit security level, the subject public key MUST use the P-384 298 curve, and the digital signature MUST be calculated using the P-384 299 curve and the SHA-384 hash algorithm. 301 While the key exchange algorithm used in TLS_ECDHE_ECDSA-collection 302 of cipher suites require the server's certificate to be signed with a 303 particular signature scheme, this specification does not impose 304 restrictions on signature schemes used elsewhere in the certification 305 path. (Often such restrictions will be useful, and it is expected 306 that this will be taken into account in practices of certification 307 authorities. However, such restrictions are not strictly required, 308 even if it is beyond the capabilities of a client to completely 309 validate a given certification path, the client may be able to 310 validate the server's certificate by relying on a trusted 311 certification authority whose certificate appears as one of the 312 intermediate certificates in the certification path.) 314 Likewise, this specification does not impose restrictions on 315 signature schemes used in the certification path for the client's 316 certificate when mutual authentication is employed. 318 5. Security Considerations 320 Most of the security considerations for this document are described 321 in TLS 1.2 [RFC5246], Elliptic Curve Cryptography (ECC) Cipher Suites 322 for TLS [RFC4492], AES-GCM Cipher Suites for TLS [RFC5288], and TLS 323 ECC Cipher Suites with SHA-256/384 and AES-GCM [RFC5289]. Readers 324 should consult those documents. 326 In order to meet the goal of a consistent security level for the 327 entire cipher suite, in Suite B mode TLS implementations MUST ONLY 328 use the curves defined in Section 4.2. Otherwise, it is possible to 329 have a set of symmetric algorithms with much weaker or stronger 330 security properties than the asymmetric (ECC) algorithms. 332 6. IANA Considerations 334 This document defines no actions for IANA. 336 7. Acknowledgements 338 This work was supported by the US Department of Defense. 340 8. References 341 8.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 347 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 348 for Transport Layer Security (TLS)", RFC 4492, May 2006. 350 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 351 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 353 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 354 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 355 August 2008. 357 [AES] National Institute of Standards and Technology, 358 "Specification for the Advanced Encryption Standard 359 (AES)", FIPS 197, November 2001. 361 [DSS] National Institute of Standards and Technology, "Digital 362 Signature Standard", FIPS 186-2, January 2000. 364 [PWKE] National Institute of Standards and Technology, 365 "Recommendation for Pair-Wise Key Establishment Schemes 366 Using Discrete Logarithm Cryptography (Revised)", NIST 367 Special Publication 800-56A, March 2007. 369 [SHS] National Institute of Standards and Technology, "Secure 370 Hash Standard", FIPS 180-2, August 2002. 372 8.2. Informative References 374 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 375 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 377 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 378 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 379 August 2008. 381 Authors' Addresses 383 Margaret Salter 384 National Security Agency 385 9800 Savage Rd. 386 Fort Meade 20755-6709 387 USA 389 Email: msalter@restarea.ncsc.mil 391 Eric Rescorla 392 Network Resonance 393 2064 Edgewood Drive 394 Palo Alto 94303 395 USA 397 Email: ekr@rtfm.com 399 Russ Housley 400 Vigil Security 401 918 Spring Knoll Drive 402 Herndon 21070 403 USA 405 Email: housley@vigilsec.com 407 Full Copyright Statement 409 Copyright (C) The IETF Trust (2008). 411 This document is subject to the rights, licenses and restrictions 412 contained in BCP 78, and except as set forth therein, the authors 413 retain all their rights. 415 This document and the information contained herein are provided on an 416 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 417 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 418 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 419 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 420 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 421 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 423 Intellectual Property 425 The IETF takes no position regarding the validity or scope of any 426 Intellectual Property Rights or other rights that might be claimed to 427 pertain to the implementation or use of the technology described in 428 this document or the extent to which any license under such rights 429 might or might not be available; nor does it represent that it has 430 made any independent effort to identify any such rights. Information 431 on the procedures with respect to rights in RFC documents can be 432 found in BCP 78 and BCP 79. 434 Copies of IPR disclosures made to the IETF Secretariat and any 435 assurances of licenses to be made available, or the result of an 436 attempt made to obtain a general license or permission for the use of 437 such proprietary rights by implementers or users of this 438 specification can be obtained from the IETF on-line IPR repository at 439 http://www.ietf.org/ipr. 441 The IETF invites any interested party to bring to its attention any 442 copyrights, patents or patent applications, or other proprietary 443 rights that may cover technology that may be required to implement 444 this standard. Please address the information to the IETF at 445 ietf-ipr@ietf.org.