One document matched: draft-ietf-krb-wg-des-die-die-die-03.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN" "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 rfc4757 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4757.xml'>
	  <!ENTITY rfc4772 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4772.xml'>
	  ]>
<rfc category="bcp"
     ipr="trust200902"
     docName="draft-ietf-krb-wg-des-die-die-die-03"
     updates="1510, 1964, 4120, 4121, 4757">

  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="no" ?>
  <?rfc compact="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>

  <front>
    <title abbrev="Deprecate DES in Kerberos">
      Deprecate DES, "export strength" RC4, and other weak
      cryptographic algorithms in Kerberos
    </title>
    <author initials='L' surname="Hornquist Astrand" fullname='Love Hornquist Astrand'>
      <organization>Apple, Inc</organization>
      <address>
        <postal>
	  <street/>
          <city>Cupertino</city>
          <country>USA</country>
        </postal>
        <email>lha@apple.com</email>
      </address>
    </author>
    <author fullname="Tom Yu" initials="T." surname="Yu">
      <organization>MIT Kerberos Consortium</organization>
      <address>
	<postal>
	  <street>77 Massachusetts Ave</street>
	  <city>Cambridge</city>
	  <region>Massachusetts</region>
	  <country>USA</country>
	</postal>
        <email>tlyu@mit.edu</email>
      </address>
    </author>

    <date month="February" year="2012"/>
    <abstract>
      <t>
	The Kerberos 5 network authentication protocol, originally
	specified in RFC1510, 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 RFC1964, RFC4120,
	RFC4121, and RFC4757 to deprecate the use of DES, "export
	strength" RC4, and other weak cryptographic algorithms in
	Kerberos. Because
	RFC1510 (obsoleted by RFC4120) supports only DES, this
	document reclassifies
	RFC1510 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="Introduction">
      <t>
	The original specification of the Kerberos 5 network
	authentication protocol <xref target="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
	reclassifies <xref target="RFC1510"/> (obsoleted by <xref
	target="RFC4120"/>) as Historic, and updates current
	Kerberos-related specifications <xref target="RFC1964"/>,
	<xref target="RFC4120"/>, and <xref target="RFC4121"/> to
	deprecate the use of DES and other weak cryptographic
	algorithms in Kerberos, including some unkeyed checksums and
	hashes, along with the weak "export strength" RC4 enctype of <xref
	target="RFC4757"/>.
      </t>
    </section>

    <section title="Affected specifications">
      <t>
	The original IETF specification of Kerberos 5 <xref
	target="RFC1510"/> only supports DES for
	encryption. <xref target="RFC4120"/> obsoletes <xref
	target="RFC1510"/> and updates the Kerberos specification to
	include additional cryptographic algorithms, but still permits
	the use of DES. <xref target="RFC3961"/> describes the
	Kerberos cryptographic system and includes support for DES
	encryption types, but it does not specify requirement levels
	for them.
      </t>

      <t>
	The specification of the Kerberos Generic Security Services
	Application Programming Interface (GSS-API) mechanism <xref
	target="RFC1964"/> and its updated version <xref
	target="RFC4121"/> define checksum and encryption mechanisms
	based on DES. With the existence of newer encryption types for
	Kerberos GSS-API defined in <xref target="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.
      </t>

      <t>
	<xref target="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.)
      </t>
    </section>

    <section title="DES insecurity">
      <t>
	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 <xref
	target="DES-Withdrawal"/>, and also announced a transition
	period that ended on May 19, 2007 <xref
	target="DES-Transition-Plan"/>. The IETF has also published
	its position in <xref target="RFC4772"/>, in which the
	recommendation summary is very clear: "don't use DES".
      </t>

      <t>
	In 2006, researchers demonstrated the ability to brute force a
	DES key in an average of less than 9 days using less than EUR
	10,000 worth of hardware <xref target="Break-DES"/>. By 2008,
	a company was offering hardware capable of breaking a DES key
	in less than a day on average <xref target="DES-1day"/> that
	cost less than USD 15,000 <xref	target="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.
      </t>
    </section>

    <section title="Recommendations">
      <t>
	This document hereby removes the following RECOMMENDED types from
	<xref target="RFC4120"/>:
	<list style='empty'>
	  <t>Encryption: DES-CBC-MD5(3)</t>
	  <t>Checksums: DES-MD5 (8, named RSA-MD5-DES in <xref target="RFC3961"/>).</t>
	</list>
      </t>

      <t>
	Kerberos implementations and deployments SHOULD NOT provide
	the following single DES encryption types: DES-CBC-CRC(1),
	DES-CBC-MD4(2), DES-CBC-MD5(3) (updates <xref target="RFC4120"/>).
      </t>

      <t>
	Kerberos implementations and deployments SHOULD NOT provide
	the following "export strength" RC4 encryption type:
	RC4-HMAC-EXP(24) (updates <xref target="RFC4757"/>). This
	document does not add any sort of requirement for conforming
	implementations to provide RC4-HMAC(23).
      </t>

      <t>
	Kerberos implementations and deployments SHOULD NOT provide
	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 <xref target="RFC4120"/>).
      </t>

      <t>
	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 encrypted Authenticator for backward
	compatibility with systems that do not support newer checksum
	types (updates <xref target="RFC4120"/>). One example is that
	some legacy systems only support RC4-HMAC(23) <xref
	target="RFC4757"/> for encryption when DES is not available;
	these systems use RSA-MD5 checksums inside Authenticators
	encrypted with RC4-HMAC.
      </t>

      <t>
	Kerberos GSS mechanism implementations and deployments SHOULD
	NOT provide the following SGN ALG: DES MAC MD5(0000),
	MD2.5(0100), DES MAC(0200) (updates <xref target="RFC1964"/>).
      </t>

      <t>
	Kerberos GSS mechanism implementations and deployments SHOULD
	NOT provide the following 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>

      <t>
	This document hereby reclassifies <xref target="RFC1510"/> as
	Historic.
      </t>

    </section>

    <section title="Acknowledgements">

      <t>
	Mattias Amnefelt, Ran Atkinson, Henry Hotz, Jeffrey Hutzelman,
	Leif Johansson, and Simon Josefsson have read the document and
	provided suggestions for improvements. Sam Hartman proposed
	moving <xref target="RFC1510"/> to Historic. Michiko Short
	provided information about the dates of end of support for
	Windows releases.
      </t>

    </section>

    <section title="Security Considerations">

      <t>
	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.
      </t>

      <t>
	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.
      </t>

      <t>
	The security considerations of <xref target="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 <xref target="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.
      </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;
      &rfc4757;
    </references>
    <references title="Informative References">
      &rfc1510;
      &rfc4772;

      <reference anchor="Break-DES"
	target="http://www.copacobana.org/paper/copacobana_SHARCS2006.pdf">
	<front>
	  <title>
	    How to break DES for EUR 8,980 - SHARCS'06 -
	    Special-purpose Hardware for Attacking Cryptographic
	    Systems
	  </title>
	  <author initials="S." surname="Kumar" fullname="Sandeep Kumar"/>
	  <author initials="C." surname="Paar" fullname="Christof Paar"/>
	  <author initials="J." surname="Pelzl" fullname="Jan Pelzl"/>
	  <author initials="G." surname="Pfeiffer" fullname="Gerd Pfeiffer"/>
	  <author initials="A." surname="Rupp" fullname="Andy Rupp"/>
	  <author initials="M." surname="Schimmler" fullname="Manfred Schimmler"/>
	  <date year="2006" month="April"/>
	</front>
      </reference>

      <reference anchor="DES-1day"
	target="http://www.sciengines.com/company/news-a-events/74-des-in-1-day.html">
	<front>
	  <title>Break DES in less than a single day</title>
	  <author>
	    <organization>SciEngines GmbH</organization>
	  </author>
	  <date/>
	</front>
      </reference>

      <reference anchor="DES-crack"
	target="http://www.tjscott.net/security.extras/des.crack.efforts.pdf">
	<front>
	  <title>DES Brute Force Cracking Efforts 1977 to 2010</title>
	  <author initials="T.J." surname="Scott">
	  </author>
	  <date year="2010"/>
	</front>
      </reference>

      <reference anchor="DES-Transition-Plan"
	target="http://csrc.nist.gov/groups/STM/common_documents/DESTranPlan.pdf">
	<front>
	  <title>DES Transition Plan</title>
          <author>
	    <organization>
	      National Institute of Standards and Technology
	    </organization>
	  </author>
          <date year='2005' month='May'/>
        </front>
      </reference>

      <reference anchor="DES-Withdrawal"
	target="http://www.gpo.gov/fdsys/pkg/FR-2005-05-19/pdf/05-9945.pdf">
	<front>
	  <title>
	    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
	    Document 05-9945
	  </title>
	  <author>
	    <organization>
	      National Institute of Standards and Technology
	    </organization>
	  </author>
	  <date year='2005' month='May'/>
	</front>
	<seriesInfo name="70 FR" value="28907-28908"/>
      </reference>

    </references>
  </back>
</rfc>