draft-ietf-krb-wg-des-die-die-die-01.txt   draft-ietf-krb-wg-des-die-die-die-02.txt 
Network Working Group L. Hornquist Astrand Network Working Group L. Hornquist Astrand
Internet-Draft Apple, Inc Internet-Draft Apple, Inc
Updates: 1510, 1964, 4120, 4121 T. Yu Updates: 1510, 1964, 4120, 4121, 4757 T. Yu
(if approved) MIT Kerberos Consortium (if approved) MIT Kerberos Consortium
Intended status: Standards Track February 8, 2012 Intended status: Standards Track February 9, 2012
Expires: August 11, 2012 Expires: August 12, 2012
Deprecate DES support for Kerberos Deprecate DES support for Kerberos
draft-ietf-krb-wg-des-die-die-die-01 draft-ietf-krb-wg-des-die-die-die-02
Abstract Abstract
The Kerberos 5 network authentication protocol, originally specified The Kerberos 5 network authentication protocol, originally specified
in RFC1510, can use the Data Encryption Standard (DES) for in RFC1510, can use the Data Encryption Standard (DES) for
encryption. Almost 30 years after first publishing DES, the National encryption. Almost 30 years after first publishing DES, the National
Institute of Standards and Technology (NIST) finally withdrew the Institute of Standards and Technology (NIST) finally withdrew the
standard in 2005, reflecting a long-established consensus that DES is standard in 2005, reflecting a long-established consensus that DES is
insufficiently secure. By 2008, commercial hardware costing less insufficiently secure. By 2008, commercial hardware costing less
than USD 15,000 could break DES keys in less than a day on average. 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 DES is long past its sell-by date. Accordingly, this document
updates RFC1964, RFC4120, and RFC4121 to deprecate the use of DES in updates RFC1964, RFC4120, and RFC4121 to deprecate the use of DES in
Kerberos. Because RFC1510 (obsoleted by RFC4120) supports only DES, Kerberos. Because RFC1510 (obsoleted by RFC4120) supports only DES,
this document also reclassifies RFC1510 as Historic. this document reclassifies RFC1510 as Historic. This document also
deprecates the weak "export strength" RC4 enctype of RFC4757.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2012. This Internet-Draft will expire on August 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 30
2. Introduction 2. Introduction
The original specification of the Kerberos 5 network authentication The original specification of the Kerberos 5 network authentication
protocol [RFC1510] supports only the Data Encryption Standard (DES) protocol [RFC1510] supports only the Data Encryption Standard (DES)
for encryption. For many years, the cryptographic community has for encryption. For many years, the cryptographic community has
regarded DES as providing inadequate security. Accordingly, this regarded DES as providing inadequate security. Accordingly, this
document reclassifies [RFC1510] (obsoleted by [RFC4120]) as Historic, document reclassifies [RFC1510] (obsoleted by [RFC4120]) as Historic,
and updates current Kerberos-related specifications [RFC1964], and updates current Kerberos-related specifications [RFC1964],
[RFC4120], and [RFC4121] to deprecate the use of DES in Kerberos. [RFC4120], and [RFC4121] to deprecate the use of DES in Kerberos.
This document also deprecates the weak "export strength" RC4 enctype
of [RFC4757].
3. Affected specifications 3. Affected specifications
The original IETF specification of Kerberos 5 [RFC1510] only supports The original IETF specification of Kerberos 5 [RFC1510] only supports
DES for encryption. [RFC4120] obsoletes [RFC1510] and updates the DES for encryption. [RFC4120] obsoletes [RFC1510] and updates the
Kerberos specification to include additional cryptographic Kerberos specification to include additional cryptographic
algorithms, but still permits the use of DES. 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 The specification of the Kerberos Generic Security Services
Application Programming Interface (GSS-API) mechanism [RFC1964] and Application Programming Interface (GSS-API) mechanism [RFC1964] and
its updated version [RFC4121] define checksum and encryption its updated version [RFC4121] define checksum and encryption
mechanisms based on DES. With the existence of newer encryption mechanisms based on DES. With the existence of newer encryption
types for Kerberos GSS-API defined in [RFC4121], Microsoft's ARCFOUR- types for Kerberos GSS-API defined in [RFC4121], Microsoft's RC4-HMAC
HMAC based GSS-API mechanism, and MIT's DES3, there is no need to based GSS-API mechanism, and MIT's DES3, there is no need to support
support the old DES based integrity (SGN) and confidentiality (SEAL) the old DES based integrity (SGN) and confidentiality (SEAL) types.
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 enctype.)
4. DES insecurity 4. DES insecurity
The insecurity of DES has been evident for many years. The National The insecurity of DES has been evident for many years. The National
Institute of Standards and Technology (NIST) officially withdrew DES Institute of Standards and Technology (NIST) officially withdrew DES
in 2005 [DES-Withdrawal], and also announced a transition period that in 2005 [DES-Withdrawal], and also announced a transition period that
ended on May 19, 2007 [DES-Transition-Plan]. The IETF has also ended on May 19, 2007 [DES-Transition-Plan]. The IETF has also
published its position in [RFC4772], in which the recommendation published its position in [RFC4772], in which the recommendation
summary is very clear: "don't use DES". summary is very clear: "don't use DES".
skipping to change at page 3, line 28 skipping to change at page 3, line 37
use of DES in Kerberos. use of DES in Kerberos.
5. Recommendations 5. Recommendations
This document hereby removes the following RECOMMENDED types from This document hereby removes the following RECOMMENDED types from
[RFC4120]: [RFC4120]:
Encryption: DES-CBC-MD5(3) Encryption: DES-CBC-MD5(3)
Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC3961]). Checksums: DES-MD5 (8, named RSA-MD5-DES in [RFC3961]).
Kerberos implementations and deployments SHOULD NOT implement the Kerberos implementations and deployments SHOULD NOT implement the
single DES encryption types: DES-CBC-CRC(1), DES-CBC-MD4(2), DES-CBC- following single DES encryption types: DES-CBC-CRC(1), DES-CBC-
MD5(3). MD4(2), DES-CBC-MD5(3) (updates [RFC4120]).
Kerberos implementations and deployments SHOULD NOT implement the Kerberos implementations and deployments SHOULD NOT implement the
checksum types: CRC32(1), RSA-MD4(2), RSA-MD4-DES(3), DES-MAC(4), following "export strength" RC4 encryption type: RC4-HMAC-EXP(24)
DES-MAC-K(5), RSA-MD4-MAC-K(6), RSA-MD5-DES(8). (updates [RFC4757]).
Kerberos implementations and deployments SHOULD NOT implement 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 It is possible to safely use the RSA-MD5(7) checksum type, but only
with additional protection, such as the protection that an encrypted with additional protection, such as the protection that an encrypted
Authenticator provides. Implementations MAY use RSA-MD5 inside an Authenticator provides. Implementations MAY use RSA-MD5 inside an
encrypted Authenticator for backward compatibility with systems that encrypted Authenticator for backward compatibility with systems that
do not support newer checksum types. One example is that some legacy do not support newer checksum types (updates [RFC4120]). One example
systems only support ARCFOUR-HMAC-MD5 for encryption when DES is not is that some legacy systems only support RC4-HMAC(23) [RFC4757] for
available; these systems use RSA-MD5 checksums inside Authenticators encryption when DES is not available; these systems use RSA-MD5
encrypted with ARCFOUR-HMAC-MD5. checksums inside Authenticators encrypted with RC4-HMAC.
Kerberos GSS mechanism implementations and deployments SHOULD NOT Kerberos GSS mechanism implementations and deployments SHOULD NOT
implement the SGN ALG: DES MAC MD5(0000), MD2.5(0100), DES MAC(0200) implement the following SGN ALG: DES MAC MD5(0000), MD2.5(0100), DES
(updates [RFC1964]). MAC(0200) (updates [RFC1964]).
Kerberos GSS mechanism implementations and deployments SHOULD NOT Kerberos GSS mechanism implementations and deployments SHOULD NOT
implement the SEAL ALG: DES(0000) (updates [RFC1964]). implement the following SEAL ALG: DES(0000) (updates [RFC1964]).
The effect of the two last sentences is that this document deprecates The effect of the two last sentences is that this document deprecates
section 1.2 in [RFC1964]. section 1.2 in [RFC1964].
This document hereby reclassifies [RFC1510] as Historic. This document hereby reclassifies [RFC1510] as Historic.
6. Acknowledgements 6. Acknowledgements
Jeffrey Hutzelman, Simon Josefsson, Mattias Amnefelt, Leif Johansson, Mattias Amnefelt, Ran Atkinson, Henry Hotz, Jeffrey Hutzelman, Leif
and Ran Atkinson have read the document and provided suggestions for Johansson, and Simon Josefsson have read the document and provided
improvements. Sam Hartman proposed moving [RFC1510] to Historic. suggestions for improvements. Sam Hartman proposed moving [RFC1510]
to Historic.
7. Security Considerations 7. Security Considerations
Removing support for single DES improves security, because DES is Removing support for single DES improves security, because DES is
considered to be insecure. considered to be insecure.
Kerberos defines some encryption types that are either underspecified Kerberos defines some encryption types that are either underspecified
or that only have number assignments but no specifications. or that only have number assignments but no specifications.
Implementations should make sure that they only implement and enable Implementations should make sure that they only implement and enable
secure encryption types. secure encryption types.
RC4, used in ARCFOUR-HMAC, is considered weak; however, the use in RC4, used in RC4-HMAC, is considered weak; however, the use in
Kerberos is vetted and considered secure for now. The main reason to Kerberos is vetted and considered secure for now. The main reason to
not actively discourage the use of ARCFOUR-HMAC is that it is the not actively discourage the use of RC4-HMAC is that it is the only
only encryption type that interoperates with older versions of encryption type that interoperates with older versions of Microsoft
Microsoft Windows once DES is removed. Windows once DES and RC4-HMAC-EXP are removed.
8. IANA Considerations 8. IANA Considerations
There are no IANA Considerations for this document. There are no IANA Considerations for this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996. RFC 1964, June 1996.
[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, March 1997. 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 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, Interface (GSS-API) Mechanism: Version 2", RFC 4121,
July 2005. July 2005.
[RFC4757] Jaganathan, K., Zhu, L., and J. Brezak, "The RC4-HMAC
Kerberos Encryption Types Used by Microsoft Windows",
RFC 4757, December 2006.
9.2. Informative References 9.2. Informative References
[Break-DES] [Break-DES]
Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., Rupp, A., Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., Rupp, A.,
and M. Schimmler, "How to break DES for EUR 8,980 - and M. Schimmler, "How to break DES for EUR 8,980 -
SHARCS'06 - Special-purpose Hardware for Attacking SHARCS'06 - Special-purpose Hardware for Attacking
Cryptographic Systems", April 2006, <http:// Cryptographic Systems", April 2006, <http://
www.copacobana.org/paper/copacobana_SHARCS2006.pdf>. www.copacobana.org/paper/copacobana_SHARCS2006.pdf>.
[DES-1day] [DES-1day]
skipping to change at page 5, line 47 skipping to change at page 6, line 19
www.gpo.gov/fdsys/pkg/FR-2005-05-19/pdf/05-9945.pdf>. www.gpo.gov/fdsys/pkg/FR-2005-05-19/pdf/05-9945.pdf>.
[DES-crack] [DES-crack]
Scott, T., "DES Brute Force Cracking Efforts 1977 to Scott, T., "DES Brute Force Cracking Efforts 1977 to
2010", 2010, <http://www.tjscott.net/security.extras/ 2010", 2010, <http://www.tjscott.net/security.extras/
des.crack.efforts.pdf>. des.crack.efforts.pdf>.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993. Authentication Service (V5)", RFC 1510, September 1993.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[RFC4772] Kelly, S., "Security Implications of Using the Data [RFC4772] Kelly, S., "Security Implications of Using the Data
Encryption Standard (DES)", RFC 4772, December 2006. Encryption Standard (DES)", RFC 4772, December 2006.
Authors' Addresses Authors' Addresses
Love Hornquist Astrand Love Hornquist Astrand
Apple, Inc Apple, Inc
Cupertino Cupertino
USA USA
 End of changes. 19 change blocks. 
32 lines changed or deleted 52 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/