added the new tls-ciphersuite draft, and the ciphersuite TLS_DH_anon_RIJNDAEL_CBC_SHAgnutls0-0-4

2 files changed, 453 insertions, 0 deletions

diff --git a/doc/draft-ietf-tls-ciphersuite-02.txt b/doc/draft-ietf-tls-ciphersuite-02.txt
new file mode 100644
index 0000000000..a5f6644467
--- /dev/null
+++ b/doc/draft-ietf-tls-ciphersuite-02.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         Pete Chown
+INTERNET DRAFT                                        Skygate Technology
+<draft-ietf-tls-ciphersuite-02.txt>                     15 November 2000
+
+                        AES Ciphersuites for TLS
+
+Status of this Memo
+
+     This document is an Internet-Draft and is in full conformance with
+     all provisions of Section 10 of RFC2026.
+
+     Internet-Drafts are working documents of the Internet Engineering
+     Task Force (IETF), its areas, and its working groups. Note that
+     other groups may also distribute working documents as Internet-
+     Drafts.
+
+     Internet-Drafts are draft documents valid for a maximum of six
+     months and may be updated, replaced, or obsoleted by other docu­
+     ments 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>
+
+     Distribution of this document is unlimited. Please send comments to
+     the author (pc@skygate.co.uk) or to the Transport Layer Security
+     Working Group's discussion list (ietf-tls@lists.certicom.com).
+
+Overview
+
+     At present, the symmetric ciphers supported by TLS are RC2, RC4,
+     IDEA, DES and triple DES.  The protocol would be enhanced by the
+     addition of AES [AES] ciphersuites, for the following reasons:
+
+     1.  RC2, RC4 and IDEA are all subject to intellectual property
+         claims.  RSA Security Inc has trademark rights in the names RC2
+         and RC4, and claims that the RC4 algorithm itself is a trade
+         secret.  Ascom Systec Ltd owns a patent on the IDEA algorithm.
+
+     2.  Triple DES is much less efficient than more modern ciphers.
+
+     3.  Now the AES process is completed there will be commercial pres­
+         sure to use the selected cipher.  The AES is efficient and has
+         withstood extensive cryptanalytic efforts.  The AES is
+
+
+
+Chown                                                           [Page 1]
+
+ietf-tls-ciphersuite-02 AES Ciphersuites for TLS        15 November 2000
+
+
+         therefore a desirable choice.
+
+     4.  Currently the DHE ciphersuites only allow triple DES (along
+         with some ``export'' variants which offer reduced key lengths).
+         At the same time the DHE ciphersuites are the only ones to
+         offer forward secrecy.
+
+     This document proposes several new ciphersuites, with the aim of
+     overcoming these problems.
+
+     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.
+
+Cipher Usage
+
+     The new ciphersuites proposed here are very similar to the follow­
+     ing, defined in [TLS]:
+
+     TLS_RSA_WITH_3DES_EDE_CBC_SHA
+     TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
+     TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
+     TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
+     TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
+     TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
+
+     All the ciphersuites described here use the AES in cipher block
+     chaining (CBC) mode.  Furthermore, they use SHA-1 [SHA-1] in an
+     HMAC construction as described in section 5 of [TLS].  (Although
+     the TLS ciphersuite names include the text ``SHA'', this actually
+     refers to the modified SHA-1 version of the algorithm.)
+
+     The ciphersuites differ in the type of certificate and key exchange
+     method.  The ciphersuites defined here use the following options
+     for this part of the protocol:
+
+     CipherSuite                           Certificate type (if applicable)
+                                           and key exchange algorithm
+
+     TLS_RSA_WITH_AES_128_CBC_SHA          RSA
+     TLS_DH_DSS_WITH_AES_128_CBC_SHA       DH_DSS
+     TLS_DH_RSA_WITH_AES_128_CBC_SHA       DH_RSA
+     TLS_DHE_DSS_WITH_AES_128_CBC_SHA      DHE_DSS
+     TLS_DHE_RSA_WITH_AES_128_CBC_SHA      DHE_RSA
+     TLS_DH_anon_WITH_AES_128_CBC_SHA      DH_anon
+
+     For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA
+     and DH_anon, please refer to sections 7.4.2 and 7.4.3 of [TLS].
+
+
+
+Chown                                                           [Page 2]
+
+ietf-tls-ciphersuite-02 AES Ciphersuites for TLS        15 November 2000
+
+
+     The AES supports key lengths of 128, 192 and 256 bits.  At the pre­
+     sent time, all of these are believed to be secure against even the
+     best equipped attackers.  The overall strength of TLS is such that
+     there is no gain from using a key length longer than 128 bits.
+     Accordingly the AES will use 128 bit keys.
+
+     The new ciphersuites will have the following definitions:
+
+     CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x2F };
+     CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA   = { 0x00, 0x30 };
+     CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x31 };
+     CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA  = { 0x00, 0x32 };
+     CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA  = { 0x00, 0x33 };
+     CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA  = { 0x00, 0x34 };
+
+     In the absence of an application profile standard specifying other­
+     wise:
+
+     1.  Servers MUST provide at least one of
+         TLS_RSA_WITH_AES_128_CBC_SHA and
+         TLS_DHE_RSA_WITH_AES_128_CBC_SHA.
+
+     2.  Clients MUST provide both TLS_RSA_WITH_AES_128_CBC_SHA and
+         TLS_DHE_RSA_WITH_AES_128_CBC_SHA.
+
+     (A TLS implementation which does not follow this requirement is
+     non-compliant with this RFC.  However, it will still be a valid TLS
+     implementation if it complies with [TLS].)
+
+     Implementations MAY provide any of the other ciphersuites described
+     above.
+
+Security Considerations
+
+     It is not believed that the new ciphersuites are ever less secure
+     than the corresponding older ones.  The AES is believed to be
+     secure, and it has withstood extensive cryptanalytic attack.
+
+     The ephemeral Diffie-Hellman ciphersuites provide forward secrecy
+     without any known reduction in security in other areas.  To obtain
+     the maximum benefit from these ciphersuites:
+
+     1.  The ephemeral keys should only be used once.  With the TLS pro­
+         tocol as currently defined there is no efficiency gain from
+         reusing ephemeral keys.
+
+     2.  Ephemeral keys should be destroyed securely when they are no
+         longer required.
+
+
+
+Chown                                                           [Page 3]
+
+ietf-tls-ciphersuite-02 AES Ciphersuites for TLS        15 November 2000
+
+
+     3.  The random number generator used to create ephemeral keys must
+         not reveal past output even when its internal state is compro­
+         mised.
+
+     [TLS] describes the anonymous Diffie-Hellman (ADH) ciphersuites as
+     deprecated.  The ADH ciphersuite defined here is not deprecated.
+     However, when it is used, particular care must be taken:
+
+     1.  ADH provides confidentiality but not authentication.  This
+         means that (if authentication is required) the communicating
+         parties must authenticate to each other by some means other
+         than TLS.
+
+     2.  ADH is vulnerable to man-in-the-middle attacks, as a conse­
+         quence of the lack of authentication.  The parties must have a
+         way of determining whether they are participating in the same
+         TLS connection.  If they are not, they can deduce that they are
+         under attack, and presumably abort the connection.
+
+         For example, if the parties share a secret, it is possible to
+         compute a MAC of the TLS Finished message.  An attacker would
+         have to negotiate two different TLS connections; one with each
+         communicating party.  The Finished messages would be different
+         in each case, because they depend on the master secret.  For
+         this reason, the MACs computed by each party would be differ­
+         ent.
+
+         It is important to note that authentication techniques which do
+         not use the Finished message do not usually provide protection
+         from this attack.  For example, the client could authenticate
+         to the server with a password, but it would still be vulnerable
+         to man-in-the-middle attacks.
+
+Copyright
+
+     Copyright (C) The Internet Society 2000. 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, pub­
+     lished and distributed, in whole or in part, without restriction of
+     any kind, provided that the above copyright notice and this para­
+     graph are included on all such copies and derivative works. How­
+     ever, 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 proce­
+     dures for copyrights defined in the Internet Standards process must
+
+
+
+Chown                                                           [Page 4]
+
+ietf-tls-ciphersuite-02 AES Ciphersuites for TLS        15 November 2000
+
+
+     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 assignees.
+
+     This document and the information contained herein is provided on
+     an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI­
+     NEERING 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 WAR­
+     RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+     The IETF takes no position regarding the validity or scope of any
+     intellectual property or other rights that might be claimed to per­
+     tain to the implementation or use other 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 pro­
+     prietary rights by implementors 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 practice
+     this standard. Please address the information to the IETF Executive
+     Director.
+
+     During the development of the AES, NIST published the following
+     statement on intellectual property:
+
+          SPECIAL NOTE - Intellectual Property
+
+          NIST reminds all interested parties that the adoption of
+          AES is being conducted as an open standards-setting
+          activity. Specifically, NIST has requested that all
+          interested parties identify to NIST any patents or inven­
+          tions that may be required for the use of AES. NIST
+          hereby gives public notice that it may seek redress under
+          the antitrust laws of the United States against any party
+          in the future who might seek to exercise patent rights
+
+
+
+Chown                                                           [Page 5]
+
+ietf-tls-ciphersuite-02 AES Ciphersuites for TLS        15 November 2000
+
+
+          against any user of AES that have not been disclosed to
+          NIST in response to this request for information.
+
+     One of the authors of Rijndael signed the following disclaimer when
+     submitting the algorithm to NIST for consideration in the AES pro­
+     cess:
+
+          I, Joan Daemen, do hereby declare that to the best of my
+          knowledge the practice of the algorithm, reference imple­
+          mentation, and mathematically optimized implementations,
+          I have submitted, known as Rijndael may be covered by the
+          following U.S. and/or foreign patents:
+
+          none
+
+          I do hereby declare that I am aware of no patent applica­
+          tions which may cover the practice of my submitted algo­
+          rithm, reference implementation or mathematically opti­
+          mized implementations.
+
+          I do hereby understand that my submitted algorithm may
+          not be selected for inclusion in the Advanced Encryption
+          Standard.  I also understand and agree that after the
+          close of the submission period, my submission may not be
+          withdrawn from public consideration for inclusion in the
+          Federal Information Processing Standard (FIPS) for
+          Advanced Encryption Standard (AES).  I further understand
+          that I will not receive financial compensation from the
+          government for my submission.  I certify that, to the
+          best of my knowledge, I have fully disclosed all patents
+          and patent applications relating to my algorithm.  I also
+          understand that the U.S. Government may, during the
+          course of the lifetime of the AES or during the FIPS pub­
+          lic review process, modify the algorithm's specifications
+          (e.g., to protect against a newly discovered vulnerabil­
+          ity).  Should my submission be selected for inclusion in
+          the AES, I hereby agree not to place any restrictions on
+          the use of the algorithm intending it to be available on
+          a worldwide, non-exclusive, royalty-free basis.
+
+          I do hereby agree to provide the statements for any
+          patent or patent application identified to cover practice
+          of my algorithm, reference implementation or mathemati­
+          cally optimized implementations and the right to use such
+          implementations for the purposes of the AES evaluation
+          process.
+
+
+
+
+
+Chown                                                           [Page 6]
+
+ietf-tls-ciphersuite-02 AES Ciphersuites for TLS        15 November 2000
+
+
+          I understand that NIST will announce the selected algo­
+          rithm(s) and proceed to publish the draft FIPS for public
+          comment.  If my algorithm (or the derived algorithm) is
+          not selected for inclusion in the FIPS (including those
+          not selected for second round of public evaluation), I
+          understand that all rights, including use rights of the
+          reference and mathematically optimized implementations,
+          revert back to the submitter (and other owner[s] as
+          appropriate).  Additionally, should the U.S. Government
+          not select my algorithm for inclusion in the AES after a
+          period of four years from the close of the submission
+          date for candidate algorithms, all rights revert to the
+          submitter (and other owner[s] as appropriate).
+
+          [signed]
+
+
+          Title: Cryptographer
+          Dated: 10-6-98
+          Place: Brussels
+
+     The following disclaimer was signed at the start of the second
+     "round" of the AES process:
+
+          Dear Mr Foti [of NIST],
+
+          Hereby we confirm that the original patent and patent
+          application information, as provided to NIST with our
+          original submission in June 1998, has not changed.  To
+          the best of our knowledge, there are no patents or patent
+          applications covering the practice of the algorithm, ref­
+          erence implementation or the mathematically optimized
+          implementations.
+
+
+          [signed]
+          Joan Daemen, Vincent Rijmen
+
+Acknowledgements
+
+     I would like to thank the ietf-tls mailing list contributors who
+     have made helpful suggestions for this document.
+
+References
+
+     [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0" RFC-2246.
+     January, 1999.
+
+
+
+
+Chown                                                           [Page 7]
+
+ietf-tls-ciphersuite-02 AES Ciphersuites for TLS        15 November 2000
+
+
+     [AES] J. Daemen, V. Rijmen, "The Rijndael Block Cipher"
+     http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf 3rd
+     September 1999.
+
+     [SHA-1] FIPS PUB 180-1, "Secure Hash Standard," National Institute
+     of Standards and Technology, U.S. Department of Commerce, April 17,
+     1995.
+
+Author's Address
+
+     Pete Chown
+     Skygate Technology Ltd
+     8 Lombard Road
+     London
+     SW19 3TZ
+     United Kingdom
+
+     Phone: +44 20 8542 0176
+     Email: pc@skygate.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chown                                                           [Page 8]
+
diff --git a/lib/gnutls_algorithms.c b/lib/gnutls_algorithms.c
index 3b676ca625..ded9bdbe9d 100644
--- a/lib/gnutls_algorithms.c
+++ b/lib/gnutls_algorithms.c
@@ -159,6 +159,7 @@ typedef struct {
 
 #define GNUTLS_DH_anon_WITH_3DES_EDE_CBC_SHA { 0x00, 0x1B }
 #define GNUTLS_DH_anon_WITH_ARCFOUR_MD5 { 0x00, 0x18 }
+#define GNUTLS_DH_anon_WITH_RIJNDAEL_SHA { 0x00, 0x34 }
 
 #define GNUTLS_DH_DSS_WITH_3DES_EDE_CBC_SHA { 0x00, 0x0D }
 #define GNUTLS_DH_RSA_WITH_3DES_EDE_CBC_SHA { 0x00, 0x10 }
@@ -200,6 +201,7 @@ static gnutls_cipher_suite_entry cs_algorithms[] = {
 	GNUTLS_CIPHER_SUITE_ENTRY( GNUTLS_DH_RSA_WITH_RIJNDAEL_128_CBC_SHA,	GNUTLS_RIJNDAEL,  GNUTLS_KX_DH_RSA,	GNUTLS_MAC_SHA),
 	GNUTLS_CIPHER_SUITE_ENTRY( GNUTLS_DHE_DSS_WITH_RIJNDAEL_128_CBC_SHA,	GNUTLS_RIJNDAEL,  GNUTLS_KX_DHE_DSS,	GNUTLS_MAC_SHA),
 	GNUTLS_CIPHER_SUITE_ENTRY( GNUTLS_DHE_RSA_WITH_RIJNDAEL_128_CBC_SHA,	GNUTLS_RIJNDAEL,  GNUTLS_KX_DHE_RSA,	GNUTLS_MAC_SHA),
+	GNUTLS_CIPHER_SUITE_ENTRY(GNUTLS_DH_anon_WITH_RIJNDAEL_SHA,   GNUTLS_RIJNDAEL, GNUTLS_KX_ANON_DH, GNUTLS_MAC_SHA),
 	{0}
 };