idnits 2.17.1 draft-green-secsh-ecc-05.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 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 835. 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 (December 2, 2008) is 5621 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 199 -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Downref: Normative reference to an Informational RFC: RFC 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 13 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: June 5, 2009 December 2, 2008 7 Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer 8 draft-green-secsh-ecc-05 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 June 5, 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. Every compliant SSH ECC 145 implementation MUST implement this public key format. 147 3.1. Key Format 149 The "ecdsa-sha2" key format has the following encoding: 151 string "ecdsa-sha2" 152 byte[n] ecc_key_blob 154 The ecc_key_blob value has the following specific encoding: 156 string [identifier] 157 string Q 159 The string [identifier] is the identifier of the elliptic curve 160 domain parameters. The format of this string is specified in 161 Section 6.1. Information on the required and recommended sets of 162 elliptic curve domain parameters for use with this algorithm can be 163 found in Section 9. 165 Q is the public key encoded from an elliptic curve point into an 166 octet string as defined in Section 2.3.3 of [SEC1]. 168 The algorithm for ECC key generation can be found in Section 3.2 of 169 [SEC1]. Given some elliptic curve domain parameters, an ECC key pair 170 can be generated containing a private key, an integer d, and a public 171 key, an elliptic curve point Q. 173 3.1.1. Signature Algorithm 175 Signing and verifying is done using the Elliptic Curve Digital 176 Signature Algorithm (ECDSA). ECDSA is specified in [SEC1] and in 177 [ANSI-X9.62]. The message hashing algorithm must be from the SHA2 178 family of hash functions [FIPS-180-3] and is chosen according to the 179 curve size as specified in Section 6.2.1. 181 3.1.2. Signature Encoding 183 Signatures are encoded as follows: 185 string "ecdsa-sha2" 186 string ecdsa_signature_blob 188 The ecdsa_signature_blob value has the following specific encoding: 190 mpint r 191 mpint s 193 The integers r and s are the output of the ECDSA algorithm. 195 The width of the integer fields is determined by the curve being 196 used. Note that the integers r and s are integers modulo the order 197 of the curve, which may be larger than the size of the finite field. 198 Thus, the integers r and s are encoded as octet strings each of 199 length ciel(log[2](n)/8) using Section 2.3.7 of [SEC1], where n is 200 the order of the elliptic curve group. 202 4. ECDH Key Exchange 204 The Elliptic Curve Diffie-Hellman (ECDH) key exchange method 205 generates a shared secret from an ephemeral local elliptic curve 206 private key and ephemeral remote elliptic curve public key. This key 207 exchange method provides explicit server authentication as defined in 208 [RFC4253] using a signature on the exchange hash. Every compliant 209 SSH ECC implementation MUST implement ECDH Key Exchange. 211 The primitive used for shared key generation is ECDH with cofactor 212 multiplication, the full specification of which can be found in 213 Section 3.3.2 of [SEC1]. The algorithm for key pair generation can 214 be found in Section 3.2 of [SEC1]. 216 The family of key exchange method names defined for use with this key 217 exchange can be found in Section 6.3. Algorithm negotiation chooses 218 the public key algorithm to be used for signing and the method name 219 of the key exchange. The method name of the key exchange chosen 220 determines the elliptic curve domain parameters and hash function to 221 be used in the remainder of this section. 223 Information on the required and recommended elliptic curve domain 224 parameters for use with this method can be found in Section 9. 226 All elliptic curve public keys MUST be validated after they are 227 received. An example of a validation algorithm can be found in 228 A.16.10 of [IEEE1363]. If a key fails validation the key exchange 229 MUST fail. 231 The elliptic curve public keys (points) that must be transmitted are 232 encoded into octet strings before they are transmitted. The 233 transformation between elliptic curve points and octet strings is 234 specified in Section 2.3 of [SEC1]. The output of shared key 235 generation is a field element xp. The ssh framework requires that 236 the shared key be an integer. The conversion between a field element 237 and an integer is specified in Section 2.3.9 of [SEC1]. 239 Specification of the message numbers SSH_MSG_KEX_ECDH_INIT and 240 SSH_MSG_KEX_ECDH_REPLY are found in Section 7. 242 The following is an overview of the key exchange process: 244 Client Server 245 ------ ------ 246 Generate ephemeral key pair. 247 SSH_MSG_KEX_ECDH_INIT --------------> 249 Verify received key is valid. 250 Generate ephemeral key pair. 251 Compute shared secret. 252 Generate and sign exchange hash. 253 <------------- SSH_MSG_KEX_ECDH_REPLY 255 Verify received key is valid. 256 *Verify host key belongs to server. 257 Compute shared secret. 258 Generate exchange hash. 259 Verify server's signature. 261 *It is recommended that the client verify that the host key sent is 262 the server's host key (using certificates or a local database). The 263 client is allowed to accept the host key without verification, but 264 doing so will render the protocol insecure against active attacks; 265 see the discussion in Section 4.1 of [RFC4251]. 267 This is implemented using the following messages. 269 The client sends: 271 byte SSH_MSG_KEX_ECDH_INIT 272 string client's ephemeral public key octet string 274 The server responds with: 276 byte SSH_MSG_KEX_ECDH_REPLY 277 string server's public host key and/or certificates 278 string server's ephemeral public key octet string 279 string the signature on the exchange hash 281 The exchange hash H is computed as the hash of the concatenation of 282 the following. 284 string client's identification string (CR and LF excluded) 285 string server's identification string (CR and LF excluded) 286 string payload of the client's SSH_MSG_KEXINIT 287 string payload of the server's SSH_MSG_KEXINIT 288 string server's public host key 289 string client's ephemeral public key octet string 290 string server's ephemeral public key octet string 291 mpint shared secret 293 5. ECMQV Key Exchange 295 The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange algorithm 296 generates a shared secret from two local elliptic curve key pairs and 297 two remote public keys. This key exchange method provides implicit 298 server authentication as defined in [RFC4253]. The ECMQV key 299 exchange method is OPTIONAL. 301 The key exchange method name defined for use with this key exchange 302 is "ecmqv-sha2". This method name gives a hashing algorithm that is 303 to be used for the HMAC below. Future RFCs may define new method 304 names specifying new hash algorithms for use with ECMQV. More 305 information about the method name and HMAC can be found in 306 Section 6.4. 308 In general the ECMQV key exchange is performed using the ephemeral 309 and long term key pair of both the client and server, a total of 4 310 keys. Within the framework of SSH the client does not have a long 311 term key pair that needs to be authenticated. Therefore we generate 312 an ephemeral key and use that as both the clients keys. This is more 313 efficient than using two different ephemeral keys and does not 314 adversely affect security (it is analogous to the one-pass protocol 315 in Section 6.1 of [LMQSV98]). 317 A full description of the ECMQV primitive can be found in Section 3.4 318 of [SEC1]. The algorithm for key pair generation can be found in 319 Section 3.2 of [SEC1]. 321 During algorithm negotiation with the SSH_MSG_KEXINIT messages the 322 ECMQV key exchange method can only be chosen if a Public Key 323 Algorithm supporting ECC host keys can also be chosen. This is due 324 to the use of implicit server authentication in this key exchange 325 method. This case is handled the same way that key exchange methods 326 requiring encryption/signature capable public key algorithms are 327 handled in Section 7.1 of [RFC4253]. If ECMQV key exchange is chosen 328 then the Public Key Algorithm supporting ECC host keys MUST also be 329 chosen. 331 ECMQV requires that all the keys used to generate a shared secret are 332 generated over the same elliptic curve domain parameters. Since the 333 host key is used in the generation of the shared secret, allowing for 334 implicit server authentication, the domain parameters associated with 335 the host key are used throughout this section. 337 All elliptic curve public keys MUST be validated after they are 338 received. An example of a validation algorithm can be found in 339 A.16.10 of [IEEE1363]. If a key fails validation the key exchange 340 MUST fail. 342 The elliptic curve public keys (points) that must be transmitted are 343 encoded into octet strings before they are transmitted. The 344 transformation between elliptic curve points and octet strings is 345 specified in Section 2.3 of [SEC1]. The output of shared key 346 generation is a field element xp. The ssh framework requires that 347 the shared key be an integer. The conversion between a field element 348 and an integer is specified in Section 2.3.9 of [SEC1]. 350 The following is an overview of the key exchange process: 352 Client Server 353 ------ ------ 354 Generate ephemeral key pair. 355 SSH_MSG_KEX_ECMQV_INIT -------------> 357 Verify received key is valid. 358 Generate ephemeral key pair. 359 Compute shared secret. 360 Generate exchange hash and compute 361 HMAC over it using the shared secret. 362 <------------- SSH_MSG_KEX_ECDH_REPLY 364 Verify received keys are valid. 365 *Verify host key belongs to server. 366 Compute shared secret. 367 Verify HMAC. 369 *It is recommended that the client verify that the host key sent is 370 the server's host key (Using certificates or a local database). The 371 client is allowed to accept the host key without verification, but 372 doing so will render the protocol insecure against active attacks. 374 The specification of the message numbers SSH_MSG_ECMQV_INIT and 375 SSH_MSG_ECMQV_REPLY can be found in Section 7. 377 This key exchange algorithm is implemented with the following 378 messages. 380 The client sends: 382 byte SSH_MSG_ECMQV_INIT 383 string client's ephemeral public key octet string 385 The server sends: 387 byte SSH_MSG_ECMQV_REPLY 388 string server's public host key octet string 389 string server's ephemeral public key octet string 390 string HMAC tag computed on H using the shared secret 392 The hash H is formed by applying the algorithm HASH on a 393 concatenation of the following: 395 string client's identification string (CR and LF excluded) 396 string server's identification string (CR and LF excluded) 397 string payload of the client's SSH_MSG_KEXINIT 398 string payload of the server's SSH_MSG_KEXINIT 399 string client's ephemeral public key octet 400 string server's public host key octet 401 string server's ephemeral public key octet 402 mpint shared secret 404 6. IANA Considerations 406 This document defines a new family of key exchange method names, a 407 new key exchange method name, and a new public key algorithm name in 408 the SSH name registry. These additions to the SSH name space will 409 have to be approved the IANA. 411 6.1. Elliptic Curve Domain Parameter Identifiers 413 This section specifies identifiers encoding named elliptic curve 414 domain parameters. These identifiers are used in this document to 415 identify the curve used in the ECC public key format, the ECDSA 416 signature blob, and the ECDH method name. 418 An elliptic curve domain parameter identifier is the Base64 encoding 419 of the MD5 hash [RFC1321] of the ASN.1 Distinguished Encoding Rules 420 (DER) encoding [ASN1] of the ASN.1 Object Identifier (OID) of the 421 named curve domain parameters that are associated with the server's 422 ECC host keys. Every identifier is precisely 24 characters in 423 length. Base64 encoding is described in Section 4 of [RFC4648]. A 424 list of the required and recommended curves, their OIDs, and the 425 encoding of their identifiers can be found in Section 9. 427 For example: the identifier for the sect163k1 elliptic curve domain 428 parameters would be "4MHB+NBt3AlaSRQ7MnB4cg==". 430 6.2. ECC Public Key Algorithm (ecdsa-sha2) 432 The ECC Public Key Algorithm is specified by the public key format 433 identifier "ecdsa-sha2". 435 6.2.1. Elliptic Curve Digital Signature Algorithm 437 The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified 438 for use with the ECC Public Key Algorithm. 440 The hashing algorithm defined by this family of method names is the 441 SHA2 family of hashing algorithms [FIPS-180-3]. The algorithm from 442 the SHA2 family that will be used is chosen based on the size of the 443 named curve specified in the public key: 445 +----------------+----------------+ 446 | Curve Size | Hash Algorithm | 447 +----------------+----------------+ 448 | b <= 256 | SHA-256 | 449 | | | 450 | 256 < b <= 384 | SHA-384 | 451 | | | 452 | 384 < b | SHA-512 | 453 +----------------+----------------+ 455 6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) 457 The Elliptic Curve Diffie-Hellman key exchange is defined by a family 458 of method names. Each method name is the concatenation of the string 459 "ecdh-sha2-" with the elliptic curve domain parameter identifier as 460 defined in Section 6.1. A list of the required and recommended 461 curves and their OIDs can be found in Section 9. 463 For example: The method name for ECDH key exchange with ephemeral 464 keys generated on the sect409k1 curve would be "ecdh-sha2-m/ 465 FtSAmrV4j/Wy6RVUaK7A==". 467 The hashing algorithm defined by this family of method names is the 468 SHA2 family of hashing algorithms [FIPS-180-3]. The hashing 469 algorithm is defined in the method name to allow room for other 470 algorithms to be defined in future documents. The algorithm from the 471 SHA2 family that will be used is chosen based on the size of the 472 named curve specified in the method name according to the table in 473 Section 6.2.1. 475 The concatenation of any so encoded ASN.1 OID specifying a set of 476 elliptic curve domain parameters with "ecdh-sha2-" is implicitly 477 registered under this specification. 479 6.4. ECMQV Key Exchange and Verification Method Name (ecmqv-sha2) 481 The Elliptic Curve Menezes-Qu-Vanstone key exchange is defined by the 482 method name "ecmqv-sha2". Unlike the ECDH key exchange method, ECMQV 483 relies on a public key algorithm that uses ECC keys: it does not need 484 a family of method names because the curve information can be gained 485 from the public key algorithm. 487 The hashing and message authentication code algorithms are defined by 488 the method name to allow room for other algorithms to be defined for 489 use with ECMQV in future documents. 491 The hashing algorithm defined by this method name is the SHA2 family 492 of hashing algorithms [FIPS-180-3]. The algorithm from the SHA2 493 family that will be used is chosen based on the size of the named 494 curve specified for use with ECMQV by the chosen public key algorithm 495 according to the table in Section 6.2.1. 497 The keyed-hash message authentication code that is used to identify 498 the server and verify communications is based on the hash chosen 499 above. The information on implementing the HMAC based on the chosen 500 hash algorithm can be found in [RFC2104]. 502 7. Key Exchange Messages 504 The message numbers 30-49 are key exchange-specific and in a private 505 namespace defined in [RFC4250] that may be redefined by any key 506 exchange method [RFC4253] without being granted IANA permission. 508 The following message numbers have been defined in this document: 510 7.1. ECDH Message Numbers 512 #define SSH_MSG_KEX_ECDH_INIT 30 513 #define SSH_MSG_KEX_ECDH_REPLY 31 515 7.2. ECMQV Message Numbers 517 #define SSH_MSG_ECMQV_INIT 30 518 #define SSH_MSG_ECMQV_REPLY 31 520 8. Security Considerations 522 The Elliptic Curve Diffie-Hellman key agreement algorithm is defined 523 in [SEC1], [IEEE1363] and [ANSI-X9.63]. The appropriate security 524 considerations of those documents apply. 526 The Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm is 527 defined in [SEC1]. The security considerations raised in that 528 document also apply. A more detailed discussion of security 529 considerations can be found in Section 4.7 of the Guide to Elliptic 530 Curve Cryptography [HMV04]. 532 The server's host key is used in the ECMQV key exchange algorithm. 533 This means that the strength of the server's ECC host key determines 534 the strength of the ECMQV key exchange algorithm. This should be 535 taken into consideration when generating ECC keys for a server. 537 The methods defined in Section 6 rely on the SHA2 family of hashing 538 functions as defined in [FIPS-180-3]. The appropriate security 539 considerations of that document apply. 541 The hashing algorithms defined for use with ECDH and ECMQV are 542 defined by their method names so that if security problems are found 543 with the SHA2 family of hashing algorithms or more secure hashing 544 algorithms become the standard then future documents can extend this 545 document to include new hashing algorithms by defining new method 546 names. 548 Additionally a good general discussion of the security considerations 549 that must be taken into account when creating an ECC implementation 550 can be found in Section 5 of the Guide to Elliptic Curve Cryptography 551 [HMV04]. 553 Since ECDH and ECMQV allow for elliptic curves of arbitrary sizes and 554 thus arbitrary security strength, it is important that the size of 555 elliptic curve be chosen to match the security strength of other 556 elements of the SSH handshake. In particular, host key sizes, 557 hashing algorithms and bulk encryption algorithms must be chosen 558 appropriately. Information regarding estimated equivalence of key 559 sizes is available in [NIST-800-57]. We note in particular that when 560 ECDSA is used as the signature algorithm and ECDH is used as the key 561 exchange method, if curves of different sizes are used, then it is 562 possible that different hash functions from the SHA2 family could be 563 used. 565 9. Named Elliptic Curve Domain Parameters 567 Implementations may support any ASN.1 object identifier (OID) in the 568 ASN.1 object tree that defines a set of elliptic curve domain 569 parameters [ASN1]. 571 9.1. Required and Recommended Curves 573 Every SSH ECC implementation MUST support the named curves below, 574 these curves are defined in [SEC2]. These curves should always be 575 enabled unless specifically disabled by local security policy. 577 o secp256r1 579 o secp384r1 581 o secp521r1 583 It is RECOMMENDED that SSH ECC implementations also support the 584 following curves. 586 o sect163k1 588 o sect233k1 590 o sect233r1 592 o sect283k1 594 o sect409k1 596 o sect409r1 598 o sect571k1 600 o secp192r1 602 o secp224r1 604 9.2. SEC Equivalent NIST Curves and Encoded OIDs 606 The following table lists common curves by their equivalent SEC and 607 NIST names. The named NIST curves are specified in [NIST-CURVES]. 609 +-----------+----------+ 610 | SEC | NIST | 611 +-----------+----------+ 612 | sect163k1 | nistk163 | 613 | | | 614 | secp192r1 | nistp192 | 615 | | | 616 | secp224r1 | nistp224 | 617 | | | 618 | sect233k1 | nistk233 | 619 | | | 620 | sect233r1 | nistb233 | 621 | | | 622 | secp256r1 | nistp256 | 623 | | | 624 | sect283k1 | nistk283 | 625 | | | 626 | secp384r1 | nistp384 | 627 | | | 628 | sect409k1 | nistk409 | 629 | | | 630 | sect409r1 | nistb409 | 631 | | | 632 | secp521r1 | nistp521 | 633 | | | 634 | sect571k1 | nistk571 | 635 +-----------+----------+ 637 The following table lists the above SEC curves, their OID, and the 638 encoding of their OID as appropriate for the identifiers and method 639 names defined in Section 6. The encoding is the Base64 encoding of 640 the MD5 hash [RFC1321] of the ASN.1 Distinguished Encoding Rules 641 (DER) encoding [ASN1] of the ASN.1 Object Identifier (OID) of the 642 named curve domain parameters that are associated with the ephemeral 643 keys. Base64 encoding is described in Section 4 of [RFC4648]. 645 +-----------+---------------------+--------------------------+ 646 | SEC | OID | Base64(MD5(DER(OID))) | 647 +-----------+---------------------+--------------------------+ 648 | sect163k1 | 1.3.132.0.1 | 4MHB+NBt3AlaSRQ7MnB4cg== | 649 | | | | 650 | secp192r1 | 1.2.840.10045.3.1.1 | 5pPrSUQtIaTjUSt5VZNBjg== | 651 | | | | 652 | secp224r1 | 1.3.132.0.33 | VqBg4QRPjxx1EXZdV0GdWQ== | 653 | | | | 654 | sect233k1 | 1.3.132.0.26 | zD/b3hu/71952ArpUG4OjQ== | 655 | | | | 656 | sect233r1 | 1.3.132.0.27 | qCbG5Cn/jjsZ7nBeR7EnOA== | 657 | | | | 658 | secp256r1 | 1.2.840.10045.3.1.7 | 9UzNcgwTlEnSCECZa7V1mw== | 659 | | | | 660 | sect283k1 | 1.3.132.0.16 | wiRIU8TKjMZ418sMqlqtvQ== | 661 | | | | 662 | secp384r1 | 1.3.132.0.34 | qcFQaMAMGhTziMT0z+Tuzw== | 663 | | | | 664 | sect409k1 | 1.3.132.0.36 | m/FtSAmrV4j/Wy6RVUaK7A== | 665 | | | | 666 | sect409r1 | 1.3.132.0.37 | D3FefCjYoJ/kfXgAyLddYA== | 667 | | | | 668 | secp521r1 | 1.3.132.0.35 | h/SsxnLCtRBh7I9ATyeB3A== | 669 | | | | 670 | sect571k1 | 1.3.132.0.38 | mNVwCXAoS1HGmHpLvBC94w== | 671 +-----------+---------------------+--------------------------+ 673 The following sequence of commands can be used on a Unix-type system 674 to generate the encoding of the OID as above provided the appropriate 675 software is installed. The program "oid" can be downloaded from 676 [OID.C]. The program "xxd" is part of the editor Vim and can be 677 downloaded from [VIM]. The program "openssl" can be downloaded from 678 [OPENSSL]. 680 echo -n ${i} > tmp.oid 681 echo -n 0000: > tmp.hex 682 oid -i tmp.oid >> tmp.hex 683 xxd -r tmp.hex tmp.der 684 openssl md5 -binary < tmp.der > tmp.md5 685 openssl base64 < tmp.md5 > tmp.b64 686 cat tmp.b64 688 10. References 690 10.1. Normative References 692 [ASN1] International Telecommunications Union, "Abstract Syntax 693 Notation One (ASN.1): Specification of basic notation", 694 X.680, July 2002. 696 [FIPS-180-3] 697 National Institute of Standards and Technology, "Secure 698 Hash Standard", FIPS 180-3, October 2008. 700 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 701 April 1992. 703 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 704 Hashing for Message Authentication", RFC 2104, 705 February 1997. 707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 708 Requirement Levels", BCP 14, RFC 2119, March 1997. 710 [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) 711 Protocol Assigned Numbers", RFC 4250, January 2006. 713 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 714 Protocol Architecture", RFC 4251, January 2006. 716 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 717 Transport Layer Protocol", RFC 4253, January 2006. 719 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 720 Encodings", RFC 4648, October 2006. 722 [SEC1] Standards for Efficient Cryptography Group, "Elliptic 723 Curve Cryptography", SEC 1, September 2000, 724 . 726 [SEC2] Standards for Efficient Cryptography Group, "Recommended 727 Elliptic Curve Domain Parameters", SEC 2, September 2000, 728 . 730 10.2. Informative References 732 [ANSI-X9.62] 733 American National Standards Institute, "Public Key 734 Cryptography For The Financial Services Industry: The 735 Elliptic Curve Digital Signature Algorithm (ECDSA)", 736 ANSI X9.62, 1998. 738 [ANSI-X9.63] 739 American National Standards Institute, "Public Key 740 Cryptography For The Financial Services Industry: Key 741 Agreement and Key Transport Using Elliptic Curve 742 Cryptography", ANSI X9.63, January 1999. 744 [HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to 745 Elliptic Curve Cryptography", 2004. 747 Springer, ISBN 038795273X 749 [IEEE1363] 750 Institute of Electrical and Electronics Engineers, 751 "Standard Specifications for Public Key Cryptography", 752 IEEE 1363, 2000. 754 [LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S. 755 Vanstone, "An Efficient Protocol for Authenticated Key 756 Agreement", University of Waterloo Technical Report 757 CORR 98-05, August 1998, . 761 [NIST-800-57] 762 National Institute of Standards and Technology, 763 "Recommendation for Key Management - Part 1: General 764 (Revised)", NIST Special Publication 800-57, March 2007. 766 [NIST-CURVES] 767 National Institute of Standards and Technology, 768 "Recommended Elliptic Curves for Federal Government Use", 769 August 1999. 771 [OID.C] Gartner, M., "OID Converter", 2006, 772 . 774 [OPENSSL] The OpenSSL Project, "OpenSSL", 2006, 775 . 777 [VIM] Moolenaar, B., "Vim", 2008, . 779 Appendix A. Acknowledgements 781 The authors acknowledge helpful comments from Alfred Hoenes, Russ 782 Housley, Jeffrey Hutzelman, Rob Lambert, and Jan Pechanek, and the 783 help of Tim Polk. 785 Authors' Addresses 787 Douglas Stebila 788 University of Waterloo 789 Department of Combinatorics and Optimization 790 Waterloo, Ontario N2L 3G1 791 Canada 793 Email: douglas@stebila.ca 795 Jon Green 797 Full Copyright Statement 799 Copyright (C) The IETF Trust (2008). 801 This document is subject to the rights, licenses and restrictions 802 contained in BCP 78, and except as set forth therein, the authors 803 retain all their rights. 805 This document and the information contained herein are provided on an 806 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 807 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 808 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 809 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 810 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 811 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 813 Intellectual Property 815 The IETF takes no position regarding the validity or scope of any 816 Intellectual Property Rights or other rights that might be claimed to 817 pertain to the implementation or use of the technology described in 818 this document or the extent to which any license under such rights 819 might or might not be available; nor does it represent that it has 820 made any independent effort to identify any such rights. Information 821 on the procedures with respect to rights in RFC documents can be 822 found in BCP 78 and BCP 79. 824 Copies of IPR disclosures made to the IETF Secretariat and any 825 assurances of licenses to be made available, or the result of an 826 attempt made to obtain a general license or permission for the use of 827 such proprietary rights by implementers or users of this 828 specification can be obtained from the IETF on-line IPR repository at 829 http://www.ietf.org/ipr. 831 The IETF invites any interested party to bring to its attention any 832 copyrights, patents or patent applications, or other proprietary 833 rights that may cover technology that may be required to implement 834 this standard. Please address the information to the IETF at 835 ietf-ipr@ietf.org.