TLS Working Group                                     Simon Blake-Wilson
INTERNET-DRAFT                                                Tim Dierks                                               V. Gupta
Internet-Draft                                                  Sun Labs
Expires: September 14, 2001                                   Chris February 27, 2003                               S. Blake-Wilson
                                                                     BCI
                                                              B. Moeller
                                       Technische Universitaet Darmstadt
                                                                 C. Hawk
                                                          Certicom Corp.
                                                           15 March 2001
                                                  Independent Consultant
                                                         August 29, 2002

                       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.

   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 can be found accessed at
 http://www.ietf.org/ietf/1id-abstracts.txt http://
   www.ietf.org/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on February 27, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes additions to TLS to support new key exchange algorithms based on Elliptic
   Curve Cryptography (ECC). (ECC) for the TLS (Transport Layer Security)
   protocol.  In particular particular, it defines new key exchange
 algorithms which 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) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme
 (ECDH), and it defines how to perform client as a new
   authentication with ECDSA
 and ECDH. mechanism.

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

   Please send comments on this document to the TLS mailing list.

Table of Contents

   1.  Introduction ................................................. 2 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   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 ..............................................
   2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  2.5.
   2.2 ECDHE_ECDSA  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   2.4 ECDHE_RSA  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   2.5 ECDH_anon .................................................... 6
  2.6.  ECDH_anon_EXPORT ............................................. 6  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.    ECC  Client Authentication .................................... 7
  3.1.  . . . . . . . . . . . . . . . . . . . .  9
   3.1 ECDSA_sign ................................................... 7
  3.2. . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.2 ECDSA_fixed_ECDH ............................................. 8
  3.3. . . . . . . . . . . . . . . . . . . . . . . . 10
   3.3 RSA_fixed_ECDH ............................................... 9 . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.  Data Structures and Computations ............................. 9
  4.1. . . . . . . . . . . . . . . . 11
   4.1 Server Certificate .......................................... 10
  4.2. . . . . . . . . . . . . . . . . . . . . . . 11
   4.2 Server Key Exchange ......................................... 11
  4.3.  . . . . . . . . . . . . . . . . . . . . . 12
   4.3 Certificate Request ......................................... 15
  4.4.  . . . . . . . . . . . . . . . . . . . . . 17
   4.4 Client Certificate .......................................... 15
  4.5. . . . . . . . . . . . . . . . . . . . . . . 18
   4.5 Client Key Exchange ......................................... 16
  4.6.  . . . . . . . . . . . . . . . . . . . . . 19
   4.6 Certificate Verify .......................................... 18
  4.7.  Computing the Master Secret ................................. 19 . . . . . . . . . . . . . . . . . . . . . . 20
   4.7 Elliptic Curve Certificates  . . . . . . . . . . . . . . . . . 22
   4.8 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . . 22
   5.  Cipher Suites ............................................... 19  . . . . . . . . . . . . . . . . . . . . . . . . 24
   6.  Security Considerations ..................................... 20  . . . . . . . . . . . . . . . . . . . 26
   7.  Intellectual Property Rights ................................ 20 . . . . . . . . . . . . . . . . . 27
   8.  Acknowledgments ............................................. 21
  9.  . . . . . . . . . . . . . . . . . . . . . . . 28
       References .................................................. 21
  10. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
       Authors' Addresses .......................................... 22 . . . . . . . . . . . . . . . . . . . . . . 30
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31

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.

Use of ECC within TLS may provide both bandwidth and computational
savings compared to other (ECC) is emerging as an attractive
   public-key cryptographic techniques.
Furthermore, the efficiencies provided by ECC may increase cryptosystem for mobile/wireless environments.  Compared
   to currently prevalent cryptosystems such as RSA, ECC offers
   equivalent security
requirements increase based on Moore's law - this with smaller key sizes.  This is illustrated by in
   the following table, based on [LEN], [2], which gives approximate comparable
   key sizes for symmetric systems, ECC systems, symmetric- and DH/DSA/RSA systems asymmetric-key cryptosystems based on
   the running times of the best best-known algorithms known today. for attacking them.

                   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

   Smaller key sizes result in power, bandwidth and computational
   savings that make ECC may offer are likely to become increasingly
desirable with the widespread use of TLS by wireless devices -
discussed, especially attractive for example, in [TLS-EXT]. constrained
   environments.

   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]. describes additions to 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 support ECC.  In
   particular, it defines

   o  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 use of the variety of applications Elliptic Curve Diffie-Hellman (ECDH) key agreement
      scheme with
