Re: [Netconf] Mandatory local configuration in Keystore groupings

[Balázs Kovács <[e-mail]>]

Hi,

> >> >> 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>.
> >> 
> >> Hmmm, sounds like *configuration*, not something goes into <operational>.
> >> 
> >> And, even if you did, that doesn't mean the keys are permanently-hidden.
> >> I suppose the model could let the client set that parameter as 
> >> well, but it somewhat defeats to goal of *never* having the private 
> >> key exposed, not even as a once in a lifetime kind of thing.
> >> That’s just my opinion, we should ask for more opinions if you're not convinced.
> >
> > I'm not convinced either way, actually ;-)  It would be good to hear 
> > other opinions as well.
> 
> We could define a "load-asymmetric-key" action that has that behavior?

Yes; if we decide to support this use case.  What do others think?

Balazs> Would this action have 'name' and 'private-key' binary input and the purpose to avoid setting the key via configuration and handling it directly in <operational>? Is it an implementation risk to handle the binary input via configuration but not via action?

> > This is what I would expect as well, but the model is not quite 
> > designed for this currently.  For example, suppose I generate a 
> > HSM-protected key with "generate-asymmetric-key".  It is then 
> > present in <operational>, with a public key etc.  Now I want to 
> > configure a certification for this key, so I have to create an entry 
> > in the "asymmetric-key" list, where I have to set both the 
> > private-key and public-key leafs (they are both mandatory); so I 
> > assume I have to use the exact values reported in <operational>?
> 
> Hmmm, using the same value could work, but it doesn't seem intuitive 
> and, from a general modelling perspective, doesn't scale e.g., what if 
> there were 100 descendants?

Exactly my point.

Balazs> In our opinion with Balazs L., we think it would be disadvantageous to change the model by ruining the containment relationship between certificate and corresponding asymmetric key. The action of 'generate-asymmetric-key' is typically something that should have effect on the 'running' configuration too (by setting the mandatory leaves) since the user wants to continue working with the result by deploying certificates or anything else related to the created asymmetric key that needs configuration. 

Balazs L.> In the NMDA RFC it is specifically indicated that actions/rpcs MAY modify the content of other datastores.
https://tools.ietf.org/html/rfc8342#section-6.2
In my view this is a general pattern that an action/rpc creates some configuration that the operator (CLI/Netconf/Restconf) may need to extend or change. In this case the action/rpc shall modify the running config not just operational.

Br,
Balazs K. and Balazs L.

-----Original Message-----
From: Netconf <[e-mail]> On Behalf Of Martin Bjorklund
Sent: Tuesday, August 28, 2018 9:07 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings

Kent Watsen <[e-mail]> wrote:
> 
>  
> > > BTW, all private keys should have nacm:default-deny-all.
> 
> Updated in my local copy.  Added to the "asymmetric-key-pair-grouping"
> grouping, so all downstream users inherit it as well.
> 
> 
> 
> > I think that the operation "generate-asymmetric-key" only affects 
> > "permanently-hidden" keys, doesn't it?  If the client wants visible 
> > keys, it will configure them in the config datastores.
> 
> It wasn't so locked down before.  How about the following two changes?
> 
> 1. Updated the action's description statement:
> 
>       action generate-asymmetric-key {
>         description
>           "Requests the device to generate an asymmetric key using
>            the specified asymmetric key algorithm.  This action is
>            used to request the system the generate a key that is
>            'permanently-hidden', perhaps because it is protected
>            by a cryptographic hardware module.  The resulting
>            asymmetric key is considered operational state and
>            hence present only in <operational>.";
> 
> 2. updated the enum's description statement:
> 
>           enum "permanently-hidden" {
>             description
>              "The private key is inaccessible due to being
>               protected by the system (e.g., a cryptographic
>               hardware module).  It is not possible to 
>               configure a permanently hidden key, as a real
>               private key value must be set.  Permanently
>               hidden keys cannot be archived or backed up.";
>           }   

Ok.

> > > Regarding the name, s/hardware-protected/permanently-hidden/?
> >
> > I think this is better.
> 
> Okay, but maybe it should be just "hidden"?

Both work for me.

> >> Now you have me second-guessing this.  Maybe a device, without 
> >> special hardware, could present the illusion of a 
> >> permanently-hidden private key - it's completely inaccessible from 
> >> the device's supported interfaces, though actually present on the filesystem.
> >
> > This is what I would like to support.
> 
> Okay.
> 
> 
> 
> >> >> 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>.
> >> 
> >> Hmmm, sounds like *configuration*, not something goes into <operational>.
> >> 
> >> And, even if you did, that doesn't mean the keys are permanently-hidden.
> >> I suppose the model could let the client set that parameter as 
> >> well, but it somewhat defeats to goal of *never* having the private 
> >> key exposed, not even as a once in a lifetime kind of thing.  
> >> That’s just my opinion, we should ask for more opinions if you're not convinced.
> >
> > I'm not convinced either way, actually ;-)  It would be good to hear 
> > other opinions as well.
> 
> We could define a "load-asymmetric-key" action that has that behavior?

Yes; if we decide to support this use case.  What do others think?

> > This is what I would expect as well, but the model is not quite 
> > designed for this currently.  For example, suppose I generate a 
> > HSM-protected key with "generate-asymmetric-key".  It is then 
> > present in <operational>, with a public key etc.  Now I want to 
> > configure a certification for this key, so I have to create an entry 
> > in the "asymmetric-key" list, where I have to set both the 
> > private-key and public-key leafs (they are both mandatory); so I 
> > assume I have to use the exact values reported in <operational>?
> 
> Hmmm, using the same value could work, but it doesn't seem intuitive 
> and, from a general modelling perspective, doesn't scale e.g., what if 
> there were 100 descendants?

Exactly my point.

> A couple other options:
> 
>  a) make each leaf (algorithm, public-key, private-key) type be a
>     union having an enumerated value like "in-operational"

This feels clumsy and also doesn't really scale.

>  b) replace the three "mandatory true" with three "must" expressions
>     that assert either all or none of the leafs are set.

Better, but also has scaling issues in the general case.


> > Another design could be to have the certificates in a separate list, 
> > with leafrefs (require-instance false) into the "asymmetric-key"
> > list.
> 
> Perhaps, but let's see if we can make this work first.

Ok, let's look at the alternatives:

(A)

  container keystore {
    container asymmetric-keys {
      list asymmetric-key {
        key name;

        leaf name { ... }
        leaf algorithm { ... }
        leaf public-key { ... }
        leaf private-key { ... }

        must "(algorithm and public-key and private-key)
              or not (algorithm or public-key or private-key)";

        container certificates {
          list certificate { ... }
        }
    }
  }


(B)

  container keystore {
    container asymmetric-keys {
      list asymmetric-key {
        key name;

        leaf name { ... }
        leaf algorithm { mandatory true; ... }
        leaf public-key { mandatory true; ... }
        leaf private-key { mandatory true; ... }

    }

    container certificates {
      list certificate {
        ...
        leaf key {
          leafref {
            path "../../../asymmetric-keys/asymmetric-key/name";
          }
          require-instance false;
          mandatory true;
        }
        ...
      }
    }
  }


I think model B is cleaner.




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