> On Jan 20, 2024, at 7:45 PM, Alan DeKok <al...@deployingradius.com> wrote:
>
> On Jan 19, 2024, at 7:14 PM, Mahesh Jethanandani <mjethanand...@gmail.com>
> wrote:
>> In my mind, and my co-authors can correct me if my understanding is
>> incorrect, I do not see "optimized auth" as a choice between "NULL-auth" and
>> "secure-sequence" numbers. When the A-bit is set, the choice is between
>> doing authentication as described in RFC 5880 (bfd.AuthType=[1..5]), or
>> doing "optimized auth". If "optimized auth" is chosen, bfd.AuthType can
>> toggle from one of the non-zero values to NULL-auth (whatever non-zero value
>> is assigned to it) and back.
>>
>> At the same time, if 'secure-seq-num' is configured as ’true’, the sequence
>> number is generated as defined by I-D.ietf-bfd-secure-sequence-numbers, and
>> inserted into the packet. The only question I ask is, if “optimized auth” is
>> enabled, and when there is a state transition, the packet is “fully”
>> authenticated by selecting bfd.AuthType as one of the non-zero values (but
>> not NULL-auth). Do we need to generate a secure sequence number at that
>> time? Or is it easier/simpler to let it continue generating the secure
>> sequence number, and not deal with “lost” packets as the session transitions
>> from bfd.AuthType with a non-zero value and NULL-auth.
>
> We should probably stop calling it "secure sequence numbers". I think that
> name doesn't help.
We'd talked about this before. I'm supportive of a late change to the naming
of the document.
>
> Instead, the draft migrated towards just being another Auth Type, but one
> where the BFD packets are not authenticated. Instead, the sender is verified
> to follow a PRNG sequence. The PRNG is seeded using the secret key and
> various per-session information.
>
> So the Auth Types are "full packet authentication" via SHA, MD5, etc or
> "verified sender".
>
> If the packet isn't authenticated but the sender is verified, then we still
> can decide that the sender is up. And it matters a lot less what the rest of
> the packet contents are.
The procedures in RFC 5880 for the various authentication types discusses what
is covered by the authentication. E.g. password doesn't provide a digest for
any of the packet.
Thus, "Meticulous Keyed ISAAC" is perhaps a reasonable name, and the fact that
it doesn't cover the entire packet isn't necessary in the naming. I.e. none of
the other procedures in their name hint as to what's covered.
>
>>> Interesting edge choice question: Alan's recent changes permits even
>>> "simple password" to be a valid mode, but it's probably not something we
>>> want to operationally support. In particular, because it does NOT include
>>> sequence numbers and thus provides zero protection vs. reply during the
>>> non-optimized path.
>>
>> Agree. Where do we call this out? In this or in the secure-sequence-number
>> draft?
>
> i would lean towards forbidding "simple password", unless it uses a
> different password than is used for the stronger authentication methods.
> Otherwise it leads to the password being exposed.
I'm supportive of that. What text would you recommend?
> I would also ask if the ISAAC PRNG is reasonably secure, do we really need
> to occasionally swap to another Auth Type?
I think this is a matter of question for the generic optimizing procedures.
For the original proposals where we either had zero authentication going on or
the latter NULL authentication mechanism with a sequence number, we wanted
something that proved periodically that the session was actually up. That
required temporarily switching to strong authentication and, implicitly, one
that had sequence numbers to prevent replay attacks.
For Meticulous Keyed ISAAC, we don't have a need for the periodic strong
authentication.
Since we now have split motivations, we need text that lets us decide when we
should periodically use stronger authentication, or not, for staying in the Up
state.
-- Jeff
>
> i.e. what is the reason for switching from ISAAC to SHA1, and then back
> again? What are we trying to prove?
>
> Alan DeKok.
