Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011


   Network Working Group                                   Manav Bhatia
   Internet Draft                                        Alcatel-Lucent
   Intended Status: Proposed Standard                    Vishwas Manral
   Expires: August 2011                                     IP Infusion
                                                       January 10, 2011

                 BFD Generic Cryptographic Authentication

                    draft-bhatia-bfd-crypto-auth-03.txt

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 10, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abstract

   This document proposes an extension for Bidirectional Forwarding
   Detection (BFD) to allow the use of any cryptographic authentication
   algorithm in addition to the already documented authentication
   schemes, described in the base specification.



Bhatia and Manral         Expires August 2011                [Page 1]


Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011


   Although this document has been written specifically to introduce two
   new Authentication types it describes how BFD can use National
   Institute of Standards and Technology (NIST) Secure Hash Standard
   family of algorithms (SHS) to authenticate the control packets, the
   method described in this document is generic and can be used to
   extend BFD to support any cryptographic hash function in the future.

Conventions used in this document

   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 RFC 2119. [RFC2119]

   Contents

   1. Introduction...................................................2
   2. BFD Security Association.......................................4
   3. Authentication Procedures......................................5
      3.1 Cryptographic Authentication and Meticulous Cryptographic
      Authentication.................................................5
      3.2 Packet Encoding............................................5
      3.3 Cryptographic Aspects......................................6
      3.4 Procedures at the Sending Side.............................7
      3.5 Procedure at the Receiving Side............................8
   4. Security Considerations........................................9
   5. IANA Considerations...........................................10
   6. References....................................................10
      6.1 Normative References......................................10
      6.2 Informative References....................................10
   7. Author's Addresses............................................11


1. Introduction

   Bidirectional Forwarding Detection (BFD) [RFC5880] specification
   includes five different types of authentication schemes: Simple
   Password, Keyed MD5 [RFC1321], Meticulous Keyed MD5, Keyed SHA-1 and
   Meticulous SHA-1. In the simple password scheme of authentication,
   the passwords are exchanged in the clear text on the network and
   anyone with physical access to the network can learn the password and
   compromise the security of the BFD domain.

   In Keyed MD5 and Meticulous Keyed MD5, the BFD routers share a secret
   key which is used to generate a keyed MD5 digest for each packet and
   a monotonically increasing sequence number scheme is used to prevent
   replay attacks.

   This isnt good enough as there have been recent reports about attacks
   on MD5 which raises concerns about the remaining useful lifetime of


Bhatia and Manral         Expires August 2011                [Page 2]


Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011


   this scheme. Specifically, the researchers have been able to develop
   algorithms that can compute hash collisions for some applications of
   MD5 [MD5-attack] [Dobb96a, Dobb96b].

   It should however be noted that these attacks may not necessarily
   result in direct vulnerabilities in Keyed-MD5 as used in BFD
   authentication purposes, because the colliding message may not
   necessarily be a syntactically correct protocol packet. However,
   there is a need felt to move away from MD5 towards more complex and
   difficult to break hash algorithms.

   In Keyed SHA-1 and Meticulous SHA-1, the BFD routers share a secret
   key which is used to generate a keyed SHA-1 digest for each packet
   and a monotonically increasing sequence number scheme is used to
   prevent replay attacks.

   Like MD5 there have been reports of attacks on SHA-1 [SHA-1-attack1]
   [SHA-1-attack2]. Such attacks do not mean that all the protocols
   using SHA-1 for authentication are at risk. However, it does mean
   that SHA-1 should be replaced as soon as possible and should not be
   used for new applications.

   It should be noted that if SHA-1 is used in the Hashed Message
   Authentication Code (HMAC) [RFC2104] construction then collision
   attacks currently known against SHA-1 do not apply. The new attacks
   on SHA-1 have no impact on the security of HMAC-SHA-1.

   HMAC can be used, without modifying any hash function, for
   calculating and verifying the message authentication values. It
   verifies both the data integrity and the authenticity of a message.

   This document proposes two new authentication types - the
   cryptographic authentication (CRYPTO_AUTH) and the meticulous
   cryptographic authentication (MET_ CRYPTO_AUTH). These can be used to
   specify any authentication algorithm for authenticating and verifying
   the BFD packets.

   By definition, HMAC requires a cryptographic hash function. We
   propose to use any one of Secure Hash Algorithms (SHA) defined in US
   NIST Secure Hash Standard (SHS) [FIPS-180-3]. [FIPS-180-3] includes
   SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. The HMAC
   authentication mode defined in NIST FIPS 198 is used [FIPS-198].

   It is believed that [RFC2104] is mathematically identical to
   [FIPS-198] and it is also believed that algorithms in [RFC4634] are
   mathematically identical to [FIPS-180-3].

   Of the above, implementations of this specification MUST include
   support for at least HMAC-SHA-256 and SHOULD include support for


