Re: [netconf] ietf crypto types - permanently hidden

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

Hi Kent,

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.

 I’m also thinking do we need the ‘generate-and-not-hide’ and the ‘install-and-hide’ use cases?

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?


we have:

   leaf private-key {
     nacm:default-deny-all;
     type union {
       type binary;
       type string {
         pattern
           '<permanently-hidden>'
         + '|<encrypted by="*">[A-Za-z0-9+/]+[=]{1,3}'
       }


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? 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?
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)?

Br,
Balazs


From: Kent Watsen <[e-mail]>
Sent: Thursday, May 30, 2019 4:14 PM
To: Balázs Kovács <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] ietf crypto types - permanently hidden


Hi Balazs,

In case of crypt-hash, I can accept the extension of the crypt(3) schemes with a $0$ that sort of represents a hash() action, since it matches the original crypt(3) syntax.

In this case, I find it awkward to tell what to do with the data (verbs) as prefixes of the data.

Agreed, but we seem to be at an impasse and I thought this approach could get us over the line.



I personally preferred actions better for this purpose.

It is my preference to use actions as well, but there's pushback there.  Maybe we could claim that the pushback is "in the rough" and press ahead regardless, but I'd rather avoid that if possible.



I assume that this representation also does not change the matter of “actions” affecting configuration (see ‘output’ values).

You mean, exploring this solution leaves the "is it possible for actions to affect configuration" as unresolved?  - correct, that discussion would remain open.



Also validation of required input and output seems more complicated to me.

How so?


The generate action returning the name of the key or optionally creating configuration sounded so far the closest match to me.

Understood.



 I’m also thinking do we need the ‘generate-and-not-hide’ and the ‘install-and-hide’ use cases?

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.


---

I'm growing weary of this discussion.  Perhaps we should do even less for the first release of the crypto-types module.  That is, instead of:

   leaf private-key {
     nacm:default-deny-all;
     type union {
       type binary;
       type string {
         pattern
           '<permanently-hidden>'
         + '|<encrypted by="*">[A-Za-z0-9+/]+[=]{1,3}'
         + '|<value-to-be-generated(-and-hidden)?>'
         + '|<value-to-be-hidden>[A-Za-z0-9+/]+[=]{1,3}';
       }

we have:

   leaf private-key {
     nacm:default-deny-all;
     type union {
       type binary;
       type string {
         pattern
           '<permanently-hidden>'
         + '|<encrypted by="*">[A-Za-z0-9+/]+[=]{1,3}'
       }


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?


Kent // contributor