Secure Shell Working Group J. Green
Internet-Draft Queen's University
Expires: April 17, 2008 D. Stebila
University Waterloo
October 15, 2007
Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer
draft-green-secsh-ecc-02
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 17, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Green & Stebila Expires April 17, 2008 [Page 1]
Internet-Draft SSH ECC Algorithm Integration October 2007
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ECC Public Key Algorithm . . . . . . . . . . . . . . . . . . . 5
3.1. Key Format . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Signature Algorithm . . . . . . . . . . . . . . . . . . . 5
3.3. Signature Encoding . . . . . . . . . . . . . . . . . . . . 5
4. ECDH Key Exchange . . . . . . . . . . . . . . . . . . . . . . 6
5. ECMQV Key Exchange . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. ECC Public Key Algorithm Identifiers . . . . . . . . . . . 12
6.2. ECDH Key Exchange Method Names . . . . . . . . . . . . . . 12
6.3. ECMQV Key Exchange and Verification Method Name . . . . . 13
7. Key Exchange Messages . . . . . . . . . . . . . . . . . . . . 14
7.1. ECDH Message Numbers . . . . . . . . . . . . . . . . . . . 14
7.2. ECMQV Message Numbers . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
Appendix A. Named Elliptic Curve Domain Parameters . . . . . . . 16
Appendix A.1. Required and Recommended Curves . . . . . . . . . . 16
Appendix A.2. SEC Equivalent NIST Curves and OIDs . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Green & Stebila Expires April 17, 2008 [Page 2]
Internet-Draft SSH ECC Algorithm Integration October 2007
1. Introduction
Due to its inclusion in NSA's Suite 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 Suite B algorithms to SSH this document
adds three ECC Suite 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).
Implementation of this specification requires familiarity with both
SSH [2] [3] [4] and ECC [6] [10] [11].
This document is concerned with SSH implementation details;
specification of the underlying cryptographic algorithms is left to
other standards documents.
Comments on this draft are solicited and should be addressed to Jon
Green <3jg19@qlink.queensu.ca>.
Green & Stebila Expires April 17, 2008 [Page 3]
Internet-Draft SSH ECC Algorithm Integration October 2007
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 characteristic-2
curve is defined as the number of bits in the binary representation
of the field, commonly denoted m.
Green & Stebila Expires April 17, 2008 [Page 4]
Internet-Draft SSH ECC Algorithm Integration October 2007
3. ECC Public Key Algorithm
The ECC public key algorithm is defined by its key format, signature
algorithm, signature encoding and algorithm identifiers.
The family of public key algorithm identifiers for ECC are specified
in Section 6.1, for the remainder of this section they are noted as
[identifier]. The identifier specified the elliptic curve domain
parameters to be used in the public key algorithm.
Information on the required and recommended sets of elliptic curve
domain parameters for use with this algorithm can be found in
Appendix A.
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 a private key, an integer d, and a
public key, an elliptic curve point Q.
3.1. Key Format
The ECC key format has the following specific encoding:
string [identifier]
string Q
Here, Q is the public key encoded from an elliptic curve point into
an octet string as defined in Section 2.3.3 of SEC1 [6].
3.2. Signature Algorithm
Signing and verifying is done using the Elliptic Curve Digital
Signature Algorithm (ECDSA). ECDSA is specified in [6] and in [13].
The message hashing algorithm MUST be the same one specified to
generate the exchange hash by the key exchange method. In the event
that the chosen key exchange method doesn't specify a hashing
function then SHA-256 [5] will be used.
3.3. Signature Encoding
Signatures are encoded as follows:
string [identifier]
mpint r
mpint s
Where the integers R and S are the output of the ECDSA algorithm.
Green & Stebila Expires April 17, 2008 [Page 5]
Internet-Draft SSH ECC Algorithm Integration October 2007
4. ECDH Key Exchange
The Elliptic Curve Diffie-Hellman (ECDH) key exchange method
generates a shared secret from an ephemeral elliptic curve local
private key and remote public key. This key exchange method provides
explicit server authentication as defined in [3] using a signature on
the exchange hash.
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 [6]. The algorithm for key pair generation can
be found in Section 3.2 of SEC1 [6].
The family of key exchange method names defined for use with this key
exchange can be found in Section 6.2. Algorithm negotiation chooses
the public key algorithm to be used for signing and the method name
of the key exchange. The method name 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 Appendix A.
All elliptic curve public keys MUST be validated after they are
received. An example of a validation algorithm can be found in
A.16.10 of [10]. 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 SEC1 Section 2.3 [6]. The output of shared key
generation is a field element xp. The ssh framework requires that
the shared key be be an integer. The conversion between a field
element and an integer is specified in Section 2.3.9 of SEC1 [6].
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 17, 2008 [Page 6]
Internet-Draft SSH ECC Algorithm Integration October 2007
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 servers signature.
*It is recommended that the client verify that the host key sent is
the servers host key (Using certificates or a local database). The
client is allowed to accept the host key without verification, but
doing so will render the protocol insecure against active attacks.
This is implemented using the following messages.
The client sends:
byte SSH_MSG_KEX_ECDH_INIT
string client's ephemeral public key octet string
The server responds with:
byte SSH_MSG_KEX_ECDH_REPLY
string server's public host key and/or certificates
string server's ephemeral public key octet string
string the signature on the exchange hash
Green & Stebila Expires April 17, 2008 [Page 7]
Internet-Draft SSH ECC Algorithm Integration October 2007
The exchange hash H is computed as the hash of the concatenation of
the following.
string client's version string (CR and NL excluded)
string server's version string (CR and NL excluded)
string payload of the client's SSH_MSG_KEXINIT
string payload of the server's SSH_MSG_KEXINIT
string server's public host key
string client's ephemeral public key octet string
string server's ephemeral public key octet string
mpint shared secret
Green & Stebila Expires April 17, 2008 [Page 8]
Internet-Draft SSH ECC Algorithm Integration October 2007
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 [3].
The key exchange method name defined for use with this key exchange
is "ecmqv-sha2". This method name gives a hashing algorithm that is
to be used for the HMAC below. Future RFCs may define new method
names specifying new hash algorithms for use with ECMQV. More
information about the method name and HMAC can be found in
Section 6.3.
In general the ECMQV key exchange is performed using the ephemeral
and long term key pair of both the client and server, a total of 4
keys. Within the framework of SSH the client does not have a long
term key pair that needs to be authenticated. Therefore we generate
an ephemeral key and use that as both the clients keys. This does
not adversely affect security and is more efficient then using two
different ephemeral keys.
A full description of ECMQV primitive can be found in Section 3.4 of
SEC1 [6]. The algorithm for key pair generation can be found in
Section 3.2 of SEC1 [6].
During algorithm negotiation with the SSH_MSG_KEXINIT messages the
ECMQV key exchange method can only be chosen if a Public Key
Algorithm supporting ECC host keys can also be chosen. This is due
to the use of implicit server authentication in this key exchange
method. This case is handled the same way that key exchange methods
requiring encryption/signature capable public key algorithms are
handled in Section 7.1 of RFC4253 [3]. 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
A.16.10 of [10]. If a key fails validation the key exchange MUST
fail.
Green & Stebila Expires April 17, 2008 [Page 9]
Internet-Draft SSH ECC Algorithm Integration October 2007
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 SEC1 Section 2.3 [6]. The output of shared key
generation is a field element xp. The ssh framework requires that
the shared key be be an integer. The conversion between a field
element and an integer is specified in Section 2.3.9 of SEC1 [6].
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_ECDH_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 servers host key (Using certificates or a local database). The
client is allowed to accept the host key without verification, but
doing so will render the protocol insecure against active attacks.
The specification of the message numbers SSH_MSG_ECMQV_INIT and
SSH_MSG_ECMQV_REPLY can be found in Section 7.
Green & Stebila Expires April 17, 2008 [Page 10]
Internet-Draft SSH ECC Algorithm Integration October 2007
This key exchange algorithm is implemented with the following
messages.
The client sends:
byte SSH_MSG_ECMQV_INIT
string client's ephemeral public key octet string
The server sends:
byte SSH_MSG_ECMQV_REPLY
string server's public host key octet string
string 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 client's version string (CR and NL excluded)
string server's version string (CR and NL excluded)
string payload of the client's SSH_MSG_KEXINIT
string payload of the server's SSH_MSG_KEXINIT
string client's ephemeral public key octet
string server's public host key octet
string server's ephemeral public key octet
mpint shared secret
Green & Stebila Expires April 17, 2008 [Page 11]
Internet-Draft SSH ECC Algorithm Integration October 2007
6. IANA Considerations
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. These additions to the SSH name
space will have to be approved the IANA.
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]. A list of the required and recommended
curves and their OIDs can be found in Appendix A.
For example: the identifier for a server with host keys generated on
the secp256r1 curve would be "secg-ecc-1.2.840.10045.3.1.7".
The concatenation of any ASN.1 OID specifying a set of elliptic curve
domain parameters with "secg-ecc-" is implicitly registered under
this specification.
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]. A list of the required and recommended
curves and their OIDs can be found in Appendix A.
For example: The method name for ECDH key exchange with ephemeral
keys generated on the sect409k1 curve would be "ecdh-sha2-
1.3.132.0.36".
The hashing algorithm defined by this family of method names is the
SHA2 family of hashing algorithms [5]. The hashing algorithm is
defined in the method name to allow room for other algorithms to be
defined in future documents.
Green & Stebila Expires April 17, 2008 [Page 12]
Internet-Draft SSH ECC Algorithm Integration October 2007
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:
+----------------+----------------+
| Curve Size | Hash Algorithm |
+----------------+----------------+
| b <= 256 | SHA-256 |
| | |
| 256 < b <= 384 | SHA-384 |
| | |
| 384 < b | SHA-512 |
+----------------+----------------+
The concatenation of any ASN.1 OID specifying a set of elliptic curve
domain parameters with "ecdh-sha2-" is implicitly registered under
this specification.
6.3. ECMQV Key Exchange and Verification Method Name
The Elliptic Curve Menezes-Qu-Vanstone key exchange is defined by the
method name "ecmqv-sha2". Unlike the other names specified here,
ECMQV relies on a public key algorithm that supports ECC keys
therefore it doesn't 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.
The hashing algorithm defined by this method name is the SHA2 family
of hashing algorithms [5]. 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:
+----------------+----------------+
| Curve Size | Hash Algorithm |
+----------------+----------------+
| b <= 256 | SHA-256 |
| | |
| 256 < b <= 384 | SHA-384 |
| | |
| 384 < b | SHA-512 |
+----------------+----------------+
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 RFC 4634 [5].
Green & Stebila Expires April 17, 2008 [Page 13]
Internet-Draft SSH ECC Algorithm Integration October 2007
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 17, 2008 [Page 14]
Internet-Draft SSH ECC Algorithm Integration October 2007
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 servers host key is used in the ECMQV key exchange algorithm.
This means that the strength of the servers ECC host key determines
that strength of the ECMQV key exchange algorithm. This should be
taken into consideration when generating ECC keys for a server.
The methods defined in Section 6 rely on the SHA2 family of hashing
functions as defined in [15]. The appropriate security
considerations of that document apply.
The hashing algorithms defined for use with ECDH and ECMQV are
defined by their method names so that if security problems are found
with the SHA2 family of hashing algorithms or more secure hashing
algorithms become the standard then future documents can extend this
document to include new hashing algorithms by defining new method
names.
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 17, 2008 [Page 15]
Internet-Draft SSH ECC Algorithm Integration October 2007
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 secp521r1 secp384r1
It is RECOMMENDED that SSH ECC implementations also support the
following curves.
sect163k1 sect233k1 sect233r1 sect283k1
sect409k1 sect409r1 sect571k1
secp192r1 secp224r1
Green & Stebila Expires April 17, 2008 [Page 16]
Internet-Draft SSH ECC Algorithm Integration October 2007
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 17, 2008 [Page 17]
Internet-Draft SSH ECC Algorithm Integration October 2007
9. References
9.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 17, 2008 [Page 18]
Internet-Draft SSH ECC Algorithm Integration October 2007
9.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 17, 2008 [Page 19]
Internet-Draft SSH ECC Algorithm Integration October 2007
Authors' Addresses
Jon Green
Queen's University
Email: 3jg19@qlink.queensu.ca
Douglas Stebila
Department of Combinatorics and Optimization
University of Waterloo
Waterloo, ON N2L 3G1
Canada
Email: douglas@stebila.ca
Green & Stebila Expires April 17, 2008 [Page 20]
Internet-Draft SSH ECC Algorithm Integration October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Green & Stebila Expires April 17, 2008 [Page 21]
