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

[Balázs Kovács <[e-mail]>]

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 <[e-mail]>
Sent: Tuesday, August 6, 2019 5:27 PM
To: Balázs Kovács <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] latest update to crypto-types and keystore drafts

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 <[e-mail]<mailto:[e-mail]>> wrote:

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 <[e-mail]<mailto:[e-mail]>>
Sent: Monday, August 5, 2019 8:46 PM
To: Balázs Kovács <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [netconf] latest update to crypto-types and keystore drafts





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

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.

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?





Br,
Balazs


Kent