idnits 2.17.00 (12 Aug 2021) /tmp/idnits8554/draft-ietf-tls-ecc-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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. ** There are 27 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([MUST]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 568 has weird spacing: '...rveType cur...' == Line 581 has weird spacing: '... opaque k <1....' == Line 583 has weird spacing: '... opaque k1 <1...' == Line 584 has weird spacing: '... opaque k2 <1...' == Line 585 has weird spacing: '... opaque k3 <1...' == (4 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 (15 March 2001) is 7736 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) == Missing Reference: 'LEN' is mentioned on line 95, but not defined == Missing Reference: 'ANSIX962' is mentioned on line 847, but not defined == Missing Reference: 'FIPS180-1' is mentioned on line 866, but not defined -- Looks like a reference, but probably isn't: '20' on line 831 == Unused Reference: 'FIPS180' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'PKIX-CERT' is defined on line 983, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1363' == Outdated reference: draft-ietf-pkix-ipki-pkalgs has been published as RFC 3279 == Outdated reference: draft-ietf-pkix-new-part1 has been published as RFC 3280 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) == Outdated reference: draft-ietf-tls-ciphersuite has been published as RFC 3268 -- Possible downref: Normative reference to a draft: ref. 'TLS-EXT' Summary: 9 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Simon Blake-Wilson 3 INTERNET-DRAFT Tim Dierks 4 Expires: September 14, 2001 Chris Hawk 5 Certicom Corp. 6 15 March 2001 8 ECC Cipher Suites for TLS 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts may be found at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories may be found at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes additions to TLS to support Elliptic Curve 33 Cryptography (ECC). In particular it defines new key exchange 34 algorithms which use the Elliptic Curve Digital Signature Algorithm 35 (ECDSA) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme 36 (ECDH), and it defines how to perform client authentication with ECDSA 37 and ECDH. 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [MUST]. 43 Please send comments on this document to the TLS mailing list. 45 Table of Contents 47 1. Introduction ................................................. 2 48 2. Elliptic Curve Key Exchange Algorithms ....................... 4 49 2.1. ECDH_ECDSA ................................................... 5 50 2.2. ECDH_ECDSA_EXPORT ............................................ 5 51 2.3. ECDH_RSA ..................................................... 6 52 2.4. ECDH_RSA_EXPORT .............................................. 6 53 2.5. ECDH_anon .................................................... 6 54 2.6. ECDH_anon_EXPORT ............................................. 6 55 3. ECC Client Authentication .................................... 7 56 3.1. ECDSA_sign ................................................... 7 57 3.2. ECDSA_fixed_ECDH ............................................. 8 58 3.3. RSA_fixed_ECDH ............................................... 9 59 4. Data Structures and Computations ............................. 9 60 4.1. Server Certificate .......................................... 10 61 4.2. Server Key Exchange ......................................... 11 62 4.3. Certificate Request ......................................... 15 63 4.4. Client Certificate .......................................... 15 64 4.5. Client Key Exchange ......................................... 16 65 4.6. Certificate Verify .......................................... 18 66 4.7. Computing the Master Secret ................................. 19 67 5. Cipher Suites ............................................... 19 68 6. Security Considerations ..................................... 20 69 7. Intellectual Property Rights ................................ 20 70 8. Acknowledgments ............................................. 21 71 9. References .................................................. 21 72 10. Authors' Addresses .......................................... 22 74 1. Introduction 76 This document describes additions to TLS to support Elliptic Curve 77 Cryptography (ECC). In particular, it defines: 79 - new key exchange algorithms which use the Elliptic Curve Digital 80 Signature Algorithm (ECDSA), and the Elliptic Curve Diffie-Hellman 81 Key Agreement Scheme (ECDH); and 83 - new client authentication methods which use ECDSA and ECDH. 85 In order to enable the use of these features within TLS, the document 86 defines enhanced data structures to convey the information that the 87 mechanisms need to exchange, the computational procedures involved in 88 the operation of the mechanisms, and new cipher suites based on the 89 mechanisms. 91 Use of ECC within TLS may provide both bandwidth and computational 92 savings compared to other public-key cryptographic techniques. 93 Furthermore, the efficiencies provided by ECC may increase as security 94 requirements increase based on Moore's law - this is illustrated by the 95 following table, based on [LEN], which gives approximate comparable key 96 sizes for symmetric systems, ECC systems, and DH/DSA/RSA systems based 97 on the running times of the best algorithms known today. 99 Symmetric | ECC | DH/DSA/RSA 100 80 | 163 | 1024 101 128 | 283 | 3072 102 192 | 409 | 7680 103 256 | 571 | 15360 105 Table 1: Comparable key sizes (in bits) 107 The savings that ECC may offer are likely to become increasingly 108 desirable with the widespread use of TLS by wireless devices - 109 discussed, for example, in [TLS-EXT]. 111 This document assumes the reader is familiar with both ECC and TLS. ECC 112 is described in ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], IEEE 113 1363 [IEEE1363], and SEC 1 [SEC1]. TLS is described in RFC 2246 [TLS]. 115 The choice of mechanisms included in this document was motivated by a 116 desire to provide mechanisms which are secure, which are as efficient 117 as possible, and which are capable of replicating all of the 118 functionality and operating modes found in the existing TLS mechanisms 119 based on integer factorization and discrete logarithm cryptographic 120 systems. TLS includes a substantial variety of functionality and 121 operating modes in consideration of the variety of applications with 122 which TLS is used. 124 The desire described above led to the inclusion of a substantial number 125 of ECC-based mechanisms. In order to encourage interoperability, a 126 small subset of the mechanisms are identified as "recommended" - these 127 mechanisms are capable of meeting the requirements of many 128 applications and they should therefore be used unless an application 129 profile of this document states otherwise, or unless in a particular 130 environment considerations such as export regulations mandate 131 otherwise. 133 The remainder of this document is organized as follows. Section 2 134 specifies key exchange algorithms for TLS using ECC. Section 3 135 specifies how client authentication is performed using ECC. Section 4 136 describes the TLS-specific data structures and computations involved in 137 the operation of the ECC mechanisms. Section 5 defines cipher suites 138 based on the ECC key exchange algorithms. Sections 6-8 discuss security 139 considerations, intellectual property rights, and acknowledgements 140 respectively. Section 9 supplies references cited elsewhere in the 141 document, and Section 10 gives the authors' contact details. 143 2. Elliptic Curve Key Exchange Algorithms 145 This document defines six new key exchange algorithms based on ECC for 146 use within TLS. 148 The table below summarizes the new key exchange algorithms. 150 Key 151 Exchange 152 Algorithm Description Key size limit 154 ECDH_ECDSA ECDH with ECDSA signatures None 155 ECDH_ECDSA_EXPORT ECDH with ECDSA signatures ECDH=163 bits, 156 ECDSA=none 157 ECDH_RSA ECDH with RSA signatures None 158 ECDH_RSA_EXPORT ECDH with RSA signatures ECDH=163 bits, 159 RSA = none 160 ECDH_anon Anonymous ECDH, no signatures None 161 ECDH_anon_EXPORT Anonymous ECDH, no signatures ECDH=163 bits 163 Table 2: Key exchange algorithms 165 Note that the key exchange algorithms marked "anon" do not provide 166 authentication of the server or the client, and, like other "anon" TLS 167 key exchange algorithms, may be subject to man-in-the-middle attacks. 168 Implementations of these algorithms SHOULD provide authentication by 169 other means. 171 The remainder of this section describes these key exchange algorithms 172 in detail. For each key exchange algorithm, this involves specification 173 of the contents of the handshake messages related to key exchange - 174 server certificate, server key exchange, client certificate, and client 175 key exchange - as well as specification of the computations involved in 176 the calculation of the master secret. 178 2.1. ECDH_ECDSA 180 ECDH is used to compute the master secret. The server is authenticated 181 via a certificate containing an ECDH public key signed with ECDSA. 183 Specifically this key exchange algorithm MUST proceed as follows: 185 - The server provides a static ECDH public key in the server 186 certificate message using the format described in Section 4.1. The 187 certificate is signed using ECDSA. 189 - The server key exchange message is not sent. 191 - Unless client authentication using ECDH is performed as specified in 192 Sections 3.2 and 3.3, the client provides an ephemeral ECDH public 193 key in the client key exchange message using the format described in 194 Section 4.5. In this case, the client certificate and certificate 195 verify message are not sent unless client authentication is performed 196 using ECDSA as specified in Section 3.1, or another signature 197 algorithm. 199 - If client authentication using ECDH is performed, the client provides 200 a static ECDH public key in the client certificate message using the 201 format described in Section 4.4. In this case an empty client key 202 exchange message is sent using the format described in Section 4.5, and 203 the certificate verify message is not sent. 205 - The client and server compute the master secret using their ECDH key 206 pairs as specified in Section 4.7. 208 ECDH computations for this key exchange algorithm are performed 209 according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the 210 ECSVDP-DH secret value derivation primitive, and the KDF1 key 211 derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are 212 performed according to ANSI X9.62 [ANSIX962] using the hash function 213 SHA-1 [FIPS180-1]. 215 2.2. ECDH_ECDSA_EXPORT 217 Export-strength ECDH is used to compute the master secret. The server 218 is authenticated via a certificate containing an ECDH public key signed 219 with ECDSA. 221 This key exchange algorithm MUST proceed in the same way as ECDH_ECDSA, 222 except that the key size for ECDH public keys is constrained to 163 223 bits or less. Here the key size of an elliptic curve public key refers 224 to the size of the underlying finite field over which the elliptic 225 curve is defined. 227 2.3. ECDH_RSA 229 ECDH is used to compute the master secret. The server is authenticated 230 via a certificate containing an ECDH public key signed with RSA. 232 This key exchange MUST proceed in the same way as ECDH_ECDSA, except 233 that the server's certificate is signed with RSA. 235 2.4. ECDH_RSA_EXPORT 237 Export-strength ECDH is used to compute the master secret. The server 238 is authenticated via a certificate containing an ECDH public key signed 239 with RSA. 241 This key exchange algorithm MUST proceed in the same way as ECDH_RSA, 242 except that the key size for ECDH public keys is constrained to be 163 243 bits or less. 245 2.5. ECDH_anon 247 Anonymous ECDH is used to compute the master secret. 249 Specifically this key exchange algorithm MUST proceed as follows: 251 - The server certificate message is not sent. 253 - The server provides an ephemeral ECDH public key in the server key 254 exchange message using the format described in Section 4.2. 256 - The client certificate message is not sent. 258 - The client provides an ephemeral ECDH public key in the client key 259 exchange message using the format described in Section 4.5. 261 - The client and server compute the master secret using their ECDH 262 key pairs as specified in Section 4.7. 264 ECDH computations for this key exchange algorithm are performed 265 according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the 266 ECSVDP-DH secret value derivation primitive, and the KDF1 key 267 derivation primitive using SHA-1 [FIPS180-1]. 269 2.6. ECDH_anon_EXPORT 271 Export-strength, anonymous ECDH is used to compute the master secret. 272 This key exchange algorithm MUST proceed in the same way as ECDH_anon, 273 except that the key size for ECDH public keys is constrained to 163 274 bits or less. 276 3. ECC Client Authentication 278 This document defines three new ECC-based client authentication methods 279 - ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH. 281 To encourage interoperability, implementations SHOULD support 282 ECDSA_fixed_ECDH. Implementations MAY support any of the other client 283 authentication methods. 285 The remainder of this section specifies these ECC-based client 286 authentication methods. The following information is provided for each 287 method: which key exchange algorithms the method may be used with, what 288 constraints apply to the method, and the formats of the certificate 289 request, client certificate, client key exchange, and certificate 290 verify messages. 292 3.1. ECDSA_sign 294 The client supplies a certificate containing an ECDSA public key, and 295 authenticates itself by signing the certificate verify message with its 296 ECDSA key pair. 298 This client authentication method MUST proceed as follows. 300 Applicable key exchange algorithms: 302 - This client authentication method is eligible for use with all the 303 non-anonymous ECC-based key exchange algorithms specified in Section 304 2, and all the existing non-anonymous TLS key exchange algorithms 305 specified in [TLS]. 307 Restrictions: 309 - In order to perform this method, the client must possess a certified 310 ECDSA public key. 312 Message exchange: 314 - The server requests use of the ECDSA_sign method by sending a 315 certificate request message containing the value "ecdsa_sign" using 316 the format described in Section 4.3. When the client receives this 317 request, it checks that it possesses an appropriate certificate and 318 that it is willing to proceed. 320 - If the client proceeds, it sends its certificate containing its ECDSA 321 public key in the client certificate message using the format 322 described in Section 4.4. It signs the handshake messages exchanged 323 so far with its ECDSA key pair and conveys the resulting signature to 324 the server in the certificate verify message using the format 325 specified in Section 4.6. 327 - (If the client does not proceed, it may perform client authentication 328 using another method suggested by the server in the certificate 329 request message in which case the client certificate and the 330 certificate verify message are sent in accordance with the selected 331 method, or it may proceed with the key exchange without client 332 authentication - in which case the client certificate and certificate 333 verify messages are not sent.) 335 ECDSA computations for this client authentication method are performed 336 according to ANSI X9.62 [ANSIX962] using the hash function SHA-1 337 [FIPS180-1]. 339 3.2. ECDSA_fixed_ECDH 341 The client supplies an ECDSA-signed certificate containing an ECDH 342 public key using the same elliptic curve domain parameters as the 343 server's ECDH public key. The client authenticates itself by computing 344 the master secret and the finished message. (This achieves 345 authentication because these computations can only be performed by a 346 party possessing the private key corresponding to one of the ECDH 347 public keys exchanged.) 349 This client authentication method MUST proceed as follows. 351 Applicable key exchange algorithms: 353 - This method is eligible for use with all the non-anonymous ECC-based 354 key exchange algorithms specified in Section 2. 356 Restrictions: 358 - In order to perform this client authentication method, the client 359 must possess an ECDSA-signed certificate containing an ECDH public 360 key using the same elliptic curve domain parameters as the ECDH 361 public key supplied by the server in the server certificate message. 363 Message exchange: 365 - The server requests use of the ECDSA_fixed_ECDH method by sending a 366 certificate request message containing the value "ecdsa_fixed_ecdh" 367 using the format described in Section 4.3. When the client receives 368 this request, it checks that it possesses an appropriate certificate 369 and that it is willing to proceed. 371 - If the client proceeds, it sends its certificate containing its ECDH 372 public key in the client certificate message using the format 373 described in Section 4.4. It sends an empty client key exchange 374 message using the format described in Section 4.5. It does not send 375 the certificate verify message. It uses its static ECDH key pair, 376 along with the server's ECDH public key) when computing the master 377 secret and finished message. 379 - (If the client does not proceed, it may perform client authentication 380 using another method suggested by the server in the certificate 381 request message, or it may proceed with the key exchange without 382 client authentication - in which case the client certificate and 383 certificate verify messages are not sent.) 385 ECDH computations for this key exchange algorithm are performed 386 according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the 387 ECSVDP-DH secret value derivation primitive, and the KDF1 key 388 derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are 389 performed according to ANSI X9.62 [ANSIX962] using the hash function 390 SHA-1 [FIPS180-1]. 392 3.3. RSA_fixed_ECDH 394 The client supplies an RSA-signed certificate containing an ECDH 395 public key using the same elliptic curve domain parameters as the 396 server's ECDH public key. The client authenticates itself by computing 397 the master secret and the finished message. (This achieves 398 authentication because these computations can only be performed by a 399 party possessing the private key corresponding to one of the ECDH 400 public keys exchanged.) 402 This client authentication method MUST proceed in the same manner as 403 the ECDSA_fixed_ECDH method, except that the client's certificate must 404 be signed with RSA, and the server requests use of the method by 405 sending a certificate request message containing the value 406 "rsa_fixed_ecdh". 408 4. Data Structures and Computations 410 This section specifies the data structures and computations used by the 411 ECC-based mechanisms specified in Sections 2 and 3. The presentation 412 language used here is the same as that used in RFC 2246 [TLS]. Because 413 these specifications extend the TLS protocol specification, these 414 descriptions should be merged with those in TLS and in any other 415 specifications which extend TLS. This means that enum types may not 416 specify all the possible values and structures with multiple formats 417 chosen with a select() clause may not indicate all the possible cases. 419 4.1. Server Certificate 421 This message is sent in the following key exchange algorithms: 423 All the non-anonymous ECC-based key exchange algorithms specified in 424 Section 2. 426 Meaning of this message: 428 This message is used to authentically convey the server's static public 429 key to the client. The appropriate certificate types are given in the 430 following table. 432 Key Exchange Algorithm Certificate Type 434 ECDH_ECDSA ECC public key; the certificate must 435 allow the key to be used for key 436 agreement. The certificate must be 437 signed with ECDSA. 439 ECDH_ECDSA_EXPORT ECC public key which can be used for key 440 agreement; key size must be 163 bits or 441 less. Certificate must be signed with 442 ECDSA. 444 ECDH_RSA ECC public key which can be used for key 445 agreement. Certificate must be signed 446 with RSA. 448 ECDH_RSA_EXPORT ECC public key which can be used for key 449 agreement; key size must be 163 bits or 450 less. Certificate must be signed with 451 RSA. 453 Table 3: Server certificate types 455 [PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in 456 X.509 certificates. Servers SHOULD use the elliptic curve domain 457 parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2 458 [FIPS186-2], and SEC 2 [SEC2]. Note that - as with RSA - the same 459 identifier is used for all ECC keys in "SubjectPublicKeyInfo". The key 460 usage extension may be used to further delimit the use of the key. When 461 a key usage extension is present, the "keyAgreement" bit MUST be set 462 for ECDH certificates. 464 Structure of this message: 466 Identical to the TLS Certificate format. 468 Actions of the sender: 470 The server constructs an appropriate certificate chain and conveys it 471 to the client in the Certificate message. 473 Actions of the receiver: 475 The client validates the certificate chain, extracts the server's 476 public key, and checks that the key is of the correct type for the key 477 exchange algorithm. 479 4.2. Server Key Exchange 481 This message is sent in the following key exchange algorithms: 483 Both the anonymous ECC-based key exchange algorithms specified in 484 Section 2. 486 Meaning of this message: 488 This message is used to convey the server's ephemeral ECDH public key 489 (and the corresponding elliptic curve domain parameters) to the client. 491 Structure of this message: 493 The TLS ServerKeyExchange message is extended as follows. 495 enum { ec_diffie_hellman } KeyExchangeAlgorithm; 497 ec_diffie_hellman 498 Indicates the ServerKeyExchange message is to contain an ECDH public 499 key. 501 enum { explicit_prime (1), explicit_char2 (2), 502 named_curve (3), (255) } ECCurveType; 504 explicit_prime 505 Indicates the elliptic curve domain parameters will be conveyed 506 verbosely, and that the underlying finite field is a prime field. 508 explicit_char2 509 Indicates the elliptic curve domain parameters will be conveyed 510 verbosely, and that the underlying finite field is a characteristic 2 511 field. 513 named_curve 514 Indicates that a named curve will be used. The use of this option is 515 strongly recommended. 517 struct { 518 opaque a <1..2^8-1>; 519 opaque b <1..2^8-1>; 520 opaque seed <0..2^8-1>; 521 } ECCurve; 523 a, b 524 These parameters specify the coefficients of the elliptic curve. Each 525 value contains the byte string representation of a field element 526 following the conversion routine in [X9.62], section 4.3.3. 528 seed 529 This is an optional parameter used to derive the coefficients of a 530 randomly generated elliptic curve. 532 struct { 533 opaque point <1..2^8-1>; 534 } ECPoint; 536 point 537 This is the byte string representation of an elliptic curve point 538 following the conversion routine in [X9.62], section 4.3.6. 540 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; 542 ec_basis_trinomial 543 Indicates representation of a characteristic two field using a 544 trinomial basis. 546 ec_basis_pentanomial 547 Indicates representation of a characteristic two field using a 548 pentanomial basis. 550 enum { 551 sect163k1 (1), sect163r1 (2), sect163r2 (3), 552 sect193r1 (4), sect193r2 (5), sect233k1 (6), 553 sect233r1 (7), sect239k1 (8), sect283k1 (9), 554 sect283r1 (10), sect409k1 (11), sect409r1 (12), 555 sect571k1 (13), sect571r1 (14), secp160k1 (15), 556 secp160r1 (16), secp160r2 (17), secp192k1 (18), 557 secp192r1 (19), secp224k1 (20), secp224r1 (21), 558 secp256k1 (22), secp256r1 (23), secp384r1 (24), 559 secp521r1 (25), (255) 560 } NamedCurve; 562 sect163k1, etc 563 Indicates use of the corresponding recommended curve specified in SEC 2 564 [SEC2]. Note that many of these curves are also recommended in ANSI 565 X9.62 [ANSIX962], and FIPS 186-2 [FIPS186-2]. 567 struct { 568 ECCurveType curve_type; 569 select (curve_type) { 570 case explicit_prime: 571 opaque prime_p <1..2^8-1>; 572 ECCurve curve; 573 ECPoint base; 574 opaque order <1..2^8-1>; 575 opaque cofactor <1..2^8-1>; 576 case explicit_char2: 577 uint16 m; 578 ECBasisType basis; 579 select (basis) { 580 case ec_trinomial: 581 opaque k <1..2^8-1>; 582 case ec_pentanomial: 583 opaque k1 <1..2^8-1>; 584 opaque k2 <1..2^8-1>; 585 opaque k3 <1..2^8-1>; 586 }; 587 ECCurve curve; 588 ECPoint base; 589 opaque order <1..2^8-1>; 590 opaque cofactor <1..2^8-1>; 591 case named_curve: 592 NamedCurve namedcurve; 593 }; 594 } ECParameters; 596 curve_type 597 This identifies the type of the elliptic curve domain parameters. 599 prime_p 600 This is the odd prime defining the field Fp. 602 curve 603 Specifies the coefficients a and b of the elliptic curve E. 605 base 606 Specifies the base point G on the elliptic curve. 608 order 609 Specifies the order n of the base point. 611 cofactor 612 Specifies the cofactor h = #E(Fq)/n, where #E(Fq) represents the number 613 of points on the elliptic curve E defined over the field Fq. 615 m 616 This is the degree of the characteristic-two field F2^m. 618 k 619 The exponent k for the trinomial basis representation x^m+x^k+1. 621 k1, k2, k3 622 The exponents for the pentanomial representation x^m+x^k3+x^k2+x^k1+1. 624 namedcurve 625 Specifies a recommended set of elliptic curve domain parameters. 627 struct { 628 ECParameters curve_params; 629 ECPoint public; 630 } ServerECDHParams; 632 curve_params 633 Specifies the elliptic curve domain parameters associated with the 634 ECDH public key. 636 public 637 The ephemeral ECDH public key. 639 select (KeyExchangeAlgorithm) { 640 case ec_diffie_hellman: 641 ServerECDHParams params; 642 Signature signed_params; 643 } ServerKeyExchange; 645 params 646 Specifies the ECDH public key and associated domain parameters. 648 signed_params 649 This element is empty for all the key exchange algorithms specified in 650 this document. 652 Actions of the sender: 654 The server selects elliptic curve domain parameters and an ephemeral 655 ECDH public key corresponding to these parameters according to the 656 ECKAS-DH1 scheme from IEEE 1363 [IEEE1363]. It conveys this information 657 to the client in the ServerKeyExchange message using the format defined 658 above. 660 Actions of the recipient: 662 The client retrieves the server's elliptic curve domain parameters and 663 ephemeral ECDH public key from the ServerKeyExchange message. 665 4.3. Certificate Request 667 This message is sent when requesting the following client 668 authentication methods: 670 Any of the ECC-based client authentication methods specified in 671 Section 3. 673 Meaning of this message: 675 The server uses this message to indicate which client authentication 676 methods the server would like to use. 678 Structure of this message: 680 The TLS CertificateRequest message is extended as follows. 682 enum { 683 ecdsa_sign (5), rsa_fixed_ecdh (6), 684 ecdsa_fixed_ecdh(7), (255) 685 } ClientCertificateType; 687 ecdsa_sign, etc 688 Indicates that the server would like to use the corresponding client 689 authentication method specified in Section 3. 691 Actions of the sender: 693 The server decides which client authentication methods it would like to 694 use, and conveys this information to the client using the format 695 defined above. 697 Actions of the receiver: 699 The client determines whether it has an appropriate certificate for use 700 with any of the requested methods, and decides whether or not to 701 proceed with client authentication. 703 4.4. Client Certificate 705 This message is sent in the following client authentication methods: 707 All the ECC-based client authentication methods specified in Section 3. 709 Meaning of this message: 711 This message is used to authentically convey the client's static public 712 key to the server. The appropriate certificate types are given in the 713 following table. 715 Client Authentication Certificate Type 716 Method 718 ECDSA_sign ECC public key which can be used for 719 signing. 721 ECDSA_fixed_ECDH ECC public key which can be used for key 722 agreement. Certificate must be signed 723 with ECDSA. 725 RSA_fixed_ECDH ECC public key which can be used for key 726 agreement. Certificate must be signed 727 with RSA. 729 Table 4: Client certificate types 731 [PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in 732 X.509 certificates. Clients SHOULD use the elliptic curve domain 733 parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2 734 [FIPS186-2], and SEC 2 [SEC2]. Note that - as with RSA - the same 735 identifier is used for all ECC keys in "SubjectPublicKeyInfo". The key 736 usage extension may be used to further delimit the use of the key. When 737 a key usage extension is present, the "keyAgreement" bit MUST be set 738 for ECDH certificates, and the "digitalSignature" bit MUST be set for 739 ECDSA certificates. 741 Structure of this message: 743 Identical to the TLS Certificate format. 745 Actions of the sender: 747 The client constructs an appropriate certificate chain, and conveys it 748 to the server in the Certificate message. 750 Actions of the receiver: 752 The TLS server validates the certificate chain, extracts the client's 753 public key, and checks that the key is of the correct type for the 754 client authentication method. 756 4.5. Client Key Exchange 758 This message is sent in the following key exchange algorithms: 760 All the ECC-based key exchange algorithms specified in Section 2. If 761 client authentication with fixed ECDH is not being used, the message 762 contains the client's ephemeral ECDH public key, otherwise the message 763 is empty. 765 Meaning of the message: 767 This message is used to convey ephemeral data relating to the key 768 exchange belonging to the client (such as its ephemeral ECDH public 769 key). 771 Structure of this message: 773 The TLS ClientKeyExchange message is extended as follows. 775 enum { yes, no } EphemeralPublicKey; 777 yes, no 778 Indicates whether or not the client is providing an ephemeral ECDH 779 public key. 781 struct { 782 select (EphemeralPublicKey) { 783 case yes: ECPoint ecdh_Yc; 784 case no: struct { }; 785 } ecdh_public; 786 } ClientECDiffieHellmanPublic; 788 ecdh_Yc 789 Contains the client's ephemeral ECDH public key. 791 struct { 792 select (KeyExchangeAlgorithm) { 793 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 794 } exchange_keys; 795 } ClientKeyExchange; 797 Actions of the sender: 799 The client selects an ephemeral ECDH public key corresponding to the 800 parameters it received from the server according to the ECKAS-DH1 801 scheme from IEEE 1363 [IEEE1363]. It conveys this information to the 802 client in the ClientKeyExchange message using the format defined 803 above. 805 Actions of the recipient: 807 The server retrieves the client's ephemeral ECDH public key from the 808 ServerKeyExchange message and checks that the public key represents a 809 point of the elliptic curve. 811 4.6. Certificate Verify 813 This message is sent in the following client authentication methods: 815 ECDSA_sign 817 Meaning of the message: 819 This message contains an ECDSA signature on the handshake messages in 820 order to authenticate the client to the server. 822 Structure of this message: 824 The TLS CertificateVerify message is extended as follows. 826 enum { ec_dsa } SignatureAlgorithm; 828 select (SignatureAlgorithm) { 829 case ec_dsa: 830 digitally-signed struct { 831 opaque sha_hash[20]; 832 }; 833 } Signature; 835 In the CertificateVerify message, the signature field contains the 836 client's ECDSA signature on the handshake messages exchanged so far. 837 According to [ANSIX962], the signature consists of a pair of integers r 838 and s. These integers are both converted into byte strings of the same 839 length as the curve order n using the conversion routine specified in 840 Section 4.3.1 of [ANSIX962], the two byte strings are concatenated, and 841 the result is placed in the signature field. 843 Actions of the sender: 845 The client computes its signature over the handshake messages exchanged 846 so far using its ECDSA key pair with ECDSA computations performed as 847 specified in [ANSIX962] with the hash function SHA-1 [FIPS186-2]. The 848 client conveys its signature to the server in the CertificateVerify 849 message using the format defined above. 851 Actions of the receiver: 853 The server extracts the client's signature from the CertificateVerify 854 message, and verifies the signature using the client's ECDSA public key 855 that it received in the ClientCertificate message. 857 4.7. Computing the Master Secret 859 In all the ECC-based key exchange algorithms specified in Section 2, 860 the client and server compute the master key as follows: 862 - They both compute a single shared secret K of length 20 bytes using 863 their ECDH key pairs with ECDH computations performed as specified by 864 the ECKAS-DH1 scheme in [IEEE1363] with the ECSVDP-DH secret value 865 derivation primitive, and the KDF1 key derivation primitive using 866 SHA-1 [FIPS180-1]. 868 - They both use K as the pre_master_secret, and compute the 869 master_secret from the pre_master_secret as specified in [TLS]. 871 5. Cipher Suites 873 The table below defines the cipher suites specified in this document 874 for use with the key exchange algorithms specified in Section 2. 876 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 } 877 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 } 878 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 } 879 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A } 880 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B } 881 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C } 882 CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x4B } 883 CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_56_SHA = { 0x00, 0x4C } 884 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x4D } 885 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x4E } 886 CipherSuite TLS_ECDH_RSA_WITH_DES_CBC_SHA = { 0x00, 0x4F } 887 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x50 } 888 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x51 } 889 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x52 } 890 CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x53 } 891 CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_56_SHA = { 0x00, 0x54 } 892 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x55 } 893 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x56 } 894 CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA = { 0x00, 0x57 } 895 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x58 } 896 CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x59 } 897 CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x5A } 899 Table 5: TLS ECC cipher suites 901 The key exchange method, cipher, and hash algorithm for each of these 902 cipher suites are easily determined by examining the name. Ciphers 903 other than AES ciphers, and hash algorithms are defined in [TLS]. AES 904 ciphers are defined in [TLS-AES]. 906 The cipher suites which use the "NULL" cipher or one of the "EXPORT" 907 key exchange algorithms are considered to be "exportable" cipher suites 908 for the purposes of the TLS protocol. 910 Use of the following cipher suites is recommended in general - server 911 implementations SHOULD support all of these cipher suites, and client 912 implementations SHOULD support at least one of them: 914 TLS_ECDH_ECDSA_WITH_RC4_128_SHA 915 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA 916 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 918 Implementations MAY support any of the other cipher suites. 920 6. Security Considerations 922 This document is entirely concerned with security mechanisms. 924 This document is based on [TLS], [ANSIX9.62], and [IEEE1363] and the 925 appropriate security considerations of those documents apply. 927 In addition implementers should take care to ensure that code which 928 controls security mechanisms is free of errors which might be exploited 929 by attackers. 931 7. Intellectual Property Rights 933 The IETF has been notified of intellectual property rights claimed in 934 regard to the specification contained in this document. For more 935 information, consult the online list of claimed rights 936 (http://www.ietf.org/ipr.html). 938 The IETF takes no position regarding the validity or scope of any 939 intellectual property or other rights that might be claimed to pertain 940 to the implementation or use of the technology described in this 941 document or the extent to which any license under such rights might or 942 might not be available; neither does it represent that it has made any 943 effort to identify any such rights. Information on the IETF's 944 procedures with respect to rights in standards-track and 945 standards-related documentation can be found in BCP-11. Copies of 946 claims of rights made available for publication and any assurances of 947 licenses to be made available, or the result of an attempt made to 948 obtain a general license or permission for the use of such proprietary 949 rights by implementers or users of this specification can be obtained 950 from the IETF Secretariat. 952 8. Acknowledgments 954 The authors wish to thank Bill Anderson, Paul Fahn, Gilles Garon, John 955 Kennedy, and Brian Minard for their help preparing this document. 957 9. References 959 [ANSIX9.62] ANSI X9.62-1999, "Public Key Cryptography For The Financial 960 Services Industry: The Elliptic Curve Digital Signature 961 Algorithm (ECDSA)", American National Standards Institute, 962 1998. 964 [FIPS180] FIPS 180-1, "Secure Hash Standard", National Institute of 965 Standards and Technology, 1995. 967 [FIPS186-2] FIPS 186-2, "Digital Signature Standard", National Institute 968 of Standards and Technology, 2000. 970 [IEEE1363] IEEE 1363, "Standard Specifications for Public Key 971 Cryptography", Institute of Electrical and Electronics 972 Engineers, 2000. 974 [MUST] S. Bradner, "Key Words for Use in RFCs to Indicate 975 Requirement Levels", RFC 2119, March 1997. 977 [PKIX-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and 978 Identifiers for the Internet X.509 Public Key 979 Infrastructure Certificate and CRL Profile", PKIX Working 980 Group Internet-Draft, draft-ietf-pkix-ipki-pkalgs-02.txt, 981 March 2001. 983 [PKIX-CERT] W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509 984 Public Key Infrastructure Certificate and CRL Profile", PKIX 985 Working Group Internet-Draft, 986 draft-ietf-pkix-new-part1-05.txt, March 2001. 988 [SEC1] SEC 1, "Elliptic Curve Cryptography", Standards for Efficient 989 Cryptography Group, 2000. 991 [SEC2] SEC 2, "Recommended Elliptic Curve Domain Parameters", 992 Standards for Efficient Cryptography Group, 2000. 994 [TLS] T. Dierks and C. Allen, "The TLS Protocol - Version 1.0," 995 IETF RFC 2246, January 1999. 997 [TLS-AES] P. Chown, "AES Ciphersuites for TLS", TLS Working Group 998 Internet-Draft, draft-ietf-tls-ciphersuite-03.txt, 999 January 2001. 1001 [TLS-EXT] S. Blake-Wilson and M. Nystrom, "Wireless Extensions to TLS", 1002 TLS Working Group Internet-Draft, 1003 draft-ietf-tls-wireless-00.txt, November 2000. 1005 10. Authors' Addresses 1007 Authors: 1009 Simon Blake-Wilson 1010 Certicom Corp. 1011 sblake-wilson@certicom.com 1013 Tim Dierks 1014 Certicom Corp. 1015 timd@consensus.com 1017 Chris Hawk 1018 Certicom Corp. 1019 chawk@certicom.com