idnits 2.17.1 draft-salter-rfc5430bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC5430, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 30, 2011) is 4554 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** 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) -- Obsolete informational reference (is this intentional?): RFC 5430 (Obsoleted by RFC 6460) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Salter 3 Obsoletes: RFC 5430 (if approved) National Security Agency 4 Intended Status: Informational R. Housley 5 Vigil Security 6 September 30, 2011 8 Suite B Profile for Transport Layer Security (TLS) 9 11 Abstract 13 The United States government has published guidelines for "NSA Suite 14 B Cryptography" that defines cryptographic algorithm policy for 15 national security applications. This document defines a profile of 16 Transport Layer Security (TLS) version 1.2 that is fully compliant 17 with Suite B. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 2 April 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction ...................................................3 66 2. Conventions Used in This Document ..............................3 67 3. Suite B Requirements ...........................................4 68 3.1. Minimum Levels of Security (minLOS).......................4 69 3.2. Suite B TLS Authentication................................5 70 4. Suite B Compliance and Interoperability Requirements ...........6 71 4.1. Acceptable Curves .........................................7 72 4.2. Certificates ..............................................8 73 4.3. signature_algorithms Extension ............................8 74 4.4. CertificateRequest Message ................................8 75 4.5. CertificateVerify Message .................................9 76 4.6. ServerKeyExchange Message Signature .......................9 77 5. Security Considerations ........................................9 78 6. Acknowledgements ...............................................9 79 7. IANA Considerations ...........................................10 80 8. References ....................................................10 81 8.1. Normative References .....................................10 82 8.2. Informative References ...................................10 83 9. Annex: A Transitional Suite B Profile .........................11 85 1. Introduction 87 This document specifies the conventions for using National Security 88 Agency (NSA) Suite B Cryptography [SuiteB] with the Transport Layer 89 Security (TLS) protocol and the Datagram Transport Layer Security 90 (DTLS) protocol. 92 This document does not define any new cipher suites; instead, it 93 defines a Suite B compliant profile for use with TLS version 1.2 94 [RFC5246] or DTLS version 1.2 [4347bis] and the cipher suites defined 95 in [RFC5289]. This profile uses only Suite B algorithms. 97 RFC 5430 defined an additional transitional profile for use with TLS 98 versions 1.0 [RFC2246] and 1.1 [RFC4346] or DTLS version 1.0 99 [RFC4347] and the cipher suites defined in [RFC4492]. When either 100 the client or the server does not support TLS version 1.2 and DTLS 101 version 1.2, the transitional profile can be used to achieve 102 non-Suite-B-compliant interoperability. The description for the 103 transitional profile appears in the Annex of this document. 105 2. Conventions Used in This Document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 We will use the notation "ECDSA-256" to represent the use of the 112 ECDSA algorithm with the P-256 curve and the SHA-256 hash function. 113 Similarly, "ECDSA-384" will represent the use of the ECDSA algorithm 114 with the P-384 curve and the SHA-384 hash function. 116 3. Suite B Requirements 118 The Fact Sheet on Suite B Cryptography requires key establishment and 119 authentication algorithms based on Elliptic Curve Cryptography and 120 encryption using AES [AES]. Suite B algorithms are defined to 121 support two minimum levels of security: 128 and 192 bits. 123 In particular, Suite B includes: 125 Encryption: Advanced Encryption Standard (AES) [AES] -- 126 FIPS 197 (with key sizes of 128 and 256 bits) 128 Digital Signature: Elliptic Curve Digital Signature Algorithm 129 (ECDSA) [DSS] - FIPS 186-3 (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 134 the curves with 256- and 384-bit prime moduli) 136 The two elliptic curves used in Suite B each appear in the literature 137 under two different names. For sake of clarity, we list both names 138 below: 140 Curve NIST name [SECG] name 141 -------------------------------- 142 P-256 nistp256 secp256r1 143 P-384 nistp384 secp384r1 145 The purpose of this document is to specify the requirements for a 146 Suite B Compliant implementation of TLS (hereafter referred to as 147 Suite B TLS). 149 3.1. Minimum Levels of Security (minLOS) for Suite B TLS 151 Suite B provides two levels of cryptographic security, namely a 152 128-bit minimum level of security (minLOS_128) and a 192-bit minimum 153 level of security (minLOS_192). Each level defines a minimum 154 strength that all cryptographic algorithms must provide. 156 The following combination of algorithms and key sizes are used in 157 Suite B TLS: 159 Suite B Combination 1 Suite B Combination 2 160 -------------------------------- -------------------------------- 161 AES with 128-bit key in GCM mode AES with 256-bit key in GCM mode 162 ECDH using the 256-bit prime ECDH using the 384-bit prime 163 modulus curve P-256 [DSS] modulus curve P-384 [DSS] 164 TLS PRF with SHA-256 [SHS] TLS PRF with SHA-384 [SHS] 166 Suite B TLS configured at a minimum level of security of 128 bits 167 MUST use a TLS cipher suite satisfying either 169 SuiteB_Combination_1 in its entirety or SuiteB_Combination_2 in its 170 entirety. 172 Suite B TLS configured at a minimum level of security of 192 bits 173 MUST use a TLS cipher suite satisfying SuiteB_Combination_2 in its 174 entirety. 176 The specific Suite B compliant cipher suites for each combination are 177 listed in Section 4. 179 For Suite B TLS, ECDH uses the Ephemeral Unified Model Scheme with 180 cofactor set to 1 (see Section 6.1.2.2 in [PWKE]). 182 To accommodate backward compatibility, a Suite B TLS client or server 183 MAY be configured to accept a cipher suite that is not part of Suite 184 B. However, whenever a Suite B TLS client and a Suite B TLS server 185 establish a TLS version 1.2 session, Suite B algorithms MUST be 186 employed. 188 3.2 Suite B TLS Authentication 190 Suite B TLS MUST use ECDSA for digital signatures; authentication 191 methods other than ECDSA-256 and ECDSA-384 MUST NOT be used for TLS 192 authentication. If a relying party receives a signature based on any 193 other authentication method, it MUST return a TLS error and stop the 194 TLS handshake. 196 A system compliant with the Suite B TLS and configured at a minimum 197 level of security of 128 bits MUST use either ECDSA-256 or ECDSA-384 198 for client or server authentication. One party can authenticate with 199 ECDSA-256 when the other party authenticates with ECDSA-384. This 200 flexibility allows interoperation between a client and a server that 201 have ECDSA authentication keys of different sizes. 203 Clients and servers in a system configured at a minimum level of 204 security of 128 bits MUST be able to verify ECDSA-256 signatures and 205 SHOULD be able to verify ECDSA-384 signatures unless it is absolutely 206 certain that the implementation will never need to verify 207 certificates originating from an authority which uses an ECDSA-384 208 signing key. 210 A system compliant with the Suite B TLS and configured at a minimum 211 level of security of 192 bits MUST use ECDSA-384 for client and 212 server authentication. 214 Clients and servers in a system configured at a minimum level of 215 security of 192 bits MUST be able to verify ECDSA-384 signatures. 217 In all cases, the client MUST authenticate the server. The server 218 MAY authenticate the client, as needed by the specific application. 220 4. Suite B Compliance and Interoperability Requirements 222 TLS versions 1.1 [RFC4346] and earlier do not support Galois 223 CounterMode (GCM) cipher suites [RFC5289]. However, TLS version 1.2 224 [RFC5246] and later do support GCM. For Suite B TLS, GCM cipher 225 suites MUST be used, therefore a Suite B TLS client MUST implement 226 TLS version 1.2 or later. 228 A Suite B TLS client configured at a minimum level of security of 128 229 bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the 230 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuite in the 231 ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 232 ciphersuite is preferred and if offered, MUST appear before the 233 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuite. 235 If configured at a minimum level of security of 192 bits, the client 236 MUST offer the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ciphersuite 237 and MUST NOT offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 238 ciphersuite. 240 One of these two cipher suites MUST be the first (most preferred) 241 cipher suites in the ClientHello message. A Suite B TLS client that 242 offers interoperability with non-Suite B compliant servers MAY offer 243 additional cipher suites, but any additional cipher suites MUST 244 appear after the two Suite B compliant cipher suites in the 245 ClientHello message. 247 A Suite B TLS server MUST implement TLS version 1.2 or later. 249 A Suite B TLS server configured at a minimum level of security of 128 250 bits MUST accept either the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 251 cipher suite or the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher 252 suite if it is offered in the ClientHellomessage, with the 253 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite being preferred. 255 A Suite B TLS server configured at a minimum security level of 192 256 bits MUST accept the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher 257 suite if it is offered in the ClientHello message. 259 If the server is not offered either of the Suite B cipher suites and 260 interoperability with non-Suite B compliant clients is desired, then 261 the Suite B TLS server MAY accept another offered cipher suite that 262 is considered acceptable by the server administrator. 264 4.1. Acceptable Curves 266 RFC 4492 defines a variety of elliptic curves. Suite B TLS 267 connections MUST use secp256r1(23) or secp384r1(24). These are the 268 same curves that appear in FIPS 186-3 [DSS] as P-256 and P-384, 269 respectively. Secp256r1 MUST be used for the key exchange in all 270 cipher suites in this specification using AES-128; secp384r1 MUST be 271 used for the key exchange in all cipher suites in this specification 272 using AES-256. RFC 4492 requires that the uncompressed(0) form be 273 supported. The ansiX962_compressed_prime(1) point format MAY also be 274 supported. 276 Clients desiring to negotiate only a Suite B TLS connection MUST 277 generate a "Supported Elliptic Curves Extension" containing only the 278 allowed curves. Clients operating at a minimum level of security of 279 128 bits MUST include secp256r1 and SHOULD include secp384r1 in the 280 extension. Clients operating at a minimum level of security of 192 281 bits MUST include secp384r1 in the extension. In order to be able to 282 verify ECDSA signatures, a client and server in a system configured 283 at a minimum level of security of 128 bits MUST support secp256r1 and 284 SHOULD support secp384r1 unless it is absolutely certain that the 285 client and server will never need to use or verify certificates 286 originating from an authority which uses an ECDSA-384 signing key. A 287 client and server in a system configured at a minimum level of 192 288 bits MUST support secp384r1. 290 TLS connections that offer both Suite B and non-Suite B compliant 291 options MAY omit the extension or they MAY send the extension but 292 offer other curves as well as the appropriate Suite B ones. 294 Servers desiring to negotiate a Suite B TLS connection SHOULD check 295 for the presence of the extension, but MUST NOT select a non-Suite B 296 curve even if it is offered by the client. This allows a client that 297 is willing to do either Suite B or non-Suite B TLS connections to 298 interoperate with a server that will only do Suite B TLS. If the 299 client does not advertise an acceptable curve, the server MUST 300 generate a fatal "handshake_failure" alert and terminate the 301 connection. Clients MUST check the chosen curve to make sure that it 302 is one of the Suite B curves. 304 4.2. Certificates 306 Server and client certificates used to establish a Suite B TLS 307 connection MUST be signed with ECDSA and MUST be compliant with the 308 "Suite B Certificate and Certificate Revocation List (CRL) Profile", 309 [RFC5759]. 311 4.3. signature_algorithms Extension 313 The signature_algorithms extension is defined in Section 7.4.1.4.1 of 314 TLS version 1.2 [RFC5246]. A Suite B TLS version 1.2 or later client 315 MUST include the signature_algorithms extension. A Suite B TLS client 316 configured at a minimum level of security of 128 bits MUST offer 317 SHA-256 with ECDSA and SHOULD offer ECDSA with SHA-384 in the 318 signature_algorithms extension unless it is absolutely certain that a 319 client will never need to use or verify certificates originating from 320 an authority which uses an ECDSA-384 signing key. A Suite B TLS 321 client configured at a minimum level of 192 bits MUST offer ECDSA 322 with SHA-384 in the signature_algorithms extension. 324 Following the guidance in [RFC5759], Suite B TLS connections MUST 325 only accept signature algorithms ECDSA with either SHA-256 or SHA-384 326 for certification path validation. (Note that this is a change from 327 [RFC5430].) 329 Other offerings MAY be included to indicate the signature algorithms 330 that are acceptable in cipher suites that are offered for 331 interoperability with servers that are not compliant with Suite B and 332 to indicate the signature algorithms that are acceptable for 333 certification path validation in non-compliant Suite B TLS 334 connections. 336 4.4. CertificateRequest Message 338 A Suite B TLS server configured at a minimum level of security of 128 339 bits MUST include ECDSA with SHA-256 and SHOULD include ECDSA with 340 SHA-384 in the supported_signature_algorithms field of the 341 CertificateRequest message unless it is absolutely certain that a 342 server will never need to verify certificates originating from an 343 authority which uses an ECDSA-384 signing key. A Suite B TLS server 344 configured at a minimum level of security of 192 bits MUST include 345 ECDSA with SHA-384 in the supported_signature_algorithms field. 347 4.5. CertificateVerify Message 349 Using the definitions found in section 3.2, a Suite B TLS client MUST 350 use ECDSA-256 or ECDSA-384 for the signature in the CertificateVerify 351 message. A Suite B TLS client configured at a minimum level of 352 security of 128 bits MUST use ECDSA-256 or ECDSA-384. A Suite B TLS 353 client configured at a minimum level of security of 192 bits MUST use 354 ECDSA-384. 356 4.6. ServerKeyExchange Message Signature 358 In the TLS_ECDHE_ECDSA-collection of cipher suites, the server sends 359 its ephemeral ECDH public key and a specification of the 360 corresponding curve in the ServerKeyExchange message. These 361 parameters MUST be signed with ECDSA using the server's private key, 362 which corresponds to the public key in the server's certificate. 364 A Suite B TLS server MUST sign the ServerKeyExchange message using 365 either ECDSA-256 or ECDSA-384. A system configured at a minimum 366 level of security of 128 bits MUST use either ECDSA-256 or ECDSA-384. 367 A system configured at a minimum level of security of 192-bits MUST 368 use ECDSA-384. 370 5. Security Considerations 372 Most of the security considerations for this document are described 373 in "The Transport Layer Security (TLS) Protocol Version 1.2" 374 [RFC5246], "Elliptic Curve Cryptography (ECC) Cipher Suites for 375 Transport Layer Security (TLS)" [RFC4492], "AES Galois Counter Mode 376 (GCM) Cipher Suites for TLS" [RFC5288], and "TLS Elliptic Curve 377 Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)" 378 [RFC5289]. Readers should consult those documents. 380 In order to meet the goal of a consistent security level for the 381 entire cipher suite, Suite B TLS implementations MUST ONLY use the 382 curves defined in Section 4.2. Otherwise, it is possible to have a 383 set of symmetric algorithms with much weaker or stronger security 384 properties than the asymmetric (ECC) algorithms. 386 6. Acknowledgements 388 The authors would like to thank Eric Rescorla for his work on the 389 original RFC 5430. 391 This work was supported by the US Department of Defense. 393 7. IANA Considerations 395 None. 397 {{{ RFC Editor, please remove this section prior to publication. }}} 399 8. References 401 8.1. Normative References 403 [4347bis] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 404 Security version 1.2", draft-ietf-tls-rfc4347-bis, July 405 2010. 407 [AES] National Institute of Standards and Technology, 408 "Specification for the Advanced Encryption Standard 409 (AES)", FIPS 197, November 2001. 411 [DSS] National Institute of Standards and Technology, "Digital 412 Signature Standard", FIPS 186-3, June 2009. 414 [PWKE] National Institute of Standards and Technology, 415 "Recommendation for Pair-Wise Key Establishment Schemes 416 Using Discrete Logarithm Cryptography (Revised)", NIST 417 Special Publication 800-56A, March 2007. 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, March 1997. 422 [RFC4347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer 423 Security", RFC 4347, April 2006. 425 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 426 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 427 for Transport Layer Security (TLS)", RFC 4492, May 2006. 429 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 430 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 432 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 433 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 434 August 2008. 436 [RFC5759] Solinas, J. and Zieglar L., "Suite B Certificate and 437 Certificate Revocation List (CRL) Profile", RFC 5759, 438 February 2010. 440 [SHS] National Institute of Standards and Technology, "Secure 441 Hash Standard", FIPS 180-3,October 2008. 443 8.2. Informative References 445 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 446 RFC 2246,February 1999. 448 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 449 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 451 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 452 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 453 August 2008. 455 [RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile 456 for Transport Layer Security (TLS)", RFC 5430, March 2009. 458 [SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain 459 Parameters", 460 http://www.secg.org/download/aid-784/sec2-v2.pdf, February 461 2010. 463 [SuiteB] National Security Agency, "Fact Sheet NSA Suite B 464 Cryptography",February 2009, 465 http://www.nsa.gov/ia/programs/suiteb_cryptography/. 467 9. Annex: A Transitional Suite B Profile for TLS 1.1 and 1.0 469 A transitional profile is described for use with TLS version 1.0 470 [RFC2246], TLS version 1.1 [RFC4346], or DTLS version 1.0 [RFC4347] 471 and the cipher suites defined in [RFC4492]. This profile uses the 472 Suite B cryptographic algorithms to the greatest extent possible and 473 provides backward compatibility. While the transitional profile is 474 not a Suite B Compliant implementation of TLS, it provides a 475 transitional path towards the Suite B compliant Profile. 477 The following combination of algorithms and key sizes are defined for 478 use with the Suite B TLS transitional profile: 480 Transitional Suite B Combination 1 Transitional Suite B Combination 2 481 ---------------------------------- ---------------------------------- 482 AES with 128-bit key in CBC mode AES with 256-bit key in CBC mode 483 ECDH using the 256-bit prime ECDH using the 384-bit prime 484 modulus curve P-256 [DSS] modulus curve P-384 [DSS] 485 Standard TLS PRF Standard TLS PRF 486 (with SHA-1 and MD5) (with SHA-1 and MD5) 487 HMAC with SHA-1 for message HMAC with SHA-1 for message 488 authentication authentication 490 A Transitional Suite B TLS system configured at a minimum level of 491 security of 128 bits MUST use a TLS cipher suite satisfying either 492 Transitional Suite B Combination 1 in its entirety or Transitional 493 Suite B Combination 2 in its entirety. 495 A Transitional Suite B TLS system configured at a minimum level of 496 security of 192 bits MUST use a TLS cipher suite satisfying 497 Transitional Suite B Combination 2 in its entirety. 499 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA and 500 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA satisfy the requirements of 501 Transitional Suite B Combination 1 and Transitional Suite B 502 Combination 2, respectively. 504 A Transitional Suite B TLS client MUST implement TLS version 1.1 or 505 earlier. 507 A Transitional Suite B TLS system configured at a minimum level of 508 security of 128 bits, MUST offer the 509 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite and/or the 510 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite in the 512 ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher 513 suite is preferred, and if it is offered, it MUST appear before the 514 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite (if present). 516 A Transitional Suite B TLS system configured at a minimum level of 517 security of 192 bits MUST offer the 518 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite in the ClientHello 519 message. 521 One of these Transitional Suite B cipher suites MUST be the first 522 (most preferred) in the ClientHello message. 524 A Transitional Suite B client that offers interoperability with 525 non-Suite B transitional servers MAY offer additional cipher suites. 526 If any additional cipher suites are offered, they MUST appear after 527 the Transitional Suite B cipher suites in the ClientHello message. 529 A Transitional Suite B TLS server MUST implement TLS version 1.1 or 530 earlier. 532 A Transitional Suite B TLS server configured at a minimum level of 533 security of 128 bits MUST accept the 534 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite (preferred) or the 535 TLS_ECHDE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if offered in the 536 ClientHello message. 538 A Transitional Suite B TLS server configured at a minimum level of 539 security of 192 bits MUST accept the 540 TLS_ECHDE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if offered in the 541 ClientHello message. 543 If a Transitional Suite B TLS server is not offered the Transitional 544 Suite B cipher suites and interoperability with non-Transitional 545 Suite B clients is desired, then the server MAY accept another 546 offered cipher suite that is considered acceptable by the server 547 administrator. 549 A Transitional Suite B TLS server MUST sign the ServerKeyExchange 550 message using ECDSA with SHA-1. The Transitional Suite B profile 551 does not impose any additional restrictions on the server certificate 552 signature or the signature schemes used elsewhere in the 553 certification path. Likewise, the Transitional Suite B Profile does 554 not impose restrictions on signature schemes used in the 555 certification path for the client's certificate when mutual 556 authentication is employed. 558 Authors' Addresses 560 Margaret Salter 561 National Security Agency 562 9800 Savage Rd. 563 Fort Meade 20755-6709 564 USA 565 EMail: msalter@restarea.ncsc.mil 567 Russ Housley 568 Vigil Security 569 918 Spring Knoll Drive 570 Herndon 21070 571 USA 572 EMail: housley@vigilsec.com