tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7298

Experimental
Pages: 55
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~sec

Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication

Part 1 of 3, p. 1 to 10
None       Next RFC Part

Updates:    6126


Top       ToC       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       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       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       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       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       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       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       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       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       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 RFC Part