Re: [netconf] ietf crypto types - permanently hidden

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

Hi,

In some implementations I can understand that backup/restore is via YANG interface, but backup/restore is possible by other methods too. On the other hand, the private key material should be created and kept on the owner device according to best security practices and certification done by for example a certificate signing request.

In that sense the generate-hidden-key action and the CSR creation action are solving the most common need for handling keys, and that is really regardless if the key is stored in a TPM, a file system, or centralized KMS.

I personally was fine with 'hidden' and I was also ok with the current actions, it was only the descriptions that seemed to be restrictive to TPM usage, thus I was asking some clarification. However, if 'hidden' is not true this way, then just call it 'generate-key'. Would that then create a binary string for the 'private-key' in operational too instead of 'permanently-hidden' thus you are referring to a 3rd option?

Br,
Balazs

-----Original Message-----
From: Kent Watsen <[e-mail]> 
Sent: Saturday, March 23, 2019 8:23 PM
To: tom petch <[e-mail]>
Cc: Balázs Kovács <[e-mail]>; Juergen Schoenwaelder <[e-mail]>; [e-mail]
Subject: Re: [netconf] ietf crypto types - permanently hidden


[top-posting for convenience]

At first we had an RPC to create a key-pair (protected or not) so as to support the best practice of the private key never leaving a device.  But backup/restore became an issue, and Martin made a persuasive argument that the private key SHOULD be configuration (not operational state).  Thusly, we relegated the RPC (now called “generate-hidden-key”) to the special case where the system generates a key that is operational-state and inaccessible (at least, not in its raw form; it may be accessible in a shrouded form) and, for all other cases, the client MUST configure the key pair (transmitted over the wire, not best practice, oh well).

Currently there are only these two options, based on the accessibility of the private key. Is the request to introduce a third option, but isn’t the intent better supported by access-control?  [the “private-key” leaf is nacm:default-deny-all]. 

Renaming “hidden” to “inaccessible” seems okay albeit, in both cases, it’s the unspecified subject (client vs system) that matters (i.e., hidden/inaccessible to whom?).  

Kent // contributor



Sent from my iPad
> On Mar 22, 2019, at 5:28 PM, tom petch <[e-mail]> wrote:
> 
> ----- Original Message -----
> From: "Balázs Kovács" <[e-mail]>
> Sent: Friday, March 22, 2019 12:44 PM
> 
> Hi,
> 
> I would really prefer the definition for 'hidden' as 'not accessible 
> via YANG protocols'. The explanation is that regardless of what method 
> I use to create/store the private keys, I still might not want the 
> operator to generate keys outside of the device or configure binary secret strings.
> 
> <tp>
> 
> I think that the meaning of the term 'hidden' varies depending on 
> which part of the I-D you are reading.  The term is absent from the 
> referenced RFC, 8017 and 5915, which is probably not a coincidence.  
> Rather, the terminology of the literature is of a key pair, made up of 
> a public and private key so the action generate-hidden-key { probably 
> means generate-key-pair; but, in other places, the word 'hidden' 
> clearly has different semantics and would probably best be replaced by 
> something else, such as inaccessible.
> 
> Tom Petch
> 
> I considered TPM protection for hidden keys is an option or example so 
> far, which adds limitations or additional complexity for moving keys, 
> but should not be the only option for hidden keys. The descriptions 
> mention TPM as example, then the rest of the text should align also to 
> keep that as example.
> 
> Br,
> Balazs
> 
> -----Original Message-----
> From: Juergen Schoenwaelder <[e-mail]>
> Sent: Thursday, March 21, 2019 4:29 PM
> To: Balázs Kovács <[e-mail]>
> Cc: [e-mail]; Kent Watsen <[e-mail]>
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> I agree, I do not understand the second sentence either. My problem is 
> that I do not know what a 'real' private key is, are hidden keys 
> somewhat unreal? Or is "not hidden" = "real"?
> 
> The last sentence can probably be fixed; I think the intention was to 
> say that you can't backup and restore hidden keys by retrieving 
> configuration and restoring the configuration.
> 
> In general, I think we need a definition what a hidden key is. Is 
> something not exposed via a YANG interface a hidden key (but it may be 
> a regular key when using other device access methods)? Or do we 
> require that a hidden key is generally protected? I assume some people 
> want to have flexibility here but from the viewpoint of a security 
> administrator it matters a lot whether 'hidden' means 'generally not 
> accessible' or only 'not accessible via YANG protocols'.
> 
> The description of install-hidden-key seems to indicate a key is 
> already 'hidden' if it only exists in <operational>. Is this really a 'hidden'
> key or more an 'ephemeral' key?
> 
> /js
> 
>> On Thu, Mar 21, 2019 at 02:23:27PM +0000, Balázs Kovács wrote:
>> Hi,
>> 
>> The 'generate-hidden-key' action is meant for cases when the key must
> be generated in the device and not the operator is configuring it. The 
> 'generate-hidden-key' is said to produce a 'permanently-hidden'
> asymmetric key. The description of 'permanently-hidden' is as follows:
>> 
>>                "The private key is inaccessible due to being
>>                  protected by the system (e.g., a cryptographic
>>                  hardware module).  It is not possible to
>>                  configure a permanently hidden key, as a real
>>                  private key value must be set.  Permanently
>>                  hidden keys cannot be archived or backed up.";
>> 
>> Th second sentence doesn't sound right. I can create a permanently
> hidden key any time by calling the 'generate-hidden-key' action, or if 
> the device or the model allows I could even switch to non-hidden key, 
> I believe, by providing the binary. So I find the second sentence 
> irrelevant in this description.
>> 
>> More importantly, I find the "Permanently hidden keys cannot be
> archived or backed up" statement false. Isn't that implementation 
> specific how archiving is done? If a device puts the hidden keys on 
> some storage, it may still be possible to back them up. I would prefer 
> to remove this sentence and leave backup considerations to implementations.
>> 
>> Could these changes be done?
>> 
>> Br,
>> Balazs
> 
>> _______________________________________________
>> netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
> 
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>