idnits 2.17.1 draft-rescorla-tls-suiteb-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 292. 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 (June 2, 2007) is 6173 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) == Outdated reference: A later version (-10) exists of draft-ietf-tls-rfc4346-bis-03 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 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: December 4, 2007 Network Resonance 6 June 2, 2007 8 Suite B Cipher Suites for TLS 9 draft-rescorla-tls-suiteb-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 4, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The United States Government has published guidelines for "NSA Suite 43 B Cryptography" dated July, 2005, which defines cryptographic 44 algorithm polcy for national security applications. This document 45 defines a profile of TLS which is conformant with Suite B. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 51 3. Suite B Requirements . . . . . . . . . . . . . . . . . . . . . 3 52 4. Suite B Compliance Requirements . . . . . . . . . . . . . . . . 4 53 4.1. Security Levels . . . . . . . . . . . . . . . . . . . . . . 4 54 4.2. Acceptable Curves . . . . . . . . . . . . . . . . . . . . . 5 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 60 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 62 Intellectual Property and Copyright Statements . . . . . . . . . . 8 64 1. Introduction 66 In July, 2005 the National Security Agency posted "Fact Sheet, NSA 67 Suite B Cryptography" which stated: 69 To complement the existing policy for the use of the Advanced 70 Encryption Standard (AES) to protect national security systems 71 and information as specified in The National Policy on the use of 72 the Advanced Encryption Standard (AES) to Protect National 73 Security Systems and National Security Information (CNSSP-15), 74 the National Security Agency (NSA) announced Suite B Cryptography 75 at the 2005 RSA Conference. In addition to the AES, Suite B 76 includes cryptographic algorithms for hashing, digital 77 signatures, and key exchange. 79 Suite B only specifies the cryptographic algorithms to be 80 used. Many other factors need to be addressed in determining 81 whether a particular device implementing a particular set of 82 cryptographic algorithms should be used to satisfy a particular 83 requirement. 85 Among those factors are "requirements for interoperability both 86 domestically and internationally". 88 This document is a profile of of TLS 1.2 [I-D.ietf-tls-rfc4346-bis] 89 and of the cipher suites defined in [I-D.ietf-tls-ecc-new-mac], but 90 does not itself define any new cipher suites. This profile requires 91 TLS 1.2. 93 2. Conventions Used In This Document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Suite B Requirements 101 The "Suite B Fact Sheet" requires that key establishment and 102 authentication algorithms be based on Elliptic Curve Cryptography, 103 that the encryption algorithm be AES [AES], and that the function 104 used for key derivation and data integrity be SHA [SHS]. It defines 105 two security levels, of 128 and 192 bits. 107 In particular it states: 109 SUITE B includes: 111 Encryption: Advanced Encryption Standard (AES) - 112 FIPS 197 (with keys sizes of 128 and 256 113 bits) 115 Digital Signature: Elliptic Curve Digital Signature Algorithm - 116 FIPS 186-2 (using the curves with 256 and 117 384-bit prime moduli) 119 Key Exchange: Elliptic Curve Diffie-Hellman or Elliptic 120 Curve MQV Draft NIST Special Publication 121 800-56 (using the curves with 256 and 122 384-bit prime moduli) 124 Hashing: Secure Hash Algorithm - FIPS 180-2 125 (using SHA-256 and SHA-384) 127 All implementations of Suite B must, at a minimum, include AES 128 with 128-bit keys, the 256-bit prime modulus elliptic curve and 129 SHA-256 as a common mode for widespread interoperability. 131 The 128-bit security level corresponds to an elliptic curve size of 132 256 bits, AES-128, and SHA-256. The 192-bit security level 133 corresponds to an elliptic curve size of 384 bits, AES-256, and SHA- 134 384. 136 4. Suite B Compliance Requirements 138 To be considered "Suite B compatible" at least one of the Galois 139 Counter Mode (GCM) CipherSuites defined in [I-D.ietf-tls-ecc-new-mac] 140 MUST be negotiated. In compliance with the guidance in the Suite B 141 Fact Sheet every TLS implementation of Suite B SHOULD implement 142 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. 144 4.1. Security Levels 146 As described in Section 1, Suite B specifies two security levels, 128 147 and 192 bit. The following table lists the security levels for each 148 cipher suite: 150 +-----------------------------------------+----------------+ 151 | Cipher Suite | Security Level | 152 +-----------------------------------------+----------------+ 153 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128 | 154 | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 | 128 | 155 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192 | 156 | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 | 192 | 157 +-----------------------------------------+----------------+ 159 4.2. Acceptable Curves 161 RFC 4492 defines a variety of elliptic curves. For cipher suites 162 defined in this specification, only secp256r1 (23) or secp384r1 (24) 163 may be used. (These are the same curves that appear in FIPS 186-2 as 164 P-256 and P-384, respectively.) For cipher suites at the 128-bit 165 security level, secp256r1 MUST be used. For cipher suites at the 166 192-bit security level, secp384r1 MUST be used. RFC 4492 requires 167 that uncompressed (0) form be supported. ansiX962_compressed_prime(1) 168 point formats MAY be supported. 170 Clients desiring to negotiate only a Suite B-compliant connection 171 MUST generate a "Supported Elliptic Curves Extension" containing only 172 the allowed curves. These curves MUST match the cipher suite 173 security levels being offered. Clients which are willing to do both 174 Suite B-compliant and non-Suite B-compliant connections MAY omit the 175 extension or send the extension but offer other curves as well as the 176 appropriate Suite B ones. 178 Servers desiring to negotiate a Suite B-compliant connection SHOULD 179 check for the presence of the extension, but MUST NOT negotiate 180 inappropriate curves even if they are offered by the client. This 181 allows a Client which is willing to do either Suite B-compliant or 182 non-Suite B-compliant modes to interoperate with a server which will 183 only do Suite B-compliant modes. If the client does not advertise an 184 acceptable curve, the server MUST generate a fatal 185 "handshake_failure" alert and terminate the connection. Clients MUST 186 check the chosen curve to make sure it is acceptable. 188 5. Security Considerations 190 Most of the security considerations for this document are described 191 in TLS 1.2 [I-D.ietf-tls-rfc4346-bis], RFC 4492 [RFC4492], and 192 [I-D.ietf-tls-ecc-new-mac]. Readers should consult those documents. 194 In order to meet the goal of a consistent security level for the 195 entire cipher suite, in Suite B mode TLS implementations MUST ONLY 196 use the curves defined in Section 4.2. Otherwise, it is possible to 197 have a set of symmetric algorithms with much weaker or stronger 198 security properties than the asymmetric (ECC) algorithms. 200 6. IANA Considerations 202 This document defines no actions for IANA. 204 7. Acknowledgements 206 This work was supported by the US Department of Defense. 208 8. References 210 8.1. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, March 1997. 215 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 216 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 217 for Transport Layer Security (TLS)", RFC 4492, May 2006. 219 [I-D.ietf-tls-rfc4346-bis] 220 Dierks, T. and E. Rescorla, "The TLS Protocol Version 221 1.2", draft-ietf-tls-rfc4346-bis-03 (work in progress), 222 March 2007. 224 [AES] National Institute of Standards and Technology, 225 "Specification for the Advanced Encryption Standard 226 (AES)", FIPS 197, November 2001. 228 [SHS] National Institute of Standards and Technology, "Secure 229 Hash Standard", FIPS 180-2, August 2002. 231 [I-D.ietf-tls-ecc-new-mac] 232 Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 233 256/384 and AES Galois Counter Mode", April 2007. 235 8.2. Informative References 236 Authors' Addresses 238 Margaret Salter 239 National Security Agency 240 9800 Savage Rd. 241 Fort Meade 20755-6709 242 USA 244 Email: msalter@restarea.ncsc.mil 246 Eric Rescorla 247 Network Resonance 248 2483 E. Bayshore #212 249 Palo Alto 94303 250 USA 252 Email: ekr@networkresonance.com 254 Full Copyright Statement 256 Copyright (C) The IETF Trust (2007). 258 This document is subject to the rights, licenses and restrictions 259 contained in BCP 78, and except as set forth therein, the authors 260 retain all their rights. 262 This document and the information contained herein are provided on an 263 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 264 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 265 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 266 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 267 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 268 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 270 Intellectual Property 272 The IETF takes no position regarding the validity or scope of any 273 Intellectual Property Rights or other rights that might be claimed to 274 pertain to the implementation or use of the technology described in 275 this document or the extent to which any license under such rights 276 might or might not be available; nor does it represent that it has 277 made any independent effort to identify any such rights. Information 278 on the procedures with respect to rights in RFC documents can be 279 found in BCP 78 and BCP 79. 281 Copies of IPR disclosures made to the IETF Secretariat and any 282 assurances of licenses to be made available, or the result of an 283 attempt made to obtain a general license or permission for the use of 284 such proprietary rights by implementers or users of this 285 specification can be obtained from the IETF on-line IPR repository at 286 http://www.ietf.org/ipr. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights that may cover technology that may be required to implement 291 this standard. Please address the information to the IETF at 292 ietf-ipr@ietf.org. 294 Acknowledgment 296 Funding for the RFC Editor function is provided by the IETF 297 Administrative Support Activity (IASA).