<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" docName="draft-ietf-lamps-crmf-update-algs-07" category="std" consensus="true" updates="4211" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3" number="9045">

  <front>
    <title abbrev="CRMF Algorithm Requirements Update">Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)</title>
    <seriesInfo name="RFC" value="9045"/>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <postal>
          <street>516 Dranesville Road</street>
          <city>Herndon</city>
<region>VA</region>
          <code>20170</code>
          <country>United States of America</country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <date year="2021" month="June"/>
    <area>Security</area>

<keyword>Authentication</keyword>
<keyword>Message Authentication Code</keyword>
<keyword>Password-Based Message Authentication Code</keyword>

    <abstract>
      <t>This document updates the cryptographic algorithm requirements for the
Password-Based Message Authentication Code in the Internet X.509 Public
Key Infrastructure Certificate Request Message Format (CRMF) specified in
RFC 4211.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>

<t>This document updates the cryptographic algorithm requirements for the
Password-Based Message Authentication Code (MAC) in the Internet X.509
Public Key Infrastructure Certificate Request Message Format (CRMF)
<xref target="RFC4211" format="default"/>.  The algorithms specified in <xref target="RFC4211" format="default"/> were appropriate in
2005; however, these algorithms are no longer considered the best
choices:

</t>
      <ul spacing="normal">
        <li>HMAC-SHA1 <xref target="HMAC" format="default"/> <xref target="SHS" format="default"/> is not broken yet, but there are much stronger alternatives <xref target="RFC6194" format="default"/>.</li>
        <li>DES-MAC <xref target="PKCS11" format="default"/> provides 56 bits of security, which is no longer considered secure <xref target="WITHDRAW" format="default"/>.</li>
        <li>Triple-DES-MAC <xref target="PKCS11" format="default"/> provides 112 bits of security, which is now deprecated <xref target="TRANSIT" format="default"/>.</li>
      </ul>
      <t>This update specifies algorithms that are more appropriate today.</t>
      <t>CRMF is defined using Abstract Syntax Notation One (ASN.1) <xref target="X680" format="default"/>.</t>
    </section>
    <section anchor="terms" numbered="true" toc="default">
      <name>Terminology</name>

        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
    </section>
    <section anchor="signature-key-pop" numbered="true" toc="default">
      <name>Signature Key POP</name>


<t><xref target="RFC4211" sectionFormat="of" section="4.1"/> specifies the proof-of-possession (POP)
processing.  This section is updated to explicitly allow the use
of the PBMAC1 algorithm presented in <xref target="RFC8018" sectionFormat="of" section="7.1"/>.</t>
      <t>OLD:</t>
<blockquote>
       algId identifies the algorithm used to compute the MAC value.  All
   implementations <bcp14>MUST</bcp14> support id-PasswordBasedMAC.  The details on
   this algorithm are presented in section <xref target="RFC4211" sectionFormat="bare" section="4.4"/>.
 </blockquote>
      <t>NEW:</t>
<blockquote>
        algId identifies the algorithm used to compute the MAC value.  All
   implementations <bcp14>MUST</bcp14> support id-PasswordBasedMAC as presented in
   <xref target="RFC4211" sectionFormat="of" section="4.4"/>.  Implementations <bcp14>MAY</bcp14> also support
   PBMAC1 as presented in <xref target="RFC8018" sectionFormat="of" section="7.1"/>.
</blockquote>
    </section>
    <section anchor="password-based-message-authentication-code" numbered="true" toc="default">
      <name>Password-Based Message Authentication Code</name>


<t><xref target="RFC4211" sectionFormat="of" section="4.4"/> specifies a Password-Based MAC that relies on
a one-way function to compute a symmetric key from the password and a MAC
algorithm.  This section specifies algorithm requirements for the one-way
function and the MAC algorithm.</t>
      <section anchor="introduction-paragraph" numbered="true" toc="default">
        <name>Introduction Paragraph</name>


<t>Add guidance about limiting the use of the password as follows:</t>
        <t>OLD:</t>
<blockquote>
          This MAC algorithm was designed to take a shared secret (a password)
   and use it to compute a check value over a piece of information.  The
   assumption is that, without the password, the correct check value
   cannot be computed.  The algorithm computes the one-way function
   multiple times in order to slow down any dictionary attacks against
   the password value.
</blockquote>
        <t>NEW:</t>
  <blockquote>
          This MAC algorithm was designed to take a shared secret (a password)
   and use it to compute a check value over a piece of information.  The
   assumption is that, without the password, the correct check value
   cannot be computed.  The algorithm computes the one-way function
   multiple times in order to slow down any dictionary attacks against
   the password value.  The password used to compute this MAC <bcp14>SHOULD NOT</bcp14>
   be used for any other purpose.
  </blockquote>
      </section>
      <section anchor="one-way-function" numbered="true" toc="default">
        <name>One-Way Function</name>


<t>Change the paragraph describing the "owf" as follows:</t>
        <t>OLD:</t>
<blockquote>
          owf identifies the algorithm and associated parameters used to
   compute the key used in the MAC process.  All implementations <bcp14>MUST</bcp14>
   support SHA-1.
</blockquote>
        <t keepWithNext="true">NEW:</t>
<blockquote>
          owf identifies the algorithm and associated parameters used to
   compute the key used in the MAC process.  All implementations <bcp14>MUST</bcp14>
   support SHA-256 <xref target="SHS" format="default"/>.
</blockquote>
      </section>
      <section anchor="iteration-count" numbered="true" toc="default">
        <name>Iteration Count</name>


<t>Update the guidance on appropriate iteration count values as follows:</t>
        <t>OLD:</t>
  <blockquote>
          iterationCount identifies the number of times the hash is applied
   during the key computation process.  The iterationCount <bcp14>MUST</bcp14> be a
   minimum of 100.  Many people suggest using values as high as 1000
   iterations as the minimum value.  The trade off here is between
   protection of the password from attacks and the time spent by the
   server processing all of the different iterations in deriving
   passwords.  Hashing is generally considered a cheap operation but
   this may not be true with all hash functions in the future.
  </blockquote>
        <t>NEW:</t>
      <blockquote>
          iterationCount identifies the number of times the hash is applied
   during the key computation process.  The iterationCount <bcp14>MUST</bcp14> be a
   minimum of 100; however, the iterationCount <bcp14>SHOULD</bcp14> be as large as
   server performance will allow, typically at least 10,000
   <xref target="DIGALM" format="default"/>.  There is a trade-off between protection of the
   password from attacks and the time spent by the server processing
   the iterations.  As part of that trade-off, an iteration count
   smaller than 10,000 can be used when automated generation produces
   shared secrets with high entropy.
      </blockquote>
      </section>
      <section anchor="mac-algorithm" numbered="true" toc="default">
        <name>MAC Algorithm</name>


<t>Change the paragraph describing the "mac" as follows:</t>
        <t>OLD:</t>
      <blockquote>
          mac identifies the algorithm and associated parameters of the MAC
   function to be used.  All implementations <bcp14>MUST</bcp14> support HMAC-SHA1
   <xref target="HMAC"/>.  All implementations <bcp14>SHOULD</bcp14> support DES-MAC and Triple-DES-MAC <xref target="PKCS11"/>.
      </blockquote>
        <t keepWithNext="true">NEW:</t>
             <blockquote>
          mac identifies the algorithm and associated parameters of the MAC
   function to be used.  All implementations <bcp14>MUST</bcp14> support HMAC-SHA256
   <xref target="HMAC"/>.  All implementations <bcp14>SHOULD</bcp14> support AES-GMAC <xref target="AES"/> <xref target="GMAC"/>
   with a 128-bit key.
	     </blockquote>
        <t>For convenience, the identifiers for these two algorithms are
repeated here.</t>
        <t>The ASN.1 algorithm identifier for HMAC-SHA256 is defined in <xref target="RFC4231" format="default"/>:</t>
        <sourcecode name="" type="asn.1"><![CDATA[
   id-hmacWithSHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
      us(840) rsadsi(113549) digestAlgorithm(2) 9 }
]]></sourcecode>
        <t>When this object identifier is used in the ASN.1 algorithm identifier, the
