<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-hartman-snmp-sha2-01" ipr="trust200902">
  <front>
    <title abbrev="snmpv3 sha2">Authenticating version 3 of the Simple Network
    Management Protocol (SNMPv3) using HMAC-SHA-2 procedures</title>

    <author fullname="Sam Hartman" initials="S." surname="Hartman">
      <organization>Painless Security</organization>

      <address>
        <postal>
          <street>356 Abbott Street</street>

          <city>North Andover</city>

          <region>MA</region>

          <code>01845</code>

          <country>USA</country>
        </postal>

        <email>hartmans@painless-security.com</email>

        <uri>http://www.painless-security.com</uri>
      </address>
    </author>

    <author fullname="Margaret Wasserman" initials="M." surname="Wasserman">
      <organization>Painless Security</organization>

      <address>
        <postal>
          <street>356 Abbott Street</street>

          <city>North Andover</city>

          <region>MA</region>

          <code>01845</code>

          <country>USA</country>
        </postal>

        <phone>+1 781 405 7464</phone>

        <email>mrw@painless-security.com</email>

        <uri>http://www.painless-security.com</uri>
      </address>
    </author>

    <author fullname="Dacheng Zhang" initials="D." surname="Zhang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <region/>

          <code/>

          <country>China</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>zhangdacheng@huawei.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Manav Bhatia" initials="M." surname="Bhatia">
      <organization>A-L</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>India</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>manav.bhatia@alcatel-lucent.com</email>

        <uri/>
      </address>
    </author>

    <date day="28" month="January" year="2014"/>

    <abstract>
      <t>This document describes the mechanism to authenticate SNMPv3 protocol
      packets using Hashed Message Authentication Mode (HMAC) with the
      SHA-256, SHA-384, and SHA-512 algorithms.</t>
    </abstract>

    <note title="Requirements Language">
      <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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The cryptographic authentication mechanism proposed in <xref
      target="RFC3414"/> specifies the support of MD5 <xref target="RFC1321"/>
      and Secure Hash Algorithm (SHA-1) algorithms for authenticating SNMPv3
      packets. The recent escalating series of attacks on MD5 and SHA-1 <xref
      target="SHA-1-attack1"/> <xref target="SHA-1-attack2"/> raise concerns
      about their remaining useful lifetime <xref target="RFC6151"/> <xref
      target="RFC6194"/>.</t>

      <t>These attacks may not necessarily result in direct vulnerabilities
      for Keyed-MD5 and Keyed-SHA-1 digests as message authentication codes
      because the colliding message may not correspond to a syntactically
      correct SNMP protocol packet. Regardless, there is a need felt to
      deprecate MD5 and SHA-1 as the basis for the HMAC algorithm in favor of
      stronger digest algorithms.</t>

      <t>This document adds support for Secure Hash Algorithms (SHA) defined
      in the US NIST Secure Hash Standard (SHS), which is defined by NIST FIPS
      180-2 <xref target="FIPS-180-2"/>. <xref target="FIPS-180-2"/> includes
      SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The HMAC authentication
      mode defined in NIST FIPS 198 is used <xref target="FIPS-198"/>.</t>

      <t/>
    </section>

    <section title="Cryptographic Aspects  ">
      <t>In the algorithm description below, the following nomenclature, which
      is consistent with <xref target="FIPS-198"/>, is used:</t>

      <t>H is the specific hashing algorithm (e.g. SHA-256).</t>

      <t>K is the secret key for authentication.</t>

      <t>Ko is the cryptographic key used with the hash algorithm.</t>

      <t>B is the block size of H, measured in octets rather than bits. Note
      that B is the internal block size, not the hash size.</t>

      <t>For SHA-1 and SHA-256: B == 64</t>

      <t>For SHA-384 and SHA-512: B == 128</t>

      <t>L is the length of the hash, measured in octets rather than bits.</t>

      <t>XOR is the exclusive-or operation.</t>

      <t>Opad is the hexadecimal value 0x5c repeated B times.</t>

      <t>Ipad is the hexadecimal value 0x36 repeated B times.</t>

      <t>Apad is the hexadecimal value of source IPv4 address repeated (L/4)
      times (repeated (L/16) for IPV6 addresses).</t>

      <t>(1) Preparation of the Key</t>

      <t>In this application, Ko is always L octets long.</t>

      <t>If the Authentication Key (K) is L octets long, then Ko is equal to
      K. If the Authentication Key (K) is more than L octets long, then Ko is
      set to H(K). If the Authentication Key (K) is less than L octets long,
      then Ko is set to the Authentication Key (K) with zeros appended to the
      end of the Authentication Key (K) such that Ko is L octets long.</t>

      <t>(2) First Hash</t>

      <t>First, the AuthenticationParameters field is filled with the value of
      Apad and is set to the serialization, according to the rules in <xref
      target="RFC3417"/>.</t>

      <t>Then, a first hash, also known as the inner hash, is computed as
      follows:</t>

      <t>First-Hash = H(Ko XOR Ipad || (SNMP Packet))</t>

      <t>(3) Second Hash T</t>

      <t>Then a second hash, also known as the outer hash, is computed as
      follows:</t>

      <t>Second-Hash = H(Ko XOR Opad || First-Hash)</t>

      <t>(4) Result</t>

      <t>The resultant Second-Hash becomes the Authentication Data that is
      sent in the AuthenticationParameters field. The length of the
      AuthenticationParameters field is always identical to the message digest
      size of the specific hash function H that is being used.</t>
    </section>

    <section title="Authentication Protocols using SHA-2">
      <t>This section introduces how the authentication protocols using SHA-2
      work. The protocols are identical to the authentication protocols
      proposed in the <xref target="RFC3414"/> except the authentication
      algorithms used in generating digests.</t>

      <section title="Elements of Authentication Protocols  ">
        <t/>

        <section title="Users  ">
          <t>Authentication using the authentication protocols makes use of a
          defined set of userNames. For any user on whose behalf a message
          must be authenticated at a particular SNMP engine, that SNMP engine
          must have knowledge of that user. An SNMP engine that wishes to
          communicate with another SNMP engine must also have knowledge of a
          user known to that engine, including knowledge of the applicable
          attributes of that user.</t>

          <t>A user and its attributes are defined as follows:</t>

          <t>&lt;userName&gt; A string representing the name of the user.</t>

          <t>&lt;authKey&gt; A user's secret key to be used when calculating a
          digest. Specifically, the value SHOULD be 32 octets for
          HMAC-SHA-256, 48 octets for HMAC-SHA-384, and 64 octets for HMAC-
          SHA-512.</t>
        </section>

        <section title="SNMP Messages Using this Authentication Protocol  ">
          <t>Messages using this authentication protocol carry a
          msgAuthenticationParameters field as part of the
          msgSecurityParameters. For this protocol, the
          msgAuthenticationParameters field is the serialized OCTET STRING
          representing the SHA-2 output done over the wholeMsg. Specifically,
          the length of this field is 32 octets for HMAC-SHA-256, 48 octets
          for HMAC-SHA-384, and 64 octets for HMAC- SHA-512. The digest is
          calculated over the wholeMsg so if a message is authenticated, that
          also means that all the fields in the message are intact and have
          not been tampered with.</t>
        </section>
      </section>

      <section title="Services Provided by the Authentication Module  ">
        <t/>

        <section title="Services for Generating an Outgoing SNMP Message  ">
          <t>The authentication protocol assumes that the selection of the
          authKey is done by the caller and that the caller passes the secret
          key to be used. Upon completion the authentication module returns
          statusInformation and, if the message digest was correctly
          calculated, the wholeMsg with the digest inserted at the proper
          place. The abstract service primitive is:</t>

          <t><figure>
              <artwork><![CDATA[   statusInformation =              -- success or failure
     authenticateOutgoingMsg(
     IN   authKey                   -- secret key for authentication
     IN   wholeMsg                  -- unauthenticated complete message
     OUT  authenticatedWholeMsg     -- complete authenticated message
          )
]]></artwork>
            </figure></t>

          <t>The abstract data elements are:</t>

          <t>statusInformation: An indication of whether the authentication
          process was successful. If not it is an indication of the
          problem.</t>

          <t>authKey: The secret key to be used by the authentication
          algorithm.</t>

          <t>wholeMsg: The message to be authenticated.</t>

          <t>authenticatedWholeMsg: The authenticated message (including
          inserted digest) on output.</t>
        </section>

        <section title="Services for Processing an Incoming SNMP Message ">
          <t>The authentication protocol assumes that the selection of the
          authKey is done by the caller and that the caller passes the secret
          key to be used. Upon completion the authentication module returns
          statusInformation and, if the message digest was correctly
          calculated, the wholeMsg as it was processed. The abstract service
          primitive is:</t>

          <t><figure>
              <artwork><![CDATA[   statusInformation =              -- success or failure
     authenticateIncomingMsg(
     IN   authKey                   -- secret key for authentication
     IN   authParameters            -- as received on the wire
     IN   wholeMsg                  -- as received on the wire
     OUT  authenticatedWholeMsg     -- complete authenticated message
          )

]]></artwork>
            </figure></t>

          <t>The abstract data elements are:</t>

          <t>statusInformation: An indication of whether the authentication
          process was successful. If not it is an indication of the
          problem.</t>

          <t>authKey: The secret key to be used by the authentication
          algorithm.</t>

          <t>authParameters: The authParameters from the incoming message.</t>

          <t>wholeMsg: The message to be authenticated on input and the
          authenticated message on output.</t>

          <t>authenticatedWholeMsg: The whole message after the authentication
          check is complete.</t>

          <t/>
        </section>
      </section>
    </section>

    <section title="Elements of Procedure  ">
      <t/>

      <section title="Procedures at the Sending Side  ">
        <t>Before a SNMPv3 device sends an SNMP packet out, the device needs
        to select an appropriate key for authentication if a keyed digest for
        the packet is required. If no appropriate key is avaliable, the SNMP
        packet MUST be discarded.</t>

        <t>If an appropriate key for authentication is available, the device
        then finds the authentication algorithm (HMAC-SHA-256, HMAC-SHA-384 or
        HMAC-SHA-512) associated with the key.</t>

        <t>Then, the operations illustrated in Section 2 are performed.</t>

        <t>The length of the msgAuthenticationParameters field is various
        according to different authentication algorithms being used.
        Specifically, the length is 40 octets for HMAC-SHA-256, 56 octets for
        HMAC-SHA-384, and 72 octets for HMAC-SHA-512.</t>

        <t>The authenticatedWholeMsg is then returned to the caller together
        with statusInformation indicating success.</t>
      </section>

      <section title="Procedure at the Receiving Side  ">
        <t>Upon receiving an SNMP packet with a msgAuthenticationParameters
        field appended, a device needs to locate an appropriate key for
        authentication to verify the packet.</t>

        <t>If there is no key found or the length of the digest received in
        the msgAuthenticationParameters field does not match the length
        associated with authentication algorithm, the received packet MUST be
        discarded.</t>

        <t>An authentication algorithm dependent process then needs to be
        performed by using the algorithm specified by the appropriate key for
        the received packet.</t>

        <t>Before the device performs any processing, it needs to save the
        content of the AuthenticationParameters field and set the
        AuthenticationParameters field with Apad.</t>

        <t>Then, the operations illustrated in Section 2 are performed. The
        calculated data is compared with the received authentication data in
        the packet.</t>

        <t>The packet MUST be discarded if the calculated and the received
        authentication data do not match. In this case, a failure and an
        errorIndication (authenticationFailure) are returned to the calling
        module. Otherwise, the authenticatedWholeMsg and statusInformation
        indicating success are then returned to the caller.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t/>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This work makes use of signifitent texts from that RFC3414.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include='reference.RFC.6151'?>

      <?rfc include='reference.RFC.6194'?>

      <?rfc include='reference.RFC.3417'?>

      <?rfc include='reference.RFC.6039'?>

      <reference anchor="FIPS-180-2">
        <front>
          <title>The Keyed-Hash Message Authentication Code (HMAC)</title>

          <author fullname="" surname="">
            <organization>National Institute of Standards and Technology, FIPS
            PUB 180-2</organization>
          </author>

          <date month="August" year="2002"/>
        </front>
      </reference>

      <reference anchor="FIPS-198">
        <front>
          <title>The Keyed-Hash Message Authentication Code (HMAC)</title>

          <author>
            <organization>National Institute of Standards and Technology, FIPS
            PUB 198</organization>
          </author>

          <date month="March" year="2002"/>
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-karp-design-guide'?>

      <?rfc include='reference.RFC.3414'?>

      <reference anchor="MD5-attack">
        <front>
          <title>Collisions for Hash Functions MD4, MD5, HAVAL-128 and
          RIPEMD</title>

          <author initials="X" surname="Wang">
            <organization/>
          </author>

          <author fullname="" initials="D." surname="Feng">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <author initials="X." surname="Lai">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <author initials="H." surname="Yu">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <date month="August" year="2004"/>
        </front>
      </reference>

      <reference anchor="Dobb96a">
        <front>
          <title>Cryptanalysis of MD5 Compress</title>

          <author initials="H." surname="Dobbertin">
            <organization/>
          </author>

          <date month="May" year="1996"/>
        </front>
      </reference>

      <reference anchor="NIST-HMAC-SHA">
        <front>
          <title>NIST's Policy on Hash Functions</title>

          <author fullname="" surname="">
            <organization>National Institute of Standards and Technology,
            Available online at
            http://csrc.nist.gov/groups/ST/hash/policy.html</organization>
          </author>

          <date month="" year="2006"/>
        </front>
      </reference>

      <reference anchor="Dobb96b">
        <front>
          <title>The Status of MD5 After a Recent Attack", CryptoBytes</title>

          <author initials="H." surname="Dobbertin">
            <organization/>
          </author>

          <date year="1996"/>
        </front>
      </reference>

      <reference anchor="SHA-1-attack1">
        <front>
          <title>Finding Collisions in the Full SHA-1</title>

          <author initials="X." surname="Wang">
            <organization/>
          </author>

          <author initials="Y." surname="Yin">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <author initials="H." surname="Yu">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <date year="2005"/>
        </front>
      </reference>

      <reference anchor="SHA-1-attack2">
        <front>
          <title>New Collision Search for SHA-1</title>

          <author initials="X." surname="Wang">
            <organization/>
          </author>

          <author initials="A." surname="Yao">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <author initials="F." surname="Yao">
            <organization/>

            <address>
              <postal>
                <street/>

                <city/>

                <region/>

                <code/>

                <country/>
              </postal>

              <phone/>

              <facsimile/>

              <email/>

              <uri/>
            </address>
          </author>

          <date year="2005"/>
        </front>
      </reference>

      <?rfc include='reference.RFC.2104'?>

      <?rfc include='reference.RFC.4086'?>

      <?rfc include='reference.RFC.4822'?>

      <?rfc include='reference.RFC.5310'?>

      <?rfc include='reference.RFC.1321'?>

      <?rfc include='reference.RFC.6234'?>
    </references>
  </back>
</rfc>
