Re: [netconf] updates to client/server drafts

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

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?


> 
> > 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?

Thanks,
Rob



> 
> 
> > 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