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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY rfc2119 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> 
<!ENTITY rfc2223 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2223.xml"> 
<!ENTITY rfc2578 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml"> 
<!ENTITY rfc2579 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml"> 
<!ENTITY rfc2580 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml"> 
<!ENTITY rfc2629 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml"> 
<!ENTITY rfc3410 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml"> 
<!ENTITY rfc4181 SYSTEM 
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml"> ]> 
<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc compact="yes"?> <?rfc 
subcompact="no"?> <?rfc strict="no"?> <?rfc rfcedstyle="yes"?> <?rfc 
comments="yes"?> <?rfc inline="yes"?> 

<!-- used to be ipr="trust200902" --> <rfc obsoletes="7630" 
category="std" docName="draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-04" 
ipr="trust200902"> <front> <!-- Enter the full document title and an 
abbreviated version to use in the page header. --> 

<title abbrev="HMAC-SHA-2_Auth_USM_new">HMAC-SHA-2 Authentication 
Protocols in USM for SNMPv3</title> 

<!-- copy the author block as many times as needed, one for each 
author.--> 

<!-- If the author is acting as editor, use the <role=editor> 
attribute--> 

<!-- see RFC2223 for guidelines regarding author names --> 

<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 year="2016" /> <area>Security Area</area> 
<workgroup>OPSAWG</workgroup> <keyword>Internet-Draft</keyword> 
<keyword>Network Management</keyword> 

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

<abstract> <t> This document specifies several authentication protocols 
based on the SHA-2 hash functions for the User-based Security Model 
(USM) for SNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which 
the MIB MODULE-IDENTITY value was incorrectly specified.</t></abstract> 
</front> 

<middle> 



<section title="Introduction"> 

<t> Within the Architecture for describing Simple Network Management 
Protocol (SNMP) Management Frameworks <xref target="RFC3411"/>, the 
User-based Security Model (USM) <xref target="RFC3414"/> for SNMPv3 is 
defined as a Security Subsystem within an SNMP engine. 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.</t> 

<t>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&nbhy;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> 

<t>This document obsoletes RFC 7630, in which the MIB MODULE-IDENTITY 
value was incorrectly specified.</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 
<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 <xref 
target="RFC2578"></xref>, <xref target="RFC2579"> </xref>, and <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> 
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 <xref target="RFC6234"/>) in the HMAC mode (described 
in <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&nbhy;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 specified 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 <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 <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> <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, mib-2 FROM SNMPv2-SMI 
-- [RFC2578] snmpAuthProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411] 

snmpUsmHmacSha2MIB MODULE-IDENTITY LAST-UPDATED "201510210000Z" -- 21 
October 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 "201510210000Z" -- 21 October 2015, midnight DESCRIPTION 
"Version correcting the MODULE-IDENTITY value, published as RFC TBD" 
-- RFC Ed.: replace TBD with actual RFC number & remove this line 
REVISION "201508130000Z" -- 13 August 2015, midnight DESCRIPTION 
"Initial version, published as RFC 7630" ::= { mib-2 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> 

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

<t>The security considerations of <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"> <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>{ mib-2 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 XXX</c> 

<c>usmHMAC192SHA256AuthProtocol</c> <c>5</c> <c>RFC XXX</c> 

<c>usmHMAC256SHA384AuthProtocol</c> <c>6</c> <c>RFC XXX</c> 

<c>usmHMAC384SHA512AuthProtocol</c> <c>7</c> <c>RFC XXX</c> 

<postamble/> </texttable> 

<t> -- RFC Ed.: replace XXX with actual RFC number and remove this 
line</t> 

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