Bhatia and Manral         Expires August 2011                [Page 3]


Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011


   HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or
   HMAC-SHA-512.

   An implementation of this specification MUST allow network operators
   to configure ANY authentication algorithm supported by that
   implementation for use with ANY given KeyID value that is configured
   into that BFD router.

2. BFD Security Association

   The BFD protocol does not include an in-band mechanism to create or
   manage BFD Security Associations (BFD SA). A BFD SA contains a set of
   shared parameters between any two legitimate BFD routers.

   Parameters associated with a BFD SA:

   O Authentication Key Identifier (Key ID) : This is a two octet
   unsigned integer used to uniquely identify the BFD SA, as manually
   configured by the network operator (or, in the future, possibly by
   some key management protocol specified by the IETF). The receiver
   determines the active SA by looking at this field in the incoming
   packet. The sender puts this Key ID in the BFD packet based on the
   active configuration.

   Using Key IDs makes changing keys while maintaining protocol
   operation convenient. Each key ID specifies two independent parts,
   the authentication protocol and the authentication key, as explained
   below. Normally, an implementation would allow the network operator
   to configure a set of keys in a key chain, with each key in the chain
   having fixed lifetime. The actual operation of these mechanisms is
   outside the scope of this document.

   Note that each Key ID can indicate a key with a different
   authentication protocol. This allows multiple authentication
   mechanisms to be used at various times without disrupting BFD
   sessions, including the introduction of new authentication
   mechanisms.

   o Authentication Algorithm : This indicates the authentication
   algorithm to be used with the BFD SA. This information SHOULD never
   be sent in cleartext over the wire. At present, the following values
   are possible: Keyed MD5, Keyed SHA-1, HMAC-SHA-1, HMAC-SHA-256, HMAC-
   SHA-384 and HMAC-SHA-512.

   o Authentication Key : This indicates the cryptographic key
   associated with this BFD SA. The length of this key is variable and
   depends upon the authentication algorithm specified by the BFD SA.
   Operators MUST ensure that this is never sent over the network in
   clear-text via any protocol. Care should also be taken to ensure that


Bhatia and Manral         Expires August 2011                [Page 4]


Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011


   the selected key is unpredictable, avoiding any keys known to be weak
   for the algorithm in use. [RFC4086] contains helpful information on
   both key generation techniques and cryptographic randomness. This is
   noted as "K" in section 3.3 below.

3. Authentication Procedures

3.1 Cryptographic Authentication and Meticulous Cryptographic
    Authentication

   The Authentication section is only present in the BFD packet if the
   Authentication Present (A) bit is set in the header. The Auth Type in
   the Authentication section is set to 6 to indicate the Cryptographic
   Authentication is in use, and is set to 7, to indicate that the
   meticulous cryptographic authentication is in use.

   Both the authentication types use a monotonically increasing sequence
   number to protect the BFD session against reply attacks. The only
   difference between the two types is that the sequence number is
   occasionally incremented in the Cryptographic Authentication mode, as
   against the Meticulous Cryptographic Authentication mode, where it is
   incremented on every packet.

   As a result of this a replay attack is possible till the next
   sequence number is sent in the Cryptographic Authentication scheme.

3.2 Packet Encoding

   A new authentication type, 6 or 7, indicating the cryptographic
   authentication mechanism in use, is inserted in the first octet of
   Authentication Section of the BFD control packet.

   If the Authentication Present (A) bit is set in the header, and the
   Authentication Type field contains 6 (Cryptographic Authentication)
   or 7 (Meticulous Cryptographic Authentication), the Authentication
   Section has the following format:

        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           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Sequence Number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                  Authentication Data (Variable)               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Bhatia and Manral         Expires August 2011                [Page 5]


Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011



   Auth Type

   The Authentication Type, which in this case is 6 (Cryptographic
   Authentication) or 7 (Meticulous Cryptographic Authentication).

   Auth Len

   Length of the Authentication Section.

   Auth Key ID

   The Authentication Key ID in use for this packet. This allows
   multiple keys to be active simultaneously.

   Sequence Number

   The Sequence Number for this packet. For Cryptographic Authentication
   this value is incremented occasionally.  For Meticulous Cryptographic
   Authentication, this value is incremented for each successive packet
   transmitted for a session.

   Authentication Data

   This field carries the digest computed by whatever Cryptographic
   Authentication algorithm is being used to authenticate the BFD
   control packet.

