Re: [netconf] ietf crypto types - permanently hidden

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Kent,

I’m slightly lost here, so my comments may not be that helpful 😊

I don’t understand why do we need an explicit action to create/install the key?  In particular, why can’t there just be a regular (intend based) configuration leaf that is “use-system-defined-key”?  The key values could be reported in <intended> and/or <operational>, suitably protected via NACM, or they could be kept entirely hidden.

I also agree with Martin/Andy that it is highly desirable to allow a device to be configured with a single configuration input file, provided from <startup> or <edit-config|data>.  I think that anything that would require, or encourage, multiple RPC interactions to setup the device would seem to be a big backwards step in terms of device management.

I’m not opposed to RPCs or actions to manage hidden keys on the device if:

(i)               these don’t get written to <running> (because they are not regular configuration), and

(ii)              there is a sensible/secure mechanism to configure the device without requiring any extra RPCs/actions to configure the device.  I.e. the RPCs/actions should only be used for exceptional management of the keys on the device.

Thanks,
Rob


From: netconf <[e-mail]> On Behalf Of Kent Watsen
Sent: 30 April 2019 18:57
To: Martin Bjorklund <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] ietf crypto types - permanently hidden




I (still) object to this.  Actions shouldn't create config.  We
already have generic protcol operations to do this.  We go from a
document-oriented configuration model towards a command-oriented
model.  Not good.  In RESTCONF, the generic methods support things
like ETags, which I suspect you don't want to replicate in this
action?   Will the action support all error-options of edit-config,
like rollback-on-error?

The specifics for how this could work would need to be defined.  Given that it is a special case, I think that we could constrain it heavily and target simple solution.   Depending how much text is required to describe it, it might be good to define an extension statement that could be placed on the actions.  While an extension statement may seem like it opens the gates for general use, we could further define the extension statement as being something that MUST NOT be used when general purpose operations are suitable such that, at least with the IETF, it could only be used in extraordinary circumstances.



Some comments on the new text:

In action generate-hidden-key, it should be stated that the public-key
will be populated, and that the private-key will exist but report
'permanently-hidden'.

Okay, but before making the edit, see comment below about lifetimes...




In action install-hidden-key, shouldn't both public-key and
private-key be mandatory?  Also state that the private-key will report
'permanently-hidden'.

Indeed, fixed.



In leaf private-key, the type binary part of the union doesn't have a
description, and the description for the leaf itself says:

      A binary that contains the value of the private key.

which is not quite correct.

I think we should state that the enum 'permanently-hidden' is only
reported in operational state.

The 'type' statement doesn't have 'description' as a substatement,
but, point taken, two updates:

In leaf private-key:
  OLD:
      A binary that contains the value of the private key.
  NEW:
      Either a binary that contains the value of the private key or, in
      the case of a hidden key, the value 'permanently-hidden'.

In enum permanently-hidden:
  OLD:
       The private key is inaccessible due to being protected by the
       system (e.g., a cryptographic hardware module).
  NEW:
       The private key is inaccessible due to being protected by the
       system (e.g., a cryptographic hardware module).  Since hidden
       keys are only ever reported in <operational>, the value
       'permanently-hidden' never appears in <intended>.


The new descriptions say:

           [...] present only in
           <operational> and bound to the lifetime of the parent
           'config true' node.

Aren't all nodes bound to the lifetime of their parent?
The action is invoked in a node that exists in <operational> and it
creates a key.  What does the statement tell me?

This seems like something new (and maybe wrong) and hence needs to be explained.  This seems new because we are saying that the lifetime of an operational value is tied to the lifetime of a configured value.  Normally we talk about how operational values exist on their own and that, if one wants to override/extend them (e.g., associate a certificate to the private key created by the manufacturer), configuration would overlay the operational values.  By extension, if the configuration is removed, the operational values go back to their original state (i.e., existing on their own).   Here we're saying that, if the configuration (for the parent node) is removed, the operational values are removed as well.

Note that this statement was added because Juergen asked about how hidden keys could be removed/replaced.   We iterated towards not wanting to support the "replace" case, and this seemed like an easy way to handle the "remove" case.  Another way to do this would be via another action such as 'remove-hidden-key'.   What do you think would be best?


Kent // contributor