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

Versions: 00

   TLS Working Group                               Ari Singer
   INTERNET-DRAFT                                  NTRU Cryptosystems
   Expires: January 3, 2002                        July 3, 2001


                        NTRU Cipher Suites for TLS
                       <draft-ietf-tls-ntru-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC 2026 [RFC2026].

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

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Conventions used in this document

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


Abstract

   This document defines a group of new TLS cipher suites that utilize
   the NTRU encryption algorithm and the NSS signature algorithm.
   These cipher suites are designed to maximize computational
   efficiency on both the client and server sides and ease deployment
   of the TLS protocol on constrained and embedded devices.  The
   document assumes the reader is familiar with the TLS protocol.


Table of Contents

   Status of this Memo................................................1
   Conventions used in this document..................................1
   Abstract...........................................................1
   1. Overview........................................................3
   2. NTRU Key Exchange Algorithms....................................3

   Singer       INTERNET DRAFT - Expires January 2002        [Page 1]

                      NTRU Cipher Suites for TLS             July 2001

   2.1 NTRU_NSS.......................................................4
   2.2 NTRU_RSA.......................................................4
   3. NTRU Client Authentication......................................5
   3.1 nss_sign.......................................................5
   3.2 rsa_nss........................................................5
   4. Message Structures..............................................6
   4.1 Server Certificate.............................................6
   4.2 Server Certificate Request.....................................7
   4.3 Client Certificate.............................................8
   4.4 Client Key Exchange............................................8
   4.5 Client Certificate Verify......................................9
   5. Cryptographic Computations and Encoding........................10
   5.1 NSS Digital Signing...........................................11
   5.2 NSS Signature Verification....................................11
   5.3 NTRU Encryption...............................................12
   5.4 NTRU Decryption...............................................12
   6. Cipher Suites..................................................13
   7. Security Considerations........................................13
   8. Intellectual Property Rights...................................13
   9. References.....................................................15
   Authors' Addresses................................................15

   Singer       INTERNET DRAFT - Expires January 2002        [Page 2]

                      NTRU Cipher Suites for TLS             July 2001

1. Overview

   The TLS protocol was designed with the purpose of enabling private
   and authenticated communication over the Internet, typically between
   high bandwidth and computationally rich entities.  This goal is
   achieved through the use of a combination of public-key techniques,
   which provide authentication and key agreement between two parties
   that may not have a-priori knowledge of each other, and symmetric
   key techniques, which provide data privacy, continued authentication
   and efficiencies in bandwidth and computational effort.

   The purpose of this document is to specify new cipher suites that
   significantly reduce the computational cost of public-key operations
   and that are easy to implement on constrained devices.  In practice,
   the computational cost of the public-key computations in TLS causes
   the most latency in the handshake and is often the limiting factor
   for server capacity of running multiple TLS sessions at once.  In
   addition, TLS, especially with client authentication, may be
   difficult to implement on wireless devices and other constrained
   devices due to memory and computational limitations.  The use of the
   NTRU encryption algorithm in the TLS handshake and the use of the
   NSS signature algorithm in the handshake and digital certificates
   may allow for greater server scalability, decreased latency in the
   handshake and deployment of the TLS protocol on a larger population
   of devices.

   This document specifies only cipher suites and the aspects of the
   TLS protocol that need to be modified in order to implement the
   cipher suites.  No other changes to the TLS protocol are required.
   For use of this Internet Draft, familiarity with the TLS protocol is
   assumed.  For full details of the TLS protocol, see RFC 2246
   [RFC2246].

   In this document, the terms Client Hello, Server Hello and Client
   Response refer to the grouping of consecutive messages sent in the
   initial handshake by either the server or client.  The terms
   ClientHello, ServerKeyExchange, etc. refer to the specific messages
   defined in the TLS specification [RFC2246].


