Re: [netconf] latest update to crypto-types and keystore drafts

[Kent Watsen <[e-mail]>]

>> 2) privileged admin copies manufacturer generated key from
>> <operational> to <running>
> 
> The device could also store this key (or rather just the name) in its
> factory configuration.

Sure, but only if it's immutable.  To be clear, users are not able to delete the manufacturer generated key(s), at least not those use to support the device's cryptographic identity.  This is true even when wiping the device for sale...


> I don't think the public key and alg needs to go into the config.

> Or in general, if the key is configured as hidden, I think it should
> NOT have a public key and alg in the config (can be ensured with
> "must").  However, they must be present in the operational state.

Okay, but in thinking about going down that route, I'd rather use a special enum/union type values to denote the absence of these fields than to mark the nodes mandatory false.  Personally, I think it's better to duplicate the values into configuration as it does no harm and it makes them easier and more consistent to work with (e.g., clients need the public key in order to encrypt data destined to the device).  Really, I don't want any keys in <operational>, but feel that we have to make an exception for the manufacturer-generated keys (unless, to your comment above, we could mark them as immutable in the configuration).  [PS: in a previous life, I used per instance metadata when a node was immutable.]



>> 3) privileged admin encrypts a well-known (secret to the organization)
>> symmetric key using the public key from the manufacturer generated
>> asymmetric key, and stores the result (i.e., <edit-config> into
>> keystore.
> 
> Ok.  However, if the device doesn't have a hidden
> manufacturer-supplied key from step 1 (no tpm), it would be useful if
> the admin could install this symmetric key so that it becomes hidden.
> But that action is no longer present in the model.

True, but it seems strange that a device would have the ability to store hidden keys without itself being shipped with a hidden key.  We could add a set of RPCs to manage the life-cycle of hidden keys, but I'd rather steer folks to using NACM in such cases, as I don't think it makes sense to either have 1) persistent user-created operational state or 2) persistent configuration that isn't configuration.



> Or does this model *require* the device to have such a key?  If no tpm
> exists, then it can exist on disk?

Not required.  For devices that don't have hidden keys, plain old NACM could protect the encryption-key used to protect all the other keys in the configuration.  The primary benefit would still be present, that keys subsequently generated by the device would be protected by the encryption key.  The downside would be that the encryption key itself, when generated, could not be protected in the same way.  For such situations, it would be recommended that this key be installed from a known-safe connection (i.e., via an air-gapped system).



>> 4) if replacing a device, load previous configuration.  Since all keys
>> should be encrypted to the same symmetric key, it should load without
>> error.
> 
> Before loading the previous config, the admin must do steps 2-3 on the
> new device, right?

Correct.  To be more clear, all steps except (4) would occur on a first device and then, when an RMA is necessary, steps (1-3) would occur on a second device, following by step (4) to migrate the configuration from the first device to the second device, and then the remaining steps (5+) would be business as usual on the second device.



>> [note: one issue here with the secret symmetric key itself
>> being loaded again, but since it was encrypted using to old device's
>> manufacturer generated asymmetric key, the logic should be able to
>> handle it.]
> 
> Hmm, can you elaborate?  It seems to me to be a problem; it needs to
> be re-installed so that it is encrypted with the new device's public
> key.

What is meant is that the symmetric key would be created once on the second device, in step (3), but because the old encrypted symmetric key was stored in configuration (on the first device), when loading the configuration here in step (4), it is as if the symmetric key is being created again on the second device.  But the logic on the second device should be able to detect this anomaly (because the key would've been encrypted by the first device's private key, and hence decryption should fail on the second device) and thus the "duplicate" symmetric key would be discarded.



> 
>> Runtime:
>> 5) whenever a regular admin wishes to use a new key, they call the
>> generate-symmetric-key or generate-asymmetric-key RPC, requesting the
>> device to generate a key for them, encrypting the result using the
>> secret organization key.
>> 6) The RPC output returns the key value (encrypted).
>> 7) The regular admin uses e.g., <edit-config> to store the key into
>> <running>.
>> 
>> 
>> Use cases: 
>>  0: normal (just NACM-protected) keys:  supported.
>>  1: manufacturer-generated permanently hidden keys: supported.
>>  2: device-generated keys: supported.
>>  3: device-generated keys in config: supported
>>  4: permanently hidden keys: not recommended nor directly
>>     supported, but one could always encrypt a key with the
>>     device's public key, thus generating a key that only the
>>     device can decrypt, and hence effectively permenently
>>     hidden.
>> 
>> 
>> Please let me know soon if you object to any aspect of this or,
>> better, support it, as I need to update the remaining drafts to
>> reflect these changes at some point soon.
> 
> Also, if we go this route, this draft (keystore) needs more text, and
> also explain the use cases described above.

Agreed.   I also never documented the "generate-symmetric-key" and "generate-asymmetric-key" RPCs...

Regarding "going this route", your response thus far seems to be on the level so, would it be fair to say that you're leaning towards thinking that it might be okay?



> Then there are some details, e.g. why do we have 
> 
>    identity asymmetric-key-algorithm {
>      description
>        "Base identity from which all asymmetric key
>         encryption Algorithm.";
>    }
> 
> vs
> 
>    identity encryption-algorithm {
>      description
>        "A base identity for encryption algorithm.";
>    }
> 
> Why isn't the latter called "symmetric-key-algorithm"?


These identities (now enumerations) are coming from the crypto-types module in a section maintained by my co-author from Huawei who has even more crypto-clue than I.   My guess is that this is what they're called in IANA registries for historical reasons.


> /martin

Kent // contributor