One document matched: draft-lha-des-die-die-die-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1964 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1964.xml'>
<!ENTITY rfc1510 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1510.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3961 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml'>
<!ENTITY rfc4120 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
<!ENTITY rfc4121 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4121.xml'>
<!ENTITY rfc4772 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4772.xml'>
]>
<rfc category="std"
ipr="trust200902"
docName="draft-lha-des-die-die-die-05"
updates="1964, 1510, 3961, 4120, 4121">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Deprecate DES support for Kerberos</title>
<author initials='L' surname="Hornquist Astrand" fullname='Love Hornquist Astrand'>
<organization>Apple, Inc</organization>
<address>
<postal>
<street/>
<city>Cupertino</city> <code/>
<country>USA</country>
</postal>
<email>lha@apple.com</email>
</address>
</author>
<date month="July" year="2010"/>
<abstract>
<t>
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.
Because the version of Kerberos specified in RFC1510 only
supports DES and has been replaced by RFC4120, RFC1510 is
reclassified as historic.
</t>
</abstract>
</front>
<middle>
<section title="Requirements Notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Background">
<t>
Kerberos 5 was defined in <xref target="RFC1510"/> and updated
in <xref target="RFC4120"/>, the Kerberos crypto system is
defined by <xref target="RFC3961"/> and includes support for
DES encryption types. This document updates <xref target="RFC1964"/>,
<xref target="RFC4120"/>, and <xref target="RFC4121"/>
to deprecate the use of DES in Kerberos.
</t>
<t>
Because the version of Kerberos specified in <xref
target="RFC1510"/> only supports DES and has been replaced by
<xref target="RFC4120"/>, <xref target="RFC1510"/> is
reclassified as historic.
</t>
<t>
DES was withdrawn in <xref target="DES-Transition-Plan"/> by
National Institute of Standards and Technology (NIST). IETF
have also published its the position in <xref
target="RFC4772"/>, which in the recommendation summery is
made very clear: "don't use DES".
</t>
<t>
In Kerberos Generic Security Services Application Programming
Interface (GSS-API) mechanism <xref target="RFC1964"/> and the
updated version <xref target="RFC4121"/> 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 <xref target="RFC4121"/>, Microsofts ARCFOUR4-HMAC
based GSS-API mech, and MITs DES3 , there is no need to
support the old DES based SGN/SEAL types.
</t>
</section>
<section title="Recommendations">
<t>
This document removes the RECOMMENDED types from
<xref target="RFC4120"/>:
<list style='empty'>
<t>Encryption: DES-CBC-MD5(3)</t>
<t>Checksums: DES-MD5 (8, RSA-MD5-DES from <xref target="RFC3961"/>).</t>
</list>
</t>
<t>
Kerberos implementation and deployments SHOULD NOT implement the
single DES encryption types: DES-CBC-CRC(1), DES-CBC-MD4(2), DES-CBC-MD5(3).
</t>
<t>
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).
</t>
<t>
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.
</t>
<t>
Kerberos GSS mechanism implementation and deployments SHOULD
NOT implement the SGN ALG: DES MAC MD5(0000), MD2.5(0100), DES
MAC(0200) (updates <xref target="RFC1964"/>).
</t>
<t>
Kerberos GSS mechanism implementation and deployments SHOULD
NOT implement the SEAL ALG: DES(0000) (updates <xref target="RFC1964"/>).
</t>
<t>
The effect of the two last sentences is that this document
deprecates section 1.2 in <xref target="RFC1964"/>.
</t>
</section>
<section title="Acknowledgements">
<t>
Jeffrey Hutzelman, Simon Josefsson, Mattias Amnefelt and Leif
Johansson have read the document and provided suggestions for
improvements. Sam hartman proposed moving <xref target="RFC1510"/> to historic.
</t>
</section>
<section title="Security Considerations">
<t>
Removing support for single DES improves security since DES is
considered to be insecure.
</t>
</section>
<section title="IANA Considerations">
<t>
There are no IANA Considerations for this document
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1964;
&rfc2119;
&rfc3961;
&rfc4120;
&rfc4121;
</references>
<references title="Informative References">
&rfc1510;
&rfc4772;
<reference anchor="DES-Transition-Plan">
<front>
<title>DES Transition Plan - Federal Register / Vol. 70, No. 96</title>
<author><organization>National Institute of Standards and Technology</organization></author>
<date year='2006' month='May'/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:53:52 |