which TLS is used.

The desire described above led to the inclusion of a substantial number
of ECC-based mechanisms. In order long-term or ephemeral keys to encourage interoperability, a
small subset of establish the mechanisms are identified as "recommended" - these
mechanisms are capable of meeting TLS
      premaster secret, and

   o  the requirements use of many
applications fixed-ECDH certificates and they should therefore be used unless an application
profile ECDSA for authentication of this document states otherwise, or unless in a particular
environment considerations such as export regulations mandate
otherwise.
      TLS peers.

   The remainder of this document is organized as follows.  Section 2
specifies
   provides an overview of ECC-based key exchange algorithms for TLS using ECC. TLS.
   Section 3
specifies how describes the use of ECC certificates for client authentication is performed using ECC.
   authentication.  Section 4
describes the TLS-specific specifies various data structures and computations involved needed
   for an ECC-based handshake, their encoding in TLS messages and the operation
   processing of the ECC mechanisms. those messages.  Section 5 defines new ECC-based cipher
   suites
based on the ECC key exchange algorithms. Sections 6-8 discuss 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 acknowledgements acknowledgments, respectively. Section 9 supplies  This is followed by a
   list of references cited elsewhere in the
document, this document and Section 10 gives the authors' contact details.
   information.

   Implementation of this specification requires familiarity with both
   TLS [3] and ECC [5][6][7][8] .

2.  Elliptic Curve Key Exchange Algorithms

   This document defines six introduces five new ECC-based key exchange algorithms based on ECC
   for
use within TLS.  All of them use ECDH to compute the TLS premaster secret
   and differ only in the lifetime of ECDH keys (long-term or ephemeral)
   and the mechanism (if any) used to authenticate them.  The derivation
   of the TLS master secret from the premaster secret and the subsequent
   generation of bulk encryption/MAC keys and initialization vectors is
   independent of the key exchange algorithm and not impacted by the
   introduction of ECC.

    The table below summarizes the new key exchange algorithms. algorithms which
   mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [3]),
   respectively.

          Key
          Exchange
          Algorithm           Description                        Key size limit
          ---------           -----------

          ECDH_ECDSA          Fixed ECDH with ECDSA signatures         None
   ECDH_ECDSA_EXPORT ECDSA-signed certificates.

          ECDHE_ECDSA         Ephemeral ECDH with ECDSA signatures         ECDH=163 bits,
                                                         ECDSA=none signatures.

          ECDH_RSA            Fixed ECDH with RSA signatures           None
   ECDH_RSA_EXPORT RSA-signed certificates.

          ECDHE_RSA           Ephemeral ECDH with RSA signatures           ECDH=163 bits,
                                                         RSA = none signatures.

          ECDH_anon           Anonymous ECDH, no signatures      None
   ECDH_anon_EXPORT   Anonymous ECDH, no signatures      ECDH=163 bits signatures.

                     Table 2: Key ECC key exchange algorithms

   Note that the anonymous key exchange algorithms marked "anon" do algorithm does not provide
   authentication of the server or the client, and, like client.  Like other "anon" anonymous TLS
   key exchange algorithms, may be exchanges, it is subject to man-in-the-middle attacks.
   Implementations of these algorithms this algorithm 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

   Note that there is used no structural difference between ECDH and ECDSA
   keys.  A certificate issuer may use X509.v3 keyUsage and
   extendedKeyUsage extensions to compute restrict the master secret. The server is authenticated
via a certificate containing use of an ECDH ECC public key signed with ECDSA.

Specifically this
   to certain computations.  This document refers to an ECC key exchange algorithm MUST proceed as follows:

- The server provides a static ECDH-
   capable if its use in ECDH public key is permitted.  ECDSA-capable is defined
   similarly.

              Client                                        Server
              ------                                        ------

              ClientHello          -------->
                                                       ServerHello
                                                      Certificate*
                                                ServerKeyExchange*
                                              CertificateRequest*+
                                   <--------       ServerHelloDone
              Certificate*+
              ClientKeyExchange
              CertificateVerify*+
              [ChangeCipherSpec]
              Finished             -------->
                                                [ChangeCipherSpec]
                                   <--------              Finished

              Application Data     <------->      Application Data

                 Figure 1: Message flow in the server
  certificate a full TLS handshake
                   * message using the format described in Section 4.1. The
  certificate is signed using ECDSA.

