Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas <[e-mail]>]

> On Jan 20, 2024, at 7:45 PM, Alan DeKok <[e-mail]> wrote:
> 
> On Jan 19, 2024, at 7:14 PM, Mahesh Jethanandani <[e-mail]> 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.