Re: [Netconf] Mandatory local configuration in Keystore groupings

[Balázs Kovács <[e-mail]>]

Hi Kent,

See below.
Br,
Balazs

-----Original Message-----
From: Kent Watsen <[e-mail]> 
Sent: Tuesday, August 28, 2018 9:11 PM
To: Balázs Kovács <[e-mail]>; Martin Bjorklund <[e-mail]>; Balázs Lengyel <[e-mail]>
Cc: [e-mail]
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings



>>> We could define a "load-asymmetric-key" action that has that behavior?
>>
>> Yes; if we decide to support this use case.  What do others think?
>>
> Would this action have 'name' and 'private-key' binary input and the 
> purpose to avoid setting the key via configuration and handling it 
> directly in <operational>? Is it an implementation risk to handle the 
> binary input via configuration but not via action?


The proposed "load-asymmetric-key" action would take 4 mandatory input parameters (name, alg, pub-key, and priv-key) and have no output other than the key showing up in <operational> with the private key "permanently-hidden".

To make things clearer, we might rename these actions to:
  - generate-permanently-hidden-asymmetric-key(...)
  - load-permanently-hidden-asymmetric-key(...)

Yes, use of these actions would be more secure since the private key is thereafter permanently hidden.  If the goal is to have the private key in configuration, then the action should not be used.

Balazs> I preferred the original short name and for me it was clear that this action produces a 'hidden' key. I actually like the idea of changing the 'hardware-protected' enum literal to 'hidden'.

Balazs> I myself just started to realize that you intend to maintain an operational tree that is out-of-sync with the configuration tree. For example, a public key can be determined from the private key. It is ok to require an instance of public key (with must) for a private key, but why is it mandatory to configure it? I did expect the public key filled in either by generate-asymmetric-key action, or by configuring private key. Also the private-key, the public-key, and the algorithm leaves need to be in sync (all valid in respect to the other).

> In our opinion with Balazs L., we think it would be disadvantageous to 
> change the model by ruining the containment relationship between 
> certificate and corresponding asymmetric key.

Can you say some more about this?  Is it mostly that the containment is really intuitive?  That the relationship is linked both ways, whereas a leadref only goes one way?

Balazs> The certificates in keystore are useless without a corresponding private key, so certificates of a key cannot be in the configuration tree once the corresponding key is removed. By the way, how would a private key be removed from <operational> if it does not exist in configuration? If you do it with an action too, how would the corresponding certificates be removed from the configuration?

Martin makes a case for 'B', but he also said that my 'b' was "Better"
but has scaling issues in the general case.  Perhaps we don't worry about the general case here?

Balazs> Was it so? I saw an A and B model, A containing 
must "(algorithm and public-key and private-key)
              or not (algorithm or public-key or private-key)";
and B containing the keys and the certificates in separate container, and a note "I think model B is cleaner".
If I got it well, model A would keep the containment and produce the key name after invoking the action (affecting the configuration tree!?) at least covering the key removal use case properly.

Balazs> If the key generation and load only affects the <operational> only, I would rather vote for model A having the containment relationship between key and certificate(s). Plus, I would also think about the mandatory statements in the configuration tree whether all 4 leaves (name, private-key, public-key, alg) or just name and private key needs to be configured.

> The action of 'generate-asymmetric-key' is typically something that 
> should have effect on the 'running' configuration too (by setting the 
> mandatory leaves) since the user wants to continue working with the 
> result by deploying certificates or anything else related to the 
> created asymmetric key that needs configuration.

Okay, but why use an action at all then?  Everything can be done via standard configuration, right?

Balazs> That is actually a good question. Until the enum had the literal 'hardware-protected' only the configuration use case of the private-key was a bit unclear. Now I assume configuring the private-key as 'hidden' could do the same as generate-private-key, but in that case the operator has no means to configure the public key (the removal of the mandatory condition for the public key could solve this). Regarding 'alg', I guess if hidden private key is asked, then algorithm is an input, but if binary private-key is configured, then it is rather implicit. Would the action be needed then?

Balazs> The action in this case seem to make sense only if the purpose of the actions is really to only affect <operational>. But based on the above, I doubt yet how affecting configuration can be avoided (even with alt A -> to maintain consistent composition of key and cert) I think this question goes back to some YANG principles and is beyond my YANG competence.


Kent // contributor