rfc8429v1.txt   rfc8429.txt 
Internet Engineering Task Force (IETF) B. Kaduk Internet Engineering Task Force (IETF) B. Kaduk
Request for Comments: 8429 Akamai Request for Comments: 8429 Akamai
BCP: 218 M. Short BCP: 218 M. Short
Updates: 3961, 4120 Microsoft Corporation Updates: 3961, 4120 Microsoft Corporation
Category: Best Current Practice July 2018 Category: Best Current Practice September 2018
ISSN: 2070-1721 ISSN: 2070-1721
Deprecate Triple DES (3DES) and RC4 in Kerberos Deprecate Triple-DES (3DES) and RC4 in Kerberos
Abstract Abstract
The Triple DES (3DES) and RC4 encryption types are steadily weakening The triple-DES (3DES) and RC4 encryption types are steadily weakening
in cryptographic strength, and the deprecation process should begin in cryptographic strength, and the deprecation process should begin
for their use in Kerberos. Accordingly, RFC 4757 has been moved to for their use in Kerberos. Accordingly, RFC 4757 has been moved to
Historic status, as none of the encryption types it specifies should 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 be used, and RFC 3961 has been updated to note the deprecation of the
triple-DES encryption types. 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 Status of This Memo
This memo documents an Internet Best Current Practice. This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841. BCPs is available in Section 2 of RFC 7841.
skipping to change at page 2, line 9 skipping to change at page 2, line 11
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Affected Specifications . . . . . . . . . . . . . . . . . . . 2 3. Affected Specifications . . . . . . . . . . . . . . . . . . . 3
4. Affected Encryption Types . . . . . . . . . . . . . . . . . . 3 4. Affected Encryption Types . . . . . . . . . . . . . . . . . . 3
5. RC4 Weakness . . . . . . . . . . . . . . . . . . . . . . . . 3 5. RC4 Weakness . . . . . . . . . . . . . . . . . . . . . . . . 3
5.1. Statistical Biases . . . . . . . . . . . . . . . . . . . 3 5.1. Statistical Biases . . . . . . . . . . . . . . . . . . . 4
5.2. Password Hash . . . . . . . . . . . . . . . . . . . . . . 4 5.2. Password Hash . . . . . . . . . . . . . . . . . . . . . . 4
5.3. Cross-Protocol Key Reuse . . . . . . . . . . . . . . . . 4 5.3. Cross-Protocol Key Reuse . . . . . . . . . . . . . . . . 5
5.4. Interoperability Concerns . . . . . . . . . . . . . . . . 5 5.4. Interoperability Concerns . . . . . . . . . . . . . . . . 5
6. 3DES Weakness . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Triple-DES Weakness . . . . . . . . . . . . . . . . . . . . . 6
6.1. Password-Based Keys . . . . . . . . . . . . . . . . . . . 6 6.1. Password-Based Keys . . . . . . . . . . . . . . . . . . . 6
6.2. Block Size . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Block Size . . . . . . . . . . . . . . . . . . . . . . . 6
6.3. Interoperability . . . . . . . . . . . . . . . . . . . . 6 6.3. Interoperability Concerns . . . . . . . . . . . . . . . . 7
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Triple DES (3DES) and RC4 encryption types are steadily weakening The triple-DES (3DES) and RC4 encryption types (enctypes) are
in cryptographic strength, and the deprecation process should begin steadily weakening in cryptographic strength, and the deprecation
for their use in Kerberos. Accordingly, RFC 4757 has been moved to process should begin for their use in Kerberos. Accordingly, RFC
Historic status, as none of the encryption types it specifies should 4757 has been moved to Historic status, as none of the encryption
be used, and RFC 3961 has been updated to note the deprecation of the types it specifies should be used, and RFC 3961 has been updated to
triple-DES encryption types. 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 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Affected Specifications 3. Affected Specifications
The RC4 Kerberos encryption types are specified in [RFC4757], which The RC4 Kerberos encryption types (including rc4-hmac) are specified
has been moved to Historic. in [RFC4757], which has been moved to Historic.
The des3-cbc-sha1-kd encryption type is specified in [RFC3961]. The des3-cbc-sha1-kd encryption type is specified in [RFC3961].
Additional 3DES encryption types are in use with no formal Additional triple-DES encryption type codepoints are in use and in
specification, such as des3-cbc-md5 and des3-cbc-sha1. These the IANA registry with no formal specification, in particular des3-
unspecified encryption types are also deprecated by this document. cbc-md5 and des3-cbc-sha1. These unspecified encryption types are
also deprecated by this document.
Though the RC4 and 3DES encryption types are still in use in some The Kerberos specification ([RFC4120]) includes recommendations for
deployments, the above status changes are made to discourage their which encryption and checksum types to implement; the deprecated
use. 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.
4. Affected Encryption Types 4. Affected Encryption Types
The following encryption types are deprecated. The numbers are the The following encryption types are deprecated. The numbers are the
official identifiers; the names are only for convenience. official identifiers; the names are only for convenience.
+----------------+--------------------------+ +----------------+--------------------------+
| enctype number | enctype convenience name | | enctype number | enctype convenience name |
+----------------+--------------------------+ +----------------+--------------------------+
| 5 | des3-cbc-md5 | | 5 | des3-cbc-md5 |
skipping to change at page 3, line 33 skipping to change at page 3, line 46
| 16 | des3-cbc-sha1-kd | | 16 | des3-cbc-sha1-kd |
| | | | | |
| 23 | rc4-hmac | | 23 | rc4-hmac |
+----------------+--------------------------+ +----------------+--------------------------+
5. RC4 Weakness 5. RC4 Weakness
RC4's weakness as a TLS cipher due to statistical biases in the RC4's weakness as a TLS cipher due to statistical biases in the
keystream has been well publicized [RFC7465], and these statistical keystream has been well publicized [RFC7465], and these statistical
biases cause concern for any consumer of the RC4 cipher. However, biases cause concern for any consumer of the RC4 cipher. However,
the RC4 Kerberos enctypes have additional flaws that reduce the the RC4 Kerberos enctypes have additional flaws. These flaws reduce
security of applications using them, including the weakness of the the security of applications that use the enctypes in various ways
password hashing algorithm, the reuse of key material across including the weakness of the password hashing algorithm, the reuse
protocols, and the lack of a salt when hashing the password. of key material across protocols, and the lack of a salt when hashing
the password.
5.1. Statistical Biases 5.1. Statistical Biases
The RC4 stream cipher is known to have statistical biases in its The RC4 stream cipher is known to have statistical biases in its
output, which have led to practical attacks against protocols such as output, which have led to practical attacks against protocols such as
TLS that use RC4 [RFC7465]. At least some of these attacks rely on TLS that use RC4 [RFC7465]. At least some of these attacks rely on
repeated encryptions of thousands of copies of the same plaintext; repeated encryptions of thousands of copies of the same plaintext;
although it is easy for malicious javascript in a website to cause 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 such traffic, it is unclear whether there is an easy way to induce a
kerberized application to generate such repeated encryptions. The kerberized application to generate such repeated encryptions. The
skipping to change at page 4, line 39 skipping to change at page 5, line 6
user-specific input is known as a "salt". The default salt for user-specific input is known as a "salt". The default salt for
Kerberos principals includes both the name of the principal and the Kerberos principals includes both the name of the principal and the
name of the realm, in accordance with these best practices. However, name of the realm, in accordance with these best practices. However,
the RC4 encryption types ignore the salt input to the string2key the RC4 encryption types ignore the salt input to the string2key
function; the function itself is a single iteration of the MD4 hash 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. 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 The MD4 hash function is very old and considered to be weak and
unsuitable for new cryptographic applications at this time [RFC6150]. unsuitable for new cryptographic applications at this time [RFC6150].
The omission of a salt input to the hash is contrary to cryptographic The omission of a salt input to the hash is contrary to cryptographic
best practices and allows an attacker to construct a "rainbow table" best practices and allows an attacker to construct construct a
of password hashes that are applicable to all principals in all "rainbow table" of password hashes; such tables are applicable to all
Kerberos realms. Given the prevalence of poor-quality user-selected principals in all Kerberos realms. Given the prevalence of poor-
passwords, it is likely that a rainbow table derived from a database quality user-selected passwords, it is likely that a rainbow table
of common passwords would be able to compromise a sizable number of derived from a database of common passwords would be able to
Kerberos principals in any realm using RC4 encryption types for compromise a sizable number of Kerberos principals in any realm using
password-derived keys. RC4 encryption types for password-derived keys.
5.3. Cross-Protocol Key Reuse 5.3. Cross-Protocol Key Reuse
The selection of unsalted MD4 as the Kerberos string2key function was The selection of unsalted MD4 as the Kerberos string2key function was
deliberate, since it allowed systems to be converted in-place from deliberate, since it allowed systems to be converted in-place from
the old NT LAN Manager (NTLM) logon protocol [MS-NLMP] to use the old NT LAN Manager (NTLM) logon protocol [MS-NLMP] to use
Kerberos. Kerberos.
Unfortunately, there still exist systems using NTLM for Unfortunately, there still exist systems using NTLM for
authentication to applications, which can result in application authentication to applications, which can result in application
servers possessing the NT password hash of user passwords. Because servers possessing the NT password hash of user passwords. Because
the RC4 string2key was chosen to be compatible with the NTLM scheme, the RC4 string2key function was chosen to be compatible with the NTLM
these application servers also possess the long-term Kerberos key for scheme, these application servers also possess the long-term Kerberos
those users, even though the password is unknown. The cross-protocol key for those users, even though the password is unknown. The cross-
use of the long-term key/password hash was convenient for migrating protocol use of the long-term key/password hash was convenient for
to Kerberos, but it now provides a vulnerability in Kerberos as NTLM migrating to Kerberos, but it now provides a vulnerability in
continues to be used. Kerberos as NTLM continues to be used.
5.4. Interoperability Concerns 5.4. Interoperability Concerns
The RC4 Kerberos encryption type remains in use in many environments The RC4 Kerberos encryption type remains in use in many environments
because of interoperability requirements. In those sites, RC4 is the because of interoperability requirements. In those sites, RC4 is the
strongest enctype that allows two parties to use Kerberos to strongest enctype that allows two parties to use Kerberos to
communicate. In particular, the Kerberos implementations included communicate. In particular, the Kerberos implementations included
with Windows XP and Windows Server 2003 support only single-DES and with Windows XP and Windows Server 2003 support only single-DES and
RC4. Since single-DES is deprecated [RFC6649], machines running RC4. Since single-DES is deprecated [RFC6649], machines running
those operating systems must use RC4. those operating systems must use RC4.
skipping to change at page 5, line 37 skipping to change at page 6, line 4
machines only supporting RC4 need to obtain a cross-realm Ticket- machines only supporting RC4 need to obtain a cross-realm Ticket-
Granting Ticket. It can be difficult to inventory all clients in a Granting Ticket. It can be difficult to inventory all clients in a
Kerberos realm and know what implementations will be used by those Kerberos realm and know what implementations will be used by those
client principals; this leads to concerns that disabling RC4 will client principals; this leads to concerns that disabling RC4 will
cause breakage on machines that are unknown to the realm cause breakage on machines that are unknown to the realm
administrators. administrators.
Fortunately, modern (i.e., supported) Kerberos implementations Fortunately, modern (i.e., supported) Kerberos implementations
support a secure alternative to RC4 in the form of AES. Windows has 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 supported AES since 2007-2008 with the release of Windows Vista and
Server 2008. MIT Kerberos [MITKRB5] has fully supported AES since Server 2008. MIT Kerberos [MITKRB5] has fully supported AES enctypes
2004 with the release of version 1.3.2, including the Generic since 2004 with the release of version 1.3.2, including the Kerberos
Security Service Application Program Interface (GSSAPI) mechanism. mechanism for the Generic Security Service Application Program
Heimdal [HEIMDAL] has fully supported AES since 2005 with the release Interface (GSSAPI). Heimdal [HEIMDAL] has fully supported AES since
of version 0.7. Though there may still be issues running ten-year- 2005 with the release of version 0.7. Though there may still be
old unsupported software in mixed environments with new software, issues running ten-year-old unsupported software in mixed
issues of that sort seem unlikely to be unique to Kerberos, and the environments with new software, issues of that sort seem unlikely to
administrators of such environments are expected to be capable of be unique to Kerberos, and the administrators of such environments
devising workarounds. are expected to be capable of devising workarounds.
6. 3DES Weakness 6. Triple-DES Weakness
The flaws in triple-DES as used for Kerberos are not quite as damning 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 as those in RC4, but there is still ample justification for
deprecating its use. As is the case for the RC4 enctypes, the deprecating its use. As is the case for the RC4 enctypes, the
string2key algorithm is weak. Additionally, the 3DES encryption string2key algorithm is weak. Additionally, the triple-DES
types were not implemented in all Kerberos implementations, and the encryption types were not implemented in all Kerberos
64-bit block size may be problematic in some environments. implementations, and the 64-bit block size may be problematic in some
environments.
6.1. Password-Based Keys 6.1. Password-Based Keys
The n-fold-based string2key function used by the des3-cbc-sha1-kd The n-fold-based string2key function used by the des3-cbc-sha1-kd
encryption type is an ad hoc construction that should not be encryption type is an ad hoc construction that should not be
considered cryptographically sound. It is known to not provide considered cryptographically sound. It is known to not provide
effective mixing of the input bits and is computationally easy to effective mixing of the input bits and is computationally easy to
evaluate. As such, it does not slow down brute-force attacks in the evaluate. As such, it does not slow down brute-force attacks in the
way that the computationally demanding PBKDF2 algorithm used by more way that the computationally demanding PBKDF2 algorithm used by more
modern encryption types does. The salt is used by des3-cbc-sha1-kd's modern encryption types does. The salt is used by des3-cbc-sha1-kd's
string2key, in contrast to RC4, but a brute-force dictionary attack string2key function, in contrast to RC4, but a brute-force dictionary
on common passwords may still be feasible. attack on common passwords may still be feasible.
6.2. Block Size 6.2. Block Size
Triple-DES is based on the single-DES primitive, simply using Triple-DES is based on the single-DES primitive, simply using
additional key material and nested encryption. Therefore, it additional key material and nested encryption. Therefore, it
inherits the 64-bit cipher block size from single-DES. As a result, inherits the 64-bit cipher block size from single-DES. As a result,
an attacker who can collect approximately 2**32 blocks of ciphertext an attacker who can collect approximately 2**32 blocks of ciphertext
has a good chance of finding a cipher block collision (the "birthday has a good chance of finding a cipher block collision (the "birthday
attack"), which would potentially reveal a couple of blocks of attack"), which would potentially reveal a couple of blocks of
plaintext. plaintext.
A cipher block collision would not necessarily cause the key itself A cipher block collision would not necessarily cause the key itself
to be leaked, so the plaintext revealed by such a collision would be 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 limited. For some sites, that may be an acceptable risk, but it is
still considered a weakness in the encryption type. still considered a weakness in the encryption type.
6.3. Interoperability 6.3. Interoperability Concerns
The triple-DES encryption types were implemented by MIT Kerberos The triple-DES encryption types were implemented by MIT Kerberos
early in its development (ca. 1999) and present in the 1.2 release, 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 but they were superseded when encryption types 17 and 18 (AES) were
implemented (by 2003) and were present in the 1.3 release. The implemented (by 2003); the AES enctypes were present in the 1.3
Heimdal Kerberos implementation also provided a version of 3DES in release. The Heimdal Kerberos implementation also provided a version
1999 (though the GSSAPI portions remained non-interoperable with MIT of triple-DES in 1999 (though the GSSAPI portions remained non-
for some time after that), gaining support for AES in 2005 with its interoperable with MIT for some time after that), gaining support for
0.7 release. Both Heimdal and MIT krb5 have supported the AES AES in 2005 with its 0.7 release. Both Heimdal and MIT krb5 have
enctypes for some 12 years, and it is expected that deployments that supported the AES enctypes for some 12 years, and it is expected that
support 3DES but not AES are quite rare. deployments that support triple-DES but not AES are quite rare.
The Kerberos implementation in Microsoft Windows has never The Kerberos implementation in Microsoft Windows has never
implemented the 3DES encryption type. Support for AES was introduced implemented the triple-DES encryption type. Support for AES was
with Windows Vista and Windows Server 2008; older versions such as introduced with Windows Vista and Windows Server 2008; older versions
Windows XP and Windows Server 2003 only supported the RC4 encryption such as Windows XP and Windows Server 2003 only supported the RC4 and
types. single-DES encryption types.
The 3DES encryption type offers very slow encryption, especially The triple-DES encryption type offers very slow encryption,
compared to the performance of AES using the hardware acceleration especially compared to the performance of AES using the hardware
available in modern CPUs. There are no areas where 3DES offers acceleration available in modern CPUs. There are no areas where
advantages over other encryption types except in the rare case where triple-DES offers advantages over other encryption types except in
AES is not available. the rare case where AES is not available.
7. Recommendations 7. Recommendations
This document hereby removes the following RECOMMENDED types from This document hereby removes the following RECOMMENDED types from
[RFC4120]: [RFC4120]:
Encryption: DES3-CBC-SHA1-KD Encryption: DES3-CBC-SHA1-KD
Checksum: HMAC-SHA1-DES3-KD Checksum: HMAC-SHA1-DES3-KD
skipping to change at page 7, line 35 skipping to change at page 8, line 7
Kerberos implementations and deployments SHOULD NOT implement or Kerberos implementations and deployments SHOULD NOT implement or
deploy the RC4 encryption type RC4-HMAC(23). deploy the RC4 encryption type RC4-HMAC(23).
Kerberos implementations and deployments SHOULD NOT implement or Kerberos implementations and deployments SHOULD NOT implement or
deploy the following checksum types: RSA-MD5(7), RSA-MD5-DES3(9), 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 HMAC-SHA1-DES3-KD(12), and HMAC-SHA1-DES3(13) (updates [RFC3961] and
[RFC4120]). [RFC4120]).
Kerberos GSS mechanism implementations and deployments SHOULD NOT Kerberos GSS mechanism implementations and deployments SHOULD NOT
implement or deploy the following SGN_ALGs: HMAC MD5(1100) and HMAC implement or deploy the following SGN_ALGs: HMAC MD5(1100) and HMAC
SHA1 DES3 KD (updates [RFC4757]). SHA1 DES3 KD. (With all its content now deprecated, [RFC4757] has
been made Historic by this document.)
Kerberos GSS mechanism implementations and deployments SHOULD NOT Kerberos GSS mechanism implementations and deployments SHOULD NOT
implement or deploy the following SEAL_ALGs: RC4(1000) and implement or deploy the following SEAL_ALGs: RC4(1000) and
DES3KD(0400). DES3KD(0400).
Per this document, [RFC4757] has been reclassified as Historic. Per this document, [RFC4757] has been reclassified as Historic.
8. Security Considerations 8. Security Considerations
This document is entirely about security considerations, namely that This document is entirely about security considerations, namely that
the use of the 3DES and RC4 Kerberos encryption types is not secure, the use of the triple-DES and RC4 Kerberos encryption types is not
and they should not be used. secure, and they should not be used.
9. IANA Considerations 9. IANA Considerations
IANA has updated the "Kerberos Encryption Type Numbers" registry IANA has updated the "Kerberos Encryption Type Numbers" registry
[IANA-KRB] to note that 1) encryption types 1, 2, 3, and 24 are [IANA-KRB] to note that 1) encryption types 1, 2, 3, and 24 are
deprecated, with [RFC6649] as the reference and that 2) encryption deprecated, with [RFC6649] as the reference and that 2) encryption
types 5, 7, 16, and 23 are deprecated, with this document as the types 5, 7, 16, and 23 are deprecated, with this document as the
reference. reference.
Similarly, IANA has updated the "Kerberos Checksum Type Numbers" Similarly, IANA has updated the "Kerberos Checksum Type Numbers"
registry [IANA-KRB] to note that 1) checksum types 1, 2, 3, 4, 5, 6, registry [IANA-KRB] to note that 1) checksum type values 1, 2, 3, 4,
and 8 are deprecated, with [RFC6649] as the reference, and that 2) 5, 6, and 8 are deprecated, with [RFC6649] as the reference, and that
checksum types 7, 12, and 13 are deprecated, with this document as 2) checksum type values 7, 12, and 13 are deprecated, with this
the reference. document as the reference.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 8, line 52 skipping to change at page 9, line 20
[HEIMDAL] Heimdal Project, "The Heimdal Kerberos 5, PKIX, CMS, GSS- [HEIMDAL] Heimdal Project, "The Heimdal Kerberos 5, PKIX, CMS, GSS-
API, SPNEGO, NTLM, Digest-MD5 and, SASL implementation", API, SPNEGO, NTLM, Digest-MD5 and, SASL implementation",
<https://www.h5l.org/>. <https://www.h5l.org/>.
[IANA-KRB] [IANA-KRB]
IANA, "Kerberos Parameters", IANA, "Kerberos Parameters",
<https://www.iana.org/assignments/kerberos-parameters/>. <https://www.iana.org/assignments/kerberos-parameters/>.
[MITKRB5] MIT, "Kerberos: The Network Authentication Protocol", [MITKRB5] MIT, "Kerberos: The Network Authentication Protocol",
<web.mit.edu/kerberos/>. <https://web.mit.edu/kerberos/>.
[MS-NLMP] Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM) [MS-NLMP] Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM)
Authentication Protocol", May 2014, Authentication Protocol", September 2017,
<https://msdn.microsoft.com/en-us/library/cc236621.aspx>. <https://msdn.microsoft.com/en-us/library/cc236621.aspx>.
[RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC [RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
Kerberos Encryption Types Used by Microsoft Windows", Kerberos Encryption Types Used by Microsoft Windows",
RFC 4757, DOI 10.17487/RFC4757, December 2006, RFC 4757, DOI 10.17487/RFC4757, December 2006,
<https://www.rfc-editor.org/info/rfc4757>. <https://www.rfc-editor.org/info/rfc4757>.
[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status",
RFC 6150, DOI 10.17487/RFC6150, March 2011, RFC 6150, DOI 10.17487/RFC6150, March 2011,
<https://www.rfc-editor.org/info/rfc6150>. <https://www.rfc-editor.org/info/rfc6150>.
 End of changes. 32 change blocks. 
84 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/