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

[Kent Watsen <[e-mail]>]

Hi Sandy,

I think you’re making two comments, but there may be more!


1) is there support for key-lifetime/expiration?

The answer is “no” (or, perhaps, “not yet”), for the simple reason that key file formats (e.g., OpenSSL RSAPrivateKey, ECPrivateKey, AESKey, etc.) do not have fields for validity periods.  Do you think this module should add such a field (like RFC 8177)? - if it did, then the module certainly could also define a key-expiration notification.  Please advise.


2) Can KEKs be renewed / rolled over?

Yes, but not like in RFC 8177.  I’m not a routing person, but my understanding to that RFC 8177’s approach is visible in routing protocol messages...

In contrast, configuration is being set and there may only be the “current” key.  That said, a renew/rollover might be implemented as follows:

   - crypto-officer generates a new KEK
   - for each device having the same KEK (e.g., primary/failover devices):
        - crypto-officer encrypts the KEK with the device’s MEK
        - crypto-officer hands off the encrypted-KEK to a regular admin
        - regular-admin loads the encrypted KEK into the device
            - note that, at this time, no switchover has occurred yet
        - for each key on the device encrypted by expiring KEK:
            - regular-admin requests the device to encrypt the key using
               the new KEK (no switchover has occurred yet).  In pseudocode:
               new-encrypted-key = new-kek.encrypt(cleartext-key) (see [1])
            - regular-admin replaces the key (encrypted by the expiring
              KEK) with the new (really the same) key (encrypted by
              The new KEK).
                           
[1] this entails the regular admins knowing the cleartext clears, which is NOT best practice, but a necessary(?) consequence of the decision discussed here: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-17#section-3.2.   

To be clear, there were before two RPCs: generate-symmetric-key() and generate-asymmetric-key().  If IETF were to rescind this decision, or when a future effort fills in the missing piece, then it would make sense to additional RPC called, perhaps, reencrypt-symmetric-key() and reencrypt-asymmetric-key().

[Update, due to second-guessing myself] Hmmm, the reasons for why the two “generate” RPCs couldn’t be defined may not apply/limit the creation of said “reencrypt” RPCs…is this something you think should be added?

Regardless if said “reencrypt” RPCs are added or not, do you think the draft should extend “Encrypting Keys in Configuration” section with the above sketch of steps?


Please let me know if there were more than these two questions in your comment.

Thanks,
Kent



> On Aug 13, 2020, at 10:44 AM, Sandra Murphy <[e-mail]> wrote:
> 
> 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)
>> 
>