idnits 2.17.00 (12 Aug 2021) /tmp/idnits6475/draft-ietf-tls-ecc-09.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.a on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1361. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 760 has weird spacing: '...rveType cur...' == Line 773 has weird spacing: '... opaque k <1....' == Line 775 has weird spacing: '... opaque k1 <1...' == Line 776 has weird spacing: '... opaque k2 <1...' == Line 777 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 (April 7, 2005) is 6252 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 219 == Unused Reference: '12' is defined on line 1284, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) == Outdated reference: draft-ietf-tls-rfc3546bis has been published as RFC 4366 -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- 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' -- Obsolete informational reference (is this intentional?): RFC 3268 (ref. '15') (Obsoleted by RFC 5246) Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group V. Gupta 3 Internet-Draft Sun Labs 4 Expires: October 9, 2005 S. Blake-Wilson 5 BCI 6 B. Moeller 7 University of Calgary 8 C. Hawk 9 Corriente Networks 10 N. Bolyard 11 April 7, 2005 13 ECC Cipher Suites for TLS 14 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all provisions 19 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 20 author represents that any applicable patent or other IPR claims of 21 which he or she is aware have been or will be disclosed, and any of 22 which he or she become aware will be disclosed, in accordance with 23 RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on October 9, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [1]. 59 Please send comments on this document to the TLS mailing list. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5 65 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3. Client Authentication . . . . . . . . . . . . . . . . . . . 9 71 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10 73 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 74 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11 75 5. Data Structures and Computations . . . . . . . . . . . . . . 12 76 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12 77 5.2 Server Hello Extension . . . . . . . . . . . . . . . . . . 15 78 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16 79 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18 80 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22 81 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23 82 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 24 83 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 25 84 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 26 85 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 26 86 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 28 87 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 88 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 90 9.1 Normative References . . . . . . . . . . . . . . . . . . . 32 91 9.2 Informative References . . . . . . . . . . . . . . . . . . 32 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 93 Intellectual Property and Copyright Statements . . . . . . . 35 95 1. Introduction 97 Elliptic Curve Cryptography (ECC) is emerging as an attractive 98 public-key cryptosystem for mobile/wireless environments. Compared 99 to currently prevalent cryptosystems such as RSA, ECC offers 100 equivalent security with smaller key sizes. This is illustrated in 101 the following table, based on [13], which gives approximate 102 comparable key sizes for symmetric- and asymmetric-key cryptosystems 103 based on the best-known algorithms for attacking them. 105 Symmetric | ECC | DH/DSA/RSA 106 -------------+---------+------------ 107 80 | 163 | 1024 108 112 | 233 | 2048 109 128 | 283 | 3072 110 192 | 409 | 7680 111 256 | 571 | 15360 113 Table 1: Comparable key sizes (in bits) 115 Smaller key sizes result in power, bandwidth and computational 116 savings that make ECC especially attractive for constrained 117 environments. 119 This document describes additions to TLS to support ECC. In 120 particular, it defines 122 o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement 123 scheme with long-term or ephemeral keys to establish the TLS 124 premaster secret, and 126 o the use of fixed-ECDH certificates and ECDSA for authentication of 127 TLS peers. 129 The remainder of this document is organized as follows. Section 2 130 provides an overview of ECC-based key exchange algorithms for TLS. 131 Section 3 describes the use of ECC certificates for client 132 authentication. TLS extensions that allow a client to negotiate the 133 use of specific curves and point formats are presented in Section 4. 134 Section 5 specifies various data structures needed for an ECC-based 135 handshake, their encoding in TLS messages and the processing of those 136 messages. Section 6 defines new ECC-based cipher suites and 137 identifies a small subset of these as recommended for all 138 implementations of this specification. Section 7 and Section 8 139 mention security considerations and acknowledgments, respectively. 140 This is followed by a list of references cited in this document, the 141 authors' contact information, and statements on intellectual property 142 rights and copyrights. 144 Implementation of this specification requires familiarity with TLS 145 [2], TLS extensions [3] and ECC [4][5][6][8]. 147 2. Key Exchange Algorithms 149 This document introduces five new ECC-based key exchange algorithms 150 for TLS. All of them use ECDH to compute the TLS premaster secret 151 and differ only in the lifetime of ECDH keys (long-term or ephemeral) 152 and the mechanism (if any) used to authenticate them. The derivation 153 of the TLS master secret from the premaster secret and the subsequent 154 generation of bulk encryption/MAC keys and initialization vectors is 155 independent of the key exchange algorithm and not impacted by the 156 introduction of ECC. 158 The table below summarizes the new key exchange algorithms which 159 mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2]), 160 respectively. 162 Key 163 Exchange 164 Algorithm Description 165 --------- ----------- 167 ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. 169 ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. 171 ECDH_RSA Fixed ECDH with RSA-signed certificates. 173 ECDHE_RSA Ephemeral ECDH with RSA signatures. 175 ECDH_anon Anonymous ECDH, no signatures. 177 Table 2: ECC key exchange algorithms 179 The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward 180 secrecy. With ECDHE_RSA, a server can reuse its existing RSA 181 certificate and easily comply with a constrained client's elliptic 182 curve preferences (see Section 4). However, the computational cost 183 incurred by a server is higher for ECDHE_RSA than for the traditional 184 RSA key exchange which does not provide forward secrecy. 186 The ECDH_RSA mechanism requires a server to acquire an ECC 187 certificate but the certificate issuer can still use an existing RSA 188 key for signing. This eliminates the need to update the trusted key 189 store in TLS clients. The ECDH_ECDSA mechanism requires ECC keys for 190 the server as well as the certification authority and is best suited 191 for constrained devices unable to support RSA. 193 The anonymous key exchange algorithm does not provide authentication 194 of the server or the client. Like other anonymous TLS key exchanges, 195 it is subject to man-in-the-middle attacks. Implementations of this 196 algorithm SHOULD provide authentication by other means. 198 Note that there is no structural difference between ECDH and ECDSA 199 keys. A certificate issuer may use X509.v3 keyUsage and 200 extendedKeyUsage extensions to restrict the use of an ECC public key 201 to certain computations. This document refers to an ECC key as ECDH- 202 capable if its use in ECDH is permitted. ECDSA-capable is defined 203 similarly. 205 Client Server 206 ------ ------ 208 ClientHello --------> 209 ServerHello 210 Certificate* 211 ServerKeyExchange* 212 CertificateRequest*+ 213 <-------- ServerHelloDone 214 Certificate*+ 215 ClientKeyExchange 216 CertificateVerify*+ 217 [ChangeCipherSpec] 218 Finished --------> 219 [ChangeCipherSpec] 220 <-------- Finished 222 Application Data <-------> Application Data 224 * message is not sent under some conditions 225 + message is not sent unless client authentication 226 is desired 228 Figure 1: Message flow in a full TLS handshake 230 Figure 1 shows all messages involved in the TLS key establishment 231 protocol (aka full handshake). The addition of ECC has direct impact 232 only on the ClientHello, the ServerHello, the server's Certificate 233 message, the ServerKeyExchange, the ClientKeyExchange, the 234 CertificateRequest, the client's Certificate message, and the 235 CertificateVerify. Next, we describe each ECC key exchange algorithm 236 in greater detail in terms of the content and processing of these 237 messages. For ease of exposition, we defer discussion of client 238 authentication and associated messages (identified with a + in 239 Figure 1) until Section 3 and of the optional ECC-specific extensions 240 (which impact the Hello messages) until Section 4. 242 2.1 ECDH_ECDSA 244 In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable 245 public key and be signed with ECDSA. 247 A ServerKeyExchange MUST NOT be sent (the server's certificate 248 contains all the necessary keying information required by the client 249 to arrive at the premaster secret). 251 The client MUST generate an ECDH key pair on the same curve as the 252 server's long-term public key and send its public key in the 253 ClientKeyExchange message (except when using client authentication 254 algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the 255 modifications from section Section 3.2 or Section 3.3 apply). 257 Both client and server MUST perform an ECDH operation and use the 258 resultant shared secret as the premaster secret. All ECDH 259 calculations are performed as specified in Section 5.10 261 2.2 ECDHE_ECDSA 263 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- 264 capable public key and be signed with ECDSA. 266 The server MUST send its ephemeral ECDH public key and a 267 specification of the corresponding curve in the ServerKeyExchange 268 message. These parameters MUST be signed with ECDSA using the 269 private key corresponding to the public key in the server's 270 Certificate. 272 The client MUST generate an ECDH key pair on the same curve as the 273 server's ephemeral ECDH key and send its public key in the 274 ClientKeyExchange message. 276 Both client and server MUST perform an ECDH operation (Section 5.10) 277 and use the resultant shared secret as the premaster secret. 279 2.3 ECDH_RSA 281 This key exchange algorithm is the same as ECDH_ECDSA except the 282 server's certificate MUST be signed with RSA rather than ECDSA. 284 2.4 ECDHE_RSA 286 This key exchange algorithm is the same as ECDHE_ECDSA except the 287 server's certificate MUST contain an RSA public key authorized for 288 signing and the signature in the ServerKeyExchange message MUST be 289 computed with the corresponding RSA private key. The server 290 certificate MUST be signed with RSA. 292 2.5 ECDH_anon 294 In ECDH_anon, the server's Certificate, the CertificateRequest, the 295 client's Certificate, and the CertificateVerify messages MUST NOT be 296 sent. 298 The server MUST send an ephemeral ECDH public key and a specification 299 of the corresponding curve in the ServerKeyExchange message. These 300 parameters MUST NOT be signed. 302 The client MUST generate an ECDH key pair on the same curve as the 303 server's ephemeral ECDH key and send its public key in the 304 ClientKeyExchange message. 306 Both client and server MUST perform an ECDH operation and use the 307 resultant shared secret as the premaster secret. All ECDH 308 calculations are performed as specified in Section 5.10 310 3. Client Authentication 312 This document defines three new client authentication mechanisms 313 named after the type of client certificate involved: ECDSA_sign, 314 ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is 315 usable with any of the non-anonymous ECC key exchange algorithms 316 described in Section 2 as well as other non-anonymous (non-ECC) key 317 exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and 318 RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. 319 Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the 320 use of a long-term ECDH client key would jeopardize the forward 321 secrecy property of these algorithms. 323 The server can request ECC-based client authentication by including 324 one or more of these certificate types in its CertificateRequest 325 message. The server MUST NOT include any certificate types that are 326 prohibited for the negotiated key exchange algorithm. The client 327 must check if it possesses a certificate appropriate for any of the 328 methods suggested by the server and is willing to use it for 329 authentication. 331 If these conditions are not met, the client should send a client 332 Certificate message containing no certificates. In this case, the 333 ClientKeyExchange should be sent as described in Section 2 and the 334 CertificateVerify should not be sent. If the server requires client 335 authentication, it may respond with a fatal handshake failure alert. 337 If the client has an appropriate certificate and is willing to use it 338 for authentication, it MUST send that certificate in the client's 339 Certificate message (as per Section 5.6) and prove possession of the 340 private key corresponding to the certified key. The process of 341 determining an appropriate certificate and proving possession is 342 different for each authentication mechanism and described below. 344 NOTE: It is permissible for a server to request (and the client to 345 send) a client certificate of a different type than the server 346 certificate. 348 3.1 ECDSA_sign 350 To use this authentication mechanism, the client MUST possess a 351 certificate containing an ECDSA-capable public key and signed with 352 ECDSA. 354 The client MUST prove possession of the private key corresponding to 355 the certified key by including a signature in the CertificateVerify 356 message as described in Section 5.8. 358 3.2 ECDSA_fixed_ECDH 360 To use this authentication mechanism, the client MUST possess a 361 certificate containing an ECDH-capable public key and that 362 certificate MUST be signed with ECDSA. Furthermore, the client's 363 ECDH key MUST be on the same elliptic curve as the server's long-term 364 (certified) ECDH key. This might limit use of this mechanism to 365 closed environments. In situations where the client has an ECC key 366 on a different curve, it would have to authenticate either using 367 ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for 368 both servers and clients is computationally more efficient than 369 mechanisms providing forward secrecy. 371 When using this authentication mechanism, the client MUST send an 372 empty ClientKeyExchange as described in Section 5.7 and MUST NOT send 373 the CertificateVerify message. The ClientKeyExchange is empty since 374 the client's ECDH public key required by the server to compute the 375 premaster secret is available inside the client's certificate. The 376 client's ability to arrive at the same premaster secret as the server 377 (demonstrated by a successful exchange of Finished messages) proves 378 possession of the private key corresponding to the certified public 379 key and the CertificateVerify message is unnecessary. 381 3.3 RSA_fixed_ECDH 383 This authentication mechanism is identical to ECDSA_fixed_ECDH except 384 the client's certificate MUST be signed with RSA. 386 4. TLS Extensions for ECC 388 Two new TLS extensions are defined in this specification: (i) the 389 Supported Elliptic Curves Extension, and (ii) the Supported Point 390 Formats Extension. These allow negotiating the use of specific 391 curves and point formats (e.g. compressed vs. uncompressed), 392 respectively, during a handshake starting a new session. These 393 extensions are especially relevant for constrained clients that may 394 only support a limited number of curves or point formats. They 395 follow the general approach outlined in [3]; message details are 396 specified in Section 5. The client enumerates the curves it supports 397 and the point formats it can parse by including the appropriate 398 extensions in its ClientHello message. The server similarly 399 enumerates the point formats it can parse by including an extension 400 in its ServerHello message. 402 A TLS client that proposes ECC cipher suites in its ClientHello 403 message SHOULD include these extensions. Servers implementing ECC 404 cipher suites MUST support these extensions, and when a client uses 405 these extensions, servers MUST NOT negotiate the use of an ECC cipher 406 suite unless they can complete the handshake while respecting the 407 choice of curves and compression techniques specified by the client. 408 This eliminates the possibility that a negotiated ECC handshake will 409 be subsequently aborted due to a client's inability to deal with the 410 server's EC key. 412 These extensions MUST NOT be included if the client does not propose 413 any ECC cipher suites. A client that proposes ECC cipher suites may 414 choose not to include these extension. In this case, the server is 415 free to choose any one of the elliptic curves or point formats listed 416 in Section 5. That section also describes the structure and 417 processing of these extensions in greater detail. 419 In the case of session resumption, the server simply ignores the 420 Supported Elliptic Curves Extension and the Supported Point Formats 421 Extension as appearing in the current ClientHello message. These 422 extensions only play a role during handshakes negotiating a new 423 session. 425 5. Data Structures and Computations 427 This section specifies the data structures and computations used by 428 ECC-based key mechanisms specified in Section 2, Section 3 and 429 Section 4. The presentation language used here is the same as that 430 used in TLS [2]. Since this specification extends TLS, these 431 descriptions should be merged with those in the TLS specification and 432 any others that extend TLS. This means that enum types may not 433 specify all possible values and structures with multiple formats 434 chosen with a select() clause may not indicate all possible cases. 436 5.1 Client Hello Extensions 438 This section specifies two TLS extensions that can be included with 439 the ClientHello message as described in [3], the Supported Elliptic 440 Curves Extension and the Supported Point Formats Extension. 442 When these extensions are sent: 444 The extensions SHOULD be sent along with any ClientHello message that 445 proposes ECC cipher suites. 447 Meaning of these extensions: 449 These extensions allow a client to enumerate the elliptic curves it 450 supports and/or the point formats it can parse. 452 Structure of these extensions: 454 The general structure of TLS extensions is described in [3] and this 455 specification adds two new types to ExtensionType. 457 enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType; 459 [[ EDITOR: The values used for elliptic_curves and ec_point_formats 460 have been left as ??. These values will be assigned when this draft 461 progresses to RFC. (The examples below will have to be changed 462 accordingly.) ]] 464 elliptic_curves (Supported Elliptic Curves Extension): Indicates the 465 set of elliptic curves supported by the client. For this 466 extension, the opaque extension_data field contains 467 EllipticCurveList. 469 ec_point_formats (Supported Point Formats Extension): Indicates the 470 set of point formats that the client can parse. For this 471 extension, the opaque extension_data field contains 472 ECPointFormatList. 474 enum { 475 sect163k1 (1), sect163r1 (2), sect163r2 (3), 476 sect193r1 (4), sect193r2 (5), sect233k1 (6), 477 sect233r1 (7), sect239k1 (8), sect283k1 (9), 478 sect283r1 (10), sect409k1 (11), sect409r1 (12), 479 sect571k1 (13), sect571r1 (14), secp160k1 (15), 480 secp160r1 (16), secp160r2 (17), secp192k1 (18), 481 secp192r1 (19), secp224k1 (20), secp224r1 (21), 482 secp256k1 (22), secp256r1 (23), secp384r1 (24), 483 secp521r1 (25), reserved (240..247), 484 arbitrary_explicit_prime_curves(253), 485 arbitrary_explicit_char2_curves(254), 486 (255) 487 } NamedCurve; 489 sect163k1, etc: Indicates support of the corresponding named curve 490 specified in SEC 2 [10]. Note that many of these curves are also 491 recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240 492 through 247 are reserved for private use. Values 253 and 254 493 indicate that the client supports arbitrary prime and 494 characteristic-2 curves, respectively (the curve parameters must 495 be encoded explicitly in ECParameters). 497 struct { 498 NamedCurve elliptic_curve_list<1..2^8-1> 499 } EllipticCurveList; 501 Items in elliptic_curve_list are ordered according to the client's 502 preferences (favorite choice first). 504 As an example, a client that only supports secp192r1 (aka NIST P-192; 505 value 19 = 0x13) and secp224r1 (aka NIST P-224; value 21 = 0x15) and 506 prefers to use secp192r1 would include a TLS extension consisting of 507 the following octets: 509 00 ?? 00 03 02 13 15 511 A client that supports arbitrary explicit characteristic-2 curves 512 (value 254 = 0xFE) would include an extension consisting of the 513 following octets: 515 00 ?? 00 02 01 FE 517 enum { uncompressed (0), ansiX962_compressed (1), 518 ansiX962_hybrid (2), reserved (3 .. 255) 519 } ECPointFormat; 521 struct { 522 ECPointFormat ec_point_format_list<1..2^8-1> 523 } ECPointFormatList; 525 Three point formats are included in the definition of ECPointFormat 526 above. The uncompressed point format is the default format in that 527 implementations of this document MUST support it. The 528 ansiX962_compressed format reduces bandwidth by including only the 529 x-coordinate and a single bit of the y-coordinate of the point. The 530 ansiX962_hybrid format includes both the full y-coordinate and the 531 compressed y-coordinate to allow flexibility and improve efficiency 532 in some cases. Implementations of this document MAY support the 533 ansiX962_compressed and ansiX962_hybrid point formats. (These three 534 formats are described in [6].) Values 248 through 255 are reserved 535 for private use. 537 Items in ec_point_format_list are ordered according to the client's 538 preferences (favorite choice first). 540 A client that can parse only the uncompressed point format includes 541 an extension consisting of the following octets: 543 00 ?? 00 02 01 00 545 A client that prefers the use of the ansiX962_compressed format over 546 uncompressed may indicate that preference by including an extension 547 consisting of the following octets: 549 00 ?? 00 03 02 01 00 551 Actions of the sender: 553 A client that proposes ECC cipher suites in its ClientHello message 554 appends these extensions (along with any others), enumerating the 555 curves it supports and the point formats it can parse. Clients 556 SHOULD send both the Supported Elliptic Curves Extension and the 557 Supported Point Formats Extension. If the Supported Point Formats 558 Extension is indeed sent, it MUST contain the value 0 (uncompressed) 559 as one of the items in the list of point formats. 561 Actions of the receiver: 563 A server that receives a ClientHello containing one or both of these 564 extensions MUST use the client's enumerated capabilities to guide its 565 selection of an appropriate cipher suite. One of the proposed ECC 566 cipher suites must be negotiated only if the server can successfully 567 complete the handshake while using the curves and point formats 568 supported by the client (cf. Section 5.3 and Section 5.4). 570 NOTE: A server participating in an ECDHE-ECDSA key exchange may use 571 different curves for (i) the ECDSA key in its certificate, and (ii) 572 the ephemeral ECDH key in the ServerKeyExchange message. The server 573 must consider the "elliptic_curves" extension in selecting both of 574 these curves. 576 If a server does not understand the "elliptic_curves" extension or is 577 unable to complete the ECC handshake while restricting itself to the 578 enumerated curves, it MUST NOT negotiate the use of an ECC cipher 579 suite. Depending on what other cipher suites are proposed by the 580 client and supported by the server, this may result in a fatal 581 handshake failure alert due to the lack of common cipher suites. 583 5.2 Server Hello Extension 585 This section specifies a TLS extension that can be included with the 586 ServerHello message as described in [3], the Supported Point Formats 587 Extension. 589 When this extension is sent: 591 The Supported Point Formats Extension is included in a ServerHello 592 message in response to a ClientHello message containing the Supported 593 Point Formats Extension when negotiating an ECC cipher suite. 595 Meaning of this extensions: 597 This extension allows a server to enumerate the point formats it can 598 parse (for the curve that will appear in its ServerKeyExchange 599 message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key 600 exchange algorithm, or for the curve that is used in the server's 601 public key that will appear in its Certificate message when using the 602 ECDH_ECDSA or ECDH_RSA key exchange algorithm). 604 Structure of this extension: 606 The server's Supported Point Formats Extension has the same structure 607 as the client's Supported Point Formats Extension. Items in 608 elliptic_curve_list here are ordered according to the server's 609 preference (favorite choice first). Note that the server may include 610 items that were not found in the client's list (e.g., the server may 611 prefer to receive points in compressed format even when a client 612 cannot parse this format: the same client may nevertheless be capable 613 to output points in compressed format). 615 Actions of the sender: 617 A server that selects an ECC cipher suite in response to a 618 ClientHello message including a Supported Point Formats Extension 619 appends this extension (along with others) to its ServerHello 620 message, enumerating the point formats it can parse. The Supported 621 Point Formats Extension, when used, MUST contain the value 0 622 (uncompressed) as one of the items in the list of point formats. 624 Actions of the receiver: 626 A client that receives a ServerHello message containing a Supported 627 Point Formats Extension MUST respect the server's choice of point 628 formats during the handshake (cf. Section 5.6 and Section 5.7). If 629 no Supported Point Formats Extension is received with the 630 ServerHello, this is equivalent to an extension allowing only the 631 uncompressed point format. 633 5.3 Server Certificate 635 When this message is sent: 637 This message is sent in all non-anonymous ECC-based key exchange 638 algorithms. 640 Meaning of this message: 642 This message is used to authentically convey the server's static 643 public key to the client. The following table shows the server 644 certificate type appropriate for each key exchange algorithm. ECC 645 public keys must be encoded in certificates as described in 646 Section 5.9. 648 NOTE: The server's Certificate message is capable of carrying a chain 649 of certificates. The restrictions mentioned in Table 3 apply only to 650 the server's certificate (first in the chain). 652 Key Exchange Algorithm Server Certificate Type 653 ---------------------- ----------------------- 655 ECDH_ECDSA Certificate must contain an 656 ECDH-capable public key. It 657 must be signed with ECDSA. 659 ECDHE_ECDSA Certificate must contain an 660 ECDSA-capable public key. It 661 must be signed with ECDSA. 663 ECDH_RSA Certificate must contain an 664 ECDH-capable public key. It 665 must be signed with RSA. 667 ECDHE_RSA Certificate must contain an 668 RSA public key authorized for 669 use in digital signatures. It 670 must be signed with RSA. 672 Table 3: Server certificate types 674 Structure of this message: 676 Identical to the TLS Certificate format. 678 Actions of the sender: 680 The server constructs an appropriate certificate chain and conveys it 681 to the client in the Certificate message. If the client has used a 682 Supported Elliptic Curves Extension, the public key in the server's 683 certificate MUST respect the client's choice of elliptic curves; in 684 particular, the public key MUST employ a named curve (not the same 685 curve as an explicit curve) unless the client has indicated support 686 for explicit curves of the appropriate type. If the client has used 687 a Supported Point Formats Extension, both the server's public key 688 point and (in the case of an explicit curve) the curve's base point 689 MUST respect the client's choice of point formats. (A server that 690 cannot satisfy these requirements must not choose an ECC cipher suite 691 in its ServerHello message.) 693 Actions of the receiver: 695 The client validates the certificate chain, extracts the server's 696 public key, and checks that the key type is appropriate for the 697 negotiated key exchange algorithm. 699 5.4 Server Key Exchange 701 When this message is sent: 703 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and 704 ECDH_anon key exchange algorithms. 706 Meaning of this message: 708 This message is used to convey the server's ephemeral ECDH public key 709 (and the corresponding elliptic curve domain parameters) to the 710 client. 712 Structure of this message: 714 enum { explicit_prime (1), explicit_char2 (2), 715 named_curve (3), reserved(4 .. 255) } ECCurveType; 717 explicit_prime: Indicates the elliptic curve domain parameters are 718 conveyed verbosely, and the underlying finite field is a prime 719 field. 721 explicit_char2: Indicates the elliptic curve domain parameters are 722 conveyed verbosely, and the underlying finite field is a 723 characteristic-2 field. 725 named_curve: Indicates that a named curve is used. This option 726 SHOULD be used when applicable. 728 Values 248 through 255 are reserved for private use. 730 struct { 731 opaque a <1..2^8-1>; 732 opaque b <1..2^8-1>; 733 } ECCurve; 735 a, b: These parameters specify the coefficients of the elliptic 736 curve. Each value contains the byte string representation of a 737 field element following the conversion routine in Section 4.3.3 of 738 ANSI X9.62 [6]. 740 struct { 741 opaque point <1..2^8-1>; 742 } ECPoint; 744 point: This is the byte string representation of an elliptic curve 745 point following the conversion routine in Section 4.3.6 of ANSI 746 X9.62 [6]. This byte string may represent an elliptic curve point 747 in uncompressed, hybrid, or compressed format; it MUST conform to 748 what the client has requested through a Supported Point Formats 749 Extension if this extension was used. 751 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; 753 ec_basis_trinomial: Indicates representation of a characteristic-2 754 field using a trinomial basis. 756 ec_basis_pentanomial: Indicates representation of a characteristic-2 757 field using a pentanomial basis. 759 struct { 760 ECCurveType curve_type; 761 select (curve_type) { 762 case explicit_prime: 763 opaque prime_p <1..2^8-1>; 764 ECCurve curve; 765 ECPoint base; 766 opaque order <1..2^8-1>; 767 opaque cofactor <1..2^8-1>; 768 case explicit_char2: 769 uint16 m; 770 ECBasisType basis; 771 select (basis) { 772 case ec_trinomial: 773 opaque k <1..2^8-1>; 774 case ec_pentanomial: 775 opaque k1 <1..2^8-1>; 776 opaque k2 <1..2^8-1>; 777 opaque k3 <1..2^8-1>; 778 }; 779 ECCurve curve; 780 ECPoint base; 781 opaque order <1..2^8-1>; 782 opaque cofactor <1..2^8-1>; 783 case named_curve: 784 NamedCurve namedcurve; 785 }; 786 } ECParameters; 788 curve_type: This identifies the type of the elliptic curve domain 789 parameters. 791 prime_p: This is the odd prime defining the field Fp. 793 curve: Specifies the coefficients a and b of the elliptic curve E. 795 base: Specifies the base point G on the elliptic curve. 797 order: Specifies the order n of the base point. 799 cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) 800 represents the number of points on the elliptic curve E defined 801 over the field Fq (either Fp or F2^m). 803 m: This is the degree of the characteristic-2 field F2^m. 805 k: The exponent k for the trinomial basis representation x^m + x^k 806 +1. 808 k1, k2, k3: The exponents for the pentanomial representation x^m + 809 x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). 811 namedcurve: Specifies a recommended set of elliptic curve domain 812 parameters. All enum values of NamedCurve are allowed except for 813 arbitrary_explicit_prime_curves(253) and 814 arbitrary_explicit_char2_curves(254). These two values are only 815 allowed in the ClientHello extension. 817 struct { 818 ECParameters curve_params; 819 ECPoint public; 820 } ServerECDHParams; 822 curve_params: Specifies the elliptic curve domain parameters 823 associated with the ECDH public key. 825 public: The ephemeral ECDH public key. 827 The ServerKeyExchange message is extended as follows. 829 enum { ec_diffie_hellman } KeyExchangeAlgorithm; 831 ec_diffie_hellman: Indicates the ServerKeyExchange message contains 832 an ECDH public key. 834 select (KeyExchangeAlgorithm) { 835 case ec_diffie_hellman: 836 ServerECDHParams params; 837 Signature signed_params; 838 } ServerKeyExchange; 840 params: Specifies the ECDH public key and associated domain 841 parameters. 843 signed_params: A hash of the params, with the signature appropriate 844 to that hash applied. The private key corresponding to the 845 certified public key in the server's Certificate message is used 846 for signing. 848 enum { ecdsa } SignatureAlgorithm; 850 select (SignatureAlgorithm) { 851 case ecdsa: 852 digitally-signed struct { 853 opaque sha_hash[sha_size]; 854 }; 855 } Signature; 857 NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange 858 algorithm and "anonymous" for ECDH_anon. These cases are defined in 859 TLS [2]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA 860 signatures are generated and verified as described in Section 5.10. 861 As per ANSI X9.62, an ECDSA signature consists of a pair of integers 862 r and s. These integers are both converted into byte strings of the 863 same length as the curve order n using the conversion routine 864 specified in Section 4.3.1 of [6]. The two byte strings are 865 concatenated, and the result is placed in the signature field. 867 Actions of the sender: 869 The server selects elliptic curve domain parameters and an ephemeral 870 ECDH public key corresponding to these parameters according to the 871 ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to 872 the client in the ServerKeyExchange message using the format defined 873 above. 875 Actions of the recipient: 877 The client verifies the signature (when present) and retrieves the 878 server's elliptic curve domain parameters and ephemeral ECDH public 879 key from the ServerKeyExchange message. 881 5.5 Certificate Request 883 When this message is sent: 885 This message is sent when requesting client authentication. 887 Meaning of this message: 889 The server uses this message to suggest acceptable client 890 authentication methods. 892 Structure of this message: 894 The TLS CertificateRequest message is extended as follows. 896 enum { 897 ecdsa_sign(??), rsa_fixed_ecdh(??), 898 ecdsa_fixed_ecdh(??), (255) 899 } ClientCertificateType; 901 ecdsa_sign, etc Indicates that the server would like to use the 902 corresponding client authentication method specified in Section 3. 904 [[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and 905 ecdsa_fixed_ecdh have been left as ??. These values will be 906 assigned when this draft progresses to RFC. Earlier versions of 907 this draft used the values 5, 6, and 7 - however these values have 908 been removed since they are used differently by SSL 3.0 [14] and 909 their use by TLS is being deprecated. ]] 911 Actions of the sender: 913 The server decides which client authentication methods it would like 914 to use, and conveys this information to the client using the format 915 defined above. 917 Actions of the receiver: 919 The client determines whether it has a suitable certificate for use 920 with any of the requested methods, and decides whether or not to 921 proceed with client authentication. 923 5.6 Client Certificate 925 When this message is sent: 927 This message is sent in response to a CertificateRequest when a 928 client has a suitable certificate and has decided to proceed with 929 client authentication. (Note that if the server has used a Supported 930 Point Formats Extension, a certificate can only be considered 931 suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and 932 ECDSA_fixed_ECDH authentication methods if the public key point 933 specified in it respects the server's choice of point formats. If no 934 Supported Point Formats Extension has been used, a certificate can 935 only be considered suitable for use with these authentication methods 936 if the point is represented in uncompressed point format.) 938 Meaning of this message: 940 This message is used to authentically convey the client's static 941 public key to the server. The following table summarizes what client 942 certificate types are appropriate for the ECC-based client 943 authentication mechanisms described in Section 3. ECC public keys 944 must be encoded in certificates as described in Section 5.9. 946 NOTE: The client's Certificate message is capable of carrying a chain 947 of certificates. The restrictions mentioned in Table 4 apply only to 948 the client's certificate (first in the chain). 950 Client 951 Authentication Method Client Certificate Type 952 --------------------- ----------------------- 954 ECDSA_sign Certificate must contain an 955 ECDSA-capable public key and 956 be signed with ECDSA. 958 ECDSA_fixed_ECDH Certificate must contain an 959 ECDH-capable public key on the 960 same elliptic curve as the server's 961 long-term ECDH key. This certificate 962 must be signed with ECDSA. 964 RSA_fixed_ECDH Certificate must contain an 965 ECDH-capable public key on the 966 same elliptic curve as the server's 967 long-term ECDH key. This certificate 968 must be signed with RSA. 970 Table 4: Client certificate types 972 Structure of this message: 974 Identical to the TLS client Certificate format. 976 Actions of the sender: 978 The client constructs an appropriate certificate chain, and conveys 979 it to the server in the Certificate message. 981 Actions of the receiver: 983 The TLS server validates the certificate chain, extracts the client's 984 public key, and checks that the key type is appropriate for the 985 client authentication method. 987 5.7 Client Key Exchange 989 When this message is sent: 991 This message is sent in all key exchange algorithms. If client 992 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 993 message is empty. Otherwise, it contains the client's ephemeral ECDH 994 public key. 996 Meaning of the message: 998 This message is used to convey ephemeral data relating to the key 999 exchange belonging to the client (such as its ephemeral ECDH public 1000 key). 1002 Structure of this message: 1004 The TLS ClientKeyExchange message is extended as follows. 1006 enum { implicit, explicit } PublicValueEncoding; 1008 implicit, explicit: For ECC cipher suites, this indicates whether 1009 the client's ECDH public key is in the client's certificate 1010 ("implicit") or is provided, as an ephemeral ECDH public key, in 1011 the ClientKeyExchange message ("explicit"). (This is "explicit" 1012 in ECC cipher suites except when the client uses the 1013 ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication 1014 mechanism.) 1015 struct { 1016 select (PublicValueEncoding) { 1017 case implicit: struct { }; 1018 case explicit: ECPoint ecdh_Yc; 1019 } ecdh_public; 1020 } ClientECDiffieHellmanPublic; 1022 ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte 1023 string ECPoint.point, which may represent an elliptic curve point 1024 in uncompressed, hybrid, or compressed format. Here the format 1025 MUST conform to what the server has requested through a Supported 1026 Point Formats Extension if this extension was used, and MUST be 1027 uncompressed if this extension was not used. 1029 struct { 1030 select (KeyExchangeAlgorithm) { 1031 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 1032 } exchange_keys; 1033 } ClientKeyExchange; 1035 Actions of the sender: 1037 The client selects an ephemeral ECDH public key corresponding to the 1038 parameters it received from the server according to the ECKAS-DH1 1039 scheme from IEEE 1363 [5]. It conveys this information to the client 1040 in the ClientKeyExchange message using the format defined above. 1042 Actions of the recipient: 1044 The server retrieves the client's ephemeral ECDH public key from the 1045 ClientKeyExchange message and checks that it is on the same elliptic 1046 curve as the server's ECDH key. 1048 5.8 Certificate Verify 1050 When this message is sent: 1052 This message is sent when the client sends a client certificate 1053 containing a public key usable for digital signatures, e.g. when the 1054 client is authenticated using the ECDSA_sign mechanism. 1056 Meaning of the message: 1058 This message contains a signature that proves possession of the 1059 private key corresponding to the public key in the client's 1060 Certificate message. 1062 Structure of this message: 1064 The TLS CertificateVerify message is extended as follows. 1066 enum { ecdsa } SignatureAlgorithm; 1068 select (SignatureAlgorithm) { 1069 case ecdsa: 1070 digitally-signed struct { 1071 opaque sha_hash[sha_size]; 1072 }; 1073 } Signature; 1075 For the ecdsa case, the signature field in the CertificateVerify 1076 message contains an ECDSA signature computed over handshake messages 1077 exchanged so far. ECDSA signatures are computed as described in 1078 Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a 1079 pair of integers r and s. These integers are both converted into 1080 byte strings of the same length as the curve order n using the 1081 conversion routine specified in Section 4.3.1 of [6]. The two byte 1082 strings are concatenated, and the result is placed in the signature 1083 field. 1085 Actions of the sender: 1087 The client computes its signature over all handshake messages sent or 1088 received starting at client hello up to but not including this 1089 message. It uses the private key corresponding to its certified 1090 public key to compute the signature which is conveyed in the format 1091 defined above. 1093 Actions of the receiver: 1095 The server extracts the client's signature from the CertificateVerify 1096 message, and verifies the signature using the public key it received 1097 in the client's Certificate message. 1099 5.9 Elliptic Curve Certificates 1101 X509 certificates containing ECC public keys or signed using ECDSA 1102 MUST comply with [11] or another RFC that replaces or extends it. 1103 Clients SHOULD use the elliptic curve domain parameters recommended 1104 in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. 1106 5.10 ECDH, ECDSA and RSA Computations 1108 All ECDH calculations (including parameter and key generation as well 1109 as the shared secret calculation) MUST be performed according to [5] 1110 using the ECKAS-DH1 scheme with the identity map as key derivation 1111 function, so that the premaster secret is the x-coordinate of the 1112 ECDH shared secret elliptic curve point, i.e. the octet string Z in 1113 IEEE 1363 terminology. 1115 Note that a new extension may be introduced in the future to allow 1116 the use of a different KDF during computation of the premaster 1117 secret. In this event, the new KDF would be used in place of the 1118 process detailed above. This may be desirable, for example, to 1119 support compatibility with the planned NIST key agreement standard. 1121 All ECDSA computations MUST be performed according to ANSI X9.62 [6] 1122 or its successors. Data to be signed/verified is hashed and the 1123 result run directly through the ECDSA algorithm with no additional 1124 hashing. The default hash function is SHA-1 [7] and sha_size (see 1125 Section 5.4 and Section 5.8) is 20. However, an alternative hash 1126 function, such as one of the new SHA hash functions specified in FIPS 1127 180-2 [7], may be used instead if the certificate containing the EC 1128 public key explicitly requires use of another hash function. (The 1129 mechanism for specifying the required hash function has not been 1130 standardized but this provision anticipates such standardization and 1131 obviates the need to update this document in response. Future PKIX 1132 RFCs may choose, for example, to specify the hash function to be used 1133 with a public key in the parameters field of subjectPublicKeyInfo.) 1135 All RSA signatures must be generated and verified according to PKCS#1 1136 [9] block type 1. 1138 6. Cipher Suites 1140 The table below defines new ECC cipher suites that use the key 1141 exchange algorithms specified in Section 2. 1143 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1144 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1145 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } 1146 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1147 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1148 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1150 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1151 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1152 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1153 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1154 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1156 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1157 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1158 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1159 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1160 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1162 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1163 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1164 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1165 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1166 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1168 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } 1169 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } 1170 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1171 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1172 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1174 Table 5: TLS ECC cipher suites 1176 [[ EDITOR: The actual cipher suite numbers will be assigned when this 1177 draft progresses to RFC. ]] 1179 The key exchange method, cipher, and hash algorithm for each of these 1180 cipher suites are easily determined by examining the name. Ciphers 1181 other than AES ciphers, and hash algorithms are defined in [2]. AES 1182 ciphers are defined in [15]. 1184 Server implementations SHOULD support all of the following cipher 1185 suites, and client implementations SHOULD support at least one of 1186 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 1187 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 1188 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 1189 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 1191 7. Security Considerations 1193 This document is based on [2], [5], [6] and [15]. The appropriate 1194 security considerations of those documents apply. 1196 One important issue that implementors and users must consider is 1197 elliptic curve selection. Guidance on selecting an appropriate 1198 elliptic curve size is given in Table 1. 1200 Beyond elliptic curve size, the main issue is elliptic curve 1201 structure. As a general principle, it is more conservative to use 1202 elliptic curves with as little algebraic structure as possible - thus 1203 random curves are more conservative than special curves such as 1204 Koblitz curves, and curves over F_p with p random are more 1205 conservative than curves over F_p with p of a special form (and 1206 curves over F_p with p random might be considered more conservative 1207 than curves over F_2^m as there is no choice between multiple fields 1208 of similar size for characteristic 2). Note, however, that algebraic 1209 structure can also lead to implementation efficiencies and 1210 implementors and users may, therefore, need to balance conservatism 1211 against a need for efficiency. Concrete attacks are known against 1212 only very few special classes of curves, such as supersingular 1213 curves, and these classes are excluded from the ECC standards that 1214 this document references [5], [6]. 1216 Another issue is the potential for catastrophic failures when a 1217 single elliptic curve is widely used. In this case, an attack on the 1218 elliptic curve might result in the compromise of a large number of 1219 keys. Again, this concern may need to be balanced against efficiency 1220 and interoperability improvements associated with widely-used curves. 1221 Substantial additional information on elliptic curve choice can be 1222 found in [4], [5], [6], [8]. 1224 Implementors and users must also consider whether they need forward 1225 secrecy. Forward secrecy refers to the property that session keys 1226 are not compromised if the static, certified keys belonging to the 1227 server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key 1228 exchange algorithms provide forward secrecy protection in the event 1229 of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. 1230 Similarly if the client is providing a static, certified key, 1231 ECDSA_sign client authentication provides forward secrecy protection 1232 in the event of client key compromise, while ECDSA_fixed_ECDH and 1233 RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy 1234 protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, 1235 with ECDSA_sign used for client authentication if necessary. Here 1236 again the security benefits of forward secrecy may need to be 1237 balanced against the improved efficiency offered by other options. 1239 8. Acknowledgments 1241 The authors wish to thank Bill Anderson and Tim Dierks. 1243 9. References 1245 9.1 Normative References 1247 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 1248 Levels", RFC 2119, March 1997. 1250 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1251 RFC 2246, January 1999. 1253 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1254 T. Wright, "Transport Layer Security (TLS) Extensions", 1255 draft-ietf-tls-rfc3546bis-00.txt (work in progress), Nov. 2004. 1257 [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, 1258 . 1260 [5] IEEE, "Standard Specifications for Public Key Cryptography", 1261 IEEE 1363, 2000. 1263 [6] ANSI, "Public Key Cryptography For The Financial Services 1264 Industry: The Elliptic Curve Digital Signature Algorithm 1265 (ECDSA)", ANSI X9.62, 1998. 1267 [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 1269 [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 1271 [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1272 1.5", PKCS 1, November 1993. 1274 [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 1275 2000, . 1277 [11] Polk, T., Housley, R., and L. Bassham, "Algorithms and 1278 Identifiers for the Internet X.509 Public Key Infrastructure 1279 Certificate and Certificate Revocation List (CRL) Profile", 1280 RFC 3279, April 2002. 1282 9.2 Informative References 1284 [12] Harper, G., Menezes, A., and S. Vanstone, "Public-Key 1285 Cryptosystems with Very Small Key Lengths", Advances in 1286 Cryptology -- EUROCRYPT '92, LNCS 658, 1993. 1288 [13] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1289 Sizes", Journal of Cryptology 14 (2001) 255-293, 1290 . 1292 [14] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 1293 Version 3.0", November 1996, 1294 . 1296 [15] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1297 Transport Layer Security (TLS)", RFC 3268, June 2002. 1299 Authors' Addresses 1301 Vipul Gupta 1302 Sun Microsystems Laboratories 1303 16 Network Circle 1304 MS UMPK16-160 1305 Menlo Park, CA 94025 1306 US 1308 Phone: +1 650 786 7551 1309 Email: vipul.gupta@sun.com 1311 Simon Blake-Wilson 1312 Basic Commerce & Industries, Inc. 1313 96 Spandia Ave 1314 Unit 606 1315 Toronto, ON M6G 2T6 1316 CA 1318 Phone: +1 416 214 5961 1319 Email: sblakewilson@bcisse.com 1321 Bodo Moeller 1322 University of Calgary 1323 Dept of Math & Stats 1324 2500 University Dr NW 1325 Calgary, AB T2N 1N4 1326 CA 1328 Phone: +1 403 220 5735 1329 Email: bodo@openssl.org 1331 Chris Hawk 1332 Corriente Networks 1334 Email: chris@corriente.net 1335 Nelson Bolyard 1337 Email: nelson@bolyard.com 1339 Intellectual Property Statement 1341 The IETF takes no position regarding the validity or scope of any 1342 Intellectual Property Rights or other rights that might be claimed to 1343 pertain to the implementation or use of the technology described in 1344 this document or the extent to which any license under such rights 1345 might or might not be available; nor does it represent that it has 1346 made any independent effort to identify any such rights. Information 1347 on the procedures with respect to rights in RFC documents can be 1348 found in BCP 78 and BCP 79. 1350 Copies of IPR disclosures made to the IETF Secretariat and any 1351 assurances of licenses to be made available, or the result of an 1352 attempt made to obtain a general license or permission for the use of 1353 such proprietary rights by implementers or users of this 1354 specification can be obtained from the IETF on-line IPR repository at 1355 http://www.ietf.org/ipr. 1357 The IETF invites any interested party to bring to its attention any 1358 copyrights, patents or patent applications, or other proprietary 1359 rights that may cover technology that may be required to implement 1360 this standard. Please address the information to the IETF at 1361 ietf-ipr@ietf.org. 1363 Disclaimer of Validity 1365 This document and the information contained herein are provided on an 1366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1368 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1369 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1370 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1373 Copyright Statement 1375 Copyright (C) The Internet Society (2005). This document is subject 1376 to the rights, licenses and restrictions contained in BCP 78, and 1377 except as set forth therein, the authors retain all their rights. 1379 Acknowledgment 1381 Funding for the RFC Editor function is currently provided by the 1382 Internet Society.