Optimizing Authentication - periodic re-authentication

[Jeffrey Haas <[e-mail]>]

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.