- The server key exchange not sent under some conditions
                   + message is not sent.

- Unless sent unless the client authentication using ECDH is performed as specified
                     authenticated

   Figure 1 shows all messages involved in
  Sections 3.2 and 3.3, the client provides an ephemeral ECDH public TLS key in establishment
   protocol (aka full handshake).  The addition of ECC has direct impact
   only on the client the server's Certificate message, the ServerKeyExchange,
   the ClientKeyExchange, the CertificateRequest, the client's
   Certificate message, and the CertificateVerify.  Next, we describe
   each ECC key exchange message using algorithm in greater detail in terms of the format described
   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 4.5. 3.

2.1 ECDH_ECDSA

   In this case, ECDH_ECDSA, the client server's certificate MUST contain an ECDH-capable
   public key and certificate
  verify message are not be signed with ECDSA.

   A ServerKeyExchange MUST NOT be sent unless client authentication is performed
  using ECDSA as specified in Section 3.1, or another signature
  algorithm.

- If (the server's certificate
   contains all the necessary keying information required by the client authentication using ECDH is performed,
   to arrive at the premaster secret).

   The client provides
  a static 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 client certificate
   ClientKeyExchange message (except when using the
  format described client authentication
   algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in Section 4.4. In this which case an empty client key
  exchange message is sent using the format described in
   modifications from section Section 4.5, and
  the certificate verify message is not sent.

- The 3.2 or Section 3.3 apply).

   Both client and server compute MUST perform an ECDH operation and use the master
   resultant shared secret using their as the premaster secret.  All ECDH key
  pairs
   calculations are performed 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 4.8

2.2 ECDHE_ECDSA

   In ECDHE_ECDSA, the master secret. The server
is authenticated via a server's certificate containing MUST contain an ECDH ECDSA-
   capable public key and be signed with ECDSA.

This key exchange algorithm

   The server MUST proceed in the same way as ECDH_ECDSA,
except that the key size for send its ephemeral ECDH public keys is constrained to 163
bits or less. Here the key size and a
   specification of an elliptic the corresponding curve public in the ServerKeyExchange
   message.  These parameters MUST be signed with ECDSA using the
   private key refers corresponding to the size of public key in the underlying finite field over which server's
   Certificate.

   The client MUST generate an ECDH key pair on the elliptic same curve is defined.

2.3.  ECDH_RSA as the
   server's ephemeral ECDH is used to compute key and send its public key in the master secret. The
   ClientKeyExchange message.

   Both client and server is authenticated
via a certificate containing MUST perform an ECDH public key signed with RSA. operation (Section 4.8)
   and use the resultant shared secret as the premaster secret.

2.3 ECDH_RSA

   This key exchange MUST proceed in algorithm is the same way as ECDH_ECDSA, ECDH_ECDSA except
that the
   server's certificate is signed with RSA.

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 MUST be signed with RSA. RSA rather than ECDSA.

2.4 ECDHE_RSA

   This key exchange algorithm MUST proceed in is the same way as ECDH_RSA, ECDHE_ECDSA except that the
   server's certificate MUST contain an RSA public key size authorized for ECDH public keys is constrained to be 163
bits or less.

2.5.  ECDH_anon

Anonymous ECDH is used to compute
   signing and the master secret.

Specifically this key exchange algorithm signature in the ServerKeyExchange message MUST proceed as follows:

- be
   computed with the corresponding RSA private key.  The server
   certificate message is not MUST be signed with RSA.

2.5 ECDH_anon

   In ECDH_anon, the server's Certificate, the CertificateRequest, the
   client's Certificate, and the CertificateVerify messages MUST NOT be
   sent.

-

   The server provides MUST send an ephemeral ECDH public key in the server key
  exchange message using and a specification
   of the format described corresponding curve in Section 4.2.

- The client certificate message is not sent.

- the ServerKeyExchange message.  These
   parameters MUST NOT be signed.

   The client provides MUST generate an ECDH key pair on the same curve as the
   server's ephemeral ECDH key and send its public key in the client key
  exchange message using the format described in Section 4.5.

- The
   ClientKeyExchange message.

   Both client and server compute MUST perform an ECDH operation and use the master
   resultant shared secret using their ECDH
  key pairs as specified in Section 4.7. the premaster secret.  All ECDH computations for this key exchange algorithm
   calculations 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. specified in Section 4.8

