One document matched: draft-ietf-krb-wg-des-die-die-die-01.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 rfc4772 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4772.xml'>
	  ]>
<rfc category="std"
     ipr="trust200902"
     docName="draft-ietf-krb-wg-des-die-die-die-01"
     updates="1510, 1964, 4120, 4121">

  <?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>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>
          <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, and
	RFC4121 to deprecate the use of DES in Kerberos. Because
	RFC1510 (obsoleted by RFC4120) supports only DES, this
	document also 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. 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 in Kerberos.
      </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.
      </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 ARCFOUR-HMAC based GSS-API mechanism, and MIT's
	DES3, there is no need to support the old DES based integrity
	(SGN) and confidentiality (SEAL) types.
      </t>

    </section>

    <section title="DES insecurity">
      <t>
	The insecurity of DES has been evident for many years. 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 implement
	the single DES encryption types: DES-CBC-CRC(1),
	DES-CBC-MD4(2), DES-CBC-MD5(3).
      </t>

      <t>
	Kerberos implementations and deployments SHOULD NOT implement
	the checksum types: CRC32(1), RSA-MD4(2), RSA-MD4-DES(3),
	DES-MAC(4), DES-MAC-K(5), RSA-MD4-MAC-K(6),
	RSA-MD5-DES(8).
      </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. One example is that some legacy systems only support
	ARCFOUR-HMAC-MD5 for encryption when DES is not available;
	these systems use RSA-MD5 checksums inside Authenticators
	encrypted with ARCFOUR-HMAC-MD5.
      </t>

      <t>
	Kerberos GSS mechanism implementations 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 implementations 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>

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

    </section>

    <section title="Acknowledgements">

      <t>
	Jeffrey Hutzelman, Simon Josefsson, Mattias Amnefelt, Leif
	Johansson, and Ran Atkinson 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, because DES is
	considered to be insecure.
      </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>
	RC4, used in ARCFOUR-HMAC, is considered weak; however, the
	use in 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 only encryption type that
	interoperates with older versions of Microsoft Windows once
	DES is removed.
      </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;
      &rfc4120;
      &rfc4121;
    </references>
    <references title="Informative References">
      &rfc1510;
      &rfc3961;
      &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>