2. NTRU Key Exchange Algorithms

   This document defines two new key exchange algorithms based on NTRU
   for use within TLS.  These algorithms all utilize the NTRU
   encryption algorithm, but utilize different authentication
   mechanisms.

   The key exchange algorithms are as follows:

   Key Exchange Algorithm       Description

   NTRU_NSS                     NTRU encryption with NSS signatures
   NTRU_RSA                     NTRU encryption with RSA signatures


   Singer       INTERNET DRAFT - Expires January 2002        [Page 3]

                      NTRU Cipher Suites for TLS             July 2001

   In both of the above key exchange algorithms, the server SHALL send
   an X.509 certificate in the Certificate field that is included in
   the Server Hello.  This certificate SHALL contain an NTRU public key
   and be signed with the specified signature algorithm.  The client
   SHALL verify that the certificate is valid and, if it is valid,
   generate a pre-master secret and encrypt it with the server public
   key.  After successful verification of the server certificate, the
   client SHALL send the encrypted pre-master secret in the
   ClientKeyExchange field that is included in the Client Response.  If
   the server desires for the client to be authenticated, the server
   MAY request a client certificate.  Client certificate types for
   client authentication are defined in this document and specified in
   section 3.

   The key strength of the NTRU public key determines the size of the
   pre-master secret.  The following table shows the required sizes of
   the pre-master secret with the corresponding NTRU key strength.
   NTRU 251, 347 and 503 provide roughly equivalent security to RSA
   1024, RSA 2048 and RSA 4096 respectively.

   Key Strength                 Pre-master Secret Size

   NTRU 251                     20 Bytes
   NTRU 347                     32 Bytes
   NTRU 503                     48 Bytes

