idnits 2.17.1 draft-green-secsh-ecc-08.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 207 has weird spacing: '... string ecds...' == Line 217 has weird spacing: '... mpint r...' == Line 218 has weird spacing: '... mpint s...' == Line 307 has weird spacing: '... string the ...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 6, 2009) is 5435 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 226 -- 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 2104 -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Stebila 3 Internet-Draft Queensland University of 4 Intended status: Standards Track Technology 5 Expires: December 8, 2009 J. Green 6 Queen's University 7 June 6, 2009 9 Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer 10 draft-green-secsh-ecc-08 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. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on December 8, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document describes algorithms based on Elliptic Curve 59 Cryptography (ECC) for use within the Secure Shell (SSH) transport 60 protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman 61 (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key 62 agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for 63 use in the SSH Transport Layer protocol. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. ECC Public Key Algorithm . . . . . . . . . . . . . . . . . . . 6 70 3.1. Key Format . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1.1. Signature Algorithm . . . . . . . . . . . . . . . . . 6 72 3.1.2. Signature Encoding . . . . . . . . . . . . . . . . . . 7 73 4. ECDH Key Exchange . . . . . . . . . . . . . . . . . . . . . . 8 74 5. ECMQV Key Exchange . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Method Names . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 6.1. Elliptic Curve Domain Parameter Identifiers . . . . . . . 14 77 6.2. ECC Public Key Algorithm (ecdsa-sha2-*) . . . . . . . . . 14 78 6.2.1. Elliptic Curve Digital Signature Algorithm . . . . . . 15 79 6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) . . . . . . . 15 80 6.4. ECMQV Key Exchange and Verification Method Name 81 (ecmqv-sha2) . . . . . . . . . . . . . . . . . . . . . . . 15 82 7. Key Exchange Messages . . . . . . . . . . . . . . . . . . . . 17 83 7.1. ECDH Message Numbers . . . . . . . . . . . . . . . . . . . 17 84 7.2. ECMQV Message Numbers . . . . . . . . . . . . . . . . . . 17 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 9. Named Elliptic Curve Domain Parameters . . . . . . . . . . . . 19 87 9.1. Required Curves . . . . . . . . . . . . . . . . . . . . . 19 88 9.2. RecommendedCurves . . . . . . . . . . . . . . . . . . . . 19 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 93 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 96 1. Introduction 98 Due to its inclusion in National Security Agency's Suite B and its 99 small key sizes elliptic curve cryptography (ECC) is becoming a 100 widely utilized and attractive public-key cryptosystem. 102 In the interest of adding Suite B algorithms to SSH this document 103 adds three ECC Suite B algorithms to the Secure Shell arsenal: 104 Elliptic Curve Menezes-Qu-Vanstone (ECMQV), Elliptic Curve Diffie- 105 Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm 106 (ECDSA), as well as utilizing the SHA2 family of secure hash 107 algorithms. 109 Compared to cryptosystems such as RSA, the Digital Signature 110 Algorithm (DSA), and Diffie-Hellman (DH) key exchange, ECC variations 111 on these schemes offer equivalent security with smaller key sizes. 112 This is illustrated in the following table, based on Section 5.6.1 of 113 NIST 800-57 [NIST-800-57], which gives approximate comparable key 114 sizes for symmetric- and asymmetric-key cryptosystems based on the 115 best known algorithms for attacking them. L is field size and N is 116 sub-field size. 118 +-----------+-----------------------------+-------+---------+ 119 | Symmetric | Discrete Log (eg. DSA, DH) | RSA | ECC | 120 +-----------+-----------------------------+-------+---------+ 121 | 80 | L = 1024 N = 160 | 1024 | 160-223 | 122 | | | | | 123 | 112 | L = 2048 N = 256 | 2048 | 224-255 | 124 | | | | | 125 | 128 | L = 3072 N = 256 | 3072 | 256-383 | 126 | | | | | 127 | 192 | L = 7680 N = 384 | 7680 | 384-511 | 128 | | | | | 129 | 256 | L = 15360 N = 512 | 15360 | 512+ | 130 +-----------+-----------------------------+-------+---------+ 132 Implementation of this specification requires familiarity with both 133 SSH [RFC4251] [RFC4253] [RFC4250] and ECC [SEC1] (additional 134 information on ECC available in [IEEE1363], [ANSI-X9.62], and 135 [ANSI-X9.63]). 137 This document is concerned with SSH implementation details; 138 specification of the underlying cryptographic algorithms is left to 139 other standards documents. 141 2. Notation 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 The data types boolean, uint32, uint64, string, and mpint are to be 148 interpreted in this document as described in [RFC4251]. 150 The size of a set of elliptic curve domain parameters on a prime 151 curve is defined as the number of bits in the binary representation 152 of the field order, commonly denoted p. Size on a characteristic-2 153 curve is defined as the number of bits in the binary representation 154 of the field, commonly denoted m. A set of elliptic curve domain 155 parameters defines a group of order n generated by a base point P. 157 3. ECC Public Key Algorithm 159 The ECC public key algorithm is defined by its key format, 160 corresponding signature algorithm ECDSA, signature encoding and 161 algorithm identifiers. 163 This section defines the family of "ecdsa-sha2-*" public key formats 164 and corresponding signature formats. Every compliant SSH ECC 165 implementation MUST implement this public key format. 167 3.1. Key Format 169 The "ecdsa-sha2-*" key formats all have the following encoding: 171 string "ecdsa-sha2-[identifier]" 172 byte[n] ecc_key_blob 174 The ecc_key_blob value has the following specific encoding: 176 string [identifier] 177 string Q 179 The string [identifier] is the identifier of the elliptic curve 180 domain parameters. The format of this string is specified in 181 Section 6.1. Information on the required and recommended sets of 182 elliptic curve domain parameters for use with this algorithm can be 183 found in Section 9. 185 Q is the public key encoded from an elliptic curve point into an 186 octet string as defined in Section 2.3.3 of [SEC1]; point compression 187 MUST NOT be used. 189 The algorithm for ECC key generation can be found in Section 3.2 of 190 [SEC1]. Given some elliptic curve domain parameters, an ECC key pair 191 can be generated containing a private key, an integer d, and a public 192 key, an elliptic curve point Q. 194 3.1.1. Signature Algorithm 196 Signing and verifying is done using the Elliptic Curve Digital 197 Signature Algorithm (ECDSA). ECDSA is specified in [SEC1]. The 198 message hashing algorithm must be from the SHA2 family of hash 199 functions [FIPS-180-3] and is chosen according to the curve size as 200 specified in Section 6.2.1. 202 3.1.2. Signature Encoding 204 Signatures are encoded as follows: 206 string "ecdsa-sha2-[identifier]" 207 string ecdsa_signature_blob 209 The string [identifier] is the identifier of the elliptic curve 210 domain parameters. The format of this string is specified in 211 Section 6.1. Information on the required and recommended sets of 212 elliptic curve domain parameters for use with this algorithm can be 213 found in Section 9. 215 The ecdsa_signature_blob value has the following specific encoding: 217 mpint r 218 mpint s 220 The integers r and s are the output of the ECDSA algorithm. 222 The width of the integer fields is determined by the curve being 223 used. Note that the integers r and s are integers modulo the order 224 of the curve, which may be larger than the size of the finite field. 225 Thus, the integers r and s are encoded as octet strings each of 226 length ciel(log[2](n)/8) using Section 2.3.7 of [SEC1], where n is 227 the order of the elliptic curve group. 229 4. ECDH Key Exchange 231 The Elliptic Curve Diffie-Hellman (ECDH) key exchange method 232 generates a shared secret from an ephemeral local elliptic curve 233 private key and ephemeral remote elliptic curve public key. This key 234 exchange method provides explicit server authentication as defined in 235 [RFC4253] using a signature on the exchange hash. Every compliant 236 SSH ECC implementation MUST implement ECDH Key Exchange. 238 The primitive used for shared key generation is ECDH with cofactor 239 multiplication, the full specification of which can be found in 240 Section 3.3.2 of [SEC1]. The algorithm for key pair generation can 241 be found in Section 3.2 of [SEC1]. 243 The family of key exchange method names defined for use with this key 244 exchange can be found in Section 6.3. Algorithm negotiation chooses 245 the public key algorithm to be used for signing and the method name 246 of the key exchange. The method name of the key exchange chosen 247 determines the elliptic curve domain parameters and hash function to 248 be used in the remainder of this section. 250 Information on the required and recommended elliptic curve domain 251 parameters for use with this method can be found in Section 9. 253 All elliptic curve public keys MUST be validated after they are 254 received. An example of a validation algorithm can be found in 255 A.16.10 of [IEEE1363]. If a key fails validation the key exchange 256 MUST fail. 258 The elliptic curve public keys (points) that must be transmitted are 259 encoded into octet strings before they are transmitted. The 260 transformation between elliptic curve points and octet strings is 261 specified in Sections 2.3.3 and 2.3.4 of [SEC1]; point compression 262 MUST NOT be used. The output of shared key generation is a field 263 element xp. The ssh framework requires that the shared key be an 264 integer. The conversion between a field element and an integer is 265 specified in Section 2.3.9 of [SEC1]. 267 Specification of the message numbers SSH_MSG_KEX_ECDH_INIT and 268 SSH_MSG_KEX_ECDH_REPLY are found in Section 7. 270 The following is an overview of the key exchange process: 272 Client Server 273 ------ ------ 274 Generate ephemeral key pair. 275 SSH_MSG_KEX_ECDH_INIT --------------> 277 Verify received key is valid. 278 Generate ephemeral key pair. 279 Compute shared secret. 280 Generate and sign exchange hash. 281 <------------- SSH_MSG_KEX_ECDH_REPLY 283 Verify received key is valid. 284 *Verify host key belongs to server. 285 Compute shared secret. 286 Generate exchange hash. 287 Verify server's signature. 289 *It is recommended that the client verify that the host key sent is 290 the server's host key (using certificates or a local database). The 291 client is allowed to accept the host key without verification, but 292 doing so will render the protocol insecure against active attacks; 293 see the discussion in Section 4.1 of [RFC4251]. 295 This is implemented using the following messages. 297 The client sends: 299 byte SSH_MSG_KEX_ECDH_INIT 300 string Q_C, client's ephemeral public key octet string 302 The server responds with: 304 byte SSH_MSG_KEX_ECDH_REPLY 305 string K_S, server's public host key octet string 306 string Q_S, server's ephemeral public key octet string 307 string the signature on the exchange hash 309 The exchange hash H is computed as the hash of the concatenation of 310 the following. 312 string V_C, client's identification string (CR and LF excluded) 313 string V_S, server's identification string (CR and LF excluded) 314 string I_C, payload of the client's SSH_MSG_KEXINIT 315 string I_S, payload of the server's SSH_MSG_KEXINIT 316 string K_S, server's public host key octet string 317 string Q_C, client's ephemeral public key octet string 318 string Q_S, server's ephemeral public key octet string 319 mpint K, shared secret 321 5. ECMQV Key Exchange 323 The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange algorithm 324 generates a shared secret from two local elliptic curve key pairs and 325 two remote public keys. This key exchange method provides implicit 326 server authentication as defined in [RFC4253]. The ECMQV key 327 exchange method is OPTIONAL. 329 The key exchange method name defined for use with this key exchange 330 is "ecmqv-sha2". This method name gives a hashing algorithm that is 331 to be used for the HMAC below. Future RFCs may define new method 332 names specifying new hash algorithms for use with ECMQV. More 333 information about the method name and HMAC can be found in 334 Section 6.4. 336 In general the ECMQV key exchange is performed using the ephemeral 337 and long term key pair of both the client and server, a total of 4 338 keys. Within the framework of SSH the client does not have a long 339 term key pair that needs to be authenticated. Therefore we generate 340 an ephemeral key and use that as both the clients keys. This is more 341 efficient than using two different ephemeral keys and does not 342 adversely affect security (it is analogous to the one-pass protocol 343 in Section 6.1 of [LMQSV98]). 345 A full description of the ECMQV primitive can be found in Section 3.4 346 of [SEC1]. The algorithm for key pair generation can be found in 347 Section 3.2 of [SEC1]. 349 During algorithm negotiation with the SSH_MSG_KEXINIT messages the 350 ECMQV key exchange method can only be chosen if a Public Key 351 Algorithm supporting ECC host keys can also be chosen. This is due 352 to the use of implicit server authentication in this key exchange 353 method. This case is handled the same way that key exchange methods 354 requiring encryption/signature capable public key algorithms are 355 handled in Section 7.1 of [RFC4253]. If ECMQV key exchange is chosen 356 then the Public Key Algorithm supporting ECC host keys MUST also be 357 chosen. 359 ECMQV requires that all the keys used to generate a shared secret are 360 generated over the same elliptic curve domain parameters. Since the 361 host key is used in the generation of the shared secret, allowing for 362 implicit server authentication, the domain parameters associated with 363 the host key are used throughout this section. 365 All elliptic curve public keys MUST be validated after they are 366 received. An example of a validation algorithm can be found in 367 A.16.10 of [IEEE1363]. If a key fails validation the key exchange 368 MUST fail. 370 The elliptic curve public keys (points) that must be transmitted are 371 encoded into octet strings before they are transmitted. The 372 transformation between elliptic curve points and octet strings is 373 specified in Sections 2.3.3 and 2.3.4 of [SEC1]; point compression 374 MAY be used. The output of shared key generation is a field element 375 xp. The ssh framework requires that the shared key be an integer. 376 The conversion between a field element and an integer is specified in 377 Section 2.3.9 of [SEC1]. 379 The following is an overview of the key exchange process: 381 Client Server 382 ------ ------ 383 Generate ephemeral key pair. 384 SSH_MSG_KEX_ECMQV_INIT -------------> 386 Verify received key is valid. 387 Generate ephemeral key pair. 388 Compute shared secret. 389 Generate exchange hash and compute 390 HMAC over it using the shared secret. 391 <------------- SSH_MSG_KEX_ECMQV_REPLY 393 Verify received keys are valid. 394 *Verify host key belongs to server. 395 Compute shared secret. 396 Verify HMAC. 398 *It is recommended that the client verify that the host key sent is 399 the server's host key (Using certificates or a local database). The 400 client is allowed to accept the host key without verification, but 401 doing so will render the protocol insecure against active attacks. 403 The specification of the message numbers SSH_MSG_ECMQV_INIT and 404 SSH_MSG_ECMQV_REPLY can be found in Section 7. 406 This key exchange algorithm is implemented with the following 407 messages. 409 The client sends: 411 byte SSH_MSG_ECMQV_INIT 412 string Q_C, client's ephemeral public key octet string 414 The server sends: 416 byte SSH_MSG_ECMQV_REPLY 417 string K_S, server's public host key octet string 418 string Q_S, server's ephemeral public key octet string 419 string HMAC tag computed on H using the shared secret 421 The hash H is formed by applying the algorithm HASH on a 422 concatenation of the following: 424 string V_C, client's identification string (CR and LF excluded) 425 string V_S, server's identification string (CR and LF excluded) 426 string I_C, payload of the client's SSH_MSG_KEXINIT 427 string I_S, payload of the server's SSH_MSG_KEXINIT 428 string K_S, server's public host key octet 429 string Q_C, client's ephemeral public key octet 430 string Q_S, server's ephemeral public key octet 431 mpint K, shared secret 433 6. Method Names 435 This document defines a new family of key exchange method names, a 436 new key exchange method name, and a new family of public key 437 algorithm names in the SSH name registry. 439 6.1. Elliptic Curve Domain Parameter Identifiers 441 This section specifies identifiers encoding named elliptic curve 442 domain parameters. These identifiers are used in this document to 443 identify the curve used in the ECC public key format, the ECDSA 444 signature blob, and the ECDH method name. 446 For the REQUIRED elliptic curves nistp256, nistp384, and nistp521, 447 the elliptic curve domain parameter identifiers are the strings 448 "nistp256", "nistp384", and "nistp521". 450 For all other elliptic curves, including all other NIST curves and 451 all other RECOMMENDED curves, the elliptic curve domain parameter 452 identifier is the ASCII representation of the Abstract Syntax 453 Notation One (ASN.1) [ASN1] Object Identifier (OID) of the named 454 curve domain parameters that are associated with the server's ECC 455 host keys, provided that the concatenation of the public key format 456 identifier and the elliptic curve domain parameter identifer (or the 457 method name and the elliptic curve domain parameter identifier) does 458 not exceed the maximum specified by the SSH Protocol Architecture 459 [RFC4251], namely 64 characters; otherwise the identifier for that 460 curve is undefined and the curve is not supported by this 461 specification. 463 A list of the REQUIRED and RECOMMENDED curves and their OIDs can be 464 found in Section 9. 466 Note that implementations MUST use the string identifiers for the 467 three REQUIRED NIST curves, even when an OID exists for that curve. 469 6.2. ECC Public Key Algorithm (ecdsa-sha2-*) 471 The ECC Public Key Algorithm is specified by a family of public key 472 format identifiers. Each identifer is the concatenation of the 473 string "ecdsa-sha2-" with the elliptic curve domain parameter 474 identifier as defined in Section 6.1. A list of the required and 475 recommended curves and their OIDs can be found in Section 9. 477 For example: The method name for ECDH key exchange with ephemeral 478 keys generated on the nistp256 curve would be "ecdsa-sha2-nistp256". 480 6.2.1. Elliptic Curve Digital Signature Algorithm 482 The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified 483 for use with the ECC Public Key Algorithm. 485 The hashing algorithm defined by this family of method names is the 486 SHA2 family of hashing algorithms [FIPS-180-3]. The algorithm from 487 the SHA2 family that will be used is chosen based on the size of the 488 named curve specified in the public key: 490 +----------------+----------------+ 491 | Curve Size | Hash Algorithm | 492 +----------------+----------------+ 493 | b <= 256 | SHA-256 | 494 | | | 495 | 256 < b <= 384 | SHA-384 | 496 | | | 497 | 384 < b | SHA-512 | 498 +----------------+----------------+ 500 6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) 502 The Elliptic Curve Diffie-Hellman key exchange is defined by a family 503 of method names. Each method name is the concatenation of the string 504 "ecdh-sha2-" with the elliptic curve domain parameter identifier as 505 defined in Section 6.1. A list of the required and recommended 506 curves and their OIDs can be found in Section 9. 508 For example: The method name for ECDH key exchange with ephemeral 509 keys generated on the sect409k1 curve would be "ecdh-sha2- 510 1.3.132.0.36". 512 The hashing algorithm defined by this family of method names is the 513 SHA2 family of hashing algorithms [FIPS-180-3]. The hashing 514 algorithm is defined in the method name to allow room for other 515 algorithms to be defined in future documents. The algorithm from the 516 SHA2 family that will be used is chosen based on the size of the 517 named curve specified in the method name according to the table in 518 Section 6.2.1. 520 The concatenation of any so encoded ASN.1 OID specifying a set of 521 elliptic curve domain parameters with "ecdh-sha2-" is implicitly 522 registered under this specification. 524 6.4. ECMQV Key Exchange and Verification Method Name (ecmqv-sha2) 526 The Elliptic Curve Menezes-Qu-Vanstone key exchange is defined by the 527 method name "ecmqv-sha2". Unlike the ECDH key exchange method, ECMQV 528 relies on a public key algorithm that uses ECC keys: it does not need 529 a family of method names because the curve information can be gained 530 from the public key algorithm. 532 The hashing and message authentication code algorithms are defined by 533 the method name to allow room for other algorithms to be defined for 534 use with ECMQV in future documents. 536 The hashing algorithm defined by this method name is the SHA2 family 537 of hashing algorithms [FIPS-180-3]. The algorithm from the SHA2 538 family that will be used is chosen based on the size of the named 539 curve specified for use with ECMQV by the chosen public key algorithm 540 according to the table in Section 6.2.1. 542 The keyed-hash message authentication code that is used to identify 543 the server and verify communications is based on the hash chosen 544 above. The information on implementing the HMAC based on the chosen 545 hash algorithm can be found in [RFC2104]. 547 7. Key Exchange Messages 549 The message numbers 30-49 are key exchange-specific and in a private 550 namespace defined in [RFC4250] that may be redefined by any key 551 exchange method [RFC4253] without being granted IANA permission. 553 The following message numbers have been defined in this document: 555 7.1. ECDH Message Numbers 557 #define SSH_MSG_KEX_ECDH_INIT 30 558 #define SSH_MSG_KEX_ECDH_REPLY 31 560 7.2. ECMQV Message Numbers 562 #define SSH_MSG_ECMQV_INIT 30 563 #define SSH_MSG_ECMQV_REPLY 31 565 8. Security Considerations 567 The Elliptic Curve Diffie-Hellman key agreement algorithm is defined 568 in [SEC1]. The appropriate security considerations of that document 569 apply. 571 The Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm is 572 defined in [SEC1]. The security considerations raised in that 573 document also apply. A more detailed discussion of security 574 considerations can be found in Section 4.7 of the Guide to Elliptic 575 Curve Cryptography [HMV04]. 577 The server's host key is used in the ECMQV key exchange algorithm. 578 This means that the strength of the server's ECC host key determines 579 the strength of the ECMQV key exchange algorithm. This should be 580 taken into consideration when generating ECC keys for a server. 582 The methods defined in Section 6 rely on the SHA2 family of hashing 583 functions as defined in [FIPS-180-3]. The appropriate security 584 considerations of that document apply. 586 The hashing algorithms defined for use with ECDH and ECMQV are 587 defined by their method names so that if security problems are found 588 with the SHA2 family of hashing algorithms or more secure hashing 589 algorithms become the standard then future documents can extend this 590 document to include new hashing algorithms by defining new method 591 names. 593 Additionally a good general discussion of the security considerations 594 that must be taken into account when creating an ECC implementation 595 can be found in Section 5 of the Guide to Elliptic Curve Cryptography 596 [HMV04]. 598 Since ECDH and ECMQV allow for elliptic curves of arbitrary sizes and 599 thus arbitrary security strength, it is important that the size of 600 elliptic curve be chosen to match the security strength of other 601 elements of the SSH handshake. In particular, host key sizes, 602 hashing algorithms and bulk encryption algorithms must be chosen 603 appropriately. Information regarding estimated equivalence of key 604 sizes is available in [NIST-800-57]; the discussion in [RFC3766] is 605 also relevant. We note in particular that when ECDSA is used as the 606 signature algorithm and ECDH is used as the key exchange method, if 607 curves of different sizes are used, then it is possible that 608 different hash functions from the SHA2 family could be used. 610 9. Named Elliptic Curve Domain Parameters 612 Implementations MAY support any ASN.1 object identifier (OID) in the 613 ASN.1 object tree that defines a set of elliptic curve domain 614 parameters [ASN1]. 616 9.1. Required Curves 618 Every SSH ECC implementation MUST support the named curves below. 619 These curves are defined in [SEC2]; the NIST curves were originally 620 defined in [NIST-CURVES]. These curves should always be enabled 621 unless specifically disabled by local security policy. 623 +----------+-----------+---------------------+ 624 | NIST* | SEC | OID | 625 +----------+-----------+---------------------+ 626 | nistp256 | secp256r1 | 1.2.840.10045.3.1.7 | 627 | | | | 628 | nistp384 | secp384r1 | 1.3.132.0.34 | 629 | | | | 630 | nistp521 | secp521r1 | 1.3.132.0.35 | 631 +----------+-----------+---------------------+ 633 * For these three REQUIRED curves, the elliptic curve domain 634 parameter identifier is the string in the first column of the table, 635 the NIST name of the curve. (See Section 6.1.) 637 9.2. RecommendedCurves 639 It is RECOMMENDED that SSH ECC implementations also support the 640 following curves. These curves are defined in [SEC2]. 642 +----------+-----------+---------------------+ 643 | NIST | SEC | OID* | 644 +----------+-----------+---------------------+ 645 | nistk163 | sect163k1 | 1.3.132.0.1 | 646 | | | | 647 | nistp192 | secp192r1 | 1.2.840.10045.3.1.1 | 648 | | | | 649 | nistp224 | secp224r1 | 1.3.132.0.33 | 650 | | | | 651 | nistk233 | sect233k1 | 1.3.132.0.26 | 652 | | | | 653 | nistb233 | sect233r1 | 1.3.132.0.27 | 654 | | | | 655 | nistk283 | sect283k1 | 1.3.132.0.16 | 656 | | | | 657 | nistk409 | sect409k1 | 1.3.132.0.36 | 658 | | | | 659 | nistb409 | sect409r1 | 1.3.132.0.37 | 660 | | | | 661 | nistt571 | sect571k1 | 1.3.132.0.38 | 662 +----------+-----------+---------------------+ 664 * For these RECOMMENDED curves, the elliptic curve domain parameter 665 identifier is the string in the third column of the table, the ASCII 666 representation of the OID of the curve. (See Section 6.1.) 668 10. IANA Considerations 670 Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], 671 this document makes the following registrations: 673 The family of SSH public key algorithm names beginning with "ecdsa- 674 sha2-" and not containing the at-sign ('@'), to name the public key 675 algorithms defined in Section 3. 677 The family of SSH key exchange method names beginning with "ecdh- 678 sha2-" and not containing the at-sign ('@'), to name the key exchange 679 methods defined in Section 4. 681 The SSH key exchange method name "ecmqv-sha2" to name the key 682 exchange method defined in Section 5. 684 This document creates no new registries. 686 11. References 688 11.1. Normative References 690 [ASN1] International Telecommunications Union, "Abstract Syntax 691 Notation One (ASN.1): Specification of basic notation", 692 X.680, July 2002. 694 [FIPS-180-3] 695 National Institute of Standards and Technology, "Secure 696 Hash Standard", FIPS 180-3, October 2008. 698 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 699 Hashing for Message Authentication", RFC 2104, 700 February 1997. 702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, March 1997. 705 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 706 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 707 RFC 3766, April 2004. 709 [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) 710 Protocol Assigned Numbers", RFC 4250, January 2006. 712 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 713 Protocol Architecture", RFC 4251, January 2006. 715 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 716 Transport Layer Protocol", RFC 4253, January 2006. 718 [SEC1] Standards for Efficient Cryptography Group, "Elliptic 719 Curve Cryptography", SEC 1, September 2000, 720 . 722 [SEC2] Standards for Efficient Cryptography Group, "Recommended 723 Elliptic Curve Domain Parameters", SEC 2, September 2000, 724 . 726 11.2. Informative References 728 [ANSI-X9.62] 729 American National Standards Institute, "Public Key 730 Cryptography For The Financial Services Industry: The 731 Elliptic Curve Digital Signature Algorithm (ECDSA)", 732 ANSI X9.62, 1998. 734 [ANSI-X9.63] 735 American National Standards Institute, "Public Key 736 Cryptography For The Financial Services Industry: Key 737 Agreement and Key Transport Using Elliptic Curve 738 Cryptography", ANSI X9.63, January 1999. 740 [HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to 741 Elliptic Curve Cryptography", 2004. 743 Springer, ISBN 038795273X 745 [IEEE1363] 746 Institute of Electrical and Electronics Engineers, 747 "Standard Specifications for Public Key Cryptography", 748 IEEE 1363, 2000. 750 [LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S. 751 Vanstone, "An Efficient Protocol for Authenticated Key 752 Agreement", University of Waterloo Technical Report 753 CORR 98-05, August 1998, . 757 [NIST-800-57] 758 National Institute of Standards and Technology, 759 "Recommendation for Key Management - Part 1: General 760 (Revised)", NIST Special Publication 800-57, March 2007, < 761 http://csrc.nist.gov/publications/nistpubs/800-57/ 762 sp800-57-Part1-revised2_Mar08-2007.pdf>. 764 [NIST-CURVES] 765 National Institute of Standards and Technology, 766 "Recommended Elliptic Curves for Federal Government Use", 767 August 1999, 768 . 770 Appendix A. Acknowledgements 772 The authors acknowledge helpful comments from James Blaisdell, Alfred 773 Hoenes, Russ Housley, Jeffrey Hutzelman, Rob Lambert, Jan Pechanek, 774 Tim Polk, and members of the ietf-ssh@netbsd.org mailing list. 776 Authors' Addresses 778 Douglas Stebila 779 Queensland University of Technology 780 Information Security Institute 781 Level 7, 126 Margaret St 782 Brisbane, Queensland 4000 783 Australia 785 Email: douglas@stebila.ca 787 Jon Green 788 Queen's University 789 Parallel Processing Research Laboratory 790 Department of Electrical and Computer Engineering 791 Room 614, Walter Light Hall 792 Kingston, Ontario K7L 3N6 793 Canada 795 Email: jon.green@ece.queensu.ca