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

[Kent Watsen <[e-mail]>]

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