3.  ECC Client Authentication

   This document defines three new ECC-based client authentication methods
- mechanisms
   named after the type of client certificate involved: ECDSA_sign, ECDSA_fixed_ECDH,
   ECDSA_fixed_ECDH and RSA_fixed_ECDH.

To encourage interoperability, implementations SHOULD support
ECDSA_fixed_ECDH. Implementations MAY support  The ECDSA_sign mechanism is
   usable with any of the non-anonymous ECC key exchange algorithms
   described in Section 2 as well as 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 non-anonymous (non-ECC) key
   exchange algorithms the method may be used with, what
constraints apply to the method, 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 formats
   use of the certificate
request, client certificate, a long-term ECDH client key exchange, and certificate
verify messages.

3.1.  ECDSA_sign would jeopardize the forward
   secrecy property of these algorithms.

   The server can request ECC-based client supplies a certificate containing an ECDSA public key, and
authenticates itself authentication by signing the including
   one or more of these certificate verify message with types in its
ECDSA key pair.

This client authentication method CertificateRequest
   message.  The server MUST proceed as follows.

Applicable key exchange algorithms:

- This client authentication method is eligible NOT include any certificate types that are
   prohibited for use with all the
  non-anonymous ECC-based key exchange algorithms specified in Section
  2, and all the existing non-anonymous TLS negotiated key exchange algorithms
  specified in [TLS].

Restrictions:

- In order to perform this method, the algorithm.  The client
   must possess check if it possesses a certified
  ECDSA public key.

Message exchange:

- The server requests use certificate appropriate for any of the ECDSA_sign method
   methods suggested by sending the server and is willing to use it for
   authentication.

   If these conditions are not met, the client should send a
  certificate request client
   Certificate message containing no certificates.  In this case, the value "ecdsa_sign" using
  the format
   ClientKeyExchange should be sent as described in Section 4.3. When 2 and the
   CertificateVerify should not be sent.  If the server requires client receives this
  request,
   authentication, it checks that it possesses may respond with a fatal handshake failure alert.

   If the client has an appropriate certificate and
  that it is willing to proceed.

- If the client proceeds, use it sends its
   for authentication, it MUST send that certificate containing its ECDSA
  public key in the client certificate client's
   Certificate message using the format
  described in (as per Section 4.4. It signs the handshake messages exchanged
  so far with its ECDSA key pair 4.4) and conveys prove possession of the resulting signature
   private key corresponding to the server in the certified key.  The process of
   determining an appropriate certificate verify message using the format
  specified in Section 4.6.

- (If the client does not proceed, it may perform client and proving possession is
   different for each authentication
  using another method suggested by the mechanism and described below.

   NOTE: It is permissible for a server in the certificate to 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 (and the key exchange without client
  authentication - in which case the to
   send) a client certificate and certificate
  verify messages are not sent.)

ECDSA computations for of a different type than the server
   certificate.

3.1 ECDSA_sign

   To use this client authentication method are performed
according to ANSI X9.62 [ANSIX962] using mechanism, the hash function SHA-1
[FIPS180-1].

3.2.  ECDSA_fixed_ECDH

The client supplies an ECDSA-signed MUST possess a
   certificate containing an ECDH ECDSA-capable public key using the same elliptic curve domain parameters as the
server's ECDH public key. and signed with
   ECDSA.

   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 MUST prove possession of the private key corresponding to one of
   the ECDH
public keys exchanged.)

This client authentication method MUST proceed as follows.

Applicable certified key exchange algorithms:

- This method is eligible for use with all by including a signature in the non-anonymous ECC-based
  key exchange algorithms specified CertificateVerify
   message as described in Section 2.

Restrictions:

- In order to perform 4.6.

3.2 ECDSA_fixed_ECDH

   To use this client authentication method, mechanism, the client
  must MUST possess an ECDSA-signed a
   certificate containing an ECDH ECDH-capable public key using and that
   certificate MUST be signed with ECDSA.  Furthermore, the client's
   ECDH key MUST be on the same elliptic curve domain parameters as the server's long-term
   (certified) 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. key.

   When the client receives using 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 authentication mechanism, the client certificate message using the format
  described in Section 4.4. It sends MUST send an
   empty client key exchange
  message using the format ClientKeyExchange as described in Section 4.5. It does not 4.5 and MUST NOT send
   the certificate verify CertificateVerify message. It uses its static ECDH key pair,
  along with  The ClientKeyExchange is empty since
   the server's client's ECDH public key) when computing the master
  secret and finished message.

