--- 1/draft-ietf-babel-hmac-01.txt 2018-12-23 14:13:08.748022810 -0800 +++ 2/draft-ietf-babel-hmac-02.txt 2018-12-23 14:13:08.784023687 -0800 @@ -1,20 +1,20 @@ Network Working Group C. Do Internet-Draft W. Kolodziejak Obsoletes: 7298 (if approved) J. Chroboczek Updates: 6126bis (if approved) IRIF, University of Paris-Diderot -Intended status: Standards Track November 14, 2018 -Expires: May 18, 2019 +Intended status: Standards Track December 23, 2018 +Expires: June 26, 2019 HMAC authentication for the Babel routing protocol - draft-ietf-babel-hmac-01 + draft-ietf-babel-hmac-02 Abstract This document describes a cryptographic authentication for the Babel routing protocol that has provisions for replay avoidance. This document updates RFC 6126bis and obsoletes RFC 7298. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -23,21 +23,21 @@ 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 https://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 May 18, 2019. + This Internet-Draft will expire on June 26, 2019. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,35 +54,37 @@ 1.2. Assumptions and security properties . . . . . . . . . . . 3 1.3. Specification of Requirements . . . . . . . . . . . . . . 4 2. Conceptual overview of the protocol . . . . . . . . . . . . . 4 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 5 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 6 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 7 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 - 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 10 + 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 11 + 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 12 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 9.2. Informational References . . . . . . . . . . . . . . . . 14 + 9.2. Informational References . . . . . . . . . . . . . . . . 15 Appendix A. Incremental deployment and key rotation . . . . . . 15 - Appendix B. Changes from previous versions . . . . . . . . . . . 15 - B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + Appendix B. Changes from previous versions . . . . . . . . . . . 16 + B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16 + B.2. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction By default, the Babel routing protocol trusts the information contained in every UDP packet it receives on the Babel port. An attacker can redirect traffic to itself or to a different node in the network, causing a variety of potential issues. In particular, an attacker might: o spoof a Babel packet, and redirect traffic by announcing a smaller @@ -114,22 +116,23 @@ is inapplicable in situations where asymmetric keying is required, where the trust relationship is partial, or where large numbers of trusted keys are provisioned on a single link at the same time. This protocol supports incremental deployment (where an insecure Babel network is made secure with no service interruption), and it supports graceful key rotation (where the set of keys is changed with no service interruption). This protocol does not require synchronised clocks, it does not - require persistently monotonic clocks, and it does not require any - form of persistent storage. + require persistently monotonic clocks, and it does not require + persistent storage except for what might be required for storing + cryptographic keys. 1.2. Assumptions and security properties The correctness of the protocol relies on the following assumptions: o that the Hashed Message Authentication Code (HMAC) being used is invulnerable to pre-image attacks, i.e., that an attacker is unable to generate a packet with a correct HMAC; o that a node never generates the same index or nonce twice over the @@ -184,21 +187,21 @@ In order to protect against replay B maintains a per-interface 32-bit integer known as the "packet counter" (PC). Whenever B sends a packet through the interface, it embeds the current value of the PC within the region of the packet that is protected by the HMACs and increases the PC by at least one. When A receives the packet, it compares the value of the PC with the one contained in the previous packet received from B, and unless it is strictly greater, the packet is discarded. By itself, the PC mechanism is not sufficient to protect against - replay. Consider a peer A that has no information about a pair B + replay. Consider a peer A that has no information about a peer B (e.g., because it has recently rebooted). Suppose that A receives a packet ostensibly from B carrying a given PC; since A has no information about B, it has no way to determine whether the packet is freshly generated or a replay of a previously sent packet. In this situation, A discards the packet and challenges B to prove that it knows the HMAC key. It sends a "challenge request", a TLV containing a unique nonce, a value that has never been used before and will never be used again. B replies to the challenge request with a "challenge reply", a TLV containing a copy of the nonce chosen @@ -299,23 +302,24 @@ Src port The source UDP port number of the packet. Dest address The destination IP address of the packet. Src port The destination UDP port number of the packet. The node takes the concatenation of the pseudo-header and the packet including the packet header but excluding the packet trailer (from octet 0 inclusive up to Body Length + 4 exclusive) and computes an - HMAC as defined in Section 2 of [RFC2104] with one of the implemented - hash algorithms. Every implementation MUST implement HMAC-SHA256 - [RFC6234], and MAY implement other HMAC algorithms. + HMAC with one of the implemented hash algorithms. Every + implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and + Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and + MAY implement other HMAC algorithms. 4.2. Packet Transmission A Babel node may delay actually sending TLVs by a small amount, in order to aggregate multiple TLVs in a single packet up to the interface MTU (Section 4 of [RFC6126bis]). For an interface on which HMAC protection is configured, the TLV aggregation logic MUST take into account the overhead due to PC TLVs (one in each packet) and HMAC TLVs (one per configured key). @@ -449,20 +453,35 @@ neighbour that sent the Challenge Reply. If no challenge is in progress, i.e., if there is no Nonce stored in the Neighbour Table entry or the Challenge timer has expired, the Challenge Reply is silently ignored and the challenge has failed. Otherwise, the node compares the Nonce contained in the Challenge Reply with the Nonce contained in the Neighbour Table entry. If the two are equal (they have the same length and content), then the challenge has succeeded; otherwise, the challenge has failed. +4.4. Expiring per-neighbour state + + The per-neighbour (Index, PC) pair is maintained in the neighbour + table, and is normally discarded when the neighbour table entry + expires. Implementations MUST ensure that an (Index, PC) pair is + discarded within a finite time since the last time a packet has been + accepted. In particular, unsuccessful challenges MUST NOT prevent an + (Index, PC) pair from being discarded for unbounded periods of time. + + Implementations that use a Hello history (Appendix A of [RFC6126bis]) + may discard the (Index, PC) pair whenever the Hello history becomes + empty. Other impementations may use a timer that is reset whenever a + packet is accepted, and discard the (Index, PC) pair whenever the + timer expires (an timeout of 5 min is suggested). + 5. Packet Format 5.1. HMAC TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | HMAC... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- @@ -546,43 +565,56 @@ fields. The length of the body is set to the same size as the challenge request TLV length received. Nonce A copy of the nonce contained in the corresponding challenge request. 6. Security Considerations This document defines a mechanism that provides basic security properties for the Babel routing protocol. The scope of this - protocol is strictly limited: it only provides authentication, on the - assumption that routing information is not confidential, only - symmetric keying, and only allows for the use of a small number of - symmetric keys on each link. Deployments that need more features, - e.g., confidentiality or asymmetric keying, should use a more - featureful security mechanism such as the one described in + protocol is strictly limited: it only provides authentication (we + assume that routing information is not confidential), it only + supports symmetric keying, and it only allows for the use of a small + number of symmetric keys on every link. Deployments that need more + features, e.g., confidentiality or asymmetric keying, should use a + more featureful security mechanism such as the one described in [I-D.ietf-babel-dtls]. This mechanism relies on two assumptions, as described in Section 1.2. First, it assumes that the hash being used is invulnerable to pre-image attacks (Section 1.1 of [RFC6039]); at the time of writing, SHA-256, which is mandatory to implement (Section 4.1), is believed to be safe against practical attacks. Second, it assumes that indices and nonces are generated uniquely - over the lifetime of a key used for HMAC computation. This property - can be satisfied either by using a cryptographically secure random - number generator to generate indices and nonces that contain enough - entropy (64-bit values are believed to be large enough for all + over the lifetime of a key used for HMAC computation (more precisely, + indices must be unique for a given (key, source) pair, and nonces + must be unique for a given (key, source, destination) triple). This + property can be satisfied either by using a cryptographically secure + random number generator to generate indices and nonces that contain + enough entropy (64-bit values are believed to be large enough for all practical applications), or by using a reliably monotonic hardware clock. If unicity cannot be guaranteed (e.g., because a hardware clock has been reset), then rekeying is necessary. + The expiry mechanism mandated in Section 4.4 is required to prevent + an attacker from delaying an authentic packet by an unbounded amount + of time. If an attacker is able to delay the delivery of a packet + (e.g., because it is located at a layer 2 switch), then the packet + will be accepted as long as the corresponding (Index, PC) pair is + present at the receiver. If the attacker is able to cause the + (Index, PC) pair to persist for arbitrary amounts of time (e.g., by + causing failed challenges), then it is able to delay the packet by + arbitrary amounts of time, even after the sender has left the + network. + While it is probably not possible to be immune against denial of service (DoS) attacks in general, this protocol includes a number of mechanisms designed to mitigate such attacks. In particular, reception of a packet with no correct HMAC creates no local state whatsoever (Section 4.3). Reception of a replayed packet with correct hash, on the other hand, causes a challenge to be sent; this is mitigated somewhat by requiring that challenges be rate-limited. At first sight, sending a challenge requires retaining enough information to validate the challenge reply. However, the nonce @@ -607,61 +639,66 @@ | | | | | TBD | Challenge Reply | this document | +------+-------------------+---------------+ 8. Acknowledgments The protocol described in this document is based on the original HMAC protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- header was suggested by David Schinazi. The use of an index to avoid replay was suggested by Markus Stenberg. The authors are also - indebted to Florian Horn and Toke Hoyland-Jorgensen. + indebted to Toke Hoiland-Jorgensen, Florian Horn, and Dave Taht. 9. References 9.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. - [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues - with Existing Cryptographic Protection Methods for Routing - Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, - . - [RFC6126bis] Chroboczek, J. and D. Schinazi, "The Babel Routing Protocol", draft-ietf-babel-rfc6126bis-06 (work in progress), October 2018. [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . + [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 + Cryptographic Hash and Message Authentication Code (MAC)", + RFC 7693, DOI 10.17487/RFC7693, November 2015, + . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. 9.2. Informational References [I-D.ietf-babel-dtls] Decimo, A., Schinazi, D., and J. Chroboczek, "Babel Routing Protocol over Datagram Transport Layer Security", draft-ietf-babel-dtls-01 (work in progress), October 2018. + [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues + with Existing Cryptographic Protection Methods for Routing + Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, + . + [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, DOI 10.17487/RFC7298, July 2014, . Appendix A. Incremental deployment and key rotation This protocol supports incremental deployment (transitioning from an insecure network to a secured network with no service interruption) and key rotation (transitioning from a set of keys to a different set @@ -692,32 +729,38 @@ o Removed the appendix about the packet trailer, this is now in rfc6126bis. o Removed the appendix with implicit indices. o Clarified the definitions of acronyms. o Limited the size of nonces and indices. +B.2. Changes since draft-ietf-babel-hmac-00 + + o Made BLAKE2s a recommended HMAC algorithm. + + o Added requirement to expire per-neighbour crypto state. + Authors' Addresses Clara Do IRIF, University of Paris-Diderot 75205 Paris Cedex 13 France Email: clarado_perso@yahoo.fr + Weronika Kolodziejak IRIF, University of Paris-Diderot 75205 Paris Cedex 13 France Email: weronika.kolodziejak@gmail.com - Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris Cedex 13 France Email: jch@irif.fr