idnits 2.17.1 draft-ietf-bfd-secure-sequence-numbers-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5880, updated by this document, for RFC5378 checks: 2004-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (29 March 2022) is 760 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) == Outdated reference: A later version (-15) exists of draft-ietf-bfd-optimizing-authentication-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jethanandani 3 Internet-Draft Kloud Services 4 Updates: 5880 (if approved) S. Agarwal 5 Intended status: Standards Track Cisco Systems, Inc 6 Expires: 30 September 2022 A. Mishra 7 O3b Networks 8 A. Saxena 9 Ciena Corporation 10 A. Dekok 11 Network RADIUS SARL 12 29 March 2022 14 Secure BFD Sequence Numbers 15 draft-ietf-bfd-secure-sequence-numbers-09 17 Abstract 19 This document describes two new BFD Authentication mechanism, 20 Meticulous Keyed ISAAC, and Meticulous Keyed FNV1A. These mechanisms 21 can be used to authenticate BFD packets, and secure the sequence 22 number exchange, with less CPU time cost than using MD5 or SHA1, with 23 the tradeoff of decreased security. This document updates RFC 5880. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 30 September 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 3. Meticulous Keyed ISAAC . . . . . . . . . . . . . . . . . . . 3 61 4. Meticulous Keyed FNV1A . . . . . . . . . . . . . . . . . . . 5 62 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Seeding and Operation of ISAAC . . . . . . . . . . . . . 7 64 5.2. Secret Key . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.3. Seeding ISAAC . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Meticulous Keyed ISAAC Authentication . . . . . . . . . . . . 9 67 7. Meticulous Keyed FNV1A Authentication . . . . . . . . . . . . 10 68 7.1. Calculation of the FNV-1a Digest . . . . . . . . . . . . 12 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 9.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 14 72 9.2. Re-Use of keys . . . . . . . . . . . . . . . . . . . . . 14 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 11.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 BFD [RFC5880] defines a number of authentication mechanisms, 82 including Simple Password (Section 6.7.2), and various other methods 83 based on MD5 and SHA1 hashes. The benefit of using cryptographic 84 hashes is that they are secure. The downside to cryptographic hashes 85 is that they are expensive and time consuming on resource-constrained 86 hardware. 88 When BFD packets are unauthenticated, it is possible for an attacker 89 to forge, modify, and/or replay packets on a link. These attacks 90 have a number of side effects. They can cause parties to believe 91 that a link is down, or they can cause parties to believe that the 92 link is up when it is, in fact, down. The goal of these methods is 93 to prevent spoofing of the BFD session by someone who could guess the 94 next sequence number. We therefore define simple and fast Auth Type 95 methods which allow parties to detect and prevent both spoofed 96 sequence numbers, and spoofed packets. 98 This document proposes the use of Authentication methods which 99 provides meticulous keying, but which have less impact on resource 100 constrained systems. The algorithms chosen are ISAAC [ISAAC], which 101 is a fast cryptographic random number generator, and FNV-1a FNV1A 102 [FNV1A] which is a fast (but non-cryptographic) hash. ISAAC has been 103 subject to significant cryptanalysis in the past thirty years, and 104 has not yet been broken. Similarly, FNV-1a is fast, and while not 105 cryptographically secure, it is has good hashing properties. 107 2. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 3. Meticulous Keyed ISAAC 115 If the Authentication Present (A) bit is set in the header, and the 116 State (Sta) field equals 3 (Up), and the Authentication Type field 117 contains TB1 (Meticulous Keyed ISAAC), the Authentication Section has 118 the following format: 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Auth Type | Auth Len | Auth Key ID | Reserved | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Sequence Number | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Seed | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Auth-Key | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Auth Type 133 The Authentication Type, which in this case is TB1 (Meticulous 134 Keyed ISAAC). If the State (Sta) field value is not 3 (Up), then 135 Meticulous Keyed ISAAC MUST NOT be used. 137 Auth Len 139 The length of the Authentication Section, in bytes. For 140 Meticulous Keyed ISAAC authentication, the length is 16. 142 Auth Key ID 144 The authentication key ID in use for this packet. This allows 145 multiple keys to be active simultaneously. 147 Reserved 149 This byte MUST be set to zero on transmit, and ignored on receipt. 151 Sequence Number 153 The sequence number for this packet. For Meticulous Keyed ISAAC 154 Authentication, this value is incremented for each successive 155 packet transmitted for a session. This provides protection 156 against replay attacks. 158 Seed 160 A 32-bit (4 octet) seed which is used in conjunction with the 161 shared key in order to configure and initialize the ISAAC pseudo- 162 random-number-generator (PRNG). It is used to identify and 163 distinguish "streams" of random numbers which are generated by 164 ISAAC. 166 Auth-Key 168 This field carries the 32-bit (4 octet) ISAAC output which is 169 associated with the Sequence Number. The ISAAC PRNG MUST be 170 configured and initialized as given in section TBD. 172 Note that the Auth-Key here does not include any summary or hash 173 of the packet. The packet itself is completely unauthenticated. 175 The purpose of this method is to secure the sequence number exchange, 176 and to both detect and prevent spoofing of sequence numbers. In some 177 cases, it is acceptable to not authenticate the entire packet, in 178 which case this method may be used. 180 When the receiving party receives a BFD packet with an expected 181 sequence number, and the correct corresponding ISAAC output, it knows 182 that only the authentic sending party could have sent that message. 183 The sending party is therefore alive/up, and intended to send the 184 message. 186 While the rest of the contents of the BFD packet are unauthenticated 187 and may be modified by an attacker, the same is true of stronger Auth 188 Types, such as MD5 or SHA1. The Auth Type methods are not designed 189 to prevent such attacks. Instead, they are designed to prevent an 190 attacker from spoofing identities, and an attacker from artificially 191 keeping a session "Up". 193 4. Meticulous Keyed FNV1A 195 If the Authentication Present (A) bit is set in the header, and the 196 State (Sta) field equals 3 (Up), and the Authentication Type field 197 contains TB2 (Meticulous Keyed FNV1A), the Authentication Section has 198 the following format: 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Auth Type | Auth Len | Auth Key ID | Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Sequence Number | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Seed | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Digest | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Auth Type 214 The Authentication Type, which in this case is TB2 (Meticulous 215 Keyed FNV1A). If the State (Sta) field value is not 3 (Up), then 216 Meticulous Keyed FNV1A MUST NOT be used. 218 Auth Len 220 The length of the Authentication Section, in bytes. For 221 Meticulous Keyed FNV1A authentication, the length is 16. 223 Auth Key ID 225 The authentication key ID in use for this packet. This allows 226 multiple keys to be active simultaneously. 228 Reserved 230 This byte MUST be set to zero on transmit, and ignored on receipt. 232 Sequence Number 234 The sequence number for this packet. For Meticulous Keyed FNV1A 235 Authentication, this value is incremented for each successive 236 packet transmitted for a session. This provides protection 237 against replay attacks. 239 Seed 241 A 32-bit (4 octet) seed which is used in conjunction with the 242 shared key in order to configure and initialize the ISAAC PRNG. 243 It is also used to identify and distinguish "streams" of random 244 numbers which are generated by ISAAC. 246 Digest 248 This field carries the 32-bit (4 octet) FNV1A digest associated 249 with the Sequence Number. The ISAAC PRNG MUST be configured and 250 initialized as given in section TBD. 252 Note that the ISAAC PRNG output is still used with this 253 authentication type. The FNV1A hash is fast, but it is not 254 secure. In order to reach an acceptable level of security with 255 FNV1A, we use ISAAC to generate secure per-packet "signing keys". 256 These per-packet keys are then used with FNV1A in order to perform 257 a keyed of hash the packet, and therefore create the Digest. 259 5. Operation 261 BFD requires fast and reasonably secure authentication of messages 262 which are exchanged. Methods using MD5 or SHA1 are CPU intensive, 263 and can negatively impact systems with limited CPU power. 265 We use ISAAC here as a way to generate an infinite stream of pseudo- 266 random numbers. With Meticulous Keyed ISAAC, these numbers are used 267 as a signal that the sending party is authentic. That is, only the 268 sending party can generate the numbers. Therefore if the receiving 269 party sees a correct number, then only the sending party could have 270 generated that number. The sender is therefore authentic, even if 271 the packet contents are not necessarily trusted. 273 Note that since the packets are not signed with this authentication 274 type, the Meticulous Keyed ISAAC method MUST NOT be used to signal 275 BFD state changes. For BFD state changes, and a more optimized way 276 to authenticate packets, please refer to BFD Authentication 277 [I-D.ietf-bfd-optimizing-authentication]. Instead, the packets 278 containing Meticulous Keyed ISAAC are only a signal that the sending 279 party is still alive, and that the sending party is authentic. That 280 is, these Auth Type methods must only be used when 281 bfd.SessionState=Up, and the State (Sta) field equals 3 (Up). 283 If slightly more security is desired, the packets can be 284 authenticated via the Meticulous Keyed FNV1A method. This method is 285 similar to the Meticulous Keyed ISAAC authentication type, except 286 that the FNV-1A hash function is used to hash a combination of the 287 packet, and per-packet ISAAC pseudo-random number. If the receiving 288 party is able to validate the hash, then the receiver knows both that 289 the sender is authentic, and that the packet contents have likely not 290 been modified. 292 As this hash function is not very secure, this method can be used 293 only in situations where the Meticulous Keyed ISAAC method can be 294 used. The Meticulous Keyed FNV1A method MUST NOT be used to signal 295 BFD state changes. 297 5.1. Seeding and Operation of ISAAC 299 The ISAAC PRNG state is initialized with the 32-bit Seed, followed by 300 the secret key, and then the rest of the state is filled with zeros. 301 The internal state of ISAAC is 1024 bytes, so the secret key is 302 limited to 1020 bytes in length. 304 The origin of the Seed field is discussed later in this document. 305 For now, we note that each time a new Seed is used, the 306 bfd.XmitAuthSeq value MUST be set to zero. 308 Once the state has been initialized, the standard ISAAC initial 309 mixing function is run. Once his operation has been performed, ISAAC 310 will be able to produce 256 random numbers at near-zero cost. When 311 all 256 numbers are consumed, the ISAAC mixing function is run, which 312 then results in another set of 256 random numbers 314 ISAAC can be thought of here as producing an infinite stream of 315 numbers, based on a secret key, where the numbers are produced in 316 "pages" of 256 32-bit vlaues. This property of ISAAC allows for 317 essentially zero-cost "seeking" within a page. The expensive 318 operation of mixing is performed only once per 256 packets, which 319 means that most BFD packet exchanges can be fast and efficient. 321 The Sequence number is used to "seek" within a the stream of 32-bit 322 numbers produced by ISAAC. The sending party increments the Sequence 323 Number on every packet sent, to indicate to the receiving party where 324 it is in the sequence. 326 The receiving party can then look at the Sequence Number to determine 327 which particular PRNG value is being used in the packet. The 328 Sequence Number thus permits the two parties to synchronise if/when a 329 packet or packets are lost. Incrementing the Sequence Number for 330 every packet also prevents the re-use of any individual pseudo-random 331 number which was derived from ISAAC. 333 The Sequence Number can increment without bounds, though it can wrap 334 once it reaches the limit of the 32-bit counter field. ISAAC has a 335 cycle length of 2^8287, so there is no issue with using more than 336 2^32 values from it. 338 The result of the above operation is an infinite series of numbers 339 which are unguessable, and which can be used to authenticate the 340 sending party. 342 5.2. Secret Key 344 For interoperability, the management interface by which the key is 345 configured MUST accept ASCII strings, and SHOULD also allow for the 346 configuration of any arbitrary binary string in hexadecimal form. 347 Other configuration methods MAY be supported. 349 The secret Key is mixed with the Seed before being used in ISAAC. If 350 instead ISAAC was initialized without a Seed, then an attacker could 351 pre-compute ISAAC states for many keys, and perform an off-line 352 dictionary attack. The addition of the Seed makes these attacks 353 infeasable. 355 As a result, it is safe to use the same secret Key for the Auth Types 356 defined here, and also for other Auth Types. 358 5.3. Seeding ISAAC 360 The value of the Seed field SHOULD be derived from a secure source. 361 Exactly how this can be done is outside of the scope of this 362 document. 364 The Seed value SHOULD remain the same for the duration of a BFD 365 session. The Seed value MAY change when the BFD state changes. 367 If the sending party changes its Seed value, bfd.XmitAuthSeq value 368 MUST be set to zero, otherwise the receiving party would be unable to 369 synchronize its sequence of numbers produced by the ISAAC generator. 370 There is no way to signal or negotiate Seed changes. The receiving 371 party MUST remember the current Seed value, and then detect if the 372 Seed changes. Note that the Seed value MUST NOT change unless 373 sending party has signalled a BFD state change with a a packet that 374 is authenticated using a more secure Auth Type method. 376 6. Meticulous Keyed ISAAC Authentication 378 In this method of authentication, one or more secret keys (with 379 corresponding key IDs) are configured in each system. One of the 380 keys is used to seed the ISAAC PRNG. The output of ISAAC (I) is used 381 to signal that the sender is authentic. To help avoid replay 382 attacks, a sequence number is also carried in each packet. For 383 Meticulous Keyed ISAAC, the sequence number is incremented on every 384 packet. 386 The receiving system accepts the packet if the key ID matches one of 387 the configured Keys, the Auth-Key derived from the selected Key, 388 Seed, and Sequence Number matches the Auth-Key carried in the packet, 389 and the sequence number is strictly greater than the last sequence 390 number received (modulo wrap at 2^32) 392 Transmission Using Meticulous Keyed ISAAC Authentication 394 The Auth Type field MUST be set to TBD1 (Meticulous Keyed ISAAC). 395 The Auth Len field MUST be set to 16. The Auth Key ID field MUST 396 be set to the ID of the current authentication key. The Sequence 397 Number field MUST be set to bfd.XmitAuthSeq. 399 The Seed field MUST be set to the value of the current seed used 400 for this sequence. 402 The Auth-Key field MUST be set to the output of ISAAC, which 403 depends on the secret Key, the current Seed, and the Sequence 404 Number. 406 For Meticulous Keyed ISAAC, bfd.XmitAuthSeq MUST be incremented on 407 each packet, in a circular fashion (when treated as an unsigned 408 32-bit value). The bfd.XmitAuthSeq MUST NOT be incremented by 409 more than one for a packet. 411 Receipt using Meticulous Keyed ISAAC Authentication 412 If the received BFD Control packet does not contain an 413 Authentication Section, or the Auth Type is not correct (TBD2 for 414 Meticulous Keyed ISAAC), then the received packet MUST be 415 discarded. 417 If the Auth Key ID field does not match the ID of a configured 418 authentication key, the received packet MUST be discarded. 420 If the Auth Len field is not equal to 16, the packet MUST be 421 discarded. 423 If the Seed field does not match the current Seed value, the 424 packet MUST be discarded. 426 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 427 Meticulous Keyed FNV1A, if the sequence number lies outside of the 428 range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) 429 inclusive (when treated as an unsigned 32-bit circular number 430 space) the received packet MUST be discarded. 432 Calculate the current expected output of ISAAC, which depends on 433 the secret Key, the current Seed, and the Sequence Number. If the 434 value does not matches the Auth-Key field, then the packet MUST be 435 discarded. 437 Note that in some cases, calculating the expected output of ISAAC 438 will result in the creation of a new "page" of 256 numbers. This 439 process will irreversible, and will destroy the current "page". 440 As a result, if the generation of a new output will create a new 441 "page", the receiving party MUST save a copy of the entire ISAAC 442 state before proceeding with this calculation. If the outputs 443 match, then the saved copy can be discarded, and the new ISAAC 444 state is used. If the outputs do not match, then the saved copy 445 MUST be restored, and the modified copy discarded. 447 7. Meticulous Keyed FNV1A Authentication 449 Where slightly more security is needed, the sender can use Meticulous 450 Keyed FNV1A. In this method, each packet is signed with a non- 451 cryptographic hash, FNV-1a [FNV1A]. This hash is reasonably fast, it 452 has good distribution, and collisions are rare. However, it is 453 linear, and potentially reversible. In addition, its output is only 454 32 bits, and it is not cryptographically strong. 456 In this methods of authentication, one or more secret keys (with 457 corresponding key IDs) are configured in each system. One of the 458 keys is included in an FNV1A digest calculated over the outgoing BFD 459 Control packet, but the Key itself is not carried in the packet. To 460 help avoid replay attacks, a sequence number is also carried in each 461 packet. For Meticulous Keyed FNV1A, the sequence number is 462 incremented on every packet. 464 The receiving system accepts the packet if the key ID matches one of 465 the configured Keys, an FNV-1a digest including the selected key 466 matches the digest carried in the packet, and the sequence number is 467 strictly greater than the last sequence number received (modulo wrap 468 at 2^32) 470 Transmission Using Meticulous Keyed FNV1A Authentication 472 The Auth Type field MUST be set to TBD2 (Meticulous Keyed FNV1A). 473 The Auth Len field MUST be set to 16. The Auth Key ID field MUST 474 be set to the ID of the current authentication key. The Sequence 475 Number field MUST be set to bfd.XmitAuthSeq. 477 The Digest field MUST be set to the value of the FNV-1a digest, as 478 described below. 480 For Meticulous Keyed FNV1A, bfd.XmitAuthSeq MUST be incremented on 481 each packet, in a circular fashion (when treated as an unsigned 482 32-bit value). The bfd.XmitAuthSeq MUST NOT be incremented by 483 more than one for a packet. 485 Receipt Using Meticulous Keyed FNV1A Authentication 487 If the received BFD Control packet does not contain an 488 Authentication Section, or the Auth Type is not correct (TBD2 for 489 Meticulous Keyed FNV1A), then the received packet MUST be 490 discarded. 492 If the Auth Key ID field does not match the ID of a configured 493 authentication key, the received packet MUST be discarded. 495 If the Auth Len field is not equal to 16, the packet MUST be 496 discarded. 498 If the Seed field does not match the current Seed value, the 499 packet MUST be discarded. 501 If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For 502 Meticulous Keyed FNV1A, if the sequence number lies outside of the 503 range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) 504 inclusive (when treated as an unsigned 32-bit circular number 505 space) the received packet MUST be discarded. 507 Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to 508 1, and bfd.RcvAuthSeq MUST be set to the value of the received 509 Sequence Number field. 511 Replace the contents of the Digest field with zeros, and calculate 512 the FNV-1a digest as described below. If the calculated FNV-1a 513 digest is equal to the received value of the Digest field, the 514 received packet MUST be accepted. Otherwise (the digest does not 515 match the Digest field), the received packet MUST be discarded. 517 7.1. Calculation of the FNV-1a Digest 519 Unlike other authentication mechanisms, the user-supplied key is not 520 placed into the Auth Key / Digest field, and the packet hashed. As 521 FNV-1a is not a cryptographic hash, such a process would simplify the 522 process for an attacker to "crack" the key. 524 Instead, for a particular packet "P", and ISAAC pseudo-random number 525 "I", the FNV1A digest "D" is calculated as shown below, where "+" 526 indicates concatenation. 528 D = FNV1A(I + P + I) 530 Where "+" denotes concatentation. We also note that the Digest field 531 of the packet MUST be initialized to all zeroes before this 532 calculation is performed 534 The calculated value "D" is then inserted into the packet in the 535 Digest field, and the packet is sent as normal. The receiving party 536 reverses this operation in order to validate the packet. 538 8. IANA Considerations 540 This document asks that IANA allocate a new entry in the "BFD 541 Authentication Types" registry. 543 Address - TBD1 545 BFD Authentication Type Name - Meticulous Keyed ISAAC 547 Reference - this document 549 Address - TBD2 551 BFD Authentication Type Name - Meticulous Keyed FNV1A 553 Reference - this document 554 Note to RFC Editor: this section may be removed on publication as an 555 RFC. 557 9. Security Considerations 559 The security of this proposal depends strongly on the length of the 560 secret, and the entropy of the key. It is RECOMMENDED that the key 561 be 16 octets in length or more. 563 The security of this proposal depends strongly on ISAAC. This 564 generator has been analyzed and has not been broken. Research shows 565 few other CSRNGs which are as simple and as fast as ISAAC. For 566 example, many other generators are based on AES, which is infeasibe 567 for resource constrained systems. 569 The security of this proposal depends on the strength of the FNV-1a 570 hash algorithm. Folding the output of ISAAC into the hash limits the 571 ability of an attacker to reverse the hash, or to perform off-line 572 dictionary attacks. Even if one particular 32-bit per-packet key is 573 found via brute force, that information will be useless, as the next 574 packet will use a different key. And since ISAAC is secure, 575 knowledge of one particular key will give an attacker no ability to 576 predict the next key. 578 In a keyed algorithm, the key is shared between the two systems. 579 Distribution of this key to all the systems at the same time can be 580 quite a cumbersome task. BFD sessions running a fast rate will 581 require these keys to be refreshed often, which poses a further 582 challenge. Therefore, it is difficult to change the keys during the 583 operation of a BFD session without affecting the stability of the BFD 584 session. Therefore, it is recommended to administratively disable 585 the BFD session before changing the keys. 587 This method allows the BFD end-points to detect a malicious packet, 588 as the calculated hash value will not match the value found in the 589 packet. The behavior of the session, when such a packet is detected, 590 is based on the implementation. A flood of such malicious packets 591 may cause a BFD session to be operationally down. 593 As noted earlier with Meticulous Keyed FNV1A, each packet is 594 associated with a unique, per-packet key. This process means that 595 even if an observer sees the Auth-Key, or the FNV-1a hash for one 596 packet, the only information gained will be a key which is never be 597 re-used, and will therefore be useless to an attacker. Further, even 598 if the attacker can "crack" a sequence of packets to obtain a stream 599 of keys, the cryptographic nature of ISAAC makes it impossible for 600 the attacker to derive the input key which is used to "seed" the 601 ISAAC state. 603 The particular method of hashing was chosen because of the non- 604 cryptographic amd reversible nature of the FNV-1a hash. If the 605 digest had been calculated any other way, then an attacker would have 606 significantly less work to do in order to "crack" the hash. In short 607 the per-packet key protects the hash, and and hash protects the per- 608 packet key. 610 We believe that this construction is reasonably secure, given the 611 constraints. If cryptographic security is desired, then implementors 612 can use MD5 or SHA1 authentication mechanisms 614 9.1. Spoofing 616 When Meticulous Keyed ISAAC is used, it is possible for an attacker 617 who can see the packets to observe a particular Auth Key value, and 618 then copy it to a different packet as a "man-in-the-middle" attack. 619 However, the usefulness of such an attack is limited by the 620 requirements that these packets must not signal state changes in the 621 BFD session, and that the key changes on every packet. 623 Performing such an attack would require an attacker to have the 624 following information and capabilities: 626 This is man-in-the-middle active attack. 628 The attacker has the contents of a stable packet 630 The attacker has managed to deduce the ISAAC key and knows which 631 per-packet key is being used. 633 The attack is therefore limited to keeping the BFD session up when it 634 would otherwise drop. 636 However, the usual actual attack which we are protecting BFD from is 637 availability. That is, the attacker is trying to shut down then 638 connection when the attacked parties are trying to keep it up. As a 639 result, the attacks here seem to be irrelevant in practice. 641 9.2. Re-Use of keys 643 The strength of the Auth-Type methods is significantly different 644 between the strong one like SHA-1 and ISAAC. While ISAAC has had 645 cryptanalysis, and has not been shown to be broken, that analysis is 646 limited. The question then is whether or not it is safe to use the 647 same key for both Auth Type methods (SHA1 and ISAAC), or should we 648 require different keys for each method? 649 If we recommend different keys, then it is possible for the two keys 650 to be configured differently on each side of a BFD lin. For example. 651 the strong key can be properly provisioned, which allows to the BFD 652 state machine to advance to Up, Then, when we switch to the weaker 653 Auth Type which uses a different key, that key may not match, and the 654 session will immediatly drop. 656 We believe that the use of the same key is acceptable, as the Auth 657 Types which use ISAAC also depend on a Seed. The use of the Seed 658 increases the difficulty of breaking the key, and makes off-line 659 dictionary attacks infeasible. 661 10. Acknowledgements 663 The authors would like to thank Jeff Haas and Reshad Rahman for their 664 reviews of and suggestions for the document. 666 11. References 668 11.1. Normative References 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, 672 DOI 10.17487/RFC2119, March 1997, 673 . 675 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 676 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 677 . 679 11.2. Informative References 681 [FNV1A] Noll, L. C., "FNV-1a", 682 http://www.isthe.com/chongo/tech/comp/fnv/index.html#FNV- 683 1a, 2013. 685 [I-D.ietf-bfd-optimizing-authentication] 686 Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, 687 "Optimizing BFD Authentication", Work in Progress, 688 Internet-Draft, draft-ietf-bfd-optimizing-authentication- 689 13, 1 August 2021, . 692 [ISAAC] Jenkins, R. J., "ISAAC", 693 http://www.burtleburtle.net/bob/rand/isaac.html, 1996. 695 Authors' Addresses 696 Mahesh Jethanandani 697 Kloud Services 698 Email: mjethanandani@gmail.com 700 Sonal Agarwal 701 Cisco Systems, Inc 702 170 W. Tasman Drive 703 San Jose, CA 95070 704 United States of America 705 Email: agarwaso@cisco.com 706 URI: www.cisco.com 708 Ashesh Mishra 709 O3b Networks 710 Email: mishra.ashesh@gmail.com 712 Ankur Saxena 713 Ciena Corporation 714 3939 North First Street 715 San Jose, CA 95134 716 United States of America 717 Email: ankurpsaxena@gmail.com 719 Alan DeKok 720 Network RADIUS SARL 721 100 Centrepointe Drive #200 722 Ottawa ON K2G 6B1 723 Canada 724 Email: aland@freeradius.org