| < draft-ietf-bfd-secure-sequence-numbers-08.txt | draft-ietf-bfd-secure-sequence-numbers-09.txt > | |||
|---|---|---|---|---|
| Network Working Group M. Jethanandani | Network Working Group M. Jethanandani | |||
| Internet-Draft Kloud Services | Internet-Draft Kloud Services | |||
| Updates: 5880 (if approved) S. Agarwal | Updates: 5880 (if approved) S. Agarwal | |||
| Intended status: Standards Track Cisco Systems, Inc | Intended status: Standards Track Cisco Systems, Inc | |||
| Expires: September 9, 2021 A. Mishra | Expires: 30 September 2022 A. Mishra | |||
| O3b Networks | O3b Networks | |||
| A. Saxena | A. Saxena | |||
| Ciena Corporation | Ciena Corporation | |||
| A. Dekok | A. Dekok | |||
| Network RADIUS SARL | Network RADIUS SARL | |||
| March 8, 2021 | 29 March 2022 | |||
| Secure BFD Sequence Numbers | Secure BFD Sequence Numbers | |||
| draft-ietf-bfd-secure-sequence-numbers-08 | draft-ietf-bfd-secure-sequence-numbers-09 | |||
| Abstract | Abstract | |||
| This document describes a security enhancement for the sequence | This document describes two new BFD Authentication mechanism, | |||
| number used in BFD control packets. This document updates RFC 5880. | Meticulous Keyed ISAAC, and Meticulous Keyed FNV1A. These mechanisms | |||
| can be used to authenticate BFD packets, and secure the sequence | ||||
| number exchange, with less CPU time cost than using MD5 or SHA1, with | ||||
| the tradeoff of decreased security. This document updates RFC 5880. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on September 9, 2021. | This Internet-Draft will expire on 30 September 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | license-info) in effect on the date of publication of this document. | |||
| publication of this document. Please review these documents | Please review these documents carefully, as they describe your rights | |||
| carefully, as they describe your rights and restrictions with respect | and restrictions with respect to this document. Code Components | |||
| to this document. Code Components extracted from this document must | extracted from this document must include Revised BSD License text as | |||
| include Simplified BSD License text as described in Section 4.e of | described in Section 4.e of the Trust Legal Provisions and are | |||
| the Trust Legal Provisions and are provided without warranty as | provided without warranty as described in the Revised BSD License. | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 | 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Theory of operation . . . . . . . . . . . . . . . . . . . . . 2 | 3. Meticulous Keyed ISAAC . . . . . . . . . . . . . . . . . . . 3 | |||
| 4. Impact of using a hash . . . . . . . . . . . . . . . . . . . 4 | 4. Meticulous Keyed FNV1A . . . . . . . . . . . . . . . . . . . 5 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 5.1. Seeding and Operation of ISAAC . . . . . . . . . . . . . 7 | |||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | 5.2. Secret Key . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5.3. Seeding ISAAC . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 | 6. Meticulous Keyed ISAAC Authentication . . . . . . . . . . . . 9 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 5 | 7. Meticulous Keyed FNV1A Authentication . . . . . . . . . . . . 10 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | 7.1. Calculation of the FNV-1a Digest . . . . . . . . . . . . 12 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | ||||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | ||||
| 9.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
| 9.2. Re-Use of keys . . . . . . . . . . . . . . . . . . . . . 14 | ||||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 | ||||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 15 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
| 1. Introduction | 1. Introduction | |||
| BFD [RFC5880] section 6.7 describes the use of monotonically | BFD [RFC5880] defines a number of authentication mechanisms, | |||
| incrementing 32-bit sequence numbers for use in authentication of BFD | including Simple Password (Section 6.7.2), and various other methods | |||
| packets. While this method protects against simple replay attacks, | based on MD5 and SHA1 hashes. The benefit of using cryptographic | |||
| the monotonically incrementing sequence numbers are predictable and | hashes is that they are secure. The downside to cryptographic hashes | |||
| vulnerable to more complex attack vectors. This document proposes | is that they are expensive and time consuming on resource-constrained | |||
| the use of non-monotonically-incrementing sequence numbers in the BFD | hardware. | |||
| authentication section to enhance the security of BFD sessions. | ||||
| Specifically, the document presents a method to generate pseudo- | When BFD packets are unauthenticated, it is possible for an attacker | |||
| random sequence numbers on the frame by algorithmically hashing | to forge, modify, and/or replay packets on a link. These attacks | |||
| monotonically increasing sequence numbers. Since the monotonically | have a number of side effects. They can cause parties to believe | |||
| increasing sequence number does not appear on the wire, it is | that a link is down, or they can cause parties to believe that the | |||
| difficult for a third party to launch a replay attack. | link is up when it is, in fact, down. The goal of these methods is | |||
| to prevent spoofing of the BFD session by someone who could guess the | ||||
| next sequence number. We therefore define simple and fast Auth Type | ||||
| methods which allow parties to detect and prevent both spoofed | ||||
| sequence numbers, and spoofed packets. | ||||
| This document proposes the use of Authentication methods which | ||||
| provides meticulous keying, but which have less impact on resource | ||||
| constrained systems. The algorithms chosen are ISAAC [ISAAC], which | ||||
| is a fast cryptographic random number generator, and FNV-1a FNV1A | ||||
| [FNV1A] which is a fast (but non-cryptographic) hash. ISAAC has been | ||||
| subject to significant cryptanalysis in the past thirty years, and | ||||
| has not yet been broken. Similarly, FNV-1a is fast, and while not | ||||
| cryptographically secure, it is has good hashing properties. | ||||
| 2. Requirements Language | 2. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| 3. Theory of operation | 3. Meticulous Keyed ISAAC | |||
| Instead of inserting a monotonically, sometimes occasionally, | If the Authentication Present (A) bit is set in the header, and the | |||
| increasing sequence number in BFD control packets, the ciphertext | State (Sta) field equals 3 (Up), and the Authentication Type field | |||
| result from a symmetric key algorithm operation (Symmetric-key | contains TB1 (Meticulous Keyed ISAAC), the Authentication Section has | |||
| algorithms require both the sender and the recipient of a message to | the following format: | |||
| have the same shared secret key) is inserted. The result is | ||||
| computed, using a shared key, on the sequence number. That | ||||
| ciphertext result is then inserted into the sequence number field of | ||||
| the packet. In case of BFD Authentication | ||||
| [I-D.ietf-bfd-optimizing-authentication], the sequence number used in | ||||
| computing an authenticated packet would be this new computed | ||||
| ciphertext. Even though the BFD Authentication | ||||
| [I-D.ietf-bfd-optimizing-authentication] sequence number is | ||||
| independent of this enhancement, it would benefit by using the | ||||
| computed ciphertext. | ||||
| As currently defined in BFD [RFC5880], a BFD packet with | 0 1 2 3 | |||
| authentication will undergo the following steps, where: | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Auth Type | Auth Len | Auth Key ID | Reserved | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Sequence Number | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Seed | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Auth-Key | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| [O]: original RFC 5880 packet with monotonically increasing sequence | Auth Type | |||
| number | The Authentication Type, which in this case is TB1 (Meticulous | |||
| Keyed ISAAC). If the State (Sta) field value is not 3 (Up), then | ||||
| Meticulous Keyed ISAAC MUST NOT be used. | ||||
| [S]: pseudo random sequence number | Auth Len | |||
| [A]: Authentication | The length of the Authentication Section, in bytes. For | |||
| Meticulous Keyed ISAAC authentication, the length is 16. | ||||
| Sender Receiver | Auth Key ID | |||
| [O] [S] [A] ------------- [A] [S] [O] | The authentication key ID in use for this packet. This allows | |||
| multiple keys to be active simultaneously. | ||||
| This document proposes that for enhanced security in sequence number | Reserved | |||
| encoding, the sender would identify a symmetric key algorithm that | ||||
| would create a 32 bit ciphertext. The symmetric key is provisioned | ||||
| securely on the sender and receiver of the BFD session. The | ||||
| mechanism of provisioning such a key is outside the scope of this | ||||
| document. This key SHOULD be different from the symmetric key used | ||||
| to to authenticate the packet. Instead of sending the sequence | ||||
| number, the sender encrypts the sequence number using it as input to | ||||
| the symmetric algorithm to produce the ciphertext, which is then | ||||
| inserted in place of the sequence number. | ||||
| Upon receiving the BFD Control packet, the receiver decrypts the | This byte MUST be set to zero on transmit, and ignored on receipt. | |||
| ciphertext using the same provisioned shared key to produce the | ||||
| received sequence number. It compares the received sequence number | ||||
| against the expected sequence number. The mechanism used for | ||||
| comparing is an implementation detail (implementations may pre- | ||||
| calculate the expected sequence number, or decrypt the received | ||||
| sequence number before comparing against expected value). To | ||||
| tolerate dropped frames, the receiver must compare the received | ||||
| sequence number against the current expected sequence number. BFD | ||||
| [RFC5880] mentions that received sequence number should be between | ||||
| (bfd.RcvAuthSeq(+1) to bfd.RcvAuthSeq+(3*Detect Mult) inclusive. | ||||
| Note: The first sequence number can be obtained using the same | ||||
| principles stated in BFD [RFC5880] i.e. (using bfd.AuthSeqKnown and | ||||
| bfd.RcvAuthSeq) | ||||
| K: symmetric key | ||||
| S: sequence number | Sequence Number | |||
| S': encrypted sequence number OR ciphertext result | The sequence number for this packet. For Meticulous Keyed ISAAC | |||
| Authentication, this value is incremented for each successive | ||||
| packet transmitted for a session. This provides protection | ||||
| against replay attacks. | ||||
| O: original RFC 5880 packet with monotonically increasing sequence | Seed | |||
| number | ||||
| f(S, K) = S', where f is a symmetric encryption algorithm | A 32-bit (4 octet) seed which is used in conjunction with the | |||
| shared key in order to configure and initialize the ISAAC pseudo- | ||||
| random-number-generator (PRNG). It is used to identify and | ||||
| distinguish "streams" of random numbers which are generated by | ||||
| ISAAC. | ||||
| f(S', K) = S, where f is a symmetric decryption algorithm | Auth-Key | |||
| Sender Receiver | This field carries the 32-bit (4 octet) ISAAC output which is | |||
| associated with the Sequence Number. The ISAAC PRNG MUST be | ||||
| configured and initialized as given in section TBD. | ||||
| [O] [S'] [A] -------- [A] [S] [O] | Note that the Auth-Key here does not include any summary or hash | |||
| of the packet. The packet itself is completely unauthenticated. | ||||
| The above diagram describes how the sender encrypts and receiver | The purpose of this method is to secure the sequence number exchange, | |||
| decrypts the sequence number. The sender starts by taking the | and to both detect and prevent spoofing of sequence numbers. In some | |||
| monotonically increasing (but non linear) sequence number and | cases, it is acceptable to not authenticate the entire packet, in | |||
| encrypting it using a symmetric encryption algorithm. The resulting | which case this method may be used. | |||
| ciphertext replaces the sequence number. As per BFD [RFC5880], it | ||||
| then calculates the hash for the entire packet and appends the hash | ||||
| value to the end of the packet, before transmitting it. | ||||
| The receiver hashes the entire packet as part of receiver | When the receiving party receives a BFD packet with an expected | |||
| authentication. On successful authentication, it decrypts the | sequence number, and the correct corresponding ISAAC output, it knows | |||
| ciphertext with the same key used to encrypt it, in order to obtain | that only the authentic sending party could have sent that message. | |||
| the original sequence number. If it is greater than the previously | The sending party is therefore alive/up, and intended to send the | |||
| received monotonically increasing sequence number, then the receiver | message. | |||
| knows it's a valid sequence number. | ||||
| 4. Impact of using a hash | While the rest of the contents of the BFD packet are unauthenticated | |||
| and may be modified by an attacker, the same is true of stronger Auth | ||||
| Types, such as MD5 or SHA1. The Auth Type methods are not designed | ||||
| to prevent such attacks. Instead, they are designed to prevent an | ||||
| attacker from spoofing identities, and an attacker from artificially | ||||
| keeping a session "Up". | ||||
| Under this proposal, every packet's sequence number is encoded in | 4. Meticulous Keyed FNV1A | |||
| ciphertext. Therefore, there is some impact on the system and its | ||||
| performance while doing encryption/decryption. As security measures | ||||
| go, this enhancement greatly increases the security of the packet | ||||
| with or without authentication of the entire packet. | ||||
| 5. IANA Considerations | If the Authentication Present (A) bit is set in the header, and the | |||
| State (Sta) field equals 3 (Up), and the Authentication Type field | ||||
| contains TB2 (Meticulous Keyed FNV1A), the Authentication Section has | ||||
| the following format: | ||||
| This document makes no request of IANA. | 0 1 2 3 | |||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Auth Type | Auth Len | Auth Key ID | Reserved | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Sequence Number | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Seed | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Digest | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Auth Type | ||||
| The Authentication Type, which in this case is TB2 (Meticulous | ||||
| Keyed FNV1A). If the State (Sta) field value is not 3 (Up), then | ||||
| Meticulous Keyed FNV1A MUST NOT be used. | ||||
| Auth Len | ||||
| The length of the Authentication Section, in bytes. For | ||||
| Meticulous Keyed FNV1A authentication, the length is 16. | ||||
| Auth Key ID | ||||
| The authentication key ID in use for this packet. This allows | ||||
| multiple keys to be active simultaneously. | ||||
| Reserved | ||||
| This byte MUST be set to zero on transmit, and ignored on receipt. | ||||
| Sequence Number | ||||
| The sequence number for this packet. For Meticulous Keyed FNV1A | ||||
| Authentication, this value is incremented for each successive | ||||
| packet transmitted for a session. This provides protection | ||||
| against replay attacks. | ||||
| Seed | ||||
| A 32-bit (4 octet) seed which is used in conjunction with the | ||||
| shared key in order to configure and initialize the ISAAC PRNG. | ||||
| It is also used to identify and distinguish "streams" of random | ||||
| numbers which are generated by ISAAC. | ||||
| Digest | ||||
| This field carries the 32-bit (4 octet) FNV1A digest associated | ||||
| with the Sequence Number. The ISAAC PRNG MUST be configured and | ||||
| initialized as given in section TBD. | ||||
| Note that the ISAAC PRNG output is still used with this | ||||
| authentication type. The FNV1A hash is fast, but it is not | ||||
| secure. In order to reach an acceptable level of security with | ||||
| FNV1A, we use ISAAC to generate secure per-packet "signing keys". | ||||
| These per-packet keys are then used with FNV1A in order to perform | ||||
| a keyed of hash the packet, and therefore create the Digest. | ||||
| 5. Operation | ||||
| BFD requires fast and reasonably secure authentication of messages | ||||
| which are exchanged. Methods using MD5 or SHA1 are CPU intensive, | ||||
| and can negatively impact systems with limited CPU power. | ||||
| We use ISAAC here as a way to generate an infinite stream of pseudo- | ||||
| random numbers. With Meticulous Keyed ISAAC, these numbers are used | ||||
| as a signal that the sending party is authentic. That is, only the | ||||
| sending party can generate the numbers. Therefore if the receiving | ||||
| party sees a correct number, then only the sending party could have | ||||
| generated that number. The sender is therefore authentic, even if | ||||
| the packet contents are not necessarily trusted. | ||||
| Note that since the packets are not signed with this authentication | ||||
| type, the Meticulous Keyed ISAAC method MUST NOT be used to signal | ||||
| BFD state changes. For BFD state changes, and a more optimized way | ||||
| to authenticate packets, please refer to BFD Authentication | ||||
| [I-D.ietf-bfd-optimizing-authentication]. Instead, the packets | ||||
| containing Meticulous Keyed ISAAC are only a signal that the sending | ||||
| party is still alive, and that the sending party is authentic. That | ||||
| is, these Auth Type methods must only be used when | ||||
| bfd.SessionState=Up, and the State (Sta) field equals 3 (Up). | ||||
| If slightly more security is desired, the packets can be | ||||
| authenticated via the Meticulous Keyed FNV1A method. This method is | ||||
| similar to the Meticulous Keyed ISAAC authentication type, except | ||||
| that the FNV-1A hash function is used to hash a combination of the | ||||
| packet, and per-packet ISAAC pseudo-random number. If the receiving | ||||
| party is able to validate the hash, then the receiver knows both that | ||||
| the sender is authentic, and that the packet contents have likely not | ||||
| been modified. | ||||
| As this hash function is not very secure, this method can be used | ||||
| only in situations where the Meticulous Keyed ISAAC method can be | ||||
| used. The Meticulous Keyed FNV1A method MUST NOT be used to signal | ||||
| BFD state changes. | ||||
| 5.1. Seeding and Operation of ISAAC | ||||
| The ISAAC PRNG state is initialized with the 32-bit Seed, followed by | ||||
| the secret key, and then the rest of the state is filled with zeros. | ||||
| The internal state of ISAAC is 1024 bytes, so the secret key is | ||||
| limited to 1020 bytes in length. | ||||
| The origin of the Seed field is discussed later in this document. | ||||
| For now, we note that each time a new Seed is used, the | ||||
| bfd.XmitAuthSeq value MUST be set to zero. | ||||
| Once the state has been initialized, the standard ISAAC initial | ||||
| mixing function is run. Once his operation has been performed, ISAAC | ||||
| will be able to produce 256 random numbers at near-zero cost. When | ||||
| all 256 numbers are consumed, the ISAAC mixing function is run, which | ||||
| then results in another set of 256 random numbers | ||||
| ISAAC can be thought of here as producing an infinite stream of | ||||
| numbers, based on a secret key, where the numbers are produced in | ||||
| "pages" of 256 32-bit vlaues. This property of ISAAC allows for | ||||
| essentially zero-cost "seeking" within a page. The expensive | ||||
| operation of mixing is performed only once per 256 packets, which | ||||
| means that most BFD packet exchanges can be fast and efficient. | ||||
| The Sequence number is used to "seek" within a the stream of 32-bit | ||||
| numbers produced by ISAAC. The sending party increments the Sequence | ||||
| Number on every packet sent, to indicate to the receiving party where | ||||
| it is in the sequence. | ||||
| The receiving party can then look at the Sequence Number to determine | ||||
| which particular PRNG value is being used in the packet. The | ||||
| Sequence Number thus permits the two parties to synchronise if/when a | ||||
| packet or packets are lost. Incrementing the Sequence Number for | ||||
| every packet also prevents the re-use of any individual pseudo-random | ||||
| number which was derived from ISAAC. | ||||
| The Sequence Number can increment without bounds, though it can wrap | ||||
| once it reaches the limit of the 32-bit counter field. ISAAC has a | ||||
| cycle length of 2^8287, so there is no issue with using more than | ||||
| 2^32 values from it. | ||||
| The result of the above operation is an infinite series of numbers | ||||
| which are unguessable, and which can be used to authenticate the | ||||
| sending party. | ||||
| 5.2. Secret Key | ||||
| For interoperability, the management interface by which the key is | ||||
| configured MUST accept ASCII strings, and SHOULD also allow for the | ||||
| configuration of any arbitrary binary string in hexadecimal form. | ||||
| Other configuration methods MAY be supported. | ||||
| The secret Key is mixed with the Seed before being used in ISAAC. If | ||||
| instead ISAAC was initialized without a Seed, then an attacker could | ||||
| pre-compute ISAAC states for many keys, and perform an off-line | ||||
| dictionary attack. The addition of the Seed makes these attacks | ||||
| infeasable. | ||||
| As a result, it is safe to use the same secret Key for the Auth Types | ||||
| defined here, and also for other Auth Types. | ||||
| 5.3. Seeding ISAAC | ||||
| The value of the Seed field SHOULD be derived from a secure source. | ||||
| Exactly how this can be done is outside of the scope of this | ||||
| document. | ||||
| The Seed value SHOULD remain the same for the duration of a BFD | ||||
| session. The Seed value MAY change when the BFD state changes. | ||||
| If the sending party changes its Seed value, bfd.XmitAuthSeq value | ||||
| MUST be set to zero, otherwise the receiving party would be unable to | ||||
| synchronize its sequence of numbers produced by the ISAAC generator. | ||||
| There is no way to signal or negotiate Seed changes. The receiving | ||||
| party MUST remember the current Seed value, and then detect if the | ||||
| Seed changes. Note that the Seed value MUST NOT change unless | ||||
| sending party has signalled a BFD state change with a a packet that | ||||
| is authenticated using a more secure Auth Type method. | ||||
| 6. Meticulous Keyed ISAAC Authentication | ||||
| In this method of authentication, one or more secret keys (with | ||||
| corresponding key IDs) are configured in each system. One of the | ||||
| keys is used to seed the ISAAC PRNG. The output of ISAAC (I) is used | ||||
| to signal that the sender is authentic. To help avoid replay | ||||
| attacks, a sequence number is also carried in each packet. For | ||||
| Meticulous Keyed ISAAC, the sequence number is incremented on every | ||||
| packet. | ||||
| The receiving system accepts the packet if the key ID matches one of | ||||
| the configured Keys, the Auth-Key derived from the selected Key, | ||||
| Seed, and Sequence Number matches the Auth-Key carried in the packet, | ||||
| and the sequence number is strictly greater than the last sequence | ||||
| number received (modulo wrap at 2^32) | ||||
| Transmission Using Meticulous Keyed ISAAC Authentication | ||||
| The Auth Type field MUST be set to TBD1 (Meticulous Keyed ISAAC). | ||||
| The Auth Len field MUST be set to 16. The Auth Key ID field MUST | ||||
| be set to the ID of the current authentication key. The Sequence | ||||
| Number field MUST be set to bfd.XmitAuthSeq. | ||||
| The Seed field MUST be set to the value of the current seed used | ||||
| for this sequence. | ||||
| The Auth-Key field MUST be set to the output of ISAAC, which | ||||
| depends on the secret Key, the current Seed, and the Sequence | ||||
| Number. | ||||
| For Meticulous Keyed ISAAC, bfd.XmitAuthSeq MUST be incremented on | ||||
| each packet, in a circular fashion (when treated as an unsigned | ||||
| 32-bit value). The bfd.XmitAuthSeq MUST NOT be incremented by | ||||
| more than one for a packet. | ||||
| Receipt using Meticulous Keyed ISAAC Authentication | ||||
| If the received BFD Control packet does not contain an | ||||
| Authentication Section, or the Auth Type is not correct (TBD2 for | ||||
| Meticulous Keyed ISAAC), then the received packet MUST be | ||||
| discarded. | ||||
| If the Auth Key ID field does not match the ID of a configured | ||||
| authentication key, the received packet MUST be discarded. | ||||
| If the Auth Len field is not equal to 16, the packet MUST be | ||||
| discarded. | ||||
| If the Seed field does not match the current Seed value, the | ||||
| packet MUST be discarded. | ||||
| If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For | ||||
| Meticulous Keyed FNV1A, if the sequence number lies outside of the | ||||
| range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) | ||||
| inclusive (when treated as an unsigned 32-bit circular number | ||||
| space) the received packet MUST be discarded. | ||||
| Calculate the current expected output of ISAAC, which depends on | ||||
| the secret Key, the current Seed, and the Sequence Number. If the | ||||
| value does not matches the Auth-Key field, then the packet MUST be | ||||
| discarded. | ||||
| Note that in some cases, calculating the expected output of ISAAC | ||||
| will result in the creation of a new "page" of 256 numbers. This | ||||
| process will irreversible, and will destroy the current "page". | ||||
| As a result, if the generation of a new output will create a new | ||||
| "page", the receiving party MUST save a copy of the entire ISAAC | ||||
| state before proceeding with this calculation. If the outputs | ||||
| match, then the saved copy can be discarded, and the new ISAAC | ||||
| state is used. If the outputs do not match, then the saved copy | ||||
| MUST be restored, and the modified copy discarded. | ||||
| 7. Meticulous Keyed FNV1A Authentication | ||||
| Where slightly more security is needed, the sender can use Meticulous | ||||
| Keyed FNV1A. In this method, each packet is signed with a non- | ||||
| cryptographic hash, FNV-1a [FNV1A]. This hash is reasonably fast, it | ||||
| has good distribution, and collisions are rare. However, it is | ||||
| linear, and potentially reversible. In addition, its output is only | ||||
| 32 bits, and it is not cryptographically strong. | ||||
| In this methods of authentication, one or more secret keys (with | ||||
| corresponding key IDs) are configured in each system. One of the | ||||
| keys is included in an FNV1A digest calculated over the outgoing BFD | ||||
| Control packet, but the Key itself is not carried in the packet. To | ||||
| help avoid replay attacks, a sequence number is also carried in each | ||||
| packet. For Meticulous Keyed FNV1A, the sequence number is | ||||
| incremented on every packet. | ||||
| The receiving system accepts the packet if the key ID matches one of | ||||
| the configured Keys, an FNV-1a digest including the selected key | ||||
| matches the digest carried in the packet, and the sequence number is | ||||
| strictly greater than the last sequence number received (modulo wrap | ||||
| at 2^32) | ||||
| Transmission Using Meticulous Keyed FNV1A Authentication | ||||
| The Auth Type field MUST be set to TBD2 (Meticulous Keyed FNV1A). | ||||
| The Auth Len field MUST be set to 16. The Auth Key ID field MUST | ||||
| be set to the ID of the current authentication key. The Sequence | ||||
| Number field MUST be set to bfd.XmitAuthSeq. | ||||
| The Digest field MUST be set to the value of the FNV-1a digest, as | ||||
| described below. | ||||
| For Meticulous Keyed FNV1A, bfd.XmitAuthSeq MUST be incremented on | ||||
| each packet, in a circular fashion (when treated as an unsigned | ||||
| 32-bit value). The bfd.XmitAuthSeq MUST NOT be incremented by | ||||
| more than one for a packet. | ||||
| Receipt Using Meticulous Keyed FNV1A Authentication | ||||
| If the received BFD Control packet does not contain an | ||||
| Authentication Section, or the Auth Type is not correct (TBD2 for | ||||
| Meticulous Keyed FNV1A), then the received packet MUST be | ||||
| discarded. | ||||
| If the Auth Key ID field does not match the ID of a configured | ||||
| authentication key, the received packet MUST be discarded. | ||||
| If the Auth Len field is not equal to 16, the packet MUST be | ||||
| discarded. | ||||
| If the Seed field does not match the current Seed value, the | ||||
| packet MUST be discarded. | ||||
| If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For | ||||
| Meticulous Keyed FNV1A, if the sequence number lies outside of the | ||||
| range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) | ||||
| inclusive (when treated as an unsigned 32-bit circular number | ||||
| space) the received packet MUST be discarded. | ||||
| Otherwise (bfd.AuthSeqKnown is 0), bfd.AuthSeqKnown MUST be set to | ||||
| 1, and bfd.RcvAuthSeq MUST be set to the value of the received | ||||
| Sequence Number field. | ||||
| Replace the contents of the Digest field with zeros, and calculate | ||||
| the FNV-1a digest as described below. If the calculated FNV-1a | ||||
| digest is equal to the received value of the Digest field, the | ||||
| received packet MUST be accepted. Otherwise (the digest does not | ||||
| match the Digest field), the received packet MUST be discarded. | ||||
| 7.1. Calculation of the FNV-1a Digest | ||||
| Unlike other authentication mechanisms, the user-supplied key is not | ||||
| placed into the Auth Key / Digest field, and the packet hashed. As | ||||
| FNV-1a is not a cryptographic hash, such a process would simplify the | ||||
| process for an attacker to "crack" the key. | ||||
| Instead, for a particular packet "P", and ISAAC pseudo-random number | ||||
| "I", the FNV1A digest "D" is calculated as shown below, where "+" | ||||
| indicates concatenation. | ||||
| D = FNV1A(I + P + I) | ||||
| Where "+" denotes concatentation. We also note that the Digest field | ||||
| of the packet MUST be initialized to all zeroes before this | ||||
| calculation is performed | ||||
| The calculated value "D" is then inserted into the packet in the | ||||
| Digest field, and the packet is sent as normal. The receiving party | ||||
| reverses this operation in order to validate the packet. | ||||
| 8. IANA Considerations | ||||
| This document asks that IANA allocate a new entry in the "BFD | ||||
| Authentication Types" registry. | ||||
| Address - TBD1 | ||||
| BFD Authentication Type Name - Meticulous Keyed ISAAC | ||||
| Reference - this document | ||||
| Address - TBD2 | ||||
| BFD Authentication Type Name - Meticulous Keyed FNV1A | ||||
| Reference - this document | ||||
| Note to RFC Editor: this section may be removed on publication as an | Note to RFC Editor: this section may be removed on publication as an | |||
| RFC. | RFC. | |||
| 6. Security Considerations | 9. Security Considerations | |||
| In a symmetric key algorithm, the key is shared between the two | The security of this proposal depends strongly on the length of the | |||
| systems. Distribution of this key to all the systems at the same | secret, and the entropy of the key. It is RECOMMENDED that the key | |||
| time can be quite a cumbersome task. BFD sessions running a fast | be 16 octets in length or more. | |||
| rate will require these keys to be refreshed often, which poses a | ||||
| further challenge. Therefore, it is difficult to change the keys | ||||
| during the operation of a BFD session without affecting the stability | ||||
| of the BFD session. Therefore, it is recommended to administratively | ||||
| disable the BFD session before changing the keys. If the keys are | ||||
| not changed frequently, an attacker can try to guess the key to | ||||
| launch a replay attack. | ||||
| This method allows the BFD end-points to detect a malicious packet | The security of this proposal depends strongly on ISAAC. This | |||
| (the decrypted sequence number will not be in sequence). The | generator has been analyzed and has not been broken. Research shows | |||
| behavior of the session, when such a packet is detected, is based on | few other CSRNGs which are as simple and as fast as ISAAC. For | |||
| the implementation. A flood of such malicious packets may cause a | example, many other generators are based on AES, which is infeasibe | |||
| BFD session to be operationally down. | for resource constrained systems. | |||
| The symmetric algorithm and key size will determine the difficulty | The security of this proposal depends on the strength of the FNV-1a | |||
| for an attacker to decipher the key from the transmitted BFD frames. | hash algorithm. Folding the output of ISAAC into the hash limits the | |||
| The sequential nature of the payload (sequence numbers) simplifies | ability of an attacker to reverse the hash, or to perform off-line | |||
| the decoding of the key. It is, therefore, recommended to use longer | dictionary attacks. Even if one particular 32-bit per-packet key is | |||
| keys or more secure symmetric algorithms. | found via brute force, that information will be useless, as the next | |||
| packet will use a different key. And since ISAAC is secure, | ||||
| knowledge of one particular key will give an attacker no ability to | ||||
| predict the next key. | ||||
| 7. Acknowledgements | In a keyed algorithm, the key is shared between the two systems. | |||
| Distribution of this key to all the systems at the same time can be | ||||
| quite a cumbersome task. BFD sessions running a fast rate will | ||||
| require these keys to be refreshed often, which poses a further | ||||
| challenge. Therefore, it is difficult to change the keys during the | ||||
| operation of a BFD session without affecting the stability of the BFD | ||||
| session. Therefore, it is recommended to administratively disable | ||||
| the BFD session before changing the keys. | ||||
| This method allows the BFD end-points to detect a malicious packet, | ||||
| as the calculated hash value will not match the value found in the | ||||
| packet. The behavior of the session, when such a packet is detected, | ||||
| is based on the implementation. A flood of such malicious packets | ||||
| may cause a BFD session to be operationally down. | ||||
| As noted earlier with Meticulous Keyed FNV1A, each packet is | ||||
| associated with a unique, per-packet key. This process means that | ||||
| even if an observer sees the Auth-Key, or the FNV-1a hash for one | ||||
| packet, the only information gained will be a key which is never be | ||||
| re-used, and will therefore be useless to an attacker. Further, even | ||||
| if the attacker can "crack" a sequence of packets to obtain a stream | ||||
| of keys, the cryptographic nature of ISAAC makes it impossible for | ||||
| the attacker to derive the input key which is used to "seed" the | ||||
| ISAAC state. | ||||
| The particular method of hashing was chosen because of the non- | ||||
| cryptographic amd reversible nature of the FNV-1a hash. If the | ||||
| digest had been calculated any other way, then an attacker would have | ||||
| significantly less work to do in order to "crack" the hash. In short | ||||
| the per-packet key protects the hash, and and hash protects the per- | ||||
| packet key. | ||||
| We believe that this construction is reasonably secure, given the | ||||
| constraints. If cryptographic security is desired, then implementors | ||||
| can use MD5 or SHA1 authentication mechanisms | ||||
| 9.1. Spoofing | ||||
| When Meticulous Keyed ISAAC is used, it is possible for an attacker | ||||
| who can see the packets to observe a particular Auth Key value, and | ||||
| then copy it to a different packet as a "man-in-the-middle" attack. | ||||
| However, the usefulness of such an attack is limited by the | ||||
| requirements that these packets must not signal state changes in the | ||||
| BFD session, and that the key changes on every packet. | ||||
| Performing such an attack would require an attacker to have the | ||||
| following information and capabilities: | ||||
| This is man-in-the-middle active attack. | ||||
| The attacker has the contents of a stable packet | ||||
| The attacker has managed to deduce the ISAAC key and knows which | ||||
| per-packet key is being used. | ||||
| The attack is therefore limited to keeping the BFD session up when it | ||||
| would otherwise drop. | ||||
| However, the usual actual attack which we are protecting BFD from is | ||||
| availability. That is, the attacker is trying to shut down then | ||||
| connection when the attacked parties are trying to keep it up. As a | ||||
| result, the attacks here seem to be irrelevant in practice. | ||||
| 9.2. Re-Use of keys | ||||
| The strength of the Auth-Type methods is significantly different | ||||
| between the strong one like SHA-1 and ISAAC. While ISAAC has had | ||||
| cryptanalysis, and has not been shown to be broken, that analysis is | ||||
| limited. The question then is whether or not it is safe to use the | ||||
| same key for both Auth Type methods (SHA1 and ISAAC), or should we | ||||
| require different keys for each method? | ||||
| If we recommend different keys, then it is possible for the two keys | ||||
| to be configured differently on each side of a BFD lin. For example. | ||||
| the strong key can be properly provisioned, which allows to the BFD | ||||
| state machine to advance to Up, Then, when we switch to the weaker | ||||
| Auth Type which uses a different key, that key may not match, and the | ||||
| session will immediatly drop. | ||||
| We believe that the use of the same key is acceptable, as the Auth | ||||
| Types which use ISAAC also depend on a Seed. The use of the Seed | ||||
| increases the difficulty of breaking the key, and makes off-line | ||||
| dictionary attacks infeasible. | ||||
| 10. Acknowledgements | ||||
| The authors would like to thank Jeff Haas and Reshad Rahman for their | The authors would like to thank Jeff Haas and Reshad Rahman for their | |||
| reviews of and suggestions for the document. | reviews of and suggestions for the document. | |||
| 8. References | 11. References | |||
| 8.1. Normative References | 11.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
| (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | |||
| <https://www.rfc-editor.org/info/rfc5880>. | <https://www.rfc-editor.org/info/rfc5880>. | |||
| 8.2. Informative References | 11.2. Informative References | |||
| [FNV1A] Noll, L. C., "FNV-1a", | ||||
| http://www.isthe.com/chongo/tech/comp/fnv/index.html#FNV- | ||||
| 1a, 2013. | ||||
| [I-D.ietf-bfd-optimizing-authentication] | [I-D.ietf-bfd-optimizing-authentication] | |||
| Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, | Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, | |||
| "Optimizing BFD Authentication", draft-ietf-bfd- | "Optimizing BFD Authentication", Work in Progress, | |||
| optimizing-authentication-11 (work in progress), July | Internet-Draft, draft-ietf-bfd-optimizing-authentication- | |||
| 2020. | 13, 1 August 2021, <https://www.ietf.org/archive/id/draft- | |||
| ietf-bfd-optimizing-authentication-13.txt>. | ||||
| Authors' Addresses | [ISAAC] Jenkins, R. J., "ISAAC", | |||
| http://www.burtleburtle.net/bob/rand/isaac.html, 1996. | ||||
| Authors' Addresses | ||||
| Mahesh Jethanandani | Mahesh Jethanandani | |||
| Kloud Services | Kloud Services | |||
| Email: mjethanandani@gmail.com | Email: mjethanandani@gmail.com | |||
| Sonal Agarwal | Sonal Agarwal | |||
| Cisco Systems, Inc | Cisco Systems, Inc | |||
| 170 W. Tasman Drive | 170 W. Tasman Drive | |||
| San Jose, CA 95070 | San Jose, CA 95070 | |||
| USA | United States of America | |||
| Email: agarwaso@cisco.com | Email: agarwaso@cisco.com | |||
| URI: www.cisco.com | URI: www.cisco.com | |||
| Ashesh Mishra | Ashesh Mishra | |||
| O3b Networks | O3b Networks | |||
| Email: mishra.ashesh@gmail.com | Email: mishra.ashesh@gmail.com | |||
| Ankur Saxena | Ankur Saxena | |||
| Ciena Corporation | Ciena Corporation | |||
| 3939 North First Street | 3939 North First Street | |||
| San Jose, CA 95134 | San Jose, CA 95134 | |||
| USA | United States of America | |||
| Email: ankurpsaxena@gmail.com | Email: ankurpsaxena@gmail.com | |||
| Alan DeKok | Alan DeKok | |||
| Network RADIUS SARL | Network RADIUS SARL | |||
| 100 Centrepointe Drive #200 | 100 Centrepointe Drive #200 | |||
| Ottowa, ON K2G 6B1 | Ottawa ON K2G 6B1 | |||
| Canada | Canada | |||
| Email: aland@freeradius.org | Email: aland@freeradius.org | |||
| End of changes. 50 change blocks. | ||||
| 153 lines changed or deleted | 599 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||