3.3 Cryptographic Aspects

   In the algorithm description below, the following nomenclature, which
   is consistent with [FIPS-198], is used:

   H is the specific hashing algorithm (e.g. SHA-256).
   K is the password for the BFD packet.
   Ko is the cryptographic key used with the hash algorithm.

   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 == 64
        For SHA-384 and SHA-512: B == 128
   L is the length of the hash, measured in octets rather than bits.

   XOR  is the exclusive-or operation.
   Opad is the hexadecimal value 0x5c repeated B times.
   Ipad is the hexadecimal value 0x36 repeated B times.
   Apad is the hexadecimal value 0x878FE1F3 repeated (L/4) times.



Bhatia and Manral         Expires August 2011                [Page 6]


Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011


   (1)Preparation of the Key

      In this application, Ko is always L octets long.

      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.

   (2)First Hash

      First, the Authentication Data field in the BFD Auth Section is
      filled with the value Apad and the Authentication Type field is
      set to 6 or 7 depending upon which Authentication Type is being
      used. The Sequence Number field MUST be set to bfd.XmitAuthSeq.


      Then, a first hash, also known as the inner hash, is computed
      as follows:

              First-Hash = H(Ko XOR Ipad || (BFD Packet))

   (3)Second Hash

      Then a second hash, also known as the outer hash, is computed
      as follows:

              Second-Hash = H(Ko XOR Opad || First-Hash)

   (4)Result

      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.

      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.

3.4 Procedures at the Sending Side

   An appropriate BFD SA is selected for use with an outgoing BFD
   packet. This is done based on the active key at that instant. If BFD
   is unable to find an active key, the BFD packet is discarded.



Bhatia and Manral         Expires August 2011                [Page 7]


Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011


   If BFD is able to find the active key, then the key gives the
   authentication algorithm (HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 or
   HMAC-SHA-512) that needs to be applied on the packet.

   An implementation MUST fill the Auth Type and the Auth length before
   the authentication data is computed. The Sequence Number field MUST
   be set to bfd.XmitAuthSeq.

   The Auth length in the Authentication section is set as per the
   authentication algorithm that is being used. It is set to 28 for
   HMAC-SHA-1, 40 for HMAC-SHA-256, 56 for HMAC-SHA-384 and 72 for HMAC-
   SHA-512.

   The Key ID is filled.

   The authentication data is computed as explained in the previous
   section.

   The result of the authentication algorithm is placed in the
   Authentication data, following the Key ID.


3.5 Procedure at the Receiving Side

   The appropriate BFD SA is identified by looking at the Key ID from
   the Authentication Section from the incoming BFD packet.

   If the Auth Key ID field does not match the ID of a configured
   authentication key, the received packet MUST be discarded.

   If bfd.AuthSeqKnown is 1, examine the Sequence Number field.  For
   Cryptographic Authentication, if the Sequence Number lies outside of
   the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult)
   inclusive (when treated as an unsigned 32 bit circular number space),
   the received packet MUST be discarded.  For Meticulous Cryptographic
   Authentication, if the Sequence Number lies outside of the range of
   bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
   treated as an unsigned 32 bit circular number space, the received
   packet MUST be discarded.

   Authentication Algorithm dependent processing, needs to be performed,
   using the algorithm specified by the appropriate BFD SA for the
   received packet.

   Before an implementation performs any processing it needs to save the
   values of the Authentication Value field.

   It should then set the Authentication Value field with Apad before
   the authentication data is computed. The calculated data is compared


Bhatia and Manral         Expires August 2011                [Page 8]


Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011


   with the received authentication data in the packet and the packet is
   discarded if the two do not match. In such a case, an error event
   SHOULD be logged.

   An implementation MAY have a transition mode where it includes
   CRYPTO_AUTH or the MET_CRYPTO_AUTH information in the packets but
   does not verify this information. This is provided as a transition
   aid for networks in the process of migrating to the new CRYPTO_AUTH
   and MET_CRYPTO_AUTH based authentication schemes.

