Deprecate DES support for Kerberos
draft-lha-des-die-die-die-04

Abstract

A long long time ago Data Encryption Standard (DES) was standardized. Some 30 years later (2003) is was withdrawn as a standard by National Institute of Standards and Technology (NIST), today 6 years later, its time for DES to finally die. By 2008 it was possible to brute force DES keys in 6.4 days using less than USD 10k worth of hardware. So by 2008 DES had passed its sell-by date. This document updates RFC1964, RFC4120, and RFC4121 to deprecate the use of DES in Kerberos.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 28, 2010.

Copyright Notice

Copyright (c) 2010 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 BSD License.

1.  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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Background

Kerberos 5 was defined in [RFC1510] (Kohl, J. and B. Neuman, “The Kerberos Network Authentication Service (V5),” September 1993.) and updated in [RFC4120] (Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” July 2005.), the Kerberos crypto system is defined by [RFC3961] (Raeburn, K., “Encryption and Checksum Specifications for Kerberos 5,” February 2005.) and includes support for DES encryption types. This document updates [RFC1964] (Linn, J., “The Kerberos Version 5 GSS-API Mechanism,” June 1996.), [RFC4120] (Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” July 2005.), and [RFC4121] (Zhu, L., Jaganathan, K., and S. Hartman, “The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2,” July 2005.) to deprecate the use of DES in Kerberos.

DES was withdrawn in [DES‑Transition‑Plan] (National Institute of Standards and Technology, “DES Transition Plan - Federal Register / Vol. 70, No. 96,” May 2006.) by NIST. IETF have also published its the position in [RFC4772] (Kelly, S., “Security Implications of Using the Data Encryption Standard (DES),” December 2006.), which in the recommendation summery is made very clear: "don't use DES".

In Kerberos Generic Security Services Application Programming Interface (GSS-API) mechanism [RFC1964] (Linn, J., “The Kerberos Version 5 GSS-API Mechanism,” June 1996.) and the updated version [RFC4121] (Zhu, L., Jaganathan, K., and S. Hartman, “The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2,” July 2005.) the following checksum and encryption mechanism is defined: three SGN ALG: 0000 - DES MAC MD5, 0100 - MD2.5 0200 - DES MAC and one SEAL ALG 0000 - DES. With newer encryption types for Kerberos defined in [RFC4121] (Zhu, L., Jaganathan, K., and S. Hartman, “The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2,” July 2005.), Microsofts ARCFOUR4-HMAC based GSS-API mech, and MITs DES3 , there is no need to support the old DES based SGN/SEAL types.

3.  Recommendations

This document removes the RECOMMENDED types from [RFC4120] (Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” July 2005.):

Encryption: DES-CBC-MD5(3)

Checksums: DES-MD5 (8, RSA-MD5-DES from [RFC3961] (Raeburn, K., “Encryption and Checksum Specifications for Kerberos 5,” February 2005.)).

Kerberos implementation and deployments SHOULD NOT implement the single DES encryption types: DES-CBC-CRC(1), DES-CBC-MD4(2), DES-CBC-MD5(3).

Kerberos implementation and deployments SHOULD NOT implement the checksum type: CRC32(1), RSA-MD4(2), RSA-MD4-DES(3), DES-MAC(4), DES-MAC-K(5), RSA-MD4-MAC-K(6), DES-MD5(7), RSA-MD5-DES(8).

Note that RSA-MD5 might be with non-DES encryption types, for example, when doing a TGS-REQ with a ARCFOUR-HMAC-MD5 some client uses RSA-MD5 for the checksum that is stored inside the encrypted part of the authenticator. This use of RSA-MD5 should probably be considered safe, so the Kerberos implementation should make sure this usage is not disabled when used with legacy system that can't handle newer checksum types.

Kerberos GSS mechanism implementation and deployments SHOULD NOT implement the SGN ALG: DES MAC MD5(0000), MD2.5(0100), DES MAC(0200) (updates [RFC1964] (Linn, J., “The Kerberos Version 5 GSS-API Mechanism,” June 1996.)).

Kerberos GSS mechanism implementation and deployments SHOULD NOT implement the SEAL ALG: DES(0000) (updates [RFC1964] (Linn, J., “The Kerberos Version 5 GSS-API Mechanism,” June 1996.)).

The effect of the two last sentences is that this document deprecates section 1.2 in [RFC1964] (Linn, J., “The Kerberos Version 5 GSS-API Mechanism,” June 1996.).

4.  Acknowledgements

Jeffery Hutzelman, Simon Josefsson, Mattias Amnefelt and Leif Johansson have read the document and provided suggestions for improvements.

5.  Security Considerations

Removing support for single DES improves security since DES is considered to be insecure.

6.  IANA Considerations

There are no IANA Considerations for this document

7.  References

7.1. Normative References

7.2. Informative References

Author's Address