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

[Kent Watsen <[e-mail]>]

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?


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