GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6649

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6649.txt · Last modified: 2012/07/03 04:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki