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

[Jeffrey Haas <[e-mail]>]

Alan,


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

I'd skip the second sentence.

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

The specification is silent on this matter.  My interpretation is that it's always a local matter between two authenticating systems.

The IETF keychain YANG model treats the keychain as a uint64 on top of a individual keychain and keychains are bound to individual protocols.

To pick my own company's implementation, the keychain has a key id 0..63 on an individual chain that may be applied to specific BFD sessions:
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/key-edit-security-authentication-key-chains.html <https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/key-edit-security-authentication-key-chains.html>

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

Agreed.  When to change to a specific authentication is the scope for that draft.

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

Sometimes on the order of months. :-)

-- Jeff