idnits 2.17.1 draft-green-secsh-ecc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year == Line 197 has weird spacing: '... string ecds...' == Line 207 has weird spacing: '... mpint r...' == Line 208 has weird spacing: '... mpint s...' == Line 297 has weird spacing: '... string the ...' -- 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 (April 14, 2009) is 5491 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 216 -- 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 (~~), 5 warnings (==), 8 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 Queensland University of 4 Intended status: Standards Track Technology 5 Expires: October 16, 2009 J. Green 6 Queen's University 7 April 14, 2009 9 Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer 10 draft-green-secsh-ecc-06 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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 October 16, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document describes algorithms based on Elliptic Curve 49 Cryptography (ECC) for use within the Secure Shell (SSH) transport 50 protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman 51 (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key 52 agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for 53 use in the SSH Transport Layer protocol. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. ECC Public Key Algorithm . . . . . . . . . . . . . . . . . . . 5 60 3.1. Key Format . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. Signature Algorithm . . . . . . . . . . . . . . . . . 5 62 3.1.2. Signature Encoding . . . . . . . . . . . . . . . . . . 6 63 4. ECDH Key Exchange . . . . . . . . . . . . . . . . . . . . . . 7 64 5. ECMQV Key Exchange . . . . . . . . . . . . . . . . . . . . . . 10 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. Elliptic Curve Domain Parameter Identifiers . . . . . . . 13 67 6.2. ECC Public Key Algorithm (ecdsa-sha2) . . . . . . . . . . 13 68 6.2.1. Elliptic Curve Digital Signature Algorithm . . . . . . 13 69 6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) . . . . . . . 14 70 6.4. ECMQV Key Exchange and Verification Method Name 71 (ecmqv-sha2) . . . . . . . . . . . . . . . . . . . . . . . 14 72 7. Key Exchange Messages . . . . . . . . . . . . . . . . . . . . 16 73 7.1. ECDH Message Numbers . . . . . . . . . . . . . . . . . . . 16 74 7.2. ECMQV Message Numbers . . . . . . . . . . . . . . . . . . 16 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 9. Named Elliptic Curve Domain Parameters . . . . . . . . . . . . 18 77 9.1. Required and Recommended Curves . . . . . . . . . . . . . 18 78 9.2. SEC Equivalent NIST Curves and Encoded OIDs . . . . . . . 18 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 82 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 23 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 85 1. Introduction 87 Due to its inclusion in NSA's Suite B and its small key sizes 88 elliptic curve cryptography (ECC) is becoming a widely utilized and 89 attractive public-key cryptosystem. 91 In the interest of adding Suite B algorithms to SSH this document 92 adds three ECC Suite B algorithms to the Secure Shell arsenal: 93 Elliptic Curve Menezes-Qu-Vanstone (ECMQV), Elliptic Curve Diffie- 94 Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm 95 (ECDSA), as well as utilizing the SHA2 family of secure hash 96 algorithms. 98 Compared to cryptosystems such as RSA, DSA, and DH, ECC variations on 99 these schemes offer equivalent security with smaller key sizes. This 100 is illustrated in the following table, based on Section 5.6.1 of NIST 101 800-57 [NIST-800-57], which gives approximate comparable key sizes 102 for symmetric- and asymmetric-key cryptosystems based on the best 103 known algorithms for attacking them. L is field size and N is sub- 104 field size. 106 +-----------+-----------------------------+-------+---------+ 107 | Symmetric | Discrete Log (eg. DSA, DH) | RSA | ECC | 108 +-----------+-----------------------------+-------+---------+ 109 | 80 | L = 1024 N = 160 | 1024 | 160-223 | 110 | | | | | 111 | 112 | L = 2048 N = 256 | 2048 | 224-255 | 112 | | | | | 113 | 128 | L = 3072 N = 256 | 3072 | 256-383 | 114 | | | | | 115 | 192 | L = 7680 N = 384 | 7680 | 384-511 | 116 | | | | | 117 | 256 | L = 15360 N = 512 | 15360 | 512+ | 118 +-----------+-----------------------------+-------+---------+ 120 Implementation of this specification requires familiarity with both 121 SSH [RFC4251] [RFC4253] [RFC4250] and ECC [SEC1] [IEEE1363] 122 [ANSI-X9.63]. 124 This document is concerned with SSH implementation details; 125 specification of the underlying cryptographic algorithms is left to 126 other standards documents. 128 Comments on this draft are solicited and should be addressed to 129 Douglas Stebila . 131 2. Notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 The data types boolean, uint32, uint64, string, and mpint are to be 138 interpreted in this document as described in [RFC4251]. 140 The size of a set of elliptic curve domain parameters on a prime 141 curve is defined as the number of bits in the binary representation 142 of the field order, commonly denoted p. Size on a characteristic-2 143 curve is defined as the number of bits in the binary representation 144 of the field, commonly denoted m. A set of elliptic curve domain 145 parameters defines a group of order n generated by a base point P. 147 3. ECC Public Key Algorithm 149 The ECC public key algorithm is defined by its key format, 150 corresponding signature algorithm ECDSA, signature encoding and 151 algorithm identifiers. 153 This section defines the family of "ecdsa-sha2-*" public key formats 154 and corresponding signature formats. Every compliant SSH ECC 155 implementation MUST implement this public key format. 157 3.1. Key Format 159 The "ecdsa-sha2-*" key formats all have the following encoding: 161 string "ecdsa-sha2-[identifier]" 162 byte[n] ecc_key_blob 164 The ecc_key_blob value has the following specific encoding: 166 string [identifier] 167 string Q 169 The string [identifier] is the identifier of the elliptic curve 170 domain parameters. The format of this string is specified in 171 Section 6.1. Information on the required and recommended sets of 172 elliptic curve domain parameters for use with this algorithm can be 173 found in Section 9. 175 Q is the public key encoded from an elliptic curve point into an 176 octet string as defined in Section 2.3.3 of [SEC1]; point compression 177 MUST NOT be used. 179 The algorithm for ECC key generation can be found in Section 3.2 of 180 [SEC1]. Given some elliptic curve domain parameters, an ECC key pair 181 can be generated containing a private key, an integer d, and a public 182 key, an elliptic curve point Q. 184 3.1.1. Signature Algorithm 186 Signing and verifying is done using the Elliptic Curve Digital 187 Signature Algorithm (ECDSA). ECDSA is specified in [SEC1] and in 188 [ANSI-X9.62]. The message hashing algorithm must be from the SHA2 189 family of hash functions [FIPS-180-3] and is chosen according to the 190 curve size as specified in Section 6.2.1. 192 3.1.2. Signature Encoding 194 Signatures are encoded as follows: 196 string "ecdsa-sha2-[identifier]" 197 string ecdsa_signature_blob 199 The string [identifier] is the identifier of the elliptic curve 200 domain parameters. The format of this string is specified in 201 Section 6.1. Information on the required and recommended sets of 202 elliptic curve domain parameters for use with this algorithm can be 203 found in Section 9. 205 The ecdsa_signature_blob value has the following specific encoding: 207 mpint r 208 mpint s 210 The integers r and s are the output of the ECDSA algorithm. 212 The width of the integer fields is determined by the curve being 213 used. Note that the integers r and s are integers modulo the order 214 of the curve, which may be larger than the size of the finite field. 215 Thus, the integers r and s are encoded as octet strings each of 216 length ciel(log[2](n)/8) using Section 2.3.7 of [SEC1], where n is 217 the order of the elliptic curve group. 219 4. ECDH Key Exchange 221 The Elliptic Curve Diffie-Hellman (ECDH) key exchange method 222 generates a shared secret from an ephemeral local elliptic curve 223 private key and ephemeral remote elliptic curve public key. This key 224 exchange method provides explicit server authentication as defined in 225 [RFC4253] using a signature on the exchange hash. Every compliant 226 SSH ECC implementation MUST implement ECDH Key Exchange. 228 The primitive used for shared key generation is ECDH with cofactor 229 multiplication, the full specification of which can be found in 230 Section 3.3.2 of [SEC1]. The algorithm for key pair generation can 231 be found in Section 3.2 of [SEC1]. 233 The family of key exchange method names defined for use with this key 234 exchange can be found in Section 6.3. Algorithm negotiation chooses 235 the public key algorithm to be used for signing and the method name 236 of the key exchange. The method name of the key exchange chosen 237 determines the elliptic curve domain parameters and hash function to 238 be used in the remainder of this section. 240 Information on the required and recommended elliptic curve domain 241 parameters for use with this method can be found in Section 9. 243 All elliptic curve public keys MUST be validated after they are 244 received. An example of a validation algorithm can be found in 245 A.16.10 of [IEEE1363]. If a key fails validation the key exchange 246 MUST fail. 248 The elliptic curve public keys (points) that must be transmitted are 249 encoded into octet strings before they are transmitted. The 250 transformation between elliptic curve points and octet strings is 251 specified in Sections 2.3.3 and 2.3.4 of [SEC1]; point compression 252 MUST NOT be used. The output of shared key generation is a field 253 element xp. The ssh framework requires that the shared key be an 254 integer. The conversion between a field element and an integer is 255 specified in Section 2.3.9 of [SEC1]. 257 Specification of the message numbers SSH_MSG_KEX_ECDH_INIT and 258 SSH_MSG_KEX_ECDH_REPLY are found in Section 7. 260 The following is an overview of the key exchange process: 262 Client Server 263 ------ ------ 264 Generate ephemeral key pair. 265 SSH_MSG_KEX_ECDH_INIT --------------> 267 Verify received key is valid. 268 Generate ephemeral key pair. 269 Compute shared secret. 270 Generate and sign exchange hash. 271 <------------- SSH_MSG_KEX_ECDH_REPLY 273 Verify received key is valid. 274 *Verify host key belongs to server. 275 Compute shared secret. 276 Generate exchange hash. 277 Verify server's signature. 279 *It is recommended that the client verify that the host key sent is 280 the server's host key (using certificates or a local database). The 281 client is allowed to accept the host key without verification, but 282 doing so will render the protocol insecure against active attacks; 283 see the discussion in Section 4.1 of [RFC4251]. 285 This is implemented using the following messages. 287 The client sends: 289 byte SSH_MSG_KEX_ECDH_INIT 290 string Q_C, client's ephemeral public key octet string 292 The server responds with: 294 byte SSH_MSG_KEX_ECDH_REPLY 295 string K_S, server's public host key and/or certificates 296 string Q_S, server's ephemeral public key octet string 297 string the signature on the exchange hash 299 The exchange hash H is computed as the hash of the concatenation of 300 the following. 302 string V_C, client's identification string (CR and LF excluded) 303 string V_S, server's identification string (CR and LF excluded) 304 string I_C, payload of the client's SSH_MSG_KEXINIT 305 string I_S, payload of the server's SSH_MSG_KEXINIT 306 string K_S, server's public host key 307 string Q_C, client's ephemeral public key octet string 308 string Q_S, server's ephemeral public key octet string 309 mpint K, shared secret 311 5. ECMQV Key Exchange 313 The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange algorithm 314 generates a shared secret from two local elliptic curve key pairs and 315 two remote public keys. This key exchange method provides implicit 316 server authentication as defined in [RFC4253]. The ECMQV key 317 exchange method is OPTIONAL. 319 The key exchange method name defined for use with this key exchange 320 is "ecmqv-sha2". This method name gives a hashing algorithm that is 321 to be used for the HMAC below. Future RFCs may define new method 322 names specifying new hash algorithms for use with ECMQV. More 323 information about the method name and HMAC can be found in 324 Section 6.4. 326 In general the ECMQV key exchange is performed using the ephemeral 327 and long term key pair of both the client and server, a total of 4 328 keys. Within the framework of SSH the client does not have a long 329 term key pair that needs to be authenticated. Therefore we generate 330 an ephemeral key and use that as both the clients keys. This is more 331 efficient than using two different ephemeral keys and does not 332 adversely affect security (it is analogous to the one-pass protocol 333 in Section 6.1 of [LMQSV98]). 335 A full description of the ECMQV primitive can be found in Section 3.4 336 of [SEC1]. The algorithm for key pair generation can be found in 337 Section 3.2 of [SEC1]. 339 During algorithm negotiation with the SSH_MSG_KEXINIT messages the 340 ECMQV key exchange method can only be chosen if a Public Key 341 Algorithm supporting ECC host keys can also be chosen. This is due 342 to the use of implicit server authentication in this key exchange 343 method. This case is handled the same way that key exchange methods 344 requiring encryption/signature capable public key algorithms are 345 handled in Section 7.1 of [RFC4253]. If ECMQV key exchange is chosen 346 then the Public Key Algorithm supporting ECC host keys MUST also be 347 chosen. 349 ECMQV requires that all the keys used to generate a shared secret are 350 generated over the same elliptic curve domain parameters. Since the 351 host key is used in the generation of the shared secret, allowing for 352 implicit server authentication, the domain parameters associated with 353 the host key are used throughout this section. 355 All elliptic curve public keys MUST be validated after they are 356 received. An example of a validation algorithm can be found in 357 A.16.10 of [IEEE1363]. If a key fails validation the key exchange 358 MUST fail. 360 The elliptic curve public keys (points) that must be transmitted are 361 encoded into octet strings before they are transmitted. The 362 transformation between elliptic curve points and octet strings is 363 specified in Sections 2.3.3 and 2.3.4 of [SEC1]; point compression 364 MAY be used. The output of shared key generation is a field element 365 xp. The ssh framework requires that the shared key be an integer. 366 The conversion between a field element and an integer is specified in 367 Section 2.3.9 of [SEC1]. 369 The following is an overview of the key exchange process: 371 Client Server 372 ------ ------ 373 Generate ephemeral key pair. 374 SSH_MSG_KEX_ECMQV_INIT -------------> 376 Verify received key is valid. 377 Generate ephemeral key pair. 378 Compute shared secret. 379 Generate exchange hash and compute 380 HMAC over it using the shared secret. 381 <------------- SSH_MSG_KEX_ECMQV_REPLY 383 Verify received keys are valid. 384 *Verify host key belongs to server. 385 Compute shared secret. 386 Verify HMAC. 388 *It is recommended that the client verify that the host key sent is 389 the server's host key (Using certificates or a local database). The 390 client is allowed to accept the host key without verification, but 391 doing so will render the protocol insecure against active attacks. 393 The specification of the message numbers SSH_MSG_ECMQV_INIT and 394 SSH_MSG_ECMQV_REPLY can be found in Section 7. 396 This key exchange algorithm is implemented with the following 397 messages. 399 The client sends: 401 byte SSH_MSG_ECMQV_INIT 402 string Q_C, client's ephemeral public key octet string 404 The server sends: 406 byte SSH_MSG_ECMQV_REPLY 407 string K_S, server's public host key octet string 408 string Q_S, server's ephemeral public key octet string 409 string HMAC tag computed on H using the shared secret 411 The hash H is formed by applying the algorithm HASH on a 412 concatenation of the following: 414 string V_C, client's identification string (CR and LF excluded) 415 string V_S, server's identification string (CR and LF excluded) 416 string I_C, payload of the client's SSH_MSG_KEXINIT 417 string I_S, payload of the server's SSH_MSG_KEXINIT 418 string Q_C, client's ephemeral public key octet 419 string K_S, server's public host key octet 420 string Q_S, server's ephemeral public key octet 421 mpint K, shared secret 423 6. IANA Considerations 425 This document defines a new family of key exchange method names, a 426 new key exchange method name, and a new public key algorithm name in 427 the SSH name registry. These additions to the SSH name space will 428 have to be approved the IANA. 430 6.1. Elliptic Curve Domain Parameter Identifiers 432 This section specifies identifiers encoding named elliptic curve 433 domain parameters. These identifiers are used in this document to 434 identify the curve used in the ECC public key format, the ECDSA 435 signature blob, and the ECDH method name. 437 An elliptic curve domain parameter identifier is the Base64 encoding 438 of the MD5 hash [RFC1321] of the ASN.1 Distinguished Encoding Rules 439 (DER) encoding [ASN1] of the ASN.1 Object Identifier (OID) of the 440 named curve domain parameters that are associated with the server's 441 ECC host keys. Every identifier is precisely 24 characters in 442 length. Base64 encoding is described in Section 4 of [RFC4648]. A 443 list of the required and recommended curves, their OIDs, and the 444 encoding of their identifiers can be found in Section 9. 446 For example: the identifier for the sect163k1 elliptic curve domain 447 parameters would be "4MHB+NBt3AlaSRQ7MnB4cg==". 449 6.2. ECC Public Key Algorithm (ecdsa-sha2) 451 The ECC Public Key Algorithm is specified by a family of public key 452 format identifiers. Each identifer is the concatenation of the 453 string "ecdsa-sha2-" with the elliptic curve domain parameter 454 identifier as defined in Section 6.1. A list of the required and 455 recommended curves and their OIDs can be found in Section 9. 457 For example: The method name for ECDH key exchange with ephemeral 458 keys generated on the secp256r1 curve would be "ecdsa-sha2- 459 9UzNcgwTlEnSCECZa7V1mw==". 461 6.2.1. Elliptic Curve Digital Signature Algorithm 463 The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified 464 for use with the ECC Public Key Algorithm. 466 The hashing algorithm defined by this family of method names is the 467 SHA2 family of hashing algorithms [FIPS-180-3]. The algorithm from 468 the SHA2 family that will be used is chosen based on the size of the 469 named curve specified in the public key: 471 +----------------+----------------+ 472 | Curve Size | Hash Algorithm | 473 +----------------+----------------+ 474 | b <= 256 | SHA-256 | 475 | | | 476 | 256 < b <= 384 | SHA-384 | 477 | | | 478 | 384 < b | SHA-512 | 479 +----------------+----------------+ 481 6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) 483 The Elliptic Curve Diffie-Hellman key exchange is defined by a family 484 of method names. Each method name is the concatenation of the string 485 "ecdh-sha2-" with the elliptic curve domain parameter identifier as 486 defined in Section 6.1. A list of the required and recommended 487 curves and their OIDs can be found in Section 9. 489 For example: The method name for ECDH key exchange with ephemeral 490 keys generated on the sect409k1 curve would be "ecdh-sha2-m/ 491 FtSAmrV4j/Wy6RVUaK7A==". 493 The hashing algorithm defined by this family of method names is the 494 SHA2 family of hashing algorithms [FIPS-180-3]. The hashing 495 algorithm is defined in the method name to allow room for other 496 algorithms to be defined in future documents. The algorithm from the 497 SHA2 family that will be used is chosen based on the size of the 498 named curve specified in the method name according to the table in 499 Section 6.2.1. 501 The concatenation of any so encoded ASN.1 OID specifying a set of 502 elliptic curve domain parameters with "ecdh-sha2-" is implicitly 503 registered under this specification. 505 6.4. ECMQV Key Exchange and Verification Method Name (ecmqv-sha2) 507 The Elliptic Curve Menezes-Qu-Vanstone key exchange is defined by the 508 method name "ecmqv-sha2". Unlike the ECDH key exchange method, ECMQV 509 relies on a public key algorithm that uses ECC keys: it does not need 510 a family of method names because the curve information can be gained 511 from the public key algorithm. 513 The hashing and message authentication code algorithms are defined by 514 the method name to allow room for other algorithms to be defined for 515 use with ECMQV in future documents. 517 The hashing algorithm defined by this method name is the SHA2 family 518 of hashing algorithms [FIPS-180-3]. The algorithm from the SHA2 519 family that will be used is chosen based on the size of the named 520 curve specified for use with ECMQV by the chosen public key algorithm 521 according to the table in Section 6.2.1. 523 The keyed-hash message authentication code that is used to identify 524 the server and verify communications is based on the hash chosen 525 above. The information on implementing the HMAC based on the chosen 526 hash algorithm can be found in [RFC2104]. 528 7. Key Exchange Messages 530 The message numbers 30-49 are key exchange-specific and in a private 531 namespace defined in [RFC4250] that may be redefined by any key 532 exchange method [RFC4253] without being granted IANA permission. 534 The following message numbers have been defined in this document: 536 7.1. ECDH Message Numbers 538 #define SSH_MSG_KEX_ECDH_INIT 30 539 #define SSH_MSG_KEX_ECDH_REPLY 31 541 7.2. ECMQV Message Numbers 543 #define SSH_MSG_ECMQV_INIT 30 544 #define SSH_MSG_ECMQV_REPLY 31 546 8. Security Considerations 548 The Elliptic Curve Diffie-Hellman key agreement algorithm is defined 549 in [SEC1], [IEEE1363] and [ANSI-X9.63]. The appropriate security 550 considerations of those documents apply. 552 The Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm is 553 defined in [SEC1]. The security considerations raised in that 554 document also apply. A more detailed discussion of security 555 considerations can be found in Section 4.7 of the Guide to Elliptic 556 Curve Cryptography [HMV04]. 558 The server's host key is used in the ECMQV key exchange algorithm. 559 This means that the strength of the server's ECC host key determines 560 the strength of the ECMQV key exchange algorithm. This should be 561 taken into consideration when generating ECC keys for a server. 563 The methods defined in Section 6 rely on the SHA2 family of hashing 564 functions as defined in [FIPS-180-3]. The appropriate security 565 considerations of that document apply. 567 The hashing algorithms defined for use with ECDH and ECMQV are 568 defined by their method names so that if security problems are found 569 with the SHA2 family of hashing algorithms or more secure hashing 570 algorithms become the standard then future documents can extend this 571 document to include new hashing algorithms by defining new method 572 names. 574 Additionally a good general discussion of the security considerations 575 that must be taken into account when creating an ECC implementation 576 can be found in Section 5 of the Guide to Elliptic Curve Cryptography 577 [HMV04]. 579 Since ECDH and ECMQV allow for elliptic curves of arbitrary sizes and 580 thus arbitrary security strength, it is important that the size of 581 elliptic curve be chosen to match the security strength of other 582 elements of the SSH handshake. In particular, host key sizes, 583 hashing algorithms and bulk encryption algorithms must be chosen 584 appropriately. Information regarding estimated equivalence of key 585 sizes is available in [NIST-800-57]. We note in particular that when 586 ECDSA is used as the signature algorithm and ECDH is used as the key 587 exchange method, if curves of different sizes are used, then it is 588 possible that different hash functions from the SHA2 family could be 589 used. 591 9. Named Elliptic Curve Domain Parameters 593 Implementations may support any ASN.1 object identifier (OID) in the 594 ASN.1 object tree that defines a set of elliptic curve domain 595 parameters [ASN1]. 597 9.1. Required and Recommended Curves 599 Every SSH ECC implementation MUST support the named curves below, 600 these curves are defined in [SEC2]. These curves should always be 601 enabled unless specifically disabled by local security policy. 603 o secp256r1 605 o secp384r1 607 o secp521r1 609 It is RECOMMENDED that SSH ECC implementations also support the 610 following curves. 612 o sect163k1 614 o sect233k1 616 o sect233r1 618 o sect283k1 620 o sect409k1 622 o sect409r1 624 o sect571k1 626 o secp192r1 628 o secp224r1 630 9.2. SEC Equivalent NIST Curves and Encoded OIDs 632 The following table lists common curves by their equivalent SEC and 633 NIST names. The named NIST curves are specified in [NIST-CURVES]. 635 +-----------+----------+ 636 | SEC | NIST | 637 +-----------+----------+ 638 | sect163k1 | nistk163 | 639 | | | 640 | secp192r1 | nistp192 | 641 | | | 642 | secp224r1 | nistp224 | 643 | | | 644 | sect233k1 | nistk233 | 645 | | | 646 | sect233r1 | nistb233 | 647 | | | 648 | secp256r1 | nistp256 | 649 | | | 650 | sect283k1 | nistk283 | 651 | | | 652 | secp384r1 | nistp384 | 653 | | | 654 | sect409k1 | nistk409 | 655 | | | 656 | sect409r1 | nistb409 | 657 | | | 658 | secp521r1 | nistp521 | 659 | | | 660 | sect571k1 | nistk571 | 661 +-----------+----------+ 663 The following table lists the above SEC curves, their OID, and the 664 encoding of their OID as appropriate for the identifiers and method 665 names defined in Section 6. The encoding is the Base64 encoding of 666 the MD5 hash [RFC1321] of the ASN.1 Distinguished Encoding Rules 667 (DER) encoding [ASN1] of the ASN.1 Object Identifier (OID) of the 668 named curve domain parameters that are associated with the ephemeral 669 keys. Base64 encoding is described in Section 4 of [RFC4648]. 671 +-----------+---------------------+--------------------------+ 672 | SEC | OID | Base64(MD5(DER(OID))) | 673 +-----------+---------------------+--------------------------+ 674 | sect163k1 | 1.3.132.0.1 | 4MHB+NBt3AlaSRQ7MnB4cg== | 675 | | | | 676 | secp192r1 | 1.2.840.10045.3.1.1 | 5pPrSUQtIaTjUSt5VZNBjg== | 677 | | | | 678 | secp224r1 | 1.3.132.0.33 | VqBg4QRPjxx1EXZdV0GdWQ== | 679 | | | | 680 | sect233k1 | 1.3.132.0.26 | zD/b3hu/71952ArpUG4OjQ== | 681 | | | | 682 | sect233r1 | 1.3.132.0.27 | qCbG5Cn/jjsZ7nBeR7EnOA== | 683 | | | | 684 | secp256r1 | 1.2.840.10045.3.1.7 | 9UzNcgwTlEnSCECZa7V1mw== | 685 | | | | 686 | sect283k1 | 1.3.132.0.16 | wiRIU8TKjMZ418sMqlqtvQ== | 687 | | | | 688 | secp384r1 | 1.3.132.0.34 | qcFQaMAMGhTziMT0z+Tuzw== | 689 | | | | 690 | sect409k1 | 1.3.132.0.36 | m/FtSAmrV4j/Wy6RVUaK7A== | 691 | | | | 692 | sect409r1 | 1.3.132.0.37 | D3FefCjYoJ/kfXgAyLddYA== | 693 | | | | 694 | secp521r1 | 1.3.132.0.35 | h/SsxnLCtRBh7I9ATyeB3A== | 695 | | | | 696 | sect571k1 | 1.3.132.0.38 | mNVwCXAoS1HGmHpLvBC94w== | 697 +-----------+---------------------+--------------------------+ 699 The following sequence of commands can be used on a Unix-type system 700 to generate the encoding of the OID as above provided the appropriate 701 software is installed. The program "oid" can be downloaded from 702 [OID.C]. The program "xxd" is part of the editor Vim and can be 703 downloaded from [VIM]. The program "openssl" can be downloaded from 704 [OPENSSL]. 706 echo -n ${i} > tmp.oid 707 echo -n 0000: > tmp.hex 708 oid -i tmp.oid >> tmp.hex 709 xxd -r tmp.hex tmp.der 710 openssl md5 -binary < tmp.der > tmp.md5 711 openssl base64 < tmp.md5 > tmp.b64 712 cat tmp.b64 714 10. References 716 10.1. Normative References 718 [ASN1] International Telecommunications Union, "Abstract Syntax 719 Notation One (ASN.1): Specification of basic notation", 720 X.680, July 2002. 722 [FIPS-180-3] 723 National Institute of Standards and Technology, "Secure 724 Hash Standard", FIPS 180-3, October 2008. 726 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 727 April 1992. 729 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 730 Hashing for Message Authentication", RFC 2104, 731 February 1997. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) 737 Protocol Assigned Numbers", RFC 4250, January 2006. 739 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 740 Protocol Architecture", RFC 4251, January 2006. 742 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 743 Transport Layer Protocol", RFC 4253, January 2006. 745 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 746 Encodings", RFC 4648, October 2006. 748 [SEC1] Standards for Efficient Cryptography Group, "Elliptic 749 Curve Cryptography", SEC 1, September 2000, 750 . 752 [SEC2] Standards for Efficient Cryptography Group, "Recommended 753 Elliptic Curve Domain Parameters", SEC 2, September 2000, 754 . 756 10.2. Informative References 758 [ANSI-X9.62] 759 American National Standards Institute, "Public Key 760 Cryptography For The Financial Services Industry: The 761 Elliptic Curve Digital Signature Algorithm (ECDSA)", 762 ANSI X9.62, 1998. 764 [ANSI-X9.63] 765 American National Standards Institute, "Public Key 766 Cryptography For The Financial Services Industry: Key 767 Agreement and Key Transport Using Elliptic Curve 768 Cryptography", ANSI X9.63, January 1999. 770 [HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to 771 Elliptic Curve Cryptography", 2004. 773 Springer, ISBN 038795273X 775 [IEEE1363] 776 Institute of Electrical and Electronics Engineers, 777 "Standard Specifications for Public Key Cryptography", 778 IEEE 1363, 2000. 780 [LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S. 781 Vanstone, "An Efficient Protocol for Authenticated Key 782 Agreement", University of Waterloo Technical Report 783 CORR 98-05, August 1998, . 787 [NIST-800-57] 788 National Institute of Standards and Technology, 789 "Recommendation for Key Management - Part 1: General 790 (Revised)", NIST Special Publication 800-57, March 2007, < 791 http://csrc.nist.gov/publications/nistpubs/800-57/ 792 sp800-57-Part1-revised2_Mar08-2007.pdf>. 794 [NIST-CURVES] 795 National Institute of Standards and Technology, 796 "Recommended Elliptic Curves for Federal Government Use", 797 August 1999, 798 . 800 [OID.C] Gartner, M., "OID Converter", 2006, 801 . 803 [OPENSSL] The OpenSSL Project, "OpenSSL", 2006, 804 . 806 [VIM] Moolenaar, B., "Vim", 2008, . 808 Appendix A. Acknowledgements 810 The authors acknowledge helpful comments from James Blaisdell, Alfred 811 Hoenes, Russ Housley, Jeffrey Hutzelman, Rob Lambert, and Jan 812 Pechanek, and the help of Tim Polk. 814 Authors' Addresses 816 Douglas Stebila 817 Queensland University of Technology 818 Information Security Institute 819 Level 7, 126 Margaret St 820 Brisbane, Queensland 4000 821 Australia 823 Email: douglas@stebila.ca 825 Jon Green 826 Queen's University 827 Parallel Processing Research Laboratory 828 Department of Electrical and Computer Engineering 829 Room 614, Walter Light Hall 830 Kingston, Ontario K7L 3N6 831 Canada 833 Email: jon.green@ece.queensu.ca