idnits 2.17.1 draft-ietf-babel-hmac-03.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 (December 26, 2018) is 1945 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 December 26, 2018 7 Expires: June 29, 2019 9 HMAC authentication for the Babel routing protocol 10 draft-ietf-babel-hmac-03 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 June 29, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . 5 59 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 60 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 7 63 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 64 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 10 65 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 11 67 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 12 69 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 9.2. Informational References . . . . . . . . . . . . . . . . 15 76 Appendix A. Incremental deployment and key rotation . . . . . . 15 77 Appendix B. Changes from previous versions . . . . . . . . . . . 16 78 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16 79 B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 16 80 B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 By default, the Babel routing protocol trusts the information 86 contained in every UDP packet it receives on the Babel port. An 87 attacker can redirect traffic to itself or to a different node in the 88 network, causing a variety of potential issues. In particular, an 89 attacker might: 91 o spoof a Babel packet, and redirect traffic by announcing a smaller 92 metric, a larger seqno, or a longer prefix; 94 o spoof a malformed packet, which could cause an insufficiently 95 robust implementation to crash or interfere with the rest of the 96 network; 98 o replay a previously captured Babel packet, which could cause 99 traffic to be redirected or otherwise interfere with the network. 101 Protecting a Babel network is challenging due to the fact that the 102 Babel protocol uses both unicast and multicast communication. One 103 possible approach, used notably by the Babel over Datagram Transport 104 Layer Security (DTLS) protocol [I-D.ietf-babel-dtls], is to use 105 unicast communication for all semantically significant communication, 106 and then use a standard unicast security protocol to protect the 107 Babel traffic. In this document, we take the opposite approach: we 108 define a cryptographic extension to the Babel protocol that is able 109 to protect both unicast and multicast traffic, and thus requires very 110 few changes to the core protocol. 112 1.1. Applicability 114 The protocol defined in this document assumes that all interfaces on 115 a given link are equally trusted and share a small set of symmetric 116 keys (usually just one, and two during key rotation). The protocol 117 is inapplicable in situations where asymmetric keying is required, 118 where the trust relationship is partial, or where large numbers of 119 trusted keys are provisioned on a single link at the same time. 121 This protocol supports incremental deployment (where an insecure 122 Babel network is made secure with no service interruption), and it 123 supports graceful key rotation (where the set of keys is changed with 124 no service interruption). 126 This protocol does not require synchronised clocks, it does not 127 require persistently monotonic clocks, and it does not require 128 persistent storage except for what might be required for storing 129 cryptographic keys. 131 1.2. Assumptions and security properties 133 The correctness of the protocol relies on the following assumptions: 135 o that the Hashed Message Authentication Code (HMAC) being used is 136 invulnerable to pre-image attacks, i.e., that an attacker is 137 unable to generate a packet with a correct HMAC; 139 o that a node never generates the same index or nonce twice over the 140 lifetime of a key. 142 The first assumption is a property of the HMAC being used. The 143 second assumption can be met either by using a robust random number 144 generator [RFC4086] and sufficiently large indices and nonces, by 145 using a reliable hardware clock, or by rekeying whenever a collision 146 becomes likely. 148 If the assumptions above are met, the protocol described in this 149 document has the following properties: 151 o it is invulnerable to spoofing: any packet accepted as authentic 152 is the exact copy of a packet originally sent by an authorised 153 node; 155 o locally to a single node, it is invulnerable to replay: if a node 156 has previously accepted a given packet, then it will never again 157 accept a copy of this packet or an earlier packet from the same 158 sender; 160 o among different nodes, it is only vulnerable to immediate replay: 161 if a node A has accepted a packet from C as valid, then a node B 162 will only accept a copy of that packet as authentic if B has 163 accepted an older packet from C and B has received no later packet 164 from C. 166 While this protocol makes serious efforts to mitigate the effects of 167 a denial of service attack, it does not fully protect against such 168 attacks. 170 1.3. Specification of Requirements 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 2. Conceptual overview of the protocol 180 When a node B sends out a Babel packet through an interface that is 181 configured for cryptographic protection, it computes one or more 182 HMACs which it appends to the packet. When a node A receives a 183 packet over an interface that requires cryptographic protection, it 184 independently computes a set of HMACs and compares them to the HMACs 185 appended to the packet; if there is no match, the packet is 186 discarded. 188 In order to protect against replay B maintains a per-interface 32-bit 189 integer known as the "packet counter" (PC). Whenever B sends a 190 packet through the interface, it embeds the current value of the PC 191 within the region of the packet that is protected by the HMACs and 192 increases the PC by at least one. When A receives the packet, it 193 compares the value of the PC with the one contained in the previous 194 packet received from B, and unless it is strictly greater, the packet 195 is discarded. 197 By itself, the PC mechanism is not sufficient to protect against 198 replay. Consider a peer A that has no information about a peer B 199 (e.g., because it has recently rebooted). Suppose that A receives a 200 packet ostensibly from B carrying a given PC; since A has no 201 information about B, it has no way to determine whether the packet is 202 freshly generated or a replay of a previously sent packet. 204 In this situation, A discards the packet and challenges B to prove 205 that it knows the HMAC key. It sends a "challenge request", a TLV 206 containing a unique nonce, a value that has never been used before 207 and will never be used again. B replies to the challenge request 208 with a "challenge reply", a TLV containing a copy of the nonce chosen 209 by A, in a packet protected by HMAC and containing the new value of 210 B's PC. Since the nonce has never been used before, B's reply proves 211 B's knowledge of the HMAC key and the freshness of the PC. 213 By itself, this mechanism is safe against replay if B never resets 214 its PC. In practice, however, this is difficult to ensure, as 215 persistent storage is prone to failure, and hardware clocks, even 216 when available, are occasionally reset. Suppose that B resets its PC 217 to an earlier value, and sends a packet with a previously used PC n. 218 A challenges B, B successfully responds to the challenge, and A 219 accepts the PC equal to n + 1. At this point, an attacker C may send 220 a replayed packet with PC equal to n + 2, which will be accepted by 221 A. 223 Another mechanism is needed to protect against this attack. In this 224 protocol, every PC is tagged with an "index", an arbitrary string of 225 octets. Whenever B resets its PC, or whenever B doesn't know whether 226 its PC has been reset, it picks an index that it has never used 227 before (either by drawing it randomly or by using a reliable hardware 228 clock) and starts sending PCs with that index. Whenever A detects 229 that B has changed its index, it challenges B again. 231 With this additional mechanism, this protocol is invulnerable to 232 replay attacks (see Section 1.2 above). 234 3. Data Structures 236 3.1. The Interface Table 238 Every Babel node maintains an interface table, as described in 239 [RFC6126bis] Section 3.2.3. This protocol extends the entries in 240 this table with a set of HMAC keys, and a pair (Index, PC), where 241 Index is an arbitrary string of bytes and PC is a 32-bit integer. 242 The Index is initialised to a value that has never been used before 243 (e.g., by choosing a random string of sufficient length). 245 3.2. The Neighbour table 247 Every Babel node maintains a neighbour table, as described in 248 [RFC6126bis] Section 3.2.4. This protocol extends the entries in 249 this table with a pair (Index, PC), as well as a nonce (an arbitrary 250 string of bytes) and a challenge expiry timer. The Index and PC are 251 initially undefined, and are managed as described in Section 4.3. 252 The Nonce and expiry timer are initially undefined and used as 253 described in Section 4.3.1.1. 255 4. Protocol Operation 257 4.1. HMAC computation 259 A Babel node computes an HMAC as follows. 261 First, the node builds a pseudo-header that will participate in HMAC 262 computation but will not be sent. If the packet was carried over 263 IPv6, the pseudo-header has the following format: 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 + + 270 | | 271 + Src address + 272 | | 273 + + 274 | | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Src port | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 278 | | 279 + + 280 | Dest address | 281 + + 282 | | 283 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | Dest port | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 If the packet was carried over IPv4, the pseudo-header has the 288 following format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Src address | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Src port | Dest address | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | Dest port | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Fields : 302 Src address The source IP address of the packet. 304 Src port The source UDP port number of the packet. 306 Dest address The destination IP address of the packet. 308 Src port The destination UDP port number of the packet. 310 The node takes the concatenation of the pseudo-header and the packet 311 including the packet header but excluding the packet trailer (from 312 octet 0 inclusive up to Body Length + 4 exclusive) and computes an 313 HMAC with one of the implemented hash algorithms. Every 314 implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and 315 Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and 316 MAY implement other HMAC algorithms. 318 4.2. Packet Transmission 320 A Babel node may delay actually sending TLVs by a small amount, in 321 order to aggregate multiple TLVs in a single packet up to the 322 interface MTU (Section 4 of [RFC6126bis]). For an interface on which 323 HMAC protection is configured, the TLV aggregation logic MUST take 324 into account the overhead due to PC TLVs (one in each packet) and 325 HMAC TLVs (one per configured key). 327 Before sending a packet, the following actions are performed: 329 o a PC TLV containing the PC and Index associated with the outgoing 330 interface is appended to the packet body; the PC is incremented by 331 a strictly positive amount (typically just 1); if the PC 332 overflows, a fresh index is generated; 334 o for each key configured on the interface, an HMAC is computed as 335 specified in Section 4.1 above, and an HMAC TLV is appended to the 336 packet trailer (see Section 4.2 of [RFC6126bis]). 338 4.3. Packet Reception 340 When a packet is received on an interface that is configured for HMAC 341 protection, the following steps are performed before the packet is 342 passed to normal processing: 344 o First, the receiver checks whether the trailer of the received 345 packet carries at least one HMAC TLV; if not, the packet is 346 immediately dropped and processing stops. Then, for each key 347 configured on the receiving interface, the implementation computes 348 the HMAC of the packet. It then compares every generated HMAC 349 against every HMAC included in the packet; if there is at least 350 one match, the packet passes the HMAC test; if there is none, the 351 packet is silently dropped and processing stops at this point. In 352 order to avoid memory exhaustion attacks, an entry in the 353 Neighbour Table MUST NOT be created before the HMAC test has 354 passed successfully. The HMAC of the packet MUST NOT be computed 355 for each HMAC TLV contained in the packet, but only once for each 356 configured key. 358 o The packet body is then parsed a first time. During this 359 "preparse" phase, the packet body is traversed and all TLVs are 360 ignored except PC TLVs, Challenge Requests and Challenge Replies. 361 When a PC TLV is encountered, the enclosed PC and Index are saved 362 for later processing; if multiple PCs are found, only the first 363 one is processed, the remaining ones are silently ignored. If a 364 Challenge Request is encountered, a Challenge Reply is scheduled, 365 as described in Section 4.3.1.2, and if a Challenge Reply is 366 encountered, it is tested for validity as described in 367 Section 4.3.1.3 and a note is made of the result of the test. 369 o The preparse phase above has yielded two pieces of data: the PC 370 and Index from the first PC TLV, and a bit indicating whether the 371 packet contains a successful Challenge Reply. If the packet does 372 not contain a PC TLV, the packet is dropped and processing stops 373 at this point. If the packet contains a successful Challenge 374 Reply, then the PC and Index contained in the PC TLV are stored in 375 the Neighbour Table entry corresponding to the sender (which may 376 need to be created at this stage). 378 o If there is no entry in the Neighbour Table corresponding to the 379 sender, or if such an entry exists but contains no Index, or if 380 the Index it contains is different from the Index contained in the 381 PC TLV, then a challenge is sent as described in Section 4.3.1.1, 382 processing stops at this stage, and the packet is dropped. 384 o At this stage, the Index contained in the PC TLV is equal to the 385 Index in the Neighbour Table entry corresponding to the sender. 387 The receiver compares the received PC with the PC contained in the 388 Neighbour Table; if the received PC smaller or equal than the PC 389 contained in the Neighbour Table, the packet is silently dropped 390 and processing stops (no challenge is sent in this case, since the 391 mismatch might be caused by harmless packet reordering on the 392 link). Otherwise, the PC contained in the Neighbour Table entry 393 is set to the received PC, and the packet is accepted. 395 After the packet has been accepted, it is processed as normal, except 396 that any PC, Challenge Request and Challenge Reply TLVs that it 397 contains are silently ignored. 399 4.3.1. Challenge Requests and Replies 401 During the preparse stage, the receiver might encounter a mismatched 402 Index, to which it will react by scheduling a Challenge Request. It 403 might encounter a Challenge Request TLV, to which it will reply with 404 a Challenge Reply TLV. Finally, it might encounter a Challenge Reply 405 TLV, which it will attempt to match with a previously sent Challenge 406 Request TLV in order to update the Neighbour Table entry 407 corresponding to the sender of the packet. 409 4.3.1.1. Sending challenges 411 When it encounters a mismatched Index during the preparse phase, a 412 node picks a nonce that it has never used before, for example by 413 drawing a sufficiently large random string of bytes or by consulting 414 a strictly monotonic hardware clock. It stores the nonce in the 415 entry of the Neighbour Table of the neighbour (the entry might need 416 to be created at this stage), initialises the neighbour's challenge 417 expiry timer to 30 seconds, and sends a Challenge Request TLV to the 418 unicast address corresponding to the neighbour. 420 A node MAY aggregate a Challenge Request with other TLVs; in other 421 words, if it has already buffered TLVs to be sent to the unicast 422 address of the sender of the neighbour, it MAY send the buffered TLVs 423 in the same packet as the Challenge Request. However, it MUST 424 arrange for the Challenge Request to be sent in a timely manner, as 425 any packets received from that neighbour will be silently ignored 426 until the challenge completes. 428 Since a challenge may be prompted by a replayed packet, a node MUST 429 impose a rate limitation to the challenges it sends; a limit of one 430 challenge every 300ms for each neighbour is suggested. 432 4.3.1.2. Replying to challenges 434 When it encounters a Challenge Request during the preparse phase, a 435 node constructs a Challenge Reply TLV by copying the Nonce from the 436 Challenge Request into the Challenge Reply. It sends the Challenge 437 Reply to the unicast address of the sender of the Challenge Reply. 439 A node MAY aggregate a Challenge Reply with other TLVs; in other 440 words, if it has already buffered TLVs to be sent to the unicast 441 address of the sender of the Challenge Request, it MAY send the 442 buffered TLVs in the same packet as the Challenge Reply. However, it 443 MUST arrange for the Challenge Reply to be sent in a timely manner 444 (within a few seconds), and SHOULD NOT send any other packets over 445 the same interface before sending the Challenge Reply, as those would 446 be dropped by the challenger. 448 A challenge sent to a multicast address MUST be silently ignored. 450 4.3.1.3. Receiving challenge replies 452 When it encounters a Challenge Reply during the preparse phase, a 453 node consults the Neighbour Table entry corresponding to the 454 neighbour that sent the Challenge Reply. If no challenge is in 455 progress, i.e., if there is no Nonce stored in the Neighbour 456 Table entry or the Challenge timer has expired, the Challenge Reply 457 is silently ignored and the challenge has failed. 459 Otherwise, the node compares the Nonce contained in the Challenge 460 Reply with the Nonce contained in the Neighbour Table entry. If the 461 two are equal (they have the same length and content), then the 462 challenge has succeeded; otherwise, the challenge has failed. 464 4.4. Expiring per-neighbour state 466 The per-neighbour (Index, PC) pair is maintained in the neighbour 467 table, and is normally discarded when the neighbour table entry 468 expires. Implementations MUST ensure that an (Index, PC) pair is 469 discarded within a finite time since the last time a packet has been 470 accepted. In particular, unsuccessful challenges MUST NOT prevent an 471 (Index, PC) pair from being discarded for unbounded periods of time. 473 Implementations that use a Hello history (Appendix A of [RFC6126bis]) 474 may discard the (Index, PC) pair whenever the Hello history becomes 475 empty. Other impementations may use a timer that is reset whenever a 476 packet is accepted, and discard the (Index, PC) pair whenever the 477 timer expires (a timeout of 5 min is suggested). 479 5. Packet Format 481 5.1. HMAC TLV 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Type | Length | HMAC... 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 489 Fields : 491 Type Set to TBD to indicate an HMAC TLV. 493 Length The length of the body, exclusive of the Type and Length 494 fields. The length of the body depends on the hash 495 function used. 497 HMAC The body contains the HMAC of the whole packet plus the 498 pseudo header. 500 This TLV is allowed in the packet trailer (see Section 4.2 of 501 [RFC6126bis]), and MUST be ignored if it is found in the packet body. 503 5.2. PC TLV 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Type | Length | PC 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Index... 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 513 Fields : 515 Type Set to TBD to indicate a PC TLV. 517 Length The length of the body, exclusive of the Type and Length 518 fields. 520 PC The Packet Counter (PC), a 32-bit (4 octet) unsigned 521 integer which is increased with every packet sent over this 522 interface. A fresh index MUST be generated whenever the PC 523 overflows. 525 Index The sender's Index, an opaque string of 0 to 32 octets. 527 Indices are limited to a size of 32 octets: a node MUST NOT send a 528 TLV with an index of size strictly larger than 32 octets, and a node 529 MAY silently ignore a PC TLV with an index of size strictly larger 530 than 32 octets. 532 5.3. Challenge Request TLV 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Type | Length | Nonce... 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 540 Fields : 542 Type Set to TBD to indicate a Challenge Request TLV. 544 Length The length of the body, exclusive of the Type and Length 545 fields. 547 Nonce The nonce uniquely identifying the challenge, an opaque 548 string of 0 to 192 octets. 550 Nonces are limited to a size of 192 octets: a node MUST NOT send a 551 Challenge Request TLV with a nonce of size strictly larger than 192 552 octets, and a node MAY ignore a nonce that is of size strictly larger 553 than 192 octets. 555 5.4. Challenge Reply TLV 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Type | Length | Nonce... 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 563 Fields : 565 Type Set to TBD to indicate a Challenge Reply TLV. 567 Length The length of the body, exclusive of the Type and Length 568 fields. The length of the body is set to the same size as 569 the challenge request TLV length received. 571 Nonce A copy of the nonce contained in the corresponding 572 challenge request. 574 6. Security Considerations 576 This document defines a mechanism that provides basic security 577 properties for the Babel routing protocol. The scope of this 578 protocol is strictly limited: it only provides authentication (we 579 assume that routing information is not confidential), it only 580 supports symmetric keying, and it only allows for the use of a small 581 number of symmetric keys on every link. Deployments that need more 582 features, e.g., confidentiality or asymmetric keying, should use a 583 more featureful security mechanism such as the one described in 584 [I-D.ietf-babel-dtls]. 586 This mechanism relies on two assumptions, as described in 587 Section 1.2. First, it assumes that the hash being used is 588 invulnerable to pre-image attacks (Section 1.1 of [RFC6039]); at the 589 time of writing, SHA-256, which is mandatory to implement 590 (Section 4.1), is believed to be safe against practical attacks. 592 Second, it assumes that indices and nonces are generated uniquely 593 over the lifetime of a key used for HMAC computation (more precisely, 594 indices must be unique for a given (key, source) pair, and nonces 595 must be unique for a given (key, source, destination) triple). This 596 property can be satisfied either by using a cryptographically secure 597 random number generator to generate indices and nonces that contain 598 enough entropy (64-bit values are believed to be large enough for all 599 practical applications), or by using a reliably monotonic hardware 600 clock. If uniqueness cannot be guaranteed (e.g., because a hardware 601 clock has been reset), then rekeying is necessary. 603 The expiry mechanism mandated in Section 4.4 is required to prevent 604 an attacker from delaying an authentic packet by an unbounded amount 605 of time. If an attacker is able to delay the delivery of a packet 606 (e.g., because it is located at a layer 2 switch), then the packet 607 will be accepted as long as the corresponding (Index, PC) pair is 608 present at the receiver. If the attacker is able to cause the 609 (Index, PC) pair to persist for arbitrary amounts of time (e.g., by 610 causing failed challenges), then it is able to delay the packet by 611 arbitrary amounts of time, even after the sender has left the 612 network. 614 While it is probably not possible to be immune against denial of 615 service (DoS) attacks in general, this protocol includes a number of 616 mechanisms designed to mitigate such attacks. In particular, 617 reception of a packet with no correct HMAC creates no local state 618 whatsoever (Section 4.3). Reception of a replayed packet with 619 correct hash, on the other hand, causes a challenge to be sent; this 620 is mitigated somewhat by requiring that challenges be rate-limited. 622 At first sight, sending a challenge requires retaining enough 623 information to validate the challenge reply. However, the nonce 624 included in a challenge request and echoed in the challenge reply can 625 be fairly large (up to 192 octets), which should in principle permit 626 encoding the per-challenge state as a secure "cookie" within the 627 nonce itself. 629 7. IANA Considerations 631 IANA is requested to allocate the following values in the Babel TLV 632 Numbers registry: 634 +------+-------------------+---------------+ 635 | Type | Name | Reference | 636 +------+-------------------+---------------+ 637 | TBD | HMAC | this document | 638 | | | | 639 | TBD | PC | this document | 640 | | | | 641 | TBD | Challenge Request | this document | 642 | | | | 643 | TBD | Challenge Reply | this document | 644 +------+-------------------+---------------+ 646 8. Acknowledgments 648 The protocol described in this document is based on the original HMAC 649 protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- 650 header was suggested by David Schinazi. The use of an index to avoid 651 replay was suggested by Markus Stenberg. The authors are also 652 indebted to Toke Hoiland-Jorgensen, Florian Horn, and Dave Taht. 654 9. References 656 9.1. Normative References 658 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 659 Hashing for Message Authentication", RFC 2104, 660 DOI 10.17487/RFC2104, February 1997, 661 . 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, 665 DOI 10.17487/RFC2119, March 1997. 667 [RFC6126bis] 668 Chroboczek, J. and D. Schinazi, "The Babel Routing 669 Protocol", draft-ietf-babel-rfc6126bis-06 (work in 670 progress), October 2018. 672 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 673 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 674 DOI 10.17487/RFC6234, May 2011, 675 . 677 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 678 Cryptographic Hash and Message Authentication Code (MAC)", 679 RFC 7693, DOI 10.17487/RFC7693, November 2015, 680 . 682 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 683 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 684 May 2017. 686 9.2. Informational References 688 [I-D.ietf-babel-dtls] 689 Decimo, A., Schinazi, D., and J. Chroboczek, "Babel 690 Routing Protocol over Datagram Transport Layer Security", 691 draft-ietf-babel-dtls-01 (work in progress), October 2018. 693 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 694 "Randomness Requirements for Security", BCP 106, RFC 4086, 695 DOI 10.17487/RFC4086, June 2005, 696 . 698 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 699 with Existing Cryptographic Protection Methods for Routing 700 Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, 701 . 703 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 704 (HMAC) Cryptographic Authentication", RFC 7298, 705 DOI 10.17487/RFC7298, July 2014, 706 . 708 Appendix A. Incremental deployment and key rotation 710 This protocol supports incremental deployment (transitioning from an 711 insecure network to a secured network with no service interruption) 712 and key rotation (transitioning from a set of keys to a different set 713 of keys). 715 In order to perform incremental deployment, the nodes in the network 716 are first configured in a mode where packets are sent with 717 authentication but not checked on reception. Once all the nodes in 718 the network are configured to send authenticated packets, nodes are 719 reconfigured to reject unauthenticated packets. 721 In order to perform key rotation, the new key is added to all the 722 nodes; once this is done, both the old and the new key are sent in 723 all packets, and packets are accepted if they are properly signed by 724 either of the keys. At that point, the old key is removed. 726 In order to support incremental deployment and key rotation, 727 implementations SHOULD support an interface configuration in which 728 they send authenticated packets but accept all packets, and SHOULD 729 allow changing the set of keys associated with an interface without a 730 restart. 732 Appendix B. Changes from previous versions 734 B.1. Changes since draft-ietf-babel-hmac-00 736 o Changed the title. 738 o Removed the appendix about the packet trailer, this is now in 739 rfc6126bis. 741 o Removed the appendix with implicit indices. 743 o Clarified the definitions of acronyms. 745 o Limited the size of nonces and indices. 747 B.2. Changes since draft-ietf-babel-hmac-01 749 o Made BLAKE2s a recommended HMAC algorithm. 751 o Added requirement to expire per-neighbour crypto state. 753 B.3. Changes since draft-ietf-babel-hmac-02 755 o Clarified that PCs are 32-bit unsigned integers. 757 o Clarified that indices and nonces are of arbitrary size. 759 o Added reference to RFC 4086. 761 Authors' Addresses 763 Clara Do 764 IRIF, University of Paris-Diderot 765 75205 Paris Cedex 13 766 France 768 Email: clarado_perso@yahoo.fr 770 Weronika Kolodziejak 771 IRIF, University of Paris-Diderot 772 75205 Paris Cedex 13 773 France 775 Email: weronika.kolodziejak@gmail.com 777 Juliusz Chroboczek 778 IRIF, University of Paris-Diderot 779 Case 7014 780 75205 Paris Cedex 13 781 France 783 Email: jch@irif.fr