IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

ECC in SSH draft version -01



Thank you for all the comments on draft-green-secsh-ecc-00.

I've addressed a lot of the concerns that were raised with a new version
of this draft draft-green-secsh-ecc-01. I submitted the new version to
the IETF, but I'm not sure if I made the deadline for drafts to be
posted, so I attached it to the message as well, while I wait for it to
be posted.

Specifically I addressed the problems with double negotiation within the
protocol and in doing so, made the ASN.1 in the document redundant, so I
moved away from ASN.1 messages. 

I'm would appreciate any comments you have on the revised version of the
draft.

Thanks, 
--
Jon Green
Research Intern
Certicom Corp.


Secure Shell Working Group                                      J. Green
Internet-Draft                                                  Certicom
Expires: April 19, 2007                                       D. Stebila
                                                              U Waterloo
                                                        October 16, 2006


Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer
                        draft-green-secsh-ecc-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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.




Green & Stebila          Expires April 19, 2007                 [Page 1]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Notation . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  ECC Public Key Algorithm . . . . . . . . . . . . . . . . . . .  5
     3.1.  Key/Signature Encoding . . . . . . . . . . . . . . . . . .  6
   4.  ECDH Key Exchange  . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Description  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Implementation . . . . . . . . . . . . . . . . . . . . . .  8
   5.  ECMQV Key Exchange and Verification  . . . . . . . . . . . . . 10
     5.1.  Description  . . . . . . . . . . . . . . . . . . . . . . . 10
     5.2.  Implementation . . . . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  ECC Public Key Algorithm Identifiers . . . . . . . . . . . 14
     6.2.  ECDH Key Exchange Method Names . . . . . . . . . . . . . . 14
     6.3.  ECMQV Key Exchange and Verification Method Names . . . . . 15
   7.  Key Exchange Messages  . . . . . . . . . . . . . . . . . . . . 16
     7.1.  ECDH Message Numbers . . . . . . . . . . . . . . . . . . . 16
     7.2.  ECMQV Message Numbers  . . . . . . . . . . . . . . . . . . 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   Appendix A.   Named Elliptic Curve Domain Parameters . . . . . . . 18
   Appendix A.1. Required and Recommended Curves  . . . . . . . . . . 18
   Appendix A.2. SEC Equivalent NIST Curves and OIDs  . . . . . . . . 18
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23






















Green & Stebila          Expires April 19, 2007                 [Page 2]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