4. Security Considerations

   This document enhances the security of the BFD protocol by adding, to
   the existing BFD cryptographic authentication methods, support for
   the algorithms defined in the NIST Secure Hash Standard (SHS) using
   the Hashed Message Authentication Code (HMAC) mode, and by adding
   support for the Hashed Message Authentication Code (HMAC) mode. It
   does not provide confidentiality as BFD contains information that
   does not need to be kept secret.

   Because all of the currently specified algorithms use symmetric
   cryptography, one cannot authenticate precisely which BFD router
   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.

   The technology in this document provides an authentication mechanism
   for BFD.  The mechanism described here is not perfect and does not
   need to be perfect. Instead, this mechanism represents a significant
   increase in the work function of an adversary attacking the BFD
   protocol, while not causing undue implementation, deployment, or
   operational complexity.

   There is a transition mode suggested where routers can ignore the
   CRYPTO_AUTH or the MET_CRYPTO_AUTH information carried in the
   packets. The operator must ensure that this mode is only used when
   migrating to the new CRYPTO_AUTH/MET_CRYPTO_AUTH based authentication
   scheme as this leaves the router vulnerable to an attack.

   To ensure greater security, the keys used should be changed
   periodically and implementations MUST 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



Bhatia and Manral         Expires August 2011                [Page 9]


Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011


   the secrecy of the shared secret key.  [RFC4086] provides guidance on
   methods for generating cryptographically random bits.

   The value Apad is used here primarily for consistency with IETF
   specifications for HMAC-SHA authentication of RIPv2 SHA [RFC4822],
   IS-IS SHA [RFC5310] and OSPF SHA [RFC5709].

5. IANA Considerations

   This document currently defines a value of 6 to be used to denote
   Cryptographic Authentication mechanism for authenticating BFD control
   packets and 7 for Meticulous Cryptographic Authentication.

6. References

6.1 Normative References

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992

   [RFC2104]  Krawczyk, H. et al., "HMAC: Keyed-Hashing for Message
              Authentication", RFC 2104, February 1997

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997

   [RFC5880] Katz, D. and Ward, D., "Bidirectional Forwarding
              Detection", RFC 5880, June 2010

   [FIPS-180-3] National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", FIPS PUB 180-3, October 2008

   [FIPS-198] US National Institute of Standards & Technology, "The
              Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
              198, March 2002.

6.2 Informative References

   [MD5-attack] Wang, X. et al., "Collisions for Hash Functions MD4,
                MD5, HAVAL-128 and RIPEMD", August 2004,
                http://eprint.iacr.org/2004/199

   [Dobb96a]  Dobbertin, H, "Cryptanalysis of MD5 Compress", Technical
              Report, 2 May 1996. (Presented at the Rump Session of
              EuroCrypt 1996.)

   [Dobb96b]  Dobbertin, H, "The Status of MD5 After a Recent Attack",
              CryptoBytes, Vol. 2, No. 2, Summer 1996.



Bhatia and Manral         Expires August 2011                [Page 10]


Internet Draft    BFD Generic Cryptographic Authentication   Jan 2011


   [SHA-1-attack1] Wang, X. et. al., "Finding Collisions in the Full
              SHA-1", Advances in Cryptology CRYPTO 05, pp. 17-36

   [SHA-1-attack2] Wang, X. et. al., "New Collision Search for SHA-1",
              Technical Report, August 2005 (Presented in the Rump
              Session of CRYPTO 05)

   [RFC4634]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, July 2006.

   [RFC4086]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC
              4086, June 2005.

   [RFC4822]  Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
              Authentication", RFC 4822, February 2007.

   [RFC5310]  Bhatia, M., et. al., "IS-IS Generic Cryptographic
              Authentication", RFC 5310, February 2009.

   [RFC5709]  Bhatia, M., et. al., "IS-IS Generic Cryptographic
              Authentication", RFC 5709, October 2009.

7. Author's Addresses

   Manav Bhatia
   Alcatel-Lucent,
   Bangalore, India
   Email: manav.bhatia@alcatel-lucent.com

   Vishwas Manral
   IP Infusion
   Almora, Uttarakhand, India
   Email: vishwas@ipinfusion.com

















Bhatia and Manral         Expires August 2011                [Page 11]