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

From: Balázs Kovács <[email-masked]>
Date: Fri, 2 Aug 2019 12:41:14 +0000

Hi,

One question regarding migratable keys. The conversation between Kent and Martin was concluded with this in the list:

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

I don't see how migration is possible here. The migratable keys were generated on the first device and are encrypted with the operator key of the first device. Does the second device has a different operator key? If yes, the migrated encrypted keys cannot be decrypted by the second device.

Unless I misunderstand this statement (which I don't see how to achieve in the model):

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

Does this well-known symmetric key mean that the symmetric key was generated externally thus its clear value must be configured to /ks:keystore/ks:asymmetric-keys/ks:asymmetric-key/ct:private-key? How is the operator key configured in clear to the second device so that it gets encrypted with the hidden manufacturer key of the second device?

Br,
Balazs

---

From: Kent Watsen <[email-masked]>
Date: Fri, 2 Aug 2019 23:47:59 +0000

Migrating configuration, including encrypted keys, from device-1 to device-2.

Preconditions:

    1) the client possesses a "secret" symmetric key
         - for this example, the key's clear-text value is known to the organization's 
           "crypto officer", but it seems that it could as well be protected by an HSM.
         - this symmetric key value MAY be unique per device, region, or whatever
           boundary the organization chooses up to being globally shared by all
           devices.

    2) devices 1 & 2 each posses a unique asymmetric key that, e.g., may be
        associated with an secure device identity (e.g., IDevID)

+--------+           +----------+          +----------+
| client |           | device 1 |          | device 2 |
+--------+           +----------+          +----------+
    |                     |                     |
    | 1. get config       |                     |
    |-------------------->|                     |
    |                     |                     |
    | 2. scrub config     x                     |
    |-----------------+                         |
    |                 |                         |
    |<----------------+                         |
    |                                           |
    | 3. get tpm protected asymmetric key       |
    |------------------------------------------>|
    |                                           |
    | 4. encrypt operator's symmetric key       |
    |--------------------------------------+    |
    |                                      |    |
    |<-------------------------------------+    |
    |                                           |
    | 5. stitch encrypted op key into cfg       |
    |--------------------------------------+    |
    |                                      |    |
    |<-------------------------------------+    |
    |                                           |
    | 6. stitch additional info into cfg        |
    |--------------------------------------+    |
    |                                      |    |
    |<-------------------------------------+    |
    |                                           |
    | 7. set config                             |
    |------------------------------------------>|
    |                                           |
    |                                           |

Steps:

1. get config

    - the client gets the full configuration from device-1
    - this config would contain an entry for an encrypted operator key
    - this config may also contain an entry for the tpm protected key

2. scrub config

    - remove the encrypted operator key
    - remove the tpm protected key, if present

3. get tpm protected asymmetric key

    - the client gets the tpm protected key from device-2
    - this key's "private-key" value would be hidden
    - only the algorithm and public-key values are present

4. encrypt operator's symmetric key

    - using device-2's public-key, encrypt the operator's "secret" symmetric key
    - this is a local operation, using any crypto library

5. stitch encrypted op key into cfg

    - put the new encrypted operator key into the config

6. stitch additional info into cfg

    - put other, presumably non-migratable info into the config
      (e.g., node-locked licenses, etc.)

7. set config

    - set the new config onto device-2

Done.  Makes sense?

Kent // contributor

> On Aug 2, 2019, at 8:41 AM, Balázs Kovács <[email-masked]> wrote:
> 
> Hi,
>  
> “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.”
>  
> I don’t see how migration is possible here. The migratable keys were generated on the first device and are encrypted with the operator key of the first device. Does the second device has a different operator key? If yes, the migrated encrypted keys cannot be decrypted by the second device.
>  
> Unless I misunderstand this statement (which I don’t see how to achieve in the model):
>  
> “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.”
>

---

From: Balázs Kovács <[email-masked]>
Date: Mon, 5 Aug 2019 07:58:52 +0000

Hi Kent,

Yes, it makes.