- (If the client does not proceed, it may perform client authentication
  using another method suggested key required 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 compute the
ECSVDP-DH
   premaster 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 is available inside the hash function
SHA-1 [FIPS180-1].

3.3.  RSA_fixed_ECDH client's certificate.  The client supplies an RSA-signed certificate containing an ECDH
public key using
   client's ability to arrive at the same elliptic curve domain parameters as the
server's ECDH public key. The client authenticates itself by computing
the master premaster secret and as the finished message. (This achieves
authentication because these computations can only be performed server
   (demonstrated by a
party possessing successful exchange of Finished messages) proves
   possession of the private key corresponding to one of the ECDH certified public keys exchanged.)
   key and the CertificateVerify message is unnecessary.

3.3 RSA_fixed_ECDH

   This client authentication method MUST proceed in the same manner as
the mechanism is identical to ECDSA_fixed_ECDH method, except that
   the client's certificate must 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". RSA.

4. Data Structures and Computations

   This section specifies the data structures and computations used by the
   ECC-based key mechanisms specified in Sections Section 2 and Section 3.  The
   presentation language used here is the same as that used in RFC 2246 [TLS]. Because
these specifications extend the TLS protocol specification, [3].
   Since this specification extends TLS, these descriptions should be
   merged with those in the TLS specification and in any other
specifications which others that 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.

4.1 Server Certificate

   When this message is sent:

   This message is sent in the following key exchange algorithms:

All the all non-anonymous ECC-based key exchange algorithms specified in
Section 2.
   algorithms.

   Meaning of this message:

   This message is used to authentically convey the server's static
   public key to the client.  The following table shows the server
   certificate type appropriate for each key exchange algorithm.  ECC
   public keys must be encoded in certificates as described in Section
   4.7.

   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 types are given (first in the
following table. chain).

          Key Exchange Algorithm  Server Certificate Type
          ----------------------  -----------------------

          ECDH_ECDSA              ECC public key; the certificate              Certificate must
                               allow the key to be used for key
                               agreement. The certificate contain an
                                  ECDH-capable public key. It
                                  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.

          ECDHE_ECDSA             Certificate must contain an
                                  ECDSA-capable public key. It
                                  must be signed with ECDSA.

          ECDH_RSA                ECC public key which can be used for key
                               agreement.                Certificate must contain an
                                  ECDH-capable public key. It
                                  must be signed with RSA.

       ECDH_RSA_EXPORT         ECC

          ECDHE_RSA               Certificate must contain an
                                  RSA public key which can be used authorized for key
                               agreement; key size must be 163 bits or
                               less. Certificate
                                  use in digital signatures. It
                                  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.

   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 is appropriate for the
   negotiated key exchange algorithm.

4.2.

4.2 Server Key Exchange

   When this message is sent:

   This message is sent in the following key exchange algorithms:

Both when using the anonymous ECC-based ECDHE_ECDSA, ECDHE_RSA and
   ECDH_anon key exchange algorithms specified in
Section 2. algorithms.

   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

   explicit_prime:  Indicates the elliptic curve domain parameters will be are
      conveyed verbosely, and that the underlying finite field is a prime
      field.

explicit_char2

   explicit_char2:  Indicates the elliptic curve domain parameters will be are
      conveyed verbosely, and that the underlying finite field is a
      characteristic 2 field.

named_curve

   named_curve:  Indicates that a named curve will be is used. The use of this  This option is
strongly recommended.
      SHOULD be used when applicable.

        struct {
            opaque a <1..2^8-1>;
            opaque b <1..2^8-1>;
            opaque seed <0..2^8-1>;
        } ECCurve;

   a, b 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 Section 4.3.3 of
      ANSI X9.62 [7].

   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

   point:  This is the byte string representation of an elliptic curve
      point following the conversion routine in [X9.62], section 4.3.6. Section 4.3.6 of ANSI
      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.

        enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;

ec_basis_trinomial

   ec_basis_trinomial:  Indicates representation of a characteristic two
      field using a trinomial basis.

ec_basis_pentanomial

   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), reserved (240..247), (255)
        } NamedCurve;

   sect163k1, etc etc:  Indicates use of the corresponding recommended named curve
      specified in SEC 2
