idnits 2.17.1 draft-ietf-babel-hmac-04.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6126bis, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document updates RFC6126, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2019) is 1875 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 (==), 4 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 Updates: 6126bis (if approved) IRIF, University of Paris-Diderot 6 Intended status: Standards Track March 9, 2019 7 Expires: September 10, 2019 9 HMAC authentication for the Babel routing protocol 10 draft-ietf-babel-hmac-04 12 Abstract 14 This document describes a cryptographic authentication mechanism for 15 the Babel routing protocol that has provisions for replay avoidance. 16 This document updates RFC 6126bis and obsoletes RFC 7298. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 10, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Assumptions and security properties . . . . . . . . . . . 3 55 1.3. Specification of Requirements . . . . . . . . . . . . . . 4 56 2. Conceptual overview of the protocol . . . . . . . . . . . . . 4 57 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6 59 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 60 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7 62 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8 63 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 64 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 11 65 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 11 67 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 12 69 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 13 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 75 9.2. Informational References . . . . . . . . . . . . . . . . 16 76 Appendix A. Incremental deployment and key rotation . . . . . . 16 77 Appendix B. Changes from previous versions . . . . . . . . . . . 17 78 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 17 79 B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 17 80 B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 17 81 B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 By default, the Babel routing protocol trusts the information 87 contained in every UDP packet it receives on the Babel port. An 88 attacker can redirect traffic to itself or to a different node in the 89 network, causing a variety of potential issues. In particular, an 90 attacker might: 92 o spoof a Babel packet, and redirect traffic by announcing a smaller 93 metric, a larger seqno, or a longer prefix; 95 o spoof a malformed packet, which could cause an insufficiently 96 robust implementation to crash or interfere with the rest of the 97 network; 99 o replay a previously captured Babel packet, which could cause 100 traffic to be redirected or otherwise interfere with the network. 102 Protecting a Babel network is challenging due to the fact that the 103 Babel protocol uses both unicast and multicast communication. One 104 possible approach, used notably by the Babel over Datagram Transport 105 Layer Security (DTLS) protocol [I-D.ietf-babel-dtls], is to use 106 unicast communication for all semantically significant communication, 107 and then use a standard unicast security protocol to protect the 108 Babel traffic. In this document, we take the opposite approach: we 109 define a cryptographic extension to the Babel protocol that is able 110 to protect both unicast and multicast traffic, and thus requires very 111 few changes to the core protocol. 113 1.1. Applicability 115 The protocol defined in this document assumes that all interfaces on 116 a given link are equally trusted and share a small set of symmetric 117 keys (usually just one, and two during key rotation). The protocol 118 is inapplicable in situations where asymmetric keying is required, 119 where the trust relationship is partial, or where large numbers of 120 trusted keys are provisioned on a single link at the same time. 122 This protocol supports incremental deployment (where an insecure 123 Babel network is made secure with no service interruption), and it 124 supports graceful key rotation (where the set of keys is changed with 125 no service interruption). 127 This protocol does not require synchronised clocks, it does not 128 require persistently monotonic clocks, and it does not require 129 persistent storage except for what might be required for storing 130 cryptographic keys. 132 1.2. Assumptions and security properties 134 The correctness of the protocol relies on the following assumptions: 136 o that the Hashed Message Authentication Code (HMAC) being used is 137 invulnerable to pre-image attacks, i.e., that an attacker is 138 unable to generate a packet with a correct HMAC; 140 o that a node never generates the same index or nonce twice over the 141 lifetime of a key. 143 The first assumption is a property of the HMAC being used. The 144 second assumption can be met either by using a robust random number 145 generator [RFC4086] and sufficiently large indices and nonces, by 146 using a reliable hardware clock, or by rekeying whenever a collision 147 becomes likely. 149 If the assumptions above are met, the protocol described in this 150 document has the following properties: 152 o it is invulnerable to spoofing: any packet accepted as authentic 153 is the exact copy of a packet originally sent by an authorised 154 node; 156 o locally to a single node, it is invulnerable to replay: if a node 157 has previously accepted a given packet, then it will never again 158 accept a copy of this packet or an earlier packet from the same 159 sender; 161 o among different nodes, it is only vulnerable to immediate replay: 162 if a node A has accepted a packet from C as valid, then a node B 163 will only accept a copy of that packet as authentic if B has 164 accepted an older packet from C and B has received no later packet 165 from C. 167 While this protocol makes serious efforts to mitigate the effects of 168 a denial of service attack, it does not fully protect against such 169 attacks. 171 1.3. Specification of Requirements 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 2. Conceptual overview of the protocol 181 When a node B sends out a Babel packet through an interface that is 182 configured for HMAC cryptographic protection, it computes one or more 183 HMACs which it appends to the packet. When a node A receives a 184 packet over an interface that requires HMAC cryptographic protection, 185 it independently computes a set of HMACs and compares them to the 186 HMACs appended to the packet; if there is no match, the packet is 187 discarded. 189 In order to protect against replay B maintains a per-interface 32-bit 190 integer known as the "packet counter" (PC). Whenever B sends a 191 packet through the interface, it embeds the current value of the PC 192 within the region of the packet that is protected by the HMACs and 193 increases the PC by at least one. When A receives the packet, it 194 compares the value of the PC with the one contained in the previous 195 packet received from B, and unless it is strictly greater, the packet 196 is discarded. 198 By itself, the PC mechanism is not sufficient to protect against 199 replay. Consider a peer A that has no information about a peer B 200 (e.g., because it has recently rebooted). Suppose that A receives a 201 packet ostensibly from B carrying a given PC; since A has no 202 information about B, it has no way to determine whether the packet is 203 freshly generated or a replay of a previously sent packet. 205 In this situation, A discards the packet and challenges B to prove 206 that it knows the HMAC key. It sends a "challenge request", a TLV 207 containing a unique nonce, a value that has never been used before 208 and will never be used again. B replies to the challenge request 209 with a "challenge reply", a TLV containing a copy of the nonce chosen 210 by A, in a packet protected by HMAC and containing the new value of 211 B's PC. Since the nonce has never been used before, B's reply proves 212 B's knowledge of the HMAC key and the freshness of the PC. 214 By itself, this mechanism is safe against replay if B never resets 215 its PC. In practice, however, this is difficult to ensure, as 216 persistent storage is prone to failure, and hardware clocks, even 217 when available, are occasionally reset. Suppose that B resets its PC 218 to an earlier value, and sends a packet with a previously used PC n. 219 A challenges B, B successfully responds to the challenge, and A 220 accepts the PC equal to n + 1. At this point, an attacker C may send 221 a replayed packet with PC equal to n + 2, which will be accepted by 222 A. 224 Another mechanism is needed to protect against this attack. In this 225 protocol, every PC is tagged with an "index", an arbitrary string of 226 octets. Whenever B resets its PC, or whenever B doesn't know whether 227 its PC has been reset, it picks an index that it has never used 228 before (either by drawing it randomly or by using a reliable hardware 229 clock) and starts sending PCs with that index. Whenever A detects 230 that B has changed its index, it challenges B again. 232 With this additional mechanism, this protocol is invulnerable to 233 replay attacks (see Section 1.2 above). 235 3. Data Structures 237 Every Babel node maintains a set of conceptual data structures 238 described in [RFC6126bis] Section 3.2. This protocol extends these 239 data structures as follows. 241 3.1. The Interface Table 243 Every Babel node maintains an interface table, as described in 244 [RFC6126bis] Section 3.2.3. Implementations of this protocol MUST 245 allow each interface to be provisioned with a set of one or more HMAC 246 keys and the associated HMAC algorithms (see Section 4.1). In order 247 to allow incremental deployment of this protocol (see Appendix A), 248 implementations SHOULD allow an interface to be configured in a mode 249 in which it participates in the HMAC authentication protocol but 250 accepts packets that are not authentified. 252 This protocol extends each entry in this table that is associated 253 with an interface on which HMAC authentication has been configured 254 with two new pieces of data: 256 o a set of one or more HMAC keys, each associated with a given HMAC 257 algorithm ; the length of each key is exactly the hash size of the 258 associated HMAC algorithm (i.e., the key is not subject to the 259 preprocessing described in Section 2 of [RFC2104]); 261 o a pair (Index, PC), where Index is an arbtrary string of 0 to 32 262 octets, and PC is a 32-bit (4-octet) integer. 264 The Index and PC are initialised to arbitrary values chosen so as to 265 ensure that a given (Index, PC) pair is never reused. Typically, the 266 initial Index will be chosen as a random string of sufficient length, 267 and the initial PC will be set to 0. 269 3.2. The Neighbour table 271 Every Babel node maintains a neighbour table, as described in 272 [RFC6126bis] Section 3.2.4. This protocol extends each entry in this 273 table with two new pieces of data: 275 o a pair (Index, PC), where Index is a string of 0 to 32 octets, and 276 PC is a 32-bit (4-octet) integer; 278 o a Nonce, an arbitrary string of 0 to 192 octets, and an associated 279 challenge expiry timer. 281 The Index and PC are initially undefined, and are managed as 282 described in Section 4.3. The Nonce and expiry timer are initially 283 undefined, and used as described in Section 4.3.1.1. 285 4. Protocol Operation 287 4.1. HMAC computation 289 A Babel node computes an HMAC as follows. 291 First, the node builds a pseudo-header that will participate in HMAC 292 computation but will not be sent. If the packet was carried over 293 IPv6, the pseudo-header has the following format: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | | 299 + + 300 | | 301 + Src address + 302 | | 303 + + 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Src port | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 308 | | 309 + + 310 | Dest address | 311 + + 312 | | 313 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | Dest port | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 If the packet was carried over IPv4, the pseudo-header has the 318 following format: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Src address | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Src port | Dest address | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | | Dest port | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Fields : 332 Src address The source IP address of the packet. 334 Src port The source UDP port number of the packet. 336 Dest address The destination IP address of the packet. 338 Src port The destination UDP port number of the packet. 340 The node takes the concatenation of the pseudo-header and the packet 341 including the packet header but excluding the packet trailer (from 342 octet 0 inclusive up to Body Length + 4 exclusive) and computes an 343 HMAC with one of the implemented hash algorithms. Every 344 implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and 345 Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and 346 MAY implement other HMAC algorithms. 348 4.2. Packet Transmission 350 A Babel node may delay actually sending TLVs by a small amount, in 351 order to aggregate multiple TLVs in a single packet up to the 352 interface MTU (Section 4 of [RFC6126bis]). For an interface on which 353 HMAC protection is configured, the TLV aggregation logic MUST take 354 into account the overhead due to PC TLVs (one in each packet) and 355 HMAC TLVs (one per configured key). 357 Before sending a packet, the following actions are performed: 359 o a PC TLV containing the PC and Index associated with the outgoing 360 interface is appended to the packet body; the PC is incremented by 361 a strictly positive amount (typically just 1); if the PC 362 overflows, a fresh index is generated; 364 o for each key configured on the interface, an HMAC is computed as 365 specified in Section 4.1 above, and an HMAC TLV is appended to the 366 packet trailer (see Section 4.2 of [RFC6126bis]). 368 4.3. Packet Reception 370 When a packet is received on an interface that is configured for HMAC 371 protection, the following steps are performed before the packet is 372 passed to normal processing: 374 o First, the receiver checks whether the trailer of the received 375 packet carries at least one HMAC TLV; if not, the packet is 376 immediately dropped and processing stops. Then, for each key 377 configured on the receiving interface, the implementation computes 378 the HMAC of the packet. It then compares every generated HMAC 379 against every HMAC included in the packet; if there is at least 380 one match, the packet passes the HMAC test; if there is none, the 381 packet is silently dropped and processing stops at this point. In 382 order to avoid memory exhaustion attacks, an entry in the 383 Neighbour Table MUST NOT be created before the HMAC test has 384 passed successfully. The HMAC of the packet MUST NOT be computed 385 for each HMAC TLV contained in the packet, but only once for each 386 configured key. 388 o The packet body is then parsed a first time. During this 389 "preparse" phase, the packet body is traversed and all TLVs are 390 ignored except PC TLVs, Challenge Requests and Challenge Replies. 391 When a PC TLV is encountered, the enclosed PC and Index are saved 392 for later processing; if multiple PCs are found, only the first 393 one is processed, the remaining ones are silently ignored. If a 394 Challenge Request is encountered, a Challenge Reply is scheduled, 395 as described in Section 4.3.1.2, and if a Challenge Reply is 396 encountered, it is tested for validity as described in 397 Section 4.3.1.3 and a note is made of the result of the test. 399 o The preparse phase above has yielded two pieces of data: the PC 400 and Index from the first PC TLV, and a bit indicating whether the 401 packet contains a successful Challenge Reply. If the packet does 402 not contain a PC TLV, the packet is dropped and processing stops 403 at this point. If the packet contains a successful Challenge 404 Reply, then the PC and Index contained in the PC TLV are stored in 405 the Neighbour Table entry corresponding to the sender (which may 406 need to be created at this stage), and the packet is accepted. 408 o Otherwise, if there is no entry in the Neighbour 409 Table corresponding to the sender, or if such an entry exists but 410 contains no Index, or if the Index it contains is different from 411 the Index contained in the PC TLV, then a challenge is sent as 412 described in Section 4.3.1.1, processing stops at this stage, and 413 the packet is dropped. 415 o At this stage, the packet contained no successful challenge reply 416 and the Index contained in the PC TLV is equal to the Index in the 417 Neighbour Table entry corresponding to the sender. The receiver 418 compares the received PC with the PC contained in the Neighbour 419 Table; if the received PC is smaller or equal than the PC 420 contained in the Neighbour Table, the packet is silently dropped 421 and processing stops (no challenge is sent in this case, since the 422 mismatch might be caused by harmless packet reordering on the 423 link). Otherwise, the PC contained in the Neighbour Table entry 424 is set to the received PC, and the packet is accepted. 426 After the packet has been accepted, it is processed as normal, except 427 that any PC, Challenge Request and Challenge Reply TLVs that it 428 contains are silently ignored. 430 4.3.1. Challenge Requests and Replies 432 During the preparse stage, the receiver might encounter a mismatched 433 Index, to which it will react by scheduling a Challenge Request. It 434 might encounter a Challenge Request TLV, to which it will reply with 435 a Challenge Reply TLV. Finally, it might encounter a Challenge Reply 436 TLV, which it will attempt to match with a previously sent Challenge 437 Request TLV in order to update the Neighbour Table entry 438 corresponding to the sender of the packet. 440 4.3.1.1. Sending challenges 442 When it encounters a mismatched Index during the preparse phase, a 443 node picks a nonce that it has never used before, for example by 444 drawing a sufficiently large random string of bytes or by consulting 445 a strictly monotonic hardware clock. It stores the nonce in the 446 entry of the Neighbour Table of the neighbour (the entry might need 447 to be created at this stage), initialises the neighbour's challenge 448 expiry timer to 30 seconds, and sends a Challenge Request TLV to the 449 unicast address corresponding to the neighbour. 451 A node MAY aggregate a Challenge Request with other TLVs; in other 452 words, if it has already buffered TLVs to be sent to the unicast 453 address of the sender of the neighbour, it MAY send the buffered TLVs 454 in the same packet as the Challenge Request. However, it MUST 455 arrange for the Challenge Request to be sent in a timely manner, as 456 any packets received from that neighbour will be silently ignored 457 until the challenge completes. 459 Since a challenge may be prompted by a replayed packet, a node MUST 460 impose a rate limitation to the challenges it sends; the limit SHOULD 461 default to one challenge request every 300ms, and MAY be 462 configurable. 464 4.3.1.2. Replying to challenges 466 When it encounters a Challenge Request during the preparse phase, a 467 node constructs a Challenge Reply TLV by copying the Nonce from the 468 Challenge Request into the Challenge Reply. It sends the Challenge 469 Reply to the unicast address from which the Challenge Request was 470 sent. 472 A node MAY aggregate a Challenge Reply with other TLVs; in other 473 words, if it has already buffered TLVs to be sent to the unicast 474 address of the sender of the Challenge Request, it MAY send the 475 buffered TLVs in the same packet as the Challenge Reply. However, it 476 MUST arrange for the Challenge Reply to be sent in a timely manner 477 (within a few seconds), and SHOULD NOT send any other packets over 478 the same interface before sending the Challenge Reply, as those would 479 be dropped by the challenger. 481 A challenge sent to a multicast address MUST be silently ignored. 483 4.3.1.3. Receiving challenge replies 485 When it encounters a Challenge Reply during the preparse phase, a 486 node consults the Neighbour Table entry corresponding to the 487 neighbour that sent the Challenge Reply. If no challenge is in 488 progress, i.e., if there is no Nonce stored in the Neighbour 489 Table entry or the Challenge timer has expired, the Challenge Reply 490 is silently ignored and the challenge has failed. 492 Otherwise, the node compares the Nonce contained in the Challenge 493 Reply with the Nonce contained in the Neighbour Table entry. If the 494 two are equal (they have the same length and content), then the 495 challenge has succeeded; otherwise, the challenge has failed. 497 4.4. Expiring per-neighbour state 499 The per-neighbour (Index, PC) pair is maintained in the neighbour 500 table, and is normally discarded when the neighbour table entry 501 expires. Implementations MUST ensure that an (Index, PC) pair is 502 discarded within a finite time since the last time a packet has been 503 accepted. In particular, unsuccessful challenges MUST NOT prevent an 504 (Index, PC) pair from being discarded for unbounded periods of time. 506 A possible implementation strategy for implementations that use a 507 Hello history (Appendix A of [RFC6126bis]) is to discard the (Index, 508 PC) pair whenever the Hello history becomes empty. Another 509 implementation strategy is to use a timer that is reset whenever a 510 packet is accepted, and to discard the (Index, PC) pair whenever the 511 timer expires. If the latter strategy is being used, the timer 512 SHOULD default to a value of 5 min, and MAY be configurable. 514 5. Packet Format 516 5.1. HMAC TLV 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Type = 16 | Length | HMAC... 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 524 Fields : 526 Type Set to 16 to indicate an HMAC TLV. 528 Length The length of the body, exclusive of the Type and Length 529 fields. The length of the body depends on the hash 530 function used. 532 HMAC The body contains the HMAC of the whole packet plus the 533 pseudo header. 535 This TLV is allowed in the packet trailer (see Section 4.2 of 536 [RFC6126bis]), and MUST be ignored if it is found in the packet body. 538 5.2. PC TLV 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type = 17 | Length | PC 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Index... 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 548 Fields : 550 Type Set to 17 to indicate a PC TLV. 552 Length The length of the body, exclusive of the Type and Length 553 fields. 555 PC The Packet Counter (PC), a 32-bit (4 octet) unsigned 556 integer which is increased with every packet sent over this 557 interface. A fresh index MUST be generated whenever the PC 558 overflows. 560 Index The sender's Index, an opaque string of 0 to 32 octets. 562 Indices are limited to a size of 32 octets: a node MUST NOT send a 563 TLV with an index of size strictly larger than 32 octets, and a node 564 MAY silently ignore a PC TLV with an index of size strictly larger 565 than 32 octets. 567 5.3. Challenge Request 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 = 18 | Length | Nonce... 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 574 Fields : 576 Type Set to 18 to indicate a Challenge Request TLV. 578 Length The length of the body, exclusive of the Type and Length 579 fields. 581 Nonce The nonce uniquely identifying the challenge, an opaque 582 string of 0 to 192 octets. 584 Nonces are limited to a size of 192 octets: a node MUST NOT send a 585 Challenge Request TLV with a nonce of size strictly larger than 192 586 octets, and a node MAY ignore a nonce that is of size strictly larger 587 than 192 octets. 589 5.4. Challenge Reply TLV 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type = 19 | Length | Nonce... 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 597 Fields : 599 Type Set to 19 to indicate a Challenge Reply TLV. 601 Length The length of the body, exclusive of the Type and Length 602 fields. The length of the body is set to the same size as 603 the challenge request TLV length received. 605 Nonce A copy of the nonce contained in the corresponding 606 challenge request. 608 6. Security Considerations 610 This document defines a mechanism that provides basic security 611 properties for the Babel routing protocol. The scope of this 612 protocol is strictly limited: it only provides authentication (we 613 assume that routing information is not confidential), it only 614 supports symmetric keying, and it only allows for the use of a small 615 number of symmetric keys on every link. Deployments that need more 616 features, e.g., confidentiality or asymmetric keying, should use a 617 more featureful security mechanism such as the one described in 618 [I-D.ietf-babel-dtls]. 620 This mechanism relies on two assumptions, as described in 621 Section 1.2. First, it assumes that the hash being used is 622 invulnerable to pre-image attacks (Section 1.1 of [RFC6039]); at the 623 time of writing, SHA-256, which is mandatory to implement 624 (Section 4.1), is believed to be safe against practical attacks. 626 Second, it assumes that indices and nonces are generated uniquely 627 over the lifetime of a key used for HMAC computation (more precisely, 628 indices must be unique for a given (key, source) pair, and nonces 629 must be unique for a given (key, source, destination) triple). This 630 property can be satisfied either by using a cryptographically secure 631 random number generator to generate indices and nonces that contain 632 enough entropy (64-bit values are believed to be large enough for all 633 practical applications), or by using a reliably monotonic hardware 634 clock. If uniqueness cannot be guaranteed (e.g., because a hardware 635 clock has been reset), then rekeying is necessary. 637 The expiry mechanism mandated in Section 4.4 is required to prevent 638 an attacker from delaying an authentic packet by an unbounded amount 639 of time. If an attacker is able to delay the delivery of a packet 640 (e.g., because it is located at a layer 2 switch), then the packet 641 will be accepted as long as the corresponding (Index, PC) pair is 642 present at the receiver. If the attacker is able to cause the 643 (Index, PC) pair to persist for arbitrary amounts of time (e.g., by 644 causing failed challenges), then it is able to delay the packet by 645 arbitrary amounts of time, even after the sender has left the 646 network. 648 While it is probably not possible to be immune against denial of 649 service (DoS) attacks in general, this protocol includes a number of 650 mechanisms designed to mitigate such attacks. In particular, 651 reception of a packet with no correct HMAC creates no local state 652 whatsoever (Section 4.3). Reception of a replayed packet with 653 correct hash, on the other hand, causes a challenge to be sent; this 654 is mitigated somewhat by requiring that challenges be rate-limited. 656 At first sight, sending a challenge requires retaining enough 657 information to validate the challenge reply. However, the nonce 658 included in a challenge request and echoed in the challenge reply can 659 be fairly large (up to 192 octets), which should in principle permit 660 encoding the per-challenge state as a secure "cookie" within the 661 nonce itself. 663 7. IANA Considerations 665 IANA has allocated the following values in the Babel TLV Numbers 666 registry: 668 +------+-------------------+---------------+ 669 | Type | Name | Reference | 670 +------+-------------------+---------------+ 671 | 16 | HMAC | this document | 672 | | | | 673 | 17 | PC | this document | 674 | | | | 675 | 18 | Challenge Request | this document | 676 | | | | 677 | 19 | Challenge Reply | this document | 678 +------+-------------------+---------------+ 680 8. Acknowledgments 682 The protocol described in this document is based on the original HMAC 683 protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- 684 header was suggested by David Schinazi. The use of an index to avoid 685 replay was suggested by Markus Stenberg. The authors are also 686 indebted to Donald Eastlake, Toke Hoiland-Jorgensen, Florian Horn, 687 and Dave Taht. 689 9. References 691 9.1. Normative References 693 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 694 Hashing for Message Authentication", RFC 2104, 695 DOI 10.17487/RFC2104, February 1997, 696 . 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, 700 DOI 10.17487/RFC2119, March 1997. 702 [RFC6126bis] 703 Chroboczek, J. and D. Schinazi, "The Babel Routing 704 Protocol", draft-ietf-babel-rfc6126bis-06 (work in 705 progress), October 2018. 707 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 708 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 709 DOI 10.17487/RFC6234, May 2011, 710 . 712 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 713 Cryptographic Hash and Message Authentication Code (MAC)", 714 RFC 7693, DOI 10.17487/RFC7693, November 2015, 715 . 717 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 718 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 719 May 2017. 721 9.2. Informational References 723 [I-D.ietf-babel-dtls] 724 Decimo, A., Schinazi, D., and J. Chroboczek, "Babel 725 Routing Protocol over Datagram Transport Layer Security", 726 draft-ietf-babel-dtls-01 (work in progress), October 2018. 728 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 729 "Randomness Requirements for Security", BCP 106, RFC 4086, 730 DOI 10.17487/RFC4086, June 2005, 731 . 733 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 734 with Existing Cryptographic Protection Methods for Routing 735 Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, 736 . 738 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 739 (HMAC) Cryptographic Authentication", RFC 7298, 740 DOI 10.17487/RFC7298, July 2014, 741 . 743 Appendix A. Incremental deployment and key rotation 745 This protocol supports incremental deployment (transitioning from an 746 insecure network to a secured network with no service interruption) 747 and key rotation (transitioning from a set of keys to a different set 748 of keys). 750 In order to perform incremental deployment, the nodes in the network 751 are first configured in a mode where packets are sent with 752 authentication but not checked on reception. Once all the nodes in 753 the network are configured to send authenticated packets, nodes are 754 reconfigured to reject unauthenticated packets. 756 In order to perform key rotation, the new key is added to all the 757 nodes; once this is done, both the old and the new key are sent in 758 all packets, and packets are accepted if they are properly signed by 759 either of the keys. At that point, the old key is removed. 761 In order to support incremental deployment and key rotation, 762 implementations SHOULD support an interface configuration in which 763 they send authenticated packets but accept all packets, and SHOULD 764 allow changing the set of keys associated with an interface without a 765 restart. 767 Appendix B. Changes from previous versions 769 [RFC Editor: please remove this section before publication.] 771 B.1. Changes since draft-ietf-babel-hmac-00 773 o Changed the title. 775 o Removed the appendix about the packet trailer, this is now in 776 rfc6126bis. 778 o Removed the appendix with implicit indices. 780 o Clarified the definitions of acronyms. 782 o Limited the size of nonces and indices. 784 B.2. Changes since draft-ietf-babel-hmac-01 786 o Made BLAKE2s a recommended HMAC algorithm. 788 o Added requirement to expire per-neighbour crypto state. 790 B.3. Changes since draft-ietf-babel-hmac-02 792 o Clarified that PCs are 32-bit unsigned integers. 794 o Clarified that indices and nonces are of arbitrary size. 796 o Added reference to RFC 4086. 798 B.4. Changes since draft-ietf-babel-hmac-03 800 o Use the TLV values allocated by IANA. 802 o Fixed an issue with packets that contain a successful challenge 803 reply: they should be accepted before checking the PC value. 805 o Clarified that keys are the exact value of the HMAC hash size, and 806 not subject to preprocessing; this makes management more 807 deterministic. 809 Authors' Addresses 811 Clara Do 812 IRIF, University of Paris-Diderot 813 75205 Paris Cedex 13 814 France 816 Email: clarado_perso@yahoo.fr 818 Weronika Kolodziejak 819 IRIF, University of Paris-Diderot 820 75205 Paris Cedex 13 821 France 823 Email: weronika.kolodziejak@gmail.com 825 Juliusz Chroboczek 826 IRIF, University of Paris-Diderot 827 Case 7014 828 75205 Paris Cedex 13 829 France 831 Email: jch@irif.fr