[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 4492

Transport Layer Security Working Group                         T. Dierks
INTERNET-DRAFT                               Consensus Development Corp.
Expires September, 1998                                      B. Anderson
                                                          Certicom Corp.
                                                          March 13, 1998

                       ECC Cipher Suites For TLS
                       draft-ietf-tls-ecc-00.txt

1.  Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or made obsolete 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.

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

2.  Introduction

   This document describes additions to TLS to support the Elliptic
   Curve Cryptosystem (ECC).  The document assumes that the reader is
   familiar with the TLS protocol.

   The document defines cipher suites which use the Elliptic Curve
   Encryption Scheme (ECES), the Elliptic Curve Digital Signature
   Algorithm (ECDSA), the Elliptic Curve Nyberg-Rueppel Signature Scheme
   with Appendix (ECNRA), the Elliptic Curve Diffie-Hellman Key
   Agreement (ECDH), and the Elliptic Curve Menezes-Qu-Vanstone Key
   Agreement (ECMQV) key establishment algorithms.  References to these
   algorithms can be found in section 13.











Dierks                                                          [Page 1]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998



3.  Table of Contents


   1.     Status of this Memo ........................................ 1
   2.     Introduction ............................................... 1
   3.     Table of Contents .......................................... 2
   4.     Rationale .................................................. 2
   5.     Elliptic Curve Key Establishment Methods ................... 3
   6.     Key Establishment Operation ................................ 5
   6.1.   ECES_ECDSA ................................................. 6
   6.2.   ECES_ECNRA ................................................. 6
   6.3.   ECDHE_ECDSA ................................................ 6
   6.4.   ECDHE_ECDSA_EXPORT ......................................... 7
   6.5.   ECDHE_ECNRA ................................................ 7
   6.6.   ECDHE_ECNRA_EXPORT ......................................... 7
   6.7.   ECDH_ECDSA ................................................. 7
   6.8.   ECDH_ECNRA ................................................. 8
   6.9.   ECMQV_ECDSA ................................................ 8
   6.10.  ECMQV_ECNRA ................................................ 9
   6.11.  ECDH_anon .................................................. 9
   6.12.  ECDH_anon_EXPORT ........................................... 9
   7.     Client Certification ....................................... 9
   8.     Data Structures ........................................... 10
   8.1.   Server Key Exchange ....................................... 10
   8.2.   Certificate Request ....................................... 13
   8.3.   Client Key Exchange ....................................... 14
   8.4.   Certificate Verify ........................................ 15
   9.     Elliptic Curve Certificates ............................... 15
   10.    Cipher Suites ............................................. 16
   11.    Elliptic Curve Cryptography Definitions ................... 17
   12.    Recommended Cipher Suites ................................. 17
   13.    References ................................................ 17
   14.    Security Considerations ................................... 18
   15.    Authors' Addresses ........................................ 18



4.  Rationale

   Several design goals drove our choice of key establishment
   algorithms:

    1. A desire to replicate all of the functionality and operating
       modes found in the current TLS cipher suites based on integer
       factorization and discret log cryptographic algorithms.

    2. While we wished to define cipher suites which use export-strength



Dierks                                                          [Page 2]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


       cryptography, we did not want to define any cipher suites which
       would require certificates with export-strength keys; thus,
       exportable cipher suites are only defined for those key
       establishment mechanisms which use the certificate key for
       authentication rather than for key establishment.

   These criteria for key establishment algorithms, when combined with a
   number of symmetric algorithms, led to a large number of possible
   cipher suites. This is problematic in that it could lead to a lack of
   interoperability due to implementors supporting different subsets of
   the available cipher suites. In order to alleviate this, we have
   indicated two of the total cipher suites as recommended (see section
   12).  Unless there are specific reasons to choose other cipher
   suites, implementors should implement the recommended suites first.

5.  Elliptic Curve Key Establishment Methods

   Key establishment is the terminology used in ISO standards to refer
   to the methods of establishing a shared key between two or more
   parties.  Within key establishment there are two classifications:
   The operation is called key transport when only one party contributes
   to the generation of the shared key.  The operation is called key
   agreement when 2 or more parties contribute to the generation of the
   shared key. For the purposes of this definition, the key in question
   is the premaster secret: TLS uses the master secret generation
   process to ensure that both parties contribute to the eventual master
   secret.

   The cipher suites defined here use the following key establishment
   methods:

   ECES_ECDSA           Elliptic-curve encryption is used for the key
                        transport; the server's certificate is signed
                        using ECDSA.

   ECES_ECNRA           Elliptic-curve encryption is used for the key
                        transport; the server's certificate is signed
                        using ECNRA.

   ECDHE_ECDSA          Ephemeral elliptic-curve Diffie-Hellman is used
                        for the key agreement; the server signs the
                        parameters with an ECDSA key and is
                        authenticated with a certificate signed with
                        ECDSA.







Dierks                                                          [Page 3]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


   ECDHE_ECDSA_EXPORT   Ephemeral elliptic-curve Diffie-Hellman in
                        export strength is used for the key agreement;
                        the server signs the parameters with an ECDSA
                        key and is authenticated with a certificate
                        signed with ECDSA.

   ECDHE_ECNRA          Ephemeral elliptic-curve Diffie-Hellman is used
                        for the key agreement; the server signs the
                        parameters with an ECNRA key and is
                        authenticated with a certificate signed with
                        ECNRA.

   ECDHE_ECNRA_EXPORT   Ephemeral elliptic-curve Diffie-Hellman in
                        export strength is used for the key agreement;
                        the server signs the parameters with an ECNRA
                        key and is authenticated with a certificate
                        signed with ECNRA.

   ECDH_ECDSA           Fixed elliptic-curve Diffie-Hellman is used for
                        the key agreement; the server's certificate is
                        signed with ECDSA.

   ECDH_ECNRA           Fixed elliptic-curve Diffie-Hellman is used for
                        the key agreement; the server's certificate is
                        signed with ECNRA.

   ECMQV_ECDSA          Ephemeral elliptic-curve MQV is used for key
                        agreement and authentication; the server is
                        authenticated with a certificate signed with
                        ECDSA.

   ECMQV_ECNRA          Ephemeral elliptic-curve MQV is used for key
                        agreement and authentication; the server is
                        authenticated with a certificate signed with
                        ECNRA.

   ECDH_anon            Anonymous elliptic-curve Diffie-Hellman is used
                        for the key agreement.

   ECDH_anon_EXPORT     Anonymous elliptic-curve Diffie-Hellman in
                        export strength is used for the key agreement.


   Key establishment mechanisms which indicate that they are for export
   strength should use an ECC key for the key agreement of no more than
   113 bits. A 113-bit ECC key provides security that is roughly
   equivalent to a 512-bit RSA key and is expected to be eligible for
   export.  The following table relates ECC key sizes to RSA key sizes



Dierks                                                          [Page 4]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


   of equivalent security.  These key sizes are considered equivalent in
   terms of work factor required to recover the private key using
   currently known fastest methods for solving the underlying
   mathematical problems of ECC and RSA.

               ECC         RSA      Time to break (MIPS-years)
             ________   _________   __________________________
             106 bits    512 bits   1E4 MY
             132 bits    768 bits   1E8 MY
             160 bits   1024 bits   1E11 MY
             191 bits   1536 bits   1E14 MY
             211 bits   2048 bits   1E20 MY

          Table 1: ECC and RSA key sizes for equivalent security

6.  Key Establishment Operation

   The TLS key establishment protocol involves this message exchange:

           Client                                        Server
           __________________               ___________________
           ClientHello          -------->
                                                    ServerHello
                                                   Certificate*
                                             ServerKeyExchange*
                                            CertificateRequest*
                                <--------       ServerHelloDone
           Certificate*
           ClientKeyExchange
           CertificateVerify*
           [ChangeCipherSpec]
           Finished             -------->
                                             [ChangeCipherSpec]
                                <--------              Finished
           Application Data     <------->      Application Data

              Figure 1: Message flow in a full TLS handshake
               * - Message is not sent under some conditions

   Of these messages, the ones involved in the key establishment itself
   are the server's Certificate message, the ServerKeyExchange, the
   client's Certificate message, and the ClientKeyExchange.

   In order to specify the ECC cipher suites, we must specify the
   following elements for each key establishment algorithm:

    -  The format of the server's certificate.




Dierks                                                          [Page 5]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


    -  The format of the server key exchange message

    -  For methods in which the client's certificate can participate in
       the key agreement, the format of the client's certificate and the
       criteria for deciding if this certificate is eligible to
       participate in the key agreement.

    -  The format of the client key exchange message

    -  How to arrive at the premaster secret given all the preceding
       information.

   Several different key establishment modes are available.  In order to
   allow full negotiation of supported algorithms, the signature
   algorithm used for the server's X.509 certificate is encoded into the
   cipher suite for those key establishment mechanisms where no
   signature algorithm is used; for those key establishments which
   utilize signature algorithms, the certificate signature algorithm is
   expected to be the same as the algorithm used in the key
   establishment.

6.1.  ECES_ECDSA

   In ECES_ECDSA, the server sends a certificate with an ECES-capable
   public key in it.  The server's certificate should be signed with
   ECDSA.  A ServerKeyExchange message is not sent because the server's
   certificate contains all the necessary keying information for the
   client to complete the key establishment.

   The client's certificate is not involved in the key establishment for
   this method, although the client can still be authenticated via the
   normal mechanism.

   The client generates a 48 byte premaster secret, encrypts it using
   ECES using the public key from the server's certificate, and sends it
   to the server in the ClientKeyExchange message (see section 8.3).

   This premaster secret is decrypted by the server and both sides use
   it to generate the master secret for this TLS session.

6.2.  ECES_ECNRA

   ECES_ECNRA is the same as ECES_ECDSA except for the fact that the
   server's certificate is signed by its CA with ECNRA.

6.3.  ECDHE_ECDSA

   In ECDHE_ECDSA, the server's certificate has an ECDSA key and is, in



Dierks                                                          [Page 6]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


   turn, signed by its CA with ECDSA. The ServerKeyExchange message
   contains an ephemeral ECDH key and a specification of the curve for
   this key. (see section 8.1).  These parameters are signed with the
   server's authenticated ECDSA key.

   The client's certificate is not involved in the key establishment for
   this method, although the client can still be authenticated via the
   normal mechanism.

   The client should verify the signature on the ServerKeyExchange
   message and generate an ECDH key on the same curve as the server's
   ephemeral key. The client encodes the public half of that key into
   the ClientKeyExchange message and sends it to the server.

   The client and server perform an ECDH key agreement using their
   private keys and the public keys they have sent to each other. The
   resultant shared secret is the premaster secret.

6.4.  ECDHE_ECDSA_EXPORT

   ECDHE_ECDSA_EXPORT is the same as ECDHE_ECDSA except for the fact
   that the curve used for the server's ephemeral ECDH key should be no
   longer than 113 bits.  Because the server's certified key is only
   used for authentication, its length is unrestricted.

6.5.  ECDHE_ECNRA

   ECDHE_ECNRA is the same as ECDHE_ECDSA except for the fact that the
   server's public key is an ECNRA key and the server's certificate is
   signed by its CA with ECNRA.

6.6.  ECDHE_ECNRA_EXPORT

   ECDHE_ECNRA_EXPORT is the same as ECDHE_ECNRA except for the fact
   that the curve used for the server's ephemeral ECDH key should be no
   longer than 113 bits.  Because the server's certified key is only
   used for authentication, its length is unrestricted.

6.7.  ECDH_ECDSA

   In ECDH_ECDSA, the server's certificate contains an ECDH public key.
   This certificate is signed by the server's CA using ECDSA.  The
   ServerKeyExchange message is not sent because the server's
   certificate contains all the necessary keying information for the
   client to complete the key establishment.

   If the server requests client authentication and includes the
   ecdsa_fixed_dh or ecnra_fixed_dh client certificate types (see



Dierks                                                          [Page 7]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


   section 8.2) and the client has a certificate which contains an ECDH
   key on the same curve as the server's public key, and this
   certificate is otherwise eligible to be used for client
   authentication, then the client's certified public key is used in
   conjunction with the server's public key to do an ECDH key agreement;
   the resultant shared secret is the premaster key.  In this situation,
   the client key exchange message is empty when sent and the client
   CertificateVerify message is not sent, as both the client and the
   server are authenticated by their ability to arrive at the same
   premaster secret.

   If client certification is not requested or if the client does not
   have a certificate with a suitable ECDH public key, the client can
   generate an ephemeral key on the same curve as the server's public
   key.  This key is encoded into the ClientKeyExchange message (see
   section 8.3) and used in conjunction with the server's key to
   complete the ECDH key agreement, yielding the premaster secret.

6.8.  ECDH_ECNRA

   ECDH_ECNRA is the same as ECDH_ECDSA except for the fact that the
   server's certificate is signed by its CA with ECNRA.

6.9.  ECMQV_ECDSA

   In ECMQV_ECDSA, the server's certificate contains an ECMQV key and is
   signed by the server's CA with ECDSA. The server then generates an
   temporary key pair and sends the public half of the temporary key in
   the ServerKeyExchange message (see section 8.1).

   If the server requests client authentication and includes the
   ecdsa_mqv or ecnra_mqv client certificate types (see section 8.2) and
   the client has a certificate which contains an ECMQV key on the same
   curve as the server's public key, and this certificate is otherwise
   eligible to be used for client authentication, then the client should
   send that certificate, then generate a temporary key and send the
   public half of that key in the ClientKeyExchange message (see section
   8.3).  The client and server then perform an MQV key agreement using
   their private keys and their peer's public keys (for each party, both
   the certified and temporary key pairs are used).  The resultant
   shared secret is the premaster secret.  The client CertificateVerify
   message is not sent, as both the client and the server are
   authenticated by their ability to arrive at the same premaster
   secret.

   If client certification is not requested or if the client does not
   have a certificate with a suitable ECMQV public key, the client
   should generate two temporary key pairs on the same curve as the



