Re: [netconf] ietf crypto types - permanently hidden

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

Hi,

Kent, I'm fine with your proposals.

Regarding subsequent calls to the actions, I agree the safe choice would be to deny them; otherwise, one could run into invalid key pairs (where a certificate was already configured) and authentication failures with network peers (especially in SSH-key-based-authentication case). 

Br,
Balazs

> -----Original Message-----
> From: Kent Watsen <[e-mail]>
> Sent: Wednesday, April 24, 2019 10:30 PM
> To: Juergen Schoenwaelder <[e-mail]>
> Cc: Balázs Kovács <[e-mail]>; [e-mail]
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> 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
>