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

[Alan DeKok <[e-mail]>]

On Jan 21, 2024, at 3:43 PM, Jeffrey Haas <[e-mail]> wrote:
> 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.

  OK.  Sounds good.

>> 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'll push some text to github, but we could add text to the section "Updating RFC 5880":

  The use of "Simple Password" authentication is  NOT RECOMMENDED.  There is little security added by exposing a plain-text password "on the wire".

  Where Simple Password authentication is used, the password MUST NOT be used for other Auth Type methods.  Using Simple Password authentication for one packet and then the same password (for example) for Keyed SHA1 authentication would expose the password, and negate all security gained through the use of Keyed SHA1.


Q: 5880 says that Auth Key ID will identify a particular key. But it's not clear if the Auth Key ID field is meant to be different for each Auth Type, or do all Auth Types share the same Auth Key ID?

>> 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. 

  I think so, yes.

> 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.

  This should be in the optimizing authentication draft, I suppose.  I have fewer opinions there.

  Off of the top of my head, swapping it once per second seems too high.  Once per day may be too low.  It all depends on how often the links stay up.

  Alan DeKok.