Re: [Netconf] Semi-configurable design in server model draft

[Martin Bjorklund <[e-mail]>]

Mahesh Jethanandani <[e-mail]> wrote:
> [Chair hat off]
> 
> > On May 27, 2016, at 10:31 AM, Kent Watsen <[e-mail]> wrote:
> > 
> > It should be noted that the following exchange happened on Apr 7th:
> >  
> > <kent>
> > Yes, the action statements are intended to update the running
> > datastore.  Presumably because the actions are either generating or
> > loading a new key, there would not be a real world locking issue, but
> > I can see how this might lead to undesirable results.  Access control
> > (NACM) was removed when we moved to the keychain based approach, but
> > presumably the private key would need to protected by
> > nacm:default-deny-all.
> >  
> > I see what you're saying.  You're right about this breaking backup and
> > restore.  The only way to fix it is for the backup (<get-config>) to
> > contain the private keys.  But note that systems using a TPM actually
> > have NO WAY to get the private key out of the TPM - only the TPM
> > itself has access to the private key.  So for these systems,
> > backup/restore (RMA) is impossible, even with root-level access on the
> > command line.
> >  
> > I'm not sure if I understand your first option.  Do you mean the
> > client would create a dummy private key entry (a placeholder) and then
> > call an action to populate the key with data?
> > </kent>
> >  
> > <martin>
> > Yes, but since the private key is not part of the config, the action
> > will not touch the running config.
> > </martin>
> >  
> > <kent>
> > I don't think the private keys can be config false, since they are
> > referenced by config true nodes in the tls/ssh-server modules.
> > </kent>
> >  
> > <martin>
> > You can have a require-instance false leafref to the config false of
> > keys, and then describe what will happen if some server is configured
> > to point to a private key that doesn't exist.
> >  
> > There are systems with tamper-proof hw that won't allow you to access
> > the keys unless a physical token is present (e.g. a USB stick).  In
> > such systems, you may very well end up with config that refers to a
> > key that isn't available.
> >  
> > Question 1:  If the private key is not stored in special HW, do we
> >   want to support backup/restore of such keys?
> >  
> >   If the answer is yes:
> >       Use a config list and a separate -state list.
> >       Make all references point to the -state list (in order to handle
> >       TPM etc)
> >  
> >   If the answer is no:
> >       Use only a config false list and define actions to manipulate
> >       the list.
> > </martin>
> >  
> >  
> > Regarding Martin’s question #1 (note: there wasn’t a question #2), I
> > think that the answer is “yes, we’d like to support backup/restore of
> > private keys”.  Is this the WG’s opinion as well?
> 
> My personal opinion is yes also. But I am a little confused here. If
> TPM does not allow for keys to be exported, what would be reflected in
> the -state list?

The -state list would contain just the name of the key; not the key
itself.

> And if a config true node refers to this config false
> node, what are we “describing” that will happen? Is there a when
> statement?

For example, if the intended config of the NETCONF server contains a
reference to a key that doesn't exist in -state, for example b/c the
special hw couldn't be accessed, then the NETCONF server wouldn't be
started.  If we have some "oper-status" leaf for the NETCONF server,
it could indicate the reason that the server wasn't started
("missing-key" or something).


/martin




> 
> >  
> >  
> > Thanks,
> > Kent
> >  
> >  
> > From: Netconf <[e-mail]> on behalf of Mahesh
> > Jethanandani <[e-mail]>
> > Date: Thursday, May 26, 2016 at 8:06 PM
> > To: "[e-mail]" <[e-mail]>
> > Subject: [Netconf] Semi-configurable design in server model draft
> >  
> > One of the issues that Kent brought up in the interim meeting was the
> > issue of configuring the private key. Some background on that issue
> > dates back to the thread that started with Martin reviewing the
> > document and here is what he brought up in that review.
> >  
> > o  Section 4.1
> >  
> >   I think the "semi-configurable" design has some issues.  You have
> >   defined some actions that actually modifies the configuration of the
> >   system.  It is not clear which config datastore is modified.
> >   Presumably running.  Interactions with locking and access control
> >   are not described.  Also, the resulting configuration is not
> >   complete - i.e., you cannot do <copy-config> to save/restore a
> >   backup.  This is fine, since you really don't want to expose the
> >   private keys in the config backup.  But some discussion is needed
> >   around this subject.  What happens if I generate a private key with
> >   your action, backup that config and then restore it?  What happens
> >   with config that has references to such a key?
> >  
> >   One way to avoid that the actions modify the configuration could be
> >   to move them into the private-key list.  One drawback is that two
> >   operations are needed in order to create a (usable) key - first
> >   create the config in running, then call the action.
> >  
> >   Another option might be to model the keys as config false data.
> >   This also solves the problem that some keys (in TPM for example)
> >   are not deletable.
> > The two suggestions that Kent brought to the meeting on whether to
> > make it a leaf or an action.
> >  
> > Leafs can be backed up or restored. But private-keys in TPM never
> > leave the source. How do we support special hardware like TPM?
> >  
> > Making it an action requires creation of a dummy private key, and then
> > call action to populate the data in it, as Martin states above. What
> > happens if the key is not available but is referenced by the system?
> >  
> > Kent, is that a fair summary of the issue?
> >  
> > Let the discussion begin :-)
> >  
> > Mahesh Jethanandani
> > [e-mail] <mailto:[e-mail]>
> >  
> >  
> >  
> 
> Mahesh Jethanandani
> [e-mail]
> 
> 
> 
> 
>