summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6460.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6460.txt')
-rw-r--r--doc/rfc/rfc6460.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc6460.txt b/doc/rfc/rfc6460.txt
new file mode 100644
index 0000000..5c5512f
--- /dev/null
+++ b/doc/rfc/rfc6460.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Salter
+Request for Comments: 6460 National Security Agency
+Obsoletes: 5430 R. Housley
+Category: Informational Vigil Security
+ISSN: 2070-1721 January 2012
+
+
+ Suite B Profile for Transport Layer Security (TLS)
+
+Abstract
+
+ The United States government has published guidelines for "NSA Suite
+ B Cryptography" that define cryptographic algorithm policy for
+ national security applications. This document defines a profile of
+ Transport Layer Security (TLS) version 1.2 that is fully compliant
+ with Suite B.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6460.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Salter & Housley Informational [Page 1]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions Used in This Document ...............................3
+ 3. Suite B Requirements ............................................3
+ 3.1. Minimum Levels of Security (minLOS) for Suite B TLS ........4
+ 3.2. Suite B TLS Authentication .................................5
+ 4. Suite B Compliance and Interoperability Requirements ............5
+ 4.1. Acceptable Curves ..........................................6
+ 4.2. Certificates ...............................................7
+ 4.3. signature_algorithms Extension .............................7
+ 4.4. CertificateRequest Message .................................8
+ 4.5. CertificateVerify Message ..................................8
+ 4.6. ServerKeyExchange Message Signature ........................8
+ 5. Security Considerations .........................................8
+ 6. Acknowledgments .................................................9
+ 7. References ......................................................9
+ 7.1. Normative References .......................................9
+ 7.2. Informative References ....................................10
+ Annex A. A Transitional Suite B Profile for TLS 1.1 and 1.0 .......11
+ Annex B. Changes since RFC 5430 ...................................13
+
+1. Introduction
+
+ This document specifies the conventions for using National Security
+ Agency (NSA) Suite B Cryptography [SuiteB] with the Transport Layer
+ Security (TLS) protocol, and the Datagram Transport Layer Security
+ (DTLS) protocol.
+
+ This document does not define any new cipher suites; instead, it
+ defines a Suite B compliant profile for use with TLS version 1.2
+ [RFC5246], DTLS version 1.2 [RFC6347], and the cipher suites defined
+ in [RFC5289]. This profile uses only Suite B algorithms.
+
+
+
+
+
+
+Salter & Housley Informational [Page 2]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+ RFC 5430 defined an additional transitional profile for use with TLS
+ versions 1.0 [RFC2246] and 1.1 [RFC4346] or with DTLS version 1.0
+ [RFC4347] and the cipher suites defined in [RFC4492]. When either
+ the client or the server does not support TLS version 1.2 and DTLS
+ version 1.2, the transitional profile can be used to achieve
+ interoperability that is not Suite B compliant. The description for
+ the transitional profile appears in Annex A of this document.
+
+2. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ We will use the notation "ECDSA-256" to represent the use of the
+ Elliptic Curve Digital Signature Algorithm (ECDSA) with the P-256
+ curve and the SHA-256 hash function. Similarly, "ECDSA-384" will
+ represent the use of the ECDSA with the P-384 curve and the SHA-384
+ hash function.
+
+3. Suite B Requirements
+
+ The Fact Sheet on Suite B Cryptography requires key establishment and
+ authentication algorithms based on Elliptic Curve Cryptography and
+ encryption using AES [AES]. Suite B algorithms are defined to
+ support two minimum levels of security: 128 and 192 bits.
+
+ In particular, Suite B includes the following:
+
+ Encryption: Advanced Encryption Standard (AES) [AES] --
+ FIPS 197 (with key sizes of 128 and 256 bits)
+
+ Digital Signature: Elliptic Curve Digital Signature Algorithm
+ (ECDSA) [DSS] - FIPS 186-3 (using the curves
+ with 256- and 384-bit prime moduli)
+
+ Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) - NIST
+ Special Publication 800-56A [PWKE] (using the
+ curves with 256- and 384-bit prime moduli)
+
+ The two elliptic curves used in Suite B each appear in the literature
+ under two different names. For sake of clarity, we list both names
+ below:
+
+ Curve NIST name [SECG] name
+ --------------------------------
+ P-256 nistp256 secp256r1
+ P-384 nistp384 secp384r1
+
+
+
+Salter & Housley Informational [Page 3]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+ The purpose of this document is to specify the requirements for a
+ Suite B compliant implementation of TLS (hereafter referred to as
+ "Suite B TLS").
+
+3.1. Minimum Levels of Security (minLOS) for Suite B TLS
+
+ Suite B provides two levels of cryptographic security, namely a
+ 128-bit minimum level of security (minLOS_128) and a 192-bit minimum
+ level of security (minLOS_192). Each level defines a minimum
+ strength that all cryptographic algorithms must provide.
+
+ The following combination of algorithms and key sizes are used in
+ Suite B TLS:
+
+ Suite B Combination 1 Suite B Combination 2
+ -------------------------------- --------------------------------
+ AES with 128-bit key in GCM mode AES with 256-bit key in GCM mode
+ ECDH using the 256-bit prime ECDH using the 384-bit prime
+ modulus curve P-256 [DSS] modulus curve P-384 [DSS]
+ TLS PRF with SHA-256 [SHS] TLS PRF with SHA-384 [SHS]
+
+ Suite B TLS configured at a minimum level of security of 128 bits
+ MUST use a TLS cipher suite satisfying either SuiteB_Combination_1 in
+ its entirety or SuiteB_Combination_2 in its entirety.
+
+ Suite B TLS configured at a minimum level of security of 192 bits
+ MUST use a TLS cipher suite satisfying SuiteB_Combination_2 in its
+ entirety.
+
+ The specific Suite B compliant cipher suites for each combination are
+ listed in Section 4.
+
+ For Suite B TLS, ECDH uses the Ephemeral Unified Model Scheme with
+ cofactor set to 1 (see Section 6.1.2.2 in [PWKE]).
+
+ To accommodate backward compatibility, a Suite B TLS client or server
+ MAY be configured to accept a cipher suite that is not part of Suite
+ B. However, whenever a Suite B TLS client and a Suite B TLS server
+ establish a TLS version 1.2 session, Suite B algorithms MUST be
+ employed.
+
+
+
+
+
+
+
+
+
+
+
+Salter & Housley Informational [Page 4]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+3.2 Suite B TLS Authentication
+
+ Suite B TLS MUST use ECDSA for digital signatures; authentication
+ methods other than ECDSA-256 and ECDSA-384 MUST NOT be used for TLS
+ authentication. If a relying party receives a signature based on any
+ other authentication method, it MUST return a TLS error and stop the
+ TLS handshake.
+
+ A system compliant with the Suite B TLS and configured at a minimum
+ level of security of 128 bits MUST use either ECDSA-256 or ECDSA-384
+ for client or server authentication. One party can authenticate with
+ ECDSA-256 when the other party authenticates with ECDSA-384. This
+ flexibility allows interoperation between a client and a server that
+ have ECDSA authentication keys of different sizes.
+
+ Clients and servers in a system configured at a minimum level of
+ security of 128 bits MUST be able to verify ECDSA-256 signatures and
+ SHOULD be able to verify ECDSA-384 signatures unless it is absolutely
+ certain that the implementation will never need to verify
+ certificates originating from an authority that uses an ECDSA-384
+ signing key.
+
+ A system compliant with the Suite B TLS and configured at a minimum
+ level of security of 192 bits MUST use ECDSA-384 for client and
+ server authentication.
+
+ Clients and servers in a system configured at a minimum level of
+ security of 192 bits MUST be able to verify ECDSA-384 signatures.
+
+ In all cases, the client MUST authenticate the server. The server
+ MAY authenticate the client, as needed by the specific application.
+
+4. Suite B Compliance and Interoperability Requirements
+
+ TLS versions 1.1 [RFC4346] and earlier do not support Galois/ Counter
+ Mode (GCM) cipher suites [RFC5289]. However, TLS version 1.2
+ [RFC5246] and later do support GCM. For Suite B TLS, GCM cipher
+ suites MUST be used; therefore, a Suite B TLS client MUST implement
+ TLS version 1.2 or later.
+
+ A Suite B TLS client configured at a minimum level of security of 128
+ bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the
+ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite in the
+ ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+ cipher suite is preferred; if offered, it MUST appear before the
+ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite.
+
+
+
+
+
+Salter & Housley Informational [Page 5]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+ If configured at a minimum level of security of 192 bits, the client
+ MUST offer the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite
+ and MUST NOT offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher
+ suite.
+
+ One of these two cipher suites MUST be the first (most preferred)
+ cipher suites in the ClientHello message. A Suite B TLS client that
+ offers interoperability with servers that are not Suite B compliant
+ MAY offer additional cipher suites, but any additional cipher suites
+ MUST appear after the two Suite B compliant cipher suites in the
+ ClientHello message.
+
+ A Suite B TLS server MUST implement TLS version 1.2 or later.
+
+ A Suite B TLS server configured at a minimum level of security of 128
+ bits MUST accept either the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+ cipher suite or the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher
+ suite if it is offered in the ClientHello message, with the
+ TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite being preferred.
+
+ A Suite B TLS server configured at a minimum level of security of 192
+ bits MUST accept the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher
+ suite if it is offered in the ClientHello message.
+
+ If the server is not offered either of the Suite B cipher suites, and
+ interoperability with clients that are not Suite B compliant is
+ desired, then the Suite B TLS server MAY accept another offered
+ cipher suite that is considered acceptable by the server
+ administrator.
+
+4.1. Acceptable Curves
+
+ RFC 4492 defines a variety of elliptic curves. Suite B TLS
+ connections MUST use secp256r1(23) or secp384r1(24). These are the
+ same curves that appear in FIPS 186-3 [DSS] as P-256 and P-384,
+ respectively. Secp256r1 MUST be used for the key exchange in all
+ cipher suites in this specification using AES-128; secp384r1 MUST be
+ used for the key exchange in all cipher suites in this specification
+ using AES-256. RFC 4492 requires that the uncompressed(0) form be
+ supported. The ansiX962_compressed_prime(1) point format MAY also be
+ supported.
+
+ Clients desiring to negotiate only a Suite B TLS connection MUST
+ generate a "Supported Elliptic Curves Extension" containing only the
+ allowed curves. Clients operating at a minimum level of security of
+ 128 bits MUST include secp256r1 and SHOULD include secp384r1 in the
+ extension. Clients operating at a minimum level of security of 192
+ bits MUST include secp384r1 in the extension. In order to be able to
+
+
+
+Salter & Housley Informational [Page 6]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+ verify ECDSA signatures, a client and server in a system configured
+ at a minimum level of security of 128 bits MUST support secp256r1 and
+ SHOULD support secp384r1 unless it is absolutely certain that the
+ client and server will never need to use or verify certificates
+ originating from an authority which uses an ECDSA-384 signing key. A
+ client and server in a system configured at a minimum level of 192
+ bits MUST support secp384r1.
+
+ TLS connections that offer options that are both compliant and non-
+ compliant with Suite B MAY omit the extension, or they MAY send the
+ extension but offer other curves as well as the appropriate Suite B
+ ones.
+
+ Servers desiring to negotiate a Suite B TLS connection SHOULD check
+ for the presence of the extension, but they MUST NOT select a curve
+ that is not Suite B even if it is offered by the client. This allows
+ a client that is willing to do either Suite B or non-Suite B TLS
+ connections to interoperate with a server that will only do Suite B
+ TLS. If the client does not advertise an acceptable curve, the
+ server MUST generate a fatal "handshake_failure" alert and terminate
+ the connection. Clients MUST check the chosen curve to make sure
+ that it is one of the Suite B curves.
+
+4.2. Certificates
+
+ Server and client certificates used to establish a Suite B TLS
+ connection MUST be signed with ECDSA and MUST be compliant with the
+ "Suite B Certificate and Certificate Revocation List (CRL) Profile",
+ [RFC5759].
+
+4.3. signature_algorithms Extension
+
+ The signature_algorithms extension is defined in Section 7.4.1.4.1 of
+ TLS version 1.2 [RFC5246]. A Suite B TLS version 1.2 or later client
+ MUST include the signature_algorithms extension. A Suite B TLS
+ client configured at a minimum level of security of 128 bits MUST
+ offer SHA-256 with ECDSA and SHOULD offer ECDSA with SHA-384 in the
+ signature_algorithms extension unless it is absolutely certain that a
+ client will never need to use or verify certificates originating from
+ an authority that uses an ECDSA-384 signing key. A Suite B TLS
+ client configured at a minimum level of 192 bits MUST offer ECDSA
+ with SHA-384 in the signature_algorithms extension.
+
+ Following the guidance in [RFC5759], Suite B TLS connections MUST
+ only accept signature algorithms ECDSA with either SHA-256 or SHA-384
+ for certification path validation. (Note that this is a change from
+ [RFC5430].)
+
+
+
+
+Salter & Housley Informational [Page 7]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+ Other offerings MAY be included to indicate the acceptable signature
+ algorithms in cipher suites that are offered for interoperability
+ with servers not compliant with Suite B and to indicate the signature
+ algorithms that are acceptable for certification path validation in
+ non-compliant Suite B TLS connections.
+
+4.4. CertificateRequest Message
+
+ A Suite B TLS server configured at a minimum level of security of 128
+ bits MUST include ECDSA with SHA-256 and SHOULD include ECDSA with
+ SHA-384 in the supported_signature_algorithms field of the
+ CertificateRequest message unless it is absolutely certain that a
+ server will never need to verify certificates originating from an
+ authority that uses an ECDSA-384 signing key. A Suite B TLS server
+ configured at a minimum level of security of 192 bits MUST include
+ ECDSA with SHA-384 in the supported_signature_algorithms field.
+
+4.5. CertificateVerify Message
+
+ Using the definitions found in Section 3.2, a Suite B TLS client MUST
+ use ECDSA-256 or ECDSA-384 for the signature in the CertificateVerify
+ message. A Suite B TLS client configured at a minimum security level
+ of 128 bits MUST use ECDSA-256 or ECDSA-384. A Suite B TLS client
+ configured at a minimum security level of 192 bits MUST use
+ ECDSA-384.
+
+4.6. ServerKeyExchange Message Signature
+
+ In the TLS_ECDHE_ECDSA-collection of cipher suites, the server sends
+ its ephemeral ECDH public key and a specification of the
+ corresponding curve in the ServerKeyExchange message. These
+ parameters MUST be signed with ECDSA using the server's private key,
+ which corresponds to the public key in the server's certificate.
+
+ A Suite B TLS server MUST sign the ServerKeyExchange message using
+ either ECDSA-256 or ECDSA-384. A system configured at a minimum
+ level of security of 128 bits MUST use either ECDSA-256 or ECDSA-384.
+ A system configured at a minimum level of security of 192-bits MUST
+ use ECDSA-384.
+
+5. Security Considerations
+
+ Most of the security considerations for this document are described
+ in "The Transport Layer Security (TLS) Protocol Version 1.2"
+ [RFC5246], "Elliptic Curve Cryptography (ECC) Cipher Suites for
+ Transport Layer Security (TLS)" [RFC4492], "AES Galois Counter Mode
+
+
+
+
+
+Salter & Housley Informational [Page 8]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+ (GCM) Cipher Suites for TLS" [RFC5288], and "TLS Elliptic Curve
+ Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)"
+ [RFC5289]. Readers should consult those documents.
+
+ In order to meet the goal of a consistent security level for the
+ entire cipher suite, Suite B TLS implementations MUST ONLY use the
+ curves defined in Section 4.1. Otherwise, it is possible to have a
+ set of symmetric algorithms with much weaker or stronger security
+ properties than the asymmetric (ECC) algorithms.
+
+6. Acknowledgments
+
+ The authors would like to thank Eric Rescorla for his work on the
+ original RFC 5430.
+
+ This work was supported by the US Department of Defense.
+
+7. References
+
+7.1. Normative References
+
+ [AES] National Institute of Standards and Technology,
+ "Specification for the Advanced Encryption Standard
+ (AES)", FIPS 197, November 2001.
+
+ [DSS] National Institute of Standards and Technology, "Digital
+ Signature Standard", FIPS 186-3, June 2009.
+
+ [PWKE] National Institute of Standards and Technology,
+ "Recommendation for Pair-Wise Key Establishment Schemes
+ Using Discrete Logarithm Cryptography (Revised)", NIST
+ Special Publication 800-56A, March 2007.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, April 2006.
+
+ [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
+ Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
+ for Transport Layer Security (TLS)", RFC 4492, May 2006.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+
+
+
+
+
+Salter & Housley Informational [Page 9]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+ [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with
+ SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
+ August 2008.
+
+ [RFC5759] Solinas, J. and L. Zieglar, "Suite B Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 5759,
+ January 2010.
+
+ [SHS] National Institute of Standards and Technology, "Secure
+ Hash Standard", FIPS 180-3, October 2008.
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, January 2012.
+
+7.2. Informative References
+
+ [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+ [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
+ Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
+ August 2008.
+
+ [RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile
+ for Transport Layer Security (TLS)", RFC 5430, March 2009.
+
+ [SECG] Brown, D., "SEC 2: Recommended Elliptic Curve Domain
+ Parameters",
+ http://www.secg.org/download/aid-784/sec2-v2.pdf, February
+ 2010.
+
+ [SuiteB] National Security Agency, "Fact Sheet NSA Suite B
+ Cryptography", November 2010,
+ http://www.nsa.gov/ia/programs/suiteb_cryptography/.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salter & Housley Informational [Page 10]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+Annex A. A Transitional Suite B Profile for TLS 1.1 and 1.0
+
+ A transitional profile is described for use with TLS version 1.0
+ [RFC2246], TLS version 1.1 [RFC4346], or DTLS version 1.0 [RFC4347]
+ and the cipher suites defined in [RFC4492]. This profile uses the
+ Suite B cryptographic algorithms to the greatest extent possible and
+ provides backward compatibility. While the transitional profile is
+ not a Suite B Compliant implementation of TLS, it provides a
+ transitional path towards the Suite B compliant Profile.
+
+ The following combination of algorithms and key sizes are defined for
+ use with the Suite B TLS transitional profile:
+
+
+ Transitional Suite B Combination 1 Transitional Suite B Combination 2
+ ---------------------------------- ----------------------------------
+ AES with 128-bit key in CBC mode AES with 256-bit key in CBC mode
+ ECDH using the 256-bit prime ECDH using the 384-bit prime
+ modulus curve P-256 [DSS] modulus curve P-384 [DSS]
+ Standard TLS PRF Standard TLS PRF
+ (with SHA-1 and MD5) (with SHA-1 and MD5)
+ HMAC with SHA-1 for message HMAC with SHA-1 for message
+ authentication authentication
+
+ A Transitional Suite B TLS system configured at a minimum level of
+ security of 128 bits MUST use a TLS cipher suite satisfying either
+ Transitional Suite B Combination 1 in its entirety or Transitional
+ Suite B Combination 2 in its entirety.
+
+ A Transitional Suite B TLS system configured at a minimum level of
+ security of 192 bits MUST use a TLS cipher suite satisfying
+ Transitional Suite B Combination 2 in its entirety.
+
+ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA and
+ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA satisfy the requirements of
+ Transitional Suite B Combination 1 and Transitional Suite B
+ Combination 2, respectively.
+
+ A Transitional Suite B TLS client MUST implement TLS version 1.1 or
+ earlier.
+
+ A Transitional Suite B TLS system configured at a minimum level of
+ security of 128 bits, MUST offer the
+ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite and/or the
+ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite in the
+
+
+
+
+
+
+Salter & Housley Informational [Page 11]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+ ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher
+ suite is preferred; if it is offered, it MUST appear before the
+ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite (if present).
+
+ A Transitional Suite B TLS system configured at a minimum level of
+ security of 192 bits MUST offer the
+ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite in the ClientHello
+ message.
+
+ One of these Transitional Suite B cipher suites MUST be the first
+ (most preferred) in the ClientHello message.
+
+ A Transitional Suite B client that offers interoperability with
+ servers that are not Suite B transitional MAY offer additional cipher
+ suites. If any additional cipher suites are offered, they MUST
+ appear after the Transitional Suite B cipher suites in the
+ ClientHello message.
+
+ A Transitional Suite B TLS server MUST implement TLS version 1.1 or
+ earlier.
+
+ A Transitional Suite B TLS server configured at a minimum level of
+ security of 128 bits MUST accept the
+ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite (preferred) or the
+ TLS_ECHDE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if offered in the
+ ClientHello message.
+
+ A Transitional Suite B TLS server configured at a minimum level of
+ security of 192 bits MUST accept the
+ TLS_ECHDE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if offered in the
+ ClientHello message.
+
+ If a Transitional Suite B TLS server is not offered the Transitional
+ Suite B cipher suites and interoperability with non-Transitional
+ Suite B clients is desired, then the server MAY accept another
+ offered cipher suite that is considered acceptable by the server
+ administrator.
+
+ A Transitional Suite B TLS server MUST sign the ServerKeyExchange
+ message using ECDSA with SHA-1. The Transitional Suite B profile
+ does not impose any additional restrictions on the server certificate
+ signature or the signature schemes used elsewhere in the
+ certification path. Likewise, the Transitional Suite B Profile does
+ not impose restrictions on signature schemes used in the
+ certification path for the client's certificate when mutual
+ authentication is employed.
+
+
+
+
+
+Salter & Housley Informational [Page 12]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+Annex B. Changes since RFC 5430
+
+ The changes from RFC 5430 [RFC5430] are as follows:
+
+ - The transitional profile for use with TLS version 1.0, TLS version
+ 1.1, and DTLS version 1.0 was moved to an annex.
+
+ - The requirement of Section 4 of RFC 5430 that a Suite B TLS 1.2
+ Client offer the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 or
+ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 cipher suites was removed.
+
+ - A Suite B TLS system configured at a minimum level of security of
+ 128 bits MUST use either TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
+ or TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, with the first being
+ preferred.
+
+ - A Suite B TLS system configured at a minimum level of security of
+ 128 bits MUST use either ECDSA on the secp256r1 curve with SHA-256
+ or ECDSA on the secp384r1 curve with SHA-384. One party can
+ authenticate with ECDSA on the secp256r1 curve and SHA-256 when
+ the other party authenticates with ECDSA on the secp384r1 curve
+ and SHA-384.
+
+ - A system desiring to negotiate a Suite B TLS connection at a
+ minimum level of security of 128 bits MUST generate a "Supported
+ Elliptic Curves Extension", MUST include secp256r1 in the
+ extension, and SHOULD include secp384r1 in the extension.
+
+ - A client and server, in order to verify digital signatures in a
+ Suite B TLS system configured at a minimum level of security of
+ 128 bits, MUST support secp256r1 and SHOULD support secp384r1.
+
+ - A Suite B TLS client configured at a minimum level of security of
+ 128 bits MUST offer SHA-256 with ECDSA and SHOULD offer SHA-384
+ with ECDSA in the signature_algorithms extension.
+
+ - Certification path validation MUST only include certificates
+ containing an ECDSA public key on the secp256r1 curve or on the
+ secp384r1 curve. The ECDSA public keys used in the certification
+ path MUST be in non-descending order of size from the end entity
+ public key to the root public key.
+
+ - A Suite B TLS server configured at a minimum level of security of
+ 128 bits MUST include ECDSA with SHA-256 and SHOULD include ECDSA
+ with SHA-384 in the supported_signature_algorithms field of the
+ CertificateRequest message.
+
+
+
+
+
+Salter & Housley Informational [Page 13]
+
+RFC 6460 Suite B for TLS January 2012
+
+
+ - A Suite B TLS client configured at a minimum level of security of
+ 128 bits MUST use ECDSA on the secp256r1 curve and SHA-256 or
+ ECDSA on the secp384r1 curve and SHA-384.
+
+ - A Suite B TLS server configured at a minimum level of security of
+ 128 bits MUST use either ECDSA on the secp256r1 curve and SHA-256
+ or ECDSA on the secp384r1 curve and SHA-384 when signing the
+ ServerKeyExchange message.
+
+Authors' Addresses
+
+ Margaret Salter
+ National Security Agency
+ 9800 Savage Rd.
+ Fort Meade 20755-6709
+ USA
+ EMail: misalte@nsa.gov
+
+ Russ Housley
+ Vigil Security
+ 918 Spring Knoll Drive
+ Herndon 21070
+ USA
+ EMail: housley@vigilsec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salter & Housley Informational [Page 14]
+