Secure Shell Working Group J. Green
Internet-Draft Certicom
Expires: April 8, 2007 D. Stebila
U Waterloo
October 5, 2006
Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer
draft-green-secsh-ecc-00
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 8, 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 8, 2007 [Page 1]
Internet-Draft SSH ECC Algorithm Integration October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. ECC Public Key Algorithm [ssh-ecc] . . . . . . . . . . . . . . 5
3.1. Key/Signature Encoding . . . . . . . . . . . . . . . . . . 6
4. ECDH Parameter and Key Exchange [ecdh-exchange] . . . . . . . 7
4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 8
5. ECMQV Key Exchange and Verification [ecmqv] . . . . . . . . . 10
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Implementation . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. ssh-ecc . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. ecdh-exchange . . . . . . . . . . . . . . . . . . . . . . 14
6.3. ecmqv . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Key Exchange Messages . . . . . . . . . . . . . . . . . . . . 15
7.1. ECDH Message Numbers . . . . . . . . . . . . . . . . . . . 15
7.2. ECMQV Message Numbers . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
Appendix A. Named Elliptic Curve Domain Parameters . . . . . . . 17
Appendix A.1. Required and Recommended Curves . . . . . . . . . . 17
Appendix A.2. Sending Lists of Curves . . . . . . . . . . . . . . 17
Appendix A.3. SEC Equivalent NIST Curves . . . . . . . . . . . . . 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 8, 2007 [Page 2]
Internet-Draft SSH ECC Algorithm Integration October 2006
1. Introduction
Elliptic Curve Cryptography (ECC) is emerging as an attractive
public-key cryptosystem for environments with limited bandwidth and
computing power. Compared to currently prevalent 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 [11], 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 | Discreet 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.
This document describes additions to the SSH transport layer to
support the use of Elliptic Curve Digital Signature Algorithm (ECDSA)
for message signing, Elliptic Curve Diffie-Hellman (ECDH) and
Elliptic Curve Menezes-Qu-Vanstone (ECMQV) to establish a shared key.
Implementation of this specification requires familiarity with both
SSH [1] [2] [3] and ECC [4] [12] [13].
Comments on this draft are solicited and should be addressed to
Jon Green <jgreen@certicom.com>.
Green & Stebila Expires April 8, 2007 [Page 3]
Internet-Draft SSH ECC Algorithm Integration October 2006
2. Requirements 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 [6].
The data types boolean, uint32, uint64, string, and mpint are to be
interpreted in this document as described in RFC 4251 [1].
This document uses Abstract Syntax Notation (ASN.1) define some
communication. This is in keeping with current ECC standards. All
ASN.1 variables are DER encoded before being sent. Information about
the ASN.1 and DER can be found in ITU-T recommendation X.680 [7] and
ITU-T recommendation X.690 [8].
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_NUMBER
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 8, 2007 [Page 4]
Internet-Draft SSH ECC Algorithm Integration October 2006
3. ECC Public Key Algorithm [ssh-ecc]
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
servers long term ECC key pair (host keys) are 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 [4] and in [15]. 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 [9] will be
used.
The algorithm for ECC key generation can be found in section 3.2 of
SEC 1 [4]. Given some elliptic curve domain parameters, an ECC key
pair can be generated containing an integer d that is 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. Details of the
curves required and recommended by this public key algorithm are
outlined in Appendix A.
The public key algorithm identifier specified for ECC is "ssh-ecc".
This specification conforms to conventions for the SSH public key
algorithm namespace [2] and must be approved by the IANA before it is
put into use.
Green & Stebila Expires April 8, 2007 [Page 5]
Internet-Draft SSH ECC Algorithm Integration October 2006
3.1. Key/Signature Encoding
The ECC public key and signature are sent in the standard encoding
for ECC keys and signatures. This requires ASN.1 DER encoding which
is specified in [7] and [8].
The ecc public key has the following encoding:
string "ssh-ecc"
ASN/DER SubjectPublicKeyInfo
Here 'SubjectPublicKeyInfo' is defined as it is in Section C3 of SEC1
[4].
The ecdsa signature has the following encoding:
string "ssh-ecc"
ASN/DER ECDSA-Sig-Value
Here the integers R and S that form the ECDSA signature are
encapsulated in the ASN.1 field 'ECDSA-Sig-Value'. The field 'ECDSA-
Sig-Value' is defined here as it is in Section C6 of SEC1 [4].
Green & Stebila Expires April 8, 2007 [Page 6]
Internet-Draft SSH ECC Algorithm Integration October 2006
4. ECDH Parameter and Key Exchange [ecdh-exchange]
4.1. Description
This section is an informal overview of the elliptic curve Diffie-
Hellman (ECDH) key exchange mechanism. A formal description can be
found in Section 4.2.
The first stage of the ECDH key exchange mechanism is the exchange of
elliptic curve domain parameters.
Once the domain parameters are decided upon, both the client and
server generate ephemeral EC key pairs, and exchange their ephemeral
public keys. Using its own key pair and the other's public key both
the client and the server derive the same shared secret key using
ECDH.
In the following: C is the client, S is the server; E_C is the
client's list of supported curves; E_S is the server's list of
supported curves; 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 and S send 'E_C' and 'E_S', lists ordered by preference (most
to least) of named elliptic curve domain parameters. The first
curve in 'E_C' that also appears in 'E_S' is the curve that will
be used for ephemeral key generation. If there are no matching
curves both sides MUST disconnect.
2. C chooses the curve it prefers most from from 'E_S' then
generates an ephemeral elliptic curve public-key / private-key
pair and sends the public-key value 'cPK'.
3. S MAY validate 'cPK' using for example algorithm A.16.10 of [12].
S chooses the first curve in 'E_C' it supports and uses it to
generate an ephemeral public-key / private-key pair. 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".
4. C MAY validate S's public-key value using for example algorithm
A.16.10 of [12]. 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'.
Green & Stebila Expires April 8, 2007 [Page 7]
Internet-Draft SSH ECC Algorithm Integration October 2006
The size of the selected curve 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. Appendix A contains more information about required and
recommended curves.
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 [4].
The algorithm for generation of EC key pairs can be found in Section
3.2 of SEC1 [4]. 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 [4].
The hash algorithm for computing the exchange hash is determined by
the size of the named curve chosen. The method for choosing a hash
function can be seen in the table below where b is the size of the
curve:
+----------------+----------------+
| Curve Size | Hash Algorithm |
+----------------+----------------+
| b <= 256 | SHA-256 |
| | |
| 256 < b <= 384 | SHA-384 |
| | |
| 384 < b | SHA-512 |
+----------------+----------------+
Green & Stebila Expires April 8, 2007 [Page 8]
Internet-Draft SSH ECC Algorithm Integration October 2006
Specification of the message numbers SSH_MSG_KEX_ECDH_REQUEST,
SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY are found in
Section 7.
The ECDH key exchange algorithm is implemented with the following
messages. The public key algorithm for signing is negotiated with
the KEXINIT messages.
Both the client and server send:
byte SSH_MSG_KEX_ECDH_REQUEST
ASN/DER curves (E_C or E_S), the list of supported curves
Information on the ASN.1 syntax used for curves can be found in
Appendix A.2.
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 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
ASN/DER E_C, the client's supported curve list
ASN/DER E_S, the server's supported curve list
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 8, 2007 [Page 9]
Internet-Draft SSH ECC Algorithm Integration October 2006
5. ECMQV Key Exchange and Verification [ecmqv]
5.1. Description
The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key generation
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 their own key pairs and the other entities public keys, both
will derive the same secret.
The following is an informal discussion of ECMQV key exchange and
verification for a formal description see Section 5.2.
The key exchange starts with the communication, from the server to
the client, of the named curve that will be used for ephemeral key
generation. The server and the client generate ephemeral key pairs,
and exchange their public keys and use the ECMQV algorithm to derive
the shared key.
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 8, 2007 [Page 10]
Internet-Draft SSH ECC Algorithm Integration October 2006
In the following: C is the client; S is the server; curve is the
curve used to generate the host key; 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. S sends 'curve' containing the named curve that was used to
generate its ECC host keys.
2. C OPTIONALLY verifies that the 'curve' has an acceptable level of
security compared to the bulk encryption algorithm chosen during
algorithm negotiation, a good reference for key strength
comparison can be found in [11]. If C accepts 'curve' then it
uses the associated domain parameters to generate an ephemeral
ECC public/private key pair. C sends 'cPK'.
3. S MAY validate 'cPK' using, for example, algorithm A.16.10 of
[12]. S generates an ephemeral public/private key pair using
'curve'. S then generates 'K' using its private hostkey, its
private ephemeral key and 'cPK'. S computes 'H' (specified
below) and the message authentication code (MAC) tag 'T' =
HMAC(K,H). S then sends "K_S || sPK || T".
4. C MAY 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 for its 'H' and 'K'. 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 [4].
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 "ssh-
ecc" MUST be selected as the server host key algorithm. If "ssh-ecc"
is not in the clients name-list then both sides MUST disconnect.
Green & Stebila Expires April 8, 2007 [Page 11]
Internet-Draft SSH ECC Algorithm Integration October 2006
ECMQV Key Exchange relies on the ECC public key algorithm to provide
it with the necessary ECC server host key. ECMQV should support the
same set of curves that the ECC public key algorithm supports.
Required and recommended curve support is outlined in Appendix A.
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 generated with sufficient strength to ensure that the ECMQV
algorithm isn't the weakest point in the SSH encryption suite.
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 [4].
The hash algorithm 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:
+----------------+----------------+
| 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
varification. The algorithm for implementing HMAC with any of the
above hash functions can be found in [10].
The specificiation of the message numbers SSH_MSG_ECMQV_KEYTYPE,
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 [4]. This algorithm is necessary to generate the
ephemeral EC key pairs needed for ECMQV.
Green & Stebila Expires April 8, 2007 [Page 12]
Internet-Draft SSH ECC Algorithm Integration October 2006
This key exchange algorithm is implemented with the following
messages.
The server sends:
byte SSH_MSG_ECMQV_KEYTYPE
ASN/DER curve
Information on the ASN.1 syntax used for curve can be found in
Appendix A.
The client responds with:
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
ASN/DER curve, the named curve all the keys are based upon
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 8, 2007 [Page 13]
Internet-Draft SSH ECC Algorithm Integration October 2006
6. IANA Considerations
This document defines two new key exchange method names and one new
public key algorithm name in the SSH name registry. These additions
to the SSH namespace will have to be approved by the IANA.
New Key Exchange Algorithms:
"ecmqv"
"ecdh-exchange"
New Host Key Algorithms:
"ssh-ecc"
6.1. ssh-ecc
The "ssh-ecc" method specifies Elliptic Curve digital signature
algorithm (ECDSA) for use in signing communications with ECC host
keys. When used with ECMQV "ssh-ecc" provides ecmqv with a host key.
This method is discussed in Section 3.
6.2. ecdh-exchange
The "ecdh-exchange" method specifies Elliptic Curve Diffie-Hellman
with for key exchange as described in Section 4.
6.3. ecmqv
The "ecmqv" method specifies the use of Elliptic Curve Menezes-Qu-
Vanstone for Key Exchange as discussed in Section 5.
Green & Stebila Expires April 8, 2007 [Page 14]
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 [3] that may be redefined by any key
exchange method [2] 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_REQUEST 30
#define SSH_MSG_KEX_ECDH_INIT 31
#define SSH_MSG_KEX_ECDH_REPLY 32
7.2. ECMQV Message Numbers
#define SSH_MSG_ECMQV_KEYTYPE 30
#define SSH_MSG_ECMQV_INIT 31
#define SSH_MSG_ECMQV_REPLY 32
Green & Stebila Expires April 8, 2007 [Page 15]
Internet-Draft SSH ECC Algorithm Integration October 2006
8. Security Considerations
The Elliptic Curve Diffie-Hellman key agreement algorithm is defined
in [4], [12] and [13]. The appropriate security considerations of
those documents apply.
The Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm is
defined in [4]. 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
[16].
The methods defined in Section 4 rely on the SHA family of hashing
functions as defined in [9]. 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
[16].
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 [11].
Green & Stebila Expires April 8, 2007 [Page 16]
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. Curve is defined in ASN.1 syntax below.
curve ::= OBJECT IDENTIFIER UNIQUE
Appendix A.1. Required and Recommended Curves
Every SSH ECC implementation MUST support the named curves below,
these curves are defined in SEC2 [5].
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. Sending Lists of Curves
When lists of curves need to be sent to negotiate mutually supported
curves they are sent as a sequence of unique ASN.1 OIDS. The ASN.1
syntax of this curve list is shown below. This ASN.1 syntax is
encoded with DER and put into the appropriate packet.
curves::= SEQUENCE SIZE (1 ... 12) OF { curve }
Green & Stebila Expires April 8, 2007 [Page 17]
Internet-Draft SSH ECC Algorithm Integration October 2006
Appendix A.3. SEC Equivalent NIST Curves
+-----------+----------+
| SEC | NIST[14] |
+-----------+----------+
| sect163k1 | nistk163 |
| | |
| secp192r1 | nistp192 |
| | |
| secp224r1 | nistp224 |
| | |
| sect233k1 | nistk233 |
| | |
| sect233r1 | nistb233 |
| | |
| secp256r1 | nistp256 |
| | |
| sect283k1 | nistk283 |
| | |
| secp384r1 | nistp384 |
| | |
| sect409k1 | nistk409 |
| | |
| sect409r1 | nistb409 |
| | |
| secp521r1 | nistp521 |
| | |
| sect571k1 | nistk571 |
+-----------+----------+
OIDs for the above curves can be found in SEC2 Section A.2.1 and
A.2.2 [5].
Green & Stebila Expires April 8, 2007 [Page 18]
Internet-Draft SSH ECC Algorithm Integration October 2006
9. Acknowledgements
The author would like to thank Douglas Stebila who wrote
draft-stebila-secsh-ecdh-01, the ECDH portion of this draft is
largely an updated version of his document.
The author would also like to thank Robert Lambert of Certicom
for all the help and knowledge he provided.
This work was performed during an internship at Certicom from
Queens University.
Green & Stebila Expires April 8, 2007 [Page 19]
Internet-Draft SSH ECC Algorithm Integration October 2006
10. References
10.1. Normative References
[1] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell Protocol
Architecture", RFC 4251, January 2006.
[2] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell Transport
Layer Protocol", RFC 4253, January 2006.
[3] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell Protocol
Assigned Numbers", RFC 4250, January 2006.
[4] Standards for Efficient Cryptography Group, "Elliptic Curve
Cryptography", SEC 1, September 2000.
[5] Standards for Efficient Cryptography Group, "Recommended
Elliptic Curve Domain Parameters", SEC 2, September 2000.
[6] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[7] Internation Telecommunication Union, "Abstract Syntax Notation
One (ASN.1): Specification of basic notation", X. 680,
July 2002.
[8] Internation Telecommunication Union, "ASN.1 encoding rules",
X. 690, July 2002.
[9] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS 180-2, August 2002.
[10] National Institute of Standards and Technology, "Keyed-Hash
Message Authentication Code", FIPS 198, March 2002.
Green & Stebila Expires April 8, 2007 [Page 20]
Internet-Draft SSH ECC Algorithm Integration October 2006
10.2. Informative References
[11] National Institute of Standards and Technology, "Recommendation
for Key Management - Part 1", NIST Special Publication 800-57.
[12] Institute of Electrical and Electronics Engineers, "Standard
Specifications for Public Key Cryptography", IEEE 1363, 2000.
[13] 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.
[14] National Institute of Standards and Technology, "Recommended
Elliptic Curves for Federal Government Use", August 1999.
[15] American National Standards Institute, "Public Key Cryptography
For The Financial Services Industry The Elliptic Curve Digital
Signature Algorithm", ANSI X9.62, 1998.
[16] Hankerson, Menezes, and Vanstone, "Guide to Elliptic Curve
Cryptography", 2004, <urn:isbn:038795273X>.
Green & Stebila Expires April 8, 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
Douglas Stebila
Department of Combinatorics and Optimization
University of Waterloo
Waterloo, ON N2L 3G1
Canada
Email: douglas@stebila.ca
Green & Stebila Expires April 8, 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.
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 8, 2007 [Page 23]
