Re: [netconf] ietf crypto types - permanently hidden

[Martin Bjorklund <[e-mail]>]

"Rob Wilton (rwilton)" <[e-mail]> wrote:
> Hi Kent,
> 
> The problem that I have with <generate-key> generating configuration
> directly in <running> is that <running> on the device is now different
> from what the management system thinks should be in <running> on the
> device.
> 
> I.e. it breaks the architectural simplicity that it is only the client
> that controls what goes into in <running>, e.g. perhaps that can be
> summarized by this flow:
> 
> "Update client's desired    ->   "Push to
> config"                         <running>"
>           ^                        |
>           |                        \/
> "Client notified of         <-   "Apply config,
> changes in <operational>"       <operational> updated"
> 
> 
> However, I would not be opposed to allowing <generate-key> create
> configuration that is persisted separately from <running> and injected
> into <intended> (e.g. merged with <running>)

But this isn't really allowed by the architecture in 8342, imo.  If
this would have been the case, we'd have another box with config going
into "intended".  8342 allows "configuration transformations" between
running and intended.

> , hence allowing leaf-refs
> in config validation to work as expected.  I think that this would
> allow device reboot to work as expected.
> 
> If the clients would like to see the keys in the configuration then
> they can monitor <operational> (or <intended>), and then add the keys,
> either in raw form, or encrypted in some way.  But I still think that
> it is architecturally cleaner if it is always the client that updates
> the <running> configuration and never the device.

I agree.  I think it would be worthwile to explore the
"non-action-based" solution that Rob proposed.  Is there anything in
that solution that doesn't work?


/martin



> 
> Thanks,
> Rob
> 
> 
> 
> From: netconf <[e-mail]> On Behalf Of Kent Watsen
> Sent: 03 May 2019 17:24
> To: [e-mail]
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> I had an idea last night that might inch us closer to a solution.
> 
> Essentially, the generate/install-key operations always populate
> <operational>, even for keys that are not-hidden, but then a follow-up
> operation (something like <copy-config>) replicates the not-hidden key
> in <operational> to <running>.  Two options:
> 
> 1) A regular-access admin executes the actions to generate the key,
> get a CSR, configure a resulting signed certificate, etc. and then, as
> a second step later in time, a special-access admin replicates the key
> to <running> (perhaps using standard <get-confg> and <edit-config>),
> so that it can be included in a standard backup and restored to *any*
> device (since this key is "not-hidden", it isn't encrypted with a
> device-specific key and hence can be migrated).
> 
> 2) A regular-access admin executes the actions to generate the key,
> get a CSR, configure a resulting signed certificate, etc. and then, as
> a second step (ideally immediately after), the regular-access admin
> executes a command like <copy-config>, but rather than copying the
> entire datastore, it just copies a subtree.
> 
> Neither option seems great.  #1 is unappealing being it necessitates
> coordination between clients.  #2 is unappealing because defining a
> generic operation for this special case seems too much.
> 
> IMO, allowing <generate-key> to create the configuration directly is
> the only client-friendly answer.
> 
> 
> Kent // contributor
>