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

[Kent Watsen <[e-mail]>]

Picking up where we left off, we discussed making 'private-key' configurable, as shown below, protected by nacm:default-deny-all.  This, in lieu of having an action statement called 'generate-private-key', which is the crux of the issue described in the subject line.

    +--rw keystore
       +--rw keys
          +--rw key* [name]
             +--rw name                            string
             +--rw private-key?                    binary
             +--ro algorithm?                      identityref
             +--ro key-length?                     uint32
             +--ro public-key                      binary
             +--rw certificates
                +--rw certificate* [name]
                   +--rw name     string
                   +--rw value?   binary

This resolves one issue, but then raises another, which is how to fully support system-generated keys, such as a key created by a TPM, that need to have certificates configured for them, such as IDevID or an LDevID certificates from IEEE 802.1AR.

Again, while we now know to use the operational state datastore to represent system-generated values, the problem becomes how to *configure* certificates for these system-generated keys, specifically the IDevID and LDevID certificates.  

But, as seen in the tree-diagram above, this is not a leafref problem, which might be solved using a solution like the one proposed for the I2RS topo model, where a require-instance false leafref in the running datastore *can* point to a node in the operational state datastore.  No, here the 'certificate' nodes are descendants of the 'key' node, so the leafref solution doesn't apply.

I don't have any good ideas for how to address this issue. Does anyone have any thoughts on how we should handle it?

[ref: https://github.com/netconf-wg/keystore/issues/2]

Thanks,
Kent



-----ORIGINAL MESSAGE-----
Hi Martin,

I’ve been trying to make sense of your suggestion, but nothing fits.   The only thing that makes sense to me is to make “private-key” config true, so it’s generally configurable, for round-tripping.  Then, to handle TPM-protected keys, we use something from the opstate solution, as the TPM-protected keys could be construed as “system generated”, at least the DevID private-key (the only TPM-protected key that I care about) could be seen that way.

But this doesn’t solve the whole problem.  While the IDevID cert could also be “system generated”, the LDevID cert is not, and config true in intended can’t point to config true in applied.   Maybe we hide/overlook this by claiming that setting an LDevID certificate is out-of-scope to the model, what do you think?

Kent



On 5/30/16, 4:26 AM, "Martin Bjorklund" <[e-mail]> wrote:

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



_______________________________________________
Netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf