<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY rfc2223 SYSTEM "reference.RFC.2223.xml">
<!ENTITY rfc2578 SYSTEM "reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "reference.RFC.2580.xml">
<!ENTITY rfc2629 SYSTEM "reference.RFC.2629.xml">
<!ENTITY rfc3410 SYSTEM "reference.RFC.3410.xml">
<!ENTITY rfc4181 SYSTEM "reference.RFC.4181.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc number="7630"
     category="std" 
     submissionType="IETF"
     consensus="yes"
     ipr="trust200902">
	<front>

	<title abbrev="HMAC-SHA-2_Auth_USM">HMAC-SHA-2 Authentication Protocols in&nbsp;the&nbsp;User&nbhy;based&nbsp;Security&nbsp;Model&nbsp;(USM) for SNMPv3</title>


		<author fullname="Johannes Merkle" initials="J.M."
				surname="Merkle" role="editor">
			<organization>Secunet Security Networks</organization>
			<address>
				<postal>
					<street>Mergenthaler Allee 77</street>
					<city>65760 Eschborn</city>
					<country>Germany</country>
				</postal>
				<phone>+49 201 5454 3091</phone>
				<email>johannes.merkle@secunet.com</email>
			</address>
		</author>

		<author fullname="Manfred Lochter" initials="M.L."
				surname="Lochter">
			<organization>BSI</organization>
			<address>
				<postal>
					<street>Postfach 200363</street>
					<city>53133 Bonn</city>
					<country>Germany</country>
				</postal>
				<phone>+49 228 9582 5643</phone>
				<email>manfred.lochter@bsi.bund.de</email>
			</address>
		</author>

		<date month="August" year="2015" />
		<area>Security Area</area>
		<workgroup>OPSAWG</workgroup>

		<keyword>Network Management</keyword>
		<keyword>SNMP</keyword>
		<keyword>USM</keyword>
		<keyword>HMAC</keyword>
		<keyword>SHA-2</keyword>

		<abstract>
			<t> This memo specifies new HMAC-SHA-2 authentication
				protocols for the User-based Security Model (USM) for SNMPv3
				defined in RFC 3414.</t>
		</abstract>
	</front>

	<middle>

		<section title="Introduction">

			<t>This memo defines a portion of the Management Information Base (MIB)
				for use with network management protocols. In particular, it defines
				additional authentication protocols for the
				User-based Security Model (USM) for the Simple Network Management Protocol
			version 3 (SNMPv3) specified in RFC 3414 <xref target="RFC3414"/>.</t>

			<t>In RFC 3414, two different authentication protocols, HMAC-MD5-96 and
				HMAC-SHA-96, are defined based on the hash functions MD5 and SHA-1,
				respectively. This memo specifies new HMAC-SHA-2 authentication
				protocols for USM using a Hashed Message Authentication Code
				(HMAC) based on the SHA-2 family of hash functions <xref target="SHA"/>
				and truncated to 128 bits for SHA-224, to 192
				bits for SHA-256, to 256 bits for SHA-384, and to 384 bits for SHA&nbhy;512.
				These protocols are straightforward adaptations of the authentication
				protocols HMAC-MD5-96 and HMAC-SHA-96 to the SHA&nbhy;2&nbhy;based HMAC.</t>

		</section>

		<section title="The Internet-Standard Management Framework">

			<t>For a detailed overview of the documents that describe the current
				Internet-Standard Management Framework, please refer to section 7 of RFC
				3410 <xref target="RFC3410"/>.</t>

			<t>Managed objects are accessed via a virtual information store, termed
				the Management Information Base or MIB. MIB objects are generally
				accessed through the Simple Network Management Protocol (SNMP). Objects
				in the MIB are defined using the mechanisms defined in the Structure of
				Management Information (SMI). This memo specifies a MIB module that is
				compliant to the SMIv2, which is described in
				STD 58, RFC 2578 <xref
				target="RFC2578"></xref>, 
				STD 58, RFC 2579 <xref
						target="RFC2579">
				</xref> and STD 58, RFC 2580 <xref
						target="RFC2580">
				</xref>.</t>
		</section>

		<section title="Conventions">
			<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 BCP 14, RFC 2119 <xref
						target="RFC2119">
				</xref>.</t>

		</section>

		<!-- ********************************************* -->


		<section anchor="protocol" title="The HMAC-SHA-2 Authentication Protocols">

			<t>