parameters <bcp14>SHOULD</bcp14> be present.  When present, the parameters <bcp14>MUST</bcp14> contain a
type of NULL as specified in <xref target="RFC4231" format="default"/>.</t>
        <t>The ASN.1 algorithm identifier for AES-GMAC <xref target="AES" format="default"/> <xref target="GMAC" format="default"/> with a 128-bit
key is defined in <xref target="RFC9044" format="default"/>:</t>

        <sourcecode name="" type="asn.1"><![CDATA[
   id-aes128-GMAC OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
      country(16) us(840) organization(1) gov(101) csor(3)
      nistAlgorithm(4) aes(1) 9 }
]]></sourcecode>
        <t>When this object identifier is used in the ASN.1 algorithm identifier, the
parameters <bcp14>MUST</bcp14> be present, and the parameters <bcp14>MUST</bcp14> contain the
GMACParameters structure as follows:</t>
        <sourcecode name="" type="asn.1"><![CDATA[
   GMACParameters ::= SEQUENCE {
      nonce        OCTET STRING,
      length       MACLength DEFAULT 12 }

   MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16)
]]></sourcecode>
        <t>The GMACParameters nonce parameter is the GMAC initialization vector.  The
nonce may have any number of bits between 8 and (2^64)-1, but it <bcp14>MUST</bcp14> be a
multiple of 8 bits.  Within the scope of any GMAC key, the nonce value
<bcp14>MUST</bcp14> be unique.  A nonce value of 12 octets can be processed more
efficiently, so that length for the nonce value is <bcp14>RECOMMENDED</bcp14>.</t>
        <t>The GMACParameters length parameter field tells the size of the
message authentication code in octets.  GMAC supports lengths between
12 and 16 octets, inclusive.  However, for use with CRMF, the maximum
length of 16 octets <bcp14>MUST</bcp14> be used.</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>

<t>This document has no IANA actions.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>


<t>The security of the Password-Based MAC relies on the number of times the
hash function is applied as well as the entropy of the shared secret (the
password).  Hardware support for hash calculation is available at very low
cost <xref target="PHS" format="default"/>, which reduces the protection provided by a high iterationCount
value.  Therefore, the entropy of the password is crucial for the security of
the Password-Based MAC function.  In 2010, researchers showed that about half
of the real-world passwords in a leaked corpus can be broken with less than
150 million trials, indicating a median entropy of only 27 bits <xref target="DMR" format="default"/>.  Higher
entropy can be achieved by using randomly generated strings.  For example,
assuming an alphabet of 60 characters, a randomly chosen password with 10 characters
offers 59 bits of entropy, and 20 characters offers 118 bits of entropy.  Using
a one-time password also increases the security of the MAC, assuming that the
integrity-protected transaction will complete before the attacker is able to
learn the password with an offline attack.</t>
      <t>Please see <xref target="RFC8018" format="default"/> for security considerations related to PBMAC1.</t>
      <t>Please see <xref target="HMAC" format="default"/> and <xref target="SHS" format="default"/> for security considerations related to HMAC-SHA256.</t>
      <t>Please see <xref target="AES" format="default"/> and <xref target="GMAC" format="default"/> for security considerations related to AES-GMAC.</t>
      <t>Cryptographic algorithms age; they become weaker with time.  As new
cryptanalysis techniques are developed and computing capabilities
improve, the work required to break a particular cryptographic
algorithm will reduce, making an attack on the algorithm more
feasible for more attackers.  While it is unknown how cryptanalytic
attacks will evolve, it is certain that they will get better.  It is
unknown how much better they will become or when the advances will
happen.  For this reason, the algorithm requirements for CRMF are
updated by this specification.</t>
      <t>When a Password-Based MAC is used, implementations must protect the
password and the MAC key.  Compromise of either the password or the MAC
key may result in the ability of an attacker to undermine authentication.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8018.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4211.xml"/>


	<reference anchor="RFC9044" target="https://www.rfc-editor.org/info/rfc9044">
<front>
<title>Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)</title>
<author initials='R.' surname='Housley' fullname='Russ Housley'>
  <organization/>