Dierks                                                          [Page 8]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


   server's public key.  The public halves of these temporary key pairs
   are encoded into the ClientKeyExchange message.  One key pair is the
   usual temporary key used for MQV and the other takes the place of the
   certified key.  Each side performs an MQV key agreement using the
   peer's public keys and its own private keys, yielding the premaster
   secret.

6.10.  ECMQV_ECNRA

   ECMQV_ECNRA is the same as ECMQV_ECDSA except for the fact that the
   server's certificate is signed by its CA with ECNRA.

6.11.  ECDH_anon

   In ECDH_anon, an anonymous Elliptic-Curve Diffie-Hellman operation is
   used to arrive at the premaster secret.  In this case, the server is
   not authenticated and may not request that the client authenticate
   itself.  The server's Certificate message is not sent. The
   ServerKeyExchange message contains the specification of a curve and a
   Diffie-Hellman public key (see section 8.1).  The client responds
   with a ClientKeyExchange message containing a Diffie-Hellman public
   key on the same curve; the premaster secret is the shared secret
   resulting from an Elliptic Curve Diffie-Hellman key agreement with
   these keys.

6.12.  ECDH_anon_EXPORT

   ECDH_anon_EXPORT is the same as ECDH_anon except for the fact that
   the curve used for the server's ephemeral ECDH key should be no
   longer than 113 bits.

