doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc6649.txt b/doc/rfc/rfc6649.txt
new file mode 100644
index 0000000..d14688a
--- /dev/null
+++ b/doc/rfc/rfc6649.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)              L. Hornquist Astrand
+Request for Comments: 6649                                   Apple, Inc.
+BCP: 179                                                           T. Yu
+Obsoletes: 1510                                  MIT Kerberos Consortium
+Updates: 1964, 4120, 4121, 4757                                July 2012
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+  Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms
+                              in Kerberos
+
+Abstract
+
+   The Kerberos 5 network authentication protocol, originally specified
+   in RFC 1510, can use the Data Encryption Standard (DES) for
+   encryption.  Almost 30 years after first publishing DES, the National
+   Institute of Standards and Technology (NIST) finally withdrew the
+   standard in 2005, reflecting a long-established consensus that DES is
+   insufficiently secure.  By 2008, commercial hardware costing less
+   than USD 15,000 could break DES keys in less than a day on average.
+   DES is long past its sell-by date.  Accordingly, this document
+   updates RFC 1964, RFC 4120, RFC 4121, and RFC 4757 to deprecate the
+   use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in
+   Kerberos.  Because RFC 1510 (obsoleted by RFC 4120) supports only
+   DES, this document recommends the reclassification of RFC 1510 as
+   Historic.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6649.
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Yu    Best Current Practice                 [Page 1]
+
+RFC 6649                Deprecate DES in Kerberos              July 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Yu    Best Current Practice                 [Page 2]
+
+RFC 6649                Deprecate DES in Kerberos              July 2012
+
+
+1.  Introduction
+
+   The original specification of the Kerberos 5 network authentication
+   protocol [RFC1510] supports only the Data Encryption Standard (DES)
+   for encryption.  For many years, the cryptographic community has
+   regarded DES as providing inadequate security, mostly because of its
+   small key size.  Accordingly, this document recommends the
+   reclassification of [RFC1510] (obsoleted by [RFC4120]) as Historic
+   and updates current Kerberos-related specifications [RFC1964],
+   [RFC4120], and [RFC4121] to deprecate the use of DES and other weak
+   cryptographic algorithms in Kerberos, including some unkeyed
+   checksums and hashes, along with the weak 56-bit "export strength"
+   RC4 variant encryption type of [RFC4757].
+
+2.  Requirements Notation
+
+   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 [RFC2119].
+
+3.  Affected Specifications
+
+   The original IETF specification of Kerberos 5 [RFC1510] only supports
+   DES for encryption.  [RFC4120] obsoletes [RFC1510] and updates the
+   Kerberos specification to include additional cryptographic
+   algorithms, but still permits the use of DES.  [RFC3961] describes
+   the Kerberos cryptographic system and includes support for DES
+   encryption types, but it does not specify requirement levels for
+   them.
+
+   The specification of the Kerberos Generic Security Services
+   Application Programming Interface (GSS-API) mechanism [RFC1964] and
+   its updated version [RFC4121] define checksum and encryption
+   mechanisms based on DES.  With the existence of newer encryption
+   types for Kerberos GSS-API defined in [RFC4121], Microsoft's
+   RC4-HMAC-based GSS-API mechanism, and MIT's DES3 (which is not
+   published as an RFC), there is no need to support the old DES-based
+   integrity (SGN) and confidentiality (SEAL) types.
+
+   [RFC4757] describes the RC4-HMAC encryption types used by Microsoft
+   Windows and allows for a 56-bit "export strength" variant.  (The
+   character constant "fortybits" used in the definition is a historical
+   reference and does not refer to the actual key size of the encryption
+   type.)
+
+
+
+
+
+
+
+Hornquist Astrand & Yu    Best Current Practice                 [Page 3]
+
+RFC 6649                Deprecate DES in Kerberos              July 2012
+
+
+4.  DES Insecurity
+
+   The insecurity of DES has been evident for many years.  Even around
+   the time of its first publication, cryptographers raised the
+   possibility that 56 bits was too small a key size for DES.  The
+   National Institute of Standards and Technology (NIST) officially
+   withdrew DES in 2005 [DES-Withdrawal], and also announced a
+   transition period that ended on May 19, 2007 [DES-Transition-Plan].
+   The IETF has also published its position in [RFC4772], in which the
+   recommendation summary is very clear: "don't use DES".
+
+   In 2006, researchers demonstrated the ability to find a DES key via
+   brute-force search in an average of less than 9 days using less than
+   EUR 10,000 worth of hardware [Break-DES].  By 2008, a company was
+   offering hardware capable of breaking a DES key in less than a day on
+   average [DES-1day] that cost less than USD 15,000 [DES-Crack].
+   Brute-force key searches of DES will only get faster and cheaper.
+   (The aforementioned company markets its device for one-click recovery
+   of lost DES keys.)  It is clear that it is well past time to retire
+   the use of DES in Kerberos.
+
+5.  Recommendations
+
+   This document hereby removes the following RECOMMENDED types from
+   [RFC4120]:
+
+      Encryption: DES-CBC-MD5(3)
+
+      Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC3961]).
+
+   Kerberos implementations and deployments SHOULD NOT implement or
+   deploy the following single DES encryption types: DES-CBC-CRC(1),
+   DES-CBC-MD4(2), DES-CBC-MD5(3) (updates [RFC4120]).
+
+   Kerberos implementations and deployments SHOULD NOT implement or
+   deploy the following "export strength" RC4 variant encryption type:
+   RC4-HMAC-EXP(24) (updates [RFC4757]).  This document does not add any
+   sort of requirement for conforming implementations to implement
+   RC4-HMAC(23).
+
+   Kerberos implementations and deployments SHOULD NOT implement or
+   deploy the following checksum types: CRC32(1), RSA-MD4(2),
+   RSA-MD4-DES(3), DES-MAC(4), DES-MAC-K(5), RSA-MD4-DES-K(6),
+   RSA-MD5-DES(8) (updates [RFC4120]).
+
+   It is possible to safely use the RSA-MD5(7) checksum type, but only
+   with additional protection, such as the protection that an encrypted
+   Authenticator provides.  Implementations MAY use RSA-MD5 inside an
+
+
+
+Hornquist Astrand & Yu    Best Current Practice                 [Page 4]
+
+RFC 6649                Deprecate DES in Kerberos              July 2012
+
+
+   encrypted Authenticator for backward compatibility with systems that
+   do not support newer checksum types (updates [RFC4120]).  One example
+   is that some legacy systems only support RC4-HMAC(23) [RFC4757] for
+   encryption when DES is not available; these systems use RSA-MD5
+   checksums inside Authenticators encrypted with RC4-HMAC.
+
+   Kerberos GSS mechanism implementations and deployments SHOULD NOT
+   implement or deploy the following SGN ALG: DES MAC MD5(0000),
+   MD2.5(0100), DES MAC(0200) (updates [RFC1964]).
+
+   Kerberos GSS mechanism implementations and deployments SHOULD NOT
+   implement or deploy the following SEAL ALG: DES(0000) (updates
+   [RFC1964]).
+
+   The effect of the two last sentences is that this document deprecates
+   Section 1.2 of [RFC1964].
+
+   This document hereby recommends the reclassification of [RFC1510] as
+   Historic.
+
+6.  Security Considerations
+
+   Removing support for single DES improves security because DES is
+   considered to be insecure.  RC4-HMAC-EXP has a similarly inadequate
+   key size, so removing support for it also improves security.
+
+   Kerberos defines some encryption types that are either underspecified
+   or that only have number assignments but no specifications.
+   Implementations should make sure that they only implement and enable
+   secure encryption types.
+
+   The security considerations of [RFC4757] continue to apply to
+   RC4-HMAC, including the known weaknesses of RC4 and MD4, and this
+   document does not change the Informational status of [RFC4757] for
+   now.  The main reason to not actively discourage the use of RC4-HMAC
+   is that it is the only encryption type that interoperates with older
+   versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed.
+   These older versions of Microsoft Windows will likely be in use until
+   at least 2015.
+
+7.  Acknowledgements
+
+   Mattias Amnefelt, Ran Atkinson, Henry Hotz, Jeffrey Hutzelman, Leif
+   Johansson, Simon Josefsson, and Martin Rex have read the document and
+   provided suggestions for improvements.  Sam Hartman proposed moving
+   [RFC1510] to Historic.  Michiko Short provided information about the
+   dates of end of support for Windows releases.
+
+
+
+
+Hornquist Astrand & Yu    Best Current Practice                 [Page 5]
+
+RFC 6649                Deprecate DES in Kerberos              July 2012
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1964]   Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+               RFC 1964, June 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3961]   Raeburn, K., "Encryption and Checksum Specifications for
+               Kerberos 5", RFC 3961, February 2005.
+
+   [RFC4120]   Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+               Kerberos Network Authentication Service (V5)", RFC 4120,
+               July 2005.
+
+   [RFC4121]   Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+               Version 5 Generic Security Service Application Program
+               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+               July 2005.
+
+   [RFC4757]   Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
+               Kerberos Encryption Types Used by Microsoft Windows",
+               RFC 4757, December 2006.
+
+8.2.  Informative References
+
+   [Break-DES] Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., Rupp, A.,
+               and M. Schimmler, "How to break DES for EUR 8,980",
+               SHARCS'06 - Special-purpose Hardware for Attacking
+               Cryptographic Systems, April 2006, <http://
+               www.copacobana.org/paper/copacobana_SHARCS2006.pdf>.
+
+   [DES-1day]  SciEngines GmbH, "Break DES in less than a single day",
+               <http://www.sciengines.com/company/news-a-events/
+               74-des-in-1-day.html>.
+
+   [DES-Crack] Scott, T., "DES Brute Force Cracking Efforts 1977 to
+               2010", 2010, <http://www.tjscott.net/security.extras/
+               des.crack.efforts.pdf>.
+
+   [DES-Transition-Plan]
+               National Institute of Standards and Technology, "DES
+               Transition Plan", May 2005, <http://csrc.nist.gov/groups/
+               STM/common_documents/DESTranPlan.pdf>.
+
+
+
+
+
+Hornquist Astrand & Yu    Best Current Practice                 [Page 6]
+
+RFC 6649                Deprecate DES in Kerberos              July 2012
+
+
+   [DES-Withdrawal]
+               National Institute of Standards and Technology,
+               "Announcing Approval of the Withdrawal of Federal
+               Information Processing Standard (FIPS) 46-3, Data
+               Encryption Standard (DES); FIPS 74, Guidelines for
+               Implementing and Using the NBS Data Encryption Standard;
+               and FIPS 81, DES Modes of Operation", Federal Register
+               Vol. 70, No. 96, Document 05-9945, 70 FR 28907-28908,
+               May 2005, <http://www.gpo.gov/fdsys/pkg/
+               FR-2005-05-19/pdf/05-9945.pdf>.
+
+   [RFC1510]   Kohl, J. and B. Neuman, "The Kerberos Network
+               Authentication Service (V5)", RFC 1510, September 1993.
+
+   [RFC4772]   Kelly, S., "Security Implications of Using the Data
+               Encryption Standard (DES)", RFC 4772, December 2006.
+
+Authors' Addresses
+
+   Love Hornquist Astrand
+   Apple, Inc.
+   Cupertino, California
+   USA
+
+   EMail: lha@apple.com
+
+
+   Tom Yu
+   MIT Kerberos Consortium
+   77 Massachusetts Ave.
+   Cambridge, Massachusetts
+   USA
+
+   EMail: tlyu@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hornquist Astrand & Yu    Best Current Practice                 [Page 7]
+