</author>
<date month='May' year='2021'/>
</front>
<seriesInfo name="RFC" value="9044"/>
<seriesInfo name="DOI" value="10.17487/RFC9044"/>
</reference>

        <reference anchor="AES">
          <front>
            <title>Advanced Encryption Standard (AES)</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date year="2001" month="November"/>
          </front>
          <seriesInfo name="FIPS PUB" value="197"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/>
        </reference>

        <reference anchor="GMAC">
          <front>
            <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title>
            <author surname="Dworkin" initials="M."/>
            <date year="2007" month="November"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-38D"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
        </reference>


<reference  anchor='HMAC' target='https://www.rfc-editor.org/info/rfc2104'>
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author initials='H.' surname='Krawczyk' fullname='H. Krawczyk'><organization /></author>
<author initials='M.' surname='Bellare' fullname='M. Bellare'><organization /></author>
<author initials='R.' surname='Canetti' fullname='R. Canetti'><organization /></author>
<date year='1997' month='February' />
</front>
<seriesInfo name='RFC' value='2104'/>
<seriesInfo name='DOI' value='10.17487/RFC2104'/>
</reference>

        <reference anchor="SHS">
          <front>
            <title>Secure Hash Standard (SHS)</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="FIPS PUB" value="180-4"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>

        <reference anchor="X680">
          <front>
            <title>Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.680"/>
        </reference>
      </references>

      <references>
        <name>Informative References</name>
        <reference anchor="DMR">
          <front>
            <title>Password Strength: An Empirical Analysis</title>
            <author initials="M." surname="Dell'Amico">
              <organization/>
            </author>
            <author initials="P." surname="Michiardi">
              <organization/>
            </author>
            <author initials="Y." surname="Roudier">
              <organization/>
            </author>
            <date year="2010" month="March"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/INFCOM.2010.5461951"/>
        </reference>

        <reference anchor="DIGALM">
          <front>
            <title>Digital Identity Guidelines: Authentication and Lifecycle Management</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date year="2017" month="June"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-63B"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-63B"/>

        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"/>
        <reference anchor="PHS">
          <front>
            <title>Energy Efficient Bitcoin Mining to Maximize the Mining Profit: Using Data from 119 Bitcoin Mining Hardware Setups</title>
            <author initials="A." surname="Pathirana" fullname="Amila Pathirana">
              <organization/>
            </author>
            <author initials="M." surname="Halgamuge" fullname="Malka Halgamuge">
              <organization/>
            </author>
            <author initials="A." surname="Syed" fullname="Ali Syed">
              <organization/>
            </author>
            <date year="2019" month="November"/>
          </front>
          <refcontent>International Conference on Advances in Business Management and Information Technology, pp. 1-14</refcontent>
        </reference>

        <reference anchor="PKCS11">
          <front>
            <title>PKCS #11 v2.11: Cryptographic Token Interface Standard</title>
            <author>
              <organization>RSA Laboratories</organization>
            </author>
            <date year="2001" month="November"/>
          </front>
        </reference>

        <reference anchor="TRANSIT">
          <front>
            <title>Transitioning the Use of Cryptographic Algorithms and Key Lengths</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date year="2019" month="March"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-131Ar2"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-131Ar2"/>
        </reference>

        <reference anchor="WITHDRAW" target="https://www.nist.gov/news-events/news/2005/06/nist-withdraws-outdated-data-encryption-standard">
          <front>
            <title>NIST Withdraws Outdated Data Encryption Standard</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date year="2005" month="June"/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>

<t>Many thanks to 
<contact fullname="Hans Aschauer"/>,
<contact fullname="Hendrik Brockhaus"/>,
<contact fullname="Quynh Dang"/>,
<contact fullname="Roman Danyliw"/>,
<contact fullname="Lars Eggert"/>,
<contact fullname="Tomas Gustavsson"/>,
<contact fullname="Jonathan Hammell"/>,
<contact fullname="Tim Hollebeek"/>,
<contact fullname="Ben Kaduk"/>,
<contact fullname="Erik Kline"/>,
<contact fullname="Lijun Liao"/>,
<contact fullname="Mike Ounsworth"/>,
<contact fullname="Francesca Palombini"/>,
<contact fullname="Tim Polk"/>,
<contact fullname="Ines Robles"/>,
<contact fullname="Mike StJohns"/>, and
<contact fullname="Sean Turner"/>
for their careful review and improvements.</t>
    </section>
  </back>
</rfc>