<!-- [rfced] We are having trouble parsing the following sentence.  Please let 
us know how we may clarify.

ORIGINAL:
This section describes the HMAC-SHA-2 authentication protocols.  They
   use the SHA-2 hash functions, which are described in FIPS PUB 180-4
   [SHA] and RFC 6234 [RFC6234], in HMAC mode described in RFC 2104
   [RFC2104] and RFC 6234, truncating the output to 128 bits for SHA-
   224, 192 bits for SHA-256, 256 bits for SHA-384, and 384 bits for
   SHA-512.

SUGGESTED:
This section describes the HMAC-SHA-2 authentication protocols, which
   use the SHA-2 hash functions (described in FIPS PUB 180-4
   [SHA] and RFC 6234 [RFC6234]) in the HMAC mode (described in RFC 2104
   [RFC2104] and RFC 6234), truncating the output to 128 bits for SHA-
   224, 192 bits for SHA-256, 256 bits for SHA-384, and 384 bits for
   SHA-512.
   
  
[jm] We agree to your suggestion. 
-->

			
			This section describes the HMAC-SHA-2 authentication protocols, which
   use the SHA-2 hash functions (described in FIPS PUB 180-4
   <xref target="SHA"/> and RFC 6234 <xref target="RFC6234"/>) in the HMAC mode (described in RFC 2104
   <xref target="RFC2104"/> and RFC 6234), truncating the output to 128 bits for SHA-224, 192 bits for SHA-256, 256 bits for SHA-384, and 384 bits for
   SHA-512. RFC 6234 also provides source code for all the
			SHA-2 algorithms and HMAC (without truncation). It also includes test harness and standard
			test vectors for all the defined hash functions and HMAC examples.</t>

			<t>The following protocols are defined:</t>
			<t>
				<list>
					<t>usmHMAC128SHA224AuthProtocol: uses SHA-224
						and truncates the output to 128 bits (16 octets);</t>
					<t>usmHMAC192SHA256AuthProtocol: uses SHA-256
						and truncates the output to 192 bits (24 octets);</t>
					<t>usmHMAC256SHA384AuthProtocol: uses SHA-384
						and truncates the output to 256 bits (32 octets);</t>
					<t>usmHMAC384SHA512AuthProtocol: uses SHA-512
						and truncates the output to 384 bits (48 octets).</t>
				</list>
			</t>

			<t>Implementations conforming to this specification MUST support usmHMAC192SHA256AuthProtocol
				and SHOULD support usmHMAC384SHA512AuthProtocol. The protocols usmHMAC128SHA224AuthProtocol and usmHMAC256SHA384AuthProtocol are OPTIONAL.</t>

			<section anchor="differences" title="Deviations from the HMAC-SHA-96 Authentication Protocol">

				<t>All the HMAC-SHA-2 authentication protocols are straightforward
					adaptations of the HMAC-MD5-96 and HMAC-SHA-96 authentication protocols.
					Specifically, they differ from the HMAC-MD5-96 and HMAC-SHA-96
					authentication protocols in the following aspects:</t>

				<t>
					<list style="symbols">
						<t> The SHA-2 hash function is used to compute the message digest in the
							HMAC computation
							according to RFC 2104
							
							and RFC 6234, as opposed to
							the MD5 hash function <xref target="RFC1321"/> and SHA-1 hash
							function <xref target="SHA"/> used in HMAC-MD5-96 and HMAC-SHA-96,
							respectively.

							Consequently, the length of the message digest prior to truncation
							is 224 bits for the SHA-224-based protocol, 256 bits for
							the SHA-256-based
							protocol, 384 bits for
							the SHA-384-based protocol, and 512 bits
							for the SHA-512-based protocol.</t>
						<t> The resulting message digest (output of HMAC) is truncated to
							<list>
								<t>16 octets for usmHMAC128SHA224AuthProtocol</t>
								<t>24 octets for usmHMAC192SHA256AuthProtocol</t>
								<t>32 octets for usmHMAC256SHA384AuthProtocol</t>
								<t>48 octets for usmHMAC384SHA512AuthProtocol</t>
							</list>
							as opposed to the truncation to 12 octets in HMAC-MD5-96 and HMAC-SHA-96.</t>
						<t>The user's secret key to be used when calculating a digest MUST be
							<list>
								<t>28 octets long and derived with SHA-224 for the SHA-224-based protocol usmHMAC128SHA224AuthProtocol</t>
								<t>32 octets long and derived with SHA-256 for the SHA-256-based protocol usmHMAC192SHA256AuthProtocol</t>
								<t>48 octets long and derived with SHA-384 for the SHA-384-based protocol usmHMAC256SHA384AuthProtocol</t>
								<t>64 octets long and derived with SHA-512 for the SHA-512-based protocol usmHMAC384SHA512AuthProtocol</t>
							</list>
							as opposed to the keys being 16 and 20 octets long in
							HMAC-MD5-96 and HMAC-SHA-96, respectively. </t>
					</list>
				</t>

			</section>

			<section anchor="Procedure" title="Processing">

				<t>This section describes the procedures for the HMAC-SHA-2
					authentication protocols.
					The descriptions are based on the definition of services and data
					elements defined for HMAC-SHA-96 in
					RFC 3414
					with the deviations listed in <xref target="differences" />. </t>

					<t>Values of constants M (the length
					of the secret key in octets) and N
					(the length of the Message
					Authentication Code (MAC) output in octets), and the hash function H used below are:
						<list>
							<t>usmHMAC128SHA224AuthProtocol: M=28, N=16, H=SHA-224;</t>
							<t>usmHMAC192SHA256AuthProtocol: M=32, N=24, H=SHA-256;</t>
							<t>usmHMAC256SHA384AuthProtocol: M=48, N=32, H=SHA-384;</t>
							<t>usmHMAC384SHA512AuthProtocol: M=64, N=48, H=SHA-512.</t>
						</list>	</t>
					
				<section anchor="Procedure_Out" title="Processing an Outgoing Message">
								
					<t>This section describes the procedure followed by an SNMP engine
						whenever it must authenticate an outgoing message using one of the
						authentication protocols defined above. Values of the constants M and N, and the hash function H are as defined in 
						<xref target="Procedure"/> and are selected based
						on which authentication protocol is configured for the given
						USM usmUser Table entry.</t>

					<t>
						<list style="numbers">
							<t>
							  The
							  msgAuthenticationParameters
							  field is set to the serialization of an
								OCTET STRING
							containing N zero
							octets; it is serialized 
								according to the rules in RFC 3417 <xref target="RFC3417"/>.</t>

							<t>Using the secret authKey of M octets, the HMAC is calculated over the wholeMsg according to
								RFC 6234 with hash function H.</t>

							<t>The N first octets of the above HMAC are taken as the computed MAC value.</t>

							<t>The msgAuthenticationParameters field is replaced with the MAC obtained in
								the previous step.</t>

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

				<section anchor="Procedure_In" title="Processing an Incoming Message">

					<t>This section describes the procedure followed by an SNMP engine
						whenever it must authenticate an incoming message using one of the
						HMAC-SHA-2 authentication protocols. 
						Values of the constants M and N, and the hash function H are as defined in 
						<xref target="Procedure"/> and are selected based
						on which authentication protocol is configured for the given
						USM usmUser Table entry.</t>

					<t>
						<list style="format %d." counter="my_count">
							<t>If the digest received in the msgAuthenticationParameters field is
								not N octets long, then a failure and an errorIndication
								(authenticationError)
							are returned to the calling module.</t>

							<t>The MAC received in the msgAuthenticationParameters field is
								saved.</t>

							<t>The digest in the msgAuthenticationParameters field is replaced by
								the N zero octets.</t>

							<t>Using the secret authKey of M octets, the HMAC is calculated over the wholeMsg according to
								RFC 6234 with hash function H.</t>

							<t>The N first octets of the above HMAC are taken as the computed MAC value.</t>

							<t>The msgAuthenticationParameters field is replaced with the MAC
								value that was saved in step 2.</t>

							<t>The newly calculated MAC is compared with the MAC saved in
								step 2.  If they do not match, then a failure and an
								errorIndication (authenticationFailure) are returned to the
								calling module.</t>

							<t>The authenticatedWholeMsg and statusInformation indicating success
								are then returned to the caller.</t>
						</list>
					</t>
				</section>
			</section>
		</section>

		<section title="Key Localization and Key Change">
			<t>For any of the protocols defined in <xref target='protocol' />, key localization 
				and key change SHALL be performed according to
				RFC 3414 <xref target="RFC3414"/> 
				using the same SHA-2 hash function as in the HMAC-SHA-2 authentication protocol.</t>
		</section>

		<section title="Structure of the MIB Module">

			<t>The MIB module specified in this memo does not define any managed objects, subtrees, notifications,
			or tables; rather, it only defines object identities (for authentication protocols) under a subtree of an existing MIB.</t>

		</section>

		<section title="Relationship to Other MIB Modules">
			<section title="Relationship to SNMP-USER-BASED-SM-MIB">
				<t>RFC 3414 specifies the MIB module for USM for SNMPv3 (SNMP-USER-BASED-SM-MIB), which defines 
					authentication protocols for USM
					based on the hash functions MD5 and
					SHA-1, respectively. The following MIB module defines new HMAC-SHA2 authentication protocols 
					for USM based on the SHA-2 hash
					functions <xref target="SHA"/>. The
					use of the HMAC-SHA2 authentication protocols requires the usage of the objects defined
					in the SNMP-USER-BASED-SM-MIB. </t>
			</section>

			<section title="Relationship to SNMP-FRAMEWORK-MIB">
				<t>RFC 3411 <xref target="RFC3411"/> specifies the SNMP-FRAMEWORK-MIB, which defines 
					a subtree snmpAuthProtocols for SNMP authentication protocols. The following 
					MIB module defines new authentication protocols in the snmpAuthProtocols subtree. 
				</t>
			</section>

			<section title="MIB Modules Required for IMPORTS">
				<t>The following MIB module IMPORTS definitions from SNMPv2-SMI <xref target="RFC2578"/> and SNMP-FRAMEWORK-MIB <xref target="RFC3411"/>.</t>
			</section>
		</section>

		<section anchor="definitions" title="Definitions">

			<figure><artwork>
