Re: [secdir] (Early) Secdir review of draft-ietf-netconf-keystore

[Sandra Murphy <[e-mail]>]

I interpreted the “shared root key” as a key encryption key — I don’t think you eliminate any issues.

(The term is common, but I haven’t found an ietf definition to reference, so I can’t say it *is* a key encryption key.)

wrt: “one can rotate or renew the key encryption key” 

I thought the migration process might work to rotate the root key, not the “shared root key”.  So the “first server” is server Bob with root key Bob.Tues-key and “second server” is server Bob with root key Bob.Wed-key.  Do you think that works?

Magnus’ mention of “renew” brings up the topic of key lifetimes, which I realize I did not think to mention.  (Yep, out of all those words, I did not mention something I should have.)  This draft includes expiration times for the certificate, but no key lifetimes, here or in the crypto-types draft.  RFC8177 does include lifetimes for keys, for the purpose of establishing valid intervals of use and key rollover.  Was key lifetime considered?

—Sandy

> On Aug 10, 2020, at 9:26 PM, Kent Watsen <[e-mail]> wrote:
> 
>> 
>> Likewise, the use of the term "root key" is a bit unclear. A "root key" normally refers to an asymmetric key, but in this text it could be either.
>> 
>> More broadly, it may be advantageous to consider a hierarchy, where a key encryption key is used to encrypt all keys in a configuration and this key encryption key in turn is protected by a root (or master) key. This way, two instances only need to share the key encryption key and there's no need for shared root keys (which may present an issue). Likewise, one can rotate or renew the key encryption key if desired, whereas this usually is harder for root keys.
> 
> What you say is the intention, but the terminology used seems to be off.   The alignment needed is:
> 
>   Root key —> Master Encryption Key (MEK)
>   Shared root key —> Key Encryption Key (KEK)
>