One document matched: draft-green-secsh-ecc-09.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2104 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3766 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3766.xml'>
<!ENTITY rfc4250 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4250.xml'>
<!ENTITY rfc4251 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml'>
<!ENTITY rfc4253 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml'>
]>
<rfc category="std" ipr="pre5378Trust200902" docName="draft-green-secsh-ecc-09">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<front>
<title abbrev="SSH ECC Algorithm Integration">Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer</title>
<author initials="D." surname="Stebila" fullname="Douglas Stebila">
<organization>Queensland University of Technology</organization>
<address>
<postal>
<street>Information Security Institute</street>
<street>Level 7, 126 Margaret St</street>
<city>Brisbane</city> <region>Queensland</region>
<code>4000</code>
<country>Australia</country>
</postal>
<email>douglas@stebila.ca</email>
</address>
</author>
<author initials="J." surname="Green" fullname="Jon Green">
<organization>Queen's University</organization>
<address>
<postal>
<street>Parallel Processing Research Laboratory</street>
<street>Department of Electrical and Computer Engineering</street>
<street>Room 614, Walter Light Hall</street>
<city>Kingston</city> <region>Ontario</region>
<code>K7L 3N6</code>
<country>Canada</country>
</postal>
<email>jon.green@ece.queensu.ca</email>
</address>
</author>
<date month="August" day="29" year="2009" />
<area>Security</area>
<workgroup>Network Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Elliptic Curve Cryptography (ECC)</keyword>
<keyword>Secure Shell (SSH)</keyword>
<abstract><t>This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol.</t></abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This document adds elliptic curve cryptography algorithms to the Secure Shell arsenal: Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA), as well as utilizing the SHA2 family of secure hash algorithms. Additionally, support is provided for Elliptic Curve Menezes-Qu-Vanstone (ECMQV).</t>
<t>Due to its small key sizes and its inclusion in the National Security Agency's Suite B, elliptic curve cryptography (ECC) is becoming a widely utilized and attractive public-key cryptosystem.</t>
<t>Compared to cryptosystems such as RSA, the Digital Signature Algorithm (DSA), and Diffie-Hellman (DH) key exchange, ECC variations on these schemes offer equivalent security with smaller key sizes. This is illustrated in the following table, based on Section 5.6.1 of NIST 800-57 <xref target="NIST-800-57" />, which gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best known algorithms for attacking them. L is field size and N is sub-field size.</t>
<texttable>
<ttcol align="center">Symmetric</ttcol>
<ttcol align="center">Discrete Log (eg. DSA, DH)</ttcol>
<ttcol align="center">RSA</ttcol>
<ttcol align="center">ECC</ttcol>
<c>80</c> <c>L = 1024 N = 160</c> <c>1024</c> <c>160-223</c>
<c>112</c> <c>L = 2048 N = 256</c> <c>2048</c> <c>224-255</c>
<c>128</c> <c>L = 3072 N = 256</c> <c>3072</c> <c>256-383</c>
<c>192</c> <c>L = 7680 N = 384</c> <c>7680</c> <c>384-511</c>
<c>256</c> <c>L = 15360 N = 512</c> <c>15360</c> <c>512+</c>
</texttable>
<t>Implementation of this specification requires familiarity with both SSH <xref target="RFC4251" /> <xref target="RFC4253" /> <xref target="RFC4250" /> and ECC <xref target="SEC1" /> (additional information on ECC available in <xref target="HMV04" />, <xref target="IEEE1363" />, <xref target="ANSI-X9.62" />, and <xref target="ANSI-X9.63" />).</t>
<t>This document is concerned with SSH implementation details; specification of the underlying cryptographic algorithms is left to other standards documents.</t>
</section>
<section anchor="notation" title="Notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
<t>The data types boolean, uint32, uint64, string, and mpint are to be interpreted in this document as described in <xref target="RFC4251" />.</t>
<t>The size of a set of elliptic curve domain parameters on a prime curve is defined as the number of bits in the binary representation of the field order, commonly denoted p. Size on a characteristic-2 curve is defined as the number of bits in the binary representation of the field, commonly denoted m. A set of elliptic curve domain parameters defines a group of order n generated by a base point P.</t>
</section>
<section anchor="ecc" title="ECC Public Key Algorithm">
<t>The ECC public key algorithm is defined by its key format, corresponding signature algorithm ECDSA, signature encoding and algorithm identifiers.</t>
<t>This section defines the family of "ecdsa-sha2-*" public key formats and corresponding signature formats. Every compliant SSH ECC implementation MUST implement this public key format.</t>
<section anchor="ecc-key-format" title="Key Format">
<t>The "ecdsa-sha2-*" key formats all have the following encoding:</t>
<figure>
<artwork>
string "ecdsa-sha2-[identifier]"
byte[n] ecc_key_blob</artwork>
</figure>
<t>The ecc_key_blob value has the following specific encoding:</t>
<figure>
<artwork>
string [identifier]
string Q</artwork>
</figure>
<t>The string [identifier] is the identifier of the elliptic curve domain parameters. The format of this string is specified in <xref target="names-curveid" />. Information on the required and recommended sets of elliptic curve domain parameters for use with this algorithm can be found in <xref target="params" />.</t>
<t>Q is the public key encoded from an elliptic curve point into an octet string as defined in Section 2.3.3 of <xref target="SEC1" />; point compression MAY be used.</t>
<t>The algorithm for ECC key generation can be found in Section 3.2 of <xref target="SEC1" />. Given some elliptic curve domain parameters, an ECC key pair can be generated containing a private key, an integer d, and a public key, an elliptic curve point Q.</t>
<section anchor="ecc-sig-alg" title="Signature Algorithm">
<t>Signing and verifying is done using the Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA is specified in <xref target="SEC1" />. The message hashing algorithm MUST be from the SHA2 family of hash functions <xref target="FIPS-180-3" /> and is chosen according to the curve size as specified in <xref target="names-ecdsa" />.</t>
</section>
<section anchor="ecc-sig-enc" title="Signature Encoding">
<t>Signatures are encoded as follows:</t>
<figure>
<artwork>
string "ecdsa-sha2-[identifier]"
string ecdsa_signature_blob</artwork>
</figure>
<t>The string [identifier] is the identifier of the elliptic curve domain parameters. The format of this string is specified in <xref target="names-curveid" />. Information on the required and recommended sets of elliptic curve domain parameters for use with this algorithm can be found in <xref target="params" />.</t>
<t>The ecdsa_signature_blob value has the following specific encoding:</t>
<figure>
<artwork>
mpint r
mpint s</artwork>
</figure>
<t>The integers r and s are the output of the ECDSA algorithm.</t>
<t>The width of the integer fields is determined by the curve being used. Note that the integers r and s are integers modulo the order of the cryptographic subgroup, which may be larger than the size of the finite field.</t>
</section>
</section>
</section>
<section anchor="ecdh" title="ECDH Key Exchange">
<t>The Elliptic Curve Diffie-Hellman (ECDH) key exchange method generates a shared secret from an ephemeral local elliptic curve private key and ephemeral remote elliptic curve public key. This key exchange method provides explicit server authentication as defined in <xref target="RFC4253" /> using a signature on the exchange hash. Every compliant SSH ECC implementation MUST implement ECDH Key Exchange.</t>
<t>The primitive used for shared key generation is ECDH with cofactor multiplication, the full specification of which can be found in Section 3.3.2 of <xref target="SEC1" />. The algorithm for key pair generation can be found in Section 3.2 of <xref target="SEC1" />.</t>
<t>The family of key exchange method names defined for use with this key exchange can be found in <xref target="names-ecdh" />. Algorithm negotiation chooses the public key algorithm to be used for signing and the method name of the key exchange. The method name of the key exchange chosen determines the elliptic curve domain parameters and hash function to be used in the remainder of this section.</t>
<t>Information on the required and recommended elliptic curve domain parameters for use with this method can be found in <xref target="params" />.</t>
<t>All elliptic curve public keys MUST be validated after they are received. An example of a validation algorithm can be found in A.16.10 of <xref target="IEEE1363" />. If a key fails validation the key exchange MUST fail.</t>
<t>The elliptic curve public keys (points) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in Sections 2.3.3 and 2.3.4 of <xref target="SEC1" />; point compression MAY be used. The output of shared key generation is a field element xp. The SSH framework requires that the shared key be an integer. The conversion between a field element and an integer is specified in Section 2.3.9 of <xref target="SEC1" />.</t>
<t>Specification of the message numbers SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY are found in <xref target="msgs" />.</t>
<figure>
<preamble>The following is an overview of the key exchange process:</preamble>
<artwork>
Client Server
------ ------
Generate ephemeral key pair.
SSH_MSG_KEX_ECDH_INIT -------------->
Verify received key is valid.
Generate ephemeral key pair.
Compute shared secret.
Generate and sign exchange hash.
<------------- SSH_MSG_KEX_ECDH_REPLY
Verify received key is valid.
*Verify host key belongs to server.
Compute shared secret.
Generate exchange hash.
Verify server's signature.</artwork>
</figure>
<t>*It is recommended that the client verify that the host key sent is the server's host key (for example, using a local database). The client is allowed to accept the host key without verification, but doing so will render the protocol insecure against active attacks; see the discussion in Section 4.1 of <xref target="RFC4251" />.</t>
<t>This is implemented using the following messages.</t>
<figure>
<preamble>The client sends:</preamble>
<artwork>
byte SSH_MSG_KEX_ECDH_INIT
string Q_C, client's ephemeral public key octet string</artwork>
</figure>
<figure>
<preamble>The server responds with:</preamble>
<artwork>
byte SSH_MSG_KEX_ECDH_REPLY
string K_S, server's public host key
string Q_S, server's ephemeral public key octet string
string the signature on the exchange hash</artwork>
</figure>
<figure>
<preamble>The exchange hash H is computed as the hash of the concatenation of the following.</preamble>
<artwork>
string V_C, client's identification string (CR and LF excluded)
string V_S, server's identification string (CR and LF excluded)
string I_C, payload of the client's SSH_MSG_KEXINIT
string I_S, payload of the server's SSH_MSG_KEXINIT
string K_S, server's public host key
string Q_C, client's ephemeral public key octet string
string Q_S, server's ephemeral public key octet string
mpint K, shared secret</artwork>
</figure>
</section>
<section anchor="ecmqv" title="ECMQV Key Exchange">
<t>The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange algorithm generates a shared secret from two local elliptic curve key pairs and two remote public keys. This key exchange method provides implicit server authentication as defined in <xref target="RFC4253" />. The ECMQV key exchange method is OPTIONAL.</t>
<t>The key exchange method name defined for use with this key exchange is "ecmqv-sha2". This method name gives a hashing algorithm that is to be used for the HMAC below. Future RFCs may define new method names specifying new hash algorithms for use with ECMQV. More information about the method name and HMAC can be found in <xref target="names-ecmqv" />.</t>
<t>In general the ECMQV key exchange is performed using the ephemeral and long term key pair of both the client and server, a total of 4 keys. Within the framework of SSH the client does not have a long term key pair that needs to be authenticated. Therefore we generate an ephemeral key and use that as both the clients keys. This is more efficient than using two different ephemeral keys and does not adversely affect security (it is analogous to the one-pass protocol in Section 6.1 of <xref target="LMQSV98" />).</t>
<t>A full description of the ECMQV primitive can be found in Section 3.4 of <xref target="SEC1" />. The algorithm for key pair generation can be found in Section 3.2 of <xref target="SEC1" />.</t>
<t>During algorithm negotiation with the SSH_MSG_KEXINIT messages the ECMQV key exchange method can only be chosen if a Public Key Algorithm supporting ECC host keys can also be chosen. This is due to the use of implicit server authentication in this key exchange method. This case is handled the same way that key exchange methods requiring encryption/signature capable public key algorithms are handled in Section 7.1 of <xref target="RFC4253" />. If ECMQV key exchange is chosen then the Public Key Algorithm supporting ECC host keys MUST also be chosen.</t>
<t>ECMQV requires that all the keys used to generate a shared secret are generated over the same elliptic curve domain parameters. Since the host key is used in the generation of the shared secret, allowing for implicit server authentication, the domain parameters associated with the host key are used throughout this section.</t>
<t>All elliptic curve public keys MUST be validated after they are received. An example of a validation algorithm can be found in A.16.10 of <xref target="IEEE1363" />. If a key fails validation the key exchange MUST fail.</t>
<t>The elliptic curve ephemeral public keys (points) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in Sections 2.3.3 and 2.3.4 of <xref target="SEC1" />; point compression MAY be used. The output of shared key generation is a field element xp. The SSH framework requires that the shared key be an integer. The conversion between a field element and an integer is specified in Section 2.3.9 of <xref target="SEC1" />.</t>
<figure>
<preamble>The following is an overview of the key exchange process:</preamble>
<artwork>
Client Server
------ ------
Generate ephemeral key pair.
SSH_MSG_KEX_ECMQV_INIT ------------->
Verify received key is valid.
Generate ephemeral key pair.
Compute shared secret.
Generate exchange hash and compute
HMAC over it using the shared secret.
<------------- SSH_MSG_KEX_ECMQV_REPLY
Verify received keys are valid.
*Verify host key belongs to server.
Compute shared secret.
Verify HMAC.</artwork>
</figure>
<t>*It is recommended that the client verify that the host key sent is the server's host key (for example, using a local database). The client is allowed to accept the host key without verification, but doing so will render the protocol insecure against active attacks.</t>
<t>The specification of the message numbers SSH_MSG_ECMQV_INIT and SSH_MSG_ECMQV_REPLY can be found in <xref target="msgs" />.</t>
<t>This key exchange algorithm is implemented with the following messages.</t>
<figure>
<preamble>The client sends:</preamble>
<artwork>
byte SSH_MSG_ECMQV_INIT
string Q_C, client's ephemeral public key octet string</artwork>
</figure>
<figure>
<preamble>The server sends:</preamble>
<artwork>
byte SSH_MSG_ECMQV_REPLY
string K_S, server's public host key
string Q_S, server's ephemeral public key octet string
string HMAC tag computed on H using the shared secret</artwork>
</figure>
<figure>
<preamble>The hash H is formed by applying the algorithm HASH on a concatenation of the following:</preamble>
<artwork>
string V_C, client's identification string (CR and LF excluded)
string V_S, server's identification string (CR and LF excluded)
string I_C, payload of the client's SSH_MSG_KEXINIT
string I_S, payload of the server's SSH_MSG_KEXINIT
string K_S, server's public host key
string Q_C, client's ephemeral public key octet
string Q_S, server's ephemeral public key octet
mpint K, shared secret</artwork>
</figure>
</section>
<section anchor="names" title="Method Names">
<t>This document defines a new family of key exchange method names, a new key exchange method name, and a new family of public key algorithm names in the SSH name registry.</t>
<section anchor="names-curveid" title="Elliptic Curve Domain Parameter Identifiers">
<t>This section specifies identifiers encoding named elliptic curve domain parameters. These identifiers are used in this document to identify the curve used in the ECC public key format, the ECDSA signature blob, and the ECDH method name.</t>
<t>For the REQUIRED elliptic curves nistp256, nistp384, and nistp521, the elliptic curve domain parameter identifiers are the strings "nistp256", "nistp384", and "nistp521".</t>
<t>For all other elliptic curves, including all other NIST curves and all other RECOMMENDED curves, the elliptic curve domain parameter identifier is the ASCII period-separated decimal representation of the Abstract Syntax Notation One (ASN.1) <xref target="ASN1" /> Object Identifier (OID) of the named curve domain parameters that are associated with the server's ECC host keys. This identifier is defined provided that the concatenation of the public key format identifier and the elliptic curve domain parameter identifer (or the method name and the elliptic curve domain parameter identifier) does not exceed the maximum specified by the SSH Protocol Architecture <xref target="RFC4251" />, namely 64 characters; otherwise the identifier for that curve is undefined and the curve is not supported by this specification.</t>
<t>A list of the REQUIRED and RECOMMENDED curves and their OIDs can be found in <xref target="params" />.</t>
<t>Note that implementations MUST use the string identifiers for the three REQUIRED NIST curves, even when an OID exists for that curve.</t>
</section>
<section anchor="names-pubkey" title="ECC Public Key Algorithm (ecdsa-sha2-*)">
<t>The ECC Public Key Algorithm is specified by a family of public key format identifiers. Each identifer is the concatenation of the string "ecdsa-sha2-" with the elliptic curve domain parameter identifier as defined in <xref target="names-curveid" />. A list of the required and recommended curves and their OIDs can be found in <xref target="params" />.</t>
<t>For example: The method name for ECDH key exchange with ephemeral keys generated on the nistp256 curve would be "ecdsa-sha2-nistp256".</t>
<section anchor="names-ecdsa" title="Elliptic Curve Digital Signature Algorithm">
<t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified for use with the ECC Public Key Algorithm.</t>
<t>The hashing algorithm defined by this family of method names is the SHA2 family of hashing algorithms <xref target="FIPS-180-3" />. The algorithm from the SHA2 family that will be used is chosen based on the size of the named curve specified in the public key:</t>
<texttable>
<ttcol align="center">Curve Size</ttcol>
<ttcol align="center">Hash Algorithm</ttcol>
<c>b <= 256</c> <c>SHA-256</c>
<c>256 < b <= 384</c> <c>SHA-384</c>
<c>384 < b</c> <c>SHA-512</c>
</texttable>
</section>
</section>
<section anchor="names-ecdh" title="ECDH Key Exchange Method Names (ecdh-sha2-*)">
<t>The Elliptic Curve Diffie-Hellman key exchange is defined by a family of method names. Each method name is the concatenation of the string "ecdh-sha2-" with the elliptic curve domain parameter identifier as defined in <xref target="names-curveid" />. A list of the required and recommended curves and their OIDs can be found in <xref target="params" />.</t>
<t>For example: The method name for ECDH key exchange with ephemeral keys generated on the sect409k1 curve would be "ecdh-sha2-1.3.132.0.36".</t>
<t>The hashing algorithm defined by this family of method names is the SHA2 family of hashing algorithms <xref target="FIPS-180-3" />. The hashing algorithm is defined in the method name to allow room for other algorithms to be defined in future documents. The algorithm from the SHA2 family that will be used is chosen based on the size of the named curve specified in the method name according to the table in <xref target="names-ecdsa" />.</t>
<t>The concatenation of any so encoded ASN.1 OID specifying a set of elliptic curve domain parameters with "ecdh-sha2-" is implicitly registered under this specification.</t>
</section>
<section anchor="names-ecmqv" title="ECMQV Key Exchange and Verification Method Name (ecmqv-sha2)">
<t>The Elliptic Curve Menezes-Qu-Vanstone key exchange is defined by the method name "ecmqv-sha2". Unlike the ECDH key exchange method, ECMQV relies on a public key algorithm that uses ECC keys: it does not need a family of method names because the curve information can be gained from the public key algorithm.</t>
<t>The hashing and message authentication code algorithms are defined by the method name to allow room for other algorithms to be defined for use with ECMQV in future documents.</t>
<t>The hashing algorithm defined by this method name is the SHA2 family of hashing algorithms <xref target="FIPS-180-3" />. The algorithm from the SHA2 family that will be used is chosen based on the size of the named curve specified for use with ECMQV by the chosen public key algorithm according to the table in <xref target="names-ecdsa" />.</t>
<t>The keyed-hash message authentication code that is used to identify the server and verify communications is based on the hash chosen above. The information on implementing the HMAC based on the chosen hash algorithm can be found in <xref target="RFC2104" />.</t>
</section>
</section>
<section anchor="msgs" title="Key Exchange Messages">
<t>The message numbers 30-49 are key exchange-specific and in a private namespace defined in <xref target="RFC4250" /> that may be redefined by any key exchange method <xref target="RFC4253" /> without requiring an IANA registration process.</t>
<t>The following message numbers have been defined in this document:</t>
<section anchor="msgs-ecdh" title="ECDH Message Numbers">
<figure>
<artwork>
#define SSH_MSG_KEX_ECDH_INIT 30
#define SSH_MSG_KEX_ECDH_REPLY 31</artwork>
</figure>
</section>
<section anchor="msgs-ecmqv" title="ECMQV Message Numbers">
<figure>
<artwork>
#define SSH_MSG_ECMQV_INIT 30
#define SSH_MSG_ECMQV_REPLY 31</artwork>
</figure>
</section>
</section>
<section anchor="manageability" title="Manageability Considerations">
<t>As this document only provides new public key algorithms and key exchange methods within the existing Secure Shell protocol architecture, there are few manageability considerations beyond those that apply for existing Secure Shell implementations. Additional manageability considerations are listed below.</t>
<section anchor="manageability-control" title="Control of Function Through Configuration and Policy">
<t><xref target="params" /> specifies REQUIRED and RECOMMENDED elliptic curve domain parameters to be used with the public key algorithms and key exchange methods defined in this document. Implementers SHOULD allow system administrators to disable some curves, including REQUIRED or RECOMMENDED curves, to meet local security policy.</t>
</section>
<section anchor="manageability-impact" title="Impact on Network Operation">
<t>As this document provides new functionality within the Secure Shell protocol architecture, the only impact on network operations is the impact on existing Secure Shell implementations. The Secure Shell protocol provides negotiation mechanisms for public key algorithms and key exchange methods: any implementations that do not recognize the algorithms and methods defined in this document will ignore them in the negotiation and use the next mutually supported algorithm or method, causing no negative impact on backward compatibility.</t>
<t>The use of elliptic curve cryptography should not place a significant computational burden on an implementing server. In fact, due to its smaller key sizes, elliptic curve cryptography can be implemented more efficiently for the same security level than RSA, finite field Diffie-Hellman, or DSA.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>This document provides new public key algorithms and new key agreement methods for the Secure Shell protocol. For the most part, the security considerations involved in using the Secure Shell protocol apply. Additionally, implementers should be aware of security considerations specific to elliptic curve cryptography.</t>
<t>For all three classes of functionality added by this document -- the public key algorithms involving ECDSA, key exchange involving ECDH, and authenticated key exchange involving ECMQV -- the current best known technique for breaking the cryptosystems is by solving the elliptic curve discrete logarithm problem (ECDLP).</t>
<t>The difficulty of breaking the ECDLP depends on the size and quality of the elliptic curve parameters. Certain types of curves can be more susceptible to known attacks than others. For example, curves over finite fields GF(2^m), where m is composite, may be susceptible to an attack based on the Weil descent. All of the RECOMMENDED curves in <xref target="params" /> do not have this problem. System administrators should be cautious when enabling curves other than the ones specified in <xref target="params" /> and should make a more detailed investigation into the security of the curve in question.</t>
<t>It is believed (see for example Section B.2.1 of <xref target="SEC1" />) that when curve parameters are generated at random the curves will be resistant to special attacks, and must rely on the most general attacks. The REQUIRED curves in <xref target="params" /> were all generated verifiably pseudorandomly. The runtime of general attacks depends on the algorithm used. At present, the best known algorithm is the Pollard-rho method. (Shor's algorithm for quantum computers can solve the ECDLP in polynomial time, but at present large-scale quantum computers have not been constructed and significant experimental physics and engineering work needs to be done before large-scale quantum computers can be constructed. There is no solid estimate as to when this may occur, but it is widely believed to be at least 20 years from the present.)</t>
<t>Based on projections of computation power, it is possible to estimate the running time of the best known attacks based on the size of the finite field. The table in <xref target="intro" /> gives an estimate of the equivalence between elliptic curve field size and symmetric key size. Roughly speaking, an N-bit elliptic curve offers the same security as an N/2-bit symmetric cipher, so a 256-bit elliptic curve (such as the REQUIRED nistp256 curve) is suitable for use with 128-bit AES, for example.</t>
<t>Many estimates consider that 2^80-2^90 operations are beyond feasible, so that would suggest using elliptic curves of at least 160-180 bits. The REQUIRED curves in this documents are 256-, 384-, and 521-bit curves; implementations SHOULD NOT use curves smaller than 160 bits.</t>
<t>A detailed discussion on the security considerations of elliptic curve domain parameters and the ECDH, ECDSA, and ECMQV algorithms can be found in Appendix B of <xref target="SEC1" />.</t>
<t>Additionally, the key exchange methods defined in this document rely on the SHA2 family of hash functions, defined in <xref target="FIPS-180-3" />. The appropriate security considerations of that document apply. Although some weaknesses have been discovered in the predecessor, SHA-1, no weaknesses in the SHA2 family are known at present. The SHA2 family consists of four variants -- SHA-224, SHA-256, SHA-384, and SHA-521 -- named after their digest lengths. In the absence of special purpose attacks exploiting the specific structure of the hash function, the difficulty of finding collisions, preimages, and second preimages for the hash function is related to the digest length. This document specifies in <xref target="names-ecdsa" /> which SHA2 variant should be used with which elliptic curve size based on this guidance.</t>
<t>Since ECDH and ECMQV allow for elliptic curves of arbitrary sizes and thus arbitrary security strength, it is important that the size of elliptic curve be chosen to match the security strength of other elements of the SSH handshake. In particular, host key sizes, hashing algorithms and bulk encryption algorithms must be chosen appropriately. Information regarding estimated equivalence of key sizes is available in <xref target="NIST-800-57" />; the discussion in <xref target="RFC3766" /> is also relevant. We note in particular that when ECDSA is used as the signature algorithm and ECDH is used as the key exchange method, if curves of different sizes are used, then it is possible that different hash functions from the SHA2 family could be used.</t>
<t>The REQUIRED and RECOMMENDED curves in this document are at present believed to offer security at the levels indicated in this section and as specified with the table in <xref target="intro" />.</t>
<t>System administrators and implementers should take careful consideration of the security issues when enabling curves other than the REQUIRED or RECOMMENDED curves in this document. Not all elliptic curves are secure, even if they are over a large field.</t>
<t>Implementers SHOULD ensure that any ephemeral private keys or random values -- including the value k used in ECDSA signature generation and the ephemeral private key values in ECDH and ECMQV -- are generated from a random number generator or a properly-seed pseudorandom number generator, are protected from leakage, are not reused outside of the context of the protocol in this document, and are erased from memory when no longer needed.</t>
</section>
<section anchor="params" title="Named Elliptic Curve Domain Parameters">
<t>Implementations MAY support any ASN.1 object identifier (OID) in the ASN.1 object tree that defines a set of elliptic curve domain parameters <xref target="ASN1" />.</t>
<section anchor="params-curvesrequiredd" title="Required Curves">
<t>Every SSH ECC implementation MUST support the named curves below. These curves are defined in <xref target="SEC2" />; the NIST curves were originally defined in <xref target="NIST-CURVES" />. These curves SHOULD always be enabled unless specifically disabled by local security policy.</t>
<texttable>
<ttcol align="center">NIST*</ttcol>
<ttcol align="center">SEC</ttcol>
<ttcol align="center">OID</ttcol>
<c>nistp256</c> <c>secp256r1</c> <c>1.2.840.10045.3.1.7</c>
<c>nistp384</c> <c>secp384r1</c> <c>1.3.132.0.34</c>
<c>nistp521</c> <c>secp521r1</c> <c>1.3.132.0.35</c>
</texttable>
<t>* For these three REQUIRED curves, the elliptic curve domain parameter identifier is the string in the first column of the table, the NIST name of the curve. (See <xref target="names-curveid" />.)</t>
</section>
<section anchor="params-curvesrecommended" title="Recommended Curves">
<t>It is RECOMMENDED that SSH ECC implementations also support the following curves. These curves are defined in <xref target="SEC2" />.</t>
<texttable>
<ttcol align="center">NIST</ttcol>
<ttcol align="center">SEC</ttcol>
<ttcol align="center">OID*</ttcol>
<c>nistk163</c> <c>sect163k1</c> <c>1.3.132.0.1</c>
<c>nistp192</c> <c>secp192r1</c> <c>1.2.840.10045.3.1.1</c>
<c>nistp224</c> <c>secp224r1</c> <c>1.3.132.0.33</c>
<c>nistk233</c> <c>sect233k1</c> <c>1.3.132.0.26</c>
<c>nistb233</c> <c>sect233r1</c> <c>1.3.132.0.27</c>
<c>nistk283</c> <c>sect283k1</c> <c>1.3.132.0.16</c>
<c>nistk409</c> <c>sect409k1</c> <c>1.3.132.0.36</c>
<c>nistb409</c> <c>sect409r1</c> <c>1.3.132.0.37</c>
<c>nistt571</c> <c>sect571k1</c> <c>1.3.132.0.38</c>
</texttable>
<t>* For these RECOMMENDED curves, the elliptic curve domain parameter identifier is the string in the third column of the table, the ASCII representation of the OID of the curve. (See <xref target="names-curveid" />.)</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>Consistent with Section 8 of <xref target="RFC4251" /> and Section 4.6 of <xref target="RFC4250" />, this document makes the following registrations:</t>
<t>In the Public Key Algorithm Names registry: The family of SSH public key algorithm names beginning with "ecdsa-sha2-" and not containing the at-sign ('@'), to name the public key algorithms defined in <xref target="ecc" />.</t>
<t>In the Key Exchange Method Names registry: The family of SSH key exchange method names beginning with "ecdh-sha2-" and not containing the at-sign ('@'), to name the key exchange methods defined in <xref target="ecdh" />.</t>
<t>In the Key Exchange Method Names registry: The SSH key exchange method name "ecmqv-sha2" to name the key exchange method defined in <xref target="ecmqv" />.</t>
<t>This document creates no new registries.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="ASN1">
<front>
<title>Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="July" year="2002" />
</front>
<seriesInfo name="" value="X.680" />
</reference>
<reference anchor="FIPS-180-3" target="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf">
<front>
<title>Secure Hash Standard</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="FIPS" value="180-3" />
<format type="PDF" target="http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf" />
</reference>
&rfc2104;
&rfc2119;
&rfc3766;
&rfc4250;
&rfc4251;
&rfc4253;
<reference anchor="SEC1" target="http://www.secg.org/download/aid-780/sec1-v2.pdf">
<front>
<title>Elliptic Curve Cryptography</title>
<author>
<organization>Standards for Efficient Cryptography Group</organization>
</author>
<date month="September" day="20" year="2000" />
</front>
<seriesInfo name="SEC" value="1" />
<format type="PDF" target="http://www.secg.org/download/aid-780/sec1-v2.pdf" />
</reference>
<reference anchor="SEC2" target="http://www.secg.org/download/aid-386/sec2_final.pdf">
<front>
<title>Recommended Elliptic Curve Domain Parameters</title>
<author>
<organization>Standards for Efficient Cryptography Group</organization>
</author>
<date month="September" day="20" year="2000" />
</front>
<seriesInfo name="SEC" value="2" />
<format type="PDF" target="http://www.secg.org/download/aid-386/sec2_final.pdf" />
</reference>
</references>
<references title="Informative References">
<reference anchor="ANSI-X9.62">
<front>
<title>Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
<author><organization>American National Standards Institute</organization></author>
<date month="" year="1998" />
</front>
<seriesInfo name="ANSI" value="X9.62" />
</reference>
<reference anchor="ANSI-X9.63">
<front>
<title>Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography</title>
<author><organization>American National Standards Institute</organization></author>
<date month="January" year="1999" />
</front>
<seriesInfo name="ANSI" value="X9.63" />
</reference>
<reference anchor="HMV04">
<front>
<title>Guide to Elliptic Curve Cryptography</title>
<author initials="D." surname="Hankerson" fullname="Darrel Hankerson"><organization /></author>
<author initials="A. J." surname="Menezes" fullname="Alfred J. Menezes"><organization /></author>
<author initials="S." surname="Vanstone" fullname="Scott Vanstone"><organization /></author>
<date month="" year="2004" />
</front>
<annotation>Springer, ISBN 038795273X</annotation>
</reference>
<reference anchor="IEEE1363">
<front>
<title>Standard Specifications for Public Key Cryptography</title>
<author><organization>Institute of Electrical and Electronics Engineers</organization></author>
<date month="" year="2000" />
</front>
<seriesInfo name="IEEE" value="1363" />
</reference>
<reference anchor="LMQSV98" target="http://www.cacr.math.uwaterloo.ca/techreports/1998/corr98-05.pdf">
<front>
<title>An Efficient Protocol for Authenticated Key Agreement</title>
<author initials="L." surname="Law" fullname="Laurie Law"><organization /></author>
<author initials="A. J." surname="Menezes" fullname="Alfred J. Menezes"><organization /></author>
<author initials="M." surname="Qu" fullname="Minghua Qu"><organization /></author>
<author initials="J." surname="Solinas" fullname="Jerry Solinas"><organization /></author>
<author initials="S." surname="Vanstone" fullname="Scott Vanstone"><organization /></author>
<date month="August" year="1998" />
</front>
<seriesInfo name="University of Waterloo Technical Report CORR" value="98-05" />
<format type="PDF" target="http://www.cacr.math.uwaterloo.ca/techreports/1998/corr98-05.pdf" />
</reference>
<reference anchor="NIST-800-57" target="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf">
<front>
<title>Recommendation for Key Management - Part 1: General (Revised)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="March" year="2007" />
</front>
<seriesInfo name="NIST Special Publication" value="800-57" />
<format type="PDF" target="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf" />
</reference>
<reference anchor="NIST-CURVES" target="http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf">
<front>
<title>Recommended Elliptic Curves for Federal Government Use</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="July" year="1999" />
</front>
<format type="PDF" target="http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf" />
</reference>
</references>
<section anchor="ack" title="Acknowledgements">
<t>The authors acknowledge helpful comments from James Blaisdell, David Harrington, Alfred Hoenes, Russ Housley, Jeffrey Hutzelman, Kevin Igoe, Rob Lambert, Jan Pechanek, Tim Polk, Sean Turner, Nicolas Williams, and members of the ietf-ssh@netbsd.org mailing list.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:19:40 |