Re: [Netconf] Mandatory local configuration in Keystore groupings

[Kent Watsen <[e-mail]>]

> Do we need to support the "local" or inline key configuration at all?

The two attached slides were presented at the IETF 102 meeting.

The ensuing discussion is captured in lines 279-312 here:
http://etherpad.tools.ietf.org:9000/p/notes-ietf-102-netconf.


> I would prefer to make the keystore model mandatory and remove the
> local cases from the client server models.  It seems better from a
> security pow to handle all keys in one place in the model, instead of
> having (possibly) private keys exposed in various places in the
> model.

I don't believe there is a security issue.  NACM or equivalent can
be used in either case.


> Also, the keystore has operations to generate new keys, which
> the local case doesn't have, so the local case also lacks some
> capabilities.

True, but the generate-private-key operation is really only 
intended to be used to direct an HSM (i.e. a TPM) to generate
a key.  

That said, the current action has no input parameter to direct 
the device to use an HSM or filesystem.  Perhaps there is a
need for a feature indicating the device has an HSM?


>  I think the model(s) will be less complex w/o the local
> case.  (At the very least, I think there should be a feature
> for the local cases, probably your case (2) below).

Yes, from the minutes, we want to add the feature "local-keys-supported".

BTW, I think that I misspoke before about it being a global on/off
switch (not per-use).  RFC 7950 says in Section 7.20.2:

   If a prefix is present on a feature name in the boolean expression,
   the prefixed name refers to a feature defined in the module that was
   imported with that prefix, or the local module if the prefix matches
   the local module's prefix.  Otherwise, a feature with the matching
   name MUST be defined in the current module or an included submodule.

So, if ietf-keystore.yang has this (note the "local-keys-supported"):

  grouping local-or-keystore-asymmetric-key-grouping {
    description
      "A grouping that expands to allow the key to be either stored
       locally within the using data model, or be a reference to an
       asymmetric key stored in the keystore.";
    choice local-or-keystore {
      mandatory true;
      if-feature "local-keys-supported";
      case local {
        uses asymmetric-key-pair-grouping;
      }
      case keystore {
        if-feature "keystore-implemented";
        leaf reference {
          type ks:asymmetric-key-ref;
          mandatory true;
          description
            "A reference to a value that exists in the keystore.";
        }
      }
      description
        "A choice between an inlined definition and a definition
         that exists in the keystore.";
    }
  }

and that grouping is used by the "ssh-server-grouping" in 
ietf-ssh-server.yang, which it is, and that grouping is used by the 
"netconf-server-grouping" in ietf-netconf-server.yang, which it is, 
and that grouping is used by some application-level module called 
"example-foo-bar.yang" that defines prefix "fb", then it seems that
maybe the foo-bar module could itself define a feature called 
"local-keys-supported" to control the underlying feature?


> I am looking at implementing the keystore model on a regular device
> for something like OpenSSH.  I don't want to expose the private keys
> at all.  I think this is possible, by not implementing ietf-keystore
> in the conventional configuration datastores, but only in
> <operational>.  New keys can still be generated with the action
> "generate-asymmetric-key".

Keystore can be implemented in both datastores.  Keys created by the
action are only present in <operational>.  The last sentence of
the action's description statement says this.


> Two questions:
>
>  1)  Is the enum "hardware-protected" really a good name in this
>      case?

As opposed to what?  In -02, this enum was called "INACCESSIBLE", 
and in -01 there was another enum called "RESTRICTED" with description
statement "The private key is restricted due to access-control".
  
We removed RESTRICTED because we said it was an access-control 
implementation thing as to how filtered-out nodes are represented 
(e.g., a dummy parameter or just missing).  And we changed 
INACCESSBLE to hardware-protected in an attempt to be more specific.

Reaching back in time, there was a thread where we discussed the 
need to support backup/restore workflows, and then a subsequent 
discussion about those keys needing to be editable outside a 
recovery session (Security Considerations on page 22). Thus, we
reasoned the only time the private key is truly not available is
when it's being shielded by something outside the control of the
system, which led us to "hardware".


>  2)  Wouldn't it make sense to add a new operation to install an
>      existing key into the keystore, with params "name", "algorithm",
>      "private-key", "public-key"?

Unsure what you mean.  Currently all these values are configurable.
Or are you trying to find a way to only "configure" them in 
<operational>?


> And a question about certificates.  Keys that are proteced by TPM are
> not present in the configuration, only in <operational>, right?  

Right.


> If so, how can I install a certificate for such a key?  Would it be
> better if the certificate list was separated from the key list?

The idea is to use the approach that was taken with the I2RS topology
model, using require-instance false.  Specifically, the 
"local-or-keystore-asymmetric-key-with-certs-grouping" has leaf 
"reference" of type "asymmetric-key-ref":

     typedef asymmetric-key-ref {
       type leafref {
         path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key"
              + "/ks:name";
         require-instance false;
       }
       description
         "This typedef enables modules to easily define a reference
          to an asymmetric key stored in the keystore. The require
          instance attribute is false to enable the referencing of
          asymmetric keys that exist only in <operational>.";
       reference
         "RFC 8342: Network Management Datastore Architecture (NMDA)";
     }

Makes sense?


Kent // contributor