1.  Introduction

   Due to its inclusion in NSA's Suit B and its small key sizes elliptic
   curve cryptography (ECC) is becoming a widely utilized and attractive
   public-key cryptosystem.

   In the interest of adding Suit B algorithms to SSH this document adds
   three ECC Suit B algorithms to the Secure Shell arsenal: Elliptic
   Curve Menezes-Qu-Vanstone (ECMQV), Elliptic Curve Diffie-Hellman
   (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA) as well
   as utilizing the SHA2 family of secure hash algorithms.

   Compared to cryptosystems such as RSA, DSA, and DH, 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 [9], 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.

       +-----------+-----------------------------+-------+---------+
       | Symmetric |  Discrete Log (eg. 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+  |
       +-----------+-----------------------------+-------+---------+

                 Figure 1: Comparable key sizes (in bits).

   Smaller key sizes result in power, bandwidth, and computational
   savings that make ECC especially attractive for constrained
   environments.

   Implementation of this specification requires familiarity with both
   SSH [2] [3] [4] and ECC [6] [10] [11].









Green & Stebila          Expires April 19, 2007                 [Page 3]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


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 RFC 2119 [1].

   The data types boolean, uint32, uint64, string, and mpint are to be
   interpreted in this document as described in RFC 4251 [2].

   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 characteristric-2
   curve is defined as the number of bits in the binary representation
   of the field, commonly denoted m.

   Protocol fields and possible values to fill them in are defined in
   this set of documents.  As an example SSH_MSG_KEX_ECDH_INIT is
   defined as follows.

   byte       SSH_MSG_KEX_ECDH_INIT
   string     pK, public key octet string.

   Throughout these documents, when the fields are referenced, they will
   appear within single quotes.  When values to fill in those fields are
   referenced they will appear in double quotes.


























Green & Stebila          Expires April 19, 2007                 [Page 4]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


3.  ECC Public Key Algorithm

   The ECC public key algorithm defines ECC public keys, private keys
   and signatures for use within the SSH protocol.  When ECC is chosen
   as the public key algorithm through key exchange negotiations the
   server's long term ECC key pair, which are called host keys
   throughout this draft, is used for identification and verification.

   When asked to sign communications or verify signatures by the key
   exchange method the elliptic curve digital signature algorithm
   (ECDSA) is used.  The algorithmic details of ECDSA can be found in
   Section 4 of SEC 1 [6] and in [13].  This document is concerned with
   the SSH implementation details; specification of the algorithm is
   left to other standards documents.

   The message hashing algorithm to be used with ECDSA is the same one
   specified to generate the exchange hash in the key exchange method
   chosen during algorithm negotiation.  If the chosen key exchange
   method doesn't specify a hashing function then SHA-256 [5] will be
   used.

   The algorithm for ECC key generation can be found in section 3.2 of
   SEC 1 [6].  Given some elliptic curve domain parameters, an ECC key
   pair can be generated containing an integer d that makes up the
   secret key and an elliptic curve point Q which makes up the public
   key.

   The elliptic curve domain parameters to generate EC keys can be
   produced at random, but this is a costly operation and may result in
   the use of domain parameters of which the security hasn't been
   tested.  Because of this, standards bodies have produced named sets
   of elliptic curve domain parameters or named curves.  This public key
   algorithm only allows named curves, specified by their ASN.1 OIDs, to
   be used.  Details of the curves that are required and recommended are
   outlined in Appendix A.

   The family of public key algorithm identifiers for ECC is specified
   in Section 6.1.  For the remainder of this section [identifier] will
   represent the ECC Public Key Algorithm identifier determined in
   Section 6.1.











Green & Stebila          Expires April 19, 2007                 [Page 5]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


3.1.  Key/Signature Encoding

   The ecc public key has the following encoding:

   string     [identifier]
   string     Q
   
   Where Q is the elliptic curve point that forms the public key.  Here
   Q is encoded from an elliptic curve point into an octet string as
   defined in Section 2.3.3 of SEC1 [6].

   The ECDSA signature has the following encoding:

   string     [identifier]
   mpint      r
   mpint      s

   Where the integers R and S are the output of the ECDSA algorithm.

































Green & Stebila          Expires April 19, 2007                 [Page 6]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


4.  ECDH Key Exchange

4.1.  Description

   The Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm
   generates a shared secret from an ephemeral elliptic curve private
   key contributed by the local entity and an ephemeral elliptic curve
   public key contributed by the remote entity.  When this algorithm is
   applied on both the client and the server both will derive the same
   shared key.

   The family of key exchange method names defined for use with this key
   exchange can be found in Section 6.2.

   The rest of this section is an informal overview of the ECDH key
   exchange mechanism.  A formal description can be found in
   Section 4.2.

   In the following: C is the client, S is the server; NC is the named
   curve specified in the algorithm name; cPK is the client's ephemeral
   public key; sPK is the server's ephemeral public key; K_S is the
   server's public host key; H is the exchange hash; s is the signature
   on H; and K is the shared secret.

   1.  C generates an ephemeral elliptic curve key pair on NC and sends
       the public-key value 'cPK'.

   2.  S SHOULD validate 'cPK' using, for example, algorithm A.16.10 of
       [10].  S generates an ephemeral public-key / private-key pair on
       NC.  S uses 'cPK' and S's ephemeral private key value to compute
       the shared secret K using ECDH.  S computes H and the signature
       's' on H using its private host key.  S sends "K_S || sPK || s".

   3.  C SHOULD validate 'sPK', for example, algorithm A.16.10 of [10].
       C verifies that 'K_S' really is the public host key for S (e.g.,
       using certificates or a local database).  C is also allowed to
       accept the key without verification; however, doing so will
       render the protocol insecure against active attacks.  C uses
       'sPK' and C's ephemeral private key to compute the shared secret
       and verifies the signature 's' on H.

   The size of the named curve specified in the algorithm name SHOULD be
   greater than 160 bits and preferably at least 224 bits.  The size of
   the curve used SHOULD be in line with the bulk encryption algorithm
   chosen during algorithm negotiation.






Green & Stebila          Expires April 19, 2007                 [Page 7]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


4.2.  Implementation

   This document is concerned with describing the implementation of ECDH
   in SSH, not the specification of the algorithm itself.  The algorithm
   used for shared key generation is ECDH, the full specification of
   which can be found in Section 3.3.2 of SEC1 [6].

   The algorithm for generation of EC key pairs can be found in Section
   3.2 of SEC1 [6].  This algorithm is necessary to generate the
   ephemeral EC key pairs needed for ECDH.

   The elliptic curve points (ephemeral public keys) 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 SEC1 Section 2.3 [6].

   The hash algorithm HASH for computing the exchange hash is determined
   by the size of the named curve specified in the method name.  The
   method for choosing a hash function can be seen in the table below
   where b is the size of the curve [5]:

                    +----------------+----------------+
                    |   Curve Size   | Hash Algorithm |
                    +----------------+----------------+
                    |    b <= 256    |     SHA-256    |
                    |                |                |
                    | 256 < b <= 384 |     SHA-384    |
                    |                |                |
                    |     384 < b    |     SHA-512    |
                    +----------------+----------------+

   Specification of the message numbers SSH_MSG_KEX_ECDH_INIT and
   SSH_MSG_KEX_ECDH_REPLY are found in Section 7.


















Green & Stebila          Expires April 19, 2007                 [Page 8]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


   The ECDH key exchange algorithm is implemented with the following
   messages.  The public key algorithm for signing is negotiated with
   the KEXINIT messages.

   The client sends:

   byte       SSH_MSG_KEX_ECDH_INIT
   string     cPK, the octet string formed from the
              client's ephemeral public key.
              
   The server responds with:

   byte       SSH_MSG_KEX_ECDH_REPLY
   string     K_S, server public host key and/or certificates
   string     sPK, the octet string formed from the server's
              ephemeral public key.
   string     s, the signature of H

   The exchange hash H is computed as the HASH of the concatenation of
   the following.


   string     V_C, the client's version string (CR and NL excluded)
   string     V_S, the server's version string (CR and NL excluded)
   string     I_C, the payload of the client's SSH_MSG_KEXINIT
   string     I_S, the payload of the server's SSH_MSG_KEXINIT
   string     K_S, the server's public host key
   string     cPK, the client's ephemeral public key octet string.
   string     sPK, the server's ephemeral public key octet string.
   mpint      K, the shared secret





















Green & Stebila          Expires April 19, 2007                 [Page 9]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


5.  ECMQV Key Exchange and Verification

5.1.  Description

   The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange algorithm
   generates a shared secret from two elliptic curve key pairs owned by
   one entity and two elliptic curve public keys owned by another
   entity.  Both entities' roles are analogous in the algorithm.  Using
   it's key pairs and the other entity's public keys, both entities'
   will derive the same secret.

   The family of key exchange method names defined for use with this key
   exchange can be found in Section 6.3.

   The following is an informal discussion of ECMQV key exchange and
   verification for a formal description see Section 5.2.

   The client doesn't necessarily have a long term key under the
   existing SSH protocol.  Instead of generating two ephemeral key pairs
   the client generates one ephemeral key pair and uses it for all the
   keys it is required to supply.  This is illustrated below considering
   the ECMQV algorithm in terms of a black box:

          Local Keys      |-----|-|-----|      Remote Keys

   ECMQV Block:               _______
                Key Pair ----|       |---- Public Key
                             | ECMQV |
                Key Pair ----|_______|---- Public Key
                                 |
                           shared secret

   Server Configuration:      _______
      Server Host Key    ----|       |----
             Pair            | ECMQV |   |--  Client Ephemeral
    Server Ephemeral Key ----|_______|----      Public Key
             Pair                |
                           shared secret

   Client Configuration:      _______
                         ----|       |---- Server Public Host Key
      Client Ephemeral --|   | ECMQV |
          Key Pair       ----|_______|---- Server Ephemeral Public
                                 |                   Key
                           shared secret






Green & Stebila          Expires April 19, 2007                [Page 10]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


   In the following: C is the client; S is the server; NC is the curve
   from the method name; K_S is the server's public host key; sPK is the
   server's ephemeral public key; cPK is the client's ephemeral public
   key; H is the exchange hash; T is the HMAC tag of H; and K is the
   shared secret.

   1.  C uses the domain parameters associated with NC to generate an
       ephemeral ECC public/private key pair.  C sends 'cPK'.

   2.  S SHOULD validate 'cPK' using, for example, algorithm A.16.10 of
       [10].  S generates an ephemeral public/private key pair using NC.
       S generates K using its private host key, its private ephemeral
       key and 'cPK'.  S computes H and the message authentication code
       (MAC) tag 'T' on H using K as the key.  S then sends "K_S || sPK
       || T".

   3.  C SHOULD validate 'sPK' and 'K_S' as above.  C verifies that
       'K_S' really is the public host key for S (e.g., using
       certificates or a local database).  C is also allowed to accept
       the key without verification; however, doing so will render the
       protocol insecure against active attacks.  C generates K using
       its private ephemeral key, 'sPK' and 'K_S'.  C independently
       computes H and verifies the tag 'T' is valid.  We use a MAC tag
       with K as a key for verification of communication with S because
       the private host key was used to create K, eliminating the need
       for a costly signing algorithm.

5.2.  Implementation

   This document is concerned with describing the implementation of
   ECMQV in SSH, not the specification of the algorithm itself.  A full
   description of ECMQV can be found in Section 3.4 of SEC1 [6].

   An implementation of SSH supporting ECMQV MUST support the ECC Public
   Key Algorithm (Section 3).  If during the key exchange algorithm
   negotiation ECMQV is chosen as the key exchange algorithm then the
   ECC Public Key Algorithm MUST be selected as the server host key
   algorithm.  This is due to the fact that ECMQV uses the servers ECC
   host keys within the key exchange.

   The server's host keys are used in shared key generation; therefore,
   the named curve used to generate them is the curve that must be used
   by the ECMQV algorithm.  Care should be taken that the server's host
   key is sufficiently strong to ensure that the ECMQV algorithm isn't
   the weakest point in the SSH encryption suite.






Green & Stebila          Expires April 19, 2007                [Page 11]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


   The elliptic curve points (public keys) 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 SEC1 Section 2.3 [6].

   The hash algorithm HASH for computing the exchange hash is determined
   by the strength of the named curve used by ECMQV.  The method for
   choosing a hash function can be seen in the table below where b is
   the size of the curve [5]:

                    +----------------+----------------+
                    |   Curve Size   | Hash Algorithm |
                    +----------------+----------------+
                    |    b <= 256    |     SHA-256    |
                    |                |                |
                    | 256 < b <= 384 |     SHA-384    |
                    |                |                |
                    |     384 < b    |     SHA-512    |
                    +----------------+----------------+

   The hash function chosen above is also the hash function that is used
   to implement the HMAC used for server identification and
   verification.  The algorithm for implementing HMAC with any of the
   above hash functions can be found in [5].

   The specification of the message numbers SSH_MSG_ECMQV_INIT and
   SSH_MSG_ECMQV_REPLY can be found in Section 7.

   The algorithm for generation of EC key pairs can be found in SEC1
   Section 3.2 [6].  This algorithm is necessary to generate the
   ephemeral EC key pairs needed for ECMQV.




















Green & Stebila          Expires April 19, 2007                [Page 12]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


   This key exchange algorithm is implemented with the following
   messages.

   The client sends:

   byte       SSH_MSG_ECMQV_INIT
   string     cPK, The octet string formed from the client's
              ephemeral public key.

   The server sends:

   byte       SSH_MSG_ECMQV_REPLY
   string     K_S, Server public host key octet string
   string     sPK, Server ephemeral public key octet string
   string     T, The 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, the client's version string (CR and NL excluded)
   string     V_S, the server's version string (CR and NL excluded)
   string     I_C, the payload of the client's SSH_MSG_KEXINIT
   string     I_S, the payload of the server's SSH_MSG_KEXINIT
   string     cPK, client's ephemeral public key octet
   string     K_S, server's public host key octet
   string     sPK, server's ephemeral public key octet
   mpint      K, the shared secret
























Green & Stebila          Expires April 19, 2007                [Page 13]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


6.  IANA Considerations

   This document defines two new families of key exchange method names
   and one new family of public key algorithm name in the SSH name
   registry.  These additions to the SSH name space will have to be
   approved the IANA.  The specification of these families is found
   below.

6.1.  ECC Public Key Algorithm Identifiers

   The ECC Public Key Algorithm specifies a family of identifiers.  The
   general format for this family of identifiers is the string "secg-
   ecc-" concatenated with the ASN.1 OID, in dotted decimal format, of
   the named curve domain parameters that are associated with the
   server's ECC host keys [8].

   There are two other identifiers in the ECC Public Key family that are
   only to be used only by the client during algorithm negotiation in
   SSH_MSG_KEXINIT messages.  These identifiers can: not be used at all,
   used on their own, or used in concert with normal "secg-ecc-[oid]"
   identifiers to specify additional supported named curves that the are
   not included in the special identifiers.

   "secg-ecc-standard" tells the server that the clients local security
   policy has not disabled any of the required curves specified in
   Appendix A and is analogous to sending "secg-ecc-1.3.132.0.37,secg-
   ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg-ecc-1.2.840.10045.3.1.7".

   "secg-ecc-extended" tells the server that the client supports all of
   the curves specified in Appendix A and is analogous to sending "secg-
   ecc-1.3.132.0.38,secg-ecc-1.3.132.0.35,secg-ecc-1.3.132.0.37,secg-
   ecc-1.3.132.0.36,secg-ecc-1.3.132.0.34,secg-ecc-1.3.132.0.16,secg-
   ecc-1.2.840.10045.3.1.7,secg-ecc-1.3.132.0.27,secg-ecc-
   1.3.132.0.26,secg-ecc-1.3.132.0.33,secg-ecc-1.2.840.10045.3.1.1,secg-
   ecc-1.3.132.0.1".

6.2.  ECDH Key Exchange Method Names

   The Elliptic Curve Diffie-Hellman key exchange is defined by a family
   of method names.  Each method name consists of the string "ecdh-
   sha2-" concatenated with the ASN.1 OID of the named curve, in dotted
   decimal notation, to be used for ephemeral key generation within the
   key exchange algorithm [8].  Information on the named curves that are
   required and recommended can be found in Appendix A.







Green & Stebila          Expires April 19, 2007                [Page 14]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


6.3.  ECMQV Key Exchange and Verification Method Names

   The Elliptic Curve Menezes-Qu-Vanstone key exchange is defined by a
   family of method names that specify what named curve will be used
   within the key exchange.  Each method name consists of the string
   "ecmqv-sha2-" concatenated with the ASN.1 OID of the named curve to
   be used in dotted decimal notation.  Information on the named curves
   that are required and recommended can be found in Appendix A [8].

   When the server forms its 'server_host_key_algorithms' name-list it
   MUST include only the algorithm from the "ecmqv-sha2-*" family that
   corresponds to the named curve used to produce its ECC host keys.  If
   the server doesn't have an ECC host key then the server MUST NOT put
   any members of the "ecmqv-sha2-*" family of algorithms in the
   'server_host_key_algorithms' name-list.




































Green & Stebila          Expires April 19, 2007                [Page 15]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


7.  Key Exchange Messages

   The message numbers 30-49 are key exchange-specific and in a private
   namespace defined in RFC4250 [4] that may be redefined by any key
   exchange method [3] without being granted IANA permission.

   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


































Green & Stebila          Expires April 19, 2007                [Page 16]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


8.  Security Considerations

   The Elliptic Curve Diffie-Hellman key agreement algorithm is defined
   in [6], [10] and [11].  The appropriate security considerations of
   those documents apply.

   The Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm is
   defined in [6].  The security considerations raised in that document
   also apply.  A more detailed discussion of security considerations
   can be found in The Guide to Elliptic Curve Cryptography section 4.7
   [14].

   The methods defined in Section 4 rely on the SHA family of hashing
   functions as defined in [15].  The appropriate security
   considerations of that document apply.

   Additionally a good general discussion of the security considerations
   that must be taken into account when creating an ECC implementation
   can be found in The Guide to Elliptic Curve Cryptography section 5
   [14].

   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 [9].























Green & Stebila          Expires April 19, 2007                [Page 17]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


Appendix A.  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 [8].

Appendix A.1.  Required and Recommended Curves

   Every SSH ECC implementation MUST support the named curves below,
   these curves are defined in SEC2 [7].  These curves should always be
   enabled unless specifically disabled by local security policy.

         secp256r1    sect283k1    secp384r1    sect409k1

   It is RECOMMENDED that SSH ECC implementations also support the
   following curves.

         sect163k1    secp192r1    sect233k1    secp224r1
         sect233r1    sect409r1    secp521r1    sect571k1

Appendix A.2.  SEC Equivalent NIST Curves and OIDs

              +-----------+----------+---------------------+
              |    SEC    | NIST[12] |        OID[7]       |
              +-----------+----------+---------------------+
              | sect163k1 | nistk163 |     1.3.132.0.1     |
              |           |          |                     |
              | secp192r1 | nistp192 | 1.2.840.10045.3.1.1 |
              |           |          |                     |
              | secp224r1 | nistp224 |     1.3.132.0.33    |
              |           |          |                     |
              | sect233k1 | nistk233 |     1.3.132.0.26    |
              |           |          |                     |
              | sect233r1 | nistb233 |     1.3.132.0.27    |
              |           |          |                     |
              | secp256r1 | nistp256 | 1.2.840.10045.3.1.7 |
              |           |          |                     |
              | sect283k1 | nistk283 |     1.3.132.0.16    |
              |           |          |                     |
              | secp384r1 | nistp384 |     1.3.132.0.34    |
              |           |          |                     |
              | sect409k1 | nistk409 |     1.3.132.0.36    |
              |           |          |                     |
              | sect409r1 | nistb409 |     1.3.132.0.37    |
              |           |          |                     |
              | secp521r1 | nistp521 |     1.3.132.0.35    |
              |           |          |                     |
              | sect571k1 | nistk571 |     1.3.132.0.38    |
              +-----------+----------+---------------------+


Green & Stebila          Expires April 19, 2007                [Page 18]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


9.  Acknowledgements

   Douglas Stebila wishes to thank Sheueling Chang and Vipul Gupta of
   Sun Microsystems.  The work on draft-stebila-secsh-ecdh-01, of which
   this work is a derivative document, was largely performed during a
   student internship at Sun Microsystems Laboratories from the
   University of Waterloo.

   Jon Green would like to thank Robert Lambert of Certicom for all the
   help and knowledge he provided.  This document was written during an
   internship at Certicom from Queens University.








































Green & Stebila          Expires April 19, 2007                [Page 19]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


10.  References

10.1.  Normative References

   [1]  Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [2]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell Protocol
        Architecture", RFC 4251, January 2006.

   [3]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell Transport
        Layer Protocol", RFC 4253, January 2006.

   [4]  Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell Protocol
        Assigned Numbers", RFC 4250, January 2006.

   [5]  Eastlake, 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA
        and HMAC-SHA)", RFC 4634, July 2006.

   [6]  Standards for Efficient Cryptography Group, "Elliptic Curve
        Cryptography", SEC 1 v1.0, September 2000.

   [7]  Standards for Efficient Cryptography Group, "Recommended
        Elliptic Curve Domain Parameters", SEC 2 v1.0, September 2000.

   [8]  International Telecommunication Union, "Abstract Syntax Notation
        One (ASN.1): Specification of basic notation", X.680 ,
        July 2002.























