idnits 2.17.00 (12 Aug 2021) /tmp/idnits16138/draft-ietf-tls-ecc-02.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 (August 29, 2002) is 7204 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 == Missing Reference: '20' is mentioned on line 786, but not defined == Unused Reference: '13' is defined on line 999, 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: February 27, 2003 S. Blake-Wilson 5 BCI 6 B. Moeller 7 Technische Universitaet Darmstadt 8 C. Hawk 9 Independent Consultant 10 August 29, 2002 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 February 27, 2003. 38 Copyright Notice 40 Copyright (C) The Internet Society (2002). 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 . . . . . . . . . . . . . . . . . . . . . . . . 24 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 81 7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 27 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 83 References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 85 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31 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][8] . 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[20]; 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. 600 Actions of the sender: 602 The server selects elliptic curve domain parameters and an ephemeral 603 ECDH public key corresponding to these parameters according to the 604 ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to 605 the client in the ServerKeyExchange message using the format defined 606 above. 608 Actions of the recipient: 610 The client verifies the signature (when present) and retrieves the 611 server's elliptic curve domain parameters and ephemeral ECDH public 612 key from the ServerKeyExchange message. 614 4.3 Certificate Request 616 When this message is sent: 618 This message is sent when requesting client authentication. 620 Meaning of this message: 622 The server uses this message to suggest acceptable client 623 authentication methods. 625 Structure of this message: 627 The TLS CertificateRequest message is extended as follows. 629 enum { 630 ecdsa_sign(5), rsa_fixed_ecdh(6), 631 ecdsa_fixed_ecdh(7), (255) 632 } ClientCertificateType; 634 ecdsa_sign, etc Indicates that the server would like to use the 635 corresponding client authentication method specified in Section 3. 637 NOTE: SSL 3.0 [4] assigns values 5 and 6 differently 638 (rsa_ephemeral_dh and dss_ephemeral_dh); these 639 ClientCertificateType values are not used by TLS. 641 Actions of the sender: 643 The server decides which client authentication methods it would like 644 to use, and conveys this information to the client using the format 645 defined above. 647 Actions of the receiver: 649 The client determines whether it has an appropriate certificate for 650 use with any of the requested methods, and decides whether or not to 651 proceed with client authentication. 653 4.4 Client Certificate 655 When this message is sent: 657 This message is sent in response to a CertificateRequest when a 658 client has a suitable certificate. 660 Meaning of this message: 662 This message is used to authentically convey the client's static 663 public key to the server. The following table summarizes what client 664 certificate types are appropriate for the ECC-based client 665 authentication mechanisms described in Section 3. ECC public keys 666 must be encoded in certificates as described in Section 4.7. 668 NOTE: The client's Certificate message is capable of carrying a chain 669 of certificates. The restrictions mentioned in Table 4 apply only to 670 the client's certificate (first in the chain). 672 Client 673 Authentication Method Client Certificate Type 674 --------------------- ----------------------- 676 ECDSA_sign Certificate must contain an 677 ECDSA-capable public key and 678 be signed with ECDSA. 680 ECDSA_fixed_ECDH Certificate must contain an 681 ECDH-capable public key on the 682 same elliptic curve as the server's 683 long-term ECDH key. This certificate 684 must be signed with ECDSA. 686 RSA_fixed_ECDH Certificate must contain an 687 ECDH-capable public key on the 688 same elliptic curve as the server's 689 long-term ECDH key. This certificate 690 must be signed with RSA. 692 Table 4: Client certificate types 694 Structure of this message: 696 Identical to the TLS client Certificate format. 698 Actions of the sender: 700 The client constructs an appropriate certificate chain, and conveys 701 it to the server in the Certificate message. 703 Actions of the receiver: 705 The TLS server validates the certificate chain, extracts the client's 706 public key, and checks that the key type is appropriate for the 707 client authentication method. 709 4.5 Client Key Exchange 711 When this message is sent: 713 This message is sent in all key exchange algorithms. If client 714 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 715 message is empty. Otherwise, it contains the client's ephemeral ECDH 716 public key. 718 Meaning of the message: 720 This message is used to convey ephemeral data relating to the key 721 exchange belonging to the client (such as its ephemeral ECDH public 722 key). 724 Structure of this message: 726 The TLS ClientKeyExchange message is extended as follows. 728 enum { yes, no } EphemeralPublicKey; 730 yes, no: Indicates whether or not the client is providing an 731 ephemeral ECDH public key. (In ECC ciphersuites, this is "yes" 732 except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH 733 client authentication mechanism.) 735 struct { 736 select (EphemeralPublicKey) { 737 case yes: ECPoint ecdh_Yc; 738 case no: struct { }; 739 } ecdh_public; 740 } ClientECDiffieHellmanPublic; 742 ecdh_Yc: Contains the client's ephemeral ECDH public key. 744 struct { 745 select (KeyExchangeAlgorithm) { 746 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 747 } exchange_keys; 748 } ClientKeyExchange; 750 Actions of the sender: 752 The client selects an ephemeral ECDH public key corresponding to the 753 parameters it received from the server according to the ECKAS-DH1 754 scheme from IEEE 1363 [6]. It conveys this information to the client 755 in the ClientKeyExchange message using the format defined above. 757 Actions of the recipient: 759 The server retrieves the client's ephemeral ECDH public key from the 760 ClientKeyExchange message and checks that it is on the same elliptic 761 curve as the server's ECDH key. 763 4.6 Certificate Verify 765 When this message is sent: 767 This message is sent when the client sends a client certificate 768 containing a public key usable for digital signatures, e.g. when the 769 client is authenticated using the ECDSA_sign mechanism. 771 Meaning of the message: 773 This message contains a signature that proves possession of the 774 private key corresponding to the public key in the client's 775 Certificate message. 777 Structure of this message: 779 The TLS CertificateVerify message is extended as follows. 781 enum { ecdsa } SignatureAlgorithm; 783 select (SignatureAlgorithm) { 784 case ecdsa: 785 digitally-signed struct { 786 opaque sha_hash[20]; 787 }; 788 } Signature; 790 For the ecdsa case, the signature field in the CertificateVerify 791 message contains an ECDSA signature computed over handshake messages 792 exchanged so far. ECDSA signatures are computed as described in 793 Section 4.8. As per ANSI X9.62, an ECDSA signature consists of a 794 pair of integers r and s. These integers are both converted into 795 byte strings of the same length as the curve order n using the 796 conversion routine specified in Section 4.3.1 of [7]. The two byte 797 strings are concatenated, and the result is placed in the signature 798 field. 800 Actions of the sender: 802 The client computes its signature over all handshake messages sent or 803 received starting at client hello up to but not including this 804 message. It uses the private key corresponding to its certified 805 public key to compute the signature which is conveyed in the format 806 defined above. 808 Actions of the receiver: 810 The server extracts the client's signature from the CertificateVerify 811 message, and verifies the signature using the public key it received 812 in the client's Certificate message. 814 4.7 Elliptic Curve Certificates 816 X509 certificates containing ECC public keys or signed using ECDSA 817 MUST comply with [14]. Clients SHOULD use the elliptic curve domain 818 parameters recommended in ANSI X9.62 [7], FIPS 186-2 [9], and SEC 2 819 [12]. 821 4.8 ECDH, ECDSA and RSA Computations 823 All ECDH calculations (including parameter and key generation as well 824 as the shared secret calculation) MUST be performed according to [6] 825 using the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation 826 primitive, and the KDF1 key derivation function using SHA-1 [9]. The 827 output of this scheme, i.e. the 20-byte SHA-1 output from the KDF, 828 is the premaster secret. 830 DISCUSSION POINT: 832 Using KDF1 with SHA-1 limits the security to at most 160 bits, 833 independently of the elliptic curve used for ECDH. An alternative 834 way to define the protocol would be to employ the identity map as key 835 derivation function (in other words, omit the SHA-1 step and directly 836 use the octet string representation of the x coordinate of the 837 elliptic curve point resulting from the ECDH computation as premaster 838 secret). This is similar to conventional DH in TLS [3], and it is 839 appropriate for TLS given that TLS already defines a PRF for 840 determining the actual symmetric keys. 842 The TLS PRF (which is used to derive the master secret from the 843 premaster secret and the symmetric keys from the master secret) has 844 an internal security limit of at most 288 bits (128 + 160 for MD5 and 845 SHA-1), so the use of KDF1 with SHA-1 can be seen to actually weaken 846 the theoretical security of the protocol. 848 Options to solve this problem include the following: 850 o Omit the SHA-1 step as describe above. (BM) 852 o Continue to use KDF1 with SHA-1 for curves up to, say, 288 bits 853 (more precisely: for curves where FE2OSP returns an octet string 854 up to 36 octets) and omit the SHA-1 step only for larger curves. 855 (SBW/BM) 857 o Continue to use KDF1 with SHA-1 for curves up to, say, 288 bits 858 and use KDF1 with SHA-256 or SHA-384 or SHA-512 for larger curves. 859 (SBW) 861 The first solution will break compatibility with existing 862 implementations based on draft-ietf-tls-ecc-01.txt. The second and 863 third solutions are somewhat of a kludge, but maintain compatibility 864 (in a large range). 866 OPEN QUESTION: We invite comments on which of these solutions would 867 be preferred. 869 END OF DISCUSSION POINT. 871 All ECDSA computations MUST be performed according to ANSI X9.62 [7] 872 using the SHA-1 [9] hash function. The 20 bytes of the SHA-1 are run 873 directly through the ECDSA algorithm with no additional hashing. 875 All RSA signatures must be generated and verified according to PKCS#1 876 [10]. 878 5. Cipher Suites 880 The table below defines new ECC cipher suites that use the key 881 exchange algorithms specified in Section 2. 883 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 } 884 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 } 885 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 } 886 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A } 887 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B } 888 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C } 890 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 891 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 892 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 893 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 894 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 896 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 897 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 898 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 899 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 900 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 902 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 903 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 904 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 905 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 906 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 908 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } 909 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } 910 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 911 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 912 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 914 Table 5: TLS ECC cipher suites 916 The key exchange method, cipher, and hash algorithm for each of these 917 cipher suites are easily determined by examining the name. Ciphers 918 other than AES ciphers, and hash algorithms are defined in [3]. AES 919 ciphers are defined in [11]. 921 Server implementations SHOULD support all of the following cipher 922 suites, and client implementations SHOULD support at least one of 923 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 924 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 925 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 926 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 928 6. Security Considerations 930 This document is entirely concerned with security mechanisms. 932 This document is based on [3], [6], [7] and [11]. The appropriate 933 security considerations of those documents apply. 935 7. Intellectual Property Rights 937 The IETF has been notified of intellectual property rights claimed in 938 regard to the specification contained in this document. For more 939 information, consult the online list of claimed rights (http:// 940 www.ietf.org/ipr.html). 942 The IETF takes no position regarding the validity or scope of any 943 intellectual property or other rights that might be claimed to 944 pertain to the implementation or use of the technology described in 945 this document or the extent to which any license under such rights 946 might or might not be available; neither does it represent that it 947 has made any effort to identify any such rights. Information on the 948 IETF's procedures with respect to rights in standards-track and 949 standards-related documentation can be found in [13]. Copies of 950 claims of rights made available for publication and any assurances of 951 licenses to be made available, or the result of an attempt made to 952 obtain a general license or permission for the use of such 953 proprietary rights by implementers or users of this specification can 954 be obtained from the IETF Secretariat. 956 8. Acknowledgments 958 The authors wish to thank Bill Anderson and Tim Dierks. 960 References 962 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 963 Levels", RFC 2119, March 1997. 965 [2] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 966 Sizes", Journal of Cryptology 14 (2001) 255-293, . 969 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 970 2246, January 1999. 972 [4] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol 973 Version 3.0", November 1996, . 976 [5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, . 979 [6] IEEE, "Standard Specifications for Public Key Cryptography", 980 IEEE 1363, 2000. 982 [7] ANSI, "Public Key Cryptography For The Financial Services 983 Industry: The Elliptic Curve Digital Signature Algorithm 984 (ECDSA)", ANSI X9.62, 1998. 986 [8] NIST, "Digital Signature Standard", FIPS 180-1, 2000. 988 [9] NIST, "Secure Hash Standard", FIPS 186-2, 1995. 990 [10] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 991 1.5", PKCS 1, November 1993. 993 [11] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 994 Transport Layer Security (TLS)", RFC 3268, June 2002. 996 [12] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 997 2000, . 999 [13] Hovey, R. and S. Bradner, "The Organizations Involved in the 1000 IETF Standards Process", RFC 2028, BCP 11, October 1996. 1002 [14] Polk, T., Housley, R. and L. Bassham, "Algorithms and 1003 Identifiers for the Internet X.509 Public Key Infrastructure 1004 Certificate and Certificate Revocation List (CRL) Profile", RFC 1005 3279, April 2002. 1007 Authors' Addresses 1009 Vipul Gupta 1010 Sun Microsystems Laboratories 1011 2600 Casey Avenue 1012 MS UMTV29-235 1013 Mountain View, CA 94303 1014 USA 1016 Phone: +1 650 336 1681 1017 EMail: vipul.gupta@sun.com 1019 Simon Blake-Wilson 1020 Basic Commerce & Industries, Inc. 1021 96 Spandia Ave 1022 Unit 606 1023 Toronto, ON M6G 2T6 1024 Canada 1026 Phone: +1 416 214 5961 1027 EMail: sblakewilson@bcisse.com 1029 Bodo Moeller 1030 Technische Universitaet Darmstadt 1031 Alexanderstr. 10 1032 64283 Darmstadt 1033 Germany 1035 Phone: +49 6151 16 6628 1036 EMail: moeller@cdc.informatik.tu-darmstadt.de 1038 Chris Hawk 1039 Independent Consultant 1041 EMail: chris@socialeng.com 1043 Full Copyright Statement 1045 Copyright (C) The Internet Society (2002). All Rights Reserved. 1047 This document and translations of it may be copied and furnished to 1048 others, and derivative works that comment on or otherwise explain it 1049 or assist in its implementation may be prepared, copied, published 1050 and distributed, in whole or in part, without restriction of any 1051 kind, provided that the above copyright notice and this paragraph are 1052 included on all such copies and derivative works. However, this 1053 document itself may not be modified in any way, such as by removing 1054 the copyright notice or references to the Internet Society or other 1055 Internet organizations, except as needed for the purpose of 1056 developing Internet standards in which case the procedures for 1057 copyrights defined in the Internet Standards process must be 1058 followed, or as required to translate it into languages other than 1059 English. 1061 The limited permissions granted above are perpetual and will not be 1062 revoked by the Internet Society or its successors or assigns. 1064 This document and the information contained herein is provided on an 1065 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1066 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1067 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1068 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1069 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1071 Acknowledgement 1073 Funding for the RFC Editor function is currently provided by the 1074 Internet Society.