[SEC2]. [12].  Note that many of these curves are also
      recommended in ANSI X9.62 [ANSIX962], [7], and FIPS 186-2 [FIPS186-2]. [9].  Values 240
      through 247 are reserved for private use.

        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

   curve_type:  This identifies the type of the elliptic curve domain
      parameters.

prime_p

   prime_p:  This is the odd prime defining the field Fp.

curve

   curve:  Specifies the coefficients a and b (and optional seed) of the
      elliptic curve E.

base

   base:  Specifies the base point G on the elliptic curve.

order

   order:  Specifies the order n of the base point.

cofactor

   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

   m:  This is the degree of the characteristic-two field F2^m.

k

   k:  The exponent k for the trinomial basis representation x^m+x^k+1. x^m + x^k
      +1.

   k1, k2, k3 k3:  The exponents for the pentanomial representation x^m+x^k3+x^k2+x^k1+1.

namedcurve x^m +
      x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).

   namedcurve:  Specifies a recommended set of elliptic curve domain
      parameters.

        struct {
            ECParameters    curve_params;
            ECPoint         public;
        } ServerECDHParams;

curve_params

   curve_params:  Specifies the elliptic curve domain parameters
      associated with the ECDH public key.

public

   public:  The ephemeral ECDH public key.

   The ServerKeyExchange message is extended as follows.

        enum { ec_diffie_hellman } KeyExchangeAlgorithm;

   ec_diffie_hellman:  Indicates the ServerKeyExchange message contains
      an ECDH public key.

        select (KeyExchangeAlgorithm) {
            case ec_diffie_hellman:
                ServerECDHParams    params;
                Signature           signed_params;
        } ServerKeyExchange;

params

   params:  Specifies the ECDH public key and associated domain
      parameters.

signed_params
This element

   signed_params:  A hash of the params, with the signature appropriate
      to that hash applied.  The private key corresponding to the
      certified public key in the server's Certificate message is empty used
      for signing.

          enum { ecdsa } SignatureAlgorithm;
          select (SignatureAlgorithm) {
              case ecdsa:
                  digitally-signed struct {
                      opaque sha_hash[20];
                  };
          } Signature;

   NOTE: SignatureAlgorithm is 'rsa' for all the ECDHE_RSA key exchange algorithms specified
   algorithm and 'anonymous' for ECDH_anon.  These cases are defined in
this document.
   TLS [3].  SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA.  ECDSA
   signatures are generated and verified as described in Section 4.8.

   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]. [6].  It conveys this information to
   the client in the ServerKeyExchange message using the format defined
   above.

   Actions of the recipient:

   The client verifies the signature (when present) and retrieves the
   server's elliptic curve domain parameters and ephemeral ECDH public
   key from the ServerKeyExchange message.

4.3.

4.3 Certificate Request

   When this message is sent:

   This message is sent when requesting the following client
authentication methods:

Any of the ECC-based client authentication methods specified in
Section 3. authentication.

   Meaning of this message:

   The server uses this message to indicate which suggest acceptable client
   authentication
methods the server would like to use. methods.

   Structure of this message:

   The TLS CertificateRequest message is extended as follows.

        enum {
         ecdsa_sign (5), rsa_fixed_ecdh (6),
            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.

      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.

   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.

4.4 Client Certificate

   When this message is sent:

   This message is sent in the following client authentication methods:

All the ECC-based response to a CertificateRequest when a
   client authentication methods specified in Section 3. has a suitable certificate.

   Meaning of this message:

   This message is used to authentically convey the client's static
   public key to the server.  The appropriate following table summarizes what client
   certificate types are given 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.

   NOTE: The client's Certificate message is capable of carrying a chain
   of certificates.  The restrictions mentioned in Table 4 apply only to
   the
following table. client's certificate (first in the chain).

          Client
          Authentication Method   Client Certificate Type
       Method
          ---------------------   -----------------------

          ECDSA_sign              ECC              Certificate must contain an
                                  ECDSA-capable public key which can and
                                  be used for
                               signing. signed with ECDSA.

          ECDSA_fixed_ECDH        ECC        Certificate must contain an
                                  ECDH-capable public key which can be used for key
                               agreement. Certificate on the
                                  same elliptic curve as the server's
                                  long-term ECDH key. This certificate
                                  must be signed with ECDSA.

          RSA_fixed_ECDH          ECC          Certificate must contain an
                                  ECDH-capable public key which can be used for key
                               agreement. Certificate on the
                                  same elliptic curve as the server's
                                  long-term ECDH key. This 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 client 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 is appropriate for the
   client authentication method.

4.5.

4.5 Client Key Exchange

   When this message is sent:

   This message is sent in the following key exchange algorithms:

All the ECC-based all key exchange algorithms specified in Section 2. algorithms.  If client
   authentication with fixed ECDH ECDSA_fixed_ECDH or RSA_fixed_ECDH is not being used, the this
   message is empty.  Otherwise, it contains the client's ephemeral ECDH
   public key, otherwise the message
is empty. key.

   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 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.)

        struct {
            select (EphemeralPublicKey) {
                case yes: ECPoint  ecdh_Yc;
                case no:  struct { };
            } ecdh_public;
        } ClientECDiffieHellmanPublic;

