Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

Hi Juergen,


> Perhaps this should say 'implementation specific' instead 'application
> specific'.

Changed in my local copy.


>> My recommendation is to modify the "generate/install-hidden-key" (renamed to just "generate/install-key") actions to have a flag indicating if the key should be "permanently hidden" (perhaps by using a TPM) or not, in which case configuration is created, same as if the client had used <edit-config>, but without needing to touch the key.
> 
> I agree that having a flag to control the behavior is useful and I
> think there should be explicit text how the action fails in case the
> requested action cannot be performed.
> 
> I am not sure I understand install-hidden-key. The description says:
> 
>           "Requests the device to load the specified values into
>            a hidden key.  The resulting asymmetric key values are
>            considered operational state and hence present only in
>            <operational>.";
> 
> So what is the persistence model of this? Does a key installed with
> install-hidden-key survive reboots? If so, can I delete somehow such a
> hidden key? (Is the answer that this key is tied to the lifetime of
> the list element indirectly using this grouping?) Does invoking
> install-hidden-key twice cause the first installed key to be
> overwritten? Can the install-hidden-key action fail in any way?
> 
> This leads to related questions for generate-hidden-key: Does invoking
> this action twice cause an existing key to be overwritten? Can I
> explicitely delete a generated hidden key? Does deleting the list item
> that directly or indirectly uses this grouping delete a hidden key?

[Disclaimer: the below reflect my understanding of how the current model works, and does not necessarily reflect if we were to flip things around by letting the actions generate configuration.]

The expectation is that the "permanently hidden" keys would persist, presumably with origin=system.

In the YANG, the "permanently-hidden" enum only appears in the "asymmetric-key-pair-grouping" grouping.   Consuming data models are expected to "use" this grouping under a "config true" node.  This grouping's description statement is noteworthy:

 grouping asymmetric-key-pair-grouping {
    description
      "A private/public key pair.
         
       The 'algorithm', 'public-key', and 'private-key'  nodes are
       not mandatory because they MAY be defined in <operational>.
       Implementations SHOULD assert that these values are either
       configured or that they exist in <operational>.";
    ...
 }

Thusly it is expected that the client will create the parent node (e.g., via <edit-config>) and then invoke either the generate or install hidden key action.  Presumably, the lifetime of the permanently hidden key would be tied to the lifetime of its parent.

Regarding what happens when the actions are invoked a second time, it's not specified.  One choice, perhaps the safe choice, would be to deny subsequent attempts, forcing the client to create a new parent node instead.  If the parent node is in a list, such as in the keystore, then the second key could be created, with certificates bound to it, before mapping reference to the old-key to the new-key.  However, if the key is not in a list, such as when using a "local-definition", then in in-place migration, along with service disruption, would be required.

Of course, one has to ask how often/likely is it that a client wants to regenerate the private key.  Presumably it would only be due to the concern that the key had been compromised (which shouldn't happen if "permanently hidden") or, perhaps, due to a proactive key-rotation policy, thinking (misguided, I believe, proven false now) that the private key's entropy expires over time.  Regardless, the point is that it seems to be an action that would seldomly occur and, when/if it does, the effort to create another parent node (in keystore or a local-definition) might not be a big deal.

PS: words such as "expectation" and "presumably" are used above to indicate a likely need for the text to be more explicit.

Kent // contributor