<![CDATA[
SNMP-USM-HMAC-SHA2-MIB DEFINITIONS ::= BEGIN
    IMPORTS
        MODULE-IDENTITY, OBJECT-IDENTITY,
    snmpModules             FROM SNMPv2-SMI          -- [RFC2578]
    snmpAuthProtocols       FROM SNMP-FRAMEWORK-MIB; -- [RFC3411]

snmpUsmHmacSha2MIB MODULE-IDENTITY
    LAST-UPDATED    "201508130000Z"       -- 13 August 2015, midnight
    ORGANIZATION    "SNMPv3 Working Group" 
    CONTACT-INFO    "WG email: OPSAWG@ietf.org
                    Subscribe: 
                        https://www.ietf.org/mailman/listinfo/opsawg
                    Editor:    Johannes Merkle
                               secunet Security Networks
                    Postal:    Mergenthaler Allee 77
                               D-65760 Eschborn
                               Germany
                    Phone:     +49 20154543091
                    Email:     johannes.merkle@secunet.com

                    Co-Editor: Manfred Lochter
                               Bundesamt fuer Sicherheit in der 
                               Informationstechnik (BSI)
                    Postal:    Postfach 200363
                               D-53133 Bonn
                               Germany
                    Phone:     +49 228 9582 5643
                    Email:     manfred.lochter@bsi.bund.de"

    DESCRIPTION     "Definitions of Object Identities needed
                    for the use of HMAC-SHA2 by SNMP's User-based
                    Security Model.

          Copyright (c) 2015 IETF Trust and the persons identified
          as authors of the code.  All rights reserved.

          Redistribution and use in source and binary forms, with
          or without modification, is permitted pursuant to, and
          subject to the license terms contained in, the Simplified
          BSD License set forth in Section 4.c of the IETF Trust's
          Legal Provisions Relating to IETF Documents
          (http://trustee.ietf.org/license-info)."

    REVISION    "201508130000Z"       -- 13 August 2015, midnight
    DESCRIPTION "Initial version, published as RFC 7630"
::= { snmpModules 235 }        

usmHMAC128SHA224AuthProtocol OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION "The Authentication Protocol 
                usmHMAC128SHA224AuthProtocol uses HMAC-SHA-224 and 
                truncates output to 128 bits."
    REFERENCE   "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC:
                Keyed-Hashing for Message Authentication, RFC 2104.
                - National Institute of Standards and Technology,
                Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
    ::= { snmpAuthProtocols 4 }

usmHMAC192SHA256AuthProtocol OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION "The Authentication Protocol 
                usmHMAC192SHA256AuthProtocol uses HMAC-SHA-256 and 
                truncates output to 192 bits."
    REFERENCE   "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC:
                Keyed-Hashing for Message Authentication, RFC 2104.
                - National Institute of Standards and Technology,
                Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
    ::= { snmpAuthProtocols 5 }

usmHMAC256SHA384AuthProtocol OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION "The Authentication Protocol 
                usmHMAC256SHA384AuthProtocol uses HMAC-SHA-384 and 
                truncates output to 256 bits."
    REFERENCE   "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC:
                Keyed-Hashing for Message Authentication, RFC 2104.
                - National Institute of Standards and Technology,
                Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
    ::= { snmpAuthProtocols 6 }

usmHMAC384SHA512AuthProtocol OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION "The Authentication Protocol 
                usmHMAC384SHA512AuthProtocol uses HMAC-SHA-512 and 
                truncates output to 384 bits."
    REFERENCE   "- Krawczyk, H., Bellare, M., and R. Canetti, HMAC:
                Keyed-Hashing for Message Authentication, RFC 2104.
                - National Institute of Standards and Technology,
                Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
    ::= { snmpAuthProtocols 7 }

END
]]></artwork>
			</figure>
		</section>


<!-- [rfced] The Security Considerations section of this
document does not contain text that matches this page:
https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security

Please review and let us know if this is intentional.

[jm] This is intentional and was agreed upon in opsawg.
-->

		<section title="Security Considerations">
			<section title="Use of the HMAC-SHA-2 Authentication Protocols in USM">

				<t>The security considerations of RFC 3414
				<xref target="RFC3414"/> also apply to
					the HMAC-SHA-2 authentication protocols defined in this document.</t>
			</section>
			<section title="Cryptographic Strength of the Authentication Protocols">

				<t>At the time of publication of this document, all of the HMAC-SHA-2 authentication protocols provide a
					very high level of security.
					The security of each HMAC-SHA-2 authentication protocol depends on the parameters
					used in the corresponding HMAC computation, which are the length of the key (if the key has maximum entropy), the size of the
					hash function's internal state, and the length of the truncated MAC. For the HMAC-SHA-2
					authentication protocols, these values are as follows (values are given in bits). </t>

				<texttable anchor='Parameters' title='HMAC Parameters of the HMAC-SHA-2 Authentication Protocols'>
					<preamble/>

					<ttcol align='center'>Protocol</ttcol>
					<ttcol align='center'>Key length</ttcol>
					<ttcol align='center'>Size of internal state</ttcol>
					<ttcol align='center'>MAC length</ttcol>

					<c>usmHMAC128SHA224AuthProtocol</c>
					<c>224</c>
					<c>256</c>
					<c>128</c>

					<c>usmHMAC192SHA256AuthProtocol</c>
					<c>256</c>
					<c>256</c>
					<c>192</c>

					<c>usmHMAC256SHA384AuthProtocol</c>
					<c>384</c>
					<c>512</c>
					<c>256</c>

					<c>usmHMAC384SHA512AuthProtocol</c>
					<c>512</c>
					<c>512</c>
					<c>384</c>

					<postamble/>
				</texttable>

				<t>The security of the HMAC scales with both the key length and the size of the
					internal state: longer keys render key guessing attacks more difficult,
					and a larger internal state decreases the success probability of MAC
					forgeries based on internal collisions of the hash function.</t>

				<t>The role of the truncated output length is more complicated:
					according to <xref target="BCK"/>, there is a trade-off in that
					<list style="empty">
					<t>by outputting less bits the attacker has less bits to
					predict in a MAC forgery but, on the other hand, the attacker also learns less about
					the output of the compression function from seeing the authentication tags computed
					by legitimate parties.</t></list></t>
					<t>Thus, truncation weakens the HMAC against forgery
					by guessing but, at the same time, strengthens it against chosen message attacks
					aiming at MAC forgery based on internal collisions or at key guessing.
					RFC 2104 and <xref target="BCK"/> allow truncation
					to any length that is not less than half the size of the internal state. </t>

				<t>Further discussion of the security of the HMAC construction is given
					in RFC 2104.</t>
			</section>
			<section title="Derivation of Keys from Passwords">
				<t> If secret keys to be used for HMAC-SHA-2 authentication protocols are derived from 
					passwords, the derivation SHOULD be performed using the password-to-key algorithm 
					from Appendix A.1 of RFC 3414 with MD5 being replaced by the SHA-2 hash function H
					used in the HMAC-SHA-2 authentication protocol. Specifically, the password is converted 
					into the required secret key by the following steps: </t>
				<t>
					<list style="symbols"> 
						<t>forming a string of length
						1,048,576 octets by repeating the
							value of the password as often as necessary, truncating
							accordingly, and using the resulting string as the input to the
							hash function H. The resulting digest, termed "digest1", is used in the next step.</t>
						
							<t>forming a second string by concatenating digest1, the SNMP
							engine's snmpEngineID value, and digest1.  This string is used
							as input to the hash function H.</t>
					</list>
				</t>

			</section>
			<section title="Access to the SNMP-USM-HMAC-SHA2-MIB">

				<t>The SNMP-USM-HMAC-SHA2-MIB module defines OBJECT IDENTIFIER values for use in other MIB modules. It does not define any objects that
					can be accessed. As such, the SNMP-USM-HMAC-SHA2-MIB does not, by itself, have any effect on the security of the Internet.</t>

				<t>The values defined in this module are expected to be used with the usmUserTable defined in the SNMP-USER-BASED-SM-MIB <xref target="RFC3414"/>. The
					considerations in Section 11.5 of
					RFC 3414 should be taken into account.</t>	
			</section>
		</section>

		<section title="IANA Considerations">
		
<!-- 
[jm] We have detected that the first assignment made by IANA is probably not correct and have requested IANA to change it. 
-->

			<t>IANA has assigned an OID for the MIB as follows.</t>
			<texttable anchor='OID-MIB' title='OID of MIB'>
				<preamble/>
				<ttcol align='center'>Descriptor</ttcol>
				<ttcol align='center'>OBJECT IDENTIFIER value</ttcol>
				<c>snmpUsmHmacSha2MIB</c>
				<c>{ snmpModules 235 }</c>
				<postamble/>
			</texttable>


			<t>Furthermore, IANA has assigned a value in the SnmpAuthProtocols registry
				for each of the following protocols.</t>
			<texttable anchor='OID-Protocols' title='Code Points Assigned to HMAC-SHA-2 Authentication Protocols'>
				<preamble/>

				<ttcol align='center'>Description</ttcol>
				<ttcol align='center'>Value</ttcol>
				<ttcol align='center'>Reference</ttcol>

				<c>usmHMAC128SHA224AuthProtocol</c>
				<c>4</c>
				<c>RFC 7630</c>

				<c>usmHMAC192SHA256AuthProtocol</c>
				<c>5</c>
				<c>RFC 7630</c>

				<c>usmHMAC256SHA384AuthProtocol</c>
				<c>6</c>
				<c>RFC 7630</c>

				<c>usmHMAC384SHA512AuthProtocol</c>
				<c>7</c>
				<c>RFC 7630</c>

				<postamble/>
			</texttable>

		</section>


	</middle>

	<back>



		<references title="Normative References">

		  <?rfc include="reference.RFC.2104" ?>
		  <?rfc include="reference.RFC.2119" ?>
		  <?rfc include="reference.RFC.2578" ?>
		  <?rfc include="reference.RFC.2579" ?>
		  <?rfc include="reference.RFC.2580" ?>
		  <?rfc include="reference.RFC.3414" ?>
		  <?rfc include="reference.RFC.6234" ?>

		  <reference anchor="SHA" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">
				<front>
					<title>Secure Hash Standard (SHS)</title>
					<author>
						<organization>National Institute of Standards and Technology</organization>
					</author>
					<date month="March" year="2012" />
				</front>
				<seriesInfo name="FIPS" value="PUB 180-4" />
				<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
			</reference>
			
		</references>

		<references title="Informative References">
		  
		  <?rfc include="reference.RFC.1321" ?>
		  <?rfc include="reference.RFC.3410" ?>
		  <?rfc include="reference.RFC.3411" ?>
		  <?rfc include="reference.RFC.3417" ?>

			<reference anchor="BCK">
				<front>
					<title>Keyed Hash Functions for Message Authentication</title>
					<author initials="M" surname="Bellare">
						<organization/>
					</author>
					<author initials="R" surname="Canetti">
						<organization/>
					</author>
					<author initials="H" surname="Krawczyk">
						<organization/>
					</author>
					<date year="1996" />
				</front>
				<seriesInfo name="Advances in Cryptology - CRYPTO" value="96" />
				<seriesInfo name="Lecture Notes in Computer Science" value="1109" />
				<seriesInfo name="Springer-Verlag"
					    value="Berlin Heidelberg" />
				<seriesInfo name="DOI" value="10.1007/3-540-68697-5_1"/>
			</reference>

		</references>


	</back>
</rfc>
