| < draft-ietf-tls-ecc-11.txt | draft-ietf-tls-ecc-12.txt > | |||
|---|---|---|---|---|
| TLS Working Group V. Gupta | TLS Working Group S. Blake-Wilson | |||
| Internet-Draft Sun Labs | Internet-Draft BCI | |||
| Expires: March 20, 2006 S. Blake-Wilson | Expires: April 20, 2006 N. Bolyard | |||
| BCI | Sun | |||
| V. Gupta | ||||
| Sun Labs | ||||
| C. Hawk | ||||
| Corriente | ||||
| B. Moeller | B. Moeller | |||
| University of Calgary | University of Calgary | |||
| C. Hawk | October 17, 2005 | |||
| Corriente Networks | ||||
| N. Bolyard | ||||
| September 16, 2005 | ||||
| ECC Cipher Suites for TLS | ECC Cipher Suites for TLS | |||
| <draft-ietf-tls-ecc-11.txt> | <draft-ietf-tls-ecc-12.txt> | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 40 ¶ | skipping to change at page 1, line 41 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on March 20, 2006. | This Internet-Draft will expire on April 20, 2006. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |||
| Abstract | Abstract | |||
| This document describes new key exchange algorithms based on Elliptic | This document describes new key exchange algorithms based on Elliptic | |||
| Curve Cryptography (ECC) for the TLS (Transport Layer Security) | Curve Cryptography (ECC) for the TLS (Transport Layer Security) | |||
| protocol. In particular, it specifies the use of Elliptic Curve | protocol. In particular, it specifies the use of Elliptic Curve | |||
| Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of | Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of | |||
| Elliptic Curve Digital Signature Algorithm (ECDSA) as a new | Elliptic Curve Digital Signature Algorithm (ECDSA) as a new | |||
| authentication mechanism. | authentication mechanism. | |||
| 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 [1]. | ||||
| Please send comments on this document to the TLS mailing list. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5 | 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 5 | |||
| 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8 | 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3. Client Authentication . . . . . . . . . . . . . . . . . . . 9 | 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10 | 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 | 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11 | 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . . 11 | |||
| 5. Data Structures and Computations . . . . . . . . . . . . . . 12 | 5. Data Structures and Computations . . . . . . . . . . . . . . . 12 | |||
| 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12 | 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12 | |||
| 5.2 Server Hello Extension . . . . . . . . . . . . . . . . . . 15 | 5.1.1 Supported Elliptic Curves Extension . . . . . . . . . 13 | |||
| 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16 | 5.1.2 Supported Point Formats Extension . . . . . . . . . . 15 | |||
| 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18 | 5.2 Server Hello Extension . . . . . . . . . . . . . . . . . . 16 | |||
| 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22 | 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 17 | |||
| 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23 | 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18 | |||
| 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 24 | 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22 | |||
| 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 25 | 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23 | |||
| 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 26 | 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 25 | |||
| 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 26 | 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 26 | |||
| 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 28 | 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 27 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 | 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . 27 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 | 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 10.1 Normative References . . . . . . . . . . . . . . . . . . 33 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 10.2 Informative References . . . . . . . . . . . . . . . . . 33 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 | 10.1 Normative References . . . . . . . . . . . . . . . . . . . 35 | |||
| Intellectual Property and Copyright Statements . . . . . . . 36 | 10.2 Informative References . . . . . . . . . . . . . . . . . . 36 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36 | ||||
| Intellectual Property and Copyright Statements . . . . . . . . 38 | ||||
| 1. Introduction | 1. Introduction | |||
| Elliptic Curve Cryptography (ECC) is emerging as an attractive | Elliptic Curve Cryptography (ECC) is emerging as an attractive | |||
| public-key cryptosystem for mobile/wireless environments. Compared | public-key cryptosystem, in particular for mobile (i.e., wireless) | |||
| to currently prevalent cryptosystems such as RSA, ECC offers | environments. Compared to currently prevalent cryptosystems such as | |||
| equivalent security with smaller key sizes. This is illustrated in | RSA, ECC offers equivalent security with smaller key sizes. This is | |||
| the following table, based on [14], which gives approximate | illustrated in the following table, based on [16], which gives | |||
| comparable key sizes for symmetric- and asymmetric-key cryptosystems | approximate comparable key sizes for symmetric- and asymmetric-key | |||
| based on the best-known algorithms for attacking them. | cryptosystems based on the best-known algorithms for attacking them. | |||
| Symmetric | ECC | DH/DSA/RSA | Symmetric | ECC | DH/DSA/RSA | |||
| -------------+---------+------------ | ------------+---------+------------- | |||
| 80 | 163 | 1024 | 80 | 163 | 1024 | |||
| 112 | 233 | 2048 | 112 | 233 | 2048 | |||
| 128 | 283 | 3072 | 128 | 283 | 3072 | |||
| 192 | 409 | 7680 | 192 | 409 | 7680 | |||
| 256 | 571 | 15360 | 256 | 571 | 15360 | |||
| Table 1: Comparable key sizes (in bits) | Table 1: Comparable key sizes (in bits) | |||
| Smaller key sizes result in power, bandwidth and computational | Smaller key sizes result in savings for power, memory, bandwidth, and | |||
| savings that make ECC especially attractive for constrained | computational cost that make ECC especially attractive for | |||
| environments. | constrained environments. | |||
| This document describes additions to TLS to support ECC. In | This document describes additions to TLS to support ECC, applicable | |||
| both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In | ||||
| particular, it defines | particular, it defines | |||
| o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement | o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement | |||
| scheme with long-term or ephemeral keys to establish the TLS | scheme with long-term or ephemeral keys to establish the TLS | |||
| premaster secret, and | premaster secret, and | |||
| o the use of fixed-ECDH certificates and ECDSA for authentication of | o the use of fixed-ECDH certificates and ECDSA for authentication of | |||
| TLS peers. | TLS peers. | |||
| The remainder of this document is organized as follows. Section 2 | The remainder of this document is organized as follows. Section 2 | |||
| skipping to change at page 3, line 51 ¶ | skipping to change at page 4, line 4 ¶ | |||
| Section 3 describes the use of ECC certificates for client | Section 3 describes the use of ECC certificates for client | |||
| authentication. TLS extensions that allow a client to negotiate the | authentication. TLS extensions that allow a client to negotiate the | |||
| use of specific curves and point formats are presented in Section 4. | use of specific curves and point formats are presented in Section 4. | |||
| Section 5 specifies various data structures needed for an ECC-based | Section 5 specifies various data structures needed for an ECC-based | |||
| handshake, their encoding in TLS messages and the processing of those | handshake, their encoding in TLS messages and the processing of those | |||
| messages. Section 6 defines new ECC-based cipher suites and | messages. Section 6 defines new ECC-based cipher suites and | |||
| identifies a small subset of these as recommended for all | identifies a small subset of these as recommended for all | |||
| implementations of this specification. Section 7 discusses security | implementations of this specification. Section 7 discusses security | |||
| considerations. Section 8 describes IANA considerations for the name | considerations. Section 8 describes IANA considerations for the name | |||
| spaces created by this document. Section 9 gives acknowledgments. | spaces created by this document. Section 9 gives acknowledgments. | |||
| This is followed by the lists of normative and informative references | This is followed by the lists of normative and informative references | |||
| cited in this document, the authors' contact information, and | cited in this document, the authors' contact information, and | |||
| statements on intellectual property rights and copyrights. | statements on intellectual property rights and copyrights. | |||
| Implementation of this specification requires familiarity with TLS | Implementation of this specification requires familiarity with TLS | |||
| [2], TLS extensions [3] and ECC [4][5][6][8]. | [2][3], TLS extensions [4], and ECC [5][6][7][9]. | |||
| 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 [1]. | ||||
| 2. Key Exchange Algorithms | 2. Key Exchange Algorithms | |||
| This document introduces five new ECC-based key exchange algorithms | This document introduces five new ECC-based key exchange algorithms | |||
| for TLS. All of them use ECDH to compute the TLS premaster secret | for TLS. All of them use ECDH to compute the TLS premaster secret | |||
| and differ only in the lifetime of ECDH keys (long-term or ephemeral) | and differ only in the lifetime of ECDH keys (long-term or ephemeral) | |||
| and the mechanism (if any) used to authenticate them. The derivation | and the mechanism (if any) used to authenticate them. The derivation | |||
| of the TLS master secret from the premaster secret and the subsequent | of the TLS master secret from the premaster secret and the subsequent | |||
| generation of bulk encryption/MAC keys and initialization vectors is | generation of bulk encryption/MAC keys and initialization vectors is | |||
| independent of the key exchange algorithm and not impacted by the | independent of the key exchange algorithm and not impacted by the | |||
| introduction of ECC. | introduction of ECC. | |||
| The table below summarizes the new key exchange algorithms which | The table below summarizes the new key exchange algorithms which | |||
| mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2]), | mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and | |||
| respectively. | [3]), respectively. | |||
| Key | Key | |||
| Exchange | Exchange | |||
| Algorithm Description | Algorithm Description | |||
| --------- ----------- | --------- ----------- | |||
| ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. | ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. | |||
| ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. | ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. | |||
| skipping to change at page 5, line 46 ¶ | skipping to change at page 5, line 46 ¶ | |||
| The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward | The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward | |||
| secrecy. With ECDHE_RSA, a server can reuse its existing RSA | secrecy. With ECDHE_RSA, a server can reuse its existing RSA | |||
| certificate and easily comply with a constrained client's elliptic | certificate and easily comply with a constrained client's elliptic | |||
| curve preferences (see Section 4). However, the computational cost | curve preferences (see Section 4). However, the computational cost | |||
| incurred by a server is higher for ECDHE_RSA than for the traditional | incurred by a server is higher for ECDHE_RSA than for the traditional | |||
| RSA key exchange which does not provide forward secrecy. | RSA key exchange which does not provide forward secrecy. | |||
| The ECDH_RSA mechanism requires a server to acquire an ECC | The ECDH_RSA mechanism requires a server to acquire an ECC | |||
| certificate but the certificate issuer can still use an existing RSA | certificate but the certificate issuer can still use an existing RSA | |||
| key for signing. This eliminates the need to update the trusted key | key for signing. This eliminates the need to update the keys of | |||
| store in TLS clients. The ECDH_ECDSA mechanism requires ECC keys for | trusted certificiation authorities accepted by TLS clients. The | |||
| the server as well as the certification authority and is best suited | ECDH_ECDSA mechanism requires ECC keys for the server as well as the | |||
| for constrained devices unable to support RSA. | certification authority and is best suited for constrained devices | |||
| unable to support RSA. | ||||
| The anonymous key exchange algorithm does not provide authentication | The anonymous key exchange algorithm does not provide authentication | |||
| of the server or the client. Like other anonymous TLS key exchanges, | of the server or the client. Like other anonymous TLS key exchanges, | |||
| it is subject to man-in-the-middle attacks. Implementations of this | it is subject to man-in-the-middle attacks. Implementations of this | |||
| algorithm SHOULD provide authentication by other means. | algorithm SHOULD provide authentication by other means. | |||
| Note that there is no structural difference between ECDH and ECDSA | Note that there is no structural difference between ECDH and ECDSA | |||
| keys. A certificate issuer may use X509.v3 keyUsage and | keys. A certificate issuer may use X.509 v3 keyUsage and | |||
| extendedKeyUsage extensions to restrict the use of an ECC public key | extendedKeyUsage extensions to restrict the use of an ECC public key | |||
| to certain computations. This document refers to an ECC key as ECDH- | to certain computations [13]. This document refers to an ECC key as | |||
| capable if its use in ECDH is permitted. ECDSA-capable is defined | ECDH-capable if its use in ECDH is permitted. ECDSA-capable is | |||
| similarly. | defined similarly. | |||
| Client Server | Client Server | |||
| ------ ------ | ------ ------ | |||
| ClientHello --------> | ClientHello --------> | |||
| ServerHello | ServerHello | |||
| Certificate* | Certificate* | |||
| ServerKeyExchange* | ServerKeyExchange* | |||
| CertificateRequest*+ | CertificateRequest*+ | |||
| <-------- ServerHelloDone | <-------- ServerHelloDone | |||
| skipping to change at page 7, line 24 ¶ | skipping to change at page 7, line 25 ¶ | |||
| to arrive at the premaster secret). | to arrive at the premaster secret). | |||
| The client generates an ECDH key pair on the same curve as the | The client generates an ECDH key pair on the same curve as the | |||
| server's long-term public key and send its public key in the | server's long-term public key and send its public key in the | |||
| ClientKeyExchange message (except when using client authentication | ClientKeyExchange message (except when using client authentication | |||
| algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the | algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the | |||
| modifications from Section 3.2 or Section 3.3 apply). | modifications from Section 3.2 or Section 3.3 apply). | |||
| Both client and server perform an ECDH operation and use the | Both client and server perform an ECDH operation and use the | |||
| resultant shared secret as the premaster secret. All ECDH | resultant shared secret as the premaster secret. All ECDH | |||
| calculations are performed as specified in Section 5.10 | calculations are performed as specified in Section 5.10. | |||
| 2.2 ECDHE_ECDSA | 2.2 ECDHE_ECDSA | |||
| In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- | In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- | |||
| capable public key and be signed with ECDSA. | capable public key and be signed with ECDSA. | |||
| The server sends its ephemeral ECDH public key and a specification of | The server sends its ephemeral ECDH public key and a specification of | |||
| the corresponding curve in the ServerKeyExchange message. These | the corresponding curve in the ServerKeyExchange message. These | |||
| parameters MUST be signed with ECDSA using the private key | parameters MUST be signed with ECDSA using the private key | |||
| corresponding to the public key in the server's Certificate. | corresponding to the public key in the server's Certificate. | |||
| skipping to change at page 8, line 29 ¶ | skipping to change at page 8, line 30 ¶ | |||
| server's ephemeral ECDH key and send its public key in the | server's ephemeral ECDH key and send its public key in the | |||
| ClientKeyExchange message. | ClientKeyExchange message. | |||
| Both client and server perform an ECDH operation and use the | Both client and server perform an ECDH operation and use the | |||
| resultant shared secret as the premaster secret. All ECDH | resultant shared secret as the premaster secret. All ECDH | |||
| calculations are performed as specified in Section 5.10. | calculations are performed as specified in Section 5.10. | |||
| Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA | Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA | |||
| key exchange algorithms require the server's certificate to be signed | key exchange algorithms require the server's certificate to be signed | |||
| with a particular signature scheme, this specification (following the | with a particular signature scheme, this specification (following the | |||
| similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2]) does not | similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3]) | |||
| impose restrictions on signature schemes used elsewhere in the | does not impose restrictions on signature schemes used elsewhere in | |||
| certificate chain. (Often such restrictions will be useful, and it | the certificate chain. (Often such restrictions will be useful, and | |||
| is expected that this will be taken into account in certification | it is expected that this will be taken into account in certification | |||
| authorities' signing practices. However, such restrictions are not | authorities' signing practices. However, such restrictions are not | |||
| strictly required in general: Even if it is beyond the capabilities | strictly required in general: Even if it is beyond the capabilities | |||
| of a client to completely validate a given chain, the client may be | of a client to completely validate a given chain, the client may be | |||
| able to validate the server's certificate by relying on a trust | able to validate the server's certificate by relying on a trusted | |||
| anchor that appears as one of the intermediate certificates in the | certification authority whose certificate appears as one of the | |||
| chain.) | intermediate certificates in the chain.) | |||
| 3. Client Authentication | 3. Client Authentication | |||
| This document defines three new client authentication mechanisms | This document defines three new client authentication mechanisms | |||
| named after the type of client certificate involved: ECDSA_sign, | named after the type of client certificate involved: ECDSA_sign, | |||
| ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is | ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is | |||
| usable with any of the non-anonymous ECC key exchange algorithms | usable with any of the non-anonymous ECC key exchange algorithms | |||
| described in Section 2 as well as other non-anonymous (non-ECC) key | described in Section 2 as well as other non-anonymous (non-ECC) key | |||
| exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and | exchange algorithms defined in TLS [2][3]. The ECDSA_fixed_ECDH and | |||
| RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. | RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. | |||
| Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the | Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the | |||
| use of a long-term ECDH client key would jeopardize the forward | use of a long-term ECDH client key would jeopardize the forward | |||
| secrecy property of these algorithms. | secrecy property of these algorithms. | |||
| The server can request ECC-based client authentication by including | The server can request ECC-based client authentication by including | |||
| one or more of these certificate types in its CertificateRequest | one or more of these certificate types in its CertificateRequest | |||
| message. The server must not include any certificate types that are | message. The server must not include any certificate types that are | |||
| prohibited for the negotiated key exchange algorithm. The client | prohibited for the negotiated key exchange algorithm. The client | |||
| must check if it possesses a certificate appropriate for any of the | must check if it possesses a certificate appropriate for any of the | |||
| skipping to change at page 11, line 14 ¶ | skipping to change at page 11, line 14 ¶ | |||
| 4. TLS Extensions for ECC | 4. TLS Extensions for ECC | |||
| Two new TLS extensions are defined in this specification: (i) the | Two new TLS extensions are defined in this specification: (i) the | |||
| Supported Elliptic Curves Extension, and (ii) the Supported Point | Supported Elliptic Curves Extension, and (ii) the Supported Point | |||
| Formats Extension. These allow negotiating the use of specific | Formats Extension. These allow negotiating the use of specific | |||
| curves and point formats (e.g. compressed vs. uncompressed), | curves and point formats (e.g. compressed vs. uncompressed), | |||
| respectively, during a handshake starting a new session. These | respectively, during a handshake starting a new session. These | |||
| extensions are especially relevant for constrained clients that may | extensions are especially relevant for constrained clients that may | |||
| only support a limited number of curves or point formats. They | only support a limited number of curves or point formats. They | |||
| follow the general approach outlined in [3]; message details are | follow the general approach outlined in [4]; message details are | |||
| specified in Section 5. The client enumerates the curves it supports | specified in Section 5. The client enumerates the curves it supports | |||
| and the point formats it can parse by including the appropriate | and the point formats it can parse by including the appropriate | |||
| extensions in its ClientHello message. The server similarly | extensions in its ClientHello message. The server similarly | |||
| enumerates the point formats it can parse by including an extension | enumerates the point formats it can parse by including an extension | |||
| in its ServerHello message. | in its ServerHello message. | |||
| A TLS client that proposes ECC cipher suites in its ClientHello | A TLS client that proposes ECC cipher suites in its ClientHello | |||
| message SHOULD include these extensions. Servers implementing ECC | message SHOULD include these extensions. Servers implementing ECC | |||
| cipher suites MUST support these extensions, and when a client uses | cipher suites MUST support these extensions, and when a client uses | |||
| these extensions, servers MUST NOT negotiate the use of an ECC cipher | these extensions, servers MUST NOT negotiate the use of an ECC cipher | |||
| suite unless they can complete the handshake while respecting the | suite unless they can complete the handshake while respecting the | |||
| choice of curves and compression techniques specified by the client. | choice of curves and compression techniques specified by the client. | |||
| This eliminates the possibility that a negotiated ECC handshake will | This eliminates the possibility that a negotiated ECC handshake will | |||
| be subsequently aborted due to a client's inability to deal with the | be subsequently aborted due to a client's inability to deal with the | |||
| server's EC key. | server's EC key. | |||
| These extensions MUST NOT be included if the client does not propose | The client MUST NOT include these extensions in the ClientHello | |||
| any ECC cipher suites. A client that proposes ECC cipher suites may | message if it does not propose any ECC cipher suites. A client that | |||
| choose not to include these extension. In this case, the server is | proposes ECC cipher suites may choose not to include these extension. | |||
| free to choose any one of the elliptic curves or point formats listed | In this case, the server is free to choose any one of the elliptic | |||
| in Section 5. That section also describes the structure and | curves or point formats listed in Section 5. That section also | |||
| processing of these extensions in greater detail. | describes the structure and processing of these extensions in greater | |||
| detail. | ||||
| In the case of session resumption, the server simply ignores the | In the case of session resumption, the server simply ignores the | |||
| Supported Elliptic Curves Extension and the Supported Point Formats | Supported Elliptic Curves Extension and the Supported Point Formats | |||
| Extension as appearing in the current ClientHello message. These | Extension as appearing in the current ClientHello message. These | |||
| extensions only play a role during handshakes negotiating a new | extensions only play a role during handshakes negotiating a new | |||
| session. | session. | |||
| 5. Data Structures and Computations | 5. Data Structures and Computations | |||
| This section specifies the data structures and computations used by | This section specifies the data structures and computations used by | |||
| ECC-based key mechanisms specified in Section 2, Section 3 and | ECC-based key mechanisms specified in Section 2, Section 3 and | |||
| Section 4. The presentation language used here is the same as that | Section 4. The presentation language used here is the same as that | |||
| used in TLS [2]. Since this specification extends TLS, these | used in TLS [2][3]. Since this specification extends TLS, these | |||
| descriptions should be merged with those in the TLS specification and | descriptions should be merged with those in the TLS specification and | |||
| any others that extend TLS. This means that enum types may not | any others that extend TLS. This means that enum types may not | |||
| specify all possible values and structures with multiple formats | specify all possible values and structures with multiple formats | |||
| chosen with a select() clause may not indicate all possible cases. | chosen with a select() clause may not indicate all possible cases. | |||
| 5.1 Client Hello Extensions | 5.1 Client Hello Extensions | |||
| This section specifies two TLS extensions that can be included with | This section specifies two TLS extensions that can be included with | |||
| the ClientHello message as described in [3], the Supported Elliptic | the ClientHello message as described in [4], the Supported Elliptic | |||
| Curves Extension and the Supported Point Formats Extension. | Curves Extension and the Supported Point Formats Extension. | |||
| When these extensions are sent: | When these extensions are sent: | |||
| The extensions SHOULD be sent along with any ClientHello message that | The extensions SHOULD be sent along with any ClientHello message that | |||
| proposes ECC cipher suites. | proposes ECC cipher suites. | |||
| Meaning of these extensions: | Meaning of these extensions: | |||
| These extensions allow a client to enumerate the elliptic curves it | These extensions allow a client to enumerate the elliptic curves it | |||
| supports and/or the point formats it can parse. | supports and/or the point formats it can parse. | |||
| Structure of these extensions: | Structure of these extensions: | |||
| The general structure of TLS extensions is described in [3] and this | The general structure of TLS extensions is described in [4] and this | |||
| specification adds two new types to ExtensionType. | specification adds two new types to ExtensionType. | |||
| enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType; | enum { elliptic_curves(10), ec_point_formats(11) } ExtensionType; | |||
| [[ EDITOR: The values used for elliptic_curves and ec_point_formats | [[ EDITOR: The values "10" and "11" used for the new extensions are | |||
| have been left as ??. These values will be assigned when this draft | tentative! (They were picked to avoid conflicts with other emerging | |||
| progresses to RFC. (The examples below will have to be changed | specifications; see http://people.nokia.net/~pasi/tls-numbers.txt .) | |||
| accordingly.) ]] | Final assignments in accordance with [4] will be done by IANA. The | |||
| values appearing in this Internet-Draft represent the authors' | ||||
| recommendations to IANA for assignments. ]] | ||||
| elliptic_curves (Supported Elliptic Curves Extension): Indicates the | elliptic_curves (Supported Elliptic Curves Extension): Indicates the | |||
| set of elliptic curves supported by the client. For this | set of elliptic curves supported by the client. For this | |||
| extension, the opaque extension_data field contains | extension, the opaque extension_data field contains | |||
| EllipticCurveList. | EllipticCurveList. See Section 5.1.1 for details. | |||
| ec_point_formats (Supported Point Formats Extension): Indicates the | ec_point_formats (Supported Point Formats Extension): Indicates the | |||
| set of point formats that the client can parse. For this | set of point formats that the client can parse. For this | |||
| extension, the opaque extension_data field contains | extension, the opaque extension_data field contains | |||
| ECPointFormatList. | ECPointFormatList. See Section 5.1.2 for details. | |||
| Actions of the sender: | ||||
| A client that proposes ECC cipher suites in its ClientHello message | ||||
| appends these extensions (along with any others), enumerating the | ||||
| curves it supports and the point formats it can parse. Clients | ||||
| SHOULD send both the Supported Elliptic Curves Extension and the | ||||
| Supported Point Formats Extension. If the Supported Point Formats | ||||
| Extension is indeed sent, it MUST contain the value 0 (uncompressed) | ||||
| as one of the items in the list of point formats. | ||||
| Actions of the receiver: | ||||
| A server that receives a ClientHello containing one or both of these | ||||
| extensions MUST use the client's enumerated capabilities to guide its | ||||
| selection of an appropriate cipher suite. One of the proposed ECC | ||||
| cipher suites must be negotiated only if the server can successfully | ||||
| complete the handshake while using the curves and point formats | ||||
| supported by the client (cf. Section 5.3 and Section 5.4). | ||||
| NOTE: A server participating in an ECDHE-ECDSA key exchange may use | ||||
| different curves for (i) the ECDSA key in its certificate, and (ii) | ||||
| the ephemeral ECDH key in the ServerKeyExchange message. The server | ||||
| must consider the extensions in both cases. | ||||
| If a server does not understand the Supported Elliptic Curves | ||||
| Extension or does not understand the Supported Point Formates | ||||
| Extension or is unable to complete the ECC handshake while | ||||
| restricting itself to the enumerated curves and point formats, it | ||||
| MUST NOT negotiate the use of an ECC cipher suite. Depending on what | ||||
| other cipher suites are proposed by the client and supported by the | ||||
| server, this may result in a fatal handshake failure alert due to the | ||||
| lack of common cipher suites. | ||||
| 5.1.1 Supported Elliptic Curves Extension | ||||
| enum { | enum { | |||
| sect163k1 (1), sect163r1 (2), sect163r2 (3), | sect163k1 (1), sect163r1 (2), sect163r2 (3), | |||
| sect193r1 (4), sect193r2 (5), sect233k1 (6), | sect193r1 (4), sect193r2 (5), sect233k1 (6), | |||
| sect233r1 (7), sect239k1 (8), sect283k1 (9), | sect233r1 (7), sect239k1 (8), sect283k1 (9), | |||
| sect283r1 (10), sect409k1 (11), sect409r1 (12), | sect283r1 (10), sect409k1 (11), sect409r1 (12), | |||
| sect571k1 (13), sect571r1 (14), secp160k1 (15), | sect571k1 (13), sect571r1 (14), secp160k1 (15), | |||
| secp160r1 (16), secp160r2 (17), secp192k1 (18), | secp160r1 (16), secp160r2 (17), secp192k1 (18), | |||
| secp192r1 (19), secp224k1 (20), secp224r1 (21), | secp192r1 (19), secp224k1 (20), secp224r1 (21), | |||
| secp256k1 (22), secp256r1 (23), secp384r1 (24), | secp256k1 (22), secp256r1 (23), secp384r1 (24), | |||
| secp521r1 (25), | secp521r1 (25), | |||
| reserved (0xFE00..0xFEFF), | reserved (0xFE00..0xFEFF), | |||
| arbitrary_explicit_prime_curves(0xFF01), | arbitrary_explicit_prime_curves(0xFF01), | |||
| arbitrary_explicit_char2_curves(0xFF02), | arbitrary_explicit_char2_curves(0xFF02), | |||
| (0xFFFF) | (0xFFFF) | |||
| } NamedCurve; | } NamedCurve; | |||
| sect163k1, etc: Indicates support of the corresponding named curve | sect163k1, etc: Indicates support of the corresponding named curve | |||
| or class of explicitly defined curves. The named curves defined | or class of explicitly defined curves. The named curves defined | |||
| here are those specified in SEC 2 [10]. Note that many of these | here are those specified in SEC 2 [11]. Note that many of these | |||
| curves are also recommended in ANSI X9.62 [6] and FIPS 186-2 [8]. | curves are also recommended in ANSI X9.62 [7] and FIPS 186-2 [9]. | |||
| Values 0xFE00 through 0xFEFF are reserved for private use. Values | Values 0xFE00 through 0xFEFF are reserved for private use. Values | |||
| 0xFF01 and 0xFF02 indicate that the client supports arbitrary | 0xFF01 and 0xFF02 indicate that the client supports arbitrary | |||
| prime and characteristic-2 curves, respectively (the curve | prime and characteristic-2 curves, respectively (the curve | |||
| parameters must be encoded explicitly in ECParameters). | parameters must be encoded explicitly in ECParameters). | |||
| The NamedCurve name space is maintained by IANA. See Section 8 for | The NamedCurve name space is maintained by IANA. See Section 8 for | |||
| information on how new value assignments are added. | information on how new value assignments are added. | |||
| struct { | struct { | |||
| NamedCurve elliptic_curve_list<1..2^8-1> | NamedCurve elliptic_curve_list<1..2^8-1> | |||
| } EllipticCurveList; | } EllipticCurveList; | |||
| Items in elliptic_curve_list are ordered according to the client's | Items in elliptic_curve_list are ordered according to the client's | |||
| preferences (favorite choice first). | preferences (favorite choice first). | |||
| As an example, a client that only supports secp192r1 (aka NIST P-192; | As an example, a client that only supports secp192r1 (aka NIST P-192; | |||
| value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) | value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) | |||
| and prefers to use secp192r1 would include a TLS extension consisting | and prefers to use secp192r1 would include a TLS extension consisting | |||
| of the following octets: | of the following octets; note that the first two octets indicate the | |||
| extension type (Supported Elliptic Curves Extension): | ||||
| 00 ?? 00 06 00 04 00 13 00 15 | 00 0A 00 06 00 04 00 13 00 15 | |||
| A client that supports arbitrary explicit characteristic-2 curves | A client that supports arbitrary explicit characteristic-2 curves | |||
| (value 0xFF02) would include an extension consisting of the following | (value 0xFF02) would include an extension consisting of the following | |||
| octets: | octets: | |||
| 00 ?? 00 04 00 02 FF 02 | 00 0A 00 04 00 02 FF 02 | |||
| [[ EDITOR: As noted above, the extension type value appearing in this | ||||
| example is tentative. ]] | ||||
| 5.1.2 Supported Point Formats Extension | ||||
| enum { uncompressed (0), ansiX962_compressed_prime (1), | enum { uncompressed (0), ansiX962_compressed_prime (1), | |||
| ansiX962_compressed_char2 (2), reserved (248..255) | ansiX962_compressed_char2 (2), reserved (248..255) | |||
| } ECPointFormat; | } ECPointFormat; | |||
| struct { | struct { | |||
| ECPointFormat ec_point_format_list<1..2^8-1> | ECPointFormat ec_point_format_list<1..2^8-1> | |||
| } ECPointFormatList; | } ECPointFormatList; | |||
| Three point formats are included in the definition of ECPointFormat | Three point formats are included in the definition of ECPointFormat | |||
| above. The uncompressed point format is the default format in that | above. The uncompressed point format is the default format in that | |||
| implementations of this document MUST support it for all of their | implementations of this document MUST support it for all of their | |||
| supported curves. Compressed point formats reduce bandwidth by | supported curves. Compressed point formats reduce bandwidth by | |||
| including only the x-coordinate and a single bit of the y-coordinate | including only the x-coordinate and a single bit of the y-coordinate | |||
| of the point. Implementations of this document MAY support the | of the point. Implementations of this document MAY support the | |||
| ansiX962_compressed_prime and ansiX962_compressed_char2 formats, | ansiX962_compressed_prime and ansiX962_compressed_char2 formats, | |||
| where the former applies only to prime curves and the latter applies | where the former applies only to prime curves and the latter applies | |||
| only to characteristic-2 curves. (These formats are specified in | only to characteristic-2 curves. (These formats are specified in | |||
| [6].) Values 248 through 255 are reserved for private use. | [7].) Values 248 through 255 are reserved for private use. | |||
| The ECPointFormat name space is maintained by IANA. See Section 8 | The ECPointFormat name space is maintained by IANA. See Section 8 | |||
| for information on how new value assignments are added. | for information on how new value assignments are added. | |||
| Items in ec_point_format_list are ordered according to the client's | Items in ec_point_format_list are ordered according to the client's | |||
| preferences (favorite choice first). | preferences (favorite choice first). | |||
| A client that can parse only the uncompressed point format (value 0) | A client that can parse only the uncompressed point format (value 0) | |||
| includes an extension consisting of the following octets: | includes an extension consisting of the following octets; note that | |||
| the first two octets indicate the extension type (Supported Point | ||||
| Formats Extension): | ||||
| 00 ?? 00 02 01 00 | 00 0B 00 02 01 00 | |||
| A client that in the case of prime fields prefers the compressed | A client that in the case of prime fields prefers the compressed | |||
| format (ansiX962_compressed_prime, value 1) over the uncompressed | format (ansiX962_compressed_prime, value 1) over the uncompressed | |||
| format (value 0), but in the case of characteristic-2 fields prefers | format (value 0), but in the case of characteristic-2 fields prefers | |||
| the uncompressed format (value 0) over the compressed format | the uncompressed format (value 0) over the compressed format | |||
| (ansiX962_compressed_char2, value 2), may indicate these preferences | (ansiX962_compressed_char2, value 2), may indicate these preferences | |||
| by including an extension consisting of the following octets: | by including an extension consisting of the following octets: | |||
| 00 ?? 00 04 03 01 00 02 | 00 0B 00 04 03 01 00 02 | |||
| Actions of the sender: | ||||
| A client that proposes ECC cipher suites in its ClientHello message | ||||
| appends these extensions (along with any others), enumerating the | ||||
| curves it supports and the point formats it can parse. Clients | ||||
| SHOULD send both the Supported Elliptic Curves Extension and the | ||||
| Supported Point Formats Extension. If the Supported Point Formats | ||||
| Extension is indeed sent, it MUST contain the value 0 (uncompressed) | ||||
| as one of the items in the list of point formats. | ||||
| Actions of the receiver: | ||||
| A server that receives a ClientHello containing one or both of these | ||||
| extensions MUST use the client's enumerated capabilities to guide its | ||||
| selection of an appropriate cipher suite. One of the proposed ECC | ||||
| cipher suites must be negotiated only if the server can successfully | ||||
| complete the handshake while using the curves and point formats | ||||
| supported by the client (cf. Section 5.3 and Section 5.4). | ||||
| NOTE: A server participating in an ECDHE-ECDSA key exchange may use | ||||
| different curves for (i) the ECDSA key in its certificate, and (ii) | ||||
| the ephemeral ECDH key in the ServerKeyExchange message. The server | ||||
| must consider the "elliptic_curves" extension in selecting both of | ||||
| these curves. | ||||
| If a server does not understand the "elliptic_curves" extension or is | [[ EDITOR: As noted above, the extension type value appearing in this | |||
| unable to complete the ECC handshake while restricting itself to the | example is tentative. ]] | |||
| enumerated curves, it MUST NOT negotiate the use of an ECC cipher | ||||
| suite. Depending on what other cipher suites are proposed by the | ||||
| client and supported by the server, this may result in a fatal | ||||
| handshake failure alert due to the lack of common cipher suites. | ||||
| 5.2 Server Hello Extension | 5.2 Server Hello Extension | |||
| This section specifies a TLS extension that can be included with the | This section specifies a TLS extension that can be included with the | |||
| ServerHello message as described in [3], the Supported Point Formats | ServerHello message as described in [4], the Supported Point Formats | |||
| Extension. | Extension. | |||
| When this extension is sent: | When this extension is sent: | |||
| The Supported Point Formats Extension is included in a ServerHello | The Supported Point Formats Extension is included in a ServerHello | |||
| message in response to a ClientHello message containing the Supported | message in response to a ClientHello message containing the Supported | |||
| Point Formats Extension when negotiating an ECC cipher suite. | Point Formats Extension when negotiating an ECC cipher suite. | |||
| Meaning of this extensions: | Meaning of this extensions: | |||
| This extension allows a server to enumerate the point formats it can | This extension allows a server to enumerate the point formats it can | |||
| parse (for the curve that will appear in its ServerKeyExchange | parse (for the curve that will appear in its ServerKeyExchange | |||
| message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key | message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key | |||
| exchange algorithm, or for the curve that is used in the server's | exchange algorithm, or for the curve that is used in the server's | |||
| public key that will appear in its Certificate message when using the | public key that will appear in its Certificate message when using the | |||
| ECDH_ECDSA or ECDH_RSA key exchange algorithm). | ECDH_ECDSA or ECDH_RSA key exchange algorithm). | |||
| Structure of this extension: | Structure of this extension: | |||
| The server's Supported Point Formats Extension has the same structure | The server's Supported Point Formats Extension has the same structure | |||
| as the client's Supported Point Formats Extension. Items in | as the client's Supported Point Formats Extension (see | |||
| elliptic_curve_list here are ordered according to the server's | Section 5.1.2). Items in elliptic_curve_list here are ordered | |||
| preference (favorite choice first). Note that the server may include | according to the server's preference (favorite choice first). Note | |||
| items that were not found in the client's list (e.g., the server may | that the server may include items that were not found in the client's | |||
| prefer to receive points in compressed format even when a client | list (e.g., the server may prefer to receive points in compressed | |||
| cannot parse this format: the same client may nevertheless be capable | format even when a client cannot parse this format: the same client | |||
| to output points in compressed format). | may nevertheless be capable to output points in compressed format). | |||
| Actions of the sender: | Actions of the sender: | |||
| A server that selects an ECC cipher suite in response to a | A server that selects an ECC cipher suite in response to a | |||
| ClientHello message including a Supported Point Formats Extension | ClientHello message including a Supported Point Formats Extension | |||
| appends this extension (along with others) to its ServerHello | appends this extension (along with others) to its ServerHello | |||
| message, enumerating the point formats it can parse. The Supported | message, enumerating the point formats it can parse. The Supported | |||
| Point Formats Extension, when used, MUST contain the value 0 | Point Formats Extension, when used, MUST contain the value 0 | |||
| (uncompressed) as one of the items in the list of point formats. | (uncompressed) as one of the items in the list of point formats. | |||
| skipping to change at page 16, line 50 ¶ | skipping to change at page 17, line 21 ¶ | |||
| When this message is sent: | When this message is sent: | |||
| This message is sent in all non-anonymous ECC-based key exchange | This message is sent in all non-anonymous ECC-based key exchange | |||
| algorithms. | algorithms. | |||
| Meaning of this message: | Meaning of this message: | |||
| This message is used to authentically convey the server's static | This message is used to authentically convey the server's static | |||
| public key to the client. The following table shows the server | public key to the client. The following table shows the server | |||
| certificate type appropriate for each key exchange algorithm. ECC | certificate type appropriate for each key exchange algorithm. ECC | |||
| public keys must be encoded in certificates as described in | public keys MUST be encoded in certificates as described in | |||
| Section 5.9. | Section 5.9. | |||
| NOTE: The server's Certificate message is capable of carrying a chain | NOTE: The server's Certificate message is capable of carrying a chain | |||
| of certificates. The restrictions mentioned in Table 3 apply only to | of certificates. The restrictions mentioned in Table 3 apply only to | |||
| the server's certificate (first in the chain). | the server's certificate (first in the chain). | |||
| Key Exchange Algorithm Server Certificate Type | Key Exchange Algorithm Server Certificate Type | |||
| ---------------------- ----------------------- | ---------------------- ----------------------- | |||
| ECDH_ECDSA Certificate must contain an | ECDH_ECDSA Certificate MUST contain an | |||
| ECDH-capable public key. It | ECDH-capable public key. It | |||
| must be signed with ECDSA. | MUST be signed with ECDSA. | |||
| ECDHE_ECDSA Certificate must contain an | ECDHE_ECDSA Certificate MUST contain an | |||
| ECDSA-capable public key. It | ECDSA-capable public key. It | |||
| must be signed with ECDSA. | MUST be signed with ECDSA. | |||
| ECDH_RSA Certificate must contain an | ECDH_RSA Certificate MUST contain an | |||
| ECDH-capable public key. It | ECDH-capable public key. It | |||
| must be signed with RSA. | MUST be signed with RSA. | |||
| ECDHE_RSA Certificate must contain an | ECDHE_RSA Certificate MUST contain an | |||
| RSA public key authorized for | RSA public key authorized for | |||
| use in digital signatures. It | use in digital signatures. It | |||
| must be signed with RSA. | MUST be signed with RSA. | |||
| Table 3: Server certificate types | Table 3: Server certificate types | |||
| Structure of this message: | Structure of this message: | |||
| Identical to the TLS Certificate format. | Identical to the TLS Certificate format. | |||
| Actions of the sender: | Actions of the sender: | |||
| The server constructs an appropriate certificate chain and conveys it | The server constructs an appropriate certificate chain and conveys it | |||
| to the client in the Certificate message. If the client has used a | to the client in the Certificate message. If the client has used a | |||
| Supported Elliptic Curves Extension, the public key in the server's | Supported Elliptic Curves Extension, the public key in the server's | |||
| certificate MUST respect the client's choice of elliptic curves; in | certificate MUST respect the client's choice of elliptic curves; in | |||
| particular, the public key MUST employ a named curve (not the same | particular, the public key MUST employ a named curve (not the same | |||
| curve as an explicit curve) unless the client has indicated support | curve as an explicit curve) unless the client has indicated support | |||
| for explicit curves of the appropriate type. If the client has used | for explicit curves of the appropriate type. If the client has used | |||
| a Supported Point Formats Extension, both the server's public key | a Supported Point Formats Extension, both the server's public key | |||
| point and (in the case of an explicit curve) the curve's base point | point and (in the case of an explicit curve) the curve's base point | |||
| MUST respect the client's choice of point formats. (A server that | MUST respect the client's choice of point formats. (A server that | |||
| cannot satisfy these requirements must not choose an ECC cipher suite | cannot satisfy these requirements MUST NOT choose an ECC cipher suite | |||
| in its ServerHello message.) | in its ServerHello message.) | |||
| Actions of the receiver: | Actions of the receiver: | |||
| The client validates the certificate chain, extracts the server's | The client validates the certificate chain, extracts the server's | |||
| public key, and checks that the key type is appropriate for the | public key, and checks that the key type is appropriate for the | |||
| negotiated key exchange algorithm. | negotiated key exchange algorithm. (A possible reason for a fatal | |||
| handshake failure is if the client's capabilities for handling | ||||
| elliptic curves and point formats are exceeded; cf. Section 5.1.) | ||||
| 5.4 Server Key Exchange | 5.4 Server Key Exchange | |||
| When this message is sent: | When this message is sent: | |||
| This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and | This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and | |||
| ECDH_anon key exchange algorithms. | ECDH_anon key exchange algorithms. | |||
| Meaning of this message: | Meaning of this message: | |||
| skipping to change at page 18, line 51 ¶ | skipping to change at page 19, line 29 ¶ | |||
| information on how new value assignments are added. | information on how new value assignments are added. | |||
| struct { | struct { | |||
| opaque a <1..2^8-1>; | opaque a <1..2^8-1>; | |||
| opaque b <1..2^8-1>; | opaque b <1..2^8-1>; | |||
| } ECCurve; | } ECCurve; | |||
| a, b: These parameters specify the coefficients of the elliptic | a, b: These parameters specify the coefficients of the elliptic | |||
| curve. Each value contains the byte string representation of a | curve. Each value contains the byte string representation of a | |||
| field element following the conversion routine in Section 4.3.3 of | field element following the conversion routine in Section 4.3.3 of | |||
| ANSI X9.62 [6]. | ANSI X9.62 [7]. | |||
| struct { | struct { | |||
| opaque point <1..2^8-1>; | opaque point <1..2^8-1>; | |||
| } ECPoint; | } ECPoint; | |||
| point: This is the byte string representation of an elliptic curve | point: This is the byte string representation of an elliptic curve | |||
| point following the conversion routine in Section 4.3.6 of ANSI | point following the conversion routine in Section 4.3.6 of ANSI | |||
| X9.62 [6]. This byte string may represent an elliptic curve point | X9.62 [7]. This byte string may represent an elliptic curve point | |||
| in uncompressed, or compressed format; it MUST conform to what the | in uncompressed, or compressed format; it MUST conform to what the | |||
| client has requested through a Supported Point Formats Extension | client has requested through a Supported Point Formats Extension | |||
| if this extension was used. | if this extension was used. | |||
| enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; | enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; | |||
| ec_basis_trinomial: Indicates representation of a characteristic-2 | ec_basis_trinomial: Indicates representation of a characteristic-2 | |||
| field using a trinomial basis. | field using a trinomial basis. | |||
| ec_basis_pentanomial: Indicates representation of a characteristic-2 | ec_basis_pentanomial: Indicates representation of a characteristic-2 | |||
| skipping to change at page 21, line 33 ¶ | skipping to change at page 22, line 16 ¶ | |||
| select (SignatureAlgorithm) { | select (SignatureAlgorithm) { | |||
| case ecdsa: | case ecdsa: | |||
| digitally-signed struct { | digitally-signed struct { | |||
| opaque sha_hash[sha_size]; | opaque sha_hash[sha_size]; | |||
| }; | }; | |||
| } Signature; | } Signature; | |||
| NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange | NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange | |||
| algorithm and "anonymous" for ECDH_anon. These cases are defined in | algorithm and "anonymous" for ECDH_anon. These cases are defined in | |||
| TLS [2]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA | TLS [2][3]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA | |||
| signatures are generated and verified as described in Section 5.10. | signatures are generated and verified as described in Section 5.10. | |||
| As per ANSI X9.62, an ECDSA signature consists of a pair of integers | As per ANSI X9.62, an ECDSA signature consists of a pair of integers | |||
| r and s. These integers are both converted into byte strings of the | r and s. These integers are both converted into byte strings of the | |||
| same length as the curve order n using the conversion routine | same length as the curve order n using the conversion routine | |||
| specified in Section 4.3.1 of [6]. The two byte strings are | specified in Section 4.3.1 of [7]. The two byte strings are | |||
| concatenated, and the result is placed in the signature field. | concatenated, and the result is placed in the signature field. | |||
| Actions of the sender: | Actions of the sender: | |||
| The server selects elliptic curve domain parameters and an ephemeral | The server selects elliptic curve domain parameters and an ephemeral | |||
| ECDH public key corresponding to these parameters according to the | ECDH public key corresponding to these parameters according to the | |||
| ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to | ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to | |||
| the client in the ServerKeyExchange message using the format defined | the client in the ServerKeyExchange message using the format defined | |||
| above. | above. | |||
| Actions of the recipient: | Actions of the recipient: | |||
| The client verifies the signature (when present) and retrieves the | The client verifies the signature (when present) and retrieves the | |||
| server's elliptic curve domain parameters and ephemeral ECDH public | server's elliptic curve domain parameters and ephemeral ECDH public | |||
| key from the ServerKeyExchange message. | key from the ServerKeyExchange message. (A possible reason for a | |||
| fatal handshake failure is if the client's capabilities for handling | ||||
| elliptic curves and point formats are exceeded; cf. Section 5.1.) | ||||
| 5.5 Certificate Request | 5.5 Certificate Request | |||
| When this message is sent: | When this message is sent: | |||
| This message is sent when requesting client authentication. | This message is sent when requesting client authentication. | |||
| Meaning of this message: | Meaning of this message: | |||
| The server uses this message to suggest acceptable client | The server uses this message to suggest acceptable client | |||
| authentication methods. | authentication methods. | |||
| Structure of this message: | Structure of this message: | |||
| The TLS CertificateRequest message is extended as follows. | The TLS CertificateRequest message is extended as follows. | |||
| enum { | enum { | |||
| ecdsa_sign(??), rsa_fixed_ecdh(??), | ecdsa_sign(64), rsa_fixed_ecdh(65), | |||
| ecdsa_fixed_ecdh(??), (255) | ecdsa_fixed_ecdh(66), (255) | |||
| } ClientCertificateType; | } ClientCertificateType; | |||
| ecdsa_sign, etc Indicates that the server would like to use the | ecdsa_sign, etc Indicates that the server would like to use the | |||
| corresponding client authentication method specified in Section 3. | corresponding client authentication method specified in Section 3. | |||
| [[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and | [[ EDITOR: The above client certificate type numbers are | |||
| ecdsa_fixed_ecdh have been left as ??. These values will be | tentative! (See http://www.iana.org/assignments/tls-parameters | |||
| assigned when this draft progresses to RFC. Earlier versions of | for the registry.) Final assignments to the TLS | |||
| this draft used the values 5, 6, and 7 - however these values have | ClientCertificateType Identifiers Registry in accordance with [3] | |||
| been removed since they are used differently by SSL 3.0 [15] and | will be done by IANA. The values appearing in this Internet-Draft | |||
| their use by TLS is being deprecated. ]] | represent the authors' recommendations to IANA for assignments. ]] | |||
| Actions of the sender: | Actions of the sender: | |||
| The server decides which client authentication methods it would like | The server decides which client authentication methods it would like | |||
| to use, and conveys this information to the client using the format | to use, and conveys this information to the client using the format | |||
| defined above. | defined above. | |||
| Actions of the receiver: | Actions of the receiver: | |||
| The client determines whether it has a suitable certificate for use | The client determines whether it has a suitable certificate for use | |||
| skipping to change at page 25, line 28 ¶ | skipping to change at page 26, line 15 ¶ | |||
| struct { | struct { | |||
| select (KeyExchangeAlgorithm) { | select (KeyExchangeAlgorithm) { | |||
| case ec_diffie_hellman: ClientECDiffieHellmanPublic; | case ec_diffie_hellman: ClientECDiffieHellmanPublic; | |||
| } exchange_keys; | } exchange_keys; | |||
| } ClientKeyExchange; | } ClientKeyExchange; | |||
| Actions of the sender: | Actions of the sender: | |||
| The client selects an ephemeral ECDH public key corresponding to the | The client selects an ephemeral ECDH public key corresponding to the | |||
| parameters it received from the server according to the ECKAS-DH1 | parameters it received from the server according to the ECKAS-DH1 | |||
| scheme from IEEE 1363 [5]. It conveys this information to the client | scheme from IEEE 1363 [6]. It conveys this information to the client | |||
| in the ClientKeyExchange message using the format defined above. | in the ClientKeyExchange message using the format defined above. | |||
| Actions of the recipient: | Actions of the recipient: | |||
| The server retrieves the client's ephemeral ECDH public key from the | The server retrieves the client's ephemeral ECDH public key from the | |||
| ClientKeyExchange message and checks that it is on the same elliptic | ClientKeyExchange message and checks that it is on the same elliptic | |||
| curve as the server's ECDH key. | curve as the server's ECDH key. | |||
| 5.8 Certificate Verify | 5.8 Certificate Verify | |||
| skipping to change at page 26, line 24 ¶ | skipping to change at page 27, line 8 ¶ | |||
| opaque sha_hash[sha_size]; | opaque sha_hash[sha_size]; | |||
| }; | }; | |||
| } Signature; | } Signature; | |||
| For the ecdsa case, the signature field in the CertificateVerify | For the ecdsa case, the signature field in the CertificateVerify | |||
| message contains an ECDSA signature computed over handshake messages | message contains an ECDSA signature computed over handshake messages | |||
| exchanged so far. ECDSA signatures are computed as described in | exchanged so far. ECDSA signatures are computed as described in | |||
| Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a | Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a | |||
| pair of integers r and s. These integers are both converted into | 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 | byte strings of the same length as the curve order n using the | |||
| conversion routine specified in Section 4.3.1 of [6]. The two byte | conversion routine specified in Section 4.3.1 of [7]. The two byte | |||
| strings are concatenated, and the result is placed in the signature | strings are concatenated, and the result is placed in the signature | |||
| field. | field. | |||
| Actions of the sender: | Actions of the sender: | |||
| The client computes its signature over all handshake messages sent or | The client computes its signature over all handshake messages sent or | |||
| received starting at client hello up to but not including this | received starting at client hello up to but not including this | |||
| message. It uses the private key corresponding to its certified | message. It uses the private key corresponding to its certified | |||
| public key to compute the signature which is conveyed in the format | public key to compute the signature which is conveyed in the format | |||
| defined above. | defined above. | |||
| Actions of the receiver: | Actions of the receiver: | |||
| The server extracts the client's signature from the CertificateVerify | The server extracts the client's signature from the CertificateVerify | |||
| message, and verifies the signature using the public key it received | message, and verifies the signature using the public key it received | |||
| in the client's Certificate message. | in the client's Certificate message. | |||
| 5.9 Elliptic Curve Certificates | 5.9 Elliptic Curve Certificates | |||
| X509 certificates containing ECC public keys or signed using ECDSA | X.509 certificates containing ECC public keys or signed using ECDSA | |||
| MUST comply with [11] or another RFC that replaces or extends it. | MUST comply with [12] or another RFC that replaces or extends it. | |||
| Clients SHOULD use the elliptic curve domain parameters recommended | Clients SHOULD use the elliptic curve domain parameters recommended | |||
| in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. | in ANSI X9.62 [7], FIPS 186-2 [9], and SEC 2 [11]. | |||
| 5.10 ECDH, ECDSA and RSA Computations | 5.10 ECDH, ECDSA and RSA Computations | |||
| All ECDH calculations (including parameter and key generation as well | All ECDH calculations (including parameter and key generation as well | |||
| as the shared secret calculation) are performed according to [5] | as the shared secret calculation) are performed according to [6] | |||
| using the ECKAS-DH1 scheme with the identity map as key derivation | using the ECKAS-DH1 scheme with the identity map as key derivation | |||
| function, so that the premaster secret is the x-coordinate of the | function (KDF), so that the premaster secret is the x-coordinate of | |||
| ECDH shared secret elliptic curve point represented as an octet | the ECDH shared secret elliptic curve point represented as an octet | |||
| string. Note that this octet string (Z in IEEE 1363 terminology) as | string. Note that this octet string (Z in IEEE 1363 terminology) as | |||
| output by FE2OSP, the Field Element to Octet String Conversion | output by FE2OSP, the Field Element to Octet String Conversion | |||
| Primitive, has constant length for any given field; leading zeros | Primitive, has constant length for any given field; leading zeros | |||
| found in this octet string MUST NOT be truncated. | found in this octet string MUST NOT be truncated. | |||
| Note that a new extension may be introduced in the future to allow | (Note that this use of the identity KDF is a technicality. The | |||
| the use of a different KDF during computation of the premaster | complete picture is that ECDH is employed with a non-trivial KDF | |||
| secret. In this event, the new KDF would be used in place of the | because TLS does not directly use the premaster secret for anything | |||
| process detailed above. This may be desirable, for example, to | other than for computing the master secret. As of TLS 1.0 [2] and | |||
| support compatibility with the planned NIST key agreement standard. | 1.1 [3] this means that the MD5- and SHA-1-based TLS PRF serves as a | |||
| KDF; it is conceivable that future TLS versions or new TLS extensions | ||||
| All ECDSA computations MUST be performed according to ANSI X9.62 [6] | introduced in the future may vary this computation.) | |||
| All ECDSA computations MUST be performed according to ANSI X9.62 [7] | ||||
| or its successors. Data to be signed/verified is hashed and the | or its successors. Data to be signed/verified is hashed and the | |||
| result run directly through the ECDSA algorithm with no additional | result run directly through the ECDSA algorithm with no additional | |||
| hashing. The default hash function is SHA-1 [7] and sha_size (see | hashing. The default hash function is SHA-1 [8] and sha_size (see | |||
| Section 5.4 and Section 5.8) is 20. However, an alternative hash | Section 5.4 and Section 5.8) is 20. However, an alternative hash | |||
| function, such as one of the new SHA hash functions specified in FIPS | function, such as one of the new SHA hash functions specified in FIPS | |||
| 180-2 [7], may be used instead if the certificate containing the EC | 180-2 [8], may be used instead if the certificate containing the EC | |||
| public key explicitly requires use of another hash function. (The | public key explicitly requires use of another hash function. (The | |||
| mechanism for specifying the required hash function has not been | mechanism for specifying the required hash function has not been | |||
| standardized but this provision anticipates such standardization and | standardized but this provision anticipates such standardization and | |||
| obviates the need to update this document in response. Future PKIX | obviates the need to update this document in response. Future PKIX | |||
| RFCs may choose, for example, to specify the hash function to be used | RFCs may choose, for example, to specify the hash function to be used | |||
| with a public key in the parameters field of subjectPublicKeyInfo.) | with a public key in the parameters field of subjectPublicKeyInfo.) | |||
| All RSA signatures must be generated and verified according to PKCS#1 | All RSA signatures must be generated and verified according to PKCS#1 | |||
| [9] block type 1. | [10] block type 1. | |||
| 6. Cipher Suites | 6. Cipher Suites | |||
| The table below defines new ECC cipher suites that use the key | The table below defines new ECC cipher suites that use the key | |||
| exchange algorithms specified in Section 2. | exchange algorithms specified in Section 2. | |||
| CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x00 } | |||
| CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x01 } | |||
| CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0xC0, 0x02 } | |||
| CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 } | |||
| CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x04 } | |||
| CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x05 } | |||
| CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0xC0, 0x06 } | |||
| CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x07 } | |||
| CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x08 } | |||
| CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x09 } | |||
| CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0A } | |||
| CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0xC0, 0x0B } | |||
| CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0xC0, 0x0C } | |||
| CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x0D } | |||
| CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x0E } | |||
| CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0F } | |||
| CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0xC0, 0x10 } | |||
| CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0xC0, 0x11 } | |||
| CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x12 } | |||
| CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x13 } | |||
| CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x14 } | |||
| CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0xC0, 0x15 } | |||
| CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0xC0, 0x16 } | |||
| CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x17 } | |||
| CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0xC0, 0x18 } | |||
| CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } | CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0xC0, 0x19 } | |||
| Table 5: TLS ECC cipher suites | Table 5: TLS ECC cipher suites | |||
| [[ EDITOR: The actual cipher suite numbers will be assigned when this | [[ EDITOR: The above cipher suite numbers are tentative! (See | |||
| draft progresses to RFC. ]] | http://www.iana.org/assignments/tls-parameters for the registry.) | |||
| Final assignments to the TLS Cipher Suite Registry in accordance with | ||||
| [3] will be done by IANA. The values appearing in this Internet- | ||||
| Draft represent the authors' recommendations to IANA for assignments. | ||||
| ]] | ||||
| The key exchange method, cipher, and hash algorithm for each of these | The key exchange method, cipher, and hash algorithm for each of these | |||
| cipher suites are easily determined by examining the name. Ciphers | cipher suites are easily determined by examining the name. Ciphers | |||
| other than AES ciphers, and hash algorithms are defined in [2]. AES | other than AES ciphers, and hash algorithms are defined in [2] and | |||
| ciphers are defined in [16]. | [3]. AES ciphers are defined in [18]. | |||
| Server implementations SHOULD support all of the following cipher | Server implementations SHOULD support all of the following cipher | |||
| suites, and client implementations SHOULD support at least one of | suites, and client implementations SHOULD support at least one of | |||
| them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, | them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, | |||
| TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, | |||
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and | |||
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. | |||
| 7. Security Considerations | 7. Security Considerations | |||
| This document is based on [2], [5], [6] and [16]. The appropriate | Security issues are discussed throughout this memo. | |||
| security considerations of those documents apply. | ||||
| For TLS handshakes using ECC cipher suites, the security | ||||
| considerations in appendices D.2 and D.3 of [2] and [3] apply | ||||
| accordingly. | ||||
| Security discussions specific to ECC can be found in [6] and [7]. | ||||
| One important issue that implementors and users must consider is | One important issue that implementors and users must consider is | |||
| elliptic curve selection. Guidance on selecting an appropriate | elliptic curve selection. Guidance on selecting an appropriate | |||
| elliptic curve size is given in Table 1. | elliptic curve size is given in Table 1. | |||
| Beyond elliptic curve size, the main issue is elliptic curve | Beyond elliptic curve size, the main issue is elliptic curve | |||
| structure. As a general principle, it is more conservative to use | structure. As a general principle, it is more conservative to use | |||
| elliptic curves with as little algebraic structure as possible - thus | elliptic curves with as little algebraic structure as possible - thus | |||
| random curves are more conservative than special curves such as | random curves are more conservative than special curves such as | |||
| Koblitz curves, and curves over F_p with p random are more | Koblitz curves, and curves over F_p with p random are more | |||
| conservative than curves over F_p with p of a special form (and | conservative than curves over F_p with p of a special form (and | |||
| curves over F_p with p random might be considered more conservative | curves over F_p with p random might be considered more conservative | |||
| than curves over F_2^m as there is no choice between multiple fields | than curves over F_2^m as there is no choice between multiple fields | |||
| of similar size for characteristic 2). Note, however, that algebraic | of similar size for characteristic 2). Note, however, that algebraic | |||
| structure can also lead to implementation efficiencies and | structure can also lead to implementation efficiencies and | |||
| implementors and users may, therefore, need to balance conservatism | implementors and users may, therefore, need to balance conservatism | |||
| against a need for efficiency. Concrete attacks are known against | against a need for efficiency. Concrete attacks are known against | |||
| only very few special classes of curves, such as supersingular | only very few special classes of curves, such as supersingular | |||
| curves, and these classes are excluded from the ECC standards that | curves, and these classes are excluded from the ECC standards that | |||
| this document references [5], [6]. | this document references [6], [7]. | |||
| Another issue is the potential for catastrophic failures when a | Another issue is the potential for catastrophic failures when a | |||
| single elliptic curve is widely used. In this case, an attack on the | single elliptic curve is widely used. In this case, an attack on the | |||
| elliptic curve might result in the compromise of a large number of | elliptic curve might result in the compromise of a large number of | |||
| keys. Again, this concern may need to be balanced against efficiency | keys. Again, this concern may need to be balanced against efficiency | |||
| and interoperability improvements associated with widely-used curves. | and interoperability improvements associated with widely-used curves. | |||
| Substantial additional information on elliptic curve choice can be | Substantial additional information on elliptic curve choice can be | |||
| found in [4], [5], [6], [8]. | found in [5], [6], [7], [9]. | |||
| Implementors and users must also consider whether they need forward | Implementors and users must also consider whether they need forward | |||
| secrecy. Forward secrecy refers to the property that session keys | secrecy. Forward secrecy refers to the property that session keys | |||
| are not compromised if the static, certified keys belonging to the | are not compromised if the static, certified keys belonging to the | |||
| server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key | server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key | |||
| exchange algorithms provide forward secrecy protection in the event | exchange algorithms provide forward secrecy protection in the event | |||
| of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. | of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. | |||
| Similarly if the client is providing a static, certified key, | Similarly if the client is providing a static, certified key, | |||
| ECDSA_sign client authentication provides forward secrecy protection | ECDSA_sign client authentication provides forward secrecy protection | |||
| in the event of client key compromise, while ECDSA_fixed_ECDH and | in the event of client key compromise, while ECDSA_fixed_ECDH and | |||
| skipping to change at page 31, line 19 ¶ | skipping to change at page 33, line 19 ¶ | |||
| o NamedCurve (Section 5.1) | o NamedCurve (Section 5.1) | |||
| o ECPointFormat (Section 5.1) | o ECPointFormat (Section 5.1) | |||
| o ECCurveType (Section 5.4) | o ECCurveType (Section 5.4) | |||
| For each name space, this document defines the initial value | For each name space, this document defines the initial value | |||
| assignments and defines a range of 256 values (NamedCurve) or eight | assignments and defines a range of 256 values (NamedCurve) or eight | |||
| values (ECPointFormat and ECCurveType) reserved for Private Use. Any | values (ECPointFormat and ECCurveType) reserved for Private Use. Any | |||
| additional assignments require IETF Consensus action [12]. | additional assignments require IETF Consensus action [14]. | |||
| [[ EDITOR: This documents also contains assignments to the registry | ||||
| for TLS ciphersuites defined in [4], and to the TLS Cipher Suite | ||||
| Registry and the TLS ClientCertificateType Identifiers Registry | ||||
| defined in [3]. All of these are currently marked as tentative since | ||||
| final assignments will have to be by IANA; see "EDITOR" notes in | ||||
| Section 5.1 (and Section 5.1.1 and Section 5.1.1), Section 5.5, and | ||||
| Section 6. ]] | ||||
| 9. Acknowledgments | 9. Acknowledgments | |||
| The authors wish to thank Bill Anderson and Tim Dierks. | The authors wish to thank Bill Anderson and Tim Dierks. | |||
| 10. References | 10. References | |||
| 10.1 Normative References | 10.1 Normative References | |||
| [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement | [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement | |||
| Levels", RFC 2119, March 1997. | Levels", RFC 2119, March 1997. | |||
| [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | |||
| RFC 2246, January 1999. | RFC 2246, January 1999. | |||
| [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and | [3] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", | |||
| draft-ietf-tls-rfc2246bis-13.txt (work in progress), June 2005. | ||||
| [[ EDITOR: The cited Internet-Draft has been approved by the | ||||
| IESG; the citation will have to be changed once it has been | ||||
| published as RFC. ]] | ||||
| [4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and | ||||
| T. Wright, "Transport Layer Security (TLS) Extensions", | T. Wright, "Transport Layer Security (TLS) Extensions", | |||
| draft-ietf-tls-rfc3546bis-01.txt (work in progress), May 2005. | draft-ietf-tls-rfc3546bis-02.txt (work in progress), | |||
| September 2005. | ||||
| [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, | [[ EDITOR: The cited Internet-Draft has been approved by the | |||
| IESG; the citation will have to be changed once it has been | ||||
| published as RFC. ]] | ||||
| [5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, | ||||
| <http://www.secg.org/>. | <http://www.secg.org/>. | |||
| [5] IEEE, "Standard Specifications for Public Key Cryptography", | [6] IEEE, "Standard Specifications for Public Key Cryptography", | |||
| IEEE 1363, 2000. | IEEE 1363, 2000. | |||
| [6] ANSI, "Public Key Cryptography For The Financial Services | [7] ANSI, "Public Key Cryptography For The Financial Services | |||
| Industry: The Elliptic Curve Digital Signature Algorithm | Industry: The Elliptic Curve Digital Signature Algorithm | |||
| (ECDSA)", ANSI X9.62, 1998. | (ECDSA)", ANSI X9.62, 1998. | |||
| [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. | [8] NIST, "Secure Hash Standard", FIPS 180-2, 2002. | |||
| [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. | [9] NIST, "Digital Signature Standard", FIPS 186-2, 2000. | |||
| [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version | [10] RSA Laboratories, "PKCS#1: RSA Encryption Standard version | |||
| 1.5", PKCS 1, November 1993. | 1.5", PKCS 1, November 1993. | |||
| [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, | [11] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, | |||
| 2000, <http://www.secg.org/>. | 2000, <http://www.secg.org/>. | |||
| [11] Polk, T., Housley, R., and L. Bassham, "Algorithms and | [12] Polk, T., Housley, R., and L. Bassham, "Algorithms and | |||
| Identifiers for the Internet X.509 Public Key Infrastructure | Identifiers for the Internet X.509 Public Key Infrastructure | |||
| Certificate and Certificate Revocation List (CRL) Profile", | Certificate and Certificate Revocation List (CRL) Profile", | |||
| RFC 3279, April 2002. | RFC 3279, April 2002. | |||
| [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | [13] Housley, R., Polk, T., Ford, W., and D. Solo, "Internet X.509 | |||
| Public Key Infrastructure Certificate and Certificate | ||||
| Revocation List (CRL) Profile", RFC 3280, April 2002. | ||||
| [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | ||||
| Considerations Section in RFCs", RFC 2434, October 1998. | Considerations Section in RFCs", RFC 2434, October 1998. | |||
| 10.2 Informative References | 10.2 Informative References | |||
| [13] Harper, G., Menezes, A., and S. Vanstone, "Public-Key | [15] Harper, G., Menezes, A., and S. Vanstone, "Public-Key | |||
| Cryptosystems with Very Small Key Lengths", Advances in | Cryptosystems with Very Small Key Lengths", Advances in | |||
| Cryptology -- EUROCRYPT '92, LNCS 658, 1993. | Cryptology -- EUROCRYPT '92, LNCS 658, 1993. | |||
| [14] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key | [16] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key | |||
| Sizes", Journal of Cryptology 14 (2001) 255-293, | Sizes", Journal of Cryptology 14 (2001) 255-293, | |||
| <http://www.cryptosavvy.com/>. | <http://www.cryptosavvy.com/>. | |||
| [15] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol | [17] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol | |||
| Version 3.0", November 1996, | Version 3.0", November 1996, | |||
| <http://wp.netscape.com/eng/ssl3/draft302.txt>. | <http://wp.netscape.com/eng/ssl3/draft302.txt>. | |||
| [16] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for | [18] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for | |||
| Transport Layer Security (TLS)", RFC 3268, June 2002. | Transport Layer Security (TLS)", RFC 3268, June 2002. | |||
| Authors' Addresses | Authors' Addresses | |||
| Simon Blake-Wilson | ||||
| Basic Commerce & Industries, Inc. | ||||
| 96 Spandia Ave | ||||
| Unit 606 | ||||
| Toronto, ON M6G 2T6 | ||||
| CA | ||||
| Phone: +1 416 214 5961 | ||||
| Email: sblakewilson@bcisse.com | ||||
| Nelson Bolyard | ||||
| Sun | ||||
| Email: nelson@bolyard.com | ||||
| Vipul Gupta | Vipul Gupta | |||
| Sun Microsystems Laboratories | Sun Microsystems Laboratories | |||
| 16 Network Circle | 16 Network Circle | |||
| MS UMPK16-160 | MS UMPK16-160 | |||
| Menlo Park, CA 94025 | Menlo Park, CA 94025 | |||
| US | US | |||
| Phone: +1 650 786 7551 | Phone: +1 650 786 7551 | |||
| Email: vipul.gupta@sun.com | Email: vipul.gupta@sun.com | |||
| Simon Blake-Wilson | Chris Hawk | |||
| Basic Commerce & Industries, Inc. | Corriente Networks LLC | |||
| 96 Spandia Ave | 1563 Solano Ave., #484 | |||
| Unit 606 | Berkeley, CA 94707 | |||
| Toronto, ON M6G 2T6 | US | |||
| CA | ||||
| Phone: +1 416 214 5961 | Phone: +1 510 527 0601 | |||
| Email: sblakewilson@bcisse.com | Email: chris@corriente.net | |||
| Bodo Moeller | Bodo Moeller | |||
| University of Calgary | University of Calgary | |||
| Dept of Math & Stats | Dept of Math & Stats | |||
| 2500 University Dr NW | 2500 University Dr NW | |||
| Calgary, AB T2N 1N4 | Calgary, AB T2N 1N4 | |||
| CA | CA | |||
| Phone: +1 403 220 5735 | Phone: +1 403 220 5735 | |||
| Email: bodo@openssl.org | Email: bodo@openssl.org | |||
| Chris Hawk | ||||
| Corriente Networks | ||||
| Email: chris@corriente.net | ||||
| Nelson Bolyard | ||||
| Email: nelson@bolyard.com | ||||
| Intellectual Property Statement | Intellectual Property Statement | |||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
| might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
| made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
| on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
| End of changes. 101 change blocks. | ||||
| 259 lines changed or deleted | 321 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||