Subject: [netconf] ietf crypto types - permanently hidden

From: Balázs Kovács <[email-masked]>
Date: Thu, 21 Mar 2019 14:23:27 +0000

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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 21 Mar 2019 15:11:51 +0000

[CC-ing Henk, who knows a little about TPMs]

Hi Balazs,

> 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:
>  
> Th second sentence doesn’t sound right. I can create a permanently hidden key any time by calling the ‘generate-hidden-key’ action,

True, but *when* the action is called is not pertinent, right?

> or if the device or the model allows I could even switch to non-hidden key, I believe, by providing the binary.

How would you get the binary?   Yes, some implementations, as a hack, MAY not actually use a cryptographic processor, but that is besides the point.   The intent with this action statement is that a cryptographic processor IS used and that the private key is forever hidden.

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

Maybe.  I am aware that e.g., TPMs, have the ability to backup a key but, I think that doing so necessitates that the key is encrypted with the SRK (storage root key) such that only the same TPM chip can decode it (Henk, can you check me on this statement?).  To this end, I agree that the last sentence is too strongly worded.

> I would prefer to remove this sentence and leave backup considerations to implementations.

Remove or replace, let's keep the conversation going. 

> Could these changes be done?

Sure, pending the outcome of this thread.

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Mar 2019 16:29:20 +0100

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

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Balázs Kovács <[email-masked]>
Date: Fri, 22 Mar 2019 12:44:05 +0000

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.

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 <[email-masked]> 
Sent: Thursday, March 21, 2019 4:29 PM
To: Balázs Kovács <[email-masked]>
Cc: [email-masked]; Kent Watsen <[email-masked]>
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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Mar 2019 14:06:59 +0100

I think we should make sure that it is clear to the client how a
device handles 'hidden' keys, i.e., via a capability (if this is a
system wide property) or via additional knobs that tell the client the
details on a per key basis. It makes a big difference whether a key is
generally protected or only via the NC/RC/.. interface.

/js

---

From: tom petch <[email-masked]>
Date: Fri, 22 Mar 2019 16:28:15 +0000

----- Original Message -----
From: "Balázs Kovács" <[email-masked]>
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 <[email-masked]>
Sent: Thursday, March 21, 2019 4:29 PM
To: Balázs Kovács <[email-masked]>
Cc: [email-masked]; Kent Watsen <[email-masked]>
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:
> 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.

---

From: Kent Watsen <[email-masked]>
Date: Sat, 23 Mar 2019 19:23:25 +0000

[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 <[email-masked]> wrote:
>

---

From: Balázs Kovács <[email-masked]>
Date: Mon, 25 Mar 2019 13:00:49 +0000

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 <[email-masked]> 
Sent: Saturday, March 23, 2019 8:23 PM
To: tom petch <[email-masked]>
Cc: Balázs Kovács <[email-masked]>; Juergen Schoenwaelder <[email-masked]>; [email-masked]
Subject: Re: [netconf] ietf crypto types - permanently hidden

Kent // contributor

Sent from my iPad
> 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
> 
> already 'hidden' if it only exists in <operational>. Is this really a 'hidden'
> 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 
> 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.
>>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 29 Mar 2019 20:25:26 +0000

Hi Balazs,

> 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 syst…

True.

> 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. Howeve…

As I understand it, your intention is to have users 1) use actions to generate private keys and CSRs and 2) that the private-key value is otherwise inaccessible to the users.   I don't believe you have a concern with the keys being "configuration" (since the nacm:default-deny-all makes the value inaccessible), and that the only bad part with the current model is that the user has to pass the private key value, which is bad because a) they are aware of the private key value and also it's possible that the private key value they generate is poor quality (e.g. having low entropy).

This is effectively what was defined on page 22 in https://tools.ietf.org/html/draft-ietf-netconf-keystore-00 <https://tools.ietf.org/html/draft-ietf-netconf-keystore-00> (we moved to the current strategy in the next version of that draft where (surprise!) the enum was called "INACCESSIBLE".   Some more history is here: https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRvez48 <https://mailarchive.ietf.org/arch/msg/netconf/OtYAlqLmlErfCr3Z4mcXqRvez48>.

The main problem with this is actions don't typically create configuration, though we certainly could define this action as doing so (i.e., it locks <running> when called)...and we might even see ourselves doing this even for keys that are *interactively* generated by a cryptographic processor.  Of course, any keys generated by the vendor during manufacturing (i.e., the IDevID key) would still be operational state.

In order to support systems that have crypto processors, since it may not be desirable to use the cryptographic processor for all keys, we need either a parameter or another action to direct the system to use the crypto processor to generate the key.

Regarding what does "inaccessible" mean, the intention is that the value is not accessible for reasons beyond access control, with this driving use-case being a cryptographic processor.   Since the term (inaccessible) is being used in a YANG module, it stands to reason that it applies to all YANG-driven interfaces and that there is no statement regarding how it may or may not be "inaccessible" in other interfaces.  That said, the goal of YANG modules is to model reality, not just a view presented by YANG-driven interfaces, and I imagine great confusion ensuing if mismatches exist across interfaces.

I agree that the description statement for the "permanently-hidden" enumeration can be improved, how about this?

    leaf private-key {
      nacm:default-deny-all;
      type union {
        type binary;
        type enumeration {
          enum permanently-hidden {
            description
              "The private key is inaccessible due to being
               protected by the system (e.g., a cryptographic
               hardware module).";
          }
        }
      }
      ...
    }

Notes:

1) I removed the "It is not possible to configure a permanently hidden key, as a real private key value must be set." text because it was confusing and yet what's intended is self-evident (i.e., the leaf is a union of a value and an enum, only one can be passed).

2) I removed "Permanently hidden keys cannot be archived or backed up." text because it was a bit overreaching.  As mentioned, even TPM-protected keys can be backed-up/restored if shrouded and the restoration is to the same machine.  The more correct statement is "RMA workflows are limited", but it doesn't need to be said here.

If the goal is to open up these actions for general use, I think that we SHOULD update them to generate *configuration*.   Clearly the intent is that keys are configuration, use of the action should be seen as supporting a best practice, but otherwise shouldn't change the characteristic that interactively-generated keys are configuration.

Thoughts?

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Mar 2019 21:53:16 +0100

I agree, I think we need to distinguish

- upload of keys
- generation of keys on the box that become (protected) configuration
- generation of keys on the box that will to into hardware protected
  storage (and never be accessible)

and the creation of a private key that becomes (protected)
configuration is similar to the creation of a user account, where an
unused uid is allocated that becomes configuration.

/js