doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc5656.txt b/doc/rfc/rfc5656.txt
new file mode 100644
index 0000000..aea96be
--- /dev/null
+++ b/doc/rfc/rfc5656.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                         D. Stebila
+Request for Comments: 5656           Queensland University of Technology
+Category: Standards Track                                       J. Green
+                                                      Queen's University
+                                                           December 2009
+
+
+Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
+
+Abstract
+
+   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.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+
+
+
+Stebila & Green             Standards Track                     [Page 1]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Notation ........................................................4
+   3. SSH ECC Public Key Algorithm ....................................4
+      3.1. Key Format .................................................4
+           3.1.1. Signature Algorithm .................................5
+           3.1.2. Signature Encoding ..................................5
+   4. ECDH Key Exchange ...............................................5
+   5. ECMQV Key Exchange ..............................................8
+   6. Method Names ...................................................10
+      6.1. Elliptic Curve Domain Parameter Identifiers ...............10
+      6.2. ECC Public Key Algorithm (ecdsa-sha2-*) ...................11
+           6.2.1. Elliptic Curve Digital Signature Algorithm .........11
+      6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) ..............12
+      6.4. ECMQV Key Exchange and Verification Method Name
+           (ecmqv-sha2) ..............................................12
+   7. Key Exchange Messages ..........................................13
+      7.1. ECDH Message Numbers ......................................13
+      7.2. ECMQV Message Numbers .....................................13
+   8. Manageability Considerations ...................................13
+      8.1. Control of Function through Configuration and Policy ......13
+      8.2. Impact on Network Operation ...............................14
+   9. Security Considerations ........................................14
+   10. Named Elliptic Curve Domain Parameters ........................16
+      10.1. Required Curves ..........................................16
+      10.2. Recommended Curves .......................................17
+   11. IANA Considerations ...........................................17
+   12. References ....................................................18
+      12.1. Normative References .....................................18
+      12.2. Informative References ...................................19
+   Appendix A.  Acknowledgements .....................................20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stebila & Green             Standards Track                     [Page 2]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+1.  Introduction
+
+   This document adds the following 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).
+
+   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.
+
+   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 [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 the field size and N
+   is the sub-field size.
+
+      +-----------+------------------------------+-------+---------+
+      | Symmetric | Discrete Log (e.g., DSA, DH) |  RSA  |   ECC   |
+      +-----------+------------------------------+-------+---------+
+      |     80    |       L = 1024, N = 160      |  1024 | 160-223 |
+      |           |                              |       |         |
+      |    112    |       L = 2048, N = 256      |  2048 | 224-255 |
+      |           |                              |       |         |
+      |    128    |       L = 3072, N = 256      |  3072 | 256-383 |
+      |           |                              |       |         |
+      |    192    |       L = 7680, N = 384      |  7680 | 384-511 |
+      |           |                              |       |         |
+      |    256    |      L = 15360, N = 512      | 15360 |   512+  |
+      +-----------+------------------------------+-------+---------+
+
+   Implementation of this specification requires familiarity with both
+   SSH [RFC4251] [RFC4253] [RFC4250] and ECC [SEC1] (additional
+   information on ECC available in [HMV04], [ANSI-X9.62], and
+   [ANSI-X9.63]).
+
+   This document is concerned with SSH implementation details;
+   specification of the underlying cryptographic algorithms is left to
+   other standards documents.
+
+
+
+
+
+
+
+Stebila & Green             Standards Track                     [Page 3]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+2.  Notation
+
+   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 [RFC2119].
+
+   The data types boolean, byte, uint32, uint64, string, and mpint are
+   to be interpreted in this document as described in [RFC4251].
+
+   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 by p.  Size on a
+   characteristic-2 curve is defined as the number of bits in the binary
+   representation of the field, commonly denoted by m.  A set of
+   elliptic curve domain parameters defines a group of order n generated
+   by a base point P.
+
+3.  SSH ECC Public Key Algorithm
+
+   The SSH ECC public key algorithm is defined by its key format,
+   corresponding signature algorithm ECDSA, signature encoding, and
+   algorithm identifiers.
+
+   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.
+
+3.1.  Key Format
+
+   The "ecdsa-sha2-*" key formats all have the following encoding:
+
+      string   "ecdsa-sha2-[identifier]"
+      byte[n]  ecc_key_blob
+
+   The ecc_key_blob value has the following specific encoding:
+
+      string   [identifier]
+      string   Q
+
+   The string [identifier] is the identifier of the elliptic curve
+   domain parameters.  The format of this string is specified in
+   Section 6.1.  Information on the REQUIRED and RECOMMENDED sets of
+   elliptic curve domain parameters for use with this algorithm can be
+   found in Section 10.
+
+   Q is the public key encoded from an elliptic curve point into an
+   octet string as defined in Section 2.3.3 of [SEC1]; point compression
+   MAY be used.
+
+
+
+Stebila & Green             Standards Track                     [Page 4]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   The algorithm for ECC key generation can be found in Section 3.2 of
+   [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).
+
+3.1.1.  Signature Algorithm
+
+   Signing and verifying is done using the Elliptic Curve Digital
+   Signature Algorithm (ECDSA).  ECDSA is specified in [SEC1].  The
+   message hashing algorithm MUST be from the SHA2 family of hash
+   functions [FIPS-180-3] and is chosen according to the curve size as
+   specified in Section 6.2.1.
+
+3.1.2.  Signature Encoding
+
+   Signatures are encoded as follows:
+
+      string   "ecdsa-sha2-[identifier]"
+      string   ecdsa_signature_blob
+
+   The string [identifier] is the identifier of the elliptic curve
+   domain parameters.  The format of this string is specified in
+   Section 6.1.  Information on the REQUIRED and RECOMMENDED sets of
+   elliptic curve domain parameters for use with this algorithm can be
+   found in Section 10.
+
+   The ecdsa_signature_blob value has the following specific encoding:
+
+      mpint    r
+      mpint    s
+
+   The integers r and s are the output of the ECDSA algorithm.
+
+   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.
+
+4.  ECDH Key Exchange
+
+   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
+   [RFC4253] using a signature on the exchange hash.  Every compliant
+   SSH ECC implementation MUST implement ECDH key exchange.
+
+
+
+
+
+Stebila & Green             Standards Track                     [Page 5]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   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 [SEC1].  The algorithm for key pair generation can
+   be found in Section 3.2.1 of [SEC1].
+
+   The family of key exchange method names defined for use with this key
+   exchange can be found in Section 6.3.  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.
+
+   Information on the REQUIRED and RECOMMENDED elliptic curve domain
+   parameters for use with this method can be found in Section 10.
+
+   All elliptic curve public keys MUST be validated after they are
+   received.  An example of a validation algorithm can be found in
+   Section 3.2.2 of [SEC1].  If a key fails validation, the key exchange
+   MUST fail.
+
+   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 [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 [SEC1].
+
+   Specification of the message numbers SSH_MSG_KEX_ECDH_INIT and
+   SSH_MSG_KEX_ECDH_REPLY is found in Section 7.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stebila & Green             Standards Track                     [Page 6]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   The following is an overview of the key exchange process:
+
+      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.
+
+      *  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 MAY 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 [RFC4251].
+
+   This is implemented using the following messages.
+
+   The client sends:
+
+      byte     SSH_MSG_KEX_ECDH_INIT
+      string   Q_C, client's ephemeral public key octet string
+
+   The server responds with:
+
+      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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stebila & Green             Standards Track                     [Page 7]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   The exchange hash H is computed as the hash of the concatenation of
+   the following.
+
+      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
+
+5.  ECMQV Key Exchange
+
+   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 [RFC4253].  The ECMQV key
+   exchange method is OPTIONAL.
+
+   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 Hashed Message Authentication Code (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 Section 6.4.
+
+   In general, the ECMQV key exchange is performed using the ephemeral
+   and long-term key pair of both the client and server, which is 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
+   it does not adversely affect security (it is analogous to the one-
+   pass protocol in Section 6.1 of [LMQSV98]).
+
+   A full description of the ECMQV primitive can be found in Section 3.4
+   of [SEC1].  The algorithm for key pair generation can be found in
+   Section 3.2.1 of [SEC1].
+
+   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
+
+
+
+
+
+Stebila & Green             Standards Track                     [Page 8]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   handled in Section 7.1 of [RFC4253].  If ECMQV key exchange is
+   chosen, then the public key algorithm supporting ECC host keys MUST
+   also be chosen.
+
+   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.
+
+   All elliptic curve public keys MUST be validated after they are
+   received.  An example of a validation algorithm can be found in
+   Section 3.2.2 of [SEC1].  If a key fails validation, the key exchange
+   MUST fail.
+
+   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 [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 [SEC1].
+
+   The following is an overview of the key exchange process:
+
+      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.
+
+      *  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 MAY accept the host key without verification, but
+         doing so will render the protocol insecure against active
+         attacks.
+
+
+
+Stebila & Green             Standards Track                     [Page 9]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   The specification of the message numbers SSH_MSG_ECMQV_INIT and
+   SSH_MSG_ECMQV_REPLY can be found in Section 7.
+
+   This key exchange algorithm is implemented with the following
+   messages.
+
+   The client sends:
+
+      byte     SSH_MSG_ECMQV_INIT
+      string   Q_C, client's ephemeral public key octet string
+
+   The server sends:
+
+      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
+
+   The hash H is formed by applying the algorithm HASH on a
+   concatenation of the following:
+
+      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
+
+6.  Method Names
+
+   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.
+
+6.1.  Elliptic Curve Domain Parameter Identifiers
+
+   This section specifies identifiers encoding named elliptic curve
+   domain parameters.  These identifiers are used in this document to
+   identify the curve used in the SSH ECC public key format, the ECDSA
+   signature blob, and the ECDH method name.
+
+   For the REQUIRED elliptic curves nistp256, nistp384, and nistp521,
+   the elliptic curve domain parameter identifiers are the strings
+   "nistp256", "nistp384", and "nistp521".
+
+
+
+
+
+Stebila & Green             Standards Track                    [Page 10]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   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) [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 identifier (or the method name and
+   the elliptic curve domain parameter identifier) does not exceed the
+   maximum specified by the SSH protocol architecture [RFC4251], namely
+   64 characters; otherwise, the identifier for that curve is undefined,
+   and the curve is not supported by this specification.
+
+   A list of the REQUIRED and RECOMMENDED curves and their OIDs can be
+   found in Section 10.
+
+   Note that implementations MUST use the string identifiers for the
+   three REQUIRED NIST curves, even when an OID exists for that curve.
+
+6.2.  ECC Public Key Algorithm (ecdsa-sha2-*)
+
+   The SSH ECC public key algorithm is specified by a family of public
+   key format identifiers.  Each identifier is the concatenation of the
+   string "ecdsa-sha2-" with the elliptic curve domain parameter
+   identifier as defined in Section 6.1.  A list of the required and
+   recommended curves and their OIDs can be found in Section 10.
+
+   For example, the method name for ECDH key exchange with ephemeral
+   keys generated on the nistp256 curve is "ecdsa-sha2-nistp256".
+
+6.2.1.  Elliptic Curve Digital Signature Algorithm
+
+   The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified
+   for use with the SSH ECC public key algorithm.
+
+   The hashing algorithm defined by this family of method names is the
+   SHA2 family of hashing algorithms [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:
+
+
+
+
+
+
+
+
+
+
+
+
+Stebila & Green             Standards Track                    [Page 11]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+                    +----------------+----------------+
+                    |   Curve Size   | Hash Algorithm |
+                    +----------------+----------------+
+                    |    b <= 256    |     SHA-256    |
+                    |                |                |
+                    | 256 < b <= 384 |     SHA-384    |
+                    |                |                |
+                    |     384 < b    |     SHA-512    |
+                    +----------------+----------------+
+
+6.3.  ECDH Key Exchange Method Names (ecdh-sha2-*)
+
+   The Elliptic Curve Diffie-Hellman (ECDH) 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 Section 6.1.  A list of the required and
+   recommended curves and their OIDs can be found in Section 10.
+
+   For example, the method name for ECDH key exchange with ephemeral
+   keys generated on the sect409k1 curve is "ecdh-sha2-1.3.132.0.36".
+
+   The hashing algorithm defined by this family of method names is the
+   SHA2 family of hashing algorithms [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
+   Section 6.2.1.
+
+   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.
+
+6.4.  ECMQV Key Exchange and Verification Method Name (ecmqv-sha2)
+
+   The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) 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.
+
+   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.
+
+
+
+
+
+
+
+Stebila & Green             Standards Track                    [Page 12]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   The hashing algorithm defined by this method name is the SHA2 family
+   of hashing algorithms [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 Section 6.2.1.
+
+   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 [RFC2104].
+
+7.  Key Exchange Messages
+
+   The message numbers 30-49 are key-exchange-specific and in a private
+   namespace defined in [RFC4250] that may be redefined by any key
+   exchange method [RFC4253] without requiring an IANA registration
+   process.
+
+   The following message numbers have been defined in this document:
+
+7.1.  ECDH Message Numbers
+
+      #define SSH_MSG_KEX_ECDH_INIT                30
+      #define SSH_MSG_KEX_ECDH_REPLY               31
+
+7.2.  ECMQV Message Numbers
+
+      #define SSH_MSG_ECMQV_INIT                   30
+      #define SSH_MSG_ECMQV_REPLY                  31
+
+8.  Manageability Considerations
+
+   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.
+
+8.1.  Control of Function through Configuration and Policy
+
+   Section 10 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.
+
+
+
+
+
+
+Stebila & Green             Standards Track                    [Page 13]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+8.2.  Impact on Network Operation
+
+   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.
+
+   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.
+
+9.  Security Considerations
+
+   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.
+
+   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).
+
+   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 Section 10 do not have this problem.  System administrators
+   should be cautious when enabling curves other than the ones specified
+   in Section 10 and should make a more detailed investigation into the
+   security of the curve in question.
+
+   It is believed (see, for example, Section B.2.1 of [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 Section 10 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
+
+
+
+Stebila & Green             Standards Track                    [Page 14]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   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.)
+
+   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 Section 1 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.
+
+   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 document are 256-, 384-,
+   and 521-bit curves; implementations SHOULD NOT use curves smaller
+   than 160 bits.
+
+   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 [SEC1].
+
+   Additionally, the key exchange methods defined in this document rely
+   on the SHA2 family of hash functions, defined in [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 Section 6.2.1 which SHA2 variant should be
+   used with which elliptic curve size based on this guidance.
+
+   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 [NIST-800-57]; the discussion in [RFC3766] is
+   also relevant.  We note in particular that when ECDSA is used as the
+
+
+
+
+Stebila & Green             Standards Track                    [Page 15]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   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.
+
+   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 Section 1.
+
+   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.
+
+   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 seeded
+   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.
+
+10.  Named Elliptic Curve Domain Parameters
+
+   Implementations MAY support any ASN.1 object identifier (OID) in the
+   ASN.1 object tree that defines a set of elliptic curve domain
+   parameters [ASN1].
+
+10.1.  Required Curves
+
+   Every SSH ECC implementation MUST support the named curves below.
+   These curves are defined in [SEC2]; the NIST curves were originally
+   defined in [NIST-CURVES].  These curves SHOULD always be enabled
+   unless specifically disabled by local security policy.
+
+              +----------+-----------+---------------------+
+              |   NIST*  |    SEC    |         OID         |
+              +----------+-----------+---------------------+
+              | nistp256 | secp256r1 | 1.2.840.10045.3.1.7 |
+              |          |           |                     |
+              | nistp384 | secp384r1 |     1.3.132.0.34    |
+              |          |           |                     |
+              | nistp521 | secp521r1 |     1.3.132.0.35    |
+              +----------+-----------+---------------------+
+
+      *  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 Section 6.1.)
+
+
+
+
+Stebila & Green             Standards Track                    [Page 16]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+10.2.  Recommended Curves
+
+   It is RECOMMENDED that SSH ECC implementations also support the
+   following curves.  These curves are defined in [SEC2].
+
+              +----------+-----------+---------------------+
+              |   NIST   |    SEC    |         OID*        |
+              +----------+-----------+---------------------+
+              | nistk163 | sect163k1 |     1.3.132.0.1     |
+              |          |           |                     |
+              | nistp192 | secp192r1 | 1.2.840.10045.3.1.1 |
+              |          |           |                     |
+              | nistp224 | secp224r1 |     1.3.132.0.33    |
+              |          |           |                     |
+              | nistk233 | sect233k1 |     1.3.132.0.26    |
+              |          |           |                     |
+              | nistb233 | sect233r1 |     1.3.132.0.27    |
+              |          |           |                     |
+              | nistk283 | sect283k1 |     1.3.132.0.16    |
+              |          |           |                     |
+              | nistk409 | sect409k1 |     1.3.132.0.36    |
+              |          |           |                     |
+              | nistb409 | sect409r1 |     1.3.132.0.37    |
+              |          |           |                     |
+              | nistt571 | sect571k1 |     1.3.132.0.38    |
+              +----------+-----------+---------------------+
+
+      *  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
+         Section 6.1.)
+
+11.  IANA Considerations
+
+   Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250],
+   this document makes the following registrations:
+
+   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
+   Section 3.
+
+   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
+   Section 4.
+
+
+
+
+
+Stebila & Green             Standards Track                    [Page 17]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+   In the Key Exchange Method Names registry: The SSH key exchange
+   method name "ecmqv-sha2" to name the key exchange method defined in
+   Section 5.
+
+   This document creates no new registries.
+
+12.  References
+
+12.1.  Normative References
+
+   [ASN1]         International Telecommunications Union, "Abstract
+                  Syntax Notation One (ASN.1): Specification of basic
+                  notation",  X.680, July 2002.
+
+   [FIPS-180-3]   National Institute of Standards and Technology,
+                  "Secure Hash Standard", FIPS 180-3, October 2008.
+
+   [RFC2104]      Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
+                  Keyed-Hashing for Message Authentication", RFC 2104,
+                  February 1997.
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3766]      Orman, H. and P. Hoffman, "Determining Strengths For
+                  Public Keys Used For Exchanging Symmetric Keys",
+                  BCP 86, RFC 3766, April 2004.
+
+   [RFC4250]      Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
+                  Protocol Assigned Numbers", RFC 4250, January 2006.
+
+   [RFC4251]      Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
+                  Protocol Architecture", RFC 4251, January 2006.
+
+   [RFC4253]      Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
+                  Transport Layer Protocol", RFC 4253, January 2006.
+
+   [SEC1]         Standards for Efficient Cryptography Group, "Elliptic
+                  Curve Cryptography", SEC 1, May 2009,
+                  <http://www.secg.org/download/aid-780/sec1-v2.pdf>.
+
+   [SEC2]         Standards for Efficient Cryptography Group,
+                  "Recommended Elliptic Curve Domain Parameters", SEC 2,
+                  September 2000,
+                  <http://www.secg.org/download/aid-386/sec2_final.pdf>.
+
+
+
+
+
+
+Stebila & Green             Standards Track                    [Page 18]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+12.2.  Informative References
+
+   [ANSI-X9.62]   American National Standards Institute, "Public Key
+                  Cryptography For The Financial Services Industry: The
+                  Elliptic Curve Digital Signature Algorithm (ECDSA)",
+                  ANSI X9.62, 1998.
+
+   [ANSI-X9.63]   American National Standards Institute, "Public Key
+                  Cryptography For The Financial Services Industry: Key
+                  Agreement and Key Transport Using Elliptic Curve
+                  Cryptography", ANSI X9.63, January 1999.
+
+   [HMV04]        Hankerson, D., Menezes, A., and S. Vanstone, "Guide to
+                  Elliptic Curve Cryptography", Springer ISBN
+                  038795273X, 2004.
+
+   [LMQSV98]      Law, L., Menezes, A., Qu, M., Solinas, J., and S.
+                  Vanstone, "An Efficient Protocol for Authenticated Key
+                  Agreement", University of Waterloo Technical Report
+                  CORR 98-05, August 1998, <http://
+                  www.cacr.math.uwaterloo.ca/techreports/1998/
+                  corr98-05.pdf>.
+
+   [NIST-800-57]  National Institute of Standards and Technology,
+                  "Recommendation for Key Management - Part 1: General
+                  (Revised)", NIST Special Publication 800-57,
+                  March 2007.
+
+   [NIST-CURVES]  National Institute of Standards and Technology,
+                  "Recommended Elliptic Curves for Federal Government
+                  Use", July 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stebila & Green             Standards Track                    [Page 19]
+
+RFC 5656             SSH ECC Algorithm Integration         December 2009
+
+
+Appendix A.  Acknowledgements
+
+   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.
+
+Authors' Addresses
+
+   Douglas Stebila
+   Queensland University of Technology
+   Information Security Institute
+   Level 7, 126 Margaret St
+   Brisbane, Queensland  4000
+   Australia
+
+   EMail: douglas@stebila.ca
+
+
+   Jon Green
+   Queen's University
+   Parallel Processing Research Laboratory
+   Department of Electrical and Computer Engineering
+   Room 614, Walter Light Hall
+   Kingston, Ontario  K7L 3N6
+   Canada
+
+   EMail: jonathan.green@queensu.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stebila & Green             Standards Track                    [Page 20]
+