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

[Martin Bjorklund <[e-mail]>]

Hi,

Kent Watsen <[e-mail]> wrote:
> 
> I started off trying to create a variation of "#2" but, as got into
> it, I realized that *encrypting* the keys would solve most problems.
> Note that we really don't want "hidden" keys at all, as them not being
> part of configuration causes backup/restore problems.  What we want
> are values that can be treated like config, but are non-sensical
> without the decryption key.  Values MAY be encrypted using a
> manufacturer-generated key (which locks the value to the device), or a
> key generated by a *privileged* admin, which opens up the possibility
> for the key to float between devices.
> 
> Specifically, imagine the following:
> 
> Precondition:
> 1) devices are shipped from manufacturer with a hidden asymmetric key
> in <operational>
> 
> Post-SZTP Onboarding:
> 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.

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.

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

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


> Device Swap:
> 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?

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

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

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




/martin


> 
> 
> Below are the change log entries.
> 
> crypto-types:
> 
>    o  Removed the 'generate-key and 'hidden-key' features.
> 
>    o  Added grouping symmetric-key-grouping
> 
>    o  Modified 'asymmetric-key-pair-grouping' to have a 'choice'
>       statement for the keystone module to augment into, as well as
>       replacing the 'union' with leafs (having different NACM settings.
> 
>    o Diffs:
>    https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-08
>    <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-08>
> 
> 
> keystore:
> 
>    o  Replaced typedef asymmetric-key-certificate-ref with grouping
>       asymmetric-key-certificate-ref-grouping.
> 
>    o  Added feature feature 'key-generation'.
> 
>    o  Cloned groupings symmetric-key-grouping, asymmetric-key-pair-
>       grouping, asymmetric-key-pair-with-cert-grouping, and asymmetric-
>       key-pair-with-certs-grouping from crypto-keys, augmenting into
>       each new case statements for values that have been encrypted by
>       other keys in the keystore.  Refactored keystore model to use
>       these groupings.
> 
>    o  Added new 'symmetric-keys' lists, as a sibling to the existing
>       'asymmetric-keys' list.
> 
>    o  Added RPCs (not actions) 'generate-symmetric-key' and 'generate-
>       asymmetric-key' to *return* a (potentially encrypted) key.
> 
>    o Diffs:
>    https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-11
>    <https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-11>
> 
> 
> 
> 
> Kent // contributor
> 
> 
> 
> 
> 
>