Re: [Netconf] Mandatory local configuration in Keystore groupings

[Martin Bjorklund <[e-mail]>]

Hi,

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

[...]

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

I think that special actions/rpc that modify config should be avoided
in probably all cases.  The text in 8342 handles generic rpcs like
"edit-data" etc.

*if* you design an action to modify config, it needs to take at least
the datastore as an input parameter.

In this particular case, I see no reason to have a special action to
modify the configuration of keys.


/martin




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