Subject: Re: [netconf] ietf crypto types - permanently hidden

From: Kent Watsen <[email-masked]>
Date: Tue, 4 Jun 2019 16:24:46 +0000

Hi Juergen,

> Some comments:
> 
> - Not sure what security best practice is and where it is defined.

https://mailarchive.ietf.org/arch/msg/netconf/duOgrXt6P-WwO-Vdole9SsxS2vg <https://mailarchive.ietf.org/arch/msg/netconf/duOgrXt6P-WwO-Vdole9SsxS2vg>

>  Creating the key on the device has the benefit that the key may
>  never have to leave the device but it also requires that I can trust
>  the device to create good keys. (People recall the glitch that led
>  to weak openssh keys on many Linux systems? And given todays world,
>  which devices should I trust to generate strong keys?) I might
>  decide that creating keys with known software I am willing to trust
>  is far better than trusting a key generator shipped by a random
>  device manufacturer.

Yes, and I've said the same here as well.  Both options should be supported.

> - Side effects are bad and should be avoided. If something requires an
>  rpc/action, make it an rpc/action.
> 
> - If you create something, give it a name; once things are named (or
>  have other unique properties), config can then refer to these named
>  objects. A create key operation might simply return a fingerprint
>  for the key as the key's name.

I'm unsure how to apply this beyond what has been discussed.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 4 Jun 2019 16:48:01 +0000

Hi Balazs,

> Also validation of required input and output seems more complicated to me.
>  
> How so?
>  
> The ‘value-to-be-generated’ “action” would require both the private-key and public-key set to the same, plus the algorithm be configured. Besides, if there is a must statement on any of these, does the must statement consider the ‘input’ or the ‘output’ values? I got a bit confused while thinking on these.

If I understand correctly, this could be addressed by a 'must' statement to ensure both the public and private key values have the "<value-to-be-generated>" prefix.

> Actually, I view  ‘generate-and-not-hide’ as a very common case.  That is, ask the system to generate the key (because clients are lazy and security best practice), and let standard NACM rules protect the key.   I think that systems supporting user-generated "hidden" keys will be somewhat rare, to the extent that there should feature statements enabling servers to indicate if they support the ability or not.
>  
> Maybe generate-and-not-hide would be widespread, but it is not my preferred choice of key handling due to that it opens up to the client to manage the key blob after first generation. So maybe all of these should be optional with features?

Yes, assuming we go this route...

> [...] 
> This removes the "verbs" (as you call them) and thus leaves open possibility for either "verbs" or action statements to be added in some future revision.   This subset still supports the critical use-case of a manufacturer-generated private key for a secure device identifier (i.e., IDevID).    Unfortunately, it does not support the security best practice use-case of having the device generate the private key.  The IESG (Security Directorate) may or may not be okay with this (obviously the shepherd would have to bring it to their attention), but perhaps it's worth testing their resolve and see what happens?
>  
> If so, can you clarify the configuration use case of client configuring <permanently-hidden>, does that produce a valid end-result?

With the latest no-"verbs" proposal, there would be no ability (defined by this model) for a client to itself create a 'permanently-hidden' key; only the manufacturer could do that.  However, in order for a client to use the manufacturer-generated hidden key, it would need to "copy" it from <operational> to <running>.   In <operational>, the 'algorithm' and 'public-key' values would be visible, but the 'private-key' would have the value 'permanently-hidden'.  So, in order to "copy" the key to <running>, the client would (presumably) copy these three values as they are in <operational>, including the string "<permanently-hidden>" for the private-key's value.  The description of the node would state that this is the only time a client can legally configure the value "<permanently-hidden>" (i.e., when the same key already exists in <operational>)

> Or would that be only an output pattern created as the result of a ‘generate-hidden-key’ action that may be added by an implementation augmenting the model?

It is primarily intended to be an output-only pattern, with the exception being that mentioned above.

> Regarding ‘encrypted by’, would that be only used when the device allows to back up encrypted keys to later restore it to same device (or any other that may get hold of the same encryption key in some way)?

Correct.  For example, TPM chips have the ability to encrypt keys using their "storage root key" (SRK), which 1) enables the key to be safely exported but 2) only the TPM having the SRK can import/decrypt it.   While I don't think it's possible for TPMs to migrate an SRK, other implementations may support that ability and so, as you say, it could possibly be put onto another device.

Kent // contributor