7.  Client Certification

   Six new client certificate types have been added: ecdsa_sign,
   ecnra_sign, ecdsa_fixed_dh, ecnra_fixed_dh, ecdsa_mqv, and ecnra_mqv.
   As noted above, the fixed_dh and mqv types are used in key
   establishment methods which allow the client's certified key to
   participate in key agreement.  In these cases, the CertificateVerify
   message is not sent; the client's ability to arrive at the same
   premaster secret as the server demonstrates its control over the
   private half of the certified public key.

   One of these certificates is eligible for use in the key agreement
   operation if it has a key which can be used with that algorithm.
   Because elliptic curve keys have the same mathematical properties for
   all the algorithms discussed in this specification, a certificate
   could have a key which was authorized for use in any of several
   algorithms or for only a particular algorithm.  In addition to the



Dierks                                                          [Page 9]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


   key's eligibility, it must be defined using the same curve parameters
   as the server's key to be used in a operation with it.  Of course,
   the use of a certificate is always subject to any and all policy
   constraints placed on it.

   In these certificates, the ecdsa or ecnra refers to the algorithm
   which the CA uses to sign the client's certificate.

   The ecdsa_sign and ecnra_sign certificate types are used in other key
   establishment methods and in cases where the client can not or
   chooses not to supply a suitable certificate to participate in one of
   the above methods.  In these cases, the client must send a
   CertificateVerify message to demonstrate its control of the private
   half key of the certified key pair.  (See section 8.4).

   Certificates requested with the ecdsa_sign ClientCertificateType must
   include an ECDSA public key and be signed by the CA with ECDSA;
   ecnra_sign certificates must include an ECNRA key and be signed with
   ECNRA.

   With all key establishment methods, it is permissible to request a
   client certificate using a different algorithm than the one used for
   the server's certificate; for example, a server doing a ECDHE_ECDSA
   or ECMQV_ECDSA key establishment could still request an ECNRA client
   certificate.

