< draft-ietf-tls-ecc-01.txt   draft-ietf-tls-ecc-02.txt >
TLS Working Group Simon Blake-Wilson TLS Working Group V. Gupta
INTERNET-DRAFT Tim Dierks Internet-Draft Sun Labs
Expires: September 14, 2001 Chris Hawk Expires: February 27, 2003 S. Blake-Wilson
Certicom Corp. BCI
15 March 2001 B. Moeller
Technische Universitaet Darmstadt
C. Hawk
Independent Consultant
August 29, 2002
ECC Cipher Suites for TLS ECC Cipher Suites for TLS
<draft-ietf-tls-ecc-01.txt> <draft-ietf-tls-ecc-02.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 Status of this Memo
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 This document is an Internet-Draft and is in full conformance with
http://www.ietf.org/ietf/1id-abstracts.txt all provisions of Section 10 of RFC2026.
The list of Internet-Draft Shadow Directories may be found at Internet-Drafts are working documents of the Internet Engineering
http://www.ietf.org/shadow.html. Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Abstract 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."
This document describes additions to TLS to support Elliptic Curve The list of current Internet-Drafts can be accessed at http://
Cryptography (ECC). In particular it defines new key exchange www.ietf.org/ietf/1id-abstracts.txt.
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", The list of Internet-Draft Shadow Directories can be accessed at
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this http://www.ietf.org/shadow.html.
document are to be interpreted as described in RFC 2119 [MUST].
Please send comments on this document to the TLS mailing list. This Internet-Draft will expire on February 27, 2003.
Table of Contents Copyright Notice
1. Introduction ................................................. 2 Copyright (C) The Internet Society (2002). All Rights Reserved.
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 Abstract
This document describes additions to TLS to support Elliptic Curve This document describes new key exchange algorithms based on Elliptic
Cryptography (ECC). In particular, it defines: Curve Cryptography (ECC) for the TLS (Transport Layer Security)
protocol. In particular, it specifies the use of Elliptic Curve
Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
authentication mechanism.
- new key exchange algorithms which use the Elliptic Curve Digital The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Signature Algorithm (ECDSA), and the Elliptic Curve Diffie-Hellman "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Key Agreement Scheme (ECDH); and document are to be interpreted as described in RFC 2119 [1].
- new client authentication methods which use ECDSA and ECDH. Please send comments on this document to the TLS mailing list.
In order to enable the use of these features within TLS, the document Table of Contents
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.
Use of ECC within TLS may provide both bandwidth and computational 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
savings compared to other public-key cryptographic techniques. 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 5
Furthermore, the efficiencies provided by ECC may increase as security 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6
requirements increase based on Moore's law - this is illustrated by the 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . 7
following table, based on [LEN], which gives approximate comparable key 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
sizes for symmetric systems, ECC systems, and DH/DSA/RSA systems based 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7
on the running times of the best algorithms known today. 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Client Authentication . . . . . . . . . . . . . . . . . . . . 9
3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Data Structures and Computations . . . . . . . . . . . . . . . 11
4.1 Server Certificate . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Server Key Exchange . . . . . . . . . . . . . . . . . . . . . 12
4.3 Certificate Request . . . . . . . . . . . . . . . . . . . . . 17
4.4 Client Certificate . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Client Key Exchange . . . . . . . . . . . . . . . . . . . . . 19
4.6 Certificate Verify . . . . . . . . . . . . . . . . . . . . . . 20
4.7 Elliptic Curve Certificates . . . . . . . . . . . . . . . . . 22
4.8 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . . 22
5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 27
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31
Symmetric | ECC | DH/DSA/RSA 1. Introduction
80 | 163 | 1024
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Table 1: Comparable key sizes (in bits) Elliptic Curve Cryptography (ECC) is emerging as an attractive
public-key cryptosystem for mobile/wireless environments. Compared
to currently prevalent cryptosystems such as RSA, ECC offers
equivalent security with smaller key sizes. This is illustrated in
the following table, based on [2], which gives approximate comparable
key sizes for symmetric- and asymmetric-key cryptosystems based on
the best-known algorithms for attacking them.
The savings that ECC may offer are likely to become increasingly Symmetric | ECC | DH/DSA/RSA
desirable with the widespread use of TLS by wireless devices - -------------+---------+------------
discussed, for example, in [TLS-EXT]. 80 | 163 | 1024
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
This document assumes the reader is familiar with both ECC and TLS. ECC Table 1: Comparable key sizes (in bits)
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 Smaller key sizes result in power, bandwidth and computational
desire to provide mechanisms which are secure, which are as efficient savings that make ECC especially attractive for constrained
as possible, and which are capable of replicating all of the environments.
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 This document describes additions to TLS to support ECC. In
of ECC-based mechanisms. In order to encourage interoperability, a particular, it defines
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 o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement
specifies key exchange algorithms for TLS using ECC. Section 3 scheme with long-term or ephemeral keys to establish the TLS
specifies how client authentication is performed using ECC. Section 4 premaster secret, and
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
respectively. Section 9 supplies references cited elsewhere in the
document, and Section 10 gives the authors' contact details.
2. Elliptic Curve Key Exchange Algorithms o the use of fixed-ECDH certificates and ECDSA for authentication of
TLS peers.
This document defines six new key exchange algorithms based on ECC for The remainder of this document is organized as follows. Section 2
use within TLS. provides an overview of ECC-based key exchange algorithms for TLS.
Section 3 describes the use of ECC certificates for client
authentication. Section 4 specifies various data structures needed
for an ECC-based handshake, their encoding in TLS messages and the
processing of those messages. Section 5 defines new ECC-based cipher
suites and identifies a small subset of these as recommended for all
implementations of this specification. Section 6, Section 7 and
Section 8 mention security considerations, intellectual property
rights, and acknowledgments, respectively. This is followed by a
list of references cited in this document and the authors' contact
information.
The table below summarizes the new key exchange algorithms. Implementation of this specification requires familiarity with both
TLS [3] and ECC [5][6][7][8] .
Key 2. Key Exchange Algorithms
Exchange
Algorithm Description Key size limit
ECDH_ECDSA ECDH with ECDSA signatures None This document introduces five new ECC-based key exchange algorithms
ECDH_ECDSA_EXPORT ECDH with ECDSA signatures ECDH=163 bits, for TLS. All of them use ECDH to compute the TLS premaster secret
ECDSA=none and differ only in the lifetime of ECDH keys (long-term or ephemeral)
ECDH_RSA ECDH with RSA signatures None and the mechanism (if any) used to authenticate them. The derivation
ECDH_RSA_EXPORT ECDH with RSA signatures ECDH=163 bits, of the TLS master secret from the premaster secret and the subsequent
RSA = none generation of bulk encryption/MAC keys and initialization vectors is
ECDH_anon Anonymous ECDH, no signatures None independent of the key exchange algorithm and not impacted by the
ECDH_anon_EXPORT Anonymous ECDH, no signatures ECDH=163 bits introduction of ECC.
Table 2: Key exchange algorithms The table below summarizes the new key exchange algorithms which
mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [3]),
respectively.
Note that the key exchange algorithms marked "anon" do not provide Key
authentication of the server or the client, and, like other "anon" TLS Exchange
key exchange algorithms, may be subject to man-in-the-middle attacks. Algorithm Description
Implementations of these algorithms SHOULD provide authentication by --------- -----------
other means.
The remainder of this section describes these key exchange algorithms ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.
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 ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
ECDH is used to compute the master secret. The server is authenticated ECDH_RSA Fixed ECDH with RSA-signed certificates.
via a certificate containing an ECDH public key signed with ECDSA.
Specifically this key exchange algorithm MUST proceed as follows: ECDHE_RSA Ephemeral ECDH with RSA signatures.
- The server provides a static ECDH public key in the server ECDH_anon Anonymous ECDH, no signatures.
certificate message using the format described in Section 4.1. The
certificate is signed using ECDSA.
- The server key exchange message is not sent. Table 2: ECC key exchange algorithms
- Unless client authentication using ECDH is performed as specified in Note that the anonymous key exchange algorithm does not provide
Sections 3.2 and 3.3, the client provides an ephemeral ECDH public authentication of the server or the client. Like other anonymous TLS
key in the client key exchange message using the format described in key exchanges, it is subject to man-in-the-middle attacks.
Section 4.5. In this case, the client certificate and certificate Implementations of this algorithm SHOULD provide authentication by
verify message are not sent unless client authentication is performed other means.
using ECDSA as specified in Section 3.1, or another signature
algorithm.
- If client authentication using ECDH is performed, the client provides Note that there is no structural difference between ECDH and ECDSA
a static ECDH public key in the client certificate message using the keys. A certificate issuer may use X509.v3 keyUsage and
format described in Section 4.4. In this case an empty client key extendedKeyUsage extensions to restrict the use of an ECC public key
exchange message is sent using the format described in Section 4.5, and to certain computations. This document refers to an ECC key as ECDH-
the certificate verify message is not sent. capable if its use in ECDH is permitted. ECDSA-capable is defined
similarly.
- The client and server compute the master secret using their ECDH key Client Server
pairs as specified in Section 4.7. ------ ------
ECDH computations for this key exchange algorithm are performed ClientHello -------->
according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the ServerHello
ECSVDP-DH secret value derivation primitive, and the KDF1 key Certificate*
derivation primitive using SHA-1 [FIPS180-1]. ECDSA computations are ServerKeyExchange*
performed according to ANSI X9.62 [ANSIX962] using the hash function CertificateRequest*+
SHA-1 [FIPS180-1]. <-------- ServerHelloDone
Certificate*+
ClientKeyExchange
CertificateVerify*+
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
2.2. ECDH_ECDSA_EXPORT Application Data <-------> Application Data
Export-strength ECDH is used to compute the master secret. The server Figure 1: Message flow in a full TLS handshake
is authenticated via a certificate containing an ECDH public key signed * message is not sent under some conditions
with ECDSA. + message is not sent unless the client is
authenticated
This key exchange algorithm MUST proceed in the same way as ECDH_ECDSA, Figure 1 shows all messages involved in the TLS key establishment
except that the key size for ECDH public keys is constrained to 163 protocol (aka full handshake). The addition of ECC has direct impact
bits or less. Here the key size of an elliptic curve public key refers only on the the server's Certificate message, the ServerKeyExchange,
to the size of the underlying finite field over which the elliptic the ClientKeyExchange, the CertificateRequest, the client's
curve is defined. Certificate message, and the CertificateVerify. Next, we describe
each ECC key exchange algorithm in greater detail in terms of the
content and processing of these messages. For ease of exposition, we
defer discussion of client authentication and associated messages
(identified with a + in Figure 1) until Section 3.
2.3. ECDH_RSA 2.1 ECDH_ECDSA
ECDH is used to compute the master secret. The server is authenticated In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
via a certificate containing an ECDH public key signed with RSA. public key and be signed with ECDSA.
This key exchange MUST proceed in the same way as ECDH_ECDSA, except A ServerKeyExchange MUST NOT be sent (the server's certificate
that the server's certificate is signed with RSA. contains all the necessary keying information required by the client
to arrive at the premaster secret).
2.4. ECDH_RSA_EXPORT The client MUST generate an ECDH key pair on the same curve as the
server's long-term public key and send its public key in the
ClientKeyExchange message (except when using client authentication
algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
modifications from section Section 3.2 or Section 3.3 apply).
Export-strength ECDH is used to compute the master secret. The server Both client and server MUST perform an ECDH operation and use the
is authenticated via a certificate containing an ECDH public key signed resultant shared secret as the premaster secret. All ECDH
with RSA. calculations are performed as specified in Section 4.8
This key exchange algorithm MUST proceed in the same way as ECDH_RSA, 2.2 ECDHE_ECDSA
except that the key size for ECDH public keys is constrained to be 163
bits or less.
2.5. ECDH_anon In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
capable public key and be signed with ECDSA.
Anonymous ECDH is used to compute the master secret. The server MUST send its ephemeral ECDH public key and a
specification of the corresponding curve in the ServerKeyExchange
message. These parameters MUST be signed with ECDSA using the
private key corresponding to the public key in the server's
Certificate.
Specifically this key exchange algorithm MUST proceed as follows: The client MUST generate an ECDH key pair on the same curve as the
server's ephemeral ECDH key and send its public key in the
ClientKeyExchange message.
- The server certificate message is not sent. Both client and server MUST perform an ECDH operation (Section 4.8)
and use the resultant shared secret as the premaster secret.
- The server provides an ephemeral ECDH public key in the server key 2.3 ECDH_RSA
exchange message using the format described in Section 4.2.
- The client certificate message is not sent. This key exchange algorithm is the same as ECDH_ECDSA except the
server's certificate MUST be signed with RSA rather than ECDSA.
- The client provides an ephemeral ECDH public key in the client key 2.4 ECDHE_RSA
exchange message using the format described in Section 4.5.
- The client and server compute the master secret using their ECDH This key exchange algorithm is the same as ECDHE_ECDSA except the
key pairs as specified in Section 4.7. server's certificate MUST contain an RSA public key authorized for
signing and the signature in the ServerKeyExchange message MUST be
computed with the corresponding RSA private key. The server
certificate MUST be signed with RSA.
ECDH computations for this key exchange algorithm are performed 2.5 ECDH_anon
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 In ECDH_anon, the server's Certificate, the CertificateRequest, the
client's Certificate, and the CertificateVerify messages MUST NOT be
sent.
Export-strength, anonymous ECDH is used to compute the master secret. The server MUST send an ephemeral ECDH public key and a specification
This key exchange algorithm MUST proceed in the same way as ECDH_anon, of the corresponding curve in the ServerKeyExchange message. These
except that the key size for ECDH public keys is constrained to 163 parameters MUST NOT be signed.
bits or less.
3. ECC Client Authentication The client MUST generate an ECDH key pair on the same curve as the
server's ephemeral ECDH key and send its public key in the
ClientKeyExchange message.
This document defines three new ECC-based client authentication methods Both client and server MUST perform an ECDH operation and use the
- ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH. resultant shared secret as the premaster secret. All ECDH
calculations are performed as specified in Section 4.8
To encourage interoperability, implementations SHOULD support 3. Client Authentication
ECDSA_fixed_ECDH. Implementations MAY support any of the other client
authentication methods.
The remainder of this section specifies these ECC-based client This document defines three new client authentication mechanisms
authentication methods. The following information is provided for each named after the type of client certificate involved: ECDSA_sign,
method: which key exchange algorithms the method may be used with, what ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is
constraints apply to the method, and the formats of the certificate usable with any of the non-anonymous ECC key exchange algorithms
request, client certificate, client key exchange, and certificate described in Section 2 as well as other non-anonymous (non-ECC) key
verify messages. exchange algorithms defined in TLS [3]. The ECDSA_fixed_ECDH and
RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
use of a long-term ECDH client key would jeopardize the forward
secrecy property of these algorithms.
3.1. ECDSA_sign The server can request ECC-based client authentication by including
one or more of these certificate types in its CertificateRequest
message. The server MUST NOT include any certificate types that are
prohibited for the negotiated key exchange algorithm. The client
must check if it possesses a certificate appropriate for any of the
methods suggested by the server and is willing to use it for
authentication.
The client supplies a certificate containing an ECDSA public key, and If these conditions are not met, the client should send a client
authenticates itself by signing the certificate verify message with its Certificate message containing no certificates. In this case, the
ECDSA key pair. ClientKeyExchange should be sent as described in Section 2 and the
CertificateVerify should not be sent. If the server requires client
authentication, it may respond with a fatal handshake failure alert.
This client authentication method MUST proceed as follows. If the client has an appropriate certificate and is willing to use it
for authentication, it MUST send that certificate in the client's
Certificate message (as per Section 4.4) and prove possession of the
private key corresponding to the certified key. The process of
determining an appropriate certificate and proving possession is
different for each authentication mechanism and described below.
Applicable key exchange algorithms: NOTE: It is permissible for a server to request (and the client to
send) a client certificate of a different type than the server
certificate.
- This client authentication method is eligible for use with all the 3.1 ECDSA_sign
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: To use this authentication mechanism, the client MUST possess a
certificate containing an ECDSA-capable public key and signed with
ECDSA.
- In order to perform this method, the client must possess a certified The client MUST prove possession of the private key corresponding to
ECDSA public key. the certified key by including a signature in the CertificateVerify
message as described in Section 4.6.
Message exchange: 3.2 ECDSA_fixed_ECDH
- The server requests use of the ECDSA_sign method by sending a To use this authentication mechanism, the client MUST possess a
certificate request message containing the value "ecdsa_sign" using certificate containing an ECDH-capable public key and that
the format described in Section 4.3. When the client receives this certificate MUST be signed with ECDSA. Furthermore, the client's
request, it checks that it possesses an appropriate certificate and ECDH key MUST be on the same elliptic curve as the server's long-term
that it is willing to proceed. (certified) ECDH key.
- If the client proceeds, it sends its certificate containing its ECDSA When using this authentication mechanism, the client MUST send an
public key in the client certificate message using the format empty ClientKeyExchange as described in Section 4.5 and MUST NOT send
described in Section 4.4. It signs the handshake messages exchanged the CertificateVerify message. The ClientKeyExchange is empty since
so far with its ECDSA key pair and conveys the resulting signature to the client's ECDH public key required by the server to compute the
the server in the certificate verify message using the format premaster secret is available inside the client's certificate. The
specified in Section 4.6. client's ability to arrive at the same premaster secret as the server
(demonstrated by a successful exchange of Finished messages) proves
possession of the private key corresponding to the certified public
key and the CertificateVerify message is unnecessary.
- (If the client does not proceed, it may perform client authentication 3.3 RSA_fixed_ECDH
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 This authentication mechanism is identical to ECDSA_fixed_ECDH except
according to ANSI X9.62 [ANSIX962] using the hash function SHA-1 the client's certificate MUST be signed with RSA.
[FIPS180-1].
3.2. ECDSA_fixed_ECDH 4. Data Structures and Computations
The client supplies an ECDSA-signed certificate containing an ECDH This section specifies the data structures and computations used by
public key using the same elliptic curve domain parameters as the ECC-based key mechanisms specified in Section 2 and Section 3. The
server's ECDH public key. The client authenticates itself by computing presentation language used here is the same as that used in TLS [3].
the master secret and the finished message. (This achieves Since this specification extends TLS, these descriptions should be
authentication because these computations can only be performed by a merged with those in the TLS specification and any others that extend
party possessing the private key corresponding to one of the ECDH TLS. This means that enum types may not specify all possible values
public keys exchanged.) and structures with multiple formats chosen with a select() clause
may not indicate all possible cases.
This client authentication method MUST proceed as follows. 4.1 Server Certificate
Applicable key exchange algorithms: When this message is sent:
- This method is eligible for use with all the non-anonymous ECC-based This message is sent in all non-anonymous ECC-based key exchange
key exchange algorithms specified in Section 2. algorithms.
Restrictions: Meaning of this message:
- In order to perform this client authentication method, the client This message is used to authentically convey the server's static
must possess an ECDSA-signed certificate containing an ECDH public public key to the client. The following table shows the server
key using the same elliptic curve domain parameters as the ECDH certificate type appropriate for each key exchange algorithm. ECC
public key supplied by the server in the server certificate message. public keys must be encoded in certificates as described in Section
4.7.
Message exchange: NOTE: The server's Certificate message is capable of carrying a chain
of certificates. The restrictions mentioned in Table 3 apply only to
the server's certificate (first in the chain).
- The server requests use of the ECDSA_fixed_ECDH method by sending a Key Exchange Algorithm Server Certificate Type
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 ECDH_ECDSA Certificate must contain an
public key in the client certificate message using the format ECDH-capable public key. It
described in Section 4.4. It sends an empty client key exchange must be signed with ECDSA.
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.
- (If the client does not proceed, it may perform client authentication ECDHE_ECDSA Certificate must contain an
using another method suggested by the server in the certificate ECDSA-capable public key. It
request message, or it may proceed with the key exchange without must be signed with ECDSA.
client authentication - in which case the client certificate and
certificate verify messages are not sent.)
ECDH computations for this key exchange algorithm are performed ECDH_RSA Certificate must contain an
according to IEEE 1363 [IEEE1363] - using the ECKAS-DH1 scheme with the ECDH-capable public key. It
ECSVDP-DH secret value derivation primitive, and the KDF1 key must be signed with RSA.
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 ECDHE_RSA Certificate must contain an
RSA public key authorized for
use in digital signatures. It
must be signed with RSA.
The client supplies an RSA-signed certificate containing an ECDH Table 3: Server certificate types
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 Structure of this message:
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 Identical to the TLS Certificate format.
This section specifies the data structures and computations used by the Actions of the sender:
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 The server constructs an appropriate certificate chain and conveys it
to the client in the Certificate message.
This message is sent in the following key exchange algorithms: Actions of the receiver:
All the non-anonymous ECC-based key exchange algorithms specified in The client validates the certificate chain, extracts the server's
Section 2. public key, and checks that the key type is appropriate for the
negotiated key exchange algorithm.
Meaning of this message: 4.2 Server Key Exchange
This message is used to authentically convey the server's static public When this message is sent:
key to the client. The appropriate certificate types are given in the
following table.
Key Exchange Algorithm Certificate Type This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and
ECDH_anon key exchange algorithms.
ECDH_ECDSA ECC public key; the certificate must Meaning of this message:
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 This message is used to convey the server's ephemeral ECDH public key
agreement; key size must be 163 bits or (and the corresponding elliptic curve domain parameters) to the
less. Certificate must be signed with client.
ECDSA.
ECDH_RSA ECC public key which can be used for key Structure of this message:
agreement. Certificate must be signed
with RSA.
ECDH_RSA_EXPORT ECC public key which can be used for key enum { explicit_prime (1), explicit_char2 (2),
agreement; key size must be 163 bits or named_curve (3), (255) } ECCurveType;
less. Certificate must be signed with
RSA.
Table 3: Server certificate types explicit_prime: Indicates the elliptic curve domain parameters are
conveyed verbosely, and the underlying finite field is a prime
field.
[PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in explicit_char2: Indicates the elliptic curve domain parameters are
X.509 certificates. Servers SHOULD use the elliptic curve domain conveyed verbosely, and the underlying finite field is a
parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2 characteristic 2 field.
[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: named_curve: Indicates that a named curve is used. This option
SHOULD be used when applicable.
Identical to the TLS Certificate format. struct {
opaque a <1..2^8-1>;
opaque b <1..2^8-1>;
opaque seed <0..2^8-1>;
} ECCurve;
Actions of the sender: 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 Section 4.3.3 of
ANSI X9.62 [7].
The server constructs an appropriate certificate chain and conveys it seed: This is an optional parameter used to derive the coefficients
to the client in the Certificate message. of a randomly generated elliptic curve.
Actions of the receiver: struct {
opaque point <1..2^8-1>;
} ECPoint;
The client validates the certificate chain, extracts the server's point: This is the byte string representation of an elliptic curve
public key, and checks that the key is of the correct type for the key point following the conversion routine in Section 4.3.6 of ANSI
exchange algorithm. X9.62 [7]. Note that this byte string may represent an elliptic
curve point in compressed or uncompressed form. Implementations
of this specification MUST support the uncompressed form and MAY
support the compressed form.
4.2. Server Key Exchange enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
This message is sent in the following key exchange algorithms: ec_basis_trinomial: Indicates representation of a characteristic two
field using a trinomial basis.
Both the anonymous ECC-based key exchange algorithms specified in ec_basis_pentanomial: Indicates representation of a characteristic
Section 2. two field using a pentanomial basis.
Meaning of this message: 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), reserved (240..247), (255)
} NamedCurve;
This message is used to convey the server's ephemeral ECDH public key sect163k1, etc: Indicates use of the corresponding named curve
(and the corresponding elliptic curve domain parameters) to the client. specified in SEC 2 [12]. Note that many of these curves are also
recommended in ANSI X9.62 [7], and FIPS 186-2 [9]. Values 240
through 247 are reserved for private use.
Structure of this message: 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;
The TLS ServerKeyExchange message is extended as follows. curve_type: This identifies the type of the elliptic curve domain
parameters.
enum { ec_diffie_hellman } KeyExchangeAlgorithm; prime_p: This is the odd prime defining the field Fp.
ec_diffie_hellman curve: Specifies the coefficients a and b (and optional seed) of the
Indicates the ServerKeyExchange message is to contain an ECDH public elliptic curve E.
key.
enum { explicit_prime (1), explicit_char2 (2), base: Specifies the base point G on the elliptic curve.
named_curve (3), (255) } ECCurveType;
explicit_prime order: Specifies the order n of the base point.
Indicates the elliptic curve domain parameters will be conveyed
verbosely, and that the underlying finite field is a prime field.
explicit_char2 cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
Indicates the elliptic curve domain parameters will be conveyed represents the number of points on the elliptic curve E defined
verbosely, and that the underlying finite field is a characteristic 2 over the field Fq.
field.
named_curve m: This is the degree of the characteristic-two field F2^m.
Indicates that a named curve will be used. The use of this option is
strongly recommended.
struct { k: The exponent k for the trinomial basis representation x^m + x^k
opaque a <1..2^8-1>; +1.
opaque b <1..2^8-1>;
opaque seed <0..2^8-1>;
} ECCurve;
a, b k1, k2, k3: The exponents for the pentanomial representation x^m +
These parameters specify the coefficients of the elliptic curve. Each x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
value contains the byte string representation of a field element
following the conversion routine in [X9.62], section 4.3.3.
seed namedcurve: Specifies a recommended set of elliptic curve domain
This is an optional parameter used to derive the coefficients of a parameters.
randomly generated elliptic curve.
struct { struct {
opaque point <1..2^8-1>; ECParameters curve_params;
} ECPoint; ECPoint public;
} ServerECDHParams;
point curve_params: Specifies the elliptic curve domain parameters
This is the byte string representation of an elliptic curve point associated with the ECDH public key.
following the conversion routine in [X9.62], section 4.3.6.
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; public: The ephemeral ECDH public key.
ec_basis_trinomial The ServerKeyExchange message is extended as follows.
Indicates representation of a characteristic two field using a
trinomial basis.
ec_basis_pentanomial enum { ec_diffie_hellman } KeyExchangeAlgorithm;
Indicates representation of a characteristic two field using a
pentanomial basis.
enum { ec_diffie_hellman: Indicates the ServerKeyExchange message contains
sect163k1 (1), sect163r1 (2), sect163r2 (3), an ECDH public key.
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 select (KeyExchangeAlgorithm) {
Indicates use of the corresponding recommended curve specified in SEC 2 case ec_diffie_hellman:
[SEC2]. Note that many of these curves are also recommended in ANSI ServerECDHParams params;
X9.62 [ANSIX962], and FIPS 186-2 [FIPS186-2]. Signature signed_params;
} ServerKeyExchange;
struct { params: Specifies the ECDH public key and associated domain
ECCurveType curve_type; parameters.
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 signed_params: A hash of the params, with the signature appropriate
This identifies the type of the elliptic curve domain parameters. to that hash applied. The private key corresponding to the
certified public key in the server's Certificate message is used
for signing.
prime_p enum { ecdsa } SignatureAlgorithm;
This is the odd prime defining the field Fp. select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[20];
};
} Signature;
curve NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange
Specifies the coefficients a and b of the elliptic curve E. algorithm and 'anonymous' for ECDH_anon. These cases are defined in
TLS [3]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA
signatures are generated and verified as described in Section 4.8.
base Actions of the sender:
Specifies the base point G on the elliptic curve.
order The server selects elliptic curve domain parameters and an ephemeral
Specifies the order n of the base point. ECDH public key corresponding to these parameters according to the
ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to
the client in the ServerKeyExchange message using the format defined
above.
cofactor Actions of the recipient:
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 The client verifies the signature (when present) and retrieves the
This is the degree of the characteristic-two field F2^m. server's elliptic curve domain parameters and ephemeral ECDH public
key from the ServerKeyExchange message.
k 4.3 Certificate Request
The exponent k for the trinomial basis representation x^m+x^k+1.
k1, k2, k3 When this message is sent:
The exponents for the pentanomial representation x^m+x^k3+x^k2+x^k1+1.
namedcurve This message is sent when requesting client authentication.
Specifies a recommended set of elliptic curve domain parameters.
struct { Meaning of this message:
ECParameters curve_params;
ECPoint public;
} ServerECDHParams;
curve_params The server uses this message to suggest acceptable client
Specifies the elliptic curve domain parameters associated with the authentication methods.
ECDH public key.
public Structure of this message:
The ephemeral ECDH public key.
select (KeyExchangeAlgorithm) { The TLS CertificateRequest message is extended as follows.
case ec_diffie_hellman:
ServerECDHParams params;
Signature signed_params;
} ServerKeyExchange;
params enum {
Specifies the ECDH public key and associated domain parameters. ecdsa_sign(5), rsa_fixed_ecdh(6),
ecdsa_fixed_ecdh(7), (255)
} ClientCertificateType;
signed_params ecdsa_sign, etc Indicates that the server would like to use the
This element is empty for all the key exchange algorithms specified in corresponding client authentication method specified in Section 3.
this document.
Actions of the sender: NOTE: SSL 3.0 [4] assigns values 5 and 6 differently
(rsa_ephemeral_dh and dss_ephemeral_dh); these
ClientCertificateType values are not used by TLS.
The server selects elliptic curve domain parameters and an ephemeral Actions of the sender:
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 server decides which client authentication methods it would like
to use, and conveys this information to the client using the format
defined above.
The client retrieves the server's elliptic curve domain parameters and Actions of the receiver:
ephemeral ECDH public key from the ServerKeyExchange message.
4.3. Certificate Request 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.
This message is sent when requesting the following client 4.4 Client Certificate
authentication methods:
Any of the ECC-based client authentication methods specified in When this message is sent:
Section 3.
Meaning of this message: This message is sent in response to a CertificateRequest when a
client has a suitable certificate.
The server uses this message to indicate which client authentication Meaning of this message:
methods the server would like to use.
Structure of this message: This message is used to authentically convey the client's static
public key to the server. The following table summarizes what client
certificate types are appropriate for the ECC-based client
authentication mechanisms described in Section 3. ECC public keys
must be encoded in certificates as described in Section 4.7.
The TLS CertificateRequest message is extended as follows. NOTE: The client's Certificate message is capable of carrying a chain
of certificates. The restrictions mentioned in Table 4 apply only to
the client's certificate (first in the chain).
enum { Client
ecdsa_sign (5), rsa_fixed_ecdh (6), Authentication Method Client Certificate Type
ecdsa_fixed_ecdh(7), (255) --------------------- -----------------------
} ClientCertificateType;
ecdsa_sign, etc ECDSA_sign Certificate must contain an
Indicates that the server would like to use the corresponding client ECDSA-capable public key and
authentication method specified in Section 3. be signed with ECDSA.
Actions of the sender: ECDSA_fixed_ECDH Certificate must contain an
ECDH-capable public key on the
same elliptic curve as the server's
long-term ECDH key. This certificate
must be signed with ECDSA.
The server decides which client authentication methods it would like to RSA_fixed_ECDH Certificate must contain an
use, and conveys this information to the client using the format ECDH-capable public key on the
defined above. same elliptic curve as the server's
long-term ECDH key. This certificate
must be signed with RSA.
Actions of the receiver: Table 4: Client certificate types
The client determines whether it has an appropriate certificate for use Structure of this message:
with any of the requested methods, and decides whether or not to
proceed with client authentication.
4.4. Client Certificate Identical to the TLS client Certificate format.
This message is sent in the following client authentication methods: Actions of the sender:
All the ECC-based client authentication methods specified in Section 3. The client constructs an appropriate certificate chain, and conveys
it to the server in the Certificate message.
Meaning of this message: Actions of the receiver:
This message is used to authentically convey the client's static public The TLS server validates the certificate chain, extracts the client's
key to the server. The appropriate certificate types are given in the public key, and checks that the key type is appropriate for the
following table. client authentication method.
Client Authentication Certificate Type 4.5 Client Key Exchange
Method
ECDSA_sign ECC public key which can be used for When this message is sent:
signing.
ECDSA_fixed_ECDH ECC public key which can be used for key This message is sent in all key exchange algorithms. If client
agreement. Certificate must be signed authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this
with ECDSA. message is empty. Otherwise, it contains the client's ephemeral ECDH
public key.
RSA_fixed_ECDH ECC public key which can be used for key Meaning of the message:
agreement. Certificate must be signed
with RSA.
Table 4: Client certificate types This message is used to convey ephemeral data relating to the key
exchange belonging to the client (such as its ephemeral ECDH public
key).
[PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in Structure of this message:
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: The TLS ClientKeyExchange message is extended as follows.
Identical to the TLS Certificate format. enum { yes, no } EphemeralPublicKey;
Actions of the sender: yes, no: Indicates whether or not the client is providing an
ephemeral ECDH public key. (In ECC ciphersuites, this is "yes"
except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH
client authentication mechanism.)
The client constructs an appropriate certificate chain, and conveys it struct {
to the server in the Certificate message. select (EphemeralPublicKey) {
case yes: ECPoint ecdh_Yc;
case no: struct { };
} ecdh_public;
} ClientECDiffieHellmanPublic;
Actions of the receiver: ecdh_Yc: Contains the client's ephemeral ECDH public key.
The TLS server validates the certificate chain, extracts the client's struct {
public key, and checks that the key is of the correct type for the select (KeyExchangeAlgorithm) {
client authentication method. case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
4.5. Client Key Exchange Actions of the sender:
This message is sent in the following key exchange algorithms: 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 [6]. It conveys this information to the client
in the ClientKeyExchange message using the format defined above.
All the ECC-based key exchange algorithms specified in Section 2. If Actions of the recipient:
client authentication with fixed ECDH is not being used, the message
contains the client's ephemeral ECDH public key, otherwise the message
is empty.
Meaning of the message: The server retrieves the client's ephemeral ECDH public key from the
ClientKeyExchange message and checks that it is on the same elliptic
curve as the server's ECDH key.
This message is used to convey ephemeral data relating to the key 4.6 Certificate Verify
exchange belonging to the client (such as its ephemeral ECDH public
key).
Structure of this message: When this message is sent:
The TLS ClientKeyExchange message is extended as follows. This message is sent when the client sends a client certificate
containing a public key usable for digital signatures, e.g. when the
client is authenticated using the ECDSA_sign mechanism.
enum { yes, no } EphemeralPublicKey; Meaning of the message:
yes, no This message contains a signature that proves possession of the
Indicates whether or not the client is providing an ephemeral ECDH private key corresponding to the public key in the client's
public key. Certificate message.
struct { Structure of this message:
select (EphemeralPublicKey) {
case yes: ECPoint ecdh_Yc;
case no: struct { };
} ecdh_public;
} ClientECDiffieHellmanPublic;
ecdh_Yc The TLS CertificateVerify message is extended as follows.
Contains the client's ephemeral ECDH public key.
struct { enum { ecdsa } SignatureAlgorithm;
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
Actions of the sender: select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[20];
};
} Signature;
The client selects an ephemeral ECDH public key corresponding to the For the ecdsa case, the signature field in the CertificateVerify
parameters it received from the server according to the ECKAS-DH1 message contains an ECDSA signature computed over handshake messages
scheme from IEEE 1363 [IEEE1363]. It conveys this information to the exchanged so far. ECDSA signatures are computed as described in
client in the ClientKeyExchange message using the format defined Section 4.8. As per ANSI X9.62, an ECDSA signature consists of a
above. 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 [7]. The two byte
strings are concatenated, and the result is placed in the signature
field.
Actions of the recipient: Actions of the sender:
The server retrieves the client's ephemeral ECDH public key from the The client computes its signature over all handshake messages sent or
ServerKeyExchange message and checks that the public key represents a received starting at client hello up to but not including this
point of the elliptic curve. message. It uses the private key corresponding to its certified
public key to compute the signature which is conveyed in the format
defined above.
4.6. Certificate Verify Actions of the receiver:
This message is sent in the following client authentication methods: The server extracts the client's signature from the CertificateVerify
message, and verifies the signature using the public key it received
in the client's Certificate message.
ECDSA_sign 4.7 Elliptic Curve Certificates
Meaning of the message: X509 certificates containing ECC public keys or signed using ECDSA
MUST comply with [14]. Clients SHOULD use the elliptic curve domain
parameters recommended in ANSI X9.62 [7], FIPS 186-2 [9], and SEC 2
[12].
This message contains an ECDSA signature on the handshake messages in 4.8 ECDH, ECDSA and RSA Computations
order to authenticate the client to the server.
Structure of this message: All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) MUST be performed according to [6]
using the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation
primitive, and the KDF1 key derivation function using SHA-1 [9]. The
output of this scheme, i.e. the 20-byte SHA-1 output from the KDF,
is the premaster secret.
The TLS CertificateVerify message is extended as follows. DISCUSSION POINT:
enum { ec_dsa } SignatureAlgorithm; Using KDF1 with SHA-1 limits the security to at most 160 bits,
independently of the elliptic curve used for ECDH. An alternative
way to define the protocol would be to employ the identity map as key
derivation function (in other words, omit the SHA-1 step and directly
use the octet string representation of the x coordinate of the
elliptic curve point resulting from the ECDH computation as premaster
secret). This is similar to conventional DH in TLS [3], and it is
appropriate for TLS given that TLS already defines a PRF for
determining the actual symmetric keys.
select (SignatureAlgorithm) { The TLS PRF (which is used to derive the master secret from the
case ec_dsa: premaster secret and the symmetric keys from the master secret) has
digitally-signed struct { an internal security limit of at most 288 bits (128 + 160 for MD5 and
opaque sha_hash[20]; SHA-1), so the use of KDF1 with SHA-1 can be seen to actually weaken
}; the theoretical security of the protocol.
} Signature;
In the CertificateVerify message, the signature field contains the Options to solve this problem include the following:
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: o Omit the SHA-1 step as describe above. (BM)
The client computes its signature over the handshake messages exchanged o Continue to use KDF1 with SHA-1 for curves up to, say, 288 bits
so far using its ECDSA key pair with ECDSA computations performed as (more precisely: for curves where FE2OSP returns an octet string
specified in [ANSIX962] with the hash function SHA-1 [FIPS186-2]. The up to 36 octets) and omit the SHA-1 step only for larger curves.
client conveys its signature to the server in the CertificateVerify (SBW/BM)
message using the format defined above.
Actions of the receiver: o Continue to use KDF1 with SHA-1 for curves up to, say, 288 bits
and use KDF1 with SHA-256 or SHA-384 or SHA-512 for larger curves.
(SBW)
The server extracts the client's signature from the CertificateVerify The first solution will break compatibility with existing
message, and verifies the signature using the client's ECDSA public key implementations based on draft-ietf-tls-ecc-01.txt. The second and
that it received in the ClientCertificate message. third solutions are somewhat of a kludge, but maintain compatibility
(in a large range).
4.7. Computing the Master Secret OPEN QUESTION: We invite comments on which of these solutions would
be preferred.
In all the ECC-based key exchange algorithms specified in Section 2, END OF DISCUSSION POINT.
the client and server compute the master key as follows:
- They both compute a single shared secret K of length 20 bytes using All ECDSA computations MUST be performed according to ANSI X9.62 [7]
their ECDH key pairs with ECDH computations performed as specified by using the SHA-1 [9] hash function. The 20 bytes of the SHA-1 are run
the ECKAS-DH1 scheme in [IEEE1363] with the ECSVDP-DH secret value directly through the ECDSA algorithm with no additional hashing.
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 All RSA signatures must be generated and verified according to PKCS#1
master_secret from the pre_master_secret as specified in [TLS]. [10].
5. Cipher Suites 5. Cipher Suites
The table below defines the cipher suites specified in this document The table below defines new ECC cipher suites that use the key
for use with the key exchange algorithms specified in Section 2. exchange algorithms specified in Section 2.
CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 } CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 }
CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 } 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_DES_CBC_SHA = { 0x00, 0x49 }
CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A } 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_128_CBC_SHA = { 0x00, 0x4B }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C } 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 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
The key exchange method, cipher, and hash algorithm for each of these CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? }
cipher suites are easily determined by examining the name. Ciphers CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
other than AES ciphers, and hash algorithms are defined in [TLS]. AES CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
ciphers are defined in [TLS-AES]. CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
The cipher suites which use the "NULL" cipher or one of the "EXPORT" CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? }
key exchange algorithms are considered to be "exportable" cipher suites CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
for the purposes of the TLS protocol. CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
Use of the following cipher suites is recommended in general - server CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? }
implementations SHOULD support all of these cipher suites, and client CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? }
implementations SHOULD support at least one of them: CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
TLS_ECDH_ECDSA_WITH_RC4_128_SHA Table 5: TLS ECC cipher suites
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. 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 [3]. AES
ciphers are defined in [11].
6. Security Considerations Server implementations SHOULD support all of the following cipher
suites, and client implementations SHOULD support at least one of
them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
This document is entirely concerned with security mechanisms. 6. Security Considerations
This document is based on [TLS], [ANSIX9.62], and [IEEE1363] and the This document is entirely concerned with security mechanisms.
appropriate security considerations of those documents apply.
In addition implementers should take care to ensure that code which This document is based on [3], [6], [7] and [11]. The appropriate
controls security mechanisms is free of errors which might be exploited security considerations of those documents apply.
by attackers.
7. Intellectual Property Rights 7. Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to the specification contained in this document. For more regard to the specification contained in this document. For more
information, consult the online list of claimed rights information, consult the online list of claimed rights (http://
(http://www.ietf.org/ipr.html). www.ietf.org/ipr.html).
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to
to the implementation or use of the technology described in this pertain to the implementation or use of the technology described in
document or the extent to which any license under such rights might or this document or the extent to which any license under such rights
might not be available; neither does it represent that it has made any might or might not be available; neither does it represent that it
effort to identify any such rights. Information on the IETF's has made any effort to identify any such rights. Information on the
procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in [13]. Copies of
claims of rights made available for publication and any assurances 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 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 obtain a general license or permission for the use of such
rights by implementers or users of this specification can be obtained proprietary rights by implementers or users of this specification can
from the IETF Secretariat. be obtained from the IETF Secretariat.
8. Acknowledgments 8. Acknowledgments
The authors wish to thank Bill Anderson, Paul Fahn, Gilles Garon, John The authors wish to thank Bill Anderson and Tim Dierks.
Kennedy, and Brian Minard for their help preparing this document.
9. References References
[ANSIX9.62] ANSI X9.62-1999, "Public Key Cryptography For The Financial [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Services Industry: The Elliptic Curve Digital Signature Levels", RFC 2119, March 1997.
Algorithm (ECDSA)", American National Standards Institute,
1998.
[FIPS180] FIPS 180-1, "Secure Hash Standard", National Institute of [2] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Standards and Technology, 1995. Sizes", Journal of Cryptology 14 (2001) 255-293, <http://
www.cryptosavvy.com/>.
[FIPS186-2] FIPS 186-2, "Digital Signature Standard", National Institute [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
of Standards and Technology, 2000. 2246, January 1999.
[IEEE1363] IEEE 1363, "Standard Specifications for Public Key [4] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol
Cryptography", Institute of Electrical and Electronics Version 3.0", November 1996, <http://wp.netscape.com/eng/ssl3/
Engineers, 2000. draft302.txt>.
[MUST] S. Bradner, "Key Words for Use in RFCs to Indicate [5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http://
Requirement Levels", RFC 2119, March 1997. www.secg.org/>.
[PKIX-ALG] L. Bassham, R. Housley and W. Polk, "Algorithms and [6] IEEE, "Standard Specifications for Public Key Cryptography",
Identifiers for the Internet X.509 Public Key IEEE 1363, 2000.
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 [7] ANSI, "Public Key Cryptography For The Financial Services
Public Key Infrastructure Certificate and CRL Profile", PKIX Industry: The Elliptic Curve Digital Signature Algorithm
Working Group Internet-Draft, (ECDSA)", ANSI X9.62, 1998.
draft-ietf-pkix-new-part1-05.txt, March 2001.
[SEC1] SEC 1, "Elliptic Curve Cryptography", Standards for Efficient [8] NIST, "Digital Signature Standard", FIPS 180-1, 2000.
Cryptography Group, 2000.
[SEC2] SEC 2, "Recommended Elliptic Curve Domain Parameters", [9] NIST, "Secure Hash Standard", FIPS 186-2, 1995.
Standards for Efficient Cryptography Group, 2000.
[TLS] T. Dierks and C. Allen, "The TLS Protocol - Version 1.0," [10] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
IETF RFC 2246, January 1999. 1.5", PKCS 1, November 1993.
[TLS-AES] P. Chown, "AES Ciphersuites for TLS", TLS Working Group [11] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Internet-Draft, draft-ietf-tls-ciphersuite-03.txt, Transport Layer Security (TLS)", RFC 3268, June 2002.
January 2001.
[TLS-EXT] S. Blake-Wilson and M. Nystrom, "Wireless Extensions to TLS", [12] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
TLS Working Group Internet-Draft, 2000, <http://www.secg.org/>.
draft-ietf-tls-wireless-00.txt, November 2000.
10. Authors' Addresses [13] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", RFC 2028, BCP 11, October 1996.
Authors: [14] Polk, T., Housley, R. and L. Bassham, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC
3279, April 2002.
Simon Blake-Wilson Authors' Addresses
Certicom Corp.
sblake-wilson@certicom.com
Tim Dierks Vipul Gupta
Certicom Corp. Sun Microsystems Laboratories
timd@consensus.com 2600 Casey Avenue
MS UMTV29-235
Mountain View, CA 94303
USA
Chris Hawk Phone: +1 650 336 1681
Certicom Corp. EMail: vipul.gupta@sun.com
chawk@certicom.com
Simon Blake-Wilson
Basic Commerce & Industries, Inc.
96 Spandia Ave
Unit 606
Toronto, ON M6G 2T6
Canada
Phone: +1 416 214 5961
EMail: sblakewilson@bcisse.com
Bodo Moeller
Technische Universitaet Darmstadt
Alexanderstr. 10
64283 Darmstadt
Germany
Phone: +49 6151 16 6628
EMail: moeller@cdc.informatik.tu-darmstadt.de
Chris Hawk
Independent Consultant
EMail: chris@socialeng.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 254 change blocks. 
757 lines changed or deleted 756 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/