doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc8429.txt b/doc/rfc/rfc8429.txt
new file mode 100644
index 0000000..d318bba
--- /dev/null
+++ b/doc/rfc/rfc8429.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          B. Kaduk
+Request for Comments: 8429                                        Akamai
+BCP: 218                                                        M. Short
+Updates: 3961, 4120                                Microsoft Corporation
+Category: Best Current Practice                             October 2018
+ISSN: 2070-1721
+
+
+            Deprecate Triple-DES (3DES) and RC4 in Kerberos
+
+Abstract
+
+   The triple-DES (3DES) and RC4 encryption types are steadily weakening
+   in cryptographic strength, and the deprecation process should begin
+   for their use in Kerberos.  Accordingly, RFC 4757 has been moved to
+   Historic status, as none of the encryption types it specifies should
+   be used, and RFC 3961 has been updated to note the deprecation of the
+   triple-DES encryption types.  RFC 4120 is likewise updated to remove
+   the recommendation to implement triple-DES encryption and checksum
+   types.
+
+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 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8429.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaduk & Short             Best Current Practice                 [Page 1]
+
+RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 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
+   (https://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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
+   3.  Affected Specifications . . . . . . . . . . . . . . . . . . .   3
+   4.  Affected Encryption Types . . . . . . . . . . . . . . . . . .   4
+   5.  RC4 Weakness  . . . . . . . . . . . . . . . . . . . . . . . .   4
+     5.1.  Statistical Biases  . . . . . . . . . . . . . . . . . . .   4
+     5.2.  Password Hash . . . . . . . . . . . . . . . . . . . . . .   5
+     5.3.  Cross-Protocol Key Reuse  . . . . . . . . . . . . . . . .   5
+     5.4.  Interoperability Concerns . . . . . . . . . . . . . . . .   6
+   6.  Triple-DES Weakness . . . . . . . . . . . . . . . . . . . . .   6
+     6.1.  Password-Based Keys . . . . . . . . . . . . . . . . . . .   7
+     6.2.  Block Size  . . . . . . . . . . . . . . . . . . . . . . .   7
+     6.3.  Interoperability Concerns . . . . . . . . . . . . . . . .   7
+   7.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   8
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
+     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaduk & Short             Best Current Practice                 [Page 2]
+
+RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018
+
+
+1.  Introduction
+
+   The triple-DES (3DES) and RC4 encryption types (enctypes) are
+   steadily weakening in cryptographic strength, and the deprecation
+   process should begin for their use in Kerberos.  Accordingly, RFC
+   4757 has been moved to Historic status, as none of the encryption
+   types it specifies should be used, and RFC 3961 has been updated to
+   note the deprecation of the triple-DES encryption types.  RFC 4120 is
+   likewise updated to remove the recommendation to implement triple-DES
+   encryption and checksum types.
+
+2.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Affected Specifications
+
+   The RC4 Kerberos encryption types (including rc4-hmac) are specified
+   in [RFC4757], which has been moved to Historic status.
+
+   The des3-cbc-sha1-kd encryption type is specified in [RFC3961].
+   Additional triple-DES encryption type codepoints are in use and in
+   the IANA registry with no formal specification, in particular
+   des3-cbc-md5 and des3-cbc-sha1.  These unspecified encryption types
+   are also deprecated by this document.
+
+   The Kerberos specification ([RFC4120]) includes recommendations for
+   which encryption and checksum types to implement; the deprecated
+   encryption and checksum types are now disrecommended to implement.
+
+   Though the RC4 and triple-DES encryption types are still in use in
+   some deployments, the above status changes are made to discourage
+   their use.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaduk & Short             Best Current Practice                 [Page 3]
+
+RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018
+
+
+4.  Affected Encryption Types
+
+   The following encryption types are deprecated.  The numbers are the
+   official identifiers; the names are only for convenience.
+
+               +----------------+--------------------------+
+               | enctype number | enctype convenience name |
+               +----------------+--------------------------+
+               |       5        |       des3-cbc-md5       |
+               |                |                          |
+               |       7        |      des3-cbc-sha1       |
+               |                |                          |
+               |       16       |     des3-cbc-sha1-kd     |
+               |                |                          |
+               |       23       |         rc4-hmac         |
+               +----------------+--------------------------+
+
+5.  RC4 Weakness
+
+   RC4's weakness as a TLS cipher due to statistical biases in the
+   keystream has been well publicized [RFC7465], and these statistical
+   biases cause concern for any consumer of the RC4 cipher.  However,
+   the RC4 Kerberos enctypes have additional flaws.  These flaws reduce
+   the security of applications that use the enctypes; the weakening
+   occurs for various reasons, including the weakness of the password
+   hashing algorithm, the reuse of key material across protocols, and
+   the lack of a salt when hashing the password.
+
+5.1.  Statistical Biases
+
+   The RC4 stream cipher is known to have statistical biases in its
+   output, which have led to practical attacks against protocols such as
+   TLS that use RC4 [RFC7465].  At least some of these attacks rely on
+   repeated encryptions of thousands of copies of the same plaintext;
+   although it is easy for malicious javascript in a website to cause
+   such traffic, it is unclear whether there is an easy way to induce a
+   kerberized application to generate such repeated encryptions.  The
+   statistical biases are most pronounced for earlier bits in the output
+   stream, which is somewhat mitigated by the use of a confounder in
+   Kerberos messages: the first 64 bits of plaintext are a random
+   confounder, and are thus of no use to an attacker who can retrieve
+   them.
+
+   Nonetheless, the statistical biases in the RC4 keystream extend well
+   past 64 bits and provide potential attack surface to an attacker.
+   Continuing to use a known weak algorithm is inviting further
+   development of attacks.
+
+
+
+
+Kaduk & Short             Best Current Practice                 [Page 4]
+
+RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018
+
+
+5.2.  Password Hash
+
+   Kerberos long-term keys can be either random (as might be used in a
+   service's keytab) or derived from a password (e.g., for individual
+   users to authenticate to a system).  The specification for a Kerberos
+   encryption type must include a "string2key" algorithm for generating
+   a raw crypto key from a string (i.e., password).  Modern encryption
+   types, such as those using the AES and Camellia block ciphers, use a
+   string2key function based on the Password-Based Key Derivation
+   Function 2 (PBKDF2) algorithm.  This algorithm involves many
+   iterations of a cryptographic hash function, designed to increase the
+   computational effort required to perform a brute-force password-
+   guessing attack.  There is an additional option to specify an
+   increased iteration count for a given principal, providing some
+   modicum of adaptability for increases in computing power.
+
+   It is also best practice, when deriving cryptographic secrets from
+   user passwords, to include as input to the hash function a value that
+   is unique to both the user and the realm of authentication; this
+   user-specific input is known as a "salt".  The default salt for
+   Kerberos principals includes both the name of the principal and the
+   name of the realm, in accordance with these best practices.  However,
+   the RC4 encryption types ignore the salt input to the string2key
+   function; the function itself is a single iteration of the MD4 hash
+   function applied to the UTF-16 encoded password, with no salt at all.
+   The MD4 hash function is very old and considered to be weak and
+   unsuitable for new cryptographic applications at this time [RFC6150].
+
+   The omission of a salt input to the hash is contrary to cryptographic
+   best practices and allows an attacker to construct a "rainbow table"
+   of password hashes; such tables are applicable to all principals in
+   all Kerberos realms.  Given the prevalence of poor-quality user-
+   selected passwords, it is likely that a rainbow table derived from a
+   database of common passwords would be able to compromise a sizable
+   number of Kerberos principals in any realm using RC4 encryption types
+   for password-derived keys.
+
+5.3.  Cross-Protocol Key Reuse
+
+   The selection of unsalted MD4 as the Kerberos string2key function was
+   deliberate, since it allowed systems to be converted in-place from
+   the old NT LAN Manager (NTLM) logon protocol [MS-NLMP] to use
+   Kerberos.
+
+   Unfortunately, there still exist systems using NTLM for
+   authentication to applications, which can result in application
+   servers possessing the NT password hash of user passwords.  Because
+   the RC4 string2key function was chosen to be compatible with the NTLM
+
+
+
+Kaduk & Short             Best Current Practice                 [Page 5]
+
+RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018
+
+
+   scheme, these application servers also possess the long-term Kerberos
+   key for those users, even though the password is unknown.  The cross-
+   protocol use of the long-term key/password hash was convenient for
+   migrating to Kerberos, but it now provides a vulnerability in
+   Kerberos as NTLM continues to be used.
+
+5.4.  Interoperability Concerns
+
+   The RC4 Kerberos encryption type remains in use in many environments
+   because of interoperability requirements.  In those sites, RC4 is the
+   strongest enctype that allows two parties to use Kerberos to
+   communicate.  In particular, the Kerberos implementations included
+   with Windows XP and Windows Server 2003 support only single-DES and
+   RC4.  Since single-DES is deprecated [RFC6649], machines running
+   those operating systems must use RC4.
+
+   Similarly, there are cross-realm deployments in which the cross-realm
+   key was initially established when one peer only supported RC4, or
+   machines only supporting RC4 need to obtain a cross-realm Ticket-
+   Granting Ticket.  It can be difficult to inventory all clients in a
+   Kerberos realm and know what implementations will be used by those
+   client principals; this leads to concerns that disabling RC4 will
+   cause breakage on machines that are unknown to the realm
+   administrators.
+
+   Fortunately, modern (i.e., supported) Kerberos implementations
+   support a secure alternative to RC4 in the form of AES.  Windows has
+   supported AES since 2007-2008 with the release of Windows Vista and
+   Server 2008.  MIT Kerberos [MITKRB5] has fully supported AES enctypes
+   since 2004 with the release of version 1.3.2, including the Kerberos
+   mechanism for the Generic Security Service Application Program
+   Interface (GSSAPI).  Heimdal [HEIMDAL] has fully supported AES since
+   2005 with the release of version 0.7.  Though there may still be
+   issues running ten-year-old unsupported software in mixed
+   environments with new software, issues of that sort seem unlikely to
+   be unique to Kerberos, and the administrators of such environments
+   are expected to be capable of devising workarounds.
+
+6.  Triple-DES Weakness
+
+   The flaws in triple-DES as used for Kerberos are not quite as damning
+   as those in RC4, but there is still ample justification for
+   deprecating its use.  As is the case for the RC4 enctypes, the
+   string2key algorithm is weak.  Additionally, the triple-DES
+   encryption types were not implemented in all Kerberos
+   implementations, and the 64-bit block size may be problematic in some
+   environments.
+
+
+
+
+Kaduk & Short             Best Current Practice                 [Page 6]
+
+RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018
+
+
+6.1.  Password-Based Keys
+
+   The n-fold-based string2key function used by the des3-cbc-sha1-kd
+   encryption type is an ad hoc construction that should not be
+   considered cryptographically sound.  It is known to not provide
+   effective mixing of the input bits and is computationally easy to
+   evaluate.  As such, it does not slow down brute-force attacks in the
+   way that the computationally demanding PBKDF2 algorithm used by more
+   modern encryption types does.  The salt is used by des3-cbc-sha1-kd's
+   string2key function, in contrast to RC4, but a brute-force dictionary
+   attack on common passwords may still be feasible.
+
+6.2.  Block Size
+
+   Triple-DES is based on the single-DES primitive, simply using
+   additional key material and nested encryption.  Therefore, it
+   inherits the 64-bit cipher block size from single-DES.  As a result,
+   an attacker who can collect approximately 2**32 blocks of ciphertext
+   has a good chance of finding a cipher block collision (the "birthday
+   attack"), which would potentially reveal a couple of blocks of
+   plaintext.
+
+   A cipher block collision would not necessarily cause the key itself
+   to be leaked, so the plaintext revealed by such a collision would be
+   limited.  For some sites, that may be an acceptable risk, but it is
+   still considered a weakness in the encryption type.
+
+6.3.  Interoperability Concerns
+
+   The triple-DES encryption types were implemented by MIT Kerberos
+   early in its development (ca. 1999) and present in the 1.2 release,
+   but they were superseded when encryption types 17 and 18 (AES) were
+   implemented (by 2003); the AES enctypes were present in the 1.3
+   release.  The Heimdal Kerberos implementation also provided a version
+   of triple-DES in 1999 (though the GSSAPI portions remained non-
+   interoperable with MIT for some time after that), gaining support for
+   AES in 2005 with its 0.7 release.  Both Heimdal and MIT krb5 have
+   supported the AES enctypes for some 12 years, and it is expected that
+   deployments that support triple-DES but not AES are quite rare.
+
+   The Kerberos implementation in Microsoft Windows has never
+   implemented the triple-DES encryption type.  Support for AES was
+   introduced with Windows Vista and Windows Server 2008; older versions
+   such as Windows XP and Windows Server 2003 only supported the RC4 and
+   single-DES encryption types.
+
+
+
+
+
+
+Kaduk & Short             Best Current Practice                 [Page 7]
+
+RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018
+
+
+   The triple-DES encryption type offers very slow encryption,
+   especially compared to the performance of AES using the hardware
+   acceleration available in modern CPUs.  There are no areas where
+   triple-DES offers advantages over other encryption types except in
+   the rare case where AES is not available.
+
+7.  Recommendations
+
+   This document hereby removes the following RECOMMENDED types from
+   [RFC4120]:
+
+      Encryption: DES3-CBC-SHA1-KD
+
+      Checksum: HMAC-SHA1-DES3-KD
+
+   Kerberos implementations and deployments SHOULD NOT implement or
+   deploy the following triple-DES encryption types: DES3-CBC-MD5(5),
+   DES3-CBC-SHA1(7), and DES3-CBC-SHA1-KD(16) (updates [RFC3961] and
+   [RFC4120]).
+
+   Kerberos implementations and deployments SHOULD NOT implement or
+   deploy the RC4 encryption type RC4-HMAC(23).
+
+   Kerberos implementations and deployments SHOULD NOT implement or
+   deploy the following checksum types: RSA-MD5(7), RSA-MD5-DES3(9),
+   HMAC-SHA1-DES3-KD(12), and HMAC-SHA1-DES3(13) (updates [RFC3961] and
+   [RFC4120]).
+
+   Kerberos GSS mechanism implementations and deployments SHOULD NOT
+   implement or deploy the following SGN_ALGs: HMAC MD5(1100) and HMAC
+   SHA1 DES3 KD(0400).  (With all its content now deprecated, [RFC4757]
+   has been made Historic by this document.)
+
+   Kerberos GSS mechanism implementations and deployments SHOULD NOT
+   implement or deploy the following SEAL_ALGs: RC4(1000) and
+   DES3KD(0200).
+
+   Per this document, [RFC4757] has been reclassified as Historic.
+
+8.  Security Considerations
+
+   This document is entirely about security considerations, namely that
+   the use of the triple-DES and RC4 Kerberos encryption types is not
+   secure, and they should not be used.
+
+
+
+
+
+
+
+Kaduk & Short             Best Current Practice                 [Page 8]
+
+RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018
+
+
+9.  IANA Considerations
+
+   IANA has updated the "Kerberos Encryption Type Numbers" registry
+   [IANA-KRB] to note that 1) encryption types 1, 2, 3, and 24 are
+   deprecated, with [RFC6649] as the reference and that 2) encryption
+   types 5, 7, 16, and 23 are deprecated, with this document as the
+   reference.
+
+   Similarly, IANA has updated the "Kerberos Checksum Type Numbers"
+   registry [IANA-KRB] to note that 1) checksum type values 1, 2, 3, 4,
+   5, 6, and 8 are deprecated, with [RFC6649] as the reference, and that
+   2) checksum type values 7, 12, and 13 are deprecated, with this
+   document as the reference.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
+              Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
+              2005, <https://www.rfc-editor.org/info/rfc3961>.
+
+   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
+              Kerberos Network Authentication Service (V5)", RFC 4120,
+              DOI 10.17487/RFC4120, July 2005,
+              <https://www.rfc-editor.org/info/rfc4120>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+10.2.  Informative References
+
+   [HEIMDAL]  Heimdal Project, "The Heimdal Kerberos 5, PKIX, CMS, GSS-
+              API, SPNEGO, NTLM, Digest-MD5 and, SASL implementation",
+              <https://www.h5l.org/>.
+
+   [IANA-KRB]
+              IANA, "Kerberos Parameters",
+              <https://www.iana.org/assignments/kerberos-parameters/>.
+
+   [MITKRB5]  MIT, "Kerberos: The Network Authentication Protocol",
+              <https://web.mit.edu/kerberos/>.
+
+
+
+Kaduk & Short             Best Current Practice                 [Page 9]
+
+RFC 8429           Deprecate 3DES and RC4 in Kerberos       October 2018
+
+
+   [MS-NLMP]  Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM)
+              Authentication Protocol", September 2017,
+              <https://msdn.microsoft.com/en-us/library/cc236621.aspx>.
+
+   [RFC4757]  Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
+              Kerberos Encryption Types Used by Microsoft Windows",
+              RFC 4757, DOI 10.17487/RFC4757, December 2006,
+              <https://www.rfc-editor.org/info/rfc4757>.
+
+   [RFC6150]  Turner, S. and L. Chen, "MD4 to Historic Status",
+              RFC 6150, DOI 10.17487/RFC6150, March 2011,
+              <https://www.rfc-editor.org/info/rfc6150>.
+
+   [RFC6649]  Hornquist Astrand, L. and T. Yu, "Deprecate DES, RC4-HMAC-
+              EXP, and Other Weak Cryptographic Algorithms in Kerberos",
+              BCP 179, RFC 6649, DOI 10.17487/RFC6649, July 2012,
+              <https://www.rfc-editor.org/info/rfc6649>.
+
+   [RFC7465]  Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
+              DOI 10.17487/RFC7465, February 2015,
+              <https://www.rfc-editor.org/info/rfc7465>.
+
+Acknowledgements
+
+   Many people have contributed to the understanding of the weaknesses
+   of these encryption types over the years, and they cannot all be
+   named here.
+
+Authors' Addresses
+
+   Benjamin Kaduk
+   Akamai Technologies
+
+   Email: kaduk@mit.edu
+
+
+   Michiko Short
+   Microsoft Corporation
+
+   Email: michikos@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+Kaduk & Short             Best Current Practice                [Page 10]
+