ecdh_Yc

   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]. [6].  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
   ClientKeyExchange message and checks that it is on the public key represents a
point of the same elliptic curve.

4.6.
   curve as the server's ECDH key.

4.6 Certificate Verify

   When this message is sent:

   This message is sent in when the following client authentication methods: sends a client certificate
   containing a public key usable for digital signatures, e.g.  when the
   client is authenticated using the ECDSA_sign mechanism.

   Meaning of the message:

   This message contains an ECDSA a signature on that proves possession of the handshake messages in
order
   private key corresponding to authenticate the client to public key in the server. client's
   Certificate message.

   Structure of this message:

   The TLS CertificateVerify message is extended as follows.

        enum { ec_dsa ecdsa } SignatureAlgorithm;

        select (SignatureAlgorithm) {
            case ec_dsa: ecdsa:
                digitally-signed struct {
                    opaque sha_hash[20];
                };
        } Signature;

In

   For the CertificateVerify message, ecdsa case, the signature field contains in the
client's CertificateVerify
   message contains an ECDSA signature on the computed over handshake messages
   exchanged so far.
According to [ANSIX962], the  ECDSA signatures are computed as described in
   Section 4.8.  As per ANSI X9.62, an ECDSA 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 [7].  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 all 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 sent or
   received starting at client conveys hello up to but not including this
   message.  It uses the private key corresponding to its signature certified
   public key to compute the server signature which is conveyed 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 client's Certificate message.

4.7.  Computing the Master Secret

In all

4.7 Elliptic Curve Certificates

   X509 certificates containing ECC public keys or signed using ECDSA
   MUST comply with [14].  Clients SHOULD use the ECC-based key exchange algorithms specified elliptic curve domain
   parameters recommended in Section 2,
the client ANSI X9.62 [7], FIPS 186-2 [9], and SEC 2
   [12].

4.8 ECDH, ECDSA and RSA Computations

   All ECDH calculations (including parameter and server compute the master key generation as follows:

- They both compute a single well
   as the shared secret K of length 20 bytes using
  their ECDH key pairs with ECDH computations calculation) MUST be performed as specified by according to [6]
   using the ECKAS-DH1 scheme in [IEEE1363] with the ECSVDP-DH secret value derivation
   primitive, and the KDF1 key derivation primitive function using SHA-1 [FIPS180-1].

- They both use K [9].  The
   output of this scheme, i.e.  the 20-byte SHA-1 output from the KDF,
   is the premaster secret.

   DISCUSSION POINT:

   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 pre_master_secret, SHA-1 step and compute directly
   use the octet string representation of the x coordinate of the
  master_secret
   elliptic curve point resulting from the pre_master_secret ECDH computation as specified premaster
   secret).  This is similar to conventional DH in [TLS]. TLS [3], and it is
   appropriate for TLS given that TLS already defines a PRF for
   determining the actual symmetric keys.

   The TLS PRF (which is used to derive the master secret from the
   premaster secret and the symmetric keys from the master secret) has
   an internal security limit of at most 288 bits (128 + 160 for MD5 and
   SHA-1), so the use of KDF1 with SHA-1 can be seen to actually weaken
   the theoretical security of the protocol.

   Options to solve this problem include the following:

   o  Omit the SHA-1 step as describe above.  (BM)

   o  Continue to use KDF1 with SHA-1 for curves up to, say, 288 bits
      (more precisely: for curves where FE2OSP returns an octet string
      up to 36 octets) and omit the SHA-1 step only for larger curves.
      (SBW/BM)

   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 first solution will break compatibility with existing
   implementations based on draft-ietf-tls-ecc-01.txt.  The second and
   third solutions are somewhat of a kludge, but maintain compatibility
   (in a large range).

   OPEN QUESTION: We invite comments on which of these solutions would
   be preferred.

   END OF DISCUSSION POINT.

   All ECDSA computations MUST be performed according to ANSI X9.62 [7]
   using the SHA-1 [9] hash function.  The 20 bytes of the SHA-1 are run
   directly through the ECDSA algorithm with no additional hashing.

   All RSA signatures must be generated and verified according to PKCS#1
   [10].

