idnits 2.17.1 draft-rescorla-tls-suiteb-11.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 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 565. 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 (November 17, 2008) is 5638 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 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 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: May 21, 2009 Network Resonance 6 R. Housley 7 Vigil Security 8 November 17, 2008 10 Suite B Profile for Transport Layer Security (TLS) 11 draft-rescorla-tls-suiteb-11.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 May 21, 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 version 1.2 which is fully conformant with Suite B. This document 44 also defines a transitional profile for use with TLS version 1.0 and 45 TLS version 1.1 employ Suite B algorithms to the greatest extent 46 possible. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 52 3. Suite B Requirements . . . . . . . . . . . . . . . . . . . . . 4 53 4. Suite B Compliance and Interoperability Requirements . . . . . 4 54 4.1. Security Levels . . . . . . . . . . . . . . . . . . . . . 7 55 4.2. Acceptable Curves . . . . . . . . . . . . . . . . . . . . 8 56 4.3. Certificates . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.4. signature_algorithms extension . . . . . . . . . . . . . . 9 58 4.5. CertificateRequest message . . . . . . . . . . . . . . . . 9 59 4.6. CertificateVerify message . . . . . . . . . . . . . . . . 10 60 4.7. ServerKeyExchange message signature . . . . . . . . . . . 10 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 68 Intellectual Property and Copyright Statements . . . . . . . . . . 13 70 1. Introduction 72 United States Government posted a Fact Sheet on National Security 73 Agency (NSA) Suite B Cryptography [NSA], and at the time of this 74 writing, it states: 76 To complement the existing policy for the use of the Advanced 77 Encryption Standard (AES) to protect national security systems 78 and information as specified in The National Policy on the use of 79 the Advanced Encryption Standard (AES) to Protect National 80 Security Systems and National Security Information (CNSSP-15), 81 the National Security Agency (NSA) announced Suite B Cryptography 82 at the 2005 RSA Conference. In addition to the AES, Suite B 83 includes cryptographic algorithms for hashing, digital 84 signatures, and key exchange. 86 Suite B only specifies the cryptographic algorithms to be 87 used. Many other factors need to be addressed in determining 88 whether a particular device implementing a particular set of 89 cryptographic algorithms should be used to satisfy a particular 90 requirement. 92 Among those factors are "requirements for interoperability both 93 domestically and internationally". 95 This document does not define any new cipher suites; instead, it 96 defines two profiles: 98 o A Suite B compliant profile for use with TLS version 1.2 [RFC5246] 99 and the cipher suites defined in [RFC5289]. This profile uses 100 only Suite B algorithms. 101 o A transitional profile for use with TLS version 1.0 [RFC2246] or 102 TLS version 1.1 [RFC4346] and the cipher suites defined in 103 [RFC4492]. This profile uses the Suite B cryptographic algorithms 104 to the greatest extent possible and provides backward 105 compatibility. While the transitional profile is not Suite B 106 compliant, it provides a transition path towards the Suite B 107 compliant profile. 109 2. Conventions Used In This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Suite B Requirements 117 The Fact Sheet on Suite B Cryptography requires that key 118 establishment and authentication algorithms be based on Elliptic 119 Curve Cryptography, and that the encryption algorithm be AES [AES]. 120 Suite B defines two security levels, of 128 and 192 bits. 122 In particular, Suite B includes: 124 Encryption: Advanced Encryption Standard (AES) [AES] - 125 FIPS 197 (with keys sizes of 128 and 256 126 bits) 128 Digital Signature: Elliptic Curve Digital Signature Algorithm 129 (ECDSA) [DSS] - FIPS 186-2 (using the 130 curves with 256 and 384-bit prime moduli) 132 Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) - NIST 133 Special Publication 800-56A [PWKE] (using the 134 curves with 256 and 384-bit prime moduli) 136 The 128-bit security level corresponds to an elliptic curve size of 137 256 bits and AES-128; it also makes use of SHA-256 [SHS]. The 192- 138 bit security level corresponds to an elliptic curve size of 384 bits 139 and AES-256; it also makes use of SHA-384 [SHS]. 141 Note: Some people refer to the two security levels based on the AES 142 key size that is employed instead of the overall security provided by 143 the combination of Suite B algorithms. At the 128-bit security 144 level, an AES key length of 128 bits is used, which does not lead to 145 any confusion. However, at the 192-bit security level, an AES key 146 length of 256 bits is used, which sometimes leads to an expectation 147 of more security than is offered by the combination of Suite B 148 algorithms. 150 To accommodate backward compatibility, a Suite B compliant client or 151 server can be configured to accept a cipher suite that is not part of 152 Suite B. However, whenever a Suite B compliant client and a Suite B 153 compliant server establish a TLS version 1.2 session, only Suite B 154 algorithms are employed. 156 4. Suite B Compliance and Interoperability Requirements 158 TLS version 1.1 [RFC4346] and earlier does not support Galois Counter 159 Mode (GCM) cipher suites [RFC5289]. However, TLS version 1.2 160 [RFC5246] and later does support GCM. For Suite B TLS compliance, 161 GCM cipher suites are REQUIRED to be used whenever both the client 162 and the server support the necessary cipher suites. Also, for Suite 163 B TLS compliance, Cipher Block Chaining (CBC) cipher suites are 164 employed when GCM cipher suites cannot be employed. 166 For a client to implement the Suite B compliant profile, it MUST 167 implement TLS version 1.2 or later and the following cipher suite 168 rules apply: 170 o A Suite B compliant TLS version 1.2 or later client MUST offer at 171 least two cipher suites for each supported security level. For 172 the 128 bit security level, 173 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 174 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 MUST be offered in this 175 order in the ClientHello message. For the 192 bit security level, 176 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and 177 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 MUST be offered in this 178 order in the ClientHello message. One of these cipher suites MUST 179 be the first (most preferred) cipher suite in the ClientHello 180 message. 181 o A Suite B compliant TLS version 1.2 or later client that offers 182 backward compatibility with TLS version 1.1 or earlier servers MAY 183 offer an additional cipher suite for each supported security 184 level. If these cipher suites are offered, they MUST appear after 185 the ones discussed above. For the 128 bit security level, 186 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MAY be offered in the 187 ClientHello message. For the 192 bit security level, 188 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MAY be offered in the 189 ClientHello message. 190 o A Suite B compliant TLS version 1.2 or later client that offers 191 interoperability with non-Suite B compliant servers MAY offer 192 additional cipher suites. If any additional cipher suites are 193 offered, they MUST appear after the ones discussed above in the 194 ClientHello message. 196 For a client to implement the Suite B transitional profile, it MUST 197 implement TLS version 1.1 or earlier and the following cipher suite 198 rules apply: 200 o A Suite B transitional TLS version 1.1 or earlier client MUST 201 offer the cipher suite for the 128 bit security level, the cipher 202 suite for the 192 bit security level, or both. For the 128 bit 203 security level, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MUST be 204 offered in the ClientHello message. For the 192 bit security 205 level, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MUST be offered in the 206 ClientHello message. One of these cipher suites MUST be the first 207 (most preferred) cipher suite in the ClientHello message. 209 o A Suite B transitional TLS version 1.1 or earlier client that 210 offers interoperability with non-Suite B compliant servers MAY 211 offer additional cipher suites. If any additional cipher suites 212 are offered, they MUST appear after the ones discussed above in 213 the ClientHello message. 215 A Suite B compliant TLS server MUST be configured to support the 128- 216 bit security level, the 192-bit security level, or both security 217 levels. The cipher suite rules for each of these security levels is 218 described below. If a Suite B compliant TLS server is configured to 219 support both security levels, then the configuration MUST prefer one 220 security level over the other. In practice, this means that the 221 cipher suite rules associated with the cipher suites listed in 222 Section 4.1 for the preferred security level are processed before the 223 cipher suite rules for the less preferred security level. 225 For a server to implement the Suite B conformant profile at the 128- 226 bit security level, the following cipher suite rules apply: 228 o A Suite B compliant TLS version 1.2 or later server MUST accept 229 the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite if it is 230 offered. 231 o If the preceding cipher suite is not offered, then a Suite B 232 compliant TLS version 1.2 or later server MUST accept the 233 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 cipher suite if it is 234 offered. 235 o If neither of the preceding two cipher suites is offered, then a 236 Suite B compliant TLS version 1.2 or later server that offers 237 backward compatibility with TLS version 1.1 or earlier clients MAY 238 accept the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite if it 239 is offered. 240 o If the server is not offered any of the preceding three cipher 241 suites and interoperability with clients that are not compliant or 242 interoperable with Suite B is desired, then the server MAY accept 243 another offered cipher suite that is considered acceptable by the 244 server administrator. 246 For a server to implement the Suite B transitional profile at the 247 128-bit security level, the following cipher suite rules apply: 249 o A Suite B transitional TLS version 1.1 or earlier server MUST 250 accept the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite if it 251 is offered. 252 o If the server is not offered the preceding cipher suite and 253 interoperability with clients that are not Suite B transitional is 254 desired, then the server MAY accept another offered cipher suite 255 that is considered acceptable by the server administrator. 257 For a server to implement the Suite B conformant profile at the 192- 258 bit security level, the following cipher suite rules apply: 260 o A Suite B compliant TLS version 1.2 or later server MUST accept 261 the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite if it is 262 offered. 263 o If the preceding cipher suite is not offered, then a Suite B 264 compliant TLS version 1.2 or later server MUST accept the 265 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 cipher suite if it is 266 offered. 267 o If neither of the preceding two cipher suites is offered, then a 268 Suite B compliant TLS version 1.2 or later server that offers 269 backward compatibility with TLS version 1.1 or earlier clients MAY 270 accept the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it 271 is offered. 272 o If the server is not offered any of the preceding three cipher 273 suites and interoperability with clients that are not compliant or 274 interoperable with Suite B is desired, then the server MAY accept 275 another offered cipher suite that is considered acceptable by the 276 server administrator. 278 For a server to implement the Suite B transitional profile at the 279 192-bit security level, the following cipher suite rules apply: 281 o A Suite B transitional TLS version 1.1 or earlier server MUST 282 accept the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it 283 is offered. 284 o If the server is not offered the preceding cipher suite and 285 interoperability with clients that are not Suite B transitional is 286 desired, then the server MAY accept another offered cipher suite 287 that is considered acceptable by the server administrator. 289 Note that these rules explicitly permit the use of CBC cipher suites 290 in TLS version 1.2 connections in order to permit operation between 291 Suite B compliant and non-Suite B compliant implementations. For 292 instance, a Suite B compliant TLS version 1.2 client might offer TLS 293 version 1.2 with both GCM and CBC cipher suites when communicating 294 with a non-Suite B TLS version 1.2 server which then selected the CBC 295 cipher suites. This connection would nevertheless meet the 296 requirements of this specification. However, any two Suite B 297 compliant implementations will negotiate a GCM cipher suite when 298 doing TLS version 1.2. 300 4.1. Security Levels 302 As described in Section 1, Suite B specifies two security levels: 303 128 bit and 192 bit. The following table lists the cipher suites for 304 each security level. Within each security level, the cipher suites 305 are listed in their preferred order for selection by a TLS version 306 1.2 implementation. 308 +-----------------------------------------+----------------+ 309 | Cipher Suite | Security Level | 310 +-----------------------------------------+----------------+ 311 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128 | 312 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | 128 | 313 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | 128 | 314 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192 | 315 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | 192 | 316 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | 192 | 317 +-----------------------------------------+----------------+ 319 4.2. Acceptable Curves 321 RFC 4492 defines a variety of elliptic curves. For cipher suites 322 defined in this specification, only secp256r1(23) or secp384r1(24) 323 may be used. These are the same curves that appear in FIPS 186-2 324 [DSS] as P-256 and P-384, respectively. For cipher suites at the 325 128-bit security level, secp256r1 MUST be used. For cipher suites at 326 the 192-bit security level, secp384r1 MUST be used. RFC 4492 327 requires that uncompressed(0) form be supported. 328 ansiX962_compressed_prime(1) point formats MAY also be supported. 330 Clients desiring to negotiate only a Suite B-compliant connection 331 MUST generate a "Supported Elliptic Curves Extension" containing only 332 the allowed curves. These curves MUST match the cipher suite 333 security levels being offered. Clients which are willing to do both 334 Suite B-compliant and non-Suite B-compliant connections MAY omit the 335 extension or send the extension but offer other curves as well as the 336 appropriate Suite B ones. 338 Servers desiring to negotiate a Suite B-compliant connection SHOULD 339 check for the presence of the extension, but MUST NOT negotiate 340 inappropriate curves even if they are offered by the client. This 341 allows a Client which is willing to do either Suite B-compliant or 342 non-Suite B-compliant modes to interoperate with a server which will 343 only do Suite B-compliant modes. If the client does not advertise an 344 acceptable curve, the server MUST generate a fatal 345 "handshake_failure" alert and terminate the connection. Clients MUST 346 check the chosen curve to make sure it is acceptable. 348 4.3. Certificates 350 Server and client certificates used to establish a Suite B-compliant 351 connection MUST be signed with ECDSA. For certificates used at the 352 128-bit security level, the subject public key MUST use the P-256 353 curve, and the digital signature MUST be calculated using the P-256 354 curve and the SHA-256 hash algorithm. For certificates used at the 355 192-bit security level, the subject public key MUST use the P-384 356 curve, and the digital signature MUST be calculated using the P-384 357 curve and the SHA-384 hash algorithm. 359 In TLS version 1.0 and TLS version 1.1, the key exchange algorithm 360 used in TLS_ECDHE_ECDSA-collection of cipher suites require the 361 server's certificate to be signed with a particular signature scheme. 362 TLS version 1.2 offers more flexibility. This specification does not 363 impose any additional restrictions on the server certificate 364 signature or the signature schemes used elsewhere in the 365 certification path. (Often such restrictions will be useful, and it 366 is expected that this will be taken into account in practices of 367 certification authorities. However, such restrictions are not 368 strictly required, even if it is beyond the capabilities of a client 369 to completely validate a given certification path, the client may be 370 able to validate the server's certificate by relying on a trusted 371 certification authority whose certificate appears as one of the 372 intermediate certificates in the certification path.) 374 Likewise, this specification does not impose restrictions on 375 signature schemes used in the certification path for the client's 376 certificate when mutual authentication is employed. 378 4.4. signature_algorithms extension 380 The signature_algorithms extension is defined in Section 7.4.1.4.1 of 381 TLS version 1.2 [RFC5246]. A Suite B compliant TLS version 1.2 or 382 later client MUST include the signature_algorithms extension. For 383 the 128 bit security level, SHA-256 with ECDSA MUST be offered in the 384 signature_algorithms extension. For the 192 bit security level, SHA- 385 384 with ECDSA MUST be offered in the signature_algorithms extension. 386 Other offerings MAY be included to indicate the signature algorithms 387 that are acceptable in cipher suites that are offered for 388 interoperability with servers that are not compliant with Suite B and 389 to indicate the signature algorithms that are acceptable for 390 certification path validation. 392 4.5. CertificateRequest message 394 A Suite B compliant TLS version 1.2 or later server MUST include SHA- 395 256 with ECDSA and/or SHA-384 with ECDSA in the 396 supported_signature_algorithms field of the CertificateRequest 397 message. For the 128 bit security level, SHA-256 with ECDSA MUST 398 appear in the supported_signature_algorithms field. For the 192 bit 399 security level, SHA-384 with ECDSA MUST appear in the 400 supported_signature_algorithms field. 402 4.6. CertificateVerify message 404 A Suite B compliant TLS version 1.2 or later client MUST use SHA-256 405 with ECDSA or SHA-384 with ECDSA for the signature in the 406 CertificateVerify message. For the 128 bit security level, SHA-256 407 with ECDSA MUST be used. For the 192 bit security level, SHA-384 408 with ECDSA MUST be used. 410 4.7. ServerKeyExchange message signature 412 In the TLS_ECDHE_ECDSA-collection of cipher suites, the server sends 413 its ephemeral ECDH public key and a specification of the 414 corresponding curve in the ServerKeyExchange message. These 415 parameters MUST be signed with ECDSA using the private key 416 corresponding to the public key in the server's Certificate. 418 A TLS version 1.1 or earlier server MUST sign the ServerKeyExchange 419 message using SHA-1 with ECDSA. 421 A Suite B compliant TLS version 1.2 or later server MUST sign the 422 ServerKeyExchange message using either SHA-256 with ECDSA or SHA-384 423 with ECDSA. For the 128 bit security level, SHA-256 with ECDSA MUST 424 be used. For the 192 bit security level, SHA-384 with ECDSA MUST be 425 used. 427 5. Security Considerations 429 Most of the security considerations for this document are described 430 in TLS 1.2 [RFC5246], Elliptic Curve Cryptography (ECC) Cipher Suites 431 for TLS [RFC4492], AES-GCM Cipher Suites for TLS [RFC5288], and TLS 432 ECC Cipher Suites with SHA-256/384 and AES-GCM [RFC5289]. Readers 433 should consult those documents. 435 In order to meet the goal of a consistent security level for the 436 entire cipher suite, in Suite B mode TLS implementations MUST ONLY 437 use the curves defined in Section 4.2. Otherwise, it is possible to 438 have a set of symmetric algorithms with much weaker or stronger 439 security properties than the asymmetric (ECC) algorithms. 441 6. IANA Considerations 443 This document defines no actions for IANA. 445 7. Acknowledgements 447 Thanks to Pasi Eronen, Steve Hanna, and Paul Hoffman for their 448 review, comments, and insightful suggestions. 450 This work was supported by the US Department of Defense. 452 8. References 454 8.1. Normative References 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 460 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 461 for Transport Layer Security (TLS)", RFC 4492, May 2006. 463 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 464 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 466 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 467 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 468 August 2008. 470 [AES] National Institute of Standards and Technology, 471 "Specification for the Advanced Encryption Standard 472 (AES)", FIPS 197, November 2001. 474 [DSS] National Institute of Standards and Technology, "Digital 475 Signature Standard", FIPS 186-2, January 2000. 477 [PWKE] National Institute of Standards and Technology, 478 "Recommendation for Pair-Wise Key Establishment Schemes 479 Using Discrete Logarithm Cryptography (Revised)", NIST 480 Special Publication 800-56A, March 2007. 482 [SHS] National Institute of Standards and Technology, "Secure 483 Hash Standard", FIPS 180-2, August 2002. 485 8.2. Informative References 487 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 488 RFC 2246, January 1999. 490 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 491 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 493 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 494 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 495 August 2008. 497 [NSA] National Security Agency, "Fact Sheet NSA Suite B 498 Cryptography", 499 . 501 Authors' Addresses 503 Margaret Salter 504 National Security Agency 505 9800 Savage Rd. 506 Fort Meade 20755-6709 507 USA 509 Email: msalter@restarea.ncsc.mil 511 Eric Rescorla 512 Network Resonance 513 2064 Edgewood Drive 514 Palo Alto 94303 515 USA 517 Email: ekr@rtfm.com 519 Russ Housley 520 Vigil Security 521 918 Spring Knoll Drive 522 Herndon 21070 523 USA 525 Email: housley@vigilsec.com 527 Full Copyright Statement 529 Copyright (C) The IETF Trust (2008). 531 This document is subject to the rights, licenses and restrictions 532 contained in BCP 78, and except as set forth therein, the authors 533 retain all their rights. 535 This document and the information contained herein are provided on an 536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 538 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 539 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 540 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 543 Intellectual Property 545 The IETF takes no position regarding the validity or scope of any 546 Intellectual Property Rights or other rights that might be claimed to 547 pertain to the implementation or use of the technology described in 548 this document or the extent to which any license under such rights 549 might or might not be available; nor does it represent that it has 550 made any independent effort to identify any such rights. Information 551 on the procedures with respect to rights in RFC documents can be 552 found in BCP 78 and BCP 79. 554 Copies of IPR disclosures made to the IETF Secretariat and any 555 assurances of licenses to be made available, or the result of an 556 attempt made to obtain a general license or permission for the use of 557 such proprietary rights by implementers or users of this 558 specification can be obtained from the IETF on-line IPR repository at 559 http://www.ietf.org/ipr. 561 The IETF invites any interested party to bring to its attention any 562 copyrights, patents or patent applications, or other proprietary 563 rights that may cover technology that may be required to implement 564 this standard. Please address the information to the IETF at 565 ietf-ipr@ietf.org.