8.  Data Structures

   Here the descriptions of the data structures exchanged are given.
   The presentation language is the same as that used in the TLS
   specification.  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.

8.1.  Server Key Exchange

   This messages is sent in the following key establishment methods:

           ECDHE_ECDSA
           ECDHE_ECDSA_EXPORT
           ECDHE_ECNRA
           ECDHE_ECNRA_EXPORT
           ECMQV_ECDSA
           ECMQV_ECNRA
           ECDH_anon



Dierks                                                         [Page 10]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


           ECDH_anon_EXPORT

   It can contain elliptic curve Diffie-Hellman keys, either signed or
   unsigned, or MQV parameters.

   Structure of this message:

       enum { ec_eces,
              ec_diffie_hellman,
              ec_menezes_qu_vanstone } KeyExchangeAlgorithm;

       enum { ec_prime_p (1),
              ec_characteristic_two (2), (255) } ECFieldID;

       enum { ec_basis_onb, ec_basis_trinomial,
              ec_basis_pentanomial } ECBasisType;

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


   a, b: These parameters specify the coefficients of the elliptic
   curve.  Each value shall be the octet string representation of a
   field element following the conversion routine in [X9.62], section
   4.3.1.

   seed: This is an optional parameter used to derive the coefficients
   of a randomly generated elliptic curve.

       struct {
           opaque point <1..2^8-1>;
       } ECPoint;


   point: This is the octet string representation of an elliptic curve
   point following the conversion routine in [X9.62], section 4.4.2.a.
   The representation format is defined following the definition in
   [X9.62], section 4.4.

       struct {
           ECFieldID   field;
           select (field) {
               case ec_prime_p:
                   opaque      prime_p <1..2^8-1>;
               case ec_characteristic_two:



Dierks                                                         [Page 11]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


                   uint16      m;
                   ECBasisType basis;
                   select (basis) {
                       case ec_basis_onb:
                           struct { };
                       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>;
       } ECParameters;


   field: This identifies the finite field over which the elliptic curve
   is defined.

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

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

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

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

   curve: Specifies the coefficients a and b of the elliptic curve E.

   base: The base point P on the elliptic curve.

   order: The order n of the base point. The order of a point P is the
   smallest possible integer n such that nP = 0 (the point at infinity).

   cofactor: The integer h = #E(Fq)/n, where #E(Fq) represents the
   number of points on the elliptic curve E defined over the field Fq.

       struct {
           ECParameters    curve_params;
           ECPoint         public;
       } ServerECDHParams;




Dierks                                                         [Page 12]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


   curve_params: This specifies the curve on which the elliptic-curve
   Diffie-Hellman key agreement is to occur.

   public: The ephemeral public key for the elliptic-curve Diffie-
   Hellman key agreement.

       struct {
           ECPoint         temp_public;
       } ServerMQVParams;


   temp_public: The temporary MQV public key; the curve on which the MQV
   operation will take place is specified by the server's certificate.

       enum { ec_dsa, ec_nra } SignatureAlgorithm;

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

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


   Note: The anonymous case for Signature is used for ECDH_anon and
   ECDH_anon_EXPORT key establishment methods: in this case, the
   Signature element is empty.

8.2.  Certificate Request

   The only addition to this message is six new types for the client
   certificate.

   Structure of this message:

       enum {



Dierks                                                         [Page 13]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


           ecdsa_sign(5), ecnra_sign(6),
           ecdsa_fixed_dh(7), ecnra_fixed_dh(8),
           ecdsa_mqv (9), ecnra_mqv (10), (255)
       } ClientCertificateType;


8.3.  Client Key Exchange

   This message is sent in all key exchanges. It can contain either an
   ECES encrypted secret, an ECDH public key (for use in ECDHE or
   ECDH_anon key establishment methods), an ECMQV temporary public key,
   or two temporary keys for use with MQV when the client does not have
   a suitable certificate.

   Structure of this message:

       struct {
           select (PublicValueEncoding) {
               case implicit: struct { };
               case explicit: ECPoint  ecdh_Yc;
           } ecdh_public;
       } ClientECDiffieHellmanPublic;


   If the client has sent a certificate with an ECDH key, the
   PublicValueEncoding will be implicit and this message will be empty.
   Otherwise, ecdh_Yc will be the client's public value for the Diffie-
   Hellman key agreement.

       struct {
           select (PublicValueEncoding) {
               case implicit: struct { };
               case explicit: ECPoint  ecmqv;
           } ecmqv_public;
           ECPoint     ecmqv_temp;
       } ClientECMQVPublic;


   If the client has sent a certificate with an MQV key, the
   PublicValueEncoding will be implicit and the ecmqv_public field will
   be empty; otherwise, ecmqv will contain the client's MQV public
   value.  In either case, ecmqv_temp will contain the temporary public
   key for the MQV operation.

   In the explicit case, the cost of an additional key generation can be
   saved by generating only one ephemeral key and sending two copies:
   one in ecmqv and one in ecmqv_temp.




Dierks                                                         [Page 14]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


       struct {
           select (KeyExchangeAlgorithm) {
               case ec_eces: EncryptedPreMasterSecret;
               case ec_diffie_hellman: ClientECDiffieHellmanPublic;
               case ec_menezes_qu_vanstone: ClientECMQVPublic;
           } exchange_keys;
       } ClientKeyExchange;


   In the ECES case, the premaster secret will be sent encrypted with
   the server's public key.  The standard TLS definition of
   EncryptedPreMasterSecret is suitable for this transmission.

8.4.  Certificate Verify

   This message is sent when the client has sent a certificate which did
   not participate in a Diffie-Hellman or Menezes-Qu-Vanstone key
   agreement.

   This type needs no new definition: the CertificateVerify message in
   TLS uses the Signature type, which we have extended for ECDSA and
   ECNRA (see section 8.1).

9.  Elliptic Curve Certificates

   All X.509 certificates must be in compliance with the PKIX profile of
   the X.509 standard [PKIX].  Elliptic curve keys should be encoded
   into X.509 certificates as specified in [PKIX-ECDSA].  However, this
   document currently only specifies formats for ECDSA keys and
   signatures.

   When this document refers to a certificate with an ECDSA, ECNRA,
   ECES, ECDH, or ECMQV key, it means a public key which is capable of
   performing a particular algorithm and which is permitted by the
   policy encoded in the certificate to participate in this algorithm.
   This may be a key which is specifically indicated as being useful for
   a particular algorithm or a general-purpose elliptic curve key which
   is allowed to perform a particular operation.

   The X.509 key usage extension encodes functions a key is allowed to
   perform.  The relevant key usage bits for algorithms are:

                       Algorithm   Key Usage Bit
                       _________   ________________
                       ECDSA       digitalSignature
                       ECNRA       digitalSignature
                       ECES        keyEncipherment
                       ECDH        keyAgreement
                       ECMQV       keyAgreement


Dierks                                                         [Page 15]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


                  Table 2: Pertinent X.509 key usage bits

   A TLS entity shall not present a certificate which is not eligible to
   participate in the negotiated cipher suite and shall refuse to
   communicate with a TLS peer which presents such a certificate.

10.  Cipher Suites

   The following cipher suites are defined:

 CipherSuite TLS_ECES_ECDSA_NULL_SHA                   = { 0x00, 0x2C }
 CipherSuite TLS_ECES_ECDSA_WITH_RC4_128_SHA           = { 0x00, 0x2D }
 CipherSuite TLS_ECES_ECDSA_WITH_DES_CBC_SHA           = { 0x00, 0x2E }
 CipherSuite TLS_ECES_ECDSA_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x2F }
 CipherSuite TLS_ECES_ECNRA_NULL_SHA                   = { 0x00, 0x30 }
 CipherSuite TLS_ECES_ECNRA_WITH_RC4_128_SHA           = { 0x00, 0x31 }
 CipherSuite TLS_ECES_ECNRA_WITH_DES_CBC_SHA           = { 0x00, 0x32 }
 CipherSuite TLS_ECES_ECNRA_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x33 }
 CipherSuite TLS_ECDHE_ECDSA_NULL_SHA                  = { 0x00, 0x34 }
 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA          = { 0x00, 0x36 }
 CipherSuite TLS_ECDHE_ECDSA_WITH_DES_CBC_SHA          = { 0x00, 0x37 }
 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x38 }
 CipherSuite TLS_ECDHE_ECDSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x39 }
 CipherSuite TLS_ECDHE_ECDSA_EXPORT_WITH_RC4_40_SHA    = { 0x00, 0x40 }
 CipherSuite TLS_ECDHE_ECNRA_NULL_SHA                  = { 0x00, 0x41 }
 CipherSuite TLS_ECDHE_ECNRA_WITH_RC4_128_SHA          = { 0x00, 0x42 }
 CipherSuite TLS_ECDHE_ECNRA_WITH_DES_CBC_SHA          = { 0x00, 0x43 }
 CipherSuite TLS_ECDHE_ECNRA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x44 }
 CipherSuite TLS_ECDHE_ECNRA_EXPORT_WITH_DES40_CBC_SHA = { 0x00, 0x45 }
 CipherSuite TLS_ECDHE_ECNRA_EXPORT_WITH_RC4_40_SHA    = { 0x00, 0x46 }
 CipherSuite TLS_ECDH_ECDSA_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_ECNRA_NULL_SHA                   = { 0x00, 0x4B }
 CipherSuite TLS_ECDH_ECNRA_WITH_RC4_128_SHA           = { 0x00, 0x4C }
 CipherSuite TLS_ECDH_ECNRA_WITH_DES_CBC_SHA           = { 0x00, 0x4D }
 CipherSuite TLS_ECDH_ECNRA_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x4E }
 CipherSuite TLS_ECMQV_ECDSA_NULL_SHA                  = { 0x00, 0x4F }
 CipherSuite TLS_ECMQV_ECDSA_WITH_RC4_128_SHA          = { 0x00, 0x50 }
 CipherSuite TLS_ECMQV_ECDSA_WITH_DES_CBC_SHA          = { 0x00, 0x51 }
 CipherSuite TLS_ECMQV_ECDSA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x52 }
 CipherSuite TLS_ECMQV_ECNRA_NULL_SHA                  = { 0x00, 0x53 }
 CipherSuite TLS_ECMQV_ECNRA_WITH_RC4_128_SHA          = { 0x00, 0x54 }
 CipherSuite TLS_ECMQV_ECNRA_WITH_DES_CBC_SHA          = { 0x00, 0x55 }
 CipherSuite TLS_ECMQV_ECNRA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x56 }
 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA               = { 0x00, 0x57 }
 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA            = { 0x00, 0x58 }



