One document matched: draft-mahesh-bfd-authentication-00.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-mahesh-bfd-authentication-00"
     ipr="trust200902">
  <front>
    <title abbrev="BFD Authentication">Optimizing BFD Authentication</title>

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

        <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>+1 (408) 904-2114</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 North 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="13" month="February" year="2015"/>

    <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> and Secure Hash Algorithm (SHA-1) algorithms is
      computationally intensive process, making it difficult if not impossible
      to authenticate every packet - particularly at faster intervals. In
      addition, 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 requirement of a stronger algorithms 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. The rest of the frames can be
      transmitted and received without authentication enabled. Bulk of the
      frames that are transmitted and received have no state change associated
      with them. Limiting authentication to frames that affect a BFD session
      state allows for 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 turned on, the document talks about every packet being enabled with
      Authentication bit and payload. 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 every packet being authenticated, the two
      ends can 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.</t>
    </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 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'?>

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