Jeff, good catch. We can document both ways, ie we can let implementations decide which of the 2 methods below they prefer? Or is the concern that this will cause a DISCUSS?
Regards, Reshad. Sent from my iPhone > On Jan 28, 2024, at 12:21 PM, Jeffrey Haas <jh...@pfrc.org> wrote: > > Optimizing Auth Authors and Working Group, > > The text on github is coming along, thanks. Much of the work has been > toward resolving procedural discussions vs. the secure sequence numbers > draft. While doing my latest review, it occurred to me that the periodic > reauthentication procedure is perhaps flawed. > > When running in the optimized mode, authentication may be disabled, the new > NULL auth type, or Meticulous Keyed ISAAC. For disabled or NULL, the intent > of periodic re-authentication was to address active attacks on the Up > portion of the session.[1] > > The procedures have a BFD implementation periodically sending out > authenticated control packets. However, there's no way in the current > procedures to synchronize that the receiver of those packets should expect > authentication. > > Thus, it's possible for an active attacker to simply drop the strong > authentication packets and simply continue to inject either the > unathenticated packets, or the next expected sequence numbers in the NULL > auth mode. > > There's at least two possible ways to address this: > 1. We simply don't worry about periodic re-auth for no-auth or NULL-auth. > We thus don't protect against this attack. If you care about this attack, > use Meticulous Keyed ISAAC and the attack goes away. > 2. We test periodic strong authentication by using a Poll sequence. If we > don't receive a Fin within the Detect Interval with strong auth, compromise > should be expected. > > > -- Jeff > > [1] Yes... the only attack we have in this mode is "keep the session Up when > it might otherwise not be". I expect the usual hilarity when we get to > security area review. >
