idnits 2.17.00 (12 Aug 2021) /tmp/idnits12510/draft-ietf-tls-ecc-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 501 has weird spacing: '...rveType cur...' == Line 514 has weird spacing: '... opaque k <1....' == Line 516 has weird spacing: '... opaque k1 <1...' == Line 517 has weird spacing: '... opaque k2 <1...' == Line 518 has weird spacing: '... opaque k3 <1...' == (3 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 (June 2003) is 6914 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 195 == Unused Reference: '4' is defined on line 991, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1018, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) -- 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 normative reference: RFC 3268 (ref. '11') (Obsoleted by RFC 5246) -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 12 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: December 2003 S. Blake-Wilson 5 BCI 6 B. Moeller 7 Technische Universitaet Darmstadt 8 C. Hawk 9 Independent Consultant 10 June 2003 12 ECC Cipher Suites for TLS 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 30, 2003. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 This document describes new key exchange algorithms based on Elliptic 45 Curve Cryptography (ECC) for the TLS (Transport Layer Security) 46 protocol. In particular, it specifies the use of Elliptic Curve 47 Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of 48 Elliptic Curve Digital Signature Algorithm (ECDSA) as a new 49 authentication mechanism. 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [1]. 55 Please send comments on this document to the TLS mailing list. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 5 61 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 9 67 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4. Data Structures and Computations . . . . . . . . . . . . . . . 11 71 4.1 Server Certificate . . . . . . . . . . . . . . . . . . . . . . 11 72 4.2 Server Key Exchange . . . . . . . . . . . . . . . . . . . . . 12 73 4.3 Certificate Request . . . . . . . . . . . . . . . . . . . . . 17 74 4.4 Client Certificate . . . . . . . . . . . . . . . . . . . . . . 18 75 4.5 Client Key Exchange . . . . . . . . . . . . . . . . . . . . . 19 76 4.6 Certificate Verify . . . . . . . . . . . . . . . . . . . . . . 20 77 4.7 Elliptic Curve Certificates . . . . . . . . . . . . . . . . . 22 78 4.8 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . . 22 79 5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 23 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 26 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 83 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 85 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 87 1. Introduction 89 Elliptic Curve Cryptography (ECC) is emerging as an attractive 90 public-key cryptosystem for mobile/wireless environments. Compared 91 to currently prevalent cryptosystems such as RSA, ECC offers 92 equivalent security with smaller key sizes. This is illustrated in 93 the following table, based on [2], which gives approximate comparable 94 key sizes for symmetric- and asymmetric-key cryptosystems based on 95 the best-known algorithms for attacking them. 97 Symmetric | ECC | DH/DSA/RSA 98 -------------+---------+------------ 99 80 | 163 | 1024 100 128 | 283 | 3072 101 192 | 409 | 7680 102 256 | 571 | 15360 104 Table 1: Comparable key sizes (in bits) 106 Smaller key sizes result in power, bandwidth and computational 107 savings that make ECC especially attractive for constrained 108 environments. 110 This document describes additions to TLS to support ECC. In 111 particular, it defines 113 o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement 114 scheme with long-term or ephemeral keys to establish the TLS 115 premaster secret, and 117 o the use of fixed-ECDH certificates and ECDSA for authentication of 118 TLS peers. 120 The remainder of this document is organized as follows. Section 2 121 provides an overview of ECC-based key exchange algorithms for TLS. 122 Section 3 describes the use of ECC certificates for client 123 authentication. Section 4 specifies various data structures needed 124 for an ECC-based handshake, their encoding in TLS messages and the 125 processing of those messages. Section 5 defines new ECC-based cipher 126 suites and identifies a small subset of these as recommended for all 127 implementations of this specification. Section 6, Section 7 and 128 Section 8 mention security considerations, intellectual property 129 rights, and acknowledgments, respectively. This is followed by a 130 list of references cited in this document and the authors' contact 131 information. 133 Implementation of this specification requires familiarity with both 134 TLS [3] and ECC [5][6][7][9] . 136 2. Key Exchange Algorithms 138 This document introduces five new ECC-based key exchange algorithms 139 for TLS. All of them use ECDH to compute the TLS premaster secret 140 and differ only in the lifetime of ECDH keys (long-term or ephemeral) 141 and the mechanism (if any) used to authenticate them. The derivation 142 of the TLS master secret from the premaster secret and the subsequent 143 generation of bulk encryption/MAC keys and initialization vectors is 144 independent of the key exchange algorithm and not impacted by the 145 introduction of ECC. 147 The table below summarizes the new key exchange algorithms which 148 mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [3]), 149 respectively. 151 Key 152 Exchange 153 Algorithm Description 154 --------- ----------- 156 ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. 158 ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. 160 ECDH_RSA Fixed ECDH with RSA-signed certificates. 162 ECDHE_RSA Ephemeral ECDH with RSA signatures. 164 ECDH_anon Anonymous ECDH, no signatures. 166 Table 2: ECC key exchange algorithms 168 Note that the anonymous key exchange algorithm does not provide 169 authentication of the server or the client. Like other anonymous TLS 170 key exchanges, it is subject to man-in-the-middle attacks. 171 Implementations of this algorithm SHOULD provide authentication by 172 other means. 174 Note that there is no structural difference between ECDH and ECDSA 175 keys. A certificate issuer may use X509.v3 keyUsage and 176 extendedKeyUsage extensions to restrict the use of an ECC public key 177 to certain computations. This document refers to an ECC key as ECDH- 178 capable if its use in ECDH is permitted. ECDSA-capable is defined 179 similarly. 181 Client Server 182 ------ ------ 184 ClientHello --------> 185 ServerHello 186 Certificate* 187 ServerKeyExchange* 188 CertificateRequest*+ 189 <-------- ServerHelloDone 190 Certificate*+ 191 ClientKeyExchange 192 CertificateVerify*+ 193 [ChangeCipherSpec] 194 Finished --------> 195 [ChangeCipherSpec] 196 <-------- Finished 198 Application Data <-------> Application Data 200 Figure 1: Message flow in a full TLS handshake 201 * message is not sent under some conditions 202 + message is not sent unless the client is 203 authenticated 205 Figure 1 shows all messages involved in the TLS key establishment 206 protocol (aka full handshake). The addition of ECC has direct impact 207 only on the the server's Certificate message, the ServerKeyExchange, 208 the ClientKeyExchange, the CertificateRequest, the client's 209 Certificate message, and the CertificateVerify. Next, we describe 210 each ECC key exchange algorithm in greater detail in terms of the 211 content and processing of these messages. For ease of exposition, we 212 defer discussion of client authentication and associated messages 213 (identified with a + in Figure 1) until Section 3. 215 2.1 ECDH_ECDSA 217 In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable 218 public key and be signed with ECDSA. 220 A ServerKeyExchange MUST NOT be sent (the server's certificate 221 contains all the necessary keying information required by the client 222 to arrive at the premaster secret). 224 The client MUST generate an ECDH key pair on the same curve as the 225 server's long-term public key and send its public key in the 226 ClientKeyExchange message (except when using client authentication 227 algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the 228 modifications from section Section 3.2 or Section 3.3 apply). 230 Both client and server MUST perform an ECDH operation and use the 231 resultant shared secret as the premaster secret. All ECDH 232 calculations are performed as specified in Section 4.8 234 2.2 ECDHE_ECDSA 236 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- 237 capable public key and be signed with ECDSA. 239 The server MUST send its ephemeral ECDH public key and a 240 specification of the corresponding curve in the ServerKeyExchange 241 message. These parameters MUST be signed with ECDSA using the 242 private key corresponding to the public key in the server's 243 Certificate. 245 The client MUST generate an ECDH key pair on the same curve as the 246 server's ephemeral ECDH key and send its public key in the 247 ClientKeyExchange message. 249 Both client and server MUST perform an ECDH operation (Section 4.8) 250 and use the resultant shared secret as the premaster secret. 252 2.3 ECDH_RSA 254 This key exchange algorithm is the same as ECDH_ECDSA except the 255 server's certificate MUST be signed with RSA rather than ECDSA. 257 2.4 ECDHE_RSA 259 This key exchange algorithm is the same as ECDHE_ECDSA except the 260 server's certificate MUST contain an RSA public key authorized for 261 signing and the signature in the ServerKeyExchange message MUST be 262 computed with the corresponding RSA private key. The server 263 certificate MUST be signed with RSA. 265 2.5 ECDH_anon 267 In ECDH_anon, the server's Certificate, the CertificateRequest, the 268 client's Certificate, and the CertificateVerify messages MUST NOT be 269 sent. 271 The server MUST send an ephemeral ECDH public key and a specification 272 of the corresponding curve in the ServerKeyExchange message. These 273 parameters MUST NOT be signed. 275 The client MUST generate an ECDH key pair on the same curve as the 276 server's ephemeral ECDH key and send its public key in the 277 ClientKeyExchange message. 279 Both client and server MUST perform an ECDH operation and use the 280 resultant shared secret as the premaster secret. All ECDH 281 calculations are performed as specified in Section 4.8 283 3. Client Authentication 285 This document defines three new client authentication mechanisms 286 named after the type of client certificate involved: ECDSA_sign, 287 ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is 288 usable with any of the non-anonymous ECC key exchange algorithms 289 described in Section 2 as well as other non-anonymous (non-ECC) key 290 exchange algorithms defined in TLS [3]. The ECDSA_fixed_ECDH and 291 RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. 292 Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the 293 use of a long-term ECDH client key would jeopardize the forward 294 secrecy property of these algorithms. 296 The server can request ECC-based client authentication by including 297 one or more of these certificate types in its CertificateRequest 298 message. The server MUST NOT include any certificate types that are 299 prohibited for the negotiated key exchange algorithm. The client 300 must check if it possesses a certificate appropriate for any of the 301 methods suggested by the server and is willing to use it for 302 authentication. 304 If these conditions are not met, the client should send a client 305 Certificate message containing no certificates. In this case, the 306 ClientKeyExchange should be sent as described in Section 2 and the 307 CertificateVerify should not be sent. If the server requires client 308 authentication, it may respond with a fatal handshake failure alert. 310 If the client has an appropriate certificate and is willing to use it 311 for authentication, it MUST send that certificate in the client's 312 Certificate message (as per Section 4.4) and prove possession of the 313 private key corresponding to the certified key. The process of 314 determining an appropriate certificate and proving possession is 315 different for each authentication mechanism and described below. 317 NOTE: It is permissible for a server to request (and the client to 318 send) a client certificate of a different type than the server 319 certificate. 321 3.1 ECDSA_sign 323 To use this authentication mechanism, the client MUST possess a 324 certificate containing an ECDSA-capable public key and signed with 325 ECDSA. 327 The client MUST prove possession of the private key corresponding to 328 the certified key by including a signature in the CertificateVerify 329 message as described in Section 4.6. 331 3.2 ECDSA_fixed_ECDH 333 To use this authentication mechanism, the client MUST possess a 334 certificate containing an ECDH-capable public key and that 335 certificate MUST be signed with ECDSA. Furthermore, the client's 336 ECDH key MUST be on the same elliptic curve as the server's long-term 337 (certified) ECDH key. 339 When using this authentication mechanism, the client MUST send an 340 empty ClientKeyExchange as described in Section 4.5 and MUST NOT send 341 the CertificateVerify message. The ClientKeyExchange is empty since 342 the client's ECDH public key required by the server to compute the 343 premaster secret is available inside the client's certificate. The 344 client's ability to arrive at the same premaster secret as the server 345 (demonstrated by a successful exchange of Finished messages) proves 346 possession of the private key corresponding to the certified public 347 key and the CertificateVerify message is unnecessary. 349 3.3 RSA_fixed_ECDH 351 This authentication mechanism is identical to ECDSA_fixed_ECDH except 352 the client's certificate MUST be signed with RSA. 354 4. Data Structures and Computations 356 This section specifies the data structures and computations used by 357 ECC-based key mechanisms specified in Section 2 and Section 3. The 358 presentation language used here is the same as that used in TLS [3]. 359 Since this specification extends TLS, these descriptions should be 360 merged with those in the TLS specification and any others that extend 361 TLS. This means that enum types may not specify all possible values 362 and structures with multiple formats chosen with a select() clause 363 may not indicate all possible cases. 365 4.1 Server Certificate 367 When this message is sent: 369 This message is sent in all non-anonymous ECC-based key exchange 370 algorithms. 372 Meaning of this message: 374 This message is used to authentically convey the server's static 375 public key to the client. The following table shows the server 376 certificate type appropriate for each key exchange algorithm. ECC 377 public keys must be encoded in certificates as described in Section 378 4.7. 380 NOTE: The server's Certificate message is capable of carrying a chain 381 of certificates. The restrictions mentioned in Table 3 apply only to 382 the server's certificate (first in the chain). 384 Key Exchange Algorithm Server Certificate Type 385 ---------------------- ----------------------- 387 ECDH_ECDSA Certificate must contain an 388 ECDH-capable public key. It 389 must be signed with ECDSA. 391 ECDHE_ECDSA Certificate must contain an 392 ECDSA-capable public key. It 393 must be signed with ECDSA. 395 ECDH_RSA Certificate must contain an 396 ECDH-capable public key. It 397 must be signed with RSA. 399 ECDHE_RSA Certificate must contain an 400 RSA public key authorized for 401 use in digital signatures. It 402 must be signed with RSA. 404 Table 3: Server certificate types 406 Structure of this message: 408 Identical to the TLS Certificate format. 410 Actions of the sender: 412 The server constructs an appropriate certificate chain and conveys it 413 to the client in the Certificate message. 415 Actions of the receiver: 417 The client validates the certificate chain, extracts the server's 418 public key, and checks that the key type is appropriate for the 419 negotiated key exchange algorithm. 421 4.2 Server Key Exchange 423 When this message is sent: 425 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and 426 ECDH_anon key exchange algorithms. 428 Meaning of this message: 430 This message is used to convey the server's ephemeral ECDH public key 431 (and the corresponding elliptic curve domain parameters) to the 432 client. 434 Structure of this message: 436 enum { explicit_prime (1), explicit_char2 (2), 437 named_curve (3), (255) } ECCurveType; 439 explicit_prime: Indicates the elliptic curve domain parameters are 440 conveyed verbosely, and the underlying finite field is a prime 441 field. 443 explicit_char2: Indicates the elliptic curve domain parameters are 444 conveyed verbosely, and the underlying finite field is a 445 characteristic 2 field. 447 named_curve: Indicates that a named curve is used. This option 448 SHOULD be used when applicable. 450 struct { 451 opaque a <1..2^8-1>; 452 opaque b <1..2^8-1>; 453 opaque seed <0..2^8-1>; 454 } ECCurve; 456 a, b: These parameters specify the coefficients of the elliptic 457 curve. Each value contains the byte string representation of a 458 field element following the conversion routine in Section 4.3.3 of 459 ANSI X9.62 [7]. 461 seed: This is an optional parameter used to derive the coefficients 462 of a randomly generated elliptic curve. 464 struct { 465 opaque point <1..2^8-1>; 466 } ECPoint; 468 point: This is the byte string representation of an elliptic curve 469 point following the conversion routine in Section 4.3.6 of ANSI 470 X9.62 [7]. Note that this byte string may represent an elliptic 471 curve point in compressed or uncompressed form. Implementations 472 of this specification MUST support the uncompressed form and MAY 473 support the compressed form. 475 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; 477 ec_basis_trinomial: Indicates representation of a characteristic two 478 field using a trinomial basis. 480 ec_basis_pentanomial: Indicates representation of a characteristic 481 two field using a pentanomial basis. 483 enum { 484 sect163k1 (1), sect163r1 (2), sect163r2 (3), 485 sect193r1 (4), sect193r2 (5), sect233k1 (6), 486 sect233r1 (7), sect239k1 (8), sect283k1 (9), 487 sect283r1 (10), sect409k1 (11), sect409r1 (12), 488 sect571k1 (13), sect571r1 (14), secp160k1 (15), 489 secp160r1 (16), secp160r2 (17), secp192k1 (18), 490 secp192r1 (19), secp224k1 (20), secp224r1 (21), 491 secp256k1 (22), secp256r1 (23), secp384r1 (24), 492 secp521r1 (25), reserved (240..247), (255) 493 } NamedCurve; 495 sect163k1, etc: Indicates use of the corresponding named curve 496 specified in SEC 2 [12]. Note that many of these curves are also 497 recommended in ANSI X9.62 [7], and FIPS 186-2 [9]. Values 240 498 through 247 are reserved for private use. 500 struct { 501 ECCurveType curve_type; 502 select (curve_type) { 503 case explicit_prime: 504 opaque prime_p <1..2^8-1>; 505 ECCurve curve; 506 ECPoint base; 507 opaque order <1..2^8-1>; 508 opaque cofactor <1..2^8-1>; 509 case explicit_char2: 510 uint16 m; 511 ECBasisType basis; 512 select (basis) { 513 case ec_trinomial: 514 opaque k <1..2^8-1>; 515 case ec_pentanomial: 516 opaque k1 <1..2^8-1>; 517 opaque k2 <1..2^8-1>; 518 opaque k3 <1..2^8-1>; 519 }; 520 ECCurve curve; 521 ECPoint base; 522 opaque order <1..2^8-1>; 523 opaque cofactor <1..2^8-1>; 524 case named_curve: 525 NamedCurve namedcurve; 526 }; 527 } ECParameters; 529 curve_type: This identifies the type of the elliptic curve domain 530 parameters. 532 prime_p: This is the odd prime defining the field Fp. 534 curve: Specifies the coefficients a and b (and optional seed) of the 535 elliptic curve E. 537 base: Specifies the base point G on the elliptic curve. 539 order: Specifies the order n of the base point. 541 cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) 542 represents the number of points on the elliptic curve E defined 543 over the field Fq. 545 m: This is the degree of the characteristic-two field F2^m. 547 k: The exponent k for the trinomial basis representation x^m + x^k 548 +1. 550 k1, k2, k3: The exponents for the pentanomial representation x^m + 551 x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). 553 namedcurve: Specifies a recommended set of elliptic curve domain 554 parameters. 556 struct { 557 ECParameters curve_params; 558 ECPoint public; 559 } ServerECDHParams; 561 curve_params: Specifies the elliptic curve domain parameters 562 associated with the ECDH public key. 564 public: The ephemeral ECDH public key. 566 The ServerKeyExchange message is extended as follows. 568 enum { ec_diffie_hellman } KeyExchangeAlgorithm; 570 ec_diffie_hellman: Indicates the ServerKeyExchange message contains 571 an ECDH public key. 573 select (KeyExchangeAlgorithm) { 574 case ec_diffie_hellman: 575 ServerECDHParams params; 576 Signature signed_params; 577 } ServerKeyExchange; 579 params: Specifies the ECDH public key and associated domain 580 parameters. 582 signed_params: A hash of the params, with the signature appropriate 583 to that hash applied. The private key corresponding to the 584 certified public key in the server's Certificate message is used 585 for signing. 587 enum { ecdsa } SignatureAlgorithm; 588 select (SignatureAlgorithm) { 589 case ecdsa: 590 digitally-signed struct { 591 opaque sha_hash[sha_size]; 592 }; 593 } Signature; 595 NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange 596 algorithm and 'anonymous' for ECDH_anon. These cases are defined in 597 TLS [3]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA 598 signatures are generated and verified as described in Section 4.8. 599 As per ANSI X9.62, an ECDSA signature consists of a pair of integers 600 r and s. These integers are both converted into byte strings of the 601 same length as the curve order n using the conversion routine 602 specified in Section 4.3.1 of [7]. The two byte strings are 603 concatenated, and the result is placed in the signature field. 605 Actions of the sender: 607 The server selects elliptic curve domain parameters and an ephemeral 608 ECDH public key corresponding to these parameters according to the 609 ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to 610 the client in the ServerKeyExchange message using the format defined 611 above. 613 Actions of the recipient: 615 The client verifies the signature (when present) and retrieves the 616 server's elliptic curve domain parameters and ephemeral ECDH public 617 key from the ServerKeyExchange message. 619 4.3 Certificate Request 621 When this message is sent: 623 This message is sent when requesting client authentication. 625 Meaning of this message: 627 The server uses this message to suggest acceptable client 628 authentication methods. 630 Structure of this message: 632 The TLS CertificateRequest message is extended as follows. 634 enum { 635 ecdsa_sign(?), rsa_fixed_ecdh(?), 636 ecdsa_fixed_ecdh(?), (255) 637 } ClientCertificateType; 639 ecdsa_sign, etc Indicates that the server would like to use the 640 corresponding client authentication method specified in Section 3. 642 EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and 643 ecdsa_fixed_ecdh have been left as ?. These values will be 644 assigned when this draft progresses to RFC. Earlier versions of 645 this draft used the values 5, 6, and 7 - however these values have 646 been removed since they are used differently by SSL 3.0 and their 647 use by TLS is being deprecated. 649 Actions of the sender: 651 The server decides which client authentication methods it would like 652 to use, and conveys this information to the client using the format 653 defined above. 655 Actions of the receiver: 657 The client determines whether it has an appropriate certificate for 658 use with any of the requested methods, and decides whether or not to 659 proceed with client authentication. 661 4.4 Client Certificate 663 When this message is sent: 665 This message is sent in response to a CertificateRequest when a 666 client has a suitable certificate. 668 Meaning of this message: 670 This message is used to authentically convey the client's static 671 public key to the server. The following table summarizes what client 672 certificate types are appropriate for the ECC-based client 673 authentication mechanisms described in Section 3. ECC public keys 674 must be encoded in certificates as described in Section 4.7. 676 NOTE: The client's Certificate message is capable of carrying a chain 677 of certificates. The restrictions mentioned in Table 4 apply only to 678 the client's certificate (first in the chain). 680 Client 681 Authentication Method Client Certificate Type 682 --------------------- ----------------------- 684 ECDSA_sign Certificate must contain an 685 ECDSA-capable public key and 686 be signed with ECDSA. 688 ECDSA_fixed_ECDH Certificate must contain an 689 ECDH-capable public key on the 690 same elliptic curve as the server's 691 long-term ECDH key. This certificate 692 must be signed with ECDSA. 694 RSA_fixed_ECDH Certificate must contain an 695 ECDH-capable public key on the 696 same elliptic curve as the server's 697 long-term ECDH key. This certificate 698 must be signed with RSA. 700 Table 4: Client certificate types 702 Structure of this message: 704 Identical to the TLS client Certificate format. 706 Actions of the sender: 708 The client constructs an appropriate certificate chain, and conveys 709 it to the server in the Certificate message. 711 Actions of the receiver: 713 The TLS server validates the certificate chain, extracts the client's 714 public key, and checks that the key type is appropriate for the 715 client authentication method. 717 4.5 Client Key Exchange 719 When this message is sent: 721 This message is sent in all key exchange algorithms. If client 722 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 723 message is empty. Otherwise, it contains the client's ephemeral ECDH 724 public key. 726 Meaning of the message: 728 This message is used to convey ephemeral data relating to the key 729 exchange belonging to the client (such as its ephemeral ECDH public 730 key). 732 Structure of this message: 734 The TLS ClientKeyExchange message is extended as follows. 736 enum { yes, no } EphemeralPublicKey; 738 yes, no: Indicates whether or not the client is providing an 739 ephemeral ECDH public key. (In ECC ciphersuites, this is "yes" 740 except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH 741 client authentication mechanism.) 743 struct { 744 select (EphemeralPublicKey) { 745 case yes: ECPoint ecdh_Yc; 746 case no: struct { }; 747 } ecdh_public; 748 } ClientECDiffieHellmanPublic; 750 ecdh_Yc: Contains the client's ephemeral ECDH public key. 752 struct { 753 select (KeyExchangeAlgorithm) { 754 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 755 } exchange_keys; 756 } ClientKeyExchange; 758 Actions of the sender: 760 The client selects an ephemeral ECDH public key corresponding to the 761 parameters it received from the server according to the ECKAS-DH1 762 scheme from IEEE 1363 [6]. It conveys this information to the client 763 in the ClientKeyExchange message using the format defined above. 765 Actions of the recipient: 767 The server retrieves the client's ephemeral ECDH public key from the 768 ClientKeyExchange message and checks that it is on the same elliptic 769 curve as the server's ECDH key. 771 4.6 Certificate Verify 773 When this message is sent: 775 This message is sent when the client sends a client certificate 776 containing a public key usable for digital signatures, e.g. when the 777 client is authenticated using the ECDSA_sign mechanism. 779 Meaning of the message: 781 This message contains a signature that proves possession of the 782 private key corresponding to the public key in the client's 783 Certificate message. 785 Structure of this message: 787 The TLS CertificateVerify message is extended as follows. 789 enum { ecdsa } SignatureAlgorithm; 791 select (SignatureAlgorithm) { 792 case ecdsa: 793 digitally-signed struct { 794 opaque sha_hash[sha_size]; 795 }; 796 } Signature; 798 For the ecdsa case, the signature field in the CertificateVerify 799 message contains an ECDSA signature computed over handshake messages 800 exchanged so far. ECDSA signatures are computed as described in 801 Section 4.8. As per ANSI X9.62, an ECDSA signature consists of a 802 pair of integers r and s. These integers are both converted into 803 byte strings of the same length as the curve order n using the 804 conversion routine specified in Section 4.3.1 of [7]. The two byte 805 strings are concatenated, and the result is placed in the signature 806 field. 808 Actions of the sender: 810 The client computes its signature over all handshake messages sent or 811 received starting at client hello up to but not including this 812 message. It uses the private key corresponding to its certified 813 public key to compute the signature which is conveyed in the format 814 defined above. 816 Actions of the receiver: 818 The server extracts the client's signature from the CertificateVerify 819 message, and verifies the signature using the public key it received 820 in the client's Certificate message. 822 4.7 Elliptic Curve Certificates 824 X509 certificates containing ECC public keys or signed using ECDSA 825 MUST comply with [14]. Clients SHOULD use the elliptic curve domain 826 parameters recommended in ANSI X9.62 [7], FIPS 186-2 [9], and SEC 2 827 [12]. 829 4.8 ECDH, ECDSA and RSA Computations 831 All ECDH calculations (including parameter and key generation as well 832 as the shared secret calculation) MUST be performed according to [6] 833 using 835 o the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation 836 primitive, the KDF1 key derivation function using SHA-1 [8], and 837 null key derivation parameters "P" for elliptic curve parameters 838 where field elements are represented as octet strings of length 24 839 or less (using the IEEE 1363 FE2OSP); in this case, the premaster 840 secret is the output of the ECKAS-DH1 scheme, i.e. the 20-byte 841 SHA-1 output from the KDF. 843 o the ECKAS-DH1 scheme with the identity map as key derivation 844 function for elliptic curve parameters where field elements are 845 represented as octet strings of length more than 24; in this case, 846 the premaster secret is the x-coordinate of the ECDH shared secret 847 elliptic curve point, i.e. the octet string Z in IEEE 1363 848 terminology. 850 Note that a new extension may be introduced in the future to allow 851 the use of a different KDF during computation of the premaster 852 secret. In this event, the new KDF would be used in place of the 853 process detailed above. This may be desirable, for example, to 854 support compatibility with the planned NIST key agreement standard. 856 All ECDSA computations MUST be performed according to ANSI X9.62 [7] 857 or its successors. Data to be signed/verified is hashed and the 858 result run directly through the ECDSA algorithm with no additional 859 hashing. The default hash function is SHA-1 [8] and sha_size (see 860 Section 4.2 and Section 4.6) is 20. However, an alternative hash 861 function, such as one of the new SHA hash functions specified in FIPS 862 180-2 [8], may be used instead if the certificate containing the EC 863 public key explicitly requires use of another hash function. 865 All RSA signatures must be generated and verified according to PKCS#1 866 [10]. 868 5. Cipher Suites 870 The table below defines new ECC cipher suites that use the key 871 exchange algorithms specified in Section 2. 873 EDITOR: Most of the cipher suites below have been left as ??. The 874 values 47-4C correspond to cipher suites which are known to have been 875 implemented and are therefore proposed here. The final determination 876 of cipher suite numbers will occur when this draft progresses to RFC. 877 Implementers using the values 47-4C should therefore be wary that 878 these values may change. 880 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 } 881 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 } 882 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 } 883 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A } 884 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B } 885 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C } 887 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 888 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 889 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 890 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 891 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 893 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 894 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 895 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 896 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 897 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 899 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 900 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 901 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 902 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 903 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 905 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } 906 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } 907 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 908 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 909 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 911 Table 5: TLS ECC cipher suites 913 The key exchange method, cipher, and hash algorithm for each of these 914 cipher suites are easily determined by examining the name. Ciphers 915 other than AES ciphers, and hash algorithms are defined in [3]. AES 916 ciphers are defined in [11]. 918 Server implementations SHOULD support all of the following cipher 919 suites, and client implementations SHOULD support at least one of 920 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 921 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 922 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 923 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 925 6. Security Considerations 927 This document is based on [3], [6], [7] and [11]. The appropriate 928 security considerations of those documents apply. 930 For ECDH (Section 4.8), this document specifies two different ways to 931 compute the premaster secret. The choice of the method is determined 932 by the elliptic curve. Earlier versions of this specification used 933 the KDF1 key derivation function with SHA-1 in all cases; the current 934 version keeps this key derivation function only for curves where 935 field elements are represented as octet strings of length 24 or less 936 (i.e. up to 192 bits), but omits it for larger curves. 938 Rationale: Using KDF1 with SHA-1 limits the security to at most 160 939 bits, independently of the elliptic curve used for ECDH. For large 940 curves, this would result in worse security than expected. Using a 941 specific key derivation function for ECDH is not really necessary as 942 TLS always uses its PRF to derive the master secret from the 943 premaster secret. For large curves, the current specification 944 handles ECDH like the basic TLS specification [11] handles standard 945 DH. For smaller curves where the extra KDF1 step does not weaken 946 security, the current specification keeps the KDF1 step to obtain 947 compatibility with existing implementations of earlier versions of 948 this specification. Note that the threshold for switching between 949 the two ECDH calculation methods is necessarily somewhat arbitrary; 950 192-bit ECC corresponds to approximately 96 bits of security in the 951 light of square root attacks, so the 160 bits provided by SHA-1 are 952 comfortable at this limit. 954 7. Intellectual Property Rights 956 The IETF has been notified of intellectual property rights claimed in 957 regard to the specification contained in this document. For more 958 information, consult the online list of claimed rights (http:// 959 www.ietf.org/ipr.html). 961 The IETF takes no position regarding the validity or scope of any 962 intellectual property or other rights that might be claimed to 963 pertain to the implementation or use of the technology described in 964 this document or the extent to which any license under such rights 965 might or might not be available; neither does it represent that it 966 has made any effort to identify any such rights. Information on the 967 IETF's procedures with respect to rights in standards-track and 968 standards-related documentation can be found in [13]. Copies of 969 claims of rights made available for publication and any assurances of 970 licenses to be made available, or the result of an attempt made to 971 obtain a general license or permission for the use of such 972 proprietary rights by implementers or users of this specification can 973 be obtained from the IETF Secretariat. 975 8. Acknowledgments 977 The authors wish to thank Bill Anderson and Tim Dierks. 979 References 981 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 982 Levels", RFC 2119, March 1997. 984 [2] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 985 Sizes", Journal of Cryptology 14 (2001) 255-293, . 988 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 989 2246, January 1999. 991 [4] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol 992 Version 3.0", November 1996, . 995 [5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, . 998 [6] IEEE, "Standard Specifications for Public Key Cryptography", 999 IEEE 1363, 2000. 1001 [7] ANSI, "Public Key Cryptography For The Financial Services 1002 Industry: The Elliptic Curve Digital Signature Algorithm 1003 (ECDSA)", ANSI X9.62, 1998. 1005 [8] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 1007 [9] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 1009 [10] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1010 1.5", PKCS 1, November 1993. 1012 [11] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1013 Transport Layer Security (TLS)", RFC 3268, June 2002. 1015 [12] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 1016 2000, . 1018 [13] Hovey, R. and S. Bradner, "The Organizations Involved in the 1019 IETF Standards Process", RFC 2028, BCP 11, October 1996. 1021 [14] Polk, T., Housley, R. and L. Bassham, "Algorithms and 1022 Identifiers for the Internet X.509 Public Key Infrastructure 1023 Certificate and Certificate Revocation List (CRL) Profile", RFC 1024 3279, April 2002. 1026 Authors' Addresses 1028 Vipul Gupta 1029 Sun Microsystems Laboratories 1030 2600 Casey Avenue 1031 MS UMTV29-235 1032 Mountain View, CA 94303 1033 USA 1035 Phone: +1 650 336 1681 1036 EMail: vipul.gupta@sun.com 1038 Simon Blake-Wilson 1039 Basic Commerce & Industries, Inc. 1040 96 Spandia Ave 1041 Unit 606 1042 Toronto, ON M6G 2T6 1043 Canada 1045 Phone: +1 416 214 5961 1046 EMail: sblakewilson@bcisse.com 1048 Bodo Moeller 1049 Technische Universitaet Darmstadt 1050 Alexanderstr. 10 1051 64283 Darmstadt 1052 Germany 1054 Phone: +49 6151 16 6628 1055 EMail: moeller@cdc.informatik.tu-darmstadt.de 1057 Chris Hawk 1058 Independent Consultant 1060 EMail: chris@socialeng.com 1062 Full Copyright Statement 1064 Copyright (C) The Internet Society (2003). All Rights Reserved. 1066 This document and translations of it may be copied and furnished to 1067 others, and derivative works that comment on or otherwise explain it 1068 or assist in its implementation may be prepared, copied, published 1069 and distributed, in whole or in part, without restriction of any 1070 kind, provided that the above copyright notice and this paragraph are 1071 included on all such copies and derivative works. However, this 1072 document itself may not be modified in any way, such as by removing 1073 the copyright notice or references to the Internet Society or other 1074 Internet organizations, except as needed for the purpose of 1075 developing Internet standards in which case the procedures for 1076 copyrights defined in the Internet Standards process must be 1077 followed, or as required to translate it into languages other than 1078 English. 1080 The limited permissions granted above are perpetual and will not be 1081 revoked by the Internet Society or its successors or assigns. 1083 This document and the information contained herein is provided on an 1084 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1085 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1086 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1087 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1088 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1090 Acknowledgement 1092 Funding for the RFC Editor function is currently provided by the 1093 Internet Society.