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

[Kent Watsen <[e-mail]>]

> It is enough if just the name and "hidden" enum is present in
> factory-defaults, and thus just these fields are copied to running.

Maybe.  The public key and algorithm must be available somehow.  I know that you're pushing for them to be pulled from <operational>, which I'm okay with in theory, but in doing so you're implying that the 3-tuple values should not be mandatory true, which is a show stopper for me.  A possible compromise would be to let the algorithm and public-key nodes also take values like <hidden-value/>.  But I feel even this is unnecessary, as explained next.

You seem to worry about special case handling, but then how to you propose the device defend against the client setting a completely different set of new/different 3-tuple values for the tpm-protected-key?  My view is that the device will detect that the key is a system-configured and (unlike other NMDA scenarios) must not let configuration overwrite it.  That sounds like special handing to me and my view is, if a device can do that, then it can also detect/prevent modification to any of the three values, hence why I feel there is not need to hide or shroud the algorithm and public-key values in the configuration.




>> Now, when this configuration from the first device is loaded onto the
>> second device, one of two things might happen:
>> 
>>  1) if the manufacturer gives the same name to each device's
>>  TPM-protected keys (i.e., <name>tpm-protected-key</name>)
>> 
>>      a) <running> (copied from <factory-default>), would contain a key
>>      having the 'key' value as the incoming key.
>>      b) this should fail, because it's not possible to change the
>>      <public-key> for a key having <hidden-private-key/>.
> 
> This would be special treatment.  And IMO it is not needed; if the
> public key and alg are not present in the config this is not an
> issue.

Even if the public key and alg fields are removed, it merge attempt would still fail, specifically, device B would fail to decrypt the operator-protected-key encrypted by device A.



>>  2) if the manufacturer gives unique names to the tpm-protected-keys
>>  (i.e., <name>key3124235234</name>)
>> 
>>      a) <running> (copied from <factory-default>), would NOT contain a key
>>      having the 'key' value as the incoming key.
>>      b) this should fail, because it's not possible to config a new key
>>      having <hidden-private-key/>.
> 
> For this use case I think it is a prerequisite that the key has the
> same name.

Why?  I don't know of a technical reason.   Maybe you mean to simplify installation guides, but there are likely not-too-complicated ways to deal with that.  Regardless, the same failure mentioned previously (that device B would fail to decrypt the operator-protected-key encrypted by device A) would be present.



>> The specific failure error isn't as interesting as knowing that it
>> will fail somehow, and implementations will need to handle the
>> possibility.
>> 
>> That said, the general recommendation, which would both be correct and
>> avoid any potential failures, would be for the client to remove the
>> device-specific and operator-wide keys first, leaving just the
>> migratable keys in the config uploaded to the second device.
> 
> THIS IS THE CONFIG FROM THE FIRST DEVICE (A)
> 
> <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
>    <asymmetric-keys>
> 
>        <!-- a device-unique asymmetric key -->
>        <asymmetric-key>
>            <name>tpm-protected-key</name>
>            <hidden-private-key/>
>        </asymmetric-key>
> 
>        <!-- operator-wide symmetric key, protected by the device-specific key
>        -->
>        <!-- this key must be created for each device (i.e., via step #3) -->
>        <symmetric-key>
>            <name>operator-protected-key</name>
>            <algorithm>aes-256-cbc</algorithm>
>            <encrypted-key>
>                <asymmetric-key>tpm-protected-key</asymmetric-key>
>                <value>base64encodedvalue-1==</value>
>            </encrypted-private-key>
>        </symmetric-key>
> 
>        <!-- a migratable key, protected by the operator-wide key -->
>        <asymmetric-key>
>            <name>ex-encrypted-key</name>
>            <algorithm>rsa2048</algorithm>
>            <public-key>base64encodedvalue-2==</public-key>
>            <encrypted-private-key>
>                <symmetric-key>operator-protected-key</symmetric-key>
>                <value>base64encodedvalue-3==</value>
>            </encrypted-private-key>
>        </asymmetric-key>
> 
>    </asymmetric-keys>
> </keystore>
> 
> 
> THIS IS THE CONFIG ON A SECOND DEVICE, AFTER STEP #3 (B)
> 
> <keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
>    <asymmetric-keys>
> 
>        <!-- a device-unique asymmetric key -->
>        <asymmetric-key>
>            <name>tpm-protected-key</name>
>            <hidden-private-key/>
>        </asymmetric-key>
> 
>        <!-- operator-wide symmetric key, protected by the device-specific key
>        -->
>        <!-- this key must be created for each device (i.e., via step #3) -->
>        <symmetric-key>
>            <name>operator-protected-key</name>
>            <algorithm>aes-256-cbc</algorithm>
>            <encrypted-private-key>
>                <asymmetric-key>tpm-protected-key</asymmetric-key>
>                <value>base64encodedvalue-4==</value>
>            </encrypted-private-key>
>        </symmetric-key>
> 
>    </asymmetric-keys>
> </keystore>
> 
> 
> If we edit-config (A) into (B), we'll trash "operator-protected-key";
> specifically its "encrypted-private-key/value" leaf must not be
> changed.
> 
> If we remove "operator-protected-key" from (A) we can then merge the
> rest of (A) into (B).
> 
> So this requires the client to pacth the config a bit.  Perhaps this
> is ok.

Okay, we agree that the client should patch the config from device A  prior to merging it into device B.   You feel that just the operator-protected-key can be removed, while I feel that both the tpm-protected-key and operator-protected-key keys should be removed.  My preference for removing both is because is mimics normal configuration updates occurring throughout the device's life.  That is, the CRUD operations would always be on the "ex-encrypted-key" keys, so just having these keys in the configuration loaded from device A would be consistent.



Kent // configuration