2.1 NTRU_NSS

   For key exchanges using NTRU encryption with NSS signatures, the
   server certificate SHALL be an X.509 certificate that includes an
   NTRU public key and is signed by the NSS signature algorithm.  The
   basic X.509 certificate structure may be found in RFC 2459 [RFC2459]
   and the ASN.1 syntax for NTRU public keys and NSS digital signatures
   may be found in Efficient Embedded Security Standard (EESS) #1
   [EESS#1].

   The NSS signature verification on the certificate and the NTRU
   encryption and decryption of the pre-master secret SHALL be
   performed as specified in EESS #1 [EESS#1].  The exact data
   structure for NTRU and NSS public keys, NTRU encrypted data and NSS
   signatures are defined in EESS #1 [EESS#1] and explicitly specified
   in section 4.

2.2 NTRU_RSA

   For key exchanges using NTRU encryption with RSA signatures, the
   server certificate SHALL be an X.509 certificate that includes an
   NTRU public key and is signed using the RSA signature algorithm.

   The approved methods for computing and verifying RSA signatures are
   listed in RFC 2246 [RFC2246], which references PKCS #1 [PKCS1].  The
   NTRU encryption and decryption of the pre-master secret SHALL be
   performed as specified in EESS #1 [EESS#1].  The data structures for
   RSA signatures are specified in RFC 2246 [RFC2246], which references

   Singer       INTERNET DRAFT - Expires January 2002        [Page 4]

                      NTRU Cipher Suites for TLS             July 2001

   PKCS #1 [PKCS1].  The exact data structure for NTRU public keys and
   NTRU encrypted data are defined in EESS #1 [EESS#1] and explicitly
   specified in section 4.

3. NTRU Client Authentication

   This document defines two new methods of client authentication based
   on NTRU for the TLS protocol.  Both techniques utilize the NSS
   signature algorithm and the certificates MAY be signed using either
   RSA or NSS.  If client authentication is desired during a TLS
   handshake, the client MAY present a certificate in either of the
   formats defined below or in any format permitted by RFC 2246
   [RFC2246].

   The client authentication mechanisms are as follows:

   Client Certificate Type      Description

   nss_sign                     NSS signature key certificate signed by
                                NSS
   rsa_nss                      NSS signature key certificate signed by
                                RSA

   During the initial handshake between the server and client, the
   server MAY send a certificate request.  The certificate request
   SHALL include an indication of the types of certificates that the
   server accepts and the certificate authorities that the server
   trusts.

   When a client certificate is requested by the server, if an
   appropriate certificate is available, the client SHALL include a
   client certificate in the Certificate field of the Client Response.
   In addition, the client SHALL include a digital signature of the
   handshake messages in the CertificateVerify field of the Client
   Response.

3.1 nss_sign

   For client authentication using NSS signatures, the client
   certificate SHALL be an X.509 certificate that includes an NSS
   public key and is signed by the NSS signature algorithm.  The ASN.1
   syntax for NSS public keys and NSS digital signatures may be found
   in EESS #1 [EESS#1].

   The NSS signature generation on the handshake messages and the NSS
   signature verification of the certificate and handshake messages
   SHALL be performed as specified in EESS #1 [EESS#1].  The exact data
   structure for NSS public keys and NSS signatures are defined in EESS
   #1 [EESS#1] and explicitly specified in section 4.

3.2 rsa_nss

   For client authentication using NSS signatures and RSA signed
   certificates, the client certificate SHALL be an X.509 certificate

   Singer       INTERNET DRAFT - Expires January 2002        [Page 5]

                      NTRU Cipher Suites for TLS             July 2001

   that includes an NSS public key and is signed using the RSA
   signature algorithm.

   The approved methods for computing and verifying RSA signatures are
   listed in RFC 2246 [RFC2246], which references PKCS #1 [PKCS1].  The
   NSS signature and verification of the handshake messages SHALL be
   performed as specified in EESS #1 [EESS#1].  The data structures for
   RSA signatures are specified in RFC 2246 [RFC2246], which references
   PKCS #1 [PKCS1].  The exact data structure for NSS public keys and
   NSS signatures are defined in EESS #1 [EESS#1] and explicitly
   specified in section 4.

4. Message Structures

   This section defines the specific message data structures necessary
   for implementation of the TLS protocol using the NTRU and NSS
   cryptographic algorithms.  These definitions should be taken within
   the context of the TLS protocol as defined in RFC 2246 [RFC2246] and
   used where appropriate.  The naming conventions for the specific
   fields are consistent with RFC 2246 [RFC2246].  The cryptographic
   computations and encoding of NTRU and NSS cryptographic data items
   are specified in section 5.

   The following data structures are defined in this section:

   Data Structure              Description

   Server Certificate          The signed data structure that is sent
                               during the Server Hello for server
                               authentication and key exchange.
   Server Certificate Request  The data structure that is used to
                               request a client certificate for client
                               authentication.
   Client Certificate          The signed data structure that is sent
                               during the Client Response for client
                               authentication.
   Client Key Exchange         The data structure that includes the
                               encrypted pre-master secret for the
                               upcoming secure session.
   Client Certificate Verify   The signature that is sent during the
                               Client Response that authenticates the
                               client for that handshake.

4.1 Server Certificate

   When this message will be sent:
        In all non-anonymous TLS handshakes, the server sends a server
        certificate to the client during the Server Hello.  This
        message will always immediately follow the ServerHello message.

   Meaning of this message:
        The certificate type SHALL be appropriate for the selected
        cipher suite's key exchange algorithm and is generally an
        X.509v3 certificate.  The public key may be of any length.  The

   Singer       INTERNET DRAFT - Expires January 2002        [Page 6]

                      NTRU Cipher Suites for TLS             July 2001

        certificate is used to authenticate the server to the client
        and provide the encryption key for key exchange.

   Key Exchange Algorithm       Certificate Key Type

   NTRU_NSS                     NTRU encryption key; the certificate
                                SHALL allow the key to be used for
                                encryption.  The algorithm used to sign
                                the certificate SHALL be NSS.
   NTRU_RSA                     NTRU encryption key; the certificate
                                SHALL allow the key to be used for
                                encryption.  The algorithm used to sign
                                the certificate SHALL be RSA.

   The certificate profiles are defined by the IETF PKIX working group
   [RFC2459].  NTRU and NSS key and cryptographic formats are defined
   by the CEES [EESS#1].  RSA key and cryptographic formats are defined
   by PKCS #1 [PKCS#1].  When a key usage extension is present, the
   keyEncipherment bit must be present to allow encryption.

   Structure of this message:
        opaque ASN.1Cert<1..2^24-1>;

        struct {
                ASN.1Cert certificate_list<0..2^24-1>;
        } Certificate;

   certificate_list
        This is a sequence of X.509v3 certificates as specified in RFC
        2246 [RFC2246] except that the key, signature and parameter
        fields for NTRU and NSS are as specified in EESS #1 [EESS#1].

4.2 Server Certificate Request

   When this message will be sent:
        A non-anonymous server MAY request a certificate from the
        client if client authentication is desired.  This message, if
        sent, SHALL be sent in the Server Hello immediately following
        the ServerKeyExchange message, if it is sent, or the Server
        Certificate message.

   Meaning of this message:
        This message informs the client that the server requests the
        use of a client certificate.  It informs the client of the
        types of certificate accepted by the server and

   Structure of this message:
        For consistency with draft-ietf-tls-ecc-01.txt, the TLS
        CertificateRequest message is extended as follows:

        enum { nss_sign (8), nss_rsa (9), (255)
        } ClientCertificateType;

   nss_sign

   Singer       INTERNET DRAFT - Expires January 2002        [Page 7]

                      NTRU Cipher Suites for TLS             July 2001

        The server requests a client certificate that contains an NSS
        key and is signed by an NSS signature.

   rsa_nss
        The server requests a client certificate that contains an NSS
        key and is signed by an RSA signature.

4.3 Client Certificate

   When this message will be sent:
        If the server has requested a client certificate and the client
        wishes to send a certificate to the server, the client MAY send
        a Client Certificate message.  This message, if sent, SHALL be
        the first message in the Client Response.

   Meaning of this message:
        The certificate type SHOULD be selected among the certificate
        types requested by the server and is generally an X.509v3
        certificate.  The public key may be of any length.  The
        certificate is used to authenticate the client to the server.

        The certificate profiles are defined by the IETF PKIX working
        group [RFC2459].  NSS keys and cryptographic formats are
        defined by the CEES [EESS#1].  RSA keys and cryptographic
        formats are defined by PKCS #1 [PKCS#1].  When a key usage
        extension is present, the digitalSignature bit must be set for
        the key to be eligible for signing.

   Structure of this message:
        opaque ASN.1Cert<1..2^24-1>;

        struct {
                ASN.1Cert certificate_list<0..2^24-1>;
        } Certificate;

   certificate_list
        This is a sequence of X.509v3 certificates as specified in RFC
        2246 [RFC2246] except that the key, signature and parameter
        fields for NTRU and NSS are as specified in EESS #1 [EESS#1].

4.4 Client Key Exchange

   When this message will be sent:
        This message is always sent in the Client Response.  It SHALL
        immediately follow the client certificate message, if it is
        sent.  Otherwise, it SHALL be the first message in the Client
        Response.

   Meaning of this message:
        This message contains the NTRU encrypted pre-master secret.
        The pre-master secret is used in TLS along with the other data
        to calculate the master secret.  Depending on the NTRU key
        size, the pre-master secret will have different sizes.  For the

   Singer       INTERNET DRAFT - Expires January 2002        [Page 8]

                      NTRU Cipher Suites for TLS             July 2001

        table of permitted key sizes and pre-master secret sizes, see
        section 2.

   Structure of this message:
        The structure of the message depends on the selected key
        exchange method.  The KeyExchangeAlgorithm and
        ClientKeyExchange from RFC 2246 [RFC2246] are extended to
        include NTRU.

        NOTE: The operation public-key-encrypted is defined in RFC 2246
        [RFC2246] section 4.7 and specifies that the length is
        represented as an opaque vector <0..2^16-1>, where the length
        is specified by the encryption algorithm (e.g. NTRU) and key.

        enum { ntru } KeyExchangeAlgorithm;

   ntru
        The KeyExchangeAlgorithm message contains an NTRU public key.

        struct {
                select (KeyExchangeAlgorithm) {
                        case ntru: NTRUEncryptedPreMasterSecret;
                } exchange_keys;
        } ClientKeyExchange

        enum { NTRU251 (1), NTRU347 (2), NTRU503 (3), (255)
        } NTRUKeyStrength

   NTRU251, NTRU347, NTRU503
        The number in the NTRU key strength name represents the size of
        the NTRU degree N (e.g. NTRU251 has degree N equal to 251).

        select (NTRUKeyStrength) {
                case NTRU251: opaque random [20];
                case NTRU347: opaque random [32];
                case NTRU503: opaque random [48];
        } PreMasterSecret

   random
        The random variable is a securely generated random value to be
        used as the pre-master secret.

        struct {
                public-key-encrypted PreMasterSecret pre_master_secret;
        } NTRUEncryptedPreMasterSecret;

   pre_master_secret
        The value of the pre-master secret, which is encrypted with the
        NTRU encryption key provided by the server to obtain the
        NTRUEncryptedPreMasterSecret.

4.5 Client Certificate Verify

   When this message will be sent:

   Singer       INTERNET DRAFT - Expires January 2002        [Page 9]

                      NTRU Cipher Suites for TLS             July 2001

        This message SHALL only be sent following a client certificate
        that contains a key that has singing capability (e.g. an NSS
        signing key).  When sent, it SHALL immediately follow the
        client key exchange message in the Client Response.

   Meaning of this message:
        This message is the digital signature of all of the preceding
        handshake messages and is used to provide explicit verification
        of a client certificate.

   Structure of this message:
        The SignatureAlgorithm and Signature from RFC 2246 [RFC2246]
        are extended to include NSS.

        NOTE: The operation digitally-signed is defined in RFC 2246
        [RFC2246] section 4.7 and specifies that the length is
        represented as an opaque vector <0..2^16-1>, where the length
        is specified by the signature algorithm (e.g. NSS) and key.

        enum { nss } SignatureAlgorithm;

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

   sha_hash
        This is the SHA-1 hash of all of the preceding handshake
        messages.  The SHA-1 algorithm is defined in FIPS 180-1
        [FIPS180-1].

        struct {
                Signature signature;
        } CertificateVerify;


5. Cryptographic Computations and Encoding

   This section specifies the exact cryptographic computations and
   encoding of NTRU and NSS data structures that are needed in order to
   implement TLS with the NTRU and NSS cipher suites.  When not
   explicitly stated, all cryptographic encoding and computations SHALL
   be as specified in RFC 2246 [RFC2246].  Note that in particular, RSA
   signature verification on certificates SHALL be computed as
   specified in RFC 2246 [RFC2246].

   The following cryptographic computations and descriptions of their
   use in TLS are defined in this section.

   Computation                 Description

   NSS Digital Signing         The operation of computing the NSS
                               digital signature on the specified hash

   Singer       INTERNET DRAFT - Expires January 2002       [Page 10]

                      NTRU Cipher Suites for TLS             July 2001

                               value and encoding the signature as an
                               opaque object.
   NSS Signature Verification  The operation of verifying an NSS
                               digital signature on a certificate or on
                               the handshake messages.
   NTRU Encryption             The operation of computing the NTRU
                               encryption of the pre-master secret and
                               encoding the encrypted data as an opaque
                               object.
   NTRU Decryption             The operation of decrypting the pre-
                               master secret.

5.1 NSS Digital Signing

   When this operation is performed:
        Whenever client authentication is performed, the client
        generates an NSS digital signature on all of the preceding
        handshake messages and places this signature in the
        CertificateVerify message in the Client Response.

        NSS digital signatures on certificates are outside of the scope
        of TLS, however, it is assumed that the NSS certificate
        signatures are performed as specified by the SVSSA signature
        scheme as defined in EESS #1 [EESS#1] and encoded in the
        certificate according to EESS #1 [EESS#1].

   Operation:
        For all NSS digital signature operations in this document, the
        signature SHALL be performed as specified by the SVSSA
        signature scheme as defined in EESS #1 [EESS#1].  The parameter
        values SHALL be included in the client certificate and SHALL be
        interpreted according to EESS #1 [EESS#1].  For the
        ClientVerify message, the input to the signature scheme SHALL
        be the concatenation of all of the previous handshake messages
        and the hash function for creating the hash of the message
        SHALL be SHA-1 [FIPS180-1] and SHALL NOT be MD5.

   Encoding:
        The structure of NSS signatures, written in TLS as the function
        digitally-signed, SHALL be encoded as a type 1 vector as
        defined in EESS #1 [EESS#1].  (This is essentially the
        polynomial written as a byte string of coefficients ordered
        from lowest degree to highest, with each byte representing a
        single coefficient.)

5.2 NSS Signature Verification

   When this operation is performed:
        The client performs NSS signature verification to verify the
        server certificate in all NTRU cipher suites.  The server
        performs NSS signature verification in all client authenticated
        handshakes to verify the client certificate and to verify the
        ClientVerify message.


   Singer       INTERNET DRAFT - Expires January 2002       [Page 11]

                      NTRU Cipher Suites for TLS             July 2001

   Operation:
        For all NSS verification operations in this document, the
        verification SHALL be performed as specified by the SVSSA
        signature scheme as defined in EESS #1 [EESS#1].  The server
        SHALL verify that the parameter values be included in the
        client certificate and interpret them according to EESS #1
        [EESS#1].  For the ClientVerify message verification, the input
        to the verification process SHALL be the concatenation of all
        of the previous handshake messages and the hash function for
        creating the hash of the message SHALL be SHA-1 [FIPS180-1] and
        SHALL NOT be MD5.  If all of the above checks pass, the server
        SHALL accept the signature as valid, otherwise the server SHALL
        reject the signature as invalid.

5.3 NTRU Encryption

   When this operation is performed:
        The client performs NTRU encryption on the pre-master secret in
        all cipher suites defined in this document.  The encrypted pre-
        master secret is included in the ClientKeyExchange message in
        the Client Response.

   Operation:
        For all NTRU encryption operations in this document, the
        encryption SHALL be performed as specified by the SVES
        encryption scheme as defined in EESS #1 [EESS#1].  The
        parameter values SHALL be included in the server certificate
        (or ServerKeyExchange message) and SHALL be interpreted
        according to EESS #1 [EESS#1].  For the ClientKeyExchange
        message, the input to the encryption scheme SHALL be the pre-
        master secret as the leftmost (first) bytes, padded on the
        right (end) by any byte string that makes the total length
        equal to the input length of the encryption function (e.g. for
        NTRU 251, the 20-byte pre-master secret will be padded with 1
        byte on the right to obtain a 21-byte input to the encryption
        function).  The padding SHOULD consist of all '0' bytes.

   Encoding:
        The structure of NTRU encryptions, written in TLS as the
        function public-key-encrypted, SHALL be encoded as a type 1
        vector as defined in EESS #1 [EESS#1].  (This is essentially
        the polynomial written as a byte string of coefficients ordered
        from lowest degree to highest (left to right), with each byte
        representing a single coefficient.)

5.4 NTRU Decryption

   When this operation is performed:
        The server performs NTRU decryption on the encrypted pre-master
        secret in all cipher suites defined in this document.  The
        encrypted pre-master secret is included in the
        ClientKeyExchange message in the Client Response.

   Operation:

   Singer       INTERNET DRAFT - Expires January 2002       [Page 12]

                      NTRU Cipher Suites for TLS             July 2001

        For all NTRU decryption operations in this document, the
        decryption SHALL be performed as specified by the SVES
        encryption scheme as defined in EESS #1 [EESS#1].  The server
        SHALL use the parameter values that are included in the server
        certificate and interpret them according to EESS #1 [EESS#1].
        For the decryption of the pre-master secret, the input to the
        decryption process SHALL be the encrypted pre-master secret
        included in the ClientKeyExchange message.  The output of the
        NTRU decryption operation SHALL be truncated to obtain the pre-
        master secret by taking the leftmost (first) n bytes of the
        plaintext, where n is the length of the pre-master secret.

6. Cipher Suites

   The table below defines the cipher suites specified in this
   document.  They are interpreted according to their names in the same
   manner as in RFC 2246 [RFC2246].  The key agreement methods
   specified in this standard are NTRU_NSS and NTRU_RSA.  The cipher
   suite numbers are subject to change depending on the numbering
   conventions and the numbers that are already used.

   CipherSuite TLS_NTRU_NSS_WITH_RC4_128_SHA           = { 0x00, 0x61 }
   CipherSuite TLS_NTRU_NSS_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x62 }
   CipherSuite TLS_NTRU_NSS_WITH_AES_128_CBC_SHA       = { 0x00, 0x63 }
   CipherSuite TLS_NTRU_NSS_WITH_AES_256_CBC_SHA       = { 0x00, 0x64 }
   CipherSuite TLS_NTRU_RSA_WITH_RC4_128_SHA           = { 0x00, 0x65 }
   CipherSuite TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x66 }
   CipherSuite TLS_NTRU_RSA_WITH_AES_128_CBC_SHA       = { 0x00, 0x67 }
   CipherSuite TLS_NTRU_RSA_WITH_AES_256_CBC_SHA       = { 0x00, 0x68 }

   Ciphers other than AES ciphers and hash algorithms are specified in
   RFC 2246 [RFC2246].  AES ciphers are specified in [TLS-AES].

   Implementations supporting NTRU cipher suites SHOULD support the
   following cipher suite.  Implementations MAY support any of the
   other cipher suites.

   TLS_NTRU_NSS_WITH_AES_128_CBC_SHA

