Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7298

Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication

Pages: 55
Obsoleted by:  8967
Updates:  6126
Part 1 of 3 – Pages 1 to 10
None   None   Next

Top   ToC   RFC7298 - Page 1
Independent Submission                                       D. Ovsienko
Request for Comments: 7298                                        Yandex
Updates: 6126                                                  July 2014
Category: Experimental
ISSN: 2070-1721


            Babel Hashed Message Authentication Code (HMAC)
                      Cryptographic Authentication

Abstract

This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7298. Copyright Notice Copyright (c) 2014 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.
Top   ToC   RFC7298 - Page 2

Table of Contents

1. Introduction ....................................................3 1.1. Requirements Language ......................................5 2. Cryptographic Aspects ...........................................5 2.1. Mandatory-to-Implement and Optional Hash Algorithms ........5 2.2. Definition of Padding ......................................6 2.3. Cryptographic Sequence Number Specifics ....................8 2.4. Definition of HMAC .........................................9 3. Updates to Protocol Data Structures ............................11 3.1. RxAuthRequired ............................................11 3.2. LocalTS ...................................................11 3.3. LocalPC ...................................................11 3.4. MaxDigestsIn ..............................................11 3.5. MaxDigestsOut .............................................12 3.6. ANM Table .................................................12 3.7. ANM Timeout ...............................................13 3.8. Configured Security Associations ..........................14 3.9. Effective Security Associations ...........................16 4. Updates to Protocol Encoding ...................................17 4.1. Justification .............................................17 4.2. TS/PC TLV .................................................19 4.3. HMAC TLV ..................................................20 5. Updates to Protocol Operation ..................................21 5.1. Per-Interface TS/PC Number Updates ........................21 5.2. Deriving ESAs from CSAs ...................................23 5.3. Updates to Packet Sending .................................25 5.4. Updates to Packet Receiving ...............................28 5.5. Authentication-Specific Statistics Maintenance ............30 6. Implementation Notes ...........................................31 6.1. Source Address Selection for Sending ......................31 6.2. Output Buffer Management ..................................31 6.3. Optimizations of Deriving Procedure for ESAs ..............32 6.4. Duplication of Security Associations ......................33 7. Network Management Aspects .....................................34 7.1. Backward Compatibility ....................................34 7.2. Multi-Domain Authentication ...............................35 7.3. Migration to and from Authenticated Exchange ..............36 7.4. Handling of Authentication Key Exhaustion .................37 8. Security Considerations ........................................38 9. IANA Considerations ............................................43 10. Acknowledgements ..............................................43 11. References ....................................................44 11.1. Normative References .....................................44 11.2. Informative References ...................................44 Appendix A. Figures and Tables ....................................47 Appendix B. Test Vectors ..........................................52
Top   ToC   RFC7298 - Page 3

1. Introduction

