idnits 2.17.1 draft-ietf-babel-hmac-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2019) is 1771 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-06 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Downref: Normative reference to an Informational RFC: RFC 7693 == Outdated reference: A later version (-10) exists of draft-ietf-babel-dtls-01 -- Obsolete informational reference (is this intentional?): RFC 7298 (Obsoleted by RFC 8967) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Do 3 Internet-Draft W. Kolodziejak 4 Obsoletes: 7298 (if approved) J. Chroboczek 5 Intended status: Standards Track IRIF, University of Paris-Diderot 6 Expires: December 22, 2019 June 20, 2019 8 HMAC authentication for the Babel routing protocol 9 draft-ietf-babel-hmac-07 11 Abstract 13 This document describes a cryptographic authentication mechanism for 14 the Babel routing protocol that has provisions for replay avoidance. 15 This document obsoletes RFC 7298. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 22, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Assumptions and security properties . . . . . . . . . . . 3 54 1.3. Specification of Requirements . . . . . . . . . . . . . . 4 55 2. Conceptual overview of the protocol . . . . . . . . . . . . . 4 56 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6 58 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 59 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8 62 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 63 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 12 64 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12 65 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13 68 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 74 9.2. Informational References . . . . . . . . . . . . . . . . 17 75 Appendix A. Incremental deployment and key rotation . . . . . . 17 76 Appendix B. Changes from previous versions . . . . . . . . . . . 18 77 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 18 78 B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 18 79 B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 18 80 B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 18 81 B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 19 82 B.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 19 83 B.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 By default, the Babel routing protocol trusts the information 89 contained in every UDP datagram that it receives on the Babel port. 90 An attacker can redirect traffic to itself or to a different node in 91 the network, causing a variety of potential issues. In particular, 92 an attacker might: 94 o spoof a Babel packet, and redirect traffic by announcing a smaller 95 metric, a larger seqno, or a longer prefix; 97 o spoof a malformed packet, which could cause an insufficiently 98 robust implementation to crash or interfere with the rest of the 99 network; 101 o replay a previously captured Babel packet, which could cause 102 traffic to be redirected or otherwise interfere with the network. 104 Protecting a Babel network is challenging due to the fact that the 105 Babel protocol uses both unicast and multicast communication. One 106 possible approach, used notably by the Babel over Datagram Transport 107 Layer Security (DTLS) protocol [I-D.ietf-babel-dtls], is to use 108 unicast communication for all semantically significant communication, 109 and then use a standard unicast security protocol to protect the 110 Babel traffic. In this document, we take the opposite approach: we 111 define a cryptographic extension to the Babel protocol that is able 112 to protect both unicast and multicast traffic, and thus requires very 113 few changes to the core protocol. 115 1.1. Applicability 117 The protocol defined in this document assumes that all interfaces on 118 a given link are equally trusted and share a small set of symmetric 119 keys (usually just one, and two during key rotation). The protocol 120 is inapplicable in situations where asymmetric keying is required, 121 where the trust relationship is partial, or where large numbers of 122 trusted keys are provisioned on a single link at the same time. 124 This protocol supports incremental deployment (where an insecure 125 Babel network is made secure with no service interruption), and it 126 supports graceful key rotation (where the set of keys is changed with 127 no service interruption). 129 This protocol does not require synchronised clocks, it does not 130 require persistently monotonic clocks, and it does not require 131 persistent storage except for what might be required for storing 132 cryptographic keys. 134 1.2. Assumptions and security properties 136 The correctness of the protocol relies on the following assumptions: 138 o that the Hashed Message Authentication Code (HMAC) being used is 139 invulnerable to pre-image attacks, i.e., that an attacker is 140 unable to generate a packet with a correct HMAC; 142 o that a node never generates the same index or nonce twice over the 143 lifetime of a key. 145 The first assumption is a property of the HMAC being used. The 146 second assumption can be met either by using a robust random number 147 generator [RFC4086] and sufficiently large indices and nonces, by 148 using a reliable hardware clock, or by rekeying whenever a collision 149 becomes likely. 151 If the assumptions above are met, the protocol described in this 152 document has the following properties: 154 o it is invulnerable to spoofing: any packet accepted as authentic 155 is the exact copy of a packet originally sent by an authorised 156 node; 158 o locally to a single node, it is invulnerable to replay: if a node 159 has previously accepted a given packet, then it will never again 160 accept a copy of this packet or an earlier packet from the same 161 sender; 163 o among different nodes, it is only vulnerable to immediate replay: 164 if a node A has accepted a packet from C as valid, then a node B 165 will only accept a copy of that packet as authentic if B has 166 accepted an older packet from C and B has received no later packet 167 from C. 169 While this protocol makes serious efforts to mitigate the effects of 170 a denial of service attack, it does not fully protect against such 171 attacks. 173 1.3. Specification of Requirements 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 177 "OPTIONAL" in this document are to be interpreted as described in BCP 178 14 [RFC2119] [RFC8174] when, and only when, they appear in all 179 capitals, as shown here. 181 2. Conceptual overview of the protocol 183 When a node B sends out a Babel packet through an interface that is 184 configured for HMAC cryptographic protection, it computes one or more 185 HMACs which it appends to the packet. When a node A receives a 186 packet over an interface that requires HMAC cryptographic protection, 187 it independently computes a set of HMACs and compares them to the 188 HMACs appended to the packet; if there is no match, the packet is 189 discarded. 191 In order to protect against replay, B maintains a per-interface 192 32-bit integer known as the "packet counter" (PC). Whenever B sends 193 a packet through the interface, it embeds the current value of the PC 194 within the region of the packet that is protected by the HMACs and 195 increases the PC by at least one. When A receives the packet, it 196 compares the value of the PC with the one contained in the previous 197 packet received from B, and unless it is strictly greater, the packet 198 is discarded. 200 By itself, the PC mechanism is not sufficient to protect against 201 replay. Consider a peer A that has no information about a peer B 202 (e.g., because it has recently rebooted). Suppose that A receives a 203 packet ostensibly from B carrying a given PC; since A has no 204 information about B, it has no way to determine whether the packet is 205 freshly generated or a replay of a previously sent packet. 207 In this situation, A discards the packet and challenges B to prove 208 that it knows the HMAC key. It sends a "challenge request", a TLV 209 containing a unique nonce, a value that has never been used before 210 and will never be used again. B replies to the challenge request 211 with a "challenge reply", a TLV containing a copy of the nonce chosen 212 by A, in a packet protected by HMAC and containing the new value of 213 B's PC. Since the nonce has never been used before, B's reply proves 214 B's knowledge of the HMAC key and the freshness of the PC. 216 By itself, this mechanism is safe against replay if B never resets 217 its PC. In practice, however, this is difficult to ensure, as 218 persistent storage is prone to failure, and hardware clocks, even 219 when available, are occasionally reset. Suppose that B resets its PC 220 to an earlier value, and sends a packet with a previously used PC n. 221 A challenges B, B successfully responds to the challenge, and A 222 accepts the PC equal to n + 1. At this point, an attacker C may send 223 a replayed packet with PC equal to n + 2, which will be accepted by 224 A. 226 Another mechanism is needed to protect against this attack. In this 227 protocol, every PC is tagged with an "index", an arbitrary string of 228 octets. Whenever B resets its PC, or whenever B doesn't know whether 229 its PC has been reset, it picks an index that it has never used 230 before (either by drawing it randomly or by using a reliable hardware 231 clock) and starts sending PCs with that index. Whenever A detects 232 that B has changed its index, it challenges B again. 234 With this additional mechanism, this protocol is invulnerable to 235 replay attacks (see Section 1.2 above). 237 3. Data Structures 239 Every Babel node maintains a set of conceptual data structures 240 described in Section 3.2 of [RFC6126bis]. This protocol extends 241 these data structures as follows. 243 3.1. The Interface Table 245 Every Babel node maintains an interface table, as described in 246 Section 3.2.3 [RFC6126bis]. Implementations of this protocol MUST 247 allow each interface to be provisioned with a set of one or more HMAC 248 keys and the associated HMAC algorithms (see Section 4.1). In order 249 to allow incremental deployment of this protocol (see Appendix A), 250 implementations SHOULD allow an interface to be configured in a mode 251 in which it participates in the HMAC authentication protocol but 252 accepts packets that are not authentified. 254 This protocol extends each entry in this table that is associated 255 with an interface on which HMAC authentication has been configured 256 with two new pieces of data: 258 o a set of one or more HMAC keys, each associated with a given HMAC 259 algorithm ; the length of each key is exactly the hash size of the 260 associated HMAC algorithm (i.e., the key is not subject to the 261 preprocessing described in Section 2 of [RFC2104]); 263 o a pair (Index, PC), where Index is an arbitrary string of 0 to 32 264 octets, and PC is a 32-bit (4-octet) integer. 266 We say that an index is fresh when it has never been used before with 267 any of the keys currently configured on the interface. The Index 268 field is initialised to a fresh index, for example by drawing a 269 random string of sufficient length, and the PC is initialised to an 270 arbitrary value (typically 0). 272 3.2. The Neighbour table 274 Every Babel node maintains a neighbour table, as described in 275 Section 3.2.4 of [RFC6126bis]. This protocol extends each entry in 276 this table with two new pieces of data: 278 o a pair (Index, PC), where Index is a string of 0 to 32 octets, and 279 PC is a 32-bit (4-octet) integer; 281 o a Nonce, which is an arbitrary string of 0 to 192 octets, and an 282 associated challenge expiry timer. 284 The Index and PC are initially undefined, and are managed as 285 described in Section 4.3. The Nonce and expiry timer are initially 286 undefined, and used as described in Section 4.3.1.1. 288 4. Protocol Operation 290 4.1. HMAC computation 292 A Babel node computes the HMAC of a Babel packet as follows. 294 First, the node builds a pseudo-header that will participate in HMAC 295 computation but will not be sent. If the packet was carried over 296 IPv6, the pseudo-header has the following format: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 + + 303 | | 304 + Src address + 305 | | 306 + + 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Src port | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 311 | | 312 + + 313 | Dest address | 314 + + 315 | | 316 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | Dest port | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 If the packet was carried over IPv4, the pseudo-header has the 321 following format: 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Src address | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Src port | Dest address | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | Dest port | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Fields : 334 Src address The source IP address of the packet. 336 Src port The source UDP port number of the packet. 338 Dest address The destination IP address of the packet. 340 Src port The destination UDP port number of the packet. 342 The node takes the concatenation of the pseudo-header and the packet 343 including the packet header but excluding the packet trailer (from 344 octet 0 inclusive up to (Body Length + 4) exclusive) and computes an 345 HMAC with one of the implemented hash algorithms. Every 346 implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and 347 Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and 348 MAY implement other HMAC algorithms. 350 4.2. Packet Transmission 352 A Babel node might delay actually sending TLVs by a small amount, in 353 order to aggregate multiple TLVs in a single packet up to the 354 interface MTU (Section 4 of [RFC6126bis]). For an interface on which 355 HMAC protection is configured, the TLV aggregation logic MUST take 356 into account the overhead due to PC TLVs (one in each packet) and 357 HMAC TLVs (one per configured key). 359 Before sending a packet, the following actions are performed: 361 o a PC TLV containing the PC and Index associated with the outgoing 362 interface MUST be appended to the packet body; the PC MUST be 363 incremented by a strictly positive amount (typically just 1); if 364 the PC overflows, a fresh index MUST be generated (as defined in 365 Section 3.1); a node MUST NOT include multiple PC TLVs in a single 366 packet; 368 o for each key configured on the interface, an HMAC is computed as 369 specified in Section 4.1 above, and stored in an HMAC TLV that 370 MUST be appended to the packet trailer (see Section 4.2 of 371 [RFC6126bis]). 373 4.3. Packet Reception 375 When a packet is received on an interface that is configured for HMAC 376 protection, the following steps are performed before the packet is 377 passed to normal processing: 379 o First, the receiver checks whether the trailer of the received 380 packet carries at least one HMAC TLV; if not, the packet MUST be 381 immediately dropped and processing stops. Then, for each key 382 configured on the receiving interface, the receiver computes the 383 HMAC of the packet. It then compares every generated HMAC against 384 every HMAC included in the packet; if there is at least one match, 385 the packet passes the HMAC test; if there is none, the packet MUST 386 be silently dropped and processing stops at this point. In order 387 to avoid memory exhaustion attacks, an entry in the Neighbour 388 Table MUST NOT be created before the HMAC test has passed 389 successfully. The HMAC of the packet MUST NOT be computed for 390 each HMAC TLV contained in the packet, but only once for each 391 configured key. 393 o The packet body is then parsed a first time. During this 394 "preparse" phase, the packet body is traversed and all TLVs are 395 ignored except PC TLVs, Challenge Requests and Challenge Replies. 396 When a PC TLV is encountered, the enclosed PC and Index are saved 397 for later processing; if multiple PCs are found (which should not 398 happen, see Section 4.2 above), only the first one is processed, 399 the remaining ones MUST be silently ignored. If a Challenge 400 Request is encountered, a Challenge Reply MUST be scheduled, as 401 described in Section 4.3.1.2. If a Challenge Reply is 402 encountered, it is tested for validity as described in 403 Section 4.3.1.3 and a note is made of the result of the test. 405 o The preparse phase above has yielded two pieces of data: the PC 406 and Index from the first PC TLV, and a bit indicating whether the 407 packet contains a successful Challenge Reply. If the packet does 408 not contain a PC TLV, the packet MUST be dropped and processing 409 stops at this point. If the packet contains a successful 410 Challenge Reply, then the PC and Index contained in the PC TLV 411 MUST be stored in the Neighbour Table entry corresponding to the 412 sender (which may need to be created at this stage), and the 413 packet is accepted. 415 o Otherwise, if there is no entry in the Neighbour 416 Table corresponding to the sender, or if such an entry exists but 417 contains no Index, or if the Index it contains is different from 418 the Index contained in the PC TLV, then a challenge MUST be sent 419 as described in Section 4.3.1.1, the packet MUST be dropped, and 420 processing stops at this stage. 422 o At this stage, the packet contains no successful challenge reply 423 and the Index contained in the PC TLV is equal to the Index in the 424 Neighbour Table entry corresponding to the sender. The receiver 425 compares the received PC with the PC contained in the Neighbour 426 Table; if the received PC is smaller or equal than the PC 427 contained in the Neighbour Table, the packet MUST be dropped and 428 processing stops (no challenge is sent in this case, since the 429 mismatch might be caused by harmless packet reordering on the 430 link). Otherwise, the PC contained in the Neighbour Table entry 431 is set to the received PC, and the packet is accepted. 433 In the algorithm described above, challenge requests are processed 434 and challenges are sent before the PC/Index pair is verified against 435 the neighbour table. This simplifies the implementation somewhat 436 (the node may simply schedule outgoing requests as it walks the 437 packet during the preparse phase), but relies on the rate-limiting 438 described in Section 4.3.1.1 to avoid sending too many challenges in 439 response to replayed packets. As an optimisation, a node MAY ignore 440 all challenge requests contained in a packet except the last one, and 441 it MAY ignore a challenge request in the case where it it contained 442 in a packet with an Index that matches the one in the Neighbour 443 Table and a PC that is smaller or equal to the one contained in the 444 Neighbour Table. Since it is still possible to replay a packet with 445 an obsolete Index, the rate-limiting described in Section 4.3.1.1 is 446 required even if this optimisation is implemented. 448 The same is true of challenge replies. However, since validating a 449 challenge reply is extremely cheap (it's just a bitwise comparison of 450 two strings of octets), a similar optimisation for challenge replies 451 is not worthwile. 453 After the packet has been accepted, it is processed as normal, except 454 that any PC, Challenge Request and Challenge Reply TLVs that it 455 contains are silently ignored. 457 4.3.1. Challenge Requests and Replies 459 During the preparse stage, the receiver might encounter a mismatched 460 Index, to which it will react by scheduling a Challenge Request. It 461 might encounter a Challenge Request TLV, to which it will reply with 462 a Challenge Reply TLV. Finally, it might encounter a Challenge Reply 463 TLV, which it will attempt to match with a previously sent Challenge 464 Request TLV in order to update the Neighbour Table entry 465 corresponding to the sender of the packet. 467 4.3.1.1. Sending challenges 469 When it encounters a mismatched Index during the preparse phase, a 470 node picks a nonce that it has never used with any of the keys 471 currently configured on the relevant interface, for example by 472 drawing a sufficiently large random string of bytes or by consulting 473 a strictly monotonic hardware clock. It MUST then store the nonce in 474 the entry of the Neighbour Table associated to the neighbour (the 475 entry might need to be created at this stage), initialise the 476 neighbour's challenge expiry timer to 30 seconds, and send a 477 Challenge Request TLV to the unicast address corresponding to the 478 neighbour. 480 A node MAY aggregate a Challenge Request with other TLVs; in other 481 words, if it has already buffered TLVs to be sent to the unicast 482 address of the neighbour, it MAY send the buffered TLVs in the same 483 packet as the Challenge Request. However, it MUST arrange for the 484 Challenge Request to be sent in a timely manner, as any packets 485 received from that neighbour will be silently ignored until the 486 challenge completes. 488 Since a challenge may be prompted by a packet replayed by an 489 attacker, a node MUST impose a rate limitation to the challenges it 490 sends; the limit SHOULD default to one challenge request every 300ms, 491 and MAY be configurable. 493 4.3.1.2. Replying to challenges 495 When it encounters a Challenge Request during the preparse phase, a 496 node constructs a Challenge Reply TLV by copying the Nonce from the 497 Challenge Request into the Challenge Reply. It MUST then send the 498 Challenge Reply to the unicast address from which the Challenge 499 Request was sent. 501 A node MAY aggregate a Challenge Reply with other TLVs; in other 502 words, if it has already buffered TLVs to be sent to the unicast 503 address of the sender of the Challenge Request, it MAY send the 504 buffered TLVs in the same packet as the Challenge Reply. However, it 505 MUST arrange for the Challenge Reply to be sent in a timely manner 506 (within a few seconds), and SHOULD NOT send any other packets over 507 the same interface before sending the Challenge Reply, as those would 508 be dropped by the challenger. 510 A challenge sent to a multicast address MUST be silently ignored. 512 4.3.1.3. Receiving challenge replies 514 When it encounters a Challenge Reply during the preparse phase, a 515 node consults the Neighbour Table entry corresponding to the 516 neighbour that sent the Challenge Reply. If no challenge is in 517 progress, i.e., if there is no Nonce stored in the Neighbour 518 Table entry or the Challenge timer has expired, the Challenge Reply 519 MUST be silently ignored and the challenge has failed. 521 Otherwise, the node compares the Nonce contained in the Challenge 522 Reply with the Nonce contained in the Neighbour Table entry. If the 523 two are equal (they have the same length and content), then the 524 challenge has succeeded; otherwise, the challenge has failed. 526 4.4. Expiring per-neighbour state 528 The per-neighbour (Index, PC) pair is maintained in the neighbour 529 table, and is normally discarded when the neighbour table entry 530 expires. Implementations MUST ensure that an (Index, PC) pair is 531 discarded within a finite time since the last time a packet has been 532 accepted. In particular, unsuccessful challenges MUST NOT prevent an 533 (Index, PC) pair from being discarded for unbounded periods of time. 535 A possible implementation strategy for implementations that use a 536 Hello history (Appendix A of [RFC6126bis]) is to discard the (Index, 537 PC) pair whenever the Hello history becomes empty. Another 538 implementation strategy is to use a timer that is reset whenever a 539 packet is accepted, and to discard the (Index, PC) pair whenever the 540 timer expires. If the latter strategy is being used, the timer 541 SHOULD default to a value of 5 min, and MAY be configurable. 543 5. Packet Format 545 5.1. HMAC TLV 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type = 16 | Length | HMAC... 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 553 Fields : 555 Type Set to 16 to indicate an HMAC TLV. 557 Length The length of the body, in octets, exclusive of the Type 558 and Length fields. The length of the body depends on the 559 HMAC algorithm being used. 561 HMAC The body contains the HMAC of the packet, computed as 562 described in Section 4.1. 564 This TLV is allowed in the packet trailer (see Section 4.2 of 565 [RFC6126bis]), and MUST be ignored if it is found in the packet body. 567 5.2. PC TLV 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Type = 17 | Length | PC | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | | Index... 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 577 Fields : 579 Type Set to 17 to indicate a PC TLV. 581 Length The length of the body, in octets, exclusive of the Type 582 and Length fields. 584 PC The Packet Counter (PC), a 32-bit (4 octet) unsigned 585 integer which is increased with every packet sent over this 586 interface. A fresh index (as defined in Section 3.1) MUST 587 be generated whenever the PC overflows. 589 Index The sender's Index, an opaque string of 0 to 32 octets. 591 Indices are limited to a size of 32 octets: a node MUST NOT send a 592 TLV with an index of size strictly larger than 32 octets, and a node 593 MAY ignore a PC TLV with an index of length strictly larger than 32 594 octets. Indices of length 0 are valid: if a node has reliable stable 595 storage and the packet counter never overflows, then only one index 596 is necessary, and the value of length 0 is the canonical choice. 598 5.3. Challenge Request TLV 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type = 18 | Length | Nonce... 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 606 Fields : 608 Type Set to 18 to indicate a Challenge Request TLV. 610 Length The length of the body, in octets, exclusive of the Type 611 and Length fields. 613 Nonce The nonce uniquely identifying the challenge, an opaque 614 string of 0 to 192 octets. 616 Nonces are limited to a size of 192 octets: a node MUST NOT send a 617 Challenge Request TLV with a nonce of size strictly larger than 192 618 octets, and a node MAY ignore a nonce that is of size strictly larger 619 than 192 octets. Nonces of length 0 are valid: if a node has 620 reliable stable storage, then it may use a sequential counter for 621 generating nonces which get encoded in the minumum number of octets 622 required; the value 0 is then encoded as the string of length 0. 624 5.4. Challenge Reply TLV 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Type = 19 | Length | Nonce... 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 632 Fields : 634 Type Set to 19 to indicate a Challenge Reply TLV. 636 Length The length of the body, in octets, exclusive of the Type 637 and Length fields. 639 Nonce A copy of the nonce contained in the corresponding 640 challenge request. 642 6. Security Considerations 644 This document defines a mechanism that provides basic security 645 properties for the Babel routing protocol. The scope of this 646 protocol is strictly limited: it only provides authentication (we 647 assume that routing information is not confidential), it only 648 supports symmetric keying, and it only allows for the use of a small 649 number of symmetric keys on every link. Deployments that need more 650 features, e.g., confidentiality or asymmetric keying, should use a 651 more featureful security mechanism such as the one described in 652 [I-D.ietf-babel-dtls]. 654 This mechanism relies on two assumptions, as described in 655 Section 1.2. First, it assumes that the hash being used is 656 invulnerable to pre-image attacks (Section 1.1 of [RFC6039]); at the 657 time of writing, SHA-256, which is mandatory to implement 658 (Section 4.1), is believed to be safe against practical attacks. 660 Second, it assumes that indices and nonces are generated uniquely 661 over the lifetime of a key used for HMAC computation (more precisely, 662 indices must be unique for a given (key, source) pair, and nonces 663 must be unique for a given (key, source, destination) triple). This 664 property can be satisfied either by using a cryptographically secure 665 random number generator to generate indices and nonces that contain 666 enough entropy (64-bit values are believed to be large enough for all 667 practical applications), or by using a reliably monotonic hardware 668 clock. If uniqueness cannot be guaranteed (e.g., because a hardware 669 clock has been reset), then rekeying is necessary. 671 The expiry mechanism mandated in Section 4.4 is required to prevent 672 an attacker from delaying an authentic packet by an unbounded amount 673 of time. If an attacker is able to delay the delivery of a packet 674 (e.g., because it is located at a layer 2 switch), then the packet 675 will be accepted as long as the corresponding (Index, PC) pair is 676 present at the receiver. If the attacker is able to cause the 677 (Index, PC) pair to persist for arbitrary amounts of time (e.g., by 678 repeatedly causing failed challenges), then it is able to delay the 679 packet by arbitrary amounts of time, even after the sender has left 680 the network. 682 While it is probably not possible to be immune against denial of 683 service (DoS) attacks in general, this protocol includes a number of 684 mechanisms designed to mitigate such attacks. In particular, 685 reception of a packet with no correct HMAC creates no local state 686 whatsoever (Section 4.3). Reception of a replayed packet with 687 correct hash, on the other hand, causes a challenge to be sent; this 688 is mitigated somewhat by requiring that challenges be rate-limited. 690 At first sight, sending a challenge requires retaining enough 691 information to validate the challenge reply. However, the nonce 692 included in a challenge request and echoed in the challenge reply can 693 be fairly large (up to 192 octets), which should in principle permit 694 encoding the per-challenge state as a secure "cookie" within the 695 nonce itself. 697 7. IANA Considerations 699 IANA has allocated the following values in the Babel TLV Types 700 registry: 702 +------+-------------------+---------------+ 703 | Type | Name | Reference | 704 +------+-------------------+---------------+ 705 | 16 | HMAC | this document | 706 | | | | 707 | 17 | PC | this document | 708 | | | | 709 | 18 | Challenge Request | this document | 710 | | | | 711 | 19 | Challenge Reply | this document | 712 +------+-------------------+---------------+ 714 8. Acknowledgments 716 The protocol described in this document is based on the original HMAC 717 protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- 718 header was suggested by David Schinazi. The use of an index to avoid 719 replay was suggested by Markus Stenberg. The authors are also 720 indebted to Donald Eastlake, Toke Hoiland-Jorgensen, Florian Horn, 721 Dave Taht and Martin Vigoureux. 723 9. References 725 9.1. Normative References 727 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 728 Hashing for Message Authentication", RFC 2104, 729 DOI 10.17487/RFC2104, February 1997, 730 . 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, 734 DOI 10.17487/RFC2119, March 1997. 736 [RFC6126bis] 737 Chroboczek, J. and D. Schinazi, "The Babel Routing 738 Protocol", draft-ietf-babel-rfc6126bis-06 (work in 739 progress), October 2018. 741 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 742 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 743 DOI 10.17487/RFC6234, May 2011, 744 . 746 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 747 Cryptographic Hash and Message Authentication Code (MAC)", 748 RFC 7693, DOI 10.17487/RFC7693, November 2015, 749 . 751 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 752 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 753 May 2017. 755 9.2. Informational References 757 [I-D.ietf-babel-dtls] 758 Decimo, A., Schinazi, D., and J. Chroboczek, "Babel 759 Routing Protocol over Datagram Transport Layer Security", 760 draft-ietf-babel-dtls-01 (work in progress), October 2018. 762 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 763 "Randomness Requirements for Security", BCP 106, RFC 4086, 764 DOI 10.17487/RFC4086, June 2005, 765 . 767 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 768 with Existing Cryptographic Protection Methods for Routing 769 Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, 770 . 772 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 773 (HMAC) Cryptographic Authentication", RFC 7298, 774 DOI 10.17487/RFC7298, July 2014, 775 . 777 Appendix A. Incremental deployment and key rotation 779 This protocol supports incremental deployment (transitioning from an 780 insecure network to a secured network with no service interruption) 781 and key rotation (transitioning from a set of keys to a different set 782 of keys). 784 In order to perform incremental deployment, the nodes in the network 785 are first configured in a mode where packets are sent with 786 authentication but not checked on reception. Once all the nodes in 787 the network are configured to send authenticated packets, nodes are 788 reconfigured to reject unauthenticated packets. 790 In order to perform key rotation, the new key is added to all the 791 nodes; once this is done, both the old and the new key are sent in 792 all packets, and packets are accepted if they are properly signed by 793 either of the keys. At that point, the old key is removed. 795 In order to support incremental deployment and key rotation, 796 implementations SHOULD support an interface configuration in which 797 they send authenticated packets but accept all packets, and SHOULD 798 allow changing the set of keys associated with an interface without a 799 restart. 801 Appendix B. Changes from previous versions 803 [RFC Editor: please remove this section before publication.] 805 B.1. Changes since draft-ietf-babel-hmac-00 807 o Changed the title. 809 o Removed the appendix about the packet trailer, this is now in 810 rfc6126bis. 812 o Removed the appendix with implicit indices. 814 o Clarified the definitions of acronyms. 816 o Limited the size of nonces and indices. 818 B.2. Changes since draft-ietf-babel-hmac-01 820 o Made BLAKE2s a recommended HMAC algorithm. 822 o Added requirement to expire per-neighbour crypto state. 824 B.3. Changes since draft-ietf-babel-hmac-02 826 o Clarified that PCs are 32-bit unsigned integers. 828 o Clarified that indices and nonces are of arbitrary size. 830 o Added reference to RFC 4086. 832 B.4. Changes since draft-ietf-babel-hmac-03 834 o Use the TLV values allocated by IANA. 836 o Fixed an issue with packets that contain a successful challenge 837 reply: they should be accepted before checking the PC value. 839 o Clarified that keys are the exact value of the HMAC hash size, and 840 not subject to preprocessing; this makes management more 841 deterministic. 843 B.5. Changes since draft-ietf-babel-hmac-04 845 o Use normative language in more places. 847 B.6. Changes since draft-ietf-babel-hmac-05 849 o Do not update RFC 6126bis. 851 o Clarify that indices and nonces of length 0 are valid. 853 o Clarify that multiple PC TLVs in a single packet are not allowed. 855 o Allow discarding challenge requests when they carry an old PC. 857 B.7. Changes since draft-ietf-babel-hmac-06 859 o Do not update RFC 6126bis, for real this time. 861 Authors' Addresses 863 Clara Do 864 IRIF, University of Paris-Diderot 865 75205 Paris Cedex 13 866 France 868 Email: clarado_perso@yahoo.fr 870 Weronika Kolodziejak 871 IRIF, University of Paris-Diderot 872 75205 Paris Cedex 13 873 France 875 Email: weronika.kolodziejak@gmail.com 877 Juliusz Chroboczek 878 IRIF, University of Paris-Diderot 879 Case 7014 880 75205 Paris Cedex 13 881 France 883 Email: jch@irif.fr