7. Security Considerations

   This document is entirely concerned with security mechanisms.  It is
   based on the TLS specification [RFC 2246], IEEE P1363.1 [P1363.1]
   and EESS #1 [EESS#1] and the appropriate security considerations
   from those documents apply.

8. Intellectual Property Rights

   NTRU Cryptosystems, Inc. has been granted U.S. Patent No. 6,081,597,
   which covers aspects of the NTRU public-key encryption scheme, and
   has applied for a patent (or patents) that covers the NSS public-key
   signature scheme.  In addition, NTRU Cryptosystems may have applied
   for additional patent coverage on implementation techniques related

   Singer       INTERNET DRAFT - Expires January 2002       [Page 13]

                      NTRU Cipher Suites for TLS             July 2001

   to the use of NTRU or NSS.  This and any additional patent
   information will be sent to the IETF.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification
   can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights, which may cover technology that may be required to implement
   the techniques in this document.  Please address the information to
   the IETF Executive Director.

   Singer       INTERNET DRAFT - Expires January 2002       [Page 14]

                      NTRU Cipher Suites for TLS             July 2001


9. References

   [EESS#1] Efficient Embedded Security Standards (EESS) #1:
   Implementation Aspects of NTRU and NSS, Draft Version 2, May 18,
   2001, Consortium for Efficient Embedded Security Standards,
   Available at http://www.ceesstandards.org.

   [FIPS180-1]  FIPS PUB 180-1, Secure Hash Standard, Federal
   Information Processing Standards Publication 180-1, U.S. Department
   of Commerce/National Institute of Standards and Technology, National
   Technical Information Service, Springfield, Virginia, April 17, 1995
   (supersedes FIPS PUB 180).  Available at
   http://www.itl.nist.gov/div897/pubs/fip180-1.htm.

   [P1363.1] IEEE Draft Standard P1363.1 D2: IEEE Standard
   Specifications for Public-Key Cryptographic Techniques Based on Hard
   Problems over Lattices, Draft 2, May 2001, Available at
   http://grouper.ieee.org/groups/1363.

   [PKCS#1] RSA Laboratories.  RSA Encryption Standard.  Version 2.0,
   October 1, 1998.

   [RFC2026] S. Bradner, "The Internet Standards Process", IETF RFC
   2026, October 1996

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

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

   [RFC2459] R. Housley, W. Ford, W. Polk and D. Solo, "Internet X.509
   Public Key Infrastructure Certificate and CRL Profile", IETF RFC
   2459, January 1999

   [TLS-AES] P. Chown, "AES Ciphersuites for TLS", draft-ietf-tls-
   ciphersuite-03.txt, January 22, 2001



Authors' Addresses

   Ari Singer
   NTRU
   5 Burlington Woods           Phone:  1-781-418-2515
   Burlington, MA  01803, USA   Email:  asinger@ntru.com





   Singer       INTERNET DRAFT - Expires January 2002       [Page 15]


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