idnits 2.17.1 draft-ietf-tls-ecc-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1487. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 821 has weird spacing: '...rveType cur...' == Line 834 has weird spacing: '... opaque k <1....' == Line 836 has weird spacing: '... opaque k1 <1...' == Line 837 has weird spacing: '... opaque k2 <1...' == Line 838 has weird spacing: '... opaque k3 <1...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2005) is 6728 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 224 == Unused Reference: '15' is defined on line 1405, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1413, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) -- No information found for draft-ietf-tls-rfc2246bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 3280 (ref. '13') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2434 (ref. '14') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3268 (ref. '18') (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group S. Blake-Wilson 3 Internet-Draft BCI 4 Expires: April 20, 2006 N. Bolyard 5 Sun 6 V. Gupta 7 Sun Labs 8 C. Hawk 9 Corriente 10 B. Moeller 11 University of Calgary 12 October 17, 2005 14 ECC Cipher Suites for TLS 15 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 20, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This document describes new key exchange algorithms based on Elliptic 49 Curve Cryptography (ECC) for the TLS (Transport Layer Security) 50 protocol. In particular, it specifies the use of Elliptic Curve 51 Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of 52 Elliptic Curve Digital Signature Algorithm (ECDSA) as a new 53 authentication mechanism. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 5 59 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7 61 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 9 65 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10 67 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 68 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . . 11 69 5. Data Structures and Computations . . . . . . . . . . . . . . . 12 70 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12 71 5.1.1 Supported Elliptic Curves Extension . . . . . . . . . 13 72 5.1.2 Supported Point Formats Extension . . . . . . . . . . 15 73 5.2 Server Hello Extension . . . . . . . . . . . . . . . . . . 16 74 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 17 75 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18 76 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22 77 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23 78 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 25 79 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 26 80 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 27 81 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . 27 82 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 29 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 87 10.1 Normative References . . . . . . . . . . . . . . . . . . . 35 88 10.2 Informative References . . . . . . . . . . . . . . . . . . 36 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36 90 Intellectual Property and Copyright Statements . . . . . . . . 38 92 1. Introduction 94 Elliptic Curve Cryptography (ECC) is emerging as an attractive 95 public-key cryptosystem, in particular for mobile (i.e., wireless) 96 environments. Compared to currently prevalent cryptosystems such as 97 RSA, ECC offers equivalent security with smaller key sizes. This is 98 illustrated in the following table, based on [16], which gives 99 approximate comparable key sizes for symmetric- and asymmetric-key 100 cryptosystems based on the best-known algorithms for attacking them. 102 Symmetric | ECC | DH/DSA/RSA 103 ------------+---------+------------- 104 80 | 163 | 1024 105 112 | 233 | 2048 106 128 | 283 | 3072 107 192 | 409 | 7680 108 256 | 571 | 15360 110 Table 1: Comparable key sizes (in bits) 112 Smaller key sizes result in savings for power, memory, bandwidth, and 113 computational cost that make ECC especially attractive for 114 constrained environments. 116 This document describes additions to TLS to support ECC, applicable 117 both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In 118 particular, it defines 120 o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement 121 scheme with long-term or ephemeral keys to establish the TLS 122 premaster secret, and 124 o the use of fixed-ECDH certificates and ECDSA for authentication of 125 TLS peers. 127 The remainder of this document is organized as follows. Section 2 128 provides an overview of ECC-based key exchange algorithms for TLS. 129 Section 3 describes the use of ECC certificates for client 130 authentication. TLS extensions that allow a client to negotiate the 131 use of specific curves and point formats are presented in Section 4. 132 Section 5 specifies various data structures needed for an ECC-based 133 handshake, their encoding in TLS messages and the processing of those 134 messages. Section 6 defines new ECC-based cipher suites and 135 identifies a small subset of these as recommended for all 136 implementations of this specification. Section 7 discusses security 137 considerations. Section 8 describes IANA considerations for the name 138 spaces created by this document. Section 9 gives acknowledgments. 140 This is followed by the lists of normative and informative references 141 cited in this document, the authors' contact information, and 142 statements on intellectual property rights and copyrights. 144 Implementation of this specification requires familiarity with TLS 145 [2][3], TLS extensions [4], and ECC [5][6][7][9]. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [1]. 151 2. Key Exchange Algorithms 153 This document introduces five new ECC-based key exchange algorithms 154 for TLS. All of them use ECDH to compute the TLS premaster secret 155 and differ only in the lifetime of ECDH keys (long-term or ephemeral) 156 and the mechanism (if any) used to authenticate them. The derivation 157 of the TLS master secret from the premaster secret and the subsequent 158 generation of bulk encryption/MAC keys and initialization vectors is 159 independent of the key exchange algorithm and not impacted by the 160 introduction of ECC. 162 The table below summarizes the new key exchange algorithms which 163 mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and 164 [3]), respectively. 166 Key 167 Exchange 168 Algorithm Description 169 --------- ----------- 171 ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. 173 ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. 175 ECDH_RSA Fixed ECDH with RSA-signed certificates. 177 ECDHE_RSA Ephemeral ECDH with RSA signatures. 179 ECDH_anon Anonymous ECDH, no signatures. 181 Table 2: ECC key exchange algorithms 183 The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward 184 secrecy. With ECDHE_RSA, a server can reuse its existing RSA 185 certificate and easily comply with a constrained client's elliptic 186 curve preferences (see Section 4). However, the computational cost 187 incurred by a server is higher for ECDHE_RSA than for the traditional 188 RSA key exchange which does not provide forward secrecy. 190 The ECDH_RSA mechanism requires a server to acquire an ECC 191 certificate but the certificate issuer can still use an existing RSA 192 key for signing. This eliminates the need to update the keys of 193 trusted certificiation authorities accepted by TLS clients. The 194 ECDH_ECDSA mechanism requires ECC keys for the server as well as the 195 certification authority and is best suited for constrained devices 196 unable to support RSA. 198 The anonymous key exchange algorithm does not provide authentication 199 of the server or the client. Like other anonymous TLS key exchanges, 200 it is subject to man-in-the-middle attacks. Implementations of this 201 algorithm SHOULD provide authentication by other means. 203 Note that there is no structural difference between ECDH and ECDSA 204 keys. A certificate issuer may use X.509 v3 keyUsage and 205 extendedKeyUsage extensions to restrict the use of an ECC public key 206 to certain computations [13]. This document refers to an ECC key as 207 ECDH-capable if its use in ECDH is permitted. ECDSA-capable is 208 defined similarly. 210 Client Server 211 ------ ------ 213 ClientHello --------> 214 ServerHello 215 Certificate* 216 ServerKeyExchange* 217 CertificateRequest*+ 218 <-------- ServerHelloDone 219 Certificate*+ 220 ClientKeyExchange 221 CertificateVerify*+ 222 [ChangeCipherSpec] 223 Finished --------> 224 [ChangeCipherSpec] 225 <-------- Finished 227 Application Data <-------> Application Data 229 * message is not sent under some conditions 230 + message is not sent unless client authentication 231 is desired 233 Figure 1: Message flow in a full TLS handshake 235 Figure 1 shows all messages involved in the TLS key establishment 236 protocol (aka full handshake). The addition of ECC has direct impact 237 only on the ClientHello, the ServerHello, the server's Certificate 238 message, the ServerKeyExchange, the ClientKeyExchange, the 239 CertificateRequest, the client's Certificate message, and the 240 CertificateVerify. Next, we describe each ECC key exchange algorithm 241 in greater detail in terms of the content and processing of these 242 messages. For ease of exposition, we defer discussion of client 243 authentication and associated messages (identified with a + in 244 Figure 1) until Section 3 and of the optional ECC-specific extensions 245 (which impact the Hello messages) until Section 4. 247 2.1 ECDH_ECDSA 249 In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable 250 public key and be signed with ECDSA. 252 A ServerKeyExchange MUST NOT be sent (the server's certificate 253 contains all the necessary keying information required by the client 254 to arrive at the premaster secret). 256 The client generates an ECDH key pair on the same curve as the 257 server's long-term public key and send its public key in the 258 ClientKeyExchange message (except when using client authentication 259 algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the 260 modifications from Section 3.2 or Section 3.3 apply). 262 Both client and server perform an ECDH operation and use the 263 resultant shared secret as the premaster secret. All ECDH 264 calculations are performed as specified in Section 5.10. 266 2.2 ECDHE_ECDSA 268 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- 269 capable public key and be signed with ECDSA. 271 The server sends its ephemeral ECDH public key and a specification of 272 the corresponding curve in the ServerKeyExchange message. These 273 parameters MUST be signed with ECDSA using the private key 274 corresponding to the public key in the server's Certificate. 276 The client generates an ECDH key pair on the same curve as the 277 server's ephemeral ECDH key and send its public key in the 278 ClientKeyExchange message. 280 Both client and server perform an ECDH operation (Section 5.10) and 281 use the resultant shared secret as the premaster secret. 283 2.3 ECDH_RSA 285 This key exchange algorithm is the same as ECDH_ECDSA except the 286 server's certificate MUST be signed with RSA rather than ECDSA. 288 2.4 ECDHE_RSA 290 This key exchange algorithm is the same as ECDHE_ECDSA except the 291 server's certificate MUST contain an RSA public key authorized for 292 signing and the signature in the ServerKeyExchange message must be 293 computed with the corresponding RSA private key. The server 294 certificate MUST be signed with RSA. 296 2.5 ECDH_anon 298 In ECDH_anon, the server's Certificate, the CertificateRequest, the 299 client's Certificate, and the CertificateVerify messages MUST NOT be 300 sent. 302 The server MUST send an ephemeral ECDH public key and a specification 303 of the corresponding curve in the ServerKeyExchange message. These 304 parameters MUST NOT be signed. 306 The client generates an ECDH key pair on the same curve as the 307 server's ephemeral ECDH key and send its public key in the 308 ClientKeyExchange message. 310 Both client and server perform an ECDH operation and use the 311 resultant shared secret as the premaster secret. All ECDH 312 calculations are performed as specified in Section 5.10. 314 Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA 315 key exchange algorithms require the server's certificate to be signed 316 with a particular signature scheme, this specification (following the 317 similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3]) 318 does not impose restrictions on signature schemes used elsewhere in 319 the certificate chain. (Often such restrictions will be useful, and 320 it is expected that this will be taken into account in certification 321 authorities' signing practices. However, such restrictions are not 322 strictly required in general: Even if it is beyond the capabilities 323 of a client to completely validate a given chain, the client may be 324 able to validate the server's certificate by relying on a trusted 325 certification authority whose certificate appears as one of the 326 intermediate certificates in the chain.) 328 3. Client Authentication 330 This document defines three new client authentication mechanisms 331 named after the type of client certificate involved: ECDSA_sign, 332 ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is 333 usable with any of the non-anonymous ECC key exchange algorithms 334 described in Section 2 as well as other non-anonymous (non-ECC) key 335 exchange algorithms defined in TLS [2][3]. The ECDSA_fixed_ECDH and 336 RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. 337 Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the 338 use of a long-term ECDH client key would jeopardize the forward 339 secrecy property of these algorithms. 341 The server can request ECC-based client authentication by including 342 one or more of these certificate types in its CertificateRequest 343 message. The server must not include any certificate types that are 344 prohibited for the negotiated key exchange algorithm. The client 345 must check if it possesses a certificate appropriate for any of the 346 methods suggested by the server and is willing to use it for 347 authentication. 349 If these conditions are not met, the client should send a client 350 Certificate message containing no certificates. In this case, the 351 ClientKeyExchange should be sent as described in Section 2 and the 352 CertificateVerify should not be sent. If the server requires client 353 authentication, it may respond with a fatal handshake failure alert. 355 If the client has an appropriate certificate and is willing to use it 356 for authentication, it must send that certificate in the client's 357 Certificate message (as per Section 5.6) and prove possession of the 358 private key corresponding to the certified key. The process of 359 determining an appropriate certificate and proving possession is 360 different for each authentication mechanism and described below. 362 NOTE: It is permissible for a server to request (and the client to 363 send) a client certificate of a different type than the server 364 certificate. 366 3.1 ECDSA_sign 368 To use this authentication mechanism, the client MUST possess a 369 certificate containing an ECDSA-capable public key and signed with 370 ECDSA. 372 The client proves possession of the private key corresponding to the 373 certified key by including a signature in the CertificateVerify 374 message as described in Section 5.8. 376 3.2 ECDSA_fixed_ECDH 378 To use this authentication mechanism, the client MUST possess a 379 certificate containing an ECDH-capable public key and that 380 certificate MUST be signed with ECDSA. Furthermore, the client's 381 ECDH key MUST be on the same elliptic curve as the server's long-term 382 (certified) ECDH key. This might limit use of this mechanism to 383 closed environments. In situations where the client has an ECC key 384 on a different curve, it would have to authenticate either using 385 ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for 386 both servers and clients is computationally more efficient than 387 mechanisms providing forward secrecy. 389 When using this authentication mechanism, the client MUST send an 390 empty ClientKeyExchange as described in Section 5.7 and MUST NOT send 391 the CertificateVerify message. The ClientKeyExchange is empty since 392 the client's ECDH public key required by the server to compute the 393 premaster secret is available inside the client's certificate. The 394 client's ability to arrive at the same premaster secret as the server 395 (demonstrated by a successful exchange of Finished messages) proves 396 possession of the private key corresponding to the certified public 397 key and the CertificateVerify message is unnecessary. 399 3.3 RSA_fixed_ECDH 401 This authentication mechanism is identical to ECDSA_fixed_ECDH except 402 the client's certificate MUST be signed with RSA. 404 Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH 405 client authentication mechanisms require the clients's certificate to 406 be signed with a particular signature scheme, this specification does 407 not impose restrictions on signature schemes used elsewhere in the 408 certificate chain. (Often such restrictions will be useful, and it 409 is expected that this will be taken into account in certification 410 authorities' signing practices. However, such restrictions are not 411 strictly required in general: Even if it is beyond the capabilities 412 of a server to completely validate a given chain, the server may be 413 able to validate the clients certificate by relying on a trust anchor 414 that appears as one of the intermediate certificates in the chain.) 416 4. TLS Extensions for ECC 418 Two new TLS extensions are defined in this specification: (i) the 419 Supported Elliptic Curves Extension, and (ii) the Supported Point 420 Formats Extension. These allow negotiating the use of specific 421 curves and point formats (e.g. compressed vs. uncompressed), 422 respectively, during a handshake starting a new session. These 423 extensions are especially relevant for constrained clients that may 424 only support a limited number of curves or point formats. They 425 follow the general approach outlined in [4]; message details are 426 specified in Section 5. The client enumerates the curves it supports 427 and the point formats it can parse by including the appropriate 428 extensions in its ClientHello message. The server similarly 429 enumerates the point formats it can parse by including an extension 430 in its ServerHello message. 432 A TLS client that proposes ECC cipher suites in its ClientHello 433 message SHOULD include these extensions. Servers implementing ECC 434 cipher suites MUST support these extensions, and when a client uses 435 these extensions, servers MUST NOT negotiate the use of an ECC cipher 436 suite unless they can complete the handshake while respecting the 437 choice of curves and compression techniques specified by the client. 438 This eliminates the possibility that a negotiated ECC handshake will 439 be subsequently aborted due to a client's inability to deal with the 440 server's EC key. 442 The client MUST NOT include these extensions in the ClientHello 443 message if it does not propose any ECC cipher suites. A client that 444 proposes ECC cipher suites may choose not to include these extension. 445 In this case, the server is free to choose any one of the elliptic 446 curves or point formats listed in Section 5. That section also 447 describes the structure and processing of these extensions in greater 448 detail. 450 In the case of session resumption, the server simply ignores the 451 Supported Elliptic Curves Extension and the Supported Point Formats 452 Extension as appearing in the current ClientHello message. These 453 extensions only play a role during handshakes negotiating a new 454 session. 456 5. Data Structures and Computations 458 This section specifies the data structures and computations used by 459 ECC-based key mechanisms specified in Section 2, Section 3 and 460 Section 4. The presentation language used here is the same as that 461 used in TLS [2][3]. Since this specification extends TLS, these 462 descriptions should be merged with those in the TLS specification and 463 any others that extend TLS. This means that enum types may not 464 specify all possible values and structures with multiple formats 465 chosen with a select() clause may not indicate all possible cases. 467 5.1 Client Hello Extensions 469 This section specifies two TLS extensions that can be included with 470 the ClientHello message as described in [4], the Supported Elliptic 471 Curves Extension and the Supported Point Formats Extension. 473 When these extensions are sent: 475 The extensions SHOULD be sent along with any ClientHello message that 476 proposes ECC cipher suites. 478 Meaning of these extensions: 480 These extensions allow a client to enumerate the elliptic curves it 481 supports and/or the point formats it can parse. 483 Structure of these extensions: 485 The general structure of TLS extensions is described in [4] and this 486 specification adds two new types to ExtensionType. 488 enum { elliptic_curves(10), ec_point_formats(11) } ExtensionType; 490 [[ EDITOR: The values "10" and "11" used for the new extensions are 491 tentative! (They were picked to avoid conflicts with other emerging 492 specifications; see http://people.nokia.net/~pasi/tls-numbers.txt .) 493 Final assignments in accordance with [4] will be done by IANA. The 494 values appearing in this Internet-Draft represent the authors' 495 recommendations to IANA for assignments. ]] 497 elliptic_curves (Supported Elliptic Curves Extension): Indicates the 498 set of elliptic curves supported by the client. For this 499 extension, the opaque extension_data field contains 500 EllipticCurveList. See Section 5.1.1 for details. 502 ec_point_formats (Supported Point Formats Extension): Indicates the 503 set of point formats that the client can parse. For this 504 extension, the opaque extension_data field contains 505 ECPointFormatList. See Section 5.1.2 for details. 507 Actions of the sender: 509 A client that proposes ECC cipher suites in its ClientHello message 510 appends these extensions (along with any others), enumerating the 511 curves it supports and the point formats it can parse. Clients 512 SHOULD send both the Supported Elliptic Curves Extension and the 513 Supported Point Formats Extension. If the Supported Point Formats 514 Extension is indeed sent, it MUST contain the value 0 (uncompressed) 515 as one of the items in the list of point formats. 517 Actions of the receiver: 519 A server that receives a ClientHello containing one or both of these 520 extensions MUST use the client's enumerated capabilities to guide its 521 selection of an appropriate cipher suite. One of the proposed ECC 522 cipher suites must be negotiated only if the server can successfully 523 complete the handshake while using the curves and point formats 524 supported by the client (cf. Section 5.3 and Section 5.4). 526 NOTE: A server participating in an ECDHE-ECDSA key exchange may use 527 different curves for (i) the ECDSA key in its certificate, and (ii) 528 the ephemeral ECDH key in the ServerKeyExchange message. The server 529 must consider the extensions in both cases. 531 If a server does not understand the Supported Elliptic Curves 532 Extension or does not understand the Supported Point Formates 533 Extension or is unable to complete the ECC handshake while 534 restricting itself to the enumerated curves and point formats, it 535 MUST NOT negotiate the use of an ECC cipher suite. Depending on what 536 other cipher suites are proposed by the client and supported by the 537 server, this may result in a fatal handshake failure alert due to the 538 lack of common cipher suites. 540 5.1.1 Supported Elliptic Curves Extension 541 enum { 542 sect163k1 (1), sect163r1 (2), sect163r2 (3), 543 sect193r1 (4), sect193r2 (5), sect233k1 (6), 544 sect233r1 (7), sect239k1 (8), sect283k1 (9), 545 sect283r1 (10), sect409k1 (11), sect409r1 (12), 546 sect571k1 (13), sect571r1 (14), secp160k1 (15), 547 secp160r1 (16), secp160r2 (17), secp192k1 (18), 548 secp192r1 (19), secp224k1 (20), secp224r1 (21), 549 secp256k1 (22), secp256r1 (23), secp384r1 (24), 550 secp521r1 (25), 551 reserved (0xFE00..0xFEFF), 552 arbitrary_explicit_prime_curves(0xFF01), 553 arbitrary_explicit_char2_curves(0xFF02), 554 (0xFFFF) 555 } NamedCurve; 557 sect163k1, etc: Indicates support of the corresponding named curve 558 or class of explicitly defined curves. The named curves defined 559 here are those specified in SEC 2 [11]. Note that many of these 560 curves are also recommended in ANSI X9.62 [7] and FIPS 186-2 [9]. 561 Values 0xFE00 through 0xFEFF are reserved for private use. Values 562 0xFF01 and 0xFF02 indicate that the client supports arbitrary 563 prime and characteristic-2 curves, respectively (the curve 564 parameters must be encoded explicitly in ECParameters). 566 The NamedCurve name space is maintained by IANA. See Section 8 for 567 information on how new value assignments are added. 569 struct { 570 NamedCurve elliptic_curve_list<1..2^8-1> 571 } EllipticCurveList; 573 Items in elliptic_curve_list are ordered according to the client's 574 preferences (favorite choice first). 576 As an example, a client that only supports secp192r1 (aka NIST P-192; 577 value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) 578 and prefers to use secp192r1 would include a TLS extension consisting 579 of the following octets; note that the first two octets indicate the 580 extension type (Supported Elliptic Curves Extension): 582 00 0A 00 06 00 04 00 13 00 15 584 A client that supports arbitrary explicit characteristic-2 curves 585 (value 0xFF02) would include an extension consisting of the following 586 octets: 588 00 0A 00 04 00 02 FF 02 590 [[ EDITOR: As noted above, the extension type value appearing in this 591 example is tentative. ]] 593 5.1.2 Supported Point Formats Extension 595 enum { uncompressed (0), ansiX962_compressed_prime (1), 596 ansiX962_compressed_char2 (2), reserved (248..255) 597 } ECPointFormat; 599 struct { 600 ECPointFormat ec_point_format_list<1..2^8-1> 601 } ECPointFormatList; 603 Three point formats are included in the definition of ECPointFormat 604 above. The uncompressed point format is the default format in that 605 implementations of this document MUST support it for all of their 606 supported curves. Compressed point formats reduce bandwidth by 607 including only the x-coordinate and a single bit of the y-coordinate 608 of the point. Implementations of this document MAY support the 609 ansiX962_compressed_prime and ansiX962_compressed_char2 formats, 610 where the former applies only to prime curves and the latter applies 611 only to characteristic-2 curves. (These formats are specified in 612 [7].) Values 248 through 255 are reserved for private use. 614 The ECPointFormat name space is maintained by IANA. See Section 8 615 for information on how new value assignments are added. 617 Items in ec_point_format_list are ordered according to the client's 618 preferences (favorite choice first). 620 A client that can parse only the uncompressed point format (value 0) 621 includes an extension consisting of the following octets; note that 622 the first two octets indicate the extension type (Supported Point 623 Formats Extension): 625 00 0B 00 02 01 00 627 A client that in the case of prime fields prefers the compressed 628 format (ansiX962_compressed_prime, value 1) over the uncompressed 629 format (value 0), but in the case of characteristic-2 fields prefers 630 the uncompressed format (value 0) over the compressed format 631 (ansiX962_compressed_char2, value 2), may indicate these preferences 632 by including an extension consisting of the following octets: 634 00 0B 00 04 03 01 00 02 636 [[ EDITOR: As noted above, the extension type value appearing in this 637 example is tentative. ]] 639 5.2 Server Hello Extension 641 This section specifies a TLS extension that can be included with the 642 ServerHello message as described in [4], the Supported Point Formats 643 Extension. 645 When this extension is sent: 647 The Supported Point Formats Extension is included in a ServerHello 648 message in response to a ClientHello message containing the Supported 649 Point Formats Extension when negotiating an ECC cipher suite. 651 Meaning of this extensions: 653 This extension allows a server to enumerate the point formats it can 654 parse (for the curve that will appear in its ServerKeyExchange 655 message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key 656 exchange algorithm, or for the curve that is used in the server's 657 public key that will appear in its Certificate message when using the 658 ECDH_ECDSA or ECDH_RSA key exchange algorithm). 660 Structure of this extension: 662 The server's Supported Point Formats Extension has the same structure 663 as the client's Supported Point Formats Extension (see 664 Section 5.1.2). Items in elliptic_curve_list here are ordered 665 according to the server's preference (favorite choice first). Note 666 that the server may include items that were not found in the client's 667 list (e.g., the server may prefer to receive points in compressed 668 format even when a client cannot parse this format: the same client 669 may nevertheless be capable to output points in compressed format). 671 Actions of the sender: 673 A server that selects an ECC cipher suite in response to a 674 ClientHello message including a Supported Point Formats Extension 675 appends this extension (along with others) to its ServerHello 676 message, enumerating the point formats it can parse. The Supported 677 Point Formats Extension, when used, MUST contain the value 0 678 (uncompressed) as one of the items in the list of point formats. 680 Actions of the receiver: 682 A client that receives a ServerHello message containing a Supported 683 Point Formats Extension MUST respect the server's choice of point 684 formats during the handshake (cf. Section 5.6 and Section 5.7). If 685 no Supported Point Formats Extension is received with the 686 ServerHello, this is equivalent to an extension allowing only the 687 uncompressed point format. 689 5.3 Server Certificate 691 When this message is sent: 693 This message is sent in all non-anonymous ECC-based key exchange 694 algorithms. 696 Meaning of this message: 698 This message is used to authentically convey the server's static 699 public key to the client. The following table shows the server 700 certificate type appropriate for each key exchange algorithm. ECC 701 public keys MUST be encoded in certificates as described in 702 Section 5.9. 704 NOTE: The server's Certificate message is capable of carrying a chain 705 of certificates. The restrictions mentioned in Table 3 apply only to 706 the server's certificate (first in the chain). 708 Key Exchange Algorithm Server Certificate Type 709 ---------------------- ----------------------- 711 ECDH_ECDSA Certificate MUST contain an 712 ECDH-capable public key. It 713 MUST be signed with ECDSA. 715 ECDHE_ECDSA Certificate MUST contain an 716 ECDSA-capable public key. It 717 MUST be signed with ECDSA. 719 ECDH_RSA Certificate MUST contain an 720 ECDH-capable public key. It 721 MUST be signed with RSA. 723 ECDHE_RSA Certificate MUST contain an 724 RSA public key authorized for 725 use in digital signatures. It 726 MUST be signed with RSA. 728 Table 3: Server certificate types 730 Structure of this message: 732 Identical to the TLS Certificate format. 734 Actions of the sender: 736 The server constructs an appropriate certificate chain and conveys it 737 to the client in the Certificate message. If the client has used a 738 Supported Elliptic Curves Extension, the public key in the server's 739 certificate MUST respect the client's choice of elliptic curves; in 740 particular, the public key MUST employ a named curve (not the same 741 curve as an explicit curve) unless the client has indicated support 742 for explicit curves of the appropriate type. If the client has used 743 a Supported Point Formats Extension, both the server's public key 744 point and (in the case of an explicit curve) the curve's base point 745 MUST respect the client's choice of point formats. (A server that 746 cannot satisfy these requirements MUST NOT choose an ECC cipher suite 747 in its ServerHello message.) 749 Actions of the receiver: 751 The client validates the certificate chain, extracts the server's 752 public key, and checks that the key type is appropriate for the 753 negotiated key exchange algorithm. (A possible reason for a fatal 754 handshake failure is if the client's capabilities for handling 755 elliptic curves and point formats are exceeded; cf. Section 5.1.) 757 5.4 Server Key Exchange 759 When this message is sent: 761 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and 762 ECDH_anon key exchange algorithms. 764 Meaning of this message: 766 This message is used to convey the server's ephemeral ECDH public key 767 (and the corresponding elliptic curve domain parameters) to the 768 client. 770 Structure of this message: 772 enum { explicit_prime (1), explicit_char2 (2), 773 named_curve (3), reserved(248..255) } ECCurveType; 775 explicit_prime: Indicates the elliptic curve domain parameters are 776 conveyed verbosely, and the underlying finite field is a prime 777 field. 779 explicit_char2: Indicates the elliptic curve domain parameters are 780 conveyed verbosely, and the underlying finite field is a 781 characteristic-2 field. 783 named_curve: Indicates that a named curve is used. This option 784 SHOULD be used when applicable. 786 Values 248 through 255 are reserved for private use. 788 The ECCurveType name space is maintained by IANA. See Section 8 for 789 information on how new value assignments are added. 791 struct { 792 opaque a <1..2^8-1>; 793 opaque b <1..2^8-1>; 794 } ECCurve; 796 a, b: These parameters specify the coefficients of the elliptic 797 curve. Each value contains the byte string representation of a 798 field element following the conversion routine in Section 4.3.3 of 799 ANSI X9.62 [7]. 801 struct { 802 opaque point <1..2^8-1>; 803 } ECPoint; 805 point: This is the byte string representation of an elliptic curve 806 point following the conversion routine in Section 4.3.6 of ANSI 807 X9.62 [7]. This byte string may represent an elliptic curve point 808 in uncompressed, or compressed format; it MUST conform to what the 809 client has requested through a Supported Point Formats Extension 810 if this extension was used. 812 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; 814 ec_basis_trinomial: Indicates representation of a characteristic-2 815 field using a trinomial basis. 817 ec_basis_pentanomial: Indicates representation of a characteristic-2 818 field using a pentanomial basis. 820 struct { 821 ECCurveType curve_type; 822 select (curve_type) { 823 case explicit_prime: 824 opaque prime_p <1..2^8-1>; 825 ECCurve curve; 826 ECPoint base; 827 opaque order <1..2^8-1>; 828 opaque cofactor <1..2^8-1>; 829 case explicit_char2: 830 uint16 m; 831 ECBasisType basis; 832 select (basis) { 833 case ec_trinomial: 834 opaque k <1..2^8-1>; 835 case ec_pentanomial: 836 opaque k1 <1..2^8-1>; 837 opaque k2 <1..2^8-1>; 838 opaque k3 <1..2^8-1>; 839 }; 840 ECCurve curve; 841 ECPoint base; 842 opaque order <1..2^8-1>; 843 opaque cofactor <1..2^8-1>; 844 case named_curve: 845 NamedCurve namedcurve; 846 }; 847 } ECParameters; 849 curve_type: This identifies the type of the elliptic curve domain 850 parameters. 852 prime_p: This is the odd prime defining the field Fp. 854 curve: Specifies the coefficients a and b of the elliptic curve E. 856 base: Specifies the base point G on the elliptic curve. 858 order: Specifies the order n of the base point. 860 cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) 861 represents the number of points on the elliptic curve E defined 862 over the field Fq (either Fp or F2^m). 864 m: This is the degree of the characteristic-2 field F2^m. 866 k: The exponent k for the trinomial basis representation x^m + x^k 867 +1. 869 k1, k2, k3: The exponents for the pentanomial representation x^m + 870 x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). 872 namedcurve: Specifies a recommended set of elliptic curve domain 873 parameters. All those values of NamedCurve are allowed that refer 874 to a specific curve. Values of NamedCurve that indicate support 875 for a class of explicitly defined curves are not allowed here 876 (they are only permissible in the ClientHello extension); this 877 applies to arbitrary_explicit_prime_curves(0xFF01) and 878 arbitrary_explicit_char2_curves(0xFF02). 880 struct { 881 ECParameters curve_params; 882 ECPoint public; 883 } ServerECDHParams; 885 curve_params: Specifies the elliptic curve domain parameters 886 associated with the ECDH public key. 888 public: The ephemeral ECDH public key. 890 The ServerKeyExchange message is extended as follows. 892 enum { ec_diffie_hellman } KeyExchangeAlgorithm; 894 ec_diffie_hellman: Indicates the ServerKeyExchange message contains 895 an ECDH public key. 897 select (KeyExchangeAlgorithm) { 898 case ec_diffie_hellman: 899 ServerECDHParams params; 900 Signature signed_params; 901 } ServerKeyExchange; 903 params: Specifies the ECDH public key and associated domain 904 parameters. 906 signed_params: A hash of the params, with the signature appropriate 907 to that hash applied. The private key corresponding to the 908 certified public key in the server's Certificate message is used 909 for signing. 911 enum { ecdsa } SignatureAlgorithm; 913 select (SignatureAlgorithm) { 914 case ecdsa: 915 digitally-signed struct { 916 opaque sha_hash[sha_size]; 917 }; 918 } Signature; 920 NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange 921 algorithm and "anonymous" for ECDH_anon. These cases are defined in 922 TLS [2][3]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA 923 signatures are generated and verified as described in Section 5.10. 924 As per ANSI X9.62, an ECDSA signature consists of a pair of integers 925 r and s. These integers are both converted into byte strings of the 926 same length as the curve order n using the conversion routine 927 specified in Section 4.3.1 of [7]. The two byte strings are 928 concatenated, and the result is placed in the signature field. 930 Actions of the sender: 932 The server selects elliptic curve domain parameters and an ephemeral 933 ECDH public key corresponding to these parameters according to the 934 ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to 935 the client in the ServerKeyExchange message using the format defined 936 above. 938 Actions of the recipient: 940 The client verifies the signature (when present) and retrieves the 941 server's elliptic curve domain parameters and ephemeral ECDH public 942 key from the ServerKeyExchange message. (A possible reason for a 943 fatal handshake failure is if the client's capabilities for handling 944 elliptic curves and point formats are exceeded; cf. Section 5.1.) 946 5.5 Certificate Request 948 When this message is sent: 950 This message is sent when requesting client authentication. 952 Meaning of this message: 954 The server uses this message to suggest acceptable client 955 authentication methods. 957 Structure of this message: 959 The TLS CertificateRequest message is extended as follows. 961 enum { 962 ecdsa_sign(64), rsa_fixed_ecdh(65), 963 ecdsa_fixed_ecdh(66), (255) 964 } ClientCertificateType; 966 ecdsa_sign, etc Indicates that the server would like to use the 967 corresponding client authentication method specified in Section 3. 969 [[ EDITOR: The above client certificate type numbers are 970 tentative! (See http://www.iana.org/assignments/tls-parameters 971 for the registry.) Final assignments to the TLS 972 ClientCertificateType Identifiers Registry in accordance with [3] 973 will be done by IANA. The values appearing in this Internet-Draft 974 represent the authors' recommendations to IANA for assignments. ]] 976 Actions of the sender: 978 The server decides which client authentication methods it would like 979 to use, and conveys this information to the client using the format 980 defined above. 982 Actions of the receiver: 984 The client determines whether it has a suitable certificate for use 985 with any of the requested methods, and decides whether or not to 986 proceed with client authentication. 988 5.6 Client Certificate 990 When this message is sent: 992 This message is sent in response to a CertificateRequest when a 993 client has a suitable certificate and has decided to proceed with 994 client authentication. (Note that if the server has used a Supported 995 Point Formats Extension, a certificate can only be considered 996 suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and 997 ECDSA_fixed_ECDH authentication methods if the public key point 998 specified in it respects the server's choice of point formats. If no 999 Supported Point Formats Extension has been used, a certificate can 1000 only be considered suitable for use with these authentication methods 1001 if the point is represented in uncompressed point format.) 1003 Meaning of this message: 1005 This message is used to authentically convey the client's static 1006 public key to the server. The following table summarizes what client 1007 certificate types are appropriate for the ECC-based client 1008 authentication mechanisms described in Section 3. ECC public keys 1009 must be encoded in certificates as described in Section 5.9. 1011 NOTE: The client's Certificate message is capable of carrying a chain 1012 of certificates. The restrictions mentioned in Table 4 apply only to 1013 the client's certificate (first in the chain). 1015 Client 1016 Authentication Method Client Certificate Type 1017 --------------------- ----------------------- 1019 ECDSA_sign Certificate MUST contain an 1020 ECDSA-capable public key and 1021 be signed with ECDSA. 1023 ECDSA_fixed_ECDH Certificate MUST contain an 1024 ECDH-capable public key on the 1025 same elliptic curve as the server's 1026 long-term ECDH key. This certificate 1027 MUST be signed with ECDSA. 1029 RSA_fixed_ECDH Certificate MUST contain an 1030 ECDH-capable public key on the 1031 same elliptic curve as the server's 1032 long-term ECDH key. This certificate 1033 MUST be signed with RSA. 1035 Table 4: Client certificate types 1037 Structure of this message: 1039 Identical to the TLS client Certificate format. 1041 Actions of the sender: 1043 The client constructs an appropriate certificate chain, and conveys 1044 it to the server in the Certificate message. 1046 Actions of the receiver: 1048 The TLS server validates the certificate chain, extracts the client's 1049 public key, and checks that the key type is appropriate for the 1050 client authentication method. 1052 5.7 Client Key Exchange 1054 When this message is sent: 1056 This message is sent in all key exchange algorithms. If client 1057 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 1058 message is empty. Otherwise, it contains the client's ephemeral ECDH 1059 public key. 1061 Meaning of the message: 1063 This message is used to convey ephemeral data relating to the key 1064 exchange belonging to the client (such as its ephemeral ECDH public 1065 key). 1067 Structure of this message: 1069 The TLS ClientKeyExchange message is extended as follows. 1071 enum { implicit, explicit } PublicValueEncoding; 1073 implicit, explicit: For ECC cipher suites, this indicates whether 1074 the client's ECDH public key is in the client's certificate 1075 ("implicit") or is provided, as an ephemeral ECDH public key, in 1076 the ClientKeyExchange message ("explicit"). (This is "explicit" 1077 in ECC cipher suites except when the client uses the 1078 ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication 1079 mechanism.) 1081 struct { 1082 select (PublicValueEncoding) { 1083 case implicit: struct { }; 1084 case explicit: ECPoint ecdh_Yc; 1085 } ecdh_public; 1086 } ClientECDiffieHellmanPublic; 1088 ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte 1089 string ECPoint.point, which may represent an elliptic curve point 1090 in uncompressed or compressed format. Here the format MUST 1091 conform to what the server has requested through a Supported Point 1092 Formats Extension if this extension was used, and MUST be 1093 uncompressed if this extension was not used. 1095 struct { 1096 select (KeyExchangeAlgorithm) { 1097 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 1098 } exchange_keys; 1099 } ClientKeyExchange; 1101 Actions of the sender: 1103 The client selects an ephemeral ECDH public key corresponding to the 1104 parameters it received from the server according to the ECKAS-DH1 1105 scheme from IEEE 1363 [6]. It conveys this information to the client 1106 in the ClientKeyExchange message using the format defined above. 1108 Actions of the recipient: 1110 The server retrieves the client's ephemeral ECDH public key from the 1111 ClientKeyExchange message and checks that it is on the same elliptic 1112 curve as the server's ECDH key. 1114 5.8 Certificate Verify 1116 When this message is sent: 1118 This message is sent when the client sends a client certificate 1119 containing a public key usable for digital signatures, e.g. when the 1120 client is authenticated using the ECDSA_sign mechanism. 1122 Meaning of the message: 1124 This message contains a signature that proves possession of the 1125 private key corresponding to the public key in the client's 1126 Certificate message. 1128 Structure of this message: 1130 The TLS CertificateVerify message is extended as follows. 1132 enum { ecdsa } SignatureAlgorithm; 1134 select (SignatureAlgorithm) { 1135 case ecdsa: 1136 digitally-signed struct { 1137 opaque sha_hash[sha_size]; 1138 }; 1139 } Signature; 1141 For the ecdsa case, the signature field in the CertificateVerify 1142 message contains an ECDSA signature computed over handshake messages 1143 exchanged so far. ECDSA signatures are computed as described in 1144 Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a 1145 pair of integers r and s. These integers are both converted into 1146 byte strings of the same length as the curve order n using the 1147 conversion routine specified in Section 4.3.1 of [7]. The two byte 1148 strings are concatenated, and the result is placed in the signature 1149 field. 1151 Actions of the sender: 1153 The client computes its signature over all handshake messages sent or 1154 received starting at client hello up to but not including this 1155 message. It uses the private key corresponding to its certified 1156 public key to compute the signature which is conveyed in the format 1157 defined above. 1159 Actions of the receiver: 1161 The server extracts the client's signature from the CertificateVerify 1162 message, and verifies the signature using the public key it received 1163 in the client's Certificate message. 1165 5.9 Elliptic Curve Certificates 1167 X.509 certificates containing ECC public keys or signed using ECDSA 1168 MUST comply with [12] or another RFC that replaces or extends it. 1169 Clients SHOULD use the elliptic curve domain parameters recommended 1170 in ANSI X9.62 [7], FIPS 186-2 [9], and SEC 2 [11]. 1172 5.10 ECDH, ECDSA and RSA Computations 1174 All ECDH calculations (including parameter and key generation as well 1175 as the shared secret calculation) are performed according to [6] 1176 using the ECKAS-DH1 scheme with the identity map as key derivation 1177 function (KDF), so that the premaster secret is the x-coordinate of 1178 the ECDH shared secret elliptic curve point represented as an octet 1179 string. Note that this octet string (Z in IEEE 1363 terminology) as 1180 output by FE2OSP, the Field Element to Octet String Conversion 1181 Primitive, has constant length for any given field; leading zeros 1182 found in this octet string MUST NOT be truncated. 1184 (Note that this use of the identity KDF is a technicality. The 1185 complete picture is that ECDH is employed with a non-trivial KDF 1186 because TLS does not directly use the premaster secret for anything 1187 other than for computing the master secret. As of TLS 1.0 [2] and 1188 1.1 [3] this means that the MD5- and SHA-1-based TLS PRF serves as a 1189 KDF; it is conceivable that future TLS versions or new TLS extensions 1190 introduced in the future may vary this computation.) 1191 All ECDSA computations MUST be performed according to ANSI X9.62 [7] 1192 or its successors. Data to be signed/verified is hashed and the 1193 result run directly through the ECDSA algorithm with no additional 1194 hashing. The default hash function is SHA-1 [8] and sha_size (see 1195 Section 5.4 and Section 5.8) is 20. However, an alternative hash 1196 function, such as one of the new SHA hash functions specified in FIPS 1197 180-2 [8], may be used instead if the certificate containing the EC 1198 public key explicitly requires use of another hash function. (The 1199 mechanism for specifying the required hash function has not been 1200 standardized but this provision anticipates such standardization and 1201 obviates the need to update this document in response. Future PKIX 1202 RFCs may choose, for example, to specify the hash function to be used 1203 with a public key in the parameters field of subjectPublicKeyInfo.) 1205 All RSA signatures must be generated and verified according to PKCS#1 1206 [10] block type 1. 1208 6. Cipher Suites 1210 The table below defines new ECC cipher suites that use the key 1211 exchange algorithms specified in Section 2. 1213 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x00 } 1214 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x01 } 1215 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0xC0, 0x02 } 1216 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 } 1217 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x04 } 1218 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x05 } 1220 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0xC0, 0x06 } 1221 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x07 } 1222 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x08 } 1223 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x09 } 1224 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0A } 1226 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0xC0, 0x0B } 1227 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0xC0, 0x0C } 1228 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x0D } 1229 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x0E } 1230 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0F } 1232 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0xC0, 0x10 } 1233 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0xC0, 0x11 } 1234 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x12 } 1235 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x13 } 1236 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x14 } 1238 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0xC0, 0x15 } 1239 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0xC0, 0x16 } 1240 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x17 } 1241 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0xC0, 0x18 } 1242 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0xC0, 0x19 } 1244 Table 5: TLS ECC cipher suites 1246 [[ EDITOR: The above cipher suite numbers are tentative! (See 1247 http://www.iana.org/assignments/tls-parameters for the registry.) 1248 Final assignments to the TLS Cipher Suite Registry in accordance with 1249 [3] will be done by IANA. The values appearing in this Internet- 1250 Draft represent the authors' recommendations to IANA for assignments. 1251 ]] 1253 The key exchange method, cipher, and hash algorithm for each of these 1254 cipher suites are easily determined by examining the name. Ciphers 1255 other than AES ciphers, and hash algorithms are defined in [2] and 1256 [3]. AES ciphers are defined in [18]. 1258 Server implementations SHOULD support all of the following cipher 1259 suites, and client implementations SHOULD support at least one of 1260 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 1261 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 1262 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 1263 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 1265 7. Security Considerations 1267 Security issues are discussed throughout this memo. 1269 For TLS handshakes using ECC cipher suites, the security 1270 considerations in appendices D.2 and D.3 of [2] and [3] apply 1271 accordingly. 1273 Security discussions specific to ECC can be found in [6] and [7]. 1274 One important issue that implementors and users must consider is 1275 elliptic curve selection. Guidance on selecting an appropriate 1276 elliptic curve size is given in Table 1. 1278 Beyond elliptic curve size, the main issue is elliptic curve 1279 structure. As a general principle, it is more conservative to use 1280 elliptic curves with as little algebraic structure as possible - thus 1281 random curves are more conservative than special curves such as 1282 Koblitz curves, and curves over F_p with p random are more 1283 conservative than curves over F_p with p of a special form (and 1284 curves over F_p with p random might be considered more conservative 1285 than curves over F_2^m as there is no choice between multiple fields 1286 of similar size for characteristic 2). Note, however, that algebraic 1287 structure can also lead to implementation efficiencies and 1288 implementors and users may, therefore, need to balance conservatism 1289 against a need for efficiency. Concrete attacks are known against 1290 only very few special classes of curves, such as supersingular 1291 curves, and these classes are excluded from the ECC standards that 1292 this document references [6], [7]. 1294 Another issue is the potential for catastrophic failures when a 1295 single elliptic curve is widely used. In this case, an attack on the 1296 elliptic curve might result in the compromise of a large number of 1297 keys. Again, this concern may need to be balanced against efficiency 1298 and interoperability improvements associated with widely-used curves. 1299 Substantial additional information on elliptic curve choice can be 1300 found in [5], [6], [7], [9]. 1302 Implementors and users must also consider whether they need forward 1303 secrecy. Forward secrecy refers to the property that session keys 1304 are not compromised if the static, certified keys belonging to the 1305 server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key 1306 exchange algorithms provide forward secrecy protection in the event 1307 of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. 1308 Similarly if the client is providing a static, certified key, 1309 ECDSA_sign client authentication provides forward secrecy protection 1310 in the event of client key compromise, while ECDSA_fixed_ECDH and 1311 RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy 1312 protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, 1313 with ECDSA_sign used for client authentication if necessary. Here 1314 again the security benefits of forward secrecy may need to be 1315 balanced against the improved efficiency offered by other options. 1317 8. IANA Considerations 1319 This document describes three new name spaces for use with the TLS 1320 protocol: 1322 o NamedCurve (Section 5.1) 1324 o ECPointFormat (Section 5.1) 1326 o ECCurveType (Section 5.4) 1328 For each name space, this document defines the initial value 1329 assignments and defines a range of 256 values (NamedCurve) or eight 1330 values (ECPointFormat and ECCurveType) reserved for Private Use. Any 1331 additional assignments require IETF Consensus action [14]. 1333 [[ EDITOR: This documents also contains assignments to the registry 1334 for TLS ciphersuites defined in [4], and to the TLS Cipher Suite 1335 Registry and the TLS ClientCertificateType Identifiers Registry 1336 defined in [3]. All of these are currently marked as tentative since 1337 final assignments will have to be by IANA; see "EDITOR" notes in 1338 Section 5.1 (and Section 5.1.1 and Section 5.1.1), Section 5.5, and 1339 Section 6. ]] 1341 9. Acknowledgments 1343 The authors wish to thank Bill Anderson and Tim Dierks. 1345 10. References 1347 10.1 Normative References 1349 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 1350 Levels", RFC 2119, March 1997. 1352 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1353 RFC 2246, January 1999. 1355 [3] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 1356 draft-ietf-tls-rfc2246bis-13.txt (work in progress), June 2005. 1358 [[ EDITOR: The cited Internet-Draft has been approved by the 1359 IESG; the citation will have to be changed once it has been 1360 published as RFC. ]] 1362 [4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1363 T. Wright, "Transport Layer Security (TLS) Extensions", 1364 draft-ietf-tls-rfc3546bis-02.txt (work in progress), 1365 September 2005. 1367 [[ EDITOR: The cited Internet-Draft has been approved by the 1368 IESG; the citation will have to be changed once it has been 1369 published as RFC. ]] 1371 [5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, 1372 . 1374 [6] IEEE, "Standard Specifications for Public Key Cryptography", 1375 IEEE 1363, 2000. 1377 [7] ANSI, "Public Key Cryptography For The Financial Services 1378 Industry: The Elliptic Curve Digital Signature Algorithm 1379 (ECDSA)", ANSI X9.62, 1998. 1381 [8] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 1383 [9] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 1385 [10] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1386 1.5", PKCS 1, November 1993. 1388 [11] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 1389 2000, . 1391 [12] Polk, T., Housley, R., and L. Bassham, "Algorithms and 1392 Identifiers for the Internet X.509 Public Key Infrastructure 1393 Certificate and Certificate Revocation List (CRL) Profile", 1394 RFC 3279, April 2002. 1396 [13] Housley, R., Polk, T., Ford, W., and D. Solo, "Internet X.509 1397 Public Key Infrastructure Certificate and Certificate 1398 Revocation List (CRL) Profile", RFC 3280, April 2002. 1400 [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1401 Considerations Section in RFCs", RFC 2434, October 1998. 1403 10.2 Informative References 1405 [15] Harper, G., Menezes, A., and S. Vanstone, "Public-Key 1406 Cryptosystems with Very Small Key Lengths", Advances in 1407 Cryptology -- EUROCRYPT '92, LNCS 658, 1993. 1409 [16] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1410 Sizes", Journal of Cryptology 14 (2001) 255-293, 1411 . 1413 [17] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 1414 Version 3.0", November 1996, 1415 . 1417 [18] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1418 Transport Layer Security (TLS)", RFC 3268, June 2002. 1420 Authors' Addresses 1422 Simon Blake-Wilson 1423 Basic Commerce & Industries, Inc. 1424 96 Spandia Ave 1425 Unit 606 1426 Toronto, ON M6G 2T6 1427 CA 1429 Phone: +1 416 214 5961 1430 Email: sblakewilson@bcisse.com 1432 Nelson Bolyard 1433 Sun 1435 Email: nelson@bolyard.com 1436 Vipul Gupta 1437 Sun Microsystems Laboratories 1438 16 Network Circle 1439 MS UMPK16-160 1440 Menlo Park, CA 94025 1441 US 1443 Phone: +1 650 786 7551 1444 Email: vipul.gupta@sun.com 1446 Chris Hawk 1447 Corriente Networks LLC 1448 1563 Solano Ave., #484 1449 Berkeley, CA 94707 1450 US 1452 Phone: +1 510 527 0601 1453 Email: chris@corriente.net 1455 Bodo Moeller 1456 University of Calgary 1457 Dept of Math & Stats 1458 2500 University Dr NW 1459 Calgary, AB T2N 1N4 1460 CA 1462 Phone: +1 403 220 5735 1463 Email: bodo@openssl.org 1465 Intellectual Property Statement 1467 The IETF takes no position regarding the validity or scope of any 1468 Intellectual Property Rights or other rights that might be claimed to 1469 pertain to the implementation or use of the technology described in 1470 this document or the extent to which any license under such rights 1471 might or might not be available; nor does it represent that it has 1472 made any independent effort to identify any such rights. Information 1473 on the procedures with respect to rights in RFC documents can be 1474 found in BCP 78 and BCP 79. 1476 Copies of IPR disclosures made to the IETF Secretariat and any 1477 assurances of licenses to be made available, or the result of an 1478 attempt made to obtain a general license or permission for the use of 1479 such proprietary rights by implementers or users of this 1480 specification can be obtained from the IETF on-line IPR repository at 1481 http://www.ietf.org/ipr. 1483 The IETF invites any interested party to bring to its attention any 1484 copyrights, patents or patent applications, or other proprietary 1485 rights that may cover technology that may be required to implement 1486 this standard. Please address the information to the IETF at 1487 ietf-ipr@ietf.org. 1489 Disclaimer of Validity 1491 This document and the information contained herein are provided on an 1492 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1493 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1494 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1495 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1496 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1497 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1499 Copyright Statement 1501 Copyright (C) The Internet Society (2005). This document is subject 1502 to the rights, licenses and restrictions contained in BCP 78, and 1503 except as set forth therein, the authors retain all their rights. 1505 Acknowledgment 1507 Funding for the RFC Editor function is currently provided by the 1508 Internet Society.