Green & Stebila          Expires April 19, 2007                [Page 20]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


10.2.  Informative References

   [9]   National Institute of Standards and Technology, "Recommendation
         for Key Management - Part 1", NIST Special Publication 800-57.

   [10]  Institute of Electrical and Electronics Engineers, "Standard
         Specifications for Public Key Cryptography", IEEE 1363, 2000.

   [11]  American National Standards Institute, "Public Key Cryptography
         For The Financial Services Industry: Key Agreement and key
         Transport Using Elliptic Curve Cryptography", ANSI X9.63,
         November 2001.

   [12]  National Institute of Standards and Technology, "Recommended
         Elliptic Curves for Federal Government Use", August 1999.

   [13]  American National Standards Institute, "Public Key Cryptography
         For The Financial Services Industry The Elliptic Curve Digital
         Signature Algorithm", ANSI X9.62, 1998.

   [14]  Hankerson, Menezes, and Vanstone, "Guide to Elliptic Curve
         Cryptography", 2004, <urn:isbn:038795273X>.

   [15]  National Institute of Standards and Technology, "Secure Hash
         Standard", FIPS 180-2, August 2002.


























Green & Stebila          Expires April 19, 2007                [Page 21]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


Authors' Addresses

   Jon Green
   Certicom
   5520 Explorer Drive
   4th Floor
   Mississauga, ON  L4W 5L1
   Canada

   Email: jgreen%certicom.com@localhost


   Douglas Stebila
   Department of Combinatorics and Optimization
   University of Waterloo
   Waterloo, ON  N2L 3G1
   Canada

   Email: douglas%stebila.ca@localhost
































Green & Stebila          Expires April 19, 2007                [Page 22]

Internet-Draft        SSH ECC Algorithm Integration         October 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr%ietf.org@localhost.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Green & Stebila          Expires April 19, 2007                [Page 23]



Home | Main Index | Thread Index | Old Index