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

From: Kent Watsen <[email-masked]>
Date: Tue, 18 Jun 2019 02:45:07 +0000

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

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

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.

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Jun 2019 10:56:08 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> 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.
> 

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

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 26 Jun 2019 23:37:48 +0000

> The device could also store this key (or rather just the name) in its

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

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

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

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

> Before loading the previous config, the admin must do steps 2-3 on the

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.

> be re-installed so that it is encrypted with the new device's public

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.

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

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

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Jun 2019 17:30:12 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> 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.

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

Agreed.  Deleting the name from the config doesn't wipe the hw key.

> This is true even when
> wiping the device for sale...
> 
> 
> 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.

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

> , 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.]
> 
> 
> 
> 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?

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.

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

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

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

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

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

Yes I think this looks promising!

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

/martin

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jun 2019 00:22:32 +0000

Hi Martin,

> can delete it from the config, just as if it had been created by an

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.

> able to modify the public key of a hw-stored key?  It is just error

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)

> If you need the public key why is it a problem to read it from

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

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

> stored encrypted.  But that one key needs to be as protected as

Agreed.

> Or perhaps state that the management of such keys are out of scope

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.

> in clear text in the config.  In this case we could as well use NACM

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.

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

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

> unless there's some strong historical reason for keeping

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

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Jun 2019 14:22:25 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> Based on your later comments, it seems that we're more in agreement
> than not.

Good!

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

Well, I wouldn't express this as "the key is immutable", but rather
that the factory defaults configuration datastore is immutable /
read-only.

> Now, upon that configuration being
> copied into <running>, the configuration would become editable and
> said keys could be removed.
> 
> 
> 
> 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)

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

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

Ok.  This makes sense.

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

Ok!

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

>       a) <running> (copied from <factory-default>), would NOT contain a key
>       having the 'key' value as the incoming key.

For this use case I think it is a prerequisite that the key has the
same name.

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

        <!-- 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)

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

> even asymmetric keys can do encryption.

Ok, let's have that discussion in the crypto-types thread.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Fri, 28 Jun 2019 14:36:06 +0000

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

> public key and alg are not present in the config this is not an

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.

> For this use case I think it is a prerequisite that the key has the

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.

> So this requires the client to pacth the config a bit.  Perhaps this

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