TLS Working Group Simon Blake-Wilson INTERNET-DRAFT Tim Dierks Expires: September 14, 2001 Chris Hawk Certicom Corp. 15 March 2001 ECC Cipher Suites for TLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts may be found at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories may be found at http://www.ietf.org/shadow.html. Abstract This document describes additions to TLS to support Elliptic Curve Cryptography (ECC). In particular it defines new key exchange algorithms which use the Elliptic Curve Digital Signature Algorithm (ECDSA) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme (ECDH), and it defines how to perform client authentication with ECDSA and ECDH. 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 RFC 2119 [MUST]. Please send comments on this document to the TLS mailing list. Blake-Wilson, Dierks, Hawk [Page 1] INTERNET-DRAFT 15 March 2001 Table of Contents 1. Introduction ................................................. 2 2. Elliptic Curve Key Exchange Algorithms ....................... 4 2.1. ECDH_ECDSA ................................................... 5 2.2. ECDH_ECDSA_EXPORT ............................................ 5 2.3. ECDH_RSA ..................................................... 6 2.4. ECDH_RSA_EXPORT .............................................. 6 2.5. ECDH_anon .................................................... 6 2.6. ECDH_anon_EXPORT ............................................. 6 3. ECC Client Authentication .................................... 7 3.1. ECDSA_sign ................................................... 7 3.2. ECDSA_fixed_ECDH ............................................. 8 3.3. RSA_fixed_ECDH ............................................... 9 4. Data Structures and Computations ............................. 9 4.1. Server Certificate .......................................... 10 4.2. Server Key Exchange ......................................... 11 4.3. Certificate Request ......................................... 15 4.4. Client Certificate .......................................... 15 4.5. Client Key Exchange ......................................... 16 4.6. Certificate Verify .......................................... 18 4.7. Computing the Master Secret ................................. 19 5. Cipher Suites ............................................... 19 6. Security Considerations ..................................... 20 7. Intellectual Property Rights ................................ 20 8. Acknowledgments ............................................. 21 9. References .................................................. 21 10. Authors' Addresses .......................................... 22 1. Introduction This document describes additions to TLS to support Elliptic Curve Cryptography (ECC). In particular, it defines: - new key exchange algorithms which use the Elliptic Curve Digital Signature Algorithm (ECDSA), and the Elliptic Curve Diffie-Hellman Key Agreement Scheme (ECDH); and - new client authentication methods which use ECDSA and ECDH. In order to enable the use of these features within TLS, the document defines enhanced data structures to convey the information that the mechanisms need to exchange, the computational procedures involved in the operation of the mechanisms, and new cipher suites based on the mechanisms. Blake-Wilson, Dierks, Hawk [Page 2] INTERNET-DRAFT 15 March 2001 Use of ECC within TLS may provide both bandwidth and computational savings compared to other public-key cryptographic techniques. Furthermore, the efficiencies provided by ECC may increase as security requirements increase based on Moore's law - this is illustrated by the following table, based on [LEN], which gives approximate comparable key sizes for symmetric systems, ECC systems, and DH/DSA/RSA systems based on the running times of the best algorithms known today. Symmetric | ECC | DH/DSA/RSA 80 | 163 | 1024 128 | 283 | 3072 192 | 409 | 7680 256 | 571 | 15360 Table 1: Comparable key sizes (in bits) The savings that ECC may offer are likely to become increasingly desirable with the widespread use of TLS by wireless devices - discussed, for example, in [TLS-EXT]. This document assumes the reader is familiar with both ECC and TLS. ECC is described in ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], IEEE 1363 [IEEE1363], and SEC 1 [SEC1]. TLS is described in RFC 2246 [TLS]. The choice of mechanisms included in this document was motivated by a desire to provide mechanisms which are secure, which are as efficient as possible, and which are capable of replicating all of the functionality and operating modes found in the existing TLS mechanisms based on integer factorization and discrete logarithm cryptographic systems. TLS includes a substantial variety of functionality and operating modes in consideration of the variety of applications with which TLS is used. The desire described above led to the inclusion of a substantial number of ECC-based mechanisms. In order to encourage interoperability, a small subset of the mechanisms are identified as "recommended" - these mechanisms are capable of meeting the requirements of many applications and they should therefore be used unless an application profile of this document states otherwise, or unless in a particular environment considerations such as export regulations mandate otherwise. The remainder of this document is organized as follows. Section 2 specifies key exchange algorithms for TLS using ECC. Section 3 specifies how client authentication is performed using ECC. Section 4 describes the TLS-specific data structures and computations involved in the operation of the ECC mechanisms. Section 5 defines cipher suites based on the ECC key exchange algorithms. Sections 6-8 discuss security considerations, intellectual property rights, and acknowledgements Blake-Wilson, Dierks, Hawk [Page 3] INTERNET-DRAFT 15 March 2001 respectively. Section 9 supplies references cited elsewhere in the document, and Section 10 gives the authors' contact details. 2. Elliptic Curve Key Exchange Algorithms This document defines six new key exchange algorithms based on ECC for use within TLS. The table below summarizes the new key exchange algorithms. Key Exchange Algorithm Description Key size limit ECDH_ECDSA ECDH with ECDSA signatures None ECDH_ECDSA_EXPORT ECDH with ECDSA signatures ECDH=163 bits, ECDSA=none ECDH_RSA ECDH with RSA signatures None ECDH_RSA_EXPORT ECDH with RSA signatures ECDH=163 bits, RSA = none ECDH_anon Anonymous ECDH, no signatures None ECDH_anon_EXPORT Anonymous ECDH, no signatures ECDH=163 bits Table 2: Key exchange algorithms Note that the key exchange algorithms marked "anon" do not provide authentication of the server or the client, and, like other "anon" TLS key exchange algorithms, may be subject to man-in-the-middle attacks. Implementations of these algorithms SHOULD provide authentication by other means. The remainder of this section describes these key exchange algorithms in detail. For each key exchange algorithm, this involves specification of the contents of the handshake messages related to key exchange - server certificate, server key exchange, client certificate, and client key exchange - as well as specification of the computations involved in the calculation of the master secret. 2.1. ECDH_ECDSA ECDH is used to compute the master secret. The server is authenticated via a certificate containing an ECDH public key signed with ECDSA. Specifically this key exchange algorithm MUST proceed as follows: - The server provides a static ECDH public key in the server certificate message using the format described in Section 4.1. The certificate is signed using ECDSA. Blake-Wilson, Dierks, Hawk [Page 4] INTERNET-DRAFT 20 January 2000 - The server key exchange message is not sent. - Unless client authentication using ECDH is performed as specified in Sections 3.2 and 3.3, the client provides an ephemeral ECDH public key in the client key exchange message using the format described in Section 4.5. In this case, the client certificate and certificate verify message are not sent unless client authentication is performed using ECDSA as specified in Section 3.1, or another signature algorithm. - If client authentication using ECDH is performed, the client provides a static ECDH public key in the client certificate message using the format described in Section 4.4. In this case an empty client key exchange message is sent using the format described in Section 4.5, and the certificate verify message is not sent. - The client and server compute the master secret using their ECDH key pairs as specified in Section 4.7. ECDH computations for this key exchange algorithm are performed according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation primitive, and the KDF1 key derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are performed according to ANSI X9.62 [ANSIX962] using the hash function SHA-1 [FIPS180-1]. 2.2. ECDH_ECDSA_EXPORT Export-strength ECDH is used to compute the master secret. The server is authenticated via a certificate containing an ECDH public key signed with ECDSA. This key exchange algorithm MUST proceed in the same way as ECDH_ECDSA, except that the key size for ECDH public keys is constrained to 163 bits or less. Here the key size of an elliptic curve public key refers to the size of the underlying finite field over which the elliptic curve is defined. 2.3. ECDH_RSA ECDH is used to compute the master secret. The server is authenticated via a certificate containing an ECDH public key signed with RSA. This key exchange MUST proceed in the same way as ECDH_ECDSA, except that the server's certificate is signed with RSA. Blake-Wilson, Dierks, Hawk [Page 5] INTERNET-DRAFT 15 March 2001 2.4. ECDH_RSA_EXPORT Export-strength ECDH is used to compute the master secret. The server is authenticated via a certificate containing an ECDH public key signed with RSA. This key exchange algorithm MUST proceed in the same way as ECDH_RSA, except that the key size for ECDH public keys is constrained to be 163 bits or less. 2.5. ECDH_anon Anonymous ECDH is used to compute the master secret. Specifically this key exchange algorithm MUST proceed as follows: - The server certificate message is not sent. - The server provides an ephemeral ECDH public key in the server key exchange message using the format described in Section 4.2. - The client certificate message is not sent. - The client provides an ephemeral ECDH public key in the client key exchange message using the format described in Section 4.5. - The client and server compute the master secret using their ECDH key pairs as specified in Section 4.7. ECDH computations for this key exchange algorithm are performed according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation primitive, and the KDF1 key derivation primitive using SHA-1 [FIPS180-1]. 2.6. ECDH_anon_EXPORT Export-strength, anonymous ECDH is used to compute the master secret. This key exchange algorithm MUST proceed in the same way as ECDH_anon, except that the key size for ECDH public keys is constrained to 163 bits or less. 3. ECC Client Authentication This document defines three new ECC-based client authentication methods - ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH. Blake-Wilson, Dierks, Hawk [Page 6] INTERNET-DRAFT 15 March 2001 To encourage interoperability, implementations SHOULD support ECDSA_fixed_ECDH. Implementations MAY support any of the other client authentication methods. The remainder of this section specifies these ECC-based client authentication methods. The following information is provided for each method: which key exchange algorithms the method may be used with, what constraints apply to the method, and the formats of the certificate request, client certificate, client key exchange, and certificate verify messages. 3.1. ECDSA_sign The client supplies a certificate containing an ECDSA public key, and authenticates itself by signing the certificate verify message with its ECDSA key pair. This client authentication method MUST proceed as follows. Applicable key exchange algorithms: - This client authentication method is eligible for use with all the non-anonymous ECC-based key exchange algorithms specified in Section 2, and all the existing non-anonymous TLS key exchange algorithms specified in [TLS]. Restrictions: - In order to perform this method, the client must possess a certified ECDSA public key. Message exchange: - The server requests use of the ECDSA_sign method by sending a certificate request message containing the value "ecdsa_sign" using the format described in Section 4.3. When the client receives this request, it checks that it possesses an appropriate certificate and that it is willing to proceed. - If the client proceeds, it sends its certificate containing its ECDSA public key in the client certificate message using the format described in Section 4.4. It signs the handshake messages exchanged so far with its ECDSA key pair and conveys the resulting signature to the server in the certificate verify message using the format specified in Section 4.6. Blake-Wilson, Dierks, Hawk [Page 7] INTERNET-DRAFT 15 March 2001 - (If the client does not proceed, it may perform client authentication using another method suggested by the server in the certificate request message in which case the client certificate and the certificate verify message are sent in accordance with the selected method, or it may proceed with the key exchange without client authentication - in which case the client certificate and certificate verify messages are not sent.) ECDSA computations for this client authentication method are performed according to ANSI X9.62 [ANSIX962] using the hash function SHA-1 [FIPS180-1]. 3.2. ECDSA_fixed_ECDH The client supplies an ECDSA-signed certificate containing an ECDH public key using the same elliptic curve domain parameters as the server's ECDH public key. The client authenticates itself by computing the master secret and the finished message. (This achieves authentication because these computations can only be performed by a party possessing the private key corresponding to one of the ECDH public keys exchanged.) This client authentication method MUST proceed as follows. Applicable key exchange algorithms: - This method is eligible for use with all the non-anonymous ECC-based key exchange algorithms specified in Section 2. Restrictions: - In order to perform this client authentication method, the client must possess an ECDSA-signed certificate containing an ECDH public key using the same elliptic curve domain parameters as the ECDH public key supplied by the server in the server certificate message. Message exchange: - The server requests use of the ECDSA_fixed_ECDH method by sending a certificate request message containing the value "ecdsa_fixed_ecdh" using the format described in Section 4.3. When the client receives this request, it checks that it possesses an appropriate certificate and that it is willing to proceed. - If the client proceeds, it sends its certificate containing its ECDH public key in the client certificate message using the format described in Section 4.4. It sends an empty client key exchange message using the format described in Section 4.5. It does not send the certificate verify message. It uses its static ECDH key pair, along with the server's ECDH public key) when computing the master secret and finished message. Blake-Wilson, Dierks, Hawk [Page 8] INTERNET-DRAFT 15 March 2001 - (If the client does not proceed, it may perform client authentication using another method suggested by the server in the certificate request message, or it may proceed with the key exchange without client authentication - in which case the client certificate and certificate verify messages are not sent.) ECDH computations for this key exchange algorithm are performed according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation primitive, and the KDF1 key derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are performed according to ANSI X9.62 [ANSIX962] using the hash function SHA-1 [FIPS180-1]. 3.3. RSA_fixed_ECDH The client supplies an RSA-signed certificate containing an ECDH public key using the same elliptic curve domain parameters as the server's ECDH public key. The client authenticates itself by computing the master secret and the finished message. (This achieves authentication because these computations can only be performed by a party possessing the private key corresponding to one of the ECDH public keys exchanged.) This client authentication method MUST proceed in the same manner as the ECDSA_fixed_ECDH method, except that the client's certificate must be signed with RSA, and the server requests use of the method by sending a certificate request message containing the value "rsa_fixed_ecdh". 4. Data Structures and Computations This section specifies the data structures and computations used by the ECC-based mechanisms specified in Sections 2 and 3. The presentation language used here is the same as that used in RFC 2246 [TLS]. Because these specifications extend the TLS protocol specification, these descriptions should be merged with those in TLS and in any other specifications which extend TLS. This means that enum types may not specify all the possible values and structures with multiple formats chosen with a select() clause may not indicate all the possible cases. 4.1. Server Certificate This message is sent in the following key exchange algorithms: All the non-anonymous ECC-based key exchange algorithms specified in Section 2. Blake-Wilson, Dierks, Hawk [Page 9] INTERNET-DRAFT 15 March 2001 Meaning of this message: This message is used to authentically convey the server's static public key to the client. The appropriate certificate types are given in the following table. Key Exchange Algorithm Certificate Type ECDH_ECDSA ECC public key; the certificate must allow the key to be used for key agreement. The certificate must be signed with ECDSA. ECDH_ECDSA_EXPORT ECC public key which can be used for key agreement; key size must be 163 bits or less. Certificate must be signed with ECDSA. ECDH_RSA ECC public key which can be used for key agreement. Certificate must be signed with RSA. ECDH_RSA_EXPORT ECC public key which can be used for key agreement; key size must be 163 bits or less. Certificate must be signed with RSA. Table 3: Server certificate types [PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in X.509 certificates. Servers SHOULD use the elliptic curve domain parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], and SEC 2 [SEC2]. Note that - as with RSA - the same identifier is used for all ECC keys in "SubjectPublicKeyInfo". The key usage extension may be used to further delimit the use of the key. When a key usage extension is present, the "keyAgreement" bit MUST be set for ECDH certificates. Structure of this message: Identical to the TLS Certificate format. Actions of the sender: The server constructs an appropriate certificate chain and conveys it to the client in the Certificate message. Blake-Wilson, Dierks, Hawk [Page 10] INTERNET-DRAFT 15 March 2001 Actions of the receiver: The client validates the certificate chain, extracts the server's public key, and checks that the key is of the correct type for the key exchange algorithm. 4.2. Server Key Exchange This message is sent in the following key exchange algorithms: Both the anonymous ECC-based key exchange algorithms specified in Section 2. Meaning of this message: This message is used to convey the server's ephemeral ECDH public key (and the corresponding elliptic curve domain parameters) to the client. Structure of this message: The TLS ServerKeyExchange message is extended as follows. enum { ec_diffie_hellman } KeyExchangeAlgorithm; ec_diffie_hellman Indicates the ServerKeyExchange message is to contain an ECDH public key. enum { explicit_prime (1), explicit_char2 (2), named_curve (3), (255) } ECCurveType; explicit_prime Indicates the elliptic curve domain parameters will be conveyed verbosely, and that the underlying finite field is a prime field. explicit_char2 Indicates the elliptic curve domain parameters will be conveyed verbosely, and that the underlying finite field is a characteristic 2 field. named_curve Indicates that a named curve will be used. The use of this option is strongly recommended. struct { opaque a <1..2^8-1>; opaque b <1..2^8-1>; opaque seed <0..2^8-1>; } ECCurve; Blake-Wilson, Dierks, Hawk [Page 11] INTERNET-DRAFT 15 March 2001 a, b These parameters specify the coefficients of the elliptic curve. Each value contains the byte string representation of a field element following the conversion routine in [X9.62], section 4.3.3. seed This is an optional parameter used to derive the coefficients of a randomly generated elliptic curve. struct { opaque point <1..2^8-1>; } ECPoint; point This is the byte string representation of an elliptic curve point following the conversion routine in [X9.62], section 4.3.6. enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; ec_basis_trinomial Indicates representation of a characteristic two field using a trinomial basis. ec_basis_pentanomial Indicates representation of a characteristic two field using a pentanomial basis. enum { sect163k1 (1), sect163r1 (2), sect163r2 (3), sect193r1 (4), sect193r2 (5), sect233k1 (6), sect233r1 (7), sect239k1 (8), sect283k1 (9), sect283r1 (10), sect409k1 (11), sect409r1 (12), sect571k1 (13), sect571r1 (14), secp160k1 (15), secp160r1 (16), secp160r2 (17), secp192k1 (18), secp192r1 (19), secp224k1 (20), secp224r1 (21), secp256k1 (22), secp256r1 (23), secp384r1 (24), secp521r1 (25), (255) } NamedCurve; sect163k1, etc Indicates use of the corresponding recommended curve specified in SEC 2 [SEC2]. Note that many of these curves are also recommended in ANSI X9.62 [ANSIX962], and FIPS 186-2 [FIPS186-2]. Blake-Wilson, Dierks, Hawk [Page 12] INTERNET-DRAFT 15 March 2001 struct { ECCurveType curve_type; select (curve_type) { case explicit_prime: opaque prime_p <1..2^8-1>; ECCurve curve; ECPoint base; opaque order <1..2^8-1>; opaque cofactor <1..2^8-1>; case explicit_char2: uint16 m; ECBasisType basis; select (basis) { case ec_trinomial: opaque k <1..2^8-1>; case ec_pentanomial: opaque k1 <1..2^8-1>; opaque k2 <1..2^8-1>; opaque k3 <1..2^8-1>; }; ECCurve curve; ECPoint base; opaque order <1..2^8-1>; opaque cofactor <1..2^8-1>; case named_curve: NamedCurve namedcurve; }; } ECParameters; curve_type This identifies the type of the elliptic curve domain parameters. prime_p This is the odd prime defining the field Fp. curve Specifies the coefficients a and b of the elliptic curve E. base Specifies the base point G on the elliptic curve. order Specifies the order n of the base point. cofactor Specifies the cofactor h = #E(Fq)/n, where #E(Fq) represents the number of points on the elliptic curve E defined over the field Fq. m This is the degree of the characteristic-two field F2^m. Blake-Wilson, Dierks, Hawk [Page 13] INTERNET-DRAFT 15 March 2001 k The exponent k for the trinomial basis representation x^m+x^k+1. k1, k2, k3 The exponents for the pentanomial representation x^m+x^k3+x^k2+x^k1+1. namedcurve Specifies a recommended set of elliptic curve domain parameters. struct { ECParameters curve_params; ECPoint public; } ServerECDHParams; curve_params Specifies the elliptic curve domain parameters associated with the ECDH public key. public The ephemeral ECDH public key. select (KeyExchangeAlgorithm) { case ec_diffie_hellman: ServerECDHParams params; Signature signed_params; } ServerKeyExchange; params Specifies the ECDH public key and associated domain parameters. signed_params This element is empty for all the key exchange algorithms specified in this document. Actions of the sender: The server selects elliptic curve domain parameters and an ephemeral ECDH public key corresponding to these parameters according to the ECKAS-DH1 scheme from IEEE 1363 [IEEE1363]. It conveys this information to the client in the ServerKeyExchange message using the format defined above. Actions of the recipient: The client retrieves the server's elliptic curve domain parameters and ephemeral ECDH public key from the ServerKeyExchange message. Blake-Wilson, Dierks, Hawk [Page 14] INTERNET-DRAFT 15 March 2001 4.3. Certificate Request This message is sent when requesting the following client authentication methods: Any of the ECC-based client authentication methods specified in Section 3. Meaning of this message: The server uses this message to indicate which client authentication methods the server would like to use. Structure of this message: The TLS CertificateRequest message is extended as follows. enum { ecdsa_sign (5), rsa_fixed_ecdh (6), ecdsa_fixed_ecdh(7), (255) } ClientCertificateType; ecdsa_sign, etc Indicates that the server would like to use the corresponding client authentication method specified in Section 3. Actions of the sender: The server decides which client authentication methods it would like to use, and conveys this information to the client using the format defined above. Actions of the receiver: The client determines whether it has an appropriate certificate for use with any of the requested methods, and decides whether or not to proceed with client authentication. 4.4. Client Certificate This message is sent in the following client authentication methods: All the ECC-based client authentication methods specified in Section 3. Meaning of this message: This message is used to authentically convey the client's static public key to the server. The appropriate certificate types are given in the following table. Blake-Wilson, Dierks, Hawk [Page 15] INTERNET-DRAFT 15 March 2001 Client Authentication Certificate Type Method ECDSA_sign ECC public key which can be used for signing. ECDSA_fixed_ECDH ECC public key which can be used for key agreement. Certificate must be signed with ECDSA. RSA_fixed_ECDH ECC public key which can be used for key agreement. Certificate must be signed with RSA. Table 4: Client certificate types [PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in X.509 certificates. Clients SHOULD use the elliptic curve domain parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], and SEC 2 [SEC2]. Note that - as with RSA - the same identifier is used for all ECC keys in "SubjectPublicKeyInfo". The key usage extension may be used to further delimit the use of the key. When a key usage extension is present, the "keyAgreement" bit MUST be set for ECDH certificates, and the "digitalSignature" bit MUST be set for ECDSA certificates. Structure of this message: Identical to the TLS Certificate format. Actions of the sender: The client constructs an appropriate certificate chain, and conveys it to the server in the Certificate message. Actions of the receiver: The TLS server validates the certificate chain, extracts the client's public key, and checks that the key is of the correct type for the client authentication method. 4.5. Client Key Exchange This message is sent in the following key exchange algorithms: All the ECC-based key exchange algorithms specified in Section 2. If client authentication with fixed ECDH is not being used, the message contains the client's ephemeral ECDH public key, otherwise the message is empty. Blake-Wilson, Dierks, Hawk [Page 16] INTERNET-DRAFT 15 March 2001 Meaning of the message: This message is used to convey ephemeral data relating to the key exchange belonging to the client (such as its ephemeral ECDH public key). Structure of this message: The TLS ClientKeyExchange message is extended as follows. enum { yes, no } EphemeralPublicKey; yes, no Indicates whether or not the client is providing an ephemeral ECDH public key. struct { select (EphemeralPublicKey) { case yes: ECPoint ecdh_Yc; case no: struct { }; } ecdh_public; } ClientECDiffieHellmanPublic; ecdh_Yc Contains the client's ephemeral ECDH public key. struct { select (KeyExchangeAlgorithm) { case ec_diffie_hellman: ClientECDiffieHellmanPublic; } exchange_keys; } ClientKeyExchange; Actions of the sender: The client selects an ephemeral ECDH public key corresponding to the parameters it received from the server according to the ECKAS-DH1 scheme from IEEE 1363 [IEEE1363]. It conveys this information to the client in the ClientKeyExchange message using the format defined above. Actions of the recipient: The server retrieves the client's ephemeral ECDH public key from the ServerKeyExchange message and checks that the public key represents a point of the elliptic curve. Blake-Wilson, Dierks, Hawk [Page 17] INTERNET-DRAFT 15 March 2001 4.6. Certificate Verify This message is sent in the following client authentication methods: ECDSA_sign Meaning of the message: This message contains an ECDSA signature on the handshake messages in order to authenticate the client to the server. Structure of this message: The TLS CertificateVerify message is extended as follows. enum { ec_dsa } SignatureAlgorithm; select (SignatureAlgorithm) { case ec_dsa: digitally-signed struct { opaque sha_hash[20]; }; } Signature; In the CertificateVerify message, the signature field contains the client's ECDSA signature on the handshake messages exchanged so far. According to [ANSIX962], the signature consists of a pair of integers r and s. These integers are both converted into byte strings of the same length as the curve order n using the conversion routine specified in Section 4.3.1 of [ANSIX962], the two byte strings are concatenated, and the result is placed in the signature field. Actions of the sender: The client computes its signature over the handshake messages exchanged so far using its ECDSA key pair with ECDSA computations performed as specified in [ANSIX962] with the hash function SHA-1 [FIPS186-2]. The client conveys its signature to the server in the CertificateVerify message using the format defined above. Actions of the receiver: The server extracts the client's signature from the CertificateVerify message, and verifies the signature using the client's ECDSA public key that it received in the ClientCertificate message. Blake-Wilson, Dierks, Hawk [Page 18] INTERNET-DRAFT 15 March 2001 4.7. Computing the Master Secret In all the ECC-based key exchange algorithms specified in Section 2, the client and server compute the master key as follows: - They both compute a single shared secret K of length 20 bytes using their ECDH key pairs with ECDH computations performed as specified by the ECKAS-DH1 scheme in [IEEE1363] with the ECSVDP-DH secret value derivation primitive, and the KDF1 key derivation primitive using SHA-1 [FIPS180-1]. - They both use K as the pre_master_secret, and compute the master_secret from the pre_master_secret as specified in [TLS]. 5. Cipher Suites The table below defines the cipher suites specified in this document for use with the key exchange algorithms specified in Section 2. CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 } CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 } CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 } CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A } CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B } CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C } CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x4B } CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_56_SHA = { 0x00, 0x4C } CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x4D } CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x4E } CipherSuite TLS_ECDH_RSA_WITH_DES_CBC_SHA = { 0x00, 0x4F } CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x50 } CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x51 } CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x52 } CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x53 } CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_56_SHA = { 0x00, 0x54 } CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x55 } CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x56 } CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA = { 0x00, 0x57 } CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x58 } CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x59 } CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x5A } Table 5: TLS ECC cipher suites The key exchange method, cipher, and hash algorithm for each of these cipher suites are easily determined by examining the name. Ciphers other than AES ciphers, and hash algorithms are defined in [TLS]. AES ciphers are defined in [TLS-AES]. Blake-Wilson, Dierks, Hawk [Page 19] INTERNET-DRAFT 15 March 2001 The cipher suites which use the "NULL" cipher or one of the "EXPORT" key exchange algorithms are considered to be "exportable" cipher suites for the purposes of the TLS protocol. Use of the following cipher suites is recommended in general - server implementations SHOULD support all of these cipher suites, and client implementations SHOULD support at least one of them: TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA Implementations MAY support any of the other cipher suites. 6. Security Considerations This document is entirely concerned with security mechanisms. This document is based on [TLS], [ANSIX9.62], and [IEEE1363] and the appropriate security considerations of those documents apply. In addition implementers should take care to ensure that code which controls security mechanisms is free of errors which might be exploited by attackers. 7. Intellectual Property Rights The IETF has been notified of intellectual property rights claimed in regard to the specification contained in this document. For more information, consult the online list of claimed rights (http://www.ietf.org/ipr.html). The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. 8. Acknowledgments The authors wish to thank Bill Anderson, Paul Fahn, Gilles Garon, John Kennedy, and Brian Minard for their help preparing this document. Blake-Wilson, Dierks, Hawk [Page 20] INTERNET-DRAFT 15 March 2001 9. References [ANSIX9.62] ANSI X9.62-1999, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", American National Standards Institute, 1998. [FIPS180] FIPS 180-1, "Secure Hash Standard", National Institute of Standards and Technology, 1995. [FIPS186-2] FIPS 186-2, "Digital Signature Standard", National Institute of Standards and Technology, 2000. [IEEE1363] IEEE 1363, "Standard Specifications for Public Key Cryptography", Institute of Electrical and Electronics Engineers, 2000. [MUST] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [PKIX-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRL Profile", PKIX Working Group Internet-Draft, draft-ietf-pkix-ipki-pkalgs-02.txt, March 2001. [PKIX-CERT] W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", PKIX Working Group Internet-Draft, draft-ietf-pkix-new-part1-05.txt, March 2001. [SEC1] SEC 1, "Elliptic Curve Cryptography", Standards for Efficient Cryptography Group, 2000. [SEC2] SEC 2, "Recommended Elliptic Curve Domain Parameters", Standards for Efficient Cryptography Group, 2000. [TLS] T. Dierks and C. Allen, "The TLS Protocol - Version 1.0," IETF RFC 2246, January 1999. [TLS-AES] P. Chown, "AES Ciphersuites for TLS", TLS Working Group Internet-Draft, draft-ietf-tls-ciphersuite-03.txt, January 2001. [TLS-EXT] S. Blake-Wilson and M. Nystrom, "Wireless Extensions to TLS", TLS Working Group Internet-Draft, draft-ietf-tls-wireless-00.txt, November 2000. Blake-Wilson, Dierks, Hawk [Page 21] INTERNET-DRAFT 15 March 2001 10. Authors' Addresses Authors: Simon Blake-Wilson Certicom Corp. sblake-wilson@certicom.com Tim Dierks Certicom Corp. timd@consensus.com Chris Hawk Certicom Corp. chawk@certicom.com Blake-Wilson, Dierks, Hawk [Page 22]