Re: [Netconf] Mandatory local configuration in Keystore groupings

[Kent Watsen <[e-mail]>]

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

Yes, let's go with the feature.  I've added it to my local copy.

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

I'd agree if we were only talking about backup/restore operations, 
which match the definition of a "recovery session", but here we're
trying to support workflows that would occur during normal operation
of the device, by administrators having sufficient permission.  The
Security Considerations section provides guidance on this too.



> Editorial issue: the draft uses both names "generate-private-key" and
> "generate-asymmetric-key".

fixed.


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

No, what I meant was that generate-asymmetric-key could take an
input parameter (enum?), protected by a feature, that the client
could use to indicate the key needs to be permanently hidden, or
define the entire RPC to have that behavior?

Regarding the name, s/hardware-protected/permanently-hidden/?


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

okay.  I was hoping that is could be the module using the grouping.


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

True.



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

Would "permanently-hidden" be better?


> <snip/>
> 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).

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.


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


>> 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":
>>
>> <snip/>
>> 
>> 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>?

Sorry, I think my example was wrong.  A better example might be the
interfaces example in Section C.3.2 in RFC 8342 [1], where the
configs overlay each other (e.g., matching keys).

For a hardware-protected key, the "asymmetric-key" (in keystore) still
appears in <operational> with an exposed "key" name, the "private-key"
value is set to "hardware-protected".  So the thinking is that a similar
path can be constructed in <intended>, while only adding/configuring the
certificates.

Actually, check out the example in keystore-05 at the end of page 7:

       <asymmetric-key or:origin="or:system">           <--- system generated
         <name>tpm-protected-key</name>
         <algorithm>ct:rsa2048</algorithm>
         <private-key>hardware-protected</private-key>  <--- hw protected
         <public-key>base64encodedvalue==</public-key>
         <certificates>
           <certificate>
             <name>builtin-idevid-cert</name>
             <cert>base64encodedvalue==</cert>
           </certificate>
           <certificate or:origin="or:intended">        <--- configured cert
             <name>my-ldevid-cert</name>
             <cert>base64encodedvalue==</cert>
           </certificate>
         </certificates>
       </asymmetric-key>



Kent // contributor