idnits 2.17.1 draft-do-babel-hmac-00.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 (July 2, 2018) is 2117 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-05 ** Downref: Normative reference to an Informational RFC: RFC 6234 -- Obsolete informational reference (is this intentional?): RFC 7298 (Obsoleted by RFC 8967) Summary: 2 errors (**), 0 flaws (~~), 2 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 July 2, 2018 7 Expires: January 3, 2019 9 Babel Cryptographic Authentification 10 draft-do-babel-hmac-00 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 January 3, 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 . . . . . . . . . . . . . . . . . . . . 7 64 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 11 68 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 11 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 9.2. Informational References . . . . . . . . . . . . . . . . 13 75 Appendix A. Use of the packet trailer . . . . . . . . . . . . . 13 76 Appendix B. Incremental deployment and key rotation . . . . . . 13 77 Appendix C. Implicit indices . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 By default, the Babel routing protocol trusts the information 83 contained in every UDP packet it receives on the Babel port. An 84 attacker can redirect traffic to itself or to a different node in the 85 network, causing a variety of potential issues. In particular, an 86 attacker might: 88 o spoof a Babel packet, and redirect traffic by announcing a smaller 89 metric, a larger seqno, or a longer prefix; 91 o spoof a malformed packet, which could cause an insufficiently 92 robust implementation to crash or interfere with the rest of the 93 network; 95 o replay a previously captured Babel packet, which could cause 96 traffic to be redirected or otherwise interfere with the network. 98 Protecting a Babel network is challenging due to the fact that the 99 Babel protocol uses both unicast and multicast communication. One 100 possible approach, used notably by the Babel over DTLS protocol, is 101 to require a secured version of Babel to use unicast communication 102 for all semantically significant communication, and then use a 103 standard unicast security protocol to protect the Babel traffic. In 104 this document, we take the opposite approach: we define a 105 cryptographic extension to the Babel protocol that is able to protect 106 both unicast and multicast traffic, and thus requires very few 107 changes to the core protocol. 109 1.1. Applicability 111 The protocol defined in this document assumes that all interfaces on 112 a given link are equally trusted and share a small set of symmetric 113 keys (usually just one, two during key rotation). The protocol is 114 inapplicable in situations where asymmetric keying is required, where 115 the trust relationship is partial, or where large numbers of trusted 116 keys are provisioned on a single link at the same time. 118 This protocol supports incremental deployment (where an insecure 119 Babel network is made secure with no service interruption), and it 120 supports graceful key rotation (where the set of keys is changed with 121 no service interruption). 123 This protocol does not require synchronised clocks, it does not 124 require persistently monotonic clocks, and it does not require any 125 form of persistent storage. 127 1.2. Assumptions and security properties 129 The correctness of the protocol relies on the following assumptions: 131 o that the HMAC being used is invulnerable to spoofing, i.e. that an 132 attacker is unable to generate a packet with a correct HMAC; 134 o that a node never generates the same index or nonce twice over the 135 lifetime of a key. 137 The first assumption is a property of the HMAC being used, and is 138 therefore out-of-scope for this document. The second assumption can 139 be met either by using a robust random number generator and 140 sufficiently large indices and nonces, by using a reliable hardware 141 clock, or by rekeying whenever a collision becomes likely. 143 If the assumptions above are met, the protocol described in this 144 document has the following properties: 146 o it is invulnerable to spoofing: any packet accepted as authentic 147 is the exact copy of a packet originally sent by an authorised 148 node; 150 o locally to a single node, it is invulnerable to replay: if a node 151 has previously accepted a given packet, then it will never again 152 accept a copy of this packet or an earlier packet from the same 153 sender; 155 o among different nodes, it is only vulnerable to immediate replay: 156 if a node A has accepted a packet from C as valid, then a node B 157 will only accept a copy of that packet as authentic if B has 158 accepted an older packet from C and B has received no later packet 159 from C. 161 While this protocol makes serious efforts to mitigate the effects of 162 a denial of service attack, it does not fully protect against such 163 attacks. 165 1.3. Specification of Requirements 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 2. Conceptual overview of the protocol 175 When a node B sends out a Babel packet through an interface that is 176 configured for cryptographic protection, it computes one or more 177 HMACs which it appends to the packet. When a node A receives a 178 packet over an interface that requires cryptographic protection, it 179 independently computes a set of HMACs and compares them to the HMACs 180 appended to the packet; if there is no match, the packet is 181 discarded. 183 In order to protect against replay B maintains a per-interface 32-bit 184 integer known as the "packet counter" (PC). Whenever B sends a 185 packet through the interface, it embeds the current value of the PC 186 within the region of the packet that is protected by the HMACs and 187 increases the PC by at least one. When A receives the packet, it 188 compares the value of the PC with the one contained in the previous 189 packet received from B, and unless it is strictly greater, the packet 190 is discarded. 192 By itself, the PC mechanism is not sufficient to protect against 193 replay. Consider a peer A that has no information about a pair B 194 (e.g., because it has recently rebooted). Suppose that A receives a 195 packet ostensibly from B carrying a given PC; since A has no 196 information about B, it has no way to determine whether the packet is 197 freshly generated or a replay of a previously sent packet. 199 In this situation, A discards the packet and challenges B to prove 200 that it knows the HMAC key. It sends a "challenge request", a TLV 201 containing a unique nonce, a value that has never been used before 202 and will never be used again. B replies to the challenge request 203 with a "challenge reply", a TLV containing a copy of the nonce chosen 204 by A, in a packet protected by HMAC and containing the new value of 205 B's PC. Since the nonce has never been used before, B's reply proves 206 B's knowledge of the HMAC key and the freshness of the PC. 208 By itself, this mechanism is safe against replay if B never resets 209 its PC. In practice, however, this is difficult to ensure, as 210 persistent storage is prone to failure, and hardware clocks, even 211 when available, are occasionally reset. Suppose that B resets its PC 212 to an earlier value, and sends a packet with a previously used PC n. 213 A challenges B, B successfully responds to the challenge, and A 214 accepts the PC equal to n + 1. At this point, an attacker C may send 215 a replayed packet with PC equal to n + 2, which will be accepted by 216 A. 218 Another mechanism is needed to protect against this attack. In this 219 protocol, every PC is tagged with an "index", an arbitrary string of 220 octets. Whenever B resets its PC, or whenever B doesn't know whether 221 its PC has been reset, it picks an index that it has never used 222 before (either by drawing it randomly or by using a reliable hardware 223 clock) and starts sending PCs with that index. Whenever A detects 224 that B has changed its index, it challenges B again. 226 With this additional mechanism, this protocol is provably 227 invulnerable to replay attacks (see Section 1.2 above). 229 3. Data Structures 231 3.1. The Interface Table 233 Every Babel node maintains an interface table, as described in 234 [RFC6126bis] Section 3.2.3. This protocol extends the entries in 235 this table with a set of HMAC keys, and a pair (Index, PC), where 236 Index is an arbitrary string of bytes and PC is a 32-bit integer. 237 The Index is initialised to a value that has never been used before 238 (e.g., by choosing a random string of sufficient length). 240 3.2. The Neighbour table 242 Every Babel node maintains a neighbour table, as described in 243 [RFC6126bis] Section 3.2.4. This protocol extends the entries in 244 this table with a pair (Index, PC), as well as a nonce (an arbitrary 245 string of bytes) and a challenge expiry timer. The Index and PC are 246 initially undefined, and are managed as described in Section 4.3. 247 The Nonce and expiry timer are initially undefined and used as 248 described in Section 4.3.1.1. 250 4. Protocol Operation 252 4.1. HMAC computation 254 A Babel node computes an HMAC as follows. 256 First, the node builds a pseudo-header that will participate in HMAC 257 computation but will not be sent. The pseudo-header has the 258 following format: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 + + 265 | | 266 + Src address + 267 | | 268 + + 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Src port | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 273 | | 274 + + 275 | Dest address | 276 + + 277 | | 278 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | | Dest port | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Fields : 284 Src address The source IP address of the packet. 286 Src port The source UDP port number of the packet. 288 Dest address The destination IP address of the packet. 290 Src port The destination UDP port number of the packet. 292 The node takes the concatenation of the pseudo-header and the packet 293 including the packet header but excluding the packet trailer (from 294 octet 0 inclusive up to Body Length + 4 exclusive) and computes an 295 HMAC as defined in Section 2 of [RFC2104] with one of the implemented 296 hash algorithms. Every implementation MUST implement HMAC-SHA256 297 [RFC6234], and MAY implement other HMAC algorithms. 299 4.2. Packet Transmission 301 A Babel node may delay actually sending TLVs by a small amount, in 302 order to aggregate multiple TLVs in a single packet up to the 303 interface MTU (Section 4 of [RFC6126bis]). For an interface on which 304 HMAC protection is configured, the TLV aggregation logic MUST take 305 into account the overhead due to PC TLVs (one in each packet) and 306 HMAC TLVs (one per configured key). 308 Before sending a packet, the following actions are performed: 310 o a PC TLV containing the Packet Counter and Index associated with 311 the outgoing interface is appended to the packet body; the packet 312 counter is incremented by a strictly positive amount (typically 313 just 1); if the packet counter overflows, a new index is 314 generated; 316 o for each key configured on the interface, an HMAC is computed as 317 specified in Section 4.1 above, and an HMAC TLV is appended to the 318 packet trailer. 320 4.3. Packet Reception 322 When a packet is received on an interface that is configured for HMAC 323 protection, the following steps are performed before the packet is 324 passed to normal processing: 326 o First, the receiver checks whether the trailer of the received 327 packet carries at least one HMAC TLV; if not, the packet is 328 immediately dropped and processing stops. Then, for each key 329 configured on the receiving interface, the implementation computes 330 the HMAC of the packet. It then compares every generated HMAC 331 against every HMAC included in the packet; if there is at least 332 one match, the packet passes the HMAC test; if there is none, the 333 packet is silently dropped and processing stops at this point. In 334 order to avoid memory exhaustion attacks, an entry in the 335 Neighbour Table MUST NOT be created before the HMAC test has 336 passed successfully. The HMAC of the packet MUST NOT be computed 337 for each HMAC TLV contained in the packet, but only once for each 338 configured key. 340 o The packet body is then parsed a first time. During this 341 "preparse" phase, the packet body is traversed and all TLVs are 342 ignored except PC TLVs, Challenge Requests and Challenge Replies. 343 When a PC TLV is encountered, the enclosed PC and Index are saved 344 for later processing; if multiple PCs are found, only the first 345 one is processed, the remaining ones are silently ignored. If a 346 Challenge Request is encountered, a Challenge Reply is scheduled, 347 as described in Section 4.3.1.2, and if a Challenge Reply is 348 encountered, it is tested for validity as described in 349 Section 4.3.1.3 and a note is made of the result of the test. 351 o The preparse phase above has yielded two pieces of data: the PC 352 and Index from the first PC TLV, and a bit indicating whether the 353 packet contains a successful Challenge Reply. If the packet does 354 not contain a PC TLV, the packet is dropped and processing stops 355 at this point. If the packet contains a successful Challenge 356 Reply, then the PC and Index contained in the PC TLV are stored in 357 the Neighbour Table entry corresponding to the sender (which may 358 need to be created at this stage). 360 o If there is no entry in the Neighbour Table corresponding to the 361 sender, or if such an entry exists but contains no Index, or if 362 the Index it contains is different from the Index contained in the 363 PC TLV, then a challenge is sent as described in Section 4.3.1.1, 364 processing stops at this stage, and the packet is dropped. 366 o At this stage, the Index contained in the PC TLV is equal to the 367 Index in the Neighbour Table entry corresponding to the sender. 368 The receiver compares the received PC with the PC contained in the 369 Neighbour Table; if the received PC smaller or equal than the PC 370 contained in the Neighbour Table, the packet is silently dropped 371 and processing stops (no challenge is sent in this case, since the 372 mismatch might be caused by harmless packet reordering on the 373 link). Otherwise, the PC contained in the Neighbour Table entry 374 is set to the received PC, and the packet is accepted. 376 After the packet has been accepted, it is processed as normal, except 377 that any PC, Challenge Request and Challenge Reply TLVs that it 378 contains are silently ignored. 380 4.3.1. Challenge Requests and Replies 382 During the preparse stage, the receiver might encounter a mismatched 383 Index, to which it will react by scheduling a Challenge Request. It 384 might encounter a Challenge Request TLV, to which it will reply with 385 a Challenge Reply TLV. Finally, it might encounter a Challenge Reply 386 TLV, which it will attempt to match with a previously sent Challenge 387 Request TLV in order to update the Neighbour Table entry 388 corresponding to the sender of the packet. 390 4.3.1.1. Sending challenges 392 When it encounters a mismatched Index during the preparse phase, a 393 node picks a nonce that it has never used before, for example by 394 drawing a sufficiently large random string of bytes or by consulting 395 a strictly monotonic hardware clock. It stores the nonce in the 396 entry of the Neighbour Table of the neighbour (the entry might need 397 to be created at this stage), initialises the neighbour's challenge 398 expiry timer to 30 seconds, and sends a Challenge Request TLV to the 399 unicast address corresponding to the neighbour. 401 A node MAY aggregate a Challenge Request with other TLVs; in other 402 words, if it has already buffered TLVs to be sent to the unicast 403 address of the sender of the neighbour, it MAY send the buffered TLVs 404 in the same packet as the Challenge Request. However, it MUST 405 arrange for the Challenge Request to be sent in a timely manner, as 406 any packets received from that neighbour will be silently ignored 407 until the challenge completes. 409 Since a challenge may be prompted by a replayed packet, a node MUST 410 impose a rate limitation to the challenges it sends; a limit of one 411 challenge every 300ms for each neighbour is suggested. 413 4.3.1.2. Replying to challenges 415 When it encounters a Challenge Request during the preparse phase, a 416 node constructs a Challenge Reply TLV by copying the Nonce from the 417 Challenge Request into the Challenge Reply. It sends the Challenge 418 Reply to the unicast address of the sender of the Challenge Reply. 420 A node MAY aggregate a Challenge Reply 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 Challenge Request, it MAY send the 423 buffered TLVs in the same packet as the Challenge Reply. However, it 424 MUST arrange for the Challenge Reply to be sent in a timely manner 425 (within a few seconds), and SHOULD NOT send any other packets over 426 the same interface before sending the Challenge Reply, as those would 427 be dropped by the challenger. 429 A challenge sent to a multicast address MUST be silently ignored. 431 4.3.1.3. Receiving challenge replies 433 When it encounters a Challenge Reply during the preparse phase, a 434 node consults the Neighbour Table entry corresponding to the 435 neighbour that sent the Challenge Reply. If no challenge is in 436 progress, i.e., if there is no Nonce stored in the Neighbour 437 Table entry or the Challenge timer has expired, the Challenge Reply 438 is silently ignored and the challenge has failed. 440 Otherwise, the node compares the Nonce contained in the Challenge 441 Reply with the Nonce contained in the Neighbour Table entry. If the 442 two are equal (they have the same length and content), then the 443 challenge has succeeded; otherwise, the challenge has failed. 445 5. Packet Format 447 5.1. HMAC TLV 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Length | HMAC... 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 455 Fields : 457 Type Set to TBD to indicate an HMAC TLV 459 Length The length of the body, exclusive of the Type and Length 460 fields. The length of the body depends on the hash 461 function used. 463 HMAC The body contains the HMAC of the whole packet plus the 464 pseudo header. 466 This TLV is allowed in the packet trailer (see Appendix A), and MUST 467 BE ignored if it is found in the packet body. 469 5.2. PC TLV 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Type | Length | PC 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Index... 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 478 Fields : 480 Type Set to TBD to indicate a PC TLV 482 Length The length of the body, exclusive of the Type and Length 483 fields. 485 PC The Packet Counter (PC), which is increased with every 486 packet sent over this interface. A new index MUST be 487 generated whenever the PC overflows. 489 Index The sender's Index. 491 5.3. Challenge Request TLV 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length | Nonce... 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 499 Fields : 501 Type Set to TBD to indicate a Challenge Request TLV 503 Length The length of the body, exclusive of the Type and Length 504 fields. 506 Nonce The nonce uniquely identifying the challenge. 508 5.4. Challenge Reply TLV 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Type | Length | Nonce... 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 516 Fields : 518 Type Set to TBD to indicate a Challenge Reply TLV 520 Length The length of the body, exclusive of the Type and Length 521 fields. The length of the body is set to the same size as 522 the challenge request TLV length received. 524 Nonce A copy of the nonce contained in the corresponding 525 challenge request. 527 6. Security Considerations 529 7. IANA Considerations 531 IANA is instructed to allocate the following values in the Babel TLV 532 Numbers registry: 534 +------+-------------------+---------------+ 535 | Type | Name | Reference | 536 +------+-------------------+---------------+ 537 | TBD | HMAC | this document | 538 | | | | 539 | TBD | PC | this document | 540 | | | | 541 | TBD | Challenge Request | this document | 542 | | | | 543 | TBD | Challenge Reply | this document | 544 +------+-------------------+---------------+ 546 8. Acknowledgments 548 The protocol described in this document is based on the original HMAC 549 protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- 550 header was suggested by David Schinazi. The use of an index to avoid 551 replay was suggested by Markus Stenberg. The authors are also 552 indebted to Florian Horn and Toke Hoyland-Jorgensen. 554 9. References 556 9.1. Normative References 558 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 559 Hashing for Message Authentication", RFC 2104, 560 DOI 10.17487/RFC2104, February 1997, 561 . 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, 565 DOI 10.17487/RFC2119, March 1997. 567 [RFC6126bis] 568 Chroboczek, J. and D. Schinazi, "The Babel Routing 569 Protocol", draft-ietf-babel-rfc6126bis-05 (work in 570 progress), May 2018. 572 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 573 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 574 DOI 10.17487/RFC6234, May 2011, 575 . 577 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 578 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 579 May 2017. 581 9.2. Informational References 583 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 584 (HMAC) Cryptographic Authentication", RFC 7298, 585 DOI 10.17487/RFC7298, July 2014, 586 . 588 Appendix A. Use of the packet trailer 590 The protocol described in this document uses the packet trailer for 591 storing HMAC TLVs. RFC 6126bis [RFC6126bis] leaves the format of the 592 packet trailer undefined. If the final version of this specification 593 uses the packet trailer, RFC 6126bis will need to be extended with 594 information about the format of the packet trailer. 596 This document assumes that the packet trailer has the same format as 597 the packet body, i.e., that it consists of a sequence of TLVs. The 598 receiver MUST silently ignore any TLV found in the packet trailer 599 unless its definition states that the TLV is allowed in the packet 600 trailer. 602 Appendix B. Incremental deployment and key rotation 604 This protocol supports incremental deployment (transitioning from an 605 insecure network to a secured network with no service interruption) 606 and key rotation (transitioning from a set of keys to a different set 607 of keys). 609 In order to perform incremental deployment, the nodes in the network 610 are first configured in a mode where packets are sent with 611 authentication but not checked on reception. Once all the nodes in 612 the network are configured to send authenticated packets, nodes are 613 reconfigured to reject unauthenticated packets. 615 In order to perform key rotation, the new key is added to all the 616 nodes; once this is done, both the old and the new key are sent in 617 all packets, and packets are accepted if they are properly signed by 618 either of the keys. At that point, the old key is removed. 620 In order to support incremental deployment and key rotation, 621 implementations SHOULD support an interface configuration in which 622 they send authenticated packets but accept all packets, and SHOULD 623 allow changing the set of keys associated with an interface without a 624 restart. 626 Appendix C. Implicit indices 628 [This appendix describes the "implicit indices" variant of the 629 protocol, which is different and incompatible to the "explicit 630 indices" variant described in the body of this document. This 631 section should either be integrated into the body of the document or 632 removed before publication of this document as an RFC, depending on 633 which protocol variant is finally chosen.] 635 The protocol described in the body of this document explicitly sends 636 indices as in each packet as part of the PC TLV. Observe that, 637 except when a challenge is required, the index sent on the wire is 638 identical to the index stored in the Neighbour Table, and therefore 639 doesn't need to be sent explicitly except during challenges: it is 640 enough for it to participate in HMAC computation in order to protect 641 against replay. The "implicit indices" variant of the protocol, due 642 to Markus Stenberg and described in this appendix, uses this 643 observation to avoid sending indices explicitly and thus shaves off 2 644 to 16 octets from almost every packet. 646 The changes to the protocol are as follows. The pseudo-header 647 includes the Index, and therefore has the following format: 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | | 653 + + 654 | | 655 + Src address + 656 | | 657 + + 658 | | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Src port | | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 662 | | 663 + + 664 | Dest address | 665 + + 666 | | 667 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | | Dest port | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Index... 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 673 The PC TLV no longer contains an Index, and therefore has the 674 following format: 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Type | Length | PC 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 This TLV is now self-terminating, and therefore allows sub-TLVs. 686 Packets containing the Challenge Reply and Challenge Request TLVs 687 must contain an explicit index. Two encodings are possible: one uses 688 Challenge Replies and Requests with an extra field for the sender's 689 index, which complicates the encoding somewhat but makes these two 690 TLVs self-terminating, the other one uses a new TLV that is used for 691 carrying an Index, which uses up a new TLV number but makes it 692 possible to reuse these two TLV with other protocols that require a 693 nonce-based challenge. 695 Packet transmission is modified as follows. If a packet contains a 696 Challenge or a Challenge Reply, then the node inserts its index into 697 the packet body. In any case, it uses its current index to generate 698 the pseudo-header that will be used to compute the HMAC. (This 699 implies that a packet must be parsed in its entirety before HMAC 700 validation, which requires a robust parser.) 702 Packet reception is modified as follows. Before checking the HMAC of 703 a packet, the receiver checks whether the packet contains an explicit 704 index. If this is the case, it uses the index contained in the 705 packet in order to generate the pseudo header; if this is not the 706 case, it uses the index contained in its neighbours table. If there 707 is no index available for that neighbour (either because the table 708 doesn't contain in an entry for this neighbour, or the entry doesn't 709 contain an index), HMAC validation fails. 711 The index and PC contained in the neighbours table are only updated 712 after HMAC validation has succeeded. 714 Since it is now impossible to differentiate between a failed HMAC and 715 an index change, a node must send a challenge whenever HMAC 716 validation fails. This implies that spoofed packets cause a spurious 717 challenge, but that doesn't change the security properties of the 718 protocol much, given that in any case replayed packets can be used to 719 cause a spurious challenge. 721 Authors' Addresses 723 Clara Do 724 IRIF, University of Paris-Diderot 725 75205 Paris Cedex 13 726 France 728 Email: clarado_perso@yahoo.fr 730 Weronika Kolodziejak 731 IRIF, University of Paris-Diderot 732 75205 Paris Cedex 13 733 France 735 Email: weronika.kolodziejak@gmail.com 736 Juliusz Chroboczek 737 IRIF, University of Paris-Diderot 738 Case 7014 739 75205 Paris Cedex 13 740 France 742 Email: jch@irif.fr