Authentication of routing protocol exchanges is a common means of securing computer networks. The use of protocol authentication mechanisms helps in ascertaining that only the intended routers participate in routing information exchange and that the exchanged routing information is not modified by a third party. [BABEL] ("the original specification") defines data structures, encoding, and the operation of a basic Babel routing protocol instance ("instance of the original protocol"). This document ("this specification") defines data structures, encoding, and the operation of an extension to the Babel protocol -- an authentication mechanism ("this mechanism"). Both the instance of the original protocol and this mechanism are mostly self-contained and interact only at coupling points defined in this specification. A major design goal of this mechanism is transparency to operators that is not affected by implementation and configuration specifics. A complying implementation makes all meaningful details of authentication-specific processing clear to the operator, even when some of the operational parameters cannot be changed. The currently established (see [RIP2-AUTH], [OSPF2-AUTH], [ISIS-AUTH-A], [RFC6039], and [OSPF3-AUTH-BIS]) approach to an authentication mechanism design for datagram-based routing protocols such as Babel relies on two principal data items embedded into protocol packets, typically as two integral parts of a single data structure: o A fixed-length unsigned integer, typically called a cryptographic sequence number, used in replay attack protection. o A variable-length sequence of octets, a result of the Hashed Message Authentication Code (HMAC) construction (see [RFC2104]) computed on meaningful data items of the packet (including the cryptographic sequence number) on one hand and a secret key on the other, used in proving that both the sender and the receiver share the same secret key and that the meaningful data was not changed in transmission. Depending on the design specifics, either all protocol packets or only those packets protecting the integrity of protocol exchange are authenticated. This mechanism authenticates all protocol packets. Although the HMAC construction is just one of many possible approaches to cryptographic authentication of packets, this mechanism makes use of relevant prior experience by using HMAC as well, and its
Top   ToC   RFC7298 - Page 4
   solution space correlates with the solution spaces of the mechanisms
   above.  At the same time, it allows for a future extension that
   treats HMAC as a particular case of a more generic mechanism.
   Practical experience with the mechanism defined herein should be
   useful in designing such a future extension.

   This specification defines the use of the cryptographic sequence
   number in detail sufficient to make replay attack protection strength
   predictable.  That is, an operator can tell the strength from the
   declared characteristics of an implementation and, if the
   implementation allows the changing of relevant parameters, the effect
   of a reconfiguration as well.

   This mechanism explicitly allows for multiple HMAC results per
   authenticated packet.  Since meaningful data items of a given packet
   remain the same, each such HMAC result stands for a different secret
   key and/or a different hash algorithm.  This enables a simultaneous,
   independent authentication within multiple domains.  This
   specification is not novel in this regard; for example, the Layer 2
   Tunneling Protocol (L2TPv3) allows for one or two results per
   authenticated packet ([RFC3931] Section 5.4.1), and Mobile Ad Hoc
   Network (MANET) protocols allow for several ([RFC7183] Section 6.1).

   An important concern addressed by this mechanism is limiting the
   amount of HMAC computations done per authenticated packet,
   independently for sending and receiving.  Without these limits, the
   number of computations per packet could be as high as the number of
   configured authentication keys (in the sending case) or as high as
   the number of keys multiplied by the number of supplied HMAC results
   (in the receiving case).

   These limits establish a basic competition between the configured
   keys and (in the receiving case) an additional competition between
   the supplied HMAC results.  This specification defines related data
   structures and procedures in a way to make such competition
   transparent and predictable for an operator.

   Wherever this specification mentions the operator reading or changing
   a particular data structure, variable, parameter, or event counter
   "at runtime", it is up to the implementor how this is to be done.
   For example, the implementation can employ an interactive command
   line interface (CLI), a management protocol such as the Simple
   Network Management Protocol (SNMP), a means of inter-process
   communication such as a local socket, or a combination of these.
Top   ToC   RFC7298 - Page 5

1.1. Requirements Language

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

2. Cryptographic Aspects

2.1. Mandatory-to-Implement and Optional Hash Algorithms

[RFC2104] defines HMAC as a construction that can use any cryptographic hash algorithm with a known digest length and internal block size. This specification preserves this property of HMAC by defining data processing that itself does not depend on any particular hash algorithm either. However, since this mechanism is a protocol extension case, there are relevant design considerations to take into account. Section 4.5 of [RFC6709] suggests selecting one hash algorithm as mandatory to implement for the purpose of global interoperability (Section 3.2 of [RFC6709]) and selecting another of distinct lineage as recommended for implementation for the purpose of cryptographic agility. This specification makes the latter property guaranteed, rather than probable, through an elevation of the requirement level. There are two mandatory-to-implement hash algorithms; each is unambiguously defined and generally available in multiple implementations. An implementation of this mechanism MUST include support for two hash algorithms: o RIPEMD-160 (160-bit digest) o SHA-1 (160-bit digest) Besides that, an implementation of this mechanism MAY include support for additional hash algorithms, provided each such algorithm is publicly and openly specified and its digest length is 128 bits or more (to meet the constraint implied in Section 2.2). Implementors SHOULD consider strong, well-known hash algorithms as additional implementation options and MUST NOT consider a hash algorithm if meaningful attacks exist for it or it is commonly viewed as deprecated.
Top   ToC   RFC7298 - Page 6
   In the latter case, it is important to take into account
   considerations both common (such as those made in [RFC4270]) and
   specific to the HMAC application of the hash algorithm.  For example,
   [RFC6151] considers MD5 collisions and concludes that new protocol
   designs should not use HMAC-MD5, while [RFC6194] includes a
   comparable analysis of SHA-1 that finds HMAC-SHA-1 secure for the
   same purpose.

   For example, the following hash algorithms meet these requirements at
   the time of this writing (in alphabetical order):

   o  GOST R 34.11-94 (256-bit digest)

   o  SHA-224 (224-bit digest, SHA-2 family)

   o  SHA-256 (256-bit digest, SHA-2 family)

   o  SHA-384 (384-bit digest, SHA-2 family)

   o  SHA-512 (512-bit digest, SHA-2 family)

   o  Tiger (192-bit digest)

   o  Whirlpool (512-bit digest, 2nd rev., 2003)

   The set of hash algorithms available in an implementation MUST be
   clearly stated.  When known weak authentication keys exist for a hash
   algorithm used in the HMAC construction, an implementation MUST deny
   the use of such keys.

