Re: [netconf] updates to client/server drafts

[Andy Bierman <[e-mail]>]

On Mon, Jun 17, 2019 at 6:01 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

> Hi Andy,
>
>
>
> Generally, we try and avoid actions modifying configuration, but in some
> cases this might be allowed (e.g. renumbering ACL entries, or disabling
> some hardware moves active configuration to pre-configuration).
>
>
>
> However, the circumstances where an action might be useful for this
> scenario is potentially a bit different from regular network device
> configuration.
>
>
>
> E.g. some programmatic mechanism to easily add a key to a client device,
> the scenario described by Tom in:
>
> https://mailarchive.ietf.org/arch/msg/netconf/7zOypLmuSnMUIYfsc_wTl2nS-84
>
>
>
> I don’t know the exact details of what is required here, but having an
> action (or RPC), dependent on a feature, might be reasonable for this
> scenario.  I would see this purely as an alternative mechanism to achieving
> the same end goal as regular configuration, potentially to allow different
> NACM rules on the action/RPC.
>
>
>

IMO it is a bad idea to create configuration as a side effect of an action.
Period.
What if the config is locked? Access control allows the user to invoke
action but not
change that specific config? Do the netconf-config-change and yang-push
notifications
get generated? Will the user or the system be identified in the audit logs?
(Too much implementation complexity as well, but the IETF does not care
about that.)

It seems much cleaner for the action to return a label for the keys/cert
(e.g., any sensitive data)
and then the client must configure its use somehow using normal editing
operations.


Thanks,
>
> Rob
>
>
>

Andy


