RFC 7298
Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication
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 AuthenticationAbstract
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.
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
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
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.
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.
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
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.
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).
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.
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)