2.2. Definition of Padding

Many practical applications of HMAC for authentication of datagram- based network protocols (including routing protocols) involve the padding procedure, a design-specific conditioning of the message that both the sender and the receiver perform before the HMAC computation. The specific padding procedure of this mechanism addresses the following needs: o Data Initialization A design that places the HMAC result(s) computed for a message inside that same message after the computation has to have previously (i.e., before the computation) allocated in that message some data unit(s) purposed specifically for those HMAC
Top   ToC   RFC7298 - Page 7
      result(s) (in this mechanism, it is the HMAC TLV(s); see
      Section 4.3).  The padding procedure sets the respective octets of
      the data unit(s), in the simplest case to a fixed value known as
      the padding constant.

      The particular value of the constant is specific to each design.
      For instance, in [RIP2-AUTH] as well as works derived from it
      ([ISIS-AUTH-B], [OSPF2-AUTH], and [OSPF3-AUTH-BIS]), the value is
      0x878FE1F3.  In many other designs (for instance, [RFC3315],
      [RFC3931], [RFC4030], [RFC4302], [RFC5176], and [ISIS-AUTH-A]),
      the value is 0x00.

      However, the HMAC construction is defined on the basis of a
      cryptographic hash algorithm, that is, an algorithm meeting a
      particular set of requirements made for any input message.  Thus,
      any padding constant values, whether single- or multiple-octet, as
      well as any other message-conditioning methods, don't affect
      cryptographic characteristics of the hash algorithm and the HMAC
      construction, respectively.

   o  Source Address Protection

      In the specific case of datagram-based routing protocols, the
      protocol packet (that is, the message being authenticated) often
      does not include network-layer addresses, although the source and
      (to a lesser extent) the destination address of the datagram may
      be meaningful in the scope of the protocol instance.

      In Babel, the source address may be used as a prefix next hop (see
      Section 3.5.3 of [BABEL]).  A well-known (see Section 2.3 of
      [OSPF3-AUTH-BIS]) solution to the source address protection
      problem is to set the first respective octets of the data unit(s)
      above to the source address (yet setting the rest of the octets to
      the padding constant).  This procedure adapts this solution to the
      specifics of Babel, which allows for the exchange of protocol
      packets using both IPv4 and IPv6 datagrams (see Section 4 of
      [BABEL]).  Even though in the case of IPv6 exchange a Babel
      speaker currently uses only link-local source addresses
      (Section 3.1 of [BABEL]), this procedure protects all octets of an
      arbitrary given source address for the reasons of future
      extensibility.  The procedure implies that future Babel extensions
      will never use an IPv4-mapped IPv6 address as a packet source
      address.
Top   ToC   RFC7298 - Page 8
      This procedure does not protect the destination address, which is
      currently considered meaningless (Section 3.1 of [BABEL]) in the
      same scope.  A future extension that looks to add such protection
      would likely use a new TLV or sub-TLV to include the destination
      address in the protocol packet (see Section 4.1).

   Description of the padding procedure:

   1.  Set the first 16 octets of the Digest field of the given HMAC
       TLV to:

       *  the given source address, if it is an IPv6 address, or

       *  the IPv4-mapped IPv6 address (per Section 2.5.5.2 of
          [RFC4291]) holding the given source address, if it is an IPv4
          address.

   2.  Set the remaining (TLV Length - 18) octets of the Digest field of
       the given HMAC TLV to 0x00 each.

   For an example of a Babel packet with padded HMAC TLVs, see Table 3
   in Appendix A.

