idnits 2.17.1 draft-ietf-tls-ecc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == 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 Abstract section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 520 has weird spacing: '... opaque k <1....' == Line 522 has weird spacing: '... opaque k1 <1...' == Line 523 has weird spacing: '... opaque k2 <1...' == Line 524 has weird spacing: '... opaque k3 <1...' == Line 557 has weird spacing: '...ameters cur...' == (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 (March 13, 1998) is 9542 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: 'ChangeCipherSpec' is mentioned on line 211, but not defined -- Looks like a reference, but probably isn't: '20' on line 583 == Unused Reference: 'ECDH' is defined on line 790, but no explicit reference was found in the text == Unused Reference: 'ECDSA' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'ECES' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'ECMQV' is defined on line 798, but no explicit reference was found in the text == Unused Reference: 'ECNRA' is defined on line 800, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ECDH' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECDSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECES' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECMQV' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECNRA' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX-ECDSA' Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security Working Group T. Dierks 3 INTERNET-DRAFT Consensus Development Corp. 4 Expires September, 1998 B. Anderson 5 Certicom Corp. 6 March 13, 1998 8 ECC Cipher Suites For TLS 9 draft-ietf-tls-ecc-00.txt 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or made obsolete by other documents at 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as work in progress. 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 2. Introduction 31 This document describes additions to TLS to support the Elliptic 32 Curve Cryptosystem (ECC). The document assumes that the reader is 33 familiar with the TLS protocol. 35 The document defines cipher suites which use the Elliptic Curve 36 Encryption Scheme (ECES), the Elliptic Curve Digital Signature 37 Algorithm (ECDSA), the Elliptic Curve Nyberg-Rueppel Signature Scheme 38 with Appendix (ECNRA), the Elliptic Curve Diffie-Hellman Key 39 Agreement (ECDH), and the Elliptic Curve Menezes-Qu-Vanstone Key 40 Agreement (ECMQV) key establishment algorithms. References to these 41 algorithms can be found in section 13. 43 3. Table of Contents 45 1. Status of this Memo ........................................ 1 46 2. Introduction ............................................... 1 47 3. Table of Contents .......................................... 2 48 4. Rationale .................................................. 2 49 5. Elliptic Curve Key Establishment Methods ................... 3 50 6. Key Establishment Operation ................................ 5 51 6.1. ECES_ECDSA ................................................. 6 52 6.2. ECES_ECNRA ................................................. 6 53 6.3. ECDHE_ECDSA ................................................ 6 54 6.4. ECDHE_ECDSA_EXPORT ......................................... 7 55 6.5. ECDHE_ECNRA ................................................ 7 56 6.6. ECDHE_ECNRA_EXPORT ......................................... 7 57 6.7. ECDH_ECDSA ................................................. 7 58 6.8. ECDH_ECNRA ................................................. 8 59 6.9. ECMQV_ECDSA ................................................ 8 60 6.10. ECMQV_ECNRA ................................................ 9 61 6.11. ECDH_anon .................................................. 9 62 6.12. ECDH_anon_EXPORT ........................................... 9 63 7. Client Certification ....................................... 9 64 8. Data Structures ........................................... 10 65 8.1. Server Key Exchange ....................................... 10 66 8.2. Certificate Request ....................................... 13 67 8.3. Client Key Exchange ....................................... 14 68 8.4. Certificate Verify ........................................ 15 69 9. Elliptic Curve Certificates ............................... 15 70 10. Cipher Suites ............................................. 16 71 11. Elliptic Curve Cryptography Definitions ................... 17 72 12. Recommended Cipher Suites ................................. 17 73 13. References ................................................ 17 74 14. Security Considerations ................................... 18 75 15. Authors' Addresses ........................................ 18 77 4. Rationale 79 Several design goals drove our choice of key establishment 80 algorithms: 82 1. A desire to replicate all of the functionality and operating 83 modes found in the current TLS cipher suites based on integer 84 factorization and discret log cryptographic algorithms. 86 2. While we wished to define cipher suites which use export-strength 87 cryptography, we did not want to define any cipher suites which 88 would require certificates with export-strength keys; thus, 89 exportable cipher suites are only defined for those key 90 establishment mechanisms which use the certificate key for 91 authentication rather than for key establishment. 93 These criteria for key establishment algorithms, when combined with a 94 number of symmetric algorithms, led to a large number of possible 95 cipher suites. This is problematic in that it could lead to a lack of 96 interoperability due to implementors supporting different subsets of 97 the available cipher suites. In order to alleviate this, we have 98 indicated two of the total cipher suites as recommended (see section 99 12). Unless there are specific reasons to choose other cipher 100 suites, implementors should implement the recommended suites first. 102 5. Elliptic Curve Key Establishment Methods 104 Key establishment is the terminology used in ISO standards to refer 105 to the methods of establishing a shared key between two or more 106 parties. Within key establishment there are two classifications: 107 The operation is called key transport when only one party contributes 108 to the generation of the shared key. The operation is called key 109 agreement when 2 or more parties contribute to the generation of the 110 shared key. For the purposes of this definition, the key in question 111 is the premaster secret: TLS uses the master secret generation 112 process to ensure that both parties contribute to the eventual master 113 secret. 115 The cipher suites defined here use the following key establishment 116 methods: 118 ECES_ECDSA Elliptic-curve encryption is used for the key 119 transport; the server's certificate is signed 120 using ECDSA. 122 ECES_ECNRA Elliptic-curve encryption is used for the key 123 transport; the server's certificate is signed 124 using ECNRA. 126 ECDHE_ECDSA Ephemeral elliptic-curve Diffie-Hellman is used 127 for the key agreement; the server signs the 128 parameters with an ECDSA key and is 129 authenticated with a certificate signed with 130 ECDSA. 132 ECDHE_ECDSA_EXPORT Ephemeral elliptic-curve Diffie-Hellman in 133 export strength is used for the key agreement; 134 the server signs the parameters with an ECDSA 135 key and is authenticated with a certificate 136 signed with ECDSA. 138 ECDHE_ECNRA Ephemeral elliptic-curve Diffie-Hellman is used 139 for the key agreement; the server signs the 140 parameters with an ECNRA key and is 141 authenticated with a certificate signed with 142 ECNRA. 144 ECDHE_ECNRA_EXPORT Ephemeral elliptic-curve Diffie-Hellman in 145 export strength is used for the key agreement; 146 the server signs the parameters with an ECNRA 147 key and is authenticated with a certificate 148 signed with ECNRA. 150 ECDH_ECDSA Fixed elliptic-curve Diffie-Hellman is used for 151 the key agreement; the server's certificate is 152 signed with ECDSA. 154 ECDH_ECNRA Fixed elliptic-curve Diffie-Hellman is used for 155 the key agreement; the server's certificate is 156 signed with ECNRA. 158 ECMQV_ECDSA Ephemeral elliptic-curve MQV is used for key 159 agreement and authentication; the server is 160 authenticated with a certificate signed with 161 ECDSA. 163 ECMQV_ECNRA Ephemeral elliptic-curve MQV is used for key 164 agreement and authentication; the server is 165 authenticated with a certificate signed with 166 ECNRA. 168 ECDH_anon Anonymous elliptic-curve Diffie-Hellman is used 169 for the key agreement. 171 ECDH_anon_EXPORT Anonymous elliptic-curve Diffie-Hellman in 172 export strength is used for the key agreement. 174 Key establishment mechanisms which indicate that they are for export 175 strength should use an ECC key for the key agreement of no more than 176 113 bits. A 113-bit ECC key provides security that is roughly 177 equivalent to a 512-bit RSA key and is expected to be eligible for 178 export. The following table relates ECC key sizes to RSA key sizes 179 of equivalent security. These key sizes are considered equivalent in 180 terms of work factor required to recover the private key using 181 currently known fastest methods for solving the underlying 182 mathematical problems of ECC and RSA. 184 ECC RSA Time to break (MIPS-years) 185 ________ _________ __________________________ 186 106 bits 512 bits 1E4 MY 187 132 bits 768 bits 1E8 MY 188 160 bits 1024 bits 1E11 MY 189 191 bits 1536 bits 1E14 MY 190 211 bits 2048 bits 1E20 MY 192 Table 1: ECC and RSA key sizes for equivalent security 194 6. Key Establishment Operation 196 The TLS key establishment protocol involves this message exchange: 198 Client Server 199 __________________ ___________________ 200 ClientHello --------> 201 ServerHello 202 Certificate* 203 ServerKeyExchange* 204 CertificateRequest* 205 <-------- ServerHelloDone 206 Certificate* 207 ClientKeyExchange 208 CertificateVerify* 209 [ChangeCipherSpec] 210 Finished --------> 211 [ChangeCipherSpec] 212 <-------- Finished 213 Application Data <-------> Application Data 215 Figure 1: Message flow in a full TLS handshake 216 * - Message is not sent under some conditions 218 Of these messages, the ones involved in the key establishment itself 219 are the server's Certificate message, the ServerKeyExchange, the 220 client's Certificate message, and the ClientKeyExchange. 222 In order to specify the ECC cipher suites, we must specify the 223 following elements for each key establishment algorithm: 225 - The format of the server's certificate. 227 - The format of the server key exchange message 229 - For methods in which the client's certificate can participate in 230 the key agreement, the format of the client's certificate and the 231 criteria for deciding if this certificate is eligible to 232 participate in the key agreement. 234 - The format of the client key exchange message 236 - How to arrive at the premaster secret given all the preceding 237 information. 239 Several different key establishment modes are available. In order to 240 allow full negotiation of supported algorithms, the signature 241 algorithm used for the server's X.509 certificate is encoded into the 242 cipher suite for those key establishment mechanisms where no 243 signature algorithm is used; for those key establishments which 244 utilize signature algorithms, the certificate signature algorithm is 245 expected to be the same as the algorithm used in the key 246 establishment. 248 6.1. ECES_ECDSA 250 In ECES_ECDSA, the server sends a certificate with an ECES-capable 251 public key in it. The server's certificate should be signed with 252 ECDSA. A ServerKeyExchange message is not sent because the server's 253 certificate contains all the necessary keying information for the 254 client to complete the key establishment. 256 The client's certificate is not involved in the key establishment for 257 this method, although the client can still be authenticated via the 258 normal mechanism. 260 The client generates a 48 byte premaster secret, encrypts it using 261 ECES using the public key from the server's certificate, and sends it 262 to the server in the ClientKeyExchange message (see section 8.3). 264 This premaster secret is decrypted by the server and both sides use 265 it to generate the master secret for this TLS session. 267 6.2. ECES_ECNRA 269 ECES_ECNRA is the same as ECES_ECDSA except for the fact that the 270 server's certificate is signed by its CA with ECNRA. 272 6.3. ECDHE_ECDSA 274 In ECDHE_ECDSA, the server's certificate has an ECDSA key and is, in 275 turn, signed by its CA with ECDSA. The ServerKeyExchange message 276 contains an ephemeral ECDH key and a specification of the curve for 277 this key. (see section 8.1). These parameters are signed with the 278 server's authenticated ECDSA key. 280 The client's certificate is not involved in the key establishment for 281 this method, although the client can still be authenticated via the 282 normal mechanism. 284 The client should verify the signature on the ServerKeyExchange 285 message and generate an ECDH key on the same curve as the server's 286 ephemeral key. The client encodes the public half of that key into 287 the ClientKeyExchange message and sends it to the server. 289 The client and server perform an ECDH key agreement using their 290 private keys and the public keys they have sent to each other. The 291 resultant shared secret is the premaster secret. 293 6.4. ECDHE_ECDSA_EXPORT 295 ECDHE_ECDSA_EXPORT is the same as ECDHE_ECDSA except for the fact 296 that the curve used for the server's ephemeral ECDH key should be no 297 longer than 113 bits. Because the server's certified key is only 298 used for authentication, its length is unrestricted. 300 6.5. ECDHE_ECNRA 302 ECDHE_ECNRA is the same as ECDHE_ECDSA except for the fact that the 303 server's public key is an ECNRA key and the server's certificate is 304 signed by its CA with ECNRA. 306 6.6. ECDHE_ECNRA_EXPORT 308 ECDHE_ECNRA_EXPORT is the same as ECDHE_ECNRA except for the fact 309 that the curve used for the server's ephemeral ECDH key should be no 310 longer than 113 bits. Because the server's certified key is only 311 used for authentication, its length is unrestricted. 313 6.7. ECDH_ECDSA 315 In ECDH_ECDSA, the server's certificate contains an ECDH public key. 316 This certificate is signed by the server's CA using ECDSA. The 317 ServerKeyExchange message is not sent because the server's 318 certificate contains all the necessary keying information for the 319 client to complete the key establishment. 321 If the server requests client authentication and includes the 322 ecdsa_fixed_dh or ecnra_fixed_dh client certificate types (see 323 section 8.2) and the client has a certificate which contains an ECDH 324 key on the same curve as the server's public key, and this 325 certificate is otherwise eligible to be used for client 326 authentication, then the client's certified public key is used in 327 conjunction with the server's public key to do an ECDH key agreement; 328 the resultant shared secret is the premaster key. In this situation, 329 the client key exchange message is empty when sent and the client 330 CertificateVerify message is not sent, as both the client and the 331 server are authenticated by their ability to arrive at the same 332 premaster secret. 334 If client certification is not requested or if the client does not 335 have a certificate with a suitable ECDH public key, the client can 336 generate an ephemeral key on the same curve as the server's public 337 key. This key is encoded into the ClientKeyExchange message (see 338 section 8.3) and used in conjunction with the server's key to 339 complete the ECDH key agreement, yielding the premaster secret. 341 6.8. ECDH_ECNRA 343 ECDH_ECNRA is the same as ECDH_ECDSA except for the fact that the 344 server's certificate is signed by its CA with ECNRA. 346 6.9. ECMQV_ECDSA 348 In ECMQV_ECDSA, the server's certificate contains an ECMQV key and is 349 signed by the server's CA with ECDSA. The server then generates an 350 temporary key pair and sends the public half of the temporary key in 351 the ServerKeyExchange message (see section 8.1). 353 If the server requests client authentication and includes the 354 ecdsa_mqv or ecnra_mqv client certificate types (see section 8.2) and 355 the client has a certificate which contains an ECMQV key on the same 356 curve as the server's public key, and this certificate is otherwise 357 eligible to be used for client authentication, then the client should 358 send that certificate, then generate a temporary key and send the 359 public half of that key in the ClientKeyExchange message (see section 360 8.3). The client and server then perform an MQV key agreement using 361 their private keys and their peer's public keys (for each party, both 362 the certified and temporary key pairs are used). The resultant 363 shared secret is the premaster secret. The client CertificateVerify 364 message is not sent, as both the client and the server are 365 authenticated by their ability to arrive at the same premaster 366 secret. 368 If client certification is not requested or if the client does not 369 have a certificate with a suitable ECMQV public key, the client 370 should generate two temporary key pairs on the same curve as the 371 server's public key. The public halves of these temporary key pairs 372 are encoded into the ClientKeyExchange message. One key pair is the 373 usual temporary key used for MQV and the other takes the place of the 374 certified key. Each side performs an MQV key agreement using the 375 peer's public keys and its own private keys, yielding the premaster 376 secret. 378 6.10. ECMQV_ECNRA 380 ECMQV_ECNRA is the same as ECMQV_ECDSA except for the fact that the 381 server's certificate is signed by its CA with ECNRA. 383 6.11. ECDH_anon 385 In ECDH_anon, an anonymous Elliptic-Curve Diffie-Hellman operation is 386 used to arrive at the premaster secret. In this case, the server is 387 not authenticated and may not request that the client authenticate 388 itself. The server's Certificate message is not sent. The 389 ServerKeyExchange message contains the specification of a curve and a 390 Diffie-Hellman public key (see section 8.1). The client responds 391 with a ClientKeyExchange message containing a Diffie-Hellman public 392 key on the same curve; the premaster secret is the shared secret 393 resulting from an Elliptic Curve Diffie-Hellman key agreement with 394 these keys. 396 6.12. ECDH_anon_EXPORT 398 ECDH_anon_EXPORT is the same as ECDH_anon except for the fact that 399 the curve used for the server's ephemeral ECDH key should be no 400 longer than 113 bits. 402 7. Client Certification 404 Six new client certificate types have been added: ecdsa_sign, 405 ecnra_sign, ecdsa_fixed_dh, ecnra_fixed_dh, ecdsa_mqv, and ecnra_mqv. 406 As noted above, the fixed_dh and mqv types are used in key 407 establishment methods which allow the client's certified key to 408 participate in key agreement. In these cases, the CertificateVerify 409 message is not sent; the client's ability to arrive at the same 410 premaster secret as the server demonstrates its control over the 411 private half of the certified public key. 413 One of these certificates is eligible for use in the key agreement 414 operation if it has a key which can be used with that algorithm. 415 Because elliptic curve keys have the same mathematical properties for 416 all the algorithms discussed in this specification, a certificate 417 could have a key which was authorized for use in any of several 418 algorithms or for only a particular algorithm. In addition to the 419 key's eligibility, it must be defined using the same curve parameters 420 as the server's key to be used in a operation with it. Of course, 421 the use of a certificate is always subject to any and all policy 422 constraints placed on it. 424 In these certificates, the ecdsa or ecnra refers to the algorithm 425 which the CA uses to sign the client's certificate. 427 The ecdsa_sign and ecnra_sign certificate types are used in other key 428 establishment methods and in cases where the client can not or 429 chooses not to supply a suitable certificate to participate in one of 430 the above methods. In these cases, the client must send a 431 CertificateVerify message to demonstrate its control of the private 432 half key of the certified key pair. (See section 8.4). 434 Certificates requested with the ecdsa_sign ClientCertificateType must 435 include an ECDSA public key and be signed by the CA with ECDSA; 436 ecnra_sign certificates must include an ECNRA key and be signed with 437 ECNRA. 439 With all key establishment methods, it is permissible to request a 440 client certificate using a different algorithm than the one used for 441 the server's certificate; for example, a server doing a ECDHE_ECDSA 442 or ECMQV_ECDSA key establishment could still request an ECNRA client 443 certificate. 445 8. Data Structures 447 Here the descriptions of the data structures exchanged are given. 448 The presentation language is the same as that used in the TLS 449 specification. Because these specifications extend the TLS protocol 450 specification, these descriptions should be merged with those in TLS 451 and in any other specifications which extend TLS. This means that 452 enum types may not specify all the possible values and structures 453 with multiple formats chosen with a select() clause may not indicate 454 all the possible cases. 456 8.1. Server Key Exchange 458 This messages is sent in the following key establishment methods: 460 ECDHE_ECDSA 461 ECDHE_ECDSA_EXPORT 462 ECDHE_ECNRA 463 ECDHE_ECNRA_EXPORT 464 ECMQV_ECDSA 465 ECMQV_ECNRA 466 ECDH_anon 467 ECDH_anon_EXPORT 469 It can contain elliptic curve Diffie-Hellman keys, either signed or 470 unsigned, or MQV parameters. 472 Structure of this message: 474 enum { ec_eces, 475 ec_diffie_hellman, 476 ec_menezes_qu_vanstone } KeyExchangeAlgorithm; 478 enum { ec_prime_p (1), 479 ec_characteristic_two (2), (255) } ECFieldID; 481 enum { ec_basis_onb, ec_basis_trinomial, 482 ec_basis_pentanomial } ECBasisType; 484 struct { 485 opaque a <1..2^8-1>; 486 opaque b <1..2^8-1>; 487 opaque seed <0..2^8-1>; 488 } ECCurve; 490 a, b: These parameters specify the coefficients of the elliptic 491 curve. Each value shall be the octet string representation of a 492 field element following the conversion routine in [X9.62], section 493 4.3.1. 495 seed: This is an optional parameter used to derive the coefficients 496 of a randomly generated elliptic curve. 498 struct { 499 opaque point <1..2^8-1>; 500 } ECPoint; 502 point: This is the octet string representation of an elliptic curve 503 point following the conversion routine in [X9.62], section 4.4.2.a. 504 The representation format is defined following the definition in 505 [X9.62], section 4.4. 507 struct { 508 ECFieldID field; 509 select (field) { 510 case ec_prime_p: 511 opaque prime_p <1..2^8-1>; 512 case ec_characteristic_two: 514 uint16 m; 515 ECBasisType basis; 516 select (basis) { 517 case ec_basis_onb: 518 struct { }; 519 case ec_trinomial: 520 opaque k <1..2^8-1>; 521 case ec_pentanomial: 522 opaque k1 <1..2^8-1>; 523 opaque k2 <1..2^8-1>; 524 opaque k3 <1..2^8-1>; 525 }; 526 }; 527 ECCurve curve; 528 ECPoint base; 529 opaque order <1..2^8-1>; 530 opaque cofactor <1..2^8-1>; 531 } ECParameters; 533 field: This identifies the finite field over which the elliptic curve 534 is defined. 536 prime_p: This is the odd prime defining the field Fp. 538 m: This is the degree of the characteristic-two field F2^m. 540 k: The exponent k for the trinomical basis representation x^m + x^k + 541 1. 543 k1, k2, k3: The exponents for the pentanomial representation x^m + 544 x^k3 + x^k2 + x^k1 + 1. 546 curve: Specifies the coefficients a and b of the elliptic curve E. 548 base: The base point P on the elliptic curve. 550 order: The order n of the base point. The order of a point P is the 551 smallest possible integer n such that nP = 0 (the point at infinity). 553 cofactor: The integer h = #E(Fq)/n, where #E(Fq) represents the 554 number of points on the elliptic curve E defined over the field Fq. 556 struct { 557 ECParameters curve_params; 558 ECPoint public; 559 } ServerECDHParams; 561 curve_params: This specifies the curve on which the elliptic-curve 562 Diffie-Hellman key agreement is to occur. 564 public: The ephemeral public key for the elliptic-curve Diffie- 565 Hellman key agreement. 567 struct { 568 ECPoint temp_public; 569 } ServerMQVParams; 571 temp_public: The temporary MQV public key; the curve on which the MQV 572 operation will take place is specified by the server's certificate. 574 enum { ec_dsa, ec_nra } SignatureAlgorithm; 576 select (SignatureAlgorithm) { 577 case ec_dsa: 578 digitally-signed struct { 579 opaque sha_hash[20]; 580 }; 581 case ec_nra: 582 digitally-signed struct { 583 opaque sha_hash[20]; 584 }; 585 } Signature; 587 select (KeyExchangeAlgorithm) { 588 case ec_diffie_hellman: 589 ServerECDHParams params; 590 Signature signed_params; 591 case ec_menezes_qu_vanstone: 592 ServerMQVParams params; 593 } ServerKeyExchange; 595 Note: The anonymous case for Signature is used for ECDH_anon and 596 ECDH_anon_EXPORT key establishment methods: in this case, the 597 Signature element is empty. 599 8.2. Certificate Request 601 The only addition to this message is six new types for the client 602 certificate. 604 Structure of this message: 606 enum { 607 ecdsa_sign(5), ecnra_sign(6), 608 ecdsa_fixed_dh(7), ecnra_fixed_dh(8), 609 ecdsa_mqv (9), ecnra_mqv (10), (255) 610 } ClientCertificateType; 612 8.3. Client Key Exchange 614 This message is sent in all key exchanges. It can contain either an 615 ECES encrypted secret, an ECDH public key (for use in ECDHE or 616 ECDH_anon key establishment methods), an ECMQV temporary public key, 617 or two temporary keys for use with MQV when the client does not have 618 a suitable certificate. 620 Structure of this message: 622 struct { 623 select (PublicValueEncoding) { 624 case implicit: struct { }; 625 case explicit: ECPoint ecdh_Yc; 626 } ecdh_public; 627 } ClientECDiffieHellmanPublic; 629 If the client has sent a certificate with an ECDH key, the 630 PublicValueEncoding will be implicit and this message will be empty. 631 Otherwise, ecdh_Yc will be the client's public value for the Diffie- 632 Hellman key agreement. 634 struct { 635 select (PublicValueEncoding) { 636 case implicit: struct { }; 637 case explicit: ECPoint ecmqv; 638 } ecmqv_public; 639 ECPoint ecmqv_temp; 640 } ClientECMQVPublic; 642 If the client has sent a certificate with an MQV key, the 643 PublicValueEncoding will be implicit and the ecmqv_public field will 644 be empty; otherwise, ecmqv will contain the client's MQV public 645 value. In either case, ecmqv_temp will contain the temporary public 646 key for the MQV operation. 648 In the explicit case, the cost of an additional key generation can be 649 saved by generating only one ephemeral key and sending two copies: 650 one in ecmqv and one in ecmqv_temp. 652 struct { 653 select (KeyExchangeAlgorithm) { 654 case ec_eces: EncryptedPreMasterSecret; 655 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 656 case ec_menezes_qu_vanstone: ClientECMQVPublic; 657 } exchange_keys; 658 } ClientKeyExchange; 660 In the ECES case, the premaster secret will be sent encrypted with 661 the server's public key. The standard TLS definition of 662 EncryptedPreMasterSecret is suitable for this transmission. 664 8.4. Certificate Verify 666 This message is sent when the client has sent a certificate which did 667 not participate in a Diffie-Hellman or Menezes-Qu-Vanstone key 668 agreement. 670 This type needs no new definition: the CertificateVerify message in 671 TLS uses the Signature type, which we have extended for ECDSA and 672 ECNRA (see section 8.1). 674 9. Elliptic Curve Certificates 676 All X.509 certificates must be in compliance with the PKIX profile of 677 the X.509 standard [PKIX]. Elliptic curve keys should be encoded 678 into X.509 certificates as specified in [PKIX-ECDSA]. However, this 679 document currently only specifies formats for ECDSA keys and 680 signatures. 682 When this document refers to a certificate with an ECDSA, ECNRA, 683 ECES, ECDH, or ECMQV key, it means a public key which is capable of 684 performing a particular algorithm and which is permitted by the 685 policy encoded in the certificate to participate in this algorithm. 686 This may be a key which is specifically indicated as being useful for 687 a particular algorithm or a general-purpose elliptic curve key which 688 is allowed to perform a particular operation. 690 The X.509 key usage extension encodes functions a key is allowed to 691 perform. The relevant key usage bits for algorithms are: 693 Algorithm Key Usage Bit 694 _________ ________________ 695 ECDSA digitalSignature 696 ECNRA digitalSignature 697 ECES keyEncipherment 698 ECDH keyAgreement 699 ECMQV keyAgreement 701 Table 2: Pertinent X.509 key usage bits 703 A TLS entity shall not present a certificate which is not eligible to 704 participate in the negotiated cipher suite and shall refuse to 705 communicate with a TLS peer which presents such a certificate. 707 10. Cipher Suites 709 The following cipher suites are defined: 711 CipherSuite TLS_ECES_ECDSA_NULL_SHA = { 0x00, 0x2C } 712 CipherSuite TLS_ECES_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x2D } 713 CipherSuite TLS_ECES_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x2E } 714 CipherSuite TLS_ECES_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x2F } 715 CipherSuite TLS_ECES_ECNRA_NULL_SHA = { 0x00, 0x30 } 716 CipherSuite TLS_ECES_ECNRA_WITH_RC4_128_SHA = { 0x00, 0x31 } 717 CipherSuite TLS_ECES_ECNRA_WITH_DES_CBC_SHA = { 0x00, 0x32 } 718 CipherSuite TLS_ECES_ECNRA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x33 } 719 CipherSuite TLS_ECDHE_ECDSA_NULL_SHA = { 0x00, 0x34 } 720 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x36 } 721 CipherSuite TLS_ECDHE_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x37 } 722 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x38 } 723 CipherSuite TLS_ECDHE_ECDSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x39 } 724 CipherSuite TLS_ECDHE_ECDSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x40 } 725 CipherSuite TLS_ECDHE_ECNRA_NULL_SHA = { 0x00, 0x41 } 726 CipherSuite TLS_ECDHE_ECNRA_WITH_RC4_128_SHA = { 0x00, 0x42 } 727 CipherSuite TLS_ECDHE_ECNRA_WITH_DES_CBC_SHA = { 0x00, 0x43 } 728 CipherSuite TLS_ECDHE_ECNRA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x44 } 729 CipherSuite TLS_ECDHE_ECNRA_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x45 } 730 CipherSuite TLS_ECDHE_ECNRA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x46 } 731 CipherSuite TLS_ECDH_ECDSA_NULL_SHA = { 0x00, 0x47 } 732 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 } 733 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 } 734 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A } 735 CipherSuite TLS_ECDH_ECNRA_NULL_SHA = { 0x00, 0x4B } 736 CipherSuite TLS_ECDH_ECNRA_WITH_RC4_128_SHA = { 0x00, 0x4C } 737 CipherSuite TLS_ECDH_ECNRA_WITH_DES_CBC_SHA = { 0x00, 0x4D } 738 CipherSuite TLS_ECDH_ECNRA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4E } 739 CipherSuite TLS_ECMQV_ECDSA_NULL_SHA = { 0x00, 0x4F } 740 CipherSuite TLS_ECMQV_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x50 } 741 CipherSuite TLS_ECMQV_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x51 } 742 CipherSuite TLS_ECMQV_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x52 } 743 CipherSuite TLS_ECMQV_ECNRA_NULL_SHA = { 0x00, 0x53 } 744 CipherSuite TLS_ECMQV_ECNRA_WITH_RC4_128_SHA = { 0x00, 0x54 } 745 CipherSuite TLS_ECMQV_ECNRA_WITH_DES_CBC_SHA = { 0x00, 0x55 } 746 CipherSuite TLS_ECMQV_ECNRA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x56 } 747 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x57 } 748 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x58 } 749 CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA = { 0x00, 0x59 } 750 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x5A } 751 CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x5B } 752 CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x5C } 754 Table 3: TLS ECC cipher suites 756 The key establishment method, cipher, and hash algorithm for each 757 cipher suite are easily determined by examining the name. Those 758 cipher suites which use the "NULL" cipher or one of the "EXPORT" key 759 establishment mechanisms are considered to be "exportable" cipher 760 suites for the purposes of the TLS protocol. 762 11. Elliptic Curve Cryptography Definitions 764 These definitions provide a quick reference for the elliptic curve 765 terms. 767 Elliptic curve Definition to come. 769 Elliptic curve point Definition to come. 771 EC parameters Definition to come. 773 EC private key Definition to come. 775 EC public key Definition to come. 777 EC key pair Definition to come. 779 12. Recommended Cipher Suites 781 In order to promote common interoperability, two cipher suites are 782 recommended for initial implementation: 783 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA and 784 TLS_ECDHE_ECDSA_EXPORT_WITH_RC4_40_SHA. Implementing these two gives 785 a basis of cryptographic strength, perfect forward secrecy, and 786 well-accepted algorithms. 788 13. References 790 [ECDH] IEEE P1363 Working Draft, February, 1997. 792 [ECDSA] IEEE P1363 Working Draft, February, 1997. 794 [ECDSA] ANSI X9.62 Working Draft, November 17, 1997. 796 [ECES] ANSI X9.63 Working Draft. 798 [ECMQV] IEEE P1363 Working Draft, February, 1997. 800 [ECNRA] IEEE P1363 Working Draft, February, 1997. 802 [PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key 803 Infrastructure: Part I: X.509 Certificate and CRL Profile, , October 1997. 806 [PKIX-ECDSA] L. Bassham, D. Johnson, W. Polk, Representation of 807 Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and 808 Signatures in Internet X.509 Public Key Infrastructure Certificates 809 , November 1997. 811 [X9.62] ANSI X9.62 Working Draft, November 17, 1997. 813 14. Security Considerations 815 This document is entirely concerned with security mechanisms. 816 Implementors should take care to ensure that code which controls 817 security mechanisms is free of errors which might be exploited by 818 attackers. 820 15. Authors' Addresses 822 Authors: 824 Tim Dierks 825 Consensus Development 826 timd@consensus.com 828 Bill Anderson 829 Certicom 830 banderson@certicom.com 832 Contributors: 834 Gilles Garon 835 ggaron@aol.com