One document matched: draft-ietf-bfd-optimizing-authentication-01.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-optimizing-authentication-01"
ipr="trust200902">
<front>
<title abbrev="BFD Authentication">Optimizing BFD Authentication</title>
<author fullname="Mahesh Jethanandani" initials="M."
surname="Jethanandani">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 (408) 526-8763</phone>
<facsimile/>
<email>mjethanandani@gmail.com</email>
<uri/>
</address>
</author>
<author fullname="Ashesh Mishra" initials="A" surname="Mishra">
<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/>
<email>mishra.ashesh@gmail.com</email>
</address>
</author>
<author fullname="Ankur Saxena" initials="A" surname="Saxena">
<organization>Ciena Corporation</organization>
<address>
<postal>
<street>3939 N 1st Street</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone/>
<facsimile/>
<email>ankurpsaxena@gmail.com</email>
<uri/>
</address>
</author>
<author fullname="Manav Bhatia " initials="M." surname="Bhatia ">
<organization>Ionos Networks</organization>
<address>
<postal>
<street/>
<city>Bangalore</city>
<code/>
<country>India</country>
</postal>
<email>manav@ionosnetworks.com</email>
</address>
</author>
<date day="15" month="February" year="2016"/>
<abstract>
<t>This document describes an optimization to BFD Authentication as
described in Section 6.7 of BFD [RFC5880].</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>Authenticating every <xref target="RFC5880">BFD</xref> packet with a
Simple Password, or with a <xref target="RFC1321">MD5 Message-Digest
Algorithm </xref> , or Secure Hash Algorithm (SHA-1) algorithms is
computationally intensive process, making it difficult if not impossible
to authenticate every packet - particularly at faster rates. Also, 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 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>. If replaced by stronger algorithms,
the computational overhead, will make the task of authenticating every
packet even more difficult to achieve.</t>
<t>This document proposes that only BFD frames that signal a state
change in BFD be authenticated. Rest of the frames can be transmitted
and received without authentication enabled. Most frames that are
transmitted and received have no state change associated with them.
Limiting authentication to frames that affect a BFD session state allows
more sessions to be supported for authentication. Moreover, most BFD
frames that signal a state change are generally transmitted at a slower
interval of 1s leaving enough time to compute the hash.</t>
<t>Section 2 talks about the changes to authentication mode as described
in <xref target="RFC5880">BFD</xref>.</t>
</section>
<section title="Authentication Mode ">
<t>The cryptographic authentication mechanisms specified in <xref
target="RFC5880">BFD</xref> describes enabling and disabling of
authentication as a one time operation. As a security precaution, it
mentions that authentication state be allowed to change at most once.
Once enabled, every packet must have Authentication Bit set and the
associated Authentication TLV appended. In addition, it states that an
implementation SHOULD NOT allow the authentication state to be changed
based on the receipt of a BFD Control packet.</t>
<t>This document proposes that the authentication mode be modified to be
enabled on demand. Instead of authenticating every packet, BFD peers
decide which frames need to be authenticated, and authenticate only
those frames. For example, the two ends can decide that BFD frames that
indicate a state change should be authenticated and enable
authentication on those frames only. If the two ends have not previously
negotiated which frames they will transmit or receive with
authentication enabled, then the BFD session will fail to come up,
because at least one end will expect every frame to be authenticated.
The state changes for which authentication is being suggested
include:</t>
<t><figure align="center" title="Optimized Authentication Map">
<artwork><![CDATA[ Read : On state change from <column> to <row>
Auth : Authenticate frame
NULL : No Authentication. Use NULL AUTH TLV.
n/a : Invalid state transition.
Select : Most frames NULL AUTH. Selective (periodic)
frames authenticated.
+--------+--------+--------+--------+--------+--------+
| | DOWN | INIT | UP | POLL | DEMAND |
+--------+--------+--------+--------+--------+--------+
| DOWN | NULL | Auth | Auth | Auth | Auth |
+--------+--------+--------+--------+--------+--------+
| INIT | Auth | NULL | Auth | Auth | Auth |
+--------+--------+--------+--------+--------+--------+
| UP | Auth | n/a | Select | Auth | Auth |
+--------+--------+--------+--------+--------+--------+
| POLL | Auth | n/a | Auth | Auth | Auth |
+--------+--------+--------+--------+--------+--------+
| DEMAND | Auth | Auth | Auth | Auth | Auth |
+--------+--------+--------+--------+--------+--------+
]]></artwork>
</figure></t>
<t>All frames already carry the sequence number. The NULL AUTH frames
MUST contain the TLV specified in Section 3. This enables a
monotonically increasing sequence number to be carried in each frame,
and prevents man-in-the-middle from capturing and replaying the same
frame again. Since all frames still carry a sequence number, the logic
for sequence number maintenance remains unchanged from <xref
target="RFC5880"/>. </t>
<t>Most frames transmitted on a BFD session are BFD CC UP frames.
Authenticating a small subset of these frames (one per configured period)
significantly reduces the computational demand for the system while
maintaining security of the session across the configured authentication
periods. The configuration of the periodic authentication interval for
BFD CC UP frames is an open issue. </t>
</section>
<section title="NULL Auth TLV">
<t>This section describes a new Authentication TLV as: <figure
align="center" title="NULL Auth TLV">
<artwork><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> where:</t>
<t>Auth Type: The Authentication Type, which in this case is 0 (NULL
Auth TL)</t>
<t>Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes</t>
<t>Auth Key ID: The authentication key ID in use for this packet. Must
be set to zero. </t>
<t>Reserved: The authentication key ID in use for this packet. This
allows multiple keys to be active simultaneously.</t>
<t>Sequence Number: The sequence number for this packet. This value is
incremented for each successive packet transmitted for a session. This
provides protection against replay attacks. Must use the same sequence
number counter as the authenticated frames. </t>
<t>The NULL Auth TLV must be used for all frames that are not
authenticated. This protects against replay-attacks by allowing the
session to maintain an incrementing sequence number for all frames
(authenticated and un-authenticated). </t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to assign a new Auth Type for the NULL Auth
TLV.</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 ability to
authentication a BFD session by taking away the onerous requirement that
every frame be authenticated. By authenticating frames that affect the
state of the session, the security of the BFD session is maintained. As
such this document does not change the security considerations for
BFD.</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'?>
<?rfc include='reference.I-D.ashesh-bfd-stability'?>
<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/>
</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.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 14:16:53 |