[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]
Versions: 00 01 02 03 04 05 06 07 08 09 10 11
12 RFC 4492
TLS Working Group Simon Blake-Wilson
INTERNET-DRAFT Tim Dierks
Expires: September 14, 2001 Chris Hawk
Certicom Corp.
15 March 2001
ECC Cipher Suites for TLS
<draft-ietf-tls-ecc-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. 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 may be found at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories may be found at
http://www.ietf.org/shadow.html.
Abstract
This document describes additions to TLS to support Elliptic Curve
Cryptography (ECC). In particular it defines new key exchange
algorithms which use the Elliptic Curve Digital Signature Algorithm
(ECDSA) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme
(ECDH), and it defines how to perform client authentication with ECDSA
and ECDH.
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 [MUST].
Please send comments on this document to the TLS mailing list.
Blake-Wilson, Dierks, Hawk [Page 1]
INTERNET-DRAFT 15 March 2001
Table of Contents
1. Introduction ................................................. 2
2. Elliptic Curve Key Exchange Algorithms ....................... 4
2.1. ECDH_ECDSA ................................................... 5
2.2. ECDH_ECDSA_EXPORT ............................................ 5
2.3. ECDH_RSA ..................................................... 6
2.4. ECDH_RSA_EXPORT .............................................. 6
2.5. ECDH_anon .................................................... 6
2.6. ECDH_anon_EXPORT ............................................. 6
3. ECC Client Authentication .................................... 7
3.1. ECDSA_sign ................................................... 7
3.2. ECDSA_fixed_ECDH ............................................. 8
3.3. RSA_fixed_ECDH ............................................... 9
4. Data Structures and Computations ............................. 9
4.1. Server Certificate .......................................... 10
4.2. Server Key Exchange ......................................... 11
4.3. Certificate Request ......................................... 15
4.4. Client Certificate .......................................... 15
4.5. Client Key Exchange ......................................... 16
4.6. Certificate Verify .......................................... 18
4.7. Computing the Master Secret ................................. 19
5. Cipher Suites ............................................... 19
6. Security Considerations ..................................... 20
7. Intellectual Property Rights ................................ 20
8. Acknowledgments ............................................. 21
9. References .................................................. 21
10. Authors' Addresses .......................................... 22
1. Introduction
This document describes additions to TLS to support Elliptic Curve
Cryptography (ECC). In particular, it defines:
- new key exchange algorithms which use the Elliptic Curve Digital
Signature Algorithm (ECDSA), and the Elliptic Curve Diffie-Hellman
Key Agreement Scheme (ECDH); and
- new client authentication methods which use ECDSA and ECDH.
In order to enable the use of these features within TLS, the document
defines enhanced data structures to convey the information that the
mechanisms need to exchange, the computational procedures involved in
the operation of the mechanisms, and new cipher suites based on the
mechanisms.
Blake-Wilson, Dierks, Hawk [Page 2]
INTERNET-DRAFT 15 March 2001
Use of ECC within TLS may provide both bandwidth and computational
savings compared to other public-key cryptographic techniques.
Furthermore, the efficiencies provided by ECC may increase as security
requirements increase based on Moore's law - this is illustrated by the
following table, based on [LEN], which gives approximate comparable key
sizes for symmetric systems, ECC systems, and DH/DSA/RSA systems based
on the running times of the best algorithms known today.
Symmetric | ECC | DH/DSA/RSA
80 | 163 | 1024
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Table 1: Comparable key sizes (in bits)
The savings that ECC may offer are likely to become increasingly
desirable with the widespread use of TLS by wireless devices -
discussed, for example, in [TLS-EXT].
This document assumes the reader is familiar with both ECC and TLS. ECC
is described in ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], IEEE
1363 [IEEE1363], and SEC 1 [SEC1]. TLS is described in RFC 2246 [TLS].
The choice of mechanisms included in this document was motivated by a
desire to provide mechanisms which are secure, which are as efficient
as possible, and which are capable of replicating all of the
functionality and operating modes found in the existing TLS mechanisms
based on integer factorization and discrete logarithm cryptographic
systems. TLS includes a substantial variety of functionality and
operating modes in consideration of the variety of applications with
which TLS is used.
The desire described above led to the inclusion of a substantial number
of ECC-based mechanisms. In order to encourage interoperability, a
small subset of the mechanisms are identified as "recommended" - these
mechanisms are capable of meeting the requirements of many
applications and they should therefore be used unless an application
profile of this document states otherwise, or unless in a particular
environment considerations such as export regulations mandate
otherwise.
The remainder of this document is organized as follows. Section 2
specifies key exchange algorithms for TLS using ECC. Section 3
specifies how client authentication is performed using ECC. Section 4
describes the TLS-specific data structures and computations involved in
the operation of the ECC mechanisms. Section 5 defines cipher suites
based on the ECC key exchange algorithms. Sections 6-8 discuss security
considerations, intellectual property rights, and acknowledgements
Blake-Wilson, Dierks, Hawk [Page 3]
INTERNET-DRAFT 15 March 2001
respectively. Section 9 supplies references cited elsewhere in the
document, and Section 10 gives the authors' contact details.
2. Elliptic Curve Key Exchange Algorithms
This document defines six new key exchange algorithms based on ECC for
use within TLS.
The table below summarizes the new key exchange algorithms.
Key
Exchange
Algorithm Description Key size limit
ECDH_ECDSA ECDH with ECDSA signatures None
ECDH_ECDSA_EXPORT ECDH with ECDSA signatures ECDH=163 bits,
ECDSA=none
ECDH_RSA ECDH with RSA signatures None
ECDH_RSA_EXPORT ECDH with RSA signatures ECDH=163 bits,
RSA = none
ECDH_anon Anonymous ECDH, no signatures None
ECDH_anon_EXPORT Anonymous ECDH, no signatures ECDH=163 bits
Table 2: Key exchange algorithms
Note that the key exchange algorithms marked "anon" do not provide
authentication of the server or the client, and, like other "anon" TLS
key exchange algorithms, may be subject to man-in-the-middle attacks.
Implementations of these algorithms SHOULD provide authentication by
other means.
The remainder of this section describes these key exchange algorithms
in detail. For each key exchange algorithm, this involves specification
of the contents of the handshake messages related to key exchange -
server certificate, server key exchange, client certificate, and client
key exchange - as well as specification of the computations involved in
the calculation of the master secret.
2.1. ECDH_ECDSA
ECDH is used to compute the master secret. The server is authenticated
via a certificate containing an ECDH public key signed with ECDSA.
Specifically this key exchange algorithm MUST proceed as follows:
- The server provides a static ECDH public key in the server
certificate message using the format described in Section 4.1. The
certificate is signed using ECDSA.
Blake-Wilson, Dierks, Hawk [Page 4]
INTERNET-DRAFT 20 January 2000
- The server key exchange message is not sent.
- Unless client authentication using ECDH is performed as specified in
Sections 3.2 and 3.3, the client provides an ephemeral ECDH public
key in the client key exchange message using the format described in
Section 4.5. In this case, the client certificate and certificate
verify message are not sent unless client authentication is performed
using ECDSA as specified in Section 3.1, or another signature
algorithm.
- If client authentication using ECDH is performed, the client provides
a static ECDH public key in the client certificate message using the
format described in Section 4.4. In this case an empty client key
exchange message is sent using the format described in Section 4.5, and
the certificate verify message is not sent.
- The client and server compute the master secret using their ECDH key
pairs as specified in Section 4.7.
ECDH computations for this key exchange algorithm are performed
according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the
ECSVDP-DH secret value derivation primitive, and the KDF1 key
derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are
performed according to ANSI X9.62 [ANSIX962] using the hash function
SHA-1 [FIPS180-1].
2.2. ECDH_ECDSA_EXPORT
Export-strength ECDH is used to compute the master secret. The server
is authenticated via a certificate containing an ECDH public key signed
with ECDSA.
This key exchange algorithm MUST proceed in the same way as ECDH_ECDSA,
except that the key size for ECDH public keys is constrained to 163
bits or less. Here the key size of an elliptic curve public key refers
to the size of the underlying finite field over which the elliptic
curve is defined.
2.3. ECDH_RSA
ECDH is used to compute the master secret. The server is authenticated
via a certificate containing an ECDH public key signed with RSA.
This key exchange MUST proceed in the same way as ECDH_ECDSA, except
that the server's certificate is signed with RSA.
Blake-Wilson, Dierks, Hawk [Page 5]
INTERNET-DRAFT 15 March 2001
2.4. ECDH_RSA_EXPORT
Export-strength ECDH is used to compute the master secret. The server
is authenticated via a certificate containing an ECDH public key signed
with RSA.
This key exchange algorithm MUST proceed in the same way as ECDH_RSA,
except that the key size for ECDH public keys is constrained to be 163
bits or less.
2.5. ECDH_anon
Anonymous ECDH is used to compute the master secret.
Specifically this key exchange algorithm MUST proceed as follows:
- The server certificate message is not sent.
- The server provides an ephemeral ECDH public key in the server key
exchange message using the format described in Section 4.2.
- The client certificate message is not sent.
- The client provides an ephemeral ECDH public key in the client key
exchange message using the format described in Section 4.5.
- The client and server compute the master secret using their ECDH
key pairs as specified in Section 4.7.
ECDH computations for this key exchange algorithm are performed
according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the
ECSVDP-DH secret value derivation primitive, and the KDF1 key
derivation primitive using SHA-1 [FIPS180-1].
2.6. ECDH_anon_EXPORT
Export-strength, anonymous ECDH is used to compute the master secret.
This key exchange algorithm MUST proceed in the same way as ECDH_anon,
except that the key size for ECDH public keys is constrained to 163
bits or less.
3. ECC Client Authentication
This document defines three new ECC-based client authentication methods
- ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH.
Blake-Wilson, Dierks, Hawk [Page 6]
INTERNET-DRAFT 15 March 2001
To encourage interoperability, implementations SHOULD support
ECDSA_fixed_ECDH. Implementations MAY support any of the other client
authentication methods.
The remainder of this section specifies these ECC-based client
authentication methods. The following information is provided for each
method: which key exchange algorithms the method may be used with, what
constraints apply to the method, and the formats of the certificate
request, client certificate, client key exchange, and certificate
verify messages.
3.1. ECDSA_sign
The client supplies a certificate containing an ECDSA public key, and
authenticates itself by signing the certificate verify message with its
ECDSA key pair.
This client authentication method MUST proceed as follows.
Applicable key exchange algorithms:
- This client authentication method is eligible for use with all the
non-anonymous ECC-based key exchange algorithms specified in Section
2, and all the existing non-anonymous TLS key exchange algorithms
specified in [TLS].
Restrictions:
- In order to perform this method, the client must possess a certified
ECDSA public key.
Message exchange:
- The server requests use of the ECDSA_sign method by sending a
certificate request message containing the value "ecdsa_sign" using
the format described in Section 4.3. When the client receives this
request, it checks that it possesses an appropriate certificate and
that it is willing to proceed.
- If the client proceeds, it sends its certificate containing its ECDSA
public key in the client certificate message using the format
described in Section 4.4. It signs the handshake messages exchanged
so far with its ECDSA key pair and conveys the resulting signature to
the server in the certificate verify message using the format
specified in Section 4.6.
Blake-Wilson, Dierks, Hawk [Page 7]
INTERNET-DRAFT 15 March 2001
- (If the client does not proceed, it may perform client authentication
using another method suggested by the server in the certificate
request message in which case the client certificate and the
certificate verify message are sent in accordance with the selected
method, or it may proceed with the key exchange without client
authentication - in which case the client certificate and certificate
verify messages are not sent.)
ECDSA computations for this client authentication method are performed
according to ANSI X9.62 [ANSIX962] using the hash function SHA-1
[FIPS180-1].
3.2. ECDSA_fixed_ECDH
The client supplies an ECDSA-signed certificate containing an ECDH
public key using the same elliptic curve domain parameters as the
server's ECDH public key. The client authenticates itself by computing
the master secret and the finished message. (This achieves
authentication because these computations can only be performed by a
party possessing the private key corresponding to one of the ECDH
public keys exchanged.)
This client authentication method MUST proceed as follows.
Applicable key exchange algorithms:
- This method is eligible for use with all the non-anonymous ECC-based
key exchange algorithms specified in Section 2.
Restrictions:
- In order to perform this client authentication method, the client
must possess an ECDSA-signed certificate containing an ECDH public
key using the same elliptic curve domain parameters as the ECDH
public key supplied by the server in the server certificate message.
Message exchange:
- The server requests use of the ECDSA_fixed_ECDH method by sending a
certificate request message containing the value "ecdsa_fixed_ecdh"
using the format described in Section 4.3. When the client receives
this request, it checks that it possesses an appropriate certificate
and that it is willing to proceed.
- If the client proceeds, it sends its certificate containing its ECDH
public key in the client certificate message using the format
described in Section 4.4. It sends an empty client key exchange
message using the format described in Section 4.5. It does not send
the certificate verify message. It uses its static ECDH key pair,
along with the server's ECDH public key) when computing the master
secret and finished message.
Blake-Wilson, Dierks, Hawk [Page 8]
INTERNET-DRAFT 15 March 2001
- (If the client does not proceed, it may perform client authentication
using another method suggested by the server in the certificate
request message, or it may proceed with the key exchange without
client authentication - in which case the client certificate and
certificate verify messages are not sent.)
ECDH computations for this key exchange algorithm are performed
according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the
ECSVDP-DH secret value derivation primitive, and the KDF1 key
derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are
performed according to ANSI X9.62 [ANSIX962] using the hash function
SHA-1 [FIPS180-1].
3.3. RSA_fixed_ECDH
The client supplies an RSA-signed certificate containing an ECDH
public key using the same elliptic curve domain parameters as the
server's ECDH public key. The client authenticates itself by computing
the master secret and the finished message. (This achieves
authentication because these computations can only be performed by a
party possessing the private key corresponding to one of the ECDH
public keys exchanged.)
This client authentication method MUST proceed in the same manner as
the ECDSA_fixed_ECDH method, except that the client's certificate must
be signed with RSA, and the server requests use of the method by
sending a certificate request message containing the value
"rsa_fixed_ecdh".
4. Data Structures and Computations
This section specifies the data structures and computations used by the
ECC-based mechanisms specified in Sections 2 and 3. The presentation
language used here is the same as that used in RFC 2246 [TLS]. Because
these specifications extend the TLS protocol specification, these
descriptions should be merged with those in TLS and in any other
specifications which extend TLS. This means that enum types may not
specify all the possible values and structures with multiple formats
chosen with a select() clause may not indicate all the possible cases.
4.1. Server Certificate
This message is sent in the following key exchange algorithms:
All the non-anonymous ECC-based key exchange algorithms specified in
Section 2.
Blake-Wilson, Dierks, Hawk [Page 9]
INTERNET-DRAFT 15 March 2001
Meaning of this message:
This message is used to authentically convey the server's static public
key to the client. The appropriate certificate types are given in the
following table.
Key Exchange Algorithm Certificate Type
ECDH_ECDSA ECC public key; the certificate must
allow the key to be used for key
agreement. The certificate must be
signed with ECDSA.
ECDH_ECDSA_EXPORT ECC public key which can be used for key
agreement; key size must be 163 bits or
less. Certificate must be signed with
ECDSA.
ECDH_RSA ECC public key which can be used for key
agreement. Certificate must be signed
with RSA.
ECDH_RSA_EXPORT ECC public key which can be used for key
agreement; key size must be 163 bits or
less. Certificate must be signed with
RSA.
Table 3: Server certificate types
[PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in
X.509 certificates. Servers SHOULD use the elliptic curve domain
parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2
[FIPS186-2], and SEC 2 [SEC2]. Note that - as with RSA - the same
identifier is used for all ECC keys in "SubjectPublicKeyInfo". The key
usage extension may be used to further delimit the use of the key. When
a key usage extension is present, the "keyAgreement" bit MUST be set
for ECDH certificates.
Structure of this message:
Identical to the TLS Certificate format.
Actions of the sender:
The server constructs an appropriate certificate chain and conveys it
to the client in the Certificate message.
Blake-Wilson, Dierks, Hawk [Page 10]
INTERNET-DRAFT 15 March 2001
Actions of the receiver:
The client validates the certificate chain, extracts the server's
public key, and checks that the key is of the correct type for the key
exchange algorithm.
4.2. Server Key Exchange
This message is sent in the following key exchange algorithms:
Both the anonymous ECC-based key exchange algorithms specified in
Section 2.
Meaning of this message:
This message is used to convey the server's ephemeral ECDH public key
(and the corresponding elliptic curve domain parameters) to the client.
Structure of this message:
The TLS ServerKeyExchange message is extended as follows.
enum { ec_diffie_hellman } KeyExchangeAlgorithm;
ec_diffie_hellman
Indicates the ServerKeyExchange message is to contain an ECDH public
key.
enum { explicit_prime (1), explicit_char2 (2),
named_curve (3), (255) } ECCurveType;
explicit_prime
Indicates the elliptic curve domain parameters will be conveyed
verbosely, and that the underlying finite field is a prime field.
explicit_char2
Indicates the elliptic curve domain parameters will be conveyed
verbosely, and that the underlying finite field is a characteristic 2
field.
named_curve
Indicates that a named curve will be used. The use of this option is
strongly recommended.
struct {
opaque a <1..2^8-1>;
opaque b <1..2^8-1>;
opaque seed <0..2^8-1>;
} ECCurve;
Blake-Wilson, Dierks, Hawk [Page 11]
INTERNET-DRAFT 15 March 2001
a, b
These parameters specify the coefficients of the elliptic curve. Each
value contains the byte string representation of a field element
following the conversion routine in [X9.62], section 4.3.3.
seed
This is an optional parameter used to derive the coefficients of a
randomly generated elliptic curve.
struct {
opaque point <1..2^8-1>;
} ECPoint;
point
This is the byte string representation of an elliptic curve point
following the conversion routine in [X9.62], section 4.3.6.
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
ec_basis_trinomial
Indicates representation of a characteristic two field using a
trinomial basis.
ec_basis_pentanomial
Indicates representation of a characteristic two field using a
pentanomial basis.
enum {
sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25), (255)
} NamedCurve;
sect163k1, etc
Indicates use of the corresponding recommended curve specified in SEC 2
[SEC2]. Note that many of these curves are also recommended in ANSI
X9.62 [ANSIX962], and FIPS 186-2 [FIPS186-2].
Blake-Wilson, Dierks, Hawk [Page 12]
INTERNET-DRAFT 15 March 2001
struct {
ECCurveType curve_type;
select (curve_type) {
case explicit_prime:
opaque prime_p <1..2^8-1>;
ECCurve curve;
ECPoint base;
opaque order <1..2^8-1>;
opaque cofactor <1..2^8-1>;
case explicit_char2:
uint16 m;
ECBasisType basis;
select (basis) {
case ec_trinomial:
opaque k <1..2^8-1>;
case ec_pentanomial:
opaque k1 <1..2^8-1>;
opaque k2 <1..2^8-1>;
opaque k3 <1..2^8-1>;
};
ECCurve curve;
ECPoint base;
opaque order <1..2^8-1>;
opaque cofactor <1..2^8-1>;
case named_curve:
NamedCurve namedcurve;
};
} ECParameters;
curve_type
This identifies the type of the elliptic curve domain parameters.
prime_p
This is the odd prime defining the field Fp.
curve
Specifies the coefficients a and b of the elliptic curve E.
base
Specifies the base point G on the elliptic curve.
order
Specifies the order n of the base point.
cofactor
Specifies the cofactor h = #E(Fq)/n, where #E(Fq) represents the number
of points on the elliptic curve E defined over the field Fq.
m
This is the degree of the characteristic-two field F2^m.
Blake-Wilson, Dierks, Hawk [Page 13]
INTERNET-DRAFT 15 March 2001
k
The exponent k for the trinomial basis representation x^m+x^k+1.
k1, k2, k3
The exponents for the pentanomial representation x^m+x^k3+x^k2+x^k1+1.
namedcurve
Specifies a recommended set of elliptic curve domain parameters.
struct {
ECParameters curve_params;
ECPoint public;
} ServerECDHParams;
curve_params
Specifies the elliptic curve domain parameters associated with the
ECDH public key.
public
The ephemeral ECDH public key.
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman:
ServerECDHParams params;
Signature signed_params;
} ServerKeyExchange;
params
Specifies the ECDH public key and associated domain parameters.
signed_params
This element is empty for all the key exchange algorithms specified in
this document.
Actions of the sender:
The server selects elliptic curve domain parameters and an ephemeral
ECDH public key corresponding to these parameters according to the
ECKAS-DH1 scheme from IEEE 1363 [IEEE1363]. It conveys this information
to the client in the ServerKeyExchange message using the format defined
above.
Actions of the recipient:
The client retrieves the server's elliptic curve domain parameters and
ephemeral ECDH public key from the ServerKeyExchange message.
Blake-Wilson, Dierks, Hawk [Page 14]
INTERNET-DRAFT 15 March 2001
4.3. Certificate Request
This message is sent when requesting the following client
authentication methods:
Any of the ECC-based client authentication methods specified in
Section 3.
Meaning of this message:
The server uses this message to indicate which client authentication
methods the server would like to use.
Structure of this message:
The TLS CertificateRequest message is extended as follows.
enum {
ecdsa_sign (5), rsa_fixed_ecdh (6),
ecdsa_fixed_ecdh(7), (255)
} ClientCertificateType;
ecdsa_sign, etc
Indicates that the server would like to use the corresponding client
authentication method specified in Section 3.
Actions of the sender:
The server decides which client authentication methods it would like to
use, and conveys this information to the client using the format
defined above.
Actions of the receiver:
The client determines whether it has an appropriate certificate for use
with any of the requested methods, and decides whether or not to
proceed with client authentication.
4.4. Client Certificate
This message is sent in the following client authentication methods:
All the ECC-based client authentication methods specified in Section 3.
Meaning of this message:
This message is used to authentically convey the client's static public
key to the server. The appropriate certificate types are given in the
following table.
Blake-Wilson, Dierks, Hawk [Page 15]
INTERNET-DRAFT 15 March 2001
Client Authentication Certificate Type
Method
ECDSA_sign ECC public key which can be used for
signing.
ECDSA_fixed_ECDH ECC public key which can be used for key
agreement. Certificate must be signed
with ECDSA.
RSA_fixed_ECDH ECC public key which can be used for key
agreement. Certificate must be signed
with RSA.
Table 4: Client certificate types
[PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in
X.509 certificates. Clients SHOULD use the elliptic curve domain
parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2
[FIPS186-2], and SEC 2 [SEC2]. Note that - as with RSA - the same
identifier is used for all ECC keys in "SubjectPublicKeyInfo". The key
usage extension may be used to further delimit the use of the key. When
a key usage extension is present, the "keyAgreement" bit MUST be set
for ECDH certificates, and the "digitalSignature" bit MUST be set for
ECDSA certificates.
Structure of this message:
Identical to the TLS Certificate format.
Actions of the sender:
The client constructs an appropriate certificate chain, and conveys it
to the server in the Certificate message.
Actions of the receiver:
The TLS server validates the certificate chain, extracts the client's
public key, and checks that the key is of the correct type for the
client authentication method.
4.5. Client Key Exchange
This message is sent in the following key exchange algorithms:
All the ECC-based key exchange algorithms specified in Section 2. If
client authentication with fixed ECDH is not being used, the message
contains the client's ephemeral ECDH public key, otherwise the message
is empty.
Blake-Wilson, Dierks, Hawk [Page 16]
INTERNET-DRAFT 15 March 2001
Meaning of the message:
This message is used to convey ephemeral data relating to the key
exchange belonging to the client (such as its ephemeral ECDH public
key).
Structure of this message:
The TLS ClientKeyExchange message is extended as follows.
enum { yes, no } EphemeralPublicKey;
yes, no
Indicates whether or not the client is providing an ephemeral ECDH
public key.
struct {
select (EphemeralPublicKey) {
case yes: ECPoint ecdh_Yc;
case no: struct { };
} ecdh_public;
} ClientECDiffieHellmanPublic;
ecdh_Yc
Contains the client's ephemeral ECDH public key.
struct {
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
Actions of the sender:
The client selects an ephemeral ECDH public key corresponding to the
parameters it received from the server according to the ECKAS-DH1
scheme from IEEE 1363 [IEEE1363]. It conveys this information to the
client in the ClientKeyExchange message using the format defined
above.
Actions of the recipient:
The server retrieves the client's ephemeral ECDH public key from the
ServerKeyExchange message and checks that the public key represents a
point of the elliptic curve.
Blake-Wilson, Dierks, Hawk [Page 17]
INTERNET-DRAFT 15 March 2001
4.6. Certificate Verify
This message is sent in the following client authentication methods:
ECDSA_sign
Meaning of the message:
This message contains an ECDSA signature on the handshake messages in
order to authenticate the client to the server.
Structure of this message:
The TLS CertificateVerify message is extended as follows.
enum { ec_dsa } SignatureAlgorithm;
select (SignatureAlgorithm) {
case ec_dsa:
digitally-signed struct {
opaque sha_hash[20];
};
} Signature;
In the CertificateVerify message, the signature field contains the
client's ECDSA signature on the handshake messages exchanged so far.
According to [ANSIX962], the signature consists of a pair of integers r
and s. These integers are both converted into byte strings of the same
length as the curve order n using the conversion routine specified in
Section 4.3.1 of [ANSIX962], the two byte strings are concatenated, and
the result is placed in the signature field.
Actions of the sender:
The client computes its signature over the handshake messages exchanged
so far using its ECDSA key pair with ECDSA computations performed as
specified in [ANSIX962] with the hash function SHA-1 [FIPS186-2]. The
client conveys its signature to the server in the CertificateVerify
message using the format defined above.
Actions of the receiver:
The server extracts the client's signature from the CertificateVerify
message, and verifies the signature using the client's ECDSA public key
that it received in the ClientCertificate message.
Blake-Wilson, Dierks, Hawk [Page 18]
INTERNET-DRAFT 15 March 2001
4.7. Computing the Master Secret
In all the ECC-based key exchange algorithms specified in Section 2,
the client and server compute the master key as follows:
- They both compute a single shared secret K of length 20 bytes using
their ECDH key pairs with ECDH computations performed as specified by
the ECKAS-DH1 scheme in [IEEE1363] with the ECSVDP-DH secret value
derivation primitive, and the KDF1 key derivation primitive using
SHA-1 [FIPS180-1].
- They both use K as the pre_master_secret, and compute the
master_secret from the pre_master_secret as specified in [TLS].
5. Cipher Suites
The table below defines the cipher suites specified in this document
for use with the key exchange algorithms specified in Section 2.
CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 }
CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 }
CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 }
CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C }
CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x4B }
CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_56_SHA = { 0x00, 0x4C }
CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x4D }
CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x4E }
CipherSuite TLS_ECDH_RSA_WITH_DES_CBC_SHA = { 0x00, 0x4F }
CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x50 }
CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x51 }
CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x52 }
CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x53 }
CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_56_SHA = { 0x00, 0x54 }
CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x55 }
CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x56 }
CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA = { 0x00, 0x57 }
CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x58 }
CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x59 }
CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA = { 0x00, 0x5A }
Table 5: TLS ECC cipher suites
The key exchange method, cipher, and hash algorithm for each of these
cipher suites are easily determined by examining the name. Ciphers
other than AES ciphers, and hash algorithms are defined in [TLS]. AES
ciphers are defined in [TLS-AES].
Blake-Wilson, Dierks, Hawk [Page 19]
INTERNET-DRAFT 15 March 2001
The cipher suites which use the "NULL" cipher or one of the "EXPORT"
key exchange algorithms are considered to be "exportable" cipher suites
for the purposes of the TLS protocol.
Use of the following cipher suites is recommended in general - server
implementations SHOULD support all of these cipher suites, and client
implementations SHOULD support at least one of them:
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
Implementations MAY support any of the other cipher suites.
6. Security Considerations
This document is entirely concerned with security mechanisms.
This document is based on [TLS], [ANSIX9.62], and [IEEE1363] and the
appropriate security considerations of those documents apply.
In addition implementers should take care to ensure that code which
controls security mechanisms is free of errors which might be exploited
by attackers.
7. Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in
regard to the specification contained in this document. For more
information, consult the online list of claimed rights
(http://www.ietf.org/ipr.html).
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
8. Acknowledgments
The authors wish to thank Bill Anderson, Paul Fahn, Gilles Garon, John
Kennedy, and Brian Minard for their help preparing this document.
Blake-Wilson, Dierks, Hawk [Page 20]
INTERNET-DRAFT 15 March 2001
9. References
[ANSIX9.62] ANSI X9.62-1999, "Public Key Cryptography For The Financial
Services Industry: The Elliptic Curve Digital Signature
Algorithm (ECDSA)", American National Standards Institute,
1998.
[FIPS180] FIPS 180-1, "Secure Hash Standard", National Institute of
Standards and Technology, 1995.
[FIPS186-2] FIPS 186-2, "Digital Signature Standard", National Institute
of Standards and Technology, 2000.
[IEEE1363] IEEE 1363, "Standard Specifications for Public Key
Cryptography", Institute of Electrical and Electronics
Engineers, 2000.
[MUST] S. Bradner, "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[PKIX-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and CRL Profile", PKIX Working
Group Internet-Draft, draft-ietf-pkix-ipki-pkalgs-02.txt,
March 2001.
[PKIX-CERT] W. Ford, R. Housley, W. Polk and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", PKIX
Working Group Internet-Draft,
draft-ietf-pkix-new-part1-05.txt, March 2001.
[SEC1] SEC 1, "Elliptic Curve Cryptography", Standards for Efficient
Cryptography Group, 2000.
[SEC2] SEC 2, "Recommended Elliptic Curve Domain Parameters",
Standards for Efficient Cryptography Group, 2000.
[TLS] T. Dierks and C. Allen, "The TLS Protocol - Version 1.0,"
IETF RFC 2246, January 1999.
[TLS-AES] P. Chown, "AES Ciphersuites for TLS", TLS Working Group
Internet-Draft, draft-ietf-tls-ciphersuite-03.txt,
January 2001.
[TLS-EXT] S. Blake-Wilson and M. Nystrom, "Wireless Extensions to TLS",
TLS Working Group Internet-Draft,
draft-ietf-tls-wireless-00.txt, November 2000.
Blake-Wilson, Dierks, Hawk [Page 21]
INTERNET-DRAFT 15 March 2001
10. Authors' Addresses
Authors:
Simon Blake-Wilson
Certicom Corp.
sblake-wilson@certicom.com
Tim Dierks
Certicom Corp.
timd@consensus.com
Chris Hawk
Certicom Corp.
chawk@certicom.com
Blake-Wilson, Dierks, Hawk [Page 22]
Html markup produced by rfcmarkup 1.123, available from
https://tools.ietf.org/tools/rfcmarkup/