>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* 15 June 2019 16:46
> *To:* Rob Wilton (rwilton) <[e-mail]>
> *Cc:* Martin Bjorklund <[e-mail]>; [e-mail];
> [e-mail]
> *Subject:* Re: [netconf] updates to client/server drafts
>
>
>
>
>
>
>
> On Fri, Jun 14, 2019 at 10:30 AM Rob Wilton (rwilton) <[e-mail]>
> wrote:
>
> Hi Martin, Kent,
>
> > -----Original Message-----
> > From: netconf <[e-mail]> On Behalf Of Martin Bjorklund
> > Sent: 13 June 2019 16:43
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [netconf] updates to client/server drafts
> >
> > Kent Watsen <[e-mail]> wrote:
> > >
> > > >>> I am strictly against hiding actions by encoding 'verbs' in an
> > > >>> ad-hoc data format. I rather not support creation of keys on the
> > device.
> > > >>
> > > >> Remember we had this cases:
> > > >>
> > > >> 1.  upload of keys
> > > >> 2a. generation of keys on the box that will go into hardware
> > protected
> > > >>    storage (and never be accessible) 2b. generation of keys on the
> > > >> box that will be stored on disk
> > > >>    (and never be accessible over the mgmt interface) 3.  generation
> > > >> of keys on the box that become (protected) configuration
> > >
> > > This list is missing cases #1 and #3 described here:
> > > https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7u
> > > Icc
> > >
> > <
> https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc
> > >.
> >
> > #1 (pre-existing key in hw) is orthogonal to the pain points we have
> here;
> > it should be possible to handle this case.
> >
> > #3 (upload of hidden key) should also be straight forward with an action.
> >
> >
> > > Also, we currently make no distinction between (2a) and (2b) - hidden
> > > is hidden, however it's implemented.
> >
> > I know, but the discussion seems to imply that this would be useful and
> it
> > seems trivial to support.
> >
> >
> > > >> I think the previous version of the draft (with YANG actions)
> > > >> handles
> > > >> 1 and 2 (a and b with trivial updates).
> > > >>
> > > >> It is only (3) that we don't have a solution for that everybody
> > > >> accepts.
> > > >>
> > > >> So perhaps we should solve 1 and 2a and 2b, and publish that, and
> > > >> leave 3 for the future?
> > > >
> > > > This may be a way to move forward. In 2a and 2b, will there be a way
> > > > to remove a generated key via the mgmt interface or do I have to
> > > > take a bigger hammer to accomplish this?
> > >
> > > I object to reverting to the approach that doesn't have the key's
> > > 3-tuple (algorithm, public key, private key) marked as mandatory true,
> > > our doing that before was unhelpful.
> >
> > I need to go back and re-read (again, I just read all threads on this
> > issue) some mails to understand what this means.
> >
> >
> > > I was hoping that the "verbs"
> > > approach could leap over the impasse but, if Juergen is strictly
> > > against it, then we should go back to the approach described here:
> > > https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJ
> > > usY
> > > <https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQM
> > > JusY>, for which a draft was never published.
> > >
> > > In the previous link, search for "Now let's discuss what this action
> > > does" and note the two options: (1) is more user-friendly, but one
> > > that Martin appears to be strictly against
> >
> > Yes, and Andy and Rob (at least).  And I do not agree that it is user
> > friendly at all!
>
> I don't think that I'm necessarily against having an action (or RPC) that
> generates a pair of keys and writes them to configuration as a special type
> of configuration update.  But I would very much regard this as a special
> case that is designed as a combined action/RPC solely to make life easier
> for clients rather than the defacto approach.  I.e., I would like there to
> be an equivalent mechanism that works, is just as secure and complete,
> using regular NETCONF <edit-config> config operations and normal
> semantics.  Then the question becomes: If we can do this using regular
> NETCONF semantics, do we still need a separate "easy to use" action/RPC as
> well?
>
>
>
>
>
> IMO it is fair to ask how many servers support actions that change
> configuration today?
>
> If several vendors say "this is great! we use it all the time! no problems
> at all!" then
>
> it is probably appropriate for standardization. Otherwise, not so much.
>
> (I don't think any vendors use this design pattern now)
>
>
>
>
>
> *[RW] *
>
>
>
>
>
>
>
> >
> > > and so perhaps (2) is all
> > > we can agree on, and yes, there would need to be a third (not
> > > mentioned) action to delete the key from <operational> (presumably
> > > after having deleted the same from <running>).  Yes, it is less
> > > friendly, if you want more friendly, then let's do (1).  I'll update
> > > the draft shortly based on the less-friendly approach (2).
> >
> > I don't think (2) is the right solution either.  I think the previous
> > version of the draft was very close to a workable solution.
> >
> > > That said, I'm also okay with giving up (for now) trying to enable a
> > > client request the server to generate a key (hidden or not) or request
> > > the server to install a hidden key [note: these are #2 and #3 in my
> > > first link above].
> >
> > I don't it is necessary to give up this.
> >
> > IMO the only problematic use case is "let the device generate a key that
> > then becomes part of the config".  If we avoid that I think we can handle
> > the other cases.
>
> I think that Juergen's idea of "store the name of the key in the <running>
> configuration, but not necessarily the value" is along the right lines.
>  - If the client is willing to write the key into the configuration,
> perhaps obfuscated, or encrypted, then that is fine.
>  - If the client wants the server to allocate the keys that also works.
>
> Taking Kent's tree diagram from the 3rd of May, perhaps this could be
> modified from:
>
>      +--rw keystore
>         +--rw asymmetric-keys
>            +--rw asymmetric-key* [name]
>               +--rw name
>               +--rw algorithm?                             <--- optional?
>               +--rw public-key?                            <--- optional?
>               +--rw private-key?           union           <--- optional?
>  (note union)
>               +---x generate-hidden-key
>               +---x install-hidden-key
>               +---x generate-certificate-signing-request
>               +--rw certificates
>                  +--rw certificate* [name]
>
> to something like this:
>
>      +--rw keystore
>         +--rw asymmetric-keys
>            +--rw asymmetric-key* [name]
>               +--rw name
>               +--rw type!                                  <-- New
> mandatory field
>               +--rw algorithm?                             <--- optional
>               +--rw public-key?                            <--- optional
>               +--rw private-key?           union           <--- optional
>               +---x regenerate-hidden-key
>               +---x install-hidden-key
>               +---x generate-certificate-signing-request
>               +--rw certificates
>                  +--rw certificate* [name]
>
> Where the new "type" enum field could have 4 options such as:
>  - plain-text <= configured algo, public/private keys in raw format (not
> secure, transferable)
>  - obscured   <= as above, but obscured with a known reversible mechanism
> (not secure, transferable)
>  - encrypted  <= as above, but encrypted using server's public key
> (secure, not transferable)
>  - server-allocated <= only name and optionally algorithm in running
> config, the server allocates the key when applying the configuration,
> public key is available in operational, private key is never reported.  Key
> pair is persisted outside of YANG configuration.
>
> YANG "must" statements could be added to "algorithm", "public-key" and
> "private-key", to enforce that these are always provided if type is
> (plain-text, obscured, encrypted).
>
> The "regenerate-hidden-key" action would allow a server-allocated hidden
> key to be regenerated if required.  If user configuration caused the key to
> be created in the first place, then the key would also be deleted if the
> key list entry is deleted from configuration.
>
> A server could also automatically create its own key, without any user
> intervention.  The server chooses the key name, and the key would be of
> type "server-allocated" but it would only exist in operational
> (origin=system).  If the key needs to be referenced in configuration then
> the client would need to configure (asymmetric-key,
> name=<server-assigned-key-name>, type=server-allocated) into the
> configuration.  Subsequently removing the configuration wouldn't delete the
> key (because it is system created, and always exists), but
> regenerate-hidden-key should work to force the key to be regenerated if
> required.  The server persists the key outside of YANG configuration.
>
> The "install-hidden-key" action would allow a client to replace any
> server-allocated hidden key.
>
> Finally, if we are concerned about ease of use, then I would OK with a RPC
> being defined that performs an edit-config request to just add a named
> asymmetric-key of type server-allocated.  The RPC could also return the
> public key that has been generated by the server.  Note that this RPC isn't
> required, everything that can be done with the RPC can still be achieved
> through editing the configuration using edit-config, and reading the public
> key back with get-data, its only purpose to simplify a use case for
> clients, and perhaps to allow it to have different NACM permissions.
>
> Would a scheme like this work?  Or am I [still] missing something?
>
>
>
>
>
> I also like Juergen's approach.
>
>
>
>
>
>
>
> Thanks,
> Rob
>
>
>
>
>
> Andy
>
>
>
>
>
> >
> >
> > > I would support this less complete solution because it still supports
> > > basic configuration (#0) and manufacturer-generated keys for, e.g.,
> > > IDevID certificates (#1), and thus a passable go-to-market solution.
> > > If folks don't like the update per the previous paragraph, then this
> > > looks like a good fallback.
> >
> >
> > /martin
> >
> > _______________________________________________
> > netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>