Dierks                                                         [Page 16]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


 CipherSuite TLS_ECDH_anon_WITH_DES_CBC_SHA            = { 0x00, 0x59 }
 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA       = { 0x00, 0x5A }
 CipherSuite TLS_ECDH_anon_EXPORT_WITH_DES40_CBC_SHA   = { 0x00, 0x5B }
 CipherSuite TLS_ECDH_anon_EXPORT_WITH_RC4_40_SHA      = { 0x00, 0x5C }

                      Table 3: TLS ECC cipher suites

   The key establishment method, cipher, and hash algorithm for each
   cipher suite are easily determined by examining the name. Those
   cipher suites which use the "NULL" cipher or one of the "EXPORT" key
   establishment mechanisms are considered to be "exportable" cipher
   suites for the purposes of the TLS protocol.

11.  Elliptic Curve Cryptography Definitions

   These definitions provide a quick reference for the elliptic curve
   terms.

   Elliptic curve         Definition to come.

   Elliptic curve point   Definition to come.

   EC parameters          Definition to come.

   EC private key         Definition to come.

   EC public key          Definition to come.

   EC key pair            Definition to come.


12.  Recommended Cipher Suites

   In order to promote common interoperability, two cipher suites are
   recommended for initial implementation:
   TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA and
   TLS_ECDHE_ECDSA_EXPORT_WITH_RC4_40_SHA. Implementing these two gives
   a basis of cryptographic strength, perfect forward secrecy, and
   well-accepted algorithms.