I assume the “secret” symmetric key could be just equally configured as normal private-key since the key is coming from outside, depending on the taste of the client if it is just a NACM protected normal private-key or an encrypted key.

Br,
Balazs

From: Kent Watsen <[email-masked]>
Sent: Saturday, August 3, 2019 1:48 AM
To: Balázs Kovács <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] latest update to crypto-types and keystore drafts

Preconditions:

Steps:

1. get config

2. scrub config

7. set config

Done.  Makes sense?

Kent // contributor

On Aug 2, 2019, at 8:41 AM, Balázs Kovács <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Br,
Balazs

---

From: Kent Watsen <[email-masked]>
Date: Mon, 5 Aug 2019 18:46:28 +0000

> On Aug 5, 2019, at 3:58 AM, Balázs Kovács <[email-masked]> wrote:
> 
> Hi Kent,
>  
> Yes, it makes.
>  

Since a symmetric key have "secret" value more so than "private" value, if we replace "private-key" with "secret-key" above, then yes, I agree.  Stated more plainly, a platform that doesn't have a TPM (or equivalent) protected asymmetric key, could instead protect the operator's symmetric key using NACM (i.e., only the crypto-officer/ restore-session can access it).  Is this what you mean?

> Balazs

Kent

---

From: Balázs Kovács <[email-masked]>
Date: Tue, 6 Aug 2019 07:11:14 +0000

Hi Kent,

Yes, sorry. This addition of symmetric-key is still to new to me. I meant the equivalent of clear and NACM protected key under symmetric keys. Which is just called ‘key’ in draft-ietf-netconf-keystore-12.

The reasons could be: the TPM or equivalent key may not exist or may not be present in keystore (which are roughly the same); or since the encryption of the operator-key is all up to the client, the client may just not implement encryption with the TPM or equivalent hidden public key as the client does not see extra security gains with that (the operator-key was created outside anyhow so it is already known by the client).

Br,
Balazs

From: Kent Watsen <[email-masked]>
Sent: Monday, August 5, 2019 8:46 PM
To: Balázs Kovács <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] latest update to crypto-types and keystore drafts

On Aug 5, 2019, at 3:58 AM, Balázs Kovács <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

Yes, it makes.

Br,
Balazs

Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 6 Aug 2019 15:26:36 +0000

Hi Balazs,

I'm unclear if there is a request for a change of any sort here.   One thing that you may be hinting at is that, while the operator can install an operator key, there is no current mechanism to enforce that keys are encrypted with it, or even at all.   

I'm currently unsure if there should be a knob/feature for this.  Perhaps servers should just trust the clients?  Most clients will be wrapped inside a controller/NMS app, and thus may restrict/enforce as needed via their interfaces to the human-operators.  Would this be good enough?

Kent

> On Aug 6, 2019, at 3:11 AM, Balázs Kovács <[email-masked]> wrote:
> 
> Hi Kent,
>  
> From: Kent Watsen <[email-masked] <mailto:[email-masked]>> 
> To: Balázs Kovács <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Aug 5, 2019, at 3:58 AM, Balázs Kovács <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Kent,
>  
> Yes, it makes.
>

---

From: Balázs Kovács <[email-masked]>
Date: Wed, 7 Aug 2019 08:50:59 +0000

Hi Kent,

Yes, so I just wanted to hint and also to get your agreement that there’s nothing enforcing that the client will store the operator key--which you used as a means of migration—in encrypted form. I do not want any change to the model in this matter, I think it is fair enough saying encryption in this case is up to the client.

Br,
Balazs

From: Kent Watsen <[email-masked]>
Sent: Tuesday, August 6, 2019 5:27 PM
To: Balázs Kovács <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] latest update to crypto-types and keystore drafts

Hi Balazs,

Kent

On Aug 6, 2019, at 3:11 AM, Balázs Kovács <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kent,

Br,
Balazs

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 5, 2019 8:46 PM
To: Balázs Kovács <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netconf] latest update to crypto-types and keystore drafts

Hi Kent,

Yes, it makes.

Br,
Balazs

Kent