idnits 2.17.1 draft-green-secsh-ecc-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 823. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (October 1, 2008) is 5685 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '2' on line 198 -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Shell Working Group D. Stebila 3 Internet-Draft University of Waterloo 4 Intended status: Standards Track J. Green 5 Expires: April 4, 2009 October 1, 2008 7 Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer 8 draft-green-secsh-ecc-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 4, 2009. 35 Abstract 37 This document describes algorithms based on Elliptic Curve 38 Cryptography (ECC) for use within the Secure Shell (SSH) transport 39 protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman 40 (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key 41 agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for 42 use in the SSH Transport Layer protocol. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3. ECC Public Key Algorithm . . . . . . . . . . . . . . . . . . . 5 49 3.1. Key Format . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3.1.1. Signature Algorithm . . . . . . . . . . . . . . . . . 5 51 3.1.2. Signature Encoding . . . . . . . . . . . . . . . . . . 5 52 4. ECDH Key Exchange . . . . . . . . . . . . . . . . . . . . . . 7 53 5. ECMQV Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 55 6.1. Elliptic Curve Domain Parameter Identifiers . . . . . . . 13 56 6.2. ECC Public Key Algorithm (ecdsa-sha2) . . . . . . . . . . 13 57 6.2.1. Elliptic Curve Digital Signature Algorithm . . . . . . 13 58 6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) . . . . . . . 14 59 6.4. ECMQV Key Exchange and Verification Method Name 60 (ecmqv-sha2) . . . . . . . . . . . . . . . . . . . . . . . 14 61 7. Key Exchange Messages . . . . . . . . . . . . . . . . . . . . 16 62 7.1. ECDH Message Numbers . . . . . . . . . . . . . . . . . . . 16 63 7.2. ECMQV Message Numbers . . . . . . . . . . . . . . . . . . 16 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 65 9. Named Elliptic Curve Domain Parameters . . . . . . . . . . . . 18 66 9.1. Required and Recommended Curves . . . . . . . . . . . . . 18 67 9.2. SEC Equivalent NIST Curves and Encoded OIDs . . . . . . . 18 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 23 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 73 Intellectual Property and Copyright Statements . . . . . . . . . . 25 75 1. Introduction 77 Due to its inclusion in NSA's Suite B and its small key sizes 78 elliptic curve cryptography (ECC) is becoming a widely utilized and 79 attractive public-key cryptosystem. 81 In the interest of adding Suite B algorithms to SSH this document 82 adds three ECC Suite B algorithms to the Secure Shell arsenal: 83 Elliptic Curve Menezes-Qu-Vanstone (ECMQV), Elliptic Curve Diffie- 84 Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm 85 (ECDSA), as well as utilizing the SHA2 family of secure hash 86 algorithms. 88 Compared to cryptosystems such as RSA, DSA, and DH, ECC variations on 89 these schemes offer equivalent security with smaller key sizes. This 90 is illustrated in the following table, based on Section 5.6.1 of NIST 91 800-57 [NIST-800-57], which gives approximate comparable key sizes 92 for symmetric- and asymmetric-key cryptosystems based on the best 93 known algorithms for attacking them. L is field size and N is sub- 94 field size. 96 +-----------+-----------------------------+-------+---------+ 97 | Symmetric | Discrete Log (eg. DSA, DH) | RSA | ECC | 98 +-----------+-----------------------------+-------+---------+ 99 | 80 | L = 1024 N = 160 | 1024 | 160-223 | 100 | | | | | 101 | 112 | L = 2048 N = 256 | 2048 | 224-255 | 102 | | | | | 103 | 128 | L = 3072 N = 256 | 3072 | 256-383 | 104 | | | | | 105 | 192 | L = 7680 N = 384 | 7680 | 384-511 | 106 | | | | | 107 | 256 | L = 15360 N = 512 | 15360 | 512+ | 108 +-----------+-----------------------------+-------+---------+ 110 Implementation of this specification requires familiarity with both 111 SSH [RFC4251] [RFC4253] [RFC4250] and ECC [SEC1] [IEEE1363] 112 [ANSI-X9.63]. 114 This document is concerned with SSH implementation details; 115 specification of the underlying cryptographic algorithms is left to 116 other standards documents. 118 Comments on this draft are solicited and should be addressed to 119 Douglas Stebila . 121 2. Notation 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 The data types boolean, uint32, uint64, string, and mpint are to be 128 interpreted in this document as described in [RFC4251]. 130 The size of a set of elliptic curve domain parameters on a prime 131 curve is defined as the number of bits in the binary representation 132 of the field order, commonly denoted p. Size on a characteristic-2 133 curve is defined as the number of bits in the binary representation 134 of the field, commonly denoted m. A set of elliptic curve domain 135 parameters defines a group of order n generated by a base point P. 137 3. ECC Public Key Algorithm 139 The ECC public key algorithm is defined by its key format, 140 corresponding signature algorithm ECDSA, signature encoding and 141 algorithm identifiers. 143 This section defines the "ecdsa-sha2" public key format and 144 corresponding signature format. 146 3.1. Key Format 148 The "ecdsa-sha2" key format has the following encoding: 150 string "ecdsa-sha2" 151 byte[n] ecc_key_blob 153 The ecc_key_blob value has the following specific encoding: 155 string [identifier] 156 string Q 158 The string [identifier] is the identifier of the elliptic curve 159 domain parameters. The format of this string is specified in 160 Section 6.1. Information on the required and recommended sets of 161 elliptic curve domain parameters for use with this algorithm can be 162 found in Section 9. 164 Q is the public key encoded from an elliptic curve point into an 165 octet string as defined in Section 2.3.3 of [SEC1]. 167 The algorithm for ECC key generation can be found in Section 3.2 of 168 [SEC1]. Given some elliptic curve domain parameters, an ECC key pair 169 can be generated containing a private key, an integer d, and a public 170 key, an elliptic curve point Q. 172 3.1.1. Signature Algorithm 174 Signing and verifying is done using the Elliptic Curve Digital 175 Signature Algorithm (ECDSA). ECDSA is specified in [SEC1] and in 176 [ANSI-X9.62]. The message hashing algorithm must be from the SHA2 177 family of hash functions [RFC4634] and is chosen according to the 178 curve size as specified in Section 6.2.1. 180 3.1.2. Signature Encoding 182 Signatures are encoded as follows: 184 string "ecdsa-sha2" 185 string ecdsa_signature_blob 187 The ecdsa_signature_blob value has the following specific encoding: 189 mpint r 190 mpint s 192 The integers r and s are the output of the ECDSA algorithm. 194 The width of the integer fields is determined by the curve being 195 used. Note that the integers r and s are integers modulo the order 196 of the curve, which is may be larger than the size of the finite 197 field. Thus, the integers r and s are encoding as octet strings each 198 of length ciel(log[2](n)/8) using Section 2.3.7 of [SEC1], where n is 199 the order of the elliptic curve group. 201 4. ECDH Key Exchange 203 The Elliptic Curve Diffie-Hellman (ECDH) key exchange method 204 generates a shared secret from an ephemeral elliptic curve local 205 private key and remote public key. This key exchange method provides 206 explicit server authentication as defined in [RFC4253] using a 207 signature on the exchange hash. 209 The primitive used for shared key generation is ECDH with cofactor 210 multiplication, the full specification of which can be found in 211 Section 3.3.2 of [SEC1]. The algorithm for key pair generation can 212 be found in Section 3.2 of [SEC1]. 214 The family of key exchange method names defined for use with this key 215 exchange can be found in Section 6.3. Algorithm negotiation chooses 216 the public key algorithm to be used for signing and the method name 217 of the key exchange. The method name of the key exchange chosen 218 determines the elliptic curve domain parameters and hash function to 219 be used in the remainder of this section. 221 Information on the required and recommended elliptic curve domain 222 parameters for use with this method can be found in Section 9. 224 All elliptic curve public keys MUST be validated after they are 225 received. An example of a validation algorithm can be found in 226 A.16.10 of [IEEE1363]. If a key fails validation the key exchange 227 MUST fail. 229 The elliptic curve public keys (points) that must be transmitted are 230 encoded into octet strings before they are transmitted. The 231 transformation between elliptic curve points and octet strings is 232 specified in Section 2.3 of [SEC1]. The output of shared key 233 generation is a field element xp. The ssh framework requires that 234 the shared key be an integer. The conversion between a field element 235 and an integer is specified in Section 2.3.9 of [SEC1]. 237 Specification of the message numbers SSH_MSG_KEX_ECDH_INIT and 238 SSH_MSG_KEX_ECDH_REPLY are found in Section 7. 240 The following is an overview of the key exchange process: 242 Client Server 243 ------ ------ 244 Generate ephemeral key pair. 245 SSH_MSG_KEX_ECDH_INIT --------------> 247 Verify received key is valid. 248 Generate ephemeral key pair. 249 Compute shared secret. 250 Generate and sign exchange hash. 251 <------------- SSH_MSG_KEX_ECDH_REPLY 253 Verify received key is valid. 254 *Verify host key belongs to server. 255 Compute shared secret. 256 Generate exchange hash. 257 Verify server's signature. 259 *It is recommended that the client verify that the host key sent is 260 the server's host key (Using certificates or a local database). The 261 client is allowed to accept the host key without verification, but 262 doing so will render the protocol insecure against active attacks. 264 This is implemented using the following messages. 266 The client sends: 268 byte SSH_MSG_KEX_ECDH_INIT 269 string client's ephemeral public key octet string 271 The server responds with: 273 byte SSH_MSG_KEX_ECDH_REPLY 274 string server's public host key and/or certificates 275 string server's ephemeral public key octet string 276 string the signature on the exchange hash 278 The exchange hash H is computed as the hash of the concatenation of 279 the following. 281 string client's version string (CR and NL excluded) 282 string server's version string (CR and NL excluded) 283 string payload of the client's SSH_MSG_KEXINIT 284 string payload of the server's SSH_MSG_KEXINIT 285 string server's public host key 286 string client's ephemeral public key octet string 287 string server's ephemeral public key octet string 288 mpint shared secret 290 5. ECMQV Key Exchange 292 The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange algorithm 293 generates a shared secret from two local elliptic curve key pairs and 294 two remote public keys. This key exchange method provides implicit 295 server authentication as defined in [RFC4253]. 297 The key exchange method name defined for use with this key exchange 298 is "ecmqv-sha2". This method name gives a hashing algorithm that is 299 to be used for the HMAC below. Future RFCs may define new method 300 names specifying new hash algorithms for use with ECMQV. More 301 information about the method name and HMAC can be found in 302 Section 6.4. 304 In general the ECMQV key exchange is performed using the ephemeral 305 and long term key pair of both the client and server, a total of 4 306 keys. Within the framework of SSH the client does not have a long 307 term key pair that needs to be authenticated. Therefore we generate 308 an ephemeral key and use that as both the clients keys. This is more 309 efficient than using two different ephemeral keys and does not 310 adversely affect security (it is analogous to the one-pass protocol 311 in Section 6.1 of [LMQSV98]). 313 A full description of the ECMQV primitive can be found in Section 3.4 314 of [SEC1]. The algorithm for key pair generation can be found in 315 Section 3.2 of [SEC1]. 317 During algorithm negotiation with the SSH_MSG_KEXINIT messages the 318 ECMQV key exchange method can only be chosen if a Public Key 319 Algorithm supporting ECC host keys can also be chosen. This is due 320 to the use of implicit server authentication in this key exchange 321 method. This case is handled the same way that key exchange methods 322 requiring encryption/signature capable public key algorithms are 323 handled in Section 7.1 of [RFC4253]. If ECMQV key exchange is chosen 324 then the Public Key Algorithm supporting ECC host keys MUST also be 325 chosen. 327 ECMQV requires that all the keys used to generate a shared secret are 328 generated over the same elliptic curve domain parameters. Since the 329 host key is used in the generation of the shared secret, allowing for 330 implicit server authentication, the domain parameters associated with 331 the host key are used throughout this section. 333 All elliptic curve public keys MUST be validated after they are 334 received. An example of a validation algorithm can be found in 335 A.16.10 of [IEEE1363]. If a key fails validation the key exchange 336 MUST fail. 338 The elliptic curve public keys (points) that must be transmitted are 339 encoded into octet strings before they are transmitted. The 340 transformation between elliptic curve points and octet strings is 341 specified in Section 2.3 of [SEC1]. The output of shared key 342 generation is a field element xp. The ssh framework requires that 343 the shared key be an integer. The conversion between a field element 344 and an integer is specified in Section 2.3.9 of [SEC1]. 346 The following is an overview of the key exchange process: 348 Client Server 349 ------ ------ 350 Generate ephemeral key pair. 351 SSH_MSG_KEX_ECMQV_INIT -------------> 353 Verify received key is valid. 354 Generate ephemeral key pair. 355 Compute shared secret. 356 Generate exchange hash and compute 357 HMAC over it using the shared secret. 358 <------------- SSH_MSG_KEX_ECDH_REPLY 360 Verify received keys are valid. 361 *Verify host key belongs to server. 362 Compute shared secret. 363 Verify HMAC. 365 *It is recommended that the client verify that the host key sent is 366 the server's host key (Using certificates or a local database). The 367 client is allowed to accept the host key without verification, but 368 doing so will render the protocol insecure against active attacks. 370 The specification of the message numbers SSH_MSG_ECMQV_INIT and 371 SSH_MSG_ECMQV_REPLY can be found in Section 7. 373 This key exchange algorithm is implemented with the following 374 messages. 376 The client sends: 378 byte SSH_MSG_ECMQV_INIT 379 string client's ephemeral public key octet string 381 The server sends: 383 byte SSH_MSG_ECMQV_REPLY 384 string server's public host key octet string 385 string server's ephemeral public key octet string 386 string HMAC tag computed on H using the shared secret 388 The hash H is formed by applying the algorithm HASH on a 389 concatenation of the following: 391 string client's version string (CR and NL excluded) 392 string server's version string (CR and NL excluded) 393 string payload of the client's SSH_MSG_KEXINIT 394 string payload of the server's SSH_MSG_KEXINIT 395 string client's ephemeral public key octet 396 string server's public host key octet 397 string server's ephemeral public key octet 398 mpint shared secret 400 6. IANA Considerations 402 This document defines a new family of key exchange method names, a 403 new key exchange method name, and a new public key algorithm name in 404 the SSH name registry. These additions to the SSH name space will 405 have to be approved the IANA. 407 6.1. Elliptic Curve Domain Parameter Identifiers 409 This section specifies identifiers encoding named elliptic curve 410 domain parameters. These identifiers are used in this document to 411 identify the curve used in the ECC public key format, the ECDSA 412 signature blob, and the ECDH method name. 414 An elliptic curve domain parameter identifier is the Base64 encoding 415 of the MD5 hash [RFC1321] of the ASN.1 Distinguished Encoding Rules 416 (DER) encoding [ASN1] of the ASN.1 Object Identifier (OID) of the 417 named curve domain parameters that are associated with the server's 418 ECC host keys. Every identifier is precisely 24 characters in 419 length. Base64 encoding is described in Section 6.8 of [RFC2045]. A 420 list of the required and recommended curves, their OIDs, and the 421 encoding of their identifiers can be found in Section 9. 423 For example: the identifier for the sect163k1 elliptic curve domain 424 parameters would be "4MHB+NBt3AlaSRQ7MnB4cg==". 426 6.2. ECC Public Key Algorithm (ecdsa-sha2) 428 The ECC Public Key Algorithm is specified by the public key format 429 identifier "ecdsa-sha2". 431 6.2.1. Elliptic Curve Digital Signature Algorithm 433 The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified 434 for use with the ECC Public Key Algorithm. 436 The hashing algorithm defined by this family of method names is the 437 SHA2 family of hashing algorithms [RFC4634]. The algorithm from the 438 SHA2 family that will be used is chosen based on the size of the 439 named curve specified in the public key: 441 +----------------+----------------+ 442 | Curve Size | Hash Algorithm | 443 +----------------+----------------+ 444 | b <= 256 | SHA-256 | 445 | | | 446 | 256 < b <= 384 | SHA-384 | 447 | | | 448 | 384 < b | SHA-512 | 449 +----------------+----------------+ 451 6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) 453 The Elliptic Curve Diffie-Hellman key exchange is defined by a family 454 of method names. Each method name is the concatenation of the string 455 "ecdh-sha2" with the elliptic curve domain parameter identifier as 456 defined in Section Section 6.1. A list of the required and 457 recommended curves and their OIDs can be found in Section 9. 459 For example: The method name for ECDH key exchange with ephemeral 460 keys generated on the sect409k1 curve would be "ecdh-sha2-m/ 461 FtSAmrV4j/Wy6RVUaK7A==". 463 The hashing algorithm defined by this family of method names is the 464 SHA2 family of hashing algorithms [RFC4634]. The hashing algorithm 465 is defined in the method name to allow room for other algorithms to 466 be defined in future documents. The algorithm from the SHA2 family 467 that will be used is chosen based on the size of the named curve 468 specified in the method name according to the table in Section 469 Section 6.2.1. 471 The concatenation of any so encoded ASN.1 OID specifying a set of 472 elliptic curve domain parameters with "ecdh-sha2-" is implicitly 473 registered under this specification. 475 6.4. ECMQV Key Exchange and Verification Method Name (ecmqv-sha2) 477 The Elliptic Curve Menezes-Qu-Vanstone key exchange is defined by the 478 method name "ecmqv-sha2". Unlike the ECDH key exchange method, ECMQV 479 relies on a public key algorithm that uses ECC keys: it does not need 480 a family of method names because the curve information can be gained 481 from the public key algorithm. 483 The hashing and message authentication code algorithms are defined by 484 the method name to allow room for other algorithms to be defined for 485 use with ECMQV in future documents. 487 The hashing algorithm defined by this method name is the SHA2 family 488 of hashing algorithms [RFC4634]. The algorithm from the SHA2 family 489 that will be used is chosen based on the size of the named curve 490 specified for use with ECMQV by the chosen public key algorithm 491 according to the table in Section Section 6.2.1. 493 The keyed-hash message authentication code that is used to identify 494 the server and verify communications is based on the hash chosen 495 above. The information on implementing the HMAC based on the chosen 496 hash algorithm can be found in [RFC4634]. 498 7. Key Exchange Messages 500 The message numbers 30-49 are key exchange-specific and in a private 501 namespace defined in [RFC4250] that may be redefined by any key 502 exchange method [RFC4253] without being granted IANA permission. 504 The following message numbers have been defined in this document: 506 7.1. ECDH Message Numbers 508 #define SSH_MSG_KEX_ECDH_INIT 30 509 #define SSH_MSG_KEX_ECDH_REPLY 31 511 7.2. ECMQV Message Numbers 513 #define SSH_MSG_ECMQV_INIT 30 514 #define SSH_MSG_ECMQV_REPLY 31 516 8. Security Considerations 518 The Elliptic Curve Diffie-Hellman key agreement algorithm is defined 519 in [SEC1], [IEEE1363] and [ANSI-X9.63]. The appropriate security 520 considerations of those documents apply. 522 The Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm is 523 defined in [SEC1]. The security considerations raised in that 524 document also apply. A more detailed discussion of security 525 considerations can be found in Section 4.7 of the Guide to Elliptic 526 Curve Cryptography [HMV04]. 528 The server's host key is used in the ECMQV key exchange algorithm. 529 This means that the strength of the server's ECC host key determines 530 the strength of the ECMQV key exchange algorithm. This should be 531 taken into consideration when generating ECC keys for a server. 533 The methods defined in Section Section 6 rely on the SHA2 family of 534 hashing functions as defined in [FIPS-180-2]. The appropriate 535 security considerations of that document apply. 537 The hashing algorithms defined for use with ECDH and ECMQV are 538 defined by their method names so that if security problems are found 539 with the SHA2 family of hashing algorithms or more secure hashing 540 algorithms become the standard then future documents can extend this 541 document to include new hashing algorithms by defining new method 542 names. 544 Additionally a good general discussion of the security considerations 545 that must be taken into account when creating an ECC implementation 546 can be found in Section 5 of the Guide to Elliptic Curve Cryptography 547 [HMV04]. 549 Since ECDH and ECMQV allow for elliptic curves of arbitrary sizes and 550 thus arbitrary security strength, it is important that the size of 551 elliptic curve be chosen to match the security strength of other 552 elements of the SSH handshake. In particular, host key sizes, 553 hashing algorithms and bulk encryption algorithms must be chosen 554 appropriately. Information regarding estimated equivalence of key 555 sizes is available in [NIST-800-57]. We note in particular that when 556 ECDSA is used as the signature algorithm and ECDH is used as the key 557 exchange method, if curves of different sizes are used, then it is 558 possible that different hash functions from the SHA2 family could be 559 used. 561 9. Named Elliptic Curve Domain Parameters 563 Implementations may support any ASN.1 object identifier (OID) in the 564 ASN.1 object tree that defines a set of elliptic curve domain 565 parameters [ASN1]. 567 9.1. Required and Recommended Curves 569 Every SSH ECC implementation MUST support the named curves below, 570 these curves are defined in [SEC2]. These curves should always be 571 enabled unless specifically disabled by local security policy. 573 o secp256r1 575 o secp384r1 577 o secp521r1 579 It is RECOMMENDED that SSH ECC implementations also support the 580 following curves. 582 o sect163k1 584 o sect233k1 586 o sect233r1 588 o sect283k1 590 o sect409k1 592 o sect409r1 594 o sect571k1 596 o secp192r1 598 o secp224r1 600 9.2. SEC Equivalent NIST Curves and Encoded OIDs 602 The following table lists common curves by their equivalent SEC and 603 NIST names. The named NIST curves are specified in [NIST-CURVES]. 605 +-----------+----------+ 606 | SEC | NIST | 607 +-----------+----------+ 608 | sect163k1 | nistk163 | 609 | | | 610 | secp192r1 | nistp192 | 611 | | | 612 | secp224r1 | nistp224 | 613 | | | 614 | sect233k1 | nistk233 | 615 | | | 616 | sect233r1 | nistb233 | 617 | | | 618 | secp256r1 | nistp256 | 619 | | | 620 | sect283k1 | nistk283 | 621 | | | 622 | secp384r1 | nistp384 | 623 | | | 624 | sect409k1 | nistk409 | 625 | | | 626 | sect409r1 | nistb409 | 627 | | | 628 | secp521r1 | nistp521 | 629 | | | 630 | sect571k1 | nistk571 | 631 +-----------+----------+ 633 The following table lists the above SEC curves, their OID, and the 634 encoding of their OID as appropriate for the identifiers and method 635 names defined in Section Section 6. The encoding is the Base64 636 encoding of the MD5 hash [RFC1321] of the ASN.1 Distinguished 637 Encoding Rules (DER) encoding [ASN1] of the ASN.1 Object Identifier 638 (OID) of the named curve domain parameters that are associated with 639 the ephemeral keys. Base64 encoding is described in Section 6.8 of 640 [RFC2045]. 642 +-----------+---------------------+--------------------------+ 643 | SEC | OID | Base64(MD5(DER(OID))) | 644 +-----------+---------------------+--------------------------+ 645 | sect163k1 | 1.3.132.0.1 | 4MHB+NBt3AlaSRQ7MnB4cg== | 646 | | | | 647 | secp192r1 | 1.2.840.10045.3.1.1 | 5pPrSUQtIaTjUSt5VZNBjg== | 648 | | | | 649 | secp224r1 | 1.3.132.0.33 | VqBg4QRPjxx1EXZdV0GdWQ== | 650 | | | | 651 | sect233k1 | 1.3.132.0.26 | zD/b3hu/71952ArpUG4OjQ== | 652 | | | | 653 | sect233r1 | 1.3.132.0.27 | qCbG5Cn/jjsZ7nBeR7EnOA== | 654 | | | | 655 | secp256r1 | 1.2.840.10045.3.1.7 | 9UzNcgwTlEnSCECZa7V1mw== | 656 | | | | 657 | sect283k1 | 1.3.132.0.16 | wiRIU8TKjMZ418sMqlqtvQ== | 658 | | | | 659 | secp384r1 | 1.3.132.0.34 | qcFQaMAMGhTziMT0z+Tuzw== | 660 | | | | 661 | sect409k1 | 1.3.132.0.36 | m/FtSAmrV4j/Wy6RVUaK7A== | 662 | | | | 663 | sect409r1 | 1.3.132.0.37 | D3FefCjYoJ/kfXgAyLddYA== | 664 | | | | 665 | secp521r1 | 1.3.132.0.35 | h/SsxnLCtRBh7I9ATyeB3A== | 666 | | | | 667 | sect571k1 | 1.3.132.0.38 | mNVwCXAoS1HGmHpLvBC94w== | 668 +-----------+---------------------+--------------------------+ 670 The following sequence of commands can be used on many Unix-type 671 systems to generated the encoding of the OID as above. The command 672 oid below is an OID converter such as [OID.C]. 674 echo -n ${i} > tmp.oid 675 echo -n 0000: > tmp.hex 676 oid -i tmp.oid >> tmp.hex 677 xxd -r tmp.hex tmp.der 678 openssl md5 -binary < tmp.der > tmp.md5 679 openssl base64 < tmp.md5 > tmp.b64 680 cat tmp.b64 682 10. References 684 10.1. Normative References 686 [ASN1] International Telecommunications Union, "Abstract Syntax 687 Notation One (ASN.1): Specification of basic notation", 688 X.680, July 2002. 690 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 691 April 1992. 693 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 694 Extensions (MIME) Part One: Format of Internet Message 695 Bodies", RFC 2045, November 1996. 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", BCP 14, RFC 2119, March 1997. 700 [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) 701 Protocol Assigned Numbers", RFC 4250, January 2006. 703 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 704 Protocol Architecture", RFC 4251, January 2006. 706 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 707 Transport Layer Protocol", RFC 4253, January 2006. 709 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 710 (SHA and HMAC-SHA)", RFC 4634, July 2006. 712 [SEC1] Standards for Efficient Cryptography Group, "Elliptic 713 Curve Cryptography", SEC 1, September 2000, 714 . 716 [SEC2] Standards for Efficient Cryptography Group, "Recommended 717 Elliptic Curve Domain Parameters", SEC 2, September 2000, 718 . 720 10.2. Informative References 722 [ANSI-X9.62] 723 American National Standards Institute, "Public Key 724 Cryptography For The Financial Services Industry: The 725 Elliptic Curve Digital Signature Algorithm (ECDSA)", 726 ANSI X9.62, 1998. 728 [ANSI-X9.63] 729 American National Standards Institute, "Public Key 730 Cryptography For The Financial Services Industry: Key 731 Agreement and Key Transport Using Elliptic Curve 732 Cryptography", ANSI X9.63, January 1999. 734 [FIPS-180-2] 735 National Institute of Standards and Technology, "Secure 736 Hash Standard", FIPS 180-2, August 2002. 738 [HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to 739 Elliptic Curve Cryptography", 2004. 741 Springer, ISBN 038795273X 743 [IEEE1363] 744 Institute of Electrical and Electronics Engineers, 745 "Standard Specifications for Public Key Cryptography", 746 IEEE 1363, 2000. 748 [LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S. 749 Vanstone, "An Efficient Protocol for Authenticated Key 750 Agreement", University of Waterloo Technical Report 751 CORR 98-05, August 1998, . 755 [NIST-800-57] 756 National Institute of Standards and Technology, 757 "Recommendation for Key Management - Part 1: General 758 (Revised)", NIST Special Publication 800-57, March 2007. 760 [NIST-CURVES] 761 National Institute of Standards and Technology, 762 "Recommended Elliptic Curves for Federal Government Use", 763 August 1999. 765 [OID.C] Gartner, M., "OID Converter", 2006, 766 . 768 Appendix A. Acknowledgements 770 The authors acknowledge helpful comments from Alfred Hines, Russ 771 Housley, Jeffrey Hutzelman, and Rob Lambert. 773 Authors' Addresses 775 Douglas Stebila 776 University of Waterloo 777 Department of Combinatorics and Optimization 778 Waterloo, Ontario N2L 3G1 779 Canada 781 Email: douglas@stebila.ca 783 Jon Green 785 Full Copyright Statement 787 Copyright (C) The IETF Trust (2008). 789 This document is subject to the rights, licenses and restrictions 790 contained in BCP 78, and except as set forth therein, the authors 791 retain all their rights. 793 This document and the information contained herein are provided on an 794 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 795 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 796 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 797 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 798 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 799 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 801 Intellectual Property 803 The IETF takes no position regarding the validity or scope of any 804 Intellectual Property Rights or other rights that might be claimed to 805 pertain to the implementation or use of the technology described in 806 this document or the extent to which any license under such rights 807 might or might not be available; nor does it represent that it has 808 made any independent effort to identify any such rights. Information 809 on the procedures with respect to rights in RFC documents can be 810 found in BCP 78 and BCP 79. 812 Copies of IPR disclosures made to the IETF Secretariat and any 813 assurances of licenses to be made available, or the result of an 814 attempt made to obtain a general license or permission for the use of 815 such proprietary rights by implementers or users of this 816 specification can be obtained from the IETF on-line IPR repository at 817 http://www.ietf.org/ipr. 819 The IETF invites any interested party to bring to its attention any 820 copyrights, patents or patent applications, or other proprietary 821 rights that may cover technology that may be required to implement 822 this standard. Please address the information to the IETF at 823 ietf-ipr@ietf.org.