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

[Kent Watsen <[e-mail]>]

Hi Martin,

>>>> 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.
> 
> No I disagree.  If an admin can create it, it could be part of the
> factory default config, for convenience.  A user with the right access
> can delete it from the config, just as if it had been created by an
> admin.

Based on your later comments, it seems that we're more in agreement than not.  Let me rephrase, if the manufacturer generated keys (with 'hidden-key' or 'hidden-private-key') are stored in the factory default datastore, per draft-ietf-netmod-factory-default, they would be read-only and hence immutable.  Now, upon that configuration being copied into <running>, the configuration would become editable and said keys could be removed.



>>> 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
> 
> I think it makes them more difficult to work with.  Why should I be
> able to modify the public key of a hw-stored key?  It is just error
> prone.

Assuming that the manufacturer generated keys are in <factory-default> then, when copied to <running>, they have identical values as they were in <factory-default> (i.e., all three fields are present)



>> (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>
> 
> If you need the public key why is it a problem to read it from
> <operational>?

It's not, but my comment was about keys as a whole (not the key's inner values).  The <factory-default> approach is nice because it normalizes all key access to one approach (intended configuration).



>>>> 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.
> 
> Hasn't the previous discussion shown that it is quite common to store
> keys separate from the normal config?

My assertion is that any device that has the ability to install "hidden" keys surely would ship with preconfigured hidden keys that could subsequently be used by admins to encrypt any keys they create later, hence negating the need for the device to support a feature to install hidden keys.


> I like the new design of this module, where all keys (but one!) are
> stored encrypted.  But that one key needs to be as protected as
> possible.

Agreed.



>> We
>> could add a set of RPCs to manage the life-cycle of hidden keys
> 
> Or perhaps state that the management of such keys are out of scope
> (for now)?

This is my preference.  In particular, the current model defines the ability for keys to be hidden, and specifically says "How such keys are created is outside the scope of this module."  It is my hope/intention to not define any module defining an ability to create/install hidden keys, thus restricting their creation to manufacturing-time magic and vendor-specific modules defining proprietary RPCs.



>>> 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.
> 
> I think this benefit goes away if the encryption key itself it present
> in clear text in the config.  In this case we could as well use NACM
> to protect *all* keys.

Yes and no.  Yes, in the sense that NACM is the ultimate protection mechanism but, no, in the sense that this fails to have value.  Specifically, regular admins can still ask the device to generate a key, encrypted by another key that they don't have access to.  Similarly, regular admins can operate in (copy/paste/reference) encrypted keys without ever being able to access the secret data.

FWIW, in JUNOS, the DDL/YANG modeling language has a special "secret data" annotation that switches on logic to encrypt said data at-rest and over-the-wire for all except users in the "super-user" class.  JUNOS users are typically configured in the "operator" class, and sometimes in the "read-only" class.  This is effectively the NACM model we're discussing here, and it's been shipping for a long time.



>> 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).
> 
> Perhaps this is the "out-of-scope" that I mentioned above?

No, this part would be best practice. That is, if one must handle private keys in the clear, at least be sure to do so via a secure system and via a secure network.



>> 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.
> 
> Hmm, I still don't see how this is supposed to work.  Are you
> suggesting special treatment for this list entry by the edit-config /
> copy-config operations?  I strongly object to such a hack, but perhaps
> you meant something else?

I'm unsure if I'd call it special treatment, so much as logical outcome - see below.


THIS IS THE CONFIG FROM THE FIRST DEVICE

<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
    <asymmetric-keys>

        <!-- a device-unique asymmetric key -->
        <asymmetric-key>
            <name>tpm-protected-key</name>      <----  name value may differ
            <algorithm>rsa2048</algorithm>
            <public-key>base64encodedvalue==</public-key>
            <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>
            <public-key>base64encodedvalue==</public-key>
            <encrypted-private-key>
                <asymmetric-key-ref>tpm-protected-key</asymmetric-key-ref>
                <value>base64encodedvalue==</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==</public-key>
            <encrypted-private-key>
                <symmetric-key-ref>operator-protected-key</symmetric-key-ref>
                <value>base64encodedvalue==</value>
            </encrypted-private-key>
        </asymmetric-key>

    </asymmetric-keys>
</keystore>


THIS IS THE CONFIG ON A SECOND DEVICE, AFTER STEP #3

<keystore xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
    <asymmetric-keys>

        <!-- a device-unique asymmetric key -->
        <asymmetric-key>
            <name>tpm-protected-key</name>      <---- name value may differ
            <algorithm>rsa2048</algorithm>
            <public-key>base64encodedvalue==</public-key>
            <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>
            <public-key>base64encodedvalue==</public-key>
            <encrypted-private-key>
                <asymmetric-key-ref>tpm-protected-key</asymmetric-key-ref>
                <value>base64encodedvalue==</value>
            </encrypted-private-key>
        </symmetric-key>

    </asymmetric-keys>
</keystore>


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

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

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.




>> 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.
> 
> Ok, but you agree that "symmetric-key-algorithm" would be better,
> unless there's some strong historical reason for keeping
> "encryption-algorithm"?

Yes, I agree, it would be best if it were called a symmetric key, as even asymmetric keys can do encryption.



Kent // contributor