Re: [netconf] ietf crypto types - permanently hidden

[Andy Bierman <[e-mail]>]

On Wed, May 1, 2019 at 3:17 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

> 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.
>
>
The document-oriented configuration came from a requirement identified
at the IAB Network Management Workshop (way back when).
It is critical for rebooting, swapping out a defective device, etc.

This seems to be a good test for whether NMDA is useful as designed.
It seems obvious that something has to be stored in <running> and
then transformed as it is applied to <intended>.

I don't see how an action or RPC approach meets the operator requirements
identified in RFC 3535.

The "server created config" problem could be viewed as an access control
problem.
There are proprietary YANG extensions that implement this approach.


>
> Thanks,
> Rob
>
>
>

Andy


>
>
> *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
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>