2.3. Cryptographic Sequence Number Specifics

The operation of this mechanism may involve multiple local and multiple remote cryptographic sequence numbers, each essentially being a 48-bit unsigned integer. This specification uses the term "TS/PC number" to avoid confusion with the route's (Section 2.5 of [BABEL]) or node's (Section 3.2.1 of [BABEL]) sequence numbers of the original Babel specification and to stress the fact that there are two distinguished parts of this 48-bit number, each handled in its specific way (see Section 5.1): 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 // 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS // | PC | +-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // The high-order 32 bits are called "timestamp" (TS), and the low-order 16 bits are called "packet counter" (PC).
Top   ToC   RFC7298 - Page 9
   This mechanism stores, updates, compares, and encodes each TS/PC
   number as two independent unsigned integers -- TS and PC,
   respectively.  Such a comparison of TS/PC numbers, as performed in
   item 3 of Section 5.4, is algebraically equivalent to a comparison of
   the respective 48-bit unsigned integers.  Any byte order conversion,
   when required, is performed on TS and PC parts independently.

2.4. Definition of HMAC

The algorithm description below uses the following nomenclature, which is consistent with [FIPS-198]: Text The data on which the HMAC is calculated (note item (b) of Section 8). In this specification, it is the contents of a Babel packet ranging from the beginning of the Magic field of the Babel packet header to the end of the last octet of the Packet Body field, as defined in Section 4.2 of [BABEL] (see Figure 2 in Appendix A). H The specific hash algorithm (see Section 2.1). K A sequence of octets of an arbitrary, known length. Ko The cryptographic key used with the hash algorithm. B The block size of H, measured in octets rather than bits. Note that B is the internal block size, not the digest length. L The digest length of H, measured in octets rather than bits. XOR The bitwise exclusive-or operation. Opad The hexadecimal value 0x5C repeated B times. Ipad The hexadecimal value 0x36 repeated B times. The algorithm below is the original, unmodified HMAC construction as defined in both [RFC2104] and [FIPS-198]; hence, it is different from the algorithms defined in [RIP2-AUTH], [ISIS-AUTH-B], [OSPF2-AUTH], and [OSPF3-AUTH-BIS] in exactly two regards: o The algorithm below sets the size of Ko to B, not to L (L is not greater than B). This resolves both ambiguity in XOR expressions and incompatibility in the handling of keys that have length greater than L but not greater than B.
Top   ToC   RFC7298 - Page 10
   o  The algorithm below does not change the value of Text before or
      after the computation.  Padding a Babel packet before the
      computation and placing the result inside the packet are both
      performed elsewhere.

   The intent of this is to enable the most straightforward use of
   cryptographic libraries by implementations of this specification.  At
   the time of this writing, implementations of the original HMAC
   construction coupled with hash algorithms of choice are generally
   available.

   Description of the algorithm:

   1.  Preparation of the Key

       In this application, Ko is always B octets long.  If K is B
       octets long, then Ko is set to K.  If K is more than B octets
       long, then Ko is set to H(K) with the necessary amount of zeroes
       appended to the end of H(K), such that Ko is B octets long.  If K
       is less than B octets long, then Ko is set to K with zeroes
       appended to the end of K, such that Ko is B octets long.

   2.  First-Hash

       A First-Hash, also known as the inner hash, is computed
       as follows:

                    First-Hash = H(Ko XOR Ipad || Text)

   3.  Second-Hash

       A Second-Hash, also known as the outer hash, is computed
       as follows:

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

   4.  Result

       The resulting Second-Hash becomes the authentication data that is
       returned as the result of HMAC calculation.

   Note that in the case of Babel the Text parameter will never exceed a
   few thousand octets in length.  In this specific case, the
   optimization discussed in Section 6 of [FIPS-198] applies, namely,
   for a given K that is more than B octets long, the following
   associated intermediate results may be precomputed only once:
   Ko, (Ko XOR Ipad), and (Ko XOR Opad).


(next page on part 2)

Next Section