doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc3268.txt b/doc/rfc/rfc3268.txt
new file mode 100644
index 0000000..80e79db
--- /dev/null
+++ b/doc/rfc/rfc3268.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                           P. Chown
+Request for Comments: 3268                            Skygate Technology
+Category: Standards Track                                      June 2002
+
+
+  Advanced Encryption Standard (AES) Ciphersuites for Transport Layer
+                             Security (TLS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document proposes several new ciphersuites.  At present, the
+   symmetric ciphers supported by Transport Layer Security (TLS) are
+   RC2, RC4, International Data Encryption Algorithm (IDEA), Data
+   Encryption Standard (DES), and triple DES.  The protocol would be
+   enhanced by the addition of Advanced Encryption Standard (AES)
+   ciphersuites.
+
+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 that the AES process is completed there will be commercial
+      pressure to use the selected cipher.  The AES is efficient and has
+      withstood extensive cryptanalytic efforts.  The AES is therefore a
+      desirable choice.
+
+
+
+
+
+Chown                       Standards Track                     [Page 1]
+
+RFC 3268                AES Ciphersuites for TLS               June 2002
+
+
+   4. Currently the DHE ciphersuites only allow triple DES (along with
+      some "export" variants which do not use a satisfactory key
+      length).  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.
+
+Cipher Usage
+
+   The new ciphersuites proposed here are very similar to the following,
+   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
+
+   TLS_RSA_WITH_AES_256_CBC_SHA       RSA
+   TLS_DH_DSS_WITH_AES_256_CBC_SHA    DH_DSS
+   TLS_DH_RSA_WITH_AES_256_CBC_SHA    DH_RSA
+   TLS_DHE_DSS_WITH_AES_256_CBC_SHA   DHE_DSS
+   TLS_DHE_RSA_WITH_AES_256_CBC_SHA   DHE_RSA
+   TLS_DH_anon_WITH_AES_256_CBC_SHA   DH_anon
+
+
+
+
+
+Chown                       Standards Track                     [Page 2]
+
+RFC 3268                AES Ciphersuites for TLS               June 2002
+
+
+   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].
+
+   The AES supports key lengths of 128, 192 and 256 bits.  However, this
+   document only defines ciphersuites for 128- and 256-bit keys.  This
+   is to avoid unnecessary proliferation of ciphersuites.  Rijndael
+   actually allows for 192- and 256-bit block sizes as well as the 128-
+   bit blocks mandated by the AES process.  The ciphersuites defined
+   here all use 128-bit blocks.
+
+   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 };
+
+   CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x35 };
+   CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA   = { 0x00, 0x36 };
+   CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x37 };
+   CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA  = { 0x00, 0x38 };
+   CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA  = { 0x00, 0x39 };
+   CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA  = { 0x00, 0x3A };
+
+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
+      protocol as currently defined there is no significant efficiency
+      gain from reusing ephemeral keys.
+
+   2. Ephemeral keys should be destroyed securely when they are no
+      longer required.
+
+   3. The random number generator used to create ephemeral keys must not
+      reveal past output even when its internal state is compromised.
+
+
+
+
+
+
+Chown                       Standards Track                     [Page 3]
+
+RFC 3268                AES Ciphersuites for TLS               June 2002
+
+
+   [TLS] describes the anonymous Diffie-Hellman (ADH) ciphersuites as
+   deprecated.  The ADH ciphersuites defined here are not deprecated.
+   However, when they are 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 consequence
+      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 parties' public keys (among
+      other things).  For this reason, the MACs computed by each party
+      would be different.
+
+      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.
+
+      Recent research has identified a chosen plaintext attack which
+      applies to all ciphersuites defined in [TLS] which use CBC mode.
+      This weakness does not affect the common use of TLS on the World
+      Wide Web, but may affect the use of TLS in other applications.
+      When TLS is used in an application where this attack is possible,
+      attackers can determine the truth or otherwise of a hypothesis
+      that particular plaintext data was sent earlier in the session.
+      No key material is compromised.
+
+      It is likely that the CBC construction will be changed in a future
+      revision of the TLS protocol.
+
+Intellectual Property
+
+   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 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
+
+
+
+Chown                       Standards Track                     [Page 4]
+
+RFC 3268                AES Ciphersuites for TLS               June 2002
+
+
+   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 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 inventions 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
+      against any user of AES that have not been disclosed to NIST in
+      response to this request for information.
+
+Acknowledgements
+
+   I would like to thank the ietf-tls mailing list contributors who have
+   made helpful suggestions for this document.
+
+References
+
+   [TLS]    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+            2246, January 1999.
+
+   [AES]    National Institute of Standards and Technology,
+            "Specification for the Advanced Encryption Standard (AES)"
+            FIPS 197.  November 26, 2001.
+
+   [SHA-1]  FIPS PUB 180-1, "Secure Hash Standard," National Institute
+            of Standards and Technology, U.S. Department of Commerce,
+            April 17, 1995.
+
+
+
+
+
+Chown                       Standards Track                     [Page 5]
+
+RFC 3268                AES Ciphersuites for TLS               June 2002
+
+
+Author's Address
+
+   Pete Chown
+   Skygate Technology Ltd
+   8 Lombard Road
+   London
+   SW19 3TZ
+   United Kingdom
+
+   Phone: +44 20 8542 7856
+   EMail: pc@skygate.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chown                       Standards Track                     [Page 6]
+
+RFC 3268                AES Ciphersuites for TLS               June 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chown                       Standards Track                     [Page 7]
+