13.  References

   [ECDH] IEEE P1363 Working Draft, February, 1997.

   [ECDSA] IEEE P1363 Working Draft, February, 1997.

   [ECDSA] ANSI X9.62 Working Draft, November 17, 1997.




Dierks                                                         [Page 17]

INTERNET-DRAFT         ECC Cipher Suites For TLS          March 13, 1998


   [ECES] ANSI X9.63 Working Draft.

   [ECMQV] IEEE P1363 Working Draft, February, 1997.

   [ECNRA] IEEE P1363 Working Draft, February, 1997.

   [PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key
   Infrastructure: Part I:  X.509 Certificate and CRL Profile, <draft-
   ietf-pkix-ipki-part1-06.txt>, October 1997.

   [PKIX-ECDSA] L. Bassham, D. Johnson, W. Polk, Representation of
   Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and
   Signatures in Internet X.509 Public Key Infrastructure Certificates
   <draft-ietf-pkix-ipki-ecdsa-01.txt>, November 1997.

   [X9.62] ANSI X9.62 Working Draft, November 17, 1997.

14.  Security Considerations

   This document is entirely concerned with security mechanisms.
   Implementors should take care to ensure that code which controls
   security mechanisms is free of errors which might be exploited by
   attackers.

15.  Authors' Addresses

   Authors:

           Tim Dierks
           Consensus Development
           timd@consensus.com

           Bill Anderson
           Certicom
           banderson@certicom.com

   Contributors:

           Gilles Garon
           ggaron@aol.com











Dierks                                                         [Page 18]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/