One document matched: draft-ietf-bfd-hmac-sha-05.xml
<?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="std" docName="draft-ietf-bfd-hmac-sha-05" ipr="trust200902">
<front>
<title abbrev="BFD HMAC-SHA">Authenticating BFD using HMAC-SHA-2
procedures</title>
<author fullname="Dacheng Zhang" initials="D." surname="Zhang">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<email>zhangdacheng@huawei.com</email>
</address>
</author>
<author fullname="Manav Bhatia " initials="M." surname="Bhatia ">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city>Bangalore</city>
<code>560045</code>
<country>India</country>
</postal>
<email>manav.bhatia@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Vishwas Manral " initials="V. " surname="Manral ">
<organization>Ionos Networks</organization>
<address>
<postal>
<street></street>
<city></city>
<region>CA</region>
<code></code>
<country>USA</country>
</postal>
<email>vishwas@ionosnetworks.com</email>
</address>
</author>
<author fullname="Mahesh Jethanandani" initials="M."
surname="Jethanandani">
<organization>Ciena Corporation</organization>
<address>
<postal>
<street>3939 North 1st Street</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 (408) 904-2160</phone>
<facsimile></facsimile>
<email>mjethanandani@gmail.com</email>
<uri></uri>
</address>
</author>
<date day="24" month="May" year="2014" />
<abstract>
<t>This document describes the mechanism to authenticate Bidirectional
Forwarding Detection (BFD) protocol packets using Hashed Message
Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512
algorithms. The described mechanism uses the Generic Cryptographic
Authentication and Generic Meticulous Cryptographic Authentication
sections to carry the authentication data. This document updates, but
does not supersede, the cryptographic authentication mechanism specified
in RFC 5880.</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 mechanisms specified in <xref
target="RFC5880">BFD</xref> defines <xref target="RFC1321">MD5
Message-Digest Algorithm </xref> and Secure Hash Algorithm (SHA-1)
algorithms to authenticate BFD packets. The recent escalating series of
attacks on MD5 and SHA-1 <xref target="SHA-1-attack1"></xref> <xref
target="SHA-1-attack2"></xref> raise concerns about their remaining
useful lifetime as outlined in <xref target="RFC6151">Updated Security
Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm
</xref> and <xref target="RFC6194">Security Considerations for the SHA-0
and SHA-1 Message-Digest Algorithm </xref>.</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 BFD 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>. <xref
target="FIPS-180-2"></xref> 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"></xref>.</t>
<t>It is believed that the HMAC algorithms defined in <xref
target="RFC2104">HMAC: Keyed-Hashing for Message Authentication </xref>
is mathematically identical to their counterparts in <xref
target="FIPS-198"></xref> and it is also believed that algorithms in
<xref target="RFC6234">US Secure Hash Algorithms </xref> are
mathematically identical to those defined in <xref
target="FIPS-180-2"></xref>.</t>
<t>It should be noted that the collision attacks currently known against
SHA-1 do not apply when SHA-1 is used in the HMAC construction. NIST
will be supporting HMAC-SHA-1 even after 2010 <xref
target="NIST-HMAC-SHA"></xref> , whereas it would be dropping support
for SHA-1 in digital signatures.</t>
<t><xref target="I-D.ietf-bfd-generic-crypto-auth">BFD Generic
Cryptographic Authentication </xref> defines new authentication types -
Generic Cryptographic Authentication (TBD1) and Generic Meticulous
Cryptographic Authentication (TBD2) that can be used for carrying the
authentication digests defined in this document. Also please refer to
this document for the procedures at the sending and the receiving
side.</t>
<t>Implementations of this specification must include support for at
least HMAC-SHA-256 and may include support for either of HMAC-SHA-384 or
HMAC-SHA-512.</t>
</section>
<section title="Cryptographic Aspects ">
<t>In the algorithm description below, the following nomenclature, which
is consistent with <xref target="FIPS-198"></xref>, is used.</t>
<t>H is the specific hashing algorithm (e.g. SHA-256).</t>
<t>K is the password for the BFD packet.</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. For SHA-1 and
SHA-256 B is equal to 64. For SHA-384 and SHA-512 B is equal to 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 0x878FE1F3 repeated (L/4) times.</t>
<section title="Preperation of the Key">
<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>
</section>
<section title="First Hash">
<t>First, the Authentication Data field in the Generic Authentication
Section is filled with the value of Apad and the Authentication Type
field is set to TBD1 or TBD2 depending upon which Authentication Type
being used. The Sequence Number field MUST be set to
bfd.XmitAuthSeq.</t>
<t>Then, a first hash, also known as the inner hash, is computed as
follows:</t>
<t>First-Hash = H(Ko XOR Ipad || (BFD Packet))</t>
</section>
<section title="Second Hash 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>
</section>
<section title="Result">
<t>The resultant Second-Hash becomes the Authentication Data that is
sent in the Authentication Data field of the BFD Authentication
Section. The length of the Authentication Data field is always
identical to the message digest size of the specific hash function H
that is being used.</t>
<t>This also means that the use of hash functions with larger output
sizes will also increase the size of BFD Packet as transmitted on the
wire.</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>The approach described in this document enhances the security of the
BFD protocol by adding, to the existing BFD cryptographic authentication
methods, support for the SHA-2 algorithms defined in the NIST Secure
Hash Standard (SHS) using the HMAC mode. However, the confidentiality
protection for BFD packets is out of scope of this work .</t>
<t>Because all of the currently specified algorithms use symmetric
cryptography, one cannot authenticate precisely which BFD device sent a
given packet. However, one can authenticate that the sender knew the BFD
Security Association (including the BFD SA's parameters) currently in
use.</t>
<t>To enhance system security, the applied keys should be changed
periodically and implementations SHOULD be able to store and use more
than one key at the same time. The quality of the security provided by
the cryptographic authentication option depends completely on the
strength of the cryptographic algorithm and cryptographic mode in use,
the strength of the key being used, and the correct implementation of
the security mechanism in all communicating BFD implementations.
Accordingly, the use of high assurance development methods is
recommended. It also requires that all parties maintain the secrecy of
the shared secret key. <xref target="RFC4086">Randomness Requirements
for Security </xref> provides guidance on methods for generating
cryptographically random bits.</t>
<t>The value Apad is used here primarily for consistency with IETF
specifications for HMAC-SHA authentication for RIPv2 <xref
target="RFC4822">RIPv2 Cryptographic Authentication </xref>, IS-IS <xref
target="RFC5310">IS-IS Generic Cryptographic Authentication </xref> and
OSPFv2 <xref target="RFC5709">OSPFv2 HMAC-SHA Cryptographic
Authentication</xref>.</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.6039'?>
<?rfc include='reference.I-D.ietf-bfd-generic-crypto-auth'?>
<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'?>
<reference anchor="MD5-attack">
<front>
<title>Collisions for Hash Functions MD4, MD5, HAVAL-128 and
RIPEMD</title>
<author initials="X" surname="Wang">
<organization></organization>
</author>
<author fullname="" initials="D." surname="Feng">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="X." surname="Lai">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="H." surname="Yu">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></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></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></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></organization>
</author>
<author initials="Y." surname="Yin">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="H." surname="Yu">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></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></organization>
</author>
<author initials="A." surname="Yao">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="F." surname="Yao">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date year="2005" />
</front>
</reference>
<?rfc include='reference.RFC.2104'?>
<?rfc include='reference.RFC.5880'?>
<?rfc include='reference.RFC.4086'?>
<?rfc include='reference.RFC.4822'?>
<?rfc include='reference.RFC.5310'?>
<?rfc include='reference.RFC.5709'?>
<?rfc include='reference.RFC.1321'?>
<?rfc include='reference.RFC.6234'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:07:38 |