On Mar 21, 2023, at 2:18 PM, Jeffrey Haas <[email protected]> wrote:
> Aside from my questions about the auth seq number space being shared between
> the
> different modes (ISAAC vs. strong), my comments are largely editorial.
>
> Comments below in the idnits numbered document:
>
>
> 112 3. Meticulous Keyed ISAAC
> [...]
>
> 150 Sequence Number
>
> 152 The sequence number for this packet. For Meticulous Keyed ISAAC
> 153 Authentication, this value is incremented for each successive
> 154 packet transmitted for a session. This provides protection
> 155 against replay attacks.
>
> I believe this sequence number is effectively per-seed. Perhaps say something
> about that here?
Yes.
After looking at it for a bit (poking APIs, sample implementations, etc.), it
looks like the simplest things is to always start the sequence at zero.
i.e. When the ISAAC method is re-seeded, the sequence number should be reset
to zero.
The sequence number is also per-key-ID. So if there are multiple keys, each
one should track its own sequence.
> 180 While the rest of the contents of the BFD packet are unauthenticated
> 181 and may be modified by an attacker, the same is true of stronger Auth
> 182 Types, such as MD5 or SHA1. The Auth Type methods are not designed
> 183 to prevent such attacks. Instead, they are designed to prevent an
> 184 attacker from spoofing identities, and an attacker from artificially
> 185 keeping a session "Up".
>
> This detail is incorrect for the MD5/SHA1 mechanisms. They are computed over
> the entire BFD Control packet. (RFC 5880, ยง6.7.3)
OK. That text is easy enough to fix.
> It's reasonable to call out that the BFD Control packet containing the
> Meticulous Keyed ISAAC authentication mechanism that no authentication is done
> over the packet. This is no different than the Simple Password mechanism in
> terms of authentication over the packet, but clearly significantly better in
> terms of detection of modification due to the randomness of the authkey.
Yes.
> 187 4. Operation
>
> [...]
>
> 201 Note that since the packets are not signed with this authentication
> 202 type, the Meticulous Keyed ISAAC method MUST NOT be used to signal
> 203 BFD state changes. For BFD state changes, and a more optimized way
> 204 to authenticate packets, please refer to BFD Authentication
> 205 [I-D.ietf-bfd-optimizing-authentication]. Instead, the packets
> 206 containing Meticulous Keyed ISAAC are only a signal that the sending
> 207 party is still alive, and that the sending party is authentic. That
> 208 is, these Auth Type methods must only be used when
> 209 bfd.SessionState=Up, and the State (Sta) field equals 3 (Up).
>
> A detail that needs to be clarified in the interactions between these two
> drafts
> is keeping track of Sequence Numbers between the competing mechanisms.
I agree.
> If it is the case that the Sequence Number is intended to be a single
> continuous
> space used by both the Meticulous Keyed ISAAC and the stronger authentication
> while performing state changes, I think we know how this should work.
I think we can't do that. The issue is that the ISAAC method has a 1-1
correlation between sequence number and expected output. The means that each
end has to understand where to start from in the sequence.
We have a few choices here:
* use new sequence numbers for ISAAC
* always start off at zero
* or, start off at some agreed-upon value, perhaps itself derived from ISAAC
* use sequence numbers taken from a previous auth method
* but what if there's no previous auth method, or auth-type==simple?
> 211 4.1. Seeding and Operation of ISAAC
> [...]
>
> 216 The origin of the Seed field is discussed later in this document.
> 217 For now, we note that each time a new Seed is used, the
> 218 bfd.XmitAuthSeq value MUST be set to zero. The Seed MUST be changed
> 219 when a BFD session transitions into the "Up" state. In order to
> 220 prevent continuous rekeying, the Seed MUST NOT be changed while a
> 221 session is in the "Up" state.
>
> Here is where the sequence numbers would need to be coordinated.
>
> Since Meticulous Keyed ISAAC is only expected to be done in the Up state after
> the optimized procedures, the sequence number should be non-zero.
What if there's no auth method, or auth-type==simple?
> I think the
> primary consequence is that when ISAAC procedures kick in for a particular
> seed,
> it could be necessary to generate some number of next-pages to permit index
> into
> the space.
>
> Clearly the mechanism won't work great if so great a time passes that the
> sequence numbers have turned through multiple pages. This isn't the expected
> or
> desired behavior since optimizing authentication procedures are there solely
> for
> securing state changes. However, those consequences should likely be
> mentioned.
I think all of this can be avoided if we just restart the sequence numbers
for ISAAC at zero. The first "page" of generated ISAAC numbers is 256
elements, so it's possible to do O(1) seeking within that page. Which means
that we can lose 256 packets before we need to check another page.
But... if we lose 256 packets, I suspect that the session will transition to
"down". From RFC 5880:
If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For
Keyed MD5, if the sequence number lies outside of the range of
bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
treated as an unsigned 32-bit circular number space), the received
packet MUST be discarded.
We can make similar statements for ISAAC auth,
If we start ISAAC sequences at some non-zero value, then that needs to be
somehow. Since the sequences increment ad infinitum) and wrap, there's no way
to know *where* in the sequence we are.
i.e. a system receives a packet with auth-type==ISAAC, and a sequence number
of 0x68092112. Is that the start of a new sequence? Or did the receiving
system miss some number of packets?
The only way to re-synchronize sequence numbers there is for the receiving
system to just compare the received 32-bit Auth-Key with the output of ISAAC.
If it finds a match, that must be the new sequence number. If it doesn't find
a match, then maybe it's out of sync? Or maybe the secret key doesn't match?
I think it's simple to just say "sequence numbers always start at zero". I
can't think of any security issues associated with that decision. Because the
sequence numbers aren't really used for anything secure. They're just used to
ensure that we have a unique identifier for each 32-bit Auth-Key value
generated by ISAAC.
> 248 The Sequence Number can increment without bounds, though it can wrap
> 249 once it reaches the limit of the 32-bit counter field. ISAAC has a
> 250 cycle length of 2^8287, so there is no issue with using more than
> 251 2^32 values from it.
>
> For the case where the sequence number wraps, what's the expected ISAAC
> behavior?
It just keeps going. The sequence number isn't used to derive the 32-bit
Auth-Keys taken from ISAAC. So wrapping doesn't matter to it.
> Should it to be to regenerate the page for the supplied credentials
> back at sequence number zero? (I expect the usual security AD commentary
> about
> this opening things up to replay attacks, but also expect to point them to the
> usual 2^32 is a Very Big Number point.)
>
> The comment below suggests this is a reset.
>
> 253 The result of the above operation is an infinite series of numbers
> 254 which are unguessable, and which can be used to authenticate the
> 255 sending party.
>
> Depending on the answer to the prior point, you may want to delete this line.
I'm not sure how this means that wrapping leads to a replay / restart. The
ISAAC output is 2^8000 or so, which is effectively infinite.
So this could be clearer. Perhaps some text explaining that the sequence
numbers are only used to detect "out of range" packets, and otherwise are not
used for anything, and have no meaning.
If the sequence wraps to zero, the ISAAC output continues without change, and
MUST NOT reseed, or repeat previously used numbers.
> 263 4.2. Secret Key
>
> 265 For interoperability, the management interface by which the key is
> 266 configured MUST accept ASCII strings, and SHOULD also allow for the
> 267 configuration of any arbitrary binary string in hexadecimal form.
> 268 Other configuration methods MAY be supported.
>
> I suggest a forward reference here to the "re-use of keys" section.
Sure.
> 283 4.3. Seeding ISAAC
>
> [...]
>
> 334 Note that this construct requires that the "Your Discriminator" field
> 335 not change during a session. However, it does allow the "My
> 336 Discriminator" field to change as permitted by RFC5880 Section 6.3
> 337 [RFC5880]
>
> Your Discriminator is only known after the systems start talking to each
> other,
> and thus go to Up. Mostly mentioned as another point towards the auth seq#
> being non-zero for the strong mode.
OK.
> 350 5. Meticulous Keyed ISAAC Authentication
>
> [...]
>
> 366 Transmission Using Meticulous Keyed ISAAC Authentication
>
> 373 The Seed field MUST be set to the value of the current seed used
> 374 for this sequence.
>
> Discussion point for authors: Should we this a state variable name?
> bfd.LocalIsaacSeed, e.g.
I think so, yes.
> 380 For Meticulous Keyed ISAAC, bfd.XmitAuthSeq MUST be incremented on
> 381 each packet, in a circular fashion (when treated as an unsigned
> 382 32-bit value). The bfd.XmitAuthSeq MUST NOT be incremented by
> 383 more than one for a packet.
>
> The point above suggests a page reset to 0 when we wrap.
I'm not sure why. The ISAAC output can just continue. We don't need to
reset.
The ISAAC construction creates a "page" of 256 32-bit numbers. When that
page has been used, the PRNG state is mixed, and it generates another page of
256 32-bit number. At no point does anything "reset" to zero.
> 385 Receipt using Meticulous Keyed ISAAC Authentication
>
> 398 If the Seed field does not match the current Seed value, the
> 399 packet MUST be discarded.
>
> See prior question about state variable name.
>
> 437 7. Security Considerations
>
> 478 7.1. Spoofing
>
> 480 When Meticulous Keyed ISAAC is used, it is possible for an attacker
> 481 who can see the packets to observe a particular Auth Key value, and
> 482 then copy it to a different packet as a "man-in-the-middle" attack.
> 483 However, the usefulness of such an attack is limited by the
> 484 requirements that these packets must not signal state changes in the
> 485 BFD session, and that the Auth Key changes on every packet.
>
> 487 Performing such an attack would require an attacker to have the
> 488 following information and capabilities:
>
> 490 This is man-in-the-middle active attack.
>
> 492 The attacker has the contents of a stable packet
>
> 494 The attacker has managed to deduce the ISAAC key and knows which
> 495 per-packet key is being used.
>
> 497 The attack is therefore limited to keeping the BFD session up when it
> 498 would otherwise drop.
>
> 500 However, the usual actual attack which we are protecting BFD from is
> 501 availability. That is, the attacker is trying to shut down then
> 502 connection when the attacked parties are trying to keep it up. As a
> 503 result, the attacks here seem to be irrelevant in practice.
>
> I would like to congratulate the authors in creating the best summary of "some
> attacks on BFD are silly". It is quite likely the chairs will recommend a
> form
> of this text as boilerplate in future BFD specifications.
Thanks. That was taken from your suggestions, with some word smithing and
additions.
Alan DeKok.
