Re: [Netconf] Mandatory local configuration in Keystore groupings

[Martin Bjorklund <[e-mail]>]

Hi,

I have started to look at implementing the client/server/keystore
modules, specifically the SSH server model for NETCONF.  In this
process, I have some comments on the model.

Do we need to support the "local" or inline key configuration at all?
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.  Also, the keystore has operations to generate new keys, which
the local case doesn't have, so the local case also lacks some
capabilities.  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).

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".  Two questions:

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

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


And a question about certificates.  Keys that are proteced by TPM are
not present in the configuration, only in <operational>, 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?



/martin


Kent Watsen <[e-mail]> wrote:
> Hi Balazs,
> 
> This issue is (was?) also being discussed here:
> https://mailarchive.ietf.org/arch/msg/netconf/tpmAeH9KLBWF0YglZ8CJmm4MW4o.
> 
> Expanding on (c) on that page, assuming we do this at all, the choices
> are:
> 
>   1: add "if-defined 'not keystore-implemented'" to the "local" choice.
>   This would
>        be a *global* on/off switch, not per use of the grouping.
> 
>   2: add "if-defined 'local-keys-supported'" to the "local" choice.
>   This would be a
>        *global* on/off switch, not per use of the grouping.
> 
>   3: do nothing; let downstream modules augment-in their own if-feature
>   statements
>       for the "choice" statement when the groupings are used.  This would
>       allow define
>        for *local* (not global) on/off switch.
> 
>   4. remove support for keystore being optional to implement.  That is,
>   regarding your
>       comment in the link below to support keys that are not shared, we
>       could require
>        that the keys still exist in keystore and leave it to the application
>        to ensure it doesn't
>        reference such keys more than once.
> 
>       https://mailarchive.ietf.org/arch/msg/netconf/xYYf0NSeT9mgtJ1KH-h7SYLSmXA
> 
> Thoughts?
> 
> Kent
> 
> 
> On 7/4/18, 7:26 AM, "Netconf on behalf of Balazs Lengyel"
> <[e-mail]<mailto:[e-mail]> on behalf
> of [e-mail]<mailto:[e-mail]>>
> wrote:
> 
> 
> Hello Kent,
> I was reading draft-ietf-netconf-keystore-05. I noticed that in the
> groupings
> local-or-keystore-end-entity-certificate-grouping,
> local-or-keystore-asymmetric-key-grouping and
> local-or-keystore-asymmetric-key-with-certs-grouping
> the keystore case is qualified with an
> if-feature "keystore-implemented"
> statement. However the local case is not qualified with if-feature. In
> ,many of our network nodes we want to implement a central keystore,
> and do NOT want to allow local security configuration. So please add
> if-feature "not keystore-implemented"
> or
> if-feature "local-keystore-allowed"
> to the local case of these groupings.
> 
> regards Balazs Lengyel
> 
> --
> 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> 
> Senior Specialist
> 
> Mobile: [phone] email:
> [e-mail]<mailto:[e-mail]>