Re: [Netconf] Mandatory local configuration in Keystore groupings

[Martin Bjorklund <[e-mail]>]

Hi,

Kent Watsen <[e-mail]> wrote:
> 
> 
> 
> > 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.

Yes, but it may be desirable to keep all keys in a single place,
instead of scattered around.  But I'm ok with using a feature.

BTW, all private keys should have nacm:default-deny-all.


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

Editorial issue: the draft uses both names "generate-private-key" and
"generate-asymmetric-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 that this is an implementation choice that doesn't have to be
visible to the operator.  I.e., if there's special hw it will be used,
else a filesystem (or something else) will be used.

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

Ok.

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

No, this won't work.  Note the text you quoted:

     Otherwise [no prefix], a feature with the matching
     name MUST be defined in the current module or an included submodule.

the current module is the module that has the if-feature statement,
i.e., ietf-keystore.


But I think a global feature is fine.  Models can always add their own
additional if-fetaure expressions via refinement.


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

Of course.

> Keys created by the
> action are only present in <operational>.  The last sentence of
> the action's description statement says this.

Exactly.

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

In my use case I would implement "generate-asymmetric-key" and it
would create the keys in the file system, and the public key would be
available in <operational>.  I don't want to expose the private key in
<operational>, so I would have to return "hardware-protected".  But it
isn't hardware protected...

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

I think this is the real issue.  So it might be that my use case of
not wanting to expose private keys at all even if there's no TPM is
explicitly not supported.  I.e., unless there's special hw present,
all private keys MUST be exposed (but NACM-protected).

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

Yes, *if* my use case of not exposing the private keys is supported,
then it would be useful to be able to generate the keys off-box, and
install them into <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?

Isn't the idea that once I have a certificate, I will write it into
/keystore/asymmetric-keys/asymmetric-key/certificates/certificate?

My question is how this is supposed to work for a hardware-protected
key that only exists in <operational>?


/martin