5. Cipher Suites

   The table below defines the new ECC cipher suites specified in this document
for that 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 TLS_ECDHE_ECDSA_WITH_NULL_SHA          = { 0x00, 0x4B 0x?? }
     CipherSuite TLS_ECDH_ECDSA_EXPORT_WITH_RC4_56_SHA TLS_ECDHE_ECDSA_WITH_RC4_128_SHA       = { 0x00, 0x4C 0x?? }
     CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  = { 0x00, 0x4D 0x?? }
     CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x4E 0x?? }
     CipherSuite TLS_ECDH_RSA_WITH_DES_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x4F 0x?? }

     CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA             = { 0x00, 0x?? }
     CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA          = { 0x00, 0x?? }
     CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x50 0x?? }
     CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x51 0x?? }
     CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x52 0x?? }

     CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_40_SHA TLS_ECDHE_RSA_WITH_NULL_SHA            = { 0x00, 0x53 0x?? }
     CipherSuite TLS_ECDH_RSA_EXPORT_WITH_RC4_56_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA         = { 0x00, 0x54 0x?? }
     CipherSuite TLS_ECDH_anon_NULL_WITH_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x55 0x?? }
     CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA     = { 0x00, 0x56 0x?? }

     CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA TLS_ECDH_anon_NULL_WITH_SHA            = { 0x00, 0x57 0x?? }
     CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA         = { 0x00, 0x?? }
     CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x58 0x?? }
     CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA     = { 0x00, 0x59 0x?? }
     CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA     = { 0x00, 0x5A 0x?? }

                        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]. [3].  AES
   ciphers are defined in [TLS-AES].

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

   Server implementations SHOULD support all of these the following 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. 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.

6. Security Considerations

   This document is entirely concerned with security mechanisms.

   This document is based on [TLS], [ANSIX9.62], and [IEEE1363] [3], [6], [7] and the [11].  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). (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. [13].  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, Anderson and Brian Minard for their help preparing this document.

9. Tim Dierks.

References

[ANSIX9.62]  ANSI X9.62-1999,

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

   [2]   Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
         Sizes", Journal of Cryptology 14 (2001) 255-293, <http://
         www.cryptosavvy.com/>.

   [3]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
         2246, January 1999.

   [4]   Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol
         Version 3.0", November 1996, <http://wp.netscape.com/eng/ssl3/
         draft302.txt>.

   [5]   SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http://
         www.secg.org/>.

   [6]   IEEE, "Standard Specifications for Public Key Cryptography",
         IEEE 1363, 2000.

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

[FIPS180]

   [8]   NIST, "Digital Signature Standard", FIPS 180-1, 2000.

   [9]   NIST, "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 1995.

   [10]  RSA Laboratories, "PKCS#1: RSA Encryption Standard version
         1.5", PKCS 1, November 1993.

   [11]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Public Key
             Cryptography", Institute of Electrical
         Transport Layer Security (TLS)", RFC 3268, June 2002.

   [12]  SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
         2000, <http://www.secg.org/>.

   [13]  Hovey, R. and Electronics
             Engineers, 2000.

[MUST] S. Bradner, "Key Words for Use "The Organizations Involved in RFCs to Indicate
             Requirement Levels", the
         IETF Standards Process", RFC 2119, March 1997.

[PKIX-ALG]   L. Bassham, 2028, BCP 11, October 1996.

   [14]  Polk, T., Housley, R. Housley and W. Polk, L. Bassham, "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 Revocation List (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.

10.
         3279, April 2002.

Authors' Addresses

Authors:

   Vipul Gupta
   Sun Microsystems Laboratories
   2600 Casey Avenue
   MS UMTV29-235
   Mountain View, CA  94303
   USA

   Phone: +1 650 336 1681
   EMail: vipul.gupta@sun.com

   Simon Blake-Wilson
Certicom Corp.
sblake-wilson@certicom.com

Tim Dierks
Certicom Corp.
timd@consensus.com
   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
Certicom Corp.
chawk@certicom.com
   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.